Trains are, in many respects, wonderful machines. They’re simultaneously both the most romantic form of travel and the most grueling way to get to work every morning. One thing trains are not however, is up-to-date with modern technology.
Whilst you can follow the course, in real time, of a plane soaring at 36,000 feet above the ground all the way from San Francisco to London you may be surprised that Train Operating Companies (TOCs) lack the ability to pinpoint the locations of their trains between stations. In other words, they may know that your train is between Cambridge and Foxton but they wont know exactly where.
Not knowing exactly where Trains are doesn’t cause any satefy issues — Block Signalling has been used to safely manage the passage of trains by identifying which “block” of track they were in, without an exact location, since the 1850s — however, it does mean that the decisions that control rooms make are being made on educated guesses of a trains exact position at any given time.
Control rooms are the brain room of the modern railway and make decisions when things go wrong. If you’ve ever been told a train cannot run due to a “lack of train crew” its unlikely the driver was off sick and instead much more likely that a delay on a train they were driving earlier has cascaded down to your service and they simply never arrived at your station to drive the train. Control rooms try to avoid this — and many other issues.
Our earlier examples of Cambridge and Foxton aren’t exactly a million miles apart, and on a normal service you would expect a train to travel between them in around 5 minutes — but as the railway gets more and more congested making real-time decisions based on a time resolution of minutes will result in more and more decisions resulting in delays and cancelations.
After having learnt about this situation, whilst onboard HackTrain 2.0, I decided to have a go at resolving it in my own time.
One constraint of working with technology for use on trains is that, for all intents and purposes, you cannot add hardware to trains. The Rail Industry in the UK is, thankfully, obsessed with safety and that means that anything added to a train has to go through rigorous Health & Safety checks. This means it can take months, or years, for anything to be installed trackside or in a vehicle.
Whilst staff who work for South West Trains (who explained the situation to HackTrain competitors) are all issued with BlackBerry devices, some companies have started issueing their Guards and Conductors with relatively modern Android devices, some of which even act as ticket printing machine for on-the-train ticket purchases.
Armed with this knowledge I decided to try and validate my idea that a train could be tracked using just the smartphone device a member of train crew is already carrying. As I didn’t know if the idea would work in reality I set about making a working prototype with the minimum possible effort.
My acceptance criteria was pretty simple: Be able to view in real time the position of a train from Cambridge to Kings Cross. This wasn’t exactly the most measurable criteria (what does “real time” mean, for example?) but it gave me something to work towards.
I walked down a few streets with my prototype client open in the Safari Browser on my iPhone and it appeared to report its location to the server as intended. So, on one of my final commutes into work before the holiday season I tested the system on a moving train on a route that includes tunnels, large areas of poor phone signal and central London; and all the different challenges these environments bring.
I was pleasently suprised with the results, shown above , despite a few anomalies.
Due to the fact I was using the `watchLocation()` function the train didn’t report its location in even time periods, as it would if you were polling the location, but rather only when the trains position changed significantly. Despite this fact, the period between the train attemting to send its location whilst on the move was never more than around 10 seconds.
I say attempted because, as expected, there were some issues with mobile coverage. I had expected to have issues in tunnels, but actually only the final tunnel before Kings Cross (which goes under the Grand Union Canal) caused issues. Lack of signal otherwised occured in a few blackspots in rural Cambridgeshire. This issue could be mitigated by employing a system such as that provided by Nomad Digital which provides an internet connection to a train using multiple sim cards connected to multiple network providers.
Another issue you can see in the above screenshot is that my train appears to have left the tracks a few times. I can assure you that this didn’t actually happen, but appears to have done so due to a combination of some inaccurate GPS readings and some failed data transfer caused by the aforementioned network connectivity problems. These errors could be mitigated using a host of techniques: comparing GPS position to known track locations, buffering changes in location that seem too great and only accepting them as true if subsequent location changes appear to be in the same area.
This was a pretty interesting project to work on. It gave me an oppertunity to develop a simple solution to a real life problem in a short period of time and learn about the awesome Socket.io library. I was happy to see it work so well, and to be wrong about tunnels. I look forward to making some of the improvements I’ve mentioned in this post and making the UI prettier and data storage a little bit more resilient.