CERTON’s Frequently Asked Questions

What industries do the DO-254 guidelines apply to?

The DO-254 guidelines apply to civil aviation for aircraft, helicopters and engines as mandated by the Federal Aviation Regulations. The guidelines apply to the systems and equipment that utilize software or airborne electronic hardware used in aviation.

Does all of the hardware implemented in a PLD need to be at the same Design Assurance Level?

Yes. It would be difficult to prove that functions of different Design Assurance Levels did not interact with each other. Shared clocks and routing resources also introduce coupling and dependencies that the designer did not intend. Credit for floor planning features in PLD design tools should not be assumed.

How can existing hardware be upgraded to comply with DO-254?

This depends on the quantity and quality of the documentation and lifecycle data produced in the original development.

In general, the FAA eschews reverse engineering to produce compliance data for software. If this approach is proposed, then it is recommended that the applicant seeks FAA agreement with the approach before proceeding with the effort. The biggest problem with existing software and hardware is producing the functional requirements needed to use in the verification testing. Requirements written after the fact tend to be based on knowledge and/or description of the specific design or implementation – not the intended function. When this happens, the verification testing proves that the design or implementation is met and not that the implementation meets its functional requirements. If the hardware/software was originally developed and approved at a lower Design Assurance Level and needs to be upgraded to a higher Design Assurance Level, then service history assessment, additional testing and activities required by the higher Design Assurance Level may be performed.

Where do traditional Preliminary and Critical Design Reviews (PDR/CDR) fit in the design life cycle timeline?

The Preliminary Design Review (PDR) is usually performed when the software or hardware requirements trace to and fully implement the system or parent requirements baseline. The Critical Design review (CDR) is usually performed when the software or hardware design traces to and fully implements its requirements. A software CDR is performed prior to the formal coding phase. A hardware CDR is typically used as an approval gate to manufacture hardware to be used in formal tests.

When should the V&V team get involved on a project?

V&V should be involved right from the planning phase. The team should write their own verification plan and assess the project needs for tools, equipment and the overall approach for verification and testing.

- V&V can review plans and standards when independent review is required.
- V&V can also perform an overview of the system, hardware and software to look for overlaps in the testing. This may allow integrated tests to cover system, software and/or electronic hardware requirements all in one test case. Such an approach requires a disciplined effort in requirements capture. It also requires test equipment that can capture analog, digital waveforms, and software data simultaneously during a test scenario.
- V&V can be highly useful and effective in requirements reviews. They can provide early feedback on whether the requirements, as written, can be verified by analysis and/or test.
- V&V can start writing their test cases as soon as the requirements are available and ideally, reviewed and released.

What is validation and when should it occur? How much design can be completed before validation?

In RTCA/DO-254 validation is the review/analysis and/or test of derived requirements to ensure that they are correct and complete in the context of the parent requirements allocated to the hardware item (i.e. a PLD). Validation of the derived requirements, for a programmable logic device (PLD) is typically performed during the review of the requirements document. All requirements denoted as "derived" are evaluated against the applicable criteria for completeness/correctness. Since the design is created to fulfill and trace to the requirements, including the derived requirements, any design work done before the derived requirements have been validated would be done at risk. That is, if the validation of the derived requirements causes changes, then there may be a downstream effect on the respective part of the design. Aerospace Recommended Practice ARP-4754 defines methods for validation of system requirements. Requirements specified at a system level and then allocated for implementation in software or airborne electronic hardware do not need to be validated again at the software or airborne electronic hardware level.

How is the Implementation phase similar between hardware and software? How is it different?

For hardware the implementation phase produces test articles using manufacturing processes and techniques identical or similar to the production environment. Once the hardware has been tested and any final changes made, the data from the implementation phase is used in the production of the hardware. Software does not have an implementation phase defined in DO-178B. The integration activity is similar to the implementation defined in DO-254.

For software, once testing is complete, the executable object code and data necessary for load control of the software is provided to production. Note that the hardware would need to be produced in an implementation phase before the software testing can be formally concluded. That is, software needs to be tested on flight hardware. The flight hardware needs to be representative of the final configuration.

Are there "High Level" and "Low Level" requirements in DO-254? Explain.

o DO-254 only specifies requirements. The design of hardware is not considered requirements. The "High Level" and "Low Level" paradigm is specific to DO-178B. This paradigm can be problematic for DO-254, especially for programmable logic devices. Software low level requirements usually require white box verification techniques to adequately test these requirements. With hardware, there is usually no convenient way to instrument internal nodes of chips to collect or inject test data. Also, for in-circuit hardware tests, the inputs to a PLD are constrained to pin level inputs. For DO-254, trying to specify low level requirements often results in designers documenting implementation specifics masquerading as functional requirements. While this is useful information, verifying these types of requirements only proves that the design is in fact the design. It does not support demonstrating that the design meets its requirements and performs its intended function.

Are there any requirements in the Hardware Design Document?

DO-254 specifies that any requirements captured during the hardware design process are fed back to the requirements capture process. The hardware design should specify the design of the hardware in text, graphical representations, schematics, diagrams or a hardware description language (HDL). A schematic specifies a circuit design – it is not a requirement.

Does DO-254 have levels similar to those for DO-178B? If so, how many levels are there and what do they entail certification wise?

DO-254 uses design assurance Level A/B/C/D/E similar to the categories as DO-178B for software. The design assurance level for hardware is determined by the classification of the hazard that a hardware failure or anomalous behavior results in. The design assurance level for software considers software cause and contribution to hazards. The objectives in Chapters 4 through 9 are required for Level A/B/C/D. In addition, Level A and B hardware needs to address the guidance in DO-254 Section 2.3.4 and the additional considerations in Appendix B.

Where does DO-254 fit into the FAA TSO certification?

FAA Advisory Circular 20-115B for software and 20-152 for airborne electronic hardware allow the use of DO-178B and DO-254, respectively, for TSO compliance. If equipment is developed under TSO rules, the applicant can show compliance to DO-178B for software and DO-254 for airborne electronic hardware. Current policy allows for DERs to make compliance findings for DO-178B and DO-254 for TSOs. This policy is currently being reassessed by the FAA.

Are there any other top-tiered certifications that DO-254 can be applied to?

Currently, DO-178B and DO-254 are aerospace specifications for commercial aircraft. They are a collection of industry best practices.

What are the most common mistakes a company makes while trying to get their product or system through certification?

- Underestimating the value of effective planning.
- Underestimating the value of well documented and well reasoned standards.
- Underestimating the value of well crafted requirements.
- Underestimating the scope of verification.
- Emphasizing delivery of software or hardware over producing well crafted requirements and design documentation.
- Overestimating the capabilities of outsourced or contracted work.
- Lack of proper oversight of outsourced or contracted activities.
- Not incorporating project specific requirements, such as FAA Issue Papers. The assumption that what was acceptable for the last development program will work on the current program is often incorrect.
- Not considering electronic hardware aspects and software design tools in common cause analysis.
- Looking for ways to avoid the real work that compliance entails.

How many stages of involvement are between the 'authority' (FAA) and the company that is trying to obtain certification and what documents are due at each S.O.I. audit?

The Stage of Involvement (SOI) audits are defined in the FAA Orders for software (8110.49) and airborne electronic hardware (8110.105). All four audits are performed for each program. The amount of direct FAA involvement is determined by a set of criteria called the level of FAA involvement (LOFI). SOI activity is also determined by the amount of delegation to a DER, program requirements and FAA Issue Papers on supplier oversight.

FAA Order 8110.105 defines 4 Stage of Involvement (SOI) audits for hardware:

- Hardware Planning Review (SOI #1)
- Hardware Design Review (SOI #2)
- Hardware Validation and Verification Review (SOI #3)
- Final Review (SOI #4)

The lifecycle data inspected at each SOI audit is defined in the respective FAA Order for software (8110.49) and airborne electronic hardware (8110.105).

How many objectives are there in DO-254 that must be addressed?

There are 34 objectives defined in DO-254.

- All 34 apply to Level A-C hardware.
- The objectives also apply for Level D hardware if the applicant elects to use DO-254 for compliance.

What is a DER? What does the DER have to do with DO-254?

A Designated Engineering Representative (DER) is a representative of the FAA Administrator authorized by law to examine, test, and/or make inspections necessary to issue aircraft certificates. A DER is not an employee of the U.S. Government, and is not federally protected for the work they perform or their decisions.

For a given project, a DER may be delegated to make compliance findings to the applicable Federal Aviation Regulations on behalf of the FAA. For airborne electronic hardware, compliance to the Federal Aviation Regulations may be established by finding compliance to the objectives in DO-254 (as permitted by Advisory Circular 20-152). For software, compliance to the Federal Aviation Regulations may be established by finding compliance to the objectives in DO-178B (as permitted by Advisory Circular 20-115B). The DER then assesses compliance to DO-178B or DO-254 as a means of compliance to the Federal Aviation Regulations. The compliance findings are documented on FAA form 8110-3.

DERs can fulfill their role as a company DER or a consultant DER. A company DER has delegation for the products their employer produces. A consultant can get delegation for projects from different suppliers or airframe manufacturers. For companies with an organizational delegation, a DER can perform their duties as an Authorized Representative (AR) in a Delegation Option Authorization (DOA) or a Unit Member (UM) in an Organization Designation Authorization (ODA).

Is DO-254 used by the Military?

Military projects can elect to use DO-178B and DO-254. The compliance to DO-178B and DO-254 is determined by the project, not the FAA. Military projects often cite these guidelines since the supplier often already have exposure. The FAA has a Military Certification Office (MCO) in Wichita, KS for military aircraft derived from commercial products. FAA certification can be performed for an already certified civilian aircraft adapted for military use. There would however be no way to certify a fighter jet since it does not have a civilian application.