Warum Hypervisor für die Zonen-Architekturen wichtig sind

Die ECU-Architektur für Fahrzeugdomänen entwickelt sich derzeit dynamisch weiter. Dieser Prozess wird teilweise durch das Kosteneinsparungspotenzial aufgrund der Konsolidierung von ECUs vorangetrieben. Ein wesentlich stärkerer Treiber sind jedoch neue Möglichkeiten, die Fahrzeugfunktionen bieten müssen, um im Automobilmarkt der Zukunft wettbewerbsfähig zu sein. Konsolidierung ist der Motor für die Weiterentwicklung der Systemarchitektur.

Welche Fahrzeug-E/E-Architekturen gibt es?

Fahrzeug-E/E-Architekturen lassen sich in drei Hauptkategorien untergliedern:

• verteilte Architektur
• Domänenarchitektur
• Zonenarchitektur.

Der folgende Abschnitt bietet eine kurze Beschreibung dieser drei Architekturen.

Am etabliertesten ist die verteilte Architektur (Distributed Architecture). Dabei werden Systemfunktionen mit Sensoren, Aktuatoren und Controllern realisiert, die einer oder mehreren dedizierten ECUs zugeordnet sind. Die Interaktion zwischen den ECUs ist begrenzt. Dadurch werden mögliche Synergien zwischen den Systemfunktionen sowohl auf der System- als auch auf der Organisationsebene beschränkt.

OEMs stellen bereits von einer verteilten auf eine domänenbasierte Architektur (Domain Architecture) um. Das Differenzierungsmerkmal der Domänenarchitektur besteht darin, dass Systemfunktionen für eine Fahrzeugdomäne einer High-Performance-Computing-Plattform (HPC) zugeordnet sind, die ein Gateway für die Kommunikation mit anderen Domänen bereitstellt. Die Domänenarchitektur erreicht ihre hohe Performance durch den geringeren Kommunikations-Overhead und die leistungsstarken Plattformen.

Die Zonenarchitektur (Zonal Architecture) zeichnet sich durch die Konsolidierung mehrerer Fahrzeugdomänen auf einer Hardwareplattform aus. Dabei bildet Ethernet das Rückgrat der Hochgeschwindigkeitskommunikation mit Gateways für Fahrzeugsensor- und Aktuator-ECUs. Durch die Konsolidierung der Fahrzeugdomänen lassen sich entsprechende Synergien nutzen. Beispielsweise lassen sich durch die Verknüpfung von Sensordaten verschiedener Fahrzeugdomänen komplexe Systemfunktionen entwickeln.

Das Tempo dieser Entwicklung mag zwar je nach OEM variieren, der Wandel findet jedoch jetzt statt. Deshalb muss sich die Softwarearchitektur parallel dazu verändern, um zukünftige Generationen von Fahrzeug-E/E-Systemen zu unterstützen. Elektrobit bietet hierzu eine Vielzahl von Lösungen.

Änderungen an der Fahrzeug-E/E-Architektur können als Evolution betrachtet werden, ihre Auswirkungen auf OEMs und Tier-1-Zulieferer sind in vielen Fällen eine Revolution: Systemfunktionen, die früher in isolierten ECUs entwickelt wurden, nutzen jetzt eine gemeinsame Plattform. Dadurch ergeben sich für vormals weitgehend unabhängige Entwicklungslebenszyklen und -umgebungen neue Abhängigkeiten. Aufgrund der unterschiedlichen Kritikalität der Software auf einer Plattform und der zunehmenden Nutzung von Open-Source-Software nehmen Systemeigenschaften wie Safety und Security eine neue Dimension an.

Mit dieser Erkenntnis verlagern OEMs die Softwareentwicklung jetzt in das eigene Unternehmen, um die Komplexität dieser konsolidierten Systeme in den Griff zu bekommen. Zur Realisierung einer harmonisierten Fahrzeug-E/E-Architektur müssen sie die Anforderungen jeder Systemfunktion und Fahrzeugdomäne mit der Hardware-, Betriebssystem- und Middleware-Schicht in Einklang bringen.

Für OEMs sind die damit verbundenen Risiken hoch. Werden die Anforderungen eines konsolidierten Fahrzeug-E/E-Systems nicht angemessen harmonisiert, können hohe Wartungskosten, geringere Zuverlässigkeit oder sogar ein verhinderter Produktionsstart die Folge nicht erfüllter Anforderungen einer Fahrzeugdomäne sein. Deshalb ist es entscheidend, neue Anforderungen an die HPC-Softwarearchitektur zu ermitteln, die im Zusammenhang mit der veränderten Entwicklungsumgebung entstehen.

Zur Identifizierung neuer Anforderungen an die Softwarearchitektur ist es hilfreich, die Schichten eines konsolidierten Systems sowohl top-down als auch bottom-up zu betrachten und die Auswirkungen auf seine Elemente zu bewerten. Die folgende Abbildung zeigt die Softwarearchitektur eines konsolidierten Fahrzeug-E/E-Systems.

Die Architektur beginnt oben mit der Systemfunktionsschicht. Die Abbildung verdeutlicht, dass zur Nutzung von Ressourcen wie Speicher, CPU, IO-Geräte oder Dateisysteme direkte Abhängigkeiten zwischen der Applikationssoftware und dem Betriebssystem bestehen können. Darüber hinaus gibt es Abhängigkeiten zwischen der Applikationssoftware und Middleware-Lösungen, um mit anderen lokalen Systemelementen der HPC-Plattform selbst zu kommunizieren und zu interagieren bzw. um mit Systemelementen inner- oder auch außerhalb des Fahrzeugs zu interagieren.

Ein konsolidiertes System muss verschiedene Systemfunktionen mit den vielen unterschiedlichen Anforderungen an Softwaredienste unterstützen. Vor diesem Hintergrund ist wahrscheinlich auch die Unterstützung von Middleware-Frameworks gefordert. Damit muss die Betriebssystemschicht die Anforderungen verschiedener Middleware-Lösungen miteinander in Einklang bringen, um mögliche Rückwirkungen zu vermeiden.

Auf der Hardwareschicht deuten aktuelle Entwicklungen darauf hin, dass neue HPC-Hardwareplattformen auf Anwendungsfälle zugeschnittene Komponenten bereitstellen, die vorher auf getrennten ECUs implementiert wurden. Ein Beispiel sind SoCs mit Echtzeit-CPU-Kernen, die zusammen mit leistungsorientierten Kernen im Lockstep-Modus ausgeführt werden. Die Innovationen bei Automotive-SoC-Plattformen werden die Zentralisierung der Recheninfrastruktur beschleunigen. Sie zwingen Systemarchitekten dazu, die in der klassischen Schichtenarchitektur von Software verwendeten Ansätze neu zu denken.

Aktuelle Multicore-Prozessoren sind leistungsstark genug, um verschiedene Betriebssysteme und deren Userland gleichzeitig zu hosten. Das bedeutet, dass unterschiedliche Profile der konsolidierten Fahrzeug-E/E-Architektur gleichzeitig auf demselben Prozessor gehostet werden können. Dadurch wiederum müssen verschiedene Betriebssysteme und das jeweilige Userland nahtlos in die bereits auf dem Prozessor ausgeführte Software integriert werden. Diese Aufgabe ist alles andere als trivial: Die gemeinsame Infrastruktur und die zugehörigen Devices müssen von unterschiedlichen Betriebssystemen bzw. deren Instanzen transparent gemeinsam verwendet werden; andere Teile sind dagegen ausschließlich einem bestimmten Betriebssystem und dessen Userland-Anwendungen zuzuordnen.

Die Top-down- und Bottom-up-Analyse der konsolidierten Fahrzeug-E/E-Architektur zeigt Folgendes: Die Betriebssystemschicht wird einem enormen Druck ausgesetzt sein, die unterschiedlichen Anforderungen von Applikationssoftware und Middleware mit neuen Tools, ermöglicht durch Hardware-Innovationen, miteinander in Einklang zu bringen.

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.

Der Hypervisor EB corbos ist ein Bare-Metal-Hypervisor für Automotive-E/E-Systeme. Er bietet sowohl die von einem typischen Embedded-Betriebssystem erwartete native Ausführungsumgebung als auch eine Ausführungsumgebung für virtualisierte Betriebssysteme wie Linux. EB corbos bietet im Gegensatz zu einem konventionellen Hypervisor dedizierte Safety- und Security-Eigenschaften, die auf seiner Microkernel-Architektur beruhen.

Die Stärke der Microkernel-Architektur liegt in der Minimierung der Codemenge, die im privilegierten Modus ausgeführt werden kann. Beim Hypervisor EB corbos können Benutzerprozesse und Gastbetriebssysteme im nicht privilegierten Modus sowie über Zusatzfunktionen des Betriebssystems laufen. Damit bleibt ein systematischer Ausfall oder der Angriff auf eine Komponente wie einen Device-Treiber auf den Userspace-Prozess begrenzt, in dem der Treiber ausgeführt wird. Gleichzeitig ist der Speicher des Microkernels von möglichen Rückwirkungen getrennt; dies erhöht die Robustheit und Sicherheit des gesamten Software-Stacks. Beim Ausfall einer Komponente, zum Beispiel eines Device-Treibers, kann der Microkernel seinen Serverprozess wie jede andere Benutzeranwendung beenden und neu starten.

Der EB corbos Hypervisor bietet im Bereich zentrale Funktionen Userspace-Tasks, -Threads und -Scheduling-Richtlinien, aber auch prozessübergreifende Kommunikation zwischen Tasks sowie virtuelle Speicherverwaltung, Zugriff auf IO-Devices und Energieverwaltung. Im Rahmen der Betriebssystem-Virtualisierung verfügt EB corbos über Virtual-Machine-Monitore zur Steuerung von Gastbetriebssystemen und über VirtIO-Server zur Virtualisierung der I/O-Kommunikation zwischen Gastbetriebssystemen, während er gleichzeitig einen transparenten Zugriff auf Hardware-Devices ermöglicht und eine Multiplex-Shell-Schnittstelle zu Gastbetriebssystemen bietet. In puncto Safety unterstützt EB corbos im Wesentlichen in drei Punkten. So erstellt ein Startprogramm für die Sicherheitsanwendung eine nach ISO 26262 entwickelte Sicherheitspartition für POSIX-Prozesse, während der Microkernel- und Stammspeicher-Pager nach ISO 26262 qualifiziert ist. Das gesamte Sicherheitskonzept ist genehmigt durch TÜV Süd Rail.

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.

Zusammengefasst bietet der Hypervisor EB corbos ein Framework zur nahtlosen Integration von Gastbetriebssystemen und nativen Prozessen mit unterschiedlicher Kritikalität auf derselben Hardwareplattform. (av)