Hardware design-assurance level mapping under DO-254

When this review is needed

• An FPGA or ASIC item was started before its design assurance level was fixed and the data has to be scoped to the right level.
• A function's failure classification changed and the hardware items inside it need their levels updated to match.
• An item first classified as simple is found to be complex, and the DO-254 objective set now applies to it.
• An IP core or reused logic block was inherited and the assurance evidence behind it has to be checked against the level it now carries.

The problem

DO-254 turns on whether a hardware item is simple or complex, and that single call decides whether the full objective set applies. The simple-versus-complex line gets drawn early, on programmable logic that later grows in function, and reused IP cores arrive with assurance pedigrees that nobody re-checks against the level the new item carries. The data then sits scoped to an assurance expectation the item has quietly outgrown.

What gets reviewed

• The complex electronic hardware items in the article and their boundaries
• The design assurance level each item carries from its failure classification
• The simple-versus-complex determination for each programmable item
• The DO-254 objective set and lifecycle data each level expects
• Design, validation, and verification data mapped to those objectives
• Reused IP cores and the assurance evidence inherited with them

What gets validated

• Each complex hardware item is assigned a design assurance level traceable to its failure classification
• The objective set applied to each item matches the level it carries
• Design, validation, and verification data map to the objectives the level expects
• Items called simple meet the criteria for that classification rather than defaulting to it
• Reused IP carries assurance evidence consistent with the level of the item it sits in
• Any item with no level assigned or no data mapped is flagged

Evidence normally required

• The hardware item list and the architecture that defines their boundaries
• The failure classification and the safety assessment behind it
• The PHAC and the rest of the hardware plans
• The pedigree of any reused IP cores or inherited logic
• The design, validation, and verification data produced so far

Common discrepancies

• A complex hardware item carrying a level below its failure classification
• An item called simple to avoid the DO-254 objective set without meeting the criteria for simple
• Reused IP inherited without assurance evidence matching the level of its host item
• Validation evidence for derived hardware requirements missing at the level that needs it
• A failure-classification change that never propagated to the hardware item levels

What is at stake

An item carried as simple that an audit reads as complex is missing the design, validation, and verification objectives the level demands, and there is no shortcut to manufacture them late. Conversely, an item over-leveled spends elemental analysis and validation effort the failure classification never required. Both show up when the hardware accomplishment summary is read against the safety assessment.

How the work runs

What the buyer receives

• A hardware-item-to-level map keyed to failure classification
• A simple-versus-complex determination record for each programmable item
• An objective coverage view per item against the level it carries
• A list of the lifecycle data the assigned levels require but the program lacks

Who uses the output

• Hardware certification leads preparing the accomplishment summary
• FPGA and ASIC engineers closing the objective gaps at the assigned level
• Program management sizing the validation work the levels imply

How the work fits into the transaction or program

The work scopes the assurance effort to each hardware item's level before the data is produced or audited. It pairs with development-assurance level allocation when the item levels themselves are what shifted, and with software level mapping where a function spans both.

Regulatory limits

Endeavor Elements maps the applicant's hardware items to their design assurance levels and checks the data against them. It does not classify failures for the authority, make compliance findings, or determine that the hardware is approved.

What this review does not cover

• Classifying failure conditions on the authority's behalf
• Producing the missing design, validation, or verification data
• Making official compliance findings or issuing any approval

Specific to this review

• DO-254 applies its full objective set to complex hardware, so an item misclassified as simple skips assurance work the level would otherwise demand.
• Hardware levels follow failure classification, so a change in the safety assessment can re-level several items at once if it is not propagated.
• A reused IP core does not inherit assurance credit automatically; its evidence has to match the level of the item it now sits inside.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits