Welche Auswirkungen hat „Software-defined Vehicle (SWdV)“ auf das Bordnetz?

Von der Domänen- zur Zonenarchitektur – das Software-defined Vehicle (SWdV) und die Anforderungen an die Datenleitungen der Zukunft

Beim Lesen von automobilen Fachartikeln kommt man aktuell um zwei Begriffe nicht herum. Zum einen liest man immer wieder von der sogenannten „Zonenarchitektur“ und in diesem Zusammenhang auch gerne vom „Software-defined Vehicle (SWdV)“.

Was hat es nun mit diesen Begriffen auf sich? Wie wirken sie sich auf zukünftige Fahrzeug-Generationen aus? Genau diesen Fragen gehen wir in diesem Blogartikel nach.

Ein Blick in die Vergangenheit: Komplexe Verdrahtung und hohes Gewicht

Was hat es nun mit den Begriffen „Zonenarchitektur“ und „Software-defined Vehicle (SWdV)“ auf sich? Wie wirken sie sich auf zukünftige Fahrzeug-Generationen aus? Um die Fragen beantworten zu können, machen wir einen kleinen Ausflug in die Vergangenheit. Die erste Form der Bordnetz-Topologie wurde als „verteilte“ oder „modulare Architektur“ bezeichnet. Dabei wurden alle Sensoren und Aktoren einzeln und auf direktem Wege mit einem Steuergerät verbunden. Jeder Sensor oder Aktor besaß die für die Funktion nötige Intelligenz und es wurden nur Steuersignale und bereits aufbereitete Messsignale über Leitungen und Bussysteme (typ. Lin- oder Can-Bus) an die Steuergeräte transferiert. In jedem Fahrzeug wurden mehrere hundert Sensoren und bis zu hundert Steuergeräte verbaut. Einzelne Leitungen erreichten eine Länge von bis zu 16,5 m. Dadurch war es keine Seltenheit, dass die gesamte Leitungslänge im Fahrzeug schnell die Kilometergrenze überschritt. Eine sehr komplexe Verdrahtung und ein hohes Gewicht des Kabelbaumes waren die Folge.

Modulare Architektur

Jedes der Steuergeräte musste mit einer, ausschließlich für die Funktionalität spezifischen, Software (Firmware) programmiert werden. Ein Firmware Update konnte in der Regel nur direkt am Gerät mit einem speziellen Programmierkabel durchgeführt werden. Das machte den Besuch einer Fachwerkstatt zwingend erforderlich und Updates wurden nur in den seltensten Fällen durchgeführt.

Das nachträgliche Erweitern der Fahrzeugfunktionen durch zusätzliche Features gestaltete sich als sehr schwierig bis undurchführbar. Für jede Funktion musste zumindest eine zusätzliche Leitung quer durch das Fahrzeug zur Anbindung an ein Steuergerät verlegt werden. Oft war auch noch ein Firmware Update am Steuergerät notwendig, um die neue Funktion zu unterstützen. Hier überstieg der Aufwand dann schnell den gewollten Nutzen.

Mit steigender Anzahl der Fahrzeugfunktionen, unter anderem im Bereich Sicherheit und Komfort, kam man dann rasch an die Grenzen dieser Verdrahtungsform.

Das war die Geburtsstunde der „Domänen Architektur“.

Aktueller Stand der Technik: Die Domänen Architektur

Im Unterschied zur „modularen Architektur“ verfolgt man bei der Domänen Architektur den Ansatz, die Sensoren und Aktoren nach ihren Funktionen und Aufgaben zu gliedern (Domäne).
Es wurden verschiedene funktionale Domänen wie etwa Antrieb, Komfort, oder Infotainment definiert. Jede davon wird mit einem übergeordneten Steuergerät, dem Domänen-Controller (DCU: Domain Control Unit) überwacht und gesteuert. Die Verbindung zum Sensor / Aktor kann mit einer nieder performanten Busverbindung(z. B. Lin- oder Can-Bus) realisiert werden.
Die DCUs selbst sind mit einem leistungsstarken und service-orientierten Netzwerk, dem sogenannten Gateway (z. B. Ethernet), verbunden.
Das Nachrüsten einer zusätzlichen Domäne, beziehungsweise einer DCU mit einer neuen Funktion, wie z.B. ADAS (Advanced Driver Assist System) ist somit jederzeit problemlos möglich

Domänen Architektur

Der Nachteil dieser Technologie zeigt sich aber schnell, wenn Funktionen einer Domäne physikalisch nicht am gleichen Ort im Fahrzeug verbaut werden können.
Die Folge sind wiederum lange Leitungen von der DCU zum Sensor oder Aktor.
Als einfaches Beispiel kann man hier die Funktion „Blinker“ heranziehen: Es sind mindestens 6 Blinkerleuchten an verschiedensten Ecken im Fahrzeug zu verdrahten, die aber alle von einer DCU angesteuert werden. Diese Art der Fahrzeug-Topologie ist aktuell noch Stand der Technik!

Die automobile Welt befindet sich aber aktuell in einem extremen Wandel.
Neben dem Ersetzen von Verbrennungsmotoren durch alternative Antriebe beschäftigt der Megatrend „Autonomes Fahren“ die gesamte Branche, was neue Konzepte für das Bordnetz von morgen erfordert.

Das Bordnetz der Zukunft: Zonenarchitektur und Software-defined Vehicle

Sicherlich hat die Domänen-Architektur einige Vorteile. Um die Komplexität moderner Fahrzeuge bewältigen und die zukünftigen Anforderungen abdecken zu können, ist jedoch ein anderer Ansatz nötig: die Zonenarchitektur.

Bei einem zonalen Ansatz (Zonenarchitektur) werden die Funktionen, anders als bei einer domänenorientierten Lösung, nach ihrer Position im Fahrzeug und nicht nach ihrer Aufgabe angeordnet.
In einem einfachen Fahrzeug gibt es vielleicht nur vier Zonen, eine pro Fahrzeugecke. Alle Geräte in einer physikalischen Zone werden von einer zonalen Steuerung, oder auch Zonal Gateway bzw. ECUs (Electronic Control Unit), gesteuert. Diese zonalen Steuerungen wiederum sind mit einer zentralen Recheneinheit über einen Backbone-Link (Highspeed Datenverbindung) verbunden.

Alle Aufgaben in einem physikalischen Bereich, deren Überwachung durch ein zonales Steuergerät erfolgt, sind dieser Zone zugeordnet. So lassen sich Beleuchtung, Bildsensoren, Blinker, Bremsen, Lenkung, Aufhängung, etc. zu einer gemeinsamen Zone zusammenfassen.

Zonale Architektur

Neben der Vereinfachung der Verdrahtung, spielen Modularität und Flexibilität eine sehr große Rolle, damit die Vorteile dieser Lösung voll ausgespielt werden können.

Modularität bedeutet hier, dass unterschiedliche Aufgaben mit ein- und derselben Hardware (z. B. identische ECUs) realisiert werden können.

Flexibilität ist die Fähigkeit, Updates, Bugfixes, Konfigurationen, aber auch Erweiterungen, ohne großem Aufwand für den Fahrer durchführen zu können. Mit der sogenannten „Over the Air“ Funktion ist es möglich, diese Aktionen mit einer Verbindung zum Internet durchzuführen, ohne eine Werkstatt aufsuchen zu müssen. Das Fahrzeug überprüft, ob Updates vorhanden sind und lädt bzw. installiert die Software auf seinen ECUs komplett eigenständig. Optionen und Erweiterungen können ähnlich dem Prinzip von App-Stores der bekannten Betriebssystem-Anbieter für mobile Endgeräte, vom Fahrzeughalter gekauft und installiert werden.

Um diese Modularität und Flexibilität auch in der Praxis zu erreichen, ist es erforderlich, solche Funktionen anstatt mit Hardware, künftig in Software abzubilden. Auch hier dient das Modell des modernen Smartphones als Beispiel, in dem Apps die unterschiedlichsten Aufgaben und Anwendungen für den User ermöglichen. Man kann mit seinem Smartphone neben telefonieren auch fotografieren oder navigieren. Wer möchte kann sogar seine Bankgeschäfte erledigen oder sich in sozialen Medien informieren.

Dieser Ansatz wird im Auto als „Software-defined Vehicle“ bezeichnet.
Quasi alle Funktionen im Fahrzeug werden nun nicht mehr über eine Hardware basierende Steuerungen realisiert, sondern ein Programm (App) löst die Aufgaben auf einem universellen Steuerrechner (Zonencontroller). Der Vorteil ist, dass viele Apps gleichzeitig laufen (Multitasking) und somit alle Funktionen einer Zone auf nur einem Zonencontroller realisiert werden können. Das erfordert natürlich sehr hohe Rechenleistungen, aber auch eine große Anzahl an Schnittstellen zu den Sensoren / Aktoren, die im Zonencontroller verbaut sein müssen.

Die Aufgabe dieser Zonencontroller besteht weiters darin mit der zentralen Recheneinheit zu kommunizieren. Dafür werden jene Daten, die an diese Zentrale gesandt werden, vorher vom Zonencontroller vorgefiltert und priorisiert. Die Systemkomplexität wird dadurch drastisch reduziert und die zentrale Recheneinheit kann auf die Verarbeitung relevanter Daten fokussiert werden (z. B.: ADAS-Funktionen, Bilddaten auswerten, usw.).

Datenverbindungen zwischen den Zonencontrollern und der zentralen Recheneinheit erfordern eine zuverlässige und schnelle Kommunikation. Automotive Ethernet Lösungen (z.B. MultiGiG) sind hier das Mittel zum Zweck.

Diese Verbindung wird als Backbone bezeichnet.

Kommunikation Zonal Gateway – Zentraler Rechner

Der Ansatz „Software-defined Vehicle“ führt bei den OEMs zwangsläufig zu einem starken Paradigmenwechsel. Waren die Fahrzeughersteller doch bisher die Know-How Träger über die verbaute Technik (Hardware) im Fahrzeug, so verlagern sich nun die Funktionen, wie auch die Wertschöpfung fast komplett von der Hardware zur Software.

Nicht mehr das Fahrzeug selbst, viel mehr die Funktion steht im Mittelpunkt und wird individuell an die Kundenwünsche angepasst. Software-Entwicklung ist aber bisher nicht wirklich eine Kernkompetenz der OEMs. Deswegen kann man hier bereits unterschiedliche Trends feststellen.
Während einige Firmen, oft jüngere Unternehmen, eher den Weg in Richtung Software- Dienstleister oder auch komplette Systeme, z. B. Android aus dem Hause Google, einschlagen, wird bei  „klassischen“ OEMs eher versucht das Know-How im Haus zu behalten und man investiert in den Aufbau einer eigenen Software-Abteilung. Es bleibt auf alle Fälle spannend, welcher dieser Wege sich auf Dauer durchsetzen wird.

Ebenso interessant ist, dass hier völlig neue Geschäftsmodelle entstehen.

Die Funktion selbst ist nicht mehr an das Fahrzeug geknüpft. Gebrauchtwagenhändler oder auch Kunden können relativ einfach neue Funktionen nachrüsten und so einen Mehrwert für das Fahrzeuges schaffen. Der Wert des Autos bleibt so über den Lebenszyklus erhalten oder könnte sogar gesteigert werden.

Auch eine zeitlich begrenzte Nutzung von Funktionen oder eine Abo-Lösung kann nun angeboten werden.

Ein weiterer Pluspunkt ist, dass das Fahrzeug mit seiner Umgebung kommunizieren kann. Es kann im Betrieb Daten sammeln und diese z. B. in einer Cloud speichern. Dieser Datenaustausch ermöglicht eine kontinuierliche Verbesserung der Funktionen und Services, die anschließend on-the-fly wieder im Fahrzeug aktualisiert werden können. Auch eine direkte Kommunikation mehrerer Fahrzeuge untereinander ist technisch denkbar. All diese Möglichkeiten sind ein weiterer, wichtiger Meilenstein auf dem Weg zum autonomen Fahren.

Ausblick: Enorme Ansprüche an Rechenleistung und Datenleitungen

Es wird sicher noch einige Zeit in Anspruch nehmen, bis die Bordnetzarchitektur auf Zonen umgestellt sein wird. Herausforderungen wie die notwendigen Rechenleistungen und Datenleitungen für 25 Gbit/s oder mehr gilt es noch zu lösen. Schätzungen zu Folge könnte es aber bis 2030 soweit sein. Weltweit arbeiten Techniker bereits intensiv an Lösungen.

MD ELEKTRONIK ist hier mit seinem Produkt Portfolio ein sehr starker und kompetenter Partner, dessen Fokus exakt auf diesen Anforderungen liegt.
Wir bieten die richtige Lösung für Koax, UTP- und STP- _(*), sowie USB-Produkte, als auch für optische Datenübertragung. Dank der hochautomatisierten Produktionsstrategie erfüllen unsere Produkte die höchsten Qualitätsansprüche. 

Zusammenfassung

Die automobile Welt ist stark im Wandel. Nicht nur der Wechsel auf Elektroantriebe stellt die Automobilhersteller vor große Herausforderungen. Ebenso gilt es, Lösungen für die Idee vom „Smartphone auf vier Rädern“ zu präsentieren.

Ein wichtiger Ansatz ist hierbei, die Effektivität des Bordnetzes zu erhöhen, indem die hohe Anzahl der einzelnen „Punkt zu Punkt“ Leitungen durch wenige performante Netzwerkleitungen (wie MultiGiG Ethernet) abgelöst werden. Dies bringt einerseits den Vorteil einer hohen Gewichtsreduzierung mit sich. Gleichzeitig bedeutet dies jedoch auch eine enorme Challenge für die ECU Hersteller, da viele Funktionen, die bisher in einzelnen Sensoren oder Aktoren selbst realisiert waren, nun als Software-Lösung in die ECU integriert werden. Diese beiden Ansätze werden als „Zonenarchitektur“ beziehungsweise „Software Defined Car“ beschrieben.

Fazit

Die Anforderungen in Puncto Rechenleistung und Datenübertragung sind sehr hoch und es gibt noch viel Luft nach oben. Die Datenleitungen der Zukunft müssen für zuverlässige Übertragungen im Bereich bis 25 Gbit/s oder schneller ausgelegt werden. Hier bieten sich optische Datenleitungen als gute Alternative zu kupferbasierenden Leitungen immer häufiger an.

(*)
UTP – Unshielded Twisted Pair
STP – Shielded Twisted Pair