Choose your reading route
eduKateSG · Why Mathematics? · Fault Tree Analysis: Boolean Logic, Minimal Cut Sets and System Risk
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 9–16
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 17–24
Check assumptions
See where design and calibration matter.Route 4 · Chapters 25–32
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 33–43
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important when many small failures can combine into one serious system event? Fault tree analysis begins with an undesired top event and uses Boolean logic, probability and minimal cut sets to show the combinations that can produce it. The method helps teams find single points of failure, hidden dependencies and useful places to reduce risk.
Did You Know? A redundant pair can look extremely reliable when failures are multiplied as independent, yet one shared power supply can become a single-event minimal cut set and dominate the whole system risk. The strongest analysis therefore checks shared resources before celebrating redundancy.
Full chapter index
Chapters 1–8 · Understand the question
Chapters 9–16 · Reproduce the example
Chapters 17–24 · Check assumptions
Chapters 25–32 · Explore applications
Chapters 33–43 · Study and verify
Fault tree analysis begins with a clearly defined top event, such as loss of cooling during a one-hour mission. It reasons downward to combinations of events that can produce that outcome. This top-down structure differs from listing every possible component fault. The definition must include system boundary, operating mode and time interval. “System failure” is too vague to support consistent logic or probability. A good top event can be observed, tested and linked to consequences.
Basic events are the lowest events quantified or investigated in the model. Intermediate events combine lower branches. Gates express Boolean logic, not physical hardware. An OR gate means the output event occurs if at least one input occurs. An AND gate means all specified inputs occur. Symbols organise reasoning, but the analyst must explain mechanisms, dependencies and conditions in words. A beautiful diagram can still be incomplete or logically wrong.
For two events A and B, P(A OR B)=P(A)+P(B)−P(A AND B). If independent, the intersection is P(A)P(B). Simply adding probabilities double-counts cases in which both occur. When probabilities are very small, addition may approximate the exact value, but the approximation and its error should be stated. OR does not mean “either but not both”; it is inclusive unless the model explicitly uses exclusive logic.
For independent events, P(A AND B)=P(A)P(B). Independence is an assumption about joint behaviour, not a feature created by drawing separate branches. Shared power, environment, maintenance, design or software can make failures dependent. Multiplying marginal probabilities for dependent redundant channels can greatly understate risk. Model common causes explicitly or use a justified dependency model. The most important mathematics may be recognising when multiplication is not allowed.
Let top event T=A OR (B AND C). Event A alone is sufficient, while B and C must occur together. The Boolean expression preserves this structure. If P(A)=0.01, P(B)=0.02 and P(C)=0.03, and all are independent, P(B AND C)=0.0006. Exact P(T)=0.01+0.0006−0.000006=0.010594. The overlap term is small but visible, making the calculation auditable.
A cut set is a collection of basic events whose joint occurrence causes the top event. It is minimal when no proper subset is sufficient. For T=A OR (B AND C), the minimal cut sets are {A} and {B,C}. Minimal cut sets reveal single points of failure and combinations that defeat redundancy. They are unique for a coherent finite fault tree, though the route used to derive them can differ.
Boolean identities simplify trees and prevent double counting. Absorption gives A OR (A AND B)=A because whenever A AND B occurs, A already occurs. Idempotence gives A OR A=A. Distributive rules can transform gate structures and expose cut sets. Simplification must retain event meaning and conditions. If two labels look identical but refer to different missions or times, merging them may be wrong; naming discipline comes before algebra.
| Event | Probability |
|---|---|
| A | 0.01 |
| B | 0.02 |
| C | 0.03 |
| B AND C | 0.0006 |
| T exact | 0.010594 |
Sometimes it is easier to calculate success and take a complement. If a top failure event is the OR of independent component failures in a series system, system success requires all components to succeed. De Morgan’s laws connect these views: NOT(A OR B)=NOT A AND NOT B. Complement transformations help verify fault trees against reliability block diagrams. Use the same mission, repair and dependency assumptions before calling results equivalent.
Most introductory trees are coherent: making a component worse cannot improve the top event. Systems with switching, control commands or mutually exclusive states can create noncoherent logic involving NOT conditions. Negated events require care because basic-event probabilities and dependencies may change with state. Do not force dynamic behaviour into a static coherent tree for convenience. A Markov or dynamic fault-tree model may be more appropriate.
Two redundant pumps may share power, cooling, software, location or maintenance. A shared event becomes a one-event minimal cut set that can dominate the tiny product of independent pump failures. Common-cause modelling can use explicit shared events or specialised parameter models when justified. Search design documents and operational history for common resources. Redundancy is only as strong as the independence it actually creates.
Some fault trees use inhibit gates or conditioning events to show that an input causes the top event only under a stated condition. For example, a valve fault may matter only during a demand. The probability must match that logic: event frequency, demand probability and mission duration cannot be mixed casually. State whether inputs are per demand, per hour or mission probabilities. Units and exposure belong in a fault tree quantification.
Procedural errors, maintenance states and communication failures can contribute to risk, but probabilities are context-dependent and ethically sensitive. Avoid labels that blame individuals while ignoring interface, workload, training and organisational design. Define the task and opportunity, use evidence and model recovery where relevant. Qualitative branches can still guide safeguards when numerical estimates are weak. Uncertain numbers should not be invented to complete a table.
NASA describes software fault tree analysis as reasoning backward from a hazard to possible software causes, including omission, wrong logic and timing or sequence. Software failures are often systematic rather than independent random component failures. Probability assignment may be difficult. The tree remains useful for requirements, coverage and verification, but quantification must match evidence. Shared requirements or common code can defeat supposed redundancy.
| Gate | Top event occurs when |
|---|---|
| OR | at least one input event occurs |
| AND | all input events occur |
| k-out-of-n | at least k specified inputs occur |
The top event is the union of cut-set intersections. Exact calculation accounts for overlaps among cut sets, using inclusion-exclusion, binary decision diagrams or other algorithms. Adding cut-set probabilities is a rare-event approximation that can overcount overlaps. For large trees, numerical tools help, but model validation and event data remain essential. Record the algorithm, truncation and probability assumptions.
Importance measures rank how events influence top-event probability under the model. Birnbaum importance examines sensitivity to an event probability; Fussell–Vesely and risk-achievement measures answer related questions. Rankings can change with mission and parameter estimates. They guide investigation and design, not moral blame or certainty about the next incident. Pair quantitative importance with feasibility, consequence and uncertainty when choosing controls.
Basic-event probabilities may come from sparse tests, field data, expert judgement or handbooks. Propagate uncertainty through the tree using intervals, distributions or scenario analysis. Sensitivity shows which assumptions matter most. Correlation and model incompleteness may dominate numerical parameter uncertainty. A narrow calculated interval is not meaningful if a common cause is missing. Present both parameter and structural uncertainty.
A static mission fault tree often uses event probabilities over a fixed interval and may ignore repair. For long missions or continuously repairable systems, probabilities change with time and state. Convert rates to mission probabilities only under stated models. If repair, standby activation or sequence matters, dynamic fault trees or Markov models may be needed. Do not mix steady-state unavailability with one-hour failure probability in the same gate.
Trace each basic-event estimate to a source, population, exposure and definition. Check whether field counts include preventive replacements, censored units or different operating environments. Component catalogue values may not fit installation stress. Human-event data may come from unlike tasks. Version every source and record uncertainty. Probability arithmetic cannot correct a mismatch between event label and data.
A fault tree can be valuable before reliable probabilities exist. Minimal cut sets expose single points of failure, missing detection and common resources. Teams can add barriers, monitoring or diversity, then reassess. Quantifying weak events prematurely can distract from an obvious one-event cut set. Complete the logic review, walk through operating modes and compare incidents before polishing decimals.
Define top event as insufficient coolant flow during a specified mission. Branches may include common power loss OR failure of both parallel pumps OR a blocked common outlet. The blocked outlet and power loss are single-event cut sets; the pump pair is a two-event set if independent. This structure shows why adding a third pump does little against shared outlet blockage. Design action follows logic, not just component reliability.
Students can model the top event “classroom demonstration unavailable at lesson start” with equipment, file, power and setup branches. The purpose is improving a process, not assigning fault to a person. They can identify an OR branch for several independent resources and an AND branch when two backups must both fail. Probabilities can remain illustrative. The lesson is Boolean reasoning, boundary definition and respectful system improvement.
A service outage tree may include loss of all regions, shared identity-provider failure, bad deployment and network routing faults. Nominally separate servers may share software and control planes. Include detection and failover only if their success logic is modelled. Cloud architecture changes quickly, so version the tree and link events to current diagrams. Incident reviews can test whether known cut sets were complete.
Reducing a dominant single-event cut set can have more impact than improving many already reliable components. Options include eliminating the cause, adding diversity, separating resources, improving detection, limiting exposure or adding recovery. Recalculate only after the design change is precisely represented. A probability reduction should correspond to a real mechanism and verified implementation. Administrative controls may be less dependable than engineered barriers.
Turn each minimal cut set into a scenario and ask whether it truly causes the top event under the defined mode. Conversely, review known incidents and challenge whether the tree can generate them. Test gate truth tables and compare success logic with an RBD where appropriate. Independent analysts should review interfaces and common resources. Software checks syntax; multidisciplinary review checks reality.
NASA defines fault tree analysis as a symbolic logic representation linking an undesired top event with contributing causes and describes minimal cut sets as the smallest sufficient combinations. Read NASA’s fault-tree appendix, system-safety resources and the Fault Tree Handbook with Aerospace Applications.
For T=A OR (B AND C), verify cut sets {A} and {B,C}. Calculate P(B AND C)=0.0006. Under mutual independence, overlap with A is 0.000006, so P(T)=0.010594. Compare with the rare-event sum 0.0106 and note the difference. Then add common event D with probability 0.02 and observe how it dominates. This small example makes logic, dependence and approximation visible.
Fault trees can omit unknown mechanisms, misstate dependencies, mix time bases or create false confidence from uncertain probabilities. Static trees may not capture order, repair and dynamic reconfiguration. Minimal cut sets depend on the tree’s completeness. A low top-event number does not prove safety or satisfy every requirement. Combine FTA with hazard analysis, testing, design review, operations evidence and monitoring.
Lead with the top event, boundary, mode and mission time. Show the tree and a plain-language logic statement. List basic events with definitions, units, sources and uncertainties. Report minimal cut sets, common causes, quantification method, overlap treatment, importance measures, sensitivity and proposed controls. Distinguish qualitative findings from quantified estimates. Readers should be able to reproduce the small calculations and challenge missing branches.
Start with truth tables for AND, OR and NOT. Build T=A OR (B AND C), derive cut sets and calculate exact probability. Apply absorption to a redundant branch. Add a shared event to a parallel system and compare. Then inspect a real but low-stakes process, define its top event and hold a logic review. Finish by converting a simple success diagram into failure logic. This develops algebra, probability and systems thinking together.
Fault tree analysis makes complex risk discussable. Boolean mathematics turns a large system into testable combinations, while minimal cut sets reveal where thoughtful design can break a path to harm. The method is strongest when teams stay curious about missing dependencies and treat uncertainty honestly. Students learn that good mathematics does not merely calculate risk; it helps people redesign systems so that fewer paths lead to failure.
Run a structured review before accepting the top-event number. One reviewer reads the system description without seeing the tree and proposes plausible ways the event can occur. A second reviewer derives minimal cut sets from the Boolean expression. The original team then compares both lists, checks operating modes and traces shared power, software, environment, maintenance and human interfaces. For every cut set, tell the physical story from initiating event to top event and ask which barrier should stop it. Quantify only after event definitions, time bases and dependencies agree. Recalculate one small branch exactly and with the rare-event approximation so the approximation error is visible. Then remove or weaken one barrier in a scenario test and confirm the tree predicts the changed vulnerability. This review does not prove completeness, but it makes omissions, assumptions and evidence gaps explicit enough to guide testing and design changes.
Create an event table with ID, definition, type, probability, unit, source, uncertainty and dependency notes. Keep gate logic in a separate structured table so formulas can calculate truth values. For small independent trees, use exact inclusion-exclusion and compare with the cut-set sum. Build a minimal-cut-set sheet that removes supersets automatically. Add scenario and sensitivity columns. Never type a probability without its mission interval, and keep common causes as explicit events rather than hidden comments.
Represent the tree as a directed acyclic graph and parse gates into Boolean expressions. Unit-test every gate with truth tables. Generate minimal cut sets symbolically, remove absorbed supersets and verify them by enumerating basic-event states for small trees. Calculate exact top-event probability by enumeration or a binary decision diagram, then compare rare-event approximations. Store event metadata, units and sources with the model. Version the tree and produce dependency warnings rather than assuming independence silently.
Fault trees support system safety, aerospace, transport, energy, process industries, medical devices, cybersecurity, software assurance and reliability engineering. Careers require probability, Boolean algebra, engineering knowledge, human factors, regulation and communication. A fault-tree result does not certify a system or guarantee employment. Students can practise with low-stakes systems, then explore safety, engineering, operations and data roles while learning how multidisciplinary review challenges assumptions.
Choose a harmless top event such as “school presentation cannot start within two minutes.” Define the boundary, build a tree and identify minimal cut sets involving power, file access, projector and backup procedure. Do not assign personal probabilities. Instead, test truth tables and propose barriers that remove one-event cut sets. Run several planned scenarios, update the logic and explain which design change improves resilience. This teaches systems thinking without blaming people.
OR does not mean exactly one input. AND probabilities cannot be multiplied without dependence assumptions. A cut set is not automatically minimal. Minimal cut sets are not causes proven by an incident. A fault tree is top-down and cannot guarantee completeness. Adding redundant components does not remove common causes. Steady-state unavailability is not a mission probability. Importance rankings are model-dependent and should not be treated as blame rankings.
The reliability block diagram article models success paths and provides a cross-check for coherent systems. The Weibull reliability article supplies component-time models. The statistical process control article monitors operating evidence. Fault trees integrate these inputs around an undesired system event.
Students should master Boolean truth tables before quantitative trees. Parents can ask what the top event means, which events share a resource and whether probabilities use the same time interval. Encourage learners to find an omitted dependency; that is valuable analysis, not failure. Use respectful system labels rather than naming people as faults. In safety examples, rely on public or simulated data and keep numerical conclusions illustrative unless authoritative evidence exists.
1. Derive minimal cut sets for T=A OR (B AND C). 2. Reproduce 0.010594. 3. Apply absorption to A OR (A AND B). 4. Add one common-cause event to two redundant channels. 5. Explain the exact OR formula. 6. Convert a series success model into failure logic. 7. Distinguish a top event from a consequence. 8. Write a qualitative recommendation that removes a one-event cut set.
### What is a minimal cut set? A smallest combination of basic events sufficient for the top event.
### Can separate branches be assumed independent? No. Shared causes and conditions must be investigated.
### Must every fault tree be quantified? No. Qualitative logic can expose important vulnerabilities.
### Does a low calculated probability prove safety? No. Completeness, evidence, uncertainty and other safety analyses still matter.
Report top event; boundary, mode and mission; consequence context; event dictionary; gates and conditioning events; data sources and units; dependencies and common causes; Boolean expression; minimal cut sets; quantification method; overlap treatment; repair and time assumptions; uncertainty; sensitivity and importance; validation scenarios; incident comparison; proposed controls; residual risk; software and version; review roles; and limitations.
Rebuild the Boolean expression from the diagram and verify every gate with truth tables. Generate cut sets independently and remove supersets. Trace each basic event to evidence and a common mission interval. Search for shared power, environment, software, maintenance and human interfaces. Compare exact and approximate probabilities. Walk every minimal cut set as a physical scenario. Challenge the tree with known incidents and a reviewer unfamiliar with the original design. Record omitted or unquantified branches rather than hiding them.
Continue through the Mathematics Learning Hub. NASA’s mechanical fault-tree resource and software fault-tree guidance show domain applications. Next reproduce the small tree in code, compare it with an equivalent reliability block diagram and then add a justified dependency rather than another independent branch.
Extended practice laboratory
Practice case 1: Define the top event
Setup: Choose loss of cooling as the undesired event.
Task: Write one precise system boundary and mission interval.
Checking target: Avoid vague labels such as system problem.
Practice case 2: Build an OR gate
Setup: Let pump failure or valve failure cause loss of flow.
Task: Write T=P OR V and calculate probability for independent rare events.
Checking target: Use exact inclusion-exclusion before any rare-event approximation.
Practice case 3: Build an AND gate
Setup: Require both redundant pumps to fail.
Task: Write T=P1 AND P2 and calculate the independent product.
Checking target: State that shared power or environment breaks independence.
Practice case 4: Find minimal cut sets
Setup: Use T=A OR (B AND C).
Task: List {A} and {B,C}.
Checking target: Remove supersets; each retained set must be sufficient and minimal.
Practice case 5: Apply Boolean absorption
Setup: Simplify A OR (A AND B).
Task: Show that it equals A.
Checking target: Do not double-count the absorbed branch in probability calculations.
Practice case 6: Calculate a small tree
Setup: Use P(A)=0.01, P(B)=0.02, P(C)=0.03 and independence.
Task: Calculate P[A OR (B AND C)] exactly.
Checking target: Obtain 0.010594, not 0.0106 by unjustified addition.
Practice case 7: Inspect common cause
Setup: Add shared power failure to two nominally redundant channels.
Task: Rebuild the tree and cut sets.
Checking target: Show how one common event can dominate the parallel benefit.
Practice case 8: Rank contributions
Setup: Use minimal cut set probabilities as a screening view.
Task: Compare candidates for design improvement.
Checking target: Avoid treating importance measures as causal certainty.
Practice case 9: Validate the logic
Setup: Walk each gate with engineers and operators.
Task: Test true/false cases and compare incident history.
Checking target: A correct calculation cannot rescue an incomplete tree.
Practice case 10: Report the analysis
Setup: State scope, top event, gates, events and dependencies.
Task: List minimal cut sets and assumptions.
Checking target: Separate qualitative completeness from quantified risk.