Dependent Failure Analysis: Three Checks Beyond Redundancy

Two controllers. Two signal paths. One shared supply. An architecture can look redundant while still depending on a single vulnerable resource.

Dependent Failure Analysis (DFA) tests the independence assumptions behind a safety concept. It examines whether a shared cause or failure propagation could defeat the protection the design relies on. ISO 26262-9:2018, Clause 7 addresses this analysis. Here are three practical starting points.

1. Follow the cause, not just the timing

A common cause failure occurs when one event or root cause directly affects multiple elements. A cascading failure occurs when one element’s failure causes another to fail. Similar timing alone does not tell you which relationship exists.

For example, an electromagnetic disturbance could upset two controllers directly. Alternatively, one faulty sender could transmit erroneous data that makes another function fail. These are hypothetical examples; the classification depends on the elements and boundaries being analysed.

The distinction matters when choosing measures. Diversity, separation, input checks or containment can help, but none automatically establishes independence. The measure must address the actual cause or propagation path.

2. Look behind the redundant boxes

Start with a concrete claim: which safety requirement depends on these elements being sufficiently independent? Then inspect what they share: power, clocks, information, communication, physical environment and development assumptions. DFA considers systematic failures as well as random hardware failures.

A shared supply failure could disable both channels. That does not automatically prove a particular hazard occurs: the consequence depends on the safety requirement, operating situation and system response. Sharing itself is not automatically prohibited; the analysis must show whether a plausible dependent failure threatens the claim and how it is prevented or controlled.

For ASIL decomposition, ISO 26262 applies decomposition to an initial safety requirement. Each resulting redundant requirement must fulfil it independently, and the implementing elements need sufficient independence. Decomposition does not relax the hardware architectural metrics or random hardware failure evaluation requirements. It is not simply a mathematical reduction of a component’s ASIL.

Also distinguish freedom from interference from independence. Freedom from interference concerns harmful cascading effects between elements. An independence argument must also address common causes.

3. Connect each claim to evidence

Use existing safety analyses to identify candidate dependencies. Failure Mode and Effects Analysis (FMEA) can reveal recurring vulnerabilities; Fault Tree Analysis (FTA) can expose combinations whose independence needs examination.

When DFA finds a dependency, revisit the affected analyses and assumptions. A common cause may need explicit representation in a fault tree; it does not automatically replace every individual failure event.

Record why a scenario is plausible, its safety impact, the chosen measure and the evidence supporting its effectiveness. For example, memory protection can address specified access violations, but does not by itself resolve timing interference or shared power failures. Verify the analysis too, and revisit it as the architecture changes.

Turn the principle into an engineering skill

The difficult part is judging whether a dependency is plausible and whether the evidence is enough. Our subscription content on Dependent Failure Analysis develops these decisions through interactive visuals, hardware and software discussions, a coupling-factor checklist and a worked example.

Explore subscription plans to go beyond recognising shared dependencies and learn how to build a defensible independence argument.