分享

Modular Approach Eases Avionics Certification...

 t涂鸦 2012-07-15

Reinventing the wheel every time is acostly and time-consuming approach to avionics design. The ability to doincremental certification is a key reason why an integrated modular avionics(IMA) system is so powerful and efficient.

CHIP DOWNING, WIND RIVER

 

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

The goal of IMA is to combine a number oftraditional, stand-alone federated systems into integrated common platforms.This system reduction/compression increases power efficiency and reducesprocessor boards, support hardware and cabling, with the complementary benefitof 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, theCommon Core System (CCS) supplied by GE Aviation for the Boeing 787 (Figure 1),is now running over 70 separate applications executing at separate safetylevels. This architecture allowed Boeing to eliminate over 100 discrete LRUs onthis state-of-the-art aircraft, and thus realize the savings in SWaP as well asthrough-life costs associated with software updates, upgrades, maintenance,overhaul and repair.

Figure 1
The most advanced Integrated Modular Avionics (IMA) system to date is theCommon Core System (CCS) supplied by GE Aviation for the Boeing 787. It runsover 70 separate applications executing at separate safety levels. Thisarchitecture allowed Boeing to eliminate over 100 discrete LRUs on thisstate-of-the-art aircraft.

The challenge of IMA is to maintain aservicing and replacement utility like federated systems have, while providinga robust mechanism for separation of applications of different safetycriticality levels. Due to the extreme high costs of software testing andre-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, thesubsystem hardware and software is delivered in a single package by a singleprime contractor, who is responsible for 100% of the design, implementation andtesting of the device; therefore, this federated systems supplier had fullcontrol over the development of the entire subsystem. This model tied the airframe manufacturer into a particular subsystem supplier and supply chain, whichlimited the options for cost savings, especially when it came to upgradingfunctionality or adopting new technology. New functionality was often solved byintroducing a new Line Replaceable Unit (LRU), which could be provided by thesame manufacturer or put out to tender for procurement, both involvingsubstantial costs.

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

Figure 2
In the federated supplier model the LRU supplier for each system supports 100%of the responsibility for DO-178B and DO-254 certification of the unit.Although an LRU could run several applications, it is certified to a singleDO-178B and/or DO-254 safety level.

 

 

Incremental certification was notpossible—every time a line of software code needed to change it forced, by DO-178Band/or DO-254 guidelines, a complete requalification of the entire LRU. This istrue even if the LRU compute platform implemented an application partitioningstrategy, usually due to control and/or data coupling between theseapplications and the operating environment. Any change in the board supportpackage (BSP), real-time operating system (RTOS)/scheduler, or in theapplication, forced a retest of the entire LRU software stack.

 

New Approach: IMA

With the newer approach of IMA, theapplications are separated from the base computing platform, communicatingthrough the standard ARINC 653 API, and controlled, using a time and spacescheduler, by the ARINC 653 RTOS (Figure 3). This separation enables theairframe manufacturer to potentially procure the base computing platform andapplications from separate sources, picking the best-in-class supplier for eachfunction. This IMA architecture allows a greater range of competition andflexibility for the airframer, but does increase the challenges of software engineeringand systems integration, including deploying airborne units where competitorsshare the same compute silicon.

Figure 3
Using the newer approach of Integrated Modular Avionics (IMA), the applicationsare separated from the base computing platform, communicating through thestandard ARINC 653 API, and controlled, using a time and space scheduler, bythe ARINC 653 RTOS.

 

Shared IMA compute platforms havenecessitated a dramatic shift in the way aircraft systems are developed, withnew, specific roles defined for the systems integrator, platform supplier andapplication suppliers; these roles are defined completely under the DO-297standard titled, “Integrated Modular Avionics (IMA) Development Guidance andCertification Considerations.” Under this model, adding more functionality tothe system involves adding, or modifying, an existing software application. Thechallenge then becomes how that software component is designed, tested andintegrated into the final system, without impacting the safety or security ofother applications or for the platform itself.

Separating Responsibilities

Each of the roles has definedresponsibilities for the certification of their component. The platformsupplier handles the delivery and certification of the base platform (hardwareand software), the application suppliers are just responsible for theirapplication, and the systems integrator is responsible for consolidation of allthe safety artifacts from these separate sources to provide an overall safetycase to the customer.

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

Incremental Certification

ARINC 653 architectural robustness perDO-178B guidelines is the key to incremental certification efficiency. Withoutthis proven separation, ARINC 653 systems are automatically converted to verycomplex and unmaintainable federated platforms, and every change to the integratedplatform forces a retest of the entire platform, causing an exponentialincrease in system testing, rendering the integrated platform not commerciallyviable.

Robustness, as defined under DO-178Bguidelines, is a very specific proof that under all application failureconditions, 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’sVxWorks 653 certification evidence, this document is over 330 pages in length,and includes testing and analysis for both the ARINC 653 RTOS provider (in thiscase, Wind River), and specific tests to be performed on the airframedeployment hardware.

Incremental certification only works if thehardware and software components are truly isolated, enabling the provenindependence or robustness of the entire system. This separation means thesoftware has to be developed without relying on specific hardware or otherapplications at build time, instead using only the computer resources providedby the base platform, through standard ARINC 653 Application ProgrammingInterfaces (APIs). These resources would include not only the ARINC 653 APIsthemselves, but provide access to hardware resources such as CPU, memory andI/O.

The first challenge of robustness is toprovide access to these resources, using the ARINC 653 APIs so thatapplications can get access to these resources and meet their designedperformance requirements. This is challenging both from a perspective ofdefining a strategy for sharing resources across the platform without impactingthe robust partitioning, but also achieving this without reducing theperformance requirements of the applications.

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

The systems integrator then has thechallenge of integrating these applications onto the base platform, and makingsure that the overall system still meets its performance requirements. Thisactivity could involve a complex negotiation between these separate suppliersin order to allocate the resources efficiently. Decisions here can also impactthe overall configuration of the shared computing platform and require theplatform supplier to provide more CPU resources or to distribute theapplications differently on the final system.

The Whole Lifecycle

Having a simple ARINC 653 application APIon top of an RTOS, or having an ARINC 653 operating system that just providestime and space partitioning at the application level, is not enough. It mustsupport an environment where not only system components are robustly separated,but also the software development lifecycle needs to be separated, fullyenabling incremental certification. This is the fourth challenge and requires amore sophisticated design environment where applications can be developed andtested without relying on the existence of other applications or specifichardware.

Often there are implicit, unseen, orotherwise unknown links or coupling between applications, BSPs and drivers thatnullify true application and system independence; robust partitioning requiresthat no control or data coupling be between partitions. Control coupling isdefined as vulnerability to external access, such as overrunning allocated timeslots, while data coupling includes shared data as well as stacks and processorregisters. Any control or data coupling between the IMA platform componentsremoves the possibility of DO-178B partitioning robustness, and thereforeincremental certification.

From Boeing 777 to 787

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

The longer term benefits of using an IMAapproach for aircraft system design are now well-defined. Reducing SWaP byeliminating scores of separate processor units has a tremendous positive impacton the efficiency and profitability of the aircraft during its lifetime, aswell as enhancing software systems’ engineering capability among the globalsupply chain.

A New Way of System Design

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

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

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多