Vehicle Data and the Connected Driver

Initially connecting the phone to the car has been about displaying content from phone into vehicle.  With Apple’s CarPlay and Google’s Android focused on extending mobile content to the car, they are missing the real value of connecting the car and smartphone:  Driver Centric Data.

With the growth of vehicle centric APIs providing greater access to the vehicle data, the number of possible solutions expands to include vehicle health, diagnostics, roadside assistance, automatic crash notification, etc. combining the best of both vehicle and the smartphone services.  By combining both open vehicle APIs with the personalization of the smartphone, connected drivers can enjoy a personalized experience with remote climate control, smart radio and dynamic media.

Having access to vehicle data can make these connected systems even more valuable beyond simply extending the existing smartphone functions into the car.  That is the reason why many of the connected car solutions expanded into vehicle data APIs.  Application developers are just getting exposed to vehicle data and are trying to figure out what they can do with it. However, to unleash the creative genius of the broader development community, the vehicle data API needs to be simple, understandable and consistent across the various technologies and OEMs.

Vehicle APIs can be broadly broken into three groups: Direct Vehicle Data, Phone Based, and Remote Vehicle Data APIs.

Direct Vehicle Data APIs are exposed when the application is directly connected to the vehicle and is typically used when the driver is inside the vehicle. These APIs allow developers to both read and control vehicle services. Direct APIs started out as proprietary APIs that were exposed to developers as part of the embedded operating system and the applications needed to reside on the IVI system to access the APIs.

With the advent of open application frameworks in the vehicle such as Android and HTML 5, there is a need to expose vehicle APIs to the third-party app developers. Some of the car makers are starting to expose such APIs and make it easier for third-party developers outside of the relatively small automotive app developer pool. For example, GM has recently announced the availability of 350+ vehicle data signals for their HTML5 based Next Generation Infotainment (NGI) https://developer.gm.com/ngi.

These APIs assume the applications are running on a connected device (like a phone or tablet) and connect directly to the infotainment systems.  The developers can access the vehicle data from a connected phone versus an embedded application on the head unit. There are more stringent security requirements though, as they are running on a brought-in device. Examples of such systems are Smart Device Link (SDL), which provides a set of vehicle APIs (see more details below) or Abalta’s WebLink.

This API group is another category of APIs (typically phone or web based) that allow applications to control some aspects of the vehicle when the driver is outside the vehicle. For example, such APIs allow to lock/unlock the vehicle, remote start it, remote climate control, etc.  The communication with the vehicle is done through a web server that in turn communicates with the telematics unit inside the vehicle.

The GENIVI Alliance is working on Remote Vehicle Interaction (RVI) API: https://github.com/GENIVI/rvi_core

There have been many attempts over the years to provide standards based access to vehicle.  The earliest and most successful of these attempts is the hardware centric OBD – II interfaces.  OBD-II has been a mandated standard since 1996 in the USA and 2001 in the EU.  There are a multitude of OBD-II solutions in the market that combine the requisite OBD-II hardware and a smartphone application.  These solutions remain hardware centric versus API driven data solutions.  The W3C and GENIVI are attempting to move to a software centric standards based solution.

GENIVI® is a nonprofit industry alliance that produces automotive software components, standard APIs, and a development platform for in vehicle infotainment and connected vehicle solutions based on open platforms and standards such as Linux.

In 2016 GENIVI has published a Vehicle Signal Specification (VSS):  https://github.com/GENIVI/vehicle_signal_specification.  It is a standardized vehicle signal specification that allows for an industry actor to use a common naming space for communicating vehicle state and, ultimately, allows the decoupling of the IVI stack from the underlying vehicle electrical architecture. The vehicle signals are vendor independent. Vendor-specific extensions can be specified in a dedicated and uncontrolled branch of the signal specification tree.

The specification currently defines 1093 separate vehicle signals.

The Word Wide Web Consortium (W3C) has an automotive working group that has proposed few specifications related to vehicle data.

In 2014 the group created a draft for Vehicle Information Access API (https://rawgit.com/w3c/automotive-bg/master/snapshots/vehicle_spec_snapshot_latest.html), which defines a JavaScript API to get/set or subscribe for vehicle data. The actual data is defined in a separate specification – Vehicle Data (https://rawgit.com/w3c/automotive-bg/master/snapshots/data_spec_snapshot_latest.html).

W3C is now working on a draft for Vehicle Information Service (VIS) https://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html. It is based on the GENIVI’s VSS.

The specification defines a protocol of how vehicle can expose vehicle signals and static data via a WebSocket.

We are excited about GENIVI’s Vehicle Signal Specification. It creates a simple and consistent API for the various vehicle related platforms (embedded, phone-side, native and web applications). It also makes the transfer of data between the head unit and the phone or the cloud very extensible, and easily manageable.

With WebLink, we have adopted the VSS as main mechanism to transfer vehicle data and expose API to the applications.  With W3C adopting it too, we hope that more platforms will adopt it and it will become de facto standard for vehicle data.  Then the app developers can focus on writing useful applications that utilize vehicle data, and not worry about “yet another vehicle data API” that they should integrate with.