Cambrian line 20 Oct 2017: loss of ERTMS speed restrictions. RAIB report released

[Belperpete]

I think you mean not updating a temporary database. I think we're in agreement aren't we?

You proposed providing "a hard-coded passive temporary balise placed for each restriction". I am disagreeing with that. With a Level 2 ETCS system, the speed restriction information should all come from the RBC.

 

[MarkyT]

But do the balises have any effect when the backup signalling methods are in operation? Presumably the ERTMS is disconnected in the cab at such times.

Maybe it needs a new mode. Could be a new packet 44 system or perhaps they could jury rig parts of the new 'limited supervision' mode in newer implementations. I don't believe the ERTMS onboard ever switches off completely at such. Even AWS/TPWS is usually emulated within the EVC and DMI using STM methods.

Alphabet soup:
EVC: European Vital Computer, core onboard movement safety system, closely integrated with traction and braking control.
DMI: Driver Machine Interface, the control screen(s) switches and sounders in the cab.
STM: Specific Transmission Module, compatible peripheral hardware and software modules for Class B systems emulation (usually a legacy national protection system but also including new things like or WCML TASS, ATO on Thameslink).

 

[Belperpete]

The use of a non-safety-critical system to effect safety-critical controls has some resonance with SSI, where the non-critical Technicians Terminal is used to apply and remove temporary controls in the interlocking, such as temporary approach control, aspect restriction (holding a signal at red), route restriction (preventing a certain route from being set), and disabling points (preventing a certain set of points from being controlled). These temporary controls may be lost after an SSI restart, in which case it is necessary for the technician to re-enter them. I wonder if this may have had some impact on the approval of something similar for the Cambrian ETCS temporary speed restrictions.

The big difference is that with SSI, the Techs Terminal merely acts as a message transmission medium. When a Technician enters a control, that command is sent straight to the interlocking, and the Techs Terminal displays the interlocking's response. Likewise, when the technician asks for a list of the controls currently applied, the Techs Terminal sends a command to the interlocking, which sends the list back to be displayed on the Tech Terminal. Nothing is stored in the Tech Terminal. With the Cambrian ETCS, on the other hand, the GEST terminal stores the state of the controls so that they can be constantly displayed. With the result that when the system went into its error mode, it continued to display out-of-date information, leading the signallers to think that the controls were applied when in fact they weren't.

I must admit, this has got me pondering about Smartlock and Westlock, where I believe their equivalents of the Techs Terminal do provide a constant display of the Technicians controls.

 

[MarkyT]

You proposed providing "a hard-coded passive temporary balise placed for each restriction". I am disagreeing with that. With a Level 2 ETCS system, the speed restriction information should all come from the RBC.

OK. In standard L2 installations I'm sure you're correct, but practically anything is possible in ERTMS land. In Berlin, Siemens have developed a new limited supervision Level 1 system called 'ZBS' to replace the mechanical train stops on the S-Bahn, using standard ETCS components. In theory, any ERTMS fitted train could use that if they had the correct software to emulate it in their EVC/DMI. Because it uses standard ETCS balises it wouldn't even need any extra hardware modules onboard.

 

[MarkyT]

The use of a non-safety-critical system to effect safety-critical controls has some resonance with SSI, where the non-critical Technicians Terminal is used to apply and remove temporary controls in the interlocking, such as temporary approach control, aspect restriction (holding a signal at red), route restriction (preventing a certain route from being set), and disabling points (preventing a certain set of points from being controlled). These temporary controls may be lost after an SSI restart, in which case it is necessary for the technician to re-enter them. I wonder if this may have had some impact on the approval of something similar for the Cambrian ETCS temporary speed restrictions.

The big difference is that with SSI, the Techs Terminal merely acts as a message transmission medium. When a Technician enters a control, that command is sent straight to the interlocking, and the Techs Terminal displays the interlocking's response. Likewise, when the technician asks for a list of the controls currently applied, the Techs Terminal sends a command to the interlocking, which sends the list back to be displayed on the Tech Terminal. Nothing is stored in the Tech Terminal. With the Cambrian ETCS, on the other hand, the GEST terminal stores the state of the controls so that they can be constantly displayed. With the result that when the system went into its error mode, it continued to display out-of-date information, leading the signallers to think that the controls were applied when in fact they weren't.

I must admit, this has got me pondering about Smartlock and Westlock, where I believe their equivalents of the Techs Terminal do provide a constant display of the Technicians controls.

It's also techs that apply and remove the restrictions rather than the signaller in SSI land, analogous to the same employees 'slipping the links' in a relay installation. Of course conventional signalling has no direct knowledge of speed...

 

[Belperpete]

.... Make the RBC and its data much simpler and encode all the static data about the infrastructure in the permanent lineside balises as well. After all, being static the data only changes when the infrastructure itself changes when the extra work of reprogramming the balises is not a great additional overhead. Means even when the RBC was down and backup signalling methods were in operation, all civil speed restrictions could still be accurately followed. I'm liking this decentralised approach.

Apologies, I have just re-read your post, and realise I had mis-red it. I thought you were saying that the speed restriction info from the balises would be in addition to that coming from the RBC, I now see that you are saying ALL the speed restriction info (for both permanent and temporary restrictions) would come from the balises, and the RBC wouldn't send any speed info.

As you say, this would simplify things. The problem is, it would over-simplify things. From my experience working with balises, there is a limited amount of information that they can transmit. This can be very limiting, especially where there are multiple routes ahead.
Even on a simple two-track metro system, we were having to "simplify" the speed restrictions in order to fit the necessary information into the balises. In practice, this meant making them more restrictive than they needed to be, e.g. by extending restrictions to join them into one, reducing the speed to match another restriction ahead or on another divergence, and so on. The advantage of ETCS Level 2 is that the RBC sends only the speed information relevant to the route the train is taking, and there is scope for sending much more information.

 

[MarkyT]

Apologies, I have just re-read your post, and realise I had mis-red it. I thought you were saying that the speed restriction info from the balises would be in addition to that coming from the RBC, I now see that you are saying ALL the speed restriction info (for both permanent and temporary restrictions) would come from the balises, and the RBC wouldn't send any speed info.

As you say, this would simplify things. The problem is, it would over-simplify things. From my experience working with balises, there is a limited amount of information that they can transmit. This can be very limiting, especially where there are multiple routes ahead.
Even on a simple two-track metro system, we were having to "simplify" the speed restrictions in order to fit the necessary information into the balises. In practice, this meant making them more restrictive than they needed to be, e.g. by extending restrictions to join them into one, reducing the speed to match another restriction ahead or on another divergence, and so on. The advantage of ETCS Level 2 is that the RBC sends only the speed information relevant to the route the train is taking, and there is scope for sending much more information.

Perhaps the balises need to be able to transmit larger messages faster. Maybe we're approaching an obsolescence point like the old radio limit with GSM?

 

[Tim M]

But what happens in degraded mode, when the RBC has shut-down and trains are being signalled manually as described in the report - are the drivers expected to remember the temporary restrictions? Surely warning boards should be provided to cover such situations?

If the train loses communication with the RBC, the driver will need to select a ‘Restricted Manual’ mode of operation with the on-board ETCS limiting speed to say 20km/h, more or less line of sight operation and probably less than most TSR’s. All such moves to be verbally authorised by the Control Centre Operator, taking into account other factors such as route set etc., including in the message any specific very low speed TSR.

Or at least that’s my interpretation from working for many years on mass transit ATP train control systems. Is ETCS different in this regard?

What bothers me, again from my experience, is that anyone would consider the application of TSR’s as less than SIL 4 - Safety Critical. What happens when a TSR is applied in an emergency, say after detection of a broken rail? It’s not clear how this is implemented.

 

[Belperpete]

What bothers me, again from my experience, is that anyone would consider the application of TSR’s as less than SIL 4 - Safety Critical. What happens when a TSR is applied in an emergency, say after detection of a broken rail? It’s not clear how this is implemented.

With SSI and its successors, route bars are applied by a non-safety critical system (the techs terminal), as per my previous post. These are arguably even more important than TSRs.

 

[Belperpete]

If the train loses communication with the RBC, the driver will need to select a ‘Restricted Manual’ mode of operation with the on-board ETCS limiting speed to say 20km/h, more or less line of sight operation and probably less than most TSR’s. All such moves to be verbally authorised by the Control Centre Operator, taking into account other factors such as route set etc., including in the message any specific very low speed TSR.

If that is the case, why are there signs for PSRs? (I have just passed one at Barmouth). It does seem inconsistent that signage is felt necessary for PSRs, but not TSRs.

 

[Belperpete]

It's also techs that apply and remove the restrictions rather than the signaller in SSI land, analogous to the same employees 'slipping the links' in a relay installation. Of course conventional signalling has no direct knowledge of speed...

According to the report, that was also how the ETCS was intended, with the techs applying the TSR controls. However, as the Cambrian doesn't have 24/7 tech support, the terminal was moved so that the signallers apply the controls.

I seem to recall that there are some SSI installations where the signallers have a tech terminal. But only for fault diagnostic purposes, not for applying controls.