As described above, the mobility simulation reads strategies/plans. These are descriptions of where travelers enter and leave the network, which turns travelers take at intersections, etc. For the transportation simulation, this means that travelers know where they are going, when they want to be there, and the route they want to take to get there. This kind of strategic knowledge is in stark contrast to, say, the simulation of ants in an ant-hill. It also makes the simulation design considerably more demanding, since the generation and handling of strategies is a whole problem of its own. Our own approach to this problem is to allow a distributed design, that is, mobility simulation and strategy generation should be separated as much as possible, and in fact we also intend to have more than one strategy generation module in the future. This is further discussed in Sec. 7.
Important strategy generation modules for the simulation of travelers are route choice, mode choice, activity time choice (which includes departure time choice), activity location choice, activity pattern choice, etc. All of these represent possible dimensions of decision-making of the traveler. For ITS applications, all of these may be of importance, since all of them can be changed in reaction to information and guidance measures.
Similarly, as becomes clear by looking at Fig. 1, traffic management strategies can (in principle) just be fed into the mobility simulation as well. That is, a group of traffic lights or a group of variable messages signs can follow a plan or strategy in the same way as a traveler can follow a plan.
Our own vision with respect to the simulation of these is a plug-and-play architecture, where strategic modules programmed by different groups can cooperate in one simulation system. The general idea is that the mobility simulation outputs events, which is information of the type ``(time, agent-id, event)''. Examples for events are ``traveler entered/left a link'', ``traveler arrived at/left activity location'', or ``sensor sensed a vehicle passing over it''. Strategy generation modules then read the events, extract those events that they are interested in, and generate plans in response.
An example of a strategic module is route generation. Travelers/vehicles need to compute the sequence of links (road segments) that they are taking through the network. A typical way to obtain such paths is to use a Dijkstra shortest path algorithm. This algorithm uses link travel times plus the starting and ending point of a trip, and generates as output the fastest path. It is relatively straightforward to make the costs (link travel times) time dependent, meaning that the algorithm can include the effect that congestion is time-dependent: Trips starting at one time of the day will encounter different delay patterns than trips starting at another time of the day. Link travel times are aggregated from the events fed back from the mobility simulation, for example into 15-min time bins, and the router finds the fastest route based on these time bins. Apart from relatively small and essential technical details, the implementation of such an algorithm is straightforward (e.g. 33). It is possible to include public transportation into the routing (5); in our current work, we look at car traffic only. Note that such a routing algorithm, with small variations, can both be used to compute a behavioral response of an agent, and routing guidance by a traffic management center.