FUTURE INTEGRATED MODULAR AVIONICS FOR JET FIGHTER
MISSION COMPUTERS
Brian Sutterfield, John A. Hoschette, Paul Anton
Lockheed Martin MS2 Tactical Systems
Eagan, Minnesota
Abstract
Highly flexible and versatile computing
architectures are needed to meet the ever-changing
jet fighter aircraft mission needs with cost-effective
processors. Future avionics mission computers will
require a continued commitment to open
architectures and modular hardware operating at
more than two orders of magnitude greater
processing than todays most advanced mission
computing solutions. Dense multiplexing busses
(optical technology) will be required to interlink
multi-core modular processors. Multi-level security
will be required to provide safeguards to ensure the
integrity of the network. Systems must be
architected in a manner that will support open
standards while still allowing for ultra high density
packaging. Backplanes will contain integrated
electrical and optical signals, and progress in
modular software development and legacy software
reuse will be necessary to maximize the efficiency of
integrating new hardware. All technologies required
to build the next generation mission computer exist
today, and by applying proper focus these
technologies can be combined to provide a quantum
increase in processing capability with higher
reliability and affordable cost.
Introduction
High speed mission computing onboard a
modern fighter aircraft is accomplished by the
mission computer. The mission computer is
networked with other avionics subsystems to aid the
pilot in mission planning, mission execution and
workload management. As the brains of this linked
and integrated avionics system, the mission
computer must support a multi-mission aircraft with
constantly changing needs to provide the pilot with
the best situational awareness possible. Shown in
Figure 1 is the advanced multi-mission F-35 fighter.
To meet the extreme and ever-changing processing
demands of modern fighter aircraft, the mission
978-1-4244-2208-1/08/$25.00 2008 IEEE.
1.A.4-1
computer requires high speed through-put,
modularity, rapid reconfiguration, and an open
architecture.
Figure 1. Advanced F-35 Multi-Mission Jet
Fighter
In this paper we present how the future
integrated modular avionics will meet these needs.
The next generation open architecture mission
computer will be based on multi-core modular
processors and will require high bandwidth
electromagnetic interference (EMI) protected data
busses. These data busses will need to support
integrated data integrity, multi-level security and
have expansion options that will support multiple
and future protocols. We see needs in the next five
to seven years of mission computers requiring
hundreds of teraflops of computer performance
versus the hundreds of gigaflops required today.
The architecture must be re-configurable to handle
high peak processing demands and provide
maximum flexibility. Hardware will comply with
open standard form factors and support standard
chassis interfaces making them interchangeable for
higher reliability and maintainability. Centralized
computing resources and interfaces to avionics
subsystems, radar, electronic warfare systems,
optical sensors, Global Positioning System (GPS),
Data Storage, Inertial Navigation System (INS), and
others will support future growth, degraded modes
and reconfiguration. Key technology components to
achieve this superior future mission computer have
already been built and independently demonstrated
in both lab and flight environments. With the proper
focus of these technologies, the next generation of
avionic mission computers is easily obtainable
within the next few years. The future of jet aircraft
mission computers centers on modular, optically
networked processors using multi-core technology
based on a standard format card and chassis [1].
Evolution of Mission Computing
Figure 2 depicts the evolution of mission
computing over its 50-year lifespan. Sensor
capability and complexity drive mission demands
which in turn drive the mission computer
performance requirements. As requirements
increase, specific advances in technology had to be
invented and applied to the mission computer to
ensure the pilot and the system were capable of
meeting the needs of the mission. As early as 1970,
engineers realized that a complex mission computer
rivaling those used by scientists would be required
to provide pilot assistance in managing his or her
workload. These early mission computers were
simple computers with processing capabilities
similar to a hand-held calculator of today. By 1980,
mission computers with localized networks were
being designed with the intention of networking
into other aircraft subsystems and to provide
additional real-time decision support to the pilot.
Industrialized microprocessors, printed wiring
boards and single board computers began to be
applied to the problem. By 1995, computer
processing hardware capability was increasing by
such magnitude that a common open systems
approach began to be applied to the development of
the mission computer. Avionics Open System
Architectures (AOSA), Optically Networked
Electronics (ONE), and Vita standards for avionics
were all results of this standardization.
As we look forward past 2010, the demand on
mission processors will continue to grow as pilot
workload and aircraft missions increase in
capability and complexity. We are already seeing
mission needs that will require one to two orders of
magnitude increase in computing requirements
within the next 10 years. Specific examples of this
are the desire to connect the pilot and aircraft to the
Global Information Grid (GIG) and link multiple
aircraft to provide local, theater and global
situational awareness during each mission. As the
commercial market struggles to maintain the pace
of electronics development, our challenge is to
ruggedize and insert the latest technologies to
support our pilots in accomplishing their mission.
Today

70s 80s 90s 00s 10s 20s

Pilot
Multi-sensors & Expanding Missions, Global Net- GIG
Increasing workload
Subsystems to More Complexity Multi-Aircraft
increases,
Mission Needs needs help
control More Subsystems Theater Awareness

Multiple Switched
Mission Birth of
Processor Network
Computing
Mission
Mission Mission ?
Computer
Computer Computer

Microprocessors Explosion of uP & memory Optical Buses

Single Board Computers High Bandwidth
Avionics Open System Multicore
Architectures (AOSA)
Technology FPGAs
Switched Networks Specialized Processors
Improvements Parallel Processing
Optically Network Electronics
(ONE)
Vita Standards

Expanding
Expanding Role
Role for
for the
the Mission
Mission Computer
Computer Requires
Requires Increasing
Increasing Processing
Processing

Figure 2. Evolution of Mission Computing

1.A.4-2
Future Mission Requirements (MIPS). The latest generation of the F-16 requires
nearly 20 gigaflops of performance, the F-22
Future mission computer processing
requires nearly 10 gigaflops of performance and the
requirements are growing at an exponential rate.
latest 5th generation fighter, the F-35, peaks at just
Figure 3 depicts a rough order of magnitude
under 200 gigaflops of required performance from
estimate of mission computer requirements [2].
the mission processor.
Early F-16 mission computer requirements were
approximately 6 Million Instructions Per Second

Processing Performance vs. Time

Maximum Reconfigurable Architectures
1,000,000 MIPS/MFLOPS
F-35 Upg

100,000 MIPS/MFLOPS

FLOPS Required During

F-35 IOC

10,000 MIPS/MFLOPS
F-22

F-16 60
Multiple Processors

Mission
1,000 MIPS/MFLOPS P4 x86
Cray-2

F-16 50
100 MIPS/MFLOPS F-16 30
F-16 Upg

10 MIPS/MFLOPS Pentium
Single Processor
TI-83 PSE
F-16A/B
TI-83 Calc
1 MIPS/MFLOPS
80486
Mission Time
.1 MIPS/MFLOPS
80386

MIPS
1970

1990

2010
1980

2000

MFLOPS

Figure 3. Future Mission Computer (MC) Requirements

We expect to see requirements exceeding one requirements, ultra high speed data buses in excess
teraflop by 2015. The processing demand varies of 10 Gbps will be necessary. In addition, the
greatly during a typical mission, and this places a network must be protected against attack and will
significant demand on the processors. No single require multi-level security, separation of classified
processor can handle the load. Multiple processors data and robust EMI capabilities. In order to make
are required, and reconfigurable architectures the mission computer more affordable, easier to
provide the potential to meet the peak processing produce, and more reliable, modular standardized
demands during the mission while still meeting the hardware and software are required. The basic
available volume and power requirements. statement of the problem is: highly flexible and
versatile computing architectures are needed to
Future mission computers will require
meet the ever-changing mission needs with cost-
reconfigurable and scalable architectures. This
effective processors.
development is driven by multi-mission aircraft
where many subsystems are required to maintain
continuous communication to successfully complete
the mission. A typical modern mission computer
architecture is shown in Figure 4. Currently, high
speed point-to-point networks are employed to
support low latency decision-making within the
mission system. As the complexity and
requirements of the system increase, we expect to
see communication needs in excess of the 1-2 GHz
required today. Ideally, the system of the future will Figure 4. Typical Mission Computer Network
support a bus topology to facilitate reconfiguration
and sharing of resources as well as straightforward
access to available data. To support mission

1.A.4-3
Technologies Needed for Increasing
MC Processing Capabilities
Much of the technology required to meet these
surfacing needs exists today in commercial and
non-military applications. Focused efforts directed
at packaging and ruggedizing these technologies in
a systematic approach will yield a quantum leap in
processing capability. These technologies are:
Dense Wave Division Multiplexing
(DWDM) Optical Bus Technology
Field-Programmable Gate Array (FPGA)
Computing Technology
Multi-Core Processors
Standardized Chassis with Integrated
Optical and Electrical Back Plane
Technology
Standard Optical Module Form Factor
Multi-Level Security Hardware and
Software
Modular Software
Figure 5. Basic Principle of DWDM and Capability Compared to Existing Buses
FPGA Computing Technology
FPGAs became heavily used in military
avionics systems beginning in 1990. Although
initially thought by some to one day replace the
general purpose processor, FPGAs have been
typically utilized as a supplementary capability for
communications and algorithmic acceleration
within the bounds of the mission system. Although
primarily used as co-processors, FPGAs may hold
the key to maintaining Moores law in the avionics
world. With general purpose processors currently
ceilinged at 2.5 3 GHz, new functionality requires
1.A.4-4
Reconfigurable and Scalable Computing
Architectures
DWDM Optical Bus Technology
Shown in Figure 5 is the basic principle of
DWDM. Using laser diode technology, 32 channels
can be sent over a single optical fiber. The receivers
are configured to receive many specific
wavelengths of light that each represents a separate
channel. Each transmitter is tunable to a specific
transmit frequency that operates independently on
the fiber bus. Therefore, a system can have
multiple technologies on a single fiber including
analog, digital, 2 to 40 Gbps, Fibre Channel or
Ethernet, each operating independently of each
other. Fiber optics offer high speed data
transmission using lighter weight, smaller cable size
and weight, and eliminate the need for specially
tuned bulky cables used in copper wire systems. In
addition, fiber optics is naturally resistant to EMI
and provides many features that directly support
multiple levels of security and data separation.
extensive use of parallel processing and multiple
processing cores. FPGAs on the other hand are still
running under 1 GHz, providing ample room for
clock speed performance improvement as well as
more logic units and additional capability added
due to reduction in feature size.
Multi-Core Processors
Typical avionics mission systems have used
multiple independent processors for several years.
Additionally, as multi-processor computers
evolved, the signal processing domains within the
avionics systems were quick to leverage these new
capabilities. Signal processing applications
typically involve the processing of large amounts of
data and, in turn, along with bounds on network
speeds, further limit the amount of signal
processing algorithms that can be parallelized.
Multi-core processors and networks speeds thus
become part of the engineering tradeoff specified
by Amdahls law.
Current general purpose processors have
somewhat stabilized around the 3 GHz mark.
Avionics systems have already effectively focused
on leveraging the multi-core market. Avionics
systems are generally a good fit for multi-core
processors because they have a generous contingent
of requirements that can be satisfied with parallel
processing or smaller serialized programs running
on several processors. A new challenge arises when
typical safety and security partitions must be
applied to the multi-core processing paradigm. It is
not clear that there currently exists a single cohesive
strategy to manage Multiple Levels of Security
(MLS), Certification Evidence Assurance Levels
(CEAL) or safety certifications (DO-178B, DO-
254, SEAL) using multi-core processors. In
addition, not all multi-core processors are created
equal. Some rely heavily on shared resources,
(shared cache for instance), while others can be
cleaved under hardware control to act as completely
independent entities. Regardless of the issues, there
is no doubt that multi-core processors will be a
significant part of most, if not all, solutions for the
foreseeable future [3]. Development of tools and
methods that allow avionics suppliers to easily
integrate multi-core processors into their systems
will be extremely important as we forge ahead on
this new path. Shown in Figure 6 is the multi-core
roadmap with the estimated number of cores per
module [2].

Figure 6. Multi-Core Processor Roadmap

1.A.4-5
Standardized Chassis with Integrated
Optical and Electrical Back Plane
Technology
Standard chassis with standard rack sizes will
continue to be required. Use of a standard chassis
will allow for ease of aircraft installation and use of
standard interfaces. High density packaging of
processing modules will be required to maximize
processing power in limited space, and this will
require liquid cooling. Standardization will allow
for swapping of cards and easy upgrading when
Chassis to Allow Reconfigurable Architectures
Figure 7. High Density Packing and Standard Size Chassis Concept
The key to high density packaging is module
standardization, and integrated electrical and optical
backplanes are critically important to bring down
the size of the chassis. Mission computer power
supplies should have the same shape factor as
processing modules. Integrated optical and
electrical backplanes need to be routed in one high
density assembly to keep the chassis size down.
Shown in Figure 8 is an integrated electrical and
optical back plane.
Figure 8. Integrated Electrical and Optical
Back Plane
1.A.4-6
they become available. Shown in Figure 7 is an
approach for high density packaging. The modules
are packaged side by side and come in standard
sizes and thicknesses. Processor heat is drawn out
of the modules along the edges through advanced
thermal packaging and into liquid-filled chassis
walls. The locking mechanism which holds the
modules in place also serves as a heat conduit. The
chassis walls contain liquid cooling lines to remove
heat. This way the construction of the module is
easier since no liquid actually passes through it.
High Density Packaging
Standard Optical Module Form
Factor
By going to a standard shape and construction
technique the modules will be lower cost and more
producible. The module construction is shown on
the left of Figure 9. At the center of the module is
the heat cooling core to remove heat from the
modules to the edge for cooling. Processing cards
are mounted on either side of the cooling core.
Standard covers are used, and the connector
interface at the bottom of the card is standard.
 Mezzanine Card
Standard
Processor Card 1
Cover

Processor Card 2
FPGA
FPGA

FPGA

FPGA FPGA FPGA

Standard
Cooling Core

Standard
Standard FPGA Standard Module for Processing
Cover
Interface
Standard Construction Techniques

Figure 9. Concept for Standard Optical Module Hardware

The module itself contains a standard set of Separation of levels

FPGAs that can be loaded with the latest processing
cores. The cores are selected based on the
processing needs. This makes the module
reconfigurable and easy to update as new and better
processing cores become available. With a module
entirely FPGA-based, the hardware need not change
every time there is a change to the processor. This
ability to reprogram FPGAs leads to significant
lifecycle cost savings.
Multi-Level Security Hardware and
Software
Future mission system computers need a
robust threat protection capability due to a large
number of potential threats from both known and
undetermined sources. In particular, threats can
come from any source that has the potential to
communicate with or link to a mission system
computer. These include threats from other aircraft,
satellites, ground stations or even maintenance
activities.
A robust security protection system for the
Mission Computer must, as a minimum, have the
following safeguards in place:
User Authentication
Handling of classified Data
Multi-level processing
Data Encryption /Decryption
High throughput, on-board encryption
engine (> 40 Mbits/sec)
Message Labeling (Source and
Destination)
Message Priority High, Medium, Low
Tamper Proof
Key among these capabilities is a secure
Network Interface Unit (NIU) that acts both as a
communications translator and gateway between
computing resources and the network. Each system
on the network must communicate with other
systems on the network only through their
respective secure NIUs. The NIUs must be able to
stop unauthorized and potentially dangerous
messages from being transmitted on the network,
and from being received from the network.
Modular Software
Existing mission computing requirements have
increased from less than one gigaflop in the 1970s
through 200 gigaflops today, and that increase in
demand is expected to continue (Figure 3). The
software supporting this increasing demand in
interconnectivity, multi-systems coordination,
reconfigurability, and adaptive, situational-
dependent responsiveness is likewise increasing
both in quantity and complexity. Recreating

1.A.4-7
customized, supporting software from scratch for
each new hardware system is very cost-prohibitive.
Many strategies for creating software must be used
to support software that is reusable, reconfigurable,
adaptable, testable, and maintainable.
Key to these strategies is to build upon existing
software solutions. Reusing existing code and
creating reusable code is a first step. There is a
challenge even in this simple requirement as high
performance embedded systems tend to prohibit
generalized software solutions, customers dont
typically want to support requirements that allow
for generalized gold plated solutions, and the
rigorous testing required of avionics systems
prohibit unused code. However, re-using code is
only a small part of the solution. There is far more
cost-effectiveness in leveraging existing software
tools: compilers, debuggers, profilers, and a myriad
of testing tools. Much of this construction on an
existing software support foundation is
accomplished through use of open software
standards that use commercial solutions. Finally,
there is an enormous need to manage the software
and tools. Systems for keeping track of capabilities,
versions, compatibilities, testing coverage, as well
as technical and user documentation. Industry
standards such as CMMI and SEI, as well as
configuration and data management methods
continue to be refined to support this software
development and these software tools.
Even after tackling the issues associated with
developing and managing reusable code while
leveraging commercial software, there are still cost-
prohibitive limits associated with transporting the
growing one to ten million lines of code in mission
system computers. There is the further need to build
systems that support automatic code conversion.
This includes:
Building effective middleware layers.
These layers both insulate software from
hardware and also hardware from
software. In addition, this middleware
will also support reconfigurable software
architectures to manage changes in
processing needs when hardware fails
and when mission systems needs change.
These middleware layers need to include
low-level operating system support
(OSS) and library support for interfaces
1.A.4-8
between generic operating systems and
generic hardware features (e.g.,
watchdog timers, standard busses, DMA
and encryption interfaces, etc.)
Developing software using tools that use
hardware, firmware, software, and
operations models to automate the
hosting across multiple processors to
balance mission processing loads.
Including debugging tools with standard
interfaces such as fault logging, start-up
and run-time testing, cross-processor,
run-time, cluster debugging
mechanisms for detecting, identifying
and locating failures (that may be
induced by hardware failures, software
design faults, interface incompatibilities,
or unanticipated events).
Capturing and logging run-time
performance data both for adaptive and
off-line performance improvements as
well as both hardware and software
failure predictions.
Providing boot-up systems that allow for
complete, secure, field-reloadable software.
Developing and maintaining a comprehensive
set of regression tests to evaluate the accuracy of
automated code conversion mechanisms against
legacy mission systems performance.
Reconfigurable and Scalable
Architectures
The processing load of the mission computer
nodes (i.e., Radar, Electronic Warfare (EW) or
Sensors) greatly varies during the mission. As
shown on the left side of Figure 10 in a simple
example, if the processing load is sized based on
static allocation, the size and power of the mission
computer quickly becomes prohibitively large. The
total aggregate processing throughput required in
this example using static resource allocation would
be 240 gigaflops.
In contrast, a reconfigurable mission computer
architecture would alter resource usage during the
mission and accomplish the processing with far less
capacity. This is shown on the right side of
Figure 10 where a reconfigurable architecture
would need only 138 gigaflops.
 Figure 10. Comparison of Static vs. Dynamic Resource Allocation and Impact on Processor Size

A reconfigurable mission computer allows for
the re-assignment of the node processing elements
as the mission demands. This is shown pictorially in
Figure 11, where the processing nodes of the
mission computer are re-assigned to the various
domains (i.e., Radar, EW and Data ) at different
stages of the mission. In the fly-out portion of the
mission the processing load is fairly balanced.
During mission ingress, the demand for radar
processing significantly increases while the demand
for EW and Data decrease. As the mission
transitions to the egress stage the radar processing
load diminishes and unused radar processing nodes
are reassigned back to Data. Finally during mission
return stage the EW load is significantly increased,
while the Radar load is further reduced. This allows
further reassignment of processing resources to
EW.

100
Radar EW Data Radar EW Data 90
Data
Misiion Computer Utilization

80
EW
70
uP uP uP uP uP uP uP uP 60
50
40
Radar
uP uP uP uP uP uP uP uP 30
20
10
0

Fly out Mission ingress Mission Timeline

Radar EW Data

Radar EW Data Radar EW Data

uP uP uP uP uP uP uP uP

uP uP uP uP uP uP uP uP

Mission Return Mission egress

Figure 11. Dynamic Reconfigurable Architecture as a Function of the Mission

1.A.4-9
Conclusion The Future Mission
Computer
Multi-mission aircraft are placing greatly
increasing demands on mission computers. The
mission computers network and architecture
continue to grow as new subsystems are added and
new processing is required. The mission computer
must have a highly flexible and versatile computing
architecture to meet the ever-changing mission
needs with cost-effective processing resources.
By using a methodical and systematic
approach and applying existing technology, the
future mission computers will be able to make a
quantum leap in processing power (>10 teraflops)
and therefore support the growth in processing
demands. The future mission computer is shown
pictorially in Figure 12. Using optical coupled
uP uP uP
Optical
Coupler uP uP uP
Figure 12. Concept for the Future Avionics Mission Computer
Acknowledgements
The authors would like to acknowledge the
contributions of Jeff Levis, Dr Keith Burgess, Mert
Horne and Rich Berg to this paper.
References
[1] Levis, J, B. Sutterfield, R. Stevens, 2006, Fiber
Optic Communication within the F-35 Mission
System, Avionics Fiber-Optics and Photonics,
2006 IEEE Conference, pp. 12-13.
[2] Data collected via Google search of open
literature.
DWDM data buses, the future mission computers
will provide an open architecture with no electrical
cross bar switches supporting data bus rates in
excess of 10 gigabits/second. Communication
between network nodes will support multi-level
security with separated levels of classified
processing. Data encryption and decryption will be
standard features allowing for safe and guarded
operation.
The computer modules will be a standard
shape and size based on FPGA and multi-core
processor technology supporting high density
packaging. Multi-core, FPGA and hybrid
processors will be supported using standard optical
bus architecture. The architecture will allow
dynamic resource allocation based on the mission
needs allowing the mission computer to accomplish
more processing with less hardware.
Typical Processor Board
FPGA
FPGA
Cooling Core
FPGA Two Sided
uP
FPGA FPGA FPGA
uP
Standard Chassis
[3] Faber, Rob, 2008, High Performance
computers Future, What will the Next 20 Years
Bring? Scientific Computing, July/August 2008,
pp. 24-25.
Biographies
Brian Sutterfield is the Chief Engineer for the
Tactical Avionics Group of Lockheed Martin in
Eagan, Minnesota. Brian was one of the chief
Architects for the F-35 Integrated Core Processor
Mission Computer. Brian is presently leading the
development the next generation mission computer
architectures for multiple programs.
1.A.4-10
 John Hoschette is a staff systems engineer in Email Addresses
the Tactical Avionics Group of Lockheed Martin in
Brian Sutterfield: brian.sutterfield@lmco.com
Eagan, Minnesota. John was one of the original
developers of the optical network used in both the John Hoschette: john.hoschette@lmco.com
F-16 and F-35 aircraft.
Paul Anton: paul.j.anton@lmco.com
Paul Anton was the Program Manager for the
F-35 mission computer in the Tactical Avionic
Group of Lockheed Martin in Eagan, Minnesota. 27th Digital Avionics Systems Conference
Under his direction the first F-35 mission October 26-30, 1008
computers were successfully built and delivered.
Paul is presently the the Tactical Avionics Business
Development Director.

1.A.4-11