Indarra - I believe BEA are correct to focus on 'how they got there' rather than 'what they did then', since there was ample evidence of a stall both in the cockpit warnings PLUS surely the basic knowledge that if you 'zoom' at high level you will run out of the big skyhook.

There should never have been ANY need for 'advanced' recovery experience, since proper control of the a/c AND recognition of and an appropriate response to the zoom and stall warnings would have avoided the 'flop' into the high AoA stall they created. Surely the aim MUST be to have pilots who can react correctly to the initial flight path divergence rather than giving training in recovering from an extreme situation.

Regarding the altimeter presentation - even given that the 'digital' display is less intuitive than the analogue dial, I still find it hard to accept that the sight of the numbers in the box spinning rapidly (does it really matter which way?? - it should NOT be happening, whichever way) did not jerk them into looking at what was happening.

> Quite some time ago I stated a belief that the inhibition
> of the stall warning below a certain speed was very unlikely
> to be Airbus-specific.
> This is something I still believe quite strongly.

Just because you believe it, doesn't make it good system
design. Rather the opposite in that if the a/c is stalled
at 60 knots, then it's definately still stalled below this.
Common sense suggests that the logic should be that if the
system detects a trend downwards in airspeed that goes
through the stall warning and then on past the 60 knot limit,
the warning should stay in place until the system data is
known good and the a/s reaches a safe level. Put another way,
if the system knows that the a/c is stalled, it should assume
the worst if it has less data to work with subsequently. It's
almost as though some back room systems engineer thought:
"The sensor data is bad, so logically, we must inhibit the stall
warning", conveniently missing the whole point of the
exercise.

The success of any automated system comes down to: How intuitive
is it in use; How accurately and consistently does it communicate
current system state to human operators; How gracefully does
it degrade beyond the design limits. No matter what the report
says, I think many at AB will be peddling furiously underwater
for quite a while :-)...

Regards,

Chris

Can I pose a possibly naive question for pilots who fly long-haul routinely?

Cockpit manning was in three shifts, which seems standard for the length of the flight.

The Captain was PNF for the first shift. He was off-duty for the second shift. However, before he left the flight deck, he asked which of the two co-pilots was going to be landing the plane, and I assume the answer was the second co-pilot, who had just completed his rest.

So the Captain hadn't assigned himself any flying at all.

Is this usual? For the commander not to get his hands on the controls at any stage of the flight?

Already done - CS25 Amendment 6 25.207 (c) - introduced after AF447 reads:

This effectively would prohibit any speed related cut off of warning

I never said it was!

The point I was getting at was that not only was there a clear reference to the speed-based inhibition in the report (which made the assertion that the BEA was covering for Airbus's system design incorrect), but also that if other manufacturers' types exhibit similar behaviour, then again it relates to a design issue in general and not one specific to Airbus.

Now, according to the report this aspect of the design appears to have been instituted because of potential failures of the AoA vanes at takeoff leading to a false stall warning - which would present a hazard close to the ground (this also means that the suggestion of adding WoW switch to the trigger inputs wouldn't work). Essentially this accident has provided a secondary worst-case scenario where the inhibition can mislead a troubleshooting process. You and I both know this is complicated stuff, don't we? :)

(Which reminds me - I should pick up my 68k assembler revision soon...)

Hi DozyWannabe,
I don't follow that logic.
If the stall warning triggers with airspeeds >60 kts, then why not simply suppress the nuisance warnings on the ground when the airspeed is <60kts AND WoW?

Owain Glyndwr;

I think the quoted sentence was introduced with JAR-25 Amendment 96/1, effective 19.05.96, incorporated in Change 15 dated 1 October 2000. It must be read in conjunction with the provision you quoted earlier, that in the demonstration of stall characteristics recovery is initiated as soon as the airplane is stalled.

Furthermore, FAA Advisory Circular AC 25-7A dated 31/3/98 states:
"If artificial stall warning is provided for any airplane configuration, it must be provide for all configurations, and continue throughout the stall until the angle of attack is reduced to approximately that at which stall warning was initiated." and -
" Stall warning tests are normally conducted in conjunction with the stall testing required by 25.103 (stall speeds) and 25.203 (stall characteristics)."

@rudderrudderrat:

I'm thinking of the worst-case scenario where ADIRU or pitot tube failure occurs at or just after rotation. If you're going to inhibit based on WoW, this potentially opens a can of worms. A spurious SW at FL250+ is one thing, but it's even more deadly on climbout.

In general, when making amendments to complex systems behaviour it is important to ensure that providing a solution for one failure mode does not adversely affect the solution for existing failure modes.

Hi DozyWannabe,

Sorry - I must be a bit dozy. I still don't understand.
The stall warning is triggered when measured Alpha exceeds some threshold. Alpha > X. The vanes are unreliable in airflow less than 60 kts. Therfore:
1) Inhibit when IAS <60 kts = No good for AF 447 scenarios.
2) Only Inhibit IF IAS <60 kts AND WoW, else Shout when Alpha > X

Why would 2) make a false stall warning on climb out more likely?

Adding a layer :)
At less than 60 knots ... even on takeoff .. you are on the ground not close to the ground .. so no hazard
And at 70 or 100 knots .. you are alway on the ground
Sorry but I don't understand the logic of this design ... (60 knots)

If air data failure causes a read of <60kts and the weight comes off the wheels. It's an edge case for certain, but probably needs to be considered.

[EDIT : Hold up - I see what you're saying. You're talking about WoW *in addition* to <60kts. My memory may be playing up, but I think some were proposing ditching the speed requirement entirely and using WoW instead. ]

HN39

OK, thanks, I didn't have the documentation to check back exactly when it appeared in CS25, but on checking back I see that JAR25 Ch 13 has the same wording, but with one important difference:

If you read that with the requirement that stall recovery is to be initiated promptly then one can see why the designers didn't cover the case of an aggravated (I like that description) stall. Without "throughout the demonstration" they would have to cover the AF447 situation. - at least that would be my interpretation of the rule.

Owain Glyndwr,
It was in the FCOM for a long time : here

Hi DozyWannabe,
Correct. The TriStar crash at JFK was partly caused by a false stall warning as the weight came off the wheels. All they had to do was hold 12.5 degs pitch and climb away.
ASN Aircraft accident Lockheed L-1011 TriStar 1 N11002 New York-John F. Kennedy International Airport, NY (JFK)

The best logic would surely be:
only inhibit whilst on the ground AND if IAS <60 kts Else Shout.

CONFiture

OK - thanks for that info.

Owain,

The most recent version of the FAA Flight Test Guide, AC 25-7C, dated X/X/2012, has this:
I tend to think that, if your interpretation of the rule had been intended, then that meaning would have been stated more explicitly.

maintaining stall warning
 

Hi,

Trying to control the stall-warning with a context-free rule is likely to be very difficult/unrewarding.

It's much easier to use some sort of finite-state-machine.

Minimal version might be something like:

State: SW_OFF
....if ( AoA_excessive & AoA_trusted) then goto SW_ON

State: SW_ON
....if ( AoA_acceptable & AoA_trusted) then goto SW_OFF

where:
AoA_trusted is true if speed > 60kts

How exactly does (2) work ?

The issue is that when IAS < 60kts Alpha = NaN (or NCD or whatever invalid indication). This happens before the SW computer.

So, is NaN > X or not ? That is the issue the SW logic has to decide.

You can't just fix the SW logic, in any meaningful way. The input data simply isn't there in this scenario.



You could maybe give the SW memory so it uses last-valid value, which would catch the 447 scenario - but that adds complexity and failure modes there.

Or you route raw AoA around the ADIRU for SW purposes - which is I think what the BUSS solution does (as a side effect of its main job) ?

Dozywannabe, #201

There are other sources that could be used as well. Ground speed,
altitude and vertical speed are in theory available from the ins,
which is completely independent of the air data system. Such data
could be used for a sub level sanity check of the air data system.
If the adr disagree and drop out, there is a historical trending
relationship between ins ground speed and adr air speed, which will
be valid short term as degraded data. Whether this is used in the
330 is not known, but it doesn't seem to have been available in any
form to the crew or the stall warning functions.

For stall warning inhibition on the ground, ins data is arguably
a far more relevant source than anything else and wouldn't
require any wow detection ?...

Maybe Hazelnuts, and it may be just me, but I am still stuck with the change to the European rules (and EASA are the more directly affected) - why make that change if they did not mean something by it? They don't usually change long standing wording on a whim. Perhaps FAA just haven't caught up yet - and you know as well as I that there is often a time gap between US and European certification changes.

For what it's worth
 

First up - I'm a regular member of the SLF community. The closest I can claim to understanding the intricacies of what happened on AF447 other than as a layman is a psychology degree (from Manchester University when a certain Swiss cheese theory Jim Reason was at the helm of the Psychology Department). I've been following the discussions on here since the incident in 2009 - thank you for everyone, irrespective of what side of the fence you're on with regard to the unending man vs. machine automation debate. It's been illuminating, fascinating and reassuring to see the unfortunate event dissected and debated by professionals from all walks of life. One hopes that through debates like these, things can only get better.

So my tuppence for what it's worth... From my understanding of the report (which I think overall reads as thorough and even handed), clearly there were some issues in terms of BOTH crew resource management and ergonomics in times of high stress, but the thing that screams out to me as fundamentally wrong in terms of 'how can this be!', is on page 192 of the report: The copilots had not undertaken any in-flight training, at high altitude, for the “vol avec IAS douteuse” procedure or on manual aeroplane handling I find that fact absolutely terrifying - irrespective of how automated the plane is I would have thought that advanced manual airmanship skills should be mandatory for any commercial pilot, irrespective of altitude!. Indeed I can't help but notice a correlation between the well publicised potentially fatal incidents which have been averted, thanks to the fantastic skills and experience of the pilot. Notable of course (and a completely unrelated incident), is of course the one on the Hudson where the pilot was a keen glider. Everyone travelling on that flight was obviously very lucky to have that particular pilot at the controls, but surely we should be looking to reduce the role of 'luck'. But what do I know...

So my question for the pilots out there: Could airlines ever be persuaded to go back to basics and do more to boost the manual flying skills of commercial pilots, irrespective of the level of automation on a designated aircraft?... Indeed completely change the structure of training so that when training on a specific aircraft, pilots start 'manual', with automation added, layer by layer? (adding layers to the onion so to speak)... Ultimately, so that every pilot is confident (relatively speaking), and knows what it feels like, to fly said aircraft when controls / automation have gone t*ts up?

Excuse my ignorance and sorry for interrupting - I'll continue lurking for now. Many thanks again for everyone's contribution

There were substantive changes to that paragraph. It is entirely possible that deletion of the words 'througout the demonstration' was thought to be editorial, non-substantive. In any case, those changes had nothing to do with AF447.

Perhaps the condition that all three AoA values are NCD while the airplane is in flight should be considered a failure of the stall warning system:

Hmm, I'm afraid you might be quite on the mark with this objection. This could very well be the reason why they implemented this less than ideal solution.
Circumnavigating the ADIRU in certain instances while going through it normally might open up new cans. (Additonal mini ADR required with possible discrepancies to main ADR's requiring redundancies and another Error Handling logic...)

From a boolean perspective a solution seems possible and even not too complicated but it might indeed conflict with their basic system design necessitating less than ideal workarounds causing other trouble.
Will be interesting to see if, when and how they can fix this.

I seem to remember that Boeing does have a similar logic of suppressing the warning if the speeds are too low. Anyone any idea if they are working on that topic as well?
Do they also calculate SW behind the ADR modules (which normally makes a lot of sense as you would otherwise need an additional mini ADR unit to convert the Raw data in a usable format just for the Stall Warning alone).

maintaining stall warning
 

infrequentflyer789

You can't just fix the SW logic, in any meaningful way.

I beg to disagree, see post #213

The input data simply isn't there in this scenario.

Yes, you do not have a meaningful value for AoA (here represented by a NaN), so cannot use it in a context-free rule to indicate if the stall-warning should be sounded.

You could maybe give the SW memory so it uses last-valid value, which would catch the 447 scenario - but that adds complexity and failure modes there.

As you say, remembering any previous sensor value (e.g. AoA ) leads to extra complexity and failure modes.

However holding the current state of the stall-alarm would not introduce such problems.


In "IEEE FP speak" my AoA_trusted and your AoA are related by: AoA_trusted = NOT(isNaN(AoA)).

Indarra,

IMO, the role of the accident investigation authority (BEA, NTSB, etc.) seems to be misunderstood at times. Their role is to investigate accidents with the sole objective of improving aviation safety. To do this they:
- Obtain and assemble factual information regarding the accident
- Analyze the factual information
- Reach a conclusion on findings of the cause or probable cause
- Make safety recommendations.

Now granted PJ2 and Dozy did some SIM work to look at whether or not recovery was possible (it appeared to be) and Owain Glyndwr did analysis depicted in graphical charts which indicated recovery was theoretically possible. However, this is not information that can be construed factual unless actual flight trials were conducted in an A-330-200 aircraft to support/confirm the theoretical findings of SIM and analysis. For example, the AA Flt.191 out of ORD went down in an asymmetrical stall shortly after liftoff. The NTSB never addressed if the plane could have been recovered satisfactory but concentrated, based on factual investigation how the accident got to this point in the first place. Afterwards, at least two university studies concluded the plane was recoverable. However, approximately 30 pilots when confronted with the problem in a SIM failed to recover the airplane. This is why speculative information or theory based information shouldn't enter into a failure report out, it could be right or it could be wrong.

Digital verses Analog - Well, take a look at the NW B-727 accident during climb out of JFK on December 1, 1974, also a stall accident. In this accident the analog altimeter didn't help either. In fact, I wonder if, at that time, digital altimeters were available, if some people would have concluded a digital altimeter would have helped.

Just some thoughts to consider....

100% with you :ok:

Hazelnuts
As I said, it maybe just me, and it's certainly not worth a lot of discussion, but regardless of whether they intended it to be just editorial, for me, as a one-time designer, that editing changes the S/W duration requirement from conditional [i.e.linked to a prescribed demonstration technique] to mandatory without explicit or implicit time limits. But as I said its not worth an argument.

I don't really see why the logic that AoA vanes are not reliable below 60 kts should have any effect on problems with untoward stall warnings near lift off. Unreliable AoA signals because of dynamic effects yes, but that is a different problem.

With my interpretation of CS25 if it is flying you believe the AoA signal(s) and latch the S/W until the AoA comes back below the threshold and is confirmed to be so. Airbuses have a logic that changes the laws from ground to flight modes, so why are people debating complicated 60 kt and WoW combinations?

Turbine D: Well said!

Just as a matter of interest and to get away from the WoW debate; does the AoA < 60 KT actually represent unreliable AoA vane angles at sea level or maximum service ceiling? I have feeling it may well be the latter.

Any takers?

Turbine D, Re, "Also 100% with you!

Re your earlier comments on the differences in our own sim stall exercise and the way AF447 was handled, yes, ours was a far more brisk pull-up and the comments you and BOAC offered ring true.

mm43. Are you saying that the actual AOA may have been greater than 45 degrees? Perhaps much greater?

Unexplained ACARS WRG msg
 

In one of the the preliminary reports it was hypothised that this msg was caused by an attempt of the pilots to shut down one or both of the affected computers.
"02:11:55 - .1/FLR/FR0906010210 27933406EFCS1 X2,EFCS2X,,,,,,FCPC2 (2CE2) /
WRG:ADIRU1 BUS ADR1-2 TO FCPC2,HARD
"
Now the data should be available to either refute or verify this assumption, but I have not found anything about it in the final report. Did I miss it?

Regards

AOA Vane Speed
 

Just a reminder that way back, I did a test with an airline type AOA vane using the hand out the window trick in my car. It came alive at less than 20 mph!

They really don't take much wind speed to activate. 60 Knots might relate to reliable airspeed measurement issues. The key issue is that AOA data is valid in its own right and should never be controlled by airspeed as to whether it is considered valid.

As we see with AF447, they had well over 100 knots airspeed on the way down, it just wasn't being directed into the pitot tubes.:*

It may be more a question of accuracy than of reliability.

Machinbird

With all respect due, your "hand out the window" AoA car vane test was'nt done witht a -50 degre TAT.

However, I agree.
It's seems to me that AoA vanes effective range is plus or minus 50 degre
(AFAIR).
(and I am sorry coming back with Tarom 1994 event: the plane was stalling with a quite vertical attitude, but the recorded AoA was 'only' 45 degre. Sure, real AoA was out of range).

Best regards

Or is it the angle at which valid CAS is no longer calculated?

Machinbird;

Thanks for reminding us about your experiment. I know the original reason given for the AoA vane invalid @ < 60 KT was to prevent spurious SW in the approach and departure regimes, but it has now been demonstrated to be confusing when the envelope gets "extended".

Say again???

I certainly cocked up that question!

I actually meant that when CAS of < 60 KT was calculated, the ADRs deem that the AoA vane angle can no longer be relied upon. In other words I answered my own question.:ouch:

Lyman,

At the end of the recording the flight path angle relative to earth was -45.2 degrees, and the pitch attitude was +16.2 degrees. In still air those values would correspond to an AoA of 61.4 degrees. With a tailwind component of 24 kt the AoA could have been about 70 degrees.

Does everyone agree that at FL350 when they lost airspeed and autopilot they should not have pulled up to a 14 degree deck angle and stalled the airplane? If they hadn't done that and had done what any experienced pilot would do and hold attitude and power and get appropriate UAS check list we wouldn't be discussing this now.

If they did stall at 38,000 any competent pilot could recover from a stall and not crash unless for some strange reason he thought holding full or almost full back stick would help him recover. Please tell me no pilot here would do the same thing they did.

If they .. had done what any experienced pilot would do and hold attitude and power and get appropriate UAS check list we wouldn't be discussing this now.

Probably we are all agreed on that point.

any competent pilot could recover from a stall

One might hope that such would be the case.

However, there is, at least, one caveat (and I note I have no background on the Airbus flock).

While some of our number have had the opportunity to experiment in sim exercises with an indication that recovery might have been possible, we note that the beloved sim is a computer not an aeroplane. The observed sim characteristics are only as good as the aeroplane model programmed and this in an area of the envelope where the model would be expected to consist of extrapolations rather than hard FT data.

There remains the question of just what real world (stability) characteristics the particular aircraft might have had in the circumstances, hand flown at high FL without the computers' assistance. The CG was fairly aft at around 29% (as I recall) and recovery from a deeply stalled situation may have presented a crew with some unusual or unexpected problems. While many may censure the crew and the particular operator's training systems for getting to the stalled situation in the first place, it may be appropriate to cut the guys in the hot seat some slack so far as "oh dear (or words to that effect), what do we do now ?" might be concerned.

Different matter for an experienced experimental TP but we are talking about two line F/Os who (so far as I am able to divine) had no broader experience. Indeed, there are some very experienced TPs who frequent this place and, with any luck, we may get some pertinent comments from those good folk.

Ultimately it will be interesting to see if AB provides useful guidance on the matter ?