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

[jdacoello]

Unfortunately, I am not fully understanding your goal with this feature. I think the following work flow would be ideal:

• The specification has all the possible properties (i.e., sensor, actuator, attribute).
• Before exporting it, one can arbitrarily select a sub set of what has been specified.

Is this what you are trying to achieve? If so, it seems that the proposed approach is too complicated.

[SebastianSchildt]

Unfortunately, I am not fully understanding your goal with this feature. I think the following work flow would be ideal:

• The specification has all the possible properties (i.e., sensor, actuator, attribute).

I think this this will not change: You put "whatever" custom attributes in your model

• Before exporting it, one can arbitrarily select a sub set of what has been specified.

I think this can become a little more fool proof/checked. Currently basically you need to use -e parameter to tell vss-tools all extended attributes it should not panic about.

However, likely when you e.g. annotate how to map VSS signal to SomeIP or VHAL, there might be several attributes invovled that are needed, some optional, some required.

If we have a machine readable way to describe this in a seperate file/config, we have two advantages

• we would actually have a formal way to describe "this is the COVESA suggestion how you might map VSS to VHAL", or "this is how you might model QoS characteristics of a signal"
• Tooling can read the some descriptions of you say "Transfer this vspec, please note there are DBC mappings in"

So tool-wise it is maybe some - I think simple - sugar on features already there, giving some extra validation, and model-wise we would have a way to formally describe extensions that are optional and go beyond "datatype, unit, type"

[erikbosch]

As mentioned by Sebastian, a way to allow tooling to do a bit more of sanity checks. Today you can specify -e xxx and then most exporters will export whatever has been defined with the xxx attribute, like xxx: 123or xxx:"abc". But you have no way to infom vss-tools that xxx shall be mandatory for all your signals, or that xxx must be an integer value in the range 0-127.

That you can off course add as a check in your downstream project, but then it is not certain that some other project that wants to use the same extra attributes can reuse your checks. By defining a profile syntax and implementing some basic checks in vss-tools the set of extra attributes can easily be reused by different projects, if needed.