Open Source Implementation of Hierarchical Scheduling for Integrated Modular Avionics ∗ Juan Zamorano, Juan A. de la Puente Universidad Polit´ecnica de Madrid (UPM) E-28040 Madrid, Spain jzamora@fi.upm.es, [email protected] Alfons Crespo Universidad Polit´ecnica de Valencia (UPV) E-46022 Valencia, Spain [email protected] Abstract This paper describes the porting of a Ravenscar compliant kernel (ORK+) to the hypervisor XtratuM to build up an open source ARINC 653 platform for avionics systems. The Integrated Modular Avionics (IMA) architecture requires a specialized operating system layer that provides temporal and spatial iso- lation between partitions. The ARINC 653 standard defines an architecture and an applications program interface (API) for such an operating system or application executive (APEX), in ARINC terms. There are diverse ARINC 653 implementations available from multiple vendors, and the standard has been suc- cessfully used in a number of commercial and military avionics systems. However, there was not an open source ARINC 653 platform available. The combination of both tools (ORK+ and XtratuM) provides an IMA platform that allows different criticality applications to share the same computer board. 1 Introduction be put in place in order to isolate applications from each other. The common approach is to provide a number of logical partitions on each computer plat- Current trends in avionic systems envisage systems form, in such a way that each partition is allocated a with increased functionality and complexity. Such share of processor time, memory space, and other re- systems are often composed of several applications sources. Partitions are thus isolated from each other that may have different levels of criticality. In such a both in the temporal and spatial domains. Temporal scenario, the most critical applications must be iso- isolation implies that a partition does not use more lated from the less critical ones, so that the integrity processor time than allocated, and spatial isolation of the former is not compromised by failures occur- means that software running in a partition does not ring in the latter. Isolation has often been achieved read or write into memory space allocated to another by using a federated approach, i.e. by allocating dif- partition. ferent applications to different computers. However, This approach has been successfully imple- the growth in the number of applications and the mented in the aeronautics domain by so-called In- increasing processing power of embedded comput- tegrated Modular Avionics (IMA) [10]. The IMA ers foster an integrated approach, in which several architecture requires a specialized operating system applications may be executed on a single computer layer that provides temporal and spatial isolation be- platform. In this case, alternate mechanisms must ∗This work has been partly funded by the Spanish Ministry of Science, project TIN2008-06766-C03-01 (RT-MODEL) 1 tween partitions. The ARINC 653 standard defines 2 XtratuM Overview an architecture and an applications program inter- applica- face (API) for such an operating system or XtratuM [7, 8, 6] is a type 1 hypervisor that uses tion executive (APEX), in ARINC terms. Temporal para-virtualisation. It was designed to meet safety isolation is provided by using a two-level schedul- critical real-time requirements. The most relevant partition scheduler ing scheme. A allocates processor features are: time to partitions according to a static cyclic sched- ule, where each partition runs in turn for the dura- tion of a fixed slice of time (cf. figure 1). The ARINC • Bare hypervisor. global scheduler is a variant of a static cyclic exec- utive, while the local schedulers are priority-based. • Employs para-virtualisation techniques. Spatial isolation between partitions is provided by implementing a separate address space for each par- • An hypervisor designed for embedded systems: tition, in a similar way as process address spaces are some devices can be directly managed by a des- protected from each other in conventional operat- ignated partition. ing systems. There are diverse ARINC 653 imple- mentations available from multiple vendors, and the • Strong temporal isolation: fixed cyclic sched- standard has been successfully used in a number of uler. commercial and military avionics systems. However, there was not an open source ARINC 653 platform • Strong spatial isolation: all partitions are exe- available. cuted in processor user mode, and do not share This paper describes the porting of an improved memory. version of the Open Ravenscar Kernel (ORK+) [11] to the hypervisor XtratuM [9] to build up an open • Fine grain hardware resource allocation via a source ARINC 653 platform [3] for avionics systems. configuration file. The combination of both tools provides an IMA plat- form that allows different criticality applications to • Robust communication mechanisms (AR- share the same computer board. Section 2 describes INC653 sampling and queuing ports). the main features of the hypervisor XtratuM. Sec- tion 3 details the architecture of ORK+ and changes needed to port it to XtratuM. Finally, some con- XtratuM provides a virtual machine closer to the clusions about the resulting ARINC 653 complaint native hardware. The virtual machine provides the operating system are drawn and plans for the near access to the system resources: cpu registers, clock, future are explained in section 4. timer, memory, interrupts, etc., through a set of sys- tem calls (hypercalls). Each virtual machine is re- ferred as “guest”, “domain” or “partition” and can contain a bare code or an operating system with the applications. To execute an operating system as a guest partition, it has to be para-virtualised which implies the replacement of some parts of the operat- ing system HAL (Hardware Abstraction Layer) with the corresponding hypercalls. In this approach, a partition is a virtual com- puter rather than a group of strongly isolated pro- cesses. When multi-threading (or tasking) support is needed in a partition, then an operating system or a run-time support library has to provide it. Figure 2 shows the XtratuM architecture and the relation with the partitions. The services provided by XtratuM are sum- marised in the table 1. Additionally to these gen- eral services, XtratuM provides specific services that FIGURE 1: ARINC 653 hierarchical archi- strongly depend on the native processor that are tecture. shown in table 2. 2 FIGURE 2: XtratuM and its development environments. Currently, version 2.2 is being used by CNES as a TSP-based solution for building highly generic and Group of ser- Hypercalls Partition reusable on-board payload software for space appli- vices type cations [1]. TSP (time and space partitioning) based Clock man- get clock; define timers Normal architecture has been identified as the best solution agement to ease and secure reuse. It enables a major decou- IRQ Man- enable / disable IRQs, Normal pling of the generic features that are being devel- agement mask / unmaks IRQs oped, validated, and maintained in mission-specific IP Commu- create ports; read / re- Normal data processing [2]. nication ceive / write / send messages IO manage- read/write IO Normal ment 3 ORK+ Overview Partition mode change, halt / re- System management set / resume / suspend ORK [4] is an open-source real-time kernel which / shutdown partitions provides full conformance with the Ravenscar task- (system) ing profile on embedded computers. The kernel has a Health mon- read / seek / status System reduced size and complexity, and has been carefully itoring man- HM events designed to allow the building of reliable software for agement embedded applications. This kernel is integrated in a Audit facili- read / status System cross-compilation system based on GNAT, support- ties ing the subset of Ada tasking which is allowed by the Ravenscar profile in an efficient and compact way. TABLE 1: XtratuM hypercalls ORK+ [11] includes support for the new Ada 2005 timing features, such as execution time SparcV8 hypercalls clocks and timers. The ORK+ kernel provides all the XM sparcv8 atomic add required functionality to support real-time program- XM sparcv8 atomic and ming on top of the LEON2 hardware architecture. XM sparcv8 atomic or The kernel functions are grouped as follows: XM sparcv8 ush regwin XM sparcv8 get ags 1. Task management, including task creation, XM sparcv8 inport synchronization, and scheduling. XM sparcv8 iret XM sparcv8 outport 2. Time services, including absolute delays and XM sparcv8 set ags real-time clock. TABLE 2: XtratuM SparcV8 hypercalls 3. Interrupt handling. 3 FIGURE 3: ORK+ architecture. That kernel functionality is implemented with • System.BB.Peripherals.Registers: Defini- the following components (figure 3): tions related to input-output registers of the peripheral devices. • System.BB:1 Root package (empty interface). • System.BB.Threads: Thread management, in- cluding synchronization and scheduling control functions. • System.BB.Serial Output: Support for serial output to a console. • System.BB.Threads.Queues: Different kernel queues such as alarm queue and ready queue. • System.BB.Time: Clock and delay services in- cluding support for timing events. That software architecture make easy to port • System.BB.Time.Execution Time Support: ORK+ to different hardware or software platforms. Execution time clocks and timers as well as Most of kernel components are fully independent group budgets support. from the underlying platform and the lower level components have specifications that are also plat- • System.BB.Interrupts: Interrupt handling. form independent. In this way, it is only needed to • System.BB.Parameters: Configuration pa- re-implement the lowest level functions on top of the rameters. provided XtratuM functions to obtain the full ORK+ functionality. • System.BB.CPU Primitives: Processor- The modified components were System.BB.Time, dependent definitions and operations. System.BB.Interrupts, System.BB.CPU Primi- • System.BB.Peripherals: Support for periph- tives, System.BB.Time.Execution Time Support erals in the target board. and System.BB.Peripherals. 1“BB” stands for “bare-board kernel”.