Mechanism(s) to define what signals that are supported in a vehicle

[erikbosch]

A recurring topic is how to handle vehicle variation - how can you find out which signals that are supported by a specific vehicle? This issues intends to capture the discussion.

A few mechanisms mentioned now and then:

• Additional VSS signals (like IsSunroofInstalled) that you can query
• Opt-in (for example layer specifying which signals that are supported)
• Opt-out (layer to remove signals)
• Dynamic content (If server has no current value for "IsSunroofClosed" then likely your car has no sunroof)
• Default value for "not present"

This issue originates from a discussion in #625

[adobekan]

I would expect that something like this is handled by infrastructure.
->discoverAll
Something like this could be realized by any implementation which is using VSS.

Adding additional VSS values would increase complexity and at the end someone would have to do those mappings.
What we have to make sure is that something like adding new or omitting defined VSS leafs is possible.
We can discuss if this could be potentially linked trough description of vehicle configuration files.

[erikbosch]

Maybe we need to link it to the deployment scenarios we have identified. Discovery-mechanisms might work for some use-cases, but for others some form of config file specifying what signals that are supported (the "opt-in" alternative) might be better. And "supported" is maybe not the only factor, if you are allowed to use it might be equally important. Like if you offer a fat VSS API for third party developers, it sort of makes sense that the API only contains read/write-methods for the signals they actually are allowed to read/write.

[adobekan]

If we talk about API details, here i would prefer specs like ViSS to handle these details. Vehicle configuration file we could discuss, in the scope of what Features vehicle is supporting. E.g. Seatheating, SeatMassage and then link those features to specific leafs.