Simplify overlay handling

[erikbosch]

This is an idea for simplifying overlays. If a node is found in overlay without type (e.g. branch, sensor) or datatype (e.g. uint8) it will try to do a look-up if a node with the same name already exist, and then use that type/datatype value.

There are limitations, like if you add something to Vehicle.Axle.Front.SomeSignal in an overlay (i.e. only for a single instance) it will not find source signal Vehicle.Axle.SomeSignal.

Many of the changes are just adding license headers. As I got failure on some changed files I also updated some files that were not changed.

Next step if this is merged is to adapt documentation in VSS repo. Possibly saying something like:

• In most cases you do not need to specify datatype and type in overlay if you are modifying an existing signal.
• Specifying datatype and type is needed if overlay addresses specific instances of a branch, like front left wheel.

[nwesem]

thx @erikbosch this is a great addition to implement issue https://github.com/COVESA/vss-tools/issues/193

I tested it on a clean install of vss-tools and is working as expected on non-struct signals. I haven't looked into the mentioned limitations on structs yet

[nwesem]

@erikbosch I tested the structs and can confirm that I get the same warnings and errors. Now I was wondering what your planned next steps are on this topic?

[erikbosch]

I did not had time (or forgot) to mention the PRs in vss-tools yesterday, but as you have already looked at it I see no problems merging this one. I have no problems updating documentation, if you have time and interest in something for #193 feel free to try it out, or if you want to improve the limitations.

[nwesem]

hi @erikbosch was there a specific reason why you didn't implement the limitations for structs? I would like to proceed with it to make https://github.com/COVESA/vss-tools/issues/193 work. An idea how you would overcome the limitations would be a valuable first step for me as I haven't worked much with the code that deals with structs.

[erikbosch]

For structs (i.e. type files) I did not really did any tests so there I do not really know how much effort, if any, that is required.

For instances we can take the example in https://github.com/COVESA/vehicle_signal_specification/pull/747

# Type and Datatype not needed
Vehicle.Speed:
  unit: m/s

# Type and Datatype needed as overlay affects a particular instance
Vehicle.Occupant.Row1.DriverSide.HeadPosition.Yaw:
  type: sensor
  datatype: float
  unit: mm

Here the problem with the second one is that when we read the overlay we have not yet analyzed/expanded instances, so you can easily find Vehicle.Occupant.HeadPosition.Yaw in tree but you would need a more advanced search algorithm to find Vehicle.Occupant.Row1.DriverSide.HeadPosition.Yaw as Row1 and DriverSide comes from instance information. Like finding Vehicle.Occupant and then check if Row1 refers to a real sub-branch or rather to an instance. This is a bit related to the discussion in #749,

[nwesem]

hi @erikbosch, sry about this, I accidentally called instances structs in this whole conversation and just realized it now.. I was referring to instances the entire time, as structs are not being used (yet) as far as I know. I'm currently trying to come up with a search algorithm to find the definition of a signal that was instantiated to link its datatype and/or type to it when it is being overwritten from an overlay..

[nwesem]

hi @erikbosch would it be possible to have a short 15-30min call about finding the type (and datatype) for instances? I've been trying to find a way to search for them but as this data is cleaned from the model before rendering a tree, I can't find a slick solution to retrieve the type and datatype. I would really appreciate it!!

[erikbosch]

@nwesem - we could try to align on a slot using the COVESA slack channel, if that works for you