The U.S. Defense Advanced Research Projects Agency (DARPA) aims high for the first generation of purpose-built, armed unmanned air vehicles (UAVs). Its Joint Unmanned Combat Air Systems (J-UCAS) program, which unites earlier Air Force and Navy efforts, would take avionics software to a new level. J-UCAS’ vastly complex common operating system (COS) would allow two different designs to work together seamlessly as a single combat system that could operate independently, short of pulling the trigger. This article describes the program at the moment before it moves from DARPA’s control to an Air Force/Navy joint program office.
Software plays a dominant role in UAVs today. Elbit Systems, manufacturer of the Hermes surveillance UAVs, feels, for example, that using a certifiable partitioning operating system—the core software of an individual computer—is key when “software with multiple safety indexes must be executed on one CPU [central processing unit],” says Shimon Sarid, vice president of Elbit’s UAV Systems Division. He also stresses the need for “layered software” to insulate the applications from the hardware and increase software portability. Computers depend on localized operating systems to manage resources such as hard drives and network cards.
DARPA’s common operating system, however, is a different animal, enabling the vehicles’ autonomy. The software would touch practically everything—command and control (C2), coms management, mission planning, human systems integration and vehicle interactivity, as well as contingency, route and stores management, and sensor, track and mission management. COS is also about reaching out to the global information grid—the Internet in the sky—connecting with the command structure and culling data and applications. Information from networks conceivably could cue aircraft sensors, says Rick Ludwig, Northrop Grumman’s X-47 director of business development. “Possibly, if the information is of high enough fidelity, you could actually cue the weapon and release it without a sensor on the aircraft having to find the target,” he muses.
J-UCAS researchers envision stealthy, networked UAVs operating all but autonomously over the battlefield. The aircraft would react to changing situations and collaborate among themselves to decide which one of them is best situated to find, image, identify and destroy targets. Key missions include the destruction of networked air defense systems, deep strike, penetrating electronic attack, and intelligence, surveillance and reconnaissance. As missions have grown, so too have the vehicles. The demonstrators being developed for J-UCAS are between an F-16 and an F-117 in size. Boeing’s X-45, for example, will grow from 8,000 pounds to 18,000 pounds (3,629 to 8,265 kg) empty weight from the A to the C version. The vehicles will fly at high subsonic speeds at altitudes greater than 40,000 feet with a 1,300-nm combat radius (unrefueled), which is considerably greater than what today’s manned fighters can do.
Based on its heritage, Boeing’s X-45C reflects the Air Force’s interest in stealthy, “first day of the war” missions, while Northrop’s X-47B reflects the Navy’s need for carrier-based operations. But Northrop is studying emerging Air Force requirements and says it could modify its third demonstrator aircraft into an “X-47B+.”
At this size and with these planned missions, the J-UCAS aircraft clearly have to be competitive with manned aircraft to survive into production, acknowledges Michael Francis, DARPA program director. The bar “needs to be raised” on the unmanned side “in the area of mission functionality.” That’s where COS comes in, as the “de facto integrator,” not only within vehicles but between them.
DARPA has a lot riding on COS, which it sees as the government’s opportunity to free core software from dependence on air vehicles—and on airframers, the prime contractors who typically control airplanes once they win the competitions to produce them. COS promises architectures that can smoothly incorporate “best of breed,” third-party applications as they emerge.
“OSD [Office of the Secretary of Defense] interest in COS is significant because of the leverage it has for interoperability,” asserts Francis. “For the first time we’re building the hard part of IT [information technology] and segregating it from the platform.” Once you do that, he declares, “you can tackle problems separately because you don’t have the industrial age component [the airframe] fully intertwined with the information age component from a schedule and cost point.” The software would be easier to upgrade, as well.
So DARPA is treating COS a little like the Manhattan Project, the secret nuclear bomb effort in World War II, Francis smiles. The agency set up a consortium, in which the primes—who are building different parts of COS and must share data with each other—are refereed by a third party, Johns Hopkins’ Applied Physics Lab, known as the integrator broker. The J-UCAS program, in its current DARPA guise, deliberately avoids a “lead systems integrator,” a contractor “daddy rabbit,” as Francis terms it, who acts as the overall integrator for the government. The integrator broker, a neutral intermediary, maintains COS configuration control and ensures that new ideas from third parties get a fair hearing.
The J-UCAS program has endured large budget hits and schedule stretches, as a result of pressures on Pentagon spending. But it’s still intact. “The fact that we went through this president’s budget and came out alive is very telling,” says Ludwig. “As a $4- to $5-billion program, we could easily have gone away.” He expects a procurement decision around 2010,
The challenges surrounding J-UCAS are formidable. How do you get the same effect multiple times and never give the enemy the same look twice, Francis asks. How do you become unpredictable, so you can achieve your desired effects? And what are the implications for the test community if software—the COS—doesn’t deliver the same answer twice in a row?
The economic assumptions of the COS development plan are being questioned, as well. For example, what incentives would third-party software developers have to contribute “best of breed” applications if the government shares their source code with others on the program?
At the top of the list is uncertainty as to the program’s direction. J-UCAS is moving to the military this fall, just as COS development accelerates. Will the Air Force, designated last year to lead the program, want to scale it back to save time and money? If so, how deep and broad will the software’s eventual footprint be?
Despite the challenges, J-UCAS and predecessor programs have made impressive strides. The Boeing X-45A, which has enjoyed a long flight test program, has released inert GPS-guided bombs, flown two-vehicle mock sorties, and demonstrated autonomous attack planning and beyond line of sight control.
The program eyes the following objectives: to build and fly the airplanes to verify basic performance (takeoff, navigation and landing); to demonstrate the feasibility of COS and the ability of the aircraft to perform combat missions; and to generate enough data from flight tests to allow the military to make informed decisions about further development and acquisition.
COS encompasses three software stages: Build 0-infrastructure, Build 1-single ship, and Build 2-multiship, the last of which stretches out till 2009. Boeing has delivered COS data management and discovery services, as well as publish/subscribe components—as part of Build 0. Discovery services allow UAVs to locate applications, such as mission planners and autorouters, on networks. This middleware, some of which derives from Boeing’s Future Combat Systems program, provides the infrastructure on which mission application software can run.
Northrop is focusing on the contingency, route, sensor, weapons and enterprise services management, as well as the platform portability, human systems interface and coms aspects of COS. The company has gotten the green light for its Build 1 proposal, but the contract was still pending at press time in August. Other companies, termed technology contributors, also will have opportunities to participate in areas such as the human system interface, autorouters and target cuing.
Boeing and Northrop each will build three, progressively more capable demonstration aircraft—the X-45Cs and X-47Bs, respectively—and begin flying the first of them in 2007. DARPA wants to reach the point where an X-45C ground station can control an X-47B and vice versa. The ideal: “a net centric system of systems where the platforms, sensor and weapons are the peripherals [to the COS],” Francis says. The whole would be much greater than the sum of the parts.
Boeing’s X-45As have made more than 60 flights, stretching back to May 2002. In August the company completed a “graduation program” at Edwards AFB, Calif., a mission to preemptively identify, attack and destroy simulated enemy air defenses—ground-based radars and missile launchers. After takeoff, the pair of UAVs used onboard decision making software to select the best flight path within a 30-by-60-mile area of action. Evading an unexpected, pop-up threat, the duo autonomously determined which vehicle held the best position, weapons and fuel to attack the higher-priority target, says Boeing. After the ground pilot authorized the simulated attack, the X-45As “destroyed” the target and returned to base.
Northrop Grumman’s Global Hawk UAV pushed autonomy at the platform level, moving to a mouse-driven interface. But J-UCAS pushes autonomy at the system-of-systems level, where multiple aircraft cooperate. To date an operator has controlled two vehicles in flight, four vehicles routinely in simulation, and six vehicles in the lab. J-UCAS envisions flexible, distributed and redundant command and control, Francis says. Responsibilities could be distributed among multiple remote operators. One could handle sensors, another, trajectory management, and yet another, after-action damage assessment. The Air Force and Navy are exploring these issues in simulation. DARPA last year demonstrated X-45 control handoff via satcom between remote operator control stations. Ultimately, the control element could be hosted on airplanes, ships and ground stations.
The X-45A allows the pilot to set the level of autonomy—from the aircraft’s asking permission at every juncture to executing an action unless the pilot intervenes within a certain time. Its avionics systems—in come-as-you-are format, taking up one of two weapons bays—included Boeing-built vehicle management and mission management computers, Rockwell Collins ARC-210 UHF coms and BAE Systems Link 16 data link. The A version—essentially a “Spiral 0,” concept plane—had a 34-foot (10-m) wing span, and 27-foot (8-m) length. The X-45C, by contrast, boasts a 49-foot (15-m) wing span and a 39-foot (12-m) length.
The X-45A is pretty much “a fly by mouse” aircraft, says Jim Martin, Boeing’s director of X-45 system test. The operator console has two screens—a navigation display and air vehicle parameter display. The workload is manageable, however, as the vehicle does its own administrative work, tracking fuel, not-to-exceed speed, maximum G loads and sideslip angles, and the health of its subsystems. It notifies the operator when something has failed.
The next step for Boeing is the X-45C, which will have real rather than simulated sensors, such as passive listening electronic support measures (ESM) and synthetic aperture radar (SAR). Its avionics will be more representative of a production airplane, says Bob Kornegay, the company’s X-45 business development manager. The X-45C is the vehicle that Boeing will take into the J-UCAS operational assessment, scheduled to run from 2007 to 2010. There are two X-45Cs in production now, and first flight is slated for March of 2007.
DARPA calls for a common sensor suite, common mission avionics and software applications initially in order to reduce costs and lower the barriers to the entry of new technologies. Both will use the ALR-69 ESM gear, says Ludwig. Raytheon, under a separate USAF contract, will incorporate network-enabled signal direction finding into the ALR-69 radar warning receiver with an eye to the suppression of enemy air defenses. Such technology would enable several J-UCAS to “sniff” the same emitter from different locations, refining its position down to the point where it could be targeted, Ludwig says. If the program exercises an option for SAR radar, Raytheon’s APG-79 has been selected. The Air Force Research Lab (AFRL) also has authorized Raytheon to produce the X-Band thin radar aperture (XTRA) conformal, load-bearing radar antenna for the J-UCAS program. Additionally, Link 16 LVT 6 equipment and a wideband satcom link will be required, according to Northrop. Electronic attack sensors have not been determined, but could be added as a pallet in the weapons bay.
The X-45C features dual, Smiths mission computers, triplex vehicle management computers (VMCs) by BAE Systems and Collins UHF ARC-210 coms, says Boeing. Smiths also provides X-45C remote interface units, memory storage, nose wheel steering and secondary power distribution. The X-45C’s vehicle management computer will use Green Hills’ Integrity-178B real-time operating system. On the traffic management side, Boeing’s X-45C will be able to link to air traffic control through the unmanned aircraft if there is no line of sight link with the tower. Boeing Phantom Works, under contract with the AFRL, is developing air refueling capability which will be demonstrated in 2010 and out, Kornegay says.
The X-47B’s wing span of 62 feet (19 m) will outstrip the F/A-18, but the fuselage (at 38 feet/12 m) will be much shorter. Gross takeoff weight will be 46,000 to 48,000 pounds (20,866 to 21,773 kg), Francis says.
Smiths provides the X-47B’s triplex vehicle management computers—with high-speed, cross-channel links—and dual-redundant mission computers. The VMCs also will host fuel measurement and management software developed by Smiths, says Al Hughes, the company’s director of business development and strategy.
Smiths is providing the mission computers for the Boeing and the Northrop vehicles, but internal “firewalls” have been set up to separate the teams. The mission computers will be the “real home” of the ARINC 653 operating system, Hughes remarks, alluding to the fact that multiple applications are expected to reside there. The X-47B’s mission computer and vehicle management computer will use Wind River Systems’ ARINC 653-compliant, partitioning operating system.
The X-47B will feature four to five different types of data buses, and the company is looking at data links such as the ARC-210, tactical common data link, common data link and tactical targeting network technology. Northrop describes a mission data storage unit, which would buffer and archive raw data from the synthetic aperture radar. Since the SAR payload is optional at this point, however, the storage unit is provisional, as well. Current plans call for payload management software to reside in the X-47B’s mission computer. The company already is testing vehicle management computers, mission management computers, navigation and coms systems in its system integration lab, Ludwig says.
Because J-UCAS vehicles are large, avionics integration is less urgent than it would be on a smaller vehicle. Northrop, for example, doesn’t intend to pursue integration to the extent practiced on the company’s small, unmanned helicopter. In Northrop’s Fire Scout, Ludwig points out, two vehicle management computers “do everything.” If you want to put a different sensor on, you affect the software on the VMC, he explains. Northrop’s J-UCAS distributes software functions among all the computers on the aircraft, Ludwig says. Computer hardware plays second fiddle. “We’ll take anybody’s computer hardware and develop the software that will go in there.”
J-UCAS also has generated a significant simulation effort, to look at human factors issues, concepts of operation (conops) and tactics, Francis says. The new technology probably is not best optimized by conventional conops, he adds.
The bottom line, however, is to evaluate J-UCAS software in a series of events in order to reduce the risks ahead of the actual operational assessment, which begins in 2007. That includes COS, as well, says Richard Graeff, UAV modeling and simulation lead at the Air Force’s Simulation and Analysis Facility (SimAF). “Early copies of COS are available, and we’ll start poking around with that [in the] late fall.” SimAF already has X-45A and X-47B software models, and will get X-45C software, too. The Navy’s China Lake test facility will get both primes’ simulations, as well, so that the services can perform independent evaluations and conduct distributed simulations with Boeing and Northrop.
In preparation for this, SimAF is improving the fidelity of its satcom modeling, including send/receive antennas and data link latencies. Another focus is modeling the ground threat, Graeff says. To support detailed simulations of real geographical areas of interest, the resolution of the multispectral terrain database has to be high enough to realistically represent images of ground targets and terrain that could be taken by synthetic aperture radar, electro-optical or infrared sensors.
SimAF also is supporting a high-level, distributed simulation of combat UAV capability with the UK’s Ministry of Defence. The first event, slated to begin this fall, will explore issues such as coalition conops and interoperability in manned and unmanned coalition scenarios such as the destruction of enemy air defenses.
Small UAV Avionics
Unmanned air vehicles (UAVs) in the 100-pound (45-kg) class can’t afford the weight and electrical power required by multiple computers. So BAE Systems is heading to higher levels of integration in its VTOL (vertical takeoff and landing) UAV, a coffee can-shaped vehicle used as a technology demonstrator. The aircraft’s computer, itself a developmental item, integrates flight control, navigation and mission planning, says Kurt Vieten, chief systems engineer for BAE’s VTOL UAV programs. The flight control navigation computer, or FCNC, as it is known, essentially replaces the flight management system, attitude heading reference system, air data computer, and the flight control, navigation and mission computers. Only the inertial measurement unit is external.
FCNC uses a stripped-down, real-time executive as its operating system, but you can just “drop applications into the computer,” he says. The box weighs 7 pounds (3 kg), but BAE wants future iterations to get below 5 pounds (2.3 kg), including embedded sensors. Integration, especially at this size, is the path to lower weight, power, volume and cost, Vieten says.