Das Auto wird zu einem Rechenzentrum auf Rädern

Dies ist der erste Teil einer zweiteiligen Serie über die Entwicklung von Fahrzeugnetzwerken

Von:Yuichi Motohashi, stellvertretender Leiter des Bereichs Endmärkte

Die Automobilindustrie wird durch das „Software-Defined Vehicle“ (SDV) neu gestaltet – ein Fahrzeug, dessen Funktionen und Wert durch Software definiert und auch nach dem Kauf durch Over-the-Air-Updates (OTA) kontinuierlich erweitert werden, ähnlich wie ein Smartphone nach dem Kauf neue Funktionen erhält. Die Bereitstellung dieser Updates erfordert ein Umdenken hinsichtlich der elektrischen/elektronischen (E/E-)Architektur im Fahrzeug, bei der die Rechenleistung auf eine kleine Anzahl leistungsstarker Plattformen konsolidiert werden muss, damit Hardware und Software unabhängig voneinander entwickelt und weiterentwickelt werden können.

Die herkömmliche verteilte Architektur umfasst zwischen einigen Dutzend und mehr als hundert funktionsspezifischen Steuergeräten (ECUs), auf denen jeweils die Software unterschiedlicher Anbieter läuft, was einheitliche, fahrzeugweite Updates erschwert. Ein weiterer wichtiger Faktor ist die Sensorfusion. Mit der Weiterentwicklung von ADAS und autonomem Fahren übertragen Kameras, Radar, LiDAR und Ultraschallsensoren zunehmend Rohdaten oder leicht verarbeitete Daten an eine zentrale Plattform zur integrierten Verarbeitung, anstatt jeweils nur ihre eigenen lokalen Entscheidungen zu melden. Beide Trends erfordern mehr Bandbreite und eine stärker zentralisierte Rechenleistung, wodurch das moderne Auto zu einem „Rechenzentrum auf Rädern“ wird. Diese zweiteilige Serie zeichnet diese Entwicklung nach – von verteilten über Domänen- bis hin zu Zonenarchitekturen – und verfolgt dabei die Veränderungen bei Sensoren, Datenformaten, SoCs und Netzwerken, während sie gleichzeitig aufzeigt, wie SerDes und Ethernet eingesetzt werden und schließlich zusammenwachsen.

Verteilte E/E: Ein Dschungel aus Steuergeräten

In der ersten Generation waren die Steuergeräte nach Funktionen aufgeteilt und arbeiteten weitgehend unabhängig voneinander. Bei den Sensoren handelte es sich in der Regel um „intelligente Sensoren“, die sich am selben Ort wie ihre Auswertungsstelle befanden, sodass über das Netzwerk nur verarbeitete Informationen mit geringer Bandbreite übertragen wurden, wie beispielsweise Ergebnisse der Objekterkennung, Entfernungs- und Geschwindigkeitsdaten sowie Warnmeldungen. Neben CAN, LIN und FlexRay reichte Automotive-Ethernet der 100-Mbps-Klasse (100BASE-T1, IEEE 802.3bw) aus, um viele Anwendungen zu unterstützen. Da jedoch Funktionen und Steuergeräte eng miteinander gekoppelt waren, führte jede neue Funktion zu zusätzlichen Steuergeräten, Kabelbäumen und Softwarevarianten, was die Integration, Aktualisierung und Verifizierung des gesamten Fahrzeugs zunehmend erschwerte. Dies war die wesentliche Einschränkung des dezentralen Ansatzes.

Bereich E/E: Konsolidierung nach Funktionen

Um diese Komplexität einzudämmen, fasst die Domänenarchitektur Funktionen zu großen Bereichen zusammen, darunter ADAS/AD, Infotainment, Karosserie, Fahrwerk und Antriebsstrang. Jede dieser Funktionen wird von einer Domain Control Unit (DCU) auf einem leistungsstärkeren SoC verwaltet, wobei ein zentrales Gateway die Daten zwischen den Domänen weiterleitet. Diese Komplexität hat sich mit dem Aufkommen fortschrittlicher ADAS-Systeme noch verstärkt. Surround-View, die Erzeugung von Vogelperspektiven, Einparkhilfen und Sensorfusion erfordern es, die Fahrzeugumgebung als ein einziges integriertes Umgebungsmodell zu behandeln und nicht als isolierte Sensorausgaben.

Die Rolle der Sensoren hat sich entsprechend verändert. Da die Erkennung nun in die DCU verlagert wurde, sind Kameras, LiDAR und Radar zu „Satellitensensoren“ geworden, die RAW-Daten oder leicht verarbeitete Datenströme ausgeben. Die Bedeutung von „Rohdaten oder leicht verarbeitete Daten“ unterscheidet sich je nach Sensor: Kameradaten können Bild-Rohdaten oder Videodaten im Bereich des Bildsignalprozessors (ISP) sein, LiDAR kann Punktwolken oder Entfernungs-/Intensitätsdaten ausgeben und Radar kann von Daten auf ADC-Ebene bis hin zu Entfernungs-/Doppler- oder Erkennungspunkten reichen. Um diese Datenströme mit hoher Bandbreite und geringer Latenz zu übertragen, reichten CAN und 100-Mbps-Ethernet nicht mehr aus. SerDes, das sich bereits in Kamera- und Display-Verbindungen bewährt hat, wurde zur schnellen Punkt-zu-Punkt-Verbindung mit geringer Latenz vom Sensor zur DCU. Im E/E-Bereich erfolgt die Konsolidierung jedoch nach wie vor eher nach Funktionen als nach physischem Standort, sodass weiterhin lange Kabel von vorne, hinten, links und rechts zu entfernten DCUs verlaufen, was die Branche in Richtung „Zonal“ treibt.

Zonales E/E: Nach Standort bündeln, im Zentrum denken

Zonal E/E wird oft als die vollendete Form nach „Domain“ bezeichnet, in der Praxis handelt es sich jedoch um einen fortlaufenden, schrittweisen Übergang. Anstatt nach Funktionen zu bündeln, werden die Ein- und Ausgänge nach ihrem physischen Standort gebündelt – entweder vorne, hinten, links/rechts oder in der Mitte. Ein Zonen-Controller in jeder Zone erfasst die nahegelegenen Sensoren, Aktoren und Low-Speed-Ein- und Ausgänge und leitet die erforderlichen Daten an einen zentralen Fahrzeug-Controller oder Zentralcomputer weiter.

Während der Übergangsphase dominiert ein hybrides Zonenkonzept. Lokale, langsame E/A-Anwendungen wie Beleuchtung, Türen, Sitze und HLK werden im nächstgelegenen Zonen-Controller gebündelt, wo Multidrop-10BASE-T1S (IEEE 802.3cg) neben CAN/LIN den Anforderungen am Zonenrand gerecht wird. Sensoren mit hoher Bandbreite wie Kameras, LiDAR und hochauflösende Radarsysteme werden häufig über SerDes direkt an den Zentralcomputer angeschlossen, wodurch die Belastung durch Bandbreite, „ power “ und Komplexität vermieden wird, die bei der Weiterleitung umfangreicher Datenströme über einen Zonen-Controller entsteht. Der größte Vorteil liegt in der Reduzierung des Kabelbaums. Kurze Verbindungen zu einem nahegelegenen Zonen-Controller in Kombination mit einem Hochgeschwindigkeits-Backbone zum Zentrum verringern die Gesamtkabellänge, die Anzahl der Steckverbinder und das Gewicht und reduzieren gleichzeitig die Anzahl der Bauteile, den Montageaufwand und die Fehlerquellen. Dies ist besonders bei Elektrofahrzeugen von Bedeutung, bei denen das Gewicht die Reichweite beeinflusst.

Dies wirft eine übergeordnete Frage auf: Warum sollte man Ethernet für dieses Backbone wählen? Weil der Abschnitt, der mehrere Zonensteuerungen, den Zentralrechner, Gateways sowie Diagnose- und Aktualisierungsfunktionen miteinander verbindet, ein echtes Netzwerk ist und keine einfache Punkt-zu-Punkt-Verbindung. Ethernet bietet ausgereifte TCP/IP-Funktionen, Switching, Adressierung, Diagnose, Sicherheit und Netzwerkmanagement, während Time-Sensitive Networking (TSN) und Zeitsynchronisation für Echtzeit-Determinismus sorgen. Es passt zudem nahtlos zu SDVs, da es die Hardware-Platzierung von der Software-Funktion trennt. Damit bleibt eine Frage für Teil 2 offen: Wie lassen sich die asymmetrischen Sensorverbindungen mit hoher Bandbreite, die in den Bereich von SerDes fallen, mit diesem Ethernet/IP-Backbone kombinieren?