PANDA: a software tool for improved train dispatching with focus on passenger flows
- 561 Downloads
We introduce the decision support tool PANDA (Passenger Aware Novel Dispatching Assistance). Our web-based tool is designed to provide train dispatchers with detailed real-time information about the current passenger flow and the multi-dimensional impact of waiting decisions in case of train delays. After presenting the algorithmic background and PANDA’s main features, we show how it can be utilized in a typical use case scenario for train dispatchers. Besides its practical value for train dispatchers, the framework can be used to systematically study scientific questions. Exemplarily, we use our software to experimentally analyse the influence of waiting decisions on realistic passenger flows of Deutsche Bahn. In a first experiment, we evaluate PANDA’s potential benefit for passengers. Our findings indicate that a remarkable reduction in total delay might be possible in comparison to current practice. In two additional experiments, we investigate the timing aspect of waiting decisions. Our observations suggest that the timing of waiting decisions is of crucial importance and that a carefully implemented early rerouting strategy has a significant potential to reduce resulting delays of passengers.
KeywordsDelays Decision support Passenger flows Rerouting of passengers Train dispatching Waiting decisions
In a fairly complex train traffic network like that of Germany, train disruptions and delays are inevitable. As a consequence, passengers may miss some planned transfer which results in significant delays at their destinations, in considerable dissatisfaction, and ultimately in economic loss for the railway company. To approach this problem, large railway companies like Deutsche Bahn employ train dispatchers who monitor delays and manually decide which trains shall wait for delayed incoming trains in order to maintain connections for passengers. Such waiting decisions induce further delays, and so train delay management becomes a highly complex optimization problem.
Unfortunately, only very limited information about current passenger flows is available for dispatchers. In today’s practice, dispatchers make isolated waiting decisions based on experience and local knowledge. The induced side-effects on future transfers are usually only vaguely known. This lack of information leads to the policy of resolving transfer conflicts relatively late, when information about the arrival time is reliable. As a drawback, many possibilities for reroutings of passengers are not taken into consideration. We here investigate to which extent an early detection of conflicting transfers and corresponding rerouting policies is beneficial, that is, may have the effect of reducing average delays. Our working hypothesis is that detailed information about passenger flows is the key to improved waiting decisions. In our setting, we make the assumption that travel routes of each passenger are available, an assumption which is realistic only to a limited extent. At the moment, the most realistic passenger flow available to us is based on statistically validated demand models. We expect, however, that trends like electronic ticketing will enable railway operators to work with high-quality passenger flows in the foreseeable future.
an overview of all transfers requiring attention from dispatchers,
detailed views on travel routes of all passenger groups who have planned to use a certain transfer,
information about the impact of waiting decisions gained from simulation,
evaluation of estimated arrival delays at the final destinations of all affected passenger groups, and
based on such an impact model on passengers, a qualified recommendation to wait or not to wait, and where applicable, how many minutes to wait.
Our software can also be used to analyse dispatching strategies. We analyse the effect of early rerouting on the passenger flow. Continuing previous work (Lemnian et al. 2014), we show that early rerouting is beneficial in a significant number of cases in comparison to the conservative strategy.
1.2 Related work
Train delay management is a well-studied field. We refer to Schachtebeck and Schöbel (2010), Kanai et al. (2011), and Dollevoet et al. (2012) for some recent work. Early delay management approaches simply assume that passengers who miss a connection wait for the next connection on the same line (for example, Schöbel 2006). Integrated passenger rerouting has been studied by Dollevoet et al. (2012), Dollevoet and Huisman (2014), and Kanai et al. (2011). Most of these approaches use integer linear programming (ILP) models and consider offline versions, where all delays are known before the optimization process starts. The integration of passenger rerouting into an ILP formulation leads to a considerable blow up, making these formulations so large for train networks like that of Germany with millions of passengers that they cannot be handled by standard integer programming techniques. In particular, solving such problems in an online setting seems to be out of reach without significant progress in solution techniques. Dollevoet and Huisman (2014) compare slow exact ILP solutions with a couple of fast heuristics. They introduce an iterative ILP approach which comes close to the exact solution but is significantly faster. However, it is not known whether the iterative ILP approach scales well to large-scale networks. Kliewer and Suhl (2011) evaluate several simple dispatching rules in an online scenario, but work with randomly generated delay scenarios and randomly generated passenger flows while we use observed delays and more realistic passenger flows. Moreover, they work only with a subfleet of interregional trains from the Frankfurt area. Bauer and Schöbel (2014) also consider various online strategies. They introduce a learning strategy based on simulations with many delay scenarios and report promising result with this strategy in experiments on artificial schedules and generated delay data.
The most important conceptual difference with our work, however, is that all mentioned previous papers do not explore the question when to decide. Corman and Meng (2015) point out in a recent review paper “while online static rescheduling has reached a wide degree of dissemination, much is still to be done with regard to the probabilistic nature of the railway traffic rescheduling problems; and how to best take uncertainty into account for future states.”
Another line of research considers larger disruptions where part of the infrastructure is temporarily unavailable. Passenger-oriented management strategies for major disruptions have recently been proposed by Kroon et al. (2015) and Veelenturf et al. (2014).
2 Passenger-aware dispatching
The current practice in dispatching is to apply standard waiting time rules of the railway operators, which provide a pre-defined threshold for each transfer. If the delay of the feeding train is smaller or equal than this threshold, then the implied dispatching decision is that the connecting train must wait. If the threshold is slightly exceeded, then dispatchers may decide to maintain a specific connection. Especially in these cases PANDA supports the dispatcher in their decision making process. To do so, PANDA needs an accurate representation of the current state of the railway network and the passenger flow.
safe, meaning that the transfer will probably be maintained;
uncertain, meaning that the transfer is uncertain but likely to hold. In this case, the feeder train is slightly delayed but by applying standard waiting time rules the transfer will be maintained;
critical, meaning that the transfer will not hold but can be maintained by waiting just a few minutes;
broken, meaning that the transfer will definitely not be maintained unless an exceptional waiting decision is taken.
After the waiting decision is evaluated a roll back of all changes is performed to prepare the simulation of the non-waiting decision. In this simulation no artificial delay is injected to maintain the transfer. Instead PANDA calculates the best alternative route for each passenger group that wanted to use this transfer. After this step PANDA checks the feasibility of the current routes of all the remaining groups in the set of affected groups. All groups that use an infeasible route need to be rerouted. This rerouting step is necessary for two reasons: first, to leave the passenger flow in a consistent state and second, to make the results of both simulations comparable. Finally, PANDA calculates the values of the evaluation criteria for all affected groups of this alternative and displays the results to the dispatcher.
The time to execute a single simulation scales with the number of passenger groups for which alternative routes have to be calculated. Given state-of-the-art implementations of the corresponding routing queries, this can be done within a few seconds. Since these computations are independent and therefore can be done in parallel, they do not provide a bottleneck. This may change in the future when more sophisticated optimization techniques are integrated into the backend. The more time-consuming task for the dispatcher is to analyse and to interpret the complex result data which PANDA provides.
3 PANDA: a webtool supporting train dispatchers
PANDA is a web-based visualization software for realtime passenger flow information. It consists of a C++ backend, which models the event-activity network and performs all simulations, and a frontend for displaying the information to the dispatcher which is based on the web programming framework Ruby on Rails. Next, we will focus on the description of the web-frontend.
3.1 Main view
3.2 Section view
3.3 Transfer view
3.4 Evaluation view
4 A typical use case for dispatchers
It is 05:02 p.m. The dispatcher observes the main view (Fig. 2) and notices a critical delay (orange marker) at Munich Central Station (München Hbf) which he hasn’t noticed before. The dispatcher wants to get additional information about this transfer and clicks on the corresponding marker.
The dispatcher is redirected to the transfer view (Fig. 4) where he gets information about the situation at Munich Central and in particular about critical transfers. He notices from the station matrix, that there are two critical (orange) transfers at this station within the next minutes. (S 6989 \(\Rightarrow \) ICE 526, and EC 216 \(\Rightarrow \) ICE 526, affecting 14, resp. 29 passengers). Further information about the latter transfer is also displayed. The dispatcher notices that the feeding train (EC 216) has a delay of 2 min. Due to a necessary transfer time of 7 min, the transfer is classified as critical. He has to decide whether the connecting train (ICE 526) should wait two additional minutes for transferring passengers. Such a decision would result in an additional delay of 2 min for 330 passengers, who are already sitting in ICE 526, in favour of 29 transferring passengers. To support the dispatcher in making a decision, PANDA offers the possibility to simulate both alternatives. The dispatcher clicks at the “Simulate Waiting Decision” button and, after a few seconds, is redirected to the evaluation view.
The results of the simulation are displayed in the evaluation view (Fig. 5). In this case, several criteria indicate that waiting for transferring passengers has a positive effect on the passenger flow. In particular, in the waiting scenario there are no passengers with a final delay of 2 h or more, while there are two passengers with such a large delay in the other case. In the displayed example, the evaluation criteria here clearly suggest to wait for transferring passengers. With the help of PANDA, the dispatcher can substantiate his passenger-friendly decision by arguments based on quantitative measures of several objective functions.
5 Case study: PANDA’s potential benefit
To analyse the potential benefits of PANDA, we wanted to estimate the effect of PANDA’s recommendations on the passenger flow. Therefore, we conducted an experiment in which we simulated and analysed several thousands of independent decisions. Here, we assume that all of PANDA’s recommendations are realizable in practice. Thereby, we ignore problems of practical feasibility, for example due to track capacities.
5.1 Experimental setup
We use the German train schedule of 2015 (with about 66,000 trains and about 280,000 transfers used by passengers per day) and realistic passenger flow information provided by Deutsche Bahn, consisting of about 3.3 million passengers on 320,000 different routes on each day. For our evaluation we used recorded data for actual delays of 10 days in June and October 2015.
For each critical transfer on our test days, we simulated a waiting decision based on the delay situation as known 15 min before the connecting train was scheduled to depart. We measured the effect of each decision on the passenger flow and compare the results with the status quo. For the latter we used the realized event times. It may well happen that the delay situation changes in the last 15 min between the decision and its actual execution so that the decision would have been different with full knowledge of future delays.
Data about 154,000 critical cases were gathered this way. These cases also include transfers, which are not regarded in practice because of train-category priority rules. For instance, a dispatcher does not consider to delay a connecting subway train in order to keep the transfer from a delayed Intercity-Express train. After filtering out all such cases, an overall number of 106,000 critical transfers remained.
On each day, realized departure and arrival event times were available with a resolution of 1 min. However, we did not have explicit information whether a transfer has been maintained by an active dispatching decision or not. Therefore, we tried to infer a posteriori, based on the realized time stamps, for each critical transfer whether it had been dispatched or not. Given the actual departure time dep(ct) of a connecting train ct, the actual arrival time \(arr( ft )\) of a feeding train \( ft \), and the minimum transfer time mintt required to change from the feeding to the connecting train, the buffer time\( buf \) for a transfer can be calculated as \( buf = dep(ct) - arr( ft ) - mintt\). Since the recorded data available to us does not contain the information which transfers have been actually maintained, but we would like to compare the number of (actively) maintained connection in the status quo and by PANDA, a formal notion is required which can be computed from available data. Therefore, we counted a train as dispatched for a particular transfer if (1) it has departed at least 2 min later than possible (or in other words: if it has gathered a new delay at the departure event of at least 2 min) and the available buffer time satisfies \(-1 \le buf \)1 or (2) if its real departure time was at most 1 min earlier than calculated by PANDA for the waiting scenario.
To reduce potential misclassifications, we considered in our final evaluation only those transfers where—with respect to the time stamps 15 min before the scheduled departure of the connecting train—the departing train had to be delayed by at least 3 min to keep the transfer. After this filtering step, about 64,000 cases remained.
Comparison of PANDA’s recommendation with status quo
Average # of passengers per day
to \(< x\) min
to \(\ge x\) min
Under our assumptions, 28.2% of all critical connections are kept by dispatching. In comparison, PANDA recommends to wait for 31.8% of these cases. Table 1 gives the average absolute numbers of passengers per day which benefit from PANDA’s recommendations, while Fig. 6 shows the relative benefit of using PANDA’s recommendations in comparison with what has been executed in practice. For all measures, we observe a significant potential to reduce passenger delays by using recommendations given by PANDA. The strongest relative reduction can be obtained for the group of passengers which would suffer from delays by 120 or more minutes. The number of passengers in this group could be reduced by about 50%, if PANDA’s recommendations would be realized (see again Table 1 for the absolute numbers of passengers affected per average day). The total sum of delay minutes could be reduced by about 24%. Recall, however, that not all recommendations are realizable due to other constraints.
Comparison of PANDA’s recommendation with status quo
6 Case study: benefits of early rerouting
As mentioned before, the current policy of train dispatchers is to decide as late as possible. Typically a waiting decision is taken about 15 min (or even less) before a transfer takes place. The rationale behind this policy is that predictions about event times become more robust over time. Our working hypothesis is, however, that earlier detection of broken transfers and immediate rerouting leads to a smaller delay for most passengers, because more alternative routes are available. We conduct an experiment investigating this hypothesis, asking the question “What is the benefit of an early rerouting strategy for the passengers?”
We use the German train schedule of 2015 and realistic passenger flow information provided by Deutsche Bahn, consisting of about 3.3 million passenger routes. In our experiments we compare three strategies for rerouting: immediate rerouting after detection of some broken transfer, waiting with the rerouting until 15 min before the transfer would have taken place (which we call 15-min-in-advance strategy) and a hybrid strategy (Experiment C). Exemplarily, we display the results of the test day June 24, 2015.
6.1 Experiment A
We select the 1000 most used transfers on several test days in 2015. One after another, we artificially delay the feeder train by a large amount of time (for example, due to some malfunction of a train), enforcing a break of the chosen transfer and a rerouting of all those passengers who planned to use this transfer. These specific delays are assumed to be known 3 h in advance. This set-up allows us to compare immediate rerouting and the 15-min-in-advance strategy in isolation, that is, without any disturbing side effects resulting from complex changes in the delay scenario.
6.2 Experiment B
As expected, we observe a mixed picture for the real-life Experiment B where the delay scenario changes over time. Now both strategies have winners and losers. The immediate rerouting strategy produces more than twice as many winners as losers. The heatmap in Fig. 8 shows that many more cases lie above the diagonal than below. A point above the diagonal means that the final delay of the corresponding passenger is higher with the 15-min-in-advance strategy than with the immediate rerouting strategy. Likewise, we consider the difference of the arrival times of both strategies (precisely, we take the arrival time of the 15-min-in-advance strategy minus the arrival time of the immediate rerouting strategy). Hence, if the difference is positive, this indicates an advantage for the immediate rerouting strategy. The right part of Fig. 8 shows the distribution of winners and losers. It has to be noted that for most rerouted passengers (namely for 88.4%) the strategy has no effect. Among the remaining passengers immediate rerouting has an advantage for 896 passengers (68.5%), whereas 411 passengers (31.5%) are better off with the 15-min-in-advance strategy. For those passengers where the choice of the strategy has an impact, the mean difference (that is, the mean reduction of the final delay) is about 14.7 min in favour of immediate rerouting. We conclude that the immediate rerouting strategy is beneficial from the perspective of an average passenger, but can also worsen matters for a non-negligible fraction of passengers.
6.2.1 Hybrid strategy: refined early rerouting
Motivated by the observed mixed picture in Experiment B we developed a third rerouting strategy. In that, we determine alternative routes as soon as we detect that a transfer might break. But in contrast to the immediate rerouting strategy, we wait with our recommendation as long as possible. More precisely, we compare the best available alternative with the currently used route and determine the first moment in time where the two routes differ. This gives us the latest moment where a passenger group could switch to that particular alternative. A few minutes before this moment we reconsider the current delay status. Since the first moment when we classified that the transfer might break, the delay situation may have changed. For example, the connecting train of the originally planned transfer also catches a delay so that our classification of it as being not maintained becomes obsolete. If we still predict the transfer to break, we perform a second search for an alternative route. We only reroute to the previously considered alternative route if the transfer is classified to break and if also the alternative is still feasible (it might be that meanwhile also the alternative route faces some previously unknown delay). By doing so, this refined strategy tends to avoid unnecessary reroutings of passengers.
6.3 Experiment C
We used the same experimental setup as in Experiment B, but this time we focus on the comparison of the immediate rerouting strategy with the hybrid strategy.
7 Conclusions and future work
We presented the PANDA train dispatching software, a webtool designed to support train dispatchers by visualizing detailed real-time information about the passenger flow and the impact of waiting decisions. We conclude from our experiments that PANDA has a high potential to reduce the delay of passengers. However, in practice, dispatching decisions can not always be realized due to the layout and occupancy of tracks or other operational constraints. Nevertheless, we feel confident that PANDA is a valuable help for dispatchers. Additionally, the software has already been successfully tested within a field test with dispatchers.
We used PANDA to experimentally investigate the question whether early (immediate or hybrid) rerouting has a positive effect on the delay of passengers and found, that this is true in many cases. On average, such a strategy is beneficial and the hybrid strategy performs best.
However, the experiment with real data also shows that a non-negligible number of passengers may suffer from a higher final delay. As the occurrence of delays and disruptions is unforeseeable, there is clearly no perfect strategy which is optimal for all individual passengers. Further research is required to reduce the number of cases where the timing of rerouting decisions later turns out to be suboptimal.
In future, we want to conduct further analysis of dispatching strategies to support dispatchers by timing suggestions. A major future topic is the full optimization of waiting decisions. At the moment, we just simulate single waiting-or-non-waiting decisions subject to applying standard waiting time rules for all other transfers.
Here, we relax the more natural condition of a non-negative buffer time slightly to reflect our observations in current practice. Dispatchers often calculate with a slightly shorter minimum transfer time than given in their “book of rules”.
The authors acknowledge partial support by Grant MU 1482/7-1 within the DFG research group FOR 2083 Integrated Planning in Public Transport and by Deutsche Bahn.
- Berger A, Blaar C, Gebhardt A, Müller-Hannemann M, Schnee M (2011) Passenger flow-oriented train disposition. In: Demetrescu C, Halldórsson MM (eds) Proceedings of the 19th annual European symposium on algorithms (ESA), Lecture notes in computer science, vol 6942. Springer, pp 227–238Google Scholar
- Lemnian M, Rückert R, Rechner S, Blendinger C, Müller-Hannemann M (2014) Timing of train disposition: Towards early passenger rerouting in case of delays. In: Funke S, Mihalák M (eds) 14th workshop on algorithmic approaches for transportation modelling, optimization, and systems, ATMOS 2014, OASICS, vol 42. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, pp 122–137Google Scholar
- Schöbel A (2006) Customer-oriented optimization in public transportation. Springer, BerlinGoogle Scholar
- Veelenturf LP, Kroon LG, Maróti G (2014) Passenger oriented railway disruption management by adapting timetables and rolling stock schedules. In: 10th international conference of the practice and theory of automated timetabling (PATAT 2014), pp 11–34Google Scholar
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.