See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224087517

An integrated modular avionics development environment

Conference Paper · May 2009

DOI: 10.1109/DASC.2009.5347582 · Source: IEEE Xplore

CITATIONS READS

22 5,909

6 authors, including:

Tobias Schoofs Cássia Tatibana

PKNOA GMV Portugal
19 PUBLICATIONS 163 CITATIONS 10 PUBLICATIONS 88 CITATIONS

SEE PROFILE SEE PROFILE

Jose Marcos Anjos José Rufino

Instituto Tecnologico de Aeronautica FCUL - Faculdade de Ciências Universidade de Lisboa
2 PUBLICATIONS 40 CITATIONS 75 PUBLICATIONS 853 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Tobias Schoofs on 21 October 2014.

The user has requested enhancement of the downloaded file.

 AN INTEGRATED MODULAR AVIONICS DEVELOPMENT ENVIRONMENT

Tobias Schoofs1 , Sérgio Santos1 , Cássia Tatibana1 , José Anjos1 , José Rufino2 , and James Windsor3
1
Skysoft SA, Portugal, Av. D. João II, Lote 1.17.02, Torre Fernão Magalhães – 7o , 1998-025 Lisboa, Portugal – Email:
firstname.lastname@skysoft.pt
2
Faculdade de Ciências da Universidade de Lisboa (University of Lisbon), Campo Grande, 1749-016 Lisboa, Portugal –
Email: ruf@di.fc.ul.pt
3
ESA/ESTEC, Keplerlaan 1, 2200 AG Noordwijk, The Netherlands – Email: james.windsor@esa.int

ABSTRACT environment for on-board applications without needing

access to the final target platform.
The ARINC 653 standard has taken a leading role
within the aeronautical industry in the development of In this context, Skysoft Portugal, S.A., co-funded by ESA,
safety-critical systems based upon the Integrated Mod- developed AMOBA – the ARINC 653 simulator for Mod-
ular Avionics (IMA) concept. The related cost savings in ular On-Board Applications [6]. First field experiences
reduced integration, verification and validation effort has revealed that the AMOBA concept is feasible as a develop-
raised interest in the European space industry for devel- ment and simulation tool for the aviation and space indus-
oping a spacecraft IMA approach and for the definition of try. However, the use cases also revealed potential for im-
an ARINC 653-for-Space software framework. As part of provement. From requirements gathered during the prac-
this process, it is necessary to establish an effective way tical industry experience, AMOBA redesign and extension
to develop, test and analyse on-board applications with- resulted in an IMA Development Environment (IMADE)
out having access to the final IMA target platform for all that provides the ARINC 653 API, Time and Space Parti-
engineers. Target platforms are usually extremely expen- tioning (TSP) and hard real-time behaviour on Linux OS.
sive considering hardware and software prices as well as
training costs. This paper describes the architecture of
an Integrated Modular Avionics Development Environ-
ment (IMADE) based on the Linux Operating System and
the ARINC 653 simulator for Modular On-Board Appli-
cations that was developed by Skysoft Portugal, S.A. in
cooperation with ESA, 2007-2008.

Key words: IMA; TSP; ARINC 653; AMOBA; Develop-

ment Tools; Simulators.
2. ARINC 653 ARCHITECTURE

1. INTRODUCTION

ARINC 653 [1, 2] is a standard that specifies a program- ARINC 653 defines support for robust partitioning in on-
ming interface for an RTOS (Real-Time Operating Sys- board systems, such that one processing unit, usually
tem), and, in addition, establishes a particular method for called a module, is able to host one or more avionics
partitioning resources over time and memory. At the mo- applications and to execute them independently. This
ment this standard has been established as an important can be correctly achieved if the underlying system, often
foundation for the development of safety-critical systems called Module Operating System (MOS), provides sepa-
in the aviation industry. This fact, allied to several sim- ration of the avionics applications, usually for fault con-
ilarities between aviation and space applications, has at- tainment, such that a failure in one partitioned function
tracted ESA’s (European Space Agency) interest in the cannot cause a failure in another partitioned function. As
development of space on-board software [3, 4, 5]. consequence the partitioning approach eases verification,
validation and certification. The unit of partitioning is
ARINC 653 standard approach for space purposes shall called a partition. A partition is basically the same as
bring new ways and concepts that are yet to be explored a program in a single application environment: it com-
and improved. Tools are needed to help on this discover- prises data, code and its own context configuration at-
ing process, as well as providing a test and development tributes (see figure 1).
 3. RATIONALE FOR AN IMA DEVELOPMENT
ENVIRONMENT

For the development of embedded real-time systems, two

platforms are usually necessary: the target and the devel-
opment platform. The two platforms are very different
in terms of purpose, features and appearance. The target
platform is based on hardware that meets the physical re-
quirements of the environment, it is intended to operate
Figure 1: IMA Concept in, like size, weight or, for space applications, radiation
hardening. It typically contains an OS capable of provid-
ing predictable behaviour of embedded applications.

Partitioning separates applications in two dimensions: The development platform, often called the host, is typi-
space and time. Spatial separation means that the mem- cally a standard desktop PC with a general purpose oper-
ory of a partition is protected: No application can access ating system like Windows or Linux. The host is, hence,
memory out of the scope of its own partition. Tempo- different from the target, as it has another purpose; it has
ral separation means that only one application at a time not the same constraints, but it must provide a suitable
has access to system resources, including the processor. environment for the embedded application development.
Therefore only one application is executing at one point The host has no support for the target API and is not capa-
in time – there is no competition for system resources ble to provide hard real-time behaviour, at best soft-real
between partitioned applications. Processes within the time behaviour is available. And of course, time parti-
scope of a partition are scheduled by a priority-based pre- tioning is not implemented by a general purpose OS.
emptive scheduler with FIFO order for processes with the
same priority. This second level scheduler is invoked
whenever an execution window assigned to its partition
starts and the partition gains access to the processor. The
process scheduler is preempted by the first level partition
scheduler when the execution window terminates (see
figure 2).

Figure 3: Host and Target

On the other hand, the target platform is typically very

expensive. This is, in particular, true for the target OS.
Licenses are usually paid per user, making it quite costly
to setup a big development team. However, as embedded
applications and their complexity are increasing, more re-
sources must be invested on development and validation
Figure 2: IMA Time Partitioning in the future.

To answer this challenge, a sophisticated but inexpen-

sive IMA Development Environment is proposed that runs
ARINC 653 specifies services for partition management, on widely used and accessible general purpose operating
process management, time management, health monitor- systems, like Linux which was chosen as the most ap-
ing and inter-process communication; processes in differ- propriate solution. This development environment pro-
ent partitions communicate via queuing ports or sampling vides the ARINC 653 API with hard real-time behaviour
ports according to the nature of the data being transmit- on Linux and brings the development platform and the
ted; processes within a partition communicate via buffers, target platform together on one desktop. This environ-
blackboards, semaphores or events. Additionally, op- ment is not able to imitate the behaviour of the target
tional services are provided by part 2 of the ARINC 653 platform precisely. But it guarantees the same functional
specification, like file system services, shared memory behaviour with the same order of events and a timing be-
blocks and naming services [2]. haviour that is close to that of the target platform.
4. REQUIREMENTS FOR AN IMA DEVELOP- A number of (partly conflicting) improvements have been
MENT ENVIRONMENT requested by users in the projects. These demands have
been compiled into a list of key requirements for an ad-
vanced IMA Development Environment:
AMOBA is currently used and evaluated in three research
and development projects, two from aviation and one
from space context: 1. The IMADE shall provide API services in strict com-
pliance to ARINC 653;

• The DIANA project (http://www. (a) Part 1

dianaproject.com), funded through the Partition Management, Process Management,
Sixth Framework Programme by the European Time Management, Intra- and Inter-Partition
Commission, aims at the definition of an advanced Communication, Health Monitoring;
IMA platform, supporting partitioned Safety Critical (b) Part 2
Java applications and advanced interoperability, Logbook System, Multiple Module Schedules,
like safe re-configuration and OMG-confirm Data Service Access Points, Naming Services.
Distribution Services (DDS). The main purpose
of the IMADE is the simulation of a distributed 2. The IMADE shall integrate a test execution environ-
avionics system interconnecting modules, simulated ment on the development platform without the need
by AMOBA, with modules run by Windriver’s for additional hardware emulators or operating sys-
VxWorks 653 and Sysgo’s PikeOS. In the context tem simulators.
of the DIANA project, Aonix ported their Safety-
Critical Java Virtual Machine, Perc Pico, to the 3. The IMADE shall execute with acceptable hard real-
IMADE .
time behaviour such that:
(a) The order of events is identical to the target
• The JEOPARD project (http://www.jeopard.
platform;
org), funded through the Seventh Framework Pro-
gramme by the European Commission, aims at the (b) Execution times are predictable;
definition of a Java development and execution en- (c) Target platforms and simulator nodes can be
vironment for parallel real-time processing. The connected to each other, forming together a
IMADE is used to benchmark an avionics applica- distributed IMA system.
tion and to compare the results with those of a vari-
ant of this application, ported to the new JEOPARD 4. The IMADE shall use standard configuration files
platform. that can be tested and reused for the target platform
without any changes.
• The AIR II project (http://air.di.fc.ul.
pt/air-ii), funded by ESA, aims at the devel- 5. The IMADE shall provide means for simple execu-
opment of a space TSP OS in strict conformance to tion with no need for complex configuration tasks.
the ARINC 653 standard. The IMADE is used as de-
velopment tool for the demonstrator, a satellite on- 6. The IMADE shall provide a realistic development
board application, ported to ARINC 653 by Thales- tool chain such that:
Alenia Space-France (TAS - F). IMADE is used to (a) It can be used for training on IMA;
simulate the AIR system, before it is actually avail-
able. Additionally, the AIR APEX interface shares (b) The same configuration management can be
some of the components of the AMOBA simulator applied to the target platform and the simula-
[7]. tor.
7. The IMADE shall include graphical analysis tools ca-
Figure 4 illustrates the relation of the mentioned projects pable to detail user processes execution; in particular
to the IMADE. these tools shall show the time and reason for pro-
cess preemption.
8. The IMADE shall be significantly inexpensive when
compared to commercial RTOS.

In the following sections, we will refer to the require-

ments as RD1-8.

Figure 4: IMADE Context

5. ARCHITECTURE OF THE IMA DEVELOP- process by a POSIX thread. Each application is, hence,
MENT ENVIRONMENT linked into a single POSIX program.

To be able to control the different programs, each repre-

The following sections describe how the requirements senting one ARINC 653 partition, the MOS is hosted on an
have been addressed by the architecture of the IMADE. additional process, communicating with the partitions by
means of signals and shared memory. Figure 5 illustrates
this design:
5.1. POSIX -based Design

AMOBA was designed as a multi-platform application

based on POSIX. This way, a wide range of operating
systems, both real-time and general purpose OS, could
be addressed. However, the implementation was mainly
intended for RTOS and the system, exhaustively tested,
was RTEMS. The direct projection of the RTEMS im-
plementation to Linux led to performance problems such
that strong hardware requirements had to be imposed for
Linux. This approach did not fulfil requirement RD3 nd
RD5 in an appropriate way.

The new design addresses the needs of a general pur-

pose operating system, in particular Linux. AMOBA ap- Figure 5: Mapping APEX on POSIX
plications have got a small memory footprint and do not
consume more processor time than required by user pro-
cesses themselves. At the same time the AMOBA library
5.3. Hard Real-Time on Linux
provides soft real-time capability to applications on any
Linux system [6, 7, 8, 9]. It will be discussed later (sec-
tion 5.3) how hard real-time capability is provided by the The most challenging requirement is to provide hard real-
IMADE. time behaviour on the development host (RD3). This
cannot be achieved without support by the operating sys-
tem itself. In the Linux community, this issue is being
5.2. MOS and POS discussed for many years now [10, 11]. Various solu-
tions have been proposed leading to concepts in which
the Linux kernel is para-virtualised and hosted by an ad-
The ARINC 653 APEX defines two types of schedulable ditional RT-kernel. Well known projects following this
objects: processes and partitions. The difference is that paradigm are the commercial RT-Linux (see http://
a partition has got its own protected memory space as- www.rtlinuxfree.org), owned by Windriver, and
signed to it, whereas the process has not. the open source RTAI (http://www.rtai.org). The
main disadvantage of such solutions is that different APIs
In POSIX, as well, two types of schedulable objects are must be used within real-time applications. Whenever a
known: threads and processes. The difference, again, is real-time application calls the Linux kernel, it leaves the
that one, the POSIX process, has got protected memory real-time mode. This is acceptable for certain kinds of
space, whereas the other, the thread, has not. embedded applications. But it is not a good solution for a
development environment where the availability of stan-
The following table reflects this relation, using +M and dard APIs for debugging, analysis and extension of the
-M to indicate an object with and, respectively, without basic capabilities of the APEX are important features.
memory protection:
The main problem, achieving hard real-time behaviour on
Linux, is latency, defined as the time between the arrival
-M +M of an event and the execution of its response. As a general
APEX process partition purpose OS, Linux is designed to enhance the average re-
POSIX thread process sponse time, whereas real-time systems aim at enhancing
the worst case response time as this is the fundamental
Table 1: APEX and POSIX factor of impact on the system predictability.

Linux high latencies are a consequence of a non-

The clear distinction of schedulable objects in POSIX and preemptive kernel approach; the kernel contains large
APEX , based on the difference of having or not having protected sections, where it cannot be preempted by a
protected memory, leads to a mapping where an APEX user task. However, it is the user tasks, implementing
partition is represented by a POSIX process, and an APEX the response to an event.
To overcome this situation, Ingo Mólnar, one of the
authors of the NPTL [9], and Thomas Gleixner re-
worked the kernel code to reduce non-preemptible se-
quences to a minimum [12]. This code is available as
patch, called PREEMPT- RT (see http://rt.wiki.
kernel.org).

The latency that can be expected with the PREEMPT- RT

patch depends on the hardware and the settings of the
system. Main drivers for latency are hardware interrupts,
causing the kernel to become active and to enter the re-
maining non-preemptible sequences. Sources of inter-
rupts are, for instance, the network interface, the graphic
card, typically when running an X server, and service in-
terrupts coming from the board. This last kind of inter- Figure 6: IMADE Generation Tool Chain
rupts is worse with newer hardware and, especially, with
all kinds of portable computers.
Few assumptions are made on how the IMADE is inte-
After running tests, based on Thomas Gleixner’s grated in the development environment of a real project;
cyclictest (http://www.rt.wiki.org) on systems it is possible to reuse the configuration data of the original
with different hardware configurations for 24 – 48 hours target platform, by directly applying them to the IMADE
each, the following latencies, given in µs, can be consid- tools or by transforming them from a proprietary format
ered representative for various kinds of modern PC hard- to the standard ARINC 653 configuration scheme. Addi-
ware; + X and - X refer to systems with and, respectively, tional information, needed for the mapping of APEX to
without an X server running: POSIX is kept outside the standard configuration to avoid
the pollution of the project’s configuration data by IMADE
specific configuration data (RD4).
Best Case Average Worst Case
Desktop + X 1 7 54 For generating, applying and managing configuration
Desktop - X 1 7 17 data, the IMADE provides a set of graphical configuration
Laptop + X 1 18 62 tools. The tools assist the configuration engineer by vi-
Laptop - X 1 11 48 sualising ARINC 653 concepts like partition scheduling,
connection tables or health monitoring events. Figure 7
Table 2: PREEMPT- RT Benchmarks provides some examples:

Industry experience confirms that deadlines down to

100µs can be guaranteed even on a system that runs
graphical user interfaces (GUI).1 Without GUIs, even
shorter deadlines appear to be possible. For the purposes
of the IMADE such values are acceptable and even com-
parable with what can be achieved on the target hardware,
both for aviation and space.

5.4. Configuration and Generation Tool Chain

The IMADE uses common tools that are usually coming

with the GNU/Linux OS, like the GNU C and Ada com-
piler and linker. The configuration tables are read and Figure 7: IMADE Configuration Management Tools
dynamically interpreted by the MOS, but are applied of-
fline to the POS (RD6). For this purpose, additional tools
are provided like the makeports tool that transforms the
5.5. Analysis Tools
port definitions and the connection table in the ARINC
653 configuration file into C code. These communication
stubs must be compiled and linked with the partitioned To study the behaviour of an avionics application in de-
application as shown in figure 6: tail (RD7), the IMADE provides logging capabilities. For
this purpose, a variant of the execution environment is
1 Refer to the discussion forum archives on http://www. available that writes internal state information to a log
kernel.org file. The output is human readable but, in the first place,
 intended for a tool presenting the states of process exe- REFERENCES
cution in a graphical manner. This representation of the
process execution focuses on the time and reason of pro- [1] Airlines Electronic Engineering Committee (AEEC),
cess preemption. At the time of writing, this analysis tool ARINC Specification 653 Part 1 (Supplement 2), Re-
is still a prototype. Figure 8 gives an idea of how the quired Services, Aeronautical Radio Inc., 2006
representation of process states will look like: [2] Airlines Electronic Engineering Committee (AEEC),
ARINC Specification 653 Part 2 (Supplement 1), Ex-
tended Services, Aeronautical Radio Inc., 2008
[3] J-L. Terraillon, K. Hjortnaes, Technical Note on On-
board Software European Space Technology Harmon-
isation, Technical Dossier on Mapping, ESA, 2003.
[4] N. Diniz and J. Rufino. ARINC 653 in Space. In
Proceedings of the DASIA 2005 – DAta Systems
In Aerospace Conference, EUROSPACE, Edinburgh,
Scotland. June 2005.
[5] J. Rufino, S. Filipe, M. Coutinho, S. Santos and J.
Windsor. ARINC 653 Interface in RTEMS, In Proc. of
the DASIA 2007 – DAta Systems In Aerospace Con-
Figure 8: IMADE Analysis Tool ference, EUROSPACE, Naples, Italy. May/June 2007.
[6] E. Pascoal, J. Rufino, T. Schoofs and J.Windsor,
AMOBA - ARINC 653 Simulator for Modular Space
Based Applications. In Proc. of the DASIA 2008
– DAta Systems In Aerospace Conference, EU-
6. SUMMARY AND CONCLUSIONS ROSPACE, Palma de Mallorca, Spain. May 2008.
[7] S. Santos, J. Rufino, T. Schoofs and J.Windsor, A
Portable ARINC 653 APEX Interface. In Proc. of the
The IMA Development Environment, discussed through- 27th Digital Avionics Systems Conference (DASC), St.
out this paper, results from the AMOBA project. AMOBA Paul, MN, USA. October, 2008.
is an implementation of the ARINC 653 APEX running on
POSIX compliant RTOS and general purpose OS. It is used [8] Kevin M. Obenland. The Use of POSIX in Real-
as simulator and development tool in several research and time Systems, Assessing its Effectiveness and Perfor-
development projects in the space and aviation domain. mance. The MITRE Corporation. September 2000.
The needs of the users in these projects have been con- [9] U. Drepper, I. Mólnar, The Native POSIX Thread Li-
solidated into a set of requirements and addressed by re- brary for Linux, February 2006, http://people.
design and improvements of the execution environment redhat.com/drepper/nptl-design.pdf.
and its tool set. The result is a complete development en-
[10] K. Dankwardt, Comparing Real-Time
vironment that, together with the PREEMPT- RT patch, is
Linux Alternatives, October 2000, http:
able to provide hard real-time execution of avionics ap-
//www.linuxdevices.com/articles/
plications on Linux. The IMADE supports ARINC 653
AT4503827066.html.
compliant configuration and analysis tools to validate ap-
plications, based on their execution on the host. [11] J. Corbet, Approaches to Realtime Linux, October
2004, http://lwn.net/Articles/106010.
The IMADE can be used for many purposes; the main use [12] S. Rostedt, Internals of the RT Patch. In Proc. of the
case is a development tool to reduce the number of ex- 2007 Linux Symposion, June 2007, http://ols.
pensive target platforms or target emulators that must be 108.redhat.com/2007/Reprints.
purchased for development projects. Other purposes are
training, hosting of prototypes and simulation of IMA en-
vironments, in the context of research and development
projects, for instance.

There are several plans for improvements and extensions

in the near future. One is the development of a static code
analyser for the detection of race conditions and dead-
locks; another interesting path of development is the in-
tegration of a specific target emulator, capable to mimic
the behaviour of specific target systems. This emula-
tor would be configured using the results of real target
platform measurements and would execute applications
based on a virtual time, modelled after the measured tim-
ing behaviour of the target platform.

View publication stats