Senior Research Engineer: Data Architecture, Connected Vehicle, Standards & Platforms
BMW Group
Part1: Complex data types
A recurring topic during the last years has been whether VSS needs to support complex data types (like structs) or not. Now we have a proposal to extend the VSS array concept so that it can be used also for branches. That allows a branch to be used a struct or as an array consisting of a struct. The intention of this session is to discuss the proposal, if it fulfil the needs of VSS users and implications on VSS implementations/protocols like VISS and Kuksa.val.
References:
VSS issue with background information: https://github.com/COVESA/vehicle_signal_specification/issues/326
Example using arrays for branches: https://github.com/kkoppolu1/vss-tools/commit/a544eff05c18b4dfcc208d6110deda6aeea32886
Part 2: Meta data handling
The newly introduced VSS overlay concept can be used to add static metadata to VSS signals. This can for example be used to specify how VSS signals shall be transferred or how they can be mapped to other protocols. An example use-case could be to define metadata to describe how VSS signals can be mapped to Android Automotive signals, or how VSS signals can be extracted from CAN communication.
The intention with this session is to discuss:
What areas do we see as most important to support?
For these areas, can COVESA specify a complete mapping or only define the attributes to use?
Example: Android mapping might be generic, mapping to CAN signals is OEM specific.
What interest exist from member companies to contribute or drive this topic?
This is a working session for the VSS project. Everyone is welcome, but VSS knowledge is required to be able to participate in the discussion.