Re: [SystemSafety] Safety Cases

From: Michael Jackson < >
Date: Tue, 11 Feb 2014 14:53:59 +0000


Peter and Peter:

[Peter B]
"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!).

[MJ] Yes. This is an example of a 'positive' functional requirement whose failure does not pose a safety risk. By contrast, failure of the complementary functional requirement---turning the key the other way stops the engine---does pose a safety risk, as some unintended acceleration incidents show. This is an example of my first kind of safety concern: unsafe because the intended behaviour 'went wrong'.

[Peter B]
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

[MJ] Yes. But surely compliance to positive requirements must mean compliance to the stated and agreed positive requirements. If by ignorance or neglect no positive requirement to detect cyclists has been stated and agreed, then the case you mention is more like my second type of safety concern: for the ignorant or neglectful developers, blind-side cyclists are one of an unbounded set of hazards outside the alphabet (or vocabulary) of the designed behaviour---just like a tree falling on your car.

[PeterL]
(we probably prefer the word "vocabulary" to the word "alphabet", because items of vocabulary have
meanings whereas items of an alphabet generally not)

[MJ] I take your point about the abstract nature of alphabet elements. The advantage of 'alphabet' is that it denotes a precisely defined set of distinct elements.

[PeterL]
For example, when expressing the safety requirement of a level crossing (grade crossing), one
doesn't need to express any general functional requirement of a train, or a road vehicle, except
that they occupy space. The safety requirement is then that the space that each occupies must be
disjoint. You don't even need to say, at this level, that a car moves, or a train moves. But surely
something about enabling movement must be in, or derivable from, the general functional requirements
of either.

[MJ] Yes. But there is a wide gap between such a requirement and the design of the crossing system. The requirement is a desired property of the system behaviour. The system includes the tracks and the given population of rail and road vehicles, and its designed behaviour must take proper account of the sizes and speeds of these vehicles. When we have a proposed designed behaviour we can evaluate whether it has the desired property. In the case of your requirement for disjoint spaces this would count as a safety analysis; the case of enabling movement demands exactly the same kind of analysis, but it would not count as a safety analysis.

At 12:26 11/02/2014, Peter Bernard Ladkin wrote:
>Michael,
>
>that sounds a lot like how one starts an Ontological Hazard
>Analysis. There is, though, a
>difference, as I see it, as follows.
>
>* You start with the overall functional requirements of the system,
>express them in some language
>(we probably prefer the word "vocabulary" to the word "alphabet",
>because items of vocabulary have
>meanings whereas items of an alphabet generally not) and wish to
>derive safety requirements from that.
>
>* Whereas OHA starts with very-top-level formulations of safety
>requirements, not general requirements.
>
>For example, when expressing the safety requirement of a level
>crossing (grade crossing), one
>doesn't need to express any general functional requirement of a
>train, or a road vehicle, except
>that they occupy space. The safety requirement is then that the
>space that each occupies must be
>disjoint. You don't even need to say, at this level, that a car
>moves, or a train moves. But surely
>something about enabling movement must be in, or derivable from, the
>general functional requirements
>of either.
>
>PBL
>
>On 2014-02-11 11:32 , Michael Jackson wrote:
> > 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.
>
>
>
>Prof. Peter Bernard Ladkin, Faculty of Technology, University of
>Bielefeld, 33594 Bielefeld, Germany
>Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de
>
>
>
>
>_______________________________________________
>The System Safety Mailing List
>systemsafety_at_xxxxxx



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Feb 11 2014 - 15:54:16 CET

This archive was generated by hypermail 2.3.0 : Thu Apr 25 2019 - 20:17:06 CEST