Design of a Middleware

Interface for ARINC 429 Data

Bus
L. M. PARRILLA
A. L. RODR

IGUEZ
A. SIM

ON-MUELA
M. M. PRATS, Member, IEEE
University of Seville
This work is focused on the design and development of
a middleware software layer which will enable real-time
communication among different embedded avionics modules
through an ARINC 429 bus. The implemented layer is based
on a C++ object-oriented (OO)-based structure and it has been
designed in accordance with middleware concepts. It makes each
specific avionics application independent from the bus, from the
manufacturers hardware and finally, from the avionics hardware
board model.
Manuscript received December 30, 2009; revised June 21 and
November 12, 2010; released for publication March 25, 2011.
IEEE Log No. T-AES/48/2/943808.
Refereeing of this contribution was handled by M. Efe.
Authors current addresses: L. M. Parrilla, A. L. Rodrguez, and
M. M. Prats, Department of Electronic Engineering, University
of Seville, Spain, E-mail: (luismiguelparcas@ieee.org); A.
Sim

on-Muela, CRISA-Astrium EADS, Spain.

0018-9251/12/$26.00 c 2012 IEEE
I. INTRODUCTION
Data buses are an important part of the global
aircraft design. Indeed, embedded avionics systems
require reliable, robust and accurate communications
among modules. For this purpose, the interconnection
of modules and strict data control are becoming of
the utmost importance. As an example, considerable
efforts in the optimisation of data management have
been made in civil avionics buses such as ARINC
429 or Avionics Full-Duplex Switched Ethernet
(AFDX).
Traditionally, federated data bus architectures,
where each system was independent (from
each other), were used in civil aircraft. In these
architectures, the modules had an individual
point-to-point communication connection. These
federated architectures became obsolete with the
advent of digital communication systems. By using
digital buses, the information can be more efficiently
shared among avionics modules [1]. As a result,
important design factors such as wire weight or
performance faults have been considerably decreased
thanks to digital communications.
The first fully-functional digital avionics data bus
was the MIL-STD-1553. This pioneering bus was
originally developed for the F-15 tactical fighter in
the early 1970s. Several years ago, in 1978, this initial
standard was upgraded by adding several features
associated with aerospace industry support and
cooperation [2]. From that moment, several military
data buses were developed, e.g. the MIL-STD-1773,
STANG 3910, or High Speed Data Bus (HSDB) [3].
As regards civil avionics data buses, the most
widespread protocol is the ARINC 429. This data bus
provides a reliable communication between avionics
embedded systems. Moreover, this protocol can
integrate information coming from different on-board
systems. In fact, the ARINC 429 features fulfill the
main requirements for a digital bus. In consequence,
this communication standard was first introduced
in the early 1980s by Airbus (A310) and Boeing
(B-757 and B-767) [4]. This bus is still being used in
most civil aircraft due to its simplicity and reliability.
However, an important drawback of ARINC 429 is
its low speed (12.5 kbit/s and 100 kbit/s maximum).
This disadvantage becomes important in new aircraft
designs for which high avionics data bus bandwidth
is an important objective. Furthermore, the weight of
the wire employed is another significant problem. This
weight becomes unacceptable when digital embedded
systemsand therefore, the interconnectionsgrow
rapidly. In order to improve the protocol speed up to
2 Mbit/s and to provide a bi-directional connection,
ARINC 629 was implemented on Boeing 777,
see [5], [6]. The protocol can be described as a
carrier sense multiple access/collision avoidance
(CSMA/CA).
1136 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
Another protocol is the so-called ARINC 664
(AFDX). This standard is a fast, redundant and
bi-directional bus architecture that overcomes most
of the limitations of traditional data buses. This
topology is flexible enough to fulfill several systems
requirements [7, 8]. Airbus has accepted this protocol
in their new aircraft designs [9].
Finally, the CAN data bus, widely used in the
automotive industry, can also be found in avionics
systems in order to allow the sharing of information
among aircraft fuel distribution systems [10].
In the last few years, new trends in avionics
architectures have tried to solve the aforementioned
problems. For instance, IMA (integrated modular
architecture) is an example of a more achievable
solution [11]. IMA involves a set of hardware,
middleware, and software resources. These resources
define safety and performance requirements to host
applications performing aircraft functions [12].
Following this trend and in order to achieve a good
combination of software and hardware in distributed
environments it is necessary to introduce a middle
layer called middleware.
For a general view of middleware refer to [14]
and [15]. In [15] an approach to technical challenges
and solutions is presented in order to create the
new generation of COTS (commercial-off-the-shelf)
technologies to meet the requirements of DRE
(distributed real-time embedded) systems. Many
research efforts are based on a publisher and
subscriber model which reduces complex network
programming for distributed applications. OMGs
DDS (Object Management Groups data distribution
systems) [16], CORBA (common object request
broker arquitecture) [17] and JMS (Java message
service) [18] are representative middleware products
that support this model. In [19] a real-time and
fault-tolerant middleware is presented, which is
also based on a publisher and subscriber model
for automotive software. Another work based on a
published and subscribed paradigm is introduced in
[20]. It consists of a DDS application on a CAN bus
protocol, integrating DDS QoS (quality of service)
parameters to improve data delivery and optimizing
network behavior. In [21], a middleware-based
architecture is presented for unmanned aircraft vehicle
(UAVs). It is also based in publish and subscribe
model and it manages low-cost mission definition and
execution.
It is worth mentioning other middlewares based
on publisher and subscriber model, open source
middleware like EPICS, OpenSplice DDS, and
OpenDDS. First, EPICS (experimental physics
and industrial control system) [22, 23] is a set
of software tools and applications that provides
software architecture to build distributed real-time
control systems in large-scale scientific projects,
i.e., particle accelerators, large experiments, and
major telescopes. In [24] an accelerator application
environment is developed and evaluated on top of
EPICS-DDS, an open source implementation of
the DDS standard interface based on the EPICS
channel access protocol. On the other hand, there are
commercial solutions for real-time publish/subscribe
middleware. Prismtech [25] has open source software
licensed under LGPL licensing called OpenSplice
DDS [26], compliant with the full profile specified
in the OMG DDS Specification v1.2 [27]. OpenSplice
is used as information backbone in TACTICOS CMS
(combat management systems). Finally, OpenDDS
[28] is an open-source C++ implementation of the
OMGs DDS, developed and copyrighted by Object
Computing Incorporated (OCI) [29]. It is built on
the ACE (adaptive communication environment)
[33] abstraction layer to provide platform portability.
OpenDDS is both a multi-language and multi-platform
implementation.
Current trends in middleware also deal with
RFID (radio frequency identification) technology.
An analysis of the requirements for RFID middleware
solutions are performed in [30], where a large amount
of data and RFID readers are taken into account. The
same authors proposed [31] an open source RFID
platform called Accada to develop applications that
address the requirement for passive RFID technology.
Industrial communication systems are quickly
changing from manufacturer-specific field bus systems
to open distributed control systems. In [32] the
authors present a service-oriented application for
a field bus integration architecture (SOAFBIA),
encapsulating a field bus system into a Web
component service for interoperability. Each entity
in the SOAFBIA supports a CORBA interface and the
message exchange in the system is supported by the
object request broker (ORB).
This paper completes the initial work presented
[13], where the preliminary concepts of a global
middleware software communication layer for ARINC
429 data bus were presented. Therefore the full design
process, adding additional features, is shown in this
new paper. Moreover, validation tests have been
completed to corroborate the correct communication
and data exchange among avionics modules.
Thus the main purpose of this work is the study,
design and implementation of a global middleware
software communication layer for ARINC 429 data
bus. This tool is conceived as an adaptation interface
for the ARINC 429 civil avionics bus, so the proposed
software tool offers a unified communication interface
for the ARINC 429 in global terms. As a result, this
layer controls the ARINC 429 communication and
manages the data transfer between some specific
avionics applications and the bus API (application
programming interface) platform. To the best of our
knowledge, there is no middleware design applied
to the ARINC 429 bus. This bus has been chosen as
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1137
the initial platform due to its simplicity and because
it is the most widely used avionic data bus. It is
worth noting that ARINC 429 is the industry standard
being used on virtually all commercial aircraft.
Moreover, this standard is an excellent starting point
for testing software tools applied to avionics data
bus management with regard to its use in more
sophisticated bus architectures such as the ARINC
664/AFDX.
The main contribution of the developed software
tool is to make each specific avionics application
independent from the bus, from the manufacturers
hardware, and finally, from the avionics hardware
board model. Therefore there is no need of any
ad-hoc proprietary communication software developed
by the hardware manufacturer for each embedded
avionics card in the data bus. This feature allows the
object-oriented-based (OO-based) structure of our
application to be easily transferred to another platform
or operating system (OS) with minor changes. As
a result, the proposed tool provides high design
flexibility in distributed communication systems, i.e.,
obtaining reusable and portable software interfaces.
This degree of freedom is achieved thanks to the
new implemented tool. Our approach is designed
to work with other middleware structures, since
it works with the low-level details of the ARINC
429 API board, thus providing independence of the
hardware from the avionics hardware board model.
In fact, the software tool presented in this paper uses
several ACE components [34]. The tools employed
are described in Section II. Another benefit of the
proposed adaptation layer is that it simplifies the bus
communication system, making it more suitable and
easier to maintain. The latter features lead to a better
knowledge of avionics interfaces and interconnection
among civil avionics buses, thereby opening the
way to new thinking about bus-oriented applications
as a means of reducing design and development
time.
Although the present work is designed for the
ARINC 429 data bus, the same principles can be
applied to other communication systems with the aim
of improving flexibility and interoperability among
manufacturers solutions. Research efforts in order
to build platform-independent applications and open
system architecture with the use of COTS are also
present in industrial communication systems, where
devices from different manufactures are connected to
become a large distributed control system.
This work has been structured in six parts. After
this prologue section, Section II presents the software
tools which have been employed to develop this
OO-based interface layer architecture. Section III
explains the architecture of the middleware layer
and the class-based objects involved in its design.
Section IV describes a typical execution sequence
performed in order to validate the middleware layer.
This sequence shows the typical behavior and the final
advantages of the new communication software layer,
presented in this work. Subsequently, Section V shows
some experimental tests which have been made in a
real ARINC 429 data exchange process. These tests
validate experimentally the developed communication
layer. The final conclusions are given in Section VI.
II. DESCRIPTION OF SOFTWARE TOOLS EMPLOYED
IN THE DESIGN OF THE MIDDLEWARE
INTERFACE
A. Middleware Services
The bus communication layer proposed in this
paper is a C++ OO-based middleware structure,
for which several commonly-used software design
patterns such as Abstract Factory, Factory Method,
and Singleton have been employed.
OO-based middleware layers provide reusable
service components. Moreover, they possess explicit
frameworks used as links among the final application
requirements, the OS low-level network protocol and
hardware designs.
Middleware services are particularly advised for
communication and data exchange among several
specific applications in distributed-architecture
platforms [14]. Each platform consists of some
low-level services and processing elements defined
by the processor architecture and the API of the OS.
Thus, the middleware service is defined by some
APIs and their supported protocols. Consequently,
middleware tools implement high-level services
making the OS calls, communication protocols, and
low-level programming details easier.
This kind of service simplifies and efficiently
manages the communication among network elements.
Therefore, more fluent communication among the
various platforms comprising the entire distributed
system is obtained. The latter middleware facility
is quite interesting in terms of portability. As
mentioned, portability is one of the key points of our
implemented software application in view of future
work and more complicated bus architectures such as
ARINC 664/AFDX.
The architecture of a typical middleware service is
illustrated in Fig. 1. Thus, middleware-based software
layers are placed between the OS and the high-level
application as its name indicates.
Compared to OSI (open systems interconnection)
models , middleware services work as top layers in
a classic OSI structure, i.e., application, presentation,
and session layers [33] (see Fig. 2). The middleware
approach defines a 7-layer structure. This structure
is standard for the interconnection architectures of
communication systems.
In this paper, a middleware service example has
been implemented. This service employs an ACE
library as described in the next section.
1138 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
Fig. 1. Architecture of typical middleware service.
Fig. 2. Middleware versus OSI models.
B. Adaptive Communication Environment
ACE is an open source OO-oriented framework
that implements core patterns for concurrent
communication software. ACE provides a rich set
of reusable C++ wrapper facades and framework
components to perform communication tasks through
OS platforms [34].
In practical terms ACE is recommended for
developers working in high-performance and real-time
communication applications. ACE tools simplify the
development of OO-based network applications and
services such as communication, event demultiplexing,
explicit dynamic linking, and concurrency.
Referring to the proposed communication layer,
specific software design patterns have been used.
These patterns are explained in the next sections.
C. Software Pattern Designs
The proposed middleware tool is composed of
several families of OO structures. These structures
have been programmed using C++ classes. The
design of these C++ classes is based on software
design patterns such as Singleton, Abstract Factory,
and Factory Method [35, 36]. Thanks to these
design patterns, specific work conditions such as
independence of hardware devices, portable designs,
and final safety applications are achieved.
The Singleton pattern assures that only one
object instance is performed during the execution of
the program. On the other hand, Abstract Factory,
combined with the Factory method pattern, allows the
separation of the object creation path from the object
itself. As a result the client application knows only
the interface to the object thanks to the superclasses.
Consequently, hardware independence is achieved,
since changes in the target board are transparent for
the high-level application.
III. DESIGN OF THE PROPOSED MIDDLEWARE
COMMUNICATION LAYER
A. General Description
The structure and interrelation of the C++ classes,
involving the implemented layer, can be observed in
Fig. 3. These classes are grouped in three families
such as the AR429 common elements (family A),
the Choose Factory class (family C, in white) and the
Factory Hierarchy (Family B, in grey). Each family
cooperates with the rest. This collaboration gives rise
to an entire hierarchy of dependent objects. Therefore,
the middleware structure works as an adaptation
stage between the specific ARINC 429 API and the
high-level application.
B. C++ Family Description
1) ARINC 429 Common Elements: The first
family, represented as family A, comprises the
common elements of the ARINC 429 bus protocol.
It defines a polymorphic structure and manages the
communication and configuration between the ARINC
429 bus and a Condor Engineering card, i.e., CEI-830
[37]. The main idea is to define several levels of
inheritance. The highest stages work as interfaces to
the final application. On the other hand, the lowest
levels are encharged with the real communication with
the specific API. This data transfer gives access to the
CEI-830 card resources.
The hierarchy presented in Fig. 3 starts with the
AR429 superclass. It links common transmission,
reception and configuration elements. Furthermore,
two other inherited classes such as AR429IO and
AR429Conf are derived from AR429 class. The first
class defines the common transmission and reception
methods and the second class is used as an interface
for card configurations.
2) Factory Hierarchy: The second family, denoted
in grey, is called Factory hierarchy. This family deals
with the creation of the aforementioned elements,
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1139
Fig. 3. C++ class families of implemented middleware layer.
i.e., transmission, reception, and configuration
objects. The Factory hierarchy is developed using the
Abstract Factory and Factory Method design patterns.
Therefore, a specific Factory object must be created.
This object generates the resources (objects) in order
to manage the communication of each card connected
to the bus. It should be pointed out that this hierarchy
creates the objects but it does not make use of them.
This last class is quite important since it separates the
object creation tasks from its own working mode.
Thus, it simplifies the Factory hierarchy design
and coordinates the resource instantiation. As a
consequence, an extra degree of flexibility is included
when a new ARINC 429 board is introduced.
3) ChooseFactory: The last class family, namely
ChooseFactory, differentiates the patterns described
before. This class, denoted in white, performs the
Factory object selection. Its main task is to select the
own Factory Object after receiving several parameters.
Thanks to this class, the selection of the Factory
related to an ARINC 429 board is more intuitive and
modular.
C. C++ Class Description
1) The ChooseFactory Class: This is the
first instantiated class in our software layer. It is
independent from the rest. Therefore, it has no
inherited relationship with any other class (see Fig. 3).
The main goal of this class is to choose a Factory
object according to some specific parameters. These
parameters are ARINC 429 card manufacturers
name and the ID board number. This last number
differentiates between cards of the same manufacturer.
According to the aforementioned parameters, a
specific Factory object is selected, i.e., a derived class
from the AR429Factory class. So the resulting Factory
object is exclusively associated with an ARINC 429
card.
2) The AR429Factory Class: This abstract class
is the superclass of the Factory hierarchy. It has
been developed using the Abstract Factory and
Factory Method design patterns. Thus it offers an
object builder interface. It coordinates the creation
of families of objects. Moreover, it defines how to
perform the object instantiation. This instantiation is
performed out of the client object which is using these
created objects. Moreover, the AR429Factory class
defines the interface for creating each member of the
required family of objects. Thus, the objects (assets)
for a specific ARINC 429 board are created by its
own intended Factory.
Several specific factories are inherited from
this class. Thus, each derived class is associated
with a given card. For example, the derived class,
called FactoryTarjeta, is created for the Condor
Engineering PCI CEI-830 card. If the user needs to
introduce other cards, a new FactoryTarjeta class is
created by keeping the same structure.
The high-level application does not know which
particular implementation of the configuration,
transmission, and reception object it is using. This
facility is achieved as it is the responsibility of the
Factory hierarchy to create them. Furthermore, the
high-level client does not know which particular
Factory implementation it is using since it has only
an abstract Factory class (AR429Factory) with pure
virtual C++ methods.
As a result, this kind of architecture simplifies,
hides implementations, and makes the system easier to
maintain. Therefore this last facility allows the reuse
of the code, which is an important advantage.
3) The FactoryTarjeta Class: This class is derived
from the AR429Factory class. The pure virtual
methods, used as interfaces in the abstract class
AR429Factory, are overridden in the derived classes.
Thus the FactoryTarjeta is in charge of creating
1140 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
new objects required for a proper working of the
communication through the ARINC 429 bus.
Therefore the created objects are associated
with the configuration, transmission, and reception
elements, which must be communicated with the card
API libraries. In consequence,, the FactoryTarjeta
object must be exclusive throughout the execution of
the application and linked to a particular ARINC 429
card. This is why the Singleton design pattern has
been employed to implement this class, for it assures
that the FactoryTarjeta class can be instantiated once.
Therefore, it possesses only one global access point.
4) The AR429Config Class: The abstract
AR429Config class implements the common
configuration methods, and works as a configuration
interface for each ARINC 429 card. Therefore, this
class contains configuration methods which define
the maximum number of transmission, reception, and
total ports. In addition the methods used to start and
to finish the bus communication, are also included in
this class.
In practical terms, this class is similar to the
AR429Factory class. Therefore, both classes are
abstract without attributes. Moreover, they possess
virtual methods which are defined in the abstract class
and are overridden in their derived classes.
5) The ConfTarjeta Class: This class implements
the final configuration interface with the physical
ARINC 429 card. Thus the aforementioned
configuration methods are overridden in this class,
which is derived from the abstract AR429Config
class which contains the ID board number and the
manufacturers code.
Using this design methodology, a specific card
calls its libraries. These card libraries are packaged
in common methods of the configuration class. This
working principle has several advantages. From the
foregoing, all the possible configuration methods
for the ARINC 429 card are centralised. Thus,
transmission and reception channel configurations
are always defined by the ConfTarjeta class. Next,
these communication parameters are verified before
the API call. This feature avoids consecutive calls
to the card configuration making the configuration
access to the card easier and more robust. Hence
the configuration object, called ConfTarjeta, is the
first object created by the FactoryTarjeta. This object
inherits the characteristics and configurations of the
intended card.
6) The AR429Tx and AR429Rx Classes: These
abstract classes are derived from the AR429IO.
They implement and normalize the transmission and
reception interface with the final client, so they are
used by the final avionics application to manage
transmission/reception resources.
7) The TxTarjeta and RxTarjeta Classes: The
objects of these classes are in charge of the data
transmission and reception through the ARINC 429
bus. For such tasks, these classes call on some API
functions which are required for the reading/writing
process. Each transmission and reception object must
be linked to an exclusive port by means of an attribute
called port number. In the transmission/reception
case, these elements must be exclusive. However,
the Singleton design pattern cannot be used. The
main problem is that these elements must be
dynamically generated according to the number
of ports. To solve the latter problem, the proposed
solution is to create these elements by means of
the FactoryTarjeta object. This object must keep
two lists (one for transmission and another for
reception) containing pointers-to-object to the
TxTarjeta or RxTarjeta classes. This kind of list is
an AC1E container named ACE UnboundedSet
which does not allow duplicated inputs. Moreover,
this structure grows dynamically as long as new
elements are added. Later, the objects are scanned
in order to check the port number. As a result, a
single transmission/reception object per port is
assured.
8) The AR429Message Class: The main objective
of this class is to process and implement the different
fields of the 32-bit ARINC 429 messages. This class
is built by linking two structures, i.e., a 4-block
structure of 8 bits and a 32 bits integer. In other
words, this structure is composed of blocks allowing
an easier access to the different message fields for
later processing. These fields have two access methods
such as set to establish their values and get to
obtain them. Moreover, it also includes a method for
checking and imposing the message parity.
This class offers significant advantages for
processing ARINC 429 messages. In transmission
mode, it simplifies the data handling before being
sent to the bus. Then the data is packaged in only one
message object. In reception mode, this class offers
some facilities to read each part of the ARINC 429
message and to act accordingly.
IV. MIDDLEWARE LAYER IMPLEMENTATION
A. Execution Sequence
The full execution sequence of the developed
C++ structure, i.e., configuration, transmission, and
reception tasks, is shown in Fig. 4. This sequence
validates a typical data exchange process using
the implemented software tool. Thanks to this
layer, bus communication is achieved through the
OO-based structure and the specific PCI CEI-830
API card. ARINC 429 API calls have not been
included in this example for reasons of complexity.
The diagram illustrated in Fig. 4 depicts the regular
execution of the software, excluding configuration and
transmission/reception errors.
The implemented tool starts with a main program
working as a high-level avionics application. This
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1141
Fig. 4. Execution sequence of middleware layer.
main code controls the execution sequence, initializes
the different tasks, and creates some objects. To
complete the communication with the API, this
high-level application only has to know the OO-based
interface composing the middleware class structure.
Therefore, the first step is to instantiate a
ChooseFactory object since it deals with the card
selection. Once the card has been selected, it creates
the Factory object (FactoryTarjeta). This last object is
instantiated at the beginning of the application to build
the main communication objects. Two parameters are
transferred to the Factory object, i.e., the ID board
number and the card manufacturer. The previous
object is implemented following the Singleton design
pattern, i.e., this object is unique at all times.
Once the Factory object is created, manufacturer
and ID board parameters are considered as object
attributes associated with the intended ARINC 429
board. At this point of the sequence, configuration,
transmission, and reception objects are instantiated
as soon as they are required. The creation of these
objects is a responsibility of the Factory object.
Next, the logical execution process is to set the
generic board and channel configuration before
transmitting or receiving any ARINC 429 data to/from
the bus. Subsequently, the main application asks the
Factory object to instantiate a single configuration
object working as a communication interface to set
the API configuration, i.e., the ConfTarjeta object.
As a result, the high-level application accesses the
board configuration by means of the ConfTarjeta class
methods.
This last step is quite important since the proposed
application can change the configuration using
exclusively the ConfTarjeta class methods and
attributes. In short, the complex C library of the API
is not necessary to complete the configuration process.
This last class is also created following the Singleton
pattern.
Consequently, there is only one object setting the
ARINC 429 configuration. As has been commented
on in the previous section, the Singleton pattern is
used to avoid several simultaneous configuration
orders and to assure a safe configuration process.
Thus, API configuration functions are called through
configuration object methods.
Transmission and reception objects are produced
by the Factory object in two steps. To begin with the
sequence, the first method has a list with the existing
transmission or reception objects linked to the board
ports. Following this first step, in which a list of the
created objects is maintained, the object is created by
means of the second method.
Once the configuration work is completed, the next
step is to transmit and receive ARINC 429 data using
the transmission and reception objects (TxTarjeta and
RxTarjeta). As has been previously mentioned, each
transmission and reception object is associated with
a single ARINC 429 board port. Thus, the TxTarjeta
and RxTarjeta objects do not follow the Singleton
pattern because they are instanced once. In fact, there
1142 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
Fig. 5. General scheme: Bus ARINC 429 connecting software layer and GSS application.
is only one TxTarjeta and RxTarjeta object per each
port available on the ARINC 429 board. The number
of transmission and reception ports is asked in the
previous configuration process.
Finally, the AR429Message class is called in
order to package the ARINC 429 word. Moreover,
this class separates the data into several fields. This
division makes the data exchange easier on both
sides of the communication since it includes data
processing methods. Thus, transmission objects use
the AR429Message class before sending any data
to the ARINC 429 bus. This message class provides
facilities to build the fields of the word. On the other
hand, the reception object keeps the data from the
bus in a message object. As expected, this data is
accessible for the high-level application without any
extra data processing.
V. VALIDATION AND SIMULATION RESULTS
Several simulation tests have been performed to
validate the developed software interface. These tests
show several examples of real-time communication
processes among avionics systems. Therefore they
validate the communication between an avionics
application, using the proposed OO-based software
interface, and other equipment connected to the
ARINC 429 bus. The real-time data is displayed by
using a software environment.
A scheme of the avionic ARINC 429 bus
connecting different PCs is depicted in Fig. 5. Each
PC has an ARINC 429 PCI board from Condor
Engineering. This proprietary board includes built-in
APIs. Obviously, every avionics board is connected
through the ARINC 429 bus.
The ARINC 429 data bus implemented for the
communication tests is equipped with six PCI CE-830
ARINC 429 boards from former Condor Engineering.
In order to perform hardware changes, the PCMCIA
CEI-715 [38] board also from Condor Engineering
is considered. The integration of the PCMCIA
board involves only initialization changes, which
have to be included in ConfTarjeta Class. Except
for board initialization issue, the basic ARINC 429
communication functionalities i.e., configuration,
transmission, and reception tasks share the same
API functions and parameters in both board models.
Therefore, API calls for board initialization are
included in the proposed adaptation layer to perform
hardware independence. This adaptation requires
changing very few lines of code, since both API
ARINC 429 functions are practically equivalent.
As well as in board model changes described
above, ARINC 429 board from different
manufacturers is also taken into account. The
APM429 PC-Card from AIM [39] is studied to
adapt the proposed middleware layer. In this case,
obviously API functions and parameters from both
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1143
Fig. 6. ARINC 429 data display.
ARINC 429 boards are different, but there are still
many similarities in the main features. For that
reason, few changes have to be considered. Hardware
adaptation is achieved only by adding the specific API
functions in the corresponding methods in charge
to make interface with the bus board. Thinking in
the proposed class model, the way to perform the
change, is to create twin classes of transmission,
reception, and configuration classes, with the same
structure, but changing the method of interface with
the API driver. The estimated percentage of code
lines for manufacturer adaptation is about 1% of
the whole code. In that manner the structure of the
middleware layer remains identical. So, only the code
lines corresponding to API calls have to be replaced.
However, portability is an important objective of
the work carried out. Therefore, intercommunication
between applications, running on different OS, is
included in the proposed system and depicted in Fig. 5.
The developed software tool is running on a
CPU on Debian GNU/linux (with Kernel 2.6.12.6).
The layer can send or receive ARINC 429 messages
to/from any PC connected by the ARINC 429 bus.
In order to display the data in a graphical manner, an
application called GSS (from Condor Engineering)
is used. GSS offers simulation and analysis tools for
systems integration, development, and test applications
with a graphical representation of multi-protocol bus
data. An example can be observed in Fig. 6.
The test performed consists of sending real-time
avionic data from an application running on our
adaptation layer. This data is sent to different
equipment as a flow stream. On the reception side,
the information has to be readable and displayable.
Therefore the analysis is divided into static and
dynamic transmission/reception tests. The static
analysis validates the capacity of the system to
exchange time-invariant data among several specific
applications in distributed-architecture platforms,
and then displaying it without changes. Dynamic
or real-time analysis measures the response against
real-time flight data variation. This test emulates a real
flight, where the system gathers real-time data from
the different systems located in the aircraft.
Before starting with the static and dynamic
analysis, the channel and equipment configuration is
described. ARINC 429 is a point-to-point protocol.
Therefore each bus board is connected to other cards
by an ARINC 429 channel or port. As a result, the
first task is the configuration of both extremes of
transmission and reception.
For the implemented C++ structure, the objective
is to deliver proper configuration parameters (channel
number, speed, and parity) to the configuration
object methods, (named ConfTarjeta methods).
These methods call the API functions to achieve the
suitable board configuration. Then, the GSS channel
window has to be filled according to the previous
1144 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
Fig. 7. Real-time roll data acquisition.
configuration. Once the configuration tasks have been
completed on both sides, the next step is to select the
desired data to be displayed in an understandable and
intuitive way.
It is worth mentioning that several graphical GSS
tools have been used to display the data received.
Roll, pitch, and yaw rates, from the flight control
computer, are the data selected to perform the tests.
This information is depicted in Fig. 6 using needle
gauges. These gauges show the current value of the
signal as a ratio percentage of the maximum value. As
a result, they provide an intuitive view of the signal
value.
A. Static Transmission/Reception Tests
The data proposed for the static analysis
correspond to the flight control computer roll, pitch,
and yaw rates. In this case study, the selection
of the label and payload in both communication
sides are essential. The label is a very important
part of the message since it identifies the type of
data and their associated parameters. Therefore the
middleware software layer is in charge of managing
the transmission process. On the other hand, it is the
GSS application which receives the data stream. In
transmission mode, the message class facilities have
been taken into account to provide flexibility and
modularity.
Thus, the data is represented in a message
object. Then this message is sent by the ARINC 429
bus using the API functions. Next, the high-level
application can access the ARINC word detail since
the message object, composing the ARINC 429 word,
is divided in several fields.
In the presented case, the GSS ARINC 429
monitor window displays the real-time messages
received by the selected port. This data is represented
on a needle gauge. Previously, the adaptation layer set
the correct transmission configuration, and also the
data format, i.e., label (in octal) and data payload.
B. Real-Time Transmission/Reception Tests
The flight director roll data is displayed in this
test. In this case, an aircraft display, a data table, and a
graphical chart were included on the GSS screen.
The issue is to create and transmit a diversity of
roll data. Therefore, this data is changing at a visual
frequency. That means, roll data variation can be
observed in the aircraft display of Fig. 6. The roll data
range has been set between 035 deg.
The data messages are sent in an incremental
linear way, linear roll increment being represented in
Fig. 7. This chart depicts the real-time data received
by the GSS application. The vertical axis of the
chart represents the roll data in degrees. On the other
hand, the horizontal axis depicts the time shown in
hours, minutes, and seconds. To complement this
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1145
Fig. 8. Received roll data table.
representation, Fig. 8 shows the received messages.
These message fields compose the transmitted roll
data of Fig. 7. For example, it can be observed
how the label field of the flight director roll data
corresponds to 140 in octal format. As was expected,
the value of this data is increased linearly.
In short, the represented charts validate the
communication process among the aircraft systems,
i.e., transmission and reception tasks following the
required parameters for the proposed communication
interface.
VI. CONCLUSION AND FUTURE WORK
Current avionics designs require efficient
bus communication and accurate data control
management. The optimization of these functions
is crucial in the case of civil avionics buses like the
ARINC 429 or the AFDX.
This paper introduces a global software
communication tool for ARINC 429 data bus.
Therefore the work is focused on the ARINC 429
aeronautic bus interconnections and communication
fields, so its main purpose is the study, design, and
implementation of a middleware software layer in
order to obtain real-time communication. This data
exchange is performed among different embedded
avionics modules connected through an ARINC
429 bus. This software tool works as an adaptation
interface which controls the transmission and
reception modes. Thus the data is properly shared
among some specific avionics hardware applications
and the bus API platform.
The implemented layer is based on a C++
OO-based structure, for which purpose several
common design patterns like Abstract Factory, Factory
Method, and Singleton have been used.
1146 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
Hence, the developed layer simplifies and makes
the bus communication system more suitable and
easier to maintain. It also provides design flexibility
in distributed communication systems obtaining
reusable and portable software interfaces. The latter
characteristic is a required target of the proposed
software tool. Thus, the proposal application makes
each specific avionics application independent
from the bus, from manufacturers hardware
and, finally, from the avionics data board model.
In consequence, there is no need for hardware
manufacturers proprietary communications software
for each embedded avionics card in the data bus.
Furthermore, the unified communication layer allows
the developed OO structure of our application to be
easily transferred to another platform or OS with
minor changes.
As a result, the improvements achieved with this
layer lead to a better knowledge of avionics interfaces
and interconnection between avionics buses. In
addition, it opens the way to thinking about making
bus-oriented applications as a means of reducing
design and development time. To summarise, this
work has been the starting point for testing avionics
data bus management software tools with a view
to their being used in more sophisticated data bus
architectures such as ARINC 664/AFDX. Presently,
the research group is working on the addition of new
functions and requirements to the proposed adaptation
layer in order to make it compatible with the next
generation of avionic data buses. The goal is to obtain
hardware and operating system independence in a
complex scenario such as the ARINC 664/AFDX.
REFERENCES
[1] Schroer, R. B.
Flight control goes digital (Part Two, NASA at 50).
IEEE Aerospace and Electronic Systems Magazine, 23, 10
(Oct. 2008), 2328.
[2] Gangl, E. C.
Evolution from analog to digital integration in aircraft
avionicsA time of transition.
IEEE Transactions on Aerospace and Electronic Systems,
42, 3 (July 2006), 11631170.
[3] Zhang, J. G., Pervez, A., and Sharma, A. B.
Avionics data buses: An overview.
IEEE Aerospace and Electronic Systems Magazine, 18, 2
(Feb. 2003), 1822.
[4] Spitzer, C. R.
The Avionics Handbook.
ISBN 0-8493-8348-X.
[5] Airlines Electronic Engineering Committee
ARINC Specification 629-3: IMA Multitransmitter
Databus, 1994.
[6] Berger, S. J.
ARINC 629 digital communication system application on
the 777 and beyond.
In Proceedings of ERA Avionics Conference and Exhibition,
1995.
[7] Schuster, T. and Verma, D.
Networking concepts comparison for avionics
architecture.
Presented at the IEEE/AIAA 27th Digital Avionics
Systems Conference 2008 (DASC08), Oct. 2630, 2008.
[8] Alena, R. L., et al.
Communications for integrated modular avionics.
In Proceedings of the IEEE 2007 Aerospace Conference,
Mar. 2007, 118.
[9] Brajou, F. and Ricco, P.
The Airbus A380an AFDX-based flight test computer
concept.
In Proceedings of AUTOTESTCON 2004, Sept. 2023,
2004, 460463.
[10] Giron-Sierra, J. M., et al.
CAN bus-based distributed fuel system with smart
components.
IEEE Transactions on Aerospace and Electronic Systems,
44, 3 (July 2008), 897912.
[11] Garside, R. and Pighetti, F.
Integrating modular avionics: A new role emerges.
IEEE Aerospace and Electronic Systems Magazine, 24, 3
(Mar. 2009), 3134.
[12] Watkins, C. B. and Walter, R.
Transitioning from federated avionics architectures to
integrated modular avionics.
Presented at the IEEE/AIAA 26th Digital Avionics
Systems Conference 2007 (DASC07), Oct. 2125, 2007.
[13] Parrilla, L. M., et al.
Design and performance of an adaptation middleware
interface for a civil avionic bus.
Presented at the 28th Digital Avionic System Conference,
Oct. 2529, 2009.
[14] Bernstein, P. A.
Middleware: A model for distributed system services.
Communications of the ACM, 39, 2 (Feb. 1996), 8698.
[15] Schmidt, D. C.
Middleware for real-time and embedded systems.
Communications of the ACM, (June 2002), 4348.
[16] Data Distribution Service for Real-Time Systems
Specification
Object Management Group, Dec. 2004.
[17] Yang, Z. and Duddy, Y.
CORBA: A platform for distributed object computing (a
state-of-the-art report on OMG/CORBA).
ACM Operating System Review, 30, 2 (Apr. 1996).
[18] Java Message Service
Sun Microsystems, Apr. 2002.
[19] Park, J., et al.
Designing real-time and fault-tolerant middleware for
automotive software.
Presented at the SICE-ICASE International Joint
Conference, 2006.
[20] Rekik, R. and Hasnaoui, S.
Application of a CAN BUS transport for DDS
middleware.
Presented at the International Conference on Application
of Digital Information and Web Technologies (ICADIWT
09), 2009.
[21] L

opez, J., et al.

A middleware architecture for unmanned aircraft avionics.
Presented at the International Middleware Conference,
Newport Beach, CA, Nov. 2630, 2007, ISBN
978-1-59593-935-7.
[22] Argonne National Laboratory
Experimental Physics and Industrial Control System.
Available at: http://www.aps.anl.gov/epics.
[23] Dalesio, L. R., et al.
The experimental physics and industrial control system
architecture: Past, present, and future.
Nuclear Instruments and Methods in Physics Research
Section A: Accelerators, Spectrometers, Detectors and
Associated Equipment, 352, 12 (Dec. 15, 1994), 179184.
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1147
[24] Malitsky, N., et al.
Prototype of a DDS-based high-level accelerator
application environment.
In Proceedings of ICALEPCS 2009, Kobe, Japan, 2009.
[25] Prismtech
http://www.prismtech.com.
[26] http://www.opensplice.com.
[27] http://www.omg.org/spec/DDS/1.2.
[28] http://www.opendds.org.
[29] http://www.ociweb.com/.
[30] Floerkemeir, C. and Lampe, M.
RFID middleware design-addressing application
requirements and RFID constraints.
In Proceedings of the Smart Objects Conference
(SOC2005), Grenoble, France, Oct. 2005, 219224.
[31] Floerkemeier, C., Roduner, C., and Lampe, M.
RFID application development with the Accada platform.
IEEE Systems Journal, 1, 2 (Dec. 2007).
[32] Tian, X., et al.
Service oriented application (SOA) for integration of field
bus systems.
In Proceedings of IEEE GLOBECOM 2007.
[33] International Organization for Standardization
Available at: www.iso.org.
[34] Huston, S. D., Johnson, J., and Syyid, U.
The Ace Programmers Guide: Practical Design Patterns
for Network and Systems Programming.
Reading, MA: Addison Wesley, 2003.
[35] Helm, R. and Johnson, J.
Design Patterns: Elements of Reusable Object-Oriented
Software.
Reading, MA: Addison Wesley, 1995, ISBN
0-201-63361-2.
[36] Shalloway, A. and Trott, J.
Design Patterns Explained: A New Perspective on
Object-Oriented Design.
Reading, MA: Addison Wesley, 2001, ISBN 0201715945.
[37] PCI CEI-830 datasheet
Available at: http://www.condoreng.com.
[38] PCMCIA CEI-715 datasheet
Available at: http://www.ge-ip.com/.
[39] ARINC 429 Test & Simulation Module for PC-Card
Available at: http://www.aim-online.com.
1148 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
Luis Miguel Parrilla Casquet was born in Seville, Spain in 1984. He received
his M.S. degree in telecomunication engineering from the University of Seville in
2009.
Since February 2008 he has worked as a full time researcher at the
Department of Electronic Engineering of the University of Seville, where since
February 2011, he is an assistant professor. His research interests are in the field
of avionics and digital systems for aeronautics applications.
D. Antonio Leopoldo Rodrguez-V

azquez has received his B.S. degree in

telecommunication engineering and his M.S. degree in electronics, signal
processing, and telecommunications from the University of Seville, Spain. He
started his Ph.D. studies in 2009.
He has been working in the Group of Electronic Technology in the
Department of Electronic Engineering, University of Seville, since 2006.
He has served as the chair of the IEEE student branch of Seville for 4 years,
and currently is secretary of the AESS Spanish Chapter.
Ad

an Sim

on-Muela was born in Tarragona, Spain in 1979. He received his B.S.

degree in telecommunications engineering from the Universitat Polit

ecnica de
Catalu

na in 2002 and the M.S. degree in automatics and industrial electronics

from the Universitat Rovira i Virgili in 2005. He also received the M.S. degree
in electrical engineering from the Institute National Polytechnique of Toulouse in
2005 and the Ph.D. degree from the Universit

e of Toulouse and the LAAS/CNRS

in 2008.
After collaborating with the Technology Group of the University of Sevilla,
he is currently working as power electronics and control systems designer for
aerospace applications in CRISA-Astrium EADS. His research interests are in
the field of embedded power electronics and digital control systems for aerospace
applications.
Mara

Angeles Martn Prats was born in Seville, Spain, in 1971. She received
the Licenciado and Doctor degrees from the University of Seville, Spain, in 1996
and 2003, respectively, both in physics.
In 1996, she joined the Spanish INTA (Aerospatial Technical National
Institute), where she was with the Renewable Energy Department. In 1998,
she joined the Department of Electrical Engineering, University of Huelva,
Spain. During 20002009, she was an assistant professor with the Electronic
Engineering Department, University of Seville, where since 2009, she is an
associate professor in the same department. Her research interest focuses on
avionics and power converters and fuel-cell power conditioner systems. She is
involved in industrial application for the design and development of electronics
systems applied to renewable energy, aeronautics, and aerospace technologies.
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS 1149