PPRuNe Forums - View Single Post - AF 447 report out
View Single Post
Old 6th Jul 2012, 01:01
  #56 (permalink)  
Irish Steve
 
Join Date: Mar 1999
Location: Ashbourne Co Meath Ireland
Age: 73
Posts: 470
Likes: 0
Received 0 Likes on 0 Posts
OK, the BEA are saying that the crew on the day were part of the problem.

Maybe, or maybe the "system" was the real culprit, and a group that is never to be seen when things go pearshaped are more culpable.

How many long haul pilots on the Airbus or for that matter any other long haul aircraft have had any experience of hand flying at cruise altitude? Not many, and one of the reasons for that is the bean counters, who get upset that pilots flying the aircraft rather than the automation may cost more because it's not operating as efficiently.

So, most pilots have not hand flown in coffin corner during normal operations. Have you ever done that in the sim? Perhaps not, and that may be because cost benefit analysis done by (guess who) the beancounters, states that accidents such as AF447 are so rare, it's not cost effective to train to such high levels of skill. Really? I wonder if the bean counters ever travel by air themselves? One has to wonder. If I then ask how many people have had to deal with failures in the sim when hand flying at high level, it's probably an even smaller number.

How many of those beancounters and high level training people are actually at the airport comforting grieving relatives when the result of some of their policies is made painfully apparent? Not many, they are always well protected from the sharp end of such involvement.

Now let's go down another road. How many people have used devices such as a DVD recorder, and thought when using it, why did the programmers do the program in this order, it's crazy, the feature I use least is the first in the menu, and the one I need most is the last, and if you look into it, the reason is that the first item is probably the system set up, and nothing else will work if you haven't done that, and then they move on to other things, and the timer programming comes often last, probably because it's the most complex area, that needs all the others , but it's the routine that the user will use most often, so in a well designed system, it should be first on the list, and the lesser used items should be further down the list.

Same scenario is sometimes true in avionics, and in things like ECAM alerts, the order they are dealt with is sometimes a lot less than intuitive, and certainly not the order than a human flight engineer would bring then to the attention of the PF or PM, having taken them all into consideration and evaluated what they all mean. Computers are wonderful, but they have limits, one of which is that they only make decisions one at a time, and only in the order of programming, which in a lot of cases takes no notice or attention to the phase of flight or the state of other systems that may or may not have been evaluated in this iteration. Some of the ECAM type alerts that are thrown at an already busy crew are not critical to the underlying main and most important criterion. Aviate, Navigate, Communicate.

It is significant to me that in 3 incidents in recent time, the system warnings and alerts have in some respects got in the way rather than helping. The 380 that had the uncontained engine failure, they were a very long time working through all the check list issues before they could eventually put the thing back on the ground.

"Sully" Sullenberger commented that when he put the 320 into the Hudson, there "wasn't time to go through all the checklists", and that resulted in a vent being open below the "water line"..

The AF incident was made more difficult to deal with by misleading guidance on the instruments.

Then there's the whole issue of the stall, and awareness of it, both from the crew aspect, AND the aircraft, which was able to stall because the automation had already thrown in the towel and degraded it's operating mode, without making that very important fact known in no uncertain manner to the crew. Do you describe that as a design fault or a design feature.

Over 40 years, I've programmed many computers, and the "trick" to successful programming is to make sure that the right response comes out of the system even if some of the inputs are wrong. Getting the system, whatever it's meant to be doing, to reject input that's wrong, is more important than getting it to validate and work with the right data, and all too often, it's the manner in which the system deals with the errors that makes the difference between staying in the air or crashing.

There are other issues, like the 330 not being stable in pitch, which because it is flown by automation is acceptable to the people that certify it. Maybe, until as already mentioned, the automation throws in the towel. If as a result the crew is given an aircraft that's degraded, and also not stable, that's not exactly giving them too much assistance.

I'm not going to go down the road of the crew training and experience issues, I'm probably ruffling enough feathers and sensitive egos already, and to go there, and bring up issues like self funded type ratings, cruise pilots, and training systems that discourage people from using spare sim slots to improve their knowledge will only make the issues even more contentious.

Over 10 years ago, the EU funded a research project that was supposed to aid and improve the quality and capability of flight deck automation, by improving the evaluation and analysis capabilities of the systems. It seems that the changes that should have come out of that project are being stalled somewhere, as I've seen very little real change in the way that most of the systems provided automatically are operating.

I've seen this accident described in other places as Airbus' Titanic, and in many respects, it is, and how both Airbus and the industry responds to it will be very significant.

One thing is clear, for a vast number of reasons, many issues that have been raised in respect of training, experience, certification and design of flight deck systems are all going to have to be looked at in a very different light as a result of the findings of this report, the implications of this accident are as far reaching as Tenerife and Kegworth in terms of the issues raised and their consequences.

I just hope that all the people implicated are really listening.

In a strictly legalistic manner, yes, the crew of 447 on the day made mistakes that were contributory to the outcome. As to wether those mistakes were "pilot error" is very much a question that needs to be discussed in a lot more detail and over a wider group than even the inquiry team, and with wider issues than just the operation of AF447 in view. It seems to me that the 447 crew were as much victims as the rest of the unfortunate people that were on board the aircraft.

I am not sure that the BEA have succeeded in fully identifying the wider and larger issues that led to this event having the outcome that it did, or more specifically, I am not sure they have given enough emphasis to the underlying issues that are clearly implied in their findings. That may be because the media is taking soundbites, and maybe because of the manner in which their report has been presented. Hopefully, when the specific and detailed findings are analysed in depth, there will be changes at all levels of the industry,

I can only hope.

Last edited by Irish Steve; 6th Jul 2012 at 01:12.
Irish Steve is offline