2.2.3.4.1 Modeling a traffic participant

Different models may be involved in modeling a traffic participant. In all the use cases, a simulator loads and interprets a scenario and a map prior to execution. The scenario is, for example, provided by OpenSCENARIO. The map data is, for example, provided by OpenDRIVE. During runtime the simulator interacts with the traffic participants via OSI messages. There may be multiple instances of a traffic participant. The traffic participants are co-simulated.

The following figure shows a very simple use case.

1100
Figure 7. Simple traffic participant

The traffic participant bases its behavior only on an idealized view of the area around it. The traffic participant’s dynamics are included in the model if they exist.

The following figure shows a traffic participant with separately modeled behavior and dynamics.

1100
Figure 8. Traffic participants with separate dynamics

OSI currently provides only limited support for data structures that describe measured internal states of the traffic participant. An example for a traffic participant internal interface is the MotionRequest message that can be used to communicate planned behaviors from a behavior planning model to a dynamics model including, for example motion controllers and vehicle dynamics.

The following figure shows a more complex traffic participant.

1100
Figure 9. Traffic participant with sensor models, AD function, and dynamics model

This use case will probably be relevant for modeling the ego vehicle, which includes the system under test. The traffic participant includes an arbitrary number of sensor models. The sensor models consume sensor view and produce sensor data. The AD function consumes sensor data and produces input for the dynamics model. The loop to the environment simulation is closed via traffic update.

The following figure shows a cooperative use case with both an AD function and a human driver.

1100
Figure 10. Traffic participant with an AD function and human driver

It is possible to model a traffic participant with an AD function in the loop, but a human driver can still override the actuation command. This type of cooperative use case is, for example, relevant to studies on human-machine interaction. In this example, a virtual on-screen representation of the scenario, or mock-up, is added after the AD function. The driver-in-the-loop interacts with the dynamics model via this mock-up. OSI currently provides only limited interfaces for data flow between the driver and the dynamics model.