white paper Safety-Critical Software Development for Integrated Modular Avionics Paul Parkinson Senior Systems Architect, Wind River Larry Kinnan Senior Engineering Specialist, Aerospace & Defense, Wind River Introduction Table of Contents Many avionics systems have been successfully developed using custom hardware and software. However, in recent Introduction ........................................................................1 years, the full life-cycle costs of customized systems have Application Development with Wind River’s forced original equipment manufacturers (OEMs) to consider VxWorks 653 Platform ........................................................2 the use of COTS-based systems. At the same time, there has Spatial Partitioning .........................................................2 been a noticeable migration away from federated architec- tures, where each individual subsystem performs a dedicated Temporal Partitioning .....................................................4 function toward generic computing platforms that can be Priority Inversion, Priority Inheritance, and used in multiple types of applications and, in some cases, run Priority Ceilings ..................................................................5 multiple applications concurrently. This approach, known as ARINC 653 Application Development ................................5 Integrated Modular Avionics (IMA), results in fewer subsys- tems, reduced weight, less power consumption, and less Heterogeneous Application Support .................................6 platform redundancy. A number of civil and military research System Configuration .........................................................6 programs have sought to define IMA architectures, and while Health Monitoring System and Restarts.............................7 they differ in their approaches, they share the same high- level objectives: Tools for Safety-Critical Systems Development .................8 • Common processing subsystems: These should allow Security Considerations for Networked IMA multiple applications to share and reuse the same Systems ..............................................................................8 computing resources. This results in a reduced number Safety Considerations for IMA Systems .............................9 of subsystems that need to be deployed and more efficient use of system resources, leaving space for Summary ........................................................................... 10 future expansion. References ........................................................................ 10 • Software abstraction: This should isolate the application About the Authors ............................................................ 10 not only from the underlying bus architecture but also About Wind River ............................................................. 10 from the underlying hardware architecture. This enhances portability of applications between different platforms and also enables the introduction of new hardware to replace obsolete architectures. • Maximize reuse: An IMA architecture should allow for reuse of legacy code. This reduces development time while affording the developer a method of redeploying This technical paper presents recent trends in the develop- existing applications without extensive modifications. ment of safety-critical avionics systems. It discusses the • Cost of change: An IMA architecture should reduce the emergence of Integrated Modular Avionics (IMA) architec- cost of change since it facilitates reuse and lowers retest tures and standards and the resulting impact on the develop- costs because it simplifies the impact analysis by ment of a commercial off-the-shelf (COTS) RTOS that is decoupling the constituent pieces of the platform that standards-compliant. execute on the same processor. IMA also facilitates support for applications that have The following sections consider the technical requirements ever-increasing levels of functionality, including the interac- for an integrated device software platform to support IMA tions between complex applications, such as head-up applications and show how VxWorks 653 Platform (see Figure displays, map display systems, and weather radar displays. 1), fulfils these requirements—in particular within the context of ARINC 653 application development. Although a number of IMA architectures and standards has emerged, the ACR Specification1 and ARINC Specification 6532 appear to have the widest adoption in the avionics Application Development with Wind River’s community. The ACR Specification addresses architectural VxWorks 653 Platform considerations, whereas ARINC Specification 653 defines at a The ACR Specification defines two important concepts high level an instance of a software implementation for an widely used in IMA: spatial partitioning and temporal IMA architecture. These and other IMA standards place new partitioning. demands on the software architecture, especially the RTOS implementation provided by the COTS supplier. Wind River Spatial Partitioning has specifically addressed these needs by developing the Spatial partitioning defines the isolation requirements for VxWorks 653 Platform3, which is being employed by the C-130 multiple applications running concurrently on the same Avionics Modernization Program and 767 Tanker4. Boeing has computing platform, also known as a module. In this model, chosen to use Wind River’s VxWorks 653 Platform for the applications running in an IMA partition must not be able to development of the Boeing 787 Dreamliner Common Core deprive each other of shared application resources or those System (CCS)5. Other Wind River customers, including EADS6, provided by the RTOS kernel. This is most often achieved are using the platform to develop avionics systems and through the use of different virtual memory contexts en- safety-critical applications. forced by the processor’s memory management unit (MMU). Eclipse Framework Workbench Editor Compiler System Viewer Development Suite Port Monitor CPU Monitor Qualified Partition Project Debugger Verocel AdaCore GNAT Pro Interpeak Software Partners Certification Services Ada Compiler Certifiable Stack DO178B Level A Certification Material ARINC 653 API VxWorks API POSIX API Run-Time Components COIL MPOS VxWorks 653 Virtutech Simulation Environment Hardware Partners COTS Boards, Semiconductor Architectures Training and Training and Installation Platform Customization Professional Services System Design Hardware/Software Integration Design Services Figure 1: Wind River’s VxWorks 653 Platform 2 | Safety-Critical Software Development for Integrated Modular Avionics App 1 App 2 App 3 App 4 Partition OS Partition OS Partition OS Partition OS Module OS ARINC Ports ARINC Scheduler Processor Figure 2: VxWorks 653 RTOS Architecture These contexts are referred to as partitions in ARINC 653. • The partition OS is implemented using the VxWorks Each partition contains an application with its own heap for microkernel and provides scheduling and resource dynamic memory allocation and a stack for the application’s management within a partition. Communication with the processes (the ARINC 653 term for a context of execution). module OS occurs through a private message-passing These requirements affect the design and implementation of interface to ensure robustness. The partition OS also the RTOS kernel and language run-time system. For example, provides the ARINC 653 APEX (application/executive) VxWorks 5.5 uses a shared virtual address space for applica- interfaces for use by applications. tions and provides basic support through the MMU to This architecture, which represents the virtual machine prevent accidental or malicious access to program code by approach as described in “Partitioning in Avionics Architec- errant applications, without incurring the performance tures: Requirements, Mechanisms and Assurance”7, provides overhead of a full process model. VxWorks 6.x and VxWorks a means of fulfilling the requirements of ARINC 653, while 653 provide an environment that uses the MMU to enforce providing a flexible, extensible framework not easily achieved separate contexts. with a monolithic kernel implementation or UNIX-like However, in an IMA environment, memory protection alone implementations. Within the framework, individual partitions would not prevent an errant application running in a partition are implemented using memory-protected containers into from consuming system resources, which might have a which processes, objects, and resources can be placed, with detrimental effect on an application running in another partitioning enforced by the MMU (virtual machines). Each partition. This can have serious consequences where multiple partition has its own stack and local heap, which cannot be applications of differing levels of criticality are running on the usurped by applications running in other partitions. The same processor. This problem cannot be resolved through partitions also prevent interference from errant memory the use of a full process model alone; instead it requires the accesses by applications running in other partitions. development of an RTOS that specifically addresses the Figure 2 shows the conceptual implementation of the needs of IMA. The VxWorks 653 operating system was VxWorks 653 architecture. The RTOS features the ability to designed specifically for this purpose and supports the have a single, shared partition OS library (shared read-only ARINC 653 model in the implementation