RTT - Why The Change Of Cancellation Reason?

[Deepgreen]

Today, a GWR class 769 working from Reading to Gatwick failed to run owing, according to the first report on RTT, to "a problem with the train". The return, and subesquent, runs are shown on RTT as cancelled "owing to the late arrival of the inbound service". Why is the initial reason for the cancellation not carried through to the consequent cancellations, as it is more accurate?

 

[Bertie the bus]

It is an ECS working so it really doesn't matter. It is also not at all uncommon. During the 2018 Northern fiasco inbound workings often showed as being cancelled due to crew issues and the corresponding outbound working then showed as cancelled due to the late arrival of an inbound service. I doubt normal passengers take much notice of the reason anyway.

 

[XAM2175]

Why is the initial reason for the cancellation not carried through to the consequent cancellations, as it is more accurate?

RTT repeats the reason that is shown in the industry public data feeds. In the industry delay attribution system the cancellation of the return service will be linked to the cancellation of the inbound, so it is technically correct to say that the return is cancelled because the inbound didn't arrive.

 

[JN114]

Today, a GWR class 769 working from Reading to Gatwick failed to run owing, according to the first report on RTT, to "a problem with the train". The return, and subesquent, runs are shown on RTT as cancelled "owing to the late arrival of the inbound service". Why is the initial reason for the cancellation not carried through to the consequent cancellations, as it is more accurate?
View attachment 102555View attachment 102556

RTT is ‘dumb’ in the sense that it literally takes the 2 character attribution code and translates it into something a little easier to understand for a human reading it.

I’m sure those trained in the dark arts can suitably correct it, but for the lay person:-

In delay attribution, the directly affected train will be coded to the code of the cause - IE ‘M0’ - Cab Safety Systems.

Any subsequent trains delayed/cancelled by that incident will be put into that incident, with a code showing why they’re delayed by that incident - that may be ‘YI’ awaiting inward stock or ‘YD’ following a late running train that is later than this one or so forth.

The full list of codes is available at

wiki.openraildata.com/index.php?title=Delay_Attribution_Guide

They all get merged into the same incident on industry systems, but RTT just reads and translates the raw code and displays it to the public.

Train operators themselves will use a different mechanism for informing their customers, whereby control staff or similar will update systems that feeds to info screens, apps and the like. That feed is also available as an open data feed, and some other websites make use of it. RTT don’t, and there’s a whole raft of politics behind that that probably don’t need to be gone over.

 

[bb21]

Today, a GWR class 769 working from Reading to Gatwick failed to run owing, according to the first report on RTT, to "a problem with the train". The return, and subesquent, runs are shown on RTT as cancelled "owing to the late arrival of the inbound service". Why is the initial reason for the cancellation not carried through to the consequent cancellations, as it is more accurate?
View attachment 102555View attachment 102556

It is simply that the data feed uses delay attribution codes as others explained, and delay attribution codes are not meant to necessarily make sense to the general public.

If you don't use it for work, or even for most people who use it at work, there will be parts of the system which make no sense. It serves a contractual purpose and that is all those codes do.

 

[Deepgreen]

RTT repeats the reason that is shown in the industry public data feeds. In the industry delay attribution system the cancellation of the return service will be linked to the cancellation of the inbound, so it is technically correct to say that the return is cancelled because the inbound didn't arrive.

It didn't say it "didn't arrive" - it said it was "late", which is incorrect, as it had already been cancelled. Although virrtually no passenger will care about this particular mileage accumulation run, I asked only out of curiosity as it seems to complicate things unnecessarily to have two reasons for the same cause. I know RTT repeats stuff in the data feed so there's no failure on the part of RTT here.

 

[bb21]

YI is inward stock reactionary code. There is no differentiation between late or cancelled inward stock because there is no need to differentiate them for DA purpose.

The deciphered wording is entirely RTT trying to be helpful, which sometimes may not be perfect because the system was designed for internal industry use only.

 

[XAM2175]

It didn't say it "didn't arrive" - it said it was "late", which is incorrect, as it had already been cancelled. Although virrtually no passenger will care about this particular mileage accumulation run, I asked only out of curiosity as it seems to complicate things unnecessarily to have two reasons for the same cause.

As @bb21 says - there's no differentiation, just "YI" for "(awaiting) inward stock" and "YJ" for "(awaiting) inbound traincrew". This is the correct reason for the cancellation of 3V11; the service cannot run because the booked stock has not arrived. In the internal DA systems this will be linked as a reaction to the cancellation of 3O10 and so in effect the internal view is that 3V11 was cancelled because the booked inward stock didn't arrived, because that stock was coming in 3O10 and 3O10 was cancelled due to a train fault.

It's that causal relationship that isn't shown in the open data.

 

[Spartacus]

It didn't say it "didn't arrive" - it said it was "late", which is incorrect, as it had already been cancelled. Although virrtually no passenger will care about this particular mileage accumulation run, I asked only out of curiosity as it seems to complicate things unnecessarily to have two reasons for the same cause. I know RTT repeats stuff in the data feed so there's no failure on the part of RTT here.

RTT makes lots of over simplifications. As a trained practitioner of the darks arts I can see how RTT often takes the most basic description of what the delay code means, as written in Section S of the Delay Attribution Principles and Rules, and shows that, when in reality there are many permutations. The description in section S of YI is "Late arrival of booked inward stock...." but in reality it encompasses most aspects related to the inward working, including, but limited it, in the inward being cancelled. RTT causes complications when it simplifies like this because for one it's over simplification often means it makes no sense, and secondly by not taking the original incident into account it unintentionally muddies the waters in regard to the prime cause of the delay, which may be many, many trains previous to yours affected.