Reverse Engineer's View der Boeing 787 "51 Day"-Richtlinie

Vor einigen Wochen gaben internationale Regulierungsbehörden bekannt, dass sie den Boeing 787-Betreibern befehlen würden, die Stromversorgung des Flugzeugs nach 51 Tagen ununterbrochenen Betriebs vollständig abzuschalten.1 Die FAA gab eine Sicherheitsempfehlung zur Lufttüchtigkeit heraus, in der diese Angelegenheit näher erläutert wurde, und ich war gespannt welche Art von Details in diesem Dokument enthalten waren.

Obwohl ich schließlich entdeckte, dass die FAA-Richtlinie nicht viele Informationen enthielt, reichte es gerade aus, um mich auf den richtigen Weg zu bringen, um die Ursache des Problems zu finden. Dieser Blogbeitrag nutzt die interessanten Informationen der FAA-Richtlinie, um Kenntnisse über einige Avionikkonzepte zu erlangen.

Zunächst müssen wir die Teile der 787-Architektur und -Systeme vorstellen, die für dieses Problem relevant sind. Die FAA-Richtlinie verwendet explizit Akronyme wie CDN oder CCS, die definiert werden sollten, bevor man mit der Ursachenanalyse fortfährt.

Was ist der gemeinsame Kern (CCS)?

Im Gegensatz zu föderierten Avionikarchitekturen, die verteilte Avionikfunktionen verwenden, die als eigenständige Einheiten gruppiert sind, verwenden Integrated Modular Avionics (IMA)2-Architekturen eine partitionierte Umgebung mit hoher Integrität, die mehrere Avionikfunktionen unterschiedlicher Kritikalität auf einer einzigen Plattform hostet. - gemeinsam genutztes Computerformular. Boeing-Ingenieure gingen noch einen Schritt weiter und entwickelten das Common Core System (CCS) für die 787, eine weitere Verbesserung auf Basis der offenen IMA-Avioniktechnologie.

Das CCS ist im Wesentlichen eine Hardware-/Softwareplattform, die Rechen-, Kommunikations- und Input-Output (I/O)-Dienste für die Implementierung von Echtzeit-Embedded-Systemen bereitstellt, die als gehostete Funktionen bekannt sind.

Mehrere gehostete Funktionen teilen sich Plattformressourcen innerhalb einer virtuellen Systemumgebung, die durch Partitionierungsmechanismen erweitert wurde, die als Teil des Plattformdesigns implementiert wurden, basierend auf VxWorks 6533, 4OS.5

Diese Partitionierungsumgebung für virtuelle Systeme stellt sicher, dass gehostete Funktionen voneinander isoliert sind, sodass sie hochkritische Anwendungen, aber auch niedrigere Anwendungsintegritätsniveaus unterstützt. Denken Sie daran, dass internationale Vorschriften fünf Stufen von Ausfallbedingungen definieren, die nach ihren Auswirkungen auf das Flugzeug, die Besatzung und die Passagiere kategorisiert sind:

Stufe A – Katastrophal

Eine Panne kann zu mehreren Todesopfern führen, in der Regel mit dem Verlust des Flugzeugs.

Stufe B – Gefährlich

Ein Ausfall hat erhebliche negative Auswirkungen auf die Sicherheit oder Leistung, verringert die Fähigkeit der Besatzung, das Flugzeug aufgrund von körperlicher Belastung oder erhöhter Arbeitsbelastung zu bedienen, oder verursacht schwere oder tödliche Verletzungen bei Passagieren.

Stufe C-Dur

Ein Ausfall reduziert den Sicherheitsspielraum drastisch oder erhöht die Arbeitsbelastung der Besatzung drastisch. Kann Passagieren Unbehagen (oder sogar leichte Verletzungen) verursachen.

Stufe D–Moll

Ein Ausfall verringert die Sicherheitsmarge leicht oder erhöht die Arbeitsbelastung der Besatzung leicht. Beispiele können Unannehmlichkeiten für Passagiere oder eine routinemäßige Flugplanänderung sein.

Stufe E–Kein Effekt

Ein Ausfall hat keine Auswirkungen auf die Sicherheit, den Flugbetrieb oder die Arbeitsbelastung der Besatzung.

Software, die auf Stufe A, B oder C genehmigt wurde, erfordert eine starke Zertifizierung, die formelle Verifizierungs- und Rückverfolgbarkeitsprozesse umfasst

Daher kann eine Level-A-DO-178B6-Software in derselben gemeinsam genutzten physischen Ressource mit einer Level-E-Anwendung koexistieren.

Abbildung 1. VxWorks 6537,A-Architektur

Im Idealfall können sich Anwendungen nicht gegenseitig stören, unabhängig von Fehlern, die in gehosteten Funktionen oder Plattformressourcen auftreten können, die vorab festgelegt und den Plattformkomponenten durch ladbare Konfigurationsdateien mitgeteilt werden, normalerweise im XML- oder proprietären Binärformat.

Im CCS finden wir die folgenden Hauptkomponenten:

Allgemeine Verarbeitungsmodule (GPMs) zur Unterstützung funktionaler Verarbeitungsanforderungen Remote Data Hubs (RDCs) zur Unterstützung analoger Systemsignale, analoger diskreter Signale und serieller digitaler Schnittstellen (CAN-Bus8, A4299 usw.) Avionik Vollduplex (A664-P7) Geschaltetes Ethernet10-Netzwerk für die Kommunikation zwischen Plattformelementen

Diese Artikel können als Line Replaceable Units (LRUs)11 oder als Module oder Karten verpackt werden, die dann in Schränke oder integrierte LRUs verpackt werden können. Somit besteht das CCS aus:

Zwei (2) Kompo...