S D V
Software-Defined Vehicle
Autor: L. Preußer, erstellt: 17-Nov-2025 Erstmals vorgetragen im Engineering Forum der IG Metall
Navigation
Durchblättern der Folien per Pfeiltaste ⬅️➡️
Kurzfassung der "Tonspur" als Text mit ⬆️⬇️
Test: ⬇️ drücken
Bravo 🥳
Auf solchen Zwischenfolien sind Begleittexte und Kontext zu finden.
Weiter geht's mit ➡️
Es ist 1990 und wir entwickeln ein Auto.
Was ist wichtig?
Kontext
Der Fahrer-Airbag ist teure Sonderausstattung.
Katalysatoren sind gerade Pflicht geworden.
ABS gibt es serienmäßig erst in der Oberklasse.
Euro NCAP (die mit den 💥🚗) gibt es noch nicht.
Es ist 1990 und wir entwickeln ein Auto.
Was ist wichtig?
Es soll fahren. Zuverlässig.
Schattenfugen, klare Linien, Falze.
Es muss hohe passive Sicherheit bieten.
Große Auswahl bei Motoren und Getrieben.
Wir brauchen 101215 Jahre Garantie auf Durchrostung!
Es ist 2020 und wir entwickeln ein Auto.
Was ist wichtig?
Kontext
Alles hat ein Steuergerät. [1]
Ohne ACC/AEB/LKA/CDP/CTA weniger ⭐⭐⭐.
Keiner nutzt On-Board Navs: 📱 ist schlicht besser.
Nr1-Problem der Pannenstatistik: Elektrik [2]
Akronyme, Sammelbezeichnung "Active Safety"
ACC = Adaptive Cruise Control Abstandstempomat. Nutzt Kamera/Radar/Lidar zur Regelung.
AEB = Autonomous Emergency Braking Notbremsassistent. Wenn ACC nicht ausreicht.
LKA = Lane Keeping Aid Spurhalteassistent. Nutzt Kameras, wirkt auf das Lenksystem.
CDP = Cyclist Dooring Prevention Warnsystem vor Türöffnung bei herannahenden Fahrrädern.
CTA = Cross Traffic Alert Querverkehrwarnung (mit Bremseingriff), Kamera/Radar.
Es ist 2020 und wir entwickeln ein Auto.
Was ist wichtig?
Wir brauchen gute Fahrerassistenzsysteme (ADAS).
Internetverbindung und ständige Updates (OTA).
Irgendwas mit Elektromotor (BEV).
Nahtlose Handy-Integration.
Wir müssen die Komplexität beherrschen!Zuverlässig.
Vergleiche 1990 mit 2020
Wo ist der Unterschied?
Software überall.
verteilt.
vernetzt.
Problem
Software ist kein Teil.
Software ist anders.
Software ist anders.
Hier will ich darauf hinaus, dass Software Information und kein Material ist. Sie lässt sich kopieren, umschreiben und anders als bei Teilen kann man Bearbeitung rückgängig machen.
Bei Teilen aus Materie geht das physikalisch nicht! (Stichwort Entropie)
Darüber hinaus beherrschen wir Menschen Software einfach nicht so gut.
Warum sonst braucht sie ständig Updates?
Fehlerfreiheit lässt sich nicht beweisen, selten genommene Ausführungspfade bleiben trotz Qualitätssicherung oft unzureichend validiert und Randbedingungen wenig untersucht.
Bei Software-Defined Vehicles ist die Fernwartbarkeit daher nicht hinreichend, sondern notwendig.
Software definiert Funktion
Fahrzeugentwicklung 2020 ohne SDV
Beispiel: verteiltes System
"Adaptive Cruise Control"
| Wir brauchen einen Sensor, der die Umgebung erfasst. |
| Ein Rechner muss Objekterkennung machen, Abstände und Trajektorien erfassen. |
| Wir brauchen Bedienelemente und visuelle Rückmeldung. |
| Der Antriebsstrang muss Zielgeschwindigkeiten einregeln. |
| Wir müssen beim Bremsregler eine Verzögerung anfragen können. |
🤔 Moment mal
Warum arbeiten wir mit Geschwindigkeit und Beschleunigung?
Weil es "Legacy" gibt!
Kontext
ACC entwickelte sich aus dem klassischen Tempomaten (CruiseControl).
Der arbeitet halt mit Fahrer-Wunsch-Geschwindigkeit.
Man hat dann ACC oben drauf gesetzt. Logisch. Abwärtskompatibel.
Beim Bremsen ist "mach' mal 50km/h" unzureichend.
Mehr Kontext 🤓
Während die ersten Tempomaten das Gaspedal mit vom Ansaugtrakt erzeugtem Unterdruck in der gewünschten Stellung festsetzten und damit annähernd konstante Leistung bereitstellten, geben modernere Systeme nur die Geschwindigkeit vor und das Motorsteuergerät regelt den Rest.
Man hatte nun also schon einen Geschwindigkeitregler im Antriebstrang.
Bei der Bremse sah das anders aus. Dort gab es nur ABS und später ESP, welche die Bremskraftverteilung auf einzelne Räder regeln und dafür auf keine externen Stellgrößen angewiesen waren.
Für ACC musste man Verzögerungsanfragen im Bremsensteuergerät verarbeiten können und daher zusätzlich einen Bremsregler entwickeln.
Feststellungen
- Komponente hält eigene Rechenleistung vor
- Komponente optimiert für spezielle Teilaufgabe
- Erweiterbarkeit = "Komponente hinzufügen"
- Fehlerbehebung = "Komponente austauschen"
- Funktionsupdate = "Koordiniertes Update für alle"
(Beim Händler oder in der Werkstatt)
Fahrzeugentwicklung 2020 mit SDV
Beispiel: verteiltes System
"Adaptive Cruise Control"
Regeln für SDV
(vereinfacht)
Ein Zentralrechner für alle Funktionen.
Weniger Verdrahtung: Nur 🗲 "Power" und 🖧 "Ethernet".
Sensoren, Aktoren, Eingabegeräte: Keine Logik, nur Signalverarbeitung.
Es gibt nur einen Längsregler.
Es gibt nur einen Querregler.
Funktionen werden miteinander verschmolzen.
Kontext
Tatsächlich kann man viele unabhängig voneinander entwickelte Funktionen zusammenlegen, wenn alle Sensoren und Aktuatoren durch einen Zentralrechner gesteuert werden.
Beispiel 1: Im Längsregler können ACC, AEB, (intelligente) Limiter, Querverkehrwarner, Rückfahrassistent etc. zusammengefasst und arbitriert werden
Beispiel 2: Im Querregler können ESP, Spurhalteassistent, Abbiegeassistent, Einparkassistent usw. zusammengefasst und arbitriert werden.
Dadurch ändert sich gegebenenfalls die Sichtweise auf eine Funktion. Ist es noch so wichtig, eine Geschwindigkeit exakt einzuregeln, wenn das System auch nach möglichst "sanfter" Fahrweise optimieren könnte?
Feststellungen
- Zentralrechner ist Universalcomputer
- Funktion hängt nicht mehr von Komponente ab
- Erweiterbarkeit = "Update per Fernwartung"
- Fehlerbehebung = "Update per Fernwartung"
- Funktionsupdate = "Update per Fernwartung"
Warum nicht gleich SDV?
SDV ist erst seit wenigen Jahren wegen stark gestiegener Rechenleistung überhaupt möglich.
Da SDV Fernwartbarkeit benötigen, ist Breitband-Netzausbau Grundvoraussetzung.
Erforderliche Sensorik und Aktuatorik ist erst seit Kurzem erschwinglich.
Warum Automobilkonzerne SDV wollen
🐙 Mehr Kundendaten!
🔧 Sinkende Garantiekosten!
🧪 Kürzere Entwicklungszeiten!
🐈🐈🐈 Mehr Gleichteile!*Stichwort Komplexität
📥 Software-Updates statt teurer Rückrufe!
💰 Abo-Modelle und zusätzliche Einnahmen!
Was "klassische" Autobauer an SDV doof finden
💸 Teurer: Stets Vollausstattung
💡 Dauert: Wissensaufbau erforderlich, Lernkurve
👨🏼⚖️ Verantwortlichkeit: Weniger beim Zulieferer, mehr Eigenentwicklung
🔀 Prioritäten: Was früher wichtig war ist nun Nebensache
Kontext
💸 Teurer: Da Funktionen nun auch noch nach Kauf entwickelt bzw. gebucht werden können, müssen die Fahrzeuge mehr Sensorik/Aktuatorik von Werk mitbringen.
💡 Dauert: Daten aus dem Feld laufen beim Hersteller massenweise erst nach Serienanlauf ein. Diese können somit erst spät zur Verbesserung der Funktion beitragen.
👨🏼⚖️ Verantwortlichkeit: Der Hersteller muss nun in Software-Plattform denken. Er muss eigene Funktionsentwicklung betreiben. Für diese ist er voll verantwortlich.
🔀 Prioritäten: Früher hatten Hersteller "das beste Licht", "das sportlichste Fahrwerk", "die klarsten Linien", "den laufruhigsten Motor". Jetzt zählen nur noch Funktion und Vernetzung.
Wenn SDV halbherzig entwickelt wird
| Szenario |
| Ein Autohersteller möchte "ab jetzt" SDVs entwickeln |
| Er stellt tausende Software-Entwickler ein |
| (denn Software soll in Zukunft ja das Geld verdienen) |
| Gleichzeitig muss er aktuelle Produkte weiter unterstützen |
| Und es wäre doch schade um die ganzen fertigen Spezifikationen! |
| Management bleibt nach Komponente sortiert: Fahrwerk, Karosserie, ADAS... |
| Budgets haben die Chefs der Fahrzeuglinie; Software-Plattform ist Dienstleister |
| Ergebnis: Fehleranfälliger, überkomplexer Moloch mit fragmentierter Architektur |
Warum so wenige traditionelle Autohersteller SDV vollständig umsetzen
Grund 1 🫏 Unternehmenskultur
Classic OEM: "Measure twice, cut once!"
SDV OEM: "Move fast & break things!"
Eine Veränderung der Unternehmenskultur ist schwierig und sehr langwierig.
Manchmal müssen bestehende Strukturen gar zerstört und anders wieder aufgebaut werden - bei laufendem Betrieb.
Weiterführende Literatur: Stichwort "Kulturmusteranalyse"
Grund 2 🧱 "Kamindenken"
Struktur erlaubt keine abteilungsübergreifende Zusammenarbeit.
Budgets werden pro Fahrzeugentwicklung und Abteilung verwaltet.
Alle optimieren lokal für ihre Bereiche.
Weiterführende Literatur: Stichwort "Silo Mentality"
Grund 3 🚩 falsche Ansätze & fehlende Fertigkeiten
Entwicklung und Fertigung werden als Kostenfaktoren betrachtet.
Manager verwalten Domänen.
Kaum Entscheidungshoheit auf technischer Ebene.
Software-Entwicklung als Dienstleistung.
Zu wenig Systemarchitektinnen, Entwickler...
Weiterführende Literatur: Stichwort "Conway's Law"
Grund 4 🐍 Kosten
Übernehmen scheint günstiger als neu denken.
(Alt-)Plattformen im Feld sind weiter zu pflegen.
Sparen unmöglich: Alle Entwicklungsbereiche bleiben erforderlich.
Also konzentriert man sich auf margenstarke Produkte.
Die sind höher im Markt platziert und man verliert Marktanteile.
Dadurch sinkt das Volumen und die Stückpreise steigen.
Weiterführende Literatur: Stichwort "The Innovator's Dilemma"
Halten wir fest ☝️
Die im Unternehmen agierenden Menschen sind weder blöd noch blind.
Niemand handelt bösartig oder irrational.
Alle Parteien erreichen die ihnen gesetzten Ziele.
Und trotzdem kommt trotz immer höherem Ressourcenaufwand kaum mehr etwas heraus.
Für Mitarbeitende im Betrieb fühlt sich eine solche Transformation mitunter an wie ein Zugunglück in Zeitlupe.
Fazit
Während einige Firmen wie Kodak und Nokia
in tiefe Krisen bis hin zur Zahlungsunfähigkeit rutschten,
konnten sich andere wie Microsoft unter Beibehaltung ähnlicher Produkte
am Markt behaupten.
Bleibt abzuwarten, wie sich "unsere" Autobauer
angesichts erstarkender Konkurrenz
im Wettbewerbsumfeld schlagen.
Mit genügend Innovationskraft,
Focus 🚗(kleiner Scherz)
und langem Atem
besteht noch Hoffnung.
🌈
Vielen Dank!
Fragen?
Hier der Link zur Präsentation.
Auf blog.schallbert.de befinden sich viele weitere interessante Artikel :)