Privacy Policy

Why a Model Based Approach Really is an Advantage!

Why a Model Based Approach Really is an Advantage!

00:00:13] Hello, my name’s Alan Barens from Texas, and today I’m joined by Paul Brown, Ullapool Whyalla, Paul is the senior director of marketing for Siemens Digital Industries, and we’re here to discuss model based propositions. This is the second of a set of videos that we’re going to be using to talk about these types of technologies. So let’s get cracking.

[00:00:38] Paul, what are we talking about when we’re talking about model based?

[00:00:42] Well, I think there’s a number of topics that we talk about in the previous examples. We’ve looked at how the model can be used as the basis of getting information downstream. But I think what we really want to talk about now is, is about the upstream process. How do we feed into the model and use the model as the base for being able to to validate products and make it, you know, make the right product to market.

[00:01:11] So so we’re talking about starting at, say, requirements, for instance, is that right?

[00:01:16] Yeah, absolutely. We’re looking at know right at the beginning requirements, specifications, you know, all the all the things that control the definition of what’s going to end up as the final product.

[00:01:30] And a lot of people sort of listen to these types of conversations. And I think we’ve heard so much jargon and so many acronyms and these these sort of conversations. And that’s just pass a couple of Biosystems engineering and RFLP and things, you know, acronyms which people get confused about. What we really want to try and do is bring this down to earth and talk about this in a different level, practical level.

[00:01:56] Yeah, absolutely. I think the challenge I mean, we all we all love acronyms and we everyone keeps throwing out these new phrases. And so you’ll start hearing and you mentioned RFLP, which is, you know, requirements, functional, logical, and then and then the product. So the whole idea of going through those cycles, you keep hearing things like KPI key performance indicators, which means what? What what’s the target? Why am I trying to do and what what is the goal I’m trying to hit. Right. And if you think about it, anyone that’s designing developing product right from the outset has some goals. So it’s not like people aren’t doing this. It’s not like this is it’s really maybe they’ve not packaged it all up into the this kind of jargon. And I think the jargon scares people off in many cases.

[00:02:48] Yeah, that’s an interesting observation, actually. But I suppose if we move on from the jargon and say, right, so this is about figuring out how to systematise product development from requirements through to the product right through to the working product. In one case, we were taught in a previous sort of edition of this video about the 3D model based information. How is this different?

[00:03:17] Well, when we look at the using the 3D model one and we look at things like adding annotation to that to feed downstream, really you’ve done your definition. You’ve actually built something that you’re pushing. You’re trying to push, communicate more of the intent behind this. But so what we really want to look at now is say is how they write from the requirements into those things that drive the decisions that you’re making when you’re designing and developing product that that side of the process. So it’s really like two overlapping areas. One is more downstream and this is more at the in the early stage bar spans the entire lifecycle because importantly, as we go through this, you know, things happen that drive and change requirements change feedback. So that loop of how we change things. But we talk about that as we go through.

[00:04:10] And what sort of type of organisation would need to think about these model based paradigms?

[00:04:17] Well, I think in many cases that you’ve got larger enterprises are more formalised in their structure. We have we know we have customers already have very formal structures for doing this. They are very systematic approaches to this. But in many ways it affects all companies. And I think one of the key elements now is business is becoming more and more complex. And in fact, complexity really is now the new norm. And because products are becoming more complex, the expectation products are looking at when we talk about things like connected products, when we talk about augmented products, autonomous, when we talk about vehicles, all those things are coming into play. And what that means is the type of product development is changing. I was talking to a customer not long ago and they a small customer. So we talk about the enterprise of VMware structured. But I as a small customer, 10 people, and they said when they first started business about 20 years ago, all of those 10 people were really either industrial designs. In other words, looking at the style and former fit or mechanical design. Now, over half their work is software and user interface because the world has changed and in bringing together multiple domains is adding the complexity.

[00:05:40] And, you know, we all know that in the past, a lot of these sort of domain and organisational structures have been separate. The people sit in separate groups that separate educational programmes with organisations that perhaps talk at the end of the day about integrating this into a product. But that’s not the case anymore, is it?

[00:06:03] No. In fact, more and more you’re seeing that people have to effectively co develop. You have to if you’re going to survive and thrive in this complex world, you have to start thinking across the organisation, across the domains. You can’t have these silos because if you do that, you’re in a constant rework type situation, which doesn’t work with the pace of business now. So what you’ve got to do is both look at code design and then validate, validate against the requirements and the specifications and say everyone is working towards a level of requirements and specification. No matter what business you’re in, you always have a certain end goal. You’re trying to get to the constantly validating against that.

[00:06:48] Right. And I mean, let’s just go back a stage. We’re talking about companies that have a problem. And the problem is complexity, whether it’s big companies or complex products or complex interactions between departments, whether they be big or small. And I think everybody suffers from this. And we don’t have we can’t just put employees into positions to solve the problems, can we? I mean, it’s it is a sophistication issue as well as a complexity issue.

[00:07:19] Oh, absolutely. I think it’s both basic sophistication level. It does require mindset. I mean, we have you have to have people thinking about this across the different disciplines as well. You can’t carry on with with silos. And so also, I would say it’s not just a technology problem. It’s you can put technology in, but technology alone won’t solve it. You have to look at the the process and how you tie these things together and what what makes sense to to ripple across the organisation.

[00:07:53] Great. So let’s take a few minutes out and then come back and talk about how we go about solving this problem, how to apply the apps and technologies to help with a sort of medium new medium of complex model based development.

[00:08:09] Yeah, OK, that’s a good plan. Thanks.