A functional safety assessor selects one hazard from the risk file and asks a fault-tree question. Which combinations of failures could produce this event, and how probable is the worst case? A failure mode inventory for risk supplies the basic events. Fault Tree Analysis (FTA), sometimes referred to as tree fault or failure tree analysis, models how individually harmless faults can combine to produce a catastrophic outcome. We’ve watched this gap surface late in programs we’ve worked with, when reworking a redundancy scheme costs months instead of days during architecture design.

This guide covers how fault trees are built, how the same logic applies to mechanical and software failures, and how to keep cut sets tied to requirements and tests throughout every audit.

What Is Fault Tree Analysis (FTA)?

In FTA, analysts start from one defined undesired outcome, called the top event, and work backward through every combination of causes that could produce it. The method identifies causes, or combinations of causes, that can lead to the defined top event, which is how the International Electrotechnical Commission (IEC) 61025 defines the method. That direction of reasoning separates fault trees from inductive methods like Failure Mode and Effects Analysis (FMEA), which start from individual component failures and reason forward to their effects. We commonly use IEC 61025 as the reference for FTA symbols, gates, and analysis approaches, while domain safety handbooks and sector-specific practices supply additional methodology.

Where Fault Tree Analysis Pays Off

The real payoff shows up in combinations a single-failure review never surfaces. Bottom-up methods catch the failure modes analysts already expect. A fault tree forces the same analysts to ask which combinations of ordinary failures add up to the one outcome nobody can tolerate, and that reframing routinely turns up a shared component sitting under two branches that were supposed to be independent.

The same tree also produces the math a functional safety case needs. Once basic events carry reliability data, Boolean reduction turns the diagram into minimal cut sets ranked by probability, which is how a program demonstrates it meets a quantitative target, such as the FAA’s catastrophic-failure threshold, rather than asserting the architecture is safe.

That documented chain of reasoning is what holds up under audit. A completed fault tree shows an assessor exactly which single points of failure the design still carries and which redundancies share a hidden weakness, in a form a reviewer can trace rather than take on faith.

When Fault Tree Analysis Is Worth the Effort

Not every failure mode needs a full fault tree, and building one for a low-consequence issue burns time the analysis doesn’t repay. The method earns its keep on a narrower set of situations:

• Catastrophic top events: the failure could hurt someone or damage the environment, and the team needs every path to that outcome mapped, not just the obvious ones.
• Redundancy and common-cause risk: the architecture leans on backup systems, and the analysis needs to confirm those backups don’t secretly share a single weakness.
• Regulatory or certification targets: the program must demonstrate a quantitative probability target, and a fault tree is the artifact that shows the math behind the claim.

Outside those cases, a lighter method such as FMEA usually gets the team to the same design decisions faster.

How to conduct FTA

Building a fault tree starts by defining the top event and connecting contributing events with Boolean logic gates. Each branch should stay tied to the failure question so the tree does not become a catalog of every possible defect.

Start by Defining the Top Event

The analysis starts with the one failure that absolutely can’t happen, such as unintended braking or loss of thrust. Getting the scope right is an engineering judgment. Being too general becomes unmanageable, and being too specific misses the broader failure picture. Complex systems often have several fault trees, one per top event, particularly for missions with distinct hazard phases. We use that boundary to keep each tree focused on the failure combination it must explain and the hazard the team needs to control.

Map Intermediate and Basic Events

From the top event, we ask what could cause it, then repeat that question at each level down. Intermediate events, drawn as rectangles, occur because of other events. Basic events, drawn as circles, are the initiating faults that need no further development, typically a component failure with known reliability data.

An undeveloped event, drawn as a diamond, marks a fault we chose not to expand, either insufficiently consequential or lacking data. Analysts should mark those boundaries explicitly, since a fault tree can never guarantee completeness, and a probability computed from an incomplete tree can be unconservative, exactly the hidden assumption an assessor will challenge.

Connect Events With Logic Gates

Gates define how lower-level events combine. An AND gate (all of its inputs must occur before it fires) is how redundancy shows up in a tree, while an OR gate (any single input is enough to fire it) covers the alternative case. Specialized gates cover other structures. The inhibit gate passes an input only under a conditioning event, the voting gates model k-out-of-n redundancy, and the priority AND gate requires inputs in sequence.

The finished tree gives us more than a diagram, since Boolean reduction of the gate logic produces minimal cut sets, the smallest combinations of basic events causing the top event. A one-component cut set is a single point of failure, while two-component cut sets are double failures that defeat a redundancy. With reliability data, the tree also supports quantitative analysis of the top event’s probability.

Catastrophic transport-aircraft failure conditions must meet catastrophic failure probability targets of no more than 1 × 10⁻⁹ per flight hour under Federal Aviation Administration (FAA) system safety assessment expectations. Fault trees commonly demonstrate an architecture that reaches the target.

How an FTA Exposes Hidden Failure Combinations: 3 Examples

The same logic applies to mechanical systems, software-related failures, and redundant safety architectures, and a sample fault tree from each domain shows how seemingly independent faults prove coupled.

Try the Method on a Mechanical System

A mechanical fault tree can use motor overheating as the top event. An OR gate splits it into a motor malfunction, a basic event, and excessive current reaching the motor, which needs development. Excessive current sits under an AND gate, requiring current in the circuit and a fuse that fails closed.

The circuit overcurrent splits under an OR gate into a wiring short, a basic event, and a voltage surge, left as an undeveloped diamond. The analysis yields a two-component minimal cut set, the fuse fails closed and the wiring shorts. A failed fuse in a healthy circuit does nothing, and a short with a working fuse gets interrupted, but together they overheat the motor.

That combination is what a bottom-up, one-failure-at-a-time analysis tends to miss, and fault trees also expose common cause failures this way. In a redundant fire pump system with no water as the top event, the same basic event, engine failure, appearing under both pump branches of an AND gate shows one shared engine quietly cancels the redundancy.

Apply the Same Logic to Software-Related Failure

When the failure runs through the software, the logic holds, but the arithmetic changes. In an infusion pump, unintended drug overdose can be the top event. An AND gate splits it into two conditions that must occur together: a hazardous over-delivery condition and a failure of the detection path meant to catch it before it reaches the patient. The over-delivery condition sits under its own AND gate, where the valve sticks open, and the flow sensor gives a false reading. The detection failure sits under an OR gate, where any single alarm failure lets an over-delivery underway go unnoticed.

Over-delivery alone requires two coincident hardware faults, and a software-related alarm failure can’t cause an overdose by itself. It can only defeat detection once over-delivery has started, which is why the top event needs both branches together, not either one alone. For software basic events, we avoid treating them like hardware failure rates unless the applicable standard and evidence support that choice. Medical device and automotive programs commonly separate software faults, introduced through specification or implementation, from randomly occurring hardware faults, so the two kinds of reliability reasoning stay distinct.

Extend the Analysis to a Redundant Safety System

Consider an aircraft brake system, where the top event is complete loss of braking on landing. An AND gate splits it into two parallel hydraulic systems failing together, since either system alone can stop the aircraft.

Each hydraulic branch fails through an OR gate covering a pump failure, a basic event, or a line rupture, another basic event. Taken alone, that yields no single point of failure, since both branches would have to fail independently for the top event to occur.

The tree earns its place when the two branches share a reservoir or a single pump drives both circuits under normal load. That shared basic event under both AND-gate inputs turns two supposedly independent systems into one common-cause failure, the same pattern a bottom-up review of each branch in isolation would miss.

Differences between FTA and FMEA

FTA and FMEA differ in four practical ways:

Aspect	Fault Tree Analysis	FMEA
Direction	Deductive, top-down	Inductive, bottom-up
Starting point	One undesired top event	Individual component failure modes
Failure scope	Combinations of failures	Generally, single points of failure
Output	Graphical tree with minimal cut sets	Tabular worksheet with Risk Priority Number (RPN) ranking

FTA models combinations of failures, traces common cause failures across subsystems, and can support a quantitative functional-safety target. FMEA fits earlier in design, when changes are cheapest, and the inventory is still being built.

For regulated programs, domain practice often settles the question. Aircraft safety assessment practice uses both, with lower-level failure-mode data feeding system-level fault trees. As Automotive Safety Integrity Level (ASIL) criticality increases, automotive programs often pair inductive and deductive analyses, drawing on our breakdown of automotive ASIL safety levels, while medical device risk analysis under ISO 14971 may also need to weigh sequences and combinations of events that an FMEA alone may not capture.

How to Build an FTA Template Auditors Can Follow

A useful FTA analysis template documents the decisions that make the diagram defensible under audit, especially when a reviewer asks why a branch stopped or a cut set led to a requirement.

Capture the FTA Decisions Behind the Diagram

A working FTA template captures the core decisions behind the tree, and these entries keep the assumptions, boundaries, input data, and results reviewable:

• Scope and problem statement: The system, its boundaries, and what the analysis decides.
• Top event statement: A precise undesired outcome, such as a pump failing to deliver flow, is drawn as the tree’s root.
• Assumptions and boundary conditions: Operating conditions, exclusions, and failure modes considered.
• Event hierarchy with gate logic: Every intermediate event is connected through a defined gate, down to basic and undeveloped events.
• Basic event data: Failure rates from equipment databases, manufacturer specifications, field history, or reliability handbooks.
• Cut set analysis: Minimal cut sets ranked by probability, with single-event cut sets flagged as single points of failure.
• Documentation and reporting: The reliability-target status and dominant contributing failure modes, with design comparisons where needed.

Audit problems often arise when a single-point failure’s derived requirement moves into another system, and the connection back to the hazard decays until an auditor pulls a sample. Keeping that requirement linked to its original top event and verification test, and flagging both the moment the hazard or mitigation changes, is what keeps the chain current as the design evolves.

Keep Symbols and Software Practical

A typical template should leave room for the standard FTA symbol set, covering basic, intermediate, and undeveloped events, house events, conditioning ellipses, and page-transfer triangles (the FAQ below breaks each down). Dedicated FTA software builds and quantifies fault trees and derives cut sets, with commercial and open-source options covering common cause modeling and Monte Carlo uncertainty analysis.

Automation is advancing on two fronts, but it still needs engineering judgment. Model-based safety analysis workflows can help generate fault trees and analyze cut sets from system models, and published approaches now use large language model approaches to suggest sub-causes while the human analyst leads the analysis.

Where Fault Tree Analysis Falls Short

A fault tree only models binary states. A component either works or it has failed, which means the method struggles with partial degradation and doesn’t capture the order events happen in, only which combinations occur. Complex systems can produce trees with hundreds of gates that become difficult to maintain as the design changes.

The bigger limitation shows up after the diagram is finished. A cut set identifies a single point of failure, but the mitigation requirement written against it often lives in a different system than the tree itself, and the link between them fades once the program moves past the safety review.

That gap turns a defensible piece of analysis into a static document nobody trusts by the next audit. The tree itself isn’t the weak point. What breaks down is the connection between the tree, the mitigation, and the test that’s supposed to prove it worked.

How Jama Connect Supports Fault Tree Analysis

Dedicated FTA tools draw fault trees. Jama Connect® can keep FTA outputs, such as top events, cut sets, and derived mitigations, connected to requirements and tests, and its Live Traceability™ flags a downstream requirement or test case as suspect the moment an upstream hazard or mitigation changes.

Jama Connect’s risk management capabilities support Preliminary Hazard Analysis (PHA) and FMEA aligned with ISO 14971 and IEC 60812. That means the failure mode inventory that populates fault tree basic events can live alongside the requirements it traces to, and a change to any requirement flags linked risk records and test cases for review. For teams running fault trees in a separate environment, linking or importing key FTA outputs into Jama Connect can help keep records from drifting apart.

How to Turn Fault Tree Findings Into Traceable Action

A practical first fault tree covers one top event developed to the limit of your reliability data. The cut sets it produces become a work list, covering single points of failure to redesign, double-failure combinations to monitor, and mitigations to write as requirements.

Jama Connect can keep those cut sets, the mitigations tied to them, and the verification tests connected as the design evolves, with results captured on the platform. If your next audit depends on that proof, start a free 30-day trial and see the workflow.

Frequently Asked Questions About Fault Tree Analysis

What is the difference between FTA and an FMEA?

They are complementary analyses that approach the same risk from opposite ends. FMEA provides component-level failure-mode data that populates basic events in fault trees, while FTA shows which combinations matter for the top event. Teams already running FMEA can reuse that data as a starting point rather than rebuilding it, a workflow that our guide to performing FMEA covers. Keeping both analyses tied to the same risk records in Jama Connect makes that reuse concrete.

What symbols are used in a fault tree diagram?

Circles represent basic events, rectangles represent intermediate events, and diamonds mark undeveloped events. The house shape marks external events that aren’t faults, ellipses record conditioning events, and triangles transfer branches between pages. Gates include AND, OR, inhibit, voting, exclusive OR, and priority AND, matching the team’s standard, tool, and reviewer. Consistency matters more than completeness. A small, consistent symbol set holds up better under audit than borrowed conventions.

Can FTA be automated?

Parts of it can be automated. Model-based safety analysis tools can generate fault trees, derive minimal cut sets, and calculate failure rates from system models, though automated generation still depends on the quality of the failure-mode model. Current AI approaches position large language models as co-pilots that suggest sub-causes while the analyst leads. Whichever tool generates the sub-causes, the result still has to trace back to a real requirement and test to hold up under audit, where Jama Connect’s traceability matters more than the tree-drawing itself.

When in the development lifecycle should FTA be performed?

FTA should be performed early in design and again whenever the system changes. Aerospace teams may use fault trees during early architecture assessment to derive safety requirements, then again to check the implemented design, a pattern the classic V-model development lifecycle mirrors. Early trees shape the architecture, and later trees confirm the built system meets the target. Functional safety teams generally reassess the tree whenever the architecture, hazards, mitigations, or reliability data change.