Wie unterschiedlich sind redundante Flugsteuerungscomputer?

Was Airbus betrifft:

1. Jede Einheit besteht aus zwei unterschiedlichen Platinen, von denen eine den Ausgang steuert und die andere ihn prüft. Unähnlich bedeutet sowohl unterschiedliche CPUs und Chipsätze (A320 verwendet i386 (Intel) und m68k (Motorola); neuere Modelle verwenden andere Kombinationen, im Grunde alles, was zum Zeitpunkt ihrer Entwicklung weit verbreitet war) und Software, die von zwei unabhängigen Teams geschrieben wurde.

2. Es gibt Failover, je nach System zwei oder drei (IIRC, die Einheit, die die Side-Sticks liest, ist die einzige mit vier Kopien).

3. Die beiden Hauptachsen Nicken und Rollen werden von zwei unterschiedlichen Systemen gesteuert. ELAC steuert Höhen- und Querruder, SEC steuert Höhenleitwerk und Spoiler. Dies sind zwei völlig unabhängige Ketten mit unterschiedlichen tatsächlichen Steuerflächen mit Ausnahme der Seitenknüppel.

4. Der A320 verfügt über ein (hydro-)mechanisches Backup für Pitch über das Trimmrad und Gieren über die Pedale, wobei die Gier-Roll-Kopplung für das Rollen verwendet wird. Das funktioniert auch bei komplettem Stromausfall. IIRC die Backups bei neueren Modellen jedoch nicht (weil ein vollständiger Stromausfall noch nie vorgekommen ist).

Redundanz wird nicht nur durch die Vervielfachung der Rechner erreicht, sondern auch durch deren Diversifizierung. Auf Airbus-Flugzeugen werden zwei verschiedene Computer verwendet (einer mit Intel-Chips, der andere mit Motorola-Chips im Fall des A320) und Software wird zweimal geschrieben, einer zur Steuerung, der andere zur Überwachung, von zwei Teams, die nicht interagieren dürfen .

Um aus Kapitel 12 des Avionik-Handbuchs zu zitieren :

Trotz der einmaligen Kosten, die durch Unähnlichkeit verursacht werden, ist es von grundlegender Bedeutung, dass die fünf Computer alle unterschiedlicher Art sind, um Gleichtaktfehler zu vermeiden. Diese Ausfälle können zum Totalausfall des elektrischen Flugsteuerungssystems führen. Folglich können zwei Arten von Computern unterschieden werden:

2 ELAC (Höhen- und Querrudercomputer) und 3 SEC (Spoiler- und Höhenrudercomputer) auf A320/A321 und,

3 FCPC (primäre Flugsteuerungscomputer) und 2 FCSC (sekundäre Flugsteuerungscomputer) auf A330/A340.

Am Beispiel des 320 werden die ELACs von Thomson-CSF um 68010-Mikroprozessoren hergestellt, und die SECs werden in Zusammenarbeit von SFENA/Aerospatiale mit einer Hardware hergestellt, die auf dem 80186-Mikroprozessor basiert. Wir haben daher zwei verschiedene Design- und Fertigungsteams mit unterschiedlichen Mikroprozessoren (und zugehörigen Schaltungen), unterschiedlichen Computerarchitekturen und unterschiedlichen funktionalen Spezifikationen. Auf der Softwareebene führt die Architektur des Systems zur Verwendung von vier Softwarepaketen (ELAC-Steuerkanal, ELAC-Überwachungskanal, SEC-Steuerkanal und SEC-Überwachungskanal), wenn funktional eines ausreichen würde.

Im Allgemeinen wird Software nicht falsch hergestellt. Wenn die Software erstellt (programmiert) wird, können Fehler wie von Ihnen beschrieben entweder durch fehlerhafte Implementierungen oder durch schlechte Spezifikationen eingeführt werden. Fehlerhafte Implementierungen werden durch Testen der Software erkannt. Das Testen nimmt viele Formen an; Unit-Tests sind eine der einfacheren Formen, bei denen einzelne Funktionen des zugrunde liegenden Programmiercodes getestet werden, um zu sehen, ob sie korrekt implementiert sind. Dies kann nach oben skaliert werden, wenn System- und Integrationstests durchgeführt werden, bei denen größere Teile der Software miteinander gekoppelt werden, um zu sehen, wie sie als Ganzes funktioniert. Aber das einfache Testen des Codes auf dieser Ebene erfasst nicht alles. Beim Schreiben eines Programms geht es selten darum, es dazu zu bringen, das zu tun, was Sie wollen, es geht hauptsächlich darum, mit all den seltsamen Grenzfällen und Fehlerszenarien umzugehen. Und hier versagt die meiste Software.

Um sich vor solchen Fällen zu schützen, können Sie Audits, Simulationen, statische Codeanalysen und viele andere Formen von Inspektionen und Tests durchführen.

Anders verhält es sich mit fehlerhaften Spezifikationen, bei denen Sie sich auf die Dokumentation verlassen müssen. In einer perfekten Welt muss jede Anforderung auf einer Ebene dokumentiert werden, in der beschrieben wird, warum die Anforderung existiert, und alle Eingaben und Ausgaben, die sich gegebenenfalls daraus ergeben sollten. Spezifikationen werden von mehreren Personen entwickelt, um zu verhindern, dass eine Person etwas vergisst oder falsch interpretiert, aber auch das erfasst nicht alles.

Um eine weitere Schutzebene gegen Softwarefehler hinzuzufügen, fügen Sie mehrere Instanzen des Systems hinzu, und Sie lassen auch ein Team seine eigene Version des Systems erstellen, vorzugsweise auf anderer Hardware. Sie können dann die Verantwortung bestimmter Subsysteme aufteilen und auf die verschiedenen Computer verteilen, auf denen das System ausgeführt wird, wodurch eine weitere Redundanzebene hinzugefügt und die Rechenlast auf jedem Computer sowie das Risiko verringert wird, dass Teile des Systems auf unvorhergesehene Weise interagieren .

The Fast Company hatte eine hervorragende Beschreibung des Prozesses des Schreibens von Software für das Space Shuttle. Obwohl es weder mit Airbus noch mit Boeing in direktem Zusammenhang steht, gibt es einen Einblick, wie der Prozess funktionierte und was daraus resultierte.

Primäre Systeme sollten identische Computer und Software haben, und dies ist bei vielen Computern von Luftfahrzeugsystemen der Fall. Die unabhängigen Backup-Systeme sollten jedoch je nach Architektur und Redundanzverwaltungsanforderungen und Sicherheitsschemata unterschiedliche Systeme und Software aufweisen. Abgesehen von Flugsteuerungen, die Unterschiede in der Hardware aufweisen, sind primäre Fluganzeigen für Piloten- und Kopilotenseiten für Fluggeschwindigkeit und Trägheitsnavigation häufig dreifach redundant, um die Lagefunktion beizubehalten. Diese verwenden korrekterweise identische 3-Navigationssystem-Computer, während das "Backup" zum Zweck der flugsicherheitskritischen Funktionen und des Determinismus unterschiedlich ist. Die Gesamtsystemarchitektur von parallel oder mehr (Triplex) muss unabhängige und redundante Systeme aufweisen, die die behördlichen und behördlichen Kriterien für Sicherheit und Lufttüchtigkeit sowie Zuverlässigkeit und Verfügbarkeit erfüllen. Im Allgemeinen erfordert das Vorhandensein identischer Computer für "Primärsysteme" ein eingehendes Testen der Fehlereinfügung der Kombination komplexer Interaktionen, um die Möglichkeit von Softwarefehlern und manchmal unbegründeten Befürchtungen zu minimieren, dass sich Fehler irgendwie in Latenz manifestieren. Korrektes Testen in allen Umgebungen ist der Schlüssel zum Erfolg Beseitigung von Mängeln, die potenzielle Gefahren und Risiken verursachen würden. Software-Sicherheitsmethoden werden empfohlen, um solche Probleme zu verhindern, zu beseitigen und zu kontrollieren, um sicherzustellen, dass die Sicherheits- und Lufttüchtigkeitsanforderungen erfüllt werden. Sicherheitsanalysen und unabhängige Überprüfungen sind in diesen Fällen mit Genehmigungen erforderlich.