Safety assessment
Safety assessment evidence support for installation approval
Safety assessment support checks that the functional hazard assessment, the preliminary and system safety assessments, and their feedback into requirements form a closed loop for an installed modification. It is prepared by or for the modifier ahead of an installation approval package. The work reads the FHA, the PSSA, the SSA, and the requirements the assessment drove, then tests whether each hazard classification traces to a requirement and each safety requirement traces to verification evidence. You receive a hazard-to-requirement-to-evidence view, a gap assessment where the loop is open, and a closure plan for the safety argument before submittal.
When this review is needed
- A modification introduces a new function or changes an existing one, and its hazard classifications set the assurance levels the rest of the package must meet.
- The FHA, PSSA, and SSA were developed at different phases and the requirement feedback between them was never reconciled.
- The safety assessment assigns development assurance levels that the software and hardware data have to match, and the modifier needs those allocations confirmed.
- A reviewer is expected to sample whether safety requirements were actually verified, and the project wants that loop checked first.
The problem
The safety assessment is the spine of an installation package: it classifies the hazards, allocates the assurance levels, and generates safety requirements that everything else has to satisfy. When the FHA, PSSA, and SSA mature across a long project, the feedback between them drifts. A hazard gets reclassified without the requirement following, or a safety requirement is written but never carried into verification. The assessment reads as complete, yet the loop from hazard to requirement to evidence has a break somewhere in the middle.
What gets reviewed
- FHA hazard classifications checked for consistency with the function and its failure conditions
- PSSA allocations traced into the safety requirements they generate
- SSA results confirmed to demonstrate the safety objectives the PSSA set
- Each safety requirement traced forward to its verification evidence
- Development assurance level allocations reconciled with the software and hardware data
- A closure plan for hazards, requirements, or objectives that do not close the loop
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 in the FHA carries into a safety requirement at the matching severity
- Every safety requirement generated by the PSSA traces to verification evidence in the SSA
- Development assurance levels allocated by the assessment match those in the software and hardware data
- Reclassified hazards propagated into the requirements and the allocations downstream
- Failure conditions and their classifications reconcile between the FHA and the SSA
Evidence normally required
- The functional hazard assessment and its failure condition classifications
- The preliminary system safety assessment and allocated safety requirements
- The system safety assessment and its supporting analyses
- The requirement set showing safety requirements and their verification links
- The development assurance levels allocated to software and hardware
Common discrepancies
- A hazard reclassified in the SSA that the requirement set still reflects at the old severity
- A safety requirement generated in the PSSA with no verification evidence behind it
- A development assurance level allocation that does not match the software or hardware data
- A failure condition present in the FHA but absent from the SSA that should demonstrate it
What is at stake
A safety assessment that does not close undermines every assurance level built on it, because the software and hardware data were scoped to allocations the assessment no longer supports. A hazard classification that shifted without propagating can leave a function under-assured or over-assured, and either finding at review forces a rework of the safety argument that cascades into the lifecycle data allocated beneath it.
How the work runs
Trace the classifications
Confirm each FHA hazard carries into a safety requirement at the matching severity.
Follow requirements to evidence
Trace each PSSA-allocated safety requirement forward to the SSA verification that demonstrates it.
Reconcile the allocations
Check the development assurance levels against the software and hardware data scoped to them.
Plan the closure
Sequence the open points in the loop by the analysis or verification each needs.
What the buyer receives
Who uses the output
- Certification project managers judging whether the safety argument closes end to end
- Engineering leads reconciling allocations with the lifecycle data beneath them
- Compliance staff presenting the hazard-to-evidence trace to the reviewer
How the work fits into the transaction or program
The safety assessment sits above the software and hardware data and sets the assurance levels those streams are scoped to. Confirming its loop closes before the package is assembled protects everything allocated beneath it, so a shifted classification or an unverified safety requirement is caught before it invalidates the lifecycle data built to the old allocation.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both accept ARP4761A analyses and ARP4754B development assurance as means of compliance for the safety assessment, and the analytical structure is common. The classification of failure conditions and the acceptable probability targets are read against the certification basis for this installation, so a safety argument assembled for one authority is checked against the basis the receiving authority actually applies.
Regulatory limits
The work checks the safety assessment for internal closure and traceability to verification. It does not perform the hazard analyses, does not set failure condition classifications, and does not make a compliance finding or grant an approval. The classifications and the compliance determination rest with the applicant and the authority.
What this review does not cover
- Performing the FHA, PSSA, or SSA analyses
- Setting failure condition classifications or probability targets
- Any compliance finding or approval on the safety of the installation
Specific to this review
- A reclassified hazard that never propagates is the most damaging safety finding, because it silently invalidates the assurance level the lifecycle data was scoped to.
- The PSSA-to-SSA link is where the loop most often breaks, since safety requirements are allocated early and verification is demonstrated much later.
- An over-assured function counts as a finding as much as an under-assured one, because either signals the allocation and the data no longer agree.
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.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
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 check the safety assessment before the software and hardware data?
The safety assessment allocates the assurance levels the software and hardware are built to. If the assessment does not close, or a classification shifted, those levels may be wrong and the lifecycle data underneath is scoped to the wrong target. Confirming the loop first protects everything allocated beneath it.
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.