"Duration" of TrafficCommands

[clemenshabedank]

It needs to be clarified if and how the state of an Action shall be transported to a TrafficParticipant. Looking at OpenSCENARIO 1.0 there is a State machine defined with the states Standby, Running and Complete. This state machine implies that certain Actions have a time and run (status: Running) until they are executed (status: Complete). This is made explicit in the Appendix A, where it is specified when an action ends (e.g. on reaching the speed, by reaching the targeted distance, by reaching the lane, ...).

Between the states, there are state transitions (Start, End, Stop, Skip) defined.

We should clarify if there shall be a feedback from the TrafficParticipant (or if the scenario engine decides about completion) and if the state transitions are relevant information to a TrafficParticipant.

Different solutions seem to be possible and shall be discussed:

1. Scenario Engine sends the respective Action(s) as TrafficCommands only once at the beginning of the Running state (as if the actions didn't have a time). The TrafficParticipant wouldn't be aware, when the scenario engine would regard the action as being completed.
2. Scenario Engine sends the respective Action(s) as TrafficCommands, as long as they are in Running State. The TrafficParticipant would be aware in this case, if the action is regarded as being completed. But it would not be aware about the transition. E.g. if there was a stop trigger (which means unsuccessful completion), this information would not be transferred.
3. Scenario Engine sends the respective Action(s) as TrafficCommands only once at the beginning of the Running state but also sends the state transition (maybe here some more specification would be needed in OpenSCENARIO 1.x what shall happen, if an Action, e.g. LaneChangeAction, is stopped prior to complete execution with a stopTransition).
4. The TrafficParticipant sends back Feedback (e.g. via TrafficUpdate) if an action is completed or if itself stops an Action. In this case the decision, if an action is completed, would not be the domain of the scenario engine anymore, although it should handle the state machine. Probably the most difficult solution, maybe not appropriate for now...

[brunoVTI]

In OSC 1.X we are currently discussing how to change the perception of Actions so that they are easier to understand. We are experimenting with a concept which divides private Actions in 2 categories - Control Strategies and Non-Control Strategies.

Control Strategy private Actions are those concerned with a goal that may take time to be fulfilled, for example: Lane change, reach speed, etc. Control Strategy private Actions assign a control strategy to an entity and are essentially a reference for whatever runtime controller instantiation (default controller, or custom controller) is controlling the entity; in order words, Control Strategy Private Actions assign the control strategies which tell controllers what to do.

All Control Strategy private Actions end whenever the task assigned by the control strategy is fulfilled. All other Actions end immediately.

From OSC's perspective, it does not matter who determines when the control strategy is fulfilled, be it the scenario engine, the TrafficParticipant, the TrafficParticipant's controller, or any other thing. OSC assumes that this information is available somewhere. OSC assumes that this information is available to whatever simulation component is regulating the "scenario runtime evolution", i.e. scenario engine, so that triggers can be evaluated.

Setting the contents of the OSI messages will narrow down the implementation options, and this is where it gets hard. In the implementation, how much "agency" does the TrafficParticipant have?

• Do we let the TrafficParticipant report when the control strategy is fulfilled or is it the scenario doing it?
  • If the TrafficParticipant reports it, then we need a message for it.
  • If the TrafficParticipant does not report it, then the message is not necessary.
  • We do not decide it and it is up to the implementation. In this case, we need the message for it and user uses it according to its implementation.
• Do we let the TrafficParticipant identify and solve the conflicts between control strategies, or is the scenario engine doing that?
  • If the TrafficParticipant needs to do this work, then it needs to be able to communicate that a control strategy will be aborted because of a conflict.
  • If the TrafficParticipant does not need to do this work, then we need a message into the TrafficParticipant telling it that a conflict arose and that control strategy X needs to be dropped.
  • We do not decide and it is up to the implementation. Then both messages need to be implemented and it is up to the individual implementations to decide how to do it.

Regardless of how the above questions are answered, some things are little more certain, at least to me:

• I do not think the TrafficParticipant should know about the Action states. Those states translate to "start doing this" or "stop doing what you are doing", and I think that is what the TrafficParticipant should see.

• If the Action is stopped, then the TrafficParticipant needs to be told that the control strategy associated to that Action is no longer valid. Stopping the Action happens in the scenario engine and there is no way for the TrafficParticipant to know that just from "introspection".

DISCLAIMER: This is my opinion not the opinion of the OSC 1.x group. The concept of Control Strategies is still work in progress and has not yet been approved by the working group, however it think it can be valuable to have it in the back of the mind when addressing this topic.

[clemenshabedank]

Thanks Bruno for this detailled feedback (again), and also for the great discussion in WP11 last Thursday together with Markus. Indeed, there are a few options. I got the feeling that the option to send "start doing this" / "abort doing this" / "you succeeded doing this" together with the regarding TrafficAction would be the best approach.
Since we don't have a Merge-process yet and it is quite urgent in SETLevel, I made a first suggestion there which will be discussed and than probably pushed to this official repo here.

[engelben]

I also think the approach to keeping the TrafficParticipant "blind" is a very appropriate abstraction level that also fits the action structure in OSC 1.

@clemenshabedank we will make sure to get the first revision of the change process in place by the project meeting at the latest