FMEA vs FTA: When to Use Fault Tree Analysis vs Failure Mode Analysis
A Severity = 9 effect lands in your DFMEA: loss of service braking. You have the failure modes, the causes, and an Action Priority of High. Then the program manager asks the one question the FMEA cannot answer — “what is the probability the brakes actually fail?” FMEA rates that risk on an ordinal 1–10 scale; it never produces a probability. Fault Tree Analysis does. The two methods are not competitors deciding which is “better” — they reason in opposite directions and answer different questions, and knowing which one to reach for saves weeks of pointing the wrong tool at a problem.
This comparison lays out how each method reasons, where each one is strong and blind, and how a quality or reliability engineer decides between them — or runs both.
The criteria that actually separate them
Most “FMEA vs FTA” tables list a dozen rows. Four criteria decide real cases: direction of reasoning, single-point versus combination failures, qualitative versus quantitative output, and breadth versus depth. Everything else follows from those.
FMEA: inductive, broad, one failure mode at a time
FMEA reasons forward (inductively): start at a component or process step, ask how each function can fail, then trace each failure mode out to its effect. It is exhaustive across breadth — every function gets examined — and it scores each failure chain with Severity, Occurrence, and Detection to set priority. IEC 60812 is the international procedure for it, alongside the AIAG-VDA handbook in automotive; ASQ’s FMEA overview is a solid plain-language reference for the method.
Its structural blind spot is combinations. FMEA evaluates one failure mode at a time, so a hazard that only occurs when two independent things fail together is easy to miss — each part looks low-risk in isolation. That same single-axis limitation is why a high RPN is not always the biggest risk: the ordinal math flattens interactions the analysis never modeled.
FTA: deductive, deep, built for combinations
FTA reasons backward (deductively): start from one undesired top event — “loss of service braking” — and decompose it through Boolean logic gates into the combinations of lower-level basic events that can cause it. An OR gate means any input triggers the event; an AND gate means all inputs must occur together. That gate structure is exactly what captures the multi-point and common-cause failures FMEA misses.
When the basic-event probabilities are known, FTA multiplies and sums them through the gates to produce a quantitative probability for the top event — the number the program manager asked for. IEC 61025 is the standard for the method, and NASA’s fault tree analysis reference is a canonical free source for the gate logic and math.
Side by side
| Criterion | FMEA | FTA |
|---|---|---|
| Reasoning direction | Inductive (cause → effect) | Deductive (effect → causes) |
| Starting point | Every component / function | One top undesired event |
| Failure scope | Single failure mode at a time | Combinations via AND / OR gates |
| Output | Ordinal S, O, D → RPN or AP | Quantitative top-event probability |
| Coverage shape | Broad across the whole system | Deep on one critical event |
| Standard | IEC 60812; AIAG-VDA | IEC 61025; NASA FTH |
| Best when | Surfacing and prioritizing all risks | Quantifying one safety-critical event |
Use them together — the practitioner workflow
The honest answer for safety-critical work is not “pick one.” The two methods chain. Run the FMEA first to surface failure modes across the design. For each Severity 9–10 effect — the ones where occurrence and detection cannot buy down the risk — spin off an FTA with that effect as the top event. The FTA quantifies the probability and exposes the combination causes the FMEA evaluated only in isolation. Then feed those basic events back into the FMEA as causes you had not listed. This is the same closed-loop discipline that connects analysis to action everywhere in a mature program; functional-safety work formalizes it, and our software FMEA under ISO 26262 shows the inductive and deductive analyses running in parallel as the standard requires.
Verdict by who you are
Tier supplier doing PFMEA for IATF 16949: FMEA is your required, day-to-day tool — it is the customer deliverable and the audit artifact. Reach for FTA only on the handful of safety-critical top events where a probability is genuinely needed. FTA is rarely a customer requirement at the process level.
Reliability engineer computing system failure probability or MTBF: FTA is your primary method — it produces the quantitative number FMEA cannot, and its gate logic models redundancy and common-cause correctly. Use FMEA to populate the basic events. This split is well established in aerospace, where aerospace FMEA and FRACAS integration sit alongside fault trees in the same reliability program.
Functional-safety engineer under ISO 26262: you need both. The standard expects inductive analysis (FMEA) and deductive analysis (FTA) because neither alone covers single-point and combination faults completely.
Start with the method your question demands
If the question is “what can go wrong and which risks do we attack first,” that is FMEA — and the RPN and Action Priority calculator turns your S, O, and D ratings into a priority you can defend in a review. If the question is “how likely is this specific catastrophe, and what combination causes it,” that is FTA. Pick the tool by the direction of the question, not by which one your team happens to know better.