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
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-101 and TEA-106. Familiarity with vehicle functions helps; no ASIL is assigned by this lesson.
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.
Start with the vehicle item and hazardous event
ISO 26262 addresses functional safety of road-vehicle electrical and electronic systems. The item definition establishes the function, boundaries, interfaces and operating context used by the safety work. Hazard analysis and risk assessment consider malfunctioning behaviour in operational situations; ASIL determination uses severity, exposure and controllability under the framework.
A component does not acquire an ASIL merely because it is used in a vehicle. The safety goals and their allocated requirements connect the vehicle-level concern to the embedded implementation. Keep the rationale visible so a supplier can understand which behaviour and assumptions its element must support.
For a practical review, contrast unintended actuation with loss of actuation in several operating situations. The same electrical fault may have different consequences when stationary, at speed or during a manoeuvre. Avoid selecting one convenient situation to represent the entire use of the function.
Connect the functional concept to technical allocation
The functional safety concept describes the safety behaviour and its allocation at an appropriate functional level; the technical work realises it through architecture and detailed hardware and software requirements. Preserve timing, fault detection, degraded behaviour and recovery across that translation.
If a supplier element is developed with assumptions about its use, treat those assumptions as integration requirements to verify. The vehicle programme must establish that the actual environment, interfaces and safety mechanisms satisfy them. Reusing an element’s assurance records is not the same as proving suitability in a new item.
Decomposition and independence require a structured argument under the standard. Two channels are not automatically an acceptable decomposition if they share a power supply, sensor, software defect or final actuator that can defeat the safety goal.
| Level | Illustrative question |
|---|---|
| Item | What vehicle function and operating context are in scope? |
| Safety goal | Which hazardous malfunction must be prevented or controlled? |
| Functional concept | What safe or degraded behaviour is required? |
| Technical allocation | Which elements realise detection, response and independence? |
| Integration evidence | Do the supplier assumptions hold in the actual vehicle? |
Control changes beyond the ECU boundary
An ECU software change can alter bus loading, diagnostic timing and behaviour seen by other controllers. Review network, power, calibration and service dependencies as part of the impact. A local passing regression may not cover the vehicle-level effect.
Separate functional-safety scope from complementary concerns such as cybersecurity and intended-function limitations. A system can behave exactly as designed yet perform inadequately in a challenging environment, and an attacker can invalidate assumptions about trusted inputs. Coordinate the relevant analyses rather than using one safety framework as proof of every product property.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Review a supplier steering sensor assumption
A supplier sensor element assumes that the integrating controller detects stale data within 20 ms. The proposed vehicle controller polls the sensor every 50 ms.
- Identify the assumption that the integration does not currently satisfy.
- Propose feasible ways to resolve the mismatch without guessing an ASIL.
- Define the evidence needed at the integrated-function level.
Show the worked answer
A 50 ms polling interval can leave stale data undetected for longer than the supplier’s assumed 20 ms, before additional scheduling or processing delay. The assumption cannot be accepted merely because normal messages usually arrive sooner. Review a faster or event-driven monitoring path, a different sensor or an alternative architecture consistent with the safety concept.
Update the timing allocation and verify stale-data detection and the required vehicle-function response under relevant load and event phase. Include loss, repetition and reset behaviour and check all credited dependencies. The item’s safety assessment and allocated requirements determine the integrity obligations; this mismatch alone does not establish an ASIL.
Review criteria
- The supplier assumption is checked quantitatively.
- Alternatives preserve the safety goal and allocated response.
- Evidence addresses the integrated function.
Check your understanding
Can a supplier assurance package replace integration analysis?
No. The actual use must satisfy its assumptions, interfaces and conditions, with evidence at the integrated level.
Does ISO 26262 cover every reason a vehicle function might be unsafe?
No. Its functional-safety scope must be coordinated with other relevant engineering and assurance activities.
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.