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.

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).

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.)

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.

AF447 war beim Passieren von FL250 nicht mehr zu retten, selbst bei korrekter Reaktion.

Wäre im Reiseflug das Normal Law wieder aktiv gewesen hätten aber alle (leider falschen) Steuerinputs den Flieger nicht in den Stall bringen können. Darum geht es mir, man braucht keinen separaten Sicherheitsmechanismus solange Normal Law funktioniert. Und wenn es zu Alternate Law wechselt hat das einen Grund, dann würde auch ein Sicherheitsmechanismus nicht mehr alle Daten zur Verfügung haben.

Oder man verbaut doppelte Fly-by-wirr Systeme und erhöht die Ticketpreise um 10%. Ach nein, das geht ja nicht.