Tesi magistrale Martino Marangon

University of Trieste
Department of Engineering and Architecture
Master Degree in Computer Engineering
Master Student
MARTINO MARANGON
Analysis of the impact of speed variation dynamics on the optimization of
the real-time railway trafﬁc 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 potrebbero
influenzare la regolare circolazione dei treni. Questi problemi potrebbero causare ritardi
e 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 la
propagazione di questi ritardi. È un processo complicato che richiede soluzioni efficaci
in 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 le
modifiche 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 del
traffico 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 il
profilo di velocità di un treno resta attinente a quello programmato: nel caso in cui si
verifichi un conflitto, non vengono tenute in considerazione le conseguenze delle fasi di
accelerazione e frenata. Nei modelli a velocità variabile, il profilo di velocità di un treno
viene aggiornato in modo da includere le conseguenze di possibili conflitti a causa di
vincoli imposti dal sistema di segnalazione. I modelli a velocità variabile sono più completi
ed accurati, tuttavia sono i meno utilizzati in quanto sono difficili da risolvere in tempi
brevi di computazione. In questa tesi verranno presentati due algoritmi per la gestione
del traffico in tempo reale: ROMA e RECIFE-MILP, concentrandoci particolarmente
sull’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 possa
essere utilizzato per valutare le soluzioni ai conflitti calcolate da algoritmi che operano
in velocità fissa. Dato uno scenario perturbato (l’ammontare di ritardo di cui i treni
soffrono 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 dato
algoritmo 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 è lo
sviluppo di un programma avente lo scopo di raccogliere ed ordinare molteplici dati,
inerenti l’infrastruttura ferroviaria ed il rolling stock dei treni. Questi dati, provenienti
da 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 informazioni
sull’infrastruttura e dettagli del rolling stock, vengono calcolate le resistenze che un
treno affronta lungo il percorso e viene determinato quando e dove il treno si trova in fase
di 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’intero
percorso del treno.
Al fine di valutare la qualità dei risultati ottenuti dai nostri programmi, li abbiamo
confrontati con un software di simulazione ferroviaria (OpenTrack). Per l’esecuzione
degli esperimenti, sono state prima modellate e poi utilizzate due infrastrutture: il nodo
di Pierrefitte-Gonesse ed il nodo tra Rosny-sur-Seine e Saint-Etienne-du-Rouvray. Per
entrambe le infrastrutture i risultati ottenuti sono stati incoraggianti: in tutti i casi
studiati, la differenza media del tempo di marcia calcolato dal nostro programma e da
OpenTrack è stata intorno o inferiore al secondo lungo l’intera linea. Il programma
sviluppato è caratterizzato da un altro punto di forza: ha un’elevata flessibilità. Esso
infatti può essere facilmente modificato in modo da includere maggiori variabili, quali le
condizioni del meteo o il comportamento dei macchinisti, in modo da rendere il calcolo
del tempo di marcia più attinente alla realtà.
Si è completato un primo sviluppo del programma per valutare le soluzioni calcolate
da 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 delle
fasi di frenata ed accelerazione. Tuttavia, in alcuni scenari, i risultati ottenuti non si
sono 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 errori
e apportare opportune correzioni.
iv

ACKNOWLEDGEMENTS
I
l primo pensiero è rivolto a Mamma e Papà, a cui questa tesi è dedicata, per avermi
sempre 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 avermi
sempre sopportato e supportato in tutti i momenti tristi e felici passati in questi mesi. Il
tuo aiuto nel portare a termine questa avventura è stato prezioso e difﬁcile da misurare:
questa tesi è dedicata anche a te.
Ringrazio molte Lorenzo per avermi concesso l’opportunità di svolgere questa tesi a
Lille 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 il
meglio. In particolare, ringrazio mio cugino Stefano (Rotti) per tutti gli anni felici passati
assieme. Un grazie di cuore alle mie due zie Agnese e Roberta, per aver sempre creduto
in 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, ringrazio
Andrea (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 1
1.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 7
2.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 33
4.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 49
5.1 Running Time Computation with Traffic Program . . . . . . . . . . . . . . . 49
5.2 Running Time Computation with Traffic Program Example . . . . . . . . . 52
6 Conclusions 57
6.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
trafﬁc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

CHAPTER
1
INTRODUCTION
1.1 Motivation of the study
T
rain 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 ﬁxed 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: Modelling
Infrastructure 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

CHAPTER
2
AN OVERVIEW ON RAILWAY AND TRAFFIC
MANAGEMENT
T
o 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 ﬁxed 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 signals
the aspects are given by lights. In this thesis, when we talk about signals, we will always
refer to light signals. The ﬁgure 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 Minimum
Headway 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 ﬁrst 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 ﬁrst 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 ﬁgure 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

CHAPTER
3
MODELLING INFRASTRUCTURE AND ROLLING STOCK
I
n 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 ﬁle.
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 Pierreﬁtte-Gonesse (Rodriguez, 2007)
3.3.2 Rosny sur Seine - St. Etienne du Rouvray
The structure of the node is presented in ﬁgure 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 Stock
Pierrefitte-Gonesse 2.1 1.2
Rosny 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

CHAPTER
4
RUNNING TIME COMPUTATION
T
he 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 inertial
resistance. 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, curve
resistance 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
ﬁgure 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 [ ]. 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 ·
I
1000
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.3
r −55
· m f or r ≥ 300m
RB =
4.91
r −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 (ﬁgure 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 ﬁnish 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 ﬁrst 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 =
v2
max1
2d
−
v2
max2
2d
If sred is shorter than the length of the section, the section is split into two parts.
The ﬁrst 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 + v2
max2
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 and
Pachl, 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 =
F
m
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 and
Pachl, 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
t1
a dt or a =
dv
dt
The distance covered can be calculated by repeated integration of the following equation:
s = s0 +
t2
t1
v dt or v =
ds
dt
In 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)− v
aw
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 ﬁgure 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 Time
Computation
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
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.
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
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, Pierreﬁtte-Gonesse
node

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

CHAPTER
5
RUNNING TIME COMPUTATION WITH TRAFFIC
I
n 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 Traffic
Program
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 Time
Estimation
Program with
Traffic
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 Trafﬁc
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 Traffic
Program 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 Time
TGVa 14790 434
TGVb 14805 403
Table 5.1: Length (in meters) of the route and running time (in seconds) in absence of
traffic
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 priority
In 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 Conflict
TGVa 434 434
TGVb 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 priority
In 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 Conflict
TGVa 434 674
TGVb 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 speed
diagram 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: Conﬂict solved - TGVb has the priority - Distance vs speed diagram
Figure 5.8: Conﬂict solved - TGVb has the priority - Blocking Time Stairways Diagram

CHAPTER
6
CONCLUSIONS
T
he 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 & Trafﬁc.
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, Universitat
Hannover.
Huerlimann, D. and Nash, A. (2010).
OpenTrack manual, version 1.6.
61

Tesi magistrale Martino Marangon

Tesi magistrale Martino Marangon

Recommended

Recommended

More Related Content

Similar to Tesi magistrale Martino Marangon

Similar to Tesi magistrale Martino Marangon (20)

Recently uploaded

Recently uploaded (20)

Tesi magistrale Martino Marangon