Neue Möglichkeiten Effiziente Ethernet-Anbindung von Automotive-Server-ECUs

Automotive Ethernet lässt sich in unterschiedlichen virtuelle Maschinen anbinden und ist in der Autobranche wichtig für Effizienz und Performance.
Automotive Ethernet lässt sich in unterschiedlichen virtuelle Maschinen anbinden und ist in der Autobranche wichtig für Effizienz und Performance.

Automatisierung, Vernetzung und Digitalisierung des Fahrzeugs werden die künftige Mobilität verändern. Wichtig hierfür: ein leistungsstarkes Fahrzeugnetzwerk wie Automotive Ethernet. Dieser Artikel beschreibt, wie sich Automotive Ethernet an unterschiedliche virtuelle Maschinen anbinden lässt.

Automotive Ethernet hat sich mittlerweile als fahrzeuginternes Netzwerk für den Automobilbereich etabliert. Grund dafür ist vor allem die massiv gestiegene Datenmenge, die im Fahrzeug übertragen werden muss, und die Weiterentwicklung der Kommunikationsart von signalbasierter Kommunikation auf eine Service-orientierte Kommunikation, wie sie in der IT-Welt schon seit Jahren Standard ist. In der Vergangenheit hat vor allem CAN die fahrzeuginterne Kommunikation dominiert. Mit Automotive Ethernet bieten sich für die Fahrzeugentwicklung ganz neue Möglichkeiten.

Automotive Ethernet in der Evolution der E/E-Netzwerkarchitektur

Während bisherige E/E-Netzwerkarchitekturen einzelne Applikationsdomänen zusammengefasst haben (Bild 1), bietet eine auf Automotive Ethernet aufbauende, flächendeckende Netzwerk-Infrastruktur im Fahrzeug die Möglichkeit, über diese Grenzen hinweg Sensoren und Aktoren zu teilen und Applikationen zu zentralisieren. Durch die laufende Zunahme des Funktionsumfangs im Fahrzeug wachsen jedoch auch Anzahl und Komplexität der Steuergeräte (Electronic Control Units, ECUs). Abhilfe bietet hier die Zentralisierung von Funktionen durch die Einführung von Server-ECUs, die viele Anwendungen auf Performance CPUs ausführen können.

Server-ECUs, die oft auch als High-Performance-Controller (HPC) bezeichnet werden, bestehen typischerweise aus einem System on Chip (SoC) mit Performance CPUs und integrierten oder separat angeschlossenen Safety-CPUs. Zur weiteren Flexibilisierung und Skalierbarkeit lässt sich dieses Konzept in Zukunft mit dezentralen »Zone-ECUs« ergänzen. Diese sogenannten Zone-ECUs verbinden alle Sensor-/Aktuator-ECUs eines Fahrzeugbereichs und binden diese Zone über einen Automotive-Ethernet-Backbone effizient an die Server-ECUs an. Um Funktionen mit unterschiedlicher Kritikalität, von unterschiedlichen Herstellern oder unter verschiedenen Betriebssystemen parallel auf einer ECU ausführen zu können, muss diese Umgebung ähnlich wie in der IT-Welt virtualisiert werden.

Virtualisierung und Anforderungen an die Kommunikation

In traditionellen Designs werden einzelne ECUs mit jeweils einer eigenen, physikalischen Ethernet-Schnittstelle an das Automotive Ethernet-Netzwerk angebunden (Bild 2).

Die unterschiedlichen Steuergeräte lassen sich nun in einem weiteren Schritt zusammenführen, beispielsweise auf eine Server-ECU. Dazu wird die ECU-Software in virtuellen Maschinen (VMs) ausgeführt, die über einen Hypervisor mit Time-and-Space-Partitioning voneinander getrennt werden (Bild 3).

Wie die Anbindung dieser VMs an das Automotive-Ethernet-Netzwerk erfolgt, bleibt hier offen. Grundsätzlich bestehen folgende Anforderungen an die Kommunikation:
Die virtuellen Maschinen (VMs) müssen miteinander und mit anderen ECUs über das Netzwerk transparent kommunizieren können.

  • Die Implementierung muss den spezifischen Anforderungen an Embedded Systems im Hinblick auf Performance und Ressourcenbedarf entsprechen.
  • Die Anbindung der VMs muss Quality-of-Service-Anforderungen (QoS) erfüllen.
  • Das System muss Uhrensynchronisation zwischen den unterschiedlichen VMs und dem Ethernet-Netzwerk bieten.
  • Die Kommunikationsschnittstelle darf weder ein Übersprechen von Fehlern zwischen den VMs bewirken noch selbst so ein Fehlverhalten in den VMs verursachen – Freedom From Interference (FFI) nach ISO 26262 muss gewährleistet sein.
  • Security-Anforderungen (Confidentiality, Integrity, Availability) müssen erfüllt werden.

Auf Basis dieser Anforderungen lassen sich nun die Aspekte unterschiedlicher Hardware-Ausführungen des in Bild 3 angedeuteten EthX-Interfaces diskutieren.