By J.R. Wilson
Designers and users of aviation electronics face daunting obsolescence issues as they try to bridge the old mil-spec era with the new commercial off-the-shelf world to keep equipment up to date and in the field at reasonable costs
The rise of commercial-off-the-shelf (COTS) components, especially in the fast-moving world of electronics and microprocessors, has forced the military to create open-architecture avionics systems wherever and whenever possible. While this is a much easier task on new programs than it is on the old platforms, traditionally lengthy military design and procurement schedules constantly lag behind increasingly rapid commercial cycles, which can see a new processor run from introduction to obsolescence in only two or three years.
The current V-22 cockpit (pictured above) and avionics layout contrasts the four main CRT displays of the older technology that will be replaced with the one (center) flat panel display already onboard.
The Pentagon has a long history of trying to bring commonality and open architectures to avionics.
The Air Force's Pave Pillar specification from the early 1980s was intended to create a modular, open, fault-tolerant, and flexible architecture for digital avionics. The program aimed specifically at the signal processing tasks of radar, communications/navigation/identification-friend-or-foe, electronic warfare, infrared search-and-track sensors, electro-optical sensors, and antisubmarine warfare - all better known by their acronyms respectively as CNI, EW, IRST, EO, and ASW.
In the early 1990s, Congress mandated the Joint Integrated Avionics Working Group (JIAWG) to create standards for the Air Force Lockheed Martin F-22 fighter, the Army Boeing-Sikorsky RAH-66 Comanche armed scout helicopter, and the (now cancelled) Navy A-X attack/fighter.
Some programs still considered new by military standards - such as the Marine Corps V-22 Osprey tiltrotor aircraft, which has just entered low-rate initial production - predate JIAWG. On these programs, systems designers are attempting to upgrade within the production cycle by migrating as many technologies as possible from other programs.
Commonality questions
Despite its lofty goals, even JIAWG ultimately proved to be of limited long-term impact.
"Mandated commonality has been tried and has not been very successful," admits Don Winter, manager of open systems research and development at the Boeing Phantom Works in St. Louis. This is true especially where the government designated two very different platforms, such as the F-22 and Comanche, to have the same avionics architecture, Winter says.
Though JIAWG's results may have fallen short of its goals, the Comanche nonetheless did have the largest influence of any other aircraft on the F-22 avionics design, points out Ron Shue, site director for the F-22 at Lockheed Martin Aeronautics Co. in Fort Worth, Texas. This is so because of early initiatives to meet on a regular basis and establish specific compatibility requirements that were incorporated into the design, he says.
Raptor 4002, pictured above, passes its 300th flight hour - the first F-22 to do so - during an 18 February 2000 sortie from the U.S. Air Force's Flight Test Center at Edwards Air Force Base, Calif. The F-22 fleet is expected to grow in the coming weeks, as Raptor 4003 makes it maiden flight from Lockheed Martin's facility in Marietta, Ga., before joining the test force later this year.
"Early in the program we established interfaces - high-speed databus, connectors, power supplies - to be complaint with the understanding of JIAWG at that time," Shue says. "We went through critical design reviews to meet their standards. We still have those standards today, although I can't speak to how well we've kept common to other platforms, such as Comanche. As JIAWG became less of a factor over time and we solidified our design, we stopped having regular interactions at the design level."
Commonality, while still a desired goal, is no longer seen as being as important between disparate programs as is an open-systems design within each program. The Pentagon's Tri-Service Open Systems Architecture Working Group defines an open system as one that "implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be used across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems and to interact with users in a style that facilitates portability. An open system, the working group says:
- has well defined, widely used, non-proprietary interfaces/protocols;
- uses standards developed/adopted by industrially recognized standards bodies;
- defines all aspects of system interfaces to facilitate new or additional systems capabilities for a wide range of applications; and
- has explicit provision for expansion or upgrading through the incorporation of additional or higher performance elements with minimal impact on the system.
"Reality set in on JIAWG during the 1990s," notes John Harrell, manager-Joint Strike Fighter (JSF) mission systems sensors at Lockheed Martin. "Trying to take advantage of technology - especially in the way the PC and cellphone markets are advancing - has required us to do some different things. When we get outmoded parts notices, we have to be ready to accommodate those. This has caused a new design philosophy to come about to make the avionics systems for new-generation aircraft affordable for the customers."
Program engineers of new aircraft avoid tying themselves to any one computer microprocessor or even family of processors (such as Intel's Pentium series). Instead, they are writing software that will, to the greatest extent possible, port across many different processors.
Avionics engineers at the Boeing
Helicopters division in Philadelphia and Sikorsky Aircraft Corp. in Stratford, Conn., originally designed Comanche with a flight computer based on the Intel i960 microprocessor. Yet when Intel abandoned that product line, Boeing-Sikorsky designers had to make other plans. After a successful demonstration of replacing the i960s with Pentium chips with only minor software changes, the program switched to the original 133 MHz Pentium - the only one that has been approved for ruggedization. Now, however, they face the same dilemma all over again as that chip has gone out of production and they have been advised Intel will soon stop supporting it.
"Our goal was to put us into a commercial growth path so we could capture the increased speed and power of the processor. We haven't upgraded the processor again because we haven't really needed to," explains Comanche avionics engineer Tom DuBois of The Boeing Company of Philadelphia, adding they are working on a backup plan involving the use of more modern, open system architecture concepts.
"You have to address the problem from a lot of angles, DuBois explains. "First, you only need as much performance as you need. Our goal is to get to processor independence in the way our systems are designed, so it doesn't really matter whether it is an Intel or PowerPC or whatever, so long as it conforms to our needs. We hope to put as much commercial architecture as possible around the chip so that when the commercial industry makes advances we can plug them in to our rack without requiring a lot of costly changes."
Computer power supplies are also an issue, DuBois says. "If the power requirements change as the new boards are released, we'll still have ways to plug them in." That requires an open architecture - including software and the operating system - that allows for plug and play. It also means finding ways to address ruggedization without dealing directly with the COTS components, including the microprocessor. That generally means placing the COTS elements inside a benign environment that will absorb the shock, vibration, heat, cold, and other factors required of ruggedization.
Simplifying that process is what DuBois calls a "basic philosophy" of the Comanche structure. This approach calls on designers to pull as much electronic processing out of the mission equipment as possible and isolate it into the core. It was a concept that came out of the JIAWG directives, enabling replacement of individual boards to achieve future upgrades rather than buying a whole new system box. It also creates one focal point for a ruggedized containment system.
Comanche computers
On Comanche, the current core cluster has a rack with 48 Standard Electronic Module-E (SEM-E) printed circuit board slots, which are for power supplies, data processor modules, general-purpose signal processors, fiber optic interfaces, and redundant systems. There are eight processors per cluster and two clusters per aircraft.
The SEM-E board format, however, can be a problem in an open-systems architecture. SEM-E is primarily a military aircraft standard, and has little commercial market support. DuBois says abandoning SEM-E will mean a significant cost reduction, but first he and his engineers have to figure out how to design it into the platform with the right number of slots.
That effort also is beginning to influence other programs.
This chart depicts the avionics architecture of the Lockheed Martin F-22 Raptor jet fighter, which is the first U.S. combat aircraft to have an integrated electronic architecture designed from the ground up.
"The V-22 is looking at an upgrade to their radar architecture, and their reconfigured mission computer design effort is looking more like Comanche," DuBois says.
In the V-22 avionics architecture, sensors will output digital data, which is too much bandwidth for a 1-megabit-per-second 1553 databus to handle, he explains. The V-22 will have a new radar with digital output, and a high-speed databus, "which is causing them to relook at the processors and design on that aircraft," DuBois says. "It has really been the Comanche program that has matured the high-speed fiber optic databus that can process up to 800 megabytes per second today. And we see a desire to go to 2-to-3 gigabits per second to handle future focal plane arrays." The Comanche uses an optical-fiber passive-star high-speed databus from Harris Corp. in Melbourne, Fla.
Comanche is also adopting advancements from other programs, especially in subsystems such as the Forward Looking Infrared (FLIR) sensor. In that instance,
Boeing-Sikorsky engineers are evolving the Longbow radar developed for the Boeing AH-64 Apache attack helicopter by reducing its size and weight by about half to fit the smaller Comanche. At the same time, they are adding sensor fusion, tying in IR and millimeter wave sensor data to reduce the incidence of false alarms and to add the ability to "see" across a wider spectrum of battlefield obscurity.
A full-scale F-22 forward section mockup is used for sensor integration testing in "free air" at Lockheed Martin Aeronautics Co. plant in Fort Worth, Texas. The facility helps with integration testing of the F-22's communication, navigation, and integration systems.
Also migrating onto Comanche is the Suite of Integrated RF Countermeasures (SIRFC), which replaces the Army's existing survivability equipment (ASE), including the AN/APR-39 radar warning receiver, AN/ALQ-136 pulse radar jammer, and AN/ALQ-162 continuous-wave radar jammer. SIRFC can geo-locate threats using its missile warning receivers, as well as incorporate real-time intelligence from a multi-mission advanced tactical terminal (MATT).
Because of the helicopter's stealth characteristics, the jammer in not necessary on Comanche, but will be part of the Air Force version of the Osprey, the CV-22, which also will receive SIRFC. Unlike its Marine progenitor, the CV-22 also will incorporate terrain-following/terrain-avoidance radar (TF/TA), an additional 900 gallons of fuel capacity, rope ladders, a survivor locator system, additional radios, and upgraded computers.
Comanche, F-22, and JSF also will have similar communications packages, including Link 16/Joint Tactical Information Distribution System (JTIDS), and a jam-resistant battlespace information network for U.S. and NATO forces. Link 16/JTIDS, which also is going aboard the B-2 stealth bomber, will substantially increase situational awareness by providing real-time information on threats, friendly aircraft, targets, and the overall air and ground order of battle to all friendly participants.
"With the [Comanche's] centralized architecture, it is easier to capture some advanced programs as they evolve and bring them onboard," notes Eric Stuverude, Boeing's business development manager for Comanche. "You reach a point where if you can get to 98 percent of the full mil-spec requirement; the military has become more flexible about tailoring their requirements to meet the commercial specs."
Rapid obsolescence
The Comanche's design approach, however, only increases the aircraft's vulnerability to the speed of commercial technology evolution. The government and program prime contractors are trying to find incentives for suppliers and program partners to take the obsolescent parts problem into account from the beginning and design ahead to deal with it.
Parts obsolescence has become an increasingly severe problem throughout the military, even on the newest programs with the greatest level of open-systems architectures. Prior to the mid-1980s, government funding drove much of the advancement in space and military technology. Today, the personal computer and telecommunications industries have fractionalized the government's status as a customer and, due to their fiercely competitive nature, are forcing technology forward at warp speed. As a result, electronic parts typically go out of production by the time systems designers have identified a specific part and approved it through the military process.
Thus open architectures create a dual-edged sword. A nearly total reliance on the commercial market means considerable time and cost savings in terms of research, development, and acquisition. At the same time engineers must design systems - and budgets - to accommodate frequent changes in hardware to keep up with the commercial world.
"In some respects, you don't need to mil-spec parts anymore," says Lockheed Martin's Harrell. "Most of the difference there happens at the end of the line rather than the beginning - how much testing is done at the end. But the military is such a small percentage of their business that a lot of vendors won't even do those tests. So, in many instances, we are taking industrial-grade parts and backing away from specifying mil-standard parts to be able to leverage COTS technology and field affordable systems."
For JSF, the central computer baseline calls for COTS technology and nearly all COTS parts, although not necessarily all COTS boards, leveraging commercial developments to the greatest extent possible to make it an affordable jet.
"Given what we've learned from legacy programs with out-of-production parts issues, we've done everything we can to make sure all of our systems and software are designed to handle the evolution of parts," Harrell says. "We've proven we can isolate changes in hardware from the software and port the software from one system to another, which is what allows us to isolate the systems from underlying hardware changes."
This is a more difficult process in the older "new" programs, such as the F-22, Comanche, and V-22. And more difficult still for even earlier designs, such as the F-18, F-16 and F-15 - and even the F-117 and B-2 stealth aircraft - although definitely part of the military's long-term effort to keep all of its aircraft operational for more years than originally expected.
"There have been some success stories under the overall dual-use technology initiative, for example," Winter says. "Under the commercial operations and support cost savings initiative (COSCSI), which is a pool of funding administered and awarded by DARPA, you can submit proposals for matching funds against industry funding. We've actually jump-started the current avionics modernization initiatives for the F-15 and F-18 with COSCSI programs awarded back in 1998. That gave those SPOs the money they needed to do the upgrade in an open COTS fashion. But that is a limited budget and only so many programs can be awarded."
One path to commonality in upgrading old systems and bringing them into closer alignment with newer platforms is more a matter of serendipity than intent, a result of supplier-level interaction and synergy. For example, the modular mission computer on the F-16 and the vehicle management and utilities subsystems on the F-22 have similar processors because engineers used a lot of the toolsets and expertise at Raytheon on both.
Another example is at Boeing, where common architectural underpinnings across several different platforms are making it sensible to pursue subsystem-level upgrades in sync. Boeing is involved in modernizing the display subsystems on five old Air Force platforms. Because one company is directing that work with common suppliers, they are finding cost benefits to performing those upgrades in step rather than having each program go through all the steps individually.
But the past comes into play on the majority of cases, especially where different contractors are working on diverse programs. So-called "stovepipe procurement"- the very way in which military programs are developed, administered, and funded - hamstrings the real potential for savings through open-architecture designs in avionics.
"The individual government program manager is not incentivized to look horizontally," Winter says. "Even without mandating commonality, some conscious decisions to collaboratively pursue some avionics initiatives across programs could result in some serious program cost savings. But within the current system, how do you get a C-17, B-1, and F-22 on the same page when they are managed by separate organizations and contractors?"
He identifies two basic challenges in the acquisition system: the inability to work horizontally across different programs and the inability to budget and plan acquisitions on a multi-year basis.
"You can build a compelling case, but the program manager in the government often can't do it because the front end is underfunded, so it defaults back to business as usual," he says. "Once something gets into the POM [program objective memorandum], it has a lot of inertia, so even if someone demonstrates later that infusing a lot of COTS into it can save money, it's just too late."
One way the Pentagon has tried to work around this problem is with performance-based contracting. Rather than detail how contractors should achieve a result - complete with military specifications and military standards - the military tells prospective contractors its expectations. It is up to the contractor to develop the lower-level allocation of requirements for those elements. That has enabled the commercialization effort. Designers can take some modules originally designed to be manufactured on a militarily compliant line, for example, and build them in a commercial facility, using commercial parts. This can achieve the same performance, reliability, and life at often greatly reduced cost.
Many experts believe that each advance in one program does influence others, despite the roadblocks that Winter cites.
"The concept of having everybody that works in avionics use the same data processor and signal processor and the same tools and development processes has been influenced by F-22 because we led the way in establishing the protocols everybody else is supposed to use," Shue says. "We're just now getting into the meat of sensor integration on F-22, but other programs will learn from us as we do sensor and data fusion and simplify the job of combat for the pilot.
"In communication/navigation, where we are responsible for sensor fusion across multiple capabilities, we learned from initial efforts we took on the F-16 to do that job. And we learned form R&D done here at Fort Worth, which was one reason we were selected to do that job for the F-22."
Of the "new" aircraft programs, the V-22 is the oldest, predating the JIAWG initiatives. Robert Leblond, Osprey avionics systems manager at Boeing, says he and his engineers are studying all the other new programs to find ways to migrate the best in new technologies onto the V-22. For the moment, the best possibilities are at the subcomponent or small components level.
"One of the best examples is how all the platforms are going to flat panel displays," he says. "We made a decision on V-22 back in 1993 to continue to pursue CRT [cathode ray tube] technology in displays because we thought it was less risk to the program than flat panel. Between then and now, flat panels matured and their lower cost and higher reliability have been taken into account and rolled back into the V-22. So now we will cut in flat panel displays at the end of Lot 3 going into Lot 4, which puts them on in-line production airplanes toward the 3rd quarter of next year."
Osprey's current display system and the electronics that go with it come from L3 Communications in Alpharetta, Ga. A competition last year awarded the contract to convert to flat panel displays and new electronics to EFW-USA in Fort Worth, Texas, a U.S. subsidiary of Elbit Systems Ltd. in Haifa Israel. EFW also provides the V-22's digital moving map.
Unlike Comanche, Osprey does not have a modular-based system. Its mission processors, provided by GD Information Systems in Minneapolis, use two RM5271-based discrete computers in each airplane. The RM5271, based on the MIPS IV instruction set architecture, is from
Quantum Effect Devices Inc. of Santa Clara, Calif. The system currently cannot be defined as open architecture, even though there is extensive COTS content.
"COTS and open-architecture systems are two different things for us," says Boeing's Leblond. "Open architecture addresses issues that put you into more standardized, modular systems than we have. But we also can take advantage, whether it is in the lower-level designs or display technologies, of things that have been developed for commercial applications. When we start migrating into open architecture, we will use as much of the electronics designed and developed for other programs as we possibly can.
"Hardware and software probably will go hand-in-hand in terms of migrating to open architectures," Leblond continues. "Today our entire operational flight program runs in a single computer. We would take that and identify the steps it would take to migrate that into a more open architecture, which might send portions of it across several processors."
For avionics systems, the move toward open architecture and the incorporation of advancing technology means smaller size, less weight, and increased processing speed. It also opens up room within tightly packed airframes to add new capabilities as they evolve.
"But does that mean an increase in performance, per se, over non-open systems," Leblond asks. "There are always capability enhancements going into the older legacy systems, as well. Bottom line, if you have an open architecture system for long term, it is easier to upgrade in terms of impact on the platform."
Finding answers for old systems is part of the mandate for organizations such as Boeing's Phantom Works and Lockheed Martin's Skunk Works (recently reorganized under the Aeronautics Company banner).
"We're looking at ways to mirror what is done in the commercial world across a variety of military systems without a revolutionary upheaval to the legacy systems," Winter says. "We need to tunnel commercial interconnectivity into legacy systems. We read a lot about the infosphere and battlefield networks and there's no doubt there will be a lot of thrust toward achieving a higher degree of interoperability, but that's already been done in the commercial world. The challenge is to do that in a way that doesn't require you to throw out everything already on the legacy platform.
"We're looking at many dimensions of commercial technology, not just fast computers, but interoperability, software and hardware technology, information management," Winter continues. "There are so many technologies that fit our vision, the challenge is adapting those things to the unique physical, environmental, and security environment of military requirements."
