Echange de signaux instrumenté Safety vers PLC de process

[glamdring]

Bonjour à tous,

je viens vous demander conseil car j'avoue être un peu perdu. Sur une de nos installations , nous devons réguler la température de sortie d'un éléments. La sonde de température présente est utilisé dans l'automate de sécurité et on me demande de la copier vers la partie process afin de l'utiliser en régulation. Dans la littérature, on stipule bien d'avoir une indépendance des couches de protections donc jusque là , nous étions parti sur un dédoublement de la mesure (1 capteurs process et 1capteur safety).
En discutant avec un collègue , celui me dit qu'un organisme de contrôle lui confirme que de copier cette valeur du Safety vers le process ne dévaluait pas la boucle de sécurité (SIL2)....je suis assez étonné de cela car c'est un peu contradictoire avec la compréhension que j'en avais jusqu'à maintenant.

Avez vous déjà rencontré ce genre de chose et pouvez vous me dire si cela vous semble "correcte"?

En vous remerciant

Glamdring

[itasoft]

slts,
c'est quoi comme capteur de la température ?
Si c'est du courant (4/20mA) il faut les mettre en série , le courant qui passe sera le même sur les deux acquisitions (loi d'Ohm)
-------

01.JPG (17.33 Kio) Vu 2525 fois

[glamdring]

Bonjour,

ce que je n'arrive pas à comprendre c'est pourquoi la norme 61511 dit que l'on doit séparer ce qui est process et sécurité mais qu'un organisme de contrôle explique que l'échange de valeur de sécurité vers le process à des fin de régulation est autorisé sans dévaluer la boucle instrumenté de sécurité.

A SIS is normally separated from the BPCS for the following reasons:-
1. To reduce common cause, common mode and systematic failures, minimising the
impact of BPCS failures on the SIS.
2. To retain flexibility for changes, maintenance, testing and documentation relating to the
BPCS.
3. To facilitate the validation and functional safety assessment of the SIS.
4. To support access security and enhance cyber security for the SIS such that revisions
to BPCS functions or data do not affect the SIS.
5. To reduce the amount of analysis that should occur to ensure that the SIS and BPCS
are properly designed, verified and managed.

je m'interroge sur la compréhension de la norme à ce sujet.

Merci de ta réponse

Glam

[itasoft]

slts,
ok, mais ça répond pas à la question , es que c'est bien du 4/20 mA ????????

[glamdring]

Bonjour ,

c'est bien du 4-20mA mais la duplication n'est pas l'objet de ma question qui porte plus sur une pratique à priori bien répandue qui me semble contradictoire avec une norme.

je vais essayer de l'expliquer autrement:

Quand tu lis la norme 61511 sur la partie SAFETY on te dit de séparer les instruments de process et de sécurité mais à priori la duplication de signal comme tu le proposes ou via une table d'échange est accepté par l'organisme de contrôle. Même si tu duplique le signal afin de l'utiliser ailleurs , une défaillance de celui va alors impacter ton process mais aussi ta boucle de sécurité.

D'un côté , on me dit de séparer et de l'autres on me dit mais vous pouvez recopier, dupliquer la valeur du safety vers le process et l'utiliser sans problème cela ne dégrade pas le niveau SIL de la boucle.

En espérant avoir été plus clair

Bien à vous

Glam

[steph68]

Salut,

Ton automate de sécurité ne peut pas te donner une image (donc une sortie) de ce capteur (une entrée) par recopie ?

Tout cela s'évalue, c'est le calcul du PL. Sans connaître le PL requis, ni ta chaîne de sécurité, c'est difficile de te répondre.
Tu as le logiciel Sistema de l'IFA qui te permet de calculer la performance de ta chaîne de sécurité.
Si tu n'es pas formé sur les PL (ISO 13849-1), ça va être compliqué.

Ce capteur n'est qu'un canal de la redondance de ta chaîne de sécurité.

Le fait de dupliquer le signal peut dévaluer ton PL, mais tant qu'il reste supérieur au PL requis, ça peut encore le faire.
Donc si tu cherches à atteindre PLe, non ne le fait pas, mais si c'est PLb (dans ce cas l'info peut même venir de l'automate process lui même) ou PLc, pas de problème, vas-y.

Tout ceci pour dire que racheter un autre capteur de température sera peut-être moins cher que de devoir le justifier par écrit.

@+

[JC87]

Bonjour,

Pour moi ça ne pose pas de problème. Une entrée de sécurité dite "sûre" qu'elle soit digitale ou analogique est traitée dans un automate de sécurité dans une partie "safety" dédié. Le fait de l'utiliser dans le programme "normal' n'affecte en rien la fonction de sécurité.

D'ailleurs si ça posait problème on ne pourrait pas utiliser ces entrées dans le programme "non safety" hors c'est parfaitement possible dans tous les automates de sécurité récent, preuve que la norme est respectée.

Ce qui poserait problème par contre c'est d'utiliser une entrée process donc "non sûre" dans une partie "Safety" et ça ce n'est pas possible dans un automate de sécurité. Il ne faut pas non plus dupliquer le signal en câblé, ça rendrait potentiellement l'entrée "non sûre", il faut le faire dans l'automate via une recopie ou en com.

JC

[itasoft]

ça rendrait potentiellement l'entrée "non sûre"
---------
je dirais même "Pas sûre du tout"

[Lorent2]

Le plus simple ne serait-il pas de renvoyer la mesure safety vers la partie procédé par communication ?

[glamdring]

Merci pour vos réponses ,

Au final le niveau de cette boucle de sécurité sera de toute façon revue car l'architecture de celle ci est 1oo1 et nous sommes en High demand pour un SIL 2 car on doit tenir compte des CCF aussi (Common Cause Failure). Ce que j'avais prévu était d'avoir un capteur process et un safety mais à priori mon collègue préfère recopier la valeur (via la com) et éviter un capteur supplémentaire. On va trancher cela en équipe et avec l'organisme de contrôle de toute façon mais au moins c'est un peu plus clair pour moi.

je vais relancer mon chef pour la formation dans tout les cas (croise les doigts)


Bien à vous

Glam