Electronics Guide

Defining the Top Event

The top event serves as the starting point for fault tree development:

• Clear definition: The top event must be precisely defined, specifying what constitutes failure, under what conditions, and during what time frame or mission phase
• Scope boundaries: Establish clear boundaries for the analysis including system interfaces, environmental conditions, and operational modes to be considered
• Failure criteria: Define specific thresholds or conditions that constitute failure, such as output voltage deviation beyond specified limits
• Mission context: Specify the operational scenario including duration, environment, and maintenance assumptions
• Single versus multiple events: Determine whether to analyze a single failure event or develop separate trees for multiple failure modes

A well-defined top event ensures the analysis remains focused and produces actionable results. Vague or overly broad top events lead to unfocused analyses that fail to identify specific failure scenarios.

Intermediate Events and Basic Events

Fault trees decompose the top event into progressively lower-level events:

• Intermediate events: Events that result from combinations of other events and are themselves further developed in the tree; represented by rectangles
• Basic events: Fundamental events that cannot or need not be further developed; represent the lowest level of resolution in the analysis, shown as circles
• Undeveloped events: Events that could be further developed but are not, typically due to insufficient information or because they fall outside the analysis scope; depicted as diamonds
• House events: Events that are either certain to occur or certain not to occur, used to model conditional scenarios; shown as house-shaped symbols
• Transfer symbols: Indicate connections to other parts of the tree or to separate fault trees; triangles pointing into or out of the tree

The level of decomposition depends on available failure data, analysis objectives, and system complexity. Basic events should correspond to failure modes for which reliability data exists or can be estimated.

Logic Gates

Logic gates define how lower-level events combine to cause higher-level events:

• AND gate: Output event occurs only if every input event has occurred and all coexist; represents redundant or parallel configurations in which multiple failures are required
• OR gate: Output event occurs if any one or more input events occur; represents series configurations or single points of failure
• Voting gate: Output occurs when at least k of n input events occur; models majority-voting architectures such as the 2-out-of-3 (2oo3) sensor arrangements common in process safety and flight control
• Exclusive OR gate: Output occurs if exactly one input occurs but not both; less common in reliability applications
• Priority AND gate: Output occurs only if inputs occur in a specified sequence; models sequence-dependent failures such as a standby unit that fails before, rather than after, the primary
• Inhibit gate: Output occurs only if the input event occurs and a conditional event is satisfied; represents conditional failures

Proper gate selection is crucial for accurate analysis. AND gates model redundancy benefits while OR gates identify vulnerability to single failures. Most fault trees are dominated by OR gates, reflecting the many ways systems can fail.

Construction Methodology

Systematic construction ensures complete and accurate fault trees:

• Top-down development: Start from the top event and ask "what could cause this event?" at each level, developing all immediate causes before moving to the next level
• Completeness checking: Ensure all possible causes are identified at each level using systematic techniques such as checklists, failure mode libraries, and expert review
• No gate-to-gate connections: Every gate output must connect to an event symbol; direct gate-to-gate connections violate fault tree conventions
• Consistent abstraction levels: Events connected to the same gate should represent similar levels of detail and system hierarchy
• State versus event: Distinguish between states (existing conditions) and events (occurrences that change states) to ensure logical consistency

Construction typically proceeds through multiple iterations, with initial trees refined as understanding deepens and reviewers identify missing failure scenarios.

Minimal Cut Sets

Cut sets are combinations of basic events that cause the top event:

• Cut set definition: A cut set is any combination of basic events that, if all occur, will cause the top event to occur
• Minimal cut set: A cut set from which no event can be removed while still causing the top event; contains only necessary events
• Cut set order: The number of basic events in a minimal cut set; first-order cut sets are single points of failure
• System vulnerability: Systems with many first-order cut sets are highly vulnerable; those with only higher-order cut sets have built-in redundancy
• Importance ranking: Cut sets can be ranked by order to prioritize design improvements

Identifying minimal cut sets is the primary objective of qualitative FTA. First-order cut sets represent single points of failure that warrant immediate design attention in critical applications.

Cut Set Determination Methods

Several approaches determine minimal cut sets from fault tree structure:

• Boolean reduction: Convert the fault tree to a Boolean expression and reduce it to sum-of-products form, applying the idempotent law (A · A = A) and the absorption law (A + A · B = A) to eliminate non-minimal terms
• MOCUS algorithm: Method for Obtaining Cut Sets; a systematic top-down algorithm that expands OR gates into additional rows and AND gates into additional columns of a working matrix, then removes supersets
• Binary decision diagrams: A canonical graph representation of a Boolean function that enables exact quantification without the inclusion-exclusion blowup, and is now the standard engine in modern FTA software
• Cut set truncation: Large trees are routinely truncated by discarding cut sets below a probability threshold or above a chosen order; the discarded contribution must be estimated and reported, since aggressive truncation can hide real risk
• Monte Carlo simulation: Random sampling approach useful for very large trees, dynamic models, and cases where exact enumeration is impractical
• Software tools: Commercial FTA software automates cut set determination and handles trees with thousands of events

For small trees, manual Boolean reduction is practical and builds understanding. Large industrial fault trees require software tools that implement efficient algorithms, because the number of minimal cut sets can grow combinatorially with tree size.

Minimal Path Sets

Path sets provide the complementary view of what must work for the system to succeed:

• Path set definition: A combination of basic events that, if none occur, guarantees the top event does not occur
• Minimal path set: A path set from which no event can be removed while still preventing the top event
• Success orientation: Path sets represent combinations of components that must function for system success
• Duality with cut sets: Path sets of the original tree equal cut sets of the complement tree (with all gates inverted)
• Reliability calculations: Path sets enable alternative approaches to calculating system reliability

Path set analysis is particularly useful when system success is more naturally understood than system failure, or when calculating reliability bounds.

Common Cause Failure Analysis

Common cause failures defeat redundancy by affecting multiple components simultaneously:

• Common cause identification: Review basic events under AND gates to identify potential common causes that could fail multiple components
• Susceptibility categories: Environmental factors, design defects, maintenance errors, external events, and operational errors
• Beta factor method: Quantify common cause susceptibility by estimating β, the fraction of a component's failure rate attributable to causes that fail redundant units together. Values from a few percent up to roughly ten percent are typical for redundant hardware, and IEC 61508-6 provides a checklist-based scoring method for estimating β from design and installation features. More elaborate multiple Greek letter and alpha factor models extend the idea to groups of three or more units
• Defense strategies: Diversity, physical separation, independence, and monitoring can mitigate common cause vulnerabilities
• Tree modification: Add common cause events to fault trees to properly model their impact on redundant configurations

Common cause failures often dominate system unreliability in highly redundant systems. Identifying and mitigating these vulnerabilities is essential for achieving target reliability in safety-critical applications.

Basic Event Probability Assignment

Quantitative analysis requires probability estimates for each basic event:

• Failure rate data: Use component failure rates from reliability databases, manufacturer data, or field experience. Widely used electronics sources include IEC 61709, Telcordia SR-332, FIDES, and the Quanterion NPRD and EPRD compendia; the venerable MIL-HDBK-217F has not been revised since 1995 and its models are now poorly matched to modern parts
• Mission time considerations: Convert failure rates to probabilities over the analysis time frame. For a non-repaired item with constant failure rate λ over mission time t, the failure probability is Q = 1 − e^−λt, which reduces to Q ≈ λt when λt is much less than one
• Demand probability: For standby components, consider both failure to start on demand (a dimensionless probability per demand) and failure to run for the required duration
• Repairable and tested items: Continuously monitored repairable items are modeled by their unavailability, approximately λ × MTTR; periodically tested items that fail undetected accrue unavailability over the test interval
• Human error probability: Estimate probabilities of human errors using human reliability analysis techniques
• Uncertainty characterization: Document uncertainty in basic event probabilities for propagation through the analysis; failure rate estimates commonly carry error factors of three to ten

Basic event probability accuracy directly limits top event probability accuracy. Because the underlying data are uncertain, FTA results are best used to compare design options and rank contributors rather than to predict an absolute failure probability to more than about one significant figure.

Probability Calculations

Gate probabilities are calculated from input event probabilities:

• OR gate: P(output) = 1 − (1 − P(A)) × (1 − P(B)) × … for independent inputs; approximates to the sum of input probabilities when all are small
• AND gate: P(output) = P(A) × P(B) × … for independent inputs; the product of input probabilities
• Quantify from cut sets, not from the drawn tree: Events repeated in several branches make gate-by-gate multiplication wrong, because the same event would be counted as though it were independent of itself. Reduce to minimal cut sets first, then quantify
• Rare event approximation: When basic event probabilities are small (roughly below 0.1), the top event probability approximately equals the sum of the minimal cut set probabilities. For coherent trees this sum is an upper bound, so the error is conservative
• Minimal cut set upper bound: The tighter bound 1 − ∏(1 − Q_i) over the cut set probabilities Q_i remains conservative and stays accurate even when the simple sum begins to exceed unity
• Exact calculation: The inclusion-exclusion principle accounts for overlap between cut sets that share events, but the number of terms grows exponentially, so exact results for large trees are normally obtained with binary decision diagrams instead
• Non-coherent trees: Trees containing NOT gates or complemented events violate the monotonicity assumptions behind these bounds and require dedicated methods

For most reliability applications the rare event approximation provides adequate accuracy with greatly simplified calculations, and it errs on the safe side. Certification evidence and probabilistic risk assessments generally use exact or bounded methods computed by software.

Importance Measures

Importance measures quantify how much each basic event contributes to system unreliability:

• Fussell-Vesely importance: The fraction of system unreliability attributable to cut sets containing the event, computed as the summed probability of those cut sets divided by the top event probability. Because a cut set is credited to every event it contains, Fussell-Vesely values across all basic events sum to more than one
• Risk Reduction Worth: The ratio of the baseline top event probability to the probability recomputed with the event's probability set to zero; identifies events whose improvement most benefits the system, and is bounded by how much of the risk that event touches at all
• Risk Achievement Worth: The ratio of the top event probability recomputed with the event's probability set to one, to the baseline; identifies events whose continued good performance is critical, which makes it the natural measure for setting maintenance and surveillance priorities
• Birnbaum importance: The partial derivative of the top event probability with respect to the basic event probability; a pure sensitivity measure that ignores how likely the event itself is, so a highly reliable component in a critical position can still rank high
• Cut set importance: The contribution of each minimal cut set to overall system unreliability, usually reported as a ranked list in which a handful of cut sets dominate the total

Importance measures guide resource allocation for reliability improvement, but they answer different questions and can rank the same events differently. Use Fussell-Vesely and Risk Reduction Worth to find where design changes pay off, and Risk Achievement Worth to find what must not be allowed to degrade in service.

Uncertainty and Sensitivity Analysis

Understanding result uncertainty is essential for informed decision-making:

• Parameter uncertainty: Uncertainty in basic event probabilities due to limited data or estimation methods. Failure rates are conventionally modeled as lognormal, characterized by a median and an error factor equal to the ratio of the ninety-fifth percentile to the median; error factors of three to ten are ordinary for electronic parts
• Model uncertainty: Uncertainty arising from simplifications, assumptions, and the choice of one modeling approach over another, such as which common cause model to apply
• Completeness uncertainty: The contribution of failure scenarios the analyst never wrote down. It cannot be quantified from within the tree, which is why peer review and comparison against field experience matter more than additional arithmetic
• Monte Carlo propagation: Sample from the basic event distributions, requantify the cut sets on each trial, and build the resulting distribution of the top event probability. Latin hypercube sampling reaches stable percentiles with fewer trials than simple random sampling
• Sensitivity analysis: Vary individual parameters, or switch a modeling assumption on and off with a house event, to identify which inputs actually govern the answer
• Confidence bounds: Report the fifth percentile, median, mean, and ninety-fifth percentile rather than a single number. For lognormal inputs the mean of the top event distribution lies above its median, sometimes by a wide margin, so quoting the median alone understates risk

Results presented with uncertainty information support better decisions than point estimates alone, particularly when a probability sits near a decision threshold. A top event probability of 8 × 10⁻³ against a target of 1 × 10⁻² looks like compliance until the ninety-fifth percentile is shown to be several times the target.

Basic Events and Their Probabilities

• A — power supply A fails: λ = 5 × 10⁻⁶ per hour, so Q_A = 1 − e^−0.0438 ≈ 4.3 × 10⁻²
• B — power supply B fails: identical unit, Q_B ≈ 4.3 × 10⁻²
• C — shared input breaker opens spuriously: λ = 3 × 10⁻⁷ per hour, Q_C ≈ 2.6 × 10⁻³
• D — output bus or OR-ing diode network fails open: λ = 2 × 10⁻⁷ per hour, Q_D ≈ 1.8 × 10⁻³
• E — common cause failure of both supplies: a beta factor of 0.05 applied to the supply failure rate gives Q_E ≈ 2.2 × 10⁻³

Minimal Cut Sets and Quantification

The tree yields four minimal cut sets: three of first order, {C}, {D}, and {E}, and one of second order, {A, B}. Under the rare event approximation the top event probability is the sum of their probabilities:

• {C} shared breaker: 2.6 × 10⁻³, about 31 percent of the total
• {E} common cause: 2.2 × 10⁻³, about 26 percent
• {A, B} both supplies independently: (4.3 × 10⁻²)² ≈ 1.8 × 10⁻³, about 22 percent
• {D} output bus: 1.8 × 10⁻³, about 21 percent

The total is roughly 8.4 × 10⁻³ for the one-year mission.

Interpreting the Result

The redundant pair, the only part of the design that was deliberately duplicated, accounts for barely a fifth of the risk. Nearly four-fifths comes from the shared breaker, the shared output bus, and the common cause term, none of which redundancy in the supplies addresses. Adding a third power supply in a one-out-of-three arrangement would replace the second-order cut set {A, B} with a third-order cut set worth roughly (4.3 × 10⁻²)³ ≈ 8 × 10⁻⁵, leaving the top event probability near 6.6 × 10⁻³. That is an improvement of only about twenty percent for a substantial increase in cost, weight, and parts count, and the added unit would probably raise the common cause term rather than lower it.

The cut set structure points instead to three specific changes: feed the two supplies from independent breakers to eliminate the {C} cut set, split or duplicate the output bus to eliminate {D}, and reduce the beta factor by using supplies of different design, separate thermal paths, and staggered maintenance. This is the characteristic value of fault tree analysis: it distinguishes redundancy that is real from redundancy that is defeated upstream or downstream, and it does so before hardware is built.

Electronic Component Failure Modes

Electronic components exhibit characteristic failure modes that must be captured in fault trees:

• Open circuit failures: Loss of electrical continuity through a component; common in resistors, inductors, and connections
• Short circuit failures: Unintended low-resistance path; common in capacitors, semiconductors under overstress
• Parametric drift: Component parameters change beyond acceptable limits while component continues functioning
• Intermittent failures: Failures that occur sporadically, often due to thermal cycling, vibration, or marginal connections
• Degradation failures: Progressive deterioration leading to eventual failure; important for wear-out analysis

Different failure modes of the same component may appear in different branches of the fault tree, reflecting their different effects on system function. A single electrolytic capacitor, for example, can contribute an open-circuit event to a loss-of-output branch and a short-circuit event to an overcurrent branch, and the two must be apportioned rather than double-counted. The split between modes is drawn from failure mode distribution data or, where none exists, from engineering judgment recorded as a documented assumption. Because the same physical part then appears as several basic events, and sometimes in several branches, careful naming discipline is essential to keep repeated events correctly identified during cut set reduction.

Circuit-Level Analysis

Fault trees for electronic circuits require understanding of circuit behavior:

• Functional decomposition: Divide circuits into functional blocks (power supply, signal processing, output stage) for systematic analysis
• Signal flow tracing: Follow signal paths to identify how component failures propagate to system failure
• Failure effect analysis: Determine how each component failure mode affects circuit function
• Sneak circuit analysis: Identify unintended circuit paths that may cause unexpected failures
• Interface failures: Include failures at circuit interfaces including connectors, cables, and module boundaries

Failure modes and effects analysis complements FTA for circuit analysis by systematically identifying the component failure modes that serve as basic events in the fault tree. The two are usually performed together: the FMEA works upward from parts to effects and populates the basic event list, while the fault tree works downward from the hazard and shows which of those effects actually combine to defeat the design. Where the two disagree, one of them is incomplete, and reconciling them is among the most productive reviews a reliability team can run.

Software and Firmware Considerations

Modern electronic systems include software that must be addressed in fault trees:

• Software failures: Software defects can cause system failure; include as basic events with estimated probabilities
• Hardware-software interaction: Model failures arising from software response to hardware anomalies
• Watchdog and monitoring: Include software monitoring functions that detect and respond to hardware failures
• Common cause: Software running on redundant hardware represents a common cause failure source
• Version diversity: Diverse software versions on redundant channels reduce common cause software failures

Software failures are difficult to quantify because software does not wear out: a defect is present from the first execution and manifests whenever its triggering conditions arise, so a constant failure rate has no physical basis. The major safety standards respond by governing software through process rigor rather than numerical targets, as DO-178C does with design assurance levels and IEC 61508-3 does with systematic capability. In fault trees, practical approaches include treating a software function as an undeveloped event, assigning a bounding probability for sensitivity purposes, or using a house event to switch the software contribution on and off and observe its influence on the result.

Power Supply and Distribution

Power system failures commonly appear as high-importance events in electronic system fault trees:

• Single power supply: Creates first-order cut set unless redundant power is provided
• Power distribution: Failures in power buses, fuses, and regulators affect multiple downstream functions
• Power quality: Include failures due to voltage excursions, noise, and transients
• Backup power: Model battery backup systems including charging, monitoring, and switchover functions
• Common power: Redundant circuits sharing common power represent common cause vulnerability

Power system analysis often reveals that apparently redundant designs share common power sources that create unexpected single points of failure.

Hazard Analysis Integration

FTA connects to system-level hazard analysis:

• Top event derivation: Top events derive from hazard analysis identifying unacceptable system states
• Safety requirement verification: FTA verifies that design meets probability targets derived from hazard analysis
• Hazard mitigation: Cut set analysis identifies where design changes most effectively reduce hazard probability
• Residual risk: FTA quantifies residual risk after mitigation measures are implemented
• Documentation: FTA provides traceable evidence for safety cases and certification submissions

Integration ensures FTA addresses the right questions, since the top events derive from hazard analysis, and that the results feed back into system safety assessment. The hazard analysis also supplies the numerical target the tree must meet. In civil aviation, for example, the failure condition classifications used with 14 CFR 25.1309 and CS-25.1309 pair each severity class with an average probability per flight hour: on the order of 10⁻⁹ for catastrophic conditions, 10⁻⁷ for hazardous, 10⁻⁵ for major, and 10⁻³ for minor. The fault tree is then the instrument that shows whether the architecture meets the budget assigned to its top event.

Safety Integrity Levels

FTA supports safety integrity level (SIL) verification in functional safety standards:

• Probability targets: SIL levels specify quantitative failure targets that FTA can verify, expressed as average probability of dangerous failure on demand (PFDavg) for low-demand functions or frequency of dangerous failure per hour (PFH) for high-demand and continuous functions. IEC 61508-1 defines each level as a decade band: PFDavg from 10⁻² down to 10⁻⁵ across SIL 1 through SIL 4, and PFH from 10⁻⁵ down to 10⁻⁹ per hour over the same range
• Architecture requirements: Standards require specific fault tolerance that cut set analysis can confirm
• Diagnostic coverage: FTA models impact of diagnostics on detected versus undetected dangerous failures
• Common cause defense: Standards require common cause analysis that FTA supports
• Proof testing: FTA models the effect of periodic testing on failure probability. For a dangerous undetected failure rate λ_DU and proof test interval T, the average unavailability contributed by that basic event is approximately λ_DU × T/2, which makes the test interval an explicit design variable

Standards such as IEC 61508 and ISO 26262 reference FTA as an appropriate technique for verifying safety function reliability. FTA alone does not establish a safety integrity level: the standards also impose architectural constraints on hardware fault tolerance and require evidence of systematic capability, which quantitative analysis cannot supply.

Event Tree Analysis Combination

Fault trees and event trees combine for complete accident sequence analysis:

• Complementary perspectives: FTA analyzes how systems fail (deductive); event tree analysis (ETA) models what happens after initiating events (inductive)
• Linked analysis: Fault trees model failure of safety functions that appear as branch points in event trees
• Accident sequences: Event tree sequences combined with FTA-derived branch probabilities yield accident sequence frequencies
• Risk integration: Combined FTA/ETA analysis enables complete probabilistic risk assessment
• Defense in depth: Combined analysis evaluates effectiveness of multiple protective barriers

The combination of FTA and ETA provides comprehensive risk analysis capability addressing both system failures and their consequences.

Regulatory Applications

FTA supports regulatory compliance across industries:

• Aerospace: The civil aviation safety assessment process defined in SAE ARP4761, revised as ARP4761A and published jointly with EUROCAE ED-135 in December 2023, employs FTA to demonstrate that catastrophic and hazardous failure conditions meet their probability budgets. It is used alongside the development guidance of ARP4754B (jointly EUROCAE ED-79B), issued in the same month, and accompanies hardware and software design assurance performed under DO-254 and DO-178C
• Nuclear: The NRC relies on FTA as a core element of probabilistic risk assessment for nuclear facilities, building on the methodology documented in the Fault Tree Handbook (NUREG-0492)
• Automotive: ISO 26262 cites FTA as a deductive method for safety analysis of automotive electrical and electronic systems, supporting Automotive Safety Integrity Level (ASIL) targets
• Medical devices: Under the ISO 14971 risk-management framework recognized by the FDA, FTA serves as an accepted technique for analyzing hazards in medical device submissions
• Rail: The CENELEC standard EN 50129 governs safety-related electronic systems for railway signalling; its 2018 edition, since superseded by EN 50129:2026, lists fault tree analysis among the techniques for the safety case, supporting the allocation of tolerable hazard rates on a basis consistent with IEC 61508

Understanding regulatory requirements ensures FTA analyses meet documentation, methodology, and review requirements for specific industries.

Software Tools

FTA software tools range from simple drawing aids to comprehensive analysis packages:

• Drawing capabilities: Create and edit fault tree diagrams with proper symbology and automatic layout
• Cut set calculation: Automated determination of minimal cut sets using efficient algorithms
• Quantification: Probability calculations with support for various probability models and time dependencies
• Importance analysis: Automated calculation of multiple importance measures
• Uncertainty analysis: Monte Carlo simulation for uncertainty propagation
• Report generation: Automated documentation meeting industry standards

Widely used commercial packages include Isograph FaultTree+ within Reliability Workbench, Relyence Fault Tree, ITEM ToolKit, and RAM Commander; the nuclear sector additionally uses dedicated probabilistic risk assessment codes. Open-source options exist for smaller applications. Tool selection depends on analysis complexity, regulatory acceptance, and how well the tool exchanges data with the FMEA, reliability prediction, and requirements systems already in use. Note that a tool that draws trees is not the same as a tool that quantifies them correctly, and any package used for certification evidence should have a documented verification history.

Analysis Process

A structured process ensures consistent, high-quality fault tree analyses:

• Planning: Define scope, objectives, assumptions, and resource requirements before beginning analysis
• Information gathering: Collect system design information, failure data, and operational context
• Tree construction: Develop fault tree systematically with ongoing review for completeness
• Qualitative analysis: Determine cut sets and identify critical vulnerabilities
• Quantitative analysis: Assign probabilities and calculate results with uncertainty
• Documentation: Record methodology, assumptions, data sources, and results
• Review: Independent review for technical accuracy and completeness

Documented processes ensure repeatability and support regulatory review. Process rigor should match the criticality of the application.

Common Pitfalls

Awareness of common mistakes improves analysis quality:

• Incomplete development: Stopping tree development before reaching basic events with available failure data
• Missing failure modes: Overlooking failure modes, particularly those not directly related to component function
• Logic errors: Incorrect gate selection (AND versus OR) that misrepresents system behavior
• Common cause neglect: Failing to identify and model common cause failures in redundant configurations
• Data quality: Using inappropriate or outdated failure data without adjustment for actual conditions
• Assumption documentation: Failing to document assumptions that affect result interpretation

Independent review by experienced analysts helps identify and correct these issues before results are used for decisions.

Limitations of the Method

Fault tree analysis is powerful within its assumptions, and knowing where those assumptions stop is part of using it well:

• Completeness cannot be demonstrated: A fault tree contains the failure scenarios the analyst thought of. Nothing in the method reveals what was omitted, and the calculated probability is silent about the branches that were never drawn
• Component failure is the unit of analysis: Accidents in which every component behaves exactly as specified, but the specified behavior is wrong for the situation, produce no basic event to place in the tree. Systems-theoretic methods such as Systems-Theoretic Process Analysis (STPA) were developed for that class of problem and complement rather than replace FTA
• Static logic: A conventional tree captures combinations, not order, duration, or feedback. Timing-dependent and control-loop behavior requires dynamic extensions, Markov models, or simulation
• Independence assumptions: The standard gate arithmetic assumes independent basic events. Dependence must be modeled explicitly through common cause terms, and a dependence that goes unrecognized silently inflates the apparent benefit of redundancy
• Precision exceeding accuracy: Software reports top event probabilities to many digits from input data that are uncertain by an order of magnitude. The comparison between design options is trustworthy long before the absolute number is
• Cost of maintenance: A large tree represents months of effort and decays quickly once the design changes, so the analysis must be resourced for the whole program, not only for the certification milestone

None of these limitations argues against fault tree analysis. They argue for pairing it with inductive and systems-theoretic methods, and for reporting its results as structured insight into failure architecture rather than as a measured property of the hardware.

Living Document Management

Fault trees should be maintained throughout the product lifecycle:

• Design evolution: Update fault trees as design matures and changes
• Field data incorporation: Refine basic event probabilities based on actual field failure data
• Configuration control: Manage fault tree versions corresponding to product configuration
• Change impact: Assess impact of design changes on fault tree results
• Lessons learned: Incorporate field failure insights to improve completeness

Maintaining fault trees as living documents maximizes return on analysis investment and ensures relevance throughout product life.

Dynamic Fault Trees

Dynamic fault trees model sequence and time-dependent failure behavior:

• Sequence dependence: Priority AND gates model failures that cause the top event only if occurring in specific sequence
• Spare gates: Model standby redundancy with cold, warm, or hot spare behavior
• Functional dependencies: Model situations where one component failure affects availability of others
• Markov model conversion: Dynamic trees can be converted to Markov models for solution
• Mission phases: Model systems with different configurations during different mission phases

Dynamic fault trees extend FTA capability to systems where traditional static analysis is insufficient because of temporal dependencies. The extension is not free: solving a dynamic subtree as a Markov chain means enumerating system states, and the state count grows roughly as a power of the number of components, so practical tools isolate the dynamic modules, solve each as a small Markov model, and fold the results back into an otherwise static tree.

Modular Decomposition

Modular approaches manage large fault tree complexity:

• Module identification: Identify subtrees that share no basic events with the rest of the tree
• Independent calculation: Calculate module probabilities independently and substitute into parent tree
• Computational efficiency: Modular decomposition dramatically reduces calculation time for large trees
• Repeated events: Repeated events appearing in multiple tree locations require special handling
• Hierarchical analysis: Natural mapping to system hierarchy enables distributed analysis

Large fault trees may contain thousands of basic events. Modular decomposition makes analysis tractable while preserving accuracy.

Non-Coherent Fault Trees

Non-coherent trees include negated (NOT) events representing success:

• Success branches: Some failure scenarios require both failure and success events to occur
• Complement events: NOT gates or complement events represent component success or non-occurrence
• Implicants versus cut sets: Non-coherent trees yield prime implicants rather than minimal cut sets
• Calculation complexity: Standard Boolean reduction and rare event approximation require modification
• Practical occurrence: Non-coherent situations arise in protection system analysis and human action modeling

While most reliability applications involve coherent systems, analysts should recognize non-coherent situations and apply appropriate methods.

Bayesian Updating

Bayesian methods update fault tree results as new information becomes available:

• Prior distributions: Initial basic event probabilities expressed as probability distributions
• Evidence incorporation: Field data, test results, or expert judgment updates distributions
• Posterior distributions: Updated probability distributions reflect combined prior knowledge and new evidence
• Propagation: Updated basic event distributions propagate through fault tree to update top event
• Decision support: Bayesian updating enables value of information analysis for data collection decisions

Bayesian approaches formalize how FTA results should evolve as system experience accumulates, supporting continuous improvement of reliability estimates. In practice the arithmetic is often kept simple by conjugate pairings: a beta prior updated with the number of failures observed in a given number of demands for per-demand probabilities, and a gamma prior updated with failures observed over accumulated operating hours for failure rates. Both yield closed-form posteriors, which makes routine re-estimation from field data cheap enough to perform at every reliability review.