CBTC - General Discussion

[RR503]

1 hour ago, Deucey said:

Just wondering, for the trains ending in loops then (today's ), do you have to factor in crew changes in or after the loop (if they did those then) or rest breaks (if the crew downtown went back uptown in the same train)?

I can't speak to past practices, but I know that today crews run through on the  at least. I'd assume they did that back then too... 

As I'm sure our RTO members will tell you, the  is a hell assignment. You're stuck in the cab of a train traversing the most crowded subway line in the nation for two hours (or more). Consequently, many of the folks who run it are quite green -- talk about being broken in -- a fact which doesn't do  capacity any favors. 

[Jsunflyguy]

6 hours ago, RR503 said:

I excluded 3rd Ave El from my calcs for precisely this reason; wanted to analyze what we once did w/ the infrastructure that exists today. 

In '49 and '54, most of the IND was running 8- or 10- car trains, and most of the BMT 8. QB express, in fact, has 11 car trains in that '54 map. On the IRT, expresses all have 10 car trains, but the IRT locals not so much -- 7th seems to still be running 5 car trains (though the map indicates that the signal system is capable of handling 30 10 car trains/hour), and Lex averages out at around 8 cars.  

Insofar as terminal ops, train length only matters if you're entering and leaving with the same crew. Needless to say, that isn't a best practice. Most systems either have crews waiting at the departing end of the terminal and/or double end with the departing crew when entering relay. 

Passenger capacity in the peak hour over time is forthcoming. I can tell you, though, that in 1954 we ran 4221 cars into the core. Today, it's 3,278 -- a 22% decrease. 

I see it now, I searched the word "Third" and forgot to check '3rd' after the reading, so my oversight on that. The length still has meaning at the terminal ends since the crews are told they're up next when their equipment is leaving the penultimate station during disruption otherwise they are there 2 minutes prior, so the distance may or may not apply, more likely that is a wash, but the time penalty for longer trains still applies for clearing the interlocking, clearing out trains (a recent procedural addition), etc.

Also I'd be a little incredulous about IRT Claiming the signal system could handle 30 10-car trains, the same company famously claimed to the City that the Els couldn't be signalized because it would no longer be able to run its 30tph headway on the local tracks. In the absence of the math being shown that isn't definitive. 

As for Dekalb, the interlocking was slowed by the oft-maligned timers, but throughput is also constrained by the Manhattan bridge being. Trains exiting the interlocking at slow speed constrain the area in the same way a backed up exit cascades down a highway and backs up the nearby interchange. Dekalb will never reach those rates again as trains over the Manhattan Bridge are constantly checked by timers (which disturbs smooth operation) enforcing a lower speed limit because the Bridge was not designed to handle trains going over it at Maximum Speed, a problem that was known but never properly addressed which lead to the critical failure in the 80s that severely disturbed Transit for the better part of a decade. Which is why its important to note that some---though not all---of these statistics were bought by years of abuse to the system that we spent a substantial amount of time and treasure cleaning up. 

I did a quick check, but as you didn't specify the time over which the cars to the core number is representing, I did check the car assignments and if we replace every Manhattan Line's 75ft cars with 10car 60ft trains that would require 578 additional cars in addition to the Modern number provided we get 3856 cars, which is a 9% increase from the 1954 number. Given the constraints we've added to our system in terms of safety constraints is about what you'd expect. I'm sure someone in Planning has the tables that would show the current theoretical capacity of the system, that's a number I'm really interested in. Look forward to your capacity notes.

Edited November 29, 2018 by Jsunflyguy

[RR503]

9 hours ago, Jsunflyguy said:

I see it now, I searched the word "Third" and forgot to check '3rd' after the reading, so my oversight on that. The length still has meaning at the terminal ends since the crews are told they're up next when their equipment is leaving the penultimate station during disruption otherwise they are there 2 minutes prior, so the distance may or may not apply, more likely that is a wash, but the time penalty for longer trains still applies for clearing the interlocking, clearing out trains (a recent procedural addition), etc.

All of this is most certainly true, but I again think we can't lose sight of the fact that longer trains worked just fine on complex routes at high throughput (34tph).

On a related note, I've heard that there was a bulletin a few months back that abolishes fumigation (!) by double-ending w/ road crews. Enforcement seems to be lacking, though... 

9 hours ago, Jsunflyguy said:

Also I'd be a little incredulous about IRT Claiming the signal system could handle 30 10-car trains, the same company famously claimed to the City that the Els couldn't be signalized because it would no longer be able to run its 30tph headway on the local tracks. In the absence of the math being shown that isn't definitive. 

Eh. Those maps clearly show that they actually did run 30-32tph x 10 cars on the express lines, and NYMTC data from later years shows as much as 28-29 delivered in some years in the '70s. This is also the BOT reporting, BTW, so that IRT obfuscation is less of an issue (and actually, given that the BOT was basically IND staff running everything, there was a feudalistic incentive to lowball BMT/IRT cap estimates...)

9 hours ago, Jsunflyguy said:

As for Dekalb, the interlocking was slowed by the oft-maligned timers, but throughput is also constrained by the Manhattan bridge being. Trains exiting the interlocking at slow speed constrain the area in the same way a backed up exit cascades down a highway and backs up the nearby interchange. Dekalb will never reach those rates again as trains over the Manhattan Bridge are constantly checked by timers (which disturbs smooth operation) enforcing a lower speed limit because the Bridge was not designed to handle trains going over it at Maximum Speed, a problem that was known but never properly addressed which lead to the critical failure in the 80s that severely disturbed Transit for the better part of a decade. Which is why its important to note that some---though not all---of these statistics were bought by years of abuse to the system that we spent a substantial amount of time and treasure cleaning up. 

Timers are definitely an issue at Dekalb. The bridge itself is actually fine (signal spacing is close enough that the low speed is made up for w/ shorter control lines), but within the interlocking, there are a zillion GT15s and GT20s that protect massive blocks, and rarely clear at posted speed. 

What I've heard is actually worse than the timers, though, are the dispatcher cams. As I'm sure you know, train routings at Dekalb are assigned at the homeball; T/Os pull up to their respective entrance signal, wait for a Tw/O to divine their headsign via CCTV, get a routing, and crawl on. That stop (which can sometimes last well over 2 mins, if not more if there are late trains) is, IINM, the primary cause of capacity erosion in the area. 

10 hours ago, Jsunflyguy said:

I did a quick check, but as you didn't specify the time over which the cars to the core number is representing, I did check the car assignments and if we replace every Manhattan Line's 75ft cars with 10car 60ft trains that would require 578 additional cars in addition to the Modern number provided we get 3856 cars, which is a 9% increase from the 1954 number. Given the constraints we've added to our system in terms of safety constraints is about what you'd expect. I'm sure someone in Planning has the tables that would show the current theoretical capacity of the system, that's a number I'm really interested in. Look forward to your capacity notes.

Another good point. IINM the older NYMTC tables normalized 75' to 60' equivalent, but I now see that the annoyingly stopped along the way somewhere. To be clear, you calculated the increase in necessary cars, or the net increase of core-bound cars? I can run the latter normalization easily later today. BTW, I'm sure this is a typo, but 3856/4221 is a 9% decrease -- just want to make sure I'm not missing something.  

[Union Tpke]

1 hour ago, RR503 said:

On a related note, I've heard that there was a bulletin a few months back that abolishes fumigation (!) by double-ending w/ road crews. Enforcement seems to be lacking, though... 

I have been seeing employees other than the train crew clearing cars at Forest Hills as of late.

[Jsunflyguy]

On 11/29/2018 at 10:07 AM, RR503 said:

All of this is most certainly true, but I again think we can't lose sight of the fact that longer trains worked just fine on complex routes at high throughput (34tph).

On a related note, I've heard that there was a bulletin a few months back that abolishes fumigation (!) by double-ending w/ road crews. Enforcement seems to be lacking, though... 

Eh. Those maps clearly show that they actually did run 30-32tph x 10 cars on the express lines, and NYMTC data from later years shows as much as 28-29 delivered in some years in the '70s. This is also the BOT reporting, BTW, so that IRT obfuscation is less of an issue (and actually, given that the BOT was basically IND staff running everything, there was a feudalistic incentive to lowball BMT/IRT cap estimates...)

Timers are definitely an issue at Dekalb. The bridge itself is actually fine (signal spacing is close enough that the low speed is made up for w/ shorter control lines), but within the interlocking, there are a zillion GT15s and GT20s that protect massive blocks, and rarely clear at posted speed. 

What I've heard is actually worse than the timers, though, are the dispatcher cams. As I'm sure you know, train routings at Dekalb are assigned at the homeball; T/Os pull up to their respective entrance signal, wait for a Tw/O to divine their headsign via CCTV, get a routing, and crawl on. That stop (which can sometimes last well over 2 mins, if not more if there are late trains) is, IINM, the primary cause of capacity erosion in the area. 

Another good point. IINM the older NYMTC tables normalized 75' to 60' equivalent, but I now see that the annoyingly stopped along the way somewhere. To be clear, you calculated the increase in necessary cars, or the net increase of core-bound cars? I can run the latter normalization easily later today. BTW, I'm sure this is a typo, but 3856/4221 is a 9% decrease -- just want to make sure I'm not missing something.  

I wouldn't say "just fine" is an appropriate view  of it. This number required a lot of what would be considered "cheating" now, with keying every automatic, actually entering a station on ST, etc. But yes it is true longer trains can be run at a higher throughput than now. Though I don't think that number is achievable any longer, and running the schedule to 100% capacity has the consequence of never being able to recover from a disruption. Although Lexington maintains 28tph which isn't bad considering every A division express that doesn't end at Utica passess over a single switch at Rogers. 

Fun point of research has ATS with its computer controlled automatic line-ups improved the A Division on time performance, it doesn't seem so, but the changeover happened in 2009 so no data that have to hand goes back that far.

The funny thing about Management Bulletins is that they don't make crew appear to do it. Although it was issued months ago the new pick went into effect three weeks ago, which moved some Station Switching (relay crew) jobs around. In fact it added some where they didn't exist at all, such as Pitkin, and a few extra at 168th. 

The place where this problem primarily exists, Continental received no recent schedule modifications to accommodate this, the last update to the schedule essentially moved some late PM jobs to midnight jobs that wrap around to the morning rush. While the  schedule has improved slightly from the perspective of average hours work (8.24 from 8.28) which, from a cursory glance, seems to be due to some changes in reporting points and modifications to how the shuttle is crewed.  The  which was already everybody's favorite line rose from an average of 8.76hrs to 9.1, and in addition to that the  now wants those same crews to extend their inbound trip 6-10 minutes depending on how long the train will rot in the relay AND start your outbound trip that much sooner. I can see why no one is enthusiastic about enforcing the policy.

If Transit wants to continue down the path of ambiguous training and policies in addition to menacing crews for minor infractions like putting a door panel out (which in the 'good ole days' was a 60 second delay as the t/o keyed the first door or two, but is now a 15 minute ordeal, with the requisite trip to 2 Broadway). Now that they are getting bad press for the policies that they chose, they simply expect the crews to just 'work harder', well I can't see how the crews tolerate it, but I reckon another 1966 is coming in the not-too-distant future.

 

With the Tower Camera thing, I believe we've stumbled into another issue that could have been solved into the past, and can still be now, but hasn't. That is the use of train describers. http://photos.signalling.org/picture?/7498/category/639-earls_court_control_room

The identity of the train can be maintained between multiple signal boxes even in a rapid transit application, and the technology has existed since the 50s, it absolutely boils my blood that we have CCTV camera (which has to read an LED that will appear as a red blur in a dark tunnel). Why punching at Pacific isn't good enough, no idea. I suspect that since the  doesn't use workstations for its NX machines (that I've seen) it's just one operator running the whole show and getting overwhelmed (or two people constantly in each other's way)....that would sound about right. The other issue is towers were individually manned with slightly more autonomy than now. At this point one or two people in a master tower supervise an entire line with no realistic way of tracking where trains specifically are, and if that one person is distracted by another issue the whole line suffers, even if they aren't involved in the problem. 

I only calculated the core cars, so R68s on the  and 46s on the  were ignored. So it would add 578 core bound cars, which is a 9% decrease from the nominal figure of 4221, I didn't catch the typo on my phone until the edit window closed. 

[Ethan777]

On 11/1/2018 at 9:42 AM, Lawrence St said:

This is what I mean. Like, if a rail breaks on lets say the  between 1st Avenue and Bedford Avenue, and CBTC can't detect it, it will continue to go at the posted speed and the consequence can be deadly. This is why I prefer motorman. 

Hello, I am a train enthusiast from Singapore where currently our 2 oldest lines from 1987 are being installed the exact same CBTC system as with what the    and QBL is receiving Thales SelTrac CBTC. I personally came to NYC in 2013 and rode your Subways (   from what I rmb) . It has been 5 years. 

I understand everyone here is reluctant to hand our operations over to a computer. But you need to understand that CBTC isn't meant to replace humans but here to greatly compliment humans in our rail operations. This should be the line of thinking any good transit authority leader should have.

CBTC has lots of cool and interesting advanced features that have helped the transit personnel in my country run our rail system well (both on train and in Control Centre).

Have good faith that the CBTC system can detect the railbreak and respond accordingly. Would like to share some insights from my country.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

In response to your worry "if a rail breaks on lets say the  between 1st Avenue and Bedford Avenue, and CBTC can't detect it, it will continue to go at the posted speed and the consequence can be deadly."

"In Singapore for our 2 oldest lines, we also use Track Circuits to detect our trains. Our Thales SelTrac CBTC was ordered by our Land Transport Authority (equivalent of  ) to interface with our Track Circuits. Whenever we encounter a Track Circuit Failure - which has a slight chance of it being a rail break, our CBTC ATS based on block occupancy logic will pick out that such sudden occupancy is indeed a Track Circuit Failure. The ATS will then automatically demand the interlocking to impose a 18kph (~11.25 mph) Temporary Speed Restriction (TSR) on that track section until the Track Circuit can be attended to by field staff. 

The Vehicle On-Board Controller in all incoming trains will immediately receive this information via the Radio Communication and the VOBC will recalculate based on current train position, a suitable braking profile to get the train to 18kph before the start of TSR. The train is able to proceed through the TSR in Automatic Mode before accelerating back to normal speed once past the area.

Through the entire process, the Train Attendant (formerly Train Operators) at our Cab Console still doesn't need to intervene and do manual driving. But based on our procedures, he would still be expected to observe the track as the train passes.

This degraded mode of operations in CBTC has delivered immense improvements for us. Under the older fixed block signalling, such a track circuit failure causes 10mins delay to service. Today, almost none.

Under the older fixed block signalling, our Train Operators are to switch to a Restricted Manual mode and personally drive the train at 18kph over the failed track circuit. But because they must stop their train, get authorisation to proceed through. This wasted crucial time in train service. But today, the train automatically slows down and it can still stay in Automatic Mode. Nothing else. except observing the track, needs to be done"

For NYCT, You definitely will have a similar safety case like mine. Do not worry too much. With CBTC, we must cover more ground. 

I'm not sure how much everyone here understands about CBTC. But I can tell you - from a country where now all our lines are CBTC (our first new CBTC line in 2003) - the art of having CBTC isn't simply about just making train operation automatic and moving block system.

For the increased degree of automation and possibly "unattended" operation - we must compensate & account for many safety cases for our CBTC system to respond accordingly should any safety-critical failure or defect occur in the operating railway because now, we are now relying less on humans to enforce safety-related actions. The Thales Seltrac "computer" is now going to do the exact same thing for us. This "computer" would collectively refer to ALL CBTC sub-systems. They must interact well with each other and react correctly to the failure and put the railway in a fail safe state in response to the failure/defect.

This is definitely something  and Thales will work on hand-in-hand, very closely, whilst the SelTrac product is being designed to fit NYCT's operating requirements just like how we have done it in Singapore. Before Thales is able to install and commission the working CBTC system on your subway, these safety cases on every aspect of operations: Train, Tracks, Interlocking Software (this will be very complex for you all), ATS, Maintenance, Training Equipment must be approved/understood by all parties and all stakeholders ; satisfied that all potential risks arising from automatic operations in CBTC are either mitigated to a ALARP or completely eliminated.

CBTC safety critical equipment like especially CBI/Train Borne VOBC must be of Safety Integrity Level 4 (SIL) standard where the likelihood of processing error is 1 in many many millions. You can go search it up. The equipment MUST WORK and ALWAYS WORK and if NOT, it must FAIL TO THE SAFER SIDE.

If some major accident/disaster is going to happen in future during CBTC operations, then Yes! You might want to question the MTA on how they managed the project and considered the safety cases - rather than blaming it on CBTC.

CBTC systems intention is to deliver automatic, high-capacity and safe operations, not buggy or flawed software. But a stunning project delivery cannot be achieved with proper/sound project collaboration in the years leading up to CBTC commission. It must be managed properly.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

In response to your worry  "This is why I prefer motorman. ", 

Articles I read from Institution Of Railway Signal Engineers (IRSE) also talked about such worry. But the general consensus is that, we should NEVER EVER REMOVE THE HUMAN from the train. In Singapore, the newest 4 rail lines are running CBTC at Unattended Train Operation level (GOA4). The trains in these lines lack a driving cab - instead the cab is embedded in a removable console cover. They can technically run without even needing Human Attendants on-board. 

It is just a "Supplier Talk" to proclaim that their signalling product is so spectacular such that its trains can run without a human onboard. But as end-users like MTA or the local rail operator, we need to think more down to Earth and be pragmatic on our safety requirements. We should not be so blinded/complacent with "Supplier Promises/Proclaiments".

This is why today in Singapore, we still have the "Motorman" job in those 4 lines today. Its branded as "Customer Service Officer". The 4th line is opening next year and currently there are openings for this role in preparation.

Their job on an 8-hour shift is to

• Board their assigned train based on roster (can be from Depot/Station/Siding) and sit on it up and down until time to rotate to another train.
• When onboard the train, these people are 90% of the time just sitting/standing around like any other passenger. They do not drive the trains but instead act as "Train Attendants" whilst the train itself moves automatically.
• During their stay on the train, they instead are to render assistance to any passenger incidents onboard, look out for suspicious activities/articles and just be general caregivers to passengers during service.
• Only during a signal/train failure/whatever railway system failure, do they need to head front, open up the driving console and do manual driving. The control center will instruct accordingly. In any fire/chemical/terrorist attack emergency, they are to be quick thinking and assist in evacuating the passengers to track via the Detrainment Ramp.
• But most of the time, they literally do nothing. They are mainly monitoring/supervising. These lines are so reliable that there are minimal incidents/failures to attend to. But yet, we can't do away with the role. We do not rest on our laurels that just because our rail lines are so reliable, we devote our stakes completely to computer.

This CSO role is clearly not just about driving. In fact, it covers greatly on passenger service and crisis management. In future, motorman are expected to know even more than what they are knowing today. With advent of technologically advanced systems like CBTC, it may be no surprise that the educational qualification for motorman eventually gets higher too because the job scope won't just be knowing how to drive a train - but more knowing how a train has a relationship with the system and responses to emergencies. Expect better pay for motorman too.

Don't worry. Don't expect NYCT to do away with motorman either. They should not. In fact, expect NYCT to REVOLUTIONISE the role of a motor man in decades to come when more of NYCT becomes automatic with CBTC like mine. The classic job of motorman will tend towards being more of Monitoring/Supervising rather than Operating.

Whoever heading MTA/governor should not tend towards the line of removing Motorman completely in view of saving money. It would be a very foolish thing to do.

 

 

Edited December 1, 2018 by Ethan777

[RR503]

12 hours ago, Jsunflyguy said:

I wouldn't say "just fine" is an appropriate view  of it. This number required a lot of what would be considered "cheating" now, with keying every automatic, actually entering a station on ST, etc. But yes it is true longer trains can be run at a higher throughput than now. Though I don't think that number is achievable any longer, and running the schedule to 100% capacity has the consequence of never being able to recover from a disruption. Although Lexington maintains 28tph which isn't bad considering every A division express that doesn't end at Utica passess over a single switch at Rogers. 

The use of keying by in the old days is overstated. Whatever railfans may say, it was, even back then, a discouraged practice. And this is to say nothing of the fact that, once you account for the extremely slow speed that trains have to achieve when keying, you're not gaining any capacity by doing it rather than waiting for an ST (which is why I believe your point about timid ST use to be so important). 

As for the Lex, it achieves 28 only on paper. Median peak throughput through Grand Central is about 23. 

And re: schedules. Yes, a saturated subway line is one that can easily, well, come out of saturation -- but 30tph is nowhere near saturation. If you go back and read the engineering documents that informed the construction of the subway, you'll find that most of the signal system (after accounting for dwell) was designed for an absolute maximum capacity of just over 40tph. Running 30 thus still leaves a good bit of give in headways; you're running 120 seconds on a system capable of <90. 

12 hours ago, Jsunflyguy said:

Fun point of research has ATS with its computer controlled automatic line-ups improved the A Division on time performance, it doesn't seem so, but the changeover happened in 2009 so no data that have to hand goes back that far.

As I'm sure @Trainmaster5 is just itching to tell you, those gains were illusory. This is not in any way an indictment of centralized dispatching (it is one of RCC culture), but it's a sad testament that when they put a tower op back at Mott, things started flowing better through there. 

12 hours ago, Jsunflyguy said:

The place where this problem primarily exists, Continental received no recent schedule modifications to accommodate this, the last update to the schedule essentially moved some late PM jobs to midnight jobs that wrap around to the morning rush. While the  schedule has improved slightly from the perspective of average hours work (8.24 from 8.28) which, from a cursory glance, seems to be due to some changes in reporting points and modifications to how the shuttle is crewed.  The  which was already everybody's favorite line rose from an average of 8.76hrs to 9.1, and in addition to that the  now wants those same crews to extend their inbound trip 6-10 minutes depending on how long the train will rot in the relay AND start your outbound trip that much sooner. I can see why no one is enthusiastic about enforcing the policy.

If Transit wants to continue down the path of ambiguous training and policies in addition to menacing crews for minor infractions like putting a door panel out (which in the 'good ole days' was a 60 second delay as the t/o keyed the first door or two, but is now a 15 minute ordeal, with the requisite trip to 2 Broadway). Now that they are getting bad press for the policies that they chose, they simply expect the crews to just 'work harder', well I can't see how the crews tolerate it, but I reckon another 1966 is coming in the not-too-distant future.

Yes. In the context of crew schedules, double ended relays certainly aren't optimal. That said, I think this is one area where (at the very least during rush hours) enforcement is non-negotiable. The abysmal operation of relay terminals in this system is one of many reasons we can't have nice things; ameliorating those policies, would, among other things, magically gain us 10tph of Queens-Manhattan capacity. 

Just in general, whoever writes crew schedules in the agency needs to be fired. We have essential tower ops (Dekalb and Queensboro, IINM, among others) doing shift changes in the middle of rush hour. I mean, come on. Even for the MTA, that's bad. 

12 hours ago, Jsunflyguy said:

The identity of the train can be maintained between multiple signal boxes even in a rapid transit application, and the technology has existed since the 50s, it absolutely boils my blood that we have CCTV camera (which has to read an LED that will appear as a red blur in a dark tunnel). Why punching at Pacific isn't good enough, no idea. I suspect that since the  doesn't use workstations for its NX machines (that I've seen) it's just one operator running the whole show and getting overwhelmed (or two people constantly in each other's way)....that would sound about right. The other issue is towers were individually manned with slightly more autonomy than now. At this point one or two people in a master tower supervise an entire line with no realistic way of tracking where trains specifically are, and if that one person is distracted by another issue the whole line suffers, even if they aren't involved in the problem. 

Yeah, this is my read. The justification for the cams I've heard internally is "well, it's an important diverge point with a history of wrong lineups," but that breaks down logically in many places. For one, the spate of wrong lineups was largely caused by the fact that there were never punches at Dekalb; train crews radioed the tower as they approached homes and got lineups that way. Issue is if you have two trains near the home -- the wrong one may get the lineup requested. That is an issue, yes, but if you want to solve it, would it be *that* hard to put the cameras and/or punches at Grand/Dekalb/Pacific/Canal instead of in the tunnels? We moreover have iTrac now; if we are worried about overwhelmed tower ops, we can feed that punch data into a computer that will, come December, be able to somewhat accurately track trains across the entire system. 

But now, why do all of this when we can resurrect IDENTRA? It worked on the ; could its toilet seats be the messiah here? 

12 hours ago, Jsunflyguy said:

I only calculated the core cars, so R68s on the  and 46s on the  were ignored. So it would add 578 core bound cars, which is a 9% decrease from the nominal figure of 4221, I didn't catch the typo on my phone until the edit window closed. 

I ran the same analysis and got a significantly smaller number -- 278 additional cars for 3536 total and a 16% decrease. My tables are below (had to remove '73 as I couldn't figure out how they were counting R44s). 

I want to eventually add some year between '54 and today in, though, if for no other reason that the analysis can't make real comparisons without looking at a world with 10 car platforms on the  and with the 11th St cut. 

Edited December 1, 2018 by RR503

[bobtehpanda]

On 11/28/2018 at 8:12 PM, RR503 said:

I can't speak to past practices, but I know that today crews run through on the  at least. I'd assume they did that back then too... 

As I'm sure our RTO members will tell you, the  is a hell assignment. You're stuck in the cab of a train traversing the most crowded subway line in the nation for two hours (or more). Consequently, many of the folks who run it are quite green -- talk about being broken in -- a fact which doesn't do  capacity any favors. 

I'm surprised they don't have crews switch off at northbound City Hall.

[Stephen Bauman]

On 11/27/2018 at 9:19 PM, bobtehpanda said:

Just to clarify; is this scheduled or real service?

It's worth noting that 1954, IIRC, is before the completion of Chrystie St (1968), the introduction of 75 ft cars with less door area, and the lengthening of platforms to ten cars long across the system. The disadvantage of longer trains is that they require longer blocks and take longer to clear interlockings, and less doors would increase dwells, but I don't know how much of a real effect that would have on max TPH. 

It's fairly easy to calculate the effect of train length on max TPH. Headway is the inverse of TPH, with a change from hours to seconds. 40 TPH translates to a 90 second headway. Part of the headway calculation is the time it takes a leader to clear a block for the follower. The leader will usually achieve cruising speed before the block between him and the follower is cleared. If we assume that cruising speed is 30 mph (45 ft/sec) and train lengths were increased from 400 to 600 feet, then it would take an extra (600-400)/45 or 4.4 seconds. Thus the headway would be increased from 90 to 94.4 seconds and the maximum TPH would be decreased to 38 tph.

[bobtehpanda]

On 10/31/2018 at 6:41 AM, Lawrence St said:

I don't like CBTC because it relies on computers instead of human hands. While it works great for the  and because they're isolated, it won't work for the others because of the complexity. 

Humans make mistakes all the time. Computers are better at humans than complexity, which is why we invented them in the first place.

As far as CBTC vs fixed-block, it is worth noting that the MTA has to upgrade signals anyways. Quite frankly, given how they've approached CBTC, I would fully expect the MTA to also f**k up brand-new fixed-block procurement, probably by mandating that it has to interface with the old signals or mandating use of MTA instead of suppliers' workers to install (see: ATS-A on the IRT).

But if we have to upgrade, I would rather spend hundreds of millions of dollars on the top-shelf stuff rather than cheap out on $100M and buy older equipment that is more "reliable" due to MTA incompetence. Because that is how we wound up with magstripe Metrocard in 2018; when it was procured in the '90s, smartcards were already happening and the MTA was even offered them.

[RR503]

18 hours ago, RR503 said:

I ran the same analysis and got a significantly smaller number -- 278 additional cars for 3536 total and a 16% decrease. My tables are below (had to remove '73 as I couldn't figure out how they were counting R44s). 

I want to eventually add some year between '54 and today in, though, if for no other reason that the analysis can't make real comparisons without looking at a world with 10 car platforms on the  and with the 11th St cut. 

Little update in this regard:

Edit: made it a lil easier to read...

Edited December 1, 2018 by RR503

[Lance]

Going forward, please use this thread for general discussion regarding CBTC. This thread may be merged with the other one depending on use.

[Lawrence St]

Is CBTC really needed?

[Stephen Bauman]

1 hour ago, Lawrence St said:

Is CBTC really needed?

You have to define quantitative performance criteria that CBTC must meet, in order to answer that question. First, does CBTC meet all the criteria? Next, are there other technologies that can meet the same criteria? If the first is true, then CBTC would be "sufficient" in a mathematical sense. If the second is false, then CBTC would be "necessary" in the same mathematical sense.

Edited December 6, 2018 by Stephen Bauman

[Jcb]

If it's used to its full potential, it can be a huge boon to the operations of the transit system. However, the inefficiency that NYCT currently operates with makes its potential benefits not worth the cost, as we could easily achieve higher frequencies with the signals that we currently have. It definitely has more frequency potential than fixed block, but at this point in time it's too expensive for what we achieve with it.

[RR503]

On 12/1/2018 at 6:02 PM, bobtehpanda said:

As far as CBTC vs fixed-block, it is worth noting that the MTA has to upgrade signals anyways. Quite frankly, given how they've approached CBTC, I would fully expect the MTA to also f**k up brand-new fixed-block procurement, probably by mandating that it has to interface with the old signals or mandating use of MTA instead of suppliers' workers to install (see: ATS-A on the IRT).

They have to upgrade in some areas, yes. But one fact that many commentators miss is that the fixed block systems currently in place are (generally speaking) not all that old. Much of the IRT was signaled parallel to ATS, IND Culver got during the rehab, CPW/Concourse/Inwood over a period of many years from the '80s onwards, West End, Sea Beach, Brighton all within the past two decades, etc etc etc. What we should be pursuing is thus a phased approach to implementation over the course of, say 20-30 years that focuses on incremental improvements to the fixed block system and competent installation of CBTC -- not an all out foamfest to obfuscate the causes of a completely separate issue, namely, that of system operational meltdown. 

5 hours ago, Lawrence St said:

Is CBTC really needed?

CBTC is necessary if you have a system at saturation and/or if you have an ancient fixed block system. Neither is true in NYC. 

Back to the analysis, I've begun my analysis of ridership patterns and crowding levels. What little I have so far is, once again, damning of MTA practices. The peak-hour subway used to be significantly more crowded (in absolute and sq feet/person terms) than it is today. This is not to say we should defer service expansion until we reach those levels again, but I believe it does present yet another data point that runs counter to this publicly held narrative of overcapacity. 

Beyond the capacity implications of this data, this should raise some questions about operations. None of the '73 throughputs would wow anyone (a result of low car availability, I've been told), but we still managed to run high volume service in what were at times extreme crowding conditions (check out 53rd). Dwell management is a must, and seemingly, a lost art in this city. 

[Lance]

2 hours ago, RR503 said:

They have to upgrade in some areas, yes. But one fact that many commentators miss is that the fixed block systems currently in place are (generally speaking) not all that old. Much of the IRT was signaled parallel to ATS, IND Culver got during the rehab, CPW/Concourse/Inwood over a period of many years from the '80s onwards, West End, Sea Beach, Brighton all within the past two decades, etc etc etc. What we should be pursuing is thus a phased approach to implementation over the course of, say 20-30 years that focuses on incremental improvements to the fixed block system and competent installation of CBTC -- not an all out foamfest to obfuscate the causes of a completely separate issue, namely, that of system operational meltdown. 

Regardless of what's been drafted in the as of yet unfunded Fast Forward plan, most of us know that the entire system does not need CBTC, which is why the original plan was more focused on need. To do otherwise would just be a waste of very finite resources. That's why the focus has always been on the lines where even improvements on fixed block will not allow for the amount of service needed to meet demand. Look at Queens Blvd for example. The express tracks are maxed out at 30 trains per hour and no amount of improvements to fixed block signaling will change that unfortunately, hence the focus there. It's the same reason why both 8th and 6th Avenues are also slated to receive CBTC signaling. The core would benefit from this much more than the single-service lines.

[RR503]

1 hour ago, Lance said:

Regardless of what's been drafted in the as of yet unfunded Fast Forward plan, most of us know that the entire system does not need CBTC, which is why the original plan was more focused on need. To do otherwise would just be a waste of very finite resources. That's why the focus has always been on the lines where even improvements on fixed block will not allow for the amount of service needed to meet demand. Look at Queens Blvd for example. The express tracks are maxed out at 30 trains per hour and no amount of improvements to fixed block signaling will change that unfortunately, hence the focus there. It's the same reason why both 8th and 6th Avenues are also slated to receive CBTC signaling. The core would benefit from this much more than the single-service lines.

I disagree, actually. To use your example of Queens Boulevard, that line's express tracks once carried 34 trains per hour with '30s era signalling -- more than we are projected to get with CBTC. They did this without keying by or anything of that sort; they simply enforced tight schedule adherence, managed dwells, used STs, and didn't have to contend with anywhere near the timer/extended control line burden that we have today. And they didn't have centralized dispatching back then. 

As for 8th and 6th, you've again presented perfect examples of corridors whose capacity is restricted by poor operational decisions. 6th local runs pretty fine, but 6th express has the hellhole that is Dekalb sitting at its south end, and thus is restricted to 20-22 tph peak. Fix that junction (and tweak practices at 59/145) and you'd most certainly have 30tph. Over on 8th, service patterns are the killer. WTC is perfectly capable of turning 24tph, but the 's Brooklyn pattern and the 53 situation means that even if all trains were maxed out, we'd only get 45tph on the line (today, we run 10 , 7  and 15  southbound into the core during the AM rush, for a total of 32tph, meaning even w/o rearrangement there's room for improvement). 

Generally, the idea that CBTC increases capacity is flawed. Fixed blocks enforce train spacing relative to the best possible speed profile for any given area of track. CBTC allows you flexibility, sure, but that does not in any way change the fact that when you're descending below that optimum profile, you're losing capacity. So what CBTC really does is take the human element out of calculations -- an insignificant change at the throughputs we run/will need to run. This isn't to say I don't think we should have it (again, useful for when service gets crappy), but it needs to be treated as such -- a 'nice to have' instead of a 'we'll die if we don't have.' We risk sinking untold billions into what amounts to a golden parachute for those incompetent managers who created this crisis. 

 

[Around the Horn]

1 hour ago, RR503 said:

As for 8th and 6th, you've again presented perfect examples of corridors whose capacity is restricted by poor operational decisions. 6th local runs pretty fine, but 6th express has the hellhole that is Dekalb sitting at its south end, and thus is restricted to 20-22 tph peak. Fix that junction (and tweak practices at 59/145) and you'd most certainly have 30tph. Over on 8th, service patterns are the killer. WTC is perfectly capable of turning 24tph, but the 's Brooklyn pattern and the 53 situation means that even if all trains were maxed out, we'd only get 45tph on the line (today, we run 10 , 7  and 15  southbound into the core during the AM rush, for a total of 32tph, meaning even w/o rearrangement there's room for improvement).

Your point about 8th just reinforces the idea that's been in my head for awhile that we will eventually come to a point where the only option to increase service is to reorganize B division services based on maximizing throughput as much as possible (i.e. designing services based on "threading" together line segments in the most efficient way possible rather than keeping existing services intact.)

[RR503]

6 hours ago, Around the Horn said:

Your point about 8th just reinforces the idea that's been in my head for awhile that we will eventually come to a point where the only option to increase service is to reorganize B division services based on maximizing throughput as much as possible (i.e. designing services based on "threading" together line segments in the most efficient way possible rather than keeping existing services intact.)

Absolutely. Sooner rather than later, there will need to be some sort of deinterlining. 

That said, we equally can’t lose sight of deficits in current service patterns. On 8th, the only line that can’t run more s/b trains today is the ; you could add 8 trains on the  and 5 on the  tomorrow with competent merge ops at Canal and no service reorganization. This issue holds on 6th and to a lesser extent on Broadway. So yes, we absolutely need to work on service patterns, but we equally need to work on service. 

[6 Lexington Ave]

At the point the system is right now, perhaps the only way forward is CBTC. I don't know the details of subway operations and my observations are from being a regular subway rider. The current crisis, in my opinion, is the result of the TA's knee-jerk reaction to accidents and incidents that have occurred over the course of the years and their overzealous approach on safety. Because of this approach, the effects those measures had on capacity were not taken into account until they had an adverse effect on the subway actually being able to run the scheduled trains, be it because of timer proliferation, ridiculous terminal procedures, lax attitude by RCC on how much service is actually run vs scheduled and overcautious train operators coupled with the slowing down of trains themselves. 

We now have a subway network that is riddled with timers that have effectively destroyed capacity potential. And this is were CBTC will actually help, I believe. Because it will give those overly cautious train operators more confidence when manually operating the train, instead of them relying on strict unmaintained timers which slow them down even more then they "have" to. The MTA has to, at this point, look at and follow best practices from all over the world so that it can improve on its basic day to day operations and make them worthy of a system that carries over 5.5 million people per woking day. The NYC subway can no longer be the exception. By switching to CBTC there would be less moving parts in the signaling system that are prone to failure, train speed would be precisely and accurately regulated the subway would be much closer to optimal performance than it is today. These are my thoughts of course.

[RailRunRob]

Welcome Pete Tomlin to the Table

https://www.progressiverailroading.com/people/news/MTA-hires-signaling-expert-to-fix-NYC-subway-signal-system--56273

Edited December 8, 2018 by RailRunRob

[RR503]

A quick methodological note from my earlier sheet: the square footage data was not lifted from NYMTC; their stats are unreliable. I instead subtracted 3' from all car lengths to account for couplers, anti-climbers, end doors, etc, and set the widths to 8.5' for IRT and 9.9' for B div. I am well aware this fails to account for cabs, seats, etc, but without knowledge of car assignments, those stats are impossible to know. Here's the sheet on which I did those calcs; do point out any errors you see. 

15 hours ago, RailRunRob said:

Welcome Pete Tomlin to the Table

https://www.progressiverailroading.com/people/news/MTA-hires-signaling-expert-to-fix-NYC-subway-signal-system--56273

Isn't he the guy who did this?

https://www.newcivilengineer.com/moving-block-signals-finally-go-ahead-on-jubilee-line/796921.article

Edited December 8, 2018 by RR503

[RailRunRob]

27 minutes ago, RR503 said:

Isn't he the guy who did this?

That would be correct sir. For 1500!

[NY1635]

On 12/7/2018 at 7:34 AM, RR503 said:

Absolutely. Sooner rather than later, there will need to be some sort of deinterlining. 

That said, we equally can’t lose sight of deficits in current service patterns. On 8th, the only line that can’t run more s/b trains today is the ; you could add 8 trains on the  and 5 on the  tomorrow with competent merge ops at Canal and no service reorganization. This issue holds on 6th and to a lesser extent on Broadway. So yes, we absolutely need to work on service patterns, but we equally need to work on service. 

Can't the extra southbound  be rerouted over to Hillside and 179th if capacity at Parsons/Archer is at it's peak? 

Edited December 8, 2018 by NY1635