Printer Friendly

Modular integrated avionics - strategies and challenges.

In the four and a half decades since the end of World War II, avionics has grown steadily in technological sophistication, impact on the combat capability of military aircraft and share of the life-cycle cost of those aircraft. Current front-line weapon systems like the F-14/15/16, the F/A-18 and the B-1B incorporate highly sophisticated sensors, electronic combat gear, communications, multifunction displays and other advanced avionics backed up by powerful embedded computers with operational flight programs (OFPs) running to as much as several hundred thousand lines of code. Many of these aircraft also employ an initial degree of avionics integration through the use of multiplex buses of the Mil-Std1553B class, with information rates on the order of 1 Mb/sec.

With the advent of the generation of aircraft now in development, especially the F-22 and the RAH-66, still another avionics revolution is in prospect. Avionics systems for these platforms are characterized by a very high degree of physical and functional integration and the use of a packaging scheme based on relatively small hardware modules. Modular, integrated avionics establish the basis for major advances in performance, reliability and maintainability. They also facilitate a straightforward and affordable path to upgrading as missions and threats evolve over the operational lifetime of the using aircraft. At the same time, these avionics demand new approaches to development and test, configuration management, standardization and maintenance.

This article explores some aspects of the acquisition and support strategies which are required if the full promise of this technology is to be realized.


Like every system generation, modern avionics systems are fundamentally driven by the state of the technology available to design and build them. A quick review of some of the more significant technological breakthroughs behind modular, integrated avionics will help set the stage for a discussion of the unique challenges these systems present.


At the heart of this avionics revolution is the concept that the avionics suite of an aircraft must be treated as a single subsystem, designed and optimized as a unified entity. This remains true even when multiple firms and hundreds of designers are required to work simultaneously on individual pieces of the suite. There is thus an unprecedented level of emphasis on an architecture which can support the complex interactions among the many avionics elements and functions required in a modern combat plane.

The architecture deserves to be thought of as a technology in its own right and is the product of decades of theoretical and experimental work. The first detailed articulation of this class of avionics architecture came in the specification produced by the Air Force Pave Pillar program. Army and Navy programs, especially the Navy's Advanced Avionics Technology Demonstration program, also made important contributions. This formed the basis for the avionics prototyping efforts in the initial phases of the F-22 and RAH-66 programs.

The Pave Pillar architecture was refined and extended by the tri-service Joint Integrated Avionics Working Group (JIAWG), which produced the Advanced Avionics Architecture (A3) standard. In combination with a family of detailed specifications and standards controlling specific aspects of the avionics design, the A3 addresses the following issues (see Figure 1):

* The top-level partitioning of the avionics suite into such functions as sensors, core processing, pilot interface and primary interconnects.

* Physical, electrical and interface requirements to ensure interoperability of modules and other system elements, including the packaging scheme based on modules installed in integrated racks.

* Protocols and interface definitions for the data paths and other interconnections, including backplanes, buses and sensor data networks.

* Overall system operation conventions to which all elements must conform, including support for built-in diagnostics.

Digital Processors

Perhaps the most obvious technological underpinning of modern avionics is the ability to embed data and signal processors with true supercomputerclass performance, along with very large memories, within the size and weight constraints of a tactical aircraft. Very Large Scale Integration (VLSI), given a powerful boost in military applications by the Very High Speed Integrated Circuits (VHSIC) program, makes such powerful miniaturization possible. For example, a single module conforming to the SEM-E packaging standard (roughly 5 x 6 x 0.6 in.) can easily contain a function like a 32-bit general-purpose CPU with 20 MIPS or more throughput.

Clusters of modules, tightly coupled via high-throughput backplane data paths, execute the various signal and data processing tasks of the integrated suite. One airplane can carry a core processing capability amounting to several hundred MIPS of data processing, specialized signal processing throughput of 10 GOPS or more and gigabytes of on-line and archival storage. The corresponding operational flight plan (OFP) will be both large (typically on the order of a million lines of Ada code) and complex.

This class of digital technology' offers advantages beyond computational capacity. It allows excellent built-in fault detection and isolation to be implemented without excessive penalties in hardware or system performance. The work of the JIAWG indicates that a relatively small number of module types, each used multiple times, can provide the required processing, storage and I/O. Accordingly, a manageable number of on-line spare modules (ideally one spare for each type of primary module in a rack or duster), coupled to highquality built-in diagnostics, can achieve a significant ability to both detect and recover from failures or damage. Surviving assets can be allocated to tasks and functions according to a priority scheme which may vary with mission phase, level of threat or other circumstances.

High-Speed Interconnects

The backplane of an integrated rack provides the interconnection for clusters of tightly coupled modules via both parallel data buses and high-throughput data flow networks. Data paths between physically separated elements such as core processing racks and sensors use some combination of point-to-point and multiplex channels implemented with fiber optics and running at up to 200 Mb/sec. The hierarchy of interconnects, from the intonor of a module to the backplane to the fiber-optic network, makes it possible to harness the available processing power and to achieve the necessary real-time operation of the avionics suite.


Sensing, communications, countermeasures and other functions require a variety of apertures which receive and transmit signals with frequencies ranging from RF through UV, depending on the requirements of a specific aircraft. Each aperture consists of an antenna or electrooptical (EO) head plus collocated receivers, detectors, transmitters, signal conditioning circuitry or other electronics and, usually, a radome or window.

In a modular, integrated avionics suite, much of the electronics will be packaged in modules and installed in racks some distance from the apertures which they support. For example, a broadband antenna might have an integral low-noise amplifier with the output signal cabled to an integrated rack containing additional receivers, filters, processors and so forth. Once signals have been analog-to-digital converted, the fiber-optic network provides fault-tolerant connectivity to digital signal and dataprocessing module clusters in the core processing area.

Many new technologies come into play in advanced RF and EO apertures, including active phased array antennas and sophisticated preprocessors for noise and clutter rejection. Programs like Integrated Communications/Navigation/Identification Avionics (ICNIA) and the Integrated Electronic Warfare System (INEWS), as well as avionics prototyping in the F-22 and RAH-66, establish the basis for extending the principles of modular, software-controlled, faulttolerant design beyond the purely digital processing regime. These efforts include demonstrations of the practicality of builtin diagnostics and reconfiguration for RF and other nondigital modular hardware.

Active phased array antennas possess inherently graceful degradation and eliminate a chronic avionics single-point failure -- the transmitter power stage. It is worth noting, however, that RF modules mounted in integrated racks present a significant technical challenge, since both highquality transmission lines and blind-mate RF connectors are required on the backplane.


The tools and practices of modern software engineering are essential to the design, integration, test and support of these avionics systems. Ada is now well established as the language of choice for mission-critical computer software, including even the most demanding real-time applications. The advantages of structured Ada programming over earlier languages such as JOVIAL range from greatly reduced error incidence in the as-written code to support for the system integration process and for longterm software maintenance.

Software engineering environments have matured to a level which allows high quality and productivity. This part of the technology spectrum will see especially dramatic change in the years ahead as entirely new approaches using object-oriented programming, knowledge-based design and other paradigms come into widespread use. Rapid prototyping, formal softwarequality metrics and the use of artificial intelligence in requirements engineering are just a few of the promising avenues to help system engineers and designers cope with the growing software challenge.


An avionics suite based on the technologies just described, to say nothing of the still more advanced ones which continue to emerge from laboratories around the world, demands some substantial changes from traditional practices. Some of the challenges confronting avionics engineers, testers and program managers are described in this section.


The effectiveness of a combat aircraft is determined by the combined attributes of its four major subsystems: airframe, propulsion, avionics and weapons. The two related challenges here are, first, to ensure that the operational requirements placed on the weapon system have been accurately and unambiguously captured and, second, to optimize the balance among the four constituents in a recipe which achieves maximum satisfaction of the requirements within constraints on cost, weight, schedule and so forth. It has become a cliche that system-development programs come to grief when requirements are unclear or floating, but there is much less understanding of the scope of the effort needed to establish the necessary detailed requirements and to communicate them to all parts of the design team.

Technology Maturation

The time from start of concept studies to first operational delivery of a new aircraft is at least 12 to 15 years, spanning two or more generations of avionics technology. This creates an enormous challenge in defining a system baseline which exploits the most advanced technology possible without incurring unacceptable risks.

One obvious aspect of this is the need for close cooperation between the system-development and technology-development communities. Another is the importance of acquisition program structures which ensure thorough evaluation of candidate technologies. Yet another is the value of a system design which provides for the orderly, incremental infusion of new technologies over the course of a development program and over the operational life of the resulting product through preplanned product improvement (P3I) or other modification programs.

System Engineering

Two aspects of the system-engineering process deserve emphasis here:

* Design Optimization: as noted earlier, the key word in effective system design is balance -- balance among system elements, balance between performance and supportability, balance between effectiveness and technical risk and so on. To pick one example, a low-observable airframe, high sustained cruise speed and defensive avionics compete with each other to some extent in determining aircraft survivability. A blended design which allocates the right amount of weight and cost to each of these is "optimum" under the metric of greatest survivability within available resources. Such trades are closely linked to requirements refinement. A similar challenge arises to make the necessary investment in the early stages of a program to avoid problems later.

It is particularly important that the entire weapon system, not just the air vehicle or other isolated subsystems, be analyzed and optimized from the start of the program. The fundamental trade-offs must be fully evaluated at each stage of requirements and design evolution to avoid decisions that preclude a truly optimized total system. The history of aircraft development offers plenty of examples of belated attention to avionics after the major aerodynamic and propulsion decisions were locked in, and great care has been taken in the ATF/F-22 program to avoid this mistake.

* Integrated Hardware/Software Design: In partitioning the integrated avionics suite into manageable pieces for design and implementation, one cardinal principle must be that the hardware and software elements of any particular function remain firmly tied together under a single design responsibility. This starts with the early phases of integration and test. It is essential that an avionics function be implemented by a unified team so that incompatiibilities surface as soon as possible and to limit misunderstandings between hardware and software designers. System specifications and test plans should start with functional performance and only "shred out" hardware and software at the level of the design hierarchy where configuration items must be documented.

It is widely understood that, in principle, the same rigorous engineering discipline dealing with requirements, test, documentation and so forth is needed for both the hardware and software elements of the design. Once again, however, experience often shows that software engineering has been neglected as being too hard or too expensive.

Integration and Test

In the era of discrete avionics subsystems, "integration" was largely a matter of solving problems with installation, power, cooling, antenna placements and cockpit layout. The combination of truly integrated avionics and greatly increased software complexity presents new challenges. Hardware and software from many separate companies and design teams must function smoothly in the ensemble. Tight configuration management, especially of the software, is essential if the process is to be kept under control. System timing, data communications latencies, built-in diagnostics and reconfigurations and a host of other system-wide issues must be addressed.

The ability to immerse the aircraft in a representative electromagnetic environment -- involving many spectral bands and millions of pulses per second to stress the avionics suite and verify performance -- is a major challenge. Another is the need to exercise the full range of system modes, particularly where hardware or software elements support multiple avionics functions. Integration and test of such a system can only be successful if careful attention to the integration strategy and enforcement of appropriate design rules are part of the program from the outset.


Over the past 25 years, combat aircraft have progressed from a situation in which it was expected that a plane would need avionics maintenance after nearly every sortie to the excellent reliability and maintainability (R&M) record of the units in the Persian Gulf War. More progress is possible if the challenge of balancing performance in the air with supportability on the ground is met.

This begins with the willingness to treat R&M as a basic priority and to allocate the hardware and software resources needed for fault detection and isolation, fault recording, redundancy and other failure recovery and maintenance support functions. Technology now makes it possible for an advanced aircraft to be a maintainer's, as well as a pilot's, dream machine.


Some powerful tools and methods are available to deal with the challenges of modular, integrated avionics. Many are adapted from computer science, reflecting the increasingly digital, software-intensive nature of avionics. Others represent the application of engineering principles which have been around for decades, appropriately tailored to the integrated avionics situation.


There is probably no more powerful set of tools than prototypes, and a variety of forms have been successfully employed in various phases of integrated avionics development.

During requirements definition, rapid prototyping with computer simulation is both a good way to explore alternative system concepts and behaviors and a means of capturing requirements in an objective, unambiguous form -- a simulation cockpit or model. By presenting proposed avionics capabilities to flight crews through cockpit mock-ups at various levels of fidelity, the system engineering team can establish priorities among avionics functions, define required levels of information detail, gain confidence that all the pilot's expectations have been accommodated and get an early start on key system design problems.

Every aspect of the avionics suite can be prototyped, from relatively crude breadboards up to flight-worthy engineering models and from individual bits and pieces up to large-scale prototypes of an entire avionics suite. For example, success in mating sensors, CNI and EW functions with core processing in a prototype represents important risk reduction for the design and integration efforts to follow, especially when a number of subcontractors and vendors are involved.

Most avionics prototypes will never fly; do not possess the full processing throughput, transmit power, bandwidth or other performance characteristics of the final design; and incorporate only a representative subset of system modes and functions. Their purpose is to allow rigorous assessment of the maturity and performance of the candidate technologies and to provide confidence that system requirements can be translated into designs which meet cost, weight, power and other constraints. The goal should be to include a set of prototype functions which stress the basic design of the integrated suite, explore important design and test methodologies and validate the required implementing technologies. In addition, the exercise of integrating and testing a prototype provides invaluable preparation for later phases of system design and test by establishing working relationships among members of the design team, exploring problems with instrumentation, providing a trial run on documentation and procedures and getting an early start on building up the real system-integration facilities.

All of these benefits were manifested in the avionics prototyping conducted during the ATF demonstration/validation phase, with payoffs carrying over to the current F-22 engineering/manufacturing development (EMD) phase.

System Simulation

As an adjunct to prototyping, high-fidelity computer simulation is an important method for refining system concepts and verifying designs before committing to expensive hardware and software.

Simulation is inherently hierarchical. At the most detailed end of the spectrum are digital hardware models at the level of individual logic gates, phenomenological models of antennas and other "engineering" models. These may be useful in themselves or embedded in a modeling context which represents more of the integrated avionics subsystem but at a higher level of abstraction, trading fidelity for comprehensiveness. At a still higher level, avionics capabilities can be included in models of the entire weapon system in support of the kinds of system-engineering trade-offs described earlier.

As the level of analysis moves up the hierarchy, detailed structural models give way to behavioral modeling techniques which can represent larger portions of the system and its environment while remaining practical to execute on available computers. Especially when validated by actual hardware/software prototypes, such analyses offer a relatively fast and cost-effective way to explore design alternatives and get an early start on identifying system-integration issues. Parts of the simulation package, e.g., models of sensors and their operating environments, can have long-term utility as part of the "instrumentation" of a system-integration facility.

Two particular simulation activities deserve a further word. For RF, IF and other analog (nondigital) hardware, excellent and affordable computer-aided design (CAD) tools have become available, most of which run on an engineering workstation. These not only save time and money in design, but also provide the kind of design data and documentation needed for system integration and test and for longterm logistic support. The other simulation arena to be emphasized is the use of state-of-the-art logic-modeling tools running on special-purpose computers called "accelerators" and going down to the level of individual logic gates (gate level system simulation, GLSS).

There is a direct analogy between the now-familiar concept of a software engineering environment (SEE) and a hardware engineering support environment (HESE) as sketched in Figure 2. The language of the SEE is Ada and that of the HESE is VHSIC Hardware Description Language (VHDL), which was explicitly designed using constructs and syntax very similar to Ada. Thus, both environments have a similar "look and feel" and provide an integrated design environment with tools for design capture, simulation, rule checking, documentation and other functions, plus a data base which links the efforts of multiple designers. These are precisely the kinds of tools needed for integrated hardware/software design.

The HESE allows difficult timing, interface, data-handling and other problems to be worked out before the actual hardware is built, greatly increasing the chances of a first-time correct design. A gate-level model of a processor also allows software integration and debugging to begin before the real hardware is available; this saves schedule delays and allows more design alterations and more thorough software testing. Any large information-handling system, but especially one with the complexity and real-time operation of an avionics suite, demands the use of a state-of-the-art CAD environment.

Figure 2 also illustrates a couple of other essential ingredients of a full computer-aided engineering (CAE) environment able to support both system engineering and design. The process must begin with the use of requirements-engineering tools, including behavioral-level simulation. Requirements engineering, which is fertile ground for application of artificial intelligence, includes the capture and unambiguous expression of requirements, analysis of these for correctness and consistency and decomposition of top-level requirements into successively more detailed entities which can be allocated to software and hardware system elements.

A program management overlay interacts with all elements of the environment to support progress tracking, resource control, planning, problem identification and other management functions. Both the SEE and the HESE should have embedded in them a set of process and quality metrics which provide essential visibility into the status of the design and are the primary inputs to project management.

System Interaction Facilities

The idea of a system integration laboratory (SIL) is not new, and SILs have been important in the success of a number of weapon system programs. The point to be made here is that a program which does a good job of avionics prototyping is a large part of the way to a full-blown SIL for EMD, which can then make the transition to the role of support facility for problem solving and modifications over the system's operating life.

Such a SIL should bring with it the appropriate SEE and HESE and should continue to use executable simulation models as the ultimate design documentation. Among other benefits, this helps with the task of generating and using data under the Computer Assisted Acquisition Logistics System (CALS) standards.

Another important extension of the traditional SIL is the avionics flying testbed. Again, the idea has been used successfully in the past for individual avionics subsystems, especially radar, but the results produced by the avionics flying laboratories used during the ATF dem/val phase have shown this capability to be essential for modular, integrated avionics. The flying lab allows sensors, CNI, EW and other functions to be tested in real environments of clutter, multipath, aircraft dynamics and other effects. It provides extensive instrumentation and direct access to equipment in flight, including the ability to load alternative software packages. Testing is far more productive than would be possible with only telemetry or onboard data recording, especially when software is being tested and the more complex functions such as sensor cuing and track correlation are being exercised.

As the ATF experience demonstrated, flying those elements of the avionics prototype which cannot be fully tested in a ground laboratory adds tremendously to the risk reduction and requirements refinement payoffs of the prototyping phase. The flying testbed does not eliminate the need for avionics testing in the actual aircraft, but it greatly reduces the number of problems to be found and fixed during weapon system flight test and saves time and money in the overall integration and test effort. Like the SIL, the flying testbed should be a long-term asset supporting the weapon system across its operational career.

Software Acquisition

Software has been emphasized in this discussion, particularly the need for integrated hardware/software development, but two further important points must be stressed: the need for a software strategy tailored to the specific circumstances of a given system, and the need for a mature software-development process in all parts of the system design team. A study of even the most notorious software disasters on earlier programs shows that most problems could have been avoided with the use of available tools and techniques and that program management and company infrastructure have been at fault far more often than software technology.

The first of these points deals with the need to match the software development approach to the characteristics of the system. DOD-Std-2167A provides a good starting point for a software-engineering strategy, but stresses the classic "waterfall" paradigm for software development. This is optimum only when the design problem is precedented, both in the sense that clear, complete and detailed requirements can be stated and that the development team has experience with similar jobs. In other circumstances, a different paradigm, especially the incremental "build a little, test a little" approach, while less tidy, may be more effective. A number of companies are beginning to apply artificial intelligence techniques to parts of the software-development process with good results. What is important is that the development task be analyzed and that a coherent strategy be defined and followed that applies the right approaches, tools and resources to each part of the software.

The second consideration involves another basic truth that is widely understood but historically just as widely ignored: highquality software which comes out on time and within budget demands a mature, effective process on the part of the developing organizations. Some important considerations are:

* A standard SEE should be defined and used by the prime contractor and all subcontractors working on software. Even better would be an integrated SEE/ HESE with a good requirements engineering front-end and a program management overlay as described above. Software technology considerations were discussed earlier, but the critical thing is for everyone on the team to be using the same tools, accessing the same corporate data base and following the same standards and procedures.

* The elements of software capability are people, facilities and process. A formal software development capability/capacity review (SDC/CR) is a good way to uncover shortfalls and problems; one should be done early in the program, well before major software development activity begins. The Software Engineering Institute has developed an assessment methodology for software process maturity and a five-level scale for scoring the maturity of a software development organization; the methodology is currently the most popular instrument for addressing this area.

* Team building and team stability are among the most important influences on success. Individual expertise is not enough; on a project of any size, a design team that has worked together and has the requisite blend of skills and experience is essential. If that team does not exist, the program structure must provide schedule and other resources to establish it.

* Two kinds of software metrics should be applied. The most widely used areprocess metrics which track things like actual versus scheduled progress, assigned personnel and the numbers and trends for trouble reports. A more complicated but highly valuable class of metrics addresses software quality by assessing such things as code structure and complexity, maintainability and compliance with design rules. A tailored set of metrics based on the nature of the project is the best insurance against undiscovered problems propagating into the later stages of a program where they are vastly more difficult and expensive to correct.

* A major ingredient in a mature software process is an estimating methodology backed up by a data base from previous estimates, often using a tailored version of a standard software cost model. Large software projects have earned a reputation for massively underestimating cost, manpower and schedule. Although software estimation is still something of a black art, there are things a program planner can do. One is to recognize that size alone is a poor predictor of software cost; complexity, existence of precedents, design team experience, process maturity and other factors may well be more important. Prototyping is perhaps the best source of data on both the size and complexity of the projected software and the resources required to develop it. In any case, a healthy dose of realism and a conscious attempt to avoid understating the problem are obviously necessary.


The avionics suite of a nextgeneration combat aircraft represents a complex, multi-disciplinary task in design, integration and test. Success demands the use of state-of-the-art tools, engineering discipline and program structures which provide the required activities and resources. Prototyping, early use of ground and airborne integration facilities and a mature software engineering process lie at the heart of an effective integrated avionics development strategy.

Col John M. Borky heads the USAF's Rome Laboratory, Griffiss AFB, NY. He has been on active duty with the USAF since 1969. He was responsible for managing the development of the ATF's integrated avionics suite as the program's director of avionics. He also was the principal Air Force action officer in the JIAWG. Col Borky has commanded the Rome Lab since 1990. He has a BEE from The Catholic University of America, SM and EE degrees from MIT and a PAD in electrical engineering from The University of Michigan.
COPYRIGHT 1992 Horizon House Publications, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1992 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Borky, John M.
Publication:Journal of Electronic Defense
Article Type:Cover Story
Date:May 1, 1992
Previous Article:The DOD EW laboratories - what's ahead?
Next Article:Technology base work in integrated avionics.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters