Re: [SystemSafety] NYTimes: The Next Accident Awaits (Simon P.P. Whiteley)

From: Simon Whiteley < >
Date: Mon, 3 Feb 2014 20:21:57 -0000

Hi everyone,

There's some interesting discussion going on here.

I just wanted to added that, for those who may not be aware, Systems Theoretic Accident Modelling and Processes (STAMP) is highlighted by UK MOD Military Aviation Authority (MAA) as an "available technique" within their " GEN 1000 SERIES- REGULATORY ARTICLES" "RA 1210 - Ownership and Management of Operating Risk (Risk to Life)", p. 13, located at:

http://www.maa.mod.uk/linkedfiles/regulation/1000_series/ra1210.pdf

Kindest Regards,

Simon P.P. Whiteley BEng (Hons) MSc MRAeS DIRECTOR
 
M: +44(0) 7899 754090

E: simon_at_xxxxxx
____________________________________________________________________________
______________

Whiteley Aerospace Safety Engineering & Management Limited Registered Office: Delta 606, Welton Road, Swindon, Wiltshire, England SN5 7XF, UK
Registered in England & Wales No: 6785948 VAT Registration No: 943 9340 07

-----Original Message-----
From: systemsafety-bounces_at_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx systemsafety-request_at_xxxxxx Sent: 03 February 2014 16:32
To: systemsafety_at_xxxxxx Subject: systemsafety Digest, Vol 19, Issue 19

Send systemsafety mailing list submissions to

        systemsafety_at_xxxxxx

To subscribe or unsubscribe via the World Wide Web, visit

        https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety or, via email, send a message with subject or body 'help' to

        systemsafety-request_at_xxxxxx

You can reach the person managing the list at

        systemsafety-owner_at_xxxxxx

When replying, please edit your Subject line so it is more specific than
"Re: Contents of systemsafety digest..."

Today's Topics:

  1. Re: NYTimes: The Next Accident Awaits (Peter Bernard Ladkin)
  2. Re: NYTimes: The Next Accident Awaits (RICQUE Bertrand (SAGEM DEFENSE SECURITE))
  3. Re: NYTimes: The Next Accident Awaits (Derek M Jones)
  4. Re: NYTimes: The Next Accident Awaits (Andrew Rae)

Message: 1
Date: Mon, 03 Feb 2014 16:49:19 +0100
From: Peter Bernard Ladkin <ladkin_at_xxxxxx To: "systemsafety_at_xxxxxx

        <systemsafety_at_xxxxxx Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits Message-ID: <52EFBA7F.8060502_at_xxxxxx Content-Type: text/plain; charset=ISO-8859-1

I must say I am puzzled by this discussion.

  1. To me, a safety case is some joined-up set of documents which purport to demonstrate that a system taken as an entity is adequately safe (whatever that is taken to be) when it's operating, and also when it's sitting around not operating (such as systems which involve radioactive and poisonous substances).
  2. The contrast is a regime in which Subsystem-X-supervisor Bill "signs off" that Subsystem X is, as far as Bill is concerned, OK, and the system is rendered operational by a hierarchical series of signatures, without necessarily any or much supporting documentation. That's the way things used to be done (Windscale, Piper Alpha).

As far as I know, Lord Cullen popularised the term "safety case" for the situation described in A, and contrasted it with the status quo, which was B, in his inquiries into major accidents.

So, for Nancy to praise aerospace certification as effective, and to denigrate safety cases as ineffective seems to me almost like a contradiction in terms. The FAA and the various European agencies are pioneers in requiring and collecting joined-up documentation that the bits all do what they should do, and the collections of bits also do what you expect of the collection, and so on.

I presume it's not that simple; that Nancy means by "safety case" something more subtle and detailed and constraining, and as far as I am concerned she is welcome, indeed encouraged, to reject subtle and constraining regimes as much as it is appropriate to do so. But to reject safety cases in the sense of A above as required by the FAA, EASA, IEC 61508, IEC 61511 and almost all the other standards promulgated by the IEC would seem to me to be nuts.

Being too subtle about safety cases, that is, more subtle than A, I would suggest is counterproductive. I am involved with two large industry segments that pay lip service to A but which in fact promulgate regime B at every available opportunity: "we don't need <material such as required by A> - we have our methods and our experience and we are good at what we do", except they are bringing in new technology and there is no such history as they wish to claim. The big political action here is still to try to prevail with
"A, not B". Still. A quarter century after Piper Alpha and Kings Cross.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de


Message: 2
Date: Mon, 3 Feb 2014 17:10:44 +0100
From: "RICQUE Bertrand (SAGEM DEFENSE SECURITE)"

        <bertrand.ricque_at_xxxxxx

To: Peter Bernard Ladkin <ladkin_at_xxxxxx
	"systemsafety_at_xxxxxx
	<systemsafety_at_xxxxxx
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits Message-ID:

        <6FC2A47F1B2CCC4C804736A81522E8304D86F99767_at_xxxxxx Content-Type: text/plain; charset="iso-8859-1"

I think there is a lot of fuzziness with the vocabulary and according to the different industry sectors. Words, like performance, prescription, certification, qualification, regulation have not the same meaning in aerospace, railway, medical device, food and drugs, defence, process industries. They have also not the same meaning in different countries. They also have different applicability according to the industrial culture. Some examples.
In the context of machinery, a certification is for a type of product or machine. It can be made by an independent (institutional) third party or by the manufacturer as self certification. A prescription is close from a predefined list of components associated with a predefined list of architectures that shall be blindly applied. This has nothing to see with prescription of methods, or prescription of results.

Sometimes the prescribed method is to realise a safety case among other things !

Some rules whatever issued by regulatory agencies, or relevant of a safety case constitution might well suit a simple industrial culture (close a pipe with a single effect valve and a single feedback) and be meaningless for other culture (use a motorised valve with 7 feedbacks, 3 commands and 8 interlocks).

In addition the safety culture is very heterogeneous across industry standards. You still have whole industries not understanding what is the point with analysing the failure modes of a safety system ...

As Nancy pointed out, comparison is very difficult.

My opinion is that all the pitfalls pointed by Nancy are pretty true but that this should not hold us from having both safety cases (as a part of a methodology, and I don't' discuss if it is the best, it has the merit of existing) and regulation as a mean of enforcement.

No driver starts driving with intention to kill, however nobody imagine living without traffic police.

No industrial company starts a plant with the intention to kill, and I don't imagine living without industry police.

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 59 11 96 82
Bertrand.ricque_at_xxxxxx

-----Original Message-----
From: systemsafety-bounces_at_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx Peter Bernard Ladkin
Sent: Monday, February 03, 2014 4:49 PM
To: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits

I must say I am puzzled by this discussion.

  1. To me, a safety case is some joined-up set of documents which purport to demonstrate that a system taken as an entity is adequately safe (whatever that is taken to be) when it's operating, and also when it's sitting around not operating (such as systems which involve radioactive and poisonous substances).
  2. The contrast is a regime in which Subsystem-X-supervisor Bill "signs off" that Subsystem X is, as far as Bill is concerned, OK, and the system is rendered operational by a hierarchical series of signatures, without necessarily any or much supporting documentation. That's the way things used to be done (Windscale, Piper Alpha).

As far as I know, Lord Cullen popularised the term "safety case" for the situation described in A, and contrasted it with the status quo, which was B, in his inquiries into major accidents.

So, for Nancy to praise aerospace certification as effective, and to denigrate safety cases as ineffective seems to me almost like a contradiction in terms. The FAA and the various European agencies are pioneers in requiring and collecting joined-up documentation that the bits all do what they should do, and the collections of bits also do what you expect of the collection, and so on.

I presume it's not that simple; that Nancy means by "safety case" something more subtle and detailed and constraining, and as far as I am concerned she is welcome, indeed encouraged, to reject subtle and constraining regimes as much as it is appropriate to do so. But to reject safety cases in the sense of A above as required by the FAA, EASA, IEC 61508, IEC 61511 and almost all the other standards promulgated by the IEC would seem to me to be nuts.

Being too subtle about safety cases, that is, more subtle than A, I would suggest is counterproductive. I am involved with two large industry segments that pay lip service to A but which in fact promulgate regime B at every available opportunity: "we don't need <material such as required by A> - we have our methods and our experience and we are good at what we do", except they are bringing in new technology and there is no such history as they wish to claim. The big political action here is still to try to prevail with
"A, not B". Still. A quarter century after Piper Alpha and Kings Cross.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de



The System Safety Mailing List
systemsafety_at_xxxxxx #
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles, ?tre soumis aux r?glementations relatives au contr?le des exportations ou ayant un caract?re priv?. S'ils ne vous sont pas destin?s, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque mani?re que ce soit le contenu. Toute exportation ou r?exportation non autoris?e est interdite Si ce message vous a ?t? transmis par erreur, merci d'en informer l'exp?diteur et de supprimer imm?diatement de votre syst?me informatique ce courriel ainsi que tous les documents qui y sont attach?s."

" This e-mail and any attached documents may contain confidential or
proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #

Message: 3
Date: Mon, 03 Feb 2014 16:13:49 +0000
From: Derek M Jones <derek_at_xxxxxx To: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits Message-ID: <52EFC03D.5080005_at_xxxxxx Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Peter,

As a non-expert I am persuaded by Nancy's arguments.

> A. To me, a safety case is some joined-up set of documents which > purport to demonstrate that a

You are describing what a safety case should be. However, I can write any document I like and call it a "Safety Case".

The thrust of Nancy's argument, as I understand it, is that sufficiently expert reviewers who have the time to review documents are likely to be available (the count of people vs. oil rigs in UK and US was very interesting).

If company management are willing to cut corners, and write shoddy safety cases to save money, then without adequate review a "safety case" approach appears to be fatally flawed.

So far I have not seen arguments from anybody on this list that address this fundamental flaw.

-- 
Derek M. Jones                  tel: +44 (0) 1252 520 667
Knowledge Software Ltd          blog:shape-of-code.coding-guidelines.com
Software analysis               http://www.knosof.co.uk


------------------------------

Message: 4
Date: Mon, 3 Feb 2014 16:31:33 +0000
From: Andrew Rae <andrew.rae_at_xxxxxx
To: Derek M Jones <derek_at_xxxxxx
Cc: "systemsafety_at_xxxxxx
	<systemsafety_at_xxxxxx
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits
Message-ID:
	<CAE4faLL7diPPsrn9X5P8u8gODP9kW4NFzveHVmmCmqZzjCv9_w_at_xxxxxx
Content-Type: text/plain; charset="iso-8859-1"

Derek,
I don't think that one is actually Nancy's strongest objection to safety
cases. In reality, there are not so many different safety techniques in use
that we need regulation just to standardise which ones are being used. In
any event the ones we have aren't so good that we would even want to
discourage using improved methods. I'm not aware of any standard mandating
STPA for example (and there several that include lists of techniques that
_don't_ include STPA).

Regulator competence is a huge problem, but it exists independently of the
existence of safety cases. Any safety analysis is only as good as the
timeliness and quality of the review. Buncefield is a great example of an
accident where the safety report was never properly reviewed simply due to
lack of regulatory resource. The response, as best I can tell, has been to
reduce the officially required amount of regulatory review rather than to
beef up the regulatory resource.

The open question - and it is genuinely open - is whether adding an argument
on top of the evidence (which exists regardless of which approach you
follow) helps or hinders the regulator. Nancy has suggested that it leads
the regulator into following the same mindset as the people who present the
evidence, rather than performing an adversarial role (confirmation bias).
Others (including myself) have suggested that this is already a huge problem
in prescriptive regulation, and that an explicit argument is more likely to
reduce than encourage confirmation bias. It's an empirical question though -
it can't be resolved by argument, only by evidence. Any evidence is likely
to be domain and culture specific though, which rules out simply comparing
different current regulators or regulatory systems.

There is a separate specific issue to do with safety case notation. I am not
personally comfortable with the fact that there are not publicly accessible
exemplars of GSN safety cases, for example, but lots of stories which can
best be characterised as GSN nightmares. When you present someone with an
unfamiliar notation their eyes tend to glaze over, reducing their ability to
closely examine the detail. This is a competence issue - knowing what good
GSN looks like, and being confident enough when presented with unfamiliar
GSN to judge that it is wrong. I kind of doubt the ability of many people in
safety roles to do this with fault trees, hazard identification reports and
FMEAs, let alone adding a new arrow to the quiver of ignorance.

Drew

My system safety podcast: http://disastercast.co.uk My phone number: +44 (0)
7783 446 814 University of York disclaimer:
http://www.york.ac.uk/docs/disclaimer/email.htm


On 3 February 2014 16:13, Derek M Jones <derek_at_xxxxxx

> Peter,
>
> As a non-expert I am persuaded by Nancy's arguments.
>
>  A. To me, a safety case is some joined-up set of documents which 
> purport
>> to demonstrate that a
>>
>
> You are describing what a safety case should be.  However, I can write 
> any document I like and call it a "Safety Case".
>
> The thrust of Nancy's argument, as I understand it, is that 
> sufficiently expert reviewers who have the time to review documents 
> are likely to be available (the count of people vs. oil rigs in UK and 
> US was very interesting).
>
> If company management are willing to cut corners, and write shoddy 
> safety cases to save money, then without adequate review a "safety 
> case" approach appears to be fatally flawed.
>
> So far I have not seen arguments from anybody on this list that 
> address this fundamental flaw.
>
> --
> Derek M. Jones                  tel: +44 (0) 1252 520 667
> Knowledge Software Ltd          blog:shape-of-code.coding-guidelines.com
> Software analysis               http://www.knosof.co.uk
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachm
ents/20140203/471fd7dc/attachment.html>

------------------------------

_______________________________________________
systemsafety mailing list
systemsafety_at_xxxxxx
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety


End of systemsafety Digest, Vol 19, Issue 19
********************************************

_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Mon Feb 03 2014 - 21:22:10 CET

This archive was generated by hypermail 2.3.0 : Thu Apr 25 2019 - 03:17:06 CEST