AMC 20-152A Development Assurance for Airborne Electronic Hardware (AEH)

• ED Decision 2020/010/R found in: AMC-20 Amdt 21 - Airworthiness of Products, Parts and Appliances (Apr 2021)

AMC 20-152A Development Assurance for Airborne Electronic Hardware (AEH) ED Decision 2020/010/R 1          PURPOSE 1.1       This AMC describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the electronic hardware aspects of airborne systems and equipment in product certification or ETSO authorisation. Compliance with this AMC is not mandatory, and an applicant may elect to use an alternative means of compliance. However, the alternative means of compliance must meet the relevant requirements, ensure an equivalent level of safety, and be approved by EASA on a product or ETSO article basis. 1.2       This AMC recognises EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, dated April 2000, and RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, dated 19 April 2000. 1.3       This AMC describes when to apply EUROCAE ED-80/RTCA DO-254, and it supplements EUROCAE ED-80/RTCA DO-254 with additional guidance and clarification for the development of custom devices, including the use of commercial off-the-shelf (COTS) intellectual property (IP), for the use of COTS devices and for the development of circuit board assemblies (CBAs). The additional guidance and clarifications are provided in the form of objectives. The applicant is expected to describe the process and activities to satisfy the objectives of this AMC. Note: EUROCAE ED is hereafter referred to as ‘ED’; RTCA DO is hereafter referred to as ‘DO’. Where the notation ‘ED-80/DO-254’ appears in this document, the referenced documents are recognised as being equivalent. 1.4       This AMC does not address the Single Event Effects (SEE) aspects or the assessment of the hardware susceptibility to SEE. AMC SEE aspects are usually addressed through a certification review item (CRI), and further guidance may be found in EASA CM-AS-004 Issue 01, issued 8 January 2018. However, the Plan for Hardware Aspects of Certification may still be used to document the certification considerations for SEE. 2          APPLICABILITY This AMC may be used by applicants, design approval holders, and developers of airborne systems and equipment containing airborne electronic hardware (AEH) to be installed on type-certified aircraft, engines, and propellers. This applicability includes the developers of ETSO articles. This AMC is applicable to AEH that contributes to hardware development assurance level (DAL) A, DAL B, or DAL C functions. When an objective is not applicable to a specific hardware DAL, the applicability restriction is directly indicated within the objective text with the following convention, for instance ‘For DAL A hardware, …’ For AEH contributing to hardware DAL C functions, only a limited set of objectives applies. Even though there is a benefit in having a structured development process that ensures a proper flow-down of requirements to the hardware and the fulfilment by the hardware of the intended function, the use of this AMC is not required for AEH contributing to hardware DAL D functions. Appendix B provides some clarifications that may be used to ensure that the DAL D hardware performs its intended function. 3          DOCUMENT HISTORY This document is the initial issue of AMC 20-152. This initial issue, jointly developed with FAA, is intentionally set at Revision A. 4          BACKGROUND This AMC is related to the development of custom devices in AEH, including the use of commercial off-the-shelf intellectual property (COTS IP) within custom devices, the use of COTS devices, and the development of circuit board assemblies (CBAs). Each of these topics is organised with: background information dedicated to each major topic, —        applicability, and —        sections where objectives are described and uniquely identified. A unique identifier for each objective is defined with a prefix and an index number (i) as follows: —        for the development of custom devices, the identifier is ‘CD-i’; —        for the use of COTS IP in custom devices, the identifier is ‘IP-i’; —        for the use of COTS devices, the identifier is ‘COTS-i’; —        for the development of CBAs, the identifier is ‘CBA-i’. Objectives are also differentiated from the rest of the text by formatting in italics. The applicant should document in the Plan for Hardware Aspects of Certification (PHAC), or any other related planning document, the process and activities that the applicant intends to perform to satisfy the objectives of this AMC. The PHAC, as well as those related planning documents, should be submitted for certification. 5          CUSTOM DEVICE DEVELOPMENT This section provides guidance for the development assurance of programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs), which are collectively referred to as ‘custom devices’. These custom devices are addressed in ED-80/DO-254, Section 1.2, Item 3 as ‘custom micro-coded components’. Developing a custom device demands a well-defined development process. However, it is understood that the process to develop complex custom devices requires more comprehensive activities and artefacts than for a simple device. Section 5.1 identifies custom devices that are within the scope of this AMC. Section 5.2 provides guidance on simple/complex classification for custom devices. Section 5.3 provides guidance on development assurance for complex custom devices. Section 5.4 provides guidance on development assurance for simple custom devices. In particular, Section 5.4 defines which sections from 5.5 to 5.11 are applicable to the development assurance of simple electronic devices. Sections 5.5 to 5.10 provide clarifications on ED-80/DO-254. Section 5.11 provides background information and guidance specific to COTS IP used in custom devices. 5.1       Applicability to Custom Devices Section 5 is applicable to a digital- or mixed-signal custom device that contributes to hardware DAL A, B or C functions. Appendix A to ED-80/DO-254 modulates the ED-80/DO-254 life-cycle data based on the DAL allocated to the hardware function. This document recognises Appendix A for the modulation of the life-cycle data according to the hardware DAL for the development of custom devices. 5.2       Simple/Complex Classification ED-80/DO-254 introduces the notion of simple and complex hardware items. This section clarifies and provides criteria that could be used to classify a device as simple by considering the design content of the custom device, and subsequently, the ability to comprehensively verify the device. A hardware custom device is classified as simple only if a technical assessment of the design content supports the ability of the device to be verified by a comprehensive combination of deterministic tests and analyses that ensure correct functional performance under all foreseeable operating conditions with no anomalous behaviour. The following criteria should be used for assessing whether a device should be classified as simple: —        simplicity of the functions and their number, —        number and the simplicity of the interfaces, —        simplicity of the data/signal processing or transfer functions, and —        independence of functions/blocks/stages. Additional criteria specific to the digital part of the design include: —        whether the design is synchronous or asynchronous, —        number of independent clocks, —        number of state machines, number of states and state transitions per state machine, and —        independence between the state machines. The applicant may propose other or additional criteria for the technical assessment of simplicity. When an item cannot be classified as simple, it should be classified as complex. However, note that an item constructed entirely from simple items may itself be complex. **Objective CD-1** For each custom device, the applicant should document in the PHAC or any related planning document: 1.         the development assurance level, 2.         the simple or complex classification, and 3.         if a device is classified as simple, the justification based on the simple classification criteria. 5.3       Development Assurance for Complex Custom Devices ED-80/DO-254 is recognised as the industry standard for the development assurance of complex custom devices. The applicant should satisfy ED-80/DO-254 and the additional objectives or clarifications described in this AMC from Sections 5.5 to 5.11. 5.4       Development Assurance for Simple Custom Devices For the development of simple custom devices, it is understood that the life-cycle data might be significantly reduced compared with the data required for a complex custom device. ED-80/DO-254 acknowledges that the documentation for the design process of a simple hardware device is less extensive than the one needed for a complex device. In addition, while verification and configuration management are also needed, these supporting processes also require less documentation for a simple device. However, it is important that a simple custom device performs its intended function, and is under configuration management, thus allowing the device to be reproduced, conformed, and analysed to ensure continued operational safety. **Objective CD-2** The applicant should propose a process in the PHAC, or any other appropriate planning document, to develop simple custom devices which encompasses the following: 1.         definition of the device functions, 2.         complete verification of the device functions through tests and analyses, 3.         configuration management of the device, including problem reporting and the instructions to reproduce the device, 4.         assessment of the build conformance of the device. Sections 5.5.2.4 and 5.5.2.5 of this document also apply to the verification process for simple custom devices. The life-cycle data for simple devices can be combined with other hardware data. If tools are used for the simple custom device development process, the objectives or clarifications of those objectives described in Section 5.8 of this document are also applicable. When the applicant intends to reuse a previously developed simple device, ED-80/DO-254 Section 11.1 and the clarifications provided in Section 5.9 of this document should be used. If the applicant intends to use COTS IP, the objectives or clarifications of those objectives described in Section 5.11 of this document are also applicable. 5.5       Clarifications to ED-80/DO-254 Validation and Verification Processes 5.5.1   Validation Process Establishing a correct and complete set of requirements is the cornerstone of the development assurance process. ED-80/DO-254 Section 6.1 addresses the validation process to ensure the completeness and correctness of derived requirements. Nevertheless, the validation process is essential for all the requirements. Indeed, the upper-level requirements allocated to the custom device are often refined, decomposed or restated at the custom device level, and in terms that support the hardware design. These custom device requirements, which are traceable from/to the upper-level requirements and, therefore, not considered to be ‘derived’, should also be correct and complete. **Objective CD-3** The applicant should validate all the custom device requirements by following the ED-80/DO254 validation process (ED-80/DO-254 Section 6). This validation activity covers both derived and non-derived requirements. For DAL A and B development, validation activities should be performed with independence. Note: ED-80/DO-254 Appendix A defines acceptable means for establishing independence. 5.5.2   Verification Process ED-80/DO-254 broadly describes the verification process, but additional guidance is needed to ensure the verification of the custom device is complete, particularly in the area of: —        design reviews, —        reviews of test cases and procedures, and —        verification of the implementation. 5.5.2.1           Conceptual Design Review Conceptual design is the process of generating a high-level design description from the hardware requirements (see ED-80/DO-254 Section 5.2). The conceptual design review is typically used to ensure that the outcome of the conceptual design activities (see ED-80/DO254 Section 5.2.2) is consistent with the requirements, and identifies constraints for the interfacing components (hardware or software) and architectural constraints for the detailed design activities of the custom device. Since this conceptual design review is already addressed in ED-80/DO-254 Section 5.2.2 through the note, no separate objective is needed. 5.5.2.2           Detailed Design Review Detailed design is the process of generating, from the conceptual design and the requirements, a hardware description language (HDL) or analogue representation of the design, constraints for the implementation (e.g. timing constraints, pinout, I/O characteristics), and the hardware– software interface description. ED-80/DO-254 introduces design reviews in Section 6.3.3.2. A design review is considered to be an essential step during the detailed design process (ED-80/DO-254 Section 5.3) supporting the implementation process, and complementing requirements-based verification. **Objective CD-4** For hardware DAL A or DAL B, the applicant should review the detailed design with respect to the design standards, and review the traceability between the detailed design and the custom device requirements, in order to demonstrate that the detailed design covers the custom device requirements, is consistent with the conceptual design, and is compliant with the hardware design standards. For hardware DAL C, the applicant should demonstrate that the detailed design satisfies the hardware design standards. 5.5.2.3           Implementation Review Within a custom device development process, tools are used to convert the detailed design data into the physical implementation. While ED-80/DO-254 does not explicitly address it, a review of the design tool reports (e.g. synthesis and place and route reports) is necessary to ensure that the execution of the tool to generate its output was performed correctly. **Objective CD-5** When tools are used to convert the detailed design data into the physical implementation, the applicant should review the design tool reports (e.g. synthesis and place and route reports) to ensure that the tool executed properly when generating the output. 5.5.2.4           Review of Verification Cases and Procedures ED-80/DO-254 introduces verification coverage analysis in Section 6.2.2 Item 4 to satisfy the ED-80/DO-254 verification process objectives and determine whether the verification process is correct and complete. A part of the coverage analysis is clarified by the following objective. **Objective CD-6** Each verification case and procedure should be reviewed to confirm that it is appropriate for the requirements to which it traces and that the requirements are correctly and completely covered by the verification cases and procedures. 5.5.2.5           Verification of the Timing Performance of the Implementation ED-80/DO-254 Section 6.2 addresses the verification of the implementation. The implementation results from the process to generate the physical custom device from the detailed design data. The post-layout netlist is the closest virtual representation of the physical custom device, resulting from synthesis (for the digital part of the device) and place and route. While it is recommended to test the implementation in its intended operational environment (i.e. by a physical test), verification using the post-layout netlist may be necessary to complement the verification of the implementation for certain requirements (e.g. features not accessible from the I/O pins of the device, timing, abnormal conditions, or robustness cases). In such cases, the coverage of the requirements by means other than a physical test should be justified. The requirement to capture the activities in ED-80/DO-254 Section 5.1.2 Item 4.g introduces the need for the requirements to address signal timing characteristics under normal- and worst-case conditions. Nevertheless, ED-80/DO-254 does not explicitly address the necessity to verify the performance of the device under all possible (best-case and worst-case) timing conditions that could possibly occur during the operation of the device. The following objective clarifies the need to take into account the variation of the environmental conditions (temperature, voltage, etc.) during the evaluation of the timing performance of the design, as well as the semiconductor device process variations. **Objective CD-7** The applicant should verify the timing performance of the design accounting for the temperature and power supply variations applied to the device and the semiconductor device fabrication process variations as characterised by the manufacturer of the semiconductor device. Note: Static timing analysis (STA) with the necessary timing constraints and conditions is one of the possible means of compliance with this objective for the digital parts of custom devices. 5.6       Clarifications to ED-80/DO-254 ‘Robustness Aspects’ ED-80/DO-254 mentions robustness defects but does not explicitly address robustness. The robustness of the design is defined as the expected behaviour of the design under abnormal and boundary/worstcase operating conditions of the inputs and internal design states. These conditions are often captured as derived requirements when they are not allocated from the upper-level process. When subjected to these conditions, it is understood that the design may not continue to perform as it would under normal conditions. **Objective CD-8** For DAL A or DAL B hardware, the abnormal and boundary conditions and the associated expected behaviour of the design should be defined as requirements. 5.7       Recognition of HDL Code Coverage Method HDL code coverage analysis is an assessment of whether the HDL code of the design has been exercised through HDL simulations. The HDL code coverage method provides an assessment of the coverage of the design logic structure, giving an indication of which aspects of the logic structure are exercised and which are not. When performed during requirements-based verification (per ED-80/DO-254 Section 6.2), HDL code coverage is recognised as a method to perform ED-80/DO-254 elemental analysis per Appendix B Section 3.3.1 for digital devices. HDL code coverage supports the assessment of whether the HDL code elements are fully covered by requirements-based simulations. As such, it does not represent an assessment of the completeness of the requirements-based testing activities or the effectiveness of the requirement coverage. **Objective CD-9** For hardware DAL A or DAL B, where HDL code coverage is used to perform elemental analysis (ED-80/DO-254 Appendix B Section 3.3.1), the applicant should define in the planning documents the detailed coverage criteria of the HDL code elements used in the design. The criteria should ensure coverage over the various cases of the HDL code elements used in the design (e.g. branches, conditions, etc.). Any non-covered case or element should be analysed and justified. Note: Code coverage might need to be complemented by additional analysis for any hardware items that are identified as not covered by the code coverage analysis, in order to complete the elemental analysis of all elements. This situation may occur in the use of some COTS IP instantiations. 5.8       Clarifications to ED-80/DO-254 ‘Tool Assessment and Qualification’ ED-80/DO-254 introduces the notion of tool assessment and qualification. ED-80/DO-254 Figure 11-1 includes a flow chart indicating the tool assessment considerations and activities, and provides guidance for when tool qualification may be necessary. This AMC uses the flow chart and its related text as a basis for providing further clarification, as follows: ED-80/DO-254 — Figure 11-1 Item 1 — Identify the Tool Information capturing the environment required for tool operation and the tool revision should be included with the tool identification. ED-80/DO-254 — Figure 11-1 Item 2 — Identify the Process the Tool Supports When identifying the design or verification process that the tool supports, it is important to also identify what purpose or activity within the hardware development process the tool satisfies. While assessing the tool limitations, evidence of formal assessment of the tool problem reports is not required if the tool output has been completely and independently assessed. ED-80/DO-254 — Figure 11-1 Item 3 — Is the Tool Output Independently Assessed? The purpose of assessing the tool output is to completely cover, with an independent means, the potential errors that the tool could introduce into the design or fail to detect during verification. **Objective CD-10** When the applicant intends to independently assess a tool output, the applicant should propose an independent assessment that verifies the tool output is correct. The independent assessment should justify that there is sufficient coverage of the tool output. The completeness of the tool assessment should be based on the design/implementation and/or verification objectives that the tool is used to satisfy. ED-80/DO-254 — Figure 11-1 Item 4 — Is the Tool a Level A, B or C Design Tool or a Level A or B Verification Tool? ED-80/DO-254 Figure 11-1 Item 4 of the tool assessment/qualification flow excludes the need for activities for tools ‘used to assess the completion of verification testing, such as in an elemental analysis’. The last statement is misleading regarding the intent of code coverage tools used for elemental analysis. As stated in Section 5.7 of this document, ‘when a code coverage tool is used for elemental analysis, it does not represent an assessment of the completeness of the requirements-based testing activities or the effectiveness of the requirement coverage’. It is therefore necessary to provide some further clarifications. —        This document recognises the Figure 11-1 Item 4 exclusion of tool assessment/qualification activities for code coverage tools only when they are used to assess whether the code has been exercised by requirements-based testing/simulations (elemental analysis). —        If test cases or procedures are automatically generated by a tool and this tool uses coverage to determine the completion of the requirements verification, then the tool should be considered to be a verification tool to answer the question raised in Figure 11-1 Item 4. ED-80/DO-254 — Figure 11-1 Item 5 — Does the Tool have Relevant History? In ED-80/DO-254, the supporting text for Figure 11-1 Item 5 can be misinterpreted to suggest that when the tool has been previously used, no further tool assessment is necessary. Item 5 should be understood to mean that the applicant will provide sufficient data and justification to substantiate the relevance and credibility of the tool history. **Objective CD-11** When the applicant intends to claim credit for the relevant history of a tool, sufficient data should be provided as a part of the tool assessment to demonstrate that there is a relevant and credible tool history to justify that the tool will produce correct results for its proposed use. ED-80/DO-254 — Figure 11-1 Item 9 — Design Tool Qualification For design tools, contrary to the note in the supporting text for Figure 11-1 Item 9, the tool history should not be used as a stand-alone means of tool assessment and qualification. A relevant tool history may be used to compensate for some particular gaps in the tool assessment and qualification process, for example, to explain the method of independent assessment of the tool output. In this case, a relevant tool history is considered to be complementary data, providing more assurance for a tool. In addition to what is already referenced in ED-80/DO-254 Figure 11-1 Item 9 for tool qualification guidance, ED-12C/DO-178C and ED-215/DO-330 may also be used. 5.9       Clarifications to ED-80/DO-254 regarding Previously Developed Hardware (PDH) Previously developed hardware (PDH) is defined as custom-developed hardware that has been installed in an airborne system or equipment either approved through EASA type certification (TC/STC) or authorized through ETSOA. The section providing clarification on the use of PDH also covers PDH that was developed and approved prior to the use of ED-80/DO-254 in civil certification. This section provides guidance on the use of ED-80/DO-254 Section 11.1 for PDH. **Objective CD-12** When an applicant proposes to reuse PDH, the applicant should use ED-80/DO-254 Section 11.1 and its subordinate paragraphs. The applicant should perform the assessments and analyses required in ED-80/DO-254 Section 11.1 in order to ensure that using the PDH is valid and that the compliance shown during the previous approval was not compromised by any of the following: 1.         Modification of the PDH for the new application or for obsolescence management; 2.         Change to the function, change to its use, or change to a higher failure condition classification of the PDH in the new application; or 3.         Change to the design environment of the PDH. The results should be documented in the PHAC or any other appropriate planning document. In the context of custom device development, any one of these three points potentially invalidates the original development assurance credit for the PDH. In case of change or modification, the applicant should assess these changes using ED-80/DO-254 Section 11.1 and its subordinate paragraphs. When the original design assurance of the PDH is invalidated by one of the above points, the custom device should be upgraded based on the assessment per ED-80/DO-254 Section 11.1. When upgrading the hardware, the applicant should consider the objectives of this document that are applicable per the assessment. 5.10    Clarifications to ED-80/DO-254 Appendix A This section clarifies the life-cycle data referenced in ED-80/DO-254 Appendix A as follows. —        The row corresponding to 10.1.6 ‘Hardware Process Assurance Plan’ in Table A-1 should also indicate HC2 for Level C to be consistent with row 10.8. —        The row corresponding to 10.2.2 ‘Hardware Design Standard’ in Table A-1 should also indicate HC2 for Level C. HDL Coding Standards are part of the Hardware Design Standards. —        The row corresponding to 10.3.2.2 ‘Detailed Design Data’ in Table A-1 should indicate HC1 for Levels A, B and C. —        The row corresponding to 10.4.2 ‘Hardware Review and Analysis Procedures’ in Table A-1 should also indicate HC2 for Level C to be consistent with row 10.4.3. —        The Top-Level Drawing referenced in ED-80/DO-254 Appendix A corresponds to a Hardware Configuration Index (HCI) document. The HCI document completely identifies the hardware configuration, the embedded logic, and the development life-cycle data. To support consistent and accurate replication of the custom device (ED-80/DO-254 Section 7.1), the Top-Level Drawing includes the hardware life cycle environment or refers to a Hardware Environment Configuration Index (HECI) document. 5.11    Use of COTS IP in Custom Device Development This section addresses COTS IP that is instantiated within FPGAs/PLDs/ASICs during the development of the custom device. This section addresses COTS IP and its integration within custom devices and describes objectives to support the demonstration of compliance with the applicable airworthiness regulations for the hardware aspects of airborne systems and equipment certification. Section 5.11.2, on ‘Applicability to COTS IP’, identifies COTS IP that are within the scope of Section 5.11. 5.11.1 Background IP refers to design functions (design modules or functional blocks, including IP libraries) used to design and implement a part of or a complete custom device such as a PLD, FPGA, or ASIC. IP is considered to be commercial off-the-shelf intellectual property, i.e. ‘COTS IP’, when it is a commercially available function, used by a number of different users, in a variety of applications and installations. Custom IP, developed for a few specific aircraft equipment, is not considered to be COTS IP. COTS IP are available in various source formats. COTS IP are categorised as Soft IP, Firm IP, or Hard IP based on the stage in the custom device design flow where the IP is instantiated. A function can be a combination of source formats and each part needs to be addressed. Definitions for Soft IP, Firm IP, and Hard IP can be found in Appendix A ‘Glossary’. Figure 1 shows a ‘simplified’ design flow of a PLD, FPGA, or ASIC, and where Soft IP, Firm IP, and Hard IP are located in the design flow.  *Figure 1 — Position of COTS IP within a ‘simplified’ design representation flow* The availability of a COTS IP does not guarantee that it is suitable to be used in a custom device for aircraft systems. Some COTS IP may have been developed using ED-80/DO-254, and will therefore have the necessary life-cycle data to demonstrate satisfaction of ED-80/DO-254. However, most COTS IP are not developed to meet aviation development assurance standards and, therefore, there are risks associated with their use in a custom device for aircraft systems or equipment. The risks of using COTS IP may include: —        Incomplete or missing documentation/data regarding: —        the behavioural operation of the COTS IP, —        how to integrate it into the design; —        Insufficient verification performed by the COTS IP provider; —        Deficient quality of the COTS IP. The potential for design errors may be increased by the lack of development assurance and/orby insufficient service experience. Possible design errors within COTS IP or in the use of COTS IP may lead to a failure mode. Riskfactors for these types of errors include: —        Unknown level of rigour of the COTS IP design and verification process; —        Misalignment between the intended usage of the COTS IP by the IP provider and the usage in the custom device by the IP user; —        Incomplete or missing details regarding the detailed operation of the COTS IP; —        Incorrect integration of the COTS IP with the rest of the custom device design; —        Integrator lacking expertise with the function of the IP. Additionally, the COTS IP user completes the development of the integrated COTS IP up to the physical implementation of the device. The COTS IP user may introduce a design error while completing the physical implementation of the COTS IP because of the user’s incomplete knowledge of the internal design of the COTS IP. 5.11.2 Applicability to COTS IP Section 5.11 is applicable to COTS IP used in a custom device that meets the definition of ‘commercial off-the-shelf intellectual property’ in the Glossary of Appendix A. This scope encompasses digital, analogue, and mixed-signal COTS IP. Note: Analogue COTS IP is within the above-mentioned scope, as it could be instantiated within a custom, mixed-signal device. Section 5.11 is applicable to COTS IP contributing to hardware DAL A, B or C functions. Section 5.11 is applicable to Soft IP, Firm IP, and Hard IP that are inserted within a custom device by the applicant. However, Section 5.11 does not apply to Hard IP that is embedded in the silicon of an FPGA or a PLD by the FPGA/PLD device manufacturer. This type of IP is considered to be part of the COTS device, and is covered in Section 6 ‘Use of Commercial Off-the-Shelf Devices. 5.11.3 Development Assurance for COTS IP A COTS IP development assurance approach should be based on the category of the COTS IP (Soft, Firm, Hard) and on the identified risks of failure due to a design error in the COTS IP itself or an error in the way it is used in the custom device. This section provides objectives addressing development assurance when using COTS IP. These objectives are intended to cover the particular aspects of development when using COTS IP, and are expressed in connection with the custom device development process that follows ED-80/DO-254 and the custom device objectives of this document. The development aspects related to COTS IP start from the custom device process that captures the allocated requirements for the function that will be performed by the COTS IP. From this entry point, the following aspects provide a basis to define the development assurance objectives for the use of COTS IP: —        Selection of the COTS IP, —        Assessment of the IP provider and the IP data, —        Planning activities, including the verification strategy, —        Definition of the requirements/derived requirements, —        Design integration, implementation, and verification of the COTS IP in the custom device. 5.11.3.1        Selection of the COTS IP to implement the function COTS IP can be available in different forms/source formats and various levels of quality. Some COTS IP may not be acceptable for use in airborne systems. The selection criteria below are intended to address the essential characteristics that are considered a minimum for the use of IP in custom AEH devices. **Objective IP-1** The applicant should select a COTS IP that is considered to be an acceptable solution, based on at least the following criteria: 1.         The IP is technically suitable for implementing the intended function; 2.         The description of the COTS IP architecture or IP design concept provides an understanding of the functionality, modes, and configuration of the IP. The description should also include an understanding of the source format or combination of source formats of the COTS IP; 3.         The availability and quality of data and documentation allow the understanding of all aspects of the COTS IP functions, modes, and behaviour, and enable the integration and verification of the COTS IP (e.g. datasheets, application notes, user guide, knowledge of errata, etc.); 4.         Information exists for the IP user to be able to create the physical implementation of the COTS IP (e.g. synthesis constraints, usage and performance limits, physical implementation, and routing instructions); 5.         It can be demonstrated that the COTS IP fulfils its intended function. 5.11.3.2        Assessment of the COTS IP Provider and COTS IP Data **Objective IP-2** The applicant should assess the COTS IP provider and the associated data of the COTS IP based on at least the following criteria: 1.         The IP provider provides all the information necessary for the integration of the COTS IP within the custom device and to support the implementation of the COTS IP within the device (e.g. synthesis constraints, usage domain, performance limits, physical implementation, and routing instructions); 2.         The configurations, selectable options, and scalable modules of the COTS IP design are documented so that the implementation of the COTS IP can be properly managed; 3.         The COTS IP has been verified by following a trustworthy and reliable process, and the verification covers the applicant’s specific use case for the COTS IP (including the used scale for scalable IP and the IP functions selected for selectable functions); 4.         The known errors and limitations are available to the IP user, and there is a process to provide updated information to the IP user; 5.         The COTS IP has service experience data that shows reliable operation for the applicant’s specific use case for the COTS IP. The assessment should be documented. The results of the assessment should be submitted together with the planning documents. 5.11.3.3        Planning of the Hardware Development Assurance Approach related to COTS IP 5.11.3.3.1     Complementary Development Assurance **Objective IP-3** When the IP-2 Objective criteria items 1, 2, 4 or 5 cannot be completely met using the IP provider’s data, the applicant should define an appropriate development assurance activity to mitigate the criteria that were not met and address the associated risk of development errors. The development assurance activity should be based on the ED-80/DO-254 objectives. Note: The results of the assessment of Objective IP-2 Item 3 are considered in Section 5.11.3.3.2. 5.11.3.3.2     The Verification Strategy for COTS IP Functions In addition to the verification of the custom device functions supported by the COTS IP, there is a need to ensure that the aspects related to the COTS IP and its usage are addressed. This section focuses on defining a verification strategy to cover those aspects. The verification performed by the COTS IP provider typically does not follow the ED-80/DO-254 verification process but may provide some credit to be used for the verification strategy. However, the verification process for COTS IP generally differs from one IP vendor to another, and the level of assurance varies depending on the IP provider’s development practices. The verification strategy may combine different means to complement the traditional requirements-based testing approach. Based on the applicant’s assessment of the IP provider and the IP data through Objective IP-2, the applicant is expected to establish a verification strategy. The aim of this verification strategy is to cover all three of the following aspects: —        The COTS IP: the purpose is to ensure that the COTS IP is verified, addressing the risk identified from the IP-2 Item 3 objective; —        Its implementation: the purpose is to ensure that the COTS IP still performs its allocated function, and that no design errors have been introduced by the design steps performed by the applicant (e.g. synthesis/place and route); —        Its integration within the custom device: the purpose is to ensure that the COTS IP has been properly connected, configured, and constrained within the custom device. The strategy may accomplish more than one aspect within a common verification step. This section identifies a general objective for the verification of COTS IP used in a custom device, enabling various verification approaches. **Objective IP-4** The applicant should describe in the hardware verification plan, PHAC, or any related planning document, a verification strategy that should encompass all three of the following aspects: 1.         The verification of the COTS IP itself, addressing the risk identified from the IP-2 Item 3 objective; 2.         The verification of the COTS IP after the design steps performed by the applicant (e.g. synthesis/place and route); 3.         The verification of the integrated COTS IP functions within the custom device. Note 1:  Reliable and trustworthy test data, test cases or procedures from the COTS IP provider may be used as part of the verification strategy to satisfy this objective. Note 2:  If the COTS IP implements functions based on an industry standard, proven standardised test vectors verifying compliance with the standard may be used in the verification strategy of the COTS IP. Note 3:  The verification strategy covers at a minimum the used functions of the COTS IP and ensures that the unused functions are correctly disabled or deactivated and do not interfere with the used functions. 5.11.3.3.3     COTS IP and Planning Aspects The applicant has to define the activities that are needed for the hardware development assurance approach related to COTS IP. **Objective IP-5** The applicant should describe in the PHAC, or any related planning document, a hardware development assurance approach for using the COTS IP that at least includes: 1.         identification of the selected COTS IP (version) and its source format(s) associated with the point(s) in the design flow where the COTS IP is integrated into the custom device; 2.         a summary of the COTS IP functions; 3.         the development assurance process that the applicant defines to satisfy the objectives of Section 5.11.3; 4.         the process related to the design integration and to the usage of the COTS IP in the development process of the custom device; 5.         tool assessment and qualification aspects when the applicant uses a tool to perform design and/or verification steps for the COTS IP. 5.11.3.4        Requirements for COTS IP Function and Validation Custom device requirements typically contain requirements that relate to the function supported by the COTS IP. The granularity of these requirements may be very different depending on the COTS IP function and the visibility of the functions supported by the IP at the custom device level. Depending on the extent of requirements-based testing as a part of the chosen verification strategy of the COTS IP, the level of detail and the granularity of the AEH custom device requirements may need to be refined to specifically address the COTS IP functions and the implementation of the COTS IP. In addition, requirements should be captured to encompass all the necessary design detail used to connect, configure, and constrain the COTS IP and properly integrate it into the AEH custom device. **Objective IP-6** The requirements related to the allocated COTS IP functions should be captured to an extent commensurate with the verification strategy. In addition, derived requirements should be captured to cover the following aspects associated with the integration of the COTS IP into the custom device design: 1.         COTS IP used functions (including parameters, configuration, selectable aspects); 2.         Deactivation or disabling of unused functions; 3.         Correct control and use of the COTS IP, in accordance with the data from the COTS IP provider. When the applicant chooses a verification strategy (see Section 5.11.3.3.2) that solely relies on requirements-based testing, the ‘extent commensurate with the verification strategy’ corresponds to a complete requirement capture of the COTS IP following ED-80/DO-254. Regarding the validation aspects, the COTS IP requirements should be validated as a part of the validation process of the AEH custom device. 5.11.3.5        Verification The applicant should ensure that the COTS IP is verified as a part of the overall custom device verification process per ED-80/DO-254 and based on the verification strategy for the COTS IP that has been described in the PHAC or a related planning document. For the requirements-based verification part, the applicant should satisfy ED-80/DO-254 Section 6.2 for the verification of the requirements related to the COTS IP (see Section 5.11.3.4 above). This can be performed as a part of the overall custom device process, therefore there is no separate objective. 5.11.3.6        DO-254 Appendix B considerations When developing a hardware DAL A or B custom device, ED-80/DO-254 Appendix B is applicable. Code coverage analysis that is recognised as part of elemental analysis (refer to Section 5.7 of this document) might not be possible for the COTS IP part of the design. However, ED-80/DO-254 Appendix B offers other acceptable methods, including safety-specific analysis. The following objective further clarifies the expectations when using safety-specific analysis. **Objective IP-7** For COTS IP used in DAL A or DAL B hardware, the applicant should satisfy ED-80/DO-254 Appendix B. The applicant may choose safety-specific analysis methods to satisfy Appendix B on the COTS IP function and its integration within the custom device functions. This safety-specific analysis should identify the safety-sensitive portions of the COTS IP and the potential for design errors in the COTS IP that could affect the hardware DAL A and DAL B functions in the custom device or system. For unmitigated aspects of the safety-sensitive portions of the IP, the safety-specific analysis should determine which additional requirements, design features, and verification activities are required for the safe operation of the COTS IP in the custom device. Any additional requirements, design features and/or verification activities that result from the analysis should be fed back to the appropriate process. 6.         USE OF COMMERCIAL OFF-THE-SHELF DEVICES Applicants are increasingly using COTS electronic devices in aircraft/engines/propellers/ airborne systems, which may have safety implications for the aircraft, engines/propellers, or systems. Section 6 addresses the use of COTS devices through objectives that support the demonstration of compliance with the applicable airworthiness regulations for hardware aspects of airborne systems and equipment certification when using complex COTS devices. Section 6.2 ‘Applicability to COTS devices’ enables applicants to identify the COTS devices that are within the scope of Section 6. Note: The term ‘COTS device’ used in this document applies to a semiconductor product that is fully encapsulated in a package. This term does not apply to circuit board assemblies (CBAs). 6.1       Background COTS devices continue to increase in complexity and are highly configurable. COTS devices provide ‘off-the-shelf’ already developed functions, some of which are highly complex. Their development and production processes undergo a semiconductor industry qualification based on their intended market (consumer, automotive, telecom, etc.). Their usage by the aerospace industry provides additional integration and higher performance capabilities than were possible in the past. The design data for these COTS devices is usually not available to the COTS user. Since these devices are generally not developed for airborne system purposes, assurance has not been demonstrated that the rigour of a COTS manufacturer’s development process is commensurate with the aviation safety risks. ED-80/DO-254 introduces a basis for the development assurance for the use of COTS devices in Section 11.2 ‘COTS components usage’. This section states that ‘the use of COTS components will be verified through the overall design process, including the supporting processes’. Since ED-80/DO-254 was released in the year 2000, the number of functions embedded and integrated in a single COTS device has significantly increased. Functions which were previously split into various components, making the interface between those components accessible for verification, are now embedded within a single chip. While there are clearly some benefits of integrating more functions within a device, the increased level of integration makes it difficult for the user to verify the different hardware functions in the device due to lack of access to the interfaces between functions. Since these devices are more complex and highly configurable than the older separate devices, the risk is greater that the COTS device will not achieve the intended function in particular use cases over the required operating conditions. Furthermore, some additional assurance is needed because design errors may still be discovered after the COTS device is released to the market, or when an applicant extends the use of the device beyond the manufacturer’s specifications. 6.2       Applicability to COTS Devices Section 6 is applicable to digital, hybrid, and mixed-signal COTS devices that contribute to hardware DAL A, B or C functions. For COTS devices contributing to hardware DAL C functions, a limited set of the objectives of this section will apply. Section 6 is also applicable to FPGA and PLD devices that embed Hard IP (see definition) in their produced/manufactured silicon, but only for the COTS part of the FPGAs/PLDs. Section 6.4 only applies to COTS devices that are complex, as determined by the following COTS complexity assessment. 6.3       COTS Complexity Assessment In order to define which COTS devices are complex, the following high-level criteria should be used, considering all functions of the device, including any functions intended to be unused: A COTS device is complex when the device: 1.         has multiple functional elements that can interact with each other; and 2.         offers a significant number of functional modes; and 3.         offers configurability of the functions, allowing different data/signal flows and different resource sharing within the device. Or when the device: 4.         contains advanced data processing, advanced switching, or multiple processing elements (e.g. multicore processors, graphics processing, networking, complex bus switching, interconnect fabrics with multiple masters, etc.). For complex COTS devices, it is impractical to completely verify all possible configurations of the device, and it is difficult to identify all potential failures. **Objective COTS-1** The applicant should assess the complexity of the COTS devices used in the design according to the high-level criteria of Section 6.3, and document the list of relevant devices (see Note 1), including the classification rationale, in the PHAC or any related hardware planning document. Note 1:  The applicant is not expected to assess the complete bill of material to satisfy the above objective, but only those devices that are relevant for the classification, including devices that are at the boundary between simple and complex. The resulting classification (simple or complex) for those devices that are at the boundary and those that are definitely complex should be documented. Note 2:  A classification rationale is required for those devices that are at the boundary (meeting a part of the high-level criteria) and are classified as simple. Some examples of classification are provided in the GM Appendix for illustration. 6.4       Development Assurance for Use of Complex COTS ED-80/DO-254 Section 11.2.1 identifies some electronic component management process (ECMP) items when using a COTS device. ED-80/DO-254 Section 11.2.2 and Section 6.1 of this document identify some concerns with using a COTS device. The following objectives acknowledge and supplement ED-80/DO-254 Section 11.2 in clarifying how to gain certification credit when using complex COTS devices. 6.4.1   Electronic Component Management Process (ECMP) As stated in ED-80/DO-254 Section 11.2, ‘the use of an electronic component management process, in conjunction with the design process, provides the basis for COTS components usage.’ **Objective COTS-2** The applicant should ensure that an electronic component management process (ECMP) exists to address the selection, qualification, and configuration management of COTS devices. The ECMP should also address the access to component data such as the user manual, the datasheet, errata, installation manual, and access to information on changes made by the component manufacturer. As part of the ECMP, for devices contributing to hardware DAL A or B functions, the process for selecting a complex COTS device should consider the maturity of the COTS device and, where risks are identified, they should be appropriately mitigated. Note: Recognised industry standards describing the principles of electronic component management may be used to support the development of the ECMP. See Appendix B. 6.4.1.1           Using a Device outside Ranges of Values Specified in its Datasheet The device reliability is established by the device manufacturer through the device qualification process (see definition of ‘qualification of a device’ in the glossary). ED-80/DO254 Section 11.2.1 Item 6 mentions that a device is selected based on the technical suitability of the device for the intended application. In some cases, the applicant may need to use the device outside the specified operating conditions guaranteed by the device manufacturer. ED-80/DO-254 Section 11.2.1 Item 4 and Item 6 should be addressed when the device is used outside its guaranteed specification. The following objective describes what to achieve when using a device outside the ranges of values specified in its datasheet. **Objective COTS-3** When the complex COTS device is used outside the limits of the device manufacturer’s specification (such as the recommended operating limits), the applicant should establish the reliability and the technical suitability of the device in the intended application. 6.4.1.2           Considerations when the COTS Device has Embedded Microcode COTS devices may need microcode to execute some hardware functions. When those functions are used by the applicant, there is a risk if the microcode has not been verified by the device manufacturer during the COTS device qualification, or if the microcode is proposed to be modified by the applicant. If the microcode is delivered by the device manufacturer, is controlled by the device manufacturer’s configuration management system, and is qualified together with the device by the device manufacturer, it is accepted that the microcode is part of the qualified COTS device. If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the microcode cannot be considered to be part of the qualified COTS device. **Objective COTS-4** If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the applicant should ensure that a means of compliance for this microcode integrated within the COTS device is proposed by the appropriate process, and is commensurate with the usage of the COTS device. Note: The PHAC (or any other related planning document) should document the existence of the microcode and refer to the process (hardware, software, system) where it is addressed. 6.4.2   COTS Device Malfunctions Some COTS devices may contain errors that may or may not have been detected by the devicemanufacturer. **Objective COTS-5** The applicant should assess the errata of the COTS device that are relevant to the use of the device in the intended application, and identify and verify the means of mitigation for those errata. If the mitigation means is not implemented in hardware, the mitigation means should be fed back to and verified by the appropriate process. Note: The above objective refers to any mitigation means (such as hardware, software, system, or other means). **Objective COTS-6** The applicant should identify the failure modes of the used functions of the device and the possible associated common modes, and feed both of these back to the system safety assessment process. 6.4.3   Usage of COTS Devices This section focuses on the usage of complex COTS devices, while Section 7 covers the overall circuit board assembly development process. This Section 6.4.3 refers to the term ’intended function of the hardware’, which is considered to be defined through the CBA development process. Complex COTS devices can have multiple functions and many configurations of those functions. The configuration of a device should be managed in order to provide the ability to consistently apply the required configuration settings, to replicate the configuration on another item, and to modify the configuration in a controlled manner, when modification is necessary. The configuration of the device addresses at least the following topics: —        Used functions (e.g. identification of each function, configuration characteristics, modes of operation), —        Unused functions and the means (internal/external) used to deactivate them, —        Means to control any inadvertent activation of the unused functions, or inadvertent deactivation of the used functions, —        Means to manage device resets, —        Power-on configuration, —        Clocking configuration (e.g. identification of the different clock domains), and —        Operating conditions (e.g. clock frequency, power supply level, temperature, etc.). **Objective COTS-7** The applicant should ensure that the usage of the COTS device has been defined and verified according to the intended function of the hardware. This also includes the hardware–software interface and the hardware to (other) hardware interface. When a COTS device is used in a hardware DAL A or B function, the applicant should show that unused functions of the COTS device do not compromise the integrity and availability of the COTS device’s used functions. Note 1:  For unused functions of the COTS device, it is recommended that an effective deactivation means is used and verified, when available. Note 2:  Verification should be performed at an appropriate level (hardware, software, equipment). ED-80/DO-254 Section 10.3.2.2.4 introduces hardware/software (HW/SW) interface data, which can be used as a reference to define the software interface data of the COTS device. Some additional consideration should be given to the critical configuration settings. Those are defined as the settings that are deemed necessary by the applicant for the proper usage of the hardware, which, if inadvertently altered, could change the behaviour of the COTS device, causing it to no longer fulfil the hardware intended function. **Objective COTS-8** If the complex COTS device contributes to DAL A or B functions, the applicant should develop and verify a means that ensures an appropriate mitigation is specified in the event of any inadvertent alteration of the ‘critical configuration settings’ of the COTS device. Note: The mitigation means might be defined at the hardware, software, or system level, or a combination of these. The mitigation means may also be defined by the safety assessment process. 7          Development Assurance of Circuit Board Assemblies (CBAs) This section provides guidance for the development assurance of CBAs (a board or a collection of boards). 7.1       Applicability Section 7 is applicable to CBAs that contribute to hardware DAL A, B or C functions. 7.2       Development Assurance of Circuit Board Assemblies (CBAs) While it is already a common practice for applicants to have an internal process to address the development of CBAs, it is necessary to clarify the expectations for development assurance, including the flow-down of the equipment/system requirements to the hardware. For consolidation of the development and/or the use of complex devices, it is essential to ensure consistency in the overall development assurance approach for the hardware domain. Moreover, definition of the CBA function is also necessary to enable the allocation of requirements and their flow-down to the complex devices. **Objective CBA-1** The applicant should have a process to address the development of CBAs that contain complex custom devices or complex COTS devices, in order to ensure that the CBA performs its intended function. The process should include requirements capture, validation, verification, and configuration management activities, and ensure an appropriate flow-down of requirements. See Appendix B for additional information. Note: The applicant’s process to address the development of the CBA may be defined together with the equipment process, when relevant. 8          RELATED REGULATORY, ADVISORY AND INDUSTRY MATERIAL (a)       Related EASA Certification Specifications (CSs) (1)       CS-23, Certification Specifications and Acceptable Means of Compliance for Normal, Utility, Aerobatic, and Commuter Category Aeroplanes (2)       CS-25, Certification Specifications and Acceptable Means of Compliance for Large Aeroplanes (3)       CS-27, Certification Specifications and Acceptable Means of Compliance for Small Rotorcraft (4)       CS-29, Certification Specifications and Acceptable Means of Compliance for Large Rotorcraft (5)       CS-E, Certification Specifications and Acceptable Means of Compliance for Engines,and [AMC 20-3B](#_DxCrossRefBm421436786), Certification of Engines Equipped with Electronic Engine Control Systems (6)       CS-P, Certification Specifications for Propellers, and [AMC 20-1A](#_DxCrossRefBm421436781), Certification of Aircraft Propulsion Systems Equipped with Electronic Control Systems (7)       CS-ETSO, Certification Specifications for European Technical Standard Orders (8)       CS-APU, Certification Specifications for Auxiliary Power Units; and [AMC 20-2B](#_DxCrossRefBm421436782), Certification of Essential APU Equipped with Electronic Controls **(b)       FAA Advisory Circulars (ACs)** (1)       AC 20-152, *Development Assurance for Airborne Electronic Hardware* (2)       AC 00-72, *Best Practices for Airborne Electronic Hardware Design Assurance Using EUROCAE ED-80( ) and RTCA DO-254( )* (3)       AC 23.1309-1, *System Safety Analysis and Assessment for Part 23 Airplanes* (4)       AC 25.1309-1, *System Design and Analysis* (5)       AC 27-1309, *Equipment, Systems, and Installations (included in AC 27-1, Certification of Normal Category Rotorcraft)* (6)       AC 29-1309, *Equipment, Systems, and Installations (included in AC 29-2, Certification of Transport Category Rotorcraft)* (c)       Industry Documents (1)       EUROCAE ED-79A, *Guidelines for Development of Civil Aircraft and Systems*, dated December 2010 (2)       EUROCAE ED-80, *Design Assurance Guidance for Airborne Electronic Hardware*, dated April 2000 (3)       RTCA DO-254, *Design Assurance Guidance for Airborne Electronic Hardware*, dated 19 April 2000 (4)       SAE International Aerospace Recommended Practice (ARP) 4754A, *Guidelines for Development of Civil Aircraft and Systems*, dated 21 December 2010 (5)       SAE International Aerospace Recommended Practice (ARP) 4761, *Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment*, dated December 1996 9          AVAILABILITY OF DOCUMENTS (a)       EASA Certification Specifications (CSs) and Acceptable Means of Compliance (AMC) may be downloaded from the EASA website: [www.easa.europa.eu](http://www.easa.europa.eu) (b)       FAA Advisory Circulars (ACs) may be downloaded from the FAA website: [www.faa.gov](http://www.faa.gov) (c)       EUROCAE documents may be purchased from:             European Organisation for Civil Aviation Equipment 102 rue Etienne Dolet, 92240 Malakoff, France Telephone: +33 1 40 92 79 30, Fax: +33 1 46 55 62 65 (Email: eurocae@eurocae.net, website: [www.eurocae.net](http://www.eurocae.net)) (d)       RTCA documents may be purchased from: RTCA, Inc. 1150 18th Street NW, Suite 910, Washington DC 20036, USA (Email: info@rtca.org, website: [www.rtca.org](http://www.rtca.org)) [Amdt 20/19] AMC 20-152A Development Assurance for Airborne Electronic Hardware (AEH) ED Decision 2020/010/R 1 PURPOSE 1.1 This AMC describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the electronic hardware aspects of airborne systems and equipment in product certification or ETSO authorisation. Compliance with this AMC is not mandatory, and an applicant may elect to use an alternative means of compliance. However, the alternative means of compliance must meet the relevant requirements, ensure an equivalent level of safety, and be approved by EASA on a product or ETSO article basis. 1.2 This AMC recognises EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, dated April 2000, and RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, dated 19 April 2000. 1.3 This AMC describes when to apply EUROCAE ED-80/RTCA DO-254, and it supplements EUROCAE ED-80/RTCA DO-254 with additional guidance and clarification for the development of custom devices, including the use of commercial off-the-shelf (COTS) intellectual property (IP), for the use of COTS devices and for the development of circuit board assemblies (CBAs). The additional guidance and clarifications are provided in the form of objectives. The applicant is expected to describe the process and activities to satisfy the objectives of this AMC. Note: EUROCAE ED is hereafter referred to as ‘ED’; RTCA DO is hereafter referred to as ‘DO’. Where the notation ‘ED-80/DO-254’ appears in this document, the referenced documents are recognised as being equivalent. 1.4 This AMC does not address the Single Event Effects (SEE) aspects or the assessment of the hardware susceptibility to SEE. AMC SEE aspects are usually addressed through a certification review item (CRI), and further guidance may be found in EASA CM-AS-004 Issue 01, issued 8 January 2018. However, the Plan for Hardware Aspects of Certification may still be used to document the certification considerations for SEE. 2 APPLICABILITY This AMC may be used by applicants, design approval holders, and developers of airborne systems and equipment containing airborne electronic hardware (AEH) to be installed on type-certified aircraft, engines, and propellers. This applicability includes the developers of ETSO articles. This AMC is applicable to AEH that contributes to hardware development assurance level (DAL) A, DAL B, or DAL C functions. When an objective is not applicable to a specific hardware DAL, the applicability restriction is directly indicated within the objective text with the following convention, for instance ‘For DAL A hardware, …’ For AEH contributing to hardware DAL C functions, only a limited set of objectives applies. Even though there is a benefit in having a structured development process that ensures a proper flow-down of requirements to the hardware and the fulfilment by the hardware of the intended function, the use of this AMC is not required for AEH contributing to hardware DAL D functions. Appendix B provides some clarifications that may be used to ensure that the DAL D hardware performs its intended function. 3 DOCUMENT HISTORY This document is the initial issue of AMC 20-152. This initial issue, jointly developed with FAA, is intentionally set at Revision A. 4 BACKGROUND This AMC is related to the development of custom devices in AEH, including the use of commercial off-the-shelf intellectual property (COTS IP) within custom devices, the use of COTS devices, and the development of circuit board assemblies (CBAs). Each of these topics is organised with: background information dedicated to each major topic, — applicability, and — sections where objectives are described and uniquely identified. A unique identifier for each objective is defined with a prefix and an index number (i) as follows: — for the development of custom devices, the identifier is ‘CD-i’; — for the use of COTS IP in custom devices, the identifier is ‘IP-i’; — for the use of COTS devices, the identifier is ‘COTS-i’; — for the development of CBAs, the identifier is ‘CBA-i’. Objectives are also differentiated from the rest of the text by formatting in italics. The applicant should document in the Plan for Hardware Aspects of Certification (PHAC), or any other related planning document, the process and activities that the applicant intends to perform to satisfy the objectives of this AMC. The PHAC, as well as those related planning documents, should be submitted for certification. 5 CUSTOM DEVICE DEVELOPMENT This section provides guidance for the development assurance of programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs), which are collectively referred to as ‘custom devices’. These custom devices are addressed in ED-80/DO-254, Section 1.2, Item 3 as ‘custom micro-coded components’. Developing a custom device demands a well-defined development process. However, it is understood that the process to develop complex custom devices requires more comprehensive activities and artefacts than for a simple device. Section 5.1 identifies custom devices that are within the scope of this AMC. Section 5.2 provides guidance on simple/complex classification for custom devices. Section 5.3 provides guidance on development assurance for complex custom devices. Section 5.4 provides guidance on development assurance for simple custom devices. In particular, Section 5.4 defines which sections from 5.5 to 5.11 are applicable to the development assurance of simple electronic devices. Sections 5.5 to 5.10 provide clarifications on ED-80/DO-254. Section 5.11 provides background information and guidance specific to COTS IP used in custom devices. 5.1 Applicability to Custom Devices Section 5 is applicable to a digital- or mixed-signal custom device that contributes to hardware DAL A, B or C functions. Appendix A to ED-80/DO-254 modulates the ED-80/DO-254 life-cycle data based on the DAL allocated to the hardware function. This document recognises Appendix A for the modulation of the life-cycle data according to the hardware DAL for the development of custom devices. 5.2 Simple/Complex Classification ED-80/DO-254 introduces the notion of simple and complex hardware items. This section clarifies and provides criteria that could be used to classify a device as simple by considering the design content of the custom device, and subsequently, the ability to comprehensively verify the device. A hardware custom device is classified as simple only if a technical assessment of the design content supports the ability of the device to be verified by a comprehensive combination of deterministic tests and analyses that ensure correct functional performance under all foreseeable operating conditions with no anomalous behaviour. The following criteria should be used for assessing whether a device should be classified as simple: — simplicity of the functions and their number, — number and the simplicity of the interfaces, — simplicity of the data/signal processing or transfer functions, and — independence of functions/blocks/stages. Additional criteria specific to the digital part of the design include: — whether the design is synchronous or asynchronous, — number of independent clocks, — number of state machines, number of states and state transitions per state machine, and — independence between the state machines. The applicant may propose other or additional criteria for the technical assessment of simplicity. When an item cannot be classified as simple, it should be classified as complex. However, note that an item constructed entirely from simple items may itself be complex. **Objective CD-1** For each custom device, the applicant should document in the PHAC or any related planning document: 1. the development assurance level, 2. the simple or complex classification, and 3. if a device is classified as simple, the justification based on the simple classification criteria. 5.3 Development Assurance for Complex Custom Devices ED-80/DO-254 is recognised as the industry standard for the development assurance of complex custom devices. The applicant should satisfy ED-80/DO-254 and the additional objectives or clarifications described in this AMC from Sections 5.5 to 5.11. 5.4 Development Assurance for Simple Custom Devices For the development of simple custom devices, it is understood that the life-cycle data might be significantly reduced compared with the data required for a complex custom device. ED-80/DO-254 acknowledges that the documentation for the design process of a simple hardware device is less extensive than the one needed for a complex device. In addition, while verification and configuration management are also needed, these supporting processes also require less documentation for a simple device. However, it is important that a simple custom device performs its intended function, and is under configuration management, thus allowing the device to be reproduced, conformed, and analysed to ensure continued operational safety. **Objective CD-2** The applicant should propose a process in the PHAC, or any other appropriate planning document, to develop simple custom devices which encompasses the following: 1. definition of the device functions, 2. complete verification of the device functions through tests and analyses, 3. configuration management of the device, including problem reporting and the instructions to reproduce the device, 4. assessment of the build conformance of the device. Sections 5.5.2.4 and 5.5.2.5 of this document also apply to the verification process for simple custom devices. The life-cycle data for simple devices can be combined with other hardware data. If tools are used for the simple custom device development process, the objectives or clarifications of those objectives described in Section 5.8 of this document are also applicable. When the applicant intends to reuse a previously developed simple device, ED-80/DO-254 Section 11.1 and the clarifications provided in Section 5.9 of this document should be used. If the applicant intends to use COTS IP, the objectives or clarifications of those objectives described in Section 5.11 of this document are also applicable. 5.5 Clarifications to ED-80/DO-254 Validation and Verification Processes 5.5.1 Validation Process Establishing a correct and complete set of requirements is the cornerstone of the development assurance process. ED-80/DO-254 Section 6.1 addresses the validation process to ensure the completeness and correctness of derived requirements. Nevertheless, the validation process is essential for all the requirements. Indeed, the upper-level requirements allocated to the custom device are often refined, decomposed or restated at the custom device level, and in terms that support the hardware design. These custom device requirements, which are traceable from/to the upper-level requirements and, therefore, not considered to be ‘derived’, should also be correct and complete. **Objective CD-3** The applicant should validate all the custom device requirements by following the ED-80/DO254 validation process (ED-80/DO-254 Section 6). This validation activity covers both derived and non-derived requirements. For DAL A and B development, validation activities should be performed with independence. Note: ED-80/DO-254 Appendix A defines acceptable means for establishing independence. 5.5.2 Verification Process ED-80/DO-254 broadly describes the verification process, but additional guidance is needed to ensure the verification of the custom device is complete, particularly in the area of: — design reviews, — reviews of test cases and procedures, and — verification of the implementation. 5.5.2.1 Conceptual Design Review Conceptual design is the process of generating a high-level design description from the hardware requirements (see ED-80/DO-254 Section 5.2). The conceptual design review is typically used to ensure that the outcome of the conceptual design activities (see ED-80/DO254 Section 5.2.2) is consistent with the requirements, and identifies constraints for the interfacing components (hardware or software) and architectural constraints for the detailed design activities of the custom device. Since this conceptual design review is already addressed in ED-80/DO-254 Section 5.2.2 through the note, no separate objective is needed. 5.5.2.2 Detailed Design Review Detailed design is the process of generating, from the conceptual design and the requirements, a hardware description language (HDL) or analogue representation of the design, constraints for the implementation (e.g. timing constraints, pinout, I/O characteristics), and the hardware– software interface description. ED-80/DO-254 introduces design reviews in Section 6.3.3.2. A design review is considered to be an essential step during the detailed design process (ED-80/DO-254 Section 5.3) supporting the implementation process, and complementing requirements-based verification. **Objective CD-4** For hardware DAL A or DAL B, the applicant should review the detailed design with respect to the design standards, and review the traceability between the detailed design and the custom device requirements, in order to demonstrate that the detailed design covers the custom device requirements, is consistent with the conceptual design, and is compliant with the hardware design standards. For hardware DAL C, the applicant should demonstrate that the detailed design satisfies the hardware design standards. 5.5.2.3 Implementation Review Within a custom device development process, tools are used to convert the detailed design data into the physical implementation. While ED-80/DO-254 does not explicitly address it, a review of the design tool reports (e.g. synthesis and place and route reports) is necessary to ensure that the execution of the tool to generate its output was performed correctly. **Objective CD-5** When tools are used to convert the detailed design data into the physical implementation, the applicant should review the design tool reports (e.g. synthesis and place and route reports) to ensure that the tool executed properly when generating the output. 5.5.2.4 Review of Verification Cases and Procedures ED-80/DO-254 introduces verification coverage analysis in Section 6.2.2 Item 4 to satisfy the ED-80/DO-254 verification process objectives and determine whether the verification process is correct and complete. A part of the coverage analysis is clarified by the following objective. **Objective CD-6** Each verification case and procedure should be reviewed to confirm that it is appropriate for the requirements to which it traces and that the requirements are correctly and completely covered by the verification cases and procedures. 5.5.2.5 Verification of the Timing Performance of the Implementation ED-80/DO-254 Section 6.2 addresses the verification of the implementation. The implementation results from the process to generate the physical custom device from the detailed design data. The post-layout netlist is the closest virtual representation of the physical custom device, resulting from synthesis (for the digital part of the device) and place and route. While it is recommended to test the implementation in its intended operational environment (i.e. by a physical test), verification using the post-layout netlist may be necessary to complement the verification of the implementation for certain requirements (e.g. features not accessible from the I/O pins of the device, timing, abnormal conditions, or robustness cases). In such cases, the coverage of the requirements by means other than a physical test should be justified. The requirement to capture the activities in ED-80/DO-254 Section 5.1.2 Item 4.g introduces the need for the requirements to address signal timing characteristics under normal- and worst-case conditions. Nevertheless, ED-80/DO-254 does not explicitly address the necessity to verify the performance of the device under all possible (best-case and worst-case) timing conditions that could possibly occur during the operation of the device. The following objective clarifies the need to take into account the variation of the environmental conditions (temperature, voltage, etc.) during the evaluation of the timing performance of the design, as well as the semiconductor device process variations. **Objective CD-7** The applicant should verify the timing performance of the design accounting for the temperature and power supply variations applied to the device and the semiconductor device fabrication process variations as characterised by the manufacturer of the semiconductor device. Note: Static timing analysis (STA) with the necessary timing constraints and conditions is one of the possible means of compliance with this objective for the digital parts of custom devices. 5.6 Clarifications to ED-80/DO-254 ‘Robustness Aspects’ ED-80/DO-254 mentions robustness defects but does not explicitly address robustness. The robustness of the design is defined as the expected behaviour of the design under abnormal and boundary/worstcase operating conditions of the inputs and internal design states. These conditions are often captured as derived requirements when they are not allocated from the upper-level process. When subjected to these conditions, it is understood that the design may not continue to perform as it would under normal conditions. **Objective CD-8** For DAL A or DAL B hardware, the abnormal and boundary conditions and the associated expected behaviour of the design should be defined as requirements. 5.7 Recognition of HDL Code Coverage Method HDL code coverage analysis is an assessment of whether the HDL code of the design has been exercised through HDL simulations. The HDL code coverage method provides an assessment of the coverage of the design logic structure, giving an indication of which aspects of the logic structure are exercised and which are not. When performed during requirements-based verification (per ED-80/DO-254 Section 6.2), HDL code coverage is recognised as a method to perform ED-80/DO-254 elemental analysis per Appendix B Section 3.3.1 for digital devices. HDL code coverage supports the assessment of whether the HDL code elements are fully covered by requirements-based simulations. As such, it does not represent an assessment of the completeness of the requirements-based testing activities or the effectiveness of the requirement coverage. **Objective CD-9** For hardware DAL A or DAL B, where HDL code coverage is used to perform elemental analysis (ED-80/DO-254 Appendix B Section 3.3.1), the applicant should define in the planning documents the detailed coverage criteria of the HDL code elements used in the design. The criteria should ensure coverage over the various cases of the HDL code elements used in the design (e.g. branches, conditions, etc.). Any non-covered case or element should be analysed and justified. Note: Code coverage might need to be complemented by additional analysis for any hardware items that are identified as not covered by the code coverage analysis, in order to complete the elemental analysis of all elements. This situation may occur in the use of some COTS IP instantiations. 5.8 Clarifications to ED-80/DO-254 ‘Tool Assessment and Qualification’ ED-80/DO-254 introduces the notion of tool assessment and qualification. ED-80/DO-254 Figure 11-1 includes a flow chart indicating the tool assessment considerations and activities, and provides guidance for when tool qualification may be necessary. This AMC uses the flow chart and its related text as a basis for providing further clarification, as follows: ED-80/DO-254 — Figure 11-1 Item 1 — Identify the Tool Information capturing the environment required for tool operation and the tool revision should be included with the tool identification. ED-80/DO-254 — Figure 11-1 Item 2 — Identify the Process the Tool Supports When identifying the design or verification process that the tool supports, it is important to also identify what purpose or activity within the hardware development process the tool satisfies. While assessing the tool limitations, evidence of formal assessment of the tool problem reports is not required if the tool output has been completely and independently assessed. ED-80/DO-254 — Figure 11-1 Item 3 — Is the Tool Output Independently Assessed? The purpose of assessing the tool output is to completely cover, with an independent means, the potential errors that the tool could introduce into the design or fail to detect during verification. **Objective CD-10** When the applicant intends to independently assess a tool output, the applicant should propose an independent assessment that verifies the tool output is correct. The independent assessment should justify that there is sufficient coverage of the tool output. The completeness of the tool assessment should be based on the design/implementation and/or verification objectives that the tool is used to satisfy. ED-80/DO-254 — Figure 11-1 Item 4 — Is the Tool a Level A, B or C Design Tool or a Level A or B Verification Tool? ED-80/DO-254 Figure 11-1 Item 4 of the tool assessment/qualification flow excludes the need for activities for tools ‘used to assess the completion of verification testing, such as in an elemental analysis’. The last statement is misleading regarding the intent of code coverage tools used for elemental analysis. As stated in Section 5.7 of this document, ‘when a code coverage tool is used for elemental analysis, it does not represent an assessment of the completeness of the requirements-based testing activities or the effectiveness of the requirement coverage’. It is therefore necessary to provide some further clarifications. — This document recognises the Figure 11-1 Item 4 exclusion of tool assessment/qualification activities for code coverage tools only when they are used to assess whether the code has been exercised by requirements-based testing/simulations (elemental analysis). — If test cases or procedures are automatically generated by a tool and this tool uses coverage to determine the completion of the requirements verification, then the tool should be considered to be a verification tool to answer the question raised in Figure 11-1 Item 4. ED-80/DO-254 — Figure 11-1 Item 5 — Does the Tool have Relevant History? In ED-80/DO-254, the supporting text for Figure 11-1 Item 5 can be misinterpreted to suggest that when the tool has been previously used, no further tool assessment is necessary. Item 5 should be understood to mean that the applicant will provide sufficient data and justification to substantiate the relevance and credibility of the tool history. **Objective CD-11** When the applicant intends to claim credit for the relevant history of a tool, sufficient data should be provided as a part of the tool assessment to demonstrate that there is a relevant and credible tool history to justify that the tool will produce correct results for its proposed use. ED-80/DO-254 — Figure 11-1 Item 9 — Design Tool Qualification For design tools, contrary to the note in the supporting text for Figure 11-1 Item 9, the tool history should not be used as a stand-alone means of tool assessment and qualification. A relevant tool history may be used to compensate for some particular gaps in the tool assessment and qualification process, for example, to explain the method of independent assessment of the tool output. In this case, a relevant tool history is considered to be complementary data, providing more assurance for a tool. In addition to what is already referenced in ED-80/DO-254 Figure 11-1 Item 9 for tool qualification guidance, ED-12C/DO-178C and ED-215/DO-330 may also be used. 5.9 Clarifications to ED-80/DO-254 regarding Previously Developed Hardware (PDH) Previously developed hardware (PDH) is defined as custom-developed hardware that has been installed in an airborne system or equipment either approved through EASA type certification (TC/STC) or authorized through ETSOA. The section providing clarification on the use of PDH also covers PDH that was developed and approved prior to the use of ED-80/DO-254 in civil certification. This section provides guidance on the use of ED-80/DO-254 Section 11.1 for PDH. **Objective CD-12** When an applicant proposes to reuse PDH, the applicant should use ED-80/DO-254 Section 11.1 and its subordinate paragraphs. The applicant should perform the assessments and analyses required in ED-80/DO-254 Section 11.1 in order to ensure that using the PDH is valid and that the compliance shown during the previous approval was not compromised by any of the following: 1. Modification of the PDH for the new application or for obsolescence management; 2. Change to the function, change to its use, or change to a higher failure condition classification of the PDH in the new application; or 3. Change to the design environment of the PDH. The results should be documented in the PHAC or any other appropriate planning document. In the context of custom device development, any one of these three points potentially invalidates the original development assurance credit for the PDH. In case of change or modification, the applicant should assess these changes using ED-80/DO-254 Section 11.1 and its subordinate paragraphs. When the original design assurance of the PDH is invalidated by one of the above points, the custom device should be upgraded based on the assessment per ED-80/DO-254 Section 11.1. When upgrading the hardware, the applicant should consider the objectives of this document that are applicable per the assessment. 5.10 Clarifications to ED-80/DO-254 Appendix A This section clarifies the life-cycle data referenced in ED-80/DO-254 Appendix A as follows. — The row corresponding to 10.1.6 ‘Hardware Process Assurance Plan’ in Table A-1 should also indicate HC2 for Level C to be consistent with row 10.8. — The row corresponding to 10.2.2 ‘Hardware Design Standard’ in Table A-1 should also indicate HC2 for Level C. HDL Coding Standards are part of the Hardware Design Standards. — The row corresponding to 10.3.2.2 ‘Detailed Design Data’ in Table A-1 should indicate HC1 for Levels A, B and C. — The row corresponding to 10.4.2 ‘Hardware Review and Analysis Procedures’ in Table A-1 should also indicate HC2 for Level C to be consistent with row 10.4.3. — The Top-Level Drawing referenced in ED-80/DO-254 Appendix A corresponds to a Hardware Configuration Index (HCI) document. The HCI document completely identifies the hardware configuration, the embedded logic, and the development life-cycle data. To support consistent and accurate replication of the custom device (ED-80/DO-254 Section 7.1), the Top-Level Drawing includes the hardware life cycle environment or refers to a Hardware Environment Configuration Index (HECI) document. 5.11 Use of COTS IP in Custom Device Development This section addresses COTS IP that is instantiated within FPGAs/PLDs/ASICs during the development of the custom device. This section addresses COTS IP and its integration within custom devices and describes objectives to support the demonstration of compliance with the applicable airworthiness regulations for the hardware aspects of airborne systems and equipment certification. Section 5.11.2, on ‘Applicability to COTS IP’, identifies COTS IP that are within the scope of Section 5.11. 5.11.1 Background IP refers to design functions (design modules or functional blocks, including IP libraries) used to design and implement a part of or a complete custom device such as a PLD, FPGA, or ASIC. IP is considered to be commercial off-the-shelf intellectual property, i.e. ‘COTS IP’, when it is a commercially available function, used by a number of different users, in a variety of applications and installations. Custom IP, developed for a few specific aircraft equipment, is not considered to be COTS IP. COTS IP are available in various source formats. COTS IP are categorised as Soft IP, Firm IP, or Hard IP based on the stage in the custom device design flow where the IP is instantiated. A function can be a combination of source formats and each part needs to be addressed. Definitions for Soft IP, Firm IP, and Hard IP can be found in Appendix A ‘Glossary’. Figure 1 shows a ‘simplified’ design flow of a PLD, FPGA, or ASIC, and where Soft IP, Firm IP, and Hard IP are located in the design flow.  *Figure 1 — Position of COTS IP within a ‘simplified’ design representation flow* The availability of a COTS IP does not guarantee that it is suitable to be used in a custom device for aircraft systems. Some COTS IP may have been developed using ED-80/DO-254, and will therefore have the necessary life-cycle data to demonstrate satisfaction of ED-80/DO-254. However, most COTS IP are not developed to meet aviation development assurance standards and, therefore, there are risks associated with their use in a custom device for aircraft systems or equipment. The risks of using COTS IP may include: — Incomplete or missing documentation/data regarding: — the behavioural operation of the COTS IP, — how to integrate it into the design; — Insufficient verification performed by the COTS IP provider; — Deficient quality of the COTS IP. The potential for design errors may be increased by the lack of development assurance and/orby insufficient service experience. Possible design errors within COTS IP or in the use of COTS IP may lead to a failure mode. Riskfactors for these types of errors include: — Unknown level of rigour of the COTS IP design and verification process; — Misalignment between the intended usage of the COTS IP by the IP provider and the usage in the custom device by the IP user; — Incomplete or missing details regarding the detailed operation of the COTS IP; — Incorrect integration of the COTS IP with the rest of the custom device design; — Integrator lacking expertise with the function of the IP. Additionally, the COTS IP user completes the development of the integrated COTS IP up to the physical implementation of the device. The COTS IP user may introduce a design error while completing the physical implementation of the COTS IP because of the user’s incomplete knowledge of the internal design of the COTS IP. 5.11.2 Applicability to COTS IP Section 5.11 is applicable to COTS IP used in a custom device that meets the definition of ‘commercial off-the-shelf intellectual property’ in the Glossary of Appendix A. This scope encompasses digital, analogue, and mixed-signal COTS IP. Note: Analogue COTS IP is within the above-mentioned scope, as it could be instantiated within a custom, mixed-signal device. Section 5.11 is applicable to COTS IP contributing to hardware DAL A, B or C functions. Section 5.11 is applicable to Soft IP, Firm IP, and Hard IP that are inserted within a custom device by the applicant. However, Section 5.11 does not apply to Hard IP that is embedded in the silicon of an FPGA or a PLD by the FPGA/PLD device manufacturer. This type of IP is considered to be part of the COTS device, and is covered in Section 6 ‘Use of Commercial Off-the-Shelf Devices. 5.11.3 Development Assurance for COTS IP A COTS IP development assurance approach should be based on the category of the COTS IP (Soft, Firm, Hard) and on the identified risks of failure due to a design error in the COTS IP itself or an error in the way it is used in the custom device. This section provides objectives addressing development assurance when using COTS IP. These objectives are intended to cover the particular aspects of development when using COTS IP, and are expressed in connection with the custom device development process that follows ED-80/DO-254 and the custom device objectives of this document. The development aspects related to COTS IP start from the custom device process that captures the allocated requirements for the function that will be performed by the COTS IP. From this entry point, the following aspects provide a basis to define the development assurance objectives for the use of COTS IP: — Selection of the COTS IP, — Assessment of the IP provider and the IP data, — Planning activities, including the verification strategy, — Definition of the requirements/derived requirements, — Design integration, implementation, and verification of the COTS IP in the custom device. 5.11.3.1 Selection of the COTS IP to implement the function COTS IP can be available in different forms/source formats and various levels of quality. Some COTS IP may not be acceptable for use in airborne systems. The selection criteria below are intended to address the essential characteristics that are considered a minimum for the use of IP in custom AEH devices. **Objective IP-1** The applicant should select a COTS IP that is considered to be an acceptable solution, based on at least the following criteria: 1. The IP is technically suitable for implementing the intended function; 2. The description of the COTS IP architecture or IP design concept provides an understanding of the functionality, modes, and configuration of the IP. The description should also include an understanding of the source format or combination of source formats of the COTS IP; 3. The availability and quality of data and documentation allow the understanding of all aspects of the COTS IP functions, modes, and behaviour, and enable the integration and verification of the COTS IP (e.g. datasheets, application notes, user guide, knowledge of errata, etc.); 4. Information exists for the IP user to be able to create the physical implementation of the COTS IP (e.g. synthesis constraints, usage and performance limits, physical implementation, and routing instructions); 5. It can be demonstrated that the COTS IP fulfils its intended function. 5.11.3.2 Assessment of the COTS IP Provider and COTS IP Data **Objective IP-2** The applicant should assess the COTS IP provider and the associated data of the COTS IP based on at least the following criteria: 1. The IP provider provides all the information necessary for the integration of the COTS IP within the custom device and to support the implementation of the COTS IP within the device (e.g. synthesis constraints, usage domain, performance limits, physical implementation, and routing instructions); 2. The configurations, selectable options, and scalable modules of the COTS IP design are documented so that the implementation of the COTS IP can be properly managed; 3. The COTS IP has been verified by following a trustworthy and reliable process, and the verification covers the applicant’s specific use case for the COTS IP (including the used scale for scalable IP and the IP functions selected for selectable functions); 4. The known errors and limitations are available to the IP user, and there is a process to provide updated information to the IP user; 5. The COTS IP has service experience data that shows reliable operation for the applicant’s specific use case for the COTS IP. The assessment should be documented. The results of the assessment should be submitted together with the planning documents. 5.11.3.3 Planning of the Hardware Development Assurance Approach related to COTS IP 5.11.3.3.1 Complementary Development Assurance **Objective IP-3** When the IP-2 Objective criteria items 1, 2, 4 or 5 cannot be completely met using the IP provider’s data, the applicant should define an appropriate development assurance activity to mitigate the criteria that were not met and address the associated risk of development errors. The development assurance activity should be based on the ED-80/DO-254 objectives. Note: The results of the assessment of Objective IP-2 Item 3 are considered in Section 5.11.3.3.2. 5.11.3.3.2 The Verification Strategy for COTS IP Functions In addition to the verification of the custom device functions supported by the COTS IP, there is a need to ensure that the aspects related to the COTS IP and its usage are addressed. This section focuses on defining a verification strategy to cover those aspects. The verification performed by the COTS IP provider typically does not follow the ED-80/DO-254 verification process but may provide some credit to be used for the verification strategy. However, the verification process for COTS IP generally differs from one IP vendor to another, and the level of assurance varies depending on the IP provider’s development practices. The verification strategy may combine different means to complement the traditional requirements-based testing approach. Based on the applicant’s assessment of the IP provider and the IP data through Objective IP-2, the applicant is expected to establish a verification strategy. The aim of this verification strategy is to cover all three of the following aspects: — The COTS IP: the purpose is to ensure that the COTS IP is verified, addressing the risk identified from the IP-2 Item 3 objective; — Its implementation: the purpose is to ensure that the COTS IP still performs its allocated function, and that no design errors have been introduced by the design steps performed by the applicant (e.g. synthesis/place and route); — Its integration within the custom device: the purpose is to ensure that the COTS IP has been properly connected, configured, and constrained within the custom device. The strategy may accomplish more than one aspect within a common verification step. This section identifies a general objective for the verification of COTS IP used in a custom device, enabling various verification approaches. **Objective IP-4** The applicant should describe in the hardware verification plan, PHAC, or any related planning document, a verification strategy that should encompass all three of the following aspects: 1. The verification of the COTS IP itself, addressing the risk identified from the IP-2 Item 3 objective; 2. The verification of the COTS IP after the design steps performed by the applicant (e.g. synthesis/place and route); 3. The verification of the integrated COTS IP functions within the custom device. Note 1: Reliable and trustworthy test data, test cases or procedures from the COTS IP provider may be used as part of the verification strategy to satisfy this objective. Note 2: If the COTS IP implements functions based on an industry standard, proven standardised test vectors verifying compliance with the standard may be used in the verification strategy of the COTS IP. Note 3: The verification strategy covers at a minimum the used functions of the COTS IP and ensures that the unused functions are correctly disabled or deactivated and do not interfere with the used functions. 5.11.3.3.3 COTS IP and Planning Aspects The applicant has to define the activities that are needed for the hardware development assurance approach related to COTS IP. **Objective IP-5** The applicant should describe in the PHAC, or any related planning document, a hardware development assurance approach for using the COTS IP that at least includes: 1. identification of the selected COTS IP (version) and its source format(s) associated with the point(s) in the design flow where the COTS IP is integrated into the custom device; 2. a summary of the COTS IP functions; 3. the development assurance process that the applicant defines to satisfy the objectives of Section 5.11.3; 4. the process related to the design integration and to the usage of the COTS IP in the development process of the custom device; 5. tool assessment and qualification aspects when the applicant uses a tool to perform design and/or verification steps for the COTS IP. 5.11.3.4 Requirements for COTS IP Function and Validation Custom device requirements typically contain requirements that relate to the function supported by the COTS IP. The granularity of these requirements may be very different depending on the COTS IP function and the visibility of the functions supported by the IP at the custom device level. Depending on the extent of requirements-based testing as a part of the chosen verification strategy of the COTS IP, the level of detail and the granularity of the AEH custom device requirements may need to be refined to specifically address the COTS IP functions and the implementation of the COTS IP. In addition, requirements should be captured to encompass all the necessary design detail used to connect, configure, and constrain the COTS IP and properly integrate it into the AEH custom device. **Objective IP-6** The requirements related to the allocated COTS IP functions should be captured to an extent commensurate with the verification strategy. In addition, derived requirements should be captured to cover the following aspects associated with the integration of the COTS IP into the custom device design: 1. COTS IP used functions (including parameters, configuration, selectable aspects); 2. Deactivation or disabling of unused functions; 3. Correct control and use of the COTS IP, in accordance with the data from the COTS IP provider. When the applicant chooses a verification strategy (see Section 5.11.3.3.2) that solely relies on requirements-based testing, the ‘extent commensurate with the verification strategy’ corresponds to a complete requirement capture of the COTS IP following ED-80/DO-254. Regarding the validation aspects, the COTS IP requirements should be validated as a part of the validation process of the AEH custom device. 5.11.3.5 Verification The applicant should ensure that the COTS IP is verified as a part of the overall custom device verification process per ED-80/DO-254 and based on the verification strategy for the COTS IP that has been described in the PHAC or a related planning document. For the requirements-based verification part, the applicant should satisfy ED-80/DO-254 Section 6.2 for the verification of the requirements related to the COTS IP (see Section 5.11.3.4 above). This can be performed as a part of the overall custom device process, therefore there is no separate objective. 5.11.3.6 DO-254 Appendix B considerations When developing a hardware DAL A or B custom device, ED-80/DO-254 Appendix B is applicable. Code coverage analysis that is recognised as part of elemental analysis (refer to Section 5.7 of this document) might not be possible for the COTS IP part of the design. However, ED-80/DO-254 Appendix B offers other acceptable methods, including safety-specific analysis. The following objective further clarifies the expectations when using safety-specific analysis. **Objective IP-7** For COTS IP used in DAL A or DAL B hardware, the applicant should satisfy ED-80/DO-254 Appendix B. The applicant may choose safety-specific analysis methods to satisfy Appendix B on the COTS IP function and its integration within the custom device functions. This safety-specific analysis should identify the safety-sensitive portions of the COTS IP and the potential for design errors in the COTS IP that could affect the hardware DAL A and DAL B functions in the custom device or system. For unmitigated aspects of the safety-sensitive portions of the IP, the safety-specific analysis should determine which additional requirements, design features, and verification activities are required for the safe operation of the COTS IP in the custom device. Any additional requirements, design features and/or verification activities that result from the analysis should be fed back to the appropriate process. 6. USE OF COMMERCIAL OFF-THE-SHELF DEVICES Applicants are increasingly using COTS electronic devices in aircraft/engines/propellers/ airborne systems, which may have safety implications for the aircraft, engines/propellers, or systems. Section 6 addresses the use of COTS devices through objectives that support the demonstration of compliance with the applicable airworthiness regulations for hardware aspects of airborne systems and equipment certification when using complex COTS devices. Section 6.2 ‘Applicability to COTS devices’ enables applicants to identify the COTS devices that are within the scope of Section 6. Note: The term ‘COTS device’ used in this document applies to a semiconductor product that is fully encapsulated in a package. This term does not apply to circuit board assemblies (CBAs). 6.1 Background COTS devices continue to increase in complexity and are highly configurable. COTS devices provide ‘off-the-shelf’ already developed functions, some of which are highly complex. Their development and production processes undergo a semiconductor industry qualification based on their intended market (consumer, automotive, telecom, etc.). Their usage by the aerospace industry provides additional integration and higher performance capabilities than were possible in the past. The design data for these COTS devices is usually not available to the COTS user. Since these devices are generally not developed for airborne system purposes, assurance has not been demonstrated that the rigour of a COTS manufacturer’s development process is commensurate with the aviation safety risks. ED-80/DO-254 introduces a basis for the development assurance for the use of COTS devices in Section 11.2 ‘COTS components usage’. This section states that ‘the use of COTS components will be verified through the overall design process, including the supporting processes’. Since ED-80/DO-254 was released in the year 2000, the number of functions embedded and integrated in a single COTS device has significantly increased. Functions which were previously split into various components, making the interface between those components accessible for verification, are now embedded within a single chip. While there are clearly some benefits of integrating more functions within a device, the increased level of integration makes it difficult for the user to verify the different hardware functions in the device due to lack of access to the interfaces between functions. Since these devices are more complex and highly configurable than the older separate devices, the risk is greater that the COTS device will not achieve the intended function in particular use cases over the required operating conditions. Furthermore, some additional assurance is needed because design errors may still be discovered after the COTS device is released to the market, or when an applicant extends the use of the device beyond the manufacturer’s specifications. 6.2 Applicability to COTS Devices Section 6 is applicable to digital, hybrid, and mixed-signal COTS devices that contribute to hardware DAL A, B or C functions. For COTS devices contributing to hardware DAL C functions, a limited set of the objectives of this section will apply. Section 6 is also applicable to FPGA and PLD devices that embed Hard IP (see definition) in their produced/manufactured silicon, but only for the COTS part of the FPGAs/PLDs. Section 6.4 only applies to COTS devices that are complex, as determined by the following COTS complexity assessment. 6.3 COTS Complexity Assessment In order to define which COTS devices are complex, the following high-level criteria should be used, considering all functions of the device, including any functions intended to be unused: A COTS device is complex when the device: 1. has multiple functional elements that can interact with each other; and 2. offers a significant number of functional modes; and 3. offers configurability of the functions, allowing different data/signal flows and different resource sharing within the device. Or when the device: 4. contains advanced data processing, advanced switching, or multiple processing elements (e.g. multicore processors, graphics processing, networking, complex bus switching, interconnect fabrics with multiple masters, etc.). For complex COTS devices, it is impractical to completely verify all possible configurations of the device, and it is difficult to identify all potential failures. **Objective COTS-1** The applicant should assess the complexity of the COTS devices used in the design according to the high-level criteria of Section 6.3, and document the list of relevant devices (see Note 1), including the classification rationale, in the PHAC or any related hardware planning document. Note 1: The applicant is not expected to assess the complete bill of material to satisfy the above objective, but only those devices that are relevant for the classification, including devices that are at the boundary between simple and complex. The resulting classification (simple or complex) for those devices that are at the boundary and those that are definitely complex should be documented. Note 2: A classification rationale is required for those devices that are at the boundary (meeting a part of the high-level criteria) and are classified as simple. Some examples of classification are provided in the GM Appendix for illustration. 6.4 Development Assurance for Use of Complex COTS ED-80/DO-254 Section 11.2.1 identifies some electronic component management process (ECMP) items when using a COTS device. ED-80/DO-254 Section 11.2.2 and Section 6.1 of this document identify some concerns with using a COTS device. The following objectives acknowledge and supplement ED-80/DO-254 Section 11.2 in clarifying how to gain certification credit when using complex COTS devices. 6.4.1 Electronic Component Management Process (ECMP) As stated in ED-80/DO-254 Section 11.2, ‘the use of an electronic component management process, in conjunction with the design process, provides the basis for COTS components usage.’ **Objective COTS-2** The applicant should ensure that an electronic component management process (ECMP) exists to address the selection, qualification, and configuration management of COTS devices. The ECMP should also address the access to component data such as the user manual, the datasheet, errata, installation manual, and access to information on changes made by the component manufacturer. As part of the ECMP, for devices contributing to hardware DAL A or B functions, the process for selecting a complex COTS device should consider the maturity of the COTS device and, where risks are identified, they should be appropriately mitigated. Note: Recognised industry standards describing the principles of electronic component management may be used to support the development of the ECMP. See Appendix B. 6.4.1.1 Using a Device outside Ranges of Values Specified in its Datasheet The device reliability is established by the device manufacturer through the device qualification process (see definition of ‘qualification of a device’ in the glossary). ED-80/DO254 Section 11.2.1 Item 6 mentions that a device is selected based on the technical suitability of the device for the intended application. In some cases, the applicant may need to use the device outside the specified operating conditions guaranteed by the device manufacturer. ED-80/DO-254 Section 11.2.1 Item 4 and Item 6 should be addressed when the device is used outside its guaranteed specification. The following objective describes what to achieve when using a device outside the ranges of values specified in its datasheet. **Objective COTS-3** When the complex COTS device is used outside the limits of the device manufacturer’s specification (such as the recommended operating limits), the applicant should establish the reliability and the technical suitability of the device in the intended application. 6.4.1.2 Considerations when the COTS Device has Embedded Microcode COTS devices may need microcode to execute some hardware functions. When those functions are used by the applicant, there is a risk if the microcode has not been verified by the device manufacturer during the COTS device qualification, or if the microcode is proposed to be modified by the applicant. If the microcode is delivered by the device manufacturer, is controlled by the device manufacturer’s configuration management system, and is qualified together with the device by the device manufacturer, it is accepted that the microcode is part of the qualified COTS device. If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the microcode cannot be considered to be part of the qualified COTS device. **Objective COTS-4** If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the applicant should ensure that a means of compliance for this microcode integrated within the COTS device is proposed by the appropriate process, and is commensurate with the usage of the COTS device. Note: The PHAC (or any other related planning document) should document the existence of the microcode and refer to the process (hardware, software, system) where it is addressed. 6.4.2 COTS Device Malfunctions Some COTS devices may contain errors that may or may not have been detected by the devicemanufacturer. **Objective COTS-5** The applicant should assess the errata of the COTS device that are relevant to the use of the device in the intended application, and identify and verify the means of mitigation for those errata. If the mitigation means is not implemented in hardware, the mitigation means should be fed back to and verified by the appropriate process. Note: The above objective refers to any mitigation means (such as hardware, software, system, or other means). **Objective COTS-6** The applicant should identify the failure modes of the used functions of the device and the possible associated common modes, and feed both of these back to the system safety assessment process. 6.4.3 Usage of COTS Devices This section focuses on the usage of complex COTS devices, while Section 7 covers the overall circuit board assembly development process. This Section 6.4.3 refers to the term ’intended function of the hardware’, which is considered to be defined through the CBA development process. Complex COTS devices can have multiple functions and many configurations of those functions. The configuration of a device should be managed in order to provide the ability to consistently apply the required configuration settings, to replicate the configuration on another item, and to modify the configuration in a controlled manner, when modification is necessary. The configuration of the device addresses at least the following topics: — Used functions (e.g. identification of each function, configuration characteristics, modes of operation), — Unused functions and the means (internal/external) used to deactivate them, — Means to control any inadvertent activation of the unused functions, or inadvertent deactivation of the used functions, — Means to manage device resets, — Power-on configuration, — Clocking configuration (e.g. identification of the different clock domains), and — Operating conditions (e.g. clock frequency, power supply level, temperature, etc.). **Objective COTS-7** The applicant should ensure that the usage of the COTS device has been defined and verified according to the intended function of the hardware. This also includes the hardware–software interface and the hardware to (other) hardware interface. When a COTS device is used in a hardware DAL A or B function, the applicant should show that unused functions of the COTS device do not compromise the integrity and availability of the COTS device’s used functions. Note 1: For unused functions of the COTS device, it is recommended that an effective deactivation means is used and verified, when available. Note 2: Verification should be performed at an appropriate level (hardware, software, equipment). ED-80/DO-254 Section 10.3.2.2.4 introduces hardware/software (HW/SW) interface data, which can be used as a reference to define the software interface data of the COTS device. Some additional consideration should be given to the critical configuration settings. Those are defined as the settings that are deemed necessary by the applicant for the proper usage of the hardware, which, if inadvertently altered, could change the behaviour of the COTS device, causing it to no longer fulfil the hardware intended function. **Objective COTS-8** If the complex COTS device contributes to DAL A or B functions, the applicant should develop and verify a means that ensures an appropriate mitigation is specified in the event of any inadvertent alteration of the ‘critical configuration settings’ of the COTS device. Note: The mitigation means might be defined at the hardware, software, or system level, or a combination of these. The mitigation means may also be defined by the safety assessment process. 7 Development Assurance of Circuit Board Assemblies (CBAs) This section provides guidance for the development assurance of CBAs (a board or a collection of boards). 7.1 Applicability Section 7 is applicable to CBAs that contribute to hardware DAL A, B or C functions. 7.2 Development Assurance of Circuit Board Assemblies (CBAs) While it is already a common practice for applicants to have an internal process to address the development of CBAs, it is necessary to clarify the expectations for development assurance, including the flow-down of the equipment/system requirements to the hardware. For consolidation of the development and/or the use of complex devices, it is essential to ensure consistency in the overall development assurance approach for the hardware domain. Moreover, definition of the CBA function is also necessary to enable the allocation of requirements and their flow-down to the complex devices. **Objective CBA-1** The applicant should have a process to address the development of CBAs that contain complex custom devices or complex COTS devices, in order to ensure that the CBA performs its intended function. The process should include requirements capture, validation, verification, and configuration management activities, and ensure an appropriate flow-down of requirements. See Appendix B for additional information. Note: The applicant’s process to address the development of the CBA may be defined together with the equipment process, when relevant. 8 RELATED REGULATORY, ADVISORY AND INDUSTRY MATERIAL (a) Related EASA Certification Specifications (CSs) (1) CS-23, Certification Specifications and Acceptable Means of Compliance for Normal, Utility, Aerobatic, and Commuter Category Aeroplanes (2) CS-25, Certification Specifications and Acceptable Means of Compliance for Large Aeroplanes (3) CS-27, Certification Specifications and Acceptable Means of Compliance for Small Rotorcraft (4) CS-29, Certification Specifications and Acceptable Means of Compliance for Large Rotorcraft (5) CS-E, Certification Specifications and Acceptable Means of Compliance for Engines,and [AMC 20-3B](#_DxCrossRefBm1701657980), Certification of Engines Equipped with Electronic Engine Control Systems (6) CS-P, Certification Specifications for Propellers, and [AMC 20-1A](#_DxCrossRefBm1701657975), Certification of Aircraft Propulsion Systems Equipped with Electronic Control Systems (7) CS-ETSO, Certification Specifications for European Technical Standard Orders (8) CS-APU, Certification Specifications for Auxiliary Power Units; and [AMC 20-2B](#_DxCrossRefBm1701657976), Certification of Essential APU Equipped with Electronic Controls **(b) FAA Advisory Circulars (ACs)** (1) AC 20-152, *Development Assurance for Airborne Electronic Hardware* (2) AC 00-72, *Best Practices for Airborne Electronic Hardware Design Assurance Using EUROCAE ED-80( ) and RTCA DO-254( )* (3) AC 23.1309-1, *System Safety Analysis and Assessment for Part 23 Airplanes* (4) AC 25.1309-1, *System Design and Analysis* (5) AC 27-1309, *Equipment, Systems, and Installations (included in AC 27-1, Certification of Normal Category Rotorcraft)* (6) AC 29-1309, *Equipment, Systems, and Installations (included in AC 29-2, Certification of Transport Category Rotorcraft)* (c) Industry Documents (1) EUROCAE ED-79A, *Guidelines for Development of Civil Aircraft and Systems*, dated December 2010 (2) EUROCAE ED-80, *Design Assurance Guidance for Airborne Electronic Hardware*, dated April 2000 (3) RTCA DO-254, *Design Assurance Guidance for Airborne Electronic Hardware*, dated 19 April 2000 (4) SAE International Aerospace Recommended Practice (ARP) 4754A, *Guidelines for Development of Civil Aircraft and Systems*, dated 21 December 2010 (5) SAE International Aerospace Recommended Practice (ARP) 4761, *Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment*, dated December 1996 9 AVAILABILITY OF DOCUMENTS (a) EASA Certification Specifications (CSs) and Acceptable Means of Compliance (AMC) may be downloaded from the EASA website: [www.easa.europa.eu](http://www.easa.europa.eu) (b) FAA Advisory Circulars (ACs) may be downloaded from the FAA website: [www.faa.gov](http://www.faa.gov) (c) EUROCAE documents may be purchased from: European Organisation for Civil Aviation Equipment 102 rue Etienne Dolet, 92240 Malakoff, France Telephone: +33 1 40 92 79 30, Fax: +33 1 46 55 62 65 (Email: eurocae@eurocae.net, website: [www.eurocae.net](http://www.eurocae.net)) (d) RTCA documents may be purchased from: RTCA, Inc. 1150 18th Street NW, Suite 910, Washington DC 20036, USA (Email: info@rtca.org, website: [www.rtca.org](http://www.rtca.org)) [Amdt 20/19] AMC 20-152A Development Assurance for Airborne Electronic Hardware (AEH) ED Decision 2020/010/R 1          PURPOSE 1.1       This AMC describes an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the electronic hardware aspects of airborne systems and equipment in product certification or ETSO authorisation. Compliance with this AMC is not mandatory, and an applicant may elect to use an alternative means of compliance. However, the alternative means of compliance must meet the relevant requirements, ensure an equivalent level of safety, and be approved by EASA on a product or ETSO article basis. 1.2       This AMC recognises EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, dated April 2000, and RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, dated 19 April 2000. 1.3       This AMC describes when to apply EUROCAE ED-80/RTCA DO-254, and it supplements EUROCAE ED-80/RTCA DO-254 with additional guidance and clarification for the development of custom devices, including the use of commercial off-the-shelf (COTS) intellectual property (IP), for the use of COTS devices and for the development of circuit board assemblies (CBAs). The additional guidance and clarifications are provided in the form of objectives. The applicant is expected to describe the process and activities to satisfy the objectives of this AMC. Note: EUROCAE ED is hereafter referred to as ‘ED’; RTCA DO is hereafter referred to as ‘DO’. Where the notation ‘ED-80/DO-254’ appears in this document, the referenced documents are recognised as being equivalent. 1.4       This AMC does not address the Single Event Effects (SEE) aspects or the assessment of the hardware susceptibility to SEE. AMC SEE aspects are usually addressed through a certification review item (CRI), and further guidance may be found in EASA CM-AS-004 Issue 01, issued 8 January 2018. However, the Plan for Hardware Aspects of Certification may still be used to document the certification considerations for SEE. 2          APPLICABILITY This AMC may be used by applicants, design approval holders, and developers of airborne systems and equipment containing airborne electronic hardware (AEH) to be installed on type-certified aircraft, engines, and propellers. This applicability includes the developers of ETSO articles. This AMC is applicable to AEH that contributes to hardware development assurance level (DAL) A, DAL B, or DAL C functions. When an objective is not applicable to a specific hardware DAL, the applicability restriction is directly indicated within the objective text with the following convention, for instance ‘For DAL A hardware, …’ For AEH contributing to hardware DAL C functions, only a limited set of objectives applies. Even though there is a benefit in having a structured development process that ensures a proper flow-down of requirements to the hardware and the fulfilment by the hardware of the intended function, the use of this AMC is not required for AEH contributing to hardware DAL D functions. Appendix B provides some clarifications that may be used to ensure that the DAL D hardware performs its intended function. 3          DOCUMENT HISTORY This document is the initial issue of AMC 20-152. This initial issue, jointly developed with FAA, is intentionally set at Revision A. 4          BACKGROUND This AMC is related to the development of custom devices in AEH, including the use of commercial off-the-shelf intellectual property (COTS IP) within custom devices, the use of COTS devices, and the development of circuit board assemblies (CBAs). Each of these topics is organised with: background information dedicated to each major topic, —        applicability, and —        sections where objectives are described and uniquely identified. A unique identifier for each objective is defined with a prefix and an index number (i) as follows: —        for the development of custom devices, the identifier is ‘CD-i’; —        for the use of COTS IP in custom devices, the identifier is ‘IP-i’; —        for the use of COTS devices, the identifier is ‘COTS-i’; —        for the development of CBAs, the identifier is ‘CBA-i’. Objectives are also differentiated from the rest of the text by formatting in italics. The applicant should document in the Plan for Hardware Aspects of Certification (PHAC), or any other related planning document, the process and activities that the applicant intends to perform to satisfy the objectives of this AMC. The PHAC, as well as those related planning documents, should be submitted for certification. 5          CUSTOM DEVICE DEVELOPMENT This section provides guidance for the development assurance of programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs), which are collectively referred to as ‘custom devices’. These custom devices are addressed in ED-80/DO-254, Section 1.2, Item 3 as ‘custom micro-coded components’. Developing a custom device demands a well-defined development process. However, it is understood that the process to develop complex custom devices requires more comprehensive activities and artefacts than for a simple device. Section 5.1 identifies custom devices that are within the scope of this AMC. Section 5.2 provides guidance on simple/complex classification for custom devices. Section 5.3 provides guidance on development assurance for complex custom devices. Section 5.4 provides guidance on development assurance for simple custom devices. In particular, Section 5.4 defines which sections from 5.5 to 5.11 are applicable to the development assurance of simple electronic devices. Sections 5.5 to 5.10 provide clarifications on ED-80/DO-254. Section 5.11 provides background information and guidance specific to COTS IP used in custom devices. 5.1       Applicability to Custom Devices Section 5 is applicable to a digital- or mixed-signal custom device that contributes to hardware DAL A, B or C functions. Appendix A to ED-80/DO-254 modulates the ED-80/DO-254 life-cycle data based on the DAL allocated to the hardware function. This document recognises Appendix A for the modulation of the life-cycle data according to the hardware DAL for the development of custom devices. 5.2       Simple/Complex Classification ED-80/DO-254 introduces the notion of simple and complex hardware items. This section clarifies and provides criteria that could be used to classify a device as simple by considering the design content of the custom device, and subsequently, the ability to comprehensively verify the device. A hardware custom device is classified as simple only if a technical assessment of the design content supports the ability of the device to be verified by a comprehensive combination of deterministic tests and analyses that ensure correct functional performance under all foreseeable operating conditions with no anomalous behaviour. The following criteria should be used for assessing whether a device should be classified as simple: —        simplicity of the functions and their number, —        number and the simplicity of the interfaces, —        simplicity of the data/signal processing or transfer functions, and —        independence of functions/blocks/stages. Additional criteria specific to the digital part of the design include: —        whether the design is synchronous or asynchronous, —        number of independent clocks, —        number of state machines, number of states and state transitions per state machine, and —        independence between the state machines. The applicant may propose other or additional criteria for the technical assessment of simplicity. When an item cannot be classified as simple, it should be classified as complex. However, note that an item constructed entirely from simple items may itself be complex. **Objective CD-1** For each custom device, the applicant should document in the PHAC or any related planning document: 1.         the development assurance level, 2.         the simple or complex classification, and 3.         if a device is classified as simple, the justification based on the simple classification criteria. 5.3       Development Assurance for Complex Custom Devices ED-80/DO-254 is recognised as the industry standard for the development assurance of complex custom devices. The applicant should satisfy ED-80/DO-254 and the additional objectives or clarifications described in this AMC from Sections 5.5 to 5.11. 5.4       Development Assurance for Simple Custom Devices For the development of simple custom devices, it is understood that the life-cycle data might be significantly reduced compared with the data required for a complex custom device. ED-80/DO-254 acknowledges that the documentation for the design process of a simple hardware device is less extensive than the one needed for a complex device. In addition, while verification and configuration management are also needed, these supporting processes also require less documentation for a simple device. However, it is important that a simple custom device performs its intended function, and is under configuration management, thus allowing the device to be reproduced, conformed, and analysed to ensure continued operational safety. **Objective CD-2** The applicant should propose a process in the PHAC, or any other appropriate planning document, to develop simple custom devices which encompasses the following: 1.         definition of the device functions, 2.         complete verification of the device functions through tests and analyses, 3.         configuration management of the device, including problem reporting and the instructions to reproduce the device, 4.         assessment of the build conformance of the device. Sections 5.5.2.4 and 5.5.2.5 of this document also apply to the verification process for simple custom devices. The life-cycle data for simple devices can be combined with other hardware data. If tools are used for the simple custom device development process, the objectives or clarifications of those objectives described in Section 5.8 of this document are also applicable. When the applicant intends to reuse a previously developed simple device, ED-80/DO-254 Section 11.1 and the clarifications provided in Section 5.9 of this document should be used. If the applicant intends to use COTS IP, the objectives or clarifications of those objectives described in Section 5.11 of this document are also applicable. 5.5       Clarifications to ED-80/DO-254 Validation and Verification Processes 5.5.1   Validation Process Establishing a correct and complete set of requirements is the cornerstone of the development assurance process. ED-80/DO-254 Section 6.1 addresses the validation process to ensure the completeness and correctness of derived requirements. Nevertheless, the validation process is essential for all the requirements. Indeed, the upper-level requirements allocated to the custom device are often refined, decomposed or restated at the custom device level, and in terms that support the hardware design. These custom device requirements, which are traceable from/to the upper-level requirements and, therefore, not considered to be ‘derived’, should also be correct and complete. **Objective CD-3** The applicant should validate all the custom device requirements by following the ED-80/DO254 validation process (ED-80/DO-254 Section 6). This validation activity covers both derived and non-derived requirements. For DAL A and B development, validation activities should be performed with independence. Note: ED-80/DO-254 Appendix A defines acceptable means for establishing independence. 5.5.2   Verification Process ED-80/DO-254 broadly describes the verification process, but additional guidance is needed to ensure the verification of the custom device is complete, particularly in the area of: —        design reviews, —        reviews of test cases and procedures, and —        verification of the implementation. 5.5.2.1           Conceptual Design Review Conceptual design is the process of generating a high-level design description from the hardware requirements (see ED-80/DO-254 Section 5.2). The conceptual design review is typically used to ensure that the outcome of the conceptual design activities (see ED-80/DO254 Section 5.2.2) is consistent with the requirements, and identifies constraints for the interfacing components (hardware or software) and architectural constraints for the detailed design activities of the custom device. Since this conceptual design review is already addressed in ED-80/DO-254 Section 5.2.2 through the note, no separate objective is needed. 5.5.2.2           Detailed Design Review Detailed design is the process of generating, from the conceptual design and the requirements, a hardware description language (HDL) or analogue representation of the design, constraints for the implementation (e.g. timing constraints, pinout, I/O characteristics), and the hardware– software interface description. ED-80/DO-254 introduces design reviews in Section 6.3.3.2. A design review is considered to be an essential step during the detailed design process (ED-80/DO-254 Section 5.3) supporting the implementation process, and complementing requirements-based verification. **Objective CD-4** For hardware DAL A or DAL B, the applicant should review the detailed design with respect to the design standards, and review the traceability between the detailed design and the custom device requirements, in order to demonstrate that the detailed design covers the custom device requirements, is consistent with the conceptual design, and is compliant with the hardware design standards. For hardware DAL C, the applicant should demonstrate that the detailed design satisfies the hardware design standards. 5.5.2.3           Implementation Review Within a custom device development process, tools are used to convert the detailed design data into the physical implementation. While ED-80/DO-254 does not explicitly address it, a review of the design tool reports (e.g. synthesis and place and route reports) is necessary to ensure that the execution of the tool to generate its output was performed correctly. **Objective CD-5** When tools are used to convert the detailed design data into the physical implementation, the applicant should review the design tool reports (e.g. synthesis and place and route reports) to ensure that the tool executed properly when generating the output. 5.5.2.4           Review of Verification Cases and Procedures ED-80/DO-254 introduces verification coverage analysis in Section 6.2.2 Item 4 to satisfy the ED-80/DO-254 verification process objectives and determine whether the verification process is correct and complete. A part of the coverage analysis is clarified by the following objective. **Objective CD-6** Each verification case and procedure should be reviewed to confirm that it is appropriate for the requirements to which it traces and that the requirements are correctly and completely covered by the verification cases and procedures. 5.5.2.5           Verification of the Timing Performance of the Implementation ED-80/DO-254 Section 6.2 addresses the verification of the implementation. The implementation results from the process to generate the physical custom device from the detailed design data. The post-layout netlist is the closest virtual representation of the physical custom device, resulting from synthesis (for the digital part of the device) and place and route. While it is recommended to test the implementation in its intended operational environment (i.e. by a physical test), verification using the post-layout netlist may be necessary to complement the verification of the implementation for certain requirements (e.g. features not accessible from the I/O pins of the device, timing, abnormal conditions, or robustness cases). In such cases, the coverage of the requirements by means other than a physical test should be justified. The requirement to capture the activities in ED-80/DO-254 Section 5.1.2 Item 4.g introduces the need for the requirements to address signal timing characteristics under normal- and worst-case conditions. Nevertheless, ED-80/DO-254 does not explicitly address the necessity to verify the performance of the device under all possible (best-case and worst-case) timing conditions that could possibly occur during the operation of the device. The following objective clarifies the need to take into account the variation of the environmental conditions (temperature, voltage, etc.) during the evaluation of the timing performance of the design, as well as the semiconductor device process variations. **Objective CD-7** The applicant should verify the timing performance of the design accounting for the temperature and power supply variations applied to the device and the semiconductor device fabrication process variations as characterised by the manufacturer of the semiconductor device. Note: Static timing analysis (STA) with the necessary timing constraints and conditions is one of the possible means of compliance with this objective for the digital parts of custom devices. 5.6       Clarifications to ED-80/DO-254 ‘Robustness Aspects’ ED-80/DO-254 mentions robustness defects but does not explicitly address robustness. The robustness of the design is defined as the expected behaviour of the design under abnormal and boundary/worstcase operating conditions of the inputs and internal design states. These conditions are often captured as derived requirements when they are not allocated from the upper-level process. When subjected to these conditions, it is understood that the design may not continue to perform as it would under normal conditions. **Objective CD-8** For DAL A or DAL B hardware, the abnormal and boundary conditions and the associated expected behaviour of the design should be defined as requirements. 5.7       Recognition of HDL Code Coverage Method HDL code coverage analysis is an assessment of whether the HDL code of the design has been exercised through HDL simulations. The HDL code coverage method provides an assessment of the coverage of the design logic structure, giving an indication of which aspects of the logic structure are exercised and which are not. When performed during requirements-based verification (per ED-80/DO-254 Section 6.2), HDL code coverage is recognised as a method to perform ED-80/DO-254 elemental analysis per Appendix B Section 3.3.1 for digital devices. HDL code coverage supports the assessment of whether the HDL code elements are fully covered by requirements-based simulations. As such, it does not represent an assessment of the completeness of the requirements-based testing activities or the effectiveness of the requirement coverage. **Objective CD-9** For hardware DAL A or DAL B, where HDL code coverage is used to perform elemental analysis (ED-80/DO-254 Appendix B Section 3.3.1), the applicant should define in the planning documents the detailed coverage criteria of the HDL code elements used in the design. The criteria should ensure coverage over the various cases of the HDL code elements used in the design (e.g. branches, conditions, etc.). Any non-covered case or element should be analysed and justified. Note: Code coverage might need to be complemented by additional analysis for any hardware items that are identified as not covered by the code coverage analysis, in order to complete the elemental analysis of all elements. This situation may occur in the use of some COTS IP instantiations. 5.8       Clarifications to ED-80/DO-254 ‘Tool Assessment and Qualification’ ED-80/DO-254 introduces the notion of tool assessment and qualification. ED-80/DO-254 Figure 11-1 includes a flow chart indicating the tool assessment considerations and activities, and provides guidance for when tool qualification may be necessary. This AMC uses the flow chart and its related text as a basis for providing further clarification, as follows: ED-80/DO-254 — Figure 11-1 Item 1 — Identify the Tool Information capturing the environment required for tool operation and the tool revision should be included with the tool identification. ED-80/DO-254 — Figure 11-1 Item 2 — Identify the Process the Tool Supports When identifying the design or verification process that the tool supports, it is important to also identify what purpose or activity within the hardware development process the tool satisfies. While assessing the tool limitations, evidence of formal assessment of the tool problem reports is not required if the tool output has been completely and independently assessed. ED-80/DO-254 — Figure 11-1 Item 3 — Is the Tool Output Independently Assessed? The purpose of assessing the tool output is to completely cover, with an independent means, the potential errors that the tool could introduce into the design or fail to detect during verification. **Objective CD-10** When the applicant intends to independently assess a tool output, the applicant should propose an independent assessment that verifies the tool output is correct. The independent assessment should justify that there is sufficient coverage of the tool output. The completeness of the tool assessment should be based on the design/implementation and/or verification objectives that the tool is used to satisfy. ED-80/DO-254 — Figure 11-1 Item 4 — Is the Tool a Level A, B or C Design Tool or a Level A or B Verification Tool? ED-80/DO-254 Figure 11-1 Item 4 of the tool assessment/qualification flow excludes the need for activities for tools ‘used to assess the completion of verification testing, such as in an elemental analysis’. The last statement is misleading regarding the intent of code coverage tools used for elemental analysis. As stated in Section 5.7 of this document, ‘when a code coverage tool is used for elemental analysis, it does not represent an assessment of the completeness of the requirements-based testing activities or the effectiveness of the requirement coverage’. It is therefore necessary to provide some further clarifications. —        This document recognises the Figure 11-1 Item 4 exclusion of tool assessment/qualification activities for code coverage tools only when they are used to assess whether the code has been exercised by requirements-based testing/simulations (elemental analysis). —        If test cases or procedures are automatically generated by a tool and this tool uses coverage to determine the completion of the requirements verification, then the tool should be considered to be a verification tool to answer the question raised in Figure 11-1 Item 4. ED-80/DO-254 — Figure 11-1 Item 5 — Does the Tool have Relevant History? In ED-80/DO-254, the supporting text for Figure 11-1 Item 5 can be misinterpreted to suggest that when the tool has been previously used, no further tool assessment is necessary. Item 5 should be understood to mean that the applicant will provide sufficient data and justification to substantiate the relevance and credibility of the tool history. **Objective CD-11** When the applicant intends to claim credit for the relevant history of a tool, sufficient data should be provided as a part of the tool assessment to demonstrate that there is a relevant and credible tool history to justify that the tool will produce correct results for its proposed use. ED-80/DO-254 — Figure 11-1 Item 9 — Design Tool Qualification For design tools, contrary to the note in the supporting text for Figure 11-1 Item 9, the tool history should not be used as a stand-alone means of tool assessment and qualification. A relevant tool history may be used to compensate for some particular gaps in the tool assessment and qualification process, for example, to explain the method of independent assessment of the tool output. In this case, a relevant tool history is considered to be complementary data, providing more assurance for a tool. In addition to what is already referenced in ED-80/DO-254 Figure 11-1 Item 9 for tool qualification guidance, ED-12C/DO-178C and ED-215/DO-330 may also be used. 5.9       Clarifications to ED-80/DO-254 regarding Previously Developed Hardware (PDH) Previously developed hardware (PDH) is defined as custom-developed hardware that has been installed in an airborne system or equipment either approved through EASA type certification (TC/STC) or authorized through ETSOA. The section providing clarification on the use of PDH also covers PDH that was developed and approved prior to the use of ED-80/DO-254 in civil certification. This section provides guidance on the use of ED-80/DO-254 Section 11.1 for PDH. **Objective CD-12** When an applicant proposes to reuse PDH, the applicant should use ED-80/DO-254 Section 11.1 and its subordinate paragraphs. The applicant should perform the assessments and analyses required in ED-80/DO-254 Section 11.1 in order to ensure that using the PDH is valid and that the compliance shown during the previous approval was not compromised by any of the following: 1.         Modification of the PDH for the new application or for obsolescence management; 2.         Change to the function, change to its use, or change to a higher failure condition classification of the PDH in the new application; or 3.         Change to the design environment of the PDH. The results should be documented in the PHAC or any other appropriate planning document. In the context of custom device development, any one of these three points potentially invalidates the original development assurance credit for the PDH. In case of change or modification, the applicant should assess these changes using ED-80/DO-254 Section 11.1 and its subordinate paragraphs. When the original design assurance of the PDH is invalidated by one of the above points, the custom device should be upgraded based on the assessment per ED-80/DO-254 Section 11.1. When upgrading the hardware, the applicant should consider the objectives of this document that are applicable per the assessment. 5.10    Clarifications to ED-80/DO-254 Appendix A This section clarifies the life-cycle data referenced in ED-80/DO-254 Appendix A as follows. —        The row corresponding to 10.1.6 ‘Hardware Process Assurance Plan’ in Table A-1 should also indicate HC2 for Level C to be consistent with row 10.8. —        The row corresponding to 10.2.2 ‘Hardware Design Standard’ in Table A-1 should also indicate HC2 for Level C. HDL Coding Standards are part of the Hardware Design Standards. —        The row corresponding to 10.3.2.2 ‘Detailed Design Data’ in Table A-1 should indicate HC1 for Levels A, B and C. —        The row corresponding to 10.4.2 ‘Hardware Review and Analysis Procedures’ in Table A-1 should also indicate HC2 for Level C to be consistent with row 10.4.3. —        The Top-Level Drawing referenced in ED-80/DO-254 Appendix A corresponds to a Hardware Configuration Index (HCI) document. The HCI document completely identifies the hardware configuration, the embedded logic, and the development life-cycle data. To support consistent and accurate replication of the custom device (ED-80/DO-254 Section 7.1), the Top-Level Drawing includes the hardware life cycle environment or refers to a Hardware Environment Configuration Index (HECI) document. 5.11    Use of COTS IP in Custom Device Development This section addresses COTS IP that is instantiated within FPGAs/PLDs/ASICs during the development of the custom device. This section addresses COTS IP and its integration within custom devices and describes objectives to support the demonstration of compliance with the applicable airworthiness regulations for the hardware aspects of airborne systems and equipment certification. Section 5.11.2, on ‘Applicability to COTS IP’, identifies COTS IP that are within the scope of Section 5.11. 5.11.1 Background IP refers to design functions (design modules or functional blocks, including IP libraries) used to design and implement a part of or a complete custom device such as a PLD, FPGA, or ASIC. IP is considered to be commercial off-the-shelf intellectual property, i.e. ‘COTS IP’, when it is a commercially available function, used by a number of different users, in a variety of applications and installations. Custom IP, developed for a few specific aircraft equipment, is not considered to be COTS IP. COTS IP are available in various source formats. COTS IP are categorised as Soft IP, Firm IP, or Hard IP based on the stage in the custom device design flow where the IP is instantiated. A function can be a combination of source formats and each part needs to be addressed. Definitions for Soft IP, Firm IP, and Hard IP can be found in Appendix A ‘Glossary’. Figure 1 shows a ‘simplified’ design flow of a PLD, FPGA, or ASIC, and where Soft IP, Firm IP, and Hard IP are located in the design flow. ![Aviation.Bot AI suggestion, not from EASA source: The image presents a simplified block diagram illustrating the integration points of Soft IP, Firm IP, and Hard IP within the design flow of a PLD, FPGA, or ASIC device. Detailed Description: The diagram consists of three large, rightward-pointing, horizontally aligned chevron-shaped blocks, each representing a sequential stage in the device design flow. The blocks are arranged from left to right and are connected in series by a continuous horizontal black line that enters from the left, passes through all three blocks, and exits to the right. Each block contains centered black text indicating the design stage: 1. The leftmost chevron block is labeled [RTL Design]. 2. The middle chevron block is labeled [Synthesis]. 3. The rightmost chevron block is labeled [Place & Route]. Above each block, there is a white rectangular callout box with a black border and a small black pointer (tail) directed at the corresponding block. Each callout contains black text specifying the type of IP associated with that stage: - Above [RTL Design], the callout reads [Soft IP]. - Above [Synthesis], the callout reads [Firm IP]. - Above [Place & Route], the callout reads [Hard IP]. The spatial relationship is strictly linear and sequential: [RTL Design] is to the left of [Synthesis], which is to the left of [Place & Route]. The callouts are positioned directly above their respective blocks, with the pointer tails clearly indicating the association. No other visual elements, colors, or textures are present; the diagram uses grayscale shading for the chevrons and black for lines and text. There are no additional symbols, legends, or decorative elements. Contextual Linkage: The diagram visually links the three main stages of the custom device design flow (RTL Design, Synthesis, Place & Route) with the corresponding types of COTS IP (Soft IP, Firm IP, Hard IP) that can be instantiated at each stage. The continuous horizontal line represents the progression of the design process, while the callouts clarify at which stage each IP type is relevant. This directly supports the textual explanation of how Soft IP, Firm IP, and Hard IP are integrated at different points in the design flow. Mermaid Markdown Version: "mermaid flowchart LR A["RTL Design"] --> B["Synthesis"] --> C["Place & Route"] A -.-> D["Soft IP"] B -.-> E["Firm IP"] C -.-> F["Hard IP"] "](file_tNNDI2wQkpg/image071.png) *Figure 1 — Position of COTS IP within a ‘simplified’ design representation flow* The availability of a COTS IP does not guarantee that it is suitable to be used in a custom device for aircraft systems. Some COTS IP may have been developed using ED-80/DO-254, and will therefore have the necessary life-cycle data to demonstrate satisfaction of ED-80/DO-254. However, most COTS IP are not developed to meet aviation development assurance standards and, therefore, there are risks associated with their use in a custom device for aircraft systems or equipment. The risks of using COTS IP may include: —        Incomplete or missing documentation/data regarding: —        the behavioural operation of the COTS IP, —        how to integrate it into the design; —        Insufficient verification performed by the COTS IP provider; —        Deficient quality of the COTS IP. The potential for design errors may be increased by the lack of development assurance and/orby insufficient service experience. Possible design errors within COTS IP or in the use of COTS IP may lead to a failure mode. Riskfactors for these types of errors include: —        Unknown level of rigour of the COTS IP design and verification process; —        Misalignment between the intended usage of the COTS IP by the IP provider and the usage in the custom device by the IP user; —        Incomplete or missing details regarding the detailed operation of the COTS IP; —        Incorrect integration of the COTS IP with the rest of the custom device design; —        Integrator lacking expertise with the function of the IP. Additionally, the COTS IP user completes the development of the integrated COTS IP up to the physical implementation of the device. The COTS IP user may introduce a design error while completing the physical implementation of the COTS IP because of the user’s incomplete knowledge of the internal design of the COTS IP. 5.11.2 Applicability to COTS IP Section 5.11 is applicable to COTS IP used in a custom device that meets the definition of ‘commercial off-the-shelf intellectual property’ in the Glossary of Appendix A. This scope encompasses digital, analogue, and mixed-signal COTS IP. Note: Analogue COTS IP is within the above-mentioned scope, as it could be instantiated within a custom, mixed-signal device. Section 5.11 is applicable to COTS IP contributing to hardware DAL A, B or C functions. Section 5.11 is applicable to Soft IP, Firm IP, and Hard IP that are inserted within a custom device by the applicant. However, Section 5.11 does not apply to Hard IP that is embedded in the silicon of an FPGA or a PLD by the FPGA/PLD device manufacturer. This type of IP is considered to be part of the COTS device, and is covered in Section 6 ‘Use of Commercial Off-the-Shelf Devices. 5.11.3 Development Assurance for COTS IP A COTS IP development assurance approach should be based on the category of the COTS IP (Soft, Firm, Hard) and on the identified risks of failure due to a design error in the COTS IP itself or an error in the way it is used in the custom device. This section provides objectives addressing development assurance when using COTS IP. These objectives are intended to cover the particular aspects of development when using COTS IP, and are expressed in connection with the custom device development process that follows ED-80/DO-254 and the custom device objectives of this document. The development aspects related to COTS IP start from the custom device process that captures the allocated requirements for the function that will be performed by the COTS IP. From this entry point, the following aspects provide a basis to define the development assurance objectives for the use of COTS IP: —        Selection of the COTS IP, —        Assessment of the IP provider and the IP data, —        Planning activities, including the verification strategy, —        Definition of the requirements/derived requirements, —        Design integration, implementation, and verification of the COTS IP in the custom device. 5.11.3.1        Selection of the COTS IP to implement the function COTS IP can be available in different forms/source formats and various levels of quality. Some COTS IP may not be acceptable for use in airborne systems. The selection criteria below are intended to address the essential characteristics that are considered a minimum for the use of IP in custom AEH devices. **Objective IP-1** The applicant should select a COTS IP that is considered to be an acceptable solution, based on at least the following criteria: 1.         The IP is technically suitable for implementing the intended function; 2.         The description of the COTS IP architecture or IP design concept provides an understanding of the functionality, modes, and configuration of the IP. The description should also include an understanding of the source format or combination of source formats of the COTS IP; 3.         The availability and quality of data and documentation allow the understanding of all aspects of the COTS IP functions, modes, and behaviour, and enable the integration and verification of the COTS IP (e.g. datasheets, application notes, user guide, knowledge of errata, etc.); 4.         Information exists for the IP user to be able to create the physical implementation of the COTS IP (e.g. synthesis constraints, usage and performance limits, physical implementation, and routing instructions); 5.         It can be demonstrated that the COTS IP fulfils its intended function. 5.11.3.2        Assessment of the COTS IP Provider and COTS IP Data **Objective IP-2** The applicant should assess the COTS IP provider and the associated data of the COTS IP based on at least the following criteria: 1.         The IP provider provides all the information necessary for the integration of the COTS IP within the custom device and to support the implementation of the COTS IP within the device (e.g. synthesis constraints, usage domain, performance limits, physical implementation, and routing instructions); 2.         The configurations, selectable options, and scalable modules of the COTS IP design are documented so that the implementation of the COTS IP can be properly managed; 3.         The COTS IP has been verified by following a trustworthy and reliable process, and the verification covers the applicant’s specific use case for the COTS IP (including the used scale for scalable IP and the IP functions selected for selectable functions); 4.         The known errors and limitations are available to the IP user, and there is a process to provide updated information to the IP user; 5.         The COTS IP has service experience data that shows reliable operation for the applicant’s specific use case for the COTS IP. The assessment should be documented. The results of the assessment should be submitted together with the planning documents. 5.11.3.3        Planning of the Hardware Development Assurance Approach related to COTS IP 5.11.3.3.1     Complementary Development Assurance **Objective IP-3** When the IP-2 Objective criteria items 1, 2, 4 or 5 cannot be completely met using the IP provider’s data, the applicant should define an appropriate development assurance activity to mitigate the criteria that were not met and address the associated risk of development errors. The development assurance activity should be based on the ED-80/DO-254 objectives. Note: The results of the assessment of Objective IP-2 Item 3 are considered in Section 5.11.3.3.2. 5.11.3.3.2     The Verification Strategy for COTS IP Functions In addition to the verification of the custom device functions supported by the COTS IP, there is a need to ensure that the aspects related to the COTS IP and its usage are addressed. This section focuses on defining a verification strategy to cover those aspects. The verification performed by the COTS IP provider typically does not follow the ED-80/DO-254 verification process but may provide some credit to be used for the verification strategy. However, the verification process for COTS IP generally differs from one IP vendor to another, and the level of assurance varies depending on the IP provider’s development practices. The verification strategy may combine different means to complement the traditional requirements-based testing approach. Based on the applicant’s assessment of the IP provider and the IP data through Objective IP-2, the applicant is expected to establish a verification strategy. The aim of this verification strategy is to cover all three of the following aspects: —        The COTS IP: the purpose is to ensure that the COTS IP is verified, addressing the risk identified from the IP-2 Item 3 objective; —        Its implementation: the purpose is to ensure that the COTS IP still performs its allocated function, and that no design errors have been introduced by the design steps performed by the applicant (e.g. synthesis/place and route); —        Its integration within the custom device: the purpose is to ensure that the COTS IP has been properly connected, configured, and constrained within the custom device. The strategy may accomplish more than one aspect within a common verification step. This section identifies a general objective for the verification of COTS IP used in a custom device, enabling various verification approaches. **Objective IP-4** The applicant should describe in the hardware verification plan, PHAC, or any related planning document, a verification strategy that should encompass all three of the following aspects: 1.         The verification of the COTS IP itself, addressing the risk identified from the IP-2 Item 3 objective; 2.         The verification of the COTS IP after the design steps performed by the applicant (e.g. synthesis/place and route); 3.         The verification of the integrated COTS IP functions within the custom device. Note 1:  Reliable and trustworthy test data, test cases or procedures from the COTS IP provider may be used as part of the verification strategy to satisfy this objective. Note 2:  If the COTS IP implements functions based on an industry standard, proven standardised test vectors verifying compliance with the standard may be used in the verification strategy of the COTS IP. Note 3:  The verification strategy covers at a minimum the used functions of the COTS IP and ensures that the unused functions are correctly disabled or deactivated and do not interfere with the used functions. 5.11.3.3.3     COTS IP and Planning Aspects The applicant has to define the activities that are needed for the hardware development assurance approach related to COTS IP. **Objective IP-5** The applicant should describe in the PHAC, or any related planning document, a hardware development assurance approach for using the COTS IP that at least includes: 1.         identification of the selected COTS IP (version) and its source format(s) associated with the point(s) in the design flow where the COTS IP is integrated into the custom device; 2.         a summary of the COTS IP functions; 3.         the development assurance process that the applicant defines to satisfy the objectives of Section 5.11.3; 4.         the process related to the design integration and to the usage of the COTS IP in the development process of the custom device; 5.         tool assessment and qualification aspects when the applicant uses a tool to perform design and/or verification steps for the COTS IP. 5.11.3.4        Requirements for COTS IP Function and Validation Custom device requirements typically contain requirements that relate to the function supported by the COTS IP. The granularity of these requirements may be very different depending on the COTS IP function and the visibility of the functions supported by the IP at the custom device level. Depending on the extent of requirements-based testing as a part of the chosen verification strategy of the COTS IP, the level of detail and the granularity of the AEH custom device requirements may need to be refined to specifically address the COTS IP functions and the implementation of the COTS IP. In addition, requirements should be captured to encompass all the necessary design detail used to connect, configure, and constrain the COTS IP and properly integrate it into the AEH custom device. **Objective IP-6** The requirements related to the allocated COTS IP functions should be captured to an extent commensurate with the verification strategy. In addition, derived requirements should be captured to cover the following aspects associated with the integration of the COTS IP into the custom device design: 1.         COTS IP used functions (including parameters, configuration, selectable aspects); 2.         Deactivation or disabling of unused functions; 3.         Correct control and use of the COTS IP, in accordance with the data from the COTS IP provider. When the applicant chooses a verification strategy (see Section 5.11.3.3.2) that solely relies on requirements-based testing, the ‘extent commensurate with the verification strategy’ corresponds to a complete requirement capture of the COTS IP following ED-80/DO-254. Regarding the validation aspects, the COTS IP requirements should be validated as a part of the validation process of the AEH custom device. 5.11.3.5        Verification The applicant should ensure that the COTS IP is verified as a part of the overall custom device verification process per ED-80/DO-254 and based on the verification strategy for the COTS IP that has been described in the PHAC or a related planning document. For the requirements-based verification part, the applicant should satisfy ED-80/DO-254 Section 6.2 for the verification of the requirements related to the COTS IP (see Section 5.11.3.4 above). This can be performed as a part of the overall custom device process, therefore there is no separate objective. 5.11.3.6        DO-254 Appendix B considerations When developing a hardware DAL A or B custom device, ED-80/DO-254 Appendix B is applicable. Code coverage analysis that is recognised as part of elemental analysis (refer to Section 5.7 of this document) might not be possible for the COTS IP part of the design. However, ED-80/DO-254 Appendix B offers other acceptable methods, including safety-specific analysis. The following objective further clarifies the expectations when using safety-specific analysis. **Objective IP-7** For COTS IP used in DAL A or DAL B hardware, the applicant should satisfy ED-80/DO-254 Appendix B. The applicant may choose safety-specific analysis methods to satisfy Appendix B on the COTS IP function and its integration within the custom device functions. This safety-specific analysis should identify the safety-sensitive portions of the COTS IP and the potential for design errors in the COTS IP that could affect the hardware DAL A and DAL B functions in the custom device or system. For unmitigated aspects of the safety-sensitive portions of the IP, the safety-specific analysis should determine which additional requirements, design features, and verification activities are required for the safe operation of the COTS IP in the custom device. Any additional requirements, design features and/or verification activities that result from the analysis should be fed back to the appropriate process. 6.         USE OF COMMERCIAL OFF-THE-SHELF DEVICES Applicants are increasingly using COTS electronic devices in aircraft/engines/propellers/ airborne systems, which may have safety implications for the aircraft, engines/propellers, or systems. Section 6 addresses the use of COTS devices through objectives that support the demonstration of compliance with the applicable airworthiness regulations for hardware aspects of airborne systems and equipment certification when using complex COTS devices. Section 6.2 ‘Applicability to COTS devices’ enables applicants to identify the COTS devices that are within the scope of Section 6. Note: The term ‘COTS device’ used in this document applies to a semiconductor product that is fully encapsulated in a package. This term does not apply to circuit board assemblies (CBAs). 6.1       Background COTS devices continue to increase in complexity and are highly configurable. COTS devices provide ‘off-the-shelf’ already developed functions, some of which are highly complex. Their development and production processes undergo a semiconductor industry qualification based on their intended market (consumer, automotive, telecom, etc.). Their usage by the aerospace industry provides additional integration and higher performance capabilities than were possible in the past. The design data for these COTS devices is usually not available to the COTS user. Since these devices are generally not developed for airborne system purposes, assurance has not been demonstrated that the rigour of a COTS manufacturer’s development process is commensurate with the aviation safety risks. ED-80/DO-254 introduces a basis for the development assurance for the use of COTS devices in Section 11.2 ‘COTS components usage’. This section states that ‘the use of COTS components will be verified through the overall design process, including the supporting processes’. Since ED-80/DO-254 was released in the year 2000, the number of functions embedded and integrated in a single COTS device has significantly increased. Functions which were previously split into various components, making the interface between those components accessible for verification, are now embedded within a single chip. While there are clearly some benefits of integrating more functions within a device, the increased level of integration makes it difficult for the user to verify the different hardware functions in the device due to lack of access to the interfaces between functions. Since these devices are more complex and highly configurable than the older separate devices, the risk is greater that the COTS device will not achieve the intended function in particular use cases over the required operating conditions. Furthermore, some additional assurance is needed because design errors may still be discovered after the COTS device is released to the market, or when an applicant extends the use of the device beyond the manufacturer’s specifications. 6.2       Applicability to COTS Devices Section 6 is applicable to digital, hybrid, and mixed-signal COTS devices that contribute to hardware DAL A, B or C functions. For COTS devices contributing to hardware DAL C functions, a limited set of the objectives of this section will apply. Section 6 is also applicable to FPGA and PLD devices that embed Hard IP (see definition) in their produced/manufactured silicon, but only for the COTS part of the FPGAs/PLDs. Section 6.4 only applies to COTS devices that are complex, as determined by the following COTS complexity assessment. 6.3       COTS Complexity Assessment In order to define which COTS devices are complex, the following high-level criteria should be used, considering all functions of the device, including any functions intended to be unused: A COTS device is complex when the device: 1.         has multiple functional elements that can interact with each other; and 2.         offers a significant number of functional modes; and 3.         offers configurability of the functions, allowing different data/signal flows and different resource sharing within the device. Or when the device: 4.         contains advanced data processing, advanced switching, or multiple processing elements (e.g. multicore processors, graphics processing, networking, complex bus switching, interconnect fabrics with multiple masters, etc.). For complex COTS devices, it is impractical to completely verify all possible configurations of the device, and it is difficult to identify all potential failures. **Objective COTS-1** The applicant should assess the complexity of the COTS devices used in the design according to the high-level criteria of Section 6.3, and document the list of relevant devices (see Note 1), including the classification rationale, in the PHAC or any related hardware planning document. Note 1:  The applicant is not expected to assess the complete bill of material to satisfy the above objective, but only those devices that are relevant for the classification, including devices that are at the boundary between simple and complex. The resulting classification (simple or complex) for those devices that are at the boundary and those that are definitely complex should be documented. Note 2:  A classification rationale is required for those devices that are at the boundary (meeting a part of the high-level criteria) and are classified as simple. Some examples of classification are provided in the GM Appendix for illustration. 6.4       Development Assurance for Use of Complex COTS ED-80/DO-254 Section 11.2.1 identifies some electronic component management process (ECMP) items when using a COTS device. ED-80/DO-254 Section 11.2.2 and Section 6.1 of this document identify some concerns with using a COTS device. The following objectives acknowledge and supplement ED-80/DO-254 Section 11.2 in clarifying how to gain certification credit when using complex COTS devices. 6.4.1   Electronic Component Management Process (ECMP) As stated in ED-80/DO-254 Section 11.2, ‘the use of an electronic component management process, in conjunction with the design process, provides the basis for COTS components usage.’ **Objective COTS-2** The applicant should ensure that an electronic component management process (ECMP) exists to address the selection, qualification, and configuration management of COTS devices. The ECMP should also address the access to component data such as the user manual, the datasheet, errata, installation manual, and access to information on changes made by the component manufacturer. As part of the ECMP, for devices contributing to hardware DAL A or B functions, the process for selecting a complex COTS device should consider the maturity of the COTS device and, where risks are identified, they should be appropriately mitigated. Note: Recognised industry standards describing the principles of electronic component management may be used to support the development of the ECMP. See Appendix B. 6.4.1.1           Using a Device outside Ranges of Values Specified in its Datasheet The device reliability is established by the device manufacturer through the device qualification process (see definition of ‘qualification of a device’ in the glossary). ED-80/DO254 Section 11.2.1 Item 6 mentions that a device is selected based on the technical suitability of the device for the intended application. In some cases, the applicant may need to use the device outside the specified operating conditions guaranteed by the device manufacturer. ED-80/DO-254 Section 11.2.1 Item 4 and Item 6 should be addressed when the device is used outside its guaranteed specification. The following objective describes what to achieve when using a device outside the ranges of values specified in its datasheet. **Objective COTS-3** When the complex COTS device is used outside the limits of the device manufacturer’s specification (such as the recommended operating limits), the applicant should establish the reliability and the technical suitability of the device in the intended application. 6.4.1.2           Considerations when the COTS Device has Embedded Microcode COTS devices may need microcode to execute some hardware functions. When those functions are used by the applicant, there is a risk if the microcode has not been verified by the device manufacturer during the COTS device qualification, or if the microcode is proposed to be modified by the applicant. If the microcode is delivered by the device manufacturer, is controlled by the device manufacturer’s configuration management system, and is qualified together with the device by the device manufacturer, it is accepted that the microcode is part of the qualified COTS device. If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the microcode cannot be considered to be part of the qualified COTS device. **Objective COTS-4** If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the applicant should ensure that a means of compliance for this microcode integrated within the COTS device is proposed by the appropriate process, and is commensurate with the usage of the COTS device. Note: The PHAC (or any other related planning document) should document the existence of the microcode and refer to the process (hardware, software, system) where it is addressed. 6.4.2   COTS Device Malfunctions Some COTS devices may contain errors that may or may not have been detected by the devicemanufacturer. **Objective COTS-5** The applicant should assess the errata of the COTS device that are relevant to the use of the device in the intended application, and identify and verify the means of mitigation for those errata. If the mitigation means is not implemented in hardware, the mitigation means should be fed back to and verified by the appropriate process. Note: The above objective refers to any mitigation means (such as hardware, software, system, or other means). **Objective COTS-6** The applicant should identify the failure modes of the used functions of the device and the possible associated common modes, and feed both of these back to the system safety assessment process. 6.4.3   Usage of COTS Devices This section focuses on the usage of complex COTS devices, while Section 7 covers the overall circuit board assembly development process. This Section 6.4.3 refers to the term ’intended function of the hardware’, which is considered to be defined through the CBA development process. Complex COTS devices can have multiple functions and many configurations of those functions. The configuration of a device should be managed in order to provide the ability to consistently apply the required configuration settings, to replicate the configuration on another item, and to modify the configuration in a controlled manner, when modification is necessary. The configuration of the device addresses at least the following topics: —        Used functions (e.g. identification of each function, configuration characteristics, modes of operation), —        Unused functions and the means (internal/external) used to deactivate them, —        Means to control any inadvertent activation of the unused functions, or inadvertent deactivation of the used functions, —        Means to manage device resets, —        Power-on configuration, —        Clocking configuration (e.g. identification of the different clock domains), and —        Operating conditions (e.g. clock frequency, power supply level, temperature, etc.). **Objective COTS-7** The applicant should ensure that the usage of the COTS device has been defined and verified according to the intended function of the hardware. This also includes the hardware–software interface and the hardware to (other) hardware interface. When a COTS device is used in a hardware DAL A or B function, the applicant should show that unused functions of the COTS device do not compromise the integrity and availability of the COTS device’s used functions. Note 1:  For unused functions of the COTS device, it is recommended that an effective deactivation means is used and verified, when available. Note 2:  Verification should be performed at an appropriate level (hardware, software, equipment). ED-80/DO-254 Section 10.3.2.2.4 introduces hardware/software (HW/SW) interface data, which can be used as a reference to define the software interface data of the COTS device. Some additional consideration should be given to the critical configuration settings. Those are defined as the settings that are deemed necessary by the applicant for the proper usage of the hardware, which, if inadvertently altered, could change the behaviour of the COTS device, causing it to no longer fulfil the hardware intended function. **Objective COTS-8** If the complex COTS device contributes to DAL A or B functions, the applicant should develop and verify a means that ensures an appropriate mitigation is specified in the event of any inadvertent alteration of the ‘critical configuration settings’ of the COTS device. Note: The mitigation means might be defined at the hardware, software, or system level, or a combination of these. The mitigation means may also be defined by the safety assessment process. 7          Development Assurance of Circuit Board Assemblies (CBAs) This section provides guidance for the development assurance of CBAs (a board or a collection of boards). 7.1       Applicability Section 7 is applicable to CBAs that contribute to hardware DAL A, B or C functions. 7.2       Development Assurance of Circuit Board Assemblies (CBAs) While it is already a common practice for applicants to have an internal process to address the development of CBAs, it is necessary to clarify the expectations for development assurance, including the flow-down of the equipment/system requirements to the hardware. For consolidation of the development and/or the use of complex devices, it is essential to ensure consistency in the overall development assurance approach for the hardware domain. Moreover, definition of the CBA function is also necessary to enable the allocation of requirements and their flow-down to the complex devices. **Objective CBA-1** The applicant should have a process to address the development of CBAs that contain complex custom devices or complex COTS devices, in order to ensure that the CBA performs its intended function. The process should include requirements capture, validation, verification, and configuration management activities, and ensure an appropriate flow-down of requirements. See Appendix B for additional information. Note: The applicant’s process to address the development of the CBA may be defined together with the equipment process, when relevant. 8          RELATED REGULATORY, ADVISORY AND INDUSTRY MATERIAL (a)       Related EASA Certification Specifications (CSs) (1)       CS-23, Certification Specifications and Acceptable Means of Compliance for Normal, Utility, Aerobatic, and Commuter Category Aeroplanes (2)       CS-25, Certification Specifications and Acceptable Means of Compliance for Large Aeroplanes (3)       CS-27, Certification Specifications and Acceptable Means of Compliance for Small Rotorcraft (4)       CS-29, Certification Specifications and Acceptable Means of Compliance for Large Rotorcraft (5)       CS-E, Certification Specifications and Acceptable Means of Compliance for Engines,and [AMC 20-3B](#_DxCrossRefBm1926189219), Certification of Engines Equipped with Electronic Engine Control Systems (6)       CS-P, Certification Specifications for Propellers, and [AMC 20-1A](#_DxCrossRefBm1926189217), Certification of Aircraft Propulsion Systems Equipped with Electronic Control Systems (7)       CS-ETSO, Certification Specifications for European Technical Standard Orders (8)       CS-APU, Certification Specifications for Auxiliary Power Units; and [AMC 20-2B](#_DxCrossRefBm1926189218), Certification of Essential APU Equipped with Electronic Controls **(b)       FAA Advisory Circulars (ACs)** (1)       AC 20-152, *Development Assurance for Airborne Electronic Hardware* (2)       AC 00-72, *Best Practices for Airborne Electronic Hardware Design Assurance Using EUROCAE ED-80( ) and RTCA DO-254( )* (3)       AC 23.1309-1, *System Safety Analysis and Assessment for Part 23 Airplanes* (4)       AC 25.1309-1, *System Design and Analysis* (5)       AC 27-1309, *Equipment, Systems, and Installations (included in AC 27-1, Certification of Normal Category Rotorcraft)* (6)       AC 29-1309, *Equipment, Systems, and Installations (included in AC 29-2, Certification of Transport Category Rotorcraft)* (c)       Industry Documents (1)       EUROCAE ED-79A, *Guidelines for Development of Civil Aircraft and Systems*, dated December 2010 (2)       EUROCAE ED-80, *Design Assurance Guidance for Airborne Electronic Hardware*, dated April 2000 (3)       RTCA DO-254, *Design Assurance Guidance for Airborne Electronic Hardware*, dated 19 April 2000 (4)       SAE International Aerospace Recommended Practice (ARP) 4754A, *Guidelines for Development of Civil Aircraft and Systems*, dated 21 December 2010 (5)       SAE International Aerospace Recommended Practice (ARP) 4761, *Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment*, dated December 1996 9          AVAILABILITY OF DOCUMENTS (a)       EASA Certification Specifications (CSs) and Acceptable Means of Compliance (AMC) may be downloaded from the EASA website: [www.easa.europa.eu](http://www.easa.europa.eu) (b)       FAA Advisory Circulars (ACs) may be downloaded from the FAA website: [www.faa.gov](http://www.faa.gov) (c)       EUROCAE documents may be purchased from:             European Organisation for Civil Aviation Equipment 102 rue Etienne Dolet, 92240 Malakoff, France Telephone: +33 1 40 92 79 30, Fax: +33 1 46 55 62 65 (Email: eurocae@eurocae.net, website: [www.eurocae.net](http://www.eurocae.net)) (d)       RTCA documents may be purchased from: RTCA, Inc. 1150 18th Street NW, Suite 910, Washington DC 20036, USA (Email: info@rtca.org, website: [www.rtca.org](http://www.rtca.org)) [Amdt 20/19]