FalconJockey Geschrieben 29. Oktober 2021 Teilen Geschrieben 29. Oktober 2021 Da kommen Warnungen auf den Bildschirmen und auch ein ziemlich eindeutiges Audiosignal. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Frank Holly Lake Geschrieben 29. Oktober 2021 Teilen Geschrieben 29. Oktober 2021 (bearbeitet) Jedes Flugzeug über 5,7 Tonnen muss es inzwischen können, Warnungen zu geben. Und das soll auch so sein, um Piloten nicht in Schwierigkeiten zu bringen. Sollte es ein Fehlalarm sein , soll der Pilot entscheiden können, doch noch abzuheben oder abzubrechen. Das Problem ist aber immer wieder, das die Piloten die Warnungen Ignorieren oder nicht war nehmen. Vor noch gar nicht all zu langer Zeit hat ein A320 ohne Fahwerk eine Landung hingelegt. Als die Crews den Fehler bemerkten starteten Sie wieder durch und stürzten ab, weil alle Ölleitungen der TW durch das rutschen über die Bahn zerstört wurden und somit die Ölversorgung komplett in kurzer Zeit ausfiehl, die TW fest gingen. Da waren unzählige Warungen auf dem gesamten Anflug. Grüße Frank Bearbeitet 29. Oktober 2021 von Frank Holly Lake Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Alexh Geschrieben 29. Oktober 2021 Teilen Geschrieben 29. Oktober 2021 vor einer Stunde schrieb Manfred J.: Hallo, Kann beim Airbus - A320 Familie, sowas auch vor kommen? Falsche Konfiguration beim Start?? LG Manni Man gibt in der MCDU Performance Page die Klappenkonfiguration für den Start ein. Diese wird dann beim Drücken der T.O. Config-Taste in der Before Takeoff Checklist mit der gesetzten Klappenstellung verglichen und bei fehlender Übereinstimmung die T.O. Config-Warnung ausgegeben. Diese ist eigentlich nicht zu überhören oder zu übersehen. Der einzige Fehler den man meiner Meinung nach tatsächlich machen könnte ist, dass man eine andere Klappenstellung für den Start wählt und eingibt, als man gerechnet hat. Aber wer weiß ob es nicht auch Leute gibt, die kreativ genug sind alle Checklisten und Warnungen auszulassen und zu ignorieren. Ich hoffe nicht. Gruß Alex 1 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Urs Wildermuth Geschrieben 30. Oktober 2021 Teilen Geschrieben 30. Oktober 2021 Am 28.10.2021 um 13:18 schrieb FalconJockey: Es kann sein, dass in der Zwischenzeit starke Windböen die/ein Höhenruder beschädigt haben. Es sieht jedenfalls schwer danach aus. Oder ob allenfalls doch irgendwelche Gust Locks installiert und dann nicht weggemacht wurden. Na ja, das Heck ist ja gut erhalten, da sollte man schon rausfinden, was da war. Würde mich nicht wundern, wenn da ein AD folgt, welches bei längerem Stillstand eine gründliche Überprüfung des Höhenruders auf allen DC9/MD80 fordert. Wäre sicher nicht falsch, wenn man sieht, das das doch mit einiger Regelmässigkeit vorkommt. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
FalconJockey Geschrieben 9. November 2021 Teilen Geschrieben 9. November 2021 Update von Juan Browne: - laut Aussage des Kapitäns konnte bei erreichen von Vr nicht rotiert werden - Startabbruch führte zum Overrun, reverse wurde genutzt, dann aber nach dem Stillstand deaktiviert - Parallelen zu einem ähnlichen Unfall aus 2017 werden gezogen, inklusive Tests am Höhenruder Anschauen! 1 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
spornrad Geschrieben 11. November 2021 Autor Teilen Geschrieben 11. November 2021 (bearbeitet) Update vom NTSB: https://www.ntsb.gov/news/press-releases/Pages/NR20211110b.aspx Beide Höhenruder waren durch Sturmschaden blockiert, genau wie bei dem Ameristar Unfall 2017. Die müssen für die Zukunft Gustlocks vorschreiben, auch wenn die schwer anzubringen sind. Und elevator position indicator mit 80 kt check wie bei der DC-8. Gruss Bearbeitet 11. November 2021 von spornrad Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
AustrianSimon Geschrieben 11. November 2021 Teilen Geschrieben 11. November 2021 (bearbeitet) 32 minutes ago, spornrad said: Update vom NTSB: https://www.ntsb.gov/news/press-releases/Pages/NR20211110b.aspx Beide Höhenruder waren durch Sturmschaden blockiert, genau wie bei dem Ameristar Unfall 2017. Die müssen für die Zukunft Gustlocks vorschreiben, auch wenn die schwer anzubringen sind. Gruss In Detroit 2017 war es nur das rechte Höhenruder, das durch Sturmschaden blockiert war aber die Rotation verhinderte. Das NTSB hat damals zwar nur als Contributing Factor, aber doch erheblich lamentiert im Final Report: "the lack of a means to enable the flight crew to detect a jammed elevator during preflight checks for the Boeing MD-83 airplane." Ich gehe daher davon aus, daß der Flight Control Test normal verlief (wie in Detroit), weil die Control Tabs der Elevators sich normal bewegen ließen, und das Problem erst im Startanlauf bemerkbar wurde beim Rotieren, analog zu Detroit. Gust Locks könnten zwar Schäden an der Elevator Aufhängung verhindern, nicht aber andere mögliche Ursachen von blockierten Elevators, daher scheint mir, es wäre noch wesentlich wichtiger den Flight Control Test so zu verbessern, daß die Crew rechtzeitig eine Blockade der Elevators bemerkt und nicht erst bei Vr. Wenn ich mir die Position der Elevators in der Endposition anschaue (ich war von Anfang an sicher, die Elevators waren blockiert, die hätten eigentlich herunterhängen müssen, und war sicher, das war der Grund des Startunfalls), sind die auf einer Linie mit dem Stabilizer, daher wäre ich nicht sicher, daß ein 80 Knoten Check der Elevator Position auf einer Anzeige hier ausreichend gewesen wäre, die Blockade zu erkennen. Fällt hier der FAA wieder einmal auf die Füsse, daß man NTSB Empfehlungen oft ignoriert oder viel zu spät umsetzt? Das NTSB beklagt ja seit Jahrzehnten, daß ihre Empfehlungen nicht oder nur schleppend umgesetzt werden, zumeist erst nach einer Wiederholung solcher Unfallursachen. Servus, Simon Bearbeitet 11. November 2021 von AustrianSimon Gedanken zur Elevator Position Indication eingefügt Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
spornrad Geschrieben 11. November 2021 Autor Teilen Geschrieben 11. November 2021 (bearbeitet) Bei der DC-8 - die ein ähnliches, aber durchgängiges Höhenruder hat - gab es wie gesagt nach ähnlichen Unfällen 1978 eine AD, die den Einbau eines "elevator position indicators" EPI im Panel vorschrieb sowie den Test der Freigängigkeit der Höhenruder bei 80 kt im Startlauf, vor Erreichen von V1. Beschrieben in diesem Unfallbericht hier: https://flightsafety.org/ap/ap_oct03.pdf Edit: (Bei der DC-8 wurde gemäss AD per EPI der Vollausschlag des im Startlauf angeströmten Höhenruders bei 80 kt getestet, also vor Erreichen der Rotationsgeschwindigkeit voll gedrückt/ voll gezogen gecheckt, ob der Elevator in beide Richtungen voll ausschlägt) Vielleicht wäre ein langer Besenstiel für den Vorflugcheck auch eine Variante die Freigängigkeit zu checken 45 minutes ago, AustrianSimon said: Gust Locks könnten zwar Schäden an der Elevator Aufhängung verhindern, nicht aber andere mögliche Ursachen von blockierten Elevators, Hier ist ja wieder, wie 2017 nur auf einer Seite, das Problem die gewaltsame Überstreckung des "Kniegelenks" der Servotab-Anlenkung durch schlagendes Ruder im Wind. Das überstreckte Kniegelenk (overcenter) kann danach nicht mehr auf Kompression wie vorgesehen einknicken, blockiert stattdessen / verbiegt zur Seite und blockiert damit das ganze Ruder, statt wie vorgesehen das Tab auszulenken. Die viskösen Dämpfelemente verhindern dieses fatale Ruderschlagen im Wind offenbar nicht zuverlässig. Gust locks würden dieses Überstrecken der Anlenkung zuverlässig verhindern. Bearbeitet 11. November 2021 von spornrad Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
AustrianSimon Geschrieben 11. November 2021 Teilen Geschrieben 11. November 2021 46 minutes ago, spornrad said: Edit: (Bei der DC-8 wurde gemäss AD per EPI der Vollausschlag des im Startlauf angeströmten Höhenruders bei 80 kt getestet, also vor Erreichen der Rotationsgeschwindigkeit voll gedrückt/ voll gezogen gecheckt, ob der Elevator in beide Richtungen voll ausschlägt) Ich habe auch zunächst einmal in diese Richtung gedacht, aber bin davon abgekommen. Bei 80 Knoten wäre sehr wohl möglich, das Bugfahrwerk vom Boden abzuheben und dann mit voller Wucht zurück auf die Bahn zu schmettern, und das könnte wohl verheerende Auswirkungen haben. Ich denke daher eher in die Richtung, daß die Elevators ja vor dem Startanlauf durchhängen (trailing edge down) und dann im zunehmenden Luftstrom sich "aufrichten" und in die Position entsprechend den Control Tabs gehen. Es entsteht also eine Bewegung der Elevators. Wenn diese Bewegung fehlt, könnte das detektiert werden und angezeigt/gewarnt werden. Diese fehlende Bewegung könnte detektiert werden über mehrere Möglichkeiten, zum Beispiel über einen Positionsgeber. Verändert sich der Positionsgeber im Startanlauf mit zunehmender Geschwindigkeit in die richtige Richtung, wäre der Elevator frei. Ich könnte mir auch vorstellen, das über die Kräfte zu messen/detektieren, denn wenn die Kräfte auf dem Elevator im Startanlauf zunehmen statt abzunehmen (weil der Elevator blockiert ist), dann könnte man die Warnung auch auslösen. Man könnte auch die Control Tab Position und Elevator Position vergleichen und bei entsprechender Differenz etwa bei 60+ KIAS die Warnung auslösen. Da gibt es also mehrere Möglichkeiten, die technisch recht einfach wären. Welche davon nun wirklich in allen Temperaturbereichen funktioniert und alle Betriebsbereiche und Möglichkeiten abdeckt, usw. müßten die Designer klären, das ist kein Job für nur ein paar Minuten Überlegung ... Die Idee ist also noch sehr unausgegoren und nicht bis in die Extrema durchgedacht. Zum Beispiel habe ich den Fall noch nicht durchgedacht, wie die Situation aussieht, wenn etwa der Elevator sich hebt im Startanlauf, aber dann nicht mehr Nose Up bewegt werden kann (sondern nur noch weiter Nose Down). In all diesen Überlegungen könnte u.U. auch zum Vorschein kommen, warum bisher die Erkenntnisse von Detroit noch nicht umgesetzt wurden, und auch warum man dem DC-8 AD zur Lösung dieses Problems nicht nähertrat - ich kann mir nur vorstellen, daß man den Verlauf der Elevatorbewegung überprüfen muß, man kann aber gerade im Startanlauf nicht die Aufmerksamkeit der Crew nur auf dieses eine Detail richten, und ein Momentanblick bei 80 KIAS reicht nicht). Servus, Simon Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
spornrad Geschrieben 11. November 2021 Autor Teilen Geschrieben 11. November 2021 (bearbeitet) 3 hours ago, AustrianSimon said: Bei 80 Knoten wäre sehr wohl möglich, das Bugfahrwerk vom Boden abzuheben und dann mit voller Wucht zurück auf die Bahn zu schmettern,... Bin mir eigentlich ziemlich sicher, dass sich für die DC-9 Varianten genau wie für die DC-8 ein Geschwindigkeitsband unter V1 findet, wo die Rudertabs schon genug angeströmt werden um die Ruder zu bewegen, die Ruder aber noch nicht die Kraft für eine Rotation aufbringen. Das Bewegen der frei aufgehängten und balancierten Ruder braucht ja nicht viel Kraft, und mit EPI kann der Pilot dann die Freigängigkeit sehen. Bei der DC-8 funktioniert das Verfahren ja seit über 30 Jahren. Bin gespannt, ob sich NTSB darauf besinnt oder sich was Neues ausdenkt. Gruss Albrecht Bearbeitet 11. November 2021 von spornrad Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
FalconJockey Geschrieben 11. November 2021 Teilen Geschrieben 11. November 2021 Ich bin mir nicht sicher, ob man für ein so rares und bald aussterbendes Flugzeug noch so einen Aufwand betreiben soll. Es würde schon reichen, nach längeren Standzeiten, per Hebebühne, Hochtreppe oder Gerüst (eines davon gibt es überall), die Freigängigkeit der Höhenruder und die Intaktheit der Gelenke zu prüfen. Fertig. 1 1 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.