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 8 hours ago | parent | next [-]

> 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 7 hours ago | parent [-]

>> 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 6 hours ago | parent [-]

> 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

▲

1718627440 6 hours ago | parent [-]

Oh, I see how you could think that, without context. That's in fact not what I wanted to say. I meant that pretty literally. The infrastructure of course knows where the train is.

> Trains are still not able to assess properly where they are, even using satellites and inside train sensors. Of course there is research on that, but it's still an unsolved problem.

*Trains* on there own! This IS a hard problem, how to do that with any other infrastructure. It IS current research and not yet solved. That is for example relevant, if you want to be able to run trains at full speed <1m tolerance, so that you can have more than one train stopping at a station <60s. All while still not paying for infrastructure and maintaining backward compatibility with a century old trains. (I mean in the future you could use the same to also couple trains at full speed, but that's still sci-fi.)

▲

thaumasiotes 3 hours ago | parent [-]

> That is for example relevant, if you want to be able to run trains at full speed <1m tolerance, so that you can have more than one train stopping at a station <60s.

...is that something you'd ever want? In general, it is, but the way it's handled is by having those trains stop on separate tracks.

Running multiple trains through the same station track in under 60 seconds means that all passengers must embark and disembark in under 30 seconds. That's very tight. I would venture to say it's too tight and meeting this goal would make the trains worse.

(And if passengers aren't getting on or off the train, then the train isn't stopping at a station.)

	▲	1718627440 2 hours ago \| parent [-]
		In a society where building more rail is not welcomed, trying to get more out of the existing tracks becomes critical. In a metro, time for embark and disembark of 30s is not unreasonable. https://de.wikipedia.org/wiki/Fahrgastwechselzeit#cite_ref-d...

▲

tancop 6 hours ago | parent | prev [-]

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 2 hours ago \| parent [-]
		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.