You may have read about MUNI's radical attempts to deal with congestion issues in its Metro Subway that runs under Market Street and also included the Twin Peaks Tunnel. Long story short, MUNI is eliminating one seat rides downtown for riders on the J, K and L streetcar lines. The given reason is since the J and K lines are limited to single unit LRV operation, those "slots" in the Metro Subway are being underutilized and the new operating plan will replace the one LRV trains with two LRV trains.
The Metro Subway is signaled by a loop antenna based CBTC system in the style of LZB and if you are noticing a pattern between articles addressing CBTC and capacity problems then I thank you for being a long time reader. Basically MUNI is noticing the capacity problems that stopped both SEPTA and MBTA from realizing a full CBTC fantasy in their respective trolley subways and MUNI's response is to make many commutes much worse. To be honest this isn't just a CBTC problem as coded track circuits would have been no better and possibly worse. The issue is a fear of less automated operation.
Here is an LRV on the eastbound track at the Embarcadaro terminal station, which seems to be the major capacity constraint as M, L, K and J line trains all turn back here. You might notice a line of cones and a lot of unused platform space. That is because at every Metro Subway station, only one train can platform at a time, even though the platforms are long enough to support two trains.
Here is the westbound track with a fresh train sitting behind the cones just hanging out with a second train close behind while they wait for the single loading/unloading berth to become available. On all of the Metro subway stations it is common for following trains to stop short on the platform and wait for the single loading zone to become available. It is also common for passengers to run their buts off along the platforms to reach said single loading zone from the far end.
Both SEPTA and the MBTA use multiple berths at underground trolley stops to varying degrees. For example at Juniper St there is an unloading spot and a loading spot. At other stations different routes can stop at different points along the platform. On both systems the signaling system is equipped with R/Y station signals that allow operators to creep forward and occupy the station behind another LRV. It's not a cure all, but it helps.
MUNI plans to update its CBTC system to one that uses wireless instead of loop antennas. It might work better, it might not, but with new LRV's already arriving, maybe someone should have thought outside the box and ordered a radar based collision avoidance system to allow closer spacing in stations and thus pipeline the passenger boarding operation. Once headways drop below two minutes, dwell time and terminal capacity dominate block separation. It's why expensive CBTC systems don't move the capacity needle much and often do worse than traditional systems with on-sight operation, spring switches and loops.
Ya know, this article is yet another disconnect I have with the "self driving car" fantasies. If the self-driving-car software is even 50% ready for prime-time, I can NOT understand why it's not being experimented with on things like light-rail (I'm including all types here). I mean, all the "self-driving-train" (equivalent) software would have to (reliably) do is STOP the damn train. No steering involved. It would't have to worry about the UPS truck parked in-front of the stop-sign and running an intersection. The signals and the platforms don't change positions. The other light-rail vehicles aren't zig-zaging in an out of lanes, there's no speeding light-rail vehicles passing each other, there's no "other lanes" to worry about so no side sensors are needed, nobody coming down tracks in the wrong direction. All the software has to do is 1) look for a vehicle in front 2) look for bodies on the tracks.
ReplyDeleteYou wouldn't even need to have the self-driving-train software control the speed of the train. For the first implementation of the software: just STOP the train. It could act like second driver overriding the primary (human) one in stop-conditions only. How hard could THAT be compared to full-blown self-driving-car software?
And yet. NOTHING. This is mind boggling to me. Because of this single issue, the entire self-driving-car stuff seems like more vapor-ware to me. If you can't implement cheaply a software/sensor based system to stop a train at this time, with the existing software that exists NOW, then driving a car is just a fantasy.
Anywho, like your site.
There are a lot of human factor's issues with stop assist, but using it as a safety backstop that would work most of the time it happened to be engaged (ie the driver is still primarily responsible for train operation) would be more reliable and efficient than a fully automated system that need to have elevator levels of safety.
Delete