Boeing 737 MAX and MCAS: The Single Sensor Nobody Fault Injected

Mostafa Dhouib·August 19, 2026·6 min read

Boeing 737 MAX and MCAS: The Single Sensor Nobody Fault Injected

The short answer. A function classified as hazardous depended on one angle of attack sensor, where that classification implies a probability target no single sensor architecture can meet. The safety analysis also understated MCAS authority by more than four times. Fault injection at the system level exposes it; calling it a missing unit test does not.

What this case is and is not

The primary reports locate the cause in system safety assessment and requirements, not in a coding defect. The JATR review, the House Transportation and Infrastructure Committee's final report, the KNKT and Ethiopian accident reports and the DOT Inspector General's report all point at the same place: a hazard classification and an architecture that did not match, and a safety analysis that did not describe the system that shipped.

So this is not a story about a test somebody forgot to write. It is included here because it is the clearest available demonstration of something narrower and, for most engineering organisations, more useful: an assumption was recorded, treated as satisfied, and never driven. That is a verification failure, and the negative control that addresses it lives at the system level rather than the unit level.

What actually happened

MCAS, the Maneuvering Characteristics Augmentation System, relied on input from a single angle of attack sensor. When that sensor produced an erroneously high reading, MCAS repeatedly commanded nose-down stabilizer trim.

Lion Air flight JT610 in October 2018 and Ethiopian flight ET302 in March 2019. 346 fatalities.

Boeing's System Safety Assessment classified an MCAS malfunction as hazardous, one level below catastrophic. That classification carries a quantitative expectation: a hazardous failure condition implies a probability target on the order of one in ten million, which a single sensor architecture cannot meet, and which normally precludes depending on one input channel at all.

The design used one.

The certification safety analysis also understated MCAS's authority. The as-shipped system could move the stabilizer more than four times the range stated in the initial safety analysis document, and the analysis did not account for MCAS re-triggering repeatedly. The document described a system with less authority, exercised once. The aircraft had a system with more authority that could fire again and again.

The assumption nobody drove

Here is the part that generalises past aviation.

Somebody wrote down that MCAS malfunction was hazardous. That is a claim with consequences: it implies redundancy requirements, probability targets, and constraints on architecture. It was recorded, it entered the documentation, and the process treated it as a property the system had.

Nobody asked the machine.

The question is embarrassingly simple to state. Feed MCAS one erroneous angle of attack value and observe what happens. That is a fault injection test, and it directly exposes both facts at once: that the function depends on a single channel with no cross-check, and that a bad reading produces repeated nose-down trim rather than a single bounded correction.

It also would have exposed the authority discrepancy, because a test that runs the shipped system to its limit measures the shipped system rather than the document describing it. The four-times gap was not a secret being kept. It was a number nobody had measured against the artifact.

This is why ISO 26262 makes fault injection highly recommended at ASIL D rather than leaving detection to unit testing, and why it sets a Single Point Fault Metric of 99 percent or above at that level, assessed through fault injection campaigns specifically. Standards bodies arrived at injection rather than analysis because analysis has a poor record. Arguing that a fault would be detected and observing that it is detected are different epistemic acts, and only one of them is evidence.

The discipline scales

Set against the other cases in this cluster, MCAS marks the top of a range.

A units mismatch between two teams needs an assertion at the boundary, because no unit test inside either module can see it. That is Mars Climate Orbiter. A field count mismatch between a producer and consumer needs an invariant in the validator. That is CrowdStrike. A single point of failure in a hazardous function needs a fault injection campaign at the system level, because the property being verified is architectural and nothing below the architecture can observe it.

The move is identical every time: take the thing you believe is true, break it deliberately, and confirm something notices. What changes is the altitude at which you have to stand to break it.

The failure mode common to all of them is that the assumption gets written into a document, a validator, or a specification, and the writing feels like the verification. It is not. A recorded assumption is a claim awaiting a test, and it will agree with you for exactly as long as you are wrong.

The honest verdict

Would a negative control have caught this? Partially, and at the system level only.

A fault injection test feeding a single erroneous sensor value exposes the dependence and the runaway trim. That is a real, specific, cheap test, and its absence is a genuine finding. But the reports describe a certification process, a set of organisational pressures, and a hazard analysis that did not track the design as it evolved. Presenting all of that as a missing test would misrepresent them, and it would let every reader who has fault injection in place conclude they are safe from this.

The transferable finding is the one to carry: identify the single points of failure in anything safety relevant, and deliberately corrupt each one to confirm the system notices. If that list does not exist for your system, building it is the work, and it is usually a day.

The general argument is in a test that has never failed is a decoration. To enumerate the failure modes your current tests actually cover, and find the ones nothing drives, the failure mode coverage tool is built for that, and unidentified single points of failure are one of the five heaviest lines in the verification diligence scorecard.

FAQ

Why did MCAS depend on a single sensor? The design used one angle of attack input despite Boeing's own System Safety Assessment classifying an MCAS malfunction as hazardous. That classification implies a probability target on the order of one in ten million, which normally precludes dependence on a single channel.

Was the 737 MAX a software testing failure? Primarily it was a system safety assessment and requirements failure. The reports locate the cause in the mismatch between the hazard classification and the architecture, and in a safety analysis that did not reflect the shipped behaviour, rather than in a coding defect.

What test would have exposed the MCAS problem? A fault injection test feeding a single erroneous angle of attack value at the system level. It surfaces both the single point dependence and the repeated nose-down trim, and running the shipped system to its limits would also have exposed the more than four times authority discrepancy.

What is fault injection in a safety context? Deliberately corrupting an input or forcing an error to confirm the system detects and handles it. ISO 26262 makes it highly recommended at ASIL D and sets a Single Point Fault Metric of 99 percent or above there, assessed through fault injection campaigns.

What should other teams take from this? That a recorded assumption is not a verified one. List the single points of failure in anything safety relevant, corrupt each one deliberately, and confirm something notices. If that list does not exist yet, building it is the first day of work.