Re: [SystemSafety] Safety Cases

From: Michael Jackson < >
Date: Tue, 11 Feb 2014 10:32:14 +0000


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,

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



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Feb 11 2014 - 11:32:29 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 20 2019 - 20:17:06 CET