AI171 Dreamliner Absturz in Ahmedabad | 12.06.25

ANZEIGE

Volume

Erfahrenes Mitglied
01.06.2018
12.532
10.380
ANZEIGE
ge-idelte Triebwerke in der Luft zu rebooten.
Mag für andere Unfälle relevant sein, hier hätte die Zeit für eine re-boot ohnehin nicht gereicht.

Vielleicht schafft man es gerade noch, die Triebwerke zu starten. Bis zur Startbahn wird man es aber kaum noch schaffen.
Ein Klassiker im Kleinflugzeugbereich, der Restsprit im Gascolator, der Spritpumpe und in der Vergasertasse reicht bei geschlossenem Brandhahn noch um den Startlauf zu beginnen, und dann erst ist Schluß. Im Verkehrsflugzeugbereich gibt es keine Bauteile mit viel Volumen, da ist viel früher Schluß.

So ein Quatsch. Die 787 hat Jet pumps in den Tanks, die Wasser als Emulsion verteilen, so daß nie größere Mengen in die Triebwerke kommen.
Wie lange müssen die laufen, bis alles Wasser emulgiert ist?
Der Sinn ist eher, einfrieren einer größeren Wasseransammlung zu vermeiden, dazu haben diese Pumpen reichlich Zeit, bis der Sprit unter 0°C abgekühlt ist.

Nur aus Interesse: Was würde passieren, wenn man in des gerade gelandete Flugzeug, also bei fast leeren Tanks, reines Wasser statt Fuel einfüllen würde?
Dann würden die kapazitiven Tankgeber Unfug anzeigen, das automatische Betankungssystem viel zu früh abschalten und der Betanker mistrauisch werden, wenn die zwei Anzeigen (am Tankwagen und am Flugzeug) so stark differieren. Einige Flugzeuge (meines Wissens der A380) haben auch ein Kalibrierungssystem (praktisch einen horizontal im Tanksumpf eingebauten kapazitiven Tankgeber der immer komplett nass ist und den Sollwert für "Voll" vorgibt) das dann Alarm schlagen würde.

Da AI171 ja nicht das erste und nicht das einzige an diesem Tag betankte Flugzeug war, würde mich ein Treibstoffproblem eher wundern.

Bei AvHerald glaubt jemand im Video zu erkennen, dass das Strobelight im Heck beim Starlauf blinkt, und ab dem Rotieren aufhört. Kann ich jetzt nicht erkennen, würde aber den Elektrikausfall untermauern. Sagt aber nicht was zuerst passiert ist.
 

marcus67

Erfahrenes Mitglied
17.01.2015
4.093
4.702
Bevor das hier noch weiter abdriftet, der Vorschlag mal wieder etwas über konkretere Technik (und nicht nur Schulphysik ;-) zu reden.

Protect-Idle per FADEC ist nach wie vor im Spiel, dies mal (neue Variante): per Schutzabschaltung via TCMA (Thrust Control Malfunction Accomodation).
Halte ich für eher unwahrscheinlich, denn das TCMA wurde sicherlich so designed, daß es anhand mehrerer Inputs zuverlässig erkennt, ob die Maschine in der Luft ist (und sich dann schlafen legt).
Auch, daß auf beiden Seiten quasi gleichzeitig TCMA auslöst, hmmmm ... (mein Favorit ist da nach wie vor der Failsafe Mode beider GCUs durch Software-Bug und dann Über-/UnterSpannungen/Fehlsynchronisationen durch Umschaltvorgänge der Backup-Spannungsquellen die die FADECs aus dem Tritt brachten).
Andereseits, der Charme der TCMA-Erklärung ist, daß es lt. anderer Quelle (auf pprune.org) offenbar nicht möglich ist, TCMA-ge-idelte Triebwerke in der Luft zu rebooten.

Seis drum, der Sunday Guardian hat offenbar einen guten Ruf (kein Schund-Blatt) und Frau Schiavo ist ja auch nicht irgendwer.

Also rausgekramt die EnglischKenntnisse oder eine (gute ;-) ) Software übersetzen lassen:


Da muss ich Dich enttäuschen - neu ist das nicht im geringsten. Habe ich hier bereits am 12.6. erklärt und wurde seitdem auch diskutiert. Auch in den professionellen Foren wird TCMA seit Wochen als mögliche Ursache diskutiert:

Da gibt es viele, viele denkbare Dinge. Die 787 hat ein TCMA System, das verhindern soll, dass ein Triebwerk nach der Landung am Boden "Amok" läuft. Weiterhin gibt es N2 Protection und einige weitere Systeme außerhalb des A/T.



Ich kann mir nicht vorstellen, dass das exakt zum gleichen Zeitpunkt passieren würde.

Weiterhin fährt das TCMA System das Triebwerk nicht auf Idle - es wird komplett abgeschaltet.

Die Stromversorgung der FADECs war es sicher nicht. Es gibt nach dem Triebwerksstart keine physikalische Verbindung mehr zwischen der Stromversorgung des Flugzeugs und den FADECs. Die Verbindung wird nach dem TW Start aufgetrennt und die Trennung automatisch verifiziert.

EDIT: Ich habe mir den Artikel im Guardian mal durchgelesen - das steht nichts, überhaupt nichts neues drin. Die Schlüsse, die sie zieht sind zudem ebenfalls falsch. - Aber gut, was hat eine ehemalige Verkehrsministerin auch Ahnung von komplexen Systemen in Flugzeugen. Keiner würde Andi Scheuer bei einem Airbus Problem um Rat fragen o_O
 

marcus67

Erfahrenes Mitglied
17.01.2015
4.093
4.702

Volume

Erfahrenes Mitglied
01.06.2018
12.532
10.380
the parameters provided and verified in this report
Kann heissen, es werden sogar noch mehr Parameter aufgezeichnet, die wurden in diesem Report aber nicht verifiziert.

Die entscheidende Frage ist aber: welche Parameter werden zuvor von welchen Datenkonzentratoren bearbeitet/zwischengepuffert/geglättet, und fallen aus wenn diese nicht mit Strom versorgt werden. Nur wenige Parameter dürften den Recorder direkt erreichen, auch noch bei Stromausfall.

Schutzabschaltung via TCMA (Thrust Control Malfunction Accomodation).
Halte ich für eher unwahrscheinlich, denn das TCMA wurde sicherlich so designed, daß es anhand mehrerer Inputs zuverlässig erkennt, ob die Maschine in der Luft ist
Das führt uns zur selben Diskussion wie bei MCAS zurück, je mehr Inputs du abfragst bevor du das System aktivierst, deso mehr Gründe gibt es, wegen denen es versagen kann, desto geringer seine Zuverlässigkeit in Bezug auf "seinen Zweck erfüllen". Du kannst nie gleichzeitig Verfügbarkeit maximieren und Fehlfunktionen mimimieren, du musst dich für einen Kompromiss entscheiden, eine Priorität definieren.
Es gibt gute Gründe Sicherheitssysteme nicht mit zu vielen Informationen zu füttern, nicht zu viele Querkontrollen durchzuführen. Deashalb ist es immer nur die zweitbeste Lösung, auf ein problematisches System eine weitere Sicherungseinrichtung draufzusatteln. Besser gleich das Grundsystem (hier: Triebwerk) solide konstruieren.

Keiner würde Andi Scheuer bei einem Airbus Problem um Rat fragen o_O
Der hat ja bekanntlich nicht mal geschafft zu fliegen, obwohl er wirklich drum gebettelt hat...
 

N140SC

Erfahrenes Mitglied
01.01.2024
687
618
Ich habe mir den Artikel im Guardian mal durchgelesen - das steht nichts, überhaupt nichts neues drin. Die Schlüsse, die sie zieht sind zudem ebenfalls falsch. - Aber gut, was hat eine ehemalige Verkehrsministerin auch Ahnung von komplexen Systemen in Flugzeugen. Keiner würde Andi Scheuer bei einem Airbus Problem um Rat fragen o_O

Bei diesem Thema zeichnen sich die wahren Experten durch Zurückhaltung aus, bis etwas wirklich bewiesen ist. Klar, dass unter diesem Umständen da nichts neues drinsteht. Im Gegensatz zu dem, was Du geschrieben hast ist sie nämlich nicht nur Professorin, sondern selbst auch Pilot in. Und mit einem Minister ist ein Inspector General auch nicht vergleichbar.
 

marcus67

Erfahrenes Mitglied
17.01.2015
4.093
4.702
Bei diesem Thema zeichnen sich die wahren Experten durch Zurückhaltung aus, bis etwas wirklich bewiesen ist. Klar, dass unter diesem Umständen da nichts neues drinsteht. Im Gegensatz zu dem, was Du geschrieben hast ist sie nämlich nicht nur Professorin, sondern selbst auch Pilot in. Und mit einem Minister ist ein Inspector General auch nicht vergleichbar.
Es bleibt aber dabei, dass einige Dinge, die sie im Interview erzählt schlicht falsch sind. Es ist hinlänglich bekannt, dass die Triebwerke von NH985 nach der Landung durch das TCMA komplett abgeschaltet wurden.

Für mich liest sich ihr Statement vor allem wie das eines Anwalts, der Geld wittert. Solche Statements habe ich schon öfter gelesen.
Beitrag automatisch zusammengeführt:

Die entscheidende Frage ist aber: welche Parameter werden zuvor von welchen Datenkonzentratoren bearbeitet/zwischengepuffert/geglättet, und fallen aus wenn diese nicht mit Strom versorgt werden. Nur wenige Parameter dürften den Recorder direkt erreichen, auch noch bei Stromausfall.
Ich glaube ja weiterhin, dass die interessanten Dinge passiert sind BEVOR der Strom ausfiel.
 

oliver2002

Indernett Flyertalker
09.03.2009
9.281
4.987
50
MUC
www.oliver2002.com
Für mich liest sich ihr Statement vor allem wie das eines Anwalts, der Geld wittert. Solche Statements habe ich schon öfter gelesen.
Beitrag automatisch zusammengeführt:

Klaro, bei solchen Unfällen wird richtig Kohle gemacht:



With over 33 years of international aviation legal experience, James Healy-Pratt and Owen Hanna have independently investigated hundreds of aviation accidents and recovered over US$1bn in settlements. They are jointly investigating this accident in conjunction with the specialist US aviation firm, The Wisner Law Firm in Chicago, Illinois. Together this team have also assisted passengers and families in many Boeing mass fatality airliner accidents, including Kenya Airways, Garuda Airlines, Lion Air, Ethiopian Airlines, and Malaysian Airlines (MH17 & MH370).

 

makrom

Erfahrenes Mitglied
05.09.2016
1.739
872
Mir scheint, als würde sich die Berichterstattung zum ganzen Thema im Wesentlichen darauf beschränken, reihum Thesen aufzuwärmen, die bereits seit Tag 1 im Raum standen.
Beitrag automatisch zusammengeführt:

Keiner würde Andi Scheuer bei einem Airbus Problem um Rat fragen o_O
Ist vmtl. immer noch besser, als ihn zu verkehrspolitischen Themen um Rat zu fragen.
 

cockpitvisit

Erfahrenes Mitglied
04.12.2009
5.300
2.989
FRA
Gibt's in der Luftfahrt Bestrebungen, bei Softwarekomponenten auch Redundanz zu schaffen, damit ein Bug nicht gleich einen Absturz verursacht? Z. B. FADEC in beiden Engines mit von verschiedenen Teams entwickelter Software zu betreiben?

Beim Space Shuttle gab's glaube ich einen 5. Flight Control Computer, der eine andere Software enthielt, speziell für den Falls eines schweren Fehlers in der Software. Gibt's was ähnliches in der Luftfahrt?
 

marcus67

Erfahrenes Mitglied
17.01.2015
4.093
4.702
Gibt's in der Luftfahrt Bestrebungen, bei Softwarekomponenten auch Redundanz zu schaffen, damit ein Bug nicht gleich einen Absturz verursacht? Z. B. FADEC in beiden Engines mit von verschiedenen Teams entwickelter Software zu betreiben?
Das wurde früher diskutiert und auch getestet. Wurde aber wieder verworfen, da sonst kleine Unterschiede zwischen beiden Systemen zu ständigen Fehlern geführt haben. Weiterhin: Wie entscheidest Du, wer Recht hat?
 

cockpitvisit

Erfahrenes Mitglied
04.12.2009
5.300
2.989
FRA
Das wurde früher diskutiert und auch getestet. Wurde aber wieder verworfen, da sonst kleine Unterschiede zwischen beiden Systemen zu ständigen Fehlern geführt haben. Weiterhin: Wie entscheidest Du, wer Recht hat?
Im o. g. Beispiel mit Triebwerken: das nicht ausgefallene Triebwerk hat Recht 🤣

Sonst genau wie bei redundanten Hardware-Systemen, da hat man doch die gleiche Problematik.
 

drusnt

Erfahrenes Mitglied
02.12.2013
1.313
2.151
Gibt's in der Luftfahrt Bestrebungen, bei Softwarekomponenten auch Redundanz zu schaffen, damit ein Bug nicht gleich einen Absturz verursacht?
Selbstverständlich. Das sind auch nicht unbedingt Bestrebungen, sondern simpelste Basics ohne die es keine Zulassung geben wird.

Ganz vereinfacht (ohne das korrekte Wording zu nutzen) zusammengefasst:

Siehe dazu z.B. Easa Certification Spec and Acceptable Means of Compliance for Large Aeroplanes
CS 25.1309(b)
The aeroplane systems and associated components, considered separately and in relation to
other systems, must be designed so that -
(1) Any catastrophic failure condition
(i) is extremely improbable; and
(ii) does not result from a single failure;
(...)
Aus den Acceptable Means of Compliance zu dieser Specification kommt man dann über die AMC 20-115D sowie der ARP4754A irgendwann runtergebrochen zur Software und dort zur DO-178C (Software Considerations in Airborne Systems and Equipment Certification).

Dort wird dann sehr eindrücklich festgelegt und beschrieben, was im Entwicklungsprozess so alles zu tun ist, falls meine Safety-Analysen zum Schluss kamen, dass eine Funktionalität zu einem Catastrophic/Hazardous/Major/Minor Event beitragen kann.

Für die höchste Kritikalität bedeutet das für das betroffene Software-Item einen entsprechend aufwändigen Planungs-/Analyse-/Requirement-/Design-/Coding-/Implementierungs-/Verifikations- und Validierungsprozess, in welchem viele Dinge mit "Independence" gefordert sind. Das kann über simple Redundanz hinausgehen und zusätzlich noch eine Andersartigkeit erfordern. Z.B. verschiedene Algorithmen um ein und den selben Parameter zu berechnen. Und das betrift nicht nur die Software selber, sondern auch Dinge im Prozess drumherum. Das kann natürlich wieder andere Fragen aufwerfen, wie z.B. diese Werte gemonitored werden.

Wie das z.B. bei Triebwerken oder speziell FADEC gemacht wurde, kann ich nicht sagen, da ich Compliancemäßig eher im Avionikbereich unterwegs bin.

Aber um mal grob den Aufwand aufzuzeigen: Für eine simple Software-Änderung an bestehender und zugelassener Software von 3 Zeilen brauchten wir auf Grund des von Safety ermittelten Impacts mehrere Monate. Es waren u.a. an der Umsetzung beteiligt: System- und Software-Architekten, Engineering, Software-Entwickler, Softwaretest, Systemtest, Integrationstest, Bodentest und Flugtest sowie die Safetyabteilung. Qualitäts- und Konfigurationsmanagement darf man auch nicht vergessen und das Projekt muss auch irgendwer managen. Wie viel hunderte Seiten Dokumentation da in der Entwicklung wegen diesen paar Zeilen Code-Änderung entstanden sind, kann ich garnicht sagen.

Sobald da irgendwie ein Major Impact im Raum steht, kann es auch bei der Softwareentwicklung ganz schnell ausarten, was den Aufwand angeht.
 

Volume

Erfahrenes Mitglied
01.06.2018
12.532
10.380
Weiterhin: Wie entscheidest Du, wer Recht hat?
Es gab ja z.B. schon Beispiele, wo 2 von 3 AoA Sensoren eingefroren waren (nachdem jemand auf die glorreiche Idee gekommen ist, sie zu kärchern...), deshalb Werte im gültigen Bereich gezeigt haben, und der eine der korrekt vor dem Überziehen warnen wollte wurde überstimmt, weil der abweichende...

Wirkliche Redundanz enteht erst, wenn man mit komplett anderen Systemen und Technologien arbeitet, z.B. mit einer Vane (mechanisch), einer Fünflochsonde (pneumatisch) und einem Laser Doppler Anemometer (optisch) um den Anstellwinkel zu bestimmen. Und das bitte noch jeweils rechts und links am Rumpf, um Schiebewinkel zu kompensieren.

Beim Space Shuttle gab's glaube ich einen 5. Flight Control Computer, der eine andere Software enthielt, speziell für den Falls eines schweren Fehlers in der Software. Gibt's was ähnliches in der Luftfahrt?
Im guten alten A320 Fly by Wire System arbeiten die redundanten Computer sogar mit verschiedenen Prozessoren (meines Wissens intel 8086 und Motorola 68000).
Wobei (lange ist es her...) die zwei Prozessorfamilien high byte und low byte eines Integers meines Wissens sogar in umgekehrter Reihenfolge im Speicher ablegen... Viel verschiedener kann die Software nicht sein.

Irgendwann muss man aber mit all den Redundanzen eine Aktion auslösen (Triebwerk laufenlassen oder stillegen), daher hat das immer Grenzen.
Du kannst ja schlecht der eine Hälfte der Einspritzdüsen von dem einen, der andere Hälfte von dem anderen Computer Sprit zumessen, das Triebwerk halb stillegen wenn du einen uncontained failure vermeiden oder ein Feuer stoppen möchtest.
 

kokosnussgarten

Reguläres Mitglied
20.05.2018
96
157
In einem Nachbarforum fand ich recht informative Informationen.

Z.B. hier (Video)

und darüber hinaus

hier (ggfls. mit einschlägigen Hilfsmitteln übersetzen) - oder hier als ...:

Zitat aus http://@airindia @DGCAIndia:"
Ich glaube, die Ursache war eine Kombination aus der Aktivierung des Treibstoffabsperrventils (FSOV) aufgrund eines kaskadierenden Ausfalls des elektrischen Systems. Es ist nicht das erste Mal, dass bei einer 787 in den ersten Flugminuten ein Ausfall des elektrischen Kaskadensystems auftrat und ein RAT-Einsatz erforderlich war.
Lassen Sie mich meine Begründung erklären: Bei der Boeing 787 laufen die Triebwerke weiter, selbst wenn alle Hydrauliksysteme ausfallen. Jedes Triebwerk verfügt über eine eigene FADEC (Full Authority Digital Engine Control), die von einem Permanent Magnet Alternator (PMA) angetrieben wird, der wiederum vom Triebwerk selbst betrieben wird. Sobald das Triebwerk läuft, arbeitet die FADEC unabhängig und regelt Treibstoff, Schub und Sicherheit – ohne dass Flugzeughydraulik oder externe Stromversorgung erforderlich ist.
Ein gleichzeitiger Ausfall der FADECs ist äußerst unwahrscheinlich. Warum also kamen die Triebwerke zum Stillstand, wenn sie doch angeblich so robust sind? Es gibt eine wichtige Komponente, die das FADEC außer Kraft setzen kann: das FSOV.
Dieses federbelastete Treibstoffabsperrventil wird nicht vom PMA angetrieben, sondern vom elektrischen Gleichstromsystem des Flugzeugs. Bei einem Stromausfall schließt die Feder das Ventil sofort und unterbricht die Treibstoffzufuhr zum Triebwerk. FSOVs sind eine Ausfallsicherung, die die Flugzeugzelle und nicht das Triebwerk schützen soll. Boeing geht davon aus, dass ein Triebwerksabschalten sicherer ist, als weiterhin Treibstoff in ein potenzielles Feuer zu leiten.
Im Videomaterial befindet sich der Kippaktuator des Fahrwerks in der vorderen Position (Zehen nach unten). Diese Bewegung erfordert eine hydraulische Systemkraft, um Wind und Schwerkraft zu überwinden. Diese vordere Position wird nur erreicht, wenn die Piloten das Fahrwerk einfahren. Das Kuriose daran ist, dass das Kippen des Fahrwerks nach vorne erst der zweite Schritt der Hauptfahrwerkseinfahrsequenz ist. Der erste Schritt besteht darin, die Türen zu öffnen, und wenn diese vollständig geöffnet sind, besteht der nächste Schritt darin, das Fahrwerk zu kippen.
Es ist unklar, warum die Türen geschlossen sind, das Fahrwerk aber bereits nach vorne geneigt ist. Höchstwahrscheinlich hat der Pilot „Fahrwerk eingefahren“ gewählt, wodurch die Einfahrsequenz ausgelöst wurde. Das Kippen des Fahrwerks wurde als zweiter Schritt eingeleitet, aber die Türen öffneten sich aufgrund eines Strom- oder Hydraulikausfalls nicht, oder die Sequenz fror mitten im Vorgang ein. Das Flugzeug verlor die Hauptantriebskraft (daher das RAT) und die Sequenz wurde mit dem Fahrwerk in einem teilweise gesteuerten Zustand angehalten:
Wagen gekippt, Türen geschlossen, Fahrwerk ausgefahren. Dieser Moment des Einfahrens des Fahrwerks könnte der genaue Punkt gewesen sein, als das ganze System nur 3–4 Sekunden nach dem Start zusammenbrach. (Es gab eine positive Steigrate bei 600 Fuß über Meeresspiegel und 174 Knoten.)
Die Triebwerke liefen noch kurz (3 Sekunden) nach, angetrieben vom restlichen Treibstoff in den Leitungen, bevor sie ausfielen. Die Hydraulik des Hauptfahrwerks wird von einem elektrohydraulischen System angetrieben – ohne Strom gibt es keinen Hydraulikdruck. Im Gegensatz dazu werden andere Hydrauliksysteme des Flugzeugs von motorbetriebenen mechanischen Pumpen versorgt. (20–30 kW Leistung zum Einfahren des Fahrwerks erforderlich).
Da das Flugzeug im Flug stabil blieb, ist es wahrscheinlich, dass beide Triebwerke gleichzeitig ausfielen. Landeklappen, Fly-by-Wire, Fahrwerk und andere Systeme froren wahrscheinlich für einen Moment ein und erlangten möglicherweise ihre Funktionalität zurück, nachdem das RAT ausgefahren war.
Die 15 kW RAT versorgt die Elektromotoren in den blauen Hydraulikleitungen einer 787 mit Strom. Dies steuert die wichtigsten Flugsteuerungsaktuatoren für Seiten-, Höhen- und Hauptquerruder. Es scheint, dass der Pilot in der Endphase des Fluges die Fluglage leicht erhöht hat. (Das Einfahren des Fahrwerks ist mit einem RAT nicht möglich.) Damit beide FSOVs schließen, müsste das Flugzeug beide AC-Busse, beide DC-Hauptbusse und die Batterie-Backups verlieren.
Dies erfordert einen massiven Stromausfall, um alle möglichen Redundanzebenen zu überwinden. Dies ist möglich, da Fälle bekannt sind, in denen es bei einer 787 und einer 777 zu einem totalen elektrischen Kaskadenausfall der meisten Systeme kam. Es ist also möglich. Alle Anzeichen deuten auf eine Treibstoffabschaltung über die FSOVs hin. Die große Frage ist, warum sie ausgefallen sind. Das ist schwer zu sagen, aber wie gesagt, ein Stromausfall ist eine sehr plausible Ursache. Das RAT wurde automatisch ausgelöst. Dies bedeutet, dass es zu einem totalen Verlust der Wechselstromversorgung kommt. Ich vermute ein Szenario, in dem ein teilweise funktionierendes oder instabiles elektrisches System während einer Stromumstellung den Einsatz von RAT auslöst. Dies könnte zu einer vollständigen Stromunterbrechung führen und möglicherweise die wichtigen DC-Busse und die Batterie-Notstromversorgung beeinträchtigen. Beim Umschalten der Stromquellen (von den Hauptbussen auf RAT) kann sich das System unvorhersehbar verhalten – insbesondere, wenn eine Quelle mit dem RAT konkurriert oder instabil ist. In einem solchen Stromchaos kann der Einsatz von RAT zu Transienten oder Verzögerungen bei der Wiederherstellung der Stromversorgung führen, was die Stromversorgung instabil machen und möglicherweise die digital gesteuerte Stromversorgung der FSOVs beeinträchtigen kann. Bei einem Stromausfall wird der gesamte Treibstoff abgeschaltet. In der 787 verfügen die FSOVs nicht über eine garantierte dedizierte oder Hot-Battery-Notstromversorgung, im Gegensatz zum Airbus A320, der sie direkt aus der Batterie versorgt. Die Batterie-Notstromversorgung der 787 unterstützt den gesamten DC-Bus, und die Energiemanagement-Software priorisiert flugkritische Systeme.
Bei begrenzter Leistung oder unregelmäßigen Lasten werden weniger kritische Systeme wie FSOVs herabgestuft . Dies ist ein sehr komplexes System mit vielen Softwareregeln. Dies spiegelt auch die Designphilosophie von Boeing wider:
Bei einem schweren Stromausfall haben die Überlebensfähigkeit der Flugzeugzelle und die Flugsteuerung Vorrang vor der Triebwerkskontinuität. Sie gehen davon aus, dass es sicherer ist, den Treibstoff abzuschalten, als das Risiko einzugehen, dass unkontrolliert Treibstoff in ein brennendes Triebwerkfleißt. Die ganze Vorstellung, dass beim Start in 400 Fuß Höhe beide Triebwerke ausfallen könnten, fühlt sich von Natur aus unsicher an. Aus Sicht der Schubkontinuität stellt dieser Designansatz eine Schwachstelle dar und könnte beim Ausfall zweier Triebwerke von Flug AI171 eine Rolle gespielt haben
Bei der 787 und anderen Boeing-Modellen gab es eine Geschichte mit ähnlichen elektrischen Problemen. Im Jahr 2024 erlitt die Besatzung eines Atlantic-Fluges 787, VS105, während des Steigflugs einen schweren elektrischen Ausfall – die Triebwerksgeneratoren fielen aus. Als Reaktion darauf wurde das RAT automatisch aktiviert, um Notstrom bereitzustellen. 2015 entdeckten Boeing und die FAA einen kritischen Softwarefehler in den Generator Control Units (GCUs) der 787. Würden die Generatoren 248 Tage hintereinander eingeschaltet bleiben, könnte ein interner Zähler überlaufen, alle vier GCUs abschalten und die Stromzufuhr komplett unterbrechen.
Die FAA gab die Notfall-AD 2015-08-51 heraus, die von den Betreibern verlangt, die 787 alle 8 Monate neu zu starten, um einen vollständigen Stromausfall während des Fluges zu vermeiden. Bei zwei getrennten Vorfällen – in Boston (JAL) und Takomatsu (ANA) – kam es zu einer Überhitzung der Batterien und einem Brand in den Lithium-Ionen-Batterien der APU des Flugzeugs. Im Dezember 2018 kam es auf dem LATAM-Flug LA8084, einer Boeing 777-300ER, auf dem Weg von São Paulo nach London zu einer elektrischen Kernschmelze. Das RAT wurde aktiviert, um Notstrom bereitzustellen. Nachdem die Triebwerke am Boden abgeschaltet wurden, kehrte plötzlich die Stromversorgung zurück – was einen Fehler im elektrischen Verteilungssystem bestätigte (wahrscheinlich ein Busschütz- oder Konverterfehler). Das Ereignis war ein typischer Kaskadenfehler: Generatorstrom war verfügbar, aber eine Kettenreaktion von Leistungsschalter- und Konverterfehlern trennte alle wichtigen Busse vom Netz, einschließlich derer, die von der APU und den Triebwerken angetrieben wurden.
Die 787 ist in hohem Maße auf softwarebasiertes Energiemanagement angewiesen. Wenn sich also die Grundursache als ein Softwarefehler in einem extrem komplexen elektrischen System herausstellt, könnte die gesamte Flotte bis zur Untersuchung am Boden bleiben. Ich schließe Dampfblasenbildung aus: Moderne Düsentreibstoffsysteme werden unter Druck und Temperatur geregelt

Zwar schon ein paar Tage alt aber dennoch durchaus plausibel. Es scheint sich auf die Software in Verbindung mit dem Einfahren des Fahrwerks zu focussieren.
 
  • Like
Reaktionen: fieseblauefrucht

Tupolew

Erfahrenes Mitglied
27.09.2012
1.473
613
Ist ja schön und gut aber bei der Erkenntnis, dass es wahrscheinlich ein Stromausfall war der eventuell durch Software ausgelöst wurde, sind wir ja hier im Thread auch schon. Bei dem Teil WARUM der Strom ausfällt kommt auch er nicht weiter
 

makrom

Erfahrenes Mitglied
05.09.2016
1.739
872
Ist ja schön und gut aber bei der Erkenntnis, dass es wahrscheinlich ein Stromausfall war der eventuell durch Software ausgelöst wurde, sind wir ja hier im Thread auch schon. Bei dem Teil WARUM der Strom ausfällt kommt auch er nicht weiter
Finds auch ein bisschen unpassend, hierbei von Stromausfall als "Ursache" zu sprechen.
Dass das ein Teil der Kausalitätskette sein könnte, legte ja bereits sehr früh die aktivierte RAT nahe, nur ist die spannende Frage halt, warum so ein Flieger einfach den Strom inkl. Redundanzen verlieren soll.
 
  • Like
Reaktionen: juliuscaesar

Mclovin

Reguläres Mitglied
15.11.2009
32
24
Aus Unwissenheit gefragt: Kämen zum Beispiel Nagetiere in Frage, um so einen massiven Stromausfall zu produzieren?
 

ServMan

Erfahrenes Mitglied
13.08.2013
3.100
3.690
FMO, AMS
  • Like
Reaktionen: tcbybot1