DO-254 – DESIGN ASSURANCE GUIDANCE
FOR AIRBORNE ELECTRONIC HARDWARE

Introduction

• Outlines a structured approach for reducing errors introduced to ensure design assurance
  • All of those planned and systematic actions used to substantiate, at an adequate level of confidence, that design errors have been identified and corrected such that the hardware satisfies the application certification basis.
• Formed by a group of industry experts under the RTCA [Radio Technical Commission for Aeronautics]
• ED-80 is the European equivalent

Scope

• Initially all electronics components
• During invocation, this was updated to complex custom integrated circuit with Design Assurance Levels A, B & C
  • Application Specific Integrated Circuits (ASIC)
  • Programmable Logic Devices (PLD)
  • Field Programmable Gate Arrays (FPGA)

Style

• Non-prescriptive
• Objectives Based
• Outlines the objectives that need to be met, then it is up to the user to decide how to achieve these objectives

Date

• Written in the 1990;s, published in 2000, invoked in 2005.
• Quite outdated

Layout

Table 2-1 Design Assurance Levels

Figure 1-1 Document Context

Appendix A – Design Assurance Levels Objectives Modulation

• What objectives need to be met
• What data needs to be recorded to prove these objectives
• Sections in the document

Appendix B – DESIGN ASSURANCE CONSIDERATIONS FOR LEVEL A AND B FUNCTIONS

Provides additional instructions to provide assurance for DAL A/B

As the design assurance level increases, the approach needed to verify that a given design meets its safety requirements may need overlapping, layered combinations of design assurance methods.

It says may but it really means will.

Section 11 – Additional Considerations

Common aspects of design and development such as

• Previously developed hardware
  • What to do when modifying already approved DO254 systems or modifying system to meet DO254 approval?
• COTS – Commercial Off-The-Shelf Components
  • What do to if you are using COTS?
• Product Service Experience
  • Having a device which has been in service for a long time, how this affect design assurance
• Tools
  • Software tools used in development and how these can introduce risk or errors
  • Tool assessment and qualification

Development Process

Referring back to Fig 5-1,

• System Processes (Section 2)
  • Feed info down into hardware
  • Defined by AR4754A standards (Systems development)
    • These will identify the requirements assigned to hardware items
    • Design Assurance Level based on system function and safety analysis
  • During the DO254 process there are iterations with the systems process any time there is a modification to the requirements of the system
• Planning (Section 4)
  • This is the real start of the DO254 process
  • Develop a set of planning documents capturing precisely how the project will meet all DO254 objectives, as the what is outlines in the objectives based on DAL.
  • Plan for Hardware Aspects of Certification (PHAC)
    • Overview of the compliance process, referencing the subsequent documents for the next level of detail down (i.e. DO178)
  • Followed by first Stage of Involvement Audit

Hardware Design Processes (Section 5)

These tend to happen sequentially

• Requirements capture (Section 5.1)
  • Capture, break down and expand requirements handed down form system processes
  • Writing precise, unambiguous, unique, complete and testable requirements
  • It is iterated any time there is a modification to the requirements that could affect system function or safety.
    • Making decisions throughout the development process which produces a “Derived Requirement” which will caused an iteration of the requirements capture stage or the system processes stage if this changes the functionality or safety of the component.
  • Requirements are the lifeblood of the DO254 process
• Conceptual Design
  • Examine the validated requirements
  • Formed into a block diagram with high level descriptions of block functions and their interactions
  • Focus on how system safety requirements will be met
• Detailed Design
  • “Meat” of the design flow
  • Writing code for each specific requirements
  • Followed by SOI-2
• Implementation
  • Taken through back-end processes like placement and routing
  • Loaded into an FPGA device
• Production Transition
  • Ensure the team can get from a controlled design code to an exact same FPGA device, repeatedly
  • Followed by SOI-4
  • Handed off to the manufacturing processes

Supporting Processes

Ongoing and interactive throughout the entire DO254 process

• Validation and Verification
  • Validation
    • Ensuring the hardware device being developed it being developed to the right set of requirements
    • “Are we building the right thing?
  • Verification
    • Ensuring the device meets the requirements that have been set
    • “Are we building the thing right?”
  • SOI-3 held to demonstrate correct verification.