Vom Fahrzeug mit Elektronik zur Softwareplattform
Bis vor kurzem konnte man ein modernes Fahrzeug aus Diagnosesicht als Sammlung vieler einzelner Steuergeräte verstehen. Der Motor hatte sein Steuergerät, das Getriebe ein eigenes, das Komfortsystem ein weiteres, Airbags, ABS und Infotainment ebenfalls. Jedes Steuergerät hatte seine Aufgabe, seinen eigenen Fehlerspeicher und seine eigene Kommunikationslogik. Der Techniker schloss das Diagnosegerät an, wählte das System aus, las Fehler aus, prüfte Messwerte und arbeitete von dort aus weiter.
Diese Welt verändert sich allmählich. Nicht über Nacht, nicht bei allen Marken gleichzeitig, aber die Richtung ist klar. Das Fahrzeug entwickelt sich von einem hardwareverteilten System zu einer Softwareplattform. Funktionen, die früher fest in einem bestimmten Steuergerät lagen, wandern zunehmend in zentrale Rechner, Domänencontroller oder Zonenarchitekturen. Gleichzeitig nehmen Cloud-Kommunikation, Fernupdates und Dienste zu, die während der Lebensdauer des Fahrzeugs aktiviert oder verändert werden können.
Bosch beschreibt das Software Defined Vehicle als Fahrzeug, dessen Funktionen durch Konnektivität und Over-the-Air-Updates kontinuierlich optimiert und erweitert werden können. Genannt werden auch Funktionen, die je nach Bedarf des Fahrers individuell aktiviert werden, etwa temporäre Dienste, Apps oder Funktionen als Service.
Für den Kunden klingt das komfortabel. Für die Werkstatt bedeutet es: Das Fahrzeug, das heute auf dem Hof steht, muss sich nicht mehr exakt so verhalten wie gestern.
Wenn dasselbe Modell technisch nicht dasselbe ist
Mechaniker sind daran gewöhnt, mit Baujahr, Motorisierung, Ausstattung und Motorkennbuchstaben zu arbeiten. Bei Software Defined Vehicles müssen sie zunehmend auch Softwareversion, aktivierte Funktionen, Update-Status, regionale Konfiguration, Dienstabonnements und frühere Softwareeingriffe berücksichtigen.
Zwei Fahrzeuge desselben Modells und Baujahrs müssen aus Diagnosesicht daher nicht mehr identisch sein. Eines kann ein neueres OTA-Update erhalten haben, das andere nicht. Eines kann eine Funktion aktiviert haben, die beim anderen fehlt. Eines kann nach einer Softwaremaßnahme des Herstellers ein anderes Verhalten des Fahrerassistenzsystems zeigen, während das andere noch mit einer älteren Version läuft.
Dieser Unterschied ist entscheidend. Bei einem klassischen Fehler sucht die Werkstatt ein defektes Bauteil, eine unterbrochene Leitung, einen fehlerhaften Sensor, ein Spannungsproblem oder eine Kommunikationsstörung. Bei einem Software Defined Vehicle kann die Ursache aber auch eine inkompatible Softwareversion, ein unvollständiges Update, eine geänderte Konfiguration, ein inaktiver Onlinedienst oder eine Sicherheitsbeschränkung sein.
Zonenarchitektur: weniger Steuergeräte, aber komplexere Zusammenhänge
Ein wichtiger technischer Schritt in Richtung Software Defined Vehicle ist die Veränderung der elektrischen und elektronischen Fahrzeugarchitektur. Das klassische Modell mit vielen einzelnen Steuergeräten wird für Hersteller immer komplexer, teurer und schwieriger zu aktualisieren. Deshalb gewinnen zentralisierte und zonale Architekturen an Bedeutung.
In einem klassischen Fahrzeug werden Systeme meist nach Funktion gegliedert. In einer Zonenarchitektur wandert ein Teil der Logik in leistungsfähigere zentrale Rechner, während Zonencontroller physische Bereiche des Fahrzeugs betreuen. Vereinfacht gesagt: Nicht mehr jede Funktion hat zwangsläufig ihr eigenes spezialisiertes Steuergerät. Mehr Funktionen laufen als Software auf einer gemeinsamen Rechenplattform.
Industrieanalysen aus den Jahren 2025 und 2026 beschreiben zonale E/E-Architektur als Möglichkeit, die Kabelkomplexität zu reduzieren und die Kommunikation zwischen Steuergeräten effizienter zu gestalten. S&P Global Mobility beschreibt Zonenarchitektur beispielsweise als Architektur, die Komplexität durch eine vereinfachte Kommunikation zwischen ECUs reduziert. Aktuelle technische Übersichten für 2026 verbinden zentralisierte und zonale Architekturen mit Software Defined Vehicles, Ethernet und Virtualisierung.
Für die Werkstatt hat das eine schwierige Konsequenz. Ein Fehler muss nicht mehr sauber in einem einzelnen Steuergerät isoliert sein. Wenn ein Problem in der zentralen Rechenplattform, der Kommunikationsschicht oder einem Softwaredienst liegt, kann es sich in mehreren Systemen gleichzeitig zeigen. Der Techniker sieht dann nicht einen klaren Fehlercode mit eindeutiger Richtung, sondern eine Gruppe von Symptomen, die auf den ersten Blick nicht zusammengehören.
Nach einem Update kann ein Kunde zum Beispiel berichten, dass sich der Spurhalteassistent anders verhält, das Infotainment verändert wurde und das Fahrzeug eine Warnung zu einem Onlinedienst zeigt. Bei einem älteren Fahrzeug würde man vielleicht drei getrennte Fehler vermuten. Bei einem SDV kann eine einzige Software- oder Konfigurationsursache dahinterstehen.
OTA-Updates: Reparatur ohne Werkstattbesuch, aber auch Fehler ohne mechanischen Eingriff
Over-the-Air-Updates gehören zu den sichtbarsten Elementen des Software Defined Vehicle. Aus Sicht der Hersteller sind sie sehr sinnvoll. Das Fahrzeug muss nicht wegen jeder Softwareanpassung in die Werkstatt. Eine Funktion kann aus der Ferne verbessert, korrigiert oder ergänzt werden. Elektrobit beschreibt OTA-Update-Lösungen als vollständige Kette, die Backend-Dienste, einen OTA-Client und fahrzeugseitige Komponenten für Software- und Firmwareupdates umfassen kann.
Für Werkstätten entsteht dadurch eine neue Realität. Ein Fahrzeug kann sich verändern, ohne physisch in der Werkstatt gewesen zu sein. Der Kunde kommt und sagt: „Seit gestern verhält es sich anders.“ Der Mechaniker öffnet die Motorhaube und sieht nichts Auffälliges. Die Kabel sind in Ordnung, die Stecker sitzen, die Sensorwerte wirken plausibel. Trotzdem verhält sich das Fahrzeug anders, weil sich die Software geändert hat.
Das bedeutet nicht, dass OTA schlecht ist. Im Gegenteil, aus Sicht von Sicherheit und Reparierbarkeit können OTA-Updates sehr wertvoll sein. Forschungsarbeiten zu sicheren OTA-Updates betonen, dass Fernupdates immer wichtiger werden, um Softwarefehler und Schwachstellen in modernen elektrischen und elektronischen Fahrzeugarchitekturen zu beheben.
Ohne diese Information kann eine Werkstatt ein Bauteil ersetzen, das gar nicht defekt ist.
Diagnose wird nicht mehr nur Fehlerspeicherlesen sein
Beim klassischen Fahrzeug hatte der Fehlerspeicher eine zentrale Bedeutung. Ein DTC war nicht immer die vollständige Antwort, aber meistens ein guter Ausgangspunkt. Er zeigte eine Richtung. Bei Software Defined Vehicles bleibt das Auslesen von Fehlern wichtig, reicht aber allein nicht mehr aus.
Moderne Diagnose muss stärker mit Kontext arbeiten. Die Frage lautet nicht nur „welches Steuergerät meldet einen Fehler“, sondern auch „welche Softwareversion läuft im System“, „welcher Dienst sollte aktiv sein“, „welche Funktion ist freigeschaltet“, „ob die Synchronisierung abgeschlossen wurde“, „ob eine Funktion durch Autorisierung gesperrt ist“ und „ob das Problem möglicherweise außerhalb des Fahrzeugs liegt“.
Das ist für viele Werkstätten eine unbequeme Veränderung. Mechaniker sind daran gewöhnt: Wenn das Auto in der Werkstatt steht, liegt das Problem im Auto. Bei SDVs stimmt das nicht immer. Die Ursache kann im Backend des Herstellers liegen, im Kundenkonto, im digitalen Schlüssel, in einer Lizenz, in regionalen Einstellungen, in einem inkompatiblen Update oder in der Sicherheitsrichtlinie des Fahrzeugs.
Ein typisches Beispiel ist ein Kunde, der sich über eine nicht funktionierende Komfort- oder Onlinefunktion beschwert. Hardwareseitig kommuniziert das Fahrzeug korrekt. Das Diagnosegerät zeigt keinen klassischen Fehler. Das eigentliche Problem kann sein, dass der Dienst nicht aktiv ist, das Konto nicht synchronisiert wurde oder das Fahrzeug auf den Abschluss eines Updates wartet. Das ist keine Arbeit für den Hammer und auch kein Grund, sofort ein Steuergerät zu ersetzen. Das ist Arbeit für Diagnoselogik, technische Unterstützung und Verständnis des Hersteller-Ökosystems.
Standarddiagnose, angeschlossen an den CAN-Bus
Warum das mit SGW, SFD und Cybersecurity zusammenhängt
Das Software Defined Vehicle lässt sich nicht von Cybersecurity trennen. Je mehr Funktionen softwarebasiert, fernaktualisierbar und mit Cloud-Diensten verbunden sind, desto wichtiger wird die Kontrolle darüber, wer welche Änderungen durchführen darf. Deshalb nehmen Security Gateways, Autorisierungen, Zertifikate, geschützte Diagnosefunktionen und Zugangssysteme wie SGW und SFD zu.
Bei älteren Fahrzeugen war die Wirkung eines unbefugten Eingriffs begrenzter. Bei einem Software Defined Vehicle kann eine Konfigurationsänderung nicht nur ein Steuergerät, sondern das Verhalten eines gesamten Systems beeinflussen. Deshalb verschärfen Hersteller den Diagnosezugang. Das ist nicht nur ein wirtschaftlicher Kampf um den Servicemarkt, auch wenn dieser Aspekt natürlich existiert. Es ist auch eine Reaktion auf das reale Risiko, dass ungeprüfte Änderungen in einem softwarebasierten System sicherheitsrelevante Folgen haben können.
Eine im Mai 2026 veröffentlichte Übersichtsarbeit beschreibt SDVs als grundlegenden Wandel von hardwarezentrierten Systemen zu softwarezentrierten Plattformen mit OTA-Updates, Automatisierung, vernetzten Diensten, Cloud-Infrastruktur, Middleware und neuen Herausforderungen bei Cybersecurity, Interoperabilität und Datenmanagement.
Für den Mechaniker bedeutet das praktisch: Wenn das Fahrzeug zur Softwareplattform wird, ähnelt ein Diagnoseeingriff stärker einem Eingriff in ein IT-System. Und bei einem IT-System geht es nie nur um „Kabel und Gerät“. Es geht um Berechtigungen, Versionen, Protokolle, Abhängigkeiten und Sicherheitsrichtlinien.
Was der Mechaniker der Zukunft verstehen muss
Der Mechaniker der Zukunft ist kein Softwareentwickler im Overall. Das wäre übertrieben und für den normalen Werkstattalltag unrealistisch. Aber er muss die Grundlogik von Softwaresystemen verstehen.
Er muss wissen, dass ein Update das Fahrzeugverhalten verändern kann. Er muss erkennen können, wann ein Fehler wie ein Hardwareproblem aussieht, aber tatsächlich mit Konfiguration zusammenhängt. Er muss verstehen, warum Funktionen, die früher problemlos möglich waren, heute ohne korrekte Autorisierung blockiert sind. Er muss mit Protokollen, Berichten, Softwareständen und Onlineverfahren arbeiten können.
Das bedeutet nicht, dass klassische mechanische Arbeit verschwindet. Bremsen, Fahrwerk, Motor, Klimaanlage, Karosserie und Verkabelung bleiben. Der Unterschied ist, dass Reparaturen immer häufiger mit einem Softwareschritt enden. Ein Bauteiltausch ohne Anpassung ist keine fertige Arbeit. Eine Unfallreparatur ohne ADAS-Kalibrierung ist keine fertige Arbeit. Ein Steuergerätetausch ohne Online-Autorisierung ist keine fertige Arbeit. Und Diagnose ohne Verständnis der Fahrzeugarchitektur wird immer häufiger blind.
Was das für Kunden von Diagnosegeräten bedeutet
Für Kunden von Diagnosegeräten wird nicht mehr nur entscheidend sein, wie viele Marken das Gerät unterstützt. Entscheidend wird, wie gut es in einer realen Werkstattsituation hilft. Bei Software Defined Vehicles reicht es nicht, möglichst viele Steuergeräte auszulesen. Der Techniker muss verstehen, was er mit den Informationen tun soll.
Hier kann DevCom als praktischer Partner für Werkstätten auftreten. Nicht nur als Lieferant von Diagnosegeräten, sondern als Unternehmen, das Werkstätten hilft, sich in der neuen elektronischen Realität der Fahrzeuge zurechtzufinden. Bei SGW/SFD bedeutet das, zu erklären, wann ein Problem an der Autorisierung liegt. Bei SDV bedeutet es, dem Techniker zu helfen zu unterscheiden, ob er ein Hardwareproblem, ein Softwareproblem, eine Konfiguration, einen Onlinedienst oder eine Herstellereinschränkung vor sich hat.
Im Werkstattalltag ist das sehr wertvoll. Ein Techniker, der versteht, dass die Ursache in der Softwareebene liegen kann, ersetzt nicht unnötig Bauteile. Eine Werkstatt, die Updates und Autorisierungen versteht, kann dem Kunden Reparaturdauer und Kosten besser erklären. Und ein Diagnoseanbieter, der diese Veränderung erklären kann, ist nicht nur Verkäufer eines Geräts, sondern ein fachlicher Begleiter.
Diagnose für das Software Defined Vehicle über autorisierten Zugriff auf das Security Gateway
Was Werkstätten schon heute tun sollten
Freie Werkstätten müssen nicht warten, bis jedes Fahrzeug vollständig softwaredefiniert ist. Die Veränderung hat bereits begonnen. Einige Gewohnheiten lohnen sich schon heute.
Bei neueren Fahrzeugen sollten Werkstätten Diagnoseberichte vor und nach der Reparatur speichern. Softwarestände sollten dokumentiert werden, sofern das Diagnosegerät dies ermöglicht. Es sollte erfragt werden, ob das Problem nach einem Update, nach einem Teiletausch, nach einem Unfall oder nach einem Eingriff einer anderen Werkstatt aufgetreten ist. Stabile Internetverbindung, stabilisierte Spannungsversorgung und ein klarer Prozess für online autorisierte Funktionen werden wichtiger.
Genauso wichtig ist Schulung. Nicht jeder Techniker muss Middleware-Architektur im Detail verstehen. Aber er sollte wissen, dass moderne Fahrzeuge Softwareabhängigkeiten haben. Er sollte verstehen, dass ein Fehler in einem Bereich sich an anderer Stelle zeigen kann. Und er sollte wissen, wann es sinnvoll ist, technische Unterstützung zu kontaktieren, bevor Bauteile ersetzt werden.
Das Fahrzeug verändert sich, die Werkstatt muss sich mitverändern
Software Defined Vehicle ist kein Marketingbegriff für Entwickler. Es ist ein Trend, der Schritt für Schritt in den Werkstattalltag kommt. Zuerst bei Premium- und Elektrofahrzeugen, später bei normalen Modellen. So wie Diagnose einst zum Standard wurde, wird auch der Umgang mit Software, Versionen, Autorisierungen und dem Online-Ökosystem des Fahrzeugs zum Standard werden.
Für Mechaniker ist das kein Grund zur Panik. Aber es ist ein Grund, anders zu denken. Ein moderner Fehler muss nicht wie ein defekter Sensor aussehen. Er kann ein unvollständiges Update, ein inaktiver Dienst, eine geänderte Konfiguration oder eine blockierte Funktion sein.