TPWS Speeding on greens?

[60074]

With a tpws OSS system, would it trigger for speeding if the associated signals were green?

For example you did 70 in a 60, running on greens?

I’m aware it would trigger for a red and potentially any restrictive signals (depending on location)

 

[CC 72100]

Short answer: no.

Long answer: TPWS is fitted to some speed reductions (not all). So a bog standard line at 60mph wouldn't have any grids unless there was a speed reduction that met the required standard to be fitted with TPWS PSR OSS protection.

 

[PupCuff]

On the whole, no.

Though there are cases for instance approaching buffers in a terminal platform where TPWS is used to protect against overspeed in this way.

Additionally, there are some locations where a permanently energised TPWS OSS (eg approaching a PSR) trigger speed is greater than the linespeed owing to it being provided for the benefit of freight trains, rather than passenger, which would have the unintended benefit of tripping speeding passenger trains. Very uncommon to see that happen though.

 

[60074]

Short answer: no.

Long answer: TPWS is fitted to some speed reductions (not all). So a bog standard line at 60mph wouldn't have any grids unless there was a speed reduction that met the required standard to be fitted with TPWS PSR OSS protection.

Thanks, so take this example

You’re speeding at 70mph on a 60mph line. You pass over OSS grids that are for a “approach release” signal into a diverging yard set at say 15mph. The signal is green as you’re going straight on. Would it trigger?

Just wondering if they have an “always on” status

== Doublepost prevention - post automatically merged: 19 Sep 2022 ==

On the whole, no.

Though there are cases for instance approaching buffers in a terminal platform where TPWS is used to protect against overspeed in this way.

Additionally, there are some locations where a permanently energised TPWS OSS (eg approaching a PSR) trigger speed is greater than the linespeed owing to it being provided for the benefit of freight trains, rather than passenger, which would have the unintended benefit of tripping speeding passenger trains. Very uncommon to see that happen though.

Surely a freight speed would be lower than a passenger speed?

 

[CC 72100]

Thanks, so take this example

You’re speeding at 70mph on a 60mph line. You pass over OSS grids that are for a “approach release” signal into a diverging yard set at say 15mph. The signal is green as you’re going straight on. Would it trigger?

Just wondering if they have an “always on” status

No, as the grids would be linked to the signal showing a proceed aspect (or a danger aspect).

The minute it is showing a proceed aspect, they should be de-energised, as they are provided here not as a protection against speeding, but as a mitigation measure to stop the train before it reaches the conflict point if it SPADs the signal (train stop grids at signal) or if it is going at a higher speed than the trigger speed (over speed grids on approach to the signal).

A green would de-energise all grids related to the signal.

The only 'always-on' grids would be those related to permissible speed reductions (ie. A linespeed that drops from 75 to 40) or buffer stop grids, as mentioned above.

 

[PupCuff]

Surely a freight speed would be lower than a passenger speed?

Yes - but for any freight speed, the corresponding passenger speed at that grid will be higher.

Looking at how the TPWS system works, the train first passes over an arming loop (first grid) which starts a timer on the train. The train then passes over a trigger loop (second grid). If the train has passed over the trigger loop whilst the timer is still running, you can establish [speed = distance/time] that the train is travelling in excess of the trigger speed.

Freight trains, as you rightly say, need to be controlled to a slower speed than passenger trains owing to their braking abilities. To do this, you increase the time that the TPWS timer runs. Therefore, this has the effect of lowering the trigger speed for freight trains.

However, if you have set a TPWS OSS to control the speed of a freight train approaching a PSR, then the corresponding trigger speed for a passenger train will then be higher - and it could be high enough that it takes the OSS trigger speed for passenger trains over the linespeed.

 

[60074]

Yes - but for any freight speed, the corresponding passenger speed at that grid will be higher.

Looking at how the TPWS system works, the train first passes over an arming loop (first grid) which starts a timer on the train. The train then passes over a trigger loop (second grid). If the train has passed over the trigger loop whilst the timer is still running, you can establish [speed = distance/time] that the train is travelling in excess of the trigger speed.

Freight trains, as you rightly say, need to be controlled to a slower speed than passenger trains owing to their braking abilities. To do this, you increase the time that the TPWS timer runs. Therefore, this has the effect of lowering the trigger speed for freight trains.

However, if you have set a TPWS OSS to control the speed of a freight train approaching a PSR, then the corresponding trigger speed for a passenger train will then be higher - and it could be high enough that it takes the OSS trigger speed for passenger trains over the linespeed.

So the tpws can’t differentiate passenger and freight? It’s literally just a basic timer

== Doublepost prevention - post automatically merged: 19 Sep 2022 ==

No, as the grids would be linked to the signal showing a proceed aspect (or a danger aspect).

The minute it is showing a proceed aspect, they should be de-energised, as they are provided here not as a protection against speeding, but as a mitigation measure to stop the train before it reaches the conflict point if it SPADs the signal (train stop grids at signal) or if it is going at a higher speed than the trigger speed (over speed grids on approach to the signal).

A green would de-energise all grids related to the signal.

The only 'always-on' grids would be those related to permissible speed reductions (ie. A linespeed that drops from 75 to 40) or buffer stop grids, as mentioned above.

So the grids don’t have multiple timers? I wondered if there’d be a primary timer for a restriction and a secondary timer for the linespeed in general (e.g for speeding on greens)

 

[PupCuff]

So the tpws can’t differentiate passenger and freight? It’s literally just a basic timer

== Doublepost prevention - post automatically merged: 19 Sep 2022 ==


So the grids don’t have multiple timers? I wondered if there’d be a primary timer for a restriction and a secondary timer for the linespeed in general (e.g for speeding on greens)

The hard work is all done on the train, so the on-train system will be configured as to whether it is freight or passenger.

The on-track infrastructure isn't that complex to be able to do things like that.

 

[Adoarable]

So the tpws can’t differentiate passenger and freight? It’s literally just a basic timer

== Doublepost prevention - post automatically merged: 19 Sep 2022 ==


So the grids don’t have multiple timers? I wondered if there’d be a primary timer for a restriction and a secondary timer for the linespeed in general (e.g for speeding on greens)

This wouldn’t work for two reasons:

1. How does the system on the train know which timer to activate? The TPWS grid is either on or off. If it’s on then the train is stopping at any speed above the set speed. If it’s not then it’s not.

2. If that were overcome, then there would have to be a network-wide fixed ratio between the primary timer and the secondary timer (because the grids don’t transmit any information at all - the system on the train can only observe the time taken to travel between the grids). This ratio would have to be very high to prevent erroneous brake applications when travelling close to line speed. Imagine for example a TPWS installation set at 15mph where the line speed is 125mph. To prevent trains travelling at 124.9mph from encountering emergency brake applications, the fixed ratio would have to be at least 8.33. But this would be useless in almost any other situation - for example if the TPWS set speed is 40mph on a 60mph line, the secondary timer would not activate unless the train were travelling above 333mph!

Adding this functionality to existing TPWS installations would involve not only working out how to overcome these two problems but also modifying every TPWS OSS in the network AND every on-train TPWS module on the network. And even then it would not be very effective because the positioning of TPWS OSS grids are designed based on their existing use, and not in positions that present the most benefit in terms of stopping trains that are already speeding when they reach the TPWS grid.

It would be far easier and more effective to instead install additional TPWS grids with a set speed just above line speed. Given this hasn’t been done I’m assuming the benefit-cost ratio is too low - the costs are high because each grid only works in a single place so you need a lot of them for effective coverage, and the benefits are low because speeding is not prevalent because it’s already controlled by cheaper methods like regular downloads of train data.

 

[CC 72100]

The hard work is all done on the train, so the on-train system will be configured as to whether it is freight or passenger.

The on-track infrastructure isn't that complex to be able to do things like that.

To add to this, the other thing to consider is to remember what TPWS is trying to achieve; there are plenty of stop signals which are not fitted with TPWS, where there would be a far greater risk of harm if something went wrong than the damage caused by doing 70 in a 60*.

*Not that I am advocating this or saying this is ok, obviously!