Approche de Détection et d'Explication d'Erreur de Commande par Filtrage Robuste

Cette section introduit le problème de la détection d'erreur de commande dans les systèmes de contrôle-commande industriels. Elle souligne les incertitudes liées au pilotage humain et la nécessité d'assurer un niveau de sécurité élevé pour les personnes, les biens et l'environnement. L'article met en avant les limites des approches existantes, notamment la difficulté de vérifier le contrôle-commande réellement implanté et la complexité de gérer les modifications du programme de l'automate programmable industriel (API) lors de la production ou par l'opérateur. L'objectif est de proposer une approche de filtrage robuste, combinée à un système d'aide au diagnostic, afin de prévenir les erreurs de commande, qu'elles soient dues à l'opérateur ou à la partie commande elle-même. La norme IEC61508 et ses implications pour la sûreté de fonctionnement sont mentionnées, soulignant le besoin de méthodes formelles pour garantir un processus de développement sûr. Différentes approches de surveillance existantes, basées sur la comparaison avec un modèle de référence, l'émulation du comportement de la partie opérative ou l'utilisation d'un filtre, sont également brièvement mentionnées. Le besoin d'explications claires pour aider l'opérateur à comprendre et corriger ses erreurs, ou celles de la partie commande, est clairement énoncé.

La section détaille le rôle crucial du filtre de sécurité robuste dans la prévention des erreurs de commande. Elle souligne l'importance d'une réponse immédiate du filtre pour garantir la sécurité, contrairement à la réaction potentiellement plus lente d'un opérateur humain. L'approche privilégiée consiste à donner la priorité au système technique de filtrage, car ce dernier assure une réaction immédiate aux situations critiques. Le document explique que le système sera initialement considéré sans défaillance, puis, dans une deuxième phase, les défaillances de la partie opérative (PO) seront prises en compte grâce aux informations issues du système de diagnostic. Le texte met en avant le caractère modulaire et itératif de la conception du filtre, ce qui permet de réduire la complexité et d'assurer une applicabilité concrète dans le monde industriel. La création du filtre implique la collaboration d'un expert qui définit les contraintes de sécurité, et d'un ingénieur qui conçoit la commande de manière classique. L'article précise que le filtre stoppe le système dans un état sûr dès qu'une contrainte n'est pas respectée, mettant l'accent sur la sécurité du système comme priorité absolue.

Cette partie explore la gestion des actions incohérentes de l'opérateur ou de la partie commande. Le système de filtrage est conçu pour détecter et empêcher les manipulations dangereuses ou non conformes au cahier des charges. Le texte aborde la nécessité d'une aide à la conduite pour l'opérateur, en lui fournissant des explications claires en cas d'action incohérente. La génération d'explications est essentielle, surtout lorsque la partie opérative (PO) est figée par le filtre. L'objectif est de permettre à l'opérateur de comprendre l'erreur et de rétablir mentalement les indices nécessaires à la correction. Le document mentionne également les pannes possibles sur les capteurs ou les actionneurs de la PO, ainsi que l'importance d'un système de diagnostic couplé au filtre de sécurité pour un fonctionnement optimal. Ce système de diagnostic coopère avec l'opérateur de conduite pour statuer sur les indécisions possibles du diagnostiqueur, assurant une sécurité maximale.

La conception du filtre de sécurité repose sur une approche modulaire et itérative de modélisation et de validation du procédé. L'objectif est de diminuer la complexité globale et d'assurer son applicabilité industrielle. Le comportement des composants et du produit est modélisé à l'aide d'automates temporisés communicants, en considérant la commande la plus permissive. Le fonctionnement de l'API (Automate Programmable Industriel) est également modélisé. Le model checker UPPAAL est utilisé pour vérifier que le système évite les états dangereux, en utilisant différentes propriétés telles que 'p toujours vrai', 'p atteignable' et 'passage par p'. Cette étape de vérification est cruciale pour garantir la sécurité du système. L'expert identifie, pour chaque état dangereux, le sous-ensemble de la partie opérative (PO) à modéliser pour la vérification par model-checking. Il définit les contraintes sécuritaires qui constituent le filtre et identifie les observateurs nécessaires pour reconstruire les informations manquantes, notamment dans les cas de non-observabilité du système (par exemple, la présence d'une pièce entre deux capteurs).

Le filtre est défini comme un ensemble de contraintes de sécurité (CS) obtenues par une approche modulaire et itérative. Ces contraintes, qui constituent le cœur du filtre, peuvent être simples (CSs), intervenant sur une seule sortie à l'instant t, ou combinées (CSc), impliquant plusieurs sorties. Elles nécessitent la connaissance des entrées/sorties (E/S) à l'instant courant et potentiellement aux instants précédents, ce qui confère au filtre une fonction mémoire. Des observateurs peuvent être nécessaires pour compenser le manque d'observabilité du système, notamment dans les cas de flux de produits. Ces observateurs correspondent à une fonction séquentielle des entrées de l'API et permettent de simplifier les contraintes en des fonctions logiques combinatoires. Les contraintes de sécurité sont exprimées sous forme de fonction logique (monôme, produit de variables logiques) devant être égale à 0 à chaque cycle de l'API pour être respectée. Un état initial de repos (à 0) pour les actionneurs est considéré comme sûr. Le système est considéré sûr si et seulement si toutes les contraintes de sécurité sont respectées à la fin de chaque cycle API. L'architecture du filtre est représentée schématiquement, illustrant la relation entre les observateurs, les contraintes de sécurité et les sorties du système.

L'approche de conception du filtre met l'accent sur sa modularité et son caractère itératif. Cette approche permet de réduire significativement la complexité du processus de conception et de validation, un aspect crucial pour son applicabilité industrielle. Le filtre est conçu par un expert, tandis qu'un ingénieur conçoit la commande de manière classique. La collaboration entre ces deux profils est essentielle pour garantir à la fois la sécurité et l'efficacité du système. La méthodologie itérative permet d'affiner progressivement le filtre, en intégrant des modifications et des améliorations basées sur les résultats des tests et validations successifs. Cette approche permet une gestion plus efficace de la complexité, en décomposant le problème en sous-systèmes plus faciles à gérer, garantissant une approche plus robuste et plus facilement maintenable. La simplification de la complexité est un facteur clé pour l’implémentation réussie du filtre dans le contexte industriel.

Cette section présente une approche décentralisée pour le diagnostic des défauts dans les systèmes de production industrielle. Elle souligne l'importance du diagnostic non seulement pour la sûreté de fonctionnement, mais aussi pour l'efficacité de la maintenance. Contrairement aux approches centralisées, difficiles à mettre en œuvre pour les systèmes complexes, une approche décentralisée est privilégiée, malgré la complexité de définir un niveau de décomposition modulaire générique. Le document mentionne les approches classiques avec représentation explicite des défauts dans le modèle, basées sur la construction d'un diagnostiqueur prenant des décisions sous forme d'étiquettes. Ces approches, initialement proposées par Sampath (1995), créent un modèle du comportement normal et défaillant du système. Cependant, elles sont limitées à des informations discrètes (capteurs et actionneurs tout ou rien). Pour enrichir la connaissance du système, des approches à base de modèles utilisant des 'templates' ou 'chroniques' sont mentionnées. Des méthodes sans modèle, souvent issues des systèmes experts, sont aussi abordées, mais leur acquisition de connaissances auprès d'experts peut s'avérer difficile et fastidieuse.

L'approche décentralisée repose sur l'utilisation de diagnostiqueurs locaux, obtenus par la modélisation locale d'une partie du composant, appelée partie de la partie opérative (PoP). Un système de production est défini comme une chaîne fonctionnelle avec une partie commande (PC) et une partie opérative (PO). Seuls les échanges d'informations entre la PO et la PC sont observables en ligne. Un diagnostiqueur local est donc créé pour chaque PoP après identification de tous les défauts possibles pour chaque état normal de chaque composant. Cette identification est réalisée par un expert, qui définit l'ensemble des défauts associés à une étiquette du diagnostiqueur. Une partition de défauts est associée à plusieurs étiquettes indiquant le type de défaillance. Deux hypothèses sont considérées pour modéliser les défauts: une hypothèse forte supposant la fiabilité de la partie commande (PC), puis l'utilisation d'une approche de filtre pour lever cette hypothèse et simplifier les modèles de diagnostic. La construction des diagnostiqueurs locaux est simplifiée grâce à l’utilisation d’un filtre, et son niveau de performance dépend de la granularité des modèles et du filtre de commande.

La coopération entre le filtre de sécurité et le diagnostic est essentielle pour améliorer la robustesse du système. Lorsqu'une défaillance survient sur un capteur ou un actionneur, les contraintes du filtre contenant les variables logiques associées deviennent erronées. Une commande autorisée peut devenir interdite, et vice-versa. Pour pallier cela, les contraintes du filtre sont enrichies par les informations des diagnostiqueurs. Un 'flag' est positionné à vrai lorsque le diagnostiqueur détecte une défaillance (état sans transition de sortie). Ce 'flag' détermine si la variable du capteur ou de l'actionneur peut être utilisée dans la contrainte du filtre (flag faux) ou si une information reconstruite doit être utilisée (flag vrai). Dans ce dernier cas, une information temporisée est introduite dans la contrainte. L'utilisation de l'algorithme de Kumar, adapté aux spécifications sous forme de contraintes logiques, permet une intégration automatique du filtre pour simplifier la construction des diagnostiqueurs. Le document souligne que la simplification des diagnostiqueurs dépend de la granularité des modèles locaux et des performances du filtre de commande. La gestion des défaillances des actionneurs diffère de celle des capteurs, car la défaillance d'un actionneur nécessite un arrêt total du système pour des raisons de sécurité.

Cette section explique la nécessité d'un système de génération d'explications pour aider l'opérateur à corriger les erreurs de commande. Lorsque le filtre de sécurité se déclenche, la partie opérative (PO) est figée, empêchant l'observation des conséquences directes de la commande erronée. L'absence d'indices rend le diagnostic difficile pour l'opérateur de maintenance. Le système d'explications vise donc à reconstruire ces indices manquants, en proposant des pistes de recherche pour identifier la cause de l'erreur. Il est important de fournir une aide compréhensible, permettant à l'opérateur de comprendre son erreur (s'il en est la source) ou celle de la partie commande, et d'améliorer son expertise. La génération d'explications doit permettre de rétablir mentalement les indices suffisants pour corriger l'erreur, que celle-ci provienne d'une action incohérente de l'opérateur ou d'une défaillance de la partie commande. Le document souligne également que l'aide doit être adaptée au niveau de compétence de l'opérateur, en proposant différents niveaux d'assistance.

La conception des Interfaces Homme-Machine (IHM) pour la génération d'explications est détaillée. Plusieurs niveaux d'aide sont définis, chacun fournissant un niveau croissant d'informations à l'opérateur. Le niveau 0, 'État Courant', indique simplement que le filtre de sécurité s'est déclenché, affichant l'état réel de la PO. Le niveau suivant, 'Projection', représente l'état dans lequel la PO aurait été sans le filtre, illustrant les conséquences de la commande erronée. Le niveau 'État avant arrêt' affiche l'état de la PO juste avant le déclenchement du filtre, mettant en évidence la situation interdite. Enfin, le niveau 'Hypothèse' propose des explications plus détaillées sur le mauvais fonctionnement de la commande, incluant l'état initial correct, les changements d'état des capteurs/actionneurs ayant mené à l'erreur, et les actions attendues sur les actionneurs. Le document souligne que plus le niveau d'aide est élevé, plus l'analyse se complexifie, impliquant un coût de développement plus important. Des expérimentations ont été menées pour déterminer le niveau minimal d'aide suffisant pour un diagnostic efficace.

Des expérimentations ont été conduites pour évaluer l'efficacité des différents niveaux d'explication. 48 participants (45 hommes, 3 femmes, âge moyen 21,94 ans) ont participé aux tests. Un protocole expérimental a été mis en place, incluant des questionnaires pour évaluer le savoir-faire des participants en automatisme. Chaque participant a effectué trois passations : une situation de référence sans aide, une avec la 'vue projection', et une avec un niveau d'aide plus avancé. Les scénarios et niveaux d'aide étaient croisés selon un carré gréco-latin pour éviter les effets d'ordre et d'apprentissage. Les résultats, basés sur les réponses aux questionnaires, montrent que plus le système d'aide fournit des explications détaillées, plus les opérateurs détectent et corrigent facilement les erreurs. Le niveau 'Hypothèse', malgré sa complexité, s'est révélé le plus efficace pour la correction des erreurs, même si les autres niveaux avancés ont également donné de bons résultats. Le document conclut sur l'importance d'un système d'aide fournissant des indices suffisants pour le diagnostic et la correction des erreurs de commande. L'implémentation des interfaces IHM a été réalisée sur un contrôleur WAGO à l'aide du logiciel CodeSys.

L'étude de cas porte sur un système virtuel de tri de caisses, provenant de la collection ITS PLC développée par la société portugaise Real Games (Magalhaes et al., 2012). Ce système de simulation, téléchargeable gratuitement sur www.realgames.pt, est utilisé pour la formation à l'automatisation (Riera et al., 2011). Le système de tri de caisses a pour objectif d'acheminer des caisses d'un tapis d'alimentation vers des monte-charges, en les triant selon différents critères (arrivée, taille, etc.). Il est instrumenté avec 11 capteurs permettant de déterminer la taille des caisses (petite ou grande), leur position sur les convoyeurs (alimentation, intermédiaire, évacuation), et la position du plateau tournant. Le système dispose de 7 sorties API (Automate Programmable Industriel) contrôlant les différents convoyeurs et le plateau tournant. Pour simplifier l'étude, les convoyeurs de sortie sont considérés comme toujours en marche, et la gestion des boutons 'start' et 'stop' n'est pas détaillée. L'analyse du diagnostic et la coopération filtre/diagnostic se concentrent sur l'actionneur A4, qui contrôle la rotation du plateau tournant, un actionneur simple effet revenant à sa position initiale si l'ordre n'est pas maintenu.

L'obtention du diagnostiqueur et la coopération filtre/diagnostic sont illustrées sur le plateau tournant (actionneur A4) utilisant les capteurs C4 et C5. L'activation de A4 provoque la désactivation de C4 puis l'activation de C5, dans des intervalles de temps prédéfinis (I2 et I4) par les spécialistes. Cinq intervalles de temps sont définis par apprentissage. Le modèle de diagnostic du plateau est présenté (Figure 12), prenant en compte les contraintes 22 et 23. Pour chaque partition de défaut (plateau, capteur C4, capteur C5), un flag est positionné à vrai en cas de défaillance détectée. Ce flag détermine l'utilisation des informations dans les contraintes du filtre. En cas de défaillance capteur, les informations C4 et C5 sont remplacées par leur estimée lorsque l'intervalle de temps correspondant est actif (équations 29, 30, 31). Une défaillance de l'actionneur A4 nécessite un arrêt total du système, contrairement à une défaillance capteur qui peut permettre un fonctionnement dégradé sous certaines conditions, avec remontée d'informations à l'opérateur si nécessaire.

Dans le cadre du système de tri de caisses, des interfaces utilisateur (IHM) pour le module d'explication ont été développées et implémentées sur un contrôleur WAGO avec le logiciel CodeSys. Ces IHM sont connectées au filtre de sécurité et aux programmes utilisateurs. Tous les niveaux d'aide initialement définis ont été implémentés et évalués. L'étude se concentre sur la détermination du niveau minimal d'explication efficace pour un agent de maintenance. Les interfaces, représentées par une vue de dessus, illustrent différents niveaux d'aide : 'État courant', 'Projection', 'État avant arrêt', et 'Hypothèse'. L'exemple présenté concerne le déclenchement de la contrainte CSs10, un relâchement de la commande du plateau tournant A4 alors que la caisse n'est pas complètement évacuée (C7 actif). Les niveaux 'État courant', 'État avant arrêt', et 'Projection' permettent de reconstruire la situation. Le niveau 'Hypothèse' vise à aider l'opérateur à comprendre les événements conduisant à l'erreur et l’état attendu des actionneurs. La complexité de la génération du niveau 'Hypothèse' est soulignée, avec 122 cas possibles à étudier dans cet exemple.

Un protocole expérimental a été conçu pour évaluer les niveaux d'explication, avec 48 participants (45 hommes, 3 femmes, âge moyen 21,94 ans). Chaque participant a évalué les aides individuellement lors de sessions de deux heures maximum. Un questionnaire a évalué leur niveau de compétences en automatisme. Les participants ont testé trois passations : une situation de référence sans aide, une avec la 'vue projection', et une avec un niveau d'assistance avancé. Les scénarios et niveaux d'aide étaient croisés selon un carré gréco-latin. Les résultats subjectifs, issus des questionnaires, montrent que plus le système d'aide fournit d'explications, plus les opérateurs détectent et corrigent efficacement les erreurs. Le niveau 'Hypothèse' s'est avéré le plus efficace, bien que les autres niveaux avancés aient aussi fourni de bons résultats. L’étude conclut sur la nécessité de déterminer le niveau d’aide minimal suffisant pour un diagnostic correct des erreurs de commande, en tenant compte du compromis entre l’efficacité de l’aide et son coût de développement.