DO-254 Introduction
Avionics hardware DO-254 clearly explained. DO-254 facts, myths, challenges, and successes described in this paper. DO-254 can be expensive, sometimes increasing hardware development/documentation costs by 150%. This DO-254 paper provides facts to hopefully reduce DO-254 costs by 20-50%.
Today, DO-178C (ED-12C in Europe) is a living document with continual changes including integration with the new ARP4761A and ARP4754B, plus new rules for multicore processing via AC 20-193.
Today, the new A(M)C 20-152A (also called AC 20-152A in the USA) introduces yet more rigor to avionics hardware and supplants the now-old and dated DO-254 and ED-80.
DO-254 has been called “DO-178’s Little Sibling.” Like many little brothers and sisters worldwide however, the term “little” is often wrong and in a few areas the relationship itself is suspect …
The following provides an overview of DO-254 plus relevant differences with DO-178C.
DO-254, or more properly, “Design Assurance Guidance for Airborne Electronic Hardware,” was created as an obvious response to two simultaneous and related events:
1. Firmware was playing a larger role in avionics, with developers rapidly leveraging increased silicon-based complexity, and
2. The avionics firmware development process was unregulated, with certification performed after-the-fact at a high level.
While embedded avionics software engineering made huge strides and inroads in the eighties and nineties, firmware development was considered an informally adjunct art form. But what is “firmware”? When does “soft” become “firm” become “hard”? Time for a review …
Twenty years ago, firmware was relegated to specialized functions within avionics as compared to its highly varied role today. There were multiple reasons early firmware was more limited in aviation:
1. Firmware development tools provided limited flexibility compared to software
2. Firmware was difficult to change once burned or loaded in silicon devices
3. Firmware was considered a less-desirable option than software due to a seemingly more difficult debugging and update process
While there was truth in each of the aforementioned reasons, smart engineers coupled with more capable development environments assured the evolution and adoption of firmware within avionics. In particular, great strides in Field-Programmable Gate Arrays (FPGA’s) brought such firmware to the forefront of aviation. With FPGA’s, all of the aforementioned restrictions on firmware adoption were dramatically reduced. FPGA’s increasingly have very modern development tools, were easy to update, and allowed for potential flexibility and execution speed advantages over software-based logic.
As a result of this evolution (or almost “revolution”) in silicon based logic, avionics developers increasingly exercised the choice of implementing logic via silicon- instead of software. However, DO-178 did not strictly apply to silicon based logic and there was no regulatory counterpart for such; thus silicon-based logic could potentially avoid the certification rigor associated with software, even though the logic may have a nearly identical purpose between software and silicon. Thus the need for DO-254: to ensure that logic developed specifically for avionics purposes underwent a similar development and certification regimen as if it had been implemented via software using DO-178 …
DO-254 then covers Complex Electronic Hardware (CEH), e.g. hardware with embedded logic. DO-254 is:
• A flexible framework for the development of airborne hardware containing avionics-specific logic.
• Able to accommodate almost all types of hardware ranging from sensors, multiplexers, and switches to full-featured FPGA’s and ASIC’s.
• A guideline which tries to cover a nearly infinite spectrum of applications thus lacks specificity for particular projects.
Like software, the term “airborne electronic hardware” from DO-254’s title is wide-ranging. At the beginning and end of the day, hardware is part of a system or more specifically an aviation eco-system. Therefore, DO-254 is normally preceded by a safety assessment per ARP4761 and an avionics system development process per ARP4754A. And the hardware itself will typically be required to undergo environmental testing via DO-160. Therefore, DO-254 is merely one link within the avionics certification chain. Avionics will be neither safe nor compliant without this safe foundation which precedes DO-254.
As previously noted, the DAL greatly affects process rigor applied to hardware via DO-254. The following graphic summarize key differences between the DALS for DO-25.
Key DAL Aspect Differences for DO-254: from AFuzion DO-254 Training
Again, in DO-254 especially, the DAL of the hardware is usually, but not always, the same as the System DAL. Why? The system contains hardware which is necessary to perform its functionality and that hardware is expected to directly correlate to the system’s contribution toward flight safety. However, this principle cannot always hold. For example, the author of this paper worked on one DO-254 project where the System was DAL B, the Software was DAL B and DAL D, but the FPGA was DAL C; in that case the FPGA was used to merely translate data packets which were checked both upstream and downstream via software. Such is the interesting thing about rules: for each one, an exception can be found.
Process Assurance is like Quality Assurance but with a larger scope including auditing of hardware suppliers and manufacturing transition processes. Process Assurance has five primary activities as depicted in the following diagram:
Process Assurance in DO-254 differs from software’sDO-178C quality assurance because hardware’s Process Assurance must audit hardware suppliers and ensure subsequent system manufacturing processes are documented, repeatable, and conform to plans. Since DO-254’s hardware’s Process Assurance has these two additional roles versus software’s Quality Assurance, it has the different name “Process Assurance”.
Scope of DO-254
DO-254 applies to most all avionics hardware, however more recent interpretations and application of DO-254 focus upon Complex electronic hardware as noted previously. Why? Because the Simple hardware is definable via black-box requirements and those requirements (and thus all the Simple functionality) can be tested at a black-box system level for example as already required under ARP4754A. For Simple hardware, the significant additional cost of detailed planning, detailed design, and low-level verification activities prescribed by DO-254 provide little added-value hence are normally not required unless a specific certification authority deems them necessary in a particular instance, for example because ARP4754A was not otherwise applied. Therefore, the most common application of DO-254 is depicted in the figure below which also elucidates the scope of DO-178C:
DO-254’s Planning Process
Wise persons know “What gets planned, gets done”. Wiser avionics authorities know “What gets planned thoroughly can be assessed more thoroughly”. Accordingly, DO-254 requires a detailed planning process consisting of five Plans and four Standards:
The DO-254 Plan for Hardware Aspects of Certification (PHAC) is the foundational planning document of an avionics hardware system. (For information on AFuzion’s DO-254 Templates and checklists, click here: https://afuzion.com/plans-checklists/#do-254-plan-templates )
The DO-254 PHAC provides an overview of the avionics system’s hardware, safety criteria with respect to DAL, and planned certification activities as noted in the following figure from AFuzion’s DO-254 training classes:
A good way to understand the application of DO-254’s four standards is to consider that DO-254 itself covers the more objective (measurable) aspects of the hardware development lifecycle, whereas certain aspects are more subjective yet equally important. Those subjective areas are hardware requirements, hardware design, hardware archival, and hardware V&V. Since each avionics project must have its own processes and assessment criteria for these subjective areas, such are specified within the four project-specific Standards thus making these “subjective” aspects “objective” for each project.
While most of the aviation guidelines are self-contained, DO-254 is unique: because it was originally intended to address all non-software aspects of a system, and there was very little complex hardware logic, numerous adjunct documents were continually added to address the evolving hardware landscape. This historical DO-254 evolution is summarized in the following graphic excerpted from AFuzion’s DO-254 training:
A common question on DO-254 projects is “Does hardware need both high-level and low-level requirements like DO-178C’s software?” The basic answer is “No – hardware only has one level of requirements, but has two levels of design: conceptual design then detailed design”. However, smart practitioners will understand the providing low-level requirements prior to implementing software reduces the number cause of software defects: assumptions. Similarly, hardware logic developers would be well-advised to similarly ensure their single level of hardware requirements was sufficiently detailed. The official hardware versus software requirements/design depiction is shown in the following graphic (see AFuzion’s advanced DO-254 Training, Day 2, for details):
DO-254 (Hardware) versus DO-178C (Software) Requirement/Design Process Flow
Another common question when applied DO-254 to silicon-based logic is “Does DO-254 require logic reviews similar to DO-178C’s software code reviews?” The quick answer is “Yes”. The following figure depicts the necessary inputs and outputs to a hardware logic review. Note the ‘transitions” from pre-to-post-logic review which are performed by engineers and audited by hardware Process Assurance.
To download the remaining 11+ pages of this technical DO-254 Introduction whitepaper, please download below:
Free: Download Remaining 10+ Page Paper Here