Problématique relative à l’utilisation des instruments intelligents dans les boucles de

L’introduction des instruments intelligents dans des applications sécuritaires basées sur les systèmes instrumentés de sécurité doit avoir pour objectif l’amélioration de la sécurité et non pas le contraire sinon à quoi bon des investissements colossaux en technologies, ressources humaines, formation et coût de revient si le résultat final de cette introduction est similaire ou en deçà du niveau des performances par rapport à des systèmes classiques utilisant des instruments conventionnels.

Pour cela, regardons de près la valeur ajoutée qu’apporte un système d’automatisation à intelligence distribuée (SAID). Celle-ci peut se résumer en la distribution de l’intelligence (ou encore des traitements) en utilisant comme auxiliaire la communication par réseau mais aussi, dans le cas d’architecture répartie, le pouvoir de faire du diagnostic distribué.

Inutile de montrer encore le mérite de l’utilisation de ce type de systèmes surtout en contrôle commande, ceci était l'objet du premier chapitre.

La question qui se pose est relative donc à la sauvegarde des performances dans un système instrumenté de sécurité par l’introduction de l’intelligence dans les différentes fonctions de sécurité, voire l’amélioration de ces performances.

La norme CEI 61508 [CEI 00] spécifie deux indicateurs de la sécurité relatifs aux systèmes électroniques programmables dédiés aux applications de sécurité. Ces deux indicateurs sont la probabilité de défaillance dangereuse (PFD) et la probabilité de défaillance en sécurité (PFS). Leur évaluation comme l’exige la norme CEI 61508 pose quelques problèmes liés à leur spécificité. En effet, les systèmes instrumentés de sécurité intègrent de manière obligatoire en fonction du niveau de sécurité requis, des auto-tests systématiques et des redondances permettant la détection et/ou la tolérance à certaines défaillances afin de garantir l’effectivité de la fonction de sécurité.

La norme exige un certain nombre de recommandations et de prescriptions relatives à l’utilisation des moyens de communication de données pour réaliser des fonctions de sécurité. Notamment lorsqu’une forme quelconque de communication de données est utilisée dans la réalisation d’une fonction de sécurité, la probabilité de défaillance de la fonction de sécurité due au processus de communication doit être estimée en prenant en compte les erreurs de transmission, les répétitions, les suppressions, les insertions, les modifications du séquencement, la corruption, le retard et le masquage. Cette probabilité doit être prise en compte lors de l’estimation de la probabilité de défaillance dangereuse de la fonction de sécurité, due à une défaillance aléatoire du matériel.

Le terme masquage signifie que le contenu exact d’un message n’est pas correctement identifié. Par exemple, un message provenant d’un composant qui n’est pas de sécurité est identifié incorrectement comme un message provenant d’un composant de sécurité.

En particulier, les paramètres suivants doivent être pris en compte en estimant la probabilité de défaillance de la fonction de sécurité due au processus de communication:

a) le taux d’erreur résiduel;

c) les limites et la variabilité de la vitesse de transfert de l’information;

d) les limites et la variabilité du temps de retard dû a la propagation de l’information. La norme explique aussi que la probabilité d’une défaillance dangereuse (en h^–1) est égale au quotient de la probabilité d’erreur résiduelle par la longueur du message (en bits) multipliée par la vitesse de transmission sur le bus des messages relatifs à la sécurité ainsi que par un facteur de 3600¹.

Les défaillances de cause commune et celles dues aux processus de communication des données peuvent résulter d’effets autres que les défaillances des composants matériels (par exemple, perturbation électromagnétique, erreurs de décodage, etc.). Toutefois, de telles défaillances sont considérées, pour les besoins de la présente norme, comme des défaillances aléatoires du matériel.

La norme recommande aussi qu’afin de maîtriser les anomalies systématiques, la conception E/E/PES doit avoir des caractéristiques de conception telles que les systèmes E/E/PE relatifs à la sécurité soient tolérants, entre autres, aux erreurs et autres effets provenant d’un processus de communication de données.

La question demeure donc sur la prise en compte des défaillances du réseau de communication et de l’introduction de son modèle de défaillance.

Les architectures des systèmes de sécurité dans l’automatisation peuvent avoir une forme classique où l’intégration de la fonction de sécurité se fait uniquement au niveau des automates programmables industriels (la fonction traitement) ou une forme dans laquelle la sécurité est distribuée avec un traitement local de la sécurité au niveau des périphériques décentralisés tout en gardant un traitement central de la sécurité au niveau des API.

Figure 3.1 : Comparaison entre une architecture centralisée (a) et une architecture distribuée (b)

La présence d'un réseau apporte une fonctionnalité additionnelle, à savoir la communication. La décomposition fonctionnelle de ces deux architectures est proposée par [CAU 04] dans laquelle la fonction de communication constitue un composant du système.

La figure 3.2 montre cette décomposition fonctionnelle pour les deux architectures.

1

La valeur 3600 correspond à la conversion d’une heure en secondes puisque la vitesse de transmission a pour unité le baud (bit par seconde) et la probabilité d’erreur est donnée avec l’unité h^–1.

Mesure 1 Mesure 2 Actionnement Mesure 1 Traitements 1 & 2 Actionnement (a) (b) Mesure 2 Traitement 2 Traitement 1

Figure 3.2 : Fonction communication dans l’architecture distribuée [CAU 04]

Ce modèle qui considère que la fonction communication fait partie intégrante du système et peut se présenter sous forme d’un composant à part entière tantôt entre la mesure et le traitement et tantôt entre le traitement et l’actionnement ne peut suffire pour représenter le modèle fiabiliste du système.

La norme, par l’utilisation des blocs diagrammes de fiabilité dans sa partie 6, donne la probabilité moyenne de défaillance sur demande d’une fonction de sécurité du système E/E/PE comme la combinaison de la probabilité moyenne de défaillance sur demande pour tous les sous-systèmes assurant ensemble la fonction de sécurité.

Plus formellement : FE L S SYS PFD PFD PFD PFD = + + Où

PFDSYS est la probabilité moyenne de défaillance sur demande d’une fonction de sécurité du système E/E/EP relatif à la sécurité,

PFD_S est la probabilité moyenne de défaillance sur demande du sous-système capteur (fonction mesure),

PFDL est la probabilité moyenne de défaillance sur demande du sous-système logique (fonction traitement),

PFDFE est la probabilité moyenne de défaillance sur demande du sous-système élément final (fonction actionnement).

Cette modélisation en diagrammes de fiabilité ne peut cependant s’appliquer pour la représentation de la fonction communication de l’architecture distribuée et on ne peut sommer facilement et simplement les probabilités moyennes de défaillances consécutives pour aboutir à la valeur moyenne de la probabilité de défaillance PFDSYS globale.

En effet, la représentation (b) de la figure 3.2 est insuffisante pour décrire les phénomènes qui se passent réellement. Ce n’est pas vraiment un diagramme de fiabilité parce que quelque soit le temps le modèle ne bouge pas. En fait, il n’est pas du tout tenu compte des défaillances réseaux qui sont des défaillances temporelles. Aussi, il y a existence d’un mode commun auquel le modèle ne fait pas allusion et qui est dû à la distribution et donc de la présence de la communication d’une part entre les capteurs et le traitement et d’autre part entre le traitement et l’actionneur.

Néanmoins, cette fonction communication peut être modélisée par un seul bloc dans le modèle fiabiliste du système afin d’avoir un modèle de référence d’un point de vue statique.

Traitement

Mesure Actionnement

Communication

Mesure Traitement Communication Actionnement

(a)

L’aspect principal de l’intelligence des systèmes d’automatisation est celui de la distribution des traitements au plus bas niveau (dit niveau 0) de la pyramide CIM (Computer Integrated Manufacturing : fabrication intégrée sous le contrôle de l’informatique) [SHE 94]. Cette distribution permet la répartition des tâches de contrôle des processus aux dispositifs de terrain (capteurs et actionneurs) favorisant ainsi la mise en place des autotests pour une détection rapide et un déclenchement de mesures nécessaires aux moments opportuns. La distribution est vue ainsi comme une sorte de sous-traitance des traitements par l’implantation des fonctionnalités complexes dans les dispositifs de terrain.

Il est aussi intéressant de situer la contribution de cette amélioration de pouvoir de réactivité à la fiabilité de ce type de systèmes plus complexes et disposant d’autres modes de défaillances par rapport aux systèmes classiques. [BRO 05] fait savoir que l’utilisation de transmetteurs intelligents améliore la robustesse aux défaillances de causes communes par la séparation du transducteur de l’électronique permettant au capteur d’être relié directement au processus physique avec une électronique qui se situe dans un endroit accessible.