Page History

By Ulf Björkengren, Senior Software Architect, Ford

The Vehicle Information Service Specification version 2(VISSv2) developed in the W3C is a service for accessing vehicle data, reading from sensors, or writing to actuators on the vehicle's network. It exposes this data using a hierarchical tree-like taxonomy defined in COVESA Vehicle Signal Specification (VSS). The service provides the data in JSON format. The service may reside in the vehicle, or on servers on the internet with information already brought off the vehicle.

VISSv2 specifies three transport protocols that are allowed to be used in client-to-server communication. The Websocket and MQTT alternatives are payload compatible, so a client can issue requests over either of these transport protocols without modification of the payload. HTTP where the path information is explicit in the URL is not fully payload compatible. In a typical scenario, the server is deployed on a high-performance ECU running Linux, and clients can either be deployed off-vehicle (e.g., in the cloud or on a mobile device in proximity of the vehicle), or in-vehicle then typically on another HPC ECU, or the IVI ECU.

As described above, the VISSv2 specification supports a wide array of scenarios but there are of course scenarios not covered. To fill a bit of this gap, an experimental addition of gRPC support besides the other transport protocol alternatives can now be found on the VISSv2 reference implementation. The implementation is payload compatible with the Websocket and MQTT alternatives, and it can be configured to run over TLS. Using protobuf for the serialization, the payload is after protobuf encoding in binary format and obviously not identical on byte level to the others where the payloads have text format. But after protobuf decoding on the receiver side, the payload is again identical also on the byte level. So, a client making use of the protobuf transcoding interface can use the same payloads on any of these transport protocols.

...