The RTCA/DO-254 document is entitled “Design Assurance Guidance for Airborne Electronic Hardware.” A committee of industry experts (known as SC-180) developed it during the late 1990’s under the guidance of the RTCA organization in conjunction with EUROCAE. The document imposes a structured and rigorous development process, focused on thorough verification and oversight, to ensure the safety of in-flight hardware. The committee finalized the document in the year 2000. Both the Federal Aviation Administration (FAA) in the US and European Aviation Safety Agency (EASA) in Europe invoked it as policy in 2005. Note that the EUROCAE organization also published the document under the name ED-80 for the European audience. The content of these documents is identical between the EU and USA.
You can read the document on your own, but to really understand how to apply it and what you must do to comply with DO-254, you will need some education. The DO-254 document itself is not that complicated; however, how the world authorities interpret it and what the means for your own compliance process can be confusing and complicated.
Part of this complication arises because the authors of DO-254 intended it to guide the development of “electronics,” which is a fairly broad scope. But when the FAA invoked it, AC 20-152 established the scope on a much smaller scope – to apply only to DAL A-C complex, custom micro-coded components (even though this scope has gradually shifted). EASA, as of 11/2017, still has not formally recognized DO-254 as a means of compliance through a AMC20-xxx. EASA utilizes project specific Certification Review Items (CRI) for the application and acceptance of DO-254 for civil avionics projects.
In addition, the style of RTCA documents are intentionally “non-prescriptive.” This means they provide general objectives that describe “what” must be done, but they provide no examples explaining “how.” So while this approach provides a lot of flexibility, it also creates a lot of ambiguity.
At this point, the document is also aging, which creates additional concerns. The committee worked on this over 20 years ago, and electronics designs have evolved substantially over this period of time. Thus, the original authors could not even imagine, and therefore did not cover and clarify, many aspects of today’s electronic designs.
Finally, while DO-254 is a static document, numerous other documents have been shaping its interpretation. Advisory circulars (specifically AC 20-152), orders (specifically Order 8110.105, now 8110.105A), certification memos (namely EASA CM SWCEH-001), issue papers and certification review items all currently shape DO-254 interpretation. Likewise, sometimes project specific requirements along with changing interpretations by the certification authorities and auditors drive the expectations of DO-254 compliance. Again, compliance is quite complicated! A harmonization effort between the FAA and EASA as of 11/2017 could lead to improved clarity. The FAA/EASA should release a harmonized AC/AMC20-152A by end of year 2017 or early 2018. The “Overarching Properties” initiative could also influence the compliance requirements of DO-254.
What follows is a summary of the content of the original document. The DO-254 Life Cycle (i.e., the process you must follow) describes an extensive planning phase, which guides the five phases of development and supporting process. Each step includes its own plans to guide it, its own objectives and activities, its own reviews to verify everything, and its own artifacts to show evidence of compliance.
DO-254 Development
The five phases of development are:
-
Requirements Capture
The systems development process provides requirements that the HW design team breaks down into hardware requirements that they will implement in the program. -
Conceptual Design
The team develops a high-level design concept. -
Detailed Design
The team does the actual coding, taking the HW requirements and concept description and turning it into a hardware design. -
Implementation
During this phase, the team takes the design code through various transformations and ultimately into its physical format. -
Production Transition
Then team defines a process to ensure handoff of the controlled design into a production environment.
DO-254 Supporting Processes
The Supporting Process are:
-
Validation and Verification
Validation ensures the requirements are correct. Verification ensures that the design implements the requirements correctly. Validation and Verification go hand in hand in the program and are often difficult to distinguish. -
Configuration Management
These processes ensure proper data control and replication. -
Process Assurance
The Process Assurance representative on the team ensures that the project’s development processes meet the life cycle process objectives, as per plans (and documents and approves any deviations) -
Certification Liaison
The certification authority reviews plans, processes, and artifacts periodically to ensure compliance.
It seems simple and straightforward enough, but the process is strewn with unknowns and pitfalls that can result in high cost and late schedules if the team does not anticipate and address them.
To learn more purchase the DO-254 document from RTC. Read it to get a basic familiarization. Then get training (and potentially consulting) to understand what you’ve read and how to apply it most efficiently to your own project given your own company’s processes and resources.