6 ms·

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

by th0ma5 7y ago

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.

hannasanarion 7y ago
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?
- th0ma5 7y ago
  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.
cyberferret 7y ago
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.)
- jacquesgt 7y ago
  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.
  - ricardobeat 7y ago
    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?
    - foldr 7y ago
      No, because an equally (probably more) likely scenario is that the relevant sensors are giving bad readings.
- Animats 7y ago
  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. [1] https://youtu.be/G161aMYCzbQ?t=100 https://youtu.be/G161aMYCzbQ?t=100
  - jamesharding 7y ago
    The engines in the MAX are still producing thrust below the centre of mass of the plane...how would this produce a nose down pitch at TOGA thrust?
    - Animats 7y ago
      Sorry, backwards.
- foldr 7y ago
  >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?
jacquesgt 7y ago
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.
- jussij 7y ago
  I don't the flight control was averaging the pilot inputs. From this link: https://en.wikipedia.org/wiki/Air_France_Flight_447#Human_factors_and_computer_interaction https://en.wikipedia.org/wiki/Air_France_Flight_447#Human_fa... 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.
  - dingaling 7y ago
    > 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.
cmurf 7y ago
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.
halter73 7y ago
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.
- EdwardDiego 7y ago
  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.
  - hef19898 7y ago
    One of the best explanations I have read on that issue. Short and accurately summing it up.
  - acqq 7y ago
    The indications were different alerts continuously sounding. It’s a complex problem, there’s a lot that can go wrong at once.
  - salawat 7y ago
    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.
agumonkey 7y ago
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 ?

by th0ma5 7y ago

hannasanarion 7y ago

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?

th0ma5 7y ago
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.

cyberferret 7y ago

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

jacquesgt 7y ago
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.
- ricardobeat 7y ago
  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?
  - foldr 7y ago
    No, because an equally (probably more) likely scenario is that the relevant sensors are giving bad readings.
Animats 7y ago
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. [1] https://youtu.be/G161aMYCzbQ?t=100 https://youtu.be/G161aMYCzbQ?t=100
- jamesharding 7y ago
  The engines in the MAX are still producing thrust below the centre of mass of the plane...how would this produce a nose down pitch at TOGA thrust?
  - Animats 7y ago
    Sorry, backwards.
foldr 7y ago
>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?

jacquesgt 7y ago

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.

jussij 7y ago
I don't the flight control was averaging the pilot inputs. From this link: https://en.wikipedia.org/wiki/Air_France_Flight_447#Human_factors_and_computer_interaction https://en.wikipedia.org/wiki/Air_France_Flight_447#Human_fa... 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.
- dingaling 7y ago
  > 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.

cmurf 7y ago

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.

halter73 7y ago

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.

EdwardDiego 7y ago
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.
- hef19898 7y ago
  One of the best explanations I have read on that issue. Short and accurately summing it up.
- acqq 7y ago
  The indications were different alerts continuously sounding. It’s a complex problem, there’s a lot that can go wrong at once.
- salawat 7y ago
  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.

agumonkey 7y ago

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 ?