The arguably best starting point for getting a clean concept of a multi-modal transportation simulation package is to recognize that all activities take place on the walking network. Even if the car is parked in the garage, people have to walk to it. As a result, the simulation needs to have a walking network, on which all activities are located, and which has transfer points to the other modes of transportation (Fig. 1).
In the actual implementation, the walking network may look similar to
the car network, and it may use the same nodes and links, but
conceptually it is a separate thing. The walking network does not
have to be connected; Fig. 2 shows an example of a
activity location which can only be reached via a freeway.
Abbildung 1: Conceptual representation of network layers
Abbildung 2: Conceptual representation of an activity location which
can only be reached via a freeway.
TRANSIMS activities files come with a specification of the desired mode how an activity should be reached. This specification is a mode string - a sequence of letters denoting the different modes. Examples for mode strings are:
It is possible to construct a search graph such that a generalized Dijkstra algorithm can be used to find a ``best'' multi-modal path through the network [11]. The construction assumes that the mode string is given, for example ``wbwbw'', where again ``w'' stands for walk and ``b'' stands for bus. This example would involve a route which uses two different bus lines.
The search graph for the algorithm is obtained as follows (see Fig. 3): For each additional entry in the mode string, a separate network layer is assumed. That is, for ``wbwbw'' we have, from bottom to top, first a walking layer, then a bus layer, then again a walking layer, etc. The layers are connected via the transfer links as was already discussed above. The main difference is that for the algorithm, network levels are replicated if they appear at more than one position in the mode string.
When consulting Fig. 3, it becomes clear that a path through the search graph can be found in an organized way via a Dijkstra algorithm: Assume that the starting location is on the left, and the traveler wants to reach a destination on the right. Since we have ``wbwbw'' as mode sequence given, the algorithm will construct five levels in exactly that sequence, as can be seen in the figure.
The Dijkstra algorithm will then start in the bottom left, and expand systematically in its usual way through the search graph. Transfer links are logically treated the same way as links for other modes, that is, they have a link travel time and possibly other attributes. In this way, the algorithm will deterministically find the fastest path through the expanded network, which will correspond to a path of the desired mode sequence. Note that it will be possible to stop the algorithm if the destination can be reached faster without changing bus lines. For further information, see Ref. [11].
The router also keeps track of car availability. It will plan car trips only with available cars (which are usually parked close to home), and it will make sure that the car is returned at the end of the day. In complicated situations (such as a different family member returning the car), it is however the microsimulation which will find errors and notify the selector to correct them. For example, the microsimulation will, during a 48h simulation, notice if a car was not returned the previous evening since it will not be available for the trip.
The above description is conceptual. For efficiency, the implementation does several simplifications and modifications:
Abbildung 3: Conceptual representation of product construction,
including one path.
As said above, the micro-simulation executes all plans simultaneously in a realistic representation of the traffic system, and it is here that interactions between travelers, for example causing jams or missed busses, are computed. As also said above, TRANSIMS, in its current implementation, assumes that all plans (including routes) are pre-calculated before the simulation starts.
In principle, the micro-simulation is just a good representation of reality. With respect to multi-modal travel, this means that again all travel of persons begins at an activities location, which is located on the walking network. If the travelers use additional modes besides walking, the simulation moves the travelers to, say, the bus stop or the parking lot, where they enter a car.
That means, for example, that traffic lights follow schedules or adaptive procedures as they do in reality, and drivers change lanes according to traffic conditions or in order to be in correct lanes for intended turns. It also means that the simulation logically moves the travelers from their starting locations (usually home) to the bus stop or the parking lot, then lets them enter their vehicles, etc.
A convenient feature of the design as it is described here is that the simulation can actually deal with multi-modal plans even if the corresponding mode of travel is not implemented in the micro-simulation. For example, walking may not explicitely be implemented. In such a case, the micro-simulation will just assume that the plan contains completely correct information, and execute that. For example, the plan may say that the traveler leaves home at time and arrives at the bus stop at time . If walking is not explicitely implemented, the micro-simulation will just assume that the travelers leaves home at and arrives at the bus stop at time . Conveniently, this works for arbitrary modes which are not implemented, so that the router does not have to take into account possible limitations of the micro-simulation, and also micro-simulations with different capabilities can run on the same set of plans. It should be clear that for such modes no interactions can be modeled. For example, when walking is not modeled, missing a train because of crowding at the subway station will not happen.
A different aspect of the multi-modal implementation is the actual representation of public transit schedules. In the TRANSIMS traffic micro-simulation, public transit service is generated the same way car traffic is generated, i.e. via drivers picking up their transit vehicle at the depot and following a prescribed route with prescribed stops, a prescribed schedule, and possibly prescribed procedures for the case of schedule deviations. This is similar to the modeling of a shared ride, where a driver in one car has to pick up one or several passengers and drop them off later. In that way, effects like the bunching of busses or schedule delays because of congestion will come out naturally. Also, buses have a capacity limit, possibly leaving passengers behind at the bus stops, and it is possible to make the loading/unloading times a function of the crowdedness. If the actual routes of drivers and transit vehicles are not available, then synthetic routes can be generated from the schedule. Such synthetic routes will however obviously not include certain effects of reality, as for example the effect that a vehicle which switches lines may not be available because of a delay.
Currently, TRANSIMS does not explicitely implement pedestrians; they are treated as any other non-implemented mode as described above. It should be clear that TRANSIMS could benefit from the addition of a realistic pedestrian mode, in particular in cities where pedestrian facilities suffer from congestion. It should also be clear that including pedestrian traffic into TRANSIMS would be relatively straightforward, and could be done via arbitrary models as long as they follow the same plans format. This, however, puts constraints on the pedestrian model design, namely that is has to follow the graph-oriented structure of TRANSIMS. In particular, it must be possible to define paths from one activity location to another, plus from activity locations to transfer points and vice versa. Agents need to be able to follow such paths, and the information must be structured in a way so that the router can work with it. This excludes, for example, random wandering across a wide plaza or through an old city where a person only approximately knows where he or she is. Future versions of TRANSIMS may eventually be extended in this regard. Also note that aspects of this can be included via putting delays on the transfer links.
No computational module will be able to anticipate everything which can happen in other modules. For example, strongly fluctuating congestion could lead to missing the train although according to mean travel times everything looks fine. Similarly, the shared ride may depart without me if I am too late, or the parking lot at the park-and-ride station may be full. In many cases, researchers may want to define non-optimal behavioral decision models for humans, which would exclude from the beginning that travelers take, say, the fastest path.
For all these elements, TRANSIMS provides its feedback mechanism (also called ``selector''). Instead of (computationally) dwelling forever on a decision between two different modes, or a range of possible starting times, the simulation can just decide ``to try it out''. For example, a transit and a car option can be tried by an individual, and the performance of both be evaluated. In that performance evaluation, aspects like the number of stop signs, or the predictability of the respective options can be taken into account. This allows both the modeling of non-optimizing behavioral models, and the inclusion of non-linear costs which cannot be picked up by Dijkstra-type routers (also see below). In the second case, an ``optimal'' solution probably cannot be guaranteed, but an individual improvement procedure can be implemented.
In many cases, this also solves the question of ``where to put'' certain decisions. For example, a mode choice decision could be made on the level of the router, via putting values of time and other things on different modes and then finding the optimal mode for the trip. It however also makes sense to look at this during the activities planning, since mode choice and activities chaining are intimately related. Via the feedback mechanism, neither of these modules has to make the decision alone - instead, in critical cases where several solutions are plausible, the selector will be able to make the individuals try out different solutions and then pick a good one according to heuristic (or optimizing) rules. Clearly, there is a tradeoff between modeling effort for the trip planning and the number of iterations one may have to run.