EASA AMC 20-152A: a new approach for COTS IP Design Assurance
Regarding COTS IP used in the development custom electronic devices for critical civil aviation applications, EASA newly published AMC 20-152A departs from previously applicable guidance. While it has been highly recommended to augment COTS IP life cycle data to satisfy ED-80/DO-254 prescriptions, this new guidance proposes alternative objectives based on available COTS IP documentation, supplier processes for verification and user support, and complementary verification. This new approach is definitely more compatible with the actual market of COTS IPs, where few products are specifically developed for the safety critical airborne device market.
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.
This guidance introduces the risks of using COTS IP in custom devices such as FPGA or ASIC:
- Incomplete documentation,
- Insufficient verification performed by the supplier,
- Poor quality of the COTS IP,
- Inadequate Fitness for Purpose,
- User error in configuring the COTS IP,
- User error in the integration process (physical implementation) of the COTS IP.
To mitigate these risks, AMC 20-152A proposes as series of objectives to be fulfilled covering the following aspects:
- Identification of the COTS IP in the certification plans and specification of the corresponding activities,
- Availability of high-quality documentation and technical data about the COTS IP,
- Specification of requirements for the IP,
- Taking credit from the supplier verification process,
- Performing verifications in complements to the supplier’s verification,
- For DAL A & B, performing additional safety analysis.
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.
COTS IP Documentation & Data
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.
Hardware Requirements related to the COTS IP
AMC 20-152A is considering two kinds of requirements:
- Requirements covering the device functions supported by the IP.
- Derived requirements specifying how to configure the IP, how to activate and deactivate functions and how to use and control the behaviour of the IP.
Requirements for the device function supported by the COTS IP
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.
Requirements for the configuration, use and control of the COTS IP
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.
Taking credit from the supplier verification process
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.
- AEH Airborne Electronic Hardware
- AMC Acceptable Means of Compliance
- ASIC Application Specific Integrated Circuit
- COTS Commercial Off-The-Shelf
- DAL Development Assurance Level
- FPGA Field Programmable Gate Array
- HDL Hardware Design Language
- IP Intellectual Property
- PHAC Plan for Hardware Aspects of Certification
- EASA AMC 20-152A, Development Assurance for Airborne Electronic Hardware (AEH), in AMC-20 amendment 19, dated 17 July 2020
- EUROCAE ED-80 / RTCA DO-254, design assurance guidance for airborne electronic hardware, April 2000
- EASA CM-SWCEH-001 Issue 01 Revision 02, Certification Memorandum - Development Assurance of Airborne Electronic Hardware, dated 08 January 2018
- FAA AC 20-152, Document RTCA/DO-254, Design assurance guidance for airborne electronic hardware, dated 6/30/05
- FAA Order 8110.105A, Simple and Complex Electronic Hardware Approval Guidance, dated 4/5/17
Author: Philippe Robert, System design Assurance & Certification Engineer, PMV Consulting & Services