Politicians rushing PTC

[zardoz]

Railway Man

We didn't have any difficulties with the braking algorithms.  It was really pretty straightforward.  Of course, we weren't trying to do anything fancy, either.

Part of me is sad that I am no longer railroading, because it might be interesting and/or amusing watching these new technologies go through their growing pains.  The entire operating department seems to have been "dumbed down" to the point where it won't be long until the human is replaced with a computer. 

Whether having machines doing all of our thinking for us will be good (safety, labor costs, etc.) or bad (computer doing stupid things causing derailments and/or drawbars and/or knuckle failures, etc.), we will have to wait and see.  

[Falcon48]

Paul_D_North_Jr

For the rest of us - and from the "public domain" - here are some excerpts from a BNSF "News Release" at:

http://www.bnsf.com/media/news/articles/2008/10/2008-10-08b.html

BNSF Ready to Implement Positive Train Control

FORT WORTH, Texas, October 8, 2008:

"BNSF Railway began development of its Electronic Train Management System (ETMS) in 2003 as a partnership with Wabtec Railway Electronics and has been testing ETMS in revenue service since 2006."

"ETMS is a PTC technology that has been proven to protect against the consequences of human error during extensive testing on BNSF. . . . "

"BNSF has successfully tested ETMS on a 135-mile stretch of track in Illinois and is continuing to test it between Fort Worth, Texas, and Oklahoma City. ETMS has passed every test during more than 1,600 train trips made so far. ETMS has stopped every train that it should have stopped, and has not stopped any train that it should not have stopped." [emphasis added - PDN]

There are a few more details in the News Release - refer to it if you want to know more.  See also another News Release with the following headline and dateline at: http://www.bnsf.com/media/news/articles/2008/10/2008-10-08a.html 

Railroad Industry Leaders Agree On Establishing Positive Train Control Interoperability Standards

OMAHA, Neb., FORT WORTH, Texas, and NORFOLK, Va., October 8, 2008:

Those cities ought to tell you that it was UP, BNSF, and NS that agreed on this - again, see the News Release itself if you want more details.

Notably, for this discussion the first News Release also says:

"BNSF Railway today announced that it is prepared to implement Positive Train Control (PTC) technology by Dec. 31, 2015, as mandated by the Rail Safety Improvement Act of 2008, and that it can have the wayside devices necessary to implement PTC in place in the Los Angeles Basin by the end of 2012." [emphasis added - PDN.]

A "class act" there - the "can-do" culture of many of the constituent roads is still alive, I see.  So it looks like the remaining challenges here were mainly financial and institutional, not technical.  Any other objections, or are we going to get on with it now ?

Edit: Here's the link to the Wabtec web page for ETMS (note that I have no known interest - financial or otherwise - in Wabtec or any of its affiliates):

http://www.wabtec.com/railroad/etms.asp 

- Paul North.

RWM - Thanks again for your extensive and insightful (perhaps "inciteful" in some instances ?) explanation and commentary on some of the nuances and implications of all this.

 

I'm aware of all of this stuff.  The point is that none of these systems have been widely implemented - they are essentially prototype systems that the designers expect to work, but haven't yet been proven in the field.  There is also a difference in design philosophy that hasn't been resolved.  The BNSF system is not a "vital" system while the UP system is.  The "bandwidth" problem has not been solved.  There's probably enough bandwidth for the freight railroads, but not for freight and passenger railroads in major metro areas.  Take a look at some of the testimony the railroads provided to Congress in connection with the recent rail safety bill for a more thorough discussion.  I think it's fair to say that the railroads are optimistic about solving these problems, but they haven't been solved as of now. 

[Railway Man]

Falcon48

I'm aware of all of this stuff.  The point is that none of these systems have been widely implemented - they are essentially prototype systems that the designers expect to work, but haven't yet been proven in the field.  There is also a difference in design philosophy that hasn't been resolved.  The BNSF system is not a "vital" system while the UP system is.  The "bandwidth" problem has not been solved.  There's probably enough bandwidth for the freight railroads, but not for freight and passenger railroads in major metro areas.  Take a look at some of the testimony the railroads provided to Congress in connection with the recent rail safety bill for a more thorough discussion.  I think it's fair to say that the railroads are optimistic about solving these problems, but they haven't been solved as of now. 

The difference between "vital" and "non-vital" (or "safety-critical", the term used in the CFRs) in the system in use by BNSF and being installed by UP and NS is in the permits filed with the FRA, along with a lot of extra redundancy in the hardware.  We installed the same system used by BNSF as an overlay but as a safety-critical system and it works just fine.  I was never particularly worried that it would not.

I think we differ in opinion whether the BNSF, UP, and NS system is field-proven or not.  I have my career sitting on top of my opinions on this, too. 

I'm comfortable that the BNSF-UP-NS system works, that BNSF's field tests proved the system's reliability beyond a shadow of a doubt, and that this system is implementable throughout the U.S. with no unusual or intractable problems beyond the normal problems in instituting new practices, procurement problems typical to all projects, construction permits, and finding the right people to train to pick up where we started and expand deployment on an aggressive timetable.  Given the FRA's extremely conservative and deliberative permitting process designed to eliminate 100.000000% of all risk something might someday go wrong that someone might blame on the FRA, which has been painful for all involved, I think the day the FRA signed off on BNSF's system that there should not have been any remaining doubt in anyone's mind.  But obviously not.

There are many in the railroad industry that agree with you.  I think my pay would be much less otherwise.

RWM

[Paul_D_North_Jr]

A little further on the above, from the January 2009 issue of Trains, "Railroads vow to make PTC work", on pg. 10:

"The four big Class Is have deployed variations of Wabtec systems, which makes the basic architecture of a nationwide standard that much easier." [cols. 2- 3, emphasis added]

" . . . the most significant [challenge] is acquiring the radio spectrum needed for the wireless link between locomotives and wayside interface units.  That will require help from Congress and federal regulators."  [col. 3, emphasis added]

A few posts earlier RWM mentioned a migration to the 200 MHZ bandwidth.  Has that been completed yet, and will that solve this issue ?

- Paul North.

[Paul_D_North_Jr]

Next question:  One word I don't remember seeing in connection with this is "Internet" - will it be dependent on that in any critical way, or will PTC be essentially independent of it ? 

My concern is, of course, hackers and similar malicious types - you know, (gulp - don't want to sound like this bunch, but . . . ) the kind of thing that the mainstream media and sky-might-fall doomsayers like to worry about and raise as potential problems - that "someone might breach the system and bring it to a standstill, or worse, deliberately cause a wreck", etc., etc.

 One great virtue of most of the railroad "legacy" Communications & Signals ("C&S") systems is that they were "stand-alone".  While such systems were usually exposed to the risk of storm damage, they weren't easily vulnerable to undetected deliberate attacks or malfunctions introduced from the outside world.  It's pretty tough - well nigh impossible - to "hack" into either the pole lines or the codes in the rails without a physical connection, and fiber-optics are essentially immune to that as well (except for maybe the NSA's monitoring taps of the Russian undersea lines ?).  This is of course aside from the very rare - and essentially unpreventable - case of intentional tampering such as by "jumping" around a removed rail joint, etc.  An SP passenger train wreck in the mid-1960's and a similar Amtrak wreck on the ATSF in the early 1990's come to mind as examples of that.

Anyway, anyone care to respond or address this, without disclosing too much to compromise the underlying security ?

- Paul North.

[Paul_D_North_Jr]

zardoz

Part of me is sad that I am no longer railroading, because it might be interesting and/or amusing watching these new technologies go through their growing pains.  The entire operating department seems to have been "dumbed down" to the point where it won't be long until the human is replaced with a computer. 

Whether having machines doing all of our thinking for us will be good (safety, labor costs, etc.) or bad (computer doing stupid things causing derailments and/or drawbars and/or knuckle failures, etc.), we will have to wait and see.  

Tom Clancy - in The Hunt for Red October, I think it was - had a line about how it was getting so that you couldn't flush the head without a computer . . .

But seriously, where could or will this lead and leave us ?  Like "cruise control" on your car ?  Like the auto-pilot on airplanes, where the pilots do the take-offs and landings, and anything exceptional, but leave it to the machine the rest of the flight ?  Will the locomotive engineers be reduced to just monitoring it, and maybe taking over only if something really goes wrong - goes wrong - goes wrong ?  Or not, if we really need to depend on the machine's predictable and quicker reactions instead ? (John Kneiling again)  How will loco engineers obtain the training and maintain their competence in train handling if the machine is doing it all - from simulators only ?  Or, will that skill set too soon pass from the scene ?  (How many of us could make a fire from flints and tinder - right now ?)

What's next ?  This could get quickly get like the new cell phones - a whole bunch of "apps" (applications) built into or added onto it.  Here's an easy one - automated grade crossing signals - the whistle-blowing.  The computer knows the line's configuration and crossing locations, the train's speed, and the required timing and pattern.  Set it up to do that unless overridden by the engineer.

Next, maybe speed management for fuel economy and scheduling - suggest (and/or enforce) maximum and minimum speeds to fit the line's operating characteristics, the operating plan, and the dispatcher's line-up for a particular day - no sense running at 50 MPH to the next CP when you're only going to have to wait there 20 minutes for the opposing move to clear.  Conversely, if the system predicts you're going to hold up a hot train if you keep moving at your present slow pace - what then ?  Obviously, we don't want it to speed the train up, but maybe expect it to inform on you and then a radio message from the DS or Supt. to explain why you're not going faster ?

And grade crossings !  I could see this being the next big step in safety upgrades, perhaps something like this:  Install sensors/ scanners at the important ones - the ones that warrant gates, and maybe those with just flashers, too.  If something "big" - truck for sure, not sure about a car - is still on the tracks when the train "hits the circuit" / the flashers activate, then the train starts to brake.  But per Zardoz above, that function will wear out its welcome real quick. [sarcasm] 

So then what ?  Maybe cameras should also be installed, and all violators ticketed/ mailed a summons, just like with the "red-light cameras" in a lot of the big cities.  Keep in mind, the railroads have their own police forces, so enforcement wouldn't be dependent so much on the "discretion" or motivation of the local cops.  I'm not sure if the RR police now generally have the inherent power to issue such traffic tickets, but if not then that could easily be taken care of by the appropriate remedial legislation - all in the name of safety, of course, esp. since the ticket revenue would most likely go to the government, not the railroad.  Still, the word would get out, and so this might be well worthwhile for the railroads to substantially reduce that hazard.  Of course, this will likely work only at the "low-hanging fruit" of the busy signalled crossings - the country crossings with only cross-bucks will probably remain devoid of such protection for a long time to come - but we do what we can, when we can.

Automated switching ?  I can see the loco knowing where it's at, but I don't see how PTC will reliably know where the last car in a string is, as they are added and dropped during the process.  There's no sensor on the end of each car (yet) to observe or transmit that info, so it wouldn't know how many cars are actually coupled or not.

Any other thoughts - suggestions - concerns ?

- Paul North.

[carnej1]

Paul_D_North_Jr

zardoz

Part of me is sad that I am no longer railroading, because it might be interesting and/or amusing watching these new technologies go through their growing pains.  The entire operating department seems to have been "dumbed down" to the point where it won't be long until the human is replaced with a computer. 

Whether having machines doing all of our thinking for us will be good (safety, labor costs, etc.) or bad (computer doing stupid things causing derailments and/or drawbars and/or knuckle failures, etc.), we will have to wait and see.  

Tom Clancy - in The Hunt for Red October, I think it was - had a line about how it was getting so that you couldn't flush the head without a computer . . .

But seriously, where could or will this lead and leave us ?  Like "cruise control" on your car ?  Like the auto-pilot on airplanes, where the pilots do the take-offs and landings, and anything exceptional, but leave it to the machine the rest of the flight ?  Will the locomotive engineers be reduced to just monitoring it, and maybe taking over only if something really goes wrong - goes wrong - goes wrong ?  Or not, if we really need to depend on the machine's predictable and quicker reactions instead ? (John Kneiling again)  How will loco engineers obtain the training and maintain their competence in train handling if the machine is doing it all - from simulators only ?  Or, will that skill set too soon pass from the scene ?  (How many of us could make a fire from flints and tinder - right now ?)

What's next ?  This could get quickly get like the new cell phones - a whole bunch of "apps" (applications) built into or added onto it.  Here's an easy one - automated grade crossing signals - the whistle-blowing.  The computer knows the line's configuration and crossing locations, the train's speed, and the required timing and pattern.  Set it up to do that unless overridden by the engineer.

Next, maybe speed management for fuel economy and scheduling - suggest (and/or enforce) maximum and minimum speeds to fit the line's operating characteristics, the operating plan, and the dispatcher's line-up for a particular day - no sense running at 50 MPH to the next CP when you're only going to have to wait there 20 minutes for the opposing move to clear.  Conversely, if the system predicts you're going to hold up a hot train if you keep moving at your present slow pace - what then ?  Obviously, we don't want it to speed the train up, but maybe expect it to inform on you and then a radio message from the DS or Supt. to explain why you're not going faster ?

And grade crossings !  I could see this being the next big step in safety upgrades, perhaps something like this:  Install sensors/ scanners at the important ones - the ones that warrant gates, and maybe those with just flashers, too.  If something "big" - truck for sure, not sure about a car - is still on the tracks when the train "hits the circuit" / the flashers activate, then the train starts to brake.  But per Zardoz above, that function will wear out its welcome real quick. [sarcasm] 

So then what ?  Maybe cameras should also be installed, and all violators ticketed/ mailed a summons, just like with the "red-light cameras" in a lot of the big cities.  Keep in mind, the railroads have their own police forces, so enforcement wouldn't be dependent so much on the "discretion" or motivation of the local cops.  I'm not sure if the RR police now generally have the inherent power to issue such traffic tickets, but if not then that could easily be taken care of by the appropriate remedial legislation - all in the name of safety, of course, esp. since the ticket revenue would most likely go to the government, not the railroad.  Still, the word would get out, and so this might be well worthwhile for the railroads to substantially reduce that hazard.  Of course, this will likely work only at the "low-hanging fruit" of the busy signalled crossings - the country crossings with only cross-bucks will probably remain devoid of such protection for a long time to come - but we do what we can, when we can.

Automated switching ?  I can see the loco knowing where it's at, but I don't see how PTC will reliably know where the last car in a string is, as they are added and dropped during the process.  There's no sensor on the end of each car (yet) to observe or transmit that info, so it wouldn't know how many cars are actually coupled or not.

Any other thoughts - suggestions - concerns ?

- Paul North.

Interestingly the recent TRAINS magazine article (I believe it was the November issue?) "10 technologies that will change railroading" laid out the same scenario in discussing the use of RC and PTC systems for mainline freight. Althought the point was made that completely unmanned trains were not a realistic possibility, at least for the forseeable future, one man crews could be...

[erikem]

Railway Man

The communication bandwidth issue was resolved with the migration to the 220 MHz standard.

 

Is this the same part of the 220MHz that UPS was using? I.E. 220-222MHz.

The 220-225 MHz band was allocated to the Amateur Radio Service up until the early 1980's when UPS grabbed the bottom 2 MHz (boo - hiss). Last time I was on 220 was about that time - most memorable QSO was on 223.5 talking to a fellow at UCSB while I was in San Diego running 1 watt into a 5/8 mag-mount on a suitcase.

[daveklepper]

The SEPTA Center-City Streetcar Subway does not handle trains, only single cars.  There is not now and never has been multiple unit operation in this particular subway on the light rail tracks.  (The two center tracks of the 4-track portion are used by the Market-Framkfort Rapid Transit Line.)  I believe this is also true of the Newark subway, but I believe provision there has been made for two-car operation.  Boston of course and Pacific Electric and Illinois Terminal and the Red Arrow Division of SEPTA all do or did at one time run mutliple unit trains of essentially multiple unit streetcars.  Bombardier's task in the SEPTA Center Subway situation was in some senses much easier than that required by the frieght railroads, but also more difficult because of the much much shorter headways, time between cars/trains.

Regarding bandwidth and use by both freight and passenger railroads in metropolitan areas:  Where multiple track operation exists and especially third rail or overhead wire electric operation, continuous antennas make for practicly a fail-safe non-inteference short-distance radio link to the moving train.  Remember that parts of the Northeast Corridor have effectively had such systems in successful operation for over 70 years, along with the Long Island Railroad.   Metro North for over 14 years.  On Metro North, continiuous antenna, the Corridor had inductive pickup on a block system (PRR pracitce) but this may have been replaced by continuous antenna.

[Bagehot]

Well, this stuff always works perfectly until it doesn't.

This is a controversial item in the rail industry, make no mistake about it. The idea is over 20 years old. However, during that time Railroads saw other investments as offering a better rate of return. They didn't achieve those rates of return -- a story in itself -- so now RRs are looking back at PTC. It requires a huge capital investment. Nobody was really willing to commit unless everyone was on board -- this has always been an industry that insists that success and failure must be lockstop. The safety angle simply ensures that the regulatory system imposes it on everyone whether they can afford it or not. And make no mistake: one key cost savings will be in train crews and further reductions in employment. For train crews, it doesn't matter where you work -- road or yard -- unless you actually sit in the engineer's seat, you will not be working in this industry in ten years.

BNSF's Steve Ditmeyer was (and is) an avid proponent of PTS, and his enthusiasm has continued on in his various careers since leaving the company. He was involved with most of BNSF's experimentation with the system. I had a chance to review his Paper presented at an AREMA conference in May, 2006 and discuss it with him. I think he's probably among the brightest guys involved in the program.

Most of my career, on the other hand, has been involved in examining various face-plants by management in the rail industry, and frankly, I get nervous with each new 'bright" idea that comes along, especially when pushed by self-interested parties. The success rate of "new ideas" is astonishingly low. "Network-Centric Railroading Utilizing Intelligent Railroad Systems" (2006) is the essence of where PTC is headed. The paper is available from AREMA and it is well worth the reading.

It may well be a revolutionary step forward. I like most of the ideas and what they intend to achieve. However, when you get all inspired about the concept, then read "The Black Swan" by  Nassim Nicholas Tale. Statistically, this concept builds in a dynamic tension in critical need of a functional backup.

It doesn't have one. The economic success of PTC is conditioned upon elimination of the backup.

-- Bagehot