System FMEA vs DFMEA: Choosing the Right Level Before You Start
Every component passed its DFMEA. The brake controller met its requirements, the wheel-speed sensor met its requirements, and the wiring harness met its requirements. The system still failed on the test track — because the failure lived in the handshake between two subsystems that each worked exactly as designed. No single component owned it, so no single DFMEA caught it.
That gap is the case for a System FMEA. It’s also where the most common scoping mistake in early design shows up. Teams either skip the system level and miss interaction failures, or they spin up a System FMEA out of habit on a product a well-scoped DFMEA would have covered. This post compares System FMEA and DFMEA on the one criterion that decides which you need: who owns interaction failures. It then covers how they feed each other, and when a separate System FMEA actually earns its keep.
The criterion that separates them: who owns interaction failures
DFMEA and System FMEA are both design-side analyses (neither is a process FMEA — if you’re sorting out that axis instead, see how DFMEA and PFMEA hand off). They differ by the level of the structure they analyze. DFMEA asks how a component or subsystem fails to deliver its own function. System FMEA asks how the system fails when its subsystems interact — the failures that emerge from interfaces, shared resources, timing, and signal exchange, not from any one part being out of spec.
Put plainly: a failure that you can pin to one component’s design belongs in a DFMEA. A failure that only appears because two correctly-functioning subsystems interact belongs in a System FMEA. Get that boundary right and the two analyses stop overlapping and start covering each other’s blind spots.
DFMEA: component and subsystem design failures
A DFMEA is structured by function: each item’s intended function is stated in verb-noun form (“transmit torque,” “seal fluid”), and failure modes are the ways that function fails — cracks, leaks, deformation, signal loss. Causes trace to design choices: material, geometry, tolerance, environmental margin. The discipline of writing those modes correctly is its own skill; see writing DFMEA failure modes in function-based verb-noun form.
DFMEA scope is set with a boundary diagram and a P-diagram before any failure modes are written — those tools draw the line around what’s “inside” the analysis and what’s an external interface. That setup work is covered in boundary diagrams and P-diagrams that scope a DFMEA. A DFMEA done well still sees interfaces — but it sees them from one component’s point of view, as inputs and outputs at its own boundary, not as system-wide interactions.
System FMEA: interactions, interfaces, and emergent failures
A System FMEA sits one level up. Its structure is the system and its subsystems. Its failure modes live between elements. A subsystem delivers a correct output at the wrong time. Two subsystems contend for the same resource. A fault crosses an interface because the receiving subsystem assumed the sender would never send that value. These are the failures the brake-system example was built from — real at the system level, invisible at the component level.
The interface focus overlaps with the interface analysis you do inside a DFMEA, but isn’t the same thing. DFMEA interface analysis maps the connections at one component’s boundary. A System FMEA reasons about the whole web of subsystem interactions at once. For mechatronic or software-heavy products, the System FMEA is also where hardware, software, and control logic meet — it pairs naturally with software FMEA for safety-critical systems, since cross-domain interaction failures rarely respect the hardware/software line.
Side-by-side: System FMEA vs DFMEA
| Criterion | System FMEA | DFMEA |
|---|---|---|
| Structure level | System and its subsystems | Component or subsystem |
| Owns which failures | Interactions, interfaces, timing, emergent behavior | A single item failing its own function |
| Typical timing (APQP) | Concept phase, earliest | Design phase, after the system is decomposed |
| Inputs | System architecture, interface definitions, use cases | Requirements, boundary diagram, P-diagram |
| Who runs it | Systems / integration engineering, often the OEM | Component design owner, often the supplier |
| Skip it when | Single-component product with few interactions | Never, if you own a component’s design |
How they feed each other
System FMEA and DFMEA aren’t competitors — they’re levels of one structure-analysis hierarchy, which is Step 2 of the AIAG & VDA FMEA Handbook 7-step method. The System FMEA runs first, in the concept phase, and its outputs — the interactions and interface requirements it flags — become inputs and constraints for the DFMEAs that follow. The handbook formalizes this with linkage points between System, Design, and Process FMEAs so a failure effect identified at one level appears as a cause or requirement at the next.
The same hierarchy appears in SAE J1739 and in IEC 60812:2018, which explicitly covers hardware, software, processes, and their interfaces — the “and their interfaces” is the part a System FMEA owns. The practical upshot: a System FMEA without DFMEAs underneath it has no detail; DFMEAs without a System FMEA above them have no owner for the failures that fall between parts.
Verdict: do you need a separate System FMEA?
If you supply a single component — a bracket, a connector, a sensor — run a DFMEA and stop there. There is no system above your part for you to analyze; your customer owns the System FMEA, and your DFMEA’s job is to honor the interface requirements they hand you.
If you’re an OEM or integrator with multiple interacting subsystems, run the System FMEA first, then DFMEAs per subsystem. The interaction failures are exactly what no supplier DFMEA will catch, and they’re the expensive ones — they surface in integration test or in the field, not on a component bench.
If your product is mechatronic or software-heavy, the System FMEA is non-negotiable: it’s the only level where hardware, software, and control interactions are visible together. Treat the System FMEA as the spine and hang hardware DFMEAs and software FMEAs off it.
If you have a simple product with few subsystem interactions, skip the separate System FMEA. Fold the handful of system-level concerns into a DFMEA scoped with a careful boundary diagram. Manufacturing a System FMEA to check a box produces a document nobody maintains — the opposite of what the analysis is for.
Whichever level you’re working at, the failure modes you find still need severity, occurrence, and detection ratings before you can prioritize action. Our RPN and Action Priority calculator handles the ranking for system-level and component-level modes alike, so the same risk logic carries across both analyses. Decide the level by where the failures live — then let the ratings tell you which ones to fix first.