ISO 26262-Aligned Model-Based Development Workflow for an EV Function

The problem

ISO 26262 asks for systematic development and evidence for safety-related automotive software, and many teams use model-based design to meet it. Students and researchers rarely see the whole chain, from hazard to safety requirement to model to test to evidence, on one function. Doing it end to end shows where tools help, where engineering judgement is essential and where evidence gaps usually appear.

Objectives

• Perform a hazard analysis and risk assessment for unintended acceleration in an EV.
• Derive safety goals and functional and technical safety requirements.
• Model a torque-monitoring safety mechanism to modelling guidelines.
• Verify it with requirement-based tests, coverage and formal property proving.
• Assemble and assess a traceable evidence package.

What you need

Key concepts

HARA and ASIL

Hazard analysis and risk assessment rates each hazard by severity, exposure and controllability, giving an Automotive Safety Integrity Level from A to D that sets the rigour of development.

Safety goal and safety mechanism

A safety goal is a top-level requirement such as 'avoid unintended acceleration'; a safety mechanism, such as a torque monitor, detects and handles faults to meet it.

Modelling guidelines

Rules on model style and constructs (naming, block use, Stateflow semantics) that make models analysable and code generation predictable; Model Advisor checks many automatically.

Tool qualification

ISO 26262 asks for confidence in the tools used; vendors provide qualification kits, and projects must still assess tool use. This project discusses it but does not perform it.

Step-by-step guide

1. 1

   Scope the item and the function

   Define the item as an EV traction control path: pedal sensors to VCU to motor controller. Choose the function to develop: a torque monitor in the VCU that compares delivered torque estimate with the driver's request and drives a safe state on a persistent mismatch. Write an item definition with boundaries, interfaces and assumptions, noting that everything is an academic example.

   Checkpoint: An item definition with a context diagram and stated assumptions.

2. 2

   Perform HARA

   List hazards such as unintended acceleration, unintended deceleration and loss of drive. For each, consider operating situations (urban traffic, highway, parking), rate severity, exposure and controllability with justifications, and derive an ASIL. Formulate safety goals with safe states and fault-tolerant time intervals as example values. Have a peer review the ratings. Keep the reasoning for every rating, not only the result, because the justification is what a reviewer examines most closely in a hazard analysis.

   Checkpoint: A HARA table with justified ratings and at least one safety goal with an ASIL and safe state.

3. 3

   Derive safety requirements

   Derive functional safety requirements from the safety goal (for example 'detect torque greater than request by more than a threshold for longer than a time and command zero torque') and technical safety requirements for the torque monitor. Enter them in Requirements Toolbox as a hierarchy linked to the safety goal. Record ASIL attributes as custom attributes. Check each requirement for testability and allocate it clearly to the torque monitor or to another element, so verification responsibilities are unambiguous.

   Checkpoint: A linked requirement hierarchy from safety goal to technical requirements.

4. 4

   Model to guidelines

   Build the torque monitor model: plausibility check of pedal sensors, comparison of estimated and requested torque, debounce, fault latching and safe-state command. Follow a chosen guideline set from the start. Link each block or state to the requirement it implements. Keep the design simple and readable, as a reviewer would expect for safety logic. Keep the monitor independent of the main torque path's calculations where possible, since a shared error could defeat both.

   Checkpoint: A model with every element linked to a requirement and the implementation status at 100 per cent.

5. 5

   Run Model Advisor checks

   Run Simulink Check's Model Advisor with the modelling-standards and high-integrity check sets. Fix violations or record justified deviations. Collect model metrics such as complexity and size. Rerun until clean. Note which checks found real problems and which were style only; this feeds the tool-effectiveness evaluation later. Save the Model Advisor configuration with the project so the same checks are run each time, and archive each report with the model version it checked. Track the number of violations found over time.

   Checkpoint: A Model Advisor report with all checks passing or each deviation justified.

6. 6

   Requirement-based testing

   Write test cases for each technical safety requirement in Simulink Test, including fault injection: stuck pedal sensor, sensor disagreement, torque estimate drift and timing at the edge of the fault-tolerant time interval. Link tests to requirements. Run them and update verification status. For each fault-injection test, record the expected safe-state response and the time at which it must occur, and check both with assessments. Include tests where faults clear just before the debounce completes, which often reveal timing defects.

   Checkpoint: All tests pass and every safety requirement shows as verified.

7. 7

   Coverage and gap closure

   Measure model coverage including MC/DC, as expected at higher ASILs. Close gaps with requirement-based tests where possible and justify the rest. Generate code, run the tests in SIL as back-to-back equivalence tests and measure code coverage. Compare model and code coverage and explain differences. Record each coverage gap with its resolution, and check that tests added to close gaps also check an expected result derived from a requirement. Keep the coverage targets per ASIL in the plan.

   Checkpoint: Coverage reports for model and code with every gap closed or justified, and SIL equivalence passing.

8. 8

   Formal property proving

   Express key safety requirements as properties with Simulink Design Verifier's proof objectives or assertions, for example 'if mismatch persists longer than T, safe-state command is true'. Run property proving and design error detection (dead logic, division by zero, overflow). Investigate counterexamples, fix the design or the property, and rerun. Record the assumptions used for each proof, since a proof is only as strong as its assumptions, and have a peer review them.

   Checkpoint: Key safety properties proven valid or each counterexample resolved, with a design error detection report.

9. 9

   Assemble the evidence package

   Collect the item definition, HARA, requirements, traceability matrix, Model Advisor reports, test and coverage reports, SIL equivalence results and proof reports. Script the generation so it can be rerun. Build a table that maps each relevant ISO 26262 Part 6 work product to the evidence you have and lists what is missing. Version the package together with the model, so any change to the design triggers regeneration of the affected evidence.

   Checkpoint: A scripted evidence package and a work-product mapping table with gaps listed.

10. 10

    Evaluate the workflow

    Record effort for each activity and the defects each found. Analyse which activities found the most important defects, how much was automated and where manual judgement dominated (HARA, requirement quality, justifications). Introduce seeded defects in the model to compare how many each verification method detects. Keep effort records as you work, not from memory afterwards, and classify each defect by type and severity so the comparison between activities is meaningful.

    Checkpoint: An effort and defect-detection table per activity, including seeded-defect results.

11. 11

    Write up

    Present the workflow, artefacts, results and evaluation. Be explicit that this is an academic, ISO 26262-aligned exercise and not a compliant safety case: no confirmation reviews, no tool qualification and no hardware considerations. Discuss what a real project would add. Release the models and scripts. Include the work-product mapping table so readers can see at a glance which parts of the standard the project addresses and which it leaves out.

    Checkpoint: A thesis chapter or paper draft with a clear statement of scope and limitations.

Testing & validation

• HARA reviewed by a peer with justified ratings.
• Full traceability from safety goal to tests.
• Model Advisor checks passing or deviations justified.
• Requirement-based tests passing with MC/DC coverage gaps closed or justified.
• Safety properties proven or counterexamples resolved.
• Seeded-defect detection rates per verification method.

Expected results

An end-to-end ISO 26262-aligned model-based development of an EV torque monitor, with a traceable evidence package and a quantitative evaluation of which workflow activities found which defects and at what effort.

Take it further

• Add PIL on a target processor and extend the evidence package.
• Perform an FMEA or FTA of the torque path and link it to requirements.
• Compare with a hand-coded implementation of the same function.
• Apply the workflow to a BMS function and compare effort.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.