[WalterBright]

The AF 449 was in a stall, and the pilots panicked and did exactly the wrong thing. The pilot came out of the lavatory and immediately realized what was wrong, and pushed the stick forward. But it was too late.

If the captain could figure it out, so could the computer.

I recall another crash, not so long ago, of a commuter plane where the wings iced up a bit and the airplane stalled. The crew kept trying to pull the nose up, all the way to the ground. They could have recovered if they pushed the stick forward - failing basic stall recovery training.

There are many others - I've watched every episode of Aviation Disasters. Crew getting spatially disoriented is a common cause of crashes.

[filleduchaos]

No, one of the pilots put the plane into an aerodynamic stall because they had failed sensors giving them erroneous airspeed information and he kept overriding the other pilot who was doing the correct thing to recover from the stall he had put the aircraft in.

What exactly was a computer at the time supposed to figure out with unreliable data, especially after a stall had first developed?

Also in fairness I was a bit too opaque with my point, which is that 1) LVL requires the pilot to actually press it, which they are unlikely to do if like you yourself have mentioned they are clueless about what situation they're actually in, and 2) LVL is not appropriate stall recovery so I don't really see how it is relevant to a case of an aerodynamic stall.

[WalterBright]

> LVL requires the pilot to actually press it

Of course. I did say it was a button to press!

> LVL is not appropriate stall recovery

It should be. I don't see how it couldn't be designed to do stall recovery. After all, the avionics do recognize a stall (as it activates the "pull up" stick shaker).

[Mawr]

"and he kept overriding the other pilot who was doing the correct thing to recover from the stall he had put the aircraft in."

Yep, the real design problem here is the idiocy of allowing dual input.

[mrguyorama]

I will repeat this as I have had to say it before:

There is no engineering fix to AF447. You cannot protect a plane from what is essentially a rogue pilot who is not restrained.

It would have happened exactly the same in a Boeing. The problem was a supposedly trained and tested pilot responding to a somewhat normal event (loss of awareness and disorientation) by freaking the fuck out and throwing a plane into the ocean from 30k feet. The copilot knew what was going on with 3 minutes left until impact, and was trying to fix things, and was using the feature to override dual input, and was still being hampered by a pilot who was refusing to do the only safe thing he should have: Sit back and shut the fuck up.

The actual solution is regular testing of pilots in stressful simulations to ensure they react predictably in bad situations. That can never be perfect though.

[WalterBright]

My suggestion was not about overriding the "nut behind the wheel", but providing the crew with a button that says "fix it".

P.S. my lead engineer at Boeing told me they can fix everything but the "nut behind the wheel".

As I mentioned before, my dad taught instrument flying. What he'd do is go through all the maneuvers where your body gets tricked, and the student (under a blackout hood so they could only see the instruments) must recover. And they'd do it over and over, until the student stopped believing his screaming senses and trusted the instruments.

I don't know all that can be simulated in a simulator. I don't know if modern flight training is sufficient.

BTW, experiments were done with birds to see how they flew "in the soup" (zero visibility). The birds would just fold their wings and drop out of it. It seems that evolution hasn't evolved a method for navigating blind.

[sseagull]

> a commuter plane where the wings iced up a bit and the airplane stalled. The crew kept trying to pull the nose up, all the way to the ground.

There’s probably a lot that match, but sounds like Colgan Air 3407 in 2009 (the last major commercial airline crash in the US before the mid-air collision earlier this year in DC)

https://en.wikipedia.org/wiki/Colgan_Air_Flight_3407

[WalterBright]

Yes, that's the one. Nice work finding it!

[shmeeed]

(It was AF 447.) I take this opportunity to recommend Admiral Cloudberg's excellent analysis (longread): https://admiralcloudberg.medium.com/the-long-way-down-the-cr...

[manarth]

    > "If the captain could figure it out, so could the computer."

The autopilot had disengaged, most likely because the pitot tubes had iced over.

The aircraft system entered ALT2 mode, where bank-angle protection is lost. Protection for angle-of-attack is also lost when 2 or more input references are lost.

You might describe these circumstances as the computer saying "I don't know what the heck's going on, you humans figure it out please".

[WalterBright]

As a former engineer who worked on the 757 flight control system, I am not terribly impressed with that design.

Having 3 pitot tubes iced over means they read 0 velocity. It is reasonable for the computer to be designed to recognize that if all three pitot tubes read 0, then the pitot tubes are the problem. With the altimeter unwinding, it should be able to recognize a stall. With the turn and bank indicator, and the AOA indicator, it should be able to return to straight and level.

Recall that the captain figured it out at a glance and knew exactly what to do.

[manarth]

The FAA report[1] gives a more comprehensive description of events.

The pitot tubes had differential icing, and didn't all read 0kts – they reported different velocity against each tube, such as 40kts or 60kts (against an expected baseline of ~ 275kts). The computer correctly recognised the data was invalid and rejected it.

It's a common narrative that the captain immediately figured out the issue. The report and transcript of the cockpit recording[2] notes that the captain's interventions showed that he had not identified the stall, nor had the copilots.

         ~ cockpit recording ~
    0:00 autopilot disconnects
    0:01 [copilot right] "I have the controls"
    0:11 [copilot right] "We haven't got a good display of speeds"
    1:26 captain enters cockpit
    1:30 [copilot right] "I don’t have control of the airplane at all"
    1:38 [captain] "Er what are you doing?"
    3:37 [captain] "No no don't climb"
    4:00 [captain] "Watch out you’re pitching up there"
    4:02 [copilot right] "Well we need to we are at four thousand feet"
    4:23 ~ recording stops ~



    [1] https://www.faa.gov/sites/faa.gov/files/AirFrance447_BEA.pdf
    [2] https://bea.aero/uploads/tx_elyextendttnews/annexe.01.en.pdf

[WalterBright]

> he had not identified the stall

Thank you. I had not seen the transcript before.

Is it possible that 40/60 kts indicates a stall? Nevertheless, the drop in altitude while the nose was up should also indicate a stall.

I know that designing avionics, and accounting for all possible scenarios is a difficult job, and we learn from the failures. But I don't buy that it was impossible/impractical for the avionics to figure out what was going on based what the other instruments were saying.

[WalterBright]

Consider the inputs the avionics had:

1. 40/60 kts on pitot tubes - could that be showing a flat spin?

2. rotating compass - flat spin?

3. altitude drop - stall

4. attitude - level, no bank

5. engines - operating normally

6. GPS - no forward progress

Does that add up to a stall?

[manarth]

I agree that comparing the various sensor data points could allow a reasonable conclusion: e.g. IAS is variable across sensors therefore IAS is unreliable, so what additional information could allow a reasonable diagnosis?

The flight system could identify a stall and prominently alert the pilots. That's one of the recommendations from the report: to implement a dedicated stall warning. The stall warning was actually active, but disregarded/unrecognised by the pilots because of the number of other simultaneous alarms and extraneous information, including an intermittent recommendation from the Flight Director system to pitch up at 12°.

In general, Airbus aircraft don't have a dedicated AOA indicator visible to the pilots; instead AOA is visualised to the pilots by proxy via the airpeed indicator.

For AF447 the flight avionics probably had enough information to bring the aircraft back to straight and level flight without pilot input.

On the other hand the 737 Max crashes were attributed to MCAS overriding the pilot input and lowering the nose, in response to incorrect/faulty AOA sensor data.

Both were extreme examples, and the recommendations probably coalesce somewhere in the middle: better information (and alert prioritisation) for pilots and redundancy in sensors and logic.

Air Astana Flight 1388 also comes to mind. I'm not sure how a flight control system would deduct cross-connected aileron controls and adapt accordingly (without introducing other risks or failure modes). Given the glacial pace of change and approval in aviation, we're probably 20–50 years away from that level of autonomy.