FTA: Top-Down Fault Tree Analysis

14.1 The FTA artifact: structure and gate types

H.A. Watson developed Fault Tree Analysis at Bell Labs in 1962 for the safety analysis of the Minuteman missile launch control system. Over the following decades it became the standard hazard-analysis method for nuclear power (USNRC), aerospace (ARP 4761) and high-consequence industrial safety (IEC 61025). Its appeal is that it makes the logical structure of the hazard visible. You can see which combinations of basic events cause the top event, and which mitigations break which combinations.

File structure

An .fta file declares one fault tree, anchored on one top event. The hdef carries topevent ref failuremode <X>, naming the failure mode (typically from an .flr) at the tree's root. The body is a hierarchy of def gate clauses. Each gate has a gatetype (one of and, or, xor, inhibit), its children as input ref failuremode|gate, and its parent as output ref failuremode|gate.

Failure modes are the basic events at the tree's leaves, and gates are the intermediate nodes. A gate's output is either the failure mode it produces or the parent gate it feeds into.

hdef faulttree EpbVehicleRollawayFTA
  name "Vehicle Rollaway Fault Tree"
  safetylevel ASIL-D
  topevent ref failuremode VehicleRollaway

  def gate rollawayRoot
    name "Vehicle rollaway root"
    gatetype or
    input ref gate clampForceLost
    input ref gate holdMonitorFailed
    output ref failuremode VehicleRollaway

  def gate clampForceLost
    name "Clamp force lost or insufficient"
    gatetype or
    input ref failuremode ClampForceUndershoot
    input ref gate sensorFault
    input ref gate motorFault
    output ref gate rollawayRoot

The four gate types

AND. The output occurs if and only if all inputs occur. AND gates represent redundancy: the top event happens only if every input event happens at the same time. They multiply low probabilities into low top-event probabilities, which makes AND gates the safety engineer's friend.

OR. The output occurs if any input occurs. Any one input is enough, so each input is a single point of failure for the output. OR gates raise top-event probability; they are the failure-analysis equivalent of weak links.

XOR. The output occurs if exactly one input occurs. It's rare in practice and used for mutually exclusive trigger conditions.

INHIBIT. The output occurs if the primary input occurs and a conditional input is also true. INHIBIT gates model a failure cause that only matters under specific operating conditions. For example, an EPB caliper bearing failure causes vehicle rollaway only when the vehicle is parked on a gradient, so the gradient is the INHIBIT's conditional input.

What follows

Subchapter 14.2 covers the cut-set analysis a fault tree makes possible: finding the minimal sets of basic events whose simultaneous occurrence causes the top event. Subchapter 14.3 covers the ASIL/DAL decomposition method that fault trees support (ISO 26262 Part 9, and the equivalent in DO-178C). Subchapter 14.4 closes with the EPB and autopilot worked examples.

14.2 Cut sets and quantitative analysis

A fault tree is worth more than its picture, because it supports two analytical techniques. Cut-set analysis enumerates the minimal sets of basic events whose simultaneous occurrence causes the top event. Quantitative top-event probability estimates how likely the top event is, given the probabilities of the basic events. Both are standard in nuclear-power probabilistic safety assessment and aerospace safety analysis, and Sylang Studio's FTA tooling supports both.

Minimal cut sets

A cut set is a set of basic events whose simultaneous occurrence causes the top event. A minimal cut set is one from which you can't remove any event without breaking the cut: it is locally minimal, and every event in it is necessary. The minimal cut sets of a fault tree, taken together, are the complete characterization of the tree's failure modes.

Cut-set analysis answers the safety-critical question: what are the simplest ways the top event can occur? A minimal cut set of size 1 (a single basic event that alone causes the top event) is a single point of failure. ASIL-D and DAL-A items typically require no minimal cut sets of size 1, so every path to the top event needs at least two simultaneous failures. That's the formal version of the redundancy principle.

Take the EPB anchor's VehicleRollawayFTA. The minimal cut sets computed by the Sylang Studio FTA workbench include {ClampForceUndershoot}, {ForceSensorOpenCircuit}, {ForceSensorDrift}, {MotorStall, MotorBondWireFail} and {ClampForceUndershoot, ForceSensorOpenCircuit}. The first three are size-1 cut sets: single points of failure. Their existence means the vehicle-rollaway analysis is not yet ASIL-D-compliant against the redundancy principle.

Quantitative top-event probability

Given probability estimates for each basic event, you can compute the top-event probability analytically. The estimates typically come from the FMEA's failurerate property, in failures per hour or per cycle. An AND gate multiplies its inputs' probabilities. An OR gate uses the inclusion-exclusion principle (for small probabilities, the approximation P(A or B) ≈ P(A) + P(B) is used), and complex trees are computed recursively.

ISO 26262 Part 9 defines target failure rates per ASIL level for the probabilistic safety analysis. ASIL-D corresponds to a probabilistic failure metric (PMHF) of <10^-8 per hour for safety-related faults that lead to hazardous events; ASIL-B is <10^-7. The fault tree's quantitative analysis is your evidence that the design meets these targets.

Sylang Studio's FTA tooling computes both the minimal cut sets (a combinatorial analysis) and the quantitative top-event probability (a numerical analysis), and the FTA workbench shows them together. The numerical analysis cites each basic event's failure rate by reference to the underlying FMEA. That keeps the two analyses in agreement.

What follows

Subchapter 14.3 covers ASIL/DAL decomposition through FTA. Subchapter 14.4 closes the chapter with the worked examples.

14.3 ASIL decomposition (ISO 26262 Part 9 Annex C)

ASIL decomposition realizes an ASIL-D safety requirement through two or more independent channels, each carrying a lower ASIL, so that the combined channels achieve ASIL-D safety integrity. ISO 26262 Part 9 Annex C specifies the technique. It is also the main economic motivation for redundancy in automotive safety architectures: two ASIL-B channels are substantially cheaper to implement than one ASIL-D channel. The fault tree is the formal vehicle for documenting the decomposition, and this subchapter shows you how.

The decomposition principle

In its simplest form, the principle gives four ways to implement an ASIL-D safety requirement. You can use two independent ASIL-B(D) channels, one ASIL-C(D) and one ASIL-A(D) channel, one ASIL-D channel (no decomposition, the baseline), or two ASIL-D channels (additional redundancy). The notation ASIL-X(Y) means implemented at ASIL-X, originating from an ASIL-Y requirement. The parenthetical keeps the safety case argument traceable to the original requirement.

The key word is independent. The two channels must not share a common-cause failure mode, and their failures must be statistically uncorrelated. The FTA is what documents the independence: the cut-set analysis confirms that no minimal cut set contains events from both channels' implementations. Without the FTA, the decomposition is unjustified, and the auditor will reject it.

ASIL decomposition in practice

The EPB dual-motor caliper anchor is the book's worked example of ASIL decomposition. The safety goal SG_NoLatentMotorFault is ASIL-D, and so is the implementing requirement REQ_EPB_003 (motor cross-check). The two channels, Motor A and Motor B, each carry their own ASIL-D motor controller. The cross-check function (also ASIL-D) provides the independence check that justifies the dual-channel architecture.

The fault tree EpbLatentMotorFTA documents the cut-set analysis. The top event (LatentMotorFaultState) occurs only when both MotorDivergence (the cross-check detection) and crosscheckFailed (failure of the cross-check itself) occur. Every cut set has size 2 or larger, so no single failure produces the top event. The argument that the architecture meets ASIL-D's redundancy requirement rests on this FTA.

The DO-178C analog

DO-178C has no direct analog to ISO 26262 Part 9 ASIL decomposition. The DAL (Design Assurance Level) framework treats redundancy at the system architecture level (per ARP 4754A), not as a decomposition of software requirements. The underlying technique is the same, though: use FTA to show that no single failure produces a hazardous outcome. The autopilot anchor's protection-law FTA serves that purpose in the DO-178C context.

What follows

Subchapter 14.4 closes the chapter with the EPB and autopilot worked examples, and ties FTA back to Chapters 12 and 13.

14.4 FTA walkthrough: EPB and autopilot

This subchapter walks the EPB anchor's two fault trees, EpbVehicleRollawayFTA and EpbLatentMotorFTA, both authored in the companion repository. It also looks at the autopilot anchor's planned fault trees. Along the way, we'll connect this chapter to Chapters 12 (safety chain) and 13 (FMEA).

EpbVehicleRollawayFTA

The vehicle-rollaway fault tree is anchored on the VehicleRollaway failure mode, a top event in the FMEA. It has four gates, and its leaves are the corresponding .flr basic events:

• rollawayRoot (the root): OR of clamp-force-lost and hold-monitor-failed.
• clampForceLost: OR of clamp force undershoot, sensor faults and motor faults.
• sensorFault: OR of force-sensor open-circuit and drift.
• motorFault: OR of motor stall and bond-wire failure.

Cut-set analysis finds several single-point failure paths (the size-1 cut sets from Subchapter 14.2). The safety mechanisms of Chapter 12 Subchapter 4 are designed specifically to break each of them. RedundantClampForceMonitor breaks the sensor-fault paths, and PersistentFaultEscalation catches the clamp-force-lost path that monitoring missed. SpeedGatedEngagement prevents the engagement-during-motion path that would compound the rollaway risk.

EpbLatentMotorFTA

The latent-motor-fault tree is anchored on LatentMotorFaultState, the dual-motor variant's most dangerous failure mode. It has two gates: the root latentRoot (AND of MotorDivergence and crosscheckFailed) and crosscheckFailed (OR of motor-stall and motor-bond-wire-fail). The AND at the root is the redundancy argument. The latent fault only manifests if the divergence occurs and the cross-check fails to detect it.

The minimal cut sets are {MotorDivergence, MotorStall} and {MotorDivergence, MotorBondWireFail}, both of size 2. Those size-2 cut sets justify the ASIL-D claim under the redundancy principle of Subchapter 14.3: no single failure produces the top event.

Autopilot fault trees (planned)

The autopilot anchor's planned fault trees would include AlphaProtectionLockoutFTA (the stall top event), BankAngleLockoutFTA (the over-bank top event) and OverspeedLockoutFTA (the V_MO/M_MO exceedance top event). Each top event is a failure of the corresponding protection law to engage when needed. Their cut sets would document the redundant-sensor and redundant-channel architecture that justifies the DAL-A claim under DO-178C. The autopilot anchor itself is not yet complete.

Integration with Chapters 12 and 13

FTA, FMEA and the safety chain connect through shared failure-mode identifiers. A failure mode defined in .flr can be a basic event in .fta (input ref failuremode <X>). It can be detected by a safety mechanism in .sam (detects ref failuremode <X>), and it can be the malfunction behind a hazard in .haz. That one identifier ties the three artifacts together, and the coverage analysis of Chapter 15 reports their cross-artifact consistency.

This is what lets the bottom-up FMEA and the top-down FTA be two views of one safety analysis, rather than competing parallel artifacts. In legacy MBSE practice, different tools (often from different vendors) produce the FMEA and the FTA, and people keep them consistent by hand. If you've ever had to reconcile the two before a review, you know how quickly they drift apart. Sylang's shared identifiers remove that drift by construction.

Closing Chapter 14

You now have FTA at the depth you need for production authoring. We covered the artifact's structure and gate types (14.1) and cut-set analysis with quantitative top-event probability (14.2). Then came ASIL decomposition through FTA (14.3) and the worked examples that tie FTA to FMEA and the safety chain (this subchapter).

Chapter 15 covers the cross-cutting traceability and coverage analyses that make the whole artifact set auditable. It matters to engineers, whose daily workflow runs on the coverage report, and to auditors, whose review process only scales with coverage tooling.

Exercises (Chapter 14)