Originally Posted by
CONF iture
It would have greatly complicated the all issue and probably bring more confusion to an already very confusing situation.
AT THE TIME the procedure was to simultaneously pitch down and apply full thrust. In other words it would have unnecessarily destabilized a situation that was under control.
Those Air Caraibes crews did so well under such confusing environment
Well, I can't argue that the pilots did a good job of diagnosing the situation and determining the spurious warnings from the real ones. However, the dangers of such things happening due to a failed pitot/static system have become much more well-known and better understood since the loss of the Aeroperu and Birgenair 757s for the same reasons (and with similar symptoms - stick-shaker and overspeed warnings simultaneously). I'd imagine it takes something of a mental leap for pilots who are conditioned to implicitly trust their instruments to determine which of the instruments cannot be trusted.
The very nature of that kind of failure is hugely dependent upon the failure mode of the sensor concerned, and it is not a matter of being able to prescribe a set of actions that will definitively tell you that there's a failure in the pitot/static system. As such, I think the BEA are right to be cautious. If they had made such a prescription and an incident occurred where the stall had turned out to be real, then they would be in the firing line.
Originally Posted by
JD-EE
IT professionals are much like that...
You make some very good points, though I think it's worth making clear at this juncture that the kind of computer/IT issue that you and I encounter daily is a world apart from those encountered in the kind of real-time systems developed for aviation.
That said, some of the better ideas to come out of those disciplines, particularly unit and regression testing, have been making inroads into mainstream software development practice over the last decade.
For non-IT people, the concept is to test each software function across the range of expected inputs, unexpected inputs and edge cases to make sure that the output matches the specification. You then do the same with multiple functions arranged in the manner they will be put together in the final system until you have a comprehensive set of tests that cover the whole application. These tests are then run throughout the software development and maintenance cycle, and if a single one of those tests fails, then you know you have a deviation from spec.
The main advantage of this is that you can prove on paper that the software matches the specification, and the secondary advantage is that if a change in one component causes unexpected behaviour in another, it will be caught in the test harness.
In the case of the A320's software, they went one step further and had two teams working in isolation providing separate implementations - if there was even the slightest match between the two, one team would be told to rewrite the functions from scratch. You then have a "quorum" of machines that can run the data through both implementations and any logical errors can be discounted.