MISSION READY | REQUS AI

            Newsletter
          

Software Reliability & System Safety

The Blind Spot in Airworthiness Software Standards

Why DO-178C-compliance is necessary but not sufficient.

Every software-driven fatal crash of the last decade shares an uncomfortable feature: the software worked exactly as designed.

It passed its requirements-based tests. It passed its structural coverage analysis. It was certified. And it still killed people, because nobody wrote down the requirement it violated. This is the gap this newsletter is about — not a bug in DO-178C's execution, but a hole in what the standard was ever designed to check for.

What DO-178C actually verifies

DO-178C, the standard that governs software in civil aircraft, is built around two pillars:

Requirements-based testing — proving that the software does everything the "shall" statements in its requirements document say it should do.

Structural coverage analysis, most famously MC/DC (Modified Condition/Decision Coverage) at the highest design assurance levels — proving that every condition in every decision has been independently exercised, so there's no dead or under-tested logic hiding in the code.

Both are real engineering achievements. MC/DC is one of the most rigorous coverage criteria in any industry, and requirements-based testing is a legitimate way to catch implementation defects — code that doesn't do what it was told to do.

MC/DC tells you your code correctly implements the logic you specified. Requirements-based testing tells you the code satisfies the "shall" statements someone wrote down. Neither one asks whether the requirements document itself was complete.

If an engineer never wrote "the software shall cross-check the angle-of-attack reading against airspeed and pitch trend before commanding a nose-down input," then no amount of MC/DC coverage or requirements-based testing will ever catch its absence. You can achieve 100% structural coverage of a system that is missing an entire category of defensive behavior, and DO-178C's own paperwork will call that a success.

This is sometimes called the implied requirements problem, and it's arguably the most consequential gap in modern flight software assurance. Two recent crashes make the case better than any white paper could.

Case study 1: The 737 MAX and the single sensor

2018–2019 · Lion Air 610 & Ethiopian Airlines 302 · 346 lives lost

The Maneuvering Characteristics Augmentation System (MCAS) on the Boeing 737 MAX was designed to push the aircraft's nose down automatically when its angle-of-attack (AoA) reading suggested an approach to stall. The aircraft carried two independent AoA sensors. MCAS, as certified, read from only one of them per flight, with no comparison against the second sensor and no plausibility check against other available data — airspeed, pitch rate, or the aircraft's own recent trajectory.

On both flights, a single faulty AoA sensor fed MCAS a false stall signal. MCAS did exactly what it was built to do: it repeatedly commanded the nose down, fighting the pilots, until both aircraft crashed.

Nothing about this was a coding defect in the MC/DC sense. The requirements said "if AoA exceeds threshold, command nose-down trim," and the code did exactly that. What was missing was a requirement nobody wrote: the system shall not take an irreversible or hard-to-reverse flight control action based on a single sensor when a second, independent sensor is available and could be compared. Boeing's eventual fix — comparing both AoA sensors and disabling MCAS on disagreement — is precisely the implied requirement that should have existed from the start.

Notional diagram: MCAS reads a single faulty AoA sensor and ignores the correct reading from the second sensor, repeatedly commanding a nose-down dive

            NOTIONAL — MCAS reads one AoA sensor reporting a false stall, ignores the correct reading from the second sensor, and repeatedly commands nose-down trim.
          

Case study 2: The F-35 and the sensor the software trusted alone

January 2025 · Eielson Air Force Base, Alaska · AIB report released August 2025

An F-35A crashed at Eielson Air Force Base after a training flight. The Air Force's accident investigation traced the chain of causation to water-contaminated hydraulic fluid that froze inside the landing gear struts, preventing them from fully extending.

The critical software moment came next. The jet's Weight-on-Wheels (WoW) sensors — plunger-type sensors that detect physical contact between the landing gear and the runway — registered "on ground" because the still-retracted struts held them in the ground position. All of the WoW sensors agreed with each other, so from a narrow internal-consistency standpoint they were "valid." The flight control system, on receiving that WoW signal, switched to its "on-ground" control law — a mode built for taxiing, not flying.

222 kt

airspeed when WoW read "on ground"

372 ft

altitude AGL at the same moment

sensor category trusted alone

The jet immediately became uncontrollable, snapping into a 30–40 degree pitch-up with a 38-degree roll, and the pilot was forced to eject.

This is a different flavor of the same underlying gap. The WoW sensors weren't malfunctioning by their own narrow definition — they were reporting exactly what their mechanical inputs told them. The failure was architectural: the flight control law made an irreversible mode transition based on one sensor category, with no cross-check against other data the aircraft already had on board and that would have flatly contradicted the WoW reading — airspeed and altitude chief among them. What didn't exist was a requirement to ask a second question before trusting the first answer: does this decision make sense given everything else the aircraft knows about its own state?

Notional diagram: the F-35 flight control law trusts a single WoW sensor and switches to ground mode while airspeed and altitude clearly show the aircraft is still flying

            NOTIONAL — the flight control law trusts a single WoW sensor reading and switches to ground mode while airspeed and altitude data, never consulted, clearly show the aircraft is still flying.
          

The pattern underneath both crashes

Strip away the specific hardware and both accidents reduce to the same three missing behaviors — none of which live inside the "shall" statements airworthiness testing verifies, and none of which MC/DC coverage could ever surface:

No sensor health / plausibility monitoring. The software had no independent way to ask "is this input even trustworthy right now?" before acting on it.

No cross-sensor comparison before irreversible actions. Both systems had a second, independent source of truth on board and neither consulted it before committing to an action that was hard or impossible to reverse in the time available.

No requirement to reconcile conflicting evidence. In both cases, other available data was inconsistent with the decision the software made, and the software had no mandate to notice.

None of these are exotic ideas. They're the kind of thing a systems safety engineer would sketch on a whiteboard in the first hour of a hazard analysis. The problem is that DO-178C's verification machinery has no natural place to catch their absence.

Where the CDE fits in

There is a resource built specifically to catalog this class of defect: the Common Defect Enumeration (CDE), developed by Ann Marie Neufelder of Mission Ready Software. It's worth distinguishing from the security world's Common Weakness Enumeration (CWE), which catalogs coding-level weaknesses that lead to exploitable vulnerabilities. The CDE has a different target: it's built from decades of root-cause analysis of real mission and safety failures.

Neither MCAS's single-sensor trust nor the F-35's uncross-checked WoW transition would show up as a CWE — they aren't coding-level vulnerabilities, they're architectural and requirements-level defect patterns. They're exactly the kind of root cause a CDE-style catalog is meant to surface during requirements and design review, before a single line of code is written or a single MC/DC branch is exercised.

What this means for the next generation of standards

None of this is an argument that MC/DC or requirements-based testing are wrong to require — they catch real, serious classes of defects and should stay. The argument is that they are necessary and not sufficient.

A more complete framework would need to explicitly require, as testable objectives in their own right:

Sensor health and plausibility checking as a first-class functional requirement, not an optional design choice left to individual engineers.

Mandatory cross-validation of independent data sources before any irreversible or high-consequence automated action.

A structured hazard-analysis step whose explicit job is to hunt for unstated requirements — not just verify stated ones.

The 737 MAX and the F-35 Alaska mishap didn't happen because engineers were careless or the code was buggy. They happened because the certification framework has no mechanism for catching a requirement that was never written down — and "the code does what we told it to do" is a very different claim from "the code does what it needed to do."

This is exactly what 6D CDE Software FMEA is built to catch

State-management and error-handling defects that MC/DC and shall-based testing structurally can't reach.

Explore Requs AI Software FMEA

Predict Earlier. Prevent More. Be Mission Ready.

Sources: U.S. Air Force Accident Investigation Board report on the January 28, 2025 F-35A mishap at Eielson AFB (released August 26, 2025); Ethiopian Airlines Flight 302 and Lion Air Flight 610 investigation findings on MCAS and single-sensor AoA input; Common Defect Enumeration (CDE), Mission Ready Software.