Julien Delange, European Space Agency
Laurent Lec, MakeMeReach

Introduction

Avionics or aerospace systems must provide a good level of reliability and robustness. Such systems must ensure a continuous operational state, even in case of unexpected event or conditions. This is especially difficult because they may operate in hostile environment and be exposed to hazards.

To address potential issues, safety-critical software must be designed with particularly attention. For that purpose, specific standards define design and coding rules to be checked during the development process and dedicated execution platforms has to be used to reduce potential errors and their impact. For example, in the avionics domain, the DO178-B [1] standard defines the quality criterion (in terms of performance, code coverage, etc.) to be met, depending on the criticality level of the system.

The ARINC653 [2] standard specifies services of an avionics execution platform. It provides time and space isolation of software functions in an entity called in partition:

• Time isolation: each partition has a fixed time slice to execute its tasks and cannot overrun its time budget so that a partition cannot impact the execution of another.
• Space partitioning: an address space is dedicated to the code and data of each partition and a partition cannot write outside its own space. In addition, communication propagated outside the partition are enforced by the underlying isolation layer.

All these standards, methods or software assist engineers in the design by detecting errors and handling them when they are raised.

Problem

Actually, if open-source software is widely used to produce embedded and real-time systems, few solution address the needs of safety-critical systems. Several initiatives (such as Open-DO [7] or Xtratum [3]) address these issues but the amount of projects is still not sufficient. For avionics architecture design, few tools exist. Globally, this problem is related to most of safety-critical systems where a certain level of quality has to be met. Availability of such tools under free-license is a strong need for several reasons. First, they are very specific to a domain and must be analyzed and validated, which is very costly. So, having open-source tools could improve collaboration between system designers but especially reduce associated development and maintenance costs.

Then, when using commercial tools, users depend on the tool provider. This is especially critical for such software since users need a long-term support. In consequence, if tool provider goes bankrupt, there is no guarantee of support so that the user may have to develop a new implementation by himself, which is very costly in terms of time and money. On the contrary, having an open-source tools guarantee software maintenance and support, even if the original contracted company disappear.

Finally, some aspects of standards (such as ARINC653 [2]) are not clearly specified so that their support are implementation-specific. In consequence, users have to comply with tools-vendor constraints and adapt their software each time they switch from one tool/implementation to another. For example, in the ARINC653 standard, this is not clear how distributed architecture has to be designed, especially how device drivers are integrated within the overall runtime architecture.

Approach & solution

To overcome these issues, we propose to implement tools and software dedicated to avionics systems design under free-software license (such as GPL or BSD). Typically, it consists in an ARINC653-compliant execution runtime that supports time and space isolation and its fully compliant with the current version of the standard.

This platform is integrated with a toolset that will also help engineers to test and design the systems. Design standards (such as DO178-B [1]) requires the enforcement of several quality criterion. By integrating software with validation and analysis tools, it will provide help to engineer to check standards requirements validation.

Finally, by providing an implementation of a standard, we also propose an implementation of some under-specified aspects. For example, device drivers and distributed aspects of ARINC653 systems would likely be addressed by an free implementation. The availability of the source code and its documentation could also initiate discussions and standardization initiatives for these aspects.

Results

POK [4], an ARINC653-compliant execution runtime released under the BSD license provides space and time partitioning support. It isolates software according to their criticality levels and supports the first part of the services defined in the ARINC653 standard.

This platform is available for three architectures: x86, PowerPC and SPARC (LEON3 processors). It can be tested easily by using QEMU, a GPL-licensed system emulator that support many processor types.

POK also defines its own device drivers integration method and distributed systems concerns implementation. In that purpose, device drivers are isolated within partitions: software that use a device has to established communication with the partition that execute its driver. By doing so, interaction between device users and device providers are explicitly defined (and enforced by the kernel). In addition, by isolating drivers within partitions, their potential errors are contained and have a limited impact (it cannot crash the whole system as in most operating systems).

Finally, this platform is integrated with a toolset that will also help engineers to test and design the systems. It includes a simulator to quickly test and check system behavior. In addition it supports COUVERTURE [6], a code analyzer released under GPL by Adacore [5], that evaluates system code coverage. This is a particular interest in the context of avionics system because code coverage is a quality criteria that must be checked on the implementation code.

Conclusion

In this paper, we present our BSD-licensed execution runtime for avionics systems: POK. It is fully compliant with the existing ARINC653 standard by providing space and time partitioning as well as basic communication services. POK also defines its own integration of device drivers and definition of distributed architectures based for partitioned systems. Moreover, its availability for several embedded platform would ease its use in an industrial context. Finally, its integration within a framework dedicated to the design of avionics domain (such as the COUVERTURE tools) ease engineers in the design and validation of their systems.

This work could be also extended in several ways. POK provides the required services of ARINC653 but other services (like the file system defined in the second part of the standard) can be introduced. It would provide more functionnalities to partition functions and so, would open POK to new development opportunities. Finally, we can also connect POK with other tools. Like the integration with QEMU, we could also integrate third-party tools that would ease developers efforts in the development process, either during system design or for implementation validation.

References

[1] Software Considerations in Airborne Systems and Equipment Certification, DO-178B http://www.rtca.org/downloads/ListofAvailableDocsMarch2011.htm#_Toc289420032
[2] ARINC653 specifications: https://www.arinc.com/cf/store/index.cfm
[3] Xtratum: http://www.xtratum.org
[4] POK: http://pok.safety-critical.net
[5] Adacore: http://www.adacore.com
[6] COUVERTURE: http://www.open-do.org/projects/couverture/
[7] Open-DO: http://www.open-do.org