Amtrak Derailment Philadelphia (5/12/2015)

Amtrak Unlimited Discussion Forum

Help Support Amtrak Unlimited Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
However this is all speciulation. I'm sure the investigation will be thorough and not leave a stone unturned to evaluate all the evidence.

Before that, anything we say is pure conjecture.
So true.

BUT - when the NTSB finds serious problems, like with this unfortunate case, or the Metro North case last year,

Preliminary warnings from them and FRA come out real soon.

Like - "get that PTC" (or ACES or whatever) working NOW.

Which is what I think NTSB and FRA have made very very clear.

The final report will take a year of careful sifting of evidence, will evaluate not only cause but emergency response (seems good) survivability (could seat belts help, did seats or car parts break loose and cause injuries) etc etc.
 
Third rail:

Do you know that the throttle sends its commands to the traction motors via a (hackable) computer? I can't say definitively, but I question that.

Tom
Computer yes, hackable unlikely. Those computers are no different from hundreds of them running around in Europe in EuroSprinters.

But Thirdrail is correct in stating that when one investigates accidents nothing is off the table until it has been investigated thoroughly and then taken off the table.

Incidentally, I will be riding behind a EuroSprinter in a couple of weeks, two weekends after this coming weekend in fact. :)

BUT - when the NTSB finds serious problems, like with this unfortunate case, or the Metro North case last year,

Preliminary warnings from them and FRA come out real soon.

Like - "get that PTC" (or ACES or whatever) working NOW.

Which is what I think NTSB and FRA have made very very clear.
That actually is not at all what NTSB and FRA said. They specifically asked Amtrak to use the existing ATC system to put in place achievable safe speed control heading into this curve from the west, pending the commissioning of ACSES later this year. They have also asked Amtrak to identify other areas where there is a speed limit drop of more than 20mph (if I recall correctly that was the number and is the same one as in response to Spuyten Duyvil) and apply the same ATC based controls to enforce safe speed. Everyone realizes that this might add some amount of time to the timetable.

I have described the specifics of what has exactly been done in a different post on the signaling thread.
 
Last edited by a moderator:
NTSB Chairman Christopher Hart “We know that a properly installed and functional positive train control or PTC would have prevented this accident.”
Bureaucrat BS.

We do not know as fact that a properly installed and functional PTC would have prevented this accident.

A properly installed and functional PTC probably would have prevented this accident, but it is not certain a properly installed and functional PTC would have prevented this accident.
 
Not related to the most recent posts:

We know that before the emergency brakes were applied by the engineer, the train had accelerated. That would at first seem to indicate the engineer wasn't dozing or incapacitated, but I have a question for those familiar with the locomotive. Could the throttle be moved forward if someone fell onto it (from dozing or some medical issue), or are there "stops" or extra sideways movements involved in putting it into different notches or speed levels that would make that unlikely? Just wondering. I know it's all speculation at this point.

The engineer had a good record and it's just hard to imagine that he was being deliberately reckless or that inattentive if he was well and awake.

As this was a new type of locomotive, even if its computer was not hacked, could there have been a software bug that caused this? IIRC, there was a plane crash, or perhaps near-crash, of an Airbus in a scenario where the plane's computer would not accept (overrode) the pilots' input and they could do nothing. Again, just wondering. I know next to nothing about these locomotives.
 
Last edited by a moderator:
I'm having trouble coming up with a scenario where this accident could have occurred with functioning PTC in place.
The key here is "functioning." In ITCS territory (Niles, MI?) not so long ago, an Amtrak train in 110mph territory was incorrectly routed onto a side track with loaded ballast hoppers. The PTC system was in-place and "operating" but since someone had left a jumper wire in place inside a signal cabinet, it showed clear. Fortunately in that case, the engineer had decided to hold off accelerating to 110mph for whatever reason and the train still came to rest within a very short distance of the loaded hoppers. My personal chief concern with PTC is the increase in complexity and complacency that will and has developed.

***NOTE: These details are coming from memory, when I have time later, I will verify them and make corrections as appropriate***
 
Yes. Human ingenuity will always be able to thwart the best designed automation, simply because humans have this false belief that they can always be better at it. :) Ehile it is true that at times human intervention is needed, and there are specific procedures for doing so, inevitably there will be someone who will come around who intentionally or otherwise will fail to follow the laid down procedures and then disaster happens. And after that inevitably we see endless moaning from people trying to completely irrationally defend the possibly irrational act of a person even before all the facts are in and the investigation is completed.

In the ITCS case mentioned it was the human ingenuity of the signal maintainer that caused the trouble. In the slow speed Acela derailment it was possibly that of the Engineer and the Dispatcher together (don't quite recall exactly what happened there off the top of my head). The fact that we have a safety system on the NEC built of bits and pieces of a modern control system glued onto an obsolete signaling system provides for many more opportunities for things to go wrong requiring human intervention providing opportunities for human ingenuity to insert itself in the loop, sometimes to the rescue and sometimes to disaster. But we got what we got and we have to learn to live with it. It is as simple as that.

So to come back to Ryan's question - PTC as it appears on the NEC depends on about 7 different interfaces where things can go wrong. In a clean slate ERTMS design and implementations there would possibly be two or three only. When there are more parts that can break, the likelihood of breaking increases. So the best of intentions can still be undermined. Nothing is for sure. However, after all the speechifying is done by everyone that wants to make speeches, at the end of the day unless we are willing to pay for a superior safety system, we will not have one.
 
I'm having trouble coming up with a scenario where this accident could have occurred with functioning PTC in place.
The key here is "functioning."
Well, yes - that's what the chair said:

NTSB Chairman Christopher Hart[/size]

“We know that a properly installed and functional positive train control or PTC would have prevented this accident.”[/size]
Sounds like a pretty safe absolute statement to me.
 
IIRC, there was a plane crash, or perhaps near-crash, of an Airbus in a scenario where the plane's computer would not accept (overrode) the pilots' input and they could do nothing.
The Airbus flight computers won't accept invalid inputs. I suspect that you're thinking of the Air France crash off Brazil a few years back. Allow me to quote Popular Mechanics (I've underlined the important bits):

The plane has climbed to 2512 feet above its initial altitude, and though it is still ascending at a dangerously high rate, it is flying within its acceptable envelope. But for reasons unknown, Bonin once again increases his back pressure on the stick, raising the nose of the plane and bleeding off speed. Again, the stall alarm begins to sound.

Still, the pilots continue to ignore it, and the reason may be that they believe it is impossible for them to stall the airplane. It's not an entirely unreasonable idea: The Airbus is a fly-by-wire plane; the control inputs are not fed directly to the control surfaces, but to a computer, which then in turn commands actuators that move the ailerons, rudder, elevator, and flaps. The vast majority of the time, the computer operates within what's known as normal law, which means that the computer will not enact any control movements that would cause the plane to leave its flight envelope. The flight control computer under normal law will not allow an aircraft to stall, aviation experts say.

But once the computer lost its airspeed data, it disconnected the autopilot and switched from normal law to "alternate law," a regime with far fewer restrictions on what a pilot can do. In alternate law, pilots can stall an airplane.

It's quite possible that Bonin had never flown an airplane in alternate law, or understood its lack of restrictions. Therefore, Bonin may have assumed that the stall warning was spurious because he didn't realize that the plane could remove its own restrictions against stalling and, indeed, had done so.
 
Senators to probe deadly Amtrak crash


Senators are planning to hold a hearing about a deadly Amtrak accident in Philadelphia that killed eight people last month.
The Senate Commerce, Science and Transportation will meet on June 10 to discuss the crash and efforts to install automated train control technologies that investigators say would have prevented the deadly accident.
 
Both Boeing and Airbus have had problems with the complex control modes that are involved in providing different levels of safety envelope protection, and pilots either misunderstanding or simply losing situational awareness of what mode they are flying in, leading to mistakes. Such was involved in the Air France crash in south Atlantic. The Asiana short landing at SFO also involved such misunderstanding leading to mishandling. Actually NTSB did criticize Boeing's design of the modes in case of the latter, and Airbus also got dinged a bit by the French BEA (equivalent of NTSB) on the Air France crash.

Now the safety envelope issue is much simpler in case of trains since they can basically move only in one dimension - along the track. Also it is relatively easy to bring the train to a completely safe state i.e. stopped dead on the track. So the overall problem of maintaining a train within a safety envelope is a much simpler one. It should be noted though that these engines do have the so called "cruise control" function AFAIK, which means that the control system does have limited capability to accelerate the train within the safety envelope, i.e. upto a speed that is the lesser of the signal speed, the civil speed limits, the maximum speed coded for the engine and the speed set in the cruise control. In case of the Frankford derailment there was no safety envelope other than the engine speed limit of 125mph since Clear does not in and of itself have an associated signal speed limit. I am not sure what exact code is put in the track for Clear on the Frankford curve.

So that does leave some room for the possibility though highly unlikely, of a control system failure leading to a speedup.

And finally, yes you can make the railroad completely safe using the ATC system but add an hour to the schedule of everything possibly. You can make it even safer by simply not running any trains at all. Safety is always a matter of balancing functionality against safety, and it is always easy to second guess a decision with 20/20 hindsight of a single event.
 
Last edited by a moderator:
Fundamentally, Boeing and Airbus have had different philosophies going into FBW designs. It was Boeing's contention that a human made need to make a maneuver that may, in fact, over stress the airframe for safety. The control laws allowed for that. The pilots still had to know how to fly the plane and understand the performance limitations. Airbus tried to take out that factor and make the control laws such that it would be impossible to leave the flight envelope. Now, this is the first time I've heard of alternate law, which I presume (rightly or wrongly) added after the initial fly-by-wire designs.

The control laws in an aircraft, albeit much more complex than in a locomotive, are subject to programming. And, as such, prone to human error. Flight testing can get 99.999% of the bugs out of the system, but perhaps just maybe a subroutine could be called out that was never contemplated which could thwart the control laws.

If you think train by wire or fly by wire is scary - I've read that there is work being done on fly by wireLESS. Pilot sends a command by RADIO to the control surface actuators and engine management system. Now that's scary.
 
The biggest problem so far has been in the ergonomics of the machine human interface regarding the operation of the aircraft under various laws. A significant proportion of the recent mishaps have been traced back partly to the loss of situational awareness regarding which law one is operating under at a given moment and confusion about what that means in terms of operations. Not much has been found in the way of actual bugs in code causing anything.

The moral equivalent of that on the NEC would be if the Engineer was confused about whether ACSES is in operation or not, and had formed a habit of ACSES warning for each civil speed limit. In that scenario, if there is a stretch with no ACSES, and Clear signal then such an Engineer could overspeed. This would be a typical case of a safety envelope protection being absent and the operator forgetting that it is absent.

The Air France stall to some extent was related to such a phenomenon, and that is what is believed explained the irrational behavior of the pilot in command. He was flying the plane as if it was under normal law, while that plane had actually transition to one of the alternate laws that did not provide the recovery to safety that he was depending on to correct the situation in the back of his mind.
 
And that is a true concern. There would have to be (and I'm surprised that Airbus apparently didn't have) a CLEAR indication when the automatic functions of the computers are disabled - whether in trains or airplanes. Training certification would require simulation in each circumstance.
 
*SNIP*

If you think train by wire or fly by wire is scary - I've read that there is work being done on fly by wireLESS. Pilot sends a command by RADIO to the control surface actuators and engine management system. Now that's scary.
UGH! Anyone who thinks fly-by-wireless is a good idea needs to be smacked hard! :angry: I could maybe see it as some kind of backup system if all the electrical cables running to the controls get cut (highly unlikely enough) but to rely on it is...unthinkable!
 
Hey all those UAVs are flown by wireless links. So start thinking fast. It is past the time for "unthinkable". And those UAVs, the larger ones are quite capable of carrying ordnance that can cause some serious damage.
 
There's a bit of a difference between wireless to plane, and wireless to the plane's control surfaces. The way UAVs are designed, a momentary loss of contact in the case of the former isn't likely to cause a crash, while a momentary loss of the latter could be catastrophic. Only the smallest (RC) craft are essentially direct wireless links to the control surfaces.
 
There's a bit of a difference between wireless to plane, and wireless to the plane's control surfaces. The way UAVs are designed, a momentary loss of contact in the case of the former isn't likely to cause a crash, while a momentary loss of the latter could be catastrophic. Only the smallest (RC) craft are essentially direct wireless links to the control surfaces.
You are making a whole host of assumptions about the architecture used for the latter which IMHO is unwarranted. Given your assumptions yes, there is a problem. But I would at least give the engineers working on such a benefit of doubt as to not being idiots.
 
There's a bit of a difference between wireless to plane, and wireless to the plane's control surfaces. The way UAVs are designed, a momentary loss of contact in the case of the former isn't likely to cause a crash, while a momentary loss of the latter could be catastrophic. Only the smallest (RC) craft are essentially direct wireless links to the control surfaces.
You are making a whole host of assumptions about the architecture used for the latter which IMHO is unwarranted. Given your assumptions yes, there is a problem. But I would at least give the engineers working on such a benefit of doubt as to not being idiots.
I would give Russian or Iranian engineers the benefit of the doubt on that. American engineers, never. :)
 
Back
Top