# ISO 26262: automotive functional safety — ASIL, HARA, decomposition and SOTIF for ADAS

> ISO 26262 applies IEC 61508 to the electrical and electronic systems of road vehicles. ASIL levels (QM, A-D) determined by HARA (severity, exposure, controllability), the V-model, hardware metrics (SPFM, LFM, PMHF), ASIL decomposition, SEooC, and the complementary role of SOTIF (ISO 21448) for ADAS and autonomy. Stakes, mistakes, good practice.

- Source : https://industryhub.site/en/articles/securite-fonctionnelle-iso-26262
- Published : 2026-06-14
- Author : IndustryHub
- Language : English
- Keywords : iso-26262, asil, hara, sotif, iso-21448, pmhf, automobile, adas

## 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](/en/standards/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](/en/tools/safety/rrf-sil) and [failure rate to MTBF](/en/tools/safety/fit-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](/en/standards/iso-26262) page and the parent standard [IEC 61508](/en/standards/iec-61508).
- The other variants: [IEC 61511 — process](/en/articles/securite-fonctionnelle-iec-61511) and [IEC 62061 & ISO 13849 — machinery](/en/articles/securite-fonctionnelle-machines-62061-13849), on the [IEC 61508](/en/articles/securite-fonctionnelle-iec-61508) foundation.
- The [risk reduction to SIL](/en/tools/safety/rrf-sil) and [failure rate to MTBF](/en/tools/safety/fit-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.