PPRuNe Forums - View Single Post - AF 447 Thread No. 7
View Single Post
Old 6th Apr 2012, 06:52
  #1285 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 76
Posts: 2,484
Received 0 Likes on 0 Posts
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.

Quote:
Originally Posted by PJ2
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 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?

Put in this way, possibly. It took until the industry had the microprocessor power to indicate a straightforward engine flameout/failure. Up until glass, the most significant failure on an aircraft and one which we practice every simulator session had no warnings - one just knows the failure by the noise if catastrophic, by the behaviour of the airplane and by examining the engine indications for fuel flow, oil pressure/temperature, N1/N2/N3 rotation, high vibs and so on.

These are good arguments for solid indications and computerized drills which monitor crew actions. The Airbus has ECAM drills for engine failures, fires and severe damage. For the longest time, an engine failure was an aircraft performance system-based failure of which, it had been taken for granted, a crew would recognize and handle using the established, trained, checked memorized, QRH or ECAM/EICAS procedures as well as standard CRM communications techniques.

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.

They did not respond to the ECAM, nor to the stall warning so would a voice/aural/visual or combination of all three? The question is open and certainly discussable.

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?

In a word, yes. In fact the failure confirmed our initial assessment that we had an airspeed indication problem because other systems were responding. Fortunately it was only the one pitot-static system and we knew the architecture of the standby system, (and so trusted it...I'm not sure I'd trust an ISIS in the same way.)

Quote:
Originally Posted by PJ2
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.

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?

Or focussed on maintaining what are obviously successful pitch and thrust values until they take a moment to slow down and gather thoughts. Nothing in transport flying requires immediate action except the rejected takeoff, a TCAS, GPWS or Stall warning - taking the time to sort things out permits the mind to "re-discipline and re-focus" itself from "cruise flight and the next waypoint" to an abnormal or emergency procedure, then the PF calls it and they get on with the drill or checklist. It is absolutely standard cockpit discipline, period.

Quote:
Originally Posted by PJ2
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 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?

No, I don't have a different view and I see training as the answer to many of these issues which crop up. I was dismayed when I watched recurrent PPCs drop to 3hrs, and equally dismayed when they went to 18 month periods instead of 12 month periods. I don't know what the standard is today, but these are corporate bean counting decisions made by non-flyers and fighting them in today's environment is very challenging, (as in "show us where this is a problem).

More details below...

Quote:
Originally Posted by PJ2
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.

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.

I concur but only in part. Sometimes nothing happening when an abnormal occurs means something. It is part of this discussion which, as with other significant issues, this industry is having. The other fascinating discussions we know about...wither automation? Wither ultra-long haul and fatigue issues? Wither instrumentation and presentations? etc.

Quote:
Originally Posted by PJ2
[...] 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.

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.

Using your comments, I will re-read IR2's relevant sections. I have to admit that I don't recall finding these comments, but quite frankly every time I read these three reports I find something new. I'd like to think it isn't me but...

Quote:
Originally Posted by PJ2
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 understand that concern, and I would much much prefer ATPL pilots to be better trained, better paid and kept highly-skilled.

Pay well and good people will come. Infatuation with technology, and here with "automation" is almost always based upon the wrong reasons - money, (as in one less crew member) rather than utility, safety and reliability. Computers remove people from direct contact with things because they model the world so well. In aviation, that model is pretty good and serves us well providing we can ignore it without result. Either in the cockpit or the boardroom, once direct contact "with the environment" is lost, the potential for uninformed tactical decisions (mistakes) increases although one usually finds that the priority of financial decisions may be enhanced.

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

No, I'm not saying that but not because such indications aren't in some way required, but because it has been determined by the industry that engine failures "don't need explicit warnings" (because they broadcast failure in other ways). I think there is a strong argument for some kind of indicating system which sorts out for the pilot the variations of failure which are possible - right now they are in the FOM, (About thread five or so someone posted a very good page from an A300 FOM showing the variation of effects of blocked pitot, blocked pitot drain hole and variations on blocked static ports etc. We know the airspeed acts as an altimeter if the pitot tube is blocked but the static hole is open - A clear way of assessing such a problem through CRT graphics and commands would be a better option than just warning of a "UAS" in cruise. Also, it has been suggested to find better ways to derive airspeed from GPS for such failures.

As with the AoA guage, none of this is of any greater safety if it isn't trained and checked and for that it also has to be "STC'd" and certified by the FAA and (possibly?) regulated?

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

I have always loved automation because it is indeed a tremendous innovation which makes aviation much safer. But it is not the third pilot, unless one treats automation in the same way one uses CRM with one's crew members. One ought to be able to "look through" what the autoflight system is doing and disconnect and hand-fly if one doesnt' like it. But I had crew members who would refuse to hand-fly and weren't confident in disconnecting the autothrust. I thought it was a sad thing to admit.

Quote:
Originally Posted by PJ2
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.

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

It is a pleasure engaging in this kind of discussion. ;-)
PJ2 is offline