In the forthcoming April, 2012 issue of Railway Age, I expose the tremendous over-design of PTC by the railroad’s technicians. Specifically I refer to the issues of 220 MHz for a wireless network that is totally unjustified given the railroads current available wireless bands that are being ignored (which the FCC shot down as to the request for additional 220 spectrum), as well as their pursuit of a Positive Train Location (PTL) component that is far beyond that which is really required. What I purposely left out of the article was the railroads’ pursuit of incorporating Intermediary Signals (ISs) into the functionality of PTC. I did so because I thought this was a bridge too far for even Railway Age (what I consider to be the most daring and honest of railroad periodicals) to take on this subject. But, the short is that the railroads’ technicians have once again ignored the actual requirements by developing solutions that are, again, totally unjustified as to both functional and technical perspectives. If you dig deeply enough into this blog you will find a posting YOY WIUs where I introduced my thoughts with an explanation meant for the non-technicians. What you read below, is a well-qualified operator’s perspective of this very point. The author is Dave Schanoes and his blog is www.ten90solutions.com.
PTC–Everybody, at least in the US, is talking about PTC. I’m no different. I talk about it. I think about it. I do some work on it. And let’s be clear– I welcomed the mandate for it… although let’s be completely clear: the Chatsworth collision that moved the US Congress to act could have been prevented by the decades old cab signal/ATC systems in use on many railroads.
So maybe PTC wasn’t needed there, but even with ATC something more is needed; actually a few something mores, given the mixture of signalled and non-signalled territory in the US.
I was talking to my friend, Ron Lindsey, of Communication Architecture about end of train, restricted speed, intermediate signals and his questions made me think, and my thoughts made him question me some more, and we agree on this:
Why This? And why not This?
March 26, 2012
236.1005 (a) (2) of the famous subpart I of the regulations governing train control reads:
“[Each PTC system required to be installed under this subpart shall] include safety-critical integration of all authorities and indications of a wayside or cab signal system, or other similar appliance, method, device, or system of equivalent safety, in a manner by which the PTC system shall provide associated warning and enforcement to the extent, and except as, described and justified in the FRA approved PTCDEP or PTCSP…”
which means, or has been interpreted to mean, intermediate block signal indications of a fixed block system, utilizing either wayside or cab signals or both, must be displayed [that’s the authority part, because in rule 251 or 261 territory, signal indications are the authority for movement] and enforced [that’s the indications part, as the fixed wayside, or cab displayed, block signals are speed indications].
There’s a “limited cab” in your system that means passenger trains must not exceed 45 mph? Guess what? PTC has to display and enforce that limited cab and speed.
So here’s my question…”why?” I’m serious, why? What is gained by PTC enforcing the intermediate signals rather than calculating the braking curve and enforcing the braking curve to the point of restriction?
Well, someone’s going to say, because the point of restriction is a train somewhere ahead of the train receiving the “limited” indication, and the point of restriction is the restriced speed indication protecting the block in which that train is, and any block signal can be a signal displaying restricted speed, and therefore, PTC must monitor the intermediate signal aspects and enforce the intermediate signal indications.
Before we go any further– no, I’m not going to advocate we do away with fixed blocks [although I heartily recommend doing away with wayside signals except at interlockings in favor of cab signal systems. And no, I’m not going to make an argument for CBTC or dynamic block or moving block, because I do not think CBTC or its variants are required for either passenger or freight movements in the US, given the density of the traffic. And, no I’m not going to advocate doing away with the “restricted speed” indication— I think the restricted speed indication has a very important role to play in terminals, yards, stations, and for broken rail protection.
I just don’t think “restricted speed” (1) can actually be enforced by PTC (2) is an effective and “positive” method of safe train separation.
Far be it from me to opportunistically cite the recent spate of restricted speed collisions as supporting evidence, but I refer to the recent spate of restricted speed collisions as establishing the point that we need to do just a bit better.
First, enforcing intermediate signal indications, even the restricted speed indication, is not necessary to PTC accomplishing its core functions: preventing train-to-train collision; derailment due to overspeed through permanent or temporary speed restriction; unauthorized incursion into a work zone; operation through a switch not properly lined for the train’s intended route.
Train-to-train collisions can still occur at restricted speed; overspeed derailment can, and is prevented without resorting to signal indication; unauthorized incursion into a work zone is eliminated through enforcement of a positive stop ; an improperly lined switch should also be protected through enforcement of a positive stop.
And… PTC is not enforcing restricted speed. It is only enforcing the numerical magnitude, the “not to exceed,” tacked on to the rear end of the definitiion. The meaning of restricted speed does not reside in the speed value. The authorization for continued movement upon receiving the restricted speed signal is not an authorization to proceed at a certain speed. The authority for movement is based on crew responsibility, upon the crew observing the rule. Of course, this simply reintroduces the possibility for human error, which PTC is supposed to prevent in the first place.
The “guts” of the restricted speed indication is that “movement must be made at a speed that allows stopping within half the range of vision short of….” ( you know the rest). PTC can’t enforce that.
Would you like to know something else about intermediate signals and the enforcement of their indications? Railroads don’t do it. Cab signal/automatic speed control systems do not do it… or aren’t required to do it.
You wanna bet? Yeah, I wanna bet.
Back in the day when I was person with a bit of authority on a major commuter railroad in a major metropolitan area, I took out my trusty pencil and paper and did some calculations.
We used a 4 aspect, fixed block, cab signal/speed control system. The aspects and associated indications were: “normal”= MAS; “limited”= for passenger trains, not to exceed 45 mph; “medium”=for passenger trains, not to exceed 30 mph; “restricted”– prepared to stop within half the range of vision etc. etc. not to exceed 15 mph.
On a rather busy portion of our railroad, the MAS was 80 mph. A train receiving a downgrade to “limited cab” was theoretically required to be at limited speed before entering the next block, particularly if the signal indication at that block was “medium cab.”
With our four aspect system, our signal design distance for deceleration from 80 mph to zero was approximately 9600 feet. Our required rate of deceleration was 1.28 ft/sec/sec or (-).84 g.
But because we do things evenly, each block was approximately 2400 feet long. Our signal design distance showed a required distance for decelerating from 80 mph to limited speed [45 mph] of 4611 feet, including the 8 second free-run time.
So what gives, here? What gives is that our on-board speed control systems did not monitor the target speed of the train in accordance with the speed transmitted by the signal protecting that block, but by the required braking rate to achieve zero velocity.
Certainly, if the engineer released the brakes before the target speed was achieved, a penalty brake application would ensue, but that again was based on not achieving a required rate of deceleration.
PTC does that. It enforces that. What it needs is not the signal data per se, but the location of the speed restriction, the target to which it calculates and enforces the required braking curve to comply with the limit to authority.
Cab signal/ATC systems convey authority to the following train enforcing the numerical magnitude of the speed, rather than enforcing the limitation to the authority. And that limitation is strictly a function of the technology the signal systems were built upon.
Why restricted speed? Why intermediate signals? Because we had NO WAY of determining, in the field, by the field apparatus, the location of the rear end of the leading train.
And today? Today, we definitely have that technology. We have GPS to locate the head end of the train. On passenger trains, we know how many cars are in the consist and the exact length of each car.
And for freight trains? Freight trains in the US operate with EOTs– end-of-train devices that utilize radio telemetry to convey the brake pipe pressure, airflow, etc. at the very rear of the train to the head end of the train. There is no reason that signal cannot be enhanced, and processed to confirm train integrity to the GPS system and to measure train length.
Conveying the train length to the Back Office System and using that length to enforce a positive stop, to withdraw a following train’s authority for movement at a point to the rear, then becomes part of our algorithm, adjusting for grade (slack on the lead train, braking on the following) for safe train separation. This is not “moving block”– but certainly could become so in existing dark territory– but rather limit to the authority for movement in a fixed block system.
And if you ask me, it would be a shame to let the limitations of an older technology hobble that of the new, forcing us to repeat the same old, same old, same old failures.
You did ask me, right?
Copyright 3/26/2012 by Dave Schanoes