Jherrod ThomasThe Lion of Functional Safety™

September 5, 2026 · 16 min read

14 CFR 33.5 / 33.28 / 33.75ARP4761A / ARP4754B / 25.1309AD 2026-15-14 / TC CF-2025-12

When the Detector and the Isolator Lived in Different Type Certificates: The A220 EEC Bleed-Leak AD (2026-15-14) Through an ARP4761A and 14 CFR 33.28 Lens

The sentence that matters in AD 2026-15-14 is thirty-one words long and sits in paragraph (e): under certain large leak conditions the engine's electronic engine control "would not transmit the necessary information to the aircraft controller to automatically isolate the opposite engine from the leak path in the bleed system." The detection lives on Pratt & Whitney's type certificate. The isolation lives on Airbus Canada's. The coverage claim that binds them lived nowhere, and it took a design review to notice.

Nothing broke. No airplane was lost, no engine quit, no crew filed a report. A design review found a hole in protection logic, and the regulatory system spent two years closing it — first with a piece of paper in the flight manual, then with a software load. This is the cleanest example I have seen this year of a failure condition that is invisible to every verification activity you would normally run, because it is not a defect in anything. It is a gap between two correct things.

1. The public record

On July 30, 2026 the FAA published final rule AD 2026-15-14 (Amendment 39-23426, Docket FAA-2026-1336, Project Identifier MCAI-2025-00254-T, 91 FR 47951), effective September 3, 2026. It supersedes AD 2025-06-01 and applies to Airbus Canada Limited Partnership Model BD-500-1A10 and BD-500-1A11 airplanes — the A220-100 and A220-300 — covering 152 airplanes of U.S. registry.

The unsafe condition, verbatim from paragraph (e):

"This AD was prompted by a design review that discovered software protection logic for potential large leaks from the engine bleed duct inside the engine core compartments was partially impaired. Under certain large leak conditions ( e.g., a duct burst at a specific portion of the engine's bleed ducting), Pratt & Whitney's PW1500G engine's electronic engine control (EEC) would not transmit the necessary information to the aircraft controller to automatically isolate the opposite engine from the leak path in the bleed system." (91 FR 47951)

Consequence, also verbatim: "could result in dual engine failure."

The chain, assembled from the four Federal Register documents and the Transport Canada mandatory continuing airworthiness information:

| Date | Event | What it required | |---|---|---| | Aug 27, 2024 | Transport Canada AD CF-2024-30 issued | AFM "Non-Normal Procedure" revision — crew manually isolates the opposite engine | | Dec 13, 2024 | FAA NPRM, 89 FR 100923, Docket FAA-2024-2554 | Proposed IBR of CF-2024-30; ATA Code 72, Turbine engine; 132 U.S. airplanes | | Mar 4, 2025 | Transport Canada AD CF-2025-12 issued (published Mar 10, effective Mar 18) | Supersedes CF-2024-30; AFM within 90 days, EEC software 2.12.1 on both engines within 18 months | | Mar 18, 2025 | FAA AD 2025-06-01, 90 FR 12457, effective Apr 22, 2025 | AFM revision only | | Feb 23, 2026 | FAA NPRM, 91 FR 8390, Docket FAA-2026-1336 | Proposed adding the software mandate | | Jul 30, 2026 | FAA AD 2026-15-14, 91 FR 47951 | Retains AFM action, mandates EEC software 2.12.1 or later; ATA Code 73, Engine fuel and control | | Sep 3, 2026 | Effective; IBR of CF-2025-12 approved | 152 U.S. airplanes |

Two details in that table are worth more than they look.

The ATA code moved. The 2024 NPRM filed this under ATA 72, Turbine/turboprop engine. The 2026 final rule files it under ATA 73, Engine fuel and control. Same failure condition, same airplanes, same physics. What changed is that the mitigation stopped being a piece of hardware behaviour and became a piece of control-system behaviour, and the chapter assignment followed the fix rather than the hazard. Configuration systems index by fix. Safety cases have to index by hazard, and those two indexes drift apart exactly here.

The fix costs $850 and the alternative costs $1.29 million. The FAA's cost table: the retained AFM action is 1 work-hour at $85. The new software upgrade is 10 work-hours at $85 = $850 per product, $129,200 fleet-wide. The optional EEC replacement — which Delta asked the FAA to permit, and which the FAA granted as an optional method of compliance — is 9 work-hours plus $1,291,050 in parts, $1,291,815 per product. The FAA's own assessment: "it is not likely that operators would need to replace the EEC in order to complete the software upgrade; therefore, the rule is not significant." A catastrophic failure condition was closed for the price of a hotel weekend per airplane, seventeen months after the mandate that credited the flight crew instead.

The comment record is short and useful. ALPA supported the NPRM without change. Delta asked for two things: permission to replace rather than modify the EEC, and a definition of "EEC software version eligible for installation" as "V2.12.1 or later" so that future releases do not require a new AD. The FAA granted both by revising paragraph (h)(4), having "coordinated with Transport Canada regarding the acceptability of specifying later versions." That is a configuration-management concession with a quiet dependency: every later EEC release now has to carry, in its own change impact analysis, the demonstration that this specific protection logic survived.

There is one more thing in the record. The 2026 AD "also removes airplanes from the applicability" — production aircraft that will have an equivalent modification embodied before delivery. A cut-in. Which means for a window of about two years, the fleet contained three configurations of the same protection function: uncovered, crew-covered, and software-covered.

The other A220 EEC software AD, four years earlier

This is not the PW1500G's first protection-logic mandate, and the contrast is the whole argument.

On December 27, 2022 the FAA published an AD (effective January 31, 2023) requiring removal of certain EEC FADEC software versions across the PW1519G, PW1521G, PW1524G and PW1525G. The prompt was an in-service event — an A220 suffered an uncommanded dual engine shutdown on landing, losing engine power and hydraulic power with braking "significantly compromised." The Aviation Safety Network records a July 2021 airBaltic A220-300 (YL-AAQ) dual-engine shutdown on landing at Copenhagen. The FAA's finding, quoted in contemporaneous coverage: the auto-throttle increasing throttle to hold Mach, immediately followed by a pilot command to idle, "caused a transient disagreement between actual and commanded thrust," which "triggered the thrust control malfunction (TCM) detection logic and resulted in dual engine shutdown once the weight on wheels signal was activated upon landing." The installed software "latches the fault and allows the engine to continue operation as commanded but shuts down the engine upon landing." The fix revised the TCM trigger criteria and, critically, established criteria permitting the logic to unlatch in flight. 147 engines, two work-hours, $170 per aircraft, $24,990 fleet-wide. (AeroTime, December 28, 2022; AirInsight, December 24, 2022)

Set them side by side. Same engine, same airframe, same box, both protection logic, both ending in a mandated EEC software load, both capable of taking out both engines.

| | 2022 TCM AD | 2026 bleed-leak AD | |---|---|---| | Discovered by | In-service dual engine shutdown | Design review | | Defect type | Protection logic fires when it should not, and latches | Protection logic does not fire when it should, at one location | | Verification that would catch it | Requirements-based testing of the TCM trigger envelope | Nothing at the software level | | Interface involved | Engine-internal, plus weight-on-wheels | Engine detection to airframe isolation | | Cost to close | $170/aircraft | $850/aircraft, plus 17 months of crew procedure |

The 2022 one is a specification defect you can find with a test campaign, because the wrong behaviour is observable in a bench envelope sweep. The 2026 one is an omission at a supplier boundary, and no amount of testing either box finds it, because both boxes do exactly what their requirements say.

2. The standards lens

Who owns the failure condition

Dual engine failure is Catastrophic. Under 14 CFR 25.1309(b) and the guidance in AC 25.1309-1B, that classification drives an average probability per flight hour on the order of 1×10⁻⁹ and a hard prohibition on any single failure producing it. 14 CFR 25.901(c) adds the powerplant installation rule: no single failure or probable combination of failures may jeopardize safe operation, and it is 25.901(c) — not 25.1309 — that pulls the engine into the airplane's safety argument. Air duct systems and their failure effects fall under 14 CFR 25.1103; the engine core compartment is a designated fire zone under 14 CFR 25.1181.

On the engine side, three rules matter and all three are about the interface:

EASA's counterparts are CS-E 50 (engine control systems) and CS-E 510 (safety analysis), with the same structure: the engine declares, the airframe consumes.

Notice what all of that machinery is shaped to carry. It carries what the engine assumes about the airplane and what the airplane must supply to the engine. It is a specification of obligations. There is no rule anywhere in that chain that requires the engine to declare, enumerated by physical failure location, which failures its protection logic detects and which it does not. Coverage is not an obligation. Coverage is a property. And properties fall through interface documents.

The analysis that should have caught it

ARP4761A (2023) sets out the safety assessment process; ARP4754B (2023) sets out development assurance and the validation of requirements. The failure condition here — bleed duct rupture inside the core compartment, hot high-pressure air migrating through the cross-bleed path to the opposite engine — is a textbook Particular Risks Analysis item. PRA exists precisely for external events, like a duct burst or a rotor burst, whose effects sweep across otherwise independent systems and defeat the independence a fault tree assumes. Alongside it, the Zonal Safety Analysis examines the physical installation in the zone: what else is in the core compartment, what a released duct does to it, and whether the isolation architecture survives.

The intended mitigation is a two-supplier chain: engine detects, engine tells airframe, airframe closes the isolation valve. In fault-tree terms, that chain is the sole barrier between a duct burst and the loss of both engines. If it is the sole barrier for a catastrophic condition, its development assurance level is FDAL A, and its failure modes belong in the System Safety Assessment with the same rigour as an actuator.

And here is where DO-178C cannot help you. DO-178C verifies that the software satisfies its requirements, that no code exists without a requirement behind it (structural coverage analysis, MC/DC at Level A), and that no requirement exists without a test. It is a superb instrument for finding code that shouldn't be there. It has no objective whatsoever for finding a hazard that has no requirement in front of it. A protection function whose requirement says "detect a leak at stations 1 through 5" will pass Level A perfectly while a burst at station 6 goes unannounced. That gap is an ARP4754B requirements validation finding, not a DO-178C verification finding, and the two activities are usually run by different people at different companies against different documents.

Crediting the crew

For seventeen months — April 22, 2025 to September 3, 2026 on the FAA side — the mitigation for a catastrophic failure condition was a flight crew procedure. AD 2025-06-01 required the AFM "Non-Normal Procedure" to carry the steps for the crew to manually isolate the opposite functional engine.

AC 25.1309-1B permits crediting flight crew action, under conditions: the crew must be alerted to the condition, the procedure must be available and trained, and the time available must be adequate for recognition and response. The FAA leaned hard on the training half of that in the 2024 NPRM, declining to mandate crew notification because 14 CFR 91.9, 91.505 and 121.137 already require operators to furnish AFM changes and pilots to follow them, and because "training on the updated AFM content is tracked by the operators and recorded in each pilot's training record, which is available for the FAA to review."

That is a sound legal argument and an incomplete safety argument. The regulations guarantee the crew has the procedure. They do not establish the annunciation path by which the crew learns a large bleed duct leak is in progress at the one duct location the automatic logic does not cover — which is, definitionally, the case where the automatic system is silent. The crew procedure is a real risk control. It is a weaker one than the same procedure would be if the detection gap did not also degrade the alerting.

3. A worked snippet

Everything below is my reconstruction from the public record — an illustration of the artifacts this failure condition demands, not the type-certificate data.

Functional Hazard Assessment row (aircraft level, ARP4761A):

| ID | Function | Failure condition | Phase | Effect | Class | Objective | FDAL | |---|---|---|---|---|---|---|---| | FHA-PNEU-07 | Isolate a failed engine's bleed path from the cross-bleed manifold | Loss of automatic isolation following a large bleed duct rupture inside an engine core compartment | All | Hot high-pressure air migrates to the opposite engine core; loss of thrust on both engines | Catastrophic | Extremely Improbable, not more than 1E-9 per FH; no single failure | A |

Fault tree, top event FT-PNEU-07 — loss of both engines following core-compartment bleed duct rupture:

                 [TOP] Dual engine failure from cross-fed bleed duct rupture
                                       |
                                    ( AND )
                        _______________|________________
                       |                                |
             BE-01 Large bleed duct           IE-1 Failure to isolate the
             rupture inside engine            leak path before opposite-engine
             core compartment                 damage (window = FTTI)
             (particular risk, PRA)                     |
                                                     ( OR )
              ____________________________________________________________
             |               |                  |               |          |
        BE-02 Leak      BE-03 EEC          BE-04 Isolation  BE-05 Valve  BE-06 Crew
        occurs at a     detects but        message received  fails to    fails to
        duct station    does not assert    but airframe      close       isolate
        NOT covered     the isolation      controller does   on command  manually
        by EEC          message on the     not command                   within FTTI
        detection       engine-airframe    the valve
        logic           interface
             *              (SW fault)        (SW fault)     (HW fault)  (human)
             |
             +--> THIS IS THE AD. Not a fault. A coverage hole in the
                  requirement, with a full Level A verification record
                  sitting on top of it, all of it passing.

Interface coverage matrix — the artifact that does not exist. This is the table I want to see on every engine-to-airframe protection function, and the one whose absence is the entire story. Station names are illustrative:

| Duct station | Sensed by | EEC asserts LEAK_ISOL_REQ | Airframe auto-isolates | Detection coverage | Residual control | |---|---|---|---|---|---| | HPC bleed port to precooler inlet | Duct overheat loop + Pb/Tb model | Yes | Yes | Covered | — | | Precooler outlet to pylon interface | Overheat loop | Yes | Yes | Covered | — | | Core compartment run, aft segment | Overheat loop, degraded margin | Yes | Yes | Covered | — | | Core compartment run, station of interest | Not within modelled leak signature | No | No | NOT COVERED | AFM non-normal procedure only | | Pylon-to-wing crossover | Airframe leak detection loop | n/a (airframe) | Yes | Covered | — |

One row in that table is the difference between "Extremely Improbable" and "we sent 152 airplanes a checklist."

FTTI budget. A protection chain that spans two companies needs an end-to-end time budget with a named owner per segment, because the total is what the safety case claims and no single company can measure it:

| Segment | Owner | Budget | Verification | |---|---|---|---| | Rupture to detectable signature | Physics | 0.5 s | Rig test / CFD correlation | | Detection and confirmation in EEC | Engine (DAL A) | 1.0 s | HIL, fault injection at every station | | Assertion to airframe controller across the interface | Engine to airframe | 0.1 s | Bus timing analysis, worst-case latency | | Controller command to valve | Airframe (DAL A) | 0.2 s | HIL | | Valve travel to sealed | Airframe (hardware) | 2.0 s | Component qualification | | Total automatic isolation time | Integrator | 3.8 s | Aircraft-level integration test, all stations | | Manual alternative: annunciation to crew action complete | Crew | 30 s or more | Simulator evaluation per AC 25.1309-1B |

The manual path is an order of magnitude slower than the automatic path. That is not an argument against crew procedures. It is an argument for writing the number down, because "30 s or more" against a 3.8 s design intent is a decision somebody should have to sign, not a gap that gets papered by a flight manual revision and revisited eighteen months later.

4. Derived requirements (excerpt)

Five, with stable IDs, allocation, and verification method. These are what I would write against FHA-PNEU-07 to make the 2026 AD structurally impossible rather than merely fixed.

PNEU-SR-001 (FDAL A, allocated: engine supplier). The engine control system shall assert the bleed leak isolation request to the airplane bleed controller within 1.0 s of leak onset for a large bleed duct leak originating at any location in the engine bleed ducting within the engine core compartment. Verification: fault injection on HIL at every duct station enumerated in the engine bleed ducting configuration list, with the list itself under configuration control and traced to the ZSA. Traces to: FHA-PNEU-07, BE-02, BE-03.

PNEU-SR-002 (FDAL A, allocated: engine supplier, consumed by airframe). The engine installation instructions issued under 14 CFR 33.5 shall include a detection coverage declaration enumerating, for every bleed duct failure location identified by the zonal and particular risks analyses, whether the engine control system detects that failure and asserts the isolation request. Any location marked "not detected" shall carry an explicit statement of the residual risk control assumed of the installer. Verification: review against the ZSA and PRA location lists; coverage declaration signed by both the engine and airframe safety authorities. Traces to: 14 CFR 33.5, 33.28, 33.75; ARP4754B requirements validation.

PNEU-SR-003 (FDAL A, allocated: airframe integrator). The airplane-level System Safety Assessment shall not claim automatic isolation credit for any bleed duct failure location that PNEU-SR-002's coverage declaration marks "not detected." Any such location shall appear in the SSA as an uncovered path with its own classification and its own mitigation. Verification: SSA-to-coverage-declaration cross-reference review at each configuration baseline. Traces to: 14 CFR 25.1309(b), 25.901(c).

PNEU-SR-004 (FDAL A, allocated: integrator). End-to-end automatic isolation time, measured from leak onset to isolation valve sealed, shall not exceed 3.8 s at any covered duct station, with the per-segment budget of PNEU-SR-001 and the valve actuation requirement held as a single traced allocation. Verification: aircraft-level integration test at the worst-case station; worst-case latency analysis across the engine-airframe interface. Traces to: FHA-PNEU-07 FTTI.

PNEU-SR-005 (operational, allocated: integrator and operator). Where a flight crew procedure is credited as the mitigation for a Catastrophic failure condition pending a design change, the credit shall be recorded with (a) the annunciation path by which the crew is alerted, (b) the demonstrated crew response time, (c) a stated expiry date, and (d) a named owner of the terminating action. A crew-procedure credit without all four is not an acceptable interim risk control. Verification: review of the interim mitigation record at each safety review board. Traces to: AC 25.1309-1B crew action crediting criteria.

PNEU-SR-005 is the one most organisations do not have, and it is the one that decides whether "temporary" means eighteen months or eighteen years.

5. What the headline really tells us

The headline version of this is "FAA orders software update on A220 engines." The engineering version is that a catastrophic failure condition was mitigated by a chain crossing two type certificates, and no artifact in either certification basis was obliged to state how much of the hazard the chain actually covered.

Both companies did their jobs. Pratt & Whitney built protection logic to a requirement and verified it to DO-178C Level A. Airbus Canada built an isolation architecture that acts on the message it is sent. The engine's installation instructions declared what the engine needed from the airplane, exactly as 14 CFR 33.5 and 33.75 require. Nothing in that stack is a defect. The failure condition lived in the space between "the engine detects leaks" and "the engine detects leaks at these specific locations and not that one" — a qualifier that has a natural home in a zonal safety analysis, and no home at all in an interface control document.

So the missing artifact is a coverage declaration: a per-failure-location statement, owned jointly, of what the detecting party detects and what the acting party may therefore assume. Not a list of signals. Signals were fine — the interface carried an isolation request and the airframe honoured it. A list of hazards, mapped to whether the signal fires for each one. The second missing artifact is smaller and more common: an interim mitigation record with an expiry date on it, so that "the crew will handle it" is a dated liability rather than a permanent state that only ends when a superseding AD happens to come along.

The generalisable version has nothing to do with airplanes, and I say this deliberately because the same shape is sitting in every domain I work in. In automotive, ISO 26262 gives you the Hardware-Software Interface specification and the Technical Safety Concept precisely to force this conversation, and I still routinely see an HSI that lists every signal on the boundary and never states the diagnostic coverage each of those signals delivers against the failure modes it was invented for. In industrial, IEC 61508 hands you the safe failure fraction and diagnostic coverage as first-class quantities, and then the safety manual for a certified subsystem states them as a single aggregate number that the integrator cannot decompose by failure location. In medical, IEC 60601-1-8 tells you what to alarm on and rarely what you are structurally unable to detect.

So take your safety function that spans an organisational boundary — the sensor supplier and the controller supplier, the module vendor and the system integrator — and answer one question. For each hazard your detection element is credited with covering, is there a signed document that says so, hazard by hazard, rather than signal by signal?

If the honest answer is "the interface spec lists the signal, and coverage is implied," then you have the same file. The good news, and it is real, is that the A220's copy of this file was opened by a design review rather than by a hull loss. That is the system working. It should not have taken two years and a flight manual page to close it.

Sources

— Jherrod Thomas, The Lion of Functional Safety™