How a Single Mechanical Failure Sparked 625 MTA Delays (2016)

“‘For 67 percent of the railroad’ — that is, every lettered train line except the L — ‘we don’t actually see train movement or control any signals and switches from the control center.’ Instead, they do it the same way they’ve been doing it for decades: train crews communicating by radio with a dispatcher. If there’s a delay, the dispatcher phones it in on the ‘6 wire,’ an open party line, and awaits instructions.”

Wow. I knew the system was old and rickety but I didn’t realize it was this old and rickety.

> “Their nightmare scenario,” says Gene Russianoff of the Straphangers Campaign, the venerable subway gadfly group, “is there are these people who are like bouncers who are standing in front of the staircase at Grand Central and put up a felt line and say, ‘You can’t go down for 15 minutes, because it’s too crowded down there.’ And it’s not an insane, paranormal phenomenon. It happens in London. And it would be terrible.”

I've had this happen while commuting in London, and it is definitely annoying. But it is not "terrible" and certainly not "insane" or a "nightmare scenario". Surely it is better than the vicious cycle of overcrowding forcing longer dwell times forcing more overcrowding? And that's not even taking into account the obvious danger of overcrowded platforms, with people at the back wanting to get to the front, and people at the front teetering over electrified rails as a train approaches.

There are only gap fillers at two NYC subway stations, Union Square and old South Ferry. Since the new South Ferry station is open again (flooded in 2012), the old curved platform at South Ferry isn't being used any more.

Those gap fillers are a tough piece of mechanical engineering. They have nearly a foot of travel, because they're on a sharply curved section of track. Some other subway systems use gap fillers, but they're usually much smaller, and are sometimes just passive rubber blocks.

Gap fillers get banged by the train as it leaves the station, rather than being retracted before the train moves. That's to prevent dumping people onto the tracks. So gap fillers have to be very tough, and they have to be pushable. That means no electric ball screws or hydraulics; they have to be pneumatic. They have to work at temperatures from below freezing to above 100F. They have to resist ice. They're stepped on by people and people can drop things through the slats, so they have a potential jamming problem. They're long sliding devices, always a headache. They're long enough that being pushed near one end when the air cylinders don't respond fast enough may force them back misaligned and jam them, which is probably the failure mode that caused the problem here.

Union Square's gap fillers are a one-off; there are no other copies of that design. If there were lots of those things, different designs would be tried and tested, as is normal for rugged mechanical design.

There are lots of small improvements that could be made to this system. Passengers are often left in the dark about what is happening, and so can't make informed decisions about which train to take, or whether to take the train at all. Announcements are rare except when trains are to be rerouted. The overhead signs that report arrival time estimates and delays are not always visible from the turnstile. And on the Lexington Ave line local track, most of those signs do not show the express train times, so transferring from the local to the express is always a gamble.

>MTA executives are naturally defensive about the criticism. They argue that, unlike in the ’70s, the current problems are a result of their own success — the subways are more popular than ever and therefore more crowded.

Aren't these the same people that got caught destroying data so that people could not check the efficiency of management?

I have recently been doing a literature survey of research into train timetabling and re-scheduling for a potential contract (using machine learning et al). Dealing with train delays in real time is not an easy problem to solve; it's pretty much a NP complete problem to find the most optimal solution. So 'the best so far' is the goal given time constraints. So I'm not surprised at all about how one issue went and cascaded. Managing real world train networks is pretty complicated because of the interconnection of so many things - the train schedules, the crew schedules, managing the rolling stock, the passengers... and the profit/loss of the train company.

I've had a lot of luck using this unofficial web-app: https://wheresthefuckingtrain.com/

What strikes me is the massive difference in functionality between the system when it is running smoothly and when it hits a snag, and how people consider the very best case to be baseline against which performance should be judged. Perhaps operations can be improved, but pending those improvements, the system is essentially running overoptimistically, pretending that its performance when everything is working right reflects its true capability more than its usual performance does. Many people have made this point, but the quote I have to hand is from Rich Hickey: "In the real world, failures are all the time. A large system is in a state of partial failure almost continuously." In a system like this, there's no point in improving the best case or even the most common case. In fact, it can be counterproductive, because it makes it hard for riders to figure out how to plan their trips, and when they do figure out the best way to use the system (getting to work an hour early many days to ensure you're consistently on time) they resent it. Also, if you perform acceptably most of the time, people are going to assume that you're just a few tweaks or a modest increase in capacity away from performing acceptably all the time, which can be very far from the truth.

One thing I don’t see acknowledged in the enthusiasm for rail-based public transit is its propensity for cascading failure. A road network has the very nice property that a disabled vehicle can coast off the road, or only block a subset of lanes, leading to a “graceful” degradation and creating backpressure that encourages other drivers to take different routes, which exist. It isn’t fun, but it’s a pretty amazing resilience story compared to alternatives. Many commodity parts, failing in ways that the system as a whole recovers from. You would think software engineers would be more positive about that.

We build train systems in such a way that if any component fails, the entire network is fucked. There’s only one way to get between A and B, and if it’s blocked by an emergency situation or the failure of some bespoke part, no trains will pass until the situation is resolved. From a distributed systems perspective, that’s horrifically bad engineering.

Maybe there’s some way to make rail networks more road-like in this way, or to build better bus systems that people will enjoy and embrace, but as it stands, the differences in failure modes motivate drivers to stay in their cars.