7.1 Applicability Section 7 is applicable to CBA that contribute to hardware DAL A, B, or C functions.
7.2 Development Assurance of Circuit Board Assemblies While it is already a common practice for applicants to have an internal process to address the development of CBA, 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 circuit board assemblies 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 AC 00-72 for additional information.
Note: The applicant’s process to address the development of the circuit board assembly may be defined together with the equipment process, when relevant.
8 RELATED REGULATORY, ADVISORY, AND INDUSTRY MATERIAL
8.1 Title 14 of the Code of Federal Regulations (14 CFR) Applicable Sections This AC provides guidance on development of an acceptable means of compliance to the following regulations, with respect to AEH development assurance: 14 CFR parts 21, 23, 25, 27, 29, 33 and 35 (principally, §§ 21 subpart O, 23.2500, 23.2505, 23.2510, 25/27/29.1301, 25/27/29.1309, 33.28, and 35.23).
8.2 FAA Advisory Circulars
• AC 00-72, Best Practices for Airborne Electronic Hardware Design Assurance Using EUROCAE ED-80( ) and RTCA DO-254().
• AC 20-174, Development of Civil Aircraft and Systems.
• AC 21-50, Installation of TSOA Articles and LODA Appliances.
• AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes.
• AC 23.2010-1, FAA Accepted Means of Compliance Process for 14 CFR Part 23.
• AC 25.1309-1, System Design and Analysis.
• AC 27-1, Certification of Normal Category Rotorcraft (Changes 1 – 8 incorporated).
• AC 29-2, Certification of Transport Category Rotorcraft (Changes 1 – 8 incorporated).
• AC 33.28-1, Compliance Criteria for 14 CFR § 33.28, Aircraft Engines, Electrical and Electronic Engine Control Systems.
AC 33.28-2, Guidance Material for 14 CFR 33.28, Reciprocating Engines, Electrical and Electronic Engine Control Systems.
• AC 33.28-3, Guidance Material for 14 CFR § 33.28, Engine Control Systems.
• AC 35.23-1, Guidance Material for 14 CFR 35.23, Propeller Control Systems.
8.3 EASA Acceptable Means of Compliance (AMC) AMC 20-152(), Development Assurance for Airborne Electronic Hardware.
8.4 Industry Documents
• SAE International Aerospace Recommended Practice (ARP) 4754A, Guidelines for Development of Civil Aircraft and Systems, dated December 21, 2010.
• SAE International Aerospace Recommended Practice (ARP) 4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, dated December 1, 1996.
• EUROCAE ED-79A, Guidelines for Development of Civil Aircraft and Systems, dated December 1, 2010.
• RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, dated April 19, 2000.
• EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, dated April 2000.
9 WHERE TO FIND THIS AC.
You may find this AC at http://www.faa.gov/regulations_policies/advisory_circulars/ If you have suggestions for improving this AC, you may use the Advisory Circular Feedback form at the end of this AC.
Digitally signed by
VICTOR W WICKLUND Date: 2022.10.07 14:15:51 -07'00' Victor Wicklund Acting Director, Policy and Innovation Division Aircraft Certification Service 27
APPENDIX A. GLOSSARY Abnormal conditions – Conditions that are inconsistent with specified normal operating conditions.
Airborne electronic hardware – An electronic “hardware item” (see ED-80/DO-254 for definition of “hardware item”) intended to be installed in airborne equipment/systems.
Batch – A manufacturing lot of a semiconductor device that is reproduced using the same semiconductor fabrication process.
Commercial off-the-shelf (COTS) device – A device, integrated circuit or multi-chip module developed by a supplier for a wide range of customers (not restricted to airborne systems), whose design and configuration is controlled by the supplier or an industry specification. A COTS device can encompass digital, analog, or mixed-signal technology. COTS electronic components are generally developed by the semiconductor industry for the commercial market, not particular to the airborne domain. These devices have widespread commercial use and are developed according to the semiconductor manufacturer’s proprietary development processes.
COTS device usage – Definition of the used and unused functions that are implemented in the device. This is further defined as an exhaustive list of conditions/constraints (such as configuration settings, usage rules, protocol, timing constraints, input output (IO) interface, and addressing schemes) associated with the performance characteristics of the used COTS functions. Respecting the defined usage of the COTS will ensure the expected performance of the device for a given set of constraints.
Commercial-off-the-shelf intellectual property (COTS IP) – Intellectual property (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 an ASIC.
Intellectual property is considered to be “COTS IP” when it is a commercially available function, used by a number of different users in a variety of applications and installations. In this document, the terminology “a/the COTS IP” refers to a piece of hardware that is COTS IP per this definition. COTS IP is available in various source formats:
a. Soft IP Soft IP is COTS IP defined as register transfer level (RTL) code, captured in an HDL such as Verilog or VHDL, that may be readable or encrypted. It is instantiated by the IP user within the custom device HDL code or by selecting the COTS IP function in a library. Soft IP will be synthesized, placed and routed in the AEH custom device.
In this document, the terminology “a/the Soft IP” refers to a piece of hardware that is Soft IP per this definition.
b. Firm IP Firm IP is COTS IP defined as a technology-dependent netlist. It is instantiated within the
custom device netlist (inserted by the user, called from a library, or selected by the user as a library function). Firm IP will be placed and routed in the AEH custom device In this document, the terminology “a/the Firm IP” refers to a piece of hardware that is Firm IP per this definition.
c. Hard IP Hard IP is COTS IP defined as a physical layout (stream, polygon, GDSII format, etc.).
Hard IP is instantiated by the IP user during the physical design layout stage;
alternatively, Hard IP is embedded into the silicon of the FPGA/PLD by the FPGA provider/device manufacturer.
In this document, the terminology “a/the Hard IP” refers to a piece of hardware that is Hard IP per this definition.
Complex COTS device maturity – A complex device is mature when the risk of an unintended function or misbehavior is low. The risk of anomalous behavior decreases as a device is widely used and device errata are documented and communicated to the users of the device.
Critical configuration settings – Those configuration settings that the applicant has determined to be necessary for the proper usage of the hardware, which, if inadvertently altered, could change the behavior of the COTS device, causing it to no longer fulfil its intended function.
Development assurance for use of COTS device – All the planned and systematic activities conducted to provide adequate confidence and evidence that the complex COTS device safely performs its intended function under its operating conditions.
Hardware design assurance level of a function – Refer to ED-80/DO-254, Table 2-1 for the definition of DAL A, B, C, and D functions.
Hybrid device – An integrated circuit combining different semiconductor dies and passive components on a substrate.
IP libraries – “IP libraries” used in the COTS IP definition refers to all sub-modules, subblocks, or other design sub-functions that are formally/commercially made available by a COTS IP provider and intended for integration within a COTS IP by the COTS IP user. However, Macro Cells for FPGAs or Standard Cells for ASICs are not considered to be IP libraries, hence they are not related to the COTS IP topic referred to in this document.
Microcode – This term often refers to a hardware-level set of instructions. It is typically stored in the COTS device’s high-speed memory, and microcode instructions are generally translated into sequences of detailed circuit-level operations. Microcode may be used in general-purpose microprocessors, microcontrollers, digital signal processors, channel controllers, disk controllers, network interface controllers, network processors, graphics processing units, and other hardware.
A Basic Input/Output System (BIOS) is an example of microcode, which is used to initialize microprocessor input and output process operations.
Mixed-signal device – A device that combines digital and analog technologies.
Note – A note in this document is supporting information used to provide explanatory material, emphasize a point, or draw attention to related items which are not entirely within context.
Objective – An objective in this document is a requirement for development assurance that should be met to demonstrate compliance with the applicable airworthiness requirements.
Previously developed hardware (PDH) – 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 FAA TSOA.
Qualification of a device – SAE EIA-STD-4899 defines component qualification as “The process used to demonstrate that the component is capable of meeting its application specification for all the required conditions and environments.” Component qualification results in a “qualified device.” Note that the use of “qualification” is not intended to refer to ED-14/DO-160 environmental qualification testing.
OMB Control Number: 2120-0746 APPENDIX B.
11 0 4 Advisory Circular Feedback Form Expiration Date: /3 /202
Paperwork Reduction Act Burden Statement: A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a currently valid OMB Control Number. The OMB Control Number for this information collection is 2120-0746. Public reporting for this collection of information is estimated to be approximately 20 minutes per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, completing and reviewing the collection of information.
All responses to this collection of information are voluntary FAA Order 1320.46D Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to:
Information Collection Clearance Officer, Barbara Hall, 800 Independence Ave, Washington, D.C. 20590.
If you find an error in this AC, have recommendations for improving it, or have suggestions for new items/subjects to be added, you may let us know by (1) emailing this form to ( ) or
(2) faxing it to the attention of the LOB/SO ( ).
S bject: : u Date
Please mark all appropriate line items:
□ An error (procedural or typographical) has been noted in paragraph on page .
□ Recommend paragraph on page be changed as follows:
□ In a future change to this AC, please cover the following subject:
(Briefly describe what you want added.)
□ Other comments:
□ I would like to discuss the above. Please contact me.
Submitted by: Date:
B-1 FAA Form 1320-73 (09/22) SUPERSEDES PREVIOUS EDITIONS