Design News is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Important Operating System Characteristics for Safe and Secure Applications

Important Operating System Characteristics for Safe and Secure Applications

Modern operating systems are the foundation of most sophisticated computing platforms. Operating systems manage the computing resources (such as memory, input/output and the central processing unit itself) so that applications can properly employ these resources to perform their required functions. When computing platforms are used in applications where safety or security is paramount, special requirements may need to be addressed.

Modern microprocessors and operating systems provide memory protection that helps developers identify and contain application faults. In avionics systems, operating systems also provide time partitioning so that multiple applications can execute on a single CPU. Standards such as ARINC 653 have been published that define services an operating system shall provide when used in an environment with multiple applications. Additionally, developers use RTCA DO-178B and, in Europe, EUROCAE ED-12B as guidance documents to ensure their software complies with safety requirements. For applications with security requirements, the ISO 15408 standard is used for certification. The following paragraphs detail these standards and the operating system characteristics essential in deploying these kinds of systems.

Important Operating System Characteristics for Safe and Secure Applications

RTCA DO-178B and DO-178C

Software used in avionics systems is generally certified to meet requirements of RTCA DO-178B. RTCA Inc. developed RTCA DO-178B as a guidance document that recognizes the various degrees to which software functions may impact safety. DO-178B was published in 1992, and the newest version, DO-178C, will be published in 2011. Developers who comply with DO-178B requirements will not need to make any changes to comply with the upcomingDO-178C revision. However, DO-178C extends the utility of DO-178B and fully embraces requirements for certification of object-oriented software, formal methods of verification, model-based design and qualification of tools.

Both DO-178B and DO-178C define five levels of software criticality, which relates to how latent software defects can contribute to a failure condition. The effort required to certify software to DO-178B or DO-178C depends on the software criticality level and hence the number of objectives required. Table 1 shows the failure conditions, with the relevant DO-178B software levels, and the number of objectives required to satisfy the requirements of each level. Level E software is not considered safety-critical and has no objectives assigned.

Important Operating System Characteristics for Safe and Secure Applications

One of the key aspects of DO-178B is the notion of fully verifying software requirements. This means software developers need to explore all the defined behavior of the software, which includes verification of the underlying operating system and board support package (BSP). Airborne applications, such as display systems, flight control systems and navigation equipment, are considered to be the most safety critical; and here is where operating system functionality plays a key role of potentially providing the ability to expose and contain faults. This means a lot of robustness testing, analysis and verification are needed to ensure that fault containment is guaranteed under a wide range of error conditions and system states.

Developers need to compose a detailed set of tests and analyses to demonstrate that handling of priorities, message queues, and resources such as memory and input/output devices are correct. Additionally, time and space partitioning provided by the OS will need to be verified, including timing analyses (a time budget outline of kernel services and critical sections of code), a partitioning analysis (addressing software control coupling, data coupling and interactions between partitioned components), and a stack analysis (showing that a stack overflow cannot occur under various conditions and inputs), among other things.

Integrated Modular Avionics

Integrated Modular Avionics (IMA) is an architecture that supports one or more applications, potentially at varying levels of DO-178B certification, on a single computing platform enabled by a time and space partitioned operating system. Some of the benefits of an IMA architecture include reduced weight, improved modularity, increased reusability, and the potential to support multiple software teams and suppliers. If an IMA architecture uses mixed DO-178B software levels, the verification scrutiny increases because an uncertified application may share virtual and physical resources with highly critical applications. The operating system needs to be highly robust to ensure that temporal, spatial and resource partitioning requirements are met. A graphic of an IMA design is given in Figure 1.

Important Operating System Characteristics for Safe and Secure Applications

Click here for a larger version

In Figure 1 the IMA architecture shows an ARINC 653 OS that runs in supervisor mode and provides hardware memory management unit (MMU) partitioning of memory, time and I/O resources. The ARINC 653 operating environment provides applications with a full set of operating system services and the basic functionality needed to support the underlying hardware. Within each partition, the applications execute in user mode completely isolated from other applications. Figure 1 shows three applications at different levels of DO-178B criticality. The ARINC 653 Application Executive (APEX) enables each application to work as if it has exclusive use of the platform, when in fact it is sharing the platform with other applications.


ARINC 653 (titled Avionics Application Standard Software Interface) is a standard that defines the services that an IMA operating system should provide to applications and supports the concepts of modularity, reusability, and portability of both applications and operating systems. Most commercial and military aircraft produced by Boeing and Airbus are now designed using IMA, demonstrating that modern computing platforms can meet stringent safety requirements and have multiple suppliers provide software that operates on a shared computing platform. Moreover, IMA is now being extended to meet not only safety requirements but security requirements, as well.

Avionics and ISO 15408 Security

Most often one thinks of avionics and security solely in terms of military aviation (e.g., a military transponder or communication radio). Consider that airborne communication, navigation and collision avoidance systems today often rely on information from remote sources making them vulnerable to unauthorized external influences that can affect both safety and security. The need for both safety and security pairs requirements for RTCA DO-178B with requirements from the Common Criteria. The Common Criteria, also known as ISO 15408, is a framework that is used to address security requirements in information technology products.

The evaluation of security software through the Common Criteria defines "evaluation assurance levels" (EAL 1-7) that indicate the process rigor associated with the development of an information technology product:

  • EAL 1: Functionally tested
  • EAL 2: Structurally tested
  • EAL 3: Methodically tested and checked
  • EAL 4: Methodically designed, tested and reviewed
  • EAL 5: Semiformally designed and tested
  • EAL 6: Semiformally verified, designed and tested
  • EAL 7: Formally verified, designed and tested

The actual EAL required for a given software application depends upon the security threats to the system and its software. An example of an avionics system that requires both safety and security approvals is a global positioning system (GPS) receiver for military applications. There may be special modes of operation where software in the GPS receiver may process classified information. Historically, these special functions would be accomplished using software on separate microprocessors so no classified information would be shared outside of that processor.

Both classified and unclassified functions can be executed on a single processor using a separation kernel with a similar time and space scheduling architecture to ARINC 653 as depicted in Figure 2.

The functions are partitioned into virtual containers, and communication between these functions is handled by the separation kernel (a small but verifiable time and space partitioned operating system). In this example, three levels of classification are depicted Top Secret, Secret and Unclassified functions that would require Common Criteria evaluation anywhere to EAL 6 or 7. The Separation kernel not only provides hardware MMU partitioning but also controls information flow, time partitioning and damage limitation.

The evolution of software design in airborne applications has led to the use of IMA architectures to meet safety and security requirements. Software applications such as display systems, flight control systems and navigation functions can be designed to share hardware resources such as the CPU, memory, and hardware interfaces through the use of a time and space partitioned operating system. Standards such as ARINC 653 and RTCA DO-178B, RTCA DO-178C and ISO 15408 are used to balance challenging operating system requirements and safety and security certification requirements. The operating systems used in IMA architectures must support robust time and space partitioning, as well as fault containment and isolation. Rigorous analyses and tests are required to show compliance with DO-178B and Common Criteria requirements for security.

Joe Wlad is senior director, Aerospace & Defense for Wind River.

1. J. Wlad Perspectives: Security and the Separation Kernel Avionics Magazine, April 1, 2007
2. RTCA. RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, RTCA, Inc. 1 December 1992.
3. ARINC. ARINC 653-1 Avionics Application Software Standard Interface. October 2003

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.