ee_architektur
| von Claas Berlin

In heutigen Autos tun bis zu 120 Rechner Dienst. Sie fahren die Seitenfenster auf Knopfdruck hinauf und wieder herunter, regeln die Innenraumtemperatur und sorgen dafür, dass der Kraftstoff genau im richtigen Moment und in der optimalen Menge in die Zylinder eingespritzt wird. Daneben werden noch zahlreiche weitere Fahrzeugfunktionen von solchen Kleincomputern gesteuert – von A wie ABS bis W wie Wegfahrsperre.

Fast überall, wo in den letzten Jahren schwerfällige Mechanik durch flexibel einsetzbare Elektronik verdrängt wurde, kamen sogenannte Electronic Control Units (ECUs) zum Einsatz. Pro Funktion eine ECU galt lange als feste Regel. Doch stößt diese Strategie mittlerweile an ihre Grenzen – und das gleich in mehrfacher Hinsicht: Skalierbarkeit, Komplexität, Versionsmanagement – das sind nur drei der vielen Aspekte, an denen sich die Grenzen des unkoordinierten Wildwuchses festmachen lassen.

Die Kommunikation zwischen den ECUs erfolgt typischerweise über Bussysteme wie CAN oder LIN. Im Dickicht des ECU-Dschungels aber lässt sie sich immer schwieriger managen. Ganz abgesehen davon, dass diese Systeme dem erhöhten Datenaufkommen nicht mehr gewachsen sind. Ganz praktische Überlegungen zeigen, dass es so nicht mehr weitergehen kann: Woher den Platz für immer mehr ECUs nehmen? Wie den steigenden Stromverbrauch abfedern? Last, but not least: Es wird immer schwieriger und teurer, die vielen unterschiedlichen Prozessortypen als Ersatzteil über den gesamten Produktlebenszyklus eines Fahrzeugmodells zu beschaffen und zu bevorraten.

Hersteller, die ihre Autos für die digitale Zukunft mit ihren schnellen Innovationszyklen und datenbasierten Geschäftsmodellen fit machen wollen, sind daher gut beraten, das elektronische Innenleben der Fahrzeuge auf eine neue Basis zu stellen. Überall in der Autoindustrie geht die Entwicklung dahin, Funktionen von der hardcodierten Single-Use-Elektronik auf die Softwareebene zu verlegen. Das erhöht schon mal die Flexibilität und lindert einige der genannten Probleme, etwa beim Platzbedarf und Energieverbrauch.

Ein weiterer Schritt ist der Ersatz bisher physisch vorhandener ECUs durch virtuelle Software-ECUs – Softwareapplikationen in einem Domänen- oder Zentralrechner. Folgt diese Umstellung einem konsistenten Architekturmodell und kann sie auf Standards aufsetzen, lässt sich damit die Komplexität erheblich reduzieren. An solchen Konzepten feilen die Elektronikabteilungen aller Autohersteller.

Die Nase vorn in diesem Rennen hat wohl Volkswagen mit seiner E3-Architektur (End-to-End-Elektronik). „Bei dem erreichten Verteilungsgrad der Funktionen und den Performance-Anforderungen gerät der bisherige Ansatz ganz klar an seine Grenzen“, erläutert Rolf Zöller, Leiter der Elektrik- und Elektronikentwicklung des Wolfsburger Autobauers. „Unsere E3-Architektur nimmt die Verteilung von Funktionalitäten wieder ein Stück zurück und zentralisiert wesentliche Funktionsanteile.“

Strikte Trennung zwischen Sensoren und Kommunikation

Ein Grundgedanke ist die Trennung der Ebenen: Sensoren und Aktuatoren sind auch weiterhin eng an die Hardware und die Mechanik angebunden, aber sie sind architektonisch von der Funktionslogik separiert. Auch hier, sozusagen im Maschinenraum der Fahrzeugelektronik, hat eine Akzentverschiebung stattgefunden: Die Komponenten auf dieser Ebene haben mit ihrer lokal integrierten Intelligenz jetzt eher den Charakter eines Smart Sensors oder Smart Actuators, wie Zöller anmerkt. Die Vorverarbeitung der Signale geschieht direkt vor Ort.

Die eigentliche Funktionslogik, die Kommunikation und die Verteilung der Daten hingegen spielen sich auf einer höheren Rechnerebene ab. Statt ECUs mit dedizierter Software, die nur auf einem spezifischen Mikrocontroller lauffähig ist, sind die Steuergeräte jetzt als Softwareapplikation auf einer wesentlich rechenstärkeren und flexibleren Plattform implementiert. Stichwort: virtuelle ECUs. Auf dieser Plattform können auch höherwertige Betriebssysteme eingesetzt werden, eine Abstraktionsschicht trennt die Hardware von der Software.

Das erinnert nicht nur zufällig an die Architektur großer IT-Systeme, es heißt auch so: In-Car Application Server (ICAS) nennt Volkswagen diese Ebene. „In Summe ergeben sich daraus deutlich mehr Freiheitsgrade, um Funktionen zu realisieren“, erklärt Rolf Zöller die Vorteile. „Man ist schneller in der Entwicklung.“ Die Kommunikationsmechanismen sind einfacher, weil sie in Software ausgelegt sind und die Ingenieure auf etablierten und verbreiteten Standards aufbauen können. Das betrifft nicht nur Autosar und Autosar Adaptive – dieses Rahmenwerk wird schon seit geraumer Zeit auch bei der Konzeption herkömmlicher ECUs berücksichtigt.

Volkswagens E3-Architektur öffnet sich auch für moderne Betriebssysteme – mit Eigenschaften wie Virtualisierung, Speicherschutz und Rechtemanagement, nicht viel anders als in der kommerziellen IT. Die Programmierschnittstellen (APIs) abstrahieren das Betriebssystem bis zu einem gewissen Grad. „Damit werden wir ein Stück weit Betriebssystem-agnostisch“, erläutert Zöller die Vorteile. Auch die Datenkommunikation zwischen den Rechnern erfolgt nach bewährten IT-Standards: Ethernet löst auf dieser Ebene Systeme wie CAN oder FlexRay ab, die einst aus der Fahrzeugindustrie heraus konzipiert wurden.

Rollout der E3-Architektur auf den gesamten Konzern

Der vielleicht wichtigste Aspekt dieser neuen Umgebung ist seine Skalierbarkeit. Die E3-Architektur soll schließlich, wie Rolf Zöller unterstreicht, für die gesamte Bandbreite der Fahrzeuge aus dem Volkswagen-Konzern gelten – ohne jegliche Brüche „vom kleinsten Škoda bis zum Panamera“. Im Hinblick auf den Faktor Skalierbarkeit steht der VW-Konzern sicher vor einer größeren Herausforderung als jeder andere Autohersteller.

Kein Wettbewerber bietet seinen Kunden ein ähnlich breites Produktspektrum an. Jedes Auto aus Volkswagens weitverzweigtem Markenuniversum, vom Up bis zum Q8 und dem erwähnten Panamera, soll softwaretechnisch auf derselben Basis aufbauen. Wobei die gehobeneren Modelle natürlich einen größeren Funktionsumfang bieten werden. Deswegen ist nicht zu erwarten, dass die softwaretechnische Skalierbarkeit auch von einer einheitlichen darunterliegenden Hardware begleitet wird.  Je nach Leistungsstufe kann eine unterschiedliche Prozessorplattform erforderlich sein.

Zu den bei Volkswagen gegenwärtig diskutierten Fragestellungen gehört laut Zöller daher auch das Partnermanagement für möglicherweise unterschiedliche Hardware. Ebenfalls eine zentrale Frage bei der Entwicklung der Architektur ist die Anzahl der nötigen In-Car Application Server. In der Branche werden vereinzelt radikale Vorschläge diskutiert, die auf einen einzigen Zentralrechner im Fahrzeug abzielen.

Nicht zuletzt unter dem Aspekt der Ausfallsicherheit und Redundanz sieht Volkswagens Konzept aber mindestens zwei solcher Server vor – einer ist primär für den Fahrzeugbetrieb und die Anbindung an die Außenwelt zuständig, der andere für wesentliche Cockpitfunktionen, Fahrerinformationssysteme und das Infotainment. Je nach Ausgestaltung des Fahrzeugmodells und der Anzahl der Fahrerassistenzsysteme könnten die Aufgaben auf bis zu fünf Computer verteilt werden, erläutert Rolf Zöller.

Ebenfalls ganz oben auf der Prioritätenliste der Volkswagen-Entwickler stand die Forderung, die installierte Software erforderlichenfalls per Fernupdate auf den neuesten Stand zu bringen – schon allein aus Gründen der IT-Security. Denn in der Autobranche setzt sich immer mehr die Erkenntnis durch, dass ein softwaredefiniertes Fahrzeug mindestens den gleichen Schutz gegen Datendiebe und Hacker braucht wie der Server eines Unternehmens. „Um diese Risiken aktiv zu managen, werden wir die Connected Cars der Zukunft sehr schnell mit Sicherheitsupdates versorgen müssen“, beschreibt Zöller die Lage. Bei reinen Sicherheitsupdates muss es aber nicht bleiben. „Wenn man diese Kommunikationsinfrastruktur schon einmal hat, kann man damit auch dem Kunden viel Gutes tun“, so der VW-Vordenker. Die Spanne möglicher Angebote reicht von einer komfortablen Fehlerbehebung bis zur Freischaltung von Functions on Demand, die – je nach Angebot – auch zeitlich befristet sein kann.

Illustration: Shutterstock/Vladimiroquai