By Esteban Sánchez, Project Manager, Avionyx.

September 2009

Electronic aviation equipment, composed of both hardware and software, plays a critical role to fulfill the objective of a safe flight. The DO-254 standard, Design Assurance Guidance for Airborne Electronic Hardware, was created in April, 2000 and formally accepted by the FAA in 2005 as a means of compliance for the design of complex electronic hardware in airborne systems. The standard was conceived as the complement to the well-recognized homologous guidance for software, DO-178B. The main objective of DO-254 is to provide design assurance guidance to assist organizations in the development of electronic hardware. The intention of this paper is to provide a quick overview of the DO-254 standard for companies, engineers and managers.

Criticality and Complexity in DO-254

The DO-254 standard defines five system development assurance levels, A through E, that varies depending on the criticality of the system (the effect that a system failure represents for the safety of the aircraft). Level A is the most stringent and it applies to systems whose failures would not allow continued safe flight. , Conversely, level E is applicable to all those systems whose failures do not affect the operational capability of the aircraft or increase the workload of the flight crew. The design assurance level determination is performed by the System Development Process (during this process the system is conceived as a whole from the highest level of the design hierarchy as it is intended to fit in the aircraft) and flowed down to the Hardware Development Process, where it is used to drive the level of design assurance required to satisfy certification objectives. The more design assurance level needed, the more complex and expensive the project will become. In its Appendix A, the DO-254 standard includes a comprehensive list of data to be produced for each level of design assurance. This appendix is particularly useful to avoid increasing the scope of the project and produce documents that are not required for the certification of the electronic hardware. 

DO-254 is applicable at the device, board or LRU level, although the compliance is only required at the device level by the FAA. DO-254 distinguishes between complex and simple electronic devices; however, it recognizes that such a differentiation is not rigorously defined anywhere. Basically, the standard defines a Simple Electronic Device as:

“One that can be demonstrated, through a comprehensive combination of deterministic tests and analyses appropriate to the design assurance level, to have a correct functional performance under all foreseeable operation conditions with no anomalous behavior”.
In terms of verification, this implies that in order to classify an electronic device as simple, exhaustive testing may be required. Based on this definition, a Complex Electronic Device can be simply defined as one that cannot be classified as a Simple Electronic Device. Examples of complex electronic devices include all flavors of Programmable Logic Devices (PLDs), such as Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs) and Application Specific Integrated Circuits (ASICs). DO-254 is written to cover all complex electronic hardware; however, FAA advisory circular 20-152 only requires the standard to be followed for complex electronic devices with design assurance levels of A, B and C.

Hardware Development Life Cycle

Rather than specifying how the electronic hardware is to be designed, produced and manufactured, DO-254 offers a comprehensive list of activities that should be performed and artifacts that must be produced during the hardware development process. The document is not intended to explain how a design should be implemented or what makes a design approach better than another. The standard focuses on the definition of the hardware development life cycle, its phases, activities and artifacts.

From a high level perspective, three major groups of processes are identified: 1) Planning Process, 2) Hardware Design Processes, and, 3) Supporting Processes. With the exception of the planning process, processes 2 and 3 are further divided into more specific processes, which are described (below) in detail, including objectives, activities and life cycle data. Figure 1 shows the big picture of the hardware development life cycle processes and their interactions.