[SystemSafety] NYTimes: The Next Accident Awaits (Simon P.P. Whiteley)
Simon Whiteley
simon at whiteley-safety.co.uk
Mon Feb 3 21:21:57 CET 2014
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 whiteley-safety.co.uk
____________________________________________________________________________
______________
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 lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
systemsafety-request at lists.techfak.uni-bielefeld.de
Sent: 03 February 2014 16:32
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: systemsafety Digest, Vol 19, Issue 19
Send systemsafety mailing list submissions to
systemsafety at lists.techfak.uni-bielefeld.de
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 lists.techfak.uni-bielefeld.de
You can reach the person managing the list at
systemsafety-owner at lists.techfak.uni-bielefeld.de
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 rvs.uni-bielefeld.de>
To: "systemsafety at techfak.uni-bielefeld.de"
<systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits
Message-ID: <52EFBA7F.8060502 at rvs.uni-bielefeld.de>
Content-Type: text/plain; charset=ISO-8859-1
I must say I am puzzled by this discussion.
A. 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).
B. 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 sagem.com>
To: Peter Bernard Ladkin <ladkin at rvs.uni-bielefeld.de>,
"systemsafety at techfak.uni-bielefeld.de"
<systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits
Message-ID:
<6FC2A47F1B2CCC4C804736A81522E8304D86F99767 at Y000IMRV02.rd1.rf1>
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 sagem.com
-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Peter Bernard Ladkin
Sent: Monday, February 03, 2014 4:49 PM
To: systemsafety at techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits
I must say I am puzzled by this discussion.
A. 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).
B. 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 TechFak.Uni-Bielefeld.DE
#
" 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 knosof.co.uk>
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits
Message-ID: <52EFC03D.5080005 at knosof.co.uk>
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 york.ac.uk>
To: Derek M Jones <derek at knosof.co.uk>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] NYTimes: The Next Accident Awaits
Message-ID:
<CAE4faLL7diPPsrn9X5P8u8gODP9kW4NFzveHVmmCmqZzjCv9_w at mail.gmail.com>
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 knosof.co.uk> wrote:
> 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 TechFak.Uni-Bielefeld.DE
>
-------------- 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 lists.techfak.uni-bielefeld.de
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
End of systemsafety Digest, Vol 19, Issue 19
********************************************
More information about the systemsafety
mailing list