ISO 26262 Dependent Failure Analysis: How to Satisfy Part 9 Without Redoing Your FMEDA

The Independence Assumption Nobody Checks

Your ASIL decomposition looks clean on paper. You split an ASIL D requirement into two ASIL B channels — Channel A in the primary microcontroller, Channel B in a safety monitor IC. The math works: ASIL B + ASIL B (with sufficient independence) = ASIL D. Your FMEDA shows both channels meet the 90% Diagnostic Coverage target. The hardware metrics are green.

Then an assessor asks: "Where is your Dependent Failure Analysis?"

The question catches teams off guard more often than it should. Dependent Failure Analysis (DFA) is a required work product under ISO 26262-9 whenever a safety architecture relies on independence between elements to achieve an ASIL target. If your system has any ASIL decomposition, any redundant channel architecture, or any claimed independence between safety mechanisms and the faults they detect — DFA is mandatory, not optional.

This article explains what DFA actually requires, how it differs from FMEDA, where teams consistently fail assessments, and how to structure a DFA that survives scrutiny.

What ISO 26262 Actually Requires

ISO 26262-9 Clause 6 defines the DFA requirement. The goal is to verify that elements assumed to be independent cannot both fail due to a shared cause — a Common Cause Failure (CCF) — or that the failure of one element cannot trigger failure of another — a Cascading Failure.

The standard distinguishes two categories of dependent failures:

• Common Cause Failures (CCF): A single initiating cause that defeats two or more elements simultaneously. Classic examples include shared power supply, shared ground reference, shared PCB, shared temperature environment, or shared software library.
• Cascading Failures: A failure in Element A that propagates to cause a failure in Element B. This includes overvoltage propagation, CAN bus babbling idiot faults, shared memory corruption, and thermal runaway spreading across a board.

ISO 26262-9 Clause 6.4 lists the freedom from interference requirements: elements with different ASIL levels or elements claimed as independent must be shown to have no unintended interactions — electrical, logical, temporal, or thermal.

The key clause that trips teams: ISO 26262-9 Clause 6.4.5 requires that the DFA cover the entire safety-relevant chain — from sensors through processing to actuators. You cannot bound the analysis to a single ECU if the claimed independence spans multiple hardware elements.

DFA vs. FMEDA: Why They Are Not the Same Analysis

The most common mistake is treating DFA as an extension of FMEDA. They answer different questions.

FMEDA operates at the component level and assumes independence between channels as a given. DFA is what justifies that assumption. If you perform FMEDA without DFA, your hardware metrics are built on an unvalidated foundation — the assessor will note this.

A practical way to think about the relationship: FMEDA measures how well each channel handles faults within itself. DFA measures whether the two channels are actually separate enough that a single event cannot defeat both at once.

The Four Categories of Dependent Failure You Must Cover

ISO 26262-9 does not prescribe a rigid template, but effective DFA must address at least four failure categories:

1. Electrical and Power Coupling

Shared voltage rails are the most frequent CCF finding. If Channel A and Channel B are both powered from the same 3.3V LDO — even through separate decoupling capacitors — a regulator failure defeats both simultaneously. The analysis must trace power from the battery terminal through every intermediate rail to each channel's supply pin.

Mitigation approaches include: separate regulators with independent enable signals, independent reverse-polarity protection, and separate fuse/TVS protection on each rail.

2. Thermal Coupling

Two ICs mounted 5 mm apart on the same PCB share a thermal environment. If one dissipates significant power — a gate driver, for example — it can heat the adjacent safety monitor beyond its operating range. DFA must either bound the thermal interaction quantitatively (using thermal resistance calculations or FEM) or implement a physical separation requirement.

For ASIL D systems, thermal coupling is often underestimated because it is slow and difficult to observe in bench testing but is fully credible at a system level.

3. Software and Configuration Coupling

Two channels implemented on separate cores of the same SoC are not automatically independent. They share:

• On-chip memory buses (potential read/write interference between cores)
• Cache architecture (cache coherency faults can corrupt data across cores)
• Interrupt controllers (a runaway interrupt handler can starve the other core)
• Watchdog hardware (a single watchdog serves both cores on many devices)
• Boot code (a shared bootloader contains shared software faults)

Demonstrating independence for dual-core lockstep processors requires a combination of hardware documentation from the semiconductor supplier (typically a Safety Manual) and architectural evidence that the software partition prevents cross-core interference. ISO 26262-9 Clause 6.4.3 specifically calls out software as a source of dependent failures.

4. Communication Channel Coupling

If both channels receive input from the same sensor — even over separate signal paths — the sensor itself becomes a CCF for both channels. DFA must trace inputs to their physical source and verify that claimed independence exists all the way back to the physical transduction point.

This is particularly relevant for ADAS radar and camera systems where a single antenna or lens feeds multiple processing channels. The diversity claim must be backed by DFA evidence, not assumed.

Structuring a DFA: A Practical Approach

A DFA document typically follows this structure:

Step 1 — Identify independent elements. List every pair of elements where independence is claimed to support an ASIL target. Trace these claims back to the FMEDA and HARA. Each independence claim becomes a DFA scope item.

Step 2 — Define failure categories per pair. For each independent element pair, systematically work through: electrical/power, thermal, EMC/ESD, mechanical, logical/software, and communication coupling.

Step 3 — Identify potential CCF and cascading failure mechanisms. For each coupling category, generate a list of initiating events. Use a structured method — typically an FMEA-style worksheet or a cause-consequence diagram.

Step 4 — Assess coverage. For each identified dependent failure mechanism, determine whether existing design features (separate power supplies, physical separation, firewalls, watchdogs, etc.) prevent or detect the failure before it causes a safety violation.

Step 5 — Document residual risks. Where coverage is incomplete, document the residual risk, its ASIL, and the rationale for acceptance or the additional mitigation required.

Step 6 — Close the loop with FMEDA. Any CCF that FMEDA cannot address because it defeats the diagnostic mechanism itself must be reflected in the PMHF budget as an undetected failure.

Where Teams Fail DFA Assessments

After seeing multiple DFA assessments, the failure modes cluster around five issues:

Scope too narrow. The DFA covers the ECU but stops at the connector. Power harness coupling, connector shared grounds, and sensor dependencies are outside the analysis boundary. Assessors will expand the scope.

Independence claimed at the wrong level. Two software tasks running on the same processor are not independent in the ISO 26262 sense unless the RTOS and hardware provide certified freedom from interference. Software partitioning needs its own evidence trail.

No connection to the ASIL decomposition. The DFA exists as a standalone document but is not referenced from the ASIL decomposition table. Assessors expect to trace from each independence claim in the decomposition to the specific DFA evidence that validates it.

Thermal analysis by assertion. "The two channels are thermally independent because they are on separate PCBs" is not evidence. DFA requires either a calculation, a test result, or a design constraint that enforces the separation.

CCF mitigations not verified in testing. A DFA that lists "separate power supply" as a mitigation but has no test evidence that the separation actually holds under fault conditions (e.g., a short on one rail does not pull down the other) is incomplete.

How DFA Connects to Your Other Safety Work Products

DFA does not exist in isolation. It must be traceable to and from:

• HARA: The hazards and ASIL targets that motivated the safety architecture determine which independence claims the DFA must validate.
• FSC (Functional Safety Concept): Independence requirements between safety mechanisms are stated here and must be covered by DFA.
• TSC (Technical Safety Concept): The hardware and software partitioning that creates independence must be described here before DFA can reference it.
• FMEDA: DFA findings that identify common cause failures must flow back into FMEDA to correctly account for undetectable failures.
• Verification Plan: DFA findings require corresponding test cases — typically injection tests at power supplies, EMC tests, and thermal stress tests.

Managing these links manually across separate documents and teams is where most programs accumulate silent inconsistencies. A change to the hardware architecture that alters a power rail — updating the DFA, updating the FMEDA, updating the TSC, and updating the verification plan — typically requires manual coordination across four engineering disciplines.

How ISO WIZ Manages DFA Traceability

ISO WIZ treats DFA as a first-class work product in the safety workflow, not an afterthought. Every independence claim in the system is tracked as a live traceability link: from the ASIL decomposition table, through the DFA evidence record, to the test case that validates it.

When a hardware architect changes a power topology, ISO WIZ immediately flags every DFA independence claim that references the affected power rail — along with the downstream FMEDA rows and verification plan entries that depend on those claims. Engineers see the full impact of a design change before it reaches review.

The cross-standard dimension matters too. A CCF between two safety channels that also handles a cybersecurity function — for example, a shared HSM that serves both the SecOC stack and the safety monitor — creates a dependency that spans ISO 26262 and ISO 21434. ISO WIZ maintains a unified traceability graph across both standards, so that kind of architectural dependency surfaces during design rather than during a certification audit.

DFA is one of the less visible requirements in ISO 26262, but it is structurally foundational. Every ASIL decomposition in your system rests on independence claims that DFA must validate. The FMEDA numbers are only meaningful if DFA has established that the two channels cannot fail together — and that link needs to be traceable, documented, and maintained as the design evolves.

ISO WIZ is built for exactly this kind of cross-document, cross-standard traceability challenge. You can start a free trial at isowiz.com and see how DFA integrates with your existing safety program within a single session.