JUL2025A01F.pdf

DATA ITEM DESCRIPTION

Title: SYSTEM SAFETY HAZARD ANALYSIS REPORT (SSHAR)

Number: DI-SAFT-80101D Approved Date: 20250715

AMSC Number: F10579 Limitation: N/A

DTIC Applicable: No GIDEP Applicable: No

Preparing Activity: 40 (AFMC/SE) PROJECT Number: SAFT-2025-001

Applicable Forms: N/A

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.

Requirements:

1.Reference 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.

2.Format. The SSHAR shall be in the contractor’s format.

3.Content. The SSHAR shall contain the following:

3.1 System description. This shall include summary descriptions of the physical and functional characteristics of the system, its software and its components.

Source: http://assist.dla.mil -- Downloaded: 2025-08-29T14:29Z Check the source to verify that this is the current version before use.

DI-SAFT-80101D

3.1.1. Reference to more detailed system, software and component descriptions, including specifications and detailed review documentation shall be supplied when such documentation is available.

3.1.2. The capabilities, limitations and interdependence of these components and software shall be expressed in terms relevant to safety.

3.1.3. The system, software and components shall be addressed in relation to its mission and its operational environment.

3.1.4. As applicable, system block diagrams, functional flow diagrams, sketches, schematics, photos, or charts may be used to clarify system descriptions.

3.1.5. Software 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.6. A brief overview of how the program defines units of software.

3.1.7. The means the program uses to identify where in the software the safety discussion relates to.

3.1.8. A brief description of the software environment and which higher order language it is written in.

3.2 Data. This shall include summaries of data used to determine the safety aspects of design features.

3.3 Hazard 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.1. A summary of the results.

3.3.2. A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include the following information:

3.3.2.1. System/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.2. Component(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.3. Subsystem 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.4. System component/software and associated phase.

3.3.2.4.1 The particular phase/component and software that the analysis is concerned with.

3.3.2.4.2 This could be a system, subsystem, component, software, system of systems interface, operating/maintenance procedure or environmental condition.

3.3.2.4.3 For 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.4 System 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.5. System 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.6. Hazard description.

3.3.2.4.6.1. A brief description of the hazard of hazardous material, for example, “Radiation leakage from radar set waveguide.”

3.3.2.4.6.2. A 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.7. Hazard identification/indication. A description of operator/crew indications which include all means of identifying the hazard to operational/maintenance personnel.

3.3.2.4.8. Effect 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.9. Risk 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.10. Recommended 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.11. Effect 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.12. Remarks. 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.13. Status. 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.14 Caution and warning notes. A complete list of warnings, cautions, and procedures required in operating and maintenance manuals and for training courses.

3.4 Hazard 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.

End of DI-SAFT-80101D