Soutenance mémoire
L’évolution des architectures de commande-surveillance
Les avancées technologiques rapides ont permis de considérer un large spectre de possibilités pour la conception des architectures de surveillance-commande. Cinq structures de base sont généralement identifiées allant de l’architecture centralisée à l’architecture hétérarchique ou distribuée .
Chacune de ces structures est composée d’un ensembles de modules ou nœuds connectés entreeux et liés aux entités physiques et/ou logiques du système (robots, machines, processus etc.). Nous donnons dans cette section une brève description de ces différentes architectures :
• La structure centralisée (Rana et al 1988) est caractérisée par une unité centrale (mainframe) puissante qui réalise la planification, le traitement de l’information et la mise à jour d’une base de données globale. Elle présente l’inconvénient d’être peu fiable en cas de défaillance et difficilement modifiable (Dilts et al 1991). Ceci est dû d’un côté, au fait que le système de commande-surveillance est implémenté sur une seule unité. Toute panne de cette unité entraîne la paralysie des fonctions de surveillance et de commande. Dans le cas de systèmes critiques comme la commande-surveillance d’un réacteur nucléaire ou d’un système embarqué, la paralysie peut avoir des conséquences catastrophiques. D’un autre côté, les besoins d’extension et de modification sont difficilement satisfaits dans une telle structure vu la grande complexité du système de commande-surveillance.
• La structure hiérarchique (Jones et al 1986) (Combacau et al 1990) (Chaillet-Subias 1995) a été utilisée pour la conception d’une architecture de commande-surveillance modulaire et hiérarchique. La complexité des systèmes basés sur des structures hiérarchiques croit rapidement avec la taille générant ainsi des coûts élevés de développement, d’installation, d’exécution, de maintenance, de surveillance et de modification ou de modernisation. En effet, de tels systèmes doivent prendre en compte des changements rapides des technologies et de l’environnement socio économique. Il est aussi difficile d’introduire les mécanismes de tolérance aux fautes dans les structures hiérarchiques sans pour autant augmenter de manière significative la complexité du système. Dans ce type de structure, l’autonomie des différents nœuds de commande-surveillance est très limitée. En effet, la défaillance d’un nœud ou d’une connexion affecte le fonctionnement des nœuds des niveaux plus bas.
• (Piche et al 1983) a suggéré une structure oligarchique ou hiérarchique modifiée dans laquelle le niveau le plus haut est composé d’un nombre relativement petit de coordinateurs communicant entre eux et où les modules d’un même niveau peuvent communiquer. Cette structure a été créée dans le but de palier aux carences de la structure hiérarchique. Elle partage pourtant plusieurs des caractéristiques de l’architecture hiérarchique mais se distingue par un degré d’autonomie plus élevé des niveaux inférieurs. Cette structure présente tous les avantages de l’architecture hiérarchique. Par contre, l’augmentation de l’autonomie implique le traitement de plus d’information par le niveau inférieur. Cette structure présente aussi la plupart des inconvénients de la structure hiérarchique.
• La structure semi-hétérarchique est une structure hiérarchique composée d’un niveau supérieur formé d’un ensemble de coordinateurs et d’un niveau inférieur formé par des modules de commande-surveillance locaux. Ces modules communiquent seulement avec les coordinateurs auxquels ils sont rattachés. En effet, le besoin de coordonner les activités de commande et de surveillance entre les différents modules nécessite une prise de décision sur la base de l’information disponible localement au niveau des modules. Cette prise de décision est effectuée par les coordinateurs. La centralisation de la décision au niveau des coordinateurs donne lieu à un certain nombre d’inconvénients qui ont été présentés dans le cas d’une structure centralisée. En plus, cette structure présente tous les inconvénients de la structure hiérarchique (Duffie et al 1996).
• Les nouvelles avancées dans les domaines de la puissance du calcul distribué et des réseaux de communication (plus particulièrement les réseaux locaux) ont ouvert la voie aux structures hétérarchiques ou distribuées (Rana et al 1988). Les structures hétérarchiques ou distribuées (Dilts et al 1991) (Lin et al 1992) sont une alternative prometteuse permettant de trouver des solutions aux problèmes cités.
Les avancées technologiques dans les domaines du calcul distribué et des communications par réseau sont aussi à l’origine de l’intérêt croissant accordé aux architectures distribuées. Récemment, l’utilisation des architectures distribuées, pour la conception de systèmes de commande, de surveillance, etc., a permis d’améliorer la fiabilité, la disponibilité, l’autonomie, etc. du système considéré. La notion centrale d’une architecture distribuée est la considération d’entités totalement autonomes et coopératives permettant ainsi une prise de décision distribuée. Nous nous intéressons plus particulièrement dans la prochaine section, à la description détaillée de l’architecture hétérarchique.
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 91). 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.
Caractérisation de systèmes distribués à base d’entités
L’adoption de l’approche distribuée pose la question de la manière de décomposer le système en entités, d’éliminer l’information globale, de définir le rôle de l’opérateur dans une telle structure et les mécanismes de tolérance aux fautes à insérer. Nous présentons dans cette section les principes proposés par (Duffie 1990) pour la caractérisation de systèmes distribués à base d’entités. Cette approche, bien qu’elle ne soit pas la seule pour la résolution de ce problème, présente l’avantage d’être générale et indépendante de la nature du système considéré.
Ces principes sont décrits comme suit :
• il y a une décomposition naturelle associée au système ;
• le résultat de la décomposition est un ensemble d’entités quasi-indépendantes avec des interactions relativement faibles ;
• toutes les communications entre les entités prennent la forme de messages transmis sur un réseau de communication ;
• la configuration physique du système doit être transparente aux entités, et les entités ne doivent pas avoir besoin de connaître les localisations des autres entités.
Afin de doter les entités obtenues par la décomposition des caractéristiques recherchées pour les systèmes distribués, l’ensemble des principes généraux suivants (Duffie et al 1988) peut permettre d’obtenir des entités autonomes, coopérantes, tolérantes aux fautes et modifiables :
• les relations maître/esclave doivent disparaître ;
• les entités doivent coopérer quand c’est possible ;
• les entités doivent retarder l’établissement de relations avec d’autres entités le plus longtemps possible et les terminer le plus tôt possible ;
• l’information générée par une entité doit être maintenue localement et communiquée sur demande aux autres entités.
|
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 compe 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
Conclusion
