@menschmeier,

besten Dank - jetzt weiss ich endlich wofür man den AoA bei der Geschwindigkeitsermittelung benötigt. Da habe ich wohl an der falschen Stelle gesucht - nur beim AoA und nicht bei den Geschwindigkeiten.
Ich habe nicht behauptet, das man den AoA-Anzeige unbedingt braucht. Ohne weitere Erläuterungen ist die Anzeige wertlos. Deshalb zeigt Airbus ihn auch nicht an. Man kann allerdings mit dem AoA einen Sackflug erkennen...
Wie dem auch sei, Boeing meint mit zwei AoA-Sensoren wäre alles Stand der Technik und im Fehlerfall - unterschiedliche AoA-Daten - können die Piloten alles retten.

die Piloten brauchen den AoA überhaupt nicht zum Fliegen. In keinem Airbus und auch in kaum einer Boeing wird er überhaupt angezeigt. Somit gibt es da nix zu diskutieren.

Direkt angezeigt wird der AoA nicht, aber zumindest im A380 kann man sich einen sogenannten Flight path Vector ins PFD aufschalten, der zeigt den Flight Path Angle und den Drift Angle an, und dann kann man sich den AoA sehr leicht ausrechnen. Übrigens ein sehr nützliches Feature.

die Piloten brauchen den AoA überhaupt nicht zum Fliegen. In keinem Airbus und auch in kaum einer Boeing wird er überhaupt angezeigt. Somit gibt es da nix zu diskutieren.

Direkt angezeigt wird der AoA nicht, aber zumindest im A380 kann man sich einen sogenannten Flight path Vector ins PFD aufschalten, der zeigt den Flight Path Angle und den Drift Angle an, und dann kann man sich den AoA sehr leicht ausrechnen. Übrigens ein sehr nützliches Feature.

Vollkommen richtig, das kann selbst die A320 schon, aber dieses nützliche Feature ist auch wieder nicht überlebensnotwendig. Und ich wage mal zu behaupten, dass ca 95% aller Piloten, die TRK/FPA benutzen den AoA nicht ausrechnen. Auch wenn sie es könnten.

Einen Sackflug können sie auch auch ohne AoA erkennen, nämlich dann wenn Pitch und V/S nicht in einem logischen Verhältnis stehen, Übertrieben dargestellt. 30° Pitch Up und V/S -5000Ft/min sind nicht gerade logisch.
Piloten haben erfahrungsgemäßt ein gutes Gespür dafür, welche Anzeigen sie erwarten bei welchem Gewicht in welcher Höhe usw.

Dieser Beitrag wurde am 29.06.2019 15:54 Uhr bearbeitet.

Natürlich - abere nicht immer - erkennt ein Pilot einen Sackflug. Wenn nicht, dann war es der letzte Flug. Weshalb haben das die AF447-Piloten nicht erkannt?

Das werden wir nicht herausfinden. Die Anzeigen im Cockpit haben funktioniert. Es fehlte "nur" die Geschwindigkeitsanzeige. Künstlicher Horizont und Vertical Speed waren nicht betroffen, zumindest nach den Aufzeichnungen des FDR nicht.

Die Diskussion auf pprune spricht von einem verbauten Prozessor aus dem Pentium 286, daher wohl die Lags mit allen Folgen. Ist das möglich?

Das ist sogar höchstwahrscheinlich. Nur dürfen sie nicht die von Ihnen gekannte Leistung eine 286er Prozessors als Maßstab nehmen. Windows verbraucht einen Großteil der Rechenleistung der Prozessoren.

Ein 286er Prozessor mr einer guten Software ist mehr als ausreichend um solche Berechnungen zu machen.

Die A320 Familie setzt z.B.: auf 386er Prozessoren (ab der Enhanced) Die A330 auf 486er Architekturen usw.
Die A380 hat z.B.: Prozessoren aus der Generation vergleichbar dem Pentium 2 und diese werden in der Spitze nur zu etwa 20% ausgelastet.

Oder vielleicht noch eindrucksvoller, die Apollo Missionen wurden mit Fluglagecomputern gemacht die in etwa ein 50stel der Rechenleistung hatten, die heute in einem herkömmlichen wissenschaftlichen Taschenrechner zu finden ist.

Ich möchte hier @menschmeier beipflichten und bestätigen.
Eine A320 ist mit 286iger Prozessoren, teilweise sogar nur 86iger, musterzugelassen worden. Was übrigens weit vorm Pentium war (286, 386, 486 und dann Pentium I). Da kann/darf man jetzt gar nicht so mir nix dir nix neuere Technologie einpflanzen (Thema Musterzulassung).
Dann sind von den Prozessoren tatsächlich keine immensen Grafikberechnungen anzustellen, sondern 'nur' einfache Mathematik. Da reicht so ein 286iger völlig aus. Der Flieger ist ja auch kein Flugsimulator und es gibt auch nicht DEN einen Computer (analog einem PC), der alles alleine macht. In so einem Flieger stecken ziemlich viele Rechner, jeder mit seiner speziellen Aufgabe, und oft doppelt oder dreifach vorhanden der Redundanz wegen.
Bei der 737 ist das in abgespeckter Form ähnlich. Auch da werden 'nur' rein mathematische Berechnungen angestellt. In sofern sollte es auch hier mit 286iger Technologie funktionieren. Was nun das genaue Problem ist, was zu den Lags führt ist aus der Ferne nicht zu beurteilen und somit sollte man sich mit Anschuldigungen nicht zu weit aus dem Fenster lehnen.
Fakt ist, auch die A320 fliegt mit 286iger Technologie sicher und ich behaupte bei ihr wird noch viel mehr gerechnet als bei der 737.

Die Diskussion auf pprune spricht von einem verbauten Prozessor aus dem Pentium 286, daher wohl die Lags mit allen Folgen. Ist das möglich?

Sorry ein Pentium 286 kann es nicht geben, denn ein Pentium ist de facto ein 586 Prozessor.

Das ist sogar höchstwahrscheinlich. Nur dürfen sie nicht die von Ihnen gekannte Leistung eine 286er Prozessors als Maßstab nehmen. Windows verbraucht einen Großteil der Rechenleistung der Prozessoren.


Ich habe mir 1987 meinen ersten PC mit einem 286 Prozessor und 12" Farbbildschirm gekauft. Windows kam erst 1990 oder 1991. Das Betriebssystem war schlicht DOS und Sie haben nicht einfach kopiert, sondern mußten copy x.y (für die zu kopierende Datei) eingeben. Also damals war der 286 das Modernste was es gab. Dennoch benötigte der Prozessor mit WordPerfect ca. 20 bis 30 Minuten um einen Text von ca. 400 Seiten nach speziellen Wörtern oder Rechtschreibfehlern zu durchsuchen.


Ein 286er Prozessor mit einer guten Software ist mehr als ausreichend um solche Berechnungen zu machen.

Was ist eine gute Software? Was ist ausreichend für die Berechnungen? Normalerweise vielleicht, aber was ist, wenn die Datenmenge explodiert, da der Pilot versucht gegen die gelieferten Daten von einem Sensor anzukämpfen?

Soweit ich weiß, benötigt ein Flugzeug heutzutage im Reiseflug auch nur ca. 30% seiner Triebwerksleistung. Aber es gibt immer wieder Situationen, da reichen dann 100% nicht aus. Gibt sogar einen protoypischen Unfall dazu. Den ersten Absturz einer B 747 überhaupt, das war Lufthansa 540 in Nairobi. Und da wurde beim Start noch nicht einmal die 100% Triebwerksleistung abgefordert, da die Maschine relativ leicht gewesen war.


Die A320 Familie setzt z.B.: auf 386er Prozessoren (ab der Enhanced) Die A330 auf 486er Architekturen usw.
Die A380 hat z.B.: Prozessoren aus der Generation vergleichbar dem Pentium 2 und diese werden in der Spitze nur zu etwa 20% ausgelastet.

Oder vielleicht noch eindrucksvoller, die Apollo Missionen wurden mit Fluglagecomputern gemacht die in etwa ein 50stel der Rechenleistung hatten, die heute in einem herkömmlichen wissenschaftlichen Taschenrechner zu finden ist.

Also Apollo können Sie nicht vergleichen. Die hatten nämlich überhaupt keinen Rechner (Computer) an Board. Die waren damals noch viel zu groß dafür. Das Problem wurde so gelöst,daß man die Daten aus der Kapsel zur Erde sandte. Dort wurden sie in riesigen Computern berechnet und die Ergebnisse wieder zurück an die Apollo geschickt.

@NeilArmstrong
Sorry ein Pentium 286 kann es nicht geben, denn ein Pentium ist de facto ein 586 Prozessor.


"Vielen" Dank für die Bestätigung meines Kommentars.


Ein 286er Prozessor mit einer guten Software ist mehr als ausreichend um solche Berechnungen zu machen.

Was ist eine gute Software? Was ist ausreichend für die Berechnungen? Normalerweise vielleicht, aber was ist, wenn die Datenmenge explodiert, da der Pilot versucht gegen die gelieferten Daten von einem Sensor anzukämpfen?

Was bedeutet Datenexplosion, da der Pilot ankämpft?
Es sollte zu einem festgelegten Zeitpunkt X die gleiche Menge Daten anfallen, nämlich die konkrete Position des Sensors ausgedrückt in einem binären Datencode, z.B. 16 Bit lang. Die 16 Bit sind es aber immer, egal wo der Sensor steht oder wie sehr der Pilot Eingaben macht. Der ist nicht plötzlich 32 bit lang oder 5x 16 Bit oder sonstwie. Die Information der Sensorposition zur Zeit X ist 16 Bit.
Ich hoffe das war halbwegs verständlich erklärt worauf ich hinaus will.

Die Frage nach dem Grund warum man nur einen Sensor benutzt hat, die stell ich mir seit es bekannt geworden ist.
War eine der ersten Dinge die man an der Uni gelernt hat - Redundanz und Sicherheit.

Ich finde keine logische Erklärung, nur die daten eines sensors zu nehmen.
Vorsätzlich hat das keiner gemacht, und jeder halbwegs moderne CPU ist in der Lage in sekundenbruchteilen einen Datenvergleich durchzuführen.

Es kann nur an einem vollkommen aus dem Ruder gelaufenen Entwicklungsprozess gelegen haben.
Anders kann ich mir das nicht erklären

Was mache ich mit zwei unterschiedlichen AoA-Sensordatensätzen? MCAS muss reagieren! Wenn ich keinen dritten Datensatz bekomme (Ich will an sich aber nur einen fehlerfreien Datensatz haben). reicht auch einer, der vom linke AoA-Sensor. Was sagt der Auftraggeber? Mach mal, wir werden schon sehen...

Das was man immer macht wenn sowas passiert: Fehlermeldung,
AoA Disagree, Warning MCAS deactivated controll pitch

Dafür gibt es ja 2 Piloten vorne im Cockpit.

@jasonbourne,

das setzt voraus, dass Boeing die Piloten über MCAS informiert und entsprechend auch schult.
Genau das wollte/will Boeing vermeiden. Deshalb konnte auch auf die Fehlermeldung - das Lämpchen - verzichtet werden.

Wie wird sich Boeing nun entscheiden?
Wie sinnig wäre eine Kontrolle über pitch und IAS? An sich müsste der Flieger dann sofort landen.

@A320Fam,

meinen Sie, dass es durch einen Fehler zuviele bestimmte Prozessaufrufe mit hoher Prioriät geben kann, die andere Prozessaufrufe praktisch ausschalten, weil diese eine niedrigere Priorität haben?
In der kommerziellen DV muss man darauf achten, dass bei Dialogen die Antwortzeit immer unter 2,5 Selkunden liegt. Das kann bei grossen Datenbanken kritisch werden. Man muss u. U. das Design ändern.
Bei Prozessverarbeitung muss man viel genauer auch die Codierung betrachten. Dafür gibt/gab es spezielle Programmiersprachen.

Lags in einem Echtzeitsystem sind idR auf Programmierfehler zurückzuführen.

 https://www.focus.de/finanzen/boerse/fuer-9-dollar-die-stunde-737-desaster-boeing-setzte-auf-billig-programmierer-bei-ungluecksflieger_id_10878918.html

@A320Fam,

meinen Sie, dass es durch einen Fehler zuviele bestimmte Prozessaufrufe mit hoher Prioriät geben kann, die andere Prozessaufrufe praktisch ausschalten, weil diese eine niedrigere Priorität haben?
In der kommerziellen DV muss man darauf achten, dass bei Dialogen die Antwortzeit immer unter 2,5 Selkunden liegt. Das kann bei grossen Datenbanken kritisch werden. Man muss u. U. das Design ändern.
Bei Prozessverarbeitung muss man viel genauer auch die Codierung betrachten. Dafür gibt/gab es spezielle Programmiersprachen.

Ich meine, das es keine großen Datenmengen sind bzw. die Datenmenge sich nicht ändert nur weil der Pilot eine Aktion startet. Es geht um den AoA Sensor und seine Datenmenge. Und die ist immer gleich gross, weil es nur ein Wert ist, nämlich die aktuelle Position des Sensors. Das ist ein Datenwort konstanter Grösse, da ändert sich doch nix, "Sensor steht bei do und soviel Grad". Der Flightcomputer rechnet somit mit einem Wert, z.B. 16bit gross. Der ist aber immer so gross, nur sein Inhalt variiert. Ob der Wert richtig bzw realistisch ist würde ja gerade beim MCAS in der Flightcomputersoftware nicht gewertet. Ob eine Auswertung/Vergleich/Wichtung zweier Datenwörter zu einer Überlastung/Lag der S/W führt mag ich nicht einzuschätzen. Aber es gibt keine Erhöhung der Datenmenge vom AOA nur weil was Defekt am Sensor ist, der sendet halt nen falschen Wert, aber in der gleichen Datengröße.

Oft steckt das Problem im Fehlerhandling. Es gibt keine oder falsche oder unzureichende Befehle/Parameter, die das System durchlaufen soll, wenn es ein Fehler auftritt. Da die Möglichkeit unendlich ist, wann, wo und was für ein Fehler auftritt.

Mal ein Beispiel, was ich aber hier für nicht relevant halte:
- in 2 Speicher schreiben 2 AoA Sensoren ihre Werte
- eine Prozessor liesst die beiden Werte und bildet daraus einen binären Wert und legt den wieder in einen Speicher
- nun liesst eine Subroutine den Wert, durchläuft eine Schlaufe, prüft, ob der Wert mit etwas bekannten in einer Datei passt, wenn nicht, wird der Wert um 1 erhöht und die Schleife erneut durchlaufen
- kommt was sinnvolles raus, hällt die Routine an, der Wert wird im Display angezeigt und die Schleife im Speicher glelöscht.
- das geht so lange gut wie Werte aus dem Speicher kommen, die am Ende zu was führen
- nun meldet ein AoA Sensor richtigen binären Müll, die Schleife findet nie ein Ergebnis und läuft unendlich weiter und blockiert Prozessorzeit und Speicher.

Ich denke nicht, dass genau das hier auftritt aber so ähnlich. Da es unendliche Varianten von Fehlern gibt, kann man auch nie alle händeln und abfangen. Die schlimmsten muss man in vielen Tests am Ende der Software Entwicklung beheben.

@dlehmann66,
es darf nicht zu unüberschaubar vielen Fehlern/Fehlermeldungen führen!
Fehlermeldung bzw. Ok-Meldungen bilden zusammen mit den Eingabedaten den Rahmen für ein Programm. Ein Programm muss testbar sein. Die Testdaten sind ein Teil der Spezifikation!
MCAS hat einen AoA von über 70° als bearbeitbar akzeptiert. Dann müsste ein sehr rustikales Kommado "Nase nach" unten kommen, falls man den Flieger retten will.