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.)

 

116 Gedanken zu „Nach A400M-Absturz: Airbus ruft zu Kontrolle der Triebwerkssteuerung auf

  1. @ Georg:

    Ich nehme Bezug auf Ihr Zitat:
    „Wie kann man denn in der Entwicklung eine statische Ausfallwahrscheinlichkeit von 10E-9, also ein Ausfall auf 1 Mrd Flugstunde berechnen und sicherstellen (nach DAL A) ?“

    Eine Fehlerrate von 10E-9 1/FH einer Funktion ist mit einem „einfachen System“ oder einzelnen Elementen nicht erreichbar. Eine derart hohe Fehlerrate ist nur durch zusätzliche Systeme (Redundanzen) zu erreichen. Ein Beispiel dafür ist eine Querrudersteuerung, welche über drei (manchmal vier) Anriebe verfügen kann. Entscheidend ist, dass diese Antriebe alle unabhängig voneinander sind und keine gemeinsamen Fehlerfälle (Common Modes) existieren (z.B. vier ölhydraulische Antriebe aber nur eine einzige Pumpe). Es ist also im Rahmen der Entwicklung der Nachweis zu erbringen, dass die Systeme wirklich unabhängig – eben redundant – voneinander sind.
    Gelingt der Nachweis (Common Mode Analyse mit Unabhängigkeitsnachweis), dass es sich um ein redundantes System handelt, dürfen die einzelnen Fehlerraten miteinander multipliziert werden. Im Beispiel der Querruderantriebe hat beispielsweise jeder Antrieb eine Fehlerrate von 10E-3 1/FH (1 Fehler alle 1000 FH) was bei drei zueinander redundanten Systemen eine Fehlerrate für einen Gesamtausfall von 10E-9 ergibt.

    Stellt sich jedoch in der Common Mode Analyse heraus, dass die Systeme nicht unabhängig sind, sondern lediglich dreimal vorhanden und tatsächlich jedes System benötigt wird (weil eine gegenseitige Beeinflussung besteht), müssen die einzelnen Fehlerraten sogar addiert werden. Das Ergebnis ist dann bereits 3*10E-3 (alle 333 FH) für einen vollständigen Systemausfall.

    Ich möchte darauf hinweisen, dass trotz des großen Zahlenunterschieds der Grat zwischen einem dreifach redundanten und einem dreimal vorhandenen – eben nicht redundanten – System sehr schmal sein kann. Hier reichen ein paar Schaltkreise die parallel verlaufen und sich beeinflussen oder dass ein sich zerlegendes Triebwerk gleichzeitig alle drei unabhängigen Systeme zerstören kann.
    Der Unabhängigkeitsnachweis kann SEHR aufwändig sein.

    Beim A400M ist es zu einem massiven Fehler gekommen, der seine Ursache bereits in der Systemauslegung (Design & Validation) hat und im Rahmen der Integrationstests (Verifikation) nicht abgefangen wurde. Eine derartige Beeinflussung darf es nicht geben.

    Da die A400M eine zivile Zulassung besitzt, wird die EASA der Sache auf den Grund gehen. Gleichzeitig wird geprüft werden, ob ähnliche Fehlerfälle auch in anderen zivilen Luftfahrzeugen mit ähnlichen Systemen auftreten können. Die Flugunfalluntersuchung erfolgt – wie üblich – erst einmal nicht in der Öffentlichkeit, um eine lückenlose Aufklärung zu ermöglichen und auch staatsanwaltliche Untersuchungen nicht zu gefährden.

    Ob das Thema anschließend in die Öffentlichkeit gelangt, hängt von der EASA, der spanischen Staatsanwaltschaft,der Einigungsbereitschaft von Airbus gegenüber den Hinterbliebenen und Geschädigten sowie dem Aufklärungsbedürfnis der Öffentlichkeit der Kundennationen ab.

  2. @ Hühnerschrecker

    Danke für Ihre ausführliche Erklärung.

    Die Potenzierung der Ausfallwahrscheinlichkeit, oder sagen wir besser die Verringerung der Unsicherheit der Anlage, kommt durch die Redundanz (die echte Redundanz.).
    Wird die Ausfallwahrscheinlichkeit des Erstsystems auch berechnet oder tatsächlich praktisch ermittelt ? (also die 10E-3 im Beispiel)

    Was heißt das nun bei der Softwareentwicklung ?
    Wenn ich für jedes Triebwerk eine FADEC-Anlage habe und die darin verbaute Engine Control Unit (ECU) mit Software gesteuert wird, brauche ich eine 3 fach redundante Software, also in Prinzip 3 parallele Verarbeitungskanäle für die Daten mit 3 unabhängig voneinander entwickelten Programmen (event. von 3 Programmierern, damit man echte Redundanz erzeugen kann)

    Auf einem Pilotenforum

    http://www.pprune.org/military-aviation/561162-reports-a400-crash-saville-spain-7.html

    diskutieren gerade die 2 Komentatoren „Radix“ und „KenV“ über ein ähnlich gelagertes Softwareproblem bei der Boeing 787 „Dreamliner“. Die 787 hat wohl 4 elektrische Generatoren aber alle mit der gleichen Software ausgestattet.
    Nach meinem Verständnis also nicht redundante Systeme, oder ?

    Und ist ein 3 fach redundates Programm mit 3 unterschiedlichen Programmen von 3 unabhängigen Programmierern für die gleiche Aufgabe entwickelt überhaupt eine realistische Vorstellung über den Aufwand der getrieben wird ?

    Also wenn die FADEC, bzw. Triebwerk- und Propellersteuerung der A400M aus 275.000 Zeilen Programmcode besteht, dann ist es statistisch nahezu sicher, dass sich mehrere latente Fehler in dem Programmcode befinden. Die Frage ist halt unter welchen Umständen sie auftreten und sich auswirken ( siehe Softwarefehler Lauda Air mit Schubumkehr in Reiseflughöhe über Thailand)

    Und wenn so ein Fehler auftritt, dann sollte es ein zweites, event. drittes redundates Softwaremodul geben, das den Fehlerfall abfängt und Funktion der Triebwerkssteuerung weiter erfüllt, oder sehe ich dies verkehrt und man verlässt auf die anderen 3 Triebwerke ?

    Zu der Aufklärung des Vorfalls. Die EASA lässt sich bestimmt von Spanien nicht vorschreiben, dass sie die Untersuchungsergebnisse nicht erhält. Dazu hat sie als Type Certificate ausstellende Behörde zuviel Macht über das Projekt A400M.

    Kann es sein, das die jetzt von Airbus an die Kunden veröffentlichte Meldung (AOT) bereits die Unfallursache abstellt und damit auch die EASA zufrieden gestellt ist und man nur die Öffentlichkeit hinters Licht führen will ?

  3. @Georg: „Die EASA lässt sich bestimmt von Spanien nicht vorschreiben, dass sie die Untersuchungsergebnisse nicht erhält. Dazu hat sie als Type Certificate ausstellende Behörde zuviel Macht über das Projekt A400M.“

    Meine Rede seit anno-toback und genau das ist die Kehrseite bzw. das letztendlich doch Positive am Commercial Approach des A400M.

  4. @ Georg:

    Was da im Bereich Kommunikation oder Recht läuft, kann ich nicht beurteilen. Ich gebe aber Recht, dass die EASA sich nichts vorschreiben lassen wird.

    Die Ausfallwahrscheinlichkeit der Systeme wird tatsächlich auf Basis der Schaltkreise und einzelnen Bauteile errechnet:
    Im Rahmen der Entwicklung werden im Top-Down Ansatz Systemanforderungen (inkl. DALs) immer weiter heruntergebrochen, bis man auf Geräteebene landet. Für hochsicherheitskritische Systeme (DAL-B und DAL-A) geht man immer tiefer bis man Spezifikationen für einzelne Platinen und Schaltkreise erstellt. Hierbei wird man immer noch geleitet von gegenseitiger Beeinflussung, Separierung, Unabhängigkeiten und Redundanzen. Mit Festlegung des ersten Designs wechselt die Systemsicherheit in den Bottom-Up Ansatz und prüft Schaltkreis für Schaltkreis nach Fehlermöglichkeiten und ihren Auswirkungen auf darüber liegenden Systemebenen. Hierbei müssen Fehler stets abgefangen werden. Dieser Prozess wird auch Safety FMEA genannt. Wird der Prozess gründlich durchgeführt, müssen eigentlich immer Designänderungen vorgenommen werden. Für hochsicherheitskritische Systeme muss die FMEA auf Bauteilebene durchgeführt werden. Das Ergebnis ist für jeden Fehler eine berechnete Fehlerrate und eine Beschreibung des Fehlerfalls. Bitte nicht verwechseln mit der Geräte MTBF – das ist eine pauschale Aussage aus dem Bereich Zuverlässigkeit / Maintenance und hat mit Systemsicherheit indirekt etwas zu tun. Eine Pauschalaussage, wie z.B. dieses Gerät hat eine MTBF von 10.000 FH ist nicht aussagekräftig, da für die Systemsicherheit jeder Fehlerfall auch unabhängig betrachtet werden muss. In der Luftfahrt werden sehr hochwertige elektrische Bauelemente verwendet, deren mittlere Fehlerrate durch Tests und Erfahrung bekannt ist und in Handbüchern hinterlegt ist.

    Soweit zu den „simplen“ Systemen, welche aus diskreten Schaltkreisen bestehen, die man vollständig testen kann. Im Bereich der „komplexen“ Systeme schaut es allerdings anders aus. Diese werden dadurch charakterisiert, dass deren Funktion nicht mehr vollständig in jedem erdenklichen möglichen Zustand getestet werden kann. Beispiele dafür sind z.B. eine Umsetzung von Funktionen in SW auf Prozessoren oder programmierbarer HW (PLDs / FPGAs). Wird eine Umsetzung als „komplexes“ System gewählt, muss in der Regel die RTCA DO-254 (HW) und die RTCA DO-178 (SW) nachgewiesen werden. Bei diesen Prozessen erfolgt die Absicherung innerhalb des sehr formalistischen Entwicklungsprozesses. Der Aufwand der Absicherung steigt dabei von DAL D bis DAL A ganz erheblich an. Die erfolgreiche Durchführung für hochsicherheitskritische Komponenten kann nur durch eine sehr fähige Organisation mit viel Erfahrung und durch vollständige Transparenz gegenüber der zulassenden Behörde gelingen.

    Eine weitere Strategie, zur Erreichung von Unabhängigkeit und wirklicher Redundanz ist die Verwendung von „Dissimilar Systems“. Es handelt sich dabei um eine Strategie, über Verschiedenartigkeit eine übergeordnete Systemsicherheit zu schaffen. Es kann damit – manchmal – gelingen, den Aufwand zu reduzieren. Im Beispiel der Querrudersteuerung gilt vom Ansatz her eine Umsetzung aus 2 hydraulischen + 1 elektrischen System als sicherer als die Umsetzung aus 3 hydraulischen Systemen. Der Grund dafür ist, dass das hydraulische System und das elektrische System weniger Common Modes haben wird. Eine ähnliche Strategie wird bei der SW-Entwicklung verfolgt, wenn der identische Funktionsumfang von unterschiedlichen Entwicklungsteams umgesetzt wird.
    Bei all diesen Überlegungen sind jedoch die Sicherheitsüberlegungen auf Systemebene entscheidend (ARP-4754). Hier erfolgt die Festlegung der Systemarchitektur und das Zuordnen von Funktionen auf Geräte und Komponenten. Eine schlechte Systemarchitektur ist wirklich nicht auf darunter liegender Ebene z.B. besonders geeignete HW oder SW „heilbar“. Man muss von einer Fehlkonstruktion sprechen.

    Ich kann keine Aussage darüber treffen, ob 4 Generatoren mit identischer SW redundant ist oder nicht. Offensichtlich hat die FAA es zugelassen. Die Frage ist „welche Aufgabe hat die SW“? Erhöht sie nur den Wirkungsgrad (z.B. DAL C) oder ist sie an der Erzeugung des Drehfeldes direkt beteiligt (z.B. DAL A)?

    Es ist nicht im Interesse der EASA, eine Sicherheitsdebatte unbedingt in der Öffentlichkeit zu führen. Gleichwohl hat die EASA kein Problem damit, wenn Diskussionen in der Öffentlichkeit landen.
    Spannend wird es wenn die Staatsanwaltschaft ermittelt und eine Anklage erhebt.

    Ich lobe mir übrigens den Segelflieger, Schwerkraft ist bislang noch nicht ausgefallen…

  5. @ Hühnerschrecker

    Herzlichen Dank für die ausführliche Schilderung der Konstruktionsabläufe moderner Systeme.

    Als alter Elektroniker der vor gut 40 Jahren mit Lötkolben und selbst geätzten Platinen angefangen und mit komplexer militärischer Elektronik in Großsystemen aufgehört hat, ist es interessant zu lesen wie heute Entwicklung funktioniert. Die letzte Zusatzaufgabe war „Maintenance Ressource Management“, was die Flugunfalluntersuchungen so interessant macht.

    Ich werden zu den gegeben Stichpunkten mal googlen und mich einlesen.

    Interessant finde ich auch die unten zitierte Aussage, weil man mit zunehmender Lebenserfahrung die Einfüsse der Organisationskultur und das interne Arbeitsklima für die erfolgreiche Auftragserfüllung immer deutlicher spürt und vor Augen geführt bekommt.

    Zitat:
    „Die erfolgreiche Durchführung für hochsicherheitskritische Komponenten kann nur durch eine sehr fähige Organisation mit viel Erfahrung und durch vollständige Transparenz gegenüber der zulassenden Behörde gelingen.“

    Wenn man dazu die Schilderung des Insiders „Koenigstiger“ (Kommentar Nr. 1745, 1746 und 1750) bei der Entwicklung des Triebwerks bei MTU und deren Steuerungssoftware liest, dann wird man schon nachdenklich, ob der Industriestandort Deutschland mit seinem herausragenden Fachkräftepotential richtig umgeht und es hegt und pflegt.

    http://www.flugzeugforum.de/threads/58109-Airbus-Military-A400M-News/page175

    PS: Segelflieger finde ich auch gut, noch besser aber Motorsegler oder Ultraleicht. Macht einfach unabhängiger vom Rest der Mannschaft am Flugplatz :-).

  6. @ Georg:

    Mir ist die alte Elektronik auch lieber. Man kann damit die meisten Probleme lösen. Im zivilen Bereich muss man aber die letzten 5% Effizienz erhaschen. Das muss man beim Militär nicht. Hier ist klar die russische Technik von Vorteil, die eben von -65 bis +70 °C funktioniert. In einem militärischen Lfz. hat der Schnickschnack nichts zu suchen.

    Wenn Du Dich einliest, solltest Du Dir nicht den Untersuchungsbericht von der Challenger Katastrophe entgehen lassen. Schau mal was Mr. Richard Feynman dazu geschrieben hat, der der einzige Unabhängige der Untersuchungskommission war.

  7. @Hühnerschrecker

    Sehr interessante Kommentare, die mich in meiner Sicht der Dinge in mehrerlei Hinsicht bestärken.
    Noch ein Hinweis in Sachen Elektronik, software und komplexe hybride Systeme.
    Früher gab es mal Referenz-/Test-und Entwicklungsplattformen in der Luft-und Raumfahrt, die nannten sich IRON BIRD, wenn ich mich noch richtig entsinne. Im Zeitalter des computer aided/distributed industrial engineering frage ich mich, was aus diesen iron birds geworden ist und 2. ob es denn zertifizierte virtual birds gibt, eine mit dem jeweiligen iron bird interoperable Integrierte Entwicklungsumgebung für die Systemsoftware-Simulation/Entwicklung des Vogels.
    Ich denke mal, dass es das nicht gibt, denn sonst hätte „man“ schon etwas darüber gehört.
    Apropos Simulation und Entwicklung und Shuttle-Katastrophen. Im Untersuchungsbericht über die Columbia-Katastrophe kann man nachlesen, dass die Katastrophen-Ursache durchaus hätte vermieden werden können, wenn denn der Gültigkeitsbereich des Simulationsprogramms in Sachen „Isoliermaterial-Ablösung“ und kinetische RCC-Paneel-Absorption beachtet worden wäre…..der erstreckte sich nämlich nur nominell aber nicht mathematisch-physikalisch korrekt auf 1 kg oder mehr Isoliermaterial, das mit ca 800 km/h auf die Frontflügel-RCC-Paneels krachte. Vor der Landung der Columbia hatte man trotz Revision aller Simulationsprogramme diesen Schadensfall ausgeschlossen, da man den mathematisch-physikalischen Gültigkeitsbereich des entsprechenden Simulationsprogrammes nicht verifizierte. So viel zu Sim&Mod und Entwicklung von hybriden komplexen Systemen…..

  8. Kurzer Einwurf @Klabautermann zum Thema Iron Bird

    Airbus verwendet einen Iron Bird beim A350: How Airbus Is Debugging the A350.

    (Airbus spielt halt schon in ner deutlich höheren Liga als Daimler Benz. Deren Stellungnahme zur A-Klasse war schon ein wenig peinlich. Deutlicher Schwerpunk auf Marketing, wenig greifbares zu Design und Qualitätskontrolle. Und „Wir hätten früher und öfter Systemtests durchführen sollen“ wird nicht besser indem man „Systemtest“ in „Quality Gate“ umbenennt. ;) ).

  9. @J.R.

    sehr interessant, danke;-)

    na also, geht doch……..wenn strategische Shareholder-Interessen involviert sind…….

  10. @Klabautermann
    Demonstrator als „neue“ Versuchsplattform gilt wohl nicht, weil der ja nur die Funktionalität aber noch nicht das Design nachweist/darstellt.
    Also meines Wissens wird sowas seit geraumer Zeit auf den Verbraucher abgewälzt ,-)
    Außerdem kenne ich seit der Scheidung das iron wieder ziemlich gut;-)

  11. @all
    ‚mal eine gany simple Frage:
    Mueste es eigentlichz bei einem so wichtigen Szstem wie ‚Antrieb‘ nicht ein manuelles #override# geben?
    Was passiert nach Beschuss und Treffern wenn die Elektronik kury schliesst?

    Es geht im mil-Bereich doch nicht um einige % efficiency mehr oder weniger sondern um Auftrag und Ueberleben!
    Sorrz, kommt evtl etwas spaet aber war eine Weile ’schwimmend‘ unterwegs…

  12. Der Stern hat in seinem Artikel von heute, 2. Juni 2015, 16:38 Uhr „Offenbar Versäumnisse bei Montage von abgestürztem A400M – Bei der Endmontage des Anfang Mai im spanischen Sevilla abgestürzten Militärtransporters A400M sind offenbar mehrere Vorschriften ignoriert worden.“ relativ gut die AFP-Berichtstattung der spanischen Wirtschaftszeitung „El Confidencial“ wiedergegeben.

    Es herrscht im AIRBUS Konzern ein ziemlicher „Hickhack“ unter den Beteiligten und die Produktionstätte in Sevilla samt der dort beschäftugten werden werden offenbar zwischen den Fronten und den Lieferzwängen und nicht nur wegen der Qualitäts- und Fertigungsmängel samt Ad-Hoc-Anpassungs- und Optimierungesentwicklungen zermahlen.

    Hier der Originalartikel aus „El Confidal“: http://www.elconfidencial.com/espana/andalucia/2015-06-02/el-accidente-del-a400m-un-fallo-en-cadena-desde-alemania-a-sevilla_866140/ . Und hier die halbwegs vernünftige Übersetzung aus dem „Promt-Translator“, welche einigermaßen die Substanz des spanischen Textes vermittelt: http://www.online-translator.com/siteTranslation/autolink/?direction=sg&template=General&sourceURL=http://www.elconfidencial.com/espana/andalucia/2015-06-02/el-accidente-del-a400m-un-fallo-en-cadena-desde-alemania-a-sevilla_866140/

  13. Die Zeit der Nebelkerzen hält bei Airbus anscheinend an !

    Wenn man den Bericht beim Stern und die Übersetzung von El Confidal liest, dann hört sich dies schon anders in der Schwerpunktsetzung an.
    Das Airbus seine Werke und seine Zulieferer im Preis und Liefertermin drückt, genauso wie die Autoindustrie es mit ihren Zulieferern macht, ist bekannt.

    Wenn man sich mal auf die zwei Fakten im Bericht konzentriert und näher untersucht.

    1. Die FADEC-Triebwerksregelung soll nach der Installation nicht mit dem Simulator getestet worden sein

    2. Es fand kein Triebwerksprobelauf vor dem Start statt.

    zu 1. Wenn man eine zertifizierte und freigegebene Version der Triebwerkssteuerstoftware hat, dann ist die zig-mal vor der Freigabe mit den verschiedenen Triebwerksversionen (ECU-Versionen) getestet worden, vor der Freigabe. Der einzige Grund der mir ad hoc einfällt um diesen Test mit dem Simulator zu machen, wäre um einen Verkabelungsfehler oder einen anderen Installationsfehler zu erkennen damit das Triebwerk nicht beim ersten Start zerstört wird.

    zu 2. Es fand kein Triebwerksprobelauf vor dem Start statt.

    Diese Aussage geht schon unter die Gürtellinie, was den Grad der Unverfrorenheit und der Dummheit anbelangt. Dies aus zwei Gründen

    1. Nach jedem Triebwerkswechsel bei einem Flugzeug in Service wird ein ausführlicher Triebwerkstest gemacht, inkl. dem Nachweis, dass das Triebwerk die gemäß Datenblatt zugesicherte Leistung, Verbrauch und andere Parameter erbringt. Und ausgerechnet der Hersteller macht vor dem Erstflug keinen Triebwerksprobelauf ? Wie abgefahren soll das denn sein ?

    2. Jeder Pilot macht vor dem einem Start einen Bremslauf und testet den Motor ob er auf Leistung kommt. Dies lernt jeder PPL-Schüler so und ausgerechnet Testpiloten vom Hersteller machen vor dem Jungfernflug keinen Bremslauf ?

    Dies wirkt auf mich völlig unglaubwürdig.

    Dagegen stelle ich mal folgende Hypothese :

    Bei der neuen FADEC-Software für die erhöhte Startleistung der Triebwerke war ein latenter, versteckter Softwarefehler enthalten. Der tritt nur auf wenn die Triebwerkssteuerelektronik, die ECU, thermisch überlastet wird. Deshalb wurde dieser Fehler vorher nicht entdeckt. Zwei Tage nach dem Unfall kannte Airbus den wirklichen Grund des Absturzes und gibt eine Warnmeldung an alle Halter heraus (AOT, wie von T.W. oben geschildert). Die Halter sollen einen simplen Check an der FADEC Software der vorhandenen A400M machen. Dabei soll festgestellt werden ob der gerade aufgetauchte Fehler in der neuen FADEC Version für die Türken auch in der Altversion auftreten kann. Alle Halter melden ein negatives Ergebnis der Überprüfung.
    Wenn das Triebwerk und / oder die Electronic Control Unit (ECU) getauscht werden, muss die Kompatibiltät der neuen Hardware mit der vorhanden FADEC-Software erneut geprüft werden.

    Im anderen Thread zum A400M habe ich die Hypothese für das Fehlerszenario etwas ausführlicher beschrieben:

    http://augengeradeaus.net/2015/05/nach-dem-a400m-crash-deutsche-maschine-bleibt-am-boden-trall-bis-2021/#comment-199152

  14. Wenn man die Übersetzung des spanischen Artikels liest und die Berichterstattung in den deutschen Medien liest, dann fehlen wichtige Details, die das Unglück mit verursacht haben.
    Da ist als erstes der immense Zeitdruck mit dem der A400M produziert wird. Der Rumpf der verunglückten Maschine ist bei Airbus in Bremen produziert worden. Er kam mit 2700 Stunden Verspätung in Spanien an. Offensichtlich versuchte das obere Management diesen Zeitverlust durch Druck auf die spanischen Endmontage auszugleichen.
    Dazu sagte ein Ingenieur des spanischen Airbus Werkes in Sevilla:
    Zitat aus der Übersetzung des Berichtes von „El Confidal“ : „Wir sind zerstoßen. Es gibt zu viel Geschäftsführer, die nicht wissen, was ein Flugzeug ist“.“

    Das Problem hat auch schon das A380 Projekt verzögert und hunderte von Millionen Euro Airbus gekostet. Weil die Hamburger Manager nicht die Schulung der Techniker auf die neue CAD-Software bezahlen wollten, hat Toulouse und Hamburg mit unterschiedlichen Softwareversionen in der Produktion und Planung gearbeitet. Als Resultat mussten Kilometer von Leitungen in den ersten A380 neu verlegt werden, weil sie in der Praxis nicht gepasst haben.

Kommentare sind geschlossen.