Systems Safety Methodology – MIL-STD-882E
Overview
System safety is a specialty within systems engineering that applies engineering and management principles, criteria, and techniques to optimize safety. MIL-STD-882E, DoD Standard Practice for System Safety, 11 May 2012, describes the methodology for identifying and assessing hazards and mitigating the associated risks encountered during the development, test, production, operation, maintenance, and disposal of the defense system. DoDI 5000.02, Operation of the Defense Acquisition System, mandates the use of 882E methodology as the basis for hazard identification and ESOH risk mitigation and management efforts required of an acquisition program. While the methodology originated with system safety engineering, it has evolved to where it can be used by any ESOH discipline. ESOH is an acronym to include many functional disciplines that encompass the processes and approaches for addressing ESOH laws, regulations, Executive Orders; DoD policies; environmental compliance; 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 (HAZMAT) management; and, pollution prevention. All ESOH functional disciplines using the system safety methodology should coordinate their efforts as part of the overall systems engineering process because mitigation measures optimized for only one discipline may create hazards in other disciplines.
Section 4.3 of MIL-STD-882E established the system safety methodology as eight elements that form a risk management process to be applied iteratively throughout all acquisition phases (including operation and support of the system). The MIL-STD-882E methodology offers flexibility and scalability to Program Managers (PMs). The inclusion of specific, discrete ESOH analysis tasks in the standard provides additional guidance in executing an ESOH risks assessment effort. Table 1 provides a list of the optional tasks and their applicability to program phases. Tasks can be prioritized and the level of effort estimated for execution of each task. This information can be of value in selecting the tasks that can be accomplished within schedule and funding constraints for an acquisition program. The PM and ESOH practitioner should ensure that MIL-STD-882E is included in solicitations and contracts as an efficient way to instruct the contractor to meet the DoD policy requirement. Only Section 3 – Definitions and Section 4 – General Requirements are mandatory when MIL-STD-882E is required in a solicitation or contract. Section 4 includes System Safety Requirements, System Safety Process (i.e. methodology), and Software Contribution to System Risk. The ESOH risk assessment effort can be augmented by identifying specific tasks that may be necessary to ensure the contractor adequately addresses areas that the program needs to emphasize. Consideration should be given to the complexity and dollar value of the program and the expected levels of risks involved.
Table 1. Task Application Matrix
The general and tailored analyses/tasks are available to assist in identifying hazards and assessing risks as the system design coalesces. Analyses may be conducted at the subsystem or component level and build to the system or system of systems level depending on the size and complexity of the system. Several specific tasks are also included to address environmental and occupational health considerations (such as hazardous material management, health hazard analysis, and environmental hazard analysis). In addition, MIL-STD-882E provides to date the most comprehensive primer on software safety.
MIL-STD-882E System Safety Methodology
The system safety methodology is intended to be an integral part of the system’s life-cycle – beginning in conceptual design and ending with demilitarization/disposal of the system. The best time to eliminate hazards is during conceptual design when avoidance of risk may be achieved through alternative designs or materials. Conceptual design efforts should rely on the contributions of ESOH practitioners as part of the systems engineering Integrated Product Team (IPT). Early efforts support hazard identification, risk assessment, and development of mitigations, which can result in significant savings – in life, equipment replacement, and environmental impact. Later the focus is on risk acceptance to support development of testing and verification of implemented mitigations. Efforts shift to configuration control, once the system design is locked in at the critical design review, bringing another iteration of identification, assessment, and mitigation steps. The efforts of the program office’s ESOH practitioners transitions upon fielding of the system to participating in mishap investigations, analyzing mishap and Component-level safety data/messages, and working with the Chief Engineer’s team and Change Control Board to review any engineering change or deviation proposals, reassessing risks, developing mitigations for any new or mischaracterized hazards, and verifying mitigations. Figure 1 illustrates the eight elements of the system safety methodology as documented in MIL-STD-882E.
Element 1 – Document the system safety approach
The system safety approach is a planned integrated and comprehensive engineering effort that establishes the constants that are employed throughout execution of the program, defines roles and responsibilities, describes how the system safety methodology is integrated into the larger systems engineering process for the acquisition program, and identifies requirements for the system. The minimum requirements for the approach include describing the risk management effort and how the program is integrating risk management into the systems engineering process, the Integrated Product Development process, and the overall program management structure; identifying and documenting the prescribed and derived requirements applicable to the system; describing the process for inclusion of ESOH derived requirements in system specifications and the flow-down of applicable requirements to subcontractors, vendors, and suppliers; defining how risks are formally accepted by the appropriate risk acceptance authority and concurred with by the user representative in accordance with DoDI 5000.02.; and describing the process for documenting hazards with a closed-loop hazard tracking system (HTS).
MIL-STD-882E provides a task that may be used to document the system safety approach: Task 102, System Safety Program Plan, (SSPP). Task 103 Hazard Management Plan may be more appropriately applied if non-system safety disciplines use the framework and methods of MIL-STD-882E to identify hazards and manage risks. As an alternative to these tasks, the system safety approach may be documented in the Systems Engineering Plan or the Programmatic ESOH Evaluation document.
Integration of the system safety methodology within the systems engineering process is crucial for execution of an effective ESOH risk management program and to have a meaningful effect on the “end system”. Special care should be exercised in committing resources for the most impact. Lines of communication and responsibility within the program, IPT structure, and various disciplines should be defined as part of the system safety approach. ESOH practitioners should be highly integrated, if not embedded, with the program office’s engineering, test, training, and logistics counterparts.
Risk assessment and acceptance are an important part of the system safety methodology. The risk assessment method should be fixed throughout the program with deliberately defined severity and probability levels definitions. The procedures for gaining formal risk acceptance in accordance with DoDI 5000.02 should be defined in the safety approach.
All programs need a tool to document and track results of the ESOH risk management effort. The closed-loop HTS is that tool. Minimum requirements for a HTS are identified in MIL-STD-882E, Section 4.3.1. A more robust system is described in Task 106, Hazard Tracking System. One key to a successful ESOH risk management effort is consistent use of the HTS as the central repository for hazard-related data, mitigations, analysis and validation efforts/results, risk acceptance, and any other pertinent data. A well-executed HTS maps the resolution of each identified hazard, as well as efficiently supporting the required risk status reporting at the varied program and technical reviews during the acquisition life-cycle for the system.
Element 2 – Identify and Document Hazards
Identification of hazards can occur at any stage of the system’s life-cycle, though it is most prevalent in the early design phase and during test and evaluation evolutions. Numerous methods are used to identify real and potential hazards including requirements, analysis, comparison to similar systems, test results, mishap investigations, etc. Task Section 200 in MIL-STD-882E offers a number of analyses typically used to help identify hazards. These include traditional system safety analyses like the Preliminary Hazard Analysis (Task 202) and Subsystem Hazards Analysis (Task 204). There are newer analyses, some geared towards occupational health and environmental impacts (e.g., Task 207, Health Hazard Analysis and Task 210, Environmental Hazard Analysis), and one geared toward System of Systems Hazard Analysis (Task 209). With Task 209, the expectation is that when a system is contributing to a larger system of systems, the consideration for new hazards, hazard contribution and mitigation is considered for the collective system of systems. Task 209 can also be used as the foundation for determining and considering hazards related to a larger context reaching beyond physical interfaces to include electronic communications and interoperability. Regardless of the method, once identified, each hazard should be entered into the HTS for processing and further monitoring.
Element 3 – Assess and Document Risk
Each identified hazard is assessed for its level of risk and the results are documented in the HTS. All programs must use the MIL-STD-882E, per DoDI 5000.02, severity category and probability level definitions and ESOH Risk Assessment Matrix in Tables I - III of the standard unless tailored alternative definitions and/or a tailored matrix are formally approved in accordance with Component policy. One example of an alternative to the definitions reflected in MIL-STD-882E might be to use numerical probability levels. Such a change may be appropriate for aircraft systems where probability of an event is tied to the number of flight hours, or ground systems where probability is tied to miles driven. Numerical probability models should only be used when there is confidence that the corresponding data will be available throughout the system’s life-cycle. For example, there is no benefit in implementing probabilities based on miles driven for vehicles (e.g., tanks) if there are no plans for reliable mileage tracking and feedback mechanism once the vehicles are fielded.
Table 2 shows the MIL-STD-882E severity categories and definitions. The ESOH practitioner selects a severity category from the established definitions based on the potential outcome of a mishap from the given hazard.
Table 2. MIL-STD-882E Severity Categories and Definitions
Table 3 shows the MIL-STD-882E probability levels and definitions which are used by the ESOH practitioner to select a probability level, based on the established definitions, to identify the likelihood of the mishap occurring.
Table 3. MIL-STD-882E Probability Levels and Definitions
The combination of severity and probability are expressed as a risk assessment code (RAC) and identified as a cell on the program’s established risk matrix, which dictates the designated risk level for the hazard. Figure 2 shows the MIL-STD-882E ESOH Risk Assessment Matrix.
Figure 2. Risk Assessment Matrix
Element 4 – Identify and Document Risk Mitigation Measures
Once the initial risk assessment is completed for a hazard, actions are taken to identify potential risk mitigation measures. The potential risk mitigations are documented in the HTS. Section 4.3.4 of MIL-STD-882E includes an order of precedence for mitigating hazards. The ideal solution is to eliminate a hazard through design or selection of materials. If the hazard cannot be eliminated, various methods of reducing the risk should be considered in the following order:
- design selections that eliminate the hazard
- design changes that reduce the risk severity, probability, or both
- design features to interrupt the mishap sequence and prevent the mishap from occurring or devices to reduce the risk severity, probability, or both
- warning devices (e.g., detection and warning systems) to alert personnel when hazardous conditions exist
- signage, procedures, training, and personal protective equipment
The program office may consider multiple mitigation efforts and may pursue more than one. Each potential mitigation should be annotated in the HTS to document that it was considered regardless of whether it was chosen for implementation.
Element 5 -- Reduce Risk
Mitigation measures are selected to achieve an acceptable risk level after consideration of the cost, feasibility, and effectiveness of candidate mitigation methods and consultation with Systems Engineering and other relevant Integrated Product Teams (IPT). Selected mitigations are implemented as early as possible in system development to minimize cost, schedule, and performance impacts. In some cases, early implementation of a mitigation action is not possible, as with newly discovered hazards in a fielded system. In such instances, expedient action is preferred to minimize risk. The status of mitigation efforts should be tracked in the HTS and briefed at technical reviews and other appropriate forums.
Element 6 – Verify, Validate, and Document Risk Reduction
The mitigation is verified and validated for effectiveness of risk reduction. Verification and validation through comprehensive testing is a desirable method, but often this option is not feasible due to cost, schedule, or other limitations. Analysis, demonstration, and inspection are valid options although sometimes are less reliable. Verification and validation methods for mitigations should be documented in the HTS along with the results. For any and all risk not eliminated, the program office decides between accepting the risk at the current level or continuing with mitigation efforts through other alternatives. Per DoDI 5000.02, all risk acceptances must occur prior to exposing people, equipment or the environment to know system-related hazards.
Element 7 – Accept Risk and Document
DoDI 5000.02 requires ESOH risk to be formally accepted “prior to exposing people, equipment, or the environment to know system-related hazards.” Risk acceptance authorities for each ESOH risk level (i.e., high, serious, medium, and low) are delineated in DoDI 5000.02 and must be adhered to by all programs regardless of the type of risk matrix used by a program for ESOH risk management. This means a system or its components may require formal risk acceptance at multiple times during the system’s life-cycle (e.g., component level testing, system integration testing, and fielding). For high and serious risks, concurrence of the User Representative is required as part of the risk acceptance process to ensure their acknowledgement of system ESOH-related risks. Pertinent data from each risk acceptance should be documented in the HTS. The ESOH Risk Management topic provides additional information on risk acceptance and reporting requirements.
Element 8 – Manage Life-Cycle Risk
After fielding of a system, responsibility for managing life-cycle risk typically transitions to an operational organization. This organization should inherit the HTS and build upon it as the system evolves over time based on changes (such as system interfaces, users, hardware and software, mishap data, mission(s) or profile(s), and system health data). Appropriate program office representatives, including ESOH practitioners, should be part of the configuration control process to ensure system design changes do not degrade the ESOH risk profile. Program office representatives and their ESOH practitioners should participate in mishap investigations, monitor mishaps in similar systems, and track follow-on testing to identify issues and risks. Newly discovered hazards or risks that were assessed as too low during system development need to be addressed using the MIL-STD-882 methodology (such as Elements 3 through 6) to include risk acceptance by the appropriate authority.
