1. Define the Top Event
State a specific undesired condition, not a vague phrase such as “system failure”. Include the function, condition and boundary where practical. Example: Loss of commanded actuator movement when movement is required.
Fault Tree Analysis Project
Build a top-down Boolean model of credible event combinations that can produce a defined undesired top event. Analyse minimal cut sets, single-point paths, dependencies and optional quantitative probability with explicit exposure assumptions.
Top-Down Qualitative Quantitative
0
Events
0
Basic events
0
Minimal cut sets
0
Single-point cut sets
—
Top-event probability*
0%
Analysis health
Fault Tree Analysis Fundamentals
A practical guide to building, analysing and reviewing a credible fault tree.
Fault Tree Analysis (FTA) is a deductive, top-down method. It starts with a clearly defined undesired system state — the top event — and develops the credible combinations of lower-level events that can cause it. The tree uses Boolean logic to show how events combine. A good FTA is first a technically credible qualitative model; quantitative probability is useful only when the logic, data basis and dependency assumptions are justified.
2. Define Scope & Boundary
Document what is inside and outside the analysis, operating state, mission phase, environmental conditions, interfaces, assumptions and exclusions. The same top event can have a different tree under different operating conditions.
3. Develop Immediate Causes
Ask: What immediate events can cause this event? Decompose each intermediate event until the analysis reaches basic or deliberately undeveloped events supported by evidence, data or another analysis.
Top / Intermediate Event
A rectangular event represents a system state or failure condition that is further developed through lower-level causes. The top event is simply the highest event in the analysis.
Basic Event
A basic event is developed no further in this tree because it is sufficiently defined for the purpose of the analysis. It may be linked to reliability data, a component failure mode, a process condition or another supporting analysis.
Undeveloped Event
An undeveloped event is intentionally not analysed further, often because information is unavailable, the event is outside scope, or development is unnecessary for the decision being supported. Record the stopping rationale.
OR Gate
The output event occurs if one or more of its input events occur. An OR branch can therefore create single-event paths to the top event. Do not use OR merely because several possible causes exist — confirm each input is individually sufficient.
AND Gate
The output event occurs only when all specified input events occur in the required condition. AND gates are common in redundant/protected architectures, but apparent redundancy does not prove statistical independence.
Transfer / Further Analysis
Large FTAs are often modular. A complex event can be developed in another tree, subsystem analysis or specialist study. This app keeps the primary tree simple, so use evidence and notes to reference supporting analyses where necessary.
How to Read the Logic
OR example
“Electrical energy unavailable” may occur if the primary power feed is open OR the local power-conditioning unit fails. Either input is sufficient to create the parent event.
“Electrical energy unavailable” may occur if the primary power feed is open OR the local power-conditioning unit fails. Either input is sufficient to create the parent event.
AND example
“Erroneous feedback causes movement inhibition” may require the position sensor to provide incorrect feedback AND the diagnostic monitor to fail to detect it. Both conditions are required by that branch.
“Erroneous feedback causes movement inhibition” may require the position sensor to provide incorrect feedback AND the diagnostic monitor to fail to detect it. Both conditions are required by that branch.
Important: AND/OR gates express logical sufficiency, not probability by themselves. A logically correct AND gate can still be quantitatively misleading if the two inputs share a common cause, power source, software, environment, supplier, process or maintenance action.
Minimal Cut Sets & Single-Point Paths
Minimal Cut Set
A minimal cut set is the smallest combination of terminal events sufficient to cause the top event according to the tree logic. If any event can be removed and the combination no longer causes the top event, the set is minimal.
Cut-Set Order
An order-1 cut set contains one event, order-2 contains two events, and so on. Lower-order sets often deserve attention because fewer coincident failures are required, but consequence and exposure still matter.
Single-Point Cut Set
An order-1 minimal cut set means one terminal event alone can produce the top event. This can identify a single-point vulnerability, but whether it is acceptable depends on the applicable safety, reliability and design framework.
Qualitative Before Quantitative
Qualitative FTA
Checks the causal structure: completeness of credible pathways, correct gate logic, minimal cut sets, single-point contributors, dependencies, common causes and model boundaries. It remains useful even when trustworthy numerical reliability data are unavailable.
Quantitative FTA
Adds probabilities or rates to terminal events and propagates them through the tree. Quantification can help compare contributors and estimate top-event probability, but numerical precision does not compensate for poor logic, missing causes or unjustified independence assumptions.
Probability Inputs & Exposure Basis
Direct Probability
Use where a probability for the relevant exposure interval is already justified. Always state the basis: per mission, per demand, per operating interval, per item population, or another defined exposure.
Constant Failure Rate
For a constant hazard rate λ over a mission/exposure time t, this app calculates P = 1 − e−λt. This is an assumption-based model and is not suitable for every failure mechanism or lifecycle phase.
Historical Estimate
Observed failures divided by relevant opportunities can provide an empirical estimate, but the population must be comparable, sufficiently large and exposure-consistent. Small samples can produce unstable estimates.
Never enter a probability without its exposure basis. A value such as 8 × 10⁻⁵ is meaningless unless the reader knows whether it is per mission, per hour, per demand, per year, per production unit or another defined basis.
Common Cause, Dependency & Redundancy
Shared Power
Two nominally redundant channels may both depend on one supply, protection device, ground path, connector or distribution unit.
Shared Environment
Temperature, vibration, moisture, contamination, fire, EMI or physical damage may defeat multiple items simultaneously.
Shared Design / Software
Common algorithms, requirements, libraries, processors, component types or design errors can make failures correlated.
Shared Manufacture
A common supplier, material batch, special process, tooling issue, configuration error or inspection weakness may affect redundant items alike.
Shared Maintenance
A single maintenance action, incorrect procedure, configuration change or access error can defeat multiple protective paths.
Latent Failure
A protective function may fail silently and remain unavailable until another event occurs. Exposure time and proof-test/diagnostic effectiveness can therefore become important.
Redundant does not automatically mean independent. If an AND gate represents two supposedly independent failures, actively search for common-cause and dependency mechanisms before multiplying probabilities.
FTA Compared with FMEA
FMEA / FMECA — Bottom-Up
Starts with item or process failure modes and asks what local and higher-level effects may result. It is strong for systematic coverage of component/process failure modes.
FTA — Top-Down
Starts with one selected undesirable outcome and asks what combinations of events can cause it. It is particularly strong for redundancy, multiple-failure combinations, safety-critical top events and identifying single-point paths.
Use them together: FMEA can identify credible failure modes that populate an FTA; FTA can reveal combinations and system-level pathways that should be checked back against DFMEA/PFMEA, design controls, test strategy, FRACAS and reliability evidence.
Recommended FTA Workflow
1 · Define
Top event, purpose, boundary, operating state, interfaces, assumptions and acceptance/review authority.
2 · Decompose
Identify immediate credible causes and connect them using the correct AND/OR relationship.
3 · Develop
Continue until meaningful basic/undeveloped events are reached and stopping rules are justified.
4 · Review Logic
Challenge completeness, duplicated events, circular logic, event wording, branch sufficiency and common-cause exposure.
5 · Analyse
Generate minimal cut sets, identify single-point paths, then quantify only where suitable data and assumptions exist.
6 · Improve & Reassess
Target high-consequence or important contributors, verify actions, update the tree and document residual risk and limitations.
Common Modelling Mistakes
Vague Top Event
“System fails” is too broad. Define a specific function, condition and boundary so the analyst knows exactly what the tree must explain.
Using AND When OR is Correct
If either input alone can cause the parent event, the gate is OR. Incorrect gate choice can dramatically distort both cut sets and probability.
Stopping Too Early
“Component failure” may not be useful enough. Develop further where the decision needs a mechanism, design weakness, process cause or controllable contributor.
Ignoring Dependencies
Multiplying two tiny probabilities can create an unrealistically tiny result if both events share power, software, environment, manufacture or maintenance exposure.
False Precision
A top-event probability shown to many decimal places is not high-quality evidence if the basic-event data are rough estimates or the model is incomplete.
Forgetting Change Control
FTA is configuration-dependent. Design, supplier, software, architecture, mission profile or process changes may invalidate branches or probability assumptions.
Worked Aerospace Example
Use “Load Aerospace Example” in Define Project to explore this model interactively.
Top event: Loss of commanded actuator movement when movement is required.
Major OR branches
Electrical energy unavailable; motor torque not produced; mechanical transmission cannot move the output; or control system inhibits/miscommands movement. Any one branch can produce the top event.
Protected AND branches
Examples include erroneous sensor feedback combined with diagnostic failure, or loss of both command channels. These are precisely the branches where dependency/common-cause review is most important.
Example data are illustrative only. They demonstrate how the app handles probability basis, mission time, cut sets and independence warnings; they are not approved aerospace reliability values and must not be reused as design data.
What a Strong FTA Report Should Demonstrate
Traceable Model
Clear top event, scope, assumptions, event definitions, gate logic, supporting evidence and configuration.
Credible Analysis
Minimal cut sets, single-point paths, common-cause/dependency review, justified probability data and clearly stated limitations.
Decision & Action
Prioritised risk-reduction actions, verification evidence, residual-risk conclusion and review/approval appropriate to the programme.
Project Definition
Interactive Fault Tree
Click an event to edit it. Drag the background to pan and use the mouse wheel or zoom buttons to zoom. Select a cut set in Analysis to highlight its path.
Selected Event
NoneNo quantitative basis defined.
Event Register
| ID | Type | Event | Gate | Probability | Basis / source | Dependency |
|---|
Qualitative Analysis
0Minimal cut sets
0Single-event sets
—Largest order
Quantitative Analysis
Probability not calculated.
For a constant failure rate: P = 1 − e−λt. Quantitative gate calculations assume statistical independence of inputs unless dependencies are explicitly modelled or otherwise justified.
Common-Cause & Dependency Review
Shared support
Power, communications, cooling, grounds and connectors can defeat apparently separate paths.
Shared design or software
Common requirements, algorithms, components or systematic defects may create correlation.
Shared manufacture or environment
Batch, supplier, process, maintenance, contamination, temperature and vibration can affect multiple items.
Risk-Reduction Action
Action Summary
FTA Quality Check
0%
Engineering Conclusion
Fault Tree Analysis Report
Generate the report to preview it.