Tesi magistrale Martino Marangon

University of TriesteDepartment of Engineering and Architecture

Master Degree in Computer Engineering

Master StudentMARTINO MARANGON

Analysis of the impact of speed variation dynamics on the optimization ofthe real-time railway traffic management problem

SUPERVISOR CO-SUPERVISOR

Lorenzo Castelli Paola Pellegrini

ACADEMIC YEAR 2014/2015

A Mamma e PapàCon quello che avevano

Mi hanno dato tutto

ABSTRACT

I servizi ferroviari sono pianificati in dettaglio definendo, con diversi mesi di anticipo,l’orario e l’ordine dei treni in punti chiave della rete ferroviaria, quali stazioni,scambi e passaggi a livello. Anche se gli orari dei treni vengono pensati e program-

mati in modo da far fronte a piccoli ritardi, problemi tecnici lungo la linea potrebberoinfluenzare la regolare circolazione dei treni. Questi problemi potrebbero causare ritardie indisponibilità di certe parti della linea ferroviaria. A causa dell’interazione tra treni,i ritardi potrebbero propagarsi lungo l’intera rete ferroviaria, generandone a catena.La gestione del problema del traffico ferroviario in tempo reale affronta queste situ-azioni: consiste nel scegliere il percorso e l’orario dei treni con lo scopo di minimizzare lapropagazione di questi ritardi. È un processo complicato che richiede soluzioni efficaciin pochi minuti. A causa di questi limiti di tempo, i dirigenti centrali (coloro ai qualiè affidato il compito di ottimizzare la circolazione dei treni) solitamente eseguono lemodifiche basandosi sulla loro esperienza; spesso l’efficienza delle misure intrapreseè di difficile previsione. Per questo motivo, lo sviluppo di modelli e programmi deci-sionali di supporto in tempo reale potrebbe aiutarli nella gestione dell’infrastruttura,migliorandone l’efficienza.

Adottiamo una classificazione dei modelli di approccio al problema della gestione deltraffico in tempo reale divisa in due classi: modelli a velocità fissa (fixed-speed models)e modelli a velocità variabile (variable-speed models). Nei modelli a veloctà fissa ilprofilo di velocità di un treno resta attinente a quello programmato: nel caso in cui siverifichi un conflitto, non vengono tenute in considerazione le conseguenze delle fasi diaccelerazione e frenata. Nei modelli a velocità variabile, il profilo di velocità di un trenoviene aggiornato in modo da includere le conseguenze di possibili conflitti a causa divincoli imposti dal sistema di segnalazione. I modelli a velocità variabile sono più completied accurati, tuttavia sono i meno utilizzati in quanto sono difficili da risolvere in tempibrevi di computazione. In questa tesi verranno presentati due algoritmi per la gestionedel traffico in tempo reale: ROMA e RECIFE-MILP, concentrandoci particolarmentesull’ultimo. RECIFE-MILP affronta il problema basandosi sui modelli a velocità fissa.

Lo scopo di questa tesi è lo sviluppo di un programma a velocità variabile che possaessere utilizzato per valutare le soluzioni ai conflitti calcolate da algoritmi che operanoin velocità fissa. Dato uno scenario perturbato (l’ammontare di ritardo di cui i trenisoffrono alla loro entrata nell’infrastruttura), il programma verifica la presenza di con-filitti e, nel caso si verifichino, li risolve basandosi sulle soluzioni calcolate da un datoalgoritmo a velocità fissa e tenendo in considerazione le conseguenze delle fasi di fre-

iii

nata ed accelerazione. Di fianco a ciò, ci siamo posti altri due obiettivi. Il primo è losviluppo di un programma avente lo scopo di raccogliere ed ordinare molteplici dati,inerenti l’infrastruttura ferroviaria ed il rolling stock dei treni. Questi dati, provenientida diversi file, vengono successivamente organizzati in una struttura standardizzata,chiamata RECIFE Data Structure. Il secondo obiettivo riguarda lo sviluppo di un pro-gramma per calcolare il tempo di marcia (running time) dei treni. Date informazionisull’infrastruttura e dettagli del rolling stock, vengono calcolate le resistenze che untreno affronta lungo il percorso e viene determinato quando e dove il treno si trova in fasedi accelerazione, frenata e velocità costante. Usando i dati precedentemente calcolati,viene calcolato il tempo di marcia per ogni circuito di binario (track circuit) e per l’interopercorso del treno.

Al fine di valutare la qualità dei risultati ottenuti dai nostri programmi, li abbiamoconfrontati con un software di simulazione ferroviaria (OpenTrack). Per l’esecuzionedegli esperimenti, sono state prima modellate e poi utilizzate due infrastrutture: il nododi Pierrefitte-Gonesse ed il nodo tra Rosny-sur-Seine e Saint-Etienne-du-Rouvray. Perentrambe le infrastrutture i risultati ottenuti sono stati incoraggianti: in tutti i casistudiati, la differenza media del tempo di marcia calcolato dal nostro programma e daOpenTrack è stata intorno o inferiore al secondo lungo l’intera linea. Il programmasviluppato è caratterizzato da un altro punto di forza: ha un’elevata flessibilità. Essoinfatti può essere facilmente modificato in modo da includere maggiori variabili, quali lecondizioni del meteo o il comportamento dei macchinisti, in modo da rendere il calcolodel tempo di marcia più attinente alla realtà.

Si è completato un primo sviluppo del programma per valutare le soluzioni calcolateda algoritmi che operano in velocità fissa. In tutti gli esperimenti eseguiti, il programmaè riuscito a risolvere i conflitti tra treni tenendo in considerazione le conseguenze dellefasi di frenata ed accelerazione. Tuttavia, in alcuni scenari, i risultati ottenuti non sisono rivelati ottimali se comparati con il software Opentrack: per questi casi, purtroppo,non si è riusciti a svolgere un’analisi approfondita al fine di capire la natura degli errorie apportare opportune correzioni.

iv

ACKNOWLEDGEMENTS

I l primo pensiero è rivolto a Mamma e Papà, a cui questa tesi è dedicata, per avermisempre sostenuto sia moralmente sia economicamente in tutti questi anni di uni-versità e in quest’ultima avventura.

Un pensiero ed un grazie enorme è rivolto ad Annika. Grazie di cuore per avermisempre sopportato e supportato in tutti i momenti tristi e felici passati in questi mesi. Iltuo aiuto nel portare a termine questa avventura è stato prezioso e difficile da misurare:questa tesi è dedicata anche a te.

Ringrazio molte Lorenzo per avermi concesso l’opportunità di svolgere questa tesi aLille e Paola per avermi seguito e aiutato molto in tutti questi mesi. Assieme a loro,ringrazio tutte le persone conosciute all’IFSTTAR, con particolare pensiero a Diego,Kaba, Joaquin, Grégory e Sonia.

Un grazie speciale va agli amici conosciuti a Lille, con cui ho condiviso momenti fe-lici e bellissime esperienze: Adil, Anja, Bogdan, Jakob, Katharina, Pierre e Spela.

Ringrazio tutti i parenti, vicini e lontani, per avermi sempre incoraggiato a dare ilmeglio. In particolare, ringrazio mio cugino Stefano (Rotti) per tutti gli anni felici passatiassieme. Un grazie di cuore alle mie due zie Agnese e Roberta, per aver sempre credutoin me e per avermi sempre incoraggiato, al buon vecchio zio Marino, a Carlo, Elisa (Elsa)e Teresa, a zia Teresina e zio Ervino (Madi), a Filippo, Elena e PierPaolo, a Elisabetta(Betty), Giacomo e Luca.

In ultimo, ma non meno importanti, ringrazio i coinquilini, i colleghi di universitàe tutti gli amici di Trieste e Udine. Sperando di non dimenticare nessuno, ringrazioAndrea (Padu), Andrea (White), Anna (DJhonny), Arianna (La Riccia), Besian (Leone),Christian, Davide (Bottox), Danile (Bolliii), Delchi, Denisa, Dennis (Telegram), Diego,Erik (La Boba), Erlis, Fabio (Scoiattolo), Francesca (AZ Casa), Francesco (Puffo), Fabio(Alce), Filip, Giulia, Giovanni (Il Grinta), Leonardo (L’Orso), Luca (Dellino), Marco (Om-bre), Orion, Orsola (Toti), Paolo (Paolino), Paolo (Paul), Pietro (Pieroooooooo), Rachele(Il Male), Rocco (Pio), Ruggero (Merenda), Stefano (Stefanin), Stefano (Pac), Stefano(Winky), Stefano (Ceno) e Stefano (Kompre).

v

TABLE OF CONTENTS

Page

List of Tables ix

List of Figures xi

1 Introduction 11.1 Motivation of the study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objective of the study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 An Overview on Railway and Traffic Management 72.1 Railway Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Block Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.4 Modelling The Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Timetable Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Traffic Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Blocking Time Stairway . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Real-Time Traffic Management . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Train Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Objective function and constraints . . . . . . . . . . . . . . . . . . . . 18

2.3.3 Modelling real-time traffic management problem . . . . . . . . . . . 19

2.4 OpenTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1 Structure of OpenTrack . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Modelling Infrastructure And Rolling Stock 25

vii

TABLE OF CONTENTS

3.1 RECIFE Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 RECIFE Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Generation of Infrastructure and Rolling Stock . . . . . . . . . . . . . . . . 28

3.3 Infrastructure Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Pierrefitte - Gonesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.2 Rosny sur Seine - St. Etienne du Rouvray . . . . . . . . . . . . . . . 31

4 Running Time Computation 334.1 Traction Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 Rolling Stock Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.2 Distance Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Running Time Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Moving Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Braking section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.3 Acceleration section . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.4 Constant Speed Section . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Running Time Computation Program . . . . . . . . . . . . . . . . . . . . . . 41

4.3.1 Comparison with OpenTrack . . . . . . . . . . . . . . . . . . . . . . . 43

5 Running Time Computation with Traffic 495.1 Running Time Computation with Traffic Program . . . . . . . . . . . . . . . 49

5.2 Running Time Computation with Traffic Program Example . . . . . . . . . 52

6 Conclusions 576.1 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Bibliography 61

viii

LIST OF TABLES

TABLE Page

3.1 Execution time (in second) to generate Infrastrucure.xml and RollingStock.xml

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Execution time (in minutes and seconds) to compute running times . . . . . . 43

4.2 Differences between our program and OpenTrack - 1 second step for OpenTrack 44

4.3 Differences between our program and OpenTrack - 0.1 second step for Open-

Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Length (in meters) of the route and running time (in seconds) in absence of

traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Running Times (in seconds) - TGVa has the priority . . . . . . . . . . . . . . . 54

5.3 Running Times (in seconds) - TGVb has the priority . . . . . . . . . . . . . . . 55

ix

LIST OF FIGURES

FIGURE Page

1.1 Example of fixed speed model - speed vs distance diagram . . . . . . . . . . . . 3

1.2 Example of variable speed model - speed vs distance diagram . . . . . . . . . . 3

2.1 Representation of block sections with track circuits and entrance/exit signals 8

2.2 Example of different kinds of light signals (Pachl, 2002) . . . . . . . . . . . . . 9

2.3 Blocking Time of a Block Section (Hansen and Pachl, 2008) . . . . . . . . . . . 11

2.4 Microscopic and Macroscopic Model (Hansen and Pachl, 2008) . . . . . . . . . 13

2.5 Example of Traffic Diagram (Hansen and Pachl, 2008) . . . . . . . . . . . . . . 15

2.6 Blocking Time Stairways Diagram (Hansen and Pachl, 2008) . . . . . . . . . . 16

2.7 Modules of the simulation process (Huerlimann and Nash, 2010) . . . . . . . . 21

3.1 Generating Infrastrucure and RollingStock program . . . . . . . . . . . . . . . 29

3.2 Circulation schema in the node of Pierrefitte-Gonesse . . . . . . . . . . . . . . 30

3.3 Node of Pierrefitte-Gonesse (Rodriguez, 2007) . . . . . . . . . . . . . . . . . . . 31

3.4 Node between Rosny sur Seine and St. Etienne du Rouvray (Pellegrini et al.,

2015a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Gradient Resistance (Huerlimann and Nash, 2010) . . . . . . . . . . . . . . . . 35

4.2 Moving Sections (Hansen and Pachl, 2008) . . . . . . . . . . . . . . . . . . . . . 36

4.3 Braking Curves due to Speed Restriction (Hansen and Pachl, 2008) . . . . . . 37

4.4 Acceleration phase, maximum speed of the section is reached (Hansen and

Pachl, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Acceleration phase, exit speed is lower than maximum speed (Hansen and

Pachl, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6 Acceleration phase, intersection with braking curve . . . . . . . . . . . . . . . . 39

4.7 Running Time Computation Program . . . . . . . . . . . . . . . . . . . . . . . . 41

xi

LIST OF FIGURES

4.8 Visual comparison between OpenTrack and our program, Pierrefitte-Gonesse

node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.9 Visual comparison between OpenTrack and our program, Rosny sur Seine -

St. Etienne du Rouvray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1 Running Time Estimation Program with Traffic . . . . . . . . . . . . . . . . . . 50

5.2 Speed-distance diagram in absence of traffic . . . . . . . . . . . . . . . . . . . . 52

5.3 Conflict situation - Blocking Time Stairways Diagram for TGVa . . . . . . . . 53

5.4 Conflict situation - Blocking Time Stairways Diagram for TGVb . . . . . . . . 53

5.5 Conflict solved - TGVa has the priority - Blocking Time Stairways Diagram . 54

5.6 Conflict solved - TGVa has the priority - Distance vs speed diagram . . . . . . 55

5.7 Conflict solved - TGVb has the priority - Distance vs speed diagram . . . . . . 56

5.8 Conflict solved - TGVb has the priority - Blocking Time Stairways Diagram . 56

xii

CH

AP

TE

R

1INTRODUCTION

1.1 Motivation of the study

Train services are planned in details, and several months in advance the train

timing and order in tracks key points, such as platforms, crossing and junctions,

are defined. Even if the timetable is developed in order to deal with minor pertur-

bations (i.e., few minutes of delay), technical failures and disturbances may influence the

runs of the trains. Technical failures and disturbances could cause delayed trains or tem-

porary unavailability of some routes. Due to the interaction between trains, these delays

may propagate along the whole network generating knock-on delays. The real-time traffic

management problem deals with finding solutions to this kind of situations. It consist in

selecting the train routes and schedules in order to minimize the propagation of delays,

ensuring the feasibility of the resulting plan of the operations. This is a short term

problem that requires solutions within few minutes. Due to this short time limit, train

dispatchers usually perform manually only few modifications and often the efficiency of

the chosen measures remains unknown.

Several computerized dispatching support systems have been developed and in the

literature many tools for real-time traffic control are proposed. In D’Ariano (2008) a

variable-speed dispatching support system, called ROMA, is presented. The system

allows the interaction with human dispatcher by adding or removing constraints or

changing the timetable. In Pellegrini et al. (2015b) an heuristic algorithm based on a

mixed-integer linear programming model, called RECIFE-MILP, is introduced. It extends

1

CHAPTER 1. INTRODUCTION

a MILP formulation proposed in Pellegrini et al. (2014), describing the characteristics

of the infrastructure in deeper detail and boosting the performance of the solution

algorithm.

1.2 Objective of the study

The main objectives of this Thesis are the following:

1. Develop a program merging data contained in several files and organize them in a

XML standardized structure.

2. Using the outputs of the preceding program, develop a program computing running

times of trains travelling along different routes.

3. Develop a program that can be used to evaluate the solutions of the RECIFE-MILP

algorithm.

RECIFE-MILP tackles the real-time traffic management problem based on the fixed-

speed model. This means that, when a conflict arise, the possible consequences of braking

and acceleration are not taken into account. Rodriguez (2007) compares the solution

returned by an algorithm when considering either variable speed or fixed speed models.

According to Rodriguez (2007), the increase of precision of the variable speed model

does not pay off, because of the big additional computational effort to calculate speed

variations dynamics.

The objective of our thesis is to develop a program that can be used to assessing the

gap between a set of conflict solutions computed using the RECIFE-MILP algorithm

and the conflict solutions computed taking into account the consequences of braking and

acceleration phases. In particular, the goal is to evaluate the difference of the trains’ exit

time from the infrastructure. The figures 1.1 and 1.2 show the difference of approaches.

The train has to stop at the signal sc1045. The first figure presents a conflict solved with

a fixed speed model: the are no acceleration or braking phases. The second figures shows

a conflict resolved with the variable speed model marked by the presence of braking and

acceleration phases.

2

1.2. OBJECTIVE OF THE STUDY

Figure 1.1: Example of fixed speed model - speed vs distance diagram

Figure 1.2: Example of variable speed model - speed vs distance diagram

3

CHAPTER 1. INTRODUCTION

1.3 Thesis Contribution

This Thesis includes several contributions to the field of real-time traffic management

problem, with the particular emphasis on conflict detection and the resolution process.

• The first contribution is the implementation of a program to manage different data

contained in several files. Given an infrastructure and several files describing it,

we developed a program that generates an unique well formatted XML file. This

file describes the infrastructure with a very high level of detail. We develop also a

program that generates an unique well formatted file concerning the rolling stock.

It can be used as the basis for the development of programs and algorithms also

not related to the traffic in real-time.

• The second contribution is the development of a program to estimate running

times with an high level of precision. High level of precision is crucial to detect

and resolve conflict in real-time. This program is also very flexible: it can be easily

modified in order to include more variables, e.g. the human behaviour of a train

driver.

• The third contribution is the development of a program that can be used to evaluate

the solutions of the heuristic algorithm RECIFE-MILP. In the event of conflict

resolution, the program takes into account the consequences of braking and accel-

eration phases.

1.4 Thesis Outline

This thesis has been split into three parts, according to the chapters’ contents: ModellingInfrastructure And Rolling Stock, Running Time Estimation and Running Time Esti-mation with Traffic. This Thesis is organized in six chapters, including this first one

introducing the Thesis, and the sixth one referring to the conclusions and future work.

Chapter 2 presents some notions about the railway network. We will see in which por-

tions a track is divided, the rules that govern traffic and we will talk about timetabling.

Then an introduction of real-time traffic management will be presented. At the end we

will present OpenTrack, a railway simulation program.

Chapter 3 introduces the RECIFE Project and the REFICE Data Structure. A description

4

1.4. THESIS OUTLINE

of the first program that we developed will follow. It generates two XML files according

to the RECIFE standard format: one file represents the infrastructure, the other one the

rolling stock. At the end we will present an overview of the infrastructures modelled.

Chapter 4 describes the data needed to estimate running times. We will talk about

the resistances that a train has to face along the route and we will see how to model run-

ning time calculations. We will continue presenting our second program which computes

running times according to given details about infrastructure and trains. At the end, a

comparison with OpenTrack will be reported.

Chapter 5 points out how to detect a conflict and how to resolve it. We will describe

the third program developed: it addresses the problem of computing running times in

presence of traffic. At the end an example of how our program work is reported.

Chapter 6 is dedicated to the conclusions and future work.

5

CH

AP

TE

R

2AN OVERVIEW ON RAILWAY AND TRAFFIC

MANAGEMENT

To improve railway service, real-time traffic management and timetable design

have been playing a key role for the last few decades. Real-time traffic man-

agement in railways aims to minimize delays after unexpected events perturb

the operations. Timetable design is the process of constructing a schedule from scratch.

Focusing on the real-time traffic management, it is important to underline the complexity

of this process. The complexity is due to time constraints: the time interval for computing

a solution is strictly limited. Develop real-time decision support tools can help traffic

controllers to manage infrastructure. Such tools can improve the trains punctuality and

help dispatchers to take dispatching actions.

The aim of this chapter is to give the reader an introduction of railway infrastructure,

timetable design and real-time traffic management problem. Starting with a description

of the infrastructure of a control area, we will see in detail in which parts a portion of a

track is divided focusing on the rules that govern traffic. We will continue explaining the

creation of timetables. Then, we will describe in detail the real-time traffic management

problem explaining its objective functions and constraints and we will see the modelling

approaches. In the end, we will present a railway simulation software called OpenTrack.

7

CHAPTER 2. AN OVERVIEW ON RAILWAY AND TRAFFIC MANAGEMENT

Figure 2.1: Representation of block sections with track circuits and entrance/exit signals

2.1 Railway Infrastructure

A railway is composed by stations and links. For safety reason, signals control the train

traffic along a line and impose a minimum distance between consecutive trains. Besides

the signals, Automatic Train Protection (ATP) is used to reach the same goal. Minimum

safety distance between two trains depends on the speed of the second train, the braking

rate of the second train and the length of the first train. ATP causes an automatic

braking if a train doesn’t respect the restrictions, e.g. passing a signal with red aspect or

exceeding the maximum speed limit.

A part of a railway network managed by one unique dispatcher is called control area.

2.1.1 Block Section

A block section is a portion of a track delimited by two main signals. It is divided in one

or more track circuits. A track circuit is a smaller portion of track where the presence of

a train is detected automatically. Different block sections may share one or more track

circuits. In figure 2.1, the block sections s1-s3 and s2-s3 share the track circuit tc5. When

the head of a train enters in the fist track circuit of a block section, all the following

ones belonging to the same block section are reserved to it. If a train uses a track circuit,

no other train can use it. For utilization we intend both physical occupation and prior

reservation. Again for for safety reason, only one train can use the same block section at

the same time. Before a train is allowed to use a block section, a certain period of time

has to be reserved for route formation and visibility distance of the signal: this time is

called formation time. When the tail of the train exits the block section, a certain interval

of time is needed before another train can use the same block section: this time is called

release time.

For defining the length of a block section, it is considered the train with worst

performance such as braking distance rate linked to mass, speed and length of the train.

8

2.1. RAILWAY INFRASTRUCTURE

Figure 2.2: Example of different kinds of light signals (Pachl, 2002)

The length of the block section is the distance needed for a complete stop, when travelling

at the maximum speed allowed and if the entrance signal has three aspects.

An ordered sequence of block sections, that links an origin-destination pair, forms a

route.

2.1.2 Signals

Along a line with lineside signals, train movements are governed by fixed signals installed

alongside the track. According to Pachl (2002), there are two main kinds of lineside

signals: semaphore signals and light signals. In a semaphore signals, the aspects are

given by the position of movable arms. They are used in old installations. On light signalsthe aspects are given by lights. In this thesis, when we talk about signals, we will always

refer to light signals. The figure 2.2 represents an example of different kinds of light

signals.

Signals are located at the beginning and at the end of every block section. A signal

indicates if a train may enter the block section behind it. A signal has a main feature: the

number of aspects. The aspects of a signal indicate to a train driver the behaviour that

has to be followed. A standard railway signalling system is characterized by 3-aspects

signals: aspect could be red, yellow or green. A red aspect means that the following block

section is used by another train so the train must reach a complete stop before the signal.

A yellow aspect means that the following block section is free, but the following one is

used by another train: the train has to decelerate and reach a complete stop before the

next signal (if the aspect of second signal remains red). A green aspect means that the

9


two following block sections are free: a train can proceed at designed speed.

Beside aspects, a signal is characterized by visibility distance. It is a measure of

the distance at which the signal can be clearly recognised and depends on the physical

characteristics of the line.

In addition we considered two more signal aspects: yellow flashing and green flashing.

A yellow flashing aspect means that the two following block sections are free, but the

third is in use: the signal has four aspects and the length of block sections is shorter. The

length is shorter because, in this case, a train has two block section available to reach a

complete stop. A green flashing aspect means that the three following block section are

free and the fourth is in use: the signal has five aspects and the length of block sections

is shorter. In addition, at the next signal the maximum speed allowed is 160 km/h.

In general, if n indicates the number of aspects of a signal, the following (n-2) block

sections are free if the aspect of every signal along the block sections considered is green.

2.1.3 Definitions

Before we move on, some definitions of relevant terms are given.

The Running Time is a fix amount of time that a train needs for travel along a

track circuit. The duration is calculated in absence of traffic and depends of physical

characteristic of the infrastructure.

The Blocking Time is the total time that a part of a track is reserved exclusively for a

train and is by consequence blocked to other trains. For a block section, the blocking time

of a train consist of the following time intervals (Hansen and Pachl, 2008) (Figure 2.3):

1. Time needed for clearing the signal

2. Time that a train driver needs to view clearly the aspect of the signal at the

entrance of the block section

3. Approach time: is the time between the signal that first indicates the behaviour to

follow and the signal at the entrance of the block section

4. Running Time for the block section

5. Time needed for clearing the block section

6. Release time: when a trains clears a block section, a certain interval of time is

needed before another train uses the same block section

10

2.1. RAILWAY INFRASTRUCTURE

Figure 2.3: Blocking Time of a Block Section (Hansen and Pachl, 2008)

The Headway is the time interval between two consecutive trains. The MinimumHeadway Distance is the minimum distance allowed between two consecutive trains.

This minimum distance is imposed for safety reasons in order to allow the second train

to perform an emergency break, if needed. To evaluate it, some physical characteristics

of both trains are taken into account, e.g. braking rate of the second train, mass of the

second train, length of the first train and physical characteristics of the infrastructure.

The Interlocking is an arrangement of movable points and signals interconnected

in a way that each movement follows the other in a proper and safe sequence. The

Interlocking System is a control system of an area with interlocked points and signals.

2.1.4 Modelling The Infrastructure

This subsection is divided into two parts. In the first part we introduce the level of

infrastructure detail as macroscopic and microscopic models. In the second part we

consider the infrastructure modelled microscopically with two different granularities: in

terms of block sections and in terms of track circuits.

11


2.1.4.1 Macroscopic and microscopic models

According to Hansen and Pachl (2008), for modelling a railway infrastructure, usually

structures derived from graph theory are used. Graph models are very flexibility and

therefore are a powerful mean to describe even the most complex railway infrastructure

(Hauptmann, 2000), (Radtke and Watson, 2007). In a graph model, the infrastructure is

separated into pieces (called links). These links are joined by nodes. We present some

definitions. A node (or vertex) represents a location in a railway network. A link (or edge)

has the function to connect two nodes. There are three levels of infrastructure details

(Hansen and Pachl, 2008):

Microscopic model This model contains the highest possible level of detail on nodes

and link. Track information, such as speed, gradient or radius, are combined with

the signalling system and some operational informations. A link holds information

about length, maximum speeds, gradient and curves. In general, this model is used

for exact running time calculation, timetable construction, conflict detection and

resolution.

Macroscopic model This model contains aggregated information on nodes and links.

It contains far less links and nodes than the microscopic model (figure 2.4). It

also has a more abstract view of the infrastructure. A typical macroscopic node

represents a station or a junction. A link may hold informations about length, type

of line, average running time. In general, the use of this model is preferred for long

term planning task or special routing problems.

2.1.4.2 Granularity of the microscopic model

Two main possibilities are considered for representing infrastructure microscopically: in

terms of block sections or in terms of track circuits. If the infrastructure is modelled in

terms of block sections, the only information available is the presence of the train in a

given block section: no information about the exact position of the train after it passed

the entrance signal is considered. In this case, if a train uses a track circuit tc, the block

section that includes tc cannot be used by another train and also all the block sections

that are sharing tc with the block section bs cannot be used. Concerning interlocking

systems (Theeg et al., 2009), we have only the system route-lock route-release. In case of

route release, block sections are released when the tail of the train has cleared the last

track circuit of the block section bs.

12

2.2. TIMETABLE DESIGN

Figure 2.4: Microscopic and Macroscopic Model (Hansen and Pachl, 2008)

If the infrastructure is modelled in terms of track circuits the information available

is the presence of a train in a certain track circuit. In this case we can have both route-

lock route-release and route-lock sectional-release systems. In case of sectional release,

block sections are released one at a time as the tail of the current train has cleared it.

Concerning the route-lock sectional-release system, when a train uses a track circuit tc,

only the block section that includes tc itself cannot be used by another train.

2.2 Timetable Design

The timetable design problem is usually a long procedure that requires several months,

including negotiations among a whole range of different stakeholders. It is a complex

problem and a compromise between capacity utilization and robustness has to be reached

(Carey and Kwiec, 1995), (Wendler, 2001), (Barter, 2004).

Timetables are generated by taking into account the following variables: the route

of trains, their corresponding start and end location, designed station stops, by the

sequence of track elements to be used by each train and when each part of the track will

be occupied. Usually, time reserves are inserted in the timetable (e.g. a few minutes of

delay) with the purpose to reduce the effects of small perturbations. It is important to

notice that large time reserves increase the punctuality of trains but reduce the capacity

of the line. For capacity of the line we intend the number of trains that can run through

13


a line in a certain period of time. Robust and reliable timetable should be able to face

small delays.

We can distinguish between two kinds of timetables (Hansen and Pachl, 2008).

Public Timetables. These timetables are available to passengers and are exhibited in

every station. For every train they contain the number of platform on which the

train is supposed to depart. In addition they contain the maximum time at which

the train arrives in the station and the minimum departure time from the station.

Opearational Timetables. This kind of timetables is not available to passengers. For

every train, it contains the arrival and the departure time. In additions it contains

the trains passing order in determinate points of interest along the track, e.g.

junctions or entrances of a block sections. It contains as well the sequence of

segments along the line used by every train, including passing time.

Timetables can also have another characteristic: they can be designed as cyclic. This

means that the trains operate with regularity respect to a certain amount of time called

cyclic time of a line. The cyclic time of a line denotes the interval of departure of trains

that are connected in the same direction. Usually this interval is one hour long. A cyclic

timetable could have the following properties:

• Synchronization: the departure of a train can be coordinated with the arrival of

others trains

• Symmetry: for every line exists another line that links the same stations but in the

reverse order

2.2.1 Traffic Diagrams

Traffic diagrams are mainly used as the basis of all planning of railway traffic. Another

function of traffic diagrams documents is the control of current operations. For describing

the amount of traffic on a line, a time-distance diagram is used. It consist out of two

axes: time axis and station axis (figure 2.5). There is a line parallel to the time axis at

every station. For representing movements of a train, its paths (oblique lines) along the

train description are used. At every intersection between train path and station lines, a

minute number represents the time when the intersection occurs. In a traffic diagram

the station axis may be represented on horizontal axis or on vertical axis: those different

representation have the same value.

14

2.3. REAL-TIME TRAFFIC MANAGEMENT

Figure 2.5: Example of Traffic Diagram (Hansen and Pachl, 2008)

2.2.2 Blocking Time Stairway

The blocking time stairway represents the operational use of a line by a train. It is created

by drawing into a time-over-distance diagram the blocking times of all block sections

that a train passes along a route. As shown in figure 2.6, there are two axes. The vertical

axis represents the time. The horizontal axis represents the distance: information about

track circuits and signalling system are graphically represented. The blocking time

stairways allows determining graphically the minimum time headway between two

trains. The minimum line headway is the minimum time lag between two consecutive

trains considering not one block section but the blocking time stairways for the whole

line.

2.3 Real-Time Traffic Management

Managing railway traffic in real-time involves minimizing delays between consecutive

trains, modifying provisionally the timetable and ensuring the feasibility of the opera-

tions. It is important to underline that this is a short-term process that requires solutions

within a few minutes. In every control area there is at least one dispatcher who receives

information about every train, e.g. information about the current location, speed and

destination of every train as well as the status of every part of the track under his

15


Figure 2.6: Blocking Time Stairways Diagram (Hansen and Pachl, 2008)

supervision. Based on his own experience, the dispatcher calculate whether and when

conflicts will occur. He will then pass to control actions with the aim of resolving conflicts.

A relevant point of delay management is to find ways how to reduce or increase delays

with the purpose of minimizing passengers’ inconveniences.

2.3.1 Train Delays

Before moving on, we will discuss train delays. The stability of railway system can be

defined as the aptitude to return to normal operations after disturbed circumstances

(D’Ariano, 2008). If a railway system is operating irregularly for a too long period of

time, it is considered as unstable. The analysis of the punctuality of trains represents an

important measure of railway operation performance. During the operation, the delay

of a train is taken into account if it is greater then a certain value n: depending on the

country, n can be around 3/5 minutes long. To manage and compensate initial delays,

recovery times and dwell times margins are adopted. The dwell time is the scheduled

stopping time of train at a platform. In addition, every timetable comprises scheduled

16


waiting times. Scheduled waiting times are also used as an indicator of timetable quality

(D’Ariano, 2008).

Two main kinds of delays can be distinguished (Sobieraj et al., 2011). We talk about

Primary Delay: when a train suffers of a certain amount of delay due to unexpected

events occur. Due to this delay, some conflicts can arise in a control area. It is

important to underline that unexpected events are not involving others trains.

The second type of delay is called Secondary Delay: we talk about secondary delay when

a train suffers of a certain amount of delay caused by the delay of another train.

The main goal of a dispatcher is to minimize secondary delays.

When a conflict occurs, the dispatcher has to take a decision in order to produce a new

non-conflicting running schedule. According to Hansen and Pachl (2008), a dispatcher

needs to proceed in the the following steps:

• Start with a conflict free timetable;

• Get information from the operation;

• Detect the conflicts;

• Resolve the conflicts;

• Generate a new conflict free timetable.

In order to detect a conflicting situation, an important step is computing the blocking

time of every block section along the route of trains. To reach this goal, the infrastructure

model has to be very detailed: the level of infrastructural detail required shall be

microscopic (section 2.1.4.2).

In real-time, a train delayed may require a different train route, which generates

conflicts with other trains. To solve these conflicts, it could be necessary to hold some

affected trains and this may generate some knock-on delays. The purpose of a dispatcher

is to minimize the consequences of such kinds of inconveniences on other trains. In order

to solve conflicts, the dispatcher needs to reschedule some trains. To reach this purpose,

a dispatcher has several possible control actions.

• Changing dwell times at scheduled stop;

• Changing train speed along the line;

• Changing train order at junctions and stations;

17


• Changing the route of the trains or even deleting train runs.

In addition, when a conflict between two trains occurs, the dispatcher has to decide

which train has the priority. According to Hansen and Pachl (2008), the dispatcher uses

the following rules:

• Emergency train get the highest priority,

• Fast trains get preference over slow trains, e.g. T.G.V. get preference over a freight

train.

In general, dispatchers still control the rescheduling process manually. Automated

conflict detection and resolution are required as a mean of support for the dispatchers:

even if the initial conflict has been resolved, additional conflicts could arise from the

solution founded. Also these conflict must be identified and resolved.

2.3.2 Objective function and constraints

In the corresponding scientific literature, several objective functions have been proposed

to solve the rtRTMP (real-time traffic management problem). In the following, we

will present the two most common ones (Pellegrini et al., 2014). The first one has the

objective to minimize the maximum secondary delay suffered by any train (D’Ariano

et al., 2007). The second objective function has the goal to minimize the total secondary

delay (Rodriguez, 2007). Multiple sets of constraints are linked to the real-time traffic

management problem:

1. Time concerning constraints. A train cannot operate before it arrives in a control

area and it must use every track circuits along a route for a certain amount of time.

A train can also occupy consecutive track circuits at the same time: this happen

when the tail is still on a track circuit but the head is already in the following one.

This time is called clearing time.

2. Constraints for managing delays. These constraints can be divided in three cases:

no constraints, delay allowed at any signal and delay allowed only out of control

area. In the first case, a delay may be allowed in every part of the control area: the

dispatcher can decide to manage the delay in every track circuit along the route

of the train. Delay allowed at any signal means that a train can stop in front of

signal. The last case could be the most difficult one: complex coordination problems

between different control areas may arise.

18


3. Constraints due to the change of rolling stock configuration. When a train arrives

in a station, it can be split in two trains, two trains can be joined to create a new

one. A train can also do a turnaround: in this case it will continue its run in the

direction from which it just arrived.

4. Capacity constraints. These constrains imply that only one train can use the same

block section at the same time

2.3.3 Modelling real-time traffic management problem

According to D’Ariano (2008), the modelling approaches to rtRTMP can be divided into

two classes.

Fixed speed models. In this model the speed profile of a train is not updated in case of

conflict.

Variable speed models. In this case the speed profile of a train is modelled with the goal

to include possible consequences of conflicts according to the current state of the

signalling system and other traffic regulations.

The variable speed model is the better choice: it is more complete and more accurate.

However, this model is not used often (Sobieraj et al., 2011). The time for computing a

solution is an important factor: usually this time is around three minutes long. The fixed

speed model is the most used because it requires less computation time.

2.3.3.1 Formulations for rtRTMP

We present two formulations for real-time traffic management problem. The first one

is called ROMA (D’Ariano, 2008) and it is a variable-speed dispatching support system.

The second one is called RECIFE-MILP (Pellegrini et al., 2015b) and is an algorithm

based on mixed-integer linear programming model.

ROMA. Railway traffic Optimization by Means of Alternative graph addresses the

rtRTMP problem when the infrastructure is represented with "rough" granularity

(in term of block sections). It is composed by four interrelated procedures and a

dispatcher can interact with the system: he can remove or add constraints or he

can change the timetable. We describe shortly the function of each procedure.

19


1. Data loading. This part is responsible for collecting data from fields. Example

of data could be the current status of the infrastructure, the timetable, the

position and speed of all running trains. It is also responsible for computing

the time needed to complete the next operation, e.g. the delay of a train when

it will enter in the network.

2. Disruption Recovery. This sub-problem receives as input a default route and

a set of re-routing options ordered by priority. Its goal is to find a passable

routing for each train trying to avoid that part of the track will be under block.

3. Real-Time Traffic Optimization. In this case the input is a set of dynamic

management strategies, e.g. flexible orders and departure time. The goal is

to find a conflict-free and deadlock-free scheduled through actions of train

re-routing or train rescheduling. Deadlock is an unstable situation where two

or more trains are blocking each other such that neither train can continue.

4. Train speed coordinator. The last sub-problem receives as input a schedule

computed by the previous procedure. Its work is to check if the solution is

consistent with train dynamics and verify if the blocking-time of every train

overlaps the blocking-time of the others following trains. If a situation of

overlap arises, a procedure will start with the aim to compute an acceptable

train speed profile .

RECIFE-MILP (REcherche sur la Capacité des Infrastructures FErroviaires). A MILP

formulation is proposed in Pellegrini et al. (2014): it addresses the rtRTMP when

the infrastructure is presented with "fine" granularity (in term of track circuits).

The formulation modelled both interlocking systems: route-lock route-release and

route-lock sectional-release, called respectively RR formulation and SR formulation.

For the SR formulation, two objective functions are considered. The first objective

function has the goal to minimize the maximum secondary delay suffered by

any train. The second one focuses on the minimization of the total secondary

delay. In Pellegrini et al. (2015b) present a heuristic algorithm, called RECIFE-MILP. The MILP formulation is extended with a more detailed description of the

characteristics of the infrastructure. The performance of the solving algorithm are

boosted: the speed for calculating a high quality feasible solution is increased and

the computational time for proving the optimality of the solution is decreased. It is

set a time limit: passed this limit, the best solution found is returned. A weight

is associated to train’s delay. The objective function is to minimize the amount of

20

2.4. OPENTRACK

Figure 2.7: Modules of the simulation process (Huerlimann and Nash, 2010)

total weighted delays when the trains exit from the infrastructure.

2.4 OpenTrack

OpenTrack is a railroad network simulation program and a research project at the Swiss

Federal Institute of Technology. The aim of the project is to develop an user-friendly tool

that can answer many different questions concerning railway operations.

In figure 2.7 we can see how the simulation tool works (Huerlimann and Nash, 2010).

OpenTrack receives in input information about the infrastructure, the rolling stock

of every train and the timetable. During the simulation phase, train movements are

calculated under the constraints of the signalling system and the timetable. A lot of data

for every train are saved continually, as speed, acceleration, position, power consumption.

OpenTrack provides a GUI where a user can follow the simulation process and interact

with it. An example of interaction could be changing the aspect of a signal along the

route of a train. During the simulation and at the end of simulation, OpenTrack provides

a lot of output data, such as time-space diagrams, tables and graphical elements.

21


2.4.1 Structure of OpenTrack

2.4.1.1 Input Data

Rolling Stock It consists of locomotive and wagons that are combined to form a train.

The locomotive types are organized in term of technical specification, as tractive

effort/speed diagram, weight, length. The user can enter and edit data for specific

locomotive into locomotive database. Wagons are not defined in OpenTrack: during

the simulation phase the only data needed is the length and the mass of the whole

train.

Track Layout Data Detailed description of the physical infrastructure that is simu-

lated. Track layout data includes track segments, called edges, signals and stations.

There are also included virtual elements such as vertices ad routes. Attributes can

be assigned to edges and vertices. For example, details such as length, gradient

and maximum speed can be stored for a particular edge; details as name switch

information can be assigned to a vertex.

OpenTrack describes the track layout in terms of double vertex graph. In a double

vertex graph, a vertex always appear together with a second vertex. Compared to

single vertex graphs, double vertex graphs can provide information at each vertex

about the edge via which the vertex has been reached.

Timetable Data These data concern information about the movements of trains: arrival

and departures time, minimum dwell time and stop information.

2.4.1.2 Infrastructure and Timetable related terms

There are three levels of infrastructure related terms:

1. Route. It consist of a set of vertices and edges linked together and they can be

explain as section of a track.

2. Path. It consists of a set of routes and they can be thought as a set of track sections

in a specific area.

3. Itinerary. It consists of a set of paths.

Timetable related terms consist of the following:

• Course. Sets of itineraries with scheduled data (e.g. timetable data) associated with

the itinerary data.

22

2.4. OPENTRACK

• Turnaround. Groups of courses used to show that the same train composition is

used for different courses.

2.4.1.3 Simulation Phase

To model train movements OpenTrack uses a mixed continuous-discrete method: the so-

lution of differential motion equation (continuous) are combined with signal information

(discrete). During the simulation phase, information about each train are stored into an

output database: acceleration, speed and distance covered. The simulation process can

be performed in two ways: normally or in animation mode. The animation mode allows

to the users to follow the running trains, the occupied track sections and the state of the

signals.

23

CH

AP

TE

R

3MODELLING INFRASTRUCTURE AND ROLLING STOCK

In the last chapter we saw that the railway infrastructure is described by several

different elements and each element has its own characteristics. Beside the physical

characteristic of the infrastructure, there are also several data about trains that

travel along the considered infrastructure. It is important to collect all of these data in

order to make them available to the phases of development of programs and algorithms.

In order to make easier the development and avoid lack of information, well organized

structures are needed. In our work, to represent these informations, we use a XML data

structure called RECIFE Data Structure.

This chapter is organized as follows. We will begin with an introduction about the

RECIFE project and we will describe the RECIFE Data Structure. Then we will talk

about the program that we developed for generating the infrastructure and the rolling

stock. At the end we will present the infrastructures that we modelled: Pierrefitte -

Gonesse and Rosny sur Seine - St. Etienne du Rouvray.

3.1 RECIFE Project

The RECIFE project (Rodriguez et al., 2007) aims to develop decision-making aid tools

for investigating the capacity of an item of railway infrastructure such as a station or a

node. According to the International Union of Railways, the rail capacity is defined as a

multidimensional concept (UIC, 2004). The first dimension is the number of trains that

are able to travel along the line within a given time interval. The second is the average

25

CHAPTER 3. MODELLING INFRASTRUCTURE AND ROLLING STOCK

speed of the trains: the higher the speed, the higher the stopping distance required

between trains. The third dimension is the timetable stability, which is the ability of a

timetable to deal with small delays. The last dimension is uniformity: the greater the

speed difference of the different types of trains that are running, the fewer trains can

travel within a given time interval.

Two central types of optimization problem are linked to the context of analysis of

railway capacity. The first, called Feasibility problem, concerns verifying if it is feasible

for a given combination of trains to run on the considered infrastructure with an existing

schedule. The second, called Saturation problem, is to introduce the maximum number

of train runs into an existing train schedule. The trains added represent the margin of

available capacity of the infrastructure. The new trains are chosen from a list of trains

called saturating list.

The main objectives of the RECIFE project are the following. Propose mathematical

models for these two problems and develop algorithms to resolve them. Integrate the

prior results with an open source platform that includes analysis and visualization

modules. Validate the model and the resolution using real problem instances.

The approach to the problems is unique because it is characterized by the highly

detailed nature of the modelling which is explained by the geographical scale of the

infrastructures that are considered.

In Sobieraj et al. (2011) a two-step approach is used to tackle the complexity of the

real-time railway traffic management problem (rtRTMP). In the first step a fixed-speed

profile is assumed to generate good solutions. In a second step, a feasibility check is

performed and the speed profile of the trains is updated to ensure it corresponds to real

operations. Pellegrini et al. (2013) analyse the impact of unexpected events that perturb

railway traffic. They analyse a mixed integer linear programming (MILP) formulation

which aims at minimizing the delay propagation when traffic is perturbed. Pellegrini et al.

(2014) propose a mixed-linear programming formulation for tackling the real-time traffic

management problem, representing the infrastructure with fine granularity. In Pellegrini

et al. (2015b) a heuristic algorithm based on a mixed-integer linear programming model,

called RECIFE-MILP it is introduced to tackle the rtRTMP. Samà et al. (2016) deal with

the real-time problem of scheduling and routing trains. They studied how to select the

best subset of routing alternatives for each train among all possible alternatives. In

Pellegrini et al. (2016) an evaluation of the performance of RECIFE-MILP is performed

in collaboration with the French infrastructure manager (SNCF Rèseau).

26

3.1. RECIFE PROJECT

3.1.1 RECIFE Data Structure

Due to various data structure contained in several and different files, there was the need

to develop a well formatted data structure. The proposal was to create a standard format

for representing the data using XML files and schema. Beside this standard format,

there was also the proposal to develop a library to manage the data structure.

The standard format proposed, called RECIFE Data Structure (RDS), split the data

into four main categories: infrastructure, rolling stock, timetable and maintenance work.

In our work we focused on developing a program to generate the XML schema for the first

two categories. In the following a brief introduction to the data structures concerning

infrastructure and rolling stock is presented.

Infrastructure Definition This schema represents detailed information about the

physical characteristic of the infrastructure, about stations and details about the

route of every train, travelling along the infrastructure represented. The structure

is as follows.

• Track Circuit. It contains information about track circuits: name, length,

speed, gradient and curve.

• Signal. It contains information about signals: name, number of aspects and

visibility distance.

• Block. It contains information about block sections such as name, entry and

exit signals, formation time, release time and by which sequence of track

circuits are composed.

• Stopping Points. It contains informations about platforms: the maximum

allowed train length, the name of the signals at the beginning and at the end.

• Stopping Points Groups. It contains information about stations such as the

name and platforms (Stopping Points).

• Journeys. It contains informations about the routes of the trains travelling

along the considered infrastructure. For every route the following information

are represented.

– The ordered sequence of block sections that compose the route;

– For the track circuits along the route, the running time and the clearing

time;

– The station(s) where the train stops, including whether the station is

departing, intermediate or destination.

27


Rolling Stock Definition In this schema information about trains are represented.

For every train there is information about its locomotive and its wagons and by

which vehicles a train is formed. For every vehicle stock details are included too.

The structure is as follow:

• Vehicle Types. For every vehicle it contains informations about its length,

rotation mass factor and mass. In addition, for locomotives, the details about

the tractive effort curve are represented.

• Rolling Stocks. It contains the sequence of vehicles that compose a train, the

constant deceleration of the train and the values of the resistance factors.

3.2 Generation of Infrastructure and Rolling Stock

In the following a description about our generation program is presented. The goal

is to generate the infrastructure and the rolling stock XML files in accordance with

the RECIFE standard format. Our program is divided into two sub-parts: the first

concerns the generation of the infrastructure file, the second generates the rolling stock

file. The data that every part receives in input are produced by OpenTrack, where the

infrastructure is modelled. The output of OpenTrack consists in XML and text files.

The program is presented in figure 3.1. Both parts are composed by the same interre-

lated procedures.

1. Data Loading (i). Using the library "Xerces XML Parser", read and clean data.

2. Data Merging (ii). The data are organized and divided in agreement with the XML

schema defined by the RECIFE standard format. We report the main functions

developed.

For the generation of the Infrastructure:

• getTopopolgyParts(...). This function combines together all the details concern-

ing track circuits;

• getBlock(...). This function combines all the information about block sections,

including the sequence of track circuits that compose every block section;

• mergeNameAspectsDistances(...). This function combines all information about

the signalling system;

28

3.2. GENERATION OF INFRASTRUCTURE AND ROLLING STOCK

Figure 3.1: Generating Infrastrucure and RollingStock program

• getStoppingPoints(...) and getStoppingPointsGroups(...) This function com-

bines details about stations and platforms;

• getJourney(...) This functions combines details about every route of the infras-

tructure.

For the generation of the Rolling Stock:

• getVehicleTypes(...). This functions combines together all the details concern-

ing the vehicles (locomotives and wagons), such as the length of vehicles, their

mass and rotation factor and, for locomotives, the tractive effort curve;

• getRollingStock(...). This functions combines together all the data about trains.

It associates to each train the order sequence of vehicles composing it, the

deceleration value and the data about the locomotive.

3. Data Output (iii). For both parts, it generates an unique XML file.

29


3.3 Infrastructure Modelling

In our work we modelled two different infrastructures. The first one is the node of

Pierrefitte-Gonesse located north of Paris. The second one is a portion of the Paris - Le

Havre line, between Rosny sur Seine and St. Etienne du Rouvray

3.3.1 Pierrefitte - Gonesse

The figure 3.2 schematically represents the routes of different kinds of trains that every-

day travel along the node. Mainly, three different kinds of trains can be distinguished:

• T.G.V., Eurostar and Thalys travelling from Lille to Paris and vice versa

• Passenger trains departing form Paris Nord to Lille and vice versa

• Freight trains from Grande Ceinture to Chantilly and vice versa

Figure 3.2: Circulation schema in the node of Pierrefitte-Gonesse

The structure of the node is presented is figure 3.3. The main characteristics are:

• Length of the line ∼ 16 km

• Average running time ∼ 7 minutes and 40 seconds

• No stations

• 79 block sections and 89 track circuits

• 61 signals: 19 with 3 aspects, 36 with 4 aspects and 6 with 5 aspects

• 37 routes

30

3.3. INFRASTRUCTURE MODELLING

Figure 3.3: Node of Pierrefitte-Gonesse (Rodriguez, 2007)

3.3.2 Rosny sur Seine - St. Etienne du Rouvray

The structure of the node is presented in figure 3.4. There are a lot of trains with different

rolling stocks circulating along the line. In our work we consider 61 different rolling

stocks.

Figure 3.4: Node between Rosny sur Seine and St. Etienne du Rouvray (Pellegrini et al.,2015a)

Description of the node:

• Length of the line ∼ 70 km

• Average running time ∼ 23 minutes and 27 seconds for high speed trains, ∼ 26

minutes and 57 seconds for passenger trains and ∼ 41 minutes and 3 seconds for

freight trains

• 10 stations and 32 platforms

• 487 block sections and 501 track circuits

• 319 signals: 258 with 3 aspects and 61 with 4 aspects

31


• 3459 routes

• Presence of gradients

To generate the XML files we used a machine with the following characteristics: OS

Ubuntu Linux 14.04 LTS 64-bit, 4GB of RAM and processor Intel Core i7-3520M CPU @

2.90GHz x 4. The table 3.1 shows the execution time required to generate the XML files.

Infrastructure Rolling StockPierrefitte-Gonesse 2.1 1.2Rosny sur Seine - St. Etienne du Rouvray 92.5 1.7

Table 3.1: Execution time (in second) to generate Infrastrucure.xml and RollingStock.xml

32

CH

AP

TE

R

4RUNNING TIME COMPUTATION

The running time is the amount of time that a train needs for travelling along

a track circuit. Estimate running times is important to achieve several goals.

To help dispatchers to take better decisions in managing traffic. To setting up a

timetable: it is crucial to compute running times for different train configuration using

the current infrastructure.

To compute running times, several data are required (Hansen and Pachl, 2008):

details of the train route, as speed limits, distance, gradient and curves. Other required

data are the characteristics of the traction unit, such as locomotive tractive effort and

locomotive resistance and data about the rolling stock, like mass, length and wagons

resistance. However, some influences on running times are not deterministic: human

behaviour, weather conditions and route conditions. To deal with these influences, two

approaches exists: random influences are taken into account through recovery times or a

probabilistic approach is used.

This chapter is structured as follows. In the first part we will talk about resistances

that a train has to face: the resistance opposed from the line, called distance resistance,

and the resistance of locomotive and wagons, called rolling stock resistance. We will focus

on running time calculation: we will see what is a moving section and how to determine

braking, acceleration and constant speed sections. Then our running time estimation

program is presented. In the end, a comparison between our program and OpenTrack is

reported.

33

CHAPTER 4. RUNNING TIME COMPUTATION

4.1 Traction Resistance

The resistance that a train has to face can be divided into two parts (Huerlimann and

Nash, 2010) distance resistance RD and rolling stock resistance RL. The sum of the two

is called traction resistance RF :

RF = RL +RD [N]

4.1.1 Rolling Stock Resistance

The rolling stock resistance consists of air resistance, rolling resistance and inertialresistance. Three different formulas are used. The first one is a combination between

other three: Sauthoff ’s formula (for passenger wagons), Strahl’s formula (for locomotives)

and improved Strahl’s formula (for freight wagons). The second one is a quadratic

equation and is called Davis formula and two variants exists: mass-dependent and

mass-independent. The last is called Maglev train resistance formula.

In our work we used the Davis mass-independent formula. More details about others

formulas can be found in Huerlimann and Nash (2010) and in Hansen and Pachl (2008).

Davis mass-independent formula The formula is:

RLZ = A+Bv+Cv2 [kN]

where RLZ is the resistance and v is the speed of the train measured in km/h. The

three parameters A, B and C are regression coefficients and are typically presented in

tabular form. The coefficients A and B account for mass and mechanical resistance. The

coefficient C refers to air resistance.

4.1.2 Distance Resistance

The distance resistance RD is the sum of three factors: gradient resistance RS, curveresistance RB and switch resistance RW . The last one is omitted in simulation due to is

small influence (Huerlimann and Nash, 2010).

RD = RS +RB +RW [N]

Gradient Resistance The gradient resistance RS is dependent upon the mass of the

train and the gradient of the line. It is independent of train speed. It is the amount of

34

4.2. RUNNING TIME COMPUTATION

train mass that works against the direction of motion of the train, as represented in

figure 4.1. The formula is:

RS = m · g · sin(α)

where α is the angle of the inclination of the line. Since the gradient of railway lines

is very slight, sin(α) can be replaced with tan(α). In railway operation tan(α) is called

inclination I and is measured in per thousand [h]. Called m (kg) the mass of the train,

g (m/s2) the value of acceleration gravity, the formula is:

RS = m · g · tan(α)= m · g · I1000

Figure 4.1: Gradient Resistance (Huerlimann and Nash, 2010)

In our work, we take the middle of the train as a point where the force is applied.

Curve Resistance When a train travels through a curve, it experiences a resistance.

This resistance is due to rigid wheel sets traveling over interior and exterior radii of

different lengths. The curve resistance RB depends on the curve radius r [m] and mass

m (kg) of the train. To evaluate it, the Roeckl’s formula (Deutsche Bahn) is used.

RB = 6.3r−55

·m f or r ≥ 300m

RB = 4.91r−30

·m f or r < 300m

4.2 Running Time Computation

The movement of a train is composed by acceleration, constant speed and braking phases.

It is determined by the tractive effort of the locomotive, by the air and track resistance

and by the route and timetable restrictions.

35


4.2.1 Moving Sections

The moving sections are formed by two part (figure 4.2): behaviour sections and character-istic sections (Hansen and Pachl, 2008). The behaviour sections are formed by movement

of the train. The characteristic sections are caused by changes of infrastructure.

The route can be partitioned into sections of equal characteristic and behaviour, e.g.,

same maximum speed and same gradient in a part of the line. The tractive effort of the

train is given by a formula valid for a certain speed interval and the acceleration phase

has to finish when the maximum speed of the train is reached. Changes of gradient and

speed limit are met along the line in a certain position.

Figure 4.2: Moving Sections (Hansen and Pachl, 2008)

4.2.2 Braking section

If the maximum speed of the next section is lower than the speed of the current section,

the reduction of speed must be completed before the head of the train reaches the next

section. For every section, the maximum speed vmax is given. The deceleration d is

constant and it depends on the rolling stock of a train. To compute the braking section,

36


the formulas of linear motion are used. The procedure is as follow (Hansen and Pachl,

2008).

1. The first step is to calculate the braking distance sred to reduce from the maxi-

mum speed Vmax1 of the current section sec1 to the maximum speed Vmax2 of the

following section sec2. The braking distance is:

sred = v2max1

2d− v2

max2

2d

If sred is shorter than the length of the section, the section is split into two parts.

The first section is a constant speed section at speed vmax1 and the second section

is a braking section. The length of the second section is sred

2. If the braking distance sred is longer then the length ssec of the section, a new value

of maximum speed Vmax1 has to be compute. The new value is called Vmax1new and

is given by:

Vmax1new =√

2d · ssec +v2max2

If the maximum speed vmax0 of previous section sec0 (previous of sec1) is greater

than vmax1, also for the section sec0 the braking distance has to be computed. For

this reason, usually the braking distance is computed in reverse order, i.e. starting

with the last section, and the braking section is computed before the acceleration

section.

Figure 4.3: Braking Curves due to Speed Restriction (Hansen and Pachl, 2008)

37


4.2.3 Acceleration section

If the maximum speed of the next section is higher than the maximum speed of the

current section, an acceleration phase is entered. We first talk about how to determi-

nate in which acceleration phase we are, then we will talk about how to calculate the

acceleration.

There are three different kinds of acceleration phases. In every case the value of

entrance speed is lower than the value of the maximum speed of the section:

The section is a constant speed section and the maximum speed vmax is reached in the

section (figure 4.4).

Figure 4.4: Acceleration phase, maximum speed of the section is reached (Hansen andPachl, 2008)

The acceleration phase is through the whole section and the exit speed is lower than

the maximum speed vmax of the section. In this case the section could be a constant

speed section or a braking section (figure 4.5).

The section is a braking section and the acceleration curve intersect the braking curve

(figure 4.6).

To calculate the value of acceleration, the basic equation of dynamics are used. Called

F the tractive effort of the engine (measured in N), m (kg) the mass of the train and a(m/s2) the acceleration of the train, we have:

F = ma =⇒ a = Fm

When a train accelerates, the locomotive must transfer a force to the rail: this force is

called tractive effort. The difference between tractive effort Z(v) and traction resistance

38


Figure 4.5: Acceleration phase, exit speed is lower than maximum speed (Hansen andPachl, 2008)

Figure 4.6: Acceleration phase, intersection with braking curve

RF (v, s) is called traction power surplus. The tractive effort depends upon the speed of

the the train. The traction resistance depends upon train speed v (m/s) and distance

covered s (m) by train (Huerlimann and Nash, 2010).

FZ = Z(v)−RF (v, s)

The train maximum acceleration rate also depends on speed limit, locomotive maximum

speed and weight of wagons. The maximum technically possible acceleration rate is given

by the following formula:

(4.1) a = FZ

m · (1+0.01%)

where % is the mass factor for rotating masses and is a constant.

39


To evaluate the actual speed of a train, the motion equation are used (Huerlimann

and Nash, 2010). The actual speed is calculated with the formula below.

v = v0 +∫ t2

t1a dt or a = dv

dtThe distance covered can be calculated by repeated integration of the following equation:

s = s0 +∫ t2

t1v dt or v = ds

dtIn our work, to evaluate the movement of a train through an acceleration section, we

decide to use the formulas of linear motion. The reason is related to tractive effort data

available: given a locomotive, we had information about the tractive effort with a step of

1 km/h. In the following a description of the procedure to evaluate the movement of a

train through an acceleration section is presented.

1. Given the values of the tractive effort at speeds v0 and (v0 +1), set a step of 0.1

km/h and evaluate the values of the tractive effort from (v0 +0.1) to (v0 +1).

2. Given two consecutive values of the tractive effort Fz1 (for speed v) and Fz2 (for

speed (v+1)) with step of 0.1 km/h, calculate the values of acceleration az1 and az2

using the formula 4.1.

3. Given the values az1 and az2 computed and the speeds v and v+1, evaluate a

weighted acceleration value aw in the interval [az1,az2].

4. We take aw as the constant value to accelerate from speed v to speed (v+0.1).

5. Use the formula of linear motion

(4.2) t = (v+0.1)−vaw

and

(4.3) s = (v+0.1)2 −v2

2aw

6. In addition, we also decided to consider different step values to compute the tractive

effort. These values are comprised between 0.1 km/h ad 1 km/h.

4.2.4 Constant Speed Section

When a train has reached its maximum speed or the maximum speed of a section, it is

in a constant speed phase. To describe its movement, we can simply use the following

formula:

s = v · t

40

4.3. RUNNING TIME COMPUTATION PROGRAM

where s (m) is the space covered, v (m/s) is the constant speed and t (s) is the time.

If in a constant speed section a train reaches a gradient section, the traction resistance

can increase since over the tractive effort: in this case a train decelerates. To compute

the deceleration we can use the same equations used in the acceleration phase: 4.1, 4.2

and 4.3.

4.3 Running Time Computation Program

This section describes our running time computation program. It is composed by an

ordered sequence of procedure and it is presented in figure 4.7. At the end a comparison

with OpenTrack is reported.

Generating Infrastructure and RollingStock program

Infrastructure.xml RollingStock.xml

Data Loading

Route Creation

Compute Running Time

Output Data

Running TimeComputation

RunningTimes.txt TrainDetails.txt Gantt.xml

Figure 4.7: Running Time Computation Program

41


1. Data Loading. This procedure receives in input the XML files generated by our

generation programs described in section 3.2: Infrastructure.xml and Rolling-Stock.xml. Using the Recife Class Manager Library, the procedure reads data from

files and organize them for the following procedure.

2. Route Creations. Given a route of a train, the order set of track circuits that

compose the route and the details about the signalling system, create the moving

sections. For every track circuit, information about its length, maximum speed,

gradient and curves are retrieved. All the information that this procedure needs

are included in the Infrastructure.xml file.

3. Compute Running Time. Using the moving section previous computed and the

data about the rolling stock of the train, the procedure computes the running time

of every track circuit and the total running time. Then the clearing time of each

track circuits is also computed. This procedure needs the following data about the

rolling stock: tractive effort of the locomotive, A, B and C parameters, deceleration

value, mass, length and mass factor of locomotive and wagons. All this information

are stored in the RollingStock.xml file. In the following the main function developed

are reported.

• getAccelerationFromSpeed(...). This function receives in input the values of

speed, gradient and curve and details about the train. It calculates the Rolling

Stock Resistance (4.1.1) and the Distance Resistance (4.1.2). Then, using the

formula 4.1, the value of acceleration is computed.

• findIntersectionAccelerationBrakingCurve(...). This function find the point

where the acceleration curve intersects the braking curve. To reach the goal,

the acceleration and braking curve are computed at the same time with a step

of 0.1 meters until the intersection point is found.

• getTotalTime(...) This is the main function of the Program. It receives in

input details about the infrastructure (as information about track circuits and

signalling system) and data about the train that will use the infrastructure.

It works as follows:

a) It computes the braking sections (4.2.2) for the whole route;

b) It finds where the train is an acceleration phase, braking phase and

constant speed phase;

c) Using the previous two functions and the formulas of linear motion, it

calculates the running time for every track circuit and for the whole route.

42


• calcClearingTimes(...) This function computes the clearing time for every

track circuit.

4. Output Data. The program produces several output files:

• A text file which contains the total running time for every train processed.

• For every train, a file reporting detailed information about the route of the

train. Using the space travelled as reference, information about speed, accel-

eration, tractive effort, rolling stock resistance and distance resistance are

stored. Those files are also given as input to an existing external program

that creates the speed-distance diagram.

• A XML that contains information to create the blocking time stairways.

To compute the running time we used a machine with the following characteristics:

OS Ubuntu Linux 14.04 LTS 64-bit, 4GB of RAM and processor Intel Core i7-3520M CPU

@ 2.90GHz x 4. We set our program with 4 different steps to compute the locomotive’s

tractive effort: 0.1 km/h, 0.3 km/h, 0.5 km/h and 1 km/h. The time needed to compute all

the running times in Pierrefitte-Gonesse (37 different train runs) and in Rosny sur Seine

- St. Etienne du Rouvray (3459 different train runs) are reported in table 4.1.

Step Pierrefitte-Gonesse Rosny S. - St. Etienne R.0.1 km/h 51.2 sec 57 min and 31 sec

0.3 km/h 13.8 sec 12 min and 58 sec

0.5 km/h 6.4 sec 5 min and 56 sec

1 km/h 2.5 sec 2 min and 29 sec

Table 4.1: Execution time (in minutes and seconds) to compute running times

4.3.1 Comparison with OpenTrack

We configured OpenTrack with two different time step of the simulation process: 1 second

and 0.1 second. With large steps the simulation process is faster but less precise. With

small steps the simulation process is slower but more exact. We set our program with 4

different steps to compute the locomotive’s tractive effort: 0.1 km/h, 0.3 km/h, 0.5 km/h

and 1 km/h. For every route of every train we compared the running time computed

by our program and the running time computed by OpenTrack. In tables 4.2 and 4.3

43


are reported the average differences between running times computed for the whole

route for the infrastructure of Pierrefitte-Gonesse and for the infrastructure between

Rosny sur Seine - St. Etienne du Rouvray. As we can see, the shorter the time step, the

closer our program is to OpenTrack. The differences between the values calculated for

Pierrefitte-Gonesse and Rosny sur Seine - St. Etienne du Rouvray is due by the different

length of the infrastructure (Pierrefitte-Gonesse ∼ 17km, Rosny sur Seine - St. Etienne

du Rouvray ∼ 70km) and by the presence of gradients and stations on Rosny sur Seine -

St. Etienne du Rouvray. Using the tables 4.1 and 4.3, we can make a comparison between

execution times and difference of running times. We can notice that our program behaves

differently depending of the infrastructure modelled. For Pierrefitte-Gonesse, shorter

the execution time, lower the average running time difference. For Rosny sur Seine

- St. Etienne du Rouvray, higher the execution time, lower the average running time

difference. The difference is due to the presence of gradient in the node between Rosny

sur Seine - St. Etienne du Rouvray.

Step Pierrefitte-Gonesse Rosny S. - St. Etienne R.

0.1 km/h ∼ 1.6 sec ∼ 2.44 sec

0.3 km/h ∼ 1.43 sec ∼ 2.63 sec

0.5 km/h ∼ 1.39 sec ∼ 2.7 sec

1 km/h ∼ 1.31 sec ∼ 2.91 sec

Table 4.2: Differences between our program and OpenTrack - 1 second step for OpenTrack

Step Pierrefitte-Gonesse Rosny S. - St. Etienne R.

0.1 km/h ∼ 0.28 sec ∼ 1.1 sec

0.3 km/h ∼ 0.26 sec ∼ 1.98 sec

0.5 km/h ∼ 0.25 sec ∼ 2.57 sec

1 km/h ∼ 0.22 sec ∼ 2.76 sec

Table 4.3: Differences between our program and OpenTrack - 0.1 second step for Open-

Track

The results obtained are very encouraging. For both infrastructures modelled the

running times difference between our program and OpenTrack is very low for all train

44


runs, in particular for the node of Pierrefitte-Gonesse where the difference is under 0.3

second. Beside the high accuracy in the computation of the running time, our program

has another strong point: it is very flexible. Thanks to its flexibility, the program could

be easily modified in order to include more variables or to use different formulas.

• In the function getAccelerationFromSpeed(...), the Davis mass-independent formula,

used to compute the Rolling Stock Resistance, can be replaced with Sauthoff ’s and

Strahl’s formulas;

• In the function getTotalTime(...), the human behaviour of train drivers and weather

conditions could be taken into account in order to make the computation of the

running time more close to real world.

We also did a visual comparison using the speed-distance diagram. We decided to report

an example for both infrastructures, figures 4.8 and 4.9. The top part of both figures

shows the speed-distance diagram based on OpenTrack logs. The bottom part shows

the speed-distance diagram of OpenTrack overlapped by the one calculated by our

program. In the latter, we can notice that there are not visible differences between the

two diagrams: this means that is every part along the route our program is really close

to OpenTrack.

45

Figure 4.8: Visual comparison between OpenTrack and our program, Pierrefitte-Gonessenode


Figure 4.9: Visual comparison between OpenTrack and our program, Rosny sur Seine -St. Etienne du Rouvray

47

CH

AP

TE

R

5RUNNING TIME COMPUTATION WITH TRAFFIC

In the fourth chapter we have showed how to estimate the running time and we have

presented our running time computation program. Therefore we have computed the

duration in accordance with the physical characteristics of the line and in absence

of traffic, which implies that all the signals met by a train during its run have green

aspect. In this chapter we will examine how to detect a conflict between trains and how

to compute the running time in presence of traffic. The first part of the chapter describes

our running time computation program in presence of traffic. Then in the second part an

example of how our program works is reported.

5.1 Running Time Computation with TrafficProgram

This section describes our running time computation program in presence of traffic.

Given a perturbed situation, we used the RECIFE-MILP algorithm to compute a set of

solutions. The structure of the program is presented in figure 5.1.

In the following a description of the procedures is presented.

1. Data Loading. The program receives in input five XML files:

• Infrastructure.xml and RollingStock.xml

49

CHAPTER 5. RUNNING TIME COMPUTATION WITH TRAFFIC

Infrastructure.xml RollingStock.xml Disruption.xml RECIFESolution.xml

Running TimeEstimationProgram withTraffic

Data Loading

Utilization Time

Find Conflict

Solve Conflict

Conflict?

Yes

Data Output

No

Running Time

RunningTimes.txt TrainDetails.txt SolvedGantt.xml

TimeTable.xml

Figure 5.1: Running Time Estimation Program with Traffic

50

5.1. RUNNING TIME COMPUTATION WITH TRAFFIC PROGRAM

• TimeTable.xml. For every train’s run, it contains the train’s entrance time in

the infrastructure and the train’s exit time from the infrastructure.

• Distruption.xml: it contains the amount of delay that trains suffer when they

enter the infrastructure.

• RECIFESolution.xml: it contains the information on train routing and priori-

ties chosen by the RECIFE-MILP algorithm.

Using these data, a priority list for every track circuit is computed.

2. Running Time. Given all trains, their corresponding moving sections and infor-

mation about the signalling system, it computes the running time of every track

circuit along the route for every train.

3. Utilization Time. Given the running times of every track circuits, it computes

the blocking times of every block section. (section 2.1.3).

4. Find Conflict. Given the blocking times of every block section, it verifies if there

are blocking times that overlap others. If this happens, it finds the two trains

in conflict and the track circuit where the conflict arises and go to procedure (5).Otherwise go to procedure (6).

5. Solve Conflict. Given the two trains in conflict and the track circuit where the

conflict occurs, it retrieves the priority list of the track circuit. On the basis of the

priority list, it decides which train shall be delayed. For the delayed train, it sets

up the signalling system and it goes back to the procedure (2) in order to verify the

feasibility of the solution.

6. Data Output. The program produces three files:

• A text file called RunningTimes.txt. It contains a row reporting the following

information for each train: infrastructure entrance time, infrastructure exit

time and running time.

• For each train, a text file called TrainDetails.txt. Using the space travelled as

reference, information about speed, acceleration, tractive effort, rolling stock

resistance and distance resistance are saved. Those files are also given as

input to an external program that creates the speed-distance diagram.

• A XML file called "SolvedGantt.xml". It contains information to create the

blocking time stairways.

51


5.2 Running Time Computation with TrafficProgram Example

In this section we report an example of how our program works. We suppose that a

conflict arises between two trains, called TGVa and TGVb respectively. In order to ease

the understanding, we suppose that all the signals along the line have 3 aspects. For this

example the infrastructure of Pierrefitte-Gonesse has been used. The table 5.1 reports

the running time (in seconds) in absence of traffic and the length (in meters) of the route

for both trains. The speed-distance diagram in absence of traffic is reported in figure 5.2.

Length Running TimeTGVa 14790 434TGVb 14805 403

Table 5.1: Length (in meters) of the route and running time (in seconds) in absence oftraffic

Figure 5.2: Speed-distance diagram in absence of traffic

Hereafter we suppose that the TGVb is on time and the TGVa is delayed when they

enter the infrastructure. Using the blocking time stairways diagram (figures 5.3 and 5.4,

one figure for train) we can notice that a conflict occurs in the following track circuits:

z1064A and z1064B for the block section sc1053-sc1065 and z1065, z1067 and z1069 for

the block section sc1065-sc1103. Given this conflict situation and reading the priority

list, our program chooses which train has the priority. Hereafter we discuss both cases:

the TGVa has the priority and the TGVb has the priority.

TGVa has the priorityIn this case the TGVb has to be delayed. Using the blocking time stairways diagram

52

5.2. RUNNING TIME COMPUTATION WITH TRAFFIC PROGRAM EXAMPLE

Figure 5.3: Conflict situation - Blocking Time Stairways Diagram for TGVa

Figure 5.4: Conflict situation - Blocking Time Stairways Diagram for TGVb

in figure 5.4, we can reconstruct the aspect of the signals that the TGVb passed. The

signals from sc1007 to ss1312D showed a green aspects. The signal ss1412D showed

a yellow aspect: the TGVb has begun a braking phase. The braking phase continues

until the train reaches the visibility distance of the signal sc1053. There are thus three

possibilities:

1. The aspect of signal sc1053 is red and it stays red at least until the TGVb arrives

in front of the signal. In this case the train reaches a complete stop and it waits

until the next block section will be free (i.e., the aspect of the signal will be yellow

53


No conflict ConflictTGVa 434 434TGVb 403 428

Table 5.2: Running Times (in seconds) - TGVa has the priority

or green).

2. The aspect of signal sc1053 is red but becomes yellow or green before TGVb arrives

in front of the signal: the train can begin to accelerate without reaching a complete

stop.

3. The aspect of signal sc1053 is yellow (or green) or becomes yellow (or green) before

the train arrives in front of the signal: the train can begin to accelerate without

reaching a complete stop.

The blocking time stairways diagram in figure 5.5 shows the conflict situation re-

solved. If we compare this diagram with the diagram of figure 5.4, we can notice that

between the signal sc1053 and the signal sc1103 there are no more conflicts. With the

help of the distance vs speed diagram of figure 5.6, we can see that TGVb faced twice a

signal with yellow aspect (ss1412D and sc1053), but it has never reach a complete stop.

In table 5.2 the running time of both trains is reported.

Figure 5.5: Conflict solved - TGVa has the priority - Blocking Time Stairways Diagram

TGVb has the priorityIn this case the TGVa has to be delayed. Using the blocking time stairways diagram

54

5.2. RUNNING TIME COMPUTATION WITH TRAFFIC PROGRAM EXAMPLE

Figure 5.6: Conflict solved - TGVa has the priority - Distance vs speed diagram

No conflict ConflictTGVa 434 674TGVb 403 403

Table 5.3: Running Times (in seconds) - TGVb has the priority

in figure 5.3, we can reconstruct the aspect of the signals that the TGVa passed. The

signals sc1007 and sc1017 showed a green aspects. The signal sc1027 showed a yellow

aspect: the TGVa has begun a braking phase. The braking phase continued until the

train reached the visibility distance of the signal sc1037. Using the distance vs speeddiagram of figure 5.7, we can see that TGVa reached a complete stop. The blocking time

stairways diagram in figure 5.8 shows the conflict situation resolved. Comparing this

blocking time stairway with the one of figure 5.3, we can see that the TGVa waited for

the passage of the TGVb in front of the signal sc1037. In table 5.3 the new running time

of both trains is reported.

55

Figure 5.7: Conflict solved - TGVb has the priority - Distance vs speed diagram

Figure 5.8: Conflict solved - TGVb has the priority - Blocking Time Stairways Diagram

CH

AP

TE

R

6CONCLUSIONS

The management of the real-time railway traffic problem is a complicated short-

term process that requires effective solutions within few minutes. It consists of

selecting the train routes and schedules in order to minimize the propagation

of delays, ensuring the feasibility of the resulting plan. Due to these time limits, train

dispatchers usually perform modifications manually based on their experience, but the

efficiency of these modifications is often unknown. The development of real-time decision

support tools can help dispatchers to manage the infrastructures with more efficiency.

In our Thesis, we talked about two tools for the real-time traffic control: ROMA

and RECIFE-MILP and we focused in particular on the latter. The aim of the Thesis

was to develop a variable-speed program that could be used to evaluate the solutions

computed by RECIFE-MILP. Beside this aim, there were two other main targets. The

first one was to develop a program to merge data from several files and to organize it in a

standard structure (RECIFE Data Structure). The second one was to develop a program

to compute running times of trains travelling on a given infrastructure.

We started with the development of a program to merge data from several files. We

used OpenTrack to produce several different files (XML and text files) containing all

data concerning the infrastructure and the rolling stock. We merged and combined all

the information contained in these files and we generated two XML files in accordance to

the RECIFE Data Structure (one file for the infrastructure and one file for the rolling

stock). These files were used as the basis for the development of our Running Time

57

CHAPTER 6. CONCLUSIONS

Computation Program and also as basis for the development of other programs concern-

ing railway management in real-time. We modelled two infrastructures: the node of

Pierrefitte-Gonesse and the node between Rosny sur Seine - St. Etienne du Rouvray.

Therefore we developed a program to compute the trains’ running times. With the

information about the infrastructure and the rolling stock, our program computes the

resistance that trains have to face along their route: distance resistance and rolling stock

resistance. It also calculates the behaviour and characteristic sections and determinates

if trains are in acceleration phase, braking phase or constant speed phase. Using all

this data, the computation of running times is performed for every track circuit along

the routes of trains and for the whole routes. Using the same infrastructure and rolling

stock, we also used OpenTrack to compute running times. We made a comparison be-

tween running times in order to evaluate the gap between our program and OpenTrack.

For both infrastructures modelled we reached very good results since the average time

difference is lower than 1 second for the whole trains’ routes.

We designed and implemented a program to compute running times in presence of

traffic. Given a perturbed scenario, the program evaluates if conflicts occurs between

trains: for each arising conflict, it finds the two trains involved in it and in which track

circuit it occurs. Using the solutions computed by the RECIFE-MILP algorithm, the pro-

grams finds which train has the priority in the track circuit where the conflict arise. Then

the aspects of signals that the trains with low priority faced along its route are recreated

in order to avoid the conflict. The new running time of the train with low priority is

re-estimated in agreement with the signalling system and considering consequences of

acceleration and braking phases.

6.1 Future works

Despite the encouraging results obtained by our Running Time Estimation Program,

more experiments should be done using infrastructures with different characteristics.

Although for the two infrastructures modelled in our work we didn’t have the curves

values, our program is configured to take them into account. Thanks to its flexibility,

the program leaves room for improvements: more variables such as human behaviour

of a train drivers, weather conditions or track conditions can be included to make the

computation of the running time more closer to real world.

58

6.1. FUTURE WORKS

Concerning the Running Time Estimation Program with Traffic, an extensive compari-

son with OpenTrack is required in order to verify the accuracy of the results: different

infrastructures, different rolling stock and more perturbed scenarios should be taken

into account. Furthermore, the program can be used to evaluate the conflict solutions

computed by RECIFE-MILP and it could be used to evaluate solutions computed by other

algorithms: it is sufficient that the solution files of the others algorithm have the same

format and structure of the one of RECIFE-MILP.

59

BIBLIOGRAPHY

Barter, W. (2004).

Forecasting robustness of timetables.

Computers in Railways IX, pages 563–572.

Carey, M. and Kwiec, A. (1995).

Properties of expected costs and performance measures in stochastic models of sched-

uled transport.

European Journal of Operational Research, pages 182–199.

D’Ariano, A. (2008).

Improving Real-Time Train Dispatching: Models, Algorithms and Applications.

PhD thesis, Department of Transport & Planning, Faculty of Civil Engineering and

Geosciences, Delft University of Technology.

D’Ariano, A., Pacciarelli, D., and Pranzo, M. (2007).

A branch and bound algorithm for scheduling trains in a railway network.

European Journal of Operational Research, 83:643–657.

Hansen, I. A. and Pachl, J. (2008).

Railway Timetable & Traffic.

Eurail press.

Hauptmann, D. (2000).

Automatic and non-discriminatory train path allocation in railway networks of arbi-

trary size.

Dissertation an Institut fur Verkehrswesen, Eisenbahnbau und -betrieb, UniversitatHannover.

Huerlimann, D. and Nash, A. (2010).

OpenTrack manual, version 1.6.

61

BIBLIOGRAPHY

OpenTrack Railway Technology Ltd. and ETH Zurich Institute for Transport Planning

and Systems.

Pachl, J. (2002).

Railway Operation and Control.VTD Rail Publishing.

Pellegrini, P., Marlière, G., Neamatian-Monemi, R., and Rodriguez, J. (2015a).

Deliverable 2.4. report on the experimental analysis on the saturation method.

Technical report.

SIGIFRET project.

Pellegrini, P., Marlière, G., Presenti, R., and Rodriguez, J. (2015b).

RECIFE-MILP: An effective MILP-based heuristic for the real-time railway traffic

management problem.

Intelligent Transportation Systems, 16:2609–2619.

Pellegrini, P., Marlière, G., and Rodriguez, J. (2013).

Boosting the performance of a milp formulation for railway traffic management in

complex junctions.

Models and Technologies for Intelligent Transportation Systems, pages 419–428.


Optimal train routing and scheduling for managing traffic perturbations in complex

junctions.

Transportation research Part B, 183:58–80.


A detailed analysis of the actual impact of real-time railway traffic management

optimization.

Journal of Rail Transport Planning & Management. To appear.

Radtke, A. and Watson, R. (2007).

Railway simulation in the United Kindom.

RTR1, pages 24–28.

Rodriguez, J. (2007).

A constraint programming model for real-time train scheduling at junctions.

Transportation Research Part B, 41:231–245.

62

BIBLIOGRAPHY

Rodriguez, J., Delorme, X., Gandibleux, X., Marlière, G., Bartusiak, R., Degoutin, F., and

Sobieraj, S. (2007).

RECIFE: models and tools for analyzing rail capacity (in french).

Recerche Transports Sécurité, 95:19–36.

Samà, M., Pellegrini, P., D’Ariano, A., Rodriguez, J., and Pacciarelli, D. (2016).

Ant colony optimization for the real-time train routing selection problem.

Transportation Research Part B: Methodological. To appear.

Sobieraj, S., Marlière, G., and Rodriguez, J. (2011).

Simulation of solutions of a fixed-speed model for the real-time railway traffic opti-

mization problem.

RailRome 2011, International Seminar of Railway Operations Modelling and Analysis.

Theeg, G., Maschek, U., and Nasedkin, O. (2009).

Railway Signalling and Interlocking. International Compendium.

Eurail press.

UIC (2004).

La capacité.

Fiche UIC406/R.

Wendler, E. (2001).

Quality management in the operation planning process by means ofharmonized mod-

elling.

Proceedings of the World Congress on Railway Research.

63

“ . . . e quindi uscimmo a riveder le stelle.”