Magnus Östberg, Mercedes-Benz

„Das SDV verändert die Kundenbeziehung erheblich“

Mercedes-Benz bringt das Software-Defined Vehicle aus der Entwicklungsschublade auf die Straße. Im Interview erklärt Chief Software Officer Magnus Östberg, warum nun Kundendaten, Open Source und KI-Agenten über den nächsten Reifegrad entscheiden.

7 min
automotiveIT hatte die Gelegenheit, am Rande des diesjährigen AUTOMOBIL-ELEKTRONIK Kongresses in Ludwigsburg mit Magnus Östberg zu sprechen.

Herr Östberg, in unseren vergangenen Gesprächen ging es stark um den Aufbau von MB.OS und um die Frage, wie Mercedes-Benz Software als Produkt etabliert. Ist die Aufbauphase beim Software-Defined Vehicle (SDV) inzwischen abgeschlossen? Beginnt jetzt die eigentliche Bewährungsprobe im Feld?

Ja, genau so ist es. Wir sind inzwischen mit unseren softwaredefinierten Fahrzeugen global im Feld. Das ist für uns eine enorm spannende Phase und natürlich auch eine große Freude, denn wir haben viele Jahre daran gearbeitet, diese Umstellung zu schaffen. Heute sprechen wir nicht mehr nur über ein einzelnes SDV, sondern über mehrere Baureihen, Aufbauformen, Antriebe und Marken. Ola Källenius hat das einmal sinngemäß als das größte „Rollout-Feuerwerk“ in der Geschichte von Mercedes-Benz beschrieben. Angefangen haben wir mit dem neuen CLA, selbstverständlich mit den batterieelektrischen Fahrzeugen. Inzwischen sind wir aber auch bei Hybriden, in der S-Klasse, bei klassischen Verbrennern im oberen Segment und bei den Vans so weit. Besonders interessant ist jetzt, was uns die Daten zeigen. Wir bekommen in Echtzeit Rückmeldungen aus dem Feld: Welche Funktionen nutzen die Kunden? Wie kommen sie damit zurecht? Was gefällt ihnen? Genau das macht diese Phase so wichtig.

Save the Date: AUTOMOBIL-ELEKTRONIK Kongress 2027

Am 22. und 23. Juni 2027 findet zum 31. Mal der Internationale AUTOMOBIL-ELEKTRONIK Kongress (AEK) statt. Dieser Netzwerkkongress ist bereits seit vielen Jahren der Treffpunkt für die Top-Entscheider der Elektro-/Elektronik-Branche.

Sichern Sie sich Ihr Konferenzticket!

Mit dem SDV stellt sich auch die Frage, wie sich Software im Fahrzeug monetarisieren lässt. Das ist nicht primär Ihre Aufgabe, aber welche Rolle spielt dieser Aspekt für Ihre Arbeit und für die Zusammenarbeit mit den Produktteams?

Der große Vorteil des Software-Defined Vehicle ist, dass man über viele Dinge nicht mehr diskutieren muss. Man kann anhand realer Daten sehen, was funktioniert und was nicht. In der Vergangenheit beruhte vieles auf Annahmen. Natürlich braucht man weiterhin eine Idee davon, welche Produkte und Funktionen man gestalten möchte. Aber ob eine Funktion tatsächlich angenommen wird, ob sie angepasst werden muss und ob eine Anpassung eine positive Wirkung hat, lässt sich heute deutlich besser bewerten. Dadurch verändert sich auch die Diskussion über Investitionen. Am Ende wird daraus eine sehr konkrete Frage nach dem Return on Investment: Welche Funktion stiftet Nutzen, wie wird sie angenommen und welche wirtschaftliche Wirkung lässt sich daraus ableiten?

Gerade für einen Premiumhersteller ist das eine sensible Frage. Kunden erwarten bestimmte Ausstattungen als Teil des Premiumanspruchs. Gleichzeitig entstehen neue digitale Zusatzfunktionen, die separat angeboten werden können. Wie zieht Mercedes-Benz hier die Grenze?

Es ist doch so: Unsere Kunden sind seit vielen Jahren an den Konfigurator gewöhnt, zumindest in Europa. Dort wählen sie aus, was sie haben möchten, und sehen transparent, was die jeweilige Option kostet. Beim Software-Defined Vehicle verändert sich bei vielen Funktionen nur der Zeitpunkt dieser Entscheidung. Der Kunde muss nicht mehr zwingend vor der Auslieferung festlegen, welche digitalen Funktionen er nutzen möchte. Er kann sich auch nach der Bestellung, nach der Fahrzeugübergabe oder erst nach ein oder zwei Jahren dafür entscheiden. Auch ein Zweitkäufer kann später Funktionen hinzubuchen. Wichtig ist dabei Transparenz. Der Kunde muss verstehen, wofür er bezahlt: für einen Monat, für ein Jahr oder für die gesamte Nutzungsdauer. Das ist ein wesentlicher Unterschied zum klassischen Fahrzeugkauf. Software macht das Angebot deutlich flexibler und gibt unseren Kundinnen und Kunden mehr Möglichkeiten.

Das heißt, der Kunde wird ein Stück weit vom Druck befreit, sich bereits beim Kauf für Funktionen entscheiden zu müssen, deren Nutzen er vielleicht erst im Alltag richtig einschätzen kann…

Genau. Natürlich gibt es weiterhin Entscheidungen, die physisch vorgegeben sind. Bestimmte Hardware muss im Fahrzeug vorhanden sein. Wenn ich eine zusätzliche Kamera für bestimmte ADAS-Funktionen brauche, muss diese entsprechend verbaut sein. Ich kann auch die Zahl der Zylinder nicht nachträglich per Software ändern. Aber viele digitale Funktionen lassen sich im Laufe der Nutzung aktivieren, anpassen oder erweitern. Das verändert die Kundenbeziehung erheblich.

Sie haben die Daten bereits angesprochen. Wie misst Mercedes-Benz konkret, welche Softwarefunktionen beim Kunden Nutzen stiften?

Dafür haben wir unsere Data Pipeline aufgebaut. Inzwischen sind rund 17 Millionen Fahrzeuge mit unserem Backend verbunden. Es gibt ja diesen Spruch: Daten sind das neue Öl. Ich würde eher sagen, Daten sind das neue Schmiermittel. Sie sind nicht einfach ein Rohstoff, den man verkauft, sondern sie sorgen dafür, dass das gesamte System besser funktioniert. Wir können beispielsweise sehen, wie sich die Nutzung der Navigation vor und nach einem Upgrade verändert. Wie häufig wird die Navigation genutzt? Wie viele erfolgreiche Routenführungen gibt es? Nutzen Kunden stattdessen alternative Apps? Und wenn ja: Was hat ihnen in unserer eigenen Lösung gefehlt? Solche Fragen stellen wir nicht nur bei der Navigation, sondern über alle relevanten Domains hinweg. Auch bei der Sprachbedienung analysieren wir zum Beispiel, wie viele Sprachbefehle gegeben werden und wie viele davon zu erfolgreichen Aktionen führen. Uns geht es nicht nur um Nutzung allein, sondern um erfolgreiche Nutzung. Dafür wurde im Unternehmen ein großes Programm aufgebaut: Datenvisualisierung, Dashboards und KPIs. Unsere Datenstrategie liefert die Grundlage, um diese Informationen systematisch in die Entwicklung zurückzuspielen.

Der große Vorteil des Software-Defined Vehicle ist, dass man über viele Dinge nicht mehr diskutieren muss. Man kann anhand realer Daten sehen, was funktioniert und was nicht

Magnus Östberg

Wie entscheiden Sie auf dieser Basis, welche Funktionen weiterentwickelt, verändert oder möglicherweise auch eingestellt werden?

Wir arbeiten hier sehr eng mit Sales und Marketing zusammen, vor allem aber auch mit den globalen Marktorganisationen. Denn welche Funktionen besonders relevant sind, hängt stark vom jeweiligen Markt und von der Kundengruppe ab. Ein Beispiel ist der US-Markt. Dort sehen wir eine deutlich höhere Nachfrage nach Funktionen wie einem „Dog Mode“, also der Möglichkeit, Haustiere unter bestimmten Bedingungen im Fahrzeug zu lassen. Auch Funktionen rund um Schnellbestellungen bei Anbietern wie Starbucks sind dort viel relevanter als in Europa. Solche Anforderungen unterscheiden sich regional erheblich. Deshalb brauchen wir einen engen Dialog zwischen Entwicklung, Produktmanagement und Marktorganisation. Wir arbeiten dabei mit agilen Methoden, analog von SAFe. Gemeinsam entwickeln wir Backlogs, und die Priorisierung erfolgt auf Basis der Daten. Funktionen oder KPIs mit hoher Relevanz landen entsprechend weit oben im Backlog. So wird die Entwicklung stärker kunden- und marktgetrieben.

Die Automobilindustrie diskutiert derzeit intensiv über Lokalisierung. Früher dominierten häufig globale Fahrzeugkonzepte, heute geht es stärker um lokale Produktion, lokale Entwicklung und lokale Kundenbedürfnisse. Software eröffnet dafür neue Möglichkeiten, erhöht aber auch die Komplexität. Wie findet Mercedes-Benz hier die Balance?

Entscheidend sind für uns globale Standards. Wir arbeiten mit klaren Leitplanken. Es ist definiert, woran sich alle Märkte halten müssen – und welchen Raum es für regionale Anpassungen gibt. In den größten Märkten haben wir lokale Teams, die bestimmte Applikationen und lokale Partner verantworten. Diese Partner sind in ihren Märkten oft die relevanten Local Heroes. Korea ist ein gutes Beispiel. Dort haben wir lokale Teams, die sehr genau verstehen, welche Erwartungen Kunden an Funktionen, Interaktion und digitale Dienste haben. Lokalisierung endet dabei nicht bei Sprache oder Navigation. Sie betrifft auch „Look and Feel“ und die Art der Bedienung. Sprache und Kultur spielen eine große Rolle dafür, wie Menschen mit einem Fahrzeug interagieren.

Werden gute lokale Ideen auch in andere Märkte zurückgespielt?

Selbstverständlich. Wir fördern ganz gezielt den Austausch von Ideen. Wir nennen das „Copy with Pride“. Dieses Prinzip treiben wir seit Jahren. Es geht darum, gute Ideen weiterzugeben, auch wenn nicht immer der Code selbst übertragen werden kann. Er kann trotzdem als Inspirationsquelle dienen. Entwickler können prüfen, wie sich ein Feature mit Anpassungen in anderen Regionen nutzen lässt. Ein Beispiel ist Karaoke. Dafür haben wir Lösungen gefunden, wie solche Angebote in unterschiedlichen Ländern rechtssicher umgesetzt werden können.

Ein wichtiges Thema im Kontext des SDV ist Open Source. Mercedes-Benz engagiert sich unter anderem bei Eclipse S-CORE. Wo verläuft aus Ihrer Sicht die Linie zwischen differenzierender und nicht differenzierender Software?

Sie haben recht: Open Source ist ein zentrales Element für uns. Gemeinsam mit BMW und Cariad haben wir den Impuls für Eclipse S-CORE gesetzt. Seit der Unterzeichnung verfolgen wir diesen Weg konsequent. Ein konkretes Beispiel ist die Diagnostik, die wir „upstream“ eingebracht, also über das Projekt frei und öffentlich zugänglich gemacht haben. Der Grund ist einfach: Alle Hersteller brauchen eine sehr gute Diagnose-Software. Wir hatten hier eine sehr detaillierte und leistungsfähige Lösung. Für unsere Kunden ist aber nicht entscheidend, wer diese Diagnostik definiert oder geschrieben hat. Wenn wir solche Must-haves gemeinsam entwickeln oder bereitstellen, verbringen wir weniger Zeit mit Grundlagen, die jeder braucht. Diese Zeit können wir dann in Funktionen investieren, die für den Kunden tatsächlich differenzierend sind.

Was ist dabei der wichtigste Treiber für Open Source: höhere Entwicklungsgeschwindigkeit, geringere Kosten oder mehr Kapazität für differenzierende Innovationen?

Im Grunde alles davon. Geschwindigkeit ist für mich aber der zentrale Punkt. Wir wollen schneller werden und gleichzeitig unsere Kosten senken, um attraktivere Produkte auf die Straße zu bringen. Wenn wir weniger Zeit und Ressourcen für Must-haves aufwenden müssen, hilft uns das in beiden Dimensionen.

Open Source ist ein zentrales Element für uns. Gemeinsam mit BMW und Cariad haben wir den Impuls für Eclipse S-CORE gesetzt

Magnus Östberg

In diesem Zusammenhang ist euch ein regulatorisches Thema zentral: die „Software Bill of Materials“. Ist die SBOM bei Mercedes-Benz bereits ein operatives Steuerungsinstrument oder vor allem ein Compliance-Thema?

Unsere End-to-End-Software-Journey hat die SBOM bereits eingebunden. Sie ist Teil unserer digitalen Lieferkette. Wenn wir Software an unsere Endkunden beziehungsweise in unsere Fahrzeuge ausliefern, ist auch diese Lieferkette digital angebunden. Das hilft uns, gegenüber Behörden und Partnern nachvollziehbar darzustellen, welche Softwarebestandteile eingesetzt werden. Es geht also nicht nur um Compliance im engeren Sinne, sondern um einen integralen Bestandteil der Softwarelieferkette.

Für weitere Transparenz hat Mercedes-Benz Anfang März ein FOSS Disclosure Portal und die Disclosure-CLI bei GitHub veröffentlicht. Was steckt dahinter?

Der Gedanke dahinter ist, den Worten Taten folgen zu lassen. Das Disclosure Portal macht transparent, welche Open-Source-Komponenten und -Lizenzen in unseren Produkten enthalten sind. Wenn wir zu Open Source beitragen, dann tun wir das nicht nur symbolisch. Wir pflegen auch den Code, den wir bereitstellen, und binden ihn automatisch in unser Build-System ein, also in unsere CI/CD-Kette. Dabei geht es nicht nur um Code, den wir selbst öffentlich gemacht haben. Auch Code, den andere veröffentlicht haben, kann in unsere Systeme eingebunden werden. Proprietärer Code, der bei uns nicht wettbewerbsdifferenzierend ist und ähnliche Funktionen erfüllt, wird entsprechend umgearbeitet oder ersetzt. Wir legen solchen Code zur Seite und nutzen stattdessen das Open-Source-Repository. Das schafft wiederum die Möglichkeit, Verbesserungen, die wir an anderer Stelle entdecken, upstream zurückzugeben. So funktioniert Open Source: Alle Beteiligten kollaborieren in einem gemeinsamen Repository. Dieses Repository wird in die eigene Entwicklungsumgebung eingebunden, daraus entsteht ein Endprodukt, und die gesamte Kette aus Continuous Integration, Continuous Delivery beziehungsweise Deployment und Continuous Testing muss automatisiert funktionieren. Nur so können wir am Ende auch rechtskonform sein. Wir müssen Open-Source-Lizenzen sauber dokumentieren, die entsprechenden Informationen im Portal bereitstellen und Behörden oder Partnern zeigen können, welche Lizenzen und welcher Code genutzt wurden. Das alles ist in unser Build-System eingebunden.

Mit dem Software-Defined Vehicle rücken klassische Fahrzeugentwicklung, IT und Softwareentwicklung näher zusammen. Wie sieht Ihre Zusammenarbeit mit Katrin Lehmann und ihrem IT-Team aus?

Das ist eine sehr gute Partnerschaft. Die IT-Organisation unter Katrin Lehmann ist verantwortlich für unsere Basissysteme und für viele Systeme, die von der gesamten Organisation außerhalb von R&D genutzt werden. Besonders wichtig ist die Zusammenarbeit im Cloud-Umfeld. Dort haben wir eine Mischsituation: Wir nutzen Dienste aus der allgemeinen IT-Landschaft, haben aber zusätzlich spezifische Anforderungen aus Forschung und Entwicklung. Noch wichtiger wird das durch KI. In einer Welt, in der Agenten, Ressourcen und Fähigkeiten an unterschiedlichen Stellen platziert sind, braucht es eine sehr enge Kommunikation mit der IT. Es geht nicht nur um technische Effizienz, sondern auch um Kosteneffizienz. Token- und Cloudkosten sind inzwischen wettbewerbsrelevant.

Zum Abschluss: Wenn wir uns in zwei Jahren wieder sprechen, woran würden Sie festmachen, dass Mercedes-Benz beim SDV den nächsten Schritt gemacht hat?

Sicherlich werden wir dann über die künftige S-Klasse sprechen. Das wird der nächste große Schritt in unserer SDV-Entwicklung und bei der Intelligenz im Fahrzeug. Die Kunden werden sich über mehr autonome Funktionen freuen können. KI-Agenten werden das Leben unserer Kunden deutlich vereinfachen. Und dann werden wir vermutlich darüber sprechen, wie langsam wir im Jahr 2026 eigentlich noch waren (lacht). Im Ernst: Das Tempo wird weiter zunehmen.

Zur Person:

Magnus Östberg ist seit September 2021 als Chief Software Officer bei Mercedes-Benz tätig. In dieser Funktion hält er die Gesamtverantwortung für das Fahrzeug-Betriebssystem MB.OS. Nach Abschluss seines Masterstudiums in Elektrotechnik an der Technischen Hochschule Chalmers im Jahr 1992, erlangte er 2006 berufsbegleitend den Executive Master of Business Administration an der Universität Göteborg. Seine Karriere startete Östberg beim Software- und Beratungsunternehmen Mecel. Anschließend übernahm er in Deutschland und den USA verschiedene Leitungsfunktionen bei Delphi. Zuletzt war Östberg als Vice President Software Platform & Systems beim Automobilzulieferer Aptiv in den USA tätig. Dort verantwortete er die Entwicklung und den Launch der ADAS Satellite Architecture bei mehreren Autoherstellern.