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: