mm43

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.

Old Carthusian

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.

jcjeant

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

HazelNuts39

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.

DozyWannabe

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

Diagnostic

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

CONF iture

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

Hamburt Spinkleman

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

PJ2

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:

DozyWannabe

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.

rgbrock1

HazelNuts39 wrote:

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

CONF iture

Good ... USE MAN PITCH TRIM PFD MSG

PJ2

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"?

DozyWannabe

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.

infrequentflyer789

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.

safetypee

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

Diagnostic

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.

Diagnostic

@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?

Old Carthusian

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.

Diagnostic

@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.