Safety case

Last updated

One definition of a Safety Case is that it is a structured argument, supported by evidence, intended to justify that a system is acceptably safe for a specific application in a specific operating environment. [1] Safety cases are often required as part of a regulatory process, a certificate of safety being granted only when the regulator is satisfied by the argument presented in a safety case. Industries regulated in this way include transportation (such as aviation, the automotive industry and railways) and medical devices. As such there are strong parallels with the formal evaluation of risk used to prepare a Risk Assessment, although the result will be case specific. A vehicle safety case may show it to be acceptably safe to be driven on a road, but conclude that it may be unsuited to driving on rough ground, or with an off-center load for example, if there would then be a greater risk of danger e.g. a loss of control or an injury to the occupant. The information used to compile the safety case may then formally guarantee further specifications, such as maximum safe speeds, permitted safe loads, or any other operational parameter. A safety case should be revisited when an existing product is to be re-purposed in a new way, if this extends beyond the scope of the original assessment.

Contents

Presenting a safety case

A safety case aims to show that specific safety claims are substantiated and, in the UK, that risks are kept 'As Low As Reasonably Practicable' (ALARP). In the US, the FDA issued a guidance document in 2010 to require infusion pump manufacturers to submit safety cases as part of the 510(k)s. [2]

A definition by UK Defence Standard 00-56 Issue 4 states: [3] Such an evidence-based approach can be contrasted with a prescriptive approach to safety certification, which require safety to be justified using a prescribed process. Such standards typically do not explicitly require an explicit argument for safety and instead rest on the assumption that following the prescribed process will generate the required evidence for safety. Many UK standards are non-prescriptive and call for an argument-based approach to justify safety, hence why a safety case is required.

Safety cases are typically documented in both textual and graphical notations, e.g. using the Goal Structuring Notation (GSN). [4]

Safety Cases are becoming more popular on civil/commercial aircraft and Department of Defense (DoD) weapon systems as complexity and criticality increase.[ citation needed ] A paradigm shift is often necessary to accept Safety Cases as traditional system safety and software safety analysis and verification approaches and processes are not adequately structured to present an effective safety argument on some more modern architectures using modern development tools and formal methods.

Some major programs in the US Department of Defense, such as the F-35[ weasel words ] Vehicle Management System (VMS) are using Model Based System Engineering (MBSE) effectively on highly complex, software intensive and safety-critical airborne system functions, along with Goal Structuring Notation (GSN). Safety Assessments and more elaborate and comprehensive Safety Cases with GSN are effective so long as Refuting Arguments and much scrutiny using traditional hazard analyses and safety approaches are included and models used to depict system behavior. More elaborate models and formal methods are being used for collective safety evidence. In the UK, GSN as part of Safety Cases have proven to be useful for providing objective safety evidence.[ citation needed ] A Safety Case is an ideal way to reflect the MBSE model, software use cases, safety architecture, safety critical functional behavior, safe states, and sequencing in the safety domain. Functional behavior is often better understood, expressed and defended when graphically displayed every step of the way in MBSE vs. traditional development with enormous paperwork that is very difficult to correlate into an effective Safety Case.

The SAE International G-48 System Safety Committee held The Safety Case Workshop at APT Research in Huntsville, AL on 15 January 2014 with several DoD agencies and leading contractors present to further study and capture the Safety Case process and methods for refinement and possible future promulgation in several Safety Standards, [5] as several already use as part of internal best practices. "There is now increasing evidence that some organizations in the U.S. are moving in the safety case direction."[ weasel words ] [6] The G-48, composed of a NASA safety Office, DoD Agencies and several leading defense contractor representatives, cite several evidence based safety advantages of Safety Cases over ANSI/GEA-STD-010 and MIL-STD-882, including 1. Upfront articulation of Arguments (rationale and claims) to be used and (2) independent review to verify and validate. Since Safety Cases are structured, evidence based approaches to satisfy the safety argument established at the start of programs, they may find a good fit in augmenting existing and proven hazard analyses methods and techniques. It is envisioned as Safety Cases gain popularity and are included in current best practices they will not replace any current effective safety methods, such as Functional Hazard Assessments (FHA), but may be included in those up front and in more comprehensive and blended safety methodologies to argument and improve capturing and documenting objective safety evidence through the program. A final Safety Case should have all of the necessary and required specific artifacts such as test evidence supporting safety claims. A well balanced Safety Case must also allow for special safety directed verification, such as testing of credible failure conditions, testing of malfunctions to observe predicted safe states and planned behavior, fault insertion for expected functionality under worse case conditions, failure immunity to ensure system ignores corruption and rogue threats, and off nominal or modified conditions, out of bounds, and other type test results to prove safety requirements are met outside normal operation.

Ideally, future Safety Case concepts, that are evolving as software intensive and high technology systems of systems gets more complex, must contain a focused data package with comprehensive safety artifacts and must be inclusive of all safety analyses, findings and determination of total summation of system risk. Safety Cases must go beyond the current MIL-STD-882 Safety Assessment Reports that are more general summary of hazard and risk based findings. Safety Cases with structured arguments, goals and objectives need to be more inclusive of various modern safety aspects, usually including requirements based safety (INCOSE), model based safety, software based safety (IEEE STD-1228), function based safety (IEC-61508, design based aerospace recommended practices for safety (SAE ARP 4761/4754A). [ citation needed ]

Agile development methods have been applied to safety case production. [7]

The review of safety cases is an important activity in the safety engineering process, performed throughout development, operation and maintenance, in which the safety case argument and evidence are scrutinized and challenged.

Related Research Articles

<span class="mw-page-title-main">Risk management</span> Identification, evaluation and control of risks

Risk management is the identification, evaluation, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.

<span class="mw-page-title-main">Safety engineering</span> Engineering discipline which assures that engineered systems provide acceptable levels of safety

Safety engineering is an engineering discipline which assures that engineered systems provide acceptable levels of safety. It is strongly related to industrial engineering/systems engineering, and the subset system safety engineering. Safety engineering assures that a life-critical system behaves as needed, even when components fail.

<span class="mw-page-title-main">Safety-critical system</span> System whose failure would be serious

A safety-critical system (SCS) or life-critical system is a system whose failure or malfunction may result in one of the following outcomes:

<span class="mw-page-title-main">Hazard analysis and critical control points</span> Systematic preventive approach to food safety

Hazard analysis and critical control points, or HACCP, is a systematic preventive approach to food safety from biological, chemical, and physical hazards in production processes that can cause the finished product to be unsafe and designs measures to reduce these risks to a safe level. In this manner, HACCP attempts to avoid hazards rather than attempting to inspect finished products for the effects of those hazards. The HACCP system can be used at all stages of a food chain, from food production and preparation processes including packaging, distribution, etc. The Food and Drug Administration (FDA) and the United States Department of Agriculture (USDA) require mandatory HACCP programs for juice and meat as an effective approach to food safety and protecting public health. Meat HACCP systems are regulated by the USDA, while seafood and juice are regulated by the FDA. All other food companies in the United States that are required to register with the FDA under the Public Health Security and Bioterrorism Preparedness and Response Act of 2002, as well as firms outside the US that export food to the US, are transitioning to mandatory hazard analysis and risk-based preventive controls (HARPC) plans.

Failure mode and effects analysis is the process of reviewing as many components, assemblies, and subsystems as possible to identify potential failure modes in a system and their causes and effects. For each component, the failure modes and their resulting effects on the rest of the system are recorded in a specific FMEA worksheet. There are numerous variations of such worksheets. An FMEA can be a qualitative analysis, but may be put on a quantitative basis when mathematical failure rate models are combined with a statistical failure mode ratio database. It was one of the first highly structured, systematic techniques for failure analysis. It was developed by reliability engineers in the late 1950s to study problems that might arise from malfunctions of military systems. An FMEA is often the first step of a system reliability study.

Reliability engineering is a sub-discipline of systems engineering that emphasizes the ability of equipment to function without failure. Reliability describes the ability of a system or component to function under stated conditions for a specified period of time. Reliability is closely related to availability, which is typically described as the ability of a component or system to function at a specified moment or interval of time.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

In functional safety, safety integrity level (SIL) is defined as the relative level of risk-reduction provided by a safety instrumented function (SIF), i.e. the measurement of the performance required of the SIF.

A hazard analysis is used as the first step in a process used to assess risk. The result of a hazard analysis is the identification of different types of hazards. A hazard is a potential condition and exists or not. It may, in single existence or in combination with other hazards and conditions, become an actual Functional Failure or Accident (Mishap). The way this exactly happens in one particular sequence is called a scenario. This scenario has a probability of occurrence. Often a system has many potential failure scenarios. It also is assigned a classification, based on the worst case severity of the end condition. Risk is the combination of probability and severity. Preliminary risk levels can be provided in the hazard analysis. The validation, more precise prediction (verification) and acceptance of risk is determined in the risk assessment (analysis). The main goal of both is to provide the best selection of means of controlling or eliminating the risk. The term is used in several engineering specialties, including avionics, food safety, occupational safety and health, process safety, reliability engineering.

<span class="mw-page-title-main">ARP4761</span>

ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment is an Aerospace Recommended Practice from SAE International. In conjunction with ARP4754, ARP4761 is used to demonstrate compliance with 14 CFR 25.1309 in the U.S. Federal Aviation Administration (FAA) airworthiness regulations for transport category aircraft, and also harmonized international airworthiness regulations such as European Aviation Safety Agency (EASA) CS–25.1309.

IEC 61508 is an international standard published by the International Electrotechnical Commission (IEC) consisting of methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.

In software engineering, software system safety optimizes system safety in the design, development, use, and maintenance of software systems and their integration with safety-critical hardware systems in an operational environment.

The system safety concept calls for a risk management strategy based on identification, analysis of hazards and application of remedial controls using a systems-based approach. This is different from traditional safety strategies which rely on control of conditions and causes of an accident based either on the epidemiological analysis or as a result of investigation of individual past accidents. The concept of system safety is useful in demonstrating adequacy of technologies when difficulties are faced with probabilistic risk analysis. The underlying principle is one of synergy: a whole is more than sum of its parts. Systems-based approach to safety requires the application of scientific, technical and managerial skills to hazard identification, hazard analysis, and elimination, control, or management of hazards throughout the life-cycle of a system, program, project or an activity or a product. "Hazop" is one of several techniques available for identification of hazards.

A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.

Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, systematic errors, hardware failures and operational/environmental stress.

ISO 26262, titled "Road vehicles – Functional safety", is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles, defined by the International Organization for Standardization (ISO) in 2011, and revised in 2018.

Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety for Road Vehicles standard. This is an adaptation of the Safety Integrity Level (SIL) used in IEC 61508 for the automotive industry. This classification helps defining the safety requirements necessary to be in line with the ISO 26262 standard. The ASIL is established by performing a risk analysis of a potential hazard by looking at the Severity, Exposure and Controllability of the vehicle operating scenario. The safety goal for that hazard in turn carries the ASIL requirements.

Goal structuring notation (GSN) is a graphical diagram notation used to show the elements of an argument and the relationships between those elements in a clearer format than plain text. Often used in safety engineering, GSN was developed at the University of York during the 1990s to present safety cases. The notation gained popularity as a method of presenting safety assurances but can be applied to any type of argument and was standardized in 2011. GSN has been used to track safety assurances in industries such as clinical care aviation, automotive, rail, traffic management and nuclear power and has been used in other contexts such as security cases, patent claims, debate strategy, and legal arguments.

The Auditory Hazard Assessment Algorithm for Humans (AHAAH) is a mathematical model of the human auditory system that calculates the risk to human hearing caused by exposure to impulse sounds, such as gunfire and airbag deployment. It was developed by the U.S. Army Research Laboratory (ARL) to assess the effectiveness of hearing protection devices and aid the design of machinery and weapons to make them safer for the user.

Human Systems Integration (HSI) is an interdisciplinary managerial and technical approach to developing and sustaining systems which focuses on the interfaces between humans and modern technical systems. The objective of HSI is to provide equal weight to human, hardware, and software elements of system design throughout systems engineering and lifecycle logistics management activities across the lifecycle of a system. The end goal of HSI is to optimize total system performance and minimize total ownership costs. The field of HSI integrates work from multiple human centered domains of study include training, manpower, personnel, human factors engineering, safety, occupational health, survivability and habitability.

References

  1. ↑ Defence Standard 00-56 Issue 4 (Part 1): Safety Management Requirements for Defence Systems. UK Ministry of Defence. p. 17.
  2. ↑ FDA: Medical Devices.
  3. ↑ "Safety Management Requirements for Defence Systems: Part 2: Guidance on Establishing a Means of Complying with Part I" (PDF). Ministry of Defence. June 1, 2007. Archived from the original (PDF) on December 15, 2017.
  4. ↑ GSN Community Standard
  5. ↑ "Safety Case Workshop" (PDF). A-P-T Research. January 14–15, 2014. Archived from the original (PDF) on December 15, 2017.
  6. ↑ Journal of System Safety, Volume 51, No.1 Winter 2015 on page 19
  7. ↑ Myklebust, T.; Stålhane, T. (September 2016). "The Agile Safety Case". Trondheim: SafeComp.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.