html5-img
1 / 25

Real Time Train Rescheduling @ SNCF

Real Time Train Rescheduling @ SNCF. Agenda. 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.

mingan
Télécharger la présentation

Real Time Train Rescheduling @ SNCF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Real Time Train Rescheduling@ SNCF

  2. Agenda 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. • Essentials • Basic Model • Applications

  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. 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 operatingfactors (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 v . 1 1 5 5 , 1

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

  12. Software system implementation Sardaigne Experimental design, • results Statistical analysis • Initial timetable incidents v . 1 1 5 5 , 1 LIPARI Software System Incidents detection Train simulator Timetabling variations monitoring Control (positions, …) • Takes into account: • Infrastructure, • Signaling system, • Rolling stock, • Incidents, • Traffic Control orders, • Drivers’ behavior Re-scheduling tools • New Schedule with new : • Routing, • Sequencing, • Timetables. Implementation Command • Translation into commands: • Sequence programming, • Route programming.

  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. Without fluidification Withfluidification gain First speed limitation (incident) v 1 . 1 5 5 , 1 v . 1 1 5 5 , 1 Space time Signaling system Second speed limitation (consequence)

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

  15. 1- Conclusion about traffic fluidification 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, …) v . 1 1 5 5 , 1

  16. 2- Traffic Control support tool • Objective: re-compute precisely a new railway schedule following perturbations and help expertsin 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, … • 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 v . 1 1 5 5 , 1

  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. Before optimization After optimization Original Schedule Original Schedule InsertedTrains Trains to be inserted CancelledTrains 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.

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

  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 ?

  25. Thank you for your attention!more on:

More Related