Safety assessment support for an ETSO authorization

When this review is needed

• The safety assessment has matured and the supplier wants its outputs checked against the design.
• The FHA failure classifications are what set the software and hardware levels the program is building to.
• A design change altered a failure path and the safety assessment may not reflect the new architecture.
• The PSSA drove requirements that need confirming as present in the requirement set and verified.

The problem

The safety assessment is where the article's failure effects are classified, and those classifications set the assurance levels everything else is built to. The work is done early in analysis and then the design moves. A mitigation the PSSA assumed does not get implemented, a failure classification set at concept is overtaken by an architecture change, or a safety requirement the assessment generated never lands in the formal requirement set. The assessment reads as complete on its own terms, but its outputs no longer match the design or the requirements they were supposed to drive.

What gets reviewed

• The functional hazard assessment against the article's functions and failure conditions
• The preliminary and final system safety assessments against the design as built
• Failure classifications and the software and hardware assurance levels they set
• Safety requirements generated by the assessment and their presence in the requirement set
• Mitigations the assessment assumed against their implementation in the design
• Consistency between the safety evidence and the compliance matrix and verification data

What gets validated

• Each identified failure condition carries a classification the assessment justifies
• The software and hardware assurance levels match the failure classifications set
• Safety requirements from the PSSA appear in the formal requirement set
• Mitigations the assessment relied on are implemented in the design as built
• The final safety assessment reflects the current architecture, not an earlier one

Evidence normally required

• The FHA, PSSA, and SSA at their current revisions
• The article's functional description and failure-condition definitions
• The design description and the architecture as built
• The requirement set the safety assessment fed into
• The assigned software and hardware assurance levels

Common discrepancies

• A failure classification overtaken by a later architecture change
• Safety requirements generated in the PSSA that never reached the formal set
• Mitigations the assessment assumed but the design did not implement
• Assurance levels that no longer match the current failure classifications

What is at stake

If the safety assessment and the design disagree, the assurance levels the program committed to may be wrong, which means the software and hardware effort could be built to the wrong level in either direction. A classification that turns out to be understated forces a level increase late, cascading into the DO-178C and DO-254 programs, while safety requirements missing from the set leave real mitigations unverified.

How the work runs

What the buyer receives

• A gap assessment of breaks between the safety assessment and the design
• An evidence map from each failure condition to its requirement and assurance level
• A closure plan for the safety requirements and classifications needing alignment

Who uses the output

• Certification leads confirming the safety case is consistent before submittal
• Compliance managers reconciling the safety evidence to the matrix
• Safety and systems engineers realigning the assessment to the design

How the work fits into the transaction or program

The safety assessment sits upstream of nearly everything else in the package, because its classifications set the assurance levels the software, hardware, and verification programs are built to. Confirming its outputs still match the design and reached the requirement set means the levels the rest of the program committed to are correct, rather than discovering after the fact that the foundation shifted.

Jurisdiction-specific considerations

EASA expects the safety assessment for an ETSO article to follow recognized guidance such as ARP4761A and to feed the development assurance under ARP4754B consistently. The review reads the assessment against that expectation, so the failure classifications and the levels they drive hold under the guidance EASA will apply rather than an informal reading.

Regulatory limits

The review evaluates the supplier's safety assessment evidence. It does not perform the safety analysis, accept it on EASA's behalf, or determine that the article is acceptably safe in the authority's judgment. Those determinations remain with EASA and the applicant.

What this review does not cover

• Performing the FHA, PSSA, or SSA analysis
• Accepting the safety assessment on the authority's behalf
• Setting the article's failure-condition classifications

Specific to this review

• The FHA classifications set the assurance levels the entire software and hardware program is built to, so an error in the assessment propagates into every downstream data set.
• Safety requirements are generated inside the assessment and can fail to reach the formal requirement set, leaving an assumed mitigation unverified.
• A late architecture change can invalidate a failure classification without anyone reopening the assessment, so the SSA is read against the design as built, not as analyzed.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits