Hacker News
points by iggldiggl 10 hours ago | 0 comments
> Update. A second security system should had stopped the train automatically in the next red semaphore (or reduced the velocity to 40Km/h) without machinist intervention. That system was down also.

No, it wasn't, from the way things have presumably played out, the scenario has simply hit an inherent design limitation. Namely LZB (https://en.wikipedia.org/wiki/Linienzugbeeinflussung) is the primary signalling and train protection system, but as a fallback, conventional colour-light lineside signalling together with the corresponding conventional train protections system (ASFA) has also been provided.

As a fallback system however, the lineside signalling has been set up with much longer signalling sections than the LZB, i.e. one conventional signalling section comprises multiple LZB signalling section. As such, it is still perfectly safe and serviceable, with the only immediate drawback that capacity will be significantly reduced due to the longer signalling sections (and also slower running speeds – the lineside signalling is limited to 200 km/h max).

The only problem comes in when you need to make an unscheduled transition from LZB to lineside signalling because of an LZB fault – while at first the trains will be safely braked to an immediate stop, you may now have ended up with multiple trains (all safely inside their own LZB block section) within the same lineside signalling block section. Which means that now there is no "next red semaphore" to prevent the second/third/… train from running into the train in front.

The proper procedure therefore is to untangle the trains by running them out of that accidentally shared block section one at a time and most likely at a reduced speed, too, but for some reason that procedure wasn't followed here…

Aún no hay comentarios.