ISO 26262 Part 9 ASIL Decomposition, DFA & Safety Analysis Explained

Hello, automotive safety architects and functional safety analysts! Welcome to the ninth deep-dive post in our comprehensive ISO 26262 series at PiEmbSysTech. In this article, we will explore ISO 26262 Part 9 – ASIL-Oriented and Safety-Oriented Analyses, covering two of the most powerful and most frequently misapplied techniques in the entire standard: ASIL decomposition and Dependent Failure Analysis (DFA).

ASIL decomposition allows engineers to reduce the development rigor (and cost) of individual components by distributing a high-ASIL safety requirement across multiple independent architectural elements. DFA is the analytical technique that validates whether those elements are truly independent – by systematically examining potential common cause failures and cascading failures that could invalidate the independence assumption. Together, these two concepts form the analytical backbone of safety architecture design in ISO 26262.

Get these right, and you can build cost-effective safety architectures that meet the highest ASIL requirements with optimized development effort. Get them wrong, and you may have a system that looks safe on paper but has hidden dependent failure paths that could lead to a safety goal violation in the field. Let us explore every aspect.

ISO 26262 Part 9 ASIL Decomposition Table of Contents

1. What is ISO 26262 Part 9 and What Does It Cover?

ISO 26262 Part 9: ASIL-Oriented and Safety-Oriented Analyses specifies the requirements for two categories of analytical activities that support the safety architecture design: ASIL decomposition (requirements decomposition with respect to ASIL tailoring) and safety-oriented analyses (including dependent failure analysis). These activities apply across all levels of development – system, hardware, and software – and provide the analytical evidence that safety architectural decisions are valid.

Part 9 is not a standalone development phase – it operates in conjunction with Parts 3 through 6, providing the analytical methods that validate architectural decisions made during concept, system, hardware, and software development. Its outputs are critical inputs to the safety case, particularly when redundant architectures or mixed-ASIL designs are employed.

2. Structure of Part 9 – The Two Pillars

ISO 26262-9:2018 contains two major normative clauses:

Clause 5: Requirements Decomposition with Respect to ASIL Tailoring – Defines the rules, prerequisites, and constraints for ASIL decomposition – the method of reducing the ASIL of individual safety requirements by distributing them across sufficiently independent redundant elements.

Clause 6: Criteria for Coexistence of Elements – Specifies the requirements for ensuring freedom from interference when elements with different ASIL levels (or QM and ASIL elements) coexist within the same system.

Clause 7: Analysis of Dependent Failures – Specifies the requirements for identifying and evaluating dependent failures — common cause failures and cascading failures – that could invalidate independence assumptions or freedom from interference claims.

Additionally, Annex C provides an informative classification of coupling factors (potential root causes of dependent failures) at system, hardware, software, and semiconductor levels.

3. ASIL Decomposition – The Concept and Purpose

ASIL decomposition is the apportioning of redundant safety requirements to elements, with sufficient independence, conducive to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements allocated to the corresponding elements. In simpler terms: if you implement the same safety function through two (or more) independent channels, you can develop each channel to a lower ASIL than the original requirement – because the probability that both channels fail simultaneously is much lower than the probability that a single channel fails.

The fundamental insight behind ASIL decomposition is that redundancy reduces risk. If a safety goal requires ASIL D (the highest rigor), and the system architecture implements this safety function through two truly independent channels, then even if one channel fails, the other still maintains the safety function. The combined system provides ASIL D protection, even though each individual channel is developed to a lower ASIL.

The economic motivation is significant: developing a component to ASIL D is substantially more expensive than developing it to ASIL B – requiring more rigorous methods, more extensive testing (including MC/DC coverage), more demanding hardware metrics, and more independent confirmation measures. If ASIL decomposition can allow the same level of vehicle-level safety to be achieved with components developed to lower individual ASILs, the cost savings can be enormous.

4. ASIL Decomposition Rules and Valid Combinations

ISO 26262 Part 9, Clause 5 defines the specific decomposition rules that determine which ASIL combinations are valid. The decomposition follows a defined scheme where the original ASIL is split across two (or sometimes three) sufficiently independent elements:

Original ASIL	Decomposition into 2 Elements	Decomposition into 3 Elements
ASIL D	ASIL D(D) + ASIL QM(D) ASIL C(D) + ASIL A(D) ASIL B(D) + ASIL B(D)	ASIL B(D) + ASIL A(D) + ASIL A(D) ASIL A(D) + ASIL A(D) + ASIL A(D) + QM(D)
ASIL C	ASIL C(C) + ASIL QM(C) ASIL B(C) + ASIL A(C) ASIL A(C) + ASIL A(C)	ASIL A(C) + QM(C) + QM(C)
ASIL B	ASIL B(B) + ASIL QM(B) ASIL A(B) + ASIL A(B)	ASIL A(B) + QM(B) + QM(B)
ASIL A	ASIL A(A) + ASIL QM(A)	–

The key principle is that the sum of the decomposed ASILs must equal or exceed the original ASIL in terms of total risk reduction capability. The most commonly used decomposition in industry is ASIL D → ASIL B(D) + ASIL B(D), which provides a balanced split that avoids both extremes and allows both channels to share the same development methodology.

5. ASIL Decomposition Notation – Understanding the (D) Suffix

When ASIL decomposition is applied, the resulting ASIL is annotated with the original ASIL in parentheses. For example, ASIL B(D) means: “This element is developed to ASIL B development methods, but it was decomposed from an original ASIL D requirement.” The “(D)” suffix is critical because it carries important implications.

Confirmation measures remain at the original ASIL level. Even though the element is developed to ASIL B methods, the confirmation measures (reviews, audits, assessments) must still be performed at the independence level required for ASIL D. This is a frequently overlooked requirement that catches many organizations by surprise.

Random hardware failure targets are NOT reduced by decomposition. ASIL decomposition applies to systematic failure requirements (development methods, testing rigor, coding standards) but does NOT apply to the random hardware failure requirements per Part 5 (SPFM, LFM, PMHF). The hardware metric targets remain at the original ASIL D level for both channels. This is logical because the probabilistic combination of random failures across two channels must still achieve the original ASIL D target for the overall safety goal.

6. Worked Example: ASIL D Decomposition for an EPS System

Consider our EPS system with Safety Goal SG1: “Prevent unintended steering torque application” [ASIL D]. Without decomposition, the entire EPS system – every hardware component and every software module that contributes to SG1 – must be developed to ASIL D rigor. This means MC/DC software coverage, 99% SPFM, 90% LFM, PMHF < 10 FIT, and I2/I3 independence for confirmation measures.

With ASIL decomposition using the ASIL D → ASIL B(D) + ASIL B(D) scheme, the system architecture is designed with two sufficiently independent channels. Channel 1 (Primary Processing Channel) implements the main EPS control algorithm with torque sensor input, motor control output, and primary fault detection. Developed to ASIL B(D). Channel 2 (Safety Monitoring Channel) implements independent monitoring of the motor current, torque sensor plausibility, and an independent safe state activation path (motor relay control). Developed to ASIL B(D).

Each channel is developed to ASIL B methods (branch coverage for software instead of MC/DC, less stringent architectural notation requirements, etc.), resulting in significant cost savings. However, both channels together must achieve the ASIL D hardware metric targets, and confirmation measures must still be performed at ASIL D independence levels. Additionally, the two channels must be demonstrated to be sufficiently independent through a thorough Dependent Failure Analysis – which brings us to the second pillar of Part 9.

7. Prerequisites for Valid ASIL Decomposition

ASIL decomposition is not a free lunch – it comes with strict prerequisites that must be satisfied for the decomposition to be valid:

Sufficient independence between the decomposed elements: The elements must be independent with respect to common cause failures and free from cascading failures. This independence must be demonstrated through a Dependent Failure Analysis (Clause 7). Without proven independence, the decomposition is invalid.

Redundant implementation of the safety requirement: Both elements must independently contribute to the same safety goal. If one element fails, the other must be capable of maintaining or achieving the safe state on its own.

Confirmation measures at the original ASIL level: As noted above, the independence requirements for confirmation reviews, functional safety audits, and functional safety assessments remain at the original (pre-decomposition) ASIL level.

Hardware metrics at the original ASIL level: SPFM, LFM, and PMHF targets are NOT reduced by decomposition – they remain at the original ASIL level for the overall item.

8. Benefits and Cost Implications of ASIL Decomposition

The primary benefit of ASIL decomposition is cost reduction in development. The most significant savings come from reduced software testing effort (branch coverage instead of MC/DC for ASIL B vs ASIL D can reduce testing effort by 30–50%), less stringent development method requirements (less formal architectural notations, less rigorous static analysis requirements), the ability to reuse existing QM or lower-ASIL components in one channel while developing only the monitoring channel to the decomposed ASIL, and more flexible staffing (engineers with ASIL B experience can be assigned to decomposed elements without requiring ASIL D-specific training).

An additional architectural benefit is that the decomposed design is inherently more robust than a single-channel design – because it has redundancy built in. Even if ASIL decomposition was not applied (i.e., both channels were developed to ASIL D), the dual-channel architecture provides fault tolerance that a single-channel design does not.

9. Limitations and What Decomposition Does NOT Reduce

Organizations often overestimate the benefits of ASIL decomposition by overlooking what is NOT reduced. Hardware metric targets (SPFM, LFM, PMHF) remain at the original ASIL. Confirmation measure independence requirements remain at the original ASIL. The need for DFA is added (not reduced) – demonstrating independence requires additional analysis effort that would not be needed without decomposition. The total system complexity increases – two channels plus the infrastructure to ensure their independence can sometimes cost more than a single ASIL D channel, particularly for simpler systems. Hardware cost may increase due to the need for physically independent hardware elements (separate processors, separate sensors, separate power supplies).

ASIL decomposition is most cost-effective for complex software-intensive systems where the software testing cost dominates the total development cost. For simpler systems where hardware cost dominates, the additional hardware required for redundancy may offset the software development savings.

10. Dependent Failures – The Hidden Danger

Dependent failures are failures whose simultaneous or successive occurrence cannot be expressed as the simple product of their individual unconditional probabilities. In other words, they are failures that are statistically correlated – the occurrence of one failure makes the occurrence of another more likely (or certain). ISO 26262 recognizes two types of dependent failures: common cause failures (CCF) and cascading failures.

Dependent failures are the fundamental threat to any redundant architecture. If two supposedly independent channels can both fail due to a single shared root cause, the redundancy provides no protection – and the ASIL decomposition claim is invalid. This is why DFA is so critical: it systematically searches for hidden dependencies that could undermine the safety architecture.

11. Common Cause Failures (CCF) Explained

A common cause failure occurs when a single event or root cause simultaneously affects two or more elements, causing them to fail. The key characteristic is that the failures share a common origin. Examples include a power supply failure that simultaneously disables both the primary processing channel and the safety monitoring channel (both depend on the same power supply), an electromagnetic interference (EMI) event that simultaneously corrupts data in both processing channels (both are susceptible to the same frequency), a manufacturing defect in a batch of identical components used in both channels (homogeneous redundancy with shared manufacturing process), a software defect that is replicated in both channels (if both channels use the same software or the same algorithms), and an environmental condition (extreme temperature, flooding) that simultaneously exceeds the operating limits of both channels.

CCFs are particularly insidious because they defeat redundancy. Two identical sensors from the same production batch, mounted in the same physical location, exposed to the same environmental conditions, and processed by the same software algorithm, provide very little true independence – even though they appear to be “redundant” in the block diagram.

12. Cascading Failures Explained

A cascading failure occurs when the failure of one element causes the failure of another element. Unlike CCF (where both failures have a common external cause), cascading failures have a causal chain: Element A fails first, and A’s failure propagates to cause Element B to fail. Examples include a software element entering an infinite loop that consumes all CPU resources, preventing a safety monitoring task from executing (the application software failure cascades to disable the safety monitor), a short circuit in a non-safety component that draws excessive current, causing the shared power supply voltage to drop below the operating threshold of a safety-critical component, a QM software component writing to a memory location that belongs to an ASIL software component (corrupting safety-critical data), and a faulty sensor generating erratic output that causes a safety-critical algorithm to produce incorrect results.

Cascading failures are directly related to freedom from interference – if a lower-ASIL or QM element can cause a safety-related failure in a higher-ASIL element, freedom from interference is not achieved.

13. Freedom from Interference (FFI) – What It Really Means

Freedom from interference is the absence of cascading failures between elements that leads to the violation of a safety requirement or safety goal. FFI is specifically about cascading failures only – it does not include common cause failures. This distinction is important and frequently confused.

FFI is particularly critical in mixed-ASIL systems – where elements with different ASIL levels (or QM and ASIL elements) coexist on the same hardware platform. The concern is that a failure in a QM element could cascade into an ASIL element and cause a safety goal violation. Part 9, Clause 6 requires that when elements of different ASILs coexist, FFI must be ensured for the higher-ASIL element – meaning the lower-ASIL element cannot interfere with the correct operation of the higher-ASIL element.

FFI is typically achieved through partitioning mechanisms – physical or logical barriers that prevent fault propagation between elements. In software, this includes memory protection (MPU/MMU preventing QM software from writing to ASIL memory regions), temporal protection (ensuring QM tasks cannot consume the CPU time budget allocated to ASIL tasks), and communication data validation (checking integrity of data received from lower-ASIL sources before using it in ASIL functions). In hardware, this includes separate power supply domains, physical isolation of signal paths, and galvanic isolation between channels.

14. Independence vs Freedom from Interference – The Critical Distinction

These two concepts are related but distinct, and confusing them is a common error:

Freedom from Interference (FFI): Addresses cascading failures only. FFI means that a failure in Element A cannot cascade to cause a failure in Element B that violates a safety requirement. FFI is required whenever elements of different ASIL levels coexist (Part 9, Clause 6).

Independence: Addresses both cascading failures AND common cause failures. Independence means that the elements are free from all dependent failures – both cascading failures and common cause failures – that could lead to safety goal violations. Independence is required for ASIL decomposition (Part 9, Clause 5) – because the decomposition claim depends on both channels being truly independent.

In mathematical terms: Independence = FFI + Absence of CCFs leading to safety goal violations. Independence is a stricter requirement than FFI alone. Achieving FFI is necessary but not sufficient for claiming independence.

15. Dependent Failure Analysis (DFA) Process

The Dependent Failure Analysis (DFA) is the systematic process of identifying and evaluating dependent failures to validate independence claims (for ASIL decomposition) and freedom from interference claims (for mixed-ASIL coexistence). The DFA process includes identifying the elements between which independence or FFI must be demonstrated (based on the safety architecture and ASIL decomposition decisions), identifying potential dependent failure initiators (DFIs) – the root causes that could trigger dependent failures, evaluating each DFI to determine whether it could cause a dependent failure (CCF or cascading failure) that violates a safety goal, and specifying safety measures to mitigate any identified dependent failure risks.

16. Coupling Factors – Root Causes of Dependent Failures

Coupling factors are the mechanisms through which a single root cause can affect multiple elements simultaneously (leading to CCF) or through which a failure in one element can propagate to another (leading to cascading failures). ISO 26262-9:2018, Annex C provides a classification of coupling factors at four levels:

System-level coupling factors: Shared power supply, shared communication bus, shared clock source, shared environmental exposure (temperature, vibration, EMI), shared physical mounting location, shared manufacturing process or batch.

Hardware-level coupling factors: Shared silicon die (for multi-channel ICs), shared PCB substrate, shared solder process, shared component supplier/batch, shared failure physics (electromigration, TDDB), shared thermal domain.

Software-level coupling factors: Shared operating system, shared scheduler, shared memory space (without protection), shared libraries or drivers, shared algorithms (homogeneous software redundancy), shared compiler/toolchain (which could introduce identical systematic errors), shared development team (same team may make similar systematic mistakes in both channels).

Semiconductor-level coupling factors: Shared power domains on the die, shared clock distribution network, shared memory controller, shared bus fabric, shared I/O pads, common vulnerability to environmental stress (latch-up, soft errors).

The DFA must systematically evaluate each relevant coupling factor for every pair of elements that requires independence or FFI, and determine whether it could lead to a dependent failure that violates a safety requirement.

17. DFA Methods – How to Identify Dependent Failures

ISO 26262 does not prescribe a single specific method for performing DFA, but several approaches are commonly used. Coupling factor checklist analysis systematically reviews each coupling factor category from Annex C against the system architecture, evaluating whether each factor applies and whether adequate mitigation is in place. FTA cut-set analysis examines the cut sets (minimal combinations of basic events that cause the top event) of the system’s fault tree – repeated events or correlated events in different cut sets indicate potential dependent failures. FMEA extension extends the system FMEA by adding columns to identify common parts, similar failure modes, or shared resources that could create dependencies. Expert review engages experienced safety engineers to review the architecture and identify potential dependencies based on engineering judgment and domain expertise.

The most thorough approach combines multiple methods – using the coupling factor checklist as the primary systematic framework, supplemented by FTA cut-set analysis for quantitative validation and expert review for coverage of non-obvious dependencies.

18. Safety Measures Against Dependent Failures

When the DFA identifies potential dependent failures, safety measures must be specified to mitigate them. Common safety measures against dependent failures include diversity (using different technologies, different algorithms, different suppliers, or different design teams for the two channels – reducing the probability that a systematic error or manufacturing defect affects both), physical separation (locating redundant elements in different physical positions on the PCB, different enclosures, or different vehicle locations – reducing shared environmental exposure), independent power supplies (providing separate, independently regulated power domains for each channel), independent clock sources (using separate oscillators or clock generators for each channel), memory protection and partitioning (using MPU/MMU hardware to enforce isolation between software elements), independent communication paths (using separate communication buses or channels), and testing and inspection (specific tests or inspections during production to detect batch-related defects).

Each safety measure must be documented in the DFA report with evidence of its effectiveness in mitigating the specific dependent failure risk it addresses.

19. DFA at Hardware, Software, and System Levels

DFA must be performed at all relevant levels of the design hierarchy. At the system level, DFA evaluates dependencies between system elements – shared power supplies, shared communication buses, shared environmental exposures, and other system-level coupling factors. At the hardware level, DFA evaluates dependencies between hardware components – shared silicon, shared PCB traces, shared manufacturing processes, and semiconductor-level coupling factors. This is particularly important for semiconductor-level analysis under Part 11. At the software level, DFA evaluates dependencies between software elements – shared operating system resources, shared memory spaces, shared execution timing, and shared libraries. Software-level DFA is closely linked to freedom from interference analysis for mixed-ASIL software partitions.

The DFA results at each level feed into the overall safety case and provide the evidence that the independence and FFI assumptions made in the safety architecture are valid.

20. Key Work Products of Part 9

Part 9 produces the following essential work products: ASIL decomposition documentation (the decomposition scheme, the allocated ASILs for each element, the rationale, and the identification of the independence requirements), Dependent Failure Analysis report (the systematic evaluation of coupling factors, identified dependent failure risks, and the safety measures specified to mitigate them), Freedom from Interference analysis report (evidence that cascading failures between mixed-ASIL elements are prevented or controlled), and safety analysis reports (FMEA, FTA, or other analyses that support the DFA findings). These work products are critical components of the safety case and are subject to confirmation review at the independence level corresponding to the original (pre-decomposition) ASIL.

21. Common Mistakes and How to Avoid Them

Mistake 1: Performing ASIL decomposition without adequate DFA. Decomposing an ASIL D requirement into ASIL B(D) + ASIL B(D) without a thorough DFA that demonstrates genuine independence is the most common and most dangerous error. The decomposition claim is only valid if independence is proven.

Mistake 2: Assuming physical separation equals independence. Placing two sensors on opposite sides of the PCB does not automatically make them independent. They may still share the same power supply, the same clock, the same software processing path, or the same vulnerability to a specific EMI frequency. Independence must be evaluated across all coupling factor categories.

Mistake 3: Forgetting that confirmation measures stay at the original ASIL. Teams frequently develop both decomposed channels to the lower ASIL methods (which is correct) but then also perform confirmation reviews and assessments at the lower ASIL independence level (which is incorrect). Confirmation measures must remain at the original ASIL.

Mistake 4: Applying decomposition to hardware metrics. SPFM, LFM, and PMHF targets are NOT reduced by ASIL decomposition. The hardware metrics must still meet the original ASIL targets for the overall item. This is explicitly stated in the standard but frequently overlooked.

Mistake 5: Confusing FFI with independence. Achieving freedom from interference (no cascading failures) is necessary but not sufficient for independence (which also requires absence of common cause failures). Organizations that demonstrate FFI but neglect CCF analysis do not have a valid independence claim for ASIL decomposition.

Mistake 6: Using homogeneous redundancy and claiming independence. Two identical hardware channels using the same components, same design, same software, and same manufacturing process have significant common cause failure potential. Diversity (different technologies, different designs, different suppliers) is typically needed to achieve genuine independence for higher ASIL decompositions.

22. Frequently Asked Questions

Q1: Can I decompose ASIL D all the way down to QM?

Yes, technically ASIL D can be decomposed as ASIL D(D) + QM(D). However, this means one channel must still be developed to full ASIL D rigor (including MC/DC, 99% SPFM, etc.), while the other is developed to QM. The QM channel still requires independence demonstration and confirmation measures at ASIL D level. This decomposition is useful when a simple, independent monitoring function (QM channel) supervises a complex ASIL D primary function.

Q2: How do I prove “sufficient independence” for ASIL decomposition?

Through a Dependent Failure Analysis (DFA) that systematically evaluates all coupling factor categories (from Annex C) between the decomposed elements, identifies any potential common cause failures or cascading failures, and either demonstrates that no dependent failures can violate the safety goal or specifies safety measures that adequately mitigate the identified risks. The DFA report is the primary evidence of sufficient independence.

Q3: Does ASIL decomposition apply to software-only requirements?

Yes, ASIL decomposition can be applied at any level – system, hardware, or software. In software, decomposition typically involves implementing redundant software functions in separate, independent software partitions with FFI enforced through memory and temporal protection. However, achieving genuine independence in software is challenging because software elements often share the same processor, OS, and compiler – all of which are coupling factors.

Q4: What is the relationship between DFA and FMEDA?

FMEDA (Part 5) evaluates random hardware failures and the effectiveness of safety mechanisms – it classifies individual fault modes and calculates hardware metrics. DFA (Part 9) evaluates dependent failures – correlated failures that affect multiple elements simultaneously. FMEDA assumes independence between elements; DFA validates that assumption. Both analyses are required for a complete safety evaluation, and their results must be consistent.

Q5: Can DFA be automated?

Partially. The coupling factor checklist analysis can be structured in spreadsheet or database tools. FTA cut-set analysis can be automated using FTA software tools. However, the evaluation of each coupling factor’s relevance and the adequacy of safety measures typically requires engineering judgment and domain expertise that cannot be fully automated. The DFA is inherently an expert-driven analysis.

Q6: Is DFA only needed when ASIL decomposition is applied?

No. DFA is also required whenever elements of different ASIL levels coexist within the same system (to demonstrate freedom from interference per Clause 6), even without ASIL decomposition. Any mixed-ASIL system – which is virtually every modern automotive ECU – requires DFA to validate FFI between the ASIL and QM elements.

23. Conclusion

ISO 26262 Part 9 – ASIL-Oriented and Safety-Oriented Analyses provides the analytical framework that enables cost-effective safety architectures through ASIL decomposition while ensuring that these architectures are genuinely safe through Dependent Failure Analysis. The interplay between decomposition (which reduces development rigor) and DFA (which validates the independence assumptions that make decomposition legitimate) is one of the most intellectually demanding and practically important aspects of automotive functional safety engineering.

Mastering Part 9 requires a deep understanding of safety architecture principles, a systematic approach to identifying coupling factors and dependent failure paths, and the engineering judgment to evaluate whether the identified risks are adequately mitigated. Organizations that invest in building this expertise can design safety architectures that are both cost-effective and genuinely safe – achieving the optimal balance between development efficiency and vehicle-level safety.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. Next in our series: ISO 26262 Parts 10, 11, and 12 – the guidelines, semiconductor application, and motorcycle adaptation parts. Be sure to review our earlier posts on Part 1 through Part 8.

Stay safe. Stay independent. Keep engineering the future.

– The PiEmbSysTech Team