What Is Fault Tree Analysis (FTA)? How It Works and When to Use It
|
What Is Fault Tree Analysis (FTA)? How It Works and When to Use It
Fault tree analysis (FTA) helps engineering teams figure out every way a system could fail before it ships. You pick the worst thing that could happen, then work backward to find every combination of events that could cause it. When those findings stay tied to the actual design, the analysis catches dangerous paths early. That’s why regulators across aerospace, automotive, medical device, and nuclear programs expect it.
The U.S. Nuclear Regulatory Commission showed what this looks like in practice back in the mid-1970s when it published WASH-1400, one of the first big risk assessments of a nuclear power plant. A later NRC report said the work gave insights into real incidents that were hard to get any other way. The method hasn’t changed much since then, but keeping findings connected to the design is still where most teams run into trouble.
This guide covers what fault tree analysis is, how to build one, how it compares to FMEA, and where that connection usually breaks down.
What Is Fault Tree Analysis (FTA)?
Fault tree analysis (FTA) is a top-down method where you start with the worst outcome your system could produce, called the top event, and trace backward through layers of causes connected by logic gates. Instead of asking “what could go wrong?” in general, you pick one specific failure and work out whether the design actually prevents it.
That’s what sets it apart from most other safety methods. You model how component failures, human errors, environmental conditions, and system interactions can combine to cause that one outcome. The goal is to find every path to the failure and figure out which ones need design attention right now.
Fault Tree Analysis vs. Failure Mode and Effects Analysis (FMEA)
Fault tree analysis and FMEA (failure mode and effects analysis) answer different questions, and most teams use both. Here’s where they split and why the handoff between them often breaks.
Attribute
| Attribute | Fault Tree Analysis | FMEA |
| Direction | Top-down (deductive) | Bottom-up (inductive) |
| Starting point | A specific system failure | Individual component failure modes |
| Primary question | “How can this failure occur?” | “What happens if this component fails?” |
| Quantitative output | Failure probability modeling | Risk ranking or prioritization |
| External events | Can include environmental and human factors | Usually narrower in scope |
failure mode from FMEA often feeds the fault tree, and the fault tree produces a safety requirement. Testing gets planned against that requirement, but the link back to the original hazard can get weak over time, especially when requirements change and nobody reassesses the downstream work.
Why Fault Tree Analysis Matters
Most safety methods look at failures one at a time. Fault tree analysis is one of the few that shows how failures combine. A sensor glitch on its own might be harmless, but pair it with an operator error and a backup system that shares the same power supply, and you’ve got a path to a catastrophic event that nobody saw coming.
That’s the real value of fault tree analysis: it forces you to think about how independent your redundancies actually are, whether your backup systems share common weaknesses, and which single points of failure the design still has. It also gives you something you can show to regulators and auditors, not just an opinion that the system is safe, but a documented chain of reasoning that proves it.
When to Use Fault Tree Analysis
Fault tree analysis is worth the effort in specific situations. It takes real work to do well, so it helps to know when it pays off and when something simpler would do. The clearest use cases look like this:
- Catastrophic top events: When the failure you’re looking at could hurt people or damage the environment, fault tree analysis gives you a clear way to map every path to that failure.
- Redundancy and common-cause risk: If the design uses redundant systems, the analysis can show whether those systems are truly independent or share a weakness the architecture missed.
- Quantitative safety targets: Because fault tree analysis supports probability modeling, teams can calculate whether a design meets a safety target and decide where to add redundancy or change the architecture.
- Regulatory and certification needs: NASA includes fault tree analysis in its system safety standards. Programs under DO-178C (airborne software), ISO 26262 (automotive functional safety), IEC 62304 (medical device software), and FDA design controls all use it because regulators want clear, documented reasoning about how failures happen.
If the top event isn’t catastrophic or the system isn’t complex enough for failures to combine in non-obvious ways, FMEA on its own may be enough.
How Fault Tree Analysis Works
The process starts with one question: what’s the one failure that absolutely can’t happen? You pick that as the top event and work backward through every combination of causes that could lead to it. The tree uses four main symbols (defined by IEC 61025):
- Top event: The system failure you’re analyzing.
- Basic event: A root cause where you stop breaking things down.
- AND gate: Every failure in the group has to happen at the same time for the top event to occur.
- OR gate: Any single failure on its own is enough to cause the top event.
You define the top event first. A broad one makes the tree unmanageable, so you want something specific enough to act on but serious enough to justify the work. From there, you break down causes layer by layer and connect them with AND and OR gates based on the system architecture, interfaces, and known hazards.
Once the tree is built, you look for the minimal cut sets, the smallest groups of failures that can cause the top event. Order-1 cut sets (single points of failure) need attention first because they show where the system is weaker than the team thought. If you have failure probability data, you can also put numbers on the tree and compare risk against safety targets.
Fault Tree Analysis Example: Medical Device
Take an infusion pump where the top event is “unintended drug overdose.” An OR gate at the top splits into two paths: either the pump delivers too much, or the system fails to catch the over-delivery. The first path breaks down through an AND gate (valve sticks open AND flow sensor gives a false reading at the same time). The second is an OR gate where any single alarm failure lets the overdose go unnoticed.
When you run the cut sets, you might find that one alarm circuit failure on its own is enough to cause the top event. That’s an Order-1 cut set, and it tells you the design needs a backup alarm or an independent shutoff. That’s where fault tree analysis changes the design, not just documents the risk. NASA, nuclear, and automotive teams all use the same logic on their own systems, and the analysis pays off in every case when its findings stay connected to the requirements and tests that prove the risk was handled.
Limitations and Where Fault Tree Analysis Falls Short
Fault tree analysis has real limits. It only models binary states (working or failed), it can’t capture the order events happen in, and complex systems produce trees that are hard to maintain. But the bigger problem is what happens after. Teams rarely struggle with the analysis itself. What breaks is the handoff:
- Disconnected mitigations: The tree identifies a single-point failure, but the requirement that came from it lives in a different system and loses its connection to the original hazard.
- Post-review requirement changes: A test or design constraint downstream doesn’t get updated because nobody sees the upstream change fast enough.
- Surface-level audit trails: The analysis, requirement, risk control, and test all exist on paper. But the connection between them is weak or outdated, and nobody notices until an auditor pulls a sample.
Once those links break, the tree stops being useful evidence and turns into a static document. NASA research shows that fixing a requirements error at the test stage can cost 21 to 78 times more than catching it during requirements, and that number climbs to 29 to over 1,500 times more in operations. If a fault tree analysis finding gets lost between the safety review and the requirement baseline, the program has already made the problem much more expensive to fix.
Keep Fault Tree Analysis Findings Connected to the Design
The best fault tree analysis doesn’t end with a clean diagram. It ends with a changed design, a stronger requirement, a better test, or a risk control that stays linked as the product changes over time. Teams that keep those connections strong see 1.8X faster defect detection, 2.1X faster test execution, and 2.4X lower test failure rates compared to teams in the bottom quartile.
If you want those kinds of results, Jama Connect® is built for exactly this. Its Live Traceability™ approach flags when a change upstream affects something downstream, so the full chain from hazard to requirement to test stays visible as the project moves forward. Try Jama Connect free for 30 days.
Frequently Asked Questions About Fault Tree Analysis
What is the difference between fault tree analysis and FMEA?
Fault tree analysis picks a specific system failure and traces backward to find every combination of events that could cause it. FMEA goes the other direction, starting with individual parts and asking what happens when each one fails. The two work well together because fault tree analysis catches dangerous combinations while FMEA catches failure modes that might not show up in a top-down view.
When should you use fault tree analysis instead of other safety methods?
Fault tree analysis works best when the top event is catastrophic and you need to understand how failures combine to cause it. It’s the go-to when a program needs to put numbers on failure probabilities or show regulators clear safety evidence.
What is the difference between quantitative and qualitative fault tree analysis?
Qualitative fault tree analysis maps the failure paths and identifies the cut sets without calculating probabilities. It tells you which failures are dangerous and where single points of failure exist. Quantitative fault tree analysis goes further by assigning failure probability data to each basic event and calculating the overall likelihood of the top event. Use quantitative when you need to prove a design meets a specific safety target or compare risk between design options.
Can you do fault tree analysis without specialized software?
You can build simple fault trees with any diagramming tool or even on a whiteboard. The tree itself doesn’t need special software. Where things get harder is keeping the findings connected to requirements, tests, and risk controls as the design changes. That’s a traceability problem, and it’s where purpose-built tools like Jama Connect help most.
How do you keep fault tree analysis findings tied to the design?
The biggest risk is that findings get written down but never connected to the requirements, risk controls, or tests they should feed into. You need those connections to stay visible so that when something changes upstream, the downstream work gets checked too. Jama Connect’s Live Traceability does this by flagging when a change affects related work.
Director of Product and Solution Marketing at Jama Software
Mario Maldari is Director of Product and Solution Marketing at Jama Software, where he focuses on requirements management and systems engineering solutions for regulated industries. He brings over 2 decades of experience across solution architecture, technical pre-sales, and software quality, and holds patents in traceability and structured data. Before moving into product marketing, he worked directly with engineering teams to solve compliance and requirements challenges.
Latest posts by Mario Maldari (see all)