Co-pilot Robert, after finally getting full control back from Co-pilot Bonin: "Damn it, we're going to crash... This can't be happening!"
Co-pilot Bonin, who had been pulling back & stalling the plane during the crisis: "But what's happening?"
Pretty much sums it up. I am thinking that perhaps Bonin had shellshock & may not have even realized he was holding the stick back. Perhaps the more experienced Robert didn't think to ask "are you pulling back the stick?" because that would be like asking "did you make sure the computer is plugged into the wall outlet?", i.e. it's so stupid & simple, that can't be "it".
There are a few things I could think that would be worth adding.
- Add a display that shows the current positions of both control sticks. Add an alarm when the two sticks are not within a certain margin of the each other, if both are engaged. Such as if one is full forward & the other is full back.
- Make clearer warnings about the implications of the "alternate law" mode. Such as a warning like "Stalling possible". Also maybe put an alarm in the pilot resting area that would relay when warnings are detected like stall or switching to alternate law.
- Delineate command better, e.g. Captain, Co-pilot #1, Co-pilot #2 so that who is in charge is clear.
> Add a display that shows the current positions of both control sticks
Yes! From the article: "As the plane approaches 10,000 feet, Robert tries to take back the controls, and pushes forward on the stick, but the plane is in "dual input" mode, and so the system averages his inputs with those of Bonin, who continues to pull back.
If this is true, it's insane. What does it mean to "average" the inputs of both pilots if one is full forward and the other one full back?? It should say "conflicting command; make up your mind".
The article alludes to the old system where the stick was just the one same stick for both pilots: no possible conflicts there.
Maybe this is a good thing if a more experienced pilot needs to 'hold the hand' of the other ofr some fine tuning manouvers, but when the commands are opposite from each other than it realy makes no sense that it decides to average them out and in doing so, basically respondes to none as desired (possibly having the operator use more force to get the desired response).
The analog stick seems much more reliable in this way, only one source of control of the aircraft, period.
The plane crashed because it burned all of its fuel in a holding pattern waiting to land in JFK. When the flight engineer noticed this, he was afraid to tell air traffic control, who he believed was "higher up" than he was (and he therefore had no right to question their decision). The result was 65 dead people.
There are several cases where a lower-ranking person has noticed something that the captain has not. And when they didn't do anything about it, people died.
Speculation regarding other contributing factors includes:
The flight engineer's apparent hesitation to challenge Van Zanten
further, possibly because Captain Van Zanten was not only senior in rank,
but also one of the most able and experienced pilots working for the airline.
As a consequence of the accident, sweeping changes were made to
international airline regulations and to aircraft... Hierarchical
relations among crew members were played down. More emphasis was
placed on team decision-making by mutual agreement.
Wouldn't the Air France 447 crash be an instance where a low ranking officer did not notice errors & was given too much control of the plane, resulting in the deaths of many people?
It sounds like both co-pilots were having mental blocks while operating together in the cockpit. With Bonin stalling the plane, while Robert is unable to figure out why the plane was not responding like he thinks it should & the insecurity of these events leads him to defer to the captain, who is not present.
I am not sure specifying a hierarchy would have helped so much in this case, but the example crashes given in this thread don't explicitly show that the hierarchical structure was the sole cause of the crashes, there were many contributing factors which lead up to both.
Your link doesn't say that there isn't a clear chain of command, it says that there should be a culture that allows professional disagreement or calling to attention. Just because the captain is declared top dog doesn't mean that protocol demands subordinates must remain quiet.
BTW, who is commanding the plane (by inputs) and who is commanding the crew are entirely separate questions. I think one of the serious issues that MUST be addressed here is the issue of conflicting commands to the plane.
1) Place all controls between the pilots so they can easily see what eachother is doing or
2) Place a selection switch and indicator that allows a pilot to unambiguously take control of the plane and disable the other input, or to keep them in linked mode where they move together and provide tactile feedback as to what the other input is doing.
Yes, the link doesn't say that, but research further and you'll find that the concept of a hierarchy is what CRM aims to eliminate. It's the First Officer's job to take the flight controls from the captain if the FO thinks the captain is doing something dangerous. Not to ask for permission, but to immediately do. This goes against the concept of a hierarchy, but is why they put two sets of controls up there.
What I don't get is why THE HELL are the two sticks averaged? What's the reasoning behind this? "Hey, one pilot thinks we should descend, the other we should climb, better maintain altitude without telling either one about it". Why?
It seems that it has been known since 1987 that pilots prefer coupled sticks:
In a 1987 evaluation of side stick controllers Summers et al (1987) found that under simulated ‘surprise’ hand overs pilots Cooper Harper rating of the schemes were (in descending order):
Coupled sides sticks with algebraically summed inputs (1.4),
Uncoupled side sticks with algebraically summed inputs and disconnect switch (final A320 implementation) (1.8),
Uncoupled with algebraically summed inputs and priority logic (original A320 implementation) (3.3), and
Uncoupled side sticks with with algebraically summed inputs (3.4).
So, Airbus chose to implement the "second best" option (using a disconnect switch). The same article speculates that even though several sound alerts might have been triggered - including a sound alerting of "Dual Input" -, the stress situation makes them insufficient:
[...] in the circumstances identified as triggering instinctive responses the value of such alerts is degraded due to the inevitable attentional tunnelling that operators experience in high stress situations.
Fascinating and crushingly disheartening. It is obvious that a coupled force feedback mechanism is the simplest human interface solution to showing what is happening between both sticks, and pilots prefer it. I would really LOVE to hear the thinking behind the fool that chose to produce an interface that allows for me to press "up" and you to press "down" and we each get fed the bogus result "up" or "down" while actually it has decided to process it as "asdfasdf".
> - Add a display that shows the current positions of both control sticks. Add an alarm when the two sticks are not within a certain margin of the each other, if both are engaged. Such as if one is full forward & the other is full back.
Even better: when you have two mechanical inputs to a single output channel, mechanically _link_ the two. If Pilot #1 moves the stick, pilot #2's stick should move. So that if there is a disagreement, they can physically observe it in their hands. Any fight over where to put the stick shouldn't be "averaged". It should be physically felt by both pilots so that they realize that there is a conflict and resolve it face to face.
It's similar to why SVN commit conflicts are so damn annoying. But they're designed to be: the only way to resolve a commit conflict is to walk over and meet your conflicter face to face and resolve. Can you imagine if SVN decided to "average the inputs"? What the fuck does that even mean? This entire plane sounds like a UI disaster (modal inputs, etc.)
- Add a display that shows the current positions of both control sticks. Add an alarm when the two sticks are not within a certain margin of the each other, if both are engaged. Such as if one is full forward & the other is full back.
This was my first thought as well. Confusion in one pilot was allowed to cause confusion in the second pilot, because he didn't realize that his partner was doing something unexpected and incorrect. If you make sure a pilot can always detect inconsistent reaction in a co-pilot, you can keep them in sync and prevent spreading confusion. An alarm when the two pilots are out of sync seems like a pretty straightforward benefit.
My understanding--I am not an aviator--is that the current Boeing controls behave this way and have for a long time. Apparently there is a lot of disagreement between the Boeing/US and Airbus/EU schools of thought, with a preference for greater mechanical (rather than electrical) interaction with flight controls on the Boeing side.
I want a device that gives me an electric shock every time I think or say this. If one can restructure one's cognitive habits in a way that replaces thoughts like this with thoughts like "What would explain this? Is this reasonable? What are the alternaives? How can I check this?", many errors will be avoided.
Illuminate the pilot's footwells with a bright red light. There is normally no illumination there at all, plus it takes up a fairly large percentage of their viewable area when looking at their screens.
Or, change the background colors of all the screens from black to red. That might harm usability too much though. Maybe change all the other switch backlighting over to red. Or change the cabin overhead lighting over to red.
To the greatest extent possible, the entire environment and interface needs to communicate the modal shift. And pilots would need to train on this shift constantly so that recognition, and the appropriate shift in thinking, would happen habitually.
I am no aviation expert, but according to other posts here the stall warning may have been ignored because Bonin didn't register that they were in alternate law. If they weren't in alternate law, the plane would have automatically limited the amount to which he could pull back.
The most obvious solution to me, if all of that information is accurate, is that there should be a distinct audio stall warning for alternate law.
Instead of the plane saying "Stall... Stall... Stall... " when in alternate law it should probably say "Stall... alternate law... Stall.. alternate law...". Doesn't guarantee you the pilot will listen, but it seems like it is pertinent enough information to push it front and center along with the stall warning.
It seems like that when analyzing this accident. If you analyze another, there may be 2 or 3 other things that would seem "pertinent enough information to push it front and center". And yet more for a 3rd accident.
The problem is that making something more noticeable automatically makes everything else less noticeable...
The two things that seem to big huge contributors to the crash are that the pilots may not have realized they were in alternate law soon enough & one or both pilots did not realize that one of them was holing the stick back stalling the plane.Both of these seem like glaring UX & training issues.
It does not appear that it's very clear when the plane goes into alternate law & it does not appear they receive much training on how to fly in alternate law. Even if they do receive training, you probably do not want your most novice pilot handling the controls in alternate law. Additionally the averaging of the inputs seems to be the most obtuse way for pilots to realize mismatched inputs.
I agree with you in general that it is a balancing act, but if you're going to have a modal interface (normal law, alternate law) and the plane's flight controls are going to perform differently depending upon that mode, an indicator of which mode you're in is immensely important in any situation.
Typically there are two lights, master caution and master warning, that indicate a problem. From there, the details can be read on another screen. Additionally, there are voice alarms for critical events, like "Traffic! Climb now!" or "Fire! right engine!".
I don't know how an Airbus notifies the crew of the switch to alternate law, but I'm willing to bet that the master caution light comes on.
Up to this point, the situation was playing out in a sadly too common case of pilot error, pilot inexperience, which makes up a huge portion of aviation accidents.
When I read about the dual input averaging, I literally exclaimed "what?!". I can't believe that, for all the strict standards that flight control software must meet, nobody called this out as a dangerous idea?
completely agree about this 'dual input' mode - crazy.
But also these modern planes seem to jump in and out of 'modes' without any warning or confirmation.
I believe the 2008 plane crash at Madrid (largely pilot error again) also suffered from some confusion about the plane 'mode'. It was set to 'normal flight mode' whilst attempting to take off (or something).
Again, both crashes largely due to 'usability' issues and cockpit design.
Madrid crash was due to a improper disconection of the flight-ground sensor by maintenance( following unclear documentation)That led to a take off without flaps ( the configuration alarm didn't sound as it should when the crew forgot to extend them). It didn't take off it only jumped out of the runway and then crashed.
It was not an usability matter just lots of small factors aligning, neither one on itself could have caused the accident.
There is a loud "dual input" voice + a red light just infront of you. Also if you push the red button on the sidestick and keep it pressed you override all te commands of the other one. This has several reasons, taking away the control from a disoriented pilot or disengaging a malfunctioning sidestick which is commanding random inputs.
Exactly. Anyone who has fought for control of a television with two remote controls knows exactly how this works out. You both start pushing channel-up and channel-down in response to what you think is the other persons action but may be in fact be your own.
The state of UX design has advanced so much, perhaps we need more UX testing so that even pilots who are unfamiliar with a plane could figure out what to do. Amazon probably does more with figuring how to help users checkout their shopping cart than plane designers helping pilots get a plane out of a stall.
Alternate law and normal law introduces two modes. This breaks one of the rules of user experience, especially if it is infrequently encountered. Combined with turning autopilot off on its own, it is bound to cause even more confusion. The plane could have put an alert asking the pilot to go on autopilot, otherwise, it will continue by making educated guesses. (A pilot is no better judge of airspeed than the computer)
Another rule of UX broken is "tell" instead of "announce". The voice should have said "Stall. Dive now" or "Stall. Why are you pulling the stick back?".
The flight computer can reinforce its credibility by demonstrating it has predictive capability. For instance, it can say, "decrease your angle of attack or you will stall in 5 seconds", then "4", "3" "2" "1", "stalling". The voice should demonstrate increased tension and panic as counting down.
It is high time the flight computer act as the "third pilot". It is similar to video judges in competitive sports.
Of course people may choose to ignore the computer, but we can then continually review why the computers assessment was wrong and improve on it.
What I don't understand is, how does a plane know it's stalling if the pitot tubes are frozen?
By the way, optical flow meters could have been used as a backup.
> how does a plane know it's stalling if the pitot tubes are frozen
Angle of attack sensor. AoA is the actual definition of a stall as it measures the point at which airflow breaks away from the wing, reducing lift.
Re your other points on computer warnings, cockpits can get pretty noisy when shit happens with various alarms, buzzers, horns and voices going off. There's actually a tendency to reduce the number of different alarms and use screen information to indicate the problem (although that may be changing after the Qantas drama in 2010 http://en.wikipedia.org/wiki/Qantas_Flight_32).
They had no functioning pitot tubes and lots of contradictory indications, which triggered a storm of alarms, most of them false. Pilots spend quite some time trying to shut alarms off while trying to figure out their situation with air control. I can't imagine trying to talk and cooperate with colleagues, facing a complex system and a life-or-death situation, while so many loud and stressful sounds are buzzing through my ears.
After 9:00, the plane inverts upside down, a "whoop-whoop" alarm goes off and the plane finally crashes into the sea. The alarm only served the sinister purpose of announcing they were going to die.
There's actually a tendency to reduce
the number of different alarms and
use screen information to indicate the problem
Yes, that'd be good UX. There should be only one actionable task presented at any time to correct errors. In any case, user testing is more important than guidelines.
I wonder if grouped alarms make any sense. For instance you can group all alarms related to stalling together, and present the one thing the pilot can do to correct this. This gives the pilot a sense of what is the most effective use of their attention in a bad situation.
QF mishap - the Wikipedia article didn't talk about the alarms.
This already happens. I have not been trained to fly an airliner, but I believe that the priority is something like stall, gpws (flying into the ground), tcas (flying into other traffic), master warning, and master caution. These all have their own lights and sounds in the cockpit, and if I know them, so does the flight crew. Presumably the 150 messages that needed to be looked at were all "caution" messages. Too many messages, yes, but nothing that endangered the safety of the flight.
In the AF447 case, the crew was getting the stall warning. They did the exact opposite of what you are supposed to do to recover from the stall. Computers were not the problem. (The same thing happened to that Colgan Air flight a few years ago. The crew reacted to the stall warning by stalling the plane even more. The plane tried to physically force the controls to nose down, which is how you recover from a stall, but the pilots fought it. Bad UI was not the problem. Bad flying was.)
The plane tried to physically force the
controls to nose down,
I'm glad you mentioned that. I thought that's what a plane should do at first, and then on second consideration wondered if the psychology of panicking pilots would be to fight the controls in order to wrest the plane from going down.
With the Qantas incident, they had something like 146 msgs appear on the screen spread over about 5 or 6 pages. So they were forcibly distracted from solving the problem from a top-down approach to having to investigate and cancel each of the 146 msgs, and that was why the two extra pilots were such a godsend, they were able to help out.
Yes, a message flood is also a failure of UX. At my place of work, when a flood of errors occur, we throttle and batch the errors so that the admin doesn't get thousands of emails.
Given that user interfaces on airplanes are digital now, there are a lot of opportunities to innovate.
For instance, where there are multiple failures and alarms, it might be better for the panel to continuously replay the sequence in which the alarms were set off, more or less like how movies do it to help the viewer understand what is happening on the computer. By showing how a system is failing through time, it shows a causal relationship. In addition, you can provide drill down capabilities.
In the case of Air France, perhaps it could have illustrated the AoA through time, and the flight velocity. Perhaps that would have explained something to the pilot.
The autopilot turning off altogether is the biggest equipment problem here (along with averaging/independent sticks). An alarm will surely be necessary but I don't see how killing off autopilot helps since the pilots probably won't have any better of an idea. Perhaps this specific incident caught an ugly edge case.
There is actually a fair amount of ergonomics and interfaces design that goes into these systems - at least equal to Amazon's shopping cart, probably more. Same goes for systems like ATC.
"Stall" does mean "dive now" to every pilot. It is extremely questionable whether including this information explicitly would help at all in the chaotic, confused environment in the cockpit at the time. "Why are you pulling the stick back" is way too long as well, although it does raise a fair point about keeping both pilots aware of each other's control inputs.
Fair enough. My main point is that we spend a lot of time trying to get the autopilot to function right, but it's not an easy problem where you can just throw a bunch of edge case detection code in. There are lots of physical control laws involved in a/c code that you can't break. Silly laws of physics type things.
pitot tubes just measure longitudinally forward airspeed (ie the direction the plane is going). altimeters measure asl (above sea level) altitude, and gyros measure angle of attack and accelerations.
I believe there is a way to tell stall just from altimeter and gyro readings when combined with state information (flap position, gear up/down, &c.) about the plane.
great points about the ui design, though.
i think the biggest issue, though, was the controls not announcing (either through force feedback or a blaring alarm or an urgently blinking light) conflicting input on the control sticks. does anyone know why this is a feature in the first place?
It's actually not a sudden reduction in lift either. Even in a stall, lift equals gravity. It's just that the normal relationship between angle of attack and lift is reversed to that higher angle of attack lowers lift rather than increasing it. This makes it inherently unstable and difficult to control, but there is in principle nothing preventing you from flying a stalled airplane all day.
my dad is a captain, very experienced -- flies 777s, has > 20k hours and is trained in both airbus and boeings.
over dinner i once asked him "so what's the most exciting or difficult situation you've even been in?"
"hm... nothing i can think of, it is all pretty boring, really"
"i mean c'mon, there's got to be something!"
"you see? if you do things by the book plus a little on the safe side it usually works out that you are never in an exciting situation -- my job is to ensure that even the most unlikely exciting situations become more unlikely."
in this particular instance, it seems that there are a few actions that could've avoided the whole situation had the people in charge had the mentality of "by the book plus a little on the safe side". the most glaring one is that the other planes in the area diverted to avoid the storm. another: the captain should have made clear who is in charge.
of course, this is very easy for me to type from the comfort of my office without any situational stress.
due to a complicated set of fortunate circumstances i once got an observer seat during re-current simulator training (happens every 6 months).
all the flying i've ever done was on ms flight simulator, but i know enough to read gauges and what not. it was so intense that even i was too stressed to finish paying attention to the whole session. lots of exciting situations there.
It's interesting that First Officer Bonin is able to doom the plane by continuing to hold back on his joystick, even when that action isn't having positive results. Had the other first officer pushed his joystick forward, would the plane begin to dive? I assume that one joystick has precedence over the other...
It seems dangerous to have two joysticks, both capable of controlling the plane, that have no physical or simulated physical link. It means that one pilot could be attempting to control the plane and his actions will have no effect whatsoever if the other seat is panicking (as in this case).
Airbus' have priority override button which will allow the pilot not flying (PNF) to take command of the aircraft. In hydraulic or "direct" flight controls, both sticks move at the same rate, you need to be stronger than the other pilot. Normally the autopilot and flight control system would have the authority to override the pilot actions (common on A320 etc.) but not all planes have that feature.
In addtion, if the autopilot or flight control system goes from a fully 'in the loop' mode to a 'direct mode' where input=output (the transition possibly being caused by faulty airpseed sensors in this case), the automatic flight control mode has no more authority to interrupt pilot command.
In situations like you describe where two 'free' (no force feedback in relation to control surface force) joystics are used, it is better to have a 'pilot in control' switch otherwise you could get situations where an inexperienced pilot would panic and force his joystick to an unsafe position, overriding the more experienced pilot.
In all cockpits, there is usually a strongly defined system of who is currently in control. At one point you can see this happening - one of the pilots declares "I have control". In normal flying conditions, any time flight control passes over between pilots there should be a declaration along those lines. However, the reactions of the pilots in this situation don't seem to be entirely in line with what they should have been doing, which is a major contributing cause to the crash.
I am a pilot (a small one but instrument rated) - there's no time EVER that you want that, and I am shocked the Airbus does not have a warning that says DUAL INPUT BEING RECEIVED. At the very least, it should give priority to the left seat controls.
I think that part of the problem here is that the plane is so far out of trim and CRM has gone completely out of the window that psychologically at least the mental workload on the junior pilot has caused him to "freeze".
Far worse, imaging a situation where one of the control inputs fails; i.e. constantly produces nose up input. Can one of the inputs be suspended / turned off?
IAAP (not commercial) and that sounds like an awful way to do things. An important aspect of cockpit resource management is to know who is controlling the airplanes, and part of that is always positively verbally transferring control, with confirmation. "I have the plane." "You have the plane." There is no situation where you want two people to both have input at the same time.
IIRC, that was lesson 1, minute 2 (right after take-off). The previous commenter who said that wouldn't think to ask because it is akin to asking 'is the computer plugged in' is probably right (though the captain should have noticed it when he was observing).
Serious design flaw, and tragic human error with devastating results. :(
I'm actually mildly surprised that it waited until you were in the air. I always brief that before takeoff whenever I take another pilot along. But yes, very basic stuff in any case, and amazing that they were not following this standard procedure.
I think another major difference is that in most planes, you can feel when the other guy is screwing around with the controls because they're connected, so you can yell at him to stop doing whatever he's doing.
It seems to me that it would be worthwhile to fake this in a pure fly-by-wire environment. The added cost and weight of a force-feedback system on the control sticks should be minimal compared to the aircraft as a whole.
I guess it could be a cheap workaround to always get smooth transitions when changing pilot. Imagine if one pilot holds full left and the other full right and you press a "switch now!"-button. You would need some kind of transition-period of maybe a second to avoid jerk which could be confusing for the pilot to not know when he has full control and when he is in transition.
This is likely the reason, and probably not just as a cheap work around, in most day to day situations it's probably the desired effect since both sticks are independent and don't move in reaction to the other.
Actually if both sticks are actually linked, the person taking over will find his stick already full-left, and have to actually pull it over to the right as part of "taking over". Such simplicity and it would result in none of this insanity.
True. But, how would you want to handle the situation of two equally competent(at least in the eyes of the employer) co-pilots vying for control? should it always go to one? always go to the other? have a switch controlled? controlled by whom? not easy questions if you ask me.
edit: I actually can't think of a good way to do that other than have a manual switch on the console that would switch between the two controls. anything else seems amazingly bad.
The men are utterly failing to engage in an important process known as crew resource management, or CRM. They are failing, essentially, to cooperate. It is not clear to either one of them who is responsible for what, and who is doing what.
I have read a few other transcripts from crashed planes and this seems to be the most common and significant contributor.
I see variations of this problem almost daily in my day to day work. It strikes me so many times that people flat out refuse to communicate or do do in an extremely ambiguous fashion, people violate responsibility boundaries all the time (faux-technical people forcing technical decisions for e.g.) and that directly results in losses far greater than they should have been if there was any notion of discipline and communication.
CRM is interesting stuff. It got popular in aviation after the crash of United 173, where the crew was so involved in a serious landing gear problem that the only one who noticed that they were running out of fuel apparently didn’t want to be rude enough to insist on dealing with it before it was too late. In that case, it was generally interpreted as too much respect for authority: the junior crew member didn’t want to distract the captain by raising the fuel problem too often. So that can go both ways.
United 173 was only a particularly good example of exactly what you point out: many plane crashes happen when individual crew members miss simple things that others could easily correct but don’t. After flight crews got CRM-based training, the incidence of this kind of thing went down measurably. But as I was reading this transcript, it was eerie to see how little they were applying it. Why were they practically silent? If they’d each volunteered a little more information about observations, intentions, and actions (“I’m leaving the stick full forward”), they’d have been fine.
Anyway, I think CRM has some pretty clear applications to normal business environments, but especially to startups. The jumbled panorama of interlocking and quickly developing options confronting a small team of coders is not unlike an aviation emergency, though at a slower pace.
I don't want to in any way refute the referenced article or the findings of the air crash investigators, because clearly the pilots here behaved incorrectly and I am just an outsider.
However I think it's worth at least mentioning that both airlines and aircraft manufacturers have a vested interest and significantly more resources to put behind demonstrating that pilot error is the primary cause of any accident.
For instance in this case you have...
• poor training (pilots unprepared for alternate law)
• possibly poor UI (de-coupling of controls, insufficient communication that aircraft had lapsed to alternate law)
• small-scale systems failure (pitots)
• incorrect response and continued failure to understand aircraft attitude (in turbulence, with no visual cues, in a situation which 'fooled' three pilots)
...which makes it an interesting one for manufacturer and airline to definitively defend, but I would guess that they can and will absolve themselves from liability.
In one of Malcolm Gladwell's books he talks about air crash scenarios, citing several cases where copilots were 'scared' of pointing out errors that they thought were being made by their captains. I think it was Korean airlines that lost a few planes this way, essentially through a lack of communication.
They brought in some guy to retrain the pilots and they never had the problem again.
This was also one of the points of Malcom Gladwell in one of his book ("the Tipping point"), where he talked about what went wrong in several examples of air crashes: lack of human cooperation at its best.
That was one of the tensest things I've read in a while. My heart was pumping up until the end. The level of stress, confusion, and terror those pilots, not to mention the passengers, must have experienced must have been truly terrible.
My thoughts exactly. While reading this I could not think about the same counter-intuitive reaction that people have when they drive and the car slips. Most people steer in the direction of the road when the single action to regain control is to slightly steer in the direction of the slippage.
That very much depends on the angle, speed, acceleration and traction you have and whether you are slipping in the front or back.
That being said in reality most people don't have the training and experience to regain control anyway, which makes the very counter-intuitive option of crashing your car in a way that doesn't/is unlikely to kill anyone a fairly good option.
Whatever actions you take they should aim to regain traction. My point is - the car's response is non-linear in such circumstances and linear responses don't help.
You can find on youtube videos of drifting cars. You can see there how complex your response (steering + throttle + braking) should be with respect to the car's state on the road.
If the plane stalls it goes down. Ponting it upwards to not go down will make it stalling even worse. You didn't have any speed to begin with and now the angle of attack is reducing its speed even more.
(Don't assume de-clutching works if you did not test it in a safe env)
I've been in flights that have experienced very mild turbulance and let me tell you, it's enough to wakup any sleepy passenger. With the amount of turbulance this plane experienced, there is no way anyone could have been oblivious to what was going on.
Looks like one issue might be that all the instruments show what the aircraft is doing and what is happening outside, but it doesn't show what the pilots are doing. When we design interfaces, we of course assume the user is aware of their own actions and embodied state. But I guess when there are multiple users we need to help them be able to sense the actions/state of others.
Linking the two sticks is one way, another might be to show the state of the two sticks on the display next to the indicator of pitch, perhaps using coloring to highlight when the sticks are being pushed forward or backward. But of course there is already an overload of indicators. Really, improvements in the software/AI might be the best solution.
> the user is aware of their own actions and embodied state
particularly unaware in this instance. due to the turbulence and general confusion it is very likely both pilots were disoriented. it is possible and likely that their senses were conveying wrong information to them.
(most people experience some mild form of this at some point when in a car or plane that's not moving next to one that is moving slowly and it feels as if you are moving backwards)
I've followed the discussion of the AF447 investigation on several flight discussion forums.
The PF (Bonin) apparently never became aware of his angle of attack (once the airplane fully stalled, AOA was absurdly high). He did not seem to be aware that his constant inputs had caused the Airbus's THS (trimmable horizontal stabilizer, horizontal flaps on the tail) to deflect to maximum in order to try to keep the nose up. Therefore when he tried to input stick up (nose down) several times briefly, and there was no obvious response (the computer takes a while to reduce THS elevation in response to opposing input), who knows what he thought -- maybe that all readings were incorrect.
Strangely, Bonin was the one pilot who had significant recent glider experience as I recall. The Airbus computer even in "alternate law" functions nothing like a glider (only "direct law" is sort of close to direct input), so maybe that further confused him.
In my opinion, at night, over an ocean, in a storm, with no visibility, in possibly significant turbulance, a modern aircraft cutting off Autopilot for any reason other than computer failure is completely unacceptable. A computer should be able to fly as well as a human under those circumstances.
People suggesting that on airliner forums get flamed. But it's true. Most pilots kept up the refrain that a computer cannot safely fly by gps and gyros unless they also have airspeed. Which is true. It's dangerous to fly if you don't have true airspeed (gyros and gps cannot accurate provide relative wind speed). However, if pitot tubes are frozen and the computer no longer has valid airspeed, the pilots no longer have valid airspeed either. Pitch and power is all they can do. The computer can do that just as well. All it needs to know is aircraft weight, which can be entered (maybe it is entered) before takeoff and automatically adjusted to account for fuel consumption.
There are a bunch of factors that contributed to the accident:
Pitots shouldn't have frozen.
Lack of Air France training for controlling an aircraft at altitude with the computer in "alternate law" (mode without full flight envelope protection; it's therefore possible to stall).
The command structure in the cockpit without the Captain (who had just gone on break) actually had Bonin in command, even though the co-pilot in the left seat outranked him... AF has since changed that. CRM (crew resource management) was poor; the co-pilot in the left seat didn't try to take control until way too late. The co-pilot was preoccupied with where the Captain was rather than offering constructive input on how to fly.
Bonin was not adequately aware of what his inputs were doing, or what the plane's Angle of Attack was, and did not react properly to the stall warning which in almost every case at high altitude means drop the nose, not raise it (though without valid airspeed there's a risk of overspeed which can cause a new set of problems).
The Airbus computers had some quirks; stall warnings stop if airspeed drops too low (due to some computer programming logic involving low airspeed, AOA sensors, and the result being silencing the stall warnings).
Nobody believed a passenger aircraft would be so stable during a full stall. This undoubtedly contributed to confusion about whether they were actually stalled. The Airbus's computer setting the trimmable horizontal stabilizer to max nose-up deflection, in response to Bonin's almost constant nose-up input, possibly contributed to the stability during stall.
Angle of Attack information may not have been adequately displayed to the PF (Bonin) -- the black box doesn't record data from the right set of instruments, so nobody knows what Bonin had on his screen.
There was poor notification on the co-pilot's side of what the PF (Bonin) was doing. Unlike traditional aircraft, it is not easy to see what the pilot in the other seat is doing with the stick.
There was poor notification on either side of the cockpit when the other pilot took control. When the co-pilot took control, Bonin almost immediately took control back, and it's not clear either of them knew what the other was trying to do. Apparently there's a light that indicates override, but who would notice such things under that amount of stress?
IOW, it was a disaster from top to bottom. Usually in aircraft accidents there's a chain of events, but in this case there were so many possible contributing causes that other than having better pitots that didn't freeze over, solving any one other problem may not have broken the chain.
IANA Pilot. I do make aerodynamically correct fixed-wing and lifting-body type paper airplanes, however, and I have had a LOT of fun playing with aerodynamics in this hobby.
One thing to keep in mind regaring stall is that it's 100% dependent on angle of attack, not speed (something Popular Mechanics gets entirely wrong). What happens basically is that at a high angle of attack the air layer doesn't track the wing surface properly and so you are deprived of standard lift. With certain aircraft designs (SR-71 for example) this is very hard to make happen (but the SR71 can stall it's engines before the wings stall due to AoA).
If you are faced with a stall, I would expect the first thing to do is to pitch down to reduce angle of attack then accellerate and pitch up to get out of it. T-tail designs are generally disfavored because the elevators can get blanked by the wings in a deep stall, but with the A330 this isn't an issue as it doesn't have this tail design.
I find it puzzling that a professional pilot would pitch up in response to a stall warning. Popular Mechanics is right to flag that is as difficult to understand.
A commenter below (cellularmitosis) makes a very interesting point: Bonin may not have realized he was in "alternate law" (let's call it "mode" instead of "law").
In "normal mode" the computer will not let pilots stall the plane, whatever they do; it will accept the commands up to what it considers dangerous. There's an "envelope" of acceptable plane movements; pilots can move inside this envelope but not outside of it.
In "alternate mode", the envelope is much wider and you can actually stall the plane.
If you're in normal mode, it makes sense to pull the stick all the way so that you're at the edge of the envelope: you climb as fast as you possibly can (as fast as the computer will let you).
And you can probably fool yourself when the stall alarm rings: the computer is telling me I'm near stalling -- I'm at the edge of the envelope, THIS IS WHAT I WANT!!
In fact you're not in normal mode anymore, and the computer is telling you that you're way past the envelope. But you can't register that, because for you that is simply impossible.
If that's what happened, the cause of the crash is insufficient training in alternate mode.
Bonin would have had to realize that the plane is in alternate mode in the first place in order to react correctly. It probably never crossed his mind since he never trained in it, and conversely if he had trained in it, he may have been more likely to at least check.
But to me the bigger problem seems to be that such an important change in the plane's behaviour could happen without anyone noticing. I'd consider the mode to be something the pilot must be made aware of, not something he has to deduce from the fact that the airspeed isn't available.
Perhaps the mode is shown prominently and the pilots just didn't notice it in their state of panic. Making it more prominent probably leads right into an insane arms race - the stall warning was as prominent as anything can be and still got ignored.
I don't envy the person who has to design a airliner cockpit's user interface and decide which of a hundred potentially vital pieces of information should be displayed how.
Bonin had to have known that the plane was in alternate law.
In the flight recorder log, at 2h10m05s, there was an audible "cavalry charge" alarm that indicated to everybody in the cockpit that the autopilot was disconnecting (plus message at the same time on the ECAM).
Then, on the ECAM message console 1 second later, the message "F/CTL ALTN LAW (PROT LOST)" was displayed: alternate law, protection lost. At the same time, Bonin said "I have the controls", which to me indicates that he knew that the autopilot was off and that alternate law was engaged.
A mode switch as important as this should be very visible. An idea: put a two-color led under every indicator light and switch to the other color when the plane falls into alternate law. This should make it sufficiently clear that something very notable has just happened.
Something like that was my initial thought. However, you have to remember that there is massive amount of very notable things going on and data shown. As brazzy pointed out, the stall warning was as prominent as possible and still was pretty much completely ignored. I don't think they would've noticed any amount of leds in that point.
When in normal law, if you pull the nose up all the way, and are at the edge of the envelope, will the computer even give you a stall warning? I would guess (hope!) not, since the plane is never actually in danger of stalling. Assuming that's the case, a stall warning from the computer should always be heeded.
If that's not the case, and the stall warning sounds even when there's no real danger of stalling (because the controls are operating in normal law), I feel like that's a terrible user interface.
I really don't like the idea in general that 'normal law' mode lets the pilots yank the controls any which way and the computer (supposedly) prevents the plane from leaving the safe flight envelope. I believe that sets up the wrong attitude in the pilot's mind about having to carefully and thoughtfully control the aircraft.
If the flight computer is having to intervene and change the flight controls, then at the very least there should be a force-feedback mechanism in the stick which tells the pilot he's doing something wrong, and that he really shouldn't be yanking back the stick that hard.
The other bad part of the user interface is that the two sets of flight controls are not linked, like they were in the old days. With side sticks, it is not easy to see what the other pilot is doing. And averaging the control inputs of the two pilots is INSANE, in my opinion. Only one pilot should be flying the plane, and it needs to be quite obvious who that is at all times.
The CRM mechanism to take over flight controls should not be saying the words "I have control", it should be flipping a big switch on the center console that visibly indicates who has control.
I like the idea of linked control, like on the small planes. That's "the principle of least surprise" and also gives the copilot the right information of what another guy is doing -- that was obviously missing here!
However if you add force feedback of the plane computer "correcting you" you'd never know if it's plane or an another guy. Therefore, force feedback from the computer doesn't sound to me as a good idea. Some kind of feedback would be a good thing, but in panic, it wouldn't be noticed. I guess I'd put something like something "protruding up" on the stick when in another mode -- you'd feel and see it.
Finally, switch flipping is unnecessary if you have a force feedback. It think that's really the major feature missing!
yeah, I agree with that. Also there's another factor in that stall warnings may have been seen as an ADIRU malfunction rather than an actual stall. In those cases, I suppose pulling back might make some sense if you think you have bad ADIRU input and the plane is in normal law.
I think the whole point is that in almost all circumstances an ADIRU failure will lead directly or indirectly to alternate law. Hence the correct procedure should be to assume alternate law and cross check.
Once your instruments start failing left, right, and centre you should go into what I call "advanced free fall" mode, check horizon (true, false or otherwise), check altitude, check parachute, repeat... If you hit gimbal lock (or similar INS failure) in the dark, well just bend over and kiss it goodbye.
From what I read from the preliminary report, it's established that the stall warning sounded. If it had not been audible on the CVR, they would probably have noted it.
One problem was that the stall warning stopped due to high angle of attack even though the plane was stalled, and it started again when the nose was lowered and the AOA was in the "valid" region again. This might have confused the pilots in a situation when they already had inconsistent airspeeds etc. to deal with.
Ah, yes, I read that too. It was so frustrating that the pilot kept pulling up all the time, it makes no sense. You'd think that at some point he'd stop and reassess, but I guess he was too confused and shocked to do it...
On the other hand, it's not obvious to me that the simulator would behave correctly in this regime either. Having the simulator work correctly in a deep stall is probably not high on their list of priorities. It's possible that this was even the first time ever that an Airbus had been stalled like that, so maybe no one actually knew how it would behave.
Yes, that's possible. I remember reading an article by the author of X-Plane about how stalls are mostly simulated by trying it in the real aircraft and programming something similar, because the airflow dynamics are too difficult to model in real time. (Incidentally, the Cessna 172 is nearly impossible to stall in X-Plane, but somewhat easier to stall in FlightGear. I wonder who's closer :)
By easier, do you mean that you have to exert more back pressure to have it stall, or that it quickly gets out of the stall? I think it can vary a bit depending on weight and the exact model you're flying. In some models it's difficult to maintain the stall because the nose will just drop.
You should get an introductory flight lesson, then you could ask do have a stall demonstrated and see which flight simulator matches best. There are a lot of signs you don't get outside a full motion simulator, such as wing buffeting and "mushy" controls.
Yup, intentional stalls give plenty of warning in a trainer.
It's the stalls caused by uncoordinated flight during a steep bank or snap spins caused by exceeding critical angle of attack, regardless of speed, that will kill you. The first is easy to get into in a trainer like a C172. The second won't happen (safely) unless you're in something with a bit less lift and more power, like a Pitts.
I've been meaning to start taking lessons so I can get a private pilot's license, but it's hard when you live in downtown Chicago without a car. There are a couple schools at MDW, but you'll eventually have to drive to the suburbs as MDW does not let students fly solo out of the airport. Probably for good reason :)
> Of course, very little airliner training happens outside a simulator, which can you can stall without damaging anything.
Maybe they should apply mild taser shocks to pilots stalling in the simulator. I'm not being snarky. There should be some kind of physical consequence of making bad mistakes, otherwise it's too disconnected from reality.
The result of that would be pilots doing everything in their power to avoid entering stall and thus learning less about behaviour while in stall and exiting stall. I'm not sure that's a desirable outcome. Sometimes you have to fail to learn.
I don't think accidents happen because pilots don't realize crashing is a bad thing, they happen because pilots do the wrong thing. You probably want pilots that have trained on dealing with lots of different failures and can do the right thing as correctly and quickly as possible, not pilots who get stressed and upset recalling the electric shocks they got during training.
It's especially frustrating for me because i remember all the times i crashed in a simulator due to stall until i understood what was happening. I don't even remember the name of the simulator, i'm not even an amateur-pilot - but that makes that report almost unbelievable, that something like this happened in a real flight to a real pilot.
unbelievable, that something like this happened in a real flight to a real pilot
Actually, most fatal crashes are "stall-spin accidents", where pilots stall the airplane near the ground without sufficient altitude to recover. But those are not cases where you keep the airplane in a deep stall for 90s. When you stall an airplane in VFR, it's obvious what happens.
No one would persist in keeping the airplane at 20 degrees positive pitch while descending at thousands of feet per minute without realizing the airplane is stalled. But here, without outside references and with obvious confusion about the state of the airplane, it was apparently beyond these guys. (Except the captain, whose comment about "no, don't climb" seems to indicate he was on the right track, but by then it was too late.)
Actually, only the less experienced copilot, Bonin, appeared to be in favor of climbing. The other repeatedly told him to level out or dive, and apparently thought Bonin had listened (which would explain why he was so baffled). As the OP points out, neither that copilot nor the captain seemed to realize that Bonin had been futilely trying to climb the whole time until that moment at the end when the captain ordered him to stop.
> One thing to keep in mind regaring stall is that it's 100% dependent on angle of attack, not speed (something Popular Mechanics gets entirely wrong). What happens basically is that at a high angle of attack the air layer doesn't track the wing surface properly and so you are deprived of standard lift.
So the air layer on the back "peels off", and you have turbulent flow on the back, instead of laminar, is that right? So the negative pressure is greatly diminished.
One thing to keep in mind regaring stall is that it's 100% dependent on angle of attack, not speed...
While the degree of stall with respect to the wing is independent of airspeed, the effects of stalling on the aircraft are very much dependent on speed. Even with the wing in the process of stalling, it can still generate enough lift to keep flying if you're going fast enough.
I find the fact that the control sticks do not move together the most troubling design flaw. Bonin's actions were not obvious to the other two pilots, if the other pilot saw his stick pulled all the way back when he knows they need to get the nose down and pick up airspeed, he'd instantly know what was wrong. Instead he is looking at instruments and talking to the other pilot and is completely unaware of how self-inflicted the crisis is.
That, and the fact that the computer chooses to average inputs from the two sets of controls even when they're very different. One pilot pulling back, and the other pushing forward and the system just quietly averages them out rather than sounding another alarm?
You suggest that one problem might be that Bonin didn't know his angle of attack. Alternately, I remember a similarity here with an Egypt Air flight that went down when some instruments went dead: when one of the instruments experienced malfunction, the pilots suddenly found it hard to believe anything the computer was saying. So maybe, on some level, Bonin dismissed the stall warning because the speed sensor had failed. One sensor is faulty, he might have reasoned, how can I know the computer isn't just over-reacting to that?
The NTSB concluded that 990 was a homicide. A relief pilot assumed control after take-off and then deliberately crashed the aircraft. From what I hear, it wasn't a fun week at the RI Medical Examiner's office.
and Aeroperu Flight 603, where the pitot tubes had been covered by maintenance workers and not removed prior to takeoff, also resulting in pilot confusion and lack of confidence in instrument readings:
The ground speed is not useful information. You can be moving backwards relative to the ground and still be overspeed. The only thing that matters to the airframe is the airspeed, and the only way to know the airspeed is to sample the air around the plane.
> You can be moving backwards relative to the ground and still be overspeed
Only in a simulator.
A Cessna 152 is a slow, low-powered trainer. It has a never-exceed speed of 141 knots. So for that aircraft to be going backwards AND be overspeed, you'd have to going into a headwind that exceeded 141 knots.
These windspeeds only occur a) during hurricanes/tornados or b) the high flight levels. You're not going to get a 152 out of the hanger during a hurricane and with a service ceiling around 14,000 feet, you're not getting close to the flight levels, which start at 18,000 feet. I supposed you might see some 100+ knot winds on occasion between 14,000 feet, but again, you're not probably going to be alive to attain the necessary altitude.
You can be moving backwards relative to the ground and still be overspeed.
That's not true. The wind even at altitude won't be more than ~100knots. It's true you can't land using GPS speed, but if your GPS tells you 90 knots ground speed at 37000ft, you know something's not right regardless of wind.
The margin between stall and overspeed is something like 20 knots at that altitude. You're not going to be able to calculate your airspeed from the groundspeed within that margin. (FWIW, I'm pretty sure this GPS speed information is available in the cockpit already. If not, you can get it off your iPhone if you really care.)
Finally, the flaps-down speed range of a Cessna 152 is 35-85 kts. So if you're facing into 85kt winds with the flaps down, you're flying backwards and are overspeed. (This can happen with the flaps up too, of course, but winds of 149 kts are a little hard to believe :)
While 149 kts at the 2,000 ft to 12,000 ft typical of Cessna 172 flight is rare, we had it in Seattle last week (wind speeds on the ground were 20 - 3 kts, at 3,000 feet we had 60 kt winds at 12,000 feet we had 100+ kts, can't remember exactly).
I'd guesstimate in the Seattle area it occurs once every 2 months below 20,000 feet. Above 20,000 feet, it's a regular occurrence.
Flying into 85kt winds will not put you overspeed, flaps down or up (assuming you're airborne, and not on the ground). Wind speed has no effect on aircraft air speed.
If you're flaps-up, engine at 2300 RPM, flying straight-and-level you're going to be cruising around 120kts airspeed in a C172 regardless of a 100kt headwind or 100kt tailwind.
Groundspeed is another story all together (and your fuel consumption getting to your destination).
True about the small margin between stall and overspeed, I didn't mean you could regularly fly like that. But according to the article, their air speed decreased from > 220knots to 90knots. What I meant was that regardless of wind, 90knots air speed should give you a ground speed so low that it should leave no doubt that you are stalled.
Apparently the PF was even thinking they were in overspeed at that point. So a ground speed should have told them that they weren't. But on the other hand, positive pitch angle and -10,000 ft/min vertical speed should also tell you beyond a doubt that you are stalled, so the problem here was not that the pilots didn't have the information they needed to figure out what was going on. They did, but failed to process it. It seems this is a classical case of "getting behind the airplane", they were just not processing events at the speed they were happening.
That's an interesting point. But if you're so panicked that you're ignoring the voice saying "stall", are you really going to check your GPS and then do a back-of-the-envelope to verify? Probably not. Because if you weren't panicked, you'd be out of the stall by following the stall recovery procedure.
> I'm sure you'd want to have a Big Flashing Warning Light telling you that ground speed <> air speed
That light would never stop flashing. :)
Once you get up a couple of thousand feet, even if the flag is hanging flush against the pole on the ground, you're going to have some type of air movement. The higher you go, the higher the windspeed (in general).
GPS can only tell you how fast you're moving over the ground. It can't tell you how fast you're moving through an airmass that might be moving with or against you, this is far more important to keeping a plane in the air than how fast you're moving between point a and point b.
I wonder if GPS could be used to estimate the air speed by means of a permanently refining mathematical model? E.g. If I know I have heading X, ground speed Y, weight Z, thrust A, you should be able to work out your predicted ground speed. Any variation in real ground speed and estimated ground speed is got to me made up of wind direction and velocity right??? Just a thought.
(Disclaimer: I know nothing about aerodynamics so this may be nonsense)
Yes, I keep hearing about pitot tube problems... I thought the Egypt Air flight I was thinking of had the same problem but I can't find information about it. It might be harder to find because I'm not sure the plane actually crashed.
That last thing is the most important thing to notice since this is what most people think is the main result of air crash investigations: making a change to break the event chain leading to the incident.
In this case there were probably a number of human errors, a.o: not noticing speed restrictions on the speedtape (even in alternate and abnormal alternate law/mode these are present, although Valpha max and Valpha prot are removed a barberpole is present up to Vstall warning) and 'ignoring' the nose-down moment the airbus tries to induce in a low speed situation.
Possibly some design errors in the form of the alpha-floor protection removed in alternate law/mode.
Seems like there is a lot to learn from this investigation for both pilots and manufacturers and although it might seem harsh and insensitive (believe me, it's not; I've lost friends due to an aircraft crash) I am actually looking forward to the 'final incident reports'.
According to the article, the pitots did, in fact, de-ice and return to normal functioning. However, apparently the alternate law needs to be manually reset, since the plane remained in direct input mode, and thus the pilots managed to stall the plane even though its instruments had all recovered.
Pitot tubes are always under strong heating during flight( so strong that the steel may blue). The problem with the 330 pitots brand in particular( there are several ) is that they cant evacuate water fast enought and sometimes they could become unserviceable ( as it happened to the af ) as they don't sense air preasure anymore.
According to the article's timeline, dual pitot failure occurred at about 02:10:06. Recovery of one pitot occurred at 02:10:36, and the other at around 02:11:03. That's about 30 seconds to recover one pitot, and 57 seconds to the recovery of the second. When you consider that this all boils down to melting off ice, that's not so bad, really. And if they hadn't royally screwed up their manual handling, it wouldn't have downed the plane - there is, in fact, a procedure for maintaining safe lift when airspeed indications are lost; somehow the copilots in command managed to screw it up, and continued to screw up even after the pitots recovered. The BBC tried replicating a pitot failure in a simulator, and when the sim pilots went by the proper procedure, there was no problem: http://www.youtube.com/watch?feature=player_detailpage&v...
So basically, this is human error, but exacerbated by a lack of training in cruise problems and poor feedback from the controls when the copilots gave conflicting commands.
The simulated test is always in a more relaxed environment. But anyway, if your instincts are good they you are OK. The problem is when your instincts tell you to do the opposite of what needs to be done. Probably the pilots need more training to break their instincts?
Maybe, but keep in mind that they are in operation on thousands of planes operating night and day, and they very seldom fail. So it's not what you would call a fragile solution. After all, the pitots involved in this flight were already due to be replaced because of icing problems.
It's hard to measure how fast you're going through the air without being able to sample the air. Pitot tubes are just the tubes that bring the air to the inside of the plane to be sampled; nothing more.
I mean, I know the physics behind pitot tubes, but I wonder if we'll come up with a better way of measuring this. Something like measuring deflections of a thousand tiny rods on the plane skin. Still vulnerable to icing and other mechanical damage, I suppose.
Maybe we'll just have really accurate GPS and beam external local instantaneous wind-speed measurements to the plane.
But, what would be taking those hyperlocal windspeed measurements--at the same altitude and within a mile or two? I can't think of any way at all to accomplish this short of a satellite with an incredible new method to measure many slices of moving air.
The fact that the heating element was not effective enough was a known fact. Since similar incident of lost of air speed had already happened. Pitot were being replaced with beefier heating elements. It was just not considered a high priority.
Thanks for the great summary. I also read the full BEA report which was very informative.
Is there ever a situation in a commercial plane where a stall would be a good thing? My non-pilot brain is trying to figure out why the plane would allow a stall even in alternate law mode.
I'm sure the Airbus user interface designers know what they are doing, but wouldn't it be possible to make stall protection always enabled, and then add a failsafe requiring both pilots to press a button to override stall protection? Then they would both have to consciously do a physical act to enter this dangerous state.
The plane did have the air speed information, at least at the time it made the stall warnings. Starting at time 2h10m17s, the pitot tubes started working again, the air speed was available, and the Flight Director came back online [page 89 of BEA report]. That is why the plane was able to make the stall warning in the first place.
I also wonder if, once the FD was back online, could the pilots have just re-engaged the auto pilot and the plane would have fixed itself? This is just such a tragic accident when there was nothing at all wrong with the plane for most of the incident!
All aircraft have a VNE speed, the NE standing for "never exceed." Going beyond this threshold invites structural failure and loss of control.
> If you're inside the plane, how does it feel when the plane has stalled?
I've mentioned this in another comment, but the body is a horrible judge of spatial reference. How the body is going to feel during a stall is tough to predict, particularly given that as a passenger a) you will have no visual reference and b) you will be at a unique distance from the aircraft's center of gravity.
That said, you might feel a little buffeting as the wing reaches a critical angle of attack, but once the plane is in a full stall you probably wouldn't feel a whole lot. It's impossible to overstate just how much the body relies on the Mark One Eyeball to properly interpret the sensation motion, gravity, centrifugal force, etc.
>at night, over an ocean, in a storm, with no visibility, in possibly significant turbulance
Instead of finding out strategies on how to fly under these circumstances, why can't the plane change its course, if they anticipate the flying route to have these conditions. How about running some reconnaissance drones in the popular routes if they suspect a bad weather and want to check out. Or try out better weather monitoring methods and tools on these routes.
Edit : Ok my mistake.On reading again, the article states "Unlike other planes' crews flying through the region, AF447's flight crew has not changed the route to avoid the worst of the storms. ".
1. This is a region that is quite regular with thunderstorms. The captain probably assumed this was like any other storm in this area any other day of the week.
2. This route is at the upperlimit this plane configuration can fly. If they had to reroute they would need to stop and refuel in another country, possibly Spain, Senegal or Morocco. I assume the captain didn't want to do this and soldiered ahead.
indeed, a computer can continue to estimate for a certain amount of time the readings of the lost sensor. You can think of solutions. But its strange to see so many cases of lost planes because of pitot problems.
I don't think the average person realizes that for aircraft pilots ice is a constant worry even in tropical areas of the world.
The temperature drops 1.98C for every 1,000 feet you go up so you can see quite quickly how fast you can enter an area below the freezing point of water.
Icing of the pitot tube and carburetor are a constant worry at least for prop driven aircraft. Right from day one you're taught what to look for signs of carburetor icing and how to correct it. Water in the fuel is probably #3 on the list.
I never got far enough along to learn about wing icing I ran out of money for lessons but really everyday it's ice, ice, ice!
I simply don't undersand (or don't comprehend) how the pilots don't know these things. My knowledge of planes is 4 hours of pilot lessons and watching a few documentaries on the Discovery channel yet I know that pulling the nose up of a plane would stall, that when you get bad readings from instruments you cross-check, and that a frozen pitot tube giving bad airspeed readings is very likely in high-altitude storms.
I even knew about the two modes of the Airbus - because I once watched an episode of "Air Crash Investigation" where the exact same thing as what is described in this accident happen to an earlier flight.
I don't know if I am jumping to judgement, but it sounds like some of these modern pilots aren't really enthusiasts - they are just people who are trained and do their jobs, and do them by the book and then go home (just like bus or taxi drivers).
I agree it's difficult to understand. I think a combination of confusion, distrust in the instruments and and a belief that the airplane would not stall must have contributed.
The PNF acknowledges "alternate law", if he had only made the PF aware of the implications of that, maybe he would have "snapped out of it" and stopped pulling up.
At some point during your training or flying career you'll probably have situations where in hindsight you'll try to understand why you acted a certain way despite knowing better. I've certainly encountered situations like that.
I think most commercial pilots today in a way have to be enthusiasts, or at least start out as one. The job market is simply too uncertain and cost of education so high that you really have like flying to go through with it. But keeping the enthusiasm in a job with a busy schedule and demanding family life might not be so easy. That's one reason why I don't plan on flying for a living.
Surely there must be more to it. Clearly all of us who've played a flight simulator know that going up too fast will cause you to lose speed and eventually stall and fall until you regain enough speed to stabilize.
Sadly in this case it sounds like a mix of overconfidence (not avoiding the storm, trusting the plane more than the stall warnings, not waking up the captain until it was too late) and a lack of training for unexpected situations were the major factors in the crash.
It seems that in the very rare cases where a commercial plane goes down spectacularly, the ones that make it alive were flown by formerly non-commercial pilots (military or otherwise), who've flown planes that give them much less assistance and in much more stressful situations and so "doing the right thing" has almost become second nature to them.
The problem with people is that even if you know what you should be doing in theory, when you're put in an extremely stressful situation you're unlikely to be able to come up with a creative solution... and few situations are more stressful than the moment you realize that something completely unexpected is happening, at night, in a thunderstorm, over the ocean, with 200+ lives depending 100% on your actions.
Interestingly I have not played flight simulators since the 1980's, but I know of overspeed stalls (usually mach tucks) in part from being fascinated about historical engineering, and ran into the issue when looking at WWII aircraft (interestingly the first confirmed incidents of overspeed stalls were with the propeller-driven Lightening aircraft in WWII).
At night, over an ocean, in a storm, with no visibility, in possibly significant turbulance and responsible for the lives of 300 people. I doubt knowledge acquired from an episode of "Air Crash Investigation" is very useful in such a case.
Watching documentaries or looking up stuff on the internet does not make anyone an expert. That Bonin guy, as inexperienced as he was, knows far, far more about piloting airplanes than you do.
Absolutely. You can almost feel the panic they must have experienced, trying to comprehend what was happening, in the dead of night, over the ocean:
"What the hell is happening? I don't understand what's happening."
"Damn it, I don't have control of the plane, I don't have control of the plane at all!"
It's like a non-fiction horror story. Cockpit data recorders provide some really gripping stories. Same with the air traffic control audio from the bird strike incident that ended with a plane landing in the Hudson river in NYC.
The Popular Mechanics account of AF447 leaves out some quotes and doesn't explain their content very clearly, unfortunately, but it appears they were doing that, more or less.
"02:11:37 (Robert) Commandes à gauche!
Left seat taking control!
[...] At any rate, Bonin soon after takes back the controls."
Sometime after 2:12:15: "As the plane approaches 10,000 feet, Robert tries to take back the controls, and pushes forward on the stick, but the plane is in "dual input" mode, and so the system averages his inputs with those of Bonin, who continues to pull back."
"02:13:43 (Robert) [...] À moi les commandes!
[...] Give me the controls!
[...] At any rate, without warning his colleagues, Bonin once again takes back the controls and pulls his side stick all the way back." Next timestamp is 02:14:23 and crash is 02:14:28.
It's not really clear whether Bonin announced his first retaking of controls. I believe protocol would in fact give him formal control if he did, despite his confusion. Robert appears to have been communicating his control correctly but Bonin appears to have been providing input during this time. We'll never know if he didn't realize he was providing input or if he didn't realize someone else was trying to control the plane.
i don't know these people and I'm not a pilot, but is it possible the Bonin wanted to crash the plane? I find it hard to believe that he would continue to pull back on the stick almost the entire time and not 'share' that information, and after Robert took control (by stating 'Give me the controls!'. Just wondering if this is something that would be looked into.
Technically possible but seemingly unlikely. I'm leaning towards Occam's razor here: that would be an awful lot of acting fairly consistent with panicked, unexperienced actions, and if you're a pilot it's not exactly difficult to crash the plane if you want to. Additionally, the decision to fly into the storm wasn't Bonin's, so if he did decide to crash the plane in this manner it would have been a very rapid decision, or a result of pretty specific deliberations like "next time the computer goes into alternate mode and there is confusion and panic in the cockpit I will do it," which again runs against the razor.
What impresses me most in this tragedy is its illustration of the culture of rigorous process to get to the bottom of what happened so that lessons can be learned to make flying safer. Relentlessly followed for decades, in all countries, this culture has made large airliner air travel the safest way to get between two distant places.
The lack of reaction to "Stall!" implies one of two things; either it was broken and the sound didn't play or the complete lack of understanding about what the word "Stall" meant with the pilots. Has either of these been proposed and discussed? The author of this piece doesn't seem to touch on why they ignore "Stall!", unless it's been confirmed the sound had been heard (on the recording maybe?) and they did indeed understand what "Stall" meant as it's "standard" pilot language?
"According to Camilleri, not one of US Airway's 17 Airbus 330s has ever been in alternate law. Therefore, Bonin may have assumed that the stall warning was spurious because he didn't realize that the plane could remove its own restrictions against stalling and, indeed, had done so."
So, here's the problem with this whole normal law / alternate law situation:
If a pilot believes he is in normal law, and wants to ascend above the storm, he'll probably just pull all the way back on the stick, thinking "this will cause the computer to ascend as quickly as it can without stalling".
AAAARGGHH!!!! This maddening concept of normal law is turning the above insanity into the EXPECTED OUTCOME! Having a computer partially ignore your control will always lead to people railing the controls all the way in the direction they want. That's just human nature.
This is just like having someone who was raised on cars with traction control drive on ice for the first time. They'll notice the car isnt accelerating as fast as it normally would, and their natural reaction will be to push the gas pedal down EVEN FURTHER! Bingo - your control system just extracted the exact opposite of rational human behavior. If they didn't have traction control, they would have heard the engine rev and the tires spinning, and they would have backed off of the gas.
If the pilot weren't under the mistaken impression that the computer would limit his input, he would have NEVER pulled the stick all the way back and held it there - he instead would have been very careful to pull the stick back only just enough to ascend safely.
The airline industry may think normal law is a feature. I consider it an abomination
You either give the human full control, or cut their control entirely. You DO NOT give them partially limited control. That only encourages exaggerated inputs.
This is an important point as cars nowadays have more and more electronic overrides - everything from traction control to stability control to anti-lock brakes to lane departure warnings (and recovery) to emergency braking and speed control.
Most of the later ones (emergency braking, speed control, lane departure) are only on expensvie cars, but within 10 years will be standard equipment on all cars. If not by legislation, probably by insurance companies offering discounts on vehicles so equipped.
It's already an issue with ABS braking in that people run into things even though they could steer around them - simply because they become fixated on pressing the brake harder and harder rather than trying to steer the car away from the impending object.
As people learn to drive with these aids and rely on them, they will become dangerous when one or more become faulty. I can see a point where people start to rely on automatic braking and don't bother putting their foot on the brake. Or take their hands off the wheel on the freeway because the car keeps it in the lane for them.
All this is great until something stops - a camera gets a squashed bug, a wheel sensor breaks from a stone, anything. And the car will be under partial human control and the inputs will be badly exaggerated.
This will become a large issue in the design of vehicle interfaces and driver training in years to come. The solution, of course, is mandatory emergency situation training in an unassisted car. But driver training is routinely ignored worldwide for cost reasons.
Getting a drivers licence in Germany costs roughly 2000€ (2673$), assuming you pass theoretical and practical exams on first try. You need to take 14 theoretical lessons at 90 minutes, 2 of them on technical stuff, you need at least 12 practical lessons, 5 outside of a town, 4 on the autobahn, 3 at night and you will need a couple regular lessons just to get started so most people end up with 20 practical lessons or so.
After all that you will have neither training nor experience with emergency situations, in fact you will barely be able to brake a car so that it stops as fast as possible, which the majority of drivers are simply incapable of.
As nice as it would be to have that training, your assumption that you have to add it is fundamentally flawed in that already nobody can manage his car in such a situation with or without assistance. Apart from that most Americans probably consider what Germans have to do to get a driver's license insane, I doubt they would even seriously consider implementing something similar.
I was recently thinking that they should introduce driving simulators as part of the training, in order to expose drivers to dangerous situations like they do with pilots.
Incidentally go-karting is a pretty good way to get some "on the edge" experience. I pretty much passed my (Swiss) driving license on the quality of my braking, which I picked up on a couple of go-kart outings.
In motorcycle racing nowadays the vehicle is governed by the computer to a surprisingly large degree. Yet this has allowed levels of performance thought unachievable not too long ago.
The same technology is now trickling down to street legal sportbikes. It's interesting to watch the public's reaction to it. Some disagree vociferously, saying that it will take the fun out of the hobby. Others acknowledge the life-saving intervention of throttle control when you're leaning in a turn on wet asphalt and mistakenly give it too much gas.
This is not only a case of getting comfortable with electronic help. It is also a case of having experience with the extreme conditions in the first place.
I've seen many people who has driven cars, without traction control, for many years and then experience ice for the first time. When the car doesn't move they press the accelerator or turn the steering wheel even more which is the exact opposite of what you should do.
Very interesting insight. But I think you're both right and wrong.
It's certainly true that computer assistance and correction leads to bad habits. I drive a motorcycle and will never drive one with ABS, because I know from many people that once you have a bike with ABS, the moment you ride one without, you fall, usually in less than half a mile: you're used to stepping furiously on the brakes, and that is quite unforgiving when there is no ABS ;-)
But it's also probably true that computer assistance saved many more lives than it took.
It just shouldn't turn off on its own; or, people should have extensive training with assistance off ("alternate law").
by "ignore" I mean they didn't acknowledge it, they didn't once mention the obnoxious noise and the implications. Even if they believe that they could not stall the plane, would they not mention it as something to consider? Looking back on the account of events through the entire thing from start to finish was little more than 5 minutes, so maybe they didn't have time in the panic to mention it, but it still seems strange to me that at no point did someone ever say "it's stalling!", even when the captain returned he didn't acknowledge either, which just seems so strange.
"We still have the engines! What the hell is happening? I don't understand what's happening." unless this is in reference to the stalling?
As the article mentions, aviation experts are rightly bamboozled by this.
The closest I've come to flying was Chuck Yeager's AFT on the Commodore 64, but even then I knew presence of engine power does not preclude a stall if your pitch is extreme.
Without knowing that Bonin had been pulling-back the whole time, I guess Robert and Dubois were searching for non-obvious reasons (and struggling, with the altered cognition under stress that the article also mentions).
In many cases people do not mention the obvious. If there is a stall alarm blaring, I do not think any pilot would actually say "the stall alarm is on".
So I do not think it too surprising that nobody mentioned stall in conversation. Now about why they did not put the nose down, it seems either that (i) they were both under the impression that the electronic controls would not let them stall; or (ii) from their experience with smaller planes they thought they would be more pronounced shaking and other physical clues when the plane did stall.
Also it seems that they were much more scared of the storm than stalling so they just wanted to escape it.
They don't explicitly state that it is something you can hear in the recording, I made the assumption that the "blackbox" contain not just an audio recording but a log of the computer system -- what actions it took, which is how they know the co-pilot was pulling back the entire time -- and they're basing it off of that. Although the way they phrase it (reading back through the relevant paragraphs now) with the assumption he is referring to it being audible it does read that way. I'll email the author to ask for clarification.
There are two recordings - the 'black box' which records all the control inputs, readings, etc. Then there is the cockpit voice recorder, which is a separate recording of the pilots voices (and radio traffic, IIRC).
I don't know if the two separate items are in the same 'box' or if they are physically separate, but there are definitely two different things being recorded.
Which the pilot and co- don't know to trust as the altimeter and other instruments are giving false readings (listen to that recording, it's all due to the instruments being taped over by ground crew and the pilots missing it on pre-flight checks).
If you've determined that the stall warning is false I imagine it's hard then to back out and stop filtering that noise out; particularly when you're concentrating very hard on something else. Someone mentioned a case where the pilots crashed because they were attending to a landing gear problem and so missed the lack of fuel.
I wonder how men/women differ in these pressure situations too. IME women generally appear to handle multi-tasking and interrupts better than men do.
The Invisible Gorilla by Christopher Chabris and Daniel Simons tries to answer this question. These guys made the video where people are supposed to count the number of basketball passes (I won't say what's actually in the video in case you haven't already seen it).
The pilots were likely afflicted by a form of inattentional blindness. Their brains certainly heard the stall warnings, but they were filtering them out so that they could focus on "the important stuff." People do stuff like this all the time, like crash their cars into motorcycles because they were so preoccupied looking for oncoming automobiles (not bikes).
Forgive my ignorance, maybe some pilots can shed some light on this. In the article it mentions that even though the plane was flying in "alternate" mode, my understanding is that it still has limits to what inputs can be given.
That said, even if autopilot is off, why wouldn't the computer have emergency functions to negate strange situations like this? When would pulling completely back on the stick while losing altitude rapidly ever be considered within the range of normal?
why wouldn't the computer have emergency functions to negate strange situations like this?
I think there are two main reasons. First, one is dealing with a situation where the autopilot has disengaged because it is receiving contradictory input from its sensors. How is the computer to know that a second sensor has not failed, and that its notion of what is normal is not? Failures may tend to cluster. The current technological presumption is that in the event of something unexpected, trust the human over the computer. At the current level of technology, this is still often a good bet.
Second, I think the legal situation encourages having a human be the final point of control. Presume that computer overrode the human, and that due to some low-probability unexpected combination of failures this caused the plane to crash despite the pilot doing "the right thing" as proven by the flight recorder. Then picture the size of the lawsuit against the everyone involved in the building and licensing of the plane. Contrast this with the same situation, but with the pilot responsible and dead in the crash. One may find that there isn't much desire from the manufacturer to change the system to take that final responsibility.
There is a famous incident with an A330 test flight where the auto pilot system happily flew into the ground precisely because, unlike Bonin, it did not panic and give in to the instinct to pull the nose back up.
I'm guessing this incident made the engineers who designed the plane a little more eager to provide for a true unhampered manual override.
> When would pulling completely back on the stick while losing altitude rapidly ever be considered within the range of normal?
I don't have a terribly accurate model of airplane control in my mind, but I think this would be the right answer when the nose is pointed down (i.e., the plane is diving). In some cases I think it might also be the right answer if your nose is level but you're losing altitude, e.g. when in a strong downdraft.
Pulling back was the wrong thing in this situation because the plane was in stall, but due to sensor problems and later high angle of attack/low airspeed, the avionics didn't have a complete image and an absolute certainty that the plane was in a stall (hence the stall warnings cutting in and out, too). I'm not sure I'd want the plane overriding me in this specific case.
Hmmm, lovely reading on a day I am due to fly with Air France across the globe!
It is easy to blame Bonin for being such an idiot and pulling on the stick all the time but it is a natural reaction, just like inexperienced drivers continuing to lock the brakes while skidding off the road. How many die that way every day?
More worrying to me is that the whole plane control is inherently and crazily unsafe. Whatever were the designers thinking, making the two sets of controls without cross-feedback and even 'averaging their inputs' ?!? Whatever were they thinking introducing flabby delays between stick movements and control surfaces? Ever tried to play a computer game with a two seconds delay of the controls?
The actual cause of the crash is this. There were three pilots trying to fly that plane at the same time: the computer, plus the two co-pilots. I guess four, if you include the captain chiming in from the back. Neither of them had any information or understanding or confidence about what the others were doing, due to no particular fault of their own. In such circumstances, adding and withdrawing auto-pilots, plus adding different 'computer modes' is totally insane and only adds to the confusion.
At least you can find some comfort in that AF447 was the first fatal accident with the type, and that there's been continuous improvement throughout the years (including replaced pitot probes). But bigger design problems might have gone unadressed because it's difficult to justify a major change in a certified design until it causes an accident.
Very insightful. Indeed it seems that one of the main contributor was the copilot's attitude (at least one of them, pulling back on the joystick all the way)
02:13:40 (Bonin) Mais je suis à fond à cabrer depuis tout à l'heure!
Obviously they were in panic mode and did not take time to think - they were reacting to the "plane go down" message by a "pull back" mode, where they should have been trying to understand why they were losing altitude.
That was terrifying. The commentary lends itself to second-guessing, but anything that distances you from what's going on (e.g. controls without tactile feedback) is generally a bad idea. Addressing it with extra procedures adds complexity, which is problematic in itself.
Panic seems to be so debilitating in situations like this as stress severely diminishes to ability to think.
Is it worth considering making certain fast acting drugs available to professionals that operate in life-threatening environments that would stop or minimize the stress response?
I'm not sure if such a drug exists, one that might reduce stress but not also impair other cognitive functions. But it might well be extremely useful. I can't think of any situations where the stress response is useful in a complex environment.
Well, there are things like beta-blockers (https://en.wikipedia.org/wiki/Beta_blocker), but the thing about emergencies is that they're fast enough that there's not time to pop some pills, much less wait for them to be digested & metabolized & take effect. The whole OP covers, what, 15 minutes it said? The only way beta-blockers might help is if one took them in advance, and they're not perfect side-effect-wise.
Interesting. Things like cocaine (I'm led to believe) act very quickly. I was even thinking that the placebo effect could be leveraged somehow. Perhaps popping a pill that resides in your top pocket could be a first response whenever a situation starts getting a little hairy.
I honestly think it's worth investigating. Why put up with having your stress response decimate your cognitive abilities, especially when you need them most?
Our bodies are horrible when it comes to spatial awareness.
Pilots are trained to ignore sensory input like the feel of gravity, the feel of being in a dive/climb/bank and use the instruments to make determinations about what the aircraft is doing. Usually those feelings are dead wrong.
It's amazing how flying into a cloud bank, even though you've been flying straight and level, suddenly your body screams at you that you're in a descending bank or something. You just learn to disregard those senses and trust the instruments.
As far as looking out the window, it was cloudy, at night, and at high altitude. At high altitude in straight and level flight your nose is pointed at blue sky, not the visual horizon.
There is an unstable mode in some aircraft (maybe only small aircraft?) where it enters into a kind of spiral dive. When you are sat in a plane where that is happening (I have done this in a training exercise) you really cannot feel anything unusual at first - the forces you experience from the different accelerations cancel out. Until all of a sudden you do feel it - at that point you are pitched with the wings at about 45 degrees and the nose pointing about 45 degrees towards the ground. Suddenly you feel it a lot. That is a very scary experience, and one of the reasons to ignore your body if you are a pilot.
When I experienced it it was in clear skies, so it would be rather obvious that it was happening just by looking out of the window, but apparently this can happen to inexperienced pilots in clouds.
when instruments were first introduced to planes, most people thought that something caused all instruments to malfunction like crazy as soon as they entered clouds due to the ghost spatial effects the pilots assumed were true ("I can't be turning, I feel like I'm going in a straight line!" or "I can't be going straight, I feel like I'm turning").
If I remember correctly, the average lifetime of a non-instrument trained pilot in instrument only conditions is measured in seconds, because these ghosting effects are so strong.
Unfortunately, no. They could not look out the window because it was dark and they were in the middle of a storm. I doubt the sky looked much different IN the clouds as opposed to 10 ft above the ocean. Presumably, it would also be too dark and stormy to see the ocean even if they were right above it.
In the dark, in a storm, you have no reference points. In a moving plane, your reference frame is further confusing. There are stories of pilots making a nice, 1-g bank turning the craft upside down and not noticing until it was too late due to white-out conditions. Gravity is only one of the forces acting on the pilots' bodies.
I'm no pilot, and I haven't read the long discussion here, but I can't see how the pilots can be blamed. That Airbus has nonsensical design. Asynchronous sticks, so the other one in the seat couldn't see the other stick being pulled back? Then averaging of the async controls, allowing one stick to work against the other? As for "alternate law," why was there no alarm like the Stall warning to repeatedly tell those in the cockpit that controls were now in Manual Override? Who thought any of that was a good idea? It was bad design that doomed that plane, not the humans inside trying to deal with a design that could thwart anyone.
EDIT: Also, I must add that it seems to me just to be able to engage with reality, a bloody string with a weight hanging from the cockpit ceiling would have shown that the airliner was climbing, from the angle it was hanging. Low-tech and it sounds stupid, but with cockpit crew so alienated from physical reality due to computer mediation and no visual cues due to the clouds, it would have immediately shown them what was really happening.
It's been done before. From the excellent article "The Turn":
> Pilots, too, have relied on pendulums. It is said that an airliner inbound to New York in the 1950s lost all its gyroscopes in heavy weather over Block Island. The captain was a wise old man who had risen with the airlines from the earliest airmail days and was approaching retirement. A lesser pilot might have fallen for the trap of intuition. But the captain simply took out his pocket watch, dangled it from its chain, and began to swing it toward the instrument panel. Flying by the pendulum and the compass, he proceeded the length of Long Island in the clouds. After breaking into the clear near the airport, he landed and wished his passengers a good day.
But in this case the pilots didn't even need to do that. Their gyros were working correctly, so they had an artificial horizon right in front of them. The attitude of the plane was known. They even recovered their airspeed indicator after 30s (the second one after a minute)! All that was needed was for the pilot to stop pulling on the stick…
Consider the positive impact of having a weight on a string flailing around in a cockpit when the shit hit the fan. The articificial horizon works on this same principle, but pilots are known to ignore it anyway. The whole point of instrument flying is to se aside your senses and common sense and look at your instruments.
One of the problems was that the plane was unexpectedly stable during the stall so the pilots might have dismissed the stall warnings as disconnected from reality.
I hope to give some light from the point of view of an airbus pilot( a320) also with B737 and MD80 experience.
First of all I must say that is very difficult to judge what happened from outside, there is a rush of adrenalin if some important alarm starts at the cockpit, it becomes worst if you are flying in the middle of the night and turbulence. Problems that would be solved or the solution evident seating at home in front of a computer, become suddenly a mistery or insolvable because you lost an stabilicer or any other physical problem to the plane( it has happened before).
The first obvious mistake is going through the thunderstorm in that lattitudes, I personally know the pilots who where flying in front of them and they took a 200miles reruting to avoid that particular thunderstorm ( as other trafics did).
Then the reaction to the lost of information : as has been said the proper way to react is using thrust power % and pitch positions, there are tables for different flight phases , they are located at the quick reference handbook, but they should be located at an sticker close to the instruments( for inmediate use as speed limits for flaps or landing gear). An automatic help for recovering such a problem would be greate but computers do fail regularly in comercial planes( if web servers that are seating in a room fail imagine something that is suffering high doses of vibration, dirt, humidity changes, temperature changes, you name it) and you there MUST be other options.
When flying that high you are at whats called coffin corner, that is you are so high that the wings will easily enter both high speed buffeting and low speed stall( both will produce a lost of altitude control, you fall but can do nothing to avoid it).
Also the engines don't have enougth thrust( as fighters do) to support the weight of the plane. So the maneuver they performed seemed to don't make sense at all, why would a pilot pull the stick to put the plane deeper in the cofin corner inside a thunderstorm?.
I think the cause is precisely training( and possibly other interface choices made by airbus helped too ), let me explain: there IS a maneuver inside thunderstorms wich is trained a lot AND will make the pilot PULL the sidestick and apply TOGA power, is called windshear( avoidment). Usually windshear is the wind state that you could find near a thunderstorm close to the airport. Is caused by the first descending burst( thunderstorm madurity) hitting the ground (please google it as it is easier to see a picture than explain it). The result is that the big wind speed changes( in seconds) may put the plane suddenly in a stall
situation. Because it happens when you have no altitude left to recover from a stall ( maybe less than 3000 feet or closer than ten miles to the airport), your only possibility is to apply TOGA power and sidestick FULL back( the protections are NOT lost and then the plane takes care of the stall, the pilot takes care of the ground). This maneuver is practiced yearly ( or almost) as one of the most important ones ( with engine fail, traffic avoiding, depresurization), so it is my opinion ( I must say is not shared by many other pilots, many of them say it was the plane or simply don't know) and the simplest cause, that they simply were trying to fight a windshear, after all they were inside a thunderstorm and had to recover the control. That is way they simply couldn't understand ( or even hear the anouncement) why the plane was in stall, because they were folloing the procedure to the point. And procedures are to be followed if you do 't want problems with the plane and the judge( in a posterior investigation)
Also there are problems with the flight controls interface of airbus that have been known from the first a320 accident, and are highly polemic between pilots. Mainly airbus tried to reinvent the wheel at the cockpits,( and the rest of plane systems)in order to save weight. So they removed the link between the pilots controls ( except the rudder-fronwheel ones) and removed the possibility of the throttle levers to move acording to the power possition while in autopilot mode ( as boeing does ), after all only one pilot is taking the controls at a given time right?. But it is wrong, control feedback is fundamental in critical situations and has saved souls in the past. Also knowing the throttle possition at every moment just resting your hand at the levers while they move, gives you an amazing information of how the plane is behaving without having to look at the engine instruments ( there are one mm dots at the indicator showing the virtual "possition" of the levers, or where the thrust is going to move next), or simply overriding the autothrottle with out having to dissengage it. This throttle problem in particular has not caused a serious problem( that I am aware) yet, but give it time... Just imaging an autothrust setting the engines to iddle at 500' and the crew worried about having the runway insight in bad weather. The " don't make me think" principles still apply with airplanes ( and save lives, not only fuel) but airbus doesn't seem to bother too much.
I hope to have clarified a bit the problem from the Point of view of an airline pilot.
Pd. Sorry for all the misspellings, I am writting from my iphone. I'll edit at home.
• Normal operation: Captain and First Officer inputs are algebrically summed.
• Autopilot disconnect pushbutton is used at take-over button.
• Last pilot who depressed and holds take-over button has priority; other
pilot’s inputs ignored.
• Priority annunciation:
- in front of each pilot on glareshield - ECAM message
- audio warning.
• Normal control restored when both buttons are released.
• Jammed sidestick:
- priority automatically latched after 30 seconds
- priority reset by depressing take-over button on previously jammed
There's also a side-stick priority display on each side showing whether the opposite side is using the take-over button.
I heard from fatal command mistakes with pilots an Asian country and now everyone has to speak English. Is this again some stupid patriotism thing (i am German, i know the French attitudes), but i seriously thought to prevent command errors everyone has to speak the international aviation language.
This sounds funny first, but i have read about this in a book i can't recall right now.
Especially asian countries have a extreme passive and submissive language. The receiver is responsible to interpret the language.
In this fatal example, the lower ranked pilot said something like "our altimeter was very fortunate in the past" and what he tried to communicate was "look at the altimeter, we are to low". He was so afraid to speak up to his tired captain that they died. Another change after that incident was to make a new flight team every time.
It's highly version controlled. Changing software versions on a plane usually means changing a lot of hardware too. After removing the boxes from the a/c, they can be returned to the manufacturer and the new software can be installed.
We test it in a ground-based simulator rig with the exact computers that would be on an a/c. If it gets approved, we put it on an airplane and we go fly the plane around a lot to make sure the software works.
A software upgrade almost always means switching out the hardware, because that's one way we ensure conformity.
The pilots, mostly, acted legitatemly based on the flawed and lacking data of which they were presented with.
Initially, the captain's non-fear of the storm was based on incorrect weather data based on a mis-configured radar system. His data seemingly grossly underestimated the severity of the weather: had he had the correct data originally he would almost definitely, like every other pilot in the region, known to avoid the area to which they eventually flew into. As soon as the radar was configured correctly, the pilots banked left to avoid it as best they could. How common a misconfigured radar is and how easily it is done is perhaps the most vital piece of information here. No aircraft should be allowed to fly with such important data being incorrect, ever. This needs to be checked and re-checked far better in future. It is the original link in this fatal chain. It was wrong data, not a wrong human assessment of data, that started off this crash sequence. Given the original radar data, the captain made the right call. And there's nothing obsentibly wrong with him going to take a nap, insofar as that's typical protocol.
Due to flying into the wrong weather-zone, the autopilot turns itself off. And that's that from there. Given that this is such a rare event it's notification is relatively minor within the grand scheme of fear and confusion that one would expect to exist for such an event that so drastically affects flying itself. There exists such a massive difference between autopilot and pilot-driven flying that there needs to be an unignorable physical presentation difference between the two: perhaps gently vibrating the control stick, changing the entire colour of the cabin (to, say, orange) using some LEDs and even changing the posture of a pilot's seat to a more upright position to subtly but distincly make for a different "feel" to computer-led flying. You'd just know based on these indicators alone. Perhaps it'd be harder to mentally block the stall warnings based on the notion that "we can't be stalling, the airliner won't let us" when it feels like you're personally in control of the whole airliner. They didn't just "ignore" the 70+ stall warnings, they completely ignored the very idea that it was possible for them to be stalling at all.
Addressing either of these two issues alone could have helped save AF447. Evaluating the other problems presented, like why two pilots can input vastly different instructions through their joysticks with both being in ignorance of one another clearly needs to be addressed (perhaps even a weighted average towards the more experienced pilot's input rather than a straight up average?); why there existed no clear chain-of-command; why the captain didn't get back quickly enough and how to "force" captains to be quicker; the best way to brief exactly what you've been doing more quickly; and perhaps a new technology that's basically "Clippy" for flying, that could say things like "You're in a stall, consider pointing down?"
This was a tragic mistake that ought not to have happen. Based on so much, let's not so easily condemn the pilots actions to stupidity and instead take a moment to consider the sheer horror they suffered after commanding such a massively complex machine in such challenging conditions with so much noise, lights and general "WTF"-ness.
Consider that environment the next time you get frustrated investigating a non-obviousl compile error in your quiet, air-conditioned, well-lit office.
If it hasn't already been discussed, could someone explain the rationale for not making the control sticks mirror each other? I know it's an artifact of old, mechanical linkages, but when two people need to be aware of the control inputs at any given time, why not relay that information by manipulating the controls to match the inputs?
If you want to get into root cause analysis, it sounds like the incorrect radar setting got them in the situation in the first place. Obviously the way the pilots dealt with that situation from then on was suboptimal, but avoiding situations where there is a chance for bad decision making is also important.
It is just me or does it sound like the simplest solution would be to have both controls react and mirror each others input, if this was done (like the older control yokes) there would've been an understanding much sooner that the co-pilot was keeping the stick back.
What really intrigues me is the fact that the captain didn't take control of the plane after returning from his nap. If a respected pilot with 11,000 flying hours to his credit made that mistake, I can't imagine what his mind must have gone through during that time.
That Bonin guy was so out of his depth, he should've been thrown out of the cockpit, then again the captain was just too laissez-faire. Bonin should've deferred as soon as captain told him to fly into the storm. Instead he chose to be Manuel from Fawlty Towers.
Unless you empathize with mistakes like this, it's very difficult to prevent them in the future. You're always going to have people who make mistakes in any system you design. The trick is to design the system so that mistakes are easily corrected, even when multiple ones are compounded.
It's akin to someone dropping a table of unrecoverable user data. Sure, it was dumb on their part, but why the hell is it possible for you to lose all your data from a single mistake?
The problem was Panic. In a panic situation humans revert back to a time when we need to run away from the bear that is chasing us in the woods. To fix this, I propose a "panic awareness system", where the machine says: "Don't panic". and tells the pilots to take some anti-panic medicine.
way too easy for you to say without being in the situation.
heavy turbulence, no visibility, confusing situation, very likely that he was disoriented, operating a very complex set of computer programs hooked up to a very complex set of physical controls that have a myriad of potential configurations and points of failure while trying to debug it at the same time in a panic and making quick decisions.
from his vantage point, it is likely that the stall warning is a symptom of something malfunctioning and not an actual stall.
that said, i thought that "if stall, you push forward" was instilled into pilots to the point of 2nd nature. i'm very surprised at the reaction to the stall warning.
The not pushing forward while stalling really does say to me by the time they thought to analyze the situation, they were in a state of absolute panic. I would be curious to know if any of the flight crew were military trained, or if all came from a civilian flight instruction background?
Exactly.But how do you do what is right (push forward - which is go down) when all your instincts tell you want up (pull)?
This is the same as driving a car in a rally. Drivers there know to drive into the slippage to recover control. But if you're a normal driver you'll do exactly the opposite.
My question is - do they train enough to break their instinct?
This is a lot more akin to a sober driver with a car that constantly blinks "service" and not realizing that they're stepping on the gas instead of the brakes, and it's not pedals, but a joystick, and it's a blizzard, and you can't feel simply by inertia which which direction you're going.
They did not have enough training in such situations. The captain seemed more competent, but he was not on the controls to do the right thing.
It's the same situation when untrained people drive cars to their limit. If the car slips then you should slightly steer in the direction of the slippage which is most of the time opposite to where the road turns. If you're not trained to do that you won't do it.
That too. I just saw a BBC video about this incident and a pilot was saying exactly that - that the pilots should know who is in control and he should pilot the plane to the safety.
But I was thinking about training more in another sense. If your instinct tells you to do something that is opposite of the right thing than you should receive more training to brake your instinct.
In this case the right thing to do was probably to push the nose down to gain speed. But if your instinct tells you that going down is not the right thing you won't do it. You should make a concious decision and you are not in the position to do that without prior exposure to the situation.