Availability and accuracy of real-time information

[Frontera2]

Hello,

I commute between Waterloo and Epsom, and have noticed a couple of interesting things about the real-time information provided online by the websites of National Rail and the TOCs.

First, it's sometimes wrong and out of sync with the info displayed on the screens (platform and concourse). What typically happens is that the web sites will state that a train is on time even when it hasn't actually arrived at the platform by the scheduled departure time, then it will be displayed as a couple of minutes late, then another couple, then another couple, and so on until it finally departs.

The impression I get is that: (1) sometimes the length of the delay is unknown, but whoever's in charge is reluctant to say so online and would prefer to guess; and (2) there is a problem conveying the actual existence of the delay in real time to the web sites that display this data.

Second, and possibly related to the above, the NR web site has recently lost the ability to display platform information:

"Due to an issue with industry data we are unable to show platform information"

This has been going on for a few weeks now so it's not a typical one-off outage. My best guess is that someone's implemented an IT change that's had an unintended side-effect (these things happen) and decided that it's a sufficiently small problem that passengers can live with it for a while.

What interests me, as someone who works in IT but has no specific rail knowledge beyond the average commuter, is that I would expect the difficult bit to be the business of reacting to timetable exceptions and devising new schedules on the fly when things go wrong. Once the decisions have been made and the timetable amendments have been plotted - which must happen, because the information ends up on the departure boards at the stations - I would expect the work of shovelling that data over to the web sites to be non-trivial but certainly not the hardest part of the enterprise.

All of which is a wildly verbose way of asking: does anyone know how the provision of real-time info works, and who is responsible for it?

Hi There,

I'll try and answer your points the best I can.

Your first point about being out of sync with the information displayed at station.. There is a reason for this..

Whilst most TOCs have their Customer Information System (CIS) connected to the national real time database - Darwin - Southern and SWT have not connected theirs yet (although are expected to do so in the near future)

Therefore for a London to Epsom journey, the information you'll see at station is driven purely by the TOC CIS whereas online and Apps are driven by Darwin.

Darwin will consider a train to be "On Time" until such time one of the following takes place;

- A manual delay forecast is applied to the train, usually by the TOC Control Room

- An alteration / cancellation message is sent to Darwin

- The train fails to report as expected within 5 minutes or at 2 successive expected reporting points (whatever is sooner)

Therefore when a train is delayed for an indeterminate time (which happens very often) the systems will increase the expected arrival time by 1 minute increments until the 5 minute / 2 reporting points threshold is reached at which point it will show as "delayed" until the train either starts moving / reporting again or a manual intervention takes place

Regarding the lack of platform information for certain stations..

Darwin will only publicly display / communicate platform numbers when they are verified by the respective station or TOC CIS system. In the event of a CIS not being connected (Southern & SWT for example) this verification cannot take place and therefore the default position is not to display them as Darwin can't confirm that's what the TOC / station operator wants.

Once SWT and Southern come on line, the platform number issue should be largely resolved.

In terms of saying who is responsible for real time info - the simple answer is that each TOC is responsible for how their own trains appear in the national database.

Hope this helps?
--- old post above --- --- new post below ---

What they can't seem to sort is late running trains disappearing from the CIS after a few minutes, assume because nobody has input that it is expected to leave from starting point xx mins late.

This is a feature of the Atos CIS system - although I believe it's configurable by operator.

Once a train enters an "indefinite delay" status (see my earlier reply) it will be removed from the "Next Train" indicators on the platforms.

The train(s) will, however, continue to be shown on the summary of departure displays.

The reason behind this is that once a train is in indefinite delay status, the CIS can't be confident that it will in fact be the next train on the platform therefore the platform displays will show the next "confirmed" departure.

Obviously once the train starts moving / reporting again the displays will change accordingly.
--- old post above --- --- new post below ---

I was told it was 6 minutes and then the word delayed would a appear on the screens.

What would be the affect if this time interval was changed to 1 or 2 minutes, instead of 6. So after say 2 minutes and it nor passing it's monitoring point it automatically changes to delayed? Would that work?

This would cause a lot of problems, particularly for long distance operators, where trains would be dropping in and out of "delayed" status
--- old post above --- --- new post below ---

The real time info on NRE is via Trust reporting points and Darwin.

If there's a few minute delay, Darwin should predict the times of the next station stops, unless it thinks time will be made up, I.e. Via a reduced calling time at a station.

The real problem is where CIS interferes (which it does) and overwrites the Darwin data.

This is a big problem in some areas and the feed from CIS should be switched off by some operators.

It's been known that some emergency timetable info which has been put in the system to be overwritten by CIS info (which was wrong).

Some Train Operatorsare using Darwin themselves to put their own amendments in rather than CIS and this info is also being used for some departure boards. It's not industry wide yet though.

Movement data into Darwin is indeed via TRUST and the Train Describers, however delay forecasts can also be manually generated via Tyrell (Control Room messaging tool), CIS systems or directly into the Darwin database

One of the primary purposes of connecting CIS systems into Darwin was to avoid confusion and have "one source of the truth" under this, CIS does not, as a general rule, over-write Darwin data. Predictions in CIS are driven by Darwin not the other way around. The only exception to this, as I've mentioned earlier, is where a manual change or forecast is applied. In the case of a delay forecast, once a train starts moving again Darwin will generate it's own forecast once more.

Regarding the emergency timetable info - CIS systems (once connected to Darwin) take the daily timetable feed via Darwin each day so the instances of this occurring are becoming very few and far between.

Operators can and do make use of the Darwin "Workstation" to make changes / put emergency timetables into the system and this works very effectively.

With the notable exception of, I believe, Real Time Trains, Darwin feeds all other public facing apps, journey planners (Trainline, Red Spotted Hanky etc) and the CIS displays at the vast majority of stations in the UK (subject to my comments in earlier posts re SN and SW)
--- old post above --- --- new post below ---

This fascinates me
I have seen some names of systems banded about and am a bit lost..
What is the newest system in use? Which one is looking to become standard (if any)
Do each TOC implement their own CIS system or do they have to use one specified by NR?

The national real time database (One source of the truth) is known as Darwin. This feeds nearly all TOC CIS systems.

The main CIS systems that are in use in the UK are manufactured by;

Atos (Known as the "LICC" (Local Information Control Centre)
Amey
KeTech
--- old post above --- --- new post below ---

Will the upgrades to South West Trains and Southern provide that going forward?

The inclusion of formation data is something that's in the long term pipeline I believe
--- old post above --- --- new post below ---

The system is better now than it used to be, and I suspect it will get better in future. In my experience its two biggest limitations at the moment are:

• As noted, it can't generally yet identify where delays will occur due to late incoming services
• It's poor at dealing with situtations where disruptions result in services stopping short

In these instances, it's a bit more of a case of relying on Twitter, making educated guesses, or old fashioned heading to the station and seeing what's happening!

The key to the first point is for TOCs to make sure that their services are "associated" with one another. That way, a delay on train "A" will ripple across to train "B"

Not sure what is meant by "It's poor at dealing with situations where disruption result in services stopping short" - as long as this information is entered into Darwin, it will feed down to displays and apps
--- old post above --- --- new post below ---

Thanks in advance. I'm quite fascinated by this area of the railways and there workings.
--- old post above --- --- new post below ---

Yesterday I was travelling back from Salisbury on the 21.26 to Woking. There was a note at the top of live departure running information on the National Rail Enquiries App apologising for the delay which was due to live arrival of the crew.

The train left Exeter only 3 minutes late. It was a minute late leaving Salisbury but appeared to arrive on time.

Would that delay attribution have been entered in advance when they didn't know how delayed the train might be? After all I've seen quite a few trains over 5 minutes late with no reason given what so ever.

Essentially yes - if a delay reason is applied to a train in either CIS or Darwin (both of which are manual processes) then it will remain in place unless it's manually changed or removed

 

[infobleep]

Hi There,

I'll try and answer your points the best I can.

Your first point about being out of sync with the information displayed at station.. There is a reason for this..

Whilst most TOCs have their Customer Information System (CIS) connected to the national real time database - Darwin - Southern and SWT have not connected theirs yet (although are expected to do so in the near future)

Therefore for a London to Epsom journey, the information you'll see at station is driven purely by the TOC CIS whereas online and Apps are driven by Darwin.

Darwin will consider a train to be "On Time" until such time one of the following takes place;

- A manual delay forecast is applied to the train, usually by the TOC Control Room

- An alteration / cancellation message is sent to Darwin

- The train fails to report as expected within 5 minutes or at 2 successive expected reporting points (whatever is sooner)

Therefore when a train is delayed for an indeterminate time (which happens very often) the systems will increase the expected arrival time by 1 minute increments until the 5 minute / 2 reporting points threshold is reached at which point it will show as "delayed" until the train either starts moving / reporting again or a manual intervention takes place

Regarding the lack of platform information for certain stations..

Darwin will only publicly display / communicate platform numbers when they are verified by the respective station or TOC CIS system. In the event of a CIS not being connected (Southern & SWT for example) this verification cannot take place and therefore the default position is not to display them as Darwin can't confirm that's what the TOC / station operator wants.

Once SWT and Southern come on line, the platform number issue should be largely resolved.

In terms of saying who is responsible for real time info - the simple answer is that each TOC is responsible for how their own trains appear in the national database.

Hope this helps?
--- old post above --- --- new post below ---


This is a feature of the Atos CIS system - although I believe it's configurable by operator.

Once a train enters an "indefinite delay" status (see my earlier reply) it will be removed from the "Next Train" indicators on the platforms.

The train(s) will, however, continue to be shown on the summary of departure displays.

The reason behind this is that once a train is in indefinite delay status, the CIS can't be confident that it will in fact be the next train on the platform therefore the platform displays will show the next "confirmed" departure.

Obviously once the train starts moving / reporting again the displays will change accordingly.
--- old post above --- --- new post below ---


This would cause a lot of problems, particularly for long distance operators, where trains would be dropping in and out of "delayed" status
--- old post above --- --- new post below ---


Movement data into Darwin is indeed via TRUST and the Train Describers, however delay forecasts can also be manually generated via Tyrell (Control Room messaging tool), CIS systems or directly into the Darwin database

One of the primary purposes of connecting CIS systems into Darwin was to avoid confusion and have "one source of the truth" under this, CIS does not, as a general rule, over-write Darwin data. Predictions in CIS are driven by Darwin not the other way around. The only exception to this, as I've mentioned earlier, is where a manual change or forecast is applied. In the case of a delay forecast, once a train starts moving again Darwin will generate it's own forecast once more.

Regarding the emergency timetable info - CIS systems (once connected to Darwin) take the daily timetable feed via Darwin each day so the instances of this occurring are becoming very few and far between.

Operators can and do make use of the Darwin "Workstation" to make changes / put emergency timetables into the system and this works very effectively.

With the notable exception of, I believe, Real Time Trains, Darwin feeds all other public facing apps, journey planners (Trainline, Red Spotted Hanky etc) and the CIS displays at the vast majority of stations in the UK (subject to my comments in earlier posts re SN and SW)
--- old post above --- --- new post below ---


The national real time database (One source of the truth) is known as Darwin. This feeds nearly all TOC CIS systems.

The main CIS systems that are in use in the UK are manufactured by;

Atos (Known as the "LICC" (Local Information Control Centre)
Amey
KeTech
--- old post above --- --- new post below ---


The inclusion of formation data is something that's in the long term pipeline I believe
--- old post above --- --- new post below ---


The key to the first point is for TOCs to make sure that their services are "associated" with one another. That way, a delay on train "A" will ripple across to train "B"

Not sure what is meant by "It's poor at dealing with situations where disruption result in services stopping short" - as long as this information is entered into Darwin, it will feed down to displays and apps
--- old post above --- --- new post below ---


Essentially yes - if a delay reason is applied to a train in either CIS or Darwin (both of which are manual processes) then it will remain in place unless it's manually changed or removed

Thanks for reply. Fascinating. Fair enough about the long distance operators and putting the delay message set at 2 minutes. May be it would work for stopping services. Or more likely perhaps not full stop.

Out of interest, what does Real Time Trains use to get platform numbers?

 

[Frontera2]

Whilst I wouldn't want to speak on behalf of RTT. My understanding is they use the raw timetable data from Network Rail - which contains the timetabled platform numbers.

 

[infobleep]

Whilst I wouldn't want to speak on behalf of RTT. My understanding is they use the raw timetable data from Network Rail - which contains the timetabled platform numbers.

The thing is, when platform number change at the last minute, they have these changes in RTT. So the update must be feed from something.

A friend wondered once why the information signallers use, couldn't be used for the stations? This was about 10 years ago they wondered this mind you and a lot has changed since then. They were thinking from the perspective of a London commuter.

 

[jon0844]

RTT won't always have the right platform, even once confirmed at a station. Usually it's confirmed when bold but at night I've seen the wrong details on RTT for trains leaving King's Cross.

It's very rare but does happen.

 

[louis97]

The thing is, when platform number change at the last minute, they have these changes in RTT. So the update must be feed from something.

There are a number a ways this might be known by RTT:

• At an origin station the train describer is entered, therefore allowed a platform to be confirmed.
• The train has arrived at a through station and therefore RTT knows the platform it is using
• RTT works out that the train will likely be using a different platform than booked (we use probability to identify common previous movements on trains which use a given platform, for example every train to use platform 1 at station B, may pass always pass through platform 1 at station A slightly further down the line)

RTT won't always have the right platform, even once confirmed at a station. Usually it's confirmed when bold but at night I've seen the wrong details on RTT for trains leaving King's Cross.

It's very rare but does happen.

This happens where a platform is changed at the last minute and the train describer has previously already been entered into another platform - this does not always happen in this situation, it can depend on the station.

 

[bearhugger]

Don't bank on it. GPS can be confused & disabled by weather conditions.

And line of sight between the GPS receiver and the satellites it's locked onto, therefore steep valleys / railway cuttings / tunnels / heavy tree cover etc. More information http://www8.garmin.com/aboutGPS/

 

[jon0844]

That seems like quite old information. Modern GPS receivers are usually very sensitive and therefore accurate in just about every condition.

 

[bearhugger]

That seems like quite old information. Modern GPS receivers are usually very sensitive and therefore accurate in just about every condition.

Yes, I would say you are correct. I was just trying to add a bit of context

 

[jon0844]

I'd also add that we're talking about pretty incredible GPS reception on a mobile phone, or even a watch these days. For a 'professional' system with proper antennas, it should never be possible to get a misreading.

 

[BurtonM]

RTT won't always have the right platform, even once confirmed at a station. Usually it's confirmed when bold but at night I've seen the wrong details on RTT for trains leaving King's Cross.

It's very rare but does happen.

True - it shafted me at Euston once, ended up waiting at the low number platforms when the train was going from 15.

Last week I was commuting into university, and a Stalybridge-Manchester Piccadilly TPE (1215 on the 23rd) was missing from NRE for some reason. One of the ones off Hull that can't keep time.
I was a little confused, and when I got to the station it wasn't on the CIS either. Puzzled, I kept an eye on RTT that suggested the train was 20+ down but not far away. It eventually arrived in P3 unannounced with 'Manchester' on the front so I went to get on and the guard told me it was cancelled from Stalybridge, and reversing to start short and make up time.

How, and indeed why, did the train disappear off NRE and the station PIS? Why wasn't it showing as 'cancelled'?

 

[DelW]

Frontera, thank you for a very interesting reply.

This is a feature of the Atos CIS system - although I believe it's configurable by operator.

Once a train enters an "indefinite delay" status (see my earlier reply) it will be removed from the "Next Train" indicators on the platforms.

The train(s) will, however, continue to be shown on the summary of departure displays.

The reason behind this is that once a train is in indefinite delay status, the CIS can't be confident that it will in fact be the next train on the platform therefore the platform displays will show the next "confirmed" departure.

I'm sure you're correct, but I have seen this happen in a situation where no other train movement would have been reasonably possible.

I was on a southbound Heart of Wales line train which was due to cross a northbound train at Llanwrtyd. We sat in the platform for some time waiting for the delayed northbound to clear the single line from Llandovery, during which time the northbound platform screen cleared, and was replaced by the time of the next northbound train due in around 4 hours time.

The particular point here being that not only could nothing else move until it arrived, but on the timetable at the time, the later train would probably have been formed by the same unit I was sitting on, making its return journey from Swansea.

 

[infobleep]

RTT won't always have the right platform, even once confirmed at a station. Usually it's confirmed when bold but at night I've seen the wrong details on RTT for trains leaving King's Cross.

It's very rare but does happen.

This evening the 18.54 Woking to Basingstoke was shown in RTT as departing from pkatform 5 up to less than a minute before its arrival. When it left Woking RTt was displaying platform 4, which is the platform is arrived into so clearly last minute changes take time to filter through.

The platform CIS was correct and I heard no announcements so I assume station staff knew in good time to alert passengers at the station.

Very pleased this did happen as I made my connecting train because of this. With a little bit of running. Unfortunately I took the view the 18.58 would go into platform 4 but actually it was us that went into that platform. Thus I'd moved to the wrong part of the train, as I was originally aiming for the platform 5 stairs.

I'd known since 10 minutes away from Surbiton station that what time I got home would depend on what the signaller did at Woking as the 18.18 Surbiton to Woking was running 6 minutes late and 10 by the time it reached Woking.

There was an interesting answer to a question on delays in a recent South West Trains web chat. I might post it some point as it was a informative answer and not something I'd considered would happen.

 

[nidave]

Frontera2 - Thanks for taking the time to reply. Its great to find out the bit that most people don't think are important until things stop working.

 

[northwichcat]

How, and indeed why, did the train disappear off NRE and the station PIS? Why wasn't it showing as 'cancelled'?

I experienced similar at Chorley once. I was waiting for a Barrow to Airport service and it disappeared off the CIS without arriving. The following Northern service turned up so I got on that and when I got to Piccadilly I checked the arrivals display and noticed the Barrow arrival was something like 20 minutes late and the departures display was showing Manchester Airport as cancelled.