Requirements-driven design with MBSE
Model-based systems engineering, or MBSE, is an amazing tool to have at your disposal for complex products as we learned in my first discussion with Tim Kinman. And in that discussion we also outlined a few pillars that support the methodology in creating the cars, aircraft and other products of tomorrow as they become more integrated. In our second episode of Model Based Matters we were joined by Tony Komar and Ryan Wilkins to understand how products are defined in the earliest stages of development and how these decisions guide downstream operations. Today I am talking about how requirements-driven design is enabled by MBSE.
One of the major reasons companies are adopting model-based systems engineering for their complex product development is that the traditional methods for orchestrating these multi-domain projects do not adequately proliferate the requirements of the initial concept. That leads to tangential work based on outdated design, it leads to delays in delivery, and it leads to lost profits. One might ask, don’t companies already work from a set of requirements to build the right car for example? The simple answer is yes, but without communicating the interconnectedness of these requirements from a single source of truth, errors are bound to occur. These requirements can take a variety of forms from customer needs – high fuel efficiency, a robust infotainment system, or push-button start – to more regulatory requirements around safety of emissions standards.
It is important to understand that these requirements contain information for many different teams about what they need to deliver. A requirement around push-button start will include mechanical information like the size of the button, where the wiring for it will be routed, the interfaces once the signal reaches the motor or other relevant systems. The system will also need to understand the states of other systems through software connections. Is the brake pedal pressed? Are coolant fluids free to flow? Is the key present? The interconnectedness is why MBSE is so valuable for requirements-driven design, it enables rapid and organic resolution of these requirements in the relevant domains. Traditionally these processes would be done with a waterfall approach where designs are handed off when completed by a given group, but by working from a unified set of requirements domains can work in parallel and reduce development times similar to the AGILE workflow for software development.
Defining the requirements in greater detail often leads into the creation of features, though depending on the project and organization these could be within the initial requirements of the system. A feature could be emergency braking for a vehicle or the push-button start example, what ever it might be the goal is to define executable systems for development. Teams work from the requirements to design features and integrate all of the systems they encompass. Emergency braking should pull in the adaptive braking system that has been previously defined instead of creating the feature again from scratch. Not only does reuse save time in development, it reduces the overall complexity of the product while in use, there are fewer lines of code to execute making reactions far faster and the entire system will be easier to validate because it relies on a previously tested system.
Another important aspect in using MBSE methods for requirements-driven design is that these definitions and requirements of the system can be shared with suppliers earlier in the development cycle. It is unlikely any complex product will be manufactured entirely in-house from raw materials; the global supply chain has become a staple of modern manufacturing. But communicating deliverables early and accurately reduces the time to market tremendously. In a car for example, a supplier could be tasked with delivering one of the defined features, it could be lidar sensing or the infotainment system. With that delivery request, the original equipment manufacturer needs to know that the components will not only connect mechanically but must be able to communicate through software. The practice of using a supplier for a feature is becoming more common and providing them accurate integration information prevents expensive reworks and delays.
These are only some of the highlights from my discussion with Tim and our guests Tony and Ryan, and for the full story of what MBSE means for requirements-driven design I would highly recommend listening to episode two of the podcast. If you are more inclined to read the discussion, the transcript is also available in its entirety. Episode three is out next so make sure your get subscribed on your favorite podcast platform – Tim and I talk about how teams work from these requirements to create complex products. We are joined by three experts from a variety of industry backgrounds, it was a great conversation, and I would highly recommend taking a listen.
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
