Throughout our analysis of the delay management problem in Chapters 2-5, we focused on the model where we assumed all delays to be known. The resulting problem already is NP-hard, even in very special cases. If, in contrast, delays occur strictly one after another and we assume that they are not known in advance, but we have to compute a new disposition timetable (based on the previous one) every time a new delay gets known, we are facing a classical online problem (see [Gat07] for an analysis of the online version of the uncapacitated delay management problem). In this case, there might exist input instances for which it is not the best approach to repeatedly compute optimal disposition timetables after the occurrence of each single source delay since other solution procedures might yield a smaller average delay. In [KS09], it is shown that in the case of uncapacitated delay management, there are some scenarios in which passenger-oriented heuristic dispatching strategies are superior to the approach of repeatedly solving the problem to optimality. However, as the limited capacity of the track system and thus the security distances between two trains and the resulting optimization potential is neglected, the results cannot be applied to the model treated in this work. Quite the contrary, our results in Section 4.3 show that the way of making the priority decisions has a large influence on the relative error and that this influence highly depends on the distribution of the source delays. It is up to now not clear which influence the priority decisions have in an online setting.
In Chapter 6, it turned out that computing a recoverable-robust timetable is a hard problem even if only a simplified nonperiodic timetabling model is considered. Many approaches on robust timetabling hence focus on special cases, for example on a single train as in [KDV07] or on heuristic approaches in the case of periodic timetabling as in [LS09]. Instead of theoretically analyzing robust timetabling, one could also take the approach to numerically compare the delay resistance of different timetables under simulated source delays and afterwards use that timetable that behaves best in average. Hence, in the next section, we present a programming framework that allows to numerically analyze the impact of different planning stages in public transportation on subsequent stages and on the operational phase. It is a joint research project that has been described in [SS09]. Parts of it are based on the results presented in this thesis.
7.3 Simulation and Numerical Evaluation with LinTim
To numerically analyze for example how delay resistant a timetable is, one could simulate different source delays and apply an optimal delay management strategy (or use the dispatching strategy that is intended to be used in practice) in each scenario. By doing so, the robustness of different timetables for common delay scenarios can be compared.
This kind of studies can be done quite comfortably using LinTim, a framework for planning in public transportation. In the following, we give a short overview of LinTim, especially of the parts which are related to this work. For a more detailled introduction, we refer to [SS09].
Overview of LinTim
The classical strategic planning steps in public transportation are network design, line planning, timetabling, vehicle scheduling, and crew scheduling. In the operational phase, delay management and crew re-scheduling are important tasks. Each of these planning steps and tasks on its own is well studied. However, the interaction between them is not understood so far.
Currently, integration of different planning steps in public transportation is an im-portant issue. Solving integrated problems is certainly harder than solving the single optimization problems of each planning phase separately. So the question arises if it is worth to deal with the large effort of integrating the problems or if it is sufficient to solve the problems separately step by step.
To answer this question theoretically is as hard as solving the integrated problems. It hence would be nice to be able to evaluate for example timetables not only regarding the classical cost objective, but also to evaluate the performance of different timetables when setting the vehicle schedules or with respect to delay management policies in the operational phase. LinTimis a software library which is capable to perform such evaluations.
LinTimis on the one hand a collection of different algorithms for single planning steps.
On the other hand, it provides tools that use the output of a preceding planning phase to create the input of the subsequent planning phase. This allows to evaluate different combinations of algorithms and to answer questions like
• From which line plans can we generate a good timetable?
• What is the impact of the lines on the vehicle schedules?
• How delay-resistant are different line concepts?
• Which timetables are suitable for generating good vehicle schedules?
• How delay-resistant are different timetables?
7.3 Simulation and Numerical Evaluation withLinTim
Structure of LinTim
We shortly sketch the workflow of LinTim. The starting point is a public transportation network (PTN) and information about the costs and the customers’ demand in this network. This input data is then used by line planning procedures. They output a line concept, i.e. a set of lines together with their frequencies. Currently, six different algorithms for line planning are integrated in LinTim. From this output, LinTim creates the input for the next planning step which is to find a timetable. The input required for timetabling is the periodic event-activity network with customers’ data on the activities. With this input, algorithms for timetabling can be run ending up with a timetable. The timetable allows to test different delay management policies.
In the design of the library, the main goal is that its usage and extension should be as simple as possible. This includes a modular design in which each planning step can be done separately and in which new algorithms and even new planning steps can be integrated easily. Furthermore, there are no regulations on programming languages since the communication between different steps is done through standardized plain-text data files. Running different parts of LinTimis controlled by shell scripts and makefiles or by a graphical user interface (see Figure 7.1).
Figure 7.1: Screenshot of theLinTimGUI.
Test cases
A data set is given by a PTN consisting of stations and direct connections between them. For each edge, we also need upper and lower bounds on the traveling time.
Furthermore, we require an origin-destination matrix, reflecting how many passengers travel between each pair of stations, and passenger weights on the edges (as some line planning algorithms require an origin-destination matrix, while other line planning algorithm can only use traffic loads on the edges as input). Finally, each dataset has to provide maximal and minimal frequencies for each edge where the minimal frequencies reflect the minimal required number of trains on an edge to serve the customers’ demand, while the maximal frequencies are needed to model capacity issues.
The test data which is available at the moment is the following:
• a hand-made example including 8 stations, 8 edges, 23 OD-pairs,
• a small real-world example with 250 stations, 326 edges, 31 000 OD-pairs, and
• a medium-size real-world example with 319 stations, 452 edges, 51 000 OD-pairs.
Evaluating a timetable’s robustness with LinTim
Given a (periodic) timetable, evaluating its robustness withLinTimworks as follows: As our delay management model requires an aperiodic event-activity network, the periodic event-activity network used for timetabling has to be transformed to an aperiodic one (it has to be “rolled out”). To this end, LinTim allows to define two points in time that describe the time interval that should be taken into account when rolling-out (for example all events that take place between 8 a.m. and 3 p.m.). Once these two points in time are given, rolling-out is straightforward: all (periodic) events and all (periodic) driving, waiting, and changing activities are duplicated according to their frequency and the length of the observation period. However, if two periodic eventsiandj are connected by a pair of periodic headway activities, then rolling-out is a little bit more complicated: each “rolled-out” copy of i and each “rolled-out” copy of j have to be connected by a pair of aperiodic headway activities, resulting in a multiplication of the number of headway activities, compared to other activities. A similar technique has been described in [LSS+10].
To evaluate the robustness, a test scenario providing source delays on events and/or on activities is needed. One possibility is to take real-world source delays if those are known for the input data of LinTim(for example if a real-world timetable and a set of delays that occurred during the operation of this timetable are given and the timetable should be compared with an alternative one, based on the same event-activity network).
7.3 Simulation and Numerical Evaluation withLinTim
Another possibility is to simulate delays. The current delay generator implemented in LinTim randomly chooses some events and/or activities and assigns a randomly chosen delay to them. The number of delays, the minimum and maximum amount of delay, and the type of delays (only on events, only on activities, or both on events and activities) can be chosen by the user as well as the period in which delays should occur (for example it is possible to take into account all events and all activities between 8 a.m. and 3 p.m. when “rolling out” the periodic timetable, but only to allow source delays to occur between 11 a.m. and 2 p.m.). Due to the modular design, other delay generators can be easily integrated, for example to simulate construction work in a station or on a track.
The solution procedures for the delay management problem that already have been implemented are:
• an exact solution procedure, solving the IP formulation (2.1)-(2.9) directly by invoking a commercial solver (FICO Xpress),
• theFsfs,Frfs,Frfs-Fix, andFsfs-Fix heuristics presented in Chapter 4.
Currently, we are working on integrating the remaining heuristics from Chapter 4 ( No-Wait-Repair,All-Wait-Repair, and Priority-Repair) as well as the reduction techniques presented in Chapter 3.
For evaluating a timetable under delays, apart from simply giving operating figures like the objective value of the delay management stage and the number of missed connections, LinTimhas a feature to visualize delays: for each station of the PTN, it sums up the delays of all events that take place in this station, then it plots the PTN and colorizes the nodes representing the stations according to the delays. An example for such a plot is given in Figure 7.2 (for the smallest test-data-set included inLinTim).
1
3 2
4
6
5 7
8
Figure 7.2: Visualizing delays withLinTim: Nodes are stations, the intensity of the color indicates the sum of all delays of all events within that station.