Nach A400M-Absturz: Airbus ruft zu Kontrolle der Triebwerkssteuerung auf
Nach dem Absturz eines Airbus-Militärtransporters vom Typ A400M bei Sevilla am 9. Mai hat die Herstellerfirma alle Nutzer dieses Flugzeugtyps aufgefordert, die Kontrolleinheiten aller vier Propellertriebwerke ihrer Maschinen zu überprüfen. Vor dem nächsten Flug sollten Checks der Electronic Control Units durchgeführt werden, teilte Airbus Defence&Space nach Unternehmensangaben den Betreibern in einer Alert Operator Transmission, einem dringenden Rundschreiben, mit. Nach Informationen von Spiegel Online wurden bei dem Unfall in Spanien durch einen Softwarefehler drei der vier Triebwerke direkt nach dem Start abgeschaltet.
Die Pressemitteilung von Airbus Defence&Space vom (heutigen) Dienstag dazu:
Airbus Defence and Space has today (Tuesday 19 May) sent an Alert Operator Transmission (AOT) to all operators of the A400M informing them about specific checks to be performed on the fleet.
To avoid potential risks in any future flights, Airbus Defence and Space has informed the operators about necessary actions to take. In addition, these results have immediately been shared with the official investigation team.The AOT requires Operators to perform one-time specific checks of the Electronic Control Units (ECU) on each of the aircraft’s engines before next flight and introduces additional detailed checks to be carried out in the event of any subsequent engine or ECU replacement.
This AOT results from Airbus Defence and Space’s internal analysis and is issued as part of the Continued Airworthiness activities, independently from the on-going Official investigation.
Nachtrag: Nach einem Bericht der Süddeutschen Zeitung (Link aus bekannten Gründen nicht) war in der abgestürzten Maschine eine neue Software-Version installiert, die mit Umpumpen des Treibstoffs eine andere Trimmung und damit militärische Flugmanöver erlauben sollte:
Branchenkreisen zufolge wurde bei dem für die Türkei bestimmten Flugzeug eine neue Software eingeführt, die von Beginn an militärische Manöver erlaubt. Dem Vernehmen nach war diese Software fehlerhaft und verursachte bei dem Erstflug der türkischen Maschine den Ausfall mehrerer Triebwerke. (…)
Den Informationen zufolge erlaubt die neue Software militärische Manöver dadurch, dass die sogenannte Trimmung des Flugzeuges verändert, also der Schwerpunkt verlagert wird. Das geschieht unter anderem, indem Treibstoff von einem Tank in den anderen gepumpt wird.
(Das Thema wird hier bereits im vorangegangenen A400M-Thread heftig debattiert; ich verschiebe die dazu aufgelaufenen Kommentare hierher.)
Offensichtlich weiß man was es war. Der Bordcomputer hat die Triebwerke aufgrund wiedersprüchlicher Daten abgestellt. So berichtet jedenfalls der Spiegel. Überschrift „Software Problem“
tätäääääähhhh. Wer hätte das gedacht.
“ „Es handelt sich sehr wahrscheinlich um ein Qualitätsproblem in unserem Werk“, heißt es aus Airbus-Kreisen. In den letzten Monaten wurde deshalb das gesamte Management der Airbus-Tochter in Sevilla ausgetauscht. “
Wie jetzt? Software oder Management?
ich kenn da einen, der beruflich mit der Software-Entwicklung im Airbus-Umfeld zu tun hat (allerdings die Zivil-Sparte). Der hat mir kürzlich unterhaltsame Geschichten erzählt, die ich jetzt grade gar nicht mehr lustig finde.
Laut aktuellen Agenturmeldungen:
….möglicherweise durch Software-Probleme in der Triebwerkssteuerung verursacht…
Das Management dürfte kaum etwas mit konkreten Software- oder Technikproblemen zu tun haben! Es trägt jedoch letztlich die Verantwortung für das Produkt und die Zusammenarbeit aller Beteiligten. Die üblichen Bauernopfer also.
Management!
Das Management hat(te) es nicht verstanden, die Arbeit/Qualität der Beauftragten
Sub-Unternehmer und Leiharbeiter sorgfältig zu überprüfen!
So sehe ich das zumindest aus meiner ‚Froschperspektive‘
Wie war das nochmal mit „Zwangsabschaltung gibt es nicht“?
Nachtrag: was mich wundert, das Schema der Flugerprobung ist doch vorgeschrieben, somit muß das doch schon ein paar Mal so abgeflogen worden sein. Irgendwelche „verrückten Dinge“ am Grenzbereich werden auch nicht gemacht worden sein.
Also setzt sich jetzt die Fehlerursache „latenter Softwarefehler“ bei der Triebwerkssteuerung FADEC durch.
Ich hatte dazu am 10. Mai schon ein paar Zeilen geschrieben.
http://augengeradeaus.net/2015/05/vier-tote-bei-absturz-von-a400m-militaertransporter-waehrend-eines-testflugs-zusammenfassung/comment-page-2/#comment-195883
Die Triebwerkssteuerung umfasst laut Untersuchungsbericht des französischen Senats 275.000 Anweisungen Programmiercode. Dies ist dreimal soviel wie für den A 380 (90.000 Zeilen). Der Grund dafür ist die umfangreiche Propellorsteuerung die in dieser Software mit integriert worden ist.
Laut einer durchgeführten Untersuchungsreihe bei „open source“- Software befindet sich alle 4000 Anweisung ein versteckter Fehler im System. Damit kann man das Fehlerpotential der Triebwerkssteuerung ermessen.
Um mal eine Vorstellung zu haben unter welchen Umständen das Triebwerk und die Softwaresteuerung u.a. von der Fa. MTU entwickelt worden ist, lese man mal die Insiderberichte des Kommentators „koenigstiger“ Nr. 1745,1746 und 1750 in dem Blog Flugzeugforum.
http://www.flugzeugforum.de/threads/58109-Airbus-Military-A400M-News/page175
Außerdem sieht die Konstruktion des A400M genauso wie bei der A380 ein Bordcomputernetz auf einer erweiterten Eternet Verkabelung (Avionic Full DupleX, AFDX) vor, wo die von den Zuliefereren hergestellten Systeme über ein Schnittstelle integriert werden, wie Windows Anwendungsprogramme laufen lässt. Wenn ein Programm sich aufhängt, wird es das Betriebssystem abschalten und die Anwendung muss neu gestartet werden. Dies ist ja bei dem offiziellen Erstflug der A400M schon als Fehler berichtet worden.
Siehe hierzu die Seite 17 (Integrationswolke) und die Seite 32 der verlinkten Airbus-Präsentation über „Integrated Module Avioncs“ ( IMA)
hDDp://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_Itier.pdf
und auf der Seite 36, 37 wird etwas zu der Qualifizierung der Subsysteme geschrieben. Das heißt für mich, wenn die Module auf dem Betriebssystem des Airbus A400M laufen, dann sind sie auch qualifiziert dort eingesetzt zu werden.
(Siehe hierzu auch den Kommentar von @ klabautermann zum Unterschied der Bedeutung von „Verifizierung“ und „Validierung“ eines Produktes gemäß gültigen ISO-Standards)
Alles in allem stellen m.M.n nach latente Softwarefehler und die mangelhafte Schnittstelle Mensch(Pilot) zum Computersystem moderner Flugzeuge die größten Fehlerursachen dar.
@ es-will-meh….
Zitat: „Der Fehler liegt also nicht nur in der Software, er liegt eigentlich in der Über-Automatisierung des Gesamtentwurfs des Flugzeugs.“
Genauso ist es! Siehe auch Airbus, Lufthansaunfall im Landeanflug von Warschau 1997
und Airbusabsturz im Mühlhausen beim Flugtag
Dabei unterscheiden sich aber Airbus und Boing in ihrer Strategie.
Airbus setzt auf Vollautomatik unter Umgehung des Piloten. Boeing schlägt dem Piloten die Änderung vor und der entscheidet ob er das tut, was der Computer im vorschlägt.
Leider hat DER SPIEGEL in seinem jüngsten Report von heute etwas zu légère formuliert und damit auch den Knackpunkt „EASA-Musterzulassung“ nicht deutlich genug angesprochen.
Streiche in http://www.spiegel.de/politik/ausland/airbus-a400m-militaermaschine-stuerzte-wegen-software-problemen-ab-a-1034421.html gedanklich:
Man habe mit der europäischen Flugaufsichtsbehörde EASA Gespräche geführt und die Beamten dort überzeugen können, dass die Fluggenehmigung für den A400M nicht aufgehoben wird
Setze gedanklich:
Man habe mit der Europäischen Agentur für Flugsicherheit EASA (EASA; englisch „European Aviation Safety Agency“) Flugaufsichtsbehörde EASA Gespräche geführt und die Beamten dort überzeugen können, dass die Musterzulassung gemäß TYPE-CERTIFICATE DATA SHEET No. EASA.A.169 für den AIRBUS A400M des Type Certificate Holder: Airbus Military Sociedad Limitada (AMSL), nicht zurückgezogen wird.
(vgl. http://www.easa.europa.eu/system/files/dfu/EASA-TCDS-A.169_Airbus_A400M-04-17072013.pdf)
Dann wäre nämlich aufgrund des „Commercial Approach“ der A400M weg von der Bildfläche, weil er nicht mehr gefertigt und auch nicht mehr geflogen werden dürfte! Es gibt nämlich keinerlei militärische Zulassung für den Flieger; nur für dessen militärische Ausrüstung und damit hat die EASA nichts am Hut.
Gleiches gilt für die Musterzulassung der Triebwerke samt Peripherie (vgl HDDP://easa.europa.eu/system/files/dfu/TCDS_E033_Issue%2006_1.0_0.pdf) und auch für die ebenfalls EASA-zugelassenen Propeller, nur ohne Engines und Flieger „fliegen“ die Propeller dann auch nicht mehr.
Eigentlich müßten die Nutzernationen über den „Commercial Approach“ beim A400M jetzt so richtig glücklich sein, denn die EASA läßt sich nicht so einfach über den Tisch ziehen und/oder auf Dauer vertrösten. AIRBUS muß jetzt schon Fundamentales zur Fehlerabstellung vorlegen und die „AMC and GM to Part 21 – Acceptable Means of Compliance and Guidance Material“ der EASA lassen denn vielleicht auch noch grüßen.
So Spielchen wie zwischen LufABw und AiRBUS beim NH90 funktionieren bei der EASA mit Garantie nicht, da kann man sich sicher sein!
————————————————————
(Zum „Commercial Approach“ vgl. HDDP://www.bundeswehr-journal.de/wp-content/uploads/2013/08/Spiegel-Anfrage-A400M.pdf)
Also ein Fehler auf 4000 Code-Zeilen ist eigentlich ein sehr stabiles Programm, denn in der Informatik gilt ein Programm, das 0,5 Fehler auf 1000 Code-Zeilen hat als stabil…….so hab ich das jedenfalls mal gelernt in computer science 4030 ;-)
Falls wir hier also eine Systemfehler-Kaskade haben, die vmtl. durch ein Versagen der Fahrwerkssteuerung ausgelöst wurde, dann liegt das weniger an der software an sich, sondern an der load tolerance, bzw, einer fehlenden/unzureichenden load balance im System, denn man sollte nicht vergessen, dass bei Start und Landung die Steuer-und Regeldichte (d.h. die Datenverarbeitungslast) besonders hoch ist……und damit wären wir mal wieder beim Thema Komplexität und deren Beherrschbarkeit, bzw. der erforderlichen Proportionalität der Komplexität (Qualität/Quantität) der Steuer-und Regel-Ressourcen zur Komplexität des zu steuernden Systems. Diese Proporionalität kann man nur näherungsweise berechnen, und deswegen braucht man protoptypische Referenzsysteme, mit denen man das Belastungsverhalten des Systems simulieren/ertesten kann. Dies ist dann besonders wichtig, wenn zu erwarten ist, dass aufgrund der physikalischen „Raum-/Zeitfaktoren“ der Mensch als Steuerinstanz keine Chance mehr hat. Insofern bin ich durchaus ein Befürworter von Automatisierung.
@Vtg-Amtmann
tja, da lag ich wohl mit meinen gestrigen Kommentaren nicht völlig daneben ;-)
Zitat aus dem Spiegel Artikel:
„Am Dienstag versandte Airbus an alle Kunden des A400M eine eindringliche Alarmmeldung. Laut der sogenannten „Alert Operator Transmission“ (AOT) können die erkannten Softwareprobleme zu einem „Ausfall der Triebwerkskontrolle“ führen. Deswegen habe Airbus alle Kunden über „notwendige Aktionen“ informiert, um dem Problem zu begegnen.“
dazu lege sich man die Berichterstattung über den 27 Jahre alten A320 Mülhausen Absturz daneben aus:
http://www.austrianwings.info/2013/06/erster-a320-absturz-vor-25-jahren/
Zitat: „Eine externe Untersuchung schien im zumindest teilweise Recht zu geben. Denn sie deckte auf, dass der europäische Flugzeughersteller Airbus in dem Monat vor dem Unfall zwei so genannte Operational Engineering Bulletins (OEB) heraus gegeben hatte, die über ein anomales Verhalten des A320 im Flugbetrieb berichteten. Doch davon wussten Asseline und Mazieres nichts, denn Air France verschickte diese Bulletins erst nach dem Unfall an all ihre Piloten.
Darin hieß es, dass die Triebwerke eventuell nicht sofort reagieren, wenn bei sehr niedriger Höhe plötzlich voller Schub gegeben wird – genau dieses Verhalten der Turbinen hatte Asseline vor der Untersuchungskommission ausgesagt.“
Kann man da Zusammenhänge in der Vorgehensweise sehen ?
und weiter hieß es zu den Flugschreibern der A320 beim Mühlhausen Absturz:
Zitat: „Auffällig war auch, dass die die letzten Sekunden vor dem Absturz auf dem Band fehlten. Ein Gericht kam daher zu dem Schluss, dass die Flugschreiber kurz nach dem Absturz manipuliert wurden.“
Ebenfalls Parallelen ?
Bis jetzt scheint ja alles noch sehr inoffiziell zu sein. Ein Softwareproblem in der Triebwerksteuerung allein erklärt meiner Meinung nach den Hergang der Ereignisse nicht. Gab es ein Problem mit dem Fahrwerk und den Klappen? Welches? Wo sind die Schnittstellen?
Wurde bei MSN 23 eine andere Softwareversion installiert als bei den anderen Maschinen? Wohl nicht. Denn nach einer Meldung des ZDF hat Airbus die Nutzer aufgerufen die Triebwerksteuerungssoftware bei den ausgelieferten A400M zu überprüfen?
Merkwürdig ist auch, dass die Info wohl aus dem Bereich Airbus und nicht aus dem Bereich der untersuchenden Stellen kommt. Von so einem kleinen Softwarefehler bis zur Einzelfalleinstufung ist es nur ein kleiner Schritt und rettet die Zulassung.
Die grundsätzliche Diskussion über die Konzepte von Airbus und Boing sind interessant, aber nur im Kontext von Zulassungsfragen.
Daher: Kann es sein, dass ein Luftfahrzeug eine technische Zulassung bekommt, wenn ein kleiner Softwarefehler derart katastrophale Auswirkungen haben kann? Kann es sein, dass ein Luftfahrzeug eine Zulassung behält, wenn das Kontrollpersonal im Cockpit das Luftfahrzeug technisch gar nicht kontrollieren kann? usw,usw…
@klabautermann: Das war mir schon gestern klar, deshalb habe ich Uhnen auch beigepflichtet
Übrigens, DER SPIEGEL – dessen Redakteur Gerald Traufetter – hat nochmals ein Video nachgelegt; harte Worte fallen da (vgl. http://www.spiegel.de/video/airbus-a400m-militaerbus-stuerzte-wegen-software-ab-video-video-1578564.html).
Was bei dem Ganzen erstaunt, daß es „nur“ zwei widersprüchliche Befehle gegeben haben soll, die gleich zum Ausfall aller drei Triebwerke führten? Das spricht wiederum für einen unmittelbaren Einfluß des FMS auf die FADEC-Systeme der Triebwerke und müßte völlig unabhängig vom tankspezifischen Fuel-Management gesehen werden.
@ schleppi
Ja, ein Flugzeug kann eine Zulassung bekommen wenn ein Softwarefehler vorliegt, weil der Softwarefehler „latent“ ist, und erst in einer ganz bestimmten Konstellation seine Auswirkung zeigt.
siehe Absturz Lauda Air über Thailand durch ungewollte Schubumkehr in Reiseflughöhe (diesmal Boeing, damit nicht der Eindruck entsteht es soll nur Airbus angeklagt werden).
Mich würden „die notwendigen Aktionen, die dem Problem begegnen“ interessieren…..wenn schon zwei widersprüchliche Steuer-Befehle dazu führen, dass die gesamte Triebwerksteuerung in einen instabilen Zustand gerät, dann schwant mir nur ganz Übles in Sachen Systembelastbarkeit und -stabilität………..
@ Georg
Die Formulierung „kann es sein“ war im Sinne von „darf“ benutzt. Ich denke, es darf nicht sein. Es macht wenig Sinn durch redundante Auslegung aller möglichen vitalen Systeme den Eindruck größtmöglicher Sicherheit zu schaffen und eine fehlerhafte Programmanweisung, die latent ein katastrophales Risiko beinhaltet bewirkt den Absturz der Maschine.
Wenn die Informationen so richtig sind, bedeutet es doch nichts weiter, als dass bei der Programmierung der Software mindestens eine Konstellation nicht gedacht wurde. Dafür gibt es aber keine Redundanz. Welche Konstellationen wurden noch nicht gedacht?
Bei solchen Systemen basiert doch die Zulassung augenscheinlich lediglich auf der Annahme, dass alle möglichen Fehlerkonstellationen in der Programmierung berücksichtigt wurden.
@ Vtg-Amtmann
Zitat: „Was bei dem Ganzen erstaunt, daß es “nur” zwei widersprüchliche Befehle gegeben haben soll, die gleich zum Ausfall aller drei Triebwerke führten? Das spricht wiederum für einen unmittelbaren Einfluß des FMS auf die FADEC-Systeme der Triebwerke und müßte völlig unabhängig vom tankspezifischen Fuel-Management gesehen werden.“
Ja, natürlich das Flight-Management-System oder bordeigene Computersystem des A400M steuert über das AFDX-Netzwerk, die Bordcomputer mit dem ARINC 653 Betriebssystem alle Flugzeugsubsysteme wie man der Grafik „ADCN Network & Topology“ auf Seite 17 der oben verlinkten Airbus-Präsentation über Integrated Modular Avionics (IMA) sehen kann.
Der Vollständigkeit hier nochmal eingefügt.
http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_Itier.pdf
Das Bordcomputer steuert über das Netzwerk die Triebwerke, die Kraftstoffanlage, das Fahrwerk, die elektrische Energieversorgung, die Kabine (Temperatur, Kühlung, Umweltbedingungen), und die Flight Control Computer.
Dies alles über ein redundantes 100 MBit Netzwerk mit direkter Adressierung der Empfängerkomponenten (über Virtual Links) bei zugesicherter Bandbreite der Übertragung und dies ganze biderektional, d. h. eine Leitung vom Subsystem zum Computer und eine zweite Leitung vom Computer zum Subsystem (hier also die FADEC-Steuerung mit 270.000 Zeilen Programmcode). Bidirektional ist das Netzwerk, damit es keine Datenkollision auf der Leitung gibt, weil wenn zwei Systeme gleichzeitig senden und so die Übertragungsgeschwindigkeit wegen einer möglichen Datenkollision und der notwendigen Wiederholung der Übertragung reduziert werden würde.
Außerdem ist das Netzwerk und der Bordcomputer „deterministisch“, d.h. bei gleichen Eingangssignalen erfolgt die Übertragung immer über den gleichen Übertragungsweg (Weg über die verschiedenen Netzwerkbridges) und ergibt garantiert das gleiche Ergebnis (andernfalls stelle ich mir auch eine Suche nach einem Übertragungsfehler im Netzwerk als extrem schwierig vor).
Wie schon mal festgestellt ist der A400M, ebenso wie andere moderne Flugzeuge, ein Computer mit Triebwerk und Flügeln
@ Schleppi
Ich bin kein Programmierer, aber man kann nie alle möglichen Fehlerursachen in einer Computerprogrammentwicklung abfangen. Es wird immer zu Programmabstürzen kommen, aber die müssen abgefangen werden und das Programm mit den Parametern der letzten Einstellung neu gestartet werden.
Aus Gründen der Systemverträglichkeit und damit ein hängendes Subsystem nicht den ganzen Flieger blockieren kann, ist diese Möglichkeit ja in dem Bordcomputersystem (wie auf Seite 32 der IMA-Präsentation dargestellt) auch ausdrücklich vorgesehen.
„Overruns are prevented, partition is suspended“.
Gemeint ist, wenn ein Anwendungsprogramm z.B. FADEC sich nicht an die Zeitvorgaben hält (zugewiesene Rechenzeit als Time-slot überschritten) kommt das Betriebssystem und beendet die Anwendung. Nach meinem Verständnis muss die Anwendung dann neu gestartet werden, ob manuell oder automatisch das weiß ich nicht.
@schleppi
1. Es liegt „in der Natur der Sache“, dass es zu 100 % fehlerfreien sotware-code nicht gibt, das ist wie mit dem Druckfehler
2. Selbst wenn ich alle software-Fehler tatsächlich beseitige, dann kommt die „Natur der Sache“ mit Namen Komplexität ins Spiel, was letztendlich nichts anderes meint, dass ich alle möglichen Systemzustände nicht mathematisch exakt berechnen und beschreiben kann, sondern nur schätzen/empirisch ermittlen kann.
3. Aus 2. folgt, dass der Automatisierungs-/Integrationsgrad eines komplexen Steuer-und Regelsystem ein Risikofaktor an sich darstellt, dem man konstruktiv und entwicklungstechnisch besondere Aufmerksamkeit schenken muß – und da prallen dann oftmals Kybernetik-Denkschulen aufeinander: die einen sind der Meinung, das System sollte nur so weit automatisiert sein, dass es den Piloten weitestgehend (vor allem kognitiv) entlastet, und die anderen meinen eben, die Automatisierung sollte so weit getrieben werden, dass der Pilot eigentlich überflüssig ist.
Die Vertreter der 2. Schule sind aber – commercial approach – leider nicht immer bereit, die Konsequenzen aus meinem 3. Punkt auch wirklich zu ziehen………..
@ Georg
Zwei Testpiloten und drei Testingenieure an Bord. Keiner hatte einen Plan, wie das Problem zu beheben war. Ich denke mit einer „einfachen“ Neustartlösung wäre jemand darauf gekommen. Das Cockpit wollte wohl bis zum Schluss nicht auf einem Acker landen. „No llegamos a la Pista“. Vielleicht gab es dafür aber auch einen anderen Grund.
Es bleibt spannend.
@Georg
…..und wenn das Betriebssystem die Anwendung beendet und diese (weil sicherheitskritisch) sofort prioritär wieder neu startet, dann haben wir zwei conflicting interrupts und die Laufzeitumgebung geht u.U. in eine Schleife und wir haben den Salat……..dass andere Anwendungen nicht mehr in Gänze auf die entralen Rechner-Ressourcen zugreifen können……
@ Schleppi
Manchmal ist auch ein Zeitfaktor. Der Mensch denkt langsamer wie eine Maschine, vor allen Dingen wenn er überlegen muss wie er eine Maschine überlisten kann.
Ich hatte schon in einen älteren Beitrag einen Art „Not-Aus“ -Schalter für den Computer gefordert, damit man in einer kritischen Situation eine Art „Manual override“ ohne viel Nachdenken erreichen kann.
Haben Sie meinen Link zum Blog „Flugzeugforum“ des Kommentators „Koenigstiger“ zu den Entwicklungsproblemen des FADEC und des Triebwerks bei MTU gelesen ?
@ klabautermann
Einverstanden. Aber dann muss man es auch auf den Kern führen: Dient die Automatisierung der Sicherheit oder der Wirtschaftlichkeit? Zulassungsfragen sind in erster Linie Fragen der Sicherheit. Jeder, der einen Pc besitzt, weiß, dass es in der Regel keine fehlerfreie Software gibt. Und der häufigste Rat des Softwareexperten, wenn er um eine Problemlösung gebeten wird ist „neu starten“. Im Flugbetrieb sollten andere Kriterien gelten.
@ Georg
Jo, war selbst eine Zeit lang bei der Occar. Aber da wird ein Fass aufgemacht…….
Die Zulassungsbehörden hätten aus meiner Sicht genau diese „Not-Aus“ Möglichkeit fordern müssen. Mit all den komplexen technischen Erfordernissen der Realisierung.
@Georg: Die Grafik “ADCN Network & Topology” auf Seite 17 der verlinkten Airbus-Präsentation über Integrated Modular Avionics (IMA) wurde bzw. ist sehr wohl verstanden. Mich hatte nur bei meinem Beitrag http://augengeradeaus.net/2015/05/spanien-stoppt-testfluege-mit-dem-a400m/comment-page-3/#comment-197202 im 3ten Absatz der gleiche Gedanke geritten wie @klabautermann in http://augengeradeaus.net/2015/05/spanien-stoppt-testfluege-mit-dem-a400m/comment-page-3/#comment-197207.
“… .wenn schon [nur] zwei widersprüchliche Steuer-Befehle dazu führen, dass die gesamte Triebwerksteuerung in einen instabilen Zustand gerät, dann schwant mir nur ganz Übles in Sachen Systembelastbarkeit und –stabilität …“
Ergo ändere man das System sofort und ohne jegliche Verzögerungen. Bis das nicht geändet ist, fliegt der Vogel nicht, auch nicht beim Militär, oder alternativ trete man den Vogel komplett in die Tonne!
Man stelle sich mal vor der A400M MSN 023 wäre statt für die Türkische Luftwaffe für Federal Express, DHL oder LH-Cargo geordert gewesen!? Da sehe ich vor meinem geistigen Auge Major Tom zwar nicht im Job-Center, aber als Frühpensionär.
@schleppi
Ich bin da ganz bei Ihnen………ich bin schon seit Jahren der Auffassung, dass System-of-Systems-Architekturen anfälliger sind als Family-of-Systems-Architekturen, bei denen die Untersysteme eben nicht um die Ressourcen einer zentralen Steuer-und Regel-Instanz buhlen müssen. Solche Architekturen sind aber „teuer“, denn man braucht mehr Ressourcen wie Kabel etc, das geht wieder aufs Gewicht usw. usw.
Wie gesagt: das ist in Teilen fast schon eine Glaubensfrage geworden……
@ Vtg-Amtmann
Okay, dann habe ich ihre Äußerung missinterpretiert.
Das Video vom Spiegel mit der Aussage nur „zwei widersprüchliche Steuer-Befehle führten dazu, dass die gesamte Triebwerkssteuerung instabil wurde“ läuft bei meinem Rechner gerade nicht. Weiß nicht woran dass wieder liegt.
Die Aussage von Airbus laut Spiegel:
„“Es handelt sich sehr wahrscheinlich um ein Qualitätsproblem in unserem Werk“, heißt es aus Airbus-Kreisen. In den letzten Monaten wurde deshalb das gesamte Management der Airbus-Tochter in Sevilla ausgetauscht.“
bringt aber meiner Meinung nach die Sache auch nicht weiter. Hier wird nur nochmals auf ein bereits vor Monaten erfolgtes Bauernopfer hingewiesen, denn das Qualitätsproblem liegt in der Integration und in der Fehlerfreiheit der FADEC-Software und dies ist ein ingenenieurtechnisches Problem in der Entwicklung und nicht ob irgendwelche Leiharbeiter in Sevilla ein Flugzeug zusammengebaut haben.
Hier haben wir aber auch einen entscheidenden Punkt erreicht der mich zuerst zur Frage führt : ist der A400M auch ein fly-by-wire Produkt ?
Denn dann wird auch zur Flugsteuerung die Frage eines „override buttons“ eine im Detail schwer zu klärende sein ! Haben wir doch schon von anderen Mustern mit Rotoren von nicht gedachten Problemen mit ziemlich glücklichem Ausgang gehört … Emergency Generatoren die plötzlich in sich kollabierten und eine Regeleinheit zutage förderten die den Technikern unbekannt war, Fehlerspeicher in Triebwerken die Technikern unbekannt waren, Kabelbrand in einer Main Avionic Bay der nicht vorstellbar schien …
… man bekommt langsam Angst ob des QM und der Zulassungssichherheit durch die Behörden bei den Airbus-Vögeln !!!
@Schleppi
Welches Fass würde man denn öffnen mit den Kenntnissen aus OCCAR-Zeit ?
Nachtrag: Oder die Techniker in Sevilla haben die falsche Softwareversion für die FADEC oder den Treiber aufgespielt.
Dies würde die o.a. Vordringliche Technische Anweisung von Airbus erklären, nach dem Motto „schaut euch mal die Versionsnummer der aufgespielten FADEC Software an und überprüft ob die mit der Versionsnummer des Triebwerks kompatibel ist, gemäß beigefügter Liste und Technischen Handbuch“.
@ Georg
Nur um das mal zu ordnen:
– Laut Airbus liegt der Fehler in der Electronic Control Unit (ECU).
– Laut Airbus handelt es sich um ein Qualitätsproblem bei Airbus. Also fehlerhafte Umsetzung der Ingenieurs-Vorgaben (so würde ich das zumindest verstehen).
– ECU und FADEC sind verschieden Systeme, die miteinander kommunizieren.
Wie kommen Sie nun auf die Idee, dass da ein Problem mit der FADEC (Full Authority Digital Engine Control) vorliegen soll?
So wie ich das verstehe, bekommt die FADEC von der ECU gesagt, was sie machen soll. Und wenn die ECU sagt: Triebwerk abschalten und die FADEC das befehlsgemäß umsetzt, dann mag die ECU Mist gebaut haben. Aber was soll an der FADEC nicht stimmen?
Und die Aussage „Es handelt sich sehr wahrscheinlich um ein Qualitätsproblem in unserem Werk“ deutet doch sehr darauf hin, dass man (in Sevilla?) fehlerhaft (ein)gebaut hat, und eben kein Design-Fehler vorliegt. Oder wie ist das zu verstehen?
@ Georg
Mir erscheint der Schritt „schaut nach ob Servicepack XY drauf ist“ als deutlich zu kurz gesprungen !
Es fallen mir doch wichtige Fragen zur Integrität der Systemarchitektur auf …
Die FADEC-S/W kommt von MTU…
@ Freiherr von Stein
Nach meinem Verständnis ist die FADEC (Full Authority Digital Engine Control) gleich der ECU (Electronic Control Unit) und der EPMU (Electronic Protection and Monitoring Unit) und deren Software.
Falls dem nicht so sein sollte, erklären Sie es bitte wie es richtig ist.
Bei FADEC und ECU verwechseln sie meiner Meinung nach Oberbegriff mit Unterbegriff.
FADEC oder auch „Einhebel-Triebwerksbedienung“, setzt voraus dass alle Triebwerks- und Flugparameter ständig erfasst, verarbeitet (ECU + Software) und an das Triebwerk weitergeleitet werden. EPMU protokolliert alle Triebwerksdaten und stellte sie zur Wartung zur Verfügung und schützt das Triebwerk vor Überbeanspruchung.
Zitat aus einem Firmenprospekt von EPI Europrop International GmbH
„MTU is responsible for the TP400-D6’s
intermediate-pressure compressor,
intermediate-pressure turbine and
intermediate-pressure shaft, the engine
protection and monitoring unit (EPMU)
and the engine control software.“
@ SER
Zitat: „Mir erscheint der Schritt “schaut nach ob Servicepack XY drauf ist” als deutlich zu kurz gesprungen !
Es fallen mir doch wichtige Fragen zur Integrität der Systemarchitektur auf …“
Schon möglich, aber dann wäre es kein Fehler von Airbus in Sevilla bei der Montage, sondern ein Fehler der Entwicklungsabteilung.
Die Schwierigkeit mit Software ist, dass es bis heute noch kaum geeignete Methoden für deren Qualitätssicherung gibt. Wenn man sich eine DO-178B oder auch eine EN 64508 ansieht, stellt man sehr schnell fest, dass dort versucht wird die Methoden aus der Hardware-Fertigung mehr oder weniger auf Software zu übertragen. Das klappt aber leider nur sehr bedingt.
„Software zu Prüfen ist ungefähr so, als bekäme man den Auftrag alle Kriminellen in einer Stadt zu finden, von denen man nicht weis wieviele es gibt und an welchen Merkmalen man sie erkennen kann“ (freies Zitat, Author weis ich nicht mehr).
Das Zitat trifft das Problem aber ziemlich genau.
In der Luftfahrt ist man was funktionale Sicherheit angeht bereits sehr weit, aber sicherlich nicht perfekt. Wenn man sich andere Industriezweige ansieht (z.B. Automotive) schaut es mit der funktionalen Sicherheit schon wirklich übel aus.
Obwohl ich weis dass Flugzeuge fehlerhaft sind, traue ich Ihnen immer noch mehr als jedem modernen PKW, LKW oder Zug. In der Luftfahrt wird das Thema einigermaßen ernst genommen, bei den anderen Industrien muss hier noch viel mehr Umdenken statt finden.
Fazit ist, dass funktionale Sicherheit an Bedeutung zunehmen wird. Wir müssen gerade für die Software-Anteile viel mehr Forschungsaufwände in die QS-Methoden investieren und die einschlägigen Standards müssen auch überarbeitet werden.
Viel wichtiger ist aber ein Umdenken in den Köpfen der Industrie (vor allem außerhalb der Luftfahrt), damit das Thema die Aufmerksamkeit bekommt die es braucht.
@ Georg | 19. Mai 2015 – 18:23
Anscheinend werden hier Begriffe unscharf benutzt/durcheinander geworfen.
Eine ECU (klassisch) gibt es beim TP400 nicht mehr, denn man steuert wesentlich mehr und autonomer und nennt das dann FADEC.
Die Steuereinheit, die der Triebwerksteuerung (FADEC) Steuerkommandos erteilt, will man offenbar nicht benennen und nennt das deswegen allgemein „Electronic Control Unit“ – so vermute ich mal.
Wenn da was mit „umpumpen von Sprit“ in den Fehler involviert war, wie vermeldet wurde, dann muss das eine „übergeordnete“ Steuereinheit sein und nicht die FADEC.
@ Georg
Quod esset demonstrandum !
… und wir haben uns noch nicht um die Fragen der Güteprüfer gekümmert ! Wenn Prüfer in der Luftfahrt oft nicht wissen was verbaut ist (wie Speicherbausteine oder wie von mir angesprochen Regeleinheiten in Notgeneratoren), wie vertrauensvoll muß man da den Güteprüfern entgegenkommen aufgrund welcher Fakten ? Vollständige Dokumentation des Herstellers ? Wohl kaum. die hätten sonst auch die normalen Prüfer, oder ?
Oder welchen Grund sollte es geben das es verschiedene Dokumentationen gibt ?
MatErhalt Level XY wegen Geld ? Eine Variante wo ich in der Wartung sagen könnte ok, aber nicht bei Fragen der Sicherheit !!!
Wie soll etwas auf Korrektheit überwacht werden, wenn der Techniker nicht weiß was abnormal oder doch noch normal ist ??? Und das bei momentan bei anderen Flugzeugen deutlich lückenhaften und auch fehlerhaften Dokumentationen …
Das ist m.M.n nicht so schwer. Die FADEC wird von dem Bordcomputernetzwerk angesprochen und bekommt die gewünschten Leistungseinstellungen mitgeteilt. Wobei nach dem Pilot report auf der aviation week, die Triebwerkssteuerung so vereinfacht worden ist, dass man nur noch „Start“, „Leerlauf“ usw. einstellt und damit dann auch die Propellordrehzahl eingestellt wird. Das Bordcomputernetzwerk, das ich weiter oben beschrieben habe, gibt die Leistungseinstellung dann über das AFDX Netzwerk an die Triebwerkssteuereinheit (nennen Sie es FADEC oder ECU und EPMU) weiter und dieses Subsystem führt die Befehle aus und für die Anzeigen im Cockpit geht es den umgekehrten Weg.
Das „umpumpen von Sprit“ wird ebenfalls über das Bordcomputernetz mit dem ARINC 653 Betriebssystem gesteuert. Bis jetzt habe ich aber nichts gelesen, dass dies fehlerursächlich gewesen sein soll.
@TW
Muss das nicht 09. Mai heissen?
@all
Habe oben zusätzliche Infos der SZ nachgetragen.
@KlausK
Ups, ja. Danke, ist korrigiert.
@TW
09. Mail???
Grr.
So lange nicht das konkrete „Alert Operator Transmission (AOT) to A400M“ von AIRBUS publik ist, samt aller darin konkret benannten „notwendigen Aktionen“, also die definitiven Prüf- und/oder Austausch-Maßnahmen nicht im Originaltext vorliegen, diskutieren wir um den heißen Brei, aber nicht darüber, warum, wo und weshalb dieser angebrannt ist!
Alles andere sind Nebelkerzen für die Medien und die Öffentlichkeit, die auf Pressemitteilungen der AIRBUS und deren Multiplikation beruhen sowie auf Schadensminimierung in Sachen Reputaion abstellen, aber es sind eben keine technisch harten Fakten (vgl. http://www.defense-aerospace.com/articles-view/release/3/163777/***-airbus-orders-checks-of-a400m-engine-controls-%3Ci%3E%28updated%29%3C%C2%A7i%3E.html & http://www.bloomberg.com/news/articles/2015-05-19/airbus-tells-a400m-users-to-check-engine-controls-after-crash).
@ SER
Zitat: „Wie soll etwas auf Korrektheit überwacht werden, wenn der Techniker nicht weiß was abnormal oder doch noch normal ist ??? Und das bei momentan bei anderen Flugzeugen deutlich lückenhaften und auch fehlerhaften Dokumentationen …“
Dokumentation ist sehr wichtig und muss von wirklichen Fachleuten erstellt werden. In der Industrie wird dies oft nicht von den Fachleuten erstellt. Lückenhafte oder fehlende Dokumentation eines Luftfahrzeuges darf es nicht geben, allerdings muss man bereit sein auch die Kosten für eine Dokumentationsabteilung, für einen „Integrated Logistic Support“ (ILS), wie dies heute heißt, auch aufzubringen. Vom Hersteller aber auch vom Kunden zu bezahlen. Bisher war es ja bei militärischen Systemen so, dass die verbesserte Dokumentation, bzw. die Fehlerbehebung der oft grottenschlechten Entwürfe der Industrie von den Spezialisten der Truppe, der Werften und den technischen Schulen geleistet wurde.
Dazu muss man aber auf Bw-Seite auch bereit sein, diese zweite Instandsetzungebene zu erhalten und nicht abzuschaffen. Momentan scheint es eher so zu sein, dass man sich ganz auf die Industrie verlassen möchte und als Alibi-Schnittstelle eine personell stark ausgedünntes „Systemzentrum XY“ als Verbindungselement zur Industrie zu unterhalten. Diese Systemzentren sollen zwar eine Bw-eigene „Erkenntnisfähigkeit“ gegenüber der Industrie aufrechterhalten, jedoch habe ich da meine Zweifel wie weit dies noch ohne die „kooperative Mitwirkung“ der Industrie funktioniert. Mit anderen Worten „Die Industrie bestimmt den Kenntnisstand der Bw über ein bestimmtes Waffensystem“.
Das dies für die Güteprüfstellen des BWB, bzw jetzt BAAINBw ein Problem darstellt, kann ich mir vorstellen, weiß jedoch auch keine Abhilfe, ohne dass die Bw die alten Strukturen wieder installiert.
siehe auch: http://augengeradeaus.net/2015/05/spanien-stoppt-testfluege-mit-dem-a400m/comment-page-2/#comment-196846
Derzeit scheinen alle Berichte von 3 Triebwerken ausgefallen sein. Ich habe im Studium mal gelernt, dass im Notfall ein Flugzeug mit 4 Triebwerken auch mit einem halbwegs flugfähig bleiben muss, Zumal in diesem Fall die Maschine ja sehr wahrscheinlich leer geflogen ist (also nur den notwendigen Treibstoff für den Flug).
Gibt es hier jemanden der zu dieser Frage (also ist die A400M mit 3 Triebwerken nicht mehr flugfähig) weitere Auskunft geben kann?
In jedem Fall wird taktisches Fliegen „am Limit“ interessant, zumal wenn der Pilot nicht vorhersagen kann, wie das Luftfahrzeug reagiert bzw. ob es seine Steuerbefehle auch wie intendiert annimmt. Zudem: wie verhält sich die Steuerung bei Ausfällen (z.B. durch Beschuß)?
Die jetzt im Nachtrag dargestellte Meldung der Süddeutschen Zeitung über die neue Software zum umpumpen von Sprit um taktisches Fliegen zu ermöglichen ist für mich wenig glaubhaft. Warum ?
So eine Software probiert man nicht auf dem Jungfernflug eines Flugzeuges aus.
Die Fehlerursache hat eine angenehme Begleiterscheinung in der Öffentlichkeit. Man benutzt halt wieder die alte Software, dann wird der Sprit nicht umgepumpt und man hat wieder ein sicheres Flugzeug.
Wenn man den eigentlichen Schwerpunkt der Unfallursache auf die Triebwerkssteuerung legt, dann zählt dies in der öffentlichen Wahrnehmung viel stärker, denn fehlerhafte Triebwerkssteuerung ist gleich ein unsicheres Flugzeug.
Ich halte diese Meldung für eine gezielte Desinformation der Airbus Öffentlichkeitsarbeitsabteilung an die Medien.