Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Securing a consistent use of concepts that derive from other concepts #675

Open
jdacoello opened this issue Oct 25, 2023 · 1 comment
Open

Comments

@jdacoello
Copy link
Contributor

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.

@ppb2020
Copy link
Collaborator

ppb2020 commented Oct 31, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants