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.
 |
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.
 |
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.
 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
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.
References:
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