design of a middleware interface for arinc 429 data bus

Design of a Middleware

Interface for ARINC 429 Data

Bus

L. M. PARRILLA

A. L. RODRIGUEZ

A. SIMON-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. Rodríguez, and

M. M. Prats, Department of Electronic Engineering, University

of Seville, Spain, E-mail: ([email protected]); A.

Simon-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

systems–and therefore, the interconnections–grow

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. OMG’s

DDS (Object Management Group’s 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

OMG’s 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

manufacturer’s 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 EMPLOYEDIN THE DESIGN OF THE MIDDLEWAREINTERFACE

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.


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 MIDDLEWARECOMMUNICATION 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,


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 manufacturer’s

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


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

manufacturer’s 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


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


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


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


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 messageobject. Then this message is sent by the ARINC 429bus using the API functions. Next, the high-levelapplication can access the ARINC word detail sincethe 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 messagesreceived by the selected port. This data is representedon a needle gauge. Previously, the adaptation layer setthe correct transmission configuration, and also thedata format, i.e., label (in octal) and data payload.

B. Real-Time Transmission/Reception Tests

The flight director roll data is displayed in thistest. In this case, an aircraft display, a data table, and agraphical 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 visualfrequency. That means, roll data variation can beobserved in the aircraft display of Fig. 6. The roll datarange has been set between 0—35 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


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.


Hence, the developed layer simplifies and makesthe bus communication system more suitable andeasier to maintain. It also provides design flexibilityin distributed communication systems obtainingreusable and portable software interfaces. The lattercharacteristic is a required target of the proposedsoftware tool. Thus, the proposal application makeseach specific avionics application independentfrom the bus, from manufacturers’ hardwareand, finally, from the avionics data board model.In consequence, there is no need for hardwaremanufacturers’ proprietary communications softwarefor each embedded avionics card in the data bus.Furthermore, the unified communication layer allowsthe developed OO structure of our application to beeasily transferred to another platform or OS withminor changes.As a result, the improvements achieved with this

layer lead to a better knowledge of avionics interfacesand interconnection between avionics buses. Inaddition, it opens the way to thinking about makingbus-oriented applications as a means of reducingdesign and development time. To summarise, thiswork has been the starting point for testing avionicsdata bus management software tools with a viewto their being used in more sophisticated data busarchitectures such as ARINC 664/AFDX. Presently,the research group is working on the addition of newfunctions and requirements to the proposed adaptationlayer in order to make it compatible with the nextgeneration of avionic data buses. The goal is to obtainhardware and operating system independence in acomplex 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), 23—28.

[2] Gangl, E. C.

Evolution from analog to digital integration in aircraft

avionics–A time of transition.

IEEE Transactions on Aerospace and Electronic Systems,

42, 3 (July 2006), 1163—1170.

[3] Zhang, J. G., Pervez, A., and Sharma, A. B.

Avionics data buses: An overview.


(Feb. 2003), 18—22.

[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. 26—30, 2008.

[8] Alena, R. L., et al.

Communications for integrated modular avionics.

In Proceedings of the IEEE 2007 Aerospace Conference,

Mar. 2007, 1—18.

[9] Brajou, F. and Ricco, P.

The Airbus A380–an AFDX-based flight test computer

concept.

In Proceedings of AUTOTESTCON 2004, Sept. 20—23,

2004, 460—463.

[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), 897—912.

[11] Garside, R. and Pighetti, F.

Integrating modular avionics: A new role emerges.


(Mar. 2009), 31—34.

[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 (DASC’07), Oct. 21—25, 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. 25—29, 2009.

[14] Bernstein, P. A.

Middleware: A model for distributed system services.

Communications of the ACM, 39, 2 (Feb. 1996), 86—98.

[15] Schmidt, D. C.

Middleware for real-time and embedded systems.

Communications of the ACM, (June 2002), 43—48.

[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] Lopez, J., et al.

A middleware architecture for unmanned aircraft avionics.

Presented at the International Middleware Conference,

Newport Beach, CA, Nov. 26—30, 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, 1—2 (Dec. 15, 1994), 179—184.


[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

(SOC’2005), Grenoble, France, Oct. 2005, 219—224.

[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 Programmer’s 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.


Luis Miguel Parrilla Casquet was born in Seville, Spain in 1984. He receivedhis 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 Rodríguez-Vazquez has received his B.S. degree intelecommunication 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.

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

degree in telecommunications engineering from the Universitat Politecnica de

Cataluna 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 Universite 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.

María Angeles Martín Prats was born in Seville, Spain, in 1971. She receivedthe 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 2000—2009, 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.


design of a middleware interface for arinc 429 data bus

Documents

civil avionics data

civil avionics buses

data busprovides

pioneering bus

avionics hardwareboard

high speed data bus

important drawback of

strict data control