Add automated driving function state to host vehicle data

[caspar-ai]

Reference to a related issue in the repository

#545

Add a description

See the linked issue for more details, but at a high level, this adds the ability for a host vehicle to report details about the internal state of automated driving functions.

It also adds HostVehicleData to a TrafficUpdate to allow this information to be reported from a SuT to the simulator, or other simulation entities.

(HostVehicleData is already a top level message, and embedded in other "reporting" type messages, to allow this information to be propagated further if necessary)

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• My suggestion follows the style and contributors guidelines.
• I have taken care about the documentation.
• I have done the DCO signoff.
• My changes generate no errors when passing CI tests.
• I have successfully implemented and tested my fix/feature locally.
• Appropriate reviewer(s) are assigned.

[pmai]

I think this is the right approach and is already looking very good to me, with a couple of suggested changes/clarifications below. With those fixed it should theoretically be good to go from my point of view. But more airing should be given to other people involved in HostVehicleData.

[pmai]

@ThomasNaderBMW this proposal for the driver assistance information to be added to HostVehicleData seems pretty good to me, could you have a look?

At least the addition of the ID field (since we are making HostVehicleData a proper top-level message this is likely required for disambiguation) and potentially the optional addition to TrafficUpdate as a feedback mechanism to the simulator (e.g. for inclusion in SensorView) should likely go into 3.4 already, with the rest then added in 3.5 quickly thereafter, if not into 3.4...

[caspar-ai]

Thanks! Comments all make sense. I'll look at fixing those up today or tomorrow.

[caspar-ai]

Thanks @pmai, I've made all the changes you suggested.

I will leave this as draft until #547 has been merged then I can rebase this onto master and mark as ready for review.

[ThomasNaderBMW]

Good PR @caspar-ai !! Many good ideas we should discuss next CCB.
As stated in the comments I would appreciate merging my PR first and then do a rebase to the master here.
As general inspiration for your content, it would be good if you take a look at
https://github.com/OpenSimulationInterface/open-simulation-interface/pull/350/files
Naming, structuring and so on. I don't say it's better, but maybe contains some improvements ;)

[caspar-ai]

@ThomasNaderBMW I've had another look through the changes in #350, as a result I have:

• used the more generic message name from that PR for the message (VehicleAutomatedDrivingFunction)
• updated all the wording throughout from feature to function to match
• merged the two lists of function enums as best seemed sensible to me, but happy to change
  • added both references to the comment at the top
• added the UNAVAILABLE_STATE as that seemed relevant, I couldn't immediately work out what STARTING and STOPPING would be used for so didn't add, but happy to add in if they are useful

In terms of what I didn't do:

• I've not taken the extra intention and external requests fields
  • I do think these are really useful additions, but I also think they are don't have to be coupled with the basic name / state that is there now
  • as such, I thought it might be easiest to leave out for now to simplify discussions, and we can add in afterwards in a new PR
• I haven't included LEVEL_1, LEVEL_2 in the names of the functions
  • overall with the names, I already worry that there isn't a good set of common terms
  • adding in the level to the name feels like it adds more complexity to that
  • if we want to capture the level, perhaps that would be best as a separate field on the message? This would potentially allow a clearer distinction
  • for example, the same function PARKING_ASSIST could be level 1, 2, or 4 depending on the sophistication, this would remove the need for using _VALET and _ASSISTANT to distinguish, which sound potentially like company-specific names used to identify them
  • (admittedly it does break down in some cases, by the same logic CRUISE_CONTROL and ADAPTIVE_CRUISE_CONTROL could be the same function name at different levels, but both are well recognised industry terms)
  • one for discussion I think!

Hope that all makes sense, let me know what you think.

[ThomasNaderBMW]

@ThomasNaderBMW I've had another look through the changes in #350, as a result I have:

• used the more generic message name from that PR for the message (VehicleAutomatedDrivingFunction)

• updated all the wording throughout from feature to function to match

• merged the two lists of function enums as best seemed sensible to me, but happy to change

  • added both references to the comment at the top

• added the UNAVAILABLE_STATE as that seemed relevant, I couldn't immediately work out what STARTING and STOPPING would be used for so didn't add, but happy to add in if they are useful

In terms of what I didn't do:

• I've not taken the extra intention and external requests fields

  • I do think these are really useful additions, but I also think they are don't have to be coupled with the basic name / state that is there now
  • as such, I thought it might be easiest to leave out for now to simplify discussions, and we can add in afterwards in a new PR

• I haven't included LEVEL_1, LEVEL_2 in the names of the functions

  • overall with the names, I already worry that there isn't a good set of common terms
  • adding in the level to the name feels like it adds more complexity to that
  • if we want to capture the level, perhaps that would be best as a separate field on the message? This would potentially allow a clearer distinction
  • for example, the same function PARKING_ASSIST could be level 1, 2, or 4 depending on the sophistication, this would remove the need for using _VALET and _ASSISTANT to distinguish, which sound potentially like company-specific names used to identify them
  • (admittedly it does break down in some cases, by the same logic CRUISE_CONTROL and ADAPTIVE_CRUISE_CONTROL could be the same function name at different levels, but both are well recognised industry terms)
  • one for discussion I think!

Hope that all makes sense, let me know what you think.

@caspar-ai : Wow good job and glad to hear you took out some suggestions!
To your points, beside the comments I made:

• I agree on STARTING and STOPPING are not needed, at least in the first step
• Regarding states and intentions we also need a discussion in the CCB. If we keep it open intentions may be added in the future, we should already now adapt the structure to keep it extendible
• Regarding the LEVEL_x assignment I see your point. Maybe it is better to leave it open how advanced the function is.

[kmeids]

Output CCB 08.12.2021:

1. @ThomasNaderBMW could you please review the final updates and confirm if everything is OK.
2. @everyone, please perform a final documentation review.

[kmeids]

Output from CCB 19.01.2022:

1. @ThomasNaderBMW to directly contact @caspar-ai to discuss the following: Add automated driving function state to host vehicle data #589 (comment)

[stefancyliax]

CCB 02.02.2022:

• Decision: Topic can be merged once two small issues still open are fixed (DCO, Reference style).
• Merge to be done by: @stefancyliax

[ThomasNaderBMW]

As discussed in CCB.