Editorial: Tödliche Software

Jungfernflug der Boeing 737 MAX
Bild: Boeing Im Rahmen der Entwicklung des neuen Mobilfunkstandards 5G wird auch intensiv an autonom fahrenden Autos geforscht. 5G-Netze sollen dabei die Kommunikation zwischen den einzelnen Fahrzeugen übernehmen: So können sich autonome Autos beispielsweise gegenseitig vor Gefahrstellen warnen oder auf der Autobahn spritsparend und verkehrsleistungssteigernd im Windschatten hintereinander fahren. Aber am Ende kommt es weniger auf die Mobilfunknetze als auf die Software an: Deren Aufgabe ist es, die Sensordaten (Kamera, Radar, Lidar, Ultraschall etc.) auszuwerten, und dabei zuverlässig gefährliche Situationen (eine Fußgängerin geht über die Straße) von harmlosen Ereignissen (der Wind weht eine leere Plastiktüte, auf der ein Mensch abgebildet ist, über die Straße) zu unterscheiden. Das gelingt noch nicht immer zuverlässig, wie in zwei früheren Editorials (Blind durch die Nacht und Fußgängerin oder Radfahrerin oder Zwitter?) zu einem Unfall mit einem autonomen Fahrzeug von Uber bereits ausgeführt wurde. Dort war das Problem, dass eine Fußgängerin, die ein Fahrrad schob, weder als Fußgängerin noch als Radfahrerin erkannt wurde.

Jungfernflug der Boeing 737 MAX
Bild: Boeing In den geplanten autonom fahrenden Autos liegt es also an der Software, ob diese unfallfrei fahren werden oder nicht. Dasselbe gilt auch für Flugzeuge, bei denen die Software ebenfalls immer größere Teile der Flugsteuerung übernimmt. Entsprechend wird die Flugsoftware regelmäßig aktualisiert und immer weiter verbessert. Bei einer beim jüngsten Modell ergänzten Sicherheits-Software scheint der weltgrößte Flugzeughersteller Boeing jedoch geschlampt zu haben. Die Folge der fehlerhaften Sicherheits-Software war der Absturz einer fast nagelneuen Boeing 737 MAX 8 mit 189 Todesopfern. Dabei war das Unglücksflugzeug noch keine tausend Stunden in der Luft gewesen.

Im vorläufigen Untersuchungsbericht zu Flug JT-610 von Jakarta nach Pangkal Pinang (Indonesien) heißt es: "At 23:25:18 UTC, the flaps retracted to 0 and several seconds later, the automatic AND trim and flight crew commanded ANU trim recorded began again and continued for the remainder of the flight." AND ist eine Abkürzung für "aircraft nose down". Der Steuercomputer drückte also das Flugzeug nach unten, und die Crew versuchte mit ANU ("aircraft nose up") dagegenzuhalten. Das gelang ihr auch mehrere Minuten lang. Ab 23:31 Uhr scheint sich aber der Steuercomputer durchgesetzt zu haben: Im Diagramm auf Seite 14 des Berichts sieht man, wie die "Pitch Trim Position" immer mehr nach unten zeigt. In der Folge verliert das Flugzeug drastisch an Höhe, während es zugleich immer schneller wird. Um 23:31:54 enden die Aufzeichnungen.

Aus dem Unfallbericht ergibt sich ferner, dass in dem Unglücksflugzeug ein wichtiger Sensor ausgefallen war, und zwar der AoA-Sensor auf der Pilotenseite. Dieser misst, aus welchem Winkel der "Fahrtwind" auf das Flugzeug trifft. Der defekte AoA-Sensor meldete nun einen viel zu hohen Wert, so als ob der Fahrtwind statt (fast) direkt von vorne (wie es in einer normalen Flugposition der Fall ist) von schräg unten kam. Der AoA-Sensor auf der Kopilotenseite funktionierte hingegen normal und meldete den richtigen, niedrigeren Wert.

Falsche Sensordaten, falsche Reaktion

Boeing 737 MAX 8
Bild Boeing Normalerweise ist es natürlich richtig, das Flugzeug nach unten zu drücken, wenn die Nase tatsächlich so weit über dem Horizont steht, wie vom defekten AoA-Sensor gemessen. Beim Unglücksflug war aber der Messwert falsch, nicht die Fluglage, und folglich führte die automatisierte Reaktion des Flugcomputers direkt nach unten ins Verderben. Die Automatik, die hier so kläglich versagt hat, heißt bei Boeing MCAS (Maneuvering Characteristics Augmentation System) und ist erstmalig mit dem überarbeiten Kurzstreckenjet Boeing 737 MAX eingeführt worden. Ihr Ziel ist es eigentlich, Flugzeugabstürze zu verhindern, indem sie in die Steuerung eingreift, wenn gefährliche Flugzustände drohen oder gar erreicht werden. Bei Airbus gibt es ein vergleichbares System seit der Einführung des A320 vor 30 Jahren. Bei Boeing ist es hingegen neu.

Kurz nach dem Absturz veröffentlichte Boeing eine Direktive, mit der Airlines angehalten werden, im Training der Piloten ausdrücklich auf den Not-Aus-Knopf des MCAS hinzuweisen. Tatsächlich hatte die Crew, die den vorletzten Flug mit dem Unglücksflugzeug von Denpasar nach Jakarta durchgeführt hatte, direkt nach dem Start dieselben Probleme wie die Crew auf dem letzten Flug. Die vorletzte Crew hatte den Not-Aus-Knopf für das MCAS jedoch betätigt, und konnte den Flug dann ohne Probleme bis zum Ziel fortsetzen. Sie wies Techniker auf das Problem mit dem defekten Sensor hin, und die Techniker der Airline arbeiteten in der Nacht am defekten Sensor, konnten den Fehler aber anscheinend nicht beheben.

In der Fachwelt ist seitdem ein Streit darüber entbrannt, ob Boeing die Piloten ausreichend über das MCAS informiert hat. Boeing steht auf dem Standpunkt, dass das MCAS im Flugmanual der 737 MAX verzeichnet ist. Piloten müssen das Manual lesen, bevor sie die Typzulassung für ein Flugzeug erhalten. Andererseits sind die Boeing 737 (das meistgebaute Verkehrsflugzeug der Welt) und die 737 MAX (die neue Version der 737) ansonsten sehr ähnlich. Da kann es schon passieren, dass Piloten beim Lesen des Manuals der 737 MAX große Teile nur überfliegen, weil dieses so ähnlich zum bereits bekannten Manual der 737 (ohne MAX) ist. Vielen Piloten, die regelmäßig beide Typen fliegen, dürften die starken Eingreifmöglichkeiten des nur bei der 737 MAX installierten MCAS daher so nicht bewusst gewesen sein. Folglich haben Sie dann auch nicht registriert, wie wichtig der MCAS-Not-Aus-Knopf sein kann.

Die Software sollte sich nicht so leicht verwirren lassen

Der Streit über Boeings Informationspolitik zum MCAS lenkt aber meines Erachtens von einem viel gravierenderen Problem ab, nämlich der Fehlerhaftigkeit des MCAS selber. Ein Sicherheitssystem sollte nicht selber zum Sicherheitsrisiko werden, nur, weil es einen einzelnen, isolierten Defekt an einem einzelnen Bauteil des Flugzeugs gibt. Egal, ob wie hier einzelner Sensor ausfällt, oder ein Triebwerk, oder eine der beiden Hydrauliken, die Piloten sind bei einem Ausfall immer stark belastet. Gerade dann sollten sie sich nicht darum kümmern müssen, auch noch Amok-laufende Sicherheitssysteme abzuschalten. Das sollten letztere schon selber tun: Wenn keine vernünftigen AoA-Daten vorliegen, weil beide AoA-Sensoren so starke Abweichungen zeigen, wie beim Unglücksflug, dann dürfen diese AoA-Daten auch nicht weiterverarbeitet werden. Statt eines solchen, sicheren Designs, scheint Boeing hingegen nur die AoA-Daten des pilotenseitigen Sensors verarbeitet zu haben.

Der Fairness halber muss man dazu sagen, dass in der Vergangenheit bei Airbus die Abschaltung der Fluglagenkontrolle nach einem Sensordefekt zum Absturz geführt hatte: Flug AF-447 von Rio de Janeiro nach Paris stürzte in den Atlantik, weil zunächst Pitot-Sonden vereist waren und daher die Geschwindigkeit des Flugzeugs nicht mehr richtig messen konnten. Autopilot und Fluglagenkontrolle schalteten sich ab. Der um das Flugzeug herum tobende Sturm führte dann sofort zu einer Schieflage des Flugzeugs. Die beiden Kopiloten (der eigentliche Pilot war am Schlafen außerhalb des Cockpits) gerieten in Panik und versuchten mit manuellen, übertriebenen Steuermanövern das Flugzeug in der Luft zu halten. Insbesondere zog der "pilot flying" am Sidestick die ganze Zeit nach oben und erreichte dadurch einen überzogenen Flugzustand mit schräg von unten anströmender Luft. In diesem verliert das Flugzeug sehr schnell an Höhe, trotz laufender Triebwerke. Eine automatische Trimmung AND (aircraft nose down) hätte beim Flug AF-447 vermutlich den Absturz verhindern können.

Die Automatik bei unklaren Sensordaten einfach abzuschalten, ist also auch nicht automatisch die beste Lösung. Die Automatik so zu programmieren, dass die Piloten sie manuell abschalten müssen, weil sie fehlerhafte Eingriffe durchführt, ist aber auf jeden Fall noch schlimmer. Am besten wäre es, wenn die Automatik bei widersprüchlichen Sensordaten selbständig ermittelt, welcher Sensor wahrscheinlich defekt ist, und dann genau dessen Daten ignoriert. Wenn, wie hier der Fall, der pilotenseitige AOA-Sensor eine gefährliche Fluglage anzeigt, alle anderen pilotenseitigen Sensoren (insbesondere Geschwindigkeit und Höhe) hingegen auf eine normale Fluglage deuten, und auch die kopilotenseitigen Sensoren konsistent eine normale Fluglage anzeigen, dann sollte der fehlerhafte Sensor eigentlich recht leicht zu ermitteln sein. Dieser wird dann isoliert, und das Flugzeug bleibt sicher in der Luft. Zugleich sollte eine Fehleranzeige aktiviert werden, die aufgrund der inkonsistenten Sensordaten den Piloten eine baldige Sicherheitslandung nahelegt.