AC 20-152A

U.S.

D epartment of Tra nsportation Federal Aviation Admi nistration Advisory Circular ct: Subje Development Assurance for Electronic Hardware Airborne Date: 10/7/22 Initiated By: AIR-622 AC No: 20 -152A 1 PURPOSE This advisory circular (AC) 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 for type certification or Technical Standard Order (TSO) authorization. The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or agency policies. However, if you use the means described in the AC, you should follow it in all applicable respects unless alternate means or deviations are proposed and accepted by the FAA.

This AC recognizes 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 April 19, 2000.

This AC 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 (CBA).

The additional guidance and clarification are provided in the form of objectives. The applicant is expected to describe the process and activities to satisfy the objectives of this AC.

Note: EUROCAE ED-80 is hereafter referred to as “ED”; RTCA DO-254 is hereafter referred to as “DO.” Where the notation “ED-80/DO-254” appears in this document, the referenced documents are recognized as being equivalent.

This AC does not address the Single Event Effects (SEE) aspects or the assessment of the hardware susceptibility to SEE. However, the Plan for Hardware Aspects of Certification may still be used to document the certification considerations for Single Event Effects.

2 2 APPLICABILITY This AC 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 certificated aircraft, engines, and propellers. This AC also applies to developers of TSO articles.

This AC 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 airborne electronic hardware 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, use of this AC is not required for AEH contributing to hardware DAL D functions. AC 00-72, Best Practices for Airborne Electronic Hardware Design Assurance Using EUROCAE ED-80( ) and RTCA DO-254( ), provides some clarifications that may be used to ensure that the DAL D hardware performs its intended function.

3 CANCELLATION This AC cancels AC 20-152, RTCA, INC., Document RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware, dated June 30, 2005.

4 BACKGROUND This AC 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 (CBA). Each of these topics is organized 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 circuit board assemblies, the identifier is “CBA-i.”

Objectives are also differentiated from the rest of the text by formatting in italics.

3 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 AC. 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 artifacts than for a simple device.

• Section 5.1 identifies custom devices that are within the scope of this AC.

• 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 through 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 recognizes 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

4 combination of deterministic tests and analyses that ensures correct functional performance under all foreseeable operating conditions with no anomalous behavior.

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 D evelopment Assurance for Complex Custom Devices ED-80/DO-254 is recognized 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 AC from Sections 5.5 through 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 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 analyzed 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 that encompasses:

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.

6 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/DO-254 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/DO-254, 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 analog 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.

7 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 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

8 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 activities in ED-80/DO-254, Section 5.1.2, Item 4.g, introduces the need for requirements to address signal timing characteristics under normal and worst-case conditions. Nevertheless, ED- 80/DO-254 does not explicitly address verification of 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 characterized 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 behavior of the design under abnormal and boundary/worst-case 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.

9 When performed during requirements-based verification (per ED-80/DO-254, Section 6.2), HDL code coverage is recognized 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 requirements-based testing activities or the effectiveness of 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 noncovered case or element should be analyzed 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 AC 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.

10 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 recognizes 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

11 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 Previously developed hardware (PDH) is defined as a custom-developed hardware device that has been installed in an airborne system or equipment either approved through FAA type certification (TC/STC) or authorized through TSOA. 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 Section 5.11 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 categorized 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 the 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.