Originally Posted by
AlphaZuluRomeo
For the record, and despite I doubt it would have changed the outcome in the light of the crew actions, I see two of them:
1/ the non-inhibition of the nose-up autotrim when stall warning is active
2/ the inhibition of the stall warning under 60kt IAS (even if I understand the logic behind the inhibition, I still think it may be worth reworking that bit of logic)
And perhaps a 3rd and 4th, but as I don't know the logic behind I'm not qualified to fully comment:
3/ the V/S switching source from air data to inertial (and back); it occured in AF447 and its consequence was a non-readable/unreliable/unrealistic displayed (air data sourced) V/S, while at the same time a reliable/realistic V/S value (aka inertial sourced V/S) was available (for the system).
4/ the non-inhibition of the F/Ds (by the system) when an UAS situation is detected: why? A/P & A/THR may (and have) been dropped, why not the F/Ds as they may give unreliable directions in such a situation?
I agree with those, with some caveats.
1/ Not sure about preventing upward trim only - you then turn THS into a control that can only ever ratchet nose-down which doesn't sound good. Maybe a fixed travel limit, but you'd need to ensure that the available range will give you all the control you need in the event you've got to a continued false stall warning. The whole autotrim area needs looking at in and out of stall IMO - too many incidents of autos trimming up into a stall and then handing the pilots the problem. It isn't going to be a simple problem with an easy answer though.
2/ I wouldn't be suprised if this was at very low level "close" to the senosrs and in hardware rather than software. Whether you term hardware issues "bugs" or not, it's a design issue (right down to what the AOA and pitot probes actually dleiver) that needs looking at.
4/ I think they do inhibit, may depend how you get into UAS though. But the switching in and out has got to be distracting and potentially confusing. Hence something with some real intelligence should switch it out and bring it back when things are properly understood and stable again. Now, what's the first UAS memory item again...
I'll also throw in another potential design issue, with the caveat that I'm also "not qualified to fully comment":
5/ the system notifies / warns of UAS, and changes control law etc., all well and good but where is that notification to the crew when the speed sensing is ok again ? I'm not sure there is anything (or nothing explicit) ? These pitot failures have been held up as transient events, lasting tens of seconds. They are being (mostly) correctly detected (but not prevented) by the built in checks and redundancy. But if the system never reports a return-to-normal, how is the crew to know ?
I believe this crew were still attempting to troubleshoot the UAS event well after it had passed, and when they should have been troubleshooting their real (correctly indicated) airspeed being fatally low.