Difference between revisions of "System Safety"
(→Models) |
|||
| Line 80: | Line 80: | ||
==Models== | ==Models== | ||
| + | Information to be supplied at a later date. | ||
==Tools== | ==Tools== | ||
Revision as of 10:25, 23 March 2017
In the most general sense, safety is freedom from harm. As an engineering discipline, system safety is concerned with minimizing hazards that can result in a mishap with an expected severity and with a predicted probability. These events can occur in elements of life-critical systems as well as other system elements. MIL-STD-882E defines system safety as “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" (DoD 2012). MIL-STD-882E defines standard practices and methods to apply as engineering tools in the practice of system safety. These tools are applied to both hardware and software elements of the system in question."
Please note that not all of the generic below sections have mature content at this time. Anyone wishing to offer content suggestions should contact the SEBoK Editors in the usual ways.
Overview
System safety engineering focuses on identifying hazards, their causal factors, and predicting the resultant severity and probability. The ultimate goal of the process is to reduce or eliminate the severity and probability of the identified hazards, and to minimize risk and severity where the hazards cannot be eliminated. MIL STD 882E defines a hazard as "A real or potential condition that could lead to an unplanned event or series of events (i.e., mishap) resulting in death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment." (DoD 2012).
While Systems safety engineering attempt to minimize safety issues throughout the planning and design of systems, mishaps do occur from combinations of unlikely hazards with minimal probabilities. As a result, safety engineering is often performed in reaction to adverse events after deployment. For example, many improvements in aircraft safety come about as a result of recommendations by the National Air Traffic Safety Board based on accident investigations. Risk is defined as “A combination of the severity of the mishap and the probability that the mishap will occur" (DoD 2012, 7). Failure to identify risks to safety, and the according inability to address or "control" these risks, can result in massive costs, both human and economic (Roland and Moriarty 1990)."
System Description
Information to be supplied at a later date.
Discipline Management
Information to be supplied at a later date.
Discipline Relationships
Interactions
Information to be supplied at a later date.
Dependencies
Information to be supplied at a later date.
Discipline Standards
Information to be supplied at a later date.
Personnel Considerations
System Safety specialists are typically responsible for ensuring system safety. Air Force Instruction (AFI) provides the following guidance:
9.1 System safety disciplines apply engineering and management principles, criteria, and techniques throughout the life cycle of a system within the constraints of operational effectiveness, schedule, and costs.
9.1.1. System safety is an inherent element of system design and is essential to supporting system requirements. Successful system safety efforts depend on clearly defined safety objectives and system requirements.
9.1.2. System safety must be a planned, integrated, comprehensive effort employing both engineering and management resources.
(USAF 1998, 91-202)
Safety personnel are responsible for the integration of system safety requirements, principles, procedures, and processes into the program and into lower system design levels to ensure a safe and effective interface. Two common mechanisms are the Safety Working Group (SWG) and the Management Safety Review Board (MSRB). The SWG enables safety personnel from all integrated product teams (IPTs) to evaluate, coordinate, and implement a safety approach that is integrated at the system level in accordance with MIL-STD-882E (DoD 2012). Increasingly, safety reviews are being recognized as an important risk management tool. The MSRB provides program level oversight and resolves safety related program issues across all IPTs. Table 1 provides additional information on safety.
| Ontology Element Name | Ontology Element Attributes | Relationships to Safety |
|---|---|---|
| Failure modes | Manner of failure | Required attribute |
| Severity | Consequences of failure | Required attribute |
| Criticality | Impact of failure | Required attribute |
| Hazard Identification | Identification of potential failure modes | Required to determine failure modes |
| Risk | Probability of a failure occurring | Required attribute |
| Mitigation | Measure to take corrective action | Necessary to determine criticality and severity |
Table 1. indicates that achieving System safety involves a close tie between Safety Engineering and other specialty Systems Engineering disciplines such as Reliability and Maintainability Engineering.
System safety engineering focuses on identifying hazards, their causal factors, and predicting the resultant severity and probability. The ultimate goal of the process is to reduce or eliminate the severity and probability of the identified hazards, and to minimize risk and severity where the hazards cannot be eliminated. MIL STD 882E defines a hazard as "A real or potential condition that could lead to an unplanned event or series of events (i.e., mishap) resulting in death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment." (DoD 2012).
While Systems safety engineering attempt to minimize safety issues throughout the planning and design of systems, mishaps do occur from combinations of unlikely hazards with minimal probabilities. As a result, safety engineering is often performed in reaction to adverse events after deployment. For example, many improvements in aircraft safety come about as a result of recommendations by the National Air Traffic Safety Board based on accident investigations. Risk is defined as “A combination of the severity of the mishap and the probability that the mishap will occur" (DoD 2012, 7). Failure to identify risks to safety, and the according inability to address or "control" these risks, can result in massive costs, both human and economic (Roland and Moriarty 1990)."
Metrics
Information to be supplied at a later date.
Models
Information to be supplied at a later date.
Tools
References
Works Cited
DoD. 2012. Standard practice for System Safety. Arlington, VA, USA: Department of Defense (DoD). MIL-STD 882E. Accessed 4 November 2014 at http://assistdoc1.dla.mil/qsDocDetails.aspx?ident_number=36027
Roland, H.E. and B. Moriarty. 1990. System Safety Engineering and Management. Hoboken, NJ, USA: Wiley-IEEE.
USAF. 1998. The US Air Force Mishap Prevention Program. Washington, DC, USA: US Air Force, Air Force Instruction (AFI).
Primary References
None.
Additional References
Bahr, N. J. 2001. "System Safety Engineering and Risk Assessment." In International Encyclopedia of Ergonomics and Human Factors. Vol. 3. Ed. Karwowski, Waldemar. New York, NY, USA: Taylor and Francis.
ISSS. "System Safety Hazard Analysis Report." The International System Safety Society (ISSS). DI-SAFT-80101B. http://www.system-safety.org/Documents/DI-SAFT-80101B_SSHAR.DOC.
ISSS. "Safety Assessment Report." The International System Safety Society (ISSS). DI-SAFT-80102B. http://www.system-safety.org/Documents/DI-SAFT-80102B_SAR.DOC.
ISSS. "Engineering Change Proposal System Safety Report." The International System Safety Society (ISSS). DI-SAFT-80103B. http://www.system-safety.org/Documents/DI-SAFT-80103B_ECPSSR.DOC.
ISSS. "Waiver or Deviation System Safety Report." The International System Safety Society (ISSS). DI-SAFT-80104B. http://www.system-safety.org/Documents/DI-SAFT-80104B_WDSSR.DOC.
ISSS. "System Safety Program Progress Report." The International System Safety Society (ISSS). DI-SAFT-80105B. http://www.system-safety.org/Documents/DI-SAFT-80105B_SSPPR.DOC.
ISSS. "Health Hazard Assessment Report." The International System Safety Society (ISSS). DI-SAFT-80106B. http://www.system-safety.org/Documents/DI-SAFT-80106B_HHAR.DOC.
ISSS. "Explosive Ordnance Disposal Data." The International System Safety Society (ISSS). DI-SAFT-80931B. http://www.system-safety.org/Documents/DI-SAFT-80931B_EODD.pdf.
ISSS. "Explosive Hazard Classification Data." The International System Safety Society (ISSS). DI-SAFT-81299B. http://www.system-safety.org/Documents/DI-SAFT-81299B_EHCD.pdf.
ISSS. "System Safety Program Plan (SSPP)." The International System Safety Society (ISSS). DI-SAFT-81626. http://www.system-safety.org/Documents/DI-SAFT-81626_SSPP.pdf.
ISSS. "Mishap Risk Assessment Report." The International System Safety Society (ISSS). DI-SAFT-81300A. http://www.system-safety.org/Documents/DI-SAFT-81300A_MRAR.DOC.
Joint Software System Safety Committee. 1999. Software System Safety Handbook. Accessed 7 March 2012 at http://www.system-safety.org/Documents/Software_System_Safety_Handbook.pdf.
Leveson, N. 2011. Engineering a safer world: systems thinking applied to safety. Cambridge, Mass: MIT Press.
Leveson, N. G. 2012. “Complexity and Safety.” In Complex Systems Design & Management, ed. Omar Hammami, Daniel Krob, and Jean-Luc Voirin, 27–39. Springer Berlin Heidelberg. http://dx.doi.org/10.1007/978-3-642-25203-7_2.
NASA. 2004. NASA Software Safety Guidebook. Accessed 7 March 2012 at [[1]].
Roland, H. E., and Moriarty, B. 1985. System Safety Engineering and Management. New York, NY, USA: John Wiley.
SAE. 1996. Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. ARP 4761. Warrendale, PA, USA: Society of Automotive Engineers. Accessed 28 August 2012 at [http://standards.sae.org/arp4761/].
SAE. 1996. Certification Considerations for Highly-Integrated Or Complex Aircraft Systems. ARP 4754. Warrendale, PA, USA: Society of Automotive Engineers. Accessed 28 August 2012 at [http://standards.sae.org/arp4754/].
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus