Tod durch Software – Kein Patch kann fatale Fehler wieder richten



  • 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?

    zum Artikel



  • Ein Blick in die Software-Spezifikation könnte Klarheit schaffen. Alles andere ist Spekulation. Und wenn da tatsächlich Abweichungen zwischen Spec., Entwurf und Implementierung existieren sollten, würde mich das sehr verwundern.



  • Der Artikel ist wohl genauso überhastet entstanden wie die MCAS-Software. Es handelt sich um die Trimmspindel des Höhenleitwerks, das vom Computer und ohne Wissen der Piloten verstellt wird. Die Absicht dahinter ist, ein Überziehen der Maschine zu verhindern. Dies kann durch die stärkeren Triebwerke verursacht werden, die durch ihre tiefe Lage ein Aufnicken bewirkten. Fliegt die Maschine zu langsam, wird umgetrimmt, um die Nase unten zu lassen. Liefert nun ein Sensor falsche Signale, wird auch umgetrimmt, wenn die Nase bereits nach unten zeigt.



  • Und was ist, wenn man bei der Spezifikation schon Fehler machte?
    Keine Abweichung zwischen Spezifikation, Entwurf und Implementierung, heißt nicht unbedingt fehlerfrei.
    Die Fehlersuche muß immer bei der Wurzel beginnen.
    Also Frage 1: Wurde die Spec richtig ausgelegt?



  • @ Olaf
    Naja, erstens müsste da dann die Spec fehlerfrei sein, zweitens garantiert eine fehlerfreie Spezifikationen noch lange nicht, dass der Code 100% fehlerfrei ist.
    Dass die Piloten nicht wissen, dass ihnen ein System ins Handwerk pfuschen kann und wie dieses zu überstimmen ist, ist die Höhe.



  • Dass in dem Artikel Seitenleitwerk und Höhenruder verwechselt wurden, schmälert nicht unbedingt die Tragik des Geschehenen.
    Fatal ist offensichtlich, dass das Signal, das die Trimmung auslöst lediglich von einem einzigen Sensor generiert wird und somit keinerlei Redundanz besteht. Wie ein solches System die Zulassung der FAA erhalten hat, ist mehr als merkwürdig und skandalös.
    VW wurde von den US-Behörden wegen des Diesel-Skandals verklagt und musst Milliarden an Schadenersatz bezahlen, ein VW-Manager sitzt in den USA deswegen in Haft. Und dies, obwohl durch diese, ich möchte dies nicht herungterspielen, betrügerische Software kein einziger Mensch direkt zu Schaden gekommen ist. Ich bin mal gespannt, wie die US-Behörden in diesem Fall handeln werden. Ich bin mir jedoch sicher, dass keinem einziger Mitarbeiter von Boeing oder der FAA auch nur ein Haar gekrümmt werden wird.
    Übrigens, auch Airbus hat in seinen Flugzeugen derartige Systeme eingebaut, allerdings werden diese von drei Sensoren angesteuert. Nur wenn die Signale von wenigstens zwei Sensoren identische Daten zeigen, werden diese weitergeleitet. Obwohl diese Redundanz die Wahrscheinlichkeit, dass falsche Signale zu einer Veränderung der Trimmung führen, um Größenordnungen vermindert, soll es vorgekommen sein, dass bei einer A-321 zwei der Sensoren offenbar in derselben Stellung eingefroren waren und die Signale dieser beiden Sensoren somit als korrekt angesehen wurden. Zum Glücvk haben die Piloten in diesem Fall das System gekannt und konnten es abschalten.
    Abgesehen von den Designfehlern mit der nicht vorhandenen Redundanz ist es unverzeihlich, dass Boeing das System nicht ausreichend veröffentlicht hat und die Piloten deshalb dem Eingreifen der Automatik hilflos ausgesetzt waren.



  • und projiziert dies bitte mal auf: Wir fahren alle bald autonom !!!
    BotU



  • Hartmut Schorrig
    Spec und Implementierung: Ja, auch die Spec kann falsch sein! Ich beobachte, dass immer noch sehr viele Entwickler dem Wasserfallmodell verhaftet sind (Spec - Imp - Test nacheinander, was einmal unterschrieben ist, gilt.) Bei sicherheitsrelevanter Sw wird noch eher nach dem Wasserfallmodell gearbeitet. Agile Software wird dann gelebt, wenn sie von oben verordnet ist, dann wird ein Prozess daraus gemacht, ebenfalls starr. Ich habe in einem guten Vortrag gehört: Sobald es strenge Regeln gibt, sei es nicht mehr agil.

    Das V-Modell soll(te) aussagen, dass gegenüber der linken oberen Ecke die Spec bereits mit der rechten oberen Ecke getestet werden sollte, noch bevor die Implementierung in der unteren Spitze des V dran ist. Man kann eine Spec auf Widerspruchsfreiheit, Vollständigkeit usw. testen und man kann auch testen, ob die dazugehörige User-Docu von den Piloten verstanden wird (klar beschrieben usw.). Wenn man das agil lebt (wirklich agil, Feedback verarbeitet, feste Zwischensteps einbaut) und parallel an Implementierungsfragen arbeitet, dann wäre es gut. Dieser Gedankengang ist nicht nur für Boeing, sondern für uns alle, egal ob sicherheitsrelevant oder nicht wichtig. Er wird zuwenig gelebt. Herr Willert, Andreas hat in einem Vortrag in ein V-Modell kleine Vs hineingemalt, das sind Variationen der kleinen Schritte von der groben zur genauen Spec, ich fand das gut! Habe leider keine Unterlagen davon.

    Ich beobachte leider auch, dass Zulassungsverfahren sehr lange dauern. Es wird dabei auf Formalien gepocht, dass ist dann die Unterschrift auf ein schon gar nicht mehr zutreffendes Dokument. Dort arbeiten auch nur Menschen, oft penible. Für eine Zulassung braucht es die Mitarbeiter der Anwender, in dem Fall der Piloten.



  • Die Unglücke sind tragisch und hätten sicher vermieden werden können. Es ist eben nicht immer gut wenn alles durch die Kräfte der Märkte reguliert werden soll.
    Leider werden international auch Kernkraftwerke inzwischen digital durch Software gesteuert. Zwar immer mit Redundanz aber eben durch Software. Das macht mir mehr Sorgen.
    Die Auswirkungen wären regional und in ihrer Konsequenz wesentlich dramatischer.
    Dabei ist ein Flugzeugabsturz schon schlimm genug…



  • Der Satz ist falsch:
    Im Falle des jüngsten Unglücks des Flugs Ethiopia Airlines 302 hatte das Flugzeug einen defekten Lagesensor. , gemeint ist Lion Maschine.

    Sehr gespannt, wie die Firma Boeing davon kommen, im Vergleich mit VW (20 Mrd.)
    EU soll einige Mrd. Euro anfordern zur Forschung Flugsicherung und Umwelt…



  • Ich habe auch gleich an das autonome fahren gedacht. Es wird noch mehr solcher Fälle geben.



  • Das schlimmste ist das die Manager die keine Ahnung von Software haben, werden so oft die Entscheidung treffen, ein Produkt schnell auf Markt zu bringen.
    Leider ist es immer noch viele Firmen und Leute nicht klar, wie wichtig sind Software Tests



  • in Zeiten schneller Markt-Einführung sind die Kunden nunmehr die Test-Karnickel. Denn ein System ohne Fehler ist einfach kein System sondern nur eine Papier-Ente.



  • Produktqualifizierungen durch und am Kunden ist heute der Standard. Persönlicher Anstand vs. Kapitalismus, dieses driftet immer weiter auseinander.



  • @ HeldVomFeld
    Wenn die Piloten das vorher wüssten, würden die gar nicht anfangen. Das nennt man dann Fachkräftemangel.



  • Tja - Functional Safety ist nun mal nicht trivial. (Ich weiß es - ich arbeite auf diesem Gebiet.)

    Das Grundproblem auf die Manager und die Timeto-Market zu schieben, ist nur Teil der Wahrheit: eine wirklich saubere Risikoanalyse ist noch schwieriger als ein sauberes (widerspruchsfreies und realistisches) Lastenheft:
    BEIDES gibt es heutzutage kaum. Lastenhefte tendieren dazu, einerseits unvollständig zu sein, und andererseits überfrachtet mit Standard-Unsinn (Motto: Kopieren wir alles rein - dann haben wir bestimmt nichts vergessen).
    Und so reift das System beim Kunden. Was im Fall von Flugzeugen (aber auch Bahnen) verheerende Folgen haben kann.

    Dass außerdem die intuitive Bedienbarkeit (z.B. Abschalten des Modus durch Ziehen des Sticks) durch super-sichere, aber völlig unsinnige Bedienkonzepte ersetzt wird, trägt weiter zur Unsicherheit bei.

    Ein trauriges Beispiel …



  • Sensible Industrieeinrichtungen und öffentliche, sicherheitsrelevante Infrastrukturen stellen besondere Anforderungen an Betrieb, Kontrolle und Steuerung. Dies gilt insbesondere bei Störungen: Erste Priorität hat dann die Herstellung eines sicheren Zustands, zweite Priorität die Festlegung wer macht weiter und welche Folgeaktivitäten sind notwendig / zulässig.
    Auf keinen Fall darf es zu einem Wettkampf Mensch / Computer kommen. Dazu ist es notwendig, daß der Pilot die volle Kontrolle in Echtzeit übernehmen kann (vorausgesetzt der Flieger - allgemein: das betroffene System - kann ohne Computersteuerung fliegen). Damit besteht grundsätzlich die Möglichkeit, wieder in eine stabile Fluglage zu kommen und weitere Maßnahmen einzuleiten.
    Natürlich kann auch ein Pilot Fehler machen, besonders wenn nicht klar ist, welche Sensoren korrekte Daten liefern und wenn der Pilot den Flugzustand nicht spürt sondern vom Bildschirm serviert bekommt.
    Ich denke, daß die Sicherheitsrichtlinien für Software in der Avionik extrem anspruchsvoll sind und auch gelebt werden - vielleicht inzwischen zu sehr formal und zu wenig im Zusammenspiel, aber die steigende Systemkomplexität bedingt immer ein Restrisiko, das auch durch KI, Quantencomputer und augmented reality nicht auszuschließen ist. Wie auch immer wir das Restrisiko berechnen und bewerten: am Schluß muß die Entscheidung stehen, ob man mit dem Restrisiko leben kann oder will.



  • Fazit meines eigenen Entwicklerlebens:
    Was nicht getestet wurde, funktioniert nicht.
    Das gilt für alle Komponenten, erst recht für Software.
    Boeing hat ein nicht funktionierendes Flugzeugmodell ausgeliefert. Boeing ist schuld.

    Leider ist sowas seit Microsofts DOS 2.2 standard - das Produkt reift beim Kunden. Den Preis bezahlen i.d.R. unbeteiligte.



  • Die Entwickler der neuen/geänderten SW sollten bei den Testflügen (wenn welche stattfanden) mitfliegen um die Sw auch so zu verifizieren. wk



  • Noch einen Beitrag, diesmal eingeloggt:
    Nichts gegen Software! Sie ist nicht schlechter als komplexe Hardware oder Mechanik. Es gibt aber folgende Dinge zu beachten, auch hinsichtlich Wirtschaftlichkeit (oder Profitgier oder Sparsyndrom):

    • Der Mensch darf nicht ausgesperrt sein, er muss sich im Notfall sich über die Technik setzen können.
    • 3 aus 2-Redundanz soll mit verschiedenen Systemen ausgeführt sein, weil sonst die Redundanz weg ist: Gleiche Systeme verhalten sich im gleichen Fehlerfall gleich fehlerhaft. Die Redundanz sollte mit einfachen Systemen ergänzt sein, das einfachste wäre dann auch der Noteingriff oder das Mit-tun des Menschen. Die Haupt-Steuer-Software darf exakt und optimal sein, was der Mensch nicht schafft. Das redundante 2. und 3. System muss anzeigen, ob das Hauptsystem relevant arbeitet (exakte Messwerte sind im Schätzbereich der weniger genauen Systeme). Die weniger genauen Systeme können dann eingreifen, die Funktion ersetzen, wenn auch unoptimaler. Das kann bei Ausfall des Hauptsystems auch einfach nur die Notbremse sein, wenn dies so ausreichen sollte.
    • Prozessoren werden immer leistungsfähiger. Man kann verschiedene Systeme zusammenwerfen, wenn es nicht Gefahren wie Hackereingriffe geben könnte (weil ggf. ein System von außen offen sein muss, dann verbietet sich das Zusammenwerfen). Aber: Nicht die Redundanz aus Kostengründen auf einer leistungsfähigen CPU-Platine zusammenführen. Auf solche Ideen könnte schonmal jemand kommen, aus der profitorientierten Führungsetage oder mit wenig Praxiserfahrung aber akademischer Hochbildung. Alles ist zu beachten.
    • Bei der Boeing737MAX war es wohl auch eine zu komplexe Konstruktion die eben nur mit der komplexen Software zu beherrschen ist. Das scheint mir eine technische Fehlrichtung. Die Systeme müssen beherrschbar bleiben (nur nicht ganz optimiert) mit normalen Mitteln. Ich werde zum Schluss mal polemisch: Wofür steht denn MAX - schneller, höher, weiter, billiger und gewinnträchtiger?

    Hartmut Schorrig


Log in to reply