ConnectedCarAPI

Rund um die Datenschnittstellen im Connected Car entsteht ein Milliardenmarkt. Bild: Daimler, Flaticon

| von Claas Berlin

Fast alles, was das Auto und seine Nutzung ausmacht, wird zunehmend durch Software und Daten definiert: Fahrerlebnis, Reiseplanung, ganze Mobilitätsmodelle sind mittlerweile das Ergebnis von Daten und Algorithmen. Bei all dieser Software handelt es sich freilich nicht um einen monolithischen Block, sondern um ein multifaktorielles, ineinander verzahntes Räderwerk. Software produziert Daten und braucht gleichzeitig welche. Damit das funktionieren kann, müssen die einzelnen Teile dieses verzahnten Räderwerks wechselseitigen Zugriff haben. Am besten über definierte Schnittstellen, die dokumentiert sind. Hier beginnt das Problem: Die Autohersteller haben nicht unbedingt ein Interesse daran, dass jeder, der möchte, auf jede Schnittstelle zugreifen und sie nutzen kann. Dafür kann es gute Gründe geben – aber nur offengelegte und im Idealfall standardisierte Schnittstellen machen es überhaupt möglich, neue Services und Geschäftsmodelle rund um vernetzte Autos zu entwickeln und anzubieten. Die Frage, wer auf welche Schnittstelle zugreifen darf und wer welche Daten nutzen kann, rückt daher zunehmend in den Mittelpunkt der aktuellen Überlegungen und Auseinandersetzungen.

Einen großen Schritt hat die Autoindustrie mit Einführung des Konzepts „Nevada-Share & Secure“ gemacht, das die Weitergabe von Fahrzeugdaten an Dritte auf eine geregelte Basis stellt – und nebenbei das bei den Herstellern verhasste „wilde“ Anzapfen der OBD-Schnittstelle durch Dongles und Apps von Dienstleistungsanbietern beenden soll. Der Zugriff auf die Daten erfolgt abgestuft nach ihrer Kritikalität über das Hersteller-Backend sowie einen nachgeschalteten neutralen Server. Dieses Konzept wurde bereits von BMW mit CarData und Daimler mit Otonomo oder High Mobility umgesetzt. Über diese Plattformen können interessierte Dritte auf die Fahrzeugdaten zugreifen und eigene Dienste entwickeln. Zum Beispiel individualisierte Versicherungsangebote oder personalisierte Informations- und Musikzusammenstellungen. Daimler macht die Fehlercodes aus dem Fahrzeuginneren zugänglich, um etwa Werkstattdienstleistungen wie Ferndiagnose zu ermöglichen. Außer über den erwähnten neutralen Server können die Daten auch über die hauseigene Entwicklerplattform Developer.mercedes-benz.com zur Verfügung gestellt werden.

Aufgabe all dieser Plattformen soll es sein, die Datenformate gebrauchstauglich zu übersetzen und einen herstellerunabhängigen Zugang zu gewährleisten. Allerdings stößt die praktische Umsetzung auf Skepsis. „Dazu gibt es im Moment weder das juristische Framework noch die entsprechenden Preismodelle, noch das technische Framework“, erklärt Christian Umbach, CEO des deutsch-amerikanischen Startups Xapix. Das Unternehmen sieht sich als Enabler für den Datenaustausch für Firmen mit Plattformambitionen und somit als Integrationspunkt herstellerunabhängiger Fahrzeugdaten. Für Umbach stellt die Nähe vor allem von Otonomo zu Daimler ein Problem dar: Zwar helfe der Erfolg von Otonomo, Klarheit rund um künftige Geschäftsmodelle und Use Cases zu schaffen, doch werde hier eine Monopolstellung eines vermeintlich neutralen Datenaggregators gefestigt. Nicht nur bei den Daten, die nach dem Nevada-Modell Dritten zur Verfügung gestellt werden, hapert es noch mit der Standardisierung und Offenheit, sondern auch und gerade bei den Daten im Auto. Was sich die einzelnen Sensoren und Steuergeräte gegenseitig mitteilen, unterliegt der strikten Kontrolle der Autohersteller – auch hier sicherlich aus vielen guten Gründen. Doch die Geheimniskrämerei steht einer Weiterentwicklung der Softwarelieferkette im Wege.
Das ist nachvollziehbar. Bei fahrzeuginternen Daten und Softwareschnittstellen geht es um die Intimsphäre der herstellereigenen Technik, um den Schutz von geistigem Eigentum. „Je näher Sie an die Sensorik kommen, desto mehr wächst die Wahrscheinlichkeit, dass sich manche Hersteller nicht so tief in die Karten schauen lassen wollen“, erläutert Michael Reichel vom Softwarehersteller Elektrobit, der als Anbieter von Entwicklungsplattformen für Fahrzeugsoftware das Spiel der Marktkräfte in diesem Bereich aus nächster Nähe miterlebt. Welche Gedankengänge die Autohersteller umtreiben, verdeutlicht exemplarisch Rolf Zöller, Leiter der Elektrik- und Elektronikentwicklung bei Volkswagen. „Derzeit ist nicht vorgesehen, das Auto für Services Dritter quasi komplett zu öffnen. Das sind strategische Überlegungen, mit denen wir noch nicht am Ende sind“, sagt er. Dazu müsse man erst noch Erfahrungen mit Test, Freigabe und Validierung sammeln – um hundertprozentig sicherzustellen, dass man alle Risiken beherrschen kann.

Immerhin: Der Wettlauf um die Automatisierung des Fahrens hat eine Reihe von Initiativen zur Schaffung von Standarddefinitionen und -schnittstellen initiiert. Beispiele sind der Kartenstandard NDS oder der darauf aufbauende De-facto-Standard Adasis, mit dessen Hilfe sich Navigationsdaten auf Fahrerassistenzsysteme aufschalten lassen. Auch beim Datenformat für das Umfeldmodell, das die Fahrzeug­sensoren aus den Umgebungsdaten errechnen, gibt es Bestrebungen, auf einen gemeinsamen Nenner zu kommen. Denn so nachvollziehbar es ist, wenn OEMs ihr geistiges Eigentum schützen wollen – es gibt durchaus gute Gründe für mehr Offenheit bei fahrzeuginternen Daten und Algorithmen. Gerade die Fahrzeughersteller als Auftraggeber für die meisten Entwicklungen in diesem Segment würden profitieren: Die Auftragsvergabe würde sich erheblich einfacher gestalten als bei Verwendung unternehmensinterner Spezifikationssätze, mit positivem Effekt für die Entwicklungszeit und die Dauer bis zum Produktstart. Grund: Wenn ein OEM einen Entwicklungsauftrag vergibt und dabei nicht auf einen Standard rekurriert, muss er die Schnittstelle detailliert beschreiben. „Eine solche Beschreibung kann leicht einen halben Aktenordner und mehr umfassen“, erklärt Michael Reichel. „Dann muss sie der Auftragnehmer erst einmal komplett verstehen und durchdringen.“ Das allein kann unter Umständen mehrere Monate dauern. Kann der Auftraggeber dagegen auf einen Standard rekurrieren, ist das Auftragsdokument vielleicht eine Seite lang, der Auftragnehmer kann sofort ans Werk gehen und ist auch schneller fertig. Allerdings kennt Reichel neben den beschriebenen strategischen Überlegungen noch zwei weitere wichtige Gründe, warum die Standardisierung der Schnittstellen nur schleppend vorankommt. Erstens: Sie kostet Geld. Einen Entwurf durch einen Standardisierungsprozess zu bringen, verschlingt erhebliche Summen. Zweitens: „Diejenigen, die einen Standard erstellen können, sind meist auch diejenigen, deren Schreibtisch sowieso schon unter Arbeit zusammenbricht.“