ISO 26262 is the international functional safety standard for electrical and electronic (E/E) systems in road vehicles, first published in 2011 by ISO Technical Committee 22 and revised in a second edition in 2018 to extend coverage to motorcycles (Part 12) and semiconductor components (Part 11). The standard introduces the Automotive Safety Integrity Level (ASIL) classification system, ranging from ASIL A (lowest rigour) to ASIL D (highest rigour), derived from a Hazard Analysis and Risk Assessment (HARA) process that combines Severity, Exposure, and Controllability parameters for each hazardous event. Compliance requires evidence of a structured safety lifecycle encompassing concept phase, system design, hardware, software, production, and operation, providing automotive OEMs, Tier 1 suppliers, and semiconductor manufacturers with a shared framework for demonstrating that residual risk of hazardous E/E failure is acceptably low. The standard is widely mandated for ADAS, powertrain control, braking, and steering systems globally, and is increasingly complemented by SOTIF (ISO 21448) and the cybersecurity standard ISO/SAE 21434 for AI-enabled autonomous driving systems.
Overview
- ISO 26262 was published in 2011 by the International Organisation for Standardisation (ISO) under Technical Committee 22 (Road Vehicles), developed in response to the exponential growth in complexity and safety criticality of vehicle electronics throughout the 2000s.
- A second edition was released in 2018, adding Part 11 (semiconductor components) and Part 12 (motorcycles), reflecting the proliferation of complex SoCs and the extension of E/E safety concerns beyond passenger cars.
- The standard establishes a complete safety lifecycle model that mirrors the V-model used in embedded software engineering — hazard analysis feeds into safety goals, which cascade through system, hardware, and software development phases, each verified and validated before integration.
- Globally, ISO 26262 compliance is either mandated by regulation or required contractually by OEMs and Tier 1 suppliers in all major automotive markets including the EU, USA, Japan, South Korea, and China.
- The standard is domain-specific and does not cover road infrastructure, trucks over 3.5 tonnes, or rail — each of which has its own functional safety standard (e.g., EN 50128 for rail, DO-178C for avionics).
Key Components
Structure — Twelve Parts
- Part 1 — Vocabulary: defines all terms and abbreviations used across the standard.
- Part 2 — Management of Functional Safety: covers organisational competence, safety culture, quality management interface, and functional safety management plan.
- Part 3 — Concept Phase: the critical Hazard Analysis and Risk Assessment (HARA) process that assigns ASIL ratings to safety goals; also covers item definition and functional safety concept.
- Part 4 — Product Development at the System Level: technical safety concept, system design, hardware-software interface specification, system integration, and validation.
- Part 5 — Product Development at the Hardware Level: hardware design, hardware architectural metrics (SPFM, LFM, PMHF), and hardware integration testing.
- Part 6 — Product Development at the Software Level: software safety requirements, architectural design, unit design and implementation, unit testing, integration testing, and Software Testing strategies by ASIL.
- Part 7 — Production, Operation, Service, and Decommissioning: maintenance of functional safety through production and field use.
- Part 8 — Supporting Processes: configuration management, documentation, software tool qualification, qualification of software components, and Formal Verification methods.
- Part 9 — ASIL-oriented and Safety-Oriented Analyses: guidelines for FMEA, Fault Tree Analysis (FTA), FMEDA, and dependent failure analysis.
- Part 10 — Guidelines on ISO 26262: informative guidance and worked examples.
- Part 11 — Semiconductor Components: safety analysis and qualification for complex hardware including SoCs and FPGAs.
- Part 12 — Adaptation for Motorcycles: hazard profiles and ASIL assignments specific to two-wheeled vehicles.
ASIL Classification
- ASIL is determined by the HARA process using three parameters:
- Severity (S0–S3): S0 = no injury; S1 = light injury; S2 = serious, possibly life-threatening injury; S3 = life-threatening or fatal injury.
- Exposure (E0–E4): how frequently the vehicle is in a situation where the hazard could occur (E0 = incredible; E4 = high probability, e.g., highway driving).
- Controllability (C0–C3): C0 = controllable in general; C3 = difficult or impossible to control, requiring automated mitigation.
- The combination yields ASIL A, B, C, or D — or QM (Quality Management) if functional safety measures beyond normal quality practice are not required.
- ASIL D is the most stringent: it requires the highest structural coverage (DC Coverage for software), the strictest coding guidelines (MISRA C), the most comprehensive independence in development and verification, and the most rigorous Safety Case documentation.
- ASIL decomposition allows an ASIL D requirement to be split into two independent ASIL B channels, reducing individual component requirements while maintaining overall system integrity.
Functional Safety Management
- Every project must appoint a qualified functional safety manager and produce a Functional Safety Management Plan.
- Supplier management provisions define how ASIL requirements are communicated and verified along the supply chain, a critical concern for multi-tier automotive procurement.
- Independence requirements for safety activities (separation of developer and verifier roles) become more stringent at higher ASIL levels.
Software Development (Part 6)
- MISRA C (or MISRA C++) coding guidelines are the de facto standard for ASIL B–D software; use of banned language constructs is documented and justified.
- Software Testing requirements escalate by ASIL: statement coverage (ASIL A), branch coverage (ASIL B/C), and DC Coverage (ASIL D).
- Tool qualification (Part 8) classifies development tools by Tool Confidence Level (TCL 1–3) and requires validation evidence proportional to their potential to introduce errors.
- Software components from prior projects (SEooC — Safety Element out of Context) must provide documented ASIL-appropriate evidence for reuse.
Hardware Architectural Metrics
- Part 5 requires quantitative demonstration of hardware architectural metrics:
- Single Point Fault Metric (SPFM): percentage of random hardware failures covered by safety mechanisms.
- Latent Fault Metric (LFM): percentage of latent faults that are detected before the next diagnostic opportunity.
- Probabilistic Metric for random Hardware Failures (PMHF): overall target in FIT (Failures In Time) per hour for the safety goal.
- These metrics require detailed FMEDA (Failure Modes Effects and Diagnostic Analysis) of all hardware components.
Applications and Use Cases
ADAS Systems
- ADAS features such as Automatic Emergency Braking (AEB), Lane Keeping Assist (LKA), and Adaptive Cruise Control (ACC) are typically ASIL B–D items requiring full ISO 26262 treatment of sensors, actuators, and the central ADAS ECU.
- ISO 26262 provides the safety argument structure that regulators (UN ECE WP.29, NHTSA) expect to see for type approval of active safety systems.
Autonomous Driving
- Autonomous Vehicle systems combine ISO 26262 (random hardware failure safety), ISO 21448 (SOTIF) (functional insufficiency of intended functionality under nominal conditions), and SAE 21434 (cybersecurity), forming a multi-standard compliance architecture.
- Level 3–5 autonomous driving ECUs commonly require ASIL D for the primary safety path, with ASIL decomposition used to split responsibilities across redundant compute channels.
Powertrain and Chassis Control
- Engine management, transmission control, electric vehicle battery management systems (BMS), electronic power steering, and electronic braking systems are typically ASIL C–D items developed fully under ISO 26262.
Semiconductor and SoC Development (Part 11)
- Microcontrollers and SoCs designed for automotive safety applications (e.g., NXP S32, Infineon AURIX, Renesas RH850) undergo ISO 26262 Part 11 qualification, providing OEM customers with documented safety analyses and ASIL-compliant hardware diagnostic mechanisms.
Tool and IP Core Qualification
- ISO 26262 Part 8 provides the framework for qualifying Software Testing and verification tools, compiler vendors, and reused IP cores, enabling the ecosystem of certified development environments (e.g., LDRA, VectorCAST, MATLAB/Simulink with IEC Certification Kit).
Standards and Context
Relationship to IEC 61508
- IEC 61508 is the parent generic functional safety standard for electrical/electronic/programmable electronic systems across all industries (process control, rail, nuclear, medical, automotive). ISO 26262 formally derives from it, adapting the SIL framework to ASIL and introducing automotive-specific processes such as HARA, SEooC, and supply chain management provisions.
SOTIF — ISO 21448
- ISO 21448 (SOTIF) (Safety of the Intended Functionality) was published in 2022 to address hazards arising not from E/E failures but from functional limitations of sensors and algorithms operating nominally — the primary challenge for Machine Learning Safety and ADAS perception systems. It complements rather than replaces ISO 26262.
ISO/SAE 21434 — Cybersecurity
- SAE 21434 (published 2021) establishes requirements for cybersecurity risk management in road vehicles throughout the full lifecycle, addressing threats to vehicle networks (CAN, Ethernet, OTA updates) that can subvert safety functions. ISO 26262 and 21434 share lifecycle structure and interface at the concept phase.
ISO/PAS 8800 — AI Safety
- PAS 8800 is the emerging standard addressing AI systems in road vehicles, providing a framework for the safety argument for ML-based components that cannot be exhaustively verified by conventional testing. It bridges ISO 26262 and SOTIF for AI perception and decision-making systems.
Aviation Parallels
- DO-178C (software) and DO-254 (hardware) serve analogous roles to ISO 26262 Parts 6 and 5 respectively in aviation, both establishing Design Assurance Levels (DAL A–E) through rigorous lifecycle evidence. ISO 26262 was influenced by the aviation safety case model but introduces automotive-specific concepts including ASIL decomposition and hardware architectural metrics.
Rail Parallels
- EN 50128 (software for railway control and protection systems) and IEC 62279 serve the same function for railway electronics, using SIL 1–4 classifications that map roughly to ASIL A–D.
Regulatory Status
- ISO 26262 is not directly mandated by law in most jurisdictions but is referenced in UN ECE WP.29 regulations (particularly UNECE Regulation 155 on cybersecurity and 156 on software updates) and in NHTSA guidance. In practice, OEM supply agreements universally require it for safety-critical systems, making it effectively mandatory for market access.
Challenges and Evolution
AI and Machine Learning
- Traditional ISO 26262 assumes deterministic, requirement-specified software verifiable through structural testing — a model fundamentally incompatible with Machine Learning Safety and deep neural network-based perception. The standard does not provide guidance on training data quality, distribution shift, or emergent failure modes.
- PAS 8800 and SOTIF (ISO 21448 (SOTIF)) are the community’s current response, but no consensus on a complete ML safety argument within the ISO 26262 framework exists as of 2026.
Complexity of Modern SoCs
- ASIL D multi-core SoCs (e.g., Automotive Embedded Systems using Arm Cortex-R clusters with lockstep) create interference analysis challenges: spatial and temporal resource partitioning (Freedom from Interference, FFI) must be demonstrated, a significant engineering burden.
Cybersecurity Interaction
- Automotive Cybersecurity threats can introduce hazardous states that ISO 26262 functional safety mechanisms were not designed to detect or mitigate. The interaction between security and safety is an active area: a successful cyberattack that disables AEB is both a security incident and a safety concern.
Supply Chain Depth
- Modern vehicles contain contributions from hundreds of Tier 2 and Tier 3 suppliers. Coordinating ASIL-appropriate evidence across deep supply chains, especially for software reuse and COTS components, remains a practical challenge.