What is ISO 26262? A Complete Guide to Automotive Functional Safety

Why Functional Safety Exists as a Discipline

Modern vehicles run on 100 or more electronic control units executing tens of millions of lines of code. A single latent defect in a brake controller, a misbehaving steering ECU, or a hardware fault in an electric powertrain inverter can kill drivers, passengers, and pedestrians. Functional Safety — the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical or electronic systems — is the discipline that systematically reduces that risk.

ISO 26262 is the automotive sector's answer to this problem. It tells development teams exactly how rigorously to engineer a brake-by-wire system versus a rear window defogger, and how to prove that rigor to a regulator, an OEM, or a court.

The standard descends from IEC 61508, the generic functional safety standard for programmable electronics published in 1998. IEC 61508 is deliberately broad. Its Safety Integrity Levels (SIL 1–4) apply to nuclear plants, railway signalling, industrial robots, and medical devices. Automotive teams found IEC 61508 too generic — vehicles have different hazard exposure patterns than nuclear reactors and different controllability assumptions than unattended industrial machinery. The automotive industry adapted IEC 61508 into ISO 26262, first published in November 2011.

The 2011 first edition covered passenger cars up to 3.5 tonnes. It excluded trucks, buses, motorcycles, and specialty vehicles. That limited scope created gaps — commercial vehicle OEMs developed bespoke processes, motorcycle makers had no applicable standard, and semiconductor suppliers struggled to align their qualification flow with customer ASIL demands.

The second edition, published in December 2018, corrected this. It expanded coverage to all road vehicles, added a new Part 11 specifically for semiconductors, added a new Part 12 tailored to motorcycles, and clarified 2011 ambiguities around ASIL decomposition, safety element out of context, and tool qualification. ISO 26262:2018 is the current edition.

Scope: What ISO 26262:2018 Covers and What It Does Not

ISO 26262 applies to serial-production road vehicles, including passenger cars, trucks, buses, trailers, and motorcycles. It addresses malfunctioning behaviour of electrical, electronic, and programmable electronic (E/E) systems — not mechanical-only systems, not human factors outside the vehicle, and not misuse.

Three adjacent concerns are explicitly out of scope:

• Cybersecurity is covered by ISO/SAE 21434, published in 2021. ISO 26262 assumes the E/E system is not under adversarial attack.
• Performance limitations of the intended functionality — cases where a system works exactly as designed but the design itself is insufficient in some operating scenario — are covered by ISO 21448 (SOTIF), published as a full standard in 2022. A lane-keep assist that correctly follows worn road markings off a cliff is a SOTIF problem, not a functional safety problem.
• Agricultural, off-highway, and mining vehicles are not covered, though the principles transfer readily.

The 12 Parts of ISO 26262:2018

Parts 1 and 10 are informative — they define vocabulary and provide guidance without mandating work products. Parts 2 through 9 are normative and contain the actual requirements auditors check. Parts 11 and 12 are domain-specific normative extensions.

A common practitioner question: why is Part 11 semiconductor-specific when hardware is already covered in Part 5? The answer is that Part 5 assumes the design team has full visibility into the hardware. Semiconductor suppliers often sell pre-qualified IP blocks — analog frontends, safety microcontrollers, memory — as “Safety Elements out of Context” (SEooC). Part 11 defines how to qualify those blocks for downstream integration without exposing proprietary internals.

The Safety Lifecycle and the V-Model

ISO 26262 organises development around a safety lifecycle that tracks a product from concept to decommissioning: Concept → Development → Production → Operation → Decommissioning. At each phase, the standard mandates specific work products and review gates.

Development itself follows a V-model. The left side of the V — concept, requirements, architecture — cascades downward from vehicle-level safety goals to software unit implementation. The right side of the V — integration, verification, validation — ascends from unit tests to vehicle-level validation. Each left-side artefact has a corresponding right-side verification or validation step.

Production, operation, and decommissioning sit outside the V on Part 7's horizontal track. Supporting processes — change management, configuration, tool qualification, distributed development — run continuously across the lifecycle per Part 8.

HARA and the Derivation of ASIL

Every ISO 26262 programme begins with Hazard Analysis and Risk Assessment (HARA). HARA identifies hazardous events that malfunctioning E/E behaviour could cause and assigns each hazard an Automotive Safety Integrity Level (ASIL). The ASIL then determines how rigorously the system must be engineered.

ASIL derivation uses three parameters, defined in ISO 26262-3:2018 Annex B:

Severity (S) — the potential for harm in the hazardous event. S0 means no injuries. S1 means light to moderate injuries. S2 means severe to life-threatening (survival probable). S3 means life-threatening to fatal (survival uncertain).

Exposure (E) — the probability that the vehicle is in a situation where the hazard could materialise. E0 is essentially negligible. E1 is very low probability (rare situations). E2 is low. E3 is medium. E4 is high probability (routine driving).

Controllability (C) — the probability that the driver or another party can prevent harm once the hazard manifests. C0 means controllable in general. C1 means simply controllable (more than 99% of drivers can avoid harm). C2 means normally controllable (more than 90% can avoid). C3 means difficult to control or uncontrollable (less than 90%).

The three parameters combine through a lookup table. The anchor rule: S3/E4/C3 → ASIL D. Every single-step reduction in any one parameter drops the resulting ASIL by one level. Combinations involving S0, E0, or C0 resolve to QM (Quality Managed — standard automotive quality processes apply, no ISO 26262 rigor beyond that).

Worked example 1 — unintended motor torque at a stationary signal. An electric vehicle's traction motor delivers unintended forward torque while the driver waits at a red light in urban traffic. Severity: fatal collision possible with cross-traffic or pedestrians — S3. Exposure: urban driving with signalled intersections is routine — E4. Controllability: most drivers cannot react before the vehicle lurches into cross-traffic — C3. Result: ASIL D.

Worked example 2 — rear brake-light failure. The rear brake lamp fails to illuminate when the driver presses the brake pedal. Severity: rear-end collision possible, likely severe — S2. Exposure: braking is routine — E4. Controllability: following driver typically has reaction distance — C1. Result: ASIL B.

The HARA output — a set of hazardous events, each with an ASIL and an associated safety goal (the top-level negative requirement, e.g., “prevent unintended traction torque exceeding X Nm while vehicle is stationary”) — drives every downstream engineering decision. For a deeper walkthrough of ASIL severity, exposure, and controllability, see our ISO 26262 ASIL Levels Explained post.

ASIL Decomposition

Developing an ASIL D component is expensive. It requires diverse hardware, formal verification, exhaustive test coverage, and independent safety assessment. ISO 26262-9:2018 Clause 5 permits a controlled relaxation: ASIL decomposition.

The principle: if a safety requirement can be implemented as two sufficiently independent sub-requirements that together satisfy the original, the sub-requirements can be developed to lower ASIL levels. The original item-level safety goal's ASIL never changes — only the implementation rigor for each sub-requirement does.

Valid decomposition schemes per Part 9 Clause 5 Table 1:

The notation ASIL B(D) means “developed to ASIL B rigor, satisfying a requirement that was originally ASIL D.” The parenthetical preserves traceability to the safety goal.

The hinge of decomposition is independence. Part 9 Clause 7 defines Dependent Failure Analysis (DFA). Shared power supplies, shared clocks, shared silicon, shared review teams, shared toolchains, and shared compilers can all invalidate the independence claim. A decomposition that looks valid on paper collapses under DFA if the two “independent” branches are actually susceptible to the same root-cause failure.

Worked example — electric power steering.A safety goal of “prevent unintended steering torque exceeding X Nm” is initially rated ASIL D. The development team decomposes it into a main ECU developed to ASIL B(D) that performs torque computation, plus an independent monitor microcontroller on a separate die, developed to ASIL B(D), that cross-checks the computation and cuts power if the main ECU's output exceeds bounds. DFA confirms the two dies have independent power regulators, independent clocks, and were reviewed by separate safety teams. The decomposition is valid and the project avoids the cost of ASIL D development on both paths.

Hardware Architectural Metrics: SPFM, LFM, PMHF

Part 5 mandates three quantitative hardware metrics to demonstrate that the hardware architecture is safe enough for its assigned ASIL.

Single-Point Fault Metric (SPFM)measures the architecture's robustness against single-point faults — faults where a single hardware failure directly violates the safety goal. Higher percentages mean more faults are either safe by design or covered by safety mechanisms.

Latent-Fault Metric (LFM)measures the architecture's robustness against latent faults — faults that are not detected before a second fault causes harm. Higher percentages mean more dormant faults are either safe or detected by diagnostics.

Probabilistic Metric for Hardware Failures (PMHF) is a probabilistic metric expressing the residual hardware failure rate per hour of operation.

Target values per ISO 26262-5:2018 Tables 4, 5, and 6:

A subtle point worth flagging: the PMHF targets for ASIL B and ASIL C are identical (< 10^-7 h^-1). The differentiation between B and C happens at SPFM and LFM, not PMHF. Many practitioners assume C is tighter on every metric and are surprised. The standard also notes (Table 6) that these target values can be tailored per Clause 4.2 for specific item uses — a vehicle driven only in daylight for under two hours per day, for instance, has a different operational profile than a commercial truck logging sixteen-hour duty cycles.

Teams demonstrate compliance through Failure Mode, Effects, and Diagnostic Analysis (FMEDA) — a structured table mapping each hardware fault mode to its probability, its effect on safety, and the diagnostic coverage provided by safety mechanisms. FMEDA is labour-intensive, error-prone, and the single most common source of audit findings in hardware safety cases.

Software Development Under ISO 26262

Part 6 governs software development at the unit, integration, and system levels. Three areas dominate practitioner attention:

Coding guidelines. MISRA C:2012 and MISRA C++:2023 are the de facto automotive coding standards. ISO 26262 does not mandate them by name but requires the team to select a language subset that demonstrably reduces the frequency of systematic faults. MISRA compliance — via static analysis tools — is the most common way teams meet this requirement.

Structural coverage. ASIL-dependent coverage expectations per Part 6 Clause 9:

• ASIL A: statement coverage
• ASIL B: statement + branch coverage
• ASIL C: statement + branch + MC/DC (modified condition/decision coverage) recommended
• ASIL D: statement + branch + MC/DC required

MC/DC is the most expensive to achieve. Each condition in a Boolean expression must be shown to independently affect the decision outcome. For a Boolean expression with four operands, MC/DC typically requires five carefully designed test cases rather than the sixteen that exhaustive coverage would demand.

Tool qualification. Safety-critical software is built with compilers, static analysers, test generators, and model-based development tools. If a tool error could inject a fault that safety mechanisms cannot detect, the tool itself must be qualified. Part 8 Clause 11 defines the process: determine Tool Impact (TI), determine Tool error Detection (TD), derive the resulting Tool Confidence Level (TCL), and qualify the tool according to the TCL. A compiler used to build ASIL D object code is typically TCL3 — the highest qualification burden.

Safety Element out of Context (SEooC)

Part 10 Clause 9 defines the Safety Element out of Context pattern. A SEooC is a component developed without knowing the specific item it will be integrated into — a safety microcontroller IP block, a motor driver reference design, a communication stack.

The SEooC supplier makes a set of safety assumptions about how the element will be used: supply voltage range, operating temperature, clock frequency, software integration approach, diagnostic response time. Downstream integrators must validate that these assumptions hold in their actual system. Mismatches between SEooC assumptions and integration reality are a frequent source of latent defects.

ISO 26262 vs ISO/SAE 21434 vs ISO 21448

Modern vehicle programmes must satisfy three adjacent standards simultaneously.

The three standards increasingly converge in practice. The same item definition feeds HARA, TARA, and SOTIF analysis. The same V-model hosts functional safety, cybersecurity, and SOTIF verification. Release gates increasingly require all three release recommendations concurrently. For a deeper dive into the ISO/SAE 21434 side, see our complete checklist of ISO/SAE 21434 work products.

A practice gaining traction is Security-Informed Safety. A TARA finding — say, that an attacker can inject false torque commands on an internal bus — directly becomes a HARA hazardous event because the attacker's action makes malfunctioning E/E behaviour more likely. Running TARA and HARA in isolation misses this coupling. Running them together, with a shared item definition and cross-feeding findings, produces stronger cases for both.

Common Implementation Pitfalls

Teams deploying ISO 26262 for the first time routinely encounter the same failure modes:

• Controllability over-rating.Assessment authorities push hardest on C ratings because they directly reduce ASIL. A “most drivers can brake in time” claim for C1 must be backed by driving studies, simulator data, or at minimum a defensible engineering argument. Asserting C1 without evidence is the fastest route to an audit finding.
• Insufficient independence for decomposition. Dependent Failure Analysis is the hinge. Shared power rails, clocks, or silicon die invalidate independence claims. Teams often assume independence and discover the gap during assessment.
• Item definition drift. The item defined at the start of the project rarely matches the item delivered. If the drift is not tracked, the HARA becomes stale — its hazard list no longer matches reality. Configuration management of the item definition is a boring but critical discipline.
• Broken bidirectional traceability across Tier-2 handoffs. OEM safety goals must trace to Tier-1 technical safety requirements, which must trace to Tier-2 hardware and software requirements. When a Tier-2 supplier redesigns a component mid-program, the upward trace back to the original safety goal often breaks silently.
• Retrofit safety cases. Building a safety case by reverse-engineering a nearly-complete product is possible but expensive and audit-fragile. Safety case construction must start at item definition.
• Tool Confidence Level ignored.Teams adopt new static analysis tools, new CI/CD pipelines, new model-based tools mid-project without re-running tool qualification. If the new tool's output affects ASIL-relevant artefacts, the qualification must be refreshed.
• FMEDA with unrealistic diagnostic coverage. FMEDA tables with 99% diagnostic coverage on every fault mode are a red flag. Real systems have holes — sensor saturation regions, cold-start windows, bus collision states — where diagnostics cannot fire. Honest FMEDA admits these and justifies residual risk.
• SEooC assumption mismatches.The supplier's safety manual assumes a 5V supply with 100 mV ripple; the integrator runs it at 5V with 350 mV ripple because of layout constraints. The assumption is violated silently and surfaces only in field failures.
• Category confusion.A team debates whether a given hazard is FuSa, cybersecurity, or SOTIF and spends weeks on classification instead of mitigation. The pragmatic answer is usually “all three” — engineer the mitigation, then argue the category after.

How Agnile Supports ISO 26262 Programmes

Our certified practitioners support OEM and Tier-1 programmes across the full ISO 26262 lifecycle: HARA facilitation and ASIL derivation, Functional Safety Concept and Technical Safety Concept development, hardware safety requirements and FMEDA, MISRA-compliant software development with structural coverage, tool qualification, and Safety Case construction.

For programmes running Functional Safety and Cybersecurity in parallel, we deliver a joint operating model — shared Item Definition, parallel HARA and TARA, coordinated release gates — supported by KAVACH on the cybersecurity side.

Frequently Asked Questions

By Shreyansh, Founder & CTO, Agnile Technologies.