Positive Train Control Myths and Facts

Jtgshu wrote:back to PTC, pardon my ignorance, but how would/can it work on roads WITHOUT cab signals?

Cab signals are not a pre-requisite for PTC. In fact, since its primary purpose is to enforce authorities, you can use it alongside any system used to grant movement authority. Which includes, of course, non-cab wayside signals w/CTC. Or even dark territory with DCS or TWC.

Jtgshu wrote:I understand that PTC has been on a wishlist for a long time by the feds, but would installng cab signals ATC/ATS be a more realistic goal? Sure, cab signals aren't going to prevent every collision, and collisions can still happen in cab signal territory, but they tend to in much lesser numbers. (of course, you can't forget about Chase MD)

Well, cab signals would certainly be more "do-able", but cab signals are reactive in nature, whereas PTC is proactive. You've hinted at it yourself - cab signal/ATC doesn't have the ability to stop a train before it passes a red signal, fouling point, etc. PTC does. That's why the Feds are requiring it.

Jtgshu wrote:This seems to be an incredible burden placed on the railroads, and seems like it was a knee jerk reaction to an incident by politicans who really don't understand the scope of what they want the railroads to do...

I agree, and I think this is one of those cases of the perfect being the enemy of the good. PTC, as the "perfect" solution, will gut every passenger railroad's and most freight railroads' capital budgets. Not much else will be getting done besides PTC because it's so expensive. And it will be expensive to operate and maintain, as well.

NellieBly's comments were good, but a little off when it comes to the discussion of cost. Just about *every* piece of wayside hardware will need to be equipped with a WIU, all of which will have to be maintained at all times. They will be in the remotest locations, the most unreachable territory as well as the easiest to access. The FRA's own estimate of annual maintenance costs for PTC after full installation is almost $1 BILLION. Every year. And we all know how good the government is with basic economic analysis. "Stimulus". I rest my case.

Regarding calculation of a braking algorithm - this is no red herring. I know. I'm working with a team on on an actual passenger PTC installation right now. Calculation of a passenger train braking algorithm is not easy because you need to take into account worst case rail condition, and then go a little more conservative than that. This is, of course, while balancing the throughput and capacity needs of the railroad.

Picture it like this - a train is cooking along at 79 MPH. A 30 MPH speed restriction is coming up. There is a theoretical "perfect" braking curve that will bring the train down to 30 MPH *just* before it enters the speed restriction. The train will never reliably do this, even under unguided fully manual control with the best engineer due to differences in conditions, equipment performance, etc. A little further back from that is the PTC "enforcement" braking curve, which takes into account worst case adhesion and other factors that could conspire to lower the train's braking performance below the nominal. A little further back from that is the PTC "warning" curve, where the PTC system will alarm if the engineer is not slowing the train sufficiently. This is determined by time - should the alarm happen 10 seconds before enforcement kicks in? 20 seconds? 30 seconds? Finally, we come to the actual performance braking curve, where an engineer who is used to the system will begin braking his or her train. Studies with cab signal systems have shown time and again that engineers, when they have a cab signal step-down in the same place every day (say, before a cab-enforced speed restriction such as the Elizabeth curves on the NEC) will run their trains in such a way as to avoid the alarm. This is called "pre-action", and engineers usually don't even know they're doing it - it's a conditioning that occurs when you run the same territory over and over again. Subtle visual cues are imprinted in the engineer's mind, and he or she almost subconsciously gets on the brake whenever those cues pop into their visual range.

You can see how the PTC system's calculation of its "enforcement" curve becomes critical. If you go too conservative, you push the other curves back, which elnongates stopping and reducing distances, reducing average speeds, throughput, and capacity. So this issue is no "red herring", as NellieBly contends. It's a real, make-or-break proposition when you're dealing with high capacity systems like the larger commuter rail lines.

So, now you're a signals and comms guy. You have to design a system that, failsafe, stops a train every time before it gets into a position to strike another train or vehicle, or fouls a conflicting route, or hits a derail, or goes over a switch in the wrong position, or goes through a curve too fast. Said system also has to minimize the hit to throughput and capacity, even though, as demonstrated, you've already de-rated the train's braking peformance, possibly substantially. Said system must mostly rely on GPS (pretty accurate) and odometer (not as accurate, and the system has to add in "uncertainty" whenever it loses GPS, de-rating braking performance yet more). It's the classic struggle between pushing trains through and stopping them.

Think that's easy? Think there are "red herrings" involved? Sorry, as someone who is actually doing the work, and not just driving train simulators, I beg to differ.

The above post echoes the claims the freight railroads have made. But let me make my point another way.

In 1969, the PATCO High Speed Line from Philadelphia into New Jersey became the first rapid transit line in North America to operate under full ATO (automatic train operation). It was primitive by modern standards -- just a bunch of relays, no computer in the modern sense -- but PATCO justified the cost of the equipment on the strength of a finding (validated by an early version of train simulation software) that the improved (yes, improved) performance made possible by ATO would enable them to save the cost of one six-car trainset, which paid for the ATO.

I've been in PATCO's control center, and the dispatchers say they can always tell when a train is operating under manual control because it falls behind the schedule.

Now I know six-car rapid transit trains are not 20,000 ton freights, but they still have to deal with variable adhesion, hills, curves, speed restrictions, and mechanical failures. Yet with this primitive ATO, PATCO was able to achieve better performance than a human engineer could achieve.

That was 40 years ago. I think we've learned a bit about train handling since that time, and computers have sure gotten better. I have no reason to believe that trains will run more slowly under PTC. They don't on PATCO.

NellieBly wrote:That was 40 years ago. I think we've learned a bit about train handling since that time, and computers have sure gotten better. I have no reason to believe that trains will run more slowly under PTC. They don't on PATCO.

ATO on this relatively short, homegenously-equpped line is cut out any time that rail conditions drop below optimal. Think the Feds are going to let railroads simply cut out PTC?

This "A happens, then B happens....*THEN COMPUTERS DO SOMETHING UNDEFINED BUT WONDERFUL*...and we get to c" argument is typical of folks who aren't charged with actually doing the work of getting PTC up and running.

The railroads are just going to have to make it work by 2015. There is zero chance Congress will change the law.

If PTC will cost 10-15 billion to install and 1 billion annually to maintain you would have to fine railroads MORE than that or it will simply be cheaper to pay the fine and not install PTC. Mark my words, when every commuter system in the country lines up in Washington with their hands out because of the hole PTC blew in their budgets Congress is going to have second thoughts and scale things back or rely on FRA waivers to pass the buck. I mean hell, the clean water act sets all these pollution and drinking water standards, but every year we hear some huge percentage of cities aren't in compliance. That's the "law" too.

Now I know six-car rapid transit trains are not 20,000 ton freights, but they still have to deal with variable adhesion, hills, curves, speed restrictions, and mechanical failures. Yet with this primitive ATO, PATCO was able to achieve better performance than a human engineer could achieve.

PATCO ATO simply accelerates and decelerates at the maximum rate given the plain old cab signal speed. Of course human operators are not going to do better than that by definition. However that is not the comparison you should be making. As the guy who did the track and speed diagram on NYC Subway.org I know a few things about the PATCO speed profiles and if the line speed restrictions were not enforced in manual mode, the human operators would beat the ATO by a good margin. For example, inbound to Walter Rand the train gets a CSS drop from 65 to 40 about 1750 feet from where a train could be safely braked for the 30mph restriction at the tunnel mouth. Or outbound over the bridge trains get a code drop from 40 to 30 some 1000 feet before the curve. There are several other similar situations where an operator using their own skill would be able to beat the ATO and that's not even factoring in them cutting corners. Don't say that's unsafe either, because speed restrictions are always calculated with a margin of error and over time the operators learn how fast they can go without derailing.

PTC (not "cab signals") has been on the NTSB's "most wanted" list since 1992.

I'm sorry, I was a little imprecise in my terminology. Before 2001 they referred to "Positive Train Separation", see #5 here.

http://www.ntsb.gov/recs/mostwanted/original_list.htm

That was basically a PRR cab signal system with some additional speed control smarts in it.

Regarding calculation of a braking algorithm - this is no red herring. I know. I'm working with a team on on an actual passenger PTC installation right now. Calculation of a passenger train braking algorithm is not easy because you need to take into account worst case rail condition, and then go a little more conservative than that. This is, of course, while balancing the throughput and capacity needs of the railroad.

Thank god someone can back me up on this and everyone should be ruing the day that PTC is installed because its basically going to turn our railroads into New York City Transit. Great, ye old cab signal box is going to have to assume the rails are covered in ice and THEN have a safety factor built in. Why don't we just stick to Restricted speed now and save all the money. Quick question for you, has nobody suggested that the safety factor built into the speed restrictions should be the safety margin that the PTC has to work with instead of adding a second safety factor?

This is called "pre-action", and engineers usually don't even know they're doing it - it's a conditioning that occurs when you run the same territory over and over again. Subtle visual cues are imprinted in the engineer's mind, and he or she almost subconsciously gets on the brake whenever those cues pop into their visual range.

That's the mark of distinction between a good engineer and a bad engineer. Good engineers will run right through the signal, wait for the cab signal drop and THEN wait a few seconds before actually beginning to break just before they get hit with the penalty application. Like a PATH engineer charging a timer w/o a speedometer, its a real indication of skill and professionalism.

Said system must mostly rely on GPS (pretty accurate) and odometer (not as accurate, and the system has to add in "uncertainty" whenever it loses GPS, de-rating braking performance yet more). It's the classic struggle between pushing trains through and stopping them.

I'm surprised that they are still pushing so hard for the GPS option. What's wrong with track mounted loops and beacons? Navigational beacons don't even need any dynamic components. Another out for at least the overlay systems is that they shouldn't have to be perfect. Engineers can stop their trains in a safe manner 99.99999...% of the time. If the PTC even has just 2 9's of reliability that still means that 99 out of 100 stop signal violations that would have occurred before, are now prevented. As you said perfect is the enemy of good. The only question will be how long before someone notices that the emperor has no clothes.

This reminds me of that stupid virtual border fence that DHS dropped a billion dollars on and then had to scrap because it was completely useless. They are on round two right now which can actually pull off pre-canned demos.

Now there is an untrue statement , The 800 000 Lbs buff strenght have been in effect for(at least) last 40 years, long before Bombardier ever made its first Skidoo.
even 1956 RDC's were made with those requirements, only thing changeed in last few years is requirement of corner coliision post.

My source is http://frwebgate.access.gpo.gov/cgi-bin ... 5539-25588

B. Static End Sstrength Requirement: Application to Existing Equipment In Sec. 238.203 of the 1997 NPRM, FRA generally proposed that on or after January 1, 1998, all passenger equipment shall be required to have a minimum static end strength (or ``buff'' or ``compressive'' strength) of 800,000 pounds. As some commenters recognized, FRA intended the date of January 1, 1998, to represent the effective date of the final rule. Yet, in light of the actual publication date of the 1997 NPRM, the date of January 1, 1998, appeared anachronistic, and FRA should have modified the NPRM to make its intent more explicit. A number of commenters nonetheless raised concerns with the application of this section-whether the date were January 1, 1998, or later-since FRA proposed to apply the static end strength requirement to existing passenger equipment.

The date was Jan 1, 1998 for the 800,000 lbs buff strength.

Amtrak commented that the proposed requirement to have buff loading apply to the existing rail fleet is not justified based on the industry's experience. Amtrak did agree that, in order to move the industry forward on crash energy management, new equipment must be built to a uniform strength standard. Amtrak stated that it currently operates AEM-7 locomotives that do not meet the proposed requirement.

Jersey_Mike wrote:Thank god someone can back me up on this and everyone should be ruing the day that PTC is installed because its basically going to turn our railroads into New York City Transit. Great, ye old cab signal box is going to have to assume the rails are covered in ice and THEN have a safety factor built in. Why don't we just stick to Restricted speed now and save all the money. Quick question for you, has nobody suggested that the safety factor built into the speed restrictions should be the safety margin that the PTC has to work with instead of adding a second safety factor?

Well, the question is - what is the brake rate that should be assumed? Because that's what will determine enforcement. If the CE-205 safe braking model is used, then it's 0.88 mphps, which is substantially lower than nominal service braking rates of passenger equipment (1.5 mphps), or even the experimentally established "actual" average service braking rate of 1.15 mphps. The safety factor is built into the brake rate. The lower you assume the wheel-rail adhesion to be, the lower the effective brake rate you assume.

Jersey_Mike wrote:That's the mark of distinction between a good engineer and a bad engineer. Good engineers will run right through the signal, wait for the cab signal drop and THEN wait a few seconds before actually beginning to break just before they get hit with the penalty application. Like a PATH engineer charging a timer w/o a speedometer, its a real indication of skill and professionalism.

Well, not so much. What the PATH engineer is doing is gaming the speed control system. It might be an indication of skill, but I don't know about the "professionalism" part. And actually, that charging behavior is more a proof of my point - they get a "feel" for the timer, without even realizing they're doing it, because they run the territory so many times a day, so many times a week. There's a conditioning effect that comes into play. Same with enforced speed restrictions with cab signal drops. It's the "here comes that building with the red door"...brake syndrome. I should, of course, clarify that this only applies in "cab, no wayside" territory. If you have preview of a wayside signal, then generally you don't get so much pre-action (unless the signal is displaying Cab Speed).

Well, not so much. What the PATH engineer is doing is gaming the speed control system. It might be an indication of skill, but I don't know about the "professionalism" part. And actually, that charging behavior is more a proof of my point - they get a "feel" for the timer, without even realizing they're doing it, because they run the territory so many times a day, so many times a week. There's a conditioning effect that comes into play. Same with enforced speed restrictions with cab signal drops. It's the "here comes that building with the red door"...brake syndrome. I should, of course, clarify that this only applies in "cab, no wayside" territory. If you have preview of a wayside signal, then generally you don't get so much pre-action (unless the signal is displaying Cab Speed).

I am not familiar with timer signals, but there is nothing detracting from an Engineers professionalism by having complete control over his train. One quality of a good Engineer is beating the code drops to the punch, knowing the location and sequence of the normal code changes. You have to very much be aware of what you are doing, and remember to put on brake. If you did not realize, you would be hitting that code.

Jersey_Mike wrote:
I'm surprised that they are still pushing so hard for the GPS option. What's wrong with track mounted loops and
beacons?

Nothing. IMHO, GPS is because of hammer/nail issues more than any technical reason. When you're holding a hammer, EVERYTHING looks like a nail...

Amtrak commented that the proposed requirement to have buff loading apply to the existing rail fleet is not justified based on the industry's experience. Amtrak did agree that, in order to move the industry forward on crash energy management, new equipment must be built to a uniform strength standard. Amtrak stated that it currently operates AEM-7 locomotives that do not meet the proposed requirement.

The 800,000 lbs standard was a recommendation prior to then. Actually, it was an AAR guideline. Nothing the AAR says is legally binding, though. IIRC, Budd's stuff tended to test a bit higher than 800,000 lbs.

Jersey_Mike wrote:Like it or not, EVERY new safety related system has slowed down operations. If you want the best headways you run on sight and live with the occasional accident.

Counterexample: Docklands Light Rail.

RogerOverOutRR wrote:I am not familiar with timer signals, but there is nothing detracting from an Engineers professionalism by having complete control over his train. One quality of a good Engineer is beating the code drops to the punch, knowing the location and sequence of the normal code changes. You have to very much be aware of what you are doing, and remember to put on brake. If you did not realize, you would be hitting that code.

Grade time signals are an old-school method of speed control in use on older rapid transit systems. They are intended to enforce a certain safe speed by holding the next signal in advance at red until a timer counts down. The timing value is determined by the desired speed and the length of the signal block. Rushing up to a red signal is not a sign of professionalism, it's a sign that the engineer has become conditioned to the timing and is making a (hopefully correct) judgment call that the signal will change just before his train passes it. Best case, the track ahead is clear and the signal, being held at Stop only by the timing mechanism, changes just as train sails through. Worst case, the signal is at Stop due to another train ahead just beyond the insulated joint, and the train sails through the signal, gets tripped by the stop arm, but there's a collision.

Your point about engineers knowing where code drops are, even if there's no corresponding wayside signal (which is the case in "cab no wayside" systems, or where there are code rate timers) is an illustration of my previous point about engineer "pre-action". I don't really have an opinion one way or the other in this case, but your point that this illustrates professionalism on an engineer's part (pre-acting to code drops) is in direct contradiction to Jersey Mike's.

Jersey_Mike wrote:Quick question for you, has nobody suggested that the safety factor built into the speed restrictions should be the safety margin that the PTC has to work with instead of adding a second safety factor?

I think several people have suggested that, in fact. As far as I can tell that's what they do in the UK.

In fact I read some EU report about ERTMS cautioning specifically against using double safety factors.

Not sure whether this has percolated into US practice, but it's certainly been discussed elsewhere.

Jersey_Mike wrote: How does an algorithm learn what the weather conditions are and how they affect train handling? If you are in a train and it starts to rain do you hit a rain button or do the speed algorithms just assume that the tracks are always covered in ice? What happens when a train following the dry braking curve slides past a signal on wet track and the algorithms are required to assume the tracks are always covered in ice and travel times on Amtrak trains increase by 20%?

I'm fairly sure that places like the DLR have speeds designed for "normal" track conditions and slowdowns for troublesome track conditions are programmed in by the dispatchers. I'm not sure how that would work on a national level (in a system as small as the DLR, the entire system has the same track conditions, barring a tree on the line).

BTW, do you realize that 22,000ton ore train is HOMOGENEOUS!! Every car ore car is the same and carries the same load. That's a piece of cake to calculate stopping curves for. Also, what is the grade profile of the line? Florida East Coast is the only major freight railroad currently using cab signal w/ speed control and surprise surprise Florida is COMPLETELY FLAT. Finally how do you teach a PTC system when its better to let a train exceed the stopping parameters because applying the air brake will lead to a runaway situation?

Competent programming. This is really easy stuff in a fully automated system.

neroden wrote:

Jersey_Mike wrote:Quick question for you, has nobody suggested that the safety factor built into the speed restrictions should be the safety margin that the PTC has to work with instead of adding a second safety factor?

I think several people have suggested that, in fact. As far as I can tell that's what they do in the UK.

In fact I read some EU report about ERTMS cautioning specifically against using double safety factors.

Not sure whether this has percolated into US practice, but it's certainly been discussed elsewhere.

The safety factor we're discussing applies to stopping and reducing distances, not to the speed restrictions per se. For example, by assuming a service braking rate of 0.88 mphps, the American passenger railroads have for some time been implicitly incorporating a safety margin into their signal designs.

neroden wrote:

Jersey_Mike wrote: How does an algorithm learn what the weather conditions are and how they affect train handling? If you are in a train and it starts to rain do you hit a rain button or do the speed algorithms just assume that the tracks are always covered in ice? What happens when a train following the dry braking curve slides past a signal on wet track and the algorithms are required to assume the tracks are always covered in ice and travel times on Amtrak trains increase by 20%?

I'm fairly sure that places like the DLR have speeds designed for "normal" track conditions and slowdowns for troublesome track conditions are programmed in by the dispatchers. I'm not sure how that would work on a national level (in a system as small as the DLR, the entire system has the same track conditions, barring a tree on the line).

You've inadvertently hit the nail on the head. On a relatively short line that uses the same or very similar equipment, this is fairly trivial. However, even slightly larger systems (to say the least of commuter rail systems that might travel 40 to 90-odd miles) can very easily have a wide range of track conditions. It's not possible to "push a button" and just make everything OK. This is, again, one of those "and then something happens" arguments.

neroden wrote:

Jersey_Mike wrote:BTW, do you realize that 22,000ton ore train is HOMOGENEOUS!! Every car ore car is the same and carries the same load. That's a piece of cake to calculate stopping curves for. Also, what is the grade profile of the line? Florida East Coast is the only major freight railroad currently using cab signal w/ speed control and surprise surprise Florida is COMPLETELY FLAT. Finally how do you teach a PTC system when its better to let a train exceed the stopping parameters because applying the air brake will lead to a runaway situation?

Competent programming. This is really easy stuff in a fully automated system.

More "and then something happens" logic. Have you ever designed a train control system? I'm not trying to be an @ss, but it's very frustrating for people who actually work in the field to be told how "easy" something is by people who have no idea.

Your point about engineers knowing where code drops are, even if there's no corresponding wayside signal (which is the case in "cab no wayside" systems, or where there are code rate timers) is an illustration of my previous point about engineer "pre-action". I don't really have an opinion one way or the other in this case, but your point that this illustrates professionalism on an engineer's part (pre-acting to code drops) is in direct contradiction to Jersey Mike's.

I think you failed to see that I was disagreeing with your thought that Engineers do not think, and just react subconsciously. This is all part of an Engineers knowledge, which requires thought.

Jersey_Mike wrote:If PTC will cost 10-15 billion to install and 1 billion annually to maintain you would have to fine railroads MORE than that or it will simply be cheaper to pay the fine and not install PTC.

The easiest fine is a speed restriction. If you don't have working PTC your trains can't go faster than 40 MPH. Pick the speed that would get railroads to act.

Jersey_Mike wrote:Quick question for you, has nobody suggested that the safety factor built into the speed restrictions should be the safety margin that the PTC has to work with instead of adding a second safety factor?

If an engineer pushes the limits of a speed restriction and loses one can fire them (or bury them, depending on the outcome). One cannot fire the computer. You can only make it safer by adding in more and more margins (run the trains slower and more conservative).

Look back into history ... Trains ran fast and loose with humans feeling their way along the rails. Then reality caught up with the odds and a major wreck occurred. Then someone said "hmm, perhaps we need some automatic block signals on the railroad" or "perhaps we need a deadman pedal". And ever since raliroads have been innovating the next level of signaling and human override. No more fast and loose. Less risk (which is good) but less speed unless the route is completely redone with grade separations, bypasses and other very expensive changes.

So go ahead, run your system into the safety margins ... and prepare to lose lives, your job and perhaps everything you have ever worked for when your choice becomes "reckless endangerment" in a court of law.