 |
Re: PTC failure: Toledo Blade on CSX Carey wreck
Author: OPRRMS
Date: 10-02-2019 - 21:27
John Bruce Wrote:
-------------------------------------------------------
> But if we take the example of the Philadelphia
> excessive speed accident a few years ago, the
> assumption is that an operating PTC system would
> prevent it, and if PTC did not, it would have
> failed to override the crew failure. So it would
> be a PTC failure had PTC been operating in that
> instance, but it wasn't, so it was a crew failure.
> Let's take a possible explanation for the Csrey
> accident, the crew was somehow able to disconnect
> PTC due to some yard requirement, but failed to
> reconnect it on the main (as best I can understand
> this). This would be a severalfold failure. I
> would think PTC would be smart enough to recognize
> its different states in yard or main service and
> reconnect itself if there were a discrepancy. If
> it were not, I would think this would be a defect
> in basic design, though not a strict malfunction.
> If the crew were instructed via policy simply to
> trust PTC, this wouldn't be a crew failure. I
> would also take the example of the 2008 Chatsworth
> head-on and suggest the crew failure could have
> been enabled by management laxity. But in general,
> the point of {TC ought to be to override every
> possible crew failure, but record the override
> action for management attention. I would think
> that except for each unanticipated situation not
> covered by system design, PTC ought to be
> overriding every known opportunity for crew
> failure and the system updated each time something
> new happens.
This incident is nothing like the Philadelphia or Chatsworth incidents.
-------------------------------------------------------
> But if we take the example of the Philadelphia
> excessive speed accident a few years ago, the
> assumption is that an operating PTC system would
> prevent it, and if PTC did not, it would have
> failed to override the crew failure. So it would
> be a PTC failure had PTC been operating in that
> instance, but it wasn't, so it was a crew failure.
> Let's take a possible explanation for the Csrey
> accident, the crew was somehow able to disconnect
> PTC due to some yard requirement, but failed to
> reconnect it on the main (as best I can understand
> this). This would be a severalfold failure. I
> would think PTC would be smart enough to recognize
> its different states in yard or main service and
> reconnect itself if there were a discrepancy. If
> it were not, I would think this would be a defect
> in basic design, though not a strict malfunction.
> If the crew were instructed via policy simply to
> trust PTC, this wouldn't be a crew failure. I
> would also take the example of the 2008 Chatsworth
> head-on and suggest the crew failure could have
> been enabled by management laxity. But in general,
> the point of {TC ought to be to override every
> possible crew failure, but record the override
> action for management attention. I would think
> that except for each unanticipated situation not
> covered by system design, PTC ought to be
> overriding every known opportunity for crew
> failure and the system updated each time something
> new happens.
This incident is nothing like the Philadelphia or Chatsworth incidents.
