DO-254: Insights from a DER

A few weeks ago I had the opportunity to sit down with an avionics industry certification expert, FAA Consultant Designated Engineering Representative (DER), Randall Fulton. We began discussing common mistakes in DO-254 projects, and then branched out to many different areas including future of DO-254, industry engineering best practices, and his advice to organizations new to DO-254.

Louie: In your experience, what are the common mistakes in DO-254 projects?

Randall: Starting certification liaison activities and the SOI-1 planning audit after the design already exists.  Many projects also need to read the additional guidance from the FAA in Order 8110.105 to understand the impact and be prepared to show the data to satisfy the Order. Organizations also underestimate the resources required for a project. This includes staffing as well as managing all the data. Another common area is not appreciating the impact of effective requirements writing skills.

Louie: What is the most commonly misunderstood aspect of DO-254?

Randall: DO-254 is written from the perspective of application to all electronics in a system. It is not PLD specific guidance. DO-254 has to be tailored to application in programs that only require compliance for PLDs. Performing the activities in DO-254 Chapter 2 through 11 will result in Level C design assurance. In order to get Level A and B, additional activities need to be performed at the device and sometimes, at the system level.  

Louie: What are some examples of problematic practices that you see in the industry?

Randall:  Not enough emphasis on the planning phase. Poor organization of verification life cycle data. There can be an overwhelming amount of simulation and hardware test data, having a well-organized data management system can really help. Subpar standards – standards should have enough information to produce a reliable design. Verification standards should explain the types of simulation and testing to perform, the test case selection criteria, how to format and present the data.  

Louie: The software domain just released the new DO-178C, do you think there will be a revision of DO-254?

Randall: Yes, but the time frame is not currently known. The CAST team has recently published Position Paper CAST-31, Technical Clarifications Identified for RTCA DO-254 / EUROCAE ED-80. The topics in CAST-31 will be one of the starting points for clarifications and updates that get addressed in committee to update DO-254. The industry has been working from additional guidance in FAA Order 8110.105 and EASA memos. It is also likely that the topics from this additional guidance will be folded into DO-254.

Louie: The big FPGA vendors are now releasing devices with hard embedded processors.  Should these devices be developed under DO-254 or DO-178C?

Randall: The devices could conceivably be developed for DO-254 compliance, but that is not required from the PLD vendor. DO-178B/C would not apply to the device aspects. Processors and PLDs are considered COTS devices, compliance to DO-254 is not assumed. Use of these devices in avionics hardware should be managed with an Electronic Components Management Plan. Reliability and failure rates should also be appropriate for the application and design assurance level. One of the main considerations for developers using these devices should be provisions for demonstrating the test coverage of the processor to FPGA interface in the SoC. Another important aspect is to have a way to perform software testing for DO-178B/C compliance on the target device, with the device in the flight hardware (processor board). The software testing part could prove difficult is tools and methods are not considered for access to the data needed for software testing.

Louie: We talked about problematic practices earlier, can you also share various engineering best practices for FPGA design and verification?

Randall:  Using a standard for requirements that enforces the notion of expressing PLD requirements as pin level behavior. The requirements should effectively describe what the waveforms or signals would look like if they were captured. All requirements should describe the timing – when an output signal responds either to an input or a time based event. Requirements should be written for the designer and for the test engineer. Another best practice is to create the test case when the requirements are complete. No need to wait until the design is built.

Louie: What is your advice for traceability data?

Randall: The trace data should explain any partial trace coverage such as when a design implement some, but not all aspects of a requirement. The verification traceability should explain any partial trace coverage such as when a test case covers some, but not all aspects of a requirement.  Capture the requirements to design trace data when the design is being performed. Capture the verification trace data when the test cases are written.

Louie: What is your advice especially to organizations working on their first DO-254 project?

Randall: Allow adequate time for planning and creating standards. Take a requirements writing class. Write requirements before finishing the design. Use a file management system for configuration control of the life cycle data.  Find someone with prior DO-254 experience and leverage their knowledge.

About Randall Fulton

Randall’s recent DO-254 projects include the primary flight controls actuation for the Boeing 787-8, lateral control electronics for the Boeing 747-8, flight control systems for the Learjet 85, input/output modules for integrated modular avionics (IMA) electronics, and commercial off-the-shelf data packages for graphics processors used in display systems.

Randall is also the primary instructor for Aldec’s DO-254 Practioner’s Course.