Incident at Chalfont & Latimer (21/06/20)

[Nicholas43]

A train doesn't bounce over incorrectly set trailing points, it forces it's way THROUGH them.

Thanks. I had wrongly guessed that the locking would prevent that, and thus (possibly) derail the train.

 

[EnriqueEspaña]

To understand what happened you need to understand the difference between trailing and facing points. The first set of points the Chiltern train encountered were trailing and set against the Chiltern train so it ran through them. A train doesn't bounce over incorrectly set trailing points, it forces it's way THROUGH them. The second set were facing to it, which is why it crossed to the opposite line directly facing the underground train that had the road.

Thankfully it had slowed sufficiently to take that last set of points, otherwise we might have had a scenario where the 165 ended up on the platform.

 

[matt_world2004]

Thankfully it had slowed sufficiently to take that last set of points, otherwise we might have had a scenario where the 165 ended up on the platform.

I think the s stock is lighter and has crumple zones designed for lower speed collisions that would had the most damage done to it

 

[Tetchytyke]

I don't think that's relevant here as it is LU infrastructure and all trains use the mechanical trainstop system. The cl.165s that work the service are specially fitted with trip cocks for this.

Ah yes, wasn't sure if ATP was on the shared bits though. Not great timing though.

Why wouldn't a tripcock have stopped this? I've never quite understood tripcocks.

Apologies if this sounds like speculation, it's not meant to be.

As far as I can tell, the Chiltern was on the up line and the Met was a down Chesham. If the points were set for the Met to go first, the Chiltern train will have gone through the trailing points for the Chesham branch (easy enough, they just push through) then through the facing crossover to end up on the down line.

 

[Dstock7080]

I thought they covered lines shared with Chiltern with a red , green and white signalling system with white being proceed in ATO mode only

This section has 4-aspect signalling, and the additional CBTC aspect will be blue.

 

[Domh245]

Why wouldn't a tripcock have stopped this? I've never quite understood tripcocks.

Based on what's been written already, the tripcock did stop the train, initially. It was the actions following being tripped that led to the incident. It'd be equivalent to being stopped by TPWS/ATP, resetting and then just carrying on - there's no active control of the train by the safety systems after an intervention, on this stock at least apparently.

 

[EnriqueEspaña]

I think the s stock is lighter and has crumple zones designed for lower speed collisions that would had the most damage done to it

I was more referring to the fact that if it had taken the crossover from southbound to northbound at linespeed i would have imagined the train turning horizontal to the platforms, crashing into both the s8 and ending up on the platform due to the force of the impact. Could have been very messy.

 

[SlimJim1694]

Having read up on this thread I was compelled to check RTT to see the timings of the incident train. Now I know RTT cannot be relied upon for hard facts, but as a general guide this is quite interesting... the train left Amersham 1 minute late but apparently arrived at Chalfont right time. If the driver had a SPAD, was 'tripped', came up in a heap, reset then carried on he would have had to have been pretty quick about it to shave a whole minute off a 3 minute journey! It's all rumour and speculation that the driver reset and continued, but these timings make me wonder if he was actually stopped at all. Could the tripcock on the Chiltern unit have been defective or isolated? Could it have been a wrong side failure that caused him to have clear aspects and thus not be 'tripped'? Perhaps the arrival time on RTT at chalfont is measured from when the train entered the track circuit, which may well have been right time if he's gone through that signal at full speed? It's all food for thought but maybe, just maybe, this Chiltern driver might not be the villain that the current picture paints.

Realtime Trains - 2C72 2113 Aylesbury Vale Parkway to Chalfont and Latimer

Realtime Trains provides live realtime running information for the Great British railway network using open data.

www.realtimetrains.co.uk

 

[jumble]

Based on what's been written already, the tripcock did stop the train, initially. It was the actions following being tripped that led to the incident. It'd be equivalent to being stopped by TPWS/ATP, resetting and then just carrying on - there's no active control of the train by the safety systems after an intervention, on this stock at least apparently.

I had understood that historically when a tripcock was tripped it let all the air out of the system and it took a good few minutes for the train compressors to pump back up
This meant that the driver had to contact control to explain.
Is it really the case that a driver can now reset it and carry on and no one will be aware?
If this is the case of then are we not going backwards in safety ?

 

[si404]

shave a whole minute off a 3 minute journey!

That's not what RTT says.

Meant to leave Amersham at 2139 and arrive Chalfont at 2142½ (3½ minutes) actually left Amersham at 2140 and arrived at Chalfont at 2143 (3 minutes journey).

Half a minute off a 3½ minute journey is quite a bit different to a minute off a three minute journey! 86% of the time timetabled, rather than 67%.

 

[Domh245]

I had understood that historically when a tripcock was tripped it let all the air out of the system and it took a good few minutes for the train compressors to pump back up
This meant that the driver had to contact control to explain.
Is it really the case that a driver can now reset it and carry on and no one will be aware?
If this is the case of then are we not going backwards in safety ?

I don't believe they completely dump the entirety of the reservoirs - on older stock they'd dump the brake pipe, but with 'newer' stock (since 1973) with electronic brake control, there's no brake pipe from which to dump the air from, whilst dumping air from the reservoirs would reduce braking capability!

With London Underground at least, there's a very specific process to be followed 'post trip' as detailed on this page (with caveat that the info on that page may be outdated) which involves contacting control and an automatic speed limiter. Needless to say that if what's been hinted at upthread is true, expect the RAIB report to focus a lot on procedures and controls around what happens 'post trip'

 

[jumble]

I don't believe they completely dump the entirety of the reservoirs - on older stock they'd dump the brake pipe, but with 'newer' stock (since 1973) with electronic brake control, there's no brake pipe from which to dump the air from, whilst dumping air from the reservoirs would reduce braking capability!

With London Underground at least, there's a very specific process to be followed 'post trip' as detailed on this page (with caveat that the info on that page may be outdated) which involves contacting control and an automatic speed limiter. Needless to say that if what's been hinted at upthread is true, expect the RAIB report to focus a lot on procedures and controls around what happens 'post trip'

Thanks
We are agreed that on LUL mandate the driver contacts control in the case of a SPAD
I will not speculate about if this is the case with Chiltern
The only comment I will make is that the safety systems did their job. The trains nearly collided but ......

 

[Mojo]

Having read up on this thread I was compelled to check RTT to see the timings of the incident train. Now I know RTT cannot be relied upon for hard facts, but as a general guide this is quite interesting... the train left Amersham 1 minute late but apparently arrived at Chalfont right time. If the driver had a SPAD, was 'tripped', came up in a heap, reset then carried on he would have had to have been pretty quick about it to shave a whole minute off a 3 minute journey! It's all rumour and speculation that the driver reset and continued, but these timings make me wonder if he was actually stopped at all. Could the tripcock on the Chiltern unit have been defective or isolated? Could it have been a wrong side failure that caused him to have clear aspects and thus not be 'tripped'? Perhaps the arrival time on RTT at chalfont is measured from when the train entered the track circuit, which may well have been right time if he's gone through that signal at full speed? It's all food for thought but maybe, just maybe, this Chiltern driver might not be the villain that the current picture paints.

Realtime Trains - 2C72 2113 Aylesbury Vale Parkway to Chalfont and Latimer

Realtime Trains provides live realtime running information for the Great British railway network using open data.

www.realtimetrains.co.uk

The train didn’t actually arrive at Chalfont, as shown by the photo above, it stopped before getting to the station; the platform was occupied by a Met train.

 

[matt_world2004]

Who would pay for the damage to the track if it is a SPAD . Would London underground or Chiltern railways

 

[Metroman62]

That's not what RTT says.

Meant to leave Amersham at 2139 and arrive Chalfont at 2142½ (3½ minutes) actually left Amersham at 2140 and arrived at Chalfont at 2143 (3 minutes journey).

Half a minute off a 3½ minute journey is quite a bit different to a minute off a three minute journey! 86% of the time timetabled, rather than 67%.

Does Real Time Trains work on London Underground tracks? There seems to be a bit of a black hole between Harrow and Amersham at times, I had assumed because it was London Underground track. I thought time table times were shown.

 

[Mojo]

Does Real Time Trains work on London Underground tracks? There seems to be a bit of a black hole between Harrow and Amersham at times, I had assumed because it was London Underground track. I thought time table times were shown.

Realtime information for this section of the railway was added to Realtime Trains a few years ago, initially data was obtained through the Trackernet feeds, however the Realtime Trains blog from January this year states that Chiltern Railways have recently introduced GPS based reporting onto their fleet.

 

[greatkingrat]

I don't think you can read too much into the RTT times here. Presumably as soon as the train passed the signal, it occupied the platform berth and RTT picked up the arrival time. If the train then stops for whatever reason before actually reaching the platform, RTT isn't going to know that.

 

[si404]

Does Real Time Trains work on London Underground tracks? There seems to be a bit of a black hole between Harrow and Amersham at times, I had assumed because it was London Underground track. I thought time table times were shown.

The post I quoted had a link in it to RTT with train times shown.

I can't speak to the accuracy of RTT here, my post was about accurate reporting of that source rather than the source's accuracy.

I don't think you can read too much into the RTT times here.

very true, but if you are going to try, then at least read it properly!

 

[SlimJim1694]

That's not what RTT says.

Meant to leave Amersham at 2139 and arrive Chalfont at 2142½ (3½ minutes) actually left Amersham at 2140 and arrived at Chalfont at 2143 (3 minutes journey).

Half a minute off a 3½ minute journey is quite a bit different to a minute off a three minute journey! 86% of the time timetabled, rather than 67%.

You are, of course, correct. I was concentrating on the fact that its very unlikely a train could come to a complete stand from an emergency brake application at line speed, have that reset, and then still make it to the next station without losing any time on its journey (and yes, I know it didnt get into the platform at Chalfont!).

The train didn’t actually arrive at Chalfont, as shown by the photo above, it stopped before getting to the station; the platform was occupied by a Met train.

I know!

I don't think you can read too much into the RTT times here. Presumably as soon as the train passed the signal, it occupied the platform berth and RTT picked up the arrival time. If the train then stops for whatever reason before actually reaching the platform, RTT isn't going to know that.

I know you can't read too much into RTT, I said as much in my post! I also covered the scenario that it may have shown as arrived as soon as it entered the next track circuit.

I was just suggesting possible alternative scenarios to it being a SPAD, reset and continue because as far as I know it has not been confirmed as that (yet).

 

[si404]

I was concentrating on the fact that its very unlikely a train could come to a complete stand from an emergency brake application at line speed, have that reset, and then still make it to the next station without losing any time on its journey (and yes, I know it didnt get into the platform at Chalfont!)

Fair enough.

 

[357]

The arrival time on RTT was fed by GPS data - not by track circuits. On desktop, if you hover over the time it shows you where the data came from.

 

[Banana]

I know it's not necessarily relevant here, but why is a branch line move being signalled in front on the up main line. Overall delay of stopping the Chiltern train as opposed to waiting for it to pass before signalling the Chesham train must be material.

Given the Chiltern train was running on-time (moreorless according to the RTT data), I wonder exactly how this move is timetabled? Was the Chesham service running late? Was the move signalled early?

 

[Banana]

To answer my question, the Chesham service is timetabled to depart C&L at 21:36.5, well in front of the Chiltern service which passes 6 minutes later.

Why the Chiltern is being delayed for the last service of the day to a single station is beyond me. Anyway, another matter I suppose.

 

[Mojo]

To answer my question, the Chesham service is timetabled to depart C&L at 21:36.5, well in front of the Chiltern service which passes 6 minutes later.

Why the Chiltern is being delayed for the last service of the day to a single station is beyond me. Anyway, another matter I suppose.

That is the Monday to Fridays timetable.

On Sundays, the train to Chesham is due to leave at 21.36, whereas the Chiltern service is due to depart from Chalfont at 21.43.

It’s simply keeping the trains in order, especially given that either way one of the trains would have had to wait. And it certainly isn’t the last train of the day!

 

[edwin_m]

Something like an S stock I suspect wouldn’t fare too badly against a 165, being of a not dissimilar construction and essentially the same size.

The Bakerloo north of Queen’s Park is perhaps more of an issue. A 378 versus a 72 Tube stock certainly wouldn’t be a fair contest even at comparatively low speed. Indeed a 59 stock car was virtually demolished when it was rear-ended by a 313 near Kensal Green in the 1980s.

I think the s stock is lighter and has crumple zones designed for lower speed collisions that would had the most damage done to it

165s pre-date the current rules for "crumple zones" and I don't know what is provided on S Stock - possibly not much as LU normally provides full braking distance overlaps so collisions directly following SPADs are theoretically impossible (not counting reset-and-continue, and noting that practice may differ from theory!). A sidelong collision on the branch crossover could have been nasty too, as side protection is less than that at the ends.

To understand what happened you need to understand the difference between trailing and facing points. The first set of points the Chiltern train encountered were trailing and set against the Chiltern train so it ran through them. A train doesn't bounce over incorrectly set trailing points, it forces it's way THROUGH them. The second set were facing to it, which is why it crossed to the opposite line directly facing the underground train that had the road.

For completeness, some kinds of points do have a risk of derailment if trailed through, though unlikely to be the case with the ones here.

 

[Banana]

That is the Monday to Fridays timetable.

On Sundays, the train to Chesham is due to leave at 21.36, whereas the Chiltern service is due to depart from Chalfont at 21.43.

It’s simply keeping the trains in order, especially given that either way one of the trains would have had to wait. And it certainly isn’t the last train of the day!

Thank you. I missed that it was Sunday.

However I'm not sure what the benefit is of "keeping the trains in order" in this instance. Wouldn't it be better to keep the one waiting that is already stationary rather than stop one already in motion? The alternative would be an arrival at Chesham c.8 mins late at 22.52.5 which would still leave enough time to make an on-time departure of the 21.57 return service.

 

[MarkyT]

The arrival time on RTT was fed by GPS data - not by track circuits. On desktop, if you hover over the time it shows you where the data came from.

Didn't know that. Thanks for the tip. Perhaps such a GPS location was close enough to resolve as being at or approaching the train's booked platform, even though it never actually arrived and was on the wrong track.

 

[MarkyT]

A sidelong collision on the branch crossover could have been nasty too, as side protection is less than that at the ends.

Indeed. I shudder at the term 'sideswipe' when used erroneously for rail collisions, implying unguided vehicles 'bouncing off' each other in a misjudged merge scenario. Rail bound vehicles will keep rolling into each other by contrast and in this case would have still been going in opposite directions so would have as much energy to dissipate into their deforming bodyshells as in a head-on, but plausibly with one nose entering the passenger cabin of the other and peeling off a side. Potentially Horrific. So lets just not use that dismissive 'sideswipe' term please everyone!

For completeness, some kinds of points do have a risk of derailment if trailed through, though unlikely to be the case with the ones here.

I recall they had to re-engineer the HPSS (high-performance switch system) design to mitigate that risk, inserting an extra frangible component into the drive.

 

[Tom]

Having read up on this thread I was compelled to check RTT to see the timings of the incident train. Now I know RTT cannot be relied upon for hard facts, but as a general guide this is quite interesting... the train left Amersham 1 minute late but apparently arrived at Chalfont right time. If the driver had a SPAD, was 'tripped', came up in a heap, reset then carried on he would have had to have been pretty quick about it to shave a whole minute off a 3 minute journey! It's all rumour and speculation that the driver reset and continued, but these timings make me wonder if he was actually stopped at all. Could the tripcock on the Chiltern unit have been defective or isolated? Could it have been a wrong side failure that caused him to have clear aspects and thus not be 'tripped'? Perhaps the arrival time on RTT at chalfont is measured from when the train entered the track circuit, which may well have been right time if he's gone through that signal at full speed? It's all food for thought but maybe, just maybe, this Chiltern driver might not be the villain that the current picture paints.

Realtime Trains - 2C72 2113 Aylesbury Vale Parkway to Chalfont and Latimer

Realtime Trains provides live realtime running information for the Great British railway network using open data.

www.realtimetrains.co.uk

Let me start with the simple things: the cancellation reason that shows on RTT is the first that goes into TRUST. If it is subsequently corrected then that does not carry through. This is an artefact of how the feeds 'take' data from TRUST.

The way the NR train describer works between Mantles Wood and Harrow-on-the-Hill South Jn, where Marylebone IECC fringes with the Metropolitan Line, is a series of several queue berths. These queue berths work on the basis that when the train steps into the Met Line at, say, Mantles Wood then it enters the queue and steps forward as far as possible. If it is the one and only train moving on the southbound Met, then it steps up to the berth just prior to the first step back in. It works likewise for the northbound. This makes the train describer 'blind' to what happens on the Metropolitan Line.

For Harrow-on-the-Hill northbound departures and Amersham southbound departures, there is a berth offset that is a positive number (it's normally negative) against the fringing NR signal into the Metropolitan Line. This means that you will always have a constant dwell time at those stations in those directions. It works similiarly with a negative arrival for Harrow-on-the-Hill southbound and Amersham northbound.

Once you are on the Metropolitan Line proper, Network Rail systems are effectively blind to what is happening. Up until about October last year when it broke properly for the final time, RTT had a mechanism to use track circuit data pulled from Trackernet to track trains through the area. In a similar mechanism to how it works on Network Rail metal, it used the time it stepped into the circuits to infer a departure and arrival time at each location based on fixed offsets.

Chiltern introduced the GPS reporting facility onto their fleet more recently which meant I was less inclined to fix the issues around Trackernet as it, really, didn't seem worth it. GPS reporting works mildly different for each operator due to the whims of the systems that drive it but, in a simplified/generalised view, the data goes into Network Rail's GPS Gateway as well as some other data warehouses. There are a series of geofences at most reporting locations which translates from time/position to reporting. I don't have a view of how big those geofences are for the Metropolitan Line but for some locations they are insanely large and they also don't always require the train to stop in the station limits to report for a station call.

My personal opinion is that the geofence, based on what I know historically, is that the geofence for Chalfont & Latimer is ... large.

 

[bramling]

Thank you. I missed that it was Sunday.

However I'm not sure what the benefit is of "keeping the trains in order" in this instance. Wouldn't it be better to keep the one waiting that is already stationary rather than stop one already in motion? The alternative would be an arrival at Chesham c.8 mins late at 22.52.5 which would still leave enough time to make an on-time departure of the 21.57 return service.

At the end of the day a signalling decision is required, and generally yes it is preferable to keep trains in order where possible. I’d say preserving a decent turnaround time for the Chesham train was probably not a bad call, as 4.5 minutes for an S stock to turn around isn’t much.

Given that the LU train had already got as far as having a clear signal, providing the driver responded immediately (no reason not to) then the Chiltern train would likely only have been checked rather than brought to a complete stand.