Title: Model-Based Development | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/model-based-development Description: Your ASIL D torque limiter was never typed by a human; a code generator produced it from a Simulink model. --- Concept guide · ISO 26262-6 · 12 chapters # Model-Based Development for ISO 26262 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. 12 Chapters 4 xIL Simulation Stages 3 Tool Confidence Levels 2 Coverage Domains Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fmodel-based-development&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **From Hand-Written Code to Models** 2. 02 **The Toolchain: Models, Generators and Artifacts** 3. 03 **What ISO 26262 Says About MBD** 4. 04 **Modeling Guidelines** 5. 05 **From Function Model to Implementation Model** The short version ## Quick answers What is model-based development in ISO 26262? Model-based development (MBD) is the practice of specifying software behavior as executable models - typically Simulink or TargetLink block diagrams and state machines - and generating production code from them instead of hand-writing it. ISO 26262-6 explicitly accommodates this: models can serve as the design representation, simulation becomes a verification method, and code generation replaces manual implementation. The safety obligations do not disappear, they relocate - into modeling guidelines, model-level verification, back-to-back testing between model and code, and a tool confidence argument for the generator per ISO 26262-8 Clause 11. Does automatically generated code still need MISRA checking and review? It depends on the confidence you can claim in the generator. If the code generator is qualified with an appropriate tool confidence level per ISO 26262-8 Clause 11, verification effort can shift to the model level, and per-line manual review of the generated C is not required. In practice, projects still run MISRA and static analysis on generated code with a project-blessed configuration, both as a safety net and because integration code around the generated unit is hand-written anyway. What the tool confidence argument buys you is relief from duplicating model-level verification at code level - not a blanket waiver. Keep going, free - [Article · 8 min read How to Implement Model-Based Development for ISO 26262](https://iso26262.academy/blog/implement-model-based-development-iso-26262) - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262, Part 6 ## Why it pays for itself ### Walk the full MBD chain Follow the journey from Simulink or TargetLink block diagrams through modeling guidelines and implementation models to generated production C, and learn exactly where ISO 26262 attaches obligations along the way. ### Climb the xIL verification ladder Understand what MIL, SIL, PIL, and HIL each prove, how back-to-back testing demonstrates model-to-code equivalence, and which coverage evidence is needed on the model versus on the generated code. ### Defend generated code to an assessor Build the tool confidence argument for your code generator - classification, qualification, and the residual verification you still owe - so autocoded ASIL software gets accepted rather than re-reviewed by hand. After the course ## What you’ll be able to do ### 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. ### Interpret model and code coverage Separate the two coverage measurements and justify MC/DC gaps at ASIL C and D. ### Argue tool confidence for a generator Classify a code generator into TCL1 to TCL3 and decide when it must be qualified. The curriculum · 12 chapters ## Chapter by chapter 1. 01 **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. - Block diagrams and state machines as executable specifications - Simulink, Stateflow and TargetLink-style workflows - What autocoding shifts, and what it does not remove 2. 02 **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. - Function model, implementation model, generated code - Embedded Coder and TargetLink generator options - Artifact traceability from requirement to object code 3. 03 **What ISO 26262 Says About MBD** How Part 6 treats model-based design, back-to-back testing, coverage and tool qualification for generated software. - ISO 26262-6 objectives mapped onto MBD - Where the standard demands back-to-back and coverage - ASIL scaling of verification rigor 4. 04 **Modeling Guidelines** How MAAB and MISRA guidelines constrain a model so that it generates readable, analyzable, safe production code. - MAAB style rules for Simulink and Stateflow - MISRA modeling and MISRA C alignment - Automated guideline checking in the toolchain 5. 05 **From Function Model to Implementation Model** Refining an idealized function model into a fixed-point, target-ready implementation model without changing the intended behavior. - Fixed-point scaling and data typing - TargetLink block replacement and code interface - Preserving behavior through the refinement 6. 06 **Production Code Generation** How the generator emits MISRA-compliant production C, and what configuration and review the output still requires. - Generator settings that drive MISRA-C output - Reading and reviewing the generated file - Traceability comments linking code back to blocks 7. 07 **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. - MIL, SIL, PIL and HIL, and what each proves - Numerical equivalence versus target behavior - Where timing and hardware effects first appear 8. 08 **Back-to-Back Testing** Comparing model and generated code on identical stimuli to prove the generator did not change behavior, and deciding tolerances. - Model-versus-code equivalence on shared stimuli - Exact match versus fixed-point tolerance bands - Stimuli reuse across MIL, SIL and PIL 9. 09 **Coverage on Model and Code** Why model coverage and code coverage are different measurements, and how MC/DC ties them together for higher ASIL. - Model coverage versus generated-code coverage - MC/DC obligations at ASIL C and D - Chasing and justifying coverage gaps 10. 10 **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. - Static analysis of MISRA and run-time errors - Polyspace and model design verification - Formal proofs alongside dynamic testing 11. 11 **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. - Tool impact and tool error detection - TCL1, TCL2 and TCL3 classification - When qualification of the generator is required 12. 12 **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. - Torque limiter from model to qualified code - Common MBD pitfalls and coverage traps - The questions an assessor will actually ask Diagrams & Visuals ## Not just text: the visual toolkit ### 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. Worked Example ## 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 MIL vs SIL back-to-back: torque output exact match, arbitration MC/DC complete Unlock the full nine-step MBD chain, PIL results and tool confidence argument Built for ## Who this guide is for - Controls engineers whose Simulink models become production ASIL code - Software leads defining the verification strategy for autocoded components - Tool responsibles classifying and qualifying a code generator toolchain - Assessor-facing engineers who must argue why generated code was not hand-reviewed ## Frequently Asked Questions Common questions about Model-Based Development for ISO 26262 The ladder runs the same test cases against progressively more realistic execution platforms. MIL (model-in-the-loop) executes the model in the simulation environment, proving the design logic. SIL (software-in-the-loop) runs the generated code compiled for the host PC, exposing code generation and numeric effects. PIL (processor-in-the-loop) runs the code on the real target processor, catching compiler and word-length issues. HIL (hardware-in-the-loop) tests the integrated ECU against a real-time plant simulation. Each rung answers a distinct question, and skipping one leaves a class of errors unexamined. Back-to-back testing runs identical stimuli through two representations of the same component - typically the model and the generated code at MIL vs SIL or SIL vs PIL - and compares the outputs, expecting equivalence within defined tolerances or exact match for states and flags. ISO 26262-6 lists it as a verification method precisely for the MBD situation: your verified design artifact is the model, your shipped artifact is the code, and back-to-back results are the evidence that the two behave identically. The course's worked example proves an ASIL C torque limiter equivalent across MIL, SIL, and PIL with full MC/DC on the arbitration logic. The guide covers the full chain in 12 chapters - from hand-written code to models, the toolchain, what ISO 26262 says about MBD, modeling guidelines, function-to-implementation model refinement, production code generation, the 4-stage xIL ladder, back-to-back testing, coverage on model and code, static analysis and formal methods, and tool confidence - closing with a worked ASIL C torque limiter example and assessor questions. A free account starts you off, and the Pro and Expert plans unlock more of the library. ## Start the course today A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required. [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fmodel-based-development&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)