Suchen

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

Seite: 2/2

Firma zum Thema

„Als Vorgesetzter muss man in der Lage sein, dem Sparzwang widerstehen zu können“

AOA Disagree Warning: Ein Indikator am unteren Bildschirmrand soll bei der Boeing 737 MAX angeben, wenn zwei Lagesensoren unterschiedliche Werte angeben. Dabei handelt es sich aber nur um ein optionales Safety-Feature – eines, das in der Unglücksmaschine Ethiopian Airlines 302 nicht vorhanden war.
AOA Disagree Warning: Ein Indikator am unteren Bildschirmrand soll bei der Boeing 737 MAX angeben, wenn zwei Lagesensoren unterschiedliche Werte angeben. Dabei handelt es sich aber nur um ein optionales Safety-Feature – eines, das in der Unglücksmaschine Ethiopian Airlines 302 nicht vorhanden war.
(Bild: The Boeing Company)

Man hört ja seit Jahren das Credo „Safety by Design“: Die Funktionsfähigkeit und die Systemsicherheit müssen von Anfang an Grundbestandteile des Software-Designs sein. Sicherheitskritische Elemente dürften demnach nicht noch einmal im Nachgang verändert werden. Doch Zeitdruck, Kostendruck und Time-to-Market stehen mit diesen Ansprüchen in Konflikt.

Neue Funktionen in vorhandene komplexe Software zu implementieren, ist nichts Ungewöhnliches. Vor allem, wenn diese nach früheren, rudimentären Methoden entwickelt wurde und zum Teil schlecht dokumentiert ist. Oft ist dies bei „Legacy Software“ der Fall. Ich kann mir gut vorstellen, dass die Ursachen für den betrachteten Fall hier liegen. Er ist ein Lehrbeispiel, das davor warnt: „Vorsicht bei solchen Maßnahmen!“ Ich will nicht ausschließen, dass das nachträgliche Implementieren von Funktionen möglich ist. Aber man muss sehr sorgfältig arbeiten und möglicherweise zusätzliche Qualitäts- und Sicherheitsmaßnahmen ergreifen, um Kompatibilitätsfehler schon im Design zu erkennen und zu beseitigen.

Wie gesagt: Es ist auch nicht ausgeschlossen, dass Leute schwerwiegende Fehler gemacht haben. Das kommt im Flugzeugbau äußerst selten vor, weil die Entwicklung unzählige Check-Instanzen durchläuft, einschließlich intensiver Behörden-Reviews. Wenn das doch der Fall sein sollte, dann muss das Konsequenzen haben. Aber wie gesagt, es gab bereits ähnliche Incidents, bei denen Leute vollkommen sorgfältig gearbeitet hatten. Auch Behörden sind diese Fehlstellen entgangen. Es wurden Kleinigkeiten oder komplizierte Funktionskonstellationen übersehen.

Es sollten immer zwei verschiedene Check-Verfahren bestehen

Ich habe bei kritischen Nachweisen immer mindestens zwei unterschiedliche Check-Verfahren eingesetzt. Und ich kann Ihnen bestätigen: In nicht wenigen Fällen haben wir Diskrepanzen festgestellt, wo ein Checker alleine nicht richtig gearbeitet hat. Oft können Sie die Funktionsweise Ihrer Checker nicht mehr plausibel nachprüfen, beispielsweise beim Model-Checking. Sie können nur glauben, wenn die melden: „alles OK“. Das ist bei kritischen Funktionen zu wenig. Dann lohnt sich die Investition, den gleichen Nachweis-Schritt noch einmal zu machen, mit einem anderen Verfahren, und zu überprüfen: Kommen beide zu demselben Ergebnis?

Aber man muss eben auch als Vorgesetzter in der Lage sein, so eine Zusatzinvestition durchzusetzen. Eine Facility hat mich einmal rund 300.000 Dollar gekostet, nur um bestimmte kritische Nachweise in einem redundanten Schritt mit dem zweiten dissimilaren Checker zu machen. Es gab damals ein Riesen-Geschrei wegen der Kosten. Aber wenn ich das nicht gemacht hätte, wären bei der Funktionsintegration reihenweise Konfigurationsfehler durchgereicht worden. Das hatte der erste Checker nicht gemerkt. Und angenommen, diese Konfigurationsfehler bewirken kritische Funktionsausfälle, sodass das Flugzeug, sagen wir mal eine Airbus A380, Startverbot erhält; ein Tag, an dem eine solche Maschine gegroundet ist, kostet eine Million Dollar! Und die zahlt gemäß Produkthaftung der Flugzeughersteller. Gemessen daran heißt das: Meine Facility hätte sich bereits nach einem Drittel Tag „Aircraft on Ground“ amortisiert.

Als Vorgesetzter muss man durchsetzen können, dass solche Investition zum Nutzen des Unternehmens gemacht werden. Und das ist, soweit ich sehe, ein Führungsmangel, der heute relativ häufig anzutreffen ist: dass die Vorgesetzten bei solchen Entscheidungen dem Druck des Kapitals, das heißt dem Sparzwang, nicht widerstehen.

Wenn man überlegt, dass alle 737-MAX-Flugzeuge bereits seit spätestens dem 13. März weltweit gegroundet sind...

Das kostet irres Geld, ja. Aber das sieht man auch an anderer Stelle. Nehmen wir den Abgasskandal: Die Hersteller konnten die Schadstoffanforderungen zum Start of Production (SOP) nicht ganz erfüllen. Das kann passieren. Am SOP kommt keiner vorbei, das Produkt muss auf den Markt. Dass man bei nicht sicherheitskritischen Funktionen mit Software vorübergehend etwas nachhilft ist nicht schön, aber vielleicht verständlich. Im Anschluss hätte jedoch sofort ein Vorgesetzter dafür sorgen müssen, dass der Fehler zum nächsten Produktionslos entfernt wird. Stattdessen haben die Hersteller acht Jahre lang mit dem gleichen Mist weiter gemacht! Unfassbar!

Hier ist selbst auf den höchsten Führungsebenen die Integrität verloren gegangen. So etwas darf nicht vorkommen. Irgendwann kommt es heraus und kostet das Unternehmen sehr viel Geld. Dagegen wären die geschätzte eine Million für das Software-Upgrade-Projekt Peanuts gewesen. Ich kann nur empfehlen, sich als Unternehmen erst gar nicht auf solche Standpunkte wie beim Abgasskandal einzulassen.

Aber auch wenn im Idealfall nichts passiert, merkt man doch am vorliegenden Fall, wie fatal sich so ein Fehler bei so komplexen Systemen mit Millionen Zeilen Code durchschlagen kann.

Ja. Dramatisch.

Wenn sich ein Fehler nur leicht auswirkt, beispielsweise das Radar anfängt zu flackern, etwas, das die Piloten rechtzeitig bemerken und angehen können...?

Das ist kein Problem, dafür gibt es Prozeduren.

Aber wenn sich dann, wie im vorliegenden Fall, etwa das Höhenleitwerk verstellt...

Das ist eine so riesige Fläche, wenn die sich bewegt, treten enorme aerodynamische Momente auf. Da kann ich mit dem Ruder so gut wie gar nichts dagegen machen – oder nur mit sehr viel Geschick, wie die Piloten der Interflug-Maschine. Da können Sie als Passagier eigentlich nur von Glück sagen, wenn die Flight Crew das abfängt. Der Pilot damals beim A310-Incident muss Nerven wie Drahtseile gehabt haben.

In der Panik einen klaren Gedanken zu fassen, ist zudem schwierig. Im vorliegenden Fall kommt der Vorwurf hinzu, dass nicht ausreichend dokumentiert worden ist, was diese Software genau macht, und ab welchem Höhenwinkel sie genau anfängt einzugreifen.

Als Pilot sind Sie dann so gut wie verloren. Wenn Sie keine System Awareness haben, dann können Sie nur noch mutmaßen. Und wenn man auch noch das falsche Funktionsmodell im Kopf hat, hat man keine Chance mehr.

Das zeigt einmal mehr, wie essentiell eine vernünftige Dokumentation ist, oder?

Absolut.

Und dass man nicht annehmen kann, dass die Funktion von einer solchen Software selbsterklärend ist.

Genau, das ist ein wichtiger Punkt. Wenn das System sehr komplex ist, dann muss man ganz besonders sorgfältig sein. In der Dokumentation und in der Entwicklung. Beides muss zu 100 Prozent übereinstimmen und verständlich sein – übrigens auch ein Problem der Semantik. Wenn eine Führungskraft ihre Entwickler, Prüfer, Dokumentierer und so weiter nicht entsprechend anweist und versäumt, geeignete Verfahren wie STAMP oder andere formale Methoden einzusetzen, ist die Wahrscheinlichkeit sehr hoch, dass etwas übersehen wird. Mit der möglichen Folge, dass es zu einem Konflikt mit schwerwiegenden Auswirkungen kommt.

(ID:45835915)

Über den Autor

 Sebastian Gerstl

Sebastian Gerstl

Redakteur, ELEKTRONIKPRAXIS