vehicle_signal_specification icon indicating copy to clipboard operation
vehicle_signal_specification copied to clipboard

Securing a consistent use of concepts that derive from other concepts

Open jdacoello opened this issue 1 year ago • 1 comments

There are currently situations where a property is modelled (e.g., Window.Position). Then another property, that could be easily derived from the previous one, is also defined (e.g., Window.IsOpen)

Vehicle.Cabin.Door.Row1.Left.Window.Position:
  datatype: uint8
  description: Window position. 0 = Fully closed 100 = Fully opened.
  max: 100
  min: 0
  type: sensor
  unit: percent
Vehicle.Cabin.Door.Row1.Left.Window.IsOpen:
  datatype: boolean
  description: Is window open or closed?
  type: sensor

Concepts like Window.IsOpen can be easily inferred from the Window.Position. What is the benefit of modeling multiple concepts that create redundant information? It can also be inconsistent in some cases. For instance, let's assume that Window.Position has the value of 50, but Window.IsOpen is False. As you can see, they are inconsistent because they contradict each other. When both are specified, the VSS user would be responsible for applying the necessary logic to validate the data before feeding the actual data to the corresponding topic.

Any idea how we can add consistency to these cases where basis and derived information is modelled?

I think that a guideline or a ruleset has to be provided because people are often tempted to further specify concepts that can easily be derived from others.

jdacoello avatar Oct 25 '23 13:10 jdacoello

This is an interesting question that we have played with to some extent, for example in trying to see if the Window.Position value could be generated through some for of timing. It does not appear to be very workable as too many factors need to be considered: temperature (slower movement when cold), aging (slower actuator when old), changing friction on the window gasket, etc.).

I would expect that some vehicles can nonetheless tell the window position with a reasonable level of accuracy. In that case, there is value in this signal being available. Thus, I don't necessarily see a contradiction in both signals being defined. Vehicles that can actually tell the window position would return values for Window.Position, while others would only report Window.IsOpen.

ppb2020 avatar Oct 31 '23 11:10 ppb2020