13.1 The term Airborne Electronic Hardware (AEH) includes Line Replaceable Units (LRUs), Circuit Board Assemblies (CBAs), Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLDs) and Field Programmable Gate Arrays (FPGA). AEH is designed for installation within a part or appliance of an aeronautical product. AEH is classified as either complex or simple. Further, complex AEH use in safety critical aircraft functions is increasing, bringing with it new safety and certification challenges.
13.2 The implementation of a robust and effective AEH design supports aviation safety. Development assurance of AEH is required to comply with most airworthiness codes. To assist in this endeavour, acceptable means of compliance is published by both Civil Aviation Authorities (CAA) and Military Aviation Authorities (MAA). AEH development assurance is typically a part of airworthiness requirements associated with Function and installation (2x.1301), and Equipment, systems, and installations (2x.1309). The purpose of this chapter is to define airworthiness design requirements and specific guidance for robust application of certification for AEH. It also identifies common approaches to the management of AEH that meet DASAs prescribed design requirements.
13.3 DASA has evaluated recognised CAA and MAA approaches to AEH, and their associated AEH standards, and concluded that careful application and in some cases expansion is required to effectively implement AEH into Defence aircraft systems. To promote the careful application of AEH standards, this chapter first defines the requirements that should be satisfied for robust AEH design. The chapter then identifies where recognised CAA/MAA approaches to AEH require particular attention, to meet DASAs prescribed requirements. This approach, which should be applied using the system safety principles in Section 2 Chapter 2, provides design organisations with guidance to embed robust AEH practices into their engineering procedures.
13.4 This chapter presents the DASA prescribed airworthiness design requirements for AEH development assurance as applicable to aircraft acquisitions, and changes to type design.
13.5 The application of AEH design requirements to Defence aircraft achieves three key outcomes:
AEH safety objectives are:
defined, and
agreed by DASA.
AEH design hazards are identified and controlled as part of the defence aircraft system safety processes.
AEH assurance rigor is defined, agreed by the DASA, and documented to meet defence aircraft systems certification.
13.6 The design of AEH that performs safety critical functions requires the application of five key engineering principles:
Complexity Considerations, is the determination of whether the AEH being implemented into within aircraft design is simple or complex.
AEH safety, is integrated with system safety, where AEH hazards are identified, analysed and treated within the context of systems engineering principles.
AEH assurance, defines the engineering rigour applied commensurate to the criticality of the functions performed by the AEH.
Alternative Methods or Processes, defines the requirements to be met to provide hardware development assurance for alternative methods and procedures to demonstrate compliance
Development of custom devices, including the use of Commercial Off The Shelf (COTS) Intellectual Property (IP) AEH within the device.
13.7 DASA prescribed AEH design requirements that support the achievement of these outcomes are defined in the following paragraphs.
13.8 There are two classifications of the term ‘complexity’ in relation to AEH, simple electronic hardware (SEH) and complex electronic hardware (CEH). Defining differences in complexity herein is based on the feasibility and level of difficulty to accomplish acceptable verification coverage by deterministic means.
13.9 ED-80/DO-254 Design Assurance Guidance for AEH defines electronic hardware to be simple only if ‘a comprehensive combination of deterministic tests and analyses appropriate to the development assurance level can ensure correct functional performance under all foreseeable operating conditions with no anomalous behaviour’. CEH is all hardware, which cannot be classified as simple. Additionally, hardware can be considered complex even if the AEH is completely constructed from simple components. AEH complexity should be considered at the circuit board or LRU level, not at the individual component level.
13.10 Design Requirement (Essential). Complexity of AEH must be assessed as simple or complex to determine the required development assurance rigour.
13.11 This complexity assessment is best done prior to development of the certification program plan (CPP).
13.12 For COTS AEH, compliance with this requirement can be demonstrated through adopting the assessment defined in Section 6.3 of FAA AC 20-152A Development Assurance for Airborne Electronic Hardware dated 7 Oct 22 / AMC-20-152A of EASA General Acceptable Means of Compliance for Airworthiness of Products, Parts and Appliances (AMC-20) dated 17 Dec 20. These documents provide an assessment centred around the high-level criteria listed below which determines whether a COTS device used as AEH is complex or not. A COTS device is complex when the device:
Has multiple functional elements that can interact with each other; and
Offers a significant number of functional modes; and
Offers configurability of the functions, allowing different data/signal flows and different resource sharing within the device.
Or when the device contains advanced data processing, advanced switching, or multiple processing elements (e.g. multicore processors, graphic processing, networking, complex bus switching, interconnect fabrics with multiple masters, etc.)
13.13 SEH still requires processes of verification and configuration management, however, it does not demand extensive development assurance required for CEH, since SEH can be exhaustively tested. The proceeding design requirements and guidance are not required for SEH. For CEH, documentation of the design process is required, and the proposed means of providing development assurance must be agreed to by the DASA as part of the certification program.
13.14 An AEH specification error, design flaw, or the lack of initial safety requirements can contribute to or cause a system failure or erroneous operator behaviour. AEH safety is a part of system safety and is used to address AEH’s contribution to aircraft hazards and cannot be undertaken independently of the total effort.
13.15 Design Requirement (Essential). AEH safety must be considered as part of the system safety program to identify any derived requirements and determine the worst credible failure condition for AEH.
13.16 The Defence aviation approach to system safety and associated DASA prescribed requirements are detailed in Section 2 Chapter 2 and involves the identification of system level hazards. Considering AEH as part of system safety allows for the identification of AEHs contribution to those hazards, the development of derived requirements to mitigate the hazards and identifies the commensurate assurance level to adequately mitigate the hazards.
13.17 Similar to software, CEH can be used to implement system level functions, therefore, poses hazards if those functions were to fail or be performed incorrectly. While software and CEH are similar in function, it is important to note that CEH safety is distinct from software safety and requires unique considerations to allow for proper identification and tracing of requirements that are derived from design decisions.
13.18 A Development Assurance Level (DAL), commensurate with the worst credible failure condition identified, is utilised to establish the required AEH assurance safety objectives. The assignment of DALs is IAW DO-254 Table 2-1, which is obtained through proper allocation of ARP 4754A Guidelines for Development of Civil Aircraft and Systems. DASA is to be consulted on the use of other system or software safety standards, related to AEH, as they may require tailoring to satisfy the objectives. As per FAA AC 20-152A / EASA AMC-20-152A, DO-254 is not required to be applied to DAL D AEH, provided that, system-level development assurance practices such as ED-79A/ARP4754A or other means are satisfied.
13.19 AEH assurance is closely coupled to AEH safety. The assigned DAL for a given system is determined through application of system safety and AEH safety. The assigned DAL determines the objectives required to be met to establish the appropriate rigor and level of confidence required to limit the likelihood of development errors could impact aircraft safety.
13.20 Design Requirement (Essential). AEH must satisfy the prescribed objectives required for the Development Assurance Level commensurate with its worst credible failure condition.
13.21 AEH assurance is an activity that includes a range of certification objectives (or certification activities) to be satisfied in all phases of the development. The applicability of these certification objectives is dependent on the DAL of the AEH, with higher assurance levels requiring an increased scope of certification objectives, thus providing a greater level of confidence in the AEH. The scope of certification objectives can cover the planning, requirements, development and verification phases of the program, as well as configuration management, quality assurance and certification liaison activities.
13.22 AEH assurance is achieved through proper application of RTCA DO-254 Design Assurance Guidance for Airborne Electronic Hardware.
13.23 While DO-254 / ED-80 Design Assurance Guidance for Airborne Electronic Hardware is the DASA endorsed process to apply development assurance for AEH, alternative methods and processes can still be utilised in the provision for AEH development assurance. If an alternative method or process is being considered for certification of AEH, the method or process should be assessed based on its ability to satisfy the applicable regulations and meet the safety intent. Alternative methods or processes are required to be approved by the DASA prior to implementation as part of the certification program plan. Some considerations for evaluation of alternative methods or processes may include:
Alternative methods or processes should show an equivalent level of development assurance to the DASA prescribed acceptable means of compliance for AEH.
Assessment of the alternative methods or processes on satisfying the AEH development assurance objectives required for certification.
Assessment of the effect of the proposed alternative methods or processes on the life cycle data.
Justification and rationale for use of the proposed alternative methods or processes should be substantiated by evidence that the methods or processes will produce the expected results.
13.24 AEH such as CBAs, PLDs, FPGAs, or ASICs can be used within custom devices in aircraft systems. If custom devices are utilised in aircraft systems, the appropriate development assurance to demonstrate compliance is addressed in ED-80/DO-254, where custom devices are referenced as custom micro-coded components at Section 1.2, Item 3. Further, clarifications and best practice on the development assurance for custom devices is provided by FAA AC 20-152A / EASA AMC 20-152A.
13.25 COTS IP can be used within custom devices. IP is considered as COTS IP when it is a commercially available function used by a number of different users in a variety of application and installations. However, the availability of a COTS IP does not guarantee it reaches a certification standard such as ED-80/DO-254, therefore, resulting in associated risks with the use of the custom device for aircraft systems. The risks of using COTS IP include incomplete or missing documentation and data, insufficient verification, and deficient quality assurance of the COTS IP leading to a greater risk of design errors, which would need to be managed utilising AEH assurance as discussed above.
13.26 Development of custom devices using COTS IP should follow the approach as detailed in FAA AC 20-152A Development Assurance for Airborne Electronic Hardware.
13.27 Section 1 Chapter 3 describes the DASA approach to recognition of Airworthiness Codes, which represent prescribed airworthiness requirements from a recognised civil or military Airworthiness Authority. This section describes common CAA and MAA application of AEH safety and assurance.
13.28 RTCA DO-254 Design Assurance Guidance for Airborne Electronic Hardware, alternatively known as EUROCAE ED-80, is recognised by CAAs, including the FAA, and EASA, as acceptable means of compliance for AEH development assurance. This standard satisfies the associated NAA’s Airworthiness Requirements (generally Federal Aviation Regulation (FAR) or Certification Specification (CS) 2x.1301 and 2x.1309).
13.29 RTCA DO-254 is not intended to be implemented in isolation, and acceptability is based on integration with other requirements of the relevant Airworthiness Code. Consequently, civil authorities will undertake AEH safety as part of system safety, along with AEH assurance within conjunction with an ecosystem of design requirements, standards and associated guidance material including:
FAA AC 20-152A Development Assurance for Airborne Electronic Hardware
EASA AMC 20-152A Development Assurance for Airborne Electronic Hardware (AEH)
13.30 MIL-HDBK-516 Airworthiness Certification Criteria defines the US DoD AEH requirements, which is termed ‘Processing Hardware/Electronics’, within Section 15.3 and references various specifications, standards and handbooks as means of compliance, including DO-254 Design Assurance Guidance for Airborne Electronic Hardware. Referencing to various specifications, standards and handbooks provides the designer the freedom to utilise military standards as well as the above civilian standards. This approach is similar to aviation software in that it facilitates civilian-military interfaces such as the application of MIL-STD-882E for system safety and DO-254 for AEH assurance.
13.31 The UK MoD term for AEH is ‘Programmable Elements’ as defined within DEF STAN 00-970 Part 13 Issue 13. The AEH approach to ensuring safety and assurance for ‘Safety Related Programmable Elements’ is further detailed within DEF STAN 00-55 Issue 4, Requirements for the Safety Programmable Elements in Defence Systems, which is the source for AEH related airworthiness requirements. DEF STAN 00-55 Issue 4 defines programmable elements as “Products, Services and Systems (PSS) that is implemented in software or programmable hardware, which includes any device that can be customised, eg. ASICs, PLDs and FPGAs”. While DEF STAN 00-970 adopts the civilian standards of DO-254 as a means of compliance for AEH assurance, it also allows legacy platforms to retain compliance against DEF STAN 00-55 Issue 4. However, the underlying UK MoD system safety requirements do not fully align with Defence requirements and as a result require considerable tailoring prior to application, as detailed in Section 2 Chapter 2.
13.32 The application of the preceding military approaches requires tailoring and prior agreement with the DASA. AEH standards such as JSSSEH and DEF STAN 00-55 are largely guidance material and, without intelligent application, may result in incomplete objective evidence that can be used to demonstrate that appropriate AEH safety management and assurance has been achieved.
13.33 Further guidance on implementing the AEH requirements prescribed in this chapter and addressing AEH development assurance is available from the chapter sponsor.