Provocative PTC Article in Popular Science Magazine

[Anonymous]

Regarding this FRA report:

http://www.fra.dot.gov/eLib/Details/L03718

 

The main thrust of the report seems to be that the railroads cannot meet the mandate deadline. 

However, after learning about the incredible volume and complexity of unresolved technical issues in the present PTC art, I doubt that the development can keep up with the speed of the advancing science, let alone meet the implementation deadline.  This government mandate seems like a staggering overreach being foisted upon the railroad industry.

It also raises this prickly question:  How many additional deaths will occur that would not have occurred had this PTC mandate not displaced and suspended the normal course of advance train safety development that the railroads have been pursuing on their own volition?

[Murphy Siding]

zugmann

edblysard

OMG, not a committee….

That means it will be 10 years or so before anything gets done, and it still won’t work ….

Hey, wait a minute, a committee and bureau would be an excellent idea!

Where can I send my resume?

     You're probably overqualified.  I'm sure they'd be looking for someonw with experience in bureaus and committes, not in railroading.

[jeffhergert]

Murphy Siding

zugmann

edblysard

OMG, not a committee….

That means it will be 10 years or so before anything gets done, and it still won’t work ….

Hey, wait a minute, a committee and bureau would be an excellent idea!

Where can I send my resume?

     You're probably overqualified.  I'm sure they'd be looking for someonw with experience in bureaus and committes, not in railroading.

Or those who have experience on donating large sums of money to political campaigns.

I wouldn't be surprised if some would rather have people who don't know how things work on such a committee.  In the words used by businesses who bring in new senior management from outside their respective industry, "they don't know what can't be done."  The flip side of that is that they have to learn the hard way what can't be done.  Making the same mistakes the previous people did. 

Jeff 

[tree68]

The primary purpose of a committee (or bureau) oftimes seems to be ensuring its continued existance...

[Anonymous]

Even without the new research and development government bureaucracy that I proposed, the mandate, as it stands, will undoubtedly contain a large measure of government bureaucracy.  After all, that is the point of these kinds of things.  The beauty is the gigantic pool of funding available in the prosperity that railroads’ currently enjoy.  After all, that prosperity was a gift from Congress, so all is fair.  We were recently talking about the railroads’ cash cows.  In the case of PTC, the railroads become the cash cow.   

Obviously the mandate deadline will have to shift, but that is not a problem.  It will just give more time to milk the cow.  We will be able to watch the price meter on PTC spin as the approaching deadline is repeatedly advanced.  The motivation to never get the job done because of a desire to keep milking the cow will never end.  I don’t expect the endless development and implementation of PTC to ever catch up with the ever rising price tag. 

[oltmannd]

BaltACD

The technical obstacles that have been identified to date fall into seven different categories:

Communications Spectrum Availability

Radio Availability

Design Specification Availability

Back Office Server and Dispatch System Availability

Track Database Verification

Installation Engineering

Reliability and Availability

So, basically, all that's really set in concrete is the name...

Phased implementation would pretty much solve all the problems.  Something like 5% of the covered miles in year one, another 5% in year two. 10% in year three and year four, 20% in year 5 and the remainder in year 6.  It would allow "stand alone" route  implementation in the first couple of years, then some targeted interline interoperability, then the whole enchillada when the technology and software are somewhat stable and mature.

It would also give the RR's a chance to think about and work on some of the secondary benefits that may be available through having the hardware in place.  Right now, they don't have the time and resources to give it a second thought.

[466lex]

"Phased implementation would pretty much solve all the problems."

"Phased implementation" of PTC would be like being half-pregnant.  All of these complex systems must be "go" from day one.  They are "vital" in the sense that failure is not an option or all benefits are lost, and, indeed, new risks are created by system failure.  It would simply be unacceptable to conduct any routine commercial operations if "the technolgy and software are [only] somewhat mature." 

(Isolated "R&D" test operations under exceedingly close mamagement and control will certainly be required to prove out the software and technolgy.  BN got that far with its ARES initiative, using a Minnesota iron ore line to prove out some of the fundamental concepts (GPS, etc).)

 

[oltmannd]

466lex

Phased implementation" of PTC would be like being half-pregnant.  All of these complex systems must be "go" from day one.  They are "vital" in the sense that failure is not an option or all benefits are lost, and, indeed, new risks are created by system failure.  It would simply be unacceptable to conduct any routine commercial operations if "the technolgy and software are [only] somewhat mature.

Nonsense.  I know all about ARES and the AAR's mostly stillborn ATCS project.  

You phase PTC in by territory.  A "dark" branch, first.  Yes, you need most of the hardware and software required for full implementation, but the whole network won't go belly up if one part breaks.   In fact, you can run PTC in the background while controlling operation the "regular" way with track warrants, then turn off the manual portion of the track warrant system - it just becomes data.  

That way you can see what the data traffic/coverage looks like, if the messaging schemes are solid, if the wayside devices are reliable, etc. etc.  You don't  have to worry about interoperability between the stand-alone and overlay variants that will exist when RRs start run thru PTC trains.  You can work through "fall back" procedures for handling PTC disabled trains.  You can work through hardware reliability issues.  You can work through clunky software code issues.

[466lex]

"Nonsense"

LOL!  "Yes, you need most of the hardware and software"?  How do you phase it in if you don't have all of the software and hardware operational? 

And, of course, the whole network won't go "belly up if one part breaks" ... but what happens to the two trains being "protected" by PTC when the early, not-fully-perfected system fails?

You are simply describing the tightly controlled environment that must prevail as an R&D start-up.  I don't consider that a "phased implementation", but perhaps it is simply a matter of semantics.

[Overmod]

466lex

"Phased implementation" of PTC would be like being half-pregnant.  All of these complex systems must be "go" from day one

You are presuming these are being used as critical, automatic systems from day one.  Evidently you are unaware of things that are common in computer or other complex systems, such as migration or cutover.  Only idiots assume complex new systems will work perfectly when instantiated, with all the bits and pieces completely integrated and trustworthy.

The 1920 Esch Act provisions for ATC were intended to be made systemwide standards ASAP, just as PTC is now (I don't have the time to pull up the exact language of both old and new for comparison -- someone please do that).  Because the technology was new and essentially untried at the time, the 'idea' was to phase in coverage, a division at a time, with the presumption that private companies would pile on the ATC-equipment bandwagon and perhaps more than one 'effective' solution would emerge.  The principal difference is that in 1920 it was the functionality that was specified; now, the idea (perhaps taking a leaf from Hamilton and Dilworth's Electro-Motive philosophy, and part of the idea behind the Internet) is to provide all the complex components as common standards so that the system works 'any load - any road' without tinkering or interworkability issues. 

I do not know if you mean the comment in the sense that all the devices and sensors, server networks and services, and communications technology (including what needs to be done to SDR) need to be present before PTC will provide 'what is promised'.  That is technically true.  One problem with the system model that was specified is that it is 'brittle'; another is that it presumes that all the different components are mandated, and therefore will be present or large fines and other enforcement will ensue.  As I have noted before, the system ought to have transparent redundancy and effective failover; it should feature graceful degrade (for example, when communications integrity on one or more frequencies is lost or corrupted); and should, like the Arpanet, feature inherent "healing" and methods of assuring the coherency and completeness of both the communicated intelligence and the actions the system takes.

They are "vital" in the sense that failure is not an option or all benefits are lost, and, indeed, new risks are created by system failure

The first part is not necessarily right, although the latter part CERTAINLY is -- and you don't have to like the novel Jurassic Park to understand why brittle complex systems have all kinds of unanticipatable failure modes... even before you get to intentional or malicious tampering or cracking.

As an interesting aside: in the history of technology there are a number of instances where less-capable systems were mandated as a result of avoiding reliance on technology.  Those of you who are apprentice or higher electricians may know the history of four-wire switches, and why they were made illegal in the late Thirties.  I well remember PAR as a solution to airport accidents -- and why it became deprecated in favor of... well, the tender mercies and all-knowing skills of ATCs.

The take-home is that even parts of PTC, when functioning even autonomously, enhance safety.  The gains in safety when more parts of the fabric interwork properly are usually synergistic, but that is not to take anything away from what the autonomous parts can do on their own.  I trust that the current instantiation of PTC doesn't have those stupid programmer errors from NAJPTC like an occasional train length of zero -- but even if not, a little 'artificial common sense' in the code or the interface design will signal safe running well in time for a HUMAN CREW to act safely in controlling the train.

It would simply be unacceptable to conduct any routine commercial operations if "the technolgy and software are [only] somewhat mature." 

"Unacceptable" to whom?

This is an idiom that has come into common English, and should be kicked back out as soon as possible.  Operations may be wise, may be unadvisable, may be downright criminally negligent -- but who are you to indicate whether a technopolitical system is 'unacceptable'?  Don't say it when you're in no position to accept or reject it!  I've had enough junior executives say this in 'negotiations' as if it were some universal rule rather than their personal assessment of the situation -- and use it for full rhetorical semantic effect, too.  

Believe me, there are a great many operations that run with 'immature' technology and software.  Or did you think that system upgrades and maintenance were always perfect ab initio, or that component or link failures never occur?  Did you think that testing, no matter how complete, substitutes for in-system field tests, which in the case of PTC in particular would require widespread (and expensive) capitalization to execute?

Contrariwise, although you might not think so, people in places like ITU R.10 actually do have some understanding of reusable software and patterns, and have designed effective hardware and software that will work in 'new' appications with reasonably high assurance.  I think this situation is remarkably true for most of the RTOS system designers, especially those involved with 'aerospace' standards of quality. 

The 'Job One' task of proper critical-systems design is (usually) to assure that the result will FAIL SAFE (remember that term?)  In the case of PTC, a bit more is required (as otherwise trains will be stopped dead and immovable on countless mains for what may be minor glitches or environmental surprises).  We come across this situation fairly often in software security -- brittle software security --, where there has to be some balance between 'stops where it should permit' and 'permits when it should stop.'  One solution was, and is, to make the system more robust, use multiple forms of information transfer, 'design out' chances for common-mode errors, etc.

I am of the personal opinion that PTC is not, and shouldn't be, a catch-all-errors 'nanny' to protect sleeping, texting, railfan-loving crewpeople from themselves.  Any subset of PTC, when considered in itself as a safety device, should work to enhance safety, even it it's as 'simple' as a radio proximity alert between locomotives (as on at least one mining railroad) or a remote crossing-intrusion system (with cameras and potentially-lucrative privatizable fines to catch the culprits' ID).  

I am of the opinion that restricting discussion on this thread to something like 'will full implementation be required by the deadline?'  Although the answer to that, given the numbers and the indeterminacies, will almost certainly be 'no', and I would hope that the prior examples of 'mandated improvements' -- usually rolling three-year extensions with certain 'benchmarks' to be met -- will be the model that the Government uses. 

[Anonymous]

Overmod,

I believe there might be a misunderstanding that has crept into this discussion.  In reading what 466lex has said and what you are saying, my interpretation is that the two of you are in agreement on this overall matter. 

[BaltACD]

When railroads signalled their properties, it was not installed 'whole cloth' on the entire property - it was done subdivision by subdivision as both the need and financing allowed. 

Likewise, when PTC is actively installed, it will also be done territory by territory.  The carriers and vendors only have so many people to train and deal with the localized issues that will crop up as each new territory gets PTC activated.  Remember, in most, if no all territories, PTC is being installed as a 'overlay' system upon the systems that already exists.

[466lex]

Forgive me if I am a bit bemused by the vehemence sometimes instantiated by informal forum postings.  First it’s “nonsense” that I’m guilty of perpetuating, and now I am “presuming”, “assuming”, “unaware” and am apparently one among “idiots”.  But, no problem ….  LOL!

PTC, as mandated, either positively controls trains or it does not.  Until it does so successfully in a totally isolated “test-bed” environment, normal railroad operations as we know them today will, seems to me, continue. 

Once “fully proven”, a “phased” installation would, again seems to me, present almost insurmountable problems of integrating operations on a network governed by multiple systems (PTC and legacy).  (Only slightly less mind-boggling is the idea that PTC will “go live” at 12:01 AM, Jan. 1, 2016, nation-wide.)

There is dramatic railroad industry precedence for the chaos which ensues from a “phased” installation:  The Penn Central elected to utilize the PRR legacy operating information system on the southern side of the merged system, and to use the NYC legacy system on the northern side.  As a direct result, the railroad ground to a disastrous halt, ultimately resulting in bankruptcy.  (Bear in mind, these relatively simple information systems had nothing to do with directly controlling trains, in that they had no link with signaling and dispatching functions.)

The reports that I see (all in the public domain) indicate that the railroads are investing heavily in an “all or nothing” strategy to meet the mandated deadline.  Signal systems are being converted system-wide, entire locomotive fleets are being equipped, etc.  Looks to me like they feel under the gun to cut-over en mass.  “Who, me nervous?” are muttering CEO’s.

The above is offered as simply one (perhaps, simplistic) perspective.  Dump on me as you will.  LOL!

[Anonymous]

466lex

Once “fully proven”, a “phased” installation would, again seems to me, present almost insurmountable problems of integrating operations on a network governed by multiple systems (PTC and legacy).  (Only slightly less mind-boggling is the idea that PTC will “go live” at 12:01 AM, Jan. 1, 2016, nation-wide.)

That seems to be the exact characterization of the quite comprehensive FRA report to Congress.  For instance, look at page 32-33 where it details the task of equipping 18,000 locomotives with PTC technology. 

http://www.fra.dot.gov/eLib/Details/L03718

Not only does this mandate need to be executed, but it also has to be managed at every step of the way to verify the progress with the mandate and confirm it to the government.  I doubt the estimated cost will even pay for the paperwork.

[edblysard]

Still no word on the badges and flip wallets?

[Anonymous]

edblysard

Still no word on the badges and flip wallets?

While there might be a good career in my new bureaucracy (USBPTCD), the big bucks are going to be waiting for the new signal workers.

 

Quote from the report: [Formatting nightmare]

 

“The PTC system signal projects require a substantial amount of work in a limited period of

time by the railroads. Historically, railroads are staffed for a fairly stable amount of signal

work from year to year. The PTC system signal work has increased the workload for railroad

signal staff, resulting in a significant increase in the number of locations where signal work is

required. The limited number of qualified signal technicians available to the railroad

industry constrains the railroad’s ability to complete the design, installation, and testing work

required for PTC system signal projects. It has also adversely affected projects to increase

railroad capacity because the same employees are needed to perform both functions. The

increase in demand for signal technicians combined with the limited number available has

resulted in a tremendous increase in signal engineering and installation costs.

 

Railroad signalmen, the craft most responsible for PTC system installation, have fewer than

9,500 members nationwide.32 In addition to implementing PTC systems, these persons are

also working full time to keep currently installed signal and train control systems operational.

The work is also arduous. PTC system installers are often required to travel 100 percent of

the time away from home—sometimes, in excess of 300 miles—working either 4 days on

and 3 days off, or 8 days on and 6 days off. They work outdoors in all types of weather, over

uneven terrain, and are required to do heavy lifting, climb ladders and poles at heights that

can exceed 40 feet. All this while working under live rail traffic conditions where both the

reliability of the existing systems must be maintained at all times, as well as the personal

safety of all persons involved.

 

The industry has already hired more than 2,000 additional signal technicians specifically for

PTC and is planning to hire hundreds more. It typically takes 18–24 months for an individual to receive the training and gain the experience necessary to handle the complexities of a PTC system. On the Class I railroads alone, approximately 60,000 engineers and conductors, 6,500 signal employees, and 2,400 dispatchers will have to be trained on PTC systems. This number does not include the mechanics, electricians, and supervisors who will also require training.”

[Overmod]

466lex

Once “fully proven”, a “phased” installation would, again seems to me, present almost insurmountable problems of integrating operations on a network governed by multiple systems (PTC and legacy).  (Only slightly less mind-boggling is the idea that PTC will “go live” at 12:01 AM, Jan. 1, 2016, nation-wide.)

There are no 'insurmountable' problems involved in switching from PTC sections to conventionally-dispatched, any more than there was historically in, say, extending CTC, or before that, implementing ABS with lighted signals.  I wish Mark were still posting on here, as he could succinctly cover exactly how the procedures would be done.  There is some choice, for example, of whether train-order control is continued over a mixed PTC-nonPTC route segment, or different train orders would be issued for the sections between operating PTC.  You'd have signs -- very much, I suspect, like the ones on the LGV in France -- noting when you're entering automatic control territory, or leaving it.

As noted, I'd also expect much of the conventional system of dispatching to continue 'in parallel' with the PTC operations, and with the paper orders having precedence over the in-cab displays and 'permissive' aspects of the PTC system at least for a while.  (Note that 'permissive' -- more restrictive actuation of PTC, for example in response to a perceived blocked crossing or impending slide (microquakes, etc. or machine-vision detection, to quote two sample technologies to do that), is no different from what happens today when a broken rail or activated slide fence puts the block or cab signals to red.

Likewise, 'instrumenting' a minimum number of switches out of the 'total' number given will allow at least some, possibly a significant degree of the 'safety' that can be provided by an operative PTC system, before there is complete -- I might use the word 'pervasive' in the MIT lab sense -- autonomic safety regardless of operating strategy.

The idea that PTC will be rolled out and operating by 2016, even with Manhattan-Project-like levels of funding and motivation, doesn't seem likely to me, either.  Part of the problem, I think, is that the Government actually believes spending more money (or bullying railroads into spending more money) will get the job done right in a shorter period of time.  It would be nice to re-create the moon shots... but there was a great deal more money, and actual competent systems engineering, built into that program.  

One thing that concerns me, that I haven't seen brought up here, is what happens when the 'whiz kids' modernizing old paradigms of dispatching no longer think they need to worry about conflicts, breakdowns, etc.  Will there come a time when dispatchers are looking at an illuminated display that gets them into much the same trouble as 'too much software representation' did on the Vincennes?  

There is dramatic railroad industry precedence for the chaos which ensues from a “phased” installation:  The Penn Central elected to utilize the PRR legacy operating information system on the southern side of the merged system, and to use the NYC legacy system on the northern side.

Pardon me for saying this, but that's an incredibly poor example, and does not even describe a phased implementation at all -- rather, just the opposite.

The 'example' in the Penn Central context would be phase-in of data harmonization (look it up) between the two systems... I tremble to think how this would have had to be done between the NYC and PRR "computer" systems as they were.  The logical thing to 'phase in' would have been a system designed for Penn Central operations, either replacing both systems or rolling out one standard (probably PRR's wretched one, under the political circumstances) across an increasing number of the 'other railroad's' operations.  [And yes, I do understand how impossible that would have been in practice at the time, in that context...]  Slowly but surely, the 'phasing in' of either a harmonized or common-system computer operation would reduce the amount of disaster that actually occurred when the green team and the red team just tried to interwork incompatible systems, without either spending the money to upgrade or acquiring the people to process the transition. (And yes, there was in my opinion a situation where Perlman's computer operations were considerably more advanced than PRR's, and therefore 'hard to throw away' -- I'm sure the supposition was to merge the 'work product' where necessary, but you don't need 20/20 hindsight looking at the systems to understand why even with a very large DP budget (which of course PC didn't have) that wasn't going to work.

 

As a direct result, the railroad ground to a disastrous halt, ultimately resulting in bankruptcy.

There was a WHOLE lot more than computer confusion -- most of which concerned paperwork associated with car movements, not the actual making up of trains -- in the 'grinding to a halt' and the bankruptcy.  In my opinion at least.  (Or perhaps, to put it a different way, I don't think the computer problems alone were the major fatal factor, and I don't think even a proper and 'perfect' harmonization of the computer facilities and systems available at that time would have staved off the bankruptcy much, if any, longer than it took historically.

(Bear in mind, these relatively simple information systems had nothing to do with directly controlling trains, in that they had no link with signaling and dispatching functions.)

Well, if you have to spend extra time figuring out how to hump cars to make trains, and then you're not sure what's in those cars when they get to the next yard, it has a link with the dispatching function...  Much more to trains than running them from point A to point B without hitting something.

[BaltACD]

PTC as it is currently being designed is as a 'OVERLAY' on top of already existant means of traffic control.  CTC areas with wayside signals will remain CTC areas with wayside signals - the PTC overlay will 'read the signals' and any other relevant directives in 'monitoring' the operation of the train.  If the train operates outside of the parameters of the data that PTC has, PTC will undertake control of the train and bring it to a stop.  All the utility of the preexisting control systems reamain in effect.

In the intial years of the implementation - PTC will not be 'running the train'.  It will be monitoring the trains operation and braking the train when it is operating outside of the data parameters that PTC has been fed for the instant location.

Train passes an 'Approach' Signal indication - If the train does not start slowing within the parameters that PTC has been programmed - PTC will slow the train (most likely to a STOP).  If the Engineer operates the train in conformity with the Signal Indication and any permanent and/or temporary speed restrictions as well as MofW Work Authorities - the engineer won't necessarily be aware that PTC is in operation.

[jeffhergert]

On the subject of operating with a PTC failure, I imagine it will be treated along the lines of how a cab signal failure is currently handled.  You get an absolute block in advance of your movement and/or run on wayside signal indications (if any) or run at restricted speed until reaching wayside signal territory and/or receiving an absolute block.

I read somewhere (I think in a Railway Age article a few years ago) that it will be permissible to allow non PTC equipped trains to operate in PTC territory for short (20 or 25 mile zones, IIRC) stretches.  The example given was for a short line that didn't need PTC on it's own lines but needed to use a section of trackage rights over what would be PTC territory on another railroad.  We have some cab signal areas like that now.  I understand they don't want to burden a small operation, but that kind of negates the whole idea behind PTC.  Let's mandate a collision avoidance system and then allow loopholes large enough to run a train through.  Or maybe short line railroaders are thought to be more reliable than class one railroaders.

Jeff 

[466lex]

Spend $15 billion, but “You'd have signs -- very much, I suspect, like the ones on the LGV in France -- noting when you're entering automatic control territory, or leaving it.”

This statement encapsulates, for me, the folly of a phased implementation.

The Chatsworth Metrolink operator missed the “sign”, aka, “signal”, “red board”, whatever.  That’s why the PTC mandate exists. 

My posing the Penn Central systems “phase in”/”data harmonization” disaster as an analogy is described as “an incredibly poor example”.  Chastised again, but I’ll stick to my point:  Attempting to manage a complex network with multiple information/control systems (in the instant discussion, PTC and legacy control systems) is, in my opinion, more than daunting.  It is folly.

And opening myself to further chastisement, I will cite the UP-SP merger melt-down as an example of the hubris so often involved in underestimating the risks inherent in network integration.  Thinking of PTC as a “mere” (implicitly meaning, in my simplistic interpretation, “simple”) “overlay” is to gloss over the reality.

The PTC mandate was established by a technologically illiterate body (aka, Congress). The FRA, charged by Congress to oversee the implementation of PTC, recognizes, much to FRA’s credit, the stupendous complexity of the undertaking and the dubious likelihood of meeting the mandate, and has so advised Congress.  (See, again, http://www.fra.dot.gov/eLib/Details/L03718)

Again, I suggest, read it and weep.

[Anonymous]

466lex

The PTC mandate was established by a technologically illiterate body (aka, Congress). The FRA, charged by Congress to oversee the implementation of PTC, recognizes, much to FRA’s credit, the stupendous complexity of the undertaking and the dubious likelihood of meeting the mandate, and has so advised Congress.  (See, again, http://www.fra.dot.gov/eLib/Details/L03718)

Again, I suggest, read it and weep.

I think you sum it up very well.  Likewise, in reading the FRA report, it strikes me that they have succeeded in adding up trees to depict the forest.  No detail is insurmountable, but it is just that there are so many of them.  Of course, the deadline will not be meant, but that is probably the least of the problems.