Decoupling instance handling from model

[erikbosch]

This is a PR for discussion. Now and then we have discussed how to handle instances as they typically varies. This ticket concerns an idea of decoupling instance definition from the actual tree. In shot - anyone can use what instances they find useful for their vehicle. But for reference VSS can publish a default instance set to get same signals as today.

vspec export yaml -u ./spec/units.yaml --strict -s ./spec/VehicleSignalSpecification.vspec -o vss.yaml -l spec/default_instances.vspec

• Advantage - Makes it easier to customize as needed
• Disadvantage - risk that there will be no "common" model on where/how to define instances.

The latter could possibly be handled by both documenting recommended instantiation models ("use RowX for axles") or alternatively by adding syntax support to define "allowed" instance models for signals, like instance_type: ROW_POS. We could also just give recommendations in the default_instances.vspec

If we go this way we need to agree on what our standard release assets shall contain - with/without default instances.

Related to #898 #810 #642 #564

[UlfBj]

We will seriously risk interoperability if we leave it as a recommendation. The existing instances should remain, the documentation should describe how the cardinality of instances can be updated using overlays.

[SebastianSchildt]

Maybe the issue here ist just wording? Technically (and usability-wise) I would love to finally split out instances (as it would make it more clear you are not "breaking" VSS law per se if you need to add another row of seats or remove one.

At the same time it should not be be/feel like "oh look you could do instances here is an example but we do not care" (like the motorbike overlay currently, that neither is nor do we feel that it is in any way normative).

However I my point of view a good way forward is

• Splitting out instances like @erikbosch described
• Making sure you NEED an instance file in tooling (so if e.g. seats is istantiated, you can not get away with jsut compiling the tree without providing instance information
• Like @UlfBj said: Describe clearly how you can change instance cardinality by overlay or by modifying the default instance file
• As per the second point: When we release VSS still incorporate the usual "Vanilla Passenger Car instances" as it is now: So like today, anyone "touching" VSS for the first time, gets sort of the standard passenger car superset of datapoints

That way I think it is more clean technically without diminishing the current normative (soft :))power of VSS

[erikbosch]

As Ulf states, if we introduce this it would be a major change as backward compatibility for users may be broken. But how much users are affected would depend on how they use VSS

• If they use "master" and just use release artifacts there should be no difference
• If they use "master" and build using Makefile no changes should be needed
• But if they build themselves directly with e.g. "vehicle export ..." they would need to add an extra argument with the instance file.

If they use a fork of VSS, already has overlays or similar things where they for example change instances things might get a bit complicated, as order of overlays then would matter, and there might be corner cases I have not thought of yet.

We may add a mandory instance file argument. But if so we may need to accept that it is empty as there might be models were no instances are used.

The documentation in https://covesa.github.io/vehicle_signal_specification/extensions/overlay/index.html mention instances, so it is already possible to change instance handling with overlays. This PR focus more on whether we actually should define number of wheels, number of seats and so on in std catalog or not. Some of the older issues propose introduction of "instance pattern". That could be an option if we from a model perspective wants to dictate how for example seat instances shall be named, but not exactly which shall exist.

[erikbosch]

MoM:

• U: Do not think it is good to remove it from vspec files. We could have example showing how to change it
• T: Concept of VSS instances is an issue for truck OEM, how can we handle discovery. We need to come up with guidelines, like vehicle specific configurations.
• T: Paul could add to TST for discussion
• T: Could have a discussion next week here
• T: We need to add discovery too
• U: App could cache instnace info
• E: or we could have attribute on how dynamic the instances are.

[erikbosch]

some of the recent Slack discussion for reference