Revolutionary Approach

By Stephen Budiansky

TO BUILD THE NEXT GENERATION OF UNMANNED FIGHTERS, BOEING AND NORTHRUP GRUMMAN ARE EXPERIMENTING WITH A NEW DESIGN PROCESS: SPIRAL DEVELOPMENT.

Vehicles that guide themselves without human control are a staple of futuristic visions. More recently, they have been the subject of some serious, if still modest, experiments: keeping traffic moving safely on “smart” highways, for one; or the Mars Rovers for another, which were equipped with a limited autonomous capability to plan their own routes across the Martian landscape and use their own onboard cameras to avoid obstacles.

But a team of hundreds of engineers at Boeing and Northrup Grumman are now working under a high-pressure deadline to turn what’s been mostly a dream up until now into a system that in a few years will be able to perform this feat for real—and in one of the most dangerous environments that exist anywhere. The goal of the Joint Unmanned Combat Aerial System (“J-UCAS”) program is to field a whole network of unmanned fighter planes that will be able to destroy enemy air defenses, attack deep targets, and conduct high-risk reconnaissance missions. And to do that, the planes will need to be able to make split-second decisions without any help from ground controllers. “The Mars Rover, it moves inches at a time,” says Kevin Wooley, mission software manager for Boeing’s X-45, one of two unmanned combat airplanes being built under the J-UCAS program. “We’re traveling at jet aircraft speeds and dropping weapons and trying to react to pop-up targets that arise.”

What is especially striking about the J-UCAS project is that it involves not only a very different way of thinking about aircraft but a different way of thinking about the whole process of engineering development. The concept is called “spiral development.” Rather than settling on a final design and then building it, the engineers on the J-UCAS project are undertaking a series of rapid design-and-build cycles in which the lessons from earlier “spirals” can be swiftly incorporated into the next. Spiral 0 in Boeing’s X-45 project is being completed this summer with a series of demonstrations in which an X-45A vehicle drops precision bombs on targets on a test range and two vehicles fly autonomously together. Spiral 1, which will lead to a much larger X-45C vehicle—nearly the size of an F-16 fighter, it will weigh 36,000 pounds, and have a wingspan of 50 feet, and carry 4,500 lbs of precision-guided bombs—has just begun. Within each spiral are smaller sub-spirals in which improvements are continually devised and incorporated.

Practitioners of spiral development acknowledge that the concept still must prove itself. And at a recent series of DOD workshops, a solid conclusion was that the key to making it work is education. “Education is the only real solution,” the workshop teams reported—both for program managers and for engineering teams. Some of the educational need is simply a matter of “acculturating” engineers and managers to working in ways sometimes quite different from what they are used to. A study of spiral development and similar concepts of speeded-up software development by two software engineering educators, Laurie Williams of North Carolina State University and Richard Upchurch of the University of Massachusetts, pointed to a number of ways students may need to be trained differently to prepare them for the rapid cycles and teamwork required. Spiral development, among other things, makes it extremely important that software be simple, transparent to all members of the team, and easy to modify. That’s not always a part of the “culture” among software engineering students. “Students sometimes develop a ‘macho’ attitude toward programming, whereby the ‘smart’ programmers take pride in developing code only they understand,” Williams and Upchurch note.

Loners need not apply

Another “cultural” trend that educators may need to explicitly counter—by devising exercises and situations that force student teamwork and collaboration—is the tendency for students, who now usually own their own computers, to spend more and more time working odd hours by themselves in their rooms. “In some regard the academic world has promoted a view of the software developer as the nocturnal loner….This perspective needs a serious revision,” they write. And finally, engineers will need greatly improved communication skills to deal with their customers on the nearly continuous basis spiral development demands, to present results and get feedback.

Boeing’s Wooley, who has a B.S. in software engineering from the University of Illinois and an M.S. from Seattle University, has worked at the company for 20 years on a variety of more traditionally conceived aerospace programs, including the AWACS aircraft and the Inertial Upper Stage satellite booster rocket. Working on J-UCAS has meant adapting to an environment with more freedom but also more uncertainty. In traditional development, once the final design is set “change is resisted and control is rigorous,” Wooley says. “In spiral development, the biggest challenge is the delicate balance between freedom and control. If you change too often nothing is ever accomplished and you spiral out of control. If there is too little change, then the system does not adapt to what is learned from the previous spiral.”

The concept of continual spirals closely parallels another paradigm-breaking concept in the J-UCAS program, namely, that it is being conceived less as an airplane than as a networked information system. “The vehicle…is merely the host around which the system is built,” Mike Francis, director of the J-UCAS program at the Defense Advanced Research Projects Agency (DARPA), explained at a DARPA technology conference last spring. The “soul” of the system, he said, is the way information is exchanged and processed among the vehicles and ground operators to build up a picture of the “battle space” and manage attacks on enemy targets.

Navy Captain Ralph Alderson, deputy director for the X-45 program, goes so far as to term the 12,000-lb., prototype X-45A vehicle a “software development tool”—a striking description for a program that, by any measure, also involves groundbreaking aeronautical engineering to build a stealthy, highly maneuverable aircraft. Yet to substantiate his point, the last two sub-spirals in the X-45A have consisted almost entirely of software improvements without any significant changes in the airframe itself.

The key idea, say the DARPA managers of the program (which is also being jointly funded by the Navy and the Air Force), is to put in place a system architecture basic and flexible enough so that it is not dependent on any single airframe or ground control station but which, by its very nature, can incorporate both new hardware and software improvements. Both the X-45, and the parallel X-47 being developed by Northrup Grumman, use a common software operating system built around fundamental functional concepts—sensor management, communications management, attack management—rather than the particular designs of their individual vehicles.

A critical question that Wooley and the team of 120 software engineers on the Boeing project are now exploring is the right balance between autonomy and human control. Much of this work has been carried out through computer simulations that can be done in parallel with actual flight testing, further speeding the development process. “We’ve tried to combine the rigors of the flight program by expanding the envelope with what you can see operationally in a simulation environment,” Wooley says. “We can fly two vehicles at Edwards [Air Force Base] because that’s what we’ve built. But in the simulation lab you can fly multiple waves of 16 vehicles—and in a more aggressive environment than what exists in Southern California. And eventually we’ll get to a point to where the operator wouldn’t know whether he’s flying a real aircraft or not.” The two X-45As have logged about 30 flights so far, but thousands of simulated flights have been flown in the lab.

“A big part of spiral development is leveraging the simulation environment to prototype concepts,” Wooley says. In the latest software iteration, the Boeing engineers are experimenting with allowing a ground controller to specify a high-level mission objective rather than, say, simply directing the plane to fly to a specific waypoint. Thus the ground operator might just instruct the system to provide surveillance in a specified area or patrol a certain sector and attack any surface-to-air missile radars it detects.

Bandwidth Demand

This concept requires groups of unmanned vehicles to communicate with each other in making decisions. A major problem in operating any remote vehicle is the high bandwidth demands when passing a lot of data back and forth between the plane and the ground; that problem becomes especially acute when the planes are beyond visual range and satellites have to be used to relay the signals. Shifting as much of the analysis and decision-making to the vehicles themselves and allowing them to talk directly to one another via line-of-sight radios alleviates the “communications bottlenecks” that Wooley said they identified from their tests in earlier software spirals.

So in the latest iterations, the vehicles might be given the capability, for example, to work together to track and identify moving targets on the ground—rather than having to pass back a stream of high-resolution images to a ground controller, which eats up huge chunks of bandwidth. When the unmanned vehicles have identified a target they could then “confer” with one another on their relative locations, their individual fuel and weapons loads, and their other mission assignments to decide which plane is best able to carry out the actual attack. The vehicles might also cooperate to fly in formations or execute other “group self-defense tactics” that provide mutual support when called for in high-threat environments.

The latest simulation tests have also explored having a single ground controller manage up to four planes at a time. It’s not like flying a radio-control model: The ground controller has no stick and not even a TV image to follow the plane’s movements. (In early flight-tests of the X-45A, a nose camera was installed, mainly to help the controller while taxiing—and, as Wooley says, to “give the operator some comfort that he can see a horizon” and is not about to crash. But “that will go away” in the next stage: “it really doesn’t work,” Wooley notes, “when you have four of them” to try to keep your eye on all at once.)

Overall, it’s less like being a pilot than being a system manager, and a crucial question being explored is exactly how much information the controller needs to have to feel comfortable allowing the airplanes to attack targets with lethal force, or even fly, on their own. “We’ve learned a lot about what the operator needs and expects to allow autonomous operation,” Wooley says of the simulations in earlier sub-spirals. Depending on the mission itself, there may be times when the controller can closely manage the plane’s movements; other times when it is best to have the plane offer suggestions to the controller; and others when the system will say, in effect, “I intend to do this if you say so” or even, “I intend to do this unless you tell me not to.”

The X-45C is expected to be flying by 2007, as will Northrup Grumman’s similar X-47B. That is a timeline more typical of the fast-paced world of commercial information technology than of government-funded weapons and aerospace programs. But it’s probably no coincidence given the “network-centered warfare” concept that is driving the J-UCAS program. And in an era when prevailing on the battlefield is about information superiority, it’s probably a safe bet that spiral development and similar concepts involving rapid and continual improvements will increasingly be part of the way new weapons systems are engineered.

Stephen Budianski is a freelance writer based in Leesburg, Virginia.