Availability and accuracy of real-time information

[Wombat]

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?

 

[Lincoln]

This is probably a huge over simplification however generally a report on a train is only as good as the last timing point it passed.

So if it passed left point A on time but was then subsequently held before it reached the next timing point B it would show as on time at point C despite being late.

Station screens can be overridden however if this is done by the local staff then it won't be reflected on the internet sources.

Once the train passes the next timing point then the system will automatically catch up.

 

[FordFocus]

Some routes, especially ones with long signalling sections with a few stations in between won't account in for the delay in these sections.

Example, the two train reporting points are at Station A and Station D. Train leaves Station A on time, the train has a problem at Station B, it racks up a 10 minute delay but the screens at Station C and D still show 'On Time' unless someone in control amends the individual journey. During the delay, unless the train is on the move and the fault sorted control can simply change the individual train to 'Delayed'.

During times of severe disruption it can be a heavy workload on people in control, especially when trains are omitting stops, terminating or have no timescale on when trains will move again.

 

[PHILIPE]

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.

 

[Tomnick]

Some routes, especially ones with long signalling sections with a few stations in between won't account in for the delay in these sections.

Example, the two train reporting points are at Station A and Station D. Train leaves Station A on time, the train has a problem at Station B, it racks up a 10 minute delay but the screens at Station C and D still show 'On Time' unless someone in control amends the individual journey. During the delay, unless the train is on the move and the fault sorted control can simply change the individual train to 'Delayed'.

During times of severe disruption it can be a heavy workload on people in control, especially when trains are omitting stops, terminating or have no timescale on when trains will move again.

Obviously, unless overridden manually, the information systems will be unaware that anything is amiss until the train becomes overdue at the next reporting point (and is then shown as such in TRUST). Do the public systems (both at stations and online) reflect this too, by stepping up the estimated time every couple of minutes as per the OP? I'd understood that the status automatically changed to 'delayed' (on some systems at least) once it was overdue by a certain number (10?) of minutes.

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.

Does that happen on all systems, and consistently? I've seen it happen before - but internally, they'll usually still be showing (but with an overdue report) until a report goes in or they're cancelled off.

 

[infobleep]

Obviously, unless overridden manually, the information systems will be unaware that anything is amiss until the train becomes overdue at the next reporting point (and is then shown as such in TRUST). Do the public systems (both at stations and online) reflect this too, by stepping up the estimated time every couple of minutes as per the OP? I'd understood that the status automatically changed to 'delayed' (on some systems at least) once it was overdue by a certain number (10?) of minutes.


Does that happen on all systems, and consistently? I've seen it happen before - but internally, they'll usually still be showing (but with an overdue report) until a report goes in or they're cancelled off.

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?

 

[wensley]

Hello,
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.

My understanding (others will correct me if needs be), is that this is permanent for a number of locations.

It's been a long time coming. The NRE website wasn't always accurate with platform information and didn't reflect all the changes that get made in the reality of an operational railway.

Hopefully this will put an end to folk waving smartphones in my face telling me I'm a fool and that of course the train next to me goes to X, when I know for certain it goes to Y!

 

[mirodo]

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.

This is an issue with the data link. Due to be fixed by the end of September, as discussed explained in this thread: http://www.railforums.co.uk/showthread.php?p=2277334

 

[Atishyou]

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.

 

[LNW-GW Joint]

Meanwhile, trains with GPS capability know exactly where they are all the time.
One day the limited timing-point data will have to give way to GPS (or some equivalent).

 

[Tomnick]

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?

I don't think that'd be sensible. It's quite common for trains to be delayed in stations by a minute or two, for something as routine as assisting a wheelchair user (and don't forget that, in most cases, the report doesn't go into TRUST until the train description steps into the next berth, at the earliest when it passes the platform starting signal), and manual reports can be late going in if the signalman's busy (though I'm not sure whether an overdue manual report triggers a 'delayed' message in the same way?). It's just asking for confusion.

Meanwhile, trains with GPS capability know exactly where they are all the time.
One day the limited timing-point data will have to give way to GPS (or some equivalent).

If I'm not mistaken, some trains have now been specially fitted with such equipment for that very purpose (a trial on the Esk Valley?). CCF also seems to have the ability to work out whether a train is being delayed between timing locations based on its berth occupation.

 

[infobleep]

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.

Does Darwin take into account the time of day and cancelled stops? For example a peak time train running late I'd u likely to have shorter station dwell times. In fact they might even be longer.

Also a train which joins and splits really does need all its 3-5 minutes to do the split / join, even if it is running late!

Equally though a train missing out stops is likely to make up time.

The existing systems seem not to be able to cope with those.

What surprises me is that this implementation couldn't done in a test environment and / or in a production environment which was then switched on on a cut over date. Rather than it being done to the live system itself.

However I've not worked on it myself so I don't actually know how it all works. What I do know is that I would find it fascinating if I did know more about it.

 

[HarleyDavidson]

Meanwhile, trains with GPS capability know exactly where they are all the time.
One day the limited timing-point data will have to give way to GPS (or some equivalent).

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

 

[swt_passenger]

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?

The "Delayed" trigger should surely be set to either 5 or 10 minutes depending on whether the service gets the long distance or short distance treatment for charter purposes.

Whether or not the PIS can cope with that is another question...

 

[Atishyou]

Does Darwin take into account the time of day and cancelled stops? For example a peak time train running late I'd u likely to have shorter station dwell times. In fact they might even be longer.

Also a train which joins and splits really does need all its 3-5 minutes to do the split / join, even if it is running late!

Equally though a train missing out stops is likely to make up time.

The existing systems seem not to be able to cope with those.

What surprises me is that this implementation couldn't done in a test environment and / or in a production environment which was then switched on on a cut over date. Rather than it being done to the live system itself.

However I've not worked on it myself so I don't actually know how it all works. What I do know is that I would find it fascinating if I did know more about it.

Any changes, such as cancellation, retiming, SSO which are made in Tyrell (from the TOCs) all feed through to Darwin, or you can batch select trains by location or a few other criteria and make the changes in one go.

At the moment, Darwin wouldn't predict it based on time of day, that would involve manual intervention unfortunately.

Compared to how it was a few years ago, when Darwin is nationwide, the potential is endless. It should eradicate almost all of the issues facing the industry at the moment, not to mention everyone will be working from the same software.
--- old post above --- --- new post below ---

The "Delayed" trigger should surely be set to either 5 or 10 minutes depending on whether the service gets the long distance or short distance treatment for charter purposes.

Whether or not the PIS can cope with that is another question...

Anything running between on time and 5 minutes late is classed as 'on time', so that's why it'll be 6 minutes.

 

[pemma]

One thing to remember is live running information only does what it's programmed to do. If the incoming service is 25 minutes late and there's a 15 minute turnaround time you can work out the outgoing service won't be on time but live running information won't pick up on that.

 

[infobleep]

Any changes, such as cancellation, retiming, SSO which are made in Tyrell (from the TOCs) all feed through to Darwin, or you can batch select trains by location or a few other criteria and make the changes in one go.

At the moment, Darwin wouldn't predict it based on time of day, that would involve manual intervention unfortunately.

Compared to how it was a few years ago, when Darwin is nationwide, the potential is endless. It should eradicate almost all of the issues facing the industry at the moment, not to mention everyone will be working from the same software.
--- old post above --- --- new post below ---


Anything running between on time and 5 minutes late is classed as 'on time', so that's why it'll be 6 minutes.

Of course if the official connection time between trains is 5 minutes and the train your on was 4-5 minutes late, you won't be thinking oh it's great my train was on time and I missed my connecting train.

I admit these things happen but that won't stop passengers not thinking of their service as being late, given they missed their connection.

 

[Lincoln]

One thing to remember is live running information only does what it's programmed to do. If the incoming service is 25 minutes late and there's a 15 minute turnaround time you can work out the outgoing service won't be on time but live running information won't pick up on that.

There are systems in place now to account for this through the information systems linking services together through the unit numbers forming them, but not every TOC has the necessary software upgrade (or indeed a CIS system even with the capability at all!).

I think it is a shame that this sort of information is not consistent across the rail network as it would really help with our image!

 

[infobleep]

There are systems in place now to account for this through the information systems linking services together through the unit numbers forming them, but not every TOC has the necessary software upgrade (or indeed a CIS system even with the capability at all!).

I think it is a shame that this sort of information is not consistent across the rail network as it would really help with our image!

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

 

[Boodiggy]

I don't think that'd be sensible. It's quite common for trains to be delayed in stations by a minute or two, for something as routine as assisting a wheelchair user (and don't forget that, in most cases, the report doesn't go into TRUST until the train description steps into the next berth, at the earliest when it passes the platform starting signal), and manual reports can be late going in if the signalman's busy (though I'm not sure whether an overdue manual report triggers a 'delayed' message in the same way?). It's just asking for confusion.


If I'm not mistaken, some trains have now been specially fitted with such equipment for that very purpose (a trial on the Esk Valley?). CCF also seems to have the ability to work out whether a train is being delayed between timing locations based on its berth occupation.

Also on CCF the colour of the box displaying the headcode will change colour depending on how late the train is.

 

[TheNewNo2]

I was, for the first time, travelling while looking at RealTime Trains the other day. It said we were 1min late at Swindon before we even left Paddington.

 

[The Planner]

Also on CCF the colour of the box displaying the headcode will change colour depending on how late the train is.

Always good fun looking seeing a multitude of pink where the proverbial happens.

 

[nidave]

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?

 

[EM2]

Always good fun looking seeing a multitude of pink where the proverbial happens.

It's a bit of a catchphrase at our place. 'Oh, bloody hell! It's all gone pink!'

 

[CyrusWuff]

There are systems in place now to account for this through the information systems linking services together through the unit numbers forming them, but not every TOC has the necessary software upgrade (or indeed a CIS system even with the capability at all!).

I think it is a shame that this sort of information is not consistent across the rail network as it would really help with our image!

The information is only as good as the system that's acting on it...or something. For example, with the system I have experience of, if you create a "Link" between two trains at a given location, it'll quite happily display "Anytown & Sometown" as the destination at every station before the connection point, and list calling points for both, with a "Front Train" and "Rear Train" remark. Obviously, this is undesirable as it's downright misleading.

 

[Frontera2]

ive worked in the industry for 21 years, all of which has been in the area of passenger information. I've been heavily involved with Darwin at first hand from both sides of the coin.

As soon as I can find the time, I will hopefully be able to answer all of your points in detail...

 

[jon0844]

I believe there are still GN services that at Finsbury Park are shown as 4 car, when they're actually 8 - but the service is going to divide later on*.

This probably leads to unnecessary congestion as those who listen will stand to board a 4 car service, and not spread out to use all eight coaches.

* Some do show in the description that the train will split, but not all.

Fortunately the 317s now have new software to explain things properly on board, which is more than the 365s do.

Clearly it's only as good as the information being entered.

 

[cuccir]

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!

 

[jon0844]

In some cases, the best option is to head to another station (if you have a 'plan B' route) if you even get a sniff of problems. People should always try and work out their plan B before travel if they can - it makes things a lot easier when things go wrong than trying to work things out when you're on a platform.

I've never been refused travel on another route (that is one of the alternatives on the GTR issued disruption guide) once there's been any report of problem - even before the TOC actually says tickets are valid on other reasonable routes.

I figure that they can let me travel to another station without extra cost, and I'll stump up the cost of a taxi/bus to get me home at the other end if I've arrived before they can sort out buses etc.

 

[infobleep]

ive worked in the industry for 21 years, all of which has been in the area of passenger information. I've been heavily involved with Darwin at first hand from both sides of the coin.

As soon as I can find the time, I will hopefully be able to answer all of your points in detail...

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

The information is only as good as the system that's acting on it...or something. For example, with the system I have experience of, if you create a "Link" between two trains at a given location, it'll quite happily display "Anytown & Sometown" as the destination at every station before the connection point, and list calling points for both, with a "Front Train" and "Rear Train" remark. Obviously, this is undesirable as it's downright misleading.

I don't know if this is the same but there would be a train to Brighton that split at Haywards Heath with a fast portion to Brighton followed by a slow portion. At Clapham Junction this use to be displayed and announced as the Brighton & Brighton service.

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.