Health-monitoring equipment
Health-monitoring equipment evidence for STC installation approval
This review prepares the certification evidence a supplier needs to install health-monitoring equipment under an STC and have the installation approved. A certification engineer reads the qualification and software artifacts, the sensor interface definitions, and the installation assumptions, then traces each one to the certification basis and the agreed means of compliance. It runs once the installation design is stable and the approval submission is in view. You receive a product-specific gap list, a requirement-to-evidence trace map, and a closure sequence ordered so the STC package holds together at review.
When this review is needed
- A health-monitoring unit is being fitted under an STC and the installation evidence has to stand on its own at approval.
- The equipment carries embedded software and the software lifecycle data must line up with the installation claims.
- Sensor placement and wiring were fixed late in the design and the interface assumptions were never checked against the basis.
- A submission date is set and the supplier needs to know which evidence is missing before the authority sees the package.
The problem
Health-monitoring installations sit between the airframe and a data pipeline, so the evidence spans structural sensor mounting, wiring, environmental qualification, and software behavior at once. The pieces are usually authored by different teams against different templates, and the installation assumptions written into the qualification plan rarely get reconciled against the actual STC basis. By the time the package is assembled, no single person can say whether every requirement has a matching artifact.
What gets reviewed
- Data integrity and sensor-interface definitions checked against the installation as designed
- DO-178C software lifecycle artifacts mapped to the equipment's declared software level
- DO-160G environmental qualification categories matched to the installation environment
- Installation assumptions in the qualification plan reconciled against the STC certification basis
- The agreed means of compliance confirmed for each applicable requirement
- Configuration of the delivered evidence set against the current installation design
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
- Each sensor-interface requirement traces to a test, analysis, or inspection artifact by identifier
- The software level claimed for the health-monitoring function matches the objectives its DO-178C data satisfies
- DO-160G test categories cover the vibration, power, and environmental conditions the installation actually sees
- Installation assumptions recorded in qualification are consistent with the airframe interface the STC describes
- No requirement is marked complete against evidence written for a superseded installation configuration
Evidence normally required
- The STC certification basis and the applicant's compliance checklist
- DO-178C plans, software verification results, and the declared software level
- DO-160G qualification test plan and results for the equipment
- Sensor interface control documents and installation drawings
- The current equipment and installation configuration list
Common discrepancies
- A sensor interface requirement with no verification artifact behind it
- Software verification results written against a build that predates the current installation
- DO-160G categories qualified for a benign environment the installation does not match
- An installation assumption in qualification that contradicts the STC interface definition
What is at stake
An installation submitted with unreconciled evidence draws findings that reopen the software and environmental data together, because the authority cannot tell which assumption each artifact was written against. That turns one review cycle into several, and each cycle pulls engineers back onto work they thought was closed. A slipped STC also holds the equipment out of the field, which is the outcome the supplier is trying to avoid.
How the work runs
Fix the basis
Establish the STC certification basis and the means of compliance the installation evidence must answer.
Map the artifacts
Trace each software, environmental, and interface artifact to the requirement it is meant to satisfy.
Reconcile assumptions
Check that qualification installation assumptions match the STC interface as designed.
Sequence the closure
Order the missing artifacts so the package is coherent when the authority reviews it.
What the buyer receives
- A product-specific evidence gap list keyed to the installation requirements
- A requirement-to-evidence trace map covering software, environmental, and interface data
- A closure sequence ordering the missing artifacts so the STC package holds at review
Who uses the output
- Certification leads assembling the STC submission and answering to the authority
- Software and hardware engineers who own the artifacts each gap points to
- Program managers sequencing the closure work against the submission date
How the work fits into the transaction or program
The review sits between equipment qualification and the STC submission. It takes the artifacts the design teams produced and confirms they answer the installation basis before the package goes to the authority, so findings surface internally rather than in the authority's response. The trace map it produces becomes the spine of the compliance submission.
Start with a single asset
Confirm requirements map to substantiating evidence.
Jurisdiction-specific considerations
An installation pursued under both FAA and EASA acceptance has to satisfy two certification bases that treat software and environmental evidence differently in their acceptance detail. The review notes where a single artifact set covers both and where one authority will expect additional substantiation the other does not.
Regulatory limits
The review checks that the installation evidence is complete, traceable, and consistent with the basis. It does not issue or grant the STC, approve the installation, or make any airworthiness determination, all of which rest with the authority.
What this review does not cover
- Authoring the software or environmental qualification evidence itself
- Performing the installation or its physical inspection
- Any approval or airworthiness decision on the modification
Specific to this review
- Health-monitoring installations fail trace most often at the sensor interface, where structural mounting evidence and software behavior have to agree but are authored separately.
- A DO-178C software level claimed but not backed by the matching objective evidence is a finding the authority raises early, before it looks at the installation.
- DO-160G categories qualified for the wrong environment are common when a unit designed for one platform is reused on another without re-checking the installation conditions.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
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).
Frequently asked questions
Do you write the missing qualification or software evidence?
No. The review identifies which artifacts are missing or mismatched and traces what each requirement needs. Producing the software verification, environmental test, or interface substantiation stays with the supplier's own engineering teams.
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.