6 lessons for Systems Engineers from the Boeing 737 MAX disaster

In May 2017, Boeing delivered the first 737 MAX aircraft, a plane that represents one of the company's biggest disasters. In October 2018, the first plane of this model crashed, followed by a second in March 2019, resulting in a total of 346 fatalities. The blame was placed on the MCAS software.

This has often been described in the press as a "software problem". But as is so often the case, the truth is somewhat more complex. And for systems engineering in particular, a closer analysis shows that the software was not the problem at all.

A major innovation in the 737 MAX was the Maneuvering Characteristics Augmentation System (MCAS), software that intervenes in the control of the aircraft. Despite major design changes that affect flight behavior, the aircraft is supposed to behave like a classic 737. In particular, this should save training costs for the pilots.

No other commercial aircraft has ever been equipped with a system like MCAS, only in the defense sector (Boeing KC-46 Pegasus).

Four factors lead to disaster

An excellent and readable summary was written by Phillip Johnston and Rozi Rarris: The Boeing 737 MAX Saga: Lessons for Software Organizations (PDF). There, the authors describe the following four factors that ultimately led to this disaster. It is important to note that these factors would also lead to serious problems in a different environment:

• Poor documentation - Many pilots complained about the quality of the documentation after the first crash.

The flight manual is inadequate and almost criminally insufficient

Pilot submission, ASRS-Report ACN 1593017

• Hasty release - The 737 MAX was driven by the Airbus A20neo, which had a nine-month head start. The pressure on employees was enormous, and the FAA was not even informed of many short-term decisions.
• Delay in software updates - Boeing had already submitted a software fix to the FAA 7 weeks before the second crash.
• Humans are not part of the system - The behavior of MCAS was not really recognizable for the pilots, an intervention in the trimming by MCAS was not communicated to the pilots.

According to Boeing, the MCAS is (counterintuitively) only active in manual flight mode and is disabled under autopilot.

The Boeing 737 MAX Saga

Is software the problem?

Even though the MCAS software has often been criticized, the software itself is only indirectly to blame for the crashes. Specifically, the following problems occurred:

• Sensors are not always reliable: Only the values of one sensor were used for the accident flights (two sensors would have been calibrated for an additional charge).
• Incorrect maintenance: Problems had already been identified before both accident flights, but were not recorded in the maintenance logbook.
• Training: The pilots of the first accident flight were not even informed of the existence of MCAS, at the time of the second crash the problem was known, but no training had yet taken place.
• Economic problems: There were options to make the system more reliable - but only for an extra charge.

None of the causes of the accident was faulty software. The software worked correctly.

Lessons for the future

One of the most important lessons to be learned from this accident is to put safety first. This also makes economic sense, as the current state of Boeing clearly shows. For this we need a corresponding culture. This in turn means that we can Menschen must take center stage.

1.Safety as part of the culture in the first place

In addition, there are a few gaps, especially for us systems engineers:

2.Complex systems cannot simply be adapted

Self-organizing, non-linear feedback systems are inherently unpredictable and difficult to control. With the exception of trivial changes, we cannot turn a screw and expect nothing else to change. And certainly not that things will get better.

I worked for a software company in the late 90s where an error in the documentation (including code documentation) was classified as a top priority bug. The result was impressive. This is all the more important for safety-critical developments. In the case of the 737 MAX in particular, proper documentation may have prevented a crash in the event of a crisis.

4.People must remain part of the system

As mentioned above, some of the pilots did not even know that MCAS existed and were not seen as part of the system. But humans have creativity and are able to deal with situations where autonomous systems are overwhelmed. There was no reason to do this here.

5.Testing is not enough

For testing to be sufficient to prove safety, you would have to test at least according to the failure rate (i.e. at least 10⁸ tests), realistically even ten times as much. That is simply not possible. This is another reason why we need a safety culture - point 1.

6.It can happen to anyone

It's easy to read about disasters and think: it couldn't happen to me - or my Fimra. But we must remember that the disaster is not the consequence of one diabolical manager's decision. Boeing made many small incremental decisions that together led to this disaster. Unfortunately, such decisions are also made in many other companies. Therefore, each individual has a duty to set higher standards every day. And we Systems Engineers must lead by example.

Image From Oleg V. Belyakov, CC BY-SA 3.0, Link