Delay Repay denied - what timings are used? (update: now resolved!)

[yorkie]

The argument about 'arrival time' is one I've argued a lot with a certain TOC - there's obviously no use me arriving into a station if the train is coupling up to another train and I'm not being allowed to make my connection. It may be handy to take a photo of when you actually step onto the platform, as surely arrival time means two different things to a TOC and to a passenger.

True, but if it's a connection, the TOC absolutely does not want you to run between platforms, and if the minimum connection time isn't reached and you miss your connection as a result, then what matters is the final arrival time into your destination. Or are you saying a TOC has argued that you should have made the connection by exiting when doors are locked?

 

[robbeech]

If only there was a way for someone to be next to the door release controls at all times.

 

[island]

I have an element of sympathy for Virgin here. They can’t win really; if a train is delayed 29 minutes should it pay for 30 anyway? If so, how about 28? 27? There has to be a cut-off, and there has to be an official source.

As bb21 suggests, if someone wishes to establish a precedent about it, they should take a test case.

 

[ForTheLoveOf]

I have an element of sympathy for Virgin here. They can’t win really; if a train is delayed 29 minutes should it pay for 30 anyway? If so, how about 28? 27? There has to be a cut-off, and there has to be an official source.

As bb21 suggests, if someone wishes to establish a precedent about it, they should take a test case.

Sympathy for a company with policies (pricing, gateline training, etc.) like Virgin? Hmm, certainly not from me!

I agree that a precedent would be the best thing, but until such time, an Ombudsman decision in favour of the passenger will be the next best thing.

 

[yorkie]

I have an element of sympathy for Virgin here.

That's your choice but I don't.

Train companies like Virgin do read this forum. They know the system is unreliable. They are aware that passengers who experienced a delay of 30/60 minutes, who have told the company they were delayed by that amount, are being told: no, you're wrong. That's terrible customer service.

They can’t win really; if a train is delayed 29 minutes should it pay for 30 anyway? If so, how about 28? 27? There has to be a cut-off, and there has to be an official source.

The company should be pragmatic. If you know your official source is wrong, you either seek change within the industry, or you take the view that your cutoff will include an allowance for such inaccuracies.

If Virgin are not capable of being pragmatic, their reputation (which is already pretty abysmal) is going to suffer.

As bb21 suggests, if someone wishes to establish a precedent about it, they should take a test case.

That's not what Virgin says. They tell people to go to Transport Focus (now the Ombudsman) if they are unhappy. Chances are, they will pay up either before it gets to the Ombudsman, or the Ombudsman will side with the customer.

That said, I would like it if someone took them to court, but I can't see this being very likely. Virgin would settle the instant they discovered it was going to court as they would not want to risk a humiliating defeat. I am not sure the courts would appreciate a claim that did not go through all the proper procedures.

 

[imtotesanon]

I have an element of sympathy for Virgin here. They can’t win really; if a train is delayed 29 minutes should it pay for 30 anyway? If so, how about 28? 27? There has to be a cut-off, and there has to be an official source.

As bb21 suggests, if someone wishes to establish a precedent about it, they should take a test case.

If the train was 29 minutes late I would indeed have sympathy for Virgin if people were claiming fraudulently (and would feel slightly narked while disembarking!).

In this case, where we started rolling into the platform 30+ minutes late, there should be no argument as it doesn't matter what measure of lateness is used - the biggest issue is the source and reliability of data, which is pretty invisible as a consumer.

 

[bb21]

If the train was 29 minutes late I would indeed have sympathy for Virgin if people were claiming fraudulently (and would feel slightly narked while disembarking!).

In this case, where we started rolling into the platform 30+ minutes late, there should be no argument as it doesn't matter what measure of lateness is used - the biggest issue is the source and reliability of data, which is pretty invisible as a consumer.

There is a very big difference between what the "correct" metric is and what a company would allow. For now, the "correct" metric is unambiguous, and will remain so until a court rules otherwise, and will continue to be the official metric for the time being regardless of however some people on this forum want to interpret things. There are limitations on what the current infrastructure can do, and a court will likely appreciate that fact should a case get that far and take that into account in its rulings.

Allegations of extended time periods without doors being released can often be investigated and suitable arrangements made for those particular cases.

For the very reasons given upthread by various people I always allow a 29/59-minute claim to go through up to a certain amount. It simply isn't worth my time in admin for someone to come back arguing what may or may not have happened in the 60 seconds following that or me having to look into it again, possibly with no clearer picture at the end. It would make no commercial sense to take a different approach to small claims imo.

But for now, anyone seeking an answer as to what the official position is shall get the same answer as the one I gave previously, as it is plainly wrong and misleading for me to give people answers which are my own interpretations and what I want to happen instead, where an official answer exists, tempting as it may be sometimes.

 

[yorkie]

...For the very reasons given upthread by various people I always allow a 29/59-minute claim to go through up to a certain amount. It simply isn't worth my time in admin for someone to come back arguing what may or may not have happened in the 60 seconds following that or me having to look into it again, possibly with no clearer picture at the end. It would make no commercial sense to take a different approach to small claims imo....

This is what all companies should do, given the inadequacies of the current system.

There is no legal basis for denying legitimate claims of 30/60 minutes just because the data - which is known to be flawed - is inaccurate. Whether or not anyone would bring a legal case against TOCs I do not know, but the TOCs have to consider loss of reputation, increased admin time, and various other factors, even if they think no-one is going to bother to haul them before the courts.

 

[Belperpete]

What I still don't understand is why TRUST should show it as 29 minutes late, yet RTT showed it as 30.5 minutes late. Agreed that RTT is an unofficial public site, but it is still getting its information from railway-supplied data.

 

[bb21]

It's because RTT isn't designed for this purpose and measures against the Working Timetable.

Why I don't really know as that isn't used anywhere in the industry.

 

[Belperpete]

The argument about 'arrival time' is one I've argued a lot with a certain TOC - there's obviously no use me arriving into a station if the train is coupling up to another train and I'm not being allowed to make my connection. It may be handy to take a photo of when you actually step onto the platform, as surely arrival time means two different things to a TOC and to a passenger.

Last year, when my train pulled into Derby station, the doors were released immediately, I was first off, and I checked the clock on the platform display as soon as I stepped off, and we were 31 minutes late arriving. However, checking RTT, that showed us as only 29 minutes late. Even allowing a minute to get the door open and step off the train, that is still a minutes' difference. I did consider submitting a claim, but as I had no proof of what time we actually arrived, I didn't bother.

Thinking about this since, on the platform displays at Derby, trains show as "arrived" long before the train actually gets into the platform, let alone stops or opens its doors. I think the train is shown as "arrived" when the train description steps into the platform berth in the signalling train describer. In the train describer, train descriptions step when a train passes a signal, so a train's description will step into the platform berth when the train passes the platform home signal (the signal reading into the platform). The train may still be a long way away from the platform when that happens, depending on how far away the signal is before the platform. This train description information is widely distributed around the railway, for use by platform displays, TRUST, etc. If my surmise is correct, trains are being recorded as arrived long before they have even got into the platform, let alone stopped.

 

[Belperpete]

It's because RTT isn't designed for this purpose and measures against the Working Timetable. Why I don't really know as that isn't used anywhere in the industry.

Ah, thanks for that.
RTT gives the public times, working times and actual times. So we should calculate the minutes late ourselves, by comparing the actual against public times. Correct?

 

[_toommm_]

Last year, when my train pulled into Derby station, the doors were released immediately, I was first off, and I checked the clock on the platform display as soon as I stepped off, and we were 31 minutes late arriving. However, checking RTT, that showed us as only 29 minutes late. Even allowing a minute to get the door open and step off the train, that is still a minutes' difference. I did consider submitting a claim, but as I had no proof of what time we actually arrived, I didn't bother.

Thinking about this since, on the platform displays at Derby, trains show as "arrived" long before the train actually gets into the platform, let alone stops or opens its doors. I think the train is shown as "arrived" when the train description steps into the platform berth in the signalling train describer. In the train describer, train descriptions step when a train passes a signal, so a train's description will step into the platform berth when the train passes the platform home signal (the signal reading into the platform). The train may still be a long way away from the platform when that happens, depending on how far away the signal is before the platform. This train description information is widely distributed around the railway, for use by platform displays, TRUST, etc. If my surmise is correct, trains are being recorded as arrived long before they have even got into the platform, let alone stopped.

2 minutes could easily be lost between the actual arrival time from a passenger's POV, and signalling data, especially in areas with massive signal blocks.

 

[bb21]

Ah, thanks for that.
RTT gives the public times, working times and actual times. So we should calculate the minutes late ourselves, by comparing the actual against public times. Correct?

That is correct, yes, officially speaking.

 

[bb21]

Last year, when my train pulled into Derby station, the doors were released immediately, I was first off, and I checked the clock on the platform display as soon as I stepped off, and we were 31 minutes late arriving. However, checking RTT, that showed us as only 29 minutes late. Even allowing a minute to get the door open and step off the train, that is still a minutes' difference. I did consider submitting a claim, but as I had no proof of what time we actually arrived, I didn't bother.

Thinking about this since, on the platform displays at Derby, trains show as "arrived" long before the train actually gets into the platform, let alone stops or opens its doors. I think the train is shown as "arrived" when the train description steps into the platform berth in the signalling train describer. In the train describer, train descriptions step when a train passes a signal, so a train's description will step into the platform berth when the train passes the platform home signal (the signal reading into the platform). The train may still be a long way away from the platform when that happens, depending on how far away the signal is before the platform. This train description information is widely distributed around the railway, for use by platform displays, TRUST, etc. If my surmise is correct, trains are being recorded as arrived long before they have even got into the platform, let alone stopped.

Unfortunately the current system isn't perfect, as there is a lot of limitations owing to legacy infrastructure capabilities, even though some people would insist on them behaving to perfection without such supporting infrastructure. Generally an average offset is added on for the final section, and that would more or less cover most cases and be correct, but you win some and lose some in a small number of cases, as some trains will be shown as 30 late when only 29, and vice versa, but the discrepancy should not be statistically significant.

This offset is then regularly recalibrated, and checked over by the DfT when a TOC's performance figures are audited, for any obvious deviation from reality. Any significant mismatch would require a recalibration exercise, which does seem to crop up with revised and new track layouts more frequently than elsewhere.

Various new tech equipment has gradually allowed individual companies to start monitoring to-the-second performance, including door release times, but so far there is no consistent national agreement and they are all at various levels of advancement. Franchise terms still define all punctuality data using TRUST data, and for the foreseeable future, this looks to remain the industry standard. "Legal implications" as others put it remains to be seen.

 

[Belperpete]

2 minutes could easily be lost between the actual arrival time from a passenger's POV, and signalling data, especially in areas with massive signal blocks.

Or areas where there is a very slow speed approach to the station, as at Derby prior to the remodelling.

 

[bb21]

Or areas where there is a very slow speed approach to the station, as at Derby prior to the remodelling.

If it is a slow approach this should in theory be captured by offset data, as that would be applicable to all services. (I say in theory as I pass no comment on the quality of some of the work produced.)

What the current system cannot really handle are cases where an individual service approaches a station at a much slower than normal speed for whatever reason in the final section.

 

[Belperpete]

Unfortunately the current system isn't perfect, as there is a lot of limitations owing to legacy infrastructure capabilities, even though some people would insist on them behaving to perfection without such supporting infrastructure. Generally an average offset is added on for the final section, and that would more or less cover most cases and be correct, but you win some and lose some in a small number of cases, as some trains will be shown as 30 late when only 29, and vice versa, but the discrepancy should not be statistically significant.

This offset is then regularly recalibrated, and checked over by the DfT when a TOC's performance figures are audited, for any obvious deviation from reality. Any significant mismatch would require a recalibration exercise, which does seem to crop up with revised and new track layouts more frequently than elsewhere.

Various new tech equipment has gradually allowed individual companies to start monitoring to-the-second performance, including door release times, but so far there is no consistent national agreement and they are all at various levels of advancement. Franchise terms still define all punctuality data using TRUST data, and for the foreseeable future, this looks to remain the industry standard. "Legal implications" as others put it remains to be seen.

Again, thanks for the insight. I take it that this offset should also cover time to release doors and such-like. It is all being measured against a set of fairly-arbitary cut-offs anyway. As you say, you win some and you lose some.

 

[bb21]

It does not. This is for wheel-stop, so with an additional few seconds if you look at door release.

 

[JB_B]

It's because RTT isn't designed for this purpose and measures against the Working Timetable.

Why I don't really know as that isn't used anywhere in the industry.

I think that's a bit of a red herring. I understand that RTT shows actual-dep less WTT-dep as +ve delay in it's Dly column (excl terminals) but no-one is suggesting you would use that as a metric for delay repay. On that measure the OP was only 21 minutes late at New Street (!).

Naturally actual-arr less GBTT-arr is the measure you'd use and what's really in question here is the relative accuracy of RTT's actual figures (or other NR Darwin fed systems) as opposed to TRUST.

 

[JB_B]

There is a very big difference between what the "correct" metric is and what a company would allow. For now, the "correct" metric is unambiguous, and will remain so until a court rules otherwise, and will continue to be the official metric for the time being regardless of however some people on this forum want to interpret things. There are limitations on what the current infrastructure can do, and a court will likely appreciate that fact should a case get that far and take that into account in its rulings.

Allegations of extended time periods without doors being released can often be investigated and suitable arrangements made for those particular cases.

For the very reasons given upthread by various people I always allow a 29/59-minute claim to go through up to a certain amount. It simply isn't worth my time in admin for someone to come back arguing what may or may not have happened in the 60 seconds following that or me having to look into it again, possibly with no clearer picture at the end. It would make no commercial sense to take a different approach to small claims imo.

But for now, anyone seeking an answer as to what the official position is shall get the same answer as the one I gave previously, as it is plainly wrong and misleading for me to give people answers which are my own interpretations and what I want to happen instead, where an official answer exists, tempting as it may be sometimes.

I'm interested to know what you mean by the term "official" here (and in your earlier posts).

I understand that TRUST is the (mandatory) metric for PPM but I've not seen anything which forces TOCs to use TRUST for their Delay Repay measure - if that is the case could you point us to the DfT/ORR specification? Or is this "official" merely in the sense of being TOC policy?

There are excellent reasons to believe that Darwin driven timings could be more accurate (at least in some cases.)

See e.g...

https://wiki.openraildata.com/index.php/TRUST_vs_Darwin

In this case we have a Darwin-driven site giving 30.5 minutes delay (which fits the OP's observations.)

http://www.realtimetrains.co.uk/train/C73004/2018/12/02/advanced

but

http://charlwoodhouse.co.uk/rail/liverail/train/13764446/02/12/18

gives 29m ( in accordance with the original rejection.) I believe the latter is a TRUST-driven site ( let me know if I'm wrong )

It would be interesting to compare relative figures for various journeys just to get a feel of which of these are getting closer to reality.

 

[bb21]

I'm not aware of any TOC basing historic data on Darwin figures as a primary source, but I have not seen all of them so may have missed some. Indeed that page you linked to stated at the very top,

In most cases, you will need to choose one platform over the other for powering your application, and a good general rule is this:

• If you are looking at what has already happened, use TRUST
• If you want to see what's going to happen, use Darwin

I can't really go into great detail in terms of official documentation as the forum isn't really the place for it, nor do I have time atm to dig it all out (but I can discuss this more at a private meal), however on a practical level, I have yet to come across any industry-wide punctuality metric (which is what Delay Repay will be based on) not based on TRUST data as the primary source (but there may be some TOC-specific ones as exceptions), and I can be quite confident there aren't many metrics I have yet to come across. Anything requiring further digging could then see various other systems interrogated, which may offer higher levels of accuracy (such as data log for additional signals or to the second), but not as the primary source. That is however all rather missing the point. TRUST has long been shown and accepted as being of sufficient accuracy to the minute on the whole, with a suitable recalibration process to correct errors. Currently there is no network-wide substitute offering the same degree of confidence for accuracy, partly because most were never designed for such purpose. Is Darwin more accurate if used for historic data? I can't really tell you but I suspect it has never been subject to the same level of attention from various stakeholders (not least ORR and DfT) as TRUST data.

Where other systems which may be more accurate exist, as I mentioned above, the customer could challenge decisions and I would expect the relevant TOC to interrogate such systems upon escalation of a rejected claim to establish facts more robustly, nevertheless availability of such systems can be patchy at places, and in their absence, TRUST data should be taken as the official answer.

I'm sure some of you will be pleased to know that there are worksteams currently taking place to try and move things away from TRUST, but the end product(s) remain to be seen.

 

[JB_B]

Thanks, bb21 - that's interesting.

 

[Tetchytyke]

the TOCs have to consider loss of reputation, increased admin time, and various other factors, even if they think no-one is going to bother to haul them before the courts.

Back when refunds were paid in RTVs my experience was that TOCs were more pragmatic in their responses. But now it's paid in cash, and now unscrupulous websites are assisting people in making claims for trains they may nor may not have been on, TOCs take a firmer line. Can't say I blame them, infuriating as a 29/59 minute delay is.

It's because RTT isn't designed for this purpose and measures against the Working Timetable.

Why I don't really know as that isn't used anywhere in the industry.

In this case it's a red herring as the WTT and GBTT arrival times appear to be the same: 2004. The discrepancy is on departure, with the GBTT being 2015 and WTT being 2016.

So the question, really, is why TRUST and the data pulled from Network Rail's own systems are different?

 

[bb21]

I don't really know tbh as I don't really know where RTT pulls its data from or what they did to it, or anything to do with the open data initiative feeds. I know in the past RTT have done funny things at times, eg. where certain parts of the journey were missing, so it is a possibility if TRUST data were retrospectively infilled, but I can't check now for that possibility as the train is more than 14 days old.

In answer to discrepancies between different systems, it is possible as I have certainly seen them before. As to why different systems exist, much of it I suspect comes down to a lack of coordination and these being end-products of projects serving different purposes. I was at an RSSB meeting recently and it is widely agreed across the industry that the whole industry is data-rich, however getting the databases to talk to each other, and getting some of them into readable format, still presents big challenges, as most were designed with particular objectives in mind following some sort of initiative, usually without much consideration for integration with other systems. I've probably digressed a little here.

 

[Tetchytyke]

I've probably digressed a little here.

No, it's really interesting.