Understanding VISS: The Connected Car's API

Demystifying Vehicle Information Service Specification (VISS)

In the rapidly evolving landscape of connected vehicles, accessing and utilising data from a car's myriad sensors and systems has become paramount. Consumers increasingly expect seamless integration of their vehicles into their digital lives, mirroring the experiences they have with their smartphones and smart home devices. However, the automotive industry's data space has historically been fragmented and complex. Enter the Vehicle Information Service Specification (VISS), an automotive API designed to provide consistent and unified access to this crucial vehicle data. This specification, spearheaded by organisations like COVESA, aims to simplify the development of innovative software-defined and connected vehicle applications by establishing a common language for vehicle data.

What is VISS and Why is it Important?

At its core, VISS is a standardised Application Programming Interface (API) that allows applications to interact with vehicle data in a predictable and uniform manner. It leverages the Vehicle Signal Specification (VSS), a common data model that defines a structured way to represent signals and attributes within a vehicle. This commonality is vital for fostering interoperability across different vehicle manufacturers and platforms, significantly easing the development process for third-party applications and services. The project's roots trace back to the W3C around ten years ago, initially focusing on a simple publish/subscribe and get/set interface over WebSockets. Over time, it has evolved to incorporate additional protocols like HTTP and MQTT, a robust access control model, and sophisticated subscription triggering conditions. In 2024, the project transitioned from W3C to COVESA, marking a new chapter in its development, with the recent release of VISS version 3.0 Release Candidate 0 available for public review.

The COVESA VISS: Addressing the Data Disconnect

The current automotive reality often presents a messy and disconnected vehicle data landscape, falling short of consumer expectations for integrated digital experiences. COVESA's involvement signifies a concerted effort to standardise this space. The COVESA Vehicle Signal Specification (VSS) serves as the backbone, exposing vehicle information in a consistent JSON format. This service can reside either within the vehicle itself or on internet servers, with data potentially pre-fetched from the vehicle. This approach aims to bridge the gap between the complex internal workings of a vehicle and the user-friendly, data-driven applications consumers have come to expect.

How VISS and VSS Work Together

The Vehicle Information Service Specification (VISS) defines a WebSocket-based API that enables client applications to perform several key operations:

• GET: Retrieve the current value of a specific vehicle signal.
• SET: Modify the value of a vehicle signal (where permitted).
• SUBSCRIBE: Register interest in receiving real-time updates when a signal's value changes.
• UNSUBSCRIBE: Cancel a previous subscription.

The purpose of this specification is to promote a server API that facilitates application development consistently across various automotive manufacturers. The underlying data model, the GENIVI Vehicle Signal Specification (VSS), provides a hierarchical 'tree-like' structure for vehicle signals, allowing for extensibility and the definition of private branches. Signals are identified by their path, for example, Signal.Drivetrain.InternalCombustionEngine.RPM. Clients can request metadata to understand the available signals and their structure.

The VSS Data Model: A Hierarchical Approach

The VSS defines a directed acyclic graph (DAG) representing the vehicle's components and signals. Major vehicle structures form the upper levels of the tree, with logical assemblies and components as child nodes. This decomposition continues until leaf nodes are reached, which represent individual signal or data attribute values. This structured approach ensures that data is organised logically and can be easily navigated by applications.

Consider the following illustrative example of a VSS tree structure:

Signal.Drivetrain.InternalCombustionEngine.RPM Signal.Body.Door.Row1.Left.IsLocked Attribute.Body.BodyType 

Key Operations and Message Structures

VISS defines a clear message structure for client-server communication, primarily using JSON over WebSockets.

1. Authorisation

For accessing signals that require permission, clients must first authorise themselves by sending an authorize request. This typically involves passing security tokens (e.g., OAuth 2.0) representing the user and/or the device making the request. The server validates these tokens and, upon success, grants access with a specified Time To Live (TTL).

Example Authorize Request:

{ "action": "authorize", "tokens": { "authorization": "user_token_value", "www-vehicle-device": "device_token_value" }, "requestId": "103" }

Example Authorize Success Response:

{ "action": "authorize", "TTL": 3600, "requestId": "103" }

2. Metadata Request

Clients can query the available data signals using the getMetadata action. This allows applications to discover the vehicle's data schema, including signal paths, descriptions, and types. Metadata can be requested for the entire schema or specific branches.

Example Metadata Request:

{ "action": "getMetadata", "path": "Signal.Drivetrain.InternalCombustionEngine.RPM", "requestId": "104" }

Example Metadata Success Response:

{ "action": "getMetadata", "requestId": "104", "metadata": { "Signal": { "description": "All signals that can dynamically be updated by the vehicle", "type": "branch", "children": { "Drivetrain": { "description": "Drivetrain data for internal combustion engines, transmissions, electric motors, etc.", "type": "branch", "children": { "InternalCombustionEngine": { "description": "Engine-specific data, stopping at the bell housing.", "type": "branch", "children": { "RPM": { "description": "Engine speed measured as rotations per minute.", "min": 0, "max": 20000, "type": "UInt16", "id": 54, "unit": "rpm" } } } } } } } }, "timestamp": 1496087968995 }

3. Get Signal Value

To retrieve the current value of a signal, a get request is used. This can be for a single signal or multiple signals using wildcards in the path.

Example Get Request:

{ "action": "get", "path": "Signal.Drivetrain.InternalCombustionEngine.RPM", "requestId": "105" }

Example Get Success Response:

{ "action": "get", "requestId": "105", "value": 2372, "timestamp": 1489985044000 }

4. Set Signal Value

The set action allows clients to modify signal values. This is subject to access control and whether the signal is writable.

Example Set Request:

{ "action": "set", "path": "Signal.Body.Trunk.IsLocked", "value": true, "requestId": "9078" }

Example Set Success Response:

{ "action": "set", "requestId": "9078", "timestamp": 1489985044000 }

5. Subscriptions

For real-time data, clients can subscribe to signals. The server then sends subscription notifications when the signal's value changes. Clients receive a unique subscriptionId to manage these subscriptions.

Example Subscribe Request:

{ "action": "subscribe", "path": "Signal.Drivetrain.Transmission.TripMeter", "requestId": "1004" }

Example Subscribe Success Response:

{ "action": "subscribe", "requestId": "1004", "subscriptionId": "35472", "timestamp": 1489985044000 }

Example Subscription Notification:

{ "action": "subscription", "subscriptionId": "35472", "value": 36912, "timestamp": 1489985044000 }

6. Unsubscribe

To stop receiving notifications, clients use the unsubscribe action with the corresponding subscriptionId. The unsubscribeAll action can be used to terminate all active subscriptions.

Example Unsubscribe Request:

{ "action": "unsubscribe", "subscriptionId": "35472", "requestId": "5264" }

Example Unsubscribe Success Response:

{ "action": "unsubscribe", "subscriptionId": "35472", "requestId": "5264", "timestamp": 1489985044000 }

Security and Privacy Considerations

VISS places a strong emphasis on security and privacy. Access control is a fundamental aspect, ensuring that only authorized users and devices can access specific vehicle signals. This is managed through token-based authentication. The specification also mandates the use of encrypted communications, typically over Secure WebSockets (WSS), to protect data integrity and confidentiality. Implementing robust security practices, including secure token management and protection against replay or spoofing attacks, is the responsibility of both client and server implementers.

Security Principals:

• User: The individual or entity making the request (e.g., driver, service provider).
• Device: The origin of the request (e.g., in-vehicle system, user's smartphone).

Access control policies can be granular, allowing different signals to have different access requirements based on the security principals involved.

Server-Side Filtering

To optimise performance and reduce network traffic, VISS supports server-side filtering for subscriptions. Clients can request notifications based on intervals, value ranges, or minimum changes. This allows the server to send data only when certain conditions are met, preventing unnecessary data transmissions.

Example Filtered Subscription:

{ "action": "subscribe", "path": "Signal.Drivetrain.InternalCombustionEngine.RPM", "filters": { "interval": 500, "minChange": 10 }, "requestId": "1234" }

This request asks for RPM updates every 500 milliseconds, but only if the value has changed by at least 10 RPM.

Use Cases and Future Potential

The primary target platform for VISS is passenger vehicles. However, its principles can extend to other applications. Potential use cases include:

• Predictive Maintenance: Alerting drivers to potential issues like low tyre pressure or oil levels.
• Smart City Integration: Sharing vehicle data with traffic management systems for optimised flow.
• Infotainment and Navigation: Providing context-aware services based on vehicle status.
• Fleet Management: Monitoring and managing vehicle performance and location.

By standardising vehicle data access, VISS plays a crucial role in integrating vehicles into the broader Web of Things (WoT), paving the way for a new generation of intelligent and connected automotive services.

Frequently Asked Questions (FAQ)

What is the primary goal of VISS?

The primary goal of VISS is to provide a standardized and consistent API for accessing vehicle data, enabling the development of interoperable connected vehicle applications across different manufacturers and platforms.

What is the role of VSS within VISS?

VSS (Vehicle Signal Specification) defines the common data model used by VISS. It provides a structured, hierarchical way to represent vehicle signals and attributes, ensuring consistency in data representation.

What communication protocols does VISS support?

VISS initially supported WebSockets and has since added support for HTTP and MQTT protocols.

How is security handled in VISS?

VISS employs a token-based access control model and mandates encrypted communication (typically WSS) to ensure data security and privacy. Clients must authorize themselves with tokens to access protected signals.

Can I subscribe to real-time data changes?

Yes, VISS allows clients to subscribe to specific vehicle signals. The server will then send notifications whenever the signal's value changes, with options for server-side filtering to manage the frequency of these notifications.

Is VISS limited to passenger vehicles?

While primarily designed for passenger vehicles, the specification's principles are not strictly limited to them. However, its design and content are focused on this segment.

What happens if a token expires?

If a token expires while a subscription is active, the server will send a subscriptionNotificationError. The client must then renew the token and potentially re-establish access or subscriptions.

Can I access data from any vehicle using VISS?

Access to vehicle data via VISS depends on the vehicle manufacturer implementing a VISS-compliant server and the application having the necessary authorization and permissions.

Conclusion

The Vehicle Information Service Specification (VISS) represents a significant advancement in the connected automotive space. By establishing a common API and data model, it lowers the barrier to entry for developers, fosters innovation, and ultimately aims to deliver the seamless, integrated digital experiences that consumers expect from their vehicles. As COVESA continues to develop and refine VISS, its adoption will be key to unlocking the full potential of software-defined vehicles.

If you want to read more articles similar to Understanding VISS: The Connected Car's API, you can visit the Automotive category.