Approche de Détection et d’EXplication d’Erreur de Commande par filtrage robuste

Ce projet GIS (2011-2012) se propose d’étudier les systèmes critiques, pilotés par des opérateurs humains, qui nécessitent une aide à la conduite. Ce projet a pour objectif de proposer une approche assurant la sécurité des personnes et de l’environnement, ainsi que le « bon » pilotage du système en mode normal et en mode dégradé. C’est une collaboration avec le LAMIH de l’Université de Valenciennes et le CRAN de l’Université de Lorraine. Pour répondre à cette problématique, plusieurs verrous scientifiques ont été identifiés :

• La mise en place d’une approche formelle pour développer les filtres de commande tout en respectant un niveau de SIL (Safety Integrity Level) donné pour ces fonctions de sécurité. Par exemple à partir du niveau SIL3, la sécurité doit être prouvée formellement. Quels sont les modèles et la méthode adaptés au contexte normalisé encadrant le développement de fonctions de sécurité ?
• Le filtrage robuste va dépendre des informations provenant de la commande, sur lesquelles le filtre peut agir mais aussi des informations provenant de la partie opérative. Le résultat du filtrage est fortement dépendant de la fiabilité de la PO. Comment prendre en compte les éventuelles défaillances de la PO et les interactions avec les processus de diagnostic des installations ?
• La génération des explications à destination d’un opérateur humain doit être compréhensible et suffisamment synthétique vis à vis de son niveau d’expertise. Quels sont les mécanismes d’abstraction ou de synthèse permettant de générer une explication compréhensible ?

L’interaction entre le filtre de commande et le diagnostic doit permettre de considérer l’état réel du système, c’est à dire les possibles défaillances des capteurs ou des actionneurs. En effet, le fait qu’un défaut survienne sur un capteur ou sur un actionneur, implique qu’il n’est plus possible de lui faire confiance. Par conséquence, il faut en tenir compte du fait qu’il y ait un défaut ou non, dans la définition du filtre. Chaque partition de défauts aura un bit pour informer le filtre sur l’état de décision du diagnostic. Cette information permettra soit d’utiliser la variable si l’information de défaillance est à 0, soit d’utiliser son équivalence si cette information de défaillance est à 1. Lors d’une défaillance, il est possible d’utiliser une information équivalente seulement pour les capteurs, en effet lorsqu’un actionneur est défaillant soit il faut effectuer une tâche de maintenance, soit il faut avoir une redondance fonctionnelle de celui-ci. Pour définir l’information équivalente d’un capteur, nous nous sommes basés sur l’information temporelle qui sépare l’évolution d’une commande de celle d’un capteur et elle a été ajoutée dans les contraintes.

Concernant la génération d’explications, les premiers travaux réalisés ont consisté à cerner de manière exacte le rôle des opérateurs humains. Hormis l’opérateur de conception – celui qui crée la commande qui peut être validée hors ligne – deux « types » d’opérateurs peuvent être distinguées : i) un opérateur de production, en lien direct avec la partie opérative, ii) un opérateur de maintenance en charge de corriger la commande si celle-ci s’avère défaillante.

Les tâches de ces deux types d’opérateurs sont différentes et peuvent conduire à des utilisations différentes du filtre tel qu’il est défini actuellement. Pour ce projet, seul l’opérateur de maintenance a été considéré. Son rôle essentiel consiste ici à assurer le diagnostic de la commande pour ensuite la corriger. Dans ce cadre, le filtre de sécurité assure le blocage de la partie opérative, i.e. le positionnement des actionneurs, de manière à empêcher toutes requêtes erronées issues de la partie commande. Les éléments accessibles au système d’aide pour assurer l’explication à cet opérateur de maintenance sont la règle de sécurité déclenchée, et les entrées et sorties de l’automate qui assure l’exécution de la commande. Les programmes automates ainsi que ses éléments internes tels que temporisation et mémoire sont considérés comme non accessibles, leur analyse étant trop problématique. L’aide au diagnostic de la commande qui peut être faite n’est alors que partielle. Ce projet a fait l’objet d’un poster lors du 4^ème Workshop du Groupement d'Intérêt Scientifique « Surveillance, Sûreté, Sécurité des Grands Systèmes » (GIS-3SGS'11) à Valenciennes, mais aussi de 2 conférences internationales.