I know we discussed this at length in the past but I bring it up again because it is in the news again.
Technology is wonderful and when it comes to flying I think it has mostly made things safer.
However here is a prime example where complete reliance on the technology can get you in trouble.
So, apart from the glass cockpit are there no simple mechanical devices that work no matter what in the cockpit? (Thinking of that little ball floating in liquid which shows the pitch and roll of the plane.)
In the article they noted the pilots thought they were in a dive and were pulling the nose up when in fact the plane was stalled and they should be pushing the nose down.
Wouldn’t that floating ball have told an undeniable truth to the pilots (i.e. the nose of the plane is pointed up)?
FTR I am not here to crucify the pilots. I am not a pilot but have read enough from pilots around here to realize these guys were in exceptionally difficult circumstances that would fool all but the most experienced pilots (and maybe have fooled them too).
Just wondering why a simple fallback that simply cannot break or at least works on simple physics that won’t go wrong isn’t used (or if there then why was it not paid attention to).
I don’t think that 100% accurate. The pilots knew they were losing altitude, but were unclear what their airspeed was due to frozen sensors. (I forget what they’re called.) This is why they didn’t know they were in a stall. It had nothing to do with the nose position. They thought the airspeed was OK, and one of them was pulling up to gain altitude. They should have pushed the nose down to gain airspeed and then worry about altitude. By the time they figured it out it was too late.
As I understand it, part of the problem was that the pilots were not communicating fully among each other. One of them was pulling the stick back the entire time, but the others did not realize he was doing that.
From what I read -
The biggest mistake was that the copilot(?) kept his stick pulled all the way back, due to misreading that they were in a dive, or panic, confusion whatever. The pilot realized they might be stalling (falling nose-up) and pushed HIS stick forward.
The bioggest stupidity of the whole inciddent is that the two sticks give no feedback as to each other stick’s position so the pilot did not know the copilot was doing the exact opposite of his control action; and the control system averages the two sticks. So it averaged out to level flight, the plane was not put in the nose-down position, stayed falling flat, and pancaked into the water.
Essentially, fatally flawed user interface design by Airbus is being passed off as training and pilot error. The idea, logically enough, is to not link the control sticks so the pilots don’t end up fighting over the controls and essentially pushing against each other - however, I don’t see how “not feeling anything” about the other’s action is an improvement.
Several other things -
apparently the pitot or other controls were frozen over with icing(?) which can happen.
the autopilot got confusing readings from the frozen-over controls, and slowed the airplane into a stall, then dropped off and let the pilots handle the mess.
The stall warning turns off after a certain time/angle so the pilots thought they were flying fast enough (diving) when they were still nose-up stalling. (Another Airbus “feature”).
Whether they should have flown through rather than around the storm area - judgement call…
So it was, sadly, a combination of poor design, weird circumstances, and failure to recognize the situation in the midst of conflicting signals.
A GPS receiver tells you your ground speed. If there is a non-zero ambient wind around you, then your air speed will be different from your ground speed. Winds aloft may be strong enough that the difference matters, if you happen to be flying close to stall speed - and that can happen if the aircraft is in the “coffin corner” area of the flight envelope.
Just for clarity’s sake, the attitude indicator you’re referring to is not a “failsafe” device. The ball isn’t floating free in liquid; if it were, it would be susceptible to any acceleration that happened, e.g. you could fly the plane through a vertical loop and it would always point toward your feet instead of the horizon. In reality, it’s a complex device that relies on internal gyroscopes, and if there’s a failure, it’s not going to indicate anything useful at all.
But never mind that. Picture yourself on AF447, and reconcile these three instrument readings:
-the attitude indicator says the plane is pitched 16 degrees up.
-the unwinding altimeter says the plane is rapidly descending.
-the silent stall warning indicates the plane is not in a stall condition.
BTW, the engines are at max thrust.
You have no airspeed measurement, and you can’t see the real horizon outside. This plane, unfortunately (and astonishingly, IMHO), is not equipped with an angle-of-attack indicator, which would unambiguously tell you what you need to know, i.e. the aircraft is in a stall so deep (AOA = ~40 degrees) that no one has ever flown a situation like this in the real world or in a simulator. How do you decide which of the above three instruments is lying to you? You’ve got just a few minutes to figure this out before you splat into the ocean. While you are trying to figure this out, it would help to know that your idiot copilot has been pulling back on his joystick the whole time. But you’re not communicating with each other, so you have no idea that he’s holding the plane in a deep stall.
If they were paying attention to the indicator on the instrument panel that tells them what mode the control sticks are in - and if they had been communicating with each other as CRM dictates they should have - then this crash might not have happened.
But one more safety system might be a good thing, since (as this accident demonstrates) air crews don’t always pay complete attention or follow the precepts of CRM.
The alternative to status quo is a force-feedback system so that the pilots do in fact “fight it out,” and the two control sticks settle at a common position at which the two pilots are both applying the same amount of force (but opposite to each other). That’s how a traditional dual-yoke control system behaves, but to do it with a pair of fly-by-wire joysticks on opposite sides of the cockpit would requires force sensors and servomotors on each stick. That’s a whole pile of extra parts that adds cost and decreases reliability, which is probably why it got left out of the original design.
In the aftermath of AF447, we might see something like that get implemented. Or we might not. FAA, last time I checked, valued a human life for the purposes of cost/benefit analysis at $1M. That is, if a change would cost more than X million dollars and would be expected to save fewer than X lives, it’s considered a bad investment. So Airbus will run the math, figuring out how much R&D and manufacturing expense might be required to implement force feedback systems on existing and future Airbus aircraft, and the FAA will estimate how many lives might be saved by those measures. Maybe it’s a good deal, maybe not. We shall see…
So what they needed was a reliable indicator of: (1) the angle of attack, (2) the true airspeed, and (3) stall condition. But they didn’t have those. The plane couldn’t make sense of what it did know, so it turned the controls over to the backup system (humans), who couldn’t handle it either.
This is typical – government accident investigators always blame someone who’s dead.
Maybe even understandable: the pilots are dead and can’t complain, Airbus is alive and could. Plus they have lots of lawyers to harass the agency if they were blamed. And strong incentives to fight such blame: the cost of retrofitting all the planes, and probable cost of settling lawsuits from relatives of the 228 dead people.
Why would it have to be so complicated? Wouldn’t a mere lamp switching on when the other pilot is using the joystick have been sufficient in this case? The pilot would then have noticed that the co-pilot was doing something and could have just asked him what.
They already have the equivalent of a light to tell them that. They obviously didn’t notice it.
All that ball does is tell you if the plane is in balanced flight, it doesn’t say anything about pitch or roll, it is also not perfect (they can get stuck.). Anyway, the instrument that tells them which way they’re pointing was working just fine, as was the backup, so having yet another instrument to tell you the same information wouldn’t improve things.
Improved control feedback and improved stall warning logic is what the situation needed.
Richard, I’m familiar with your credentials. It seems somewhat intuitive to a non-pilot like me that a plummeting altitude might possibly be a symptom of a stalled aircraft. In your opinion, why wouldn’t the co-pilots have recognized this after some of the futile corrections they attempted?
I’m supposing inexperience and panic, but logically there are only a handful of possible solutions. I’m thinking that working through them in a calm and rational fashion would be SOP.
Therefore pilot error is most definitely first and foremost, no?
The design is not so hot. The crew training was not so hot. The crew did not communicate well.
But…
Have they reproduced the flight in the sims? Was it recoverable & how long did they have to start the recovery? Have they loaded up a real plane, assuming the problem was recoverable, and gone poking around in the corners of the box?
One critical point was that the stall warning shut off (IIRC, past a certain speed?). Everything except the altimeter seemed to say they were climbing.
As somebody said in a previous thread, the ride probably was not smooth. Floats etc. are not much use when they are bobbing and swinging.
IIRC when the plane was pitched nose way up there was no airflow across the airspeed sensors. The pilots did nose down once or twice (working from memory here) when they did nose down the air speed sensor started registering that there was not enough air speed and the plane in fact was in a stall.
At this point the pilots made the critical mistake. If they had flown the plane the way pilots are taught (stall warning = nose down gain more air speed) they would have fixed the problem and continued the flight. Instead they put the nose down got a stall warning so they pulled the nose back up because it made the warning go away. They treated the symptom rather than the root cause.
Add to that a less than perfect set of control software and really poor (almost non existent CRM) you have a recipe for disaster.
Yes. The airspeed indicator malfunction (frozen pitot tube) was what started this whole thing, but it eventually thawed out - at which point they had already established an angle of attack around 40 degrees and an airspeed of around 60 knots. The aircraft designers figured nobody would ever put the plane in a flight configuration like this, so they programmed the computer to assume that wild inputs like this were invalid, and so the stall warning did not sound - despite the fact that the aircraft was, in fact, in a deep stall.
On a few occasions they tried to push the nose down, reducing AOA and increasing airspeed enough that the stall warning finally began to sound. This confused the hell out of them, so they stopped pushing the nose forward and sat there befuddled.
So the pitot tube froze up. Shit happens. The pilots put the plane into a stall. They were dumb (or at least one of them was), and they didn’t communicate well. Bad pilots, and bad training. The plane lied to them about the stall condition. Bad aircraft design.
Well it’s very rare for an accident to have a single cause, but pilot error seems like the most significant cause in this accident. My post you responded to was just listing design features of the aircraft that would have been useful in helping the pilots work out what was going on.
There’s no other way for humans to fly than complete reliance on the technology - planes are inherently entirely technological objects.
(Silly nitpick, I know, because the rest of your post makes it clear that you’re talking about single point of failure scenarios.)