Dependent Failure Analysis (DFA) in ISO 26262: CCF, Cascading Failures & FFI Explained

Hello, automotive safety engineers, system architects, and functional safety analysts! Dependent Failure Analysis (DFA) is one of the most critical – and most challenging – safety analysis activities in ISO 26262. While FMEA analyzes individual component failures and FTA traces failure paths to safety goal violations, DFA specifically targets dependent failures – failures that are not statistically independent because a single root cause can defeat multiple elements simultaneously, destroying the redundancy and independence that the safety concept relies upon.

In this comprehensive guide at PiEmbSysTech, we will explain common cause failures, cascading failures, the critical distinction between freedom from interference and independence, coupling factors at every level, and the step-by-step DFA process with worked examples. Let us begin.

1. What is DFA and Why It Matters

Dependent Failure Analysis (DFA) is a safety analysis method defined in ISO 26262 Part 9, Clause 7 that identifies and evaluates failures that are not statistically independent – where a single root cause can simultaneously affect multiple elements assumed to be independent, potentially defeating the redundancy and safety mechanisms upon which the safety concept relies.

DFA matters because the entire foundation of automotive safety architecture relies on the assumption that certain elements are independent: the primary function channel is independent from the monitoring channel; the safety mechanism is independent from the function it monitors; the ASIL D decomposed elements are independent from each other. If these independence assumptions are wrong — if a single root cause can simultaneously disable both the function and its safety mechanism – then the safety concept is fundamentally flawed. DFA is the analysis that validates or invalidates these independence assumptions.

2. What Are Dependent Failures?

A dependent failure is a failure of multiple elements that is not the result of independent failure events. If elements A and B have independent failure rates λ_A and λ_B, the probability of both failing simultaneously should be λ_A × λ_B (very small). But if a common root cause can trigger both failures, the combined probability becomes much higher – equal to the probability of the single root cause occurring. This dramatically increases the risk of safety goal violation compared to what the independent failure calculation predicts.

ISO 26262 identifies two types of dependent failures: Common Cause Failures (CCF) and Cascading Failures.

3. Common Cause Failures (CCF) Explained

A Common Cause Failure (CCF) occurs when two or more elements fail simultaneously due to a single specific event or root cause — without one element’s failure causing the other’s. The failures are correlated because they share a common susceptibility.

Examples of CCF:

A shared power supply voltage regulator fails – both the primary MCU and the monitoring MCU lose power simultaneously because they both depend on the same supply.

An electromagnetic interference (EMI) event disrupts both redundant CAN communication channels simultaneously because both transceivers are on the same PCB with insufficient shielding.

A temperature exceedance event causes both redundant temperature sensors to drift out of specification simultaneously because they are mounted in the same thermal environment.

A common software library used by both the command function and the monitoring function contains a systematic design error that affects both simultaneously.

A manufacturing defect in a common PCB fabrication batch affects multiple components on the same board.

4. Cascading Failures Explained

A Cascading Failure occurs when the failure of one element directly causes the failure of another element – the failures propagate in a chain reaction. Unlike CCF (where both elements fail from a common external cause), in cascading failures, one element’s failure is the cause of the other element’s failure.

Examples of cascading failures:

A short circuit in the motor driver IC causes overcurrent on the shared power bus – which damages the monitoring MCU’s power supply input, disabling the monitoring function.

A software exception in a QM application SWC corrupts the shared memory region used by an ASIL D safety SWC (spatial interference – if MPU protection is absent or misconfigured).

A CAN transceiver failure in dominant mode blocks all CAN communication – preventing safety-relevant diagnostic messages from being transmitted by other ECUs on the same bus.

A runaway QM task consumes all available CPU time – preventing the ASIL D safety task from executing within its FTTI (temporal interference).

5. CCF vs Cascading Failures – Key Differences

Aspect	Common Cause Failure (CCF)	Cascading Failure
Cause mechanism	Single external root cause affects multiple elements simultaneously	Failure of element A directly causes failure of element B
Failure propagation	Parallel – both elements fail from the same cause	Sequential – failure chains from one element to the next
Examples	Shared power supply failure, EMI event, temperature exceedance, common software library bug	Short circuit damaging adjacent circuits, memory corruption, bus blocking, CPU starvation
Mitigation strategy	Diversity, physical separation, independent resources	Isolation, protection barriers (MPU, fuses), fault containment
Relation to FFI	Not directly related to FFI (FFI only considers cascading failures)	Directly addressed by FFI
Relation to Independence	Must be addressed to claim independence	Must be addressed to claim independence

6. Freedom from Interference (FFI) Defined

ISO 26262 Part 1 defines Freedom from Interference (FFI) as: the absence of cascading failures between elements that could lead to the violation of a safety goal. FFI is specifically about preventing failure propagation from one element to another. Critically, FFI only considers cascading failures – it does not include common cause failures. FFI can exist even if CCF potential exists between two elements – as long as no cascading failure path leads to a safety goal violation.

7. Independence Defined

ISO 26262 Part 1 defines Independence as: the absence of dependent failures (both CCF and cascading failures) that could lead to a multi-point failure violating a safety goal. Independence is a stronger property than FFI – it requires freedom from both cascading failures and common cause failures.

8. FFI vs Independence – The Critical Distinction

Independence = FFI + No Common Cause Failures

FFI is required for coexistence of elements with different ASILs on the same hardware (e.g., QM and ASIL D software on the same MCU – addressed through AUTOSAR partitioning). Independence is required for ASIL decomposition – where two elements must be sufficiently independent for the decomposed ASIL to be valid. This distinction is frequently confused in practice – many engineers use FFI and independence interchangeably, but they are different properties with different scope.

9. When is DFA Required?

DFA is required whenever the safety concept relies on the independence of elements or on freedom from interference between elements. Specifically, DFA is required for ASIL decomposition (to verify sufficient independence between decomposed elements – Part 9 Clause 5), for coexistence of elements with different ASILs (to verify FFI between elements of different ASILs sharing resources – Part 9 Clause 6), for verification of safety mechanism effectiveness (to verify that dependent failures cannot simultaneously disable both the monitored function and the safety mechanism), and for any architecture where redundancy is claimed as a safety measure (to verify that the redundancy is not defeated by dependent failures).

10. Coupling Factors – The Root Causes of Dependent Failures

Coupling factors are the physical, logical, or environmental characteristics that create dependencies between elements. ISO 26262-9:2018 Annex C provides a classification of coupling factors at four levels:

System level coupling factors: Shared power supply, shared clock source, shared communication bus (CAN, SPI, Ethernet), shared mechanical mounting (same enclosure, same PCB), shared environmental exposure (temperature, vibration, EMC), shared connector (single connector failure disconnects multiple signals).

Hardware level coupling factors: Common semiconductor technology, shared die area (for multi-function ICs), same PCB layout routing proximity, shared ground plane, common manufacturing lot (same solder paste, same pick-and-place machine), common test coverage limitations.

Software level coupling factors: Shared memory space (without MPU protection), shared CPU resources (without temporal protection), shared software libraries or middleware, shared RTOS resources (semaphores, mutexes), shared global variables, common compiler and toolchain (common systematic errors in code generation).

Semiconductor level coupling factors: Shared power domain on-chip, shared clock tree, common substrate coupling, shared ECC logic, common fabrication process, cross-talk between adjacent signal paths, shared scan chain for DFT.

11. The DFA Process – Step by Step

Step 1 – Identify element pairs (couples) for analysis: Based on the system architecture, identify all pairs of elements where independence or FFI is assumed by the safety concept. This includes all ASIL-decomposed element pairs, all pairs where one element is a safety mechanism for the other, and all pairs where different-ASIL elements share resources.

Step 2 – Identify coupling factors for each pair: For each identified couple, systematically evaluate all applicable coupling factor categories (system, hardware, software, semiconductor) to identify potential dependencies.

Step 3 – Analyze common cause failure potential: For each coupling factor, evaluate whether a single root cause could simultaneously affect both elements in the couple, defeating the assumed independence. Document the analysis in the CCF worksheet.

Step 4 – Analyze cascading failure potential: For each coupling factor, evaluate whether a failure in one element could propagate to the other element, defeating the assumed FFI. Document the analysis in the cascading failure worksheet.

Step 5 – Evaluate safety measures: For each identified dependent failure potential, identify existing or needed safety measures that prevent, detect, or mitigate the dependent failure. Evaluate the effectiveness of these measures.

Step 6 – Verify safety measure effectiveness: Using FTA, FMEA, simulation, or fault injection testing, verify that the safety measures adequately address the identified dependent failure risks.

Step 7 – Document the DFA report: Compile the complete DFA documentation including the couple identification, coupling factor analysis, CCF analysis, cascading failure analysis, safety measures, and verification evidence.

12. Common Cause Failure Analysis – Methodology

The CCF analysis follows a structured approach: identify the element couple, identify all shared resources and environmental exposures (coupling factors), for each coupling factor evaluate the CCF potential (can a single root cause fail both elements?), for each identified CCF potential document the root cause and the failure effect, and identify and evaluate safety measures to prevent or mitigate the CCF.

Safety measures against CCF include: diversity (different technologies, different manufacturers, different algorithms), separation (physical distance, separate enclosures, separate PCBs), independence of resources (separate power supplies, separate clocks, separate communication channels), environmental protection (temperature derating, EMC shielding, vibration isolation), and process measures (separate manufacturing lots, different toolchains for diverse software channels).

13. Cascading Failure Analysis – Methodology

The cascading failure analysis examines how a fault in one element can propagate to another. For each interface between elements in the couple, the analysis evaluates what failure modes of element A could propagate through the interface to cause a failure in element B, whether protection barriers exist to contain the fault within element A, and what the consequence of fault propagation would be on the safety function.

Safety measures against cascading failures include: spatial isolation (MPU/MMU memory protection, separate address spaces), temporal isolation (OS timing protection, execution budgets, watchdog monitoring), communication protection (E2E protection, CRC, alive counters), electrical isolation (fuses, current limiters, galvanic isolation, separate power domains), and fault containment regions (partitioning the system such that faults are contained within defined boundaries).

14. DFA Inputs from FMEA and FTA

DFA does not operate in isolation – it takes critical inputs from FMEA and FTA. From FMEA: similar parts or components with similar failure modes that appear multiple times indicate potential for dependent failures. From FTA: examination of cut sets reveals potential CCF – if a two-event minimal cut set contains events affecting the same physical resource, a CCF could convert the AND gate into an effective OR gate. Repeated identical events in different branches of the fault tree indicate dependent failure potential. The DFA analyst should systematically review the FMEA and FTA outputs for these indicators.

15. Safety Measures Against Dependent Failures

Coupling Factor	Dependent Failure Risk	Safety Measure Example
Shared power supply	CCF: Supply failure disables both channels	Independent voltage regulators for each channel; supply monitoring with independent reference
Shared memory space	Cascading: QM software corrupts ASIL data	MPU partitioning; AUTOSAR OS-Application isolation
Same semiconductor technology	CCF: Common design error affects both MCUs	Heterogeneous MCU selection (different families/vendors)
Shared CAN bus	Cascading: Bus-off condition blocks safety messages	Separate safety CAN channel; E2E protection with timeout; bus guardian
Shared CPU time	Cascading: QM task starves ASIL task	OS timing protection; priority-based scheduling; execution budget monitoring
Common environmental exposure	CCF: Temperature exceedance affects both sensors	Physical separation; temperature derating; diverse sensor technologies
Shared software library	CCF: Library bug affects both channels	Diverse algorithms; different libraries for each channel; independent code review

16. DFA at System, Hardware, Software, and Semiconductor Levels

DFA must be performed at every level where independence or FFI is assumed. System level: Analyze dependencies between ECUs, between sensors, between communication channels, and between power supplies. Hardware level: Analyze dependencies between components on the same PCB – shared traces, shared power planes, common thermal environment, common manufacturing defects. Software level: Analyze dependencies between software components sharing the same MCU – memory, CPU time, communication resources, shared code libraries. AUTOSAR’s partitioning mechanisms provide the software-level FFI framework. Semiconductor level: Analyze dependencies within complex ICs – shared power domains, shared clock trees, substrate coupling, common test infrastructure. Part 11 provides semiconductor-specific DFA guidance.

17. Worked Example – EPS Dual-Channel DFA

For an EPS system with ASIL D decomposed to ASIL B(D) + ASIL B(D) using a dual-MCU architecture (TC397 primary + TC375 monitoring), the DFA must verify independence between the two channels:

Couple: TC397 primary channel ↔ TC375 monitoring channel.

CCF analysis (coupling factors examined): Power supply – MITIGATED: separate voltage regulators (5V_Primary, 5V_Monitor) from independent sources on the PCB. Clock source – MITIGATED: TC397 uses internal PLL with external 20 MHz crystal; TC375 uses separate internal PLL with independent 16 MHz crystal. Temperature – PARTIALLY MITIGATED: both MCUs are on the same PCB (common thermal environment), but both are derated to full automotive temperature range with margin. EMC – MITIGATED: separate ground planes, EMC filtering on each channel’s critical signals. Semiconductor technology – MITIGATED: TC397 and TC375 are different device families (different silicon designs), providing technology diversity. Software toolchain – MITIGATED: both channels compiled with qualified compiler; monitoring channel uses different algorithm from primary channel (algorithmic diversity).

Cascading failure analysis: SPI cross-check interface – MITIGATED: E2E protected with CRC-16 and alive counter; timeout detection; failure of SPI does not propagate electrical damage (voltage-limited signals). Safety relay control – MITIGATED: relay K1 controlled exclusively by monitoring MCU; primary MCU has no electrical path to control or damage the relay circuit. Shared connector – EVALUATED: both channels share the main ECU connector; connector failure could affect both channels (residual coupling factor – accepted with additional connector reliability analysis).

DFA conclusion: The dual-channel architecture provides sufficient independence for ASIL D decomposition, with the shared connector identified as a residual coupling factor addressed through connector derating and reliability analysis.

18. The DFA Report – Contents and Structure

The DFA report is a required work product that documents the DFA scope and objectives (which element couples are analyzed and why), the coupling factor analysis (systematic evaluation of all applicable coupling factors per ISO 26262-9 Annex C), the CCF analysis results (for each coupling factor: identified CCF potential, safety measures, and effectiveness evaluation), the cascading failure analysis results (for each interface: identified propagation paths, safety measures, and effectiveness evaluation), residual risks (any coupling factors that are accepted rather than fully mitigated, with justification), and verification evidence (FTA cut set analysis, simulation results, fault injection test results, or other evidence confirming the effectiveness of safety measures).

19. Common Mistakes and How to Avoid Them

Mistake 1: Confusing FFI with independence. FFI addresses only cascading failures. Independence addresses both cascading AND common cause failures. For ASIL decomposition, independence (not just FFI) must be demonstrated.

Mistake 2: Performing DFA too late in development. DFA should begin at the architectural phase when coupling factors can be eliminated by design. Discovering a critical CCF after the PCB is designed and manufactured is extremely costly to fix.

Mistake 3: Assuming physical separation alone provides independence. Two MCUs on separate PCBs still share common environmental exposure (same enclosure temperature, same vehicle vibration), common manufacturing processes, and potentially common software toolchains. Physical separation reduces but does not eliminate coupling factors.

Mistake 4: Not considering software coupling factors. Two software channels running on the same MCU share CPU, memory, and OS resources — even with AUTOSAR partitioning, the MPU configuration, OS scheduling, and RTE communication must be verified to provide effective FFI.

Mistake 5: Ignoring semiconductor-level coupling factors. For complex SoCs with multiple safety-relevant IP blocks, on-chip coupling factors (shared power domains, clock trees, substrate noise) can create dependent failures that are invisible at the PCB level.

Mistake 6: Not documenting the DFA adequately. The DFA report must be detailed enough for an independent assessor to understand the analysis, evaluate the completeness of coupling factor coverage, and judge the effectiveness of the safety measures. A superficial DFA that simply states “elements are independent” without detailed coupling factor analysis is a common audit finding.

20. Frequently Asked Questions

Q1: Is DFA only needed for ASIL decomposition?

No. DFA is needed whenever independence or FFI is assumed – including ASIL decomposition, coexistence of different-ASIL elements, and any architecture relying on redundancy or safety mechanism independence. Even without ASIL decomposition, if the TSC claims that a safety mechanism is independent from the function it monitors, DFA must verify that claim.

Q2: Can FFI exist without independence?

Yes. FFI means no cascading failures lead to safety goal violation. Independence means no dependent failures (neither cascading nor CCF) lead to safety goal violation. You can have FFI (no cascading path) while still having CCF potential — which means you have FFI but not full independence.

Q3: What tools are used for DFA?

DFA is typically performed using structured worksheets (Excel or dedicated tools), with inputs from FMEA (APIS IQ, Medini Analyze) and FTA. The coupling factor analysis from ISO 26262-9 Annex C is used as a systematic checklist. Some tools like Ansys Medini and Vector PREEvision support integrated DFA workflows linked to the system architecture model.

Q4: How does DFA relate to beta factor calculation?

In IEC 61508, the beta factor quantifies the fraction of failures that are common cause. ISO 26262 does not use the beta factor approach explicitly — instead, it requires a qualitative/semi-quantitative DFA that identifies specific coupling factors and evaluates specific safety measures. However, some practitioners use beta-factor-like scoring approaches (as described in ISO 26262-9 Annex C) to provide a semi-quantitative DFA evaluation.

Q5: Does DFA need to be repeated when the design changes?

Yes. Any design change that affects the architecture, interfaces, shared resources, or physical layout may introduce new coupling factors or invalidate existing safety measures. The DFA must be reviewed and updated as part of the change impact analysis.

21. Conclusion

Dependent Failure Analysis (DFA) is the safety analysis that validates the most critical assumptions in the safety architecture – that redundant elements are truly independent and that safety mechanisms cannot be defeated by dependent failures. By systematically identifying coupling factors, analyzing both common cause failure and cascading failure potential, and verifying the effectiveness of safety measures, DFA provides the evidence needed to support ASIL decomposition, mixed-ASIL coexistence, and safety mechanism independence claims. Without rigorous DFA, the safety case rests on unverified assumptions – and unverified assumptions are the most dangerous kind of technical debt in functional safety.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For the foundational Part 9 coverage, see Part 9 – ASIL Decomposition & DFA.

Stay safe. Stay independent. Keep engineering the future.

— The PiEmbSysTech Team