JUL2025A01G.pdf

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

DATA ITEM DESCRIPTION

Title: HAZARD TRACKING SYSTEM (HTS) DATA

Number: DI-SAFT-82085A Approved Date: 20250715

AMSC Number: F10584 Limitation: N/A

DTIC Applicable: No GIDEP Applicable: No

Preparing Activity: 40 (AFMC/SE) Project Number: SAFT-2025-009

Applicable Forms: N/A

Use/Relationship: The Hazard Tracking System (HTS) Data will be used to document and track essential information from contractors for accomplishing the tracking system requirements of MIL- STD-882E(C1). This data includes the closed loop hazard tracking requirements in MIL-STD- 882E(C1) paragraph 4.3.1.d and Task 106 as well as the Software Level of Rigor (LOR) Data requirements of paragraph 4.4.3.

This Data Item Description (DID) contains the format, content, and intended use information for the data deliverable resulting from the work tasks described in MIL-STD-882E(C1). This applies to all developmental and sustaining engineering activities for the Department of Defense (DoD) systems, equipment, and facilities. This DID also contains additional data elements required when MIL-STD- 882E(C1) Detailed Requirements Tasks are applied to the contract.

(Copies of this document are available online at https://quicksearch.dla.mil.)

This DID supersedes DI-SAFT-82085

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 HTS database shall be in a format compatible with government office capabilities. Data shall be delivered in one of these formats; (e.g., software tools/applications such as spreadsheets or databases).

3. Content. The HTS shall contain the following information:

3.1 Safety Hazard Tracking System Data

3.1.1 Unique Hazard Identifier: Identifier used for positive Closed-Loop Hazard Tracking.

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

DI-SAFT-82085A

3.1.2 System/Subsystem Description. Information needed to describe the system or subsystem. Typical Topics Include:

3.1.2.1 System/subsystem description.

3.1.2.2 System/subsystem interfaces of interest to included interfaces between subsystems, between hardware and software, between different units of software, with the environment, with the human, and to include Architectural/Facility Enterprises.

3.1.2.3 System configuration(s)

3.1.2.4 System of system interfaces

3.1.3 Hardware. Information needed to properly characterize hardware being cited, if applicable. Typical Topics Include:

3.1.3.1 Relevant Component Identification

3.1.3.2 Specific Component Configuration(s) and related Configuration History

3.1.3.3 Manufacturing Details (forging, milling, casting, additive manufacturing, etc.)

3.1.3.4 Testing Details

3.1.3.5 Materials

3.1.3.6 Treatments

3.1.3.7 Installation

3.1.4 Software. Information needed to properly characterize software being cited, if applicable. Typical Topics Include:

3.1.4.1 Software architecture description

3.1.4.2 The program’s definition of what a Unit of Software is (e.g. Computer Software Configuration Item (CSCI), Computer Software Component (CSC), Computer Software Unit (CSU); this definition is to be used in all documentation required by this DID.

3.1.4.3 Unit(s) of software associated with the hazard.

3.1.4.4 Additional clarification of where within the unit of software relates to the hazard.

3.1.4.5 Software Versions

3.1.4.6 Relevant Control Laws

3.1.5 Human (Consider/Use occupational health data) Information needed to describe how the human is involved in a hazard, if applicable. Typical Topics Include:

3.1.5.1 Ergonomic hazardous conditions (user physical characteristics)

3.1.5.2 Exposure to physical, chemical, radiological, biological hazardous conditions

3.1.6 Environment. (Consider/Use environmental data) Information needed to describe how undesired environment effects (e.g. wind, precipitation, light, etc.) are involved in a hazard, if applicable.

3.1.7 Hazard Description. Information needed to sufficiently describe the hazard. Typical Topics Include:

3.1.7.1 Hazard characterization

3.1.7.2 Modes of operation of interest (normal, emergency, maintenance, text, disposal, etc.)

3.1.7.3 Environmental interfaces (vibration, heat, exposure to corrosive substances, etc.)

3.1.7.4 Hazard effects involving hardware, software, human, environmental

3.1.8 Safety Relationship to Requirements. Those requirements with a relationship to safety. This shall include citations for a system’s safety requirement or requirements associated with hazard controls.

3.1.9 Risk Assessment. Details needed to properly document a hazard. Typical Topics Include:

3.1.9.1 Assertions and assumptions behind Severity (Per MIL-STD-882E(C1) Table I)

3.1.9.2 Assertions and assumptions behind Probability (Per MIL-STD-882E(C1) Table II).

include all math in the derivation of quantitative probabilities

3.1.9.3 Identify all unknown data associated with the hazard.

3.1.9.4 Resultant Risk (Per MIL-STD-882E(C1) Table III) for “Initial Risk”, “Risk As of Today”, “Target Risk”, and/or “Event Risk” (aka Test Event).

3.1.9.5 Unique conditions during a special event

3.1.10 Hazard Controls. Document the hazard controls associated with a hazard. Typical Topics Include:

3.1.10.1 An explanation of each selected hazard control.

3.1.10.2 An association with the selected hazard controls and the System Safety Order of Precedence

3.1.10.3 Reducing Probability (aka Mitigation) or Severity (aka Amelioration)

3.1.10.4 Rejected controls

3.1.10.5 Projected amount of “risk” bought back (e.g. the amount of risk reduction as the result of incorporating hazard controls)

3.1.10.6 Projected control implementation plan

3.1.10.7 Schedule for each control to be installed throughout fleet

3.1.10.8 Verification control implemented into design (verifications of risk reduction)

3.1.10.9 Validation control achieving desired hazard intervention

3.1.11 Hazard Status. Description of the hazard status. Typical Topics Include:

3.1.11.1 Progress of hazard control implementation

3.1.11.2 Formal acceptance by the Risk Acceptance Authority

3.1.11.3 Open/In Work/Closed

3.1.12 Related Hazards. Referenced to other related hazards.

3.1.13 Other. Related anomalies, incidents, or mishaps.

3.1.13.1 Such citations shall not cite Limited Use Mishap Data.

3.1.13.2 Any other items (i.e., studies, analyses, test data, notes or similar data) generated in the performance of the contract with respect to the HTS.

3.1.13.3 Hazard Point of Contact

3.2 Software LOR Data: This data is generated as a result of MIL-STD-882E(C1) paragraph 4.4.

3.2.1 Unit of Software Information needed to properly characterize software being cited.

The program’s definition of what a Unit of Software is (e.g. CSCI, CSC, CSU); this definition is to be used in all documentation required by this DID.

3.2.2 SwCI/LOR Determination. The rationale supporting how the Software Criticality Index (SwCI)/LOR was derived for each Unit of Software. Typical Discussion Includes

3.2.2.1 For each unit of software, the Software Control Category (SCC; MIL-STD-882E(C1) Table IV) and supporting rationale for determining applicable SCC.

3.2.2.2 For each unit of software, the rationale behind determining worst potential Severity (MIL- STD-882E(C1) Table I) for the software unit. Several hazards may involve the same unit of software, the most severe Severity is used.

3.2.2.3 MIL-STD-882E(C1) Table V Results for the software unit’s SwCI and tier of LOR.

3.2.3 LOR Activities:

3.2.3.1 Describe each LOR Activity for each LOR Tier (corresponding to SwCI Tier).

3.2.3.2 Provide LOR artifacts correlated to each LOR activity for each Unit of Software.

3.2.4 LOR Activity Status

3.2.4.1 Define the timeline when MIL-STD-882E(C1) Table VI questions are to be asked.

(e.g. prior to Preliminary Design Review – PDR; prior to Critical Design Review – CDR; prior to formal testing; prior to fielding, periodically during sustainment).

3.2.4.2 For each Unit of Software, provide status of MIL-STD-882E(C1) Table VI question for each LOR Activity

3.2.4.3 For each LOR Tier’s Activity:

3.2.4.3.1 Annotate what is left to be defined.

3.2.4.3.2 Annotate Government Program Management (PM) decision to expend additional resources to define LOR activity or obtain Risk Acceptance Authority’s formal acceptance for the unspecified LOR Tier. If unavailable, highlight the need for a decision to be made.

3.2.4.4 For each incomplete (e.g. non-compliant) LOR activity:

3.2.4.4.1 Annotate specifically what is incomplete with the LOR criteria.

3.2.4.4.2 Provide partial artifacts if available

3.2.4.4.3 Annotate Government PM decision to expend additional resources to define LOR activity or obtain Risk Acceptance Authority’s formal acceptance for the incomplete LOR activity. If unavailable, highlight the need for a decision to be made.

End of DI-SAFT-82085A