ISO 26262 functional safety

Scope and structure

ISO 26262 addresses functional safety for electrical and electronic (E/E) systems within road vehicles, covering the full safety lifecycle from concept through production, operation, service and decommissioning. It is organised as a multi-part standard covering management, concept phase, system-level, hardware-level and software-level requirements, supporting processes, and ASIL-oriented and safety-oriented analyses. Its scope is systems, not entire vehicles, and it explicitly addresses hazards arising from malfunctioning behaviour rather than all safety hazards a vehicle might present.

ASIL classification

Automotive Safety Integrity Levels (ASIL A to D, plus QM for hazards not requiring ISO 26262 measures) are derived from a hazard analysis and risk assessment considering severity, exposure and controllability of a potential hazardous event. ASIL D represents the highest integrity requirement. A common misunderstanding is treating ASIL as a property of a component in isolation; it is a property of a specific hazardous event associated with a specific function, and the same component can carry different ASILs in different functional contexts.

• Severity: the potential harm to people if the hazard occurs.
• Exposure: the probability of the operational situation that would make the hazard relevant.
• Controllability: the likelihood that the driver or other actors can avoid harm if the hazard occurs.
• ASIL decomposition allows a requirement to be split across independent elements to reduce the ASIL each must individually meet, provided independence can be demonstrated.

The safety lifecycle in practice

The standard's V-model structure ties each level of specification (system, hardware, software) to a corresponding level of verification, with the safety requirements flowing down from the hazard analysis and the verification evidence flowing back up to confirm they were met. In practice, the discipline that determines whether this works is traceability: every safety requirement must be traceable to the hazard it addresses, to the design element implementing it, and to the test or analysis that verifies it. Gaps in this chain are the most common finding in an ISO 26262 assessment.

Common failure modes

• Hazard analysis performed once early in the programme and not revisited as the design changes, leaving ASIL assignments stale.
• Safety requirements written at a level too abstract to verify, producing verification activities that cannot demonstrate the requirement was actually met.
• ASIL decomposition claimed without adequate evidence of independence between the decomposed elements.
• Software unit and integration testing that achieves structural coverage targets without demonstrating the safety requirement itself was exercised.
• Confirmation measures (safety audits, assessments, confirmation reviews) treated as end-of-project formalities rather than ongoing checks.

What a safety case needs to demonstrate

A safety case built for ISO 26262 needs to show a defensible argument, supported by evidence, that the item is acceptably safe for its intended function and operating context. Assessors expect to see the hazard analysis and risk assessment, the safety requirements derived from it with clear ASIL assignment and rationale, the architecture and its safety mechanisms, verification results tied to specific requirements, and a record of confirmation measures including independent assessment appropriate to the ASIL. Where independence requirements apply — for example, independent assessment for higher ASILs — assessors will check that the independence was real, not organisational in name only.

Practical steps for a new or evolving programme

• Define item boundaries and operational context precisely before starting hazard analysis, since ambiguity here propagates through every later step.
• Keep the hazard analysis and risk assessment as a living artefact, revisited at defined change points, not a one-time deliverable.
• Establish traceability tooling early; retrofitting traceability across hundreds of requirements late in a programme is one of the most expensive corrections to make.
• Plan confirmation measures and independence requirements against the programme schedule, since qualified assessors and reviewers are a scarce resource.
• Treat software tool qualification and component qualification (for reused or purchased elements) as a distinct workstream with its own evidence requirements.

Frequently asked questions