Boeing 737 MAX MCAS: Software Authority, Sensor Dependence, and Two Fatal Crashes
The 737 MAX accidents showed how MCAS authority, dependence on a single angle-of-attack input, pilot-response assumptions, alert design, and certification processes could combine into catastrophic system risk.
MCAS was introduced to modify handling characteristics in a specific flight regime
The Boeing 737 MAX incorporated the Maneuvering Characteristics Augmentation System, or MCAS, into its flight-control architecture. MCAS could command stabilizer trim under certain high angle-of-attack conditions to help the aircraft meet handling-quality requirements. The system became central to investigations after Lion Air Flight 610 crashed in October 2018 and Ethiopian Airlines Flight 302 crashed in March 2019, killing 346 people in total. NTSB later focused on how system-safety assessments had modeled MCAS failures and assumed pilots would respond.[1]
A control augmentation function acquired significant operational authority
When software can move a stabilizer, the safety case must account not only for intended activation but for erroneous repeated activation and the pilot’s ability to recognize what is happening.
Original MCAS behavior depended heavily on one angle-of-attack input
Investigations found that erroneous angle-of-attack data could activate MCAS even though the aircraft had more than one AOA sensor. The Joint Authorities Technical Review examined the flight-control design and certification process and identified concerns around system integration, assumptions, and the way changes to MCAS were assessed during development.[2] The architectural issue was not simply that a sensor can fail; sensors always can. The question was whether one bad input could command repeated nose-down trim without adequate independent validation.
Redundant sensors do not help if the control law trusts only one of them
Hardware redundancy must be connected to decision logic. Otherwise the system carries duplicate information without using it to challenge a dangerous command.
Lion Air 610 exposed a chain involving sensor data, maintenance, alerts, and MCAS
Indonesia’s KNKT investigation found a complex sequence involving an incorrectly calibrated replacement angle-of-attack sensor, maintenance and troubleshooting issues, cockpit indications, and repeated MCAS commands.[3] The report did not assign the accident to one line of software or one crew action. It showed how design, maintenance, documentation, and human response interacted. That systems perspective is essential because removing any one contributor could have changed the outcome.
Ethiopian 302 showed that awareness of runaway-trim procedures did not eliminate the hazard
The Ethiopian investigation documented repeated nose-down trim commands and the crew’s attempts to counter them.[4] The accident occurred after the Lion Air crash had already focused global attention on MCAS. That made clear that procedural knowledge alone was not an adequate substitute for redesigning the hazardous control path.
Training is weaker than eliminating an unsafe trigger
When a failure can generate high workload, confusing alerts, and rapidly changing forces, engineering should reduce the failure’s authority before relying on perfect human recovery.
Certification assumptions about pilot reaction became a central issue
NTSB concluded that assumptions used in safety assessments about immediate and appropriate pilot responses did not adequately reflect the multiple alerts and indications crews faced in the real accidents.[1] The recommendation was broader than the MAX: certification methods should validate human-response assumptions under realistic failure presentations. Human beings are part of the control loop, and their performance cannot be represented as a fixed zero-delay recovery function.
System changes addressed sensor comparison, command limits, alerts, and training
Before the MAX returned to service, FAA required new flight-control computer software, updated display software for AOA disagreement, revised procedures, sensor-system tests, and additional training requirements.[5] MCAS behavior was changed so the system compared AOA inputs and had tighter limits on command authority. These changes attacked the architecture rather than only adding warnings.
The redesign added defense in depth
No single improvement carries the entire safety case. Sensor disagreement detection, command limits, cockpit information, procedures, and training work together to prevent recurrence.
The accidents changed oversight of certification and delegated engineering work
The MAX investigations prompted scrutiny of how design changes were communicated, assessed, and delegated between Boeing and regulators. JATR recommended stronger integrated system review and attention to how functions evolve during development.[2] Large systems are dangerous when individual changes appear locally small but alter authority, dependencies, or failure severity at the aircraft level.
The case also changed how engineers discuss “pilot in the loop” assumptions. A human recovery action is not an independent backup if the same failure that needs recovery also changes forces, alarms, displays, and available time. Treating human intervention as a safety barrier requires testing it under the full workload created by the failure, not under a simplified simulator scenario where the diagnosis is obvious.
Why the 737 MAX belongs in software-failure history
The 737 MAX accidents matter to software engineering because they show that catastrophic failure rarely belongs to “the software” in isolation. MCAS code, sensor architecture, safety assessment, alerting, documentation, maintenance, training, and certification formed one socio-technical system.[1][3]
The strongest lesson is to challenge hidden assumptions at system boundaries. If software authority depends on a sensor, ask how that sensor fails. If safety depends on pilot intervention, test the actual alert environment and available time. If redundant hardware exists, verify the algorithm uses it. If a function’s authority changes during development, revisit the hazard classification rather than inheriting an old one. The MAX history is difficult precisely because no single correction tells the whole story; safety had to be rebuilt across several layers at once.
Works Cited
- 01
- 02
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.