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

How we slowed the subway down

homesignalblog.wordpress.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: How we slowed the subway down

#41

Post by pantalaimon »

hadlock wrote: post #39
jimmyswimmy wrote: post #35

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

My 1955 Citroen (designed in 1933) has the original speedometer and speed sender cable. It's accurate (GPS tracked) to within 2-3km/h. This is with nearly 70k miles on the clock. This is the same mechanism Citroen used in their 2CV from 1946 until 1992. Most Model A Fords from 1929 have their original speedometer (which works fine, might need greasing every few decades though). With tens of thousands of miles on them…

GPS doesn’t work underground though.

But the problem described in the article seems rather unique to NYC and one has to ask how other subway systems manage just fine without artificial slowdowns.

Re: How we slowed the subway down

#42

Post by squeaky-clean »

jimmyswimmy wrote: post #35
hristov wrote: post #12

It is actually bonkers that in this day and age the NYC subway cannot install accurate speed gauges on their trains. You can get an accurate bike speedometer for $20 on amazon, but the NYC subway cannot provide an accurate speedometer for train carrying a couple of hundred people. It is true that trains require more rigorous standards, but it is not a difficult problem. For example you can put a sensor on the electri…

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 while upgrades happen which tend to take years for a full line upgrade.

https://en.m.wikipedia.org/wiki/Communications-based_train_c...

Re: How we slowed the subway down

#43

Post by mvnuweucxqokii »

pantalaimon wrote: post #41
hadlock wrote: post #39

Earlier quoted context omitted.

My 1955 Citroen (designed in 1933) has the original speedometer and speed sender cable. It's accurate (GPS tracked) to within 2-3km/h. This is with nearly 70k miles on the clock. This is the same mechanism Citroen used in their 2CV from 1946 until 1992. Most Model A Fords from 1929 have their original speedometer (which works fine, might need greasing every few decades though). With tens of thousands of miles on them…

GPS doesn’t work underground though. But the problem described in the article seems rather unique to NYC and one has to ask how other subway systems manage just fine without artificial slowdowns.

I'm pretty sure the person you're replying to was saying that the original speedometer mechanism in their 1955 car is accurate to within 2-3 km/h of the speed reported by GPS, and thus suggesting that this pre-GPS mechanism ought suffice for the subway / be better than whatever they currently use.

Re: How we slowed the subway down

#44

Post by pantalaimon »

tgsovlerkhgsel wrote: post #2

The obvious solution seems to be to technically enforce the speed limits without relying on average-speed-through-section, which seems to have been done way too late. Likewise, the yellow signals could trigger enforcement of a braking curve to ensure the train will have a sufficiently low speed at the next red signal. (This is how one of the German systems works - PZB, not a modern one either, I think the braking-cur…

PZB was already introduced in 1934

https://en.m.wikipedia.org/wiki/Punktförmige_Zugbeeinflussun...

Re: How we slowed the subway down

#45

Post by pantalaimon »

mildchalupa wrote: post #28

One of the things that I find interesting in terms of long lasting standard or infrastructure development is that small variations in design choices early in a system result in radically different performance down the line. For instance the width or guage of a train track will greatly influence the carrying capacity and the size of objects transportable via rail. Same for the size of lane of road. Infrastructure, and…

The subway is actually a systems that is easier to change than others (unless you talk about the physical dimensions of the train) since it’s an isolated system and lines are usually separate too, so you don’t have to change it all at one.

Re: How we slowed the subway down

#46

Post by danuker »

joe_the_user wrote: post #19
dzdt wrote: post #3

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

A bureaucracy can't ignore the possibility of a deadly crash. But they chose the slow-down instead of spending the money needed for safety. Which is despicable imo. But there is the quandary that they know a modernization project could be a disaster just all American public transit projects tend to be disasters.

Reminds me of Atlas Shrugged, when they had to resort to manual track signal switching.

"Physical men, serving as lamposts. You’ve advocated it long enough—you’ve got what you wanted’" (pp. 875-76).

Re: How we slowed the subway down

#47

Post by Dylan16807 »

hristov wrote: post #5
dzdt wrote: post #3

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

> And it is good for the bureaucracy to be risk adverse if it comes to my life.

Only moderately risk adverse.

Unless you'd approve of all roads having a 15-20mph speed limit? Because that's the natural conclusion of prioritizing accidents much higher than speed. And I'm not being hyperbolic or using a slippery slope argument. I'm saying that you have to admit a tradeoff to get any kind of sensible result.

Re: How we slowed the subway down

#48

Post by notmtaemployee »

hristov wrote: post #12

It is actually bonkers that in this day and age the NYC subway cannot install accurate speed gauges on their trains. You can get an accurate bike speedometer for $20 on amazon, but the NYC subway cannot provide an accurate speedometer for train carrying a couple of hundred people. It is true that trains require more rigorous standards, but it is not a difficult problem. For example you can put a sensor on the electri…

A couple of thoughts:

The approach you describe to measure speed from the motor position is essentially what subway cars use. Ignoring wheel slip, which is not a rare phenomenon, this approach works very well. However, when you defer maintenance, things operated in harsh environments _will_ eventually break down.

(Within the context of the issues mentioned by the linked 2018 NY Post article) Speedometers were (bizarrely) judged as non-critical parts (i.e., the car can still be used in service with it broken) because, after all, the signaling system will catch any over-speed, thus the repair, and more importantly the maintenance, of speedometers was not prioritized. Thankfully most of Cuomo's goons and bean counters have been pushed out.

As for the wayside speed enforcement, the author only briefly touched on the solutions to the problem described in the article, but it's known as Communications Based Train Control (CBTC)[1]. It's a moving block system (compared to current fixed block signals) that used train speed, track geometry, and the location of other trains to determine maximum safe operating speed.

I would argue that it's not "maddening" to control subway speed with electro-mechanical timing mechanisms, control lengths, etc. This was cutting edge in the 1920s & 1930s, and indeed some of the oldest signaling in the system is from that era (though thankfully, the amount is decreasing).

It is however maddening to decide in 1995, given other existing speed control solutions at the time (coded track circuits, CBTC, axle counters) to expand the use of these timers. But as the saying goes if you have a hammer, everything is a nail.

Even more maddening is how slow the subway's transition to CBTC has been. NYCT was an early leader, with the Canarsie line being one of the first brown-field re-signaling jobs (not to mention a 24/7 railway), and then the program just seemed to languish under management that didn't see CBTC's value or the need for modernization (could write pages on this). Thankfully the new cadre of people at 2 Broadway has put the CBTC program into high gear, with 4 (5?) lines under various stages resignaling at the movement.

As a bonus tidbit: the wheel slip issue mentioned above is fixed in CBTC operations with the inclusion of a free axle, equipped with no motor or breaks, thus never experiencing a lack of adhesion. Passive RFID balise's placed at known intervals (i.e. loaded into the train) allow the train to then audit (while in operation) how far its estimated position and speed have deviated from where it truly is. Some CBTC systems also have car-brone backups based on accelerometers or rail-facing doppler radars.

[1] https://en.wikipedia.org/wiki/Communications-based_train_con...

Re: How we slowed the subway down

#49

Post by atoav »

o10449366 wrote: post #38
jimmyswimmy wrote: post #35

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

Unfortunately, it's a pretty tired HN comment to posit something as being more simple than it actually is. Even during the pandemic there were widespread complaints about the signal work on the L line that has now transformed it from one of the worst lines to one of the best. There's no such thing as "simple work" on a system that millions of people depend on for consistent uptime.

If you count in the financial constrait that service is working under, sure. But meassuring the speed/position of a rail vehicle on a piece of track reliably is not an unsolvable feat of hardware engineering. It is done elsewhere and it is done elsewhere where similar constraints for uptime exist.

Theoretically by that logic we could argue that trains are hard because making the motors for them is non-trivial. It is non-trivial, and depending on your standards it might be even hard. But it is essentially a solved problem. You want a motor? You get one from the big companies, let them design one or use one from an existing similar train. Same thing goes for measuring speed. You want it? Create a team researching which ones to get.

Like in many places NY infrastructure has it's best days long behind itself and it is a wonder it still works. That infrastructure is in dire need of modernization and it has been for a while. The reason this is not done is not because it is hard or impossible to do. It is just expensive.

Post reply on HN