[HN Gopher] SimSig: Railway Signalling Simulations
___________________________________________________________________
SimSig: Railway Signalling Simulations
Author : untilted
Score : 176 points
Date : 2024-07-10 09:02 UTC (13 hours ago)
(HTM) web link (www.simsig.co.uk)
(TXT) w3m dump (www.simsig.co.uk)
| cybrox wrote:
| This is really cool!
|
| For people who don't want to go full scale sim and prefer a bit
| of a lighter interpretation of working with signalling screens, I
| can recommend Rail Route
| (https://store.steampowered.com/app/1124180/Rail_Route/).
| fragmede wrote:
| For people that want a railway simulator that includes game
| mechanics to drive a lot of complexity, try Factorio.
| 8372049 wrote:
| Or OpenTTD
|
| https://www.openttd.org
| loa_in_ wrote:
| Especially a fork called JGR's patchpack, featuring
| programmable signals and so much more.
| gsck wrote:
| Pretty sure the developers of Factorio made a train game
| based around the train system in Factorio. Can't for the life
| of me remember its name but it looks rather good
| chin7an wrote:
| Is it Sweet Transit? The about section mentions that the
| developer was part of Factorio.
|
| Edit to add link - https://www.sweettransitgame.com/
| gsck wrote:
| Yes, that's the one. Never played it, but from my
| understanding its effectively just the train system
| lifted out of Factorio with a game built around it.
| Cthulhu_ wrote:
| It even looks like the rail assets were lifted straight
| from Factorio. I mean if it's all above board it's fine -
| Factorio's train system is really good.
|
| That said, they're also giving it major updates/overhauls
| in the upcoming update, so this one would be falling
| behind if there's no good relationships between the two.
| TylerE wrote:
| He was one of the graphics contractors not a dev.
|
| It is not very good. The game design is just and, failing
| to be either a good train sim or an interesting strategy
| game.
|
| It basically flopped in early access.
| wiz21c wrote:
| first paragraph on home page is really funny and alluring : "...
| How often has your train been delayed because of "signal failure"
| and you've wondered why trains can't be routed around the problem
| - or why it is even a problem in the first place? You'll soon see
| exactly why - with SimSig!"
|
| really resonates with my experience as a commuter
| rwmj wrote:
| Memories of playing _Heathrow Air Traffic Control_
| (https://www.spectrumcomputing.co.uk/entry/2270/ZX-Spectrum/H...)
| 8372049 wrote:
| Nowadays you can do virtual ATC work in VATSIM and IVAO,
| controlling airspace for flight sim players.
| nateguchi wrote:
| See also: https://signalmaps.co.uk/#gwml1:1627
|
| Live signal maps in the UK
| amouat wrote:
| Also traksy e.g:
| https://traksy.uk/live/T+EDB+KGX+d+@2024-07-10T13:00/M+1+EDI...
| class700 wrote:
| There's also OpenTrainTimes
| https://www.opentraintimes.com/maps/signalling/wat#T_WATRLMN
|
| And https://www.realtimetrains.co.uk/ for precise
| times/platform information.
| marksomnian wrote:
| And https://www.map.signalbox.io/, which tries to
| interpolate signal locations onto a geographic map (with
| the expected level of inaccuracy, though still not half-
| bad)
| londons_explore wrote:
| Railway signalling IMO is an area where a little research could
| _dramatically_ increase the throughput of the railway network
| with a rather low cost.
|
| Todays railways mostly use fixed block signalling. Expensive and
| unreliable equipment ensures that there is only one train on each
| 'block' of railway track at the same time. That forces trains to
| be at least 1 or 2 blocks apart, which are frequently multiple
| miles long. End result: Trains are usually 10's of minutes apart,
| or at least 1 minute apart even in urban subway systems.
|
| A more advanced system would aim to have trains as close together
| as cars are on a freeway. Trains would be able to hitch and
| unhitch whilst moving 100 mph, allowing different loads to be
| sent different directions and different sets of passengers to
| stop at different stations. Crashes would be avoided by having
| every train know about the train ahead and behind, and unable to
| make any move which would cause a collision (ie. it is not
| allowed to slam the brakes on if there is a train right behind
| you).
|
| Such a system would be implemented primarily on the _trains_ ,
| and primarily in _software_. Software is expensive to develop
| then cheap to replicate, a property very important if you want to
| deploy it widely.
|
| It would be backwards compatible with fixed block signalling by
| simply saying that within each existing fixed block there is
| _either_ one legacy train, _or_ an unlimited number of gen 2
| trains who will all communicate with eachother (and any train who
| cannot communicate with every other train within the block is not
| allowed to enter the block).
|
| Hardware/software failures are kept safe by simulating every
| possible type of failure (ie. braking, locomotion, power, derail,
| position uncertainty, comms), and every second generating a plan
| which will be executed by every train in case of each type of
| failure occurring. Any move any train wants to make where any of
| the above plans cannot be generated with a safe outcome isn't
| allowed.
| dividuum wrote:
| > A more advanced system would aim to have trains as close
| together as cars are on a freeway.
|
| https://en.wikipedia.org/wiki/European_Train_Control_System#...
| londons_explore wrote:
| This still doesn't allow train spacing of less than the
| braking distance. Braking distance of trains is large (due to
| high uncertainty in track friction), which still means trains
| are typically 1 minute or more apart when moving fast.
|
| As long as you have comms with the trains around, it's
| clearly possible to safely go less than the braking distance,
| as long as you can be sure of the behaviour of the train
| ahead, even in the case of an equipment failure (ie. in case
| of a power failure, it will not slam the brakes on, but
| decelerate at X m/s^2).
| pixiemagic wrote:
| What happens if there's some other reason to brake, such as
| an unreported fallen tree on the line ahead?
| londons_explore wrote:
| You can still brake - you just need (automatic) agreement
| of all trains behind you to do so.
|
| You aren't allowed to brake 'as much as possible' anymore
| - instead the best you can achieve is 'the best the worst
| of the trains behind me can achieve'.
| garaetjjte wrote:
| If one train derails for some reason, then _every single_
| train on the line crashes in the greatest pileup ever.
| Great.
| londons_explore wrote:
| Thats already the case for carriages within a train....
| And people are fine with it.
|
| We're also fine with the risk of a derailment onto a
| neighbouring track with traffic going the opposite
| direction. We could have tech which detects that, but we
| do not.
| lqet wrote:
| > And people are fine with it
|
| The thing you are missing is compartmentalization. A
| modern high-speed train can hold around 1,000 people.
| This is the maximum number of people that could die in an
| accident (ignoring trains on other tracks or people next
| to the tracks). What you are proposing is essentially a
| train of infinite length, with virtual (software)
| coupling between groups of carriages. But then there is
| no limit to the maximum number of deaths in an accident.
| If you have 50 high-speed trains all traveling in this
| virtually coupled manner, a single accident may cause
| 50,000 casualties. People would not accept this, and no
| sane policy maker would allow it.
|
| Note that if you consider derailments into neighboring
| tracks, you still have an upper limit of 2 times maximum
| train capacity, in our example 2,000.
| corobo wrote:
| A train derailing onto another track would be a hell of a
| derailment
|
| Take this incident for example
| https://www.bbc.co.uk/news/uk-england-surrey-68466494
|
| Imagine that then resulted in "the following train then
| slammed into the derailed train, having been unable to
| stop in time"
| rjmunro wrote:
| It happened at the Clapham Junction rail crash in 1988:
| https://www.bbc.co.uk/news/uk-england-london-46509473
|
| A total of 3 trains were involved.
| corobo wrote:
| Oh wow, I was 6 months old when that happened. (36y/o
| now)
|
| Pretty decent track record if that's the most recent
| example!
|
| Upping the ante: how much worse would that have been if
| there were trains following closer than braking distance
| in both directions.
|
| Special note that the train derailed so severely in this
| incident after colliding with a train stopped in front of
| it.
|
| I'm even less of a fan of OP's "braking distance shmaking
| distance" proposal with this example of why it's a bad
| idea!
| blibble wrote:
| one of the original tube line ATO systems allowed a train
| to enter a platform as another was departing
|
| people did not seeing this and the system was modified to
| not do it
| danhor wrote:
| You could also characterize the maximum braking ability
| of the train in front of you and the minimum braking
| ability of your own train and determine the needed
| distance for any given speed based on that. This would of
| course be more complicated and probably be solved by only
| including broad categories of trains (i.e. only two sets
| of values for either passenger trains or freight trains).
| TylerE wrote:
| You also would need to consider the braking ability of
| the train BEHIND you.
| rjmunro wrote:
| As soon as one train brakes, the train behind should
| automatically brake. The separation distance can be
| maintained. The problem is if the first train hits an
| object or derails, this might cause it to slow down
| faster than the brakes would have done, and the following
| train may not have time to stop.
| mezmor wrote:
| Aren't braking distances so large because of the massive
| amounts of mass in motion? Inertia, etc. Even high
| certainty of track friction wouldn't change that.
|
| Also, I don't think it's ever safe to be closer than
| braking distance because the bahavior of the train ahead is
| never guaranteed. There's always a chance somebody parks
| their car on a rail crossing or some other sudden stopping-
| event occurs.
| thanzex wrote:
| I think that's not something that can be avoided,
| unfortunately. Any number of things could cause a train to
| suddenly stop. A mechanical failure, derailment, collision,
| a wagon could get detached... On roads we have millions of
| vehicles, carrying on average a very small amount of
| people, around 1.5. For efficiency sake we have accepted
| the risk of staying within _reaction_ distance instead of
| _stopping_ distance between vehicles.
|
| It is a tradeoff between the safety of lives on board and
| traffic requirements that is relatively easier to accept
| when the average number of people involved is low against
| massive speed and efficiency gains.
|
| The same cannot be said for trains though. Modern trains
| carry upwards of 1000 passengers, often at high speeds and
| without all of the safety and retention systems built into
| modern cars.
|
| Having one or multiple trains with this large amount of
| people onboard be involved in a sudden catastrophic
| accident is possibly not worth the efficiency gained by
| thess than one minute separation.
|
| Unfortunately we cannot just think about a normal scenario
| of simple deceleration
| sneak wrote:
| > _On roads we have millions of vehicles, carrying on
| average a very small amount of people, around 1.5. For
| efficiency sake we have accepted the risk of staying
| within reaction distance instead of stopping distance
| between vehicles._
|
| No. Unsafe drivers have illegally decided this, but in
| most jurisdictions it is your responsibility to stop your
| vehicle short of the one in front of you. You should be
| maintaining stopping distance from your vehicle to the
| one in front.
| lqet wrote:
| > You should be maintaining stopping distance from your
| vehicle to the one in front.
|
| I am not so sure. In Germany, for example, the minimum
| required distance to the car in front of you is "speed in
| km/h divided by 2 in meters". So for 100 km/h, you are
| required to keep a minimum distance of 50 meters. I very
| much doubt that you can stop a car going 100 km/h within
| 50 meters.
| whartung wrote:
| You do t need to stop a 100 km/hr car in 50 meters
| because, barring that sudden brick wall appearing ahead
| of the car in front of you, they're not stopping in 50m
| either.
|
| The 50m is the reaction buffer, not the stopping buffer.
|
| It's also prudent to give more leeway to vehicles you can
| not see around to avoid the large truck swerving to avoid
| the refrigerator that just fell out of the truck in front
| of them problem.
| corobo wrote:
| At least with cars they also have the option to swerve
| away from the chaos if the stopping distance is too
| short.
|
| Not to disagree, just throwing in a variable that trains
| don't have
| andruby wrote:
| That's interesting, in Belgium I think it's "2 seconds",
| or at least that's what was promoted recently on the
| radio.
|
| You should be able to sing "Last night a DJ saved my
| live", which is a bit more than 2 seconds. I liked that,
| because it's one you can actually test for while driving.
|
| I find it a lot harder to estimate 50m while driving at
| 100km/h
| thanzex wrote:
| Not really. In my country, at least, it is explicitly
| stated in driving theory manuals to maintain at least one
| reaction distance between the car in front of you.
|
| For a car traveling at 100Km/h the stopping+reaction
| distance would mean more than 130m, which is a quite
| large and possibly impractical for higher traffic
| scenarios.
| lqet wrote:
| It is not safe. If your train crashes into a truck, or
| derails, or explodes, all trains behind will crash into it
| if they are nearer than their own breaking distance. This
| is not possible in a classic block system: the block is
| freed _only_ when the last carriage of the blocking train
| has left the block.
| TylerE wrote:
| That's a metric crapton of ifs. I would never get on such a
| system, it is fundamentally unsafe.
| andbberger wrote:
| this is decidely a feature and not a bug. CBTC systems work
| by continually updating track leases to the last known
| position. this allows for high throughput while safely
| avoiding collisions in case of catastrophe.
|
| highway separation is unacceptable for anything other than
| trams (which are slow and have track brakes). the path to
| safely increasing throughput is to increase braking
| performance and minimize dwell time. existing systems eg
| paris line 14 and the tokaido shinkansen have very high
| throughput.
|
| transit projects would look even better compared to
| highways if they had to be safe too!
| kqr wrote:
| > Crashes would be avoided by having every train know about the
| train ahead and behind, and unable to make any move which would
| cause a collision (ie. it is not allowed to slam the brakes on
| if there is a train right behind you).
|
| Note that with any latency in the system, they need to consider
| not just the train behind, but /several/ trains behind:
| https://two-wrongs.com/keep-a-safe-following-distance.html
| p_l wrote:
| Moving block systems are not really new, they just aren't
| distributed widely.
| londons_explore wrote:
| Moving block doesn't allow trains to get closer together than
| the braking distance. This would.
| bluGill wrote:
| There is good reason they don't do that: trains derail once
| in a while, your plan means the following train will hit
| that train and so the accident is worse.
|
| Part of the answer to that is better track maintenance.
| However that isn't a perfect answer and so we need larger
| gaps.
|
| Note that cars on the freeway are normally much closer
| together than is safe as well. If cars maintained a safe
| following distance we would need 5 times as many lanes.
| (you know the massive freeways in Huston that urbanists
| like to show as bad: that is about the correct size of
| freeway for Des Moines, Huston needs many more if they want
| to be a car oriented city)
| TylerE wrote:
| Saying trains should be closer than braking distance is
| like saying with devs shouldn't support https. It's
| something no expert in the field wound agree with.
| secondcoming wrote:
| > Crashes would be avoided by having every train know about the
| train ahead and behind
|
| Isn't this a block system?
|
| > it is not allowed to slam the brakes on if there is a train
| right behind you
|
| So if we have three trains in close succession and the first
| derails or loses power, the second is not allowed stop because
| there's a train behind it?
|
| > Trains are usually 10's of minutes apart, or at least 1
| minute apart even in urban subway systems.
|
| At least on the London underground it isn't unheard of for the
| next train to be arriving in 1 minute. Most delays are caused
| by passengers, not infrastructure.
| euroderf wrote:
| AFAIK the underground is not beset with blockages caused by
| fallen trees and stalled automobiles.
| secondcoming wrote:
| It does have its fair share of 'people under a train' and
| people preventing doors from closing.
| cmul wrote:
| Which is why ATO (automatic train operation) is most
| often found in subways where the platforms can be
| equipped with gates to keep passengers out until a train
| has stopped safely. Suicide by train and level crossings
| are a nightmare in risk management for railway safety,
| hence also (new) high speed tracks are usually planned
| without any intersections with roads or paths, at
| respective additional costs.
| marksomnian wrote:
| Some lines on the London Underground do use ATO without
| platform barriers. The driver closes the doors, checks
| that the platform is clear, then starts the train. ATO
| takes over until the next station, where the driver
| watches to make sure there's nobody too close to the
| edge, ready to slam on the emergency brake.
| londons_explore wrote:
| > So if we have three trains in close succession and the
| first derails or loses power, the second is not allowed stop
| because there's a train behind it?
|
| The second is allowed to follow the 'train ahead derailed'
| plan, which presumably will involve stopping at a rate that
| the third train can also achieve.
|
| If comms is maintained during the event, new plans can also
| be made that are maybe better (eg. maybe try to brake harder
| than the guaranteed minimum braking)
| corobo wrote:
| Instead of a derailed train and a couple delayed trains you
| now have a derailed train and a couple of trains with flat
| wheels that also need clearing up (assuming they avoided
| slamming into each other)
|
| Definitely not sold on the "let's chuck out the failsafe
| method of railwaying" idea, haha
| trainyperson wrote:
| The 1-minute (or less) headways on London Underground are
| precisely because of signal modernization over the past
| couple decades that has moved certain lines beyond purely
| fixed-block signaling.
| trainyperson wrote:
| Much of what you're describing (besides the live hitching and
| unhitching) is made possible by Communication-Based Train
| Control (CBTC) [see link below]. This has been implemented in
| many rail systems globally, mostly urban rail. It helps reduce
| headways _a lot_. However:
|
| 1. It's not just a software problem - installing the hardware
| is time-consuming and expensive. The engineering requirements
| are much stricter when human lives are at stake so you can't
| just strap on a radio to each train. You still need additional
| infrastructure along the tracks to manage communications.
|
| 2. There are other limiting factors in reducing headway -
| having enough trains and having enough train operators.
| Somewhat easier to solve perhaps but still costly and non-
| trivial.
|
| ------
|
| https://en.wikipedia.org/wiki/Communications-based_train_con...
| TylerE wrote:
| Urban systems are generally single-user networks, which makes
| life a lot easier. For main line railways that assumption
| doesn't hold, which is where things kinda fall apart.
|
| It's a bit like the old copypasta from the slashdot days of
| "This is why your solution to spam won't work", where one of
| the options was "It requires the entire internet to change at
| once.
|
| Just look at what a big deal in the US it was to get positive
| train control (PTC) installed nationally.. and that's a much
| simpler system that is basically local (Picks up info from
| relays in the track, but all the logic is in the locomotive).
| Cthulhu_ wrote:
| This puts a LOT of faith / confidence in and requirements on
| hardware and communications; while it all sounds good on paper
| / in your head / in theory, there's going to be a ton of
| practical issues that someone more qualified than me will be
| able to list.
|
| It's got the same energy as Musk advocating for Hyperloop
| and/or car tunnels by amortizing all the practical, cost,
| engineering, legal and safety considerations. Sure, in theory a
| maglev train in a vacuum tube is super fast, but in practice
| building the infrastructure is prohibitively expensive and
| there's not a big enough market for it.
| londons_explore wrote:
| The market for people transport is huge. Imagine the cost of
| all apartments in manhattan @ $3000/sq foot. Now imagine the
| cost of the same apartments built in upstate new york @
| $250/sq foot.
|
| A transit provider who can get people from a house in a rural
| area to manhattan in 15 mins can pocket that difference,
| which is _huuuuge_.
| bluGill wrote:
| > Imagine the cost of all apartments in manhattan @
| $3000/sq foot.
|
| Does such a thing exist? A tiny bathroom is 25sq feet - or
| $75000. That just seems too much.
|
| Zillow lists studio apartments in Manhattan for
| $3000-$5000/month. They also list apartments in New Jersey
| for $250/month just 30 miles away (1 hour drive to
| Manhattan according to maps). At that distance we don't
| need fancy hyperloop, we just need good higher speed rail
| service easially done with existing technology. (I have no
| idea how the apartments compare other than price - likely
| the Manhattan ones are much nicer for the same amount of
| space and the New Jersey neighborhood may be unsafe)
| NovemberWhiskey wrote:
| $2,000 to $3,000 per square foot is absolutely the asking
| price for condos in parts of New York like Tribeca and
| Soho.
| cmul wrote:
| Imho, the major constraint for railways in most countries is
| policy, not technology. In the US and many large (surface area)
| countries, railways primarily serve for freight transportation
| and, to a shockingly underdeveloped degree, local commuters. In
| Europe legacy solutions and differences of national systems,
| planning guidelines and even power grid cause problems. Some
| nations' railways are extremely underfinanced and have been
| driven to the brink of collapse in the privatizations of the
| early 90s with more than 30 years of missed investments. The
| rollout of ETCS tries to remedy that and so do ERA/EUG/ERJU but
| the coffers of many nations are rather empty/respectively other
| interests weigh higher (subsidies for streets, automotive
| companies, aviation and other big buckets like farming).
| jcranmer wrote:
| There are two things that control the ruling headway on a
| subway system. The first is platform dwell time. While a train
| is stopped at a station, you cannot let another train move into
| its position as if it was going to start moving on schedule,
| because it's actually quite likely that it _won 't_. Given that
| platform dwell time is about 30s, and taking into account time
| needed to decelerate and accelerate to/from a stopped position,
| this limits minimum headways to about 1m.
|
| Similarly, switch fouling time is another constraint: you don't
| want to move a switch while a train is allowed to path over it,
| in case the switch fails to switch. From what I've heard of
| existing urban systems, this leads to a minimum headway of
| ~90s, although I don't know how much of that is signal-induced
| padding.
|
| The next thing to point out is that these are theoretical
| maximum density; the practical maximum operational usage is
| generally far less. Most subway systems have the physical
| capability of operating ~45TPH on a subway line, yet you'll
| notice that extremely few do. Moscow Metro has managed 40TPH on
| an unbranched line; branched lines struggle to get to 30TPH,
| and heavily reverse-branched systems like the DC Metro or NYC
| Subway struggle to make even 20TPH. Introduce branches into the
| mix, and you need trains to make it onto the mainline in slots,
| and there's going to be variance in arrival time because the
| system is used by humans; reverse branches makes the problem
| worse because these slots need to line up well on multiple
| lines at the same time.
|
| > Trains would be able to hitch and unhitch whilst moving 100
| mph, allowing different loads to be sent different directions
| and different sets of passengers to stop at different stations.
|
| No. There's a reason railroads have banned the practice of
| unhitching at speed (it's incredibly dangerous), and hitching
| is even worse. And if you're talking about EMU passenger train
| sets, most of them are designed to not be hitched or unhitched
| particularly frequently--these aren't your standard automatic
| coupler system (which doesn't couple brake lines or electrical
| lines or other things automatically anyways, FWIW).
| danhor wrote:
| > and heavily reverse-branched systems like the DC Metro or
| NYC Subway struggle to make even 20TPH.
|
| I find this really interesting that is seems to be the limit
| for "big-boy" complicated subway systems, while there are
| many very complicated smaller systems that achieve much more.
| For example, a lot of the german Stadtbahn systems run
| somewhat long trains (up to 80m), run using conventional
| signalling systems underground (so not on-sight, which would
| allow for a much higher throughput). Naively I'd assume the
| tram-style segments and frequent at-grade crossings would
| make this much worse, but apparently not.
|
| For example, Stuttgart
| (https://download.vvs.de/Stadtbahn_Liniennetz.pdf, https://gl
| eisplanweb.eu/show.php?Map=Stuttgart&Index=1&Heigh...)
| currently runs 27 tph between Stadtbibliothek and Olgaeck,
| with plans to run 30 tph without any upgrades, and 30 tph
| between Staatsgalerie and Stockach (additionally even running
| the U11 for events) without any significant issues and quite
| a complex network with many flat junctions outside the
| underground sections. The DC Metro has much less complicated
| branching/reverse-branching patterns.
| TylerE wrote:
| Trams often have rubber tires, which gravely increases
| acceleration and braking.
|
| Also, 80m isn't that long. Trains on the the DC metro are
| pushing 200. 8 cars long.
| danhor wrote:
| > Trams often have rubber tires
|
| No, they don't. There are a handful of weird french
| systems (and even less outside of France), but there are
| more ruber-tire metros than trams, I'm sure. They are
| rare and have been getting rarer.
|
| 80m is in the lower half for metros, but long in the
| context of systems having on-street portions (exceeding
| the german legal limit of 75m with a special exception).
| It's also on the long end for small metro systems.
| TylerE wrote:
| The Stuttgart system is light rail, not a tram. Big
| difference.
| TylerE wrote:
| That isn't how trains work. They take miles to stop.
|
| Being able to stop any train on the network without risking it
| running in to another is not negotiable.
| divingdragon wrote:
| > Crashes would be avoided by having every train know about the
| train ahead and behind, and unable to make any move which would
| cause a collision (ie. it is not allowed to slam the brakes on
| if there is a train right behind you).
|
| You are assuming that a train will never have to suddenly stop.
| This will never fly in the real world. Even if you consider a
| completely closed railway system with no possibility of
| external obstructions, there are many kinds of failure that
| would cause modern trains to apply emergency breaks due to
| fail-safe designs.
|
| If you remove the bit about not allowing to slam on the breaks,
| then you just described SelTrac. Even the first version used on
| the Vancouver SkyTrain (opened in the 80s) is capable of
| running trains closer than braking distance from what I
| remember reading. I don't believe it is actually enabled on
| many SelTrac systems though, because you still need to have
| safety margins. There is always the possibility that the train
| in front may decelerate at a rate higher than its emergency
| braking rate, like if it derailed or collided with external
| obstructions.
| bryananderson wrote:
| As others have pointed out, most of this is a good idea and
| already exists in the form of moving-block communications-based
| train control which is used all over the world.
|
| The parts that don't exist--traveling closer than the stopping
| distance and hitching/unhitching at speed--are not good ideas
| unfortunately.
|
| You can't travel closer than the stopping distance because you
| can't guarantee that the train ahead will stop at its own
| achievable stopping distance. If you could, you could do as you
| describe, and have the next train start braking instantly when
| the one ahead brakes. But striking an unexpected obstacle
| and/or derailing can cause the train ahead to stop quite a bit
| more abruptly than that! If the train ahead suffers some kind
| of violent failure, it could leave sizable debris and/or track
| damage at the point of the event, even if most of the train
| continues along for some distance. So, even with moving-block
| CBTC, you must _always_ be capable of stopping before reaching
| the current location of the train ahead of you.
|
| Anyway it is not really necessary to travel so closely
| together, because the limiting factor of throughput is station
| dwell time. Sure you could have huge throughput on a line with
| no stations if you could theoretically travel at car-on-highway
| spacing, but if you have stations and they can only serve one
| train at a time, you won't gain anything by doing this. You can
| improve this by having a platform with a track on each side so
| you can load two trains at once (and this is pretty common when
| dwell time is really long and throughput must be high, i.e. for
| intercity trains on a busy line), but that is the best you can
| do. You can't really scale this to a bunch of platform tracks
| because you'll start to have merging conflicts when rejoining
| the track.
|
| The problem with unhitching at speed follows naturally from the
| problem with close following: the moment you unhitch, you are
| now following too closely behind another train, and you cannot
| stop in time if something bad happens to it.
| cmul wrote:
| For German speakers: https://www.estw-simulator.de/index.html
| https://www.estwsim.de/cms/index.php
|
| These have been around for a while and quite closely mimic
| (slightly older) German signalling specifications for signaller
| interfaces.
|
| My company builds such systems as test and demonstration systems
| for real railway projects with respective functional safety
| constraints. If you're interested to learn more about the
| signalling infrastructure in Europe or Germany, feel free to ask.
| shagie wrote:
| Also in the German train signaling ...
| https://www.eisenbahnbetriebsfeld.de
|
| A Tom Scott video on it - The world's most useful model railway
| https://youtu.be/6TLcaJdsRr0
| 0xTJ wrote:
| This is the sort of simulation/game, like Dwarf Fortress
| (especially older versions) where I don't have the slightest idea
| what's going on, or how to make things happen, but am still
| having plenty of fun.
| Animats wrote:
| My favorite simulator for railway signals is NXSYS.[1] This
| simulates General Railway Signal's NX system down to the relay
| level. NX had the first "intelligent user interface" device. When
| a train enters the interlocking, the dispatcher pushes an entry
| button to indicate they want to dispatch that train. All the
| possible exit points then light up. The dispatcher then pushes
| the button at the appropriate exit light, and all the signals and
| switches are set up for that route.
|
| Routing within the interlocking is automatic. Exit lights only
| light up if there's an available path. The system is aware of
| trains in the interlocking, switches locked for maintenance, and
| the actual position of switches, signals, and train stop devices.
| As a train moves through the interlocking, track space and
| switches are released behind it automatically, becoming available
| for other trains.
|
| Today this seems routine, but it was a huge breakthrough in the
| 1930s. The original marketing brochure is available online.[2]
|
| [1] https://bernardgreenberg.com/Subway/
|
| [2] https://anyflip.com/lbes/vczg
| tyteen4a03 wrote:
| While we're on the topic of niche railway games, I highly
| recommend [NIMBY
| Rails](https://store.steampowered.com/app/1134710/NIMBY_Rails/) -
| it is the closest you can get to building functional railway
| systems in a game.
___________________________________________________________________
(page generated 2024-07-10 23:00 UTC)