[SystemSafety] Safety Cases

[Tracy White]

Peter
 
Probably why Rail sensibly talk in terms of the single acronym RAMS (reliability, availability, maintainability and safety) acknowledging the close relationship in terms of competing requirements in this area (saw that relationship described as a ‘symbiotic’ in a SSS article some time back); probably a further reason why systems and safety assurance should be talked about (argued) in the same breath.
 
I see RAM as providing a context for describing the ‘acceptability’ of the achieved safety. I do like the phrase that I heard used many years ago where safety was described as a ‘quality attribute’ of a design/product; equally RAMS are ‘quality attributes’ of any product for which you would desire some measure in order to assess the ‘rightness’ of the deliverable.
 
Tracy
 

> On 11 Feb 2014, at 22:00, Peter Bishop <pgb at adelard.com> wrote:
> 
> "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
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20140212/a15918d6/attachment-0001.html>