Hacker News
points by 1718627440 16 hours ago | 0 comments
> a damning indictment of the glaring incompetence of train companies.

No, what I describe has nothing to do with the companies, that's the research state. It's just an indictment of you making bold statement about a subject, you don't now enough about.

> I can have reasonably accurate gps readings of my phone

Would you dare to cross on a rope over a deep valley, blind using only GPS readings of your phone? Because that's kind what you are suggesting, expect you also move a few hundred other people.

[–] swiftcoder 16 hours ago
> Would you dare to cross on a rope over a deep valley, blind using only GPS readings of your phone?

Hang on, this is nothing at all like that - trains run on fixed tracks. The only bit of data we are interested in for collision avoidance is the linear offset along the track. Even the shittiest GPS fix of all-time would give a good-enough intersection with a fixed path to avoid crashing into a second stationary train in the open country-side (do you see any satellite line-of-sight blockers in the crash footage?)

[–] 1718627440 16 hours ago
> The only bit of data we are interested in for collision avoidance is the linear offset along the track.

So that is naive, but assuming that would be all that you need, with GPS you would also need the positions of all other trains. But why would you transmit all this information to every train, instead of just computing the collisions in a central node? (That's what is done now.) A better fit for what you suggest would be radar, and this does exist. [1] But that's where your original assumption is naive. You regularly pass other trains within <2m at high speeds, so linear offset is not all you need.

   [1] https://www.dlr.de/en/kn/research-transfer/projects/next-generation-train/rcas-railway-collision-avoidance-system
[–] swiftcoder 13 hours ago
> But why would you transmit all this information to every train, instead of just computing the collisions in a central node?

Because central nodes can fail (as they did here, both human and machine), and providing this redundant data allows both the computer and the human-in-the-loop on the fast-moving chunk of steel to independently validate the decisions coming from the central node.

> You regularly pass other trains within <2m at high speeds, so linear offset is not all you need.

In this collision, both trains were on the same track. So while we obviously care about adjacency issues in the general case, this specific failure mode can be detected purely via a linear offset.

[–] 1718627440 13 hours ago
You can and do have redundancy in the central node already. Also that's not what failed here.

> In this collision, both trains were on the same track.

Yeah, but how do you distinguish that? So when I understand you correctly, what you want is: Find another moving chunk of metal in the radius of 2km, which moves toward you, but not in a direct or ballistic trajectory, but in a arbitrary complicated trajectory, but which can lookup in a database. Also you are operating in the real world, so there are potentially houses, trees and mountains in between. I guess that would be possible, but it would be really expensive. Your best bet would be to adapt a missile detection and targeting system from the military. A system which does exist and is somewhat similar is RCAS (https://www.dlr.de/en/kn/research-transfer/projects/next-gen...).

[–] swiftcoder 12 hours ago
> Yeah, but how do you distinguish that?

By enumerating the tracks?

I feel like you are intentionally trying to turn this into a spherical cow situation by insisting on solutions that work in an information vacuum. All of this sort of problem in the real world is solved by sensor fusion from multiple data sources.

Trains are captive to a particular track - they can only change tracks at specific pre-determined junctions. With a pretty minimal sensor feed from each junction we can statically determine which track segment a given train is on. With GPS we can shrink that segment length down to a few kilometres. By sharing data persistently every single train can validate that central command-and-control is not about to run it into another train from behind...

There cases which are genuinely challenging engineering problems (i.e. derailments that impinge on adjacent tracks), but this trivial case of bumper cars is not one of them.

[–] 1718627440 12 hours ago
>> Yeah, but how do you distinguish that?

> By enumerating the tracks?

How do you distinguish that the <2km away detected moving train runs on your track on not on the one directly besides you?

> Trains are captive to a particular track - they can only change tracks at specific pre-determined junctions.

Yeah, but you do not know which one it runs on. Your entire point is that you do not trust the information the infrastructure knows. If you do allow to use information from the infrastructure, then why not use the sensors that already exist along the whole train network? It's also very unlikely that there is something electrically connecting the two rails of a track, that you would like to run over. So why wouldn't you trust that information, but some vague GPS signal?

> we can statically determine

But the current state of the art is, that you deterministically and provable know where a train is. Why would you use a more expensive, less safe system? The current focus to reduce errors in computing train conflicts is to prevent random bit flips due to radiation at the same time in three different computers running different software.

> I feel like you are intentionally trying to turn this into a spherical cow situation

The situation where you proposal makes sense, but the current system does not, is a spherical cow situation, that's my point.

[–] swiftcoder 10 hours ago
> that you deterministically and provable know where a train is

You are the one who framed this conversation as it not being solved how to deterministically know where a train is. Everyone else in here has been kindly suggest that if perfect information is unobtainable, then we should work with what we have

[–] tancop 10 hours ago
Redundancy in a central node is an oxymoron. Safety critical systems need to work 100% of the time if any single node fails, and stop safely if there are multiple failures and it can't work properly. Doesn't matter if each individual node is 100% reliable by itself because connections fail too.
[–] 1718627440 6 hours ago
You can still have redundancy in the computation, that isn't prevented by being in the same location.

> Safety critical systems need to work 100% of the time

Railway safety must be safe 100% of the time, but not available 100% of the time. Also the point of a signal box is to make decisions about the order of train assignment to track. You absolutely do not want multiple points of truths for that.

[–] collabs 16 hours ago
The way I think of it, divide the tracks into segments. Before you put a train on a segment, you must ask a question - is there a train on it. There are only two answers possible, No, and something else. If it is something else, stop. Don't let the train on that segment.

There are optimizations possible like make segments smaller etc but the original algorithm is trivial. If we can't figure things out, we make segments longer and we slow down the trains until we can. I am positive for a sufficiently large track segment and a sufficiently slow train, we can always answer the question with a no.

[–] jdmichal 9 hours ago
You've "invented" interlocking railway semaphores, after which the computer science concept was named.

https://en.wikipedia.org/wiki/Railway_semaphore_signal

https://en.wikipedia.org/wiki/Interlocking

[–] 1718627440 16 hours ago
Congratulation you are reinventing 1890 state of the art.
[–] bombcar 3 hours ago
The problem is when the modern computer-dependent system replaces the ancient one, and so then the computer is down there is nothing at all.
[–] 1718627440 2 hours ago
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
[–] 1718627440 3 hours ago
Which is why you generally don't do that.
[–] Pragmata 11 hours ago
who said anything about only using gps? I'm saying in addition to their current system!
[–] 1718627440 11 hours ago
The exact comment I answered to. https://news.ycombinator.com/item?id=50287160
[–] Pragmata 6 hours ago
i don't see where it says they should use gps alone. In fact it even mentions starlink in addition to gps.

>Even GPS + Starlink + 1 monitor (is that 50k€?) could have prevented this.

My reading on that sentence was that even a simple setup would have been sufficient to prevent this. Not that it should be the only thing.

[–] 1718627440 6 hours ago
My reading indicates, that "Even X could have prevented this." means that X is able to solve the issue on it's own. Otherwise X would in fact not prevent it.

- I don't think X would actually work, without actually eventually recreating part of the current railway control system, and the current rail control system alone already works better.

- I don't think another less reliable more costly safety system helps, when the current one already stated that there is a problem, and it was ignored.