Stephan Durach ist Senior Vice President Connected Company, Development Technical Operations bei der BMW Group.

Der Wechsel zu AOSP wird die rasante Integration vieler Applikationen ermöglichen. Davon ist Stephan Durach, Senior Vice President Connected Company, Development Technical Operations bei BMW, felsenfest überzeugt. (Bild: BMW)

Herr Durach, in diesem Jahr gehen bei BMW gleich zwei neue Betriebssysteme an den Start. Weshalb steht dies einer einheitlichen Software-Plattform nicht entgegen?

Für den Kunden sollte sich alles gleich anfühlen, deshalb sehen wir darin keinen Widerspruch. Es gibt funktionale Unterschiede, aber diese werden so gut wie möglich kompensiert. Wir wollen eine Gleichheit auf der applikativen, funktionalen Seite schaffen. Davon ausgehend soll die darunterliegende Plattform den maximalen Carryover von einer Generation zur nächsten ermöglichen – über die unterschiedlichen Produktlinien hinweg. Haben wir heute schon einen Carryover von einhundert Prozent? Haben wir nicht, aber das ist das Ziel. Beim Technologiewechsel von der klassischen Linux-Schiene zum AOSP (Anm. d. Red.: Android Open Source Project) entsteht natürlich ein Migrationsaufwand. Zunächst parallelisieren sich die Systeme ein bisschen, aber in der nächsten Generation führen wir sie zusammen. Dann fahren wir wirklich auf einer Plattform.

Ab dem Operating System 10 gelingt dann der vollständige Carryover?

Gewisse Umfänge haben wir bereits von unserer Linux-Welt auf AOSP übertragen. Meine Idealvorstellung ist, dass alle Funktionen, die jetzt im AOSP entwickelt werden, auch für das nächste OS zugeschnitten sind. Die Navigationsapplikation wird etwa einfach per Drag & Drop auf die nächste Plattform gezogen. Das Einzige, was wir anpassen werden, ist das User Interface.

In anderen Software-Layern wird weiterhin Linux genutzt. Kann es ein „einheitliches“ Betriebssystem überhaupt geben?

Unsere Fahrzeuge haben verschiedenste Domänen mit unterschiedlichen Anforderungen. Wenn ich das System weiterentwickeln möchte, muss ich eine gewisse Abstraktion im System erreichen. Das Konzept eines Shared Service Layers, auf den ich mich notifizieren kann, macht genau dies möglich. Die spannende Frage dabei ist: Wo, wann und wie muss im Layer-Modell geschnitten und abstrahiert werden, ohne dass es den hardwareseitigen Ressourcenaufwand ins Unermessliche steigert? Ein einheitliches Konzept, was alle Anforderungen erfüllt, halte ich für schwierig.

Gab es einen konkreten Auslöser für den Wechsel zu AOSP?

Der Linux-Weg hat für uns gut funktioniert und wir wären ihn auch weitergegangen. Allerdings haben wir uns AOSP immer wieder sehr intensiv angeschaut. Irgendwann war der Punkt erreicht, an dem dieses Open-Source-Produkt die Reife und Rahmenvoraussetzungen erfüllt hat, um diesen Schritt zu gehen. Ein Produkt allein hilft noch nichts, es muss auch ein Ökosystem an Entwicklern, Tools und Applikationen geben. Der App-Store und das SDK-Angebot (Anm. d. Red.: Software Development Kit) haben letztlich zu einem Tipping-Point geführt. Am Ende war es eine Frage von Kosten und Nutzen, schließlich war der Wechsel auch mit einem gewissen Aufwand verbunden.

Worin unterscheidet sich die Entwicklung für Linux und AOSP?

Die Linux-Welt ist zwar Open Source, aber vieles was wir tun, ist proprietär BMW. Wir haben unsere eigenen Entwicklungstools und -umgebungen. Es gibt keine Standardapplikationen. Wir haben vieles selbst entwickelt oder von unseren Partnern entwickeln lassen. AOSP bietet eine Quasi-Standardisierung, unter anderem weil viele Branchen und Firmen in dieser Umgebung entwickeln. Während ich bei Linux teilweise erst überlegen muss, woher ich die nötigen Tools bekomme, sind sie bei AOSP schon vorhanden. Mein Lieblingsbeispiel ist die Navigation: Mapbox liefert dafür ein SDK (Anm. d. Red.: Software Development Kit), das etwa auch bei Strava-Karten zum Einsatz kommt. Wenn ich das gleiche SDK benutzen kann, habe ich natürlich einen ganz anderen Absprungpunkt. Anfangs hatten wir ein Feature-Set zur Verfügung, haben unser User Interface darauf aufgebaut und es integriert. Zwölf Monate später hat Mapbox neue Features nachgeschoben, die wir gar nicht beauftragt hatten – wie wir das früher in unserer alten Welt gemacht haben. Diese bedarfsorientierten Neuerungen nehmen wir gerade alle mit. Das heißt, ich habe einen kontinuierlichen Feature-Zuwachs. Zudem existiert auf Android eine viel größere Entwickler-Community, die für uns arbeiten kann.

Existierten anfänglich noch Berührungsängste mit Google-Diensten?

Bei Abhängigkeiten haben wir klare rote Linien. Das betrifft etwa das Thema Privacy, den Umgang mit Datenströmen oder die Möglichkeiten der Kontrolle. Google Automotive Services (GAS) ist ein Bundle, das für uns nicht funktioniert – in vielerlei Hinsicht. Die freie Gestaltung der Kundenschnittstelle ist unsere eigene Hoheit. Die würde ich ungern von einem anderen Unternehmen zertifizieren lassen. Das findet bei uns nicht statt.

Können die Kunden von dieser Schnittstelle eine nahtlose Integration ihres digitalen Ökosystems erwarten?

Die Integrationsgeschwindigkeit wird deutlich schneller. Dieser Umstand ist äußerst wichtig für uns. Es gibt viele Applikationen, die in der Android-Umgebung laufen und die man mit überschaubarem Aufwand an das Automotive-Umfeld anpassen kann. Zudem handelt es sich um Anpassungen, die unsere Partner auf funktionaler Seite ein Mal übernehmen und dann für viele Unternehmen verfügbar machen. Das ermöglicht einen viel höheren Grad der Skalierung. Deshalb bin ich felsenfest davon überzeugt, dass wir sehr viele Applikationen in sehr geringer Zeit zur Verfügung stellen können.

Welche Rolle wird künstliche Intelligenz bei der User Experience einnehmen?

Erste Ansätze werden schon heute verwirklicht, wenn der Kunde seine Daten zur Analyse freigibt. Wenn ich morgens in mein Auto einsteige, schlägt es mir unter der Woche das Büro als Navigationsziel vor. Am Wochenende erhalte ich andere Vorschläge. Proaktivität ist ebenfalls etwas, das unsere Produkte bereits zu einem gewissen Grad an den Tag legen. Von ersten Hinweisen bis zum Auslösen einer Aktion muss aber alles gestuft und sauber ablaufen. Es darf sich für den Kunden nicht komisch anfühlen oder ihn erschrecken. Der Eingriff einer KI sollte ein magischer Moment sein. Ich fahre auf der Arbeit etwa jeden Morgen an eine Schranke und bediene den Fensterheber. Das Auto hat dieses Verhalten gelernt und öffnet das Fenster mittlerweile automatisch. Über Personalisierung wird dies zu jedem neuen Fahrzeug weitervererbt. Da freue ich mich jedes Mal aufs Neue. Das ist genau die Art von künstlicher Intelligenz, die ich gerne hätte. Wenn ich in die Münchener Innenstadt an den Viktualienmarkt navigiere, erkennt das System die schwierige Parkplatzsituation. Es liefert Parkvorschläge oder führt durch Straßen, in denen das Auffinden eines Parkplatzes besonders wahrscheinlich ist. Diese Logik wurde der KI über Algorithmik bereits antrainiert. Jetzt schauen wir uns Punkt für Punkt an, an welcher Stelle wir dies sukzessive hochfahren können. Im Auto-Kontext muss man damit äußerst vorsichtig sein. Keiner möchte ein Produkt haben, dass den Fahrer in einer Verkehrssituation mit Informationen zuspammt. Künstliche Intelligenz birgt ein großes Potenzial, kann im Übermaß aber auch komisch wirken – wie die Klammer bei Microsoft Office.

Zitat

"Der Eingriff einer KI sollte ein magischer Moment sein."

Stephan Durach, BMW Group

Functions on Demand sind ebenfalls ein Punkt, bei dem Vorsicht geboten ist. Werden die neuen Betriebssysteme diese Büchse der Pandora endgültig öffnen?

Ich weiß nicht, ob es wirklich eine Büchse der Pandora ist. Das hängt von den Funktionen ab. Wir haben Features, die wir über die Zeit entwickeln und die einen echten Mehrwert bieten. Ein naives Beispiel: Angenommen, es gäbe grundsätzlich keine Navigation, ein Jahr später könnten wir sie aber anbieten. Dahinter stehen Entwicklungs- und Lizenzkosten sowie Übertragungsgebühren für das Karten-Streaming. Verschenke ich dieses Feature oder biete ich es gegen Gebühr an? Man muss Functions on Demand mit einem klaren Inhalt verbinden und darf nicht den Eindruck erwecken, dass ein ohnehin bezahltes Feature erneut abkassiert wird. Das wird nicht funktionieren. Derzeit übt die gesamte Industrie, in welcher Kleinteiligkeit solche Angebote Sinn ergeben. Ich vergleiche das gerne mit den Online-Medien: Am Anfang war alles umsonst, dann wurde jede Kleinigkeit abgerechnet und mittlerweile hat sich ein Mittelmaß eingependelt. Das Abo-Modell bei Zeitungen existiert schließlich schon weitaus länger. Und wer heutzutage einen Fernseher kauft, zahlt trotzdem extra für Netflix. Deswegen sehe ich das Thema nicht so kritisch. Auf der Content- und Softwareseite sind Functions on Demand meiner Meinung nach absolut legitim und werden auch verstanden.

Bei der Sprachassistenz greift das neue Betriebssystem auf die Fähigkeiten von Amazon Alexa zurück. Weshalb erfolgte keine direkte Integration?

Der Dialog mit der Sprachassistenz ist ein markenprägendes Element – so wie die grafische Gestaltung des User Interface. Allein die Stimme differenziert schon von anderen Marken. Die Art und Weise, wie der Dialog geführt wird, und das Funktionsset bleiben deshalb unsere Aufgabe. Amazon liefert somit kein fertiges Produkt, sondern ein SDK mit verschiedenen Funktionalitäten. Wir können mehr oder minder frei konfigurieren, ob und wie wir sie nutzen. Gewisse Funktionsblöcke bei der Sprachverarbeitung – wie Audiosignalaufbereitung, Noise-Cancelling oder Filterung – gehen wir hingegen mit einem anderen Partner an.

Welche Funktionalitäten liefert das SDK denn konkret?

Die Spracherkennung gehört ein stückweit zum Amazon-Service. Dies erfolgt auf eben jenem Service Layer. Wir schieben dort unsere Audiofiles rein und die Erkenner-Software prozessiert diese. Hierbei erwarten wir von der Alexa-Technologie einen deutlichen Qualitätsschub. Danach folgt die Interpretation des Erkannten. Amazon spricht dabei von Intents. Die Engine und das SDK liefern Standard-Intents, die gut funktionieren. Ich kann zum Beispiel auf verschiedenste Weise nach dem Wetter fragen. Früher mussten wir jeden Dialog eigenhändig gestalten, jetzt müssen wir uns nicht mehr selbst darum kümmern. So können wir uns bei der Sprachassistenz auf Dinge konzentrieren, die wirklich wichtig sind und der Differenzierung dienen.

Wird der Intelligent Personal Assistant dadurch zum vollumfänglichen Assistenten oder bleibt er eine erweiterte Sprachbedienung?

In dieser Hinsicht wird sich eine Menge wandeln. Wir kommen aus einer Welt von Command and Control – wie bei einer gezielten Navigation oder einem Telefonanruf. Wir möchten aber in eine Welt einsteigen, die Natural Language Understanding bietet. Wenn Amazon etwa die Intents für die Frage nach dem Bundeskanzler von Deutschland oder die Reisebuchung über einen bestimmten Anbieter schon gebaut hat, nehmen wir dies natürlich mit, anstatt sie mühselig nachzubauen. Das könnte man als Beifang bezeichnen. Und auch bei der Verknüpfung mit den Fahrzeugdaten wird sich einiges tun. Die einfachen Dinge, wie die Frage nach dem aktuellen Standort oder der restlichen Fahrzeit, funktionieren heute schon. Nun fangen wir an, auch bei den Points of Interest die Enden zusammenzuführen.

Die My-BMW-App verfügt mittlerweile über eine digitale Reifendiagnose. Welche Anbindungen sind darüber hinaus an Werkstätten und Ersatzteilgeschäft geplant?

Wir bieten bereits eine Online-Terminvereinbarung an. Zudem kann der Mechaniker bei der Reparatur über die App einen Dialog eröffnen oder dem Kunden ein Video zuschicken. Wir wollen gemeinsam mit den Niederlassungen die komplette Kommunikation über diesen Kanal fahren, weil es für den Kunden schlichtweg bequemer ist. Anhand der Fahrzeugdaten kümmern wir uns schon heute proaktiv – egal ob durch Infos in der App, Push-Notifikationen, E-Mails oder persönlichen Kontakt. Wir wollen den Kunden ansprechen, bevor er ein Problem hat, aber ohne einen Verkaufsdruck zu generieren. Wenn etwa die Reifen sich dem Lebensende nähern, können wir darüber informieren, bevor eine verunsichernde Kontrollmeldung erscheint oder gar eine Panne passiert. Das macht die Wartung deutlich planbarer. Hektische Terminvereinbarungen können dadurch vermieden werden.

Was kann BMW noch von Tech-Playern wie Google, Apple oder Microsoft lernen?

Wir haben schon eine ganze Menge gelernt. Zum Beispiel nur Dinge zu tun, die wirklich skalieren. Wer zu proprietär oder kleinteilig denkt, bekommt bei Service und Wartung ein Problem. Worauf ich ein bisschen neidisch bin, ist die Geschwindigkeit, mit der diese Unternehmen ihre Devices weltweit ausrollen und auf dem neuesten Stand halten. Da stecken wir gerade mittendrin. Wir haben auch eine riesige Flotte von knapp fünf Millionen Fahrzeuge, aber verglichen mit dem ein oder anderen Tech-Player ist das noch eine kleine Menge. Da kann man sich sicherlich einiges abschauen. Allerdings gibt es auch Ansätze, die wir für keine gute Idee halten: Wir machen etwa kein Beta-Testing am Kunden. Das würde ich keinesfalls übernehmen. Wir wollen ein qualitatives Produkt liefern, das von Anfang an Freude bereitet.

Zur Person:

Stephan Durach, BMW

Seit Oktober 2020 ist Stephan Durach als Senior Vice President Connected Company, Development Technical Operations bei der BMW Group tätig. Er blickt auf eine lange Karriere beim bayerischen Autobauer zurück, die 1998 nach seinem Studium der Elektrotechnik an der TU Karlsruhe begann. Nach diversen Aufgaben im Bereich Elektronik und Software wurde er 2008 zum Head of Technology Office Palo Alto/Mountain View ernannt. Im Jahr 2013 kehrte Durach als Head of Entertainment, Mobile Devices and App Centers zurück nach Deutschland. Anschließend folgte eine Position als Vice President Electronics and Driver Experience in der Luxusklasse sowie unterschiedliche Führungsrollen im Elektronikeinkauf.

Sie möchten gerne weiterlesen?