Modern vehicles use hundreds of sensors which produce thousands of different data points, or signals, amounting to terabytes of data available per vehicle per day. The data points available on modern vehicles range from door lock state, fuel or charge level to tire pressure sensors and anti-lock brake control unit status. There is no question vehicles are transforming, becoming connected, electric and autonomous all of which relies extensively on signals data. A common and standardized data model and interface facilitates rapid innovation and development of various use cases involving this data.
At the center of this effort is a common data model for these vehicle signals, namely the Vehicle Signal Specification (VSS) which is explained here explainer. To access this data in a standardized way an effort to develop an interface was initially started by W3C in collaboration with COVESA and in 2024 was transferred fully to COVESA, the Vehicle Information Service Specification (VISS). The service can reside either in the vehicle, or in the cloud. Client applications can also reside in the vehicle, cloud or running on a nomad device such as a smartphone.
Vehicle signals, the definition and access to them, has historically been OEM proprietary. This has made it difficult for suppliers, commercial fleets, tech companies, insurance companies, regulators and other interested parties to integrate across vehicle brands. Furthermore, since VISS and VSS are open standards their use will reduce cost, promote innovation, interoperability and facilitate third party software development.
VSS uses a tree structure with well-defined open definitions, but it also has the ability to be extended to handle new and /or proprietary signals if needed. The transport and access (API) together comprise the VISS version 2 specification, that includes HTTPS, MQTT, as well as Websockets which was the only transport protocol supported in the first version of VISS. The second and current version of VISS also includes a complete access control model, ability to support a consent model, and filtering techniques to better fit OEM requirements.
The intention is to use web technologies to facilitate development of applications with limited, trusted entities and not to make vehicles available for arbitrary connections over the web. Access to specific data points and use of the information is outside the scope of this work. It is expected automotive manufacturers will govern which parties can run logic on or against vehicles, manage permissions, conduct security and legal/privacy audits. Regulators and courts, Massachussets Right to Repair lawsuit as an example and the EU data act will undoubtedly influence this as well. VISS was designed as a technical solution to be flexible in accomodating the future business ecosystem. The COVESA Security and Data Expert Groups formal best practices which will include security and privacy aspects.
VISS version 1 deferred on access control to individual implementations and as mentioned only supported Websockets. Of the thousands of data points potentially available, a client application could subscribe to an allowed subset, and thus receive initial and updated values over time. The second version expanded on the filters available for Websocket and MQTT subscriptions and also allows for individual requests over these protocols and HTTPS of individual signals or if allowed a set of specified signals. For example, issuing a request to the node Vehicle.Drivetrain.Transmission would, if authorized, return all data available for a vehicle's transmission.
Notes on implementation and use
VISS has known implementations by Volvo, BMW, JLR, Renesas, Bosch, Visteon, Geotab, AGL and Mitsubishi Electric to name a few. The underlying data model VSS is seeing much wider adoption, e.g. within AWS Fleetwise, Blackberry Ivy as well as having accompanying ontology (VSSo) and graph schema for machine learning and generating knowledge graphs, since its uses go far beyond a single API.
A client application for example could reside on the vehicle itself on an on-board logic, telematics or head unit. From there it can authenticate itself against VISS and based on permissions granted for the specific application, can read or even write data to/from the vehicle. Applications may be user facing, providing information to operator or occupants or performing data sampling for analysis.
There are multiple uses for vehicle telematics data. Electric vehicle charging events can be combined with charging infrastructure, route planning and weather conditions to plan trips on a vehicles' behalf and ensure battery is not depleted. Insurance companies can use it, with owner/operator permission and typically in exchange for a discount on premium, to assess driving behavior. Fleet operators and mechanic services can assess vehicles performance and predict maintenance issues before they arise and leave a vehicle stranded. Information about a vehicles' status, location, fuel/charge level, diagnostics, etc can be conveyed to the owner on the head unit/in-vehicle infotainment or a trusted, paired smartphone.
Several projects gathered under the umbrella COVESA CVII are addressing the mentioned use cases and the required connectivity building blocks where VISS is an important component to address needs within the vehicle, cloud, AI/knowledge graph, service and solution level all centered on the common vehicle data model VSS. Various potential architectures are under discussion, especially as COVESA and AUTOSAR are seeking to increase collaboration. Architectural terms are maintained by COVESA as well as a Mira board of potential architecures which VISS might be a part of.
A standards based interface, and data model, supports interoperability between vehicle brands, and thus enables an open ecosystem where innovation of new services can thrive.