To be fair, ignoring user input could have potentially have saved Air France 447... I mean I actually can't think of an automated fool proof system that would've fixed 447, but incorrect input was a major factor.
IIRC, the cockpit voice recording included a comment from one of the co-pilots about how pulling back on the yoke couldn't cause a stall. The assumption was that the Airbus's fly-by-wire system would prevent it and ensure the aircraft still climbed as long as the pilot held back on the stick.
The co-pilot apparently didn't realize that the sensor issue that disabled the autopilot also disabled the stall prevention. And that's despite an audible "STALL" warning being repeated in the background.
The captain was not in the cockpit when the whole situation started, but as he re-entered the cockpit during the stall he saw one of the co-pilots holding back on the yoke and told him to push the yoke forward to prevent the stall. The co-pilot followed the instructions, but only for a few seconds before pulling the yoke back again.
All of this is to say if the plane hadn't been known to ignore user inputs in most situations, the co-pilot might not have assumed the Airbus would do the right thing and climb no matter what when pulling back on the yoke. So in a sense, never ignoring user inputs might have also saved Air France 447.
Apparently (think I read in the Langewiesche feature) the plane ended up in such a deep stall that the flight control software started ignoring the AoA sensor data (as implausible) and the STALL warning stopped. But when the co-pilot stopped pulling back on the stick, the AoA decreased, and the STALL warning sounded again.
This might have convinced him that easing off on the stick was actually causing the stall, which was tragically misguided.
Exactly - the computer had switched contexts, but the pilot hadn't. And expecting pilots to switch their mental map of expected behaviour when the computer does (and did so with, from the accounts I read, very minimal indication that it had done so) during a high stress situation, is asking for trouble.
This is my number one objection to over-reliance on automation.
Every piece of software is a mechanism. In order to truly be able to safely use something without outside aid, one must have a complete mental map of the mechanics of the system in question. Abstraction helps; but not when you start getting into high-risk contexts.
The copilot pulling the yoke back continued to do so, long after the other, much more experienced, copilot had formally assumed control and had attempted to bring the nose back down by pushing the yoke forward. Ultimately the inexperienced copilot fighting against his more experienced superior was what doomed the airplane. Both the senior copilot and the captain immediately identified the problem and attempted to take the correct action.
This is not a problem with how the system works, since this behaviour is explicitely communicated to pilots. It even says right on the instrument panel what control law the plane is in. There are only a handful of control laws and the differences aren't that complex. Anyone with sufficient experience in flying Airbus products knows this.
I don't know a whole lot about this, but I seem to remember that there was one design decision, that, while not wrong, was different from the generation before, and that is that the airplane yokes were not mechanically coupled to one another. If they were mechanically coupled, the experienced pilot could have felt the other pilot pulling back on the controls, but what was happening was that the two pilots were pulling the controls in different directions AND the plane was averaging the control inputs and giving no feedback to the pilots that what each was doing was wildly inconsistent or contradictory.
>The copilot pulling the yoke back continued to do so, long after the other, much more experienced, copilot had formally assumed control and had attempted to bring the nose back down by pushing the yoke forward.
At least according to the official accident report, neither of the pilots at the controls consistently made nose down stick inputs.
Basic rudimentary 'stick and rudder' flying skills was a big factor in AF447's crash. All old school pilots know that when you aircraft is in a nose high stall condition, you never keep pulling back on the stick, but instead push it forwards to lower the nose and get the wings flying again.
The fact that the co-pilot in question kept holding the stick to the back stops was the main reason that the aircraft wallowed into the sea. Weirdly, he did let go of the stick for a brief few seconds, which was the only time during the harrowing descent that the aircraft started to behave normally, but then he pulled it back and held it back right up until impact.
Yep, the aircraft could have ignored these inputs, but the inputs are counter to what any reasonably skilled pilot would have done. (Note: Different to the MAX crashes where pulling back on the stick under speed IS the accepted way to stop a descent.)
Part of the issue may have been that the plane had slowed down so much that the stall warning stopped (it disengages below a certain airspeed apparently). When he stopped pulling up, the plane sped up and the stall warning started again. Pull up again, plane slows down, stall warning stops.
I wonder if something about this system was changed after that incident - why not keep sounding the stall alarm if the plane ends up outside the flight/sensor envelope? Can’t you assume that it didn’t magically cross the stall zone back into normal flight?
Basic rudimentary 'stick and rudder' flying skills was a big factor in AF447's crash. All old school pilots know that when you aircraft is in a nose high stall condition, you never keep pulling back on the stick, but instead push it forwards to lower the nose and get the wings flying again.
Except on an Airbus. If the plane is in "normal law", it won't go into a stall condition. Here's the Airbus training video.[1] Note, by the way, that the automatic recovery includes going to full throttle. The throttle levers don't move, though. Unlike Boeing, where the levers are moved by the computers and the pilot can overpower that. In the 737 Max, though, it's worse, because the engines are mounted too high and full thrust pushes the nose down. So "full power and back off on the stick" will not work.
>The fact that the co-pilot in question kept holding the stick to the back stops was the main reason that the aircraft wallowed into the sea. Weirdly, he did let go of the stick for a brief few seconds, which was the only time during the harrowing descent that the aircraft started to behave normally, but then he pulled it back and held it back right up until impact.
This description isn't consistent with what's in the accident report. Where are you sourcing it from?
AF 447 wasn’t all that different from this situation. One of the co-pilots was trying to pitch the nose down to recover from the stall. The other was panicking and trying to pitch up. The plane averaged their inputs, without giving feedback via the stick that this was happening. It wasn’t until very late in the flight that they figured out what was happening, and then it was too late to recover.
Obviously there was some significant pilot error in this case, but a big contributor mag have been that the pilot who was trying to correct the stall didn’t understand that the plane was ignoring his input because of the averaging.
In April 2012 in The Daily Telegraph, British journalist Nick Ross published a comparison of Airbus and Boeing flight controls; unlike the control yoke used on Boeing flight decks, the Airbus side stick controls give little visual feedback and no sensory or tactile feedback to the second pilot.
Ross reasoned that this might in part explain why the pilot flying's fatal nose-up inputs were not countermanded by his two colleagues.
In a July 2012 CBS report, Sullenberger suggested the design of the Airbus cockpit might have been a factor in the accident. The flight controls are not mechanically linked between the two pilot seats, and Robert, the left-seat pilot who believed he had taken over control of the aircraft, was not aware that Bonin continued to hold the stick back, which overrode Robert's own control.
That suggest there was only ever one pilot flying and the way that pilot reacted to the situation had a big part to play in the final crash.
> That suggest there was only ever one pilot flying
"Pilot flying" is a human-factors title, not a software function-lock. It just indicates who has control responsibility at that moment but it is not enforced by technical means.
It is intended to eliminate ambiguity in crew functions; the PF can be a newbie copilot even if the commander of the aircraft is a 30-year-service Captain who would become the PNF at that point. Its all part of Crew Resource Management theory.
There should only be one PF in a cockpit at any one time, precisely to avoid the situation that arose with the Air France flight where the computer was receiving inputs from two pilots.
I was responding to the claim the flight control was averaging the two pilot inputs, because if that was the case then two pilots would have been flying the plane.
Might point was I doubt that this was in fact happening and there was only ever one pilot in charge.
> the Air France flight where the computer was receiving inputs from two pilots.
The link and quotes I posted suggest that was not happening.
The system was just ignoring the other pilot (and that was the designed fault) because it also failed to tell that other pilot he was being ignored.
You may be right about the averaging. From rereading the accident report, the Pilot Flying took back control of the plane after the Pilot Not Flying engaged his controls and tried to pitch down.
But, it’s the same basic idea. The PNF thought he’d gotten control of the plane, and didn’t understand why his input wasn’t having an effect. He didn’t get feedback from the stick telling him a different input was being honored. And neither pilot appears to have been fully aware that they were in a flight control mode where there was a risk of stalling. The PF especially never seemed to have made that connection, and the PNF took a fairly long time to call it out. As a result, the PF may not have been aware that he needed to actively keep the angle of attack inside the flight envelope.
So, PNF tries to pitch down, but isn’t aware the plane got put back into a mode where he isn’t in control. PF is pitching up, but isn’t aware the plane switched to a mode where this could lead to a stall. That’s the similarity I was getting at.
From the reported control traces, there was no prolonged period of dual input. There were 3 or so brief moments of dual control input (1 - 2 seconds), during which a warning was sounded. The pilots never spoke out loud about it, but we can infer that they heard the dual input warning and were aware when it happened because the sequence of events was the same each time; inputs from both joysticks received -> aural dual input warning -> input from one joystick stops.
Something about the idea of two pilots inadvertently fighting each other for control of the aircraft has definitely caught peoples’ imagination. But it didn’t happen.
The incorrect user input on AF447 happened AFTER all of the automatic systems had failed due to sensor clogging. How could ignoring user input have helped the flight when the plane's computer giving up was the cause of the manual takeover in the first place?
Yes, I guess that's where I say I don't know of a fool proof system, and then yeah how would it know it was incorrect input. I was simply saying incorrect input, given the actual situation, was an issue.
I'd say the improper input was the most direct factor, as it was responsible for the stall condition all the way into the ocean.
But there are multiple major factors leading up to that, including the lack of high altitude training in direct law, and that the simulator didn't exactly simulate high altitude stalls, and that the stall warning stopped when the angle of attack was beyond the sensor limit. All of these things are major and the final report really sank a lot of blame on Airbus and Air France as well as pilot startle effect basically stopping their brains from working the problem. The senior pilot who arrived didn't have that, and quickly figured out the source of the problem but by then it was too late, not enough altitude to recover.
After so many decades, there's no golden rule here ? (genuine question).
A principle of zero automation fallback in case of confusion ? something that is hardcoded deep in the design so that people in charge (pilot crew) can know for sure that whatever happens is in their hands ?
The co-pilot apparently didn't realize that the sensor issue that disabled the autopilot also disabled the stall prevention. And that's despite an audible "STALL" warning being repeated in the background.
The captain was not in the cockpit when the whole situation started, but as he re-entered the cockpit during the stall he saw one of the co-pilots holding back on the yoke and told him to push the yoke forward to prevent the stall. The co-pilot followed the instructions, but only for a few seconds before pulling the yoke back again.
All of this is to say if the plane hadn't been known to ignore user inputs in most situations, the co-pilot might not have assumed the Airbus would do the right thing and climb no matter what when pulling back on the yoke. So in a sense, never ignoring user inputs might have also saved Air France 447.