Proposal "struct": "Weak" layer reference to external IDLs - COVESA/vehicle_signal_specification GitHub Wiki

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

This is basically "tunneling" (anyone remember stuffing base64 in CDATA in XML? :) ).
Your techstack may not "understand" what it is handling there, but in the end it does not matter, it is always about the endpoints understanding the semantics of data (even true for VSS)
Will never be used in standard catalogue

Comparison with modeling using branch

Whether you like this better, or an approach outlined in https://github.com/COVESA/vehicle_signal_specification/wiki/Proposal-%22struct%22:-Just-model-as-branches,-the-rest-is-deployment is just a matter of taste. However, the difference between reusing branches for modeling higher-order data types and referencing external IDLs (multiple proposals) is that
When using branches, sensors/attributes/actuators can still take only primitive types such as int, float, etc
When using external IDLs, sensors/attributes/actuators can take higher-order types (structs) defined in an IDL

For this reason, the external IDL approach fits better semantically - extending the "data type" that the sensors can take. With branches, we get a fragmented system where higher-order types (structs) are defined as branches and primitive types are specified within the sensor/actuator/attribute node as a datatype property.

Proof of concept

Commit: https://github.com/kkoppolu1/vss-tools/commit/4f5d922e7edfc93a7c51dfc0f08c6dd690760f80