4.3.18.9. Environment Safety and Occupational Health

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.3.18.9. Environment, Safety, and Occupational Health

4.3.18.9. Environment, Safety, and Occupational Health

Environment, Safety, and Occupational Health (ESOH) analyses are an integral, ongoing part of the systems engineering (SE) process throughout the life cycle. The benefits of early integration of ESOH considerations include:

• Mitigation of program cost and schedule risks from actions that cause damage to people, equipment, or the environment
• Reduction of Operations and Support and disposal costs
• Provision of a safe, suitable, supportable, and sustainable capability able to operate world-wide

Throughout each acquisition phase, programs conduct the ESOH analyses to:

• Identify and mitigate potential risks to the system and its associated personnel
• Manage ESOH design considerations from the beginning of the SE effort
• Plan for compliance with the National Environmental Policy Act (NEPA) and Executive Order (EO) 12114, Environmental Effects Abroad of Major Federal Actions
• Ensure compliance with statutory ESOH requirements

Efforts to identify and analyze hazards, and mitigate ESOH risks provide information needed for informed design decisions and development of ESOH-related documentation for milestone decisions.

DoD defines ESOH in MIL-STD-882E, DoD Standard Practice for System Safety 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."

ESOH System Design Requirements

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

ESOH in Program Documents

The Acquisition Program Office ESOH-specific documents are the Programmatic ESOH Evaluation (PESHE) and the NEPA/EO 12114 Compliance Schedule. The Systems Engineering Plan (SEP) contains the ESOH management planning information. The SEP, PESHE, and NEPA/EO 12114 Compliance Schedule provide inputs to program documentation that include, but are not limited to: Technology Development Strategy (TDS), Test and Evaluation Strategy (TES), Test and Evaluation Master Plan (TEMP), Life-Cycle Sustainment Plan (LCSP), Corrosion Prevention and Control Plan (CPCP), system specifications, solicitations, and contracts; and capability documents.

The SEP contains ESOH design considerations as an integral part of the requirements analysis process, including trade study criteria. ESOH design considerations are particularly important for Milestone A to ensure SE addresses ESOH during the Technology Development (TD) phase, which includes a significant amount of the design development, testing, and the Preliminary Design Review. SEP Table 4.6-1 includes the information listed in Table 4.3.18.9.T1. Additional ESOH details are provided in SEP Sections 3.4 and 3.6; Tables 2.2-1, 3.4.4-1, 3.4.4-2, and 4.4-1; and Figure 3.4.1-1.

Table 4.3.18.9.T1. ESOH Information in SEP

The PESHE documents the ESOH design consideration data produced by executing the ESOH planning described in the SEP. The PESHE includes, but is not limited to:

• ESOH Risk Matrices (for hardware and software) used by the program with definitions for severity categories, probability levels, risk levels, and risk acceptance and user representative concurrence authorities.
• The following data for each hazard: Hazard Tracking System (HTS) identification number, hazard description, potential mishap, initial Risk Assessment Code (RAC) and risk level, mitigation measure(s) and funding status, target RAC and risk level, current RAC and risk level, and risk acceptance and user concurrence status (NOTE: providing an electronic copy of the current data from the HTS would satisfy this requirement).
• The following data for each hazardous material, hazardous waste, and pollutant associated with the system: the specific uses, locations, quantities, and plans for their minimization and/or safe disposal (NOTE: providing an electronic copy of the current data from either the HTS (if it includes this information) or the hazardous materials management data would satisfy this requirement).
• Environmental impact information not included in the HTS or hazardous materials tracking system needed to support installation and range analyses.

NOTE: The results of the sustainability analysis (see DAG section 4.3.19.2. Sustainability Analysis) should be used to inform the hazard analysis.

DoDI 5000.02, Enclosure 12 requires that each program maintain a NEPA/EO 12114 compliance schedule. This schedule includes, but is not limited to:

• Each proposed action (e.g., testing or fielding)
• Proponent (as defined in DoDI 4715.9) for each action
• Anticipated start date for each action at each specific location
• Anticipated NEPA/EO 12114 document type
• Anticipated start and completion dates for each document
• The document approval authority

Because actions occurring during the TD phase may require NEPA/EO 12114 compliance, the program should develop a TD Compliance Schedule for inclusion in the SEP. DoDI 5000.02, Enclosure12 also requires programs to support other organizations’ NEPA/EO 12114 analyses involving their systems.

ESOH Activities by Phase

Table 4.3.18.9.T2. aligns typical ESOH activities by phase.

Table 4.3.18.9.T2. ESOH Activities by Phase

ESOH Risk Management

The Systems Engineer uses the MIL-STD-882E process to identify and assess hazards (to include software safety), eliminate hazards where possible, and manage ESOH risks where hazards cannot be eliminated. MIL-STD-882E provides a matrix and defines probability and severity criteria to categorize ESOH risks. Prior to exposing people, equipment, or the environment to known system-related hazards, the Systems Engineer ensures ESOH risks are formally accepted, which includes formal concurrence on high and serious risks by the designated user representative as defined in MIL-STD-882E (or by each participating Service user representative in a Joint program). DoDI 5000.02 identifies the appropriate management level authorized to accept ESOH risks.

For Joint programs, the Component Acquisition Executive of the Lead Executive Component should be the acceptance authority for high-level risks. The program documents formal risk acceptances as part of the program record (e.g., Hazard Tracking System (HTS)). If a risk level increases for a hazard, a new risk acceptance is required prior to 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.02, Enclosure 12 requires programs to report the status of current high and serious ESOH risks at program reviews and fielding decisions and the status of all ESOH risks at technical reviews. The purpose of this reporting is to inform the Milestone Decision Authority (MDA), Program Executive Office (PEO), Program Manager, and end user about trades being made and ESOH risks that need to be accepted. Each ESOH risk report includes the following: the hazard, potential mishap, initial Risk Assessment Code (RAC) and risk level, mitigation measure(s) and funding status, target RAC and risk level, current RAC and risk level, and risk acceptance / user representative concurrence status.

Hazardous Materials (HAZMAT) Management

When Hazardous Materials (HAZMAT) and chemicals/materials of evolving regulatory concern are designed into the system or used for system operation and maintenance, the Systems Engineer assesses and documents the ESOH risks for each combination of HAZMAT and application. The Systems Engineer also documents:

• The locations, quantities, and usage of each HAZMAT
• Safe demilitarization and disposal requirements
• Energetic qualification information, as applicable
• Reasonably anticipated quantities of hazardous waste generated during normal operation and maintenance
• Hazardous emissions/discharges including those anticipated in emergency situations
• Special training, handling, and storage requirements

The Systems Engineer manages hexavalent chromium usage in systems to balance the requirements for corrosion control and prevention 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 Program Manager, in concert with the user and the T&E community, provides safety releases (to include formal ESOH risk acceptance in accordance with DoDI 5000.02, Enclosure 12, Section 6), to the developmental and operational testers before any test using personnel. The safety release addresses each system hazard present during the test and include 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. The program documents safety releases as part of the Program Record.

The Program Manager 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.

Green Procurement Program (GPP)

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

• Reducing resource consumption
• Ensuring availability of chemicals and materials
• Reducing waste generation
• Contributing to regulatory compliance

Program Managers should implement the applicable GPP procedures in Federal Acquisition Regulation (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 GPP is available on the DENIX website.

Key Resources

• Acquisition Community Connection/ESOH
• Defense Acquisition University Continuous Learning Modules “CLE 009 -- ESOH in Systems Engineering” and “CLR 030 – ESOH in JCIDS”
• Defense Federal Acquisition Regulation Supplement (DFARS)
• Federal Acquisition Regulation (FAR)
• Joint Software System Safety Engineering Handbook, August 27, 2010
• MIL-STD-882E with 25 optional Tasks

Top of page