-
Notifications
You must be signed in to change notification settings - Fork 170
Proposal "struct": "Weak" layer reference to external IDLs
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: ObstacleListMessageYou 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
- No changes needed to VSS
- It will work with all existing VSS stacks out there
- Information about the data structure is lost to VSS stacks that do not know how to handle this form of data specifically
- 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
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.
Commit: https://github.com/kkoppolu1/vss-tools/commit/4f5d922e7edfc93a7c51dfc0f08c6dd690760f80