ISO 26262 — Automotive functional safety
Learn how the automotive safety lifecycle connects hazardous vehicle behaviour to ASILs, system architecture, hardware, software and production evidence.
After this module, you should be able to:
- Describe the item-based automotive safety lifecycle
- Explain HARA and Automotive Safety Integrity Levels
- Relate technical safety concepts to hardware and software
- Recognise freedom-from-interference and confirmation measures
Automotive functional safety begins with hazardous vehicle behaviour.
ISO 26262 adapts functional-safety principles to series-production road vehicles. The lifecycle begins with an item definition and hazard analysis and risk assessment (HARA), then develops functional and technical safety concepts before hardware and software realisation.
Automotive Safety Integrity Levels (ASIL A to D) classify the rigour associated with safety goals; QM denotes risk addressed by normal quality management. ASIL determination considers severity, exposure and controllability. It does not measure feature importance or component quality.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Concept phase | What is the item, its environment and hazardous behaviour? | Item definition, HARA and safety goals |
| System design | How are functional goals refined and allocated? | Functional and technical safety concepts |
| Hardware | Are architectural metrics, failure rates and diagnostics adequate? | Hardware safety analysis and verification |
| Software | Are architecture, implementation and verification appropriate to ASIL? | Software safety lifecycle evidence |
| Supporting processes | How are configuration, change, tools and suppliers controlled? | Plans, qualification and confirmation records |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Define the item, vehicle interfaces, modes and dependencies
- 2. Identify hazardous events from malfunctioning behaviour
- 3. Classify severity, exposure and controllability; assign safety goals
- 4. Develop functional and technical safety requirements with safe states and timing
- 5. Allocate requirements with independence or justified decomposition
- 6. Verify each level, validate at vehicle level and maintain production and field feedback
Worked application: unintended steering assist
The HARA considers operating situations and the driver’s ability to control unintended torque. A safety goal is refined into torque limits, monitoring, power-stage shutdown and diagnostic timing. Hardware and software teams must show freedom from interference where mixed-criticality functions share the MCU.
Build evidence that explains the reasoning.
Lifecycle, tailoring, responsibilities and confirmation measures.
Functions, boundaries, assumptions and vehicle context.
Hazardous events, classifications and safety goals.
Functional and technical requirements with allocation.
Dependent failures, hardware metrics and software faults.
Structured argument linking goals, design and evidence.
Common failure patterns
A component is assigned an ASIL without allocated safety requirements.
Analysis starts with component faults rather than vehicle hazards.
Redundancy is claimed without sufficient independence.
Production variation and operational monitoring are omitted.
Further learning
- ISO 26262-1:2018Official ISO entry for the vocabulary part of the road-vehicle functional-safety series.
- TEA-201 · Systems engineers and architectsSystem allocation, interfaces and assurance evidence.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.