Crashproof Code

Flying an experimental supersonic aircraft requires rock-solid flight software


Most people can tolerate the occasional computer crashes that plague modern life. Not so the pilot of a jet fighter streaking through the sky at a notch above the speed of sound. A single software glitch could send the aircraft spiraling out of control, possibly killing the pilot. It's our job to make sure that doesn't happen.

Writing and testing software for the onboard computers that translate a jet pilot's commands into actions is hard enough at the best of times, but when an experimental technique for controlling a supersonic aircraft is thrown into the mix, the job gets really tough--and interesting. That's the task faced by our teams at Boeing Co. and NASA as a modified F/A-18 strike fighter tests out a new way of using its wings.

This research program--dubbed the active aeroelastic wing (AAW) project--breaks with decades of aircraft tradition. Normally, to roll left and right, airplanes use control surfaces, such as ailerons and flaps, which are attached to the leading and trailing edges of relatively rigid wings. The control surfaces are angled up and down to alter the amount of lift on the wings, rolling the aircraft one way or the other.

A modified F/A-18 jet maneuvers over the Mojave Desert in California during flight tests for the Active Aeroelastic Wing project. The project could lead the way to more fuel-efficient and agile planes.

Photo: NASA

But the AAW is flexible enough to be twisted on demand in flight--and it could herald nothing less than a revolution in aviation. The twisting can be used to control the plane's roll, reducing and, we hope, ultimately eliminating, the need for ailerons and flaps and their associated hardware. The result: thinner, lighter airplane wings.

The benefits would be immense. For example, knocking 10 percent off the weight of a jumbo jet's wing would result in annual fuel cost savings of about US $1 400 000 per plane. And while it may be some time before this technology percolates into civil aviation, the military is already interested in the other advantages heralded by the AAW. Increased fuel efficiency, for instance, means the ability to carry more weapons for longer distances. As a bonus, AAW-equipped planes would be more maneuverable, able to execute sharper turns at higher speeds. Although current combat planes are already near the physiological limit of human pilots' ability to withstand turns, future remotely piloted or robotic planes would be able to fully exploit this new agility.

Building on research in the 1980s and early 1990s by NASA and the U.S. Air Force, the AAW project began in 1996 as a joint effort. Its participants are NASA's Dryden Flight Research Center in Edwards, Calif.; the U.S. Air Force Research Laboratory at Wright-Patterson Air Force Base in Dayton, Ohio; and the Boeing Phantom Works divisions in St. Louis and Huntington Beach, Calif. The first flight tests of the AAW-equipped F/A-18 took place from November 2002 to April 2003.

But the idea of using a flexible wing to control a plane is not new: in fact, it's exactly as old as flight itself. Just over a century ago, the Wright brothers twisted the wood-and-cloth wings of their first plane to adjust its course. Twisting the wings in different directions on either side of the pilot increased lift on one wing and decreased it on the other, causing the plane to roll.

As airplanes flew faster and higher, however, engineers moved to stiffer wings and relied on ailerons to bank or roll planes to the left or right.

Ironically enough, an overly flexible wing was a serious problem during the initial development of the F/A-18 strike fighter in the 1970s and 1980s. At high speeds, deflecting an aileron up or down would twist the wing the other way--negating roll torque from the ailerons. The result was a sluggishly rolling aircraft, not desirable when you are upside down and close to the ground, say. In the extreme, the twisting wing could roll the plane in exactly the opposite direction of the one the pilot intended. The problem was solved by building new reinforced wings and adjusting the flight control software to compensate for the small amount of twisting that still occurred.

When the AAW project started, engineers realized that the F/A-18's teething problem could save a lot of the time and effort normally required to develop a test bed for experimental flights. By replacing a few wing panels, they could return the plane's wings to their prototype flexibility.

Next, the project needed to come up with a way of twisting the wing in flight. Another stroke of luck came to the rescue. The leading-edge flap of an F/A-18's wing is split in two; this allows the wings to be folded up, important for conserving deck space on aircraft carriers. Normally, both halves of this flap are moved as one by a single actuator, but the project added a second actuator that lets us control each half separately. Differentially deflecting the two halves when the F/A-18 is flying at high speed creates aerodynamic pressures that force the wing to twist. By varying the flap deflections, we can control the amount and direction of twisting, and so roll the plane [see picture, " "].Pitching and yawing the plane still require rudders and elevators.

Although the wing twists through only a few degrees, this slight variability should be more than enough to affect the handling of the aircraft and demonstrate whether an idea straight out of the Wright brothers' playbook could become part of the 21st-century aircraft engineer's toolbox. Future AAW wings should be able to twist themselves, without the need for the external flaps used in our experimental program.

But for this rosy future to come to pass, we have to prove the wing can be used to control the F/A-18. The initial flight tests last year, known as Phase 1, did not use the wing to control the aircraft. Rather, we put hundreds of strain gauges onto the wings to monitor their behavior. During a series of 50 flights, we twisted the new wings back and forth in small increments while maneuvering the plane at altitudes from 1500 to 7500 meters and at speeds from Mach 0.85 to Mach 1.30.

This limited twisting wasn't yet enough to cause the aircraft to roll one way or the other. Instead, the objective was to generate the physical data needed to develop the software that would allow the F/A-18 to use its flexing wings to maneuver safely in the air, even when flying faster than the speed of sound.

The idea of using a flexible wing to control a plane is not new: in fact, it's exactly as old as flight itself. Just over a century ago, the Wright brothers twisted the wood-and-cloth wings of their first plane to adjust its course.

The first "live" tests, with the AAW wings actually controlling the F/A-18's flight, are scheduled to begin this month as part of the Phase 2 flight tests at NASA's Dryden Flight Research Center (the home of the storied series of X-planes, from Chuck Yeager's supersonic X-1 to today's unmanned hypersonic X-43A.) Before the tests can happen, though, we need to have enough confidence in the reliability of our computerized flight control system that we can let pilots climb into the cockpit without making us--or them--flinch.

The system that will control the wings is based on a commercial off-the-shelf processor: a Motorola 68040 central processing unit. (Macintosh users may remember this chip was used to power Apple's early 1990s line of Quadra computers.) As in the F/A-18's original setup, four processors are used in parallel to provide quadruple redundancy. The 68040 CPUs are installed in the F/A-18's flight control computer alongside the original processors; should any problems with the new system manifest themselves in flight, the test pilot can flick a switch and return control to this tried-and-true system.

The original flight control processors are also responsible for providing the interface to the aircraft's command and control systems, passing inputs to the research processors and sending their outputs to the various servos that operate the rudders, flaps, and so on [see diagram, " Fly-by-Wire"]. But the biggest difference between the F/A-18's system and a consumer-grade computer system is in the software.

The flight software has to keep track of the plane's speed, altitude, and attitude while monitoring the pilot's controls for commands. Based on a set of rules known as control laws, the software must then translate any commands from the pilot into movements of the aircraft's various control surfaces, such as the rudders or, most significantly, the flaps that flex the AAWs. And this all has to happen fast enough that the plane responds instantly to the pilot and reliably enough that he can bet his life it will work all the time, every time.

Despite its complex and critical job, the flight software is compact, consisting of only about 13 000 lines of source code written in the Ada language. When compiled, the code fits into approximately 160 kilobytes. Compare this with the millions of lines of code that compile into tens of megabytes for a modern Web browser or word processor.

Flight Software is fundamentally different from the type of software most of us encounter on the desktop, or even the software that runs such enterprise-class applications as banking databases, and not just in size. For one thing, flight software must operate in real time. We're all used to the spinning hourglasses and watches that appear regularly on our computer screens; they're telling us that the print preview or new spreadsheet we just asked for is on its way but that the computer doesn't know quite when (if ever) it will appear.

The problem goes beyond the vagaries of office software. It is fundamental to many of the operating systems used in general-purpose computers--they have no way to guarantee how long a given task will take. Of course, most of the time this unreliability isn't a problem. If your media player has to drop a few frames of a movie because the video couldn't be processed fast enough, or if it takes 150 milliseconds to select an e-mail when it normally takes 10, you're not going to notice. The worst-case scenario, when the computer completely hangs, is usually just a blip in the workday and cured by a quick reboot.

We don't have that luxury. We have to guarantee that when the flight computer starts calculating how far an elevator should move in response to a command by the pilot, the job will be finished quickly enough so that the computer has enough time to calculate where all the other control surfaces should be and still appear to be responding instantly to the pilot's wishes. This is mission-critical, real-time operation.

To pull this off, first we established an absolute limit on the amount of processor time a task can use. A task might be calculating a rudder position or checking the pilot's control stick for movement. A hardware timer interrupts the flight computer every 6.25 ms, forcing it to move on to the next task on its to-do list. Eventually the computer reaches the bottom of the list and starts at the top again. Each task is given a fixed number of the 6.25-ms slots on the to-do list. The same task might be given several slots on the list--but no more, firmly constraining the processor time of even the busiest task and ensuring that every task gets a turn.

A critical task that has to respond very quickly to changing external events has an even stricter schedule--it must be completed in the first 2.2 ms of its time slot. This is because the original F/A-18 flight computers are waiting impatiently for commands to pass on to the plane's rudders, flaps, and other flight systems, and if no new command is received after 2.2 ms, the last command will be repeated. For example, if a rudder is told to turn, the original flight computers will continue to send turn commands until told to do otherwise.

While it's okay for a rudder to keep turning a few milliseconds longer than it should every now and then because of a task's occasionally missing its deadline, as a rule we have to ensure that every task can be completed in the time allotted. Otherwise, the task will fall further and further behind the rest of the system, introducing an ever-growing lag in response time that can spell disaster.

Clearly, a task that uses a very complex algorithm to work out what it's supposed to be doing will simply exhaust its share of processor time before it comes up with a result. To keep that from happening, we created what is called a gain schedule, a simplification technique that replaces complex algorithms with simple linear calculations based on empirical data.

This is where all the Phase 1 flight testing paid off. We took the data from the strain gauges and other monitoring instruments onboard the F/A-18 and used it to update the plane's original aerodynamics and structural loads databases created for the F/A-18 when it was first developed.

These databases gave us the information we needed to create the control laws that form the basis of the aircraft's flight software. The laws are designed to allow maximum agility without overstressing the airframe. They dictate what positions control surfaces should be in to make the F/A-18 execute a given maneuver--a gentle roll, say, or a sharp dive--taking into account the plane's current speed and orientation.

In other words, the plane's response to the pilot's pulling the control stick to the right is one thing when it's in the middle of a high-speed climb and another when it's coming in for a landing. These laws also embody the rules for how the plane should handle problems in flight, such as a stuck control surface or a malfunctioning air-data sensor.

The laws that are produced by analyzing the databases are cumbersome. They use complex nonlinear formulas to determine the best positions of the plane's control surfaces in response to pilot commands covering the whole range of conditions that the plane could experience in flight. There's no way we could squeeze these formulas into the flight computer and still have the software work in real time.

So, with the results of the complex analysis as a guide, we used Austin, Texas-based National Instruments Corp.'s MATRIXx control design and simulation software to chop the range of possible flight conditions into different regions. For example, one region might cover level flight, while another covers a banking turn. Within each region, a different easy-to-compute linear approximation can be trusted to adequately determine the aircraft's behavior. The look-up table of regions and their corresponding linear approximations is the gain schedule, and it forms the heart of the plane's control software.

In flight, then, the computer's to-do list looks something like this: inputs are gathered from the pilot's controls and flight instruments, such as the air-data sensor, which collects information used to work out the plane's altitude and air speed. Next, the flight instrument information is used to find which region of the gain schedule is applicable and to select the corresponding linear approximation. The resulting linear calculation then quickly computes where the plane's control surfaces should be based on the inputs from the pilot [see diagram, " The Mind of the Machine"].

Of course, knowing that the software can run fast enough to keep up with the aircraft is pointless if it isn't doing the right thing. It is the effort we put in to make sure it does what it should that marks another huge difference between flight software and your average piece of desktop software. People have grown accustomed to consumer and business software shipping with missing features and an armada of bugs, often because of insufficient testing by vendors. That's not an option for us.

Making sure the software does the right thing begins with the very first draft of the flight software. The mathematical description of the gain schedule--the parameters describing the various regions of flight and the equations that form the corresponding linear approximations--was automatically converted by the MATRIXx software into Ada source code to eliminate the possibility of errors being introduced "in translation."

We loaded the preliminary software into a flight simulator, which let our test pilots try it out to see if it behaved as an F/A-18 should and gave us a chance to make adjustments. Then we started systematic testing.

We Do have one major advantage. Unlike most software developers, who have to accommodate the bewildering array of hardware and software that might be used in combination with their program, we have complete control over the hardware our flight software will run on. This allows us to duplicate exactly the environment our software will experience in flight, using a specialized test bench on the ground. If we can get it to work on the bench, we can be confident it will work in the air.

The test bench lets us plug in the actual flight computers we'll be using in the F/A-18. It can simulate all the inputs the software will experience during flight, including control stick movements and airspeed information. The bench accepts outputs from the flight computers that would normally drive actuators and feeds them into simulated versions of their associated control surfaces, including a special simulator we built to accommodate the new actuator for the outboard leading-edge flap. The simulators are based on the updated databases from the Phase 1 flight tests.

We didn't attempt to test the flight software all in one piece. In that situation, when problems arise, trying to pinpoint the error in the software is almost impossible. Instead, with testing already in mind, we created the flight software as a collection of about 450 independent modules. Each module was responsible for performing one or more simple functions, such as checking the position of the pilot's control stick or computing what position an elevator should be in [see picture, " Through the paces"].

A special debugging mode built into the flight computers allowed us to test individual modules one at a time by systematically supplying a range of inputs. After the individual modules checked out, we tested larger and larger combinations of modules until the entire system passed muster.

At this stage, we called for a second round of flight simulation with our test pilots, this time using a sophisticated simulator at Boeing's St. Louis division, the hardware-in-the-loop simulator (HILS). The HILS used an actual F/A-18 cockpit that was connected to the new flight control computers. Most important, the HILS confirmed that pilots could switch between the experimental flight system and the original flight computer processors without any loss of control during the transition.

In mid-July, the AAW software entered the final phase of testing at NASA's Dryden facility. The previous testing assumed that the plane was operating normally, but the Dryden testing (which also uses the HILS simulator) focused on making sure the software could cope when things go wrong: malfunctioning actuators, failed instrumentation, or damaged hardware, for example.

The ultimate test of the software, though, will come this month when one of our test pilots takes the F/A-18 up and puts the active aeroelastic wing through its paces. Although the flight will be closely monitored from the ground, the pilot and plane will be out on their own.

While we will have to await the results of the experimental program before deciding where the AAW project goes next, an obvious follow-up step would be to design wings that can twist in flight without flaps, so we can start reaping the weight benefits of the aeroelastic approach. Ultimately, it may be possible to design so-called morphing wings, wings that at the flick of a switch would be able to transform themselves into almost any form while the plane is in the air--for example, long slender shapes for fuel-efficient cruising or narrow delta shapes for combat maneuverability [see illustration, " The shape of things to come"]. With that accomplishment, the familiar paraphernalia of airplanes--rudders, elevators, flaps, and ailerons--would take their place alongside exhibits like the Wright Flyer in aerospace museums.