Structuring the fault tree for FAA / EASA review

Why aviation FTA is a different conversation

Three structural differences between an aviation safety case and any other domain shape how the tree gets read:

1. The acceptable failure rate scales with consequence severity, not with development cost. 14 CFR 25.1309(b) and CS-25.1309 specify that the probability of any failure condition must be "inversely proportional to the severity of its effects". Catastrophic conditions must be extremely improbable (≤ 10⁻⁹/flight-hour); hazardous conditions extremely remote (≤ 10⁻⁷); major conditions remote (≤ 10⁻⁵); minor conditions probable (≤ 10⁻³). These thresholds are bright lines, not negotiating positions.
2. The tree must trace to a specific failure condition in the FHA. Every top event in an SSA-supporting FTA is a verbatim failure condition from the Functional Hazard Assessment. Aggregating two failure conditions into one tree to share basic events, or splitting one across multiple trees, both break the traceability the certification engineer is using to verify completeness. One FHA failure condition, one FTA, no exceptions.
3. "No single failure causes catastrophic" is a separate claim. The reviewer specifically checks that the minimal cut sets of every catastrophic-classified tree contain no order-1 cuts. This is a structural property of the tree, independent of probabilities, and it is its own audit item — passing the 10⁻⁹/flight-hour quantification while having a single basic event in an order-1 cut is a non-finding-but-noted observation that triggers a redesign conversation regardless of the rate.

Beyond these three, aviation tree submissions tend to be larger than automotive ones (a single-aisle aircraft's complete SSA covers thousands of failure conditions across hundreds of trees) and are reviewed against published advisory circulars (FAA AC 25.1309-1A, EASA AMC 25.1309) that name specific expectations the trees have to satisfy. The volume alone is why structural conventions matter: the certification engineer is reading dozens of trees for one programme, and consistency of structure is what lets them spot the one that's wrong.

Step 1The ARP 4761 framework FTA fits into

FTA isn't a standalone deliverable in the aviation safety process — it's the deductive technique inside a larger framework. The framework progresses through four phases, each of which produces artefacts that flow into the next:

The two structural points to note for tree-builders crossing over from other domains:

• The FTA is built twice. Once preliminarily during PSSA (with allocations), once verifying during SSA (with validated data). Both versions live in the safety case; reviewers compare them to confirm the architecture didn't drift between phases. Trees that show only the SSA version with no PSSA traceability raise a "where did the allocations come from" question that's painful to answer late.
• CCA is a peer to FTA, not a sub-process. The Particular Risks Analysis is its own deliverable; the Zonal Safety Analysis is its own deliverable; the CMA is its own deliverable. Their outputs fold back into the FTA as new basic events or shared-cause links, but the analyses are run independently and the artefacts stand alone. β-factor CCF (the automotive convention covered in Article 5) is not the aviation answer to common-cause; CCA is.

Step 2What the reviewer actually looks at

Six things a certification engineer examines on a submitted FTA, in roughly the order the issues tend to surface during review. Knowing the order lets the analyst pre-empt findings — most of these are cheap to fix during build and expensive to fix during certification.

Two structural patterns under these are worth naming:

The "no single failure causes catastrophic" check is structural, not numerical

For any tree with severity classification Catastrophic, the reviewer reads the minimal cut-set list and confirms that no order-1 cut exists. This is independent of the per-cut probability — even an order-1 cut at 10⁻¹²/h is a finding, because the property being verified is the architecture's robustness to single-point failure rather than its quantitative rate. AC 25.1309-1A explicitly requires this property; CS-25.1309 §AMC matches. Trees where an order-1 cut survives the SSA tend to have a basic event that "shouldn't really be order-1 because we mitigate it operationally" — the reviewer's response is "operational mitigation isn't a basic-event property, model it as an INHIBIT gate or accept the order-1 finding".

"Probability of failure" vs "Average Probability of Failure on Demand"

Aviation and process-industry reviewers use different conventions for what gets quantified. ARP 4761 defaults to per-flight-hour rates (a continuous demand profile). IEC 61511 SIS conventions (used in process plants) default to PFD_avg — the time-averaged probability that the safety function is in the failed state when called upon. Trees that mix the two — perhaps because the analyst was trained in one domain and is now submitting in the other — produce numerically incomparable cut sets. ARP 4761 §3.4 names this trap explicitly; the reviewer flags any tree where some basic events are rates and others are demand probabilities without an explicit mapping.

Step 3Worked example — total loss of aircraft hydraulic power

Take the failure condition from the FHA verbatim: "Total loss of aircraft hydraulic power". Severity classification: Catastrophic (loss of primary flight controls, landing gear retraction, normal braking). Per-condition target: ≤ 10⁻⁹ /flight-hour. Development Assurance Level: DAL A.

The architecture is the canonical wide-body civil pattern: three physically and electrically independent hydraulic systems (System A, System B, System C), each capable of supporting flight on its own. Top-level structure:

Total Loss of Aircraft Hydraulic Power
                  │
                  ▼
                 AND
                / | \
              A   B   C    ← three independent hydraulic systems
              │   │   │
             OR  OR  OR    ← per-system failure modes
            /|\  /|\  /|\

First-pass quantification — independent failures only

Per-system failure rate, summing the dominant contributors (engine-driven pump, line rupture, fluid loss): approximately 10⁻⁵/h per system. Validated data sources: MIL-HDBK-217F Notice 2 for the pump and pressure-regulator failure rates, NPRD-2016 for tubing and seals, vendor-supplied FMEDA for the system-level reservoir and accumulators. With three independent systems and a typical 5-hour flight mission:

P(System X fails over 5h mission) ≈ 10⁻⁵ × 5 = 5×10⁻⁵
P(all three independent fails)    ≈ (5×10⁻⁵)³ = 1.25×10⁻¹³ /mission
Per-flight-hour rate              ≈ 1.25×10⁻¹³ / 5 ≈ 2.5×10⁻¹⁴ /flight-hour

2.5×10⁻¹⁴/h vs the 10⁻⁹/h target. The independent-failures arithmetic gives an answer five orders of magnitude under target — comfortably catastrophic-extremely-improbable, on paper.

This number is also a fantasy, and the certification engineer knows it. The Sioux City story (UA Flight 232, 1989) is the canonical instance: triple-redundant DC-10 hydraulics defeated by a single fan-disc fragment that punctured all three systems simultaneously. The independent-failures arithmetic ignored the particular-risk path entirely, and the actual dispatch-relevant rate was dominated by it. The next step is exactly the structural lesson the post-Sioux City regulatory environment crystallised: independent-failure quantification is necessary but not sufficient. CCA's three sub-analyses each contribute order-1 or order-2 cuts that the independent tree never sees.

Second-pass — folding in the CCA results

The Common Cause Analysis (run in parallel with the SSA) yields three new basic events, each entering the FTA at the top level via OR with the independent-failure AND-gate:

Re-quantifying the top event with these added:

P(TOP) ≈ P(independent ABC) + P(PRA) + P(ZSA AND System C) + P(CMA)
       ≈ 2.5×10⁻¹⁴ + 1.0×10⁻⁹ + (5×10⁻¹⁰ × 5×10⁻⁵×5)/5 + 2.0×10⁻¹⁰
       ≈ 1.0×10⁻⁹ + (negligible) + 2.0×10⁻¹⁰
       ≈ 1.2×10⁻⁹ /flight-hour

1.2×10⁻⁹/h vs 10⁻⁹/h target. Fails the catastrophic threshold — the PRA basic event alone is already at 10⁻⁹/h and the CMA stacks on top. The independent-failures contribution is invisible at this scale; the per-system reliability programme is doing nothing for the limiting answer.

Third-pass — design response

The certification engineer reads the order-1 cut {BE-PR-001} and the order-1 cut {BE-CM-001} and asks: what mitigates these directly? The architectural responses are the same ones the post-Sioux City era introduced into wide-body design:

• Ram Air Turbine (RAT) — an emergency hydraulic-and-electrical power source independent of the three primary systems, deployed on dual-engine failure or total hydraulic loss. Adding it as a 4th branch under the top-level AND turns each PRA-driven cut from order 1 into order 2: {BE-PR-001, RAT-fails}. With RAT failure rate ~10⁻³/h, that cut becomes 10⁻⁹ × 10⁻³ = 10⁻¹²/h. Same logic for the CMA cut.
• Hydraulic-line zonal separation — System C is routed through the keel beam rather than the wing roots, satisfying the ZSA's "no single zone takes out 2+" requirement. This is what made the ZSA cut order-2 rather than order-1 in the table above.
• Fluid-servicing diversity — three separate servicing ports, three separate fluid lots, three separate verification samples. Eliminates the CMA basic event entirely. Carried as a maintenance-programme requirement in the safety case (the FTA references the AMM procedure directly).

Re-quantified with RAT and CMA-eliminated:

P(TOP) ≈ P(PRA AND RAT-fail) + P(independent ABC) + P(ZSA AND C-fail)
       ≈ 1×10⁻⁹ × 1×10⁻³ + 2.5×10⁻¹⁴ + ~10⁻¹⁴
       ≈ 1.0×10⁻¹² /flight-hour

10⁻¹²/h, three orders of magnitude under the catastrophic target. The architecture meets the rate, the order-1 catastrophic cuts are eliminated, and every basic event has a validated data source. The submission package contains the three trees (independent-only, post-CCA, post-mitigation) so the reviewer can see exactly how the architecture evolved to clear the bar.

Step 4How CCA findings actually fold back into the FTA

The mechanical question is: where in the tree does each kind of CCA finding land, and what data source supports its basic-event probability? Three sub-analyses, three different patterns:

The integration discipline is the part that's easy to get wrong. Each CCA sub-analysis is run by a different specialist (zone engineer, particular-risk engineer, software diversity reviewer), produces its own report, and feeds basic events into the FTA via change-impact analysis. Changes to any of the three CCAs trigger an FTA revision. Trees that lag the CCA — common in late-stage programmes where requirements are churning — get flagged as "not aligned with current CCA findings", which is its own audit item separate from the technical content.

Five pitfalls a reviewer will catch

• PSSA-to-SSA drift. The PSSA tree was built early on architecture allocations; the SSA tree is built later on validated data. If the architecture changed between phases — a subsystem consolidation, a software re-platforming, a vendor switch — the PSSA→SSA traceability breaks. Reviewers' standard question: "show me the change-impact-analysis from rev X to rev Y of the architecture, and the corresponding FTA revision". Trees without explicit revision history relative to the architecture get flagged.
• Independence asserted without ZSA cross-check. Two redundant items "in different boxes" might be in the same zone — same fire hazard, same single-fluid leak. The ZSA is the artefact that confirms physical separation; assertions of independence in the FTA that don't have a ZSA reference are reviewer-bait. Cite the zone identifier; cite the ZSA finding.
• CMA shortcuts. "Diverse implementations" listed without naming the diversity dimensions (different language, toolchain, team, design philosophy, review process per ARP 4754A §5.4.1) is a flag. Reviewers spot this immediately because the CMA report has to enumerate the dimensions; a missing enumeration usually means the diversity hasn't actually been engineered.
• Mission-profile assumptions buried in a single number. A basic event at 5×10⁻⁵/year converts to per-flight-hour only if you know the assumed annual flight hours. A 737 cycles every 2 hours; a 777 averages 12 hours per flight. Stating "8000 flight hours/year" inline next to the conversion makes the assumption auditable; omitting it doesn't make it go away.
• Data-source citation without revision number. "MIL-HDBK-217" without the Notice qualifier (217E vs 217F vs 217F Notice 2) gives different rates for the same component class. NPRD-2016 differs from NPRD-2011. FIDES 2009 differs from FIDES 2004. Reviewers expect the revision; "MIL-HDBK-217F Notice 2, January 1995" is the correct citation form.

Where to go next

• Open the hydraulic-loss template. FTA Studio ships the aviation_loss_of_hydraulic_power tree as one of the eight industry templates; the AND-of-three structure used in this article's worked example is already in place. Adjust the basic events to your aircraft's specific architecture.
• For the underlying SSA workflow, the ARP 4761 reference page covers the FHA / PSSA / SSA / CCA framework at the standards level.
• For the cross-technique view, Article 4 covers FTA + FMEA + ETA together; ARP 4761 SSA is the canonical instance of all three running in concert.
• For comparison with other domains, Article 6 (automotive ASIL decomposition) and the upcoming Article 9 (rail EN 50126 RAMS Phase 4) cover the equivalent regulatory frameworks. The structural patterns repeat with vocabulary variations.