Menschliches Versagen oder bewußte menschliche Einflußnahme ist extrem unwahrscheinlich.

Der ganze Unfall ist extrem unwahrscheinlich. Ich sehe keinen Grund, warum eine menschliche Ursache zwingend unwahrscheinlicher sein sollte, als eine technische.

Ich habe jetzt keine wirkliche Statistik gemacht (und ChatGPT ist darin leider noch zu schlecht), aber "gefühlt" überwiegen bei Totalverlusten von Flugzeugen sogar menschliche oder eine Kombination aus technischen und menschlichen Ursachen sogar denen mit rein technischen Ursachen.

Was mich so ein kleines bisschen an der technischen Ursache zweifeln lässt: Der Unfall ist jetzt bald zwei Wochen her, und die Flugschreiber sind zeitnah geborgen worden. Und ich gehe davon aus, dass Tag und Nacht an deren Auswertung gearbeitet wird.

Sicher ist es noch viel zu früh auch nur für einen Zwischenbericht. Aber mit der Anzahl an Parametern, die da mutmaßlich zur Verfügung stehen und der heutigen Auswerte-Methodik sollte man doch inzwischen eine grobe Idee haben, was da passiert ist. Nur: Es gibt kein grounding der Flotte, keine Emergency AD, oder irgendwelche (öffentlich bekannten) Operator instructions - nada. Alle 787 fliegen munter weiter...

gerade hier vermute ich allerdings auch die große Herausforderung:

WAS war der Root-Cause einer möglicherweise erkennbaren Reihe von Aktionen, die sich aus dem FDR erkennen lassen?

In meiner unmaßgeblichen Kenntnis von Systemen (Flugzeuge bis etwas über 5,70 to MTOW) ohne FADEC etc. und mit etwas Software-Entwickler-Kenntnis, stellen sich die Fragen:

• ist es sinnvoll und richtig, dass allein durch Software der Shutdown eines Triebwerks überhaupt möglich sein kann? Egal ob durch dieFADEC, FCU oder Fuel shutoff valves...
• keine Software ist fehlerfrei. Wie müssen Systeme zusammenarbeiten, um ein unbeabsichtigtes Herunterfahren von Komponenten zu verhindern?
• Wie sicher funktioniert die Elektronik, über 10 Jahre alt, Wärme, Feuchtigkeit, "Bugs" im ursprünglichen Sinn des Wortes. Kann das - nach Maßgabe zum Zeitpunkt der Entwicklung des Musters B787 - berücksichtigt sein, sind die entsprechenden Software-Releases aktuell und OK?
• welche Maintenance-issues gab es? Wurden defekte Systeme getauscht, ggf. als INOP gelabelt und mittels Minimum-Equipment-List weiterbetrieben?
• Wurden Komponenten als "release to service" geschrieben, obwohl nicht "lufttüchtig", aber nicht mehr rechtzeitig verfügbar (AOG vermeiden?) oder unzureichend repariert?
• Ich will hier absolut kein Bashing gegen die Airline und deren Maintenance betreiben, aber Indien ist jetzt auch nicht als "Gold-Standard" für Flugzeugwartung bekannt... Meine - 10 Jahre zurückliegenden - Erfahrungen mir indischer Air-OPS lassen da leichte Zweifel aufkommen...
• das Ganze gepaart mit verborgenen Fehlern in der Systemlogik...

Nur ein paar Gedanken zu den bislang veröffentlichten Fakten und auch Spekulationen...

+1

Arbeiten wohl gerade an der Formulierung für die Presse?!

Unglaublich, danke für die Recherche. Ich kann es irgendwie nicht nachvollziehen, dass sich im Internet soviele Leute mit fremdenden Federn schmücken.

Persönlich bin ich auch der Meinung, dass die Ursache in der Software zu suchen ist. Schon die Tatsache, dass es eine AD gibt, die es fordert eine Komponente nach 248 Tagen neu zu starten (FAA AD-2020-06-14) damit Altitude und Attitude in den PFDs weiterhin korrekt angezeigt werden. Vermutlich läuft in der betroffenen Komponente ein Softwarezähler für zehn-Milisekunden-Zeitschritte. Wenn es sich bei dem Zähler um eine 32-Bit Integer Variable handelt (Wertbereich -2147483648 ... 2147483647), dann läuft der Zähler nach 248,5 Tagen über und die SW stürzt ab (2147483647 / (24*60*60*100) = 248,5). Eigentlich wird bei Software welche nach der Luftfahrt SW-Entwicklungs Norm DO-178 entwickelt und getestet wird, je ein Testfall für jeden möglichen Grenzfall von Variablen erzeugt (z.B. Überlauf) und getestet, was wohl bei der Software dieser Komponente nicht erfolgt ist. Es gibt noch weitere ADs, welche einen Neustart von Komponenten nach 51 bzw. 22 Tagen fordern. Die von den ADs behandelten Fehler führen zwar sicher nicht zu einem katastrophalen Ausfall kommt, aber man weiß nie, was in Kombination mit einem anderen Fehler herauskommt.

Ich bin auch sehr sicher, dass der Unfall eine rein technische Ursache hatte. Die einzige andere, plausible, Möglichkeit wäre Suizid .. aber ich finde, dass dazu die Umstände nicht passen.

Ich tippe auch auf Software-/Systemfehler ...

Alles sehr valide Fragen, und eine RCA kann u.a. deshalb sehr komplex und langwierig sein. Aber eigentlich ist es doch nicht der Sicherheitsstandard in der kommerziellen Großluftfahrt, dass man in so einem Fall alles erst mal laufen lässt!?

"Hm, also irgendein Elektrik-Problem hat alle busses betroffen und beide FSOV's (fiktiv!) geschlossen. Wie das genau passiert ist, müssen wir noch analysieren, deshalb haben wir noch keinen echten fix. Aber, naja, ist die letzten 10 Jahre nie vorgekommen, wird schon nicht so schnell nochmal passieren..."

Ernsthaft? Naja, aber bei den Auswirkungen eines groundings und bei der Anzahl der Player, die so ein Ansinnen auf den Plan rufen würde, auch irgendwie vorstellbar.

Ein weiteres "Erklärvideo", wo der Produzent seine Infos her hat, kann man nicht sagen. Ein "Aviation-Expert" ist er sicher nicht, da sein Kanal auch ganz andere Themen behandelt. Der Audio-Track des Videos ist so schnell gesprochen, dass er nur abgelesen worden sein kann.

Dennoch ist ein Teil recht interessant, ab 13:44 werden die elektrischen Fehlerfälle gelistet/erklärt, welche dazu führen, dass beide FADECs in den sogenannten "Protect Idle" mode zu gehen, was dann zu einem völligen Schubverlust führt. Der Zustand würde ca. eine Minute lang anstehen, bis z.B. die APU genug Backupstrom liefert. Alles kein Problem, wenn man in 30.000 ft fliegt, in 500 ft ist es hingegen gar nicht gut.

https://youtu.be/M_8CYyZRWXE?si=svMnWNXOOk5686S3

Ob das alles stimmt kann ich nicht beurteilen. Die Infos unterstützen jedoch die allgemeine Vermutung, dass es sich um ein Software bzw. Architekturproblem handelt.

Zu dem Thema "idle thrust" gibt es eine Alert Notice der FAA aus dem Jahr 2020: AIR-20-19. See attached

Vielen Dank, sehr interessant.

Wirklich interessant:

Several in-service reports have been received from operators that the auto-throttle remained engaged in the IDLE mode when the flight crew advanced the thrust levers to conduct a balked landing (a goaround initiated after touchdown, but before the thrust lever selection). Once airborne, the thrust levers moved back to idle.

Das bestätigt zumindest, dass es eine "Systemfunktion" gibt, die den Schub nach dem Abheben zurücknimmt.

Bislang bereitet mir Kopfzerbrechen, dass ein möglicher Systemfehler bei grob 1.100 Flugzeugen in fast 15 Jahren seit Erstauslieferung, zum ersten Mal auftritt. Wäre er bereits früher aufgetreten, selbst bei glimpflichem Ausgang, wäre das sicher auch als sicherheitsrelevantes Event intensiv untersucht worden. Da es bisher in keinem der von mir genutzten Medien thematisiert wurde, dachte ich, dass es so etwas nicht gegeben hat. Die LTA spricht aber eine andere Sprache.

Die verunfallte 787 scheint ein relativ frühes Exemplar zu sein:

Your particular 787, delivered to Air India in 2014, had amassed 41,000 hours of flying time and just under 8,000 takeoffs and landings, according to Cirium, an aviation industry analytics firm.

Quelle: https://time.com/7293945/boeing-787-dreamliner-long-history-safety-concerns/

Sie war also schon lange im Einsatz als die o.a. LTA herausgegeben wurde. Wurden die vorgeschlagenen Maßnahmen (sind darin nicht näher ausgeführt) durchgeführt?

*Spekulation (eher laienhaft) an* Denkbar wäre also vielleicht eine versehentliche Betätigung des Go-Around-Buttons (siehe oben "Goaround initiated") in Verbindung mit einem Problem der Weight-On-Wheel-Switches (bzw. falsche Sensorwerte zum Flugzustand) oder Thrust-Lever-Stellung, dann ein (versuchtes) Einfahren des Fahrwerks, welches massiv Leistung vom Triebwerk (evtl. bereits in Idle gefahren) abverlangt und so zum Elektrikausfall führt, was wiederum die RAT ausfahren lässt. Daran beteilgt vielleicht noch reduzierte Redundanz, weil Generatoren/Hydraulikpumpen nur auf dem Papier einsatzfähig waren. Und natürlich geht es in Idle nur noch nach unten. *Spekulation aus*

Wie gesagt, laienhafte Spekulation, aber für mich fügen sich immer mehr Puzzleteile zusammen.

EDIT: Ich vergaß zu erwähnen, dass der o.a. Quellenartikel vom Time Magazine lesenswert ist und - unabhängig von der Wartung durch Air India - das Qualitätsurteil für die Arbeit bei Boeing vernichtend ist.

EDIT2: Idle Thrust kann eigentlich nicht sein, da wohl die Power Levers hardwired mit der FCU an der Engine sind. Und dass der Pilot diese nicht voll nach vorne geschoben hat (und dort hält), ist nicht vorstellbar. Es muss also etwas mit den FSOV gewesen sein.