Skip to content

Latest commit

 

History

History

vss

README.md

KUKSA VSS Data

Introduction

KUKSA is adapted to use Vehicle Signals Specification as defined by COVESA. Officially released versions are available at the COVESA VSS release page. For convenience JSON versions of the official VSS catalogs has been copied to this repository.

Included VSS versions

Version Used as default in Databroker versions
VSS 4.1
VSS 4.0 0.4.0 -
VSS 3.1.1 0.3.1
VSS 3.0 0.2.5 - 0.3.0
VSS 2.2
VSS 2.1
VSS 2.0

Known limitations

  • VSS 3.1 is not supported as it contains a branch without description. Descriptions are mandatory in VSS but that is currently not checked by vss-tools. However, KUKSA.val databroker requires description to be present. Use VSS 3.1.1 instead.

Change process

This is the process for introducing support for a new VSS version:

  • Copy the new json file to this folder, note that VSS releases use a a slightly different naming convention, adapt the name to the pattern used in KUKSA.val
  • Check if KUKSA.val code relying on VSS syntax needs to be updated to manage changes in syntax
  • Check if examples needs to be updated due to changed signal names or syntax
  • Change build scripts and examples to use the new version as default
    • Search for the old version number and replace where needed
    • Known suffixes to search for vss_release_ include *.md, *.sh, *.cpp, *.txt, *.ini
    • Also check all Dockerfile
  • Some files (*.txt) instead list all versions, there just add the new version
  • If needed, adapt or extend test cases to use the new version instead of previous version
  • Remember to also integrate new version in KUKSA Feeder repository

Release Candidate Handling

VSS-project has started to use release candidates. A possible approach to verify VSS release candidates is:

Create Pull-Requests based on the release candidate. Copy the file "as official version" to kuksa.val/kuksa.val.feeders. I.e. even if version is v4.0rc0 copy it as v4.0. Only where there is a formal reference to a VSS release/tag use the full name. When official release is created replace the copied *.json-file (if needed), regenerate derived files, (if any, currently only in kuksa.val.feeders), and update github links in this file.

Tests after update

Kuksa-val-server unit tests

Kuksa-val-server smoke test

Examples:

Start and authorize with generated token:

$ python -m kuksa_client
Welcome to Kuksa Client version 0.2.1

                  `-:+o/shhhs+:`
                ./oo/+o/``.-:ohhs-
              `/o+-  /o/  `..  :yho`
              +o/    /o/  oho    ohy`
             :o+     /o/`+hh.     sh+
             +o:     /oo+o+`      /hy
             +o:     /o+/oo-      +hs
             .oo`    oho `oo-    .hh:
              :oo.   oho  -+:   -hh/
               .+o+-`oho     `:shy-
                 ./o/ohy//+oyhho-
                    `-/+oo+/:.

Default tokens directory: /home/erik/.local/lib/python3.9/site-packages/kuksa_certificates/jwt

connect to wss://127.0.0.1:8090
Websocket connected!!

Test Client> authorize /home/user/.local/lib/python3.9/site-packages/kuksa_certificates/jwt/super-admin.json.token

Check that changes to the new version has taken effect, e.g. that new signals exist or that changed or added attributes are present.

Test Client> getMetaData Vehicle.Powertrain.Transmission.DriveType

Do some set/get on new signals to verify that it works as expected.

Test Client> setValue Vehicle.CurrentLocation.Longitude 16.346734

Test Client> getValue Vehicle.CurrentLocation.Longitude

Kuksa-val-server and dbc2val smoke test

Run dbc2val as described in documentation using example dump file. Verify that no errors appear in kuksa-val-server log. Not all signals in the mapping files are used by the example dump file, but it can be verified using Kuksa Client that e.g. Vehicle.Speed has been given a value.

Kuksa-val-server and gps2val smoke test

Run gps2val as described in documentation using example log. If gpsd already is running at port 2947 a different port like 2949 may be used. Then gps2val config file must also be updated to use that port. If device handling does not work on test platform -t can be used to uss TCP instead.

gpsfake -t -P 2949 simplelog_example.nmea

If everything works as expected successful set requests with values similar to below shall be seen:

VERBOSE: SubscriptionHandler::publishForVSSPath: set value 48.811483333 for path Vehicle.CurrentLocation.Latitude
...
VERBOSE: SubscriptionHandler::publishForVSSPath: set value 8.927633333 for path Vehicle.CurrentLocation.Longitude
...
VERBOSE: SubscriptionHandler::publishForVSSPath: set value 12.244000434875488 for path Vehicle.Speed

The Kuksa Client can be used to verify that data actually is correctly interpreted.

Test Client> getValue Vehicle.CurrentLocation.Latitude
{"action":"get","data":{"dp":{"ts":"2022-08-19T14:04:43.339202324Z","value":"48.780133333"},"path":"Vehicle.CurrentLocation.Latitude"},"requestId":"025e5b10-d389-4a96-ba43-46f6a8c06b9e","ts":"2022-08-19T14:04:43.1660914283Z"}

Kuksa_databroker smoke test

Build and run kuksa_databroker using the new VSS file according to documentation, e.g.

$cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_4.0.json

Use the client to verify that changes in VSS are reflected, by doing e.g. set/get on some new or renamed signals.

$cargo run --bin databroker-cli

client> set Vehicle.CurrentLocation.Latitude 3
-> Ok
client> get Vehicle.CurrentLocation.Latitude
-> Vehicle.CurrentLocation.Latitude: 3

Kuksa_databroker and dbc2val smoke test

Run dbc2val as described in documentation using example dump file. It is important to use databroker mode.

./dbcfeeder.py --usecase databroker --address=127.0.0.1:55555

Verify that no errors appear in kuksa-val-server log. Not all signals in the mapping files are used by the example dump file, but it can be verified using Kuksa Client that e.g. Vehicle.Speed has been given a value.