Due to increasing passenger demand and thus increased frequency of trains on the famous Cusco – Machu Picchu line in the last decade, a need has been identified to improve the current safety and traffic control system.
The operator was looking for commercially attractive solutions based on innovative information and communication technologies which ensure better management, control and monitoring of the movement of trains, improving the operational efficiency and optimizing the use of human and material resources. Intelligence on Wheels and their Latin America representative Ferrostaal Peru were jointly invited to present their Train Collision Avoidance System (TrainCAS) and demonstrate its feasibility on-site.
To do so, two of Perurail’s railcars of type Macosa were temporarily equipped with the TrainCAS system. On each train, one onboard unit (OBU) was mounted for the demonstration rides foreseen as part of the regular public train service. As the system does not require any component in the infrastructure and entirely relies on onboard components (“virtual infrastructure”), it took less than four hours to equip both trains and have the system fully up-and-running. Both trains were temporarily equipped with an OBU, comprising a direct train-to-train radio, a localization submodule and a robust railway-computer. Connected to an antenna on the vehicle’s roof and the batteries of the railcar, both vehicles were immediately ready to go onto regular service afterwards. To demonstrate the available human-machine-interfaces for the train drivers, one “essential HMI” was mounted in the passenger area of one of the railcars. Additionally, detailed insight to the algorithmic output was provided to the operator attendees through a management console. A final installation would also have a connection to the brake valve to initiate a braking maneuver in case of an alarm.
With this equipment on board, both trains were part of the scheduled regular train service running several times on the line. During these rides the system concept was explained in full detail. This included in particular the fact that the system makes use of an electronic track map which is stored locally on each onboard unit, and that there is no centralized communication necessary for the collision avoidance functionality. It was also explained under which circumstances an alarm is raised, what are the various conditions which are observed and how the point in time for an alarm is dynamically determined. Of course the configuration can be adapted to the requirements of infrastructure and train operators (e.g. adding pre-alarms or use different thresholds).
It was very surprising to the operator’s staff that the full functionallity is given even in areas where there was no cellular mobile phone network (3G/4G) coverage available – which was the case in approx. 40% along the railway network between Ollantaytambo and Machu Picchu Pueblo stations. However, whenever a “network coverage of opportunity” is given such as 3G/4G or Wi-Fi in some stations, all the data collected on 100% of the railway network and continuously evaluated by the system can be provided to some central monitoring station, even in store-and-forward mode for non-realtime evaluation (e.g. speed and acceleration profiles, or travelled distance and schedule deviations by each vehicle per day). Likewise, control data such as additional speed limits can be provided to the trains via any network of opportunity to temporarily restrict the velocity in specific parts of the railway network if required.
Several crossings of the equipped trains were planned per day in Desvio Pampacuhua station where the system clearly demonstrated in all cases that no false alarm is raised for regular crossings of the trains, i.e. when the trains are passing each other on separate tracks, which the system clearly identifies, as can be seen in the following enlarged picture (blue are the trains, green the current braking distance of a moving train).
The following pictures show a whole series of snapshots from a crossing of train 222 coming from Ollanta and reaching Pampacuhua first, with train 221 coming from Machu Picchu as second. As mentioned, no alarm was raised in any of the crossings, which was exactly what was to be expected for regular crossings on parallel tracks.
Here the system demonstrates its particular and unique feature of being a “guardian safety angel” without any interaction of the train driver under regular (i.e. non-alarm) operations. Simply by two trains coming into communication range of each other, the direct train-to-train messages are exchanged (in the crossing scenario illustrated above this was at a distance of 4.9 km, the exact range varies given the environment), the system fulfills its protection function. This inherently goes in line with the fact that the principal collision risk increases for closer trains and the direct train-to-train communication improves correspondingly. Once again, this safety enhancement does not require any base station network coverage, and no alarm is raised because two trains just being close.
As there was – as expected – no collision alarm to be seen and heard on the driver’s interface at any crossing, a portable version of the onboard unit was used to “emulate” another train which was on the same track than the equipped train. First this emulated train (a person carrying the portable device next to the track) was “driving” towards the train shortly before it was reaching Ollanta. The train’s onboard unit clearly identified the imminent danger of a front collision and provided an alarm on the essential HMI – early enough to bring the train to a safe stop with regular braking. After leaving Ollanta station, the same setup was used to emulate a rear-end collision of the train with the portable unit. Again, the alarm was well placed.
The train rides coincidently provided another scenario, which was not planned but is very relevant for the operator: A fallen tree was blocking the track in front of train 222 for about 2 hours.
This situation is not at all a rare occurrence (on the next day some rocks were blocking the track for 3.5 hours). The tree blocking was in an area without any cellular nor operational radio network coverage. The operator sent two of its staff members with mobile radios along the track in opposite direction, to move at least 500 meters in order to warn any approaching trains. By coincidence the following train was train 221, also equipped with the TrainCAS system. As soon as the trains were 6.7 km apart, they were fully aware of each other (see the following screenshot). In case the regular communication approach would have failed and/or no staff member would have been available to “manually” warn the approaching following or opposing train, the system would have raised an alarm once passing the configured thresholds as this is exactly one of the situations it is designed for.
In general the system has proved full operational capabilities even with a very preliminary version of the electronic map, minimal calibration of sensors and temporary mounting under the real challenging environmental conditions of the particular track. The following picture shows just with an example that shadowing and destructive reflections are very big challenges for conventional communication and satellite navigation systems along the Cusco – Machu Picchu track.
The temporary installation was a huge success in demonstrating the system’s capabilities. Continuous accurate track-selective localization along the entire track was given using onboard sensors only. Direct train-to-train communication was working properly for the collision avoidance application. Any network coverage of opportunity can be used for bidirectional exchange of messages with a control center or the maintenance team. A particular strong argument for the approach is its flexibility to be adapted to the customer’s needs in a very efficient and economical way. With this system’s approach almost all the well-established existing procedures may stay in place, by adding another layer of safety. All the data collected by the system can be evaluated for additional use cases, and additional interfaces for external systems can be provided if desired.