Open Train Times

Producing a robust timetable and equipping it with systems that can minimise the effects of any disruption (see accompanying article) is one thing, but conveying all this real time information to the general public is something else.

When disruption occurs, it is a common complaint that ‘nobody knows what’s going on’ or ‘staff on the station don’t tell us anything’. This can be fair criticism and many readers will have experienced just these situations. Even when things are going well, information such as up-todate details of train times, platforms, train formation and suchlike can be a bit minimal at other than the busiest of stations.

Yet all the information is there, even if the associated decision making is not always as sharp as people would like. Can this information be conveyed to the public in a form that is understandable?

A trial some years ago at Peterborough involved the provision of a display screen in the concourse showing the train describer movements as being shown to the signaller in Peterborough Power Box. Cynics said that people would not understand what the diagram was conveying nor the head codes or the stepping functions. They were wrong and regular rail users soon learned to interpret the train movements and how these would relate to their intended journey. Maybe the travelling public are not as stupid as some people think!

Could the idea be extended further to make train movement data available as a national provision service that would be accessible from any smart phone or tablet device? One man who thought so is Peter Hicks, who is the driving force behind Open Train Times (OTT). Peter is a former IP Network engineer and now a Railway Systems consultant and software developer. He is also a rail commuter, so has first-hand experience of knowing what is needed.

Accessing the data

Since Network Rail compiles the timetable and owns all the signalling systems that deliver train movement information, getting its cooperation was clearly vital. The first step, however, was knowing what to ask for.

Train schedules are created in TPS (Train Planning System) for the current and next timetable period. This is exported in the rail-specific CIF format, the origins of

Rail Engineer | Issue 183 | April 2020 which date back to a mainframe system called TSDB (Train Service Data Base) developed by British Rail. A full timetable is around 600Mbytes of data and contains the timetable for 12 months. Shortterm changes and variations to existing schedules are loaded incrementally with updates published each night.

Nonetheless, Network Rail was asked if this CIF data could be made available with real-time data feeds for an open data project. The immediate answer was “nobody has ever asked for this before”, but a policy decision was eventually made to allow access. So far so good.

However, the next question was “can real time data be obtained and can we use this data for distribution purposes so that everyone can take advantage?” This was more difficult and it ended up being discussed at the Department for Transport’s Transparency Board. Eventually, the government decided that it was in the public interest and the data should be made available for general

information. The concept of OTT was thus borne, with the project starting out as ‘TSDB Explorer’ which was the first iteration of the site.

The data needed

In order to provide a credible real time train running information service, a number of data feeds are needed. These consist of: » TPS (Train Planning System) to give timetable data; » TRUST (Train Reporting using system TOPS) to give real time running data from designated reporting points; » TD (Train Describer) which delivers train running information derived from signal and berth data within signalling centres; » VSTP (Very-Short-Term Planning) which has in day and next day alterations to the timetable. From these, live track diagrams can be derived using other material such as the TPS network model and route learning material from TOCs. These diagrams can also be built using scheme plans, block schematics of the track and signalling layouts, but they remain drawn by hand. As well as high-level information about signal aspects, the Train Describer (TD) feed contains plenty of low-level information, including train movements and routes set between signals. These are based on signalling ‘berths’, which usually, but not always, represent individual signals. Train movements are represented by the train description passing from one berth to an adjacent one.

Train describer information is usually aggregated into TRUST for automatic train reporting, but there are still many low-density or rural lines that retain absolute block working often, with semaphore signals and non-continuous track circuiting. Open Train Times cannot generally provide information for these areas, which currently amount to about 20 per cent of the total, although this is always decreasing as signalling systems are modernised or replaced.

The TD data is delivered as a stream of updates, so not only is this a constant delivery, there is no ‘current snapshot’ available, which means systems have to build and persist their own berth data locally.

The data messages come as two classes. Firstly, there is C Class, equating to berth messages: » A step instruction to move a description from berth A to berth B; » Cancel - where a description is removed from the system; » Interpose - to cater for new descriptions being inserted when, for example, a train splits or joins. Most C Class messages are triggered by the train’s occupation or clearance of track circuit or axle counter sections.

Secondly, there are S Class messages, which give updates of anything the train describer is set up to provide, such as: » Routes set and/or signal aspects; » Point status conditions, normal or reverse; » Track circuit or axle counter sections; » TRTS (Train Ready to Start) plungers as used by platform staff; » Level Crossing operational status. Signalling functions are defined in Group Standard RT/E/C/11205 and any of these may be an output from the train describer. Signal aspect status has only two states – most restrictive (red) and not most restrictive (yellow, double yellow and green), equating to 0 or 1. Routes have one data bit per route letter and class and track sections can be either occupied or not occupied. All of this information is constantly updated and output.

There are also ‘latch’ messages that relate to an on/off status. TRTS plungers come into this category, where they are held ‘on’ until the route is set by the signaller. They can also be used for emergencies, such as to indicate the operation of a ‘Signal Group Replacement Control’ that instructs all signals in the area to be put back to red.

Open Train Times architecture

One might be forgiven for wondering why all this timetable, signalling and train describer information needs to be known in such detail. The answer is simple - if a service is to be offered to the general public, then it has to be accurate, timely and understandable. Poor information soon gets an unenviable reputation and will not be trusted.

The development of OTT has evolved. The architecture of the web site has grown to cope with the increasing number of users. The basic flow is as follows: Feed from Network Rail Open Data Message Queuing Servers (2 off) Processors (2 off) that consume the input data and update a database and in-memory data cache Multiple Web Clusters spread geographically Load Balancers Data out to Users.

The site is written in the Ruby on Rails framework, with some functions being handled by more specialised software suited to the job. The system was initially hosted on Rackspace, but has since migrated to Linode as this offered cost and performance benefits. It has subsequently been migrated to Amazon Web Services, a popular cloudhosting environment used by thousands of companies, including National Rail Enquiries.

To give an idea of the scale, every day the system accepts 750,000 TRUST messages, 7,250,000 TD steps and 525,300 train schedules. All of these inputs come free of charge from Network Rail’s Open Data platform. There are 126 hand drawn maps on the system with greater than 55,000 map elements and around 900 simultaneous concurrent map users. During the period when Flying Scotsman was running on the main line, this figure rose to 1,500.

Usage and users

OTT was launched in January 2012. Like all applications, it is easy to access and use once you know how. The younger generation adapts to this better than my generation but the value of the information makes persisting worthwhile. Start by typing in opentraintimes.com; click on MAPS and type in the geographic location or town that you require. A series of map areas will display - East Midlands, Anglia, London Overground, Sussex, and so on - then click on the area you want. Click then on the particular line or section of line where you need information. A map will then appear showing the route, signal numbers and train describer berths. Users then need a bit of common sense to identify the particular train they are looking for. In the TD berths will appear as

a four-digit head code, for example 1A66. This represents a train which will move from berth to berth as its journey progresses.

Not everyone will understand the type of train that the head code represents, but it is relatively easy to work out the particular train you are looking for. Other letters might appear in the berth which are entered as free text by the signallers. Examples are: “NOT” “IN” “USE” in adjacent berths; “LAND SLIP” “LINE SHUT”, “BLOC”, anything that gives the status of a particular line or route.

An alternative is to click on the logo and search for trains by location. Clicking on the TRAINS icon will bring up an advanced search engine for anyone who wants to search for trains timed specifically at two points. To achieve this, you may need additional coded information for the specific trains you are looking for.

Usage has since mushroomed - there are now over one million visits per month. A number of TOCs use OTT unofficially, but this only goes to demonstrate the value of the site and the information it yields. Open Train Times has a presence on Facebook and Twitter, where regular updates to the site are published. Questions have been asked about cyber security, which has been considered but it begs the question as to what is open and closed data. Where data is open, the risk is much smaller since it is always available. In any case, the information is advisory and not critical so, if something is misinterpreted, no great damage is done.

The relationship with Darwin was questioned, but Darwin exists to produce future information for Customer Information Screens and will interpret the same data sources to anticipate what information should be displayed.

Peter Hicks has to be applauded for what he has achieved. It is not his full-time job and he makes no income from the public website. His ambition is simply to provide information for the travelling public – in essence, he is a modern-day philanthropist.

Peter Hicks spoke to a joint meeting of the IRSE London & SE section and the Signal & Electrical Engineers’ Technical Society to explain how Open Train Times came about, the challenges faced and the work still to do.

IMAGINE THE JOURNEY

TRAFFIC MANAGEMENT

CUSTOMER XPERIENCE

SIGNALLING CONTROL OPERATIONS MANAGEMENT

Operations wide, results focused, digital management; improving performance and increasing capacity.

Digital platform with automated movement authorities. Integrates with all interlockings and any TMS; reducing the cost of operations and infrastructure renewals. Real time, disruption management. Plan optimum stock and crew utilisation; improving service resilience and customer satisfaction. Customer communication, data gathering and analytics; delivering personalised engagement and informed journeys.