![](bg5.png)
between reference and system time), or to twice pass-
ing a certain time interval (in the opposite case). Traf-
ficSimulation estimates the trend of the clock inaccu-
racy over a few seconds and adjusts the global clock
speed to compensate for the trend. Using a dedicated
network and identical computers, clock speed differ-
ences fall below 0.1%, which leads to clock inaccura-
cies in the range of one or two milliseconds.
3.6 Inter-module Event Handling
The type of event referred to here is a message rather
than the representation of a state change (see 2.1).
Events are a means of informing a part of a soft-
ware that something has happened, thereby decou-
pling the origin of the event from the one or more
listeners attached to it. The decoupling means that
the listener usually has no access to the object that is-
sues it, and that the listener’s notify() function is
called in a different thread. Usually, there is a delay
between posting the event and the moment when the
notify is called, but the delay should be within cer-
tain limits. For every event, the notify() function
should be called exactly once. The events should be
presented to the listener in the order of their occur-
rence. TrafficSimulation provides a mutex-protected
FIFO event queue for every module. Whenever an
event is posted, it is pushed to the event queues of all
modules. The event queue is emptied between acquir-
ing the state data objects and executing the update()
function. Since smart pointers to the event object are
inserted into the queues, no memory and computation
time is wasted on copying. The delay between event
creation and the call of the notify() function is min-
imal for every module.
4 CORE MODULES
4.1 Road Module
The road is an essential part of TrafficSimulation. It
can be created according to track information files,
but mostly it is created randomly, according to con-
figurable distributions of curviness. The accessible
track is created about 2 km ahead of, and deleted 2 km
behind the position of the reference vehicle. This
keeps the amount of memory used for the road ge-
ometry data (about 1 MB per km) approximately con-
stant. The data that forms the road is essentially a
graph of interconnected RoadSection objects. Every
RoadSection is defined to be of a clothoid structure
with constant curvature change. It is subdivided into
RoadStrip objects, which laterally span the road. The
RoadStrip is the unit that is appended to the road
in one step. It contains all geometrical information
needed to put additional objects next to the road, like
buildings, trees or traffic signs. For every lane and the
left and the right bound, a RoadStrip contains a Road-
Segment object. This smallest unit of geometric road
information is used by the vehicles.
The Road Module is also responsible for provid-
ing the graphical data needed in order to render the
road. Surface textures can be changed online, as well
as brightness and contrast with the lane markings.
Since lane marking structure is crucial for testing lane
detection algorithms, the patterns of lane markings
can be configured, double and triple lane markings as
well bott’s dots can be used.
The Road Module also determines positions
where new vehicles can be created and the area from
where vehicles have to be removed in order to not
leave the valid track information.
4.2 Vehicle Module
Obviously, the Vehicle Module is the functional unit
responsible for the one or many vehicles on the road.
It creates and deletes vehicles according to the infor-
mation from the Road Module (see 4.1). Every vehi-
cle is composed of four parts:
• a driver model, which computes acceleration and
steering data. Special cases of a driver model
are the Steering Wheel Plug-In, where these data
are provided by a human driver, and the External
Driver Model Plug-In that obtains these data ei-
ther from ethernet or from the CAN bus
• a vehicle model, which computes the physical
state changes that affect the vehicle when apply-
ing the driver commands. TrafficSimulation con-
tains by default a standard linear model, which
is sufficient for most applications. If a very pre-
cise vehicle model is required, the CarSIM vehicle
model is a better option. It can be integrated using
the CarSIM Vehicle Model Plug-In
• a vehicle controller, which is a mediation layer
between driver and vehicle model. The default
implementation maps the control data from the
driver model directly to the vehicle model. But
it can be used to model intervention systems that
correct the driver’s steering commands in case of
eg. an imminent collision
• a 3D model of the appearance of the car. Illumi-
nation, including turn signals, and wheel rotation
are modelled.
Every vehicle is equipped with a state data object. A
large fraction of data is provided by the vehicle mod-
A VERSATILE SIMULATED REALITY FRAMEWORK - From Embedded Components to ADAS
181