Add door position

[erikbosch]

Some vehicles (e.g. minivans) may have (sliding) doors that are electronically controlled and which can be stopped in various positions. Then a signal and a switch makes sense.

Inspired by DOOR_POS/DOOR_MOVE in Android VHAL https://android.googlesource.com/platform/hardware/interfaces/+/master/automotive/vehicle/2.0/types.hal.

[erikbosch]

Meeting discussion:

• Please review
• Daniel: It would be great to have something modular that can be reused for all types of moving parts
• Erik: Could possible by achieved by having signals in a branch
• Daniel: We can compare with interior lights
• Pierre: Would we possibly need an "IsSlidingDoor" (or "IsPositionalDoor" or similar) signal to state if door supports position
• Daniel: We need to provide mechanism to define what exist in your vehicle, selecting the few concepts that you need. Better to select what you need than to remove what you do not need
• Pierre: VSS is superset, but we use a subset matching the current vehicle. I need mechanism to say that this particular door has position.
• Ulf: Alternative is tooling supporting removal
• Erik: This could possibly be an interesting topic for next AMM - how to define what entities a vehicle supports
• AP: Erik to create Github issue for the general discussion (created in Mechanism(s) to define what signals that are supported in a vehicle #628)

[erikbosch]

Concerning the idea from @jdacoello to "reuse a definition" for moveable parts. In general it is feasible to have a common *.vspec file that is included in many different places. The change compared to today would be that the description of individual signals in generated/expanded VSS then would be generic, i.e. you need to consider the path to know whether the signal concerns a window, a door or a shade. I.e. the description for the position signal for the sunroof window would just say "position, 0 = fully closed, 100 = fully open" or similar. But that is maybe not a problem.

That could if needed potentially be managed by changing description during generation/expansion and including (parts of) the description from branches above.

[erikbosch]

As suggested by Daniel I did a test to try to restructure for reuse, i.e. using the same set of signals for all movable items. See the dummy PR below:

https://github.com/boschglobal/vehicle_signal_specification/pull/23/files

I think it would work quite well - but I did some observations

• By using the same definition we may need to specify context-specific differences on branch level. An example is blinders/shade, where the meaning of open/close may not be crystal clear and where the definition of position previously were different (i.e. we will get opposite meaning of signal compared to before)
• We will also have the same type (i.e. sensor or actuator) on all use-cases. That does not need to be a problem, a client anyway need to know if they have rights to access a signal as an actuator or not.

Lets discuss next week if we want to go this path.

[erikbosch]

Meeting notes:

• Daniel: we could potentially include names from parent branch and replace existing "item" Like replace <item> with something inherited
• AP: Erik to create issue for variables in description (Edit: Erik created Support of variables in signal descriptions. #631)
• Daniel: in long term "path" should not be used as identifier. If we have generic pieces/snippets, how shall we handle setting identifiers on signals.
• Adnan: UUID two parts, one is tracing elements, the other for binary identifiers for transmit. UUIDs can be one part of the solution to maintain versioning.
• Daniel: We shall not have more than a few thousands concepts/signals
  -AP: erik to integrate the "moveable item" concept into this PR.

[erikbosch]

Updated according to discussion. What we need to decide at some meeting - s the semantic change of the Shade signals so important that it must be part of a major release. As the change is only in description it will not break any existing integrations, but later if client implement according to description from v4.0 and server-side from v4.1 then there will be problems found in integration test. As it only affect semantic of signal my view is that we do not need to release it as a major release.

[erikbosch]

Meeting notes:

• Sebastian: We actually change the meaning. Not so sure
• Ulf: If we set a policy that semantic change does not result in a major change. Maybe ok here, but not in others, seems risky.
• Erik: Do we want to start using two branches, one for major, one for minor?
• Daniel: This is not a major. Can start from initial position rather than open/close. Can use StartPos=0 and EndPos=100, realtionship to IsOpen depends on context. StartPos and EndPos needs to be described for every usage (in freetext).
• Erik: If we use StartPos/EndPos and describe that endpos for Shade is "Fully deployed". use overlay if range does not fit. Keep switch values (open/close)
• Pierre: Overlays-if we want portable overlays we have an issue if semantic is left to developer. Prefer if we have a clear definition embedded in catalog.
• Pierre: Concerning Minor/Major, do not expect that I need to changes if I move from one minor to another. In the case I would need to make a change. Not what I would expect. So this type of change would be major.
• Erik: Will update the PR to use StartPos/EndPos. I think it will be possible without changing semantics.
• Daniel: We could possibly have multiple "types" of doors if needed.
• Erik: Do we need to start supporting two branches (minor changes and major changes)?
• Daniel: Possibly start by defining classication for changes
• AP Erik: Create an issue for general major/minor process (Process for handling major and minor changes #634)
• Daniel: Think it works well with with the proposal from Adnan on concepts.

[erikbosch]

Meeting notes:

• Please review, will be merged next week unless there are objections

[erikbosch]

Meeting decision: merge