The application of Model-Based Systems Engineering – the modern solution for industrial complexity and sustainability – ep. 10 Transcript
In this tenth episode of the Model-Based Matters podcast series our experts discuss the modern solution for industrial complexity and sustainability.
Nick Finberg, Technical Writer for Thought Leadership at Siemens, is once again interviewing Tim Kinman, vice president of Trending Solutions and Global Program Lead for Systems Digitalization at Siemens Digital Industries Software, providing his expertise on this subject. Enjoy reading the podcast.
Check out the transcript (below) or listen to the audio podcast.
Read the transcript
Nick: Welcome to Model-Based Matters, Siemens software’s top spot for discussions on everything, model-based systems engineering. I’m Nick Finberg and I’m joined again by Tim Kinman to talk about what MBSE means here at Siemens and some of the trends and drivers cropping up in the different industries we support. Hey Tim, it’s been a little while since we sat in and talked. Hope you’re doing well.
Tim: Yeah, I am doing well, and it has been a while, so good that we’re back together.
Nick: So, for our listeners who are just joining us for the first time, do you mind giving a little bit of background on yourself and what you do here at Siemens?
Tim: Yeah, thanks, Nick. I’m Tim Kinman and I run a program here within our Siemens software division heading up our MBSE strategy. So, I’m really working toward helping customers address smart connected products and the influx and the complexity of the products around software and systems interoperability, system interaction. And a lot of this is what we refer to as shift left, moving further upstream in the decision making of system engineering. So that’s hope where our discussion leads to today.
Nick: Awesome, Tim. So, in our last series we talked to quite a few different industry experts around automotive, electronics, and even heavy industry. And in almost every discussion the trends of why MBSE was important really came down to increased complexity in the industry. From your meetings with customers, is that still the case, but maybe more importantly, is this the case across more industries than what we’ve covered so far?
Tim: It is absolutely still the case and going faster. So, in the way that our customers are being challenged, there are a lot of global trends that are driving and sometimes forcing them to take action, whether it is the circular economy, all the movement towards sustainability and how to build more effective, sustainable products, it is related to experience driven products where more and more the product operational needs are being driven by software in product. And that’s not just automotive, but across many, many industries. And customers are increasingly being asked to and improve their time to market and product quality at a much, much faster pace. So, the ability to get product insight from active products and bring that back into their engineering activity is also I think a compelling trend that’s driving their decisions and their actions.
Nick: You mentioned sustainability and circular economies. Is that kind of a growing trend within the customers you’re talking about?
Tim: Well, it is.
Nick: Okay. So, in our previous discussion, we’re trying to measure absolutely everything within the life cycle of a product, from early system design, all the way to how does that product go into the next product. So now for a company already dealing with complex products, products like aircraft or automobiles, even electronics, it’s very likely that people have dealt with systems engineering to some extent before and maybe even model-based systems engineering. But for those maybe not in the know about what MBSE is today, could you explain some of the nuances between the two? What’s changed to warrant talking about it again?
Tim: Yeah, so I think historically a lot of customers already doing model-based design using models to deal with the geometric representation. Customers have moved further into model-based engineering, connecting mechanical and electrical from a more still of the physical aspects of engineering and furthering that is where we move into MBSE is where we’re now thinking about the product as a total system that encompasses the software elements representing the operational.
We must think about the safety not just of failure, but the safety of usage, which again brings software into that. And what’s happened as you’ve seen products become more complex, we’ve seen, and everyone has their example of failures in the field, which could be catastrophic at times depending on what type of product it is. And many times, those failures have resulted from poor requirements that led to poor engineering decisions or it’s been the result of interfaces between components in the system that had to talk to one another and those components did not have a proper definition of what that exchange should be, which also would lead to either a hazard based result or a failure based result.
Nick: Okay. I think I’m getting it, but do you have maybe a simplistic example from a customer that you were talking to where this kind of thing happen, and they were trying to get rid of it from their process?
Tim: We have other situations, could be an automotive where things that are sensor based, software based are leading to breaking issues. So, we’ve also had situations where you might see an example where a vehicle had a failure and it was related to a sensor to software to the actuation of the brakes, all that was traced back to a requirement issue, which is analogous or a long lines of system engineering as well. So, whether it’s going from a requirements traceability to the system result or a detailed system decomposition or system representation of the interfaces in the components. But there are quite a few examples out there that are representing failures of product that are rooted or trace back to an issue that would’ve otherwise been found in a model-based system engineering process.
Nick: Okay. So, it sounds like identifying the needs of a project is kind of the first step in creating this more effective map for development, but how might a business or an engineering group begin to apply that information? How do you take what you have from entering requirements of, okay, this software system needs to be able to last the length of this car, or what are the kind of colors that customers are looking for for this product? How do you integrate that stuff early on?
Tim: Well, that’s my big question, and I think that’s the fundamental of many of our customers is how do I, and the reference we use shift left, how do I take my physical representation? And it’s typically a progression of how they test. It comes back to how they’re testing their product to meet the specification. And so there’s one element of how do I simulate my product in a virtual world that satisfies the requirements as specified?
And then you start shifting further left and you say, “Okay, well then how do I ensure that I have architected in my product in the most effective way to meet that specification?” And so we start getting into more of the extensions of standard product architecture, EBOM type approach, where we’re now connected into system elements of functional non-physical representations. That’s where the architecture would come together. And even further than that, you start challenging have I specified my product correctly?
And so earlier in the MBSE process, we have approaches where you can challenge the requirements and test those requirements to confirm that the requirements are allocated, that the requirements are good. And often the way you do that is you really address the requirements in a behavioral model virtually, and you have some traceability that you can account for those requirements against functions that are to be performed by the product. And then you have additional ways that you can then test and verify those functions to the system elements. And so all of this progression is what customers are trying to do.
And ideally one would accelerate what I just said and I’ve shifted all the way left, and that’s where I’m really verifying that I have good requirements that are based in a functional and a system definition. And that becomes the descriptive product that I then take into engineering. And I think this is where all of our customers are really coming from many times a physical world where they’ve kind of ingrained the design, engineering, and the manufacturing. And now what they’re doing is connecting earlier so that they can understand the product before they begin to build.
Nick: Okay. So maybe coming back to our quick discussion about sustainability or circular economies, this section, this establishing of the system architecture and then evaluating it as you progress through development would maybe be where is this material coming from that I’m manufacturing with? What are the associated CO2 emissions or any other sustainability concerns? Is that kind of what you’re talking about? And then you would be able to then balance maybe those against another supplier that you have relationships with that maybe is not as far away, but their process maybe takes a little bit more energy. Is that kind of what you’re getting at?
Tim: Well, it could be competing requirements. So, if we think about specifying an autonomous vehicle, and it doesn’t need to be a commercial car, it could be a manufacturer material robot, it could be a unmanned vertical take of landing kind of delivery. But yeah, it could be anything like that. And so what you’re dealing with is you could have a requirement that says, “I have a requirement that my CO2 footprint cannot be more than X amount per hour or measured in some unit.”
But you may also have a competing requirement that says, “But I must be able to have a performance characteristic of horsepower, or I must be able to have a particular delivery payload element that is competing with my CO2 requirement.” And so the system’s activity that we’re talking about allows me to evaluate different system architectures where I may have competing requirements. It allows me to think about variations or different options of that system architecture that better balances the various requirements where those requirements could be sustainability requirements.
That could be hazardous material, it could be CO2 emission, it could be, I don’t know, it could be distance, there could be other elements of that, but I could also be balancing against safety requirements. I could also be balancing against other non-functional requirements as well as functional requirements that have more of a human operational element. So it allows you to, in a virtual environment, when I’m thinking about system engineering, it allows me to bring a lot of the requirements elements that are functional and nonfunctional, that are also performance related together and think through different system architecture variations and decisions before I start committing into the engineering of that end product.
Nick: So, I get that this is super helpful to understand some of the foundational parts of a product and even some of the verification workflows that you’re going to be using later on. Does this also set up the communication relationships early in the process? How do you interact with the different groups making stuff, if it’s software doing something for an autonomous vehicle, how do you make sure that they’re talking with someone out of maybe the breaking systems division?
Tim: Right, yes. And it does because when we’re thinking about products, specifically products that are being driven by software for operational execution, you need to think about that decomposition between which one of the product functions are going to be satisfied by a person or persons, and which one of those functional elements are going to be satisfied by the system, which at that level is likely going to be something that is a combination of software and hardware. And so this allows me to do that decomposition. And in connection with that, I can also think about the interfaces that span those. So it could be a sensor where its signal is sent across a network and the network interprets that signal through either a distributed computing or a centralized computing model, and then the computer then sends the signal to the actuator that triggers the event.
And so, all of us happening at a very, very high rate, meaning like microsecond or faster because especially in a safety scenario, if the sensor detects something in obstacle, then you want to hit the breaking right away was that shows you from sensor to network to computing device to actuator to physically something happen has to be very, very rapid. And so, there are interfaces that are across one of those boundaries I just described that I need an interface definition of basically a contract between these system elements of how they work together. And all that gets defined and detailed as you’re thinking about that system architecture. So the system architecture at the beginning could be very conceptual core grain, but as I start detailing out the system design, that interface contract that I’m describing would have much, much more detail about maybe not just the inputs and outputs across that boundary, but even down to the technology that might be used to transact that interface.
Nick: If you’re writing down even the technologies, would that be more of it’s happening later in the development cycle and each of these is already made and constructed? Or could it even be, I already made this in the past from a different product, let’s use it again and put it here.
Tim: It could be either, right. So that’s a good point about reuse because ideally we’d like to be able to leverage our digital twin at our next product phase. And so in the product that I’m interested in, I may be looking for a starting point that is related to an existing product. It could be a next gen model of one product, or it could be a certain set of system elements from a completely different product. So the element of reuse coming from the digital twin is yes, that’s a key element, and if I have an ability to have modularized system elements with all of their representations contained, then I should be able to plug that into other product variations using this interface definition.
Nick: Okay, very cool. We’re kind of talking about this in the abstract is what does this process look like for someone trying to apply MBSE methodology? So for an engineer working on a project using MBSE, what might that look like from an authoring and contract perspective? Is there a specific tool that you’re using?
Tim: Well, I think system engineering and the way that the system engineering teams are working, they’re all about descriptive modeling, and that’s what the SysML activity is about. It’s about being able to describe what you want the product to do and then verify it in a virtual world that it can accomplish that before I commit to the engineering. So, a typical system engineering person would be using some type of requirements authoring, they want to capture requirements in a level of detail that could be measured and test it against. They then want to think about how those requirements can get satisfied functionally, what are the functions that need to be represented for those requirements to be addressed. And then you then start thinking about, okay, with a functional definition, how might the product look? And so you start thinking about a system model that starts representing a early view of the product as a decomposed set of system elements that would be used to achieve that.
And even that decomposition could be a combination of hardware and software components that would work together. And in that early architecture, you may be also thinking about basic interfaces that begin with a relationship type of interface. From there, then you start using additional tools, additional applications that you verify the operational, you verify that the allocation of those requirements of the behavior are being satisfied, even going down to safety elements, using that same system architecture to think about safety in the context of the causal analysis that could lead to incorrect hazard or incorrect usage leading to hazard.
Or you could be thinking about how do I verify that from a failure that says, what happens if I have a component of failure? What’s the impact to the rest of my system? All of those things are in the span of work that a system engineer and colleagues, because at this point it could be other people from engineering disciplines working in that system definition phase. That’s what they would be working toward. And then ideally, you down select to the concept that you think is the most viable meeting your business criteria with the right balance to your requirements. And then that’s what then gets moved into the next level of detail for product engineering.
Nick: That is a really good example of what this process looks like and it will dovetail nicely into our next discussion, but we are hitting the end of our time for today. Next episode we will pick back up on the role of SysML in the future of model-based systems engineering practices. Tim, I look forward to talking with you again shortly and to the audience I hope this conversation is just as interesting for you. We’ll be back soon, and we hope you can join us again.
Siemens Digital Industries Software is driving transformation to enable a digital enterprise where engineering, manufacturing and electronics design meet tomorrow.
Siemens 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
