Copyright © 2024 COVESA®. This document includes material copied from or derived from W3C VISS version 2 - Core.
The Vehicle Information Service Specification (VISS) is a service for accessing vehicle information, signals from sensors on control units within a vehicle's network. It exposes this information using a hierarchical tree like taxonomy defined in COVESA Vehicle Signal Specification (VSS). The service provides this information in JSON format. The service may reside in the vehicle, or on servers in the internet with information already brought off the vehicle.
This specification describes a third version of VISS which has been implemented and deployed on production vehicles. The first version of VISS only supported WebSocket as a transport protocol, the second version is generalized to work across different protocols as some are better suited for different use cases. The second version added support for the HTTP and MQTT transport protocols, subscription capabilities was improved and an access control solution was added.
There are three parts to this specification, [[CORE]], [[TRANSPORT EXAMPLES]], and PAYLOAD ENCODING. This document, the VISS version 3.0 PAYLOAD ENCODING specification, describes the VISSv3.0 payload encodings that is used in some cases. The companion specifications [[CORE]] describes the messaging layer, and [[TRANSPORT EXAMPLES]] describes the deviations form the CORE specification that are used by some transport protocols.
This document describes the payload encodings that is used by some transport protocols.
The acronym 'VISSv3.0' is used to refer to this document, the VISS version 3.0 specification. The acronym 'VSS' is used to refer to the 'Vehicle Signal Specification' which is hosted by COVESA. The term 'WebSocket' when used in this document, is as defined in the W3C WebSocket API and [[RFC6455]], the WebSocket Protocol.
The payload primary format is JSON. This means that the payloads received by a client SHALL have the JSON format, unless an implementation deliberately deviates from this. See the [[CORE]] document for the JSON payload format of the messages for the different transport protocols.
Protobuf, short for Protocol Buffers, is a language-neutral, platform-neutral, extensible mechanism for serializing structured data, developed by Google. This encoding method is particularly beneficial for efficient data serialization and deserialization, ensuring low latency and reduced payload size, which are crucial for vehicle information services.
The Vehicle Information Service Specification (VISS) defines a protocol for accessing vehicle data in a standardized manner. As vehicles become more connected and data-driven, the need for efficient data exchange methods becomes paramount. Protobuf encoding serves as an optimal solution within VISS due to its compact binary format and schema evolution capabilities.
In this chapter, we outline the integration of Protobuf encoding with VISS version 3.0, providing comprehensive details on schema definitions, encoding and decoding processes, and practical examples. This will enable seamless implementation and interoperability across different systems and platforms within the automotive ecosystem.
The following protobuf source code describes the VISS message payloads. Stored in a file e.g. named "viss.proto" the protbuf compiler (protoc) can be used to create helper functions that can be called to encode and decode between the JSON format and the protobuf format. The protobuf source code below also contains a "service" clause that the protoc compiler uses to create a gRPC based communication framework.
This part outlines how Protobuf encoding is realized across various transport protocols, including gRPC, WebSocket, and MQTT.
The 'service' clause in the Protobuf schema is used by the Protobuf compiler(protoc) to automatically generate code for gRPC-based communication. This code simplifies the implementation of server and client interactions by handling the details of network communication, allowing developers to focus on the application logic.
If a server supports protobuf payload encoding over the Websocket protocol then it shall be shown in the server capabilities data how the client configures this. Two mechanisms are defined:
If a server supports protobuf payload encoding over the MQTT protocol then it shall be shown in the server capabilities data which topic name that the server uses to listen for clients that want to issue requests with protobuf encoded payloads. The recommended topic name is the topic name used for the unencoded payload channel appended with the string "/protobuf".
The protobuf compiler uses the protobuf source code to generate an API to helper functions that can be used to implement the encoding and decoding between JSON and the protobuf format for the various VISS messages. The implementation of the encoding and the decoding is out-of-scope in this specification.
Several IDLs may take a JSON scheme representation of the interface description as input, e. g. OpenAPI and asyncAPI. The JSON scheme representation of the VISSv3.0 interface in the [[CORE]] specification can be used for such a purpose.