Given its complexity and the critical applications for which it is designed, embedded avionics software must undergo a rigorous approval and testing process before it can be approved as airworthy.

The complexity of aerospace software makes it impossible to exhaustively – or even simply – test it and declare it safe for operation onboard an aircraft that will operate in domestic airspace. Instead, commercial avionics software must go through a well-defined development process, focused on design assurance, which includes a rigorous test regimen.

The development assurance process is defined by guidance material (RTCA/DO-178 and SAE ARP4761/4754 documents) that has been approved by certification authorities. Working groups composed of many of the leading aerospace companies, research branches, universities, specialty groups, and industry stakeholders work toward consensus-based guidance material to define and evolve the necessary safety standards. When considering what goes on an aircraft, it’s important to understand that individual electronics components do not receive safety certification. Only engines, propellers, and the aircraft itself are actually certified aeronautical products. Software is approved for a given installation for a piece of hardware as part of a certification program; if approved, the software is considered ready for installation on a product that will be certified.

In the case of a mission computer, to receive approval from the FAA, the electronics hardware must generally be designed and approved to the DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) standard and to RTCA/DO-160 (Environmental Conditions and Test Procedures for Airborne Equipment). The software that runs on the mission computer must be designed and approved to DO-178C (Software Considerations in Airborne Systems and Equipment Certification). For embedded systems, these documents are key for system designers who evaluate the hardware components, operating systems, and applications that they will use in their safety-certifiable systems.

One of the first steps to getting software approved as safety-certifiable is establishing an understanding of its criticality. A safety analysis of the software is performed through the cooperation of the software, systems, and safety development teams that identifies what function the software performs and ascertains the consequences of anomalous behavior of the software. The result is a determination of the Design Assurance Level (DAL) for the software item. For example, software for a single-board computer (SBC) designed for use in a flight control computer (Table 1) must be developed to DAL A, the highest level of criticality, due to the consequences of unintended behavior of the software. Similarly, software for a video capture and processing card providing the graphics in a primary flight display system would normally need to be demonstrably certifiable to DAL A.

Generally, determining the appropriate DAL for an electronics system is the responsibility of safety engineers who examine the functionality of the aircraft and its system and subsystems. While it would be an easy choice to require that all software meets the highest, or DAL A, level, it is not always desirable to specify the highest-level software in every use case. That’s because the cost of development and testing rises as the criticality level of the system rises. Basically, a precise safety analysis will justify a specific DAL level for the software needed for that system design, that aircraft, and the required functions.

Promulgating standards

SAE International is a global association responsible for developing engineering standards for a variety of industries. Its Aerospace Recommended Practice (ARP) guidelines play a critical role in the aircraft design and safety-certification process. One of SAE’s most prominent sets of standards is ARP4754A, which details Guidelines for Development of Civil Aircraft and Systems. While SAE ARP4754 is the top-level guidance standard in the industry for systems engineering, the safety processes and engineering used in aerospace are defined in SAE ARP4761. This document provides complete guidance for safety engineers: for example, on how to perform a functional hazardous assessment, how to perform a preliminary and final systems safety assessments, and a Failure Modes, Effects and Criticality Analysis (FMECA).

ARP4754, on the other hand, in conjunction with ARP4761, assists systems engineers in the architecting of a system and the allocation of functions to specific software and hardware items. Whatever an OEM applicant submits to the certification authority must be backed up by a safety analysis. The certification authorities have the prerogative to review any of the system’s technical data and then assess whether they agree with the DAL level determinations made by the OEM. In the event they don’t agree with the DAL designation, they may make the OEM provide further justification or raise the DAL for that application. The process is not subjective. The OEM presents scientific and quantitative data about the software’s functionality and the consequences of its failure to the certification authority and also takes into account industry precedents.

For any avionics system, each of the engineering domains –systems, software, and programmable hardware – is responsible for ensuring that the system is fully verified and tested. For the systems side of the application, engineers must perform requirements-based testing to ensure that all of the specified system functions and requirements are fully verified. The same applies for software and hardware domains. Thorough testing of each of these domains requires very particular knowledge of the system and item designs.

DO-178C safety-certifiable software must undergo a rigorous process that generates a significant amount of data (also referred to as software lifecycle data). One component of that data is the actual executable code that will run on the system. Supporting data include plans, requirements, design, architecture, source code, test procedures, reports and analysis. All of the data accompanying the executable software code is known as the data artifact package (or lifecycle data) for the particular software and hardware combination that comprises the application.

Historically, the hardware and software for a new safety-certifiable application was custom-built from the ground up, a process that could take years and millions of dollars to complete. Today, it is now possible to select commercial off-the-shelf (COTS) safety-certifiable hardware components, with the associated executable software and all of the software and hardware life cycle data needed to demonstrate to the certification authority that the software and hardware is indeed safe.

It’s not unusual for customers to be surprised at the cost of the process of developing DO-254 hardware and DO-178C software. What’s more, learning the process iteratively, as certification audits are failed, can be even more costly. While a system developer’s engineering group may have the necessary skills to develop the executable code, it’s rare that they will have experience with the safety certification process. Certification experience is essential for successfully executing efficient software certification programs. If that expertise is not available internally, outside firms can provide it.

Familiarity with the testing required for safety-certifiable applications is an important skillset. That’s because testing can be a fairly significant portion of the certification process, ranging from 30% to 40% of the overall cost, depending on the system’s DAL level. The software developer may choose to conduct all the testing, or testing can be outsourced. It can be cost-effective to engage an outside firm with the required test and certification experience. Mannarino Systems & Software has considerable experience with the entire software approval/certification process and in guiding customers through such programs and tests.

The testing process for DO-178C (Figure 1) software will always involve a level of hardware integration, since software cannot be verified on its own. Software must be approved on the target hardware. Depending on the application, system-level testing will be required; verification at software level, AEH level (ie, programmable hardware), and potentially at a system level may be performed if the customer needs that type of support.

Who is testing?

A smaller firm such as Mannarino can often perform all of the required testing, or a subset of the testing, for software, programmable hardware, and some system programs, depending on the customer’s needs. For safety-certifiable software programs, it is possible for some outside firms to handle the complete program, from planning to approval. Provided with the system specification, these firms can develop and collect all the lifecycle data, including the executable code, all the test procedures, and all the results generated from testing.

In addition, some firms are actually able to provide software/hardware certification/approval services. MANNARINO, for example, is a Design Assurance Organization under Transport Canada, the first service provider worldwide to receive the delegation for both DO-178 software and DO-254 hardware. With such a designation authority, a firm can actually approve software and hardware on behalf of the certification authority.

There is a growing trend for offshoring some of the test work. Low-level testing houses, which may offer competitive hourly rates, may not be able to deliver the quality of work required to satisfy the rigorous DO-178B process. It can also take additional time and work to get an offshore testing provider up to speed.

Today, customers are seeking more turnkey solutions and support for their safety-certifiable applications. Through the use of COTS hardware and an experienced outside software development and testing services supplier, customers can cost-effectively speed the deployment of their hardware and low-level software. An outside expert with experience in avionics system integration, safety analysis, systems engineering, operating system software, and board support package software, can offload the customer, enabling them to focus their valuable resources on the development of their application software.

Consider a system developer with a requirement for a Full Authority Digital Engine Control (FADEC) software with programmable DO-254 hardware. The system integrator can either attempt to build the hardware or obtain safety certifiable modules from an external supplier. An example is Curtiss-Wright’s Power Architecture-based VPX3-152 3U OpenVPX SBC module designed to meet DO-254 DAL A requirements.

If the COTS vendor and software supplier (MANNARINO) work in concert, they can provide the system developer with a complete safety-certifiable DO-254 hardware and DO-178C operating system and board support package, along with the needed data artifact package. In addition, MANNARINO can provide guidance through hurdles of the DO-178 & DO-254 approval processes. The customer is then free to put their energies into developing the application software that is their unique added value.

John Mannarino is president and founder of Mannarino Systems and Software (St. Laurent, Québec, Canada).

MANNARINO

www.mss.ca

[email protected]

Twitter @mannarino_ss

FB @mannarinosystemsandsoftwareinc