[SystemSafety] Safety Cases

[Peter Bishop]

"Not right" does not necessarily = "Unsafe"
e.g. turning the ignition key might fail to start the engine but the car 
is still safe (probably safer than if it did start!).

Also "right" in the sense of compliance to positive requirements does 
not guarantee safety if some positive safety requirement has been 
omitted. e.g. large lorries turning left (driver's blind side( have been 
killing quite a few cyclists in  London recently - probably because 
there is no requirement to be able to detect cyclists beside the lorry.

Peter Bishop
Adelard

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
>> >
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE

-- 

Peter Bishop
Chief Scientist
Adelard LLP
Exmouth House, 3-11 Pine Street, London,EC1R 0JH
http://www.adelard.com
Recep:  +44-(0)20-7832 5850
Direct: +44-(0)20-7832 5855