Login: 
Passwort: 
Neuanmeldung 
Passwort vergessen



Das neue Heft erscheint am 30. März
War früher alles besser?
Frühjahrsflug in die Normandie
EDNY: Slot-Frust und Datenleck
Triebwerksausfall kurz nach dem Start
Der kleine QRH-Bausatz
Unfall: Wer zu oft warnt ...
Engagierter Journalismus aus Sicht des eigenen Cockpits
Engagierter Journalismus aus Sicht des eigenen Cockpits
Abgestürzter Ethiopian Airlines Flug
Sortieren nach:  Datum - neue zuerst |  Datum - alte zuerst |  Bewertung

  412 Beiträge Seite 6 von 17

 1 ... 6 7 8 9 10 11 12 ... 16 
 

18. März 2019: Von Reinhard Haselwanter an Achim H.

Ob die MAX danach sicher ist, kann man m.E. noch nicht sagen... Der increase des Steuerinputs von 0.6° auf 2.5° ist immerhin 4 mal größer als gegenüber der Zertifizierung angegeben...mit diesem starken input wäre ja dann auch eine Fehlfunktion des Systems anders einzustufen gewesen... Die Notwendigkeit für diesen starken Steuerungsinput kam ja durch die Vorverlegung der TW (und damit der starken Verschlechterung des aerodynamischen Verhaltens des Flugzeugs). Das "neue" MCAS wird jedenfalls wesentlich aufwändiger sein müssen, da es (weiterhin) einerseits sicherstellen muss, dass in bestimmten Flugzuständen das Flugzeug weiterhin die Nase nicht hochnimmt, andererseits ein Überstuern (wie möglicherweise bei beiden Abstürzen geschehen) mit so starken Trim-down-inputs auch ausgeschlossen werden muss... Boeing wird mittelfristig nicht umhinkommen, einen komplett neuen Entwurf für ein Narrowbody-Flugzeug zu machen. Je eher sie anfangen, desto schneller kann das wieder auf die Erfolgsspur zurückführen (so dass evtl. sogar ein Teil der Bestellungen in ein paar Jahren schon auf das neue Muster gewandelt werden kann)...

just my 2 cts...

EDIT: Natürlich muss aber vorher eine Lösung für die 737 MAX gefunden werden, denn der Markt verlangt ja die Flugzeuge nicht erst in ein paar Jahren, und Boeing muss auch weiterhin Geld (nicht zuletzt auch für zukünftige Entwicklungen) verdienen.

18. März 2019: Von Matthias Reinacher an Achim H.

Wie würde man denn mit zwei Sensoren die Fehlfunktion eines der beiden erkennen (jetzt mal von "geht auf 0 oder unendlich" abgesehen -- wobei "0" ja ein valider Wert sein kann...)? Crosscheck mit anderen Sensoren? Oder "Mismatch" und dem Piloten in die Hand drücken?

Generell ist es ja attraktiv, immer ein Quorum zu bilden (ungerade Anzahl von Sensoren). Hilft auch nicht immer (siehe oben verlinkter Airbus-Incident), aber im allergrössten Teil der Fälle...

18. März 2019: Von Wolff E. an Matthias Reinacher

Ich würde das "auf die Schnelle" so lösen, dass beide Sensoren den selben Wert zeigen müssen, ist das nicht Fall, MCAS abschalten und Warnung ins Cockpit geben. Des weitern sollte MCAS nicht "unzählige Male" hintereinander "nach vorn" trimmen dürfen, was aber eher kaum passieren, wenn man beide Sensoren vergleicht und nur bei "selben Werten" die Trimmung aktiviert. Natürlich wären drei Sensoren besser, aber das wäre vermutlich deutlich mehr Aufwand, dies zu zertifizieren. Und Boeing braucht eine schnelle Lösung.

18. März 2019: Von Georg v. Zulu-eZulu-schwit-Zulu an Wolff E.

Wären positive Rate-of-Climb sowie negative Beschleunigung nicht Rahmenparameter, die den Usecase auszeichnen, den MCAS abfangen soll?

? Das System soll einen zu hohen Anstellwinkel vermeiden, Steigrate oder Speedabnahme sind sekundär.

Die genannten Sekundärphänomene, also Geschwindigkeitsabnahme und positive RoC wären aber Sicherheitsmerkmale, um zu bestimmen, ob es sich beim vermeintlich gemessenen, zu hohen AoA um eine Fluglage auf den HighSpeed-Stall zu handelt, oder ein Meßfehler wahrscheinlich ist.

Natürlich würde eine Eingrenzung auf diese Fluglageparameter z.B. nicht beim vollen Stall greifen, aber dafür ist das System ja auch nicht gedacht.

18. März 2019: Von Schauss Walter an Wolff E.

Und wenn der Fehler in der Sofware liegt ?

18. März 2019: Von  an Wolff E.

Ich würde das "auf die Schnelle" so lösen, dass beide Sensoren den selben Wert zeigen müssen, ist das nicht Fall, MCAS abschalten und Warnung ins Cockpit geben.

Ganz so einfach ist es wahrscheinlich nicht: Wenn das MCAS kein „Komfortfeature“ sondern ein notwendiges System ist, ohne das der Flieger aus aerodynamischen Gründen nicht Zulassungsfähig wäre, dann ist das Abschalten des MCAS ein Serious Incident.
Das ist zwar wahrscheinlich immer noch besser, als wenn das MCAS den Flieger in den Boden fliegt - aber dafür erhöht sich die Gefahr von Stall-Accidents enorm. Darum hat man es ja.

18. März 2019: Von Wolff E. an 

Deshalb eine deutliche Warnung wenn es ausfällt. Boeing MUSS ja warnen, wenn MCAS aus was für Gründen auch immer, wenn es gestört ist. Es wäre wirklich Murks, wenn Boeing einen Ausfall nicht im Cockpit kommunizieren würde! Und die Warnung mit "max pitch xx Degrees" versehen. Sooo schwer kann das nicht zu programmieren sein.

18. März 2019: Von Wolfgang Lamminger an Wolff E.

wenn aber schon die AoA-Anzeige ein "aufpreispflichtiges Feature" ist?

Ich stelle mir vor, dass sich zumindest die Plausibilität des AoA-Sensors mit seiner Wirkung auf MCAS überprüfen liesse, wenn ich den gemessenen Wert kenne und nicht nur auf einen wildgewordenen Pitch-Down-Trim reagieren muss.

Offensichtlich wird ja der Messwert des AoA-Sensors für MCAS verwendet und nur in Fällen, die die Option eingebaut haben, auch auf dem Display angezeigt?!

18. März 2019: Von Flieger Max L.oitfelder an Georg v. Zulu-eZulu-schwit-Zulu Bewertung: +1.00 [1]

Ich habe schon im Normalflug innerhalb aller erlaubten Parameter Steigraten bis zu 12.000ft/min im Airbus gesehen, wie willst Du denn ein solches Feature von einer positiven ROC abhängig machen? Ditto "abnehmende Geschwindigkeit", AoA wird wohl doch das Zuverlässigste sein.

18. März 2019: Von Willi Fundermann an Wolff E. Bewertung: +1.00 [1]

Heute Morgen in Spiegel Online:

https://spon.de/afrvL

Wenn davon auch nur die Hälfte stimmt, dürfte es für Boeing teuer werden.

18. März 2019: Von RotorHead an Schauss Walter

Das Problem liegt sehr wahrscheinlich an mangelnder Schulung, auch der mangelnden Information seitens Boeing geschuldet.

Boeing hat MCAS deshalb entwickelt, um bei großen AoA eine zusätzliche Vergrößerung des AoA und außerdem Auftriebsverlust durch Abschattung der Tragflächen zu vermeiden. Beides wird bei zu hohem AoA durch die Cowlings der Triebwerke bewirkt.

Bei eingeschaltetem Autopilot besteht keine Notwendigkeit für "MCAS". Der Autopilot vermeidet selbständig zu große AoA.

Wird allerdings per Hand geflogen, kann sich "MCAS" einschalten. Das passiert, wenn es einen zu großen A0A feststellt. In diesem Fall wird der komplette horzontale Stabilizer in Richtung nose down verstellt, offenbar um bis zu 2,5°.

Etwas zu wenig beachtet wurde bis jetzt, dass auch die Steuerkräfte bei der MAX-8 nur etwas halb so groß sind, wie bei den Vorgängermodellen. Das kann gerade beim Start dazu führen, dass ein auf dem Muster noch "unerfahrener" Pilot versehentlich zu viel Pitch zieht wegen der ungewohnten Steuerkräfte oder Mangels Wissens um das MCAS und damit das MCAS auslöst.

Wenn MCAS beim Take-Off auslöst, kann folgende Fehlerkette entstehen:

  1. MCAS aktiviert sich und trimmt das Flugzeug auf nose down;
  2. ser Pilot bemerkt, dass das Flugzeug die Nase senkt und zieht stärker am Höhenruder;
  3. das MCAS regelt nach, weiter mit Schritt 2 bis 2,5° Pitch am Stabilizer erreicht sind;
  4. ein Einschalten des Autopilots in dieser Situation sorgt dafür, dass das Flugzeug zunächst ganz gewaltig die Nase senkt, weil der Autopilot ein derartig vertrimmtes Flugzeug erst einmal wieder korrekt trimmen muss;
  5. schaltet man mangels Kenntnis um MCAS Autopilot und elektrische Trimmung (also auch MCAS) aus und vergisst aber den Stabilizer wieder korrekt zu trimmen, hat man ein Problem;
  6. schaltet man MCAS rechtzeitig aus, fliegt per Hand und überschreitet dann (vielleicht auch wegen der niedrigeren Steuerkräfte) den kritischen AoA bei dem die Triebwerke den AoA aerodynamsich noch mehr erhöhen und außerdem den Auftrieb verringern, hat man ein noch viel größeres Problem.

Anmerkung: Falls sich die Geschwindigkeit in Folge des Nose Downs erhöht, erhöht sich dadurch auch die ungünstige Wirkung des vertrimmten Stabilizers. - Offenbar ein Teufelskreis.

Das geschilderte Szenario lässt sich durch Schulung (und wahrscheinlich nur dadurch) vermeiden. Dazu sind selbstverständlich ausreichende Informationen durch den Hersteller notwendig. - Hier stellt sich mir die Frage, wie man einen Simulator für dieses Muster bauen und zulassen kann, wenn vom Hersteller keine ausreichenden Unterlagen vorliegen, die das Flugzeug, sein aerodynamisches Verhalten und seine Systeme beschreibt...

18. März 2019: Von Schauss Walter an Willi Fundermann

Dazu kommen noch die Probleme mit der USAIRFORCE und die KC46

The USAF says it will not take deliveries again until all production aircraft have been cleared of debris and Boeing has formulated a plan to resolve the issue.

Discovery of foreign object debris (FOD) caused Boeing to ground its undelivered KC-46A tankers at its Washington state facilities for inspections, according to a memo obtained by The Seattle Times.

The USAF and Boeing confirm the issue to FlightGlobal.

https://www.flightglobal.com/news/articles/usaf-suspends-boeing-kc-46a-tanker-deliveries-until-456272/

18. März 2019: Von Alexander Callidus an 

Dazu wird ein großer Teil der 4600 Bestellungen storniert werden, da bin ich schon jetzt fast sicher.

Forbes argumentiert dagegen

18. März 2019: Von  an Alexander Callidus Bewertung: +1.00 [1]

Ja, die Aussage war wohl zu vollmundig. Laß es mich anders sagen: Wenn Boeing das Problem nicht innerhalb von wenigen Monaten in den Griff kriegt, dann werden einige Kunden abspringen. Mehrere haben bereits angekündigt, darüber nachzudenken – vielleicht aber auch, um größere Rabatte auszuhandeln etc.

18. März 2019: Von Ernst-Peter Nawothnig an 

Halbwegs einfach umzusetzende Lösungen scheint es nicht zu geben. Wir dürfen wohl annehmen, auch wenn es nicht nach außen drang, dass Boeing seit dem ersten Absturz mit aller Kraft an dem MCAS-Problem arbeitet. Nicht erst seit dem zweiten Absturz. Da ist es ein schlechtes Zeichen, dass immer noch nichts kommt. Seine Heiligkeit, den Aktienkurs, würde man bestimmt nicht mehr als nötig leiden lassen.

Klar ist AoA das Richtige - wenn es richtig gemessen wird.

Das Absurde ist doch: Software (MCAS) entscheidet, die Nase in den Boden zu rammen. Aus Sicherheitsgründen, um den Highspeed-Stall abzuwenden. Andere Softwarekomponente brüllen gleichzeitig: Terrain, Terrain! Die (noch unbewiesene) These: Hier spielt Software verrückt und bringt ein Flugzeug zum Absturz, mit entweder schwieriger oder nicht vorhandener Möglichkeit für die Piloten zum Eingriff.

Ich frage mich schlichtweg: Gibt es einfache Parameter, die den Software-Systemen zur Verfügung stehen, und deren Werte ein "No-Go" für die Entscheidung von MCAS zum Eingriff hätten sein müssen? Und eine negative RoC und eine Zunahme an Geschwindigkeit (mit satten Basiswert über dem Stall) könnten bei erster Überlegung meinerseits solche "No-Go"-Kriterien für einen MCAS-Eingriff sein. Diese "No-Gos" lägen zwar auch bei einem Full-Stall vor (P.S.: Und wären für die Jungs von AF447 ganz hilfreich gewesen), aber m.W. haben weder Airbus noch Boeing im Pflichtenheft stehen, einen Full-Stall automatisch auszuleiten.

P.S. Du erlebst als Programmierer halt manchmal, dass ein Code-Block, den Du für den Fall X geschrieben hast, auch aktiviert wird, wenn Fall Y, der völlig anders gelagert ist, eintritt: Weil Du Dich zu sehr auf den Fall X konzentriert hast, und nicht berücksichtigt hast, dass Fall Y auch für Dein Handlungskriterium zutrifft. Das können Banalitäten wie z.B. eine fehlende Tiefpassfilterung von Meßwerten sein, oder schlichtweg zu wenig Fantasie.

18. März 2019: Von Tee Jay an  Bewertung: +2.00 [2]

Ich zitiere: "As Boeing hustled in 2015 to catch up to Airbus and certify its new 737 MAX, Federal Aviation Administration (FAA) managers pushed the agency’s safety engineers to delegate safety assessments to Boeing itself, and to speedily approve the resulting analysis."

Quelle: https://www.seattletimes.com/business/boeing-aerospace/failed-certification-faa-missed-safety-issues-in-the-737-max-system-implicated-in-the-lion-air-crash/

Selbst-Zertifizierungen sind schon was Feines. Daß die zertifizierte Fliegerei auch alles bei uns aus der UL Fliegerei abkupfern muß...

Und noch ein Zitat:

"Both Boeing and the FAA were informed of the specifics of this story and were asked for responses 11 days ago, before the second crash of a 737 MAX last Sunday."

18. März 2019: Von Flieger Max L.oitfelder an Georg v. Zulu-eZulu-schwit-Zulu Bewertung: +1.00 [1]
  1. Mit High-speed stall hat das MCAS nichts zu tun
  2. Full stall gibt es bei Airbus im Normal Law gar nicht, das Normal Law verhindert aktiv ein Ansteigen des AoA über Alpha prot hinaus.

Max, ich habe auch nicht vom Normal Law geschrieben, sondern nur mein Gedankenspiel eines "besseren MCAS" am Beispiel des Full-Stalls relativiert. Eben am Beispiel von AF447, wo es möglicherweise etwas gebracht hätte, wenn eine Software die überforderten Piloten overruled hätte und "Nose down, ihr Idioten" erzwungen hätte.

Zu eins: Im Prinzip finde ich das Rollenspiel schon ganz hilfreich: Ich als ein fiktiver Programmierer des MCAS-Systems, Du als Pilot eines Airliners. Ich habe als Programmierer sogar ein gewisses basales Verständnis von Aerodynamics aus Theorie und Praxis, und implementiere eine Routine, die bei zu hohem AoA die Nase runter zwingt. Ich programmiere weiter vorgeblich korrekt Begleitumstände: Autopilot off, Clean configuration. Vielleicht mache ich einen Fehler, dass das Ganze trotzdem auch bei Autopilot on oder Flaps unter bestimmten Umständen eingreift (ja, das ist grundsätzlich denkbar, dass das System abweichend von der Spezifikation arbeitet, nichts anderes ist mein Alltag). Nun hat (fiktiv) meine Software Lionair und Ethopian in den Boden gerammt. Es ist als Programmierer oft so, dass Du 20 mal auf den Code starrst (oder andere darauf starren) und niemand den Fehler findet. Angenommen, es gibt tatsächlich keinen Fehler in der Software - es liegt nur am falschen Messwert des AoAs. In welcher Weise würdest Du mich als Programmierer anschreien und sagen: "Hey, Du kannst doch nicht die Nase runter trimmen, wenn ..."? Wenn was? Meine erste Antwort wäre: Wenn das Flugzeug beschleunigt und sinkt. Dann ist mutmaßlich das Abschattungskriterium nicht vorliegend, auch wenn der AoA es suggeriert. Um die Frage geht es mir.

Wenn bei AF447 das normal law wieder aktiviert geworden wäre dann hätte es genau das gemacht: Nase runter, trotz Full back Sidestick...

Aber es muss bei Bedarf deaktiviert werden können (bei AF nicht zutreffend).

19. März 2019: Von Mark Juhrig an RotorHead Bewertung: +1.00 [1]

ich denke das Hauptproblem für die Piloten war, dass sie (vermutlich) nichts von der Existenz und Funktionsweise des MCAS wussten.

Hier (https://www.satcom.guru/2018/11/stabilizer-trim.html) gibt es eine schöne Beschreibung diverser Höhenruder-Trim-Systeme inkl. B737NG. Dort ist auch die Funktion der "Column Cut-Out Switches" der 737NG-Trimmung beschrieben. Sollte der AP z.B. "wie verrückt" nach auf Kopflastig trimmen und der Pilot per Yoke (Column) dagegenhalten, dann wird der Trim-Motor über den Column-Cut-Out-Switch abgeschaltet, solange der Pilote am Steuerhorn zieht.

Beim 737 MAX MCAS führt jedoch Aktivierung der Column-Cut-Out-Switches (durch Ziehen am Steuerhorn) NICHT zur Deaktivierung des MCAS, siehe hier:

Boeing describes MCAS as a result of a handling quality shortcoming encountered in an accelerated stall, that would be likely be tested as a wind-up turn. The pilot holds airspeed and progressively increases bank angle and back pressure to result in stalling at high load factors. The flight condition is most likely entered with the aft column travel beyond the column cutout threshold. If the aft column cutout was active, MCAS would be inhibited before it could do anything. For this reason, I think Boeing decided to disable the column cutout feature for MCAS, via autopilot software change. (Quelle: https://www.satcom.guru/2018/11/737-mcas-failure-is-option.html).

Die Steuerhornkräfte bei völlig vertrimmten Höhenruder der B737MAX werden mit ca. 400N/40kg pro Seite (Summe 800N/80kg) angenommen (Quelle: https://www.quora.com/Following-the-latest-737-Max-8-aircraft-crash-should-one-be-worried-about-flying-on-them-Is-there-a-significant-design-flaw-in-this-plane-that-makes-it-the-DC10-of-the-modern-era). Das passt insofern, dass wir mal im Rahmen eines Projektes die Steuerkräfte einer C172 vermessen haben. Bei Trimmstellung "Voll Nose Down" braucht es über 300N (300N war das Maximum was der Sensor messen konnte) um den Flieger auf konstanter Höhe zu halten (bei 95 KIAS).

Zum Thema "nichts davon wissen": Ich habe mal die Steuerung eines Fliegers an meinen Mitflieger (auch Pilot) übergeben, ohne ihm zu sagen, dass der Autopilot (Heading-Mode) aktiv ist. Er wollte einen kleine Kurskorrektur vornehmen und ist am aktivierten AP gescheiter. Diesen zu übersteuern, wäre ein leichtes gewesen, aber die ungewohnten Steuerkräfte (durch den dagegensteuernden AP) waren im wohl derart suspekt, dass er mit der Situation nicht klar kam. Dazu kam noch, dass er nicht wusste, dass der Flieger einen AP hat.

Viele Grüße Mark

19. März 2019: Von  an Flieger Max L.oitfelder

Da habe ich andere Informationen. Der Leiter des A330-Trainings einer führenden deutschen Airline sagte mir im Gespräch, dass sich das Flugzeug - zumindest in der letzten Phase des Absturzes - in einem Flugzustand befand aus dem es wahrscheinlich nicht mehr zu recovern war.

Er meinte auch, dass sich dieser aerodynamische Zustand im Simulator nicht vollständig realistisch darstellen lässt. (Es kann sein, dass er sagte, dass man das zu einem späteren Zeitpunkt konnte, aber dazu kann ich mich nicht präzise erinnern.)

19. März 2019: Von  an Georg v. Zulu-eZulu-schwit-Zulu Bewertung: +1.00 [1]

Wenn das Alles so ist, wie von vielen vermutet, dann handelt es sich tatsächlich um einen nicht nur bei Flugzeugen sehr typischen Design-Fehler der Software, der allerdings viel früher im Prozess passiert ist und viel schwieriger zu beheben ist. Solche Fehler haben schon sehr viel - wenn auch meist nur finanziellen - Schaden angerichtet. Die aktuellen GPS-Rollover Probleme von Avidyne sind ein anderes Beispiel des gleichen Design-Fehlers:

Die Rede ist von „Seitennutzung von Daten“. Oder anders formuliert: Software-Entwickler und -Architekten sind in der Regel sehr gut darin, kreativ Datenquellen anzuzapfen um für ihrProgramm alle notwendigen Informationen zu bekommen, aber sehr schlecht darin, die Qualität und Seiteneffekte dieser Datenquelle zu verstehen.

Beispiel hier MCAS: Es gibt ein für die Flugsicherheit kritisches Problem mit der aerodynamischen Stabilität des Flugzeuges. Um dieses technisch zu beheben braucht man ein System, das den AoA begrenzt. Denkt der Programmierer: „Klasse, nehme ich doch einfach den AoA der eh gemessen wird und setze darauf meinen Algorithmus an“. Der Denkfehler ist nun: Es wird heute in einem solchen Flugzeug gar kein AoA für sicherheitskritische Anwendungen gemessen! Das Datum „AoA“ liegt zwar scheinbar schon vor, nicht aber in einer Qualität und Zuverlässigkeit, die für sicherheitskritische Anwendungen notwendig ist.

Daher kann eine Veränderung der Software zwar temporär vielleicht dafür sorgen, dass MCAS nicht mehr so viele Flugzeuge in den Boden fliegt - das eigentliche Problem kann Software aber niemals lösen: Das Shannon-Theorem hat sogar theoretisch bewiesen, dass Daten durch Verarbeitung nicht besser werden können (Shit in / Shit out). Aus einer AoA-Messung die nicht für sicherheitskritische Anwendungen geeignet ist wird auch durch die beste Software keine bessere Messung.
Für eine nachhaltige Lösung des Problems müssen also sich zuerst die Ingenieure überlegen, wie man den AoA entsprechend zuverlässig messen kann (mehr, bessere, andere Sonden, etc.) bevor die SW-Ingenieure dann darauf die Software bauen können.


  412 Beiträge Seite 6 von 17

 1 ... 6 7 8 9 10 11 12 ... 16 
 

Home
Impressum
© 2004-2024 Airwork Press GmbH. Alle Rechte vorbehalten. Vervielfältigung nur mit Genehmigung der Airwork Press GmbH. Die Nutzung des Pilot und Flugzeug Internet-Forums unterliegt den allgemeinen Nutzungsbedingungen (hier). Es gelten unsere Datenschutzerklärung unsere Allgemeinen Geschäftsbedingungen (hier). Kartendaten: © OpenStreetMap-Mitwirkende, SRTM | Kartendarstellung: © OpenTopoMap (CC-BY-SA) Hub Version 14.22.03
Zur mobilen Ansicht wechseln
Seitenanfang