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

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

Man hört ja seit Jahren immer wieder das Credo „Safety by Design“: die Funktionsfähigkeit, die Systemsicherheit muss von Anfang an Grundbestandteil des Software Designs sein. Was natürlich ausschließen würde, dass man dann im Nachgang sicherheitskritische Elemente nochmal aufmacht und neue Codezeilen dazu packt. Aber dann hört man auf der anderen Seite, dass Zeitdruck, Kostendruck und Time-to-Market mit diesen Ansprüchen in Konflikt stehen.

Bestehende komplexe Software, die man aufmachen muss, um hinterher neue Funktionen drauf zu setzen, ist ja nicht unbedingt ungewöhnlich. Vor allem, wenn es nach früheren rudimentären Methoden entwickelt wurde, wo auch die Dokumentation zum Teil schlecht ist, auch bekannt unter der Bezeichnung „Legacy Software“. Ich kann mir gut vorstellen, dass es hier im Grunde passiert ist. Es ist ein Lehrbeispiel, genaugenommen, eines bei dem man sagen kann: „Vorsicht bei solchen Maßnahmen!“ Ich will nicht ausschließen, dass das geht. Aber da muss man 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 da wirklich Leute massiv Fehler gemacht haben, aber 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 da natürlich eingegriffen werden. Dann müssen auch Köpfe rollen, finde ich, denn das darf nicht sein. Aber wie gesagt, es gab bereits ähnliche Incidents, und da haben Leute vollkommen sorgfältig gearbeitet. Auch den Behörden sind diese Fehlstellen entgangen. Da wurden einfach 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 es nur glauben, wenn die melden: „alles OK“. Das ist zu wenig bei kritischen Funktionen. Dann lohnt sich die Investition, den gleichen Nachweis-Schritt nochmal zu machen, mit einem anderen Verfahren, und zu überprüfen: kommen die beide zum gleichen Ergebnis?

Aber muss man eben dann auch als Vorgesetzter in der Lage sein, so eine Zusatzinvestition durchzusetzen. Eine Facility hat mich mal locker 300.000 Dollar gekostet, nur bestimmte kritische Nachweise in einem redundanten Schritt mit dem zweiten dissimilaren Checker zu machen. Das 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 der Flugzeughersteller gemäß Produkthaftung. Gemessen daran heißt das: meine Facility hat sich bereits nach einem Drittel Tag „Aircraft on Ground“ amortisiert gehabt.

Das muss man als Vorgesetzter aber durchsetzen können, dass solche Investition gemacht werden zum Nutzen des Unternehmens. 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 da überlegt, dass alle 737-MAX-Flugzeuge bereits seit spätestens dem 13. März weltweit gegroundet sind...

Das kostet ein irres Geld, ja. Aber das sieht man auch an anderer Stelle. Nehmen wir mal den Abgasskandal. Das läuft doch auf das Gleiche hinaus. Die konnten die Schadstoffanforderungen zum Start of Production (SOP) nicht ganz erfüllen – OK, kann passieren. Am SOP kommt keiner vorbei, das Produkt muss raus. Dass man dann bei nicht sicherheitskritischen Funktionen mit Software vorübergehend etwas nachhilft – na ja, nicht schön, aber vielleicht verständlich. Nur korrekterweise muss dann sofort ein Vorgesetzter hergehen und zu den Entwicklern sagen: Wir nehmen jetzt eine Million in die Hand, und dann machen wir den Fehler zum nächsten Produktionslos raus. Aber stattdessen haben die acht Jahre lang mit dem gleichen Mist weiter gemacht! Unfassbar!

Das ist einfach Verlust von Integrität, auf den höchsten Führungsebenen. Das kann nicht sein, das darf nicht sein, das sehen sie ja. Irgendwann kommt es raus und dann kostet es das Unternehmen ein irres 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 bei so komplexen Systemen, mit Millionen Zeilen Code, so ein Fehler durchschlagen kann.

Ja. Dramatisch.

Wenn er sich etwas kleines auswirkt und dann, zum Beispiel, nur das Radar anfängt zu flackern, etwas, das die die Piloten es rechtzeitig bemerken und aufgreifen 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, das sind unglaubliche aerodynamische Momente die da auftreten. 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 wieder fängt. Der Pilot damals, beim A310-Incident, muss Nerven wie Drahtseile gehabt haben.

Aber erst einmal in der Panik dann erst einmal einen klaren Gedanken in dieser Richtung fassen, ist ja wieder eine andere Situation. Im vorliegenden Fall kommt ja noch der Vorwurf dazu, dass das nicht ausreichend dokumentiert worden ist, was diese Software genau macht, und ab welchem Höhenwinkel sie jetzt genau anfängt zu greifen.

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

Da merkt man einfach immer wieder wie essentiell auch vernünftige Dokumentation ist.

Absolut.

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

Genau, das ist schon der Punkt. Wenn das System sehr komplex ist, dann muss man ganz besonders sorgfältig sein. In der Dokumentation, und in der Entwicklung. Das muss 100% übereinstimmen und verständlich sein – auch ein Problem der Semantik. Wenn eine Führungskraft da nicht drauf achtet, ihre Entwickler, Prüfer, Dokumentierer und so weiter nicht entsprechend anweist, und versäumt, geeignete Verfahren wie STAMP oder andere formale Methoden einzusetzen – dann ist die Wahrscheinlichkeit, dass etwas übersehen wird, sehr hoch. Und auch, dass das dann zum Konflikt kommt.

Tod durch Software – Kein Patch kann fatale Fehler wieder richten

„Software Engineering hat die Aufgabe, sich selbst abzuschaffen“

(ID:45848490)