Skip to content

ISO 26262: Automotive Functional Safety

ISO 26262:2018 is the functional safety standard for electrical and electronic systems in road vehicles. It adapts the general principles of IEC 61508 to the specific needs of the automotive industry, covering the entire safety lifecycle from concept through decommissioning.

If you're developing software for any automotive function that could affect vehicle safety — from advanced driver-assistance systems (ADAS) to powertrain control — ISO 26262 compliance is required.

ASIL Determination

ISO 26262 assigns an Automotive Safety Integrity Level (ASIL) to each safety goal based on three factors:

Factor Description Scale
Severity (S) Potential harm to vehicle occupants or other road users S0 (no injuries) – S3 (life-threatening / fatal)
Exposure (E) Probability of the operational situation occurring E0 (incredible) – E4 (high probability)
Controllability (C) Ability of the driver or other persons to control the situation C0 (controllable in general) – C3 (difficult to control)

The combination of S, E, and C determines the ASIL:

C1 C2 C3
S1 + E1 QM QM QM
S1 + E2 QM QM QM
S1 + E3 QM QM ASIL A
S1 + E4 QM ASIL A ASIL B
S2 + E1 QM QM QM
S2 + E2 QM QM ASIL A
S2 + E3 QM ASIL A ASIL B
S2 + E4 ASIL A ASIL B ASIL C
S3 + E1 QM QM ASIL A
S3 + E2 QM ASIL A ASIL B
S3 + E3 ASIL A ASIL B ASIL C
S3 + E4 ASIL B ASIL C ASIL D

QM = Quality Management

QM means standard quality management is sufficient — no additional safety requirements from ISO 26262 apply. ASIL A is the lowest safety level; ASIL D is the most stringent.

Required Deliverables by ASIL Level

The following table shows the documentation rigor required at each ASIL level. Higher ASILs demand more formal methods, more thorough analysis, and more comprehensive testing:

Deliverable QM ASIL A ASIL B ASIL C ASIL D
Technical Safety Requirements — ● ● ● ●
Software Safety Requirements — ● ● ● ●
Software Architecture — ● ● ● ●
Software Unit Design — ○ ● ● ●
Unit Testing — ● ● ● ●
Integration Testing — ● ● ● ●
Requirements-Based Testing — ● ● ● ●
Structural Coverage (statement) — ● ● ● ●
Structural Coverage (branch) — — ● ● ●
Structural Coverage (MC/DC) — — — ○ ●
Back-to-Back Testing — — — ○ ●
FMEA / HARA — ● ● ● ●
Traceability (requirements → tests) — ● ● ● ●
Traceability (bidirectional, all levels) — ○ ● ● ●

● = Required · ○ = Recommended · — = Not required

Artifact Mapping: ISO 26262 → V-Model Extension

ISO 26262 Clause Required Deliverable V-Model Command Output Artifact ID Schema
Part 6, 6.4.2 Software safety requirements requirements requirements.md REQ-NNN
Part 6, 7.4.1 Software architecture architecture-design architecture-design.md ARCH-NNN
Part 6, 7.4.5 Software unit design module-design module-design.md MOD-NNN
Part 6, 8.4.2 Hardware-software interface specification system-design system-design.md SYS-NNN
Part 6, 9.4.1 Software unit verification plan unit-test unit-test.md UTP-NNN-X / UTS-NNN-X#
Part 6, 9.4.2 Software integration test specification integration-test integration-test.md ITP-NNN-X / ITS-NNN-X#
Part 6, 9.4.3 Software requirements-based test specification acceptance acceptance-plan.md ATP-NNN-X / SCN-NNN-X#
Part 6, 9.5 Requirements traceability trace traceability-matrix.md Multi-matrix
Part 9 Hazard Analysis and Risk Assessment (HARA) hazard-analysis hazard-analysis.md HAZ-NNN

System-level testing

For ISO 26262 Part 4 (System Design), use the system-design command to produce IEEE 1016:2009–aligned design views and system-test for corresponding ISO 29119-4 system test procedures (STP-NNN-X / STS-NNN-X#).

ASIL Decomposition (ISO 26262-9 §5)

ISO 26262 allows ASIL decomposition — splitting a high-ASIL safety requirement across multiple independent architectural elements so that each element carries a lower ASIL. The V-Model Extension supports this:

ISO 26262-9 Clause Requirement V-Model Extension Artifact
§5.4.2 ASIL decomposition rationale for architecture elements architecture-design.md — ASIL allocation per ARCH-NNN element
§5.4.3 Independence argument for decomposed elements architecture-design.md — independence justification between modules
§5.4.5 Verification of decomposed safety requirements integration-test.md — ITP-NNN-X procedures validating decomposed ASILs

ASIL decomposition example

An ASIL D requirement can be decomposed into two ASIL B(D) elements, provided the architecture guarantees independence (no common-cause failures, no cascading failures). The architecture-design command documents this decomposition with explicit independence arguments per ARCH-NNN element.

ASIL-D Workflow: Autonomous Emergency Braking

Here's how a team building an ASIL-D system (e.g., Autonomous Emergency Braking — AEB) would use the V-Model Extension:

Step 1 — Configure the domain

# v-model-config.yml
domain: iso_26262
asil_target: D
system_name: "AEB Controller"

Domain configuration

Setting domain: iso_26262 in your v-model-config.yml activates ISO 26262–specific validation rules, terminology, and ASIL-aware artifact generation across all commands.

Step 2 — Generate safety requirements

specify run speckit.v-model.requirements specs/aeb-controller/

Requirements are generated with ISO 26262 terminology and include ASIL allocation metadata. Each REQ-NNN is validated against the 8 IEEE 29148 quality criteria.

Step 3 — Generate architecture with ASIL decomposition

specify run speckit.v-model.architecture-design specs/aeb-controller/

The architecture document includes:

  • ARCH-NNN elements with IEEE 42010 views (Logical, Process, Interface, Data Flow)
  • ASIL allocation per element (e.g., ARCH-001 [ASIL D], ARCH-002 [ASIL B(D)])
  • Independence arguments for decomposed elements
  • Cross-cutting module identification

Step 4 — Generate module designs and all test levels

specify run speckit.v-model.module-design specs/aeb-controller/
specify run speckit.v-model.unit-test specs/aeb-controller/
specify run speckit.v-model.integration-test specs/aeb-controller/
specify run speckit.v-model.acceptance specs/aeb-controller/
specify run speckit.v-model.system-test specs/aeb-controller/

Step 5 — Run HARA (Hazard Analysis and Risk Assessment)

specify run speckit.v-model.hazard-analysis specs/aeb-controller/

The FMEA register uses ASIL-aware severity scales and assesses hazards across multiple operational states (e.g., parking vs. highway driving vs. intersection approach), as required by ISO 26262 Part 3.

Step 6 — Generate the full traceability matrix

specify run speckit.v-model.trace specs/aeb-controller/

For an ASIL-D system, the trace command generates all five matrices:

  • Matrix A: Requirements → Acceptance Tests
  • Matrix B: System Design → System Tests
  • Matrix C: Architecture → Integration Tests (with ASIL decomposition verification)
  • Matrix D: Module Design → Unit Tests
  • Matrix H: Hazards → Mitigations → Verification

Step 7 — Run impact analysis for change control

specify run speckit.v-model.impact-analysis --full REQ-003 specs/aeb-controller/

ISO 26262 Part 8 requires rigorous change management. The impact analysis command traverses the full dependency graph and produces a blast-radius report showing every artifact affected by a change.

Structural Coverage Requirements

ISO 26262 Part 6 specifies structural coverage requirements that increase with ASIL level:

ASIL Statement Coverage Branch Coverage MC/DC Coverage
A ● — —
B ● ● —
C ● ● ○
D ● ● ●

Coverage analysis with V-Model Extension

The unit-test command generates white-box test procedures designed to achieve the required coverage levels. Use the test-results command with --coverage to document actual coverage metrics for the audit trail. For ASIL D, ensure MC/DC coverage is explicitly documented.

Cross-References