Signalling chaos: Inside the Elizabeth line's two-day breakdown | Hacker News Reader

Signalling chaos: Inside the Elizabeth line's two-day breakdown

ianvisits.co.uk

28 pointsedward11 comments

There's very little information in either this post or elsewhere on the internets.

This discussion on a UK rail forum provides some food for thought [1]

The Elizabeth line is pioneering in terms of aiming for automated train operation (ATO) over infrastructure that's shared to some extent with trains driven by humans. Going beyond driving per se, both types of trains make use of highly complex automation for functions like switch management, traffic separation for safety and station door opening.

Reading through the lines, two systemic difficulties this brings about are:

(A) A conceptually new ATO system (Siemens Trainguard MT); a further plot twist is that Siemens acquired the system mid-development from Invensys.

(B) Ad-hoc integration of this system with a large number of external systems provided by several vendors; it should be of note that rail systems are not designed for to interoperability with other vendors, and integration is often achieved post-development bringing about otherwise avoidable complexity.

Given that during the incident each individual domain of the system (A) has been reset and validated multiple times, my suspicion falls on the undocumented and uncharted complexity underlying (B).

[1] https://www.railforums.co.uk/threads/elizabeth-line-total-lo...

The communications system is not novel. It's GSM-R, which is good old 2G cellular with some special railroad features. Both voice comms and signalling run over that system. Since both went out, the comm system must have failed.

Do we know for certain that a major cause of the failure has been a GSM-R failure?

Industrial grade communication systems tend to be very well behaved in terms of fault detection and management. I'd be very surprised if the whole whack-a-mole dynamic described in the post was a failure mode of GSM-R system per se.

> Do we know for certain that a major cause of the failure has been a GSM-R failure?

Train drivers lost their voice connection to their control centers.

Feels like it's looking for some (new?/refactoring?) common interface/protocol for engine and rolling-stock comms.

Is that even possible? Anyone known what type of on-rail signaling is possible?

Some more context https://www.railengineer.co.uk/migrating-from-gsm-r-to-frmcs...

I'd assume signaling software requires years of certification. Nobody starts refactoring before it's too late.

Disclaimer: No insider knowledge.

Content-wise more like outside

Incidentally GSM-R problems led to a nationwide train service shutdown in Norway on December 25. Related?

It was said the fact of a shutdown was not a huge exception in Norway, it had happened before. The fact that they couldn't just restart was. Just what I read.

As others are saying in the comments, this feels like a bit of a useless post – it claims to explain what went wrong but actually never gives any explanation.

Reply on news.ycombinator.com