jonnhrr wrote:Given that the touted advantage of CBTC is to squeeze more TPH out of a line (whether it actually does this is another issue) wouldn't the T be better off just installing a conventional low-tech signaling system, something proven? After all TPH is not an issue on this line, it has more than enough capacity for the traffic.
Unless they are looking at it as a test bed for CBTC in the Central Subway which makes sense.
Jon
It's not anything inherent with "CBTC increases TPH". It's the Green Line: what kind of traffic intermixes on the Green Line, and what the Green Line's theoretical capacity ceiling is. Vs. whether there is a CBTC design/layout that can be fitted to the Green Line that's equal-or-better.
The Green Line already has one of the highest TPH's of any rapid transit system in the world, but the way it goes about that is pretty much managed chaos. Grade-separated branches with a dispatch-controlled signal system (D) of more-or-less precise scheduling merging at the same place as two street-signaled lines with crapshoot scheduling. Then a street-running line (E) that begats a reservation-running line all under street signaling transitioning into a flow-corrected subway line before merging at the midpoint. Then 3 downtown turnbacks. All in a 100-year-old subway with bizarre dimensions and its own set of flow kinks related to its archaic age and cobbled-together design that was adapted from downtown loop circulator to ill-fitting end-to-end circulator. Operating line-of-sight on incredibly short signal blocks still assisted to large degree by human dispatchers squawking over the radio while keeping hand count of train positions to keep some semblance of order. How does one unify all this under one computer brain?
On lines where CBTC is being implemented or strongly considered you've usually got a conventional HRT line (e.g. NYC Subway , or Red/Blue/Orange) with conventional end-to-end grade separation, conventional signaling on ALL branches and routings that's under the complete control of central dispatch (i.e. no "unknown" control like surface traffic), conventional controlled stops (NYC- or Blue-style mechanical trips, or Red/Orange-style analog ATO), conventional-length signal blocks for a 6+ car HRT train where even the shortest blocks are 'long' compared to the Green Line, and 110 years of more-or-less 'standard' heavy-rail subway design. It's orders-of-magnitude more straightforward to fit to a computer because all properties of the line are homogenous 'known-knowns' under central control. Even factoring in variable station dwell times and the crazy quilt of merging/diverging lines like in NYC doesn't seriously test the boundaries of automated dispatching. Therefore, a well-designed CBTC system that takes into precise account every 'known-known' of a subway line can quite easily equal the TPH of the previous system and potentially exceed it if the design shoots for that goal. Without question it would increase TPH potential on Red, Orange, and Blue. Especially Red.
Or...
On other mixed-traffic LRT systems that feed into a signalized subway, you can also do CBTC effectively because the 'managed chaos' variables are more self-contained than the Green Line. The subway's layout is likely a newer design still carrying the traffic it was originally designed for (i.e. trunkline not loop, with sight distances between blocks designed for LRV's and/or multi-car consists not open-car 1890's trolleys). There may be fewer branches, or less-irregularly spaced branch
meges making the subway co-mingling easier to anticipate. And EVERY other trolley subway--MUNI, SEPTA, Toronto--has far fewer TPH as its starting point than the Green Line does. So light rail CBTC starts out with somewhat higher degree of design difficulty than a 'closed' centrally-controlled HRT system...but way less design difficulty than the Green Line.
The Green Line is just off-the-charts in comparison. And while other systems worldwide share SOME of its quirks and may even hit the severe end of the scale on SOME of those quirks...the Green Line is literally the only one in the entire world that presents ALL of those quirks in that messy a combination. And thus has no precedent for how to design a signal system to deal with ALL of those quirks. And therefore there's not even a reasonable expectation that there's a perfect-enough CBTC design to be had today that could maintain current TPH. Let alone enhance it. Because TPH probably already is at the bleeding-edge limit of what you could run heavy LRV's more-or-less safely through those tunnels.
Now...it could be possible to do CBTC on the D. CBTC in the Huntington tunnel. CBTC from North Station outbound to the GLX branches and anything furher. And then just stop there and transition onto the current signals for Kenmore-NS. Those outer signalized parts of the Green Line by their very nature will never have more than a theoretical minority of the TPH and the train spacing that the Kenmore-North Station gut of the Central Subway has. Those are well within the 'known-knowns' design tolerances of CBTC deployed elsewhere, and just a partial install of CBTC to those spots could bring real benefits.
-- Safety, collision avoidance.
-- Lower maintenance costs. LOTS less trackside hardware to maintain with CBTC. Which is why post-Sandy NYC is stepping up its investment. And why the T may want to strongly consider it on Blue even with its light traffic volumes; that's a few hundred signal heads, mechanical trip arms, trip arm heaters, and a whole lot of electrical cable taking a pounding from salt air which it could entirely retire in favor of sporadically-placed low-voltage radio transponders.
-- A return to 50 MPH speeds on the D, and an expansion of 50 MPH territory to more places on the D and certain places on GLX.
-- Additional precision on the branchline dispatching, making threading the needle into the Central Subway easier to do without bunching.
You still would be under human control with all the safety implications therein on the most crowded parts of the subway, so it's not a complete solution. But it's a beneficial start, and #3 and #4 above do very tangibly improve Central Subway service by-proxy. I suspect even if they did start rolling it out with a goal of converting the central subway we'd still only see CBTC on the D first for several years until it's perfected. So it probably would've been a Phase I: D, GLX, Huntington anyway. They just may want to re-approach this idea that "Phase II: Central Subway" has no firm commitment to ever proceed until they can guarantee a Do-No-Harm design for TPH. If they do find the way, it's a software solution; the trackside, onboard, and dispatcher hardware is the same as what they used for the branchlines, and thus compatible. So they lose nothing doing the branches then abandoning plans to do the Central Subway. Or doing absolutely nothing to the Central Subway other than programming some barest-minimal acceptable collision avoidance and leaving everything else alone.
