Mr Optimistic

PJ2 - thanks again. Sorry about all this: was the answer 28000 feet ?

PJ2

Mr. Optimistic

Re your earlier question about when the captain returned was 20k of altitude sufficient?

The captain returned when the aircraft was in descent passing FL355 just as the stall warning stopped due to "NCD" from the AoA vanes and the VS was about -10,000fpm. The sim exercises showed that recovery could occur with aggressive ND sidestick, held until the airplane began flying again and that took between 18,000ft and 22,000ft depending upon the exercise and when recovery actions began, (SS moved from NU to ND, etc). (that is a 4000ft difference but bear in mind at these descent rates that is also about 12 seconds.

The answer depends more upon the actions taken than it does on the airplane once recovery actions are aggressive and in place. I don't think part ND SS would do it in 20,000ft and it may not do it at all from an AoA of 40deg.

RR_NDB

Hi,

Considering what was learned by operators and pilots until now:

Is it probable a similar case (UAS, cruise) where crew "don't understand"?

What kind of man-machine interface enhancement could be useful to allow immediate crew "understanding" of the issue (UAS), in order to go DIRECTLY to the "fix"? (UAS drill, whatever)
I'm assuming crew never identified the UAS. This (lack of understanding) subsequently being aggravated by inadequate PF SS handling and wrong perception of speed, misleading (PF) persistently to try reduce it (350 to apogee). Always increasing (continuously) the "lack of understanding" of PF/PM then Captain, by several consequences of initial errors.

mm43

Well, they did. Or at least the PNF announced the loss of speeds and later the change to ALT Law.
Page 54/55 of BEA Interim Report No.3 provides detail on what should have been done under the heading:-

1.17.4 Air France crew operational instructions

The real question should be why the PF believed he could manoeuvre the A/C at FL350+ the same way he had been trained to do at below FL100. Ultimately what was done right/wrong and by whom boils down to bad CRM associated with as yet undetermined Human Factors. I do find it "a bit of a stretch" to blame the systems/human interface when many similar situations have been successfully handled by other crews. All this crew were required to do is detailed in AF SOPs.

Machinbird

It is all well and fine to put something down in a written SOP, but if you do not test people to verify their understanding of the SOP, then you are asking for major violations of the SOP.

Since PF & PNF had apparently not had a chance to demonstrate flight in cruise in ALT2 law under UAS conditions, they were open to uncorrected misunderstandings.

If the regular sim sessions were not long enough to exercise this capability, then they were not long enough. Any misunderstanding should have been found and fixed. That falls right on the bean counter's and upper management's heads.

Organfreak

How about another aural warning? "Unreliable airspeed! Go to memory items!" I realize that this crew was already overloaded with warnings, but if the airplane "knows" it's in UAS, there's no excuse for it not to use every means to notify the pilots.

RR_NDB

Quote:

...when many similar situations have been successfully handled by other crews.

Statistically speaking ONE case of COMPLETE lack of understanding after trigger (3 Pitot's then UAS) among other < 40 cases reccommend attention to EVERYTHING. (HF, man machine interface, etc.). We must remember similar conditions (no visual references, turbulence, etc.) could occur again.

My point is:

1) Considering "frequency" of UAS cases traced to the use of now obsolete Thales probes.

2) Considering some cases were related to the use of competitor probes, currently and still in use.

3) Considering they became "rapidly lost" and "increasingly confused"

4) Considering Pitot's data (simultaneous failure) are still today not adequately processed (NO REDUNDANCY AT ALL) by System

5) Considering identification of UAS presently has to be done by scan and feeling (as linked paper put)

6) Consider PF was caught in surprise and acted almost immediately (by "lack of speeds" as you observed)

I ask:

Why not to provide an instantaneous (even non causal, before an eventual Law change) indication to the crews (Airbus SAS, Boeing, Embraer, etc.) (PRECISELY) of UAS?

Complementing: The point is, everything SIMPLE and PRECISE the System (through the man machine interface) provide to the crew, if possible (UAS is) IMO increases the safety of the plane operation.

Surprises (coming from her ) better to avoid.

The mentioned paper (i am considering still valid and "official") led me to this point.

AF447 case was not "triggered just by "tiny ice crystals" affecting "obsolete AS probes" in a System operating without redundancy (Air data).

AF447 case was triggered (it seems to me) by a "lack of understanding" of what was really happening. UAS as everyone know, causes erratic indication in several indicators as mentioned in the linked paper. The Pitot data (considered GARBAGE by the System designers) during a transient phase are still fed to pilots (they receive this "input") that need to rush the scan in order to just identify UAS. As the paper points.

If the System tells you (on UAS) you save time (precious) and could act MUCH more precisely and fast.

IMO, the "interface" should be reviewed. Why? Because in my opinion can be easily improved with good cost benefit relationship.

BUSS could still be an optional. (STD in 380);

An UAS indicator could be Standard. At least before we solve the Pitot's issue.

Evolution (stepwise) is not based in "blaming". Sometimes "a tweak" (as you know) "makes a difference"

Ultimately what was done right/wrong and by whom boils down to bad CRM associated with as yet undetermined Human Factors.

I agree. But remember:

CRM and HF "becomes critical" under extreme difficult conditions. In Portland the crew had time to digest the surprise (gear problem). F-GZCP had few seconds and apparently never understood and realized the "benign" problem: Simply an UAS. That shortly "dissipated".

RR_NDB

Hi,

Open to everything specially in EXTREME conditions.

The information (Pitot's "garbage out") is available. The System (a subsystem) could easily process and present the results. How? This must be studied. The interface must be always kept simple. K.I.S.S. principle is mandatory to the interface characteristics.

PS

HF study could be extended to upper management, bean counter's and System designers. .

In order to understand why they fail. And to improve man machine interface.

DozyWannabe

They're on the last pages of the previous thread and the first pages of this one.

Turbine D

I wanted to make it a little easier to see each of the SIM experiences, so I put them all together in this post. Each experience is followed by answers to questions by other posters. I didn't post the questions (saving some space) but they should be evident from the answers. Hope this helps....

From CONF iture:

As we got little extra time in the sim today, we did experience a full stall from FL350.
Here is what I can report from the experience :
From the STALL warning we kept a light aft pressure on the sidestick
It was not long before we got a negative vertical speed of 15000ft/min
THS went to 12 deg UP under STALL warning
As we decided to exit the stall, full fwd pressure on the sidestick was applied
But we were unable to lower the nose
THS did not move
THS was then manually rolled fwd
Nose came down
Exit was then possible
I can't remember all the details, too much stuff to look at.
Thrust was kept at idle all the time.

Early fwd pressure on the sidestick at initial STALL warning should prevent a stall to develop.

From DozyWannabe:

What we had was an A320 sim rather than an A330, which comes with some key differences - the most obvious of which is the lack of Alternate 2, the nearest equivalent being Alternate without speed stability, and a different underlying architecture past a certain point.

The first experiment involved setting the conditions to night IMC with CBs in the vicinity, having set the autoflight to take us to 35,000ft and hold us there. We had a friend of his who is a TRE sitting in the LHS to provide guidance and monitor what we were doing. He then failed the ADCs, leading to autopilot disconnect and a drop to Alternate (without speed stability) and we tried to follow through and maintain a 15 degree pitch angle. Things we noted:
I'd suspected it would involve considerable effort to hold the sidestick there for a significant amount of time, but I was genuinely surprised at just how much.
The zoom climb occurred exactly the way we expected
The Alternate Law (no speed stability) on the A320 seems to have a hard trim limit of 3 degrees nose up
It was definitely possible to hold the aircraft in the stall with 3 degrees of nose-up trim and full back stick, but it required effort
The aircraft wanted to nose down and recover itself, and with about 10 degrees of nose-down maintained with the sidestick at the moment we passed about 30,000ft, we managed to effect a recovery with the speed coming back up to a point where we could level out safely at about 20-25,000ft judging by the standby altimeter.
The second experiment was the same as the first, but as my pal had noted, the A320 has a hard limit of 3 degrees NU trim available via autotrim in the secondary Alternate Law. We tried again, this time winding in full nose-up trim manually just prior to the point of stall. This time:
The aircraft seemed more willing to hold pitch with the trim at full-up, but to hold it at 15 degrees still required considerable effort
We had to add a touch of rudder (on the TRE's advice) to control the roll.
Despite full nose-up trim, we elected to start a recovery as we came down through about 35,000ft this time, just to see if it was possible using sidestick only
Following the same 10 degree nose-down sidestick demand as before, the trim rolled forward with the sidestick demand, returning to around neutral within about 5-8 seconds, and we came out of the stall as before.
Based on this, as far as the A320 is concerned at least, recovery is possible using autotrim via sidestick only even when the trim has been manually wound fully nose-up. Given more time we'd have liked to see what happened attempting recovery at lower altitudes, but the general take-away seems to be that with sufficient forward sidestick demand it is possible to recover from stall even with trim forced to where it's not supposed to be.
Further details I've just been reminded of - the stall stabilised at approx 180kts IAS on the sim control with the nose-up trim at 3 degrees (the A320 hard limit). With full nose-up trim the stall was similar, but stabilised at approx. 160kts IAS. The Stall Warning was not only clear, but so loud that the TRE had to cancel it with the Emergency Cancel button in order for us to hear each other. On the second (full nose-up trim) experiment, all I had to do was briefly glance down to my left to see the trim roll forward - smoothly and *very* quickly - following recovery via sidestick pitch down.

Some questions answered:

Having conferred, we loaded extra fuel so that the FMGC showed MAX ALT FL379. C of G was 32% MAC. The ROD in our experiments maxed at approx 6,000ft per minute, with the VSI needle turning amber in the PFD. One of the reasons I hope someone will perform a later experiment will be to see how leaving the recovery till later in the sequence will affect the ROD, and hopefully also find out how a 40% MAC CoG will affect things. The caveat here is that the later you leave it, the further outside the tested flight envelope you go, and the more divergent the sim's performance from the real thing will become.
After the initial NU pitch increase (induced with approximately half back-stick, as in the DFDR traces), we triggered a very short "G" induced stall warning as we climbed, then when the real warning sounded continuously (as happened in the AF447 scenario) we applied TOGA and held 10 to 15 degs pitch on the sidestick - during which full deflection was required in order to come close to maintaining it - as I said, the nose wanted to come down naturally if I released pressure for even a split-second.

Initially, autothrust dropped to Thrust Lock. We pulled the thrust levers back to match the thrust, but as we moved them the thrust increased slightly. The TRE then deliberately staggered the TLs slightly to induce a roll to the right which we trimmed out with rudder and the slightest touch of aileron.

From PJ2:

With weights, CG, SAT mirroring AF447 and a bit of turbulence, following loss of airspeed (all 3 ADRs out), the sim was pitched up at FL350 and held in the climb until stalled, (THS reached 13.6deg). Shortly after the stall we returned the ADRs for use during the balance of the exercise, (to see the FPV during the stall).

Post-apogee (approx FL360), full forward stick was applied and held.

At FL330 the pitch was 8deg ND.

At FL310 the AoA (using FPV) was approx 40deg and the VSI was 18000fpm +. Pitch was about 14deg ND which was all the pitch that could be obtained.

Pitch slowly reduced to about 10degND still with full forward stick. As it was held the THS unwound and returned to normal settings.

We could watch the AoA reducing as the FPV slowly climbed "up" the PFD from past the red ND warning arrows below 30deg pitch marks.

Thirty seconds after the first Stall Warning passing through FL270 the AoA had reduced to 30deg, descent rate was 16000fpm.

Ten seconds later at FL255 the AoA was 12deg, CAS was 250kts, VSI was 7400fpm.

At FL245 the stall warning stopped 40 seconds after it began, the AoA was 10degND, M0.658, VSI 7000fpm down, CAS 278kts.

From an AoA of 40deg to 10deg took 24 seconds and about 6000ft. This exercise took about 22000ft; some were less.

Overspeed was never a problem nor was a secondary stall if one was gentle, (took about another 6000ft IIRC)

Some questions answered:
Normal cruise pitch attitude is between 2.3 and 3deg depending mostly upon weight. A pitch up to 5deg pitch attitude (+2.5deg) results in about an 800 to 1500fpm climb and a gradual loss of energy if held long enough. The UAS QRH checklist and the FCTM cautions strongly against holding such pitch attitudes for long and advises to get the QRH out quickly and set pitch and power. The FCTM also states that the Memory Items are not to be done if the immediate safety of the aircraft is not impacted.

For the purposes of the exercise there was no "judging" of how much to pitch up. We pitched up high enough to stall the aircraft. Fifteen degrees would do it, sometimes we were higher.

The overriding impression of these sessions was how quickly things occurred and how fast was the altitude loss.

My comment about "how quickly things unfold" is an observation on the amount of time it took to lose control. Time is always "relative to perception and familiarity". When a pilot is highly trained, highly experienced and very familiar with his/her airplane, the flow of even huge amounts of information and lots of events flow much more slowly, perceptually, because the mind anticipates much more effectively and easily, (depending upon other factors such as distraction, fatigue) than if one is relatively inexperienced in such circumstances.

In terms of this loss of control, while it unfolded literally over a period of about 40 seconds, oddly that is tons of time to do something, but it is not a lot of time for assessment, discussion, action.

In re the sim exercise, power was at various settings (though never TOGA). Also, there were variations in altitude needed for recovery. In one exercise we "did nothing" and the aircraft happily remained in stable flight at FL350 as power remained in "TOGA LOCK" (last setting before disconnect) and the pitch at 2.5deg, approximately.

gums, you're right about the sim not really being able to teach this kind of thing - you can't feel "the mush"...the slight delay in responsiveness in both changes in attitude and flight path even though the subtle indications may be accurately simulated.

The exercise was a worst-case - fully developed stall, late recovery attempt, thrust was not idle. As I mention to HN39, a smart recovery, (as in brisk forward stick at the first stall warning blip, held fully forward without variation, thrust at idle), can be made which reduces the altitude required. It's still going to take a lot of altitude to a) regain the AoA and b) regain the energy, (due low availability of excess thrust, so its height for energy, initially).

Thanks HN39...the FPV symbol was 10deg below the line dividing blue and brown on the PFD, which to me indicated an AoA of roughy +10deg while the aircraft was still descending rapidly, so it was my clumsy writing even though I think the meaning came through for most others. On the stall warning, in fact the first exercise there was no such warning because we had all the ADRs off, then on for the FPV later - we did it again using a different failure method to get the sim into Alt 2...these are details behind the larger exercise but technically correct - my posts are almost always too long as it is.

In my non-engineering view, the sim "behaved" as I expected the airplane might. I don't have experience with the Cooper-Harper scale although I am familiar with it and my own characterizations of the airplane were probably generous. The warning and cautions which accompanied the CAS and ADR failures were less distracting than I had anticipated.

I gathered from the session that it's difficult to simulate the loss of pitot/static information and get the exact same failures/ECAM messages and the method that got closest was failing ADRs and then re-instituting them to some degree. It didn't affect sim behaviour but it does affect available indications. This is a long way of explaining that I can't answer your question with any meaningful information. On one stall we had no warning which was because all ADRs were still failed and on others we had full FPV indications...a bit ad hoc in this area.

CONF iture

Never heard read or seen anything like it ... Anyone with valuable experience on 320 to confirm this ?

mm43

Let's go back to AF447 Thread No.4 Post #616 - which was directed at you. My point is that if the A/C is to "detect" and "report" UAS, the system may as well be programmed to maintain the "status quo" as I proposed.

I can agree with your point, though I believe Airbus would prefer that these sort of "misunderstandings" by third parties didn't impact on its bottom line.

Diagnostic

@mm43,

I agree sir that the PNF announced those 2 points, but as we see in the CVR transcript, no-one mentioned (i.e. vocalised) the UAS process (memory items - decide whether needed or not, then QRH). If we accept (as I do), that there will be no relevant words omitted from the transcript we've seen (e.g. I don't need to read any "last words" from the crew, if they said things to loved ones etc., so their omission wouldn't surprise me), then either they (especially the PF):

a) did truly recognise the UAS situation, didn't vocalise that recognition, and forgot that there was a procedure to follow (IMHO unlikely);

or

b) did not truly recognise the UAS situation for being that, and (this is speculation by me) treated it as some kind of unknown instrument / system failure, which they then got (terminally) bogged-down in trying to understand - which was not helped when instruments responded in unexpected ways when stalled, even though they were not faulty (e.g. low IAS due to high AoA affecting the pitot probes, leading to intermittent stall warning etc).

On the evidence I've read so far (in all the BEA reports and these threads), I vote for (b). This adds me to the list of other readers who believe that a explicit "You have a UAS condition! Follow the UAS procedure!" warning, may have helped, instead of the procedures assuming that the UAS condition would be correctly recognised by every crew, every time.

As you have pointed out, adding such an explicit UAS warning could then lead to an attempt at automation keeping the "status quo" when that happens, although I see that as a step of development beyond that of just giving a warning.

I'm sure some of the professional pilots will say that a trained ATPL pilot should not need that kind of "spoon-feeding", and I don't disagree. However for various reasons too long to explain right now, experience in my own (non-aviation) field makes me think this sort of explicit warning message should be seriously considered (not that Airbus or Boeing or any other manufacturers care what I think ).

I respectfully disagree that "similar situations have been successfully handled by other crews" (depending on the subjective interpretation of "similar" and "successfully" of course ) as I explain here:
http://www.pprune.org/tech-log/46062...ml#post6673738
http://www.pprune.org/tech-log/46062...ml#post6747450
http://www.pprune.org/tech-log/46839...ml#post6804546

The BEA (in interim report 2, page 51 onwards in the English edition) discuss those UAS events with enough details to examine (13 to be exact). To quote myself from previously:

"Sure, none of the other flights crashed, but several were not handled according to the QRH, not all of them went into Alt* law meaning that subsequent actions cannot sensibly be compared to AF447"

The BEA explicitly mention the lack of other crews following the correct memory items, among other things. Therefore this looks much less like an AF447-only mistake IMHO, and makes the system/ human interface again an area where there should be focus, given that UAS events will continue to occur with current pitot technology.

RR_NDB

Hi,

mm43:

I agree fully with you. After 7+ months "doing some R&D on that, i became progressively convinced the Man machine interface (very probably) played an important role on this case.

The reason i specified "just indications" (instead of "actions") was twofold;

1) Allow a smooth learning curve (for all "players"). Is stepwise.

2) Doesn't represent "automation". Just another "AID". An extra resource.

Why not a COMBO: (UAS & AOA). Two major "components" here.



PS

Certainly your post #616 was processed (in batch ) all this months. thank you for remembering. I wouldn't.

Diagnostic

@RR_NDB,

Hi,

I know your post wasn't addressed to me, but I just wanted to say that I agree with all your points above

I wonder why this explicit UAS warning isn't being done already. Is it that plane manufacturers are assuming correct recognition of the UAS situation every time? (A dangerous assumption, IMHO, with confirmation of that danger provided by the BEA report that I mentioned.) Or is there something which we're not considering, that is preventing them providing this explicit warning?

Lyman

A sore spot since the beginning. Rapid understanding is critical, there is no call for delay, imho. Yes, resources. "WARNING: speeds suspect, recall Pitch and Power for conditions and config. No delay."

There was a great pressure, to which BEA succumbed, in releasing a memorandum which Airbus scanned and re-released.

"There are no NEW mechanical issues with our a/c, per BEA"
They needed that for the airshow.

Diagnostic, consider what it would mean in the middle of this investigation, for Airbus to reconfigure their cockpit systems to include UAS/WARN.

Everyone knows the problem, but so long as Airbus do not address it with upgrades, it does not "exist".

To react is to confess. In the case of Air France, they had a reason and an excuse to r/r the Pitot Probes. The PILOTS would not fly until they were changed.

It would be impossible for pilots to gather to protest a fleetwide problem caused by the aircraft itself........and not just a subcontractor eg Pitots, or Duff "pipe"

No amount of soothing words can alter the fact that UAS remains a problem for the platform, not just the pilots.

mm43

@DiagnosticThanks for your well thought-out post.

That "step beyond" was an attempt to stop the initial "misunderstanding" and/or "startle factor" that has previously been discussed. It may be viewed as problematic to an outcome, but we are currently dealing with an outcome that became a "problem".

bubbers44

Since hand flying skills are not required any more maybe the autopilot should just go to attitude hold and autothrottles freeze in their cruise mode. No more stalls at 35,000 and training doesn't have to be changed. New guys with 350 hrs would love it.

HazelNuts39

Not all UAS scenarios are as obvious as AF447. The high altitude / ice particle scenario is a relatively recent addition to the family.

RR_NDB

Hi,

Diagnostic:

Quote:

Or is there something which we're not considering, that is preventing them providing this explicit warning?

Important question. Some possibilities. Will comment ASAP.