Surveillance hardware
DO-254 hardware assurance evidence support for surveillance equipment
This support reads a surveillance unit's DO-254 evidence set and confirms it actually demonstrates the hardware design assurance the certification plan claims. It suits transponder, ADS-B, and antenna-fed hardware where the airborne electronic hardware sits behind a TSO or STC package. A hardware assurance specialist walks the requirements, conceptual and detailed design data, verification results, and configuration records to see what the DAL demands versus what the package holds. You get a standards map keyed to each DO-254 objective, a gap list ordered by closure effort, and a sequence for clearing findings before submittal.
When this review is needed
- A transponder or ADS-B unit is heading for TSO authorization and the hardware assurance data has never been checked against the plan.
- An authority finding on the airborne electronic hardware has to be answered and the team needs to know which objective it touches.
- A programmable device on the surveillance board was treated as simple hardware and the classification needs a second look.
- The design changed after the last verification run and the evidence has to be shown current for the fielded configuration.
The problem
Surveillance hardware carries a mix of custom logic and off-the-shelf programmable parts, and the DO-254 evidence for those parts is often thinner than the plan implies. A supplier can hold stacks of test reports and still be missing the requirements-to-verification trace that shows each derived requirement was captured and driven back into the safety assessment. That gap does not read on a page count; it reads when a reviewer asks for the thread and it is not there.
What gets reviewed
- Requirements capture for the surveillance hardware, including derived requirements and their rationale
- Conceptual and detailed design data checked against the DAL the plan assigns
- Verification results traced to each hardware requirement rather than presented as a loose test set
- Programmable device classification and the assurance path chosen for each part
- Configuration and problem-report records that fix the evidence to a known hardware build
- The link from derived hardware requirements back into the system safety assessment
What gets validated
- Each hardware requirement traces forward to a verification result and back to a design element
- Derived requirements carry rationale and were passed to the safety process rather than left isolated
- The DAL applied to the surveillance function matches the assignment in the plan and safety assessment
- Programmable device assurance follows the path the plan commits to for that part class
- Verification evidence corresponds to the configuration baseline named in the records
Evidence normally required
- The hardware plans, including the PHAC and verification plan for the surveillance unit
- Requirements, design data, and the verification results for the airborne electronic hardware
- Programmable device configuration data and any device-level assurance records
- The system safety assessment feeding the DAL for the surveillance function
- The certification basis and any prior authority findings on the package
Common discrepancies
- A block of verification results with no requirement they demonstrably close
- A programmable part treated as simple hardware without the analysis to support that call
- Derived requirements present in design notes but never surfaced to the safety assessment
- Verification run against an earlier board revision than the one in the submitted configuration
What is at stake
A package submitted with an incomplete hardware assurance thread draws findings that reopen verification, not paperwork. On surveillance equipment tied to airspace mandates, a stalled DO-254 substantiation delays the whole installation approval, and the cost of rerunning verification late is far higher than confirming the trace held before submittal.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Frame the DAL
Confirm the design assurance level the safety assessment assigns to the surveillance function and what DO-254 objectives it drives.
Walk the trace
Follow each hardware requirement forward to verification and back to design, flagging any break in the thread.
Test the device path
Check that each programmable part follows the assurance path the plan commits to and that its classification holds.
Sequence the closure
Order the open objectives by the effort each takes so the team clears the package in a defensible order.
What the buyer receives
- A standards map keyed to each DO-254 objective for the surveillance hardware
- A gap list ranked by the effort each closure takes
- A closure sequence a reviewer can follow from open finding to supporting evidence
Who uses the output
- Certification leads deciding whether the hardware package is ready to submit
- Hardware engineers who own closing the trace and rerunning any short verification
- Compliance managers tracking which objectives remain open against the submittal date
How the work fits into the transaction or program
The mapping sits between design freeze and submittal, after the hardware verification is nominally done but before the package goes to the authority. It reads the evidence the way a reviewer will, so the gaps surface while the team can still close them, and its output feeds the compliance narrative the TSO or STC submission rests on.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 as a means of compliance for airborne electronic hardware, but the certification basis and the expectations around programmable device assurance can differ between the two systems. The mapping notes where the evidence satisfies one authority's expectation but would need supplement for the other.
Regulatory limits
This work reads and maps evidence against the DO-254 objectives. It does not make an airworthiness determination, approve the hardware design, grant a TSO or STC, or accept the package on any authority's behalf. Those decisions rest with the applicant and the authority.
What this review does not cover
- Authoring the hardware design or verification data itself
- Running or witnessing hardware verification tests
- Issuing any approval or compliance finding for the authority
Specific to this review
- On surveillance boards the weakest DO-254 link is usually the programmable device path, because an off-the-shelf part gets assumed into simple hardware without the analysis that call requires.
- Derived hardware requirements are the ones that fall out of the safety loop, and a reviewer looks for exactly that thread first.
- A high page count of test reports says nothing about assurance if none of them tie back to a stated hardware requirement.
Sources
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.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
Does this cover the environmental qualification for the transponder as well?
No. This mapping is scoped to the DO-254 hardware assurance objectives. Environmental qualification runs against DO-160G and is handled as a separate evidence set, though the two are often reviewed alongside each other for the same unit.
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.