Hacker News new | past | comments | ask | show | jobs | submit login
What really happened aboard Air France 447 (popularmechanics.com)
858 points by fr0sty on Dec 8, 2011 | hide | past | favorite | 365 comments

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.

The new planes should have a way to emulate that.

I was shocked that new airplanes use joysticks are just simple inputs and don't give (some) feedback on the current state of the current control surfaces or the state of the other joystick.

This seems like a "feature" of analog controls that you'd want to take forward to fly-by-wire systems.

For me the 'averaging' of two controls seem totally bizarre. One pushing forward and one pulling back and the computer thought that was OK?

My fear of flying is reaching new heights.

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.

- Delineate command better, e.g. Captain, Co-pilot #1, Co-pilot #2 so that who is in charge is clear.

This antiquated idea has killed many more people than it would have saved in this case. Read about CRM:


I think a classic example is:


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.

An additional case that I know about, the Tenerife airport disaster: http://en.wikipedia.org/wiki/Tenerife_airport_disaster


  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.

Two options.... 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.

What happens if they're fighting each other?

Then they have to fight! You can't delegate responsibility to the "system" to resolve such a fight. A fight is a fight. And if it's happening, you can't automagically get rid of the fight.

At least there's feedback, and you can immediately see what's happening! In the current configuration, Bonin's stick inputs were nearly unknowable to the other officer.

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.

I think you'd still do better to have a manual selection of which input is commanding, with an option of having both sticks linked and moving together.

Deliberate selection of inputs would be best. Maybe a switch in the middle that both selects and displays which input is active?

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?

I was also really surprised about this after reading the article. I look around to know a bit more about the Airbus design and arrived at this [article](http://msquair.wordpress.com/2011/09/16/pilots-in-the-loop-a...). The problem is not that they are averaged, but it seems to be that they are not coupled.

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

I found that really bizarre as well. It's also troubling to me that the sticks don't move in concert. That seems like an excellent mode of communicating what the other pilot is doing.

Exactly. I fail to see any benefit to removing feedback on how the plane is actually contolled at any given moment.

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

You can display so much information before you add to confusion in a high stress situation. Haptic feed back could be useful.

Yes. Or some kind of haptic connection

Like one stick moving the other...

I think the simplest solution to the mismatched stick issue is to use servo motors to replicate the old situation--the movement of each stick mirrors the movements of the other.

A pilot wouldn't have to look for some stick position display, or indicator light, if they can easily feel the deflection of the stick.

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.

The linked article said that Boeing indeed to behave this way, and frankly I am not boarding ANY Airbus flights in the future.

Motors can fail.

Use mechanical feedback. Not necessarily rigid connection, but at least some kind of elastic coupling or something. Or, heck, connect them rigidly.

> "This can't be happening!"

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.

His statement was made out of exasperation 4 seconds before he died. There is very little he could have done to change his fate at that point.

Still an indication of bad mental habits. And it doesn't strike me as out of line with his actions (complete disregard of the empirical information he had) the minutes before.

This one feature may have prevented the crash.

A indicator light, saying the plan is in "alternate law" mode, and SHIT can go wrong, very quickly.

Also an alarm in the pilot resting area that would relay when warnings are detected like stall or switching to alternate law.

At least one of them realized it, but not the one flying. From http://www.bea.aero/en/enquetes/flight.af.447/transcript29ju... :

"At 2h10.16 seconds, the pilot in the left seat, the pilot not flying, says “we have lost the speeds” then “alternate law”"

Okay. This is how the cockpit apparently looks: http://www.pbase.com/image/47231836

Where are you going to stick the indicator light so that it's impossible to ignore it or mistake it for something else.

Some ideas:

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.

> Illuminate the pilot's footwells with a bright red light

Might interfere with normal/night vision.

Make it a loud, repeated aural indication. Oh wait, the stall warning was just that and got completely ignored...

I think we've discovered the most difficult UX design task on earth.

You know that Don Norman's insights come, in large part, from investigating nuclear reactor controls (Three Mile Island) and air crash investigations.

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.

yes, and I'm not sure under what situation a 'democratic' dual-input mode is a good idea!

Maybe everyone on the plane could have one!

Having multiple joysticks that can be in different positions at the same time and yet all simultaneously affect the flight of the Airbus is a serious design flaw.

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?

Precisely.. I'd also like to know under what circumstances this would actually be used, and be a useful safety feature to have implemented.

At the very least, there should be a significant warning in the cockpit when "dual input" mode is active. That is an incredibly dangerous "feature."

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

I utterly agree on reducing continuous and loud sound warnings in the cabin.

This 1996 757 Aeroperu crash recording is quite scary: http://www.youtube.com/watch?v=G5QSBlYTJ1Y

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.

I really appreciate that recording because it helps empathize with exactly how disturbing it would be to be in that situation.

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

Yeah, I don't know about the a/c in question; however, the Colgan crash was a result of the pilot fighting the stick pusher and winning. The stick pusher is not easy to override.

It seems counter intuitive to nose down when you're falling out of the sky, but it's how you recover.


If one were to apply principles of Tao, it would be to yield. Give the stick pusher nothing to push.

      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.

It does seem like that happens. Wikipedia links to a few incidents involving the stick pusher:


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.

Messages are prioritized on the screens in the cockpit in any aircraft I've ever seen. Higher priority messages are near the top and are a different color.

There are lots of messages because lots of things can go wrong with an aircraft. They aren't all critical "land now" messages, but may be relevant.

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.

Try writing the code for an autopilot some time. It's hard. We spend a lot of time flight testing just the autopilot.

Making something go in a particular direction at a particular altitude at a particular speed is hard enough. Throw in a stall and the best the plane can do is try to nose down.

Well not at 400' and 130knots... That is way they were performing a windshear maneuver ( incorrectly) at FL 340.

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?

I double checked, AOA sensors are weather-vane type systems.

AoA sensors are separate from pitot tubes and in every schematic I have seen located on the exterior of the aircraft, so I believe the measurement is direct.

> The voice should demonstrate increased tension and panic as counting down.

This part doesn't sound so useful, in a cockpit with worried pilots.

>how does a plane know it's stalling if the pitot tubes are frozen?

I think it can easily do that by measuring the G force similar to an accelerometer on iPhone.

No. There is, not surprisingly, another sensor in the airflow for that.


Accelerometers measure acceleration. You won't feel any unusual G forces for any constant velocity, whether it's climbing or descending.

Yes you're right...Stall is not a free fall but a sudden reduction in lift which can occur for instance when the angle of attack increases beyond a certain value.

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.


Uncle (in-law) pretty much says the same thing.

Well ask your dad about landing in short runways during a thunderstorm with strong gusting cross winds + contaminated runway. If he didn't have a rush with that...

Surely he's been in exciting situations in simulators, at least? (And if not, he probably should arrange for some simulated excitement :)

oh yeah...

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.

and stop calling me surely.

Training in a flight simulator is an entirely different thing... altogether!

It's "Stop calling me Shirley" :)

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

Anyone have any insight into this?

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.

See the following link for more info: http://msquair.wordpress.com/2011/09/16/pilots-in-the-loop-a...

Should not one pilot say "I Got Her" and tell other pilot that you do nothing, I will take care of it.

That happened in the main article, but the pilot in error takes control back shortly after.

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.

According to the article, the input from the two joysticks is averaged.

Which raises a very good question, when would you ever want that joystick behaviour?

This is a fantastic question. I can think of no situation where this behavior would be desireable, but then again IANAP

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.

Was really shocked to read the article.

It does: there's an audible warning that says the words "DUAL INPUT"

The English translation of the BEA's third interim report on the flight is available here: http://www.bea.aero/docspa/2009/f-cp090601e3.en/pdf/f-cp0906...

It includes the full CVR transcript at the end, which shows that the dual input alarm activated five times.

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?

Then link the sticks mechanically.

Still, if the panicky guy is unconsciously trying to out-muscle you, well, then you reach over and punch him in the face.

If even that fails... uh... I guess you're in deep deep doo-doo at that point.

... so if there was a noise (intercom, radio, talking etc) and you didn't hear the announcement, that's it ,game over.

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.

Same experience. Pre-flight briefing with instructor: "When I say 'I have the plane', do NOT fly the plane".

But then again, that's a VFR flight in decent weather. I'd imagine it's a bit easier to get stressed in the middle of the night in a storm over the Atlantic with electrical failures.

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.

Wouldn't be surprised if that's one of the outcomes of this - you'll still have the ability to override the other stick, but you'll know you're overriding.

I'm a pilot and that seems insane.

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.

good point - but I think a 'dual input' mode is the wrong solution to that problem.

Simply is the cheapest when you want to go all digital.

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.

perhaps have the plane decide which input seems more rational, then announce who has control.

Sounds like a great way to further mess up an emergency by making it harder for people to figure out the impacts of their actions on the situation.

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,[0] 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.

0. http://en.wikipedia.org/wiki/United_Airlines_Flight_173

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)

vs • 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.

You might be thinking of his book "Outliers", which dedicates a large segment to plane crashes.

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.

Except that steering in the direction of the slippage may not be the correct action at all, at least in some vehicles. http://www.oregon.gov/OSP/PATROL/safety_tip_slide_control.sh...

It indeed depends on how the car slips. What is different is the amount you do throttle, braking and steering but the response is so counter-intuitive that you need proper training to do it correctly.

The correct course of action is to declutch so that the wheels get back in sync with the road. Of course, you cannot do that on an automatic car.

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 do wonder if passengers knew what was happening. Many might have been asleep. It sounds like there was a fair bit of turbulence on.

It looks like from the report that none of the cabin crew raised any concerns, so I'm wondering if people were pretty much oblivious and they went quickly.

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.

I couldn't actually bring myself to click to page 2.

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.

What's missing from this article is the fact that the Captain chose to fly right into the storm, saying "on va pas se laisser emmerder par des cunimbs" (in essence: "fuck this storm")


This is incredible hubris.

Then, in the middle of the storm he leaves the two copilots alone, one of them quite inexperienced, and goes for a nap. He's obviously trying to demonstrate that he's not afraid of anything.

Well, maybe he was fearless, but now he's dead and so are all the passengers, passengers he was in charge of.

- - -

Once in the storm, and with the incredible amount of stress, it's hard to say if other pilots would have done better (other pilots that night avoided the storm!)

I've read that pilots are trained to react to a stall at the beginning of their career, but not as part of their regular training -- I don't know if it's true or not.

What's true is that stall is one of the worst things that can happen; it's like training bus drivers to hit the brakes when they're going right into a wall: of course they would do that...

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.

References: [1] Page 45, http://www.bea.aero/docspa/2009/f-cp090601e3.en/pdf/f-cp0906... [2] Page 88, Ibid.

Of course Bonin knew that the autopilot was off. I don't think that's the same as being in alternate law.

What boggles my mind is that pilots are being trained in anything less than every mode an aircraft operates on.

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.

There's a school of thought that says that user interfaces should be modeless, I wonder if the concept of a mode here is a fault in the design of the HCI as well as insufficient training?

Oh no ... we are NOT turning this into another Vi vs Emacs flamefest


Actually the normal vs alternate law thing might be a mode to build into the displays. I am usually a modeless fan and a VIM user, but this is an exception ;-)

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.

I was thinking of the Qantas and Malaysian Airlines mishaps where faulty ADIRU's lead to sudden uncommanded changes in altitude and eventual stall warnings.

Is it possible that the warning speaker was broken? It's odd that none of the pilots would even acknowledge it. Or does the recorder record the stall warning noise too?

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

Yes, maybe a combination of shock, confusion or distrust in the instruments was a factor. It will be interesting to see what the human factors group of the investigation comes up with.

I'm sure that the flight training will also be investigated, there has been concerns that improper stall recovery technique is being taught by some instructors: http://www.caa.co.uk/docs/33/012010.pdf

(And of course, in planes that are not certified for stalls, you can't really practice full stalls and have to train on approach to stalls instead.)

(And of course, in planes that are not certified for stalls, you can't really practice full stalls and have to train on approach to stalls instead.)

Of course, very little airliner training happens outside a simulator, which can you can stall without damaging anything.

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.

No, what I mean is - tase them when they "crash" in the simulator, not when they stall.

A simulator "crash" is not nearly significant enough to their reptilian brain. Their neocortex may register it as a failure, but for the reptilian brain is just a big nothing.

Adding some physical jolt may drive the lesson deeper in their psyche, that a crash really is a bad thing.

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.

Well, you can turn off the shocks for training days when they are practising stall recovery, but leave on the shocks for regular situations.

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?

This clearly looks like an anomaly that the plane should detect and correct. Or at least announce somehow. The computer should average only when controls are consistent with each other.

You never know what's the time when you have two clocks.

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.

the other similar incidents are Birgenair Flight 301, where the pitot tubes were blocked because of insect nests, resulting in pilot confusion:


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:


With these similar incidents you would think that air crews would have learnt from these disasters. If you read the reports on those two accidents, the similarities to the AF disaster are remarkable.

Considering how many incidents there seems to be due to the loss of these airspeed sensors it seems crazy not to have an additional, different method of calculating airspeed.

Is there a reason GPS is not suitable here?

GPS gives you speed relative to the ground, not speed relative to the air, which is what's important for aerodynamics.

Yes, but when groundspeed with a slight lag is all that's available is it really that much worse than nothing, which seems to be the failure mode at present?

I stress I'm not a pilot and I'm sure you'd want to have a Big Flashing Warning Light telling you that ground speed <> air speed, but there'd seem to be some benefit over nothing at all.

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

149 kts occurs daily -- at altitude.

For example the current winds aloft forecast for BML shows 155 kts at 30,000 feet:


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.

(asking here because your other reply is nested too deeply)

> The margin between stall and overspeed is something like 20 knots at that altitude.

Whaaa? I thought aircraft have a much wider margin.

How does it change with altitude?

If the margin is so low, then wouldn't a sudden wind gust simply knock the plane off the sky?


(Perhaps a better explanation than the article: http://de.wikipedia.org/wiki/Datei:CoffinCorner.png)

And to answer your question about wind gusts: yes. That is why you don't fly into thunderstorms.

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

GPS gives you ground speed. Airspeed is a different thing -- imagine if you're flying into a strong headwind.

It can't give you the relative speed of the air around the aircraft.

Given the speed at which the readings in my android phone update while driving a car, I'd say yes.

let alone we forget losing a B2 bomber during take off for similar reasons.


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

Making a computer that can fly without airspeed makes less sense to me than making an airspeed sensor that either doesn't ice, or can de-ice itself. Is that so impossible?

Supposedly they do de-ice themselves, but that obv didn't work properly here.

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.

Ah, I was not aware they already could. My next question is why not make themselves de-ice better?

This maybe seems trollish or silly, but in all seriousness, if your sensors aren't good enough, first rule out improving the sensors before you try to compensate with the system.

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?

There is other debris that can clog pitot tubes. Birgenair Flight 301 crashed because some wasps built a nest in a pitot tube during an extended layover:


189 people died.

(Also note the failure to react properly to the stall warnings. This comes up again and again.)

I wonder if in a couple of decades we'll look back at pitot tubes and wonder what the hell we were thinking using such a fragile solution.

(Of course, in a couple of decades we'll probably have a much more accurate external method of finding out speed/airspeed.)

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 real WTF is that planes are kept aloft by aerodynamics. One day we'll look upon that the way nowadays we think of zeppelins.

Being restricted to rich people with "fuck the planet" attitude, hopefully the jet airliner market will be small enough to stall technologically.

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.

I agree. I know little about aviation, but wouldn't it be better if the sensors would automatically de-ice themselves rather than only being de-iced at the pilots' command?

I believe they're continually heated.

At least every one I've seen is labeled "heated probe" or the like which probably wouldn't be necessary if they had to be manually de-iced.


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.

as far as I understand, "stall protection" is a feature of the autopilot knowing its current airspeed.

you can drive down the road without hitting things, right? what if you're blind?

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!

Almost all of this is in the article, and what isn't, takes some parsing to sort out. I would have found those bits of color more helpful if the additional info was related alone.

> without valid airspeed there's a risk of overspeed which can cause a new set of problems

What problems specifically?

> Nobody believed a passenger aircraft would be so stable during a full stall.

What was the plane "supposed" to do during the stall? If you're inside the plane, how does it feel when the plane has stalled?

> What problems specifically?

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.

Not all planes are stable in a full stall, some lose longitudinal stability and will be almost impossible to keep level.

Oh sure but most passenger planes are pretty docile a stall.

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

Not changing course like almost all other flight that night was their first mistake.

I noticed that the article suggested their weather radar was incorrectly set up, so that might be their first mistake.

They should have pay extra attention to the weather since this region of the globe is prone to the worst storm. They even aknowledge it in the recording.

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.

You simply don't fly through a thunderstorm, as you simply don't drive through A concrete wall at 100mph. No matter how short you are on fuel.

That was the first thing I noted in reading this.

Is there any discussion as to why they didn't seek an alternate plan and if not, is this something that needs to or has been remedied?

> Is there any discussion as to why they didn't seek an alternate plan

The Captain chose not to, because he "wasn't afraid of clouds" (see my comment above). This was a huge mistake.

But Captains are in charge of their route and it makes sense; it would be incredibly bureaucratic and dangerous if routes were decided from a central command somewhere at the airline headquarters...

What we need are humble pilots; there should be psychological evaluation to weed out those who think they are John Wayne hunting down Indians.

Part of the difficulty is that the job attracts daredevils -- among others: that night, all other Captains went around the storm...

Would the weather radar not being set up correctly have played a part in the reasoning of the captain?

I can't find any reference of Bonin having glider ("vol à voile" in French) experience, do you have a source? I see many blog entries asserting that if he did it would never have happened...

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 never got far enough along to learn about wing icing I ran out of money for lessons

Hey, me too! (And 9/11 happened which made it a lot harder for foreigners to fly.)

But I did have the opportunity to get a lesson in how to avoid carb icing without carb heat when I pulled the carb heat control straight out of the dash on our 152. ;-)

I'm not surprised most of the 152s are probably from the 1970s and are used constantly for training it's amazing the last even with strict control of inspections and repairs.

I learned on a Cessna 152 too but one day we had to use a 172 it was like a Cadillac compared to the 152.

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.

I was thinking about that after reading the report. From our perspective it might be obvious, but we can't put ourselves into that situation.

I wonder if civillian pilots can be trained in the same way as military pilots to handle stresses in emergencies and to think clearly. Or to at least learn something from military techniques

Yeah I'm curious about that too.

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.

  That Bonin guy, as inexperienced as he was, knows far,
  far more about piloting airplanes than you do.
Not anymore.

ye no shit, and I am thinking through how the situation gets to a point where he can forget all that and keep pulling the stick back up

He panicked. What's there not to understand?

how about why do people who have been thoroughly trained and have spent thousands of hours at the control suddenly forget everything they know in an emergency?

I am pretty certain that when the full report here is released it won't stop at 'he panicked' and that this accident will have ramifications for the entire industry

Things can tend to go out the window when you are going through high stress.

>> 02:14:23 (Robert) Putain, on va taper... C'est pas vrai! Damn it, we're going to crash... This can't be happening!

What a frightening moment. I can only imagine what was going through his head at that moment.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact