Dynamics on a graph

A big difference between typical CA models and those used for transportation applications is that the latter typically operate on a graph. A graph consists of nodes and links. Nodes for transportation applications have ID-numbers and geographical coordinates. Links connect two nodes, and they have attributes such as speed limit or number of lanes. Obviously, nodes correspond to intersections and links to the roads connecting them.

Traffic on links can be represented through 2d arrays, with one dimension being the length and the other one being the number of lanes, and using the driving models from Sec. 2. The only addition is to include lane changes for plan following, which forms an additional incentive to change lanes as discussed in Sec. 2. The remaining parts of the driving logic concern themselves with intersections.

Intersections

An easy way to deal with intersections is to treat intersections as ``black boxes'' without internal dynamics. In this case, the prioritization is handled when vehicles are about to enter the intersection. There are two important cases: turning movements which are ``protected'' by traffic signals, and unprotected turns. These will be discuseed in the following.

Protected turns are straightforward, since the signal schedule is assumed to take care of possible conflicts. If vehicles can brake to zero speed in one time step (as is assumed in most CA models for traffic), then a yellow phase is not needed. The only other condition for a vehicle to move through an intersection is that there needs to be space on the outgoing link.

Unprotected turns (yield, stop, merging, etc.) are more advanced. In general, for each turning movement a list of conflicting lanes needs to be available, which is normally generated via pre-processing and is part of the network coding. A vehicle that wants to go through an intersection checks for each conflicting lane if there is a conflicting vehicle, and only if there is none and if in addition the outgoing link has space, then the vehicle can move.

The rules for conflicting lanes are normally treated in terms of gap acceptance, very similar to the safety criterion in lane changing. For example, one can demand that for each interfering lane, a conflicting vehicle needs to be at least $n \times v$ cells away, where $n$ is a small number, and $v$ is the speed of the conflicting vehicle. If the simulation has a time step of 1 sec, then $n$ corresponds to the time gap of the conflicting vehicle in seconds. In reality, this time gap is of the order of 5 sec; in CA-based simulations, we found that 3 sec yields more realistic dynamics.

Unexpected side effects and calibration/validation

Sometimes, an arbitrary rule, as plausible as it may be, can have unexpected side effects. For example, $g > n \times v$ means that with $v=0$ the gap still needs to be larger than or equal to one. In contrast, with $g \ge n \times v$ the turn will be accepted when the gap is zero and the conflicting vehicle is not moving. The resulting differences in fundamental diagrams (see Fig. 3) are enormous. The latter turns out to model ``zip-lock'' dynamics, which is in fact the desired behavior under congested conditions.

In protected turns during the green phase as well as for unprotected turns which have the priority (such as a freeway link connecting to another freeway link at the position of an off-ramp), care has to be taken that free traffic flows unobstructed through the connection. This means, for example, that for CA logic with $v_{max} > 1$, up to $v_{max}$ cells of the outgoing link need to be considered.

Care has also to be taken when different incoming links compete for space on the same outgoing link. Although in principle the prioritization given by traffic rules should take care of this, in practice such conflicts can rarely be completely avoided, for example because of small network coding errors. In order to have a robust implementation, it is thus desirable that vehicles reserve cells where they intend to go.

This can again lead to unexpected effects. For example, we noticed above that the condition $g \ge n \times v$ is very different from $g > n \times v$ under congested conditions. In TRANSIMS, however, it turns out that there is in fact no difference at all between the two rules. Why is that? The answer is that in TRANSIMS, vehicles with velocity zero on the main road reserve space on the outgoing link on the assumption that they might accelerate to speed one. In consequence, vehicles from the minor road cannot move to that same space, even if it turns out that the vehicle on the major road does not move after all.

In order to find out about such unexpected effects, driving logic should be systematically tested. In fact, there should be standardized test cases that each micro-simulation should do and which should be publicly available, e.g. on the internet. A minimum set of tests would consist of the fundamental diagrams for 1-lane, 2-lane, and 3-lane traffic (such as Fig. 2 right), and for all unprotected merging movements (such as Fig. 3). Such tests should be done with the production version of the code so that differences between the specification and the actual implementation could be detected. These tests should be available as an easy-to-configure run of the software package, and the results should be available on the Internet.

Figure 3: Different yield rules. LEFT: Vehicles accept turn if $g \ge 3 \, v$. RIGHT: Vehicles accept turn if $g > 3 \, v$. Note the large difference in the congested regime.

[width=0.4]ge3v-gz.eps[width=0.4]gt3v-gz.eps

The simplest version of the TRANSIMS driving logic consists in fact of the rules described above. Most discussed variations, such as different gap acceptance at unprotected turns, or different $p_{noise}$, can be changed by global parameters.

The ``roundabout'' solution

An elegant solution to many of these conflicts is the use of small roundabouts at intersections [22]. The advantage of roundabouts is that the high complexity of interfering lanes of standard intersections is decomposed into smaller sub-units, where in each sub-unit only the conflict between the roundabout and the incoming lane needs to be resolved.

Alternative implementation of graph dynamics

The above description assumes that a street network is given as a graph. It was already said that this yields realistic description at links, but may become problematic at nodes. The software package VISSIM [23] therefore dispenses with nodes and connects links via a second type of links, called connectors. Such connectors start somewhere on a link and end somewhere on a (usually different) link. There is no need that they start at beginnings or ends of links. Any vehicle which encounters an outgoing connector somewhere on the link can decide to go there, or to continue on the link. However, a vehicle need to select one of the connectors eventually, since there is nowhere to go once the vehicle reaches the end of the link.

Similarly, incoming traffic is modeled via connectors which end somewhere on the link, not necessarily at its beginning. There need to be rules which resolve conflicts between incoming vehicles and vehicles which are already on a link.

As a radically different approach, it is possible to dispense with the graph dynamics completely. The whole transportation system then is overlayed by a CA grid structure, and vehicles always move within cells. The typical artifacts with off-axis movement are compensated for by smoothing techniques. CITY-TRAFFIC [24] seems to be using this technology; we use a similar approach for the simulation of tourists hiking in the Alps [25].