See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/277310777

Real-Time Traffic Conditions with SUMO for ITS Austria West

Conference Paper · May 2013

DOI: 10.1007/978-3-662-45079-6_11

CITATIONS READS

10 438

4 authors, including:

Petru Pau Karl-Heinz Kastner

Johannes Kepler University Linz RISC Software GmbH
12 PUBLICATIONS   77 CITATIONS    4 PUBLICATIONS   26 CITATIONS   

SEE PROFILE SEE PROFILE

Robert Keber
Johannes Kepler University Linz
4 PUBLICATIONS   17 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ITS Upper Austria View project

All content following this page was uploaded by Robert Keber on 04 December 2019.

The user has requested enhancement of the downloaded file.

 Real-Time Traffic Conditions with SUMO
for ITS Austria West

Karl-Heinz Kastner1, Robert Keber1, Petru Pau1, and Martin Samal1

1
RISC Software GmbH, Softwarepark 35,
4232 Hagenberg, Austria
{ karl-heinz.kastner, robert.keber, petru.pau, martin.samal }@risc.software.at

Abstract. ITS Austria West is a long-term project, funded by the Austrian gov-
ernment, to create a platform for providing real-time traffic data and prognoses.
The calculation of the traffic situation is based on the open source package
SUMO (Simulation of Urban MObility). One innovation in this project is the
scenario builder, a module which maintains the origin/destination matrix and
aggregates data from various sources, like traffic counters and floating car data.
The simulation model is continuously calibrated in order to provide an accurate
view of the traffic situation in the whole street network. The calculated level-of-
service information is visualized and exported to other intelligent transport sys-
tems. Due to the complexity of the model (streets, vehicles and real-time data),
the simulation’s performance is unsatisfactory. A possible improvement is the
parallelization of SUMO.
Keywords: traffic simulation, traffic condition, parallel computing.

1 Introduction

Predictably, the future Intelligent Transport Systems (ITS) will make a significant
contribution to secure our long-term mobility. Challenges facing such systems include
intelligent handling of the increasing traffic by use of efficient multimodal transport,
as well as the need to a balanced use of existing transport infrastructure. In this re-
spect, the availability of reliable real-time traffic information to all stakeholders (insti-
tutions, companies and individuals) is necessary.
The project ITS Austria West aims at providing a traffic data platform which gen-
erates accurate information regarding the current traffic situation, based on a (limited)
number of traffic data sources and on historical information regarding vehicle trips on
Upper Austrian roads. For the computation of current status of each road, as well as
for short-term prognoses, the traffic simulation package SUMO is used.
In this paper we describe the concepts of ITS Austria West and focus on the inte-
gration of SUMO, and its results, into the real-time traffic data platform.
 Section 2 contains an overview of the ITS Austria West project, its architecture and
short descriptions of the main components. In section 3 we describe the integration of
SUMO package within ITS Austria West and give some technical details about our
approach to a parallel SUMO. Section 4 contains some ideas about consuming the
results – using the traffic information provided by SUMO to define level-of-service
values that can be used to describe synthetically the current traffic status. We end with
some conclusions and future extensions.

2 ITS Austria West

The main goal of the project ITS Austria West is to continuously provide real-time
snapshots of the traffic situation in Upper Austria and Salzburg to the VAO service
(Verkehrsauskunft Österreich – Austrian Traffic Information System, [5]). Project
partners are the state Upper Austria, the state Salzburg, RISC Software GmbH, Salz-
burg Research and Logistikum Steyr. The project is funded by the Austrian KLIEN
fond (“Klima- und Energiefond”) and by the Upper Austrian government. It started in
June 2011 and ends in September 2014.
The underlying street network is based on data provided by GIP [2] (“Gra-
phenintegrationsplattform”), a database which comprises all Austrian highways, inter-
state and municipal roads, as well as local, low-ranked streets. The GIP database was
created in the frame of a previous project conducted by all nine states of Austria. This
database is intended as a starting point for many current and future applications.
In order to create a real-time snapshot for the state of Upper Austria, up-to-date
traffic data is crucial. Various data sources are utilized: stationary vehicle counters, as
well as floating car data (FCD).

2.1 ITS Austria West: Architecture

Conceptually, the software realizing the tasks of ITS Austria West consists of:
- components handling the sensor data;
- components for visualizing or publishing results;
- a simulation environment;
- a module in charge with generating and running scenarios, and
- a management component.
Fig. 1 gives an overview of the system architecture, whose main components are ex-
plained in the following paragraphs.

The controlling part of the ITS West Austria Management System is the manage-
ment console, where all processes are created, parameterized and controlled.

The scenario builder, triggered by the console, is responsible for the periodic crea-
tion of new scenarios, which serve as basis for the simulation of the traffic for the
next time interval. This complex component works with a model of the Upper Austri-
 Management Console
VLSA

Scenario
Scenario
Demand Builder

Simulation
GIP

WMS

VDL FCD
Result

Fig. 1 ITS Austria West Management System: System architecture.

an road network, and uses the real-time sensor data, together with the output of run-
ning simulations, to generate periodically snapshots of the traffic status.

Computed values of the traffic status (summarized as level of services – LoS, see
[3]) are made available in various ways. An important outlet is a set of WMS layers
(web map service, see [4]), published and made available via a website: The roads
with delays or traffic jams are marked with standardized colors, as well as the por-
tions with road works or roadblocks.

Since not all roads are covered by sensors, some way to extrapolate the known, re-
al-time traffic values to the uncovered streets has to be realized. We use traffic simu-
lation applications to estimate traffic values on all roads of the street network. The
simulation environment makes it possible to start simulations (SUMO, for the mo-
ment, but other systems are under consideration as well), to communicate with them,
and to extract their results.

The sensor data module receives information from different types of sensors:

1. Vehicle detection loops (VDL) are stationary detectors which count the number of
vehicles and their velocity. About 80 vehicle detection cells, owned by the Upper
Austrian government, are installed on the main streets. Road maintenance data, al-
so owned by the Upper Austrian government, are used to detect streets with road-
blocks. Last but not least, the Austrian highway agency ASFINAG streams up-to-
date information for the 2.178 km Austrian highways.
2. Floating car data is provided by the Austrian emergency rescue service “Samar-
iterbund” (only from vehicles that are not in action), some taxi fleets and a world-
wide GPS tracking company.
 The VLSA configuration contains locations of the traffic lights and the logic behind
their functioning. Based on the VLSA, the crossroads with traffic lights are identified
and integrated in the internal street network.
The demand model, i.e. the origin / destination matrix, is provided by the Upper
Austrian authorities and adapted using historical traffic data on Upper Austrian roads.
From the raw data collected from stationary sensors, time-variation curves with the
traffic values are computed and, based on these curves, the routes from the original
demand model are temporally distributed during one day. These routes serve as input
for the simulation tools.

3 Traffic simulation

In order to fill up gaps in the network coverage with sensors, traffic simulation appli-
cations offer an attractive alternative. Such applications, developed since the 1950s,
can be classified in microscopic, mesoscopic and macroscopic.
In a microscopic model every vehicle is simulated. Such a model contains a de-
tailed street graph, with traffic lights and turn lanes, and a demand model – an origin /
destination matrix.
Mesoscopic models describe the traffic entities (roads and vehicles) at an equal
level of detail, but their behavior and interactions are described at a lower level of
detail.
In macroscopic models all parts are simulated in a lower detail. Traffic flow values
are computed and maintained, rather than individual vehicles.

Main commercial providers of traffic simulation applications are PTV (with

VISUM), Aimsun, Caliper and UAF, but for development purposes, the free, open-
source simulation tool SUMO is among the most interesting.

The computation power of nowadays computers makes it possible to use, with

some success, microscopic traffic simulation applications even for large-scale models,
or real-life models. These tools should provide the maximum level of accuracy in
modelling and predicting the values of traffic for whole geographic regions, during
prolonged periods of time.
They come, however, with some challenges:

1. Modelling the road network: Problems arise from inexactitudes in data, and from
the tradeoff between the efficiency requirements (i.e., keeping the number of
streets as small as possible) and accuracy requirements (i.e., how well the road
network model represents the real street network).
2. Modelling the routes: The demand model provided by authorities becomes quickly
obsolete, due to the highly dynamical social and economic conditions in the mod-
elled region.
3. Inherent complexity of the simulation: Microscopic traffic simulation applications
handle every action of every vehicle, which might lead to millions of operations
per second.
3.1 Using SUMO for ITS Austria West
SUMO is an open source, microscopic simulation package developed by the Ger-
man Aerospace Center (DLR) in 2001. It is not only a traffic simulation, but rather a
suite of applications which help prepare and perform the simulation of traffic [1].
In order to be able to employ SUMO in ITS Austria West, a model of the road
network and a model of the trips (with the full definition of the roads for each trip)
must be available.
The road network is generated periodically from the latest version of the GIP data-
base. Additional information comes from the Upper Austrian traffic light system and
from the stationary vehicle sensors. With this input, a SUMO network is generated, in
which the roads, intersections, turning relations, traffic lights and vehicle induction
loops are modeled.
The set of daily routes is computed in a complex process in which the trips con-
tained in the origin-destination matrix are distributed along the daily time variation
curves.

3.2 Simulation Run

In order to offer a realistic and useful view of the traffic status, periodical snap-
shots are sufficient. Every few minutes traffic data collected from sensors or provided
by a simulation must be integrated into such a snapshot.
There are two ways in which a traffic simulation tool can be used:

Sensor data

Route generation

Network and
vehicle routes
initialization
Simulation

Traffic values Sensor data

Integration and
Route generation

Network and
vehicle routes normal step
Simulation

.
.
.

Fig. 2 Running more instances of the simulation application, one in each time interval.

1. The simulation application is started at the beginning of a time interval; it runs for
a time (5 minutes simulation time), and then stops. The output is collected and in-
terpreted. Fig. 2 contains a graphical representation of this process.
2. The simulation application runs continuously. At the beginning of a time interval,
the next 5 minutes are simulated. When the simulation of this interval is complet-
ed, the results are collected and, if necessary, the model is adjusted (calibrated) on-
the-fly (A graphical depiction of this process can be seen in Fig. 3.)

Sensor data

Network and
vehicle routes calibration

Sensor data

Traffic values

calibration Sensor data

ITS
Traffic values Austria
West
calibration
Sensor data
Simulation

Traffic values

calibration

Fig. 3 Running one instance of the simulation application, with periodic calibration and output.

Regardless in which way the simulation is used, calibrations need to be performed

periodically. They might comprise vehicle re-routing, insertion of new vehicles or
removal of some vehicles already in the network. Also, the speed on some roads
might need to be changed, due to events which occurred in the reality.

It turned out that simply loading the whole model in SUMO takes prohibitively
long (about one minute or more). In the first, start-and-stop model, considerable time
is used up by initialization; even if the simulation runs exceedingly fast, too little time
remains for the tasks that need to be executed after the simulation has finished (inter-
pretation of results, aggregation of real-time data, generation of data for WMS layers,
preparation of data for the next simulation interval).
We decided to implement the second, always-running model.

Managing a Running SUMO Simulation

From the management console, an instance of the simulation application can be
started and communication mechanisms are set in place.
We use TraCI (Traffic Control Interface) API to send orders to SUMO. For ex-
tracting results, with the status of every vehicle currently running, and with the statis-
tics collected by vehicle induction loops, we use the socket-based dumping mecha-
nisms implemented in SUMO.
 Fig. 4 shows the activities taking place in the simulation and in ITS Austria West
during a time interval.
ITS Austria West

SUMO
.
. Latest sensor data
.
simulation of current interval
finished
socket
dump
Traffic values
Calibration:
- insertion
waiting - removal
- re-routing
of vehicles
TraCI

Calibration orders
start “Simulate to” order
simulation
simulating

simulation of current interval

finished
.
.
.

Fig. 4 Communication between SUMO and ITS Austria West.

At the beginning of the interval, calibration orders are sent to SUMO via TraCI.
They are immediately followed by a “Simulate To” order, which commands SUMO
to perform a simulation up to the end of the current interval, in simulation time.
SUMO integrates the changes contained in the calibration orders (adding new ve-
hicles, removing or re-routing existing vehicle) and immediately starts to simulate the
traffic. When the end of the currently simulated interval is reached, SUMO puts the
traffic values on the dump socket and waits until next “SimulateTo” is received.
Ideally, SUMO finishes the simulation before the end of the current interval in real
time. If this is the case, the simulation management component is able to do its work;
the synchronisation of the simulation with the reality is possible.
The SUMO output is collected and interpreted by the simulation management
component of ITS Austria West. If it disagrees with the latest real-time data received
from sensors, new calibration orders are generated accordingly.
More importantly, however, the output of SUMO can be used in the computation
of the traffic snapshots issued by ITS Austria West: For streets not monitored by ve-
hicle counters, or not described by floating car data – streets where the traffic situa-
tion is otherwise unknown – we can use traffic values obtained from the simulation.
The integration of simulation data into the traffic snapshots is optional and can be
turned on or off in the management console.

We described above the use of SUMO in a real-time scenario. It should be men-

tioned, however, that ITS Austria West allows working with a simulation tool in cali-
bration mode as well, where synchronisation with the real time is not necessary and
historical traffic data, for each currently simulated time interval, are used instead of
the latest traffic data. The purpose of running a simulation in calibration mode is to
obtain a calibrated demand model. Expectedly, the traffic situation obtained by run-
ning simulations with a calibrated demand model approximates better the situation on
the roads.

3.3 Parallelism

In order to work in a real environment, the simulation must perform considerably

faster than real-time. Several tests have shown that the rush hours, in Upper Austria,
cannot be in fact simulated by SUMO faster than real-time.
The most immediate way to speed things up is the parallelization of the software.
To achieve this goal, the existing SUMO single-threaded calculation model need to
be reengineered and converted into a multi-threaded model, where the new positions
of the cars are calculated in parallel.

We describe in the following our experiments for parallel SUMO and conclude
with a few results. It will become apparent that a profound reengineering is necessary
in order to obtain an efficient version of parallel SUMO.
All technical details refer to SUMO version 0.17. In newer versions, names of
some functions mentioned here may have been changed.

For the simulation of the traffic in a working day, routes were generated according
to statistical data received from official, governmental institutions. In Upper Austria
only, the total number of vehicles driving daily exceeds one million. As expected, the
highest density of vehicles occurs during the rush hours – 5 to 9, and 15 to 19 – when
more than 100 thousand vehicles are simultaneously on the roads.
When given as input to Sumo, these routes lead to an unsatisfactory simulation
speed of the traffic, starting from 6:00am simulated time. The efficiency of Sumo
decreases steadily, reaching levels where the simulated time runs slower than the real
time.
This fact challenged us to look for ways to parallelize the heavy work load. A
quick profiling showed the functions in which Sumo spends most of the time, during
an internal simulation step (see Fehler! Verweisquelle konnte nicht gefunden wer-
den.). Further investigations revealed that the function MSTL-
LogicControl::setTrafficLightSignals can be easily parallelized, but
for the other two relevant functions, MSEdgeControl::moveFirst and
MSEdgeControl::moveCritical , the parallelization is not trivial. Also, when
the number of routes starting in a small time interval is extremely high, the program
spends a significant amount of time in the function MSInsertionControl::
emitVehicles and therefore it also needs to be considered for parallelization.
Our first attempt at parallelization involved OpenMP and was a brute-force ap-
proach. Steps in highest-level ”for”-loops were executed in parallel; critical sections
were defined to forbid concurrent access to data structures, if these data structures
 MSNet::simulationStep()

MSEventControl::execute()
(myBeginOfTimestepEvents,
4%
myInsertionEvents,
myEndOfTimestepEvents)

MSEdgeControl::detectCollisions() 0%

MSTLLogicControl::setTrafficLightSignals(SUMOTime t) 21.6%

MSEdgeControl::patchActiveLanes() 0.05%

MSEdgeControl::moveCritical(SUMOTime t) 14.4%

MSEdgeControl::moveFirst(SUMOTime t) 37.2%

MSEdgeControl::changeLanes(SUMOTime t) 0%

MSRouteLoaderControl::loadNext(SUMOTime step) 1.34%

MSInsertionControl::emitVehicles(SUMOTime time) 2.48%

MSVehicleTransfer::checkInsertions(SUMOTime time) 0.0%

Fig. 5 The most important functions invoked in a simulation step, in SUMO.

were being modified from at least one thread. This approach, its shortcomings and
some results will be described in the next section.

All subsequent discussions refer to adapting and compiling SUMO within Mi-
crosoft Visual Studio 10, on Windows 7 platforms.

Using OpenMP in a Minimally-Invasive Parallelization

In our first approach, we used OpenMP directives to define code blocks executed
in parallel. Where concurrent access, especially in writing, was not desired, we de-
fined critical sections.
The OpenMP standard provided by the C++ compiler in Visual Studio 10 does not
allow parallelization of ”for”-loops where the loop variable is an STL iterator.
Since the main ”for”-loops in the three functions mentioned above are driven by
iterators over STL containers, some artificial constructs are needed in order to use the
OpenMP ”for” directive.
In fact, starting a parallel thread for each step of those for loops is not computa-
tionally efficient, due to the considerable overhead involved. We decided to split the
affected STL containers beforehand; each part is then processed in its own thread.
This simple strategy is clearly effective when the STL containers do not change af-
ter initialization – like the elements processed in function MSTLLogic-
Control::setTrafficLightSignals . Here, a number of iterator domains
are defined on the container with traffic light logics, as soon as the initialization of
this container ends. Using OpenMP ”for” directive, in MSTLLogic-
Control::setTrafficLightSignals , each iterator domain is processed in a
separate thread, in which a local iterator runs over the current domain.
The objects processed in the other two functions, MSEdgeControl::
moveFirst and MSEdgeControl::moveCritical , are active lanes, i.e.,
lanes which contain vehicles. Active lanes can be removed from this container in both
functions; lanes becoming active are added to the container in MSEdgeControl::
moveFirst . A splitting strategy similar to that described above would need a re-
computation of the iterator domains at the end of each of these two functions, and
would involve essentially a sequential traversal of the container.
We use an alternative strategy, namely an array of STL containers. Each element of
this array is processed in a separate thread, started by an OpenMP ” for” directive, in
both functions MSEdgeControl::moveFirst and MSEdgeControl::
moveCritical . Lanes which were not active, but in the current step contain vehi-
cles, are added after the parallel section of MSEdgeControl:: moveCritical
has finished; these new lanes are evenly distributed among the containers in the array.
Some internal data structures in classes MSVehicle , MSLane and MSLink are
accessed and modified from functions that may be running, at the same time, in dif-
ferent threads. Since STL containers are not multithreaded-safe, mechanisms must be
provided to avoid multiple access. The first idea was to use again OpenMP directives,
namely to define critical sections.
With an OpenMP ”critical ” directive, blocks of code are marked with a name
that identifies a critical section. If a thread gets hold of a marked block, any other
thread attempting to run a block marked with the same name must wait until the run-
ning block is freed.
We defined a set of critical sections to restrict the access to internal data structures
for vehicles, lanes and links.
This approach has two important shortcomings:
1. The critical sections restrict access to portions of code, rather than to shared
data. As a consequence, processing the vehicles on a street in Berlin, for ex-
ample, must wait until the same kind of processing finishes the vehicles on a
street in Leipzig, although they can – and should – be processed in parallel
without restrictions. In other words, the threads must wait for one another alt-
hough there may be no reason to do that.
 2. In every processing step (once every second simulation time) a number of
threads are generated – once in MSEdgeControl::moveFirst and once
in MSEdgeControl::moveCritical – and closed. While small, the in-
volved overhead is not negligible.
The alternative to critical sections is to define locks (by means of, e.g., mutexes) as
members of each instance of MSVehicle , MSLane and MSLink. Whenever a criti-
cal structure is being accessed, the lock shall be activated; at the end of the pro-
cessing, the lock shall be released.
The conceivable overhead for this alternative is not negligible, both in memory
consumption and computation effort. Our first experiments revealed that, indeed,
parallelization with locking objects defined for each element (lane, link, and vehicle)
is even slower than the sequential SUMO, and the memory consumption increases
drastically.

OpenMP Parallelization: Results

In our tests we used a version of the modified SUMO console application (version
0.16) adapted for 2, 4 and 8 threads: Two, four and respectively eight iterator domains
were defined for the traffic lights, arrays of containers with similar lengths for the
active lanes. We ran this version on a computer with four cores with hyperthreading at
3.4 GHz, and 8 Gb RAM.
For a moderately large network and set of vehicles, the best results were obtained
with the 4-thread parallel version. It finished the simulation in about 65% of the time
needed by the sequential version. This network was randomly generated, with 150000
edges. The 20 000 routes were also randomly generated; the maximum number of
vehicles simultaneously on the roads was around 3500.
For a large network (whole Upper Austria), after the first 25 000 seconds, the 4-
thread parallel version took only 57% from the time needed by the sequential version.
The maximum number of vehicles simultaneously on the roads was around 80 000;
more than 263 000 vehicles have been generated.
Parallel versions with two and eight threads proved to be less efficient. In the 2-
thread version, the overhead did not pay off: the gain in efficiency, for the parallelized
part, was too small. In the 8-thread version, the number of threads competing to exe-
cute critical sections led to prohibitively long waiting times.
Exact results, with the time spent by SUMO in each relevant function, are shown in
Table 1.

Alternative Approaches to Parallelization

The brute-force parallelization is inherently limited, if no additional information about
the network and/or vehicle routes is employed. Generating a number of threads in
each simulation steps, threads that afterwards compete to gain access to shared data
structures, cannot lead to efficient, scalable parallel versions of SUMO.
Table 1. Time spent by SUMO in the most relevant function, in a processing step.
Random network Upper Austria
(150 000 edges (180 000 edges,
20 000 route) 1 200 000 routes)
Sequential After 13600 steps and 182.661 seconds: After 25000 steps and 1128.699 seconds:
Timestep Events: 9.012 seconds Timestep Events: 13.493 seconds
setTrafficLightSignals: 35.213 seconds setTrafficLightSignals: 62.747 seconds
patchActiveLanes: 0.041 seconds patchActiveLanes: 0.128 seconds
moveCritical: 33.23 seconds moveCritical: 348.401 seconds
moveFirst: 39.986 seconds moveFirst: 426.741 seconds
changeLanes: 0.003 seconds changeLanes: 95.919 seconds
loadNext: 2.005 seconds loadNext: 17.874 seconds
emitVehicles: 2.148 seconds emitVehicles: 34.950 seconds
checkInsertion: 0.002 seconds checkInsertion: 20.176 seconds
Parallel (2 threads) After 13500 steps and 152 seconds: After 25000 steps and 820.784 seconds:
Timestep Events: 10.169 seconds Timestep Events: 14.775 seconds
setTrafficLightSignals: 29.004 seconds setTrafficLightSignals: 40.176 seconds
patchActiveLanes: 0.04 seconds patchActiveLanes: 0.126 seconds
moveCritical: 24.438 seconds moveCritical: 231.840 seconds
moveFirst: 30.979 seconds moveFirst: 257.587 seconds
changeLanes: 0.009 seconds changeLanes: 102.652 seconds
loadNext: 2.103 seconds loadNext: 18.569 seconds
emitVehicles: 2.322 seconds emitVehicles: 34.468 seconds
checkInsertion: 0.002 seconds checkInsertion: 22.728 seconds
Parallel (4 threads) After 13500 steps and 119.1 seconds: After 25000 steps and 649.733 seconds:
Timestep Events: 9.085 seconds Timestep Events: 13.687 seconds
setTrafficLightSignals: 21.673 seconds setTrafficLightSignals: 25.024 seconds
patchActiveLanes: 0.036 seconds patchActiveLanes: 0.113 seconds
moveCritical: 15.3 seconds moveCritical: 174.939 seconds
moveFirst: 18.19 seconds moveFirst: 173.349 seconds
changeLanes: 0.009 seconds changeLanes: 103.212 seconds
loadNext: 2.01 seconds loadNext: 18.653 seconds
emitVehicles: 2.249 seconds emitVehicles: 34.901 seconds
checkInsertion: 0.001 seconds checkInsertion: 23.766 seconds
Parallel (8 threads) After 13600 steps and 133.35 seconds: After 25000 steps and 798.479 seconds:
Timestep Events: 9.87 seconds Timestep Events: 15.934 seconds
setTrafficLightSignals: 26.465 seconds setTrafficLightSignals: 33.021 seconds
patchActiveLanes: 0.034 seconds patchActiveLanes: 0.129 seconds
moveCritical: 19.78 seconds moveCritical: 209.453 seconds
moveFirst: 26.96 seconds moveFirst: 236.049 seconds
changeLanes: 0.011 seconds changeLanes: 144.329 seconds
loadNext: 2.391 seconds loadNext: 23.945 seconds
emitVehicles: 2.951 seconds emitVehicles: 43.803 seconds
checkInsertion: 0.006 seconds checkInsertion: 30.203 seconds
 A more elaborate approach at parallelization should start by splitting the underly-
ing data structures using some topological criteria. From the original sets of roads,
junctions, traffic lights, etc., sub-networks should be defined. The number of connec-
tions between different sub-networks should be as small as possible.
The simulation should proceed on each sub-network in parallel, so that each thread
runs its own simulation loop. Synchronization points should be defined, in order to
keep fast threads from running ahead. Also, vehicles that jump over sub-network
boundaries should be processed in a sequential manner: It must be ensured that no
multiple accesses to the data structures affected in this processing step occur.

It is clear to us that this approach requires a significant re-engineering of SUMO,

starting with a design oriented towards parallelism. While the foreseeable effort is
considerable, we are confident that a fully parallel, scalable version would provide the
efficiency needed to simulate large-scale, real-life traffic situations.

4 Project Outcomes

Based on the information available during a simulation run, the level-of-service

(LoS) should be calculated. The term “level-of-service” has been defined differently
over the time. The origin of this definition comes from the transportation planning in
the U.S., where this notion was defined for the service quality of road infrastructure.
The traditional level-of-service is available in 6 categories, from A (for free ride) to F
(for gridlock). The details are set out in the Highway Capacity Manual [3]. In Europe
usually only the traffic-light colours are used (green: free travel, orange: slow-moving
traffic and red: traffic jam). Additionally, the colour Black can represent gridlocks.
In our case, the level-of-service is extracted from traffic information associated to
relevant edges: To every edge of the road network with a computed density of traffic
(either from real-time data or from SUMO), a level-of-service is assigned.
The image in Fig. 6 shows the LoS information generated from a SUMO instance,
without real-time data, using MapWindow (an open-source GIS) to display the rele-
vant data.
Eventually, a public web site shall exist where the information shall be provided by
means of web map service (WMS) layers, one for each LoS degree. A mobile app,
developed for a large range of mobile devices, will integrate the WMS and back-
ground (e.g. Google Maps, OpenStreetMaps) layers. Fig. 7 offers a preview of this
web site. The road works and roadblocks are also visible.
 Fig. 6 LoS mapping in an open-source GIS.

Fig. 7 Preview of the web page with WMS layers offering the LoS for Upper Austrian roads.
The background is obtained from OpenStreetMaps.
 5 Conclusions and future work

In this paper we described a system that employs SUMO as a core simulation sys-
tem for computing short-term traffic data starting from a given traffic situations and a
dynamically adjusted demand model. The traffic status at the end of the simulation is
adjusted with real-time data coming from networks of sensors and stands as basis for
the next short-term simulation.
For the street network of Upper Austria, and for real-life scenarios, the efficiency
of SUMO decreased below real-time. We described in section 3.3 our attempt at par-
allelizing SUMO. While imperfect and, in fact, not efficient enough, our parallel-
SUMO prototype showed that the multithreaded approach yields significant speed
improvements.
We described how SUMO is currently used in ITS Austria West, synchronized
with the real time; we intend to use SUMO for a short-term prognosis, in which the
next 30 minutes, or more, are simulated. This prognosis will be used to study the ef-
fect of various changes in the street network, coming from e.g. accidents, road works,
or different speed limits.
To improve the quality of the prognosis, the existing sensor network will be further
expanded, which should lead to a faster recognition of traffic disruptions. The gener-
ated real-time traffic condition is considered as a basis for a dynamic traffic infor-
mation system and adaptive traffic control systems on a long-term.

6 References

1. M. Behrisch and L. Bieker and J. Erdmann and D. Krajzewicz, SUMO - Simulation of Urban
MObility: An Overview, Barcelona, Spain, SIMUL 2011, 2011, 63-68
2. http://www.gip.gv.at (10. Jan. 2013)
3. Highway Capacity Manual, Transportation Research Board, National Research Council 3.
ed. 1985, 5. [updated], 1994.
4. http://www.opengeospatial.org/standards/wms
5. http://www.gip.gv.at/VAO-en.html

View publication stats