Environment, Safety, and Occupational Health (ESOH)

Definitions

MIL-STD 882 (System Safety) defines System Safety (SS) as “The application of engineering and management principles, criteria, and techniques to achieve acceptable risk within the constraints of operational effectiveness and suitability, time, and cost throughout all phases of the system life cycle.” It defines SS Engineering as “An engineering discipline that employs specialized knowledge and skills in applying scientific and engineering principles, criteria, and techniques to identify hazards and then to eliminate the hazards or reduce the associated risks when the hazards cannot be eliminated.”

System Safety in Systems Engineering

SS is an important element of SE that provides a standard, generic method for the identifying, classifying, and mitigating hazards. DoDI 5000.88, Section 3.6.e., requires the program to use the SEP to document a strategy for the SS Engineering program in accordance with MIL-STD-882. MIL-STD-882 reinforces integration of other functional disciplines into SE to improve the consistency of hazard management practices across programs. DoDI 5000.02 requires the establishment of a safety and risk management program to ensure program cost, schedule, and performance objectives are achieved, and to communicate the process for managing program uncertainty and safety risks that must be eliminated or controlled, or can be accepted.

DoD expands the objective and use of the SS methodology to integrate risk management into the overall SE process. MIL-STD-882 defines System Safety Management (SSM) as “All plans and actions taken to identify hazards; assess and mitigate associated risks; and track, control, accept, and document risks encountered in the design, development, test, acquisition, use, and disposal of systems, subsystems, equipment, and infrastructure.” SSM describes general engineering requirements and design criteria for safety risk management during system design and development. It identifies safety risk management requirements, including procedures, for test, operations and support, and disposal. MIL-STD-882 provides a matrix and defines probability and severity criteria to categorize risks. Before exposing people, equipment, or the environment to known system-related hazards, the risks shall be accepted by the appropriate authority as defined in DoDI 5000.02. The system configuration and associated documentation that supports the formal risk acceptance decision shall be provided to the Government for retention through the life of the system.

MIL-STD-882 covers hazards as they apply to systems, products, equipment, and infrastructure, including both hardware and software, throughout design, development, test, production, use, and disposal. Hazards, control measures, and risks as they apply to autonomy, artificial intelligence, and unmanned systems, including autonomous weapon systems, need to be assessed as part of the SS process. The SS Engineering program identifies safety certification such as the Airworthiness Release, Fuze Safety Reviews, Hazard of Electromagnetic Radiation to Ordnance Classification and Certification, Energetic Material Qualification, HC, Ignition Safety Review, Health Hazard Assessment and Joint Weapon Safety reviews and assessments.

Major Capability Acquisition Environment, Safety and Occupational Health

ESOH analyses are an integral, ongoing part of the SE process throughout the life cycle. DoDI 5000.88, Section 3.6.e. requires programs to use the SS methodology in MIL-STD-882 to manage their ESOH considerations as an integral part of the program’s overall SE process. This starts with including ESOH management planning in the SEP to cover technology development, and system development activities and continues throughout the system’s life cycle.

DoD defines ESOH in MIL-STD-882 as “the combination of disciplines that encompass the processes and approaches for addressing laws, regulations, EOs, DoD policies, environmental compliance, and hazards associated with environmental impacts, system safety (e.g., platforms, systems, system-of-systems, weapons, explosives, software, ordnance, combat systems), occupational safety and health, hazardous materials management, and pollution prevention.”

The PM uses the SS methodology for the identification, documentation, and management of environmental, occupational and health hazards and their associated risks during the system's development and sustainment. The PM, with support from the Systems Engineer and SS SMEs, eliminates hazards where possible, and manages environmental, occupational, and health hazards risks where hazards cannot be eliminated.

The PM, Systems Engineer and SS SMEs should also identify and integrate environmental, occupational and health hazards requirements into the SE process including, but not limited to, complying with National Environmental Policty Act (NEPA), EO 12114, and applicable environmental quality requirements, which will require assessing the system's operation and maintenance pollutant emissions, prohibiting or strictly controlling the use of banned or restricted hazardous materials, such as hexavalent chrome and ozone-depleting substances. Results of environmental, occupational and health hazards and concerns are documented in the PESHE and their NEPA/EO 12114 Compliance Schedule. The PESHE consists of the environmental, occupational, and health hazard data, hazardous materials management data, and any additional environmental, occupational and health compliance information required to support analyses at test, training, fielding and disposal sites.

Software System Safety

Software System Safety (SSS) is defined in MIL-STD-882 as “the application of system safety principles to software.” DoDI 5000.88, Section 3.6.e., requires the program to use the SEP to document a strategy for the SS Engineering program including SSS in accordance with MIL-STD-882. The standard provides a structured, yet flexible and tailorable, framework for the assessments of software contribution to system risk. The assessment of risk for software, and consequently software-controlled or software-intensive systems considers the potential risk severity and degree of control the software exercises over the hardware, and dictates the level of rigor (LOR) tasks needed to reduce the risk level. The LOR tasks and analyses specify the depth and breadth of software analysis and verification and validation activities necessary to provide a sufficient level of confidence and safety assurance that a safety significant software function will perform. The SS and SSS hazard analysis processes and the successful execution of LOR tasks are important elements to increase the confidence that the software will perform as specified to software performance requirements, while reducing the number of contributors to hazards that may exist in the system. All software contributions to system risk are documented in the Hazard Tracking System (HTS).

The Joint Services Software Safety Authorities’ “Software System Safety Implementation Process and Tasks Supporting MIL-STD-882” is a concise guide to assist in implementing the SSS information in MIL-STD-882. The Joint Software System Safety Engineering Handbook process descriptions complement MIL-STD-882 for these analyses. Allied Ordnance Publication (AOP) 52, “Guidance on Software Safety Design and Assessment of Munitions Related Computing Systems” provides additional guidance on how to conduct required software analyses.

The Unmanned System Safety Engineering Precepts Guide for DoD Acquisition is intended to support the development and design of safe Unmanned System (UxS), associated safety significant software, support hardware and firmware, and Service safety reviews. The guide is directed toward UxS SS engineers as well as UxS PMs, systems engineers, system designers, and T&E managers. The precepts are intended to be general, to be complemented by systems specific to a program office. The guide is intended to provide the PM with a point of initiation for precepts that can aid the development of an SS Engineering Program. The guide includes a summary of the three types of safety precepts (e.g. Programmatic, Design, and Operational), an analysis of the major UxS safety concerns, and an assessment of the state of the art of AI and autonomous capabilities, which, when integrated properly, can enable the desired performance of UxS autonomy, human-machine interaction, and command and control.

Hazard Tracking System (HTS)

A closed-loop HTS is used to document, track, and maintain hardware and software related hazards and their associated risks data. The HTS includes subcontractor, vendor, and supplier hazard tracking data. The minimum data elements for this task for the tracking system are hazard, system, subsystem, applicability, requirements references, system mode, causal factor, effects, mishap, initial risk, event risk, target risk, control measures, hazard status, verification and validation method, acting person(s), record of risk acceptance(s), and hazard management log. The HTS is maintained throughout the system’s life- cycle.

The following minimum data for each hazard is included in the HTS identification number; identified hazards (including descriptions); associated mishaps (potential mishaps resulting from the hazard); risk assessments (including the initial, target, and event(s) Risk Assessment Codes (RACs) and risk levels); identified risk mitigation measures; selected (and funded) control measures; hazard status (current RAC and risk level based on any control actions that have been implemented, verified, and validated); verification of risk reductions (i.e., status of assessments of mitigation effectiveness); and risk acceptances (records of each risk acceptance decision including the names of the risk acceptance authority and user representative(s); and dates of risk acceptance and user concurrence(s)).

SS in SE Process

Early application of SS Engineering contributes to identification and control of potential safety hazards, safer designs, and reduction in overall life cycle cost and avoids reliance on procedural controls. SS considerations start with including SS management planning in the MSA phase, or equivalent phase, after completion of the AoA and before Milestone A activities and continues throughout the system’s life cycle.

The PM and the Systems Engineer ensure SS is addressed during MSA or equivalent phase by identifying inherent hazard risks and developing criteria to define objectives for the SS engineering program.

The PM and the Systems Engineer ensure SS is addressed during TMRR or equivalent phase by identifying safety constraints to implement into the development of critical and new technologies. This is critical because the program conducts most of its developmental testing and finalizes a significant portion of the system design during TMRR. During TMRR, the SS SME can provide the most cost-effective SS support to the program by identifying and then eliminating or mitigating hazards and ensuring SS compliance during system testing and design development. The Systems Engineer and SS SMEs document the results of their TMRR. Finally, properly integrating SS in SE requires addressing the following areas:

SS System Design Requirements

The Systems Engineer identifies the SS requirements applicable to the system throughout its life cycle from statutes, regulations, policies, guidance, design standards and capability documents. From these requirements, the Systems Engineer should derive SS design requirements and include them in capability documents, technical specifications, solicitations, and contracts.

SS in Program Documents

Together the Systems Engineer and the SS SMEs use the SEP to document the program’s plan to integrate SS into the SE process, incorporating SS as a mandatory design, test, sustainment, and disposal consideration. For Environmental and Occupational Health (EOH) considerations, the Programmatic ESOH Evaluation (PESHE) and the NEPA/EO 12114 Compliance Schedule are used to document the results of the program’s implementation of their EOH planning. This approach segments required EOH information across the SEP, PESHE, and NEPA/EO 12114 Compliance Schedule to avoid duplication and enhance ESOH integration.

The SEP should include the SS management planning information listed in Table 5-8.

Table 5-8. ESOH Information in SEP

Column Heading in Systems Engineering Plan (SEP) Table 4.6-1 Expected Information (provided or attached)
Cognizant PMO Organization Organizational structure for integrating system safety (SS) and environment, safety, and occupational health (ESOH) (or refer to SEP Table 3.4.4-2)
Certification Required SS approvals, endorsements, releases, and the designated high and serious risk acceptance user representative(s)
Documentation SS Management Plan, SS Program Plan, Hazards Analyses, Programmatic ESOH Evaluation (PESHE) and NEPA/EO 12114 Compliance Schedule
Contractual Requirements (CDRL#) SS and environmental and occupational language, SS CDRL items, and ESOH DFARS clauses
Description / Comments Description of how design minimizes SS risks by summarizing how the program has integrated SS considerations into Systems Engineering processes including the method for tracking hazards and SS risks and mitigation plans throughout the life cycle of system

The Systems Engineer and SS SMEs also provide input to other program documentation such as the: AS, TEMP, LCSP, system performance specifications, solicitations, contracts, and capability documents. The repository for SS data and information should include, but not be limited to:

Programs should use the results of the sustainability analysis (see Section 2.2.6 Sustainability Analysis) to inform the hazard analysis.

DoDI 5000.88, Section3.6.e., requires that each program maintain a NEPA/EO 12114 compliance schedule. This schedule includes but is not limited to:

The PM should incorporate the NEPA/EO 12114 Compliance Schedule into the program IMS and IMP.

Because actions occurring during technology development and system development may require NEPA/EO 12114 compliance, the program should identify these compliance requirements early in the SEP. DoDI 5000.88, Section 3.6.e. also requires programs to support other organizations NEPA/EO 12114 analyses involving their systems.

SS Risk Management

The PM is responsible for ensuring the appropriate management level accepts SS risks prior to exposing people, equipment or the environment to those risks.

This means a given SS risk may require multiple risk acceptances as the risk level changes across the life of a system. For example:

For joint programs, the SS risk acceptance authorities reside within the lead DoD Component (unless the MDA approves an alternative) and each participating DoD Component provides an appropriate user representative. Joint programs should identify the specific risk acceptance authority and user representative offices in the PESHE. If a joint program uses a MOA to document risk acceptance authority and user representative offices, they should attach the MOA to the PESHE.

The program documents formal risk acceptances in the System Safety Risk Assessment as part of the program record (e.g., HTS). If a risk level increases for a hazard, a new risk acceptance is required before exposing people, equipment or the environment to the increased risk. The program also participates in system-related mishap investigations to assess contributing hazards, risks and mitigations.

DoDI 5000.88, Section 3.6.e. requires programs to report the status of current high and serious SS risks at program reviews and fielding decisions and the status of all SS risks at technical reviews. The purpose of this reporting is to inform the MDA, PEO, PM and end user about trades being made and SS risks that need to be accepted. Each SS risk report includes the following:

In accordance with MIL-STD-882, a risk is never closed nor is the term “residual” risk used. This enables programs to ensure, as their system changes occur over time; they assess those changes for any potential to alter existing risk levels or to add hazards. This also enables a program to determine the potential for eliminating hazards or reducing their risk levels as the program implements system design or operating and maintenance procedure changes.

Hazardous Materials Management

Hazardous Material (HAZMAT) management is an integral part of the risk management effort within the program’s SE process using this Standard's methodology. When HAZMAT, including any item or substance that, because of its chemical, physical, toxicological, or biological nature, could cause harm to people, equipment, or the environment are designed into the system or used for system operation and maintenance, the PM and Systems Engineer assess and document the risks for each combination of HAZMAT and application. (NOTE: The use of certain HAZMATs in system design can increase life cycle cost and create barriers to Foreign Military Sales.) The Systems Engineer can use the optional Task 108, Hazardous Materials Management Plan, in MIL-STD-882 and/or the AIA National Aerospace Standard (NAS) 411, Hazardous Materials Management Program, as the basis for a program's HAZMAT management. Both Task 108 and NAS 411 require a contractual listing of the HAZMAT, which the program intends to manage. The contractual listing categorizes each listed HAZMAT as Prohibited, Restricted or Tracked. NAS 411-1, Hazardous Material Target List, provides a DoD-AIA agreed-upon baseline listing of HAZMAT for each category to use as the starting point in defining the program's list of HAZMAT. When using either Task 108 or NAS 411, the PM and Systems Engineer should document the following data elements for each listed HAZMAT:

The Systems Engineer manages hexavalent chromium usage in systems to balance the requirements for CPC and the procedures in DFARS (Subpart 223.73 - Minimizing the Use of Hexavalent Chromium). For more information on chemicals/materials of evolving regulatory concern, refer to the DENIX website.

Safety Release for Testing

The PM, in concert with the user and the T&E community, provides safety releases (including formal ESOH risk acceptance in accordance with DoDI 5000.88, Section 3.6.e.), to the developmental and operational testers before any test exposing personnel to ESOH hazards. The safety release addresses each system hazard present during the test and includes formal risk acceptance for each hazard. The program’s safety release is in addition to any test range safety release requirements, but it should support test range analyses required for a range-generated test release. Safety releases should be documented as part of the Program Record.

The PM should provide a transmittal letter to the involved test organization with a detailed listing of the system hazards germane to the test that includes the current risk level and documented risk acceptance along with information on all implemented mitigations.

Safety Confirmation

The PM, in concert with the user and the T&E community, ensures a Safety Confirmation (SC) is provided as a formal document that provides the material developer and the decision maker with the test agency's safety findings and conclusions and that states whether the specified safety requirements have been met. It includes a risk assessment for hazards not adequately controlled, lists technical or operational limitations, and highlights safety problems requiring further testing. The SC is provided for milestone and materiel release decision reviews, fielding, and equipping

Sustainable Procurement Program

In an effort to enhance and sustain mission readiness over the system life cycle, reduce reliance on resources and reduce the DoD footprint, programs should follow the policy and procedures identified in the DoD Sustainable Procurement Program (SPP). SPP benefits include:

PMs should implement the applicable SPP procedures in FAR (Subparts 23.2, 23.4, 23.7 and 23.8) to select materials and products that are energy-efficient, water conserving and environmentally preferable. More information on SPP is available on the DENIX website.

Climate Change

In an effort to continuously adapt current and future DoD operations to address the impacts of climate change, and to maintain an effective and efficient U.S. military, DoDD 4715.21 (para 1.2, 2.1, and 2.4) requires programs to integrate climate change considerations, including life cycle analyses, into acquisitions.

Products and Tasks

Product Tasks
10-9-1: Develop programmatic environmental safety and occupational health evaluation (PESHE)
  1. Identify and evaluate the different ESOH issues related to the program.
  2. Identify any ESOH risks and mitigations for the systems and program.
  3. Develop recommendations for mitigating ESOH risks, and submit to decision maker.
  4. Upon approval, perform cost benefit analysis relative to the ESOH issues/risks in the proposed system design.
  5. Document all issues/risks and approved recommendations in the programmatic environmental safety and occupational health evaluation (PESHE), and submit to the decision maker for approval.
  6. Verify incorporation of the approved PESHE and related planning documents in the program’s systems engineering plan (SEP).
10-9-2: Develop system safety plan / program
  1. Develop a comprehensive system safety plan for the system and the program in accordance with current guidance.
  2. Identify all possible safety risks in the proposed system design.
  3. Perform technical and cost benefit analysis to support developing recommendations for mitigation of safety risks.
  4. Using inputs from the contractor and partner, develop the system safety program, including all safety risks and mitigation plans.
  5. Verify incorporation of system safety program elements into the system safety plan.
  6. Verify incorporation of the system safety plan in the program’s systems engineering plan (SEP).
10-9-3: Develop hazardous materials (HAZMAT) program plan
  1. During the design of the system, identify any and all sources of hazardous materials used or created over the life of the program, including materials used or created in the manufacturing, operation, storage, transportation, maintenance, demilitarization, and decommissioning of the system.
  2. Perform needed technical, cost / benefit, or impact analysis to develop recommendations for risks, mitigations, design changes, and development of the HAZMAT program plan in accordance with current guidance.
  3. Document analyses and recommendations in the HAZMAT program plan.
  4. Verify incorporation of the HAZMAT program plan into the hazard mitigation plan.
  5. Verify incorporation of the HAZMAT program plan and related management documentation in the program’s systems engineering plan (SEP).

Source: AWQI eWorkbook

Resources

Key Terms


Policy and Guidance


DAU Training Courses


DAU Communities of Practice

DAU Media

On this page

  1. Definitions
  2. System Safety
  3. Major Capability Acquisition Environment, Safety and Occupational Health
  4. Software System Safety
  5. Hazardous Tracking System
  6. SS in SE Process
  7. SS System Design Requirements
  8. SS in Program Documents
  9. SS in Risk Management
  10. Hazardous Materials Management
  11. Safety Release for Testing
  12. Safety Confirmation
  13. Sustainable Procurement Program
  14. Climate Change
  15. Resources
Back to top