Some thoughts on CAR APIs
Since around 2009 I have been engaged in making car data accessible. Working on different research projects together with OEMs such as Volkswagen, Daimler, BMW, Audi and others, I noticed great enthusiasm, spirit and the willingness of many engineers to make this possible. On the other hand I also noticed great fear of loosing control or cannibalization of old business models through disruption. But as Robert Iger (CEO of Disney) wrote in his book (The Ride of a Lifetime), it is important to recognize the change, embrace the change and then do something about it. You sometimes have to accept to loose money in the short term in order to grow out stronger in the long term. As Disney has decided to start their own streaming platform with Disney+, they were willing to loose money in short term in licensing fees from Netflix and others and placed their bet on the future. Creating their own streaming service is a big investment and risk, but in the long term it could give them more control, direct customer access and higher revenues than they could ever make with a sole licensing business.
The old automotive industry is facing a change as well. As the digitalization of vehicles is progressing, the need for digital transformation within the OEMs is nearly overdue. Tesla and other new players are putting a lot of pressure on the old mechanical engineering company’s including the supplying industries such as Bosch, Continental and many others. Their way of working together will need to radically change in order to be able to keep up with the new players in terms of software development and digital innovation. The OEMs now need to embrace the change and do something about it. But creating digital innovation requires a big shift in processes and mindset. It is possible but very hard to achieve for mainly non digital companies. If you look at how successful digital innovators work, it is completely different to the way OEMs and most supplier companies are structured: flat hierarchies, transparency in decision making (e.g. by applying OKR, see “Measure What Mattes” by John Doerr), interdisciplinary cross functional teams working in agile iterative processes. It is possible to achieve such a transformation and create an ambidextrous organisation as explained in “The Innovator’s Method” by Nathan Furr and Jeff Dyer. But maybe there is an easier solution for the OEMs: let others create the digital innovation. All that has to be provided is a great platform for automotive applications and the digital innovations will come to you. The book “Platform Revolution” by Geoffrey Parker et al. describes quite well, what is necessary to build a successful platform similar to what Apple and Google did. My suggestion to the OEMs is: be bold and you will grow out stronger in the long term. Because, if you don’t do it, someone else will. But dont take my word for granted, ask Robert Iger for his opinion on this.
What is the first step in building a Car-App platform? Provide an API!
Easier said than done. Today almost every OEM has an internal API to access their vehicles and all modern cars need to be connected (due to e.g the European eCall regulation). So the APIs are already existing, but only a few are made publicly available. If you search on Github, you will find a lot of open source projects that provide you with reverse engineered APIs of many manufacturers such as JLR, Tesla, GM and others. One bold OEM is going forward and provides a public API and SDK: Mercedes-Benz (Daimler)! This is outstanding, as it is the first step in the right direction to build a platform for vehicle apps.
The market for Car APIs is evolving and a number of companies already started implementing and providing platforms for Car-App development. These are for example the Berlin located startup “High Mobility”, the US based service provider “Smartcar” and the Israeli market leader in that area “Otonomo”. In the course of a research project one of my students, Felix Dimmler, analysed the diffent players on the market and evaluated their APIs. In his thesis, he describes the functionality of a connected vehicle, the importance & relevance of vehicle data, and how the platforms of individual providers of connected car APIs differ in their business model, functionality, and usability. He asks the questions: “Are cross-manufacturer vehicle interfaces feasible and do they offer advantages compared to proprietary platforms? In which use-cases are cross-manufacturer and when are proprietary solutions more appropriate? He conducted interviews with different experts in the field and analysed standard approaches such as the Extended Vehicle ISO (ExVe) standard. He also compared the usability of the different APIs and their implementation quality.
We will see, when the first OEMs embrace the change and start building their own platforms so that digital innovation in the car can happen as it happend with the mobile phone, when Apple provided the App Store and the developer platform. We will see.
Conclusion of Felix’s thesis
I let this blog post end with the words of Felix Dimmler concluding the following in his thesis:
“The analysis showed that the market of connected car services and the connected car API platforms is further ahead than the vehicle manufacturers themselves: customers are willing to share data if they benefit by a service or an application. Up to 94 percent of connected car services customers in the USA and 77 percent in Europe show interest in connected car services. Connected car API platforms can already process a lot more information than manufacturers currently provide. Although some manufacturers are open to share their data, they are very cautious about which data is released as this is not reversible. To prevent the misuse of vehicle data and making the approval processes of third-parties easier, the data is bound to fixed use-cases tailored by the OEMs, whether this is a proprietary platform or a neutral server like High Mobility or Otonomo. This increases vehicle security and data protection but slows down the process of getting access to more vehicle data and functions. Technically, the supply of more vehicle data is no concern on the side of the connected car API platforms.
The results of the analysis provide a clear statement regarding the first research question, if cross-manufacturer connected car API platforms are feasible. Both, proprietary as well as cross-manufacturer platforms are us- able for real-world implementation if the current, still limited scope of data and functionality does not restrict the use-case. What all providers have in common is a free development and test environment to experiment and encourage new connected car services. But cross-manufacturer platforms offer the advantage that a data protection-compliant vehicle communication only has to be implemented once and can be used across mul- tiple car brands without individual contractual negotiations. In terms of their diversity, the platforms differ in their product portfolios, compatible manufacturers, and their appearance on the market. High Mobility and Smartcar appear to offer a similar service with their focus on personal connected car services. However, Smartcar is less partnership-oriented, as there is no reference to the ExVe concept or the principle of the neu- tral server. Both High Mobility and Otonomo officially operate as neutral servers for the car brands BMW, Mercedes-Benz, and MINI. Nevertheless, in comparison, Otonomo is differently positioned with its offer of aggregated data and appeals to much greater institutions as target groups. But, the platform in general is not mature yet due to the missing ability to create & test personal services as well as the developing streaming interfaces. Otonomo is the biggest player in this comparison and has grown quicker than its competitors, regarding the number of partnerships and the amount of data the platform is processing. Proprietary platforms are also able to provide aggregated data at first-hand as the supply of this data has more potential in monetization than personal data. Current use-cases for this are already more common, e.g. real-time traffic or parking information whereas use-cases for personal vehicle services like on-demand fueling or usage-based insurance are not popular yet.
The technical evaluation based on individual implementations, guidelines, and pre-defined criteria showed that the platforms barely differ in API design. However, Otonomo needs improvement to provide more tailored error information and state-of-the-art APIdocumentation as well as proper implementation of some API guidelines. Furthermore, the way how aggregated data is provided asynchronously via a CSV file is rather unusual. Moreover, the test implementations showed that there are differences due to the availability of SDKs to support a developer for easier integration. High Mobility and Smartcar made the implementation easier by a wide range of available SDKs, while Otonomo and Daimler only rely on REST interfaces, which require more effort.
The answer to the final question, in which use-cases cross-manufacturer platforms are better suitable compared to proprietary platforms depends on the use-case. Regardless of whether the use of vehicle data is a personal or aggregated service, cross-manufacturer connected car API platforms are better suited when vehicles from several manufacturers need to be addressed. This eliminates the need for contractual negotiations with the individual manufacturers and the implementation of various APIs and authorization processes at minimal extra costs. However, due to missing legal obligations, the manufacturers can reserve data products for themselves, as Daimler does currently, which offers vehicle remote control only with its mobile SDKs, for instance. In general, new data products are more likely to be available sooner on a proprietary platform. Moreover, it can react faster on customer requirements. The individual OEM integration can be an alternative for data consumers with a homogeneous fleet. In the case of aggregated data, it remains to be seen what kind of additional value the cross-manufacturer platforms will offer in the future compared to the proprietary ones. Currently, Otonomo forwards the data without enriching it with any real added value or interpretation as this is left to the third-parties as data consumers. But in terms of data supply, Otonomo also offers data access via its consumer playground using a user interface within the browser. Thus, not only developers but also data analysts who are interested in the history of traffic data can access the data, for instance.
Outlook
The demand for vehicle data could develop in favor of cross-manufacturer platforms, as this enables more data to become available with one interface. In this context, the integration of new vehicle classes such as light and heavy commercial vehicles and motorcycles could increase the amount of data even further. Besides that, it might be interesting to see how new categories of data and new ways of gathering data through new data chan- nels via external cloud systems would emerge. The data might be delivered directly from the vehicle via Android Automotive, as an example. Moreover, other use-cases would be available through write access to open or close, start and stop vehicles to enable trunk delivery, car-rental/car-sharing, or workshop services that allow mainte- nance data to be updated without a physical data connection to the vehicle. From time to time, hesitant OEMs could realize that these platforms are more likely to be a multiplier of their revenue from vehicle data than a com- petitor, as they would still make money by providing access to their vehicles. For example, workshops today buy tools to read diagnostic data. In the future, this could be a bundle of APIrequests per month.
Some data-consumers are likely to remain on data of one or two manufacturers by using proprietary platforms. Also, several use-cases or target groups might only be targeted by the OEMs themselves. Therefore, the cross- manufacturer connected car API platforms and proprietary platforms will certainly have a coexistence.
The demand for access to cross-manufacturer vehicle data might grow faster than what can be offered from these platforms today due to restrictions. But it is a commonly known fact that the data release of OEMs is still limited. Therefore, the growth in customers is moderate. However, this might change with the further integration of additional OEMs and data sources. The potential is not yet really recognized by the market, but in the long run, the connected car API platforms could replace the OBD-II solutions as they might become more profitable on a larger scale.
Overall, when considering the potential industries, it is uncertain if there is already enough data being shared, e.g. for media research purposes, to be valuable for third-parties. Regarding personal services, it is questionable whether the use of the services brings substantial real benefit to a vehicle owner. This could be an indicator of why some industrial sectors are still hesitating to use vehicle data. For these sectors, market research and convinc- ing may still be required to justify these services on the basis of a connected car API platform. Furthermore, it must be evaluated how implementations perform under real-life conditions with real-life vehicles and how the compatibility of attributes looks like.” (Felix Dimmler, 2020)