Comment by matthewmacleod | Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

Parent Full thread

Of course, in reality you can't build safety-critical systems that operate in challenging rail environments by slapping together an Arduino, a GPS receiver, and an IMU and saying "problem solved lol".

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.

To be fair, Brazil has been using GPS-based dispatching for quite a while. While I haven't investigated their implementation in-depth, almost the entirety of the long distance rail network has switched to it and no longer uses wayside signaling, preferring to track entirely via GPS.

Cab footage implies otherwise, at least on freight lines in the Belo Horizonte region operated by MRS Logística. [0] It's anyone's guess how long that remains the case.

[0] https://www.youtube.com/c/MichaelRSilva/videos (captions in Portuguese)

You're correct about MRS. They seem to be the last holdout on a number of lines. I believe almost the entire remaining network is on GPS now.

They should be solved asap. Increasing rail utilization is key to many of the problems we are facing. Rail can move cities, nothing else can do that.

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.

Generally speaking, LIDAR or cameras on trains don’t solve much, because trains’ braking distances (and therefore what they need to “see”) extends for hundreds of meters, sometimes over a kilometer, and around curves, walls, etc. It’s a different problem space.

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.

You can dead reckon speed, location from camera lidar data, just like what they were doing with the magnetic map in the article.

I made no statements that the train would be locally self engineering using the cameras.

If dead reckoning is what you're relying on, you need

* 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.

Lidar on trains has some uses, but you're quite correct that it isn't the primary sensor. However, automating trains on heavy-haul networks like the US & Brazil is a big opportunity.

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).

This is already possible on small isolated networks (I think there are a few heavy haul lines like this in Australia.)

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.

I understand your thinking but don't agree. Automation can indeed be rolled out, as long as it fits cleanly within the existing network. A fully automated train that follows the same rules as non-automated would easily work. The challenge is you can't realize the network fluidity benefits until much later, vs. an all-at-once rollout.

Ay, but there's the rub. It's challenging to do this well at the required level of reliability, and at a cheap enough cost to deploy at scale.

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?

Perhaps you could use fusion of cheaper sensors to provide good enough location information. What is lacking though is the software and regulatory framework to do that. It requires a change in philosophy. In the past you had an ensemble of data that had very good statistical reliability and could be a source of truth. We are moving to systems where individual sources of data lack that reliability due to physical limitations. That is a hard problem to solve. You can see similar issues in aviation.

>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.

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.

Those steps up already exist. The railway I work for has in-cab radios that we routinely measure the signal coverage to confirm minimal black spots, plus there’s also GSM phones (as in, hardwired in the driver’s cab), in all our locos.

I never thought a comment about an Arduino and a few sensors would be taken so literally as a finalized product.

Reply on news.ycombinator.com