PPRuNe Forums - View Single Post - AF 447 Thread No. 7
View Single Post
Old 15th Nov 2011, 15:29
  #280 (permalink)  
DozyWannabe
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by AlphaZuluRomeo
I'm aware that some terms used are not the proper ones, but being on an aviation forum I felt OK to use them as intended by other posters. Besides, english is not my mothertongue.
Not a problem - it wasn't intended as a criticism of you or your writing, it was just a case of getting the terminology straightened out.

So, about logical/algorythm errors:
...
They see the outcome, which is that from a pilot's point of view, the system is illogical.
Absolutely - I'm all about the information-sharing though, for two reasons. Firstly, to a software guy, seeing minor inaccuracies like that would be a bit like you guys reading "The plane crashed because the pilot pulled on the wing flaps that make it climb or descend" in the papers - the difference is that in your case it's well-meaning, but it still gives me a nervous tic when I see it, so sorry about that. Secondly, we know journos trawl these pages, and the last thing we need is a headline like "PILOTS SAY COMPUTER ERROR AT HEART OF FATAL AIRBUS PLUNGE", or similar silliness.


Well, I cannot. Could you elaborate, please? I did the reasonning with: "Would a pilot (provided he's aware & not mental) trim up when the aircraft is (near) stalled?" I could not see a single reason/circonstances where the answer is "yes".
The problem (as you state below regarding another point, and as I think I said in my original reply) is with false positives. If a sensor jam or genuine technical error causes the stall warning to sound when the aircraft is neither at or near the stall, that solution would prevent the pilot from trimming up when he wanted or needed to. You're then faced with the option of holding attitude with the primary controls and thrust (which would be fatiguing) - or if the limit applied to autotrim only, forcing pilots who are not used to trimming manually to do so at altitude with an abnormal situation on their hands.

I don't know why the A320 sim limits the nose-up trim and the A330 didn't in this case. Someone suggested that the limit might be airspeed-dependent, but the TRE had failed both ADCs. It's a question to ask Airbus, for sure.

About complexity: Yes, such a feature would add one more logical test.
See airtren's post - it's a lot more involved than that, going right back to the specification and trying to define potential knock-on effects of the change.

it doesn't seem a big deal to Airbus either because the NU autotrim is inhibited in Normal Law when the pseudo equivalent of the S/W (namely: the AoA protection) is active (ref: FCOM A330). If they can implement it in Normal Law, the complexity argument is IMO moot in Alternate Law.
The protections are a separate subsystem entirely from the annunciation/warning subsystem. There is no overarching logic connecting them, which makes implementing such a change considerably harder. I can see where you're coming from, I just think that a hard limit on autotrim under certain flight control circumstances would make more sense.

Other way is perhaps to inform the crew (how: to be thought) that currently "AoA measure is invalid. Consequence: S/W inop". That far more simple to implement, and avoids the need to "assume" what the S/W state should be.
With an eager and switched-on crew, sure that'd work. But this crew in the wee hours appeared not to notice a Stall Warning that was blaring in their ears for nearly a minute. By the time the AoA values became invalid, the situation was pretty grim - what chance they'd notice the warning you suggest?

Yes, I'm sure the V/S source switched. There is such a parameter in the FDR traces : "VERTICAL SPEED SELECTED FROM ADR (1=ADR 0=IR)"
Thanks, it's been a while since I read it in depth (thought I've gone back to specific traces briefly since.


The logic hole I saw there is that while A/P and A/THR are dropped (i.e. the crew must re-engage them manually if they want them back), the F/Ds seem to just go flagged, but come back "from themseleves" when the conditions seem back to good: Would it not be better to let the crew manually re-engage the F/Ds, having assessed the which data are good and which are not?
I think that design decision is a compromise - i.e. after an abnormal situation like that, would the crew notice that FDs were available and switch them back on again? I think the idea there was that they'd bring the FD back once the data was good, it would then be up to the crew to either use, disregard or disable them.

Food for thought - thanks!
DozyWannabe is offline