View
214
Download
0
Category
Preview:
Citation preview
Real Time Train Rescheduling@ SNCF
2
Agenda
• Essentials
• Basic Model
• Applications
Traffic density is getting very high in several networks and management areas also tend to grow. In consequence, traffic management complexity is rising and management system have to evolve.
A major challenge today is to study efficient tools to help experts’ decisions in the rescheduling process of tomorrow.
3
Essentials about Real Time Rescheduling
• Essentials– An overview of the problem
– Main challenges
• A Basic Model
• Applications
4
An overview of the problem
• Aim : on line recomputing railway schedule following perturbations.
• Method : minimizing the total accumulated delay.
• Nowadays, SNCF has developed 3 off line prototypes working within a train simulator (SiSyFe),
• This allows us to study formulations and optimization techniques.
5
Main challenges
Rescheduling requirements:– Tractable - Fast calculations ( < 10 min)– Operational solution – must be immediately applied
on the field– … (good enough solution)
Remark:initial timetable can be used to construct a first feasible solution!
6
A brief look at a model formalizing the train rescheduling problem & the railway operations.
• Essentials
• A Basic Model– Network formalization
– Variables
– Constraints
• Applications
7
Formalizing:Railway network is a graph.
Station (simple)
Junction, switches, …
Complex station
Track
nodes are stations or switches, and edges are interconnecting tracks.
8
Decisions Variables
Rescheduling decisions concern:
• Time of departure and arrival at each node,
(this is equivalent to speed variation considerations )
• Sequencing of trains at nodes,
• Track choice.
• (cancellation)
These decisions have to respect:
operational constraints & commercial constraints.
9
Constraints (examples)
The following examples of constraints are associated with each train (c) at each node (n) of the network.
Headways:• In order to prevent conflicts, trains must be spaced. We impose a specific separation time
between departures (D) and/or arrivals (A) of the two trains (c1 & c2 with c1 before c2 ):Min_spacing A(c1,n) - A(c2,n) && Min_spacing D(c1,n) - D(c2,n)
Running times:• Note: considering a minimal and a maximal running time to reach one node from another
is equivalent to imposing speed limits:Min_run A(c,n2) - D(c,n1) Max_run
Stops duration:• Due to commercial and operating factors (maintenance, for example) stopping times
must be bounded: Min_stop D(c,n) - A(c,n) Max_stop
Other specific constraints:• connections between two trains, shuttles, …• we must take into account track choice and sequencing (and cancellation).
10
Linear Programming Model
155,1v.1
11
Applications @ SNCF
• Essentials
• Model
• Applications– Software system @ SNCF
– 1.Traffic fluidification,
– 2.Traffic control,
– 3.Re-routing.
12
Software system implementation
155,1v.1
Train simulator
Takes into account:
•Infrastructure,•Signaling system,•Rolling stock,
•Incidents,•Traffic Control orders,
•Drivers’ behavior
Initial timetable
Control
(positions, …)
Command
Incidents detection
LIPARI Software System
Re-scheduling tools
Timetabling variations monitoring
New Schedule with new :•Routing,•Sequencing,•Timetables.
Translation into commands:•Sequence programming,•Route programming.
Implementation
Sardaigne
• Experimental design,
• Statistical analysis results
incidents
13
1- Traffic fluidification
• Aim: manage closely a railway node to prevent conflict between pairs of trains in order to ensure fluidity of the traffic.
• Decisions: speeds, re-sequencing.
155,1v.1155,1v.1
Spac
e
time
First speed limitation(incident)
With fluidification Withoutfluidification
gain
SignalingsystemSecond speed limitation
(consequence)
14
1- Rémilly - Baudrecourt
155,1v.1
<1 B>
<2 B>
<2
<2
<1
<1
Poste 2 de Metz-Sablon
SEI de Lamorville
Benestroff
St-Avold
< 2 B >
C3
J4
J1
J2
J3C1
C2
• Management of pairs of predictable conflicts.
• Radius = 50 km
• very heterogeneous traffic (from international freight
to TGV)
15
1- Conclusion about traffic fluidification
155,1v.1
Experiments showed 2 problems:
– simplex method vs. robustness of solutions,
– linear programming vs. acceleration modeling.
Real experimentations are not scheduled due to:
– lack of operational equipment (Galileo/GPS, GSM-R, …)
16
2- Traffic Control support tool
• Objective: re-compute precisely a new railway schedule following perturbations and help experts in traffic control decisions.
• Scope: minor incident management (e.g. few minutes delays in a heavy traffic area)
• Decisions: timetable, re-sequencing and track choice.
17
1- Tours-Bordeaux, Éole, …
155,1v.1
• Incidents:
– delay at the entrance
– delay during a stop
(5-30 min)
• Tours-Bordeaux
– 100.000 var.
– 200.00 const.
– Time limit < 5mn
• ÉOLE project (link between east & west
networks in Paris)
– up to 540 trains
18
2- Conclusion about traffic control tools
Studies show:– The sensitivity of solutions: few variations (e.g. 3s) can
lead to problems. (see traffic fluidification)
– Real size of problems were treated.
Perspectives:– Experimenting different models
– Extending the model’s scope (fluidification/routing)
– Integrating in the future control system.
19
3- Insertion of re-routed trains
• Scope: major incident (e.g. major line breaks down)
• Principle: trains are to be inserted in a new schedule considering a set of pre-defined routes.
• Uses a less accurate description of the network. (macroscopic)
• Resolution method can be tuned to this specific problem.
Original Schedule
Trainsto be inserted
Original Schedule
Inserted Trains
Cancelled Trains
Before optimization After optimization
20
3- Lyon – Paris High Speed Line (LGV 1)
155,1v.1Incident:
– 230 km of “LGV ” is down
– re-routing by Dijon.
Exemple:– Time window: 16h-24h– 80 trains– 30 nodes– 1380 nodes-trains
21
3- Conclusion about rerouting
Remarks:
– looks like a “capacity management tool” (i.e. a basic planning tool)
– Macroscopic description leads to refine solutions in a second stage.
Problems:
– Today, cancellation of trains in inhomogeneous traffic is a hard bargain (regulation).
– New developments concern (homogeneous) suburban traffic.
22
Global Conclusions
Real Time Train Rescheduling @ SNCF:
Essentials/Model/Applications.
About objective function, optimality,… and robustness!
23
Criteria & robustness
What should we optimize?
– Sum of total delays,
– Delays perceived by clients, (including connections, etc ..)
– An economic cost function, (delay fees)
– Capacity management,
– … ?
Criteria may differ, but robustness is the common goal of infrastructure managers.
Not (only) robustness of optimality, but most of all robustness of feasibility!
24
Robustness(es)
Indeed, from an industrial point of view, robustness is a key goal:the “best” solution must be operational …
i.e. robust against minor incidents.
Because :
– control system cannot monitor precisely all micro-events,
– great inertia of machines & human factors make precise controlling difficult,
– … life is not predictable !
=> Now, how can we achieve this goal ?
Thank you for your attention!
more on:
Recommended