Contribution à la surveillance distribuée des systèmes à événements discrets complexes

Les fonctions de supervision-surveillance

Dans ce paragraphe, nous définissons les fonctions élémentaires du système de supervision et de surveillance. Les lettres M, S ou C indiquent à quel système précédemment étudié (surveillance (M), Supervision (S), Commande (C)) est rattachée la fonction (Combacau et al 2000).
Détection (M) : elle détermine la normalité ou l’anormalité du système en fonctionnement. Deux classes d’opérations anormales sont considérées :
la première inclut les situations dans lesquelles les contraintes opérationnelles du procédé sont violées (par exemple les situations de collisions),
la deuxième regroupe les situations dans lesquelles la loi de commande n’est pas respectée (par exemple, les situations de retards dus à des délais de fabrication trop long).
Suivi (M) : il maintient un historique des traitements exécutés et une trace des événements observés par le système de commande-supervision. Diagnostic (M) : il cherche une causalité liant le symptôme, la défaillance et son origine.
Classiquement, trois sous-fonctions sont distinguées : localisation : détermine le sous-système responsable de la défaillance, identification : identifie les causes de la défaillance, explication : justifie les conclusions.
Pronostic (M) : le but de la fonction pronostic est de déterminer les conséquences d’une défaillance sur le fonctionnement futur du système. Deux types de pronostic peuvent être distingués (Boufaied et Combacau 2001). Le premier, appelé pronostic préliminaire, cherche les conséquences inévitables d’une défaillance (identification de l’ensemble des tâches qui ne peuvent plus être exécutées en respectant l’ordonnancement). Le deuxième, appelé pronostic préventif, est centré sur l’erreur latente et sur la propagation de défaillance (la répétition de la même défaillance). Ce type de pronostic est utilisé afin d’éviter de l’exécution d’activités menant à la détection du même symptôme.
Pronostic préliminaire : à ce stade du traitement correctif, seules la défaillances et ses causes sont connues. Afin de prévoir les effets de la faute, trois types d’information sont prises en compte : l’ordonnancement des tâches à exécuter sur la ressource défectueuse, l’analyse hors ligne des conséquences de la défaillance (AMDE pour l’Analyse des Modes de Défaillance et de leurs Effets) (Villemur 1998), les données statistiques concernant l’état d’échec de la ressource (MTTR pour Mean Time To Repair).
Pronostic préventif : seules les défaillances dont les effets ne sont pas immédiatement détectés sont considérées dans ce cas. En effet, une propagation d’erreur peut avoir lieu suivant le routage d’un produit défectueux. Le pronostic préventif détermine s’il y a d’autres produits qui sont affectés par le même défaut qui induirait le même symptôme dans le futur.

La fonction détection

La surveillance d’un système complexe doit permettre de traiter tous les comportements qui s’écartent du comportement attendu en déterminant l’état actuel du système. Cette fonction est un des principaux éléments d’un système de surveillance (Valette et al 1994). Dans un scénario simpliste, la détection (Holloway et al 1990) (Combacau 1991) (Cruette 1991) (Toguyeni 1996) de symptômes de défaillance peut être une observation par un opérateur que le système ne fonctionne pas correctement. Des techniques plus avancées se basent sur la détection «rapide» d’un symptôme de défaillance afin que les mécanismes de recouvrement ou de reconfiguration puissent être exécutés ou que le système soit arrêté pour éviter une propagation des dommages. Ces techniques s’appuient sur les dates limites d’occurrence des signaux attendus, le suivi de l’évolution de l’état du système, les systèmes experts, l’utilisation de capteurs spécialisés et les techniques d’analyse de fréquence. Toutes ces techniques se basent sur l’information envoyée par les capteurs. L’ajout de nombreux capteurs dédiés à la surveillance n’est pas toujours possible pour des raisons techniques et de coûts. Mais surtout, il est désormais largement admis que dans les systèmes à événements discrets (SED), les éléments tombant le plus souvent en panne sont les capteurs. De ce fait, si leur ajout augmente la sécurité, par contre le système de surveillance perd beaucoup de sa disponibilité.
Cette thèse traite en partie l’utilisation de l’information non envoyée par les capteurs dans les mécanismes de détection.
Les défaillances dans les systèmes peuvent être divisées en deux classes : les défaillances liées à la commande incluant des bogues logiciels : l’application des techniques de tolérance aux fautes permet de limiter considérablement le nombre de défaillances dues au système de commande. Ceci techniques seront explicitées ultérieurement dans le cadre d’une architecture de commande-surveillance distribuée.
les défaillances physiques d’éléments du procédé. La détection de symptômes de défaillance liés aux éléments du procédé requiert généralement l’élaboration d’un modèle du système à surveiller (procédé). Ce modèle peut être un modèle de bon fonctionnement ou un modèle de dysfonctionnement. Par exemple, dans le cas de systèmes discrets, un modèle correspondrait à un réseau de Petri, et dans le cas de systèmes continus, un modèle correspondrait à un ensemble d’équations différentielles. Il existe aussi un certain nombre de méthodes de détection qui n’utilisent pas de modèles, c’est à dire qu’il n’est pas fait appel à une description du système surveillé. Il s’agit essentiellement d’outils statistiques, qui permettent des tests sur des grandeurs caractéristiques du système.

Outils statistiques pour la détection

Les outils statistiques de détection consistent à supposer que les signaux fournis par les capteurs possèdent certaines propriétés statistiques. De nombreux tests permettent de vérifier si ces propriétés sont présentent dans l’échantillon des signaux mesurés. Le signal mesuré est considéré comme étant une variable aléatoire (Isermann 1984). Le test le plus simple qui puisse être envisagé est la comparaison des variables observées (continues, discrètes, symboliques ou non, …) avec des valeurs limites fixées à l’avance. Cela revient à supposer que la grandeur mesurée traduit un fonctionnement normal du système lorsque sa valeur de mesure est comprise dans certaines limites. Deux types de seuils peuvent être utilisés : le seuil de prévention dont le dépassement indique l’apparition probable d’un symptôme de défaillance, et le seuil d’anomalie au delà duquel l’évolution des variables est considérée comme anormale. Ces limites sont usuellement choisies de façon à être suffisamment distantes de l’apparition d’une défaillance tout en maintenant un faible taux de fausses alarmes (dépassements qui ne correspondent pas à des défaillances). Une autre technique de test consiste en une fenêtre d’observation. Une fenêtre d’observation est constituée par un ensemble fini de mesures successives des grandeurs du procédé sur un certain horizon temporel.
Les tests statistiques effectués sur ces fenêtres consistent à vérifier les propriétés statistiques que les signaux observés dans cette fenêtre sont supposés posséder.
La fonction détection est, comme nous l’avons défini une fonction de surveillance. Elle doit par conséquent faire partie d’une structure de commande-surveillance particulière. Plusieurs architectures de commande-surveillance sont décrites dans la littérature. Le paragraphe suivant donne un aperçu de leur l’évolution au cours de ces dernières années.

Les architectures hétérarchiques ou distribuées

Le terme hétérarchique est utilisé pour caractériser des systèmes à caractère local, (Duffie et al 1988) (Duffie et al 1996). En effet, ces systèmes collectent de l’information locale et agissent sur une partie du système contrôlé. Ces structures distribuées sont des structures coopératives regroupant des membres ou entités ou sites, ayant chacun un rôle à jouer et communiquant entre eux afin de réaliser un but global. (Hatvany 1985) suggère «une architecture distribuée coopérative» dans laquelle et en dépit de l’absence d’entités de haut niveau, chaque entité doit se conformer à certaines règles afin d’obtenir certains privilèges. (Duffie et al 1988) a proposé une structure distribuée de commande dans laquelle les relations entre entités ne suivent pas le modèle maître/esclave.
Les architectures distribuées offrent un certain nombre d’avantages dont : la réduction de la complexité et l’amélioration de la tolérance aux fautes grâce à la localisation de l’information ; la réduction des coûts de développement des logiciels grâce à la suppression des niveaux supérieurs; l’amélioration de la maintenabilité, de la modifiabilité/extensibilité, de la reconfigurabilité/adaptibilité et de la disponibilité/tolérance aux fautes grâce à l’introduction de la modularité et de l’autonomie. La maintenabilité englobe une maintenance facilitée du système. Un système est dit modifiable si des changements au niveau des éléments du système peuvent être facilement effectués. Un système est extensible si de nouveaux éléments peuvent être facilement ajoutés au système afin d’augmenter ses fonctionnalités (Dilts et al). La reconfiguration du système est souvent nécessaire lorsqu’il s’agit d’ajouter ou de supprimer des composants du système quand il est en cours de fonctionnement, c’est à dire en ligne ; le maintien de la robustesse et de la flexibilité.
En abordant le problème de la caractérisation de systèmes sur la base d’une architecture distribuée, (Duffie 1990) propose de décomposer les besoins fonctionnels du système en un ensemble d’entités quasi-indépendantes et communicantes. Le paragraphe suivant explique une manière de caractériser des systèmes distribués à base d’entités.

La tolérance aux fautes dans un système distribué à base d’entités

La tolérance aux fautes indique la capacité du système à continuer à fonctionner, éventuellement dans un état dégradé, malgré l’occurrence de défaillances logicielles. Elle inclut la détection d’un symptôme de défaillance logicielle, son diagnostic et la détermination des actions appropriées de recouvrement.
Dans la mesure où il n’est pas possible d’identifier toutes les situations de défaillance, il est impossible de définir tous les mécanismes de recouvrement nécessaires pour faire face à toute situation de défaillance du système de commande-surveillance. Dans ces conditions, une structure distribuée présente l’avantage d’améliorer la tolérance aux fautes du logiciel grâce à l’élimination de l’information globale et permet ainsi de réaliser : le confinement des fautes dans les entités, le recouvrement des fautes dans d’autres entités, la réduction de la complexité, la réduction du coût de développement.
De manière générale, un système de surveillance-commande composé d’entités fonctionnant de manière autonome perd certaines de ses fonctionnalités mais pas toutes lorsqu’une ou plusieurs de ses entités sont défaillantes. Les symptômes de défaillance peuvent avoir plusieurs sources dont la défaillance du réseau de communication, défaillance du processeur supportant l’entité, un problème de synchronisation entre entités ou encore des erreurs dans la logique de programmation des entités. Ces symptômes peuvent être détectés quand les messages attendus ne sont pas reçus par les entités ou sont reçus au mauvais moment, ou quand ces messages n’ont pas le bon contenu. Des mécanismes de surveillance de défaillances liées à des bogues logiciels doivent donc être réalisés au sein de toute entité.
Dans un système de surveillance distribuée à base d’entités plusieurs classes de symptômes nécessitent l’exécution des mécanismes de surveillance de manière complètement distribuée ou sous la conduite d’une ou de plusieurs entités. Les actions entreprises localement par les entités doivent être globalement cohérentes . La tolérance aux fautes se trouve ainsi améliorée puisque la défaillance d’une entité participant à la résolution d’un problème distribué de surveillance n’influe pas considérablement sur le résultat obtenu, contrairement au cas ou une seule entité est dédiée à l’exécution des mécanismes de surveillance.

Table des matières

Introduction
I. Cadre de l’étude
I.1. Introduction
I.2. Concepts de base et définitions
I.3. Les fonctions de supervision-surveillance
I.4. La fonction détection
I.4.1. L’approche modèle du procédé
I.4.2. L’approche signature de défaillance
I.4.3. Outils statistiques pour la détection
I.5. L’évolution des architectures de commande-surveillance
I.6. Les architectures hétérarchiques ou distribuées
I.6.1. Caractérisation de systèmes distribués à base d’entités
I.6.2. Exemple d’un système distribué sur la base d’entités
I.6.3. La tolérance aux fautes dans un système distribué à base d’entités
I.6.4. Les protocoles d’interaction dans un système distribué à base d’entités
I.6.5. Les nouvelles architectures distribuées
I.6.6. L’architecture basée agent
I.7.Conclusion
II. Distribution du système de surveillance-commande : prise en compte des aspects temporels dans les systèmes à événements discrets
II.1. Introduction
II.2. La distribution du système de surveillance-commande
II.2.1. Les systèmes de commande distribués
II.2.1.1. Commande distribuée par réseaux de Petri contrôlé
II.2.1.2. Commande distribuée par automates à états finis
II.2.1.3. Prise en compte des délais de communication dans les systèmes de commande distribués
II.2.2. Les systèmes de surveillance distribués
II.2.2.1. Les approches de la surveillance distribuée
II.2.2.1.1. Architecture de surveillance décentralisée proposée par l’Université du Michigan
II.2.2.1.2. Architecture de surveillance décentralisée proposée par l’Université de Toronto
II.2.2.2. Surveillance distribuée à base de modèle
II.2.2.2.1. Surveillance distribuée à base de modèle de comportement
II.2.2.2.2. Surveillance distribuée à base de modèle temporel
II.2.2.2.2.1. Automate temporel
II.2.2.2.2.2. Automate temporisé
II.2.2.2.2.3. Treillis temporel
II.2.2.3. Spécification de contraintes temporelles
II.2.2.3.1. Détermination des contraintes temporelles
II.2.2.3.2. Expression des contraintes temporelles
II.2.2.4. Vérification de contraintes temporelles
II.2.2.4.1. Prévision des dates d’occurrence des événements
II.2.4.2.2 Modèle pour la surveillance de procédé à instance-unique
II.2.2.4.3. Modèle pour la surveillance de procédé à instance-multiple
II.2.2.5. Détection au plus tôt de la violation de contraintes temporelles
II.3. Problèmes liés à la distribution du système de surveillance-commande
II.3.1. Synchronisation d’horloge
II.3.2. Prise en compte des délais de communication
II.3.3. Rétablissement de l’ordre global des messages échangés
II.3.4. Minimisation du coût de communication et de calcul
II.4. Les chroniques
II.5. Conclusion
III. La fonction détection distribuée : prise en compte des délais 
III.1. Introduction
III.2. Définitions
III.3. Décomposition de l’architecture de surveillance
III.3.1. Contraintes locales, contraintes globales
III.3.2. Notion de sous-chronique et de reconnaissance de chronique
III.3.3. Distribution des contraintes temporelles
III.3.4. Le protocole de communication entre superviseurs
III.3.5. Notion de délai
III.3.5.1. Délai de communication
III.3.5.2. Délai opératoire
III.4. Reconnaissance d’une sous-chronique avec prise en compte des délais
III.4.1. Prise en compte du délai de communication dans la vérification des contraintes
III.4.1.1. Cas de contrainte de type intervalle
III.4.1.2. Cas de contrainte de précédence
III.4.1.3. Cas de contrainte de type fenêtre d’admissibilité
III.4.2. Prise en compte du délai opératoire dans la vérification des contraintes
III.4.3. Prise en compte des délais, cas général
III.4.4. Exemples d’application
III.4.4.1. Délai de communication entre superviseurs
III.4.4.2. Délai opératoire ou de transport
III.4.5. Interprétation de la notion de flou
III.4.6. Coopération entre superviseurs
III.4.6.1. Cas d’un délai opératoire
III.4.6.2. Cas d’un délai de communication
III.5. Date d’occurrence imprécise
III.6. Conclusion
IV. Modélisation par réseaux de Petri des mécanismes de la détection distribuée
IV.1. Introduction
IV.2. Rappels sur les réseaux de Petri
IV.2.1. Réseau de Petri et concepts de base
IV.2.2. Réseau de Petri temporel
IV.2.3. Réseau de Petri p-temporel
IV.2.4. Comparaison des deux modèles
IV.3. Modélisation de chronique et principes de base
IV.3.1. Etude des aspects statiques de la modélisation
IV.3.1.1. Modélisation des contraintes
IV.3.1.2. Modélisation d’une chronique
IV.3.2. Etude des aspects dynamiques liés à la modélisation
IV.3.2.1. Les réseaux de Petri p-t-temporels
IV.3.2.2. Prise en compte des occurrences multiples d’un événement
IV.3.2.2.1. Spécification des occurrences multiples d’un événement dans les contraintes
IV.3.2.2.2. Prise en compte des occurrences multiples d’un événement lors de la reconnaissance de la chronique
IV.3.2.2.3. Utilisation des réseaux de Petri pour la prise en compte des occurrences multiples
d’un événement
IV.4. Modélisation de sous-chronique sans prise en compte des délais
IV.4.1. Décomposition du réseau de Petri représentant une chronique
IV.4.2. Regroupement des réseaux de Petri représentant des contraintes temporelles
IV.5. Modélisation de sous-chronique avec prise en compte des délais
IV.5.1. Modélisation d’une contrainte de type intervalle avec prise en compte des délais
IV.5.2. Modélisation d’une contrainte de type fenêtre d’admissibilité avec prise en compte des
délais
IV.5.3. Modélisation d’une contrainte de précédence avec prise en compte des délais
IV.5.4. Modélisation et reconnaissance de sous-chronique
IV.6. Application aux systèmes de transport
IV.7. Conclusion
V. Application à la surveillance d’un terminal intermodal
V.1. Introduction
V.2. Définitions
V.3. Description du terminal intermodal
V.4. Modélisation de l’installation de transport par réseau de Petri
V.5. Distribution des contraintes temporelles et modélisation des sous-chroniques
V.6. Reconnaissance en ligne des sous-chroniques
V.7. Conclusion
Conclusion Générale
Références bibliographiques

Télécharger le rapport complet