The context — when electronics hold the wheel
A modern car is more than a hundred controllers commanding braking, power steering, transmission, and now driving assistance. When electronics decide, a failure no longer just stalls the engine: it can kill.
The Toyota unintended-acceleration affair, around 2009-2010, crystallised the question — not so much by its actual cause (largely attributed to floor mats and pedals) as by the one it posed to the whole industry: how do you prove an electronic control system is safe? ISO 26262, published in 2011, is the normative answer: adapting functional safety to the automotive world, where volume, cost and usage variability change the rules.
ISO 26262: the IEC 61508 of automotive
ISO 26262 — “Road vehicles — Functional safety” — is the automotive application of IEC 61508. It covers the electrical and electronic (E/E) systems of production vehicles. Its first edition dates from 2011; the second (2018) broadened the scope to trucks, buses and powered two-wheelers, and added a part dedicated to semiconductors.
Like all of the 61508 family, it rests on a safety lifecycle — but with vocabulary and metrics specific to the domain.
ASIL: the scale, determined by risk
Where the process world speaks SIL and machinery PL, automotive speaks ASIL — Automotive Safety Integrity Level: QM (quality managed, no safety requirement), then A, B, C, D (the most demanding).
ASIL is not chosen, it is determined by the HARA analysis (Hazard Analysis and Risk Assessment), combining three parameters for each hazardous situation:
- Severity (S0-S3): from no injury to fatal injuries;
- Exposure (E0-E4): the probability of being in the situation (rainy motorway, reversing…);
- Controllability (C0-C3): the driver’s ability to avoid the harm.
Crossing the three gives the ASIL. A severe (S3), frequent (E4) and uncontrollable (C3) situation calls for ASIL D.
The V-model and the safety case
ISO 26262 structures development as a V-model: item definition, HARA, functional safety concept, then technical safety concept, system / hardware / software development, and the ascent through integration, verification and validation.
It is all recorded in a safety case arguing that the item is safe. An automotive specificity: the confirmation measures — confirmation reviews, functional safety audit, and assessment — with increasing degrees of independence depending on the ASIL. The higher the ASIL, the more the assessor must be independent of the design team.
The automotive-specific concepts
Four notions structure the practice:
- ASIL decomposition: splitting an ASIL D requirement across two independent lower-level elements (e.g., ASIL B(D) + ASIL B(D)), provided their independence is proven. It makes achievable what would be too costly in one block.
- SEooC (Safety Element out of Context): developing a component without a specific target vehicle, on the basis of usage assumptions, which an integrator then validates. It is the model of Tier-1 suppliers.
- FTTI (Fault Tolerant Time Interval): the time between a fault appearing and the harm. Fault detection and the transition to a safe state must fit within this window.
- Hardware metrics: automotive does not measure PFD but coverage rates and an hourly probability.
| Metric | ASIL B | ASIL C | ASIL D |
|---|---|---|---|
| SPFM (single-point faults covered) | ≥ 90 % | ≥ 97 % | ≥ 99 % |
| LFM (latent faults covered) | ≥ 60 % | ≥ 80 % | ≥ 90 % |
| PMHF (dangerous failure/hour) | < 10⁻⁷ | < 10⁻⁷ | < 10⁻⁸ |
The risk reduction to SIL and failure rate to MTBF calculators remain useful for reasoning in orders of magnitude.
SOTIF (ISO 21448): when the function “works” but is not enough
ISO 26262 deals with failures: a component breaks. But ADAS and autonomous driving pose another problem: the system works exactly as designed, and it is the design itself that is insufficient — a camera that fails to recognise a pedestrian against the sun, a radar fooled by a reflection. No failure, but a hazard.
That is the subject of SOTIF — ISO 21448 (Safety Of The Intended Functionality): the safety of the intended function against performance limits and foreseeable misuse. For an autonomous vehicle, SOTIF is at least as critical as ISO 26262: you can no longer reduce everything to a failure. The two standards complement each other.
Cybersecurity: ISO/SAE 21434
A connected vehicle is attackable, and an attack can become a physical hazard. ISO/SAE 21434 is the cybersecurity counterpart of ISO 26262 — Road vehicles — Cybersecurity engineering. Functional safety, SOTIF and cybersecurity now form a triptych inseparable from vehicle development.
The stakes
The human stake is direct: braking, steering, ADAS — failure is measured in lives.
The industrial stake is scale: a systematic defect replicates across millions of vehicles; a recall costs hundreds of millions. Process rigour is not a luxury, it is insurance.
The regulatory stake rises with autonomy: type approval, liability, and a framework (including the EU AI Act for AI functions) that is tightening.
The mistakes not to make
| Mistake | Why people make it | Why it is dangerous |
|---|---|---|
| Believing ISO 26262 covers ADAS on its own | It is THE automotive safety standard | 26262 handles failures, not functional insufficiency — you need SOTIF (21448) |
| Decomposing into ASIL without proving independence | Cutting the cost of an ASIL D | Without real independence, a common cause ruins the decomposition |
| Using a SEooC without checking the assumptions | Reusing an “already safe” component | The supplier’s usage assumptions may not hold in your vehicle |
| Forgetting the FTTI | Detecting the fault… too late | Detection slower than the tolerance window does not protect |
| Separating safety and cybersecurity | Two teams, two worlds | A cyber flaw can trigger the very hazard functional safety aimed to prevent |
Good practice
Run a rigorous HARA per situation, and derive the ASIL — do not “choose” it by habit.
Treat ISO 26262 (failures), SOTIF (functional insufficiency) and ISO/SAE 21434 (cyber) together, especially for ADAS and autonomy.
Justify any ASIL decomposition with demonstrated independence.
Verify a SEooC’s assumptions in the real integration context.
Size fault detection and the transition to a safe state to fit within the FTTI.
Document a reasoned safety case and organise confirmation measures with the independence the ASIL requires.
Review checklist
- Item definition clear and bounded
- HARA documented (S, E, C) and ASIL determined per function
- Functional then technical safety concepts traced
- ASIL decomposition justified by proven independence
- SEooC assumptions verified at integration level
- Hardware metrics met (SPFM, LFM, PMHF) for the target ASIL
- FTTI covered by detection + safe state
- SOTIF (ISO 21448) addressed for ADAS/autonomous functions
- Cybersecurity (ISO/SAE 21434) integrated
- Safety case and confirmation measures with adequate independence
Going further
- The ISO 26262 page and the parent standard IEC 61508.
- The other variants: IEC 61511 — process and IEC 62061 & ISO 13849 — machinery, on the IEC 61508 foundation.
- The risk reduction to SIL and failure rate to MTBF calculators.
One last thing. The automotive industry pushed functional safety to mass scale, then forced it to surpass itself: with autonomy, proving a system does not fail is no longer enough — you must prove that, even working perfectly, it does the right thing. That is the whole leap from ISO 26262 to SOTIF, and the real challenge of the decade.