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,

Slides:



Advertisements
Similar presentations
Medical devices: Application of risk management to medical devices
Advertisements

Module N° 4 – ICAO SSP framework
Integra Consult A/S Safety Assessment. Integra Consult A/S SAFETY ASSESSMENT Objective Objective –Demonstrate that an acceptable level of safety will.
Module N° 3 – ICAO SARPs related to safety management
ESOH Committee Task Plan
Roadmap for Sourcing Decision Review Board (DRB)
PROJECT RISK MANAGEMENT
CIP Cyber Security – Security Management Controls
Software Quality Assurance Plan
Understanding the Requirements Qimpro Standards Organization
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
CENTRAL CONTRACTOR REGISTRATION (CAGE CODES) DFARS Case 2003-D040 DFARS Parts 204, 212, 213 and 252 are amended to remove policy on Central Contractor.
Define & Compare Flowcharts of Each Method Tom Delong.
DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Phase III – Validation Thomas Howard Chris Pierce.
Secure System Administration & Certification DITSCAP Manual (Chapter 6) Phase 4 Post Accreditation Stephen I. Khan Ted Chapman University of Tulsa Department.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
Systems Engineering Management
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Defining the Activities. Documents  Goal Statement defines why helps manage expectations  Statement of Work what gets delivered defines scope  Software.
ISO 9000 Certification ISO 9001 and ISO
4. Quality Management System (QMS)
4. Quality Management System (QMS)
OH&S Management System
QUALITY MANAGEMENT SYSTEM ACCORDING TO ISO
S/W Project Management
Integrated Capability Maturity Model (CMMI)
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
SQA Architecture Software Quality By: MSMZ.
Introduction to ISO New and modified requirements.
Introduction to Software Quality Assurance (SQA)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Basics of OHSAS Occupational Health & Safety Management System
Software Quality Assurance Activities
ISO 9001:2000 QUALITY MANAGEMENT SYSTEM REQUIREMENTS
WHAT IS SYSTEM SAFETY? The field of safety analysis in which systems are evaluated using a number of different techniques to improve safety. There are.
Project Planning QMS Training.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Project Management
LSST Camera CD-3 Review Brookhaven National Laboratory, Brookhaven, NY LSST Safety Council Camera Review Bremerton, WA 2015 LSST Camera Environment,
Project Life Cycle.
Georgia Institute of Technology CS 4320 Fall 2003.
1 FRENCH PROPOSAL FOR ESARR6 1 - BACKGROUND - 15/02/00 : Kick-off meeting, Presentation of the CAA/SRG input (SW01), Request from the chairman to comment.
SMS Planning.  Safety management addresses all of the operational activities of the entire organization.  The four (4) components of an SMS are: 1)
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Develop Project Charter
Over View of CENELC Standards for Signalling Applications
International Security Management Standards. BS ISO/IEC 17799:2005 BS ISO/IEC 27001:2005 First edition – ISO/IEC 17799:2000 Second edition ISO/IEC 17799:2005.
Maintaining and Sustaining System Integrity Configuration Management for Transportation Management Systems Configuration management (CM) describes a series.
Evaluate Phase Pertemuan Matakuliah: A0774/Information Technology Capital Budgeting Tahun: 2009.
Preparation Plan. Objectives Describe the role and importance of a preparation plan. Describe the key contents of a preparation plan. Identify and discuss.
OSHA Safety and Health Program Management Guidelines
ISO 9001:2015 Subject: Quality Management System Clause 8 - Operation
Development, Validation, Implementation and Enhancement for a Voluntary Protection Programs Center of Excellence (VPP CX) Capability for the Department.
WORKSHOP ON ACCREDITATION OF BODIES CERTIFYING MEDICAL DEVICES INT MARKET TOPIC 9 CH 8 ISO MEASUREMENT, ANALYSIS AND IMPROVEMENT INTERNAL AUDITS.
Department of Defense Voluntary Protection Programs Center of Excellence Development, Validation, Implementation and Enhancement for a Voluntary Protection.
System Development Life Cycle (SDLC). Activities Common to Software Projects Planning : Principles Principle #1. Understand the scope of the project.
Department of Defense Voluntary Protection Programs Center of Excellence Development, Validation, Implementation and Enhancement for a Voluntary Protection.
Software Engineering — Software Life Cycle Processes — Maintenance
Hazard Analysis of Routine Activities
ATEC Safety Verification Process
Supportability Design Considerations
Flooding Walkdown Guidance
Air Carrier Continuing Analysis and Surveillance System (CASS)
Defining the Activities
HSE Case: Risk Based Approach.
Quality Management Systems – Requirements
Engineering Processes
Software Reviews.
Presentation transcript:

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, Alabama

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.

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

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 300 - 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 400 - Verification Task 401 Safety Verification Task 402 Explosives Hazard Classification Data Task 403 Explosive Ordnance Disposal Data

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

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 5000.02) Document hazards with a closed-loop Hazard Tracking System (HTS)

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

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

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)

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

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

Element 7 Accept risk and document Risks accepted by appropriate authority per DoDI 5000.02 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 5000.02

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 5000.02 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

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

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

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

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)

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

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

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

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

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

April 2009 25 pages

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

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

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

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.

Questions? Deep Impact Don Swallom Safety Engineer AMCOM Safety Office Aviation System Safety Division (256) 842-8641 donald.w.swallom.civ@mail.mil Questions? Deep Impact