La sécurité des machines automatisées - Analyse des risques ... - Irsst

IRSST - La sécurité des machines automatisées
Analyse des risques et des moyens de protection sur une presse à injection de plastique
57
ANNEXE A : SÉCURITÉ DES SYSTÈMES COMMANDÉS PAR DES API
A.1 Introduction à la sécurité des systèmes commandés par des API
Un automate programmable, aussi connu comme automate programmable industriel (API) est
défini par la norme CEI 61131-1 comme étant :
« un système électronique fonctionnant de manière numérique, destiné à être
utilisé dans un environnement industriel qui utilise une mémoire programmable
pour le stockage interne des instructions orientées utilisateur aux fins de mise en
œuvre de fonctions spécifiques, telles que des fonctions de logique, de mise en
séquence, de temporisation, de comptage et de calcul arithmétique, pour
commander au moyen d’entrées et de sorties tout-ou-rien ou analogiques divers
types de machines ou de processus ».
Par ailleurs, un automate programmable standard n’est pas conçu pour gérer des fonctions de
sécurité. En effet, l’INRS recommande de ne pas faire confiance au seul API pour assurer la
gestion des fonctions de sécurité [12]. Une défaillance de l’API peut engendrer un mouvement
dangereux conduisant à un accident. Ce comportement est dû au fait qu’un API standard n’a pas
été conçu pour détecter toutes ses défaillances internes et adopter une position de repli en
sécurité lorsque celles-ci se produisent. Donc, une logique câblée extérieure à la commande
gérée par l’API (commande du processus) est préférable afin qu’il n’existe pas de liaison directe
entre une commande intempestive provenant de l’API et le mouvement dangereux. Un circuit à
base de logique câblée agirait en priorité soit directement sur la puissance, soit sur l’API en
coupant l’alimentation des cartes de sortie [13]. L’IRSST a aussi produit un document suggérant
des règles de sécurité pour l’utilisation des API [13]. En résumé, les risques spécifiques des API
sont les suivants :
• Les programmes qui peuvent initialement être bien élaborés, peuvent être
malencontreusement modifiés par un intervenant imprudent ou mal informé. Cette
modification du programme initial peut être rendue nécessaire par l’évolution du système
automatisé. Des modifications de programme sans aucune documentation, surtout des
programmes gérant des fonctions de sécurité sont dangereuses.
• L’API demeure un appareil électronique et prévoir les modes de défaillances en cas
d’incident, notamment sous l’effet d’influences externes (ex. température, poussière,
humidité, vibrations, parasites électromagnétiques ou électrostatiques) est difficile.
• L’API possède une unité centrale et un système de traitement à canal unique et peut avoir un
mode commun de défaillance. L’architecture interne de l’API n’a pas été conçue pour gérer
des fonctions de sécurité. Cependant, la fiabilité globale d’un automate programmable
dépend surtout du nombre et de la fiabilité de ses cartes d’entrée/sortie. Dans un ensemble
automatisé, 90 à 95% des défauts matériels sont extérieurs à l’automate et proviennent avant
tout des capteurs et de leurs liaisons, des actionneurs et pré-actionneurs et de leurs liaisons.
Néanmoins, même si les processeurs des API actuels ont atteint des taux de défaillances
particulièrement bas, il n’est généralement pas recommandé d’utiliser un API standard pour
gérer des fonctions de sécurité sur les systèmes automatisés.