MKROPPdXESORS AND

MICROSYSTEMS
ELSEVIER Microprocessors and Microsystems 20 (1997) 479-483

ARINC 653 - Achieving software re-use

A. Cook”, K.J.R. Huntb
aFormerIy with British Aerospace Airbus Ltd. Airframe Avionics, 867-02. Cl New Technical Centre. PO Box 77, Filion. Bristol, Avon, 8599 7AR, UK
‘British Aerospace Airbus Ltd, Airframe Avionics, 867-02, Cl New Technical Centre, PO Box 77, F&on. Bristol, Avon, B599 7AR, UK

Abstract

A key goal of the ARINC 653 (APEX) specification is the achievement of software re-use through provision of a standard
operating environment for applications software. Reuse of software can be achieved in two ways: (i) by re-using operating systems,
which provide common functions across the application spectrum, eg. health monitoring, process management, communications
mechanisms; and (ii) by re-using the applications software which provides avionics applications functions. By provision of a stan-
dardised interface between applications and operating system, ARINC 653 facilitates both forms of re-use.
Operating systems are by nature tightly coupled to the underlying hardware platform, re-use of operating systems is therefore
limited to modules employing the same hardware unless a new standard such as COEX (Core Executive Interface) can be tightly
defined.
Applications software is often dependent on the actual aircraft implementation. Direct re-use of applications will not always be
possible; however, by use of ARINC 653, it will be possible to re-use individual partitions of an application in other applications.
ARINC 653 is language-dependent
and within languagessuch asAda there is scopefor functionally identical implementations
which are syntactically different. Unless definitive language implementations of ARINC 653 are adhered to, language issues will
becomea major hurdle to re-use.
A large cost of avionics development (particularly software) is the cost of certification. Currently, avionics functions are certified at
the ‘system’level. In order to maximisethe benefits of software re-use, means must be found to claim credit for previously-developed
softwarecomponentsof a system.EUROCAE WG48 and RTCA SC182arecurrently investigatingthis issuein their definition of an
Avionics Computing Resource.It is hopedthat thesegroups,working in co-operationwith ARINC 653,will provide the meansto
achievethe benefitsof re-use.

Keywords: Software m-use; Integrated Modular Electronics; ARINC 653

1. Introduction This paper discussesthe issuesof software re-use and

A key goal of Integrated Modular Avionics (IMA) is
achievement of cost benefits through the re-use of com-
ponents. Software re-use will be facilitated through the
Application Executive interface (APEX) defined in the
ARINC 653 [l] working paper.
Compliance with the APEX interface will allow soft-
ware to be used on another platform without changes to
the source code. However, the maximum benefits of soft-
ware re-use will not be obtained unless the software is
written in a modular manner in responseto a functional,
rather than aircraft application specific, set of require-
ments. This re-use of software will enable development
and through-life cost benefits to be achieved when
compared to the incremental design approach often
used when migrating designsbetween aircraft variants.
0141-9331/97/$17.00 c 1997 Published by Elsevier Science B.V.
PII s0141-9331(97)01113-1
describes the means of achieving the cost benefits of
re-use through the ARINC 653 interface. The objectives
of the EUROCAE WG-48 and RTCA SC- 182, which are
defining a Minimum Operational Performance Standard
(MOPS) for an Avionics Computing Resource (ACR),
are also described. The impact of the ACR MOPS, in
conjunction with ARINC 653, on the certification of
re-usable software is discussed.
2. Why r-e-usesoftware?
Currently, the procurement of avionics software is
very expensive. In an avionics system, software often
accounts for a high percentage of the development
480 A. Cook, K.J.R. Hunt/Microprocessors
cost, particularly if industry standard hardware modules
are used. A large proportion of this development cost is
incurred in meeting certification requirements in
particular complying with the verification and validation
pro-cesses. While safety and certification requirements
must remain paramount there is obvious potential for
cost benefit if software can be re-used in new imple-
mentations and credit taken for previous certification
effort.
Re-use of applications is appropriate in the following
circumstances:
i) the application is to be implemented in a different
airframe type, but where the software requirements
are unchanged.
ii) although the software requirements have not changed,
it is thought beneficial to upgrade or modify the
hardware platform.
iii) new options or functions are identified for existing
software. Additional software can be added while the
remainder is re-used.
3. Current barriers to cost effective re-use of software
Presently, avionics software is procured by the air-
frame manufacturer as part of a system providing an
aircraft function. The computing platform is purpose
built to an architecture which meets the availability
and integrity requirements of the aircraft function. Hard-
ware and software are thus tightly coupled, both to each
other and to the actual aircraft implementation. Any
changes to the aircraft functionality will require changes
to the existing software code. The full verification and
validation process must therefore be repeated to ensure
that the changes do not prevent existing software from
meeting its requirements. Similarly the re-use of an entire
application in a new airframe type is often not possible.
Components of software from previous implementations
may be re-used in new implementations. Such com-
ponents must execute in conjunction with components
which have been specifically developed for the new
implementation, and all software components of the
new implementation are therefore subject to the com-
plete verification and validation process.
Cost effective re-use will only be achievable when com-
ponents of software can be added to a system, with the
assurance that the new components do not affect the
integrity of existing software.
4. Achieving re-use with integrated modular avionics
IMA, as described in ARINC 651 [2], proposes an
approach to avionics design which places emphasis
firmly on component re-use. IMA components conform
and Microsystems 20 (1997) 479-483
to an open standard allowing manufacturers to produce
equipment which is decoupled from an actual imple-
mentation. These components are configured into an
architecture which meets the availability and integrity
requirements of the aircraft functions to be implemented.
5. IMA software and ARINC 653
Within IMA, applications software will provide each
system’s functionality. The applications software runs
under the control of an executive, with one or more
applications running on a core processing module. The
executive provides a set of system services to the appli-
cations, eg. memory allocation, process management,
communications services and health monitoring, thus
decoupling the applications from the hardware environ-
ment. Using an executive enables applications to become
relocatable across core modules. However, re-use of
applications across dissimilar executives will only be
achieved if the interface, through which the executive
services are accessed, is the same for all possible execu-
tives. This requirement is the main driver for the ARINC
653 working paper ‘Avionics Applications Software
Standard Interface’. ARINC 653 defines the Application
Executive (APEX) interface. A set of services required
by an avionics executive are described and a set of pro-
cedure declarations by which they are accessed are
defined, these declarations being the APEX interface.
By the nature of the services they provide, executives
are tightly coupled to the underlying architecture of the
hardware.
The executive itself is a re-usable component of soft-
ware, providing functionality which would otherwise be
a requirement of the application software. However,
because of the coupling to hardware, executives are not
easily portable across different platforms. To enable the
re-use of executives across different platforms, a further
interface known as the Core Executive (COEX) inter-
face is described in ARINC 651 [2], which is a logical
interface between an executive and the underlying
hardware. As yet, no ARINC working group has been
set up to define the COEX. Currently, it is expected that
the executive will be supplied as an integral part of
the core module which, itself, will be the re-usable
component.
6. Partitioning for safety
From the discussion in the previous paragraph it can
be seen that ARINC 653 is the key standard for facilitat-
ing re-use of avionics applications software in IMA.
ARINC 653 provides a common logical environment
for applications software, allowing software to be ported
 A. Cook, K.J.R. Hunt/Microprocessors
from one platform to another. However, from earlier
discussion, it is clear that to maximise the cost-benefits
of re-use, it is necessary to reduce the verification and
validation effort required when software is re-used.
ARINC 653 addresses this issue through the concept of
partitioning. Applications software executes within a
number of partitions, each of which is isolated in time
and space from other partitions. The software within a
particular partition can only address a pre-allocated area
of memory, and can only execute within pre-determined
timeslices.
The partitioning mechanism ensures that software
errors in one partition do not propagate into other par-
titions. There are three main advantages for re-use,
gained by implementation of the partitioning mechan-
ism; software of different DO- 178B [3] levels can execute
on the same module, malfunction of software in one
partition cannot affect execution of software in other
partitions, new software can be added to or removed
from a partition without affecting the execution of soft-
ware in other partitions.
By employing the partitioning mechanism appli-
cations can be partitioned into loosely coupled com-
ponents. Where it can be shown that failure of a
particular component does not adversely affect the
critical functions of the application, the component’s
software can be assigned a lower DO-178B [3] level,
something that obviously has advantages both during
initial design and when the component is re-used. Modi-
fied software can be added to partitions while re-using
software in other partitions without repeating the verifi-
cation and validation process. As long as it is demon-
strated that software can be located in a partition,
meeting its time and space requirements, software can
therefore also be ported to a different module without
repeating the verification and validation processes.
Partitioning, however, is only a means of ensuring that
errors do not propagate between components. Partition-
ing cannot guarantee that common mode or combina-
tional failures cannot occur, nor does it provide a means
of fault recovery. For example, if two partitions each
contain software performing a function whose individual
loss is major but whose combined loss is catastrophic,
and they execute on the same module, then the processor
is a single point of failure which would lead to a cata-
strophic failure condition. The configuration of par-
titions onto core modules must therefore satisfy the
normal safety assessments, assurance must be provided
that functional availability and integrity requirements
are met, and that common mode failures are eliminated.
In order to implement the ARINC 653 partitioning
mechanism, the timing requirements of each application
must be known, and a partition execution schedule
derived for each module. The schedule must be periodic
to allow deterministic execution, although applications
may need to respond to aperiodic events. Aperiodic
and Microsystems 20 (1997) 479-483 481
processes must therefore be allocated timeslices within
the partition execution cycle; if the aperiodic event
does not occur, processing will not take place within
the allocated timeslice. Similarly, a partition’s software
may occasionally complete its execution before the end
of the partition timeslice, in which case all processing is
suspended until the end of the timeslice. Nothing can be
done to recover the under-utilised processor time, as the
partitions must execute with fixed periodicity.
7. Challenges of the IMA approach
A major disadvantage of the IMA approach is the
level of work required by the system integrator. The sys-
tem integrator must determine how applications will be
partitioned in terms of functionality and predict the
memory and time requirements of each partition. The
integrator is responsible for allocating functions to
modules and defining the partition execution cycle for
each module. The definition of the time schedule is a
task whose complexity is likely to rise exponentially
with the number of partitions to be configured onto a
core module. It is unlikely that a schedule of even
moderate complexity can be determined manually and
therefore the assistance of sophisticated software tools
will be required. Because of the relocatable nature of
applications, any particular partition may need to pass
messages to partitions located either on the same
module, on a different module in the same cabinet or
outside the host cabinet. The integrator is responsible
for ensuring that the communications paths are set up
for each partition, by generating configuration tables for
each module which provide routing information for all
messages sent and received by each partition resident on
the module. The generation of configuration tables is
another high-complexity task which will require sophis-
ticated tools to assist successful implementation.
The successful achievement of IMA objectives is
highly dependent on being able to control the complexity
of implementations and the development of tools which
can alleviate the work load of the system integrator.
8. Software re-use outside the IMA environment
The problems described in the previous paragraph are
essentially caused by attempts to integrate aircraft func-
tions into a common system environment. Functional
integration is not, however, essential for achieving cost-
effective re-use. The APEX interface is independent of
any physical implementation and is equally applicable
to Line Replaceable Units (LRUs) and to IMA Line
Replaceable Modules (LRMs).
EUROCAE WG-48 and RTCA SC-l 82 were established
to define a Minimum Operational Performance Standard
482 A. Cook, K.J.R. Hum/Microprocessors
(MOPS) for an Avionics Computing Resource (ACR).
The ACR will be a generic computing module which can
host unspecified applications software, and the MOPS
will define a set of characteristics which will establish if
the ACR is capable of hosting a certain class of appli-
cation. An IMA core processing module may achieve
the classification of an ACT but an ACR is not neces-
sarily an IMA core processing module. EUROCAE
WG-48 has made the reduction of certification costs
when re-using applications software one of its primary
objectives. This cost reduction will be achieved through
pre-qualification of the ACR, and an ACR developed to
comply with the MOPS will be qualified to host certain
types of application software. It is anticipated that there
will be a number of ACR classes. The ACR MOPS will
describe a logical environment for the execution of appli-
cations software, rather than focusing on the physical
hardware characteristics. The ACR will therefore consist
of a processor and operating system with a standard
Applications Programming Interface (API); the
APEX will hopefully be adopted as the API. The
ARINC 653 working group and RTCA SC-182 have
met to discuss common issues of ARINC 653 and the
ACR. The agreement and participation of the air-
worthiness authorities is essential to the success of
the ACR MOPS. The concept of component pre-
qualification, for an unspecified application, is a radical
one. Precisely what credit can be taken when porting
software from one ACR to another needs to be defined
and agreed with the authorities. Currently, the FAA
actively participates in RTCA SC-182, and EUROCAE
WG-48 has made the European Authorities aware of
its objectives and intentions.
9. Timescales for applicable standards
ARINC 653 is approaching completion of Phase 1.
All the services have been defined and the service call
procedures specified. However a final review meeting
will be held towards the end of 1995. The major topic
at this meeting will be to agree two appendices giving
a definitive specification of the APEX in Ada and C.
The appendices are necessary because although Sec-
tion 3.0 of ARINC 653 specifies the service calls as
a set of pseudo-code procedure declarations, there
remains a possibility of producing functionally identi-
cal implementations which have syntactic differences.
This could arise, for example, where Ada generic
packages are used. Syntactic differences would affect
the portability of software across different APEX
implementations, and it is therefore proposed to
include comprehensive language definitions as gui-
dance to developers,
RTCA SC-182 and EUROCAE WG-48 intend
to complete the specification of the MOPS for ACR by
and Microsysiems 20 (19973 479-483
September 1997. Subject to their approval of the MOPS,
the FAA has agreed to produce a Technical Standard
Order based on the MOPS by September 1998.
10. Conclusions
Software re-use is potentially of great benefit to the
avionics industry and the biggest benefit will be in the
area of certification. The benefit will only be achieved if
mechanisms can be established to enable the carrying
over of previous verification and validation work, when
software components are re-used.
To facilitate re-use, a move away from hardware and
software which are both tightly coupled to specific func-
tions is required. Avionics computers should instead be
based on processing modules which feature an executive
allowing relocatable applications. IMA and the more
recent ACR concept propose this type of solution.
ARINC 653 describes the required functionality of an
Avionics Executive and defines the APEX interface
through which applications access the services. By devel-
oping executives which comply to the APEX interface,
applications can be ported across modules. ARINC 653
is a key standard for avionics software re-use.
One of the main features of ARINC 653 is the defini-
tion of partitioning. Partitioning ensures that the exe-
cution of software within a particular partition cannot
be adversely affected by software executing in another
partition. The implementation of this concept enables
software of different criticalities to execute on the same
processing module and to allow changes to software
within one partition while guaranteeing that other par-
titions are not affected. Partitioning is therefore a crucial
concept to enable certification credit to be taken when
re-using software.
ARINC 653 and the ACR MOPS provide a mech-
anism for re-use of applications software, although the
means of gaining certification credit is dependent on
a process of pre-qualification of components. Pre-
qualification is a radical concept for certification and
will only be achieved in co-operation with the certifica-
tion authorities.
ARINC 653 is applicable both to IMA and future
LRU implementations. Early adoption by industry will
ensure that future avionics software will be upwardly
compatible with later IMA solutions, and the benefits
of successful re-use will be felt in the near term as well
as the more distant future.
References
[I] Avionics applications software standard interface, ARINC Project
Paper 653, Draft 13, June 1995.
 A. Cook, K.J.R. Hunt/Microprocessors and Microsystems 20 (1997) 479-483 483

[2] Design guidelines for integrated modular avionics, ARINC Report

651, November 1991. Ken Hunt completed an MSc in Electronics System Design at Cran-
[3] Software considerations in airborne systemsand equipment certifi- field Institute of Technology in 1974, then took up a post at GEC’s
Central Research Laboratory at Wembley. During this time, he
cation, EUROCAE/RTCA DO-178B/ED12B, December 1992 i worked on commercial and military semiconductor- and phosphor-
based displays and infrared imaging systems. Moving to BAe
Dynamics in 1985, he took on responsibility for the electro-mechan-
Alan Cook graduated with a BSc (Eng) degree in Materials Science ical design and manufacturing of many of the companys defence
from Imperial College London in 1983. Having developed an interest products; latterly with responsibility for the EMC design, perfor-
in computing while at college. he decided to pursue a career in the mance and testing of avionic and shipborne equipments. During this
software industry, initially taking employment as a programmer with time, he worked on several modular avionic programmes, including
Ferranti Computer Systems Ltd in October 1983. He subsequently the Advanced Avionic Architecture and Packaging (A’P) study and
workedfor Plessey Avionics and GEC, his work areas were develop- chaired the ASSC (Avionic Systems Standardisation Committee)
ment of real-time systems and performance assessment models. He Packaging Working Group. Since transferring to the Airbus division in
joined British Aerospace Airbus in 1991 to work on the Control Tech- 1991, he has workedon avionic equipmentsfitted to aircraft rangingfrom
nology Programme, looking at the certt$cation and software aspects Concorde to the A330. Whilst in his present role as Manager, Systems
of integrated modular avionics. He has been a member of the ARINC Technology, he has been consortium manager for the Control Tech-
653 working group since 1993, and is currently secretary of EVRO- nology Programme Phase 2.
CAE WG48 (Avionics Computing Resource).