CBTC for the T

[George_Apley]

Winston or F-Line?

Here's what F-Line has said in the past on CBTC for the Green Line [emphasis mine]:

The basic design would be CBTC. Which can either have moving blocks or fixed blocks. Since the blocks are mostly software-based and virtual, it can be whatever you program it to be. Moving blocks probably are not going to work in the Central Subway, so they would have to implement it with fixed blocks more or less the same as the current setup. And surgically fine-tuned to not decay headways under computer guidance vs. line-of-sight/human judgement. That's hard. Not impossible, but really really hard. And they have to get it right on the first try, so they can't proceed with haste.

IF such a setup can be designed it wouldn't increase throughput, but would bring all the other compelling advantages advantages of CBTC: safer operation with auto stop enforcement, vastly less track-mounted hardware to maintain, far less reliance on human dispatching. But, again, Central Subway capacity isn't the issue so much as unpredictability of branch schedules causing clogs where they intermix. So half the battle of making it run smoother is getting the branches all reliably on-schedule. Fix the surface clogs on the B and C first. Then a more conventional CBTC setup on the D and GLX to manage those headways. At a purely traffic management level the Central Subway can thrive as-is if the pen-and-pad guesswork were reduced to just the Kenmore-North Station stretch with more accurate branch arrival times. After all, it handled many more branches than this a half-century ago and lots of 3-car operation back then too. The main argument for CBTC downtown is purely safety: preventing operator-error incidents like the Gov't Ctr. crash. With secondary considerations for lowering maintenance burden and preventing crippling signal downtime like there was for months after the '96 flood shorted out everything from Kenmore to Copley. All of that's worthwhile enough to keep plugging away at the studies for due diligence.

It's the fucking-with-headways thing. And every one tweak having 3 unintended consequences. This is so difficult...and so difficult to do as open-heart surgery during active service...that you can't assume there will be any improvements whatsoever. The block locations may shift slightly, but it is far-fetched to see how this will result in headway enhancement. It may take 10 years to design something that even meets the do-no-harm standard, and there will be compromises. It is entirely possible that a 'tolerable' level of headway limitations will prove acceptable for installing CBTC if counteracted with 4-car trains and other enhancements compensating for a new headway cap. Enhancement is not the reason they'd be considering CBTC on the Central Subway. Safety, safety, safety. Because there are questions about how safe an operation line-of-sight is with that kind of density and such hugely heavy modern LRV's.

It's not a magic bullet. It's not intended to be one. And it doesn't do the same thing here that it would do on Red/Blue/Orange or D/GLX. Where they have to thread the needle is finding the do-no-harm compromise point, or as close as they can get to it. You are not getting throughput enhancements. The only way to do that is by biting the bullet and constructing parallel subway trunks: Huntington to Brookline Village, South End-Back Bay-Huntington, and Grand Junction LRT between Lechmere and a BU Bridge subway extension. Route the traffic on different circuits for exponential capacity increases. No Jetsons shit is going to do that on signals alone in a 115-year-old continuously operating trolley subway.


You can, however, make the whole thing run properly by getting trains into the subway on-time. That's a known-known, because that's how it all worked when there were more branches to juggle. That's what the current means of dispatching is predicated on. Fixing the B bottlenecks, streamlining the C, and re-signaling the D and GLX do that job. Do it well enough that you can still fit in other extensions. That's where the crux of the problem is. That's where the solution has to come from. Downtown doesn't make the branches operate better. The branches make downtown operate better.

 

[Commuting Boston Student]

Deficiencies in the application are not the same thing as deficiencies in the technology itself.

In this case, modern CBTC software deployed around the world today (including in NYC) is capable of 40 TPH per track. I understand that each of the four Green Line branches is using 9~10 TPH per track right now, which means that the application of the technology available to us right now shouldn't cause a drop in utilized capacity. What it's going to do is drop the potential capacity - we're pretty much at the limit of today's CBTC software and we won't be able to, say, add another branch right away.

But I want to restate: deficiencies in the application are not necessarily deficiencies in the technology. There is no absolute limiter to the technology itself that prevents CBTC from ever being faster than the speed of human thought - the limiters are all either physical (you can only ever signal trains X distance apart from each other, you can only ever move the switches at Y speed) or deficiencies in our available hardware and software. In the case of the former, it doesn't matter who or what dictates the schedule - in the case of the latter, technology gets better every day.

In Philadelphia's case, they're operating more than 60 TPH per track and that's well beyond what the systems are designed to accommodate. That's what's killing them, not some imaginary ceiling on what the applications of the technology will ever be able to achieve. The idea is that we need to get this close enough to "correct" the first time to dispel this luddite-ish myth that the technology isn't ever going to beat a pack of engineers sitting in a back room with a bunch of drafting paper and some pencils - and so that when we do add a fifth or a sixth branch to the Central Subway, it's just a matter of upgrading from turn-of-the-century hardware to state of the art (in 2035 or whenever it happens to be) hardware without us all coming right back here and wringing our hands about how much technology sucks and how "safety" should always be put in sarcasm-quotes or sarcasm-italics because safety is never a legitimate concern, right?

 

[Matthew]

Sorry, I thought the article had a date in it, forgot to mention that it is an old article from several years ago.

Philly has been running 72 TPH through their subway, albeit smaller streetcars, under CBTC operation. It's been rough, from what I understand, but it has been running for over 5 years now. So clearly, if they can do it with that schedule, we can do it with our 40-44 TPH schedule.

 

[abdinoor]

That sounds like a problem for software engineers to fix.

Software engineer here. I agree with you. Sounds like they have either faulty data (lack of sensors or unreliable sensors) or faulty algorithms. Both are solvable problems.

 

[winstonoboogie]

Sorry, I thought the article had a date in it, forgot to mention that it is an old article from several years ago.

Philly has been running 72 TPH through their subway, albeit smaller streetcars, under CBTC operation. It's been rough, from what I understand, but it has been running for over 5 years now. So clearly, if they can do it with that schedule, we can do it with our 40-44 TPH schedule.

A major difference compared to SEPTA is the MBTA network includes a flat junction (Copley Junction) right in the busiest traffic section, you have about 43 trains per hour each way, but you also have a subset of about 12 trains per hour (the E Line) crossing the main line at grade. SEPTA Rt 10 splits off at a grade-separated junction at the 36St portal.

I have heard that the MBTA is considering a low-tech alternative to CBTC that would not reduce capacity and would provide collision protection not now offered by the existing signals.
http://en.wikipedia.org/wiki/Intermittent_Inductive_Automatic_Train_Stop

 

[Matthew]

Okay, so the flat junction is a complication for sure. And honestly, I don't know much about the day-to-day operation of SEPTA's streetcar subway, or whether they've come to peace with their CBTC installation. I just wanted to bring it up as a data point.

I have heard that the MBTA is considering a low-tech alternative to CBTC that would not reduce capacity and would provide collision protection not now offered by the existing signals.

IIATS sounds like a slightly more advanced, electromagnetic version of mechanical trip arms. That doesn't help with the problem of needing to use line-of-sight operation to maintain service levels.

I presume that this IIATS installation would to be configured to allow restricted speed upon passing a signal at danger.

 

[winstonoboogie]

Okay, so the flat junction is a complication for sure. And honestly, I don't know much about the day-to-day operation of SEPTA's streetcar subway, or whether they've come to peace with their CBTC installation. I just wanted to bring it up as a data point.



IIATS sounds like a slightly more advanced, electromagnetic version of mechanical trip arms. That doesn't help with the problem of needing to use line-of-sight operation to maintain service levels.

I presume that this IIATS installation would to be configured to allow restricted speed upon passing a signal at danger.

I think they emphasis is on collision avoidance vs. running more cars per hour, but doing it in a way that does not reduce the cars per hour. It would still be line of sight, but with a back-up to apply the emergency brakes if an operator violated a signal. Mechanical trip arms like the Blue Line still uses were never practical on the Green Line, because the trips on the vehicles would be set off at grade-crossings in the winter (built up snow from street plowing would set off the trip on the cars, not an issue on rapid transit). The electromagnetic trips would not have that issue. There would still need to be an ability to pass a restrictive signal at very slow speeds in order to maintain the ability to couple/push disabled trains.

 

[Matthew]

Well it still sounds like IIATS is meant for a fixed block system, so how would it allow "line-of-sight" operations? Very small blocks?

 

[winstonoboogie]

Well it still sounds like IIATS is meant for a fixed block system, so how would it allow "line-of-sight" operations? Very small blocks?

I thought you were referring to the present signal system in the Green Line subway as line of sight. I think of it as de facto line of sight because the blocks are very short and there is no penalty for violating a signal.

I believe they are looking at this as an overlay to the existing signal system in the Central Subway and on the Riverside line. If a conventional block signal displayed red, the inductive system would trip a train (activate the emergency brakes) if it passed the signal. I don't think they would use this on the surface of Beacon, Commonwealth, or Huntington Ave. which would remain true line of sight, however the majority of serious streetcar collisions over the last 40 years that have caused serious injury (including an employee death) and/or heavy damage to equipment, have taken place in the subway or on the Riverside line

 

[Matthew]

My understanding is that a conventional fixed block system such as that currently installed on the Green Line Central Subway would not allow for 43 TPH, and that it only works now because the operators 'cheat' it in a controlled (well... somewhat) manner.

So a rigidly enforced fixed block system (using IIATS, for example) would make it impossible to operate the current schedule?

 

[winstonoboogie]

My understanding is that a conventional fixed block system such as that currently installed on the Green Line Central Subway would not allow for 43 TPH, and that it only works now because the operators 'cheat' it in a controlled (well... somewhat) manner.

So a rigidly enforced fixed block system (using IIATS, for example) would make it impossible to operate the current schedule?

The existing block can handle the 43 trains, "cheating" in the subway or on the Riverside line would mean passing a red, and someone could get time off or fired for that. The "cheating" that I see more often is operators violating speed restrictions on the B/C/E surface lines, some operators may claim they have to do that in order to keep schedules (especially with the one door boarding), but in the subway, there is not much opportunity to go faster than the speed limits because of the close station spacing and the signals that must be followed.

The Central Subway used to handle more the 43 TPH when Watertown was operating, but double-berthing (two trains stopping on the same platform) was not frowned on back then. After a series of collisions in 1989-1992, an APTA peer committee reviewing light rail safety recommended that the practice of double-berthing be discontinued. With the exception of the longer platform at Park St., and trains unloading at North Station eastbound, it is very rare to see two two-car trains load/unload on the same platform.

 

[The EGE]

Incidentally, the Market Street Subway carrying Muni Metro in San Francisco currently handles about 42 TPH at peak, with a full signal system and two grade-separated junctions. When the T Third line was introduced in 2007, this was briefly about 50 TPH and everything went to hell.

 

[Matthew]

On another note, the article from Philly claims that they had Bombardier install CBTC for $25 million (that the company footed to make up for a late order). Why does the MBTA cite close to a billion dollars for CBTC here?

When the T Third line was introduced in 2007, this was briefly about 50 TPH and everything went to hell.

This is before they ran thru the K to the T?

 

[The EGE]

This is before they ran thru the K to the T?

Precisely. The combined KT seems to be doing well.

 

[jass]

We let 15 years old drive cars with a visual signal system at 2 second headway

But well payed professionals on a track with 60 second headways? Oh heavens no!

 

[BuilditDenser]

I apologizing for bumping an old thread, but I have a question that has been bothering me for a bit and with the recent draft of the CIP, I think it is worth discussing


In the draft of the CIP unveiled on 3/16 at an MBTA FCMB meeting, MaassDot outlined a possible $1.08 billion budget for track, signals, and power. On the illustrative project list, they include $553 million for red, green, and orange line signal upgrades.

In the past few years, other transit agencies have been moving towards CBTC. Namely, SEPTA and the MTA.

MTA- first line they upgraded was the L. Cost $340 million and took 11 years. Recently (july 2015) they awarded a $205 million contract to make the 7/flushing line have CBTC signals.

SEPTA - in november, they awarded a $52 million contract for CBTC for two light rail lines (small ridership)

Just the other day Siemens completed testing for CBTC with LTE technology which would even further decrease the cost.


The T was quoted in 2003 at: 750 million for red line, 500 million for orange line, and another high amount for the blue line. What makes us so much more expensive? Given how NYC is paying about $275 million per line, wouldn't the CIP money be better spent converting some lines to CBTC?


In a recent atlantic article, it said that the blue line mechnical signals cost $168,000 per track mile per year in maintenance. CBTC would also improve reliability, safety, headways, and speed. If the MBTA could get the cost down to their peers, it seems like a great investment that should be lobbied hard to be included in the newest CIP


Draft CIP: http://www.mbta.com/uploadedfiles/A...IP316BoardMeetingCIP316UpdateBoardVersion.pdf (slide 49 is what I reference)

Atlantic article : http://www.theatlantic.com/technolo...dont-we-know-where-all-the-trains-are/415152/

 

[F-Line to Dudley]

True costs have to also account for the on-vehicle installs and the central ops installs, because CBTC is much more a 'software' system than a trackside hardware system. NYC spent a fortune over years and years equipping central dispatch before it ever ran its first revenue train on the new system, and has been ordering subway cars by the hundreds compatible with its chosen CBTC installation even though it may be a decade or more before some of them run on CBTC-equipped track. It's a massive and very time-intensive up-front investment and ramp-up before anyone gets to ride a CBTC-equipped train. It'll take 20+ years before every line on NYC Subway is running on CBTC, but because so much of the changeover is packed up-front with ops-to-vehicle systems integration they'll be overall past the halfway point of systemwide implementation much sooner than their CBTC-equipped track miles hit 50%. Those up-front costs are mind-boggling...but, it gets progressively easier and less costly with every additional track mile of scale they install it on. That's why they're starting to picking up the pace of the installs and starting to see more economical installs per-line. It's not because they're only getting started or things suddenly got cheaper. It's that the first billion already got spent on things that nobody except the back office could see.


The breakout of the T's lump-some projections don't reflect the extreme skew to up-front integration costs with central ops and the vehicles, so the totals aren't useful at all for direct comparison. While the MTA started plowing into that behind-the-scenes design-build almost a decade-and-half ago, the T is still sitting at square-one and dollar-$1. Whichever line they choose first is going to be a big sticker shock*, because that's the line that'll bear the brunt of design costs and equipping central ops with all the massively complex back-office computers. The lines with the most vehicles will have highest vehicle costs, simply because each car will have to be retrofitted with CBTC-compatible signal units. Red has more cars than Orange which has more cars than Blue. The new cars aren't being ordered with CBTC units because they can't know what onboard computers to order until the nittiest-grittiest details of the systems design has been hashed out. The new computer-heavy Red and Orange cars should be relatively easier to retrofit than the mildly older Blue Line cars, but it would've been impossible to guess at the factory how to make them compatible from Day 1. Track miles are at the backside. If they do Blue first and save Red till last, the fact that Red is so much longer than Blue doesn't mean that you can project costs by comparing lump-sum vs. track miles. Track miles will be the smallest portion of Red's lump-sum budget, and per- track-mile costs will probably be precipitously falling by the time they get to doing up the trackside equipment on their longest line.

So that's what accounts for it all. It scales very differently from other track infrastructure like electrical or rail replacements. But it's not all that different from what NYC went through with CBTC. Lineside installations are such a smaller % of the total cost and such large % of the total cost is front-loaded on systems integration. It's very much like the railroad PTC mandate in that it's taken years and years for each carrier to equip dispatch and square stuff like radio spectrum acquisition. Most lineside installs, like Amtrak on the south-of-NYC portion of the NEC, all happened eleventh-hour vs. the deadline with the deadline extension mainly being extra time for all that field work. It's a rough timeline analogy for how it goes with subway CBTC even though the subway and RR systems are quite different. It's because of the extreme "software, not hardware" nature of the systems.



*Green Line is a whole other ball of wax. Nobody's designed a CBTC system for a light rail system with the Green Line's train spacing. Doing up the Central Subway is basically going to be a whole new set of up-front costs that won't be lowered much by any head starts on the 3 conventional HRT lines. It's likely Red/Orange/Blue will be well underway before they can even put forward a paper design that'll work on Green. Treat them as TWO wholly separate CBTC efforts--a heavy-rail implementation needing its full ramp-up costs, and a light rail implementation needing its full ramp-up costs--to account for why Green seems to be paying twice for the back-end side of it. It pays twice because Green LRT is that much different from our very un-special Red/Orange/Blue HRT lines which do get much easier after the first guinea pig absorbs the up-front pain and suffering.

 

[BuilditDenser]

Thanks (as always) for the detailed response.

I'm disappointed that the T did not have a CTBC plan its recent red/orange car purchase. It really looks like that was the best chance the t will have to begin to a slow crawl towards CBTC. Would these cars be easier to convert to CBTC since they are pairs? Like can you only update the As but not the Bs? Or do you have to update all of them?

Given that many transit agencies have recently switched to CBTC, will the centrals ops install become cheaper over time?

 

[The EGE]

CBTC isn't necessarily as high a priority for the T as it is for NYC right now. The Lexington Avenue line currently tops out at 27 TPH in each direction on the express tracks (slightly less on the locals); the Red Line currently maxes at 14 TPH (except for an extra Braintree run at peak-of-the-peak), the Blue Line at 12 TPH, and the Orange line at 10. There's no more blood to squeeze from the Lex except via CBTC, whereas more reliable rolling stock + SGR to remove speed restrictions + better track maintenance for higher speeds on the long straightaways + enough rolling stock to run higher frequencies could pull a lot more from the existing MBTA heavy rail system.

As recently as 2003, the MBTA claimed 16 TPH on the Red Line, 15 TPH on the Blue Line (4 car trains back then), and 12 TPH on the Orange Line. The Orange Line ran 15 TPH in the 80s before 6-car trains were implemented, and the Red Line track infrastructure and signals can handle about 20 TPH (speed restrictions, dwell times, etc do not currently allow that, but in top shape the line could handle it).

The Orange Line is going from 120 cars (96 required for rush hour) to 152 as part of the new order; that's enough to hit about 12 TPH. The Red Line should run more reliably with the new cars, so service will be better on average even without additional cars. The Blue Line is stuck where it is, but it's certainly capable of more TPH with the existing signalling. None of them would actually gain that much from CBTC without first topping off with more rolling stock, significant change in SGR, and station modifications - and that's enough to handle probably a 50% increase in capacity per line.

 

[swtat]

Thanks (as always) for the detailed response.

I'm disappointed that the T did not have a CTBC plan its recent red/orange car purchase. It really looks like that was the best chance the t will have to begin to a slow crawl towards CBTC. Would these cars be easier to convert to CBTC since they are pairs? Like can you only update the As but not the Bs? Or do you have to update all of them?

Given that many transit agencies have recently switched to CBTC, will the centrals ops install become cheaper over time?

I could be wrong, but I think the new vehicles are designed with provisions for CBTC. Here is a clause from the technical specifications document of the new Red/Orange Line vehicles:
The ATP supplier shall demonstrate the ability to provide a system that will work on an analog, continuous coded cab signaling system with upgradeability to work in mixed analog and digital track circuit territories. The supplier shall submit to the Authority for review and approval, demonstrated successful operation of its equipment on both types of systems.