AoA is really the weak point in my opinion, the probe can get stuck or iced up; they always seemed extremely fragile to me for something so critical. Not to mention, redundancy is limited by the number of probes, of which there are only two on all the aircraft I've worked on, so if they ice up, that's it. IIRC that's what started the chain of events which brought down the Air France fight.

Maybe there is an alternative to AoA. The whole point is to determine how air will be affecting surfaces such as the wing, so one could instead just put pressure transducers all over the aircraft. From that you can determine how close you are to stalling. You can even tell where on the aircraft a stall is imminent.

It was a typo, but for "332" (which is the jargon for "330-200").

By itself, this is a sensible thing to do, since the AOA sensors are composed of a little vane that is free to rotate and align itself with the direction of airflow, connected to an angle resolver that measures the angle of the vane. If the airflow is not fast enough, there will not be enough force exerted to reliably and continually align the vane, thus the instantaneous angle of the vane may not conform to the angle of the airflow. To quote the BEA report:

> If the CAS [calibrated air speed] measurements for the three ADR [air data reference] are lower than 60 kt, the angle of attack values of the three ADR are invalid and the stall warning is then inoperative. This results from a logic stating that the airflow must be sufficient to ensure a valid measurement by the angle of attack sensors, especially to prevent spurious warnings.

However, the pilot flying had gotten the airspeed under that 60kt threshold, which inhibited the stall warning. When he reacted by pushing the control stick forwards (the correct reaction to a stall), the airspeed increased (a good thing, you need airspeed for lift) and the AOA decreased (also a good thing). However, the airspeed quickly increased over the 60kt threshold -- well before the AOA had a chance to decrease past its threshold. Therefore, the stall warning sounded again.

This does not fit into any mental model of how aircraft operate. A pilot knows, from their training and experience, that when you pull back on the stick, you end up stalling your plane (which leads the stall warning to sound); and to recover from a stall, you must push forwards on the stick, which unstalls the plane. After you're out of the stall, after you've recovered by pushing the stick, you expect the stall warning to be silent.

The crew were likely not aware that the stall warning cannot sound under 60kt airspeed, and could not, were not given the opportunity or information to realize that "stall warning NOT sounding" can signify that the plane is in fact, very seriously stalled.

The crew reacted with control inputs to shut that stall warning up, to avoid a stall, because "silent stall warning" is supposed to mean "not stalled". Acting on that stall warning, unaware of its treacherous reversed semantics -- sounding with the stick pushed forwards, and silenced when pulling back -- sent that crew to their doom:

> Until the end of the flight, the angle of attack values changed successively from valid to invalid. Each time that at least one value became valid again, the stall warning re-triggered and each time the angle of attack values were invalid, the warning stopped. Several nose-down inputs caused a drop in the pitch attitude and the angle of attack, whose values then became valid, such that a clear nose-down input resulted in the triggering of the stall warning. It appears that the PF reacted, on at least two occasions, with a nose-up input, whose consequences were an increase in angle of attack, a drop in measured speed and consequently stopping the stall warning. Until the end of the flight, no valid angle of attack value was less than 35°.

There was no AOA instrument on the flight deck either! The computers saw the AOA increase when the pilots pulled the stick back and saw the AOA decrease when the pushed forwards, but the pilots themselves never saw that, because they were not shown a single AOA number/readout. The information they were given that was derived from AOA (the stall warning's status) was completely and fatally misleading; to the point that the pilots never diagnosed a stall:

> The crew never formally identified the stall situation. Information on angle of attack is not directly accessible to pilots. The angle of attack in cruise is close to the stall warning trigger angle of attack in a law other thann normal law. Under these conditions, manual handling can bring the aeroplane to high angles of attack such as those encountered during the event. It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required.

> Consequently, the BEA recommends that EASA and the FAA evaluate the relevance of requiring the presence of an angle of attack indicator directly accessible to pilots on board aeroplanes.

The aviation industry loves to blame pilots when things go wrong. In most cases they're right, but as systems become more and more incomprehensible, we're expecting far too much of the wetware that most pilots that are humans run.

AF447 was an engineering crash. The collection of systems on that flight deck misrepresented the state of the aircraft to the people flying it. Now you can start equivocating about various subsytems, and in particular each subsystem may have acted in a logical way for good reasons. But the overall system, the collection of subsystems, in my opinion killed those people. With the information the computers had that it knew was valid -- GPS being the primary one -- the plane could have only been in one of two configurations. If there had simply been some way of showing both configurations to the pilots at the same time they would have went level immediately. Instead, because the history of avionics is that each subsystem is either go or no-go, nobody seemed to be responsible for the collection of systems as a whole and how they interacted with people. The idea was just to train the hell out of people and make them responsible. That works extremely well with five mechanical systems with known and transferable failure modes. It's not going to work with 20 electronic systems each of which has had the kiss of technological product development on it.

This is definitely the case. Forcing humans, in an extremely stressful situation, to reverse engineer what different sensors are reading (or if they're broken), what their own control inputs are doing and what the computers are thinking/doing based solely on perhaps-misleading computerized annunciations and observed aircraft behavior doesn't end well.

Critical measurements -- like angle of attack -- must be shown explicitly (a recommendation of the BEA) to the humans and not solely reserved for computer-consumption. Furthermore, there is likely room for better presenting the current state of the sensors that affect the flight control computers, the status of all the automation, and the current flight control laws to reduce the "what is it doing now?" factor that is unfortunately so dominant in these incidents that combine aircraft upsets with system malfunctions, maybe as a synoptic diagram on its own ECAM page -- not crammed onto the PFDs for a pilot actively flying the aircraft.

The plane changed modes and nobody realized it. That amazes me. To have different modes where the controls and indicators do different things and not have that information readily apparent? Ok, this is where you might could use better training. But gee. Like you said, another page on the ECAM would have been fine. You could have put a couple of wooden mechanical airplane models on sticks manipulated by the computer to show the top two best guesses for situation and ended up with something better than what they had.

I think the worst part of that disaster was that aside from engineering/program/integration management, I don't see any particular group of people that were directly at fault. Yet it all came together in a disaster. I find that situation unacceptable.

This claim is directly contradicted by the cockpit transcript in the official accident report:

https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/annexe.01...

At 2 h 10 min 22,1, the co-pilot notes that the plane is in alternate law.

The pilots had reliable altitude and attitude information, which is all they needed to determine the configuration of the plane.

Recently, I have discussed about the STCA with an ATC. In approach, when aircraft are turning, there are often alerts that are to be ignored. They could easily be filtered out by software, but controllers prefer a simpler and more predictable system even if it causes false alarms. Maybe aircrafts are becoming too smart and pilots not enough trained.

I understand you can have the junior guy flying. I can even understand the intermittent conditions that could lead to mis-identification of aircraft status. But any system, no matter what's in there, should be able to have the senior person on-board approach it from waking up and understand what the heck is going on. That is a requirement of the overall system.

Could we continue to train our way of more and more complex avionics? Sure. Maybe. How would we ever know that we've reached a point where that's no longer an option? I'm happy with my "sleepy senior pilot" criteria. If that's not it, what is?

It's not unusual for pilots to drift in and out of quasi-consciousness when doing hard aerobatic maneuvers. That usually works fine because there are only so many things to look at. Contrast that to your average GA instrument pilot. There's more stuff. They're taught extensively on partial panel -- but the thing that kills far too often is that pilots suck at figuring out when a system is going bad. It's not flying the airplane. It's trying to figure out what the airplane is telling you.

Anybody that's been doing software for any length of time at all knows that computers can tell you a lot more complicated and nuanced stuff than you can absorb. The pilots and the airplane should never be fighting one another.

If we model the stall warning as a boolean variable - then we are not able to signal the user about the fact that the warning system is in fact "inoperable".

On the other hand if the warning system had a state which would say "inoperable", or at it's best return an error - "speed too low", then this warning would never have a state which could be incorrectly interpreted.

This is exactly the same kind of mistake as a difference between NULL pointer and the 0 address you'd encounter while programming.

Actually the inexperienced COPILOT did this. The pilot realized that was a problem eventually, but too late. And unfortunately the Airbus takes the average of both pilot inputs.

You can see more here: https://safetyfirst.airbus.com/app/themes/mh_newsdesk/docume...

https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...

Really? That's the best way to handle that?

The pilots should never both be trying to apply control inputs at once. There isn't really a good way of handling the situation where the pilots are not communicating and are trying to make conflicting control inputs.

It wasn’t until a few minutes before Air France’s crashed that the pilot realized what the copilot was doing.

This is not true. See e.g.

http://www.airliners.net/forum/viewtopic.php?t=772033&start=...

02:11:43 (Captain) What the hell are you doing? [captain returns to cockpit]

02:13:40 (Bonin) But I've had the stick back the whole time! [At last, Bonin tells the others the crucial fact whose import he has so grievously failed to understand himself.]

02:14:29 - recording stops

[1]https://www.tailstrike.com/010609.html

Note that at the point of the transcript you're referencing, the captain was in the cockpit but not seated at the controls. It therefore would make no difference to his awareness of the situation whether or not the control sticks were linked, as he wasn't holding either of the sticks.

Unlike the captain, the PNF and PF (who were seated at the controls) both seem to have thought that they needed to climb. See 2 h 13 min 39,7 and 2 h 13 min 40,6.

Unlike the captain, the PNF and PF (who were seated at the controls) both seem to have thought that they needed to climb. See 2 h 13 min 39,7 and 2 h 13 min 40,6.

There's also evidence from the rest of the transcript that the pilots at the controls were perfectly capable of observing (or inferring) which inputs were being made.

I think there's an underling misconception here that an Airbus sidestack has a "position" akin to the position of the yoke of a plane with fully manual controls. An Airbus is flown with the sidestick remaining in its central position 99% of the time. To climb, for example, the pilot makes a short backward movement and then lets the stick return to its neutral position. The flight control software will maintain the specified climb until another stick input is made. For this reason, stick inputs tell you very little. If, for example, you see the PF push the stick forward, that doesn't necessarily mean that the plane's being put into a dive. The PF might just be reducing the rate of climb. You'd have to keep track of the complete history of stick inputs to know what was going on.

On top of that, as only one pilot has their hands on the stick at any given time, for the PNF to visually observe brief movements of their own sidestick would hardly be any easier for them than just looking at the sidestick of the PF, who's right next to them.