Software-defined Vehicles: Wenn Code über Fahrverhalten und Reichweite entscheidet

Der Paradigmenwechsel im Fahrzeugbau durch softwaregesteuerte Systeme

Im klassischen Fahrzeug war die Funktion meist fest an ein bestimmtes Steuergerät gekoppelt. Das Motorsteuergerät regelte den Verbrennungsmotor, das Getriebesteuergerät schaltete, das ABS-Steuergerät überwachte die Raddrehzahlen, und zahlreiche weitere Einheiten tauschten Informationen über CAN- oder FlexRay-Verbindungen aus. Beim Software-defined Vehicle verschiebt sich diese Zuordnung. Funktionen werden zunehmend als Softwaredienste auf zentralen High-Performance Computern, kurz HPCs, ausgeführt. Dadurch entscheidet nicht mehr allein die mechanische Auslegung über Fahrverhalten, Rekuperation oder Reichweite, sondern auch der aktuelle Programmstand, die Parametrierung und die Kommunikation zwischen den Recheneinheiten.

Die Entkopplung von Software und Hardware ermöglicht es, Funktionen nach der Fahrzeugproduktion weiterzuentwickeln. Algorithmen für Drehmomentverteilung, Dämpferregelung oder Batteriethermomanagement können angepasst werden, ohne jedes Mal die Hardware zu ersetzen. Für die Werkstatt bedeutet das jedoch eine grundlegende Veränderung. Bei Beanstandungen an Fahrwerk, Antrieb oder Reichweite reicht das Auslesen eines einzelnen Fehlerspeichers oft nicht mehr aus. Zonale Netzwerktopologien und Automotive Ethernet Schnittstellen werden zu einem festen Bestandteil der Diagnose, ebenso wie Softwarestände, Berechtigungen, Codierungen und eine lückenlose Dokumentation.

Zonale E-E-Architekturen und Automotive Ethernet im Detail

In einer zonalen E-E-Architektur werden Sensoren und Aktoren zunächst nach ihrem Einbauort gebündelt. Eine Zone im Vorderwagen kann beispielsweise Kameras, Raddrehzahlsensoren, Beleuchtung, Lenksysteme und lokale Stellglieder anbinden. Ein Zonensteuergerät übernimmt die Kommunikation, wandelt Protokolle um und leitet die Daten über leistungsfähige Ethernet-Verbindungen an einen zentralen Fahrzeugcomputer weiter. Die lokale Bündelung reduziert die Zahl langer Einzelverbindungen und schafft eine klarere Trennung zwischen physischer Anbindung und funktionaler Verarbeitung.

Automotive Ethernet übernimmt dabei nicht einfach die Rolle eines schnelleren CAN-Busses. Ethernet stellt eine standardisierte, paketorientierte Kommunikationsbasis bereit, über die große Datenmengen von Kameras, Radar, Diagnosefunktionen und zentralen Anwendungen übertragen werden können. Multi-Gigabit-Verbindungen ermöglichen höhere Bandbreiten, während Switches, PHYs und Gateways den Datenverkehr priorisieren und in die jeweiligen Netzbereiche verteilen. Für die Werkstatt ist entscheidend, dass Kommunikationsfehler nicht zwangsläufig als klassischer Busfehler mit einem einzigen eindeutigen Eintrag erscheinen. Paketverluste, Synchronisationsprobleme, fehlerhafte VLAN-Konfigurationen oder ein instabiler Link können mehrere Funktionen gleichzeitig beeinflussen.

Der Unterschied zum klassischen Aufbau lässt sich in der Praxis wie folgt einordnen:

Merkmal	Klassischer ECU-Verbund	Zonaler HPC-Aufbau
Funktionsverteilung	Viele dedizierte Steuergeräte	Wenige zentrale Rechner und Zonencontroller
Kommunikation	Vorwiegend CAN, LIN oder FlexRay	Automotive Ethernet mit Gateway- und Switch-Strukturen
Softwarebindung	Stark an die ECU-Hardware gekoppelt	Abstrakte Softwaredienste und virtuelle Instanzen
Diagnose	Steuergerätebezogene UDS-Abfragen	Zusätzliche Server-, API- und Plattformdiagnose
Fehlerbild	Oft lokal begrenzter Ausfall	Mögliche Wechselwirkungen zwischen mehreren Funktionen

Bei der Fehlersuche muss deshalb zuerst die Architektur des konkreten Fahrzeugs bekannt sein. Ein Kommunikationsfehler an einem Zonencontroller kann beispielsweise dazu führen, dass mehrere Sensoren scheinbar gleichzeitig ausfallen. Vor dem Austausch einzelner Komponenten sind Versorgung, Masse, Ethernet-Link, Zeitstempel, Netzwerkzustand und Softwarekompatibilität zu prüfen. Ein vorschneller Teiletausch verschiebt die Ursache häufig nur und erzeugt zusätzliche Codier- oder Variantenprobleme.

Einfluss von Software auf Fahrdynamik und Reichweitenmanagement

Fahrdynamische Eigenschaften werden zunehmend durch zentrale Regelalgorithmen bestimmt. Bei Elektrofahrzeugen kann die Software das Antriebsmoment einzelner Achsen oder Räder koordinieren, die Rekuperation an Bremsdruck, Batteriezustand und Fahrmodus anpassen und gleichzeitig Stabilitätsregelsysteme berücksichtigen. Die mechanische Leistungsfähigkeit des Motors bleibt zwar unverändert, doch die Art, wie diese Leistung abgerufen wird, kann sich mit einem neuen Programmstand deutlich verändern.

Das gilt ebenso für das Energiemanagement. Ladezustand, Zelltemperatur, Innenwiderstand, Außentemperatur und erwartete Streckenprofile fließen in die Berechnung der verfügbaren Leistung ein. Das Thermomanagement entscheidet, wann Batterie, Inverter und Elektromotor gekühlt oder vorgewärmt werden. Eine optimierte Software kann Ladezeiten verkürzen oder die nutzbare Leistung bei niedrigen Temperaturen besser bereitstellen. Umgekehrt kann eine fehlerhafte Parametrierung zu vorsichtiger Leistungsbegrenzung, unnötigem Energieverbrauch oder einer auffälligen Abweichung zwischen berechneter und tatsächlich erreichbarer Reichweite führen.

• Eine geänderte Rekuperationsstrategie beeinflusst Verzögerung, Bremsgefühl und Energie-Rückgewinnung.
• Neue Temperaturgrenzen können Ladeleistung und Antriebsmoment begrenzen.
• Veränderte Navigations- und Verbrauchsmodelle wirken sich auf die Reichweitenprognose aus.
• Andere Drehmomentfilter können Anfahrverhalten, Traktion und Komfort spürbar verändern.
• Softwarestände von Batterie, Inverter, Antrieb und Fahrzeugrechner müssen zueinander passen.

Bei einer Reichweitenbeanstandung ist daher eine reine Probefahrt nicht ausreichend. Vor dem Start sollten Softwarestände, Adaptionswerte, Batteriezustand, Temperaturverläufe und relevante Energieverbrauchsdaten erfasst werden. Erst der Vergleich mit Referenzwerten unter ähnlichen Bedingungen zeigt, ob ein tatsächlicher Systemfehler, ein Lernwertproblem, ein thermischer Einfluss oder lediglich eine veränderte Berechnungslogik vorliegt. Software-defined Vehicles verlangen hier eine enge Verbindung aus klassischer Messtechnik, Datenanalyse und sauberer Versionskontrolle.

Over-the-Air Updates versus Werkstattprogrammierung

Over-the-Air-Updates sind besonders für Infotainment, Navigation, Konnektivität und ausgewählte Komfortfunktionen geeignet. Sie ermöglichen eine Aktualisierung ohne direkten Werkstattbesuch und können neue Funktionen oder Sicherheitskorrekturen bereitstellen. Bei sicherheitskritischen Mixed-Criticality-Systemen gelten jedoch andere Anforderungen. Auf einem zentralen HPC können Anwendungen mit sehr unterschiedlichen Sicherheits- und Echtzeitanforderungen parallel laufen. Eine Änderung an einer nicht sicherheitskritischen Anwendung darf weder Bremsung, Lenkung noch Energieversorgung beeinträchtigen.

Deshalb bleiben kontrollierte Werkstattverfahren für viele Steuergeräte und sicherheitsrelevante Softwarestände unverzichtbar. Ein unterbrochener Flashvorgang kann einen unvollständigen Programmstand hinterlassen. Auch ein Softwarekonflikt zwischen Batterieelektronik, Antrieb, Gateway und Fahrzeugkonfiguration kann nach einem scheinbar erfolgreichen Update Folgefehler erzeugen. Eine systematische Übersicht zu den Anforderungen zentralisierter Mixed-Criticality-Plattformen bietet die wissenschaftliche Literaturübersicht zu HPC-Architekturen.

• Vor dem Flashen Fahrzeugidentifikation, Zielsoftware und Kompatibilität prüfen.
• Eine geeignete, stabile Spannungsversorgung anschließen und Ladezustand sowie Stromreserve kontrollieren.
• Diagnoseinterface, Netzwerkverbindung und Rechner während des gesamten Vorgangs gegen Unterbrechung sichern.
• Verbraucher nach Herstellervorgabe abschalten und Zündung, Ladezustand oder Türstatus nicht eigenmächtig verändern.
• Nach dem Flashen Fehlerspeicher, Codierung, Anpassungen und Funktionsfreigaben vollständig prüfen.

In der Praxis sind OTA und Werkstattprogrammierung keine Gegenspieler. OTA kann eine Fahrzeugflotte schnell mit einem neuen Stand versorgen, während die Werkstatt die technische Kontrolle über sicherheitskritische Eingriffe, den Austausch von Steuergeräten und die abschließende Validierung behält. Ein neu eingebautes Modul besitzt häufig nur eine generische Software oder ist noch nicht an die Fahrzeugvariante angepasst. Die Registrierung, Codierung und gegebenenfalls das geführte Programmieren erfordern dann eine kabelgebundene Verbindung und einen stabilen Werkstattprozess.

Diagnose und Fehlersuche mit SOVD und virtuellen ECUs

Das klassische UDS-Modell richtet sich primär an einzelne Steuergeräte. Service-Oriented Vehicle Diagnostics, kurz SOVD, erweitert diesen Ansatz um eine serviceorientierte Kommunikation mit zentralen Recheneinheiten, Anwendungen und Diagnoseservern. Ein SOVD-kompatibler Server kann Diagnosedienste über strukturierte Schnittstellen bereitstellen, Zugriffe verwalten und Informationen aus HPCs, konventionellen Steuergeräten und virtuellen Instanzen zusammenführen. Lösungen wie PRODIS.SOVD verbinden dabei moderne HPC-Diagnose mit etablierten Verfahren wie UDS, ODX und K-Line.

Für die Werkstatt verändert sich damit die Perspektive. Es wird nicht mehr nur gefragt, welcher Fehlercode in welchem Steuergerät gespeichert ist. Zusätzlich ist zu klären, welcher Prozess, Dienst, Container oder Kommunikationspfad betroffen ist. Bei einem Linux-basierten HPC können Prozessstatus, Logdateien, KPI-Verläufe und Berechtigungen für die Ursachenanalyse relevant sein. Virtuelle ECUs unterstützen diese Entwicklung bereits in der Softwareentwicklung. Sie ermöglichen Tests mit mehreren Betriebssystemen und vernetzten Fahrzeugdiensten, bevor die finale Validierung auf realer Hardware erfolgt. Für die Diagnosepraxis bedeutet das, dass auch virtuelle Funktionsinstanzen und ihre Abhängigkeiten in der Fehlerkette berücksichtigt werden müssen.

1. Fahrzeug und Architektur eindeutig identifizieren, einschließlich HPC, Zonencontroller, relevanter Softwarestände und Kommunikationsvarianten.
2. Gesamtfahrzeugdiagnose durchführen und nicht nur den Fehlerspeicher des betroffenen Funktionsbereichs auslesen.
3. Fehlerzeitpunkte, Umgebungsbedingungen, Kommunikationsstatus und wiederkehrende Ereignisse mit Logdaten und KPI-Verläufen abgleichen.
4. Versorgung, Masse, Ethernet-Link, Gateway-Routing und Berechtigungen prüfen, bevor einzelne Hardware ersetzt wird.
5. Nach der Korrektur einen kontrollierten Funktionstest, erneuten Diagnoselauf und Versionsabgleich durchführen.

Wichtig ist eine klare Trennung zwischen Symptom und Ursache. Ein ausgefallener Fahrerassistenzdienst kann durch einen Sensor, eine Netzwerkverbindung, einen Prozessabsturz, einen ungültigen Softwarestand oder eine fehlende Berechtigung ausgelöst werden. SOVD erleichtert den strukturierten Zugriff, ersetzt aber nicht die technische Bewertung. Jede Diagnoseaktion muss nachvollziehbar bleiben, besonders wenn Remotezugriff, OTA-Funktionen oder sicherheitsrelevante Freigaben beteiligt sind.

Variantenvalidierung und saubere Konfigurationsdokumentation

Jede Codierung, Anpassung und Programmierung verändert den Zustand des Fahrzeugs. Variantencodierung legt fest, welche Ausstattung und welche Funktionsumfänge eine Steuerung erwartet. Eine Anpassung verändert beispielsweise Lernwerte oder Schwellen, während eine Programmierung den eigentlichen Softwarestand ersetzt. Diese Eingriffe dürfen nicht in einem allgemeinen Auftragstext verschwinden. Die Dokumentation muss erkennen lassen, welcher Zustand vorlag und welcher Zielzustand hergestellt wurde.

Besonders nach OTA-Aktualisierungen ist der Soll-Ist-Abgleich entscheidend. Ein Fahrzeug kann zwischen zwei Werkstattbesuchen seinen Softwarestand ändern, ohne dass ein klassischer Werkstattauftrag dazu existiert. Vor der Freigabe müssen deshalb Softwareversionen, Hardwareindex, Codierung, Anpassungen und relevante Kampagnen geprüft werden. Eine belastbare Fahrzeugakte verhindert Doppelprogrammierungen, erleichtert spätere Fehlersuche und schützt vor Rückruffehlern durch nicht zusammenpassende Stände.

1. Fahrzeugidentifikation, Kilometerstand und Anlass der Arbeit dokumentieren.
2. Vorherigen Zustand von Hardware, Software, Codierung und Anpassungswerten sichern.
3. Verwendetes Diagnosesystem, Datenstand und durchgeführte Arbeitsschritte festhalten.
4. Zielsoftware, Codierung und Variantenkonfiguration mit der Herstellervorgabe abgleichen.
5. Nacharbeit durch Fehlerspeicherprüfung, Funktionsprüfung und erneuten Versionsreport bestätigen.

Vor der Auslieferung sollte zusätzlich geprüft werden, ob alle Steuergeräte erreichbar sind, keine temporären Kommunikationsfehler zurückbleiben und sicherheitsrelevante Funktionen freigegeben sind. Bei Elektrofahrzeugen gehören dazu auch Ladefreigabe, Hochvoltstatus, Batterietemperaturmanagement und die Plausibilität der Reichweitenberechnung. Eine saubere Dokumentation ist damit kein Verwaltungsaufwand am Rand, sondern ein technischer Teil der Reparaturqualität.

Souveräne Beherrschung softwaredefinierter Systeme als Werkstattstandard

Software-defined Vehicles verbinden klassische Mechatronik mit IT-Netzwerkdiagnose. Mechanische Bauteile, Sensoren, Aktoren, Ethernet-Strukturen, HPCs, virtuelle Steuergeräte und Cloud-Dienste bilden ein zusammenhängendes System. Wer nur den mechanischen Fehler oder nur den gespeicherten Code betrachtet, riskiert eine unvollständige Diagnose. Entscheidend ist ein sauberer Ablauf, der Versorgung, Kommunikation, Softwarestand, Konfiguration und Funktion gemeinsam bewertet.

Werkstätten stellen sich zukunftssicher auf, wenn sie Diagnoseprotokolle standardisieren, Ethernet-Messtechnik beherrschen, SOVD und klassische UDS-Verfahren kombinieren und jede Änderung am Fahrzeugzustand nachvollziehbar dokumentieren. Vor jedem Flashvorgang stehen Identifikation, Kompatibilitätsprüfung und stabile Spannungsversorgung. Nach jedem Eingriff folgen Soll-Ist-Abgleich, Funktionsprüfung und eine belastbare Abschlussdokumentation. So wird aus komplexer Software keine unkontrollierbare Variable, sondern ein prüfbarer Bestandteil professioneller Fahrzeugdiagnose.