[SystemSafety] Who applies risk acceptance principles - Part 2

[M Mencke]

This discussion has been extremely interesting for me, particularly
Bridal's points 1 and 2, which include the phrase:

"2. Assuming that the safety function has been designed and implemented, it
would in theory be possible to investigate if the probabilistic requirement
is met. In reality, however, such calculations can usually not be made."

>From my point of view, standards such as IEC 61508 and EN 50126  give the
impression that such calculations *can* usually be made. I think that this
is where the confusion regarding SIL "calculation" comes from. I consider
it very reasonable that the concept of SI does not only consist of a
probability but also a set of requirements and techniques. However, I think
upon reading the standards SIL is principally portrayed as a probability to
be complied with, which thus leads to this interpretation.

Thanks for the info regarding the workshop.

Regards,

Myriam.



2012/9/20 Bridal Olof <Olof.Bridal at volvo.com>

>  Dear Bertrand,****
>
> ** **
>
> I agree that the definition of safety integrity in 3.5.4 and note 3 in
> 3.5.8 are inconsistent with each other. In 3.5.4, the safety integrity is
> definied as a probability of a system to behave in a particular way. Note 3
> in 3.5.8 states that a SIL (which is a discretized safety integrity) is not
> a property of a system. I would certainly say that a probability of a
> system to behave in a particular way is a property of that system so there
> is some contradiction here. 'SIL' should either be defined such that it can
> only represent a *required* probability (as it was in the 1998 version),
> or such that the probability can be either a requirement or an actual value
> (as it seems to be in the 2010 version.). Either way is fine but one
> excludes the other.****
>
> ** **
>
> In my mind it works like this:****
>
> **
>
> 1. For a given safety function, the probability (or frequency, depending
> on the type of function) of a dangerous failure needs to be below some
> limit if a tolerable risk is to be achieved. This limit is the required
> safety integrity. It can be expressed as a SIL requirement, for example SIL
> 1.****
>
> 2. Assuming that the safety function has been designed and implemented, it
> would in theory be possible to investigate if the probabilistic requirement
> is met. In reality, however, such calculations can usually not be made and
> note 3 in clause 7.6.2.9 of IEC61508-1 (2010 version) applies: "*It is
> accepted that it will not be possible to predict quantitatively the safety
> integrity of all aspects of E/E/PE safety-related systems. Qualitative
> techniques, measures and judgements will have to be made with respect to
> the precautions considered necessary to ensure that the target failure
> measures are achieved.*"
>
> 3. It is obviously not ideal to have probabilistic requirements and no
> feasible way of verifying whether the required probability has been
> achieved . IEC61508 addresses this by defining what is considered (by the
> IEC61508-developing committee) to be the appropriate "*qualitative
> techniques, measures and judgements*" . Thus, IEC61508 defines
> process-oriented requirements for the different SILs. Whether or not these
> requirements are necessary and/or sufficient to achieve the required SIL,
> i.e. the required probability, is a topic that has been discussed for more
> than a decade but it's another story.****
>
> ** **
>
> Best regards,****
>
> ** **
>
> Olle****
>
> ** **
>
> *From:* RICQUE Bertrand (SAGEM DEFENSE SECURITE) [mailto:
> bertrand.ricque at sagem.com]
> *Sent:* den 20 september 2012 14:50
> *To:* Bridal Olof; systemsafety at techfak.uni-bielefeld.de
> *Subject:* RE: [SystemSafety] Who applies risk acceptance principles -
> Part 2****
>
> ** **
>
> Yes, and it has been heavily disputed in the committee. This wording
> reflects the influence of the manufacturers (CAVEAT EMPTOR).****
>
> ** **
>
> But, if you read Note 3 of both 3.5.8 and 3.5.4, you can see the internal
> contradiction. In the first one, it clearly states that the such
> "probability" contains unquantifiable contributors. In the second one, it
> states that it cannot be a property of anything. That's the best the
> opponents managed to have.****
>
> ** **
>
> Sic transit gloria mundi.****
>
> ** **
>
> *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:* systemsafety-bounces at techfak.uni-bielefeld.de
> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de] *On Behalf Of *Bridal
> Olof
> *Sent:* Thursday, September 20, 2012 2:42 PM
> *To:* systemsafety at techfak.uni-bielefeld.de
> *Subject:* Re: [SystemSafety] Who applies risk acceptance principles -
> Part 2****
>
> ** **
>
> Dear Bertrand,****
>
> ** **
>
> I'm afraid that's simply wrong. Safety integrity is *by definition*(clause 3.5.4 of IEC61508-4, year 2010) a probability and the safety
> integrity level, or SIL, is according to clause 3.5.8 in IEC61508-4 simply
> a discrete level corresponding to a range of safety integrity values. The
> fact that a given SIL leads to a given set of development-related
> requirements does not change the meaning of the SIL. It is still a
> (discretized) probability.****
>
> ** **
>
> Best regards,****
>
> ** **
>
> Olle****
>
> _________________________________________________
> Dr Olle Bridal****
>
> Senior Engineering Specialist – Functional Safety****
>
> Systems and Architecture****
>
> ** **
>
> *Volvo Group Trucks Technology*
>
> Advanced Technology & Research
> Dept BF40553, M2.7
> 405 08 Gothenburg, Sweden****
>
> Telephone:    +46-31-323 30 16
> SMS/Text:            +46-76-553 30 16
> E-mail: olof.bridal at volvo.com****
>
> www.volvogroup.com****
>
> ** **
>
> *From:* systemsafety-bounces at techfak.uni-bielefeld.de
> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de] *On Behalf Of *RICQUE
> Bertrand (SAGEM DEFENSE SECURITE)
> *Sent:* den 20 september 2012 14:31
> *To:* M Mencke; systemsafety at techfak.uni-bielefeld.de
> *Subject:* Re: [SystemSafety] Who applies risk acceptance principles -
> Part 2****
>
> ** **
>
> Hi Myriam,****
>
> ** **
>
> your comment let me think that you assimilate "actual SIL" to a quantity
> that can be calculated, probably a probability.****
>
> ** **
>
> But "required SIL" is not a probability. "Required SIL" means that a set
> of requirements applies. This set of requirements (381 in Ed1) covers five
> domains :****
>
> **·         **Project development****
>
> **·         **Avoidance of systematic errors in the hardware design
> through manadtory or recommended application of methods and techniques****
>
> **·         **Hardware fault tolerance through architectural constrainsts
> on the system design****
>
> **·         **Maximum acceptable probability of dangerous failure on
> demand or per hour****
>
> **·         **Avoidance of systematic errors software development through
> manadtory or recommended application of methods and techniques (up to 673
> prescriptions)****
>
> Maximum PFD or PFH is only one among 381 requirements. Alas, this is often
> the single one widely discussed.****
>
> ** **
>
> "Actual SIL" could rather be translated in "compliance to required SIL
> requirements". This cannot be calculated, only assessed.****
>
> ** **
>
> *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:* systemsafety-bounces at techfak.uni-bielefeld.de
> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de] *On Behalf Of *M
> Mencke
> *Sent:* Thursday, September 20, 2012 1:29 PM
> *To:* systemsafety at techfak.uni-bielefeld.de
> *Subject:* Re: [SystemSafety] Who applies risk acceptance principles -
> Part 2****
>
> ** **
>
> ** **
>
> 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."****
>
> #****
>
>   ** **
>
> ** **
>
> #
>
> ****
>
> " 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."
>
> ****
>
> #****
>
> #
> " 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/20120924/e4e7200a/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/20120924/e4e7200a/attachment-0001.jpeg>