Presentation on theme: "The MIL-STD-882 Process Presentation to the 14-15 January 2014 Safety Case Workshop Don Swallom U.S. Army Aviation and Missile Command Redstone Arsenal,"— Presentation transcript:
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 CaveatOpinions 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-882ContentProcessWhat is "Acceptable Risk"How 882 "makes the safety case"
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 processOverall program management structureIdentify and document the prescribed and derived requirements applicable to the systemEnsure inclusion in the system specificationsRequirements 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 softwareSystem interfaces (includes human interfaces)Intended use or applicationOperational environmentMishap dataRelevant environmental and occupational health dataUser physical characteristicsUser knowledge, skills, and abilitiesLessons learned from legacy and similar systemsEntire system life-cyclePotential impacts to personnel, infrastructure, defense systems, public, environmentDocument 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 IIAssessed 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 approvedDocument numerical definitions of probabilityAssessed risks documented in HTS
14 Element 4 Identify and document risk mitigation measures Identify potential risk mitigationsEstimate expected risk for alternativesDocument in the HTSEliminate 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 selectionReduce risk through design alterationIncorporate engineered features or devicesProvide warning devicesIncorporate signs, procedures, training, and personal protective equipment (PPE)
15 Element 5 Reduce riskSelect and implement mitigation measures to achieve an acceptable risk levelConsider and evaluate the cost, feasibility, and effectiveness of candidate mitigation methods as part of the systems engineering and Integrated Product Team (IPT) processesPresent 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 implementationValidate effectiveness of all selected risk mitigation measures through appropriate:AnalysisTestingDemonstration orInspectionDocument 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 hazardsSystem 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 approvedUser representative part of the process throughout the life-cycleProvides formal concurrence before Serious & High risk acceptanceAfter 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 recognizedRevised risk accepted IAW DoDI
18 Element 8 Manage life-cycle risk Identify hazards and maintain HTS through system life-cycleMonitor 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 risksIf new hazard discovered or known hazard has higher risk, formally accept IAW DoDIDoD 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 safetyThe 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 RiskRisk that the appropriate acceptance authority (as defined in DoDI ) is willing to accept without additional mitigation.
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)
25 Defund B to increase A and optimize both Total CostOptimumCostCost of MishapsCost of mitigation measuresCostBDefund B to increase A and optimize bothADegree of SafetyThe Safety Bathtub Curve
26 Claims – Arguments - Evidence Claim = assertion to be provenClaimClaimArgument = how evidence supports claimArgumentArgumentEvidence = required documentationEvidenceEvidenceThese 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 engineeringElement 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
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 hazardsb. Results of analyses and tests performed to identify hazards, assess risks, and verify/validate effectiveness of mitigation measuresc. Hazard Tracking System (HTS) datad. Summary of risks for each identified hazarde. 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