[SystemSafety] NYTimes: The Next Accident Awaits

Andrew Rae andrew.rae at york.ac.uk
Mon Feb 3 17:31:33 CET 2014


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/attachments/20140203/471fd7dc/attachment-0001.html>


More information about the systemsafety mailing list