7.4.3.2 Incorporate Safety Devices.
If system safety hazards to the public cannot be eliminated through design selection or operational decisions, then system safety risks to the public should be reduced using active or passive safety devices. An example of an active safety device would be utilization of a computing system for shutting down a rocket engine when sensors detect thrust chamber temperatures outside of operational parameters. Examples of passive safety devices include burst disks in pressure systems, spring-loaded pressure relief valves, and break wires between stages. Provisions should be made for periodic functional checks of safety devices, where appropriate.
7.4.3.3 Provide Warning Devices.
When neither design nor safety devices eliminate or adequately reduce the risk of identified system safety hazards to the public, devices should be used to detect a hazardous condition and produce adequate warning.
Warning signals and their application should be designed into the system to minimize the likelihood of inappropriate human reaction and response.
A warning indicator on a flight controller console is an example of a warning device.
7.4.3.4 Develop and Implement Procedures and Training.
Procedures and training are generally used to supplement other mitigation measures. When it is not feasible to eliminate or adequately reduce the risk of identified system safety hazards to the public through design selection or specific safety and warning devices, procedures and training should be developed and implemented. Specific procedural and training mitigation measures that may be utilized include:
Conducting dress rehearsals to ensure crew readiness under nominal and non-nominal flight conditions.
Creating and using current and consistent checklists that ensure safe conduct of flight operations during nominal and non-nominal flights.
Consolidating flight rules, procedures, checklists, contingency plans, and emergency plans in a safety directive, notebook, or other compilation.
Establishing communication protocols, including defined radio communications terminology and a common intercom channel for communications.
Conducting flight readiness reviews.
7.5 Validation and Verification.
The reduction of system safety hazards to the public via risk mitigations applied at various levels (component, subsystem, system, or mission) must be validated and verified as required by § 450.109(b)(5).
7.5.1 Validation of Risk Mitigations and Verification Methods.
Per § 450.109(b)(5), validation evidence must be documented. It must demonstrate that the risk elimination and mitigation measures achieve the risk level specified by § 450.109(b)(3). This documented evidence (e.g., V&V Tracking Log) must be provided to the FAA in accordance with 450.109(f)(1). Validation determines whether the implemented mitigation measures and their respective verification methods are sound. Thus, the validation effort ensures that each mitigation and verification is unambiguous, correct, complete, and consistent. In addition, the validation process evaluates that each mitigation measure and respective verification is well understood and operationally and technically feasible.
7.5.2 Verifying Risk Mitigations.
Verification is the process of identifying and producing verifiable and measurable evidence for ensuring that the respective mitigation measures adequately support the documented reduction of system safety risk to the public. Where possible, the FAA expects verification of mitigation measures to utilize existing industry standards.
Essential information for verification includes:
Identification of specific method(s) used to verify the mitigation measure;
Identification of specific evidence to be produced; and Indication of closure based on successful completion of specified method with production of adequate, verifiable, and measurable evidence.
7.5.2.1 Verification Artifacts.
Per § 450.109(b)(5), verification evidence must be documented and it must demonstrate that the risk elimination and mitigation measures achieve the risk level specified by § 450.109(b)(3). This documented evidence, which can include design analysis, test data, and inspection reports, must be provided to the FAA in accordance with 450.109(f)(1).
Ideally, all mitigation measures should be validated and verified by the time of application submittal. The FAA recognizes that applicants may not have the ability to verify all mitigations prior to submission of an application. In those instances, an acceptable verification closure strategy should be documented with expected completion dates (which must be closed prior to licensed operation pursuant to any relevant terms and conditions of the license). This strategy should be provided to the FAA with adequate time to review the closure status of verification evidence prior to the initiation of the applicable licensed activity.
7.5.2.2 Verification Traceability.
Traceability ensures proper application of verifications for § 450.109(b)(5) and should be demonstrated from:
1. Subsystem and component functional failures to their causes to respective mitigations to adequate verifications;
2. Subsystem and component functional failures to respective system safety hazards to the public at the system and mission level;
3. Subsystem and component level risk assessment to system and mission level risk assessment; and
4. System safety hazards to the public at the system and mission level to their respective mitigations to adequate verifications.
7.5.2.3 Verification Methods.
The FAA encourages discussion on proposed verification methods early in the licensing process. Four acceptable methods of verifying mitigation measures, in accordance with § 450.109(b)(5), include:
Analysis – Technical or mathematical evaluation, mathematical models, simulations, algorithms, and circuit diagrams.
Component, subsystem, or system test – Actual operation to evaluate performance of system elements during ambient conditions or in operational environments at or above expected levels to measure safety margins. These tests include functional tests and environmental tests.
Demonstration – Actual operation of the system or subsystem under specified scenarios, often used to verify reliability, transportability, maintainability, serviceability, and human engineering factors.
Inspection – Physical examination of hardware, software code, or documentation to verify compliance of the feature with predetermined criteria.
7.5.3 Iterative Approach of Validation and Verification.
The validation and verification (V&V) process is a comprehensive, closed-looped, iterative process to be used in all phases of the lifecycle of a launch or reentry system.
Any mitigation that fails V&V cannot be relied on for elimination or reduction of system safety risks to the public.
7.6 Identifying New Hazards and Updating the Flight Hazard Analysis.
In accordance with § 450.109(c), criteria and techniques must be established and documented for identifying new hazards and updating a flight hazard analysis throughout the lifecycle of the launch or reentry system. In accordance with § 450.109(e), a process must be defined and implemented for continually updating the flight hazard analysis and system safety risk assessment to reflect knowledge gained during the lifecycle of the launch or reentry system.
7.6.1 Updates from Lifecycle Data.
Foreseeably, data gained during design, manufacture, test and operation, including the discovery of anomalies and faults, usually impacts a flight hazard analysis. Necessary data should be identified, and approaches should be implemented, to detect anomalies and failures in order to improve the flight hazard analysis. Additionally, information gained during assembly and operation of components, subsystems, and next-level systems contributes to the further understanding of the overall system and mission and may lead to additional updates to the flight hazard analysis. A process should be implemented to update the flight hazard analysis and residual system safety risk assessment to reflect knowledge gained during the lifecycle of the integrated system and mission.
7.6.2 Accuracy via the System Safety Program.
In accordance with § 450.103(b) and (d) and explained more fully in AC 450.103-1, System Safety Program, methods to detect flight anomalies and system failures and processes for evaluating post-flight data must be defined in the documented system safety program. The flight hazard analysis should adequately reflect the data gained from these methods and processes to ensure accuracy throughout the lifecycle of a launch or reentry system.
7.6.3 Completeness Prior to Flight.
In accordance with § 450.109(d), the flight hazard analysis must be complete and all system safety hazards to the public must be mitigated to acceptable levels, specifically that of § 450.109(b)(3), for every launch or reentry.
7.7 Application Requirements.
In accordance with § 450.109(f), an application must include: (1) the flight hazard analysis data produced in accordance with § 450.109(b)(1) through (5), including the verification evidence for the risk elimination and mitigation measures; and (2) the criteria and techniques for identifying new hazards throughout the lifecycle of the launch or reentry system, as required by § 450.109(c).
Appendix A A-1 Appendix A. System Safety Template for § 450.109 Flight Hazard Analysis.
Table A-1 conveys the types of data that should be provided by an acceptable system safety analysis, including a method for traceability between all aspects of system safety hazards to the public. It is intended as a guide to show what information should be provided within a flight hazard analysis. It also shows how logical tracking for each item can be used to show the relationships between the different pieces of information.
A hazard analysis format conveying the information of Table A-1, such as similar tables or traditional worksheets, should be utilized.
TABLE A-1. System Safety Template for § 450.109 Flight Hazard Analysis
Subsystem and Component Level
System and Mission Level1 Subsystem(s) Component(s) / Item(s) Functional Failure ID(s) Failure Description and End Effect Possible Cause(s) Risk Before Mitigation Measures Risk Elimination / Mitigation Measures Risk After Mitigation Measures Verification Evidence Hazard to Public1 Risk Elimination / Mitigation Measures1 Risk After Mitigation Measures1 Verification Evidence1
L S R L S R L S R
Top-Level System [TBD] Next-Level System [TBD] Avionics Main Computer TBD Main computer [Function TBD] during [Mission Phase TBD] fails [Failure TBD], possibly resulting in loss of vehicle control, break-up, or [End Effect TBD] C1 Board Failure
C2 Electro-Static Discharge (ESD)
C3 Foreign Object Debris (FOD)
C4, and so on…
Initial or no data TBD TBD C1.M1 – Specific to mitigation of board failure (design, test, manufacturing process, etc.)
C1.M2 – Specific to mitigation of C1 C1.M3, and so on… TBD TBD TBD C1.M1.V1 – Documented evidence specific to performed C1.M1 mitigation C1.M1.V2, and so on… C1.M2.V1, and so on… C1.M3.V1, and so on… H1 Off-nominal trajectory
H2 Abort Debris
H3 Reentry Debris
H4, and so on… H1.M1 - Specific to mitigation of H1 [Flight Safety System (FSS), operational restrictions, clear areas, etc…] H1.M2, and so on… TBD TBD TBD H1.M1.V1 – Documented evidence specific to H1.M1 mitigation H1.M1.V2, and so on… H1.M2.V1, and so on… C2.M1 – Specific to mitigation of ESD (design, test, manufacturing process, etc.)
C2.M2 - Specific to mitigation of C2 C2.M3, and so on… C2.M1.V1 – Documented evidence specific to performed C2.M1 mitigation C2.M1.V2, and so on… C2.M2.V1, and so on… C2.M3.V1, and so on… H2.M1 - Specific to mitigation of H2 [deorbit criteria, contingencies, established clear areas for NOTAM and NOTMAR, etc…] H2.M2, and so on… H2.M1.V1 – Documented evidence specific to H2.M1 mitigation H2.M1.V2, and so on… H2.M2.V1, and so on…
C3.M1 – Specific to mitigation of FOD (design, test, manufacturing process, etc.)
C3.M2 - Specific to mitigation of C3 C3.M3, and so on… C3.M1.V1 – Documented evidence specific to performed C3.M1 mitigation C3.M1.V2, and so on… C3.M2.V1, and so on… C3.M3.V1, and so on… H3.M1 - Specific to mitigation of H3 [abort criteria, mission rules, contingencies, established clear areas for NOTAM and NOTMAR, etc…] H3.M2, and so on… H3.M1.V1 – Documented evidence specific to H3.M1 mitigation H3.M1.V2, and so on… H3.M2.V1, and so on… Note:
1 - “System and Mission Level” may be captured as shown or in a separate table or spreadsheet with traceability to “Subsystem and Component Level” 2 - “C1.M1.V1” is only an example; the key is to demonstrate traceability by a suitable method.
3 - L = Likelihood; S = Severity; R = Risk 4 - Typically within system safety: Likelihood (L) = Probability (P); Severity (S) = Consequence (C); L x S = R
OMB Control Number: 2120-0746 (Expiration Date: 08/31/2023)
FAA Form 1320-73 (06-2020)
Advisory Circular Feedback
If you find an error in this AC, have recommendations for improving it, or have suggestions for new items/subjects to be added, you may let us know by (1) emailing this form to ASTApplications@faa.gov, or (2) faxing it to (202) 267-5450.
Subject: (insert AC title/number here) Date: Click here to enter text.
Please check all appropriate line items:
☐ An error (procedural or typographical) has been noted in paragraph Click here to enter text.
on page Click here to enter text..
☐ Recommend paragraph Click here to enter text. on page Click here to enter text. be changed as follows:
Click here to enter text.
☐ In a future change to this AC, please cover the following subject:
(Briefly describe what you want added.)
Click here to enter text.
☐ Other comments:
Click here to enter text.
☐ I would like to discuss the above. Please contact me.
Submitted by: Date:
Paperwork Reduction Act Burden Statement: A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a currently valid OMB Control Number. The OMB Control Number for this information collection is 2120-0746. Public reporting for this collection of information is estimated to be approximately 5 minutes per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. All responses to this collection of information are voluntary to obtain or retain benefits per 14 CFR 77. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to: Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.