A400M: Vor tödlichem Absturz Triebwerksdaten gelöscht?
Nach dem Absturz eines A400M-Transportflugzeugs bei Sevilla am 9. Mai scheint es in den Ermittlungen der Unglücksursache eine neue Spur zu geben. Möglicherweise seien Daten der Triebwerksteuerung gelöscht worden, berichtet Reuters:
Nach dem tödlichen Absturz eines Militärtransporters vom Typ Airbus A400M drehen sich die Ermittlungen Insidern zufolge um versehentlich gelöschte Triebwerksdaten. Ohne diese Dateien funktionierten die Steuercomputer der vier Triebwerke nicht, sagten mehrere mit der Angelegenheit vertraute Personen der Nachrichtenagentur Reuters. (…)
Demnach wird aber ein Szenario durchgespielt, in dem die Daten dreier Motoren bei einer Software-Installation gelöscht wurden.
Die englische Version der Reuters-Meldung ist etwas detaillierter:
Investigations are at an early stage but the key scenario being examined is that the data — known as „torque calibration parameters“ — was accidentally wiped on three engines as the engine software was being installed at Airbus facilities. (…)
Under the A400M’s design, the first warning pilots would receive of the engine data problem would be when the plane was 400 feet (120 metres) in the air, according to a safety document seen by Reuters. On the ground, there is no cockpit alert.
That system has been in place since the A400M first flew in 2009.
Das ist immer noch hinreichend vage, dürfte die Debatte über den tödlichen Unfall aber neu entfachen.
Nachtrag: Bei der Paris Air Show will das Unternehmen die Maschine wie geplant vorführen:
Breaking: @AirbusDS says that the A400M will take part in the usual flying display at Paris Air Show #PAS15
— Tim Robinson (@RAeSTimR) June 10, 2015
Zwar arbeite ich nicht in der Entwicklung, betreue aber mit meinem Team hochverfügbare Serversysteme in einem Sicherheitsbereich in dem es in erster Linie um Perfomance geht. In den letzten 10 Jahren (so lange bin ich auf diesem Posten) ist bei uns kein Fehler nach Softwareupdates aufgetreten der auch nur annähernd einen Ausfall hätte verursachen können.
So ein Fehler stimmt mich doch etwas nachdenklich und lässt schon an grobe Fahrlässig oder Absicht glauben.
Ich verstehe immer noch nicht, dass es bei einer Militaermaschine keinen ‚manual override‘ (Notbetrieb) gibt.
Was macht die Elektronik bei Treffern (Kurzschluss usw)? –
@SvenS: Die Steuerung ist ein embedded System. Vergleiche mit einer Server-Landschaft sind ein Äpfel und Birnenvergleich. Die Software selbst scheint ja nicht das Problem zu sein, eher die Prozedur und Qualitätskontrolle beim Zusammenbau des Flugzeugs.
Schleierhaft ist mir allerdings, das diese Fehler erst ab 400Fuß Flughöhe gemeldet werden. Interessant wäre es zu erfahren, ob Fuß über Grund oder Meereshöhe…
So ganz unschlüssig klingt es nicht, dass bestimmte Fehlermeldungen an ein Höhenlevel gekoppelt werden. Denn am Boden interessieren bestimmte Fehlerzustände schlichtweg nicht. Auch wenn es hier uU fatal war.
Zum Vergleich:
Bei meinem Auto meldet sich der Gurtwarner auch nur, wenn eine bestimmte Mindestgeschwindigkeit erreicht ist. Beim Kickstart an der Ampel ist es dann für das Anlegen desselben aber auch bereits zu spät.
Was bedeutet diese Meldung nun, für den Absturz ?
Ich versuche mal eine vorsichtige Annäherung. Gelöscht wurden bestimmte Triebwerksdaten, die vom Hersteller, also EPI, namentlich MTU nach der Endmontage beim Probelaufen der neuen Triebwerke ermittelt wurden.
Zitat: “ known as „torque calibration parameters” — was accidentally wiped on three engines as the engine software was being installed at Airbus facilities“
„torque calibration parameters“, sind wohl die Daten des maximalen Drehmomentes was das Triebwerk erzeugt oder bei maximaler Leistung aushalten kann. Man erinnere sich, dass das automatisch hervorgerufene Gegendremoment bei dem Propellerantrieb, die ganze Flügelstruktur erheblich belastet. Außerdem sollte bei der türkischen Maschine eine neue Triebwerksoftware (FADEC) mit erhöhter Startleistung (= erhöhtes Drehmoment) zum Einsatz kommen.
Was ist vermutlich passiert ?
Nachdem die (maximalen ?) Drehmomentdaten der Triebwerke fehlten, wird eine Schutzschaltung nach kurzer Zeit, die Leistung der Triebwerke auf Leerlauf reduziert haben. Warum dies erst in 400 Fuss Flughöhe gemeldet wird, erschließt sich mir allerdings auch nicht. Vermutlich hätte hier auch kein „manual override“-Schalter geholfen, denn wenn der Triebwerkssteuerung die Parameter der Eingangskalibrierung nach der Herstellung fehlen, dann keine Software der Welt richtig arbeiten.
Zitat: „was accidentally wiped on three engines as the engine software was being installed at Airbus facilities. “
Durch einen menschlichen Fehler beim Installieren der Triebwerkssteuerungssoftware (FADEC) oder durch einen Bug in der neuen FADEC Software, der die Parameter der Drehmomentkalibrierung überschrieben hat ?
Außerdem werden solche Parameter mindestens in einem EEPROM abgespeichert, also in einem nicht ohne weitere Eingriffe löschbaren Halbleiterspeicher – dies macht die Sache nicht gerade leichter verständlich !
Torque calibration data sind nur die für jedes Triebwerk spezifischen Daten, um die Regelung des Triebwerks für einen bestimmten Drehmomentoutput einzustellen.
@ MikeMolto
Das ist genau das Problem. Aus diesem Grund wird ja die Steuerungsphilosophie kritisiert.
@ Tom
Wenn der Triebwerkssteuerung grundlegende Daten fehlen, interessiert das besonders am Boden. Denn nur dort kann man noch entscheiden, ob das Fehlen ein Grund ist den Flug nicht anzutreten.
@ Neaber
Das wird AGL sein, da es sich vermutlich um ein Take-Off Feature handelt.
@ all
Da liegt noch einiges im Dunkeln.
Was ist mit den Telemetriedaten? Der unterschiedliche Drehmomentoutput der Triebwerke hätte doch auffallen müssen. Wenn in 400 ft Flughöhe die Meldung für 3 Triebwerke kommt, was macht der erfahrene Pilot? Er macht auf dem Absatz kehrt! Konnte ich anhand der Flightradar Daten nicht erkennen. Safe turning altitude in sevilla bei take off 09 ist 600ft. Wieso wurden nur bei 3 Triebwerken die Kalibrierungsdaten gelöscht? Warum gehen die Triebwerke bei fehlender Drehmomentkalibrierung in den Leerlauf? Und das noch im Flug? Welchen Sinn macht es drei oder ggfs alle Triebwerke während des Fluges im Leerlauf drehen zu lassen, weil Kalibrierungsdaten fehlen? Warum gibt es keine Sicherung dagegen, alle Triebwerke softwaregesteuert in den Leerlauf zu bringen? Wir werden noch einiges erfahren……
Zum Nachtrag:
Wer bei der Paris Air Show eine Flugvorführung fliegt und wer nicht entscheidet der Veranstalter und nicht das Unternehmen.
@schleppi | 10. Juni 2015 – 11:33
Wenn die Daten gar nicht vorhanden sind, ist dies natürlich am Boden meldenswert. Aber der Computer wird ständig nicht auf Existenz der Vergleichsdaten prüfen, denn diese haben nach seiner Programmierung schlicht da zu sein. Er wird mutmaßlich nur im Flug prüfen, ob sich die Messwerte noch im Rahmen der Parameter befinden. Eine Prüfung die am Boden wenig Sinn macht.
Daher fällt es dann leider erst im Flug auf, dass keine Vergleichsdaten abgespeichert sind.
Für meinen Autogurt wäre uU auch eine Warnung vor Abfahrt sinnvoll. Denn nur dann prüfe ich, ob ich nicht doch zu beleibt für den Gurt bin oder das Gurtschloss beim letzten Möbeltransport beschädigt wurde.
Aber für diese Ausnahmefälle halten die Hersteller eine derartige Prüfung und Systemmeldung für nicht notwendig. Vergleichbar dem undenkbaren Ausnahmefall, dass jemand/etwas die Kalibrierdaten eines LfzTriebwerkes löscht.
Eine fly-by-wire Steuer- und Regelweichware, die beim Hochfahren des Systems nicht prüft ob alle Kalibrierungs-Bibliotheken vorhanden und intakt sind ?? Ich glaub ich setz mich nie wieder in ein Flugzeug…..jedenfalls keins von Airbus.
@klabautermann: Das verstehe ich auch nicht. Ich selbst entwickle Steuerungen im embedded Bereich. Eine der wichtigsten Sicherheitsmaßnahmen ist die Überprüfung der Software selbst(Bildung einer Prüfsumme über den gespeicherten Code + Vergleich mit abgelegter Prüfsumme), der Konfigurationsdaten(meist das selbe Vorgehen + Prüfung auf Zulässigkeit der Konfigurationsdaten zur vorgefundenen Software-Version) und der grundsätzlichen Funktionsprüfung der Hardware (Logik-Checks, Timing-Prüfungen etc.).
IMHO sollte vor dem Testflug eigentlich ein simulierter Start mit Abbruch durchgeführt worden sein. Und da sollen Triebwerksprobleme gar nicht auffallen? Dies wird zumindest bei den mir bekannten LFZ-Montagelinien so durchgeführt. Irgendwer hier, der vielleicht die Prüfung der deutsche A400M begleitet hat oder Infos dazu hat?
Kaum vorstellbar, dass bei einem solch kritischen (embedded) system grundlegende Maßnahmen des Konfigurations- und Qualitätsmanagements missachtet worden sein sollen. Wenn es tatsächlich so war, dann liegt bei den Verantwortlichen für die Integration einiges im Argen.
275000 Zeilen Programmcode und die darin potentiell enthaltenen Fehlermöglichkeiten lassen bei der Triebwerkssteuerungssoftware (FADEC) grüßen !
Man bräuchte mal eine grundsätzliche Skizze über den Aufbau der Triebwerksteuersoftware um festzustellen wo und wann die „torque calibration data“ im Ablauf gebraucht werden !
Offensichtlich ist es die einfache Abhängigkeit: Pilot setzt 100 % Leistung, Triebwerkssteuersoftware fährt das Triebwerk in der Leistung hoch, bis der Drehmomentwert am Propeller erreicht ist, nicht zutreffend, sonst hätte dies beim Startlauf schon auffallen müssen, oder ?
Wie wäre es mit folgender Logik ?
Pilot setzt 100 % Leistung, Triebwerkssteuersoftware fährt die Leistung des Triebwerks hoch, da die Kalibrierdaten fehlen, geht das Triebwerk in einen zu hohen Drehmomentbereich (Over-Torque), nach einer gewissen Zeit oder bei 400 ft über Grund, stellt die EPMU (Elektronic Protection and Monitoring Unit) des Triebwerks fest, Triebwerk ist überlastet und fährt unabhängig vom Pilotenwillen das Triebwerk auf Leerlauf runter um die Überlastsituation abzustellen ?
Verstehe ich das richtig, das der Überlastschutz, welcher verhindern soll das sich des Teile des Triebwerks eventuell beschädigt werden dafür gesorgt hat, dass die komplette Maschine zerstört wurde?
Selbst mein Kabelreceiver hat zwei ROMs und behält die alte Software inklusive Konfigurationen wenn ich die Firmware update. Das kleine Billigteil macht sogar einen automatischen Fallback im Fehlerfall.
Nach immer neuen Verzögerungen und Fehlern, sollte man mal überlegen ob der technische Partner wirklich leisten kann was von ihm erwartet wird oder ob es nicht anders gibt die es besser können.
• Halb O.T.: Man kann sich nur noch wundern, was bei AIRBUS und in deren Umfeld so alles läuft, bzw. besser gesagt eben nicht läuft. Hier der in Sevilla abgestürzte A400M mit seinen Triebwerken und ECUs samt FADECs in den verschiedensten “Software-Varianten” und Verschleierungsmanövern.
• Dann angeblich der A400M in Malaysia mit den von den Medien berichteten Verbindungsbolzen am insgesamt verstellbaren Leitwerk, welche nur eine “falsche Oberflächenbehandlung” erfahren hätten, aber nicht flugsicherheitsrelevant seien, jedoch vom Hersteller kostenfrei an allen A400M ausgetauscht werden sollen.
• Weiterhin “plätschern” beim NH90 die auszutauschenden OHCP und die “Softwarelösungen” für die RTM 322 so vor sich hin.
• Die Projekte SEA LION und H645 (LUH-SOF) sollen schon wieder einmal hinter den Zeit- und Kostenplänen liegen.
• Bei den SEA LYNX vibrieren die Heckrotorwellen ohne angeblich die Wuchtgewichte verloren zu haben, dafür sollen an den Lagerböcken angeblich 3 von 4 Schrauben verschwunden sein, die Bohrungen hätten “Langlochcharakter” (mangels Passhülsen) und es seien sogar halbe Lagerböcke im “VS-NfD” verschwunden.
• Für das RTM 322 gibt es seit 22.055.2015 das nächste AD.
• Allein seit 06.02.2002 insgesamt 17 ADs für den EC120B.
• Ferner seit 26.02.1998 insgesamt 75 ADs für EC135/635.
• Seit 25-09-1997 insgesamt 61 ADs für BK117/RC145/645.
• Und die EASA kann sich vor den weiteren ADs ( EAD, PAD, SIB und ECI) für die weiteren AIRBUS- und EADS-Produkte schon seit Jahren kaum mehr retten (vgl. http://ad.easa.europa.eu/search/advanced/result/).
• (vergleiche 7 ADs seit EASA-Zulassung am 28.09.2007 beim AW/PZL SW-4)
• (vergleiche insgesamt 5 ADs seit EASA-Zulassung 17.03.2005 beim AW/PZL W-3A Sokol).
Grundsätzlich braucht die Regelung die Torque Calibration Data immer. Bei der Airbus Philosophie setzt der Pilot eigentlich gar nichts. Er gibt einen Impuls für eine bestimmte Flughöhe und Geschwindigkeit oder der Autopilot macht das. Den Rest macht die Regelung. Was das die Regelung mit dem Triebwerk macht, wenn die Daten fehlen ist programmabhängig. Nach der Beschreibung war es ja möglich unterhalb des flight idle das Triebwerk zu regeln. So etwas passiert, wenn zum Beispiel der Gasgenerator auf Vollast läuft und die Propellerwelle sehr langsam dreht, weil eine Fehlfunktion der Propellerblattverstellung vor liegt. Das ergibt hohe Drehmomente auf die Propellerwelle, die durch ein Abregeln der Gasgeneratordrehzahl ausgeregelt werden. Ein Fehlen der Kalibrierungsdaten könnte durch die Regelung ähnlich interpretiert werden.
Das mit den 400´ AGL (Above Ground Level – Höhe über Grund) macht Sinn.
Das ist nämlich genau die Höhe in der ein anderes Climbschedule/Powersetting greift.
Wechsel der Geschwindigkeit von V [klein] 2 zu V [klein] FS.
M. W. wird bei Problemen at or below 400´AGL erstmal nur überwacht und weitergestiegen bevor manuell eingegriffen wird.
Meine Beschreibung könnte im Detail auf die Schnelle vielleicht nicht 100% korrekt sein – bitte daher ggf. um etwas Nachsicht.
Bei gidf.de mal selbstständig „400ft agl v2“ eingeben. Da sind einige brauchbare Links/Buchhinweise/Foren zu finden, die es etwas besser erklären. [Bildersuche mit diesem Suchbegriff führt beim ersten Bild zu einer m.E. recht ordentlichen Beschreibung]
;o)
Also im Zusammenhang mit Software und Turbinensteuerung etc und Qualitätssicherung fällt mir natürlich noch etwas ein:
http://www.spiegel.de/netzwelt/netzpolitik/kaspersky-virenjaeger-entdeckt-virus-bei-sich-selbst-a-1037898.html
Man kann/sollte offenbar heutzutage gar nichts mehr ausschliessen in Sachen IT-Sicherheit.
@ CRM Moderator
FAR Part 25.111
Except for Gear Retraction and Propeller Feathering, the airplane configuration may not be changed, an no change in power or thrust that requires action by the pilot may be made, until the airplane is 400 ft above the take-off surface.
Ab 400 ft AGL schreibt dann die FAR Part 25 eine Steigrate von min 1,7 % vor.
@ Schleppi , @ CRM-Moderator
Mit ihren Erklärungen ist der Grund warum die Regelung bis 400 ft über Grund nichts unternommen hat gut nachvollziehbar.
Ich möchte das Augenmerk nochmals auf die Umstände des Überschreiben / Löschen der Drehmomentdaten des Triebwerks legen.
Sind die „torque calibration data“ jetzt für jedes Triebwerk unterschiedliche, spezifische Werte, die der Triebwerkshersteller ermittelt und dem Flugzeugbauer mit liefert ?
Und wenn ja, wie wurden diese Daten in Sevilla gelöscht ?
Durch Aufspielen der neuen FADEC-Software mit verstärkter Startleistung, quasi durch eine Fehlfunktion der neuen Software oder durch einen unachtsamen Mitarbeiter der diese Daten bei den 3 Triebwerken gelöscht hat ?
Ich weiß, Sie können diese Fragen auch nicht so einfach beantworten, aber wenn man nicht die richtigen Fragen stellt, dann sucht man die Lösungen in der falschen Richtung.
Sind bei 400´AGL die
a) Triebwerke ausgefallen?
b) Triebwerke auf Leerlauf gesetzt worden?
c) Propeller gefeathered (Segelstellung) worden?
@ CRM-Moderator
Also laut Airbus-Mitteilung war die Leistungseinstellung „eingefroren“ bei voller Startleistungseinstellung. Nach dem Versuch die Leistung der Triebwerke zu reduzieren und auf „Flight idle“ zu stellen, war die Leistungseinstellung bei dieser Einstellung „eingefroren“ (bei 3 von 4 Triebwerken).
Soweit die Airbus-Mitteilung:
http://airbusdefenceandspace.com/newsroom/news-and-features/statement-regarding-accident-information-transmission-ait-to-a400m-operators-as-follow-up-to-aot-of-19-may/
Das 4. Triebwerk ließ sich laut der Zeitung „Welt“ zwar einstellen, hatte aber auch Probleme die gewünschte Leistung zu erbringen.
Wenn laut FAR Part 25 unter 400 ft. die Startleistungskonfiguration nicht verändert werden darf, dann haben sicherlich die Piloten erst ab dieser Höhe versucht die Triebwerksleistung zu reduzieren und dann dürfte sich der o.g. Fehler abgespielt haben.
Über die Propellerstellung ist nichts bekannt, wenn die Triebwerksregelung jedoch noch teilweise funktioniert hat (Wechsel von Startleistung auf Leerlauf hat trotz „freeze“ funktioniert), dann könnte natürlich auch die Steigung der Propeller automatisch auf Leerlauf, sprich Segelstellung eingestellt worden sein.
@schleppi
Danke für die Klarstellung zur Teilnahme an einem Flugprogramm bei Messen.
Das engl. „will“ als Futur hat in diesem Zusammenhang nichts mit dem deutschen „wollen“ zu tun!
De facto zeigt das Flugprofil auf flightradar, bzw. Twitter, dass die Steigrate bis 600 – 700 ft konstant hoch blieb und erst dann reduziert wurde.
https://twitter.com/flightradar24/status/597028089072381952/photo/1
@ CRM-Moderator
Noch ein Punkt aus dem Pilot Report des A400M in der aviation week:
„the A400M power levers ar not back driven, frozy position at the „managed power detent““
Dies wurde als Nachteil bewertet, dass der Pilot nicht auf einen Blick sieht, was der Autopilot mit dem Schub macht.
@ CRM Moderator
Die FAR 25.111 Regelung ist eine alte Regelung, die den Startvorgang beim Flug in drei Phasen einteilt. 1. bis 35 ft 2. bis 400 ft 3. bis 1500 ft.
Bei der Regelung der Triebwerke ist es vermutlich so, dass die erst greift (angezeigt wird), nachdem 400 ft erreicht sind. Vorher wird mit Startleistung geflogen.
Daher auch meine Verwunderung über das nicht eingefahrene Fahrwerk, da das im Flug ein reiner Widerstandskörper ist.
Mein Beispiel mit der Propellersteuerung sollte nur deutlich machen, welche Wechselwirkungen mit der Triebwerksteuerungssoftware bestehen können. Wenn einer Regelung die grundlegende Tabelle fehlt, die den Zusammenhang zwischen Gasgeneratordrehzahl, Treibstoffzufuhr und Drehmoment enthält, dann ist es eine Frage der Programmierung, welche Maßnahmen getroffen werden.
Die Meßdaten werden korrekt gewesen sein, aber die Steuerung kann damit nichts anfangen, weil es den Zusammenhang in der Tabelle nicht „nachlesen“ kann.
Unterhalb von 400 ft hätte danach eigentlich wieder mit Startleistung geflogen werden können.
Wenn mehrmotorige Flugzeuge bei max Grossweight mit 50% Antriebsleistung nach Zulassungskriterien noch fliegen können MÜSSEN, erschließt sich mir nicht der Sinn einer elektronischen „Pilot-ich-helf-dir-mal-das-Triebwerk-vor-Überlast-zu-schützen“ Automatik …
Völliger Irrsinn und JA, was macht denn dann die Karre erst bei Beschuß ???
@ Schleppi
Zustimmung !
Warum hat das Triebwerk aber unter 400 ft funktioniert ?
Wenn der Pilot „Startleistung“ am Triebwerk wählt, muss ja auch bei dieser Stellung von der Software in der Tabelle nachgeschaut werden, Startleistung entspricht welcher Gasgeneratordrehzahl, welche Triebwerkstemperatur darf maximal dabei auftreten, welche Kraftstoffmenge muss eingespritzt werden und welches Drehmoment darf oder muss an der Antriebswelle erreicht werden ?
PS:
Es geht ja mMn nicht um die Flugsteuerungssoftware mit dem „auto throttle“, sondern um die Triebwerkssteuersoftware (FADEC) die die Befehle vom Schubhebel entsprechend umsetzen soll.
@Georg, @Schleppi: Auszug aus FM A400M für die Situation kommt evt. noch. Habe mal grob die Emergencies überflogen und die scheinen relevant zu sein, nur muß ich noch Anderes erledigen. Wer also das FM vom A400M hat sollte mal dort nachsehen.
Damit hätte ich die 400´AGL ge- und erklärt. Was man so alles mal gelernt hat.
Ich gehe nicht davon aus, dass mit vollem Schub T/O gemacht wird. Wobei….. es war ja ein Testflug…..
http://en.wikipedia.org/wiki/Flex_temp
http://www.skybrary.aero/index.php/Reduced_Thrust_Takeoff
Wenn „nur“ die falsche Software aufgespielt wurde, warum sind nicht 4 von 4 Triebwerken ausgefallen?
@ CRM-Moderator
Zitat: „known as „torque calibration parameters” — was accidentally wiped on three engines as the engine software was being installed at Airbus facilities.“
Anscheinend sind nur bei 3 Triebwerken die Drehmomentparameter gelöscht worden.
Wenn die neue FADEC-Software für die Löschung verantwortlich wäre, müssten diese Daten auch für das 4. Triebwerk gelöscht worden sein, oder beim Aufspielen der Software auf das Triebwerk haben die Techniker einen Fehler gemacht. Dies war meine obige Frage, warum nur 3 von 4 ?
Vielleicht ist das gar kein Fehler?
Vielleicht eine Art Notausgang?
1 kann immer irgendwie geregelt werden?
Ok. Jetzt wirds fast esotherisch….. ;o)
Wir warten weiterhin auf Erleuchtung.
@ CRM-Moderator
Lt. Pilot Report ist der „maximum performance climb“ mit 7000 fpm angegeben. Von dieser Steigrate war der verunglückte A400M meilenweit entfernt.
Die Wahrscheinlichkeit ist größer für den Fall, dass die Techniker dreimal die Software-Umstellung „erfolgreich“ vollzogen haben und beim vierten Triebwerk durch einen Fehler nicht die Software umgestellt wurde, als anders herum, dreimal einen identischen Fehler zu machen. So wird bei drei Motoren die „erfolgreiche“ Software-Umstellung die Drehmomentparameter gelöscht haben und der Vierte war durch einen begangenen Fehler davor bewahrt.
eines muss man meiner Meinung nach festhalten: scheinbar handelt es sich hier um einen eklatanten Designefehler. Ein Ausfall der Software führt zum Verlust eines Luftfahrzeuges, ohne das die Besatzung die geringste Chance hatte einzugreifen. Vieleicht sehe ich das alles zu pragmatisch, da ich noch Steuerung (egal ob Lfz oder Triebwerk) eher mechanisch kenne (C-160). Aber verkehrt war das sicher nicht.
@ AMSI
Jau.
Was mich beschäftigt ist die Frage, ob man mit 3 Triebwerken in idle bis auf 1700ft in einer normalen Steigflugkurve steigen kann. Ich denke eher nicht. Vielleicht kann da jemand weiter helfen. Georg könnte ja mal die Steigraten bis 400ft und nach 400ft nachsehen und posten. Ich hab keine genaueren Daten von Flight Radar 24.
@ AMSI
Zitat: „handelt es sich hier um einen eklatanten Designefehler“
Nach den heute veröffentlichten Fakten, könnte es auch ein menschlicher Fehler beim Aufspielen einer Software gewesen sein.
Nichts destro trotz hat die Software von Flugzeugen schon einige Abstürze verursacht und wirklich zukunftssicher sind Flugzeuge ohne großen Softwareanteil.
@Georg | 10. Juni 2015 – 13:38
Richtig, wenn Triebwerksdaten gelöscht wurden, wären die Triebwerke vermutlich bereits beim Probe laufen oder beim Rollen an Boden ausgefallen. Höchstwahrscheinlich wäre es gar nicht möglich die Triebwerke überhaupt zu starten.
Ferner wurde die Software-Version mit Sicherheit per Checkliste überprüft.
Also müssen wir warten, bis das nächste Puzzle Teil kommt !
@ Schleppi
Die Originaldaten von Flightradar24 werden nicht mehr angezeigt. Die Zusammenfassung auf dem Twitter Bild ist aber auch aussagekräftig:
https://twitter.com/flightradar24/status/597028089072381952/photo/1
Ich denke, dass die Einstellung auf Leerlauf erst in der Höhe von 1700 ft erfolgt ist, dann hörte das Steigen auf. Bis dahin war es bis 600 ft relativ steil und von 600 ft bis 1700 ft etwas abgeflacht. Der ganze Steigflug hat lt. Twitter nur gut eine Minute gedauert.
Ich würde mal abschätzen die ersten 600 ft mit einer Steigrate von 3000 ft / Min und danach mit 1000 ft / Min bis zum Ausfall der Triebwerke auf Leerlaufstellung.
@ Milliway
Die Calibration Data werden anscheinend nur während des Fluges gebraucht und nach Aussage der Meldung wird das Problem erst ab einer Flughöhe von 400ft angezeigt.
Aber grundsätzlich bezweifel ich auch diese angebotene Ursache, weil der Flugweg, wie aus Flight Radar Daten ersichtlich, nach meiner Bewertung gegen den gleichzeitigen Ausfall von 3 Triebwerken spricht.
@ Georg
Der Steigflug sieht bis 1500 ft nach meiner Einschätzung normal aus. Der kleine Geschwindigkeitsabfall beim initial climb ist normal. Danach wurde im climb bis 1500 ft die Geschwindigkeit noch erhöht. Das würde aber gegen die 400 ft Anzeige des Fehlers sprechen und der Flugweg spricht ebenfalls gegen die Theorie des gleichzeitigen Ausfalls von 3 Triebwerken wegen fehlender calibration data.
Hilfreich wäre, wenn Inhalt und der genau Zeitpunkt der ersten Meldung der Besatzung bekannt wäre.
Der Sinkflug zeigt drei nahezu lineare Phasen. 1. Phase bis ca 1200 ft 2. Phase etwas steiler (höhere Sinkrate) bis ca 400 ft 3. Phase sehr steil bis zum Boden
Alles bei nahezu konstanter Ground speed. Die dritte Phase mit sehr steilem Sinkflug könnte durch einen turn begründet sein.
Bei 1500´ AGL….. das ist wieder so eine bekannte Höhe….wäre ja da dann die nächste „Programmierstufe“ fällig für Climb Thrust?
Wann werden die Klappen nochmal eingefahren? 400´AGL, oder?
Wenn man die Zahlen hört (400´ 1500´) klingelts bei mir.
Gut…..nochmal von vorne….bei 400´AGL sollen die Klappen eingefahren werden? Geht aber nicht? Bei 1500´ wechsel zu Cruise Climb (Climb thrust) und 3 Triebwerke gehen aus?
Da Sevilla Field elevation 112´ ist kommt das ziemlich genau hin……
@ CRM-Moderator
Zu welchen Zeitpunkt ist bei dem Steigflug eigentlich der Punkt wo die Flugsteuerungssoftware mit der „Auto Thrust“-Funktion von der reinen Triebwerkssteuersoftware (FADEC) die Kontrolle übernimmt (vorausgesetzt sie sind mit maximaler Leistungseinstellung gestartet (TOGA) )?
Oder wird bereits mit den weiter oben verlinkten „Reduced Thrust Take off“ gestartet ?
Vermutlich haben die Piloten nach dem Ausfall erstmal die Flugsteuerungssoftware abgeschaltet und haben am Leistungshebel „Volle Leistung“ (TOGA) gesetzt, oder ?
Dies wäre doch eine natürliche Reaktion der Piloten, wenn die Flugsteuerungssoftware meine Triebwerke auf Leerlauf runterfährt, oder ?
Wenn die Software über 400 ft auf Leerlauf schaltet, schaltet sie dann wieder auf Schub wenn man wieder unter 400 ft sinkt?
@Georg
Ich denke nicht das man die Steuersoftware einfach abschalten kann. Wenn ein Motorsteuerung im Auto nicht funktioniert bleibt ja auch nur der weg in die Werkstatt. ;)
@SvenS
Meine Erachtens nach ist die 400´ Angabe hier als Abschlutt eines Startsegmentes zu sehen. Das heisst im Umkehrschluss aber ( leider ) nicht das im Sinkflug unter 400´ alles wieder in Ordnung ist. Das System arbeitet jeden Schritt ab und beendet ihn.
Standardschritte ganz grob sind hier:
Start – Steigflug – Reiseflug – Sinkflug – Landung
@VTGAmtmann
eine kleine Korrektur, Sie sagten das in Malaysia fehlerhafte Bolzen gefunden wurden. Das war jedoch beim deutschen A400, dort wurde ein Check vorgezogen und dabei ist es entdeckt worden. :)
Die Frage lautet, welche Software ist durch das Fehlen der Drehmomentdaten gestört worden ?
1. Die Triebwerksteuersoftware (FADEC) die die Triebwerke und den Propeller autonom, d.h. ohne die Flugsteuerungssoftware (FCS) steuert, oder
2. die Flugsteuerungssoftware (FCS), die die Triebwerke in der Betriebsart „managed thrust“ oder eben „auto throttle“, steuert ?
Damit zusammenhängend die Frage nach der 400 ft Grenze, vorausgesetzt es gab zu diesem Zeitpunkt einen Übergang von der Triebwerkssteuersoftware auf die Flugsteuerungssoftware („managed thrust“).
Dies alles führt zu der Frage, „für was werden die gelöschten „Drehmoment Kalibrierdaten“ in dem Ablauf benötigt“ ?
Sind es
a ) Maximalwerte, bei deren Auftreten an der Turbinenwelle die Triebwerksleistung reduziert werden muss ? oder
b) Maximalwerte, die der Propeller als Arbeitswiderstand für die Turbine darstellen darf und bei deren Überschreitung die Propellerblattverstellung auf Leerlauf gefahren wird, damit die Last für die Turbine reduziert wird ? oder
c) sind die Drehmomentwerte Werte, die für jede Leistungseinstellung des Triebwerks bnötigt werden um die gewünschte Ausgangsleistung zu erzeugen ?
Abhängig davon kann man dann ein mögliches Fehlerszenario ableiten, z.B. im Falle b) könnte man sagen, durch das Fehlen des max. Drehmomenteswertes was der Propeller für die Turbine als Last darstellen darf, hat die Elektronik, die Software den Wert „0 Nm“ angenommen, damit automatisch den Propeller auf Leerlauf gestellt, die Turbine war aber auf Startleistung also annähernd Vollast gelaufen, und musste jetzt schnell runterfahren um sich nicht selbst zu zerlegen.
Dies wäre dann das Fehlerbild gemäß der Originalmeldung, dass der Schub sich „unterhalb von der „Flight Idle“ Einstellung einstellen ließ“, aber ab der Einstellung „Flight Idle“ waren die Schubhebel „eingefroren“.
@ Spiekie
Die Sache mit unter 100 Fuss war damals beim Airbus Mulhouse Unglück 1988 auch eine unsichtbare Grenze, weil die Software erkannt hat, dass Flugzeug befindet sich im Landeanflug und hat die Annahme von „Vollen Schub“ durch die Piloten verweigert hat. Danach wurde diese Softwarefunktion geändert.
„Dies wäre dann das Fehlerbild gemäß der Originalmeldung, dass der Schub sich „unterhalb von der „Flight Idle“ Einstellung einstellen ließ“, aber ab der Einstellung „Flight Idle“ waren die Schubhebel „eingefroren““
War nicht die originale Meldung erst froozen in „take off“ und nach der Reduzierung auf
„flight Idle“keine Leistungserhöhung mehr möglich?
Im Flug ist die niedrigste Einstellung „flight Idle“,darunter kommt nur noch „feather“
mit laufendem Triebwerk oder Triebwerk „off“ mit Propeller in „feather“.