The promise of greater efficiency by using Integrated Modular Avionics (IMA) systems that reduce Space, Weight and Power (SWaP), is now coming to fruition. Very large, visible projects such as Boeing’s 787 Dreamliner and Airbus’ A380 are taking advantage of this more efficient strategy to integrate airframe suppliers’ systems into shared airborne compute platforms. 

The goal of IMA is to combine a number of traditional, stand-alone federated systems into integrated common platforms. This system reduction/compression increases power efficiency and reduces processor boards, support hardware and cabling, with the complementary benefit of reduced bill of materials (BOM) and number of Line Replaceable Units (LRUs), which simplifies spares management and training demands.

The most advanced IMA system to date, the Common Core System (CCS) supplied by GE Aviation for the Boeing 787 (Figure 1), is now running over 70 separate applications executing at separate safety levels. This architecture allowed Boeing to eliminate over 100 discrete LRUs on this state-of-the-art aircraft, and thus realize the savings in SWaP as well as through-life costs associated with software updates, upgrades, maintenance, overhaul and repair.

The challenge of IMA is to maintain a servicing and replacement utility like federated systems have, while providing a robust mechanism for separation of applications of different safety criticality levels. Due to the extreme high costs of software testing and re-certification, a viable IMA platform must enable an efficient, cost-effective path to meeting RTCA DO-178B and DO-254 safety certification. This can only be done with incremental software certification.

Fundamental Changes

Under a federated avionics model, the subsystem hardware and software is delivered in a single package by a single prime contractor, who is responsible for 100% of the design, implementation and testing of the device; therefore, this federated systems supplier had full control over the development of the entire subsystem. This model tied the air frame manufacturer into a particular subsystem supplier and supply chain, which limited the options for cost savings, especially when it came to upgrading functionality or adopting new technology. New functionality was often solved by introducing a new Line Replaceable Unit (LRU), which could be provided by the same manufacturer or put out to tender for procurement, both involving substantial costs.

In the federated supplier model (Figure 2), the LRU supplier for each system supported 100% of the responsibility for DO-178B and DO-254 certification of the unit. Typically, a single LRU would support one aircraft function, such as a Flight Management System; and although it could run several applications to support this function, it would be certified to a single DO-178B and/or DO-254 safety level. The LRU supplier would then take the entire system through the certification process and provide this evidence to the airframe manufacturer for inclusion in the aircraft safety case.

Incremental certification was not possible—every time a line of software code needed to change it forced, by DO-178B and/or DO-254 guidelines, a complete requalification of the entire LRU. This is true even if the LRU compute platform implemented an application partitioning strategy, usually due to control and/or data coupling between these applications and the operating environment. Any change in the board support package (BSP), real-time operating system (RTOS)/scheduler, or in the application, forced a retest of the entire LRU software stack.

New Approach: IMA

With the newer approach of IMA, the applications are separated from the base computing platform, communicating through the standard ARINC 653 API, and controlled, using a time and space scheduler, by the ARINC 653 RTOS (Figure 3). This separation enables the airframe manufacturer to potentially procure the base computing platform and applications from separate sources, picking the best-in-class supplier for each function. This IMA architecture allows a greater range of competition and flexibility for the airframer, but does increase the challenges of software engineering and systems integration, including deploying airborne units where competitors share the same compute silicon.

Shared IMA compute platforms have necessitated a dramatic shift in the way aircraft systems are developed, with new, specific roles defined for the systems integrator, platform supplier and application suppliers; these roles are defined completely under the DO-297 standard titled, “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations.” Under this model, adding more functionality to the system involves adding, or modifying, an existing software application. The challenge then becomes how that software component is designed, tested and integrated into the final system, without impacting the safety or security of other applications or for the platform itself.

Separating Responsibilities

Each of the roles has defined responsibilities for the certification of their component. The platform supplier handles the delivery and certification of the base platform (hardware and software), the application suppliers are just responsible for their application, and the systems integrator is responsible for consolidation of all the safety artifacts from these separate sources to provide an overall safety case to the customer.

As a result, the IMA approach of putting multiple separate safety-critical software applications on a single hardware platform has led to much stricter contracts between these separate components, at both the business and system levels. Although this stricter contract and separation between the components gives the systems integrator the challenge of allocating resources among all of the application suppliers, it does provide a platform that may allow each of these applications to be safely certified to a different level. IMA platforms also introduce the capability of incremental certification, where the retest of the entire platform is not required, only a test of the scope of any application change.

Incremental Certification

ARINC 653 architectural robustness per DO-178B guidelines is the key to incremental certification efficiency. Without this proven separation, ARINC 653 systems are automatically converted to very complex and unmaintainable federated platforms, and every change to the integrated platform forces a retest of the entire platform, causing an exponential increase in system testing, rendering the integrated platform not commercially viable.

Robustness, as defined under DO-178B guidelines, is a very specific proof that under all application failure conditions, a single failure in one partition will not affect other partitions. This can be a challenging endeavor to prove, and in the case of Wind River’s VxWorks 653 certification evidence, this document is over 330 pages in length, and includes testing and analysis for both the ARINC 653 RTOS provider (in this case, Wind River), and specific tests to be performed on the airframe deployment hardware.

Incremental certification only works if the hardware and software components are truly isolated, enabling the proven independence or robustness of the entire system. This separation means the software has to be developed without relying on specific hardware or other applications at build time, instead using only the computer resources provided by the base platform, through standard ARINC 653 Application Programming Interfaces (APIs). These resources would include not only the ARINC 653 APIs themselves, but provide access to hardware resources such as CPU, memory and I/O.

The first challenge of robustness is to provide access to these resources, using the ARINC 653 APIs so that applications can get access to these resources and meet their designed performance requirements. This is challenging both from a perspective of defining a strategy for sharing resources across the platform without impacting the robust partitioning, but also achieving this without reducing the performance requirements of the applications.

The second challenge is how to build, configure and deploy the application in an IMA system so that applications can readily move from one platform to another, and applications can be modified without changing or affecting either the base platform, or other applications. This is where the platform supplier has the challenge of mapping these I/Os and other system computing resources to the ARINC 653 API, as well as providing other APIs for ease of migration of other software assets (such as POSIX or VxWorks applications).

The systems integrator then has the challenge of integrating these applications onto the base platform, and making sure that the overall system still meets its performance requirements. This activity could involve a complex negotiation between these separate suppliers in order to allocate the resources efficiently. Decisions here can also impact the overall configuration of the shared computing platform and require the platform supplier to provide more CPU resources or to distribute the applications differently on the final system.

The Whole Lifecycle

Having a simple ARINC 653 application API on top of an RTOS, or having an ARINC 653 operating system that just provides time and space partitioning at the application level, is not enough. It must support an environment where not only system components are robustly separated, but also the software development lifecycle needs to be separated, fully enabling incremental certification. This is the fourth challenge and requires a more sophisticated design environment where applications can be developed and tested without relying on the existence of other applications or specific hardware.

Often there are implicit, unseen, or otherwise unknown links or coupling between applications, BSPs and drivers that nullify true application and system independence; robust partitioning requires that no control or data coupling be between partitions. Control coupling is defined as vulnerability to external access, such as overrunning allocated time slots, while data coupling includes shared data as well as stacks and processor registers. Any control or data coupling between the IMA platform components removes the possibility of DO-178B partitioning robustness, and therefore incremental certification.

From Boeing 777 to 787

Despite all the challenges, a prime example of the benefits of adopting an IMA approach is the evolution of the Boeing 777 to the 787. While the 777 had IMA for the flight management systems, the current IMA development for the 787 is running approximately 70 applications on a single avionics hardware platform, combining the navigation systems, electrical power distribution and waste management systems. This architecture has allowed Boeing to eliminate discrete LRUs and thus realize savings in SWaP and through-life costs associated with maintenance, overhaul and repair.

The longer term benefits of using an IMA approach for aircraft system design are now well-defined. Reducing SWaP by eliminating scores of separate processor units has a tremendous positive impact on the efficiency and profitability of the aircraft during its lifetime, as well as enhancing software systems’ engineering capability among the global supply chain.

A New Way of System Design

This has required a fundamental shift in the way these systems are specified, designed, implemented and tested, which has required years to implement at its highest efficiency in order to maintain the high safety levels mandated in the avionics industry. Each product generation increases the level of integration, while supporting associated increases in complexity and in certification testing. The software in the current generation of aircraft is probably the most rigorously tested software on the planet.

These changes, not just in the technology, but also in the standards, business model and certification strategies, all advance at different speeds. However, these IMA advances have made significant increases in efficiency when implemented with robust separation and incremental certification as proven by the latest-generation aircraft implementing these global IMA standards and practices.  

Wind River Systems
Alameda, CA.
(510) 748-4100.
[www.windriver.com].