Richtig ist: Die Automotive-Plattform der Zukunft muss auf Basis existierender Komponenten gebaut werden. Doch zwei Hindernisse stehen den Automotive-OEMs auf dem Weg zum software-definierten Auto im Wege. Das eine sind proprietäre Ansätze, das andere ist eine Lücke in der Plattform. Was tun?
Kennen Sie Nick Marshall? Nein? Das ist der Mann, der dadurch bekannt wurde, dass er seine Beine enthaart, eine Damenstrumpfhose trägt, raucht, sich föhnt und dabei in die Badewanne stürzt – quasi alles gleichzeitig. Nachahmung nicht empfohlen. Aber in seinem Fall ist er hinterher nicht gegrillt, sondern weiß stattdessen, „Was Frauen wollen“. Sowas gibt es natürlich nur im Film.
Nick hat uns etwas voraus: Er kennt die Bedürfnisse seiner Zielgruppe. Die Bedürfnisse von Partnern und Kunden zu kennen – diese Information ist auch in der Automobilwelt mindestens so viel wert wie ein voller Tank oder eine geladene Batterie. Nachdem wir letztes Mal – ganz ohne Föhn und Gedankenlesen – eruiert haben, was Autofahrer wollen, reden wir heute über das, was Entwickler wollen. Denn diese beiden Komponenten münden direkt in das, was Connected-Car-Plattformen wollen (bzw. brauchen).
Autofahrer wollen in Zeiten der Digitalisierung ihr individuelles Service-Ökosystem auch im Auto verwenden – möglichst bruchfrei. Der maximale Aufwand für die Bereitstellung von Apps im Auto sollte bei einem Knopfdruck liegen, wenn sie nicht gar direkt auf der In-Car-Plattform integriert sind. Typische Dienste, die heute schon quasi als Zubehör geliefert werden, sind Entertainment-Dienste wie Spotify und Parkinfos. Damit sind sie aber die Ausnahme. Die überwiegende Menge der Apps, die außerhalb des Auto-Lebensraums existieren, haben ihren Hometurf im Internet. Und sie spielen nach den dort geltenden Regeln wie Continuous Innovation, Integration, Delivery und Deployment. Wöchentliche, teils tägliche Updates und Erweiterungen des Systems durch agile Ansätze – das passt nicht so recht zu den doch recht langen Entwicklungszyklen von Autos. Wenn wir also versuchen, App-Ökosysteme und Autos zu kombinieren, geraten wir in eine systemische Schieflage.
Gleichzeitig spielt für Automobilbauer aber Geschwindigkeit eine entscheidende Rolle – und ich meine jetzt nicht die Höchstgeschwindigkeit eines Autos, sondern die Bereitstellung von Produkten und digitalen Services am Markt. Es liegt nahe, dass Automotive OEMs auch für ihr Go-to-Market von der App-Kultur profitieren können.
Die entscheidende Rolle dafür spielt die Connected-Car-Plattform der Zukunft. Sie setzt auf einigen ausgereiften und schon länger verfügbaren Komponenten auf, aber sie braucht noch ein paar Extras, damit sie in die software-definierte Ära passt.
Zu den vorhandenen Komponenten zählen die Connected-Car-Services selbst sowie externe Geräte. Das können neben Smartphones der Nutzer auch andere vernetzte Dinge wie Elektroladesäulen oder Verbindungen ins Smart Home sein. Außerdem gehören die Automobilflotte eines OEM mit ihren jeweiligen In-Vehicle-Plattformen und das Cloud Backend dazu – in der Regel auf Basis von industrie-agnostischen IaaS und PaaS der Hyperscaler. Mobile Konnektivität ist eine weitere Kernkomponente, die Telco Edge ein optionaler Baustein. Diese ist Stand heute für kritische Dienste ein Muss; zukünftig wird sie aber auch für optionale Dienste herangezogen werden, um den Fahrern eine verbesserte User Experience zu verschaffen.
Im Zentrum dieser Komponenten – zwischen dem industrie-agnostischen PaaS und den In-Car-Services – klafft aber eine Lücke, an der sich der Erfolg der Automotive-Plattform entscheidet. Und bislang ist es den Hyperscalern nur bedingt gelungen, diese Lücke zu schließen. Hier beäugen sich die agile App-Welt und die proprietäre E/E-Automobilwelt kritisch. Die Lösung für diese Situation ist eine Art Unterhändler zwischen den beiden Seiten: ein Automotive PaaS. Diese zusätzliche Komponente ist das zentrale Herzstück, das eine leistungsfähige Connectar-Car-Plattform braucht. Das Automotive PaaS nutzt etablierte Standards der App-Welt, um Services schnell ins Auto zu bringen.
Bislang setzten Automobilhersteller für die Bereitstellung von Apps im Auto auf eigene Standards. Doch dieser Ansatz erhöht die Attraktivität für Apps nicht. App-Entwickler sind in den Standards des Internets und der Cloud zu Hause. Und sie werden für eine – im Vergleich zur gigantischen Internetwelt – kleine IoT-Endgerätewelt der Autos nicht doppelt auf verschiedenen Standards entwickeln. Wenn Autohersteller also wollen, dass ihre Fahrzeuge bzw. In-Vehicle-Plattformen einen einfachen und schnellen Zugang zur Welt der Apps erlauben, müssen sie sich auf die gängigen Standards der App-Welt einlassen.
Das Automotive PaaS macht genau das: Es öffnet App-Entwicklern die Tür zu den Autos und fördert so die App-Kultur an Bord. Es stellt App-Entwicklern alle Tools im Rahmen einer Bibliothek bereit, damit sie ihre Apps mit geringem Aufwand automotive-spezifisch bereitstellen können. Kurz und gut: Es lohnt sich nicht, das Rad neu zu erfinden, sondern es ist besser, auf den fahrenden Internetzug aufzuspringen. Er ist das schnellste Transportmittel, um die Kluft zwischen Auto und App zu überbrücken. Und die standardisierte Plattform nutzt nicht nur den externen Entwicklern, sondern hilft auch der Entwicklung auto-spezifischer Apps. Dafür werden typische, native Fahrzeug-Features wie Monitoring, Public Key Infrastructure (PKI), Digital Twins oder Over-the-Air-Funktionalität bereitgestellt. Eine Plattform für alle, mit der sich eine konsequente Orientierung am Fahrernutzen realisieren lässt, die einen Vendor Lock-in vermeidet und die zudem alle regionalen Märkte bedient.
Die Erkenntnis sollte so neu nicht sein: Etablierte Branchenstandards haben schon in der Vergangenheit ihren Wert bewiesen, indem sie unnötige Aufwände vermieden, Kosten gesenkt und schneller zu Produkten geführt haben. Die Wertschöpfung für den Fahrer entsteht nicht auf der Ebene der Plattform, sondern bei den angebotenen Diensten. Warum die Automobilindustrie in der software-definierten Ära diese Lektion neu lernen mussten, erschließt sich mir nicht wirklich.
Eine Herausforderung bleibt: Wie gelingt der Sprung von einer proprietären Plattform hin zu einer neuen standardisierten Plattform? Nur wenn die existierende, proprietäre Plattform behutsam in Richtung einer standardisierten Plattform transformiert wird. Und genau das wird in den nächsten Jahren – wenn sich OEMs auf den skizzierten Weg einlassen – eine weitere herausfordernde Aufgabe werden. Umstellungen während des laufenden Betriebs waren schon immer unbeliebt. Dafür entsteht dann aber die Basis dafür, dass das Auto über Jahre hinweg konsistent gemanagt werden kann – und „weiß, was Fahrer wollen“. Es erlaubt OEMs, diese Wünsche schnell und effizient zu erfüllen. Und das könnte ein Differenzierungsmerkmal in der App-Ära sein.
Gleichzeitig bietet die vereinheitlichte Plattform aber einen weiteren, nicht zu unterschätzenden Vorteil – und zwar für den Betrieb der Fahrzeugflotte. Die Dienste, die über die automobile Entwicklungsplattform bereitgestellt werden, kommen dem Vehicle Operation Center (VOC) zugute. Das VOC erlaubt ein zentrales Monitoring und eine ebensolche Steuerung der kompletten Fahrzeugflotte. Das VOC ermöglicht dem OEM, im laufenden Betrieb die Flotte zu optimieren, beispielsweise über Over-the-Air-Updates, und die Informationsrückläufe zu bündeln. Verknüpfung von Entwicklung und Betrieb – auch dieses Konzept ist nicht neu: Wir sprechen von einer Art DevOps für das konsistente, weltweite Flottenmanagement.
Angereichert mit diesen drei Komponenten sowie einer Zukunftslösung für Connectivity, die sowohl technisch, als auch betriebswirtschaftlich in allen bedienten Märkten überzeugt, sollte die Connected-Car-Plattform der Zukunft stehen. Soweit man das heute absehen kann. Beim Blick in die Zukunft kann uns aber nicht mal Nick Marshall helfen.
Vernetztes Fahren bedeutet Integration der „Autozeit“ in die „Lebenszeit“ außerhalb des Autos. Eine leistungsfähige Fahrzeugplattform im vernetzten Fahrzeug muss diese Aufgabe meistern. Damit leistet sie einen wichtigen Beitrag zur Wertschöpfung des Autos. Zukünftige vernetzte Fahrzeugplattformen werden zu 360-Grad-Serviceplattformen. Sie sind die Basis für eine Fülle verschiedener Dienste – die auch über das Auto selbst hinausgehen. Zunächst werden individueller Kundendienst, Flotten- und individuelles Fahrzeugmanagement abgedeckt. Dazu pflegen sie die Kundenbeziehung und bieten einen Feature-on-Demand-Marktplatz. Zuletzt bieten sie den Zugriff auf OEM- und Drittanbieter-Ökosystemdienste. Sie werden zu einer digitalen Kundenschnittstelle, einem In-Car-Shop, der zu verschiedenen Angeboten führt und das Design neuer Geschäftsmodelle erlaubt.
Im nächsten, abschließenden Post dieser Serie will ich einen Blick hinter die Kulissen werfen: Welche Komponenten und welche Architektur sind notwendig, damit OEMs ihren Kunden eine solche Plattform anbieten können?