1. Real Time Train Rescheduling @ SNCF

2. 1 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. 2 Essentials about Real Time Rescheduling Essentials –An overview of the problem –Main challenges A Basic Model Applications

4. 3 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. 4 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. 5 A brief look at a model formalizing the train rescheduling problem & the railway operations. Essentials A Basic Model –Network formalization –Variables –Constraints Applications

7. 6 Formalizing: Railway network is a graph. nodes are stations or switches, and edges are interconnecting tracks.

8. 7 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. 8 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. 9 Linear Programming Model 155,1 v.1

11. 10 Applications @ SNCF Essentials Model Applications –Software system @ SNCF –1.Traffic fluidification, –2.Traffic control, –3.Re-routing.

12. 11 Software system implementation 155,1 v.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. 12 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,1 v.1 155, 1 v. 1 Space time First speed limitation (incident) With fluidification Without fluidification gain Signaling system Second speed limitation (consequence)

14. 13 1- Rémilly - Baudrecourt 155,1 v.1 Management of pairs of predictable conflicts. Radius = 50 km very heterogeneous traffic (from international freight to TGV)

15. 14 1- Conclusion about traffic fluidification 155,1 v.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. 15 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. 16 1- Tours-Bordeaux, Éole, … 155,1 v.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. 17 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. 18 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 Trains to be inserted Original Schedule Inserted Trains Cancelled Trains Before optimization After optimization

20. 19 3- Lyon – Paris High Speed Line (LGV 1) 155,1 v.1 Incident: –230 km of “LGV ” is down –re-routing by Dijon. Exemple: –Time window: 16h-24h –80 trains –30 nodes –1380 nodes-trains

21. 20 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. 21 Global Conclusions Real Time Train Rescheduling @ SNCF: Essentials/Model/Applications. About objective function, optimality,… and robustness!

23. 22 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. 23 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 ?

25. Thank you for your attention! more on: