Jump to content

MTA board member slams the agency for misleading New Yorkers about delays in subway service


Via Garibaldi 8

Recommended Posts

It's become a chore mainly because of some of the adolescent smart-asses who have flooded this place in the last 4 years or so. Perhaps there were too many head-in-the-clouds dreamers and drama queens back when you and me first joined, but I've frankly grown tired of all the bean-counters and those who mindlessly support the hi-tech march into oblivion.

Because I have a bit more sense than to believe that a particular switch placement is enough to prevent a particular service improvement from happening, and I know from actual experience that tried-and-true electromechanical designs are inherently more reliable than computerized garbage. And thank Christ I'm not the only one who sees through the folly:

I agree largely with what you say, but this bashing of computer systems is just false. Every CBTC run system in the world has orders of magnitude fewer signal related delays than NYC, a system run on your beloved electromechanical relays.

 

On the same thread, CBTC will make the system so much more flexible. Dispatchers will be able to use all tracks in every direction, allowing for the kinds of service rerouted you suggest with greater ease. I hate to play into the stereotype laid out above, but it really will be a saving grace.

Link to comment
Share on other sites


  • Replies 130
  • Created
  • Last Reply

I agree largely with what you say, but this bashing of computer systems is just false. Every CBTC run system in the world has orders of magnitude fewer signal related delays than NYC, a system run on your beloved electromechanical relays.

 

On the same thread, CBTC will make the system so much more flexible. Dispatchers will be able to use all tracks in every direction, allowing for the kinds of service rerouted you suggest with greater ease. I hate to play into the stereotype laid out above, but it really will be a saving grace.

Adding the fact that:

  • Reaction time with a computer is in the order of microseconds, limited by the physical specifications of the machine which it gets sensory data from and which it controls. So a train can react to minute changes in environmental conditions whereas a human operator would have to wait for a person to finish their sentence over the radio or watch for the right signal.
  • It knows things that a human operator cannot know such as a train around a curve up ahead and exactly what position that train is at and how fast it is moving. Thus, it can operate with much smaller safety margins which are currently generous for the sake of human error.
  • A computer only has to be programmed once and its program propagated to all trains. That saves a lot on operating costs since you only need a person to be responsible as a safety check and backup for emergencies. (The era of robots is upon us, and jobs will be lost just like the end of switchboard operators, travel agents, cashiers, Uber drivers …but people will adapt.)
Link to comment
Share on other sites

 

Adding the fact that:

  • Reaction time with a computer is in the order of microseconds, limited by the physical specifications of the machine which it gets sensory data from and which it controls. So a train can react to minute changes in environmental conditions whereas a human operator would have to wait for a person to finish their sentence over the radio or watch for the right signal.
  • It knows things that a human operator cannot know such as a train around a curve up ahead and exactly what position that train is at and how fast it is moving. Thus, it can operate with much smaller safety margins which are currently generous for the sake of human error.
  • A computer only has to be programmed once and its program propagated to all trains. That saves a lot on operating costs since you only need a person to be responsible as a safety check and backup for emergencies. (The era of robots is upon us, and jobs will be lost just like the end of switchboard operators, travel agents, cashiers, Uber drivers …but people will adapt.)

 

Yeah, that's a non-question at this point it's all going this way.  Adapt and embrace.

Link to comment
Share on other sites

1- There is no confusion. People complain to politicians, politician asks a barely introductory question or bases it on personal experience and huffs, puffs, stamps foot, and declares the state of affairs "unacceptable." Few decision makers are willing to really delve into details, they leave that for all the middle managers. That's why the few decision makers that do deal in details are exceptional at what they do.

 

2- Not talking about the kiddies that come here to argue about train paint schemes and fantasy land where the subway goes to Jersey. Talking about the generally informed posters. I don't even read the kiddie posts anymore unless I feel like trolling someone who I feel deserves it for excessive shitpoasting. Otherwise I ignore the children.

 

4-"Not true" was in response to your post claiming turned trains cause longer waits and delays for the passengers who don't get service because a train is turned. The service remains frequent because of the congestion that necessitates turning the train in the first place. Oftentimes, a train is turned to alleviate this congestion which causes "station to station" delays, where a train arrives almost immediately after the previous train left, and is held until its leader vacates the next station. The wait time is nearly nonexistent in these situations and turning a train in this scenario allows the area of the delay to be reduced by one station, while providing badly needed service in the opposite direction which is likely being underserved at that exact moment due to the bunching.

 

Think of it like this. You ride the 1.

 

-Train #1 has a sick passenger at 137 St. That train has to hold for EMS.

-Train #2 has to hold at 145 St. You don't want trains stuck between stations, so the train will be held.

-Train #3 has to hold at 157 St.

-Train #4 has to hold at 168 St.

-Train #5 has to hold at 181 St.

 

The RCC Dispatcher happens to notice a delay in service going uptown behind the train that just so happens to be at 181 St. going north (Train #6). So the Dispatcher decides to turn Train #4 back uptown to provide uptown service behind that train, until Train #7 arrives, say, 10 minutes after Train #6. If train #4 is turned so that it leaves exactly between the northbound Trains 6 and 7, you've maintained a 5 minute headway.

 

Not only does this provide needed service in the uptown direction, but it also reduces the size of the delay going south. Train #5 can now move up to 168 St. once Train #4 has been turned. Once the sick passenger is cleared up, Train #1 can be given a skip to 96 St., and the next 3 trains (2, 3, and 5) can run regular to pick up passengers and help recover from the delay, which isn't as bad with one less train in that mix.

 

Or, looking at it another way, Train #2 could be crossed to the middle track and operated express to 96 St. to bypass the delay. There are lots of strategies to manage delays, almost all of which Transit already uses. Which one is appropriate depends on the time of day, where on the line the delay occurs, and what direction of travel is more "vital" at that moment at that location. During the AM rush you need to get people into the CBD (Central Business District). During the PM rush you need to get people OUT of the CBD. The proper strategy is always the one that meets that goal, and allows the corresponding terminal that provides that service to run trains as regularly as possible.

 

Turns AND skips both make service better than doing nothing and letting trains idle in stations as incident related congestion builds.

Well I'm not arguing that trains shouldn't be short turned, but I don't see how you can say that passengers aren't delayed and/or do receive the same level of service.  It's physically not possible.  With your example, you eliminated one southbound train, so that's one less train available to passengers heading into the CBD.  Then there's the extra wait for a train.  Yes, you can have that first train run skip stops to catch up, but then there's the crowds of people that now have been waiting and the backup from that, so while the attempt is to get trains back on schedule, you still usually wind up being late as the passenger and the train just isn't as late as it would've been. I know this because I've experienced this very thing.  The only one who may benefit is perhaps someone who gets on a train that runs skip stop but was scheduled to take a later train to begin with.

 

Now it also depends on when such a thing occurs. If it's during the rush then, you usually minimize the delay but you rarely completely eliminate it because of what I mentioned previously.

Link to comment
Share on other sites

Well I'm not arguing that trains shouldn't be short turned, but I don't see how you can say that passengers aren't delayed and/or do receive the same level of service.  It's physically not possible.  With your example, you eliminated one southbound train, so that's one less train available to passengers heading into the CBD.  Then there's the extra wait for a train.  Yes, you can have that first train run skip stops to catch up, but then there's the crowds of people that now have been waiting and the backup from that, so while the attempt is to get trains back on schedule, you still usually wind up being late as the passenger and the train just isn't as late as it would've been. I know this because I've experienced this very thing.  The only one who may benefit is perhaps someone who gets on a train that runs skip stop but was scheduled to take a later train to begin with.

 

Now it also depends on when such a thing occurs. If it's during the rush then, you usually minimize the delay but you rarely completely eliminate it because of what I mentioned previously.

 

Those passengers are going to be sitting on a train in the station regardless. In his example above, passengers from Train #4 still have to wait for Trains #1, 2, and 3 to get out of the way before they can move forward. Whether they're doing so from Train #4 or Train #5 makes no difference in terms of wait time.

 

And by doing so, you let passengers from Train #5 get to 168th Street and at least have a shot at taking the (A) or (C) (whether that was their original plan or their backup plan because of the delay). 

Link to comment
Share on other sites

 

Think of it like this. You ride the 1.

 

-Train #1 has a sick passenger at 137 St. That train has to hold for EMS.

-Train #2 has to hold at 145 St. You don't want trains stuck between stations, so the train will be held.

-Train #3 has to hold at 157 St.

-Train #4 has to hold at 168 St.

-Train #5 has to hold at 181 St.

 

The RCC Dispatcher happens to notice a delay in service going uptown behind the train that just so happens to be at 181 St. going north (Train #6). So the Dispatcher decides to turn Train #4 back uptown to provide uptown service behind that train, until Train #7 arrives, say, 10 minutes after Train #6. If train #4 is turned so that it leaves exactly between the northbound Trains 6 and 7, you've maintained a 5 minute headway.

 

Not only does this provide needed service in the uptown direction, but it also reduces the size of the delay going south. Train #5 can now move up to 168 St. once Train #4 has been turned. Once the sick passenger is cleared up, Train #1 can be given a skip to 96 St., and the next 3 trains (2, 3, and 5) can run regular to pick up passengers and help recover from the delay, which isn't as bad with one less train in that mix.

 

Or, looking at it another way, Train #2 could be crossed to the middle track and operated express to 96 St. to bypass the delay. There are lots of strategies to manage delays, almost all of which Transit already uses. Which one is appropriate depends on the time of day, where on the line the delay occurs, and what direction of travel is more "vital" at that moment at that location. During the AM rush you need to get people into the CBD (Central Business District). During the PM rush you need to get people OUT of the CBD. The proper strategy is always the one that meets that goal, and allows the corresponding terminal that provides that service to run trains as regularly as possible.

 

Turns AND skips both make service better than doing nothing and letting trains idle in stations as incident related congestion builds.

 

That is some expert dispatching you describe there. 

 

I wonder more and more if better dispatching and perhaps even sharp TSS's positioned at "choke points" could help the system cope these days. 

 

I don't listen regularly, but I do have my scanner with me and when I get stuck I do follow along with what's going on. Seems like they could sometimes do a better job working around a BIE or train that has to go OOS, and that these situations could get resolved faster. I know that, in the case of a BIE the crew has to try and find the cause and that can be time consuming - but finding a way to resolve the issue faster could help with a lot of the pain. Some of the dispatching I've heard - we'll say - lacks inspiration. 

 

regardless of what percentage of the delays are rightfully the fault of passengers - the fact is that the high loading of the system exacerbates any and every delay proportional to ridership. 

 

In the situation you describe - train 4 that gets short-turned - the more crowded 168 st gets, the longer it takes to fumigate and change ends. 

 

The more crowded stations and trains are the longer it takes to take a train OOS. And since crowding already drives up dwell times, and increased headway drives up crowding, a BIE or other delay becomes amplified perhaps exponentially. 

 

Now, okay, a TSS isnt gonna be a superhero here, but could clear a train quicker, could theoretically help with BIE. Hell (and this is a reach) some rudimentary EMT training and they could at least get a sick passenger off the train and wait with them for EMS. I am fully aware of the myriad reasons why the last example doesn't hold much water but - you get my point. there's creative thinking that can be applied to make the best of the situation. 

Link to comment
Share on other sites

I agree largely with what you say, but this bashing of computer systems is just false. Every CBTC run system in the world has orders of magnitude fewer signal related delays than NYC, a system run on your beloved electromechanical relays.

 

On the same thread, CBTC will make the system so much more flexible. Dispatchers will be able to use all tracks in every direction, allowing for the kinds of service rerouted you suggest with greater ease. I hate to play into the stereotype laid out above, but it really will be a saving grace.

 

And how many of those systems interline? How many of those systems run 24/7/365? How many of those systems move as many passengers as NYCT does under both of those conditions?

 

The answer is none.

 

It's easy to have no CBTC delays when you can shut the line down every night, or for weeks on end at a time (and even months in some cities!) to perform vital repairs. It's also easy to have CBTC on a line when one of your perfect computer systems decides to malfunction, and only a handful of trains are automatically stopped at the same exact time, instead of the 24 trains that will all go brakes in emergency on the L line during the AM rush if there were to be a line wide CBTC failure (which has happened numerous times by the way since the system was implemented - man is it fun to hear "no service from 8th Avenue to Rockaway Parkway" on the radio!).

 

CBTC makes the system so much more "flexible?" Wow, who knew. Back in the days before a lot of the switches and signals and towers were removed or left idle that accommodated this movement, that flexibility already existed with tower controlled fixed block signalling. In fact, it continues to in places where the switches and signals have been left alone, or modified in an advantageous way. All CBTC has been for the L line is a multi-billion dollar boondoggle that allows the line to run a couple extra trains per hour. Meanwhile, in the time it has taken to design, install, implement, and troubleshoot it, ridership on the L has grown by an order of magnitude far greater than can be simply met by the "extra service" CBTC allows. And the L line is now at capacity, so without major capital investment, it can't really accommodate more trains per hour than it does now.

 

But - best part - CBTC is software! NYCT consists of numerous corridors, all of which can't be upgraded at the same time. Yet, due to interlining, all CBTC elements must be able to communicate with one another at all times! Which means spare no expense when, in 20 years, manufacturers (who, like all tech companies are in the business of "buy THIS not THAT it's NEWER but NOT COMPATIBLE") you're going to have to spend money getting different systems to talk to each other, or you're going to have to habitually make expensive replacements and upgrades to keep all of this "new crap" functional.

 

It's a waste of money that would be far better spent on new corridors. Build a new corridor, get 30 trains per hour. Add CBTC, get 2 trains per hour (maybe). Shouldn't be a tough choice.

Link to comment
Share on other sites

 

Adding the fact that:

  • Reaction time with a computer is in the order of microseconds, limited by the physical specifications of the machine which it gets sensory data from and which it controls. So a train can react to minute changes in environmental conditions whereas a human operator would have to wait for a person to finish their sentence over the radio or watch for the right signal.
  • It knows things that a human operator cannot know such as a train around a curve up ahead and exactly what position that train is at and how fast it is moving. Thus, it can operate with much smaller safety margins which are currently generous for the sake of human error.
  • A computer only has to be programmed once and its program propagated to all trains. That saves a lot on operating costs since you only need a person to be responsible as a safety check and backup for emergencies. (The era of robots is upon us, and jobs will be lost just like the end of switchboard operators, travel agents, cashiers, Uber drivers …but people will adapt.)

 

 

So sick and tired of reading this crap from all the tech fanboys.

 

The reaction time of a human and a computer is negligible. You know what the difference of 1 second in reaction time is at 40 MPH (as fast as most subway trains will go under normal circumstances, other than river tubes or certain highly specific express runs)? About 60 feet. A lot of what CBTC does, station time signals already do. It only helps in areas where signals are spaced far apart, and allows a couple extra trains on each line. That's all.

 

Radio instructions have to be relayed to the crew, and the crew must react. Well guess what about CBTC instructions. They have to be entered into the computer! This process is not instantaneous and must be done by a dispatcher, and it takes time to initiate (longer than it takes to say something over the radio!). CBTC also, in select circumstances, SLOWS DOWN railroad operation beyond what is necessary. Under a standard flagging arrangement, a green "resume" is placed where any non-restricted train will be clear of the work area. Cool - train is out of the work area, resume normal speed. But under CBTC, the entire train must pass the green "resume" before the computer allows it to resume normal speed.

 

Also, this is something pretty much every tech fanboy ever doesn't seem to understand. Computer systems save operating costs ON PAPER ONLY. You still need a dispatcher, a train operator, and a conductor. No one wants to be stuck on a subway train in a tunnel when CBTC fails, with 2000 people on it, and no crew. CBTC or any other computer system cannot safely operate doors in a system that moves 6.5 million people every day under extreme conditions, so you need a conductor too. CBTC does nothing without a dispatcher controlling it. And you need maintainers to maintain all of this equipment, upgrade the software, etc. It's an expensive investment that keeps on spending.

 

The solution to NYC's problems is not more technology for the hell of it. It's building out the system so that we at least replace all of the transit that has been lost since 1950 since over the past 70 years, not much has been added to the system.

 

Seriously - what have we added since the mid 50's???

63rd Street?

Parsons/Archer (which replaced the Jamaica El that actually went farther)?

3 stops on 2nd Avenue?

34th/Hudson Yards?

In 70 years????

 

While losing the Third Avenue El in both Manhattan and the Bronx, the Culver shuttle, the southern half of the Myrtle Ave. el (which would be quite helpful right now, BTW), and others???

 

But please, tech sheep, keep telling us how 2 trains per hour on each line will save us from all this, now and in the not so distant future where ridership spikes even MORE!!!

Link to comment
Share on other sites

That is some expert dispatching you describe there. 

 

I wonder more and more if better dispatching and perhaps even sharp TSS's positioned at "choke points" could help the system cope these days. 

 

I don't listen regularly, but I do have my scanner with me and when I get stuck I do follow along with what's going on. Seems like they could sometimes do a better job working around a BIE or train that has to go OOS, and that these situations could get resolved faster. I know that, in the case of a BIE the crew has to try and find the cause and that can be time consuming - but finding a way to resolve the issue faster could help with a lot of the pain. Some of the dispatching I've heard - we'll say - lacks inspiration. 

 

regardless of what percentage of the delays are rightfully the fault of passengers - the fact is that the high loading of the system exacerbates any and every delay proportional to ridership. 

 

In the situation you describe - train 4 that gets short-turned - the more crowded 168 st gets, the longer it takes to fumigate and change ends. 

 

The more crowded stations and trains are the longer it takes to take a train OOS. And since crowding already drives up dwell times, and increased headway drives up crowding, a BIE or other delay becomes amplified perhaps exponentially. 

 

Now, okay, a TSS isnt gonna be a superhero here, but could clear a train quicker, could theoretically help with BIE. Hell (and this is a reach) some rudimentary EMT training and they could at least get a sick passenger off the train and wait with them for EMS. I am fully aware of the myriad reasons why the last example doesn't hold much water but - you get my point. there's creative thinking that can be applied to make the best of the situation. 

 

They already do all of that.

 

TSS's routinely cover "areas" on all shifts and sometimes are in the right place or on the right train when an incident happens and can help out.

 

In the case of a BIE, it has to be investigated. You have to make sure it is safe before you move, especially if you don't know the cause. Even on a tech train which is supposed to tell you the cause. Just because the 7th car got tripped doesn't mean "shrug" let's go. It means you have to make sure there is nothing unsafe under there. Someone could have fallen between cars. A signal could have malfunctioned, or that basketball those kids threw on the tracks could have tripped the train. If you just move, the train could get tripped again. We don't want trains being tripped when they're moving ever since the sudden stop can cause someone to get hurt. An incident is one thing, but a second trip due to the same cause is a major problem. Having a TSS won't speed this up, a classic case of too many chiefs not enough Indians. The more people that go on the roadbed the worse it gets, because before we move a train in that situation, we have to be sure that everyone is up off the roadbed. Unfortunately there are no shortcuts for that one. The best way to manage that is to hold back service in front of the delay so the gap is not as bad, and try and turn some trains heading in the other direction in front of the BIE to maintain service while the investigation goes on. Where having a TSS helps is when the BIE is in a station since 99 times out of 100 it's a pulled cord and having a TSS can help the crew find it faster. This is already being done.

 

In the case of a sick passenger, everything you describe is already done. TSS's routinely wait with sick passengers on the platform for EMS to arrive so the train can continue its trip.

 

Discharging a train does not take that long. Announce it, close down...crew walks through train and keys off any stragglers. Delays from taking a train out of service usually take no more than 5 minutes. If the train is being discharged and turned, then add whatever time it takes for the Train Operator to change ends to turn back. Not an unmanageable delay, even in rush hour.

 

You are correct that high loading exacerbates every problem. That's why you correct that by building more lines. Redundancy is great. When there is a problem like the one I described earlier on the 1...you know what you can tell people? Take the A or C!!! And if the delay is really bad (such as with a man under), then you can keep turning southbound trains back to Van Cortlandt at 168 St. (basically run the 1 as a shuttle between 168 and 242 until the delay is cleared) and tell everyone getting off at 168 St. to transfer to the A or C to continue their trip downtown. But without that redundancy, you're on an island.

 

We need more lines because there are still too many areas where that's just not an option, and when service goes down, that's all she wrote. That's how you combat crowding, by reducing it and providing alternatives. Look at what Second Avenue did. Now when they decide to knock out Lexington Avenue for Fastrack, let's say, there is another way for people who would like to go to 68th, 77th, 86th, and 96th to get to their destination quickly instead of a shuttle bus.

Link to comment
Share on other sites

So now it's clear: We need more trunk lines rather than CBTC. As much as I agree, do we really see the TA looking to build more lines? Looking how little the expansion has been within the last half century just like you pointed out.

 

The new trunk line, for now, is the Second Avenue Subway. Given that the MTA had trouble finding money for the current Capital plan, even with only a three stop subway expansion, either the MTA needs to be better at convincing people to give it money (through fares, state and city money, etc.), or the MTA needs to reduce costs, for there to be any further, substantial increase in the speed of expansion.

Link to comment
Share on other sites

And how many of those systems interline? How many of those systems run 24/7/365? How many of those systems move as many passengers as NYCT does under both of those conditions?

 

The answer is none.

 

It's easy to have no CBTC delays when you can shut the line down every night, or for weeks on end at a time (and even months in some cities!) to perform vital repairs. It's also easy to have CBTC on a line when one of your perfect computer systems decides to malfunction, and only a handful of trains are automatically stopped at the same exact time, instead of the 24 trains that will all go brakes in emergency on the L line during the AM rush if there were to be a line wide CBTC failure (which has happened numerous times by the way since the system was implemented - man is it fun to hear "no service from 8th Avenue to Rockaway Parkway" on the radio!).

 

CBTC makes the system so much more "flexible?" Wow, who knew. Back in the days before a lot of the switches and signals and towers were removed or left idle that accommodated this movement, that flexibility already existed with tower controlled fixed block signalling. In fact, it continues to in places where the switches and signals have been left alone, or modified in an advantageous way. All CBTC has been for the L line is a multi-billion dollar boondoggle that allows the line to run a couple extra trains per hour. Meanwhile, in the time it has taken to design, install, implement, and troubleshoot it, ridership on the L has grown by an order of magnitude far greater than can be simply met by the "extra service" CBTC allows. And the L line is now at capacity, so without major capital investment, it can't really accommodate more trains per hour than it does now.

 

But - best part - CBTC is software! NYCT consists of numerous corridors, all of which can't be upgraded at the same time. Yet, due to interlining, all CBTC elements must be able to communicate with one another at all times! Which means spare no expense when, in 20 years, manufacturers (who, like all tech companies are in the business of "buy THIS not THAT it's NEWER but NOT COMPATIBLE") you're going to have to spend money getting different systems to talk to each other, or you're going to have to habitually make expensive replacements and upgrades to keep all of this "new crap" functional.

 

It's a waste of money that would be far better spent on new corridors. Build a new corridor, get 30 trains per hour. Add CBTC, get 2 trains per hour (maybe). Shouldn't be a tough choice.

 

 

OK, I'll do this paragraph by paragraph

 

Many. Ex: Shanghai, Tokyo, Beijing, Hong Kong... And all of said systems have interlining. So you're wrong. 

 

Ummmm have you ever read the NYC subway? Ever heard the conductor announce that due to signal problems, the train is going OOS or will just sit and sit and sit....? Computer systems rely on just a few number of parts, connected wirelessly or with fibre optics, removing one of the most common points of failure in our current system. The problem with the way that CBTC was done in NYC was that the MTA (at the request of the unions) decided to integrate it with block signals, creating a technological mess and significantly increasing costs/maintenance. 

 

Your next point again has to do with the way the MTA is doing this. If they got their sorry acts together, and decided to just do it instead of catering to their contractor friends with thousands of contractors doing the work of 1, you wouldn't have the problem you described. 

 

Yes. I agree that new corridors are necessary, but updating of existing ones is also needed. New shiny things are nice, but if all the old stuff doesn't work well, and is in fact using technologies that are *so* outdated that they have to be fabricated specially for the subway, then its time to do some SGR work. 

Link to comment
Share on other sites

So sick and tired of reading this crap from all the tech fanboys.

 

The reaction time of a human and a computer is negligible. You know what the difference of 1 second in reaction time is at 40 MPH (as fast as most subway trains will go under normal circumstances, other than river tubes or certain highly specific express runs)? About 60 feet. A lot of what CBTC does, station time signals already do. It only helps in areas where signals are spaced far apart, and allows a couple extra trains on each line. That's all.

 

Radio instructions have to be relayed to the crew, and the crew must react. Well guess what about CBTC instructions. They have to be entered into the computer! This process is not instantaneous and must be done by a dispatcher, and it takes time to initiate (longer than it takes to say something over the radio!). CBTC also, in select circumstances, SLOWS DOWN railroad operation beyond what is necessary. Under a standard flagging arrangement, a green "resume" is placed where any non-restricted train will be clear of the work area. Cool - train is out of the work area, resume normal speed. But under CBTC, the entire train must pass the green "resume" before the computer allows it to resume normal speed.

 

Also, this is something pretty much every tech fanboy ever doesn't seem to understand. Computer systems save operating costs ON PAPER ONLY. You still need a dispatcher, a train operator, and a conductor. No one wants to be stuck on a subway train in a tunnel when CBTC fails, with 2000 people on it, and no crew. CBTC or any other computer system cannot safely operate doors in a system that moves 6.5 million people every day under extreme conditions, so you need a conductor too. CBTC does nothing without a dispatcher controlling it. And you need maintainers to maintain all of this equipment, upgrade the software, etc. It's an expensive investment that keeps on spending.

 

The solution to NYC's problems is not more technology for the hell of it. It's building out the system so that we at least replace all of the transit that has been lost since 1950 since over the past 70 years, not much has been added to the system.

 

Seriously - what have we added since the mid 50's???

63rd Street?

Parsons/Archer (which replaced the Jamaica El that actually went farther)?

3 stops on 2nd Avenue?

34th/Hudson Yards?

In 70 years????

 

While losing the Third Avenue El in both Manhattan and the Bronx, the Culver shuttle, the southern half of the Myrtle Ave. el (which would be quite helpful right now, BTW), and others???

 

But please, tech sheep, keep telling us how 2 trains per hour on each line will save us from all this, now and in the not so distant future where ridership spikes even MORE!!!

 

And part two!

 

I'll skip the ad hominem stuff, and go to the meat. 

 

The reaction time matters when it comes to automation, which I will speak to below. 

I am not a T/O, and I have never operated a train, so I can't speak directly to what you're complaining about, but that sounds like a UI/system design problem. Again, MTA's fault, not CBTC's. 

 

One thing that ranters don't seem to understand: once CBTC is installed, T/Os, conductors, etc will not be needed. We have seen both in NYC and elsewhere that OPTO at the very least is easy -- except for the part where we have to negotiate with the unions. Fully automated systems are popping up all over the place -- in cities with crowding mind you -- so with a bit of courage, the MTA could eliminate all train crews after they install CBTC (and yes, I know I'm making myself VERY unpopular here by saying that). 

 

So once you've done the above, you have a bunch of cash that you can now use. Put it to work! Build all those fantasy lines that you want. 

 

This is the 21st century. Time to get with it, MTA. 

Link to comment
Share on other sites

So sick and tired of reading this crap from all the tech fanboys.

 

The reaction time of a human and a computer is negligible. You know what the difference of 1 second in reaction time is at 40 MPH (as fast as most subway trains will go under normal circumstances, other than river tubes or certain highly specific express runs)? About 60 feet. A lot of what CBTC does, station time signals already do. It only helps in areas where signals are spaced far apart, and allows a couple extra trains on each line. That's all.

 

Radio instructions have to be relayed to the crew, and the crew must react. Well guess what about CBTC instructions. They have to be entered into the computer! This process is not instantaneous and must be done by a dispatcher, and it takes time to initiate (longer than it takes to say something over the radio!). CBTC also, in select circumstances, SLOWS DOWN railroad operation beyond what is necessary. Under a standard flagging arrangement, a green "resume" is placed where any non-restricted train will be clear of the work area. Cool - train is out of the work area, resume normal speed. But under CBTC, the entire train must pass the green "resume" before the computer allows it to resume normal speed.

 

Also, this is something pretty much every tech fanboy ever doesn't seem to understand. Computer systems save operating costs ON PAPER ONLY. You still need a dispatcher, a train operator, and a conductor. No one wants to be stuck on a subway train in a tunnel when CBTC fails, with 2000 people on it, and no crew. CBTC or any other computer system cannot safely operate doors in a system that moves 6.5 million people every day under extreme conditions, so you need a conductor too. CBTC does nothing without a dispatcher controlling it. And you need maintainers to maintain all of this equipment, upgrade the software, etc. It's an expensive investment that keeps on spending.

 

The solution to NYC's problems is not more technology for the hell of it. It's building out the system so that we at least replace all of the transit that has been lost since 1950 since over the past 70 years, not much has been added to the system.

 

Seriously - what have we added since the mid 50's???

63rd Street?

Parsons/Archer (which replaced the Jamaica El that actually went farther)?

3 stops on 2nd Avenue?

34th/Hudson Yards?

In 70 years????

 

While losing the Third Avenue El in both Manhattan and the Bronx, the Culver shuttle, the southern half of the Myrtle Ave. el (which would be quite helpful right now, BTW), and others???

 

But please, tech sheep, keep telling us how 2 trains per hour on each line will save us from all this, now and in the not so distant future where ridership spikes even MORE!!!Imne

 I agree with everything you said especially expansion I can't tell you many times in discussions especially on the Second Avenue I just couldn't figure out where the extra bandwidth was coming from I tried despite knowing the Math didn't add up. So expansion would indeed render the need for ATO most cases unnecessary thank you I know I'm not crazy.  Now I respect your knowledge and experience with the MTA you're at the pinnacle of your field. A degree in Civil Engineering and internship turned 6-month job at Kawasaki isn't going to trump 20 years experience. I Don't think anyone can deny that I can't you got me there. But with that out of the way, one thing I am qualified to speak on is software and technology What I'm about to say I mean with the utmost respect and I had to learn this myself as a Gen Xer when it comes to Technology and to lesser extent Millennial's there's no winning that war. It's best to embrace and guide em or bring experience to the table. All the twentysomething interns that we have walked through our doors. Entitled overconfident and over complicated used to piss me off to no end. Turns out most just need a little guidance. We know our time is always limited better to have an imprint on the replacement IMO. To your points on ATO/CBTC, everything you said was correct from the current MTA perspective. But I come bearing info and gems from the outside world. Some of the CTBC computers and software are what circa 1999-2004? Updates both hardware and software okay but still limited to the infrastructure of that time. Might as well be 1945 most of the issues you spoke of are well within reach with hierarchical learning systems which have improved leaps and bounds in the last 2-3 years. I visited Uber 4-5 months ago they had dedicated department of data scientists and all working on eliminating latency and algorithmic efficiency this kinda SOA (Service Oriented Architecture) could be flip and used for Rail operations none of this was around in 2010 let alone 2004 or 1999 plus cloud computing for  processing larger datasets, integration, and interoperability and speeder updates. Fred Flinstone designed what the MTA's has now. The point is I wouldn't bet on black (Human Jobs) the MTA could hold out 30 years But the world would upgrade there systems around it electrical grids, Traffic (possibly autonomous) Water, just to name a few it's going to happen Inevitability you and I will more than likely be out of the way I mean after all we all have our time. I'd much rather at least have my input and have a shot a shaping what's to come. I hear a few folks here and it a lot like fear and fear is a major point of weakness. Some of these tech fanboys might go on to be the one to build something major teach em don't bash em. All this information about what trains? What are you going to do with it pass it on.. Just a little food for thought. 

Link to comment
Share on other sites

And part two!

 

I'll skip the ad hominem stuff, and go to the meat. 

 

The reaction time matters when it comes to automation, which I will speak to below. 

I am not a T/O, and I have never operated a train, so I can't speak directly to what you're complaining about, but that sounds like a UI/system design problem. Again, MTA's fault, not CBTC's. 

 

One thing that ranters don't seem to understand: once CBTC is installed, T/Os, conductors, etc will not be needed. We have seen both in NYC and elsewhere that OPTO at the very least is easy -- except for the part where we have to negotiate with the unions. Fully automated systems are popping up all over the place -- in cities with crowding mind you -- so with a bit of courage, the MTA could eliminate all train crews after they install CBTC (and yes, I know I'm making myself VERY unpopular here by saying that). 

 

So once you've done the above, you have a bunch of cash that you can now use. Put it to work! Build all those fantasy lines that you want. 

 

This is the 21st century. Time to get with it, MTA. 

I didn't see this but your 100% as I stated in my post the Latency barrier there able to get around that now. With AI (Machine Learning) Even work arounds dispatches the CPU can handle. Feeling uncomfortable about this I can understand that but this isn't what could happen! This is going to happen. A message from the frontlines. 

Link to comment
Share on other sites

Yeah no, the New York City Subway will never go to full automation. Sure they may go OPTO but ZPTO is bordering on impossible

I can see your point however it won't be because it's not technically possible. Comfortability and the human elements will be the restrictive factors.  I'd like to know someone's on staff mentally can't lie

Link to comment
Share on other sites

So sick and tired of reading this crap from all the tech fanboys.

 

The reaction time of a human and a computer is negligible. You know what the difference of 1 second in reaction time is at 40 MPH (as fast as most subway trains will go under normal circumstances, other than river tubes or certain highly specific express runs)? About 60 feet. A lot of what CBTC does, station time signals already do. It only helps in areas where signals are spaced far apart, and allows a couple extra trains on each line. That's all.

 

Radio instructions have to be relayed to the crew, and the crew must react. Well guess what about CBTC instructions. They have to be entered into the computer! This process is not instantaneous and must be done by a dispatcher, and it takes time to initiate (longer than it takes to say something over the radio!). CBTC also, in select circumstances, SLOWS DOWN railroad operation beyond what is necessary. Under a standard flagging arrangement, a green "resume" is placed where any non-restricted train will be clear of the work area. Cool - train is out of the work area, resume normal speed. But under CBTC, the entire train must pass the green "resume" before the computer allows it to resume normal speed.

 

Also, this is something pretty much every tech fanboy ever doesn't seem to understand. Computer systems save operating costs ON PAPER ONLY. You still need a dispatcher, a train operator, and a conductor. No one wants to be stuck on a subway train in a tunnel when CBTC fails, with 2000 people on it, and no crew. CBTC or any other computer system cannot safely operate doors in a system that moves 6.5 million people every day under extreme conditions, so you need a conductor too. CBTC does nothing without a dispatcher controlling it. And you need maintainers to maintain all of this equipment, upgrade the software, etc. It's an expensive investment that keeps on spending.

 

The solution to NYC's problems is not more technology for the hell of it. It's building out the system so that we at least replace all of the transit that has been lost since 1950 since over the past 70 years, not much has been added to the system.

 

Seriously - what have we added since the mid 50's???

63rd Street?

Parsons/Archer (which replaced the Jamaica El that actually went farther)?

3 stops on 2nd Avenue?

34th/Hudson Yards?

In 70 years????

 

While losing the Third Avenue El in both Manhattan and the Bronx, the Culver shuttle, the southern half of the Myrtle Ave. el (which would be quite helpful right now, BTW), and others???

 

But please, tech sheep, keep telling us how 2 trains per hour on each line will save us from all this, now and in the not so distant future where ridership spikes even MORE!!!

Glad to see I'm not the only one that sees through the CBTC bullshit.

 

So sick and tired of reading this crap from all the tech fanboys.

 

The reaction time of a human and a computer is negligible. You know what the difference of 1 second in reaction time is at 40 MPH (as fast as most subway trains will go under normal circumstances, other than river tubes or certain highly specific express runs)? About 60 feet. A lot of what CBTC does, station time signals already do. It only helps in areas where signals are spaced far apart, and allows a couple extra trains on each line. That's all.

 

Radio instructions have to be relayed to the crew, and the crew must react. Well guess what about CBTC instructions. They have to be entered into the computer! This process is not instantaneous and must be done by a dispatcher, and it takes time to initiate (longer than it takes to say something over the radio!). CBTC also, in select circumstances, SLOWS DOWN railroad operation beyond what is necessary. Under a standard flagging arrangement, a green "resume" is placed where any non-restricted train will be clear of the work area. Cool - train is out of the work area, resume normal speed. But under CBTC, the entire train must pass the green "resume" before the computer allows it to resume normal speed.

 

Also, this is something pretty much every tech fanboy ever doesn't seem to understand. Computer systems save operating costs ON PAPER ONLY. You still need a dispatcher, a train operator, and a conductor. No one wants to be stuck on a subway train in a tunnel when CBTC fails, with 2000 people on it, and no crew. CBTC or any other computer system cannot safely operate doors in a system that moves 6.5 million people every day under extreme conditions, so you need a conductor too. CBTC does nothing without a dispatcher controlling it. And you need maintainers to maintain all of this equipment, upgrade the software, etc. It's an expensive investment that keeps on spending.

 

The solution to NYC's problems is not more technology for the hell of it. It's building out the system so that we at least replace all of the transit that has been lost since 1950 since over the past 70 years, not much has been added to the system.

 

Seriously - what have we added since the mid 50's???

63rd Street?

Parsons/Archer (which replaced the Jamaica El that actually went farther)?

3 stops on 2nd Avenue?

34th/Hudson Yards?

In 70 years????

 

While losing the Third Avenue El in both Manhattan and the Bronx, the Culver shuttle, the southern half of the Myrtle Ave. el (which would be quite helpful right now, BTW), and others???

 

But please, tech sheep, keep telling us how 2 trains per hour on each line will save us from all this, now and in the not so distant future where ridership spikes even MORE!!!

Well the tech fanboys are all idiots anyway. Screw 'em. I bet none of them would even know how to repair a car from before 1990 (it's a good skill to have).

 

OK, I'll do this paragraph by paragraph

 

Many. Ex: Shanghai, Tokyo, Beijing, Hong Kong... And all of said systems have interlining. So you're wrong. 

 

Ummmm have you ever read the NYC subway? Ever heard the conductor announce that due to signal problems, the train is going OOS or will just sit and sit and sit....? Computer systems rely on just a few number of parts, connected wirelessly or with fibre optics, removing one of the most common points of failure in our current system. The problem with the way that CBTC was done in NYC was that the MTA (at the request of the unions) decided to integrate it with block signals, creating a technological mess and significantly increasing costs/maintenance. 

 

Your next point again has to do with the way the MTA is doing this. If they got their sorry acts together, and decided to just do it instead of catering to their contractor friends with thousands of contractors doing the work of 1, you wouldn't have the problem you described. 

 

Yes. I agree that new corridors are necessary, but updating of existing ones is also needed. New shiny things are nice, but if all the old stuff doesn't work well, and is in fact using technologies that are *so* outdated that they have to be fabricated specially for the subway, then its time to do some SGR work.

Dude, he works for the TA; he knows inherently more about how transit systems work than you ever will.

 

And part two!

 

I'll skip the ad hominem stuff, and go to the meat. 

 

The reaction time matters when it comes to automation, which I will speak to below. 

I am not a T/O, and I have never operated a train, so I can't speak directly to what you're complaining about, but that sounds like a UI/system design problem. Again, MTA's fault, not CBTC's. 

 

One thing that ranters don't seem to understand: once CBTC is installed, T/Os, conductors, etc will not be needed. We have seen both in NYC and elsewhere that OPTO at the very least is easy -- except for the part where we have to negotiate with the unions. Fully automated systems are popping up all over the place -- in cities with crowding mind you -- so with a bit of courage, the MTA could eliminate all train crews after they install CBTC (and yes, I know I'm making myself VERY unpopular here by saying that). 

 

So once you've done the above, you have a bunch of cash that you can now use. Put it to work! Build all those fantasy lines that you want. 

 

This is the 21st century. Time to get with it, MTA.

The TWU would disagree with you on that. And if passengers were going to be told that their trains are to be operated by robots, there would be an uproar. Computers will never replace the safety of human operation. Rail accidents would be an order of magnitude more catastrophic if we left it up to computers.

Link to comment
Share on other sites

Glad to see I'm not the only one that sees through the CBTC bullshit.

 

Well the tech fanboys are all idiots anyway. Screw 'em. I bet none of them would even know how to repair a car from before 1990 (it's a good skill to have).

 

Dude, he works for the TA; he knows inherently more about how transit systems work than you ever will.

 

The TWU would disagree with you on that. And if passengers were going to be told that their trains are to be operated by robots, there would be an uproar. Computers will never replace the safety of human operation. Rail accidents would be an order of magnitude more catastrophic if we left it up to computers.

R10 you're reaching a bit have to call you on that. Fix a car before 1990? What does that really mean to someone more than likely born after at point I hear that case made all the time about people that can't code in today's world I don't fully agree there either. What are we talking critical thinking, common sense? What's the plus for skills with vintage and obsolete equipment what are they missing?  Subway Guy is good at what he does no question  I acknowledge and respect his input and experience. I don't mean any disrespect in bringing him up in thid context but these a step before his realm a world outside of TA there are teams of people that work hard to design and build the TA's cars and lines. Without them, there would be no system to know about or cars to quote/un quote foam over I lived in the world a mostly invisible one.  Sponsored by your friends Math and Science. ATO/CBTC by current NYC standards I hear you there all valid. You have some time but you're going to make the argument that you're going to be able out to think a learning system whether or not you understand this is another question I can see how you might think this judging from what you currently see man are you in for a treat. Moral's factored with the human element I'd like to know someone's in the cab at least in 2017 but give society thirty or forty years Millennial's and their offspring might feel different after all they never knew the world without Technology. Might welcome their new overlords with open arms only one way to find out.  2057 here we come!

Link to comment
Share on other sites

I call B.S. on the whole CBTC has reached its capacity thing.

 

The (L) has 24 TPH at best, while the Jubilee line in London, which also has CBTC, runs 30 TPH during the rush hours and 27 TPH during middays and on weekends and in two years will run 36 TPH in the rush periods. If the (L) train can't run 30 TPH, that's on the physical plant and the configuration of the two terminals (and the lack of a third short turn Terminal with a suitable third track) and not the CBTC infrastructure.

 

The fact that the MTA has refused to take any sort of action to fix that (for example, building rail tracks west of 8th Avenue or even a new three track terminus at 10th Avenue) is most certainly something worthy of ire.

 

Now if for some bizarre reason the CBTC system designed for the (L) truly can't handle more trains, that's just plain absurd on their part, and anyone who signed off on that deserves to be fired and should never work on an MTA project again.

Link to comment
Share on other sites

I call B.S. on the whole CBTC has reached its capacity thing.

 

The (L) has 24 TPH at best, while the Jubilee line in London, which also has CBTC, runs 30 TPH during the rush hours and 27 TPH during middays and on weekends and in two years will run 36 TPH in the rush periods. If the (L) train can't run 30 TPH, that's on the physical plant and the configuration of the two terminals (and the lack of a third short turn Terminal with a suitable third track) and not the CBTC infrastructure.

 

The fact that the MTA has refused to take any sort of action to fix that (for example, building rail tracks west of 8th Avenue or even a new three track terminus at 10th Avenue) is most certainly something worthy of ire.

 

Now if for some bizarre reason the CBTC system designed for the (L) truly can't handle more trains, that's just plain absurd on their part, and anyone who signed off on that deserves to be fired and should never work on an MTA project again.

Who's supplying CBTC here in New York? When I was at Kawasaki I remember Mitsubishi working with us on some overseas projects are they in the US market?

Link to comment
Share on other sites

Who's supplying CBTC here in New York? When I was at Kawasaki I remember Mitsubishi working with us on some overseas projects are they in the US market?

 

I don't remember off the top of my head but it was definitely in some old board materials that had to do with the Siemens CBTC test track on Culver.

Link to comment
Share on other sites

I call B.S. on the whole CBTC has reached its capacity thing.

 

The (L) has 24 TPH at best, while the Jubilee line in London, which also has CBTC, runs 30 TPH during the rush hours and 27 TPH during middays and on weekends and in two years will run 36 TPH in the rush periods. If the (L) train can't run 30 TPH, that's on the physical plant and the configuration of the two terminals (and the lack of a third short turn Terminal with a suitable third track) and not the CBTC infrastructure.

 

The fact that the MTA has refused to take any sort of action to fix that (for example, building rail tracks west of 8th Avenue or even a new three track terminus at 10th Avenue) is most certainly something worthy of ire.

 

Now if for some bizarre reason the CBTC system designed for the (L) truly can't handle more trains, that's just plain absurd on their part, and anyone who signed off on that deserves to be fired and should never work on an MTA project again.

To this point what would the issue be? The Wayside ATP/ATO system if I remember correctly is what manages communications and regulates movement distance and dwell time. I'm not a expert but could the issue be there maybe?

Link to comment
Share on other sites

I don't remember off the top of my head but it was definitely in some old board materials that had to do with the Siemens CBTC test track on Culver.

Yeah found it you were correct. Siemens and Thales. Don't see Mitsubishi anywhere im trying to remember what that project was? They might have been building an inter operability system between the different systems maybe. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.