Infotainmentsysteme im Connected-Car sicher machen

In der Vergangenheit waren Audiosysteme in Fahrzeugen eher einfach konstruiert: Sie zeichneten sich durch simple Funktionalität, einen einfachen Tuner und eine rudimentäre Bedienoberfläche aus. Die bidirektionalen Kommunikationskanäle waren – wenn überhaupt – nur sehr vereinfacht vorhanden. Bei den geschlossenen Systemen wurde die gesamte Software bereits vor dem Verkauf vom Hersteller aufgespielt und blieb in der Regel über die gesamte Lebensdauer des Gerätes hinweg unverändert. Dabei war das Volumen der integrierten Software sehr gering.

Bild 1: Durch Virtualisierung ist eine sichere Anbindung des Fahrzeugs an die Cloud möglich.Visteon

Heute verfügen die meisten In-Vehicle-Infotainmentsysteme (IVI-Systeme) über sehr ausgefeilte anspruchsvolle Bedienoberflächen mit Eingabetasten, möglicherweise einem berührungssensitiven Bildschirm (Touchscreen), einer Anbindung an Rückfahrkameras sowie Audio- und hochauflösende Videowiedergabefunktionen. Hinzu kommen viele weitere Sprach-, Gestik- oder Dateneingabefunktionen zur Kommunikation, Mediaplayer, Spiele sowie diverse andere Tools. Die Systeme unterstützen außerdem eine kabellose Kommunikation beispielsweise über Wi-Fi, Bluetooth oder Infrarot. Anwender können über die IVI-Systeme Daten hochladen und auf Anwendungen zugreifen. Das Gesamtvolumen der Software solcher Systeme beläuft sich auf einige Millionen Code-Zeilen (Lines of Code).

Infotainment im Fahrzeug

Die Kluft zwischen Unterhaltungs- und Automobilelektronik ist seit den frühen 2010ern zunehmend größer geworden. Ausschlaggebend dafür war die rasante Verbreitung von Smartphones, denn mit diesem Trend stiegen auch die Erwartungen der Verbraucher an die Funktionalitäten im Fahrzeug. Anwender möchten auch innerhalb des Fahrzeugs nahtlos mit der Außenwelt verbunden sein und die von Mobilgeräten vertrauten Funktionen nutzen können. Die Automobilindustrie reagierte zunächst zurückhaltend auf diese Forderungen und steht jetzt daher um so mehr im Zugzwang, die Lücke zu schließen, die zwischen den hohen Erwartungen der Verbraucher an Infotainmentfunktionen und den aktuellen Möglichkeiten moderner IVI-Elektronik klafft. Dabei stehen Fahrzeughersteller zwei wesentlichen Problemstellungen gegenüber: Einerseits sind IVI-Funktionen ohne Firmware-Updates im Vergleich zu Produkten der Unterhaltungselektronik schnell überholt. Andererseits gefährdet ein IVI-System als Gateway zum Bordnetz unter Umständen die Sicherheit der Elektronik im Fahrzeug, sodass eine Firewall zwischen Fahrzeugnetzwerk und Außenwelt nötig wird. Virtualisierung kann maßgeblich zur Lösung dieser Probleme beitragen.

Virtualisierungstechniken

Bild 2a: Bei Virtual Machines (VMs) läuft der Hypervisor auf dem Host-Betriebssystem.Visteon

Das Konzept der Virtualisierung hat seine Ursprünge im Bereich der Großrechner und kommt heute vor allem bei PCs zum Tragen. Erst seit Kurzem findet Virtualisierung zunehmend in Embedded-Systemen Anwendung. Dabei sind drei verschiedene Arten von Virtualisierungstechniken zu unterscheiden:

• Bei Virtual Machines (VMs, virtuelle Maschinen) läuft der Hypervisor auf dem Host-Betriebssystem und stellt somit eine zweite Softwareebene dar. Die Gastbetriebssysteme laufen folglich auf der dritten Softwareebene oberhalb der Hardware.
  

  Bild 2b: Bei der Paravirtualisierung/Bare-Metal-Virtualisierung sitzen Hypervisor direkt auf der Hardware. Visteon

• Bei der Paravirtualisierung/Bare-Metal-Virtualisierung sitzen Hypervisor direkt auf der Hardware. Zum einen abstrahieren beziehungsweise regulieren sie die Hardwarezugriffe, steuern zum anderen aber auch die Gastbetriebssysteme. Diese Virtualisierungstechnik ist in automobilen Embedded-Plattformen am weitesten verbreitet. Die Gastbetriebssysteme laufen auf einer Ebene oberhalb des Hypervisors. Ein Beispielprodukt für diese Art der Virtualisierung ist COQOS von Open-Synergy.
  

  Bild 2c: Bei der Container-Virtualisierung ermöglicht der Kernel des Host-Betriebssystems nicht nur eine, sondern mehrere parallele, voneinander isolierte Instanzen in der Benutzerumgebung. Visteon

• Bei der Container-Virtualisierung ermöglicht der Kernel des Host-Betriebssystems nicht nur eine, sondern mehrere parallele, voneinander isolierte Instanzen in der Benutzerumgebung. Hierfür wird kein vollständiges Gastbetriebssystem installiert, sondern lediglich für jede „Sandbox“ eine minimale Emulation der API und des Speichers des Host-Betriebssystems erzeugt.

Vorteile von Virtualisierung im Fahrzeug

Virtualisierung hat in punkto IVI-Design neue Türen geöffnet, denn mit ihrer Hilfe lässt sich die IVI-Architektur in kritische und nicht-kritische Partitionen aufteilen. Die kritische Partition beinhaltet die Bordnetzkommunikation sowie andere Software, die über ein Echtzeit- oder ein Thin-Client-Betriebssystem läuft. Funktionen der Benutzeroberfläche sind in der nicht-kritischen Partition hinterlegt, die auf einem leistungsstarken verbraucherbasierten Betriebssystem wie Linux oder Android läuft. Dieser Aufbau erlaubt die Aktualisierung der Firmware einer Partition, ohne die andere Partition zu stören. Davon profitieren Fahrzeughersteller, da sich somit Funktionen der Bedienoberfläche aktualisieren lassen, ohne die kritische Partition zu tangieren.

Ein Beispiel für die Umsetzung dieses Ansatzes sind die gemeinsamen Infotainmentlösungen von Visteon und Open-Synergy. Um die Integration von Unterhaltungselektronik in Fahrzeug-Infotainmentlösungen voranzutreiben, sind die beiden Unternehmen eine strategische Partnerschaft eingegangen. Ziel ist es, offene IVI-Anwendungen mit der geschlossenen Fahrzeug-Domain zu verbinden. In einem ersten Projekt integrierte Visteon das Betriebssystem COQOS von Open-Synergy in seine Infotainment-Plattform Open-Air I1.2. Damit ist die neuste Generation der Infotainmentprodukte des Automobilzulieferers mit Virtualisierungstechnologie ausgestattet. In der so entstehenden virtuellen Umgebung können mehrere Betriebssysteme in verschiedenen Partitionen auf demselben Prozessor laufen.

Bild 3: IVI-Funktionen sind ohne Firmware-Updates schnell überholt. Außerdem kann ein IVI-System als Gateway zum Bordnetz die Sicherheit der Elektronik im Fahrzeug gefährden. Virtualisierung kann maßgeblich zur Lösung dieser Probleme beitragen.Visteon

Da Anwendungen unabhängig voneinander in separaten Softwarepartitionen ablaufen, sind Fahrzeughersteller mit dieser Lösung in der Lage, Linux- oder Android-basierte Infotainmentfunktionen parallel zu Autosar-konformer Software zu integrieren. Die Applikationen beeinträchtigen sich also nicht gegenseitig. Eine entsprechende Boot-Technologie stellt die schnelle Verfügbarkeit wichtiger Fahrerinformationen sicher, während spezielle Softwaretreiber dafür sorgen, dass verschiedene Partitionen die Hardware wie Audio oder Video nutzen können.

In-Vehicle-Sicherheit per Virtualisierung

Virtualisierung kann außerdem wesentlich zur Verbesserung der In-Vehicle-Sicherheit beitragen, indem eine virtuelle Maschine ein Subsystem derart isoliert, dass sich ein Systemausfall nicht auf andere Subsysteme auswirkt. Beim In-Vehicle-Infotainment ist der CAN-Kommunikations-Stack von entscheidender Bedeutung für die Sicherheit des Systems. Bei einem erfolgreichen Angriff von außerhalb könnte das IVI-System andere kritische CAN-Knoten im Fahrzeugnetzwerk beeinträchtigen. Im Extremfall könnte es zu Störungen im Bordnetz kommen. Auch ein Verschlüsselungs-Subsystem muss vor potenziellen Bedrohungen gesichert sein, um sensible Nutzer- und Fahrzeuginformationen vor Hackerangriffen zu schützen.

Die sich daraus ergebenden Sicherheitsanforderungen an das IVI-System mit Millionen sicherheitskritischen Code-Zeilen sind somit enorm hoch. In offenen Systemen ist das Betriebssystem besonders leicht angreifbar und zudem so groß, dass es hunderte, wenn nicht sogar tausende von Bugs enthalten kann. Ohne Virtualisierung können Hacker, die sich erfolgreich Zugang zum Betriebssystem verschafft haben, jeden anderen Bereich des Systems angreifen.

Mithilfe von Virtualisierung ist das Gastbetriebssystem nicht in der Lage, die Daten anderer Subsysteme zu beeinträchtigen. Auch der Zugriff zum Prozessor ist wesentlich eingeschränkt. So ist sichergestellt, dass kritische Komponenten nicht durch Bugs oder andere Codes gefährdet werden.

Grenzen der Virtualisierung

Virtualisierung ist von Natur aus komplex und weist wie die meisten technologiebasierten Plattformen gewisse Einschränkungen und potenzielle Probleme auf. Insbesondere die Aspekte Softwarekomplexität, Integration, Sicherheitsrichtlinien und „Trusted Computing Base“ stellen bislang Grenzen der Virtualisierung dar.

Software-Komplexität

Durch die Isolation, die mit Virtualisierung möglich ist, entstehen komplette virtuelle Maschinen für jedes Subsystem. Das bedeutet, dass jede dieser virtuellen Maschinen ihr eigenes Betriebssystem verwenden muss. Allerdings steigt mit jeder virtuellen Maschine der Software-Umfang, sodass sowohl der Speicherplatzbedarf als auch die Anzahl möglicher Fehlerquellen zunimmt. In Folge steigt die Wahrscheinlichkeit ernsthafter Leistungseinbußen.

Bild 4: Virtualisierung hat in punkto In-Vehicle-Infotainmentdesign neue Türen geöffnet. Mit ihrer Hilfe lässt sich die IVI-Architektur in kritische und nicht-kritische Partitionen aufteilen.Visteon

Integration

Die Subsysteme eines Embedded-Systems arbeiten nicht unabhängig voneinander. Vielmehr gilt genau das Gegenteil, denn sie müssen so entwickelt sein, dass sie möglichst eng zusammenarbeiten, um die gewünschte Funktionalität des Systems zu erreichen. Dies widerspricht in gewisser Hinsicht dem Grundgedanken der Virtualisierung. Notwendige Kanäle zur Kommunikation beziehungsweise zum Datenaustausch zwischen verschiedenen Subsystemen stellen potenzielle Gefahrenquellen für das Gesamtsystem dar.

Sicherheitsrichtlinien und Trusted Computing Base

Viele Embedded-Systeme müssen kritische Sicherheitsanforderungen erfüllen. Virtualisierung alleine ist jedoch nicht unbedingt in der Lage, all diesen Sicherheitsanforderungen nachzukommen.

Virtualisierung unterstützt nicht die Minimierung der sogenannten „Trusted Computing Base“ (TCB), also sämtlicher sicherheitskritischen Hardware-, Firmware- und Softwarekomponenten. Oft hat die TCB hohe Leistungsanforderungen und muss deshalb in der Lage sein, effizient mit dem Rest des Systems zu kommunizieren. Virtualisierung unterstützt hierbei nicht.

Fazit

Paravirtualisierung wird gemeinhin als beste Embedded-Option betrachtet. Ein paravirtualisierter Thin-Client-Hypervisor kann auch weiterhin Grundlage für Embedded-IVI-Systeme sein. Dazu übernimmt er das Ressourcen-Management bezüglich Speicher, Geräten, Energieversorgung sowie des gesamten Schedulings und ermöglicht eine sichere Kommunikation sowie die Ressourcenteilung zwischen den Gastbetriebssystemen.

Andererseits verfügen auch einige Prozessorkerne über einen Hypervisor-Modus, der eine hardwaregestützte Virtualisierung ermöglicht. Paravirtualisierungsanbieter verfolgen diese Strategie und erweitern den Hypervisor-Modus entsprechend, um Optionen wie hardwaregestützte Virtualisierung und 40-Bit-Adressierung zu integrieren. Mit hardwaregestützter Virtualisierung lässt sich der Wartungsaufwand der Paravirtualisierung reduzieren, was wiederum die im Gastbetriebssystem benötigten Anpassungen senkt. Diese Art Virtualisierungsarchitektur ist die Grundlage für die Entwicklung modernster Software für die vernetzten Fahrzeuge der Zukunft.

(av)