Safety case

From Wikipedia, the free encyclopedia

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.

Presenting a safety case[edit]

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.


  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.

External links[edit]