Diese Konsequenzen hat die Plattform-Konsolidierung von ECUs

Bei der Bewältigung der neuen Herausforderungen für die Betriebssystemschicht wird die Virtualisierung zu einem starken Instrument. Der Grund ist ihre Fähigkeit, sowohl Systemfunktionen in deren eigener Betriebsumgebung zu kapseln als auch Ressourcen systemweit transparent zu schützen und zu teilen. Deshalb wird die Hypervisor-Technologie in zukünftigen Fahrzeug-E/E-Architekturen eine zunehmend größere Rolle spielen.

Der Einsatz von Hypervisoren hat sich zwar erst im letzten Jahrzehnt durchgesetzt, das zugrunde liegende Konzept etablierte sich jedoch bereits früh in der Geschichte der Betriebssystementwicklung. Der Begriff Hypervisor hat seinen Ursprung in einer früheren Bezeichnung für ein Betriebssystem, nämlich Supervisor. Ein Hypervisor ist im Wesentlichen der Supervisor eines Supervisors oder anders ausgedrückt: ein Betriebssystem für Betriebssysteme. Ungefähr 2005 nahm die Verwendung von Hypervisor-Technologien im IT-Serverbereich rasant zu. Diese Entwicklung war hauptsächlich auf Hardware-Innovationen zurückzuführen, die die Verarbeitung privilegierter Befehle, ausgeführt von Gastbetriebssystemen, drastisch verbesserte. Embedded-Hypervisoren sind bereits in aktuellen Fahrzeugsystemen im Einsatz.

Ein guter Hypervisor fungiert als Framework zur nahtlosen Integration von Gastbetriebssystemen und nativen Prozessen mit unterschiedlicher Kritikalität auf derselben Hardwareplattform, aber aus der Konsolidierung von ECUs auf einer Plattform ergeben sich sieben neue Anforderungen:

Ein Betriebssystem nimmt an, dass es die alleinige Kontrolle über die Hardwareplattform hat, auf der es ausgeführt wird. Die klassische Technologie zur transparenten gemeinsamen Nutzung von Hardware durch Betriebssysteme bezeichnet man als Virtualisierung – mit virtuellen Maschinen als Kapselung von (Gast-)Betriebssystemen, deren Userland und Anwendungen.

Durch die Virtualisierung kann die Variantenanzahl der konsolidierten E/E-Architektur verringert und damit der Aufwand zur Unterstützung einer neuen Hardwareplattform im Hypervisor gekapselt werden. Dies führt letztlich zu Kostensenkungen bei der Weiterentwicklung der konsolidierten Fahrzeug-E/E-Architektur.

Bei der Ausführung im Hypervisor EB corbos ist die Hardwareplattform virtualisiert; ein Betriebssystem hat lediglich eine allgemeine Sicht auf die Plattformhardware. Des Weiteren unterstützt der Hypervisor die Zuordnung von Hardwaregeräten zu bestimmten virtuellen Maschinen. Ein Bare-Metal-Hypervisor ist dafür zuständig, einem gehosteten Betriebssystem Hardwaregeräte bereitzustellen. Daher hat er die Möglichkeit, zu steuern, auf welche Geräte Zugriff besteht. Folglich kann der Systemdesigner differenziert steuern, welche Hardware-Devices ausschließlich von einer virtuellen Maschine verwendet und welche gemeinsam genutzt werden können. Mit dieser Modularität lässt sich ein hochgradig skalierbares System aufbauen, in dem mögliche Rückwirkungen zwischen getrennt entwickelten Systemfunktionen vermieden werden.

Elektrobit entwickelt den Hypervisor EB corbos mit der Unterstützung und dem Know-how der Mitarbeiter von Kernkonzept. Der Hypervisor EB corbos beruht auf Kernkonzepts Capability-basiertem L4Re Operating System Framework und erfüllt dadurch die Sicherheitsanforderungen leistungsstarker Automobil-ECUs. Das L4Re-System ist ein Virtualisierungsprodukt auf Basis des L4-Mikrokernels. Es nutzt die Hardware-Virtualisierungsunterstützung der gängigen Architekturen wie Arm, x86 oder RISC-V und ist die Open-Source-Lösung zur Entwicklung hochgradig sicherer Laufzeitumgebungen.

Bei einer verteilten Entwicklung muss jeder Partner seine Software in einer klar definierten Umgebung entwickeln. Andernfalls kommt es bei der späteren Integration der Software möglicherweise zu Abweichungen im Laufzeitverhalten. So können beispielsweise fehlende Bibliotheken oder unterschiedliche Bibliotheksversionen in der Zielentwicklungsumgebung zu Konflikten bei der Integration führen.

EB corbos unterstützt die Nutzung vorkonfigurierter Ausführungsumgebungen. Diese Umgebungen sind im Wesentlichen das Abbild eines konfigurierten Betriebssystems. Sie bieten eine schnelle und zuverlässige Möglichkeit zur Beschleunigung des verteilten Entwicklungsprozesses. Gleichzeitig stellt eine vorkonfigurierte Ausführungsumgebung sicher, dass die Entwicklungspartner eine Umgebung verwenden, die die Qualitäts-, Safety- und Security-Anforderungen der gesamten konsolidierten Fahrzeug-E/E-Architektur erfüllt.

Aufgrund der Anzahl unterschiedlicher Funktionen, die der konsolidierten Fahrzeug-E/E-Architektur zugeordnet sind, ist ein Mechanismus zur Gewährleistung schneller Startzeiten für kritische Systemfunktionen unerlässlich. Es muss sichergestellt werden, dass nicht-kritische Systemfunktionen die Startzeitwerte kritischer Systemfunktionen nicht beeinträchtigen.

Die Priorisierung kann natürlich auf der Applikationsebene implementiert werden, zum Beispiel über das kooperative Scheduling von Systemfunktionen. Diese Designstrategie erhöht jedoch die Komplexität der Auslegung jeder Systemfunktion, da nicht wesentliche Abhängigkeiten zwischen Systemfunktionen hinzukommen.

Der Hypervisor EB corbos unterstützt die transparente Priorisierung des Starts virtueller Maschinen; mit der Hypervisor-Startstrategie ist nur der Systemarchitekt befasst. Dies stellt sicher, dass Systemressourcen zuerst wesentlichen Systemfunktionen zugeordnet werden, damit deren Initialisierung frühestmöglich abgeschlossen werden kann. So wird weiterhin sichergestellt, dass auf dem Hypervisor ausgeführte Systemfunktionen nicht über das Startverhalten von Elementen eines Systems informiert sind, die nicht im Zusammenhang mit ihnen stehen.

Ein wesentliches Merkmal eines Betriebssystems ist das Teilen globaler Software-Ressourcen mit der Applikationssoftware. Anstatt eine Bibliothek direkt in eine Anwendung einzubauen, besteht beispielsweise beim Start die Möglichkeit, eine gemeinsam genutzte Bibliothek zu laden. Dies reduziert den gesamten ROM-Bedarf für die Software. Zusätzlich können gemeinsam genutzte Bibliotheken einzeln aktualisiert werden, ohne jedes entsprechende Programm aktualisieren zu müssen.

Ein Problem, das im Laufe der Lebenszeit eines Betriebssystems häufig auftritt, wird bisweilen als „Abhängigkeitshölle“ bezeichnet. Es entsteht in der Regel, wenn die Anzahl der durch die Middleware-Schicht unterstützten Frameworks steigt. Dabei weichen die von jedem Framework benötigten Versionen der Bibliotheken und Betriebssystemschnittstellen schließlich voneinander ab. Folglich müssen Frameworks zur Integration in neue Bibliotheksversionen regelmäßig aktualisiert werden, obwohl in den Frameworks selbst keine Änderungen nötig sind. Analog dazu kann für Legacy-Frameworks, die auf demselben Betriebssystem ausgeführt werden, ein Downgrade von Bibliotheksversionen erforderlich sein.

EB corbos partitioniert das System auf der Betriebssystemebene. Dies verringert die Wahrscheinlichkeit für Konflikte in den erforderlichen gemeinsam genutzten Bibliotheken und Diensten, auf die die Applikationssoftware zugreift. Jede Betriebssysteminstanz stellt eine Konfiguration bereit, die sich unabhängig steuern lässt. Auf diese Weise reduziert sich der Gesamtaufwand für die Verwaltung der von verschiedenen Systemfunktionen benötigten individuellen Betriebssystemkonfigurationen.

Sicherheitsrelevanten Anwendungen wird eine sichere Ausführungsumgebung zur Verfügung gestellt: Sie können ihre Funktionalität umsetzen, ohne aufgrund von Fehlfunktionen im konsolidierten Fahrzeug-E/E-System Menschen zu gefährden. Für eine sichere Ausführungsumgebung müssen drei Voraussetzungen erfüllt sein: Erstens muss die zugrunde liegende Hardware-Software-Schnittstelle wie vorgesehen funktionieren. Zweitens muss das Betriebssystem, in dem die Applikationssoftware ausgeführt wird, wie vorgesehen funktionieren. Und drittens muss für alle sicherheitsrelevanten Elemente des Systems Rückwirkungsfreiheit gewährleistet sein.

Der Hypervisor EB corbos unterstützt eine sichere Ausführungsumgebung für sicherheitsrelevante Anwendungen. Er erfüllt die Anforderungen der ISO 26262 in Bezug auf die sicherheitsrelevante Entwicklung und Verifikation. Dies verringert die Wahrscheinlichkeit von Laufzeitfehlern im Hypervisor-Code und sorgt für die sichere Verwendung von Hardwareschnittstellen. Zusätzlich erfüllt dieser Hypervisor auf der Systemebene die Anforderungen „Spatial Freedom from Interference“ und „Temporal Freedom from Interference“. Sichergestellt wird dies durch die Partitionierung der Hardware- und Software-Elemente des Systems.

Die Partitionierung ist ein einfaches, starkes Argument dafür, dass zwischen Komponenten, die mit unterschiedlichen Vertrauensstufen entwickelt wurden, keine Rückwirkungen möglich sind. Eine Partitionierung kann auf verschiedenen Ebenen der Software-Architektur der konsolidierten Fahrzeug-E/E-Architektur durchgeführt werden. Ein auf Bare Metal ausgeführter Microkernel-Hypervisor ist das wirkungsvollste Argument für eine abgeschlossene Partitionierung. Dies ist darauf zurückzuführen, dass auf höheren Ebenen der Softwarearchitektur die Anzahl der Schnittstellen mit potenziellen Rückwirkungen zunimmt. Bei der Partitionierung innerhalb eines Betriebssystems sind weitere Maßnahmen erforderlich, um sicherzustellen, dass alle Probleme hinsichtlich möglicher Rückwirkungen ermittelt und reduziert werden.

Aufgrund der zunehmenden Unterstützung vernetzter Systemfunktionen spielt Security in der konsolidierten Fahrzeug-E/E-Architektur eine noch wichtigere Rolle. Schwachstellen in Betriebssystemen und Middleware-Frameworks können zu Exploits führen, die wiederum den Missbrauch von der konsolidierten Fahrzeug-E/E-Architekturplattform zugeordneten Systemfunktionen zur Folge haben.

Der Hypervisor von EB senkt die Gefahr von Bedrohungen für Assets wie Kryptografiedienste, Benutzerdatenzugriff, Netzwerkinformationsfluss und Identy Access Control. Dazu werden sämtliche Hypervisor-Ressourcen in Capabilities gekapselt, die nur der Microkernel ändern kann. Der Versuch, auf Capabilities zuzugreifen, die der Systemarchitekt nicht konfiguriert hat, erkennt das System sofort. Die Capabilities ziehen sichere Grenzen zwischen Prozessen und Betriebssysteminstanzen der konsolidierten Fahrzeug-E/E-Architektur. Darüber hinaus dienen sie zum Aufbau entsprechender vertrauenswürdiger Kommunikationskanäle.

Systemfunktionen im Fahrzeug werden in der Regel iterativ über mehrere Fahrzeug-Abstraktionsebenen hinweg entwickelt und integriert. Systems-Engineering-Prozesse stellen sicher, dass sich die integrierten Systemfunktionen bei der Integration in die höheren Fahrzeug-Abstraktionsebenen auslegungsgemäß verhalten. Unnötige Abhängigkeiten zwischen Systemfunktionen führen zu höheren Entwicklungskosten und längeren Entwicklungszyklen.

Auf Prozessebene oder auf der Ebene der virtuellen Maschinen bietet EB corbos isolierte Ausführungsumgebungen, die sich ausschließlich einer Organisationseinheit zuordnen lassen. Das Ergebnis ist eine vereinfachte Systemintegration dank geringerer Auswirkungen der Ausführungsumgebungen für eine Systemfunktion auf andere, nicht mit ihr im Zusammenhang stehende Systemfunktionen.

Die zuvor beschriebenen Anforderungen zeigen, dass der Hypervisor EB corbos für OEMs eine adäquate Lösung zur Realisierung zukünftiger konsolidierter Fahrzeug-E/E-Architekturen ist, weil der Hypervisor die passende kompositionelle Beschaffenheit des Systems ermöglicht. Weil die Anforderungen der konsolidierten Fahrzeug-E/E-Architektur immer vielfältiger werden, beginnt die monolithische Software-Architektur mit ihrer hochintegrierten Middleware- und Betriebssystemschicht daran zu scheitern. Bei älteren ECUs, die im Fahrzeug isoliert waren, mag die monolithische Architektur gut funktioniert haben, aber die Softwarearchitektur einer konsolidierten Fahrzeug-E/E-Architektur muss zur Skalierung in eine kompositionelle Plattform mit weniger Abhängigkeiten zwischen den Komponenten übergehen.

Die Weiterverwendung einer monolithischen Software-Architektur führt nicht nur auf der System-, sondern auch auf der Organisationsebene zu Problemen. Zunächst müssen Geschäftseinheiten in einem Unternehmen eine matrixförmige Organisationsstruktur beherrschen, um von anderen Einheiten entwickelte Systemfunktionen zu ergänzen, die auf derselben Plattform ausgeführt werden. Als Folge daraus heißt es, Entwicklung und Wartung zwischen den Geschäftseinheiten zu synchronisieren.

Ein weiteres Problem für OEMs und Tier-1s ist das Management konkurrierender Anforderungen an die Betriebssystemschicht. In vielen Fällen wird eine einzige Plattform diese Anforderungen nicht erfüllen können, so dass in der Konsequenz einige Systemfunktionen möglicherweise nicht wie gewünscht ausgeführt werden oder unter Umständen nicht realisierbar sind.

Auch Safety und Security werden in einer Software-Architektur mit unterschiedlicher Kritikalität zu einem massiven Problem. Für alle Elemente eines Systems müssen Kriterien für die Koexistenz angegeben werden. Das gilt auch für Open-Source-Software, die darauf ausgeführt wird. Ab einem gewissen Grad an Systemkomplexität sind Safety und Security nicht mehr realistisch zu gewährleisten.

Paradoxerweise kann sich der Wartungsaufwand für ein monolithisches System bei einer konsolidierten Fahrzeug-E/E-Architektur drastisch erhöhen. Ursache hierfür sind die verstärkten Abhängigkeiten zwischen den Softwareelementen einer Plattform. Eine geringfügige Änderung in einem Softwareelement muss gegebenenfalls mit einer Vielzahl von Systemelementen synchronisiert werden. Bei einem kompositionellen System sind die Auswirkungen der Änderung jedoch auf ein Teilsystem beschränkt. Dies reduziert den Aufwand für die Implementierung, Verifizierung und Bereitstellung der erforderlichen Änderungen.

Die zukünftige Fahrzeug-E/E-Architektur konsolidiert ECUs auf einer leistungsstarken Plattform. Jetzt sollte klar sein, dass diese Architektur eine neue Art der Systemauslegung erforderlich macht, die der Hypervisor EB corbos in seiner speziellen Art und Weise unterstützt. So bietet er Systemelementen mit unterschiedlichen Vertrauensstufen eine sichere Ausführungsumgebung. Aber er unterstützt darüber hinaus auch die transparente gemeinsame Nutzung von Systemressourcen. So lassen sich skalierbare Plattformen mit minimalen Abhängigkeiten zwischen Systemelementen erstellen. Schließlich liefert der EB corbos die Grundlage für die Organisation der Tätigkeiten in einer verteilten Entwicklungsumgebung. Damit ist er ein zentraler Bestandteil bei der Realisierung zukünftiger Fahrzeug-E/E-Architekturen.