Choose your reading route
eduKateSG · Why Mathematics? · Dynamic Fault Trees: Priority Gates, Spare Dependencies, Functional Triggers and Sequence-Aware 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 11–20
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 21–30
Check assumptions
See where design and calibration matter.Route 4 · Chapters 31–40
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 41–48
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important in dynamic fault trees? A static fault tree records combinations of faults, but many engineered systems also care about order, standby state, switching and functional triggers. Dynamic fault trees add gates whose meaning changes with sequence and state, then connect the logic to Markov chains, simulation or other quantitative solvers.
This guide develops priority-AND, sequence-enforcing, spare and functional-dependency mechanisms with checked examples. The numbers are educational illustrations. Real risk assessments need configuration evidence, domain review, verified tools and the standards that apply to the actual system.
Full chapter index
Chapters 1–10 · Understand the question
Chapters 11–20 · Reproduce the example
Chapters 21–30 · Check assumptions
Chapters 31–40 · Explore applications
Chapters 41–48 · Study and verify
CHAPTER 1 OF 48 · Understand the question
1. Why static logic is sometimes insufficient
An ordinary AND gate says that all listed events occur, without caring which happens first. Yet a valve that fails before a command can create a different outcome from the same two events in reverse order. Cold spares, startup sequences and dependencies are also stateful. Dynamic fault-tree mathematics preserves this information instead of forcing every mechanism into a commutative Boolean expression.
Define one unwanted outcome in observable terms, such as loss of a function during a stated mission. Give the boundary, operating mode and time horizon. A vague top event makes every later probability ambiguous. Dynamic modelling is justified only when sequence or state can materially change whether, when or how the top event occurs.
A priority-AND, often written PAND, occurs when all input events happen in a specified order. For two continuous lifetimes A and B, a left-to-right PAND may mean A fails before B and both have failed by time t. The ordering convention must be stated because tools can differ on simultaneous events and inclusive versus exclusive semantics.
Let A and B be independent exponential lifetimes with rates 0.01 and 0.02 per hour. The probability that A fails first is 0.01/(0.01+0.02)=1/3. The probability that both have failed by a finite mission time needs integration; the first-order fraction alone is not the probability of a completed PAND by t.
| Quantity | Value |
|---|---|
| Rate A | 0.01/hour |
| Rate B | 0.02/hour |
| A fails first | 1/3 |
| B fails first | 2/3 |
For independent exponential A then B, integrate λA exp[-(λA+λB)u] times the probability B fails between u and t. This gives an order-specific mission probability. At very long time, both eventually fail and the result tends to λA/(λA+λB). The limiting check is useful, but it must not replace the finite-time calculation.
A sequence-enforcing gate, or SEQ, restricts which failure order is allowed in the model. It is not simply another probability multiplier. The restriction can represent physical interlocks or modelling logic. Document what happens if an event tries to occur out of sequence: is it impossible, dormant, ignored or evidence that the model boundary is wrong?
A functional-dependency gate, or FDEP, has a trigger and dependent events. When the trigger occurs, the dependents are forced into a failed or unavailable state under the chosen semantics. This represents functional loss, not necessarily physical damage. Recovery, partial dependence and delay require more states than an instantaneous deterministic trigger.
A spare gate represents a primary unit and one or more spares. A spare can be cold, warm or hot, with different dormant failure behaviour. The gate also needs switching coverage and an activation rule. Merely adding a backup box does not determine reliability; standby survival and successful takeover are part of the mathematical mechanism.
A cold spare is often idealised as unable to fail while dormant; a warm spare has reduced dormant hazard; a hot spare operates and may have a hazard similar to the primary. These are modelling categories, not labels to assign by appearance. Power, environment, diagnostics and wear during standby determine the appropriate evidence.
A simple warm-spare model uses dormant hazard αλ when active hazard is λ. The factor α between zero and one is sometimes called a dormancy factor. It is conditional on configuration and environment. Estimate it from applicable standby data or physics. A convenient α chosen to make the answer look reasonable is not evidence.
Let c be the probability that detection, command and switching succeed when the primary fails. In an idealised one-primary one-spare system, the spare contributes only on the branch where it survives standby and the switch succeeds. Keep c separate from component reliability so design teams can see whether tests, sensors or hardware drive risk.
Suppose the primary survives a 10-hour mission with probability 0.90. If it fails, a spare is available with probability 0.95 and switching succeeds with probability 0.98. A simplified one-demand calculation gives 0.90+0.10×0.95×0.98=0.9931. This ignores failure timing and post-activation survival, so it is a teaching check, not a full dynamic result.
| Term | Value |
|---|---|
| Primary survives | 0.90 |
| Primary fails | 0.10 |
| Spare available | 0.95 |
| Switch succeeds | 0.98 |
| Illustrative result | 0.9931 |
CHAPTER 13 OF 48 · Reproduce the example
13. Why the simple spare formula is limited
The calculation treats the spare as if one availability number covers the whole mission. A time-dependent model must integrate over primary failure time, standby exposure, switch success and remaining active time. It may also include common causes. The simple result should be used to verify branch logic before building the detailed solver.
One quantitative route converts a dynamic fault tree into states such as primary active, spare dormant; primary failed, spare active; switch failed; and system failed. Transition rates or probabilities connect them. State labels should contain enough information to determine future behaviour. Merging states with different spare histories can silently change the answer.
If transitions have exponential waiting times and future rates depend only on the present state, a continuous-time Markov chain can solve transient and steady-state questions. This is powerful but restrictive. Ageing, deterministic delays and history-dependent switching break the memoryless assumption unless the state is expanded or another method is used.
Static subtrees can often be handled efficiently with binary decision diagrams while dynamic portions use states. Hybrid solvers exploit this separation. The decomposition must preserve dependencies crossing the boundary. A compact computation is valuable only when its semantics match the original gates.
Simulation can sample lifetimes, triggers, switches and sequences directly. It handles complex timing but needs reproducible random seeds, convergence checks and rare-event care. Compare it with analytic special cases. A million simulated missions do not repair an incorrect gate definition or an unsupported parameter.
Continuous independent lifetimes have zero probability of exact ties, but digital clocks, common shocks and batched logs can create simultaneous timestamps. State the tie rule for PAND and SEQ gates. Better time resolution may resolve some ties; shared-cause modelling may be more appropriate for others.
A basic dynamic fault tree often focuses on nonrepairable mission reliability. If repair, reset or inspection restores components, define whether gates remember prior order and how spares are replenished. Markov regenerative, Petri-net or simulation methods may be more suitable. Do not insert a repair rate without specifying operational policy.
A common event can defeat primary and spare together. Represent the shared mechanism explicitly rather than hiding it in a lower coverage value. Common causes can also affect detection, power and control logic. Redundancy claims are credible only when the dependency boundary is clear.
The earlier fault-tree analysis guide explains Boolean gates and minimal cut sets. Dynamic gates extend that logic when timing changes the outcome. Keep static portions static when they are adequate; extra states create more parameters and review work.
Reliability block diagrams show success paths. A spare path may look parallel while its availability depends on order and switching. Use the block diagram for architecture and the dynamic model for behaviour over time.
The Markov reliability guide develops state transitions and availability. A dynamic tree can provide the logic that generates those states. Check whether exponential waiting times are defensible before adopting a Markov solution.
Include the commands, power, sensors and human actions required for a dynamic function. Excluding the switching controller while modelling only the spare unit can make coverage look perfect by definition. Boundaries should follow the success claim and remain consistent across diagrams, data and calculations.
Maintain a table for each rate, probability and delay with units, population, environment, configuration, sample size and uncertainty. Use primary test or field evidence where possible. Expert judgement can be represented, but it should be labelled and tested in sensitivity analysis.
Sample or bound failure rates, dormancy factors, coverage and common-cause parameters. Preserve correlations where they share evidence. Report a range or distribution for the top-event probability, plus the inputs that dominate it. Numerical precision should not exceed evidence precision.
Vary one mechanism or use global sensitivity to see whether switching, dormant failure or active failure drives the result. Dynamic importance can change with mission time. Sensitivity identifies where evidence or redesign may matter; it does not prove causality or select a safety action automatically.
Remove all dynamic gates and compare the solver with a static fault tree. Set coverage to one and dormancy to zero to recover an ideal-spare case. Check short-time and long-time limits, probability conservation and unreachable states. These controlled cases catch modelling and software errors.
Compare predicted event sequences, switching outcomes and mission failures with applicable tests or operations. Total failure probability alone can fit for the wrong reason. Validate intermediate states and timing. Configuration changes require reassessment because a new controller can change the dynamic semantics.
Draw a primary pump, a warm spare and a controller. Label the states before and after primary failure, then add a switch-failure branch. Calculate the simplified 0.9931 illustration and list what it omits. This connects conditional probability, state diagrams and engineering assumptions.
Ask the student why order changes the outcome. Which event is the trigger? What is dormant? What must work during takeover? Encourage a labelled diagram before arithmetic and a final sentence naming assumptions. This builds transferable reasoning without pretending the example certifies a real system.
CHAPTER 32 OF 48 · Explore applications
32. Common misconception: dynamic means time varying only
Dynamic fault trees are about sequence and state dependence as well as time. A constant failure rate can still participate in a dynamic gate. Conversely, a time-varying rate in a simple series system does not by itself require a dynamic fault-tree gate.
CHAPTER 33 OF 48 · Explore applications
33. Common misconception: a spare is ordinary parallel redundancy
A spare may be inactive until demanded, can fail while dormant and needs successful activation. Two continuously operating parallel units have different exposure and dependencies. The diagram can look similar while the probability model is different.
The same pair of component failures can produce success in one order and system loss in the other. Commutative Boolean gates cannot express that distinction. A priority gate changes the mathematics by preserving the story told by time.
Define PAND, SEQ, FDEP and SPARE. Compute the first-failure order probability for rates 0.01 and 0.02. Reproduce the simplified spare result. Explain why ties matter. Draw a state model. Name two common causes. Design a coverage test. State a cautious conclusion.
CHAPTER 36 OF 48 · Explore applications
36. FAQ: must every fault tree become dynamic?
No. Use dynamic gates only when order, standby or functional dependence changes the decision. Static models are easier to review and may be fully adequate. Complexity should follow the mechanism and available evidence, not the capability of the software.
A qualified tool can be appropriate, but independent checks remain valuable. Reproduce small cases analytically, compare another method when practical and inspect generated states. Tool verification does not validate the model or its input data.
Record the top event, mission, boundary, gate definitions, event order, tie rules, component states, rates, dormancy, coverage, common causes, solver method, truncation, uncertainty, verification cases, validation evidence and configuration version. Preserve diagrams and machine-readable inputs.
NASA describes a dynamic fault-tree propulsion model and compares static and dynamic probabilistic risk approaches. Use these with the applicable organisational standard and system evidence.
Mathematics matters because sequence, standby and triggers change how redundancy behaves. Dynamic gates make those mechanisms explicit and connect them to states, integrals or simulation. A responsible analysis defines semantics, verifies limiting cases, validates event paths and reports uncertainty before using a number in a decision.
Dynamic behaviour can change between launch, cruise, standby, testing and shutdown. A spare may be cold in one phase and hot in another; a trigger may be enabled only during a command window. Model phases explicitly or condition transitions on phase. Combining all exposure into one average rate can create impossible sequences and hide the period that drives risk.
Switching or detection may take a nearly fixed time rather than an exponential waiting time. Markov chains approximate such delays with several phases, while simulation or semi-Markov models can represent them directly. Check whether the approximation changes mission failure probability, especially when the allowed response window is short.
If an operator diagnoses and activates a spare, define cues, decision time, workload, training and recovery paths. A single coverage probability may be useful for screening but cannot explain why performance changes. Use human-reliability evidence appropriate to the task and avoid treating people as identical memoryless components.
Gate semantics depend on firmware, wiring, set points and operating procedures. Link every model version to an authoritative configuration. When logic changes, re-run sequence tests and review formerly unreachable states. Historical failure rates from another configuration may not transfer without an explicit argument.
Very small top-event probabilities can make ordinary simulation inefficient. Importance sampling or accelerated methods may help, but altered sampling requires correct likelihood weights. Test the method on a model with a known answer and report effective sample size. Rare-event technique precision cannot justify uncertain input tails.
A dynamic tree may support design comparison, test planning or risk monitoring. Each use needs a time horizon and acceptance process. A sensitivity result can justify collecting better switching data; it does not independently approve a design. Keep analytical output, engineering judgement and formal authority distinct.
Reliability engineers, safety analysts, systems engineers, control specialists and software assurance teams use sequence-aware reasoning. Students practise conditional probability, integration, graph states and verification. These skills support pathways, but mathematics alone does not guarantee admission or a particular career outcome.
A student should be able to explain why PAND is not an ordinary AND gate, calculate a first-failure order probability, draw the states of a spare system and list evidence needed for dormancy and coverage. The strongest answer also states one limitation and one verification check.
Extended practice laboratory
Practice case 1: Order probability
Setup: Use independent rates 0.01 and 0.02 per hour.
Task: Calculate the chance A fails first.
Checking target: Obtain one third; do not call it the finite-time PAND probability.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 2: PAND horizon
Setup: Choose a finite mission time.
Task: Write the order-specific integral.
Checking target: Check the long-time limit approaches one third.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 3: Spare branch
Setup: Use 0.90 primary survival, 0.95 spare availability and 0.98 coverage.
Task: Evaluate the simplified branch formula.
Checking target: Obtain 0.9931 and list omitted timing.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 4: Warm spare
Setup: Set active hazard λ and dormant factor α.
Task: Describe the state change after demand.
Checking target: Keep dormant and active exposure separate.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 5: FDEP trigger
Setup: Name one trigger and two dependents.
Task: Draw forced state changes.
Checking target: Distinguish functional loss from physical damage.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 6: Tie rule
Setup: Give two events the same logged timestamp.
Task: Choose and justify a PAND tie convention.
Checking target: Preserve common-shock possibility.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 7: State generation
Setup: List primary active, spare dormant, spare active and failed states.
Task: Add transitions and units.
Checking target: No two merged states may have different futures.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 8: Markov check
Setup: Set exponential rates.
Task: Write the generator row sums.
Checking target: Each row sums to zero and probabilities remain conserved.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 9: Simulation check
Setup: Sample failure and switching events.
Task: Compare an ideal case with an analytic result.
Checking target: Report seed, trials and interval.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 10: Uncertainty
Setup: Vary coverage, dormancy and shared cause together.
Task: Find the dominant input.
Checking target: Do not treat correlated evidence as independent.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 11: Validation
Setup: Design a takeover test with sequence timestamps.
Task: Compare predicted paths.
Checking target: Validate intermediate states, not only top-event count.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 12: Conclusion
Setup: State mission, gate semantics, solver and uncertainty.
Task: Separate analysis from approval.
Checking target: Name configuration and review boundary.
Method note: Write the event order, state before the event, state after it and the parameter units. Then name the gate semantics and one omitted dependency. A correct numerical result without those labels is incomplete because another tool or reviewer could interpret the sequence differently.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.