SoaringTheSkies;
Re your thoughtful response at
#1315,
sorry, but the (non aviation) engineer in me sais differently:
First, I appreciate "the engineer in you"! It's a partnership with the designers, of this there is no doubt.
As I said earlier, the systemic failure of this accident is terribly similar to the Birgenair 301 accident in 1996. In both cases, a faulty sensor was the single input to an automation system that subsequently flew the airplane into a stall.
I disagree. These two accidents bear only superficial similarities. I think it is beneficial to understand why. The main reason is, the similarity between the static/pitot sensors and a Radio Altimeter in terms of the nature of potential outcomes should one or the other fail, especially in the two accidents cited, is minimal.
An airplane with an unreliable Radio Altimeter can be flown without a problem - it is a non-event. I have seen it, flown it, seen such spikes/dropouts in flight data. I have also flown a B767 with serious pitot-static problems, (at night, over mountains) and know the potential for disorientation.
Because the crew can become quickly disoriented in an airplane with a faulty static port or pitot tube in IMC (Instrument Meteorogical Conditions- not sure you know the term, sorry, and both the Aero Peru and Birgenair flights were at nightm over water), the aircraft is at great risk without a very disciplined crew response. There is a very good reason why QRH's (Quick Reference Handbooks for Abnormals/Emergencies) now have detailed guidance for pitot-static system faults. There is an equally good reason why there is very little in the QRH regarding either subtle or obvious Radio Altimeter failure because it isn't an issue.
There may be engineering aspects to this but this isn't fundamentally an engineering issue. It is an airmanship, piloting issue.
When on approach, especially below 1000ft above ground, the pilot flying should have his/her hands on the thrust levers. The thrust reduction would have been felt as the thrust levers came back. Yes, that would be a natural response of the autothrust if the speed was high, (airplane capturing glideslope from above), but at some point the speed is going to bleed off as the glideslope is captured and maintained. If the thrust levers don't respond with more thrust, the pilot does his/her job and flies the airplane. A pilot NEVER waits for automation to do it's job if it isn't doing it's job. Once again, that isn't an engineering issue, it is a pilot issue.
But: both events shouldn't have developed to anything serious in the first place, because at least theoretically, all relevant information was available to the automation systems to make a decision to either continue in a coordinated, safe mode (A/T and A/P feeding off a known good data source) or to completely hand it off to those humans who, in ambiguous situations, should know better what to do than the engineer behind his desk.
I take your point, think it's an important one and am glad you're thinking this way as an engineer. However, there is no way "automation" could have been employed in either the Birgenair or Aeroperu accidents. No automation system can function on erroneous data - we have ample proof of that of course. The pilots had to intervene and hand fly and in an extremely short period of time, become test pilots in equally extremely demanding circumstances.
The kind of piloting intervention we are discussing here likely happens hundreds of thousands of times a day in almost every landing carried out by large and small transports alike. It is what we do - we fly an airplane and in a tragic moment of ?....this crew didn't. It really is no more complicated than that.
No system can be designed that can successfully and without creating collaterally-serious problems which didnt' exist before said design, to protect against human error. No automated system which is designed to tell the driver of a car that he should brake because the car in front is rapidly approaching, should be relied upon nor faulted for the rear-end collision....Nor, I will hastily add, do we have the right to expect that our accepted responsibilities, in this case professional ones, will be appropriated by engineering design solutions - they must, of necessity, always remain in the "assisting" role. Tricky, I would assume, but that is why this discourse is so important.
Again, thanks for your response.