Fault Tree Analysis (FTA): A Deductive approach - Part 2

In the previous blog post, we talked about the theory behind the FTA. In this post, we are going to do a concrete example of an FTA

A quick example: "Vehicle does not steer"

To see how the pieces fit together, take a safety-critical top event from an automated vehicle: the vehicle does not steer. Loss of steering can happen in several independent ways, so directly beneath the top event sits an OR gate: any one branch alone is enough to cause it.

Fig: FTA example

The first branch is a mechanical failure of the steering rack or linkage. It's a single basic event, and because it sits directly under the top OR gate on its own, it's a single point of failure. The second branch is loss of steering assist. It is designed to tolerate faults, assist is lost only if the primary actuator fails and its backup fails, so this branch sits under an AND gate, and both root faults must occur together to matter. The third branch, loss of steering command, sits under an OR gate of its own: either a steering-ECU fault or a communication-bus error can cut the command path.

The diagram shows at a glance that the mechanical linkage is a lone weak point, while the steering-assist path is protected by redundancy. Scale that same logic up across an entire mission-critical system, and you can see why the method is so effective at revealing exactly what can go wrong and why.

How an FTA is done

In practice the workflow is consistent. You define the top event and the boundaries of the analysis like how deep to go, what's in scope. You understand the system and its operating modes. You construct the tree downward, gate by gate, to basic events. Then you analyze it qualitatively to extract minimal cut sets and spot single points of failure and common-cause vulnerabilities. If you have failure-rate data, you go a step further and analyze it quantitatively to calculate the actual probability of the top event. Finally, you interpret and act: redesign, add redundancy, or change inspection intervals to break the dangerous cut sets.

Where is an FTA used

FTA shows up wherever failure is expensive or dangerous: aerospace and defense, nuclear and chemical process plants, automotive systems like braking, airbags, and increasingly driver-assistance and autonomy, medical devices, and manufacturing robotics. It's even used in software and site-reliability engineering to reason about outages, and its close relative the "attack tree" applies the same logic to cybersecurity.

FTA vs. FMEA

FTA is often mentioned alongside FMEA (Failure Mode and Effects Analysis), and it helps to see them as opposites that complement each other. FTA is top-down: start with one failure and trace its causes. FMEA is bottom-up: start with each component, ask how it could fail, and follow the effects upward. FTA is brilliant for understanding how one catastrophic event can arise from combinations of faults; FMEA is brilliant for systematically cataloguing many possible failure modes and prioritizing them. Serious safety programs frequently use both.

Strengths and limits

FTA's strengths: it makes complex failure logic visual and communicable, it exposes single points of failure, and it supports both qualitative insight and quantitative probability. But it has limitations as well that are worth knowing. It's time-consuming to build well. It treats events as mostly binary, either working or failed and struggles with partial or degraded states. A standard fault tree is a static snapshot that doesn't naturally capture timing or wear-out. And its quality is only as good as the analyst's understanding of the system; a missed failure path simply won't appear.

The takeaway

At its core, Fault Tree Analysis is a disciplined way of answering "what could go wrong, and what would it take?" It turns vague worry into a structured map of failure, and that map is what lets engineers spend their effort exactly where the system is weakest.