Signal references inside structs?

[jsyvanen]

Hi All,

I am building some struct data types and would find it useful/convenient to be able to compose it from signals defined in the rest of the tree. However, it seems that struct datatypes can only contain items of type property or struct whereas signals in the tree need to be one of sensor actuator attribute branch and indeed attempting to include these in the definition of the struct throws an error in the tooling.

To take a simple example mentioned in the struct docs, to define a struct for GPS location one could define:

Types.GPSLocation:
  type: struct
  description: location.

Types.GPSLocation.Latitude:
  type: property
  datatype: string
  description: latitude.

Types.GPSLocation.Longitude:
  type: property
  datatype: string
  description: longitude.

But it seems one cannot compose the struct out of signals in the broader tree eg. from signals in the Vehicle.CurrentLocation path eg. using an #include.

Is there a way to do what I am describing above? If no, is there a reason its a bad idea and/or why it was prohibited?

[erikbosch]

The reasoning when creating the struct concept was that signals can be seen as something similar to variables in many programming languages, and you cannot reuse/reference a variable when creating a struct or class. VSS signals also specifies if they are sensors/actuators/attributes, but that information does not make any sense inside a struct. Technically in vss-tools it would have been possibly to allow signals inside structs, as they contain the information needed.

When we introduced the structs we discussed hypothetically that the current CurrentLocation signals possible should be removed and instead replaced with a single signal using a struct, but nothing has really happened there.

It could also be good to know that there have been other proposals to separate data representation from signals, like presented in a presentation from Ford on the links below.

https://wiki.covesa.global/display/WIK4/Data+Models+and+Ontologies
https://wiki.covesa.global/download/attachments/53510159/VSS%20Extensions%20and%20Ford%20Signal%20Ontology.pptx?version=2&modificationDate=1694797760649&api=v2

That would result in something like below, and with that approach it would be easy to reuse Vehicle. Longitude for both individual signals as well as inside structs. But no active implementation ongoing in that area either.

CurrentLocation.Longitude:
  property: Vehicle.Longitude
  type: sensor
  description: Current longitude of vehicle in WGS 84 geodetic coordinates, as measured at the position of GNSS receiver antenna.

Vehicle.Longitude:
  datatype: double
  type: property
  min: -180
  max: 180
  unit: degrees
  description: Longitude in WGS 84 geodetic coordinates.

The advantage would be that we only would need to specify min/max for longitude in a single location, compared to today when we have multiple.

[jsyvanen]

Cheers.

A facility for being able to reference already defined signals (or as in the case of the above suggestion properties) would be very useful. The tree is simple and useful in a number of ways but it has been somewhat difficult to apply in many instances.

In our use-case(s) we have a number of complex objects that we foresee as needing to contain multiple signals, initially we were hoping we could use struct types for this and represent these objects within our VSS model itself along with the signals contained in it. I think the way we'd now address this is to leave this representation issue outside VSS itself and use VSS only to validate that referenced signals are valid.

Is the working group interested in having the above type of initiative driven?

[erikbosch]

Now I think that I understand your use-case - you want to aggregate/derive larger objects from other signals, which could be useful if you for instance want to have a struct containing vehicle speed, position and fuel-level or an identifier to be able to get/set/transmit those 3 signals in a single operation.

A possible solution to this could be to use a special field like vss-ref to indicate which signal that provides values

Types.MyTransferStruct:
  type: struct
  description: Some data to be sent to backend.

Types.MyTransferStruct.Latitude:
  type: property
  datatype: float
  vss-ref: Vehicle.CurrentLocation.Latitude
  description: latitude.

Types.MyTransferStruct.MyTemperature:
  type: property
  datatype: int8
  vss-ref: Vehicle.OutsideTemperature
  description: longitude.

There have been some discussion on this long time ago, but then the conclusion was that it is something that should not be part of "core VSS" but rather something defined/used by downstream implementation projects.

We are always interested in new ideas on how to extend/improve VSS. If you have a rough idea we could reserve 10-15 minutes in an upcoming VSS meeting (Tuesdays 16.00 CET/CEST) for you to present the idea and for discussion.

[jsyvanen]

Thanks @erikbosch this idea with vss-ref is helpful. With that it might be possible to include the "composed" complex objects into the tree itself instead of composing those outside the tree as part of serialisation process. Now to align the datatype description at the signal vs. struct definition levels...

Re: improvements/extensions my hope is that something like this will come out of our project for the community. WIP. Cheers.

[jdacoello]

I think this issue origines from the fact that one tree hierarchy is not expressive enough. So, you might need to work around and increase the features of VSS. However, I would like to point out again that any evolution of VSS into something bigger must include the adoption of an established language that natively supports cross references. This was the main message of the presentation I did at the last COVESA event.

One option (not the only one) is evolving VSS with GraphQL schema language. Check out the slides, they contain plenty of examples.

[nwesem]

MoM:

• open for more comments, please read through