RTCA DO-254, "Design Assurance Guidance For Airborne Electronic Hardware," is the primary guidance for aviation electronic hardware production, with its latest version published in 2000. RTCA DO-254 specifies design lifecycle requirements for avionic systems and provides guidelines for airworthiness of aircraft electronic hardware. DO-254, like DO-178, was released in collaboration with RTCA and EUROCAE. DO-254 was officially adopted by the FAA in 2005 in response to the increasing use of various electronic equipment in aviation.
DO-254 compliance helps enhance the safety of passengers, crew, and operators, and strengthens your organization. Additionally, since some projects require DO-254 compliance, it provides your company with a competitive advantage over other manufacturers and developers who do not provide this compliance.
The main processes for DO-254 certification can be summarized as follows:
- Planning Process
- Development Process
- Verification Process
The development process must begin after the planning process is completed, but the verification process must be carried out from the beginning to the end of the project.
DO-254 standards must be met with the following documents and more:
- PHAC (Plan for Hardware Aspects of Certification)
- HVP (Hardware Verification Plan)
- HVP (Hardware Validation Plan)
- HPAP (Hardware Process Assurance Plan)
- HAS (Hardware Accomplishment Summary)
Some DO-178 documents may resemble DO-254 documents. You can review and purchase our DO-178 documents here.
DO254 Documents
PHAC
PHAC (Plan for Hardware Aspects of Certification) must be produced during the planning process and approved by the certification authority. PHAC reflects an agreement between the certificate applicant and the certification authority on the procedures and actions to be carried out, as well as the resulting evidence to be created, to fulfill the hardware aspects of certification. Within this plan, the developer explains their strategy and how DO-254 is applied. Please click here to review our PHAC document.
Hardware Verification & Validation Plan
Hardware Verification Plan checks whether the hardware meets the design requirements. On the other hand, Hardware Validation Plan is used to check whether the hardware meets the user's operational and functional requirements. As stated in the previous definitions, the fundamental distinction between verification and validation is the environment in which the tests are conducted. The correctness of the design is checked against the design requirements in a verification flow. The correctness of the design is evaluated against the targeted user's requirements during the validation flow. These documents should also be prepared as part of the planning process.
HPAP
HPAP (Hardware Process Assurance Plan) checks whether the hardware design lifecycle processes and data have been identified and comply with approved plans. Methods necessary to meet hardware design assurance objectives, including defined strategies, are recommended to the certification authority. Please click here to review our HPAP document.
HAS
HAS (Hardware Accomplishment Summary) informs the certification authority about what has been accomplished on the hardware side. The difference between PHAC and HAS is that with PHAC you tell the certification authority what you plan to do, while with HAS you tell them what you actually did. HAS should also indicate deviations from the approved PHAC document. HAS should include hardware identification information, hardware status, version history, and compliance declaration. It is also similar to the Software Accomplishment Summary document used for DO-178 compliance. HAS should include sections on system and hardware overview, hardware design lifecycle description, and hardware lifecycle data. Please click here to check our HAS document.
Design Phases
Preliminary Design Phase
The preliminary design phase begins with the functional baseline created during conceptual design and continues with the translation of system-level functional needs into design requirements for subsystems that will be combined to form the system. This translation requires the continuation of the requirements analysis initiated in conceptual design. Specific needs for the system's hardware, software, and personnel must be defined. Benefit/risk analyses are performed, and the preliminary design work results in the creation of an allocated baseline where needs are assigned to individual subsystems comprising the system.
Critical Design Phase
The critical design phase is a multidisciplinary technical process that ensures a system can proceed to production, demonstration, and test while meeting specified performance criteria within cost, schedule, and risk constraints. The product baseline is initiated during the critical design phase. The purpose of the critical design is to evaluate the final design of a system as defined in product specifications for each configuration item in the product baseline, and to verify that each configuration item has been incorporated into detailed design documents.
The critical design phase is completed by conducting a Critical Design Review. CDR ensures that the system can proceed to test and production. It also states that the requirements in question can be met within budget and schedule. The resulting comprehensive drawings and specifications provide a final baseline along with an initial product baseline. CDR must be thorough and comprehensive.
Final Design Phase
The Final Design phase includes precise architectural and technical drawings of every project component. For some projects, it is important to create a final design report. All identified design issues must be resolved before completing the final design phase. Drawings and reports must be detailed enough to provide timelines. A revised timeline, cost estimates, and requirements should be included in the final design report. It must also be confirmed that the project is financially viable. Any changes made during the Final Design Phase are more expensive than those made in previous phases. Consequently, they must be made with great care.
Author: Can Önal ([email protected])
