Scenario Authoring Overview
ISAT User's Guide Table of Contents
Scenario Authoring Overview
Basics
Scenario authoring involves the specification of both the static and dynamic elements of a virtual environment so that certain events appear to anyone who drives the simulator under the specific scenario, regardless of small differences in driving style or timing. For example, consider the testing of a new in-vehicle warning device that provides various alarms to warn drivers of potential collisions. The researchers are interested in seeing how different warning signals perform as far as their ability to alert the driver and prevent a collision. To test such a device, one should be able to create potential collision situations. One way to do this is to have the subject drive along a road and through an intersection controlled by traffic lights while the light is green. As the driver nears the intersection, another car (car B), which is initially stopped by the red light on the other leg of the intersection, begins moving, thus blocking the subject‟s path. Let us consider the issues in building such a scenario.
The problem
By far the most critical aspect of such a scenario is timing the motion of car B so that it provides a consistent time-to-collision condition for all subjects, something that is necessary in evaluating the collision avoidance device. However, additional issues have to be considered. When was car B created? Is car B is the same make and model for all subjects, or does it change? How does one ensure that the traffic light is green when the subject approaches as opposed to yellow or red? What if different subjects travel at different speeds toward the intersection?
One approach to building such a scenario is to script everything explicitly that is dynamic about the virtual environment so that its timing is tied to the motion of the simulator driver. For example, time 0 is when the scenario starts, time 40 is when the driver reaches some fixed distance from the intersection, time 60 is when the driver's front bumper enters the intersection, and time 100 is when the driver reaches some point beyond the intersection. Scripting software can determine the value of time based on how fast or how slow the drivers moves and then trigger every change in the virtual environment based on the parametric time scale. For example, the light will turn green at time 20, and car B will begin moving at time 40 and reach the middle of the intersection at time 60. That way, everything is scripted, and no matter how fast or slow the driver moves, the event will happen consistently.
Such techniques are often used in simulators that use relatively short scenarios or involve few dynamic traffic elements. The technique is simple, easy to understand, and provides deterministic results. However, when considering such a technique for use in high-fidelity simulators, several problems arise. In high-fidelity simulators, scenarios are longer and generally involve multiple entities. Coordinating one or two elements through explicit scripting for a 5-minute scenario is reasonable, but coordinating 500 vehicles for a 45-minute scenario is daunting and virtually impossible. Note that the 500 vehicles may not be active at the same time; in fact, they may represent traffic in the opposing lane that is not an integral part of the scenario. Nevertheless, if scripting were the only tool available, it would have to be used for all vehicles. Another complication has to do with what happens after the event takes place. One may want to trigger different scenarios after the near-collision event, depending on the outcome of the first event. For example, if there was a near collision, a less severe event may need to take place at the next intersection, but if the subject veered away early enough, a more severe event may be necessary. Such decision-making cannot be programmed when scripting is the only tool.
An alternative approach is to use intelligent agents that populate the simulator‟s virtual environment and behave autonomously. For example, autonomous driver models can be used to control the various vehicles in the scene. In addition, an intelligent manager can control the traffic lights so their timing follows a specific pattern. Such an approach makes it easy to create scenarios involving multiple entities because the labor-intensive specification of the individual behavior of every entity is eliminated. In addition, the length of the scenario does not overly complicate the development of the scenario because autonomous entities can be created automatically throughout the scenario. However, various other complexities surface. For example, timing and coordination become harder to achieve. Consider the example described earlier. If a traffic light manager controls the state of the traffic lights based on a fixed pattern, there is no guarantee that the light will be green when the simulator driver approaches the intersection. Furthermore, if vehicles are autonomous, there is no guarantee that car B will be waiting at a red light because it may have decided to pick a different route earlier. Even if a car is waiting at the red light, subjects will travel at different speeds. Therefore, they will reach the intersection at different times, and the proper time for car B to block the intersection is not known a priori.
ISAT Toolset Approach
The approach used for scenario authoring in the NADS software and supported by the ISAT is a hybrid between the two techniques, with emphasis on using intelligent agents in conjunction with coordinators to ensure consistency. Specifically, the ISAT allows the user to create any number of entities that behave largely autonomously. In addition, the user can create coordinators; coordinators are "invisible" entities that exist in the virtual environment, but are not displayed. These coordinators orchestrate events by monitoring what happens and modifying the autonomous behavior of the remaining agents to achieve a pre-specified goal. Additional coordinators can be used to automate the generation of traffic, control the traffic lights, modify the environment conditions, and control numerous aspects of the simulator‟s operation. In addition, the ISAT allows the creation of purely scripted entities. The evolution of these entities is completely deterministic, and their timing can be either independent or dependent on the simulator driver's actions.
Deterministic objects, or Deterministic Dynamic Objects (DDOs), as they are referred to in the ISAT, are objects whose behavior is pre-scripted by the user. Specifically, the user can select a path and specify the velocity of the DDO at each point in the path. While the scenario is running, a DDO simply follows its path according to the user's specification. Dependent DDOs, or DDDOs, are similar in that they follow a specific path, but their velocity adjusts so they reach a specific point of their path at the same time another entity reaches another target point. DDDOs allow vehicles that follow a scripted path to behave consistently as far as their relative position to another object (including the simulator driver), independent of the variation in the other object's speed. Both DDOs and DDDOs lack collision-avoidance capabilities.
Autonomous Dynamic Objects (ADOs) use a sophisticated autonomous driver model that controls their motion. One can think of an ADO as a human driver that is driving around the virtual environment trying to reach its destination. An ADO will follow the rules of the road, including following the speed limit and respecting traffic lights, and will exhibit most behaviors exhibited by real drivers. A unique feature of the driver model used in the NADS SDC, however, is the ability to have its default behavior modified at runtime. For example, an ADO can be told to follow a specific speed independent of the external conditions, to change lanes, to take a particular turn, and so on. Such commands can be initiated by the researcher while the scenario is running, or can be issued by the various coordinators that can be authored a priori. The latter is by far the most common due to its repeatability. The key coordinators include the trigger, the traffic manager, the traffic source, and the traffic light manager.
The trigger is an entity that is given a series of conditions and a series of actions. It continuously evaluates its conditions and, when they are all true, performs the actions. Examples of conditions include another object reaching a specific point in the road network or a traffic light turning green. Various actions are available, including creating a new entity, deleting an existing entity, modifying the cycle of the traffic lights, terminating the simulation, causing system failures on the vehicle driven by the simulator driver, and issuing behavior modification commands to a set of autonomous entities. A detailed description of how the trigger operates and how the ISAT can be used to specify the trigger‟s events and actions is given later in this document.
The traffic manager is tasked with generating autonomous traffic to populate the area around the driver. Because of a finite limit on the computational resources of the simulator, it is not possible to simulate an arbitrary number of vehicles in real-time. Therefore, traffic is created only in the area around the driver. The traffic manager is given a specific traffic profile and a desired density, and it will create or delete objects as necessary to maintain that density.
A traffic source is another coordinator whose job is to create traffic. Unlike the traffic manager, however, it creates vehicles at a specific point in the database.
The traffic light manager is responsible for controlling the state of traffic lights in the scene. Through the ISAT, the user can program the traffic light manager to achieve just about any timing cycle. In addition, the traffic light manager, in conjunction with the triggers, allows the linking of traffic lights to achieve coordinated traffic light groups.
