DI-SAFT-82085A

Hazard Tracking System (HTS) Data

Specifies the format and content for Hazard Tracking System (HTS) Data used to document and track hazard tracking and Software Level of Rigor information required by MIL-STD-882E(C1).

Approval DateJuly 15, 2025

AMSC NumberF10584

Preparing Activity40 (AFMC/SE)

Project NumberSAFT-2025-009

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.

Supersedes

DI-SAFT-82085

—

Description & Purpose

—

Application & Interrelationship

—

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

Preparation Instructions

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

2FormatThe 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).

3ContentThe HTS shall contain the following information:

3.1Safety Hazard Tracking System Data

3.1.1Unique Hazard IdentifierIdentifier used for positive Closed-Loop Hazard Tracking.

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

3.1.2.1System/subsystem description

3.1.2.2System/subsystem interfacesSystem/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.3System configuration(s)

3.1.2.4System of system interfaces

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

3.1.3.1Relevant Component Identification

3.1.3.2Specific Component Configuration(s) and related Configuration History

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

3.1.3.4Testing Details

3.1.3.5Materials

3.1.3.6Treatments

3.1.3.7Installation

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

3.1.4.1Software architecture description

3.1.4.2The program's definition of what a UnitThe 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.3Unit(s) of software associated with the hazard

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

3.1.4.5Software Versions

3.1.4.6Relevant Control Laws

3.1.5Human (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.1Ergonomic hazardous conditions (user physical characteristics)

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

3.1.6Environment(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.7Hazard DescriptionInformation needed to sufficiently describe the hazard. Typical Topics Include:

3.1.7.1Hazard characterization

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

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

3.1.7.4Hazard effects involving hardware, software, human, environmental

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

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

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

3.1.9.2Assertions and assumptions behind Probability (Per MIL-STD-882E(C1) Table II)include all math in the derivation of quantitative probabilities

3.1.9.3Identify all unknown data associated with the hazard

3.1.9.4Resultant 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.5Unique conditions during a special event

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

3.1.10.1An explanation of each selected hazard control

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

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

3.1.10.4Rejected controls

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

3.1.10.6Projected control implementation plan

3.1.10.7Schedule for each control to be installed throughout fleet

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

3.1.10.9Validation control achieving desired hazard intervention

3.1.11Hazard StatusDescription of the hazard status. Typical Topics Include:

3.1.11.1Progress of hazard control implementation

3.1.11.2Formal acceptance by the Risk Acceptance Authority

3.1.11.3Open/In Work/Closed

3.1.12Related HazardsReferenced to other related hazards.

3.1.13OtherRelated anomalies, incidents, or mishaps.

3.1.13.1Such citations shall not cite Limited Use Mishap Data

3.1.13.2Any 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.3Hazard Point of Contact

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

3.2.1Unit of SoftwareInformation 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.2SwCI/LOR DeterminationThe rationale supporting how the Software Criticality Index (SwCI)/LOR was derived for each Unit of Software. Typical Discussion Includes

3.2.2.1For each unit of software, the Software Control CategoryFor 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.2For each unit of software, the rationale behind determiningFor 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.3MIL-STD-882E(C1) Table V Results for the software unit's SwCI and tier of LOR

3.2.3LOR Activities

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

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

3.2.4LOR Activity Status

3.2.4.1Define the timeline when MIL-STD-882E(C1) Table VI questionsDefine 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.2For each Unit of Software, provide status ofFor each Unit of Software, provide status of MIL-STD-882E(C1) Table VI question for each LOR Activity

3.2.4.3For each LOR Tier's Activity

3.2.4.3.1Annotate what is left to be defined

3.2.4.3.2Annotate Government Program Management (PM) decision to expendAnnotate 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.4For each incomplete (e.g. non-compliant) LOR activity

3.2.4.4.1Annotate specifically what is incomplete with the LOR criteria

3.2.4.4.2Provide partial artifacts if available

3.2.4.4.3Annotate Government PM decision to expend additionalAnnotate 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.

References

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

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer