AF 447 Thread No. 7

[Diagnostic]

@PJ2,

Thanks for your comments. I note you're taking a break from this, as I will also be doing. I've learned new information from some people, including you, over the past few days, thanks.

Originally Posted by PJ2

Not to re-argue the matter, but we know that none of these crew actions were done with AF447 and for this reason (which I have elaborated upon in earlier posts), I concur with O.C., that this is primarily a performance/crew accident. There certainly are training-and-standards issues here as well, and there are airmanship, system knowledge and CRM issues. The HF Report will, (and should) be thick and deeply researched.

As I said (more than once) to O.C., I agree with that - the crew behaviour certainly appears to be the primary cause of this accident (which clearly implicates training etc.).

However, in BEA IR2 was evidence of inappropriate UAS recognition (and therefore incorrect subsequent procedure) by several crews, not just AF447. It therefore seemed sensible to consider what could be done to help crews via improvements in the man/machine interface, especially since I have seen parallels to such "hidden decisions" in large computer systems, and their adverse effects on quick & efficient troubleshooting by humans.

What I have read over the last few days is that such changes are seen as unnecessary by some people, so I'll withdraw from the thread for the time being, but with my personal opinion (as a GA pilot & engineer, and therefore acknowledging that I don't have the experience to know the consequences) still being that improvements here may be a "net win", and hence worth investigating further, at least.

As you said, the HF part of the report will make interesting reading!


@TTex600

Hi,

As with PJ2, your comments about the state of current training and what pilots are being measured on (and hence what training is being driven to produce), are very interesting - and worrying. Unfortunately I also see this management drive to "train to meet tick-boxes" instead of "train to meet actual requirements" being done outside of aviation.


@safetypee,

Hi,

Another "thanks" from me for those links. Much earlier in these threads, I saw mention of the Dr Bainbridge "Ironies of Automation" paper which I read at the time. I'll see how the papers / discussions in your recent links relate to her conclusions. Some of the descriptions in her paper really resonated with me, as being human behaviour which I've seen and/or experienced.


@RR_NDB,

Hi Mac,

Thanks again for your recent posts & analysis. It will be interesting to see if the BEA recommend manufacturers to re-visit the current situation about UAS warnings / recognition.

Originally Posted by RR_NDB

Airbus SAS (and others) are processing UAS just to the System. The System is not fed with garbage. The pilots need to "process" any garbage through scan and brain.

Indeed - that extra workload on the crew, to figure-out themselves (again) what has already been decided by the avionics, seems unnecessary & unhelpful.


@CONF iture,

Hi,

Originally Posted by CONF iture

When you read the memo, it does seem normal to have to deal with a continuous STALL warning without taking any necessary action ...

Thanks for highlighting this - very interesting. I hadn't recognised the correlation to my thoughts about the PF's treatment of the still warning (i.e. deliberately ignoring it), with this document saying that the crew could sometimes get a stall warning with, as you say, no instructions to respect it using SOP. It's a shame that the English version of IR3 pages 63 & 64 which mention this document, didn't translate it.

This leads onto the concern that, if they ignore a stall warning for long enough, then it may no longer still be an approach to stall warning, but may now be a we're stalled warning!

Again, it'll be interesting to see how (or if) the HF part of the final report believes this document may have factored into the crew's (especially the PF's) treatment of the stall warning.


@RetiredF4,

Hi franzl,

Thanks for your comments. I see that you've mentioned all the main points I had been thinking about (and some more), and already explained them to O.C. much better than I was doing!


@HazelNuts39,

Hi,

Originally Posted by HazelNuts39

Originally Posted by Diagnostic

"This is a UAS situation, all my pitot probe pressures are different so I have to disconnect the AP - recommend you fly pitch & power which for this alt is X/Y"

The trigger was that the system detected a sudden drop in one of the three airspeed values. The "all pitot probe pressures are different" occurred much later at 2:12:xx when the ADR DISAGREE message was generated.

Thanks for the correction. I thought I had previously mentioned the sudden drop of airspeed values in another reply, but it must have been in a draft that I deleted, as I can't see it now. In the above quote I was giving one (obviously amateur and anthropomorphized) example message text, but hadn't meant it to be intended as accurate for any one specific situation (hence why I mentioned "X/Y" instead of specific values). I should have been more careful to avoid misinterpretation.

Originally Posted by HazelNuts39

Considering the multitude of possible causes and flight conditions, IMHO the computers cannot reliably identify UAS, but must leave the diagnosis of the problem to intelligent humans.

But decisions are already being made by the avionics about when the air data is unreliable, to then trigger the AP to disconnect etc. I understand that these decisions may not be perfect, but given that they exist already, I'm just suggesting that it is worthwhile exposing the reason for the avionic's decision to the crew - instead of expecting crew to figure out the reason for AP disconnect etc. again, and and perhaps getting that analysis wrong (or at least getting distracted by trying to do it).

You bring up an interesting point - of those 2 effects caused by pitot blockage (airspeed discrepancies and rapid change of airspeed reading), I expect it's more difficult for humans to detect the rapid change of detected airspeed (unless they happen to be looking at the specific instrument at that moment) than to detect discrepancies, since immediately after a change, the (incorrect) speed may stabilise (as seems to have happened on AF447). I want to do some more reading and think about that.


@Old Carthusian,

Hi,

Originally Posted by Old Carthusian

Everything keeps on coming back to training, SOPs and CRM.

Yes! And I continue to acknowledge this, as I have done over the last few days.

I'm specifically looking deeper into an SOP issue (i.e. the SOP for UAS), but unfortunately (and despite further clarification from me) you keep raising a different part of the overall problem (training) without acknowledging any common ground regarding SOP. Indeed, yet again you've repeated that the outcome of a UAS is what is important, ignoring my point that the UAS recognition and procedure (or lack of it) followed by the crew, is also important.

You've also again asked for a "guarantee" from me, despite me pointing out how unreasonable that is. If I wanted to, I could also ask you to guarantee things about the opinions in some of your replies, which you couldn't do.

Therefore I don't see any value in further conversation if there is no mutual respect here, and I'll politely withdraw from further conversation with you for the moment. Thanks for your comments anyway.

[Added: Before someone reminds me, I know UAS is not an SOP, although the knowledge that the UAS Abnomal procedure exists, counts as being an SOP, IMHO. ]