ARINC 653 ROLE IN INTEGRATED MODULAR AVIONICS (IMA)
Paul J. Prisaznuk, AEEC staff, ARINC, Annapolis, Maryland
Abstract
The air transport industry has developed
ARINC Specification 653 as a standardized Real-
Time Operating System (RTOS) interface
definition. The document specifies the interface
boundary between avionics software applications
and the core executive software. The
standardization effort was sponsored by the airline
user community and involved many interested
parties, including airframe manufacturers, avionics
suppliers, RTOS suppliers, government and
academia.
ARINC 653 is a key enabler in the
development of Integrated Modular Avionics
(IMA). In many ways it represents a paradigm shift
for avionics development; in particular it recognizes
the RTOS as key component of an IMA system.
The commitment shown by industry to IMA could
not be more evident than that shown by the Airbus
A380 and the Boeing 787 avionics suites.
This paper will provide top-level overview of
IMA software architecture, the key elements of the
ARINC 653 standard and its current development
status.
Introduction
Integrated Modular Avionics (IMA) has now
come of age, being installed in practically every
new airplane model that enters service today. This
high-density avionics packaging concept first
introduced to airlines on the Boeing 777 has rapidly
gained acceptance in both military and commercial
aircraft, from the Lockheed C130 AMP, to the
Airbus A380 and the Boeing 787, to cite a few.
It is now most evident to even the most casual
of observers; IMA makes sense from a business
standpoint. The reduction of avionics weight and
volume attributed to IMA can translate directly into
the ability for air transport operators to carry
revenue-producing payload. This revenue can lead
to airline profitability, enable new aircraft
acquisitions and provide sustained commerce
required for industry growth. IMA has shown great
978-1-4244-2208-1/08/$25.00 ©2008 IEEE.
1.E.5-1
utility in air transport installations and it has a long
and productive future ahead.
Key Terms Used in this Document
APEX: Application/Executive Interface,
meaning the interface boundary between avionics
software applications and the RTOS.
Application: Software and/or application-
specific hardware with a defined set of interfaces
that, when integrated with a platform, performs a
function.
Core Module: A hardware component that
contains hardware resources (core processor and
devices).
Core Software: The operating system and
support software that manage platform resources to
provide an environment in which an application can
execute.
Partitioning: An architectural technique to
provide the necessary separation and independence
of functions or applications to ensure that only
intended coupling occurs. The mechanisms for
providing the protection in an IMA platform are
specified to a required level of integrity.
Application: Avionics software that provides a
specific aircraft function.
HM: Health Monitor, hardware and/or
software function that has shared responsibility
between the application software and the RTOS.
The Health Monitor must be able to perform fault
monitoring, fault containment and fault
management at both the application level and the
IMA system level.
IMA: Integrated Modular Avionics
RTOS: Real Time Operating System
ARINC 653 Background
In the mid-1980s the industry recognized that
all digital avionics systems had common
components; among them central processor,
memory and I/O. The Real-Time Operating System
(RTOS) was also identified as component deserving
of particular attention. It turned out that the RTOS
was being developed on an ad hoc basis for each
digital avionics system. This approach was both
costly and unnecessary. With this recognition, the
focus of standardization moved from hardware to
software. While the industry has been reluctant to
develop hardware standards for IMA, it has
wholeheartedly embraced software standards for
IMA and in particular: ARINC 653: Avionics
Application Software Standard Interface[1].
ARINC 653 was first adopted in 1997 by the
Airlines Electronic Engineering Committee
(AEEC). The acceptance of ARINC 653 by both
Airbus and Boeing for their latest aircraft has
solidified the role of ARINC 653 as an industry
standard. The level of industry acceptance has
broadened as a result, and now includes the entire
supply chain; from suppliers of IMA systems, to
suppliers of various modules and components,
software functional applications, and many others,
including the RTOS supplier.
ARINC Specification 653 is being developed
in four parts:
• ARINC Specification 653: Part 1[1],
Required Services
• ARINC Specification 653: Part 2[2],
Extended Services
• ARINC Specification 653: Part 3[3],
Conformity Test Specification
• ARINC Project Paper 653: Part 4,
Subset Services
Because this paper highlights the role of the
ARINC 653 standard in IMA systems, the reader
might be tempted to ask: Why develop a standard
Real-Time Operating System interface? The answer
resides in the vision, the technical concept, and the
benefits expected to be realized by the user
community.
A standardized RTOS interface provides two
key benefits. First, it establishes a known interface
boundary for avionics software development, thus
allowing independence of the avionics software
applications and the underlying core software. This
enables concurrent development of application
software components and the RTOS. The same
1.E.5-2
applications can be made portable among compliant
ARINC 653 platforms.
Second, the standard RTOS interface
definition enables underlying hardware platform
and the core software to evolve independent of the
software applications. Together, this approach to
IMA systems development assures a cost-effective
upgrade path over the entire life of the airplane.
The air transport industry has developed
ARINC 653 as a standardized RTOS interface
definition. It is specified as the interface boundary
between the avionics software applications and the
underlying core software, including the RTOS
proper. The standardization effort was sponsored by
the airline user community, through ARINC, and
involved many interested parties. Software
specialists convened and identified the specific
needs for avionics equipment:
• Safety-critical - as defined by FAR Part
25.1309
• Real-time - responses must be within
prescribed time period
• Deterministic - the results are predictable
and repeatable
ARINC 653 is the only RTOS interface
definition that supports these needs. Additionally,
avionics software is qualified to the appropriate
level of RTCA DO-178 / EUROCAE ED-12. This
process requires rigor and attention to detail.
Software must be demonstrated to comply with the
appropriate government standards set to assure safe
operation. Therefore, the RTOS is designed to be
simple and deterministic in its operational states.
IMA architectures encourage the integration of
many software functions. Mechanisms are provided
by the RTOS to manage the communication flow
between software applications and the data on
which they operate. Control routines are performed
as a result of system level events. These in turn
affect aircraft operation.
Software functionality within IMA is provided
by the software applications which rely on
computing resources provided by the avionics
platform. The use of application software offers
greater flexibility to meet user and customer needs,
including functional enhancement. As the size and
complexity of embedded software systems increase,
modern software engineering techniques (such as systems primarily. However, the concepts also lend
object oriented analysis and design, functional themselves to traditional federated equipment that
decomposition with structured design, top-down may contain more than one partitioned function.
design, bottom-up design, etc.) can ease the
An example of the software architecture is
software development process and improve
shown in Figure 1. The primary components of the
productivity. Among the many advantages,
system are: applications software that performs the
software can be defined, developed, managed and
avionics functions and core software that provides a
maintained as modular components.
standard and common environment for software
The ARINC 653 scheduling model can be applications. The core software includes:
described as a two-tier model, with the top-level
• Real-Time Operating System (RTOS) -
using fixed temporal scheduling of software
Manages logical responses to
partitions. The applications running in these
applications demands. It allocates
partitions have full access to IMA computing
processing time, communications
resources. At the lower-level, each partition can use
channels and memory resource.
interrupts and other asynchronous events to ensure
real-time requirements are met within its partition • Heath Monitor (HM) - Initiates error
boundary. The RTOS allocates resources and recovery or reconfiguration strategies
enforces all partitioning rules. that perform a specific recovery action.
• Hardware Interface System (HIS) -
Overall System Architecture Manages the physical hardware resources
The ARINC 653 software interface on behalf of the RTOS.
specification has been developed for use with IMA
APPLICATION
SOFTWARE

Application Application
Software Software
System Partition(s)
of of
Partition 1 Partition 2

APEX

LOGICAL COMMUNICATIONS EXCEPTION HANDLING

OPERATING SYSTEM
ENVIRONMENT
SOFTWARE

PARTITIONING SCHEDULER HEALTH MONITOR

CORE
PROCESSOR
CORE

MEMORY MANAGEMENT CONTEXT SWITCHING BIT

PHYSICAL COMMUNICATIONS
DEVICE HANDLERS HARDWARE INTERFACE SYSTEM

INTERRUPT HANDLING
CORE

COMMUNICATIONS BITE
INTERRUPT CONTROLLER
MEDIA

HARDWARE
MMU CLOCK

Figure 1. System Architecture (ARINC 653)

1.E.5-3
 The partition is similar to that of a multitasking
application within a general purpose computer.
Each partition consists of one or more concurrently
executing processes, sharing access to processor
resources based upon the requirements of the
application. All processes are uniquely identifiable,
having attributes that affect scheduling,
synchronization, and overall execution.
The RTOS is responsible for allocating
processor time and memory regions to each
application. These are configurable items in the
RTOS that are managed by the system integrator.
To enable application software portability,
communication between partitions is independent
of the location of both the source and destination
partition. An application sending a message to, or
receiving a message from, another application will
not contain explicit information regarding the
location of its own host partition or that of its
communications partner. The information required
to enable a message to be correctly routed from
source to destination is contained in configuration
tables that are developed and maintained by the
system integrator, not the individual application
developer. The system integrator configures the
environment to ensure the correct routing of
messages between partitions hosted on a IMA
platform.
The Application/Executive (APEX)
Interface
The principal goal of the APEX interface is to
provide a general-purpose interface between the
application software and the RTOS proper.
Standardization of this interface boundary (also
called RTOS interface) allows for application
portability between ARINC 653 compliant
platforms and the procurement of hardware and
software from a wide range of suppliers. This
promotes competition, reduces development cost
and reduces overall cost of ownership. The main
features of the ARINC 653 RTOS interface are as
follows:
1. The RTOS interface provides the
minimum number of services consistent
with the need to fulfill IMA
requirements. The interface is expected
to ease the development of application
1.E.5-4
software and assist software developers
in the production of reliable products.
2. The RTOS interface is extendable to
accommodate future system
enhancements. The RTOS interface
retains compatibility with previous
versions of the software.
3. The RTOS interface satisfies the
common real-time requirements for Ada
and C programming languages. These
different models should use the
underlying services provided by the
RTOS interface in accordance with their
certification and validation criticality
level.
4. The RTOS interface decouples
application software from the actual
processor architecture. Therefore, the
impact of hardware changes on the
application software can be minimized.
The RTOS interface allows application
software to access the executive services
but insulates the application software
from architectural dependency.
5. The RTOS interface specification is
language independent. This is a
necessary condition for the support of
application software written in different
high-level languages, or application
software written in the same language
but using different compilers. The
fulfillment of this requirement allows
flexibility in the selection of compilers,
development tools, and development
platforms. The RTOS interface places
layering and partitioning demands on the
RTOS proper to allow growth and
functional enhancement.
Communication requests can be made in one
of several modes. The application can request that
the function be performed and be suspended,
awaiting completion of that request, or continue
running and either poll the status of the request or
be merely alerted that the transaction is complete.
Inside the ARINC 653 RTOS
The main role of the RTOS is to ensure
functional integrity in scheduling and dispatching
application programs. It is a function of the RTOS
to allocate processing time to each partition,
dispatch each process for execution, provide the
necessary memory and I/O resources and absolutely
ensure partition isolation in time and space
(memory). It should be possible to prove that the
level of temporal determinism (i.e., specific
behavior at a specific time) is unaffected by the
addition of other applications to the IMA platform.
It should be pointed out that partitioning cannot be
provided by the RTOS alone. Rather, this is a
combined function of the RTOS and memory
management hardware.
One method of achieving this is to implement
a method of time slicing and to split applications
into strict tempo or scheduled groups. Each strict
tempo application is assured a specific amount of
processing time in each time slice so that it can
perform a certain number of defined algorithms in
each allocated time slot. If an application attempts
to overrun its time slot then it is timed out by the
RTOS. The scheduling provides a sufficient amount
of time to each time slice for this to work
efficiently.
The RTOS is capable of recognizing both
periodic and aperiodic processes, and scheduling
and dispatching all processes. It provides health
status information and fault data for each partition.
Since the RTOS will need to perform with a high
degree of integrity for critical applications, it will
have certification criteria that are commensurate
with the collection of functions. The design of the
RTOS, therefore, should be as simple as possible.
The RTOS also manages the allocation of
logical and physical resources on behalf of the
applications, and ensures those allocated resources
are isolated from each other. It is responsible for the
management of memory and communications. It
receives interrupts associated with power failure
and hardware error, relaying these incidents to the
Health Monitor function, which in turn directs the
necessary actions to enable recovery or otherwise. It
should also channel application-specific software
interrupts or events to the appropriate application to
a defined time scale. As manager of all physical
resource in this environment, the RTOS monitors
1.E.5-5
requests for resources and controls access for those
resources which cannot be used concurrently by
more than one application. It has access to all
memory, interrupts and hardware resources.
The RTOS is capable of reporting faults and
executing subsequent actions. In its allocation and
management of resource requests and
communication interfaces from and to applications
it has limited access to the applications memory.
Because Health Monitoring has a special role in
IMA, it is treated as a separate topic in this paper.
In particular, Health Monitor functions must be
allocated to both application software and the
RTOS.
The processing of a communication request
within the RTOS consists of setting up the
appropriate I/O format and passing the message to
the hardware interface. To ensure temporal
determinism, each message definition includes a
maximum and minimum time of response. Certain
message types also include a timeout specification
which could be set up by the application. Hence all
communications including requests, commands,
responses, data I/O, etc., between the applications
and the RTOS is rigorously defined by ARINC 653.
Part 1 of ARINC 653 addresses these aspects
of the RTOS:
• Partition Management
• Process Management
• Time Management
• Memory Management
• Interpartition Communication
• Intrapartition Communication
• Health Monitor
Given a rigorous definition of the RTOS, it is
possible to integrate and test applications on a
general purpose computer which simulates the
RTOS interface. It is also possible to host a variety
of applications without need to modify the RTOS.
Standardized RTOS message definitions allow a
growth path for future enhancement of the interface.
As long as any future RTOS definition is a superset
of earlier definitions, then no conflict will arise as a
result of any enhancement.
Health Monitor Function
The Health Monitor function resides with the
RTOS and interfaces to a recovery strategy table
defined by the aircraft designer or system
integrator. The Health Monitor is responsible for
monitoring hardware faults within IMA platform
and faults within the RTOS. Hardware faults
detected by the Built-In Test (BIT) include memory
and processor faults. Any local hardware
reconfiguration is hardware implementation specific
and takes place within the hardware interface
system. This is transparent to the rest of the IMA
system.
The RTOS monitors the hardware responsible
for the integrity of the software partitions and
communicates with the Health Monitor function on
software and hardware integrity failures. The
Health Monitoring function is specific to the IMA
platform and to the specific aircraft installation.
Therefore, this software is partitioned into an RTOS
Health Monitor and a recovery strategy table. The
latter requires configuration definition and recovery
strategies embedded within it. The RTOS contains
an error reporting capability which can be accessed
by applications. If an application detects a fault in
the operation, it is able to report this to the RTOS
which in turn invokes the Health Monitoring
function. It is the role of the application to inquire
health status and any reconfiguration that might
have been performed. The RTOS is bound by the
RTOS interface specification to provide standard
Application Program Interface (API) to all types of
application software.
Faults are detected at various levels. The
objective is to contain faults before they propagate
across an interface boundary. In addition to self-
monitoring techniques, application violations,
communication failures and faults detected by
applications are reported to the RTOS. A recovery
table of faults is used to specify the action to be
taken in response to the particular fault. This action
initiated by the Health Monitor and might include
the terminating an application and starting an
alternative application, together with an appropriate
level of reporting. The recovery action is largely
dependent on the design of the IMA system.
1.E.5-6
Two types of Health Monitor recovery tables
are possible. One table is provided at the partition
level. The other table is provided at the system
level, for the integration of several partitions on a
module. For partition level errors, the local partition
Health Monitor table would:
• Define the error level (partition or
process)
• Define the action at partition level
• Define the error code in case of process
error level
Acceptable methods of Health Monitoring are
evolving within industry and this will be reflected
in future updates to ARINC 653. These are
expected to emerge in 2009-2010.
Software Applications
Application software is developed in modules
that perform a specific function on the aircraft.
Today functions like Flight Management and Data
Link Communications Management can be
implemented in software, using generic IMA
computing resources. The software applications are
specified, developed and verified to the level of
criticality appropriate to its function. Within an
IMA platform, each application software module
operates independently using the resources
provided by the IMA platform.
The application software is responsible for the
redundancy management for a specific function,
and for signal selection and failure monitoring of
inputs from external sensors or other systems.
Modular software design enables the
implementation of software partitions to isolate
avionics functions within a common hardware
environment. Application software is independent
of hardware, though some applications will require
dedicated I/O sensors, such as a pitot static probe.
Software modules may be developed by
independent sources and integrated into the IMA
platform. Therefore, it is necessary for software
within a partition to be completely isolated from
other partitions so that one partition cannot cause
adverse affects in another partition. To ensure
partition integrity, partition load images are
statically and separately built. These applications
stand alone as independent program modules with
no interdependencies with other program modules.
These applications may require dedicated controls
and display, I/O processing and associated
hardware.
Process scheduling attributes are used by the
partition code to change the execution or state of a
process within that partition. In this way the
integrity of one application is not compromised by
the behavior of another application, whether the
other application is deemed more or less critical.
All communications between applications are
performed through the RTOS whose mechanisms
ensure that there is no violation of the interface and
that no application either monopolizes a resource or
leaves another permanently suspended.
I/O handling is one significant area which in
traditional applications development is very specific
to the aircraft configuration of sensors. In the
interest of portability and reuse, the partitioning of
the applications software architecture should
identify the aircraft specific I/O software and
partition it from the functional and algorithmic
elements of the application. Such sensor I/O
conditioning is logically defined as a separate
function associated with the sensor.
Most applications require functional data at
specific rates. Much of the design of applications
which ties them specifically to a particular aircraft
system is the sensor handling. The removal of this
function from the application increases portability
and, furthermore, it concentrates the sensor
handling into a single area, allowing sensor data
with specific characteristics to be generally
available to more than one application. Changes to
sensor characteristics are confined to sensor data
managers, thereby increasing portability and reuse
of applications software. The applications software
is invoked by the scheduling component of the
RTOS in a deterministic manner.
Current Status of ARINC 653
ARINC 653 is evolving to meet industry
needs. Part 1 is being updated to align terminology
with that used in RTCA DO-297/EUROCAE ED-
124: Integrated Modular Avionics (IMA)
Development Guidance and Certification
Considerations[4]. These changes are expected to
add further to the common understanding of
1.E.5-7
ARINC 653 principles, including broader
acceptance within the regulatory community. The
terms defined are:
Core Module: A hardware component that
contains hardware resources (core processor and
devices).
Core Software: The operating system and
support software that manage platform resources to
provide an environment in which an application can
execute.
Within ARINC 653, these terms are elaborated
to explain that each core module can contain one or
more individual processors. The core module
architecture has influence on the RTOS
implementation, but not on the APEX interface
used by the application software of each partition.
The processes of a partition cannot be distributed
over multiple processors, either in the same core
module or in different core modules. Application
software should be portable between core modules
and between individual processors of a core module
without modifying its interface with the RTOS.
ARINC 653 Extended Services
ARINC 653 Part 2 defines Extended Services
that are viewed to be desirable, but they are not
required to be used in an ARINC 653
implementation. Part 2 describes software services
viewed to be valuable to application programs after
many years of industry experience with IMA
systems.
ARINC 653 Extended Services include:
• File System
• Sampling Port Data Structures
• Multiple Module Schedules
• Logbooks
• Sampling Port Extensions
• Service Access Points
The ARINC 653 File System is defined in
Part 2. The file system is a general purpose way of
managing data storage. Much like the file system in
a desktop environment, the file system hides and
manages the details of the various forms of data
storage on a module. Specifically, the file system is
a set of services that provide the ability to open,
close, read, write, and delete files and directories.
Each implementation provides a unique set of one
or more types of storage media, such as RAM,
Flash, EPROM, or network based media. The file
system permits multiple partitions to use the
services to access the storage media. The file
system manages the low-level details of the media
for the partitions using it.
Many avionic applications use a file system to
organize permanent data for storage and retrieval
from local or networked computers or to store data
temporarily in volatile memory. For example, the
Flight Management System (FMS) needs a file
system to look up route information during flight.
The Terrain Awareness and Warning System
(TAWS) needs a file system to access digital terrain
elevation and obstacle data from its data bases.
Sampling Port Data Structures are defined in
Part 2. This provides a standardized set of data
structures for exchanging parametric data. Included
in this definition is a standardized method for
conveying the status of the data. The objective is to
reduce unnecessary variability in parameter
formats, thus reducing the need for custom I/O
processing. When used properly, this will enhance
portability of applications, and improve efficiency
of the core software. This is analogous to typical
aviation data buses (e.g., ARINC 429, ARINC 629,
ARINC 664 P7, etc.), where the message payload
format complies with a set of standard type and
status indication rules. Since interpartition
communication has to meet many of the same
objectives as data bus communication, it makes
sense to have a similar set of rules for it. This
capability eases ARINC 653 communication of
interpartition messages over aircraft buses and
aircraft networks.
ARINC 653 Part 2 also supports multiple IMA
schedules. ARINC 653 has introduced multiple
IMA schedules to enable IMA systems to schedule
different functions at different times. The following
are examples of where multiple module schedules
are useful:
1. Initialization/Program Elaboration –
Each partition requires a certain amount
of time to initialize its variables, data,
structures, and associated hardware.
1.E.5-8
2. Component failures – Application
programs critical to continuous flight and
airworthiness could be allocated to run
on another processor, replacing a less
critical application, when the primary
processor fails.
As an example of multiple schedules, the data
loading function resides in one partition, so it
receives specific time and space allocation. In the
data loading mode, the data loading function gets
all the central processing unit bandwidth for
maximum speed and efficiency. But after data
loading is complete, built-in mechanisms allow the
software to switch to the normal operational flight
mode, with data loading deactivated. Aircraft
employing multiple schedules will need to certify
each mode and the transitions between modes.
Logbooks are defined in ARINC 653 Part 2 as
a means used to store messages. The logbook
retains the stored data in the event of a power
failure. The data can be recovered when power is
restored to the module. Each logbook is accessible
by only one partition. The logbook consists of a
buffer in Non-volatile Memory (NVM). A message
logged in a logbook is initially stored in the buffer
before being written into memory. The buffer
allows the application to write several messages in
the logbook in rapid succession without having to
wait the time needed for writing the NVM between
each message.
Sampling Port Extensions are defined in
ARINC 653 Part 2 for adding the following
sampling port services:
1. READ_UPDATED_SAMPLING_MESS
AGE
2. GET_SAMPLING_PORT_CURRENT_
STATUS
3. READ_SAMPLING_MESSAGE_CON
DITIONAL
The main purpose for these services is to
provider greater flexibility to the application when
reading sampling port messages.
Service Access Points (SAPs) are defined in
ARINC 653 Part 2. A SAP is a special kind of
queuing port that allows access to addressing
information when sending and receiving messages.
The SAP services are similar to the ARINC 653
queuing port services but will have additional
parameters to support address information. SAP
ports are typically used in client/server applications,
where there are a number of possible addressees,
but for a specific message a single addressee must
be specified. Because this may change in real time,
it is desirable to have a mechanism for an
application to have some control over the
addressing.
Conformance Testing in Part 3
Part 3 of ARINC 653 provides guidance for
testing RTOS conformity to ARINC 653, the
ultimate goal of which is to provide a standard test
suite and set of test code. Part 3 presently covers
only those tests pertinent to ARINC 653 Required
Services defined in Part 1. Conformity Tests for
Extended Services will be provided in a future
Supplement to ARINC 653. ARINC encourages
developers of ARINC 653 operating systems to
work together to reach consensus on methods for
independent testing.
Coming Soon: A Lean-Mean Subset of
ARINC 653
The latest ARINC 653 document in the set is
Part 4, is due to emerge later in 2008-2009. The
popularity of ARINC 653 has generated a need for
a lean subset of ARINC 653 to support non-
partitioned, single-thread computing platforms. The
intention is to optimize memory space and improve
processor performance. Further, the goals are to:
1. Reduce RTOS code footprint, reduce
system states and enable formal proof
techniques
2. Simplify dynamic behavior, ease
temporal behavior and use formal
methods for analysis
3. Provide only required services with no
deactivated code or dead code
4. Simplify the Health Monitor
Summary
ARINC 653 is a key enabler in the
development of Integrated Modular Avionics
(IMA). The commitment shown by the industry to
IMA could not be more evident than that shown by
1.E.5-9
the Airbus A380 and the Boeing 787 avionics
suites. IMA core software can support multiple
avionics applications; it can be developed
concurrently and hosted on one computing
platform. The emergence of ARINC 653 has
created a competitive business environment where
avionics suppliers can readily purchase an RTOS
that is EUROCAE ED-12 and RTCA DO-178B
“certifiable” to Level A - the most stringent
software certification level. This business
environment ensures that only the best products fill
the market.
In addition to minimizing the direct cost of the
RTOS, ARINC 653 helps to manage Non-
Recurring Engineering (NRE) cost of avionics
application software development. Because
emerging RTOS products will likely comply with
both ARINC 653 and RTCA DO-178B, an
environment of acceptance and understanding is
evolving. Application developers, software
engineers, programmers, regulatory authorities and
the community at large will all benefit from IMA.
Together, the IMA principles enable millions
of lines of avionics software to be developed and
approved as necessary to meet airline operational
needs over the entire life of an aircraft.
References
[1] ARINC Specification 653: Part 1, Avionics
Application Software Standard Interface, Required
Services (March 7, 2006) available from ARINC,
2551 Riva Road, Annapolis, MD 21401
https://www.arinc.com/cf/store/index.cfm
[2] ARINC Specification 653: Part 2, Avionics
Application Software Standard Interface, Extended
Services (January 22, 2007) available from ARINC,
2551 Riva Road, Annapolis, MD 21401
https://www.arinc.com/cf/store/index.cfm
[3] ARINC Specification 653: Part 3, Avionics
Application Software Standard Interface,
Conformity Test Specification (October 16, 2006)
available from ARINC, 2551 Riva Road,
Annapolis, MD 21401
https://www.arinc.com/cf/store/index.cfm
[4] RTCA DO-297/ED-124: Integrated Modular
Avionics (IMA) Development Guidance and
Certification Considerations available from RTCA,
18th Ave NW, Washington D.C., www.rtca.org and
EUROCAE, Paris, France, www.eurocae.org
Acknowledgements
ARINC would like to recognize the
commitment of industry participants in this activity,
and in particular the leadership provided by both
Airbus and Boeing. Gordon Putsche, Boeing, serves
as U.S. Chairman for this activity. Airbus has
provided Peter Anders, Serge Goiffon and Frederic
Aspro in leadership positions.
27th Digital Avionics Systems Conference
October 26-30, 2008

1.E.5-10