Title: Dependent Failure Analysis (DFA) | ISO 26262 Academy
URL: https://iso26262.academy/features/concepts/dependent-failure-analysis
Description: Dependent failure analysis per ISO 26262-9: find the initiators and coupling factors that let one root cause defeat redundant channels or a decomposition.

---
Concept guide · ISO 26262-9 §7 · 11 chapters

# Dependent Failure Analysis (DFA)

Learn to test the independence and freedom-from-interference claims your safety concept rests on, using the ISO 26262-9 method at system, hardware and software level.

11

Chapters

6

Method steps

2

Worked examples

Included in [Expert](https://iso26262.academy/pricing#plan-advanced)

[Preview free](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fdependent-failure-analysis&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters

Inside the course

1. 01 **Why DFA Matters**
2. 02 **Common-Cause vs Cascading**
3. 03 **Coupling Factors & DFI**
4. 04 **DFA in the Lifecycle**
5. 05 **The DFA Method**

The short version

## Quick answers

What is dependent failure analysis (DFA) in ISO 26262?

Dependent failure analysis is the method defined in ISO 26262-9, Clause 7 for verifying that elements which are claimed to be independent, or merely free from interference, really are. Statistical independence is an assumption, not a physical guarantee: a shared supply, clock, memory, or environment can let a single root cause defeat several elements at once. DFA systematically identifies dependent failure initiators (DFIs) and the coupling factors connecting supposedly independent elements, then confirms that mitigations break the coupling. It underpins ASIL decomposition, redundancy claims, and mixed-ASIL coexistence, and it runs iteratively from the concept phase through hardware and software design.

What is the difference between common-cause and cascading failures?

A common-cause failure strikes multiple elements from one shared root: for example, a shared 5 V reference drifting and corrupting both channels of a redundant sensor pair at the same time. A cascading failure propagates from one element to the next: the first element fails, and its failure causes the second to fail. Both are dependent failures, and both defeat independence claims, but they need different mitigations: a common cause is broken by removing the shared resource or adding diversity, while a cascade is broken by blocking the propagation path.

Keep going, free

- [Article · 3 min read Dependent Failure Analysis: Three Checks Beyond Redundancy](https://iso26262.academy/blog/practical-tips-for-mastering-dependent-failure-analysis-in-iso-26262)
- [Article · 7 min read The Core Concept of Dependent Failure Analysis in ISO 26262](https://iso26262.academy/blog/the-core-concept-of-dependent-failure-analysis-in-iso-26262)
- [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam)

Why this course · ISO 26262, Part 9, Clause 7

## Why it pays for itself

### Prove independence instead of assuming it

Redundancy and ASIL decomposition claims collapse when one root cause defeats both channels. The six-step DFA method turns those assumptions into a validated independence argument backed by evidence.

### Hunt initiators with a checklist

A category-by-category coupling-factor checklist (proximity, shared power and ground, shared memory and communication, common IP and tooling) drives complete coverage so no plausible dependent failure initiator slips through.

### Work it at every level

Two worked examples, a dual-ECU steering topology at system level and a fictional dual-channel brake control, take independence claims through candidate scenarios to measures with effectiveness evidence.

After the course

## What you’ll be able to do

### Validate independence claims

Decide whether decomposition and redundancy claims hold by checking that no single root cause bridges the channels.

### Identify dependent failure initiators

Surface the root-cause events and coupling factors that link elements you assumed were independent.

### Run the method at every level

Apply the structured DFA from system topology down to hardware and software, with clean hand-offs between them.

### Select effective mitigations

Choose separation, diversity, partitioning and monitoring measures that actually break the coupling you found.

### Separate DFA, FFI and CCF

Use each term correctly and connect them into one coherent independence argument.

The curriculum · 11 chapters

## Chapter by chapter

1. 01
   **Why DFA Matters**
   See why an independence claim is a hypothesis to test, the reasons DFA is performed, and where the method lives in ISO 26262-9.
   - Independence claims
   - Reasons to perform DFA
   - Normative home in Part 9
2. 02
   **Common-Cause vs Cascading**
   Separate the two dependent-failure patterns in plain language, compare them side by side and place both under their parent category.
   - Plain-language definitions
   - Side-by-side comparison
   - Automotive examples
3. 03
   **Coupling Factors & DFI**
   Learn what a dependent failure initiator is, how coupling factors give it a path, and how the depth of the analysis should scale.
   - Dependent failure initiators
   - Coupling factor categories
   - Pathway model
4. 04
   **DFA in the Lifecycle**
   Place DFA on the V-model and list the inputs it consumes and the outputs it hands to later work products.
   - V-model placement
   - Required inputs
   - Produced outputs
5. 05
   **The DFA Method**
   Walk the six-step process from scoping the independence claim to recording the evidence, and set up the worksheet that carries it.
   - Method overview
   - Six-step process
   - Worksheet structure
6. 06
   **Coupling-Factor Checklist**
   Use a structured checklist that regroups the coupling-factor classes into working categories, so every path in the scoped architecture gets a recorded answer.
   - Using the checklist
   - Working categories
   - Recorded rationale
7. 07
   **DFA at System Level**
   Run the analysis on the vehicle topology, hand findings down to the hardware and software DFAs, and decide when the system DFA is done.
   - System-level coupling factors
   - Hardware and software hand-off
   - Dual-ECU steering example
8. 08
   **DFA for Hardware**
   Examine hardware coupling categories, study the common-cause concerns of a dual-core lockstep, and rank the available mitigations.
   - Hardware coupling categories
   - Lockstep case study
   - Mitigation hierarchy
9. 09
   **DFA for Software**
   Find software coupling factors, apply the three interference dimensions, and show freedom from interference between sub-elements on a partitioned OS.
   - Software coupling factors
   - Three FFI dimensions
   - Protected OS partitioning
10. 10
    **Worked Example**
    Apply the method to a fictional dual-channel brake control: set scope and assumptions, list candidate scenarios, and attach measures with effectiveness evidence.
    - Scope and assumptions
    - Candidate scenarios
    - Effectiveness evidence
11. 11
    **DFA vs FFI vs CCF**
    Pin down DFA, freedom from interference, common-cause and cascading failure so the terms stay consistent across your safety documentation.
    - Precise definitions
    - Master comparison
    - How the concepts fit

Read all 11 chapters with Expert.

Start with a free account: the complete Functional Safety Concept guide and 5 practice exams a month, then upgrade when you need this guide.

[Expert](https://iso26262.academy/pricing#plan-advanced)

[Preview free](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fdependent-failure-analysis&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [Try the 7-question demo exam](https://iso26262.academy/demo-exam)

Figures

## Not just text: the visual toolkit

### Common-cause vs cascading timeline

One shared root striking two elements at once, set against a failure that travels from one element to the next.

### Coupling path breaker

Follow an initiator along its coupling path and see which measure interrupts it.

### Coupling-factor coverage heat map

Shows at a glance which coupling categories an analysis has examined and which it has not.

### Redundancy, diversity and independence

A comparator that separates three properties engineers often treat as one.

### Dual-ECU steering topology

System-level coupling paths drawn on a redundant steering architecture.

Worked Example

## Fictional Dual-Channel Brake Control

Chapter 10 applies the full method to two brake control channels, from the independence claim under test to the evidence that each measure works.

- Scope, assumptions and the independence claim being tested
- A coupling map of the two control channels
- Candidate dependent-failure scenarios across shared resources
- Measures assigned to each scenario and the evidence of their effectiveness

Brake control DFA

Scope: two fictional brake control channels and the claim that they are independent

Unlock in course

Built for

## Who this guide is for

- Engineers relying on ASIL decomposition who must defend the independence requirement
- Hardware designers with lockstep cores or redundant sensor channels
- Software architects hosting mixed-ASIL components on one microcontroller
- Reviewers and assessors checking whether an independence argument actually holds

## Frequently Asked Questions

Common questions about Dependent Failure Analysis (DFA)

Whenever your safety concept depends on independence or freedom from interference. The classic triggers are ASIL decomposition (the decomposed elements must be independent), redundant channels credited as fault tolerance, diverse monitoring such as lockstep or watchdog arrangements, and mixed-ASIL software coexisting on a shared processor. The rigor of the analysis scales with the ASIL of the safety goal being protected, and DFA is most valuable when started at the concept phase, where changing an architecture is still cheap.

Coupling factors are the shared attributes that connect supposedly independent elements and give a dependent failure initiator its path: shared resources such as power, clock and memory, shared information inputs, weak immunity to the environment, communication paths, components of identical type, systematic coupling through common design or tools, and unintended interfaces. The course regroups these classes into a small set of working categories for a hands-on checklist, so every path in the scoped architecture gets a recorded answer.

Eleven chapters covering why DFA matters, coupling factors and initiators, the six-step method and its worksheet, a coupling-factor checklist, DFA at system, hardware and software level, and the terminology split between DFA, FFI, common-cause and cascading failure. Two worked examples apply the method: a dual-ECU steering topology at system level and a fictional dual-channel brake control. A free account starts you off, and the Pro and Expert plans unlock more of the library.

## Running this analysis on a real project?

Have an engineer check it, or help you build it. You get written findings on method, coverage and results.

From **$1,490** with a written quote before any charge

[See how we can help](https://iso26262.academy/features/consulting?service=analysis#sample)

## Start the course today

A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov and RBD simulators, and 5 practice exams per month. The Pro and Expert plans unlock more of the 93-guide library. No credit card required.

[Preview free](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fdependent-failure-analysis&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)

Continue with

## Where this topic leads next.

[Browse all 93 guides](https://iso26262.academy/features/concepts#library)

- Safety analyses [HAZOP (Hazard and Operability Study) in ISO 26262](https://iso26262.academy/features/concepts/hazop) Learn to think in deviations, not just failures, using guide words applied to a system's design intention to surface hazards a checklist would miss. See how a technique born in the process industry becomes a rigorous, worksheet-driven feeding source for the ISO 26262 HARA. [Expert](https://iso26262.academy/pricing#plan-advanced) 14 chapters
- Safety analyses [Markov Chains Analysis](https://iso26262.academy/features/concepts/markov-chains) Learn state-transition modeling for multi-state systems with degradation, repair, and fault tolerance scenarios. Includes an interactive Markov calculator, a dual-channel model explorer, and comparison with FTA and FMEA. [Expert](https://iso26262.academy/pricing#plan-advanced) 7 chapters
- Verification and assessment [Verification & Validation](https://iso26262.academy/features/concepts/verification-validation) Learn multi-level verification from unit testing through system and vehicle validation with ASIL-dependent coverage criteria. Covers reviews, HIL/SIL testing, fault injection, MC/DC coverage, and evidence management. [Expert](https://iso26262.academy/pricing#plan-advanced) 9 chapters
