[HN Gopher] A new way of keeping trains apart uses magnetic sign...
___________________________________________________________________
A new way of keeping trains apart uses magnetic signals in the
tracks
Author : helsinkiandrew
Score : 36 points
Date : 2022-10-01 11:46 UTC (11 hours ago)
(HTM) web link (www.economist.com)
(TXT) w3m dump (www.economist.com)
| bombcar wrote:
| The title reminds me of
| https://en.m.wikipedia.org/wiki/How_to_Avoid_Huge_Ships
| msbarnett wrote:
| > 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.
| teraflop wrote:
| 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.
| ColinWright wrote:
| https://web.archive.org/web/20221001114657/https://www.econo...
| [deleted]
| Stevvo wrote:
| Sounds really complex.
|
| Why not just count how many times the wheels turn?
| FredPret wrote:
| Train wheels spin. It's steel on steel
| NamTaf wrote:
| 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.
| kevincox wrote:
| > 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.
| lowbloodsugar wrote:
| The economist is playing Factorio now.
| just_boost_it wrote:
| 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.
| NamTaf wrote:
| 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.
| smileysteve wrote:
| 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.
| NamTaf wrote:
| 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.
| zokier wrote:
| https://en.wikipedia.org/wiki/European_Train_Control_System#.
| ..
| smileysteve wrote:
| 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"
| olivermuty wrote:
| To be fair, <<why don't they just>> has also made a lot of
| startup founders very wealthy over the last 15 years ;)
| NamTaf wrote:
| 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.
| jen729w wrote:
| > 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.
| ..
| smileysteve wrote:
| 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.)
| smileysteve wrote:
| 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.
| smileysteve wrote:
| > 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.
| naijaboiler wrote:
| 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.
| smileysteve wrote:
| I do have experience using location beacons where GPS isn't
| available, along with inferring location from other sensors
| though...
| matthewmacleod wrote:
| 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.
| FredPret wrote:
| >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.
| NamTaf wrote:
| 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.
| kposehn wrote:
| 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.
| smileysteve wrote:
| I never thought a comment about an Arduino and a few sensors
| would be taken so literally as a finalized product.
| sitkack wrote:
| 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.
| bobthepanda wrote:
| 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.
| sitkack wrote:
| 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.
| kposehn wrote:
| 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).
| bobthepanda wrote:
| 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.
| KaiserPro wrote:
| > 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.
| smileysteve wrote:
| > 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. >
| Animats wrote:
| > 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.
| pestatije wrote:
| 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.
| AnimalMuppet wrote:
| 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.
| pstuart wrote:
| tl;dr -- fingerprint the magnetic properties of the rails
| themselves and map accordingly.
|
| This is incredibly clever and I hope this catches on.
| ChildOfChaos wrote:
| Well i'd imagine when they touch, that's kinda bad for safety...
| lb1lf wrote:
| Just after two trains had crashed at Asta 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 Asta 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.
| AnimalMuppet wrote:
| 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.
| lb1lf wrote:
| 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.
| NamTaf wrote:
| 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.
| lb1lf wrote:
| 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.
| NamTaf wrote:
| 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.
| lb1lf wrote:
| 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
| Togframforingsforskriften, 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...
| zidel wrote:
| For information specific to Norway (in Norwegian) there
| is a lot here:
|
| https://trv.banenor.no/wiki/Forside
|
| https://www.jernbanekompetanse.no/wiki/Forside
| NamTaf wrote:
| 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).
| Tsiklon wrote:
| 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.
| pmyteh wrote:
| 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...
___________________________________________________________________
(page generated 2022-10-01 23:00 UTC)