# stall on commercial airliner - why is there no better on-board software? [duplicate]

## STALL:

I believe a simple software update to the existing on-board flight computers could - possibly - save lives.

Pilots need to be indicated possible errors by the on-board computers more detailed and more clearly.

## Backround: after having watched these 3 reports on:

       1) crash Air France flight 447 to Rio into the Atlantik in 2009,
an A330-203 (reason:stall, technical problem: air speed sensor(s)
frozen)

2) crash of Air New Zealand owned XL-Airways A320-200 in 2008
(reason: stall, technical problem: pitch sensor frozen)

3) crash Birgenair 301 in 1996 of 757-200 from the Dominican Republic
(reason: stall, technical problem: air speed sensor)


In general, these very often occuring problems with a faulty or temporarily faulty sensors (i.e. frozen) such as an air speed sensor should be directly indicated to the pilots by better software in the current on-baord computers.

A more relevant message to the pilots could and should be indicated.

For example: "POSSIBLE ERROR - Air speed sensor. Check pitch. If pitch within the range of xx - xx then possibly no stall situation present". [the pitch value to be used could come from an internal look-up table in the on-board computers memory for the given aircraft under its current load conditions].

In the case of Air France, had the pilots taken no action other than maintaining altidude and air speed, nothing would have happened.

As they took incorrect action, assuming there was a stall situation, the whole problem emerged in the first place.

The on-board computers should "know": IF the air speed does not match +/- the air speed the plane should be doing for its given amount of thrust by the engines [lookup-table in software], then: (assuming engines and plane is ok), there must either be a problem with the pitch sensor(s) or air speed sensor(s).

As these sensors are doubled, they are checked against each other. If , for example, two air speed sensors differ from each other, as I believe it is currently done, then it is assumed by the on-boad computers that one of these is faulty, but the on board computer does not conclude which one it may be and thus does not "know" what air speed it should use.

BUT, as explained above, WHY NOT: when checking against prevailing thrust and pitch and other relevant sensors, the on-board computers can come to an estimation for the given aircraft's actual air speed currently present [lookup-table in on-baord computers memory].

And then, this information with the big mention of POSSIBILITY should be indicated in the warning messages, to give pilots a head start in analyzing and identifying the problem.

Currently, it seems to me, that unneccessarily, much valuable time is spent by the piolots having to first analyze the situation from scratch and then decide on which action is needed to regain control from the stall, by which time it is often too late as altidude/air speed are by then too low for a recovery.

This was the case for (1) Air France as well as for (2) XL-Airlines.

Also, (1, Air France) had the problem that if one pilot pulled the stick backwards and the other pilot moved the stick forward, the action was cancelled out and no indication was given as far as I know, so pilots lost further valuable time arguing.

In (2, XL-Airlines) also had the problem that the A320-200 would in the stall emergency situation only respond to the trim wheel and not to the stick. The pilots realised this too late.

The on-board computer indicated this on its screen, but it was overlooked, as obviously very unusual.

It is as if when driving a car, suddenly it is no longer the steering whel we need to change direction but the handbrake.

What were the developers thinking here, I really do not understand.

Last but not least: the constant alarm noise should after a while be tuned down somewhat and the sound level reduced - it does nothing to get the situation resolved faster but instead causes stress levels to soar even higher, which is detrimental to pilots acting calmly and in getting the situation under control..

• multiple sensors can fail at the same time, computer programs can have bugs – ratchet freak Mar 29 '16 at 13:59
• The on-board computers should "know": IF the air speed does not match +/- the air speed the plane should be doing for its given amount of thrust by the engines [lookup-table in software], then: (assuming engines and plane is ok), there must either be a problem with the pitch sensor(s) or air speed sensor(s) there is quite a lot more stuff that can make the lookup table not match the measured speed, including software bug, engine malfunctions, etc. – Federico Mar 29 '16 at 14:09
• "Last but not least: the constant alarm noise should after a while be tuned down somewhat and the sound level reduced" - this sounds like a good idea, but note the suppression of stall warnings actually contributed to the AF447 incident. (Stall warnings did not sound at very high angles to prevent false warnings, apparently.) – Andy Mar 29 '16 at 14:18
• In the case of AF447, the aircraft was capable of flying safely, and should have been flown safely. No software would have saved the poor souls on that flight. What were the developers thinking here - many times more than you or me. – Simon Mar 29 '16 at 16:08
• You are right, the computer should had come to a reasonable estimation of the speed, even in the presence of false airspeed data. The computer between the ears of the captain, that is. What does it help to try to cover every eventuality in software when you have badly educated bus drivers in charge? Sadly, the pay and treatment of pilots by their management makes it obvious they are seen as bus drivers, and we should not be surprised if they behave like this sometimes. I am more amazed when they rise above that, and they do that in 99.9% of all cases. – Peter Kämpf Mar 29 '16 at 21:05

For example: "POSSIBLE ERROR - Air speed sensor. Check pitch. If pitch within the range of xx - xx then possibly no stall situation present". [the pitch value to be used could come from an internal look-up table in the on-board computers memory for the given aircraft under its current load conditions].

An aircraft can stall at any pitch angle and many different speeds, so pitch is not a good indicator of the onset of a stall. A better indicator is Angle of Attack, but in many cases those sensors freeze over. You cannot measure AoA without a physical sensor using MEMS or INS components.

The on-board computers should "know": IF the air speed does not match +/- the air speed the plane should be doing for its given amount of thrust by the engines [lookup-table in software], then: (assuming engines and plane is ok), there must either be a problem with the pitch sensor(s) or air speed sensor(s).

A problem with the pitch sensor/airspeed sensor does not automatically mean a stall, and also should not present additional stall warnings without the actual stall condition. How would you separate the two? Just like you don't want them to overlook a warning, you also don't want to present too many that aren't relevant as it will increase the time it takes to figure out what is going on.

BUT, as explained above, WHY NOT: when checking against prevailing thrust and pitch and other relevant sensors, the on-board computers can come to an estimation for the given aircraft's actual air speed currently present [lookup-table in on-baord computers memory].

Imagine flying from clean air into the jet stream as the sensors fail. You haven't changed the thrust levels and suddenly you are presented with a tail wind which greatly reduces your airspeed. Engine thrust does not immediately react to the surrounding air mass, you can't say that for every condition Thrust X = Airspeed Y, its not a simple correlation especially given changing conditions.

And then, this information with the big mention of POSSIBILITY should be indicated in the warning messages, to give pilots a head start in analyzing and identifying the problem.

No, this is absolutely not a good thing to do. Like I said above, you don't want to present warning conditions about the possibility of a situation. The pilot should be able to infer from airspeed invalid warnings that the possibility of a stall is there, and fly the aircraft appropriately. Presenting too many warnings is worse than not enough.

Currently, it seems to me, that unneccessarily, much valuable time is spent by the piolots having to first analyze the situation from scratch and then decide on which action is needed to regain control from the stall, by which time it is often too late as altidude/air speed are by then too low for a recovery

Pilots are trained for stall recognition and recovery and the recovery procedure after recognition should be a reaction without a lot of thought. The problem with the Air France flight is that the pilots did not recognize the stall even after the airspeed sensors started working again. By the time the captain realized that one person was climbing while the other person was descending, it was too late:

02:13:40 (Robert) Remonte... remonte... remonte... remonte...
Climb... climb... climb... climb...
02:13:42 (Captain) Non, non, non... Ne remonte pas... non, non.
No, no, no... Don't climb... no, no.
02:13:43 (Robert) Alors descends... Alors, donne-moi les commandes... À moi les commandes!
Descend, then... Give me the controls... Give me the controls!
02:14:23 (Robert) Putain, on va taper... C'est pas vrai!
Damn it, we're going to crash... This can't be happening!
02:14:25 (Bonin) Mais qu'est-ce que se passe?
But what's happening?
02:14:27 (Captain) 10 degrès d'assiette...
Ten degrees of pitch...

Exactly 1.4 seconds later, the cockpit voice recorder stops. That means when the pilot realized that they had the wrong control inputs at 2:13:42 it was less than 60 seconds from impacting the water, no way they would have been able to recover. So the take-away from AF447 was that pilots needed to be trained to recognize a stall and the proper recovery techniques. The pilots had regained control at 2:10:38 and the airspeed sensors were reading normally at that time. By 2:10:55 all avionics were functional. They put the aircraft into another stall at 2:11:03 when they tried to climb at TOGA power around 37,500 feet.

Again, the issue is overload. You don't want to overload the pilots with too much information. A stall horn and the red X over the airspeed indication should be enough for the pilot to realize to lower the nose and increase speed. AF447 was a wake-up call to commercial operators about the lack of hand-flying skills in todays pilots and quite a few good changes came from it including stall awareness training and recovery training on a reoccurring basis.

• To extend on your good answer... "[pilots] needed to be trained to recognize a stall and the proper recovery technique" may be the core of the problem, as pointed out in this interesting reading of the accident by Vanity Fair: The Human Factor. Automation may actually contributes to this lack of pilot skills, "a better software" as the OP suggests could actually lead to removing the pilots from the cockpit, but that won't remove all the failures. I'm not sure this is what I want. – mins Mar 30 '16 at 7:54
• Thanks @mins, I completely agree. The erosion of hand-flying skills in modern airliner pilots is downright frightening. Usually an airliner flight is wheels-up-autopilot-on all the way to touchdown. I've heard that this is even a matter of company policy in some instances. The other sad part is that many of the pilots aren't paid enough to have GA as a hobby so they can't get into aircraft that require good old stick-and-rudder skills. – Ron Beyer Mar 30 '16 at 13:52
• @mins Loss of flying skills is certainly a factor in accidents but I don't think its any more of an issue in FBW ac than a typical AP. They both pretty much require the same amount of hand flying. The truth is, on AF447, no matter how much analysis has been done there's just no clear answer explaining that pilots actions. Failing to recognize and recover from the stall is clear but how they got into the stall in the first place is another issue. – TomMcW Mar 30 '16 at 17:56
• @RonBeyer My personal, non-pilot opinion (aka pure armchair speculation) is that the complexity of the Airbus FBW system throws pilots curveballs. When there's a malfunction and the control law changes, the pilot is handed an aircraft that doesn't fly the way they are used to. It's like trying to ride one of those old-time bicycles with the big front wheel. You'd eventually figure out how to do it but you'll probably fall a few times before you get the hang of it. – TomMcW Mar 30 '16 at 17:56
• @TomMcW Again, its an erosion of hand-flying skills. Alternate law just means that the airplane does what you ask, you shouldn't be a PIC without knowing how to fly an airplane that responds like every other non FBW airplane. The issue wasn't really being in alternate law, it wasn't knowing how to fly the thing by hand without a computer in between. You shouldn't be learning how to fly a plane when you are responsible for 200+ lives, you should have hundreds of (recent) hours doing so already. – Ron Beyer Mar 30 '16 at 20:35