How to Implement Model-Based Development for ISO 26262

This is the core advantage of Model-Based Development. By shifting the engineering focus from manual coding to visual modeling and simulation, teams can detect errors earlier and streamline compliance with safety standards. ISO 26262 Part 6 explicitly supports this approach, providing specific guidance for software developed using modeling tools.

If you are transitioning to this methodology or looking to refine your current workflow, this quick how-to guide will walk you through the essential steps of implementing Model-Based Development compliantly.

What is Model-Based Development in ISO 26262?

A flowchart illustrating the standard Model-Based Development workflow in an ISO 26262 context.

Model-Based Development is a methodology where graphical models serve as the primary artifact for software specification, design, and verification. Instead of interpreting text-based requirements and manually translating them into C or C++ code, engineers use modeling environments to create executable specifications.

ISO 26262 Part 6 recognizes that a model can represent different levels of abstraction. A model might serve purely as a software architectural design, or it might be detailed enough to generate production code automatically. The standard requires you to define exactly how the model is used in your development lifecycle. If the model is used to generate code, it must be treated with the same rigor as traditional source code.

Understanding this distinction is your first step toward compliance. Once you define the model's role, you can proceed to the practical steps of building a safe, verifiable system.

Step 1: Establish Strict Modeling Guidelines

Just as manual coding requires standards like MISRA C to prevent unsafe programming practices, modeling requires strict guidelines. Graphical environments offer hundreds of blocks and configuration settings, but not all of them are safe for automotive production.

To comply with ISO 26262, you must restrict the modeling environment. This involves defining a subset of allowable blocks, establishing naming conventions, and dictating how data flows through the model. Industry standards, such as the MathWorks Automotive Advisory Board guidelines, provide an excellent foundation.

Applying these guidelines ensures your models are readable, deterministic, and free from unintended behaviors. Many modeling tools include automated checkers that scan your model against these rules, providing immediate feedback to the engineer.

Key Takeaway: Never start modeling without a defined and enforced set of modeling guidelines. Automated enforcement is highly recommended for ASIL C and ASIL D projects.

Step 2: Verify Logic Early with Model-in-the-Loop (MIL)

The greatest strength of Model-Based Development is the ability to simulate your design immediately. This phase is known as Model-in-the-Loop testing. During this stage, both the controller logic and the physical environment are simulated on a standard PC.

Consider an Adaptive Cruise Control system. In a MIL environment, you can build a "plant model" that simulates the physics of your vehicle and a target vehicle ahead. You can then feed various scenarios into your controller model: the target vehicle suddenly braking, a sensor temporarily losing tracking, or another car cutting into your lane. You can observe how your controller model reacts without needing physical hardware.

ISO 26262 requires you to derive test cases from your software safety requirements. By executing these test cases in the MIL environment, you prove that the core logic is sound before any software implementation begins.

Key Takeaway: Use MIL testing to validate requirements and architecture early. Save your test vectors, as you will need them for back-to-back testing later.

Step 3: Automate with Code Generation

Once the model is fully verified in the MIL environment, the next step is translating it into source code. While manual translation is possible, automatic code generation is the industry standard for Model-Based Development.

Code generators analyze your graphical model and automatically produce highly optimized C or C++ code. This eliminates the human errors associated with manual typing, such as misplaced pointers or simple syntax mistakes. However, ISO 26262 requires you to prove that the code generator did not introduce new errors during the translation process.

This is where ISO 26262 Part 8 comes into play. You must evaluate the confidence level of your code generation tool. If you use a highly qualified tool, you can reduce the amount of manual code review required. If the tool is not qualified, you must perform rigorous reviews and testing on the generated code to ensure it perfectly matches the model's intent.

Key Takeaway: Automatic code generation reduces manual coding errors, but you must either qualify the code generator or rigorously verify its output to satisfy ISO 26262 Part 8 requirements.

Step 4: Back-to-Back Testing (SIL and PIL)

Generating code is only half the battle. You must now prove that the generated code behaves exactly like the verified model. ISO 26262 highly recommends a technique called back-to-back testing for higher Automotive Safety Integrity Levels.

This involves two specific testing phases. First is Software-in-the-Loop testing. You compile the generated code for your PC processor, run the exact same test vectors you used during MIL testing, and compare the outputs. If the MIL output and SIL output match, the code generation was successful.

Next is Processor-in-the-Loop testing. You compile the generated code using your target compiler and execute it on the actual target microcontroller (or an emulator). You run the test vectors again. This proves that the target compiler and the specific hardware architecture did not alter the intended behavior.

Key Takeaway: Back-to-back testing is the cornerstone of Model-Based Development compliance. It mathematically proves consistency between the model, the generated code, and the compiled target executable.

Step 5: Measure Structural Coverage at Both Levels

To ensure your testing is exhaustive, ISO 26262 requires structural coverage metrics. For ASIL D systems, this typically means achieving Modified Condition/Decision Coverage.

In a Model-Based Development workflow, you must measure coverage at the model level during MIL testing. This ensures your test vectors exercise every logical path within the graphical blocks. However, achieving 100 percent coverage at the model level does not guarantee 100 percent coverage at the code level.

Code generators sometimes insert defensive code or optimize logic in ways that create untestable paths in the C code. Therefore, you must also measure structural coverage during SIL or PIL testing. Any discrepancies between model coverage and code coverage must be thoroughly analyzed and documented in your safety case.

Key Takeaway: Always measure coverage at both the model level and the generated code level to ensure no unintended functionality was introduced during translation.

Essential Checklist for MBD Compliance

To help you structure your workflow, here is a practical checklist for implementing Model-Based Development in an ISO 26262 context:

• Define the Model's Role: Document whether the model is used for specification, architecture, or code generation.
• Enforce Guidelines: Implement an automated checker for standards like MAAB before any simulation begins.
• Traceability: Ensure every block or subsystem in the model links directly to a software safety requirement.
• MIL Verification: Execute requirements-based test cases on the model and achieve target model coverage.
• Tool Qualification: Determine the required Tool Confidence Level for your code generator.
• Back-to-Back Testing: Automate the comparison of MIL, SIL, and PIL test results.
• Code Coverage: Verify that the generated code meets the required structural coverage metrics (e.g., MC/DC for ASIL D).

By following this sequence, you create a robust, verifiable chain of evidence from initial requirement to final target executable.

Conclusion

Model-Based Development is a powerful enabler for automotive functional safety. By visualizing logic, simulating early, and automating code generation, you can drastically reduce the time spent chasing bugs in physical prototypes. When aligned with ISO 26262 Part 6, this methodology provides a rigorous, mathematical approach to proving software safety.

The transition from manual coding to modeling requires discipline, particularly in establishing guidelines and configuring back-to-back testing environments. However, the investment pays off through higher software quality and a much smoother safety assessment process.

Ready to master these techniques and apply them to your own projects? Dive deeper with our comprehensive Model-Based Development courses on the ISO 26262 Academy platform, or test your current understanding with our free practice exams. Equip yourself with the skills to engineer the next generation of safe automotive software.

Abbreviations & Key Definitions

• ACC - Adaptive Cruise Control, an advanced driver-assistance system that maintains a safe distance from vehicles ahead.
• ASIL - Automotive Safety Integrity Level, a risk classification scheme defined by ISO 26262.
• HIL - Hardware-in-the-Loop, a simulation technique where actual electronic control units are connected to a simulated physical environment.
• MAAB - MathWorks Automotive Advisory Board, an organization that provides widely accepted modeling guidelines for automotive software.
• MC/DC - Modified Condition/Decision Coverage, a software code coverage metric required for high-criticality systems.
• MIL - Model-in-the-Loop, testing the mathematical model of the control logic within a simulated environment before code generation.
• MISRA C - A set of software development guidelines for the C programming language developed by the Motor Industry Software Reliability Association.
• PIL - Processor-in-the-Loop, testing the compiled code on the target microcontroller hardware using simulated inputs.
• SIL - Software-in-the-Loop, testing the generated C/C++ code compiled for a desktop environment to verify it matches the model's behavior.
• TCL - Tool Confidence Level, a classification in ISO 26262 Part 8 that determines the level of qualification required for a software tool.