Nachlässigkeit, Dummheit, Absicht, oder - ein Programmierproblem

[oberallgeier]

Mich bewegt ein Programmierproblem das sicher nicht einfach ist: die Unglücks- und Pannenserie bei Boeings 737 Max. Was ist der Hintergrund? (Anmerkung: ich >glaube< dass eine heutige CPU deutlich aufwendiger zu konstruieren ist, als das flugmechanisch/-dynamische Steuersystem eines Airliners).

Klar, Boeing wird die Karten zumindest vor einer Lösung und positiver Bestätigung nach einer gewissen "neuen" Betriebsdauer nicht offen legen - wenn überhaupt (man könnte ja zu tief reinschauen). Aber was führt dazu, dass ein so potenter Hersteller so ein grundlegendes Problem hat? Erst die falsche Lösung - mit einer voreiligen und vermutlich zurecht-gelogenen Freigabe und danach monatelange Korrekturen, an deren bisherigen Ende die Entdeckung eines neuen Fehlers steht. Natürlich ist das System hoch komplex, zumal ein bereits mehrfach umgebauter Flugzeugtyp vorliegt. Beim Flieger wurde offenbar die ursprünglich angestrebte und weitgehend erzielte flugmechanische Stabilität durch die vielen Modifikationen beeinträchtigt und blieb daher kaum handelbar. Aber wieso ist das beim heutigen Stand der Automatisierungen ein Problem für die Programmierer? (Im Gehirn meldet sich der Elchtest der Sternenfirma).

Auch anhaltende Pannenserien in der Luftfahrt sind sicher ausführlich dokumentiert und kolportiert: Lockheed F-104/G - 116 Tote durch Abstürze, 269 Abstürze von 916 Maschinen, ein Guinness-Rekord (schnellste Landung ever).

Also das Pannenpotential müsste weithin bekannt sein.

Gibt es denn nicht mächtige Organisationshilfen für Großprojekte dieser Art? Oder ändert sich an den Programmierwerkzeugen über den langen Entwicklungszeitraum so viel? Gut, die Basisversion hatte gut drei Jahre von Entwicklungsbeginn 1965 bis zum ersten Verkauf/Einsatz 1968. Vermutlich sind die damaligen Unterlagen für heutige Systemanalysen und Programmiergrundlagen kaum mehr brauchbar. Auch über die anschließenden Modifikationen sind bestimmt mehrere Generationen von Programmiersprachen und -tools gegangen. Dazu die schon anfangs bekannten Probleme der tief liegenden Tragflächen (die ersten brachen schon vor der Maximallast) und des Platzmangels für die Triebwerke . . . Wobei die Triebwerke im Lauf der Zeit immer fetter wurden - um die Schallschutzforderungen zu erfüllen.

Das eingangs erwähnte Programmierproblem: Ist so ein Programmieraufwand wirklich so unglaublich umfangreich dass offenbar die Orientierung kaum mehr möglich ist? (Ich weiß, dass diese Frage schon recht kindlich wirkt.)

[Gnom67]

Welche Erkenntnis erhoffst du dir denn aus deinem Prosawerk?

Im Grunde ist die Antwort ganz einfach: Da sind überall Menschen am Werk und die machen nun mal Fehler - zumal, wenn es um hochkomplexe Systeme geht.
Jegliche Hilfsmittel sind wiederum von Menschen erdacht, die Fehler machen. Nachlässigkeit, Absicht oder Dummheit zu vermuten, ist hier wenig angebracht, obwohl es im Einzelfall immer sein kann, dass ein Fehler drauf zurückgeht, dass einfach jemand einen schlechten Tag hatte.
Überall passieren Fehler, jeden Tag, Massenweise. Warum nicht auch in der Luftfahrt. Bei allem Bemühen, weil jeder weiß, was da dranhängt. Aber vergleiche mal die paar Abstürze mit den knapp 3300 Verkehrstoten jährlich allein in Deutschland (vor allem unter dem Aspekt, dass ein Flugzeug nicht mal eben rechts ranfahren kann, wenn wenn Triebwerk explodiert - und statt 3 Leuten gleich 300 drinsitzen).

Die Prozessoren sind übrigens das geringste Problem. In Flugzeugen werden in der Regel recht alte Prozessoren eingesetzt, deren Eigenschaften und vor allem Fehler man sehr gut kennt. Keiner würde den neuesten i7 in einem Flugzeug verbauen. Viel zu riskant. Im ersten Eurofighter (2003) werkelten u. a. Motorola 68020-Prozessoren von 1984 - also 20 Jahre alte Chips.

Zur Belustigung (weil hier geschickterweise die Fälle mit toten Astronauten ausgelassen wurden): Disintegrating Rockets

[Manf]

Im Gespräch zwischen Piloten und Flugzeugbauern das ich mitbekommen habe, (eigentlich habe ich das wenigste davon mitbekommen,) kommt immerhin die Tendenz heraus, dass man nachdem man es erreicht hat, Flugzeuge stabil fliegen zu lassen, den Schwerpunkt der Entwicklung auf weitere oder eben andere Punkte konzentriert und damit immer mehr auf die Kontolle eines tendenziell instabilen Systems angewiesen ist.

[Hubert.G]

Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers

Wenn man so was liest kommen schon gewisse Bedenken auf. Es muss ja nicht heissen das diese Leute schlecht programmieren. Ob sie aber gewisse fehlerhafte Zusammenhänge erkennen könne wie ein Programmierer mit etwas breiterem Wissen? Kostet aber wahrscheinlich etwas mehr.

[Gnom67]

Ob ein saturierter Entwicklungsingenieur mit 150.000 € Jahresgehalt besser programmieren kann als ein indischer Programmierer, da wäre ich mir nicht so sicher. Außerdem halte ich derartige Meldungen für Polemik. Erstens weiß man nicht, welche Softwareteile wohin fremdvergeben wurden (vielleicht gings da nur um die Leuchanzeige für die besetzte Toilette) und zweitens entbindet es den Auftragsgeber nicht davon, ein sauberes Pflichtenhheft zu erstellen und die Verifizierung kritischer Softwareteile zu gewährleisten. Aber zum Glück kennt der gesunde Volkszorn schon längst die Ursachen und die Schuldigen. Die bösen, gierigen, skrupellosen Unternehmer sind es (bei denen wir Konsumenten unsere Flüge in alle Welt nicht billig genug kaufen können...).

[Holomino]

In https://www.tagesschau.de/wirtschaft/boeing-235.html ist keine Rede von Softwarefehlern. Das das MCAS im Fehlerfall gegen den Piloten arbeitet, scheint ein grundsätzlicher Planungsfehler zu sein.


Was mir als Laie auffällt. es wird immer hur von einem Sensor gesprochen. Muss die Sensorik im Flugbetrieb nicht redundant ausgelegt werden? Ich würde wahrscheinlich auch als Pilot ins Cockpit kotzen, wenn mein künstlicher Horizont und der Höhenmesser den Sinkflug anzeigen, das MCAS aber den Stall misst und das Ruderhorn nach vorne reißt.

[Klebwax]

Nachlässigkeit, Dummheit, Absicht,

Das mag alles mit eine Rolle gespielt haben. Ich denke es war Feigheit. Die MAX ist, so wie ich es verstanden hab, eigentlich nicht flugtauglich. Du schreibst

Beim Flieger wurde offenbar die ursprünglich angestrebte und weitgehend erzielte flugmechanische Stabilität durch die vielen Modifikationen beeinträchtigt und blieb daher kaum handelbar.

Diese "Stabilität" wurde von der Geschäftsleitung nicht primär angestrebt, die MAX sollte mit der gleichen Zulassung fliegen, wie die alte 737. Dabei ging es vordergründig um die Kosten für eine neue Zulassung, ich vermute aber man hatte Angst, die Zulassung für einen ganz neues Flugzeug nur mit viel Zeitaufwand oder gar nicht zu erreichen. Die Regeln sind inzwischen so komplex geworden, daß sie möglicherweise in ihrer Gänze nicht mehr erfüllbar sind, weil sie sich teilweise auch widersprechen. Es hatte aber niemand den Mut, diese einzugestehen. Ich kann das verstehen. Ein Flugzeug zu entwickeln ist beliebig aufwändig und ein Misserfolg, selbst wenn er offenlegt, daß die heutigen Zulassungsregeln nicht vollständig erfüllbar sind, kann selbst eine große Firma ruinieren. Ich hätte die Verantwortung für die Entscheidung, die Triebweke wegen ihrer Größe an einen Ort zu versetzen, an dem sie die Flugstabilität nicht mehr gewährleisten, nicht übernommen. Selbst wenn ich dabei den Job verloren hätte. Die Geschäftsleitung von Boeing hat anders entschieden.

Das ist aber nur ein Teil des Problems.

Ist so ein Programmieraufwand wirklich so unglaublich umfangreich dass offenbar die Orientierung kaum mehr möglich ist?

Ja, so ist es. Eigentlich müsste man nach fünf bis zehn Jahren große Projekte komplett löschen und neu aufsetzen. In den Jahren hat sich soviel toter und auch sinnfreier Code angesammelt, daß er die Mehrheit ausmacht. Aber auch das traut sich keiner, die vorhandenen Systeme müssen ja weiter laufen und damit wird das Gehalt verdient. Es wird also angeflickt und gepfuscht. Als (konstruiertes) Beispiel: Ein neuer Sensor liefert bessere Werte als der alte. Ein Algorithmus kann manchmal mit den Werten nicht umgehen. Man müsste ihn also neu schreiben. Nun wird dieser aber auch an an anderen Stellen benutzt. Die Verantwortung, daß ein modifizierter Algorithmus auch an dieser Stelle kein Problem macht, will keiner übernehmen. Am Ende wird um das Problem herumprogrammiert. Die notwendigen Zulassungen tun ein übriges.

Ich hab auch im kleinen sowas mehrmals erlebt. Es fängt an mit einer Demo, einem Proof of Concept. Die fängt dann an, sich zu verselbständigen und schleppt alle Probleme, die sie als Demo so hat, weiter. Jetzt gibt es die Möglichkeit, um die Probleme herumzuprogrammieren. Dabei entsteht dann ein kaum wartbares Gebilde. Oder man beerdigt diese Programm. Soviel Mut wie Gordon hat kaum einer:

I never intended for wiringPi to be statically linked either – and thanks to the incompetence of many people who have done just this, I’ve had over 10,000 emails from people who upgraded their Pi and found that code stopped working because they were reliant on a system (typically some java/javascript/node or home automation or UPS thing) which had statically linked an older version. This sheer incompetence on their part has saddened and depressed me hugely.

Er hat den Support eingestellt. Das müsste in vielen Fällen auch in kommerziellen System passieren.

Die Prozessoren sind übrigens das geringste Problem. In Flugzeugen werden in der Regel recht alte Prozessoren eingesetzt, deren Eigenschaften und vor allem Fehler man sehr gut kennt. Keiner würde den neuesten i7 in einem Flugzeug verbauen. Viel zu riskant. Im ersten Eurofighter (2003) werkelten u. a. Motorola 68020-Prozessoren von 1984 - also 20 Jahre alte Chips.

Das sehe ich eher als großes Problem. Keiner versteht diese Prozessoren mehr richtig, wenn die ursprünglichen Entwickler in Rente sind. Und ich glaube auch nicht, daß es um das Risiko geht sondern darum, das die Software, übersetzt mit einem 30 Jahre alten Compiler zugelassen ist. Am Ende führt das dazu, daß der Code auf einem modernen Prozessor in einem Emulator läuft. Für die Zulassung bleibt das binäre Image identisch.

MfG Klebwax

[HaWe]

"Nachlässigkeit, Dummheit, Absicht, oder - ein Programmierproblem "
ja, alles das zusammen, beginnend schon bei grundlegenden Konstruktionsproblemen (veränderter Schwerpunkt durch die größeren, anders angebrachten Triebwerke, zusätzlich gefährliches, abruptes Anströmverhalten ab bestimmter Anströmwinkel), und dann aber mehr noch:
Profitgier, gepaart mit grober Fahrlässigkeit, Vorsatz, Zeitdruck und nicht vorhandener externer Kontrolle:
Boeing hat sich ohne die FAA ausschließlich selber "kontrolliert" - bekannte interne Insider-Warnungen und Fehler wurden nicht an die FAA weitergeleitet und nicht nachhaltig behoben, sondern verschwiegen und geheim gehalten, und sogar schon bestehende Hinweise in Handbüchern insb. zum Problemfeld MCAS wurden nachträglich gelöscht.
Zusätzliche Sicherheitssysteme wie weitere Sensoren gab es für die Käufer (Airlines) nur als kostenpflichtige, optionale (teure) Zusatzausstattung, auch verpflichtende Sicherheitstrainings für die Besatzungen im Flugsimulator (inb. zum MCAS) gab es nicht, und noch nicht mal in Handbüchern gab es insb. klar erkennbare Infos zum MCAS Verhalten und dessen Abschaltung.
(Dass die FAA nicht mehr zur eigenen Zulassungs-Prüfung und -Überwachung von Flugzeugen verpflichtet war, ging ja auf ein Trump-Dekret zurück.)
Stattdessen: Zusammenschustern unter Zeit- und Kostendruck um jeden Preis, und dabei Probleme und Risiken unter den Teppich kehren.
In den Medien wurde über all das ja auch wirklich breit berichtet, man braucht nur nach Boeing 737 Max googeln
(- und Berichte über neu bekannt gewordene Probleme reißen ja auch nicht ab...)

[Gnom67]

Das sehe ich eher als großes Problem. Keiner versteht diese Prozessoren mehr richtig, wenn die ursprünglichen Entwickler in Rente sind. Und ich glaube auch nicht, daß es um das Risiko geht sondern darum, das die Software, übersetzt mit einem 30 Jahre alten Compiler zugelassen ist. Am Ende führt das dazu, daß der Code auf einem modernen Prozessor in einem Emulator läuft. Für die Zulassung bleibt das binäre Image identisch.

Wieso soll keiner die alten Prozessoren verstehen? Die haben Register und Befehlssätze und sind ansonsten eine Blackbox. Man weiß aus langer Erfahrung, welche Tücken sie haben und wie zuverlässig sie sind. Und der interne Aufbau einer 386 CPU (275000 Transistoren) ist allemale einfacher zu verstehen als der eines i7 (12 Milliarden Transistoren). Wer wäre denn so risikofreudig (oder deutlicher gesagt so blöd), einen solchen Prozessor zu benutzen oder gar einen alten Prozessor auf einem neuen zu emulieren? Da verstecken sich doch im neuen Prozessor UND im Emulator unabsehbare Risiken. Ich halte das mit den Emulatoren daher für ein Gerücht. Sollte wirklich ein Flugzeugbauer seine alte Software auf Emulatoren und neuen CPUs laufen lassen, dann geschieht es ihm ganz Recht, wenn die Dinger abstürzen.

Man sollte diesen Unternehmen nicht dauernd völlige Blödheit und Arroganz unterstellen. Man muss einfach mal akzeptieren, dass diese Dinge wirklich extrem schwierig sind und dass Menschen nun mal Fehler machen. Die Fehlerfreiheit von Software lässt sich nicht beweisen - das wissen wir spätestens seit Gödel. Fast ein Wunder, dass nicht viel mehr passiert.

[Klebwax]

Wieso soll keiner die alten Prozessoren verstehen? Die haben Register und Befehlssätze und sind ansonsten eine Blackbox.

Schön wärs. Da gabs reihenweise Tricks und Sideefects, die von den Programmierern auch weidlich genutzt wurden. Die Programmierer, die das mal beherscht haben, gibt es nicht mehr. Auch heute findet man viele Programmierer die meinen, man müsste jeden Trick in Assembler verwenden, weil der Code dann etwas kürzer wird. Das gilt aber auch für Hochsprachen. Da wurden rund um das Jahrzweitausend-Problem Cobol Programmierer aus dem Ruhestand reaktiviert,

Und was die Zuverlässigkeit der Bausteine angeht, ist es nicht besser. Diese Prozessoren können nicht mehr gefertigt werden. Die FABs, die diese großen Strukturbreiten fertigen konnten, sind längst außer Betrieb. Und ob das alte Design auf einem mehrfach schnelleren Silizium noch läuft, kann dir niemand versprechen. Mir ist das selbst bei simpler Gatterlogik schon passiert. Die zuletzt gelieferten Chips waren schneller und plötzlich funktionierte die Schaltung nicht mehr. Moderne Prozessoren werden in so hohen Stückzahlen täglich einem Feldtest unterzogen (oder einfacher gesagt benutzt), daß ihre Zuverlässigkeit wesentlich besser beurteilt werden kann.

Sollte wirklich ein Flugzeugbauer seine alte Software auf Emulatoren und neuen CPUs laufen lassen, dann geschieht es ihm ganz Recht, wenn die Dinger abstürzen.

Leicht gesagt, solange du nicht drin sitzt. Ob so was in einem Flugzeug gemacht wird, weiß ich nicht. Es kommt aber aus kompatibilitätsgründen öfter vor, als man denkt. Es gibt genügend Maschinensteuerungen, die an einem Parallelport eines PCs betrieben werden, den es gar nicht mehr gibt. Statt die Anwendung neu zu schreiben wird versucht das ganze mit einem Parallelport Emulator und einem 386-Emulator zum Laufen zu bringen..

Man sollte diesen Unternehmen nicht dauernd völlige Blödheit und Arroganz unterstellen.

Hab ich nicht getan. Ich hab von Feigheit gesprochen. Die Feigheit z.B. zuzugeben, das ein System unwartbar geworden ist. Oder das Konzepte, die mal modern und auch gut waren, durch den technischen Fortschritt nicht mehr tragen. Dies gilt nicht nur für die Produzenten sondern auch für die Gremien, die Normen beschließen.

MfG Klebwax