Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SimSig: Railway Signalling Simulations

simsig.co.uk

Post reply on HN
Print view View original

91–100 of 101 posts

Re: SimSig: Railway Signalling Simulations

#91

Post by corobo »

febusravenga wrote: post #87
corobo wrote: post #57

Earlier quoted context omitted.

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

Interesting. Never thought about that, but are you saying that emergency brake on train tears wheels so much that it's not able operate normally? Interesting learn. (the whole thread started by overconfident guy with unrealistic ideas ended as very informative, so actually net plus, who would thought)

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

Re: SimSig: Railway Signalling Simulations

#92

Post by akpa1 »

8372049 wrote: post #9
rwmj wrote: post #4

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.

Re: SimSig: Railway Signalling Simulations

#93

Post by lqet »

andruby wrote: post #67
lqet wrote: post #42

Earlier quoted context omitted.

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

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

The reflector posts are always exactly 50 meters apart, which makes this relatively easy.

Re: SimSig: Railway Signalling Simulations

#94

Post by withinboredom »

londons_explore wrote: post #35
Cthulhu_ wrote: post #29

Earlier quoted context omitted.

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

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 .

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?

Re: SimSig: Railway Signalling Simulations

#95

Post by mrguyorama »

8372049 wrote: post #8
fragmede wrote: post #6

Earlier quoted context omitted.

For people that want a railway simulator that includes game mechanics to drive a lot of complexity, try Factorio.

Or OpenTTD https://www.openttd.org

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.

Re: SimSig: Railway Signalling Simulations

#96

Post by iggldiggl »

bryananderson wrote: post #81
londons_explore wrote: post #12

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

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…

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

Re: SimSig: Railway Signalling Simulations

#97

Post by iggldiggl »

TylerE wrote: post #65
londons_explore wrote: post #18

Earlier quoted context omitted.

Moving block doesn't allow trains to get closer together than the braking distance. This would.

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.

Re: SimSig: Railway Signalling Simulations

#98

Post by bryananderson »

iggldiggl wrote: post #96
bryananderson wrote: post #81

Earlier quoted context omitted.

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…

> 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 abs…

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.

Re: SimSig: Railway Signalling Simulations

#99

Post by M95D »

rjmunro wrote: post #55
pixiemagic wrote: post #20

Earlier quoted context omitted.

What happens if there's some other reason to brake, such as an unreported fallen tree on the line ahead?

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.

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?

Re: SimSig: Railway Signalling Simulations

#100

Post by wolrah »

bryananderson wrote: post #81
londons_explore wrote: post #12

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

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…

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

Post reply on HN