Allocating headcodes

[Junior]

I'm involved in the upgrade of a railway terminal and am finding myself involved in discussions with the signalling and operational fraternity. I'm not railway technical, but interested in risk.

Part of the discussion relates to risk of dewirement resulting from accidental routing of electric trains into non-electrified sidings, the cause being wrong allocation of a train's headcode.

I'm trying to understand how credible a risk this is...

• how are headcodes allocated (ie manually or by computer)
• how often are they allocated (ie allocated on a daily, monthly, annual basis etc) - presumably dependent on route
• are they unique (ie once a headcode is allocated, can it be allocated again?)

Is there any other information available to the signaller that would prevent this risk from eventuating?

I've looked through RAIB accident reports but can't find reference to any accidents relating to headcodes - therefore does this seem credible?

 

[The Planner]

We don't allocate headcode's that would determine what traction it is using. The signaler has the ability to interrogate the schedule to find out what it consists of in terms of traction and wagons using TRUST/TOPS. I don't think the headcode is a risk.

 

[pdeaves]

Headcodes are not unique. Generally it is highly unlikely that two trains with the same headcode would be in the same area at once but occasions have happened.

 

[IanXC]

We don't allocate headcode's that would determine what traction it is using. The signaler has the ability to interrogate the schedule to find out what it consists of in terms of traction and wagons using TRUST/TOPS. I don't think the headcode is a risk.

2Ixx Leeds towards Wigan Wallgate are in the LTP as 2Rxx where there is planned to be a 153 in the formation to indicate they must go to Wigan North Western and not to Wallgate where they are not route cleared.

 

[ComUtoR]

From a Drivers perspective. Many of us do not know how the headcode relates to routing information. Most of us would be happy to run around as 1A00 all day and not give a fork and spoon. There is mitigation against a wrong route because of "route knowledge" I don't believe that anything "railway" should be taken in isolation.

A couple of reports I have read recently have highlighted that human factors are still the highest risk. A wrong route on our patch recently was simply because the Signaller pressed the "wrong button"

 

[Horizon22]

Headcodes are helpful for an "at a glance" look for signallers / controllers. But I certainly wouldn't expect signallers to assume anything as to a particular stock. It's not hard to interrogate TRUST to check workings.

Headcodes (officially train IDs) are set up at the planning stage and normally for convenience in a sequential order (1A01 - 1A02 etc.). Some routes will use even and odd to signify up and down, some will change the letter to signify this (e.g. 1A01 up, 1B01 down). On Southeastern odd and even last digits are generally used to signify Cannon Street or Charing Cross services. So each region will be slightly different. Headcodes should be input into the base timetable for the day although I don't know the specifics of how this reaches the signalling systems. Any alterations to the plan can also be discussed with signallers and input manually. As an aside, modern train stock will allow the driver / guard to input the headcode to activate the CIS properly. They are also used for GSMR purposes.

To prevent an issue the signaller has multiple options; interrograte TRUST as below, check the simplifiers or failing that simply ask the driver/confirm with Control.

 

[Class 170101]

I'm involved in the upgrade of a railway terminal and am finding myself involved in discussions with the signalling and operational fraternity. I'm not railway technical, but interested in risk.

Part of the discussion relates to risk of dewirement resulting from accidental routing of electric trains into non-electrified sidings, the cause being wrong allocation of a train's headcode.

I'm trying to understand how credible a risk this is...

• how are headcodes allocated (ie manually or by computer)
• how often are they allocated (ie allocated on a daily, monthly, annual basis etc) - presumably dependent on route
• are they unique (ie once a headcode is allocated, can it be allocated again?)

Is there any other information available to the signaller that would prevent this risk from eventuating?

I've looked through RAIB accident reports but can't find reference to any accidents relating to headcodes - therefore does this seem credible?

In terms of incidents take a look at the recent incident at Neville Hill where although the main issue was speed causing the crash reference was made to headcode issues leaving Leeds for the depot and the distraction caused.

In another Thread its also been mentioned recently about two trains having the headcode 1O14 (I think) in the Reading area at the same time - its around 13:30 at Reading. This is no no in Train Planning terms and it was mentioned about GSMR Radio issues as well - a safety issue therefore.

A train headcode is unique at the planning level but it is NOT unique at the signaller level so two of the same four digit headcode should be set apart by at least 6 hours and preferably more.

 

[Horizon22]

In terms of incidents take a look at the recent incident at Neville Hill where although the main issue was speed causing the crash reference was made to headcode issues leaving Leeds for the depot and the distraction caused.

In another Thread its also been mentioned recently about two trains having the headcode 1O14 (I think) in the Reading area at the same time - its around 13:30 at Reading. This is no no in Train Planning terms and it was mentioned about GSMR Radio issues as well - a safety issue therefore.

A train headcode is unique at the planning level but it is NOT unique at the signaller level so two of the same four digit headcode should be set apart by at least 6 hours and preferably more.

Neville Hill wasn't really that - the issues was with the TMS software and the driver having issues setting that up - the headcode was incidental to the matter.

 

[Bald Rick]

The risk here is not what headcode (aka reporting number) is allocated in the train planning process.

The risk is a train being described incorrectly in the signalling system, either through a data error in the daily upload from the Train Planning system, or through an input error by a signaller in areas without automatic route setting. In both cases, if not identified and corrected, there is then potential for a wrong routeing at some point after its departure from origin. If that wrong routeing is from an electrified route on to a non electrified route, and the driver doesn’t spot the wrong route and accepts it, you are likely to have a train off the wire. In some circumstances, this can bring the wires down.

How often do trains get described incorrectly in the signalling system? Every day, somewhere, and wrong routeings for this reason are fairly common as a result. How often does it lead to a train off the wire? Infrequently, as mitigations are in place to prevent it where the risk exists. However the risk is credible.

The best mitigation, other than signage, is to have run off wires through the relevant junctions, which gives the driver more chance to realise he/she is on a wrong route and stop before running off the wire, and also eliminates any dewirement risk.

 

[Class 170101]

Neville Hill wasn't really that - the issues was with the TMS software and the driver having issues setting that up - the headcode was incidental to the matter.

But remember the headcodfe set up what the train was supposed to be doing and it set the Diesel engines to operate from cold rather than pre-heat thus distracting the driver.

The best mitigation, other than signage, is to have run off wires through the relevant junctions, which gives the driver more chance to realise he/she is on a wrong route and stop before running off the wire, and also eliminates any dewirement risk.

I am guessing here the wire overruns don't exist. I'm aware of several locations in Anglia alone where thery don't exist and off runs have occurred including at Ely North Jn.

 

[Bald Rick]

I am guessing here the wire overruns don't exist. I'm aware of several locations in Anglia alone where thery don't exist and off runs have occurred including at Ely North Jn.

I am guessing that in the example quoted by the OP, there is a debate about whether run offs should be provided or not for a reconfigured layout that has electrified and non-electrified sidings

The answer to that will depend on various matters, including the frequency of electric / non-electric traction, the speed at which drivers will be driving at when the relevant critical junction is reached, the nature of the layout itself, and the consequences of a train coming off the wire, in terms of safety, performance, ability to recover, and potential damage.

 

[ComUtoR]

Neville Hill wasn't really that - the issues was with the TMS software and the driver having issues setting that up - the headcode was incidental to the matter.

I thought the TMS software issue was because it was directly linked to the headcode. A lot of 700 issues were because of the TMS/PIS link. Thankfully this has been removed with 707s

 

[AMD]

I thought the TMS software issue was because it was directly linked to the headcode.

It wasn't necessarily the headcode itself that caused the issue but the input method into the TMS screen that caused the issue, if you read the report it notes that the method to input the headcode had been trained wrongly in both the simulation environment and the real life cab - this then caused the distraction issue with the driver as the headcode hadn't been accepted and he was trying to resolve the situation, and lost his situational awareness in regards to the HST he was following.

 

[ComUtoR]

It wasn't necessarily the headcode itself that caused the issue but the input method into the TMS screen that caused the issue, if you read the report it notes that the method to input the headcode had been trained wrongly in both the simulation environment and the real life cab - this then caused the distraction issue with the driver as the headcode hadn't been accepted and he was trying to resolve the situation, and lost his situational awareness in regards to the HST he was following.

I've read it a couple of times. I'm acutely aware of the training aspect and the NTS failures. I might have another read and go back over the technical apsects. I think my perspective is a little skewed because of the direct impact to my current role :? Cheers.

 

[jfollows]

My understanding from the report is that the software required the driver to press the "check stops" button as part of the process of entering a new train headcode.

This seems to me as a major design issue because the software developers did not think this through. Checking the stops of a passenger train makes sense, but why would a driver want to check the stops on a non-stopping direct ECS service?

Then the problem was compounded by poor documentation and implementation of a simulator and an "app" which did not require drivers to use "check stops" to enter a new headcode.

So I see it as quite understandable how the driver was confused and distracted.

 

[Horizon22]

I've read it a couple of times. I'm acutely aware of the training aspect and the NTS failures. I might have another read and go back over the technical apsects. I think my perspective is a little skewed because of the direct impact to my current role :? Cheers.

Yes the driver had issues setting up the headcode at Leeds (as he'd be trained incorrectly). As he was concerned he might get into issues when he reached Neville Hill, he started trying to do this whilst moving, hence being distracted causing the crash. So the primary issue was distraction by the TMS, with the detail being the headcode and "check stops" issue

 

[jfollows]

Of course I'm not a train driver, but to me it seems wrong that a train's behaviour differs based on what headcode it's been told that it has coupled with its understanding of what that means in the timetable. From my perspective, as someone who worked with computers for his entire working life, it seems that someone has thought that using complicated software to solve a problem is the right thing to do, and it seems wrong to do that to me. One result can be that, documented in the Neville Hill case, the driver disables parts of the computer software - but this could lead to other unwanted effects.

I just can't help think that train software is too complex for its own good nowadays. But I'm only an interested observer.

 

[Horizon22]

Of course I'm not a train driver, but to me it seems wrong that a train's behaviour differs based on what headcode it's been told that it has coupled with its understanding of what that means in the timetable. From my perspective, as someone who worked with computers for his entire working life, it seems that someone has thought that using complicated software to solve a problem is the right thing to do, and it seems wrong to do that to me. One result can be that, documented in the Neville Hill case, the driver disables parts of the computer software - but this could lead to other unwanted effects.

I just can't help think that train software is too complex for its own good nowadays. But I'm only an interested observer.

I mentioned this on a previous thread that drivers of 20+ years who have trained with a mechanical mind now need to have a computational mind with the new rolling stock coming in and that's not always as easy as it seems. Some training regimes have made assumptions they'd pick it up. The issue here I think was the driver thought there was going to be an issue, when in reality it would be unlikely. Again that's poor training.

Probably some systems are a bit too complex and could do with better UI/UX testing, but its not something that can't be reasonably easy overcome. Anyway we're going off the topic a little here.