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

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.

Aftermath of AF 447 until BEA final report
 

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.

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.

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.

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.

Lack of minimum understanding: UAS root cause
 

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". :E

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. :mad: And to improve man machine interface.

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

SIM Experiences
 

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.

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

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.

@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 :oh: ).

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.

Man machine interface (UAS processing)
 

Hi,

mm43:

I agree fully with you. After 7+ months "doing some R&D :8 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.

:E

PS

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

@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 :ok:

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?

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. :D:D

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.

@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".;)

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.

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

"wonder why this explicit UAS warning isn't being done already."
 

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.

As HN39 has mentioned, the likelihood of ice crystals above FL300 and less than -40 deg C wasn't considered.

The following proposed amendment is the outcome of more recent UAS events.

http://oi42.tinypic.com/2yjvbc3.jpg

I still remain to be convinced by the man/machine interface explanation. We are running the danger of over-generalising from one specific example. Nothing points to a problem with the interface - rather it consistently points to a failure of crew performance. There was and still is a procedure for UAS which if followed clears the incident up quite effectively. Other crews have successfully dealt with the issue so why didn't this one? What was the difference that caused this crew to stall and crash their aircraft?
This is the issue which all attempts to blame the machine fail to address. Why this crew? What was so different about them that they couldn't follow the SOPs, that CRM was non-existant and that there was no clear chain of command? The interface is not the issue because other crews handled it successfully. Training and culture can also be added to the mix but it also and significantly comes down to the individual members of the crew and does not go beyond them. Certainly the aircraft and the controls can probably be re-designed so that this sort of incident would never happen again and I would favour this but I can't help suspecting that without better training someone will find another way to crash one of these aircraft.

Hi,

It is indeed always the same question we pose and she defies statistics
Have a incompetent pilot in a crew can happen
Have two incompetent pilots in a crew is rare
Have three incompetent pilots in a crew defies statistics

That's not what I said or meant. The Airbus requirement (ice crystals) in your diagram covers the atmospheric conditions of AF447 (FL350; SAT -38.8). I was thinking about obstructed static ports, blocked pitot drain holes combined or not with blocked pitot 'intake', in various phases of flight. Sorry if that wasn't stated explicitly.

CONF's experience sounds like he ended up in Direct Law or Abnormal Attitude, as Alternate in any mode should still have autotrim enabled.

@mm43,

Hi,

And thanks for your continued comments :)

I can certainly see some merit to an automated "UAS handling", and I firmly believe that the "startle factor" is indeed an issue to some extent, in any man/machine monitoring interface (as described in Dr Bainbridge's paper).

My specific concern is that if such automated UAS handling is introduced, then the (a) recognition of UAS and (b) subsequent actions, have got to be correct. :) I just don't know whether the level of confidence in the automation is there yet (and the pilot/passenger confidence in the automation!), to make this option (i.e. an automated UAS response) better than leaving the human in the loop (i.e. a guided UAS response / warning). I'm very happy to read the views of the experts in this area.

The option I am most concerned about, is leaving the situation as it is, due to the inadequate UAS recognition and handling by the other crews (in addition to AF447) as highlighted in the BEA Interim Report 2. While this was only one hole in the AF447 "swiss cheese", if that hole can be closed (or at least made smaller), in a (relatively) low cost / low risk way, then surely we reduce the risk of all the holes lining-up again.

@Old Carthusian,

Hi,

My point is that there is not just one example. If that was the case, I wouldn't be spending any time commenting on this point. :) The BEA Interim Report 2 makes it clear (at least to me) that there is a much larger problem with UAS recognition & handling, which was the start of the sequence of events leading to the crash.

To use your words: I "remain to be convinced" that, had the AF447 crew truly realised that the "lost speeds" (to quote the PNF) were actually expected due to a temporary UAS, would any of the subsequent events leading to the crash have happened? Reduce the "startle factor", reduce the crew's concern that this is an unusual problem, remind them to turn off the FD etc. - does the PF then follow whatever (unfortunately unknown) cues he did, which caused the "zoom climb"? Perhaps not.

I'm not trying to convince you that I'm "correct", but over some decades working with diagnosing complex systems, I have seen many many times, that having an incorrect mental model of what is happening at the beginning of a problem drastically reduces the liklihood of correct handling (especially quick & efficient handling), as that problem continues. It's from that experience, that I see similarities with the sequence of events on AF447.

I politely suggest that if several crew's behaviour was wrong (which is a documented fact), then by definition, the "interface" isn't well-designed. Or there are many crews who are sub-standard. Which one is easier to fix?

If by "successfully" you mean "without crashing", then yes. :) But as I've said before, I do not accept that as a good standard of measurement. Several other crews did not recognise & handle UAS correctly. Are you really OK with that, as long as they don't crash on that specific time they mis-handle it? I'm not. I see this as a larger problem which needs to be understood & fixed, so that crews do not (for example) follow incorrect FD commands, during UAS events.

See above - it's not just this crew who failed to recognise & follow the UAS procedure. I'm not trying to "blame" the machine - this is undoubtedly a "swiss cheese" situation with many holes. This is just one of the holes, but it's one where improvements (e.g. a specific warning / message is given), seems achievable.

I certainly agree that there were other problems like CRM (more holes in the swiss cheese). I'm just saying that, from everything I've read, UAS recognition & handling is one hole in that cheese, and if any of the holes had been closed, then the accident wouldn't have happened.

See above. I politely disagree that it's possible to be so definite.

Agreed, although these are difficult & long-term issues. That's not to say that airlines shouldn't try to improve these, but being pragmatic, I would rather have a partitial improvement (e.g. better UAS warnings, and perhaps assisted UAS handling) in the shorter-term, while waiting for longer-term improvements in training & CRM etc., than not have any improvement in the shorter-term, while waiting for longer-term improvements.

On this point I politely disagree, as I explain above. I'm happy to see if future posts change my mind, but I don't know how it is possible to be so definite that this is a crew-only problem (by which I interpret you as saying an AF447 crew-only problem).

If it was Direct Law the USE MAN PITCH TRIM PFD MSG would have show up ...

Inadequate, wrong, mis-handle, in-correct. What in report No. 2 do you see that warrants those terms?

Hello Diagnostic;

Enjoying reading your contributions, thank you. If I may offer a thought and a comment on the points of discussion between you and Old Carthusian...

On an increase in automated responses, I can understand the logic of such an argument (the BUSS relies upon this logic), but what concerns me from a pilot's p.o.v. is long-term reduced situational awareness and the need for in-depth understanding of high-altitude, high-Mach No. swept-wing flight, (old fashioned "airmanship", I guess) because it is still humans who are doing the piloting.

I offer this view out of a concern for what remains inexplicable, and that is the instant decision to pitch a transport aircraft up at such high pitch-rates (increasing 'g'-loading to 1.55g) to such high pitch attitudes and keep the aircraft there.

I would be interested in either data or an argument that this indicates an interface problem, for, as you are, I am open to any information that shows that normal training and SOPs for this event are inadequate in some circumstances and because of obscurity are best left to automated responses.

As has been observed throughout the thread by those who fly these aircraft, such pitch attitudes at cruise altitudes are simply never intentionally achieved for the very reasons loss of control occurred.

In re your observation, "Several other crews did not recognise & handle UAS correctly.", I don't recall specifically where there were untoward outcomes due recognition and handling issues with other crews in other events but again am open to new information. There are no characterizations one way or the other in IR2 [Interim Report 2], Appendix 7 regarding crew responses one way or another and from what I've read I don't see any descriptions of difficulties experienced by other crews in the body of IR2. There were a few events such as the Air Caraibes, (report here, in French), the Northwest and the TAM events but to my recollection, (and I have been wrong on more than a few things before!), the UAS events haven't been problematic as most crews "did nothing" and the airspeed returned within a minute or less.

The argument here isn't at the stage of deciding whether more automation, the same level of automation or reduced interventions are needed. This is very much a continuing dialogue between pilots and engineers! The ability to "look through" the automation and decide for oneself what the airplane is doing, what it needs and why, is being lost because it is being supplemented and when supplements occur, practice and therefore skill, then thinking and knowing atrophy

I have had kindly pointed out to me a recent conference at the Royal Aeronautical Society entitled, "The Aircraft Commander in the 21rst Century". There is an excellent videoed presentation from this conference by Captain Scott Martin, (Gulfstream Experimental Test Pilot) on the very topic at hand. From the site:

As effective PF during our experiments, I was relying on the TRE to watch ECAM as my concentration was 100% on the PFD, SS and trim wheel. I'd be impressed if you could read ECAM while trying to maintain what they were doing.

HazelNuts39 wrote:

Why? Surely aircraft have been flying at such altitudes for quite some time now. What has changed?

Good ... USE MAN PITCH TRIM PFD MSG

rgbrock1;
Perhaps I can help. In climbing through FL200 or so (IIRC), in a B767-200, captain flying, I noticed my CAS gradually decreasing - no EICAS messages, no Master Cautions; what would have been a normal 320kt climb speed, (again IIRC), had decreased gradually to around 250kts - the rate of climb had not increased and I glanced over to the captain's ASI and it read 320kts or so. It was very subtle. We took the reading off the standby ASI and it agreed with the right-side ASI, so we used that ASI. About that time the amber "Rudder ratio" EICAS caution annunciated and an aileron lockout (again, IIRC) annunciated. As the left-side ASI approached 350kts we expected an overspeed warning but it did not occur. We continued the climb and leveled off at flight plan altitude with the right side reading equal to the standby and the left-side pegged on the stop. The right-side autopilot engaged and we continued to destination. On approach, as the air warmed the left-side ASI indication returned to normal. We wrote it up. This was around 1985/86. I never saw it again.

I've thought of that often - what if we had lost all speed indications? There were no pitch-power tables at the time but we could have used the FOM Long-range cruise numbers to keep us safe and monitored pitch, comparing it with past experience. We'd have probably continued; it was night, winter conditions at departure - destination was daylight and a bit warmer. I doubt if ours was the only such experience.

The difficulty with automation is GIGO - if the info isn't available to the flight crew, what's the automation using? The notion of "historical figures" has been broached, (as in, what's the airplane been doing over the past ten minutes") but that's what pilots do anyway, and supplementing such awareness gradually destroys such awareness.

A few have hit upon a very good point - if we fix this, then what will be the next cause? Or do we teach airmanship sufficiently to keep the aircraft safe? While cadet programs teach technical competence, do they teach one how to be "a pilot"?

Well, in which case I'd say the sim configuration must have been slightly off - would you have a chance to re-run your experiment in the not too distant future? Alas mine was very much a one-off.

I think back when CONF first posted he stated that his sim was a dual ADR fail to trigger UAS. That would leave one ADR in and AOA would trigger abnormal attitude law, which would stop autotrim. Apparently without putting up the PFD message which also ties in with what CONF saw [yep I agree, sounds stupid, think it should be fixed, but not relevant to 447].

I don't think the SIM would replicate the fall in measured airspeed at the pitots at high AOA and fail all ADRs as a result.

The high altitude / ice particle scenario is a relatively recent … What has changed?
 

Some thoughts;-

• Global warming is put aside, but not eliminated (see refs).
• Engine design. Problems were reported with aircraft engines as early as 1989/90. Serious research and regulatory activities started in the mid – late 90s after some aircraft suffered multiple engine rollbacks.
  Modern engines use very high efficiency aerodynamic components with close tolerance fittings. Whereas older designs could suffer some ice accretion without obvious problems, the new systems degrade rapidly. An analogy is with super-critical wing sections suffering from ‘bug splatter’.
  Even so, larger engines appear to manage ice crystal icing easier than smaller engines, but performance/degradation depends on individual designs – see centrifuge issues below. In addition, use of internal anti-icing heat adds to the possibility of melting some crystals providing the ‘glue’ (freezing water) for other crystals to stick together. With older/unheated engines the crystals tended to bounce off (possible origin of no airframe ice [accretion] below -40C).
• Changes in design and location of probes. TAT probes encountered problems in similar timescales as engines (also some reports of A310 / Concord pitot problems – flight test?).
  New pitot designs perhaps did not consider ice crystal capture/build up, or they enhanced the particle melting ‘glue’ aspects.
  Airframe aerodynamic efficiencies resulted in probe locations where there is more catchment of ice crystals. High curvature flow around the aircraft nose tends to centrifuge out the heavier water / crystal content, but smoother low curvature flow results in more lightweight ice crystals entering the tube; again specific design issues with probe, aircraft, and location.
• Avionics. Availability of modern colour radar may encourage crews to fly closer storm centres than previously. The older ‘cloud and clunk’ WXR gave a single boundary defined by skilful use of tilt/gain – stay out of this area and a bit more; new radars have several ‘automatic’ colours thus a choice of acceptability – keep out of the red, but yellow / green may be acceptable. This false reasoning has been reinforced with sales talk of ‘cleaver’ electronic features; pilots overlook this and also that most aircraft WXR do not detect ice. Ice crystal conditions at best might only show as a green zone.
  Thus the exposure to ice crystals - frequency of encountering the conditions and the duration in the conditions has increased.
• Changes in operational complexity – airspace limits, e.g. does RNP / RVSM (or crew’s perception of safety limits ) increase the probability of encountering areas of Cbs. Crew’s awareness of the icing threats depends on training and incidents reported. Modern airframes appear to tolerate more icing encounters – better design / efficient systems, but this may not apply universally to all aircraft or all aspects of a single type.
  The industry appears to be less aware of icing risks; have we forgotten many of the rules of thumb – don’t fly in/under the anvil of Cbs.

Complacency?

http://icingalliance.org/meetings/RI...ersion_nss.pdf

IASCC - International Air Safety & Climate Change conference - presentations, workshop 1, day 2, Eric Duvivier, EASA - "High Altitude Icing Environment"

http://www.ukfsc.co.uk/files/Safety%...Oct%202009.pdf

Hi PJ2,

Thanks very much for your comments all through these threads, and for the opportunity to discuss. I've tried to minimise the quotes, while still (hopefully) keeping the context - if you feel this has distorted things, then sorry & please correct me.

I do understand this p.o.v. and as I said, I'm not yet convinced about totally automated responses, but at least an explicit UAS warning seems (with hindsight) a clear improvement, doesn't it?

After all, if there is an engine fire, the systems (I don't know if it's the FADEC or others) detect the excessive temperature and alert you, as the pilot, to that specific problem. (I flew several of these in a B737 simulator, some years ago - that bell gets the heart racing :) ). The system does not just say "Hey, something is wrong - I know what the problem is, but you have to work it out from some gauges on the panel - and hurry up!". Why give the crew a specific fire warning (or low fuel warning, or any of the other warnings where the system highlights the specific issue), and not give the crew a specific UAS warning?

In your B767 example a few posts ago, is it sensible (and optimal) to make the crew "jump through the mental hoops" to try to work backwards from the "Rudder ratio" EICAS caution, to the underlying UAS event?

Completely agreed - it's currently inexplicable, due to the lack of justification/explanation voiced by the PF. As I think several here have already said, the human factors part of the final report will make interesting reading, but it may be more like "educated guesswork" in this area, than any of us would want.

However, if the PF had correctly announced and followed the UAS procedure, then they would both have been focussed on the 5 degree pitch target instead, wouldn't they - at least possibly?

As I see it, BEA Interim Report 2 page 51 onwards provide evidence for either:

a) too difficult to recognise UAS via the existing interface, or/and
b) insufficient training to recognise UAS via the existing interface.

IMHO these are related - the less obvious the interface to report a UAS (and to also encourage that the UAS procedure should be followed) to the crew, the more training, skill, concentration, ongoing crew practice will be needed. Or do you have a different view?

More details below...

Agreed that I've seen nothing regarding untoward outcomes in that BEA report, but IMHO that's not what the metric being measured should be.

That is my understanding too (apart from duration - BEA mention up to 3min 20sec of continuous invalid speeds). But consider what we learn from the BEA report about the various crews lack of following UAS procedures, and what that means about the chances of a potentially different outcome next time.

As I understand it, one of the reasons for crew procedures is precisely to prevent different outcomes depending on crew, time of day, visibility, and all the other variables which a crew has to deal with. Once we see lack of adherance to procedures, don't we get closer to the chances of "bad things" happening? That has been my experience, both with flying and with other highly-controlled situations.

Of the 13 UAS events where the BEA had sufficient detail to know what the crew did / did not do:

"Four crews did not identify an unreliable airspeed"

and

"For the cases studied [which I interpret as being all 13 cases] the recording of the flight parameters and the crew testimony do not suggest application of the memory items in the unreliable airspeed procedure:
* The reappearance of the flight directors suggests that there were no disconnection actions on the FCU;
* The duration of the engagement of the Thrust Lock function indicates that there was no rapid autothrust disconnection actions then manual adjustment on the thrust to the recommended thrust;
* There was no search for display of an attitude of 5°."

So as I read it, all 13 crews "got it wrong", to a greater or lesser extent, with a third of them (4 out of 13) failing to do any UAS procedure, and all 13 failing to do the memory items. Isn't that just a timebomb waiting for a crew getting things badly wrong in the future, when they are presented with an unrecognised UAS at the "wrong time" (sleepy, poor CRM, "startle factor" etc.)? If they get distracted trying to diagnose a non-existant instrument fault (which is really just temporary UAS), couldn't that potentially lead to another AF447-like event? IMHO, based on reading other accident reports where distraction was a factor - yes.

I understand that concern, and I would much much prefer ATPL pilots to be better trained, better paid and kept highly-skilled.

However, are you saying that aircraft system designers shouldn't help flight crew by giving an explicit warning for UAS, even though the systems know that there is "just" a UAS event (which has a procedure to follow) and not some other instrumentation fault (which needs to be investigated, diagnosed, coped with, etc.)?

I have a view about how an automated response might be considered, in a way that still keeps the crew "in the loop", but I'd like to initially focus on giving explicit UAS warnings (to try to drive the following of UAS procedures).

Many thanks - I look forward to viewing that when I'm back with a normal internet connection. :)

@Hamburt Spinkleman,

Hi,

I believe I have answered this during my reply above to PJ2 - the short answer is page 51 onwards in that report. However if you disagree, I'm happy to again quote specific examples from the report, to explain my choice of words.

Or do you see this part of the BEA report as showing correct UAS procedures were followed in all 13 cases? Or were completely followed in even one case?

Diagnostic
I am afraid we are still faced with the question of why? It does still come down to the individual crew. It is something that I learned flying replica biplanes (note that I have never flown big transport aircraft but I feel what I learned has some relevance). - know your machine. Know your drills. There is no escape from this. The crews who didn't initially recognise UAS were still able to successfully deal with the problem. One crew (AF447) wasn't and followed a totally inappropriate behaviour pattern. Evidence indicates that the safeguards expected in a transport aircraft were not utilised but were for some reason ignored. This is, I am afraid, a crew issue - not a machine issue. It also relates to this particular crew not the others. I would suggest that reading some of the Korean Airlines accident reports would be productive. They are different accidents but the cultural parallels and CRM failures are instructive and one can see a bearing on this accident. We have to be very careful in trying to find a 'hard' solution when the cause may well lie in the 'soft' factors.

@Old Carthusian,

Hi,

As with my reply to PJ2 I've tried to reduce the quotes a little, but if you think I've destroyed the context, then I'm sorry and please point out what's wrong.

Why what specifically? I think you're asking "why didn't the AF447 crew follow the UAS procedure", but I'm not sure if you're asking a bigger "why"? Sorry if I'm missing something obvious. I'll assume you're referring to the UAS procedure question here, rather than "why the zoom climb" etc.

Do you mean it's always an individual crew decision, or it was only a problem with the AF447 crew, or ...? Sorry, again, I can't grasp your specific meaning. :(

I completely agree that this should be the objective. However, are we expecting too much of pilots, to be both pilots and flight engineers? With aircraft of the complexity of the A330, the "know your machine" mantra, while it remains the objective, is impossible (realistically) with the same depth as you know your biplanes. The more complex the machine, the more ways it can go wrong, or at least, behave "unexpectedly". For example, just remember how many pilots here were unaware of the stall warning being disabled under 60 knots IAS.

As I said to PJ2, I can't agree with that as being an acceptable result, meaning we should just blame the AF447 crew and stop looking deeper. From reading that BEA report, it looks to me that controlled flight sometimes continued in spite of and not because of what some of the 13 crews did (e.g. premature AP reconnection, with incorrect airspeed being used). I don't class that as "successfully" dealing with the problem by any measure - expect that they didn't crash (see my previous comments on that).

I agree about their behaviour, but they are not the only crew to fail to identify the UAS.

I politely disagree that it is so clear-cut. If you make the machine complex enough, and add in human imperfections, then you could get a man/machine interface which will be OK for some people, some of the time, and fail to "get through to" different people or at different times. IMHO that would be, in part, a machine (design) issue.

To suggest that this is (only) a crew issue implies that you believe the machine is perfect. And yet a UAS situation was reportedly not identified at all by 4 out of 13 other crews. Don't you think that might be pointing to it being too difficult for typical crews to reliably recognise a UAS, using the current recognition method being taught?

I don't understand exactly what "it" refers to in that sentance, so I can't comment.

I am not trying to find a "hard" (i.e. systems) solution - sorry if you thought that I was, as I can't have been clear enough. The "soft" (human) factors clearly played a large part when looking at the whole crash sequence.

I'm suggesting that it is possible to mitigate some inevitable "soft" (i.e. human) factors (e.g. no human is perfect; we all have circadian rhythms & limited attention spans etc. etc.) by improving some systems behaviours, to better support the pilots when things go wrong (i.e. tell them clearly about a UAS event - don't leave them to work it out from hints). That is in addition, of course, to extra training, more hand-flying for the crews etc. etc.