A400M- Absturz: Mehr Details zu möglichem Softwarefehler
Hinweise auf Softwareprobleme, die am 9. Mai zum Absturz des Airbus A400M-Transportflugzeugs im Mai bei Sevilla geführt haben sollen, hatte es bereits vor drei Wochen gegeben. Die Welt am Sonntag legt jetzt mit neuen Details nach (Link aus bekannten Gründen nicht):
Bereits am Tag vor dem Unfall kam es nach Informationen der „Welt am Sonntag“ nach einem Bodentest zu einer Fehlermeldung zur Software. (…)
Der Fehler blieb jedoch unbemerkt und wurde von den Systemen nicht angezeigt. „Die Lampe stand auf Grün“, heißt es. Im Fehlerprotokoll nach dem Bodentest tauchte nur ein „unspezifisches Problem“ auf.
Daraufhin habe ein Spezialist aus der Endmontage den Vorschriften entsprechend die Triebwerkssoftware neu geladen. Allerdings fehlten diesmal die technischen Basisdaten von drei Triebwerken – was ebenso unbemerkt blieb.
Das deckt sich im Wesentlichen mit der Reuters-Meldung vom 10. Juni. Ich greife es trotzdem mal auf, damit es wieder einen aktuellen A400M-Thread gibt.
(Foto: Techniker bei einem Flug der A400M-Testmaschine MSN006)
Es ist mir einfach völlig unverständlich, dass AB einerseits ein sehr tiefgreifendes (computer aided) fly-by-wire Konzept realisiert hat, das sogenannte „menschliche Fehler“ im Flugbetrieb weitgehend ausschliessen soll; andererseits aber wohl nur ziemlich „magere“ technische bzw. organisatorische Maßnahmen zur Minimierung/Vermeidung menschlicher Fehler bei der Softwarepflege und -änderung eben dieses fly-by-wire-Systems getroffen hat. Es darf einfach nicht vorkommen, dass gem. Vorschrift „ein Spezialist aus der Endmontage“ eine sicherheitskritische Software neu installiert und das Fehl von „technischen Basisdaten von drei Triebwerken“ vor dem Erstflug nicht auffällt. Das ist piss-poor-industrial-engineering und schlicht und einfach unsafe…..allein dafür müßte man AB die Lizenz entziehen, abgesehen davon, dass AB seine fly-by-wire-Philosophie dadurch ad absurdum führt.
Ach Gott ja. Wenn wir nur genug Vorschriften hätten… Dann wäre das Problem erledigt? Ich melde da mal den begründeten Zweifel an. An Vorgaben mangelt es in dieser Industrie nie. Aber an Zeit. Immer läuft alles unter Zeitdruck. Und so wird eben auch mal ein Handgriff gemacht, der so nicht im Manual steht.
Mögliches Szenario:
Da steht also ein Abnahmeflug an, alles steht auf dem Hof und langweilt sich, weil irgend ein Bit noch auf Null steht, statt auf Eins. Der Chef tapert auf und ab und nörgelt dem Elektriker die Ohren voll, er möge den Kleinkram jetzt bitte mal zum Abschluß bringen.
Antwort „Nein, ich muß noch mal den Test durchlaufen lassen“
„Ja, aber das Upload hat doch ok gemeldet“
„Ja, aber laut AMM muß ich noch mal den Test…“
„Sie sind wohl von der Situation überfordert“
„Na gut“
@iltis
Tja, und deshalb darf man sich eben in der „Montage“ eines software-driven-system nicht auf manuals und ihre korrekte Handhabung durch „Spezialisten“ verlassen, sondern man muß konstruktiv-technisch sicherstellen, dass die Montage eben fail-safe ist…….
Es ist doch geradezu paradox, ein System, das die möglichen Fehler anderer Spezialisten (Pilot) im Betrieb ausschliessen soll, quasi „händisch“ montiert. Wenn fly-by-wire, dann auch engineer-by-wire.
@klabautermann: Nein, denn auch das müsste von irgendwem manuell erbaut werden.
Man kommt einfach nicht von der Nummer runter, daß man seinen Job perfekt machen muß, auch wenn einem die Kaufleute mit ihrem ewigen Gequatsche vom Sparen im Genick sitzen. Und dazu braucht es standhafte Techniker bis ganz oben. Also vollkommen aussichtlos…
@iltis
„…… irgendwem manuell erbaut werden.“
Da sind wir in der IT schon etwas weiter, z.Bsp.:
http://www.cedes-sa.com/en/services-support/software/configuration-software-safety/
@klabautermann: Laufen Sie da nicht Gefahr, in die gleiche Technikgläubigkeit zu verfallen wie Airbus beim Layout seiner Flieger?
Ich darf höfflich an meinen Beitrag http://augengeradeaus.net/2015/06/a400m-vor-toedlichem-absturz-triebwerksdaten-geloescht/#comment-201098 aus der „Le Bourget – Woche“ erinnern. Prompt kam danach das, was zu erwarten war.
Man kann kein Programm falsch oder unvollständig installieren; entweder Ja oder Nein.
Man kann aber ein falsches und/oder unvollständiges Programm erfolgreich(*) installieren und wenn dann die in einem Kontext und einer Abhängigkeit stehenden weiteren Programme das nicht merken, ist das Gesamtsystem vom Software-Design „Sch….“ samt der ganzen „AIRBUS-Fly-by-Wire-Philosophie“, welche die Piloten aus (dann nur noch vermeintlichen) Sicherheitsgründen bevormundet!
@klabautermann hat dies sehr konsequent dagestellt.
(* der „Erfolg“ war der Crash)
@iltis 14:29
Mittlerweile hoffe ich nur noch, dass die von ihnen beschriebene Szene so in einem Luftfahrtechnischen Betrieb nicht passieren kann. Ich würde es aber leider auch nicht mehr ausschließen.
Das saubere Abarbeiten der Check Liste bzw. der jeweiligen Handbücher für Wartung/Inst. – nachdem man sich versichert hat, dass diese auf dem aktuellen Stand sind – sollte jedem, der in einem Flugbetriebsbereich arbeitet absolut in Fleisch und Blut übergegangen sein.
@Vtg-Amtmann
Ich bin Embedded Software Entwickler, glauben Sie mir, man kann eine Software falsch oder unvollständig installieren. Das passiert in der Industrie sehr oft. Einfachste Vorgehensweisen werden immer wieder verletzt:
* Datenintegrität vor (Quelle) und nach (Flashspeicher) dem Update sicherstellen
* Eigene Binärintegrität nach dem Booten sicherstellen
* Verifikation, daß in einem System jede Komponente freigegeben ist.
* Plausibilitätsprüfung von Eingabedaten (z.B. Motorkalibrierung)
In der Regel fehlt so etwas, Es wird viel gepfuscht.
@Wuehlmaus: Natürlich haben Sie im Detail recht, aber so tief wollte ich gar nicht einsteigen. Wer die von Ihnen benannten simpelsten Steps nicht als Selbstverständlichkeiten beherrscht, denn danach kann kaum nocht etwas schief gehen, dem sollte die EASA besser gleich den Laden dicht machen.
@Vtg-Amtmann
Ich möchte Sie nur an die Ariane 5 erinnern. Das waren Anfängerfehler:
http://www5.in.tum.de/~huckle/bugs.html
Hier sind auch ein paar interessante Bugs aufgeführt:
https://www.xing.com/communities/posts/10-der-bekanntesten-softwarefehler-1005713529
Das passiert aber nicht nur in der Software. Ist es beim NH90 nicht so, daß trotz anderslautender Anforderungen unterschiedliche Metalle bei Verbindungen benutzt wurden?
@Keng: Ich überlege gerade, wieviel Desillusion Sie vertragen. Vorschriften werden vor allem dazu genutzt, das schwächste Glied in der Kette entscheiden zu lassen, ob sauber oder schnell gearbeitet wird. Das Ergebnis können Sie daran ablesen, wie die Airlines zu kämpfen haben, die sich nicht oder nur sehr begrenzt am „Geiz ist geil“ beteiligen.
Ich kenne (fast) nur Leute, die ihren Urlaubsflieger nach dem Preis aussuchen. Und das tun heute auch die Buchungsportale für die Geschäftsreisenden.
@Wuehlmaus: Stimmt.
Es leuchtet sogar mir als Laien ein, daß man, wenn ein Programm auf eine Datenbasis angewiesen ist und zur Ausführung darauf zugreift, man prüft, ob die Datenbank überhaupt befüllt sind.
Ich habe bereits vor laenger Zeit meine Meinung dazu geaeussert und bleibe dabei:
Versaeumte Endpruefung!
Jemand hat bei der Abnahme der letzten (vorgeschriebenen) software-Pruefung gegen Entgelt (wie in Spanien ueblich, aus Kosten- oder Zeitgruenden – eigentlich das Selbe-) einen Haken mit Unterschrift geleistet ohne geprueft zu haben.
Saemtliche troepfchenweise nunmehr hervorgebrachten Erklaerungen sind Nebelkerzen in diesem Umfeld.
@iltis
Grundsätzliche Zustimmung, dass die Furcht vor Verantwortung und die Praxis der nachfolgenden rechtlichen Betrachtung (im Nachgang, ohne Zeitnot und mit allen nachträglich zugänglichen Informationen), dazu geführt hat, dass man den Kleinsten in der Verantwortungskette henkt.
Beim Vergleich einer (Billig-)Airline mit dem Entwickler eines neuen Lfz muss ich widersprechen. Aus mehreren Sichten.
1. Auch die Airline wird die Herstellervorgaben recht gut einhalten. Sei es, weil sie die Lfz nur geleast hat, weil sie sie nach Benutzung gut weiterverkaufen will oder weil die Gesamtrechnung doch bringt, dass der Verlust für den Investor bei einem Lfz-Verlust mit dem ganzen (Versicherungs-)Nachgang größer ist, als der Gewinn beim sparen an der Wartung.
(Ich würde gerne mal die Kurve der Versicherer sehen, wo die Gesamtkosten pro Lfz bei einem Verlust über die Passagierzahlen aufgetragen sind)
2. AMSL ist aber kein Hersteller, der nur marktgängiges Produkt supportet. Der A400M ist eigentlich noch im Prototypen-Status, Bei gutem Willen in der Einführungsphase. Ich muss also von diesem LTB, der mit einem neuen Produkt punkten muss (Vertragserfüllung), erwarten, dass er wenigstens die interne QS soweit durchsetzen kann, dass er seine Meilensteine erreicht. (und damit seine Kohle bekommt)
(3. Den Punkt Einsatz- und Versorgungsreife heben wir uns lieber für später auf.)
OT:
@ Wuehlmaus | 28. Juni 2015 – 20:47
http://www5.in.tum.de/~huckle/bugs.html
„Ursachen von Software-Bugs
[…]
– Gigantismus
– Unterschaetzen der Aufgabenstellung“
Das erinnert irgendwie an SASPF.
Was das Netz sonst noch so über den Warbus bereit hält.
Bitte selber selber googeln,waren mir zu viele Links…
„temporary deviation a400m“
Zitat: „Im Fehlerprotokoll nach dem Bodentest tauchte nur ein „unspezifisches Problem“ auf“.
Das ist eben das Problem mit den „Built In Test Equipment“-Routinen. Man muss eben die verschiedenen, möglicherweise auftretenden Fehler durch Programmroutinen abfangen und durch entsprechende Meldungen zur Anzeige bringen beim Softwaretest.
Ansonsten hat der Techniker eben nur die Möglichkeit aus der Erfahrung heraus,
a) die Fehlermeldung zu ignorieren, da unerheblich (wurde bei ca. 70 % der Fehlermeldung beim Eurofighter bei der dessen Einführung in die Truppe gemacht), oder
b) aus der Erfahrung heraus zu wissen welche „unspezifische Probleme“ hinter der Fehlermeldung stecken könnten, z.B. der Verlust der Speicherinhalte für die Drehmomentkalibrierdaten und diese dann beheben, oder
c) die Software nochmals zu installieren und dann zu hoffen, dass damit die Fehlermeldung beseitigt ist. Allerdings sollte man in diesem Falle, wenigstens den Softwaretest nochmals laufen lassen um zu verifizieren, dass die Fehlermeldung weg ist.
Nach dem Bericht in dem oben zitierten Artikel der „Welt“, sollen „jeweils zwei Computer ein Triebwerk steuern“ und die Test zeigten für beide Computer den Zustand „in Ordnung“ also „grün“ an.
Wenn dem so ist, dass zwei Computer sich gegenseitig kontrollieren, dann sollte sichergestellt sein, dass sie nicht gleich „falsch“ anzeigen können.
Die Steuerungscomputer sollten mit unterschiedlichen Programmen, von unterschiedlichen Programmierern unabhängig erstellt, bestückt sein, damit ein Programmierfehler durch unterschiedliche Reaktionen auffällt.
Dies scheint hier nicht der Fall gewesen zu sein. Wie man dann noch eine statistische Ausfallwahrscheinlichkeit von 1 * 10E-9 errechnet hat (DAL A), ist für mich nicht nachvollziehbar. Damit ist gleichzeitig nachgewiesen, dass der Absturz eben kein „menschlicher Fehler“ bei der Produktion war, sondern dass die statistische Sicherheit über einen katastrophalen Ausfall der Triebwerkssteuerungen von dem oben erwähnten Ereignis von 1 bei 1 Mrd Flugstunden nicht gegeben ist und dem Absturz somit ein „Konstruktionsfehler“ zugrunde liegt