[SystemSafety] Who applies risk acceptance principles - Part 2

Thu Sep 20 13:28:50 CEST 2012

2012/9/20 M Mencke <menckem at gmail.com>

> True, the concept is not in the standards. However, I have frequently
> heard the frase that a product must "comply" with a SIL X and the idea of
> compliance with a SIL.
>
> This leads us (at least me) to think that a SIL must be estimated and then
> calculated in order to be below the 10-9 or whatever SIL is required.
> Otherwise, why do methods such as FMECA and FTA exist? Fault trees assign
> probabilities of failure, which when analysed lead to a dangerous failure
> rate for functions, which should be lower than the SIL (or THR) required
> for that function when it was allocated in the beginning.
>
>
> 2012/9/20 RICQUE Bertrand (SAGEM DEFENSE SECURITE) <
> bertrand.ricque at sagem.com>
>
>>  The "actual SIL" concept does not exist at all in the standards. Only
>> the "required SIL" exists. Anything else is erratic semantic deviation
>> generally driven by commercial reasons. This leads for instance to
>> absurdities such as  'SIL software calculator".****
>>
>> ** **
>>
>> There are no provisions at all in the standard for "actual SIL"
>> reconstruction. Even an overall framework such as ARP4761 does not exist.
>> ****
>>
>> ** **
>>
>> *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*
>>
>> * *
>>
>> [image: cid:image002.jpg at 01CCD767.029CDE20] ****
>>
>> ** **
>>
>> *From:* M Mencke [mailto:menckem at gmail.com]
>> *Sent:* Thursday, September 20, 2012 12:43 PM
>> *To:* RICQUE Bertrand (SAGEM DEFENSE SECURITE)
>> *Cc:* Peter Bernard Ladkin; systemsafety at techfak.uni-bielefeld.de
>>
>> *Subject:* Re: [SystemSafety] Who applies risk acceptance principles -
>> Part 2****
>>
>>  ** **
>>
>> 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****
>>
>> ** **
>>
>> #
>> " 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."
>>
>> #
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20120920/a86dd6b9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1835 bytes
Desc: not available
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20120920/a86dd6b9/attachment-0001.jpeg>