You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.IsOpen:
datatype: booleandescription: 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.
The text was updated successfully, but these errors were encountered:
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.
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)Concepts like
Window.IsOpen
can be easily inferred from theWindow.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 thatWindow.Position
has the value of50
, butWindow.IsOpen
isFalse
. 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.
The text was updated successfully, but these errors were encountered: