Report on Traffic Flow Model D4.2

DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers Project Reference: 636285 H2020-MG 2014-2015 Innovations and Networks Executive Agency Project Duration: 1 May 2015–31 April 2018

Authors Jelena AKSENTIJEVIC Johann BLIEBERGER Mark STEFAN * Andreas SCHÖBEL

*Corresponding author: Andreas Schöbel, [email protected]

Date: May, 10th 2017

Dissemination level: (PU, PP, RE, CO): PU

This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 636285

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

DOCUMENT HISTORY

Number Date Author(s) Comments

1 20/03/2017 Andreas Schöbel First Draft

2 14/04/2017 Jelena Aksentijevic Introduction, Data Flow Model, Case Studies

3 25/04/2017 Mark Stefen, Jelena Kronecker Algebra Aksentijevic

4 1/05/2017 Andreas Schöbel Executive Summary

5 7/05/2017 Mark Stefan Case studies

6 8/05/2017 Andreas Schöbel Summary and Conclusions

7 9/05/2017 Jelena Aksentijevic Final proofreading

8 23/06/2017 Vijay Ramdas Final Review

9 10/07/2017 Ken Gavin, Julie Clarke Final Version

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Table of Contents

Executive Summary4 1 Introduction5 2 Dataflow Model7 2.1 Input Part 1: Infrastructure, Rolling Stock and Timetable7 2.2 Input Part 2: Infrastructure Manager Assessment Request7 3.2.1 Assessment of consequences of restricted availability of infrastructure assets8 3.2.2 Assessment of consequences of operational incident8 3.2.3 Assessment of benefits from infrastructure enhancement8 4 Kronecker Algebra for Railway Operation10 4.1 Introduction into Kronecker Algebra based Railway System Optimization10 4.2 Physical train model11 4.3 Calculation of the optimal driving strategy of a train12 4.4 Kronecker Algebra for analysis and optimization of railway systems13 4.5 System optimisation17 5 Irish Rail Case Study25 5.1 Northern Line Malahide – Drogheda – Dundalk25 5.2 Dublin Area31 6 Summary and Conclusions52 References53

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Executive Summary

During maintenance work on infrastructure assets, the management of railway traffic is a challenging task for modern railway operation. Of course, all assets in use have to fulfil high requirements in terms of availability. Nevertheless, they are expected to eventually fail and therefore will need to be maintained or replaced in a timely fashion (i.e. before they start having severe impacts on daily operations). Once sophisticated models are able to predict the right timing for replacement, traffic flow will have to be rescheduled. Typically, maintenance work is carried out during night time because typically there is significantly less traffic than during day time or even no traffic. Maintenance works may also be scheduled for off-peak periods. Unfortunately, some tasks may even require closure of sections between two cross overs for a longer period of time. If this happens on a single track line, passenger trains need to be replaced by bus service and cargo trains will be either rerouted or rescheduled. On a double track line, the capacity issue has to be taken into account. Depending on the distance between two neighbouring cross overs, capacity may be significantly reduced. This leads to the question of which trains can be cancelled or delayed. To address this, a number of constraints have to be considered. This task is usually managed manually or with very little support from existing IT systems. The aim of Task 4.3 within the frame of Destination Rail Project was to develop a methodology to support Infrastructure Managers in their decision making process concerning traffic planning during maintenance work. A mathematical framework, called Kronecker Algebra, has been selected as a promising methodology, even for real time applications e.g. Driver Advisory Systems in accordance to the objectives in the description of work. While the performance of most algorithms decreases when additional constraints are added, Kronecker Algebra can deliver faster results with the addition of more constraints. This behaviour is very suitable for application in railway operations since we are dealing with a lot of constraints that need to be considered in finding solutions for real applications. Operational parameters like the infrastructure asset characteristics, the rolling stock and the original timetable are used for calculations under reduced availability of sections or track speed limits. Input data has been successfully collected from Irish Rail (Milestone 15). The output consists of optimised train runs in terms of punctuality and overall energy consumption and can be used for the evaluation of different scenarios for carrying out maintenance work for infrastructure assets. The traffic flow model has been successfully tested on the Northern Line between Malahide and Dundalk as well as on the Dublin Urban Area between Connolly and Pearse (Milestone 16). Ultimately however, it remains the responsibility of an infrastructure manager to decide which scenario is selected for real application. In comparison to existing practice, the infrastructure manager’s decision will be supported by more precise consequence data however. The developed traffic flow model allows a detailed assessment of the operational effects of any changes of network availability.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

1 Introduction

The current state-of-the art in terms of railway traffic operations consists of microscopic simulations of railway operations that are based upon physical and mathematical models of the railway system. Such tools generally provide output indicators in terms of operational performance; for example, delays and/or energy consumption. To date, optimisation has typically been predefined by the user of the tool, introduced into the simulation and ‘tested’ for its applicability through simulations. This has resulted in missed opportunities for finding optimal solutions, and has led to simulation programmes not being able to solve dispatching questions or handle headway conflicts.

The traffic flow model developed in the Task 4.3 of Destination Rail includes innovative, graph-theory based mathematical techniques. Furthermore, it incorporates the ability to dynamically optimise operations, in particular degraded operations during maintenance or renewal works on the railway infrastructure. In addition to allowing a detailed assessment of the operational effects of any changes to network availability, this traffic flow model also uses new techniques to identify options for improving response to interruptions. In other words, this model incorporates the ability to mitigate the impacts of existing bottlenecks in the railway system by the rescheduling of trains whose performance could be affected. To put it differently, this model is capable of providing options to improve traffic flow as well as assessing the impact of maintenance and renewal strategies. This is done by optimising traffic flow while taking into account a number of different parameters, including energy consumption and punctuality. As a result, the model will allow an adaptation of the outputs to meet the specific requirements of different end-users.

The traffic flow model has a modular structure and can therefore interface with the other tools developed and used in this project (including the Network Whole Life Cost Model developed in Task 4.4). Adopting an open data exchange standard for a software product entails many advantages like compatibility with other software components, accessible documentation, portability and flexibility. RailML 1 is a common open, xml-based exchange format used in the railway sector and it has been used as standard data exchange for the work package at hand. The standard comprises most of the input information needed to compute traffic flow optimization, divided into three schemata: infrastructure, rolling stock and timetable. Due to the number of different interfaces, this model can also contribute to improvements in Driver Advisory Systems (DAS) by providing reliable, ‘online’ movement authority optimisation to resolve conflicts at junctions arising from any source of disruption.

The EU transport policy is focused on providing support for increasing the usage, the useable capacity and the performance of existing rail networks, for example by facilitating the switching of freight transport from road to rail through the prioritisation of the renewal and optimisation of new rail sections in order to reduce bottlenecks. The objective of the traffic flow model is to offer infrastructure managers a ‘plug and play’ tool for dealing with traffic modelling and optimisation functionalities that can help them test and compare different potential scenarios of network disturbances. Furthermore, by modelling their operational impacts, the model also has the capability to demonstrate other innovations developed in the project.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Dataflow model offers an overview of data necessary for the application of the optimisation algorithm. The input data consists of two categories: 1) data for the simulation of the operational railway traffic flow (this includes infrastructure characteristics, rolling stock features and timetable under undisturbed conditions) and 2) the different network scenarios for analysis by the infrastructure manager.

In terms of the analysis the model can be used to assess:

 The consequences of restricted availability of infrastructure assets. The aim of this is to reduce the impact of restricted availability of infrastructure assets. The restriction can result from maintenance work on a given track section, resulting in a reduced speed limits for that section or on the neighbouring track, as a protection measure for the staff.  The consequences of operational incidents on the network. An interruption event can be the result of a broken down train or unavailability of the track section due to external factors such as flooding, landslides etc.  The benefit associated with infrastructure enhancement. Examples of infrastructure enhancement include the construction of an additional crossing over on a highly trafficked line or an additional bridge. For each case, the optimisation of the speed profile of approaching trains is crucial for enabling them to pass the bottleneck sections exactly at the allowed speed limit in order to keep occupation time as short as possible.

Finally, the model has been used to analyse impacts on operations as part of two case studies; namely, 1) the Northern Irish Line, Malahide – Drogheda – Dundalk, which represents a rural area, and 2) Dublin, which represents an urban area. The goal was to compare the overall performance impacts on a simulated network using current optimisation techniques and when utilising the new model’s optimisation functionality.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

2 Dataflow Model

The input for the traffic flow optimisation tool is defined by two components: 1) the current characteristics of the rail system and 2) the infrastructure manager’s requirements on the potential network changes that need to be evaluated. The two components will be merged with the help of a lightweight visualisation tool, OpenTrack simulation software 2 and subsequently processed using the syntax of the input files for the optimisation tool. The workflow is shown in Figure 1.

Figure 1: Dataflow Model

2.1 Input Part 1: Infrastructure, Rolling Stock and Timetable

Infrastructure data include information about tracks and operation control points, and all other related assets (e.g. stations, platforms etc.), such as rolling stock data relating to the physical characteristics of trains which are part of the traffic system under consideration, timetable data, which provides information about planned train routes, as well as stopping patterns and their associated time schedules.

2.2 Input Part 2: Infrastructure Manager Assessment Request

The user (e.g. infrastructure manager) sets out the alternative disruption scenarios and or infrastructure enhancement scenarios for the assessment of the consequences on the existing traffic flow. The possible assessment request provided by the infrastructure manager can be divided into three categories, namely, 1) restricted availability of infrastructure assets, 2) operational incidents and 3) infrastructure enhancement.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

3.2.1 Assessment of consequences of restricted availability of infrastructure assets

The aim of the assessment is to reduce the impact of restricted availability of infrastructure assets due to planed works on the network. This can result from maintenance work on a given track section resulting in the imposition of reduced speed limits on that section and/or on the neighbouring track, as a protection measure for the staff.

The following data has to be provided by the infrastructure manager:

 affected track or track section (reference: infrastructure & timetable input)  speed change [km/h]  time period (begin [hh:mm:ss] – end [hh:mm:ss]) and duration or repetition  thresholds for delays of affected trains [hh:mm:ss] to set priority on trains reaching their specific threshold  monetary value of delay minutes for different train categories (regional, intercity, freight) (linked to WP3) and for the passenger transport information about differences in the monetary values depending on the day of the week.

3.2.2 Assessment of consequences of operational incident

An operational incident can occur due to a broken down train or unavailability of the track section due to external factors (i.e. unplanned), for example, flooding of a bridge.

The following data has to be provided by the infrastructure manager:

 affected track or track section (reference: infrastructure & timetable input)  time period (begin [hh:mm:ss] – end [hh:mm:ss])  thresholds for delays of affected trains [hh:mm:ss]  monetary value of delay minutes for different train categories (regional, intercity, freight) (linked to WP3) and for the passenger transport information about differences in the monetary values depending on the day of the week.

3.2.3 Assessment of benefits from infrastructure enhancement

Examples of infrastructure enhancement include the construction of an additional crossing over a highly trafficked line or construction of an additional bridge.

The following data has to be specified by the infrastructure manager:

 location of the planned section and connections to existing tracks (reference: infrastructure input [track:id] and position on the track [meters])  length of the planned section [meters]  speed restriction on the selected section [km/h]  gradient on the selected section (if changed) [‰]  set of affected trains (reference: timetable)

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

 monetary value of delay minutes for different train categories (regional, intercity, freight) (linked to WP3) and for the passenger transport information about differences in monetary values depending on the day of the week.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

4 Kronecker Algebra for Railway Operation

4.1 Introduction into Kronecker Algebra based Railway System Optimization

The algorithm for calculating the optimal driving strategy and optimizing the overall railway system is based on the PhD thesis “Energy-efficient Optimization of Railway Operation. An Algorithm Based on Kronecker Algebra” [3].

In general, a railway system consists of several trains and a large infrastructure network. In such complex systems, it is very difficult for the train driver and the dispatcher to find a solution which enables each train to arrive at its destination on time and minimise energy consumption at the same time. To ensure the requirements for a safe system, some operations are carried out by automated systems. However, energy consumption is considered less and therefore there is high potential for saving traction energy. This potential can be divided into two parts. On the one hand, each single trip can be optimised through the deployment of an optimal driving strategy, resulting in minimal traction energy demand. On the other hand, the optimisation can be applied to the complete railway system. In the latter case, the schedules, delays, and restrictions on the tracks have to be taken into account for the identification of an optimal solution. The optimisation of such a system must also satisfy important criteria like safety, punctuality and passenger comfort. Based on these restrictions, the optimisation algorithm needs to determine an overall solution with energy consumption as low as possible. The results of the algorithm can be used to support train drivers and dispatchers.

The first part of the algorithm consists of finding an optimal solution for a single journey, which consists of four driving stages, namely acceleration-phase, speed-hold-phase, coasting-phase, and braking-phase. The second part of the algorithm is the optimisation of the complete system by applying the so-called Kronecker Algebra and the single-trip optimisation.

Kronecker Algebra consists of Kronecker Sum and Kronecker Product and it is used to create a matrix which contains all possible movements of the trains within the system. Each train has a route for its journey that consists of a sequence of track sections. This information is given as a matrix and used as input for the algorithm. Each track section is modelled by a semaphore and given as a matrix, too. Kronecker Sum calculates all possible interleavings of the trains, but only if they do not use the same track sections. If several trains use a common track section, Kronecker Product is used to ensure that the access to each section is produced sequentially. More specifically, a train can enter a section only if it has been released by another train. The result of the application of Kronecker Algebra is again a matrix, which can be represented by a graph. The optimal driving strategy for each train is given as a distance-speed-diagram. This model is used to determine and avoid conflicts (e.g. deadlocks or headway-conflicts). All conflict-free solutions are calculated and as a result, the best solution in terms of energy consumption is determined.

For each railway company it is a formidable challenge to provide a well-performing railway network covering several aspects like punctuality, passenger comfort, energy demand, etc.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

The human brain cannot grasp and handle the complexity of large railway systems that include a large numbers of trains, track sections, railway stations and others aspects. Consequently, automation systems are required to carry out some of the tasks and to help the user find good management strategies and to act in a safe way. One of the many challenges is the need to find optimal driving strategy for each train within the railway system. If the train driver knows the track well, then he / she might find a good driving strategy in terms of energy demand, but it may not be the best one. Algorithms on fast computers can calculate an optimal driving strategy quickly and this information can be forwarded to train drivers or to automated driving systems. For large systems in which several trains use the same track sections, the problem is more complex because there must be also be a synchronisation between the trains to guarantee that a train enters a track section only if it is not occupied by another train. When calculating a solution with minimal energy consumption, the sequence of trains entering and leaving track sections depends on the planned travel time and the energy consumption. Finding the best solution is a complex task and requires substantial computing power. Thus, it is impossible for a human brain to single-handedly find the best strategy in real-time without the support of automation systems.

The algorithm optimises the movements of trains within a railway system, taking account of the following restrictions:

 Safety: the algorithm must ensure that more than one train is not within a track section at the same time. Further track restrictions (e.g. maximum allowed track speed) and train restrictions (e.g. maximum train speed) must also be taken into account.  Punctuality: the trains must leave and arrive on time.  Driving comfort: the calculated speed profile must be easy to follow by the train driver and passenger comfort must not be affected in an unpleasant way (e.g. lots of accelerating and braking phases within one trip). In addition, it must be possible to define a speed-step-size (e.g. 5 km/h steps) due to the restrictions of cruise control.  Energy efficient driving: the overall energy consumption of all trains must be as low as possible in strict accordance with the previous restrictions.

4.2 Physical train model

To calculate the optimal driving strategy of each train within the system, a realistic train model was implemented, based on the formulae used in OpenTrack [5], where parameters like traction and braking force, train parameters, and several types of resistance (e.g. rolling, gradient, curve) were taken into account. The formulae used, including the calculation of acceleration curves, braking curves, the speed changes within a coasting phase and the calculation of the energy consumption are not described here, but further details can be found in [3].

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

4.3 Calculation of the optimal driving strategy of a train

Before providing detailed information about the algorithm for optimisation of the overall railway system, some information about a single trip optimisation must be specified. The optimal driving strategy of a single train depends on various factors of influence, including:

 the gradient of the track and speed restrictions  the length and weight of the train  the scheduled travel time  traction power and braking capability  recuperation behaviour  various resistance parameters

The optimal driving strategy for a train, which starts at a given position and drives within a given travel time on a specified track to reach its destination (final position), may contain the following driving modes in exactly this order:

1 Acceleration-phase: the train starts its acceleration-phase with maximum traction force at the start position with a given starting speed (e.g. 0 km/h at a railway station) and accelerates until the hold speed and the hold position are reached; 2 Speed-hold-phase: the train starts its speed-hold-phase at the hold position with hold speed and drives at constant speed until the coasting position is reached. The speed value at this position is called coasting speed and is equal to the hold speed; 3 Coasting-phase: the coasting-phase starts at the coasting position and ends at the braking position. During this phase, the train will use its traction nor braking force to just roll until the braking position is reached; 4 Braking-phase: the braking-phase starts at the braking position and ends at the final position. The speed decreases from the braking speed to the final speed (e.g. to 0 km/h at a commercial stop which can be a station or other stop position).

Based on the four aforementioned driving phases, the optimal strategy is calculated by arranging these regimes in such a way that the train will reach its final position within the planned travel time, with less energy consumption and with guaranteed driving comfort for the train driver and the passengers. Further details about the algorithm and how to calculate the optimal driving strategy, as well as a number of examples of the calculation can be found in [3].

Figure 2 shows the result of calculating the optimal driving strategy for a train. The blue line shows the speed of the train, based on the optimisation algorithm while the red line illustrates a typical driving strategy used in the field when a coasting phase is not part of the strategy. Based on train and track parameters (e.g. recuperation is possible or not, the gradient of the track), energy savings of about 10 per cent are possible in the blue line compared to the red one.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 2: Example of an optimal driving strategy (blue) compared to a typical driving strategy in the field (red)

4.4 Kronecker Algebra for analysis and optimization of railway systems

Kronecker Algebra was introduced to model concurrent systems, in particular for computer systems consisting of several threads which access shared memory and then modified for usage in railway systems. Kronecker Sum and Kronecker Product are simple matrix operations that can be used to model synchronisation of shared resources and generate interleavings. In computer science, the access to a shared memory by several threads must be synchronised and for this reason Kronecker Algebra is applied. When applied to railway systems, trains correspond to the threads and track sections to the shared memory. The access to the resource is modelled by semaphores from computer science. As a result, a train can enter a track section only if it is not occupied by another train. The application of Kronecker Algebra enables the finding of conflicts (e.g. headway-conflicts, deadlocks). The resulting graph shows all possible movements of the trains and based on this graph, a conflict-free situation can be found (if it is possible, within the given timetable).

4.4.1 Representation

As previously mentioned, Kronecker Algebra is a mathematical model which can be used to calculate a matrix describing a complete railway system. Directed graphs are used to represent movements of the trains and operations on track sections. Each train is assigned at least one route consisting of at least one track section. A track section can be part of several routes. As a result, the routes describe movement of the trains and can be represented as graphs, too. Each graph can be represented by its adjacency matrix, which is used as input for the calculations. Assume that the edges in the graphs are labelled by elements of a semiring that consists of a set of labels containing the following semaphore calls:

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

 pi denotes entering or reserving track section i, in particular Tj:pi means that train j wants to enter track section i.

 vi denotes leaving or releasing track section i, in particular Tj:vi means that train j will leave track section i.

A railroad system consists of several trains and track sections which are represented by graphs and their adjacency matrices. In general, binary semaphores are used to represent the operations on track sections, whereas each track section is modelled by its own semaphore.

4.4.2 Modelling Synchronization and Interleavings

Kronecker product allows the modelling of synchronisation. Given a m-by-n matrix A and a p-by-q matrix B, their Kronecker product, denoted by A⨂B, is a mp-by-nq block matrix defined by

푎1,1퐵 ⋯ 푎1,푛퐵 퐴⨂퐵 = ( ⋮ ⋱ ⋮ ) 푎푚,1퐵 ⋯ 푎푚,푛퐵

Given a matrix A of order m and a matrix B of order n, their Kronecker sum denoted by A⨁B is a matrix of order mn defined by

퐴⨁퐵 = 퐴⨂퐼푛 + 퐼푚⨂퐵 where Im and In denote identity matrices of order m and n, respectively.

Assume two trains want to use the same track section. Thus, the occupancy needs to be synchronised. An additional matrix is used to model the track section

0 푝 푆 = ( ) 푣 0

As already mentioned, p denotes entering the track section and v means leaving the section. The complete system behaviour can be described by a matrix, generated by

푅 = (퐶⨁퐷)⨂푆

In general, a railway system 푆 is modelled by a set of track sections 푇 = {푇푖|1 ≤ 푖 ≤ 푟}. Each track section 푇푖 is modelled by a matrix

0 푝푖 푇푖 = ( ). 푣푖 0

In addition, a railway system consists of a set of trains 퐿 = {퐿푗|1 ≤ 푗 ≤ 푡}. The route 푅푗 of train 퐿푗 is a sequence of track sections 푇푙1, … , 푇푙푠 for 1 ≤ 푙푛 ≤ 푟 and 1 ≤ 푛 ≤ 푠. Each route is modelled by a 2푠 × 2푠 -matrix. The set of routes is denoted by 푅 = {푅푗|1 ≤ 푗 ≤ 푡}. The behaviour of railway system 푆⟨푇, 퐿, 푅⟩ is modelled by

푡 푟 푆 = (⊕푗=1 푅푗)⨂(⊕푖=1 푇푖),

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

During the evaluation of the Kronecker product, t pi=pi∙pi and vi=vi∙vi. The different paths in the graph corresponding to matrix S mirror all possible behaviours of the railway system in terms of temporal interleavings of the actions of trains, namely entering and leaving track sections.

4.4.3 Example

Assume two trains accessing the same track section 1. The routes of the trains will be:

 R1: p1, v1

 R2: p1, v1

Written as matrix, the routes will be

0 푝1 0 0 푝1 0 푅1 = (0 0 푣1) and 푅2 = (0 0 푣1) 0 0 0 0 0 0

Track section 1 is modelled by

0 푝1 푇1 = ( ). 푣1 0

푡 푟 Based on the previous equations, ⊕푗=1 푅푗 and ⊕푖=1 푇푖 are calculated. Next, the complete system is calculated, which results in a matrix of size 18. For better readability in the graph- illustration of the results, only nodes reachable from the entry node are shown. The resulting graph of the example is illustrated in Figure 3.

Figure 3: Resulting graph of the example

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

It can be seen that there are two possible paths within the graph:

 R1.p1, R1.v1, R2.p1, R2.v1: Train 1 (using route R1) enters track section 1 and releases

section 1. Then train 2 (using route R2) can enter and release section 1.

 R2.p1, R2.v1, R1.p1, R1.v1: Train 2 (using route R2) enters track section 1 and releases

section 1. Then train 1 (using route R1) can enter and release section 1.

After applying Kronecker Algebra, the resulting graph may contain various types of nodes which are defined as follows.

 Deadlock: If the final node cannot be reached from a certain node d, then node d denotes a deadlock situation or a situation which will definitely result in a deadlock;  Safe state: A state is safe if all trains can perform their actions without having to take into account the movements of other trains within the system. From safe states only safe states can be reached;  Critical state: A state is critical if both, a deadlock and a safe state can be reached;  Synchronising nodes: A synchronising node is a node such that:

o there exists an edge ein = (i; s) with label vk, and

o there exists an edge eout = (s; j) with label pk.

where k denotes the same track section and ein and eout are mapped to different trains. Each synchronizing node is assigned at least one synchronizing condition. Each synchronizing condition contains a train leaving a track section, a train entering the track section, and the track section itself. A multi-synchronizing node contains more than one synchronizing condition.  Stop node: A stop node is a node where a train has to stop at a railway station for departure or arrival.

Consider node 5 of the graph of the previous example (Figure 3). It has an incoming edge labelled by R2.v1 and an outgoing edge R1.p1. Thus, the node is a synchronizing node, the synchronizing condition of node 5 is: 2  1: 1 where train 2 is leaving the track section 1 and train 1 is entering it. The following table gives an overview about the different node types and their illustration in the resulting graph:

Table 1: Different types of nodes

Node type Illustration

Deadlocks Red

Safe states Green

Critical states Orange

Synchronizing nodes Filled

Multi-synchronizing nodes Filled, double border

Stop nodes Rectangular

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Alternative routes: in general, each train has a well-defined route within the railway system. In some special situations it might happen that the train must leave the main track, (for instance, during overtaking or due to a blocked track section). Therefore, alternative routes should also be defined. As a consequence, the resulting graph is much wider than without alternative routes. On the other hand, it is possible for the trains to use different routes, if the preferred route cannot be used or is considered to be worse in terms of energy demand.

The number of edges after the application of Kronecker Sum is O(mn)1. Thus, the number of edges is linear in order of the resulting adjacency matrix. The number of nodes is bounded from above by n*k, where k is the number of trains within the railway system and the route of each train consists of n nodes. The resulting matrix, describing the complete railway system, is sparse. This enables the application of memory saving data structures and efficient algorithms (e.g. by using adjacency lists, which are linear in the number of nodes). In the worst case however, the number of nodes increases exponentially with the number of trains.

4.5 System optimisation

Previously, the optimisation of the driving strategy of a single train and the application of Kronecker Algebra has been considered.

If there are more trains within a railway network, each train could influence other trains. For example, a train wants to enter a track section which is occupied by another train. In this case, the train has to wait until the track section is released. The optimisation of the complete railway system, based on Kronecker Algebra and the single trip optimisation is described herein. The algorithm that delivers optimised behaviour in terms of energy consumption of all trains within a railway system consists of the following parts:

 Kronecker Algebra based system analysis  Graph reduction  Determining all possible routes  Finding the optimal driving strategy

4.5.1 Kronecker Algebra based system analysis

In a railway system with several trains, a deadlock situation might occur. The first part of the optimisation algorithm is to apply Kronecker Algebra to get all movements of the trains within the railway network. For this reason, each route must be given by using the p and v operations of the track sections. If the length of a train is less than the length of each track section, the train does not need to reserve more than two track sections simultaneously. However, if the length of the train is longer than a section, several track sections must be reserved simultaneously. With regard to the train route, it is also possible that several track sections need to be reserved at the same time but are released one after another. Each route can be modelled by using matrices and illustrated as a graph, where the edges are labelled by the p and v operations. In addition, the track sections must be modelled by

1 Assuming the corresponding matrices have order m and n, respectively

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

semaphores from computer science. By applying Kronecker Algebra, a matrix is created containing several states. The resulting matrix consists of all possible train movements, including deadlocks. It will be reduced to the relevant nodes in the following section.

4.5.2 Graph reduction

The resulting graph after the application of Kronecker Algebra can be reduced to the relevant synchronising nodes. The algorithm is designed to run on multi-core CPUs. There are several running tasks with each task having a unique id, which is a positive integer. The maximum number of tasks can be adjusted in the algorithm settings. The graph reduction consists of the following four steps that will be described in the next sections:

I. Determine the graph nodes.

II. Find the synchronising nodes.

III. Check the synchronising nodes.

IV. Find a path between the synchronising nodes.

Each part is designed to run on multi-core CPUs. Most of the operations are done solely within the task. If access to shared memory is unavoidable, it is guarded by protected objects, which are part of the Ada programming language. After the execution of the tasks, relevant data is copied from the local memory of the tasks to the global program memory.

Step I - Determine the graph nodes: as previously mentioned, the resulting graph is represented by a matrix. The first step of the graph reduction is to find all nodes that are reachable from the entry node. This is done by a breadth-first search, where each reachable node is added to a task-local set of nodes. After all nodes are examined, each task copies its data to a global set of nodes. As a result, a graph consisting of nodes reachable from the entry node remains. In this resulting graph, there may be all types of nodes, including deadlocks, which will be eliminated in the next step. Also, there may have been nodes within the resulting graph that are not reachable from the entry node. These nodes do not show up following the reduction procedure. As a consequence, all remaining nodes represent possible states in the railway system and all edges represent train movements, respectively.

Step II - Find the synchronising nodes: the goal of the second part of the graph reduction is to eliminate all deadlock-nodes. There is no a path from the deadlock-nodes to the final node. Therefore, the graph is traversed from the final node to the entry node. Similar to the first part of the algorithm, each reachable node is added to a set of nodes and its predecessors are added to the queues of the running tasks, whereby the task-id is again calculated by the hash-function. As a consequence, the deadlock-nodes are not reachable from the final node and thus not added to the set of nodes. In addition, all synchronizing nodes and stop nodes are determined and saved in separate data structures.

Step III - Check the synchronising nodes: If there is a chain of synchronising nodes with exactly the same synchronisation conditions, the last node of the chain is called leader synchronising node. Isolated synchronising nodes (with no direct connection to other synchronising nodes) are leader synchronising nodes, too. Only leader synchronising nodes

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

are required for synchronisations between trains and the calculation of their optimal driving strategy. The third part of the graph reduction algorithm checks if the synchronising nodes found in part two are so-called leader synchronising nodes or shortly, leaders.

If there is a chain of synchronising nodes with exactly the same synchronisation conditions, the last node of the chain is called leader synchronising node. Isolated synchronising nodes (with no direct connection to other synchronising nodes) are leader synchronising nodes, too. Assume a graph consisting of several nodes, but without synchronising nodes. Several paths between the entry and the final node may exist. As there are no synchronising nodes between the entry node and the final node, the movements of the involved trains are independent (no common track section used). As a result, all paths between the entry node and the final node are equal in a way that each train has the same movements (in the same order) on each path, without impacting on any of the other trains. Now assume that exactly one synchronisation node exists within the graph. In such a situation, all paths between the entry node and the synchronising node and all paths between the synchronising node and the final node are the same. This idea can be extended to a graph containing several synchronising nodes. If there is a chain of synchronising nodes, where each of them has the same synchronisation condition(s), only the last synchronising node is relevant, because each path which ends at the last synchronising node of the chain will have the same movements of the trains and the last synchronisation will definitely be done. If a path contains several synchronising nodes with the same synchronisation conditions and each synchronisation is done, the last one will have an effect on the resulting driving strategy, independent of the other synchronising nodes in the chain. Thus, all synchronising nodes, except the last one of the chain, can be handled as normal nodes. As a consequence, all isolated synchronising nodes and the last synchronising nodes of a chain will be handled as leaders, the others will be handled as non-synchronising nodes. The entry node and the final node are generally handled as synchronising nodes, in particular as leader synchronising nodes. Since stop nodes are a special kind of synchronising node, this part of the algorithm is applied in the same way for both synchronising nodes and stop nodes. For simplification, only the term synchronising nodes will be used in the explanation. After executing this part of the algorithm, the relevant nodes for further calculations are determined, which consist of the start node, the leader synchronising nodes, and the final node.

Step IV - Find a path between the synchronising nodes: in the previous parts of the algorithm, the graph was reduced and the leader synchronising nodes were computed. The last step is to find paths between these nodes with the restriction that each incoming and outgoing edge within the synchronisation must be used. The algorithm works as follows:

 The graph is traversed from the final node to the entry node by taking nodes from the task-local queue. At each node, the node itself, the last visited leader synchronising node, and the visited track sections in between the nodes are added to a task-local queue;  Each node is checked to identify whether it is a synchronising or a normal node.  If the node is a synchronising node, the additional information is updated (last visited synchronising node and visited track sections). Thus, the information of the leader synchronising nodes contains the node itself and at least one synchronising node, which can be reached from this node, including the track sections between them;

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

 If the node is a normal node, its predecessors must be examined. If a predecessor is not in the set of nodes from the first part, then it is not reachable from the entry node and thus not relevant for the deadlock-free situation and the reduced graph. On the other hand, if the node is in the set of nodes form the first part, the following situations must be considered: o If the predecessor is a real synchronising node, then this path is not relevant; o If the predecessor is a normal node, then the path is relevant; o If the previously visited synchronising node is the final node, then the path is relevant; o All the other paths are not relevant for calculating the optimal driving strategy.  If a relevant path is found, the information from the last node (previously visited leader synchronising node, the used track sections, and the current edge-label) is extended by the current track section i, if the edge label indicates entering or

reserving a track section, indicated by pi. If the entry node is reached, then the starting track section of the corresponding train is added to the node information, because this section is reserved initially and thus has no p-operation in the graph. Finally, the node itself and its node information are added to the queue.

When the resulting graph is created, it contains only the entry node, the leader synchronising nodes, and the final node.

4.5.3 Determine all possible routes

After the graph is reduced, calculation of all possible routes for each train remains. If trains have more than one possible route on their journey, several combinations of the routes exist:

푛

푅 = ∏ 푟푖 푖=0 where R is the number of combinations, n is the number of trains, and ri is the number of routes for train i. Some combinations which lead to deadlock situations may occur. These combinations of routes must not be considered for the overall result. In the previous section the graph was created, deadlocks were eliminated, and the graph was reduced to the relevant nodes. This means that the resulting graph is the basis for further calculations without deadlocks. To find all possible combinations of the routes of all trains within the railway system, the reduced graph is traversed from the entry node to the final node, using a depth-first search algorithm. When the final node is reached, a route is found and the passed track sections of each train are added to a set of routes. Each route contains at least the entry node and the final node. Between these two nodes, there might be stop nodes, if the train has stops at railway stations or synchronizing nodes, if there is a demand for synchronization on track sections between trains. Results of the application of Kronecker Algebra might include several paths between two synchronizing nodes at the same track sections. To ensure that every synchronisation is done, all synchronising and stop nodes which are found while traversing the graph must be saved in a set for a particular route. Each combination of routes has its own set with a unique id that is created by the track sections of the involved routes.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

4.5.4 Finding the optimal driving strategy

In the previous subsection, all possible routes were determined. The last step of the algorithm consists of finding the optimal solution in terms of energy. It is necessary to calculate the energy consumption for each route. A route might be partitioned into sub-tracks by stop nodes. Two types of sub-tracks can be distinguished:

 Sub-tracks without synchronisation: a sub-track of a particular route of a train does not contain the demand for synchronisation if there are no synchronisation node between two stop nodes. As a result, a train can drive undisturbed along its route and its driving strategy can be calculated independent of other trains;  Sub-tracks with synchronisation: if there is at least one synchronisation node within a sub-track, the calculation of the optimal driving strategy is more complex than the single trip optimisation.

Figure 4: Blocking Time of a Track Section [6, 7]

Some additional system behaviour present in railway systems must be considered in the calculations. Figure 4 shows the blocking time of a block section which will be used as the base to determine the blocking time of each track section. It can be seen that the blocking time of a track section is longer than its occupation time and consists of the following parts [7]:

 Time for clearing the signal.  The Sighting distance is illustrated at the left side on top of the figure. It starts at the point of view (when the driver can see the distant signal) and ends at the position of

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

the distant signal. The time from seeing the signal until the train passes it, is called Signal watching time.  The Approach time shows the complete time the train takes from the distant signal to the beginning of the section.  The train time on the track section is called Time between block signals.  The time between leaving a track section and completely passing a clearing point (e.g. all axles passed an axle counter) is called Clearing time.  In the end an additional offset is needed for releasing the track section (Release time).

As a result, a track section will be blocked for some time for clearing the signal before the train arrives at the point of view and released some additional release time after the complete train has passed the clearing point (e.g. an axle counter). The following values are calculated to ensure the correct synchronisation of trains on track sections:

 Earliest release time: this value is calculated in accordance with the schedule and indicates the earliest instant of time when a train releases a track section, assuming that it arrives at its destination within the planned travel time;  Latest release time: this value is calculated in accordance with the schedule and indicates the latest instant of time when a train releases a track section, assuming that it arrives at its destination within the planned travel time;  Earliest reservation time: this value is calculated in accordance with the schedule and indicates the earliest instant of time when a train reserves a track section, assuming that it arrives at its destination within the planned travel time;  Latest reservation time: this value is calculated in accordance with the schedule and indicates the latest instant of time when a train reserves a track section, assuming that it arrives at its destination within the planned travel time.

Additionally, the corresponding speed values are calculated (minimum and maximum speed for entering and leaving a track section, restricted by the train and track parameters and the schedule). The algorithm is designed to find all solutions with all conflicts avoided and trains arriving at their destination within the planned travel time. Only solutions without overlapping of the instants of time for entering and leaving a track section are allowed to be taken into account for finding the optimal solution in terms of minimal energy consumption. Before analysing the synchronising nodes, these time values are computed for every pair of trains involved in a synchronisation condition.

The next step is to analyse the synchronising nodes of each route. Three types of routes can be distinguished:

 No synchronisation between trains is needed: there are several situations where no synchronisation between trains is needed: o A track section is used by a single train; o A track section is used by more than one train, but there is no overlapping of the blocking time of a leaving and an entering train. If no synchronisation is needed, the corresponding synchronisation condition is removed from the synchronising node. If all synchronisation conditions are removed from a node, the node itself is removed from the route. Due to the schedule it might

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

be possible that all synchronising nodes are removed from a route and thus, only the entry node and the final node remain and the optimal driving strategy is calculated with the single trip optimisation;  No synchronisation between trains is possible: due to the calculated instants of time, based on the planned schedule, a situation where no synchronisation is possible might occur. If synchronisation is not possible, at least one train would not be able to reach its destination within the planned travel time. Since the algorithm only considers results with punctual arrival at each destination for the calculation of the driving strategies, the route is not taken into account for the overall results; Synchronisation between trains is needed: if the calculated instants of time show that synchronisation between trains is possible and needed, then the synchronising condition will not be changed in the synchronisation node.

There are several situations that may occur after the instants of time are calculated and their relationships are analysed:

 If all the routes are removed, it is not possible that the trains will reach their destinations on time. Possible solutions include adaptation of the timetable or reassignment of the routes (e.g. a train might use an alternative route);  If all routes consist of only the entry and the final nodes, there will be no interaction between the trains within the railway network and thus the optimal driving strategy for each train can be calculated independent of each other;  For all routes consisting of at least one synchronising node, the optimal driving strategy is calculated as follows: o Each node within the resulting routes must be analysed. For this reason, the nodes are put in an ascending order by their node ids. As a result, the positions which are part of the synchronisation conditions are also ordered correctly. The stop nodes divide the complete track into sub-tracks. Due to the synchronisation nodes, the sub-tracks are divided into several parts; o If a train is involved in a synchronisation condition, the node, in particular the track section from the synchronisation condition is relevant for the train. Based on the definitions for the earliest/latest and entering/release times, the relevant time and speed values for the corresponding track section are calculated and saved in a vector together with the synchronisation position. For a train entering a track section, the start position of the track is used as the synchronisation position and for a leaving train, the end position is considered. For each route and additionally, within the route for each train, a separate vector is used to save the data. This procedure is repeated for each node of the route until the final node is reached. If necessary, the next route is analysed in the same way. If all routes and their nodes are analysed, the optimal driving strategies can be calculated. The determination of the optimal driving strategy is done for each route and also for each train in each of the routes. Therefore, the calculation starts with the first train of the first route. Due to the fact that the complete track is split into several parts and each part can have several output speed values, in combination with several travel time values, a recursive algorithm is used to calculate several driving strategies for the overall result. The algorithm calculates the optimal driving strategy

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

between two positions taken from the vector. The input speed of the current calculation is based on the previous calculation, in other words, the input speed is the output speed of the previous calculation. The output speed can vary between the minimum and maximum output speed value. The travel time is also based on the previous calculation and can vary between the minimum and maximum travel time values. The optimal driving strategy for the given input parameters is calculated. If a solution is found, the calculated output values are taken as input parameters for the next part. This procedure is repeated until the last element of the vector is reached. After this, the calculation for the next train within the system starts and when all computations of all trains are finished, the same procedure is done for the next route. Thus, the algorithm calculates various driving strategies for each train. The last step within the optimisation algorithm is to find the best solution in terms of energy consumption. For this reason, all combinations of the results of the involved trains are analysed. Since there are several instants of time for entering and leaving a track section, an overlap between a train entering and another one leaving a track section may occur. Such results are not valid and are discarded from the set of results. Consequently, the results that meet the following restrictions are checked: . Each train is within its schedule; . A track section can be used only if it is not occupied by another train; . Minimal in terms of energy consumption.

Additional reduction of the graph

Due to the fact that the resulting graph might be very large, only successors of a node where the connecting edge contains the next operation in terms of the time or if alternative route is available are taken into account. This will result in a much smaller graph and reduce the calculation time. Therefore, when feeding in the routes into the algorithm, the travel time for each track section will be taken into account a priori.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

5 Irish Rail Case Study

The traffic flow model was validated using the Irish railway network. Two scenarios have been selected: 1) one representing a rural part of the network, with an infrastructure that is not very complex and has low intensity of traffic, namely, Northern Line between Malahide und Dundalk, via Drogheda; 2) the complex Dublin network, which has a high traffic intensity.

The quality of the input data is extremely important or order to obtain a satisfactory output. Infrastructure, Rolling Stock and Timetable were the basic components for running the traffic flow model. For the assessment of restricted availability of infrastructure assets as well as enhanced infrastructure layouts, a collaboration between WP3 and Irish Rail for the realistic application of the scenario was crucial.

5.1 Northern Line Malahide – Drogheda – Dundalk

The Boyne Viaduct represents the test zone (i.e. maintenance work) between Drogheda and Dundalk. This section is a single line section with a maximum speed limit of 50 km/h. On a single track line, usually the priority is set for as much work as possible to be done in the time slot between two trains. Moreover, there are even cases of timetable modification for the more efficient maintenance work. OpenTrack, a software for the simulation of railway operations, offered visualisation of railML 1 input data by converting them into graphic representation of infrastructure. This can be seen in the Figure 5.

Figure 5: Infrastructure of the Northern Line Malahide-Drogheda-Dundalk visualized using OpenTrack software

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Rolling Stock using this section includes IC and Cargo trains using class 201 and DART traveling only to Malahide.

Figure 6: Train Graph Malahide-Drogheda-Dundalk (9:00AM - 1:00PM)

The train graphs presented in Figure 6 (9:00AM - 1:00PM) and Figure 7 (5:00 PM – 9:00 PM) are examples of the existing timetable of the above drawn infrastructure. The planned timetable (black line) from Malahide to Dundalk and the timetable after the simulation run (including blocking time stairway) using OpenTrack software are shown. This example does not include any optimisation, but serves as input data. Optimisation has been carried out for the section between Rush & Lusk and Balbriggan.

Figure 7:Train Graph Malahide-Drogheda-Dundalk (5:00 PM – 9:00 PM)

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Table 2: Timetable for T1 from Rush & Lusk to Balbriggan

T1 Arrival Departure Rush & Lusk 07:38:30 07:39:30 Skerries 07:44:00 07:44:30 Balbriggan 07:49:30 07:50:30

Table 3: Timetable for T2 from Balbriggan to Rush & Lusk

T2 Arrival Departure Balbriggan 07:45:00 07:46:00 Skerries 07:51:30 07:52:30 Rush & Lusk 07:58:30 07:59:30

Figure 8: Train Graph with blocking time stairway between Rush & Lusk and Balbriggan for the trains T1 and T2

Figure 9: Speed-Distance diagram showing optimal driving strategy for the train T1

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 10: Speed-Distance diagram showing optimal driving strategy for the train T1

Table 4: Energy consumption for the trains T1 and T2 before and after optimization process between Rush & Lusk and Balbriggan

Total energy consumption (including 67,96 kWh recuperative braking) without optimization (“hold strategy”):

Total energy consumption (including 65,99 kWh recuperative braking) with optimization:

Savings ~ 3 %

Construction Area at track section 45

Table 5: Timetable for the T1 from Rush & Lusk to Balbriggan with construction area at track section 45

T1 Arrival Departure Rush & Lusk 07:38:30 07:39:30 Skerries 07:44:00 07:44:30 Balbriggan 07:48:20 07:50:30

Table 6: Timetable for the T1 from Balbriggan to Rush & Lusk with construction area at track section 45

T2 Arrival Departure Balbriggan 07:45:00 07:49:00 Skerries 07:52:50 07:53:20 Rush & Lusk 07:58:30 07:59:30

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

By using the modified schedule above, T1 will arrive on time at Skerries and will be 70 seconds earlier in Balbriggan to release track section 62 as early as possible. Train T2 will be late by 80 seconds in Skerries but it will be on time at Rush & Lusk. So no further delays will occur due to construction works on track section 45.

Figure 11: Train graph including blocking time stairway between Rush & Lusk and Balbriggan for the trains T1 and T2 during construction work at track section 45

For both trains, different driving strategies have been calculated, the same as before, which are illustrated in the following two figures. Due to the higher driving speed and less travel time, the energy consumption is much higher than before. Without a construction area, the overall energy consumption of the two trains was 65,99 kWh, however, when using the same track due to construction on the track 45, it is 95,39 kWh.

Figure 12: Speed-Distance diagram showing optimal driving strategy for the train T1 with construction work being done on the track section 45

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 13: Speed-Distance diagram showing optimal driving strategy for the train T2 with construction work being done on the track section 45

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

5.2 Dublin Area

The Dublin area includes a more complex infrastructure and consequently, more complex railway operations. Figure 14 shows a simplified model of the Dublin area topology that is the focus of this case study. On the other hand, Figure 15, which was created using OpenTrack simulation tool, offers a detailed illustration of infrastructure required for the application of the Kronecker Algebra.

Figure 14: Simplified model of the Dublin are case study

Connolly Station

CY51 1 Clontarf Road 2 Killester CY55 110 km/h 30 km/h 2 3 DN278 DN281 CY11 CY13 CY16 CY18 CY24 CY26 CY28 CY32 CY43 CY56 Northern Line

DN280 DN283 CY12 CY14 CY15CY15 CY19 CY25 CY27 CY29 CY33 CY52 4 Tara Street Pearse Grand Canal Dock 5 30 km/h DC425 DC436 50 km/h CY36 CY48 CY91

CY76 CY78 CY87 CY92 CY94 DC408 DC411 DC414 DC416 DC419 DC424 DC429 DC434 DC443 DC448 DC451 Drumcondra North Strand Junction 6 7 DC449 50 km/h Glasnevin Junction CY77 CY79 CY88 CY93 CY95 DC406 DC409 DC412 DC415 DC417 DC422 DC427 DC432 DC441 CW22 CWR26 CW26 CW28 CW32 CY74

DC439 DC444 HN338 CW25 CWR25 CW27 CW31 CY75

30 km/h Ashtown Broombridge Docklands Station

CL105 CL102 CW52 CW56 DS106 DS104

CL104 CL103 CW51 CW53 CW54 CW55 CW58 DS108 DS103 50 km/h 30 km/h 15 km/h

HN272 HN331 DS107 CY82

HN271 HN332 HN336

HN288 30 km/h 160 km/h 10 95 km/h HN318 Park West Station 110 km/h 8 7 HN286 HN299 HN317

HK112 HK108 HN316 Island Bridge Junction 6 HK110 HK106 5 HN315 95 km/h 30 km/h

HN314 Depot HK109 HK105 HN237 HN241 HN243 HN253 HN256 4 Heuston 3 HK111 HK107 HK101 HN242 HN244 HN254 HN257 HN266 HN277 HN313

HN239 HN246HN246 HN255 HN265 HN276 HN312 110 km/h HN258 Inchicore 2 95 km/h 2,312 HN311 30 km/h 160 km/h 1

Figure 15: Infrastructure of Dublin area visualized using OpenTrack tool

For this case study, the area between Connolly station and Grand Canal Dock (Figure 16) has been chosen as a test maintenance area for the application of the optimisation algorithm. Case study includes closure of one track between two cross-overs on a double track section due to some planned maintenance. This case study represents an expansion

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

of the Kronecker algebra application used on the Boyne Viaduct single track line already described in details in the previous chapter. While working on a double track line, all traffic has to run over the remaining track, where typically a slow speed zone has to be established to protect the working staff. For this bottleneck section, it is of great importance to make efficient usage of available capacity.

Figure 16: Test maintenance area Connolly - Grand Canal Dock (using OpenTrack for visualization)

Figure 17: Test maintenance area including the track sections

In the interests of readability, the trains travelling on working days are grouped as follows: a) 06:00 – 08:00 b) 08:00 – 10:00 c) 10:00 – 12:00

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Schedule: Group A

Schedule DUBLIN Connolly – DUBLIN Pearse

These trains use the following track sections:

72, 68, 66, 64, 62, 60, 58, 56, 54, 52, 50, 48, 46, 44, 42, 40, 38, 36, 34, 32

Table 7: Timetable from Dublin Connolly to Dublin Pearse for T1, T3, T4, T6, T7, T9 and T10

T1 T3 T4 T6 T7 T9 T10 DUBLIN Arr 06:29 06:54 06:58 07:01 07:06 Connolly DUBLIN Dep 06:10 06:25 06:30 96:55 06:59 07:03 07:07 Connolly Tara Dep 06:13 06:28 06:33 06:58 07:02 07:06 07:09 Street DUBLIN Arr 06:14 06:29 06:34 06:59 07:03 07:08 07:12 Pearse

Table 8: Timetable from Dublin Connolly to Dublin Pearse for T12, T14, T15, T17, T19, T20 and T22

T12 T14 T15 T17 T19 T20 T22 DUBLIN Arr 07:09 07:24 07:26 07:30 07:36 07:39 07:45 Connolly DUBLIN Dep 07:11 07:25 07:27 07:31 07:37 07:41 07:46 Connolly Tara Dep 07:15 07:28 07:30 07:34 07:40 07:45 07:49 Street DUBLIN Arr 07:16 07:29 07:33 07:36 07:42 07:46 07:51 Pearse

Table 9: Timetable from Dublin Connolly to Dublin Pearse for T24, T26 and T29

T24 T26 T29 DUBLIN Arr 07:50 07:54 07:59 Connolly DUBLIN Dep 07:51 07:55 08:00 Connolly Tara Dep 07:54 07:59 08:03 Street DUBLIN Arr 07:58 08:00 08:05 Pearse

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Schedule DUBLIN Pearse – DUBLIN Connolly

These trains use the following track sections:

35, 37, 39, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63, 65, 67, 69, 71, 73

Table 10: Timetable from Dublin Pearse to Dublin Connolly for T2, T5, T8, T11, T13, T16 and T18

T2 T5 T8 T11 T13 T16 T18 DUBLIN Dep 06:19 06:49 06:59 07:09 07:17 07:27 07:34 Pearse Tara Dep 06:21 06:51 07:01 07:11 07:19 07:29 07:36 Street DUBLIN Arr 06:24 06:54 07:04 07:15 07:22 07:32 07:39 Connolly DUBLIN Dep 06:24 06:54 07:04 07:15 07:23 07:33 07:39 Connolly

Table 11: Timetable from Dublin Pearse to Dublin Connolly for T21, T23, T25, T27, and T28

T21 T23 T25 T27 T28 DUBLIN Dep 07:39 07:49 07:51 07:54 07:58 Pearse Tara Dep 07:41 07:51 07:53 07:56 08:01 Street DUBLIN Arr 07:46 07:54 07:56 07:59 08:06 Connolly DUBLIN Dep 07:54 07:57 08:00 08:08 Connolly

Table 12: Energy consumption before and after optimization process from Dublin Pearse to Dublin Connolly

Total energy consumption (including 89,9 kWh recuperative braking) without optimization (“hold strategy”):

Total energy consumption (including 68,5 kWh recuperative braking) with optimization:

Savings ~ 24 %

Figure 18 shows the results of the simulation between 06:00 and 08:00 AM.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 18: Train graph including blocking time stairway between Dublin Pearse and Dublin Connolly for the schedule group A

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Typical driving strategy DUBLIN Connolly – DUBLIN Pearse

Table 13: Typical driving strategy from Dublin Connolly to Dublin Pearse

Start Start Hold Hold Coast Coast Brake Brake End End Pos. Speed Pos. Speed Pos. Speed Pos. Speed Pos. Speed

2308 0 2258 30 1901 30 1901 30 1901 30

1901 30 1901 30 1436 30 1434 30 1384 0

1384 0 1334 30 1332 30 815 24 780 0

Figure 19: Speed-Distance diagram showing optimal driving strategy from Dublin Connolly to Dublin Pearse

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Typical driving strategy DUBLIN Pearse – DUBLIN Connolly

Table 14: Typical driving strategy from Dublin Pearse to Dublin Connolly

Start Start Hold Hold Coast Coast Brake Brake End End Pos. Speed Pos. Speed Pos. Speed Pos. Speed Pos. Speed

950 0 1001 30 1002 30 1476 25 1514 0

1514 0 1563 30 1635 30 2471 20 2496 0

Figure 20: Speed-Distance diagram showing optimal driving strategy from Dublin Pearse to Dublin Connolly

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Schedule Group B

Schedule DUBLIN Connolly – DUBLIN Pearse

Table 15: Timetable from Dublin Connolly to Dublin Pearse for T2, T3, T4, T6, T8, T10 and T12

T2 T3 T4 T6 T8 T10 T12 DUBLIN Arr 08:04 08:09 08:12 08:14 08:18 08:26 08:31 Connolly DUBLIN Dep 08:06 08:10 08:13 08:15 08:19 08:27 08:32 Connolly Tara Dep 08:09 08:13 08:16 08:19 08:22 08:30 08:35 Street DUBLIN Arr 08:10 08:14 08:18 08:21 08:25 08:31 08:36 Pearse

Table 16: Timetable from Dublin Connolly to Dublin Pearse for T14, T15, T17, T18, T20, T21 and T23

T14 T15 T17 T18 T20 T21 T23 DUBLIN Arr 08:35 08:39 08:43 08:49 08:51 08:55 08:58 Connolly DUBLIN Dep 08:37 08:41 08:45 08:50 08:53 08:57 09:00 Connolly Tara Dep 08:40 08:44 08:48 08:53 08:56 09:00 09:02 Street DUBLIN Arr 08:42 08:46 08:50 08:55 08:57 09:01 09:06 Pearse

Table 17: Timetable from Dublin Connolly to Dublin Pearse for T24, T26, T28, T31, T32, T35 and T36

T24 T26 T28 T31 T32 T35 T36 DUBLIN Arr 09:04 09:09 09:12 09:25 09:30 09:42 Connolly DUBLIN Dep 09:05 09:10 09:13 09:26 09:31 09:40 09:44 Connolly Tara Dep 09:08 09:13 09:16 09:29 09:34 09:43 09:48 Street DUBLIN Arr 09:10 09:14 09:18 09:30 09:36 09:45 09:49 Pearse

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Table 18: Timetable from Dublin Connolly to Dublin Pearse for T38 and T39

T38 T39 DUBLIN Arr 09:50 09:54 Connolly DUBLIN Dep 09:51 09:57 Connolly Tara Dep 09:53 10:00 Street DUBLIN Arr 09:56 10:01 Pearse

Schedule DUBLIN Pearse – DUBLIN Connolly

Table 19: Timetable from Dublin Pearse to Dublin Connolly for T1, T5, T7, T9, T11, T13 and T16

T1 T5 T7 T9 T11 T13 T16 DUBLIN Dep 08:02 08:13 08:17 08:22 08:26 08:31 08:39 Pearse Tara Dep 08:04 08:15 08:19 08:24 08:28 08:34 08:42 Street DUBLIN Arr 08:07 08:18 08:23 08:28 08:31 08:37 08:46 Connolly DUBLIN Dep 08:08 08:19 08:24 08:28 08:39 08:47 Connolly

Table 20: Timetable from Dublin Pearse to Dublin Connolly for T19, T22, T25, T27, T29, T30 and T33

T19 T22 T25 T27 T29 T30 T33 DUBLIN Dep 08:50 08:57 09:04 09:10 09:17 09:24 09:35 Pearse Tara Dep 08:52 08:59 09:06 09:12 09:19 09:26 09:37 Street DUBLIN Arr 08:55 09:02 09:09 09:16 09:22 09:29 09:40 Connolly DUBLIN Dep 08:55 09:09 09:16 09:23 09:41 Connolly

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Table 21: Timetable from Dublin Pearse to Dublin Connolly for T34 and T37

T34 T37 DUBLIN Dep 09:38 09:49 Pearse Tara Dep 09:41 09:51 Street DUBLIN Arr 09:44 09:54 Connolly DUBLIN Dep 09:54 Connolly

Table 22: Energy consumption before and after optimization process between Dublin Pears and Dublin Connolly for the schedule group B

Total energy consumption (including 121 kWh recuperative braking) without optimization (“hold strategy”):

Total energy consumption (including 92 kWh recuperative braking) with optimization:

Savings ~ 24 %

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 21: Train graph including blocking time stairway between Dublin Pearse and Dublin Connolly for the schedule group B

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Schedule Group C

Schedule DUBLIN Connolly – DUBLIN Pearse

Table 23: Timetable from Dublin Connolly to Dublin Pearse for T2, T5, T7, T8, T10, T11 and T14

T2 T5 T7 T8 T10 T11 T14 DUBLIN Arr 10:04 10:09 10:23 10:26 10:35 10:39 10:54 Connolly DUBLIN Dep 10:05 10:10 10:23 10:29 10:37 10:40 10:55 Connolly Tara Dep 10:08 10:13 10:26 10:32 10:40 10:44 10:58 Street DUBLIN Arr 10:10 10:14 10:28 10:33 10:43 10:45 10:59 Pearse

Table 24: Timetable from Dublin Connolly to Dublin Pearse for T15, T17, T20, T21, T23, and T26

T15 T17 T20 T21 T23 T26 DUBLIN Arr 10:57 11:09 11:20 11:26 11:39 11:54 Connolly DUBLIN Dep 10:59 11:10 11:21 11:27 11:40 11:55 Connolly Tara Dep 11:01 11:13 11:23 11:30 11:43 11:58 Street DUBLIN Arr 11:04 11:14 11:26 11:31 11:44 11:59 Pearse

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Schedule DUBLIN Pearse – DUBLIN Connolly

Table 25: Timetable from Dublin Pearse to Dublin Connolly for T1, T3, T4, T6, T9, T12 and T13

T1 T3 T4 T6 T9 T12 T13 DUBLIN Dep 10:00 10:04 10:08 10:19 10:34 10:40 10:47 Pearse Tara Dep 10:02 10:06 10:10 10:21 10:36 10:42 10:49 Street DUBLIN Arr 10:06 10:09 10:15 10:24 10:39 10:46 10:52 Connolly DUBLIN Dep 10:06 10:09 10:24 10:39 10:46 10:53 Connolly

Table 26: Timetable from Dublin Pearse to Dublin Connolly for T16, T18, T19, T22, T24, and T25

T16 T18 T19 T22 T24 T25 DUBLIN Dep 11:04 11:10 11:19 11:34 11:40 11:49 Pearse Tara Dep 11:06 11:13 11:21 11:36 11:42 11:51 Street DUBLIN Arr 11:09 11:16 11:24 11:39 11:46 11:54 Connolly DUBLIN Dep 11:09 11:17 11:24 11:39 11:46 11:54 Connolly

Table 27: Energy consumption before and after optimization process from Dublin Pears to Dublin Connolly

Total energy consumption (including 77 kWh recuperative braking) without optimization (“hold strategy”):

Total energy consumption (including 61 kWh recuperative braking) with optimization:

Savings ~ 21 %

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 22: Train graph including blocking time stairway between Dublin Pearse and Dublin Connolly for the schedule group C

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Construction Area at track section 56

If a construction area between the stations DUBLIN Connolly and Tara Street is assumed, track section 56 (for example) will not be available. As a result, trains must be synchronized on their access on common-used track sections. Trains from DUBLIN Connolly now will use track section 60 and 61 to drive to the other track, use section 51 at the right track at Tara Street and go back on the left track via section 47 and 44.

There are now two possibilities to hold the schedule or to have the smallest possible delays; this is explained using trains T17 and T18, shown in the figure 23.

1. T17 will leave track section 47 before T18 enters it 2. T18 will leave track section 61 before T17 enters it

Figure 23: Train graph including blocking time stairway between Dublin Pearse and Dublin Connolly for the trains T17 and T18 with construction work on the track 56

The above figure shows the result of the synchronization of these two trains, where T17 will use the common track sections first, followed by T18 (first strategy mentioned above). It must be mentioned that it is possible only when their timetable is adapted in the following way:

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Table 28: Original and adapted timetable for the train T17

T17 T17 (Original) (Modified) DUBLIN Arr 11:09 11:09:00 Connolly DUBLIN Dep 11:10 11:10:00 Connolly Tara Dep 11:13 11:12:20 Street DUBLIN Arr 11:14 11:13:30 Pearse

Table 29: Original and adapted timetable for the train T18

T18 T18 (Original) (Modified) DUBLIN Dep 11:10 11:10:00 Pearse Tara Dep 11:13 11:14:00 Street DUBLIN Arr 11:16 11:16:35 Connolly DUBLIN Dep 11:17 11:17:05 Connolly

At each station, the train will stay for 30 seconds. With these assumptions, it is possible for to run both trains without any delay. Due to the different driving strategies, the energy consumption is higher for both trains. The following table gives an overview of the energy consumption.

Table 30: Comparison of energy consumption during original and modified timetable for trains T17 and T18

T17 T17 T18 T18 (original) (modified) (original) (modified)

Connolly – 1,534 kWh 1,739 kWh Pearse – 0,905 kWh 1,051 kWh Tara Street Tara Street

Tara Street - 0,947 kWh 1,347 kWh Tara Street - 1,347 kWh 1,624 kWh Pearse Connolly

Overall 2,481 kWh 3,086 kWh Overall 2,292 kWh 2,675 kWh

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Due to the construction area and the modified schedule, about 20 % more traction energy is necessary, but both trains will not have any delay at their second stations and thus, no impact on other trains. The driving strategies for both trains are illustrated in Figure 24 and Figure 25.

Figure 24: Speed-Distance diagram showing optimal driving strategy for the train T17

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 25: Speed-Distance diagram showing optimal driving strategy for the train T18

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

The situation with the trains T19 and T20 opposite to the above is described. The strategy will be to have train T19 use the common track sections before train T20.

Due to the reservation of several track sections, it is not possible for train T20 to start before T19 leaves section 61. Therefore, T20 has to wait at station Dublin Connolly before starting. Due to an in-built reserve in the timetable, again, the schedule is not violated even if both trains have to use the same track between Dublin Connolly and Tara Street. The only impact is the arrival of train T20 10 seconds later than in the original timetable. This is due to the fact, that Dublin Pearse is the last station of its journey, these 10 seconds might not be a problem. On the other hand, 10 seconds can be gained again before the arrival at the next station, due to the reserve in the travel time between two stations. The results are given in Figure 26.

Figure 26: Train graph including block time stairway between Dublin Pearse and Dublin Connolly for the trains T19 and T20

As already mentioned, the travel time for both trains was adapted (especially T19 will be faster) and therefore, the maximum speed was higher than before for both trains. That leads to an energy consumption being more than 40% higher. The driving strategies are illustrated in the following Figure 27 and Figure 28.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 27: Speed-Distance diagram showing optimal driving strategy for the train T20

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

Figure 28: Speed-Distance diagram showing optimal driving strategy for the train T19

Obviously, most of the time, it is possible that the trains will be on time at most of the stations, even when there is construction area on one track. However, some adaptions of the schedule and a higher amount of traction energy is necessary.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

6 Summary and Conclusions

The application of Kronecker Algebra for traffic flow modelling during maintenance work on infrastructure assets has demonstrated that significant improves can be achieved in terms of punctuality and energy consumption for rail networks. The Dublin case study revealed potential savings of up to 24 % in terms of traction energy, which is a fact usually neglected in optimal solution searching processes. Current practice lies somewhere between a hold strategy and an optimised one. However, a systematic approach has the potential to results in additional savings. Of course, if one timetable does not offer any reserves in running time, punctuality cannot be guaranteed during maintenance work and energy saving may not be a priority.

The presented methodology offers the opportunity for an infrastructure manager to easily compare different scenarios for maintenance work. However, for the output data to reflect reality, input data has to have a high level of accuracy. Only then can the infrastructure manager rely on this methodology and the results of the whole decision support tool.

For real time application, a bidirectional interface to traffic management systems is required, as it has already been the case in the microscopic simulation of railway operations.

D4.2 Report on Traffic Flow Model DESTination RAIL – Decision Support Tool for Rail Infrastructure Managers

References

1. RailML: 2. OpenTrack Ralway Technology GmbH: 3. Mark Volcic, Energy-efficient Optimization of Railway Operation. An Algorithm based on Kronecker Algebra. 2014, Phd-thesis. Vienna, Austria. 4. Daniel Hürlimann. OpenTrack Manual, 2013. 5. Joern Pachl and Thomas White. Analytical capacity management with blocking times. In Transportation Research Board. 83rd Annual Meeting, Jan 2004. 6. Jörn Pachl. Timetable Design Principles. In Ingo A. Hansen, Jörn Pachl, and Thomas Albrecht, editors, Railway, Timetable & Traffic: Analysis, Modelling, Simulation, pages 9– 42. Eurailpress, Hamburg,Germany, 1 edition, 2008.