[SystemSafety] Safety Cases

[nfr]

Michael,

You're right, of course. A first priority and essential requirement is a correct and complete statement (specification) of functional requirements - defining what's "right". I guess that the safety-case "definition" that I quoted took that for granted.

I guess, too, that there's a risk of the fourth question, to which you pointed, leading to confusion as to what a safety case is for (confusion between safety and functional requirements). A safety case wouldn't normally be concerned with whether a car starts or not; market forces deals with such matters. But when a functional requirement could have safety implications, the safety case should identify it and its potential failure modes and consequences and show why the risk of unsafe failure is tolerable (you cite a breaking system as an example of this). 

Discovering (and analysing) what could "go wrong" (go unsafe) is the business of hazard analysis techniques, such as FMEA and HAZOP, which, for their effective application, require understanding of what is right. So, such understanding (knowledge?) is implicit in the definition. (But its requirement makes it just as valid to include your fourth question as to assume it).

Best,
Felix.



On 11 Feb 2014, at 10:32, Michael Jackson wrote:

> Felix:
> 
> Yes, of course: I was adding a simplified question to the set of simplified questions you cited. But I think there is a useful related distinction to be made.
> 
> A system has an intended functional behaviour satisfying a set of 'positive' requirements: "When I press the footbrake the car slows down," and "When the current flow is excessive the circuit breaker trips." These are positive, just like "When I turn the steering wheel the car turns" and "When the ignition switch is turned on the motor starts." There is some (quite large) set of events, states, etc embodying this behaviour: let's call it the alphabet of the functional design. When the car is properly designed, maintained, and operated, it 'goes right' in the sense that an observer who observes only elements of the alphabet will see that the functional behaviour is as intended.
> 
> The first kind of safety concern arises directly from some failure to exhibit the intended functional behaviour: "I pressed the brake but the car didn't slow down (so I ran into the car ahead)." "The current flow exceeded the threshold but the circuit breaker didn't trip (so the cable caught fire)." These safety concerns arise when "something goes wrong": what goes wrong (but not, in general the resulting mishap) is fully expressible in the functional design alphabet. If a serious accident results the investigators determine what should have "gone right" but in fact "went  wrong". Knowing "What constitutes going right" allows them to examine what "went wrong" and identify the causes.
> 
> The second kind of safety concern arises from circumstances expressible only in a larger alphabet. The road collapses in front of the car; a tree falls on the car; the car is rammed from behind and the fuel tank explodes; the exhaust system is damaged by impact of a flyng stone and poisonous fumes leak into the cabin; a child left alone in the car contrives to start it and cause a crash. The alphabet of such imaginable dangers is unbounded: the hazards cannot be identified by examining the causal links on which the intended functional behaviour relies.
> 
> The distinction, of course, is not rigorous. Failure of a positive requirement, expressible in the functional design alphabet, may often be due to some phenomenon outside that alphabet breaking a causal link; and one could express maintaining integrity of the fuel tank against rear impact as a required functional behaviour. As a product class evolves, robustness against a commonly encountered failure may become a recognised positive requirement and then operationalised in a modification or enhancement of the specified functional behaviour.
> 
> Although the distinction is not rigorous, it is, I think, of value.
> 
> Regards,
> 
> -- Michael
> 
> 
> 
> 
> At 23:39 10/02/2014, nfr 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
>> >
>