Traditionell sind die Rechner (Steuergeräte) in Fahrzeugen bis 2020 bzw. 2025 in einer Domainarchitektur organisiert. Das bedeutet, sie sind ihren Aufgaben nach entsprechenden Bereichen des Fahrzeugs zugeordnet. Mit der Zeit sind die in größeren Gruppen organisiert, sodass eines sich nicht mehr z.B. nur um die Bremsen bzw. das ABS kümmert.

Das ist also bei der fortgeschrittenen Domainarchitektur schon längst in den Rechner für das Fahrwerk aufgegangen oder die Software für den Motor in die Funktionsdomäne Antriebsstrang. Jede Domäne hatte ihren eigenen Controller. Es war also schon ein erster Schritt in die Richtung geringerer Anzahl von Steuergeräten.

Aber z.B. der Leitungsaufwand zu den Sensoren war noch groß, weil die Wirkungsbereiche der einzelnen Controller sich überschnitten. Leicht zu erkennen, dass der Zonenrechner hier etwas mehr Abhilfe schafft. Wichtig auch, das Auto von heute hat weniger Zonen als früher Domänen. Es ist also ein weiterer Schritt in Richtung Verdichtung.

Trotzdem bleibt bei einer Zonenarchitektur trotz verminderter Anzahl von Steuergeräten ein zentraler Hochleistungsrechner erhalten. Die Funktionen müssen koordiniert werden und z.B. der lokalen Zuordnung eines OTA-Updates zugeordnet werden. Hier ist auch schon Software enthalten, die unabhängig von Hardware ist.

Überhaupt spielt ja genau in diesem Zusammenhang die Middleware eine wichtige Rolle. Veränderungen sind möglich, ohne die Hardware explizit zu kennen. Umgekehrt kann sich ein Fehler leichter auf größere Bereiche auswirken und wer sich hier illegalen Zugang verschafft hat deutlich mehr Möglichkeiten.

Wie haben die Zulieferer auf die Neueinführung solcher Systeme reagiert und wie sieht nunmehr deren Zusammenarbeit mit OEMs aus? Sie bieten z.B. komplette Zentralcomputer an, bei Bosch Central Vehicle Computers, bei Continental zentrale E/E-Plattform und bei ZF ProAI mit einem der leistungsstärksten Fahrzeugrechner überhaupt.

Spätestens hier lernen wir einen neuen Begriff im Gegensatz zum schon ewig verwendeten der Central Processing Unit die Graphics Processing Unit kennen. Letztere ist im Gegensatz zu ersteren auf massive Parallelverarbeitung ausgelegt, tausende Operationen gleichzeitig.

Wir nehmen hier nur ein Beispiel für den Aufgabenbereich einer GPU. Es wäre die Auswertung von Bildern und deren Vergleich vielleicht mit Vorlagen, womit wir beim Autonomen Fahren oder zumindest dem in fast allen neuen Fahrzeugen beschrittenen Weg dorthin wären. Auch das muss in einer modernen Software-Architektur einen Platz finden.

Und wenn wir schon einmal bei der Unterbringung von Algorithmen sind, die müssen z.B. bei einem Notbremssystem zumindest doppelt und bei Drive by Wire auch noch dreifach ausgelegt sein. An alledem sehen Sie, dass es mit der friedlichen Nutzung nebeneinander von CAN- und anderen Bussen ohne Aufdeckung der Software vorbei ist.

Vielleicht bezieht sich die Definition des Software-basierten Autos gar nicht so sehr auf das Infotainment, als vielmehr um die innere Struktur der anderen, für das Fahren und die Sicherheit viel wichtigeren Strukturen moderner Fahrzeuge. Dort wird Integration jetzt besonders wichtig. Vielleicht werden die meisten Veränderungen hier dem/der Autofahrer/in gar nicht bewusst.

Für die Zusammenarbeit zwischen OEMs und Zulieferern wird es im wahrsten Sinne des Wortes eng. Warum? Ganz einfaches Beispiel wäre, wenn ein Zulieferer die Steuerung für die elektrische Handbremse und ein anderer die Verstellbarkeit der Federung bei Anhängerbetrieb liefern würde, beide integriert in den Zonenrechner Heckzone.

ChatGPT sagt dazu, dass die OEMs wesentlich mehr Softwarehoheit übernehmen bis hin zur Übernahme vieler Aufgaben von Zulieferern. Umgekehrt können diese als Produzenten kompletter Module ihren Aufgabenbereich wesentlich erweitern. Mögliche Zwischenlösungen und die damit einhergehenden Rechtsfragen vielleicht in einem eigenen Kapitel.