Keeping track of which parallel track a train was on automatically was a solved problem a hundred years ago, using relays and lights and hard-wired logic. Adding computers and GPS greatly increases the precision with which dispatch knows position and speed along the track, but knowing which track has not changed in the last century.
Oh, they can, but it's usually a very traumatic event.
What we're talking about here is some sort of TCAS-equivalent for the case where the central signalling is down – while it's easy to accurately localise trains with the aid of a central signalling system that authoritatively knows about the infrastructure layout, it's quite more difficult when you're trying to do the same thing in a decentralised, train-local fashion.
Single track means that at least outside of stations, collisions can be reliably identified without much danger of false positives (and for station areas you can just institute a blanket speed limit to compensate for the gap in RCAS coverage, which might not even be any lower than the speed limit required for traversing diverging/spring-operated/hand-operated points there anyway), and no already existing full-scale signalling system means that RCAS actually provides a significant safety benefit and is therefore likely worthwhile from a cost-benefit-analysis point of view, too, if you're actually regularly operating multiple trains simultaneously on that kind of infrastructure.
Whereas on multi-track mainline railways avoiding false positives is much harder and normally you should already have proper signalling and train protection systems in place anyway, so the additional safety benefits of RCAS would be much more marginal.
It's not impossible. But handwaving GPS placement of trains at the correct location, direction, and track deserves more than a handwave as trivial.
Presumably switches already report their position to somewhere.
It's absolutely unacceptable for this problem exist in today's world.
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.
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 Google Maps gets wrong what lane I'm in, nobody dies. It can be right 99% of the time, that's good enough. It's not good enough for a train system, though - at least, I suspect it's not. I'd want a lot more than "it works in my car" before I trusted it.
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.
As a passenger, I'm very glad software engineers haven't (fully) taken over aviation and railway safety yet.
I cant recall but maybe a year or two back in ES, a train on one line was derailed around a curve or something and a train at high speed in the opposite direction hit the derailed train.
It seems like a very bad design to have rails that close to each other when for minimum cost they could have significant separation especially when the rails are over open flat ground. Bridges and tunnels of course might be exceptions to this, but over open ground the cost should be low enough that there could and should be separation.
"Reasonably accurate GPS" trying to determine which track you're on at 150 mph is not as simple as you make it sound. Yeah, it can determine how far along the track you are. But when you get two trains moving toward each other, each at 150 MPH, do you really trust that GPS to tell you that they're on different tracks?