By J.R. Wilson
Removing long military development and procurement cycles from a new vehicle can have a significant influence on how engineers approach creating an avionics system that takes best advantage of rapidly evolving commercial technology. Perhaps nowhere has this been clearer than with the NASA/Lockheed Martin X-33 advanced technology demonstrator.
The X-33 is a half-scale, sub-orbital prototype of a reusable, single-stage-to-orbit launch vehicle. Developers expect the follow-on commercial vehicle, called the "VentureStar," to lower dramatically the cost of space flight from about $10,000 per pound to orbit to $1,000 or less.
As with all new government programs, X-33 relies heavily on commercial-off-the-shelf (COTS) components - but how engineers choose COTS parts and incorporate them into the commercial spacecraft differs significantly from how they use COTS on most military aircraft.
"We have leaned more toward COTS for X-33 primarily because we needed low-risk hardware and software development tools immediately, on day one of the contract," says Tony Jacob, head of X-33 business development for Lockheed Martin Aeronautics Company-Palmdale (formerly known as the SkunkWorks).
"The standards on the F-22, for example, looked at the equipment over a very long lifecycle," Jacob says. "For X-33, we're building one vehicle and trying to do that quickly, which is why we needed these things immediately."
Avionics development
Avionics for the X-33 are the responsibility of Honeywell Commercial Systems of Clearwater, Fla., under the direction of X-33 program manager Jose Aldana at Lockheed Martin.
The system they designed is a triplex configuration tailored on aircraft-style architectures to provide aircraft-level reliability. The vehicle management computers at the heart of the system interface with the rest of the subsystem through a series of MIL-STD 1553 databuses. All the mechanical and avionics subsystems on the vehicle connect to that subsystem, either directly to the bus or through one of the data interface units.
The three redundant vehicle and mission computers (VMCs), which run in lockstep on a frame basis, handle all guidance, navigation, and control computations, as well as manage all avionics subsystems on the vehicle. There also are two forward and two rear data interface units and four engine-control data interface units, each using a VME backplane and ruggedized COTS cards. In addition, several I/O cards are aboard the aircraft. The cards are about half COTS and the rest custom-built by Honeywell (AlliedSignal at the time) and packaged in a custom chassis that is cold-plate cooled.
The 11 processors in the VMC use the PowerPC 603e microprocessor running at 100 MHz. Honeywell officials say they chose the PowerPC because it represented the least risk, was available in a ruggedized version, and was compatible with the VxWorks software development tools from Wind River Systems in Alameda, Calif.
"We went out of our way to avoid anything risky on X-33," says Dana Alden, Lockheed Martin's X-33 avionics lead. "This program is a giant step for rocketry and we didn't want the avionics to get in the way of that happening. There will only be a few VentureStar vehicles. You can afford to upgrade a few vehicles more often than you can a fleet of 600 aircraft. So as new demands come down the road for VentureStar, they can be upgraded. That's why sticking with the COTS approach makes a lot of sense - you want to be able to upgrade it at low cost. And the avionics for X-33 have been very low cost."
Aldana says he agrees: "The philosophy behind the vehicle management computers was to ensure we could have an architecture that could grow in time without having to redesign the whole architecture. As the technology either matures or advances, we should be able to go to a different set of cards that we can implement without affecting the overall system in terms of form, fit and function."
Setting the stage for faster processors is only part of the upgrade plan. A high-speed databus will be necessary to deal with VentureStar's increased information sharing among processors and between each of the avionics elements. The high-speed databus also will interface with payload and possible high-speed communications requirements, such as video, that are not part of X-33.
While designers will base that decision on available technology at the time, the current thinking is that something like a 100 megabit-per-second Fiber Distributed Data Interface (FDDI) fiber optic bus will replace the 1 megabit-per-second 1553.
"I suspect whatever the JSF [Joint Strike Fighter] program decides on will become the de facto standard for the industry on the military side and we'll probably follow that in terms of bus architecture. They haven't decided yet and probably won't until they make their proposals," Dana says. "The technology is moving so fast it's hard to keep up. A few years ago everyone thought the F-22 would dictate the standards for the next 50 years, but JSF certainly is going to pick a different set of standards. You have to move on; you can't just stand still."
While the X-33 avionics requirement does not push the envelope, relying heavily on a standard avionics architecture and many COTS elements will require some unique applications. For example, the
X-33's inertial navigation and global positioning systems (GPS) will be the drivers in meeting it's highly constraining accuracy requirements for landing, using GPS and differential GPS inputs to implement vehicle guidance.
The design features a vehicle health-monitoring system comprising 50 small remote health nodes scattered around the vehicle, which collect temperatures, pressures, and vibration levels. Each node has its own PowerPC processor and links to the others by FDDI buses. The system, built by Sanders, a Lockheed Martin company in Nashua, N.H., can collect as many as 1,200 different parameters.
All of these systems have been designed from the beginning to evolve with and make the best use possible of new technologies.
From the VentureStar spacecraft "we will try to get as much benefit out of ongoing aircraft-type hardware and software development as possible [for VentureStar], but on selected avionics units, we will want to take advantage of the technology that will be available five or six years from now, with the emphasis on reduced size, weight, power and cost," Aldana says.
While the suborbital X-33 can live with systems that meet the environmental operational standards of the F-22, the follow-on VentureStar will face more serious vibration, temperature, and radiation concerns. To deal with those, engineers as much as possible will place COTS elements in a "cocoon" that will buffer them from the environment. But while tailoring the environment is less costly than modifying components, it is not always a workable solution.
"In a lot of instances, you are going to have to have the science to meet the requirement rather than continue to try to baby the unit as much as you can," Aldana says. "Take sensor accuracy - the inertial measurement unit, for example. If you have to use vibration isolators, your measurements can become meaningless because you are isolating factors you want to measure. In those cases, you will have to have units designed specifically for the environment, so a COTS approach may not be as useful as you would like it to be."
Even so, designers at Lockheed Martin and Honeywell say they believe the commercial VentureStar will grow out of the heavily COTS-reliant X-33 smoothly and with an open architecture that will enable its avionics and other systems to evolve economically with the advance of commercial technology.
"In general, the architecture we put together is the first step in the integration of COTS into a vehicle for the space environment," Aldana says. "We believe we can move from this first step on with significant lessons learned on X-33 that will allow us to isolate the best features of this architecture and in all probability modify it to eliminate the drawbacks. We believe we have been successful in achieving the goals of the X-33 program and learning enough to optimize this architecture on future programs."
null
