Was heißt schon sicher? MultiCore-Systeme für die Luftfahrt

Auf einem Chip integrierte Systeme mit mehreren Prozessorkernen etablieren sich zunehmend in Smartphones und leistungsstarken Netzwerkgeräten. Auch in traditionell konservativen Branchen wie etwa der Luftfahrt verzeichnet man großes Interesse an Multicore-Prozessoren. Systementwickler müssen sich nun sicherheitsrelevanten Herausforderungen stellen, für die im Konsumerbereich oder bei herkömmlichen Computersystemen keine Notwendigkeit besteht.

Prozessorarchitekturen, die heute in Avioniksystemen eingesetzt werden, sind, bezogen auf ihre Fähigkeiten, eher als konservativ zu bezeichnen. Sie nutzen bekannte Standard-Chips mit nur einem Prozessorkern (Singlecores). Für Systeme der kommenden Generation jedoch zwingen ehrgeizige Vorgaben bezüglich Platzbedarf, Gewicht und Leistungsaufnahme (Size, Weight and Power - SWaP) sowie die Kosten für Wartung und Pflege die Luftfahrtbranche dazu, den Einsatz von Multicore-Architekturen in Erwägung zu ziehen. Die Luftfahrtbranche, aber auch das Militär, hatte in der Vergangenheit großen Einfluss auf die Entwicklung von Chiparchitekturen und -technologien. Dieser Einfluss schwindet jedoch, da preiswerte, kommerziell verfügbare Siliziumbausteine mit geringem Energieverbrauch und großem Funktionsumfang die Innovationszyklen vorantreiben. Als Folge befassen sich die Hersteller von Avioniksystemen zunehmend mit dem Einsatz von COTS-Technik (Commercial Off-the-Shelf), um den Funktionsumfang erhöhen und die Entwicklungskosten senken zu können.

Diese neuen Entwicklungen bringen allerdings einige Herausforderungen mit sich. Marktanalysten von VDC gehen bei Multicore-Architekturen von einem starken Wachstum aus und rechnen bis 2013 mit durchschnittlich 21,4% Zuwachs pro Jahr. Darin enthalten sind Betriebssysteme, Tools und Services. Rund 7,1% der aktuellen Designs nutzen Multicore-Architekturen. Analysten erwarten, dass diese Zahl bis 2013 auf 11,4% steigt. Auf der anderen Seite ergab der VDC-Report, dass 75% der befragten Anwender weniger als zwei Jahre Erfahrung mit Multicore-Technologie haben. Außerdem stellen Zertifizierungsanforderungen eine Herausforderung für die Nutzung von Multicore-Technik im Umfeld sicherheitskritischer Systeme dar. Dies gilt speziell im Bereich Luftfahrt, wo strenge Zertifizierungen wie RTCA DO-178C und EUROCAE ED-12C erforderlich sind.

Steigende Systemkomplexität

Während »Safety« ganz klar zu den wichtigsten Zielen in der Luftfahrt zählt, zeichnet sich auch ein Trend hin zu einem höheren Funktionsumfang ab. Für beide Ziele müssen in der Luftfahrt aktive OEMs in der Lage sein, viele Applikationen in gemeinsame Computerplattformen zu integrieren. Dabei müssen die Applikationen getrennt voneinander bleiben, um die Zahl möglicher Fehler zu reduzieren und den Entwicklungsprozess zu vereinfachen. Das traditionelle Konzept bei großen Verkehrsflugzeugen bestand darin, sehr viele einzelne Computer oder LRUs (Line Replaceable Units) einzusetzen, um das Flugzeug mit separaten Funktionen wie Steuerung des Fahrwerks, Wetterradar, Treibstoff-Management etc. auszustatten. Dieses Konzept für Avioniksysteme bedeutet, dass jede LRU eigene Entwicklungs- und Implementierungskosten mit sich bringt und zugleich die SWaP-Anforderungen insgesamt erhöht. Hinzu kommen Kosten für Ersatzteile, Wartung und Training für diese Vielzahl diskreter Systeme sowie die hochkomplexe Aufgabe des Abkündigungs- oder Obsoleszenz-Managements.

Die Möglichkeit, alle diese Applikationen auf nur einem Chip zu administrieren - oder zumindest auf einer wesentlich kleineren Zahl von Systemen als bisher - ist daher äußerst attraktiv, solange äquivalente Safety oder Security nachgewiesen werden können. Zweifellos führen weniger Ersatzteile und geringere Wartungsprobleme auch zu einer höheren Zuverlässigkeit sowie zu niedrigeren Betriebskosten.

Durch Virtualisierung in Flugzeugen wie etwa der Boeing 787 über eine Umgebung mit der Bezeichnung IMA (Integrated Modular Avionics) konnte die Luftfahrtbranche diese Konsolidierung bereits nutzen. Dabei kommt der Standard ARINC 653 zum Einsatz, der die Ausführung mehrerer Anwendungen auf nur einem Core ermöglicht. ARINC 653 ist die international anerkannte Spezifikation für Speicher- und Zeitpartitionierung in sicherheitsrelevanten Echtzeitbetriebssystemen (RTOS). Dieser Standard kann auch mehrere Safety-Stufen in einem System unterstützen. Dadurch können auf einem IMA-System Level-A-Applikationen (höchste Stringenz laut Definition der DO-178C »Software Considerations in Airborne Systems and Equipment Certification«) zusammen mit Level-B-Anwendungen auf einem einzigen Prozessorkern laufen. Dabei kommen Software und Prozessorhardware zur Trennung der Applikationen zum Einsatz.

Bild 1 zeigt eine typische Single-core-Architektur, auf der ein ARINC-653-System läuft. Jede Applikation wie zum Beispiel der Flight-Controller oder das Radar läuft auf einer anderen Safety-Stufe. Das Betriebssystem nutzt den Prozessor, um diese Konfigurationsbereiche einzurichten und sorgt für die Partitionierung. Um mehrere Safety-Stufen auf einem Prozessor unterstützen zu können, muss der Systemintegrator einen Sicherheitsnachweis erbringen und die Systemrobustheit durch Messungen der Prozessorleistung und der Reaktionsfähigkeit des Kernels, der alle Systemressourcen verwaltet und die I/Os steuert, nachweisen.

Multicore-Designauswahl

Multicore-Prozessoren erhöhen die Komplexität und können den Nachweis der funktionalen Sicherheit auf Avionik-Plattformen stark beeinträchtigen.

Eine erste Entscheidung besteht darin, entweder ein SMP-Betriebssystem (Symmetric Multi-Processing) zu wählen, bei dem eine Instanz des OS auf mehrere Cores läuft, oder aber mit Supervised-AMP (Asymmetric Multi-Processing) die einzelnen Instanzen zu isolieren, wobei jedem Rechenkern ein OS zugeordnet wird (Bild 2). Theoretisch lässt sich die Separation leichter erreichen, wenn auf jedem Core eine einzelne OS-Instanz läuft. Demgegenüber könnte das Aufteilen eines OS über viele Cores ermöglichen, dass jede Applikation auf jedem Rechenkern läuft, wie es zum Beispiel »Windows« auf einem PC anstrebt. Es ist potenziell einfacher, eine Applikation auf ein SMP-System zu migrieren, da die Applikation das Vorhandensein mehrerer Cores ignorieren kann, während sich das OS um die Verteilung der Rechenressourcen kümmert. Doch dies ist ein schwerwiegender Nachteil im Hinblick auf Safety, weil der ARINC-653-Standard den Nachweis des Determinismus für Level-A-Applikationen verlangt. Das Betriebssystem könnte veranlassen, dass eine bestimmte Applikation einmal auf einem Prozessor-Core läuft und ein anderes Mal auf einem anderen Rechenkern. Falls die Applikation auf einem anderen Core läuft, muss eventuell der Cache geleert werden, was die Systemperformance verändert. Des Weiteren ist es nicht einfach, den Sicherheitsnachweis etwa für die Worst-Case-Ausführungszeiten zu erbringen.

Ein AMP-basiertes Design andererseits nutzt einen Hypervisor, um geteilte Hardware-Ressourcen zu partitionieren, und unterstützt mehrere Applikationen mit verschiedenen Safety-Levels. Ferner lässt sich veranlassen, dass eine bestimmte Applikation immer auf einem bestimmten Core läuft, um den Grad an Determinismus zu erhöhen.

Bild 3 zeigt ein EFB (Electronic Flight Bag) in einer Multicore-Konfigura-tion, bei der die Komplexität mit zu-sätzlichen Prozessor-Cores beträchtlich steigt. Unterschiedliche Typen von Applikationen laufen hier 
mit verschiedenen Safety-Levels und ermöglichen den Betrieb eines »Linux«- oder »Android«-Systems auf einem oder mehreren dieser Rechenkerne, während auf einigen anderen zum Beispiel »VxWorks« für 
sicherheitskritische Level-A-Umgebungen läuft. Das System ist partitioniert und die passende Zahl von Prozessor-Cores zugeordnet, um das richtige Maß an Performance für jede der Applikationen zu liefern.

Geteilte Ressourcen

In beiden Fällen jedoch - SMP und Supervised-AMP - bleibt das Problem geteilter Ressourcen zwischen den Cores und Applikationen bestehen. Dies ist die bei weitem größte Herausforderung bei Multicore-Prozessoren hinsichtlich Safety. Gibt es einen gemeinsamen First-Level- oder Second-Level-Cache? Falls ja, wie wird mit dem Verlust des Determinismus im Zusammenspiel der Caches umgegangen, wenn eine Level-A-Applikation läuft? Ist es wichtig, einen »Single Point of Failure« beim Zugriff auf den Speicher zu haben? Hat der Prozessor eine Switched-Fabric-Backplane oder eine Standardbus-Backplane? Wenn es ein Standardbus ist, wie wird mit Prioritäten in den verschiedenen Prozessor-Modi umgegangen? Was passiert, wenn eine I/O-Exception im Prozessor eintrifft, und welcher Core ist dafür zuständig? Werden Timer-Interrupts zwischen den Cores synchronisiert oder gibt es einen separaten Eingang für jeden Rechenkern? Auch die Frage, ob auf dem Level-A-Core die Flugsteuerungen oder das Unterhaltungssystem läuft, ist von Bedeutung.

Es gibt keine Standardvorgehensweise oder Richtlinie für den Einsatz eines Multicore-Prozessors in einem Avioniksystem. Außerdem sind alle Multicore-Systeme verschieden; Halbleiterhersteller haben sie nicht einheitlich entwickelt, und jede Architektur muss unabhängig untersucht werden, um den Sicherheitsnachweis erbringen zu können. Entwickler müssen einfach Dinge ausprobieren, beurteilen, wie gut diese funktionieren, und dann eventuell auftretende Probleme lösen.

Virtualisierung kann den Entwicklungsprozess wesentlich vereinfachen. Ein virtualisiertes System nutzt einen Hypervisor-Software-Layer, auf dem ein Mix von Betriebssystemen läuft und der eine schnelle Kommunikation zwischen den Cores ermöglicht. Der Hypervisor trennt die Betriebssysteme voneinander und ermöglicht Entwicklern, die Steuerung der I/Os auszulagern und dennoch ARINC-653-Partitionierung zu nutzen. Ferner legt der Hypervisor zum Beispiel fest, welcher Core welchen Speicher nutzt oder für die Netzwerkschnitt--stelle zuständig ist. Virtualisierung ermöglicht das Management von mehreren Geräten aus der Softwareperspektive. Aus Sicht der Hardware kann es jedoch erforderlich sein, beispielsweise die Separation bei der Nutzung von gemeinsamen Caches nachzuweisen.

Ein Virtuali-sierungs-Layer wie der »Hypervisor« von Wind River trägt dazu bei, die SWaP-Anforderungen von Avioniksystemen zu reduzieren (Bild 4).

Der Hypervisor abstrahiert die darunterliegende Hardware und ermöglicht die Konfiguration partitionierter Softwarebereiche, die sich auf einfache Weise zwischen Cores verschieben lassen. Wenn Applikation und Gast-Betriebssysteme richtig spezifiziert sind, steht der Nutzung von Software-Virtualisierung für sicherheitskritische Systeme auf Multicore-Plattformen nichts im Wege.

Über den Autor:

Alex Wilson ist Director of Business Development für Aerospace and Defence Wind River.