Even within the framework as described above, there is considerable flexibility in how to interpret the different pieces. One of these pieces is how to aggregate the link travel times: While the traffic simulation generates link entry and exit times for each individual vehicle, the router needs link traversal times as a function of link entry time. As pointed out above, these latter times also need to be aggregated in order to reduce computational overhead.
One issue is whether to use link entry or link exit times as the basis for aggregation. The way the router works, one would like the average travel time of all vehicles entering the links during a specific period of time. In terms of simulation logic, this is awkward since one needs to keep information about when the last vehicle belonging to such a batch has actually left the link.
This issue can be addressed by ``backdating'' (47), that is, one calculates the respective link entering times. For example, assume that the average link travel time for vehicles exiting between 9 and 9:15 is 10 min, and the average link travel time for vehicles exiting between 9:15 and 9:30 is 15 min. By backdating, one would arrive at the result that all vehicles entering between 8:50 and 9:05 need 10 min, and all vehicles entering between 9:00 and 9:15 need 15 min. This clearly leads to gaps and overlaps; piece-wise linear functions can be used to interpolate between the periods.
In our approach, we separate the aggregation from the micro-simulation. That is, the micro-simulation is asked to output event information every time a vehicle leaves a link. A post-processing step then aggregates this data into the information needed by the router.
For the post-processing, we use a pair of AWK scripts; AWK is a standard Unix tool (named for the initials of its authors) that parses line-oriented input files while it also is a fully programmable, C-like interpreted programming language. The first script reads the events file produced by the micro-simulation, filters the events that relate to vehicles entering and exiting links, and compiles them together into an intermediate file that lists, for each vehicle, the time it entered and exited each link on its route. The second script aggregates the output of the first script, to determine the average travel-time on the links.
We ran the above setup with the Gotthard scenario. In this section we present the results of that simulation.
For the following, we concentrate on an about 50 km 
100 km
section north of Lugano. For better exposition, the orientation of
the plots will be rotated by 90 degrees, so that Lugano now is to the
right and the Alps are to the left.
Fig. 1(c) shows snapshots of the situation at 19:00 and at
20:00. These and all other snapshots are after 49 feedback
iterations. In general, the vehicles are jammed up because there are
bottlenecks inside Lugano.
The implausible feature of these plots is that there are traffic jams on the side roads while the freeway is empty. Note that there is no en-route replanning, and so the plan-following vehicles are stuck with their plans for the whole duration of their trips.
The problem was caused by the fact that the router will not react ``fast enough'' if traffic is moving well at the beginning of the time bin, but not at its end. Cars that enter a link at the beginning of the time bin will leave sooner than the router expects, but those placed at the end of the time bin will leave later than expected.
As an example, suppose
that the router is considering routing two agents 
and 
on a
link 
during the time bin from 7:00 to 7:15. Suppose further that
is close to free-flowing at 7:00, but is congested
by 7:15. Also assume that its average travel-time during this time
bin is calculated to be five minutes.
If agent starts out on the link near the beginning of the time
bin, say 7:03, it has a clear ride and will be off the link after,
say, four minutes.
If agent starts out on the link closer to the end of the time bin,
say 7:10, it gets into that congestion and has a longer travel time,
say nine minutes. The result is that in the simulation agent will be
minute ahead of the router's schedule, while will be four minutes
behind schedule.
Overall, there are four cases:
As a first possible remedy, giving the router an ``early warning'' about impending congestion build up is considered. This is done by simply offsetting all the time bin data so that it is ahead of reality by one bin. This causes the router to use the 7:15-7:30 time bin information when it enters a link between 7:00 and 7:15. That way, it will instruct agents to avoid congested links before those links actually get congested. It will also place more vehicles on links that are undergoing transitions from congested to free-flowing at an earlier time. Based on the reasoning above, however, this situation should not cause too much of a problem. - It turns out that this alone is not sufficient: The system still allows the freeways to empty earlier than the side roads (not shown).
Another issue with the data used by the router is that it is an average of the travel times experienced by the vehicles. As stated above, if the router under-predicts the travel-time for an agent on a link during a time bin, that agent will be behind schedule. Instead of giving the router an early warning, we alter the router's view of the links so that it pays more attention to the travel times of those vehicles who experienced congestion on the links. In other words, we bias the link selection against congested links. The simplest way to do this is to take the maximum travel-time experienced on each link during each time bin, rather than the average. - Also this measure does not fix the problem: The freeway still empties earlier than the side roads (not shown).
Neither offsetting the travel times data, nor biasing it toward the maximum reported travel time make the results plausible. As a next test, a combination of the two was tried. That is, the system takes the maximum travel times instead of the averages, plus it offsets the resulting travel times data by one bin. Figure 1(d) shows the output from this result. As one can see, the side roads finally empty out before the freeway does, as is plausible.
After enough analysis, ``combining maximum travel-time and offset time bins'' finally solved the problem. One essentially had to greatly exaggerate the router's view of the links undergoing transition from free-flowing to congested regimes, so that it could react in time to move travelers away from those links to avoid the congestion. This solution was tailored for this specific problem, however. If there are other routing problems that we discover at a later time, we may have to adjust our travel time reporting strategy again. Such adjustments could conflict with the current method, bringing back the problem of empty freeways with congested side roads. For example, we never looked at routes for vehicles which are early within a time bin, the first of our four above cases. We would like a more robust solution, which can work even if flaws exist in the router or the feedback system.
In the next section we present an alternative solution to the maximum and/or offset strategies, which moves away from adjusting the travel times reporting, to adjusting the behavior of the travelers.