1718627440

There is a reason postfix is the idiomatic way in C, it is the correct choice most of the time.

When I wrote that comment I would have answered, that you already need to distrust a system, that of course still have the authority to sound like it would be right. Also from other accident reports, my understanding is that relying on yet another system causes people to make even more errors, while when they start to manually assess the situation from first principles, they are able to grasp the fundamental error, because they are questioning every assumption, as they are reconstructing a world model different from the automatic system. But the latter takes more time and effort, so people tend to do the former.

The thing is that in modern automated dispatching you only have the same world model as the automatic system, so when there is an error you have the same world model as the system, but that just detected, that that does not equal the actual state of the world. And often the error is in fact a false positive.

But now, I actually think that this accident was caused by several systems being in effect: https://news.ycombinator.com/item?id=50298796

> When the Iryo reported to be stuck, all the trains in the line should have been notified to stop once more

That would have meant that the dispatcher would have been aware that they already ordered a collision before. If a train stops no accident will happen, unless it could have happened regardless. Yes, such a decision would have prevented the accident or lessened it's impact, but the absence of it has not caused it. The error was already done before.

From reading only the linked BBC article, I would come to a totally different conclusion. That would sound like more of a dispatcher ordering a manual operation of a train, without having assessed the situation correctly. While yes, this happens (https://en.wikipedia.org/wiki/Bad_Aibling_rail_accident), this happens on minor single-track lines where the dispatcher starts playing games on his smartphone full-time due to being bored, not on a major high-speed line. Also the issue with LZB doesn't fit into the picture that the BBC paints, neither do the many people involved, so I will prefer the theory mentioned above. Also that seems like a "reasonable" "sufficiently not-obvious" error to make, given the line and attention.

The thing is that trains move way faster compared to friction (which is needed for breaking and manoveering) than cars. The equivalent is if you would be driving 900-1200 km/h with your car[1]. Good luck being able to break in time on that speed and estimating your position with GPS.

Also the hard part is knowing the position of the others and their trajectory, which changes in between moving towards them and is done by a third party. The normal passing distance is smaller than the width of your vehicle and you can only change your own direction every few kilometers. That means that the others trajectory towards you can only become known after you are already past your last opportunity to change your trajectory and even within your breaking distance. Good luck!

[1] Friction for cars on the road is 0.010-0.015, for trains 0.001-0.002; train speed 120 km/h * 7.5 = 900 km/h equivalent for car; that's not even a high-speed train.

So to explain the used terms more: Most train control systems operate under the assumption of a fixed block. The whole network is separated into blocks, there can always be only one train in a block. Each block is protected by a signal, there must always be a red signal separating one train from the next, and there are sensors that detect when a train drives in a block, when it drives out of a block and how many carriages (train integrity is important too).

For point based train control systems, operation of a train is only enforced at every signal (and on the way in approach at specific points), this means e.g. that a train does not run over a red signal, does not drive faster than the maximum speed, and has acknowledged speed limits.

For line based train control systems, that supervising happens continuously over the whole track.

Since the physical signals and sensors are expensive in installation and maintenance and railway capacity depends on the number of blocks on a track, line based train control systems support virtual blocks. This means that the signals and sensors are not physically there, but simulated by computers (on the train and signalbox). From the view of the point based train control that means multiple trains are in a single block, because it does not know about the virtual subblocks. When a train is running that only supports point based train control it can only use whole blocks, so the capacity is simply reduced, but it is still safe, because every physical block is also known in the line based control system.

When the line based train control system stops being in use, the fundamental constraint of the point based train control system is being violated: there are multiple trains that are in a single block, and hence not actually protected by a red signal in between. This means that you must ignore the signals until every train has crossed at least one physical signal.

(This is speculation:) It seems that that the operators assumed that there is still a safety system in place, that they can rely on. Hence they did no tell the trains to use manual operation, (which might also require driving by sight [max. 40km/h], but not necessarily, I don't know the proper procedure in Spain), but told them to fall back to the normal safety system. It's reported that some train drivers and dispatchers questioned that, but that can also be an translation error and instead them repeating what was said, as is proper safety procedure. But the point based train control system will show a green signal, even if there is actually a train in front, because it is in the same block as you, but the signal shows whether you are allowed to drive in the next block, not into the current, as you are already in the current block. This seemed to be what happened here, the second train saw the green signal thought they are back in the automatic safety system and accelerated to 200km/h, not knowing that there is still a train in front. The first train should have also started driving, but did not, due to an error in the train. In normal situations this should never cause an accident, but in this case the accident would not have occurred if that wouldn't have taken place, but that would have been simply by luck.

You can see the green signal in some of the pictures, which to me looks really weird (kinda like a both dead and alive corps), because I would expect to put all signals to red in the case of an accident. I would expect to do that, while you are calling the emergency number, but I do not know if that is the procedure in Spain. You also see in the pictures that the whole cluster traveled about a train length and that the last carriages of the first and the first of the second train are merged into one. This indicates a surprisingly high speed for the crash, above 100km/h. That fits the explanation of the second train not being able to see the first until directly up to a few 100 meters before.

There were actually more trains in that block, so it's pure luck, that there were "only" two trains involved in this accident. Also some claimed, that there was a curve directly before, so the second train couldn't see the first until directly up to the accident. This would not have prevented the accident, it would have just reduced the involved crash speed and hence reduced the number of dead people.

It's quite ironic, that the accident would have likely not happened in case of no safety system being present.

---

Actual classical collisions of two trains like in this case are quite rare, because that's like the first purpose of every train control system, which exist since the 1870s. The accident from January this year in Spain was also a collision, but because a train derailed, while another train passed it. This can't really be prevented by a current train control system, other then not allowing the derailment to happen in the first place. Derailment in carriages is actually not rare at all, but daily, it's like going slightly on the shoulders of the street with your car, but train derailments are.

The accident from Meerbusch-Osterath from 2017 is similar in that is was also a collision. The cause itself is not really similar. The normal train control also failed, so the trains need to be operated manually. For that it was still relied on the automatic train detection and labeling system, but that had a bug (and some operator error due to a bug, this is simplified) and showed the number of the second train, where the block of the first train was. So they allowed the second train to advance. They did have contact with the first train, because they noticed something was wrong, but that driver didn't properly speak German and also failed to look out of the window directly where a hectometer sign was, so he couldn't tell the dispatchers were he actually was. The dispatcher forgot to tell the driver of the second train to use drive by sight (40km/h), so he accelerated to full speed (120km/h). The accident only caused 40 injured people and no deaths, because the second driver saw the first train. The accident happened at night, in the dark and at a speed of 85km/h. Train dispatchers are supposed to keep track of the trains and the actions they do too, but since the automatic train detection and labeling works most of the time, it becomes easy to rely on it.

The accident from Fallersleben from 2002 is similar, because the original failure of LZB and fallback to PZB is the same. Hence there was also more than one train in one block. The signalbox software told the second train to advance to full speed and the first to stop. This would have caused a crash, but the train driver of the second train noticed, that couldn't be and notified the dispatcher who then told them to not proceed, hence the accident didn't happen. This caused it to become mandatory to let the first train to drive again operate on sight [40 km/h].

Because the issue is knowing where the other trains are, not yours.

From what I read the opposite was the case. They kept relying on a fallback system, when manual operation was required: https://news.ycombinator.com/item?id=50298796

Actually in this case it looks like the error was that the light did show green, when it should be ignored: https://news.ycombinator.com/item?id=50298796

Actually in this case it seemed that the opposite was the case, there was another fallback system, but you needed to disregard it, and operate manually, but the operators likely didn't notice that. https://news.ycombinator.com/item?id=50298796

(The following is speculation:) The issue is that there was still a fallback system operating (ASFA), so they likely assumed that there is still a safety system running, while actually it needed to be ignored, because due to virtual blocks of LZB there is then more than one train in a ASFA block. This means that the next signal shows you "clear", so you accelerate thinking you are back into normal operation, but there is actually a train in front of you, just not in the next block, but in your very own block, which is a situation that is not supposed to happen. So the issue is kind of different train control systems interacting disagreeing with each other. Ironically it would have been actual if there would not have been another safety system, because then they would have known, that they need to operate manually right away.

The following is hypothetical, since we do not have a proper safety report yet.

It sounds like the issue happened, because there was an error in the line-based train control system (LZB), which led to falling back to the point-based train control system (ASFA). However since there are more virtual blocks in LZB, than physical blocks in ASFA, this means that suddenly more than one train is in one block, which violates the most basic assumption of train control. That requires the trains to not rely on the train control at all, even if it says that the block is clear, but instead are operated manually.

I do not know what the proper procedures for that are in Spain, but in e.g. Germany that seems to require driving by sight. However that is also only after a number of accidents due this situation. So the following seem to be similar accidents from Germany:

- https://de.wikipedia.org/wiki/Eisenbahnunfall_von_Meerbusch-...

- On April 9, 2002, a near-collision occurred near Fallersleben. After a computer at the LZB control center in Fallersleben crashed, two trains on each of the two main tracks came to a stop. When the computer was restarted, the rear train in each pair was signaled a speed of 160 km/h, while the front train in each pair was signaled 0 km/h. One of the two train operators following saw the train stopped in front of him; the other, as a precaution, contacted the operations center, which warned him not to proceed.

Yes. General safety culture. However asking who is at fault instead of asking how to prevent it from occurring again, is also an indication of a lack of safety culture.

In addition: https://news.ycombinator.com/item?id=50297950 https://news.ycombinator.com/item?id=50293093

Which is why you generally don't do that.

Fundamentally I don't know what the cause is, because there is no full safety report yet, but I doubt that it was a driver error alone, which is what automatic braking systems at signals are actually targeting.

There are situations where the dispatcher needs to instruct the driver to ignore the road signals and hence also ignore the automatic enforcement of the signals. It shouldn't happen to often, but the real world is always more messy.

Ultimately red signals due not fall from the sky. They are controlled by the same people that issue oral or written movement authorities. So focusing on just the oral movement authorities doesn't address the real problem. In the end it is the same signal in a different medium.

I do not Spanish to assert whether it is true, but it is often said about German and there it is not true. I think the issue, that it is often mixed in daily speech, but that's true for English as well.

"Sadly" anything involving safety with humans is never a solved problem, because safety culture needs continuing training and effort.

I should have written that comment quite differently, it took a while for me to understand how it is read.

I did not say "train systems are ...", I said "trains are ...". This is referring to e.g. that odometry based on wheels results in a drift. GNSS is to imprecise and unreliable. I'm aware that you simply use balises, that's what I meant with "markers in the track". However that's based on the infrastructure again, so it's again not trains on their own.

https://news.ycombinator.com/item?id=50293093

It was simply supposed to be an example how GPS sounds like it should easily solve a problem, but does not without additional measures, that then do not need GPS anymore.

Thanks.

I mean they are systems that rely on GNSS in Europe, but no safety systems, that would be simply to unreliable. For example I believe the railway announcements in Germany to depend on GNSS. They are also unreliable.

Because balises cost money, are payed for by infrastructure companies. Their position needs to be decided a priori, so you can't have the whole resolution on the whole network in order to get as close to the physical limits between trains as possible. Also it would be nice to be able to implement automatic shunting without additional infrastructure costs.

There are actually different definitions for what a block is. It can be both a section where you can decide for trains to enter or where you can change their sequence (Zugfolgeabschnitt vs. Zugmeldeabschnitt, don't know the English terms) Also it can be a physical implementation of any constraint between components of different stations.

But yes there does not need to be a limitation on there only being a single train in a tunnel.

In addition to that being unpractical, the train doesn't even know the state of switches, i.e. not whether it is on the same track as some other position. It's just that this is undecidable for a single train. (This is what my first comment was about, it's simply not known how to solve it on the level of a single train, likely because it is impossible.) However the answer for what to do if a train can't trust the network, is don't move. Or move by sight, which is limited to 40km/h for good reason.

On the other hand this is a complete non-issue and solved for more than a century on the network level. So there is zero need to invent satellite or vision based train detection at worst even using statistical systems, when you can use deterministic systems, for example using the fact that a train is out of metal, so it's detectable by the train closing a electric circuit between the rails. Or using the sensors that are installed at every signal, switch or other positions for precisely this question.

Ok, so railway safety for me doesn't stop at the end of high-speed lines. But, maybe Japan does indeed clear the measure you suggested, so congratulations to Japan, I guess?

It can be on the other track right now, but change to your track in the future. Or in other words, the topology of the network changes in operation. Whether the track you are on and the track another train is on, is the same or not is not decidable without knowing the current network state.

> Presumably switches already report their position to somewhere.

Yeah and this somewhere already knows whether a crash is going to happen. In which case your solution brings no benefit. You can't rely on the correctness of a system, which you want to make an alternative to, to help in the case the original system fails.

This discussion focuses on a non-problem (granted partly due to an imprecise comment of mine). The system knows where all the trains are and also that a crash will happen, if the decision is made, that then indeed was made.

What is needed is that the system needs to convince the operator there is still a problem, after it proved itself unreliable. My suggestion would be a log of the constraints the prover encountered while determining whether there is a conflict. This certainly already exists somewhere in the background, but I am not aware whether that is currently shown to operators in deployed systems. It does exist somewhat in the research systems we use in university.

> And that conclusion is basically meaningless.

That's the distinction between being able to do something or not if you do not have control over the webserver, as is likely the case for a lot or PHP websites, so I wouldn't say it's meaningless.

My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.

> And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix

The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.

> And that's assuming you actually meant "turn off PHP" the entire time?

I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.

And according to the article the signalling system reported, that the track is blocked.

I wasn't talking about a specific line at all. Research doesn't need a clear problem to try to find better solutions. Also Deutsche Bahn does think there is enough of a "problem", because they do support that research.