Technologie Tod durch Software – Kein Patch kann fatale Fehler wieder richten

Zwei Abstürze in nur fünf Monaten, 346 Tote – das ist die tragische Bilanz, die derzeit dafür sorgt, dass mit der Boeing 737 MAX eines der modernsten Flugzeuge weltweit nicht starten darf. Eine Software zur Verbesserung der Flugsteuerung soll Schuld tragen. Wie kann so etwas heute noch passieren?

Am 10. März erschütterten die Nachrichten um den Absturz einer Boeing 737 MAX 8 der Ethiopian Airlines die Welt. Es war der zweite Vorfall dieser Art innerhalb von fünf Monaten: Erst im Oktober 2018 war in Indonesien mit dem Flug Lion Air 610 eine weitere MAX 8 verunglückt. Beide Abstürze forderten zusammen 346 Todesopfer. Die Flugzeuge der 737-MAX-Linie sollten eigentlich nach und nach den Avionik-Klassiker Boeing 737 ablösen. Stattdessen haben, während ich diese Zeilen schreibe, weltweit alle Flugzeuge der erst seit 2016 bestehenden, eigentlich hochmodernen Serie Startverbot.

Ein Versagen der Software war wohl ursächlich

Beide Unglücksmaschinen waren nach dem Start mit unregelmäßiger Flugkurve und -geschwindigkeit aufgestiegen, sanken anschließend unkontrolliert ab und schlugen steil auf dem Boden auf. Nach den konkreten Ursachen wird zwar noch gesucht, aber ein gemeinsamer Nenner konnte für beide Abstürze ausgemacht werden: Beide Male scheint die Steuerungssoftware MCAS (maneuvering characteristics augmentation system), ein „System zur Verbesserung der Flugeigenschaften“, ein zentraler Aspekt für die Abstürze gewesen zu sein. Diese Software existiert derzeit exklusiv für die Flugzeuge der MAX-Reihen von Boeing – ein Umstand, der offenbar nicht einmal den Piloten dieser Maschinen bewusst ist.

Im Falle des jüngsten Unglücks hatte das Flugzeug einen defekten Lagesensor. Der Fehler wurde vom MACS aber nicht erkannt. In der Folge ermittelte das System falsche Steuerungsdaten. Wie die New York Times meldet existieren Hinweise darauf, dass das „Flugeigenschaftsverbesserungssystem“ eine als Hubspindel (engl. jackscrew) bekannte Vorrichtung ausgelöst hat, die den Winkel der Seitenleitwerke steuert, um den Flugkurs auf Basis dieser Daten zu korrigieren. Die Nase des Flugzeugs senkte sich daraufhin plötzlich ab. Die Piloten waren nicht in der Lage, die fehlerhaften Steuerbefehle auszugleichen – mit fatalen Konsequenzen.

War der sicherheitskritische Aspekt der Software nur ein Nachgedanke?

Dieser tragische Vorfall demonstriert, wie dramatisch sich das Versagen von Software Engineering auswirken kann. Denn in diesem Fall hat es auf ganzer Linie versagt: Piloten waren den Umgang mit der Software nicht gewohnt. Die Dokumentation war unzureichend, bestimmte Korrekturmaßnahmen des MCAS werden offenbar im Handbuch nicht erwähnt. Das Qualitätsmanagement konnte trotz aller erfolgten Safety-Zertifizierungen kritische Fehler nicht verhindern. Aber wo genau ist der Fehler geschehen?

War die eilige Time-to-Market der Maschine ein Faktor? Die EE Times mutmaßt, dass Boeing im Wettrennen mit Airbus unbedingt die Nase vorn haben wollte, und deswegen die 737-MAX-Reihe so schnell wie möglich auf dem Markt platzieren wollte. Die Modernität des Flugzeugs gilt auch als Verkaufsargument: Mehr als drei Viertel aller aktuellen Bestellungen in den Auftragsbüchern von Boeing betreffen die MAX-Familie, rund 100 Airlines sollen mehr als 5000 Maschinen dieses Typs bestellt haben.

Um das Flugzeug so schnell wie möglich auf den Markt bringen zu können, mussten auch Kosten gespart werden - und offenbar wurde in diesem Zusammenhang auch darauf verzichtet, auf mögliche Änderungen der Flugeigenschaften hinzuweisen. Dementsprechend wurden Piloten, die das Handling einer regulären 737-Maschine gewohnt waren, nicht extra neu geschult. Was auch dazu führt, dass vielen die Existenz dieses Systems nicht einmal bekannt ist.

Je mehr Details über das Unglück ans Licht kommen, um so mehr erhärtet sich der Verdacht, dass die Integration der Steuerungssoftware wohl erst im Nachgang erfolgt ist! Die Integration des MCAS sollte nicht nur Piloten beim Flug unterstützen, es wurde wohl extra in die 737-MAX-Familie integriert, um ein Problem mit der Positionierung der Triebwerke zu lösen – die Software sollte das schon richten. Das bestehende Flugsteuerungssystem wurde demnach um neue Codezeile in MCAS erweitert, um den destabilisierenden Pitchkräften der neuen Triebwerke entgegenzuwirken. Das System sollte die Piloten aktiv beim Flug unterstützen – im Fall des Fluges der Ethopia Airlines 302 sieht es aber so aus, als hätte es statt dessen aktiv gegen die Bemühungen der Piloten gearbeitet.

Safety by Design wird seit Jahren gepredigt – aber wie etabliert ist es wirklich?

Systemsicherheit, und vor allem funktionale Sicherheit, sollte nie etwas sein, um das man sich erst nachträglich kümmert! Schon seit Jahren predigen Embedded-Experten, Themen wie Safety oder Security von Beginn an in den Design-Prozess einzubeziehen. Wie so oft scheint das Problem bei der Einhaltung von Safety-Vorgaben an Problemen im Prozess- und Qualitätsmanagement zu liegen. Dass dies offenbar gerade in der Avionik, einem der am Schärfsten auf Einhaltung von Safety-Ansprüchen bestehenden Industriezweige, geschehen ist, ist erschütternd.

Vorfälle wie dieser machen auf schmerzhafte Art und Weise klar, dass das Thema Sicherheit in der Softwareentwicklung heute noch immer viel zu häufig auf die leichte Schulter genommen wird. Wir dürfen uns nicht blind auf Safety-Richtlinien verlassen – oder darauf, dass Softwarebedienung selbsterklärend ist. Anforderungen müssen klar definiert sein. Testfälle müssen die gesamte Codebasis abdecken können. Größte Sorgfalt muss beim Entwickeln von Software geboten sein.

Boeing hat so schnell wie möglich ein Software-Update für sein MCAS versprochen. Aber wie viel ist das jetzt noch Nutze? Das Vertrauen in das System ist bereits dahin, die Opfer sind nicht mehr aus der Welt zu schaffen. Qualität, das ist etwas, dass man nicht einfach schnell im Nachhinein ausbessert. Denn manche Fehler lassen sich hinterher – auch durch den besten Patch der Welt – nicht wieder gut machen.

Dieser Beitrag ist ursprünglich auf unserem Partnerportal Elektronikpraxis erschienen.

(ID:45812005)