Safety assessment support for TSO authorization

When this review is needed

• The safety assessment is drafted and its results have to be tied back to requirements and verification before submission.
• A design change altered a failure path and the FHA and downstream assessments have to catch up.
• The software or hardware assurance level was driven by the safety assessment and the rationale has to hold.
• Derived safety requirements were produced but never fed into the requirements trace or the verification plan.

The problem

The safety assessment is developed alongside the design but on its own thread, and the two threads drift. A hazard identified in the FHA generates a mitigation requirement that has to land in the design, be traced, and be verified, but the handoffs between the safety process and the engineering process are where results fall through. An assessment can read as complete while the requirements it produced never reached the people who had to implement and verify them.

What gets reviewed

• The functional hazard assessment checked against the article's current design and function
• Preliminary and system safety assessment results traced to derived requirements
• Derived safety requirements confirmed present in the requirements trace
• Verification confirmed for the mitigations the safety assessment relies on
• The assurance-level rationale the safety assessment drives for software and hardware
• Safety results that do not trace to a requirement or a verification identified

What gets validated

• Each identified hazard leads to a mitigation requirement that reached the trace
• The FHA reflects the article's current design, not a superseded failure structure
• Derived safety requirements appear in the requirements set and their verification plan
• The assurance levels the assessment drives match the objectives the data was built to
• Every safety result closes with a requirement and a verification behind it

Evidence normally required

• The FHA, PSSA, and SSA for the article
• The derived safety requirements the assessment produced
• The requirements trace and verification records
• The current design and function the assessment should reflect
• The assurance-level rationale for software and hardware

Common discrepancies

• A derived safety requirement missing from the requirements trace
• An FHA that predates a design change affecting a failure path
• A mitigation the assessment relies on with no verification confirming it
• An assurance level driven by the assessment that the lifecycle data does not meet

What is at stake

A safety result that does not trace to a requirement and a verification leaves a mitigation the article claims but never demonstrated, which is exactly what a reviewer probes. A stale FHA that missed a design change can under-assess a failure path, driving an assurance level that no longer fits and forcing rework once the mismatch is found. Safety gaps found late are among the most disruptive, because they can reopen requirements, design, and verification together.

How the work runs

What the buyer receives

• A gap assessment on the safety case and its links to engineering
• A map from each hazard through its requirements to its verification
• A closure plan for the safety results that do not yet trace

Who uses the output

• Certification leads presenting the safety case to the FAA
• Safety engineers reconciling their results with the requirements trace
• Program managers tracking which safety results still lack closure

How the work fits into the transaction or program

The safety assessment sets the assurance levels the DO-178C and DO-254 data are built to and generates requirements the trace must carry, so it touches nearly every other artifact. This review runs once the assessment is drafted and the trace exists, and its closure plan drives the requirement and verification work the safety results still need.

Jurisdiction-specific considerations

The safety assessment is developed to ARP4761A and ARP4754B as the FAA accepts them for the article, so its process and depth follow FAA-accepted practice. A later program under another authority can reuse the assessment, but the review checks the results against the FAA basis rather than assuming the acceptance transfers.

Regulatory limits

The review checks that safety results trace to requirements and verification and that the assessment reflects the current design. It does not perform the safety assessment, set the assurance level as a regulatory act, or make a finding that the article is safe.

What this review does not cover

• Conducting the FHA, PSSA, or SSA
• Setting the article's assurance levels as a regulatory decision
• Issuing an FAA finding on the safety case

Specific to this review

• The safety and engineering processes run on separate threads, so the handoff of a derived requirement is where results most often fall through.
• A stale FHA is more dangerous than a missing one, because it drives an assurance level off a failure structure the design has already changed.
• Safety gaps are the most disruptive to find late, since a single untraced result can reopen requirements, design, and verification at the same time.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits