[SystemSafety] NYTimes: The Next Accident Awaits

Tue Feb 4 04:07:46 CET 2014

https://law.resource.org/pub/bg/ibr/bds.en.50129.2003.pdf

From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Nancy Leveson
Sent: Tuesday, February 4, 2014 10:43 AM
To: Andrew Rae
Cc: <systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits

Drew,

I took quotes from the standards in the UK and some in Australia. Except for the last abstract, they were simply the first 15 references that came up when I googled "safety case" and "safety case regime." There are some differences, but none of them are using the term as just another way of saying "the activities of safety engineers." While certainly anyone can make up and use any definition for any term they want, it does not help in communication to do so. It would be best to create a new term rather than use a term that has been defined for decades and is widely used to have a specific meaning..

All

The European Committee for Electrotechnical Standardization's concept of a safety case is described in some detail in EN 50129:2003 here:

https://law.resource.org/pub/bg/ibr/bds.en.50129.2003.pdf

 I complied with the 1998 version of this standard. It hasn't changed much. Modern wisdom (which I heartily support) is that one should progressively collect the required evidence of safety as a project progresses. As it turned out I did not have this luxury. The exercise turned out to be roughly four man months work. 

On a personal level, at the start, it was a daunting prospect. Felix Redmil dropped by and I asked him if he had any words for me. Something I might be able to cut and paste. He quite rightly indicated that each safety case is specific to the application and demurred. 

In the end completing this document made me, and I think many others on the project feel good about ourselves. A hell of a lot of work had been done and we did have the evidence. For example, I could go back two years and find records of review. This was, from the safety perspective, the culmination of a happy project - thanks to the company culture, an inspired project manager and a sophisticated and reasonable customer. When I say culture I mean that we demonstrated by our actions and our deliverables that we were committed to safety. This was not lost on the customer who may or may not have analysed the safety case in detail. If he did he would have recognised elements of evidence that he was very familiar with. The safety program was visible to the customer throughout the project.

This has been a long conversation about safety cases. I hope it continues. The fundamental point I would like to make is that, at this stage of our development, because software intensive system development remains knowledge work which is largely invisible and massively complex the only way to effectively deliver a safe system is to have people committed to safety doing the work. And to have methods of gaining visibility into that commitment. A safety case document is one window into this commitment. 

I'd be interested in any comments.

Les

On Mon, Feb 3, 2014 at 7:21 PM, Andrew Rae <andrew.rae at york.ac.uk> wrote:

Nancy,
I think for fairness it is necessary to point out that many of those quotes are commentary on different regimes, and no regime would match the detail on all of them. That last abstract is a blatant mis-characterisation by someone who _really_ doesn't understand an ALARP regime. 

The fundamental point you were making is sound. A goal based regulation (which is really what safety cases are intended for) is not just an umbrella over prescription. You can make a safety argument over the top of evidence generated by prescription but that, whilst technically a safety case, is a different beast from selecting your own evidence in support of a regulated goal.

Complex QRA is not a safety case thing, though, as some of the quotes suggest.  It is used as much if not more in prescriptive environments. Likewise workforce involvement, confidentiallity and focus on operations are not inherently safety case related. 

Different people clearly have different pictures in mind when discussing this. I understand you don't want to get drawn into a debate - the price of that may be letting people argue using terms differently from how you would yourself. 

Cheers,
Drew 

On 3 Feb 2014 23:27, "Nancy Leveson" <leveson.nancy8 at gmail.com> wrote:

I said I would withdraw but I am so amazed by this discussion that I thought I would at least try to bring some facts into it. The communication problems here seem to devolve from misunderstandings about: 

    1. The definition of a safety case. Many people here seem to be using "safety case" as simply a synonym for any evidence generated that involves safety. This is not the standard definition of a safety case. 

    2. The definition of a "safety case regime." Note that I tried to use this phrase in my messages, but sometimes I forgot. But this is a regulatory approach that started in the UK after the Piper Alpha accident. It also is widely used in Australia. Not so much in the U.S. There was a lot of controversy about the safety case regime in the U.S. after Deepwater Horizon. Much of the discussion involved lawyers and environmentalists, not engineers. I have included an abstract that will give you the idea at the end of this message. 

    3. Safety cases and safety case regulatory regimes are mostly used in health and safety of workers, not in engineering development (although it is occasionally used that way). Note below that the work force must be involved in the safety case according to the U.K. standards -- they are talking about operations safety.

Here are some quotes I pulled from the web. Everything in italics was not written by me. The bold-faced, non-italicized sentences were written by me. Most of the quotes below refer to U.K. standards and practices because the U.S. and most other countries do not use a safety-case regime except in a very limited way:

Safety cases are basically non-prescriptive and performance based - in the same manner as for process safety management programs onshore. Instead of following detailed rules, the owner (duty holder) of the facility set his or her own standards. The duty-holder's performance is then assessed against that standard.

A safety case regime is an objective-based regime whereby legislation sets broad safety objectives and the operator, who accepts direct responsibility for the ongoing management of safety, develops the most appropriate methods to achieve those objectives.

[Nancy: An example of a goal-based (performance-based) safety requirement in aviation is that "The aircraft navigation system must be able to estimate its position to within a circle with a radius of 10 nautical miles with some specified probability." Another example comes from the international standard for new aircraft in-trail procedure (ITP) equipment “The likelihood that the ITP equipment provides undetected erroneous information about accuracy and integrity levels of own data shall be less than 1E-3 per flight hour” [RTCA, 2008]. While some safety requirements (like these examples) in the aviation industry are starting to be stated as goal-based, it is a rather recent phenomenon. The majority of certification in aviation is prescriptive. One big problem, of course, is how to prove that the probabilities will be satisfied, i.e., that the goal will be achieved.]

A definition by UK Defence Standard 00-56 Issue 4 states:[1] <http://en.wikipedia.org/wiki/Safety_case#cite_note-1>  … an evidence-based approach [that] 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.

The  Offshore Installations (Safety Case) Regulations 2005 aims to reduce the risks from major accident hazards to the health and safety of the workforce employed on offshore installations, and in connected activities. The regulations implement the main recommendations of Lord Cullen's Report of the Public Inquiry into the Piper Alpha Disaster.

Australia Offshore Petroleum and Greenhouse Gas Storage (Safety) Regulations:

Objective based (or goal setting) regimes, including the safety case regime, are based on the principle that the legislation sets the broad safety goals to be attained and the operator of the facility develops the most appropriate methods of achieving those goals. A basic tenet is the premise that the ongoing management of safety is the responsibility of the operator and not the regulator.

Often used in environmental health and safety and the operation of a facility, not the engineering development.

The important features of a safety case regime, are that it must have (1) a risk/ hazard framework, (2) there must be workforce involvement, (3) you must be required to make the case to a regulator, (4) the regulator must be engaged, and (5) there must be a requirement of duty of care, he said.

A safety case is built upon the following three principles. 

1.	Those who create risks are responsible for controlling those risks. 
2.	Safe operations are achieved by setting and achieving goals rather than by following prescriptive rules.
3.	All risks must be reduced such that they are below a threshold of acceptability. 

First, the company that owns and operates a platform has "to assure itself" that the facility is safe. At root, a safety case is developed for the facility personnel and company management - not for outside parties. A safety case is not fundamentally a regulatory tool - although it is often used by regulators. For example, operators of large and expensive deepwater facilities in the Gulf of Mexico (GoM) frequently develop analyses and reports which are very similar to safety cases. They do this - in spite of the lack of regulatory requirements - simply to assure themselves that they have identified the factors that could lead to the loss of their very expensive facilities. 

Safety cases are basically non-prescriptive and performance based - in the same manner as for process safety management programs onshore. Instead of following detailed rules, the owner (duty holder) of the facility set his or her own standards. The duty-holder's performance is then assessed against that standard.

A safety case regime is an objective-based regime whereby legislation sets broad safety objectives and the operator, who accepts direct responsibility for the ongoing management of safety, develops the most appropriate methods to achieve those objectives.

[Nancy: Here is an example of a paper, actually just the abstract, by a U.S. law professor that describes the controversy in the U.S. I can send her paper if you are interested although you should be able to find it on the web. I got pulled into this controversy because of my role in the Deepwater Horizon accident report and a DOE advisory committee I was on after the accident. Rena and I wrote a newspaper opinion piece about the safety case approach.]

Lessons from the North Sea January 6, 2011 Copyright 2010 by Rena Steinzor 1 

 Lessons from the North Sea: Should “Safety Cases” Come to America? 

By Rena Steinzor∗ 

ABSTRACT: The catastrophic oil spill in the Gulf of Mexico last spring and summer has triggered a frantic search for more effective regulatory methods that would prevent such disasters. The new Bureau of Ocean Energy Management, Regulation, and Enforcement (BOEMRE) is under pressure to adopt the British “safety case” system, which requires the preparation of a facility-specific safety plan that is typically several hundred pages long. This regulatory scheme is described as a “goal oriented” approach that inculcates a “safety culture” within companies that operate offshore in the British portion of the North Sea because it overcomes a “box-ticking” mentality and constitutes “bottom up” implementation of safety measures. Safety cases are strictly confidential: only company officials, regulators and, in limited circumstances, worker representatives, are allowed to see the entire plan. This paper argues that the safety case approach should not come to America because this confidentiality and the risk levels tolerated by the British system conflict with the both the spirit and the letter of American law. 

British regulations allow the plans to be no more protective than preventing one in 1,000 worker deaths and require operators to spend no more than $1.5 million per life saved. These standards are far more lax than comparable American legal requirements. The use of quantitative risk assessment and cost benefit analysis within the plans means that they must be prepared by technical experts far removed from an oil rig, suggesting that safety cases are not “bottom up” vehicles for ensuring best operational practice. The U.S. now fields only 55-60 inspectors to cover 3,500 facilities in the Gulf. To be even minimally effective, a safety case regime would require increasing available overseers by orders of magnitude, a prospect that is unlikely given the political climate in Washington. Lastly, a British study of conditions in the North Sea suggest alarming neglect of the physical infrastructure that ensures safety, further undermining claims that the safety case system is as effective as its advocates claim. 

This paper was presented at a symposium organized by the Boston College Environmental Affairs Law Review and will be published in any upcoming issue of that publication. Comments should be addressed to rsteinzor at law.umaryland.edu.

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

-- 
Prof. Nancy Leveson
Aeronautics and Astronautics and Engineering Systems
MIT, Room 33-334
77 Massachusetts Ave.
Cambridge, MA 02142

Telephone: 617-258-0505
Email: leveson at mit.edu
URL: http://sunnyday.mit.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20140204/543ac89c/attachment-0001.html>