Originally Posted by
carlosgustavo
STALL WARNING MUST ALWAYS WORK. Its unveliable that on the Airbus with that pitot probe on icing condicions doesnt.
Its funny for me how people blame the pilots because the stall warning sound for 57sg and they didint recognize the stall. Dont you understand that when the stall warning stops means NOT STALL, but the aircraft wad actual stalling.
Originally Posted by
MountainBear
This is exactly what I mean by burden shifting.
In response to my comment about stall warning logic several posters claimed that the situation AF447 found itself in was a set of facts that simply couldn't have been anticipated prior to this accident. But part of the job description of engineers and designers in all fields is to use their imagination, not just their reason. It's not a defense to say "We failed to anticipate" when part of your professional and ethical duty is to anticipate.
If you'd like to have a look at this post in the other thread, courtesy of thermalsniffer. This post does not (IMO) have the definitive translation from the French, but it is the first I've seen that syncs the CVR details up with the facts in the BEA note released in June :
http://www.pprune.org/tech-log/45687...ml#post6614845
Then please check your prejudice at the door and listen carefully.
The Stall Warning sounded initially, at 2:10:10.4 and at 2:10:13. This was in response to the drop in IAS caused by the blockage of the pitot tubes. This is likely a false warning and stops. I would suspect (though I have no proof as my notes don't go into the required detail) that the IAS component of the stall warning logic is disabled when an ADR DISAGREE status is in effect - at least, if I was designing the logic, that is how I'd have it work.
(Note, this is not how the software is actually written, being instead generated from a graphical representation of the logic paths, but I hope it will suffice for demonstrative purposes)
Code:
if (STALL WARNING && ADR DISAGREE)
then
STALL WARNING INPUT PARAMS = AoA ONLY
else
STALL WARNING INPUT PARAMS = AoA AND IAS
The reason for this is because it was discovered from the Birgenair and Aeroperu crashes (and it had been suspected but impossible to prove from as far back as BEA548 at Staines in 1972) that aural warnings can be filtered out by the human brain under stress conditions - therefore it is prudent to determine which of the aural warnings is valid and only present those.
I don't believe that IAS would be considered a valid input to stall warning for the sake of it, as stall warning is purely a function of AoA, which is the way stall warnings have been implemented for a very long time. The only logical reason I can see for introducing an IAS parameter would be to filter out false warnings.
Now, back to the transcript. The second time the stall warning starts is at 2:10:51, which as I understand it was around the point of the apogee of the zoom climb and the point at which the aircraft approached and then began to fall into the stall regime. This stall warning is the real thing, and it continues for just under a minute. During this time the nose-up inputs are aggressively maintained and the aircraft starts bleeding off even more airspeed. If I've understood correctly, for at least the first 10 seconds the real stall warning was sounding, if not slightly longer, all the pilots had to do was push the sidestick forward and the aircraft would have come out of the stall. They were, however, not trained in this escape maneouvre, having only been trained on the approach to stall.
The stall warning stops at 2:11:45, and during this time the stall warning has been sounding for almost a minute, during which time the inputs have been almost universally nose-up (i.e. incorrect and making the situation worse). Also during this time, the pitots have become unblocked and crucially
the speeds are once again valid and ADR DISAGREE is not longer in effect. What this means is:
- Stall warning is inhibited due to a *genuine* IAS reading of less than 60kts
- At this point the aircraft is falling at or near terminal velocity and is unrecoverable
Therefore, while with 20/20 hindsight, the Stall Warning logic should be reviewed (potentially by adding air/ground mode detection as an input to the logic if this is not the case already*),
the inhibition of Stall Warning at 60kts and below had no causative effect on this accident, because by the time the aircraft had reached this point it was already too late. That the initial false Stall warning triggered (and was quickly silenced) at the same time as the PF made his initial (and only significant) nose-down input was an unfortunate coincidence, but the fact remains that the stall warning system was doing it's job correctly from the point at which the actual stall began to the point at which the aircraft was way outside the flight envelope, nearly a whole minute later.
I apologise for the bluntness of this post, but I wanted to make it as crystal-clear as I could.
[* - after all, you don't want a stall warning blaring at you during initial takeoff roll and landing rollout... ]