Die Evolution der EE-Architektur

Die Autoindustrie arbeitet derzeit fieberhaft an den Software- und Hardware-Komponenten ihrer Fahrzeuge. Fest steht, das historische gewachsene Durcheinander in punkto elektronischer Steuergeräte (ECUs), Steuersoftware und Verkabelung muss dringend vereinfacht und auf eine neue Basis gestellt werden. Es geht dabei um nichts anderes als um eine neue, elektrisch-elektronische EE-Architektur (E/E).

Der folgende Blog und die Abbildungen zeigen die logische Darstellung einer zonalen EE-Architektur im Fahrzeug und stellen nicht das physische Layout dar.

Mit neuen EE-Architekturen sollen nicht einfach komplexe Strukturen verringert, sondern gleichzeitig Kosten eingespart werden, nicht nur bei Design und Fertigung, sondern auch im Fahrbetrieb beim Service. Was wie der gordische Knoten der Auto-Elektronik erscheint, muss allerdings nicht über Nacht gelöst werden (mehr Information haben wir übrigens auch hier zusammengestellt). Moderne EE-Architekturen lassen sich, wenn sie überlegt konzipiert sind, mit der Zeit ausbauen – ähnlich wie bei neuen Modellen erweiterte Funktionen in die Fahrzeugpalette einer Marke aufgenommen und diese auf neue Markttrends reagieren können. Dabei gehen die Entwicklungsschritte von der in letzter Zeit üblichen Gateway-Architektur über die zum Teil schon praktizierte Domain-Controller-Architektur zu einer verteilten zonalen und schließlich zu einer konsolidierten zonalen EE-Architektur (Grafik 1).

Grafik 1: Beispiel eines evolutionären Wegs in eine Zonale E/E Architektur

Immerhin stellt die im Vergleich zur früheren, völlig dezentralisierten und „flachen“ Architektur eines Autos die derzeit am häufigsten in Fahrzeugen eingesetzte „Central Gateway Architecture“ bereits einen Fortschritt dar. Das Gateway strukturiert das Netz im Auto (Grafik 2). Es ist mit vielen Sub-Netzwerken verbunden und jede Funktion benötigt ihre eigenen Prozessoren (ECUs) sowie die entsprechenden Endgeräte (Edge Devices). Komplexität bedeutet ganz konkret auch Gewicht – mit rund 70 Kilogramm Kupfer – und diffizile manuelle Fertigung.

Grafik 2: das logische Layout einer “Central Gateway Architecture“  

Der nächste Schritt zu Anwendungsdomänen (Domains) bündelt verschiedene funktionale Bereiche mit ähnlichen Anforderungen, etwa Cockpit bzw. Armaturenbrett, Karrosserie (Body), Antriebsstrang (Drivetrain) und den Bereich automatisiertes Fahren (ADAS). Der zentrale Gateway-Domain-Controller übernimmt die komplexe Arbeit der Fahrzeugsteuerung, die Domain-Controller verwalten die verschiedenen Domain-Subnetze und konsolidieren die Funktionen einiger Steuergeräte, was die Komplexität schon ein wenig reduziert (Grafik 3).

Grafik 3: Das logische Layout einer “Domain Controller Architecture“

Im nächsten Evolutionsschritt ersetzt ein Fahrzeugserver das Domain-Gateway (siehe Grafik 4). Der Computer kann dann verschiedene Rollen einnehmen. Der Server verwischt die Anwendungsdomänen in gewisser Weise und unterteilt sie in weitere einzelne Software-Module. Im Laufe der Zeit können immer mehr Funktionen von den Domänen-Controllern auf den Fahrzeugserver verlagert werden, was zu einer weiteren Reduzierung der physischen Hardware und der Verkabelung führt und gleichzeitig eine Steigerung der Funktionalität ermöglicht. Die Entscheidung, ob eine Funktion von einem Domain-Controller oder einem zentralen Server gesteuert wird, wird durch den Entwicklungslebenszyklus der EE-Plattform des Fahrzeugs beeinflusst und kann unterschiedlichen Evolutionspfaden folgen.

Grafik 4: Die verteilte, zonale Architektur (logisches Layout)

Sobald eine Funktion auf einem Fahrzeugserver realisiert wird, kann sie leicht auf andere Fahrzeuge innerhalb der Marke oder verbundener Marken portiert werden, da es sich nur um Softwarepakete handelt. Auch bei der Entwicklung für künftige Modelle ergeben sich Vorteile. Die Entwicklungszeiten werden reduziert und gleichzeitig die Zuverlässigkeit und Qualität verbessert. Das Hinzufügen von softwarebasierten Funktionen zu einem Fahrzeugmodell, um eine Modelldifferenzierung zu schaffen, wird nicht länger eine große Neuentwicklung sein, sondern ein einfacher Softwarewechsel in einer gemeinsamen EE-Architektur. Zudem erlauben diese Architekturen das Hinzufügen von Funktionalität durch Firmware-Upgrades über den Lebenszyklus eines Autos hinweg. Die Konsolidierung der gesamten Software auf einem zentralen Fahrzeugserver ist die nächste Stufe der Evolution (Grafik 5).

Grafik 5: Die konsolidierte, zonale Architektur (logisches Layout)

Es wird sich noch zeigen, ob es bei einem Server bleibt oder mehrere Server bestimmte Funktionsbereiche bedienen. In dieser konsolidierten Stufe können also ein oder mehrere Fahrzeugserver alle Funktionen des Fahrzeugs steuern und die Verbindung zu einer verringerten Anzahl an ECUs herstellen, die als zonale Gateways fungieren und die sich auch physisch in verschiedenen Zonen innerhalb des Fahrzeugs befinden können. Die Gateways können in einer Baum-, Ring- oder Sterntopologie verbunden werden, je nach den Anforderungen an Ausfallsicherheit und Redundanz. Auch hierdurch werden die Kosten für Entwicklung, Hardware und Verkabelung erheblich gesenkt. Gleichzeitig werden Diagnose- und Wartungszeit verringert, was ebenfalls die Wirtschaftlichkeit verbessert (Grafik 6).

Figure 6: Die möglichen Topologien einer konsolidierten, zonalen Architektur (schematisches Layout)

Derzeit ist die „konsolidierte, zonale Architektur“ noch Zukunftsmusik, dennoch wird aktuell die Grundlage dafür geschaffen, indem schrittweise von der Hardware abstrahiert wird. GuardKnox arbeitet mit großen Fahrzeugherstellern zusammen und unterstützt sie auf dem Weg zu diesem Ziel.

Jeder Evolutionsschritt bringt die OEMs Stück für Stück in die sich klar abzeichnende Zukunft. Die Vorteile bei der Reduktion der Komplexität und der Kosten sowie der Erhöhung von Funktionalität und Flexibilität – bis hin zur Erschließung neuer Geschäftsmodelle – sind derart immens, dass sie wohl niemand außer Acht lassen kann.

Beachten Sie auch unser Webinar, das die Transformation in die zonale EE-Architektur aufzeigt.