VSS plan for next AMM October (Dearborn, Michigan, US) 2022

[erikbosch]

We need to start discussing how we want to set up the VSS parts for the next AMM (2.5 days), what features do we want to present or discuss in working sessions. Potential topics includes overlays.

Please provide ideas, so we can discuss at upcoming meetings.

[erikbosch]

Two ideas for sessions/discussions

Variation handling in VSS

The signal needs of e.g. a motorbike differs from the needs of a normal passenger car. A potential solution to this is to use the overlay mechanism to create profiles for various types of vehicles. This can be used to e.g. add motorbike-specific signals to a motorbike profile, but it could also be used to add/remove signals based on specific vehicles.

Discussion topics:

• What should be in "core VSS", and what shall be in vehicle-type profiles?
• Shall e.g. sunroof signals be in standard VSS and removed in motorbike profile, or should it only exist in the passenger-car-profile?
• What profiles do we see as needed for the near future
• Need for recommendation for overlay structure (e.g. use in order "standard VSS spec" + "vehicle type profile" + "OEM generic additions" + "Vehicle specific overlays")

Meta data handling in VSS

The support for overlays and arbitrary attributes in VSS makes it possible to add overlays to specify static information on e.g. accuracy/frequency/security for a signal.

Discussion topics:

• Do we want COVESA/VSS to create recommendations on attribute names and/or attribute syntax to use, that possibly can be used by servers like VISS or for manual analysis of e.g. performance. data usage and security concepts
• Do we also want to prepare recommendations on meta-data that can be included in single data observations of VSS. E.g. propose what identifier to use if timestamps are to be provided together with data observations, and/or propose fields for e.f. "data source", "accuracy/precision" and similar. This could possibly be used as input for anyone implementing VSS support (like e.g. VISS)
• What areas/standards/methods do we see as prioritized? Do we e.g. consider it important to "standardize" attributes for meta-data needed for tools to be able to distribute VSS data over CAN or SOME/IP (e.g. event id or PDU id)

[erikbosch]

Another topic: VSS and VSC relationship

[fringley]

Something that came up in the AAOS working group yesterday is how we include metadata specific for code generation into the Android VHAL. E.g. should this be an AAOS specific file, just using the VSS property naming, or could/should this be included as metadata in a "main" VSS file.

And on from that, should these AAOS metadata properties have a defined prefix in their name e.g. aaosId, or be nested under a defined hierarchy within the VSS property, e.g.

aaos:
     id: example

[SebastianSchildt]

Sound like a job for an overlay. So basically an addtional file, that tooling understands. That would need to be flat then, and of course some defintion would be needed what to call the fields, and what their meaning.

That basically would give the chance to annotate ever sensor or actuator or attributed with for e.g. aaos-id: <something>

See here https://covesa.github.io/vehicle_signal_specification/rule_set/overlay/
right picture "newKey" example

[fringley]

Makes sense. An overlay is how the current poc/example is working, so perhaps that is ok as it stands.

[kkoppolu1]

Discussion topic suggestion: Supporting complex data types - #326

[erikbosch]

@erikbosch to discuss with @adobekan and fill in https://wiki.covesa.global/display/WIK4/Data+Expert+Group+Working+Internal+planning+page+for+COVESA+AMM+October+2022 before end of week.
Draft shall preferably be ready before Data expert Group meeting on Thursday

Possible additional topics (in addition to overlays):

• How to not break backward compatibility and governance.
• How to organize overlays

[erikbosch]

Document at https://wiki.covesa.global/display/WIK4/Data+Expert+Group+Working+Internal+planning+page+for+COVESA+AMM+October+2022 updated, feel free to review it.