„Wenn wir das schaffen, ist das eine Art Mondlandung“

Für Mercedes-Benz ist MB.OS, das im vergangenen Jahr im neuen CLA seine Premiere gefeiert hat, der neue Dreh- und Angelpunkt in der softwarebasierten Architektur aller kommenden Fahrzeuggenerationen. Das schlagende Herz, das den Takt für all das vorgibt, was den Schwaben für neue digitale Geschäftsmodelle in Zukunft so vorschwebt.Aber MB.OS ist weder einfach nur ein weiteres neues Betriebssystem noch fiel es im „Ländle“ einfach so vom Himmel. Das System stellt die komplette Logik der Fahrzeugsoftware sowie dessen Genese auf den Kopf. 

Im Interview mit automotiveIT erklären Matthias Schneider, Vice President IT RD & Procurement, und Martin Haselbach, Director MB.OS Cloud, Data and SW Update & Diagnostics, warum die Zukunft des Autos im Code liegt – und weshalb dieser Wandel weit mehr erfordert als neue Tools. Sie sprechen über die Entkopplung von Hard- und Software, die steile Lernkurve hin zu iterativen OTA‑Updates, den Aufbau einer einheitlichen End‑to‑End‑Software‑Journey und die Bedeutung von Transparenz entlang der gesamten Wertschöpfung. Zudem erläutern sie, wie KI den Entwicklungsalltag revolutioniert, was „China Speed“ wirklich bedeutet – und warum die Transformation für Mercedes-Benz einer kleinen Mondlandung gleichkommt.

Wie weitreichend ist das Software-Update der neuen S-Klasse?

Mit der neuen S-Klasse modernisiert Mercedes-Benz sein Flaggschiff gezielt weiter. Kern der automobilen „Neuerfindung“ ist die Software. Welche digitalen Features wurden bereits angekündigt und wie weitreichend ist die Modernisierung am Ende tatsächlich?

Ronja Schmiedchen

Herr Schneider, Herr Haselbach, Mercedes-Benz spricht wie viele andere Hersteller davon, dass die Zukunft des Fahrzeugs im Code liegt. Was verstehen Sie operativ unter einem softwaredefinierten Fahrzeug?

Matthias Schneider: Für uns ist ein Software-defined Vehicle ein Fahrzeug, das nicht nur durch Softwarefunktionen geprägt ist, sondern sich über den gesamten Produktlebenszyklus weiterentwickelt und auf Kundenverhalten reagiert. Das heißt, wir lernen aus den Daten unserer Flotte, entwickeln das Produkt darüber weiter und halten es über den Lebenszyklus aktuell.

Martin Haselbach: Ergänzend dazu ist das Fahrzeug immer Teil eines digitalen Ökosystems. Die Integration von Diensten wie YouTube, Spotify oder Audible zeigt, dass wir das Produkt in einem größeren Gesamtkontext denken, von dem unsere Kunden unmittelbar profitieren.

Ihr großes Projekt der vergangenen Jahre war der Aufbau einer konsistenten Software Journey entlang der gesamten Wertschöpfung. Was war der konkrete Auslöser, der Sie erkennen ließ: Wir müssen Software bei Mercedes radikal neu denken?

Haselbach: Mercedes-Benz hat früh erkannt, dass sich wettbewerbsdifferenzierende Vorteile zunehmend über Software definieren. Deshalb wollen wir sie selbst entwickeln und zugleich die nötige Infrastruktur schaffen, um Software im Unternehmen grundsätzlich neu zu denken. Das betrifft nicht nur die Fahrzeugentwicklung, sondern auch Produktion und Aftersales. Software entkoppelt sich von der Hardware und reicht heute bis weit über das Werk hinaus. Als der Bedarf aus der Entwicklung heraus immer deutlicher wurde, war klar: Wir brauchen neue Tools, neue Prozesse und eine Infrastruktur, die schnelle, hochfrequente Entwicklung und das zuverlässige Ausrollen von Software überhaupt erst ermöglicht.

Schneider: Entscheidend war zudem, aus den klassischen Ressortgrenzen herauszutreten und die gesamte Kette über den Produktlebenszyklus hinweg zu betrachten. Unser Ziel war nicht, für Entwicklung, Produktion und Aftersales jeweils eigene Stacks und Update-Fähigkeiten aufzubauen, sondern möglichst eine durchgängige Toolchain aufzusetzen.

In welchem Bereich folgten die ersten Konsequenzen auf diese Erkenntnis: Technologie, Organisation oder Kultur?

Schneider: Es war gerade nicht die Organisationsdenke, weil sehr schnell deutlich wurde, dass wir entlang von Prozessen und Wertströmen denken müssen. Hinter der End-to-End Software Journey stehen verschiedene Teil-Abschnitte, die jeweils wertschöpfende Businessprozesse abbilden. Ein Beispiel ist die Fähigkeit, Fahrzeuge – auch in der Erprobungsflotte – OTA-updatefähig zu machen. Diese Prozesssicht war von Anfang an zentral: erst den Wertstrom verstehen, dann die richtigen Menschen aus der Organisation zusammenbringen, um ihn gezielt zu verbessern.

„Wir haben Software als Produkt bei Mercedes etabliert“

Seit Jahren arbeitet Mercedes am MB.OS. Nun steht der vollumfängliche Rollout kurz bevor. Im Interview spricht Software-Chef Magnus Östberg über den aktuellen Stand, die Bedeutung von OTA-Updates und die zunehmende Trennung von Software und Hardware.

Haselbach: Dazu kamen bewusst ambitionierte Ziele. Wir haben früh gesagt: Hardware und Software werden künftig entkoppelt sein, um Software schneller denken zu können. Allein dieser Anspruch war disruptiv. Uns war wichtig, Ziele zu formulieren, bei denen allen klar ist: Wenn wir das schaffen, ist das nicht nur eine evolutionäre Verbesserung, sondern eine Art persönliche Mondlandung.

Die Entkopplung von Hard- und Software galt also als Schlüssel. Wo lagen dabei die größten Hürden?

Haselbach: Je weiter ein Ziel in die Zukunft reicht, desto disruptiver wirkt es zunächst. Entsprechend gab es durchaus Diskussionen darüber, ob das überhaupt realistisch ist. Operativ haben wir deshalb mit Zwischenzielen gearbeitet. Wenn das große Ziel darin besteht, ein Fahrzeug innerhalb von drei Monaten per OTA von der Idee bis zum Rollout eines Features zu aktualisieren, dann hilft es, zunächst mit sechs Monaten zu beginnen. Solche Zwischenschritte machen ambitionierte Ziele greifbar.

Wenn Sie mal die damalige Vision von der „MB.OS End-2-End Software Journey“ mit der Realität abgleichen: Welche Annahmen haben sich bestätigt, welche mussten Sie korrigieren?

Haselbach: Bestätigt hat sich vor allem die Entkopplung von Hardware und Software. Der Ansatz, dass die Software dann im Werk oder per Update aufgespielt wird, ist aus unserer Sicht der richtige Weg. Als grundsätzlich falsch würde ich keine unserer Annahmen bezeichnen. Was sich allerdings noch stärker entwickelt hat als anfangs gedacht, ist die Update-Frequenz. Ursprünglich war unser Ziel, alle drei Monate Updates zum Kunden zu bringen. Dann haben wir gesehen, dass andere Player noch deutlich schneller agieren. Entsprechend hat sich der Trend zu iterativen Releases weiter verschärft.

Schneider: Bestätigt hat sich auch unser Leitgedanke „We are the architects“. Wir wollen die Hoheit über die Architektur behalten – im Fahrzeug, in der Infrastruktur und im Tooling. In diesen Schlüsselfunktionen dürfen wir nicht von einzelnen Vendoren abhängig sein. Mit der End-to-End Software Journey haben wir den Anspruch, dass diese Architekturkompetenz im eigenen Haus liegt.

Die Fahrzeugarchitekturen waren vor zehn Jahren noch deutlich anders aufgestellt als heute. Wie schwierig war es damals, gewachsene Strukturen aufzubrechen und die relevanten Partner und Stakeholder für diesen Weg mitzunehmen?

Schneider: Das war mit Blick auf lange gewachsene Strukturen kein einfacher Schritt, und an manchen Stellen ist das noch heute herausfordernd. Gleichzeitig haben viele Partner verstanden, dass es am Ende ein Teamsport ist. Wenn wir die besten Lösungen für unsere Kunden schaffen wollen, müssen wir die jeweils besten Partner für bestimmte Themen auswählen können und zugleich in der Lage sein, über Updates schnell zu reagieren. Das erhöht die Kundenzufriedenheit und davon profitieren am Ende alle Beteiligten. Insofern war es auch ein Mindset-Thema. Wir haben dafür ein gutes Setup mit Partnern gefunden, die diesen Weg mitgehen.

Was verändert sich für einen OEM, wenn er die Verantwortung über die gesamte Softwarekette übernimmt?

Schneider: Eigentlich lag diese immer beim OEM. Unsere Marke und unser Produkt müssen den Kundenansprüchen gerecht werden. Neu ist, dass wir in einem vernetzten Ende-zu-Ende-System sicherstellen müssen, dass die gesamte Kette funktioniert. Ein Update muss vom Anfang bis zum Ende zuverlässig laufen. Das heißt: Wir wollen verstehen, was in der Kette passiert, wie die Tools ineinandergreifen, wo Probleme entstehen können und wie wir sie sichtbar machen. Genau dafür braucht es Transparenz und die passenden Dashboards.

Haselbach: Gleichzeitig verändert sich aber auch die Rolle der IT – sie rückt stärker in eine moderierende Funktion. In einem großen Unternehmen treffen naturgemäß zwischen Entwicklung, Produktion, Sales und Aftersales unterschiedliche Perspektiven aufeinander. Hier kann eine IT helfen, die Sichtweisen zusammenzuführen.

Bleiben wir beim Partnerökosystem: Welche Rolle spielen Open Source und offene Strukturen wie die Gemeinschaftsinitiative S-CORE?

Haselbach: Open Source ist für uns sehr relevant. Entscheidend ist immer die Frage: Wo differenzieren wir uns wirklich im Wettbewerb? Dort müssen wir unsere Kraft und unsere eigenen USPs einsetzen. In anderen Bereichen wiederum greifen wir bewusst auf Open-Source-Komponenten zurück. Ein Beispiel ist S-Core im Umfeld der Fahrzeugdiagnose. Dort sehen wir Potenzial für Re-Use und Standardisierung. Das gilt ebenso für klassische Entwicklungskomponenten wie Logging-Lösungen. Solche Bausteine entwickeln wir nicht selbst neu. Gleichzeitig konsumieren wir nicht nur Open Source, sondern bringen uns auch in Communities ein und tragen Beiträge zurück. Im IT- und Tooling-Umfeld ist Open Source ohnehin unverzichtbar.

„Mit dem OEM-Commitment ist echtes Momentum entstanden“

Eclipse S-CORE soll als Open-Source-Stack zur gemeinsamen Basis für softwaredefinierte Fahrzeuge werden. Ansgar Lindwedel von der Eclipse Foundation erklärt, warum „Code first“ ein Booster für die Entwicklung ist und warum die globale SDV-Bewegung jetzt Fahrt aufnimmt.

Ronja Schmiedchen

Beim Thema OTA-Updates fällt oft das Stichwort „China Speed“. Wie lässt sich dieses Tempo halten – und weiter steigern?

Haselbach: Entscheidend sind Disziplin und Standardisierung – und das heißt: eine Toolchain statt Toolchaos. Das beschleunigt enorm. Disziplin heißt: Wir arbeiten in einem festen Takt. Unsere Release-Züge fahren in definierten Zyklen ab. Wenn etwas nicht rechtzeitig fertig wird, halten wir diesen Zug nicht auf, um den Rhythmus zu halten. Dieses Flow-Mindset ist zentral. Dann verschiebt sich ein Feature eben in den nächsten Takt. Wir wollen nicht zwangsläufig immer häufiger ausrollen, aber wir wollen die Fähigkeit haben, bei Bedarf auch schneller als im Drei-Monats-Rhythmus zu reagieren.

Bremsen Sicherheits- und Zertifizierungsanforderungen dieses Tempo noch aus?

Haselbach: Nein, sie sind heute integraler Bestandteil der Toolchain. Prozesse, die früher zum Teil manuell waren, sind inzwischen weitgehend automatisiert. Genau das ist ein Mehrwert für die Entwickler: Regulatorik und Geschwindigkeit wirken nicht mehr gegeneinander, weil die Absicherung in den Entwicklungs- und Release-Prozess eingebettet ist.

Wenn wir auf die Chip-to-Cloud-Infrastruktur schauen: Wo lagen dort die größten Herausforderungen?

Schneider: Ene wesentliche Herausforderung war es, die Entkopplung von Software und Hardware wirklich konsequent durchzuhalten. Wir wollten Software unabhängig von der zugrunde liegenden Infrastruktur bereitstellen. Dass unsere Deployments im Markt heute performant funktionieren, ist das Ergebnis konsequenter Absicherung. Die Lösung musste nicht nur beim Kunden, sondern auch im Werk zuverlässig funktionieren, wo Updates in laufende Produktionsabläufe integriert werden. Dort ist intensive Entwicklungs- und Absicherungsarbeit eingeflossen.

Haselbach: Rückblickend waren die größeren Hürden eher in der Abstimmung unserer organisatorischen und prozessualen Rahmenbedingungen. Wir haben einen einheitlichen MB.OS-Releasetakt über alle Werke und mehrere Ressorts hinweg eingeführt. Alle Beteiligten in diesen gemeinsamen Takt zu bringen, war anspruchsvoller als die technologische Umsetzung selbst. Letztlich ging es darum, Arbeitsweisen zu wandeln, aber genau darin lag auch der Hebel.

Wo war dieser Wandel der Arbeitsweisen am stärksten spürbar? Eine Produktion beispielsweise arbeitet bekanntlich nach anderen Maßstäben.

Haselbach: Natürlich war das zunächst ein naheliegender Gedanke. Eine Produktion setzt auf Stabilität und Flexibilität. Aber eine Produktion sieht auch den Vorteil einer Software Journey, wenn es einmal ein Problem gibt und schnell eine Lösung geliefert werden kann. Wenn ein Fehler eingetreten ist, konnten wir viel schneller als früher helfen und dadurch auch wieder intern Akzeptanz erzeugen. Es war immer unsere Aufgabe, die Software-Journey zu erklären, auch wenn damit erst einmal eine Veränderung einherging. Diese Neuerungen haben dann typischerweise auch die Mitarbeitenden überzeugt, selbst etwas zu verändern und zu optimieren. Am Ende haben sie den Vorteil selbst gespürt.

Wie fließen Rückmeldungen aus Produktion und Kundennutzung in die laufende Optimierung ein?

Schneider: Mit der Software Journey haben wir erstmals die Möglichkeit, entlang der gesamten Prozesskette systematisch Datenpunkte zu erfassen. Wir sehen Erfolgsquoten, erkennen Bottlenecks und können gezielt gegensteuern. Diese Transparenz stellen wir Entwicklung, Produktion und Aftersales gleichermaßen zur Verfügung. Hinzu kommt die Cloud-Infrastruktur, über die wir Daten aus dem Feld zusammenführen können: Wie werden Funktionen genutzt? Wie gut werden Updates angenommen? Damit schließen wir sowohl den Feedback-Loop im Prozess als auch den zum Kunden deutlich besser als früher und können Daten aus dem Feld sehr viel besser für die Weiterentwicklung und Optimierung nutzen.

Sie haben beide den Wandel der Rollen zwischen IT und Entwicklung erlebt. Warum war dieser Perspektivwechsel notwendig?

Haselbach: Matthias und ich hatten auch vor unseren heutigen Rollen bereits Berührungspunkte, allerdings jeweils aus unseren ursprünglichen Funktionen heraus – er aus der Entwicklung, ich aus der IT. Als klar wurde, dass dieses Projekt Realität werden würde, war ebenso klar, dass punktuelle Zusammenarbeit nicht ausreichen würde. Es ging darum, in die jeweils andere Organisation hineinzugehen, von innen heraus zu wirken und zugleich die Stärken der jeweiligen Domäne besser zu verstehen. Genau deshalb haben wir Rollen gewechselt.

Schneider: Es ging sogar um mehr als um einen reinen Rollenwechsel. Entscheidend war Co-Creation. Doppelte Berichtslinien und Dual Roles haben geholfen, diese Brücke kürzer zu machen und aus klassischen Zuständigkeiten herauszukommen.

IT und Engineering müssen dieselbe Sprache sprechen

Entwicklung und IT müssen beim software-definierten Fahrzeug so stark wie nie zusammenarbeiten. Genauso zählen externe Partner und deren Knowhow zu den wichtigen Aspekten, betonen Experten auf dem automotiveIT car.summit.

Götz Fuchslocher

Wer musste sich wem stärker annähern – IT der Entwicklung oder vice versa?

Schneider: Solche Veränderungen funktionieren nur, wenn beide aufeinander zugehen. Perspektivwechsel helfen dabei, die Anforderungen und Herausforderungen des jeweils anderen zu verstehen. Es ist deshalb keine Frage von drei Schritten auf der einen und einem auf der anderen Seite, sondern eine situative Entscheidung. Kurz vor einem Anlauf etwa, als es stark um Stabilität der Toolchain ging, waren klassische IT-Tugenden besonders gefragt: Robustheit, Lastfähigkeit, Hochverfügbarkeit. In anderen Phasen stehen andere Prioritäten im Vordergrund. Genau dieses situative Verständnis ist entscheidend.

Oft heißt es, IT bleibe trotz ihrer Softwarenähe stärker in bestehenden Prozessen verhaftet, auch weil sie Infrastruktur sichern und den Betrieb stabil halten muss. War das bei Ihnen ähnlich?

Schneider: Ich würde das nicht in „alt“ und „neu“ einteilen. Es gibt bestimmte Tugenden, die heute genauso relevant sind wie früher. Bei uns läuft das unter dem Begriff „Rock Solid Operation“. Ein stabiler Betrieb ist nichts Veraltetes, sondern absolut zentral – in der Produktion, im Werk und im Aftersales. Die höchsten Anforderungen an Verfügbarkeit kamen bei uns sogar aus dem Aftersales. Dort war klar: Wenn die Toolchain steht, kann das weltweit Auswirkungen auf die Werkstätten haben. Das zeigt, wie zentral diese Perspektive ist. Umgekehrt hat die IT viel stärker verstanden, welche Anforderungen von der Fahrzeug- und Architekturseite kommen. Ich würde daher eher von gewachsener gegenseitiger Wertschätzung sprechen.

Für Entwickler gilt heute oft das Prinzip „You build it, you run it“. Wie schwierig war es, dieses Verantwortungsverständnis zu verankern?

Haselbach: Rückblickend haben wir gelernt: Die Entwickler wollten das eigentlich schon lange, ihnen fehlten nur die richtigen Werkzeuge. Früher waren die Toolchains stark in Silos organisiert. Heute können Entwickler über Dashboards live in die Systeme schauen, Downloadraten verfolgen und direkt sehen, wie sich ihre Software im Feld verhält. Dadurch ist das Interesse sofort gestiegen. Es lag also nicht am Wollen, sondern an den fehlenden Möglichkeiten. Sobald eine zentrale Toolchain und eine durchgängige Infrastruktur vorhanden sind, greifen Entwickler das sehr schnell auf.

Stichwort KI: Manche haben sich gedanklich schon vom Software-defined Vehicle verabschiedet und reden nun dem „AIDV“ das Wort. Für sie die logische Konsequenz oder doch eher noch Buzzword-Bingo?

Schneider: Ich bin überzeugt, dass KI alle Phasen des Produktentstehungsprozesses, des gesamten Lifecycles und letztlich auch das Produkt selbst tiefgreifend verändern wird – nicht nur evolutionär, sondern in vielen Bereichen revolutionär. Mit welcher Geschwindigkeit sich KI derzeit entlang des Software-Lifecycles entwickelt, ist bemerkenswert. Gleichzeitig stehen wir aus meiner Sicht erst am Anfang dessen, was möglich ist. Gerade auch im klassischen Engineering werden wir den Einsatz von KI-Tools künftig deutlich stärker sehen. Das beginnt bereits bei der Erstellung von Spezifikationen und Lastenheften, die heute noch vielfach manuell erarbeitet werden. Neue Tools unterstützen dabei, nehmen Arbeit ab und können auf dieser Basis sogar direkt Testfälle ableiten oder Hinweise zur Absicherung geben. Erste Lösungen dafür sind bereits im Einsatz – und ich glaube, das ist erst der Anfang. Das Potenzial reicht dabei weit über die Dokumentation hinaus: von der Erstellung technischer Unterlagen über Qualitätssicherung bis hin zur automatisierten Prüfung von Code und Spezifikationen. Ein KI-Agent kann schon heute unterstützend mitlaufen und kontrollieren, ob Code oder Anforderungen stimmig sind. Darin liegt nicht nur ein großer Effizienzgewinn, sondern auch ein wichtiger Impuls für ein noch höheres Qualitätsniveau.

Haselbach: Wir bewegen uns derzeit vom Copilot-Zeitalter in ein Agenten-Zeitalter. Während Copiloten bislang vor allem unterstützt haben, können unterschiedliche Agenten mittlerweile konkrete Aufgaben übernehmen. Damit verändert sich auch der Arbeitsalltag unserer Teams. Die eigentliche Herausforderung wird vor allem darin liegen, wie anpassungsfähig Unternehmen sind und wie schnell sie lernen, mit dieser neuen Dynamik Schritt zu halten und sie für sich zu nutzen.

Wenn künftig Entwickler und KI-Agenten gemeinsam arbeiten: Wie schafft man Akzeptanz statt Angst vor Verdrängung?

Haselbach: Mir ist wichtig, dass KI unsere Mitarbeitenden besser macht. Die Teams sind in diese Veränderung eingebunden. Gerade Aufgaben, die eher routiniert oder wenig attraktiv sind, lassen sich sinnvoll an KI delegieren. Das erhöht nicht nur die Effizienz, sondern oft auch die Qualität – etwa bei Testabdeckung oder Prüfungsschritten. Entscheidend ist aber: KI übernimmt nicht alles. Wir bewegen uns in einem hochregulierten Umfeld. Deshalb wird der Mensch immer eine Review- und Kontrollfunktion behalten. Bevor bei uns ein Commit erfolgt, schaut weiterhin ein Mensch darauf. Das wird auch so bleiben, weil wir verstehen müssen, was die KI mit unserem Code macht. Es wird zudem weiterhin Menschen geben, die selbst manuell entwickeln, allein damit wir verstehen, wie sich unser Code durch die AI weiterentwickelt und verändert. Genau diese Kombination schafft Akzeptanz: KI als Unterstützung, nicht als Gegenspieler.

Zuletzt ein Blick in die Zukunft: Wie werden sich Software-Releasezyklen in drei bis fünf Jahren verändern?

Haselbach: Der Kern der Software Journey wird bestehen bleiben. Die Trennung von Hard- und Software sowie das 24-3-Prinzip werden weiterhin tragende Elemente sein. Gleichzeitig wird KI überall Einzug halten. Wo heute noch manuell dokumentiert wird, wird KI auf Basis vorhandener Daten künftig Vorschläge generieren und Prozesse beschleunigen. Deshalb wird die Geschwindigkeit weiter deutlich steigen. Wir können den Zwei-Wochen-Takt, vielleicht sogar einen Zwei-Tages-Takt ermöglichen, wenn wir den in kritischen Fällen brauchen. Gleichzeitig werden Kernfundamente und Prinzipien ihre Gültigkeit behalten.

Schneider: Mit der Software Journey und der Toolchain haben wir uns ein zentrales Asset geschaffen, das diese Beschleunigung überhaupt erst ermöglicht. KI braucht Daten – und genau diese Daten stehen uns durch die durchgängige Toolchain zur Verfügung. Weil wir sowohl die Toolchain als auch die Architekturkompetenz im eigenen Haus haben, können wir Prozessschritte viel leichter automatisieren, als es in einer fragmentierten Systemlandschaft möglich wäre. Damit haben wir eine starke Ausgangsbasis geschaffen, um künftig noch engere Releasezyklen zu realisieren. Am Ende wird aber der Kunde den Takt vorgeben.

Das Interview führten: Ronja Schmiedchen und Yannick Tiedemann.