The probe by the Federal Railroad Administration and CSX includes an examination of the proper activation, operation, and functioning of PTC on the territory as well as any human factors that may have contributed to the Aug. 12 wreck.
PTC was active on the line at the time of the predawn collision near Carey, Ohio, on CSX’s former Chesapeake & Ohio route between Columbus and Toledo, according to people familiar with the matter.
But the safety system had been disengaged on the northbound train, Columbus-Willard local H702, that slammed into the side of southbound unit frac sand train W314 at the end of a passing siding, sources tell Trains.
PTC “is on that line and active. The rub being the crew that blew the signal had the PTC disengaged for switching purposes,” a person familiar with the matter says.
The local’s locomotive derailed, along with a total of 25 cars. The engineer was taken to the hospital as a precautionary measure.
Just prior to the 5:21 a.m. wreck, the crew of the southbound train tried to alert the northbound train by flashing the headlight, blowing the horn, and calling on the radio, The Toledo Blade reported, citing a report by the Wyandot County Sheriff’s office.
Railroads are required to have PTC fully operational by a Dec. 31, 2020, deadline. Until then, under the deadline extension granted beyond Dec. 31, 2018, trains operating over a route with PTC are not required to have the system activated, federal officials say.
Even after the 2020 deadline, operating without PTC engaged would be permissible under certain limited circumstances, including switching, yard-to-yard moves, and when a train’s locomotive fails to connect with the PTC system while already en route, federal officials say.
CSX declined to comment, saying the incident remains under active investigation.
See? I told you there would be “errors” in PTC. Maybe we should have waited for flexible blocks, etc. The lawyers and politicians had their field day against “evil corporations”–yet it’s the government’s MBTA that’s spending over $100 mill on yet another signal system, the third here on the RR since I moved here 12 years ago. Just wait for errors in GPS to show up; I live next to one on the highway GPS..
Well, this puts to rest the silly notion that one man in the cab is all the Robber Rail Barons need as far as crew…someone definitely HAS TO watch the satchel-ass Engineman !
When making switching moves, PTC has to be disabled. It’s required and allowed by rule, you don’t need a dispatcher’s authorization for that. The changing of direction “confuses” the PTC. It wasn’t designed to make reverse movements. The screen may try to reorient the screen because it “thinks” it’s going forward when it’s going backward. It might make a penalty brake application or disengage itself.
There are two ways to temporarily disable protection. One is doing a “soft” cut-out. The other, and being a newer upgrade, may not be available on all PTC equipped engines is a Restricted Speed option. Both remove protection and remove the display screen map. The difference is that the restricted speed option will enforce restricted speed during the time full protection has been disabled.
Once the switching moves are finished, the PTC must be restored before proceeding.
It’s also true that PTC isn’t the panacea it’s made out to be. Currently, being an overlay upon existing signal systems, once you’re past a block signal any changes within that block (switch being opened, broken rail, etc.) will not be known to the PTC system. It can “see” the next block signal ahead of it, but not what’s happening within that block. It allows trains and engines to pass non-absolute red signals (what are commonly called “intermediate signals”) at restricted speed. Fatalities have happened in restricted speed collisions.
My software engineer cousin would compare these first users/customers as the beta testers (of the not totally bug free software, which management forced to market before its time).
Expect more finger pointing grandstanding from the same politicians who grandstanded and stomped their feet about the railroads supposed “foot dragging” on implementing this devilishly complex system—which is still not perfected and trouble free.
Ask any NS, UP, or CSX honest crewmember; PTC is disabled far more frequently than the public is led to believe, due to the many problems that have yet to be solved. Per the government, hurry, hurry, hurry and let’s hope it works.
Get down to brass tacks on this incident. The crew of the local “blew the signal” according to the article. PTC or no PTC, they should have stopped at the signal. Why did they ignore the lineside signal?
The crew of the southbound train “tried to alert the northbound train by flashing the headlight, blowing the horn, and calling on the radio.” Why didn’t the local crew react?
The local crew disabled the PTC system according to the article. So the real questions about PTC are:
Why did the local crew disable PTC?
Could the local crew have completed their work with PTC operational?
Was disabling PTC “legal” under the circumstances?
Did the crew have to ask for permission to disable PTC? If yes, did they receive permission?
Was the crew required to notify the dispatcher when the PTC was disabled? If yes, did this happen?
Did anyone other than the crew know the local’s PTC was disabled?
PTC was off for the local train so it could not operate the brakes to stop the train and prevent the collision. Does the PTC equipment on the locomotive have a physical or software ‘PTC off’ switch to disable PTC control of the locomotive while continuing to connect with the PTC infrastructure and provide local train status including GPS location, direction and speed information? If the onboard PTC is disabled using the ‘PTC off switch’ does the engineer’s PTC display continue to provide warnings? Did the crew disable PTC using the ‘PTC off switch’ or by turning an electrical circuit breaker off that completely disabled all PTC functions?
Lots of questions for the investigation to answer.
“Totally bug free software”? Good heavens. What planet are you reporting from. There is no such thing — at least for anything more complex than a routine which puts “Hello there” on the screen when a key is pressed. And when you couple the software with communication protocols, which can and frequently do fail, the very best any competent individual designing and implementing software can expect is that it fail operational — and even that s a very far stretch for anything complex. Otherwise, it has to be fail safe — or used as a guide, not a control.
In aircraft, this requirement is implemented by arranging things so that if the magic dies — which it often does — the pilot (who is hopefully well trained and paying attention) can disable the magic completely and fly the bird by hand (drones are set up so that most failures either result in a more or less controlled descent wherever they happen to be, or an in-air self destruct)
In railroading signaling, this used to be implemented (simplifying) by the rule that says if you miss a signal, or the signal is dark you treat it as a red. Stop, and find out what the problem is and ask the dispatcher if you may continue. Honestly the only way I can see to implement this with PTC — the software for which is very complex, and which is laden with all manner of communication protocols — is that a failure anywhere in the system be treated as an emergency stop for all trains using the system. Of course, the question then becomes… how do you detect a failure or spurious command?
Just like law enforcement having body cams. Lots of value until the policemen turn them off.
Braden, crews are already required to get authority to disengage PTC at least on BNSF’s California lines. I work for Amtrak and the big problem comes from “passing the buck” between the host RR and Amtrak as to who will say “ok, disegage PTC and run on signal indication”. This has delayed trains for up to 25 minutes because no one wants to make a “command decision” and take responsibility. Oh yeah, and keep the RR fluid as the San Joaquin valley line is, for the most part, single track. PTC is a goddamned joke, but hey your government knows best.
After this incident crews will be required to get mandatory authorization to disengage PTC or a software upgrade will have remote access to stop any potential cutout of PTC
PTC isn’t all what it’s made out to be.
John Rice
Your analogy between PTC and police body cameras is a false dichotomy since police are not supposed to turn those body cameras off(they’re a requirement in many departments to protect the officers, not the public). The simplest outcome from this investigation is that the yard to yard and switching options of turning PTC off will be removed and it will be required to be on at all times, the locomotives failure to connect when already in motion is not something you can require it be on for.
I don’t understand why it took this long for this info to be public. Also, can’t understand why you would need to turn it off for switching. You’d still be within movement limits…
NS requires authorization before a crew may cut out PTC as well.
Please refer to my comment under the previous day article on PTC and software.
Bottom line: PTC is not a panacea. It will not and cannot prevent all accidents on a railroad, any more than any “software” can prevent all accidents or problems anywhere else (ask Boeing…).
Anyone who thinks otherwise — and I’m sorry if my bluntness offends someone — is a d____d fool, or a politician.
The best defence — as I said yesterday — is the constant care and vigilance of the men and women who run the trains.