Parameters during runtime (Runtime Variables)
Bugzilla Link | 4287 |
Created on | Jan 27, 2020 11:03 |
Version | unspecified |
Extended Description
This is a copy of email I've sent to everyone regarding the problems when we use ParameterAction during runtime.
Hello,
Yesterday over the ASAM meeting we elaborated a bit on ManeuverGroups and Parameters and it was decided that a smaller meeting will be held to discuss the situations what to do with Parameters during runtime. I’m sending this mail as additional elaboration on what I was trying to say then and as a notice that this is one of the last corner cases of the standard that could impose some kind of trouble.
For reference I’ll describe once again the scenario mentioned during the meeting, let’s call it Scenario A.
Scenario A:
Define one parameter speed=50km/h inside our parameter declaration.
Use one vehicle Vehicle 1 inside this scenario and with properly created storyboard structure (Story 1, Act 1, ManeuverGroup 1, Maneuver 1, Event 1) have only one SpeedAction that for its absoluteTargetSpeed uses parameter $speed.
We don’t have any condition created for starting Event 1 so this means SpeedAction will start executing immediately; let us also can assume that this action will execute for couple of seconds.
Now if we introduce additional ParameterSetAction - which is a global action - inside its separate storyboard structure (Story 2, Act 1, ManeuverGroup 1, Maneuver 1, Event 1) and we say that we want to set new value for parameter $speed, for example $speed=150km/h, then this begs the question what will happen to the speed of Vehicle 1 that is currently executing SpeedAction that is using $speed?
Basically, the parameter doesn’t know if it is in conflict with some other action.
There is also one more interesting scenario that demonstrates how things can hairy pretty quickly, let’s call it scenario B.
Scenario B:
Define one parameter executor=”Vehicle 1” inside our parameter declaration.
Use two vehicles this time, Vehicle 1 and Vehicle 2, and storyboard structure (Story 1, Act 1, ManeuverGroup 1, Maneuver 1, Event 1) with SpeedAction but in the actors of the ManeuverGroup 1 you put parameter $executor.
If we run this scenario SpeedAction will get executed by Vechicle 1. Great. Now lets again use the ParameterSetAction and make it set $executor=”Vehicle 2” just when the Vehicle 1 is in the middle of execution of SpeedAction. Who in the end is running this SpeedAction, one bit Vehicle 1 and one bit Vehicle 2? This of course in practice doesn’t have any sense.
Scenario C:
Additional complications can arise if use a $executor as one of the triggeringEntitites inside conditions. We combine that with new ManeuverGroup which now has option selectTriggeringEntities that dynamically sets the actors.
The flow is: Conditions have triggeringEntities that can be $params. When condition becomes true those triggeringEntities become actors on ManeuverGroup (if selectTriggeringEntities=true) and they are the one executing actions. As we have ParameterSetAction that can change $executor one need to be pretty sharp that day to find out what is going on.
My proposal is to just remove ParameterAction (and maybe ParameterCondition if we don’t need it). I can’t think of any kind of use case where this behavior of parameters (aka runtime variables) could be necessary, and if it actually is maybe we can add it to next version when implementation is more mature and elaborated.
Kind regards,
Daniel