1. The MIL-STD-882 Process Presentation to the January 2014 Safety Case Workshop Don Swallom U.S. Army Aviation and Missile Command Redstone Arsenal, Alabama

2. Caveat
Opinions expressed are those of the speaker and not the coordinated position of AMCOM, Army Materiel Command, the US Army or the Department of Defense.
But maybe they should be.

3. MIL-STD-882
Content
Process
What is "Acceptable Risk"
How 882 "makes the safety case"

5. Task Section 100 – Management
Task 101 Hazard Identification and Mitigation Effort Using The System Safety Methodology
Task 102 System Safety Program Plan
Task 103 Hazard Management Plan
Task 104 Support of Government Reviews/Audits
Task 105 Integrated Product Team/Working Group Support
Task 106 Hazard Tracking System
Task 107 Hazard Management Progress Report
Task 108 Hazardous Materials Management Plan
Task Section 200 – Analysis
Task 201 Preliminary Hazard List
Task 202 Preliminary Hazard Analysis
Task 203 System Requirements Hazard Analysis
Task 204 Subsystem Hazard Analysis
Task 205 System Hazard Analysis
Task 206 Operating and Support Hazard Analysis
Task 207 Health Hazard Analysis
Task 208 Functional Hazard Analysis
Task 209 System-of-Systems Hazard Analysis
Task 210 Environmental Hazard Analysis
Task Section Evaluation
Task 301 Safety Assessment Report
Task 302 Hazard Management Assessment Report
Task 303 Test and Evaluation Participation
Task 304 Review of Engineering Change Proposals, Change Notices, Deficiency Reports, Mishaps, and Requests for Deviation/Waiver
Task Section Verification
Task 401 Safety Verification
Task 402 Explosives Hazard Classification Data
Task 403 Explosive Ordnance Disposal Data

6. Appendix A Guidance for the System Safety Effort (2 pages)
Appendix B Software System Safety Engineering and Analysis (6 pages)

8. Element 1 Document the system safety approach
Minimum requirements:
Describe the risk management effort and how the program is integrating risk management into:
Systems engineering process,
Integrated Product and Process Development process
Overall program management structure
Identify and document the prescribed and derived requirements applicable to the system
Ensure inclusion in the system specifications
Requirements flow-down to subcontractors, vendors, and suppliers.
Define how hazards and risks are formally accepted (DoDI )
Document hazards with a closed-loop Hazard Tracking System (HTS)

9. Element 2 Identify and document hazards
Identify hazards through a systematic analysis process. Include:
System hardware and software
System interfaces (includes human interfaces)
Intended use or application
Operational environment
Mishap data
Relevant environmental and occupational health data
User physical characteristics
User knowledge, skills, and abilities
Lessons learned from legacy and similar systems
Entire system life-cycle
Potential impacts to personnel, infrastructure, defense systems, public, environment
Document hazards in the HTS

10. Element 3 Assess and document risk
Assess severity and probability of the potential mishap(s) for each hazard across all system modes using Tables I and II
Assessed risks are expressed as a Risk Assessment Code (RAC)
Table III assigns a risk level of High, Serious, Medium, or Low for each RAC.
Tables I, II and III used unless alternative approved
Document numerical definitions of probability
Assessed risks documented in HTS

14. Element 4 Identify and document risk mitigation measures
Identify potential risk mitigations
Estimate expected risk for alternatives
Document in the HTS
Eliminate the hazard else reduce to lowest acceptable level within constraints of cost, schedule, and performance by applying system safety design order of precedence:
Eliminate hazards through design selection
Reduce risk through design alteration
Incorporate engineered features or devices
Provide warning devices
Incorporate signs, procedures, training, and personal protective equipment (PPE)

15. Element 5 Reduce risk
Select and implement mitigation measures to achieve an acceptable risk level
Consider and evaluate the cost, feasibility, and effectiveness of candidate mitigation methods as part of the systems engineering and Integrated Product Team (IPT) processes
Present current hazards, their associated severity and probability assessments, and status of risk reduction efforts at technical reviews

16. Element 6 Verify, validate, and document risk reduction
Verify implementation
Validate effectiveness of all selected risk mitigation measures through appropriate:
Analysis
Testing
Demonstration or
Inspection
Document verification and validation in the HTS

17. Element 7 Accept risk and document
Risks accepted by appropriate authority per DoDI before exposing people, equipment, or environment to known system- related hazards
System configuration and associated documentation supporting formal risk acceptance decision shall be provided to the Government for retention through the life of the system.
Tables I, II and III used unless alternative approved
User representative part of the process throughout the life-cycle
Provides formal concurrence before Serious & High risk acceptance
After fielding, mishaps, user feedback, and experience with similar systems or other sources may reveal new hazards or demonstrate that the risk for a known hazard is higher or lower than previously recognized
Revised risk accepted IAW DoDI

18. Element 8 Manage life-cycle risk
Identify hazards and maintain HTS through system life-cycle
Monitor and assess changes (interfaces, users, hardware, software, mishap data, missions, profiles, system health data, etc.)
Program office and user community maintain effective communications to identify and manage new hazards and risks
If new hazard discovered or known hazard has higher risk, formally accept IAW DoDI
DoD requires program offices to support system-related Class A and B mishap investigations by providing analyses of hazards that contributed to the mishap and recommendations for materiel risk mitigation measures, especially those that minimize human errors

19. System safety
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

20. Acceptable Risk
Risk that the appropriate acceptance authority (as defined in DoDI ) is willing to accept without additional mitigation.

21. Acceptable Risk Unacceptable Risk Acceptable Unacceptable Risk
Reduction
Effort
Unacceptable
Risk
Acceptable
Cost ↑
Schedule ↑
Performance ↓
Unacceptable

22. Lowest Acceptable Risk Level
When a hazard cannot be eliminated, the associated risk should be reduced to the lowest acceptable level within the constraints of cost, schedule, and performance by applying the system safety design order of precedence.
- Paragraph 4.3.4, Identify and document risk mitigation measures. (Element 4)

23. Lowest Acceptable Risk Level
Reduction
Effort
Unacceptable
Risk
Acceptable
Lowest
Acceptable
Cost ↑
Schedule ↑
Performance ↓
Unacceptable

24. Lowest Acceptable Risk Level
Reduction
Effort
High
Serious
Medium
Low
Unacceptable
Acceptable
Unacceptable
Cost ↑
Schedule ↑
Performance ↓
Risk

25. Defund B to increase A and optimize both
Total Cost
Optimum
Cost
Cost of Mishaps
Cost of mitigation measures
Cost B
Defund B to increase A and optimize both A
Degree of Safety
The Safety Bathtub Curve

26. Claims – Arguments - Evidence
Claim = assertion to be proven
Claim
Claim
Argument = how evidence supports claim
Argument
Argument
Evidence = required documentation
Evidence
Evidence
These terms are not used in MIL-STD-882E

27. Verify – Validate - Document
MIL-STD-882 does use the terms verify and validate in the context of systems engineering
Element 6 is "Verify, validate, and document risk reduction"
Task 401 is "Safety Verification"
If hazard mitigations are rigorously integrated into system requirements they will be verified and validated assuming a rigorous systems engineering process

28. April 2009
25 pages

30. Safety Assessment Report versus Safety Case Report
Safety Case - A structured argument, supported by a body of evidence that provides a compelling, comprehensible and valid case that a system is safe for a given application in a given operating environment.
Safety Case Report - A report that summarises the arguments and evidence of the Safety Case, and documents progress against the safety programme.
- Defence Standard 00-56

31. Safety Assessment Report versus Safety Case Report
Safety Assessment Report - A comprehensive evaluation of the safety risks being assumed prior to test or operation of the system or at contract completion. It identifies all safety features of the system, design, and procedural hazards that may be present in the system being acquired, and specific procedural controls and precautions that should be followed.
- DI-SAFT-80102B, Safety Assessment Report

32. Safety Assessment Report versus Safety Case Report
301.1 Purpose. Task 301 is to perform and document a Safety Assessment Report (SAR) to provide a comprehensive evaluation of the status of safety hazards and their associated risks prior to test or operation of a system, before the next contract phase, or at contract completion.
- MIL-STD-882 Task 301, Safety Assessment Report

33. Safety Assessment Report versus Safety Case Report
The contractor shall prepare a report that contains the following information:
a. Specific risk matrix used to classify hazards
b. Results of analyses and tests performed to identify hazards, assess risks, and verify/validate effectiveness of mitigation measures
c. Hazard Tracking System (HTS) data
d. Summary of risks for each identified hazard
e. Hazardous Material (HAZMAT)
f. Test or other event-unique mitigation measures necessary to reduce risks.
g. Recommendations applicable to hazards located at the interface of the system with other systems.
h. Based on the scope of the report, a summary statement addressing the system's readiness to test, operate, or proceed to the next acquisition phase.
i. List all pertinent references, including (but not limited to) test and analysis reports, standards and regulations, specifications and requirements documents, operating manuals, and maintenance manuals.

34. Questions? Deep Impact Don Swallom Safety Engineer AMCOM Safety Office
Aviation System Safety Division
(256)
Questions?
Deep Impact