Shifting Left Using Model-Based Engineering

As heterogenous integration increases design complexity and forces engineers out of long-standing silos, model-based systems engineering (MBSE) is becoming essential for improving quality and reducing failures in the field.

While it may seem like a new buzzword, MBSE’s principles date back to the 1990s. In essence, it’s a process of building models that enable early decisions, which pays off in fewer fixes down the line. Commonly applied in automotive and aerospace development, it is beginning to spread into other areas as its value becomes more widely recognized, and as advanced chips increasingly are deployed in safety- and mission-critical applications. But despite its decades-long use, there are still many bespoke techniques, and more development is needed to automate MBSE processes.

“Before model-based systems and requirements engineering, systems were specified in an informal and ad-hoc way, using natural language and spread sheets,” said Tim Kogel, principal engineer at Synopsys. “This informal approach to capturing requirements and specifications does not scale with the complexity of today’s systems. Formal methods are needed, with tool support, to check requirements and systems specifications for correctness and consistency. Also, government regulations demand traceability of requirements along the product lifecycle for safety-critical applications like automotive and aerospace, from specification to refinement, implementation, integration, testing, and maintenance.”

Fig. 1: An MBSE environment combined with a virtual prototype for automotive E/E architectural analysis. Source: Synopsys

This is how MBSE is being used for development in the automotive and aerospace/defense sectors to address complexity and criticality. “The primary use cases are in transportation, whether it be aerospace and defense, automotive, or just mobility in general — anything where there is a risk to life or infrastructure,” said Neil Hand, director of marketing for the IC segment at Siemens EDA. “If there is a kinetic mass being moved, you want to make sure that kinetic energy is going to work properly.”

For any modeling, the scope of development matters, and use models drive requirements.

“At the scope of simulating an airplane, the industry calls it MBSE,” said Frank Schirrmeister, vice president of solutions & business development at Arteris. “Still, simulation fidelity is much lower from a semiconductor point of view, as the details of a chip, for instance, will be abstracted away as functions. The use model here is early functional integration and often capture of requirements.”

Put simply, MBSE provides a basic framework for aerospace and other designers. “For example, you create early models of the airplane, of how the different system functions work together, and you refine from there,” Schirrmeister said. “That’s the classic V diagram, where you go from the early analysis, refine, and add more detail. Eventually, you arrive at the implementation of it for hardware/software, and then you go up the V diagram on the other side, where you do the integration and validation.”

Nevertheless, it still may be an unfamiliar approach for many designers, especially those outside of transportation.

“Most designers work off of defined specifications, not functional requirements,” said Chris Mueth, director of new markets management at Keysight. “The advantage to MBSE is to better collaborate, re-use IP, and make better product through the insights gained in the MBSE process. In the commercial sector, end products that are systems in themselves and include a complex interdependent functionality, like a smart phone, would be good candidates for MBSE.”

Best practices
Surprisingly, even after 30 years, there aren’t best practices in MBSE, at least in the sense of a list of protocols to follow. Rather, designers should think in terms of best approaches, and start from a basic question. 

“The whole shift left process always involves models,” Schirrmeister said. “Fundamentally, what’s the scope of the system you’re modeling, and what’s the level of fidelity you’re dealing with? The best practice I’ve seen is the creation of hybrid models. The weakness of a very abstract model-based systems engineering environment is its accuracy. To balance that, you could replace the component that you want to develop in more detail. For example, as you add more accuracy, software-based simulation may become very slow. To understand the hardware component of a chip, you could place it in an emulator. This would give you the ability to take the rest of the model-based environment as a test bench and have your specific environment modeled more accurately. Therefore, the pragmatic approach is a mix of abstraction levels, and that’s what we’ve seen in the sub-flows as well.”

Synopsys’ Kogel boils best practices down to three approaches:

• Standard language: “SysML has emerged as the most popular language for MBSE,” he said. “SysML v2 is on the final stretch of ratification and will enable further formal checking and automation, thanks to stricter formal syntax and textual notation.”
• Standards-based tooling: “There are several commercial SysML-based tools which provide capabilities like traceability, consistency checking, change management, documentation generation, life-cycle collaboration, and other capabilities.”
• Structured methodology to manage system complexity. “For example, RFLP (requirements, functional, logical, physical) is deployed in the automotive domain as a step-by-step refinement process.”

Additionally, Siemens’ Hand recommended not trying to build an ad hoc infrastructure that is unconnected. “It’s expensive and time-consuming. Look at the problem of what are you really trying to solve and then build the tooling around those capture points to make sure you have that visibility into the system. It’s basically just building the V.”

Pitfalls
MBSE is not a perfect solution, however, and those who adopt it need to be aware of pitfalls. Schirrmeister said the challenge with MBSE is that it has been almost impossible to connect the MBSE models into the more detailed development flows of the subsystems. “For semiconductor design, the MBSE models at best would give you some data for the test benches, but they would not become a model that you can directly refine and then feed into the implementation flow. That said, it’s useful to help you avoid decisions that you would otherwise find too late in the implementation flow.”

The catch is that a model, by definition, always keeps implementation details away from the user as it tries to reach the abstraction that allows the highest speed of execution. “Because of that, you always need to understand what questions your model is even able to answer,” he said. “For instance, what if you’re trying to ask very detailed performance questions, like the impact of pipeline performance in a processor. It’s possible the model hasn’t modeled that yet, and you may not even be aware that the model doesn’t give you that fidelity, because the model comes from somebody else. As a result, you may arrive at completely wrong conclusions for your project.”

It also takes a commitment to accepting more overhead up front, in the belief that the extra time and effort will be rewarded by catching problems before they appear later in design or even in implementation. However, as with all modeling, there’s a feedback loop, and designers must not neglect updating. Keeping models in sync is important for accuracy.

“The focus of MBSE is on the formalized capture of a system specification and checking it for correctness and consistency,” said Kogel. “SysML v2 will enable users to derive static properties from the specification — for example, the BOM or the total weight. MBSE does not prevent you from defining a system that is over- or under-dimensioned, or fulfill non-functional requirements like performance or power consumption, which depend on dynamic system behavior like external events and user interaction.”

One remedy to address these issues could be to complement MBSE with a virtual prototype for architecture analysis to enable simulation-based quantitative trade-off analysis and design space exploration. The outcome is a validated system specification, with a much higher confidence that the final system implementation will also meet non-functional requirements.

An MBSE approach should also be complemented with tooling and methodology for automated testing, along with electronic digital twins for accelerated bring-up and testing of functional requirements. “Modern testing tools support the importance of requirement specifications, which can then be translated step-by-step into executable test sequences,” said Kogel. “These tests should be seamlessly executed along the product lifecycle, starting with the initial algorithmic models (model-in-the-loop), via early software implementations running on electronic digital twins (software-in-the-loop and virtual hardware-in-the-loop), to the final hardware implementation.”

Tools and automation
Tools for MBSE, in the sense of available modeling languages, have existed for decades. In the sense of automating processes, they are a goal, but not yet a reality.

“When you look at commercial emulation tools, they all have the capability to connect in a hybrid environment,” said Schirrmeister. “In some cases, you see people connecting MATLAB to achieve more accurate models and build these hybrid systems. That’s a pragmatic way out for connecting MBSE, which in itself often is a higher-level model disconnected from the implementation flows of the sub-components. These hybrids now bring you the ability to connect the different flows. For certain use models, that works well. For example, the software-use model where you have processor models for the processor in the system, but you still need to more accurately model your graphics sub-system. In that case, you can combine a system model with the more accurate emulation models representing the hardware in a fair amount of detail, and then simulate them together.”

Indeed, there is still a lot of ad hoc work and a lot of gaps, Hand said. “It’s a problem, especially as you tie into semiconductor engineering, which is why it is a fairly expensive jump to make. SysML v2 is going to allow us to do a lot more automation, but there’s a gap in the tooling today, although there are gaps that we’re already filling. We’re working with customers where we’re able to trace verification status in the right multi-domain, whether it’s PCB, whether it’s mechanical, whether it’s semiconductor, to bring together verification capture points, and thread that verification so the systems designer can see the whole view. So tools exist, but there’s a lot more that is needed, especially as we try to reduce the cost and reduce barriers so it can be for everyone, not just designers dealing with kinetic mass.”

One option being considered are properly trained LLMs that could lead to automatic generation of models, leaving both Excel files and paper diagrams in the past.

Conclusion
As companies strive for automation, tooling for MBSE likely will evolve, along with a more ordered set of best practices. The importance of MBSE as an approach, however, is unlikely to change.

“Since the late ’90s, we have been trying to apply UML, and later SysML, for SoC design, as a higher level of abstraction. MBSE was, is, and always will be the technology of the future. It was a topic in the ’90s, and because complexity is constantly rising, it still is a topic,” said Schirrmeister.

MBSE is an especially hot topic now because modern systems are defined by their algorithms, which impact every aspect of the product. “For example, you’ve got a car, you’ve got a certain set of requirements which involve self-driving, such as range, and everything else that is going to be impacted,” Hand noted. “The battery technology is going to be impacted by the software algorithms impacting that battery. Those batteries are all part of the mechanical structure of the car. You can draw a direct line from a piece of software or an electronics choice to impacting the overall system’s physical design. No longer can you abstract electronics to a second-class citizen that’s abstracted away in traditional model-based systems engineering. You’ve got to start looking at electronics in the context of the rest of the system, and look at that system as a whole.”

Thus, the industry finds itself at a turning point. “We’re at the beginning of the true integration of model-based engineering with electronics co-design, which will deliver the next level of optimization and productivity for the semiconductor-based solutions,” Hand added. “Today, model-based systems engineering can largely ignore the function of the semiconductor and still work. If you think about hierarchy, electronics and software generally live on leaf nodes. Whereas if you look at where new systems are heading, their functionality is no longer leaf, it’s all sprinkled throughout. As a result, the whole systems methodology needs to be different.”

And while the principles of MBSE will remain a driving force, methods could potentially change enough to require a new buzzword.