Model-Based Development (MBD) changed the automotive software engineering by aligning with the human cognitive process, unlike traditional C or assembler coding. MBD enables a Left-Shift approach, reducing costs by deducting issues in the early development cycle. This blog article summarizes 3 reasons for Model-Based Development Approach
Reason #1 Higher Abstraction Level
In the early days, software was written in low-level languages like Assembler, but as complexity grew, engineers sought a higher level of abstraction. That’s when C-Code emerged. Engineers wrote the C-Code and used compilers to translate the C-Code to Assembler Code. However, complexity didn’t stop there. Engineers needed something even closer to the human brain and more graphical.
Unified Modeling Language (UML) has ended the object-oriented methodology in 1997 with its superior features including reusability, configuration management, quality and architecture contributing to MBD. Model-based approaches to software development and systems engineering use technologies to include graphical modeling languages, that support system design and analysis through machine readable models.
How did the Level of Abstraction change over time?
As the MBD is a software methodology based on the V-cycle, initially users used model as a visualization method for the code. Any changes done to the code, must be carefully reflected to the model for the engineer to understand. Later, a round-trip engineering synchronization between model and code is established which needs management in both code and model levels. Later, the development became more model centric. Which means the user uses automatic code generation on model to generate the code.
Reasons #2 Modelling & Testing - Divide & Conquer
Finding Engineers in the field of Embedded Software Development, who can master the entire process is a challenging task. Model-Based Development allows for a “divide-and-conquer” approach. Domain Experts can focus on developing Models with their knowledge, whereas Software Engineers can handle the translation of those models into executable code. This separation is key for efficiency.
ISO 26262, the functional safety standard for automotive systems, supports faster development through the Divide & Conquer approach in several ways:
- Modular Development: ISO 26262 encourages hierarchal system decomposition, where safety related functions are broken into smaller, manageable components. This allows different teams to work in parallel well-defined modules, reducing bottlenecks and increasing the speed of development
- Requirements-Based Development & Reuse: ISO 26262 mandates traceability between requirements, design and testing. This structured approach allows for the reuse of certified components, significantly reducing the development time for subsequent projects.
- Independently Verifiable Components: The standard requires clear safety independence between software modules, enabling teams to develop and verify them separately. This minimizes the rework when changes are made, as long as interfaces and safety requirements are met.
The Shift to Model-Centric Development and Automatic code generation has led to structured validation stages: Model-in-the-Loop (MIL) verifies functionality at the model level, Software-in-the-Loop (SIL) tests the generated code in a simulation environment, and Processor-in-the-Loop (PIL) ensures correct execution on the target processor.
In context of MBD, ISO 26262 addresses the model based testing and Back-to-Back testing. Specifically, Section 9.4.5 recommends the Software Unit Testing carried out at the Model Level followed by Back-To-Back comparisons between Model and Object Code.
Back-To-Back tests is a common practice to ensure that the generated code behaves consistently with the high-level models. This involves comparing outputs of model simulations with those of the compiled code under identical input conditions. Although the standard doesn’t mandate back-to-back testing, this method aligns with the standard’s objectives of verifying that the software design and implementation meet the specified requirements. This blog article from Wolfgang Meincke dives deeper into whether to test purely on Model and/or code.
Reason #3 Shift-Left – Fail Early, Fail Cheap Approach
In the current rapid evolving Automotive industry, such as SDVs, traditional methods are facing significant challenges such as V-Cycle. Although they are stable and has proven significant results, the speed at which we deliver the Software is not enough to catch up with the market.
There are currently 3 challenges in the Automotive Software Development following the V-Cycle,
- Defining cases of testing is a manual and time-consuming process
- Testing typically occurs late in the development lifecycle, which limits the test coverage and makes it harder for the development teams to remedy any issues found.
- It is often a challenge to determine whether there is an exception or a failure occurring on the target system
Once such methodology to overcome these challenges is “Shift Left” in the V-Model. The concept of Left Shift is simple – Moving the test and validation phases earlier in the development lifecycle.
When shifted left, testing is prioritized from the very beginning of the software development lifecycle. Finding the defects earlier in the software can significantly decrease defect fixing costs. This is because the cost of correcting a mistake in the early phase of software development is significantly cheaper than when it is discovered later or even in production. – Fail Early, Fail Cheap.
If we have a look at the graph below, we can see that many bugs are introduced in the coding phase. In traditional testing strategies, most of them are identified closer to the release when the cost of their fixing is significantly higher than in the earlier stages.
We can see that allowing a bug to go unnoticed until the system testing phase can cost up to forty times more than catching it during coding and ten times more expensive than detecting it during unit testing. The cost becomes enormous if the bug goes undetected until the deployment stage.
Traditional testing strategies, bugs are detected in later stages of software development
On the other hand, with testing shifted left, the image looks quite different. The number of bugs introduced is still highest in the coding phase and the growth of the cost of them being fixed has the same trend. However, the grey curve indicating detection appears to be larger on the less expensive side, while smaller on the more expensive side, resulting in a considerable decrease in costs.
With the shift left testing approach, bugs are identified in earlier stages when fixing is less expensive
Conclusion
The blog article summarizes 3 reasons why Model-Based Development (MBD) is the best choice for developing Software for Automotive Embedded Systems. It highlights, how MBD’s advantages in enabling fast iterations in an agile development process using the Divide-and-Conquer approach. The article also summarizes on how MBD along with Shift-Left in the V-Cycle can save costs for the development’s lifecycle.
