La publication des spécifications PLCopen Safety marque une étape importante dans la réconciliation du monde fonctionnel avec celui de la sécurité.
La publication des spécifications PLCopen Safety marque une étape importante dans la réconciliation du monde fonctionnel avec celui de la sécurité. Ces nouvelles spécifications traitent des aspects relatifs à la programmation des fonctions de sécurité, ainsi qu’à leur intégration au sein des environnements de développement IEC 61131-3.
Dès le début des années 80, l’INRS (Institut National de Recherche et de Sécurité) mettait en garde la communauté industrielle contre l’utilisation d’automates programmables pour l’implémentation de fonctions de sécurité. Celles-ci devaient être confiées à une logique câblée spécifique, permettant la mise en sécurité d’une machine même en cas de défaillance de l’API de commande. Depuis cette époque les choses ont bien évolué et l’apparition d’un nouveau type d’API, capable d’assurer la gestion des fonctions de sécurité, à entraîné une migration progressive de l’implémentation des systèmes de sécurité du hardware vers le software.
Image SAFEPROG_Keyvisual.jpg : Source KW Software
Toutefois, il existe aujourd’hui encore une forte déconnexion entre les parties fonctionnelles et relatives à la sécurité des systèmes automatisés. Cette déconnexion se traduit par l’utilisation d’environnements, de systèmes et d’outils de programmation différents, voire même par l’implication de groupes de personnes distincts, entre lesquels les échanges peuvent s’avérer difficiles. L’une des conséquences de cette séparation est la prise en compte souvent tardive des aspects relatifs à la sécurité dans le cycle de développement des systèmes automatisés. La tendance au raccourcissement des délais de développement n’arrangeant rien à l’affaire, cela se traduit en dernière extrémité par des fonctions de sécurités mal intégrées et peu testées.
Or s’il est un aspect qui gagne en importance aux yeux des industriels, c’est bien la sécurité. En effet, celle-ci est de plus en plus considérée comme un moyen d’améliorer la compétitivité : des procédés plus sûrs garantissent des temps d’arrêt moindres, l’élimination des risques d’accidents est synonyme d’une plus grande disponibilité des opérateurs, etc. Et tout cela sans compter que la législation impose des contraintes de plus en plus sévères aux fournisseurs d’équipements, et inflige des sanctions financières de plus en plus lourdes aux contrevenants.
Aider les constructeurs à s’y retrouver
En Europe, les constructeurs de machines sont confrontés à plus de 300 standards relatifs à la sécurité. Autant dire qu’il est très difficile, voire impossible pour bon nombre d’entre eux de s’y retrouver. L’ambition de PLCOpen, au travers de la publication des nouvelles spécifications Safety, était d’aider les constructeurs de machines dans leur démarche, en leur apportant des outils de développement adaptés, leur permettant d’intégrer dès le début du cycle de conception les aspects relatifs à la sécurité.
Le modèle d’architecture logicielle proposé par PLCopen continue de différencier la partie fonctionnelle de la partie relative à la sécurité des applications, comme le recommandent d’ailleurs tous les standards existants. Néanmoins, alors que jusqu’à présent cette différenciation entraînait l’utilisation d’environnements de développements à deux niveaux, variant dans leurs caractéristiques de gestion des fonctions de sécurité, le modèle proposé par PLCopen uniformise tout cela, et fusionne les deux niveaux au sein d’une seule et même plateforme, c’est-à-dire un environnement de développement fonctionnel (Logic et Motion), intégrant une partie dédiée à la sécurité (Safety).
Image Archi.jpg :Sur la partie gauche du modèle, deux types d’entrées sont identifiés. Au centre, les deux environnements sont représentés séparément. Tous deux sont reliés à leurs entrée/sorties respectives. L’échange de données entre les applications « Safety » et « Functional » sont représentés au milieu. La partie fonctionnelle dispose d’un accès non restreint en lecture des entrées de sécurité ainsi qu’aux variables globales. Les signaux « non-safe », quant à eux, ne peuvent être utilisés dans la partie Safety que pour contrôler le déroulement du programme, et ne peuvent en aucun cas être connectés directement aux sorties de sécurité (comme l’indiquent la flèche de droite ainsi que l’opérateur ET).
Safety Function Blocks
Afin d’aider les développeurs a créer des applications de sécurité, la première mission de PLCOpen a consisté à identifier un certain nombre de fonctions de sécurité, et à définir un ensemble de blocs fonctionnels de haut niveau (les Safety Function Blocks), permettant de les décrire. L’utilisation d’éléments tels que les Function Blocks pour le développement d’applications présente de nombreux avantages : la spécification, de même que la validation des fonctionnalités s’en trouvent grandement facilitées ; par ailleurs, l’utilisation de blocs fonctionnels permet de masquer les détails de l’implémentation et de rendre le développement moins dépendant de l’architecture hardware sous-jacente. A l’heure actuelle, le comité technique de PLCOpen a d’ores et déjà identifié 16 fonctions de sécurité, représentées par 19 Function Blocks. Validés à la fois par la BGIA et la TUV, ceux-ci couvrent les fonctions de sécurité les plus importantes, telles que : l’arrêt d’urgence, la sécurité des portes, la sélection des modes de marche, la commande bimanuelle, etc.
SAFEPROG_2.jpg : Source KW Software
Une fois que les fonctionnalités ont été représentées sous forme de Function Blocks, l’étape suivante consiste à déterminer comment les combiner au sein de programmes de sécurité. A ce niveau, le but poursuivit par PLCOpen était de faire en sorte que le logiciel fournisse une assistance maximale à l’utilisateur. Pour cela, un nouveau type de donnée, baptisé « Safebool », a été introduit. Celui-ci se réfère à un signal de sécurité de type booléen pouvant se comporter comme une entrée ou comme une sortie. La définition de ce nouveau type de donnée constitue la base de l’identification des parties relatives ou non à la sécurité, et permet à l’outil de développement de guider l’utilisateur pour la réalisation de connexions autorisées, tout en lui interdisant les connexions incorrectes.
Eviter les erreurs
La combinaison de Function Blocks de sécurité au sein d’un programme applicatif requiert un environnement de développement adapté. Un certain nombre de recommandations et de restrictions permettant d’obtenir un tel environnement sont énoncés dans les spécifications. Par exemple, une préférence est donnée à l’utilisation des langages graphiques FBD (Function Blocks Diagram) et LD (Ladder Diagram), en raison de leur caractéristiques leur facilité de création et de vérification des programmes.
Signalons enfin que les spécifications PLCOpen Safety définissent trois modes d’utilisation : basic, expert et système, permettant d’adapter les possibilités de développement offertes en fonction de l’expérience et du niveau de responsabilité de l’utilisateur. En mode basic, celui-ci n’est autorisé à développer une logique de sécurité qu’en connectant des Function Blocks déjà certifiés ainsi que des Function Blocks élémentaires de type timer ou compteur, par le biais de connexions ET/OU. Le mode Expert va plus loin et offre quant à lui la possibilité à l’utilisateur de définir ses propres extensions de Function Blocks. Enfin, le mode Système est pour sa part réservé aux fournisseurs de systèmes de contrôle de sécurité. Il est centré sur le développement de nouveaux Functions Blocks certifiés, destinés à être intégrés dans une librairie.
j46p32La publication des spécifications PLCopen Safety marque une étape importante dans la réconciliation du monde fonctionnel avec celui de la sécurité. Ces nouvelles spécifications traitent des aspects relatifs à la programmation des fonctions de sécurité, ainsi qu’à leur intégration au sein des environnements de développement IEC 61131-3.
Dès le début des années 80, l’INRS (Institut National de Recherche et de Sécurité) mettait en garde la communauté industrielle contre l’utilisation d’automates programmables pour l’implémentation de fonctions de sécurité. Celles-ci devaient être confiées à une logique câblée spécifique, permettant la mise en sécurité d’une machine même en cas de défaillance de l’API de commande. Depuis cette époque les choses ont bien évolué et l’apparition d’un nouveau type d’API, capable d’assurer la gestion des fonctions de sécurité, à entraîné une migration progressive de l’implémentation des systèmes de sécurité du hardware vers le software.
Image SAFEPROG_Keyvisual.jpg : Source KW Software
Toutefois, il existe aujourd’hui encore une forte déconnexion entre les parties fonctionnelles et relatives à la sécurité des systèmes automatisés. Cette déconnexion se traduit par l’utilisation d’environnements, de systèmes et d’outils de programmation différents, voire même par l’implication de groupes de personnes distincts, entre lesquels les échanges peuvent s’avérer difficiles. L’une des conséquences de cette séparation est la prise en compte souvent tardive des aspects relatifs à la sécurité dans le cycle de développement des systèmes automatisés. La tendance au raccourcissement des délais de développement n’arrangeant rien à l’affaire, cela se traduit en dernière extrémité par des fonctions de sécurités mal intégrées et peu testées.
Or s’il est un aspect qui gagne en importance aux yeux des industriels, c’est bien la sécurité. En effet, celle-ci est de plus en plus considérée comme un moyen d’améliorer la compétitivité : des procédés plus sûrs garantissent des temps d’arrêt moindres, l’élimination des risques d’accidents est synonyme d’une plus grande disponibilité des opérateurs, etc. Et tout cela sans compter que la législation impose des contraintes de plus en plus sévères aux fournisseurs d’équipements, et inflige des sanctions financières de plus en plus lourdes aux contrevenants.
Aider les constructeurs à s’y retrouver
En Europe, les constructeurs de machines sont confrontés à plus de 300 standards relatifs à la sécurité. Autant dire qu’il est très difficile, voire impossible pour bon nombre d’entre eux de s’y retrouver. L’ambition de PLCOpen, au travers de la publication des nouvelles spécifications Safety, était d’aider les constructeurs de machines dans leur démarche, en leur apportant des outils de développement adaptés, leur permettant d’intégrer dès le début du cycle de conception les aspects relatifs à la sécurité.
Le modèle d’architecture logicielle proposé par PLCopen continue de différencier la partie fonctionnelle de la partie relative à la sécurité des applications, comme le recommandent d’ailleurs tous les standards existants. Néanmoins, alors que jusqu’à présent cette différenciation entraînait l’utilisation d’environnements de développements à deux niveaux, variant dans leurs caractéristiques de gestion des fonctions de sécurité, le modèle proposé par PLCopen uniformise tout cela, et fusionne les deux niveaux au sein d’une seule et même plateforme, c’est-à-dire un environnement de développement fonctionnel (Logic et Motion), intégrant une partie dédiée à la sécurité (Safety).
Image Archi.jpg :Sur la partie gauche du modèle, deux types d’entrées sont identifiés. Au centre, les deux environnements sont représentés séparément. Tous deux sont reliés à leurs entrée/sorties respectives. L’échange de données entre les applications « Safety » et « Functional » sont représentés au milieu. La partie fonctionnelle dispose d’un accès non restreint en lecture des entrées de sécurité ainsi qu’aux variables globales. Les signaux « non-safe », quant à eux, ne peuvent être utilisés dans la partie Safety que pour contrôler le déroulement du programme, et ne peuvent en aucun cas être connectés directement aux sorties de sécurité (comme l’indiquent la flèche de droite ainsi que l’opérateur ET).
Safety Function Blocks
Afin d’aider les développeurs a créer des applications de sécurité, la première mission de PLCOpen a consisté à identifier un certain nombre de fonctions de sécurité, et à définir un ensemble de blocs fonctionnels de haut niveau (les Safety Function Blocks), permettant de les décrire. L’utilisation d’éléments tels que les Function Blocks pour le développement d’applications présente de nombreux avantages : la spécification, de même que la validation des fonctionnalités s’en trouvent grandement facilitées ; par ailleurs, l’utilisation de blocs fonctionnels permet de masquer les détails de l’implémentation et de rendre le développement moins dépendant de l’architecture hardware sous-jacente. A l’heure actuelle, le comité technique de PLCOpen a d’ores et déjà identifié 16 fonctions de sécurité, représentées par 19 Function Blocks. Validés à la fois par la BGIA et la TUV, ceux-ci couvrent les fonctions de sécurité les plus importantes, telles que : l’arrêt d’urgence, la sécurité des portes, la sélection des modes de marche, la commande bimanuelle, etc.
SAFEPROG_2.jpg : Source KW Software
Une fois que les fonctionnalités ont été représentées sous forme de Function Blocks, l’étape suivante consiste à déterminer comment les combiner au sein de programmes de sécurité. A ce niveau, le but poursuivit par PLCOpen était de faire en sorte que le logiciel fournisse une assistance maximale à l’utilisateur. Pour cela, un nouveau type de donnée, baptisé « Safebool », a été introduit. Celui-ci se réfère à un signal de sécurité de type booléen pouvant se comporter comme une entrée ou comme une sortie. La définition de ce nouveau type de donnée constitue la base de l’identification des parties relatives ou non à la sécurité, et permet à l’outil de développement de guider l’utilisateur pour la réalisation de connexions autorisées, tout en lui interdisant les connexions incorrectes.
Eviter les erreurs
La combinaison de Function Blocks de sécurité au sein d’un programme applicatif requiert un environnement de développement adapté. Un certain nombre de recommandations et de restrictions permettant d’obtenir un tel environnement sont énoncés dans les spécifications. Par exemple, une préférence est donnée à l’utilisation des langages graphiques FBD (Function Blocks Diagram) et LD (Ladder Diagram), en raison de leur caractéristiques leur facilité de création et de vérification des programmes.
Signalons enfin que les spécifications PLCOpen Safety définissent trois modes d’utilisation : basic, expert et système, permettant d’adapter les possibilités de développement offertes en fonction de l’expérience et du niveau de responsabilité de l’utilisateur. En mode basic, celui-ci n’est autorisé à développer une logique de sécurité qu’en connectant des Function Blocks déjà certifiés ainsi que des Function Blocks élémentaires de type timer ou compteur, par le biais de connexions ET/OU. Le mode Expert va plus loin et offre quant à lui la possibilité à l’utilisateur de définir ses propres extensions de Function Blocks. Enfin, le mode Système est pour sa part réservé aux fournisseurs de systèmes de contrôle de sécurité. Il est centré sur le développement de nouveaux Functions Blocks certifiés, destinés à être intégrés dans une librairie.
