Closed erikbosch closed 11 months ago
Meeting notes:
We (Velocitas) also need to discuss with Digital.Auto, what they think/prefer.
Meeting notes:
Added test examples on how this works with overlays. In short, using our overlay mechanism to add signals to expanded paths works, but then the consumer of the output need to do the logic understanding that Vehicle.Door.Row1.Pos1.NewSignal
actually refer to the signal Vehicle.Door.NewSignal
in the door instance Row1.Pos1
.
That is likely Ok for now, but perhaps as part ongoing VSS discussions (this one, ontologies, ...) we possibly need to refactor how we define and use instances, like discussed in https://github.com/COVESA/vehicle_signal_specification/issues/642.
Meeting notes:
As of today all our tools expand instance information, resulting in that you do not know (for sure) if
Row1
represents an instance or is a real branch. In some cases, like for example if you want to create an object oriented API/SDK this might be a disadvantage as you may want to offer methods like:is_my_door_open = my_vehicle.getDoor(ROW1, DRIVER_SIDE).is_open()
... rather than having Row1 and DriverSide as objects. Having a JSON file where no transformation/expansion has been performed make it easier to generate the API/SDK as wanted. Under the hood the API/SDK must still create the old expanded path if it is to communicate with an implementation that rely on trditional expanded paths (like VISS and KUKSA.val)
The implementation in this PR add functionality for Yaml, JSON and CSV exporters. For others a warning is given if
--no-expand
is used. See test cases for examples.The included *.json file on top level is only for reference and will not be part of final commit. It shows resulting JSON if using latest VSS and the
--no-expand
option.