Welche Rolle E/E-Architekturen beim Elektroauto der Zukunft spielen – Acht Fragen an Carsten Hoff von dSpace

Sie werden als „Nervenbahnen des Autos“ bezeichnet – die unzähligen Datenleitungen in modernen Autos, die in kilometerlangen Kabelbäumen Sensoren, Motoren und Steuergeräte miteinander verbinden. Die ganzen Systeme müssen nicht nur perfekt miteinander harmonieren, sondern kommunizieren teilweise noch über das Internet nach außen. Ein hochkomplexes System, von dem die Autokäufer in der Regel möglichst wenig mitbekommen – wenn Hersteller und Zulieferer ihre E/E-Architektur im Griff haben.

Kein Wunder also, dass E/E-Architekturen für die OEM und ihre beteiligten Partner zu einem enorm wichtigen Thema geworden sind – und Milliardenbeträge investiert werden. Denn die Absatztrends zeigen, dass vielen Kunden –vor allem auf dem chinesischen Markt – Software-Themen und Connectivity-Dienste wichtiger sind als technische Details am Antrieb ihres (künftigen) Autos. Kaufentscheidungen fallen heute mitunter anhand der Zyklen der Software-Updates oder wie gut das Auto sich in das eigene, digitale Ökosystem einfügt. Und nicht nach der Batteriechemie, der Bauart der Elektromotoren oder gar der Anzahl an Zylindern.

Doch wie spielt das alles zusammen? Wohin gehen die Trends, wo liegen Chancen und Risiken? Im Interview mit electrive steht Carsten Hoff, CEO der dSpace-Gruppe und Tagungsleiter bei der Fachtagung EEHE („electrical + electronic systems in hybrid and electric vehicles“) am 14. und 15. Mai in Bamberg, Rede und Antwort.

Herr Hoff, E/E-Architekturen sind den meisten Autokäufern vermutlich nicht geläufig, Software-Updates „Over-the-air“ hingegen schon. Wie muss ein OEM seine E/E-Architektur vorbereiten, um bestmöglich für OTA-Updates gerüstet zu sein?


OTA-Updates erfordern einen holistischen Ansatz, da sie nicht nur spezielle E/E-Architekturen im Fahrzeug erfordern, sondern auch erhebliche Auswirkungen für den OEM und seine Entwicklungsprozesse mitbringen.

Die E/E-Architektur des Fahrzeugs muss so gestaltet sein, dass sie auch noch in etlichen Jahren in der Lage ist, zukünftige Software zu erhalten, zu verifizieren, auf ein oder mehrere Steuergeräte zu verteilen und letztlich auch auszuführen. Hierzu sind modulare Hard- und Softwarearchitekturen notwendig. Typischerweise kommunizieren diese service-basiert über Ethernet, sodass die Kommunikation der Steuergeräte untereinander flexibel ist.

Die Auswirkungen auf den OEM sind ebenso umfangreich. Neben der offensichtlich notwendigen Backend-Verbindung sind die entwicklungstechnischen Änderungen tiefgreifender. Anstatt ein Fahrzeug fertig auszuliefern, wird ein Fahrzeug in Zukunft über Jahre weiterentwickelt werden. Dieses erfordert ein durchgängige Daten- und Versionsmanagement und die Möglichkeit diese unterschiedlichen Softwareversionen zu testen und zu homologieren. Eine Lösung zur Beherrschung dieser Komplexität ist die virtuelle Verifikation anhand eines sogenannten Digital-Loop.

Kurz gesagt: OTA-Fähigkeit muss ein Grundprinzip der gesamten Architektur und des Entwicklungsprozesses sein, nicht nur ein nachträgliches Add-on.

Ist die E/E-Architektur eines Fahrzeugs vor allem für Connectivity-Themen relevant? Oder welche Rolle spielen dabei elektrische Antriebe und das autonome Fahren?

Connectivity ist ein wichtiger Treiber, aber bei weitem nicht der Einzige. Insbesondere das autonome Fahren hat Auswirkungen auf die E/E Architektur, da hier enorme Datenmengen erzeugt und verarbeitet werden müssen. Diese Themen beeinflussen jedoch nicht so sehr die Kommunikation zwischen den Steuergeräten, sondern mehr die betroffenen Steuergeräte. 

Für die Steuergeräte der autonomen Fahrfunktionen bedeutet das zum Beispiel Redundanzkonzepte und hohe funktionale Sicherheitsanforderung in Kombination mit hohen Bandbreiten und Echtzeitanforderungen.

Connectivity Steuergeräte verfügen über flexiblere und andere Schnittstellen. Typischerweise sind hier die schnellere Update-Zyklen vorhanden und mit hohen Security-Anforderungen verknüpft. 

Wie sehen Sie die deutschen Hersteller in diesem Bereich aufgestellt? BMW hat mit seiner neuen Klasse eine komplett neue Architektur mit vier großen Zentralcomputern angekündigt, VW arbeitet mit dem US-Startup Rivian zusammen.

Die deutschen OEMs haben erkannt, dass eine tiefgreifende Transformation notwendig ist. BMW geht mit seiner neuen Klasse mutig voran und setzt auf eine zentralisierte Rechnerarchitektur, die viele Einzelsteuergeräte ersetzt. Volkswagen nutzt Kooperationen wie mit Rivian, um innovative Software- und Hardwarelösungen ins Portfolio zu bringen. Diese und ähnliche Schritte sind in der gesamten Industrie zu beobachten – nicht nur bei den deutschen OEMs.

Jedoch sind bei der Umsetzung deutliche Unterschiede zu erkennen. Ein wesentlicher Faktor bei der konsequenten Umsetzung ist, wie stark Altlasten über Bord geworfen werden können.

Oft ist von einer „zonalen“ E/E-Architektur die Rede. Was verbirgt sich hinter diesem Begriff?

Die „Zonen“ einer E/E-Architektur sind nur ein Teil des Gesamtkonzeptes. In der Regel besteht eine zonale Architektur aus einem bis zu einigen wenigen High-Performance-Computern (HPCs), mehren Zonen-Steuergeräten und den sensorischen/mechatronischen Komponenten.

Die HPCs verfügen über zentralisierte Funktionen und übernehmen die wesentlichen Aufgaben. Möglich wäre z.B. je ein HPC für alle Fahrfunktionen, die Connectivity und die autonomen Fahrfunktionen. Logisch darunter angeordnet sind die Zonensteuergeräte – etwa Vorderwagen, Fahrgastzelle und Heck, welche die sensorischen/ mechatronischen Komponenten anbinden. Ausnahmen bilden hierbei die Sensoren für die autonomen Fahrfunktionen, welche in der Regel direkt an die HPC angebunden sind.

Die neue Struktur reduziert drastisch die Komplexität, vereinfacht Kabelbäume, spart Gewicht, senkt Kosten und steigert die Flexibilität bei der Integration neuer Funktionen.

Kurz: Zonale Architekturen sind die Antwort auf die steigende Komplexität moderner Fahrzeuge.

Welche Rolle spielt die Cybersecurity bei der Entwicklung? Kann man da Maßnahmen vereinheitlichen oder müssen die Absicherungen spezifisch angepasst werden?

Spätestens mit der Einführung der neuen Cybersecurity Normen wie ISO/SAE 21434 und UN R.155 ist nicht nur die funktionale Sicherheit ein zentrales Entwicklungsziel. Die Cybersecurity ist, ebenso wie die OTA-Updates, ganzheitlich zu betrachten, da sie jede vernetzte Komponente betrifft und in der Post-Production-Phase über Jahre sichergestellt werden muss. Hierzu sind neue Prozesse, Vorgehen und Methoden notwendig, angefangen von einer sogenannten Threat-And-Risk-Analysis (TARA) über Cybersecurity Tests (auch in Kombination mit funktionalen Tests) bis zur ggf. späteren Stilllegung von Funktionen.  

Wie viel Kompetenz haben die OEM überhaupt bei den „Nervenbahnen des Autos“, welche Rolle spielen die Zulieferer bei der E/E-Architektur?

Im Rahmen des Software-Defined-Vehicles (SDV) und der Zonal-Architekturen bauen die OEMs verstärkt eigene Kompetenzen auf, besonders in Schlüsselbereichen wie Software-Architektur, Systemintegration und Funktionssicherheit. Die Definition der Architektur, der Bussysteme und der Kommunikation liegt dabei klar in den Händen der OEMs. Dieses gilt insbesondere für OEMs, die ein hohes Systemverständnis haben oder definierte Teile der Applikation selber entwickeln wollen.

Gleichzeitig bleiben Zulieferer unverzichtbare Partner – insbesondere bei der Bereitstellung der Hardware-Plattformen, Basissoftware oder spezifischen Technologien wie Hochvolt-Komponenten oder Fahrassistenzsystemen. Die Zusammenarbeit verschiebt sich jedoch: OEMs geben weniger Spezifikationen vor und übernehmen mehr Systemverantwortung, während Zulieferer verstärkt als Entwicklungspartner agieren.

Welche Trends sehen Sie bei der E/E-Architektur? Wohin geht die Reise bei der Hardware und welche Anforderungen werden an die künftige Software gestellt?

Die Richtung ist klar: stärkere Zentralisierung der Rechenleistung auf leistungsfähige HPCs und Zonen-Controller, verbunden über schnelle Ethernet-Netzwerke. Die Hardware und Software werden stärker entkoppelt, so dass flexiblere und modularere Systeme entstehen.

Software-seitig wird zunehmend modularer entwickelt und getestet. Die Virtualisierung nimmt dabei einen hohen Stellenwert ein, da nur so die hohen Anforderungen an schnelle Entwicklungszyklen, größere Komplexität bei gleichzeitig gesteigerter Qualität eingehalten werden.

Die geforderten Funktionsumfänge steigen stetig an. Kann das auch zu einer Kostenfalle werden? Über welche Kosten sprechen wir bei der E/E-Architektur eines modernen, vernetzten E-Autos und wohin werden sich die Kosten entwickeln, wenn die Anforderungen an die Systeme immer höher werden?

Natürlich ist eine steigende funktionale Komplexität ein hohes Risiko für explodierende Kosten. Schon heute macht die E/E-Architektur einen erheblichen Anteil an den Gesamtkosten eines Fahrzeuges aus. 

Allerdings ist es mit den richtigen Methoden, Prozessen und Werkzeugen möglich, die Kostenschraube nicht nur zu stoppen, sondern auch umzukehren. Die schon angesprochene Virtualisierung ist eine Möglichkeit. Zonale Architekturen mit leistungsfähigen HPCs führen zu einer erheblichen Vereinfachung der Kabelbäume. BMW hat hierzu kommuniziert, dass der Kabelbaum der neuen Klasse um 30% leichter ist und sich die Anzahl der Varianten um Faktor 3.000 reduziert hat.

Darüber hinaus ergeben sich durch die neuen E/E-Architekturen mit einer SW-Monetarisierung und OTA-Updates auch neue Möglichkeiten für die OEMs.