 |
Re: LA Times story on Metrolink vs BNSF incident at Rialto [link]
Author: SP5103
Date: 11-22-2008 - 17:07
We observed the speed aspects being immediately and precisely enforced - to the letter. The engineer had to be on his toes, as we soon discovered. While at 79 mph, we received a "40mph" aspect due to a diverging route ahead, setting alarms off. Almost immediately, the engineer dumped the throttle and applied full service brakes - the alarms quieted. As we approached target speed, he partially released the brakes to flare in right at 40mph. But he did it just a little too soon (at about 45 mph), resulting in more alarms and a full service dump to a screeching halt (irretrievable braking). This in front of the FRA observer! But the FRA did get to see how tight the enforcement really was. Of course, the engineer immediately made the requisite report of his error over the radio, while he was waiting for the controls to reset.
While there are those that might call this "progress", It appears to me this might be too sensitive electronic system unnecessarily interfering with a skilled engineer from doing his job. By this description, acceptable methods of train handling have given way to trying to shut up the #(&@$# alarm and serving a computer system designed to bureaucratic specifications. No doubt a change in aspect should have some kind of audio clue, but not a continuous alarm because the engineer and train has not had any time to react.
As far as the most recent Metrolink oooops, one could speculate that there is a possibility that the brakes (dynamic or air) did partially fail. It would be interesting to know what the event recorder says. At what speed and how far from the signal did the engineer apply the brakes, and at what point was an emergency application made? Assuming that Metrolink's contractor suddenly has two persons in the cab, what are their qualifications? The FRA is investigating no doubt, but I'm not sure this incident would normally involve the NTSB.
I am in favor of a realistic PTC system that reminds the engineer of a apect change, and if the engineer is failing to take action to control their train then PTC does. It does not sound to me that the one above is anything I would want to deal with.
While there are those that might call this "progress", It appears to me this might be too sensitive electronic system unnecessarily interfering with a skilled engineer from doing his job. By this description, acceptable methods of train handling have given way to trying to shut up the #(&@$# alarm and serving a computer system designed to bureaucratic specifications. No doubt a change in aspect should have some kind of audio clue, but not a continuous alarm because the engineer and train has not had any time to react.
As far as the most recent Metrolink oooops, one could speculate that there is a possibility that the brakes (dynamic or air) did partially fail. It would be interesting to know what the event recorder says. At what speed and how far from the signal did the engineer apply the brakes, and at what point was an emergency application made? Assuming that Metrolink's contractor suddenly has two persons in the cab, what are their qualifications? The FRA is investigating no doubt, but I'm not sure this incident would normally involve the NTSB.
I am in favor of a realistic PTC system that reminds the engineer of a apect change, and if the engineer is failing to take action to control their train then PTC does. It does not sound to me that the one above is anything I would want to deal with.
