Air France Crash Underscores Challenge of Designing Complex Automated Systems

On May 31, 2009,four hours into a trip from Rio de Janeiro to Paris, Air France Flight447, an Airbus A330-200, encountered heavy turbulence. Fifteen minutes later, anautomated system began sending messages documenting a worsening situation asfirst one and then another of the redundant electrical systems failed until allfour were gone. Among the last messages sent was one advising that the cabinpressurization system had also failed suggesting an in-flight breakup.

The circumstances surroundingthis flight underscore the diabolical challenge of designing complex, automatedsystems for multiple contingencies and then managing the consequences of thedesign choices made. Since I have a couple hats in my collection, one for whenI'm being an engineer and another for when I'm being a pilot, the crash broughtthese challenges into sharp focus. It also reminded me of 30+ years of pilot concernsabout Fly-By-Wire flight control systems.

In a Fly-By-Wire system, electricmotors and actuators operate the flight surfaces via wires or fiber opticstrands. Multiple computers provide continual oversight of the process. Designersemploy software to prevent what they consider to be dangerous or illogical userinputs from the pilot in an attempt to reduce pilot error and thereby increasesafety. Unfortunately there have been accidents â€“ some fatal – because designersdidn't adequately anticipate abnormal flight regimes.

In a fully implementedFly-By-Wire system, there's no reversion to manual control. Pilots are systemmanagers, making requests of the computers, which then decide whether therequests are reasonable. They control the movement of control surfaces using aset of rules or "laws." On an Airbus for example, four operational laws governits operation: Normal,Normal Alternate, Abnormal Alternate and Direct Law. As systems fail, controlauthority changes, eventually offering the pilot control only of elevator trim,rudder and thrust of the airplane's engines in the Direct Law mode.

With four electrical systemsand multiple computers, the odds of ever getting to Direct Law are remote. But Flight447 lost all of the electrical buses plus cabin pressurization in athunderstorm, which was something the designers probably listed as an extremelyunlikely possibility. Manual reversionin this case may not have helped, but it certainly could not have hurt. In adire emergency, a pilot needs access to every flight control on the airplane.After all, if things are really bad, why make them worse by restricting apilot's options to the point that he or she is little more than a passenger?

To an aeronautical designer, there'sa tightrope to walk that's both long and very far above the ground. Involvingnon-designers in the process isn't something that's normally high on their listof priorities since outsiders (pilots in this case) will frequently want to addfeatures that translate to added cost. Still, most airline pilots I know whomake their living in a Fly-By-Wire airplane don't object to the software itself.They appreciate the smooth way the computers execute the flight surfacemovements.

What they hate is the lack offull control of the airplane in an emergency. This desire is at variance with an aircraftdesigner's mindset that tries to prevent mistakes by restricting the actions apilot can take. While these design objectives work well in normal operations,should things go horribly bad, as they did with Flight 447, the design rulesmay be in conflict with what's required to extricate oneself from disaster. Thisis the pilot's case in a nutshell.

John Hansman, a pilot and an AeronauticalProfessor at M.I.T. specializing in aircraft design, has studied thedifferences in the Fly-By-Wire control philosophy and the more traditionalapproach to aircraft control. In his opinion, Fly-By-Wire gives more decisionauthority to the aircraft systems and less to the pilot, whereas traditionalsystems provide dynamic feedback on the operation of the aircraft but leavemost of the decisions to the pilot. Hansman feels that by allowing computers tomake critical decisions when operating in an abnormal flight regime, designersplace a tremendous burden on themselves to anticipate all possible emergency modesand design the system to react appropriately.

But what's appropriate? That'sat the core of the debate. Although there are budget constraints in any design,Hansman has an approach that may help. Hetells his students, who may well be the next generation of Boeing or Airbusdesigners, that to make correct decisions, particularly when designing complexmachines like airplanes, it's critical to involve end users early in the designprocess. He teaches that both the designer and the end user have a mental modelof how something should work. However, the two models are frequently atvariance with one another.

An example: A designer working on flight dynamic issues notes there are many reportsof pilots getting the airplane to assume a steep angle of attack coupledwith a decay in air-speed to decay. This set of conditions is precisely whatkilled New York Yankee catcher Thurmond Munson as he approached an airport inhis Cessna Citation business jet. The designer's solution was to examine theamount of pitch up requested by the pilot, and as it increased, cause theengines to spool up so that the aircraft can't slow down. This strategy workedfine until a combination of events that had not been modeled during the designphase fooled the system. Although thepilot steadily increased the pitch, the engines didn't spool up. The pilotshould have immediately lowered the nose and manually increased the thrust but,relying on the automation, he didn't, and the airplane crashed short of therunway. It was a case of pilot and designer error.

Another example: A pilotdescended below the normal Initial Approach Fix (IAF) altitude because theweather was excellent and he was flying a visual approach. Once past the IAF, hecommanded the aircraft to fly the approach. He thought it would simply continueon towards the runway, capturing the glide slope from below instead of fromabove which is the way it works when you start at the IAF. Instead, the aircraft went into an immediateclimb and attempted to reach the altitude required at the IAF even though thatpoint was behind the aircraft by this time. The pilot decoupled the aircraftfrom the autopilot but placed the airplane back in the approach mode once he'dsatisfied himself that the system was working properly. The aircraft once againstarted climbing, giving the passengers a carnival ride they didn't expect. Thedesigner in this case never anticipated the pilot would attempt to fly aprecision approach from a point other than where the approach is normallybegun.

We may never know whathappened to Flight 447. But the dialoguethat will emerge from this event will be invaluable to system designers, asthey continue in their quest to design higher degrees of safety into theirautomated systems.

Contributing Editor John Loughmiller is an ElectronicsEngineer specializing in Single Channel Per Carrier communications systems andcontrol logic system design for automated communications devices. He's also a4,500 hour commercial pilot, flight instructor and aircraft owner and is a LeadSafety Team Representative for the Federal Aviation Administration.    

Read additional in-depth Air France crash coverage at Flightglobal:
Investigators confirm airspeed problem on Air France A330
AF447 accident - icing, pitot tubes and radar in the frame