I. INTRODUCTION
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. Simo´ n-Muela, CRISA-Astrium EADS, Spain.
c 2012 IEEE 0018-9251/12/$26.00 ° 1136
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).
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. 1138
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.
IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 48, NO. 2 APRIL 2012
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. Fig. 1. Architecture of typical middleware service.
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
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
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 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. 1140
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
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 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
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 1142
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
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. 1144
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
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.
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.
A. Static 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 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
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.
B. Real-Time Transmission/Reception Tests
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. 1146
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.
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.
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17] REFERENCES [1]
[2]
[3]
[4]
[5]
[6]
[7]
Schroer, R. B. Flight control goes digital (Part Two, NASA at 50). IEEE Aerospace and Electronic Systems Magazine, 23, 10 (Oct. 2008), 23—28. 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. Zhang, J. G., Pervez, A., and Sharma, A. B. Avionics data buses: An overview. IEEE Aerospace and Electronic Systems Magazine, 18, 2 (Feb. 2003), 18—22. Spitzer, C. R. The Avionics Handbook. ISBN 0-8493-8348-X. Airlines Electronic Engineering Committee ARINC Specification 629-3: IMA Multitransmitter Databus, 1994. Berger, S. J. ARINC 629 digital communication system application on the 777 and beyond. In Proceedings of ERA Avionics Conference and Exhibition, 1995. 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.
[18] [19]
[20]
[21]
[22]
[23]
Alena, R. L., et al. Communications for integrated modular avionics. In Proceedings of the IEEE 2007 Aerospace Conference, Mar. 2007, 1—18. 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. 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. Garside, R. and Pighetti, F. Integrating modular avionics: A new role emerges. IEEE Aerospace and Electronic Systems Magazine, 24, 3 (Mar. 2009), 31—34. 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. 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. Bernstein, P. A. Middleware: A model for distributed system services. Communications of the ACM, 39, 2 (Feb. 1996), 86—98. Schmidt, D. C. Middleware for real-time and embedded systems. Communications of the ACM, (June 2002), 43—48. Data Distribution Service for Real-Time Systems Specification Object Management Group, Dec. 2004. 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). Java Message Service Sun Microsystems, Apr. 2002. Park, J., et al. Designing real-time and fault-tolerant middleware for automotive software. Presented at the SICE-ICASE International Joint Conference, 2006. 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. Lo´ pez, 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. Argonne National Laboratory Experimental Physics and Industrial Control System. Available at: http://www.aps.anl.gov/epics. 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.
PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS
1147
[24]
[25] [26] [27] [28] [29] [30]
[31]
[32]
1148
Malitsky, N., et al. Prototype of a DDS-based high-level accelerator application environment. In Proceedings of ICALEPCS 2009, Kobe, Japan, 2009. Prismtech http://www.prismtech.com. http://www.opensplice.com. http://www.omg.org/spec/DDS/1.2. http://www.opendds.org. http://www.ociweb.com/. 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. Floerkemeier, C., Roduner, C., and Lampe, M. RFID application development with the Accada platform. IEEE Systems Journal, 1, 2 (Dec. 2007). Tian, X., et al. Service oriented application (SOA) for integration of field bus systems. In Proceedings of IEEE GLOBECOM 2007.
[33] [34]
[35]
[36]
[37] [38] [39]
International Organization for Standardization Available at: www.iso.org. 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. Helm, R. and Johnson, J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995, ISBN 0-201-63361-2. Shalloway, A. and Trott, J. Design Patterns Explained: A New Perspective on Object-Oriented Design. Reading, MA: Addison Wesley, 2001, ISBN 0201715945. PCI CEI-830 datasheet Available at: http://www.condoreng.com. PCMCIA CEI-715 datasheet Available at: http://www.ge-ip.com/. ARINC 429 Test & Simulation Module for PC-Card Available at: http://www.aim-online.com.
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 Rodríguez-Va´ zquez 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.
Ada´ n Simo´ n-Muela was born in Tarragona, Spain in 1979. He received his B.S. degree in telecommunications engineering from the Universitat Polite´ cnica de Catalun˜ a 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 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 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. PARRILLA, ET AL.: DESIGN OF A MIDDLEWARE INTERFACE FOR ARINC 429 DATA BUS
1149
