Model-Based Development for ISO 26262
12 chapters Most production ECU code is no longer hand-written; a generator emits it from a Simulink or TargetLink model. This page walks the full journey from block diagrams to production C, through modeling guidelines, the MIL/SIL/PIL/HIL verification ladder, back-to-back testing, and the tool confidence argument that makes an assessor accept generated code.
How You Learn
Video and text stay in sync. As you scroll through the chapter, the video jumps to the matching explanation automatically.
Learning Objectives
Build a compliant model toolchain
Wire function model, implementation model and generator so every stage stays traceable and MISRA-aligned.
Apply MAAB and MISRA modeling guidelines
Constrain Simulink and Stateflow so the generator emits readable, analyzable, safe production code.
Climb the xIL verification ladder
Decide what to prove at MIL, SIL, PIL and HIL and where timing and hardware effects first matter.
Run back-to-back model-versus-code tests
Set tolerance bands and reuse stimuli to prove the generator preserved the model's behavior.
Chapters
From Hand-Written Code to Models
Why safety-critical control functions moved from hand-written C to Simulink and Stateflow models, and what changes when a diagram becomes the source of truth.
The Toolchain: Models, Generators and Artifacts
The full chain of models, code generators such as Embedded Coder and TargetLink, and the artifacts each stage produces and must keep traceable.
What ISO 26262 Says About MBD
How Part 6 treats model-based design, back-to-back testing, coverage and tool qualification for generated software.
Modeling Guidelines
How MAAB and MISRA guidelines constrain a model so that it generates readable, analyzable, safe production code.
From Function Model to Implementation Model
Refining an idealized function model into a fixed-point, target-ready implementation model without changing the intended behavior.
Production Code Generation
How the generator emits MISRA-compliant production C, and what configuration and review the output still requires.
The xIL Verification Ladder
Model-in-the-loop, software-in-the-loop, processor-in-the-loop and hardware-in-the-loop as an escalating ladder that each answer a different question.
Back-to-Back Testing
Comparing model and generated code on identical stimuli to prove the generator did not change behavior, and deciding tolerances.
Coverage on Model and Code
Why model coverage and code coverage are different measurements, and how MC/DC ties them together for higher ASIL.
Static Analysis and Formal Methods
Applying static analysis and formal tools such as Polyspace and design verifiers to prove absence of run-time errors in generated code.
Tool Confidence for Code Generators
The ISO 26262-8 Clause 11 argument that determines TCL1 to TCL3 and whether the generator itself must be qualified.
Worked Example, Pitfalls & Assessor Questions
An ASIL C torque limiter carried through the full MBD chain, with the pitfalls and assessor questions that trip real projects.
Diagrams & Visuals
MBD Toolchain Flow
Traces the chain from function model through implementation model and code generator to production C and object code.
The xIL Verification Ladder
Escalates from MIL to SIL to PIL to HIL, showing what new question each rung answers about the software.
Back-to-Back Test Harness
Feeds identical stimuli to model and generated code and compares outputs to prove behavioral equivalence.
Model vs Code Coverage Map
Contrasts model coverage against generated-code coverage and locates where MC/DC gaps appear.
Tool Confidence Decision Path
Routes a code generator through tool impact and error detection to land on TCL1, TCL2 or TCL3.
PIL Timing & Equivalence View
Shows numerical equivalence and target timing effects surfacing once code runs on the real processor.
Autocoding an ASIL C Torque Limiter
An ASIL C torque limiter caps motor torque to the driver request plus margin and drops to a degradation state on implausible demand, modeled as arbitration logic and a Stateflow state machine. TargetLink generates the unit, which is then proven equivalent through MIL, SIL and PIL back-to-back testing with exact-match states and flags and full MC/DC on the arbitration logic.
- Function model captures torque cap arbitration and a Stateflow degradation state machine
- ASIL C attribute carried from the requirements tool into the implementation model
- TargetLink generates the production unit with project-blessed MISRA settings
- MIL, SIL and PIL back-to-back runs compare torque outputs on identical stimuli
- Exact match on states and flags, with MC/DC on the arbitration logic complete
- Generator tool confidence argued and the residual review items closed out
Verification Ledger: ASIL C Torque Limiter
Master Model-Based Development for ISO 26262
Work the full chain from Simulink model to qualified production code, through modeling guidelines, the xIL ladder, back-to-back testing and the tool confidence argument.
Start Learning Now