search

COVESA / vehicle_signal_specification

Vehicle Signal Specification - standardized way to describe automotive data
Mozilla Public License 2.0
319 stars 164 forks source link

[VSS2] Position-related branches proposal #81

Closed klotzbenjamin closed 3 years ago

klotzbenjamin commented 5 years ago

The current VSS contains about 1100 signals in total, but only about 300 if we remove the position-related redundancy. The data model would also benefit from an udate of how positions are described, to make a clearer difference between what branches physically represent (composents, domains) and there position branch (Front, Left, Row1...).

Currently we have for instance Signal.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure to describe the tire pressure on the front left tire. The metadata of this signal, and of its hosting branch is the same as in Signal.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure, Signal.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure, Signal.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure

In addition, there is no fix rule about position modeling, and in the same example, there is the branch Wheel between 2 position branches.

Proposal We could dedicate a branch type to positions, and add a dedicated symbol (for instance "-") in a similar way as URI parameters. So for instace the previous example could become: Signal.Chassis.Axle-Row1.Wheel-Left.Tire.Pressure Where the branches Chassis and Wheel are parametrized with their position. Or even Signal.Chassis.Axle.Wheel.Tire.Pressure-Row1.Left Where the signal is parametrized with the position.

This could be a way of not only remove redundant concepts, but also allow access on multiple positions at once with a wildcard, as proposed in https://github.com/GENIVI/vehicle_signal_specification/issues/48

gunnarx commented 4 years ago

@danielwilms

In this sentence...

I like it to have it in the entire path, as it gives a clear mapping to what is multiplied. Also, it avoids duplication. Take Axle as an example. In case you have multiple leafs under it, you have to specify each and every time the amount of axles.

...I believe you are aiming for something similar to what I was proposing:

@gunnarx wrote:

Vehicle.Chassis.Axle.Row[1..2].Tire.[Left,Center,Right].Pressure

Is that true? If so, please note this. It is easier to understand if referring to examples and what was previously said than only writing a new description in your own words (a lot of misunderstandings).

...And we soon need a real full example. The above line was intended to show the kind of structure we need. The actual example needs of course to be written in the full YAML model format

@danielwilms wrote:

In case you have multiple leafs under it, you have to specify each and every time the amount of axles.

I am not sure if you wrote the correct thing here. I think where I was going with this is that there are multiple children but those are not leaves. Ulf's proposal seems to already allow for multiple leaves since extensibility is defined at the first parent of the leaf nodes?

I think you (and I) are describing that a logical modeling of the car's physical structure allows for instances further up the tree. But maybe that in the end becomes too complex, I don't yet know.

For an example, let's assume there is some MovementSensor on each wheel axle that measures rotational speed as well as vibration, and that for some reason there are two on each axle for redundancy:

Here are 4 rows of axles, each having 2 sensors (on left and right): (the word Row is sometimes redundant but let's keep going with it).

Is this what you also are talking about @danielwilms ?

Vehicle.Chassis.Axle.Row[1..4].Tire.[Left,Right].Pressure Vehicle.Chassis.Axle.Row[1..4].MovementSensor[Left,Right].RotationSpeed Vehicle.Chassis.Axle.Row[1..4].MovementSensor[Left,Right].Vibration

instead of this:

Vehicle.Chassis.Axle.Tire.Pressure.Row[1..4][Left,Right] Vehicle.Chassis.Axle.RotationSensor.RotationSpeed.Row[1..4][Left,Right] Vehicle.Chassis.Axle.RotationSensor.Vibration.Row[1..4][Left,Right]

@UlfBj I think it is in a case like this when there are multiple sub-trees that the "instances" of the axles becomes mentioned in more than one place of the tree. The hierarchy also becomes a little weird (because the upper level structure like the Axles/Rows gets mentioned in the leaf).

Looking at: Vehicle.Chassis.Axle.RotationSensor.RotationSpeed.Row[1..4][Left,Right] The word "Row" feels like it is in the wrong place.

gunnarx commented 4 years ago

Maybe the RowX nodes should be discarded, and should be declared as Axle[1..X] instead?

Just to answer this: Yes in a final model I think so. For now we are dealing with bigger issues, so it is OK if we keep going with the example.

UlfBj commented 4 years ago

I think you (and I) are describing that a logical modeling of the car's physical structure allows for instances further up the tree. But maybe that in the end becomes too complex, I don't yet know.

I agree that this is the point that differs between @danielwilms and @gunnarx view, and @UlfBj view. And yes, I believe it becomes too complex if going with your view.

I think it is in a case like this when there are multiple sub-trees that the "instances" of the axles becomes mentioned in more than one place of the tree.

Yes, the instances becomes mentioned in multiple places in the tree. But in the YAML source that governs this it is only mentioned once. And if you count the total number of nodes for the two cases, it is the same.

The hierarchy also becomes a little weird (because the upper level structure like the Axles/Rows gets mentioned in the leaf).

I agree, but that is due to the "weird" relation between Axle and Row[1..4]

Just to answer this: Yes in a final model I think so. For now we are dealing with bigger issues, so it is OK if we keep going with the example.

If we agree that Row[1..4] shall be replaced by Axle[1..4], and Axle removed, then I think we should use that structure in this thread.

UlfBj commented 4 years ago

Going with the view to allow instances further up the tree, we have to deal with the case of multiple instance declarations in a subtree. Which I guess must be forbidden, or else this model is only for people finding three-dimensional chess easy;).

UlfBj commented 4 years ago

Just for fun I copied all branches containing Axle in the id-file and transformed it to the instance model, including replacement of Row[1..2] with Axle[1..2], see below. I think it looks great! The exercise also led to finding an error in the existing tree: Vehicle.Chassis.Axle.Row2.WheelCount is missing This would not happen with the new instance model.

* Existing structure ***** Vehicle.Chassis.Axle.Count Vehicle.Chassis.Axle.Row1.TireDiameter Vehicle.Chassis.Axle.Row1.TireWidth Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.BrakesWorn Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevel Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.PadWear Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.PressureLow Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Temperature Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.BrakesWorn Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.FluidLevel Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.PadWear Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.PressureLow Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Temperature Vehicle.Chassis.Axle.Row1.WheelCount Vehicle.Chassis.Axle.Row1.WheelDiameter Vehicle.Chassis.Axle.Row1.WheelWidth Vehicle.Chassis.Axle.Row2.TireDiameter Vehicle.Chassis.Axle.Row2.TireWidth Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.BrakesWorn Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.FluidLevel Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.PadWear Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.PressureLow Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Temperature Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.BrakesWorn Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.FluidLevel Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.PadWear Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.PressureLow Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Temperature Vehicle.Chassis.Axle.Row2.WheelCount // Missing in VSS tree Vehicle.Chassis.Axle.Row2.WheelDiameter Vehicle.Chassis.Axle.Row2.WheelWidth

* New structure ***** Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Left Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Right Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle2.Left Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle2.Right Vehicle.Chassis.Wheel.Brake.FluidLevel.Axle1.Left Vehicle.Chassis.Wheel.Brake.FluidLevel.Axle1.Right Vehicle.Chassis.Wheel.Brake.FluidLevel.Axle2.Left Vehicle.Chassis.Wheel.Brake.FluidLevel.Axle2.Right Vehicle.Chassis.Wheel.Brake.FluidLevelLow.Axle1.Left Vehicle.Chassis.Wheel.Brake.FluidLevelLow.Axle1.Right Vehicle.Chassis.Wheel.Brake.FluidLevelLow.Axle2.Left Vehicle.Chassis.Wheel.Brake.FluidLevelLow.Axle2.Right Vehicle.Chassis.Wheel.Brake.PadWear.Axle1.Left Vehicle.Chassis.Wheel.Brake.PadWear.Axle1.Right Vehicle.Chassis.Wheel.Brake.PadWear.Axle2.Left Vehicle.Chassis.Wheel.Brake.PadWear.Axle2.Right Vehicle.Chassis.Wheel.Tire.Pressure.Axle1.Left Vehicle.Chassis.Wheel.Tire.Pressure.Axle1.Right Vehicle.Chassis.Wheel.Tire.Pressure.Axle2.Left Vehicle.Chassis.Wheel.Tire.Pressure.Axle2.Right Vehicle.Chassis.Wheel.Tire.PressureLow.Axle1.Left Vehicle.Chassis.Wheel.Tire.PressureLow.Axle1.Right Vehicle.Chassis.Wheel.Tire.PressureLow.Axle2.Left Vehicle.Chassis.Wheel.Tire.PressureLow.Axle2.Right Vehicle.Chassis.Wheel.Tire.Temperature.Axle1.Left Vehicle.Chassis.Wheel.Tire.Temperature.Axle1.Right Vehicle.Chassis.Wheel.Tire.Temperature.Axle2.Left Vehicle.Chassis.Wheel.Tire.Temperature.Axle2.Right Vehicle.Chassis.Axle1.TireDiameter Vehicle.Chassis.Axle1.TireWidth Vehicle.Chassis.Axle1.WheelCount Vehicle.Chassis.Axle1.WheelDiameter Vehicle.Chassis.Axle1.WheelWidth Vehicle.Chassis.Axle2.WheelCount Vehicle.Chassis.Axle2.TireDiameter Vehicle.Chassis.Axle2.TireWidth Vehicle.Chassis.Axle2.WheelDiameter Vehicle.Chassis.Axle2.WheelWidth

Vehicle.Chassis.Axle.Count // redundant?

UlfBj commented 4 years ago

Well, I delievered a little too fast, the last couple of rows above should be:

Vehicle.Chassis.TireDiameter.Axle1 Vehicle.Chassis.TireDiameter.Axle2 Vehicle.Chassis.TireWidth.Axle1 Vehicle.Chassis.TireWidth.Axle2 Vehicle.Chassis.WheelCount.Axle1 Vehicle.Chassis.WheelCount.Axle2 Vehicle.Chassis.WheelDiameter.Axle1 Vehicle.Chassis.WheelDiameter.Axle2 Vehicle.Chassis.WheelWidth.Axle1 Vehicle.Chassis.WheelWidth.Axle2

This points to the need of reformulation of one of the rules for instantiation in my proposal: Instantiation rules in a branch node only applies to its direct children of type sensor or actuator.

Using instantiation to generate this new tree, three branch nodes would have to contain declarations: Brake and Tire nodes: "instances": ["Axle[1..2]", ["Left", "Right"]] Chassis node: "instances": "Axle[1..2]"

UlfBj commented 4 years ago

An improved structure for the branches above could be (WheelCount deemed redundant and removed): Vehicle.Chassis.Wheel.Diameter.Axle1 Vehicle.Chassis.Wheel.Diameter.Axle2 Vehicle.Chassis.Wheel.Width.Axle1 Vehicle.Chassis.Wheel.Width.Axle2 Vehicle.Chassis.Wheel.TireDiameter.Axle1 Vehicle.Chassis.Wheel.TireDiameter.Axle2 Vehicle.Chassis.Wheel.TireWidth.Axle1 Vehicle.Chassis.Wheel.TireWidth.Axle2

Using instantiation to generate this tree, three (YAML) branch nodes would have to contain declarations: Brake and Tire nodes: "instances": ["Axle[1..2]", ["Left", "Right"]] Wheel node: "instances": "Axle[1..2]"

Now I think it starts to look good. With an instantiation model that is straightforward and relatively simple to implement.

UlfBj commented 4 years ago

Changing the model to allow for instantiation declarations further up the tree would lead to the instance declarations to look like: Brake and Tire node: "instances": ["Left", "Right"] Wheel node: "instances": "Axle[1..2]" Not much of a gain in declaration simplicity, but in my view significantly more complex to implement (as the impl needs to handle not only this particular combination, but all possible.

gunnarx commented 4 years ago

The hierarchy also becomes a little weird (because the upper level structure like the Axles/Rows gets mentioned in the leaf).

I agree, but that is due to the "weird" relation between Axle and Row[1..4]

No, it's the structure, and the proposal. I think you basically have agreed to this in your description and say you would be willing to live with it because it becomes less complex. The point is not about Row and Axle but that instances that are higher up the tree (assemblies of the physical car) gets mentioned in the node instead of their logical position.

From your latest example:

Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Left

The physical car looks more like this:

Vehicle.Chassis.Axle.Wheel.Brake.BrakesWorn....

We should really agree on this being the reality, even if we decide to go with the leaf-only instances design.

gunnarx commented 4 years ago

Well, I delievered a little too fast, the last couple of rows above should be:

It is usually possible to edit the comment from the drop-down menu (it is OK to make some fixes)

gunnarx commented 4 years ago

Changing the model to allow for instantiation declarations further up the tree would lead to the instance declarations to look like: Brake and Tire node: "instances": ["Left", "Right"] Wheel node: "instances": "Axle[1..2]"

Well, that looks weird of course. You have instantiated wheels using 2 axles, but not using the left-right location of the wheel. So it seems half way.

I think either you instantiate all the wheels using two instance dimensions, such as Axle[1,..2] and Left and Right (i.e. 4 instances because there are 4 wheels...) and then the brakes and tires are simply children under those instances, or the Axles themselves need to be a node with instances?
I'm still looking to see if the model can be more according to reality.

Not much of a gain in declaration simplicity, but in my view significantly more complex to implement

I've seen (and heard in our discussions) this argument a few times and I am not a big fan actually. I think a logical, understandable model is what creates least complexity if looking at the big picture.
But more importantly, I don't like the "implementation is complex" argument if it stands on its own. (For example, reducing the ability to do complex queries because it is difficult to implement -- this reduces the usability of it all)

(as the impl needs to handle not only this particular combination, but all possible.)

After we have a better model of wheels and axles, let's dig into this part, because I don't yet see the pitfalls of having instances further up the tree. Which are these combinations you mean?

(I make no more answer on the other comments since they are more minor improvements on the same proposal)

UlfBj commented 4 years ago

The proposal to place the instantiated nodes at the far end of branches I believe came from @klotzbenjamin . There is in my view at least one strong argument for that, it reduces the number of nodes compared to if instantiation is located further up in the branch. Downside may be what @gunnarx points to, that the logical structure expressed by the path becomes less intuitive. Another argument is that if the path expressions are used in URI expressions, then not having the variability point(s) at the end makes it hard, if not impossible, to use in search expressions. Implementation complexity would be less of an argument if it was done once, I agree. But only in an ideal open source world it is once. A solution that is hard to understand is no good, I agree. However, I do not see that would be the case here, at least not to a degree that trumps the arguments for it.

UlfBj commented 4 years ago

I would like to point out that we are discussing two design issues here, whether the "instances declaration" (in the YAML source) can appear at any point in a branch, or only towards the end leaf, and whether the "instances realization" (in the Tools output) can appear at any point in a branch, or only towards the end leaf. For the instances realization there will be more of redundant nodes with instance variability points further up in the branch, while on the other hand the "hierarchical model" (Axle before Wheel) is better preserved. As I see it, these are the two main conflicting arguments that we need to weigh against each other. For the instances declaration the redundancy (of declarations) is less when it may appear further up in the branch, with the main counter argument in my view being implementation complexity. If you see arguments missing, please add. Then I think we should try to make a decision as a solution to this is needed in Gen2.

UlfBj commented 4 years ago

There is one more argument for allowing the instance variability point in the realization to be anywhere in the branch, and that is that eliminates the need to break the rule that only branch nodes may have children. A pretty strong argument in my view.

UlfBj commented 4 years ago

As I found the argument above quite strong, I looked into a possible design for this model.

Instance declaration rules:

How would the Axle, Wheel subtree look like with this? The Axle, Wheel subtree could with this design look identical to its existing structure.

The declarations needed in the vspec file would be: In the branch node declaring the Row1/Row2 branch nodes: the node name would be "Row", with instances: "[1..2]". In the branch node declaring the Left/Right branch nodes, the node name could be "Wheel handedness", with instances:["Left", Right"] then replacing this node name.

gunnarx commented 4 years ago

Just a quick reply on this to clarify:

Implementation complexity would be less of an argument if it was done once, I agree. But only in an ideal open source world it is once.

I realize people can't be expected to read between the lines and see how I think, so let me clarify. When I say "once" I am really thinking "once within some context". Here I meant it relative to other things, and not necessarily once in the whole world. As in: It is done once per organization.
Let me put it this way instead: When the complex part of the software is written, with some effort, then it is "done", and by the nature of computer programs that implementation is fairly isolated to one place in the code. This is in contrast with working with extending, changing, maintaining the internal data models (which will happen, in-company proprietary extensions to VSS...). I think that will be a much more continuous process and that work affects the entire data model all over, as opposed to being isolated to one piece of the software. There is also a level of expert understanding that perhaps only a single software implementor needs to have, whereas we can try to simplify for a larger amount of people who I would expect work with the data model. This is why I make the argument that human understandability and reducing any manual work that might be repeated is more important to me than implementation complexity. Both are valid concerns of course (and they are likely correlated anyway, so let's just keep working on a logical solution).

gunnarx commented 4 years ago

A solution that is hard to understand is no good, I agree. However, I do not see that would be the case here, at least not to a degree that trumps the arguments for it.

I could agree to this. My objections were not really related to the difficulty of understanding. I was only pushing back on the implementation complexity argument (because it has also been repeated in other discussions) and not claiming that the currently discussed proposals are more or less complex for humans. (I might come back to that)

gunnarx commented 4 years ago

Only allowed in branch nodes, however not in the root node.

So if I understand this whole thing correctly, in practice this means that the model is generating the leaves from the instance definition(s)?

Let's say we are modelling something like this:

...MyBranch.Leaf

and we realize we need two identical leaves:

So the YAML model specifies:

MyBranch
   type: branch
   instances: [Leaf1,Leaf2]

so you mean that once it gets processed this generates:

MyBranch.Leaf1 
MyBranch.Leaf2

and those are the actual leaves, but generated?

What about this alternative:

YAML / model definition:

MyBranch.Leaf
    type: sensor   (a leaf)
    instances: [1..2]

generates

MyBranch.Leaf1
MyBranch.Leaf2

Isn't my definition above an "instance" definition that is defined on a leaf node? I think I would call that Yaml definition a leaf node, even if it is not the actual generated leaves (named Leaf1 and Leaf2) And wouldn't this be OK?

gunnarx commented 4 years ago

The declaration has two allowed formats, the first appends the index to the node name, in the second the enumerated values replace the node name. 1 instances: "[1..2]" 2 instances:["Left", Right"]

Thanks for clarifying this. It is the behavior I have assumed from reading the discussion, but it is good to document it.

gunnarx commented 4 years ago

There is one more argument for allowing the instance variability point in the realization to be anywhere in the branch, and that is that eliminates the need to break the rule that only branch nodes may have children. A pretty strong argument in my view.

Didn't understand this 100%, but I imagine it could be answered by answering my comment two steps above.

gunnarx commented 4 years ago

or only towards the end leaf, and whether the "instances realization" (in the Tools output) can appear at any point in a branch, or only towards the end leaf.

Useful distinction but not one I had imagined. To me, the logical thing is that realization is also made further up the tree, exactly where it is defined. It must be hard to understand how to address a node if it is not addressed using the "path" that can be seen in the defined YAML model?

UlfBj commented 4 years ago

@gunnarx The instance declaration in the branch ..MyBranch.Leaf

MyBranch
   type: branch
   instances: [Leaf1,Leaf2]

would in my proposal lead to the branches

..Leaf1.Leaf
..Leaf2.Leaf

To allow instance declaration in leaf nodes as you suggest is in my view of little interest, only useful if one wants to create an array of identical (except for name) nodes. Is there any such example in the existing tree? The instance arrays in the existing tree is what I have seen always in branch nodes. Support for "Leaf node arrays" I believe should be designed as described here https://github.com/GENIVI/vehicle_signal_specification/issues/110 instead of through instance declarations.

UlfBj commented 4 years ago

Didn't understand this 100%, but I imagine it could be answered by answering my comment two steps above.

What I tried to say here is that if instance realizations are appended at the "leaf node" (in the YAML source), then this "leaf node" is no longer at the far end of the branch, i. e. we will have node types other than "branch" that have (partly) the role of branch nodes. This will in my view degenerate the architecture, although it is manageable. Uniformity and simplicity as keywords also for me:).

UlfBj commented 4 years ago

It must be hard to understand how to address a node if it is not addressed using the "path" that can be seen in the defined YAML model?

It may be a bit hard (not much in my view) for the person writing the YAML source. For Gen2 clients this is a non-problem as they relate to the realization of the tree, not its YAML definition.

danielwilms commented 4 years ago

What I tried to say here is that if instance realizations are appended at the "leaf node" (in the YAML source), then this "leaf node" is no longer at the far end of the branch, i. e. we will have node types other than "branch" that have (partly) the role of branch nodes. This will in my view degenerate the architecture, although it is manageable. Uniformity and simplicity as keywords also for me:).

I think there's a misunderstanding. The instances will be created through the tools and not in the yaml files. The only thing, which appears in the yaml is the positioning information in the branches themselves.

UlfBj commented 4 years ago

The instances will be created through the tools and not in the yaml files. The only thing, which appears in the yaml is the positioning information in the branches themselves.

That is exactly my view also. What I call "instance realization" is what comes out of the tools. So what I try to say is that in the YAML source a node appearing as a leaf (and being of a "leaf" node type (sensor/actuator/attribute) will in what comes out of the Tools no longer be a leaf, and will have children. This can of course be handled, but in my view it degenerates the simplicity of the data model.

UlfBj commented 4 years ago

In this thread there is now two proposals, one where the "instantiation nodes" are appended at the end of branches, and one where these nodes can be applied at any position in a branch (except root and leaf positions). Have we come to a point where we feel we can take an informed decision? In that case I would go with the latter proposal. There would of course still be another judgement point when a PR implementing it is submitted.

danielwilms commented 4 years ago

In this thread there is now two proposals, one where the "instantiation nodes" are appended at the end of branches, and one where these nodes can be applied at any position in a branch (except root and leaf positions).

I've put an example of the possible csv result earlier. could you do the same with yours to see how it would really look like?

I still think that adding instances to the nodes wouldn't touch the data model itself, creating instances of the branches would do that quite significantly. especially addressing one single instance of a leaf would be hard with the dot notation and branch instantiation if you don't put that information to the end. An example would be really appreciated.

UlfBj commented 4 years ago

I've put an example of the possible csv result earlier. could you do the same with yours to see how it would really look like?

As I do not have a tool implemented with this it would take a lot of manual work to create an example. And as I see it, for the alternative where "instantiation nodes" can be applied at any position, it would not provide any new information as it would look identical to what the current tree looks like (if used for that purpose).

creating instances of the branches would do that quite significantly.

But that is exactly how it is in the existing tree. Branches like "...Axle.Row1..." and "...Axle.Row2..." are two branch instances. This can be identically reproduced with the instantiation model I propose. So what is then the gain, one could wonder? It is that in the YAML source there is no need to create multiples of the branches, it is compactly expressed with the "instances" property. The Tools then expands this into the multiple "instance" branches in the output.

addressing one single instance of a leaf would be hard with the dot notation and branch instantiation if you don't put that information to the end.

Addressing would look identical with how it looks today. Which is natural, since the tree would have identical structure.

An example would be really appreciated.

For my proposal on locating the "instance nodes" at the end of branches, I think my comment https://github.com/GENIVI/vehicle_signal_specification/issues/81#issuecomment-547896189 contains illustrative examples (in the "New structure" node list). It also shows the "problem" I have pointed to in that alternative, that the node that in the YAML source is the leaf node, BrakesWorn in the example below, is in the expanded tree not any longer a leaf node. It is now a node of type Sensor, but with two children (Axle1 and Axle2). Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Left

danielwilms commented 4 years ago

But that is exactly how it is in the existing tree. Branches like "...Axle.Row1..." and "...Axle.Row2..." are two branch instances. This can be identically reproduced with the instantiation model I propose.

Ok, I thought I've missed something. Was looking for the difference. :)

Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Left It would be more like: Vehicle.Chassis.Wheel.Brake.BrakesWorn ["Axle1", "Left"]

This instantiation would get closer to other systems and principles (Android, VSSo, REST, OOP,...) and the tree would be so much easier to read and separate clearly definition from instantiation and therefore does not span out so much. I guess we're stuck. Any opinion other than ours? @gunnarx, @magnusfeuer, @rstreif, @rtroncy, @klotzbenjamin,

To conclude, the question is: 1) Change the YAML but keep the tree structure as is 2) Change the YAML and use the instantiation of the leafs

UlfBj commented 4 years ago

Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Left It would be more like: Vehicle.Chassis.Wheel.Brake.BrakesWorn ["Axle1", "Left"]

So what you suggest is that the nodes Axle1 and Left above are what I would call "virtual nodes"? I.e. their definition is derived from data in BrakesWorn, and maybe Wheel (or where the "instance" declaration is found)? There are no "physical" node structures for these nodes as for the other nodes in the example branch? There is no "children" component in the BrakesWorn node explicitly indicating that it has Axle1 (and Axle2) as children? That would then not break the rule that leaf nodes are at the outer edge of branches. I think you point to the core question with your options 1. and 2. above. If my understanding of "virtual leafs" above is correct, then I could accept any of the two, but I still think I would prefer 1.

petervolvowinz commented 4 years ago

I must say that the hole discussion is very confusing. What defines a virtual leaf ? Is it virtual used in the same sense as a virtual function ? or is it some pieces of data that does not have a physical mapping ?

I clearly need examples from YAML to the actual instantiated tree to understand this.

rtroncy commented 4 years ago

To conclude, the question is:

  1. Change the YAML but keep the tree structure as is
  2. Change the YAML and use the instantiation of the leafs

I know which solution I prefer but I'm unable to match this with those short descriptions, i.e. to know which one is which. I also think we should have, side by side, the YAML definition and the actual instantiated tree for both options.

gunnarx commented 4 years ago

Answering with my understanding, possibly in reverse order.

I must say that the hole discussion is very confusing.

I think it mostly got confusing in the last few comments.

What defines a virtual leaf ? Is it virtual used in the same sense as a virtual function ?

No.

or is it some pieces of data that does not have a physical mapping ?

Also no.

I clearly need examples from YAML to the actual instantiated tree to understand this.

There have been several examples as we went through the discussion. I think there was a sudden unexpected sidetrack now. But yes, a full example should be coming fairly soon if we can try to converge in stead of diverge.

gunnarx commented 4 years ago

To conclude, the question is:

  1. Change the YAML but keep the tree structure as is
    1. Change the YAML and use the instantiation of the leafs

I know which solution I prefer but I'm unable to match this with those short descriptions, i.e. to know which one is which. I also think we should have, side by side, the YAML definition and the actual instantiated tree for both options.

I agree and I also think this short description is not really understandable. But it came together with an introduction of what seems to be a very different and new interpretation from Daniel, so it might not be valid as a full summary of our choices, IMHO. Let's backtrack a bit first.

Now, on to comment on that.

UlfBj commented 4 years ago

For alternative one, please look at https://github.com/GENIVI/vehicle_signal_specification/issues/81#issuecomment-549327173. From this comment> The declarations needed in the vspec file would be: In the branch node declaring the Row1/Row2 branch nodes: the node name would be "Row", with instances: "[1..2]". In the branch node declaring the Left/Right branch nodes, the node name could be "Wheel handedness", with instances:["Left", Right"] then replacing this node name. With the addition of these two instance declarations in the two mentioned branch nodes, and the also mentioned name change of these nodes, and of course removal of all already "instantiated" YAML branches, the Tools would render the tree identical to the existing (node descriptions would be somewhat different). The vspec files would become quite smaller, and easier to read. Changing an instantiation (e. g. from two Rows to four Rows would be just to change "instances": "[1..2]" to "instances": "[1..4]" in the Row branch node.

For alternative 2, with "physical" nodes in the tree realization, see the comments at https://github.com/GENIVI/vehicle_signal_specification/issues/81#issuecomment-547896189.

For alternative 2, with "virtual" nodes in the tree realization, I leave that to Daniel to show.

gunnarx commented 4 years ago

I've put an example of the possible csv result earlier. could you do the same with yours to see how it would really look like?

Please, "earlier" is not precise enough. Please link. Do you mean the files base_tree.txt and instances.txt from this comment?

In my opinion, we are primarily discussing the source format, which is YAML. Secondarily perhaps something that is generated from that (but that is more in order to understand the meaning of the YAML change proposal). So I would like to propose that examples are primarily in YAML.

Please confirm which example you meant (if you are still committed to the idea). I think there are a number of answers already provided by Ulf to your proposal which are trying to get us back on a common track, but there are more to come - I just want to be sure that I don't comment on something that is obsolete.

I do not like the introduction of the "virtual" word, it does not clarify anything. @UlfBj I propose that before trying to interpret Daniel too far and put new names on this direction I'd like to understand why there is a sudden new direction?
@danielwilms This is because I'm not 100% sure if you first explained some criticism of the most recent idea (that has been refined and seemed almost done) to back up the new proposal, or if we did not have the same understanding of the current idea. I think it looks to me/Ulf like you made a sudden very sharp turn?

gunnarx commented 4 years ago

More to be said, if there is more clarity on where we stand with @danielwilms last entry and if it is actually a working proposal, but I can pick this one out right away:

Vehicle.Chassis.Wheel.Brake.BrakesWorn.Axle1.Left It would be more like: Vehicle.Chassis.Wheel.Brake.BrakesWorn ["Axle1", "Left"]

The first line is an example of "the result". Ulf has said that tooling will generate these from a definition of instances. The second line is an example of instantiation. But we only used for discussion (see below)

Furthermore:

Vehicle.Chassis.Wheel.Brake.BrakesWorn ["Axle1", "Left"]

This is totally against the format as it is described in the third bullet of this comment.

We had two proposed ways to instantiate: Axle[1..2] which expands to Axle1 and Axle2 and xxx["Left", "Right"] which expands to xxx.Left and xxx.Right. Now under that proposal you clearly cannot have an enumeration with two different things (Axle and Left). So you introduced something very different - this is what I mean by "sharp turn".

Maybe it helps to check consensus on the following. This format is at least in my mind never actually written! It is only a compact way we used to communicate inside of this discussion how to structure the tree.

Like this:

Vehicle.Chassis.Wheel.Brake.BrakesWorn ["A", "B"] basically never needs to be seen in the future except in this discussion section***

What we have is actually this:

It is either in YAML:

Vehicle.Chassis.Wheel.Brake.BrakesWorn
    instances: ["A", "B"]

or in "generated results":

Vehicle.Chassis.Wheel.Brake.BrakesWorn.A
Vehicle.Chassis.Wheel.Brake.BrakesWorn.B

Those are IMHO the only two actual text formats that matter.

* Obviously you could** generate that format for documentation or otherwise, but I just want us to be clear that this way of writing things are not really a part of the actual VSS in the proposal I have in my mind now.

This is my understanding - we'll see if @UlfBj and others agree.

Vehicle.Chassis.Wheel.Brake.BrakesWorn ["Axle1", "Left"] This instantiation would get closer to other systems and principles (Android, VSSo, REST, OOP,...) and the tree would be so much easier to read and separate clearly definition from instantiation and therefore does not span out so much

@danielwilms you previously seemed to support that instantiation of Axle belongs further up the tree and therefore should be instantiated there. So also therefore, your example to make it more like a programming language does not fit with me, at all. Anyway, that point is still moot because of what I wrote above - this "format" is in any case never written anywhere, isn't that right?

UlfBj commented 4 years ago

@gunnarx, I agree with most of your comments above, except for

xxx["Left", "Right"] which expands to xxx.Left and xxx.Right.

As I want to see it, and has used it in comments above (in my proposed design for alternative 1), it would instead be xxx["Left", "Right"] which expands the node xxx to the nodes Left and Right (xxx does not exist any more, but is replaced by two nodes Left and Right).

Vehicle.Chassis.Wheel.Brake.BrakesWorn instances: ["A", "B"]

I think the example to add instantiated nodes A and B as children to BrakesWorn is something you do not find in the tree, and should be solved differently. As I have mentioned before, IF arrays of this type should be represented in the tree (which I think there is no example of today), then I think it should be designed as described here https://github.com/GENIVI/vehicle_signal_specification/issues/110 In my design proposal for Alternative 1, instantiation declarations are only allowed in branch nodes, however not in the tree root node. The declaration leads to the the node containing the declaration becomes instantiated. In my design proposal for Alternative 2, are only allowed in branch nodes. It leads to that instantiation nodes are appended at the "far end" of all branches below it.

Regarding my interpretation, and naming, of @danielwilms proposal, I agree I was too fast, sorry. I leave it to him to explain and propose naming.

gunnarx commented 4 years ago

@UlfBj

As I want to see it, and has used it in comments above (in my proposed design for alternative 1), it would instead be xxx["Left", "Right"] which expands the node xxx to the nodes Left and Right (xxx does not exist any more, but is replaced by two nodes Left and Right).

OK, I have misread your previous definition - I guess because I prefered my way. Let me try to argue for it:

In your definition above you indeed write that Wheel should be replaced by Left and Right but I don't think that is really logical. I mean let's "construct" the car then we get:

wheel sits on the axle and there is one left and one right wheel:

...Axle.Wheel 
         instances: ["Left","Right"]

We want this result, in my opinion:

...Axle.Wheel.Left
...Axle.Wheel.Right

It makes sense to me say Wheel.Left and Wheel.Right in the result -- There are many similar constructions were in the VSS tree before introducing the instances concept, and I think we are trying to replace those. So in this case if the Wheel node gets replaced we suddenly have 

Axle.Left
Axle.Right

which is not right - totally different thing.

Now to achieve what we want you would have to introduce a node only to hold the instances, if I understand your description. I name it with a silly long name here, just for effect.

...Axle.Wheel.MyWheelInstanceHolderNode
           instances: Left, Right

now when the MyWheelInstanceHolderNode gets replaced with instances the resulting tree looks OK:

Axle.Wheel.Left
Axle.Wheel.Right

But I don't see the advantage in having to introduce this instance holder node. Left and Right are instances of Wheel and should logically be defined on the Wheel node I thought -- and I don't want the word Wheel to disappear from the model. For example, there could be other children hooked on there, like Wheel.SpeedSensor or Wheel.Tire.Pressure, and so on?) Just like above, they would make less sense if their parent node disappeared.

The idea with allowing instances further up the tree, if we succeed in making that work would be that the two children I just mentioned, are implicitly duplicated as well. In other words, since Wheel has Left and Right (I'm ignoring multiple Axles for the moment) then you automatically also have these nodes:

Wheel.Left.SpeedSensor
Wheel.Right.SpeedSensor
Wheel.Left.Tire.Pressure
Wheel.Right.Tire.Pressure

So, I should follow my own example and use YAML:

Path.To.Node.Something
             instances: ["Left","Right"]

expands to 

  Path.To.Node.Something.Left
  Path.To.Node.Something.Right

(Noteworthy that I propose the "." to appear there)

whereas

      instances: [1..2]

expands to:

Path.To.Node.Something1
Path.To.Node.Something2

This was a small missunderstanding of your defined proposal but I actually quite liked the way that the enumeration type and the array type expanded slightly differently in my mind. And in both cases the word "Something" remains in the result because it has value.

I think the example to add instantiated nodes A and B as children to BrakesWorn is something you do not find in the tree, and should be solved differently.

I don't understand since it was a made up example, but maybe the rest of your feedback was more a consequence of our different world views on expansion.

IF arrays of this type should be represented in the tree

I'm a bit more confused. The example was using the enumeration type with values A and B, and not what I like to call the array type? --> [1..4]

In my design proposal for Alternative 1, instantiation declarations are only allowed in branch nodes, however not in the tree root node. The declaration leads to the the node containing the declaration becomes instantiated.

I agree with this, it being instantiated, but propose the behavior as above.

In my design proposal for Alternative 2, are only allowed in branch nodes. It leads to that instantiation nodes are appended at the "far end" of all branches below it.

Here you meant leaf node I think? Or are they defined on branches but end up in the leaves?
Anyway I think 'm not interested in that alternative at the moment so I (you) can skip that answer for now

UlfBj commented 4 years ago

|| In your definition above you indeed write that Wheel should be replaced by Left and Right but I don't think that is really logical

No, that is not what I say. In my proposal for Alternative 1, the name of the node in which the instantiation declaration is found its name is indeed replaced (and instantiated N times), but I do not for this alternative suggest to put the declaration in the Wheel node, instead in a node directly below it, called "Wheel handedness" https://github.com/GENIVI/vehicle_signal_specification/issues/81#issuecomment-549327173. Wheel handedness would then be replaced by Left/Right and the wanted tree structure would be achieved. In my proposal for Alternative 2 I place the instantiation declaration in the Wheel node, but in that alternative that leads to instantiation of Left/Right at the far end of branches below.

UlfBj commented 4 years ago

If it should be allowed to include instance declarations in all node types, not only branch nodes, then with a subtree like below (copied from existing tree structure, so instances would not be where they are shown here, but moved to the end). Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.BrakesWorn Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevel Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.PadWear where the branch Brake has four leaf children, it would be possible to either place the instance declaration in each of the four leaf nodes, or in the branch Brake above (in your proposal). In my proposal it would have to be in the Brake node. I cannot see that the freedom to place it in either the branch or all leafs add anything, it rather allows for mistakes to declare in one leaf. BTW, I see the discussion in this comment to be relevant only for Alternative 2 (instantiations at the far end of branches).

UlfBj commented 4 years ago

This seems like a never-ending story, I think we should soon at least try to narrow it down through deciding on whether we should go with Alternative 1 or 2.

rtroncy commented 4 years ago

I think we are not far from converging, but the problem is that this issue has a long list of comments and it is really hard to follow, mostly because in the course of the discussion, we each try to interpret the proposal of the others (with sometimes require corrections), and this is again mostly because all of us are not rigorous enough to write a full example, leaving under-specified proposal, and we instead keep referring to previous (sometimes incomplete) comments. I swear that I have spent hours in going back and forth in this long comment list and even have attempted to put notes on paper and board but there are still some unknown and left to interpretation statements.

We should give a short name to the 2 (or are there 3?) proposals we have on the table, I'm not sure. Please, don't use "alternative 1", "alternative 2" as labels, but choose rather a meaningful name, and in the worst case, the name of the proposer who is championing the proposal.

We should write a concrete full example, using ONLY the YAML syntax, together with the associated generated instances (and not a new made up syntax). The closest to this are the comments from Gunar here and here. Even if you have partly wrote something in the past, don't force the reader to go up the comment tree, but instead, aim to write a SINGLE self-contained comment showing the entire example.

Can @gunnarx @UlfBj and @danielwilms agree to do this? I'm confident that if we do this exercise, we can reach consensus.

PeterWinzell commented 4 years ago

I second that.

On Fri, 8 Nov 2019 at 07:15, Raphael Troncy notifications@github.com wrote:

I think we are not far from converging, but the problem is that this issue has a long list of comments and it is really hard to follow, mostly because in the course of the discussion, we each try to interpret the proposal of the others (with sometimes require corrections), and this is again mostly because all of us are not rigorous enough to write a full example, leaving under-specified proposal, and we instead keep referring to previous (sometimes incomplete) comments. I swear that I have spent hours in going back and forth in this long comment list and even have attempted to put notes on paper and board but there are still some unknown and left to interpretation statements.

We should give a short name to the 2 (or are there 3?) proposals we have on the table, I'm not sure. Please, don't use "alternative 1", "alternative 2" as labels, but choose rather a meaningful name, and in the worst case, the name of the proposer who is championing the proposal.

We should write a concrete full example, using ONLY the YAML syntax, together with the associated generated instances (and not a new made up syntax). The closest to this are the comments from Gunar here https://github.com/GENIVI/vehicle_signal_specification/issues/81#issuecomment-551452992 and here https://github.com/GENIVI/vehicle_signal_specification/issues/81#issuecomment-551613866. Even if you have partly wrote something in the past, don't force the reader to go up the comment tree, but instead, aim to write a SINGLE self-contained comment showing the entire example.

Can @gunnarx https://github.com/gunnarx @UlfBj https://github.com/UlfBj and @danielwilms https://github.com/danielwilms agree to do this? I'm confident that if we do this exercise, we can reach consensus.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GENIVI/vehicle_signal_specification/issues/81?email_source=notifications&email_token=AE5PWUFPB3KG7ON6WHNFUB3QSV7CVA5CNFSM4GGVSHWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDSNEEQ#issuecomment-551866898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5PWUDA6UB7VN3AAEVCUGDQSV7CVANCNFSM4GGVSHWA .

UlfBj commented 4 years ago

I can also accept that, with the following requirements added:

UlfBj commented 4 years ago

The below subtree could be used for the exercise? I am open for other suggestions. I think it should be a part of the existing VSS tree. Maybe some branch containing the Row2 node should be added?

Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.BrakesWorn Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevel Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.PadWear Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.PressureLow Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Temperature Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.BrakesWorn Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.FluidLevel Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.FluidLevelLow Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.PadWear Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.PressureLow Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Temperature

gunnarx commented 4 years ago

No, that is not what I say. In my proposal for Alternative 1, the name of the node in which the instantiation declaration is found its name is indeed replaced (and instantiated N times), but I do not for this alternative suggest to put the declaration in the Wheel node,

OK!

instead in a node directly below it, called "Wheel handedness" #81 (comment).

Fine! Then "Wheel handedness" is the "instance holder node" in my writing above. Can we move on now to discuss the differences in these two variants? I'm asking if it isn't better to skip such an extra node that is only going to disappear in the generated/resulting tree?

This seems like a never-ending story,

It might be frustrating but this, and comments like "this is so confusing" are not helpful. There is only one way through this and that is to actually go through it, by clear discourse where you answer to what the other person said, then ask for clarification if needed.
Anyone, feel free to create as many examples as you like.

narrow it down through deciding on whether we should go with Alternative 1 or 2.

I stated my position on that, at least. So we're looking for @danielwilms to join the same track, or clarify his most recent input, primarily? I hope you see that I ruled out Alternative 2 : Instances appear only on leaves, according to my opinion. At least I'd like to continue exploring Alternative 1: Instances of branches are possible (with the small change). When you stopped short of answering to the rest of my comment, there is no way of knowing what you are after here -- complete acceptance of your way of writing Alternative 1, or just the general principle of it?

(Raphael)

and this is again mostly because all of us are not rigorous enough to write a full example, leaving under-specified proposal

Certainly true for some of the comments earlier but I disagree, at least on my latest part. I made a serious attempt to write enough details to get across the points I needed to get across. The primary reason was, admittedly, to highlight what might remain as disagreement between Ulf and me. I would appreciate feedback on that proposal, specifically. I think at least those of us who really need to converge and understand each other now, the details are clear. And as I wrote previously, a fuller example should follow shortly, but we could possibly before that narrow down to avoid over-exemplifying some approaches that no one wants.

Maybe some branch containing the Row2 node should be added?

Yes, otherwise it's a very confusing example to use instantiation for Row but not show the full example. Do I need to exemplify how my current viewpoint/proposal (can still change) looks in YAML? I think I did already to enough detail with a very similar example?

rtroncy commented 4 years ago

Certainly true for some of the comments earlier but I disagree, at least on my latest part.

This was softly acknowledge in the rest of my comment when I wrote "The closest to this are the comments from Gunar here and here". It is actually one of the most complete piece in this thread IMHO.

Maybe some branch containing the Row2 node should be added? Yes, otherwise it's a very confusing example to use instantiation for Row but not show the full example.

+1. I also think we should do the complete example proposal from @UlfBj comment but adding Row2 examples (and maybe one Axle2 example as well).

Do I need to exemplify how my current viewpoint/proposal (can still change) looks in YAML? I think I did already to enough detail with a very similar example?

Yes, please. Personally, I will find very useful that you write a single self-contained comment showing how you would like to have this list represented in YAML together with the associated generated instances AND the rules used for insertion of the instance declarations in the YAML tree.

gunnarx commented 4 years ago

OK, since I will be mostly offline from this discussion for a week now, I'd like to put in the requested example according to my current best proposal (could still change...):

Vehicle.Chassis.Axle:
   type: branch

Vehicle.Chassis.Axle.Row:
   type: branch
   instances: [1..2]

Vehicle.Chassis.Axle.Row.Wheel:
   type: branch
   instances: ["Left", "Right"]

# Note that to make this work, I believe the YAML definition of nodes does 
# not ever use instance names in the path.  No Row1 or Row2 or Left or Right.
#  The next levels of the tree must look like this, IMHO:
Vehicle.Chassis.Axle.Row.Wheel.Brake:
   type: branch
   ...

Vehicle.Chassis.Axle.Row.Wheel.Brake.BrakeWorn:
   type: sensor      # i.e. a leaf
   datatype: ...
   etc.

Vehicle.Chassis.Axle.Row.Wheel.Brake.FluidLevel:
   type: sensor      # i.e. a leaf
   datatype: ...
   etc.

Vehicle.Chassis.Axle.Row.Wheel.Brake.FluidLevelLow:
   type: sensor      # i.e. a leaf
   datatype: ...
   etc.

Vehicle.Chassis.Axle.Row.Wheel.Brake.PadWear:
   type: sensor      # i.e. a leaf
   datatype: ...
   etc.

Vehicle.Chassis.Axle.Row.Wheel.Tire.Pressure:
   type: sensor

Vehicle.Chassis.Axle.Row.Wheel.Tire.PressureLow:
   type: sensor

Vehicle.Chassis.Axle.Row.Wheel.Tire.Temperature:
   type: sensor

Generates this: ("generates" here in practice means that the VSS signals can be accessed by using this path, in actual queries)

Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.BrakesWorn
Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevel
Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.FluidLevelLow
Vehicle.Chassis.Axle.Row1.Wheel.Left.Brake.PadWear
Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.PressureLow
Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Temperature
Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.BrakesWorn
Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.FluidLevel
Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.FluidLevelLow
Vehicle.Chassis.Axle.Row1.Wheel.Right.Brake.PadWear
Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure
Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.PressureLow
Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Temperature

Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.BrakesWorn
Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.FluidLevel
Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.FluidLevelLow
Vehicle.Chassis.Axle.Row2.Wheel.Left.Brake.PadWear
Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure
Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.PressureLow
Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Temperature
Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.BrakesWorn
Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.FluidLevel
Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.FluidLevelLow
Vehicle.Chassis.Axle.Row2.Wheel.Right.Brake.PadWear
Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure
Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.PressureLow
Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Temperature

Notes (note deleted)

(sidenote: As we talked about before, "Row" is somewhat superfluous and could be done by instantiating on the Axle node instead, yielding Axle1 and Axle2, but I went with the proposal exactly as specified and how I think that proposal would be represented in YAML to generate this result, according to my preferred variation of this). We are discussing methods now, not the actual final VSS tree.