ISO 26262

ISO 26262 is the functional-safety standard for road-vehicle E/E systems. Learn the safety lifecycle, hazard analysis and risk assessment (severity, exposure, controllability), ASIL determination, safety goals and requirements, hardware metrics (SPFM, LFM, PMHF), software methods and safety mechanisms, and SOTIF.

When electronics steer, brake and accelerate the car, a software bug or hardware fault can kill. ISO 26262 defines how to develop these systems so that residual risk is acceptably low — from concept through production and operation.

Its central idea: the more dangerous a potential failure, the higher the Automotive Safety Integrity Level (ASIL A–D) and the more rigorous the development.

An analogy

ASIL is like a building code for earthquakes: a garden shed (QM) needs little, a hospital (ASIL D) needs the strictest design, testing and inspection.

Safety lifecycle and V-model

Concept (item definition, HARA, safety goals) → system → hardware and software development on the V-model with verification at each level → integration and validation → production, operation, decommissioning. Confirmation measures (reviews, audits, assessments) check independence.

HARA and ASIL

For each hazardous event, rate severity of harm, exposure to the driving situation and controllability by the driver. The combination gives ASIL QM, A, B, C or D. Safety goals (e.g. 'avoid unintended acceleration > 0.3 g') inherit the ASIL and are refined into functional and technical safety requirements.

Hardware and software

Hardware: FMEDA calculates failure rates and diagnostic coverage; SPFM/LFM/PMHF targets per ASIL; safety mechanisms (lock-step cores, ECC, watchdogs, plausibility checks). Software: coding guidelines (MISRA), unit testing with coverage (MC/DC for ASIL D), freedom from interference, static analysis.

Decomposition, SOTIF and cybersecurity

ASIL decomposition splits a requirement over independent redundant elements (e.g. D = B(D) + B(D)). ISO 21448 SOTIF addresses hazards without faults (sensor limitations, misinterpretation) — crucial for ADAS. ISO/SAE 21434 cybersecurity interacts with safety. Safety cases argue that all goals are met.

Formulas

• ASIL shortcut (S1–3, E1–4, C1–3): S + E + C = 10 → D, 9 → C, 8 → B, 7 → A, ≤ 6 → QM
• SPFM: SPFM = 1 − Σ(λ_SPF + λ_RF) / Σλ
• Targets: ASIL D: SPFM ≥ 99 %, LFM ≥ 90 %, PMHF < 10 FIT; ASIL B: ≥ 90 %, ≥ 60 %, < 100 FIT
• FIT: 1 FIT = 1 failure per 10⁹ device-hours

Worked example: ASIL determination

Given: Unintended full braking on a motorway: S3 (fatal), E4 (high exposure), C3 (uncontrollable); Wrong door-ajar chime: S0

Find: ASILs.

• S3 + E4 + C3 = 10 → ASIL D
• S0 → QM (no safety relevance)

Answer: ASIL D and QM

Worked example: Single-point fault metric

Given: Total safety-related failure rate 500 FIT; Single-point + residual faults 4 FIT

Find: SPFM and ASIL D compliance.

• SPFM = 1 − 4/500 = 99.2 % ≥ 99 % ✓

Answer: 99.2 % — meets ASIL D target

Common mistakes

• Wrong: Treating ISO 26262 as paperwork at the end. — Right: Safety drives architecture from the concept phase.
• Wrong: Assuming redundancy alone reaches ASIL D. — Right: Redundant parts must be independent (no common-cause failures).

Applications

• Brakes, steering, powertrain: ASIL C/D controllers with redundancy and monitoring.
• ADAS & automated driving: ISO 26262 + SOTIF + cybersecurity for perception and planning.
• EV batteries: BMS protecting against thermal runaway (ASIL C/D).

Key takeaways

• HARA: S × E × C → ASIL QM/A–D.
• Safety goals → FSC → TSC → HW/SW requirements.
• ASIL D: SPFM ≥ 99 %, LFM ≥ 90 %, PMHF < 10 FIT.
• Add SOTIF and cybersecurity for ADAS.

Going further

• FMEDA: Failure modes, effects and diagnostic analysis computes hardware metrics.
• Freedom from interference: Memory/timing protection prevents QM software corrupting ASIL software.
• Safety of the intended functionality: Scenario-based testing and triggering-condition analysis for ADAS.