Chapter 3. Traffic Simulations and SUMO

3.1. A short Introduction to Traffic Simulation Theory

3.1.1. Simulation types

SUMO is a microscopic, space continuous and time discrete traffic simulation.

In traffic research four classes of traffic flow models are distinguished according to the level of detail of the simulation. In macroscopic models traffic flow is the basic entity. Microscopic models simulate the movement of every single vehicle on the street, mostly assuming that the behaviour of the vehicle depends on both, the vehicle's physical abilities to move and the driver's controlling behaviour (see [Chowdhury, Santen, Schadschneider, 2000]). Within SUMO, the microscopic model developed by Stefan Krauß is used (see [Krauss1998_1], [Krauss1998_2]), extended by some further assumptions (see !!!). Mesoscopic simulations are located at the boundary between microscopic and macroscopic simulations. Herein, vehicle movement is mostly simulated using queue approaches and single vehicles are moved between such queues. Sub-microscopic models regard single vehicles like microscopic but extend them by dividing them into further substructures, which describe the engine's rotation speed in relation to the vehicle's speed or the driver's preferred gear switching actions, for instance. This allows more detailed computations compared to simple microscopic simulations. However, sub-microscopic models require longer computation times. This restrains the size of the networks to be simulated.

Figure 3.1. The different simulation granularities; from left to right: macroscopic, microscopic, sub-microscopic (within the circle: mesoscopic)

The different simulation granularities; from left to right: macroscopic, microscopic, sub-microscopic (within the circle: mesoscopic)

Within a space-continuous simulation each vehicle has a certain position described by a floating-point number. In contrast, space-discrete simulations are a special kind of cellular automata. They use to divide streets into cells and vehicles driving on the simulated streets "jump" from one cell to another.

Figure 3.2. The difference between a space-continuous (top) and a space-discrete (bottom) simulation

The difference between a space-continuous (top) and a space-discrete (bottom) simulation

Almost every simulation package uses an own model for vehicle movement. Almost all models are so-called "car-following-models": the behaviour of the driver is herein meant to be dependent on his distance to the vehicle in front of him and of this leading vehicle's speed. Although SUMO is meant to be a test bed for such vehicle models, only one is implemented by now, an extension to the one developed by Stefan Krauß (see !!! for furhter details). Other obstacles, such as traffic lights, are of course considered herein, too.

It seems obvious, that each driver is trying to use to shortest path through the network. But when all are trying to do this, some of the roads - mainly the arterial roads - would get congested reducing the benefit of using them. Solutions for this problem are known to traffic research as dynamic user assignment. For solving this, several approaches are available and SUMO uses the dynamic user assignment approach developed by Christian Gawron (see [Gawron1998_1]).

3.1.2. Needed Data

At first, you need the network the traffic to simulate takes place on. As SUMO is meant to work with large networks, we mainly concentrated our work on importing networks and the computation of further needed values. Due to this, no graphical editor for networks is available, yet. Beside information about a network's roads, information about traffic lights is needed.

Further, you need information about the traffic demand. While most traffic simulation use a statistical distribution which is laid over the network, each vehicle within SUMO knows its route. Within this approach, the route is a list of edges to pass. Although this approach is more realistic, it also induces a large amount of data needed to describe the vehicle movements. By now, routes are not compressed within SUMO and so may be several MB large. We will possibly change this in future.

3.2. The Workflow of Preparing a Simulation

As shortly described above, you basically have to perform the following steps in order to make your simulation run:

  1. Build your network

    Use either own descriptions (described in chapter 4, "Building Networks from own XML-descriptions") or if you have some digital networks SUMO can import, convert them (described in chapter 4, "Converting other Input Data")

  2. Build the demand

    Build your own movements using either by a) describing explicit vehicle routes (see chapter 5, "Using Trip Definitions"), b) using flows and turning percentages only (see chapter 5, "Using the Junction Turning Ratio - Router"), c) generating random routes (see chapter 5, "Generating random Routes"), d) importing OD-matrices (see chapter "Using OD2TRIPS" or "Using Flow Definitions"), or e) importing routes you own (see chapter 5, "Importing Routes").

  3. If needed, compute the dynamic user assignment (described in chapter 5, "Dynamic User Assignment")

  4. Perform the simulation (described in chapter 6, "Performing the Simulation") to get your desired output

This process is also visualised within the next figure.

Figure 3.3. Process of simulation with SUMO; (rounded: definite data types; boxes: applications; octagons: abstract data types)

Process of simulation with SUMO; (rounded: definite data types; boxes: applications; octagons: abstract data types)

Please remark, that most of the tools are command-line tools by now. They do nothing if you just double-click them (besides printing errors). Do also notice, that the call parameter desribed in the following chapters may be also stored in so-called "configuration files" to allow their reuse. This possibility is described in chapter "Using Configuration Files".

3.3. SUMO

3.3.1. Main Software Paradigms

Two basic design goals are approached: the software shall be fast and it shall be portable. Due to this, the very first versions were developed to be run from the command line only - no graphical interface was supplied at first and all parameter had to be inserted by hand. This should increase the execution speed by leaving off slow visualisation. Also, due to these goals, the software was split into several parts. Each of them has a certain purpose and must be run individually. This is something that makes SUMO different to other simulation packages where the dynamical user assignment is made within the simulation itself, not via an external application like here. This split allows an easier extension of each of the applications within the package because each is smaller than a monolithic application doing everything. Also, it also allows the usage of faster data structures, each adjusted to the current purpose, instead of using complicated and ballast-loaded ones. Still, this makes the usage of SUMO a little bit uncomfortable in comparison to other simulation packages. As there are still other things to do, we are not thinking of a redesign towards an integrated approach by now.


last change: Wednesday, 30-May-2007 02:13:49 PDT