Die übergeordneten Vorteile offener Systemstandards klingen alle logisch und überzeugend. Man vermeidet die Bindung an einen bestimmten Anbieter, senkt die Lizenz- und Entwicklungskosten und sorgt für einen ausgeglichenen Wettbewerb auf dem Markt.
Die Anbieter sind verpflichtet, ihre Produkte an die Standards anzupassen und mit der Community in Kontakt zu bleiben, wenn sich Anforderungen und Technologien weiterentwickeln. Die auferlegten Kosten für die Teilnahme mögen hoch sein. Klar ist aber, dass ein gravierender Mangel an Standardisierung die Lieferkette deutlich mehr kostet.
Modulare Systeme: Der Teufel steckt im Detail
Nahezu alle angestrebten Vorteile offener Systeminitiativen im Verteidigungsbereich – einschließlich des MOSA Transformation Office der US-Armee, des OMS der US-Luftwaffe und der Pyramide des britischen Verteidigungsministeriums (MoD) – hängen von der Fähigkeit der Ingenieure ab, Systemkomponenten über verschiedene Softwareplattformen oder Produktlinien hinweg effektiv wiederzuverwenden.
Bei der Hardware wurden Fortschritte auf der Ebene der austauschbaren Einheiten (Line Replaceable Unit, LRU) erzielt. Doch bei der Software fehlt es an technischen Spezifikationen, um die Absicht hinter modularen offenen Systemen zu erfüllen. Dies wird durch Initiativen wie das im Dezember 2022 angekündigte Global Combat Air Programme (GCAP) noch wichtiger.
GCAP vereint das von Großbritannien und Italien geleitete Projekt für ein zukünftiges Kampfflugzeug (FCAS), zu dessen Ergebnissen unter anderem der „Tempest“-Düsenjet gehört, mit dem japanischen F-X-Programm. Die Systeme, die durch Fähigkeiten wie unbemannte Flugzeuge, fortschrittliche Sensoren und moderne Waffen erweitert werden, sind äußerst komplex.
Kein einziges Unternehmen und in der Tat nicht eine Nation kann all diese Funktionen liefern. So entstehen Teaming-Vereinbarungen, infolge derer Unternehmen passende Systemmodule entwickeln, um sie in Flugwerke zu integrieren. Der Druck auf die Markteinführungszeit ist groß, da die Länder darauf bedacht sind, Funktionen zu liefern, mit denen sie ihren Vorsprung vor den Konkurrenten halten können. Da diese teuren Plattformen jahrzehntelang in Betrieb sein werden, besteht außerdem der Wunsch, die Bindung an einen bestimmten Anbieter zu vermeiden und bewährte Technologie in anderen Plattformen wiederzuverwenden.
In jüngster Zeit gab es Ankündigungen mehrerer europäischer Länder, den amerikanischen F-35 Joint Strike Fighter einsetzen zu wollen. Einigen europäischen Regierungen bereitet die Abhängigkeit von einem anderen Land beziehungsweise Kontinent bei wichtigen Verteidigungsgütern jedoch Sorge.
Dies deutet darauf hin, dass auf modulare Systeme eine gute Idee sind. Und das sind sie. In den USA gibt es eine von der US-Armee vorangetriebene Initiative namens Modular Open System Approach (Mosa). Die Herausforderung besteht im Level, auf dem diese Modularität in dieser und in anderen Normen definiert wird, und in den Auswirkungen auf die aufgabenkritischen Elemente dieser Systeme. Diese sind diejenigen, die einfach immer auf deterministische Weise funktionieren müssen. So lassen Sie uns einige der Schwachstellen in unseren modularen Standards erörtern, die verhindern, dass Kunden diese überzeugenden Vorteile erreichen.
Im Idealfall möchten wir Systemintegratoren in die Lage versetzen, eine Softwarekomponente so einfach in ein System einzufügen wie eine VPX-Karte in ein Gehäuse. Die Realität sieht aber so aus, dass die Portierung von Software auf andere Betriebssystemplattformen eher mit einer Herztransplantation als mit dem Austausch einer Telefonkarte vergleichbar ist.
Standards wie Face (Future Airborne Capability Environment) und Pyramid beschreiben Schnittstellen von Bibliotheken, an die sich Anwendungen anbinden können, um Dienste des Betriebssystems zu nutzen. Diese Schnittstellen enthalten jedoch nur Beschreibungen für Software, die im Benutzeranwendungsbereich ausgeführt werden kann. In den Normen fehlen Beschreibungen des erwarteten Verhaltens und der Nebenwirkungen, die eine Echtzeit- und Gefahrenanalyse ermöglichen.
Sie berücksichtigen nicht die Systeminformationen, die erforderlich sind, um ein umfassendes System aufzubauen, zu integrieren und zu konfigurieren, damit es sich korrekt verhält. Sie decken auch keine Softwarekomponenten ab, die sich im Betriebssystem selbst befinden, wie zum Beispiel Treiber und Zustandsüberwachungen.
Beim Aufbau eines LRU ist es üblich, dass ein Softwareplattform-Entwicklungsteam aus mehreren Unternehmen besteht, die jeweils eine Teilsystemkomponente beisteuern. Dazu zählen 1553-Treiber, GPU-Treiber, Ethernet-Treiber mit Netzwerk-Stack-Integration, Boot-Sicherheitsmodule, kontinuierlich eingebaute Testmodule und so weiter Der Großteil der Software wird für nicht standardisierte APIs auf Kernel-Ebene geschrieben und mit proprietären Konfigurationstools verpackt. Der Systemintegrator wird das komplette System integrieren und qualifizieren. Diese Arbeit kann unglaublich ineffizient sein, wenn die Beteiligten kein gemeinsames Verständnis für eine Komponente und deren Qualifizierung haben, bevor sie sie an den Integrator weitergeben.
Die Lösung: Standardisierung
Der Schlüssel zur Lösung dieser Situation liegt in der Standardisierung der Fähigkeit, komplette Softwarestapel aus austauschbaren Komponenten zusammenzustellen und zu validieren, während gleichzeitig die Mechanismen der Zusammenstellung und Validierung von Systemen verbessert werden. Wenn die Regierung die Entwicklung eines Treibers finanziert, sollte ein Hauptintegrator in der Lage sein, den Treiber mit wenigen oder gar keinen Änderungen in einem anderen Betriebssystem wiederzuverwenden.
Für Lynx liegt die Lösung in der Einführung zweier Technologien zur Verbesserung der Mechanik und Durchführbarkeit der Echtzeit-Kompositionsfähigkeit, nämlich: Hypervisoren zur Partitionierung von Ressourcen und zur Zuweisung von Komponenten als einzelne virtuelle Maschinen, und Unikernels, die als Laufzeitumgebung für jede einzelne Komponente anstelle herkömmlicher Gastbetriebssysteme verwendet werden können, um die Ressourcennutzung und die Timing-Eigenschaften zu verbessern.
Hypervisoren
Der Hauptunterschied zwischen dem Hypervisor- und dem Betriebssystem-Ansatz besteht darin, dass der Hypervisor den Komponenten die Möglichkeit gibt, ihre eigenen lokalen Ressourcen zu verwalten. Eine auf einem Hypervisor gehostete Komponente ist ein vollständiges Softwaremodul, das eigenständig ausgeführt werden kann und portabel ist. Herkömmliche Betriebssysteme, bei denen die Softwarekomponenten nicht vollständig sind und ohne Verknüpfung mit den Bibliotheken des Betriebssystems ausgeführt werden können, erzwingen eine Abhängigkeit, die die Wiederverwendbarkeit sehr einschränkt. Hypervisoren erhöhen auch die Unabhängigkeit zwischen den Komponenten und ermöglichen robustere Architekturen für die Schichtung von Referenzmonitoren für Sicherheit und Schutz. Die Angriffsfläche eines Hypervisors ist überdies wesentlich kleiner als die eines Betriebssystems.
Dass Hypervisoren eine zusätzliche Komplexitätsschicht in den Software-Stack einfügen, führt zu einem zusätzlichen Ressourcen- und Rechenaufwand sowie zu Sicherheitsbedenken. Mit einer anderen Bereitstellungsstrategie jedoch können sie effektiv dazu beitragen, Systeme einfacher und berechenbarer zu machen. Hier kommen die Unikernels ins Spiel.
Unikernel
Unikernel ermöglichen es Programmen, alle Betriebssystemdienste in einem einzigen Adressraum einzubinden, wodurch die Notwendigkeit entfällt, in einen speziellen Kernelmodus zu wechseln, um einen Systemdienst aufzurufen. Betriebssystem-gehostete Anwendungen errichten Barrieren, die Anwendungen zwingen, ihren Kontext zu verlassen und in einen gemeinsamen Kernelraum einzutreten, um die Anforderungen der aufrufenden Prozesse zu erfüllen.
In der Unikernel-Architektur verweisen die Anwendungen lediglich auf die benötigten Betriebssystemfunktionen. Der Compiler lässt ungenutzte Funktionen natürlich weg. Da Unikernel nicht mehr kontextabhängig sind und nicht mehr von konkurrierenden Prozessen blockiert werden, ist das Ausführungsverhalten von Unikerneln einfacher zu beobachten und zu charakterisieren.
Dies reduziert den Aufwand für die Multicore-Timing-Analyse und macht den Prozess der Sicherheitszertifizierung überschaubarer. Die Unabhängigkeit und die zeitlichen Eigenschaften eines Unikernels machen ihn schlichtweg zu einer besseren Integrationseinheit für die Zusammenstellung von Systemen, bei denen die Integrität und Vorhersagbarkeit eines Systems einfacher zu überprüfen ist. Wenn man das Konzept weiterdenkt, wäre ein Unikernel nicht nur eine Aufgabe oder eine Anwendung, sondern er würde auch Subsysteme umfassen. Die Kombination von Unikerneln mit Hypervisoren ermöglicht es, Systeme mit einem höheren Grad an Genauigkeit zu komponieren, und gibt Architekten die Möglichkeit, explizit Pipelines von Software-Stacks aus einzelnen Unikernel-Komponenten zu erstellen, wobei die Komponenten die Rolle von Kernel-Diensten wie Netzwerk-Stacks und Gerätetreibern übernehmen können.
Da wir die Modellierung von Systemen als eine Integration von Software-Pipelines vorschlagen, ist es absolut entscheidend, die Mosa-Vision aufrechtzuerhalten. Indem sichergestellt wird, dass die Komponenten über Standardschnittstellen verbunden sind, die auch in anderen Pipelines mehr als zehn Jahre lang interagieren können.
Hypervisoren sind gut geeignet, dieses Problem zu lösen, da sie über etablierte Standards verfügen, um Schnittstellen zwischen virtuellen Maschinen über die Oasis-VirtIO-Spezifikation und Schnittstellen zwischen virtuellen Maschinen und physischen Maschinen unter Verwendung von Standardspezifikationen wie PCI Express handzuhaben.
Fazit
Hypervisoren und Unikernel sind der Schlüssel zur Entwicklung von Komponenten auf Plattformebene ohne die Abhängigkeit von proprietären Kernelbibliotheken. Mit den verbesserten Timing- und Leistungseigenschaften der Unikernel-Architektur können die Leistung und Vorhersagbarkeit von Unikernel-Pipelines leicht mit den Echtzeiteigenschaften von RTOS-Diensten mithalten.
Es bleibt aber noch viel zu tun, was die Standardisierung und die Verfeinerung der Techniken zur Verknüpfung von Komponenten mit Echtzeitbeschränkungen betrifft.
