ISO 26262-9:2018 — Functional Safety — ASIL-Oriented and Safety-Oriented Analyses

1. Introduction to ASIL-Oriented and Safety-Oriented Analyses

ISO 26262-9:2018 is a pivotal part of the ISO 26262 functional safety standard series, addressing the analytical methods and techniques used to manage Automotive Safety Integrity Levels (ASILs) and perform safety analyses throughout the development lifecycle. This part provides the structured framework for ASIL decomposition, criteria for coexistence of elements with different ASILs, dependent failure analysis (DFA), and comprehensive safety analyses including FMEA, FTA, HAZOP, and Markov modelling.

The standard addresses four interconnected domains, each building upon the previous: ASIL decomposition allows safety requirements to be allocated across redundant elements; coexistence criteria ensure that elements with different ASILs can share the same system without interference; dependent failure analysis validates the independence assumptions underlying decomposition and coexistence; and safety analyses provide the quantitative and qualitative evidence for overall risk reduction.

2. ASIL Decomposition and Coexistence

2.1 ASIL Decomposition (Clause 5)

ASIL decomposition is a powerful technique for safety requirement allocation. It allows a safety requirement with a given ASIL to be decomposed into redundant safety requirements at the next level of detail, allocated to sufficiently independent design elements. The permitted decomposition schemas are precisely defined:

• ASIL D → ASIL C(D) + ASIL A(D), or ASIL B(D) + ASIL B(D), or ASIL D(D) + QM(D)
• ASIL C → ASIL B(C) + ASIL A(C), or ASIL C(C) + QM(C)
• ASIL B → ASIL A(B) + ASIL A(B), or ASIL B(B) + QM(B)
• ASIL A → ASIL A(A) + QM(A)

A critical constraint: evaluation of hardware architectural metrics and safety goal violations due to random hardware failures remains unchanged by ASIL decomposition. This means that even if an ASIL D requirement is decomposed to ASIL B(D) + ASIL B(D), the hardware metrics must still be evaluated against ASIL D targets.

2.2 Criteria for Coexistence (Clause 6)

When safety-related sub-elements with different ASILs (or non-safety sub-elements) coexist in the same element, Clause 6 provides the analytical framework for determining whether they can be developed at their respective ASILs rather than being elevated to the highest ASIL present. The key concept is freedom from interference: a lower-ASIL sub-element must not cause cascading failures that violate a safety requirement allocated to a higher-ASIL sub-element. This is demonstrated through analysis of data flow, control flow, input/output signals, and other design measures.

3. Dependent Failure Analysis

Clause 7 establishes requirements for demonstrating independence between elements — a prerequisite for both ASIL decomposition and coexistence. The analysis must consider both cascading failures (failure propagation from one element to another) and common cause failures (a single event causing multiple elements to fail simultaneously).

The standard identifies nine coupling factor classes that analysts must evaluate:

• Shared resources: Power supply, clock, data bus, wiring harness
• Shared information inputs: External messages, sensor readings
• Insufficient environmental immunity: EMI, ESD, temperature, vibration
• Systematic coupling: Common development tools, identical production processes
• Identical component types: Same microcontroller, same actuator type
• Communication: CAN, FlexRay, inter-microcontroller links
• Unintended interfaces: Crosstalk, memory leaks, thermal coupling

4. Safety Analyses

4.1 Qualitative and Quantitative Methods

Clause 8 provides the overarching framework for safety analyses, which serve multiple purposes: identifying new hazards, verifying safety concepts, supporting safety measure definition, and providing evidence for the safety case. The standard distinguishes between:

• Qualitative analyses: FMEA (system, design, process), FTA, HAZOP, ETA — used to identify failure modes and their causes without quantifying probabilities.
• Quantitative analyses: Quantitative FMEA/FTA, Markov models, reliability block diagrams — used to evaluate hardware architectural metrics and probability of safety goal violation due to random hardware failures.

4.2 Analysis Methods Classification

Safety analyses are further classified by methodology: inductive methods (bottom-up, from causes to effects) include FMEA and ETA; deductive methods (top-down, from effects to causes) include FTA and RBD. The standard explicitly recommends combining inductive and deductive approaches for comprehensive coverage.

For single-point fault and latent fault coverage, the analysis method must be capable of identifying multiple-point faults. The depth and rigor of the analysis must be commensurate with the ASIL — higher ASILs demand more thorough analysis, broader fault models, and stronger verification of results.

5. Engineering Design Insights for ISO 26262-9 Implementation

• DFA as a design tool: Rather than treating dependent failure analysis as a documentation exercise, integrate it into the architectural design phase. Early DFA review of candidate architectures can identify coupling issues before detailed design commitments are made.
• ASIL decomposition strategy: Prefer ASIL B(D) + ASIL B(D) for safety-critical systems — it provides balanced redundancy without creating an excessively weak link (QM-assigned elements are often difficult to control in practice).
• Freedom from interference evidence: For software coexistence, consider memory partitioning (MPU/MMU-based), time-triggered scheduling, and independent stack monitoring as evidence measures. Hardware coexistence typically relies on physical separation, galvanic isolation, and independent voltage domains.
• Checklist-driven DFA: Develop a company-specific DFA checklist based on Annex C, extended with lessons learned from field returns and previous assessments. This institutionalises knowledge and ensures consistency across projects.
• Quantitative analysis tooling: Invest in integrated FMEA/FTA tools that support automatic cut set analysis, common cause failure modelling (with beta factor estimation), and seamless connection to hardware failure rate databases (IEC 62380, SN 29500).

6. Frequently Asked Questions