6 Lehren aus dem Boeing 737 MAX Desaster für Systems Engineers

Im Mai 2017 lieferte Boeing die ersten Maschinen vom Typ 737 MAX aus, ein Flugzeug, dass einen der größten Desaster der Firma repräsentiert. Denn schon im Oktober 2018 kam es zum ersten Absturz einer Maschine dieses Modells, im März 2019 zu einem zweiten, wobei es zu insgesamt 346 Todesfällen kam.

In der Presse wurde dies oft als „Softwareproblem“ bezeichnet. Doch wie so oft ist die Wahrheit etwas komplexer. Und insbesondere für das Systems Engineering zeigt eine genauere Analyse, dass die Software gar nicht das Problem war.

Eine große Neuheit bei der 737 JAX war das Maneauvering Characteristics Augmentation System (MCAS), eine Software, die in die Steuerung des Flugzeugs eingreift. Trotz größerer Designänderungen, die das Flugverhalten beeinflussen, soll sich dadurch das Flugzeug wie eine klassische 737 verhalten. Dadurch sollten insbesondere Trainingskosten für die Piloten eingespart werden.

Kein anderes kommerzielle Flugzeug war bisher mit einem System wie MCAS ausgestattet, es gab dies lediglich im Defense-Bereich (Boeing KC-46 Pegasus).

Vier Faktoren führen zum Desaster

Eine hervorragende und gut lesbare Zusammenfassung wurde von Phillip Johnston und Rozi Rarris geschrieben: The Boeing 737 MAX Saga: Lessons for Software Organizations (PDF). Dort beschreiben die Autoren die folgenden vier Faktoren, die letzten Endes zu diesem Desaster geführt haben. Wichtig hierbei: Diese Faktoren würden auch in einem anderen Umfeld zu schweren Problemen führen:

• Schlechte Dokumentation – Viele Piloten beschwerten sich nach dem ersten Crash über die Qualität der Dokumentation.

The flight manual is inadequate and almost criminally insufficient

Pilot submission, ASRS-Report ACN 1593017

• Übereilte Freigabe – Der Treiber der 737 MAX war der Airbus A20neo, der neun Monate Vorsprung hatte. Der Druck auf die Mitarbeiter war enorm, die FAA wurde über viele kurzfristige Entscheidungen gar nicht informiert.
• Verzögerung bei Software Updates – Bereits 7 Wochen vor dem zweiten Crash hatte Boeing einen Software Fix bei der FAA eingereicht.
• Menschen sind nicht Teil des Systems – Das Verhalten von MCAS war für die Piloten nicht wirklich erkennbar, ein Eingriff in das Trimmen durch MCAS wurde nicht an die Piloten kommuniziert.

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

The Boeing 737 MAX Saga

Ist Software das Problem?

Auch wenn die Software MCAS oft kritisiert wurde, so hat die Software selbst jedoch nur indirekt Schuld an den Abstürzen. Konkret traten die folgenden Probleme auf:

• Sensoren sind nicht immer Zuverlässig: Bei den Unglücksflügen wurden nur die Werte eines Sensors benutzt (für einen Aufpreis wären zwei Sensoren abgeglichen worden).
• Inkorrekte Wartung: Schon vor beiden Unglücksflügen wurden bereits Probleme festgestellt, aber nicht im Wartungslogbuch festgehalten.
• Schulung: Den Piloten des ersten Unglücksflugs wurde noch nicht einmal die Existenz von MCAS mitgeteilt, zum Zeitpunkt des zweiten Absturzes war das Problem zwar bekannt, aber es hatte noch kein Training stattgefunden.
• Wirtschaftliche Probleme: Es gab Optionen, das System zuverlässiger zu machen – aber nur gegen Aufpreis.

Keine der Unglücksursachen war fehlerhafte Software. Die Software hat korrekt funktioniert.

Lehren für die Zukunft

Eine der wichtigsten Lehren aus diesem Unglück ist es, Sicherheit an erste Stelle zu stellen. Das ist auch wirtschaftlich sinnvoll, wie man am aktuellen Zustand von Boeing deutlich sehen kann. Dazu brauchen wir eine entsprechende Kultur. Das wiederum bedeutet, dass wir den Menschen in den Mittelpunkt stellen müssen.

Darüber hinaus gibt es ein paar Leeren besonders für uns Systems Engineers:

Selbst-organisierende, nicht-lineare Feedbacksysteme sind inhärent unvorhersagbar und schwer zu steuern. Bis auf triviale Änderungen können wir nicht an einer Schraube drehen und erwarten, dass sich sonst nichts ändert. Und erst recht nicht, dass es besser wird.

Ich habe Ende der 90er für eine Softwarefirma gearbeitet, bei der ein Fehler in der Dokumentation (auch Codedokumentation) als Bug höchster Priorität eingestuft wurde. Das Ergebnis war beeindruckend. Für sicherheitskritische Entwicklungen zählt das umso mehr. Insbesondere bei der 737 MAX hatte vernünftige Dokumentation im Krisenfall möglicherweise den Crash verhindert.

Wie schon oben geschrieben, wussten die Piloten teilweise gar nicht, dass MCAS existierte und wurden nicht als Teil des Systems gesehen. Doch Menschen haben Kreativität und sind in der Lage mit Situationen umzugehen, bei denen autonome Systeme überfordert sind. Es gab hier gar keinen Grund, dies zu tun.

Damit Testen zum Nachweis der Sicherheit ausreicht, müsste man mindestens der Versagensrate entsprechend testen (also mindestens 10⁸ Tests), realistisch gesehen sogar das zehnfache. Das ist einfach nciht möglich. Auch deswegen brauchen wir – Punkt 1. – eine Sicherheitskultur.

Es ist leicht über Desaster zu lesen und zu denken: Mir – oder meiner Fimra – könnte das nicht passieren. Doch wir dürfen nicht vergessen, dass das Unglück nicht die Konsequenz der Entscheidung von einem teuflischen Manager ist. Boeing hat viele kleine inkrementelle Entscheidungen getroffen, die zusammen zu diesem Desaster geführt haben. Solche Entscheidungen werden leider auch in vielen anderen Firmen getroffen. Daher hat jeder einzelne die Pflicht, sich täglich höhere Standards zu setzen. Und wir Systems Engineers müssen hier als Vorbild dienen.

Bild Von Oleg V. Belyakov, CC BY-SA 3.0, Link