RSS Feeds
Air France Crash Underscores Challenge of Designing Complex Automated Systems
An engineer/pilot's view on what went wrong with Flight 447
John Loughmiller, Contributing Editor -- Design News, June 4, 2009
On May 31, 2009, four hours into a trip from Rio de Janeiro to Paris, Air France Flight 447, an Airbus A330-200, encountered heavy turbulence. Fifteen minutes later, an automated system began sending messages documenting a worsening situation as first one and then another of the redundant electrical systems failed until all four were gone. Among the last messages sent was one advising that the cabin pressurization system had also failed suggesting an in-flight breakup.
The circumstances surrounding this flight underscore the diabolical challenge of designing complex, automated systems for multiple contingencies and then managing the consequences of the design choices made. Since I have a couple hats in my collection, one for when I'm being an engineer and another for when I'm being a pilot, the crash brought these challenges into sharp focus. It also reminded me of 30+ years of pilot concerns about Fly-By-Wire flight control systems.
In a Fly-By-Wire system, electric motors and actuators operate the flight surfaces via wires or fiber optic strands. Multiple computers provide continual oversight of the process. Designers employ software to prevent what they consider to be dangerous or illogical user inputs from the pilot in an attempt to reduce pilot error and thereby increase safety. Unfortunately there have been accidents – some fatal – because designers didn't adequately anticipate abnormal flight regimes.
In a fully implemented Fly-By-Wire system, there's no reversion to manual control. Pilots are system managers, making requests of the computers, which then decide whether the requests are reasonable. They control the movement of control surfaces using a set of rules or "laws." On an Airbus for example, four operational laws govern its operation: Normal, Normal Alternate, Abnormal Alternate and Direct Law. As systems fail, control authority 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 systems and multiple computers, the odds of ever getting to Direct Law are remote. But Flight 447 lost all of the electrical buses plus cabin pressurization in a thunderstorm, which was something the designers probably listed as an extremely unlikely possibility. Manual reversion in this case may not have helped, but it certainly could not have hurt. In a dire 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 a pilot's options to the point that he or she is little more than a passenger?
To an aeronautical designer, there's a tightrope to walk that's both long and very far above the ground. Involving non-designers in the process isn't something that's normally high on their list of priorities since outsiders (pilots in this case) will frequently want to add features that translate to added cost. Still, most airline pilots I know who make 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 surface movements.
What they hate is the lack of full control of the airplane in an emergency. This desire is at variance with an aircraft designer's mindset that tries to prevent mistakes by restricting the actions a pilot can take. While these design objectives work well in normal operations, should things go horribly bad, as they did with Flight 447, the design rules may be in conflict with what's required to extricate oneself from disaster. This is the pilot's case in a nutshell.
John Hansman, a pilot and an Aeronautical Professor at M.I.T. specializing in aircraft design, has studied the differences in the Fly-By-Wire control philosophy and the more traditional approach to aircraft control. In his opinion, Fly-By-Wire gives more decision authority to the aircraft systems and less to the pilot, whereas traditional systems provide dynamic feedback on the operation of the aircraft but leave most of the decisions to the pilot. Hansman feels that by allowing computers to make critical decisions when operating in an abnormal flight regime, designers place a tremendous burden on themselves to anticipate all possible emergency modes and design the system to react appropriately.
But what's appropriate? That's at the core of the debate. Although there are budget constraints in any design, Hansman has an approach that may help. He tells his students, who may well be the next generation of Boeing or Airbus designers, that to make correct decisions, particularly when designing complex machines like airplanes, it's critical to involve end users early in the design process. He teaches that both the designer and the end user have a mental model of how something should work. However, the two models are frequently at variance with one another.
An example: A designer working on flight dynamic issues notes there are many reports of pilots getting the airplane to assume a steep angle of attack coupled with a decay in air-speed to decay. This set of conditions is precisely what killed New York Yankee catcher Thurmond Munson as he approached an airport in his Cessna Citation business jet. The designer's solution was to examine the amount of pitch up requested by the pilot, and as it increased, cause the engines to spool up so that the aircraft can't slow down. This strategy worked fine until a combination of events that had not been modeled during the design phase fooled the system. Although the pilot steadily increased the pitch, the engines didn't spool up. The pilot should have immediately lowered the nose and manually increased the thrust but, relying on the automation, he didn't, and the airplane crashed short of the runway. It was a case of pilot and designer error.
Another example: A pilot descended below the normal Initial Approach Fix (IAF) altitude because the weather was excellent and he was flying a visual approach. Once past the IAF, he commanded the aircraft to fly the approach. He thought it would simply continue on towards the runway, capturing the glide slope from below instead of from above which is the way it works when you start at the IAF. Instead, the aircraft went into an immediate climb and attempted to reach the altitude required at the IAF even though that point was behind the aircraft by this time. The pilot decoupled the aircraft from the autopilot but placed the airplane back in the approach mode once he'd satisfied himself that the system was working properly. The aircraft once again started climbing, giving the passengers a carnival ride they didn't expect. The designer in this case never anticipated the pilot would attempt to fly a precision approach from a point other than where the approach is normally begun.
We may never know what happened to Flight 447. But the dialogue that will emerge from this event will be invaluable to system designers, as they continue in their quest to design higher degrees of safety into their automated systems.
Contributing Editor John Loughmiller is an Electronics
Engineer specializing in Single Channel Per Carrier communications systems and
control logic system design for automated communications devices. He's also a
4,500 hour commercial pilot, flight instructor and aircraft owner and is a Lead
Safety 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
-
It may be important for pilots to understand completely the machine he is flying its behaviour/limits of control systems design etc., so that he can suitably fly aircrafts during unexpected scenarios.
After all machines do not have interest in results, they just perform instructions.'>As rightly pointed out, most of such failures are due to lack of cross experience between Flying and designing avionics systems. System designers do not have flying experience as pilots and hence their designs might not have envisaged all posiible combinations of failures, while pilots do not completely understand the auto pilot design and at times may get surprised at aircraft's response when it is different from the assumed one.
It may be important for pilots to understand completely the machine he is flying its behaviour/limits of control systems design etc., so that he can suitably fly aircrafts during unexpected scenarios.
After all machines do not have interest in results, they just perform instructions.
Thangamurugan - 2009-12-8 04:52:12 EDT -
OK, I know it sounds illogical - but I feel a lot more comfortable if the guy in control is sitting nearer the accident than I am!
This is always the case with manual control, but I've never flown behind a system designer - thats why I DON'T trust fly-by-wire!
Mike Bibby - 2009-13-6 11:33:58 EDT -
The reason that the computer has more control authority over the pilot in the fly-by-wire system is because it is SAFER. Most airline crashes are caused by pilot error, not computer glitches.
Just because in an extreme condition, that a pilot could have made a better decision than a computer, doesn't mean that computers are not safer overall. Computers don't overreact and they are predictable. The U.S.A.F. has been using Fly-By-Wire since the 60's.
fly by - 2009-9-6 10:56:28 EDT -
I have always thought that complex life safety critical automatic systems should have several times the amount of time spent in verification and simulation testing as was spent in designing the software and hardware. I have never in my limited experience seen this to be the case.'>Well balanced article on the risks and benefits of fly-by-wire.
Am I mistaken, or have there not been at least three major software 'bugs' that have been discovered on the Airbus 330 through catastrophic loss of life, starting with loss of one of the first examples at the Paris Air Show while being flown by company demonstrator pilots?
I have always thought that complex life safety critical automatic systems should have several times the amount of time spent in verification and simulation testing as was spent in designing the software and hardware. I have never in my limited experience seen this to be the case.
Kim L. Ground - 2009-9-6 08:31:25 EDT -
The only possiblely good thing is that the plane was not from an American Manufacturer, so the liberals can't blame the USA for this one.'>The problem with computer control is that there are always situations that will arise that cause the computer to make the wrong choice. It happens in cars and on desktop computers and in home appliances, so why should we believe that it will be any different on an airplane. Except that you don't "re-boot" and continue. Those are just software failures. Even the best systems that I have designed will not work properly when there are thousands of volts and hundreds of amps passing through the control circuits. There are a number of possible lightning entry points that would bring most of the energy into the controls system, at which time all fly-by-wire functions would become inoperative.
The only possiblely good thing is that the plane was not from an American Manufacturer, so the liberals can't blame the USA for this one.
William Ketel - 2009-8-6 21:04:13 EDT
