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

Question

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

Answer 1

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.