AML STC expansion
Safety assessment support for an AML STC model-list expansion
This work reviews the safety assessment supporting an approved model list expansion, confirming the failure conditions, their classifications, and the requirements they generate still hold for the added aircraft. It serves avionics and equipment suppliers extending an STC to new models, before submission. The review walks the FHA, PSSA, and SSA and checks that the results feed back into requirements and verification rather than sitting apart from them. You receive a gap assessment, a traced safety argument, and a closure plan for the assessment work the expansion reopens.
When this review is needed
- The added aircraft integrate the equipment differently, so a failure condition or its classification may change.
- The launch FHA assumed an installation and architecture that the new models do not share.
- The safety assessment produced requirements that have to be confirmed as still allocated and verified for the expansion.
- A reviewer will trace failure-condition classifications into the software and hardware levels and the supplier wants that chain intact first.
The problem
A safety assessment is built on the launch aircraft's architecture and installation. When the equipment moves to a different model, the same failure can carry a different severity: a function that was minor in one installation can become hazardous in another because the surrounding systems and mitigations differ. The FHA, PSSA, and SSA written for the original model can quietly stop describing the added aircraft, while the classifications they set still drive the software and hardware levels downstream.
What gets reviewed
- Failure conditions from the FHA re-examined for the architecture of the added aircraft
- Classification severity re-checked where the new installation changes the effect of a failure
- PSSA and SSA results reconciled to the added models' integration and mitigations
- Safety requirements traced into the requirement set and their verification
- Classifications that drive software and hardware levels confirmed against the current assessment
- Reopened assessment items 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
- Each failure condition reflects the architecture and installation of the added aircraft
- Classification severity accounts for the mitigations actually present on the new models
- PSSA and SSA results are consistent with the integration on the added effectivity
- Safety-driven requirements are allocated and traced to verification
- The classifications feeding software and hardware levels match the current assessment
Evidence normally required
- The FHA, PSSA, and SSA from the original AML STC
- The architecture and integration description for the added aircraft models
- The safety requirements and their allocation
- The failure-condition classifications driving the assigned software and hardware levels
- Any mitigation or independence assumptions the assessment relied on
Common discrepancies
- A failure condition whose severity rises on the added aircraft because a mitigation present on the launch model is absent
- An FHA that describes the original architecture rather than the added installation
- A safety requirement generated by the assessment that never reached the requirement set
- A classification driving a software or hardware level that the current assessment no longer supports
What is at stake
A stale classification is the most expensive kind of gap, because everything downstream depends on it. If a failure condition is more severe on the added model, the software and hardware levels it drives are understated, and the lifecycle data built to those levels is short before anyone looks at it. Safety results that never fed back into requirements leave the argument disconnected, which is exactly what a reviewer probes. Reopening the assessment late cascades into re-verification across the package.
How the work runs
Re-open the failure set
Take the FHA failure conditions and re-examine them against the architecture of the added aircraft.
Re-check the classifications
Confirm each severity accounts for the mitigations actually present on the new models.
Trace results to requirements
Follow PSSA and SSA outputs into the requirement set and their verification.
Plan the reopened work
Sequence the assessment items the expansion reopens into a closure plan before submission.
What the buyer receives
Who uses the output
- STC holders confirming the safety argument holds for every added aircraft model
- Certification leadership judging whether classifications still support the assigned levels
- Program managers scoping reopened assessment work against the schedule
How the work fits into the transaction or program
The safety assessment sits upstream of almost everything else in the expansion. Its classifications set the software and hardware levels, and its requirements flow into the trace, so it is reviewed early and its findings ripple forward. A change here can reopen the DO-178C and DO-254 data reviews, which is why the assessment is confirmed before those levels are treated as fixed.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both accept ARP4761A methods, but their expectations on how classifications are justified and how the safety argument is documented can differ. The review flags where the assessment rationale is thin so the failure-condition case holds for either authority reviewing the expansion.
Regulatory limits
This work reviews the safety assessment for consistency and traceability. It does not classify failure conditions on the authority's behalf, accept the assessment, or make a compliance finding on the safety of the installation.
What this review does not cover
- Performing the aircraft-level safety assessment or its analyses
- Setting or approving failure-condition classifications
- Any airworthiness or safety determination on the installation
Specific to this review
- The same failure can classify differently across models, because severity depends on the surrounding architecture and the mitigations each installation provides.
- A stale classification is the most costly gap in an expansion, since it silently understates the software and hardware levels built beneath it.
- Safety results that never feed back into requirements leave the argument disconnected, and that disconnect is exactly what a reviewer traces for.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Why can a failure condition change classification just because the aircraft model changed?
Severity depends on effect, and effect depends on the surrounding systems. A function backed up by an independent path on the launch aircraft can be single-thread on an added model, which raises the classification. Because that classification drives the software and hardware levels, the review confirms it before those levels are relied on downstream.
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.