Boeing-Crash: „Haben Sie Ihre Zustände nicht im Griff, fliegt Ihnen das System um die Ohren“

| Autor: Sebastian Gerstl

Ethiopian Airlines Flug 302: Am 10. März stürzte die Maschine der Boeing 737 MAX Reihe ab. Schnell wurde das Flugaugmentationssystem MCAS als möglicher Schuldiger ausgemacht. Aber wo liegt das ursächliche Problem?
Ethiopian Airlines Flug 302: Am 10. März stürzte die Maschine der Boeing 737 MAX Reihe ab. Schnell wurde das Flugaugmentationssystem MCAS als möglicher Schuldiger ausgemacht. Aber wo liegt das ursächliche Problem? (Bild: Ethiopian Airlines ET-AVJ takeoff from TLV / FlickreviewR 2 / CC BY-SA 2.0)

Firmen zum Thema

Zwei Abstürze in nur fünf Monaten – welche Lehren lassen sich aus den verunglückten Boeing 737 MAX ziehen? Ein Interview mit Henning Butz, Systemtechniker und Experte für Systems-Engineering in der Avionik.

Seit dem Absturz einer Boeing 737-MAX-8-Maschine am 10. März steht der Flugzeugbauer Boeing unter massivem Druck. Innerhalb von gerade einmal fünf Monaten war es das zweite Flugunglück einer Maschine diesen Typs – beide Male mit fatalen Folgen.

Die Untersuchungen konzentrieren sich in beiden Fällen auf die Technik des modernen Fliegers – speziell auf das Flugverhalten-Augmentationssystem MCAS. Seit nun beinahe zwei Wochen bestehen für Flugzeuge der 737-MAX-Reihe weltweit Startverbote.

Boeing arbeitet derzeit an einem Sicherheitsupdate für das MCAS. Denn ehe das System nicht erneut für sicher erklärt und zugelassen wird, bleiben die Maschinen „on ground“. Flüge fallen bei zahlreichen Airlines aus. Jeder Tag, an dem die Flugzeuge auf dem Boden bleiben, kostet Boeing Summen in Millionenhöhe. Mit Garuda Indonesia hatte Ende März bereits die erste Airline einen milliardenschweren Großauftrag storniert und auf 49 bereits bestellte 737-MAX-8-Maschinen verzichtet – so schwer wiegt der Vertrauensverlust bereits.

Doch nicht nur Flugzeughersteller Boeing, sondern auch die amerikanische Flugzulassungsbehörde FAA sieht sich starken Vorwürfen ausgesetzt. In den USA prüft derzeit der Generalinspekteur des Verkehrsministeriums, ob die Maschinen mit der umstrittenen Steuerungssoftware MCAS überhaupt hätten zertifiziert werden dürfen. Auch das FBI hat sich einigen Berichten zufolge bereits in die Untersuchungen eingeschaltet, ob bei der Zulassung der Fliegerfamilie alles mit rechten Dingen zugegangen ist.

Ehe ein endgültiger Unfallbericht über die Abstürze vorliegt, kann man über die Ursachen hinter der Katastrophe nur Mutmaßungen anstellen. Klar scheint nur, dass ein Versagen vorliegt. Aber wie konnte es soweit kommen? Wie sehen die Prüfinstanzen aus? Und gibt es in der Luftfahrt schon vergleichbare Vorfälle?

Henning Butz war 25 Jahre in diversen Funktionen und Leitungsebenen im Systems Engineering bei Airbus in Hamburg und Bremen beschäftigt. Neben seinen Aufgaben in internationalen Luftfahrtvorhaben berät er auch luftfahrtfremde Branchen: Auto-, Bahn-, Prozessindustrie, Verteidigung sowie CAE-Software und Logistik bei der Einführung, Geschäftsentwicklung und Realisierung neuer Systemtechnologien, einschließlich der erforderlichen Methoden, Werkzeuge und Prozesse. Gegenwärtig arbeitet er in internationalen Projekten zum Thema „Schritte zu höheren Automationsstufen in der Flugführung“.

Wir haben den erfahrenen Systemtechniker um eine Einschätzung der Lage gebeten – und darüber gesprochen, welche Lehren Unternehmen auch aus anderen Industriebereichen aus dem Unglück ziehen sollten.

ELEKTRONIKPRAXIS: Herr Butz, wie sieht der Zulassungsprozess bei so einem Avionik-System aus?

Henning Butz: Wenn ein neues System installiert wird, mit dem zahlreiche Veränderungen verbunden sind, dann wird mit der Behörde ein entsprechender Zulassungsplan abgestimmt, und es werden Means of Compliance festgelegt, sozusagen Nachweis-Mittel und Nachweis-Vorschriften, die vom Hersteller genau einzuhalten sind. Das wird alles in einem Sicherheits- und Zertifikationsplan mit der Luftfahrtbehörde abgestimmt. Dort steht konkret drin, welche Means of Compliance erfüllt, welche Nachweise erbracht werden müssen, Testvorgaben, analytische Berechnungen und vieles mehr.

Henning Butz: Der erfahrene Systemtechniker arbeitet international als selbständiger Berater und Interim-Manager im Engineering und Projektmanagement komplexer, sicherheitskritischer Systeme.
Henning Butz: Der erfahrene Systemtechniker arbeitet international als selbständiger Berater und Interim-Manager im Engineering und Projektmanagement komplexer, sicherheitskritischer Systeme. (Bild: Advanced Systems Engineering Solutions - ASES)

Von diesem Prozess kann man auch nicht abkommen, weil mindestens ein Vier-Augen-Prinzip gilt. Selbst wenn also bei dieser MCAS-Zertifizierung jemand gemogelt haben sollte, hätte das in mindestens zwei Instanzen geschehen müssen. Mir würde kein Fall einfallen, bei dem so etwas schon vorgekommen wäre.

Das unterscheidet übrigens die Luftfahrt vom Automobilbau, der da mehr im eigenen Saft schwimmt und solche Pläne und Nachweise nicht im Vorfeld mit dem Kraftfahrtbundesamt abstimmt – jedenfalls nicht in der Breite und Tiefe, wie im Flugzeugbau.

Die Zeitung Seattle Times hat den Vorwurf ins Spiel gebracht, dass Teile der Sicherheitsüberprüfung von der FAA an Boeing zurückgegeben worden wären.

Grundsätzlich ist das legitim. Jedes Flugzeugwerk, das für die Erstellung von Flugzeugsystemen zugelassen ist – auch Zulieferbetriebe – hat eine entsprechende Musterprüfleitstelle, im Englischen auch airworthiness board. Die dort arbeitenden Leute sind autorisiert, die Ergebnisse des Flugzeugbauers zu begutachten. Und sie sind vollkommen unabhängig. Kein Geschäftsführer käme auf den Gedanken, die Prüfer zu zwingen, etwa ein Design freizugeben, das sie im Sinne der Sicherheit nicht befürworten, ganz egal welcher Kosten- oder Zeitdruck herrscht.

Diese Sicherheitsingenieure müssen auch völlig unabhängig sein. Wenn sie ihren Job vernünftig machen, kann ihnen von Unternehmensseite her keiner reingrätschen. Das ist ein entscheidender Unterschied zwischen der Luftfahrtindustrie und anderen Branchen. Die Sicherheitsingenieure können im Streitfall direkt zur Flugaufsichtsbehörde gehen. Und die macht im Extremfall den Laden dicht.

Hat es denn in der Luftfahrt schon einen vergleichbaren Vorfall gegeben, bei dem eine so sicherheitskritische Technik offenbar versagt hat?

Vorfälle, also Incidents, hat es durchaus gegeben. Dabei ist zwar kein Flugzeug abgestürzt, aber es gab doch Analog-Beispiele, die quasi identisch abgelaufen sind, auch bei Airbus. Es gab 1991 einen Vorfall mit einer A310 der Luftfahrtgesellschaft der DDR, Interflug. Die wollte in Moskau landen und musste beim Landeversuch durchstarten. Was die Piloten allerdings nicht wussten: In diesem Maschinen-Typ war eine spezielle Steuerung für den Autopiloten installiert, die für die Mikrowellen-Landesysteme der Engländer geeignet war. Die gab es so aber in Moskau nicht. Soweit ich mich erinnere, schaltete der Autopilot sich mit dieser Vorrichtung ab einer bestimmten Flughöhe auf die Trimmung der Höhenflosse ein und ab einer anderen bestimmten Höhe automatisch wieder aus.

Weil der Pilot durchstarten musste, hat er ins Steuerhorn gegriffen und die Maschine in der Annahme hochgezogen, dass der Autopilot – wie er es gewohnt war – sich bereits abgeschaltet hätte. Aber der Autopilot hat sich in einer bestimmten Höhe wieder eingeschaltet, und damit die Rudereingaben des Piloten über die Trimmung des Höhenleitwerks deutlich verstärkt. Die Maschine erreichte dadurch einen Anstellwinkel von über 80° und verlor schnell an Geschwindigkeit. Bei nur noch 40 Knoten kippte das Flugzeug seitlich nach hinten und stürzte mit einem Winkel von 70° in Richtung Boden. Es gelang dem Piloten zwar, das Flugzeug wieder abzufangen. Aber als es wieder auf der entsprechenden Höhe war, griff der Autopilot erneut ein, und zog das Flugzeug im 70°-Winkel in die Höhe. Das ist drei oder viermal passiert, ehe es dem Piloten gelang, das Problem in den Griff zu bekommen.

Da haben sich quasi System und Pilot gegenseitig aktiv bekämpft.

Genau, das war sozusagen ein „Force Fighting“ gegeneinander. Der Grund war, dass zwei Systeme unter bestimmten Randbedingungen nicht hundertprozentig abgestimmt waren. Das wird wahrscheinlich im Fall Boeing ähnlich sein. Offenbar sind hier (beim Unglück der Ethiopian Airlines Maschine, Anm. d. Red.) zwei Fehler verantwortlich: ein Software(funktions)fehler und ein Sensorfehler.

Aber ich gehe davon aus, dass Design- und Testfehler gemacht wurden und das System nicht vollständig unter allen Betriebsbedingungen – vor allem Fehlerkonditionen – validiert wurde. So etwas geschieht insbesondere dann, wenn mehrere Funktionen gekoppelt werden, die früher nichts miteinander zu tun hatten.

Die Triebwerke der 737 MAX sind größer als beim Vorgänger 737. Daher sind diese weiter vorne montiert. Dadurch wandert der Schubschwerpunkt nach vorne. Das führt dazu, dass beim Beschleunigen die Nase überproportional nach oben gedrückt wird. Das Augmentationssystem MCAS soll die Überschreitung bestimmter Anstellwinkel verhindern und arbeitet entsprechend gegen diese Nasenanhebung. Seine Funktion setzt korrekte Sensordaten voraus. Stimmen diese nicht, kann es zu Überreaktionen kommen.

Das MCAS soll laut Boeing auch dazu dienen, dass Piloten, die das Flugverhalten der alten 737 kennen, die 737 MAX wie gewohnt fliegen können, ohne dass eine neue Schulung notwendig wäre.

Das ist der Punkt. Ohne das MCAS hätte die Maschine selbst mit wenig Schub ihre Nase bereits überproportional aufgestellt. Das MCAS hat dagegen gehalten, sodass sich das ausgeglichene Flugverhalten der alten 737 synthetisch eingestellt hat. Offensichtlich hat dies in bestimmten Flugphasen oder Situationen – etwa aufgrund fehlerhafter Sensorsignale – zu größeren Ausschlägen oder höheren Empfindlichkeiten geführt als geplant. Die Piloten waren vermutlich völlig überrascht von diesem Verhalten und haben in der kurzen verfügbaren Zeit keine Antwort gefunden. Vielleicht hatten sie auch keine Idee, wie sie reagieren sollten.

Kann das an der mangelnden Testfall-Güte liegen? Dass man bestimmte Testszenarien im Vorfeld nicht abgedeckt beziehungsweise nicht aufgegriffen hat?

Zumindest von außen sieht das so aus.

Es gab Vorwürfe, dass manche Piloten gar nicht richtig gewusst hätten, was MCAS überhaupt tut. Sie beschwerten sich auch darüber, dass das System schlecht dokumentiert sei. So sei beispielsweise nicht klar, ab welchem Winkel es aktiv beginnt einzugreifen.

Offensichtlich wurde die Funktion nicht richtig verstanden, oder sie wurde nicht richtig kommuniziert. Es kann auch gut sein, dass die Entwickler diese Funktion mit der heißen Nadel gestrickt haben, weil Boeing erst nach „design freeze“ der Flugsteuerung, die außerdem mutmaßlich viel alte Software enthält, festgestellt hat, dass das Flugzeug überproportional auf den Schubvektor reagiert. Womöglich haben sie nachträglich die MCAS-Funktion integriert, nachdem das Design bereits fertig war, um das Flugzeug handhabbar zu machen.

Dann können solche Sachen passieren. Etwa, weil die Beteiligten den Umfang der Systemkopplungen nicht mehr überblicken, oder weil beispielsweise bei Sensorfehlern unerwünschte Wechselwirkungen mit anderen Systemen entstehen, die vorher nicht vorhanden waren. Ich denke, das ist ein typisches System- oder Funktions-Interoperabilitäts-Problem. Das nennt man dysfunktionales Verhalten: Einzelne Funktionen nehmen Zustände an, die nicht zum Betriebszustand und zu den Zuständen anderer Systeme passen.

Was hier vorliegt, sieht aus wie eine Resonanz-Katastrophe

Beispiel Börsencrash: Manche Aktionäre haben eine Software, in denen sogenannte Stop-Loss-Marken gesetzt sind. Diese Marken sind im kleinen Signalbereich durchaus sinnvoll: Sinkt meine Aktie unter einen bestimmten Wert, leitet die Software automatisch einen Verkauf ein, um größere Verluste zu vermeiden. Jetzt gibt es aber Situationen, in denen mehrere Werte beginnen, noch schneller nachzugeben. Wenn viele Aktionäre solche Stop-Loss-Marken gesetzt haben, verkaufen plötzlich viele auf einmal ihre Aktien. Diese Leute wissen nichts voneinander, auch nicht von den Marken der anderen Beteiligten. Durch den zeitgleichen Massenverkauf stürzt der Kurs noch weiter und schneller ab.

Das hat zur Folge, dass andere, weniger scharf gesetzte Stop-Loss-Marken nun ebenfalls getriggert werden. Dann geht der Crash richtig los, verursacht durch zahlreiche „Hidden Links“ zwischen den einzelnen Marken. Also zwischen Zuständen, die eigentlich nichts miteinander zu tun haben, weil sie in der Regel weit voneinander entfernt sind. Aber durch bestimmte Konstellationen treten diese Zustände plötzlich miteinander in Konflikt. Daraus kann eine Resonanz-Katastrophe resultieren.

Normalerweise sorgt man dafür, dass ein System durch Failure- bzw. Constraint-Monitoring so abgesichert ist, dass nur die wenigen zulässigen Zustände nach außen wirksam werden. Bei Software spricht man von der State Explosion: Selbst bei einfachen Zustandsautomaten können schnell 1050– Zustände auftreten. Diese lassen sich nicht alle testen. Darum umgeben Entwickler ihr System in der Regel mit Monitoring-Funktionen. Diese sorgen dafür, dass jeder Zustand unterdrückt wird, der nicht einem zulässigen Zustand entspricht. Ich sage immer: Es muss einen eisernen Ring von Monitoren und Protektionen zur Überwachung der zulässigen Zustände um das System herum geben, eben den Constraints, damit nichts durchrutscht. Wurde das nicht sauber aufgebaut, kann ein unzulässiger Zustand durchs Monitoring schlüpfen.

Und die Gefahr, dass solche Zustände durchrutschen oder ungewollte Interoperabilitäten eintreten, ist größer, wenn ich meinen Code im Nachgang nochmal aufmache und zusätzliche Funktionen einbaue.

Absolut richtig, genau. Und dann laufe ich Gefahr, dass sich die Constraints nicht mehr sauber managen und kontrollieren lassen. Dann treten unkontrollierte Zustände auf, ohne dass es auffällt. Diese können sich mit anderen Zuständen verbinden. Und dann fliegt Ihnen das System um die Ohren, wie beim Börsencrash.

Es gibt inzwischen Verfahren, mit denen sich so etwas in den Griff bekommen lässt. STAMP zum Beispiel: „System-Theoretic Accident Model and Process“, das von Nancy Leverson am MIT entwickelt wurde. Dieser Ansatz besagt, dass Fehler oder Katastrophen keine Verkettung von Fehlern sind, sondern ein systemischer Rückkopplungs-Effekt aufgrund schlecht gemanagter Constraints.

Was bedeutet das für softwaregestützte Automatisierungsprozesse? Was für Lehren und was für Konsequenzen lassen sich daraus ziehen?

Solange die Systeme und ihre Komponenten sauber segregiert sind, ist das alles kein Thema. Doch wenn viele komplexe Funktionen über unterschiedliche Schnittstellen und ohne ausreichende Kontrolle zusammengeschaltet werden, ist die Gefahr sehr groß, dass dysfunktionale Verletzungen der Constraints auftreten. Mit einem Vorwärts-Ansatz ist es praktisch ausgeschlossen, alle Eventualitäten und daraus resultierende Effekte abzufangen. Wenn bei sicherheitskritischen Produkten solch ein Effekt bis in die oberste Ebene durchschlägt, kann das schwer wiegende Folgen haben.

Wer sich dessen bewusst ist, dass hier das größte Problem liegt, kann das mit entsprechenden Methoden oder Prozessen in den Griff bekommen. Ein Top-Down-Entwurf hilft sehr. Gutes Systems Engineering auch. STAMP ist bereits erprobt und akzeptiert. Es stellt an den Entwickler systematisch bestimmte Fragen wie: „Hast du auch daran gedacht ….? Was passiert, wenn da was ausfällt …? Wie ändern sich die Zustände, wenn dies und das ausgelöst wird …?“ und so weiter. Dies dient dazu, genau diese Fehlstellen und diese Verletzung der Constraints zu erkennen und auszumerzen.

Es gibt auch andere Verfahren, beispielsweise Contract-based Design. Dieses sorgt dafür, dass schon von der kleinsten Komponente an vagabundierende Zustände ihre Umgebung nicht verlassen können. Wir haben gerade in München zu diesem Verfahren eine Engineering-Plattform entwickelt, die voraussichtlich Mitte dieses Jahres fertig wird. Wenn man strikt nach diesem CBD-Paradigma entwickelt, sorgt schon der Prozess in Verbindung mit konkreten Check-Methoden dafür, dass diese vagabundieren Zustände erst gar nicht entstehen können.

Anstatt mühselige Kompatibilitätsanalysen zu machen und dann irgendwie zu ermitteln, wie all diese unzähligen Zustände zusammenpassen, sollte man lieber von Anfang an dafür sorgen, dass Komponenten zum Beispiel überhaupt nur drei Zustände einnehmen können. Diese Vorgaben müssen sorgfältig getroffen werden. Dann folgen systematische Kompatibilitäts- und Konsistenz-Analysen sowie Dominanz-Analysen. Das lässt sich alles formalisieren. So ist sichergestellt, dass diese Contracts zusammenpassen. Wenn man den Prozess und die entsprechenden Nachweise zusammen nimmt, erhält man einen fast schon formalen Nachweis der Kompatibilität, zumindest auf der Signal- beziehungsweise Zustandsebene.

Bei der enormen Komplexität moderner Systeme wird man ohne formalen Nachweis inzwischen nicht mehr auskommen.

Nein, da kommen Sie nicht mehr ohne formale Nachweismethoden aus, auf keinen Fall. Nur mit Testen alleine decken wir schon seit Langem nicht mehr den gesamten Zustandsraum komplexer Systeme ab.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben
Viel interessante Details zum Hintergund einer Softwareentwicklung .Im vorliegenden Fall geht es...  lesen
posted am 05.04.2019 um 14:56 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45835915 / Safety & Security)