20.4.1 RTOS Kernel

The kernel is the heart of the RTOS. It provides the basic services (such as the ARINC 653 services described in Section 20.8.1) and is designed to be independent of the underlying hardware, as much as possible.^† The goal of most RTOS developers is to isolate the kernel from the hardware in order to allow reuse and portability. The hardware-specific code is normally implemented in the BSP and device drivers.

20.4.2 Application Program Interface

The applications access the RTOS services through an API, which functions as the interface between the RTOS kernel and an application.

The API provides a list of available calls that a programmer can make using the RTOS. The ARINC 653 APEX (APplication EXecutive) is the most common API used in avionics for IMA systems. The POSIX (portable operating system interface) is also employed by some RTOSs. POSIX standards (such as Institute of Electrical and Electronic Engineers [IEEE] 1003.1b) include the following interface definitions for an RTOS: task management, asynchronous I/O, semaphores, message queues, memory management, queued signals, scheduling, clocks, and timers [7]. POSIX is based on UNIX (uniplexed information and computing system). Because there were multiple flavors of UNIX, there are several IEEE standards related to POSIX [4]. As UNIX was not developed for a hard real-time environment, POSIX must be used carefully in avionics. This was one of the motivations for the development of the ARINC 653 APEX. There is some similarity between ARINC 653 and POSIX, since many of the POSIX concepts influenced ARINC 653. The difference between POSIX and ARINC 653 APEX is small at the API level; however, the differences are more significant at the program organization level. APEX was conceived to provide separation between different applications sharing the same processor; i.e., to provide robust partitioning between the APEX partitions. POSIX does not provide the same kind of robust partitioning, but it does provide support for multiple processes to collaborate. Table 20.1 provides a high-level general comparison of ARINC 653 and POSIX.

20.4.3 Board Support Package

The BSP isolates the RTOS from the target computer processing hardware. It allows the RTOS kernel to be portable to various hardware architectures within the same central processing unit (CPU) family. “The BSP initializes the processor, devices, and memory; performs various memory checks; and so on. Once initialization is complete, the BSP can still function to perform low-level cache manipulations” [9], as well as some other hardware access (e.g., flash manipulation or timer access). Much of the BSP code operates in privileged mode and works closely with the RTOS. The BSP is sometimes called a hardware abstraction layer, a hardware interface system, or platform enabling software. It is customized for the specific hardware and is often implemented using C and assembly. The BSP is sometimes developed by the RTOS users (e.g., the avionics developer) using a template from the RTOS supplier—especially when the avionics utilize custom hardware. At other times, the BSP is provided and/or tailored by the RTOS supplier. Depending on the nature of the hardware, the BSP can be a rather large component.

20.4.4 Device Driver

Similar to the BSP, the device driver provides the interface between the RTOS kernel and a hardware device. The hardware devices may be on the processor board or separate. Hardware on the processor board may be handled by the BSP or a separate driver. The driver is a low-level, hardware-dependent software module that provides the interface between an application (sometimes mediated by higher level RTOS library or kernel functions) and a specific hardware device. A device driver is responsible for accessing the hardware registers of the device and may include an interrupt handler to service interrupts generated by the device. Most avionics systems have multiple devices, such as Ethernet devices, ARINC 664 avionics full-duplexed switched ethernet (AFDX) end systems, RS-232 serial devices, I/O ports, analog-to-digital converters, and controller area network (CAN) databuses.

20.4.5 Support Libraries

Oftentimes, language-specific run-time support is provided as libraries with the RTOS kernel. For example, “in the C language, a number of standard library specifications permit the user to call functions to move memory, compare strings, and use mathematical functions such as mod, floor, and cos” [9]. These run-time libraries are often packaged with the RTOS (either within the kernel or as a separate library package). The libraries are normally provided by the RTOS supplier as precompiled object code that can be linked together with the applications. That way, only the library functions needed are linked in. Some smart linkers can actually identify which library functions are called by the application and only link those functions into the executable.

20.5.1 Deterministic

A safety-critical system delivers the right answer in the right order and at the right time. “Determinism is the characteristic of a system which allows the correct prediction of its future behavior given its current state and knowledge of future changes to its environment (inputs)” [10]. Nondeterminism on the other hand “means that a systems’ future behavior cannot be correctly predicted. (An unpredictable system cannot be called ‘safe.’)” [10]. The behavior of an RTOS in a safety-critical domain must be predictable. That is, given a particular input, the RTOS generates the same output. In particular, the outputs are within the bounds defined in the requirements. A deterministic RTOS provides both functional correctness and temporal correctness as defined by the requirements; it also only consumes known and expected (bounded) amounts of memory and time.

20.5.2 Reliable Performance

The RTOS must meet the horsepower requirements needed to enable the application to perform its intended functionality. Many factors determine the RTOS performance, including computation times, scheduling techniques, interrupt handling, context switch times, cache management, task dispatching, etc. [4]. Performance benchmarks are typically provided in a data sheet with the RTOS. Performance varies widely depending on the specific hardware, interfaces, clock speed, compiler, design, and operating environment. Thus, when selecting an RTOS, companies almost always run their own benchmarks before deciding which RTOS to purchase.

20.5.3 Compatible with the Hardware

The RTOS kernel must be compatible with the selected processor. Likewise, the BSP must be compatible with the selected processor board and core devices, and the device drivers must be compatible with the system devices.

20.5.4 Compatible with the Environment

The RTOS should be capable of supporting the selected programming language and compiler. Most RTOSs are supported with an integrated development environment, which includes the compiler, linker, debugger, and other tools for successful integration of the applications, RTOS, supporting software, and the hardware.

20.5.5 Fault Tolerant

Fault tolerance is “the built-in capability of a system to provide continued execution in the presence of a limited number of hardware or software faults” [11]. A fault tolerant RTOS plans for application failures and provides mechanisms for recovery or shutdown. The RTOS enables fault management which consists of (1) detecting faults, failures, and errors; (2) correctly identifying faults, failures, and errors when they are detected; and (3) performing the response preplanned for the system [11].

20.5.6 Health Monitoring

Health monitoring is closely related to fault management and is another feature of a fault tolerant RTOS. Health monitoring is a service frequently provided by an RTOS to provide fault management for most (if not all) of the system that uses the RTOS. DO-297 explains that health monitoring is responsible for detecting, isolating, containing, and reporting failures that could adversely affect resources or the applications using those resources [11]. DO-297 focuses on the IMA platform; however, the RTOS plays a key role in the overall health management scheme of the system. The Federal Aviation Administration (FAA) research report on RTOSs in IMA systems states the following:

Health monitoring is specified in ARINC 653. The health monitor is the RTOS function responsible for identifying, responding to, and reporting hardware, application, and RTOS faults and failures. Health monitoring helps to isolate faults and prevents failures from propagating.

By classifying and categorizing faults and the health management responses, a range of possibilities exists that helps the application supplier and IMA system integrator select appropriate behavior. Configuration tables are used to describe intended recovery of identified faults, such as ignoring the fault, reinitializing a process, restarting (warm or cold) a partition, performing a total system reset, or calling a system-specified routine to take system-specified actions [12].

ARINC 653 identifies a number of error codes that must be detected and handled. “An error can be handled within a process, in a partition, or in the health monitoring module or process” [9].

The objective of the ARINC 653 health monitoring function is to

contain faults before they propagate across an interface boundary. In addition to self-monitoring techniques, application violations, communication failures and faults detected by applications are reported to the RTOS. A recovery table of faults is used to specify the action to be taken in response to the particular fault. This action [is] initiated by the Health Monitor and might include terminating an application and starting an alternative application, together with an appropriate level of reporting [13].^*

The recovery action is dependent on the system design and requirements.

20.5.7 Certifiable

Certifiability is a necessary characteristic of an RTOS utilized by safetycritical systems. If the RTOS is to be installed in an aircraft, it will need to satisfy the objectives of DO-178C.^† It is worth noting that the RTOS itself is not certified; rather, it is developed to be certified as part of an aircraft, engine, or propeller.^‡ Most COTS RTOSs suitable for installation in aviation products have a certification package available to support the overall certification. The certification package contains the artifacts to show compliance with DO-178C (or DO-178B) and to support safety and certification. Some of the typical certification challenges for RTOSs are presented later in this chapter (Section 20.7).

20.5.8 Maintainable

Maintainability is a desirable characteristic for all software used in safetycritical systems, including the RTOS. Since the life of the system is likely to be quite long (possibly over 20 years), the RTOS must be maintainable (i.e., able to be modified to accommodate additional applications, equipment, hardware, etc.). The life cycle data and configuration management processes required by DO-178C support maintainability.

20.5.9 Reusable

While not a required characteristic, most RTOSs are designed to be reusable. As noted previously, the kernel is abstracted from the hardware using a BSP and device drivers. The FAA’s Advisory Circular (AC) 20-148, entitled Reusable Software Components, is typically applied to an RTOS. AC 20-148 provides FAA guidance for packaging a reusable software component (RSC) for reuse in multiple systems. Even if the project does not seek an RSC letter from the FAA, they will probably want to follow the suggestions of the AC in order to develop the RTOS component to be as reusable as possible. Reuse is further discussed in Chapter 24.

20.6.1 Multitasking

Multitasking is a method where multiple tasks, also known as processes, share a common processor. Multitasking creates the appearance that many tasks are running concurrently on a processor when, in fact, the kernel interleaves (for a single core processor) their execution using a scheduling algorithm. When the processor stops executing one task and starts executing another task, this is called a context switch. When context switches occur frequently enough, it appears that tasks are running in parallel. Each seemingly independent program (task) has its own context, which is the processor environment and system resources that the task sees each time it is scheduled to run by the kernel.

20.6.2 Guaranteed and Deterministic Schedulability

Meeting deadlines is one of the most fundamental requirements of an RTOS. For safety-critical systems, the scheduling and timely completion of multiple tasks must be deterministic. For RTOSs used in advanced avionics (e.g., IMA systems), two kinds of schedulability are normally desired:^* (1) scheduling between partitions and (2) scheduling within partitions. Each is discussed here.

20.6.3 Deterministic Intertask Communication

Since only one task can be run at a time (for single core processor), there must be mechanisms for tasks to communicate with one another. For many RTOSs, queues and messages provide a means for intertask communication; this approach helps to avoid the situation where a task reads a segment of memory while another is writing to it. There are at least three reasons that intertask communication is needed [4]:

1. To synchronize or coordinate activities without data transfer. Generally such tasks are linked by events, including time-related factors, such as time delays or elapsed time. Task synchronization or task cooperation is used to synchronize the shared resources. There is some overlap between task synchronization and task coordination because task synchronized operations may be used to coordinate tasking operations. However, as soon as an interrupt is used to block and release tasks, it is no longer task coordination because the tasks are synchronized with the real-time interrupts.

2. To exchange data without synchronizing. There are times when tasks exchange information without the need for synchronization or coordination. This is often accomplished with a data store (e.g., pools or buffers) that incorporates mutual exclusion to ensure data are not corrupted.

3. To exchange data at carefully synchronized times. This is the scenario where tasks wait for events and use data associated with those events. For example, task synchronization may be achieved by suspending or halting tasks until the required conditions are met.

20.6.4 Reliable Memory Management

RTOSs support memory allocation and memory mapping and take action when a task uses memory. Most processors include an on-chip memory management unit (MMU) that allows software threads to run in hardwareprotected address space [14]. The MMU is responsible for handling accesses to memory. MMU functionality typically includes virtual addresses to physical addresses translation, memory protection, cache control, and bus arbitration. Since the MMU is COTS functionality provided with the processor and the integrity of the MMU is unknown, the MMU typically requires some special attention during the certification effort. Generally, the accuracy of the MMU’s functionality, as well as the overall processor functionality, is verified through the detailed testing of the RTOS and its supporting software (e.g., BSP). Some of the common memory issues (such as memory leakage, fragmented memory, and memory coherency) to avoid are discussed later.

20.6.5 Interrupt Processing

Real-time systems usually respond to external events using interrupts through interrupt service routines (ISRs). The RTOS normally saves the context of the interrupted task to return after the interrupt is processed. The interrupt processing can have a significant impact on the system performance. Generally, interrupt processing does the following [15]:

• Suspends the active task.

• Saves the task-related data that will be needed when resuming the task.

• Transfers control to the appropriate ISR.

• Performs some processing in the ISR to determine necessary action.

• Retrieves and saves critical (incoming) data associated with the interrupt.

• Sets required device-specific (output) values.

• Clears the interrupt hardware so the next interrupt can be recognized.

• Transfers control to the next task, as determined by the scheduler.

In order to prevent race conditions (two tasks attempting to change the same data without coordination), RTOSs sometimes disable interrupts while accessing or manipulating internal (critical) operating system data structures. The maximum time that an RTOS disables interrupts is referred to as the interrupt latency. Worst-case interrupt latency times should include “all software overhead that must be endured before the actual ISR is executed” [16]. There is typically a trade-off between interrupt latency, throughput, and processor utilization.^* This should be factored in when determining worstcase performance [17]. A key to meeting performance is to have low interrupt latency [18].

Some RTOSs reduce interrupt latency through a technique called work deferral. If an ISR causes other RTOS work to be scheduled during an interrupt, the work may be saved on a work queue and invoked later. This reduces the times of critical regions and makes the system more responsive; however, it adds complexity when calculating the worst-case execution time.

20.6.6 Hook Functions

Many RTOSs include what is referred to as hook functions (or callback functions). A hook function allows a developer to associate application code to a particular function within the RTOS. The hook is executed by the RTOS function (sometimes with elevated priority and access to RTOS resources). These hooks can be used to extend the RTOS for specific user needs, particularly if the proprietary RTOS source code is not available. Hook functions allow customization without modifying the RTOS source code and inadvertently introducing a defect. Hook functions can allow the RTOS user to perform some actions before or after the RTOS responds to some event without the overhead of a separate task creation. Oftentimes, hook functions are used to assist with debugging during development. They may be deactivated or disabled in the final product. Obviously, hook functions must be handled carefully in safety-critical systems because they have the ability to modify the behavior of the RTOS itself [19].

20.6.7 Robustness Checking

An RTOS should be designed to protect itself against certain user errors. Examples of built-in robustness checks include validating parameters passed through the API by an application making a system call, ensuring that a task priority is within the permitted range of the RTOS, or ensuring that a semaphore operation works only on a semaphore object. Robustness checking is complex and verification of the robustness features may require special testing techniques [20].

20.6.8 File System

File system is a way of managing data storage.^† Similar to the file system in a desktop environment, the RTOS file system manages and hides the details of the various forms of data storage on the hardware. The file system provides the ability to open, close, read, write, and delete files and directories.

The implementation is unique to the type of storage media (such as random access memory (RAM), flash memory, erasable programmable read-only memory (EPROM), or network-based media). The file system allows multiple partitions to access the storage media. The RTOS kernel or its supporting library implements the file system to manage the low-level details of the media for the partitions that use it. Avionics applications often use a file system to store and retrieve data. For example, flight management systems and terrain awareness systems may use a file system to access their databases [13].

20.6.9 Robust Partitioning

Many IMA RTOSs support robust partitioning. The definition of robust partitioning was included earlier (in Section 20.2). DO-297 section 2.3.3 explains the following:

The objective of robust partitioning is to provide an equivalent level of functional isolation and independence as a federated system implementation (i.e., applications individually residing on separate Line Replaceable Units (LRU)). This means robust partitioning supports the cooperative coexistence of applications using shared resources, while assuring that any attempted unauthorized or unintended interaction is detected and mitigated. The platform robust partitioning protection mechanisms are independent of any hosted applications, that is, applications can not alter the partitioning protection provided by the platform [11].

The RTOS plays a key role in implementing the robust partitioning—to ensure that the shared resources of time, memory, and I/O are protected. Partitioning is described in more detail in Chapter 21.

20.7.1 Technical Issues to Consider

20.7.2 Certification Issues to Consider

This section identifies some of the common certification-related scenarios or issues that are encountered when using an RTOS in a safety-critical aviation system.

20.8.1 ARINC 653 Overview

ARINC 653, Avionics Application Software Standard Interface, is a three-part standard that is about three inches thick when printed double-sided. Only a high-level overview is presented here. ARINC 653 specifies the APEX interface between applications and the underlying run-time system. It provides an API standard for a robustly partitioned operating system but allows flexibility for implementing the RTOS.

Paul Prisaznuk explains two key benefits of the ARINC 653 standard ized RTOS interface. First, it provides a clear interface boundary for the avionics software development. The avionics software applications and the underlying core software can be developed independently, allowing concurrent development of the RTOS and the applications that use the RTOS. Additionally, the same applications may be portable to other ARINC 653 compliant platforms. Second, the ARINC 653 RTOS interface definition enables the underlying core software and the hardware platform to evolve independent of the software applications that will be hosted on them [13].

The APEX API defines the following functionality for an RTOS: (1) sending and receiving data to/from other software applications or networked systems; (2) managing resources like time, memory, I/O, and displays; (3) handling errors; (4) managing files; and (5) scheduling software tasks or processes.

There are some unique things about the APEX API compared to other APIs. First, it is designed specifically for the aviation community with safety in mind. Second, it is designed for a partitioned computing environment. It includes two-tiered scheduling of applications (between partitions and within partitions) to ensure that one partition will not affect another partition. It also defines interpartition communications to allow safe communication between partitions. Third, it provides a health monitor interface that allows errors and conditions at the computing module level to be communicated to applications, as well as application level errors to be communicated and handled at the module (board) level [3]. Section 20.4.2 and Table 20.1 provide a high-level comparison of the ARINC 653 APEX features and the POSIX features.

In addition to the API, APEX provides a standardized, configurable operating environment for software applications to facilitate the abstraction of the application software from the underlying hardware. ARINC 653 defines the configuration specification and an assumed operating environment.

The basic concept of ARINC 653 is that an application is given a partition (like a container) to function in. The dimensions of the partition are defined by attributes such as memory size, processor utilization (e.g., in terms of period and duration), interpartition I/O ports and connections (communication channels), and health monitor actions. The attributes of the partition are determined by configuration data that are defined by the system integrator.

ARINC 653 contains three parts. Each part is briefly described in the following.

Part 1 defines the required services in order to meet safety needs, ensure application portability, and allow communication between partitions. Part 1 defines the following core services [3]:

• Partition management: allows applications (even with different criticality levels) to execute on the same hardware with no undue influence on one another, spatially or temporally.

• Process management and control: includes the resources needed to manage the processes within a single partition.

• Time management: allows the management of one of the most critical resources controlled by the operating system (i.e., time). In the APEX philosophy, time is independent of process or partition execution. All time values are related to the core module time and are not relative to the partition or process.

• Interpartition communication mechanisms: allow the communication of messages between two or more partitions executing either on the same hardware or on different hardware. Two paradigms are provided: queuing for variable-sized messages and sampling for fixedsize messages.

• Intrapartition communication mechanisms: allow the communication of messages between processes within the same partition without the overhead needed for global message passing.

• Health monitoring functions: monitors and reports platform and application faults and failures. It also helps isolate faults in order to prevent failures from propagating. In an IMA system the health monitor performs fault monitoring, fault containment, and fault management at both the application level and the system level.

Part 2 extends the Part 1 services to include the following [28]:

1. File system: a general-purpose, abstract method for managing data storage, as noted in Section 20.6.8.

2. Sampling port data structures: a standardized set of data structures for exchanging parametric data. These help to reduce unnecessary variability in parameter formats, thus reducing the need for custom I/O processing. These data structures also enable portability of applications and improve efficiency of the core software.

3. Multiple module schedules: extend the single static module sched ule in Part 1 to allow multiple schedules to be defined in the configuration table.

4. Logbook system: used to store messages. It retains the stored data after a power failure, so the data can be recovered when power is restored to the module. Each logbook is accessible by only one partition, and the logbook content and status are not altered by partition reset.

5. Sampling port extensions: extend Part 1 basic services for sampling ports with the following services:

   1. READ_UPDATED_SAMPLING_MESSAGE

   2. GET_SAMPLING_PORT_CURRENT_STATUS

   3. READ_SAMPLING_MESSAGE_CONDITIONAL

6. Support access port (SAP): a special kind of queuing port that allows access to addressing information when sending and receiving messages.

7. Name service: a companion to the SAP services. It allows a partition to retrieve an address based on a name and to retrieve a name based on an address.

8. Memory blocks: provide a means for a partition to access blocks of memory within the module’s memory space. Access privileges for the partition are defined in the configuration tables. Partitions can be granted read-only or read-write access to a memory block.

Part 3 is a conformity test specification. It describes test assertions and responses necessary to demonstrate conformity to the required services software interface defined in Part 1. This specification is intended to be used to evaluate ARINC 653 compliance.

Most RTOSs comply with parts of ARINC 653 Part 1 and Part 2 but not all of them. At this time, Part 3 is not required for certification, since the APIs are tested as part of DO-178B or DO-178C compliance. It may be used in the future by potential RTOS customers to evaluate RTOS functionality and to confirm ARINC 653 compliance. Additionally, if the ARINC 653 becomes administered by an independent standards body, the conformity testing will become a valuable measure of adherence to the standard.

ARINC 653 is updated on a regular basis to address the needs of the aviation community; therefore, it’s important to confirm the version of ARINC 653 being used, as well as the specific services implemented.

20.8.2 Tool Support

Significant tool support is necessary in order to successfully integrate and verify the installed RTOS and to analyze the real-time applications that use the RTOS. An RTOS is usually supported with an integrated development environment. Gerardo Garcia writes: “The development environment has an enormous impact on the quality and speed of development as well as the project’s overall success” [18].

Tools are provided to support code development and analysis. Code developmenttoolsincludean editor, assembler, compiler, debugger, browser, etc. Toolsto support run-time analysis include a debugger, coverage analyzer, performance monitor, etc. “The debugging capabilities of your real-time software development tools can mean the difference between creating a successful control system and spiraling into an endless search for elusive bugs” [18]. Debug tools (such as application profilers, memory analysis tools, and execution tracing tools) help to optimize the real-time applications [18].

Tools are also provided to evaluate the RTOS behavior and application performance. RTOS-oriented tools include tools to analyze timing behavior of tasks and ISRs, effects caused by task/task and task/ISR interactions (such as synchronization and preemption), problems related to resource protection features (e.g., priority inversion and deadlocks), and overheads and delays due to intertask communication [4].

Additionally, tools are often provided to help with RTOS configuration. Configuration tools help to configure memory, partitioning constraints, communication mechanism (e.g., buffers and ports), I/O devices, health monitoring parameters, etc. For ARINC 653 compliant platforms, many deployment and implementation details are defined in the configuration tables. Some RTOS or platform developers provide tools to support the configuration; however, this is an area that is still evolving. Horváth et al. claim that despite the complexity of ARINC 653 configurations, current tools are only available for the very low-level design. Tools are lacking at the higher levels to capture configuration process, validate configuration design constraints, record design decisions, trace the configuration data to the requirements, etc. “As a result, verification of configuration tables is a tedious activity” [29].

20.8.3 Open Source RTOSs

An open source RTOS is one that has the source code publicly available, free of charge, for use and/or modification from its original design. Such RTOSs are normally created as a collaborative effort in which programmers improve the code and share the changes within the community. There are a number of open source RTOSs available, such as Linux, which has drawn considerable attention. However, to date I know of no open source RTOS that has the supporting DO-178C data available to support certification. Additionally, the code is regularly updated—normally without attention to safety impact. If one were to use an open source RTOS in a safety-critical system, one would probably either need to implement architectural mitigation (such as wrappers) to limit the impact of the RTOS or reverse engineer the DO-178C life cycle data using a defined code baseline. Some government-funded research is being performed to investigate if it’s possible to reap the benefits of open source and the vast toolset available, while still meeting the safety and certification requirements.

Serge Goiffon and Pierre Gaufillet performed a research study considering ARINC 653 and Linux. Their paper points out the Linux is not ready for DO-178B (and now DO-178C) compliance for the following reasons: no development and verification plans exist, the development environment is heterogeneous and complex (distributed over Internet, multiplatform, etc.), there are no universal development standards (requirements, design, or code standards) used, and little-to-no design documentation exists [8]. The paper also identified some steps that are needed to address DO-178B^* certification, including reverse engineering the missing data, the addition of ARINC 653 partition scheduling, and APEX API compliance [8]. Getting an open source RTOS ready for use in a safety-critical application that requires DO-178C would be a major undertaking.

20.8.4 Multicore Processors, Virtualization, and Hypervisors

Many avionics organizations are considering the feasibility of multicore processors and the use of virtualization and hypervisor technology. Virtualization provides a software environment in which programs (including entire operating systems) can run as if on bare hardware, when in reality they are not running on the hardware but on a layer between called a virtual machine. A virtual machine is basically an isolated duplicate of the real machine. A software layer provides the virtual machine environment which is normally called a virtual machine monitor (VMM) or a hypervisor. The VMM has the following essential characteristics [30]:

• It provides an environment that appears to be identical to the original machine.

• Programs running in this environment only have minor decreases in speed.

• The VMM completely controls the system resources.

Virtualization has gained popularity in the mainstream computing community and is now starting to be offered with COTS RTOSs. It isolates operating systems, applications, devices, and data from each another while running on the same hardware platform. A hypervisor is used to provide virtualization and protection services. In order to tune performance, the size of the hypervisor is relatively small [30].

If virtualization or hypervisor technology is used, DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, should be considered. The related techniques portion of DO-332 could apply to such technology.

At this time, the use of multicore processors, virtualization, and hypervisors are being considered for installation in aircraft. However, to my knowledge none have been approved for installation in a commercial civil aircraft. Manufacturers and certification authorities are currently performing investigations, identifying the issues, and working to resolve them. I have no doubt that such technology will be used on commercial aircraft in the not-too-distant future.

20.8.5 Security

Many RTOSs are required to meet both safety and security standards, particularly when the RTOS is used in military aviation applications. For the security domain, the Common Criteria^* is applied. The Common Criteria has seven evaluation assurance levels (EALs), with EAL 7 being the highest. For RTOSs that are used in safety and security domains, both DO-178C and the Common Criteria are applied.^†

20.8.6 RTOS Selection Questions

When choosing an RTOS for use in safety-critical systems, there are several aspects to evaluate. Appendix C provides three categories of questions to consider when selecting an RTOS: (1) general RTOS questions, (2) RTOS functionality questions, and (3) RTOS integration questions.