DN Staff

February 8, 2011

7 Min Read
Important Operating System Characteristics for Safe and Secure Applications

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

Modern microprocessors and operating systems provide memoryprotection that helps developers identify and contain application faults. Inavionics systems, operating systems also provide time partitioning so thatmultiple applications can execute on a single CPU. Standards such as ARINC 653have been published thatdefine services an operating system shall provide when used in an environmentwith multiple applications. Additionally, developers use RTCA DO-178B and, inEurope, EUROCAE ED-12B as guidance documents to ensure their software complieswith safety requirements. For applications with security requirements, the ISO15408 standard is used for certification. The following paragraphs detail these standards and the operating systemcharacteristics essential in deploying these kinds of systems.

Important Operating System Characteristics for Safe and Secure Applications

Important Operating System Characteristics for Safe and Secure Applications_A



RTCA DO-178B and DO-178C

Software used in avionics systems is generally certifiedto meet requirements of RTCA DO-178B. RTCA Inc. developed RTCA DO-178B as aguidance document that recognizes the various degrees to which softwarefunctions may impact safety. DO-178B was published in 1992, and the newestversion, DO-178C, will be published in 2011. Developers who comply with DO-178Brequirements will not need to make anychanges to comply with the upcomingDO-178C revision. However, DO-178C extendsthe utility of DO-178B and fully embraces requirements for certificationof object-oriented software, formal methods of verification, model-based designand qualification of tools.

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

Important Operating System Characteristics for Safe and Secure Applications

Important Operating System Characteristics for Safe and Secure Applications_B


One of the key aspects of DO-178B is the notion of fullyverifying software requirements. This means software developers need to exploreall the defined behavior of the software, which includes verification of theunderlying operating system and board support package (BSP). Airborneapplications, such as display systems, flight control systems and navigationequipment, are considered to be the most safety critical; and here is where operatingsystem functionality plays a key role of potentially providing the ability toexpose and contain faults. This means a lot of robustness testing, analysis andverification are needed to ensure that fault containment is guaranteed under awide range of error conditions and system states.

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

Integrated Modular Avionics

Integrated Modular Avionics (IMA) is an architecture thatsupports one or more applications, potentially at varying levels of DO-178Bcertification, on a single computing platform enabled by a time and spacepartitioned operating system. Some of the benefits of an IMA architectureinclude reduced weight, improved modularity, increased reusability, and thepotential to support multiple software teams and suppliers. If an IMAarchitecture uses mixed DO-178B software levels, the verification scrutinyincreases because an uncertified application may share virtual and physical resourceswith highly critical applications. The operating system needs to be highlyrobust to ensure that temporal, spatial and resource partitioning requirementsare met. A graphic of an IMA design is given in Figure 1.

Important Operating System Characteristics for Safe and Secure Applications

Important Operating System Characteristics for Safe and Secure Applications_C



Click here for a larger version


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

ARINC 653

ARINC 653 (titled Avionics Application Standard SoftwareInterface) is a standard that defines the services that an IMA operating systemshould provide to applications and supports the concepts of modularity,reusability, and portability of both applications and operating systems. Mostcommercial and military aircraft produced by Boeing and Airbus are now designedusing IMA, demonstrating that modern computing platforms can meet stringentsafety requirements and have multiple suppliers provide software that operateson a shared computing platform. Moreover, IMA is now being extended to meet notonly safety requirements but security requirements, as well.

Avionics and ISO 15408 Security

Most often one thinks of avionics and security solely interms of military aviation (e.g., a military transponder or communicationradio). Consider that airborne communication, navigation and collisionavoidance systems today often rely on information from remote sources makingthem vulnerable to unauthorized external influences that can affect both safetyand security. The need for both safety and security pairs requirements for RTCADO-178B with requirements from the Common Criteria. The Common Criteria, alsoknown as ISO 15408, is a framework that is used to address securityrequirements in information technology products.

The evaluation of security software through the Common Criteriadefines "evaluation assurance levels" (EAL 1-7) that indicate the process rigorassociated 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 dependsupon the security threats to the system and its software. An example of anavionics system that requires both safety and security approvals is a globalpositioning system (GPS) receiver for military applications. There may bespecial modes of operation where software in the GPS receiver may processclassified information. Historically, these special functions would beaccomplished using software on separate microprocessors so no classified informationwould be shared outside of that processor.

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

The functions are partitioned into virtual containers, andcommunication between these functions is handled by the separation kernel (asmall but verifiable time and space partitioned operating system). In thisexample, three levels of classification are depicted Top Secret, Secret andUnclassified functions that would require Common Criteria evaluation anywhereto EAL 6 or 7. The Separation kernel not only provides hardware MMUpartitioning but also controls information flow, time partitioning and damagelimitation.

The evolution of softwaredesign in airborne applications has led to the use of IMA architectures to meetsafety and security requirements. Software applications such as displaysystems, flight control systems and navigation functions can be designed toshare hardware resources such as the CPU, memory, and hardware interfacesthrough the use of a time and space partitioned operating system. Standardssuch as ARINC 653 and RTCA DO-178B, RTCA DO-178C and ISO 15408 are used tobalance challenging operating system requirements and safety and securitycertification requirements. The operating systems used in IMA architecturesmust support robust time and space partitioning, as well as fault containmentand isolation. Rigorous analyses and tests are required to show compliance withDO-178B and Common Criteria requirements for security.

Joe Wlad is senior director, Aerospace & Defense forWind River.

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



Sign up for the Design News Daily newsletter.

You May Also Like