I know it’s off-topic for the current conversation, but this isn’t at all what happened on AF447.
The zoom climb and resulting stall came from a single set of control inputs, from the pilot flying the plane.
The pilot and co-pilot were pulling in different directions. The pilot was pointing the noise down to pick up airspeed and stop the stall. The co-pilot, who was panicking, was holding his stick up, because he wanted to climb. The system was programmed so if it both pilots made inputs at the same time, it ignored them.
The head pilot, was on break, was not in the cockpit at the time of the stall. So the co-pilot was relatively inexperienced.
Finally, he co-pilot explained he’d been pulling up the whole time. The head pilot, who had returned to the cockpit by this point, and the other pilot at that point realized what was going on, and said no, point the noise down. But it was too late.
I know that is a story that has become something like common knowledge, but it isn’t at all true.
There were I think three incidents of dual input after the stall. None of them lasted longer than a couple of seconds. The Airbus gives both a visual and aural warning when there’s dual control input, and we can infer the pilots heard / saw the dual input warning as one of them backed off each time it happened. Which is why they only lasted a couple of seconds.
There’s no sense from the cockpit voice transcription or the flight data of any kind of fight for control of the aircraft (even an unwitting one). There’s also no real sense that either the senior co-pilot or the captain really understood what had happened. No one ever said - despite over a minute of non-stop stall warnings - “we’ve stalled the plane, and need to push the nose down to regain airspeed”. There were disagreements between the crew; the senior co-pilot trying to coach the junior co-pilot (who didn’t even seem to have even realised he was pulling the plane into a climb when already at 35,000 feet), and later when he was almost begging for control of the aircraft. And later the Captain saying something about “no, don’t pull up”. But it was all indecisive and unfocused.
Bottom line.
- The stall was caused by the pilot flying the plane.
- Stall recovery wasn’t prevented by dual control input, because no one actually attempted a stall recovery in the first place. And the few moments of actual dual input don’t seem to have impacted anything very much.
I just remember reading the transcript in my organization management class’ text book and being deeply affected to the point of nausea. So thanks for bringing it back!
This is really cool. Do you have a link? I’d love to read more.
When I stall my A-10, it dips a wing, noses down a bit and I recover. Even the more vicious machines in my sim such as the MiG-19 and F-14 can easily be recovered unless the situation devolves into nasty shit like flat spins. Is that something you can’t do in an Airbus?
These are much heavier and more massive planes, the physics are fairly different. Sometimes the software even prevents certain maneuvers.
Someone who knows a lot more will fill the details in a minute.
On the Air France flight, they never really tried to recover from the stall.
Here, if you want to be depressed:
They put the plane into a deep stall, continued to push the nose up, and it stayed stable enough that it was effectively falling downwards with wings level (ish) and its nose pitched upwards 20 - 40 degrees. Even when it rolled, they were still able to correct that, with the plane falling out of the sky and forward air speeds of sometimes less than 60 knots.
Maybe if it had been a bit less stable and, say, threatened to spin, it might have been more obvious to the pilots what had happened?
The point was, they didn’t seem to recognise that they had stalled.
People have run the scenario in flight sims and suggested that a stall recovery could have been successfully started all the way down to 5000 feet. There’s an interesting question about that though; that plane was so far outside it’s normal flight envelope, no test pilot would have got anywhere close. As simulator software is based on flight test data, it’s hard to know how real those simulator runs were.
That was an interesting read, and it seems to back up what I heard that MCAS was designed specifically to fix that situation and reject the pilot’s inputs. From that transcript the pilots were holding the stick up to attempt to climb out of the stall for the 3 of the last 4 minutes of the flight before it crashed, when they needed to dive to gain speed and generate lift. It wasn’t until the one co-pilot mentioned that he was pulling back on the stick that the captain realized why they were in the bad situation.
So MCAS would have solved this situation (in my understanding) by ignoring the pilots inputs and diving the nose down to gain lift.
I’m not so sure. As far as I’m aware, the only purpose of MCAS (when functioning correctly) is to change the response curve of pitch input, more or less—with the larger, forward-mounted engines, when the 737MAX gets into a high-angle-of-attack condition (i.e. nose above direction of flight), the yoke force required to pull the nose higher goes down. By adding nose-down input, MCAS makes it so that the yoke force required goes up. It’s not a stall avoidance system, to my knowledge—it just makes it more obvious with controls feedback when you’re getting into a dangerous condition.
Worth noting that the 737 family is not fly-by-wire—that’s why a system whose purpose is to tweak the controls feel operates by actuating a control surface. The DCS Ka-50 simulates some similar difficulties—it also has hydraulic controls which the flight computers can actuate.
Someone’s got some 'splaining to do:
How many things have to be fucked up for that to happen? Including the pilots.
Not sure many. The article states the wrong flight plan was filed, so the pilots and the ATC were flying based on the flight plan they were given.
Wow. What a chilling article. Thank you for sharing it.
The final paragraph was great. As a user-centered designer of hardware/software tools for operability, it’s especially important to really comprehend the way automation works. In the end, this disaster was more than a human error – it was a gaping usability issue. The designers of the system failed to account for a very important, though rare, edge case.
But the crash raises the disturbing possibility that aviation may well long be plagued by a subtler menace, one that ironically springs from the never-ending quest to make flying safer. Over the decades, airliners have been built with increasingly automated flight-control functions. These have the potential to remove a great deal of uncertainty and danger from aviation. But they also remove important information from the attention of the flight crew. While the airplane’s avionics track crucial parameters such as location, speed, and heading, the human beings can pay attention to something else. But when trouble suddenly springs up and the computer decides that it can no longer cope—on a dark night, perhaps, in turbulence, far from land—the humans might find themselves with a very incomplete notion of what’s going on. They’ll wonder: What instruments are reliable, and which can’t be trusted? What’s the most pressing threat? What’s going on? Unfortunately, the vast majority of pilots will have little experience in finding the answers.
One of the best and most complete articles on the subject:
Holy moly. Again, from an operability design perspective:
The push for automation was a philosophical shift for Boeing, which for decades wanted to keep pilots in control of the planes as much as possible.
So here we are changing a decades-old paradigm… yet:
When upgrading the cockpit with a digital display, he said, his team wanted to redesign the layout of information to give pilots more data that were easier to read. But that might have required new pilot training.
…and yet designers’ hands were tied. The weren’t allowed to make any changes to the cockpit that would result in new training.
So instead, they simply recreated the decades-old gauges on the screen. “We just went from an analog presentation to a digital presentation,” Mr. Ludtke said. “There was so much opportunity to make big jumps, but the training differences held us back.”
…with a huge new addition of “background” automation, as follows:
Boeing added the new software in the Max, known as MCAS, which would automatically push the nose down if it sensed the plane pointing up at a dangerous angle. The goal was to avoid a stall. Because the system was supposed to work in the background, Boeing believed it didn’t need to brief pilots on it, and regulators agreed. Pilots weren’t required to train in simulators.
That’s just such a big oversight.
What a tragic mistake.
Other than totally ignoring pilots’ frantic input, did MCAS actually fail to do what it’s supposed to?
Though a bit older, this article has a bunch of nice infographics, showing the 737Max and some flight data from flightradar24.