Viele der Vorteile der Multicore-Virtualisierung in eingebetteten Systemen sind gut dokumentiert. Die Möglichkeit, mehrere Legacy-Single-Board-Computer (SBCs) mit verschiedenen Betriebssystemen und Anwendungen auf einem einzigen, virtualisierten Multicore-SBC zu konsolidieren, wird allgemein als der greifbarste Vorzug der Plattformen kommender Generationen angesehen. Aber die Fähigkeit von CPU-Virtualisierung und Hypervisoren, in Bezug auf Echtzeit-Performance, Softwarekom-positionsfähigkeit und architektonische Robustheit zu überzeugen, ist der Embedded Software Community weniger bekannt. Im Folgenden werden die drei wichtigsten im Zusammenhang mit der FACE-Referenzarchitektur entstehenden Vorteile erörtert.
Dediziertes Partitionierungssegment
In den letzten zehn Jahren wurden erhebliche Fortschritte bei der Fähigkeit erzielt, durch CPU-Virtualisierung mehrere Betriebssysteme auf einem einzigen Prozessor auszuführen. Die zugrunde liegende Hardware hat Eigenschaften, die für Embedded-Ingenieure, denen es auf Robustheit und Vorhersagbarkeit ankommt, ebenso interessant sind, auch wenn sie sich als Erstes in der IT-Welt durchgesetzt haben.
Im traditionellen Plattform-Softwaredesign beherbergt jeder Prozessor einen einzelnen Betriebssystem-Kernel, der für die Verwaltung von Speicherzuweisung, Ausführungs-planung, Interrupt-Routing, Ausnahmebehandlung, Peripheriesteuerung und Bus-Multiplexing verantwortlich ist. Inzwischen jedoch ist virtualisierungsfähige Multicore-Hardware in der Lage, viele Kernel zu beherbergen, wobei jedem Kernel Teilmengen von Ressourcen unterschiedlicher Art und Größe zugewiesen werden. So können mehrere unabhängige Softwarelaufzeiten auf einem Gerät implementiert werden, ohne dass durch einen gemeinsamen Kernel die Gefahr eines Gleichtaktausfalls besteht. Solche Fähigkeiten verbessern grundlegende Architektureigenschaften in Bezug auf Sicherheitsbelange.
Aus der Sicherheitsperspektive trägt die Verwendung integrierter CPU-Virtualisierungsfunktionen zur Isolierung von Hardwaresicherheitsfunktionen und zur Trennung von Anwendungslaufzeitdiensten von Hardwaresteuerungsschnittstellen wesentlich zur Gewährleistung der Systemstabilität bei. Solche Designtechniken eliminieren häufig ausgenutzte Bedrohungsvektoren vollständig, die zur Umgehung von Sicherheitsrichtlinien, zur Privilegienerweiterung und zum Verlust der CPU-Kontrolle führen können.
Das Einhalten von Schwellenwert-Designprinzipien wie Vorhersagbarkeit, Integrität und Hochverfügbarkeit usw. wird erheblich unterstützt durch Virtualisierungs-/Parti-tionierungsfunktionen wie zum Beispiel
➔ DMA-Kanalisolierung
➔ Gemeinsame Cache-Partitionierung der letzten Ebene
➔ Speicherbus-Bandbreitenzuweisung
➔ Unabhängige Interrupt-, Ereignis- und Ausnahmebehandlung
Die Möglichkeit, Softwarepartitionen mit größerer Genauigkeit auf Hardwareebene zu befestigen und zu steuern, passt perfekt zu den Idealen von FACE.
Bild 2 führt den Begriff des »Hardware-Partitionierungssegments«, der von einem Hypervisor erfüllt wird, in die FACE-Referenzarchitektur ein. Die Darstellung zeigt einen Hypervisor, der zwei Sätze von Software auf zwei verschiedenen CPU-Kernen isoliert. Jeder Satz ist dabei mit FACE-konformen Komponenten konfiguriert. Darüber hinaus erhält jeder Softwaresatz größere Partitionierungseigenschaften als ein einzelnes OS-gehostetes Design, bei dem die Gerätetreiber und der interne Dienst getrennt sind.
Vereinfachung des Raums für Echtzeit
Die Aufnahme eines weiteren Segments in FACE wäre ein erhebliches Unterfangen. Die Einführung einer weiteren Technologieklasse und Softwareschicht unterhalb eines Betriebssystems hingegen mag für echtzeit- und sicherheitsaffine Entwickler, die Komplexität scheuen, kontraproduktiv erscheinen. Doch die Hardware-Partitionierungs- und Multiplexing-Möglichkeiten der CPU-Virtualisierung erlauben es, Teilmengen von Laufzeitfunktionen für kritische Aufgaben auf einem Prozessor zu kapseln und abzubilden, auf dem gleichzeitig Anwendungen mit inhärent umfangreicheren Laufzeit- und Serviceabhängigkeiten laufen.
Angenommen, eine Anwendung zur Überwachung des Zustands der Fahrzeug-steuerung, wie zum Beispiel eine Hochfrequenz-Mehrheitsabstimmung CBIT (Continuous Built-in Test), die für die TMR-Fehlererkennung (Triple Modular Redundancy) benötigt wird, muss neben einer Flugplanungsanwendung auf einem Multicore-Prozessor laufen. Anstatt beide Anwendungen gleichzeitig auf demselben Betriebssystem zu implementieren, das denselben Netzwerk-Stack und Kernel nutzt, kann mit Hilfe einer Hypervisor-basierten Lösung die Health-Monitor-Anwendung folgendermaßen funktionieren (Bild 3):
➔ Auf einen separaten CPU-Kern abgebildet
➔ Auf eine separate Ethernet-MAC abgebildet
➔ Ausführung nach einem unabhängigen Thread-Scheduling-Algorithmus
➔ Isoliert von orthogonalen Interrupts und blockierenden Semaphoren
➔ Isoliert von DMA- und OS-Kernel-Speicherzugriffsfehlern
➔ Ausführung auf einer optimierten, minimalistischen POSIX-konformen Laufzeitumgebung
Das Ergebnis ist ein ideales Szenario für einen Echtzeitprogrammierer, der die Analyse der Worst-Case-Ausführungszeit (WCET) vereinfachen möchte. Auf der LRU-Ebene (Line Replaceable Unit) behält die Plattform jedoch die Fähigkeit, Anwendungen mit umfangreicheren TSS- (Transport Services Segment) und OSS- (Operating System Segment) Fähigkeitsanforderungen zu hosten, die weniger von Timing- und Integritätsrisiken betroffen sind.
Portabilität und Wiederverwendung
Ein Sitzenbleiben auf den nicht wiederkehrenden Kosten für das Board Support Package (BSP) könnte vermieden werden, wäre die interne Plattformsoftware portabler. Low-Level-Code-Module (insbesondere Treiber) sind notorisch problematisch, wenn Eigenschaften der Wiederverwendung und Interoperabilität vorhanden sein sollen.
Die Standardisierung von OS-internen Kernel-Schnittstellen ist aufgrund ihres einzigartigen Designs und (in vielen Fällen) auch aufgrund ihrer proprietären Natur nicht praktikabel. Einige Klassen von Gerätetreibern, die unabhängig von Core-Diensten sind und nur geringe Unterstützung für Betriebssystemfunktionen benötigen (zum Beispiel das Dateisystem), können jedoch von einem Hypervisor isoliert und über Standard-IPC-Schnittstellen (Inter-Process Communication) in Anwendungen integriert werden.
Es ist nachweisbar, dass Geräte unabhängig von Betriebssystemen gesteuert und mit anderen Komponenten integriert werden können, ohne proprietäre Betriebssystem-abhängigkeiten einzubetten – beispielsweise eine OpenGL-UA-Anwendung, die lediglich Treiber mit Zugriff auf die GPU-Geräteschnittstelle benötigt. Oder ein eigenständiger MIL-STD-1553-Service mit TSS-kompatiblen E/A-Schnittstellen, der für PCS-Anwendungen (Portable Component Segment) zur Verfügung steht (Bild 4).
Anstatt sich auf Betriebssystemimplementierungen bei Ressourcenzuordnung und IPC-Transporten zu verlassen, können die TSS-Schicht und die lokale Anwendungs-Laufzeitsoftware über ausreichende Fähigkeiten verfügen, um abhängige Module zu lokalisieren und unter Verwendung von standardmäßig vom Hypervisor bereitgestellten Schnittstellen und Diensten zu integrieren. Ein solcher Ansatz kann sogar den Verpackungsanforderungen der FACE Unit of Conformance folgen. Diese Vision ist nicht weit hergeholt, wenn man bedenkt, dass Virtualisierungsstandards wie OASIS VIRTIO bereits existieren und etabliert sind. So wie FACE sich auf POSIX stützt, um Standardspezifikationen für die OSS aufrechtzuerhalten, kann VIRTIO in ähnlicher Weise das vorgeschlagene Hardware-Partitionierungssegment unterstützen.
Das Thema Disruption wurde bereits eingangs erwähnt. Ein weiterer aufkommender Aspekt, ist die Schaffung von städtischen Mobilitätsplattformen, die menschliche Passagiere oder Fracht durch die Luft befördern. Der wahrscheinliche Gewinner der Hardwarearchitektur in dieser Anwendung werden die Automobilplattformen sein (einhergehend mit einer Reduktion der bestehenden Avionik-Plattformen). Aus der Systemperspektive wird es notwendig sein, einen Weg hin zu relevanten System-zertifizierungsstandards einschließlich DO-178 zu schaffen. Die Einführung von FACE, für das Unternehmen diverse zertifizierte und zertifizierbare Software-Stacks entwickelt haben, kann eine schnellere Einführung bis zum Einsatz dieser neuen Klasse von autonomen Fahrzeugen ermöglichen.
Die Portabilitäts- und Interoperabilitätsvorteile von FACE beschränken sich bislang im Allgemeinen auf die Missionssystemsoftware, die von Betriebssystemen oberhalb der TSS-Schicht gehostet wird. Durch die Ausrichtung der militärischen Avionik auf die Entwicklung unbemannter Systeme verschwinden die zugrundeliegenden Grenzen zwischen Missionssystem- und Fahrzeugsteuerungs-Rechendomänen immer mehr und die Einschränkungen von FACE werden zu einem Ärgernis.
Um die Anforderungen der Automobilindustrie zu erfüllen, müssen die Stärken von FACE erkannt und gleichzeitig die Umgebung an die Anforderungen der Fahrzeug- steuerungssoftware angepasst werden. Jüngste Erfahrungen mit Fahrzeugsteuerungs-Subsystemen haben gezeigt, dass Virtualisierung ein Mittel ist, um die Komplexität der Plattformsoftware zu reduzieren, indem der Zugriff auf die Low-Level-Hardware-steuerung ausgegliedert wird, während gleichzeitig die architektonischen Vorteile der Partitionierung und der Interoperabilitätsschnittstellen bereitgestellt werden.
Der Autor
Will Keegan
leitet in seiner Rolle als Chief Technical Officer die technologische Ausrichtung aller Lynx-Produktlinien. Er war maßgeblich an der Entwicklung wichtiger Sicherheitstechnologien innerhalb von Lynx beteiligt, um die Reichweite der bestehenden Produkte zu erweitern, wobei der Schwerpunkt auf Cybersicherheit, Kryptographie und Virtualisierung lag. Keegan hat einen Bachelor of Science in Computerwissenschaften von der University of Texas.