Re: [SystemSafety] NYTimes: The Next Accident Awaits

From: Andrew Rae < >
Date: Mon, 3 Feb 2014 16:31:33 +0000


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 >



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Feb 03 2014 - 17:31:47 CET

This archive was generated by hypermail 2.3.0 : Sat Feb 16 2019 - 18:17:06 CET