this is the kind of nitty-gritty stuff I wish railroad management games would show, a lot of them are very arcade-like in comparison
How we slowed the subway down
91–99 of 99 posts
Re: How we slowed the subway down
#92This reminds me of the trouble they've had upgrading Air Traffic Control systems.
I grew up in Manhattan and rode the subway constantly. I remember sometimes taking the front car, looking out the window and wondering what the odds were of a collision. Then a friend explained how the red light control system made it physically impossible for one train to crash into another.
Ha! Glad I didn't know the truth back then, I might have developed a phobia about using the subway.
Re: How we slowed the subway down
#93Earlier quoted context omitted.
While i agree that it is surprising that MTA continues to use archaic technology, I don't the solution is nearly as simple as you pose it. Hardware engineering is hard, and in-service engineering of complex systems desiring near 100% uptime is challenging. The sensors must not simply survive a dirty, dusty environment, they must work perfectly with no glitches and for long periods between maintenance. And if they do…
Is there a term for using multiple redundancy and statistics to solve issues, for example using 5x 99% reliable sensors rather than a single 99.99% sensor that costs 100x more?
engineering
Re: How we slowed the subway down
#94Earlier quoted context omitted.
So, considerably less than the average articulated lorry, or indeed Skoda Octavia?
No, very much around the average for an articulated lorry. But metro trains stop and start every 2-5 minutes all day, last 40+ years, but also travel on a very smooth "road".
You must live somewhere without a lot of road haulage, or without any taxis.
Re: How we slowed the subway down
#95After an operator-error derailment on the commuter rail line I frequently ride, the response of the NTSB was to require the railroad de-prioritize on-time performance and increase schedule times. As a frequent rider on the route I would much rather have my 15 minutes per day back and risk a once-per-century fatal accident. But the risk-averse bureaucracy we've built doesn't make such calculations with a balance like…
"Sure you save some lives but how many will be late!" I do not like this math. For example the accident may not be once per century. And it is good for the bureaucracy to be risk adverse if it comes to my life. The answer is that they should improve the technology so that the system is safe and faster.
But hold on - do you really want to be significantly slower on your way to the hospital or doctor, for symptoms that you didn't think merited an ambulance; but actually do? This isn't an uncommon kind of trip, it's a pretty common one. Adding minutes to millions of trips adds deaths that are much harder to count up, but are no less real. Now add in kids left alone for an extra few minutes times millions, etc, etc. There are tradeoffs here; risk doesn't lie on just one side of the equation.
Re: How we slowed the subway down
#96> Collisions happened more frequently than they do today, but they generally did not kill. And while there exist news reports of incidents that sound suspiciously like signal system design issues – for example, a B train which rear-ended the system’s revenue collection train in Brooklyn in 1968 – these seem to have been rare. Most of the accidents whose stories made it into the press seemingly had little to do with signal system’s deficiencies.
Where is the NTSB (national transportation safety board) in all of this? You shouldn't have to search around for news reports to find out about when incidents took place on a transit system operated by the government.
If NYC isn't adequately investigating, cataloging, and dealing with these incidents, why isn't the NTSB doing anything about it?
While the article is very interesting from an engineering perspective, it boggles the mind that such a safety critical piece of infratstructure is allowed to operate in an opaque manner with little or no oversight.
Re: How we slowed the subway down
#97Earlier quoted context omitted.
PZB was already introduced in 1934 https://en.m.wikipedia.org/wiki/Punktförmige_Zugbeeinflussun...
The previous commenter did not say PZB were introduced in the 1950s, but adaptation to braking curve. Not an expert in the area, but I very vaguely remember that 1 out of 3 braking curves is selected for each train. Not sure how big the risk is that trains would operate under the wrong braking curve and whether that has ever materialized in form of an accident. Edit: Selecting a braking curve seems important when the…
Supervision of actual braking curves through PZB was actually only introduced starting in the mid-80s (first version of the PZB implemented through microprocessors), and widespread retrofitting of older rolling stock with an upgraded PZB-version only began in the late 1990s/early 2000s in response to the Rüsselsheim rail crash.
Before that, speed control only happened at discrete points along the lines of "speed must be lower than x kph after y seconds", so you could actually continue running at full speed for up to y seconds before tripping the train protection.
Meanwhile, the currently existing lines on the two pre-war Underground rapid transit systems in Germany (Hamburg and Berlin) are still using simple train stops, too (though they did at some point upgrade to magnetic/inductive train stops instead of the original mechanical train stop system).
Re: How we slowed the subway down
#98Earlier quoted context omitted.
No, very much around the average for an articulated lorry. But metro trains stop and start every 2-5 minutes all day, last 40+ years, but also travel on a very smooth "road".
You must live somewhere without a lot of road haulage, or without any taxis.
I don't have the link to hand. It was figures from a forum for drivers discussing what "average mileage" would mean on a British articulated lorry.
Re: How we slowed the subway down
#99Earlier quoted context omitted.
While i agree that it is surprising that MTA continues to use archaic technology, I don't the solution is nearly as simple as you pose it. Hardware engineering is hard, and in-service engineering of complex systems desiring near 100% uptime is challenging. The sensors must not simply survive a dirty, dusty environment, they must work perfectly with no glitches and for long periods between maintenance. And if they do…
They're slowly switching each line to a CBCT based signaling, the lines that do have it are vastly improved. Aside from all the budget and construction corruption issues of the MTA, it's difficult to do because the NYC subway is expected to run 24/7. And so upgrades need to be scheduled around limited times during which lines can be shut down, usually just a few hours overnight. And also keep the old system running w…
Anecdotally, CBTC is a greeat improvement in many scenarios. On long and straight stretches between express stops, trains now fly along (probably at least 40mph; never got to see inside the TO’s cab). And upon approaching an occupied station, they slow down to a crawl but keep moving until about 25-50 feet before the station, instead of being stuck several fixed blocks back before the station. Thus there is much greater track capacity = more (potential) trains per hour, and generally more reliable trips.