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]
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/).
For people that want a railway simulator that includes game mechanics to drive a lot of complexity, try Factorio.
Or OpenTTD
OpenTTD's default signaling system is mediocre. "Path signals" which are "recommended" and the only signal system not locked behind a settings change, will get you into trouble more often than not. You can only put a path signal somewhere where "it is safe for an arbitrary train to park here", which is a problem more often than not. If you are used to block signalling, as used in real trains, path signals will repeatedly surprise you in unfortunate ways. You have to basically deprogram everything you learned about signalling and even build rather different track layouts to use them. Add to that, platforms are not integrated into path signals in any useful way, so a train will sometimes refuse to advance to it's destination platform if it is a "Drive through" capable station if it cannot reserve a path well past it's desired endpoint.
IMO block signals are much simpler to understand for simple use cases, even if it is hard to make complicated railways with them. I think for normal people picking up OpenTTD, they would be a better choice.
Path signals are closer to how a modern signaling system operates. They absolutely can allocate multiple paths through the same block as long as the position of switches guarantees no conflicts.
Especially a fork called JGR's patchpack, featuring programmable signals and so much more.
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
Is it Sweet Transit? The about section mentions that the developer was part of Factorio.
Edit to add link - https://www.sweettransitgame.com/
The mechanics or more or less entirely unlike factorio. It’s this really weird city sim / train game hybrid that is pretty crappy at both halves.
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.
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.
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
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.
Memories of playing Heathrow Air Traffic Control (https://www.spectrumcomputing.co.uk/entry/2270/ZX-Spectrum/H...)
Nowadays you can do virtual ATC work in VATSIM and IVAO, controlling airspace for flight sim players.
It's super rewarding to do, but you do need actual training and often there are big waiting lists.
For a modern equivalent, I'd recommend atc-sim.com
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.
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
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.
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...
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).
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.
> 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.
If you are unhitching though wouldn't your former train have been just as likely to hit whatever the now-unhitched component in front might be about to hit?
Basically the only scenario where I can see this realistically being an issue would be if the car(s) being unhitched were already on the edge of stability to the point that being unhitched was the straw that broke the camel's back and they then immediately crashed in front of the now separated unit following.
> So, even with moving-block CBTC, you must always be capable of stopping before reaching the current location of the train ahead of you.
And even if you say 'I don't care, I think the risks of using relative braking distance are acceptable', every set of points that needs to be moved over between trains effectively poses a stationary obstacle while it is in transit and thereby effectively still forces you to use absolute braking distance between trains.
Yeah, great point, especially since points are often the next bottleneck after station dwells (I’m thinking especially of BART’s Oakland Wye here). Close following really does not solve what matters for throughput.
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.
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.
> 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)
$2,000 to $3,000 per square foot is absolutely the asking price for condos in parts of New York like Tribeca and Soho.
In the US, there is already plenty of public transport that people don’t ride due to stigma. How will the Hyperloop solve this problem?
> 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.
> 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.
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.
AFAIK the underground is not beset with blockages caused by fallen trees and stalled automobiles.
It does have its fair share of 'people under a train' and people preventing doors from closing.
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.
[dead]
> 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)
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
Aye as the sibling comment says it's not guaranteed to happen, I'm considering the worst case scenario outside of collision (needing to move trains that can no longer move themselves, needing to offload and transport stranded passengers, causing further delay, etc)
For what it's worth overconfident guy kicked off an interesting conversation!
It's also quite possible that I'm overcautious and the future will have trains within braking distance of each other and it turns out to be no big deal.
Thoroughly enjoyed thinking about the scenario in any case. Some proper Hacker News brain tickling in this thread :)
While it won't guarantee such level of destruction, emergency braking generally involves breaking beyond normal usability limits - including allowing for effective destruction of components in process
> 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
> 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#...
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).
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
> 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.
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.
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.
No, they’re very long because steel wheel on steel rail has much much much lower coefficient of friction than rubber on asphalt. If they brakes any harder they wheels would just lock up and skid, both running the wheels AND taking longer to stop than a normal braking application.
[dead]
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.
That’s a metric crapton of ifs. I would never get on such a system, it is fundamentally unsafe.
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!
What happens if there's some other reason to brake, such as an unreported fallen tree on the line ahead?
What happens if the train in front is a passenger train (a passenger pulled the alarm handle) and the train behind is 30 cars loaded with coal, steel beams or diesel fuel?
If one train derails for some reason, then every single train on the line crashes in the greatest pileup ever. Great.
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).
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).
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.
looking for what hasn't yet said here...
- some lines like Yamanote already use mobile block, 1 minute headways is pretty much SoTA with or without it.
- some systems like surface trams and AGTs can stop on a dime, but they are low efficiency, low capacity systems.
- trains scale well, the longest freight train known to man so far is ~4.5 miles long. A typical 15-car ~2k passenger commuter trains stretch about 300m(0.2mi).
- Just napkin math in loud: each Yamanote train at typical 150% capacity running at 1-minute headways can transport 2k[pax] * 60[min] = 120k passengers per hour per train; Yamanote has 30 stations with at at least one each of CW and CCW platforms; 120k * 30 stations is already 3.6m passenger per hour combined, or 28.8m per 8 hour day. Hypothetically the train can be joined back to back, operated 16 hours per day, tracks can be doubled, for a 2^3 multiplier to 28.8m figure. That's 230.8m/day or about 67.5% US population worth of traffic from just four pair of rails, and that's technically feasible with current technology. The question is how to make bucks out of it(build pairs of one Disneyland and a highrise apartment complex each along the rails)
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).
> 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://gleisplanweb.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 Stöckach (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.
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.
The Stuttgart system is light rail, not a tram. Big difference.
Moving block systems are not really new, they just aren't distributed widely.
Moving block doesn't allow trains to get closer together than the braking distance. This would.
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)
I'm not even sure derailments is the worst flaw.
As soon as one train has to slow down, you're going to get the mother of all cascading effects - trains are slow to brake, but their acceleration is quite a bit slower than that, and you'll be limited to, at the very best, the acceleration of the slowest train in front of you.
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.
Plus as soon as you need to throw a set of points between successive trains, you're back to absolute braking distance, because a set of point in transit effectively acts as a stationary obstacle.
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.
See also: https://signalmaps.co.uk/#gwml1:1627
Live signal maps in the UK
Also traksy e.g: https://traksy.uk/live/T+EDB+KGX+d+@2024-07-10T13:00/M+1+EDI...
There's also OpenTrainTimes https://www.opentraintimes.com/maps/signalling/wat#T_WATRLMN
And https://www.realtimetrains.co.uk/ for precise times/platform information.
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)
[dead]
[flagged]