Safety-critical software continues to make its way into military embedded application environments beyond avionics flight systems, such as weapons systems and communications equipment. Often, all of these systems operate together as a single “system-of-systems.” This makes it increasingly important that each of them meets the most stringent and rigorous requirements for safety-criticality, since, if one fails, there could be failures or vulnerabilities in the entire system as a whole.
However, as safety-critical software has proliferated with the multitude of embedded operating systems (OSs) and other software solutions available, so has its complexity. Traditionally, embedded devices have been hardware-centric, and the embedded software has consisted of relatively simple, flat address space kernels carefully designed to optimize performance and minimize the memory footprint. The new embedded system-of-systems, however, is characterized by growing software complexity, so much so that embedded software now dominates development costs and schedules.
As a result, the old way of developing software from scratch for each embedded project is giving way to the need to reuse software from previous development efforts wherever possible, in order to reduce the time, costs and risks involved in redevelopment efforts.
To help reduce the complexities, expense and time needed to get avionics systems to market, the Federal Aviation Administration (FAA) has developed robust guidelines and methodologies for software reuse. Reusable software component (RSC) approval promises to have far-reaching implications and create a major shift in the embedded software industry. Safety-critical design engineers will not only have more software choices available than ever before, but will also be able to reuse software code in multiple safety-critical systems.
RSC FAA Approval: A Standards-Based Approach
Reusable components are not a new concept. In fact, many other industries have long benefited from reusing interchangeable parts. However, the reuse of embedded software represents a significant issue in aviation, since the FAA must approve all software as safe.
In the whole certification process of an embedded OS or other software solution in avionics, for example, each system must meet the rigorous DO-178B standard that defines safety-critical software guidelines for the development of airborne systems. DO-178B certification comprises five levels of safety-criticality, with Level A requiring the most demanding certification process. Until the formidable specifications of this standard are met, a safety-critical computing system literally never gets off the ground.
Currently, any time a systems integrator wants to integrate its DO-178B Level A-certified software component into a new hardware system, the entire hardware/software configuration has to be certified together again. Moreover, that certification is only valid for that particular hardware/software box in that particular configuration. Integrators that try to use the same OS for newer platforms cannot take advantage of that OS’s existing certification: instead, certification has to be done all over again for each hardware/software system they build.
The FAA realized that there was an opportunity to improve the certification process so that system integrators could reuse their existing software, reduce time-to-market and take credit for their previous development efforts.
Thus, the concept of RSC approval for software components was born and guidelines were provided for reusing software data, if properly planned and packaged, with minimal rework from one project to another. These guidelines were released as part of the FAA advisory circular (AC) AC 20-148 for airborne systems and equipment. AC 20-148 shows one acceptable way for RSC developers, integrators and applicants to gain FAA acceptance of components that may make up a part of a system’s software application. It lists software libraries, input and output data files, OSs and communication protocols, among others, as potential components for RSC approval.
RSC approval is the first standards-based approach for software reuse, so that systems integrators can consider portions of the safety-critical software code and supporting DO-178B artifacts—which include software, requirements documentation, design documentation, requirements coverage, test sweeps, verification procedures and test results—for reuse in other embedded system designs with other software components. The RSC developer provides integrators with guidance on how to use those components and take credit for the different objectives of DO-178B. Essentially, an integrator can take partial credit for some objectives and full credit for others. This helps to significantly decrease the time required for software development, modification and maintenance across various design projects and to minimize the overall costs of avionics equipment.
To date, only one RSC Acceptance Letter has been issued: a Level C approval for a vocoder algorithm. However, achieving RSC approval for a DO-178B Level A-compliant embedded OS takes substantially more effort and entails more objectives that need to be met. No DO-178B Level A RTOS has received RSC approval, although many OS vendors are vying to be the first, including LynuxWorks. When an RSC Acceptance Letter is issued for a DO-178B Level A embedded OS, a tremendous industry milestone will have been achieved.
Integrators and the FAA
At a time when engineering labs are charged to do more with less and still meet demanding cost and time schedules, software developers and avionics manufacturers find it all the more desirable to have reusable software components that can be integrated and reused in many other aircraft computers. Software reuse is an important aspect of controlling and reducing software costs and improving quality.
The level of rigor required for achieving RSC approval is more stringent than certification for DO-178B Level A compliance alone. The average time needed to write and generate DO-178B Level A software is three to four hours per line of code. To achieve RSC approval for an OS that has 90,000 lines of reusable code would obviously require considerable time and investment.
With RSC approval, the software components identified as reusable are already approved by the FAA. The OS provider chooses software components that are target hardware-independent, such as the kernel and libraries, which can constitute as much as 65% of the code. From that perspective, RSC approval provides system integrators and developers a tremendous head start when a significant amount of the OS is already approved (Figure 1).
Not only does RSC approval benefit system integrators and developers, but it also benefits the FAA. One of the motivations behind RSC approval was to eliminate duplicate efforts by individual FAA aircraft certification offices (ACOs) certifying a technical standard order (TSO) data package, or hardware/software configuration. Once the data package for software components identified as reusable has received RSC approval by one ACO, it can then be reused and accepted without another ACO being required to review the data all over again.
All the Work is Done for System Integrators
The time, cost and effort to achieve RSC approval for a DO-178B Level A embedded OS is no small feat (Figure 2). An embedded OS vendor must go through a rigorous process with the FAA to demonstrate how it intends to achieve RSC approval for DO-178B Level A, as outlined in the vendor’s Plan for Software Aspects of Certification (PSAC).
As part of this PSAC, the OS vendor identifies the hardware-independent components of the OS that are reusable for supported processor architectures, irrespective of which target hardware they run on. These components will not need any modifications. Once the PSAC is approved by the FAA, the embedded OS vendor starts its RSC development effort. Artifacts must be created for each of the identified reusable components.
Essentially, the entire review of DO-178B Level A compliance is already done. The end result is a DO-178B Level A data package for the RSC components and an RSC data sheet. The RSC data sheet, as outlined in the AC 20-148, includes the final assumptions, target processors on which the RSC can be used and the remaining integrator activities required to achieve full credit for the DO-178B objectives.
RSC approval for an embedded OS is neither evaluated nor issued by the FAA in isolation. Instead, it is done in partnership with a systems integrator, or “initial applicant,” which helps the OS vendor get an RSC Acceptance Letter as part of an approval for type certificates (TCs), supplemental type certificates (STCs), amended type certificates (ATCs), amended supplemental type certificates (ASTCs) and technical standard order (TSO) authorizations. The FAA reviews the RSC data package to ensure that, in fact, it is reusable and has been validated across more than one particular hardware platform. In addition, the FAA verifies that all the objectives of DO-178B Level A and the guidance provided by AC 20-148 have been satisfied.
Once the RSC Acceptance Letter is issued, all that each “follow-on” systems integrator needs to do is plug the approved data package into its environment, and provide the remaining components—the board support package (BSP) and chip support package (CSP)—following the defined application programming interface (API) guidance.
For example, the LynxOS-178 is already certified to DO-178B Level A. LynuxWorks plans to achieve RSC approval for the kernel and the POSIX libraries (Figure 3). The system integrator need only provide the board support software for the custom target hardware, and execute the test suites provided with the RSC data package on the system integrator’s environment.
As soon as the systems integrator achieves the same results that were identified as part of the approved data package, it receives full credit for the approval associated with all of the reusable components. The integrator doesn’t have to develop requirements, develop design, show traceability of the requirement of the design, write verification cases, show traceability of requirements to verification cases, or do any Modified Code Decision Coverage (MCDC) testing, that is, the structural coverage required for Level A. With RSC approval, all of this is already done. Integrators can simply take credit for DO-178B Level A objectives that already have been fully met—without having to submit all of the life-cycle data to the FAA for review—and can be confident that they will meet the standards mandated for commercial avionics.
Economic incentives and software complexity have made it desirable to develop reusable software components that can be integrated into a number of safety-critical systems. As the most complex part of an OS, the effort to generate a DO-178B Level A kernel and artifacts is significantly higher than the effort for a BSP. Therefore, an approved and certified kernel provides tremendous savings in effort, cost and time.
With RSC approval for a DO-178B Level A OS, software reuse will soon be a reality for safety-critical embedded systems used in avionics systems. Software reuse will fundamentally change the future of embedded software development by improving developer productivity, controlling software quality, reducing product schedule risks and minimizing overall development costs: all things of great importance to any systems engineering organization.
LynuxWorks Inc.
San Jose, CA.
(408) 979-3900.
[www.lynuxworks.com].
