Was ist ein Software-Defined Vehicle (SDV)?
Was ist ein Software-Defined Vehicle? Ein Software-Defined Vehicle (SDV) ist ein Auto, dessen Funktionen und Weiterentwicklung vor allem durch Software auf gemeinsamen Rechnerplattformen mit stabilen Hardwareschnittstellen bestimmt werden. Zentrale oder zonale Rechner, dienstorientierte Software und kontrollierte Over-the-Air-Updates sind typische Bausteine. Konnektivität allein macht noch kein SDV, sicherheitskritisches Fahren muss auch offline funktionieren.
Wofür steht SDV im Automobil?
SDV steht für Software-Defined Vehicle. Die brauchbare Definition beschreibt die Architektur: Stabile Schnittstellen trennen Software von einzelnen Hardwareboxen, wichtige Funktionen laufen auf gemeinsamen Rechnerplattformen, und der Hersteller verwaltet die Software über das Fahrzeugleben. Ein Over-the-Air-Update ist eine Fähigkeit des SDV, aber allein noch kein Beleg für ein software-definiertes Auto.
Was macht ein Auto softwaredefiniert?
Vier Eigenschaften trennen ein SDV vom bloß vernetzten Auto. Fahrzeugfunktionen entstehen als Softwareprodukte, Rechner und Netzwerke tragen mehrere Funktionen, Schnittstellen verringern die Hardwareabhängigkeit, und ein kontrolliertes Updatesystem hält die Flotte aktuell. Die Verbindung hilft bei Updates und Telemetrie. Lenken, Bremsen und Insassenschutz müssen jedoch auch ohne Mobilfunk funktionieren.
| Fahrzeugtyp | Rolle der Software | Verbesserung nach Verkauf |
|---|---|---|
| Traditionelles verteiltes Auto | Funktion hängt an eigenem Steuergerät und Lieferantenpaket | Meist nur per Werkstatt-Flash |
| Vernetztes Auto | Cloud-Dienste ergänzen weitgehend feste Fahrzeugfunktionen | Einige Apps und Karten |
| Software-Defined Vehicle | Funktionen laufen auf kontrollierten Plattformen mit stabilen Schnittstellen | Breitere, abgesicherte Funktions- und Plattformupdates |
Die SDV-Plattform: Hardware, Middleware und Dienste
Zur Hardware gehören Sensoren, Aktoren, Zonensteuergeräte und Zentralrechner. Plattformsoftware übernimmt Betriebssysteme, Diagnose, Cybersicherheit, Kommunikation und Update-Steuerung. Fahrzeugfunktionen nutzen Dienste und APIs, statt jedes Gerät direkt anzusprechen. AUTOSAR Classic bleibt für eingebettete Echtzeitregelung wichtig, Adaptive und andere POSIX-Umgebungen tragen leistungsstärkere Anwendungen.
Drei Tests für ein echtes SDV
Der erste Test ist Übertragbarkeit. Kann ein Team eine Funktion auf die nächste Generation des Fahrzeugrechners verschieben und den Großteil des Anwendungscodes weiterverwenden? Oder beginnt die Arbeit neu, weil jeder Sensor und Aktor eine proprietäre Schnittstelle hat? Der zweite Test ist Release-Unabhängigkeit. Lässt sich Software kontrolliert testen, signieren und ausrollen, ohne den gesamten elektrischen Entwurf wieder zu öffnen? Der dritte Test ist Flottenkontrolle. Kennt der Hersteller die genaue Hardware- und Softwarekombination jedes Autos, kann er ein unpassendes Paket ablehnen und ein unterbrochenes Update wiederherstellen?
Diese Fragen sind strenger als der Blick auf neue Symbole im Infotainment. Sie zeigen, ob Software wirklich von Hardware getrennt und als eigenes Engineering-Produkt geführt wird. Ein Auto kann eindrucksvolle OTA-Updates erhalten und trotzdem aus vielen isolierten Lieferanten-Stacks bestehen, die weder Daten noch Release-Zyklen teilen.
SDV vs. vernetztes Auto
Ein vernetztes Auto tauscht Daten mit Telefonen oder Cloud-Diensten aus. Ein SDV verändert die Entwicklung des Fahrzeugs selbst. Ein Auto kann Musik und Verkehrsdaten streamen und trotzdem je Funktion ein starres Steuergerät haben. Umgekehrt dürfen die sicherheitskritischen Funktionen eines SDV keine dauerhafte 5G-Verbindung verlangen. Gute Programme verbinden beides, die Begriffe sind aber keine Synonyme.
Wie ein Softwareupdate wirklich ins Auto gelangt
Ein Serienupdate ist eine kontrollierte technische Änderung an einer ganzen Flotte. Das Backend wählt geeignete Fahrzeuge nach Hardware, Region und aktuellem Softwarestand aus. Vor der Installation prüft das Auto Signatur, Kompatibilität, Speicher und Energiezustand. Bei sicherheitsrelevanten Steuergeräten muss das Fahrzeug möglicherweise geparkt und fahrunfähig sein. Nach der Installation prüft das System die neue Software und meldet Belege an das Flotten-Backend zurück. Für ein gescheitertes Update braucht es einen festgelegten Wiederherstellungsweg, je nach Steuergerät etwa eine frühere Softwarepartition, ein Recovery-Image oder einen Werkstattprozess.
Der OTA-Knopf ist deshalb nur die sichtbare Spitze eines großen Systems. Die UN-Regelung Nr. 156 verlangt ein Software Update Management System und Nachweise zu Versionsstand, Kompatibilität, sicherer Durchführung und Wiederherstellung nach einem Fehler. Sie schreibt keinen bestimmten Cloud-Stack vor. Sie zwingt den Hersteller, die Änderung zu beherrschen.
Rechner mit gemischter Kritikalität sind die harte Aufgabe
Ein Zentralrechner kann Navigation, Fahrerbeobachtung und Funktionen des automatisierten Fahrens tragen. Diese Programme dürfen aber nicht dieselben Rechte haben. Ein eingefrorener Mediendienst darf einer bremsrelevanten Funktion weder Prozessorzeit noch Speicherbandbreite nehmen. Serienarchitekturen nutzen deshalb Hardware- und Softwarepartitionierung, Watchdogs, Zugriffskontrolle und unabhängige Sicherheitsmechanismen. Tief eingebettete Steuergeräte bleiben für Aufgaben sinnvoll, die deterministisches Timing und sehr kleine Fehlerbereiche brauchen.
In der Praxis lautet die Architektur selten „ein Rechner steuert das ganze Auto“. Sie ist eine Hierarchie aus Zentralrechnern für schwere, fahrzeugweite Funktionen, Zonensteuergeräten für lokale Anschlüsse und Strom sowie eigenen Controllern, wo Timing, Sicherheit oder Kosten sie rechtfertigen. Deshalb existieren CAN, LIN und Automotive Ethernet weiter nebeneinander.
Vorteile und technische Risiken
Eine gemeinsame Plattform kann doppelte Hardware vermeiden, Software über Modelle wiederverwenden, Releases beschleunigen und manche Fehler ohne Werkstatt beheben. Die Bündelung vergrößert zugleich die Wirkung eines Softwarefehlers. Hersteller brauchen Konfigurationskontrolle, Rückfallversionen, Cybersicherheit, funktionale Trennung und lange Supportzeiträume. Softwarewiederverwendung hat außerdem eine Bedingung: Plattform und Schnittstellen müssen stabil bleiben. Wenn jedes Modell die Middleware abspaltet, wird aus dem versprochenen Skaleneffekt ein größeres Wartungsproblem. Abo-Umsatz ist möglich, aber ein Geschäftsmodell und keine technische Voraussetzung.
Die Systeme hinter dem Softwareauto
Die zonale E/E-Architektur liefert Rechner und Netzwerke, Nvidia Automotive ist ein möglicher Compute-Stack, und der Fahrzeugentwicklungsprozess kontrolliert Hardware- und Softwarefreigaben. Die mechanische Grundlage erklärt wie ein Auto funktioniert.
Am klarsten wird die Release-Kette, wenn Software die Verantwortung verändert. Vergleiche Level 2 mit Level 3 und ordne beide in die SAE-Stufen L0-L5 ein. Für die Serienabsicherung führt der Weg zu APQP und PPAP, für das Gesamtbild zum Automobiltechnik-Hub.
Primärquellen, geprüft am 24. Juli 2026: Die AUTOSAR Adaptive Platform dokumentiert ihre dienstorientierten Functional Clusters. COVESAs SDV-Definitionsarbeit beschreibt Software, Schnittstellen und Ökosystem statt bloßer Konnektivität. Die offizielle Seite zur UN-Regelung Nr. 156 behandelt Software Update Management Systeme.
Tesla ist das klarste Serienbeispiel. Unsere Analyse zu Tesla als Software-Defined Vehicle trennt öffentliche Architekturbelege, OTA-Verhalten und Hardwaregrenzen.
Ein SDV braucht ein Netz für harte Echtzeitsignale und Softwaredienste. Sieh dir an, wie CAN, LIN und Automotive Ethernet in einem zonalen Fahrzeug zusammenarbeiten.
Software-Defined Vehicles: häufige Fragen
Was bedeutet SDV im Automobil?
SDV bedeutet Software-Defined Vehicle, also ein Auto, dessen Funktionen und Lebenszyklus hauptsächlich durch Software auf gemeinsamen, aktualisierbaren Rechnerplattformen bestimmt werden.
Was ist eine SDV-Plattform?
Sie verbindet Fahrzeugrechner, Netzwerke, Betriebssysteme, Middleware, APIs, Updatesysteme und Entwicklungswerkzeuge, auf denen Fahrzeugfunktionen laufen.
Wie unterscheidet sich ein SDV vom vernetzten Auto?
Ein vernetztes Auto tauscht Daten mit externen Diensten aus. Ein SDV verändert die interne Architektur, damit Funktionen als Software entwickelt, verteilt und gepflegt werden. Ein Auto kann das eine sein, ohne das andere vollständig zu erfüllen.
Macht ein Over-the-Air-Update ein Auto zum SDV?
Nein. OTA ist nur eine Fähigkeit. Ein SDV braucht zusätzlich kontrollierte Plattformen, stabile Hardwareschnittstellen, Lebenszyklusverwaltung und wiederverwendbare Software.
Welche Vorteile hat ein Software-Defined Vehicle?
Möglich sind mehr Softwarewiederverwendung, weniger doppelte Steuergeräte, schnellere Fehlerbehebung und Funktionen, gemeinsame Plattformen über Modelle sowie bessere Diagnose.
Welche Risiken hat ein SDV?
Zentralisierung kann die Wirkung eines Fehlers vergrößern. Cybersicherheit, funktionale Trennung, Konfigurationskontrolle, Rückfallversionen und langfristiger Softwaresupport sind entscheidend.
