[Bug] Index-based access to VSS instances, e.g. Vehicle.Cabin.Seat.Row(1).Pos(2). ..., not offered by generated model

[BjoernAtBosch]

Some month ago we introduced the automated vehicle model generation from a json-based model specification referenced in the AppManifest (before we provided pre-generated models in GitHub repos for Python and C++, which was generated from the original vspec files provided by COVESA).

The switch to the JSON-based format was done, because we wanted to have a single file representation of the VSS signal catalog and also the digital.auto project is providing their models as JSON. This was done under the assumption that json-based VSS specification is semantically identical to vspec-based origin (except file separation, of course).

But unfortunately it isn't: In the vss.json all kind of instances, e.g. like instances of Seats, are expanded and the information that the different seats in Row1 Pos1 and Row2 Pos3 are instances of a single Seat definition is lost.

This leads to the problem that the functions that should offer index based access to instances are not generated as part of the model like they would if using model generation from vspec files. The index-based access functions enable iteration over, for example, the rows of seats and seats per row; means allows for something like this: Vehicle.Cabin.Seat.Row(row_idx).Pos(pos_idx).Position

Unfortunately, we also cannot easily move back to use vspec files for model generation as Digital.Auto is working on json base, only.

We are currently working hard on a solution for this.

[BjoernAtBosch]

Solution proposal for COVESA: COVESA/vss-tools#293

[BjoernAtBosch]

Erik Jaegerval provided a quick prototype with PR COVESA/vss-tools#293 showing two possible solutions:

1. Keeping instance expansion but adding a flag "expanded": true for each expanded branch
2. Add a flag --no-expand to the vspec2json (or in general: vspec2x.py) of the VSS tooling to discard instance expansion and instead keeping the instance information in the generated output files.

JSON examples are included for both. We should check if any of the approaches would fit our needs, and Erik will mention it on VSS meetings so they can start thinking about it as well.

[BjoernAtBosch]

I provided a PoC fix of our model-generator for solution (i), that restores the original instance information (from vspec files). This has limitations in cases where the expanded flag isn't correctly set and also for the case that an instances (or some) have "special" attributes, which is allowed by the VSS specification.

I also tried solution (ii) with our model-generator and it works "out-of-the-box". Means, no fixes in the model-generator needed.

Solution (ii) would be preferred, as it keeps the original information of the vspec files in the JSON file.

[BjoernAtBosch]

I also thought about a PoC that recognizes expanded instances just by comparing children of a branch and rating them as instances of a common definition if they contain equal (grand) children.
Unfortunately, this would have even more limitations than the PoC identifying instances based on the expanded flag: There could be branches consisting of a single instance only (in model for specific vehicles, e.g. roadsters having only row1 of seats). But still an index-based access function must be available as developers would expect that when writing vehicle independent apps.

[BjoernAtBosch]

Currently, we are in discussion with digital.auto, if the proposed solution (ii) (see above) would also fit for them.