Add signals for Motion Management

[erikbosch]

This is a proposal to add a number of signals for vehicle motion management, for instance making sure that vehicle stability is maintained during braking and when turning. As this is somewhat complex area it is also proposed to add a page in documentation to describe possible usage.

I will invite subject matter experts to the VSS meetings October 22nd and 29th so that they can give background to the change and answer questions.

[SebastianSchildt]

You mean invite them October? I assume not September NEXT year?

[erikbosch]

You mean invite them October? I assume not September NEXT year?

Oh dear, is it already October?

[SebastianSchildt]

I was wondering, with these "more specialized" VSS areas, should we give easy options (i.e. via overlay) to ONLY transform this branch, or maybe even formulate this as a self contained tree (and thus potential overlay).

Don't get me wrong, I think it is very cool to extend VSS in this direction, and instead of blocking this with another half year discussion, let's rather check and merge it. I am just thinking that the criteria for "generally useful" when deciding what to add later are different from the VehicleMotion Branch compared to the whole tree (or let's say infotainment), so maybe it is the time to have the moduels/profiles/composable stndnard model discussion again.

[erikbosch]

Concerning separate signals for target values (as discussed in last meeting) we had some previous discussion in #744.
I think one approach could be to discuss on what level we want to have the "default" actuation functionality. Historically in VSS, we have sort of assumed that the actuation part for Door.IsOpen corresponds to the interface available to the driver/owner, possibly through an app. That a request comes from QM and some safety-relevant components needs to check that it it is safe to actually open door before sending the open door request to the actual door actuator. Theoretically we could have a another actuator that represents the actual command send to the "stupid" door motor.

In cases where there could be more advanced logic before deciding what to request from the real actuator we have often used separate signals, like a separate signal for target cruise control speed. With that approach, if one just see vehicle motion management as an "optional system", it sort of makes sense to use separate signals. Maybe the driver has the ability to disable the vehicle motion system, and then the drive train and brakes will react directly based on pedal position. I.e. vehicle motion system cannot directly control brakes and electrical engine. So I think one need to check in individual cases if we think that having a traditional "dual usage" actuator makes sense.

[erikbosch]

MoM:

• Stefan: Important to have AsIs and ShouldBe
• Mattias: There are where relevant
• Erik: Potential merge decision next week, if no open points/reviews/remarks/discussions at next meeting 5th we may take a merge decision.
• Erik: Continue review, please add discussion topics to the Pull Request so Mattias/Markus can read/prepare and if possible join next meeting.
• Ulf: Thinks it is reasonable for some signals to have both current and target, when reasonable. "Current" shall be without suffix, target shall have "Target" suffix.

[erikbosch]

MoM:

• Please review, to be merged next week unless there are any outstanding discussions/objections
• Stephen: Do we have any guidance on when to use a new branch vs. distribute into existing trees (like chassis)?
• Erik: Do not think so, can check it up

[erikbosch]

MoM: Merge