The application of model-based systems engineering – ep. 1 Transcript
In this first episode of the model-based systems engineering (MBSE) series, Nick Finberg of Siemens Global Marketing interviews Tim Kinman, Vice President of Trending Solutions and Global Program Lead for Systems Digitalization at Siemens Digital Industries Software. Tim helps us understand how model-based systems engineering is impacting the automotive industry.
Model-based systems engineering (MBSE) transforms the industries’ approach to the design and build process. It enables visualization, simulation and optimization of products before any actual building occurs. These innovative capabilities make it an integral part of all industries that are addressing product complexity.
Please read more in the transcript below, or listen to the audio podcast.
Read the transcript
Nicholas Finberg: So, Tim, I’ve been hearing a lot of model-based systems engineering as a concept starting to emerge as a sort of predecessor to PLM and other management workflows, and a lot of different people are talking about it. The aerospace and automotive industries are the most prominent. But energy, utilities and other medical companies are looking at adoption. MBSE seems like a hot topic, so why might a company want to embrace it?
Tim Kinman: Well, Nick, model-based has been around for a long time. In the past, we moved from a specification or a document-based view to models that allowed us to work more collaboratively together to simulate and digitalize a lot of this information. So, as we have historically moved from drawings to 3D models to production models, MBSE is just another continuation of that that allows us now to move out of documents into models that represent the scope of the product, and the behavior of the product that drives the physical implementation. So, it’s an evolution of the continuation of a digitalization activity that’s been going on for years.
Nicholas Finberg: So, there are a lot of other ways to say model-based: the model-based design, model-based simulation. Are those all the same?
Tim Kinman: Well, model-based, as I said, model-based says that I have something that I can represent in a digital way that I can repeat or collaboratively simulate. So, it’s a model. And just as we’ve had geometric models, we’re now in the systems area of how we want to build models. And those models could be models that represent a requirement; it could be a functional view, meaning that I have an ability to decompose behavior; so, it could be a simulation model. Therefore, the modeling in this traditional form but in the context now of a system’s definition, which is representing parameters and requirements and functional behavior.
Nicholas Finberg: So, “systems,” is a broad term. Can we ground that in something a little bit more tangible, say, a car? How would you start defining the systems?
Tim Kinman: From an overall system, you would say the system represents all the elements of the vehicle. Now, that could have subsystems; you could have a braking system; you could have an infotainment system – those become subsystems that are working together but still within the context of a singular system definition. And typically, a system is something that is being contained or represented in more of a singular product view; so, it has a lifecycle, it has an operational view, it has a geographical usage view. So, in many ways is self-contained to all the requirements: the behavior, the system injury models, but also now connected into all of the other subsystems that could be an electrical subsystem – the braking or hydraulic system, it really ties it all together in a more singular product definition.
Nicholas Finberg: So, it sounds like it’s more of a collaborative process amongst everyone; you have people working on the infotainment system, you have people working on the mechanical systems. How do they work together?
Tim Kinman: Well, they’re all now working toward a common goal. So, if we look at the past, it was very mechanical-driven; you have things that were more around kinematics and structural elements. And even in those days, they were working together because there’s meeting conditions, there’s collision but it was all geometric. Now, the dependencies are being viewed as interfaces, it could be signals. The things that are now connecting these engineering teams together are no longer only physical, it could be elements of a network that sends signals throughout the system, where now the partners are needing to interact with one another. An example of a vehicle – go back to automotive – you have a sensor, which is a physical thing, but it picks up an incoming signal. Now, I need to transfer that across a network in the vehicle. And as I transfer that to the network in the vehicle, there is an ECU, there’s a board somewhere that’s listening for that signal. And as it picks up that signal, it knows that it needs to take an action because that is the actuator that understands to do work. And now that will physically enable the physics element of the braking system. So, now I’ve just tied together a sensor that now mechanically picks up or electronically picks up the signal, transfers that through an internet type of connection within the vehicle to another device that is listening. And the software then triggers an action to a physical braking of the vehicle. So, all those things are tying together – mechanical, electrical, electronic, and software – to enable that function.
Nicholas Finberg: So, everyone’s working together through the entire process. That sounds like it’s a little bit different than how validation works right now in most of these industries. They do all their work, they know generally where they are working on the project together, but then they hit a point where they just start connecting everything. Is this the major point of change for MBSE?
Tim Kinman: Well, I think one of the major points of change is now, again, it’s no longer physical. If we look at how people worked together before, oftentimes, you would find the failure after the product was built. Or then you thought, “Well, let me be smarter, and I’ll start doing physical prototypes to find the failure before I release the product.” And then people progress to get even smarter yet again, that says, “Well, let me now digitize this, and let me do simulations before I do the physical build.” But now we inject software into this conversation. And now the software part is driving what the physics behavior will result in, which means that I now need to think much, much earlier around not just the structural elements of what I’m building or the physical elements of what I’m building, but what is the operational or the system’s behavior that’s going to drive how it reacts to the operator or how it reacts to its environment? So, the need for verification is much more critical now because I have many more paths through a software logic that is being also impacted to how the physics of the physical will behave as the software is being triggered.
Nicholas Finberg: This speaks to the running example of automotive, but it could also speak to the electrification of airplanes. So, there’s a lot of changes in how stuff is being designed in the aircraft or the automobile – software is definitely part of it. But how do you make sure the requirements from, maybe, government institutions or the public sector, how does that get managed?
Tim Kinman: Well, there’s an information explosion as one thing. I think if you’re talking about the management of the information and the coordination across people, you need an information management system now more than ever, because the volume of information needed and the volume of information that’s being tracked is much higher now than it has been before, coupled with the complexity of the product is much, much higher. So, to answer your question, I think there are different paths, there are different approaches. But if we just think about program planning and execution, there’s one element that says; from concept through final release, I have the need to organize people through a lifecycle of maturity from the beginning, when I start my concept to how I release. So, how I’m managing data and people, typically, is through some type of program, organization, event gates. And those event gates, I then tie to how am I verifying progress relative to my delivery.
And when I’m verifying, I could be verifying against a scope of requirements that sometimes maybe the requirements are measurable very early, there may be other more complex types of functions that are being developed, where those are not coming together integrated until much later in the product cycle. And so, then I’ll have additional event gates that I will be measuring to those integrated functions that work together and satisfy the requirement. And so ideally, over this course of time, you’re orchestrating actions to the engineering teams. You’re measuring their progress relative to the requirements through some verification and simulation results. You’re progressing all the way to the point of final verification and validation that you can show that you’ve closed, by test, to all those requirements that have been noted that represent the product definition, I can now show that I’ve achieved all my requirements, whether it’s functional, nonfunctional, performance, or safety. So, there’s a lot of things going on to keep all the people connected. And again, some of that is optimizing at the information level, other elements were optimizing at the cross engineering and the development activity.
Nicholas Finberg: How is the security of these devices changing now that there’s so much software and a lot of them are being connected to the internet? How does that play into MBSE?
Tim Kinman: The “connected” is the key point. So, anytime you are connected, it’s an opportunity for someone else to do negative things. Whether it’s in your internet at home, your computer, we all have situations where things have been hacked. The same thing happens to connected products. Now, you have to think about how you are connected. And there are certain protocols that are related to the signal coming to the connected device that is trying to prevent that. And there are other elements that inside of the product that you’re engineering, you have to think about requirements in the context of threats. So, we have capabilities now where when we are modeling the behavior, when we’re thinking about that product definition, we’re building in requirements that deal with threats for the connected product. And then we mitigate that through engineering actions that may have to either put certain elements in place that can prevent piracy, prevent attacks, but you start putting mitigation elements as part of your safety and quality that are directly related to how you counter the threats of the connected product.
Nicholas Finberg: So, we’ve talked quite a bit about aerospace and automotive, are there any other areas or industries that are kind of seeing this transition and realizing that it’s something they need?
Tim Kinman: About every industry now, it seems, because the blur is there. Anytime you’re doing automation, more and more people are looking for the ability to take human operational behavior and transition that to automation. So, one example that we’re thinking about, or people are actually doing, is in healthcare. Imagine that you have a medical device, maybe it’s a scanning imaging type of machine. And normally, when you have a person in there, there is a technician that is calibrating the machine to the person that’s doing a set-up to make sure that everything is done in an appropriate way. Now imagine, instead of having a technician, you have sensors, and the sensors have automated that. And I’m now able to have a move of an operational behavior to system behavior because of that transition. So, that’s one example. And there are plenty of other examples in the industrial area where we may have material transport robots, for example, in a factory. We’ve seen examples where factory automation is showing material moving around the plant, but typically, it’s a very direct line – you go along that path from point A to point B. And more and more manufacturing is looking at material delivery much the way commercial automotive is looking at autonomous vehicles; providing the sensors in the intelligence that a material delivery can move throughout a plant; recognizing obstacles but without having a rigid path for delivery but instead finding the most efficient route through the plant – that’s another example.
Nicholas Finberg: That sounds a little bit like what’s happening in the automotive industry right now. Does MBSE play a role in maybe mitigating some of that delay that’s happened with computer chips? Maybe holding stuff in stock, a little bit longer, similar to what Toyota has done?
Tim Kinman: I don’t know if this helps in just-in-time inventory. I mean, just-in-time inventory, in many ways, is a physical thing. But on the counter to that, the material delivery is now moving in a different way. So, imagine that the physical element is already there, but the software element is rapidly changing. So, one thing that MBSE is impacting is things like over-the-air updates. Right now, you see that all the time in your cell phone, or your cell phone is asking you to do an update because it’s providing either additional security or it’s providing additional features. Now, imagine that’s a vehicle or an industrial machine that says, “The physics are the same, but I detected a bug in the software.” And so, I can over-the-air update a software update to that device, same as I would to my cell phone. The same analogy would hold true. I no longer am dependent on a supply chain to deliver a fix or an update. But instead, I’m able to deliver that fix or update through an over-the-air action seamlessly to that smart product.
Nicholas Finberg: Would that include some amount of variance control, say, you have so many different models of car?
Tim Kinman: It absolutely would, and it’s even more granular than that. It would go down to the ECU, and probably would even get down to the VIN number of the vehicle. It would get down to I know that I have this software update that affects this ECU in this particular model this year. So, to get all those things lined up, you may have a VIN type of arrangement that says, “This software update goes to this class of vehicles that have all these VIN elements in common.” And then I have to then know that I’ve shipped a software update that could be like a tolerance stack where let’s say I have 200 ECUs in the vehicle, which is not uncommon, and I have a software update that on the first day goes to one ECU, and on the 10th day goes to a different ECU. And on the 30th day, a yet another ECU. It’s possible that you also have to track which update went to which vehicle on which day because you may find out that there is some interaction between those. So, it gets somewhat complicated but it’s a real situation. And Tesla is probably the best example in the vehicle space where Tesla has been able to manage that effectively in how they’re delivering over-the-air updates while also maintaining quality control over the behavior that would result thereafter. But I think, in automotive, in general, more and more commercial vehicle companies are being impressed to move to over-the-air updates, rather than the traditional service visit when you need to do those types of updates.
Nicholas Finberg: What’s the difference between systems engineering, and systems of systems engineering?
Tim Kinman: Let’s go back to the vehicle when we talked about that as a system and as a collection of subsystems – it’s contained. The vehicle is a unit. It has a life cycle. It has evolutionary development. The subsystems may be on different behaviors. But nonetheless, it is a system. Now, the system that system is connecting, as it sounds, multiple systems together. So, now imagine a vehicle operating, but it’s now also connected and communicating to a satellite. And the satellite, potentially, is giving it navigation likely if it’s autonomous. And then that satellite is connected to yet another ground station, which is gathering information. So, think about each system as that it has operational independence – it lives in it runs on its own. It has an evolutionary cycle on its own. I could have a vehicle, or a satellite, or a ground station that is evolving in its own engineering cycle – so, there’s independence.
And there’s this idea of emergent behavior that when put together, there are multiple systems that are independent but yet operating together as systems of systems, there’s a resulting behavior that results only by the combination of those systems working in concert. And in military, a similar example is very prevalent in thinking about things like radar systems that then need to connect to a ground station that could initiate a rocket or a missile response. There’s a lot of military applications of systems of systems even with all this connected to even flight vehicles or drones. But the main part of systems of systems is that we’re now taking individual systems, which they’re operationally and evolutionary independent, connecting those now together as a coordinated interaction that results in an outcome that would only be viable when connecting those systems together in a system of systems result.
Nicholas Finberg: Thanks for talking to me, Tim, today. I’ll have a lot of homework before the next episode.
Siemens Digital Industries Software is driving transformation to enable a digital enterprise where engineering, manufacturing and electronics design meet tomorrow.
Xcelerator, the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software, helps companies of all sizes create and leverage a comprehensive digital twin that provides organizations with new insights, opportunities and levels of automation to drive innovation.
For more information on Siemens Digital Industries Software products and services, visit siemens.com/software or follow us on LinkedIn, Twitter, Facebook and Instagram. Siemens Digital Industries Software – Where today meets tomorrow.
