Feature-based engineering with MBSE
Model-based systems engineering (MBSE) encompasses so many different processes in the world of system development that it can be hard to explain what it truly entails. It can be something completely different between companies and even internal departments because of it’s reach. But the third episode of Model Based Matters with Tim Kinman and me really made the value for product development click. In the episode, we’re joined by Piyush Kakare, the Global Director for Automotive Industry Solutions; Michael Baloh, a Control Engineer; and Brad McCaskey, a Portfolio Executive. All of them work at Siemens and have their hands in forming the MBSE solution. The variety of experience was invaluable in discussing the session’s topic – feature-based engineering – let’s dive in.
Taking a step along the MBSE path from the Product Definition where we began to define system requirements and what problems a new product needs to solve; we need to understand the desired features in a vehicle. Historically features for the automobile have been mechanical in function and implementation, think higher speeds, better braking, more comfortable seats and even the number of cupholder. But this has been changing for a while, computer chips have been introduced to optimize vehicle performance, anti-lock braking systems rely on electrical coding to ensure safety, and more recently cars have adopted more complex driver aids like automatic braking and parking assist. All of these are features, one of the prevalent right now is a switch to push-button start. Behind all of these ideas however is a great deal of complexity that must be solved in a variety of domains to get it right.
Push-button start for instance sounds like a very simple thing to implement, instead of an ignition key there’s a button, one might argue the action itself is simpler. But under the surface of that button is a web of interdependencies. The electrical signal from the button needs to be processed as an input by one of the vehicle’s electronic control units (ECUs), which in turn makes calls to a variety of other systems – are the brakes engaged? Is the key present to initiate the start? What temperature is the engine at, and will the coolant be able to flow properly? All of these responses are important to ignition and require understand from a variety of engineering departments to design it. Electrical engineers craft the electrical harnesses to route all the signals produced by the ECUs that were developed by the electronics and software engineers, and all of that will eventually interact with the mechanical systems in the vehicle.
Feature-based engineering as a part of MBSE encourages these different groups to work in parallel and to organically communicate on what needs to be developed to reach the feature functionality. From the product definition engineering groups will have a limited architecture to work from and they will refine the design to meet their needs. This is in turn portrayed in the digital twin where other groups can see and understand the interconnects that are relevant to their work. Returning to the push-button start example, when a software engineer is creating the code that runs these processes, they need to know how to call information from the ECUs. And if a variable like whether the brake is activated by a different feature in the system, it should be possible to reuse it instead of requiring a new system to deliver redundant information. This is the value of a single source of truth and MBSE – reuse. It enables much more rapid development, and it reduces some of the complexity of the systems at hand.
All of this runs on a what is essentially a system of contracts between the system architecture and the individual systems in a vehicle. The feature is the contract of what needs to be available and the specifics of how it is achieved in development are the fine print of the document. All relevant parties need to sign off that the contract works for them to deliver the right product. And making all of this digital means that groups can know exactly when a change breaks the contract. It could be that a connector for a wiring harness is too large to fit through the opening that was creating in the vehicle body or the time it should take for a system to receive a signal before it errors out. There is so much to feature-based engineering for model-based systems engineering and I would highly recommend listening to the episode. And if you haven’t been following along our first episode covers MBSE at a high level – what is it and how does it improve complex development – and episode two involves the creation of the system architecture – what’s in it and what role does it play in development?
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
