Comment by potamic
4 hours ago
During normal operations you can act on the distant signal, because you know you're the only one in the block. But when falling back from linear to point signalling, you cannot make that assumption anymore. You need to get back to a state where you are certain you're the only one in the block, and the only way to do that is to reach the next main signal by sight after which you know you're clear for the that block.
Sure, another way to be certain is for the controller to manually verify that the block is clear and verbally communicate to the driver to override the protocol. But that is putting a lot of burden on human judgement, and even without this incident, anyone would agree is not the best idea.
I don't think this should be required for "normal" operations of the network. Sure, human override should always be there for when an exceptional situation occurs. But you should take extra precaution when that happens because you're already on your final safety net and relying on the judgement of a single human at that time, and that's okay because it's an exceptional situation that doesn't happen often and when it does you can afford to spend an hour or two to take that extra precaution.
The problem happens when the system fails so often that human override becomes the new normal, and because you're doing it every day you now cannot afford to spend the extra hour and tend to skip the extra precaution because you're doing it everyday and start to feel you know what you're doing.
> You need to get back to a state where you are certain you're the only one in the block, and the only way to do that is to reach the next main signal by sight after which you know you're clear for the that block.
Yes, that is manual operation.
> Sure, another way to be certain is for the controller to manually verify that the block is clear and verbally communicate to the driver to override the protocol.
That's not another way, that's the exact situation you just described. To "manually verify that the block is clear" is drive by sight. The only alternative would be to walk along the whole track.
The problem is (AFAIK), that they didn't do that.
> I don't think this should be required for "normal" operations of the network. Sure, human override should always be there for when an exceptional situation occurs. But you should take extra precaution when that happens because you're already on your final safety net and relying on the judgement of a single human at that time, and that's okay because it's an exceptional situation that doesn't happen often and when it does you can afford to spend an hour or two to take that extra precaution.
All of that is the case, but you underestimate how often exceptional is in a whole train network. One per million means it occurs daily.
> and when it does you can afford to spend an hour or two to take that extra precaution.
You have a lot of time, but that means you operate on the order of minutes, not seconds. Needing hours is not emergency operation, that means we cease doing operations. You can of course take several hours to bring the network back to full operation, but you need hundred to thousand operations for that, so a single operation still doesn't have hours time.
> To "manually verify that the block is clear" is drive by sight. The only alternative would be to walk along the whole track.
But aren't there additional systems that can detect that a block is obstructed (e.g. also by left behind carriages that got disconnected) like the electrical track circuit (Gleisstromkreis)?
Or wouldn't that have helped because we're back again to the issue that with the downgrade from LZB to PZB we lost the virtual blocks, and both trains are now occupying the same, longer, non-virtual block?
Which would mean that this block would have been indicated to the controllers as not clear - but that is exactly what they would expect to see, because they're currently deciding what instructions to give to the AVE, which they know is stopped in that block. But they have no indication that there is a second train (Iryo) in front, occupying the same block.
Hence, I assume, the protocol to resume operations with drive by sight after a LZB failure (which seems to have been ignored in this case). But why not also have the protocol demand that operations are resumed front-to-back in that situation? I suspect that "front-to-back" is not nearly as unambiguous a concept in reality as it may seem in my layman's head.
> But aren't there additional systems that can detect that a block is obstructed (e.g. also by left behind carriages that got disconnected) like the electrical track circuit (Gleisstromkreis)?
That's not an additional system, that is the PZB (or here ASFA).
> Or wouldn't that have helped because we're back again to the issue that with the downgrade from LZB to PZB we lost the virtual blocks, and both trains are now occupying the same, longer, non-virtual block?
Yes.
> But they have no indication that there is a second train (Iryo) in front, occupying the same block.
We don't know what they missed, and speculating on that is quite pointless, if we want to have that discussion, we need to wait for the post mortem, this is what such a report exists for. We only know THAT they missed something. That they missed that the first train was in that block too, is one option. It could also be, that it was not clear which signals are virtual or that there was a communication mismatch between different dispatchers or that there was a bug in the automatic train identification system or that an automatic system did call for that procedure. All of these already do occur in railway accidents, they are not really speculative. The last one is what happened in 2002 in the exact same situation: the computer automatically ordered the second to full speed and the first to stop. There could also be some other issue, that I can't think of right now. Most likely it's more than one error, because people still do pay attention.
> Hence, I assume, the protocol to resume operations with drive by sight after a LZB failure (which seems to have been ignored in this case)
I don't actually know what the protocol in Spain is. In Germany it is like that now, but only due to the 2002 near-accident. Before that it was ambiguous. If you are a dispatcher you don't only get taught a bunch of rules. You get taught the primary constraints and then you are able to construct the rules from first principles. However under pressure it's likely to forget something vital, so there are still rules that you are supposed to follow. But no ruleset will be ever complete, that's why you don't only follow rules.
> But why not also have the protocol demand that operations are resumed front-to-back in that situation?
That wouldn't solve anything. Drive by sight is safe in that situation, driving faster is not. If you start front-to-back you can still have collisions, but you just waste time. There is also not necessarily no physical block between trains, so it could be safer to start a later train. Also are you sure you are able to correctly assess the positions and order of the train? You are supposed to, but I mean that obviously failed here. Just drive by sight.
Shinkansen does that afaik. 30km/hr cap during manual operation. No exceptions.
And in Europe the cap is 40km/h in most places. The issue is that they did not call for manual operation.