Military Embedded Systems

FACE, ARINC, DO-178C avionics standards help U.S. DoD's vision of reusable technology to take off

Story

March 12, 2013

Bernard Dion

ANSYS, Inc.

While historically single-vendor procured, today's airborne systems utilized by the U.S. DoD need to instead comply with the DoD's vision of more cost-efficient, reusable, modular, standards-based applications ready for flight in both manned and unmanned airspace. Standards such as the Future Airborne Capability Environment (FACE), ARINC 653 and 661, and DO-178C are helping the military avionics industry achieve this paradigm. Tools providing model based-design and verification capabilities can also assist.

Historically, U.S. Department of Defense (DoD) airborne systems have typically been developed for a unique set of requirements by a single vendor. This form of development has served the DoD well until recently. However, this development process has major drawbacks including long development time and lack of hardware and software reuse between various aircraft platforms, which results in a platform-unique design. The advent of significantly more complex mission equipment and electronics systems has caused an increase in the cost and schedule to integrate new hardware and software into aircraft systems. This combined with the extensive testing and airworthiness qualification requirements have begun to affect the ability of the DoD aviation community to deploy these new capabilities across the DoD projects. The good news, though, is that avionics standards such as the Future Airborne Capability Environment (FACE), ARINC 653 and 661, and DO-178C can enable the aviation community to provide such technological advantages to the DoD, saving time and money. Model based-design and verification tools can also help achieve the goal.

FACE provides reusability

The FACE Consortium’s FACE standard was designed as a response to the U.S. DoD aviation community’s challenges. The approach used by FACE is to develop a standard for a software computing environment designed to promote software product lines that are reusable across different air platforms[1].

Several components comprise the FACE approach to software reuse. This approach allows software-based “capabilities” to be developed as components that are compatible with other software components through defined open standards interfaces. It also provides for the reuse of software across different hardware computing environments that contain differing platform devices. This includes the use of avionics functional standards such as ARINC 653 for Integrated Modular Avionics and ARINC 661 for the design of Cockpit Display Systems (CDSs) and User Applications (UAs). FACE will also support airworthiness qualification of airborne systems such as DO-178C Levels A through E and, in addition, the Common Criteria Evaluation Assurance Level 4 (EAL 4) through Level 7 (EAL 7). Ultimately, the goal of FACE is to reduce development and integration costs and reduce time to field new avionics capabilities. The FACE Consortium is hosted by the Open Group and it includes U.S. military industry suppliers, customers, and users. It meets regularly to define a reference architecture, a set of guidelines, and a business model.

ARINC 653: Multiple application hosting

The ARINC 653 standard[2] is a specification for executive software that allows hosting several avionics applications on a single Integrated Modular Avionics (IMA) hardware platform while guaranteeing space- and time-partitioning for these critical applications. Assuming each application is certified for DO-178B/C at a given level (A through E), safety integrity of the overall avionics systems can be achieved since data integrity can be guaranteed and a sufficient time budget can be allocated to each application so that it can run in due time. ARINC 653 is a part of the ARINC 600-Series standards for Digital Aircraft and Flight Simulators.

An IMA-based methodology has several key benefits for airframers and avionics developers: It aims to minimize the number of on-board computers, resulting in lower size and weight, while enabling the use of legacy systems because components are interoperable and “plug and play.” This flexible design can be changed and optimized at a late stage during development. The standard supports incremental certification, allowing airframers to better manage the DO-178B/C certification process. The ability to achieve incremental certification is a direct benefit of the ARINC 653 partitioning mechanisms since certification can be achieved first for each application and then for the overall systems. Moreover, changing an application does not require recertification of the other applications.

Figure 1 depicts the ARINC 653/IMA use model together with a model-based methodology that relies on a SysML-based description of the applications residing on the IMA and the automatic generation of the IMA configuration tables. The top-right system view exhibits three applications that reside on the IMA platform and their communications. On this basis and on the basis of a description of the IMA platform configuration (Usage Domain), a set of IMA configuration tables can be automatically generated to configure the platform. As shown on the left side of Figure 1, each application can itself be developed by using a traditional manual coding approach or, better, by using a model-based development approach.

 

Figure 1: The ARINC 653/IMA use model and model-based technology

(Click graphic to zoom by 1.9x)


21

 

 

ARINC 661 standardizes CDSs, UA communications

ARINC 661[3] is a standard that defines the Cockpit Display System (CDS) interfaces, including communication between the CDS and the avionics UAs and communication between the CDS and the pilots. It is also a part of the ARINC 600-Series Standards for Digital Aircraft and Flight Simulators.

The ARINC 661 standard normalizes the design of an interactive CDS and the manner in which these systems communicate with UAs such as flight management systems, flight control systems, flight warning systems, and so on. It does this by using a set of 67 predefined and standardized graphical widgets, some of it changeable through pilot interaction (trackball, keyboard, tactile screens, and so on), and by standardizing the communication protocol at runtime between a UA and the CDS. Thus, ARINC 661 ensures that the full CDS interactively behaves with the avionics systems in the same manner regardless of UA developer and CDS manufacturer.

ARINC 661-compliant applications provide key benefits for airframers, CDS developers, and UA developers. With model-based development tools that support the ARINC 661 standard, aircraft manufacturers, CDS developers, and avionics UA developers can ensure ARINC 661 compliance and dramatically increase productivity while achieving the highest level of graphical quality and the safety considerations that must be obeyed when certifying these applications under DO-178B/C up to Level A.

Figure 2 depicts the ARINC 661 use model together with a model-based methodology that relies on specific tools to describe the graphical and behavioral properties of the widgets and the automatic generation of the ARINC 661 runtime server.

 

Figure 2: ARINC 661 use model and model-based technology

(Click graphic to zoom by 1.9x)


22

 

 

Graphics and logic modeling tools can be used to describe each widget that will reside in the CDS ARINC 661 runtime server. Moreover, for a given UA, the same graphical modeling tool can be used to describe how widgets are assembled on the pages pertaining to this application. From this description of the pages, the modeling tool is automatically generating Definition Files that are loaded into the CDS when the aircraft starts.

Understanding DO-178C

DO-178C should be approved by the U.S. Congress this year. Therefore, understanding the key differences in the standard as compared to DO-178B and how to best meet the certification requirements in the most cost- and time-effective manner possible will affect all avionics developers in the immediate future. The standard defines the objectives to be achieved for software certification of airborne systems. The overall structure of the DO-178C standard and related documents is depicted in Figure 3.

 

Figure 3: The DO-178C documents structure

(Click graphic to zoom by 1.8x)


23

 

 

The core DO-178C standard is an evolution of the existing DO-178B standard. It defines a number of objectives regarding the processes that have to be followed to certify software at a given level (A through E). It comes with technology-specific documents pertaining to Object-Oriented Technology and Related Techniques (OO/RT), Model-Based Development and Verification (MBDV), and Formal Methods (FM) that complement the objectives to be achieved when a specific technology is used by the applicant (the aircraft manufacturer working in relation with its suppliers). In this discussion, we should put the emphasis on the Model-Based Development and Verification Supplement, DO-331[5], and the Tools Qualification document (DO-330)[6]. The rules and objectives described in these two documents allow efficient use of the methods described in the previous two sections. These methods are model-based (DO-331), and they can bring the most benefits to their users when they can rely on qualified tools (DO-330).

Standards, model-based design tools meet avionics challenge

Creating avionics applications that comply with FACE, ARINC 653 and 661, and DO-178C presents unique challenges for systems and software engineers. These applications must be designed in an effective manner to meet the requirements of these emerging standards, while taking into consideration development and certification costs.

Thus, to meet emerging avionics standards, avionics developers will have to rethink their systems and software development strategies. The time to do that is now. These standards are dictating all future development strategies, and by utilizing tools that encourage reuse and reduce development and certification costs, the U.S. DoD, the FACE standard, and other emerging standards are leading the way into the future of aircraft development strategies.

Traditional tools relying mostly on manual coding methods will not allow meeting the challenges since they lead to high development and verification costs and they result in software code that is highly dependent on the initial technology and thus cannot be reused.

Meanwhile, model-based design and verification tools facilitate reusability and lower development and certification and therefore have unique advantages over non-model-based tools. They improve communication among system/software teams, customer, suppliers, and certification authorities because model-based design is used as a common graphical language in the development process. Model-based design tools also improve long-term maintainability, reuse, and retrofit of applications, as proposed by FACE, because they can support hardware, software, and platform independence. Also, developers can more easily maintain variations, making changes when needed in a graphical fashion, rather than having to maintain code. The SCADE product family is a good example of this type of model-based development tool. It supports both the ARINC 653 and ARINC 661 standards and automatic and DO-178B/C-certified code generation from software models.

References

[1] Future Airborne Capability Environment (FACE) Reference Architecture, the Open Group, 2012.

[2] ARINC 653, Avionics Application Software Standard Interface Software, ARINC, 2010.

[3] ARINC 661 Specification 661-4, Cockpit Display System Interfaces to User Systems, ARINC, 2010.

[4] DO-178C, Software Considerations in Airborne Systems and Equipment Certification, RTCA, 2011.

[5] DO-331, Model-Based Development and Verification, Supplement to DO-178C and DO-278A, RTCA, 2011.

[6] DO-330, Software Tool Qualification Considerations, RTCA, 2011.

Bernard Dion is Chief Technical Officer at Esterel Technologies, which he cofounded in 1999. He received an E. Engr. degree from Ecole Centrale de Lyon and a Ph.D. in Computer Sciences from the University of Wisconsin. He then started at Honeywell Bull in the Ada language team. As a professor, he created a graduate school in systems and software engineering. He has been the European secretary of the tools qualification subgroup within the committee that created DO-178C.

Esterel Technologies, a subsidiary of ANSYS, Inc. +33 1 30 68 61 60 www.esterel-technologies.com

 

Featured Companies

ANSYS, Inc.

2600 ANSYS Drive
Canonsburg, Pennsylvania 15317