Schub braucht große Drehzahlen.
Jein. Das Verhältnis zwischen Startschub und Leerlaufschub ist wesentlich größer als das Verhältnis zwischen Startderehzahl und Leerlaufdrehzahl.
Schub braucht Luftdurchsatz und Gastemperatur, der Einfluß der Temperatur ist deutlich höher als der des Luftflusses. Was auch gut ist, denn die Temperatur kannst du praktisch spontan durch die eingespritzte Spritmenge steuern.
Deshalb läuft das Triebwerk beim Start ganz langsam hoch. Die ECU spritzt genau so viel ein, dass dieser Vorgang unter allen Bedingungen stabil abläuft.
Was dann in der Praxis heisst: Die ECU spritzt weniger ein als bei Vollgas, verzögert den Hochlauf bewusst damit er stabil aubläuft.
Schon die klassischen hydromechanischen FCUs haben beim Hochlauf bewusst die Spritzufuhr reduziert um Compressor Stalls zu verhindern, beim Runterlauf bewusst die Spritzufuhr erhöht um ein Flameout zu verhindern. Würde der Schubhebel direkt die Einspritzmenge steuern, hätte man diese zwei Probleme, deshalb gibt es schon immer eine Regeleinrichtung.
Beim Hochlauf kann die Turbine (wenn man ihr hinreichen heisses Gas liefert, sprich genug Sprit einspritzt) mehr Leistung liefern, als der Verdichter aufnehmen kann ohne das einzelne Stufen "überziehen". Du kannst Luft "berghoch" also gegen einen Druckanstieg nicht beliebig zwingen, kannst nicht beliebig viel Drehmoment auf den Verdichter geben ohne dass er die Luftströmung überfordert.
Moderne FADECs machen diesen Job besser und exakter, dazu blasen moderne Triebwerke im Hochlauf noch bewusst Luft vor der Brennkammer ab um den Verdichter zu entlasten (oft gut zu hören), aber im Prinzip ist die Kunst ein Turbinentriebwerk zu beschleunigen vor allem es nicht zu stark zu beschleunigen, es nur so viel wie gerade möglich mit Sprit zu versorgen.
NSelbst wenn ein FADEC Kanal wegen eines technischen Defekts einen Schaltvorgang erkennen würde, würde der andere Kanal das nicht tun. Was die Systeme daraus machen würden, weiß ich nicht. Es gäbe aber mit Sicherheit eine Disagree Fehlermeldung, die ebenfalls auf dem DFDR zu finden wäre.
Nicht unbedingt, kommt auf das exakte System an, viele Disagree Probleme werden einfach von der Software "gelöst" und lösen keine externe Fehlermeldung aus, die auf dem DFDR gespeichert würde, allenfalls interne im FADEC Wartungsspeicher. Ich hoffe auf eine detaillierte Beschreibung im Abschlußbericht, was exakt aufgezeichnet wird, wer alles das Ursignal von Schalter bearbeitet bevor es aufgezeichnet wird.
Die Schalter sind mechanisch verriegelt und seitlich geschützt.
Offenbar war die Verriegelung aber bereits Bestandteil eines Service Bulletins. Wie jede mechanische Einrichtung kann auch diese verschleißen. Wie jede bewegliche, federbelastete Einrichtung kann sie in der entriegelten Stellung blockieren (Federbruch, verunreinigungen, Korrosion...). Bei einem Schalter der jeden Flug zweimal betätigt wird, fällt das aber auf, wird gemeldet und abgestellt. Also theoretisch möglich aber unwahrscheinlich.
D.h. die Leitung geht direkt zur FADEC, keine Schaltung o.Ä. dazwischen? Bei Avherald las es sich so, als sei da noch ein Controller zwischen.
Bei manchen Flugzeugen ist z.B. die EEC (Electronic Engine Control) unit dazwischen. Zur exakten 787 Konstruktion habe ich keine Unterlagen.
Interessant zu sehen, das sowohl
GE als auch
RR Probleme mit versagenden Lötstellen in der Triebwerkssteuerung haben.
Dass allerdings zwei Lötstellen mit ähnlicher Funktion für zwei Triebwerke binnen einer Sekunde versagen (und die FADEC glaubt, die Fuel Cutoff Switches stünden auf "Aus") ist ähnlich wahrscheinlich, wie dass ein Meteorit das Flugzeug trifft...
Bei der aktuellen Informationslage ist nicht zu 100% klar, wie es zu dem gleichzeitigen cutoff Signal für beide Triebwerke gekommen ist, ich gehe aber davon aus, dass die detaillierte Soundspektrumanalyse klar zeigen können wird, ob die Schalter physikalisch bewegt wurden, oder nur ein Signal irgendwie gesendet wurde.
Der AvHerald spricht ja auch davon, dass die Triebwerkskonsole zweimal gewechselt wurde, es ist also auch denkbar, dass sich ein Kabel/Stecker gelöst hat, der nicht korrekt befestigt wurde. Keine Ahnung ob beide Schalter über den selben Stecker mit der FADEC verbunfen sind, oder da bewusst getrennte verwendet werden. Aber all diese Szenarien wird der endgültige Bericht ziemlich sicher eines nach dem anderen beschreiben und klar anhand von eindeutigen Daten ausschließen.
Dann wird sich schlimmstenfalls eine "fehlerhafte Komponente" als ursächlich erweisen, für die wir weder Designvorschriften schreiben, noch 100% sichere Prüfvorschriften definieren oder ADs herausgeben können, und bei denen ein Softwareupdate sehr schwierig ist... Und deren Funktion nicht aufgezeichnet wird.
