Aligning Deos and RTEMS with the FACE Safety Base Operating System Profile Gedare Bloom Joel Sherrill Gary Gilliland Howard University OAR Corporation DDC-I, Inc. Washington, D.C. Huntsville, AL Phoenix, AZ [email protected] [email protected] [email protected] ABSTRACT application portability across platforms. This includes re- The Open Group Future Airborne Capability Environment quirements that impact the operating system, programming (FACETM) Consortium has developed a reference architec- languages, graphics support, and information interchange ture and standard for real-time embedded avionics systems. between application components. The FACE Technical Standard defines required capabilities The FACE Technical Standard defines four operating sys- for real-time operating systems (RTOS), portable compo- tem profiles, which are a combination of the ARINC 653 [4] nents, and a shared data model to facilitate information and POSIX [3] standards. The profiles are designed to be exchange between components. FACE RTOS requirements amenable to different levels of safety and security certifica- are based on ARINC 653 and POSIX 1003.1b with tailor- tion. The capabilities provided by the RTOS are tailored ing to address the safety and security needs of avionics sys- to meet the requirements of avionics systems. ARINC 653 tems. Deos is a safety-certified RTOS that supports AR- support is required in three of the four operating system INC 653 but not POSIX. In contrast, RTEMS is an open profiles. When initially defined, no existing RTOS provided source RTOS that supports POSIX but not ARINC 653. all of the capabilities required to be FACE conformant. Integrating a paravirtualized RTEMS with Deos combines Applications may either be written to the ARINC 653 the strengths of both and provides a path to conformance APIs or to one of the four POSIX profiles. In three of the with the FACE Safety Base operating system profile. This POSIX profiles, the ARINC 653 services for health, sampling paper presents the FACE operating system profiles and dis- ports, and queueing ports are required to be available for use cusses the technical challenges of the paravirtualization and by POSIX applications while in the fourth profile, this ca- integration effort. pability is optional. Logically, this is two separate execution environments hosted on an underlying operating system that provides virtualized time and space isolation. There is no CCS Concepts requirement that both environments be the same operating •Computer systems organization → Real-time oper- system, which led to our approach of using Deos together ating systems; •Software and its engineering → Real- with RTEMS to meet FACE conformance requirements. time systems software; DDC-I and OAR Corporation were tracking the FACE Consortium effort, but both Deos and RTEMS had signif- Keywords icant capabilities missing for conformance. Deos met the FACE ARINC 653 RTOS requirements but did not meet RTEMS, Deos, POSIX, FACE, paravirtualization, avionics any of the POSIX requirements. RTEMS nearly completely met the POSIX requirements for the single process Safety 1. INTRODUCTION Base profile but had no ARINC 653 support. After analysis The Open Group Future Airborne Capability Environ- in conjunction with discussions, we decided that executing ment (FACETM) is a collaboration of US government and a paravirtualized RTEMS in a Deos partition was a feasible industry to define an open avionics platform suitable for use and affordable path to FACE Safety Base conformance that in both military and commercial aircraft. The Consortium offered a unique value proposition to end users. Combin- has developed a technical standard and conformance process ing Deos and RTEMS capabilities meets most of the FACE as well as implementation and business practice guidance. operating system profile requirements. Purely POSIX appli- The FACE Technical Standard (Edition 2.1 [8]) defines the cations can run under RTEMS, while ARINC 653 tasks can infrastructure and application structure required to ensure run under Deos. For applications that require tasks with both POSIX and ARINC 653 services we provide a novel approach that supports tasks in Deos that request POSIX services from an RTEMS task. The POSIX service is satis- fied by RTEMS as if it were a library in another partition. In this manner, application developers do not need to split their application into tasks specifically to run under RTEMS or Deos, and instead can rely on Deos and RTEMS to work together to satisfy the POSIX and ARINC 653 interface re- EWiLi ’16, October 6th, 2016, Pittsburgh, USA. quirements. Copyright retained by the authors. Figure 1: FACE Architecture with Deos and RTEMS in the Operating System Segment (OSS). Other seg- ments shown: Portable Components Segment (PCS), Platform-Specific Services Segment (PSSS) Transport Services Segment (TSS), I/O Services Segment (IOSS). In this paper, we provide an overview of the FACE oper- 2.1 FACE Operating System Profiles ating system profile requirements, a discussion of the techni- The FACE Technical Standard Edition 2.1 [8] defines four cal capabilities missing from Deos and RTEMS to meet the operating system profiles. These profiles were carefully de- Safety Base profile, and the activities required to integrate signed to reflect the RTOS services and capabilities that had the two RTOSes capabilities and jointly meet the profile re- been through avionics and medical safety and security cer- quirements. tifications at various levels of criticality. All of these profiles are subsets of the full POSIX 1003.1b standard, which in- 2. BACKGROUND cludes approximately 1300 methods. The FACE operating The FACE Reference Architecture is defined in terms of system profiles are as follows with the smaller profiles being five segments. Figure 1 shows how these segments interface proper subsets of the larger profiles: with each other. The Portable Component Segment con- tains portable business logic as components that are poten- • Security - a single process profile that includes 136 tially applicable to multiple avionics systems. These com- POSIX methods and requires ARINC 653. This pro- ponents communicate solely using the Transport Services file was designed for an application such as an infor- Segment (TSS). The TSS is a critical segment in the FACE mation gateway. Applications written to this profile Reference Architecture because all application information do not exit; they execute forever. As such, methods to exchanges are defined in terms of the FACE Shared Data delete, close, or destroy operating system objects are Model and transferred using TSS services. The Platform- not included. Specific Services Segment (PSSS) contains components that • Safety Base - a single process profile which includes include platform specific business logic and device interfaces. 246 POSIX methods and requires ARINC 653. This PSSS components may interface with both the TSS and I/O profile also does not include methods used to delete or Services Segment (IOSS). The IOSS is comprised of software close operating system objects. components that provide a bridge between operating system device drivers to the PSSS. The IOSS is accessed only by • Safety Extended - a multiprocess, multithreaded pro- PSSS components and does not use the TSS. file which includes 335 POSIX methods and requires All of the FACE architectural segments are built on top ARINC 653. This profile also does not include meth- of the Operating System Segment (OSS), which includes the ods used to delete or close operating system objects. operating system, programming language run-times, frame- works, and health services. However, the foundation for all • General Purpose - a multiprocess, multithreaded pro- architectural segments and the deployed platform is the real- file which includes 812 POSIX methods. ARINC 653 time operating system (RTOS) software within the OSS. As support is optional. This profile addresses the needs shown in Figure 1, the OSS is the only segment that con- of applications which do not have safety certification nects with every other segment in the FACE architecture. requirements and require richer POSIX support. This Figure 2: System Architecture Across User-Kernel Modes. profile includes methods used to delete or close oper- to satisfy the conformance requirements for the Safety Base ating system objects, and is also the only profile to OS profile. include stdin, stdout, and stderr. RTEMS is an open source single process, multithreaded RTOS with robust POSIX 1003.1b support. As a mature, POSIX partitions hosted on ARINC 653 RTOSes have ac- community-developed software system, RTEMS has wide cess to the ARINC 653 health services as well as sampling support for about fifteen processor architectures and over and queueing ports. POSIX partitions may use shared mem- 175 board support packages. With user selectable scheduling ory, ARINC 653 ports, or TCP/IP to communicate with algorithms, it supports SMP on PowerPC, ARM, SPARC, applications in other partitions. and x86 and has been tested on systems up to 24 cores. At first glance, the FACE profiles appear to duplicate RTEMS includes multiple file systems including in-memory, those defined by POSIX.13 [1], but there are significant dif- FAT, JFFS2 and a custom RTEMS File System (RFS) for ferences. For example, all FACE POSIX profiles include real-time predictable performance. It also includes FreeBSD networking while only two of the four defined by POSIX.13 TCP/IP and USB support. RTEMS does not have ARINC- include it. The largest difference is that the FACE profiles 653 support so it cannot alone satisfy the Safety Base OS were defined based on industry experience with avionics and profile, and yet when initially evaluated, RTEMS was miss- other safety qualification. This leads to methods considered ing fewer than 10 of the 246 POSIX methods required by unsafe for multi-threaded programming like strtok() being this profile. included in all profiles defined in POSIX.13-1998 but only in Interestingly, evaluated against the multiprocess FACE the FACE General Purpose Profile. Even the largest FACE General Purpose OS profile RTEMS does surprisingly well, profile, the General Purpose Profile, only includes 812 of supporting approximately 90% of the methods required.