AMM Idea: Overlays - introduce easy solution to add keys to multiple signals

[erikbosch]

Idea collected during AMM. In some cases you might want to add the same key/property to a large number of signals, e.g. add something like "included: true" to a large number of signals. A "shortcut" solution for doing this could be useful

[nwesem]

hi @erikbosch can you elaborate a bit on this? Do you already have sth in mind how a signal like this would be defined?
I could take some time to implement this

[erikbosch]

Hi @nwesem - I will try to explain some ideas that I had at that time. The problem as of today is that you need quite many lines to change a signals, like using delete below.

Vehicle.Service.TimeToService:
  type: sensor
  datatype: int32
  delete: true

(Parts of it is due to tool limitations, that we for instance require type even if we theoretically could manage without for overlays). Anyhow, if we would like to use delete for a large number of signals it would be great with a method where you only need a single line for each extra signal. One idea could be to support something like below where you define the wanted change (add/delete) and then just list all signals that shall be involved. Would likely be quite easy to implement if we support defining overlays without specifying type so that the tool just could expand it. But one could think of other ideas/solutions/syntax as well. The challenge is likely to find something that can be implemented without adding to much complexity

delete_some:
  type: overlay
  add:
     delete: true
  signals:
    - dsdsd
    - dsssd
    - ds
    
define_safety:
  add:
     asil: qm
  signals:
    - a
    - d
    - f
    
remove_unit:
  remove:
     unit:
  signals:
    - xxx
    - yyy
    - zzz

[nwesem]

I've been trying to come up with a way to solve this, but you are right the way the overlays are currently loaded (just like any vspec using load_tree(...)), we need to at least provide type and datatype.

To me this seems like a two step process:

1. Find a way to merge overlay that doesn't define datatype and type to a currently loaded tree and then
2. add the keys to all signals defined under the condition that the signals already exist in the currently loaded tree

What if we defined an additional way of integrating overlays in a currently loaded tree by checking if all signals have datatype and type or not. If they don't provide datatype and type we assert that all defined signals in the overlay already exist in the currently loaded tree. If all signals defined in the overlay already exist, we can change only the data defined in the overlay. But that also means that we would have to deal with two types of overlays from now on.

Is there a better way to solve this? Please let me know what you think @erikbosch @adobekan