[SystemSafety] Who applies risk acceptance principles - Part 2
Eric Scharpf
EScharpf at exida.com
Fri Sep 21 00:16:21 CEST 2012
At the risk of over simplifying, we have be able to help a lot of companies with the idea that the calculations give a probability value and all of the follow on systematic failure management and related elements determine whether the calculated probability can be applied with confidence.
Best regards,
Eric
Dr. Eric W. Scharpf, CFSE
Partner, exida Asia Pacific
ANZ Service Centre
278 Blueskin Road
RD1 Port Chalmers
Dunedin 9081
New Zealand
+64-3-472-7707
escharpf at exida.com<mailto:escharpf at exida.com>
www.exida.com<http://www.exida.com/>
From: systemsafety-bounces at techfak.uni-bielefeld.de [mailto:systemsafety-bounces at techfak.uni-bielefeld.de] On Behalf Of Bridal Olof
Sent: Friday, 21 September 2012 1:59 a.m.
To: systemsafety at techfak.uni-bielefeld.de; bertrand.ricque at sagem.com
Subject: Re: [SystemSafety] Who applies risk acceptance principles - Part 2
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]<mailto:[mailto:bertrand.ricque at sagem.com]>
Sent: den 20 september 2012 14:50
To: Bridal Olof; systemsafety at techfak.uni-bielefeld.de<mailto: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<http://www.sagem-ds.com/>
[cid:image002.jpg at 01CCD767.029CDE20]
From: systemsafety-bounces at techfak.uni-bielefeld.de<mailto:systemsafety-bounces at techfak.uni-bielefeld.de> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de]<mailto:[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<mailto: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<mailto:olof.bridal at volvo.com>
www.volvogroup.com<http://www.volvogroup.com>
From: systemsafety-bounces at techfak.uni-bielefeld.de<mailto:systemsafety-bounces at techfak.uni-bielefeld.de> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de]<mailto:[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<mailto: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<http://www.sagem-ds.com/>
[cid:image002.jpg at 01CCD767.029CDE20]
From: systemsafety-bounces at techfak.uni-bielefeld.de<mailto:systemsafety-bounces at techfak.uni-bielefeld.de> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de]<mailto:[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<mailto: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<mailto: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<mailto: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<tel:%2B33%20%280%291%2058%2011%2096%2082>
M +33 (0)6 87 47 84 64<tel:%2B33%20%280%296%2087%2047%2084%2064>
23 avenue Carnot
91300 MASSY - FRANCE
http://www.sagem-ds.com<http://www.sagem-ds.com/>
[cid:image002.jpg at 01CCD767.029CDE20]
From: M Mencke [mailto:menckem at gmail.com<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<mailto: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<mailto: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<tel:%2B33%20%280%291%2058%2011%2096%2082>
M +33 (0)6 87 47 84 64<tel:%2B33%20%280%296%2087%2047%2084%2064>
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> [mailto: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<mailto: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<tel:%2B49%20%280%29521%20880%207319> www.rvs.uni-bielefeld.de<http://www.rvs.uni-bielefeld.de>
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto: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<mailto: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."
#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20120920/c4a9e6a4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1835 bytes
Desc: image001.jpg
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20120920/c4a9e6a4/attachment-0001.jpg>
More information about the systemsafety
mailing list