Concept for specifying VSS-tools profiles?

[erikbosch]

A topic that is mentioned now and then is the possibility to add and possibly standardize additional metadata to VSS signals to describe "feature of interest", "safety/security classification", "CAN dbc mapping" and similar. In VSS that is already possible by using extended attributes.

Vehicle.Speed
  type: sensor
  datatype: float
  unit: km/h
  my_own_attribute_1: 123
  my_own_attribute_2: "free text"

The tooling supports extended attributes, if you specify -e my_own_attribute_1 -e my_own_attribute_2 no warnings will be given and the extra attribute will be present in generated files like yaml, csv, json.

I am thinking of two potential "improvements"

Concept for defining profiles

To provide better re-usability and control of extended attributes I am thinking if it would make sense to define a profile format, possibly like below. That profile could be loaded by vss-tools and be used to validate signals in the catalog. That could be useful if you for a particular deployment need to provide some extended attributes for every signal.

myprofile:
  mandatory: true # If true all signals must use this profile, so they must have "my_own_attribute_1"
  my_own_attribute_1:
    mandatory: true
    unit: uint16
    description: "Describes xxxxx"  
  my_own_attribute_2:
    mandatory: false
    unit: string
    description: "Describes xxxxx"  

This could then be added as input to vspec

vspec export csv -p /some/path/to/myprofile.yaml

Managing a catalog of profiles

It would be possible for VSS (or VSS-tools) repo to host a folder with contributed and/or recommended profiles. I.e. if a COVESA member or a downstream project has defined a profile they think is generally useful, then it could be contributed to COVESA so that also other downstream solutions could use it.

Note that the profile catalog would only define the extended attributes that are possible to use, it would (most likely) not provide actual values to use for the signals in VSS Standard catalog as that would differ from case to case.

[erikbosch]

MoM:

• Presented at meeting
• Ulf: Correct to add in vss-tools rather vss. For VISSr we use "validate"
• Ted: Used for data campaigns in commercial vehicles
• Please discuss in issue