Proposal "struct": Just model as branches, the rest is deployment

This proposal argues, that VSS is already able to model the structure, and further impications such as describing a specific interfaxce are out of scope for VSS and shall be handled, deployment specific.

I guess we are again in the discussion what goes in the interface and what is the part of the model only. Or what do we have to model from a vehicle system and how at the end interface is realized.

If we go this way, next discussion will be how do we combine e.g. speed, position, wheel rotation and ambient temperature into custom message "myMessage" and can we model that in VSS?

I guess main motivation of VSS is how to have common setup around vehicle taxonomy/model and not messages or interfaces.

Example

---

myLidar.vspec

Will be used later in ADAS Lidar

Obstacle:
    type: branch
     aggregate: true
## aggregate can be translated to struct or whatever you prefer in the tooling even custom made tooling

Id:
    type: sensor
    datatype: int64

Probability:
    type: sensor
    datatype: float

---

myMain.vspec

Vehicle.ADAS.Lidar:
    type: branch

Vehicle.ADAS.Lidar.Front:
    type: branch
    
Vehicle.ADAS.Lidar.Front.Obstacles:
    type: branch
    #include myLidar.vspec Obstacles

---

Then you introduce for your deployment setup specific config file (or define a layer with specific keywords for your techstack), basically something that can help you with your specific IDL challenge for your deployment and usage of vss.

This might help you to generate some additional code automatically.

mycustom.depl

vehicle.adas.lidar.front.obstacles
    cardinality: many -> goes into repeated e.g
    type: struct, class, list whatever you find useful 
    ....

or you just generate granulated protobuf messages from VSS and rest of the code you write in your main protofile

-> message myCustomMessage( repeated VehicleAdasLidarObstacles myCustomData = 1)

Disadvantages

• Inconsistent array handling. Arrays of primitive types are natively supported using the datatype keyword while arrays of higher-order types (structs) are left to the deployment stage.
• Using branches results in a fragmented type system where primitives are defined as a property of sensors/actuators/attributes via the datatype keyword while higher-order types (structs) are defined outside the sensors/actuators/attributes as a branch.

Neutral

• This results in a fundamentally different model - higher order types (structs) are a combination of sensors/actuators/attribute values rather than sensors/actuators/attributes' value type being a struct.