Boeing 737 MAX
What changes when a safety-critical control can act on one sensor?
After two 737 MAX crashes killed 346 people, the FAA identified the original MCAS reliance on one angle-of-attack sensor among the safety issues that had to be addressed. The revised design uses both sensor inputs and disables MCAS for the flight when their difference exceeds a threshold.
Documented impact
Authoritative findings
The documented event
Lion Air flight 610 crashed on 29 October 2018, killing all 189 passengers and crew; Ethiopian Airlines flight 302 crashed on 10 March 2019, killing all 157 passengers and crew. The NTSB reported that erroneous high angle-of-attack inputs resulted in MCAS activating on both accident flights and also produced multiple alerts and indications. The FAA's return-to-service review identified the original use of a single angle-of-attack sensor and repeated MCAS commands as safety issues requiring correction. The updated flight-control software uses both sensor inputs, compares them and disables the stabiliser trim system, including MCAS, for the remainder of the flight when their difference exceeds a calculated threshold.
Hypothetical institutional scenario
How might the same control pattern appear?
A safety- or customer-critical automated control can initiate a consequential action from one data feed. A second independent feed exists but is used only for display or diagnosis. The system's safety assessment assumes that an operator will recognise a bad input, interpret several concurrent alerts and reverse the action within a short time. Those recognition and response assumptions have not been tested under realistic workload and ambiguity.
Stress-test questions
Questions for challenge and assurance
-
Technology
Which high-consequence automated actions can be initiated by one data source, and what happens when that source disagrees with an independent input?
-
Risk committee
Are assumptions about human recognition and intervention tested under realistic alert load and time pressure, or accepted from design documentation?
-
Operations
Does a detected input disagreement produce a safe degraded state, or leave operators to diagnose and reverse an active control?
-
Board
Who has standing to reopen an approved design assumption after incidents, near misses or new operational evidence challenge it?
NFRisk practitioner interpretation
Control implication
Redundancy is not achieved merely by installing a second sensor or data source; it must participate in decision logic, disagreement handling and safe degradation. Design assurance should trace each high-consequence action to its input dependencies, test plausible common and single-source failures, and validate the time and information a human needs to intervene. The central governance question is who can reopen an accepted design assumption when operational evidence challenges it.
Framework relevance
Explicitly labelled analytical mappings
FAA safety issue: single AOA sensor dependency
The FAA identified erroneous data from one AOA sensor activating MCAS as a safety issue that had to be addressed, and documented the revised use of both sensor inputs and disagreement logic.
737 MAX Return to Service · Federal Aviation AdministrationNTSB safety-assessment lens: pilot recognition and response
The NTSB questioned whether accident-flight responses were consistent with the pilot recognition and response assumptions used in the original functional hazard assessment and recommended stronger validation of those assumptions.
Safety Recommendation Report ASR-19-01 · National Transportation Safety BoardEvidence register
Primary and supporting sources
-
Federal Aviation Administration
Summary of the FAA's Review of the Boeing 737 MAX (opens in a new tab) 18 November 2020 · Authoritative primary source -
National Transportation Safety Board
Assumptions Used in the Safety Assessment Process and the Effects of Multiple Alerts and Indications on Pilot Performance (opens in a new tab) 19 September 2019 · Authoritative primary source
Publication note
A documented external event—not an NFRisk client engagement.
The named organisations are included because authoritative sources document the event. Their inclusion does not imply that they are or were NFRisk clients, that they endorse this analysis, or that NFRisk participated in the event or response. Framework relevance and NFRisk practitioner interpretation are analytical layers applied after the event.
Return to the Risk Scenario LibraryFrom scenario to mandate
Test the equivalent control assumption in your environment.
NFRisk can use this scenario as a starting point for a focused structural diagnostic, risk-architecture review or delivery-assurance discussion.