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

[erikbosch]

Some partially unrelated topics if/when we are discussing "VSS instances v2.0"

• Do we want to support only 1 dimensional arrays/instances? Could make handling on dynamic instances on server side easier. Disadvantage that we may need "intermediate objects" like SeatRow/DoorRow
• Do we want to support only numeric instances - may make iteration easier?
• Do we want to modify expand pattern, e.g. "Vehicle.DoorRow1.Door1" Instead of "Vehicle.Door.Row1.Left"
  • "Vehicle.Axle.Row1.Wheel.Left"
• Do we want to generate some signals automatically when expanding, like "Vehicle.DoorRowCount", "Vehicle.Axle1.Wheel1.Instances"
• Do we want metadata to indicate if instances can be added dynamically or not

[erikbosch]

MoM:

• T: Numeric based instances may be liked by Jaspar
• T: but you loose context data
• T: But there might be semantics for coordinates, could be additional metadata. Like wheel15 - will have metadata to describe location.
• E: A bit similar AOSP zone concept.
• T: For efficiency - you can do discovery, but might be inefficient. Possibly static/start representation, to not have to dynamically check number of wheels on every startup
• E: inst_type: static | (semi) | dynamic
• T: Config may change. Static can be config available to all apps. Can also include what is semi-dynamic.
• D: Do not see a problem removing instance declaration from normative spec. With pre-defined instances and people change, then integrity is compromised
• D: Agreement needs to be clear.
• S: Discovery - doubtful about discovery. First passive - observing signals. If you do not see signal you do not know if it does not exist or there are some failure
• S: Active discovery will load your network, but user discovery shall be limited. You can check if trailer is connected. How often should we run discovery. Good to have some parameter for how often it shall be checked.
• E: If we e.g. want to visualize tire pressure for wheels on both truck and trailer, the app must either check regularly or observe some signal indicating changes
• S: For bus/truck, app needs to get reliable source of truth from somewhere
• S: Have looked at Yorito - they add extra signals for every entry, not that nice. Why not in the tree have only signals that exist.
• D: Often missunderstanding of the scope of VSS. What is missing in tooling is possible to select only a scope of the tree.
• D: Publishing schema registry
• S: Skeptical of adding additional signals. Implicit signals may double number of signals. Using some form of discovery
• E: Could possibly be rather server metadata

[wiedmama]

I think there are some limitations in the "instances" concept that might be overcome when we allow arrays of branches. A new attribute elements might be introduced to do so:

Example:

Vehicle.Chassis.Axle:
  type: branch
  description: Axle Signals
  elements: Axle[1,2]

Vehicle.Chassis.Axle.Wheel:
  type: branch
  description: Signals of a distinct axle
  elements: ["Left","Right"]

which is expanded to

Vehicle.Chassis.Axle1.Left
Vehicle.Chassis.Axle1.Right
Vehicle.Chassis.Axle2.Left
Vehicle.Chassis.Axle2.Right

There are two main differences compared to instances:

1. The branches Axle1 and Axle2 are children of Chassis not of Axle. So they are side by side on the same level like the branch item which describes them.
2. There are no "multidimensional" arrays. This should be no problem as an array of branches can directly hold another array of branches as child.

Putting the new elements on the same level offers the possibility to describe trees like

Vehicle.Implement2.Boom1.Section3
Vehicle.Implement1.Tank2

which is currently not possible with instances.

With instances it is also not possible to put items (attribute/sensor/actuator/branch) on every level. Using instances like done in Vehicle.Cabin.Door.Row1.DriverSide there is no possibility to have e.g. Vehicle.Cabin.Door.Row1.SideCount.

Expressing the same tree with elements it will look as

Vehicle.Cabin.Door.Row:
  type: branch
  description: High-level cabin door row data.
  elements: Row[1,2]

Vehicle.Cabin.Door.RowCount:
  type: attribute
  instantiate: false
  description: Number of doors
  datatype: uint8

Vehicle.Cabin.Door.Row.Side:
  type: branch
  description: High-level cabin door row data.
  elements: ["DriverSide","PassengerSide"]

Vehicle.Cabin.Door.Row.Side.SideCount:
  type: attribute
  instantiate: false
  description: Number of sides the door can be on
  datatype: uint8

It needs further discussions whether the elements should be limited to numeric, like Row1, Row2 or whether things like DriverSide, PassengerSide is still allowed. It is necessary when we want to avoid breaking changes. Using attributes to describe the "Side" of an item might be more productive in the end.

I think with this approach we can express the "numeric instances" in a more elegant way (might be useful for Jasper), have the flexibility to add items anywhere in the path and allow shorter paths in the end.

There should be no impact regarding tooling as long as the expanded model is used. I already wrote a prototype of the vss-tools to support elements which seems to work fine.

When we introduce rules how the Count is related to the actual number of branches, this also will be helpful for variant parts.

[UlfBj]

The proposal by @wiedmama solves the issues with the current instances concept. I support this proposal with the comments:
The element enumeration should support naming like DriverSide, PassengerSide, etc.
In the example above, the node Vehicle.Cabin.Door.RowCount does not require instantiate: false as it is not a child of Vehicle.Cabin.Door.Row.

[adobekan]

@wiedmama
Vehicle.Chassis.Axle1.Left Vehicle.Chassis.Axle1.Right Vehicle.Chassis.Axle2.Left Vehicle.Chassis.Axle2.Right
How would you identify here what is an array, e.g. how json would look or proto?

We had a very similar discussion on this topic some time ago, and I am trying to identify the issue / pr. It was very long chat, myb @erikbosch or @SebastianSchildt can help.

In any case, if you want to proceed with your proposed solution, you still need to define the "array" first and then work with its key elements or instances. This is precisely the purpose of using instances they provide a structured way to access and manage those elements.

With instances you can do quite some of these things, you can generate similar setup. Then if i am implementing API to grab all Axles i would be able to do it with Vehicle.Chassis.Axles.*

here is docu
Vehicle.Chassis.Axles.1 Vehicle.Chassis.Axles.2 Vehicle.Chassis.Axles.5
or
Vehicle.Chassis.Axles.Axle1 Vehicle.Chassis.Axles.Axle2 Vehicle.Chassis.Axles.Axle5

if you want to do what you are describing, go into actual upper level branch with direct tags, then i would suggest include. Because what you are referring to, it is not an array.
`Vehicle:
Chassis:

Axle1:
  type: branch
  include:
    - Axle.vspec

Axle2:
  type: branch
  include:
    - Axle.vspec`

also if you want to attach additional attributes, e.g. Axle 1 has different attributes e.g. some extra wheels on Axle2, or simply attribute is needed in the top branch, you can do that as well via overlay
here is docu
you can also remove attributes from the instance, just go for removing Nodes section.

Cheers,
Ado

[sschleemilch]

Vehicle.Implement2.Boom1.Section3
Vehicle.Implement1.Tank2
which is currently not possible with instances.

@wiedmama
Why not?

Vehicle:
  type: branch
  description: V
  instances:
    - Implement[1,2]

Vehicle.Foo:
  type: branch
  description: Foo
  instantiate: false

Vehicle.Bar:
  type: branch
  description: Foo

Vehicle.Implement2.Boom1:
  type: branch
  description: Boom1

Vehicle.Implement1.Tank1:
  type: branch
  description: Tank1

Vehicle.Implement2.Boom1.Section3:
  type: branch
  description: Section3

❯ vspec export tree -s model.vspec --strict
[17:40:29] WARNING  No 'quantity' files defined. Default not existing: /Users/Q534774/workspace/vss-tools/quantities.yaml         main.py:65
           WARNING  No 'unit' files defined. Default not existing: /Users/Q534774/workspace/vss-tools/units.yaml                  main.py:71
           INFO     VSpecs loaded, amount=1                                                                                     vspec.py:146
           INFO     Vehicle                                                                                                       tree.py:90
                    ├── Foo                                                                                                                 
                    ├── Implement1                                                                                                          
                    │   ├── Bar                                                                                                             
                    │   └── Tank1                                                                                                           
                    └── Implement2                                                                                                          
                        ├── Bar                                                                                                             
                        └── Boom1                                                                                                           
                            └── Section3

[wiedmama]

@sschleemilch :
Excuse me, I guess the example

Vehicle.Implement2.Boom1.Section3
Vehicle.Implement1.Tank2
which is currently not possible with instances.

was a little bit too compact. I tried to outline a tree where you can have e.g. 1..3 implements, each having 1..2 booms and 1..2 tanks on implement level and e.g. 1..32 sections on boom level.

Is this possible with instances? I failed trying to do so. Writing this I also had in mind a mechanism where the actual number of implements, booms, tanks, etc. might be overwritten or set by another mechanism like discussed already above. So writing each element manually is not an option.

[sschleemilch]

Vehicle:
  type: branch
  description: d

Vehicle.Door:
  type: branch
  description: d
  instances:
  - Row[1,2]
  - [DriverSide, PassengerSide]

If I understood correctly, you would like to attach something to all Row* instances without naming all of them explicitly?
If that's the case then yes, this is a current limitation that cannot be done.
Of course it can be done by modelling it a bit differently and not chaining the instances together, something like this:

Vehicle:
  type: branch
  description: d

Vehicle.Door:
  type: branch
  description: d

Vehicle.Door.Row:
  type: branch
  description: d
  instances:
    - [1,2]

Vehicle.Door.Row.Count:
  type: attribute
  description: d
  datatype: uint8
  instantiate: false

Vehicle.Door.Row.Side:
  type: branch
  description: d
  instances:
   - [Driver,Passenger]

Vehicle.Door.Row.Side.Count:
  type: attribute
  description: d
  datatype: uint8
  instantiate: false

I fear that having elements and instances at the same time might be a bit much to grasp the differences.
We might be able to tweak the current implementation though to say that when specifying Vehicle.Door.Row: and having instances defined in the way Row[1,2] that it should be attached to those children.

Is that the core of the limitation you see?

[UlfBj]

The elements concept main difference to the instances concept is as I see it that it does not add new levels of nodes to the branch, it modifies the node level where it is declared. This I see as an improvement that makes it worth replacing the instances concept with it. Even if both concepts can achieve the same results, it is expressed in a more understandable syntax with the elements concept.

[wiedmama]

Ulf is right: the difference is where the new items are placed. With instances they are created as child elements. Using elements they are generated side-by-side on the describing node level.

@sschleemilch :
It is possible to create the same expanded trees which are currently described with instances. But it also offers the the possibility do express something like

Vehicle.Implement<A>.Tank<B>.Level
Vehicle.Implement<A>.Boom<C>.Section<D>

Here the implements have both a tank and a boom array as children. This is not possible with instances. Using instances you always need a non-instance level in between which will end up in

Vehicle.Implements.Implement<A>.Tanks.Tank<B>.Level
Vehicle.Implements.Implement<A>.Booms.Boom<C>.Sections.Section<D>

And I still think the actual numbers for A, B, C should be described in a way that makes it easy to describe deviations like already discussed in this PR. I am sure there is a way to describe typical variation points which will be necessary when VSS is used beyond passenger cars.

Not directly related but triggering an idea: In your (@sschleemilch) example you created instances that will end up expanded in branches

Vehicle.Door.Row.1
Vehicle.Door.Row.2

Using vspec tool with the --strict option it complains that the names are not CamelCase. Maybe it is worth to think about allowing pure number branch names to show that these items are array elements. This would also "solve" the problem how to mark an item is an array element. My only doubt here is, that I am not sure whether existing implementations support pure number branch names.

[sschleemilch]

Ulf is right: the difference is where the new items are placed. With instances they are created as child elements. Using elements they are generated side-by-side on the describing node level.

Yeah, I get the idea and yes, you cannot express it with instances. So I am in general fine to change it but probably we only should have either instances or elements or change the current instances to behave like the elements.

That elements consumes the last part of the path might also not be that intuitive though.

[UlfBj]

I agree that the name instances is more intuitive than elements. So I am for keeping the name but change the behavior.

[adobekan]

@wiedmama
Could you please share an example with us where this is necessary?

[wiedmama]

@adobekan

Could you please share an example with us where this is necessary?

One example (as already written above) are nested branches

Vehicle.Implement<A>.Tank<B>.Level
Vehicle.Implement<A>.Boom<C>.Section<D>

Here the implements have both a tank and a boom array as children. This is not possible with instances. Using instances you always need a non-instance level in between which will end up in

Vehicle.Implements.Implement<A>.Tanks.Tank<B>.Level
Vehicle.Implements.Implement<A>.Booms.Boom<C>.Sections.Section<D>

Here you have up to 3 levels to describe the machine structure e.g. of a fertilizer. Moreover there are things like an ApplicationRate sub-branch which can be on implement, boom and/or section level, so this will be implemented as `#include' ending up in a path that gets even longer.

Regarding the name elements vs instances: I agree that the name instances is more intuitive but using the same syntax and change the behavior is dangerous as vspec files might be processed without errors but produce different vehicle trees as instances crates items as children whereas element do this on the same level. Therefore I searched for a new name and unfortunately up to now I found nothing better than elements but I'm free for suggestions here.

Besides this with instances you can create multi-dimensional instances like done in Doors

Vehicle.Door:
  type: branch
  description: d
  instances:
  - Row[1,2]
  - [DriverSide, PassengerSide]

which will not work with elements. So keeping the name while having different behavior and limitations will be even more confusing.

Introducing a new tag also allows a migration scenario where instances and elements can be used in the same tree. After a migration period, the instances might be marked as outdated/legacy an can be finally removed.

[UlfBj]

@wiedmama , your comments on naming are valid.
How about instances2? It could then at some point long after deprecation of instances be renamed to that.

[adobekan]

The elements concept main difference to the instances concept is as I see it that it does not add new levels of nodes to the branch, it modifies the node level where it is declared. This I see as an improvement that makes it worth replacing the instances concept with it. Even if both concepts can achieve the same results, it is expressed in a more understandable syntax with the elements concept.

Quite often we need those nodes. Otherwise you just start messing around with naming of concept and instances and then whole model is gone. Also, where do you add attributes that are related to all instances which you have? If we remove top node in many cases you will just have to extend attribute name and find a patch.

[wiedmama]

Quite often we need those nodes. Otherwise you just start messing around with naming of concept and instances and then whole model is gone. Also, where do you add attributes that are related to all instances which you have? If we remove top node in many cases you will just have to extend attribute name and find a patch.

You are right: We need a place to put everything that is related to all instances. But the "top node" is not removed, it is just side-by-side with the generated elements/instances:

Vehicle.Foo:
  type: branch
  description: Example branch
  elements: [1,3]

Vehicle.Foo.Count:
  type: attribute
  description: Actual available number of Foo branches
  instantiate: false

Vehicle.Foo.Value:
  type: sensor
  description: Some value on Foo
  datatype: float

Will generate

Vehicle.Foo.Count
Vehicle.Foo1.Value
Vehicle.Foo2.Value
Vehicle.Foo3.Value

This approach allows to keep the expanded tree the same and so should not affect all tools which work on expanded trees. The instantiate: false shows what is related to all instances (in the original vspec - not so clear in the expanded trees).

As already explained above I would also be fine if it generates

Vehicle.Foo.Count
Vehicle.Foo.1.Value
Vehicle.Foo.2.Value
Vehicle.Foo.3.Value

On the upside, with this approach it is clear that pure number branches are instances/elements of its parent branch. It is also clearly visible what is common for all instances (everything else).

On the downside, I am not sure whether all tools can handle pure number branches and it would be a breaking change as the resulting expanded tree would be different.

[UlfBj]

@wiedmama I think your examples breaks the elements model.
To generate
Vehicle.Foo.Count
Vehicle.Foo1.Value
Vehicle.Foo2.Value
Vehicle.Foo3.Value
I believe the declaration should be:
Vehicle.Foo:
type: branch
description: Example branch
elements: Foo[1,3]

To generate
Vehicle.Foo.Count
Vehicle.Foo.1.Value
Vehicle.Foo.2.Value
Vehicle.Foo.3.Value
I believe it should be:
Vehicle.Foo:
type: branch
description: Example branch

Vehicle.Foo.FooInstances:
type: branch
description: Example branch
elements: [1,3]

Or have I misunderstood the new model?

[wiedmama]

@UlfBj

Or have I misunderstood the new model?

In short: No you were right.
To generate

Vehicle.Foo.Count
Vehicle.Foo1.Value
Vehicle.Foo2.Value
Vehicle.Foo3.Value

The declaration should be

Vehicle.Foo:
type: branch
description: Example branch
elements: Foo[1,3]

Vehicle.Foo.Count:
  type: attribute
  description: Actual available number of Foo branches
  instantiate: false

Vehicle.Foo.Value:
  type: sensor
  description: Some value on Foo
  datatype: float

It should be elements: Foo[1,3] not elements: [1,3]. This was my original suggestion.

The other/new approach came in my mind when I read the remarks of @adobekan which includes paths like
Vehicle.Chassis.Axles.1 Vehicle.Chassis.Axles.2 Vehicle.Chassis.Axles.5. If is is "legal" to have paths which are pure numbers we might limit the elements to generate pure number branches. In contrast to my original suggestion they are again created as child elements (be aware that it will create e.g. Foo.1 instead of Foo1):

Vehicle.Foo.Count
Vehicle.Foo.1.Value
Vehicle.Foo.2.Value
Vehicle.Foo.3.Value

can be generated by

Vehicle.Foo:
type: branch
description: Example branch
elements: [1,3]

Vehicle.Foo.Count:
  type: attribute
  description: Actual available number of Foo branches
  instantiate: false

Vehicle.Foo.Value:
  type: sensor
  description: Some value on Foo
  datatype: float

which is quite the same instances is doing in the moment. The only change would be that elements is limited to one generated level and to pure numbers. But on the plus side, the generated pure number branches will indicate that these are generated element branches.

But as already explained, this will be a breaking change as the generated models will be not the same and it is only possible if pure number branches are allowed and supported by tools.

[UlfBj]

New name proposal: array
array: element[1,3]
array: [element1, element2]

[wiedmama]

@UlfBj
array sounds good for me as it shows the intention (creating an array of branches).

From your example I assume that you want to avoid pure number branches. I guess we will run intro trouble with pure number branches: When e.g. an SDK is generated with access objects, the class names will bee based on the branch name but class names in many programming languages must not be numbers.

To allow an assignment of the generated elements to the owning parent I would like to suggest that the generated branches names always start with name of the base branch:

Vehicle.Foo:
type: branch
description: Example branch
array: [1,3]

will expand to

Vehicle.Foo1
Vehicle.Foo2
Vehicle.Foo3

[UlfBj]

@wiedmama , I believe that e. g. JASPAR wants pure number nodes in their "VSS tree". So although I agree with you that it might lead to trouble in some scenarios I think we should leave that judgement to the implementers of the trees. The same goes for the relationship between parent/child node names. I do not think we should restrict it as you propose above, but leave also this to the judgement of the implementer.
array: [1,3] should lead to pure number nodes.

[UlfBj]

In the CVIS project we are defining a trailer tree that shall include a path structure as shown below,
Trailer.Chassis.Axle.Liftable.AxleConfig
Trailer.Chassis.Axle.Liftable.Pos1.Position
Trailer.Chassis.Axle.Liftable.Pos2.Position
..
..
Trailer.Chassis.Axle.Row1.Wheel.Pos5.Brake.FluidLevel:
Trailer.Chassis.Axle.Row1.Wheel.Pos5.Brake.IsBrakesWorn:
..
..
Trailer.Chassis.Axle.Row12.Wheel.Pos7.Brake.FluidLevel:
Trailer.Chassis.Axle.Row12.Wheel.Pos7.Brake.IsBrakesWorn:
..

This was attempted to be achieved with the vspec below but VSS-tools rejects it as a Critical model error.
Commenting out instantiate: false line below passes but does not generate the desired path structure.

Axle:
instances: Row[1,15]
type: branch
description: Axle branches, max 15.

#include Axle.vspec Axle

Axle.Liftable:
type: branch
instances: Pos[1,5]
instantiate: false
description: Axle liftable features

#include AxleFeature/Liftable.vspec Axle.Liftable

I cannot see how to get around this deficiency of the instances concept (I guess this is what @wiedmama has pointed to already). If that is the case I would say the decision to replace it with the array concept should be straight forward as I believe it can generate the wanted path structure.

[sschleemilch]

I don't see why not:

Vehicle:
  description: d
  type: branch

Vehicle.Axle:
  instances:
    - Row[1,2]
  type: branch
  description: d

Vehicle.Axle.Wheel:
  instances:
    - Pos[1,2]
  description: d
  type: branch

Vehicle.Axle.Liftable:
  type: branch
  instances:
    - Pos[1,2]
  instantiate: false
  description: d

Vehicle.Axle.Liftable.Position:
  type: sensor
  datatype: uint8
  description: d

Vehicle.Axle.Liftable.AxleConfig:
  type: branch
  description: d
  instantiate: false

           INFO     VSpecs loaded, amount=1                                                                                                       vspec.py:146
           INFO     Vehicle                                                                                                                         tree.py:90
                    └── Axle                                                                                                                                  
                        ├── Liftable                                                                                                                          
                        │   ├── AxleConfig                                                                                                                    
                        │   ├── Pos1                                                                                                                          
                        │   │   └── Position                                                                                                                  
                        │   └── Pos2                                                                                                                          
                        │       └── Position                                                                                                                  
                        ├── Row1                                                                                                                              
                        │   └── Wheel                                                                                                                         
                        │       ├── Pos1                                                                                                                      
                        │       └── Pos2                                                                                                                      
                        └── Row2                                                                                                                              
                            └── Wheel                                                                                                                         
                                ├── Pos1                                                                                                                      
                                └── Pos2 

The only valid deficiency of instances is that you will always need a branch node in between instance definitions if you want to attach something on all of those instances, which is not the case here.

[UlfBj]

@sschleemilch you are right. This was what I believed I was doing, but after looking closer I found i did not. Thanks for triggering me to look closer :).
My comment above can be disregarded in the context of this thread. Sorry for the confusion.

[sschleemilch]

See COVESA/vss-tools#545 for a possible solution by introducing a new keyword instances_relation that takes either child which is the default and does behave like the old instances and sibling which will replace the node its defined in with the expanded instances.