ETSO authorization
DO-254 hardware lifecycle data support for ETSO
This review examines the DO-254 airborne electronic hardware lifecycle data behind an EASA European Technical Standard Order authorization, meaning the hardware plans, design data, verification results, and configuration records that show the complex hardware was developed to its assigned design assurance level. A certification specialist checks that the DAL objectives are addressed by the data and that the design and verification actually reach the assurance the level demands. It runs while the hardware data can still be corrected, before it is filed. You receive a gap assessment against the DAL, an evidence map from objective to data, and a closure plan for the shortfalls.
When this review is needed
- The hardware lifecycle data has matured and the supplier wants it checked before filing.
- The assigned DAL calls for advanced verification methods whose results must be shown in the data.
- A complex device such as an FPGA or ASIC was developed and the design assurance has to be substantiated.
- Commercial off-the-shelf or previously developed hardware is being used and needs assessment for the DAL.
The problem
DO-254 applies to the complex hardware in an article, and the effort scales with the assigned design assurance level. The plans commit to a set of activities, the device gets designed and verified, but the data does not always demonstrate the assurance the DAL requires. Verification stops at functional testing where the level called for additional methods, a device is treated as simple when it should have been assessed as complex, or the design data does not trace to the requirements it implements. The binder is thick, yet the assurance argument has holes at the level assigned.
What gets reviewed
- The hardware plans against the assigned DAL and the invoked ETSO
- Design data traced from hardware requirements through implementation
- Verification methods and results against what the DAL requires
- Complexity classification of each device and its justification
- Configuration and archive records for the hardware design data
- Commercial off-the-shelf and previously developed hardware assessed for the DAL
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 the hardware data
- Verification uses methods adequate for the DAL, extending past functional testing where the level requires more
- Each device's complexity classification is justified and drives the right level of effort
- Hardware design data traces from requirements through implementation to verification
- Off-the-shelf or reused hardware carries assessment adequate for the assigned DAL
Evidence normally required
- The hardware lifecycle data set at its current maturity
- The plan for hardware aspects of certification and the design plans
- The hardware design data, including device descriptions and source
- The verification results and the methods behind them
- The assigned DAL and the failure-effect classification behind it
Common discrepancies
- A device treated as simple that warranted a complex-device assessment
- Verification limited to functional testing where the DAL required more
- Design data that does not trace to the hardware requirements it implements
- Off-the-shelf hardware used without assessment for the assigned DAL
What is at stake
Hardware that does not demonstrate its DAL cannot support the function at the failure classification claimed, and closing the gap late is hard: additional verification on a fabricated device may be impossible without a respin, and reclassifying a device as complex reopens the whole hardware lifecycle. Either correction can dominate the remaining schedule.
How the work runs
Confirm the DAL
Establish the assigned design assurance level from the failure-effect classification and the EASA agreement.
Classify the devices
Check each device's complexity classification and confirm it drives the right level of lifecycle effort.
Test the verification
Confirm the verification methods and results meet what the DAL requires, reaching past functional testing where the level demands it.
Assess the reuse
Deliver a gap assessment and a closure plan covering design-data traces and off-the-shelf assessments.
What the buyer receives
Who uses the output
- Certification leads confirming the hardware meets its DAL before filing
- Compliance managers reconciling the hardware data to the matrix and safety case
- Hardware engineers closing the objective and verification gaps found
How the work fits into the transaction or program
The hardware DAL flows down from the article's failure effects the same way the software level does, and the two have to hold together for the function to be authorized. Checking the hardware data against its DAL before it is filed means a shortfall is found while a fix is still possible, rather than after fabrication has closed the cheap paths to correction.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
EASA accepts DO-254 as the means of compliance for complex airborne electronic hardware in an ETSO and expects the DAL to match the hardware's contribution to failure conditions. The review reads the data against the EASA-agreed DAL and any additional verification EASA expects for the device class, not against a lighter interpretation of the standard.
Regulatory limits
The review evaluates the supplier's hardware lifecycle data. It does not design or verify the hardware, accept the data on EASA's behalf, or determine that the hardware meets its DAL in the authority's judgment. Acceptance of the hardware data rests with EASA.
What this review does not cover
- Designing or verifying the airborne electronic hardware
- Accepting the hardware data on the authority's behalf
- Assigning the design assurance level itself
Specific to this review
- Complexity classification drives the entire DO-254 effort, so a device wrongly called simple understates the whole hardware lifecycle built on that call.
- Additional verification a DAL requires can be impossible to add after fabrication without a device respin, which makes early review of verification methods time-critical.
- Off-the-shelf hardware brings no design assurance of its own, so its adequacy for the DAL rests entirely on the assessment the supplier performs and documents.
Sources
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Does DO-254 apply to every part in our hardware?
No. DO-254 lifecycle rigor applies to complex electronic hardware such as programmable devices. The review checks each device's complexity classification first, because that call decides how much of the lifecycle data each device actually needs.
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.