Ulf Björkengren - Ford Motor Company
Peter Winzell - Volvo Cars
This project provides a reference implementation of the released COVESA VISSv2.0 specification on the v2.0 branch, the master branch contains reference implementations of the VISSv3.0 and the subsequent VISSv3.1 specifications.
A tutorial can be found here.
- Support for the HIM Vehicle data profile.
- This enables VISS to support not only the VSS tree but also other trees that are defined using the vspec syntax.
- It also enables a set of trees to be exposed to clients.
- Support for the Unix Domain Socket transport protocol.
- Support for Set request out-of-order evaluation (Issue#100). //Not yet implemented on VISSR
- Multiple tree support. The server can be configured to manage multiple trees that a client can access.
- Server capabilities. A Server tree can be accessed by clients.
- File transfer. Upload/download of files is available on Websocket.
- Data compression. Request local path compression and Request relative timestamp compression is available on Websocket.
- Protobuf encoding is available on Websocket.
- gRPC support. This wa already available on an experimental level in VISSR @v2.0.
- JSON scheme used to validate client requests.
- Support for the VSS struct datatype.
- Error responses due to JSON scheme errors contain a description generated by the JSON scheme validator.
- The filter keyname "type" is changed to "variant".
- The filter variants "static-metadata" and "dynamic-metadata" are replaced by the variant "metadata".
- The "subscriptionId" parameter in unsubscribe response messages is deleted.
- The error object keyword "message" is changed to "description".
- The error:decription values are not normative any more.
- HTTP/Websocket/MQTT(incl app-level protocol on top).
- Get/Set/Subscribe/Unsubscribe methods (Subscribe/Unsubscribe not available over HTTP).
- Filters supported are Timebased/Change/Range/Curvelog/Paths/Metadata (History currently inactivated).
- Access control including RBAC support and policy document usage as per specification.
- Consent support. The server may connect to an External Consent Framework and together realize consent functionality.
- Unix domain sockets is supported. Payload formats are identical to Websocket format. Socket file name is /var/tmp/vissv2/udsMgr.sock.
- HTTP, Websocket, and gRPC can be configured to run with/without TLS.
- gRCP is supported also by the v2.0 server implementation (not in v2.0 spec).
- SwCs such as feeder and datastore are available to realize a complete tech stack from client to the vehicle "native" domain.
- Tool for realizing a data mapping between the "VSS domain" and the vehicle "native" domain (e.g. between VSS and CAN data).
Two shell scripts are available for a quick start of trying out the VISSR tech stack. System dependencies such as having a Go build system installed must first be fulfilled.
- runtest.sh: This script builds and runs the server and the feederv3 simulating some signals, then it runs the testclient and displays its request messages and the associated response messages.
- runstack.sh: This script builds and runs the server and the feederv3 simulating some signals, enabling any client implementation to connect to the server.
See the tutorial for more information.
Described in TESTING.md.
The main principle is that the master branch shall featurewise be in synch with the latest version of the VISS specification. Experimental features that are not supported in the specification shall be kept on topic branches. If/when the experimental features on a topic branch become supported in the specification then the branch shall be merged to the master branch. The list below shows the current set of branches.
- master: features that are not dependent on new features introduced on the branches below.
- v3.1.5: features related to DDS support. Branched off master.
- v3.2: features related to VISS Service profile support. Branched off master.
- v4.0: features related to VDM support. Branched off v3.2.
Features pushed to master shall be merged to the v3.1.5, v3.2 and v4.0 branches. Features pushed to v3.1.5 shall be merged to the v3.2 and v4.0 branches. Features pushed to v3.2 shall be merged to the v4.0 branch.
VISSR is an open standard and we invite anybody to contribute. Currently VISSR contains - among others - significant contributions from