• Aucun résultat trouvé

Tant les industriels que les chercheurs se posent des questions sur l’application de la norme CEI 61508 et avancent quelques commentaires et interprétations à propos de cette norme. Celle-ci n’aborde pas le délicat problème de l’utilisation des instruments intelligents dans les systèmes d’automatisation et le champ reste libre de telle sorte que certains fournisseurs revendiquent des instruments intelligents certifiés CEI 61508.

7.1. Limites de la norme CEI 61508

Il ne s’agit pas de faire une interprétation de la norme CEI 61508 traitant la sécurité fonctionnelle mais tout simplement de poser la problématique sur la difficile utilisation de la

* * *

* * SIL1

SIL1 SIL1 SIL2

* * *

* SIL1 SIL2

SIL1 SIL2 SIL3

* SIL1 SIL1

SIL1 SIL2 SIL3

SIL3 SIL3 SIL3 +

norme. Il est à noter que les lecteurs de cette norme ressentent rapidement la nécessité d’être guidés, tant les notions qui y sont exposées peuvent paraître complexes, inhabituelles ou difficiles à mettre en œuvre.

Cette complexité la rend parfois difficilement applicable. Il faut rappeler que la norme est composée de sept volumes contenant 500 pages environ et elle préconise plus de 1000 prescriptions.

Beaucoup de prescriptions ne sont pas assignées à une certaine gamme des niveaux d’intégrité de sécurité ou à la complexité de la conception [FAL 04]. Ceci rend la norme difficile à utiliser pour de plus petits projets et rend la gestion de la sécurité fonctionnelle trop chère pour des petites et moyennes entreprises.

L'ambiguïté possible dans l'interprétation encourage les utilisateurs à employer la norme comme boîte à outils et à mettre en application plutôt les aspects qu'ils appréhendent [FAL 04]. Les utilisateurs en Amérique du Nord semblent être principalement préoccupés par la sécurité de matériel (taux de défaillances dangereuses, taux de défaillances en sécurité) [GOB 05] tandis qu’en Europe (Allemagne) [FAL 04], beaucoup d'utilisateurs semblent être préoccupés davantage par la sécurité de logiciel. La norme laisse également une bonne part à l'interprétation. Les interprétations diffèrent entre les experts sur les contraintes architecturales de matériel et la prise en compte du diagnostic. Les normes européennes du secteur industriel telles que la norme EN 954-1 n'acceptent pas des systèmes où le mode de défaillance d’un composant simple pourrait mener à un état peu sûr contrairement à la CEI 61508.

La norme CEI 61508 définit l’intégrité de sécurité comme propriété de l'installation complète de sécurité du capteur à l’actionneur. En outre, les parties 2 et 3 de la norme entrent dans le détail dans la conception et la "vérification et validation" (V&V) des systèmes électroniques programmables. Ceci mène souvent à la confusion auprès des fournisseurs qui n'hésitent pas à attribuer un niveau de SIL à leurs instruments. Pourtant, cela n’a aucun sens, le niveau de SIL étant strictement associé à une fonction de sécurité donnée. Pour réaliser cette fonction, l’utilisateur met en œuvre plusieurs sous-systèmes : capteur, traitement, actionneur. Dans chacun des sous-systèmes, des composants peuvent être mis en redondance. La PFDavg de l’ensemble doit être calculée à partir des caractéristiques des composants et des architectures mises en œuvre.

Le SIL ne saurait être en aucun cas une caractéristique intrinsèque d’un instrument. Ce que nous pouvons considérer est uniquement une compatibilité avec un niveau de SIL. Cela correspond à une PFDavg comprise dans la plage correspondant au SIL requis, cette PFDavg étant affectée d’une période de test définie.

La norme demande des informations sur la conception des éléments entrant dans la chaîne de sécurité. Dans certains cas, il est possible de disposer de ces informations et de connaître le niveau de fiabilité du dispositif entrant dans la chaîne de sécurité. Le manque d’informations sur la conception pour les éléments constituant la boucle fait en sorte qu’il faut alors s’appuyer sur les retours d’expérience du fournisseur, qui peut fournir des informations précises sur la fiabilité de ses produits. Et à partir de là, il est possible de concevoir la chaîne de sécurité.

La probabilité de défaillance sur demande devrait être aussi renommée, car sa dénomination prête à confusion. Il ne s’agit nullement d’une défaillance à la sollicitation classique, mais d’une indisponibilité moyenne sur un intervalle temporel spécifié [INA 05].

Les formules littérales proposées dans le volume 6 de la norme, qui permettent le calcul de la probabilité de défaillance à la demande pour différentes architectures de systèmes, ont fait l’objet de quelques critiques [GUO 07] [ZHA 03] [HOK 04]. Ces relations sont données sans explications ou justifications et elles ont induit plus d’interrogations, voire de critiques, que de solutions satisfaisantes [INA 05].

Par exemple, le cas de l’architecture 1oo1 (1 out of 1) décrite dans la partie CEI 61508-6 de la norme qui dispose d’un seul canal et ne présente donc pas de redondance. A cette architecture, la norme affecte une durée moyenne d’indisponibilité tCE telle que :

MTTR MTTR T t D DD D DU CE

λ

λ

λ

λ

+       + = 2 1

λD : Taux de défaillances dangereuses

λDU : Taux de défaillances dangereuses non détectées λDD : Taux de défaillances dangereuses détectées T1 : durée du test périodique

MTTR : Durée moyenne de réparation

La probabilité moyenne de défaillance sur demande (indisponibilité moyenne) en est déduite :

CE D

avg t

PFD =λ .

La norme ne donne pas de justification pour la détermination de ce genre de relations. [INA 05] a essayé d’élucider ceci par l’utilisation d’un modèle markovien multi-phases. Les résultats ont montré qu’il faut avancer plusieurs hypothèses telles que l’utilisation de taux de réparation fictif, le choix de l’ordre de quelques approximations, l’assimilation de la durée moyenne d’indisponibilité à la durée moyenne de non fonctionnement (MDT) [ZHA 03], l’approximation qui consiste à confondre la MTBF (Mean Time Between Failures ou durée moyenne entre deux défaillances successives) et la MTTF (Mean Time To Failure ou durée moyenne de bon fonctionnement avant la première défaillance)…

Les résultats montrent aussi que la norme est conservative, puisqu’elle donne des résultats légèrement pessimistes.

[SIG 05] stipule que le concept d’intégrité de sécurité est nécessaire mais pas suffisant pour caractériser correctement le niveau d’intégrité de sécurité d’un système instrumenté de sécurité. En effet, les formules centrées sur la détermination d’un indicateur moyen ne prennent pas en compte les dépassements répétés du seuil haut du domaine SIL concerné ni leurs conséquences négatives sur le niveau de sécurité réel du SIS étudié.

7.2. Positionnement vis-à-vis des SAID

La norme CEI 61508, bien qu’elle soit relative aux systèmes électriques, électroniques et électroniques programmables dédiés à la sécurité, ne traite pas explicitement le cas des systèmes d’automatisation à intelligence distribuée ni celui des instruments intelligents qui les composent.

Les seuls endroits où la norme fait allusion à ce type d’instruments figurent dans la partie 4 relative aux définitions et abréviations. On y trouve suite à la définition donnée à l‘électronique programmable que celle-ci est une technologie basée sur l’informatique, pouvant comprendre du matériel, du logiciel, ainsi que les unités d’entrée et de sortie. La

norme précise que ce terme recouvre les appareils microélectroniques basés sur une ou plusieurs unités centrales de traitement associées à des mémoires. Et parmi les exemples des dispositifs électroniques programmables, la norme cite les microprocesseurs, les microcontrôleurs, les automates programmables, les circuits intégrés spécifiques à une application (ASIC), les automates logiques programmables et finalement les capteurs intelligents comme faisant partie des autres appareils basés sur la technologie informatique. De plus, la norme dans cette même partie 4 présente un système électronique programmable (PES, Programmable Electronic System) comme étant un système de commande, de protection ou de surveillance basé sur un ou plusieurs dispositifs électroniques programmables recouvrant ainsi tous les éléments du système tels que l’alimentation, les capteurs jusqu’aux actionneurs en passant par les voies de communication.

L’illustration est faite sur la figure 2.12 suivante :

Figure 2.12 : Structure d’un PES avec deux dispositifs électroniques programmables [CEI 00]

Cette figure montre la façon dont est représenté le PES dans la norme CEI 61508, il y a une distinction de l’électronique programmable des dispositifs PE1 et PE2 qui se retrouvent en série et qui peuvent représenter par exemple un capteur intelligent et un automate programmable. L’électronique programmable peut par conséquent naturellement être présente en divers endroits du PES.

Une manière dont la norme traite la répartition de cette électronique programmable est de considérer une certaine redondance parallèle si on considère que la figure précédente à trait à une redondance série. Dans ce cas de figure aussi, le PES est composé de canaux distincts incorporant séparément de l’électronique programmable.

Nous constatons bien qu’implicitement il s’agit ici d’un partage de tâches et d’une distribution de l’électronique programmable à travers les différents dispositifs qui constituent le PES.

L’autre aspect absent ou presque de la norme est celui relatif aux réseaux de communication et particulièrement les réseaux de terrain. La norme reste muette sur cet aspect ainsi que sur l’interface matériel / logiciel. Sur l’aspect logiciel, la norme se contente de dresser uniquement des recommandations.

Parmi ce type de recommandations, la norme spécifie le langage de programme figé (FPL, Fixed program language) dans lequel l’utilisateur est limité à l’ajustement de quelques paramètres (par exemple la gamme d’un transmetteur de pression, les seuils d’alarme, les adresses de réseau). La norme spécifie aussi le langage de variabilité limitée (LVL, Limited Variability Language) qui est conçu pour être compréhensible par les utilisateurs du domaine du processus et fournit la possibilité de combiner des fonctions de bibliothèque spécifiques à une application.

Les exemples représentatifs de dispositifs avec FPL sont les capteurs intelligents et les vannes intelligentes et un exemple des systèmes utilisant les LVL est celui d’un automate programmable standard.

8. Paramètres de performance en sécurité pour les systèmes

Documents relatifs