A new way of keeping trains apart uses magnetic signals in the tracks(economist.com)
economist.com
A new way of keeping trains apart uses magnetic signals in the tracks
https://www.economist.com/science-and-technology/2022/09/28/keeping-trains-apart-is-crucial-to-safety
80 comments
https://web.archive.org/web/20221001114657/https://www.econo...
> For a 200-metre section, Dr Lauer calculates, there is about one chance in a trillion that it is duplicated anywhere on the 2.3bn kilometres of track currently laid around the world.
Uh, isn’t this the wrong calculation though? We don’t care about the chance of collision between a particular section and any other section, we care about the chance that any pair of sections collide. Birthday paradox stuff.
Uh, isn’t this the wrong calculation though? We don’t care about the chance of collision between a particular section and any other section, we care about the chance that any pair of sections collide. Birthday paradox stuff.
The birthday paradox has a factor for the number of people in the room - the question isn’t usually who else has the same birthday in the entire universe, it’s who else within loud talking distance.
Here restricting the search to a radius of known starting positions should suffice.
Here restricting the search to a radius of known starting positions should suffice.
These sections would be sequential making the search space very small.
I don't think the birthday paradox is exactly the right model either. By itself, a matching fingerprint between two different rail sections on opposite sides of the world wouldn't present a problem, as long as the train knows its initial location and is smart enough to know it couldn't have instantly teleported. You just need a low enough probability of collisions between nearby pairs of track segments in order to not get lost.
But in any case, the statement you quotes smells like very sloppy statistics. There's a huge difference between saying that the pattern of permeability is unpredictable, and saying it's random -- the latter is a very strong assumption. It's easy to imagine ways the measurement could have local or global biases towards particular kinds of patterns, and the existence of any such effects would make the "one in a trillion" number completely meaningless.
On top of that, the article says magnetic permeability isn't part of the official material specifications. What happens if the railroad operator switches to a new supplier, whose process results in rails that are much more uniform?
This seems to be the research group's web page: https://www.mrt.kit.edu/disensor/ I looked for a published paper that would go into more detail, but I couldn't find one.
But in any case, the statement you quotes smells like very sloppy statistics. There's a huge difference between saying that the pattern of permeability is unpredictable, and saying it's random -- the latter is a very strong assumption. It's easy to imagine ways the measurement could have local or global biases towards particular kinds of patterns, and the existence of any such effects would make the "one in a trillion" number completely meaningless.
On top of that, the article says magnetic permeability isn't part of the official material specifications. What happens if the railroad operator switches to a new supplier, whose process results in rails that are much more uniform?
This seems to be the research group's web page: https://www.mrt.kit.edu/disensor/ I looked for a published paper that would go into more detail, but I couldn't find one.
If there were biases, then the pattern of permeability would be predictable. For instance, encrypted data is not random, but it's not predictable.
Just after two trains had crashed at Åsta in Norway back in 2000 or so, a journalist from the Norwegian Broadcasting Company managed to ask the accident site manager whether the trains had been on the same track when they collided.
Long, crushing silence, then. "Presumably, yes."
If I remember correctly, one of the key findings after the accident was that train controllers' only means of communicating with the trains they were supervising was to call the train drivers. On their personal cell phones. It was part of the procedure prior to starting a journey to call in to the central and have the controllers write down the phone number to be used to reach, say, the southbound from Trondheim.
Now we luckily have modern train management systems and GSM-R, but 19 people died at Åsta because the northbound driver seemingly forgot that there was a southbound train on incoming on the track he was going to use - and didn't pay attention to the signal telling him the track was occupied. Then, once the northbound train got going, train control took a couple of minutes to figure out what had happened and then also found out that he couldn't find the note with today's phone numbers.
Long, crushing silence, then. "Presumably, yes."
If I remember correctly, one of the key findings after the accident was that train controllers' only means of communicating with the trains they were supervising was to call the train drivers. On their personal cell phones. It was part of the procedure prior to starting a journey to call in to the central and have the controllers write down the phone number to be used to reach, say, the southbound from Trondheim.
Now we luckily have modern train management systems and GSM-R, but 19 people died at Åsta because the northbound driver seemingly forgot that there was a southbound train on incoming on the track he was going to use - and didn't pay attention to the signal telling him the track was occupied. Then, once the northbound train got going, train control took a couple of minutes to figure out what had happened and then also found out that he couldn't find the note with today's phone numbers.
Wow. That's kind of crazy. Seems like the main failure was the northbound running the signal, though. The lack of radio just means that they had no way to save the situation after the mistake happened.
Nowadays, the train controller can stop a train remotely even if unable to raise the train on the radio.
Still baffles me how packed the old system was with failure modes, though.
Still baffles me how packed the old system was with failure modes, though.
What system do they use for this? I’m not aware of any remote-stop functionality outside of driverless railways but that’s not to say it doesn’t exist.
I only know what i've read about it in the papers, but I think the concept was that the trains and track are fitted with instrumentation enabling the train controller to see in real time exactly what segment of track any train is on at the moment; he will then periodically authorize a train to occupy the X next segments. Presumably the system is interlocked so that it is impossible to authorize two trains to occupy the same segment at the same time.
If a train finds itself on a segment it has not been authorized for, it stops - regardless of what the driver thinks of the matter.
If a train finds itself on a segment it has not been authorized for, it stops - regardless of what the driver thinks of the matter.
That system is track circuitry that uses relays to detect rolling stock when they short the two rails via their wheels. That exists widely, and it identifies that rolling stock is present in a track section. That same relay also locally (as in, on the ground at that location) triggers any signals to switch to red.
Controllers can’t then give authorisation to another train to enter that section, nor can they override any red signal. In cases where it applies, they also can’t remotely control track switches to enter this occupied section. However there’s nothing with that system that then controls the rolling stock itself, so a driver can still SPAD if they don’t see or ignore the red, and the remote network controller absolutely cannot stop a train that is hurtling towards an occupied section. That’s all on the driver in the cab.
Fun fact: track clips are used by track gangs to short these sections in lieu of a big axle sitting on it, which is one of the methods of providing site control to the gangs so trains don’t enter their worksite. It’s certainly not the only one, though.
Controllers can’t then give authorisation to another train to enter that section, nor can they override any red signal. In cases where it applies, they also can’t remotely control track switches to enter this occupied section. However there’s nothing with that system that then controls the rolling stock itself, so a driver can still SPAD if they don’t see or ignore the red, and the remote network controller absolutely cannot stop a train that is hurtling towards an occupied section. That’s all on the driver in the cab.
Fun fact: track clips are used by track gangs to short these sections in lieu of a big axle sitting on it, which is one of the methods of providing site control to the gangs so trains don’t enter their worksite. It’s certainly not the only one, though.
I googled around a bit out of curiosity, and it appears the remote control is indirect - the train controller can override a green signal to red. (Presumably not the other way around!)
All trains have instrumentation which will cause them to stop if they pass a red signal.
The gritty details appear to be in the Togframføringsforskriften, however this has been repealed a couple of years ago, presumably to bring us in line with EU regulations - but I am too tired to try to figure this out tonight, though I have always been a sucker for figuring out how signalling systems work...
All trains have instrumentation which will cause them to stop if they pass a red signal.
The gritty details appear to be in the Togframføringsforskriften, however this has been repealed a couple of years ago, presumably to bring us in line with EU regulations - but I am too tired to try to figure this out tonight, though I have always been a sucker for figuring out how signalling systems work...
Yup, any controller can set a signal to red (that’s how we do track blocks, said clips are the backup to that because you always want the dude in the sky to know you’re there).
Not all trains have kit to stop a SPAD, unless you meant specifically in the instance of the operator involved in this incident. Some do, but it’s absolutely not universal around the world. For example, Automatic Train Protection (ATP) can do this, but it requires both a track-side magnet and the rolling stock to have the kit for it. We use that to trigger our driver vigilance system acknowledgement when approaching suburban passenger stations. Failure to acknowledge the vigilance prompt will throw the brake to emergency and stop the train.
That said, it’s absolutely not present out in the Wild West of freight (because maintaining that many ATP magnets is insanely prohibitive).
Not all trains have kit to stop a SPAD, unless you meant specifically in the instance of the operator involved in this incident. Some do, but it’s absolutely not universal around the world. For example, Automatic Train Protection (ATP) can do this, but it requires both a track-side magnet and the rolling stock to have the kit for it. We use that to trigger our driver vigilance system acknowledgement when approaching suburban passenger stations. Failure to acknowledge the vigilance prompt will throw the brake to emergency and stop the train.
That said, it’s absolutely not present out in the Wild West of freight (because maintaining that many ATP magnets is insanely prohibitive).
For information specific to Norway (in Norwegian) there is a lot here:
https://trv.banenor.no/wiki/Forside
https://www.jernbanekompetanse.no/wiki/Forside
https://trv.banenor.no/wiki/Forside
https://www.jernbanekompetanse.no/wiki/Forside
This is a bafflingly casual regard to safety, with not even a token based system to grant access to a particular section of track. The problem that caused this accident was solved in the 1800’s.
Well, the train didn't have the (notional) token, so the signal was correctly at danger. Which is the 1800s solution to the problem (absolute block signaling). And in the 19th century it was also difficult to reach train drivers who passed signals at danger, due to a lack of radios etc., which did cause accidents when signals failed or drivers passed them at danger.
Box-to-train emergency communication was itself definitely a solved problem by the mid 20th century, though...
Box-to-train emergency communication was itself definitely a solved problem by the mid 20th century, though...
The title reminds me of https://en.m.wikipedia.org/wiki/How_to_Avoid_Huge_Ships
Title has since changed but originally it was something like "trains should not be on the same track to avoid collisions"
It's a cute, but impractical idea. It requires materials not to change properties over time, track not to wear, a globally distributed map that is always up to date and consistent.
Trains have very complex odometry on board already. You'd just add this new magnet sensor to the ensemble of sensors already in use to locate the train. Magnetic maps can be updated using reference markers with known positions, e.g. balises, from the data that trains collect.
[deleted]
If the properties are consistent enough, and it's inexpensive to update then it seems not unreasonable at all. They certainly seem to think so.
Each train would have a sensor which would be able to detect changes and update the database. Maps could easily be regional.
If you can update with changes on the fly, then you can propagate errors on the fly as well. There are likely some quite fatal corner cases that could be found the hard way.
It's a good thing we aren't using updated updated-on-the-fly computer systems for controlling powerplants, chemical refineries, trading on finacial markets or driving cars!
Knight Capital updated their your stock algorithms on the fly, instead of properly investigating the cause of failure[1], resulting in a loss of USD$460 Million after unwinding most of the trades with other firms.
[1] https://en.wikipedia.org/wiki/Knight_Capital_Group
[1] https://en.wikipedia.org/wiki/Knight_Capital_Group
This is a pretty cool idea. Trains make a surprising amount of money, so there's probably a lot of money to be made if it increases efficiency. The costs of errors here are measured in lives though, not Jira tickets, so I hope he's done some very careful testing.
I tend to agree that it’s a nifty idea but I think it’s a decade or so too late as the industry settles on ETCS. The legwork to prove ETCS as SIL-rated is done, whereas this has all those uphill battles still to fight and I’m not sure it’ll have the potential advantages to overcome that. You can also approach any of the Siemens/Hitachi/Bombardier/etcs. of the world and have no issue spec’ing for ETCS today.
This does have potential advantages in maybe finding track defects if set up correctly to do so? But that sort of system already exists and is installed on rolling stock, so once again it’s having to overcome the first mover advantage.
This does have potential advantages in maybe finding track defects if set up correctly to do so? But that sort of system already exists and is installed on rolling stock, so once again it’s having to overcome the first mover advantage.
"New"?
What's so new about what seems to be like a common Automatic block signaling? I thought that this was a commonly used thing. Hence a small current on the rails (you can even tap into it and charge your phone).
What's so new about what seems to be like a common Automatic block signaling? I thought that this was a commonly used thing. Hence a small current on the rails (you can even tap into it and charge your phone).
Now i can imagine some rail being reused for a different line and suddenly trains showing up in the old line on screens in the control room.
It might be worse than that. Rail wears, so the signature probably changes with time, even if nobody moves the rail.
Then, in the US, they sometimes use "rail grinders" - specialized trains that literally grind the surface of the rail, in order to remove things like spalling that come from heavy use. That probably changes the magnetic signature, too, a lot faster than regular wear does.
That's not insoluble - re-map after you grind. But it does complicate things somewhat.
Then, in the US, they sometimes use "rail grinders" - specialized trains that literally grind the surface of the rail, in order to remove things like spalling that come from heavy use. That probably changes the magnetic signature, too, a lot faster than regular wear does.
That's not insoluble - re-map after you grind. But it does complicate things somewhat.
[deleted]
Sounds really complex.
Why not just count how many times the wheels turn?
Why not just count how many times the wheels turn?
Wheels slip and their diameter changes which throws out dead reckoning. Counters are also not accurate and will have cumulative error over time.
It’s complex because edge cases like this exist for simpler systems.
It’s complex because edge cases like this exist for simpler systems.
> their diameter changes
To be clear they are not cylinders, but cones (truncated). Do depending on how the train wobbles they will spin differently to travel the same distance even if they don't slip. So you definitely need some method of regular correction if you want accurate measurements.
To be clear they are not cylinders, but cones (truncated). Do depending on how the train wobbles they will spin differently to travel the same distance even if they don't slip. So you definitely need some method of regular correction if you want accurate measurements.
I in fact meant that they wear through quite substantial diameter differences, but yes conical tread will further throw it out.
Train wheels spin. It’s steel on steel
[deleted]
The economist is playing Factorio now.
tl;dr -- fingerprint the magnetic properties of the rails themselves and map accordingly.
This is incredibly clever and I hope this catches on.
This is incredibly clever and I hope this catches on.
Well i'd imagine when they touch, that's kinda bad for safety...
The difficulties with gps seem over stated,
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.
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.
This is hilariously hand-wavey of the complexity and strikes at my frustrations between how most IT engineers see the world vs how real-world engineers do.
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.
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.
IT engineers routinely do that to other fields as well. I'm a doctor and tech guy. The amount of times I have to read the ignorant arrogance of some guy thinking some ML is about to replace doctors... I wish people will just stick to what they know best, and approach other fields with respectful curiosity.
> The amount of times I have to read the ignorant arrogance of some guy thinking some ML is about to replace doctors...
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.
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.
I do have experience using location beacons where GPS isn't available, along with inferring location from other sensors though...
in systems where thousands of lives depend on your design working correctly even in adverse conditions like storms ?
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.
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.
> how most IT engineers see the world vs how real-world engineers do
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...
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...
But computer programming is an enormous field and there are types of programming that look very much like engineering- ie using the laws of science for practical applications. I agree a startup putting up a website isn’t engineering, but if building rockets is engineering (which it surely is) then building the software to safely operate those things is engineering too.
In as much as brushing your teeth is dentistry, yes.
But this is a "tech" problem where signals and switches operating by humans are error prone, and the technology to automate those exists.
The article is about a tech solution and deployment never able to come (in the U.S.)
The article is about a tech solution and deployment never able to come (in the U.S.)
To be fair, «why don’t they just» has also made a lot of startup founders very wealthy over the last 15 years ;)
I’ll cop that, though I’m fairly confident in saying it’s the exception that proves the rule, in that those ones end up knowing the problem space so well that they sort of horseshoe around to seeing new insights others miss.
also, even though some startup founders have become very rich questioning the basics with technology, many more have failed.
> This is hilariously hand-wavey of the complexity and strikes at my frustrations between how most IT engineers see the world vs how real-world engineers do.
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.
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.
This wasn't a "why don't they just" response though because the article does touch on GPS and the issues it poses.
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"
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"
> There’s way more than “a few” dead spots, and what happens if those repeaters fall over?
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.
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.
That is even more hilariously hand-wavey, given you just got smoked for that.
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.
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.
Coincidentally, I have worked with localized location beacons deployed to nationwide chains of stores that help you find the aisle the item you're looking for is on.
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.
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)
[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.
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.
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.
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.
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.
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.
* 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).
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.
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?
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?
>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.
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.
> The difficulties with GPS seem over stated.
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.
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.
> Which Track? Trains don't randomly switch tracks except in yards,
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.
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.
> Track spacing is often much less than the dilution of position,
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 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. >