In the current integration configuration the traffic simulation model runs on a separate computer, which communicates with the scenario module via an ethernet network. However, the plan is to integrate the traffic simulation model into the
Vehicle Dynamics Model Visual System
Traffic Simulation Model Steering wheel,
pedals,
…
Pos., speed, … of ambient veh The current view
Pos., speed, … of DS-vehicle Scenario Module
Pos., speed, … of DS-vehicle
scenario module and thereby get rid of the ethernet communication. This has not yet been possible to do due to ongoing work with the scenario module computer.
The current ethernet communication set up uses two different kinds of protocols. In order to be sure that commands like start, stop and freeze of the simulation reaches the simulation model; these commands are sent via a TCP/IP connection. The TCP protocol checks whether the IP-packages arrive at their destination and return feedback information to the sender. Thanks to this handshaking the sender know if the information has reached the receiver, the scenario module for example knows if the simulation model has received an initialization or a start command. Information about the state variables is instead sent via a UDP/IP connection. This protocol is more convenient to use when sending real time data since no handshaking is used. This makes the connection faster but more unreliable since the sender does not know which IP-packages that reach the receiver. The sender cannot even be sure of that the packages reach the receiver in the same order that they were sent in. The solution to the increased unreliability is to increase the send frequency. Then it does not matter if one package does not reach the receiver or if the packages arrive in the wrong order.
The receiver can discard any old package that arrives late and do not suffer from
“losing” a package since it quickly gets a new package with up to date information.
In order to minimize the time delay between actions in the simulator and the visualization of those actions, information in the main driving simulator loop is sent with a very high frequency, namely 200 Hz. The scenario module must always have up to date information about the simulated vehicles. This implies that the scenario module either must be able to handle a missing package from the traffic simulation model or that the send frequency from the simulation model to the scenario module must even be higher than the frequency in the main loop.
Irrespective of which approach that is used the update of the vehicles’ positions and their behavior must be run on different computer processor threads since the position and speed must be updated with the main loop frequency while running the behavioral update with this frequency is a waist of computer power. The high frequency position update can either be ran in the traffic simulation module or in the scenario module. We have chosen the latter approach in which the scenario module keeps the simulated vehicles’ positions and speeds up to date by extrapolating the latest information received from the traffic simulation model.
One problem when running the simulation model and the scenario module on different computers is the synchronization of clocks. The used clock in the scenario module and the traffic simulation model must be very well synchronized in order for the extrapolation of the vehicles’ position to be correct. This has been a problem in this work because the scenario module and the simulation model have been running on different operating systems. The traffic simulation model has been running on a Windows machine, on which it has been hard to find a clock with enough accuracy and that does not drift. This has resulted in that when driving close to a simulated vehicle this vehicle seems to jump a little back and forth. There is therefore an ongoing work of compiling the traffic simulation model to also be able to run in the operating system Linux in order to totally integrate the simulation model and the scenario module. This would solve the synchronization problem and would also lead to that the ethernet communication is unnecessary, which is quite nice since the ethernet communication has been a very common source of error during the integration work.
6 Validation
The primary outputs of the developed model are the behavior of the simulated vehicles, thus the primary output is at a microscopic level. It is therefore important to also validate this model at a microscopic level. If the model is valid at the microscopic level it will also generate valid results at a macroscopic level, noticeable is that the opposite does not always hold. However, how validation of the developed model on a micro level could and should be done is not obvious.
This chapter therefore starts with a discussion of different ways and methods for validating the model. The chapter then continues with a description of the two used validation approaches. The chapter ends with a discussion and some additional observations made during tests in the driving simulator.