How automated is the 'expected time' in the National Rail live web feed?

[Edinburgh2000]

How does the expected time get to be calculated for the National Rail web feed? I ask because of an example from today, whereby 1W96 (London KX - Inverness) is running about 30L (having been diverted via Gainsborough Lea Rd). It is running behind 2Y09 (North Berwick to Edinburgh) which is not scheduled to arrive at Edinburgh until 1659. Yet the National Rail status for 1W96 is showing an estimated departure for it from Edinburgh of 1650. That clearly cannot be possible and anyone with any understanding of the network would know that the best that could be expected would be arrival about three minutes behind 2Y09 plus about a 6-10 minute dwell in Edinburgh for a best departure at about 1710.

As time progresses, and 1W96 gets held behind the stopping 2Y09 at each of its station stops, the NR site slips the expected time backwards, which must be hugely frustrating to anyone waiting at Edinburgh for the train, seeing it appear to get later and later when, in reality nothing has changed from the situation that was committed when the signaller put 2Y09 ahead of 1W96.

So, my questions are:

• why does the NR 'status' field show an expected departure time equal to the Traksy estimated arrival time for 1W96, even though it is scheduled to have a 14 minute dwell at Edinburgh?
• why does the NR 'status' field show an impossible arrival time, given that the train is following another train with a later scheduled arrival?
• how much manual intervention is there in the algorithms that produce these estimated times in the 'status' fields to provide intelligent input into the data?

[Footnote: 1W96 has just left at 1710.]

 

[pdeaves]

why does the NR 'status' field show an impossible arrival time, given that the train is following another train with a later scheduled arrival?

I suspect the system knows that the timetable requires a certain journey time and has a certain amount of padding. Thus it knows the train 'should' be able to arrive at such and such time, without having any ability to know or take account of a train stuck behind another one.

 

[Surreytraveller]

The systems aren't that clever. They could be, but then the computers would start assuming things that wouldn't always be right.
Theoretically it might be possible for the fast train to pass the slower one if bi-directional signalling were to be used, so perhaps the system considers this possibility?

 

[js1000]

In my experience they usually state the 'best-case scenario'. Generally I find it to be accurate enough to reliably use. It can take longer to process when a faster train is held up behind a stopper. This is isolated around certain stations and lines - potentially as Surreytraveller says bi-directional signalling is possible and the algorithm will assume this? I've noticed an anomaly when substitute rolling stock is used. For instance, it's fairly obvious when a substitute 75mph 150 is being used instead of a 90mph 323 but the feed is still somewhat over-ambitious as it seems to still allocate 'padding' is to a faster unit class that is not in service. Conversely, same can be applied to the 90mph+ 195s on routes timetabled to 75mph Class 150s which they have replaced in recent months - they're nippy enough to make up lost time on the 75mph timetabled service. Seems to be a lot of variables in the algorithm that are difficult to explain.

 

[takno]

Traksy takes a pretty naive approach - we just take the last trust report and assume that the only time the train will catch up is performance allowances.

The automatic algorithm for National Rail appears to do much the same thing, albeit also using the signal data to update some routes slightly more regularly. The main differences is that it seems to fall back quite regularly to just saying "Delayed" rather than risking giving people info that might make them miss their train. The major difference is that they seem to assume that the train will be able to catch up almost all of any extended station call.

It would be pretty difficult to figure out algorithmically how long a train will be delayed if it is stuck behind another train for a few reasons. Firstly, even working out that a train is in this position is difficult without a pretty detailed network model and complex set of rules. Secondly, it's difficult to know whether things are just going to be left to run their course - maybe the slow train will be looped or cancelled or given a better path at a junction because of the following train. Thirdly, it's not impossible that the operator will do something like run a different train over a later portion of the service rather than running it through and delayed.

I'm somewhat inclined to remove the predictions from Traksy altogether, or replace them with the national rail ones. People can see how late the train is right now and predict from that with just as much confidence.

 

[_toommm_]

In this case, the system doesn't know what is ahead of the train so it can't accurately calculate if it will experience any further delays and won't be able to have an allowance for this.

I was on this train today all the way from Kings X to Inverness and we hit an ESR just outside Inverness, but it won't account for that either. It'll also struggle up there as well as some points don't report correctly on its journey, so it can go off the radar for a while.

 

[Surreytraveller]

In this case, the system doesn't know what is ahead of the train so it can't accurately calculate if it will experience any further delays and won't be able to have an allowance for this.

I was on this train today all the way from Kings X to Inverness and we hit an ESR just outside Inverness, but it won't account for that either. It'll also struggle up there as well as some points don't report correctly on its journey, so it can go off the radar for a while.

I believe on the Highland Mainline, TRUST reports are input manually by the signallers, so there is no automated train tracking

 

[takno]

I believe on the Highland Mainline, TRUST reports are input manually by the signallers, so there is no automated train tracking

I assume (although I'm not certain) that reports as far as Carrbridge are automatic now. If the delay was closer to Inverness than that then yes it would be manual

 

[whhistle]

Darwin takes information from a bunch of sources, mainly Train Describers (which are at fixed points along the track).
They also take information from TRUST (which gets most of it's info from Train describers), Control messages and CIS Controller input to decide how late a train is.

As others have said, Darwin won't take anything else into consideration.
If a train goes "off route" from the expected route, Darwin will mark the train as "Delayed" until it shows at an expected train describer point. Darwin cannot track a train off-route so doesn't know how late it is.

For example on the West Coast, if a train is diverted via Northampton instead of taking the main line, until it hits the train describer outside Rugby (where the lines meet again), Darwin will mark the train as "Delayed". CIS Controllers can (and usually do) override this with a particular time (for this example, about 20 mins extra). The CIS will show that extra delayed time until it gets further information (IE, the train passes the Rugby train describer) and updates accordingly.

All this information gets added to Darwin, which then outputs it all so wherever you look (online, at the station, through apps), all the information should be the same.

 

[Edinburgh2000]

Thanks for these helpful responses to my OP. I take it then that the answer to my question:

• how much manual intervention is there in the algorithms that produce these estimated times in the 'status' fields to provide intelligent input into the data?

is: "None at all."

It appears that the system is allowed to generate its own forecasts for the expected departure times at later stations, with no manual intervention. That is a shame, as there must be many cases where a signaller or other railway staff can see that the expected time being shown to passengers is patently wrong.

Would it really be so difficult to add a facility into the system such that authorised staff from the control rooms, or signallers, could manually input an estimated departure time? The system could simply be programmed to show the later of the system-generated forecast or the manually input forecast. In the example I give in the OP, that would have allowed the signaller who decided to put 2Y09 ahead of 1W96 to add an estimated departure for 1W96 from Edinburgh of 1710. That would have stayed as the displayed forecast departure, unless 1W96 got even later.

I believe on the Highland Mainline, TRUST reports are input manually by the signallers, so there is no automated train tracking

That is a separate point. I think you mean that the signallers manually input the actual times a train passes a reporting point, once it has occurred. I was asking about forecast times and whether signallers have any opportunity to input their intelligence into the system to advise passengers when the train is likely to depart from later station stops. I think the posts above have implied that there is no such option for signallers to help customers.

 

[takno]

Thanks for these helpful responses to my OP. I take it then that the answer to my question:


is: "None at all."

It appears that the system is allowed to generate its own forecasts for the expected departure times at later stations, with no manual intervention. That is a shame, as there must be many cases where a signaller or other railway staff can see that the expected time being shown to passengers is patently wrong.

Would it really be so difficult to add a facility into the system such that authorised staff from the control rooms, or signallers, could manually input an estimated departure time? The system could simply be programmed to show the later of the system-generated forecast or the manually input forecast. In the example I give in the OP, that would have allowed the signaller who decided to put 2Y09 ahead of 1W96 to add an estimated departure for 1W96 from Edinburgh of 1710. That would have stayed as the displayed forecast departure, unless 1W96 got even later.




That is a separate point. I think you mean that the signallers manually input the actual times a train passes a reporting point, once it has occurred. I was asking about forecast times and whether signallers have any opportunity to input their intelligence into the system to advise passengers when the train is likely to depart from later station stops. I think the posts above have implied that there is no such option for signallers to help customers.

I think there is an ability to add a manual override, but it would take some time to accurately calculate it and work through any scenarios. Possibly there should be people available to do that, but it would be pretty expensive, and the signaller would be very unlikely to have time in a lot of boxes.

Ultimately it's probably better to give customers an earlier time than turns out to be the case and have them waiting on the platform, than give them a later time and let them wonder off to the pub and miss the train

 

[Surreytraveller]

I think there is an ability to add a manual override, but it would take some time to accurately calculate it and work through any scenarios. Possibly there should be people available to do that, but it would be pretty expensive, and the signaller would be very unlikely to have time in a lot of boxes.

Ultimately it's probably better to give customers an earlier time than turns out to be the case and have them waiting on the platform, than give them a later time and let them wonder off to the pub and miss the train

Yes, it would require additional staff to be employed, as I wouldn't think any existing staff would have the time to do it, especially if there were any disruption going on. In addition, those staff would be second guessing what the signallers or other control staff would be doing, perhaps guessing what decisions would be made before those decisions had been made during dynamic and very fluid situations.
The end result would then be worse than the current system.

 

[Surreytraveller]

That is a separate point. I think you mean that the signallers manually input the actual times a train passes a reporting point, once it has occurred. I was asking about forecast times and whether signallers have any opportunity to input their intelligence into the system to advise passengers when the train is likely to depart from later station stops. I think the posts above have implied that there is no such option for signallers to help customers.

Calm down dear. I was merely responding to somebody else's post, and it adds to people's understanding of how data is input into the system

 

[splitfare]

Ultimately it's probably better to give customers anearlier time than turns out to be the case and have them waiting on the platform, than give them a later time and let them wonder off to the pub and miss the train

As a passenger, I agree - I’d rather be given a time that is perhaps “optimistic” even “impossible” when other factors are taken into account - this will ensure I’m on the platform when the train does arrive rather than an “estimate” that might be improved on, which as takno suggests might encourage people to walk away from the platform and consequently miss the train should it gain time against the estimate.

 

[Edinburgh2000]

My apologies to whhistle, whose post #9 was one minute before my post #10 and so I had not seen it. Your explanation is most helpful:

CIS Controllers can (and usually do) override this with a particular time (for this example, about 20 mins extra). The CIS will show that extra delayed time until it gets further information ...... and updates accordingly.

All this information gets added to Darwin, which then outputs it all so wherever you look (online, at the station, through apps), all the information should be the same.

and this changes the answer to my OP. It seems that there is indeed an opportunity for manual intelligent intervention to override the expected times shown in the system.

 

[Surreytraveller]

My apologies to whhistle, whose post #9 was one minute before my post #10 and so I had not seen it. Your explanation is most helpful:


and this changes the answer to my OP. It seems that there is indeed an opportunity for manual intelligent intervention to override the expected times shown in the system.

Yes, there is opportunity, BUT this would involve the CIS Operators second-guessing what Signallers and Control are going to do. Controllers would make decisions based on crew workings, stock workings and other information. It could get very messy if information were to be manually input into the system.

 

[Edinburgh2000]

Yes, there is opportunity, BUT this would involve the CIS Operators second-guessing what Signallers and Control are going to do. Controllers would make decisions based on crew workings, stock workings and other information. It could get very messy if information were to be manually input into the system.

So what does a CIS Operator do?

 

[Surreytraveller]

So what does a CIS Operator do then?

They would input any known alterations, such as cancellations, running fast, altering train length etc. It would not be possible for them to monitor every single train on the network to see if the automated systems are guessing correctly what is going on, and overlaying those automated guesses with their own guesses (bearing in mind you've probably got one CIS Operator on duty monitoring hundreds of trains)

 

[class 9]

The systems aren't that clever. They could be, but then the computers would start assuming things that wouldn't always be right.
Theoretically it might be possible for the fast train to pass the slower one if bi-directional signalling were to be used, so perhaps the system considers this possibility?

As it was following the local from North Berwick, there's no bi directional signalling from Drem towards Edinburgh, apart from through Calton tunnels into Waverley.
Also the simplified bi directional signalling on the ECML is used in emergencies, failures and planned engineering works only, as the reduced speeds would cause considerable delays to traffic in opposite direction.

 

[Surreytraveller]

As it was following the local from North Berwick, there's no bi directional signalling from Drem towards Edinburgh, apart from through Calton tunnels into Waverley.

The systems could be designed to consider every possibility into their algorithms, but this would throw up other anomalies. Yes, it is obvious that a fast train stuck behind a stopper would lose more time, but that it assuming it won't get past the stopper, the stopper won't be sped up, the train won't be restarted at Edinburgh with fresh stock and crew etc. If you suddenly start giving people assumed information, and the assumed information turns out to be wrong, you'll look even more of an idiot than you are already, and you also have to spend more time and resources correcting the error.
There are systems in the pipeline to link all the information from different systems together to provide more accurate information, but they take years to try and get right.

 

[whhistle]

Yes, there is opportunity, BUT this would involve the CIS Operators second-guessing what Signallers and Control are going to do. Controllers would make decisions based on crew workings, stock workings and other information. It could get very messy if information were to be manually input into the system.

There isn't much second guessing.
CIS Controllers at stations use their local knowledge and practice from previous situations.
Some TOCs have their CIS controller as part of the Control team, based in the same room / neighbouring desks.
Many controllers are in the same building / room as signallers so can ask.

Remember, Train Operating Companies are Network Rail customers - Network Rail will inform TOC Controllers if trains are going to be diverted prior to the first one doing so.

A station CIS controller will know if trains are being diverted one way, it'll take an extra 20 mins. We'll stick with the West Coast for examples

- If the line [from Coventry] to Birmingham was blocked, they'd send trains to Stafford and back down to Birmingham. That takes between 45 mins and 60 mins extra. An accurate delay time can be manually inputted (or picked up from the Control message).

Another favourite is sending trains from Birmingham to Aston and "round the houses" to re-join the line at Stechford. Again, controllers know approximately how long this takes and send out a message to all staff detailing the delay. This message is picked up by Darwin and the time of the train adjusted accordingly. If the train takes less time to make this move (or longer!), as soon as it hits the train describer at Stechford the delay will automatically be adjusted.

Even "person struck by a train" incidents have a rough estimate of how much of a delay they will cause. It's clear within the first 10/20 mins or so that the situation is likely to be quick or slow to resume normal services. For this example though, there are many factors involved, such as train location, locality of other services, time of day... all these play a part in the Controller deciding how long a delay may be.
Most mark the train as "Delayed" and that's that.

Controllers are aware of these diversions and disruptions and can forecast accordingly and pretty accurately.

 

[whhistle]

Interestingly there was a discussion whether marking a train as "Delayed" or giving a time (that increases by 1 minute, every minute) is best. There was a third choice of adding a 20 minute delay.

This is only in the context of an unknown delay time (for example if a train has a fault that isn't a quick fix).
- a train that is diverted (and still moving) is very different.

Do CIS controllers mark the train as "Delayed" and thus the customer may think it could turn up in 2 mins, 20 mins, 2 hours or never?

Do CIS controllers allow the train to increase delays by 1 or 2 mins every 1 or 2 mins? But then this annoys customers as the delay keep changing.

The third option was to add 20 mins delay to a train. But what happens if the train fault is solved in 5 mins? The customer may have thought "oh, it's coming in 20 mins, I'll pop to the shop" and then miss their train.

There are no other choices for how to convey a message of "the train is broken down. The fault could be solved in 5 mins, or 50 mins."

An industry meeting discounted the third option and it was agreed it wouldn't be promoted for use in practice. TOC reps from the south said their customers didn't mind it being marked as "delayed", while those in the north wanted a particular time to be displayed. The Darwin program had to be configured one way or the other to promote consistency of information.

I believe each TOC has it's own policy on the matter but one very inventive CIS controller displayed "delay at least 20 mins" so customers could see even if the train started moving straight away, there was at least a 20 minute delay.
This also plugs into the "last reported at..." section of some CIS screens.

 

[Surreytraveller]

There isn't much second guessing.
CIS Controllers at stations use their local knowledge and practice from previous situations.
Some TOCs have their CIS controller as part of the Control team, based in the same room / neighbouring desks.
Many controllers are in the same building / room as signallers so can ask.

Remember, Train Operating Companies are Network Rail customers - Network Rail will inform TOC Controllers if trains are going to be diverted prior to the first one doing so.

A station CIS controller will know if trains are being diverted one way, it'll take an extra 20 mins. We'll stick with the West Coast for examples

- If the line [from Coventry] to Birmingham was blocked, they'd send trains to Stafford and back down to Birmingham. That takes between 45 mins and 60 mins extra. An accurate delay time can be manually inputted (or picked up from the Control message).

Another favourite is sending trains from Birmingham to Aston and "round the houses" to re-join the line at Stechford. Again, controllers know approximately how long this takes and send out a message to all staff detailing the delay. This message is picked up by Darwin and the time of the train adjusted accordingly. If the train takes less time to make this move (or longer!), as soon as it hits the train describer at Stechford the delay will automatically be adjusted.

Even "person struck by a train" incidents have a rough estimate of how much of a delay they will cause. It's clear within the first 10/20 mins or so that the situation is likely to be quick or slow to resume normal services. For this example though, there are many factors involved, such as train location, locality of other services, time of day... all these play a part in the Controller deciding how long a delay may be.
Most mark the train as "Delayed" and that's that.

Controllers are aware of these diversions and disruptions and can forecast accordingly and pretty accurately.

A CIS Operator at one station only intersted in trains through their station may be able to keep on top of it.

They are doing away with CIS Operators being based in the same room as signallers. Now try being a CIS Operator for a whole TOC trying to keep track of all trains during mass disruption. If all trains are being diverted one way, it may, or it may nott add 20 minutes to the journey. If one train is diverted and it is not stuck behind a stopper - but how long will it add journey times for a mixture of fast and stopping trains, on a piece of track designed for six trains an hour, now having to take twelve trains an hour?

Any manual inputs a CIS Operator puts into the system, as soon as the system receives an automated input, adjusts the manual input. Thereby undoing the work of the CIS Operator.

It ain't as easy as your post suggests!

And although officially TOCs are Network Rail's customers - in reality, the TOCs do what Network Rail tells them (yes, there is some wiggle room, but if NR says no, then its no). It is not like you going to Tesco.

 

[Edinburgh2000]

There isn't much second guessing.
CIS Controllers at stations use their local knowledge and practice from previous situations.

Many thanks whhistle. Very enlightening.

So am I right then to infer (although this isn't your patch north of the border) that in the example in my OP, the CIS Controller, being a local person knowing that there are no passing loops or bi-directional signalling from Drem to Edinburgh, would see quickly that the LNER train (1W96) could not arrive before the stopper (2Y09), and so he or she could have manually input an estimated departure time of 1710, knowing that that was the best that could be achieved? But we understand with constraints on time and resource it would not always be possible for such manual interventions to be made and so the default is just to let the system generate the predicted times.

 

[Wombat]

Interestingly there was a discussion whether marking a train as "Delayed" or giving a time (that increases by 1 minute, every minute) is best. There was a third choice of adding a 20 minute delay.

This is only in the context of an unknown delay time (for example if a train has a fault that isn't a quick fix).
- a train that is diverted (and still moving) is very different.

Do CIS controllers mark the train as "Delayed" and thus the customer may think it could turn up in 2 mins, 20 mins, 2 hours or never?

Do CIS controllers allow the train to increase delays by 1 or 2 mins every 1 or 2 mins? But then this annoys customers as the delay keep changing.

The third option was to add 20 mins delay to a train. But what happens if the train fault is solved in 5 mins? The customer may have thought "oh, it's coming in 20 mins, I'll pop to the shop" and then miss their train.

There are no other choices for how to convey a message of "the train is broken down. The fault could be solved in 5 mins, or 50 mins."

An industry meeting discounted the third option and it was agreed it wouldn't be promoted for use in practice. TOC reps from the south said their customers didn't mind it being marked as "delayed", while those in the north wanted a particular time to be displayed. The Darwin program had to be configured one way or the other to promote consistency of information.

I believe each TOC has it's own policy on the matter but one very inventive CIS controller displayed "delay at least 20 mins" so customers could see even if the train started moving straight away, there was at least a 20 minute delay.
This also plugs into the "last reported at..." section of some CIS screens.

That's very interesting, thank you. I think I prefer option 1 - when I see an expected departure time creeping up in increments of one minute, I start thinking "You clearly don't know, so why keep up the pretence?" On the other hand, I think that most delays on my route are only a few minutes, so a flat "Delayed" may be overly pessimistic. How about having a "Minor delay" status, which can escalate into a "Major delay" after a certain amount of elapsed time or when someone sets the status manually?

 

[221129]

Many thanks whhistle. Very enlightening.

So am I right then to infer (although this isn't your patch north of the border) that in the example in my OP, the CIS Controller, being a local person knowing that there are no passing loops or bi-directional signalling from Drem to Edinburgh, would see quickly that the LNER train (1W96) could not arrive before the stopper (2Y09), and so he or she could have manually input an estimated departure time of 1710, knowing that that was the best that could be achieved? But we understand with constraints on time and resource it would not always be possible for such manual interventions to be made and so the default is just to let the system generate the predicted times.

They normally do tbf. However if the train is still moving it will undo any manual input as it passes every reporting point.

 

[londonmidland]

That's very interesting, thank you. I think I prefer option 1 - when I see an expected departure time creeping up in increments of one minute, I start thinking "You clearly don't know, so why keep up the pretence?"

This happens a lot at Birmingham New Street.

I was waiting for my Liverpool service, which was on time until just outside the station, where it got held up at Proof House Jn.

So it went from on time, to expected, to delayed, and then back to expected once the train started moving. Creeping up after each minute past.

Is it after three minutes of no movement where it then changes from expected to delayed?

 

[221129]

This happens a lot at Birmingham New Street.

I was waiting for my Liverpool service, which was on time until just outside the station, where it got held up at Proof House Jn.

So it went from on time, to expected, to delayed, and then back to expected once the train started moving. Creeping up after each minute past.

Is it after three minutes of no movement where it then changes from expected to delayed?

Aye thereabouts.

 

[whhistle]

...the LNER train (1W96) could not arrive before the stopper (2Y09), and so he or she could have manually input an estimated departure time of 1710, knowing that that was the best that could be achieved?

I'd say so yes.
Although Darwin does go a bit further and it should be able to realise a slower stopper is in front and adjust the times by itself.
In practice though, the stopper may show an arrival time of 17:10. Darwin will mark the express as a 17:11 arrival, even though that's unrealistic It may have been fixed changed by now though.

 

[whhistle]

There's more fun with Darwin around the network too.
It should have been solved as there's a limited amount of places this happens but the train describers in and around Exeter made Darwin act a little strangely. Something about trains that stop at St Davids and St Thomas (?) and perform some sort of reversal move, but as there aren't any TDs in between, the train automatically marks as "Delayed" until it rolls in.

Similarly, there are stretches on the Chiltern lines and certainly in Wales that have a very long stretch between train describers. In the early days, some services would be marked as "delayed" as it Darwin didn't take into account the distance between the describers. Special programming should have been written in to combat this.

There was also a vote by TOC reps on how long Darwin would automatically mark a train as "delayed". It used to be 5 or 7 mins or something. This was changed to just 3 minutes (which then caused the Welsh problem!), although may have changed again since I was involved.