About The Open Rail Live Signalling Diagrams

We'll start with the negative stuff: The live signalling diagrams are an experimental service provided at my own expense, primarily for my own entertainment. As such, it may be withdrawn at any time, temporarily or permanently.

With the above warning in mind, you are welcome to use the diagrams and pass on the details to others.

Network Rail Open Data

Network Rail make freely available a large amount of data, including timetables, train movements and many other areas. For much more information about this, see the Open Rail Data Wiki, where you can find out what is available, how to get it, and what I and others are doing with it.

What Can You See?

The information on the diagrams is derived mainly from the train describers data feed from Network Rail. Currently I'm using describer areas M0, M1, and WA, which are MRROC Lime Street WestCAD, MRROC Liverpool Area WestCAD and Warrington PSB respectively. (MRROC is Manchester Regional Rail Operations Centre, located at Ashburys) The detail available varies from describer to describer, on some you can only see the signalling berths, while others also show signals and some of the route selections. Some of the berths belong to other boxes (See the FAQ below) and are provided in the data stream so the signaller knows what is coming. For these, we generally don't have signals.

The route selections are shown on the diagram either by highlighting the selected route through the junction or by means of a berth showing the name of the route. Note that these are not point indications - They indicate that the signaller has selected a route across the junction.

The black information panel displays details of each train shown on the diagram, if I can find it in my database. By the way, the time is from the working timetable so it may differ from public timetables, and might sometimes have an H for half appended.

Decoding Signalling Data

The signalling data provided by Network Rail comes in two parts: Berth movements are easy to understand, "2F68 from 3592 to 3590" is pretty simple once you realise that berth 3592 is on the approach side of signal LL3592. On the other hand, the signal data provided is somewhat "unfriendly" in that they provide the information but no advice on what it means. It is left as an exercise for the user to decode the data stream. For a more detailed exposition of the process required to decode the signal data, see my notes on the Open Rail Data Wiki.

Only an on or off indication is supplied for each signal, with off corresponding to any of one yellow, two yellows, green, one flashing yellow, two flashing yellows, or two white dots. That is why the signals on my diagram only show green or red (or black when the information is missing.).

How It Works - The Technical Bit


Working hard in the background is a small virtual server located in Nuremberg, Germany collects data from Network Rail, analyses it and stores it in a database. The database is then used to provide various web pages including timetable details, live departure boards and so on, including the live signalling page. Just one small part of the whole system is responsible for the real time signalling data which is used to drive the diagrams.

Signalling Display

Each diagram is an SVG (Scalable Vector Graphics) file. This format was selected because javascript running on the client can easily update the diagram. The negative side of this choice is that older browsers don't support SVG.

Once the page has loaded, some javascript checks with the server for any updates on a regular basis and then alters the displayed diagram accordingly. I'd never designed anything like this before, and was pleasantly surprised how easy it was.

After playing with a couple of SVG editing tools which were annoyingly unsatisfactory, I ended up hand coding the SVG file, which was tedious but not too difficult. The M4 Macro Processor is used to automate common sequences such as signals and berths.

Open Source

All the software involved is open source, and you can find it at https://github.com/philwieland/openrail. Feel free to download it and have a play, please let me know how you get on.


To learn more about the electrification in the northwest, see my Northwest Sparks web site and blog.

Appeal For Information

If anyone can supply a copy of the details of what the signalling bits denote, it would be very welcome. I've guessed almost all of them for the M1 describer, but one or two remain elusive.

I would also appreciate comments on the design of my diagram. What is the 'correct' way of indicating selected routes? How should I draw two berths 'in the same place' e.g. Huyton platform 2?


Why are many signals not shown?

I show all the signals that I receive data for. You can see the berth identity in each empty berth in grey, on the Huyton diagram those that begin with E, S, or W belong to Edge Hill, St Helens or Warrington boxes. These berths show train movements, mainly so the signaller can see what's approaching, but I don't get signal information for them. I don't think the signaller has any control over these areas either.

It doesn't update.

Probably a browser issue (or the server is temporarily out of action) If this persists, let me know what browser you are using and I'll see if I can do anything.

Wrong Train Details?

The signalling data feed gives me the reporting number of the train. I then use a simple mechanism to work out the description of the service, for display in the list of trains. Where the same headcode is allocated to two trains which pass through the area within a few hours of each other, this can sometimes select the wrong one.

What On Earth is Train 667Y ?

Normally, an occupied berth will display the reporting number (Headcode) of the train. There are two reasons for odd train IDs:
1. Before making their data available, Network Rail hide certain details. In particular, the reporting numbers of some freight trains are considered secret. So a freight working may appear with a scrambled label that doesn't look like a proper headcode.
2. Signallers, or the system itself, can insert useful information into berths instead of train headcodes. For example **** on a blocked line, 2SET to indicate two stabled units in a platform, or the planned departure time for a stabled train. Signallers at Lime Street sometimes put a headcode in the platforms for a train that isn't there. This is to mark where that train will depart from when the incoming service arrives, presumably to help get the information on the departure screens.

I can see the same train in two places, and/or a train with a green signal behind it.

If there is an interruption in the data feed due to a fault at my server or at Network Rail, messages can get lost. Incorrect indications will only be resolved when another train passes along the line. Strange indications can also result from signal failures: Where a train is given permission to pass a signal at danger, its identity on the diagram may be left behind, so to speak.

All or many of the signals are black.

After an extended loss of data my software will reset all signals and berths to the unknown state, where berths are empty and signals are black. They will only be restored to correct values when an update is received, which may not be until a train passes along the line.

Future Plans

Currently, your browser contacts the server once every 4 seconds or so, to check for updates. I might take a look at streaming this information instead (More of a trickle than a stream, actually!). This would result in more timely updates, at the cost of a lot of programming effort for me.

Adding more maps will happen slowly, if at all.


You can contact me at editor at nw-sparks.co.uk