UK railways seem to be missing technology and capability to prevent collisions

[fishwomp]

Moderator note: split from

Report of collision Bedford (Elstow) - 19/06/26

Hearing reports of a collision between two trains at Bedford with one train now derailed

www.railforums.co.uk

It's somewhat surprising if no system was fitted as they are relatively easy to retrofit.

However, such a system, whether fitted or not, may not have been effective at this signal. A SPAD monitoring system would be looking for a condition of signal showing red and track circuit beyond signal going from not occupied to occupied. We don't have details of track circuits at this site but the track circuit that would be used to detect the SPAD may be the same one that was still occupied by the 810. [..]

Seems to be a pile of missing technology and capability:

1. SPAD alerts - an uncommanded disappearance from one section and arrival in another (ie. not a signalled join of two trains)
2. Derailment alerts and collision notification - why does a car have (mandatory?) emergency service calling on collision but not a train? Why does a Garmin bike computer detect a sudden stop and text the missus with GPS position, a £300 device? Would have helped here, and the recent derailments, and other catastrophic accidents such as Carmont.
3. Battery-backup for GSM-R phones
4. Continuous sub-1 second commit to disk video cameras
5. In-cab video as seen on lorries (https://www.bbc.co.uk/news/uk-england-37823457 shows one example, of several, where it has been used for convictions) - we might know _why_ it happened sooner.

Only (1) on the list is at all railway specific. Everything else is proven outside of the railway. All augment and rather than change anything safety already in place.

I was also wondering about axle counters: I thought there was also a track circuit in place or some other system to replace the function of track circuit operating clips. Is that so?

Are detonators required if the line is known to have track circuits?

 

[edwin_m]

SPAD alerts - an uncommanded disappearance from one section and arrival in another (ie. not a signalled join of two trains)

This was included in Automatic Route Setting when I was involved with it way back in the early 90s. But as I noted in my previous post, in this case there may not be enough separate track circuits to identify the situation, at least until the rear of the train has passed the overlap (and it "disappears" from that track circuit) which is probably about 300m travel distance after the actual SPAD. Travel time from there to the collision would be just a handful of seconds, not enough for the signaller to react and send out an emergency stop in time to make much difference.

 

[Belperpete]

Seems to be a pile of missing technology and capability:

1. SPAD alerts - an uncommanded disappearance from one section and arrival in another (ie. not a signalled join of two trains)

That is not quite how SPAD alerts work. The general philosophy of SPAD alarms is to warn the signaller as soon as a SPAD occurs, so that he can take preventative action. Waiting until the back of a train left the previous track section could delay the alarm considerably, by which time it may be too late. In addition, a system that relied on a track section going clear could be inhibited by things like track section sequencing, that prevents a section falsely showing clear, e.g. due to leaf fall.

A SPAD alarm is generated when the section ahead of a signal goes occupied without the signal showing a proceed aspect. However, it may not be able to detect a SPAD if the forward section is already occupied by another train.

With relay technology, that most UK signalling still uses, the state of most automatic signals is controlled locally by trackside relays, and not reported back to the control centre. So there is no way to tell what aspect such signals are showing, and therefore of detecting a SPAD. It is only with the advent of computer-based signalling that all automatic signals are directly controlled from the interlocking.

I understand that some control centres do have systems that will report a section unexpectedly going clear or occupied. However, it is not as simple as may be expected, and there situations in which it won't alarm, and many sections where it has to be permanently disabled because it would generate too many false alarms.

2. Derailment alerts and collision notification - why does a car have (mandatory?) emergency service calling on collision but not a train? Why does a Garmin bike computer detect a sudden stop and text the missus with GPS position, a £300 device? Would have helped here, and the recent derailments, and other catastrophic accidents such as Carmont.

And how many false alarms would such a system generate?

 

[fishwomp]

And how many false alarms would such a system generate?

None when done correctly. We don't remove safety devices like the deadmans device, or AWS, just because they might trigger a false stop - we improve them until they're right.

The forces in a relevant train prang are quite distinct from normal riding conditions. Considerably more distinct than what my bike seems to handle well (rough / sudden stop) vs normal road or off-road cycling. I do get false alarms - but usually that's the bike toppling over at a cake stop. Where the garmin mis-recognizes it, I get 30 seconds to cancel before it sends an SMS: I'm glad that I have it, although to date I've not needed its help.

There's a scale of what you might consider: decelerating by more than X, if your nose cone has deformed, if you accelerate by more than Y etc. A smart group of people in a room could own it and get it right.

 

[Belperpete]

I think the aim of existing SPAD detection systems and the like has been to prevent accidents from happening in the first place. However, it probably is time to consider systems that would automatically report an accident, in order prevent a second consequential collision.

Such a system would really need to alert the relevant signaller directly, not some central location that has to scrabble around finding out where the train is and so which signaller to contact, with vital time being lost.

I have no doubt that a system could be devised to do it, but how much things like nose cone deflection and the other sensors you suggest would require to provide and maintain.

 

[MarkyT]

That is not quite how SPAD alerts work. The general philosophy of SPAD alarms is to warn the signaller as soon as a SPAD occurs, so that he can take preventative action. Waiting until the back of a train left the previous track section could delay the alarm considerably, by which time it may be too late. In addition, a system that relied on a track section going clear could be inhibited by things like track section sequencing, that prevents a section falsely showing clear, e.g. due to leaf fall.

A SPAD alarm is generated when the section ahead of a signal goes occupied without the signal showing a proceed aspect. However, it may not be able to detect a SPAD if the forward section is already occupied by another train.

At Bedford, HW154 is plated as automatic in the HST cab view video, and has no obvious track circuit cabling or termination boxes visible. Combined berth and overlap is a reasonable assumption. The combined berth and overlap ahead to WH152 is ~1300m, outside the usual limits for a single end fed TI21, but a centre fed config with receivers at either end would likely work, though it'd be sumated as one logical track circuit in the interlocking/SB. Note I've assumed TI. I don't know what specific TC types are used around here.

With relay technology, that most UK signalling still uses, the state of most automatic signals is controlled locally by trackside relays, and not reported back to the control centre. So there is no way to tell what aspect such signals are showing, and therefore of detecting a SPAD. It is only with the advent of computer-based signalling that all automatic signals are directly controlled from the interlocking.

I understand that some control centres do have systems that will report a section unexpectedly going clear or occupied. However, it is not as simple as may be expected, and there situations in which it won't alarm, and many sections where it has to be permanently disabled because it would generate too many false alarms.


And how many false alarms would such a system generate?

At WH154, it would be possible to add a separate overlap track circuit or a inductive wheel sensor at the signal that could detect a second entry to the block and generate an alarm. As 'just another auto signal' that could be a precedent to apply such measures at all 10,000+ plain line signals throughout the UK, which would likely be as expensive as equipping them all with TPWS.

Perhaps not all, but a replacement joint at the signal, emergency replacement switch on panel/vdu, SPAD detection and TPWS might be a reasonable package of measure at the first plain line signal after leaving a major junction or station, where runaways, ding ding & away incidents and other misunderstandings are arguably more likely.

 

[HSTEd]

The GSM-R system supports a very large number of endpoints and even supports SMS messaging. After all it is fundamentally a GSM phone.

Given there are only ~15,000 passenger rail vehicles on the network, we could probably put a battery backed GSM-R radio in every vehicle that could send a message if certain requirements are met. For example the vehicle believes it is no longer on the rails. If handsets were available in every vehicle it would ensure any surviving train crew could get in touch with control and emergency services rapidly as it is highly unlikely they would all be disabled.

We could then build a system that would detect messages from a formation, then query other vehicles in the same unit for a status update and alarm if it is unable to obtain them.

 

[Stossgebet]

If talking of new tech to prevent collisions like Bedford. It already exists. It is ETCS. It is in use in many countries, and would have prevented the Bedford incident. The answer isn't to invent something new and a whole new raft of testing and procedures. The answer is to speed up the introduction of the answer that already exists. Or just extend the existing TPWS system to cover every signal on a mainline.
But i think doing anything other than speeding up ETCS is akin to the whole 'cup and cone' scenario with Mk1's.

 

[Belperpete]

Given there are only ~15,000 passenger rail vehicles on the network, we could probably put a battery backed GSM-R radio in every vehicle that could send a message if certain requirements are met.

Send a message to who? And saying what? How does a GSM-R unit in the last vehicle even know what service it is on?

For example the vehicle believes it is no longer on the rails.

If drivers don't even know that their train has derailed, how do you expect a standalone telephone to know the difference between a rough coupling-up and a derailment?

If handsets were available in every vehicle it would ensure any surviving train crew could get in touch with control and emergency services rapidly as it is highly unlikely they would all be disabled.

These days, when almost every passenger carries a mobile phone, is that really necessary?

We could then build a system that would detect messages from a formation, then query other vehicles in the same unit for a status update and alarm if it is unable to obtain them.

Only if that system reliably knows exactly what vehicles are in any given formation, taking account of trains joining and dividing, last minute set swaps, etc. It would certainly have to be a lot better than the current system that feeds passenger information systems.

 

[Nicholas Lewis]

At WH154, it would be possible to add a separate overlap track circuit or a inductive wheel sensor at the signal that could detect a second entry to the block and generate an alarm. As 'just another auto signal' that could be a precedent to apply such measures at all 10,000+ plain line signals throughout the UK, which would likely be as expensive as equipping them all with TPWS.

Surely you would favour TPWS Train Stop over doing this even if its ability to fully avoid a collision at least it would significantly reduce the energy involved in a collision. I would favour a simpler installation on auto sections where retrofitted so it can be added with the same ease that AWS was without having to provide all the TPWS failure functionality.

Clearly long term we should be using ETCS but that is a decades long project so we need a quicker economical fix.

 

[35B]

Surely you would favour TPWS Train Stop over doing this even if its ability to fully avoid a collision at least it would significantly reduce the energy involved in a collision. I would favour a simpler installation on auto sections where retrofitted so it can be added with the same ease that AWS was without having to provide all the TPWS failure functionality.

Clearly long term we should be using ETCS but that is a decades long project so we need a quicker economical fix.

Do we? This whole conversation is on the basis that "something bad has happened therefore something must be done". We don't know why the train passed the signal as it did, and nowhere is there any calculation of the costs and benefits of the change, or what other work it might distract.

In the meantime, the discussion ignores the minor reality that the passenger compartments remained intact, and that no passengers died as a result of this - the result of a lot of work over several decades to mitigate the consequences when something goes wrong.

 

[HSTEd]

Send a message to who? And saying what? How does a GSM-R unit in the last vehicle even know what service it is on?

It would send a message to a suitably designed control infrastructure, presumably saying things like "Vehicle is on its side" or "Vehicle experienced emergency brake application followed by vibration consistent with derailment"
It doesn't need to know what service it is on, the control infrastructure presumably knows what vehicles are in each unit, given that that doesn't change for years at a time.

If the other vehicles in the unit corroborate or are unreachable, then the control room can call the driver using the permanently associated driver's cab number for that unit or put out a group call. Indeed if persistent vibration is detected then the control room can just phone the driver and ask, using the permanently associated number for that unit.

Whilst GSM-R can be used to call based on service number, it can also call a hardware number.

If drivers don't even know that their train has derailed, how do you expect a standalone telephone to know the difference between a rough coupling-up and a derailment?

I don't think rough coupling typically results in persistent vibrations lasting multiple seconds whilst the train is moving at operationally relevant speeds.

These days, when almost every passenger carries a mobile phone, is that really necessary?

A passenger won't know the correct numbers to call after all.

 

[edwin_m]

Do we? This whole conversation is on the basis that "something bad has happened therefore something must be done". We don't know why the train passed the signal as it did, and nowhere is there any calculation of the costs and benefits of the change, or what other work it might distract.

In the meantime, the discussion ignores the minor reality that the passenger compartments remained intact, and that no passengers died as a result of this - the result of a lot of work over several decades to mitigate the consequences when something goes wrong.

I think @MarkyT and @Nicholas Lewis are suggesting what would be better to do if "something must be done", but there is a big question over what the proportionate response is here. Elstow would almost certainly have been prevented by some system that applied the brakes on passing the signal, but is the only such fatality we have had in the 20+ years since TPWS was fitted. Also almost certainly, the crashworthiness of these trains has reduced the casualties compared to older designs, again the first time this technology has made any difference, and possibly at the cost of writing both units off.

These statistics aren't going to go anywhere near justifying a widespread fitment of TPWS or any other infrastructure-based solution that only addresses SPAD-related accidents. To my mind a simple train-based system such as an accelerometer may be justifiable, firstly because it ought to be cheaper but also because it also reduces the consequential risk of other types of accident such as the Lewes and maybe the Wickford derailments by allowing any approaching trains on other tracks to be stopped more quickly.

 

[Belperpete]

If talking of new tech to prevent collisions like Bedford. It already exists.

I think what is being proposed is to prevent what could have happened at Bedford, and has happened in a number of other accidents - another train on a parallel track running into debris of a first accident.

Just ensuring that both driver and guard have access to a working mobile GSM-R unit would be a good starting point, before trying to develop something more complicated.

 

[35B]

I think what is being proposed is to prevent what could have happened at Bedford, and has happened in a number of other accidents - another train on a parallel track running into debris of a first accident.

Just ensuring that both driver and guard have access to a working mobile GSM-R unit would be a good starting point, before trying to develop something more complicated.

Quite. And possibly looking at the collision performance of the Hitachi 8xx units, Hitachi looking further at the issues first highlighted in Leeds 6 years ago

 

[Belperpete]

It would send a message to a suitably designed control infrastructure, presumably saying things like "Vehicle is on its side" or "Vehicle experienced emergency brake application followed by vibration consistent with derailment"
It doesn't need to know what service it is on, the control infrastructure presumably knows what vehicles are in each unit, given that that doesn't change for years at a time.

The unit on the train might not need to know what service it is on, but anybody who needs to make use of the information needs to know what service is in trouble and whereabouts it is.

If the other vehicles in the unit corroborate or are unreachable, then the control room can call the driver using the permanently associated driver's cab number for that unit or put out a group call. Indeed if persistent vibration is detected then the control room can just phone the driver and ask, using the permanently associated number for that unit.

And when the driver doesn't respond, because he is busy driving?

I don't think rough coupling typically results in persistent vibrations lasting multiple seconds whilst the train is moving at operationally relevant speeds.

It can if repeated attempts at coupling up are made.

And persistent vibrations are a feature of some trains, e.g. 197s running over jointed track.

I still maintain that the simple solution of just ensuring that both driver and guard have access to a working GSM-R unit would be adequate.

 

[Falcon1200]

why does a car have (mandatory?) emergency service calling on collision but not a train?

Simple answer; Cars are involved in collisions far more frequently - ie every single day - Than trains; When was the last passenger train collision before Elstow? And how would any such system distinguish between a collision and units being coupled?

 

[fishwomp]

Simple answer; Cars are involved in collisions far more frequently - ie every single day - Than trains;

A car driver can easily do 250,000 miles and never have a collision. It's not a daily occurence for every driver

When was the last passenger train collision before Elstow?

Specifically a collision between two trains: Talerddig, Oct 2024 ; low speed at Aviemore (2023) ; Salisbury (2021)

A collision with a large inanimate object: several times a year, sometimes buffer stops, often farm vehicles.

A derailment - twice this summer at speed.

A drop over a viaduct (2020)

And how would any such system distinguish between a collision and units being coupled?

Quite easily - that's quite gentle. Or it bleedin' should be!! An actual collision is going to be more G-force than a coupling up for long duration than a coupling-up too. In an accident, people get hurt, and luggage shifts - that doesn't happen in coupling up!

A derailment is going to be bouncy for a longer period of time - possibly recorded on a different device though nearer the bogies.

I'd leave it to a bunch of smart people in a room to do the engineering - I'm just confident a solution exists.

 

[MarkyT]

AWS and TPWS might be enhanced to incorporate additional safeguards that some other legacy limited supervision systems in Europe have:

1. Mandatory speed reduction to under a target speed after passing cautionary AWS, applicable for a measured distance or period of time, like the 1000Hz inductor in German Indusi (or PZB). No subsequent acceleration above the target within this distance or time.

2. No acceleration after successfully passing a TPWS OSS speed trap (where provided) on final approach to a red signal, like the Indusi 500Hz magnet. Again, no subsequent acceleration within a measured distance or time.

3. TPWS TSS train stops (where provided) would continue to work as now, like the Indusi 2000Hz inductor, to enforce an immediate emergency stop.

In this scheme, at a signal without TPWS, a cautionary AWS alert, once acknowledged, would still enforce an immediate significant slow-down, taking much energy out of a collision like Bedford after a SPAD, giving a driver more time to notice the obstruction and, with luck, maybe even stop before contact.

Arguments against this have often centred around the scenario where an AWS magnet has been passed at caution, successfully acknowledged, then the driver sees the signal clear up to green before it is passed, so a train with mandatory cautionary deceleration couldn't take best advantage of the better aspect seen. Indusi sidesteps this problem by having the 500Hz inductor at the signal rather than on its approach.

In the UK, enforcing such cautionary speed restrictions for signals on very densely trafficked lines where trains routinely follow each other closely on double yellows at near line speed, would be detrimental to speed and capacity. It's unfortunate SRAWS (Southern Region or Signal Repeating Advance Warning System) development was abandoned in the 1970s.

 

[edwin_m]

A car driver can easily do 250,000 miles and never have a collision. It's not a daily occurence for every driver

But the risk of being killed when travelling by car is at least five times that of doing the same distance by train.

Specifically a collision between two trains: Talerddig, Oct 2024 ; low speed at Aviemore (2023) ; Salisbury (2021)

A collision with a large inanimate object: several times a year, sometimes buffer stops, often farm vehicles.

A derailment - twice this summer at speed.

A drop over a viaduct (2020)

Of these only Talerddig involved a fatality, compared with around 1600 road deaths every year in the UK. That doesn't justify a major investment in rail safety when spending the same amount on road safety would most likely save many more lives.

 

[fishwomp]

Of these only Talerddig involved a fatality, compared with around 1600 road deaths every year in the UK. That doesn't justify a major investment in rail safety when spending the same amount on road safety would most likely save many more lives.

It's not a rational world - risks/rewards are not logically applied even within the railway, let alone across transport as a whole. A change to status quo is seen as new risk to mitigate, even if spending on some particular crossing removal would be better spent on a more dangerous crossing where there is no change.

By the argument you're proposing, we'd never have bothered with TPWS. We might even ignore crash-worthiness given that, really, overwhelmingly, trains don't crash.

Almost every item on my list is pretty simple - compared to the average rail project. I'm sure it's still possible to make it expensive..

 

[HSTEd]

AWS and TPWS might be enhanced to incorporate additional safeguards that some other legacy limited supervision systems in Europe have:

1. Mandatory speed reduction to under a target speed after passing cautionary AWS, applicable for a measured distance or period of time, like the 1000Hz inductor in German Indusi (or PZB). No subsequent acceleration above the target within this distance or time.

2. No acceleration after successfully passing a TPWS OSS speed trap (where provided) on final approach to a red signal, like the Indusi 500Hz magnet. Again, no subsequent acceleration within a measured distance or time.

3. TPWS TSS train stops (where provided) would continue to work as now, like the Indusi 2000Hz inductor, to enforce an immediate emergency stop.

In this scheme, at a signal without TPWS, a cautionary AWS alert, once acknowledged, would still enforce an immediate significant slow-down, taking much energy out of a collision like Bedford after a SPAD, giving a driver more time to notice the obstruction and, with luck, maybe even stop before contact.

Arguments against this have often centred around the scenario where an AWS magnet has been passed at caution, successfully acknowledged, then the driver sees the signal clear up to green before it is passed, so a train with mandatory cautionary deceleration couldn't take best advantage of the better aspect seen. Indusi sidesteps this problem by having the 500Hz inductor at the signal rather than on its approach.

In the UK, enforcing such cautionary speed restrictions for signals on very densely trafficked lines where trains routinely follow each other closely on double yellows at near line speed, would be detrimental to speed and capacity. It's unfortunate SRAWS (Southern Region or Signal Repeating Advance Warning System) development was abandoned in the 1970s.

Whilst you could approximate some of this with TPWS equipment. I think you are essentially going to end up with an ETCS Level 1 implementation to effectively implement that.

And that gets us back to the familiar, well trodden ground.

 

[edwin_m]

By the argument you're proposing, we'd never have bothered with TPWS.

I was the humble minute-taker on the committee that developed the idea of what became TPWS and also involved in some of the analysis to evaluate whether it was worthwhile. That most certainly was based on value of preventing a fatality, although somewhat undermined later when some bells and whistles were added. However, the benefits came out very much as predicted and that's one reason it's difficult to justify spending more today to address essentially the same problem.

 

[HSTEd]

We have come very close to some hairy incidents though, avoided often through luck.

The overspeed incidents near Grantham and Peterborough in particular could have turned very nasty, if the trains had been going not that much faster.

I think high performance multiple units have created a whole range of new risks that were never a serious problem before.

Plus incidents like the lever that was left in the wrong position on the Caledonian sleeper, disabling the train brake, that could have caused a major collision in the middle of Edinburgh Waverley in rush hour.

I do wonder if luck has saved us from some very real risks.

 

[MarkyT]

Whilst you could approximate some of this with TPWS equipment. I think you are essentially going to end up with an ETCS Level 1 implementation to effectively implement that.

And that gets us back to the familiar, well trodden ground.

You might design the enhanced system using existing track transponders, but specify the new onboard module for older trains to support a future balise reader for similar limited functionality, like Eurosignum. Modern trains with active onboard ETCS computers and screens could activate this mode by emulation, using interfaced receiver modules as necessary, and it could be a stepping stone to L1 LS/FS or higher levels.