Resource Partitioning in Phoenix-RTOS for Critical and Noncritical Software for UAV systems

Modern embedded systems’ increasing complexity and varied safety levels make it hard to coordinate all functionalities within a single run-time environment. Access to more advanced and capacious hardware changes the trend from utilising many separated platforms into one managing the whole compounded airborne system. Providing an appropriate isolation and synchronisation level is achievable only by adapting an operating system with separation mechanisms into UAV systems. This paper introduces Phoenix-RTOS, the microkernel structured real-time operating system designed to be consistent with aerospace standards DO-178C and ARINC 653. The current market offers many counterparts like VxWorks, Integrity 178, PikeOS and many others. These products are well known and used in leading-edge avionics and space projects. However, it is not possible to use them in many low-budget projects due to the high price. The Phoenix-RTOS differs from others and is an open-source project becoming a standard solution for energy, gas meters and UAV systems.In this paper, we focus on the currently designed mechanisms of microkernel architecture for providing a mixed-criticality system, particularly for compliance with ARINC 653. Engineers have been identifying time and space partitioning issues to cope with tight worst-case execution bounds of critical tasks.

Abstract-Modern embedded systems' increasing complexity and varied safety levels make it hard to coordinate all functionalities within a single run-time environment. Access to more advanced and capacious hardware changes the trend from utilising many separated platforms into one managing the whole compounded airborne system. Providing an appropriate isolation and synchronisation level is achievable only by adapting an operating system with separation mechanisms into UAV systems. This paper introduces Phoenix-RTOS, the microkernel structured real-time operating system designed to be consistent with aerospace standards DO-178C and ARINC 653. The current market offers many counterparts like VxWorks, Integrity 178, PikeOS and many others. These products are well known and used in leading-edge avionics and space projects. However, it is not possible to use them in many low-budget projects due to the high price. The Phoenix-RTOS differs from others and is an open-source project becoming a standard solution for energy, gas meters and UAV systems. In this paper, we focus on the currently designed mechanisms of microkernel architecture for providing a mixed-criticality system, particularly for compliance with ARINC 653. Engineers have been identifying time and space partitioning issues to cope with tight worst-case execution bounds of critical tasks.

I. INTRODUCTION
T HE Unmanned Air Vehicles (UAV) market increased significantly in recent years. However, plans about flying machines carrying out missions of particular importance (e.g. transport of hazardous substances and medical supplies) above our heads in inhabited areas cannot become a reality without ensuring the high safety standards of airborne systems. According to European Union regulations introduced in 2019 [1], the UAV can be allowed to conduct a mission in the urban environment only after a positive certification process conducted by the civil aviation agencies such as European Union Aviation Safety Agency (EASA) or Federal Aviation Agency (FAA). To reduce the time of the certification process, the manufacturers choose certified Real-Time Operating Systems (RTOS) to run their critical and non-critical applications. The current market offers several operating systems compliant with aviation standards, but only large companies can afford them due to high license costs. To overcome this obstacle Phoenix Systems has started working on Phoenix-RTOS 178 version compliant with aviation standards [1]. Making a system as an open source product allows manufacturers with a limited budget to enter the market. The new version of the Phoenix-RTOS is designed to comply with DO-178C and ARINC 653 standards described in the next paragraph.

A. Aviation Standards
Standards play a crucial role in the aerospace industry. One of the most important is DO-178C, the fulfilment of which allows usage software in airborne devices. DO-178C defines five levels of failure caused by software: catastrophic, hazardous, major, minor, and no effect. Moreover, it defines five corresponding Design Assurance Levels (DAL) from the most rigorous level A to level E. Depending on the DAL level, tenants' appropriate process management has to be fulfilled. Another one, Aeronautical Radio Incorporated (ARINC) standard focuses on technical aspects that define a series of detailed rules for a dedicated area, like data transmission protocols, cockpit user interfaces, and many others. The aerospace projects are always compliant with DO-178C, however meeting the ARINC standards depends on project's requirements. The best policy for operating system development for critical applications is described in standard ARINC 653. Running different critically level software on the same hardware platform is the primary domain of Integrated Modular Avionics (IMA). To realize an IMA approach in RTOS, the Partitioning Operating System (POS) concept should be introduced to support spatial and time partitioning [10]. In the avionics industry, the Avionics Application Standard Software Interface, called APEX provided by ARINC 653, has been introduced as a set of guidelines to provide a standardized interface between POS and avionics applications [10]. The leading role of the ARINC 653 is to improve the safety and certification process of safety-critical systems and outline the architectures approach for POS's engineers [10]. More details about APEX are presented in the fourth section.

B. History of Phoenix-RTOS
The idea for writing a new RTOS originates from the Warsaw University of Technology where the prototype of Phoenix-RTOS was developed from scratch as a master thesis [1] in 1998. The rapidly growing Internet of Things (IoT) market resulted in an industry need where a new operating system with efficient implementation and rich functionalities to be required. Due to this fact, the second version of Phoenix-RTOS was developed by Phoenix Systems and widely implemented in data concentrators for the smart grid, smart energy meters and smart gas meters. Phoenix-RTOS 2 is recognized on the market as a real-time system for the smart grid and software-defined solutions.
The third version of the system based on a microkernel architecture has been developed to be easily used in microcontroller-based low power devices and more advanced processors. The new approach provided in version three allows the use of Phoenix-RTOS on a broad range of processors architecture from the smallest ones like ARM Cortex-M, to more those complex like ARM Cortex-A, ia32 or RISC-V [1]. Employing the Phoenix-RTOS in version three to the energy meters sector has proven its applicability for high complexity systems which work in harsh environments. The experience obtained in the industry moved the company forward in achieving the next milestone to make Phoenix-RTOS consistent with DO-178C standard in a design assurance level A.
Phoenix-RTOS compliant with DO-178C is developed as an open-source project under the BSD license. From the time of writing this paper, only several open-source competitors supporting ARINC 653 have been found, which are described in the third chapter. The rest of the systems for critical purposes are commercial. It is strongly believed that by providing the system as an open-source product, the gap in the market is filled for projects with a limited budget, and the topic of critical systems will be covered. This paper presents our consideration for partitioned based microkernel development in Phoenix-RTOS. A current trends analysis in the industry has been conducted and there are visible alternatives that can be offered by the open-source product. The research focuses on implementing microkernel mechanisms to support spatial and time partitioning to fill ARINC 653 requirements.

II. MIXED CRITICALITY SYSTEM
Operating systems for critical purposes should be highly reliable. As is considered in Tanenbaum et al. [5] they should not be interrupted entirely or halted to recover from a failure that occurs in a module that is not in the critical execution path of a service or an internal operation [4]. To achieve this goal, operating systems should provide safety and security functionalities not to allow the non-critical zone's fault to propagate to a critical one. Safety and security functions seem to be similar, and although these terms have common elements, they differ. This chapter presents the concept of safety-critical and security-critical systems in more detail. The next one presents examples of systems divided into appropriate categories.

A. Safety-critical
The main challenge tackled by a safety-critical system is to provide a clear border between different critical zones called partitions. Due to this fact, these kinds of operating systems are often called partitions kernels. Partitioning mechanisms should provide spatial and temporal separation [2]. Moreover, the partition kernel is in charge of resources management such as I/O devices to permit access to only assigned parts of the system. To enforce spatial separation, each individual partition runs in a hardware-protected address space. For this purpose, the Memory Management Unit (MMU) performs mapping of virtual to physical addresses. To enforce time separation, each partition and thread have a dedicated time slot of the CPU in which the actions have to be completed. The static analysis is obligatory to define the Worst-Case Execution Time (WCET) of each running partition and process. Based on the WCET the best scheduling algorithm is selected to take control of the CPU when attempts of time overrun occur. The central concept of a safety system requires static resource allocation for partitions and static analysis of system performance. Safetycritical systems are compliant with DO-178C and ARINC 653. However, standards do not impose requirements describing how spatial and time separation should be performed. The chosen solutions can differ between individual systems.

B. Security-critical
The security-critical systems originate from the concept of Multiple Independent Levels of Security (MILS) specification, which is a high-assurance architecture based on separation and information flow security [3]. The foundation of MILS is a Separation Kernel (SK), which is responsible for adherence of data isolation, damage limitation and resource partitioning. SK extends partitioning kernels of sets of specific functionalities to enforce security separation, and information flow [2]. The security requirements are known as Common Criteria (CC) [3] establishing seven Evaluation Assurance Levels (EAL) from 1 to 7, which is the most rigorous. Moreover, CC defines robust requirements dedicated to an operating system called Separation Kernel Protection Profile (SKPP). To obtain satisfying certification for EAL7, the partitioning mechanisms have to be rigorously verified using formal methods [3]. Compared to partitioning kernels, SK provides a more dynamic environment that does not have to be known ahead of time. The typical approach to realizing separation kernel is based on embedded hypervisor and software virtualization mechanisms. The hypervisor layer manages the system resources and virtual partitions, which are capable of running guest operating systems with different levels of critically [2].

III. BACKGROUND AND RELATED WORK
Operating systems for critical applications is a complex topic that demands a considerable workloads and financial resources. Due to this fact, only several companies can deliver reliable products. The most known and widely used systems on the market are presented in the following subsections. The last paragraph is devoted to open source projects.

A. Lynx Software Technologies
The Lynx Software Technologies has on offer two operating systems for critical application: LynxOS-178 and LynxSecure.
The first version of the system, LynxOS-178, is a safetycritical system. It meets the DO-178C DAL A regulations and supports POSIX, and APEX standards [6]. However, this version of OS would not meet the highest EAL7 criteria, which require formal mathematical methods to prove the security of SK. For this reason, LynxSecure is introduced to provide a separation kernel based on hypervisor virtualization. The second version OS design includes safety and security domain isolation, trusted execution environments and reference monitor plugins such as firewalls and encryption [6]. A popular solution for complex systems is to use LynxSecure to provide secure partitioning and LynxOS-178 to launch critical applications compliant with APEX.

B. GreenHills
INTEGRITY 178 is a world-leading RTOS for safety and security applications certified both to the highest level of DO-178C DAL A and SKPP/EAL6+ [7]. The producer claims tasks protection in the guaranteed time window domain. The space domain is arranged by static memory allocation and hardware enforcement of MMU for each partition. The system isolates applications and data into different security domains to ensure the MILS environment. As a separation kernel, IN-TEGRITY 178 provides a virtualization layer in the userspace instead of in the kernel [7].
The GreenHills also offers a version for multicore architectures -INTEGRITY 178 tuMP. As one of the few systems that provide full flexibility in choosing the software multi-processing architecture, ranging from simple Asymmetric Multi-Processing (AMP) to modern Symmetric Multi-Processing (SMP) to Bound Multi-Processing (BMP) for the highest combination of determinism and utilization [7].

C. WindRiver
The WindRiver company takes a similar approach as Lynx Software Technologies. In the offer can be found two versions of software for critical purposes. The first one VxWorks 653 is compliant with DO-178B/C DAL A and ARINC 653 [8]. The second one VxWorks MILS provides compliance to SKPP using a hypervisor. To combine safety and security mechanisms, two versions of WindRiver products are used side by side.

D. SYSGO
The flag product of SYSGO company is a PikeOS compliant with DO-178C DAL B and ARINC 653 [2]. Although the system provides safety and security-critical mechanism, it is not compliant with SKPP. PikeOS offers a separation kernel-based hypervisor with multiple partitions for many other operating systems and applications [9]. The engineers from SYSGO developed a similar concept as the GreenHills company for INTEGRITY-178. The PikeOS does not need an external hypervisor, its internal layer provides security and virtualization between partitions.

E. Open Source Systems
According to a survey presented by researchers in [2], the majority of open-source projects are academic implementations. Special consideration should be given to POK and XtratuM operating systems due to compliance with ARINC 653. However, none of them is compliant with DO-178C. Furthermore, there are other systems worth mentioning like Quest-V or Muen. Although they provide some mechanism of spatial and temporal partitioning of resources, they do not comply with any of the considered standards.

IV. ARINC 653
The primary objective of ARINC 653 is to fulfil the IMA requirements to provide an environment for the independent execution of avionics applications utilizing different critical levels. The majority scope of the regulation defines the Application Programing Interface (API) between the operating systems and avionics applications. One of the benefits of standard usage is to provide high portability of avionics software to run on different operating systems.
The standard consists of five parts [11]. Part 0 describes a general overview about ARINC 653. Part 1 summarises the required services to be supported by APEX and part 2 reports extended services. Section B in chapter fourth, precisely presents the services concepts. Part 3 of ARINC 653 is divided into two parts: 3A and 3B, and provides a guideline for conformity tests for both required and extended services. Part 4 defines a subset of API specified by part 1. Finally, part 5 describes recommended capabilities for multicore applications. The conformance of the APEX API to the ARINC 653 standard is validated by passing all of test suites defined by part 3 of the standard. Fig. 1 shows the example architecture of a system compliant with ARINC 653. The integrated module represents a complete RTOS which consists of a core module and applications. The Core Software (CSW), referred to as the operating system and hardware layer applying many processors, each consisting of one or more processor cores [11]. CSW should provide the ARINC 653 interface, health monitoring system, two level scheduler and suitable time and space separation based on configuration data. The highest layer of the IMA architecture presents either application software partitions and system partitions. The first ones are restricted to using only ARINC 653 calls to interface to the system [11]. The second ones are partitions specific for the operating system requiring interfaces outside of the APEX scope. They manages system specific task such as device drivers or fault management schemes [11] which are not defined by ARINC 653. Both of them are subject to robust space and time partitioning.

B. Static System Configuration
According to the specification, a partition is a program in an application environment that consists of text, data section, stack, own context, and configuration attributes [11]. In this case, a process is a programming unit contained within a partition that executes concurrently with other processes within the same partition [11]. In other words, the process in ARINC 653 glossary corresponds to a thread running inside a process, and the partition refers to a process in UNIX like systems.
Each of the partitions and processes are described by system configuration files. They contain detailed information about the demand for system resources, communication ports, execution windows and scenarios for health monitor systems. The most popular approach for APEX environment description is an Extensible Markup Language (XML) or AADL language.

V. PHOENIX-RTOS 178
Phoenix-RTOS 178 is a new version of the system compliant with DO-178C and ARINC 653, based on the Phoenix-RTOS version three. The new approach follows the rules for mixed safety-critical systems to provide a reliable and robust run-time environment for the avionics industry.
This chapter focuses on the system architecture to explain how spatial and time separation is resolved in Phoenix-RTOS 178. The presented solutions have been developed and deployed on the Zedboard platform, equipped with a Xilinx Zynq-7000 dual-core ARM Cortex-A9 processor family.

A. System Architecture
The system architecture consists of a bootloader and a kernel. The first one, Phoenix-RTOS loader (PLO) can be treated as a first-stage and a second-stage bootloader. Acting as the first-stage bootloader, PLO configures the memory controllers and various supported devices on a dedicated platform. It is also responsible for preparing the board for the kernel and performing built-in tests (BITs) to check correctness of the operation of the critical peripherals. The second-stage bootloader loads the operating system and selected partitions from storage devices to the memory. The fig. 2 shows PLO Command-Line Interface (CLI). Configuration data about the system setup is passed to the kernel by a structure called syspage. The syspage contains all information about board configuration and partition descriptions compliant with ARINC 653 standard. The second system's component is a kernel responsible for providing spatial and time separation by memory and threads  management modules. The system is startup by the initial thread being in charge of launching the health monitor, system and user partitions with resources assigned to them by the setup data. After the successful initialization phase, the chosen scheduler algorithm is launched. The fig. 3 shows Phoenix-RTOS providing interaction with user via Phoenix-RTOS shell. The essential kernel's safety-critical mechanisms are described in the next two chapters.

B. Spatial Separation
The crucial element of the system for critical purposes is providing spatial separation for partitions. In Phoenix-RTOS 178, this mechanism is implemented using multi maps and an MMU controller. The multi maps approach allows the simultaneous use of different memory devices such as on-chip RAM (OCRAM) or DDR SDRAM. This solution provides additional physical separation. User is able to use a specific memory for dedicated purposes. If there is a requirement to use the memory with a fast access for critical application, the OCRAM should be chosen. The memory virtualization is provided by the MMU controller and configured based on the information about accessible volatile memory described by the PLO in the syspage.
Another essential element embedded into the memory management module is a caching policy. Phoenix-RTOS 178 invalidates and cleans executable pages and allows the user to define uncacheable memory regions independently.
The memory virtualization provides the same linear memory map for each partition. Switching between them provides an additional delay in changing the MMU controller's translation table. To avoid an overhead, the Address Space Identifier (ASID) mechanism is added to the memory management module to assign a memory map to the partition. Furthermore, the spatial separation is in charge of controlling of the mapping I/O devices' memory to only one partition to not allowing sharing resources.

C. Time Separation
A robust and reliable scheduling policy is an essential element of the operating system to perform critical tasks on time. In an environment compliant with ARINC 653, a twolevel scheduler should be introduced. The fig. 4 shows an illustrative scheduling policy for mixed-criticality systems.
The first scheduler supervises the partition work. The most common algorithm for hard real time embedded systems is the Rate Monotonic (RM) scheduling with a fixed priority [12]. In the presented example, each partition has: an assigned priority, WCET, Average Case Execution Time (ACET) and period. The critical partitions have the highest priority allowing to preempt the other ones and to meet deadlines. Making a static analysis using the integration tool, it is possible to verify whether the system is feasible and all partitions can meet their deadlines with the assumed values.
The second scheduler is responsible for scheduling processes within a partition. The ARINC 653 allows to choose a dedicated scheduling policy or the default one is selected.
Keeping WCET bounds of partitions depend on the internal mechanism of the operating system. The common problem for RM scheduling policy is a priority inversion, causing deadlock between partitions or processes. To avoid this situation, the synchronization mechanisms owning dynamic changing priority to the highest one sharing amongst other partitions or threads.

D. APEX Interface
Realization of the APEX services in Phoenix-RTOS 178 is performed using systems calls to the kernel. The interface is implemented in the form of a static library linked to the partition executive file. The library interface checks the correctness of the given arguments and passes them via the Application Binary Interface (ABI) to the kernel running in a privileged mode.
The microkernel architecture provides a message passing interface between servers. The communication services like inter-partition communication use the exact mechanism. The other ones use a dedicated system calls to perform the action defined in ARINC 653.

VI. CONCLUSION
In this paper, we presented the research work on the mechanisms for integrating critical and noncritical software management by safety operating systems. The growing UAV market and its application will need to use reliable RTOS compliant with DO-178C and ARINC 653. Phoenix-RTOS 178, as an open source project, will be the best choice for manufacturers entering the market with a limited budget.
The presented work shows working Phoenix-RTOS on the Zynq-7000 platform commonly used in airborne systems. Our goal was to highlight the basic concepts of mixed criticality systems and explain the general architecture of Phoenix-RTOS 178. Future work includes completing time and space separation mechanisms as well as the APEX interface in Phoenix-RTOS 178.