for a large part of the way down the pitch and power were reasonable values for a climb (10-15 degrees nose up) with full power,
Perhaps easy to Monday morning quarterback this accident, but all crew should be hard wired with SSR, (standard stall recovery),this includes recognising all symptoms of a stall. An uncommanded rate of descent being a prima facie symptom – first action, move control forward to eliminate symptom of the stall, set full power, when safe speed achieved roll wings level.
The CAA in its wisdom teaches recovery action for limited panel approach to stall: full power, roll, and then pitch – actions in nearly opposite sequence to the SSR. In a high performance SEP or SET this would set you up nicely for torque roll, aileron reversal and a spin.
This video is a good example of how Part 121 USA airlines deal with the subject. Pity best practice in the USA is not adopted uniformly.
Cobalt wrote:
I suggest you read the accident report.
What makes you think I haven’t? I have, and I stand by my opinion. That accident was not primarily (if at all) caused by automation.
I agree with most of that opinion, my only point was that once they entered the deep stall, flying pitch and power would not help them. They had a perfectly plausible attitude and power combination at that point. Even standard stall recovery would be difficult, you would have to pitch around 20-40 degrees nose down to reduce the angle of attack below the critical angle.
And I also agree that the – previous – teaching for stall recovery was problematic; I had two – separate – “1 hour revalidation check-that-is-not-a-check” flights with jet pilots where they tried to power themselves out of an approaching stall, and who needed some “encouragement” to (a) stall the aircraft fully and (b) positively “break” the stall while applying power, not after.
There remains the element of a crew used to rely on automation which was out of their depth when it wasn’t fully available.
Airborne_Again wrote:
Very little, I would say. An ASI failure in cruise should be a complete non-event.
I was referring to this (the stall warning coming on and off despite the airplane being in a continuous stall):
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..
(source: BEA final report)
And I did not mean to start a long debate about AF443. Just to point out that automation introduces elements that are not always well understood by pilots, or require extensive knowledge on the particular system. Pilots that only fly a few hours a year cannot be expected to master those systems. Many are already challenged enough mastering the G1000.
Airborne_Again wrote:
That accident was not primarily (if at all) caused by automation.
Nobody claimed it was.
Aviathor wrote:
What role did automation play in the AF443 accident?
The question was what role it might have played. For example whether it confused the pilots and therefore prevented them from correctly identifying they were in a stall.
Aviathor wrote:
And I did not mean to start a long debate about AF443. Just to point out that automation introduces elements that are not always well understood by pilots, or require extensive knowledge on the particular system. Pilots that only fly a few hours a year cannot be expected to master those systems. Many are already challenged enough mastering the G1000.
Yes, it was certainly an unfortunate design decision to stop the stall warning when the speed became “unrealistically” low. But that also is not an automation issue.
(On the other hand, if the stall warning did stay on at extremely low airspeeds, I can imagine other situations involving sensor problems where this could give a false stall warning and confuse the pilots — there is no clear cut answer.)
It would be difficult to have FBW in GA, due to the complex systems, and the need for fallbacks. Even an Airbus has a fallback to manual elevator and rudder control, which is all you need to fly and land (you can lose the ailerons etc, totally). Due to so many inept people working in the various companies, GA struggles even getting autopilot servos to be reliable so good luck with entrusting the whole lot to computer control.
Also the servicing scene ranges from just-ok to absolutely dire, and this requires systems to be kept as simple as possible.
Also you need an auto throttle for any meaningful FBW functionality, which is another big dimension in reliability; even most bizjets don’t have it. Accordingly, envelope protection as is implemented in GA is done using the primitive method of controlling pitch, regardless of how close to the ground you are. Finally, GA planes are mostly too underpowered for auto throttle to work properly.
Also the build quality of big jets is nothing like what one has in GA. Even the connectors in wiring harnesses cost 100x more…
AF443 → AF447.
IMHO the primary cause of AF447 was a lack of the most basic “how a plane flies” knowledge coupled with a lack of aircraft systems knowledge (e.g. where does the pitch data on the PFDs come from, and is it related to unreliable airspeed info?) as a result of crappy jet pilot training in the said country’s elite aviation academy 
Although the latter part is probably common in airlines; the systems are too complex for the sort of non-techy people who form the bulk of the airline pilot cadet intake. The dodgy software around the stall warning was just another hole in the cheese; the result of a programmer (much more likely a committee) which didn’t have any flying knowledge.
A colleague is now a Performance pilot for an A319/320 operator, and an aerospace engineer, the airline has regular dialogue with Airbus advising the manufacturer of software eccentricities which they uncover in operations. Airbus appreciates the feedback but then has to figure out why the automatics decided to do, whatever they did.
Peter wrote:
Even an Airbus has a fallback to manual elevator and rudder control, which is all you need to fly and land (you can lose the ailerons etc, totally).Airbuses have a fallback mode where the stick position directly determines the elevator and rudder positions, but it is still fly-by-wire is it not? That is, there is no hydraulic or mechanical linkage but the computers still read the stick position and give commands to the elevator/rudder servos.
I was told by an A330 pilot that there is a hydraulic override to the rudder and elevator, but I know no more. Probably @a_and_c will know.
I recall half of the dual-redundant FBW code was written in Pascal, which (I did it at univ, and even one of my firm’s comms products is a protocol converter with a Pascal compiler) by definition cannot contain any bugs, because it takes an infinite amount of time to write code which does anything 
The Apollo lunar module is more interesting as well as more obvious; that had an override from the stick (displacement over x degrees) directly to the reaction thrusters
