Published in Embedded Computing Design.
Authored by John Mannarino, Mannarino Systems and Software.
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 identify what function the software performs and ascertain 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 video capture and processing card providing the graphics in a primary flight display system would normally need to be demonstrably certifiable to DAL A.
Read the full article here.