Skip to content

Proposal "struct": "Weak" layer reference to external IDLs

Jump to bottom Edit New page
Sebastian Schildt edited this page Jul 25, 2022 · 4 revisions

This tries to reduce the effort for https://github.com/COVESA/vehicle_signal_specification/wiki/Proposal-%22struct%22:-Reference-external-IDLs and make it deployment specific like https://github.com/COVESA/vehicle_signal_specification/wiki/Proposal-%22struct%22:-Just-model-as-branches,-the-rest-is-deployment

This takes advantage of the fact, that VSS already supports uint8[] as datatype and all existing tech stacks are expected to work with it.

The example would look like this

ADAS.Lidar.Front
    type: branch

ADAS.Lidar.Front.ObstacleList
    type: sensor  
    datatype: uint8[]

Then we may have an overlay myprotostack-overlay.vspec

ADAS.Lidar.Front
    type: branch

ADAS.Lidar.Front.ObstacleList
    type: sensor  
    protomsg: ObstacleListMessage

You might generate

python vspec2json.py ../spec/VehicleSignalSpecification.vspec -e protomsg -o myprotostack-overlay.vspec.vspec --json-pretty out.json

which will generate a JSON as before, and if you load it in e.g. a VISS stack such as KUKSA it will just deal with a uint8[] datapoint, no modifications needed.

You also might imagine a .protpo tooling, that is called the same way

python vspec2proto.py ../spec/VehicleSignalSpecification.vspec -e protomsg -o myprotostack-overlay.vspec.vspec --json-pretty out.json

That will express the VSS model in terms of protobuf and rolling the messages referenced by protomsg directly into the model

You could build similar things for other stacks/IDLs of course

Advantages

  • No changes needed to VSS
  • It will work with all existing VSS stacks out there

Disadvantages

  • Information about the data structure is lost to VSS stacks that do not know how to handle this form of data specifically

Neutral

Add a custom footer
Clone this wiki locally