Edit: folgendes habe ich gerade auf Twitter gefunden:

https://x.com/Pulkit_Saraf/status/1936330919138275758?t=oe9oryKd85YAyQRPsiTJLA&s=19

Dieser Post ist mehrfach kopiert. Er wurde auch als erster Kommentar (vom Videoersteller @Garybpilot selbst) unter dem zuvor verlinkten Video gepostet. Als Quelle wurde @HeyFixThis genannt. Ein passender Kommentar von @HeyFixThis ist aber weder bei YT, noch bei X zu finden. Es lässt sich also nicht wirklich verifizieren, wieviel B787 Know-how hinter dem Post steckt.

Für mich (und leider auch die Opfer) spielt es keine so wichtige Rolle, ob zuerst Dual Engine Failure eingetreten ist oder eine Total Electrical Failure, die zu einer Dual Engine Failure geführt hat. Die Ursache dürfte ziemlich sicher in der Software-/Systemumgebung liegen und damit spielt die Ursachenforschung eine umso dringlichere Rolle. Menschliches Versagen oder bewußte menschliche Einflußnahme ist extrem unwahrscheinlich.

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