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.