PPRuNe Forums - View Single Post - AF447 wreckage found
View Single Post
Old 27th Aug 2011, 20:05
  #3334 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 76
Posts: 2,484
Received 0 Likes on 0 Posts
Originally Posted by TJHarwood @ Post # 3183
The problem is far far wider than Toulouse......
Yes, indeed the problem of the handling of automation in the industry is far broader "than Toulouse" and the evidence for this is widely available and has been since the mid-1980's. The problem stems from an infatuation with the huge potential cost-savings, with added flight-safety benefits. On the whole the history of automation's introduction and acceptance by the industry, particularly those who use it on a daily basis, has been successful and the accident record supports this view as does the wide acceptance of those who initially transitioned through the Lockheed L1011, B767/757 to the B777 & A300/A310 to the A320/A340 and A330. The numbers tell us that the initiative is successful by both cost and safety standards.

It may initially seem obvious but an "automation accident" could be understood as a "cognitive" accident as much as it may be understood as a technical accident. This is in contrast with past causes which usually involved weather, navigation error, mid-air collision or CFIT. In the end it's all "cognitive" but the character of engagement with automation where "something is done for oneself by a system in which many though not all decisions governing outcomes are resident within the system and do not emerge from oneself" is materially different than the "bread-and-butter cable-and-pulley pilot engagement with/without hydraulic support" traditional approach to solving the problems of controlled flight.

The material difference is, automation intends to solve "the problems of flight", (this description requires a lot of unpacking), which were ordinarily understood intuitively from long experience and a few rushes of adrenaline. Sometimes a pilot is solving the problems of automation which in turn are solving the problems of flight but for the most part, because of the long history of very robust research and development in the design and implementation of "automation" per se, the two complement one another -again, the record clearly demonstrates this - automation has come to terms with both cost priorities and safety principles.

But there are exceptions, some unforeseen, a few bad design decisions and as always, the human factor...that category of events which occur because people are people and sometimes subvert or otherwise use in the most imaginative but unanticipated ways, systems which have the best and most honourable design foundations and technical intentions.

I wouldn't think the term "ergonomics" would be helpful in delineating the problem for the purposes of study, but how the question(s) is/are enframed always determines the nature and character of the answer so it is important to understand how to ask the question. (That's just another way of saying, "eastern rats perform better for eastern psychologists", or, "to a two-year old with a hammer, everything is a nail").

Against this unfolding automation trend from the early 80's on, AW&ST ran a series of very well conceived and written articles on automation in 1995. (I've made PDFs of those articles but don't have a place to post them yet.) Essentially, the articles are saying the same thing as we are today, which begs the question concerning "more automation?"

I am hearing from good friends in the industry that an automatic response to TCAS events is being considered. The reason is, there are numerous incorrect responses by flight crews to TCAS RA events. Designers and the industry are reaching for more automation.

Here's a clear example: In running a FOQA Program, we designed 28 specific events which enumerated and otherwise captured, very specifically and in detail, all TCAS events and crew responses. We were motivated to do this because both Lufthansa and Air France had done this years earlier, (1994, IIRC), and they found what we were finding in our budding Program.

The solution is comprehension and training, not more automation, but that argument seems to have been superseded by the decision not to use these 28 events to determine what and why TCAS responses weren't always correct, in favour of an automated response. I have not studied the Uberlingen accident sufficiently to know whether an automated response would have avoided the collision or not, but that is not the issue: the issue is a decision to reduce margins of error because it is now possible to do that while demonstrating that automation can produce "acceptable levels of safety".

And so this is another aspect of automation which is quite different than the one "we old guys who flew steam", faced. We now have young people, (20's, 30's) who have never known anything but glass, FMCs and varying levels of automation. For many, their first jobs were as likely to be on automated aircraft as on a Beaver flying hunters, fishers, oil-men and arctic workers into strips which demand a very high situational awareness, physical and mental sharpness and for which automation remains an infant.

The question of automation has always been enframed in traditional ways when the real problem is how the pilot engages, or is engaged by, computer solutions to the ancient, unchanging problems of aviation. For example, the article written by someone who claimed to be an experienced A330 captain and who said that flying the A330 was just the same as playing a video game may have described one tiny aspect of the character of this interaction but missed entirely, the fact that if one's competence with this or that video game is questionable it is wholly inconsequential while flying an aircraft, however done, is not. Others have said this, but the act of digital flight is a twice-removed cognitive step from handling the airplane.

The best example is one we all know about...the analogue wrist watch that always tells us "how much", and the digital equivalent which requires a higher level of cognitive engagement to first calculate, then construct a model of, then interpret one's own situation on top of such model, before one can determine, "how much". What is the meaning of "clockwise", or "half-past three" when one is interpreting a rolling series of numbers?

These are not insurmountable but as others have said very well here, such changes to digital flight do require different training methods, practise and cognitive responses.

People respond best to images, most strongly when such images "tell a story", and not to single digits from which "how much" must be intellectualized and then re-expressed as an image which then conveys "the story" which is usually a specific metric as compared against the whole, all in one image. The airspeed and altitude tapes do this to a certain extent already, but the TCAS response described earlier, seems to have more than its share of incorrect responses primarily because of the way the RA information is presented on the PFD.

TJ Harwood, this is all off the top of my head and is intended as thoughts against which others may push and change, dismiss or add to. As a pilot of these aircraft for 15 years, my approach was to "look through" all the automation to see what the airplane was doing and that meant airspeed, altitude, rate of climb/descent, heading/track and engine thrust, and if all of these were what were needed for the job immediately at hand, and they were trending (for the next ten miles or so) in the right direction (and "no changes" is a trend), then I let the automation do its work.

I think that is what was meant when someone else here said that automation was an assistant to the pilot; it is most certainly not a third or fourth pilot but as that dangerous mentality gets even more established, especially with managements and pilots who have flown nothing but automated aircraft, the way back becomes very difficult because fear builds upon fear and soon one is afraid to fly. Seen it, and I doubt very much whether this was ever the original intent of those who contemplated using microprocessors to solve the problems of flight.

I have already referenced some whom I believe have some important things to say. The interesting thing is, we are not hearing from many pilots, and I think that is because they're getting on with it and flying their airplanes, treating it just as is described above...For most pilots, automation is transparent to the task at hand, and instead we have the age-old aviation problems remain, which the major innovations of SOPs, CRM, Threat-and-error management and thorough training, as well as EGPWS, TCAS, ADS-B/CPDLC, SatNav are all intended to resolve and for the most part, do.

I look forward to reading others' views.
PJ2 is offline