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
Einerseits ist der Hersteller primär verantwortlich, sichere Systeme zu entwickeln. Behörden legen Kriterien fest, wie das zu geschehen hat, und prüfen nach.
Andererseit schreit alles danach, dass die Behörde alles penibel prüfen soll, und erst nach solcher Prüfung das System freigegeben wird, was alles langwierig und teuer macht.
Also macht man hier der FAA gleichzeitig den Vorwurf, ein System von Boeing zu einfach durchgewunken zu haben, und eine schnelle Lösung zu verhindern...
Nein, falsch. Im Moment stehen die Kisten am Boden, wo sie hingehören. Und die FAA bemüht sich, jetzt ihren Job richtig zu machen. Dafür sollte sie sich die nötige Zeit lassen, statt "beta 2.0" durchzuwinken. Vorher war die Situation die, dass die aktive Analyse von Boeing: "Wir haben da wohl etwas geschlampert programmiert - jetzt mit 2 statt 1 Sensoren und nur einmal eingreifen" Menschenleben gerettet hätte.
Ich möchte meinen Punkt nochmal an einem Beispiel deutlich machen, dass die Mehrzahl kennt: AutoRouter.
In AutoRouter kann man einen GAR direkt filen, wenn es nach UK geht. Großartig. Daneben filed man einen Flightplan. Autorouter hat nun eine Funktion, über die ich gestolpert bin: Der macht tatsächlich dumme Dinge wie die Anzahl der Personen im GAR mit der Anzahl der Personen im FPL zu vergleichen. Das hat niemand Achim ins Pflichtenheft geschrieben, keine EASA, keine FAA - und es geht auch nicht um Menschenleben. Aber Achim hat sich um diesen Fall gekümmert. Einfach einen billigen Plausibilitätscheck eingebaut, der sagt: "Hey, da ist was inkonsistent!". Obwohl es nur um kleine formale Fehler geht.
So programmiert man richtig, sogar "beyond expectations".
Wie man falsch programmiert, sieht man bei Boeing.
Der Vergleich hinkt, weil Autorouter kein lebensnotwendiges Echtzeit-Regelungssystem ist! MCAS ist das.
Ja, wenn MCAS auf Grund falscher Daten falsch regelt, dann sterben leider Menschen. Das Problem ist aber (auf Grund eines fundamentalen Hardware-Designfehlers): Wenn MCAS nicht funktioniert, dann sterben auch Menschen.
Während es in Deinerm Autorouter-Beispiel einen einfachen Safe-State und damit eine einfache Regel bei Dateninkonsistenten gibt („WENN Daten inkonsistent DANN nix machen bis der User die Inkonsistenz aufhebt“) besteht die bei MCAS offensichtlich nicht. Gäbe es sie, dann wäre es ja extrem einfach gewesen, nach Lion-Air erst mal das MCAS in allen Fliegern stillzulegen.
In so fern wäre ich echt vorsichtig dabei, die Schuld den Boeing-Programmieren zu geben: Natürlich könnten sie einfach im Programm feststellen, dass Eingangswerte nicht zusammen passen - aber es kann sich kein Programmierer sondern nur ein Aerodynamiker überlegen, was das System eigentlich machen soll, wenn es solche Inkonsistenten Werte gibt. In der Luft anhalten und warten, bis der Pilot angeklickt hat, welche AoA-Sonde wohl richtig anzeigt geht ja leider nicht...
Ich würde sogar sagen, dass MCAS wal wieder ein gutes und leider sehr tragisches Beispiel dafür ist, dass es eine sehr dumme Idee ist, Hardware-Designfehler mit Software beheben zu wollen.
Deine Kritik, dass "Nicht-Handeln" anders als bei Auto-Router ebenfalls eine gefährliche Situation ist, ist richtig.
Sie berücksichtigt aber nicht, dass den Programmierern oder Systemarchitekten alle Daten vorlagen, um die richtige Entscheidung zu treffen. Es gibt diverse Flugzeuge, die nicht mal die "digitale AoA-Anzeige" in Form der Tröte haben. Hier fliegen Piloten anhand diverser anderer Parameter, die einen Rückschluss auf den AoA zulassen, durchaus überwiegend erfolgreich Starts und Landungen: Habe ich bei Gewicht X Speed Y, ist der AoA vermutlich noch im unkritischen Bereich. Lutz hat dargelegt, dass man vermutlich für jedes IAS, GS und RoC eine Flugsituation finden kann, in der der AoA kritisch ist, auch wenn die anderen Daten "sauber" sind. Stimmt vermutlich. Verknüpft man das aber mit der Historie, also dem Zustand ein paar Sekunden vorher, kann man durchaus die Plausibilität beurteilen: Bleiben IAS, ROC, GS, Schub und Pitch weitgehend konstant, ist eine radikale Änderung des AoA um 40 Grad grob unplausibel. Boeing hat aus zig Meßwerten, die einen Aufschluss zur Fluglage zulassen, genau einen herausgegriffen und sich auf ihn bedingungslos verlassen, ohne ihn mit diversen anderen, darunter einem redundanten Parameter (dem 2. AoA-Sensor) auch nur ansatzweise abzugleichen.
Anders argumentiert:
Wir wissen alle, dass wir bei der Tröte drücken sollten
Ausnahme 1: "Das gilt nicht beim Flare" hat Boeing ja noch mitbekommen
Niemand von uns würde aber - weil seine Tröte einen Defekt hat und im Steigflug plötzlich dauertrötet - sein Flugzeug erst in den Levelflug, dann in den Sinkflug bringen, und dann mit 80 Grad in den Boden rammen.
Deswegen nehme ich mir raus, bei der "neuen" MCAS-Version auch von "beta 2.0" zu sprechen.
Wir widersprechen uns gar nicht. Was ich meine ist nur, dass 1.) MCAS immer eine „Beta-Krücke“ sein wird, weil es das eigentliche Problem des Flugzeugs nicht behebt und 2.) genau diese Regeln die Du bzgl. inplausiblem AoA beschreibst nicht von einem Programmierer, sondern nur von einem Aerodynamiker kommen können.
Stellen wir uns doch mal so was ähnliches wie MCAS in Hardware und nicht in Software vor:
Da „merkt“ jemand, dass man bei einem Flugzeug am Höhenruder so stark ziehen kann, dass es trotz voller Motorleistung in den Stall geht. Da man den Piloten nicht zutraut, solche Flugzustände selber zu vermeiden braucht man eine technische Lösung. Das Problem wird damit behoben, dass an am Knüppel eine mechanische Sperre anbringt, dass man ihn nicht mehr zu weit nach hinten ziehen kann. Jetzt merkt aber plötzlich jemand, dass man dann in Turbulenzen nicht mehr immer den notwendigen Ruderausschlag geben kann, um das Flugzeug auf Höhe zu halten. Also wird an die mechanische Sperre ein Klappmechanismus angebaut, mit dem man sie in Turbulenzen wegklappen kann.
Klingt absurd - aber genau auf diesem Weg ist Boeing mit der MCAS-Software...
Es gibt wie üblich viele unterschiedliche Faktoren, die zusammen die Katastrophe herbeigeführt haben. Die folgenden Punkte sind natürlich nur Spekulation.
Das Verhalten des AoA-Vanes:
"Why did it flip to ~75deg at 150kn? More interestingly, why did it flip back to "normal" for a moment just before end of flight before flipping back to error?"
"If the vane had been lost the AoA sensor would become unbalanced about its usual axis of rotation. The internal balance weight** would then cause the axle to be subject to movement when the aircraft transitioned from +g to -g. +g would cause the indication of +AoA. (If I have got this the right way round). [...] It therefore seems quite likely that the vane was lost or perhaps damaged soon after take off, perhaps by a bird strike or otherwise. Note however that if the vane had been bent back its balance would be moved in the other direction and its aerodynamic influences would still have been felt so I think that the best conclusion consistent with the data is that the vane was lost."
Die "Add-On Software MCAS":
"The third MCAS activation lasting 9 or so seconds starting at 05:40:41 did not alter stab pitch trim because the FO had just cut power to the stabilizer jackscrew motor. The report glibly notes that fact. But why did MCAS even try to activate, as if sitting there fat, dumb and stupid? Exactly what type of coding allows the FCC to attempt to command AND trim when both STAB TRIM switches are already set to CUTOUT? Seems the designed use case never anticipated this sequence."
"0. Of course MCAS MUST NOT BE operative with AOA disagree. Minimal software mod. 1. one AOA clearly fails, why not use a switch to transfer everything to the other (manually or automatically). It's a 3 way switch (AOA input L/NORM/R). In the event of stick shaker on, AOA disagree, check if any AOA is stupid (75 is quite stupid), switch to the other side, no more alarms in the cabin, crisis over in 10s tops. minimal wiring loom mod. Even if you don't do it: 2. We have now perfect data about the influence of AOA over airspeed. 30 knots tops over the full AOA range and airspeed. Probably 15 knots 0 to 15 degrees 0 to 300 knts, probably less than 5 knots in the really tricky areas (slow). Upon AOA disagree, both airspeeds should use a default AOA value(4 deg maybe) instead of throwing UAS. and offer a reading with a possible +-7 knot deviation. But keep autothrottle and autopilot, maybe a caution message (airspeed calculation inacurate, stay 20 knots away from limits). Not a really disturbing unreliable airspeed, just because of a few knots. Minimal software mod. 3. Same with altitude. (altitude calculation inaccurate, stay 1000 feet clear from limits). Minimal software mod. So that the only remaining alarm would be a stick shaker plus AOA disagree, and you still have autopilots. Much, much easier to handle. But if this is still enough for you to have the aircraft out of trim and miss speed management, 4. If speed goes over 280, message: reduce speed to regain trim ability). Minimal software mod. My point is: most probably ANY of those mods would have saved the day, and all of them are pretty evident. To me the problem is simply a huge lack of effort at design level to 1) Imagine 2) prepare for failures. "
"To understand the blip trims one must have flown fast jets at low altitude. At the speed ET302 is flying, 360kts, it?s hypersensitive to trim. The least trim action and the aircraft reacts violently. Any trimming is in short blips. [...]
But the aggressive MCAS, trimming with a speed 50% higher than the pilot and for a full nine seconds, kicks in at 8 with a force they didn?t expect. Speed is now at 375kts and MCAS was never designed to trim at these Speed/Altitude combinations. Dynamic pressures, which governs how the aircraft reacts to control surface movements, is now almost double it was when last MCAS trimmed (Dynamic pressure increases with Speed squared).
[...]
If the elevator reacts to these displacements, at the Dynamic Pressure we have, we should have seen the diving stop. The lack of reaction to the large Control Column displacement of two Pilots pulling makes me think we now have blowback. This is not a design fault, we are well beyond Vmo. But it explains the rapid dive, unhindered by the Pilots? actions.
It?s easy to say ?Why didn?t they trim then??. Because they are going down at 20 degrees nose down (which is a lot, a normal landing approach is 3°) and at 400kts. Then you just pull for all you have. And the aircraft is not reacting to the largest Control Column displacement since takeoff. This makes them pull even harder, the aircraft is unresponsive and they are fighting for theirs and all the passenger lives.
"
Aus einem anderen Post:
"EASA document from Feb 2016 allegedly states that electric trim would not work above 230 knots. That might explain why they re-engaged trim (if the indication that they did re-engage trim is correct)...
Might be a good time to reiterate the relevant part from the document:
"The increased safety provided by the Boeing design limits on the thumb switches (for out-of-trim dive characteristics) provides a compensating factor for the inability to use the thumb switches throughout the entire flight envelope. Furthermore, the additional crew procedures and training material will clearly explain to pilots the situations where use of the trim wheel may be needed due to lack of trim authority with the wheel mounted switches."
"
Punkte, die die Piloten ggf. hätten anders machen können:
"The press are of course having a field day saying that HAL drove them into the ground despite the pilots doing the correct procedure.However, the errors are clear here and they're not made in Seattle. -------->incorrect response to Unreliable airspeed(hand control to FO,and land) -------->repeated attempt to engage AP A despite left side sensor problems -------->decision to retract flaps in a MAX-8 following unreliable airspeed(unwise) -------->failure to cutout trim switches prior flaps retraction if crew felt the need to climb to MSA for whatever reason(cant think of one) --------->failure to counteract MCAS proportionately using opposing trim... Lionair counteracted MCAS in this fashion over 20 times.It buys time. --------->having belatedly recognized the need to cutout trim switches the pilot either doesnt ask the copilot to trim ANU manually or the copilot doesnt know how to operate manual trim (manual handle button must be depressed before it will release)....relates to training and crew composition...200 hour pilots dont belong in airline operations,pay to fly,SOP rote over airmanship etc etc"
"Punkte, die die Piloten ggf. hätten anders machen können:"
Wenn der Trim per Trimmrad oberhalb von 230 kts, sicher aber in der Region der Vmo nicht mehr möglich ist, erst recht nicht, wenn das Höhenruder voll gegen die Trimmung gezogen wird, hatten die Piloten ab 1:45 nach dem Abheben keine Chance mehr, den Flieger auszutrimmen.
Elektrisch trimmen ist fraglich, weil über die Schalter nicht der gesamte Bereich abgefahren werden konnte (Sicherheitsfeature) und sie seit 737 max nicht mehr den Trimmotor ohne Automatiken nutzen konnten.
Sie hätten natürlich in wenigen tausend Fuß über Grund per Parabelflug die Höhenflosse entlasten können, im lastfreien Augenblick per Handrad nose up kurbeln, Flieger versuchen abzufangen, wieder drücken zum entlasten, wieder Kurbeln... diese yoyo-Technik stand vor Jahrzehnten noch in 737-Handbüchern, wurde aber zwischenzeitlich entfernt.
Fazit: footballspielende Boeing-Testpiloten mit perfekter Systemkenntnis würden jetzt wahrscheinlich eine ganz gute Chance haben, diese MCAS-Fehlfunktion und Trimsystem zu überleben. Soweit zu "es kommen immer mehrere Faktoren zusammen"
Es wird ohne Frage noch weiter "gepuzzelt" werden müssen, bis die komplette Kette an Ereignissen rekonstruiert worden ist. Ich hoffe vor allem darauf, dass im Ergebnis vor allem die Interaktion zwischen Mensch und Maschine verbessert wird.
Im Bericht wundert mich, dass die Piloten wohl nicht viel kommuniziert haben und auch sonst ein für mich etwas seltsames Verhalten gezeigt haben:
Obwohl kurz nach dem Abheben der Stick Shaker auf der linken Seite auslöst (und bis zum Crash arbeitet) und wohl auch eine Master Caution ausgelöst wurde, gab es keine Übergabe der Controls an den Copilot und kein Gespräch darüber, wieder umzukehren und zu landen. Der Copilot akzeptiert fröhlich eine weitere Freigabe zum Steigen und einen Shortcut.
Eigentlich sollte jetzt jedem im Cockpit klar sein, dass irgendetwas nicht stimmt.
Trotz des aktiven Stick Shaker wird der Autopilot zugeschaltet und die Klappen werden eingefahren. - Wollte der Pilot den Flug mit Stick Shaker fortsetzen? - Jedenfalls verabschiedet sich kurz danach der Autopilot und die eingefahrenen Klappen aktivieren das MCAS und - weil immer noch der Pilot von links fliegt - wird der defekte linke AoA-Sensor vom MCAS verwendet.
Das MCAS trimmt das Flugzeug Nose Down. - Was macht ein Flugzeug, wenn es die Nase senkt und die Leistung nicht verringert wird? - Es wird sehr viel schneller. Die Leistung der Triebwerke wurde zu keinem Zeitpunkt durch die Piloten verringert!
Dass man ein Flugzeug nur noch schwer (per Hand) Trimmen kann, wenn die IAS bereits bei weit über 400kt ist, dürfte wohl kein Wunder sein. Ebenso ist es bei dieser Speed kein Wunder, dass sich der vertrimmte Stabilizer nicht mehr durch das Höhenruder korrigieren lässt.
In den Medien wird berrichtet, die Piloten hätten "alles richtig gemacht". - Naja.
"Natürlich könnten sie einfach im Programm feststellen, dass Eingangswerte nicht zusammen passen - aber es kann sich kein Programmierer sondern nur ein Aerodynamiker überlegen, was das System eigentlich machen soll, wenn es solche Inkonsistenten Werte gibt."
Die Antwort ist: "Nix"! In der neuen "Flight International" z.B. ist ein Test der PC 24 veröffentlicht. Da heißt es zu genau dem Thema: "The PC-24 has two angle-of-attack vanes / sensors and crosscheck their values before declaring a stall condition." Das scheint also - zumindest für die Ingenieure bei Pilatus - doch machbar.
natürlich ist das machbar, wenn man nicht gerade irgendwelche Clickworker aus Schwellenländern als Programmierer beschäftigt oder den Sub vom Sub vom Sub....
Vermutlich kann das Tomas nicht beantworten. Was aber m.E. sehr wahrscheinlich ist: Vom Verantwortungsgefühl wurde wie bei Outsourcing nach Indien & Co. gearbeitet: Die FAA hat "nur single sensor" durchgewunken (auf Basis mutmaßlich falscher Annahmen über die Wirkungsintensität). Beauftragt wird vom Verantwortlichen: "Schreib Software für Single Sensor!" Programmierer sagt sich: "Warum soll ich diskutieren, ob ich aus den vorliegenden Daten auch mehr machen könnte?".
Ob Outsourcing oder auch im Konzern fehlendes Gesamtverantwortungsdenken: Krank ist das im Sinne einer Firmenkultur so oder so. Im Konzern, für den ich arbeite, habe ich zumindest teilweise den Eindruck, es gäbe eine offene Kultur, die diesem Denken des "Ich tue nur meinen unmittelbaren Job" eine aufmunternde Kultur des "Denk' als Gesamtfirma" entgegenstellt.
Bin übrigens seit gestern aus meinem PUT auf Boeing raus und wieder finanziell gesehen neutral.
Hatte ich in der Tat auch. PUTs in den letzten 3 Jahre waren nur Tesla und Boeing. Bei Tesla war es zu sehr Nervenritt, ich war im PUT als Elon Musk den Fake vom Aufkauf durch die Saudis verbreitete und die Aktie Richtung 400 schoss. Bei Boeing gehe ich zwar davon aus, dass sie zurecht gegrillt werden, aber die USA lieber Milliardenstrafen gegen Bayer verhängen und durchsetzen, als unter dem Strich Boeing für den wirklich unnötigen Tod von Menschen zur Verantwortung zu ziehen: Ich glaube nicht, dass Boeing wirklich gerecht für den Tod der Menschen bezahlen werden muss, die durch unsägliche Unverantwortung in Kauf genommen wurden. Insofern sagt mir mein Realismus: Die werden mit einem halben Jahresgewinn als Strafe davon kommen. Das ist nicht gerecht, aber m.E. realistisch.
Du bist ja nicht der einzige, der puts kauft, und Konzerne wie Boeing und die Investoren von Tesla wissen wie man damit umgeht. So einfach ist das nicht.
Ich verstehe Dein Posting nicht so ganz: Ich habe die PUTs nicht als Demonstration gegen Boeing gekauft, sondern ganz schnöde, um damit Geld zu verdienen. Weil ich am 4.4. der Meinung war, dass das Ausmaß der unverantwortlichen Implementierung von MCAS noch nicht im Kurs eingepreist wäre und viele Große noch davon ausgingen, dass die Art der Implementierung von MCAS schon halbwegs professionell für Luftfahrtmaßstäbe wäre. Jetzt denke ich, dass es eingepreist ist, und die Schocker mit den tatsächlichen Verurteilungen doch eher so mild ausfallen werden wie die Tropfen, die z.Zt. als Mairegen in NRW runtergehen.
