On the final signalling hiccup. Is it my imagination or are these now becoming very frequent?
Going back in time, surely failures occurred but we didn't notice? or trains ran without a problem?
I'm not sure whether exact figures on signalling failures per year, per route, are published - one for Stuving, our resident Google sleuth?
Given the track defects last night at Langley and yesterday and today at Slough you might think those were on the increase, but I think generally the opposite is true. 'Broken rails' were down a whopping 90% from 952 in 1998 to 109 in 2015 for example.
I don't think Network rail have ever published (i.e. externally) details of the failures that cause "incidents", though the Route Plans and similar documents have contained a lot of mentions of performance and how it's going to improve. But they are much fuller of jargon than comprehensible facts. Mostly you can get
PPM‡ and the like, telling you nothing about who did what do whom. I've seen promises of more useful performance information, but not anything specific.
Network Rail (
NR» ) do quite a bit of work in asset monitoring and the like (and promote it), aimed at predicting failures before they happen (the best kind of prediction, I'm sure). Some of that gets into the railway technical press. Suppliers are also busy doing this kind of stuff; even my ex-colleagues at Thales are at it now - though we didn't have any rail projects in my time. I saw a presentation of their work based on detailed analysis of the current drawn by a point motor, looking for patterns that show it meeds servicing or is about to grind to a halt. That and similar tricks may be very clever and potentially useful, but of course it all has to work, and make a difference, when rolled out on a large scale. And that I've not heard anything about.
What I have found is that NR now have a
page of links to data (search for statistics and pick "Our information and data").
There is an item for Network Performance, bit its "related link" isn't (a link). The only other thing that might be of use, if anyone has the time to make use of it, is "historical delay attribution". That's not as historical as it might be (just 2018-19 and on), but is a complete list of all delay attribution incidents. There's a short explanation of its content and the column contents, which start with:
The file attached is a standard data extract from our Performance System database (PSS▸ ). The
information within the file contains all “attributed” delays to passenger train services in line with the
guidance in the Delay Attribution Guide. The information is structured for industry systems and
understanding, the below provides a few key insights into the data contained.
The data contains both delay and cancellation events (denoted by the performance event code) and a
user should be careful when summing delay minutes (pfpi minutes) to exclude cancellation events.
Each (4-week) period's data comes in a large zipped CSV file - large as in up to 500,000 rows x 39 columns. You'll need a copy of the DAPR to hand, not just the explanation, to process that lot into anything useful! These are the column heads:
FINANCIAL_YEAR_AND_PERIOD
ORIGIN_DEPARTURE_DATE
TRUST_TRAIN_ID_AFFECTED
PLANNED_ORIG_LOC_CODE_AFF
PLANNED_ORIG_GBTT_DATETIME_AFF
PLANNED_ORIG_WTT_DATETIME_AFF
PLANNED_DEST_LOC_CODE_AFFECTED
PLANNED_DEST_GBTT_DATETIME_AFF
PLANNED_DEST_WTT_DATETIME_AFF
TRAIN_SERVICE_CODE_AFFECTED
SERVICE_GROUP_CODE_AFFECTED
OPERATOR_AFFECTED
ENGLISH_DAY_TYPE
APP_TIMETABLE_FLAG_AFF
TRAIN_SCHEDULE_TYPE_AFFECTED
TRACTION_TYPE_AFFECTED
TRAILING_LOAD_AFFECTED
TIMING_LOAD_AFFECTED
UNIT_CLASS_AFFECTED
INCIDENT_NUMBER
INCIDENT_CREATE_DATE
INCIDENT_START_DATETIME
INCIDENT_END_DATETIME
SECTION_CODE
NETWORK_RAIL_LOCATION_MANAGER
RESPONSIBLE_MANAGER
INCIDENT_REASON
ATTRIBUTION_STATUS
INCIDENT_EQUIPMENT
INCIDENT_DESCRIPTION
REACTIONARY_REASON_CODE
INCIDENT_RESPONSIBLE_TRAIN
PERFORMANCE_EVENT_CODE
START_STANOX
END_STANOX
EVENT_DATETIME
PFPI_MINUTES
TRUST_TRAIN_ID_RESP
TRUST_TRAIN_ID_REACT
Edit: VickiS - Clarifying Acronym