Field approval, safety assessment
Field-approval safety assessment evidence support
This support readies the safety assessment evidence behind a field-approval installation and confirms the analysis actually closes. It works through the functional hazard assessment, the preliminary and system safety assessments, and the derived safety requirements, then checks that each hazard mitigation traces to a requirement and to verification evidence. A safety engineer runs it before the package goes to the FAA. What comes back is a gap assessment across the assessment chain, a hazard-to-mitigation evidence map, and a plan to close the items that do not yet trace.
When this review is needed
- An installation changes a system's function and the field approval needs a safety assessment to support it.
- The functional hazard assessment exists but the mitigations were never traced to closing evidence.
- Failure classifications drove the software level or DAL, and those classifications need to hold up on review.
- A prior field-approval attempt was returned because the safety case did not close against verification.
The problem
A safety assessment reads as a clean argument on paper long before every hazard actually traces to a mitigation and a verification result. The failure condition classifications set downstream assurance levels, so an assessment that does not close pulls the software and hardware evidence out of alignment with it. A modifier changing an existing system inherits assumptions from the original type design that the new assessment has to either carry forward or replace, and those seams are where a field approval reviewer probes.
What gets reviewed
- The functional hazard assessment and the failure conditions it identifies for the changed function
- The preliminary system safety assessment and the safety requirements it derives
- The system safety assessment and the evidence that each mitigation is met
- Common-cause and independence considerations where the architecture relies on them
- Derived safety requirements traced to design, implementation, and verification
- Assumptions carried from the original type design and their validity for this change
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 in the FHA has a mitigation carried through to the SSA
- Derived safety requirements trace to design and to a verification result that confirms them
- Failure classifications are consistent with the assurance levels assigned to software and hardware
- Independence and common-cause claims are supported rather than asserted
- Assumptions inherited from the original type design still hold for the modified function
Evidence normally required
- The functional hazard assessment for the affected functions
- The preliminary and system safety assessments and their derived requirements
- Common-cause analyses and any fault-tree or dependency evidence
- The verification results that mitigations depend on
- The certification basis and the original type-design assumptions the change touches
Common discrepancies
- A hazard identified in the FHA with no mitigation carried into the SSA
- A failure classification that no longer matches the assurance level assigned downstream
- An independence claim in the architecture that the evidence does not actually support
- A safety requirement with no verification result confirming it is met
What is at stake
A safety case that does not trace end to end gets challenged, and every downstream assurance claim tied to its failure classifications comes into question with it. That can force rework of software or hardware evidence that looked finished, delaying the approval and keeping the modified system on an interim footing until the argument closes.
How the work runs
Map the hazards
List the failure conditions in the FHA and the classification each one carries for the changed function.
Follow the mitigations
Trace each hazard through the PSSA and SSA to the mitigation meant to address it.
Confirm against verification
Check that derived safety requirements reach a verification result and that classifications match the assurance levels assigned.
Close the argument
Sequence the unclosed items and the assumptions needing re-validation for completion before submission.
What the buyer receives
Who uses the output
- Safety and engineering leads deciding which mitigations still need evidence
- Compliance managers assembling the safety case for the field approval
- Maintenance leadership gauging when the modified function can be cleared into service
How the work fits into the transaction or program
The assessment review is the hinge between the safety analysis and every assurance level it drives. It confirms the hazard argument closes before the software and hardware evidence is judged against the classifications the assessment set, so a weak safety case is caught before it undermines otherwise complete lifecycle data.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review checks that the safety assessment traces from hazard to mitigation to verification and reports where it does not. It does not classify failure conditions on the FAA's behalf, accept the safety case, make a compliance finding, or determine airworthiness.
What this review does not cover
- Performing the safety analysis or authoring the FHA, PSSA, or SSA
- Setting or accepting failure condition classifications
- Any approval or airworthiness determination on the modified system
Specific to this review
- Failure condition classifications set the software level and DAL, so an unclosed safety case pulls downstream assurance out of alignment.
- Independence and common-cause claims are where architectures most often assert more than the evidence supports.
- A change to an existing system carries assumptions from the original type design that the new assessment must re-validate, not inherit silently.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
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
Why does the safety assessment matter for our software and hardware evidence?
The failure condition classifications in the assessment set the software level and design assurance level your lifecycle evidence is judged against. If the safety case does not close, those classifications are in doubt, and the software and hardware evidence built on them can be pulled back into question.
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.