DITTO Project Deliverable 3.3 Milestone 11

Optimisation at the Network Level and the Interface between Optimisation and Dynamic Simulation

Attila A. KovacsTolga BektasChris N. PottsJohn ArmstrongUniversity of Southampton, April 2017.Version 2 edited by John Preston, June 2017.

AbstractDeliverable 2.3, titled Stochastic Optimisation, was concerned with increasing capacity utilisation for a small area of the rail network around Peterborough station, the results of which suggested that a number of new services could be added to the existing timetable. The present deliverable examines the implications of the previous set of findings on a wider area of the network, in particular the possible knock-on effects on other stations surrounding Peterborough, and describes the computational challenges faced. The deliverable also presents additional results on the number of new services that can be inserted within the wider network. The findings suggest that the network around Peterborough is well utilised and that this station does not necessarily seem to constitute a bottleneck in the network. The findings also indicate that no more than three additional services could be inserted into the reference timetable between Alexandra Palace and Grantham. Finally, a maximum of five additional services between Peterborough and Grantham, and another five between Peterborough

1

and Alexandra Palace could be inserted into the timetable.

2

1. IntroductionThe aim of this deliverable to is examine the capacity utilisation of a wider area of the network as compared to what was studied in Deliverable 2.3 titled Stochastic Optimisation (Kovacs et al., 2016). Previously, we assumed that delays are mainly propagated from large stations. This assumption enabled us to focus only on Peterborough and others within close proximity. The results of the study indicate that there seems to be plenty of gaps within the timetable for additional services to be inserted. The question remains, however, as to whether this additional use of capacity would result in conflicts outside of the Peterborough area.

The present deliverable investigates this very question and concerns the modelling of a larger section of the British rail network. This, however, comes at the cost of needing to ignore delay considerations as the scale of the larger network tested here in combination with stochastic delays exceeds the capabilities of the computational resources, even with access to a super-computer. In the remainder of this report, we present different approaches that have been investigated to solve the large-scale timetabling problem. In its classical form, the technique originally mentioned in the project proposal, i.e., multi-commodity network flow design, turned out to be intractable for modelling operational constraints such as the existence of parallel tracks and the non-overtaking constraint for trains travelling along the same track. To overcome these limitations, a deterministic job-shop model is used in conjunction with the large neighbourhood search algorithm (LNS) described earlier in Deliverable 2.3. This network optimisation will then be used to identify additional train services that may operate on the East Coast Main Line between Doncaster and Alexandra Palace. In future deliverables, these additional services will be assessed using the TrackULA dynamic simulation tool that has been developed in DITTO, thus developing an interface between our optimisation and simulation tools.

2. Solution ApproachesWe have tested three different approaches to solve the train-timetabling problem, each of which is described in the rest of this section.

Multi-commodity network designThe multi commodity network design approach has been suggested in the project proposal as it has also been used in the pre-cursor OCCASION project to verify the feasibility of a smaller-scale timetable on a wider network. The idea is to use a time-expanded network where

3

each node in the railway network (e.g., corresponding to a station or set of points) is replicated to represent different points in time. For each train at a given location and point in time, the decision is whether or not to move to a different location arriving at a particular point in time. The route from the origin of a service to its destination is denoted by a flow through the network from the source (origin) to the sink (destination). The size of the resulting model increases with the number of the nodes, the time frame and granularity (e.g., seconds, minutes), and the number of services. An example is given in Figures 1 and 2. Figure 1 illustrates a network with two stations and one point. Figure 2 shows the corresponding time-space network over a time horizon of ten units, using a granularity of one time unit. Two nodes identify each station, one indicating arrival at station and one indicating departure. Scheduling a train from Node 0 to Node 4 in Figure 1 involves finding a flow though through the network indicated by the arrows in Figure 2. These types of models are convenient to model the flow of goods over a network at a high level of planning. However, modelling railway operations also requires particular operational constraints that are usually not considered in multi-commodity network design problems. The most pertinent one is the first-in-first-out property on tracks (i.e., no overtaking). Another feature in railway operations is the presence of parallel tracks. In particular, trains can overtake each other if they are assigned to different tracks but this is not possible if they travel along the same track. Given the difficulties associated with representing such operational constraints within multi-commodity network design and the computational intractability of the resulting model, we have not been able to pursue this approach any further.

Figure 1: Sample network with two stations and one bi-directional track

4

Figure 2: Trajectories identified in the second iteration

Column generation approachThe second approach investigated for solving the timetabling problem is a column generation algorithm that works with complete trajectories, each corresponding to a train passing though the network from its origin to its destination rather than traversing a single arc of the railway network. The problem of scheduling a set of services on a network then translates into assigning trajectories to services without violating operational constraints. The number of trajectories is finite (as we consider a discrete time horizon), but very large. Therefore, we generate trajectories on an ‘as-needed’ basis in our algorithm. Initially, there is one trajectory for each service (e.g., the fastest one). By solving a linear program, we assign trajectories to services such that the maximum number of services can run on the network without conflicts. The compatibility of two given trajectories with regard to, e.g., platform capacity and headways, can be checked in a pre-processing step. Each step of the algorithm solves a sub-problem to identify a new trajectory. This procedure is repeated until no trajectory is found which would improve the current solution. We have developed a functioning version of the algorithm that is able to solve very small instances with three stations and 40 trains. However, larger instances such as the network tested in this study exceed the capabilities of computational resources to run the algorithm efficiently. Consequently, we have not been able to pursue this approach any further.

Job shop approachThe solution approach described in Deliverable 2.3 is able to generate timetables by taking into account delays. The size of the input data is irrelevant from an algorithmic point of view. However, the large computational requirements prevent the generation of robust timetables for a large part of the network. The computational

5

requirements, however, can be reduced if timetable robustness considerations for the timetable (e.g., the ability to mitigate minor delays) are ignored. Consequently, we have focused solely on achieving feasible timetables with additional services.

The job-shop model has some drawbacks that had a minor impact on a small network, but might significantly distort results on large networks. Figure 3 illustrates one potential drawback, which is based on Syston Junction near Leicester. The blue and red arcs in the figure indicate the fast and slow tracks, respectively.

Figure 3: Example of a junction where fast tracks are denoted by blue arrows and slow tracks by red arrows

In the example shown in Figure 3, the assignment of trains to tracks would dictate whether trains running from B to A would be in conflict with trains from C to A. When travelling on the slow track, trains from B to A have to be assigned to a junction-machine in the job-shop model, whereas on the fast track they do not. Jobs that may require a different set of operations depending on the actual machine assignment are, typically, not considered in classical job shop scheduling problems. We overcome such issues by making simplifying assumptions, although these might lead to infeasibilities in the resulting timetables. Details of the assumptions made are described in the following section.

3. Computational ExperimentsThis section describes the case study tested, together with some simplifying assumptions that are made.

Description of the case studyThe case study involves a wider rail network as compared to the one

6

tested in Deliverable 2.3. The network for the present deliverable comprises 35 key stations (including Alexandra Palace, Cambridge, Doncaster, Peterborough, Leicester, and Nottingham), 17 junctions, 21 points, and 215 arcs. In our representation, we define junctions as complex assemblages of points, typically where passenger and/or freight routes join/separate. Points involve simpler layouts, typically where the number of tracks on a given route changes. Stations with a single platform in each direction that offer no opportunity to overtake or change the track assignments do not require scheduling decisions, and therefore are not included as stations in our job shop model. The layout is presented in Figure 4, in which arcs represent track segments that are either fast (blue), slow (red), mixed (black), or freight (green) tracks. It is assumed that a given train can be assigned to any track and to any platform as this approach is currently applied on heavily utilised sections. However, no changes are allowed on directions, even on bi-directional tracks. From the national timetable, we select all passenger and freight trains (including light locomotives) that visit any of the nodes between 7am and 9am. We additionally consider 16 services that run as required (denoted by Q paths in the CIF files). In total, there are 326 services in our reference timetable. This results in 4,968 operations in the job-shop model (see Deliverable 2.3). In contrast to the earlier approach where the travel times were calculated by dividing the distance by an average speed based on maximum line speeds1, we use the travel times as indicated in the timetable that additionally include scheduled waiting times2.

This approach may be seen to be conservative as some trains, and freight trains in particular, occupy track segments for much longer than actually required. However, at the same time, the resulting timetables are more realistic as it enables the acceleration and deceleration profiles associated with the stopping pattern to be modelled more accurately.

1 Working with the average speed was appropriate for express trains that do not stop within the network. That is, increasing the travel times by assuming lower velocities would make the original timetable infeasible. However, it is unclear whether or not slow trains can achieve the assumed speed.2 Scheduled waiting times were minimised in the OCCASION project. As this may have unexpected consequences on the reliability of the timetable, we model the buffer times as given to prevent any knock-on effects.

7

Figure 4: Network used in the case study. Stations are indicated by circles, points by triangles, and junctions by rectangles. The

East Coast Main Line is highlighted.

The optimisation parameters are set as follows: existing services may

8

be shifted by ±5 minutes, the journey time of passenger services may not be stretched, headway times are set to 3 minutes across the network (apart from a few at certain locations to comply with the reference timetable, see below for further details), and the minimum dwell times are taken from the input timetable.

The capacity of the network is investigated by generating timetables with an increasing number of additional services. All new services are copies of some of the existing services (i.e., with the same route and journey times) from the reference timetable. This indicates that all additional services must arrive at or depart from Peterborough between 7am and 9am. Finally, the number of new services ranges from 1 to 10.

Simplifications in the modelGiven the inconsistencies indicated in the Appendix and due to issues arising in the modelling of various track assignment at junctions in the job shop model, we make simplifications on headways as shown in Tables 1 and 2. Furthermore, we assume that express trains are not in conflict with other trains at NENGLNN and PBROEFL junctions, and at SYSTNSJ when travelling from LESTER to LOGHBRO or vice versa.

Table 1: Headways on tracks

Table 2: Headways at junctions.

9

4. ResultsFor each number of additional services from 1 to 10, we generate five instances by replicating randomly chosen services from the reference timetable to account for the variability of random choice. Four scenarios are examined: adding services that either pass through (i) Peterborough, (ii) Peterborough and Alexandra Palace, (iii) Peterborough and Grantham, or (iv) Peterborough, Grantham, and Alexandra Palace. The LNS is aborted either after 90,000 iterations, or 30 hours, or when a feasible timetable is found, whichever is reached first. Each instance is solved three times to account for the stochastic nature of the solution algorithm. Despite the generous computational resources made available, it is still possible for a timetable with additional services to be declared infeasible even though it may not be. This is due to the nature of the algorithm used, which does not guarantee optimality of the solutions identified.

Figure 5 summarises the results. The horizontal axis shows the number of additional services. The vertical axis shows the number of feasible timetables identified out of the five tested, for varying numbers of additional services. The routes of the new services are distinguished by colour. In particular, the services that pass thorough Peterborough are indicated in blue, services that pass through Peterborough and Alexandra Palace in red, services that pass through Peterborough and Grantham in yellow, and services that pass through all three stations in green.

Figure 5: Number of feasible timetables for different numbers of added services with different routes.

The results shown in Figure 5 indicate a highly utilised network. The results also indicate that it is possible to insert up to ten services into

10

the reference timetable3. However, the capacity drops significantly if the additional services are those running along prominent routes. In particular, only five services could be added to the timetable between Peterborough and Grantham or between Peterborough and Alexandra Palace. It turns out that the services that run between Alexandra Palace and Grantham (through Peterborough) are the hardest to schedule – at most three of such services could be replicated.

5. Concluding remarksThe results indicate that the rail network is well utilised in the peak hours. No more than five services could be added on the prominent routes (e.g., between Peterborough and Alexandra Palace, and Peterborough and Grantham). Given the simplifications made (e.g., ignore shunting movements and rolling stock availability) it seems that an infrastructure investment needs to be made to provide additional capacity if there is a desire for the number of services to be increased on these routes. An alternative way to provide additional capacity is to re-allocate or re-visit the scheduled waiting times (i.e., buffer times to mitigate knock-on delays) using stochastic optimisation techniques. Finally, as there is a significant difference between the number of trains that can be scheduled on a small network around Peterborough (as described in Deliverable 2.3) and on the wider area network described in this study, these results suggests that Peterborough is not necessarily a bottleneck in the network. Our work suggests that the key bottleneck on the network modelled is between Woolmer Green and Digswell, where four tracks reduce to two to cross the Digswell Viaduct.

One extension to this study would be to look at allowing changing directions on bi-directional tracks to enhance the (theoretical and practical) capacity of the network, and reducing the headways to the extent that the track length, signalling and safety considerations allow.

ReferenceKovacs, A., Bektas, T. and Potts, C. (2016) Stochastic Optimisation. DITTO Milestone 9, Deliverable 2.3. October.

3 The random selection of the new services added is the main reason for failing to identify a feasible timetable with nine additional services. There might be more services on busy routes or services with long routes.

11

Appendix

Conflicts in original timetableBefore using the reference timetable as input, we had to perform data cleansing. Next, we list some examples.

The following Q-trains (i.e., they run as required) use the same resources at the same time until ALEXNDP. They are then separated by a headway of one minute at GORDONH and by two minutes at HFDN. In this example, the service with the UID H41399 was removed from the timetable.

The following Q-trains have different ID numbers and routes, but use the same resources at the same time at the given locations. In such cases, we remove the service that has the shorter route.

12

The next trains depart from RTFD with a distance of two minutes. This is an overtaking move, i.e., the first train arrives in the platform loop and departs two minutes after the following train has passed. While this might strictly be a headway violation, we have reduced the headway at this location to two minutes.

13

The next two trains maintain a headway of only one minute until SYSTNSJ. We have deleted the service with the UID H06742.

The following two express trains pass SHPRTBJ with a headway of two minutes. The trains are travelling in opposite, conflicting directions through the junction. The junction margin is probably less than the headway, since the junction can be released for a train travelling in the opposite direction more quickly than one train can follow another. We have reduced the headway time at this location to two minutes.

14