Failure Modes, Read Before They Happen A plain-language guide to DFMEA and PFMEA

FMEA stands for Failure Mode and Effects Analysis. Strip away the acronym and it is a structured way of asking three questions about something you are building, before you build it: What could go wrong? How bad would it be? And what are the odds we either cause it or miss it?

Think of it as a fire drill on paper. You walk through every part of a design, or every step of a process, and you deliberately try to imagine the ways it can misbehave. Each imagined misbehavior is a failure mode. For every failure mode you trace its effect (what the customer or the next operation feels) and its cause (the underlying reason it happens). Then you score the risk and decide where to spend your attention.

The reason engineers bother is simple arithmetic. A failure caught on a whiteboard costs a meeting. The same failure caught in validation costs a redesign. Caught at the customer, it costs a recall. FMEA is the cheapest place in that sequence to find trouble.

Two flavors dominate. A DFMEA studies a design: a part, a subsystem, a circuit, a piece of software, asking how the thing itself can fail to do its job. A PFMEA studies a process: the assembly line or workflow that makes the thing, asking how the steps that build it can introduce defects. They share the same machinery and feed each other, which is exactly why they are usually taught together.

The clearest way to keep them apart is to ask: am I blaming the blueprint, or the workshop? A DFMEA assumes the factory is perfect and asks whether the design itself is sound. A PFMEA assumes the design is fine and asks whether the process can reliably reproduce it.

The 2019 AIAG-VDA handbook (the joint American and German automotive standard) reframed FMEA as a seven-step process. The first three steps are setup, the middle three are the analysis everyone pictures, and the last step closes the loop. Click through them.

Before you can ask how something fails, you have to agree on what it is and where it ends. That is the job of step two. A boundary diagram draws a box around your system, shows what sits inside, and names every interface that crosses the boundary. The interfaces matter most, because a surprising share of real failures happen not inside a part but at the seam where two parts meet.

Below is a boundary diagram for an electric vehicle traction inverter, the unit that turns the battery's DC into the three-phase AC that spins the motor. Each line crossing the dashed boundary is a candidate for failure analysis.

Step three asks what each item is supposed to do. You cannot define failure until you have defined success. The classic tool here is the P-diagram (parameter diagram). It frames an item as a transfer function: inputs go in, the ideal function happens, and outputs come out, while two extra arrows acknowledge reality. Control factors are things the designer can set; noise factors are things they cannot, like temperature, aging, and the customer's driving style.

Everything that is not the ideal output is an error state, and error states are exactly the failure modes the DFMEA will analyze.

Step four is where most of the thinking happens. Every failure has three layers, and confusing them is the single most common mistake in FMEA. Read the chain from the middle out:

• Failure mode is the anchor: the way the item fails to deliver its function. State it at the item's own level.
• Failure effect is what happens upward and outward: what the next assembly, the vehicle, or the customer experiences. Severity scores this.
• Failure cause is what happens downward: the mechanism or condition that triggers the mode. Occurrence and your prevention controls live here.

The reliable trick is the focus element. Pick the item you are analyzing, and the same physical event is a cause when you look down to its parts, a mode at its own level, and an effect when you look up to its system. Tap a node below to light the chain.

Step five turns the analysis into numbers so you can prioritize. Each failure gets three scores from 1 to 10. They are not measurements; they are calibrated judgments, anchored to rating tables your organization agrees on in advance.

From RPN to Action Priority

For decades teams multiplied the three numbers into a Risk Priority Number (RPN = S × O × D, from 1 to 1000) and chased the biggest products. The trouble is that multiplication hides what matters. An RPN of 112 can come from a mild annoyance that happens constantly, or from a safety hazard that is merely rare. Those deserve very different responses, yet they look identical.

The 2019 handbook replaced RPN as the decision rule with Action Priority (AP): a lookup table that returns High, Medium, or Low. It deliberately weights severity first, then occurrence, then detection, so that a high-severity item never hides behind a low product. RPN is still fine as a rough sort, but AP decides what you must act on.

Set the three ratings and watch both the old RPN and the new AP respond. Notice how raising severity alone can jump the AP to High even when the RPN stays modest, which is the whole point of the 2019 change.

The calculator answers one cell at a time. To feel why the 2019 method weights severity first, it helps to see the whole space at once. There are exactly 1000 combinations of S, O, and D, and every one resolves to High, Medium, or Low. Below, each thumbnail is one severity level, showing how Occurrence and Detection trade off at that severity. Click a thumbnail to expand it.

Engineers under schedule pressure love to "fix" risk by adding a final inspection, which lowers the detection score on paper. This simulation shows why that is the weakest of the three levers. Parts stream down a line. A fraction are born defective (set by occurrence). A detection gate catches some of them, but never all. Whatever slips past reaches the customer.

Try it: push occurrence down and watch escapes collapse. Then leave occurrence high and crank detection to its best, and watch escapes shrink but never vanish. Prevention beats inspection every time.

Here is a compact DFMEA for two functions of the inverter from Figure 2. Read it left to right as the cause-mode-effect chain, then the three scores, then the resulting Action Priority, then the action that follows. This is the shape every DFMEA row takes.

Now the process side. The same motor needs a stator, and the stator is wound, inserted, welded, and tested on a line. A PFMEA walks each step and asks how that step can produce a part that does not match the design. First, the process flow, because a PFMEA without a flow diagram is guesswork.

Step six is where an FMEA earns its keep. You take a High or Medium item and define actions, then you re-score to confirm the risk actually moved. The widget below starts from the worst PFMEA row, the loose-winding-tension item (S7 / O5 / D5, High). Toggle the candidate actions and watch the priority recompute. Notice which levers move it and which do not.

There is a third member of the family that the design-and-process pair leaves out. FMEA-MSR (Monitoring and System Response) analyzes failures that happen while the customer is driving and are caught by the vehicle's own on-board monitoring, which then commands a safe response. It is the formal meeting point between classic FMEA and the monitoring world of VHM and PHM.

MSR keeps Severity but swaps the other two ratings for ones that make sense in the field:

The key move is that monitoring plus response can lower the effective severity. An open inverter phase that would be a sudden loss of propulsion (S9) becomes, with a fast monitor and a controlled torque cut, a managed coast-down with a warning lamp (perhaps S7). You did not prevent the fault; you changed what the customer experiences. That is exactly what a VHM strategy buys.

How an FMEA row becomes a monitored condition

This is the practical bridge. Each FMEA concept has a direct counterpart in a health-management design, and walking the mapping turns a static analysis into a monitoring requirement.

Failure mode

The fault hypothesis a monitor must distinguish from healthy operation.

Failure cause

The root condition; its field rate is the failure rate λ that feeds Frequency and prognostic models.

Detection rating (D)

Diagnostic coverage: a low D means high coverage, a monitor that almost always catches the fault.

Current detection control

For MSR this is literally the on-board monitor and its system response, not a bench test.

Degradation vs random

Degradation modes (wear, fouling, aging) are prognosable and get an RUL estimate; random modes get detect-and-respond.

Recommended action

Often becomes "add a monitor", "raise diagnostic coverage", or "add a prognostic feature", a requirement handed to the VHM team.

FMEA tells you what can fail and how badly. FMECA (the C is for Criticality) adds how much it matters in aggregate, by weighting each mode with how often it is expected to occur. It comes from the reliability lineage (MIL-STD-1629A, now IEC 60812) and is the natural choice when you have failure-rate data, exactly what a telemetry fleet provides.

There are two ways to do it. The qualitative route plots every mode on a criticality matrix of severity against occurrence; modes drifting to the upper right are the ones to attack. The quantitative route computes a mode criticality number:

C_m = β · α · λ_p · t

where λ_p is the part's failure rate, α is the fraction of that rate attributable to this mode, β is the chance the mode actually produces the effect, and t is the operating time. Sum the modes of an item to get its item criticality, then rank. The point is the same as Action Priority, focus finite effort, but expressed in failures per hour rather than a category.

FMEA is bottom-up: start at a component, ask what its failure does. Fault Tree Analysis is top-down: start at one undesired event and decompose it into the combinations of lower causes that produce it, using logic gates. They are complements, not rivals. FMEA gives breadth, every mode gets a look. FTA gives depth on one critical event, and crucially it captures combinations: FMEA naturally handles single failures, while an AND gate in a fault tree captures the case where two things must fail together.

The most useful picture for a review meeting is the bowtie, which puts a single top event in the middle and shows both halves of the risk story at once. On the left are the threats (causes) and the prevention barriers that lower their occurrence. On the right are the consequences and the mitigation barriers, including on-board monitoring, that limit the damage. It is the cleanest way to show how prevention and detection do different jobs.

An FMEA is not the end of the paperwork chain; it is the source of it. The findings flow into the documents that actually run the factory. Skipping this is how a beautiful FMEA still ships defects: the analysis never reached the line.

It works like a relay. The DFMEA flags features whose variation would hurt safety or function, the special characteristics. Those get special symbols on the drawing and are handed to the PFMEA, which figures out how the process could compromise them. The PFMEA's controls become the Control Plan, the operating document that says, per characteristic, what is measured, how, how often, and what to do when it goes out of bounds (the reaction plan). Finally, the whole stack is bundled into the PPAP, the package a supplier submits to prove it can make the part to spec before mass production starts.

A few hard-won habits separate FMEAs that prevent failures from FMEAs that just fill a binder.

• Start from functions, not parts. List what each item must do, then ask how each function can fail. A part-by-part list misses the failures that live in interactions and interfaces.
• One mode, one row, one severity. If a single mode has two very different effects, score severity on the worst one. Do not average; averaging makes a safety risk look like an annoyance.
• Detection is the consolation prize. If your only action is "add an inspection," you have managed the symptom, not the disease. Spend effort on occurrence first (see Section 10).
• Keep severity stable. Severity comes from the effect, not from how rare or detectable the cause is. Do not lower severity because you added a test; that is double-counting.
• Make it living. An FMEA written once and filed is worthless within a year. Feed it field returns, warranty data, and every design or process change. The dashed loop in Figure 1 is the whole point.
• Special characteristics flow downstream. A design weakness you cannot fully eliminate becomes a controlled characteristic on the drawing and a watched item on the PFMEA. That is how the DFMEA protects the PFMEA.
• Calibrate your scales first. Agree on what each S, O, and D rating means before the meeting. Otherwise everyone scores 5 to avoid argument, and the analysis tells you nothing.

A pocket glossary

Failure mode

The specific way an item fails to meet its function (open, short, leak, drift), stated at the item's level.

Special characteristic

A feature whose variation could affect safety or compliance, requiring extra control on the process.

Poka-yoke

Mistake-proofing: a fixture or design that makes the wrong action physically impossible.

Prevention vs detection control

Prevention lowers occurrence by stopping the cause; detection lowers the detection score by catching the result. Only prevention reduces real risk.

Action Priority (AP)

The 2019 High / Medium / Low decision rule that replaces RPN as the trigger for action, weighting severity first.

1. AIAG & VDA. Failure Mode and Effects Analysis (FMEA) Handbook, 1st edition, 2019. The harmonized standard that introduced the seven-step method and Action Priority; the canonical source for the S/O/D and AP tables referenced throughout this guide.
2. AIAG. Potential Failure Mode and Effects Analysis (FMEA), 4th edition, 2008. The earlier RPN-based reference, still common in legacy programs; useful for understanding the transition described in Section 7.
3. SAE J1739. Potential FMEA in Design, Manufacturing and Assembly Processes. SAE's parallel recommended practice for DFMEA and PFMEA in automotive contexts.
4. Stamatis, D. H. Failure Mode and Effect Analysis: FMEA from Theory to Execution, 2nd edition, ASQ Quality Press. A practitioner-oriented treatment with extensive worked examples.
5. IEC 60812. Failure modes and effects analysis (FMEA and FMECA). The international standard covering FMEA and its criticality-weighted extension, FMECA, for general engineering.
6. ISO 26262. Road vehicles, Functional safety. Where DFMEA findings on safety-relevant items (such as the torque monitor in Section 11) connect to ASIL determination and safety goals.