PPRuNe Forums - View Single Post - AF 447 Thread No. 7
View Single Post
Old 14th Nov 2011, 00:29
  #201 (permalink)  
DozyWannabe
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
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:
OK, that's cool - and that was all I was asking for. I'm puzzled as to why other posters regard it as though it's like pulling teeth and expect me to jump through hoops for them before I get a reasonable answer. Let's have a look!

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)
So first of all, looking at these in a cursory manner, these are not "logical errors" in terms of software engineering - the term has a very specific meaning which is whereby programming instructions that are syntactically correct nevertheless produce erroneous return data. What you're describing here is a situation where a system operating in the field has produced results that highlight potential issues going right back to the specification (or indeed a set of circumstances that the original specification did not or could not take into account) - the result of which is what us nerds refer to as a "change request".

Now I've got that rather dull bit of nitpicking out of the way, let's dig in.

1. Limiting the autotrim in response to a stall warning sounds good in theory, but you're going to have two major problems right off the bat. The first is quite simple, and that is "what happens if the stall warning is false?". I can foresee a couple of situations off the top of my head where that could be more dangerous than letting the trim run. The second is a bit more esoteric and complex, and indeed can apply to all the things you're talking about, and that is the increase in complexity such a change will add to the system as a whole. Determining the knock-on effect that change would have is a very involved process and the logic paths would have to be scrutinised at a very in-depth level, and of course you run afoul of the old engineering maxim that adding complexity is increasing the number of potential points of failure. That said, it looks like the A320 has a hard nose-up limit on the autotrim in Alternate of 3 degrees, while the A330 does not. I'd be interested to know what they discovered inbetween development of the two airliners that led to that change. I think that a hard limit would probably be a more effective solution than checking against Stall Warning status (which is after all in a completely different subsystem and may or may not be valid).

2. I wouldn't be surprised if most airliner designs of a mid-80's vintage or later have similar logic. Determining whether a stall warning is valid or not has been a tough nut to crack for a long time, and in an overwhelming majority of cases, the limits set probably make good sense - I mean this is the only case where it has been perceived as an issue and in order to make it one the aircraft was taken further out of the flight envelope than any test pilot would dare attempt. On paper it looks sensible, because Stall is a function of AoA, and the limit of the AoA vanes' effectiveness as reported by the supplier is <60kts. I saw talk of using a WoW switch earlier, and I don't think that the designers would assume that if the computed speed is less than 60kts then the aircraft must be on the ground, given how in-depth they went and how many permutations they went through to arrive at the spec they did. In their shoes I'd be thinking "if we know that the data is going to be unreliable past this point, then it's probably best discarded". Unfortunately they didn't bet on the set of circumstances that caused AF447 (specifically "what if an aircraft was held in a stall to the point where that limit is reached?"), and even those who have no particular love for Airbus have to admit it's an edge case to end all edge cases. I have no clue how easy or difficult it would be to latch the current stall warning status when that limit is reached, and I foresee complexity arising from what to do once a recovery has been effected (namely "We've latched stall warning because we can't trust the data, so at what point can we start trusting it again?").

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?
These are definitely trickier as they depend on a given reading of the DFDR data in Interim #3.

3. Are you sure that the V/S trace indicates mode-switching from air data to inertial and back? I was told that the extreme variations towards the end of the trace indicate the static ports being fouled by the airflow induced by the stall, and it is not until the computed airspeed is in the low 100kts area (by which point the stall is well-established) that the readings start to look wrong

4. For starters, I'm not sure how to read the FD trace accurately, but they are inhibited when airspeed data is lost (as you'd expect them to be) - those spikes during the period of actual UAS indication might indicate attempts to re-engage them manually, but I have to defer to more knowledgable folks there. The FDs come back on (as they are designed to) when the airspeed data returned and then switch off again as the aircraft slows to the point where presumably the stalled air is playing merry havoc with the pitot/static and AoA sensors

In these cases, the situation the aircraft found itself in was so extreme that I wouldn't know where to start in terms of getting reliable and accurate data. I wonder what difference having the BUSS might have made?

Last edited by DozyWannabe; 14th Nov 2011 at 02:07.
DozyWannabe is offline