Rockwell Collins achieves DO-178 certification using traceability analysis
Software that is used in a commercial aircraft system must be certified against the avionics safety standard, DO-178. This standard is oriented around an interrelated set of software life cycle processes falling into three main categories: the software planning process, the software development processes (requirements, design, coding, integration) and the integral processes (verification, configuration management, quality assurance, and certification liaison). For each of these processes, DO-178 defines the associated objectives, the activities that are needed to meet the objectives, and the artifacts (software life cycle data) serving as evidence that the activities have been performed satisfactorily.
System certification entails demonstrating that the relevant objectives have been met. The specific objectives for any system component depend on the component’s Design Assurance Level (DAL), which in turn reflects the criticality of the component in terms of overall aircraft safety. The highest software DAL, Level A, applies when a failure would lead to a catastrophic failure condition for the aircraft and thus significant loss of human life. For DAL A, close to 70 different objectives must be met.
The software components in the Integrated Display System (IDS) developed by Rockwell Collins are DAL A. This system, featuring Rockwell Collins EFIS/EICAS Interface Unit (EIU-7001), includes many of the advanced features found on the Boeing 787,such as an electronic checklist with cursor control panel, navigation performance scales and vertical situation displays. The verification process objectives for DAL A software require a demonstration of complete source code coverage: test cases derived from the software requirements must fully exercise the code structure, and Modified Condition/Decision Coverage (MC/DC) must be achieved. However, a potential issue arises if some object code is not traceable to the source code – for example, if the compiler expands a source construct into a complex code sequence involving conditional instructions. In such a case the requirements-based tests might not be sufficient: although the source code has been fully covered, some branches in the generated code might not be exercised. If, because of a compiler error, the generated code is incorrect, then such a defect might not be detected by the requirements-based tests and would remain latent in the delivered application.
This situation was anticipated in the DO-178 guidance. The following structural coverage analysis activity (§6.4.4.2b) for Level A software is specified when the compiler generates object code that is not traceable to source code: “additional verification should be performed on the object code to establish the correctness of such generated code sequences”.
There are several ways to deal with this issue, and some guidelines are suggested by the Certification Authorities Software Team Position Paper CAST-12. The AdaCore approach, consistent with these guidelines, entails selecting representative code samples for each Ada feature permitted by the customer’s coding standard, compiling these samples to identify instances of non-traceable object code (for example, array slice assignment), and then performing additional verification on the non-traceable code. This additional verification consists of defining requirements for the added code, and composing and running test cases to check that the requirements are met.
AdaCore has performed this kind of analysis in the past, and it has been used as a part of the certification artifacts to show source to object code traceability for avionics systems certified to DAL A. Based on this successful previous experience, Rockwell Collins selected AdaCore to conduct an analogous traceability analysis for the IDS Program. The IDS program used the GNAT Pro High-Integrity Edition cross-compiler, hosted on Windows and targeted to the PowerPC-ELF. The GNAT Pro High-Integrity Edition is a full Ada compiler, but it also includes several profiles (restricted versions of the run-time libraries) that can simplify the certification effort and reduce the size of the executable.
The EIU-7001 program used the Zero FootPrint (ZFP) profile, which eliminates tasking, exception propagation, constructs that would require implicit dynamic code, type finalization, string names for enumeration literals, and several other features. Additionally, several features permitted by the ZFP profile but not needed in Rockwell’s application were omitted in order to simplify the traceability analysis. These include local allocators (i.e., allocators within a subprogram), dynamic dispatch in Object-Oriented Programming, dependence on the predefined I/O packages, access values designating subprograms, functions returning unconstrained values, and exception handlers. Although the resulting subset lacked dynamic features such as tasking and exception handling, it did include support for dynamic allocation at the library level and was sufficiently expressive to allow Rockwell to successfully implement their application.
The traceability analysis package met Rockwell Collins’ certification requirements and reduced their certification effort. Since AdaCore was able to use its existing infrastructure and methodology to efficiently conduct such an analysis, it allowed Rockwell engineers to devote their energies to other aspects of the certification process. Most importantly the certification authorities accepted the traceability analysis as compliant with the DO-178B structural coverage analysis objectives.
The need for additional verification on non-traceable object code has sometimes been referred to as a “hidden objective” in DO-178B: it needs to be conducted at Level A, but is not explicit in the tables that define the objectives. This has been addressed in DO-178C, where it appears explicitly. AdaCore’s approach that was used for DO-178B will be equally applicable to DO-178C.
For more information, visit AdaCore online at http://www.adacore.com.
Resources
RTCA /EUROCAE DO-178B/ED-12B – Software Considerations in Airborne Systems and Equipment Certification, December 1992.
RTCA /EUROCAE DO-178C/ED-12C – Software Considerations in Airborne Systems and Equipment Certification, December 2011.
www.rockwellcollins.com/sitecore/content/Data/News/2011_Cal_Yr/CS/FY11CSNR52-787_Certification.aspx
Kelly Hayhurst, Dan Veerhusen, John Chilenski, Leanna Rierson. A Practical Tutorial on Modified Condition / Decision Coverage; NASA / TM-2001-210876.
Certification Authorities Software Team (CAST) Position Paper CAST-12, Guidelines for Approving Source Code to Object Code Traceability; December 2002.
www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-12.pdf
Software-related image courtesy Shutterstock.
