Safety Certification - Easing the Path
Meeting the Demand for COTS Safe and Secure Certification Evidence
Starting with COTS components that are targeted by the vendor for safety certification and that already have documented levels of assurance can greatly speed the development and certification effort.
RANDY KYTE AND RICK HEARN, CURTISS-WRIGHT CONTROLS EMBEDDED COMPUTING
Page 1 of 1
The demand for safety and security certification evidence for hardware and software in systems has increased dramatically in recent years. In the past, this evidence was developed individually by aerospace and defense suppliers for single programs or a progressive line of similar systems over the life of a platform. This single-purpose certification was possible because the complexity of systems was relatively low when compared to today’s deployed systems.
Today, however, the complexity of systems is far greater, and the ability of any single program or product to fund complex certification is rare. Therefore, to continue to deliver systems with far greater capabilities that also comply with a growing demand for certification, suppliers must use commercial-off-the-shelf (COTS) certification evidence from their suppliers. In the aerospace and defense avionics market this most common certification is RTCA DO-178B and EUROCAE ED-12B for software, and RTCA DO-254 and EUROCAE ED-80.
One recent development helping to grow the need for safety certification is GATM (Global Air Traffic Management), which creates a worldwide network of satellite-based communication, navigation, surveillance and air traffic management systems to enable safe air travel operations in our already crowded airspace. GATM standards were established by the Federal Aviation Administration (FAA) and the International Civil Aviation Organization (ICAO), a special agency of the United Nations, in order to keep air travel safe and effective in increasingly crowded worldwide air space. This next-generation air traffic control system will increasingly use more airborne and ground devices that will be implemented based upon augmented U.S. GPS and Russian GLONASS signals today, and European GALILEO constellations in the future as that system is fully deployed. These systems will require many components to have DO-178B, DO-254 and DO-278 safety certification guidelines, similar to DO-178B, for communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) that will allow GATM to more efficiently support growing air traffic control demands. In an expansion of these standards, many of these certified systems will be ground-based.
Another key driver in this space is the trend for the military to require military aircraft to meet certification standards in order to enable them to operate and mix with civilian and commercial aircraft in controlled national airspace (Figure 1). This trend drives requirements to include compliance with air traffic messaging systems as well as overall aircraft safety, similar to civilian aircraft operations. One major difference in certification of civilian and military aircraft is who oversees the process. While military avionics vendors are more frequently required to show adherence to DO-178B, they are not necessarily certified by the FAA, which does oversee all civil avionics certifications. Nevertheless, many military system integrators do currently use FAA and RTCA DO-178B design assurance guidelines for general design process assurance, and/or as a replacement for aging military design standards. Aircraft certification authorities often defer to the DO-178B and DO-254 guidelines as an acceptable means of compliance against the safety requirements of the overall aircraft.
Overview of Safety Certification Guidelines
DO-178B and DO-254 are not specifications but guidance documents for good software and hardware development practices. DO-178B defines software considerations in airborne systems and equipment certification, and provides guidelines for the production of software for airborne systems and equipment that performs its intended function with a level of confidence in safety that complies with airworthiness requirements. These guidelines include objectives for software life cycle processes, descriptions of activities and design considerations or achieving those objectives, and descriptions of the evidence that indicate that the objectives have been satisfied.
Originally published in 1980 by the Radio Technical Commission for Avionics (RTCA), DO-178B version A was released in 1985, followed by version B in 1992. It establishes a series of design assurance objectives and the method by which these objectives will be met. It limits the latitude of implementation for coding standards, and sets requirements for capture process and test and verification methodologies.
DO-254 is a much less mature document than DO-178B that applies the same basic design assurance principles to the design of safety-critical hardware including FPGA code (firmware) and complex COTS components such as ASICs and ASSPs.
Curtiss-Wright Safety Certifiable hardware and BSPs are designed following the design assurance process defined in RTCA DO-178B / EUROCAE ED-12B and RTCA DO-254 / EUROCAE ED-80 and defined and clarified by the certification authority / aircraft program. While a module is not officially “certified” until certified as part of a full aircraft certification, we provide the hardware and software that will satisfy the certification process at the level of the platform in which it will be integrated.
Both DO-178B and DO-254 use similar design assurance levels. Within the certification process, a module’s functions are assigned a Design Assurance Level ranging from A through E, based on the criticality to the overall system safety assessment. The safety assessment takes a system-level view in which the contribution of each system element to the overall system safety is assessed (Table1).
A subsystem cannot be certified without knowledge of the requirements of the system certification effort. The design assurance level required dictates the amount of design documents, or artifacts, that must be generated and the depth of testing that must be undertaken. The difference in the design assurance levels addresses the independent verification of the software design process, the source code compliance and source code accuracy. It also determines the test objectives, which range from Level A - MCDC (modified condition/decision), Level B - decision testing and Level C - statement coverage.
Meeting the Need
To satisfy the growing need of military avionics platforms to meet civilian certification standards, COTS vendors need to develop wide expertise in the design of COTS modules that are complemented with DO-178B and/or DO-254 certification evidence. Safety certification efforts must be focused on every aspect of developing and deploying embedded modules for system platforms that must meet safety certification requirements. To meet these needs, single board computers, DSP platforms, graphics platforms and associated products should be supported with a wide variety of safe and secure operating systems that all have safety certification artifacts available. This evidence can then be combined with certified products to complete a robust foundation for accelerating platforms into certified environments. Typically customers opt for early delivery of board support packages for immediate development and integration, and then have the appropriate certification artifacts delivered when they are entering their safety certification process.
In addition, DO-254 development support can be provided by using standard product as a prototype. It is important to work closely with customers to understand their specific certification requirements, and then develop plans to modify and/or upgrade hardware and software to support equipment safety requirements. The hardware can be adapted using DO-254 processes to support new or removed features and to create the required artifacts. The software can also be modified as required under DO-178B processes.
Part of the Larger System
The goal of these efforts is to deliver safety certification products that enable single board computers and other products to be certified as part of a larger system that meets the safety requirements demanded by civilian aircraft regulators such as the EASA and the FAA, and, in Canada, Transport Canada. Because a board-level product is not certified on its own, the vendor needs to provide the system developer with a document package or “design artifacts” that detail the design assurance processes around the particular module’s development. This package is then included by the system developer as part of a system-level certification process.
Because safety certification is always performed at the platform level, it is the COTS vendor’s role to provide hardware and software that will meet the customer’s needs for the particular certification level that they must ultimately satisfy. This certification evidence enables the customer’s subsystem to go into the platform’s next higher level of assembly, which will then undergo the safety certification process. With this certification evidence and the service history gained for an individual program, significant benefits can accrue for the next program by using a similar hardware and BSP combination, speeding both the integration and certification process on future programs.
Vendors, customers and partners must work together to identify what level of effort their particular program requires. This involves determining which documents need to be produced and what level of configuration management must go into those documents. Each safety certification project requires a PSAC/PHAC (plan for safety certification), and there are a number of plan and design documents that must accompany the safety certification document package. This document package comprises the design artifacts, requirements documents and traceability documents. In addition, the modules must be tested to a degree dependent on the required certification level. All of the resulting test artifacts must be available to the certification board for scrutiny as well as provided in the documentation package.
A high percentage of the certification evidence from earlier projects is often available for reuse in later projects. But, depending on the module features that will be used by the customer, it often becomes necessary to rewrite sections of the PHAC/PSAC, and so remove irrelevant functions and add specific tests. While the basic package itself can be reused, it is typically necessary to customize each safety certifiable effort to a greater or lesser extent. Note that with respect to Wind River operating system certification evidence, there is significant reuse, especially when the processor has not changed from previous programs. The reuse of both hardware and software certification artifacts significantly compresses time-to-market and certification.
The safety certifiable process requires close interaction with the customer, including review and approval of all essential documents. It is essential to have intimate knowledge of the next level of the platform into which the module will be integrated. To provide a turn-key certifiable board/software package to the customer there must be detailed information available about the safety requirements that will flow down from the highest levels of the platform to the level of the platform at which the module will reside
Customers can begin their safety certifiable product development quickly by leveraging COTS technology targeted at safety certified requirements, drastically cutting development time and speeding time-to-market for programs that require customization or modified COTS (MCOTS), often reducing development time by as much as 8 months. Safety certifiable development resources include an extensive library of rugged COTS intellectual property building blocks. These include COTS Continuum software IP blocks comprising BSPs, software drivers, high-performance software and middleware.
Curtiss-Wright Controls Embedded Computing