Manch persönliche Email, die mich erreicht, zieht einem die Socken aus. Generell bin ich gerne bereit, Studenten bei ihrem Studium mit meinem Wissen zu helfen und habe das auch schon mehrfach, ohne es an die große Glocke zu hängen, getan.

Was ich allerdings nicht mache, ist die Recherche-Arbeit für eine Hausarbeit anderer zu erledigen. Das ist der eine Grund, warum ich die Anfrage nach einer Literaturliste zur Mensch-Maschine-Schnittstelle bei Boeing und Airbus nicht erfüllen werde.

Der andere Grund ist, dass es eben keine öffentliche Primärliteratur zu den genauen Punkten gibt, die der Fragesteller wissen wollte. Eine generelle Antwort auf die „allgemeine (Computer-)Schnittstelle bei Boeing für einen Co-Piloten“ etwa ist so sinnlos, wie die Frage, ob Essen für Jugendliche gesund ist.

Boeing ist ein Hersteller, der seit vielen Jahrzehnten Entwicklungen hervorbrachte und die Flugzeuge daraus sind so unterschiedlich im Cockpit ausgestattet, wie es die ganze Bandbreite der aktuellen Technik erlaubt. Zur Rück- und Quermeldung von Steuerinputs bei Boeing Flugzeugen kann man keine allgemeine Aussage treffen, da es von nur Stall Warning (also quasi keine Envelope Protection) bis zur vollen Envelope Protection* wie bei Airbus Flugzeugen alles gibt. Die volle Envelope Protection kann aber überdrückt werden von der Crew. Nur Aussagen über die Flight Controls gelten für alle Boeing Flugzeuge. 

Wer also Einzelheiten zu einem Interface (der Schnittstelle) eines Piloten zu seiner Technik im Cockpit wissen möchte, kommt nicht umhin, sich die Herstellerhandbücher für das entsprechende Flugzeugmuster anzusehen, Fluglinien für ihre Anwendung und Abweichungen dazu zu befragen und Piloten, die dieses Flugzeugmuster fliegen, zu interviewen. Und darüber hinaus das Hintergrundwissen mitzubringen, das gefundene oder erfragte Wissen auch beurteilen zu können.

Auf einige der in der Mail aufgeworfenen Fragestellungen werden wir hier explizit eingehen (mit den Voraussetzungen aus dem vorhergehenden Absatz) und die Antworten einer größeren Öffentlichkeit zur Verfügung stellen. Alle Zitate (in grün) stammen aus besagter Mail. Der Erklärkasten ist (c) flugundzeit.

 

 

…ich bin vor kurzem auf den deutschen Wikipedia-Artikel zur „Flight Envelope Protection“ sowie auf das unterschiedliche Feedback eines Flugzeugs an den Pilot not Flying je nach Flugzeugmuster (z. B. Unterschiede bei Airbus und Boeing) aufmerksam geworden.

Ich vermute aufgrund meiner „Laien-Interpretation“ diesbezüglich die folgenden beiden Annahmen:

1.) Flugzeuge von Boeing geben am Steuerhorn dem Pilot Not Flying ein leichter interpretierbares Feedback zu den Aktionen des Pilot Flying als dies am Sidestick eines Airbus der Fall ist,…

Ja, bei Boeing Flugzeugen bewegen sich die Flight Contols von PF (Pilot Flying) und PM (Pilot Monitoring) synchron, da sie mechanisch verbunden sind. Der PM sieht also alle Inputs des PF. Beide Piloten sehen auch alle Inputs des Auto Flight Systems, wenn dieses das Flugzeug fliegt.
Die Sidesticks im Airbus sind nicht miteinander verbunden. Der PM sieht also die Inputs des PF nicht. Beide Piloten sehen auch folglich die Inputs des Auto Flight Systems nicht, wenn dieses das Flugzeug fliegt.

…aber ein manueller eventuell „unsinniger“ Override einzelner Parameter der Flight Envelope Protection kann unbewusst herbeigeführt werden.

Nein, die Envelope Protection zeigt die Grenzen des Envelopes auf, sodass ein unbewusstes Verlassen des Envelopes erschwert und damit (weitgehend) verhindert wird. Durch höheren Kraftaufwand kann der Envelope aber bewusst verlassen werden.

Allerdings haben nicht alle Boeing Flugzeuge eine vollumfängliche Envelope Protection. Diese ist nur in den neueren Flugzeugtypen vorhanden. 

2.) Flugzeuge von Airbus geben am Sidestick dem Pilot Not Flying kein bzw. ein nur schlecht interpretierbares (bzw. weder sichtbares noch haptisches) Feedback zu den Aktionen des Pilot Flying aber ein manueller eventuell „unsinniger“ Override einzelner Parameter der Flight Envelope Protection erfordert vor dieser Aktion ein explizites manuelles Deaktivieren einzelner Kontrollsysteme.

Die Sidesticks geben kein Feedback.

Durch bewusstes Ausschalten mehrerer Flight Control Computer (mindestens 2 von 7) oder durch bewusstes Ausschalten mehrere Teile der Sensorik des Flugzeugs kann die Protection eingeschränkt oder komplett unmöglich gemacht werden.

Aus den Annahmen würde also im Extremfall folgen:

a) Der PF einer Boeing kann versehentlich beliebig riskante und beliebig unsinnige Steuerbefehle geben (also eher schwach ausgeprägte Flight Envelope Protection), …

Ja, er kann bewusst den Envelope verlassen; versehentlich in neueren Modellen eher nicht. Versehentlich nur in den Modellen wie alte B737, die keine Protection haben. 

…aber der PNF kann die Wechselwirkung zwischen dem Verhalten des PF und dem Verhalten des Flugzeugs leicht nachvollziehen (also Erleichterung von gutem Crew Resource Management).

Ja. Der PM sieht die Steuereingaben des Pilot Flying

b) Ein Airbus setzt Steuerbefehle vor der Ausführung in solche Befehle um, die laut „Vermutung [sic!] der Computer“ möglichst ungefährlich und möglichst wenig unsinnig sein sollten, (also eher stark ausgeprägte Flight Envelope Protection). Aber der PNF kann die Wechselwirkung zwischen dem Verhalten des PF und dem Verhalten des Flugzeugs nicht leicht nachvollziehen (also Erschwerung von gutem Crew Resource Management).

Ja, alle Inputs werden bewertet und dann erst in Steuerbefehle umgesetzt, die das Flugzeug im Envelope halten. Hier liegt allerdings die Gefahr darin, dass die Computer durch falsche Daten der Sensorik den Envelope falsch bestimmen und somit unter Umständen der Envelope verlassen wird und sich die Piloten nicht mal dagegen wehren können, da die richtigen Inputs der Piloten, die das Flugzeug im Envelope halten würden von den Computern fälschlicherweise als gefährlich betrachtet und somit unterdrückt werden.

Mich interessiert dies vorwiegend vor dem Hintergrund von versehentlich „unlogisch“ programmierten Computern bzw. versehentlichen „unlogischen“ Eingaben in Computer sowie „Human Computer Interaction“ bzw. Informatik allgemein zum Beispiel bezogen auf Flugzeuge, aber auch in allen anderen Bereichen der praktischen Informatik.

Die Beurteilung von „unlogisch“ muss aus Piloten- und nicht aus Programmiersicht erfolgen. Es gibt Situationen, die in der Luft eintreten können, die sich der Fußgänger-Mensch am Schreibtisch zuvor nicht ausdenken kann.

Das ist genau das, was mir und anderen Piloten Bauchweh verursacht: Informatiker müssen mit Piloten (und Herstellern) gleichberechtigt zusammenarbeiten, wenn etwas Sicheres für die Menschen an Bord herauskommen soll. Ein Informatiker, der sich Wissen über Computersysteme anliest, ist nicht ausreichend um ein Cockpit(computer)system zu entwickeln oder zu programmieren. Erst recht nicht, wenn es um KI-Anwendungen geht, deren möglicherweise nicht nachvollziehbaren Outputs der Mensch-Pilot da oben dann nicht mehr nachvollziehen kann.

Und ja, es gibt auch Informatiker, die selber fliegen. Die in der Luftfahrt zu hause sind, auch wenn sie beruflich nicht ihr Geld damit verdienen. Sie sollten bevorzugt bei der Entwicklung neuer Systeme eingesetzt werden. Vielleicht kosten sie mehr, als jemand der noch nie selber einen Steuerknüppel bedient hat, aber im Sinne der Langzeitkosten von Crashs, gerade bei zunehmender Automatisierung gesamter Vorgänge und nicht nur der Unterstützung von Flugzuständen, ist das eine Voraussetzung.

Das mag hart klingen, der Crash eines Verkehrsflugzeuges aber ist härter.