• / Home
• / Mag
• / EASA-AMC-20-152A-COTS-IP-Design-Assurance

The traditional guidance for using COTS IPs in the development of AEH devices has been to require DO-254 compliant life-cycle data, as discussed in EASA Certification Memorandum for AEH (Ref 3.). Some vendor would therefore market their IPs with “certification kits”. However, this has been limited to aviation specific products, and more generic functions have no such certification kit. Another possibility has been, for soft IPs (i.e., those sold as HDL code to be implemented on the device by the user), to use reverse-engineering for creating conceptual design and requirements and for performing the DO-254 required verification activities. However, this is costly and complex to achieve.

In July 2020, EASA published AMC 20-152A, new Acceptable Means of Compliance for Airborne Electronic Hardware (Ref 1.). This guidance, which is harmonised with FAA AC 20-152A (not yet published at the time of writing this article), includes a chapter dedicated to the use of COTS IPs. 
 

These objectives are rather high-level and seem to provide a large flexibility in the way they can be interpreted. This could indicate that more stringency in the satisfaction of some of them could compensate for weaknesses in satisfying others. For example, a “less than high” quality of the IP documentation may be compensated by specifying more detailed requirements related to the IP.

Specifying the intend to use a COTS IP, in the custom device PHAC, has always been required, although this was implicit. AMC 20-152A introduces an explicit objective and proposes some guidance about what needs to be documented in the plan about the COTS IP:

• Its identification and its functions,
• The COTS IP integration activities in the custom device development process,
• The COTS IP verification activities in the custom device verification process,
• The design assurance approach and associated credits claimed,
• Tool assessment and qualification, when pertinent.
   

One significant innovation, brought in by AMC 20-152A, consists of objectives related to the COTS IP documentation and data. In the context of the previously available guidance, the only documentation required was DO-254 compliant life-cycle data, i.e., hardware requirements and design data, which might not necessarily be reader-friendly.

AMC 20-152A is asking for documentation that “provides an understanding of the functionality, modes, and configuration of the IP”. It also indicates that the “quality” of documentation and data is an important factor to be considered. This “quality” may be interpreted as various aspects such as accuracy, completeness, or user-friendliness. Obviously, a high-quality documentation is a mitigating factor for the risk of user error in the integration of the IP in the development process. 

The required COTS IP data includes information about known errors and limitations. Here, the quality of this data may be related to the supplier’s process that creates it. Errors and limitations would result from the supplier’s verification and from the management, by the supplier, of user feedback. It is also required that the updated information about known errors and limitations is provided to the users. To get credit for that, the user would need to assess the supplier process for errata management and submit the related evidence for certification.

Finally, some service experience data is requested, for the specific use case of the IP in the user’s device. The guidance material associated with the AMC indicates that the goal is to claim a certain level of maturity, supported by the availability of stable errata data. However, no quantitative objective is provided, apart from the example of a COTS IP having been on the market for more than 2 years.

The COTS IP documentation and data must be assessed by the IP user and documented in the certification submission.
 

In the development of an FPGA program or of an ASIC, the decision to use of a COTS IP is made when some device functional requirements can be supported by this IP. The requirement capture process for the device development normally identifies requirements specifying functions that are supported by the COTS IP, as part of the DO-254 process. 

In some cases, the IP provides the major part of a required top-level device function. In this case, the devices requirements will specify in details the IP function. In other cases, the decision to use the IP is made in the lower levels of the device design and the only device requirements related to the IP will be derived requirements instructing the device developer to use the COTS IP to achieve some design goal.

The normal DO-254 requirements verification process will therefore contribute to verify the correct functionality of the COTS IP via the verification of device requirements associated to its supported functions. AMC 20-152A indicates that level of details of these requirements should be “commensurate with the verification strategy”. As hinted earlier, this indicates that specifying more detailed requirements, for the device function supported by the IP, would compensate for limitations in other evidence related to the IP correctness such as the supplier’s verification process or service experience.
 

In order to behave correctly, the COTS IP needs to be configured, unused functions need to be deactivated, and it must be interconnected and controlled in accordance with its documentation. AMC 20-152A makes it explicit that all these considerations must be captured as derived requirements for the device.

The capture of these requirements will be done on the basis of an assessment of the COTS IP documentation and associated data. This should include the assessment of known errors and limitations. 

In case of a “less than high” quality of the IP documentation, the requirements capture process may need to compensate for the lack of accuracy or of completeness of the documentation by performing experimentations with the COTS IP or by reverse-engineering of its implementation.

With the specification of these requirements, in the device hardware requirement specification, the normal DO-254 requirements verification process will mitigate the risk of user error, in configuring the COTS IP, and in its integration.
 

AMC 20-152A explicitly request that the IP user assesses the COTS IP supplier verification process to determine that this process is “trustworthy and reliable”. The result of this assessment must be documented in the certification submission.

A high-quality IP documentation will contribute to make the supplier verification process “trustworthy and reliable”. Also, this “trustworthy and reliable” verification process will contribute to the documentation of known errors and limitations. 

AMC 20-152A does not provide any detailed criteria for what is meant by trustworthy and reliable. However, it is possible to consider that it may be related to coverage of the functions that are described in the IP documentation. Of course, this would need to be supported by a rigorous configuration management process. And, in case of modifications, change impact analysis and regression verification would need to be shown appropriate.
 

AMC 20-152A requires that a verification strategy is established for the COTS IP and its usage. This strategy is to be based on the following elements:

• The IP supplier effort, provided the applied process is trustworthy and reliable,
• The IP service experience,
• Complementary verification of the IP performed by the user,
• Verification of the device requirements specifying the functions supported by the IP.

The underlying goal of the verification strategy should be to mitigate the risks of poor-quality IP and of errors in the implementation of the IP in the device developed by the IP user. The verification of the device requirements specifying the configuration, use and control of the COTS IP should take care of errors in the usage of the IP.

Of course, the strategy will depend on whether the IP is a soft, a firm or a hard IP. 
 

For DAL A & B devices, AMC 20-152 clarifies that DO-254 appendix B is to be complied with and that, for a COTS IP, the most likely means to achieve compliance is the safety-specific analysis. The effects of design errors in the IP on the device and the system safety should be analysed. If safety impacts are identified, they should be mitigated by protection mechanisms designed in the device and additional verification activities.

Author: Philippe Robert, System design Assurance & Certification Engineer, PMV Consulting & Services

#AircraftCertification