Part III
Robustness in Public Transport
8
Robustness Tests for Public Transport Planning
We learn from failure, not from success!
— Bram Stoker, Dracula [Sto97]
8.1 Introduction
One major challenge in public transport planning is establishing reliable services. Services can be fast and cheap, but reliability is also essential. When a passenger has to arrive before a deadline, he will choose another means of transport if the provided service is not reliable enough.
If other means of transport are not an option earlier services than theoretically necessary have to be chosen, thus spending more time to commute. In a survey from 2017, 41% of Germans, commuting by car stated that they would consider using public transport if only reliability were not so bad. In this survey, reliability ranked second after ticket-price outranking speed and a smaller number of interchanges [Sta17].
Public transport planners have a hard time improving the reliability of their services. In cities of the size of Karlsruhe (300k inhabitants) planners manually add buffer times to driving edges, that often encounter delays. This practice, however, is not compatible with high levels of optimization as done in the field of integrated line planning and timetabling (see Section 2.2).
Integrated line-planing and timetabling can improve the average traveling times of passengers and cost for the service provider significantly. The problem with these methods, however, is that they do not optimize their solution for robustness. Using the term robustness in the context of optimization, yet, can easily be confused with robust timetable optimization. The next section will focus on a clear differentiation between both terms.
The Term Robustness in Robust Timetable Optimization
There are several types of robustness to express defined aspects of a solution. Strict robustness, for example, is one of those robustness types introduced by Soyster in [LS73]. Under his definition, a timetable is strictly robust if the execution is feasible under all possible scenarios.
Timetables designed with this type of robustness typically have very long driving times due to extreme buffers. Liebchen et al. introduced a more practically oriented robustness type; the recoverable robustness [Lie+09]. Here changes in timetable (by delays or otherwise) are allowed as long as feasibility can be restored afterwards. Goerigk and Schöbel conclude in [GS10], that it is crucial for the application of these robustness concepts that the uncertainty set defining possible delays has to be known. As a consequence of the given definitions, the robustness
85
concept of a timetable can only be deduced with the uncertainty set used to construct the solution.
robust timetable optimization The creation of a timetable, that is able to recover the delays of vehicles according to defined requirements.
robustness The quality of a timetable, that delays introduced to vehicles have a low impact on the arrival delay of passengers measured in arrival delay or lost utility for all passengers.
The notion of robustness used in this research is an empiric measurement to compare different timetables rather than formal classification. Real-world scenarios do not follow all feasibility constraints many models enforce during computation. The breakdown of a vehicle alone at any point in time challenges those models. Then the execution of a schedule often is no longer possible.
We consider a timetable as robust if it can handle disturbances with little loss in quality of service (compared to alternatives). The field of improving the robustness of public transport has many aspects. In the next section, we set goals for the research done concerning robustness.
Goals of this research
In the context of FOR 2083, there has been a challenge to understand, create, and evaluate line plans and timetables for a given network. The most frequently studied of those networks was the grid-network shown in Figure 3.5. Several approaches were made manually creating and generating line plans and schedules. Computer scientists took a different approach. First they created solutions that were the fastest in terms of perceived journey time. Later they were also able to generate the solution with minimal cost, satisfying all constraints made to a solution for a schedule [PSS18]. They also created many sets of optimized solutions based on manually created line-plans as well as heuristically generated ones [Pät+17]. Several solutions had a good compromise between cost and perceived journey time outperforming manual solutions. There still were remaining questions. How reliable were these plans in terms of robustness? If reliability were measurable, can we create more robust schedules? Creating a schedule that is also robust, presents an entirely different challenge. This is because there is no formal definition of the term robustness, which is suitable for practical application. We suggest using a set of generic simulations containing common scenarios found in most public transport systems. After these simulations, the performance of each instance should be evaluated using passenger delays at their final destination, and several other indicators as robustness measurement. More specifically, these measurements should serve multiple purposes in the context of comparing different plans of the same infrastructure network.
• being suitable to replicate the expected shortcomings of a plan,
• highlight differences in the choice of the line network,
• observing trade-offs between robustness and travel times based on timetables whichLinTim optimized for the respective line plan,
86 Chapter 8 Robustness Tests for Public Transport Planning
• identifying the best methods for robust timetable creation.
In addition to these purposes, there are several other properties robustness test should have.
• The robustness tests shall apply to all possible line networks and corresponding timetables in public transport and for general demand patterns varying within a day.
• There should be multiple scenarios/test each potentially capturing different strengths and weaknesses of a given schedule.
• The tests support parametrization for changing delays.
• The tests should work under different assumptions for passenger behaviour.
There have been several works of research influencing this investigation. The next section will highlight the ones of most significant importance.
Related Work
The study of punctuality and its effect on passengers has always been of high importance. Reports often provide the percentage of services that arrive on time [Ver22]. Being on time, however, is defined as to arrive not later than within a given margin (e.g., 5 or 15 minutes for long-distance trains) of the planned arrival time. More recent publications often use metrics measuring the dissatisfaction of passengers. In a Dagstuhl seminar in 2016 [Dag16], Dennis Huisman coined the phrase “passenger punctuality 2.0” for measuring the (weighted) total passenger delay at the destination for all passengers. [Sch01; Sch06] uses the latter as well as [HGL08] and others. Less sophisticated indicators include the mere number of delayed departure and arrival events [Cic+09]. Alternatively, Acuna-Agost et al. [AA+11] propose to count every time unit of delay at every planned stop and the last stop. In the PANDA software framework used in Part II, dispatchers relied on viewing several KPIs measuring different aspects of passenger discomfort. Complex cost functions resulting in one numeric value for satisfaction/dissatisfaction have several advantages when comparing situations. The drawback is that they are hard to understand/interpret for operators and even for planners. Now we look at robust timetabling from an operator’s perspective.
In this setting, it is desirable that a timetable can absorb delays and recover quickly (thus avoiding penalties for the operator). To this end, inserting buffer times in the schedule may help to reduce the effect of disturbances, but may harm the realized travel times. Not only the total amount of buffer times but also their distribution along the lines is essential. These aspects have intensively been studied in operations research. For example, Kroon et al. [Kro+08] use stochastic optimization to allocate time supplements to make the timetable maximally robust against stochastic disturbances. They use the expected weighted delay of the trains as an indicator. Using mixed-integer linear programming, Sels et al. [Sel+16] improve punctuality for passenger trains in Belgium by minimizing the total passenger travel time as expected in practice. Be˜sinović et al. [Bes+16] optimized the trade-off between minimal travel times and maximal robustness using integer linear programming. Their formulation includes a measure for
8.1 Introduction 87
delay recovery computed by an integrated delay propagation model in a Monte Carlo setting. In these works, the line network is usually already fixed. Robustness of timetables was empirically investigated (concerning different robustness concepts) in [GS10]. [GSS13] studied the robustness of lines. [Sch12] provides a general survey of line planning in public transport. A recent integrated approach combines line planning and timetabling, but without considering robustness [Sch17].
Our work proposes to create a way of analyzing more than one aspect for a more robust public transport system. At least the issue of passenger satisfaction and features relevant for operation shall be contained and analyzed. To achieve our goal, we suggest the combination of integrated line-planning and timetabling, creating multiple instances. Subsequently, we run robustness tests evaluating every single instance. These robustness tests have been introduced by us during the work on [Fri+17b]. This chapter contains our methods and findings.
