Voir la source de Etude des possibilités de distribution d'un algorithme de surveilance

==Introduction==
Dans le cadre de notre formation en dernière année IMA, nous avons été amenées à effectuer un projet de fin d'études. Vu l'importance de ce dernier dans le cadre de notre projet professionnel, notre choix s'est porté sur l'étude des possibilités de distribution d'un algorithme de surveillance car nous sommes toutes les deux intéressées par la supervision, le diagnostic, la tolérance aux fautes et la surveillance des systèmes automatisés, sujets qui sont au coeur des préoccupations industrielles courantes. Ce projet nous initiera également à la maîtrise d'outils de développement industriel pour résoudre des problématiques courantes, à savoir la détéction, l'isolation des défauts et le contrôle/commande distribué. D'où l'intérêt porté sur celui-ci. 

==Présentation du projet==

Les systèmes automatisés sont de moins en moins contrôlés et supervisés de façon globale. Leur architecture évolue d’une architecture centralisée vers une architecture distribuée où les algorithmes de commande sont implantés au plus près des producteurs d’informations. Les capteurs et actionneurs deviennent des instruments intelligents capables de prendre en compte des fonctions habituellement implantées à un niveau global de supervision. L’objectif du projet est d’étudier les possibilités de distribution d’une application de surveillance (détection et localisation de défauts) en partant d’une architecture distribuée définie uniquement du point de vue commande. Pour ceci, le projet se découpera selon les grandes parties suivantes : 
- Etude de l’analyse structurelle, approche classiquement utilisée pour générer des relations de redondance analytique, permettant d’élaborer des algorithmes de surveillance.
- Proposition d’une démarche pour répartir au mieux les algorithmes de surveillance au plus près des producteurs d’informations.
- Validation de la démarche proposée sur le générateur de vapeur. Cet équipement, installé en D301, reproduit le fonctionnement d'une centrale thermique. Il sert de support à la validation de travaux de recherche dans le domaine de la supervision des systèmes automatisés (détection et localisation de défauts, élaboration de lois de commande tolérantes aux fautes …).
Les algorithmes sont développés sous Matlab/Simulink et implantés sur une carte d’acquisition et de traitement temps réel DSPACE. 

Dans un premier lieu, nous allons donc comprendre le principe de l'analyse structurelle pour l'étudier sous le générateur de vapeur. Ensuite, nous allons proposer un algorithme de surveillance afin de décentraliser la commande des différents systèmes du générateur de vapeur, pour au final l'implémenter sous la carte DSPACE. 


==Réalisations==

<u> Du 17 septembre  au 29 septembre </u>
Documentation sur l'analyse structurelle

Documents : 
* Analyse_Structurelle_Staroswiecki.pdf
* Diagnosis and default tolerant control

Résultats : 
* Compréhension du principe de l'analyse structurelle, en parallèle avec le cours de Supervision (Mr. Bouamama)
* Rédaction d'un premier rapport intermédiaire expliquant le principe des relations de redondances analytiques, des matrices de signatures des fautes, et du couplage. 

<u> Du 1er octobre au 15 octobre </u>

Documentation sur le générateur de vapeur (GV)

Documents :
* HERMES_GV_FINAL.pdf
* GV_MARCEL.pdf

Résultats :
* Interprétation de l'analyse structurelle sur le GV
* Création des RRA du GV, de la Matrice de signature des défauts. (MSF)

<u> Du 15 octobre au 20 octobre </u>

Documentation sur La MSF des étudiants de l'année dernière
Comparaison avec notre MSF obtenue

<u> Du 5 novembre au 17 novembre </u> 
Implémentation d'un algorithme Matlab, avec la fonction de Dulmage Mendelsohn, pour obtenir une MSF triangulaire supérieure afin de faciliter sa décomposition en sous-systèmes. 
Résultats : 

* Voir code pièce jointe : [[Fichier:image.png]]

La matrice résultante après la décomposition de Mendelsohn est la suivante : 
[[Fichier:matrice.png]]

Notons que la décomposition de Mendelsohn n'est pas unique, mais nous fournit plusieurs décompositions pas plus triangulaires que celle obtenue. Ainsi, la matrice obtenue nous facilite la décomposition en sous-systèmes. 

Notons également que nous pouvons procéder manuellement à cette décomposition en sous-systèmes, mais cette méthode a été déjà effectuée l'année passée, et nécessite l'étude de chaque cas à part. D'où la nécessité de créer un algorithme qui nous effectue la décomposition automatique quelque soit la matrice et le système étudié.

<u> Du 20 novembre au 24 novembre  </u>

Prise en main du GV et des capteurs installés
Rédaction d'un 2nd rapport intermédiaire, résumé de ce qui a été fait.

Photo du GV : [[Fichier:GV.jpg]]

<u> Du 26 novembre au 1er Décembre </u>

[[But :]] Création d'un premier algorithme de décomposition sous Matlab, pour la décomposition en sous-systèmes, dans le but de décentraliser la commande du GV. 

Il existe déjà 4 microcontrolleurs, et un PC maître qui les supervise, il faudra donc séparer le système en 3 ou 4 sous-systèmes, appelés aussi unité de contrôles (CU).

Les CU doivent être décomposés de façon à réduire les flux sur le bus de terrain les reliant entre eux. Il faudra donc réfléchir à une procédure qui minimise ce flux, en introduisant à partir de la MSF, les différents capteurs et le calcul des RRA dans les 3 ou 4 CU.

<u> Du 3 décembre au 13 décembre </u>

Résultat du 1er algorithme non satisfaisant, recherche d'un deuxième algorithme répartissant la matrice sous 3 sous-systèmes, tout en triangularisant la matrice de façon à réduire le flux des échanges entre les sous-systèmes obtenus. L'algo est le suivant : 


[[Fichier:algo.png]]


Cet algorithme nous permet d'avoir un résultat satisfaisant, comme l'illustre la figure [[Fichier:testo.png]]

Nous avons validé la démarche par la prof.

Nous avons également rédigé le rapport et le PPT pour la soutenance du mardi 18 dédembre.


==Conclusion==

Nous avons réussi à comprendre et analyser le cahier des charges, en commençant par une première approche théorique de l’analyse structurelle, pour enfin réussir, après de nombreux essais à trouver un algorithme qui satisfait nos exigences, et qui répartit notre système en trois unités de contrôles homogènes, réduisant les échanges entre eux.  La moitié du travail est faite, reste à implémenter notre algorithme en temps réel sous DSPACE, et le tester pour pouvoir effectuer la supervision décentralisée du générateur de vapeur.

=== Deuxième partie ===


<u> Du 21 janvier au 2 février </u>

Développement sous Matlab de la méthode de décomposition validée lors de la première période.
Dans notre plan de travail, nous avons prévu une semaine pour ce développement. Néanmoins, la méthode demandait plus de temps que prévu. Vu l'importance des autres points à venir, nous avons décidé de la finaliser plutard.

<u> Du 4 février au 9 février </u>

Implémentation de l'algorithme de surveillance.

Nous avons repris le modèle effectué par les étudiants de l'année dernière, de façon à répartir les différents capteurs selon la nouvelle décomposition, c'est-à-dire : Avoir 3 unités de contrôle qui communiquent entre elles, à l'aide d'un réseau modélisé sur Matlab/Simulink, qui traitent les notions de communication réseau, i.e : envoi et réception des données entre les sous-systèmes.

Nous avons pensé à deux solutions : (modélisées sous Simulink)
1) Ordonnancer les tâches des trois sous-systèmes afin qu'ils puissent communiquer les données générées entre eux.
2) Mettre en place des 'block delay" sur les sorties communiqués des sous-systèmes pour respecter les temps d'envoi et de réception de données entre eux. 

<u> Du 11 février au 16 février </u>
Tests en mode Hors Ligne. Nous avons estimé les valeurs des capteurs sans avoir à connecter notre modèle avec le GV.
Dans un premier lieu, nous avons testé notre démarche en mode Hors ligne, c’est-à-dire que nous avons utilisé des valeurs théoriques fixées au préalable, qui représentent les données fournies par les capteurs du GV, pour en générer les résidus. Ensuite, nous avons comparé à l’aide d’une soustraction les résidus issus de la modélisation centralisée, à ceux que nous avons obtenu après la décentralisation. 
Nous nous sommes rendues compte que les calculs de tous les résidus en mode décentralisé, se font en même temps, comme dans le cas du mode centralisé. Alors qu’en réalité, les unités de contrôle échangent des données capteurs entre elles, par conséquent, le calcul des résidus du système nécessite un temps de communication entre les sous-systèmes en question.  Ce qui nous a poussées à réfléchir à une méthode pour respecter le temps de communication entre les unités de contrôle. 
Le sous-système correspondant à la régulation « niveau d’eau + Débit vapeur » ne demande aucune donnée des autres sous-systèmes pour effectuer ses calculs de RRAs, mais les deux autres réclament les données validées par celui-ci. Nous avons donc songé à lui donner la priorité d’exécution. Puis viendra en second lieu le sous-système régulation « niveau d’eau dans le condenseur » qui ne demande que deux données. Puis en dernier lieu, nous placerons le sous-système « régulation de la cuve et du circuit de refroidissement ». Cet ordonnancement a été représenté par des « blocks delay » sur Simulink, traduisant 
un retard de communication entre les valeurs des capteurs échangées. Ci-dessous le schéma Simulink de notre représentation. 
[[Fichier:centr.jpg]]

<u> Du 17 février au 24 février </u>
Tests en ligne sur le GV 

La suite du travail consiste en la validation de cette démarche sur le générateur de vapeur installé en D301A. Notre travail a commencé par la prise en main de l’installation et la maîtrise du pilotage de l’installation. Comme le GV est un système important en taille et en risques, il est impératif de respecter des règles de sécurité, notamment à l’allumage. Ensuite, une prise en main du logiciel ControlDesk était nécessaire avant d’implémenter nos résultats sur la carte d’acquisition. Enfin, nous avons implémenté cet algorithme de surveillance sous Matlab/Simulink, qui consiste, à travers les RRAs générées, à détecter les défauts sur les capteurs, en fonction des seuils préalablement définis, pour générer les alarmes en cas de dépassement de ces seuils.

Interprétation des résultats obtenus

Rédaction du rapport

<u> Du 25 février au 28 février </u>
Préparation de la soutenance
Validation par l'enseignant.