INRS

INSTITUT NATIONAL DE RECHERCHE ET DE SCURIT

pour la prvention des accidents du travail et des maladies professionnelles

Probabilit de Dfaillance Dangereuse dun

systme : explications et exemple de calcul

Note Scientifique et Technique n 225

Pascal LAMY N / IET

septembre 2002
Rsum

Dans le domaine de la scurit des machines, de nouvelles normes (CEI 61508 et CD CEI
62061) sont apparues et visent quantifier la probabilit de dfaillance dangereuse, nomme
PFD, des pannes matrielles dun systme. Cette quantification est un des moyens qui permet
de classer les systmes par niveau de scurit (SIL).
Ce document rappelle, dans un premier temps, les diffrentes notions utiles pour calculer la
probabilit de dfaillance dangereuse, notamment lexplication des diffrents paramtres
intervenants dans lestimation de la PFD. Il prcise ensuite la dmarche suivre pour raliser
ce calcul.
Finalement, un exemple dapplication sera dtaill en insistant sur une architecture base
dautomates identiques et une autre architecture base dautomates htrognes. Cette note
scientifique et technique se veut comme un support permettant de mieux apprhender le calcul
de la probabilit de dfaillance dangereuse. Les hypothses prises seront dtailles et
plusieurs mthodes de calcul seront explicites.

-2-
 Sommaire

1 Introduction ........................................................................................................................5
2 Dfinitions ..........................................................................................................................5
3 Logigramme pour le processus de conception .................................................................11
4 Etude fonctionnelle du systme ........................................................................................11
4.1 Les fonctions de scurit ..........................................................................................12
4.2 Etude de l'architecture du systme............................................................................12
4.3 Allocation des blocs fonctionnels aux sous-systmes ..............................................12
5 Etude probabiliste .............................................................................................................12
5.1 dun composant .....................................................................................................12
5.2 Dfaillance dangereuse et dfaillance sre...............................................................12
5.2.1 Prambule .........................................................................................................12
5.2.2 Dfinitions des tats..........................................................................................13
5.2.3 Action des dfaillances.....................................................................................15
5.2.4 Classification / quantification des dfaillances ................................................16
5.3 dun module...........................................................................................................18
5.4 Dtermination des facteurs .......................................................................................18
5.4.1 Taux de couverture ...........................................................................................18
5.4.2 Modes communs...............................................................................................19
5.4.3 Intervalle de temps entre proof test ..................................................................19
5.5 Dtermination du dun sous-systme ....................................................................20
5.6 PFD (Probabilit de dfaillance dangereuse) du systme ........................................20
6 Exemple de calcul.............................................................................................................21
6.1 Fonctions de scurit ................................................................................................21
6.1.1 Dtection de personne ......................................................................................22
6.1.2 Commande bi-manuelle....................................................................................22
6.2 Dcomposition en blocs fonctionnels.......................................................................24
6.3 Architecture du systme ...........................................................................................24
6.4 Allocation des blocs fonctionnels aux sous-systmes ..............................................25
6.5 Exigences de scurit pour chaque bloc fonctionnel................................................26
6.6 Exigences fonctionnelles ..........................................................................................26
6.6.1 Bloc 1 : dtection de franchissement................................................................26
6.6.2 Bloc 2 : acquisition des donnes tat machine .................................................26
6.6.3 Bloc 3 : traitement logique ...............................................................................26
6.6.4 Bloc 4 : comparateur.........................................................................................26
6.6.5 Bloc 5 : Arrt de la machine (ou mcanisme d'arrt) .......................................27
6.7 Dtermination des taux de dfaillances ....................................................................27
6.7.1 Sous-systme 1 .................................................................................................27
6.7.2 Sous-systme 2 .................................................................................................27
6.7.3 Sous-systme 3 .................................................................................................28
6.8 Dtermination des facteurs .......................................................................................29
6.8.1 Sous-systme 1 .................................................................................................29
6.8.2 Sous-systme 2 .................................................................................................29
6.8.3 Sous-systme 3 .................................................................................................30
6.9 Architecture avec 2 API identiques : cas de la faible sollicitation ...........................30
6.9.1 PFDavg du systme par la mthode des blocs diagrammes ...............................31
6.9.2 PFDavg du systme par arbre des causes ...........................................................37
6.9.3 PFDavg du systme par diagramme de Markov.................................................38

-3-
 6.9.4 Introduction des modes communs ....................................................................40
6.10 Architecture avec 2 API diffrents : cas de la faible sollicitation ............................41
6.10.1 PFDavg par la mthode des blocs diagrammes ..................................................41
6.10.2 PFDavg par la mthode de larbre des causes ....................................................41
6.10.3 PFDavg par la mthode du graphe de Markov ...................................................42
6.11 Rcapitulatif des rsultats pour PFDavg ....................................................................42
6.12 Cas de la forte sollicitation .......................................................................................42
6.12.1 Mthode des blocs diagrammes........................................................................43
6.12.2 Arbre des causes ...............................................................................................43
6.12.3 Graphe de Markov ............................................................................................43
6.12.4 Comparaison entre les diffrentes mthodes ....................................................44
7 Rcapitulatif des hypothses faites...................................................................................45
8 Conclusion et remarques ..................................................................................................46
Annexe 1 ................................................................................................................................47
Annexe 2 ................................................................................................................................49
Bibliographie ............................................................................................................................50

-4-
1 Introduction
L'utilisation de systmes lectroniques complexes (par exemple programmables) dans les
systmes de commande des machines a ncessit de modifier l'approche au niveau de la
conception de ces machines.

De nouvelles normes1 2 proposent ainsi des prescriptions techniques pour la conception et

l'intgration de systmes lectroniques complexes dans la partie commande des machines.
Pour caractriser les pannes alatoires matrielles, il est de plus propos de quantifier les
dfaillances dangereuses de ces systmes en utilisant la probabilit de dfaillance dangereuse
(PFD).

Ce document se propose d'expliquer les diffrentes mthodes permettant de calculer la

moyenne de la probabilit de dfaillance dangereuse sur demande due aux pannes
matrielles alatoires (cas de la faible sollicitation). On expliquera aussi le calcul de la
probabilit de dfaillance dangereuse par unit de temps (cas de la forte sollicitation).
Ce guide s'utilise dans le cas de systmes de commande pour des machines (au sens de la
norme CD CEI 620611) constitus d'un ensemble de sous-systmes dont on connat les
caractristiques de fiabilit.

Dans un premier temps, nous ferons un rappel sur la notion de probabilit et nous dfinirons
les termes ncessaires au calcul.
Le calcul de la probabilit de dfaillance dangereuse commence avant tout par une tude
fonctionnelle du systme qui permet de dcomposer l'ensemble afin d'identifier les fonctions
de scurit. Cette tude fonctionnelle va aussi permettre d'obtenir une vue architecturale
(matrielle) du systme.
En fonction de la dcomposition, il faut ensuite quantifier les dfaillances de chaque partie.
Les modles de calcul proposs permettront ensuite de prendre en compte les apports des
diffrents sous-systmes et de fournir la probabilit de dfaillance dangereuse de l'ensemble.

2 Dfinitions
Systme 3: Ensemble dtermin d'lments interconnects ou en interaction.
Exemples :
Arrt d'une machine suite la dtection d'une personne. Le systme pourrait tre
constitu d'un barrage immatriel qui dtectera l'intrusion d'une personne, d'un module
de traitement (APIdS Automate Programmable Industriel ddi la Scurit ou autre)
et de la commande d'arrt.
Si on utilise un autre point de vue, on peut aussi considrer comme systme un
automate programmable dont la fonction sera de positionner une de ses sorties en
fonction de ses entres. Dans ce cas, le systme API (Automate Programmable
Industriel) sera constitu trs schmatiquement de la carte d'acquisition, de lunit
centrale (CPU) et de la carte de sortie.
On constate donc que la notion de systme dpend fortement du niveau auquel on se place.
Dans la suite du document, on s'intressera plus particulirement aux fonctions de scurit et

-5-
donc aux systmes tels que, par exemple, celui ralisant l'arrt d'une machine suite la
dtection d'une personne.

Sous-systme : Ensemble de modules (automate programmable par exemple). Selon la norme

CEI 615082, un lment d'un systme peut-tre un autre systme appel dans ce cas sous-
systme. Les sous-systmes peuvent tre eux-mmes soit un systme de commande, soit un
systme command compos de matriel et de logiciel en interaction avec l'tre humain.

Module3: Ensemble fonctionnel de composants encapsuls formant un tout (circuit d'entre ou

de sortie, carte lectronique).

Composant2 : La plus petite partie d'un module, d'un sous-systme ou dun systme qu'il est
ncessaire et suffisant de considrer pour l'analyse du systme. Cette plus petite partie pourra
tre limite par les donnes disponibles donnant les caractristiques du composant. On sera
parfois oblig de rester au niveau module pour l'analyse.
La dcomposition propose est donc :
composant / module / sous-systme / systme.

Redondance3: Existence dans une entit de plus d'un moyen pour accomplir une fonction
requise. On parlera de canaux en redondance.

Canal (selon CEI 615082): Module ou sous-systme excutant une fonction indpendante.
Un canal peut tre constitu de plusieurs modules.

Fonction de scurit (selon 2 et 620611): fonction ralise par un systme relatif la scurit
pour assurer ou maintenir un tat de scurit de la machine par rapport un vnement
dangereux spcifique.

Etat de scurit (selon 2): Etat de la machine lorsque la scurit est ralise.

Panne alatoire 2: Panne en gnral due uniquement au matriel (hardware), rsultant de

divers mcanismes de dgradation et dont l'instant exact d'occurrence n'est pas prvisible. Par
contre, la moyenne de la probabilit de dfaillance dangereuse due aux pannes alatoires
matrielles peut tre quantifie de faon prcise, par le taux de dfaillance notamment.

Panne systmatique 2: Par opposition aux pannes alatoires, ce sont des dfaillances relies
de faon systmatique une certaine cause, ne pouvant tre limines que par une
modification de la conception, du processus de fabrication, des procdures d'exploitation, de
la documentation ou d'autres facteurs.

Test de diagnostic : Selon 1 et 2, test en ligne (en fonctionnement) pour dtecter des dfauts
(comme un WatchDog ou chien de garde - selon ISA-S84.01-19965, un test de la mmoire
vive (RAM) ou de la mmoire programme).
D'aprs ISA-S84.01-19965 (page 70), les tests de diagnostic sont effectus priodiquement et
automatiquement pour dtecter les dfauts latents cachs qui empchent le SIS (Safety
Integrated System) de rpondre une demande.
Les tests de diagnostic agissent au niveau composant/interne (et non pas au niveau de la
fonction de scurit) et permettent de dtecter les erreurs alatoires (dues au matriel). Dans

-6-
certains cas, ils permettent de dtecter les erreurs systmatiques (telles que les bugs logiciels :
cf. ISA5 B.9.3.6). Un WatchDog peut dtecter des sauts de programme dus des bugs
logiciel.
Les tests de diagnostics permettent de rparer rapidement et de limiter le temps pass en mode
dgrad.
Il existe 2 types de tests de diagnostics :
- les diagnostics de rfrence : comparaison par rapport une valeur prdtermine
comme la mesure de la priode de temps (watch dog), le calcul de la somme de
contrle dune mmoire programme (checksum), le rebouclage de toutes les sorties
sur une entre (dtection des pannes des practionneurs en cas de discordance).
Selon Goble4 (p.86), le taux de couverture de ces tests est gnralement bon (entre
0.9 et 0.999),
- les diagnostics par comparaison une unit oprationnelle ( comparaison de tables
de donnes logiques entre 2 ou plusieurs canaux).

Taux de couverture des tests de diagnostic (ou Diagnostic Coverage DC) : Historiquement,
le taux de couverture a t introduit lors des programmes spatiaux amricains pour
caractriser la tolrance aux fautes logicielles. Le taux de couverture a t ainsi dfini comme
tant la probabilit (nombre compris entre 0 et 1) qu'une panne soit dtecte. La dfinition la
plus gnrale est :
somme des taux de dfaillances des composants dtects en panne
taux de couverture =
somme des taux de dfaillances de tous les composants

La norme CEI615081 dfinit ce taux de couverture pour les tests automatiques de diagnostic
comme tant le rapport du taux de dfaillance des pannes dangereuses dtectes (par un test
de diagnostic) sur le taux de dfaillance total des pannes dangereuses (dtectes et non
dtectes).

DC =
DD

total dangereuses

Lvaluation de DC se fait par exemple (cf. ISA4 p 201) par une analyse des modes de
dfaillances et des diagnostics. On cherchera ainsi dterminer les dfaillances possibles et
savoir si elles peuvent tre dtectes, puis on calculera le rapport ci-dessus l'aide des taux de
dfaillances et non pas uniquement l'aide du nombre des dfaillances.

Proof Test : Dfinition de CEI62061 et de CEI61508: test priodique hors ligne ralis pour
dtecter des pannes dans un systme de telle sorte que le systme puisse tre rpar afin de
revenir dans un tat quivalent son tat initial.
Selon ISA-S84.01-19965, dans le cas o le diagnostic coverage serait minimum ou insuffisant
(si on ne peut pas ou ne sait pas raliser un test de diagnostic satisfaisant), on pourra
augmenter la frquence du proof test. En augmentant la frquence du proof test, on vrifiera
plus souvent que la fonction de scurit est bien disponible.
Le proof test est excut au niveau du systme. Cest un test fonctionnel de la fonction de
scurit hors fonctionnement automatique (activit priodique devant tre conduite selon une
procdure afin de dtecter les dfauts latents qui empchent le systme de scurit de remplir
sa fonction de scurit ; le systme de scurit entier doit tre test) alors que le test de
diagnostic est plutt une dtection interne en fonctionnement. Le proof test permet de dtecter
les pannes latentes qui n'ont pas t vues par les tests de diagnostics. On peut aussi effectuer
des proof tests au niveau des sous-systmes mais cela sapplique plus lindustrie du process.

-7-
Temps de mission : Temps pendant lequel le systme est utilis pour son application de
scurit. Lorsque des proof tests sont raliss, ce temps de mission sera considr comme gal
au temps entre deux proof tests conscutifs. Dans les cas o il n'y a pas de proof tests, on
prendra le temps de mission gal au temps de vie de l'appareil (MTTF).

Fiabilit (reliability en anglais)4 : Probabilit qu'un dispositif accomplisse sa fonction voulue

lorsque ce dispositif travaille dans les limites prvues et un instant donn. La fiabilit se
note R. C'est une fonction du temps telle que :
R(t) = P(T>t); probabilit que le temps T (temps o la panne intervient) soit suprieur
au temps t (temps oprationnel ou temps de fonctionnement; dfinition de l'ISA5); on peut
aussi la dfinir comme la probabilit que le systme ne soit pas dfaillant pendant l'intervalle
de temps [0,t]. La fiabilit n'a de sens que si elle est associe au temps de mission. Cest un
nombre sans dimension.

Diffrents temps caractristiques :

Remise en
Dfaillance service Dfaillance
0

temps
MTTF MDT MUT

MTBF

Dbut de la Fin de la
rparation Remise en
Dfaillance Dtection rparation service

temps pour remettre

temps mis temps mis pour MTTRep en service
pour dtecter prendre actions

MTTRes

MDT

MTTF3 : Mean Time To Failure. Pour un systme que l'on ne rpare pas, le MTTF est le
temps moyen de fonctionnement avant la premire dfaillance.
La dfinition du MTTF est :

MTTF = R(t ) dt
0

-8-
MTBF3: Mean Time Between Failure. Le MTBF na de sens que pour un systme rparable..
C'est la dure moyenne entre deux dfaillances conscutives. MTBF MTTF = 1/ dans le
cas d'un composant simple de taux de dfaillance qui, aprs rparation, peut-tre considr
comme identique ce qu'il tait en dbut de vie.

MTTR3 : Mean Time To Repair. C'est le temps moyen mis pour rparer le systme. Le MTTR
est dfini dans la CEI 61508 comme tant Mean Time To Restoration. Il faudrait alors
prciser les termes MTTRep6 pour Mean Time To Repair et MTTRes6 pour Mean Time To
Restoration. La diffrence entre les deux est lie au fait que l'on considre ou non le temps
mis pour remettre en service l'quipement, le MTTRes l'incluant.

MDT3 (donn quivalent tort au MTTR comme dans la CEI 61508): Mean Down Time.
Cest la dure moyenne d'indisponibilit ou de dfaillance. Elle correspond la dtection de
la panne, la rparation de la panne et la remise en service. Le MDT se dcompose en temps
mis pour dtecter la dfaillance + temps de raction avant la mise en place des actions pour
rparer + MTTRes.
Pour les systmes o la rparation s'effectue hors-ligne (il y a possibilit d'enlever l'lment
dfaillant sans perturber le fonctionnement du systme), le MTTRes ne comprend plus le
MTTRep. Cela permet de diminuer le temps d'indisponibilit du systme.

MUT3 : Mean Up Time. Cest la dure moyenne de fonctionnement aprs rparation.

En rgle gnrale, on confond le MTTF et le MTBF car on suppose que le MDT est faible
devant le MUT. Le MUT est de plus considr comme quivalent au MTTF (le systme
rpar est considr comme neuf alors que ce n'est pas forcment le cas (tout n'a pas t
chang). Sans approximation, MTBF = MUT + MDT.

Intervalle entre tests de diagnostics : Les tests de diagnostics doivent tre effectus une
certaine frquence afin de dtecter les pannes. Cet intervalle de temps intervient dans le calcul
de la probabilit de dfaillance dangereuse. En fait la norme CEI 61508 prcise les cas :
- pour les systmes faible sollicitation, le MTTRes est considr comme tant la
somme de l'intervalle entre les tests de diagnostic et le temps de rparation,
- pour les systmes forte sollicitation, pour lesquels l'intervalle entre tests de
diagnostics n'est pas d'un ordre de grandeur infrieur au taux de demande moyen,
l'intervalle entre tests de diagnostic s'ajoute au MTTRes.
Dans la mesure o les pannes sont considres comme tant dtectes et rpares rapidement,
on a vu ci-dessus que le MTTRes est ngligeable devant le temps entre deux pannes
conscutives. En fait, il faut s'assurer que l'intervalle entre tests de diagnostics est
suffisamment petit pour que le temps d'indisponibilit du systme soit petit devant le MTBF.
Finalement, on pourra envisager un intervalle entre tests de diagnostics infrieur d'un facteur
100 (valeur dexpert) au MTBF de l'quipement afin de s'assurer que l'indisponibilit de
l'quipement sera ngligeable devant le MTBF.

Probabilit d'une dfaillance par unit de temps (heure, anne) ou taux de dfaillance:
Note (t) pour un fonctionnement continu du systme. C'est la probabilit pour que le
systme soit dfaillant. Cette dfinition s'applique pour tout type d'lments (systme, sous-
systme, module, composant, canal).

-9-
Probabilit de dfaillance sur demande PFD(t) (probability failure on demand) : C'est la
probabilit sur l'intervalle de temps [0,t] que le systme ne puisse pas excuter la fonction
pour laquelle il a t conu au moment o la demande de cette fonction est faite. Cest un
nombre sans dimension.
Dans le cas d'un systme mono canal :
PFD(t) = 1 - Fiabilit = 1- R(t); cette notion est en fait la base des probabilits. La somme de
la probabilit d'un vnement et de son complment doit faire 1.

Probabilit moyenne de dfaillance sur demande PFDavg (Average of the probability failure
on demand) : C'est la valeur moyenne par rapport l'intervalle de temps entre proof test (test
fonctionnel) de la probabilit de dfaillance sur demande5. Selon l'existence de proof test ou
non, la valeur moyenne se calculera par rapport l'intervalle de temps Ti entre ces proof tests
ou par la valeur moyenne par rapport au temps de vie du composant (s'il n'y a pas de proof
test, Ti = MTTF).
T
1 i
PFDavg (Ti ) = PFD(t ) dt
Ti 0
Cette grandeur s'utilise dans le cas des systmes faible sollicitation et cest un nombre sans
dimension.

Probabilit d'une dfaillance dangereuse par unit de temps (heure, anne) ou taux de
dfaillance dangereuse : Not D(t) pour un fonctionnement continu du systme. C'est la
probabilit que le systme soit dfaillant de telle sorte qu'il soit incapable d'excuter la
fonction de scurit attendue. D(t) dt reprsente la probabilit d'avoir une dfaillance entre
(t,t + dt) sachant qu'il n'y a pas de dfaillance sur l'intervalle [0,t].

Probabilit d'une dfaillance dangereuse par heure PFH (probability of a dangerous

failure per hour):
Cette notion prend en compte les intervalles entre tests. S'il n'y a pas de moyens de rparation,
PFD
PFH = . Cette grandeur s'utilise dans le cas des systmes forte sollicitation.
Ti

Disponibilit (availability en anglais)4 : Probabilit pour qu'un dispositif soit oprationnel au

temps t. Le systme peut avoir t rpar dans le pass.

- 10 -
3 Logigramme pour le processus de conception
Le logigramme suivant reprsente les diffrentes tapes de conception dune fonction de
scurit. Il suit la dmarche propose par les normes CEI 61508 et CD CEI 62061.

Analyse et estimation du risque pour la

fonction de scurit (systme)

Dcomposition de la fonction de
scurit en bloc fonctionnel

Cration d'une architecture pour le

systme

Dtail des exigences de scurit pour

chaque bloc fonctionnel (driv des
exigences de la fonction)

Allocation des blocs fonctionnels aux

sous-systmes

Conception du sous-systme
(dtermination des diffrentes
caractristiques)

Dtermination du SIL des sous-

systmes et du systme

4 Etude fonctionnelle du systme

Dans un premier temps, il faut procder une estimation du risque afin de dterminer les
dangers possibles pour l'oprateur et donc les fonctions de scurit qui devront tre mises en
place pour s'en affranchir.

- 11 -
4.1 Les fonctions de scurit
Il faut recenser les fonctions de scurit que le systme doit raliser. On dcrira chacune de
ces fonctions. On doit dfinir chaque fonction de scurit en une structure de blocs
fonctionnels et donner pour chaque bloc:
- la description de sa structure,
- les exigences fonctionnelle,
- la dfinition des entres/sorties (informations transmises telles que la vitesse, la
position,).

4.2 Etude de l'architecture du systme

Il faut dcomposer le systme en sous-systmes puis en modules afin d'avoir une finesse
d'analyse suffisante en fonction des donnes disponibles des diffrents lments. (Voir la
figure dallocation des exigences de scurit des blocs fonctionnels aux sous-systmes de la
norme CD CEI 62061).

A chaque niveau de dcomposition, on essaiera de descendre un niveau plus bas. On arrtera

la dcomposition en fonction des informations disponibles (connaissance des taux de
dfaillances par exemple).

4.3 Allocation des blocs fonctionnels aux sous-systmes

Il faut ensuite affecter chaque bloc fonctionnel un sous-systme.
La reprsentation en bloc fonctionnel correspond une vue de l'esprit du systme. Par contre,
le passage aux sous-systmes correspond la vue matrielle.
On peut allouer plus d'un bloc fonctionnel un simple sous-systme mais on ne peut pas
allouer un bloc fonctionnel plusieurs sous-systmes si ces sous-systmes ont des exigences
fonctionnelles diffrentes (selon CD CEI 62061).
Selon la norme CD CEI 620611, les fonctions de diagnostic ne doivent pas tre inclues dans
ces blocs fonctionnels (ce doit tre des blocs part).

5 Etude probabiliste
5.1 dun composant

Le taux de dfaillance dun composant lectronique lmentaire sera donn par le

constructeur de ce composant.

Dans la plupart des cas, le constructeur ne fournit quun taux de dfaillance global ( du
systme ou des sous-systmes). Toutefois, il ne sera pas ncessaire, en gnral, de
descendre au niveau composant, ce guide tant fait pour un assemblage de sous-systmes.

5.2 Dfaillance dangereuse et dfaillance sre

5.2.1 Prambule

- 12 -
La description ci-dessous est aborde au sens de la norme CEI 61508 ou CD CEI 62061 qui
considre que l'on peut dterminer le taux de couverture des pannes dangereuses (DC) et des
pannes sres (CS). Cela suppose donc au pralable la dtermination des dfaillances
dangereuses des fonctions de scurit du systme.

5.2.2 Dfinitions des tats

Le systme peut se trouver dans 4 types d'tats

- un tat normal,

- un tat normal dgrad,

- un tat de scurit,

- un tat de dfaillance dangereuse.

Etat normal

Dans l'tat normal, la fonction de scurit du systme est valide (le systme peut rpondre
une sollicitation) et il n'existe pas de dfaillance.

Etat normal dgrad

Dans l'tat normal dgrad, la fonction de scurit du systme est valide (en fonctionnement
ou hors ligne), des composants du systme pouvant tre dfaillants. Le systme peut ragir
lors de l'arrive d'un vnement dangereux (intrusion d'une personne dans une zone contrle
par exemple).
On peut avoir des fautes latentes ou une accumulation de fautes. Un tat non dangereux peut
trs bien comprendre une accumulation de fautes (cela correspond la catgorie 4 de la norme
EN 954). Cette accumulation de fautes ne va pas entraner un tat dangereux. La fonction de
scurit est globalement respecte mais le temps de rponse a peut-tre volu, la finesse de
dtection galement.

Etat de scurit

Il s'agit d'un tat du systme pour lequel la scurit est ralise. Cet tat peut faire suite
l'apparition d'un vnement dangereux ayant entran l'activation de la fonction de scurit, on
est donc dans le cas du fonctionnement nominal du systme.
Il peut aussi faire suite lapparition dune dfaillance. Le systme peut ainsi entrer dans cet
tat (arrt d'une machine par exemple) ds qu'une dfaillance d'un ou plusieurs composants se
produit:
- soit le systme a dtect cette dfaillance,
- soit la dfaillance n'a pas eu d'action nfaste vis vis de la scurit et a plac le systme
dans un tat sr
on parle alors de dfaillance sre ou dfaillance en scurit.

- 13 -
Etat de dfaillance dangereuse

C'est un tat du systme o la fonction de scurit n'est plus ralise, un ou plusieurs

composants tant dfaillant.
Le systme entre dans cet tat ds qu'il prsente un risque d'accident et manque de rpondre
une demande d'activation de la fonction de scurit.
on parle alors de dfaillance dangereuse.

- 14 -
5.2.3 Action des dfaillances

Toutes les dfaillances dtectes en ligne par les tests de diagnostic sont qualifies de
dfaillances dtectes. Celles qui ne sont pas dtectes sont qualifies de dfaillances non
dtectes.

Les dfaillances sres et dtectes font passer le systme de l'tat normal l'tat de scurit.
on leur associe le taux de dfaillance SD.

Les dfaillances sres et non dtectes font passer le systme de l'tat normal l'tat dgrad.
on leur associe le taux de dfaillance SU.

Les dfaillances dangereuses et dtectes auraient la potentialit de faire passer le systme de

l'tat normal l'tat de dfaillance dangereuse mais leur dtection associe une stratgie

- 15 -
scuritaire (passage en position de repli, arrt, alarme) permet au systme de le rediriger vers
l'tat de scurit.
on leur associe le taux de dfaillance DD.

Les dfaillances dangereuses et non dtectes - et uniquement celles-ci - font passer le

systme de l'tat normal l'tat de dfaillance dangereuse
on leur associe le taux de dfaillance DU.

On peut aussi amliorer la scurit du systme en effectuant des proof tests de priode plus
petite. Le proof test vrifie la fonction de scurit alors que les tests de diagnostic vrifient le
fonctionnement interne du systme. Ces proof tests sont effectus hors-ligne afin de tester la
fonction de scurit sans perturber le process (temps masqu) et de pouvoir ainsi replacer le
systme dans son tat initial (tat normal) aprs rparation. On voit donc apparatre ici 2 types
de proof test :
- soit un proof test qui va vrifier la fonction de scurit dans sa totalit (jusqu' la mise en
repli) avec donc un risque de blocage de la production et impossibilit de faire ce test sauf
en fin de poste ;
- soit un proof test qui va vrifier, lors d'un temps mort du process, que la fonction de
scurit est efficace (par exemple test de la commutation dune sortie sans mise en repli,
test de la fonction de scurit sil n'y a pas de danger comme lors de la remonte du
coulisseau d'une presse).
En rgle gnrale, un proof test a une priodicit beaucoup plus importante (intervalle entre
test plus grand) qu'un test de diagnostic et cela d au fait quil est effectu hors-ligne. On
souhaite ainsi dtecter une panne qui ne serait pas forcment vue . Par exemple, le fait qu'un
barrage immatriel ne remplisse plus sa fonction de dtection et que cela nait pas t vu par
des tests de diagnostic. Si on simule, par un proof test, lintrusion dune personne passant
travers le barrage immatriel, la fonction de scurit sera sollicite et on se rendra compte de
linefficacit du barrage. Un proof test permettra de s'assurer que cette fonction de scurit est
bien remplie et donc que la dfaillance dangereuse devient dtecte.

5.2.4 Classification / quantification des dfaillances

Si on considre que toutes les dfaillances sont rparties en dfaillances sres et dfaillances
dangereuses, il faut bien prciser ce que recouvrent ces deux termes :

- pour les dfaillances dangereuses, s'agit-il des dfaillances dangereuses dtectes seules
ou des dfaillances potentiellement dangereuses ?
- pour les dfaillances sres, s'agit-il des dfaillances sres dtectes et non dtectes ou
des dfaillances qui permettent d'entrer dans un tat de scurit ?

Ce paragraphe est destin viter dventuelles confusions.

La norme CEI 615082 (partie 6, annexe C) considre que la rpartition entre dfaillances sres
et dfaillances dangereuses peut tre dterministe pour des composants simples. Pour des
composants complexes, dont il n'est pas possible d'effectuer une analyse dtaille de chaque
mode de dfaillance, une rpartition des dfaillances en 50% sres et 50% dangereuses est
accepte :
D = S = 0,5
o est le taux de dfaillance du composant.

- 16 -
La structure des dispositifs de scurit actuels minimise les dfaillances dangereuses. Dans
notre cas, nous pourrons considrer des architectures o une seule dfaillance est dangereuse,
le but tant de dterminer la probabilit de dfaillance dangereuse du systme. Pour les
systmes ayant plusieurs canaux pour accrotre la scurit, il est moins probable qu'une
dfaillance dangereuse du matriel conduise un tat dangereux de l'ensemble ou un tat
dans lequel la fonction de scurit ne peut plus tre excute.

Ici, il faut entendre par dfaillances dangereuses les dfaillances potentiellement dangereuses
(dfaillances dangereuses non dtectes et dfaillances dangereuses dtectes non rpares)
c'est--dire :
DU + DD = 0,5

En fait, les dfaillances dangereuses dtectes et non rpares peuvent tre considres
comme des dfaillances en scurit si le temps de rparation est court. Elles sont dangereuses
uniquement tant qu'elles ne sont pas rpares.

D S

DD SD

DU SU

- 17 -
En conclusion, nous dcidons de prendre le raccourci suivant :

DEFAILLANCE DANGEREUSE = DEFAILLANCE DANGEREUSE NON-DETECTEE

DEFAILLANCE EN SECURITE = DEFAILLANCE DANGEREUSE DETECTEE ET REPAREE

+ DEFAILLANCE SURE NON-DETECTEE
+ DEFAILLANCE SURE ET DETECTEE

Compte tenu de l'hypothse ci-dessus, il en rsulte :

taux de dfaillance dangereuse = DU = D

taux de dfaillance en scurit = SU + SD + DD = S

Et, si on considre qu'il y a qui-rpartition entre les dfaillances dangereuses et les

dfaillances sres :

D = S = 0,5

5.3 dun module

Pour simplifier les calculs, la dtermination du taux de dfaillance dun module (carte
lectronique, circuit d'entre, circuit de sortie) se fera en utilisant lgalit suivante :
mod ule = composant
Ce cas correspond au pire cas puisque l'on met tous les composants en srie (sans tenir
compte des ventuelles redondances).
Il ncessite de connatre les diffrents composants et leurs taux de dfaillance.

On peut utiliser des logiciels tel que RAM Commander pour valuer le des modules partir
des des composants.

5.4 Dtermination des facteurs

5.4.1 Taux de couverture

En fonction des tests de diagnostic effectus, on pondre le taux de dfaillance. On dfinit

ainsi :
DU = D = taux de dfaillance dangereuse non dtecte= 0.5 x (1-DC) x o DC est
le taux de couverture des dfaillances dangereuses.

La dtermination du taux de couverture des diagnostics rsulte dans la plupart des cas d'un
travail d'expertise, pouvant tre guid par l'exprience ou par estimation. On les classe
gnralement en 3 catgories (CF CEI 615082) : faible (infrieur 60 %), moyen (compris
entre 60 et 90 %), lev (suprieur 99 %).

En toute rigueur, la dfinition des taux de couverture donne pour les taux de dfaillances
dangereuses dtectes :

- 18 -
 DD = 0.5 x DC x

Remarque:
Du fait de l'hypothse que l'on a faite (DU = D), l'expression de DD est interprter avec
prcaution. Dans notre cas, nous ne nous intressons qu' DU.

5.4.2 Modes communs

Dans le cas de structure redondante (multiple canaux), les modes communs reprsentent les
dfaillances qui peuvent apparatre dans les canaux suite une mme cause (par exemple une
erreur de conception ou une perturbation agissant sur les deux dispositifs).

Lintroduction des dfaillances de mode commun est gnralement modlise par le facteur
tel que :

C = : taux de dfaillances de mode commun

N = (1-) : taux de dfaillances indpendantes

= C + N

Dans le cas des dfaillances dangereuses non dtectes, on a

DUC = DU : taux de dfaillances dangereuses non dtectes de mode commun
DUN = (1-) DU : taux de dfaillances dangereuses non dtectes de mode normal.

Le choix du facteur est laiss lapprciation subjective de lutilisateur. Il varie

gnralement entre 0.5 et 5 %. (Voir la Norme CEI 615082 annexe D partie 6 qui essaie de
formaliser lvaluation de et voir aussi la thse de P. Charpentier9).

5.4.3 Intervalle de temps entre proof test

Lintervalle de temps entre proof test intervient dans le calcul de la PFDavg. Cet intervalle de
temps influe sur le niveau de scurit. (cf. B15.2 ISA-S84.01-19965).
Pour le calcul de PFDavg, on utilise un intervalle de temps entre proof test Ti qui correspond
la frquence laquelle on teste tout le systme et on suppose quaprs rparation, le systme
est comme neuf.
Pour la machinerie o les temps de cycle sont courts, on utilise gnralement un seul
intervalle de temps entre proof test pour vrifier la fonction de scurit de lensemble du
systme.

Remarque : Dans certaines applications, lindustrie du process utilise des intervalles de temps
entre proof test propres chaque sous-systme. On suppose ainsi que lon teste
fonctionnellement chaque sous-systme indpendamment les uns des autres.

- 19 -
5.5 Dtermination du dun sous-systme

Aprs avoir dcompos le systme en sous-systme, on calcule le taux de dfaillance du sous-

systme lorsque cette donne n'est pas fournie par le constructeur. Dans le cas d'un systme
utilisant un capteur d'acquisition, un automate programmable, et la commande de la partie
oprative, lautomate programmable sera considr comme un sous-systme. Le sous-systme
automate programmable est constitu dune carte dacquisition, dun ensemble logique de
traitement, dune carte de sortie.
On peut reprsenter un automate programmable comme tant constitu de 3 composants :

Unit dacquisition Unit de traitement Unit de sortie

mod ule
= composant = unit d 'acquisition + unit de traitement + unit de sortie

Il existe aussi des outils logiciels permettant de calculer le taux de dfaillance d'un ensemble
partir des lments constituant cet ensemble (par exemple RAM Commander, BQR Suite).

5.6 PFD (Probabilit de dfaillance dangereuse) du systme

Le calcul de la probabilit de dfaillance de lensemble sera dtermin aprs avoir modlis le

systme par un arbre des causes, un diagramme de Markov ou des blocs diagramme (cf.
rapport de synthse INRS7, logiciel SOFIA ou Risk Spectrum pour larbre des causes ou
MARK-EXD pour Markov).

L'arbre des causes est un modle statique bas sur la dtermination des causes amenant
l'vnement dangereux. Le logiciel Risk Spectrum permet de calculer le taux de dfaillance
global de l'ensemble. Pour dterminer le PFDavg, il faudra introduire les intervalles de temps
entre proof test Ti et reprendre un calcul formel (un outil logiciel n'est alors pas ncessaire).

Le graphe de Markov sera utile lorsque les taux de dfaillance sont constants et si on veut
ventuellement faire des calculs en considrant les taux de rparation. Il permet d'avoir une
approche dynamique (variation en fonction du temps) : un instant donn, l'tat de l'lment
est suffisant pour connatre toute sa vie future. Le graphe de Markov donnera une probabilit
de dfaillance dangereuse. C'est le modle le plus dlicat mettre en uvre mais certainement
le plus exact (si la modlisation est correcte).

Les blocs diagrammes prsentent une approche plus fonctionnelle dont l'utilisation est plus
facile. Ils ne permettent pas la modlisation de systme incluant des temps de rparation. Ils
permettent d'utiliser des lois de calculs de probabilit (modlisation srie, parallle,).
L'utilisation de cette mthode permet de calculer le PFD ou PFDavg. Il existe aussi des
logiciels de calcul (SafeCalc par exemple) qui utilisent cette modlisation. La modlisation du

- 20 -
mode commun se fera en plaant un bloc supplmentaire dans le modle qui reprsentera la
part des modes communs.

Remarque :
Il ne faut pas confondre taux de dfaillance et PFD/PFDavg. Le taux de dfaillance donne une
probabilit de dfaillance par unit de temps alors que le PFD est la probabilit que le systme
n'excute pas la fonction pour laquelle il a t conu, au moment o on le demande. On
travaille ainsi pendant une priode de temps donn.
Le PFD fait intervenir le taux de dfaillance mais aussi le taux de couverture et l'intervalle de
temps entre les proof tests.

6 Exemple de calcul
Lexemple choisi ne vise qu montrer une application pratique de la mthode et ne doit
pas tre considr comme la validation dun processus industriel existant.

Un oprateur commande la mise en marche d'une machine via un dispositif de double

commande. Plus prcisment, lorsque la double commande est sollicite, la machine peut
dmarrer. L'oprateur doit laisser constamment ses 2 mains sur la double commande. Lorsque
la machine a termin son travail, l'oprateur peut retirer ses mains des boutons poussoirs.
Une protection ultime est prvue sous la forme d'un barrage immatriel pour assurer une
protection si la double commande ne joue plus son rle.
Remarque : Dans les applications actuelles en machinerie, ce barrage sert pour les tiers et
non comme protection ultime car on fait confiance la double commande qui possde dj un
SIL ou une catgorie.

6.1 Fonctions de scurit

Dans l'exemple de l'architecture double htrogne tudie par C. Blanchet8, on peut

distinguer 2 fonctions de contrle de la scurit:
- la fonction de la commande bi-manuelle qui empche le dmarrage de la machine ou
arrte la machine,
- la fonction de dtection de personne qui coupe l'alimentation de la machine.

- 21 -
 Informations Informations Informations
"Barrage de mise en "Double
immatriel" (B.I.) marche commande" (D.C.)

Traitement 1 Traitement 2 Traitement 1 Traitement 2

B.I. B.I. D.C. D.C.

Comparaison Comparaison

Information de
Informations de double Informations
Information de
fin du travail commande de mise en
franchissement du
dangereux valide marche
barrage

Traitement 1 Traitement 2
Commande de la
processus processus
machine

Comparaison
Commande sre de scurit
de la machine

6.1.1 Dtection de personne

Cette fonction a lieu lorsque le barrage immatriel dtecte le franchissement ou l'intrusion

dans la zone. La sortie de ce barrage est duplique. Chaque information est envoye vers un
API. Le rsultat du traitement est ensuite compar et envoy directement vers la machine pour
couper l'alimentation (envoi vers l'actionneur).
La fonction de scurit est donc l'arrt de la machine lors de la dtection du franchissement
travers le barrage immatriel.

6.1.2 Commande bi-manuelle

La double commande doit tre actionne pour enclencher le dmarrage de la machine et

maintenue en position pour continuer le processus. La fonction de scurit est donc l'arrt de
la machine si l'on relche l'appui sur 1 ou les 2 boutons de la double commande pendant le
mouvement dangereux (et non pas, comme on pourrait le penser, le dmarrage d'un cycle).

- 22 -
On a aussi comme fonction de scurit l'empchement de dmarrage de la machine en cas
d'appui dsynchronis.
Les signaux de la double commande sont envoys vers 2 API, le rsultat du traitement est
compar pour permettre la commande de l'alimentation de la machine.

On traitera dans la suite la fonction de scurit relative la dtection de personnes.

- 23 -
 6.2 Dcomposition en blocs fonctionnels
On doit donner un titre fonctionnel chaque bloc.

Bloc fonctionnel 1

Bloc fonctionnel 4 Bloc fonctionnel 5

INPUT Bloc fonctionnel 3
Information du barrage
immatriel Comparaison des OUTPUT
(sortie :signal lec 0V- Logic Solver signaux des 2 canaux Commande de la
24V) Traitement des signaux machine
d'entre venant des
Bloc fonctionnel 2 capteurs (sortie 0V-24V)

Acquisition des donnes

d'tat de fonctionnement
de la machine, position du
coulisseau par exemple

6.3 Architecture du systme

L'architecture doit tre dfinie en fonction du design et de la dcomposition fonctionnelle faite ci-dessus.

CAPTEUR LOGIQUE ACTIONNEUR

Sous Systme 1 Sous Systme 2 Sous Systme 3

Barrage immatriel Traitement logique Commande de la

machine

- 24 -
6.4 Allocation des blocs fonctionnels aux sous-systmes
On peut utiliser un schma du type tel que celui propos dans la norme CEI620611
Remarque : On peut associer plusieurs blocs fonctionnels un sous-systme.

Dcomposition
seulement si
ncessaire pour le
design du sous-
systme
Vue virtuelle :
dcomposition
fonctionnelle
Coupure de
Traitement Acquisition Comparaison l'alimentation
Dtection de personnes Decompose
Dtection du donnes tat
logique
F = FB1+FB2+FB3+FB4+FB5 franchissement machine
All
oca
tion

1
Systme Architecture Barrage immatriel
API 1 et API 2 Commande

Acquisition canal 1: Vue relle :

dtection et tat machine architecture

Traitement canal 1

Acquisition canal 2:
dtection et tat machine

Traitement canal 2

- 25 -
6.5 Exigences de scurit pour chaque bloc fonctionnel
Voir CEI620611

Note:
Les exigences de scurit consistent dterminer le SIL requis. La norme CD CEI 62061 ne
donne pas la mthode pour dterminer le SIL requis pour un bloc fonctionnel. Il faut juste
s'assurer que SILsys<= (SILsubsytem)lowest.
Par contre, pour la fonction de scurit, la norme CD CEI 62061 prcise qu'il faut faire une
estimation du risque pour dterminer le SIL requis (exig).

6.6 Exigences fonctionnelles

6.6.1 Bloc 1 : dtection de franchissement

Exigences fonctionnelles
Entre : Franchissement ou non-franchissement du barrage.
Fonctionnalit : Dtection du franchissement du barrage par une personne.
Sortie : la sortie d'un barrage immatriel est compose soit d'une sortie statique (en fait un
transistor interne au barrage qui est aliment par l'extrieur et qui va pouvoir gnrer le
signal) ou par une sortie relais. La sortie est donc du type contact libre de potentiel,
l'utilisateur choisissant sa propre alimentation suivant ses besoins.

6.6.2 Bloc 2 : acquisition des donnes tat machine

Exigences fonctionnelles
Entre : tat de la machine (position du coulisseau et non pas mode de fonctionnement).
Fonctionnalit : donner la position de la machine.
Sortie : tat de fonctionnement de la machine.

6.6.3 Bloc 3 : traitement logique

Ces blocs correspondent aux API.

Exigences fonctionnelles
Entre : Signal 0V-24V venant du barrage immatriel et signal de fonctionnement de la
machine.
Fonctionnalit : Si la machine est en fonctionnement et signal du barrage 0V, alors il faut
couper l'alimentation (intrusion dans la zone lors du fonctionnement). De plus, si la machine
est arrte, l'oprateur actionne la double commande et le signal du barrage passe 0V, il faut
couper l'alimentation de la machine dangereuse.
Sortie: Dsactiver la commande de la machine.

6.6.4 Bloc 4 : comparateur

Exigences fonctionnelles
Entre : signal 0V-24V venant des sorties des API.
Fonctionnalit : s'il y a une discordance entre les 2 signaux, il faut couper l'alimentation de la
machine. Sinon, le signal est envoy tel quel vers la commande de la machine.

- 26 -
Sortie : signal 0V-24V coupure de l'alimentation.

6.6.5 Bloc 5 : Arrt de la machine (ou mcanisme d'arrt)

Exigences fonctionnelles
Entre: signal venant du comparateur.
Fonctionnalit : dclencher le mcanisme d'arrt.
Sortie: machine arrte.

6.7 Dtermination des taux de dfaillances

Le MTBF d'un quipement peut tre fourni par son constructeur. En gnral, ce MTBF est
prvisionnel (calcul par utilisation de bases de donnes composant). Parfois, les
constructeurs disposent de suffisamment de retour d'exprience sur leurs matriels en
exploitation pour fournir un taux de dfaillance rel.

6.7.1 Sous-systme 1

Le taux de dfaillance du barrage immatriel est fourni par le constructeur. Le barrage

immatriel est un barrage constitu de 2 cellules photolectriques.
Attention, en fonction de la charge en sortie, la dure de vie du barrage immatriel pourra tre
fortement diminue. En effet, des relais sont utiliss en sortie pour transfrer l'information du
barrage. Or il est communment admis que des relais peuvent subir en fonctionnement normal
106 manuvres. En fonction du courant appliqu sur ces contacts et de la nature de la charge
(capacitive ou inductive donc risque d'tincelles), le nombre de manuvre sera fortement
rduit et le MTBF de l'ensemble pourra ne pas correspondre au MTBF calcul. De plus, si l'on
considre que le systme est sollicit toutes les 10 s, au bout de 2780h de fonctionnement, le
relais aura atteint les 106 commutations. Par contre, si on sollicite le barrage toutes les 2h, on
aura atteint les 106 commutations au bout de 228 ans de fonctionnement.

Pour information, 1,9% des barrages de ce type reviennent en usine pour rparation.

6.7.2 Sous-systme 2
Ce sous-systme est compos de deux automates programmables diffrents.

6.7.2.1 Automate A

Entre Unit Sortie

Module Module
dextension
centrale dextension

Diagramme de fiabilit de lautomate A

- 27 -
 En terme de taux de dfaillance, le diagramme ci-dessus se traduit de la faon suivante :
API = Entre + UC + Sortie .

D'aprs les dfinitions du 2 concernant le MTBF, on a

Module 1 1
Entre = Sortie = =
Nombred ' E / S MTTFModule Nombred ' E / S MTBFModule Nombred ' E / S
.
Et, UC = 1 1
MTTFUC MTBFUC

Pour l'automate A, on a les valeurs suivantes fournies par le constructeur :

MTTFModule = 228ans , Et, donc
1 1 2 1
API 2 + = + 4,11.10 6 dfaillances
MTBFModule Nombred ' E / S MTBFUC 228 8 25
/h

6.7.2.2 Automate B

Entre/Sortie Unit
Module dextension
centrale

API = Entre / Sortie + UC

Or le constructeur nous a fourni

UC = 22.1 10-6
E/S = 1.1 10-6 (pour une carte)

d'o API = 23.1 10-6 dfaillances par heure (avec une carte E/S)

6.7.3 Sous-systme 3

Le sous-systme 3 peut tre ralis partir :

Dun comparateur. Le bloc fonctionnel "commande de la machine" n'est plus
ncessaire. On considrera que le signal de commande est envoy par le comparateur
et le sous-systme 3 nexiste plus. La fonction de scurit s'arrte l'ordre envoy.
Dune lectrovanne double corps. La commande ainsi que la fonction comparateur
sont effectues par l'lectrovanne. Il faudra alors obtenir le taux de dfaillance de cette
lectrovanne.

- 28 -
6.8 Dtermination des facteurs

6.8.1 Sous-systme 1

Le fournisseur de ce sous-systme ne peut pas nous donner les taux de couverture, la

proportion de pannes dangereuses et sres ainsi que l'intervalle de temps entre proof test.

On ne dispose que du du barrage, ce qui conduit prendre arbitrairement :

Dbarrage = 0.5 x (1-DCbarrage) x barrage

Le barrage tant de catgorie 4, on considrera que le taux de couverture des tests de

diagnostics est gal DCbarrage = 99%.

Le barrage immatriel n'est pas redondant donc il n'y a pas de modes communs pour ce
barrage.

Le temps entre deux proof tests conscutifs (test fonctionnel) sera pris arbitrairement gal Ti
= 168 h (1 mois).

6.8.2 Sous-systme 2

On considrera pour les calculs que les deux APIs ont les mmes caractristiques de fiabilit
et les mmes taux de couverture, proof tests, Ces valeurs seront celles considres pour
lautomate A.

On ne dispose que du global de l'API, ce qui conduit prendre

DAPI = 0.5 x (1-DCAPI) x API

Le fournisseur de l'API ne nous a pas donn un taux global mais a simplement donn les taux
de couverture des tests internes (test de la RAM par exemple).
Pour l'API, on considre que son taux de couverture des dfaillances dangereuses est de
DCAPI = 90%. Ce taux de couverture est donn titre indicatif pour permettre dvaluer la
probabilit de dfaillance. Il doit certainement tre suprieur au taux de couverture rel.

On considrera tout dabord les deux automates comme tant homognes (les paramtres de
calculs retenus seront ceux de lautomate A et on ne considrera pas les modes communs).

Pour les API, on considre que l'intervalle de temps entre proof test est gal la vie de
lquipement soit 10 ans, ce qui revient dire que l'automate n'est jamais test compltement
fonctionnellement durant toute sa dure de vie;
Ti = 87700 h.

Nous allons prsent insister sur linfluence des paramtres taux de couverture et
intervalle entre proof test sur la dtermination de la PFD.

- 29 -
 Lintervalle de temps entre proof test ou temps de mission Ti sert comme base de calcul pour
la valeur moyenne de la PFD. Les tests de diagnostics interviennent dans le calcul du taux de
dfaillance par l'intermdiaire du taux de couverture.

En effet, dans la mesure o aprs un proof test, le systme est considr comme neuf, il ne
doit plus y avoir de dfaillance la demande. PFDavg tant une valeur moyenne par rapport au
Ti, il peut bien y avoir une indpendance entre le taux de couverture des tests de diagnostics et
le temps entre deux proof tests conscutifs Ti.

Pour l'impact de l'intervalle entre tests de diagnostics, voire la partie dfinition. On rappellera
ici que l'intervalle entre tests de diagnostics doit tre suffisamment petit devant le temps entre
2 dfaillances MTBF (facteur 100 au moins) pour que l'on puisse ngliger le temps de
rparation devant le temps entre deux dfaillances.

6.8.3 Sous-systme 3

On considre que la machine est commande par une lectrovanne.

Dcommande = 0.5 x (1-DCcommande) x commande

De faon arbitraire, on prendra un taux de couverture de 90% et un temps Ti entre proof tests
gal 12 mois soit 8770h. Les dfaillances de mode commun nont pas de sens.

6.9 Architecture avec 2 API identiques : cas de la faible sollicitation

On considre ici que les deux automates ont le mme taux de dfaillances, sans modes
communs (=0)

sous-systme mode taux de intervalle de temps D

commun couverture DC entre proof test Ti
en heures en mois
barrage 0 99% T1 = 168 1 5.0 10-9 2.5 10-11
immatriel
API1 0 90% T2 = 87700 120 4.1 10-6 2.05 10-7
API2 0 90% T2 = 87700 120 4.1 10-6 2.05 10-7
commande 0 90% T3 = 8770 12 5.0 10-8 2.5 10-9

- 30 -
6.9.1 PFDavg du systme par la mthode des blocs diagrammes

6.9.1.1 Calcul manuel

Rappels :

On nommera ri la fiabilit de llment i du diagramme.

Pour des lments en srie,

1 2 n

la fiabilit est donne par

n
R (t ) = ri (t )
1

Pour des lments en //,

la fiabilit est

n
R (t ) = 1 (1 ri (t ) )
1

Les diffrents types d'architecture d'un systme redondant ont t modliss dans la
norme CEI 615082. On rappelle ici les principaux types d'architecture avec deux
canaux9:
- 1oo2 (1 out-of 2) qui est une architecture constitue de deux canaux connects en
parallle ralisant chacun la fonction de scurit. Les tests de diagnostics qui

- 31 -
 existent ne changent pas l'tat de la sortie et il faut une dfaillance des deux
canaux pour avoir une dfaillance dangereuse.
- 1oo2D (1 out-of 2D) qui est une architecture constitue de deux canaux connects
en parallle. En fonctionnement normal, les deux canaux doivent demander la
fonction de scurit avant que celle-ci ne soit active. Si les tests de diagnostic
dtectent une dfaillance sur un des canaux, la sortie considre sera celle du canal
exempt de faute. Si les tests de diagnostic dtectent une faute ou une diffrence
entre les deux canaux ne pouvant tre attribue l'un des canaux, la sortie sera
positionne dans un tat sr. Cette architecture est plus approprie pour du process
ou pour privilgier la disponibilit.
- 2oo2 (2 out-of 2) qui est une architecture dans laquelle les deux canaux sont
connects en parallle de telle sorte que les deux canaux doivent demander la
fonction de scurit avant que celle-ci ne soit active. Les tests de diagnostics
signalent les fautes mais ne changent pas l'tat de la sortie.

Dans notre cas, la partie logique est constitue de 2 API monts en parallle. Pour des raisons
de scurit, on souhaite que ds qu'un des deux canaux demande la fonction de scurit, le
systme soit arrt. De plus, le systme passe en scurit en cas de dsaccord des 2 sorties et
un signal est renvoy vers l'entre des API. La logique correspondante est soit 1oo2, soit
1oo2D. On peut associer la discordance une architecture 1oo2D (si une diffrence existe
entre les deux canaux alors on positionne la sortie dans un tat sr) car on ne sait pas
distinguer quel est le canal en panne. Il faudrait demander l'oprateur un test supplmentaire
pour dterminer le canal en panne. Par contre, l'tat de la sortie n'est pas modifi par les tests
de diagnostics.
On a donc ici une logique 1oo2 puisque les tests de diagnostics ne modifient pas directement
l'tat de la sortie (c'est la comparaison entre les deux API qui oriente l'tat de la sortie vers
l'tat sr) et il faut une dfaillance des deux canaux pour avoir une dfaillance dangereuse.

Le problme est de quantifier le taux de couverture de la dtection des discordances au niveau

du comparateur. Il parat impossible de dterminer tous les dfauts dont les consquences se
manifestent par un cart de temps de traitement entre les deux voies (pas de dsynchronisme).
On ne dtecte pas les pannes latentes qui se rvleront un cycle plus tard ou dans un autre
mode de marche.

Les taux de couverture sont donns pour caractriser les tests de diagnostics faits en interne
(dans un API ou dans le barrage) comme les tests ddis (test CPU, test de la mmoire). Ils ne
prennent pas en compte des mcanismes de dtection tels que celui fait par le comparateur
pour dtecter une incohrence entre les 2 canaux. De mme, si on introduit du dynamisme
comme mcanisme de dtection de fautes, il sera difficile de quantifier cet apport par un taux
de couverture. Comment estimer alors le taux de couverture de ce mcanisme pour la
dtection de pannes dangereuses? En effet, nous travaillons dans notre cas sur des tats tablis
donc nous ne voyons pas forcment si une entre ne change pas d'tat.
La quantification des taux de couverture reste donc aujourd'hui trs approximative.

Dans les calculs qui suivent, on ne peut pas parler en toute rigueur de fiabilit puisque l'on
considre uniquement les pannes dangereuses non dtectes. Toutefois, pour des raisons de
simplicit, nous emploierons le terme fiabilit.

La fiabilit R(t) de la partie logique, dans ce cas de redondance parallle, est donne par :
Rlogique = 1-[(1-rAPI1)(1-rAPI2)].

- 32 -
En considrant une loi de distribution exponentielle,
1-rAPI1(t) = 1-e-api1 t DAPI1* t
1-rAPI1(t) = 1-e-api2 t DAPI2* t
d'o Rlogique(t) = 1-DAPI1DAPI2 * t2

La fiabilit du barrage est donne par

dbarrage t
Rbarrage (t ) = e 1 barrage
D
t

La fiabilit de la commande est donne par

d
Rcommande (t ) = e commandet 1 commande
D
t

Pour le systme complet, la fiabilit de l'ensemble (association en srie des 3 sous-systmes)

est
Rsystme = Rbarrage * Rlogique * Rcommande

Rsystme(t) = (1-Dbarrage t) (1-Dcommande t)( 1-DAPI1DAPI2 * t2)

et
PFDsystme(t) = 1- Rsystme(t) = 1-(1- Dbarrage t) (1-Dcommande t)(1-DAPI1DAPI2 * t2)
PFDsystme(t) = DAPI1DAPI2 * t2 + Dbarrage t + Dcommande t - Dbarrage Dcommande t2 -
DbarrageDAPI1DAPI2 t3 -Dcommande DAPI1DAPI2 t3 + Dbarrage Dcommande DAPI1DAPI2 t4

6.9.1.1.1 Intervalle de temps entre proof test identique pour tous les sous-systmes

Pour avoir le PFDavg, il faut calculer

T
1 i
PFDavg = PFD (t) dt
Ti 0
d'o
PFDavg = (Dbarrage + Dcommande) Ti/2 + (DAPI1DAPI2 -DcommandeDbarrage)Ti2/3 (Dbarrage +
Dcommande) DAPI1DAPI2 Ti3/4 + DbarrageDcommandeDAPI1DAPI2 Ti4/5

On considre ci-dessus que le temps Ti entre proof test est le mme pour tous les composants.

On prendra un intervalle entre proof test Ti de 87700h soit le temps de mission.

On obtient:

Blocs diagrammes
PFDavg 2.18445 10-4

Si on prend un intervalle entre proof test Ti de 168h, on a le rsultat suivant :

Blocs diagrammes
PFDavg 2.1249 10-7

- 33 -
6.9.1.1.2 Intervalle de temps entre proof test diffrent pour chaque sous-systme

Si on veut calculer la valeur moyenne pour diffrents intervalle de temps entre proof test (de
chaque sous-systme), on peut utiliser le calcul suivant :
PFDavg =
1
[ D D D D
]
1 (1 barrage t1 )(1 commande t 3 )(1 API1 API 2 t 2 ) dt1 dt 2 dt 3
2

TTT1 2 3

avec
T1 = 1 mois soit 168h pour le barrage
T2 = 120 mois (10 ans) soit 87700h pour les API
T3 = 12 mois soit 8770h pour la commande
soit
T1 T T2
PFDavg = 1 1 barrage 1 commande 3 1 API 1 API 2 2
D D D D

2 2 3
et donc, avec les valeurs prsentes au dbut de ce chapitre, on a
PFDavg = 1-(1-2.1 10-9)(1-1.09625 10-5)(1-1.07742154083 10-4)
PFDavg = 1.1871 10-4

6.9.1.2 Utilisation du logiciel SafeCalc

Ce logiciel ne fait que des calculs numriques associs une modlisation par blocs
diagramme. On supposera par exemple que les taux de dfaillances sont :
- pour le barrage immatriel, on prendra comme prcdemment barrage = 5 10-9
- pour la commande, on prendra un commande = 5 10-8

Ce logiciel utilise les taux de pannes de base du composant, on entre les taux de couverture
et le SIL obtenu est de 3.

- 34 -
Dans ce cas, Ti pour le sensor group est de 1 mois soit 168h, 120 mois correspond 10 ans
pour la partie logique et 12 mois pour l'actionneur. On rappelle que le Ti caractrise
l'intervalle de temps entre chaque proof test (test de maintenance qui remet le systme comme
neuf).

On a donc les rsultats suivants:

PFDavg
Calcul manuel 1.18 10-4
Outil informatique SafeCalc 1.19 10-4

Remarque:
Dans le logiciel SafeCalc, il faut entrer une valeur pour le MTTR. Compte tenu de la valeur
leve des temps considrs par rapport au temps de rparation, l'impact du MTTR sur la
valeur du PFDavg est trs faible. L'utilisation du MTTR par le logiciel SafeCalc doit tre utile
pour dterminer les temps d'indisponibilit du systme. On ne peut pas utiliser le logiciel
SafeCalc avec 2 parties logiques diffrentes ( logic solver ayant des valeurs de taux de
dfaillances diffrents).

6.9.1.3 Utilisation d'autres outils

La description dtaille de ces outils sera faite en Annexe. Tous ces outils ne donnent pas la
PFD mais le MTBF ou le taux de dfaillance.

- 35 -
Exemple de loutil Reliability Workbench
On obtient un MTBF = 3.96 108 soit un taux de dfaillance de 2.53 10-9. On obtient ici un
taux de dfaillance et non pas la PFDavg. Ces deux notions ne sont pas les mmes puisque
dans la PFDavg intervient l'intervalle de temps entre proof test.

6.9.1.4 Remarques concernant les normes CEI 61508 et CD CEI 62061

Les normes CEI 61508 et CD CEI 62061 proposent pour le calcul de la PFD du systme :
PFDsystme = PFDsous-systme
Dans ce cadre, on a donc
PFDsystme = PFDbarrage + PFDlogique + PFDcommande

PFDbarrage(t) = 1-Rbarrage(t) = Dbarrage t

PFDlogique(t) = 1-Rlogique(t) = DAPI1DAPI2 t2
PFDcommande(t) = 1-Rcommande(t) = Dcommande t
soit PFDsystme(t) = Dbarrage t + DAPI1DAPI2 t2 + Dcommande t

Dans le cas dun intervalle de temps entre proof test diffrent pour chaque sous-systme et
pour des taux de dfaillance identiques pour les automates, on a

[ ( ) ]dt dt dt
1 2
PFDavg = D
t + commande
barrage 1
D
t 3 + DAPI t 2 1 2 3
T1T2T3

( DAPI T2 ) 2
PFDavg = Dbarrage T1/2 + Dcommande T3/2 +
3

soit
PFDavg = 1.187 10-4

- 36 -
6.9.2 PFDavg du systme par arbre des causes

On peut reprsenter l'arbre des causes de la faon suivante:

Dfaillance dangereuse

ou

ET

Barrage Organe de
API 1 API 2 commande de la
machine
(lectrovanne)

Cet arbre prend en compte uniquement les dfaillances dangereuses non dtectes puisque ce
sont celles qui contribuent la valeur de la PFD.

On utilisera le logiciel Risk Spectrum pour obtenir le taux de dfaillances.

6.9.2.1.1 Intervalle de temps entre proof test diffrent pour chaque sous-systme

Dans ce cas, en utilisant la faon de calculer la PFD telle que dans l'ISA4, on a :
PFD = Dbarrage Ti barrage + Dcommande Ti commande + (DAPI Ti API)2.

Cette expression est obtenue en regardant dans l'arbre des fautes les contributions
l'vnement dangereux. Un "OU" donne une addition, un "ET" donne un produit. Chaque
partie tant le produit du taux de dfaillance dangereuse non dtecte par l'intervalle de temps
entre proof test.

On a donc

[ ( ) ]dt dt dt
1 2
PFDavg = D
t + commande
barrage 1
D
t 3 + DAPI t 2 1 2 3
T1T2T3

- 37 -
 ( DAPI T2 ) 2
PFDavg = Dbarrage T1/2 + Dcommande T3/2 +
3

soit
PFDavg = 1.187 10-4

6.9.2.1.2 Intervalle de temps entre proof test identique pour chaque sous-systme

( DAPI Ti ) 2
PFDavg = Dbarrage
Ti/2 + DcommandeTi/2 +
3
On prendra un intervalle entre proof test Ti de 87700h soit le temps de mission.
On obtient:

Arbre des fautes

PFDavg 2.1846 10-4

Si on prend un intervalle entre proof test Ti de 168h, on a les rsultats suivants :

Arbre des fautes

PFDavg 2.1249 10-7

6.9.3 PFDavg du systme par diagramme de Markov

tat dangereux: tat n2.

Ce diagramme est un cas simple, il faudrait tenir compte des dfaillances dtectes et non
dtectes, dangereuses et non dangereuses.

2 DAPI
1
API en DAPI
panne
OK
0
2
Danger

Dbarrage + Dcommande

- 38 -
On obtient ainsi la matrice de transition de l'ensemble

1 2 DAPI barrage
D
commande
D
2 DAPI barrage
D
+ commande
D


P= 0 1 DAPI API
D

0 0 1

Il faut ensuite partir de l'tat de dpart S = (1 0 0), calculer par itrations successives la
matrice Si = Si-1 P et la PFD associe.

Pour obtenir le PFDavg, il faut en mme temps calculer la moyenne des PFD donc calculer
pour chaque itration le PFDi = PFDi-1 + Probai(tat 2).
(PFDavg = PFD/nombre de pas de calculs).

Dans ce cas, on ne peut pas avoir plusieurs intervalles de temps entre proof test. La valeur que
l'on va choisir pour le nombre d'itrations correspond la valeur du Ti et on ne peut prendre
en compte qu'une seule valeur pour tous les sous-systmes.

On peut reprsenter cela par l'algorithme suivant:

S = (1 0 0)
Sint = S*P
PFDavgint = Sint(3); cela correspond la troisime composante de la matrice

for i=1 to Ti
S=Sint*P
Sint=S
PFDavgint = PFDavgint + S(3)
endfor

PFDavg = PFDavgint/Ti

La valeur numrique de la matrice est :

0.9999995875 4.1 10 7 2.525 10 9

P= 0 0.999999795 2.05 10 7 en prenant les D incluant les taux de
0 0 1

couverture.

On obtient les valeurs suivantes en fonction de Ti :

Ti PFDavg
168 2.13753 10-7
8770 1.2136 10-5
87700 2.1569 10-4

On trouvera le dtail de la dmarche dans le chapitre 8 de Goble4.

- 39 -
6.9.4 Introduction des modes communs

On prsentera succinctement les cas pour le bloc diagramme et larbre des fautes. Pour de
plus amples informations, on pourra se rfrer Goble4 et Charpentier9.

6.9.4.1 Bloc diagramme

Il faut ajouter un bloc en srie avec les API qui modlisera les modes communs.

La fiabilit de cette partie logique sobtiendra par le calcul suivant :

Rlogique (t) = [1-(1-r indpendant API (t))(1-r indpendant API(t))]r commun API(t)
d
Avec r commun API (t) = e API t 1 DAPI t
r normal API (t) = 1-e-API t DAPI* t

6.9.4.2 Arbre des causes

Dfaillance dangereuse

ou

ET

Barrage Organe de
API 1 API 2 commande de la
machine
(lectrovanne)
Mode commun API 1 et 2

- 40 -
Dans ce cas, en utilisant la faon de calculer le PFD telle que dans l'ISA4 et en considrant les
deux automates homognes de taux de dfaillance API, on a :
PFD = Dbarrage Ti barrage + Dcommande Ti commande + ((1-) DAPI Ti API)2 + DAPI Ti API

6.10 Architecture avec 2 API diffrents : cas de la faible sollicitation

On considre maintenant deux APIs 1 et 2 diffrents, sans modes communs. Nous utiliserons
les valeurs suivantes :

Barrage API 1 API 2 Commande

Taux de 2.5 10-11 2.05 10-7 1.15 10-6 2.5 10-9
dfaillance
dangereuse non
dtecte
Intervalle entre 168 87 700 87 700 8770
proof test (h)

La valeur du taux de dfaillance pour lAPI2 est obtenue en prenant les valeurs = 23.1 10-6,
DC = 0.9 de lautomate B.

6.10.1 PFDavg par la mthode des blocs diagrammes

6.10.1.1 Intervalle de temps entre proof test diffrents

Il suffit de reprendre la formule

T1 T3 T22
PFDavg = 1 1 barrage 1 commande 1 API 1 API 2
D D D D
et l'on a :
2 2 3
PFDavg = 6.1536 10-4

6.10.1.2 Intervalle de temps entre proof test unique

On utilise lexpression trouve au paragraphe prcdent:

PFDavg = (Dbarrage + Dcommande) Ti/2 + (DAPI1DAPI2 -DcommandeDbarrage)Ti2/3 (Dbarrage +
Dcommande) DAPI1DAPI2 Ti3/4 + DbarrageDcommandeDAPI1DAPI2 Ti4/5

Blocs diagrammes
PFDavg (Ti 87 700 heures) 7.1503 10-4
PFDavg (Ti 168 heures) 2.1432 10-7

6.10.2 PFDavg par la mthode de larbre des causes

6.10.2.1 Intervalle de temps entre proof test diffrents

On reprend lexpression trouve dans le paragraphe prcdent :

- 41 -
 DAPI 1 API 2 T2 2
D

PFDavg = Dbarrage T1/2 + Dcommande T3/2 +

3

d'o PFDavg = 6.1537 10-4

6.10.2.2 Intervalle de temps entre proof test unique

Pour la mthode utilisant l'arbre des causes, on utilise :

DAPI 1 API 2 Ti 2
D
D D
PFDavg = barrage Ti/2 + commande Ti/2 +
3
On obtient

Arbre des causes

PFDavg (Ti 87 700 heures) 7.1513 10-4
PFDavg (Ti 168 heures) 2.1432 10-7

6.10.3 PFDavg par la mthode du graphe de Markov

La mthode matricielle par graphe de Markov ne permet pas de donner la PFDavg dans le
cas dintervalles entre proof test multiples.
Le calcul avec des taux de dfaillances diffrents ne sera pas excut ici. La modlisation du
comportement est plus complique et napportera rien concernant lapplication de la mthode.

6.11 Rcapitulatif des rsultats pour PFDavg

Bloc diagramme Arbre des causes Markov

PFDavg (Ti diffrent, API gaux) 1.186 10-4 1.187 10-4 N/A
PFDavg (Ti unique = 168h, API gaux) 2.1249 10-7 2.1249 10-7 2.137 10-7
-4
PFDavg (Ti unique = 87 700h, API gaux) 2.1844 10 2.1846 10-4 2.1569 10-4
PFDavg (Ti diffrent, API diffrents) 6.1536 10-4 6.1537 10-4 N/A
-7
PFDavg (Ti unique = 168h, API diffrents) 2.1431 10 2.1431 10-7 -
-4
PFDavg (Ti unique = 87 700h, API gaux) 7.150 10 7.151 10-4 -

Il faudra faire attention lors du calcul matriciel au nombre ditrations qui seront prises en
compte. En effet, on approxime la valeur de PFDavg en faisant une somme destine calculer
la valeur moyenne. Or, une valeur moyenne tant une intgrale, le calcul de cette valeur par
itrations sera plus prcis si le nombre de pas de calcul est important. Plus le Ti est grand,
plus le nombre ditrations est grand et meilleur sera le rsultat obtenu.

6.12 Cas de la forte sollicitation

Pour les systmes en forte sollicitation, il faut dterminer la probabilit de dfaillance
dangereuse par heure PFH. On rappelle que
PFH = PFD/Temps de mission.
Dans ce cas, on ne peut quutiliser des intervalles entre proof tests uniques ; il ne faudra donc
pas comparer avec les valeurs de PFDavg obtenues pour des intervalles de temps entre proof
tests multiples.

- 42 -
6.12.1 Mthode des blocs diagrammes
On rappelle ci-dessous l'expression trouve pour PFD
PFDsystme(t) = DAPI1DAPI2 * t2 + Dbarrage t + Dcommande t - Dbarrage Dcommande t2 -
DbarrageDAPI1DAPI2 t3 -Dcommande DAPI1DAPI2 t3 + Dbarrage Dcommande DAPI1DAPI2 t4

Si on utilise un intervalle de temps entre proof test unique, on a lexpression

PFD = DAPI1DAPI2 * Ti 2 + Dbarrage Ti + Dcommande Ti - Dbarrage Dcommande Ti 2-
DbarrageDAPI1DAPI2 Ti 3-Dcommande DAPI1DAPI2 Ti 3 + Dbarrage Dcommande DAPI1DAPI2 Ti 4

Do
PFH = PFD/Ti = DAPI1DAPI2 * Ti + Dbarrage + Dcommande - Dbarrage Dcommande Ti -
DbarrageDAPI1DAPI2 Ti 2-Dcommande DAPI1DAPI2 Ti 2 + Dbarrage Dcommande DAPI1DAPI2 Ti 3

Pour un intervalle entre proof test de 10 ans et pour une architecture API identique,
PFH = 6.21 10-9

6.12.2 Arbre des causes

PFH = PFD/temps de mission

Lexpression de PFD a t obtenue dans le paragraphe PFDavg du systme par arbre des
causes
PFD = Dbarrage Ti + Dcommande Ti + DAPI1 DAPI2 (Ti API)2

PFH = Dbarrage + Dcommande + DAPI1 DAPI2 Ti

Pour un intervalle entre proof test de 10 ans et pour une architecture API identique,
PFH = 2.5 10-11 + 2.5 10-9 + (2.05 10-7)2 87700
PFH = 6.21 10-9

6.12.3 Graphe de Markov

On rappelle la matrice de transition de l'ensemble

1 2 DAPI barrage
D
commande
D
2 DAPI barrage
D
+ commande
D


P= 0 1 DAPI API
D

0 0 1

Il faut ensuite partir de l'tat de dpart S = (1 0 0), calculer par itrations successives la
matrice Si = Si-1 P et la PFD associe qui est la 3ime composante de la matrice S.

Dans ce cas, on ne peut pas avoir plusieurs intervalles de temps entre proof test. La valeur que
l'on va choisir pour le nombre d'itrations correspond la valeur du Ti et on ne peut prendre
en compte qu'une seule valeur pour tous les sous-systmes.

- 43 -
On peut reprsenter cela par l'algorithme suivant :
S = (1 0 0)
Sint = S*P
PFD = Sint(3); cela correspond la troisime composante de la matrice

for i=1 to Ti
S=Sint*P
Sint=S
endfor
PFHint = S(3)

PFH = PFHint/Ti

La valeur numrique de la matrice est :

0.9999995875 4.1 10 7 2.525 10 9

P= 0 0.999999795 2.05 10 7 en prenant les D incluant les taux de

0 0 1
couverture.

On obtient les valeurs suivantes en fonction de Ti :

Ti PFH
168 2.531 10-9
8770 2.888 10-9
87700 6.099 10-9

6.12.4 Comparaison entre les diffrentes mthodes

Pour un temps entre proof test de Ti = 87700 h, on a

Bloc diagramme Arbre des fautes Markov

PFH 6.21 10-9 6.21 10-9 6.10 10-9

- 44 -
7 Rcapitulatif des hypothses faites
Rappel :
Les notions abordes dans ce document (taux de dfaillance, probabilit de dfaillance
dangereuse) ne concernent que les pannes matrielles alatoires.

1) Le temps d'indisponibilit (temps de dtection de la panne, rparation et remise en service)

est considr petit devant le MTBF donc on confond le MTTF et le MTBF. Les pannes
dangereuses dtectes sont donc considres rpares rapidement.
L'intervalle de temps entre test de diagnostic est petit devant le MTBF (facteur 100).

Ces deux hypothses permettent de considrer comme dangereuse uniquement les pannes
dangereuses non dtectes.
Les pannes potentiellement dangereuses qui sont dtectes sont considres comme rpares
suffisamment rapidement pour ne pas tre dangereuses.

2) On suppose une rpartition 50% pannes dangereuses, 50% pannes sres; ceci permet
d'utiliser dans le calcul du PFD le taux de dfaillance donn par le constructeur ou calcul
l'aide des bases de donnes de fiabilit pour obtenir le taux de dfaillance des pannes
dangereuses.
D = 0.5

3) Le taux de couverture des tests de diagnostic est approxim dans la plupart des cas. La
mthode plus rigoureuse consisterait faire une analyse des modes de dfaillances (qui
ncessite en toute rigueur de connatre les modes de dfaillance des composants ou modules).

4) La dtermination de la valeur de caractrisant le mode commun reste l'heure actuelle

une estimation d'expert.

5) Pour le calcul de PFDavg, le temps entre deux proof tests conscutifs Ti doit tre dtermin
en fonction des contraintes dexploitation ainsi que des spcifications de maintenance du
systme. Si aucune spcification n'a t faite, il faudra estimer ce temps Ti. L'impact de cet
intervalle de temps entre proof test est important sur le calcul de PFDavg.

- 45 -
8 Conclusion et remarques
Il faut ici rappeler lobjectif de ce document qui est de prsenter les diffrentes mthodes
permettant de calculer la valeur moyenne de la Probabilit de Dfaillance Dangereuse d'un
systme (cas des faibles sollicitations). Nous avons tendu le calcul au cas de la forte
sollicitation.

Les rsultats numriques de l'exemple ne sont en aucun cas prendre comme rfrence pour
d'autres applications. En effet, chaque fonction de scurit ncessite une analyse et un calcul
propre.

La mthode des blocs diagrammes est celle qui se rapproche le plus d'une reprsentation
fonctionnelle du systme. Cette mthode s'applique donc bien dans des cas simples et ne
ncessite qu'une analyse fonctionnelle.

La mthode de l'arbre des causes ncessite en plus de l'analyse fonctionnelle, la

dtermination des dfaillances qui vont amener la perte de la fonction de scurit. Cette
mthode est plus complte que la mthode des blocs diagrammes.

La mthode des graphes de Markov est la plus complique des trois, tant au niveau de la
modlisation que de l'exploitation du modle pour la dtermination de la probabilit de
dfaillance dangereuse. Toutefois, cette mthode, bien que plus complte pour modliser les
diffrents tats du systme, ne permet pas de considrer des intervalles de temps entre proof
tests diffrents pour chacun des constituants du systme.

La probabilit de dfaillance dangereuse d'un systme n'est qu'un des lments qui permet de
juger une fonction de scurit. Elle ne concerne que les pannes matrielles alatoires et fait
partie des exigences demandes par la norme CEI 61508 ou CD CEI 62061 pour les systmes
complexes.

- 46 -
Annexe 1
"Les logiciels de calcul pour les blocs diagrammes"

SafeCalc
Cet outil est dvelopp par Honeywell. Une version de dmonstration est disponible sur le site
http://europe.iac.honeywell.com/products/fsc/2product/safecalc.htm?session_id=1&timestam
p=975939478290
Cet outil a t ralis pour correspondre la norme CEI 61508. Il permet, partir d'une
schmatisation bloc diagramme, de calculer le SIL pour une installation. Il faut pour cela
introduire le taux de dfaillance, le taux de couverture, l'intervalle entre proof test. Cet outil
ne permet pas d'utiliser plus d'une logique de traitement par fonction de scurit.

PDS Tool
Cet outil a t dvelopp par le SINTEF, organisme norvgien (voir sur le site
http://www.sydvest.com/Products/products.htm).
Cet outil est de conception plus ancienne et reprend un concept propre cet organisme. Il
utilise tout de mme les blocs diagrammes comme principe de modlisation.

SILK
Cet outil permet de dterminer un SIL en accord avec la norme CEI 61508. Il n'y a pas de
version de dmonstration. Pour tout renseignement, voir http://www.safety-
sc.nl/software/silk.htm.

Reliability Workbench
Une version de dmonstration de ce logiciel est disponible sur le site
http://www.isograph.com/
Cet outil modlise les diagrammes blocs (modle en srie et parallle) et avec la possibilit de
modliser des voteurs.

BQR Suite
Une version de dmonstration est disponible sur le site http://www.bqr.com. Cet outil permet
de mieux modliser les systmes srie, //, voteur, Ce logiciel utilise des bases de donnes
de fiabilit (type MIL-HDBK ou RDF) et permet aussi de faire de la modlisation par arbre
des fautes.
L'avantage de cet outil est de pouvoir dcomposer un systme en sous-systme
Ce logiciel ne permet pas d'utiliser des taux de dfaillances plus petits que 10-9.

Relex Reliability Software

Une version de dmonstration est disponible sur le site http://www.relexsoftware.com. Cet
outil permet de modliser des blocs diagrammes trs sommairement (modle parallle ou
srie) en utilisant une base de donnes composant.

- 47 -
SUPERCAB
Un aperu des possibilits de ce logiciel est disponible sur le site
http://www.cabinnovation.fr/
Ce logiciel permet de modliser par l'intermdiaire des blocs diagrammes un systme et il
fournit les donnes classiques de fiabilit (MTBF, ). Apparemment, il n'y a pas de bases de
donnes associe avec ce logiciel.

Item Toolkit Software

Voir sur le site http://www.itemsoft.com/download.html. Cet outil n'a pas t essay.
C'est un outil qui permet aussi de faire des blocs diagrammes et qui utilise des bases de
donnes de composant type MIL, Bellcore.

RAM Commander
La version de base de ce logiciel fournit exclusivement une base de donnes de fiabilit de
composants lectroniques. Il existe en option la modlisation par blocs diagrammes.

- 48 -
Annexe 2
"Les logiciels de calcul pour les arbres des fautes et Markov"

On donnera ici pour information quelques logiciels existant sur le march. Ces logiciels
permettent de dterminer le taux de dfaillance de l'vnement principal (celui au sommet de
l'arbre).
On dispose ainsi comme outil pour les arbres de fautes :
- Risk Spectrum; logiciel permettant de traiter les modes communs sans base de donnes
propre; les valeurs des taux de dfaillance sont entrer par les utilisateurs. Cet outil est
vendu par Sector (cf. http://www.sector-sa.com/)
- Simtree; logiciel simple d'arbre de dfaillance
- Cabtree disponible sur le site http://www.cabinnovation.fr/
- BQR Suite
- Reliability Workbench
- Relex reliability software

Pour les outils pour les graphes de Markov:

- MARK_Exd
- Carms (voir le site http://rac.iitri.org/DATA/RMST/rel_model.html#CARMS)
- Reliability Workbench
- BQR Suite

- 49 -
Bibliographie

1
CD CEI 62061 : Scurit des machines Scurit fonctionnelle des systmes lectriques / lectroniques /
lectroniques programmables relatifs la scurit, Version n 44/380/CD, mai 2002, 90p
2
CEI 61508 Scurit fonctionnelle des systmes lectriques / lectroniques / lectroniques programmables
relatifs la sret.
Partie 1 : Prescriptions gnrales, UTE C 46-061, avril 2000, 59 p.
Partie 2 : Exigences pour les systmes lectriques / lectroniques / lectroniques programmables, UTE C 46-062,
avril 2000, 71 p.
Partie 3 : Prescriptions concernant les logiciels, UTE C 46-063, avril 2000, 49 p.
Partie 4 : Dfinitions et abrviations, UTE C 46-064, avril 2000, 26 p.
Partie 5 : Exemples de mthodes pour la dtermination des niveaux d'intgrit de scurit, UTE C 46-065, avril
2000, 28 p.
Partie 6 : Guide pour l'application des parties 2 et 3, UTE C 46-066, avril 2000, 75 p.
Partie 7 : Bibliographie des techniques et des mesures, UTE C 46-067, avril 2000, 115 p.
3
Sret de fonctionnement des systmes industriels Fiabilit Facteurs humains Informatisation A.
Villemeur 1988
4
Control Systems Safety Evaluation & Reliability 2nd Edition William M.Goble 1998
5
ANSI/ISA 84.01 1996 : Application of Safety Instrumented Systems for the Process Industries
6
Systmes haute disponibilit Concepts Technique de l'ingnieur R. J. Chevance 08/1999
7
Document de travail INRS S/00DT 003 : Quantification du niveau de scurit de dispositifs composants
complexes : tude critique
8
Contribution la ralisation d'une architecture redondante d'ordre 2 htrogne. Stage de fin d'tude de C.
Blanchet, lve ENSEM, aot 2000
9
Philippe Charpentier Architecture dautomatisme en scurit des machines : Etude des conditions de
conception lies aux dfaillances de mode commun, Rapport de thse, juillet 2002, 156 p.

- 50 -