DI-SAFT-80101D
System Safety Hazard Analysis Report (SSHAR)
The System Safety Hazard Analysis Report (SSHAR) is used to systematically identify and evaluate hazards, both real and potential, for their elimination or control.
Approval DateJuly 15, 2025
AMSC NumberF10579
Preparing Activity40 (AFMC/SE)
Project NumberSAFT-2025-001
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Related
DI-SAFT-80102DI-SAFT-80105DI-SAFT-80106DI-SAFT-82085
Application & Interrelationship
—
Use & Relationship
The System Safety Hazard Analysis Report (SSHAR) is used to systematically identify and evaluate hazards, both real and potential, for their elimination or control. The SSHAR documents these hazard analyses.
a. This Data Item Description (DID) contains the content and format preparation instructions for the data product generated by the specific and discrete task requirement as delineated in the contract.
b. This DID is related to DI-SAFT-80102, Safety Assessment Report (SAR); DI-SAFT-80105, System Safety Program Progress Report (SSPPR); DI-SAFT-80106, Health Hazard Assessment Report (HHAR), and DI-SAFT-82085, Hazard Tracking System (HTS) Data.
(Copies of the DIDs are available online at https://quicksearch.dla.mil.)
c. This DID supersedes DI-SAFT-80101C.
Preparation Instructions
1Reference documents.The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.
2Format.The SSHAR shall be in the contractor's format.
3Content.The SSHAR shall contain the following:
3.1System description.This shall include summary descriptions of the physical and functional characteristics of the system, its software and its components.
3.1.1Reference to more detailed system, software and component descriptions, including specifications and detailed review documentation shall be supplied when such documentation is available.
3.1.2The capabilities, limitations and interdependence of these components and software shall be expressed in terms relevant to safety.
3.1.3The system, software and components shall be addressed in relation to its mission and its operational environment.
3.1.4As applicable, system block diagrams, functional flow diagrams, sketches, schematics, photos, or charts may be used to clarify system descriptions.
3.1.5Software and its role(s) shall be included in this description.This shall include a brief overview of the software architecture and its roles, emphasizing safety critical elements within the system.
3.1.6A brief overview of how the program defines units of software.
3.1.7The means the program uses to identify where in the software the safety discussion relates to.
3.1.8A brief description of the software environment and which higher order language it is written in.
3.2Data.This shall include summaries of data used to determine the safety aspects of design features.
3.3Hazard analysis results.This shall include a summary or a total listing of the results of hazard analysis. The following are the content and format requirements:
3.3.1A summary of the results.
3.3.2A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include the following information:
3.3.2.1System/subsystem/unit.The particular part of the system that this analysis is concerned with. For example, if this item(s) applies to a radar system modulator, use "modulator." If there are several modulators in the system, be sure to clearly specify which one the analysis pertains to.
3.3.2.2Component(s) failure mode(s) and software faults/defects.All component failure modes and software faults/defects which can result in a hazard. Failure modes generally answer the question of "how" it fails.
3.3.2.3Subsystem failure mode(s).The subsystem failure mode descriptions for the System Hazard Analysis (SHA) are similar to the component and software faults/defects descriptions provided in the SubSystem Hazard Analysis (SSHA). However, emphasis is now placed on failure affecting interfacing subsystem operations.
3.3.2.4System component/software and associated phase.
3.3.2.4.1The particular phase/component and software that the analysis is concerned with.
3.3.2.4.2This could be a system, subsystem, component, software, system of systems interface, operating/maintenance procedure or environmental condition.
3.3.2.4.3For a given safety issue, references to software shall include the unit of software as well as other means to identify where within the unit of software the safety interest resides.
3.3.2.4.4System event(s) phase.The configuration of phase of the mission the system is in when the hazard is encountered, for example, during maintenance, during mission phase, during pre-mission phase, full power applied, etc., or it could be encountered in all system events.
3.3.2.4.5System operation description.A description of what is normally expected to occur as the result of operating the component/software/subsystem or performing the operating/maintenance action.
3.3.2.4.6Hazard description.
3.3.2.4.6.1A brief description of the hazard of hazardous material, for example, "Radiation leakage from radar set waveguide."
3.3.2.4.6.2A complete description of the potential/actual hazards inherent in the item being analyzed, or resulting from normal actions or equipment failure, or handling of hazardous materials.
3.3.2.4.7Hazard identification/indication.A description of operator/crew indications which include all means of identifying the hazard to operational/maintenance personnel.
3.3.2.4.8Effect of hazard.The detrimental effects which could be inflicted on the subsystem, system, other equipment, facilities or personnel, resulting from this hazard. Possible upstream and downstream effects shall also be described.
3.3.2.4.9Risk assessment.A risk assessment for each hazard (classification of severity and probability of occurrence should be defined or referenced IAW MIL-STD-882E(C1) or its latest publication). This is the assessment of the risk prior to taking any action to eliminate or control the hazard. Quantitative risk assessment is preferred whenever relevant data resource is available.
3.3.2.4.10Recommended action.The recommended action(s) required to eliminate or control the hazard using the system safety design order of precedence specified in paragraph 4.3.4 of MIL-STD-882E(C1). Sufficient technical detail is required to permit the design engineers and the customer to adequately develop and assess design criteria resulting from the analysis. Include alternative designs and life cycle cost impact where appropriate.
3.3.2.4.11Effect of recommended action.The effect of the recommended action on the assigned risk assessment. This is the risk assessment after taking action to eliminate or control each hazard. If the recommended action will result in cost/schedule/performance penalties to the extent that the contractor requires government approval prior to incorporation, then these considerations shall be addressed.
3.3.2.4.12Remarks.Any information relating to the hazard not covered in other blocks, for example, applicable documents, previous failure data on similar systems, or administrative directions.
3.3.2.4.13Status.The status of actions to implement the recommended, or other, hazard controls. The status shall include not only an indication of "open" or "closed," but also reference to the drawing(s), specification(s), procedure(s), etc., that support closure of the particular hazard.
3.3.2.4.14Caution and warning notes.A complete list of warnings, cautions, and procedures required in operating and maintenance manuals and for training courses.
3.4Hazard analysis methods and techniques.Provide a description of each method and technique used in conduct of the analysis. Include a description of assumptions made for each analysis and the qualitative or quantitative data used.
Schema v3.0Community-maintained · Verify against ASSIST