Because aircraft avionics software includes safety-critical aspects, the military continues to embrace the DO-178B/C guidelines used for commercial aircraft systems.
JOHN BLEVINS, DIRECTOR, SOFTWARE TOOLS DEVELOPMENT, LYNUXWORKS
Safety-critical avionics software has been evolving for decades, providing increased functionality while becoming more complex. In response, regulatory authorities and commercial avionics manufacturers co-authored the RTCA/DO-178 guidelines for developing avionics software. Developers of commercial avionics software must demonstrate compliance with DO-178’s guidelines to assure that their software can safely perform its intended function. More recently, the FAA has issued further guidance for so-called reusable software components (RSCs as defined in AC20-148). This guidance requires activities beyond those of DO-178, but the advantage is that certification evidence created under an RSC during one certification can be re-used on subsequent certifications, resulting in considerable cost and schedule savings.
Complexity Drives the Need
The current version of these guidelines is known as DO-178B/C and is generally considered one of the strictest software standards in existence today. All commercial avionics software in the U.S. is required to comply with the DO-178B/C standard. The guidelines defined in DO-178B/C are intended to ascertain that avionics developers employ a degree of process rigor during software development and verification to ensure that the software will perform its intended function with an appropriate level of confidence in safety.
Note that while DO-178B/C was created to guide commercial avionics software development, developers of military avionics software have adopted it in recent years (Figure 1). However, nowadays military developers rarely adopt DO-178B/C in its entirety, often due to cost, effort and schedule, nor do they undergo the rigorous compliance audits conducted by the FAA or other certification authorities.
Figure 1
While DO-178B/C was created to guide commercial avionics software development, developers of military avionics software have adopted it in recent years.
It’s All About Process
While DO-178B/C does not define a process per se, it does define guidelines that a compliant process must meet. DO-178B/C defines five major software life cycle processes:
Planning: During this process, the software plans for the following four life cycle processes are created. This planning must occur in the context of system/software considerations, especially those related to safety. More on this issue later.
Development: At this stage, software requirements, design and code are created and the resulting software is integrated with target hardware in preparation for testing.
Verification: Artifacts created in the development process are assessed to detect and report any errors (error removal is a development activity).
Software Configuration Management (SCM): This process spans both development and verification and ensures that adequate problem reporting, change control and configuration control are in force.
Software Quality Assurance (SQA): This last process spans development, verification and configuration management to ensure adequate quality controls are enforced.
The Software Planning Process
The primary objective of the planning process is the creation of plans for the other four life cycle processes. These plans define the processes to be used, procedures and standards to be followed, and tools/environments to be used (e.g., compilers/debuggers, testing tools, configuration management tools).
These plans must be created in the context of system/software considerations, especially those related to safety. DO-178B/C defines five levels of avionics “failure conditions” to which software might contribute (catastrophic, hazardous, major, minor and no effect) and five corresponding levels of software “design assurance” (levels A, B, C, D and E). For example, modern flight control software typically requires Level A design assurance, which imposes the most stringent process rigor, since a fault therein could be catastrophic (i.e., loss of aircraft and loss of life). Conversely, a maintenance function might require only Level D design assurance and very low process rigor, since a fault would have minimal effect on the safe operation of the aircraft. The five levels of software design assurance are directly mapped to the five “criticality” levels of avionics failure conditions. The key difference between Levels A and B is that Level A requires a more thorough degree of testing.
The Software Development Process
The primary objective of the development process is creation of the software requirements, architecture, design and code in compliance with standards identified during the planning process. The development process also covers loading the resulting executable object code onto the target system for hardware/software integration and testing. Requirements are often written at two levels.
During the requirements phase, engineers develop high-level software requirements based on system requirements that have been allocated to software, safety requirements and system architecture. At the design phase, engineers develop low-level software requirements based on high-level requirements and develop software architecture (design constraints). Low-level requirements provide a level of detail such that code can be directly implemented from them with no further information.
Traceability Requirements
In general, high-level requirements must trace to the system-level constructs from which they were developed, and low-level requirements must trace to the high-level requirements from which they were developed. However, derived requirements may be identified that do not trace anywhere-such as command and control software might have a derived low-level requirement for a priority queue. That said, all derived high-level requirements must be fed back to the system safety assessment to ensure that they don’t introduce safety issues. Similarly, all derived low-level requirements must be analyzed to ensure that they don’t compromise any high-level requirements.
During the coding phase, engineers develop software that implements the low-level requirements in conformance with the software architecture. All code must trace to the low-level requirements from which it’s developed. In general, traceability for lower-level design assurance software (Levels C and D) can be relatively coarse-grained-an entire software module may trace to a handful of requirements. Conversely, traceability for higher-level design assurance software (Levels A and B) is generally expected to be much more finer-grained-a few lines of code may trace to one or more requirements. Under design assurance Levels A and B there can be no code that does not trace to the requirements.
During the integration phase, engineers create executable object code from the software developed during the coding phase. They then load the executable object code onto the target hardware in preparation for hardware/software integration and testing. The compilers used to create the executable object code must undergo a process called “object code analysis,” which verifies that the generated code is correct for the constructs in the source code.
The Software Verification Process
During this lifecycle process, the main objective is the detection and reporting of any errors in the artifacts created during development. All errors are fed back to the development phase to be corrected. Note: verification does not simply mean testing, it also includes review and analysis.
During the testing phase, engineers develop and execute test cases (test descriptions) and test procedures (executable test code) intended to demonstrate that the software satisfies its requirements, and to demonstrate, to a high degree of confidence, that all errors that could lead to unacceptable failure conditions have been removed. DO-178B/C emphasizes requirements-based testing (black box), wherein tests are developed from the software’s high- and low-level requirements. In limited cases, unit level tests may be needed to drive hard to reach paths in a given piece of code (white box).
Tests should include: normal range cases-such as testing a tan( ) function with a value of zero-and robustness cases-testing a tan( ) function with a value of 90, hardware/software integration cases and software/software integration cases.
In general, tests should be run on the target hardware intended for use in the aircraft being developed. However, DO-178B/C allows that constraint to be relaxed under appropriate circumstances, especially in the case of low-level design assurance software. During the review phase, engineers assess the outputs of the development and verification processes for accuracy, completeness, consistency, verifiability, traceability and conformance to standards. Such reviews are typically guided by a checklist or similar aid to ensure a robust result.
During the analysis phase, engineers inspect three key outputs of the development and verification processes. First, test results are analyzed for correctness. The results of any failed tests are fed back to the development process for correction. Second, test cases and procedures are analyzed to ensure that every requirement traces to one or more tests and that every test traces to one or more requirements. Third, the structural coverage generated during testing is analyzed to ensure an appropriate level of testing completeness.
Any code that is determined to be “dead code”-unreachable during execution-must be removed as part of the development process. The LynxOS-178 RTOS (Figure 2) is available with artifacts for all levels of FAA certification requirements, helping with the certification of the complete system including the RTOS.
Figure 2
The LynxOS-178 RTOS is available with artifacts for all levels of FAA certification requirements, helping with the certification of the complete system including the RTOS.
The SCM Process and SQA Process
The SCM process is active throughout development and verification. Its major objectives include control configuration items (CIs) and to establish controlled configurations of the software from which executable object code can be derived. A means must be established to reliably replicate executable object code. Any problems must be recorded and assessed, and any associated changes must be made in a controlled manner. And finally, formal procedures need to be established for approving/disapproving the inclusion of changes into a new baseline.
The SQA process also is active throughout development and verification. Its major objectives include ensuring that software development and verification activities comply with approved software plans and standards. Software life cycle transition criteria must also be satisfied. Before releasing the final executable object code, ensure that all software life cycle processes are complete, that the executable object code is controlled, and that it can be regenerated (if needed).
Using a RTOS that has been developed using the DO-178B/C process can be very beneficial to the integration and certification of that RTOS in the final system with the avionics application. At LynuxWorks, the DO-178B/C development process used for the LynxOS-178 operating system follows the strict SQA process used in developing avionics applications, making system integration and subsequent certification much easier for avionics developers.
Reusable Software Components (RSCs)
Driven by a desire to reduce cost and schedule, avionics manufacturers have begun to design and deploy reusable/portable hardware platforms and application software. This approach is especially attractive in markets such as commercial avionics, which require costly development, verification and certification activities. Clearly, if a manufacturer can incur the cost of developing and verifying a software component once, and if they can then reuse that software and the associated certification evidence at a drastically reduced cost, that manufacturer gains an advantage over any competitors that lack that capability.
Consequently, the FAA has developed guidelines for so-called RSCs. This guidance requires some activities beyond those of DO-178B/C, but the advantage is that all certification evidence created under the RSC during one certification can be reused, as is, on subsequent certifications. This reduces the time, effort and risk involved with a certification, and is particularly attractive if it is applied to embedded software, as this can be shared across many customers and systems. The LynxOS-178 operating system from LynuxWorks is the only RTOS to have been accepted as an RSC.
DO-178B/C has best been described as a set of overlapping safety nets intended to catch software errors and prevent them from finding their way onto aircrafts. It helps software developers achieve this goal within a flexible framework that allows for varying degrees of process rigor during software development and verification, thereby striking a practical balance between safety and cost/effort.