FMEA and FTA analyze failure from opposite directions. FMEA (Failure Mode and Effects Analysis) works bottom-up: it starts at individual components or process steps, lists how each could fail, and traces the effects upward. FTA (Fault Tree Analysis) works top-down: it starts at one undesired failure event and works backward through logic gates to the combinations of causes that could produce it.
They are not rivals, and picking one is usually the wrong question. FMEA is inductive and broad, good at cataloging every way things can go wrong one at a time. FTA is deductive and focused, good at showing how several failures combine to cause one catastrophe. This guide explains each direction, where they differ, when to reach for which, and how strong safety programs run both together.
What is FMEA, and why is it bottom-up?
FMEA is a bottom-up, inductive method. You start at the bottom, individual components in a design or individual steps in a process, and for each one you ask: how could this fail? Then you trace each failure mode upward to its effect on the system and the customer, and you score it on severity, occurrence, and detection to rank where to act first. The reasoning runs from cause to effect: given this part fails this way, what happens?
The strength of the bottom-up approach is coverage. FMEA forces a team to walk every component or step and consider its failure modes systematically, so it catches the quiet, single-point failures that a big-picture view would skip. Its weakness is the mirror image: because it looks at failure modes one at a time, it is not built to show how combinations of failures interact to cause one big event. Our full FMEA guide covers the scoring mechanics in depth.
What is FTA, and why is it top-down?
FTA is a top-down, deductive method. You start at the top with a single undesired event, the "top event", something specific and serious like "brake system loses pressure" or "reactor overheats", and you work downward, asking what could cause it. Each cause is broken into its own causes, connected by logic gates: an OR gate means any one input is enough to cause the event above it, an AND gate means all inputs must occur together. You keep decomposing until you reach basic events you can no longer usefully break down. The result is a tree that shows every path, and every combination of paths, that leads to the top event.
The strength of the top-down approach is that it captures combinations and lets you put numbers on them: if you know the probability of each basic event, the gate logic lets you calculate the probability of the top event, which is why regulators in aerospace and nuclear ask for fault trees as safety evidence. Its weakness is scope: a fault tree analyzes one top event at a time, so a failure mode that does not feed your chosen event simply is not in the tree.
How do FMEA and FTA differ in practice?
The direction is the headline, but the practical differences follow from it: what each starts with, what logic it uses, what it produces, and what it is blind to.
| FMEA | FTA | |
|---|---|---|
| Direction | Bottom-up | Top-down |
| Logic | Inductive (cause to effect) | Deductive (effect to cause) |
| Starts from | Every component or process step | One undesired top event |
| Handles combinations? | Weak; one failure mode at a time | Strong; AND/OR gates model combinations |
| Main output | Ranked list of failure modes and actions | Logic tree and top-event probability |
| Best at | Broad coverage, single-point failures | Focused analysis of one serious event |
| Blind spot | Interacting failures across components | Failure modes outside the chosen event |
When should you use FMEA versus FTA?
Reach for FMEA when you need broad coverage and you do not yet know where the problems are: early in design or process development, when qualifying a new line, or whenever you want a systematic sweep of everything that could go wrong so nothing is skipped. FMEA is the workhorse for day-to-day quality and reliability because it catalogs single-point failures and ranks them for action.
Reach for FTA when one specific failure is serious enough to justify a focused investigation, especially a safety or catastrophic event where you need to understand how causes combine and you need a probability you can defend to a regulator. FTA is also the natural tool when a bad event has already happened and you want to map every path that could have produced it, which is why it overlaps with root cause analysis. A quick 5 whys handles a simple single-thread cause; a fault tree handles the case where several conditions had to line up. The full method has its own fault tree analysis guide.
A concrete example makes the split clear. Imagine a filling line that occasionally ships an under-filled bottle. An FMEA on that line lists dozens of failure modes across every step, worn nozzle, drifting sensor, wrong recipe, low supply pressure, and ranks each on severity, occurrence, and detection. It is a broad inventory of everything that could go wrong. An FTA takes the single top event, "bottle ships under-filled," and asks what combination of conditions had to occur for one to escape: the fill was short and the check-weigher missed it and the reject gate failed. The FMEA tells you where to spend prevention effort across the whole line; the fault tree tells you why the layers of protection let one through. You usually want both answers, which is why the two methods end up side by side rather than in competition.
How do you use FMEA and FTA together?
The strongest programs do not choose; they run both, because each covers the other's blind spot. FMEA finds the failure modes that a top-down view would miss, and FTA reveals the dangerous combinations that a one-at-a-time view cannot see. A common, practical way to combine them:
- Start broad with FMEA. Sweep the design or process bottom-up, list the failure modes, and rank them by severity, occurrence, and detection. This is your wide net.
- Pick the top events from the worst FMEA results. The highest-severity failure modes, the ones that can hurt someone or take down the system, become candidate top events for a fault tree. FMEA tells you which events are worth the deeper analysis.
- Build a fault tree for each top event. Work top-down from that event through AND and OR gates to the basic causes, so you see every path and every combination that could produce it, including ones FMEA scored separately and never connected.
- Quantify where it matters. If you have failure-rate data for the basic events, use the gate logic to estimate the top event's probability, turning a qualitative worry into a number you can compare and defend.
- Feed the tree's findings back into the FMEA. A combination the fault tree exposes, or a cause it shows is shared across several branches, becomes a detection or prevention action back on the FMEA worksheet, closing the loop.
What do the standards say?
The sources behind FMEA and FTA
- The American Society for Quality describes FMEA as a bottom-up, step-by-step approach for identifying all possible failures in a design, process, product, or service, so problems can be corrected before they reach the customer (ASQ, What Is FMEA?).
- Fault Tree Analysis has its own international standard, IEC 61025, which describes the top-down deductive method, its event and gate symbols, and how to build and evaluate a fault tree (IEC 61025:2006).
- NASA's Fault Tree Handbook with Aerospace Applications (2002), published by the Office of Safety and Mission Assurance, is a widely used reference for FTA methodology and quantification in high-consequence systems (NASA Fault Tree Handbook).
How does a connected floor support both methods?
Whether you rank failure modes bottom-up or estimate a top event top-down, both methods run on failure data that has to be true. FMEA's occurrence scores and FTA's basic-event probabilities are the same kind of claim, how often something actually fails, and both go stale when defect counts, escapes, and equipment failures live on clipboards and get reconstructed from memory. When that data is captured live at the point of work, tied to the line, the machine, and the cause, FMEA occurrence can be re-scored against reality and FTA probabilities rest on real failure rates instead of estimates. That live feedback is what Harmony gives a plant, working alongside your existing systems with no rip-and-replace. The processor in our CLS case study moved from failure data found the next morning to failure data visible during the shift, which is the condition both a bottom-up worksheet and a top-down tree need to stay honest. The same live signal strengthens the design FMEA upstream and the corrective actions downstream. See how the capture works on the features overview.