One aspect of any transportation simulation package needs to be the actual traffic dynamics. Ideally, one wants to have travelers walking to the vehicles, entering the bus or the car, then those vehicles drive through the traffic, stop at lights, obey speed limits, and make turns at intersections after getting into the necessary lane. This is the task of the traffic micro-simulation module.
One aspect of such a traffic simulation is that travelers need to know how they navigate through the system. When do they enter a bus, when do they make a turn, etc.? This task is typically solved by a routing module.
Any routing module needs as input the origin and the destination of the trip. Traditionally, one uses origin-destination matrices here - that is, tables which contain information about how many people travel between any pair of destinations in the region. A disadvantage of this method is that all information about the travelers themselves is lost at this level - and in consequence, decisions cannot be coupled to such information any more. For example, a person who arrives late at work because of congestion may skip lunch in order to catch up. An alternative method of demand generation for travel is called ``activity-based''. This method is closer to how individual humans think and plan - that is, for each individual in the simulation the module generates individual plans for activities.
It is not sufficient to run these three modules in sequence since, for example, plans depend on congestion but congestion depends on plans. In order to find a solution which is consistent between the modules, it is common to run feedback iterations, where the agents slowly adapt to the situations they encounter. - The next sections will describe the modules including feedback in more detail.
In order to generate the demand for transportation, many of today's projects are based on activities. That is, instead of using an abstract origin-destination matrix, they look into people's motivation to travel. This is achieved by having the simulation generate sequenced activities for the day, for example: Sleep until 7am. - Be at work at 9am. - Go to lunch at 12:30pm for one hour. - Leave work after 8 hours of work. - Go to the kindergarten to pick up a child. - Go shopping. - Go home and stay there for the rest of the day. These activities come with locations, that is, they generate demand for travel. Two successive activities which take place at two different locations will generate a trip request.
It is clear that one needs to have information about the network impedance (i.e. the travel times between different locations) when making activity plans. We will come back to this in the section about feedback and in the outlook.
Once the simulation ``knows'' where and when people do their activities, transportation is generated via connecting activities that take place at different locations. This includes modal choice (walking, bicycle, train, car, etc.) and the precise routing.
So far, we have generated ``plans'' of the individuals. The travelers in the simulation compute their plans for the following time period, which may for example be a day. Now these plans need to be executed, which is called the traffic micro-simulation. These simulations come at many different levels of resolution and fidelity, reaching from the traditional steady-state flow-based cost function to very detailed micro-simulations.
If one is interested in time-dependent results, as for example the queue build-up during the onset of rush periods, the simulation needs to be sufficiently realistic to contain such dynamics. Traditional flow-based cost functions are not able to realistically deal with such dynamical effects, at least not in a straightforward way. Thus, the right traffic simulation has to be chosen according to what aspects of the dynamics one wants to have represented for a given question. There are currently more than hundred traffic microsimulations [1]. However, in most of these travelers do not follow individual plans as was explained above. Examples of plan-following traffic simulations are TRANSIMS [2], DYNAMIT and MITSIM [3], DYNASMART [4], and LEGO [5]. In some of these, travelers do not ``know'' their full routes but only their destinations (and are routed via the simulation which knows the paths); the practical impact of this difference is not known.
The traffic simulation needs input from the demand generation, since it executes the plans from the demand generation. However, the demand generation depends on the traffic simulation because for example congestion only shows up in the traffic simulation, and demand adjusts to such shortages. In order to deal with this situation, one iterates between demand generation and traffic simulation. For example, the demand generation module is run assuming no congestion, the resulting traffic simulation is run, then the demand simulation is run again now including the congestion from the last traffic simulation run, etc., until a steady state is reached. That is, the system is systematically relaxed towards a consistent state.
An important issue in this context is the question of computational
efficiency versus behavioral realism. Traditional static equilibrium
assignment has, once the origin-destination matrix and the network
including link-cost function are specified, a unique solution (in
terms of the paths flows). This allows one to concentrate on the
fastest computational algorithm to find this solution. In iterated
transportation simulations, this issue is considerably more
complicated. Although such iterated simulations relax to some kind of
reproducible steady state, this state is stochastic. Also, it is not
clear if this state is unique or if it depends on the path of the
computation - in dynamic traffic assignment (DTA) computational
evidence indicates that it is
unique [6, 7] but once one includes other
aspects such as public transit or activities rescheduling it is easy
to construct scenarios where this is no longer true.
Another important aspect is that real systems may not be at this
relaxed state at all. In that case, transients matter much more,
which means that the rules of the synthetic travelers would have to
be much more realistic than for just reaching the relaxed state.
A metropolitan region easily consists of several millions of travelers. In order to get an idea of the necessary computing let us assume that we want to simulate a scenario of 24 hours ( 86400 secs) with 1 million travelers. Simulations typically do second-by second updates. In each update, several variables such as traveler speed or traveler location are computed. Let us assume that there are ten such variables, and the update of each variable needs 100 basic computer cycles. This is not a lot: For example, a simple algorithm for lane change will consider the following: Do I need to change lanes? Where are my neighbors? Is there enough space for me to change lanes? Also, fetching data from RAM typically takes about 10 cycles. A result of these assumptions is that, with a 1 GHz-CPU, the scenario takes
of computing time. Running 50 iterations thus will take 50 days of computing time on a single CPU. Using parallel computers will reduce this number accordingly; for example, using a so-called Beowulf of 50 Pentium PCs will lead to a computing time of between one and two days. See Refs. [9, 10] for more information.