Skip to content

PMA article data

Airborne electronic hardware lifecycle data support for a PMA article package

This review examines the airborne electronic hardware lifecycle data built to DO-254 for a PMA article, and tests whether it supports the assigned design assurance level. A certification engineer checks that the hardware plans, design data, verification results, and configuration records are present at the level's objectives and describe one consistent hardware item. It catches lifecycle data that supports a lower assurance level than the hardware is assigned, and gaps in the more demanding activities the higher levels add. You receive a gap assessment, an objective-coverage map at the assigned DAL, and a closure plan before formal review.

When this review is needed

  • A DO-254 data set is assembled and the team wants its coverage checked against the assigned design assurance level.
  • The DAL was set by the safety assessment and the higher-level activities may not all be evidenced.
  • A complex device carries elemental analysis or additional verification that needs confirming for the level.
  • The hardware data underpins the accomplishment summary and must be coherent before the summary claims objectives met.

The problem

DO-254 data is built around a design assurance level, and the more demanding activities, the elemental analysis, the additional verification coverage, the independence, apply only above certain levels. It is easy to build a data set that would satisfy a lower DAL and assume it covers the assigned one, leaving the level-specific activities thin or absent. Design data, verification, and configuration records also drift out of step across a long hardware program, so the set can look complete while the pieces describe slightly different versions of the device.

What gets reviewed

  • Hardware plans checked for the objectives the assigned DAL requires
  • Design data confirmed complete and consistent with the verified device
  • Verification results checked for the coverage and independence the DAL demands
  • Elemental analysis and additional verification confirmed where the level requires them
  • Configuration management records reconciled to one device version
  • Objective gaps between the delivered data and the assigned DAL flagged

Scope this review

Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.

Identify what is missing against the means of compliance.

What gets validated

  • Every DO-254 objective for the assigned DAL is addressed by lifecycle data
  • Verification meets the coverage and independence the level requires
  • Elemental analysis or additional verification is present where the DAL demands it
  • Design and configuration data describe one consistent device version
  • The accomplishment summary matches the hardware records it rests on

Evidence normally required

  • The DO-254 hardware plans and their current revisions
  • Design data, requirements, and the verification results for the device
  • Elemental analysis and additional verification data where applicable
  • Configuration management records for the hardware item
  • The assigned design assurance level and the safety assessment that set it

Common discrepancies

  • Lifecycle data supporting a lower DAL than the one assigned to the device
  • Elemental analysis or additional verification missing where the level requires it
  • Verification coverage or independence short of the assigned DAL
  • Design and configuration records that describe different device versions

What is at stake

Hardware lifecycle data that falls short of its assigned DAL is a finding the FAA will hold, because the level was assigned by the safety assessment to bound the failure consequences. Closing it late can mean additional verification, a fresh elemental analysis, or reconstituting configuration records under review pressure, and any accomplishment summary claiming these objectives met carries the shortfall forward until the records are sampled.

How the work runs

01

Fix the assigned DAL

Confirm the design assurance level set by the safety assessment, since it determines which activities apply.

02

Check objective coverage

Read the hardware data objective by objective against the assigned DAL and note every gap.

03

Reconcile the device version

Confirm design, verification, and configuration records all describe one consistent device.

04

Deliver the map and plan

Provide an objective-coverage map at the DAL and a closure plan for the work each gap requires.

What the buyer receives

  • A gap assessment listing objectives unmet for the assigned design assurance level
  • An objective-coverage map showing where the data meets or misses the DAL
  • A closure plan for the verification, analysis, or configuration work needed

Who uses the output

  • Certification leads asserting hardware objective coverage at review
  • Quality leads confirming configuration records resolve to one device
  • Hardware leads closing the verification and analysis gaps identified

How the work fits into the transaction or program

The hardware lifecycle data is the substance behind the accomplishment summary and the compliance argument for the electronic hardware, so it is checked before those documents rely on it. Confirming coverage against the assigned DAL early keeps a summary or matrix from resting on hardware data a reviewer's sampling would find short.

Start with a single asset

Reduce finding cycles by checking the package first.

Jurisdiction-specific considerations

This work supports PMA approval under the FAA framework, where DO-254 is the recognized means for airborne electronic hardware development assurance. The review keeps the objective-coverage argument in FAA terms and does not recast it for another authority's hardware process.

Regulatory limits

This review assesses whether the lifecycle data meets the assigned design assurance level. It does not design or verify hardware, does not make a compliance finding, and does not grant PMA or any airworthiness approval.

What this review does not cover

  • Producing missing verification, analysis, or configuration records
  • Performing the safety assessment that assigns the design assurance level
  • Conducting elemental analysis or additional verification for the supplier

Specific to this review

  • DO-254 layers activities by level, so elemental analysis and additional verification appear only above certain DALs and are the first things missing when data is built to a lower target.
  • A complex device can pass a lower-level data check yet miss the assurance activities its assigned DAL adds, which makes the DAL the anchor for every review.
  • Design and configuration drift is a hardware-specific trap: a late board spin leaves records describing versions that no longer match the verified device.
  • Independence expectations rise with the DAL, so verification done without the required independence reads complete but does not satisfy the level.

Sources

Frequently asked questions

Do we need elemental analysis for our device?

It depends on the assigned design assurance level and the device complexity. The more demanding verification activities, including elemental analysis, apply above certain levels, so the review confirms the assigned DAL and checks whether those activities are present where the level requires them. If they are missing at a level that demands them, that gap goes on the closure plan.

Relevant glossary terms

Related pages

Where this fits

Talk to an engineer who has done this work

We will walk through your current state, the records or evidence involved, and a scoped first engagement.

Talk through the aircraft, records, evidence, deadline, and next useful step.