Date:Mai 04, 2015

Single-tracked to Machu Picchu

Timetable construction and simulation of incidents for the Peruvian Railway on the Cusco – Machu Picchu line

Client: PeruRail
Project period: February 2008

Initial situation
In the 15th century the Incas built the estate Machu Picchu more than 2000 metres above sea level. Nowadays, the ruin is a popular destination for tourists. The increasing amount of visitors results in a constant growth of passengers travelling on the single-track between Cusco and Machu Picchu.  Due to the mountainous conditions some track sections of the 120 kilometre line have to be passed in a zigzag course.

Not only the very high gradients (>30 ‰), but also old fashioned, original vehicles as well as poor infrastructure conditions and frequent track blockages due to falling rocks lead to delays in the operational process.

Challenge
Small and local disturbances can affect the whole network. The dispatcher has to find a reasonable regulation to reduce the delay and restore the scheduled timetable.

The display of all track features in RailSys is required for the determination of possible solutions for trouble-free performances. Hence, PeruRail will have access to an easily operated and productive planning tool to create infrastructures and timetables.

Furthermore, by the use of RailSys the dispatcher will be able to react directly to any perturbations. Automatic measures shall restore the scheduled timetable immediately.

Strategy
Plans and on-site inspections provide the necessary data for a microscopic display of the existing infrastructure in RailSys. Every peculiarity of the infrastructure, e. g. single-way track sections and the different maximum speeds, is considered. For a detailed running time calculation, profiles with the driving dynamics for all involved vehicles will be created.

Due to the single-track section, the long travel time from Cusco to Machu Picchu (up to 6.5 hours) and the 45 daily train runs between 4 am and 11 pm, barely any capacities remain. This even increases the consequences that small local delays have on the whole network.

To recreate this case, realistic perturbations are simulated in collaboration with the dispatcher. Automatic dispatching decisions are individualised in RailSys and adapted to the regional conditions.

Result
The dispatcher is now able to simulate several dispatching possibilities in RailSys in a time lapse to find the best solution for the restoration of the scheduled timetable.

Discussions with the dispatcher have shown that RailSys generates useful and convertible solutions within seconds.