Environment, Safety, and Occupational Health (ESOH), and Exercise

Environment, Safety, and Occupational Health (ESOH), and Exercise The following continuous learning modules are relevant to this lesson: - CLE039 Environmental Issues in T&E - CLE009 ESOH in Systems Engineering - CLR030 ESOH in JCIDS ESOH Community of Practice: https://acc.dau.mil/esoh

ESOH Implications for T&E Planning ESOH risk mgmt. is part of the risk mgmt. process Potential risks include: Impacts & adverse effects from routine testing, test failures, and mishaps Scope of risks includes: HAZMAT use & hazardous waste generation Safety (including explosives safety, ionizing & nonionizing radiation) Human health (chemical, physical, biological, ergonomic, etc.) Environmental & occupational noise Impacts to the environment (air, water, soil, flora, fauna) The T&E community must comply with all ESOH statutory & regulatory requirements

ESOH Risk Management For Environmental, Safety, and Occupational Health (ESOH) risks, the PM shall: Integrate ESOH risk management into the Systems Engineering process Eliminate ESOH hazards where possible (manage risks that can t be eliminated) Use MIL-STD 882 methodology Must accept residual risk, prior to exposing people, equipment, or the environment Residual risk acceptance authorities: High risks CAE Serious risks PEO Medium and low risks PM DoDI 5000.02, Encl 3

ESOH System Safety Process Element 1: Document the System Safety Approach Element 5: Reduce Risk Element 2: Identity and Document Hazards Element 6: Verify, Validate, & Document Risk Reduction Element 3: Assess and Document Risk Element 4: Identity and Document Risk Mitigation Measures Element 7: Accept Risk and Document Element 8: Manage Life-Cycle Risk 4

Document the System Safety Approach The PM shall document the system safety approach for managing hazards as an integral part of the SE process. Minimum requirements for the approach include Describing the risk management effort ID & document the prescribed & derived requirements applicable to the system Define how hazards & associated risks are formally accepted by the appropriate risk acceptance authority Document hazards with a closed-loop Hazard Tracking System (HTS) Source: MIL-STD 882E, page 10. 5

Identify and Document Hazards Hazards are identified through a systematic analysis process that includes system hardware & software, system interfaces & the intended use/environment Consider Mishap data Relevant environmental & occupational health data User physical characteristics, knowledge skills & abilities Lessons learned from legacy/similar systems 6

Assess & Document Risk (Severity/Consequences) SEVERITY CATEGORIES MIL-STD-882E Description Severity Category Catastrophic 1 Critical 2 Marginal 3 Negligible 4 Mishap Result Criteria Could result in one or more of the following: Death, permanent total disability, irreversible significant environment impact, or monetary loss equal to or exceeding $10M. Could result in one or more of the following: permanent partial disability, injuries or occupational illness that may result in hospitalization of the at least three personnel, reversible significant environmental impact, or monetary loss equal to or exceeding $1m but less than $10M Could result in one or more of the following: injury or occupational illness resulting in one or more lost work day(s), reversible moderate environmental impact, or monetary loss equal to or exceeding $100K but less than $1M Could result in one or more of the following: Injury or occupational illness not resulting in a lost work day, minimal environmental impact, or monetary loss less than $100K.

Assess & Document Risk (Probability) PROBABILITY LEVELS Description Level Individual Item Fleet/Inventory* Frequent Probate Occasional Remote Improbable Eliminated A B C D E F Likely to occur often in the life of an item. Will occur several times in the life of an item. Likely to occur sometime in the life of an item. Unlikely, but possible to occur in the life of an item. So unlikely, it can be assumed occurrence may not be experienced in the life of an item. Continuously experienced. Will occur frequently. Will occur several times. Unlikely, but can reasonably be expected to occur Unlikely to occur, but possible. Incapable of occurrence. This level is used when the potential hazards are identified and later eliminated.

Table A-II Example of Probability Levels PROBABILITY LEVELS Description Level Individual Item Fleet/Inventory* Quantitative Frequent A Likely to occur often in the life of an item. Continuously experienced. Probate B Will occur several times in the life of an item. Will occur frequently. Occasional C Likely to occur sometime in the life of an item. Will occur several times. Remote Improbable Eliminated D E F Unlikely, but possible to occur in the life of an item. So unlikely, it can be assumed occurrence may not be experienced in the life of an item. Unlikely, but can reasonably be expected to occur Unlikely to occur, but possible. Incapable of occurrence. This level is used when the potential hazards are identified and later eliminated.

Assess & Document Risk (Risk Matrix) Probability Severity Catastrophic (1) RISK ASSESSMENT MATRIX Critical (2) Marginal (3) Negligible (4) Frequent (A) High High Serious Medium Probable (B) High High Serious Medium Occasional (C) High Serious Medium Low Remote (D) Serious Medium Medium Low Improbable (E) Medium Medium Medium Low Eliminated (F) Eliminated MIL-STD-882E

Identify & Document Risk Mitigation Measures The goal should always be to eliminate the hazard if possible. When the hazard cannot be eliminated Reduce the risk to the lowest acceptable level Within cost, schedule & performance constraints Applying system safety design order of precedence: Eliminate hazards Design changes Incorporate engineered features or devices Provide warning devices Signs, procedures, training, PPE 11

Reduce Risk Mitigation measures are selected and implemented to achieve an acceptable risk level Present the current hazards, their associated severity & probability assessments & status of risk reduction efforts at technical reviews and test readiness reviews. 12

Verify, Validate & Document Risk Reduction Verify the implementation & validate the effectiveness of all selected risk mitigation measures through Appropriate analysis Testing Demonstration Inspection Document the verification & validation in the Hazard Tracking System 13

Accept Residual Risk, and Document 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, Encl. 12. The user representative shall be part of this process throughout the life-cycle of the system; and shall provide formal concurrence before all Serious & High risk acceptance decisions. Each risk acceptance decision shall be documented in the Hazard Tracking System (HTS) 14

Manage Lifecycle Risk After the system is fielded, the program office uses the system safety process to identify hazards & maintain the HTS throughout the system s lifecycle. Test related risks (such as those in the upcoming exercise) need to be managed throughout the T&E process. In addition, DoD requires program offices to support system-related Class A and B mishap investigations. 15

Software Contribution to System Risk The assessment of risk for software, and consequently software-controlled or software-intensive systems, cannot rely on the risk severity & probability. Another approach shall be used for the assessment of software s contributions to system risk that considers the potential risk severity & the degree of control that software exercises over the system. 16

Software Control Categories MIL-STD-882E, Table IV Level Name Description 1 Autonomous (AT) 2 Semi- Autonomous (SAT) 3 Redundant Fault Tolerant (RFT) Software functionality that exercises autonomous control authority over potentially safety significant hardware systems, subsystems, or components without the possibility of predetermined safe detection and intervention by a control entity to preclude the occurrence of a mishap or hazard. (This definition includes complex system/software functionality with multiple subsystems, Interacting parallel processors, multiple interfaces, and safety-critical functions that are time critical.) Software functionality that exercises control authority over potentially safety-significant hardware systems, subsystems, or components, allowing time for predetermined safe detection and intervention by independent safety mechanisms to mitigate or control the mishap or hazard. (This definition includes the control of moderately complex system/software functionality, no parallel processing, or few interfaces, but other safety systems/mechanisms can partially mitigate. System and software fault detection and annunciation notifies the control entity of the need for required safety actions.) Software item that displays safety-significant information requiring immediate operator entity to execute a predetermined action for mitigation or control over a mishap or hazard. Software exception, failure, fault, or delay will allow, or fail to prevent, mishap occurrence. (This definition assumes that the safety-critical display information may be time-critical, but the time available does not exceed the time required for adequate control entity response and hazard control.) Software functionality that issues commands over safety-significant hardware systems, subsystems, or components requiring a control entity to complete the command function. The system detection and functional reaction includes redundant, independent fault tolerant mechanisms for each defined hazardous condition. (This definition assumes that there is adequate fault detection, annunciation, tolerance, and system recovery to prevent the hazard occurrence if software fails, malfunctions, or degrades. There are redundant sources of safety-significant information, and mitigating functionality can respond within any time-critical period.) Software that generates information of a safety-critical nature used to make critical decisions. The system includes several redundant, independent fault tolerant mechanisms for each hazardous condition, detection and display. 4 Influential Software generates information of a safety-related nature used to make decisions by the operator, but does not require operator action to avoid a mishap. 5 No Safety Impact (NSI) Software functionality that does not possess command or control authority over safety significant hardware systems, subsystems, or components and does not provide safety significant information. Software does not provide safety-significant or time sensitive data or information that requires control entity interaction. Software does not transport or resolve communication 17 of safety-significant or time sensitive data.

Software Safety Criticality Matrix Severity Safety Criticality Matrix Software Control Category Catastrophic (1) Critical (2) Marginal (3) Negligible (4) 1 SwCI 1 SwCI 1 SwCI 3 SwCI 4 2 SwCI 1 SwCI 2 SwCI 3 SwCI 4 3 SwCI 2 SwCI 3 SwCI 4 SwCI 4 4 SwCI 3 SwCI 4 SwCI 4 SwCI 4 5 SwCI 5 SwCI 5 SwCI 5 SwCI 5 MIL-STD-882E, Table V 18

SwCl SwCl 1 SwCl 2 SwCl 3 SwCl 4 SwCl 5 Software Level of Rigor (LOR) Level of Rigor Tasks Tasks Program shall perform analysis of requirements, architecture, design, and code; and conduct in-depth safety specific testing. Program shall perform analysis of requirements, architecture, and design; and conduct in-depth safety-specific testing. Program shall perform analysis of requirements and architecture; and conduct in-depth safety-specific testing. Program shall conduct safety-specific testing. Once assessed by safety engineering as Not Safety, then no safety specific analysis or verification is required. Consult the Joint Software Systems Safety Engineering Handbook http://www.acq.osd.mil/se/docs/joint-sw-systems-safety-engineering-handbook.pdf and AOP 52 for guidance on required software analyses MIL-STD-882E, Table V 19

Relationship Between SwCI, Risk Level, LOR Tasks, and Risk Software Criticality Index (SwCl) SwCl 1 SwCl 2 SwCl 3 SwCl 4 Risk Level High Serious Medium Low Software LOR Tasks and Risk Assessment/Acceptance If SwCI 1 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as HIGH and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 1 LOR tasks or prepare a formal risk assessment for acceptance of a HIGH risk. If SwCI 2 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as SERIOUS and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 2 LOR tasks or prepare a formal risk assessment for acceptance of a SERIOUS risk. If SwCI 3 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as MEDIUM and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 3 LOR tasks or prepare a formal risk assessment for acceptance of a MEDIUM risk. If SwCI 4 LOR tasks are unspecified or incomplete, the contributions to system risk will be documented as LOW and provided to the PM for decision. The PM shall document the decision of whether to expend the resources required to implement SwCI 4 LOR tasks or prepare a formal risk assessment for acceptance of a LOW risk. SwCl 5 Not Safety No safety-specific analyses or testing is required. 20 MIL-STD-882E, Table VI

Risk Management / Environment, Safety & Occupational Health (ESOH) Exercise MDD Materiel Solution Analysis CDD Validation Dev. RFP Release A B C Tech Maturation & Risk Reduction Engineering and Manufacturing Development FRP Production & Deployment IOC FOC Operations & Support YOU ARE HERE 21

Risk Management / ESOH Exercise Given: Acquisition documents COIs and CTPs Objective: Identify Safety and Environmental Issues and prepare mitigating strategies Overview (4 steps) 1. Review the system hazard assessment white paper 2. Select one safety and one environmental test hazard 3. Analyze and rate hazards 4. Develop mitigating strategies 22

Hazard Assessment (DoD Risk Management Guide) Likelihood 5 4 3 2 Red = High Yellow = Moderate Green = Low Destroy UAV 1 Example: 1 2 3 4 5 Consequence Test hazard: flutter test, structural failure, Destroy UAV Likelihood = 3; Consequence = 5 Assessment: High (see table) 23

Safety / Environmental Hazards (Sample Format) Hazard Rating Mitigating actions Hazard 1 For example: Destroying the UAV Hazard 2 Po = 3 C = 5 H, M, L Po = X C = X H, M, L Action 1-M&S to predict conditions where structural failure is likely to occur Action 2-Change the UAV design, to decrease likelihood Action 3-Change test methods, to decrease consequences (use scale model in wind tunnel instead of UAV) Action 1 Action 2 Action 3 Should they have used the MIL-STD 882 approach (vice DoD Risk Mgmt Guide)? 24

ESOH Exercise - Timeline Four Tasks (30 minutes): 1. Review system hazard assessment white paper 2. Select one safety and one environmental test hazard 3. Analyze and Rate Hazards (Make educated guesses, as necessary) 4. Develop at least 3 mitigating actions for each hazard 25