PMA article data
Safety assessment evidence support for a PMA article approval
Safety assessment support readies the functional hazard, preliminary, and system safety analyses that a PMA article approval package rests on. It is done ahead of formal review, for a part supplier who has to show that hazard classifications and failure conditions actually tie to requirements and verified evidence. The work reads the FHA, PSSA, and SSA against the certification basis and finds every place where a safety result asserts a conclusion no requirement or test supports. You come away with a scored gap assessment, an evidence map linking each safety claim to its source, and a closure plan that orders the fixes before the package leaves your hands.
When this review is needed
- A hazard classification in the PSSA drives a design assurance level that the supporting analysis has never been reconciled to.
- The SSA cites failure rates and exposure times that no verification evidence in the package actually backs.
- A design change late in the program shifted a failure condition and the safety analyses have not caught up.
- The applicant is about to open formal review and wants the safety story checked before an authority reads it.
The problem
Safety analyses are written early and revised often, so by the time a PMA article package is assembled the FHA, PSSA, and SSA rarely agree with each other or with the requirements they are supposed to justify. A hazard called catastrophic in one document is major in the next, an assumed failure rate has no test behind it, and a mitigation credited in the analysis appears nowhere in the design. The applicant knows the pieces exist but cannot show a reader that they hold together.
What gets reviewed
- Functional hazard assessment reviewed for hazard classifications consistent across the analysis set
- Preliminary safety assessment checked so derived safety requirements map to the design
- System safety assessment reconciled to failure rates, exposure times, and verification evidence
- Safety requirements traced back to the certification basis and forward to test or analysis
- Design assurance level assignments confirmed against the hazard classifications that drive them
- Late design changes checked for their effect on failure conditions and mitigations
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 hazard classification carries the same severity across the FHA, PSSA, and SSA with no silent reclassification
- Derived safety requirements in the PSSA appear in the design and carry a verification path
- Failure rates and exposure times cited in the SSA are supported by data the package contains
- Every credited mitigation is present in the design and shown to work by test or analysis
- Design assurance levels follow from the hazard classifications rather than being asserted independently
Evidence normally required
- The functional hazard assessment for the article and its functions
- The preliminary and system safety assessments with their supporting analyses
- The requirements set and the certification basis the article is approved against
- Verification evidence for the failure conditions and mitigations the safety case relies on
- The change history for any design revision that touched a failure condition
Common discrepancies
- A hazard reclassified between analysis revisions without the design assurance level following it
- An SSA failure rate assumed rather than substantiated by test or field data in the package
- A safety requirement derived in the PSSA that never reached the design or a verification method
- A mitigation credited in the analysis that the reviewed design does not actually implement
What is at stake
A safety case that does not trace invites questions the applicant cannot answer on the spot, and each unanswered question stalls the review while the authority waits for evidence that may not exist. Left unaddressed, a mismatched hazard classification can force a design assurance level to be reworked after the fact, which reopens verification that was thought complete and pushes the approval date out by weeks.
How the work runs
Read the hazard set
Assemble the FHA, PSSA, and SSA and confirm hazard classifications agree across the three.
Trace safety requirements
Follow each derived safety requirement into the design and to a verification method.
Test the assumptions
Check that cited failure rates, exposure times, and mitigations are backed by evidence in the package.
Score and sequence
Rank the gaps by their effect on the approval and lay out the order to close them.
What the buyer receives
Who uses the output
- Certification leads assembling a safety case that will survive an authority's questions
- Engineering owners deciding whether a hazard classification or mitigation has to be reworked
- Quality leads confirming the safety evidence is coherent before the package is released
How the work fits into the transaction or program
The safety assessment sits at the center of the compliance story, because the design assurance levels and much of the verification effort flow from it. Checking it before formal review means the applicant fixes a broken hazard trace on their own schedule rather than under an authority's questions, and the evidence map it produces feeds straight into the compliance matrix the rest of the package hangs on.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The safety analyses follow the ARP4761A and ARP4754B methods the FAA accepts, and the certification basis for the article sets which failure conditions and classifications the authority expects to see justified. Where the same part is aimed at more than one authority, the review notes where the accepted hazard classifications or credited mitigations diverge so the applicant is not surprised later.
Regulatory limits
The review checks that the safety evidence is internally consistent and traceable to requirements and verification. It does not make an airworthiness determination, classify a hazard on the authority's behalf, or grant or predict any approval of the article.
What this review does not cover
Specific to this review
- Design assurance levels are set by the hazard classifications, so a single reclassified hazard can invalidate a whole branch of verification thought complete.
- Safety analyses are revised more often than any other document in the package, which is why their conclusions drift out of step with the requirements they justify.
- A credited mitigation that never made it into the design is one of the hardest findings to see, because the analysis reads as complete on its own.
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. FAA type certification process, certification basis establishment, and compliance findings.
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
Do you redo the safety analyses or just review them?
The work reviews the analyses you already have and shows where their conclusions do not trace to requirements or verification. It does not author the FHA, PSSA, or SSA, and it does not run the tests that would substantiate an assumed failure rate. Those stay with your engineering team.
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.