[SystemSafety] Who applies risk acceptance principles - Part 2

[M Mencke]

A lot of work with the aim of determining what is an acceptable risk level
has already been done, for instance, it is generally accepted that for a
risk with Catastrophic consequences, the THR should be 10-9.

However, I think that there is some confusion in general regarding the
difference between the *required* SIL and the *actual *SIL of the system
functions, at least in my experience.

In aviation, during Preliminary Hazard Identification an initial SIL is
allocated for a function. I imagine this is equivalent to the THR for
railway, that is, an acceptable level of risk in the case of a failure of a
function. I view this initial allocation as the SIL that is *required *for
the system functions. Subsequently, during the design phases, the
(sub)systems are analysed to determine the *actual *SIL of the functions,
and the design may be updated to improve the probability of a dangerous
failure.

What I have seen is that this initial SIL allocation is frequently
considered as the *actual* SIL of the system, in the style of "this is a
SIL 4 system" (which in itself is not correct because it is the functions
that have a SIL). The design could be analysed and it could result that the
dangerous failure rate is actually much higher than the one that is
required by the SIL 4 allocation performed in the beginning.

I'm aware that these issues have already been discussed in standards such
as IEC 61508, however, in practice the distinction isn't always made.


2012/9/20 RICQUE Bertrand (SAGEM DEFENSE SECURITE) <
bertrand.ricque at sagem.com>

> Here is what is curretly being discussed
>
> START QUOTE
>
> 5 Achieving tolerable risk
> 5.1 Iterative process of risk assessment
> The critical issue the standards writers must address as a product
> (process or service) goes through the
> supply chain from development to the user (consumer) is to determine
> whether the iterative process of risk
> assessment is assumed by:
>  the standard writing committee for specific and known hazards,
>  the standard reader/user for hazards to be identified by him/her, or
>  a government or regulatory body.
> 5.2 Tolerable risk
> 5.2.1 Safety is achieved by reducing risk to a tolerable level — defined
> in this Guide as tolerable risk (see
> Figure 1). Tolerable risk is determined by the search for an optimal
> balance between the ideal of absolute
> safety and the demands to be met by a product, process or service, and
> factors such as benefit to the user,
> suitability for purpose, cost effectiveness, and conventions of the
> society concerned. It follows that there is a
> need to review the tolerable level, in particular when developments, both
> in technology and in knowledge, can
> lead to economically feasible improvements to attain the minimum risk
> compatible with the use of a product,
> process or service.
> NOTE The concept of safety and reducing risk to a tolerable level varies
> significantly depending on whether the
> product is used in the workplace or by a consumer in the home. Whereas it
> is possible to control risks to a greater extent
> in the workplace through occupational training, protective procedures and
> equipment that workers are obligated to follow
> and use, this might not be taken into account in the home environment.
> 5.2.2 Safety is dealt with in standards work in many different forms
> across a wide range of technologies and
> for most products, processes and services. The increasing complexity of
> products, processes and services
> entering the market requires that the consideration of safety aspects be
> given a high priority.
>  END OF QUOTE
>
> Bertrand RICQUE
> Program Manager, Optronics and Defense Division
>
> T +33 (0)1 58 11 96 82
> M +33 (0)6 87 47 84 64
> 23 avenue Carnot
> 91300 MASSY - FRANCE
> http://www.sagem-ds.com
>
>
>
>
> -----Original Message-----
> From: systemsafety-bounces at techfak.uni-bielefeld.de [mailto:
> systemsafety-bounces at techfak.uni-bielefeld.de] On Behalf Of Peter Bernard
> Ladkin
> Sent: Thursday, September 20, 2012 11:41 AM
> To: systemsafety at techfak.uni-bielefeld.de
> Subject: Re: [SystemSafety] Who applies risk acceptance principles - Part 2
>
> Hi Myriam,
>
> thanks for the update.
>
> The 1999 ISO Guide 51 on safety aspects in standards says that standards
> shall incorporate certain
> processes which it calls cumulatively "risk assessment". This consists of
> * defining intended use and reasonably foreseeable misuse
> * identifying hazards
> * estimating risk
> all of which is called "risk analysis". Risk analysis together with the
> subsequence step
> * evaluating risk
> is called "risk assessment". After risk assessment, one asks
> * whether tolerable risk is achieved
> If so, one is done. If not, one is to perform
> *risk reduction
> and start again at the top.
>
> Guide 51 is currently being modified and I don't know what is in the new
> version. I suspect it may
> lose its commendable simplicity.
>
> Now, there is nothing in the above which suggests that deriving risk
> acceptance principles is a
> practice which must appear in a safety standard. Obviously, in deciding
> whether tolerable risk is
> achieved, one must either apply a set of principles or decide ad hoc. I
> suspect most people would go
> for principles in the abstract but probably go ad hoc (that is, "what my
> boss tells me I have to
> do") in practice.
>
> It seems to me like a good idea it would be required that the decision
> method for "tolerable risk"
> be made explicit. That is, in your terms, that risk acceptance principles
> were to be explicitly defined.
>
> PBL
>
> --
> 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 TechFak.Uni-Bielefeld.DE
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir des
> informations confidentielles ou ayant un caractère privé. S'ils ne vous
> sont pas destinés, nous vous signalons qu'il est strictement interdit de
> les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
> soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
> informer l'expéditeur et de supprimer immédiatement de votre système
> informatique ce courriel ainsi que tous les documents qui y sont attachés."
> ******
> " This e-mail and any attached documents may contain confidential or
> proprietary information. If you are not the intended recipient, you are
> notified that any dissemination, copying of this e-mail and any attachments
> thereto or use of their contents by any means whatsoever is strictly
> prohibited. If you have received this e-mail in error, please advise the
> sender immediately and delete this e-mail and all attached documents from
> your computer system."
> #
> _______________________________________________
> 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/20120920/8d2d5a27/attachment.htm>