Jan 13, 2008

When auto pilots go bad...

Disengagement of the autopilot is usually a non-event. We do it all the time when we prefer to "hand fly" at any time. But if the aircraft happens to be badly out of trim when the autopilot lets go, bad things have been known to happen.

Case in point:
http://aviation-safety.net/news/news.php?field=datumcode&var=200701%25

09 JAN 2007 Appeal court upholds acquittal of JAL pilot over fatal autopilot mishap
An appeal court upheld a lower court`s acquittal of a former Japan Air Lines pilot over an autopilot mishap that left a cabin attendant dead. In July 2004, the district court found the pilot not guilty after concluding that he was not aware that his release of the autopilot would cause the aircraft to pitch up and down violently, resulting in the death a cabin attendant and injuries to 13 passengers and crewmembers. In the appeal trial, prosecutors claimed that the defendant could have predicted that his release of the autopilot could cause the aircraft to pitch up and lead to an accident. The accident occurred on June 8, 1997 on a JAL MD-11 jet with 180 passengers and crewmembers. (Mainichi Daily News)

4 comments:

MathFox said...

Things get interesting when the autopilot throws its hands in the air, jumps in the lap of the PF and shouts "save the plane". (Figuratively spoken, that's what the autopilot did.) It usually requires some skill to get the plane back in controlled flight at those times.

I've found the incident report of the incident you mention at
http://www.jalcrew.jp/jca/706/706%20Accident%20Investigation%20Report%20TST(Body).pdf

Aluwings said...

Mathfox, thanks. That makes for interesting reading. As always, you can detect that alignment of items that leads to an accident: soaring fuel prices and increasing pressure on profit margins leads to an MD-11 designed with questionable stability in the high speed regime; instability accentuated when speed brakes are deployed (another economic "shortcut" in the design?); auto-flight software programming and potential glitch repercussions waiting to be discovered; clear air turbulence (CAT) and vertical windshear present; ATC restriction forcing the flight high on the descent profile; Captain accepting the normal descent restriction, expecting to counter-act the late start with a higher speed descent; auto-flight modes switching to handle the necessary speed and descent rate changes; airspeed approaching maximum limit in conjunction with windshear encounter; flight attendants pre-programmed by commercial agenda to give higher priority to passenger/marketing tasks over safety requirements; post-injury measures failing to recognize the life-threatening nature of at least one flight attendant's condition; poor coordination of ambulance service with arrival of aircraft; inappropriate interference in the normal procedures by the medical techs in order to attend first to the injured passengers.

All-all a sad outcome for the flight attendant who subsequently died of his/her injuries. And it seems like the proto-typical case where someone was trying to hang all this on the Captain (i.e. pilot error). Thankfully he was still alive to defend himself - not always the case.

MathFox said...

Being a non-pilot and more of a systems and modelling guy I spotted some different gems in the report, but I agree with your general findings.

I blame the weather and ignorance of the "fasten seatbelt" sign as direct causes of the injuries; company pressure on the flight attendants increased their risk.
About the software; the FCC glitch couldn have been a programming error; but the divergence between IAS and filtered air speed, when the wind changes more than 1kt/second is a design feature, that might have been introduced as (suboptimal) fix for control instabilities.

Another design issue that might have influenced recovery of control of the plane is the 0.2 seconds delay between control inputs and effectuation. This may lead to ~2.5 Hz oscillations in any control axis if the (auto-)pilot is insufficiently suppressing them. A low-pass filter in the control loop (filtered air speed) will suppress those oscillations. I wonder why they chose a > 10 second time constant for that filter.
The correct solution for the control delay problem is IMO a faster (more expensive) computer... can you say economy again?

Aluwings said...

Interesting insights. Thanks!