Reasons for delays are announced based on what the delay attribution system says.
If there is a train failed without power, and there’s a pantograph on the floor, it will usually go down to a fault with the power supply, (Code I1), or possibly an electrification operational incident under investigation (OI). These will be announced as an issue with the power supply or overhead lines, both by auto announcers and any manual announcements.
After a little investigation, it becomes apparent what happened, and the incident was reallocated to being down to the driver. The delays are reallocated to this code (TG). However, for obvious reasons (same as with SPADs and other driver errors) they are announced as operational incidents.
If only delays were attributed that quickly! Its much more common to see information provided by TOC Customer Information desks being used in creating delay incidents than the other way around. Plus as JN114 stated, there is no automated link, or even mapped list from one to the other.
The only delay reason that really annoys me is " .... due to late arrival of the incoming service" - a Waterloo favourite. OK - so why was that, then?
Thats a local decision - such a reason isn't in the main Darwin feed list of reasons: https://wiki.openraildata.com/index.php/Darwin:Late_Running_reason_codes_and_text
Na the worst is what I heard at Bristol Parkway yesterday. Something to the effect of "due to a short notice change to the timetable". Well yes. But no mention of the real reason (overrunning engineering works).
The difference being that 'a short notice alteration to the timetable' should mean a plan to amend the service has been put in place before the start of service due to a known issue. Whereas 'overrunning engineering works' should be something that has happened unexpectedly.
