Zentralisierung von Software in Fahrzeugen Hardware-Hypervisor: Auto-Apps zuverlässig virtualisieren

Anbieter zum Thema

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

ISH Ingenieursozietät GmbH

Sichere, Hardware-basierte Virtualisierung ist der Schlüssel dafür, dass bei Fahrzeugen das Zentralisieren von immer mehr Software- Funktionen in immer weniger elektronischen Steuergeräten (ECU) gelingt.

Automobilhersteller wollen ihren Kunden immer mehr Komfort, Konfigu­rationsmöglichkeiten und Services bieten. Dadurch steigt die Komplexität der Software und der zugrundeliegenden Hardware. Gleichzeitig sind OEMs bestrebt, die Zahl der elektronischen Steuergeräte (Elec­tronic Control Units, ECUs) im Auto zu verringern und mehr Softwarepakete in einer ECU zu implementieren. Um die Anforderungen zu erfüllen, befindet sich die Struktur der Systeme in unseren Autos im Wandel – geprägt durch den Trend, mehrere ECUs in einer großen ECU zusammenzufassen.

Hierfür muss die Hardware so beschaffen sein, dass sich verschiedene Softwarepakete separieren lassen und eine reproduzierbare Echtzeit-Performance geboten wird. Gegenseitige Beeinflussungen müssen zudem ausgeschlossen sein. Erreichen lässt sich diese Separierung durch eine Virtualisierung, die entweder nur auf der Softwareebene oder mit Hardware-Unterstützung erfolgen kann.

Bildergalerie

Bildergalerie mit 5 Bildern

STMicroelectronics hat sich für die Umsetzung mithilfe eines Hardware-Hypervisors (HV) entschieden und die ARM-basierte Stellar-Produktfamilie von Automotive-Mikrocon­trollern entwickelt. Diese eignet sich für Anwendungen gemäß ISO 26262 ASIL-D und zielt nicht nur auf den Antriebsstrang, sondern auch auf Gateway-, Chassis- und Safety-Applikationen mit den kommenden Generationen von Domain-Architekturen.

Grundlage der Chips bildet der energie­effiziente 28-nm-FD-SOI-Prozess (Fully Depleted Silicon on Insulator). Als Speicher ist schnelles Phase-Change Memory (PCM) integriert. OTA-Support (Over-The-Air) schafft die Voraussetzung für unkomplizierte Updates der Embedded-Automotive-Produkte. Das entscheidende Element der Stellar- Familie ist die hardwaremäßige Virtualisierungs-Unterstützung, mit der STMicroelec­tronics die neuesten Konzepte und Trends in der Automotive-Welt unterstützen will.

Höherer Takt und mehr Kerne reichen nicht mehr

Vorbei sind die Zeiten, in denen man Performance-Zuwächse einfach durch Anheben der Taktfrequenz oder durch mehr Prozessorkerne erzielen konnte]. Die Software der Mikrocontroller ist mittlerweile so komplex geworden, dass ein schlichtes Erhöhen der Megahertz-Werte nicht mehr zum gewünschten Resultat führt.

Überdies kommt noch ein weiterer Parameter ins Spiel, nämlich die Separierbarkeit. Da OEMs ihre Software von verschiedenen Tier-1-Zulieferern beziehen, wird jeder Teil der Software in einer Art Sandkasten ohne Kenntnis der übrigen Softwareelemente entwickelt.

Alle Softwarekomponenten müssen deshalb vollkommen eigenständig sein und zu beliebigen Zeitpunkten aktualisiert werden können, und zwar unter völliger Einhaltung der Sicherheitsanforderungen und ohne gegenseitige Beeinflussungen. Der entscheidende Faktor, der die Entwicklung schwierig macht, ist also die Partitionierung des Systems. Deshalb entschied man sich für eine vollständige Separierung der Software und die Unterstützung durch einen Hypervisor.

Welche verschiedenen Arten von Hypervisoren gibt es?

Es gibt zwei Arten von Hypervisoren, jede hat Vor- und Nachteile. Grundsätzlich gilt: Während per Software emulierte Funktionen zu Lasten der Performance gehen, schränkt eine Hardware-basierte Umsetzung die Portierbarkeit ein. Software-Hypervisoren lassen sich auf beliebige Geräte portieren, da der zum Separieren nötige Teil im Prinzip ein weiteres Betriebssystem ist.

Diese Typ 2 genannten Hypervisoren ähneln einer virtuellen Maschine auf einem PC wie VirtualBox [3]. Unter Beachtung zielspezifischer Funktionen lassen sich Typ-2-Hypervisoren auf unterschiedliche Mikrocontroller portieren. Ein Hardware-Hypervisor kommt ohne ein zusätzliches Betriebssystem aus, da die für die Separierung erforderlichen Funktionen fest integriert sind.

Mehrere Separationsebenen, konfiguriert per Software

Software kommt hauptsächlich für die Konfiguration zum Einsatz. Unter dem Strich sind eine geringere Core-Auslastung, eine höhere Verarbeitungsgeschwindigkeit und weniger Overhead zu verbuchen. Der in der Stellar-Familie verwendete ARM Cortex-R52-Core wartet mit drei Separierungsebenen auf [4]:

• Exception Level 2: Wird vom Hypervisor genutzt und sorgt für die gesamte Virtualisierung sowie das Management der gemeinsam genutzten Ressourcen.

• Exception Level 1: Verarbeitet das Betriebssystem.

• Exception Level 0: Auf dieser Ebene läuft die finale Applikation.

Je niedriger der Exception Level ist, umso weniger Rechte hat die Software. Die Memory Protection Unit (MPU) mit ihren zwei Bereichssätzen (für EL2 und EL1) setzt die Restriktionen von Seiten des ARM-R52 um. Die Stellar-Familie arbeitet mit bis zu 9 ARM-basierten Cores vom Typ R52 oder M4 – jeder muss zielseitig identifizierbar sein.

Dazu wird die Virtual Machine Identification (VMID) auf dem Bus übertragen. Nur der Cortex-R52 unterstützt dieses Seitenbandsignal nativ, für andere Master wie den Cortex-M4 ist eine Hardware-Erweiterung erforderlich. Ein im Network On Chip (NOC) inte­griertes Firewall-(FW-)Element schützt die Ressourcen vor unerwünschten Zugriffen. Stellar-Controller verteilen mehrere Firewalls auf verschiedene Ressourcen (Bild 3). Abhängig von der VMID erlauben oder verhindern diese Firewalls Schreib- und Lesezugriffe auf die betreffenden Ressourcen.

Hypervisor definiert Grenzen und Zugriffsrechte

Die Hypervisor-Software konfiguriert die Grenzen und die Zugriffsrechte der Master auf die verschiedenen Slaves bzw. die gemeinsam genutzten Ressourcen. In Bild 4 ist der Ablauf der Konfiguration und Ausführung für zwei virtuelle Maschinen (VM 1 und VM 2) zu sehen. Nach dem Power-On-Reset beginnt der ARM-R52 bei EL2.

Auf dieser höchsten Privilegierungsstufe kann der Core auf alle für die Konfiguration nötigen Speicherstellen zugreifen. Als erstes werden die Grenzen der virtuellen Maschinen festgelegt. Dazu zählt das Konfigurieren der Firewalls und das Zuweisung der Peripheriefunktionen zu den VMs einschließlich der korrekten VMID für die Verarbeitungseinheit.

Kontextwechsel zeit- oder ereignisgesteuert

Kommt es zu Kontextwechseln, also zum Wechsel von einer Task zur anderen und in diesem Fall auch von einer VM zur anderen, müssen die Informationen über den aktuellen Stand der Verarbeitung abgespeichert bzw. geladen werden. Dies umfasst CPU-Register, mit Interrupts verknüpfte Register und die Grenzen der MPU-Regionen. Während der Verarbeitung durch eine VM können Kontextwechsel entweder zeitgesteuert oder durch ein Ereignis angestoßen werden (Bild 5) – bei Stellar erfolgt dies ohne Belastung der Cores.

Als gemeinsam genutzte Ressourcen lassen sich auch Interrupts virtualisieren. Die ARM-Architektur arbeitet mit zwei verschiedenen Interrupts: den Fast Interrupt Request (FIQ) und den Interrupt Request (IRQ). Aus Sicht der Virtualisierung können beide entweder virtualisiert – d. h. an den Hypervisor weitergeleitet (EL2) – oder direkt an den Supervisor verwiesen werden (EL1). Bei Weiterleitung an den Hypervisor lässt sich der Interrupt entweder auf EL2 verarbeiten oder an die Ziel-VM weiterleiten.

Neuste Domain-Architekturen verlangen nach Virtualisierung

Virtualisierung ist unverzichtbar, um die Anforderungen der neuesten Softwaretrends und Domain-Architekturen erfüllen zu können. Umsetzen lässt sich die Virtualisierung auf zweierlei Weise, wobei die Komplexität entweder in der Software oder in der Hardware angesiedelt ist. Hier ist es erforderlich, gewohnte Denkmuster zu verlassen.

Um das Maximum aus einem System herauszuholen, muss die Software um den Mikrocontroller herumgebaut werden und die Hardware berücksichtigen. Die Hardware-Lösung ist am besten für eine schnelle und sichere Separierung der Software geeignet, wie sie für die künftigen Softwarearchitekturen im Automobilbereich unerlässlich ist.

* Jan Pistulka ... ist Marketing and Application Manager bei STMicroelectronics EMEA ADG.

(ID:47462453)