Skip to content

AML STC expansion

DO-254 hardware lifecycle data support for an AML STC expansion

This work reviews the DO-254 airborne electronic hardware lifecycle data behind an approved model list expansion, confirming it supports the design assurance level the added installation assigns. It serves avionics and equipment suppliers extending an STC to new models, before submission. The review examines hardware plans, design data, verification results, and configuration records for consistency with the assigned level, and finds where the data does not carry the DAL claimed. You receive a gap assessment, a level-to-data map, and a closure plan for the hardware data still owed.

When this review is needed

  • The added installation assigns a design assurance level to a hardware function above the level the device was developed to.
  • Complex hardware was revised for the expansion and the verification and configuration data have to reflect the new revision.
  • The original DO-254 data supported the launch aircraft and its DAL rationale has to be re-checked for the added models.
  • A reviewer will read the hardware verification and elemental analysis against the assigned DAL and the supplier wants that read first.

The problem

DO-254 data holds together only when the plans, the design data, the verification, and the configuration records all describe hardware at one design assurance level. When an added installation drives a function's DAL higher, verification that was adequate at the lower level can leave gaps: elemental analysis, additional verification methods, or robustness testing that the higher level expects but the original program never produced. The design data looks finished while the assurance argument for the new level is incomplete.

What gets reviewed

  • The design assurance level each added installation assigns to the hardware confirmed against its failure condition
  • Hardware plans and standards checked for consistency with the assigned DAL
  • Design data and its verification reviewed against the methods the DAL requires
  • The configuration and release records reconciled to the hardware revision being submitted
  • Verification methods expected at the assigned DAL but absent from the data identified
  • Open hardware data assembled into a closure plan for the STC holder

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

  • The assigned DAL matches the failure-condition classification for the added installation
  • Hardware plans and standards are consistent with the objectives of the assigned DAL
  • Verification results include the methods the assigned DAL expects for the hardware
  • Release and configuration records match the hardware revision under review
  • No assurance objective for the DAL is claimed met without supporting data

Evidence normally required

  • The hardware plans and the DO-254 configuration index
  • The hardware requirements, design data, and applicable standards
  • Verification records including analysis, review, and test results
  • Configuration management and release records for the hardware
  • The failure-condition classification driving the DAL on the added models

Common discrepancies

  • A hardware function whose DAL rises on the added installation with verification built for the lower level
  • Elemental or robustness analysis expected at the higher DAL that the data never produced
  • Configuration records pointing to a hardware revision earlier than the one submitted
  • A verification method claimed complete without the record that would evidence it

What is at stake

A hardware function whose DAL rises on the added installation, backed by data built for the lower level, has a real assurance shortfall rather than a clerical one. A reviewer comparing the verification set to the assigned level finds the missing methods, and closing them can mean re-verification against a device that may no longer be easy to instrument. That work has long lead time, and the expansion waits on it.

How the work runs

01

Confirm the assigned DAL

Establish the design assurance level each added installation drives from its failure-condition classification.

02

Check plans and standards

Confirm the hardware plans and standards are written to the assigned DAL's objectives.

03

Review verification and configuration

Check the verification methods and configuration records against what the DAL requires and the revision submitted.

04

Plan the open data

Sequence the hardware data still owed into a closure plan before submission.

What the buyer receives

  • A gap assessment of hardware data that falls short of the assigned DAL
  • A level-to-data map showing where assurance objectives are met and where they are open
  • A closure plan for the hardware lifecycle data still owed before submission

Who uses the output

  • STC holders confirming the hardware data supports the DAL the installation assigns
  • Certification leadership deciding where re-verification of the hardware is required
  • Program managers planning hardware lead time into the expansion schedule

How the work fits into the transaction or program

The hardware data review, like the software review, takes its assigned level from the safety assessment. It runs after the compliance map and alongside the software lifecycle review, and its findings feed the verification trace, because an assurance shortfall at the hardware level is also a hole in the requirement-closing evidence.

Start with a single asset

Reduce finding cycles by checking the package first.

Jurisdiction-specific considerations

FAA and EASA both accept DO-254 for complex electronic hardware, but the expectations on elemental analysis and on the depth of verification at a given DAL can differ. The review flags where the hardware data is thin for the assigned level so the assurance argument holds for either authority.

Regulatory limits

This work reviews the hardware lifecycle data against the assigned DAL. It does not audit the hardware development, accept the data on the authority's behalf, or make a compliance finding on the hardware.

What this review does not cover

  • Performing the hardware verification or analysis that closes an open assurance objective
  • Assigning the DAL or the failure-condition classification
  • Any finding of compliance on the airborne electronic hardware

Specific to this review

  • When an added installation raises a hardware DAL, the usual shortfall is in verification method: elemental analysis or robustness testing the lower level never demanded.
  • Hardware re-verification is often harder than software re-work, because the device may no longer be straightforward to instrument once the program has moved on.
  • Configuration records are the quiet check: they reveal whether the verification data describes the revision actually being submitted.

Sources

Frequently asked questions

How does a DO-254 review differ from the DO-178C software review?

Both check that lifecycle data supports the assigned level, but the shortfalls differ. On hardware, a higher DAL typically calls for elemental analysis and additional verification methods rather than software coverage, and re-verifying a hardware device can be harder than re-running software tests. The review isolates the specific assurance objectives left open at the new DAL.

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.