There are parallel tracks within metres of one another. Switching yards have tonnes of them and require precise knowledge of what’s in what.
GPS isn’t SIL.
Trains operate in cluttered environments with reflection and echo abound. That causes drift above the separation of tracks.
There’s way more than “a few” dead spots, and what happens if those repeaters fall over?
There’s tonnes of reasons why high tech isn’t used in train safety-critical systems. The fact you suggest an arduino as an appropriate platform for this is frankly absurd and underscores your misunderstanding of the whole issue.
Close enough isn’t good enough. Crashing doesn’t just mean you reboot or reload the program and try again. It means people die.
Edit to add: A good rule of thumb I’ve learnt after 15 years in the game: if you look at the solution to an engineering problem and then start a sentence with “why don’t they just…”, you probably don’t understand the problem well enough.
Don't worry, it will. A bunch of people will die afterwards, but they'll all be poor so noone will care when they look at how much it improved profits.
Most of us have classifiers to tell if a picture is a hot dog or not a hot dog, but we don’t necessarily tell hospitals we’ve solved the problem of early cancer diagnosis.
Reminds me of…
# Programmers: Stop Calling Yourselves Engineers
“It undermines a long tradition of designing and building infrastructure in the public interest … The title ‘engineer’ is cheapened by the tech industry.”
https://www.theatlantic.com/technology/archive/2015/11/progr...
The article is about a tech solution and deployment never able to come (in the U.S.)
This has become glaringly obvious after starting to learn how aviation works and working on getting a PPL. If you know about this tech, it's interesting to ask software engineers to invent something like ILS and see what they come up with. There's a tendency to both underestimate what is needed AND overengineer the solution.
The Arduino comment was not supposed to be taken literally as a production solution.
There's a big difference between "why don't they just" and "these problems spelled it in the article seem overstated"
Presumably, given the 2 sets of analog systems currently in place, you fail safe to the inefficient systems in the article, when a vehicle doesn't know it's location.
Fail-safe systems are notoriously hard to design - what is the truth when one system is wrong? How do you detect that a system is giving the wrong answer (737MAX hardware sensor failure, software working exactly as very carefully designed)? Adding complexity decreases reliability unless some very deep voodoo engineering is applied.
I think you are thinking linearly, that two systems with a 1% failure rate could be put together to make a system with 0.01% failure rate. Bzzzzzzt, wrong, instead you could easily end up with a system with a 5% failure rate.
There are many sources of confounding variables: two systems tend to fail in the same complex corner cases, safety systems tend to have common dependencies (Fukushima tidal wave), and adding complexity to systems adds subtle failure modes.
Disclaimer: I would call myself a software engineer, because my definition of engineering is making good compromises. Other “engineering” disciplines very often work on non-safety critical systems, yet they are still called engineers. And these days software underpins most safety critical systems e.g. you depend somewhat that your CAD software or circuit analysis software returns the correct result, even though software usually disclaims all warranties/guarantees. The designers of the space-shuttle made safety compromises, but that was engineering. SpaceX followed a fail-fast approach, and I think software engineers have been innovating and optimising that methodology for many years (not saying it was invented by software engineers). Engineering for safety is an orthogonal skill to engineering discipline. Edit: wrench on your own vehicle safety systems, and you can’t help but notice multiple potential safety faults, often related to usability fails. Mechanical engineers design with unforeseen safety failure modes. Engineering is a spectrum. Making appropriate good compromises is engineering. Ingroup “engineers” versus outgroup “engineers” is miscategorisation and politics: especially considering the root of the word and that we use the word certified when we want a “real” engineer. https://probablydance.com/2022/09/17/finding-the-second-bug-... is an example of deep software engineering guruness, uncovering heisenbugs in complicated poorly written GNU glibc synchronisation primitives. My considered opinions.
None of the things you have described are "easy problems". In fact, they are pretty difficult! Systems need to be robust, interoperable, reliable, provably correct, fail safely, deal with surprising edge cases, have long service lives, and any number of other challenges.
In any case, all you've really done here is re-invent technology that already exists. In ETCS level 2, for example, the signalling system uses known-location transmitters on the track as references and the train calculates its position in-between using on-board sensors like axle encoders, IMUs etc.
This is just a short article about an interesting new technology for providing the "train position" component of the system by building a magnetic map of the rails. Pretty cool idea – if it's accurate enough, it provides a more robust source of absolute positioning information, which is key to allowing the rollout of realising "moving-block" approaches in which trains' movement authorities are updated in real-time, allowing higher traffic density.
And it's not like nobody's thought about GPS/GNSS either – there have been extensive projects looking into the feasibility of those systems. The Russian ABTC-M system uses GLONASS, and I'm sure some implementations of PTC in the US use GPS. But again, these are difficult challenges incorporating lots of different technology and you don't solve them overnight.
[0] https://www.youtube.com/c/MichaelRSilva/videos (captions in Portuguese)
Many of these things would be solvable by solar powered cameras on 4G/5G/starlink. Vibration sensors in the tracks, transponders in the cars, wheels, engines, etc. We need way more signals than we currently have.
Rail utilization will certainly help at the margins, but only maybe one or two trains an hour. The real meat and potatoes is generally more tracks, and removing conflict points on existing ones.
I made no statements that the train would be locally self engineering using the cameras.
* the last junction you passed and how you exited, and
* number of turns of the wheel.
The issue is that rewiring junctions is very expensive, upgrading trains to be compatible is expensive, etc. Even more so if you cannot upgrade an entire network all at once, and you need to account for mixed operations with both new and legacy compatible systems.
The pressure to reduce crew costs means longer trains and less network fluidity; automating them allows much shorter point-to-point consists on the same infrastructure. As long as they have the right sensors they can run much closer together - even couple & de-couple en route (with some extra equipment).
The issue with networks is that it is impossible to roll out automation all at once, and the intermediate mixed automated/non-automated network is more complex and harder to do safely and reliably.
NYC has been moving to (theoretically automatable) CBTC signaling from mechanical signals. It's been challenging.
* The CBTC and mechanical interface has issues and constantly fails over the entire system
* The mechanical system is itself falling apart because it dates from the '30s, and is so old that the suppliers no longer exist and they source parts either from collectors on eBay or make it themselves, and this is also affecting the first bullet point
* Few modern suppliers of signaling actually sell fixed-block signaling that can handle the capacity required today, and even if they did, would it make sense to spend hundreds of millions or billions on a stopgap to CBTC, which will also cost hundreds of millions or billions?
Since many current systems do not meet those criteria (another comment mentions a “communication system” of writing down the day’s train drivers’ cell numbers on a note), I’d argue that any improvement towards an ideal system is a step up. We can’t wait for perfection.
If anything, they are understated. GPS is so easy to spoof that it should not be used in a vital system.
Most train control systems have two completely separate systems. One keeps trains from running into each other, and the other makes the railroad run efficiently. The first usually depends on brutally simple and fail-safe wayside equipment. The second is based on direction from a control center somewhere. The second system is capable of keeping trains separated on its own, and it's so tempting to get rid of all that wayside safety equipment, with all that gear in trackside boxes needing maintenance visits.
Track spacing is often much less than the dilution of position, which is less than ideal. This means that the area that the GPS thinks the train is, is bigger than the track width. Trains in the UK are often in cuttings, urban canyons etc, which means that the error margin could be up to 100m without much effort.
> instrumenting each switch to understand when a train switches tracks seems like an easy problem.
Only if you ignore that those sensors are now life critical, so is the connection, and the software that joins it all up.
> Tunnels? First there aren't "that" many and there aren't many long enough that a single long train shouldn't count it as occupied in the interest of safety.
again see DoP. But safety distance is related to speed. the slower the trains the shorter the distance, which means you are more likley to bump into GPS DoP issues. Also tunnels normally have cuttings, which again limit the number of satellites visible.
> It also shouldn't be a high effort to add a satellite or wireless repeater with a known location at at least each end of a tunnel.
again see safety critical equipment, you'll need fail safes
> The accelerometer can even early report rough tracks or switches.
Whats the percentage drift per second of those sensors? How often is the calibration frequency? how much vibration can it handle before it becomes inaccurate? whats the mean time to failure?
As a point, the "new" thameslink trains refused to open its doors at the thameslink station, because the station was in a tunnel, and the GPS wasn't available. This meant that the train said it didn't know where it was, so no doors open.
As a general rule of thumb, life critical stuff needs to be simple, well tested and well characterised. Failure of a system might cause a death, subtle failure is even more dangerous. This means expense.
Which is why I spell out to instrument the current reporting switches (which are the current systems (and yes they fail))
> As a general rule of thumb, life critical stuff needs to be simple, well tested and well characterised.
For context, my state leads in railroad crossing deaths, in part because the existing signaling infrastructure is too sparse or dilapidated. >
Which Track? Trains don't randomly switch tracks except in yards, instrumenting each switch to understand when a train switches tracks seems like an easy problem.
Tunnels? First there aren't "that" many and there aren't many long enough that a single long train shouldn't count it as occupied in the interest of safety. It also shouldn't be a high effort to add a satellite or wireless repeater with a known location at at least each end of a tunnel.
An arduino with GPS tracking an accelerometer (or gyro), a compass, add a few wireless location nodes around tunnels and other dead spots and every difficulty here is solved. The accelerometer can even early report rough tracks or switches.
What excuses the economist entertains while we have successful tracking in many other forms of transport.