1718627440
Like:
$ cat $(find project/ -name '*.py' -type f)
?The issue is that this gives perverse incentives for companies, unless you also have proper regulation, which you should have anyway. The issue is that you don't.
But in this case I agree with you, because in addition to the costs, there are also huge benefits for the general population to letting these companies fail. Both in actual behaviour and power right now, but also as a future incentive for all other companies.
But if you replace ATC with train control in general, then yes, I agree.
b) In a point based train control system, communication only happens at specific points. That's why it is called this way. On it's own it is safe, because in order to do anything non safe, like passing a red signal, you need to pass such a point. In order to violate a speed limit, you would need to pass the start of the speed limit, which also is such a point.
If you operate a line based control system, you are constantly making collisions from the view of the point based control system. The moment the line based system breaks down, the point based control system takes over and the only safe choice to do in the case of a collision is to immediately stop all trains. That's exactly what it did.
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.
Exactly.
> Probably like moving one train at a time at <40kph so that there is minimum one ASFA block
If you tell the drivers to move by sight (also <40km/h), you can tell them to all move at the same time, because "by sight" means that the drivers themself can observe objects in their track. They essentially start to move like cars on the road, which they normally don't. Normally a driver does not have an obligation to verify that it is safe to drive somewhere, but then they do. It does not mean that the trains actually move at 40km/h, they can move at 1km/h if that what is required in order to move the train by sight. 40km/h is just the maximum after which it is deemed unsafe to move a train by sight even in the best sight conditions.
> Not only passengers would be angry [...]
I doubt that was even a consideration, that would mean that they would have been aware they ordered a collision, but rather:
> What likely happened was that they didn't think about any of that at all [...]
Yes.
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.
> Some reports said that the renfe train rolled for 25km - if this is what their fallback is like - it is absolutely inexcusable. Oh my...
I do not know what you mean with that, and what "rolling" would mean here.
If you (as a dispatcher) order a train to drive into an occupied block, you ordered a collision, independently of whether you notice later and call for an emergency stop in time, or someone else notices and prevents it.
> And when one reported to be unable to do so, they failed to stop those that were around it.
That's not what was the problem, they wouldn't be required to do that. Any train is supposed to stop at any time, without you having notice of that. It's completely normal, that you do not call for other trains to stop, if one train reports that it stopped.
In order for them to think of the conclusion of "first train stops" -> "shit there is another train in that block", they need to be aware that they told another train to be in the same block, before the call. Ordering a train to drive into the same block as another train, means ordering the trains to collide. So they would have to be aware that they ordered a train to collide into the other prior to the call, in order to arrive at that conclusion.
> The newer system should be running.
A newer system would not solve anything here. This exact failure case exists in every system that has virtual blocks, which is every new system. If you are looking for scapegoats, THAT is one.
> ordered to everyone to just restart the march, but the Iryo just couldn't.
Railway protocols operate under the assumption that any train can stop at any time immediately (not even with a braking distance) without the dispatcher noticing. You need to have the information of complete departure of the previous train before allowing the next train to move. If the first train would be able to start, it would still be pure luck if there wouldn't have been a collision.
If the first train was really just before the exit of a block, then it's pretty safe to assume that the second train saw the corresponding distant signal.
> the Spanish system allows the controller to override the point-based rules
Every system allows that, it is required in order to be able to operate a railway network.
> What I'm gathering from other sources is that the Spanish system allows the controller to override the point-based rules and provide manual clearance
What actual happened is my speculation, the explanation how LZB works is not. It can be the case, that they messed up while issuing manual movement authorities, but if they did not notice that they need to switch to manual operation, they will have caused a crash.
> then when LZB goes down it has to slow down/wait/follow some different protocol
The trains did stop when the LZB reported an error, like they should.
> follow some different protocol
That is manual operation, which I suspect they failed to do.
man encrypt works. info /encrypt works too.