Sichere Integration heterogener Software-Welten

Je mehr das Auto und die moderne Unterhaltungselektronik verschmelzen, desto größer wird die damit einhergehende Herausforderung. Bisher sind Fahrzeugsysteme und mobile Endgeräte mit Internetzugang nur wenig integriert. Dieses Prinzip lässt sich in einer vernetzten Welt jedoch nicht durchhalten. Im Auto begegnen sich zwangsläufig Software-Welten, die nicht ohne weiteres kompatibel sind. Eine der sattsam bekannten Hürden bilden die schnellen Weiterentwicklungszyklen der Unterhaltungselektronik. Aber nicht nur neue Apps sowie Updates bekannter Systeme treiben die Dynamik. Das rasante Aufkommen der vergleichsweise jungen Android-Technik zeigt, dass im Prinzip jederzeit ein komplett neues Betriebssystem zum globalen Trend werden kann.

Die Virtualisierung per Hypervisor ermöglicht neue Cockpit-Konzepte im Rahmen der Connectivity.Continental

Gleichzeitig hat das Auto aus nachvollziehbarem Grund einen Standard wie Autosar hervorgebracht, um angesichts der wachsenden Komplexität der Automobilelektronik die Entwicklung und den Test zuverlässiger, sicherer und wiederverwendbarer Software beherrschbar zu halten. Schon die systemtechnischen Anforderungen von Autosar-Funktionen unterscheiden sich grundlegend von denen eines Linux-basierten Multimediasystems, das ebenso Bestandteil eines modernen Fahrzeugcockpits ist. Während originäre Fahrzeugsysteme wie ein Kombiinstrument beispielsweise harte Echtzeitanforderungen, schnelle Verfügbarkeit, hohe Ausfallsicherheit und hohe Wiederholfrequenzen in der Grafik benötigen, müssen bei Multimedia-Anwendungen aufgrund der viel höheren Softwarekomplexität diesbezüglich Abstriche hingenommen werden. Hier stehen Rechenkapazitäten und große Datenvolumen im Mittelpunkt (Tabelle 1). Wegen dieser Verschiedenheit sind die unterschiedlichen Software-Welten heute in getrennten Steuergeräten (ECUs) untergebracht. So ist beispielsweise die Funktionalität des Kombi-Instruments in einer ECU konzentriert, während die Multimedia-Welt von der Head-Unit gesteuert wird.

Tabelle 1: Unterschiedliche Anforderungen von Interior Software-Welten.Continental

Würde man dieses Prinzip fortschreiben, so käme mit der dynamischen Welt der Android-Apps mit Internetzugang noch eine weitere ECU hinzu. Vor allem in kompakten und mittleren Fahrzeugsegmenten liegt es nahe, eine solche Hardware-Proliferation zu vermeiden und bisher getrennte ECUs in einer Domäne zu integrieren. Leistungsfähige Multicore-CPUs bieten dafür heute optimale Voraussetzungen.

Ganzheitliches HMI durch Domänenintegration

Im Kern geht es bei einer solchen Domänenintegration gar nicht so sehr um Software-Welten und Systemanforderungen – auch wenn diese Aspekte die unmittelbare technische Aufgabe umreißen. Eigentlich geht es um den Fahrer: um dessen Zugang zu innovativen Funktionen und deren Nutzbarkeit im Fahrzeug-Cockpit. Solange die einzelnen Software-Welten getrennt existieren und starr verschiedenen Displays zugeordnet werden, muss der Fahrer die Integration selbst leisten. Dazu muss er sich je nach Software-Welt, die er gerade bedient oder nutzen möchte an das Bedienkonzept anpassen. Diese geistige Eigenleistung steht jedoch in Konkurrenz zur Konzentration auf die Fahraufgabe. Deshalb scheint es angesichts der Zahl an elektronischen Systemen im Fahrzeug geboten, dem Fahrer diese Anpassungsleistung abzunehmen. Der Mensch am Steuer tut sich wesentlich leichter, wenn er oder sie bei jeder Bedienung und bei jeder Systemnutzung nach denselben einheitlichen Prinzipien vorgehen kann.

Noch besser ist es, wenn der Fahrer oder die Fahrerin je nach Verkehrssituation und je nach persönlicher Verfassung stets die relevanten Informationen angezeigt bekommt, die in der Situation auf einem bestimmten Kanal (visuell, akustisch, haptisch) optimal wahrgenommen werden. Eine solche multimodale Mensch-Maschine-Schnittstelle (HMI), die ein durchgängiges Anzeige- und Bedienkonzept zur situativ optimierten Darstellung von Inhalten nutzt, ist eine Basis für ein holistisches HMI. Je größer die Heterogenität der Systemwelten im Cockpit, desto wichtiger wird die Entwicklung in Richtung eines holistischen HMI, um die Leistung des Fahrers oder der Fahrerin an der Schnittstelle zu erhalten. Bei der Domänenintegration werden mit diesem Ziel mehrere Displays und Softwarewelten einheitlich von einer Hardware aus koordiniert. Um dem Fahrer die wichtigste Information dort anzuzeigen, wo er sie am besten verarbeiten kann, werden Inhalte situativ angezeigt: im Kombi-Instrument, im Head-up-Display (HUD), im Display der Mittelkonsole oder auch im verbundenen mobilen Endgerät.

Unveränderte Software-Welten höher integrieren

Bild 1: Schematische Struktur einer Virtualisierung mit Hypervisor.Continental

Angesichts der unterschiedlichen Anforderungen von Autosar, Genivi/Linux und Android wäre es ein immenser Aufwand, eine eigene, umfassende Automobillösung zur Integration dieser Software-Welten zu entwickeln. Selbst wenn es gelingt, ein derart mächtiges System stabil zu machen, wäre es kaum zertifizierbar. Also kann die Lösung nur darin bestehen, möglichst unveränderte und ausgereifte Software-Welten ins Auto zu integrieren. Das bewährte Prinzip der Integration, das bisher nur bei harmonischen Anforderungsprofilen galt, muss dafür auch auf heterogene Profile ausgedehnt werden.

Um diese höhere Integration möglich zu machen, hat Continental in Zusammenarbeit mit Sysgo Hypervisor-Technologie ins Auto transferiert. Der Hypervisor PikeOS teilt Ressourcen, wie etwa die Rechenleistung einer Multicore-CPU, in mehrere virtuelle Rechner auf. Bild 1 zeigt ein Schema der Schichtenarchitektur. Die drei Software-Technologien Autosar, Genivi/Linux und Android laufen parallel und strikt separiert auf virtuellen Maschinen, die nicht notwendigerweise mit einzelnen Kernen identisch sind. Derzeit kommen dafür Multicore-CPUs mit bis zu vier Kernen zum Einsatz.

Selbst wenn eine Anwendung aus der Unterhaltungselektronik auf einer virtuellen Maschine Probleme bereitet, laufen die anderen Anwendungen unbeeinflusst weiter. Unterschiedliche Sicherheitsanforderungen und gänzlich verschiedene Software-Lebenszyklen können so auf einer Hardware koexistieren. Einzelne Software-Pakete lassen sich jederzeit aktualisieren, um die Entwicklungsdynamik in der Unterhaltungselektronik mit dem Auto kompatibel zu machen.

Sichere Trennung zwischen Trusted und Untrusted

Bild 2: Die Security Policy mit den Sicherheitsregeln einer Firewall schottet Trusted Automotive Systeme gegen Untrusted Systeme ab. Der Hypervisor erlaubt eine kontrollierte Kommunikation der Betriebssysteme mit Secure In/Out.Continental

Entscheidend für die Nutzung eines Hypervisors im Fahrzeug ist, dass dieser zertifizierbar ist. Nur so lassen sich sicherheitsrelevante Funktionen ohne zusätzliche ECU bündeln. Eine Stärke des Sysgo-Hypervisors liegt darin, dass diese Software mit nur wenigen tausend sehr genau geprüften Codezeilen ausreichend schlank ist, um zertifiziert werden zu können. Ein Vergleich mit der Mächtigkeit von Linux macht deutlich, worum es dabei geht: Bei mehreren hunderttausend Codezeilen ist ein Linux-System mit etwa 500 MByte Umfang schlichtweg nicht mit vertretbarem Aufwand zertifizierbar.

Der Hypervisor sorgt für die strikte Separierung zwischen den virtuellen Maschinen, den darauf laufenden Betriebssystemen und den In/Outs der Hardware. Durch diese Abschottung haben die virtuellen Maschinen direkten Hardwarezugriff nur soweit dies der Hypervisor zulässt. Teilen sich virtuelle Maschinen spezielle Hardware, müssen sie über den Hypervisor bei den Shared Services (= Server) anfragen. Handelt es sich dabei um eine untrusted virtuelle Maschine, wird die Sicherheitspolitik (Security Policy) mit einbezogen. Bild 2 zeigt das Prinzip. Selbst wenn der angefragte Hardwarezugriff gemäß der Sicherheitspolitik zulässig ist, stellt der Server selbst über den Hypervisor die benötigten Daten bereit.

Es gehört also zu den Grundprinzipien des verwendeten „Secure In/Out“, dass alle Zugriffe auf gemeinsam genutzte Hardware nur über den Hypervisor erfolgen, nicht direkt von einem Betriebssystem. Beispielsweise kann die Hypervsior-Trennschicht Linux daran hindern, auf einem Speicher zu schreiben. Der Hypervisor erlaubt lediglich eine kontrollierte Kommunikation zwischen Betriebssystemen. Damit sind auch Probleme wie Data Races, die durch unkoordinierten Schreibzugriff mehrerer virtueller Maschinen entstehen können, ausgeschlossen.

Bild 3: Ausgewählte Entscheidungskriterien für eine Virtualisierung mittels Hypervisor beziehungsweise für dedizierte ECUs.Continental

Durch diese Abschottung und die Security Policy lassen sich unterschiedliche Levels of Trust unterscheiden, obwohl sie auf derselben Hardware laufen. So ist es möglich, eine ASIL-B-Funktion mit wenigen tausend Codezeilen sicher neben Linux zu betreiben. Diese Mechanismen der Abschottung sind zukünftig bereits in der Hardware neuer ICs integriert. Damit ist garantiert, dass es nicht zu nachteiligem Laufzeitverhalten von virtualisierten Systemen kommt. Dass die Virtualisierung auf hohem Sicherheitsniveau funktioniert, lässt sich daran ablesen, dass es bereits zertifizierbare PikeOS-Hypervisor-Architekturen in der Luftfahrt (etwa im Airbus), der Bahn- und Medizintechnik gibt.

Anfragen von außen müssen natürlich ebenfalls durch die Firewall der Security Policy hindurch. Für die Android-Community eröffnet sich durch eine klar definierte Security Policy die Möglichkeit, gezielt Apps für das Auto zu entwickeln. Da die Security Policy ebenfalls aktualisiert werden kann, bietet die Virtualisierung auch hier Zukunftssicherheit. Zwar liegt es nahe, die Türen, die mit der Security Policy geöffnet werden, möglichst genau und schmal zu definieren, aber grundsätzlich kann sich das Auto so der Android-Welt öffnen.

Vorteile der höheren Integration

Bild 4: In einem ganzheitlichen HMI können Inhalte beispielsweise mittels Gestensteuerung von einem Anzeigeort an einen anderen verschoben werden.Continental

Eine Interior-ECU eröffnet zahlreiche Vorteile. Zu den naheliegenden gehört, dass bei einer Partitionierung innerhalb eines Systems höhere Bandbreiten verfügbar sind. So kann für große Datenvolumen ein Speicherbus anstelle von bis an die Grenze ihrer Leistungsfähigkeit ausgereizten Videoschnittstellen genutzt werden.

Ein weiterer Vorteil besteht in der flexiblen Zuordnung von Ressourcen. Während in einer dedizierten ECU bei steigendem Speicherbedarf eine Verdoppelung durch einen größeren Baustein erfolgen muss, lässt sich der insgesamt größere Speicher für eine Multicore-CPU fein granuliert als Ressource den einzelnen virtuellen Maschinen zuweisen.

Aus Sicht des OEM und Tier 1 ist es einfacher, ein ganzheitliches HMI mit einer Interior-ECU zu realisieren als mehrere Quellen zu koordinieren. Mit einer Interior-ECU besteht zum Beispiel größtmögliche Flexibilität in der Ansteuerung von Displays. Denkbare Konflikte wie die Frage, wo ein Bild gerendert wird, das situativ auf unterschiedlichen Displays benötigt wird, stellen sich hier nicht.

Auch bei der Zuteilung von Ressourcen und der Definition der virtuellen Maschinen besteht im Prinzip bis zuletzt Flexibilität, falls sich beispielsweise herausstellen sollte, dass eine zunächst gewählte Partitionierung der Kerne noch nicht die optimalen Ergebnisse bringt. Sogar der kurzfristige Übergang auf eine CPU mit einer anderen Anzahl von Rechenkernen ist ohne Neuprogrammierung möglich.

Grafik Know-how ist unerlässlich

Wie verschieden die Anforderungen der unterschiedlichen Software-Welten im Auto sind, zeigt sich gerade bei der Grafik deutlich. Hier prallen hohe Anforderungen an Schnelligkeit auf mächtige Grafiken. Um beide in einem Grafik-Stack abdecken zu können, ist ein tiefes automobilspezifisches Grafik Know-how nötig, denn es geht nicht um das Design einer Oberfläche, sondern darum, unterschiedliche Grafik-Stacks zusammen zu bringen. Kombi-Instrument-Anforderungen lassen sich daher nicht einfach mit einem High-End-Linux-System umsetzen. Um beispielsweise sehr kurze Startup-Zeiten und hohe Bildwiederholungsfrequenzen aus einem Grafiksystem  herauszuholen, muss man über eine spezifische Grafikkompetenz verfügen.

Virtualisierung gezielt nutzen

Bei allen Vorteilen der Virtualisierung wird es auch in Zukunft unterschiedliche Cockpit-Architekturen geben, denn die Hypervisor-Technologie eignet sich nicht für alle Fahrzeuge gleichermaßen. In Modellen mit High-End-Ausstattung beispielsweise werden die einzelnen Teildomänen die jeweilige Kapazität des ICs in ihrer ECU auslasten. In diesen Fällen werden somit weiterhin dedizierte ECUs gebraucht. Ähnliches gilt, wenn spezielle Chips in der ECU integriert sind, die keine Hypervisor-Technologie unterstützen. Ebenfalls ein Hindernis für eine Domänenintegration ist eine Skalierung von Fahrzeugausstattungen auf Basis von unterschiedlicher Hardware. Wenn dagegen eine Variantenvielfalt und Skalierung auf Softwarebasis erwünscht ist, eignet sich die Virtualisierung hervorragend, um diese Strategie zu realisieren. Virtualisierung schafft damit eine ideale Plattform für software-ausbaufähige Systeme. Bild 3 gibt einen vereinfachten Überblick über Kriterien, die für oder gegen eine Virtualisierung mit Hypervisor-Technologie sprechen.

Trotz der genannten Einschränkungen ist die Virtualiserung mittels Hypervisor eine Zukunftstechnologie für das Kombi-Instrument, das HUD und die Head-Unit (Bild 4). Durch die Möglichkeit, ausgereifte Systeme nahezu unverändert im Auto nutzen zu können, lässt sich gezielt Kundennutzen schaffen – und das auf einem Kostenniveau, das gerade in kompakten Modellen neue Möglichkeiten eröffnet. Anders gesagt: Virtualisierung erweitert das Spektrum dessen, was in einem bestimmten Kostenrahmen höher integriert werden kann, um neue Vorteile für den Autofahrer zu eröffnen.

(av)