Vehicle Data Interfaces

Modern cars are loaded with sensors and actuators the continuously monitor the vehicle and allow control of its functions. However, all of that is essentially limited mostly to the car itself and to what the maker of the vehicle intended it to do, as there are no APIs that other systems can access. That's a pity since data from the sensors and vehicle functions could potentially be used for so many more things that provide value to vehicle owners, passengers, traffic systems and more. Various car makers have started addressing this problem by providing APIs that third-party applications can access. Unfortunately, there are no standards for that, which limits the application to a single car maker unless the developer also writes code to integrate the application with other car makers' APIs.

The Automotive Working Group is developing a series of specifications allowing web developers to write applications running in a web browser or an embedded web runtime on a car's infotainment system to access signals from vehicle sensors and to carry out actions via the vehicles actuators.

The Challenge

Accessing a vehicle's hardware and software platform is vastly different from accessing sensors on mobile devices. There are many unique challenges to overcome:

• Modern cars are distributed compute systems. Sensors and actuators are connected to a multitude of electronic control modules (ECU) which in turn are connected to each other via various buses and networks. Some ECUs also function as gateways between buses and networks.
• ECUs and the buses and networks connecting them are different from car maker to car maker and are not even the same between different models of the same car maker. While virtually all car makers connect ECUs using controller area network (CAN), the application protocols are different.
• Currently the automotive industry has no standard convention for vehicle data APIs. While most cars have similar data signals, the naming is different from car maker to car maker.
• While the majority of modern cars share a minimum set of common signals, the range of signals can vastly vary by make, model, and type of vehicle. Luxury cars tend to have more features and instrumentation than entry level vehicles.
• While car makers are interested in making a subset of the signals available to developers they also want to be able to extend APIs with private signals for their own purposes.
• Layered and granular security mechanisms are required that provide authentication and authorization to access vehicle signals and controls. Car makers need to be in control of what applications are granted what access and that credentials and rights cannot be stripped and transferred from one application to the next.
• The design needs to decouple the software programming and signal interface from the electrical architecture of the vehicle.

The Working Group is addressing these challenges with two specifications for Vehicle Information Services Specification (VISS) and for Vehicle Information API Specification (VIAS). These specifications build on top of GENIVI's Vehicle Signal Specification (VSS) which provides a tree-like hierarchical standardization of vehicle signals and their names.

Conventional Approach - The "Fat API"

The conventional approach models a system as a collection of objects that interact with each other. Each object defines attributes and methods through which information is exchanged. For example a JavaScript snippet to access a vehicle's speed using a conventional API could look like this:

var vehicle = navigator.vehicle;
vehicle.vehicleSpeed.get().then(function (vehicleSpeed) {
   console.log("Vehicle speed: " + vehicleSpeed.speed);
}, function (error) {
   console.log("There was an error"); });

There are some issues with this approach:

• Addition of new signals and controls requires a change of the specification.
• Changes require modification of the implementation.
• Calling non-existing or purposely non-provisioned APIs create run time errors.
• Maintaining backwards compatibility can become a challenge as signals and controls evolve.
• Authorization and access control on a per-API basis is complex.
• Single point addressing means that only one signal can be accessed at a time.
• Vehicles can have many hundreds of different signals and controls. Providing objects and APIs for all of them makes the system complex and hard to use.

New Approach - Services with Signal Tree

Instead of providing APIs for every signal, this approach only provides four core services which are passed a signal tree as arguments to address the signals:

• get - retrieve the current value of a signal
• set - set the value of a signal
• subscribe - receive notification if a signal has changes
• unsubscribe - stop receiving notifications for a signal

In addition to the four core services there are two services providing authorization and introspection:

• authorize - present credentials to access signals
• introspect - obtain a data structure containing the currently authorized signals

Signals are organized as a logical tree as shown in the illustration.

The tree structure provides for hierarchical access to signals and attributes. The branches group signals and attributes into entities that logically belong together. The leaves of the tree represent the signals and attributes. Signals are addressed using dot-notation for name paths:

Signal.Chassis.Brake.FluidLevel
Signal.Drivetrain.FuelSystem.Level
Attribute.Cabin.Door.Count
Attribute.Engine.Displacement

The last path component represents the signal or attribute. The leading path components represent the branches. A fully qualified name addresses a single signal or attribute. Wildcards allow addressing multiple signals and/or branches.

Vehicle Data Interfaces Architecture

The architecture for the vehicle data interfaces comprises the two components Vehicle Information Services (VIS) and Vehicle Information API (VIA). VIS is implemented as a web socket server to which VIA, essentially a JavaScript library on top applications are built, connects to. This two-component architecture provides for the most flexibility and re-usability: the services of the web socket server can be used by other components in the vehicle and the JavaScript library can run in any web browser and web runtime envrionment. The latter avoids implementation of a native API into web browsers and web runtime environments making browser dependencies on the vehicle platform unnecessary. The platform-dependent component is just the web socket server which is a much simpler component than a web browser or a web runtime environment.

As the JavaScript library running inside a web browser and/or a web runtime environment uses a network socket connection to the web socket server the components can be distributed to different systems inside the vehicle as shown in the illustration: web browser / runtime environment are running on the IVI system, frequently also referred to as headunit, while the web socket server is running on the telematics control unit (TCU). The can, of course, also quite easily run on the same system.

General Security Architecture

Security is paramount for in-vehicle systems for obvious reasons. Security must be part of the vehicle platform and built bottom-up. That is the very reason why VISS and VIAS actually do not define a security architecture at all. The only define security principals, a method to pass a security token from an application via the API call to the web socket server, and minimum requirements for the security token:

• Path - the signal path the token authorizes. The path may be a branch name or contain wildcards to authorize entire branches.
• Actions - list of actions that the token authorizes for the path. The list contains at least one of the actions introspect, get, set, subscribe and unsubscribe.
• Valid From - UTC time stamp indicating the date and time from which on the token is valid.
• Valid Until - UTC time stamp indicating the date and time until which the token is valid.

Format and encoding of the security token are not defined by the specification. VIAS and VISS treat them as opaque data structures. That allows car makers and their suppliers to implement them as it fits their platform security strategy best. There is also no requirement for an implementation of the web socket server to interpret the security tokens itself. It may pass them on to underlying components of the software stack.

GENIVI-specific Security Architecture

The illustration depicts the security architecture for a GENIVI platform.

In this architecture the Remote Vehicle Interaction (RVI) Core implements the security mechanisms. RVI uses JSON Web Tokens (JWT) for representation of security claims. The JWT contain the authorizations for an application as well as the application's public key. JWT are then signed (or potentially encrypted) with a private key from the car maker's key ladder. The car maker acts as the signing authority and all private keys from the ladder are protected by the car maker's IT infrastructure. When RVI Core receives an authorization token it validates it with the public key matching the car maker's private key. When an application wants to issue a command to RVI Core, it signs its request using its private key. RVI Core validates the signature with the application's public key retrieved from the JWT. If the signature is confirmed, RVI Core checks the request against the authorizations from the JWT. If the application is authorized, RVI Core executes the command.

RVI Core handles requests coming from the internal web socket server as well as requests received from other RVI Cores such as cloud services. The same security mechanism applies to all of them.

RVI Core does not itself process any vehicle signals but passes the requests on to the Vehicle Signal Interface (VSI). VSI is a signal abstraction and high-performance software switchboard connecting data sources and sinks. It has interfaces for the various vehicle buses and supports publish and subscribe.

For all native applications running on the GENIVI platform which uses Linux as its operating system, the OS's security mechanisms are used for mandatory access control. For GENIVI it is SELinux that grants RVI Core access to VSI, VSI access to hardware buses, etc. The GENIVI security team develops threat models and analyzes the components for potential vulnerability.

The GENIVI platform security architecture is only one possible implementation. Car makers and their suppliers can implement an architecture that best suits their needs. Car makers are ultimately responsible for evaluating applications that are looking to access vehicle signals and potentially carry out actions. They also have to issue the security tokens.

This article is only a condensed overview of VISS, VIAS and the architecture for it. All of it is work in progress and subject to continuous evolution and improvement.