Dr Chris Morris answers our questions on the new Network Rail Acumen Platform Docker, to which he and PhD student, Richard Horridge, contributed heavily on software development. Both provided consultancy on appropriate technologies to choose.
What’s the project?
It’s known as the Network Rail Acumen Platform Docker. It’s a real-time information tool for signallers and station staff. The tool takes data from the signalling system and displays information from it for the benefit of both signallers and station staff.
Surely that’s already available?
The data is collected across the network but it’s not available everywhere and not in the format that we have developed nor is it available in a cost effective way. Previously, staff in locations which lacked complete traffic management systems had to rely on phone calls to ask signallers to make relevant changes. This tool automates that process. This tool also provides significant extra information to station staff and makes information quicker and easier to access for signallers, bringing everything up to date and ultimately levelling up the playing field.
What does it do?
It displays information including predicted train locations; actual train locations; status of trains (including timeliness, need for changes to be made etc); and performance data / customer information. It is highly visual, using map, layout and timetable displays of the information so the user can access it in a way which works for them and station staff have up to date, accurate information to pass on to customers.
Problems, such as services entering one platform and leaving from another, or entering platforms which are out of use, are highlighted and the users are able to communicate with the signal box, for example to get the train re-platformed.
It can show signallers and station staff a quick overview of potential problems across a route by showing a map with all of the services timetabled to call at a specific station. The real-time benefit of this product is that it gives a visual indication of lateness which means the signallers can take an immediate, informed choice of action instead of having to make a phone call to find the right person with the right information – all of which takes precious time.
The system updates for each service whenever the train passes a signal. This feeds into the active forecast for the service which then estimates its time of arrival at the targeted station. The forecast keeps track of any changes made by application users to the running of the service e.g. platform changes, arrival, departure and pass time changes etc. and can be displayed to application users in several ways. This can be as a listing of calling points, as a map (e.g. in the train positioning example) and in a default view which displays the forecast lateness of services in the current station.
Give me a couple of examples of its use please.
Ok, here are a few scenaorios (all fictional services and places).
Late running service:
The London Midland train from Euston is running late and will be late arriving into Crewe Platform 5, where it is due to become the train to York. Another train, running to time, will be in platform 5 when the Euston service arrives. The signaller must decide where to put the late running train. The platform docker shows the best options and reminds the signaller about moving the outbound service. It communicates the signaller’s decision to the station staff, who can update passengers and passenger information systems (including, but not limited to, DARWIN).
Crew awaited:
Station staff in York have marked train as ready to depart, but note that the replacement driver is not present. The station staff can use the application to notify the signaller of this so the signaller can allow another train to go instead. Previously, the signaller would have been left guessing why the train wasn’t moving, eventually phoning the station and delaying several other trains whilst waiting to find a member of staff able to come to the phone and who also has the relevant information.
Train with a defect:
A defect has been reported a train, and the engineering team say they will need access to the right hand side of the train to fix it. An alert can be put on the train to request it goes into an appropriate platform to enable the repair.
Trains join:
There are two CrossCountry services which join at New Street Station to form one larger onward service. The first, larger, part of the train is sitting, waiting, at New Street but the other part is delayed. Meanwhile the platform is timetabled to another service, which is running to time. A signaller spots a vacant platform and replatforms the shorter CrossCountry service to it. However, the system gives a warning about the planned association between the two services, meaning the signaller can realise the replatforming is a silly idea and delays the train until it can go to the correct platform, thereby avoiding potential chaos in getting the trains together to join them.
What stage is it at?
User acceptance testing is passed and staff training has started, prior to deployment at York station, with Crewe and Birmingham New Street expected to follow shortly.