Suchen

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

| Autor: Sebastian Gerstl

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.

Ethipian 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?
Ethipian 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 / Ethiopian Airlines ET-AVJ takeoff from TLV / FlickreviewR 2 / CC BY-SA 2.0 / CC BY-SA 2.0 )

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, kosten 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 verzichte – so schwer wiegt der Vertrauensverlust bereits.

Doch nicht nur Flugzeughersteller Boeing, sondern auch auf 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 habe 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 uns mit dem erfahrenen Systemtechniker um eine Einschätzung der Lage unterhalten – und darüber, welche Lehren auch Unternehmen aus anderen Industriebereichen aus dem Unglück ziehen sollten.

„Offenbar liegen hier wenigstens zwei Fehler vor“

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

Henning Butz: Wenn so 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 – sozusagen Nachweis-Mittel und Nachweis-Vorschriften – festgelegt, die dann auch vom Hersteller genau einzuhalten sind. Das wird alles in einem Sicherheits– und Zertifikationsplan mit der Luftfahrtbehörde abgestimmt. Da 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 schon mal in mindestens zwei Instanzen geschehen müssen. Mir würde jetzt kein Fall einfallen, bei dem so etwas schon einmal vorgekommen wäre.

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

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

Grundsätzlich ist das, wenn sie ein Flugzeug bauen, auch 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 Leute, die da drin sitzen, sind autorisiert, die Ergebnisse des Flugzeugbauers zu begutachten. Und die sind vollkommen unabhängig. Da käme kein Geschäftsführer 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 da herrscht.

Diese Sicherheits-Ingenieure müssen auch völlig unabhängig sein. Wenn die Ihren Job vernünftig machen, kann Ihnen auch von Unternehmensseite her keiner reingrätschen. Das ist ein entscheidender Unterschied zwischen der Luftfahrtindustrie und anderen Branchen. Die Sicherheits-Ingenieure 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. Da ist zwar kein Flugzeug abgestürzt, aber es gab doch Analog-Beispiele, die quasi identisch abgelaufen sind – auch bei Airbus. Es gab da 1991 einmal 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, war, dass in diesem Maschinen-Typ eine spezielle Steuerung für den Autopiloten installiert war, 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.

Offenbar liegen hier zwei verschiedene Fehler vor

Weil der Pilot durchstarten musste, hat er ins Steuerhorn gegriffen und hat die Maschine hochgezogen in der Annahme, 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 hatte dadurch plötzlich einen Anstellwinkel von über 80°, ist quasi senkrecht hochgegangen, und hat dabei natürlich an Geschwindigkeit verloren. Als die Maschine dann auf 40 Knoten Geschwindigkeit runter war, ist das Flugzeug seitlich nach hinten abgekippt und mit 70° zu Boden gestürzt. Es gelang dem Piloten zwar, das Flugzeug wieder abzufangen. Aber als es dann wieder auf der entsprechenden Höhe war, griff der Autopilot wieder ein, und zog das Flugzeug erneut mit 70° Winkel in die Höhe. Das ist dann drei, viermal passiert, ehe es dem Piloten gelang, die Sache in den Griff zu bekommen.

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

Genau, das war sozusagen ein Force Fighting gegeneinander. Das lag daran, weil zwei Systeme nicht hundertprozentig abgestimmt waren, unter, sag ich mal, bestimmten Randbedingungen. Und das wird wahrscheinlich hier so ähnlich sein. Beziehungsweise, zunächst muss man ja feststellen, dass hier (beim Unglück der Ethiopian Airlines Maschine, Anm. d. Red.) ja offenbar zwei Fehler verantwortlich sind: ein Software(funktions)fehler und ein Sensorfehler.

Aber ich gehe schon davon aus, dass da natürlich Design– und Testfehler gemacht wurden, und das System nicht vollständig unter allen Betriebsbedingungen, Fehlerkonditionen vor allen Dingen, validiert wurde. Und so etwas geschieht, insbesondere dann, wenn mehrere Funktionen, die eigentlich früher nichts miteinander zu tun hatten, plötzlich miteinander gekoppelt werden.

Es ist ja hier so: die 737 MAX hat, im Vergleich zur alten 737, weit nach vorne geschobene Triebwerke, weil die größer sind als die alten. Dadurch wandert der Schubschwerpunkt nach vorne und drückt, wenn der Pilot mehr Gas gibt, die Nase überproportional hoch. Das Augmentationssystem MCAS soll die Überschreitung bestimmter Anstellwinkel verhindern und arbeitet entsprechend gegen die Nasenanhebung. Wenn das System ein falsches Sensorsignal bekommt, dann kommt es gegebenenfalls zu Überreaktionen.

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. Selbst mit wenig Schub hätte die Maschine, ohne das MCAS, die Nase bereits überproportional hoch genommen. Das MCAS hat da dagegen gehalten, sodass sich sozusagen das ausgeglichene Flugverhalten der alten 737 synthetisch eingestellt hat. Das hat offensichtlich hier in bestimmten Flugphasen oder bei bestimmten Situationen – etwa fehlerhaften Sensorensignalen – zu größeren Ausschlägen oder höheren Empfindlichkeiten geführt als geplant.

Das scheint hier relativ klar zu sein: Außerdem waren die Piloten völlig überrascht von diesem Verhalten, und hatten – in der kurzen Zeit zumindest – keine Antwort hatten, oder keine Vorstellung davon, wie sie damit umgehen sollen.

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

Zumindest aus der Ferne sieht das ganz genau so aus.

Man hörte auch Vorwürfe in dem Sinne, dass manche Piloten gar nicht so richtig gewusst hätten, was MCAS überhaupt tut. Und auch Piloten die sagten, dass das System schlecht dokumentiert wäre, etwa ab welchem Winkel es aktiv anfängt zu greifen.

Offensichtlich wurde die Funktion nicht richtig verstanden, oder sie wurde nicht richtig kommuniziert. Und 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. Dann haben sie womöglich noch oben zusätzlich, nachdem das Design schon bestanden hatte, die MCAS-Funktion draufgeflanscht, um das Flugzeug handhabbar zu machen.

Dann können solche Sachen passieren, vielleicht weil die Beteiligten den Umfang der Systemkopplungen nicht mehr überblicken, oder weil, insbesondere bei Sensorfehlern, unerwünschte Wechselwirkungen mit anderen Systemen entstehen, die vorher nicht bestanden hatten. Ich denke mal, 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

Nehmen wir mal einen Börsencrash, da gab es in der Vergangenheit ja auch Beispiele dazu: 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 eine Börse, oder mehrere Werte, beginnen, steiler abzustürzen. Wenn viele Aktionäre solche Stop-Loss-Marken gesetzt haben, verkaufen jetzt viele auf einmal ihre Aktien. Diese Leute wissen nichts voneinander, und auch nicht von den Marken der anderen Beteiligten. Aber dadurch, dass jetzt ein plötzlicher Massenverkauf einsetzt, stürzt der Kurs noch weiter und schneller ab. Das hat zur Folge, das andere, eigentlich viel entspanntere Stop-Loss-Marken, nun ebenfalls getriggert werden. Dann geht der Crash richtig los. Das wird verursacht durch zahlreiche Hidden Links zwischen den einzelnen Marken, 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. Und dann haben Sie die Resonanz-Katastrophe.

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 manchmal von der State Explosion: da haben Sie schnell 1050– Zustände, auch bei relativ einfachen Zustandsautomaten. Die können sie niemals alle testen. Darum umgeben Sie in der Regel Ihr System mit Monitoring. Diese Monitore sorgen eigentlich dafür, dass jeder Zustand, der nicht so aussieht wie ein Zulässiger, eins auf die Nuss kriegt und wieder verschwindet. Ich sage immer: Da muss ein eiserner Ring von Monitoren und Protektionen zur Überwachung der zulässigen Zustände, eben der Constraints, um das System sein, damit da nichts durchrutscht. Hat man das nicht sauber gemacht, schlüpft auch mal ein Zustand durchs Monitoring durch.

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 reinpacke.

Absolut richtig, genau. Und dann laufe ich Gefahr, dass sich die Constraints nicht mehr sauber managen und nicht mehr sauber kontrollieren lassen. Dann sind da irgendwelche Zustände draußen, die machen was sie wollen, und Sie merken es nicht. Die verbinden sich jetzt mit anderen Zuständen. Und dann fliegt Ihnen, wie beim Börsencrash, das System um die Ohren.

Dabei gibt es ja inzwischen Verfahren, mit denen Sie so etwas in den Griff bekommen können. STAMP ist so eines, System-Theoretic Accident Model and Process, das wurde von Nancy Leverson am MIT entwickelt. 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 jetzt für Softwaregestützte Automatisierungprozesse? Was für Lehren und was für Konsequenzen kann man jetzt daraus ziehen?

Wie gesagt, solange die Systeme und ihre Komponenten sauber segregiert sind, ist das alles kein Thema. Aber sobald viele Funktionen, die schon von sich aus relativ komplex sind, über diverse Schnittstellen und gegebenenfalls unzureichend kontrolliert zusammengeschaltet werden, ist die Gefahr, dass dysfunktionalen Verletzungen der Constraints passieren, sehr groß. Ich glaube, es ist in diesem Vorwärts-Wege nahezu ausgeschlossen, das wirklich alles zu fangen. Da wird man immer wieder solche Effekte erleben. Mit Glück überlebt man sie bei sicherheitskritischen Produkten. Wenn man Pech hat, und sich so ein Effekt auf die oberste Ebene durchschlägt, geht's schief.

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 da sehr, gutes Systems Engineering auch. STAMP ist ja bereits erprobt und akzeptiert. Es stellt an den Entwickler systematisch bestimmte Fragen, nach dem Motto: „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. Das dient, um genau diese Fehlstellen und diese Verletzung der Constraints zu erkennen und auszumerzen.

Es gibt auch noch andere Verfahren, beispielsweise Contract-based Design. Das sorgt dafür, dass schon von der kleinsten Komponente an die vagabundierende Zustände nicht herauskommen können. Wir haben gerade in München zu diesem Verfahren eine Engineering Plattform entwickelt, die wird voraussichtlich Mitte dieses Jahres fertig. Wenn man strikt nach diesem CBD-Paradigma entwickelt, sorgt schon der Prozess in Verbindung mit konkreten Checkmethoden dafür, dass diese vagabundieren Zustände erst gar nicht entstehen können. Anstatt mühselige Kompatibilitätsanalysen zu machen und dann irgendwie herauszukriegen, wie all diese unzähligen Zustände zusammenpassen, sorge ich lieber von Anfang an dafür, dass meine Komponenten zum Beispiel überhaupt nur drei Zustände einnehmen können. Diese Vorgaben treffe ich ganz sorgfältig. Und dann mache ich systematische Kompatibilitäts– und Konsistenz-Analysen, und Dominanz-Analysen. Das kann ich alles formalisieren. Damit stelle ich sicher, dass diese Contracts zusammenpassen. Dann hat man, wenn man den Prozess und die entsprechenden Nachweise zusammen nimmt, 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 den gesamten Zustandsraum komplexer Systeme nicht mehr ab.

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