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 ¨C 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 ¨C von verteilten ¨¹ber Dom?nen- bis hin zu Zonenarchitekturen ¨C 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 ¨C 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?
