[SystemSafety] Safety Cases

[nfr]

Sorry for any confusion. My aim wasn't to define "hazard ID" or "safety", merely to propose, as a generalisation, that the purpose of a safety case (as defined in the '80s) is to show why what could breach safety won't do so.
What safety analysts and engineers consider appropriate to include in a safety case in any particular instance is for their determination in that instance. They may, for example, consider it appropriate to address the possibilities of lead fumes, generated by flaking paint, if employees have to work for long periods in a small, confined, poorly ventilated space. But I was trying to make a simpler point than that.

I had the impression that, in the recent prolific exchange of emails, different participants in the discussion were basing their comments on different notions of what a safety case is, or is intended to achieve.
So I thought that pointing to a general expression of a safety case's purpose might be useful to some. And expanding this into the three questions should facilitate a quick mental analysis of what is required in order to produce a thorough, persuasive safety case. 
Taking the mind away from specific, limited definitions might just help combatants to argue about the same thing.

Felix.


On 11 Feb 2014, at 00:59, Tracy White wrote:

> Felix
> 
> I agree in the broad sense, but ‘unsafeness’ doesn’t come purely from ‘hazards’. Unsafeness also comes from poor or substandard engineering, but I would not wish to see a ream of hazard associated with deficient engineering solutions. I have been on a project where somebody wanted a hazard log entry for ‘using the wrong steel’ and ‘using the wrong colour paint’ but listing these types of ‘engineering’ failures as ‘hazards’ would be impractically and frankly ludicrously open ended.
> 
> This is why I believe it is more sensible and ‘complete’ to talk in terms of ‘systems and safety assurance’ which would extent the argument to, in addition to the explicit safety (hazard) issues, talk about the ‘good system engineering’ process and activities including appropriate competency, oversight and approvals/authorities etc. So ‘wrong’ in this sense derives from both ‘hazards’ (the safety program) and deficient engineering processes (the engineering program).
> 
> Tracy
> 
> 
> 
>> On 11 Feb 2014, at 10:09, nfr <felix.redmill at newcastle.ac.uk> wrote:
>> 
>> Michael,
>> 
>> In addressing safety, "wrong" equals "unsafe". And to determine what might be, or might become, unsafe, we need to identify the hazards.
>> 
>> What is right, in that context, is what is deemed not to be unsafe.
>> 
>> Felix.
>> 
>> 
>>> On 10 Feb 2014, at 11:43, Michael Jackson wrote:
>>> 
>>> Felix:
>>> 
>>> Yes. But surely there is a missing prior question here:
>>> 
>>> 0. What constitutes going right?
>>> 
>>> How can we discuss 'going wrong' without a clear understanding of 'going right'?
>>> Yet in much discussion of safety this question seems to be relegated to a tacit
>>> background understanding.
>>> 
>>> -- Michael Jackson
>>> 
>>> 
>>> At 11:19 10/02/2014, nfr wrote:
>>> 
>>>> In the 1980s, 'the safety case' was defined as having the purpose of answering three questions:
>>>> 
>>>> 1. What could [possibly] go wrong?
>>>> 
>>>> 2. Why won't it?
>>>> 
>>>> 3. But what if it did?
>>>> 
>>>> One or two of you might propose that each of these questions could be answered by a single sentence. But, with a bit of thought, you'll recognise that, in order to answer the questions fully, a great deal of evidence must be adduced, from a great deal of work - from complete and correct specification, through thorough design, hazard ID, risk assessment, etc., to emergency planning.
>>>> 
>>>> Felix.
>>>> _______________________________________________
>>>> The System Safety Mailing List
>>>> systemsafety at TechFak.Uni-Bielefeld.DE
>> 
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE