DESIGN CONSIDERATIONS FOR SYSTEMS HOSTED ON INTEGRATED
MODULAR AVIONICS PLATFORMS
Christopher B. Watkins, Randy Walter, GE Aviation, Grand Rapids, Michigan
Abstract
System architects are accustomed to
developing systems hosted in federated
environments that allow for developmental
independence. However the system boundaries are
different when systems are hosted in an Integrated
Modular Avionics (IMA) platform. The boundaries
lie within shared resources, and thus lead to greater
dependencies between systems. This drives new
design considerations for system architects. The
natural tendency is to leverage traditional federated
design concepts when building systems for IMA
environments, but this can lead to inefficient use of
system resources, and a lack of preparedness for the
inevitable change that will occur within the
integrated set of systems. IMA has become a
standard in the civil and military aviation industries,
so it is important to understand these new design
considerations.
The question addressed by this paper is “What
unique design considerations are there for systems
hosted on an IMA platform?” All of the
considerations can be attributed to three main
drivers present in the IMA environment: (1)
optimization of system resources across the
integrated set of hosted systems, (2) change
containment when hosted systems change and (3)
change containment when the IMA platform
elements change (technology insertion).
These three factors impact the traditional
developmental independence between systems since
it requires the architect to consider their system’s
role within the integrated set of systems. They must
now consider how they will tolerate changes that
are out of their control, such as changes to other
hosted systems or the IMA platform that affect the
shared resource performance. They must now
consider how they contribute to the efficient use of
system resources as part of the greater system-wide
optimization strategy. If these factors are not
addressed, then it can lead to wasted system
resources, increased development costs, and high
costs-of-change. Therefore the incentive to ensure
978-1-4244-2208-1/08/$25.00 ©2008 IEEE.
1.A.2-1
that these new design considerations are addressed
lies with both the system integrator who owns the
integrated set of systems and the architect of each
hosted system.
This paper is based upon the authors’
experience in developing IMA systems at GE
Aviation. GE Aviation has developed open system
IMA architectures for commercial aircraft (Boeing
787 Dreamliner), as well as military aircraft
(Boeing C-130 combat aircraft, and Boeing KC-767
Tanker).
Traditional Design Philosophies Are
Good but Not Good Enough
The natural tendency for a systems engineer is
to approach a new architecture using the design
methodologies that have worked well in the past.
There is an inherent desire to avoid repeating past
mistakes, and to take advantage of lessons learned.
These “traditional design philosophies” add value to
the next project by providing for quicker, cost-
effective development efforts that maintain high
quality standards. However it is important for the
engineer to understand when a new architecture
diverts outside the mold of past projects and
requires the standard design philosophies to be
adjusted.
The transition from federated avionics
architectures to IMA architectures as described in
previous work [1] bring new design elements to the
table and thus require an adjustment to the
traditional design philosophies. The foundation of
the engineer’s experience is still applicable, but
there are some new architectural characteristics that
must be managed properly in order to avoid
unwanted effects. IMA systems represent higher
levels of system integration than what is typical in
the past due to the use of shared system resources as
described in previous work [2]. If the integration is
not adequately addressed during a hosted system
design, then it can lead to unnecessary system
growth and an increased cost of change for future
updates. If these unintended consequences become
a reality, then it is too late to mitigate. The design
must sufficiently account for the high level of
system integration. The level of independence
between hosted system developments is different
than what can be assumed between federated
systems.
Developmental Independence
A hosted system in an IMA environment
continues to maintain a level of independence from
the other hosted system developments due to the
robust partitioning characteristics inherent to the
IMA platform. However the IMA environment
adds new dependencies between systems since they
need to design for integration:
• Compliance to optimization directives
for the integrated set of hosted systems
• New types of system interfaces require
new abstraction layers to be defined in
the system architecture in order to
contain change
The hosted system developer must actively
participate in the overall effort to optimize the
integrated set of hosted systems. The systems
integrator will provide directives for each hosted
system as part of the overall resource optimization
process.
The hosted system must include design
elements that provide clear architectural boundaries
to contain change. GENESIS is a reference IMA
architecture that helps illustrate these fundamental
elements and system interfaces [3]. Change is
usually contained at well-defined interfaces that
provide an abstraction layer to the rest of the
system. Certification artifacts supplement the
design to prove that changes to the IMA platform or
other hosted systems do not cross that abstraction
layer and impact the unaffected hosted system.
The new design philosophies that should be
considered in an IMA environment are a direct
result of moving the system boundaries into a
shared computing resource. They are organized
into three main topics:
• Optimization of System Resources
• Change Containment when Hosted
Systems Change
1.A.2-2
• Change Containment when the IMA
Platform Changes
Optimization of System Resources
Efficiency and optimization go hand-in-hand.
Efficiency is what drives aircraft manufacturers to
the IMA architectures. They want to reduce the
size, weight and power for aircraft systems through
a more efficient use of shared resources.
As new aircraft electronic systems migrate
towards more integrated architectures utilizing a
shared system platform, optimization of the
integrated system requires all participants to adhere
to a disciplined design integration process. This
process is not only critical for an orderly
development process but also aims to establish best
practices for efficient use of system resources.
Analyze TRUE Data Rate and Latency Needs
One of the key development practices for a
successful platform integration is a true analysis of
individual system needs. This starts with the
definition of a system’s functional requirements and
its data needs to fulfill those requirements. Just as in
federated systems, an interface control document is
necessary to define the functional data flows
between the various system elements. The attributes
of those data flows are key in determining network
bandwidth resource usage. Often in the past, system
developers simply accepted data at the rate a
publisher transmitted that data without a great deal
of thought as to the “real” data rate needs for the
system. Likewise, many developers gave little
thought to the actual data latency characteristics
from a publisher. However in a shared
communication environment these data attributes
become primary drivers of resource utilization. A
critical element of passing a preliminary design
review gate should include the sound definition of
system data needs, including required rate and
latency attributes along with justification of those
needs.
Utilize and Trust Platform Characteristics
The IMA platform comes with a set of
integrity and availability characteristics that hosted
system developers must understand to efficiently
utilize the system resources. Individual hosted
system developers must use this context when
architecting their elements on the integrated
platform. Review of the hosted system architecture,
along with justification for meeting integrity,
availability and dispatch requirements become
critical elements for passing a preliminary design
review gate. The availability and independence
characteristics of the IMA components should be
leveraged, not ignored. Architectural decisions for
hosted system redundancy should be based upon the
IMA platform reliability attributes in order to meet
regulatory availability and desired dispatch
requirements.
Another aspect of IMA is the platform-
provided functionality (a.k.a. platform
infrastructure). The hosted system developer
should avoid building functionality that duplicates
functionality provided by the platform. For
example, consider the cold start and system
restoration strategy implemented in the IMA.
Federated systems may employ many different
strategies from power retention to non volatile data
storage through power transients. These individual
hosted system strategies must be aligned with the
particular IMA characteristics to avoid wasteful use
of system resources. If a computing element in an
IMA is backed up with battery power, individual
functions writing data to non volatile memory
resources is not only a waste of those resources but
a waste of the basic processing resources as well.
Maximize the Processing Capability of the
IMA Platform Architecture
As with any hardware/software platform
design, the processing architecture provides
“features” to enhance the performance capability of
the system. It’s incumbent upon the IMA supplier
to adequately document these features in IMA
descriptive material so hosted system developers
are aware of this capability. It is important for
developers to understand and consider these
features in architecting the software that will
execute on the processing resource. Application
software architectures should leverage processing
features to the extent possible to avoid wasting
resources. Review of hosted system software
architecture to ensure adherence to these practices
becomes a critical element for passing the critical
design review gate.
1.A.2-3
For example, features such as data and
instruction cache are best utilized by a modular
software architecture that utilizes common
subroutines and common data buffers. This allows
repeatedly-called modules and data to be drawn into
cache on first usage where subsequent access is
significantly faster.
Establish “Resource Budgets”
The approach to resource management is
fundamentally different between federated and IMA
architectures. The act of sharing computing
resources requires changes to the systems
integration thought process. It requires the set of
system developers to work together with the
systems integrator to achieve an integrated solution.
The approach to resource management should be
considered up-front, so that the project structure and
associated contracts can be setup to appropriately
manage the IMA program. The cost of a hosted
system is not only its development cost, but also the
measure of the amount of resources it uses. It is
critical that there is an incentive structure that
drives the hosted system providers to minimize the
total cost of their proposed system.
Inherent Motivations for System Optimization
are Different
In a federated architecture, the hardware
infrastructure component is owned by the supplier
who is implementing the system. Therefore trades
between hardware and software performance are
within the same company/organization. In this case,
there exists an inherent motivation to optimize the
system. In an IMA structure the overall system
optimization is usually split between companies and
can be spread across multiple departments or
organizations within a given company.
There is an inherent motivation for each
company/organization to optimize individual pieces
of the system instead of the overall system. There
is a motivation for hosted function developers to
pass inefficiencies to other systems thereby
reducing their optimization burden at someone
else’s expense. Therefore incentives must be
established that ensure individual optimization is
consistent with overall system optimization. This is
accomplished by recognizing that IMA platform
resources are a primary driver of the classic metrics
of weight, volume, power, and cost. So when
considering the value of any implemented system,
the IMA platform resource usage must be added
into the equation. The more efficiently the platform
resource is utilized, the better the system value. At
the same time, the more capable the IMA platform
is, the better the system value. In order to facilitate
system optimization, the concept of budgets is used.
The budgets are used to measure an individual
system’s contribution to the optimization of the
integrated set of systems. More capability in the
IMA platform translates to fewer components to
implement an integrated system; the IMA supplier
benefits from lower production cost. Conversely,
more efficient hosted systems benefit from a reward
system for reducing the overall system resource
demands, providing better value to the airplane.
Change Containment When Hosted
Systems Change
The second design philosophy unique to IMA
environments is related to hosted system change.
As with any integrated system, careful
consideration for system change must be part of the
initial architectural philosophy from concept to
implementation. Within the IMA environment, the
traditional design philosophies must be adjusted to
account for the new type of system interface
embodied by the shared platform resources.
The hosted system boundaries lie within the
shared system resource, and therefore the system
interface (system inputs and outputs) are governed
by the resource quantities and performance. The
IMA platform is configured to instantiate hosted
system resource quantity and performance. In this
case, the interfaces are not wholly described by
physical interfaces to a box. The interface is also
defined by logical system boundaries where data is
exchanged between systems within the shared
resource. These non-traditional interfaces can be
documented using a modified version of the
traditional “ICD” approach.
Create a Well-Defined ICD
Traditionally, the term “Interface Control
Document (ICD)” refers to the documentation of
the wiring and data rates for communication
between boxes (line replaceable units or modules).
This definition is fine for federated systems, but
1.A.2-4
IMA architectures require the ICD to include more
detail. The ICD must fully characterize all system
interface elements of the hosted system including
processing resource requirements and data
communication requirements. For example, non-
traditional ICD parameters include, but are not
limited to, processing time-slice, memory size,
message size, data rate, data latency, data jitter,
software API definition and timing (time to return
from API call), processor integrity, and network
integrity. These ICD parameters need to be defined
between each logical point within the system that
defines the data flows. Data flows do not have to
physically exit a box, so traditional wire connects
are not even defined between some of these points.
For example there are no wires between the hosted
system code and the platform APIs.
These non-traditional attributes lay the
foundation for the allocation of sufficient resources
to preclude massive system reconfiguration when
accommodating change. Wholesale system
reconfiguration has the potential to alter resource
attributes that affect another hosted system’s
requirements. Though a proper set of integration
tools will alert the system integrator of this
unintended effect, a new configuration must be
found that meets all requirements or the affected
hosted system must be re-validated in the new
configuration.
The danger of not fully defining the ICD is that
unintended change to other systems is more likely
to occur. A system developer is much less likely to
make a change that affects the ICD since the ICD
helps the developer understand the wide-spread
system impact of the modification. However if they
are able to make a change without affecting the
documented ICD, then they will conclude the
change will not impact other systems in the
integrated set. The danger of an incomplete ICD is
that changes could impact an undocumented ICD
parameter and affect another system. This would
be a surprise to most all parties. Surprises like this
can delay an initial certification program or bring an
existing production line to a halt.
Don’t Restrict your ICD Definition
Unnecessarily
A change strategy needs to be in place at the
outset to mitigate the potential for unintended
impact. That strategy starts with characterizing the
true system requirements for interfaces that lie
within shared resources. These requirements must
be validated/justified to prevent overly restrictive
requirements from becoming an issue later. It is
easy for a developer to draw from past experience
with federated systems and issue requirements that
were easy to achieve with dedicated [non-shared]
resources. If it worked in the past, then it is natural
to not change what worked. However that past
experience is not necessarily based upon an
optimized set of systems that share IMA resources.
It is possible that the hosted system could tolerate
less stringent requirements and thereby alleviate
shared resource contentions. These aspects of a
hosted system architecture become a critical
element for passing a preliminary design review
gate.
Architectural Decisions that Limit the Ability
to Reconfigure the Platform Resources
Allocation
While the strategies employed above are well
suited to contain change and avoid large scale
system reconfiguration, there will come a time
when significant new functionality will be
integrated into the system driving a large scale
reconfiguration. The same strategies help with this
scenario but additional considerations are necessary
as well. Hosted system elements need to be
portable. In other words, they require the ability to
be moved to a different physical resource without
impact. This may be necessary to “make room” for
the new system. Therefore hosted system
architectures that require multiple applications to be
allocated to the same physical processing resource
should be avoided. Co-location requirements are
typically driven by applications that require shared
memory or a specific execution order to operate
properly. The portability aspect of a hosted system
architecture becomes a key element for passing a
critical design review gate.
Change Containment when the IMA
Platform Changes
The second design philosophy unique to IMA
environments is related to IMA platform changes
(technology insertions). Hosted system changes are
1.A.2-5
one level of change, but the more costly change
occurs when the IMA platform is changed. This is
due to the fact that all the hosted systems depend
upon the platform, so a platform change has the
potential to impact all systems. It is critical to
create a well-defined strategy for platform changes,
and to carefully coordinate that strategy across all
suppliers of the hosted systems.
Platform changes are typically related to
technology insertions. They include things like a
processor bus speed increase, a processor swapped
out for new processor, and increased speed of
communication network.
There are two parts to the strategy to minimize
the cost of change for platform changes: Design and
Verification. First, the hosted system developers
should design time-insensitive mechanisms into
their system architecture. Next the hosted system
developers should employ a verification strategy
that addresses the full range of their resource
budgets.
Hosted Systems Should be Built Using Time-
Insensitive Architectures
A hosted system can be architected to work for
a point solution, or its design can be robust enough
such that it can tolerate certain changes in its
operating environment due to technology insertions.
The systems that employ the latter approach will
support a much lower cost of change over its
lifecycle.
There is an assumption in this paper that a
technology assertion will affect timing, and not
change the fundamental functionality of the IMA
platform. Platform functional changes are not
likely since they invalidate the usage domain for the
hosted systems. That scope of change is outside the
intent of this paper.
A little bit of design strategy up-front can save
a lot of time and cost later in the system’s lifecycle.
Three design considerations are discussed that can
help minimize a system’s sensitivity to data flow
timing.
Wall-Clock Based Event Schedules
Aircraft systems rely on the exchange of data
between internal processes within a system and
externally between separate systems. System
functions that source or sink data can be called data
“events”. Aircraft systems are usually
deterministic, which means that a data sink event
expects the data to become available (be delivered)
within a given time constraint. Likewise, a function
that sources data is required to deliver the data
within a given time constraint. There are two types
of time tables that these timing constraints can be
based upon. The first option is to rely on the
function’s current processing speed. In this case the
function’s time-slice, period, and execution order
define when the function requires the data to be
delivered. The function has well-defined point(s)
within its execution time when it is ready to process
new data. If any of the function’s timing
parameters are changed, then the execution points
that accept new data will be skewed in time (based
on processing time) and the delivered data may not
be available to the function at that time. This could
disrupt the functionality of the system. The second
option is to rely on “wall-clock” schedules. This is
the preferred design strategy in order to minimize
sensitivity to processor timing. In this case, the
function is still defined by the same parameters
(time-slice, period, execution order), but the data
delivery requirements are based upon a separate
timetable: wall clock. The function’s execution
points that accept new data are based upon wall-
clock rather than on the processing time table. The
function is architected to process new data
whenever those wall clock events occur. In other
words, the function’s process timing can change as
long as it still completes within the same wall clock
time interval. This tolerance allows for the
function’s process to be executed faster or slower
(increased/decreased bus speed), or be delivered on
a faster/slower communications bus without
affecting the system’s functionality and
performance.
Fast, Time-Sensitive Feedback Loops
There are types of systems that are not
appropriate for the shared IMA environment. Some
systems cannot afford enough tolerance in their
resource requirements to accommodate shared
resources. In other cases, the resource requirements
are extremely demanding, and it does not make
sense to drive the cost of the entire IMA platform to
meet the extraordinarily demanding requirements of
a small minority of the hosted systems.
1.A.2-6
Extremely fast feedback control loops may
have unique demands that are not common with
most of the other hosted systems. In this case it is
probably better to dedicate resources to that system
rather than to utilize a shared IMA resource.
Slower feedback control systems that are
sensitive to process timing rigidity in order to tune
their control parameters should also avoid shared
resources. If possible, these control systems could
be architected to be sensitive to wall-clock timing,
allowing the control parameters to be protected
from slight changes in process timing or data
delivery latencies.
Design for Asynchronicity
The timing between multiple elements in a
system can be synchronous or asynchronous. If it is
synchronous, then the processors are synchronized
to a common timetable and data delivery between
elements can be very deterministic in the context of
process timing. Since the functions on the separate
system elements always execute at the same time in
relation to each other, the data source and sink
events remains rigidly aligned with the function’s
process timing. The problem with this approach is
that a change to the timing to either function will
invalidate the data event timing and adversely
impact the system’s function.
The alternate approach assumes the system
elements operate asynchronously. This approach
minimizes the impact of a timing change for a
function’s process since the design does not rely on
processes between system elements to be synced.
Instead, the functions are designed to wall clock
time, and the data sink functions are able to tolerate
data deliveries across a range of timing conditions.
Verification Strategy Should Address Range
of Resource Performance
Design is the first part of the strategy to
contain change, but verification is the other half. It
is imperative that the verification strategy proves
that the hosted system meets its requirements given
a range of potential shared resource
performance [4].
When using dedicated [non-shared] resources,
the resource performance typically defined with a
narrow tolerance. In this case, the verification
strategy is able to verify the system to the as-built
system resource performance. However, when change if the hosted systems are designed and
using shared resources, the resource performance is verified using federated system philosophies.
more likely to be defined in terms of a bounded
range.
References
In this case, the verification effort requires
[1] Watkins, Christopher B., Randy Walter, Oct.
analysis and/or test methods to demonstrate that the
2007, Transitioning from Federated Avionics
hosted system can meet its requirements over a
Architectures to Integrated Modular Avionics, 26th
range of possible resource performance constraints.
Digital Avionics Systems Conference (DASC),
If the IMA platform resources are reconfigured in
Dallas, Texas, IEEE,
the future and the resource performance is changed
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&a
but remains within the verified performance budget,
rnumber=4391842.
then the change is effectively contained. The
change would not impact the hosted system. The [2] Watkins, Christopher B., Oct. 2006, Integrated
hosted system would not be required to perform any Modular Avionics: Managing the Allocation of
regression testing since the initial verification Shared Intersystem Resources, 25th Digital
activity remains valid. Avionics Systems Conference (DASC), Portland,
Oregon, IEEE,
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnum
Conclusions ber=4106349.
There are many design considerations that a
[3] Spitzer, Cary, Randy Walter, Chris Watkins,
system architect must address when developing a
Dec. 2006, Digital Avionics Handbook, 2nd
system hosted in an IMA environment. However it
Edition, Boca Raton, FL, CRC Press, Avionics
is not sufficient to simply rely on traditional design
Development & Implementation ch. 12-1:
philosophies that were founded in the federated
Genesis, www.crcpress.com/shopping_cart/product
design domain. The IMA environment introduces
s/product_contents.asp?id=&parent_id=&sku=085
new dependencies upon systems that share a set of
X&isbn=9780849350085.
resources, and these dependencies must be
addressed by the hosted system design and [4] Watkins, Christopher B., Oct. 2006, Modular
development efforts. Verification: Testing a Subset of Integrated
Modular Avionics in Isolation, 25th Digital Avionics
This paper has addressed three categories of
Systems Conference (DASC), Portland, Oregon,
design considerations: optimization of system
IEEE,
resources, change containment when hosted
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnum
systems change, and change containment when the
ber=4106353.
IMA platform changes. While this is not
necessarily an exhaustive list of design
considerations that are unique to the IMA Email Addresses
environment, it should highlight the fact that IMA Randy Walter: randy.walter@ge.com
developments cannot be managed exactly like
federated system developments. This is the main Chris Watkins: chris.watkins3@ge.com
point of the paper. IMA systems can provide great
levels of system efficiency, but there will be
unnecessary system growth and high costs of 27th Digital Avionics Systems Conference
October 26-30, 2008

1.A.2-7