Dynamic arrays?

[erikbosch]

An alternative approach to having struct-support (see #326) could possibly be to redesign our branch/instance-handling. As of today we must always specify range for instances, like:

Seat:
  type: branch
  instances:
    - Row[1,4]
    - Pos[1,5]
  description: All seats.
#include SingleSeat.vspec Seat

And in all our tools this gets expanded, like:

https://github.com/GENIVI/vehicle_signal_specification/blob/master/docs-gen/static/releases/v2.1/vss_release_2.1.csv

I am not so fond of that we need to specify range already in "core" VSS, as we then need to make some assumptions. In the current VSS-spec it seems that we want to support a very short but quite wide bus. And we do not yet have any way to specify that there only are 2 seats in the front row but 3 in the back row, like in many cars.

Vehicle.Cabin.Seat,branch,,,false,,,,All seats.,,b0b253106b2851e3bb5c71ae3b09f09d,
Vehicle.Cabin.Seat.Row1,branch,,,false,,,,All seats.,,7a420ddeac6f538eb3939bb4a242d136,
Vehicle.Cabin.Seat.Row1.Pos1,branch,,,false,,,,All seats.,,9f570421f00a53f19f3741bd4e53303b,
...
Vehicle.Cabin.Seat.Row4.Pos5.HasPassenger,sensor,boolean,,false,,,,Does the seat have a passenger in it.,,7be9cd29db38535ca3b0d10289699e5c,

This makes expanded files big, and if you want to change number of seat rows you need to go back to VSS first. Would it be an idea to consider a different handling of branches with instances, where you do not necessarily need to specify the range already in vspec.

E.g. that we would allow unlimited specification like:

Seat:
  type: branch
  instances:
    - Row[]
    - Pos[]
  description: All seats.
#include SingleSeat.vspec Seat

... or even without named dimensions ...

Seat:
  type: branch
  instances:
    - [] # Row
    - [] # Pos
  description: All seats.
#include SingleSeat.vspec Seat

And that the tools then does not expand the instances but just keep the information, like:

Vehicle.Cabin.Seat,branch,,,false,,,,All seats.,,b0b253106b2851e3bb5c71ae3b09f09d, "Row[], Pos[]"
Vehicle.Cabin.Seat.HasPassenger,sensor,boolean,,false,,,,Does the seat have a passenger in it.,,7be9cd29db38535ca3b0d10289699e5c,

or with defined ranges as today:

Vehicle.Cabin.Seat,branch,,,false,,,,All seats.,,b0b253106b2851e3bb5c71ae3b09f09d, "Row[1,4], Pos[1,5]"
Vehicle.Cabin.Seat.HasPassenger,sensor,boolean,,false,,,,Does the seat have a passenger in it.,,7be9cd29db38535ca3b0d10289699e5c,

Then some layer/config-mechanism (static definition of available seats) or some form of dynamic registration must be used to inform e.g. a VISS-server on which seats that actually are available. But this could rather be seen as a part of a VISS implementation rather than VSS. Addressing would be just as today, you could e.g. ask a VISS-server for

"Vehicle.Cabin.Seat.Row4.Pos5.HasPassenger"

or if anonymous dimensions are used:
"Vehicle.Cabin.Seat.4.5.HasPassenger"

If you want to know which seats that actually are available you would need to ask the VISS-server for meta data for "Vehicle.Cabin.Seat"

This could work also for the array example in #326. If you want to get the whole delivery list you just do a read on the branch DeliveryList And if needed also support write.

This would indeed be a big change, so my ambition with this issue is just to discuss if we need/want support for "unlimited" branches, and what implications that would lead to.

[crea7or]

Why they should be dynamic if the number of seats, for example, never changes in vehicle? Maybe it's more related to have some common vspec file for a few modifications of a vehicle?

[erikbosch]

We have discussed layering to override default vss data for a long time, including concept like pruning (#252). And that could likely work well if you have a fixed size, even if the expanded/flattened JSON/CSV still would be quite big if you have many seats in the vehicle. Already with the current 4x5=20 seats it result in about 1000 lines of definitions for seats in the generated CSV file.

But I can see that we in the future might need to support branches where we do not in advance can or want to specify max size, and there unspecified range and no expansion could possibly be a solution.

[danielwilms]

Already with the current 4x5=20 seats it result in about 1000 lines of definitions for seats in the generated CSV file.

I somewhat agree, but as it's part of the path and therefore of the dot-notated identifier of the leaf it might be good to keep it listed. But keeping the overriding through layers in mind we can discuss how to find maybe default values, which illustrate the most common use-cases and not inflate the result too much.

[danielwilms]

Requirement: has to be easy to run and execute (example instances, etc.)

[UlfBj]

find maybe default values, which illustrate the most common use-cases and not inflate the result too much.

This should as I see it be sufficient to solve the "problem".

[danielwilms]

close for now, as examples in instantiation help understanding