VSS Layers Concept

Starting point: VSS Composable Layers

USE CASES

There are two major use-cases for layering

Proprietary additions to the vocabulary

Those proprietary changes expand the vocabulary of signals/attributes, which should not go upstream (yet). In case of the decision to publish them it should be easy to do so.

This layering approach is already given by the private branch. A possible improvement here would be merging of sub-branches, instead of simple overwrite.

Deployment requirements

In case VSS gets deployed, customisation is needed for various reasons (vehicle configuration, markets, etc.). Those changes are not changing the vocabulary itself but rather its usage.

Overwriting meta data

There's meta data, which is static, as it defines the standard vocabulary. This data shouldn't be changed. But there's meta data, which changes with the configuration of the vehicle, like instantiation of components (e.g. doors). Configuration specific meta data shall be changeable.

Adding meta data

Certain configurations need specific meta data at time of deployment. It can be a specific vehicle configuration, privacy settings, markets or mapping and adapting of original source data towards the taxonomy. This meta data has to be attached to the original specification.

Defining a subset of nodes

Almost all vehicle configuration only support a subset of nodes. That should be configurable.

Approaches

What to standardise in layer concept

Additional meta data often differs quite a lot. An generic approach with tool support makes sense. Defining keys for additional meta data only in generic cases (e.g. access rights, etc.)

Data Format

As YAML is used for the specification, it should be the same for VSS Layers.

Placing the files

Next to spec files

One option is to follow the structure of the specification, with a specific ending.

PROS

• Follows approach of specification

CONS

• Hard to do with include, as additional meta data will be often on leaf level. Through include the structure of the spec is not equivalent with the structure of the tree
• Many layers clutter the spec

One single file per layer

One option is to create one file with all nodes for adding and overwriting meta data per configuration/deployment.

/spec/...
/layers/
/layers/config-xy.layer

PROS

• Same structure as the tree
• Clearly separates vocabulary (somewhat global) and layer information (somewhat local)
• Skeleton can be created through tooling

CONS

• Different way of handling spec and layers

Tooling support

• Layer file(s) as additional input of compiler
• Skeleton can be created through tooling
• Improvement of merge case in private branch