an integrated modular avionics development

AN INTEGRATED MODULAR AVIONICS DEVELOPMENT ENVIRONMENT Tobias Schoofs1 , Sérgio Santos1 , Cássia Tatibana1 , José Anjos1 , José Rufino2 , and James Windsor3 1

Skysoft SA, Portugal, Av. D. João II, Lote 1.17.02, Torre Fernão Magalhães – 7o , 1998-025 Lisboa, Portugal – Email: [email protected] 2 Faculdade de Ciências da Universidade de Lisboa (University of Lisbon), Campo Grande, 1749-016 Lisboa, Portugal – Email: [email protected] 3 ESA/ESTEC, Keplerlaan 1, 2200 AG Noordwijk, The Netherlands – Email: [email protected]

ABSTRACT The ARINC 653 standard has taken a leading role within the aeronautical industry in the development of safety-critical systems based upon the Integrated Modular Avionics (IMA) concept. The related cost savings in reduced integration, verification and validation effort has raised interest in the European space industry for developing a spacecraft IMA approach and for the definition of an ARINC 653-for-Space software framework. As part of this process, it is necessary to establish an effective way to develop, test and analyse on-board applications without having access to the final IMA target platform for all engineers. Target platforms are usually extremely expensive considering hardware and software prices as well as training costs. This paper describes the architecture of an Integrated Modular Avionics Development Environment (IMADE) based on the Linux Operating System and the ARINC 653 simulator for Modular On-Board Applications that was developed by Skysoft Portugal, S.A. in cooperation with ESA, 2007-2008. Key words: IMA; TSP; ARINC 653; AMOBA; Development Tools; Simulators.

1.

environment for on-board applications without needing access to the final target platform.

In this context, Skysoft Portugal, S.A., co-funded by ESA, developed AMOBA – the ARINC 653 simulator for Modular On-Board Applications [6]. First field experiences revealed that the AMOBA concept is feasible as a development and simulation tool for the aviation and space industry. However, the use cases also revealed potential for improvement. From requirements gathered during the practical industry experience, AMOBA redesign and extension resulted in an IMA Development Environment (IMADE) that provides the ARINC 653 API, Time and Space Partitioning (TSP) and hard real-time behaviour on Linux OS.

2.

ARINC 653 ARCHITECTURE

INTRODUCTION

653 [1, 2] is a standard that specifies a programming interface for an RTOS (Real-Time Operating System), and, in addition, establishes a particular method for partitioning resources over time and memory. At the moment this standard has been established as an important foundation for the development of safety-critical systems in the aviation industry. This fact, allied to several similarities between aviation and space applications, has attracted ESA’s (European Space Agency) interest in the development of space on-board software [3, 4, 5]. ARINC

ARINC 653 standard approach for space purposes shall bring new ways and concepts that are yet to be explored and improved. Tools are needed to help on this discovering process, as well as providing a test and development

ARINC 653 defines support for robust partitioning in onboard systems, such that one processing unit, usually called a module, is able to host one or more avionics applications and to execute them independently. This can be correctly achieved if the underlying system, often called Module Operating System (MOS), provides separation of the avionics applications, usually for fault containment, such that a failure in one partitioned function cannot cause a failure in another partitioned function. As consequence the partitioning approach eases verification, validation and certification. The unit of partitioning is called a partition. A partition is basically the same as a program in a single application environment: it comprises data, code and its own context configuration attributes (see figure 1).

3.

Figure 1: IMA Concept

Partitioning separates applications in two dimensions: space and time. Spatial separation means that the memory of a partition is protected: No application can access memory out of the scope of its own partition. Temporal separation means that only one application at a time has access to system resources, including the processor. Therefore only one application is executing at one point in time – there is no competition for system resources between partitioned applications. Processes within the scope of a partition are scheduled by a priority-based preemptive scheduler with FIFO order for processes with the same priority. This second level scheduler is invoked whenever an execution window assigned to its partition starts and the partition gains access to the processor. The process scheduler is preempted by the first level partition scheduler when the execution window terminates (see figure 2).

RATIONALE FOR AN IMA DEVELOPMENT ENVIRONMENT

For the development of embedded real-time systems, two platforms are usually necessary: the target and the development platform. The two platforms are very different in terms of purpose, features and appearance. The target platform is based on hardware that meets the physical requirements of the environment, it is intended to operate in, like size, weight or, for space applications, radiation hardening. It typically contains an OS capable of providing predictable behaviour of embedded applications. The development platform, often called the host, is typically a standard desktop PC with a general purpose operating system like Windows or Linux. The host is, hence, different from the target, as it has another purpose; it has not the same constraints, but it must provide a suitable environment for the embedded application development. The host has no support for the target API and is not capable to provide hard real-time behaviour, at best soft-real time behaviour is available. And of course, time partitioning is not implemented by a general purpose OS.

Figure 3: Host and Target

Figure 2: IMA Time Partitioning

On the other hand, the target platform is typically very expensive. This is, in particular, true for the target OS. Licenses are usually paid per user, making it quite costly to setup a big development team. However, as embedded applications and their complexity are increasing, more resources must be invested on development and validation in the future.

ARINC 653 specifies services for partition management, process management, time management, health monitoring and inter-process communication; processes in different partitions communicate via queuing ports or sampling ports according to the nature of the data being transmitted; processes within a partition communicate via buffers, blackboards, semaphores or events. Additionally, optional services are provided by part 2 of the ARINC 653 specification, like file system services, shared memory blocks and naming services [2].

To answer this challenge, a sophisticated but inexpensive IMA Development Environment is proposed that runs on widely used and accessible general purpose operating systems, like Linux which was chosen as the most appropriate solution. This development environment provides the ARINC 653 API with hard real-time behaviour on Linux and brings the development platform and the target platform together on one desktop. This environment is not able to imitate the behaviour of the target platform precisely. But it guarantees the same functional behaviour with the same order of events and a timing behaviour that is close to that of the target platform.

4.

REQUIREMENTS FOR AN IMA DEVELOPMENT ENVIRONMENT

AMOBA is currently used and evaluated in three research and development projects, two from aviation and one from space context:

• The DIANA project (http://www. dianaproject.com), funded through the Sixth Framework Programme by the European Commission, aims at the definition of an advanced IMA platform, supporting partitioned Safety Critical Java applications and advanced interoperability, like safe re-configuration and OMG-confirm Data Distribution Services (DDS). The main purpose of the IMADE is the simulation of a distributed avionics system interconnecting modules, simulated by AMOBA, with modules run by Windriver’s VxWorks 653 and Sysgo’s PikeOS. In the context of the DIANA project, Aonix ported their SafetyCritical Java Virtual Machine, Perc Pico, to the IMADE . • The JEOPARD project (http://www.jeopard. org), funded through the Seventh Framework Programme by the European Commission, aims at the definition of a Java development and execution environment for parallel real-time processing. The IMADE is used to benchmark an avionics application and to compare the results with those of a variant of this application, ported to the new JEOPARD platform. • The AIR II project (http://air.di.fc.ul. pt/air-ii), funded by ESA, aims at the development of a space TSP OS in strict conformance to the ARINC 653 standard. The IMADE is used as development tool for the demonstrator, a satellite onboard application, ported to ARINC 653 by ThalesAlenia Space-France (TAS - F). IMADE is used to simulate the AIR system, before it is actually available. Additionally, the AIR APEX interface shares some of the components of the AMOBA simulator [7]. Figure 4 illustrates the relation of the mentioned projects to the IMADE.

A number of (partly conflicting) improvements have been requested by users in the projects. These demands have been compiled into a list of key requirements for an advanced IMA Development Environment: 1. The IMADE shall provide API services in strict compliance to ARINC 653; (a) Part 1 Partition Management, Process Management, Time Management, Intra- and Inter-Partition Communication, Health Monitoring; (b) Part 2 Logbook System, Multiple Module Schedules, Service Access Points, Naming Services. 2. The IMADE shall integrate a test execution environment on the development platform without the need for additional hardware emulators or operating system simulators. 3. The IMADE shall execute with acceptable hard realtime behaviour such that: (a) The order of events is identical to the target platform; (b) Execution times are predictable; (c) Target platforms and simulator nodes can be connected to each other, forming together a distributed IMA system. 4. The IMADE shall use standard configuration files that can be tested and reused for the target platform without any changes. 5. The IMADE shall provide means for simple execution with no need for complex configuration tasks. 6. The IMADE shall provide a realistic development tool chain such that: (a) It can be used for training on IMA; (b) The same configuration management can be applied to the target platform and the simulator. 7. The IMADE shall include graphical analysis tools capable to detail user processes execution; in particular these tools shall show the time and reason for process preemption. 8. The IMADE shall be significantly inexpensive when compared to commercial RTOS. In the following sections, we will refer to the requirements as RD1-8.

Figure 4: IMADE Context

5.

ARCHITECTURE OF THE IMA DEVELOPMENT ENVIRONMENT

The following sections describe how the requirements have been addressed by the architecture of the IMADE.

5.1.

POSIX -based

process by a POSIX thread. Each application is, hence, linked into a single POSIX program. To be able to control the different programs, each representing one ARINC 653 partition, the MOS is hosted on an additional process, communicating with the partitions by means of signals and shared memory. Figure 5 illustrates this design:

Design

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

The new design addresses the needs of a general purpose operating system, in particular Linux. AMOBA applications have got a small memory footprint and do not consume more processor time than required by user processes themselves. At the same time the AMOBA library provides soft real-time capability to applications on any Linux system [6, 7, 8, 9]. It will be discussed later (section 5.3) how hard real-time capability is provided by the IMADE.

5.2.

MOS

and POS

The ARINC 653 APEX defines two types of schedulable objects: processes and partitions. The difference is that a partition has got its own protected memory space assigned to it, whereas the process has not. In POSIX, as well, two types of schedulable objects are known: threads and processes. The difference, again, is that one, the POSIX process, has got protected memory space, whereas the other, the thread, has not. The following table reflects this relation, using +M and -M to indicate an object with and, respectively, without memory protection:

Figure 5: Mapping APEX on POSIX

5.3.

Hard Real-Time on Linux

The most challenging requirement is to provide hard realtime behaviour on the development host (RD3). This cannot be achieved without support by the operating system itself. In the Linux community, this issue is being discussed for many years now [10, 11]. Various solutions have been proposed leading to concepts in which the Linux kernel is para-virtualised and hosted by an additional RT-kernel. Well known projects following this paradigm are the commercial RT-Linux (see http:// www.rtlinuxfree.org), owned by Windriver, and the open source RTAI (http://www.rtai.org). The main disadvantage of such solutions is that different APIs must be used within real-time applications. Whenever a real-time application calls the Linux kernel, it leaves the real-time mode. This is acceptable for certain kinds of embedded applications. But it is not a good solution for a development environment where the availability of standard APIs for debugging, analysis and extension of the basic capabilities of the APEX are important features.

Table 1: APEX and POSIX

The main problem, achieving hard real-time behaviour on Linux, is latency, defined as the time between the arrival of an event and the execution of its response. As a general purpose OS, Linux is designed to enhance the average response time, whereas real-time systems aim at enhancing the worst case response time as this is the fundamental factor of impact on the system predictability.

The clear distinction of schedulable objects in POSIX and APEX , based on the difference of having or not having protected memory, leads to a mapping where an APEX partition is represented by a POSIX process, and an APEX

Linux high latencies are a consequence of a nonpreemptive kernel approach; the kernel contains large protected sections, where it cannot be preempted by a user task. However, it is the user tasks, implementing the response to an event.

APEX POSIX

-M process thread

+M partition process

To overcome this situation, Ingo Mólnar, one of the authors of the NPTL [9], and Thomas Gleixner reworked the kernel code to reduce non-preemptible sequences to a minimum [12]. This code is available as patch, called PREEMPT- RT (see http://rt.wiki. kernel.org). The latency that can be expected with the PREEMPT- RT patch depends on the hardware and the settings of the system. Main drivers for latency are hardware interrupts, causing the kernel to become active and to enter the remaining non-preemptible sequences. Sources of interrupts are, for instance, the network interface, the graphic card, typically when running an X server, and service interrupts coming from the board. This last kind of interrupts is worse with newer hardware and, especially, with all kinds of portable computers. After running tests, based on Thomas Gleixner’s cyclictest (http://www.rt.wiki.org) on systems with different hardware configurations for 24 – 48 hours each, the following latencies, given in µs, can be considered representative for various kinds of modern PC hardware; + X and - X refer to systems with and, respectively, without an X server running:

Desktop + X Desktop - X Laptop + X Laptop - X

Best Case 1 1 1 1

Average 7 7 18 11

Worst Case 54 17 62 48

Table 2: PREEMPT- RT Benchmarks

Figure 6: IMADE Generation Tool Chain Few assumptions are made on how the IMADE is integrated in the development environment of a real project; it is possible to reuse the configuration data of the original target platform, by directly applying them to the IMADE tools or by transforming them from a proprietary format to the standard ARINC 653 configuration scheme. Additional information, needed for the mapping of APEX to POSIX is kept outside the standard configuration to avoid the pollution of the project’s configuration data by IMADE specific configuration data (RD4). For generating, applying and managing configuration data, the IMADE provides a set of graphical configuration tools. The tools assist the configuration engineer by visualising ARINC 653 concepts like partition scheduling, connection tables or health monitoring events. Figure 7 provides some examples:

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

5.4.

Configuration and Generation Tool Chain

The IMADE uses common tools that are usually coming with the GNU/Linux OS, like the GNU C and Ada compiler and linker. The configuration tables are read and dynamically interpreted by the MOS, but are applied offline to the POS (RD6). For this purpose, additional tools are provided like the makeports tool that transforms the port definitions and the connection table in the ARINC 653 configuration file into C code. These communication stubs must be compiled and linked with the partitioned application as shown in figure 6: 1 Refer to the discussion forum archives on http://www. kernel.org

Figure 7: IMADE Configuration Management Tools

5.5.

Analysis Tools

To study the behaviour of an avionics application in detail (RD7), the IMADE provides logging capabilities. For this purpose, a variant of the execution environment is available that writes internal state information to a log file. The output is human readable but, in the first place,

intended for a tool presenting the states of process execution in a graphical manner. This representation of the process execution focuses on the time and reason of process preemption. At the time of writing, this analysis tool is still a prototype. Figure 8 gives an idea of how the representation of process states will look like:

Figure 8: IMADE Analysis Tool

6.

SUMMARY AND CONCLUSIONS

The IMA Development Environment, discussed throughout this paper, results from the AMOBA project. AMOBA is an implementation of the ARINC 653 APEX running on POSIX compliant RTOS and general purpose OS. It is used as simulator and development tool in several research and development projects in the space and aviation domain. The needs of the users in these projects have been consolidated into a set of requirements and addressed by redesign and improvements of the execution environment and its tool set. The result is a complete development environment that, together with the PREEMPT- RT patch, is able to provide hard real-time execution of avionics applications on Linux. The IMADE supports ARINC 653 compliant configuration and analysis tools to validate applications, based on their execution on the host. The IMADE can be used for many purposes; the main use case is a development tool to reduce the number of expensive target platforms or target emulators that must be purchased for development projects. Other purposes are training, hosting of prototypes and simulation of IMA environments, in the context of research and development projects, for instance. There are several plans for improvements and extensions in the near future. One is the development of a static code analyser for the detection of race conditions and deadlocks; another interesting path of development is the integration of a specific target emulator, capable to mimic the behaviour of specific target systems. This emulator would be configured using the results of real target platform measurements and would execute applications based on a virtual time, modelled after the measured timing behaviour of the target platform.

REFERENCES [1] Airlines Electronic Engineering Committee (AEEC), ARINC Specification 653 Part 1 (Supplement 2), Required Services, Aeronautical Radio Inc., 2006 [2] Airlines Electronic Engineering Committee (AEEC), ARINC Specification 653 Part 2 (Supplement 1), Extended Services, Aeronautical Radio Inc., 2008 [3] J-L. Terraillon, K. Hjortnaes, Technical Note on Onboard Software European Space Technology Harmonisation, Technical Dossier on Mapping, ESA, 2003. [4] N. Diniz and J. Rufino. ARINC 653 in Space. In Proceedings of the DASIA 2005 – DAta Systems In Aerospace Conference, EUROSPACE, Edinburgh, Scotland. June 2005. [5] J. Rufino, S. Filipe, M. Coutinho, S. Santos and J. Windsor. ARINC 653 Interface in RTEMS, In Proc. of the DASIA 2007 – DAta Systems In Aerospace Conference, EUROSPACE, Naples, Italy. May/June 2007. [6] E. Pascoal, J. Rufino, T. Schoofs and J.Windsor, AMOBA - ARINC 653 Simulator for Modular Space Based Applications. In Proc. of the DASIA 2008 – DAta Systems In Aerospace Conference, EUROSPACE, Palma de Mallorca, Spain. May 2008. [7] S. Santos, J. Rufino, T. Schoofs and J.Windsor, A Portable ARINC 653 APEX Interface. In Proc. of the 27th Digital Avionics Systems Conference (DASC), St. Paul, MN, USA. October, 2008. [8] Kevin M. Obenland. The Use of POSIX in Realtime Systems, Assessing its Effectiveness and Performance. The MITRE Corporation. September 2000. [9] U. Drepper, I. Mólnar, The Native POSIX Thread Library for Linux, February 2006, http://people. redhat.com/drepper/nptl-design.pdf. [10] K. Dankwardt, Comparing Real-Time Linux Alternatives, October 2000, http: //www.linuxdevices.com/articles/ AT4503827066.html. [11] J. Corbet, Approaches to Realtime Linux, October 2004, http://lwn.net/Articles/106010. [12] S. Rostedt, Internals of the RT Patch. In Proc. of the 2007 Linux Symposion, June 2007, http://ols. 108.redhat.com/2007/Reprints.