[SystemSafety] Safety Cases

[Michael Jackson]

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
> >