Many companies have well established processes to develop programmable devices (ASIC, PLD, FPGA hereinafter referred to as PDs) that is compliant to DO-254 [41]. This process typically depends on the availability of complete design information for the IP, e.g., requirements, code, plans, verification results, traceability matrix etc. Since this is not generally available for purchased or licensed COTS IP, avionics vendors are not able to apply these processes and therefore are not able to use any of the wide variety of COTS IP available from vendors thus 1) pushing up cost and time by developing custom IP and 2) bringing additional risk from developing “one-of-a-kind” IP that does not benefit from a wide usage base.
The make-buy decision, being essentially an economic one, is altered by the availability of COTS IP and thus design decisions that are not currently economically feasible become possible. This factor alone will help to drive down non-recurring and recurring cost and also reduce life cycle cost from the avoidance of obsolescence. The economic aspect drives the decision process on how to deal with an obsolescence event.
The only known COTS IPs that have an available DO-254 DAL A package provided are the Altera NIOS-SC processor IP, the TTECH ARINC 664 controller in Xilinx FPGAs and ARINC- 429 interface IP from BARCO and Ultra Electronics. The NIOS-SC is a relatively low end processor with limited application areas. The small market size and high cost of developing a DO-254 support package is likely to discourage IP suppliers from entering the market to any significant degree, so the availability of functions is expected to remain very low for the foreseeable future.
This section proposes how we might define selection criteria and a process for assessing COTS IP and vendors for suitability for use in certified aerospace products of all design assurance levels. Suitability here means not only that the COTS IP/PD combination performs its required functions under all the expected normal and abnormal operating conditions, but also that it has been developed within a structured and controlled process of assessed quality that is consistent with the DO-254 process-based design assurance philosophy. This process will provide high confidence that the IP is functionally correct and error free and that the target end-use equipment can be certified.
There exists the possibility that any electronic component, whether containing IP or not, will contain design errors. This possibility is recognized by the current guidance; however the current Title 14 CFR guidance also recognizes that such errors should be mitigated by system design measures such as redundancy and dissimilarity developed through the processes of ARP-4754A and ARP-4761 augmented through the process-based design assurance processes of DO-178C and DO-254.
DO-254 sets out a complete process for the specification, design, verification and documentation of complex electronic hardware, of which PD’s are an example. Currently DO-254 only applies to PD’s that are programmed with avionics manufacturer developed IP. This restriction is due to the limitations, guidance and policy imposed by the FAA [143-148] since the impracticality of applying it to COTS hardware is recognized. DO-254 also defines the supporting infrastructure that all the design activities must be accomplished within, such as quality assurance, requirements traceability, configuration management, and design and coding standards. This collection of design, verification and infrastructure documentation is collectively referred to as life cycle data. DO-254 is generic enough that user defined data formats are quite acceptable provided they meet the content requirements and are properly cross-referenced to the DO-254 hardware life cycle data item descriptions as described in section 9.3.2.
Since COTS IP is developed for wide usage in a range of applications, there are often multiple operating modes and features. When used in a particular application, some of these modes and features may never be invoked and therefore represent the hardware equivalent of dead code. Dead code can be a hazard since there are no corresponding requirements, and thus may not be tested. Guarding against erroneous invocation of dead code must be one of the objectives of verification, however this assumes that the user knows what dead code there is in the COTS IP and this may not be the case. This issue is not confined to IP; a similar concern arises for software and for electronic components and modules where modes are controlled by a configuration register or pin programming. This is a difficult problem, but some of the advanced verification techniques discussed in section 9.4.1 may be able to address this issue.
The major markets for COTS IP are in telecommunications, computers and other non-aero sectors. Here, there is no requirement to demonstrate design assurance to a certification authority such as the FAA or EASA. In these markets, cost and time to market are the principal drivers rather than safety.
Aerospace application of COTS IP is constrained by the requirement to demonstrate design assurance. In the civil aircraft market, the FAA invokes design assurance requirements through AC 20-152 [143] associated policy [148] which in turn references DO-254 as an acceptable (but not the only) means of compliance. For military equipment, similar requirements are often levied by the customer on a contract by contract basis. AC 20-152 currently restricts the application of DO-254 to PDs, largely due to the recognized impracticability of obtaining the life cycle data for COTS electronic components.
There is little experience of regulatory approval of systems that contain COTS IP and therefore there is no well-established process for doing so. Recent, but unofficial, guidance for the FAA certification-process staff in conducting DO-254 reviews of PDs is provided in draft Order 8110.CEH [147, 149] and in a more general DO-254 Job Aid [146]. These do not explicitly
mention COTS IP. In addition, CAST position papers [145] provide some additional guidance, but also does not specifically address how COTS IP should be certified.
9.3.1. A Suggested Approach to COTS IP Assurance
The demonstration of DO-254 compliance is difficult for COTS IP. The life cycle data that is required by DO-254 is not generally provided. The proposition in this section is that much of the data exists in a well-managed COTS IP vendor, but may not be organized in the way consistent with DO-254. To what extent this is true is a research question suggested in sections 9.4.1.4 and 11 . This section expands on the approach developed in [150]. The initial assumption is that high quality, well managed COTS IP vendors have an interest in developing products that are free from design errors and correctly implement the design requirements set out for the product at the start of the development program. This assumption is based on the expectation that vendors who supply large volumes will not be prepared to risk that design errors will slip through the validation and verification processes, which cause defects in the products of their customers and a corresponding loss of confidence. COTS IP vendors have a strong incentive (commercially, not safety driven) to eliminate design errors from their products, since these errors lead to costly rework, recalls and product liability penalties. They also have a broad customer and application base so that problem reports are quickly fed back to the vendor. The IEEE Draft Standard P1734 [151] is intended to provide a unified view of quality measures for IP to facilitate the use and integration of this IP in electronic systems.
There is a strong similarity between the hardware design process defined in DO-254 and the ISO- 9001 philosophy of “say what you do -- do what you say”. That is to say, avionics vendors must define their IP processes in great detail, show that these processes satisfy the objectives of DO- 254 and support the processes with a QA function to ensure they are followed and can be demonstrated to have been followed. There is, therefore, an expectation that a pre-requisite for vendors to be able to supply COTS IP of adequate quality is that they carry an ISO-9001 or equivalent approval. This approval is intended to assure that the vendor follows a well-defined and documented development process extending from requirements capture through to validation and verification, with supporting process for quality assurance, configuration management, problem reporting, and resolution. For these types of vendors there will likely be a strong correlation between vendor process and documents, and DO-254 process and life cycle data items.
The general approach proposed is to set out a discovery process to map DO-254 life cycle data items to the corresponding items of vendor data. This discovery process is a type of gap analysis in the vendor’s processes, and thus highlights the additional costs to the user of creating the missing life cycle data or developing mitigations in higher-level assemblies or software.
This process-oriented approach is based on a structured examination (through an audit) of whether the COTS IP vendor has established and followed a rigorous and structured approach to the specification, design, and verification of the COTS IP, and that it has been used in multiple applications with no unresolved problem reports outstanding. Furthermore, the process validates that the vendor operates adequate process assurance and quality assurance controls that are able to assure configuration management of the delivered product, the supporting application documents and the necessary supporting tools. That these processes are in place and operating
correctly will be verified by an independent external certification body performing periodic audits to the top-level quality certificate (e.g., ISO-9001).
The intent is to gain assurance that the necessary processes exist, are followed and are adequate rather than reviewing the artifacts of each and every COTS IP. The vendor will be expected (as they typically do) to provide minimum deliverable documentation sufficient for successful application, with references into the qualification documentation.
A suggested map of the proposed process is shown in Figure 8. The audit elements may be based on the VSIA QIP tool [152].
PROCESS DATA MAPS