Interface supervision : Différence entre versions

Version actuelle datée du 28 mai 2013 à 11:36

Présentation du projet

Description

Il s'agit d'un système hydraulique constitué de deux réservoirs ( T1 et T2) alimentés par une pompe et qui pouvant communiquer à l'aide d'une vanne. Ce système est la représentation d'une station hydraulique réelle qui doit être régulée en niveau à l'aide d'une interface de supervision distante. Il contient deux capteurs de niveaux pour chacune des deux cuves et un capteur de débit à la sortie de la pompe.

Objectifs

Notre projet est constitué principalement de deux parties: La première consiste à améliorer l'aspect visuel du modèle proposé en utilisant l'interface de Labview en lien avec la boite à outil RTW de Matlab/Simulink le tout en temps réel. La deuxième consiste à corriger quelques limites du PID mis en place par de nouvelles commandes, notamment la prédicateur de Smith et la commande Floue.

Compétences demandées

• La commande avancée.

• Modélisation et identification des systèmes linéaires invariants.

• Maîtrise du logiciel de simulation Labview.

• Maîtrise de Simulink ainsi que la boite à outil RTW.

Matériel

• Le système hydraulique.

• La carte d'acquisition National Instrument.

Logiciel

• Matlab/Simulink

• Labview

• NI Max

Avancement du projet

Semaine par semaine

Semaine 1 (04/02/13)

Dans les séances de la première semaine il était question de bien comprendre le fonctionnement général du système. On a réalisé différents testes en temps réel en introduisant à chaque fois des perturbations par les différentes vannes pour voir la performance du PID utilisé face à telles contraintes.

D'autre part, on a fait une synthèse objective des objectifs attendus de ce projet ainsi que les compétences à mettre en évidence pour aboutir aux résultats attendus. On a donc décidé de partager le projet en deux parties principales: La première s'occupe de la partie interface Labview en liaison avec le modèle Simulink, la seconde est consacrée à l'amélioration de la commande utilisée en fonctions des limites découvertes du PID après les différents testes.

Semaine 2 (14/02/13)

En premier temps, on a rassemblé les logiciels nécessaires pour la réalisation de la première partie du projet. Le poste ne disposait pas de Labview et l'école n'offre qu'une version très ancienne (V6.1), on a du contacte National Instrument pour avoir une License pour étudiant. On a pas pu avoir une License mais une version d'évaluation prolongeable. En second temps, on a énumérer les solutions plausibles et étudier leurs faisabilités.

Solutions trouvées:

1- Récupération du PID utilisé dans Matlab/Simulink et reconstruction de la totalité du modèle sur Labview.

2- Création d'un tunnel ActiveX entre l'interface réalisée sur Labview et un tableur (Excel par exemple) puis récupérer les données d'entrées sorties et l'action du PID sous formes de tables numériques sur ce dernier

3- Compilation du modèle Simulink sous forme d'un fichier DLL puis utilisation de l'utilitaire SIT (Simulation Interface Toolkit).

Semaine 3 (27/02/13)

Les séances de cette semaine étaient consacrées pour la mise en pratique des deux premières solutions proposées ci-dessous. On tire les conclusions suivantes pour chacune de ces solutions:

Solution 1: Cette solution est assez intuitive. Puisqu'il s'agit d'avoir des résultats plus exploitables visuellement, il suffit de récupérer le PID utilisé dans Matlab/Simulink et de refaire tout le modèle sur Labview.

Cette solution n'a pas été choisie pour deux raisons: D'une part parce que la configuration du PID du modèle Simulink a été faite avec des tables d'étalonnages spéciales pour ce modèle, et donc il est nécessaire soit de reconfigurer le PID soit de refaire les tables d'étalonnage pour Labview. D'autre part, en choisissant cette solution on dépasse les limites du cahier des charges, le travail va être réalisé uniquement sur Labview et les solveurs de Matlab ne seront pas exploités.

Solution 2: Le tunnel ActiveX avec un tableur se réalise facilement, mais les données récupérés du modèle Simulink ne sont pris que dans un intervalle de temps bien limité. Le tunnel ActiveX fonctionne avec un tableur statique, c'est-à-dire qu'il ne change pas de valeurs en temps réel. Cette solution est rejetée.

Semaine 4 (04/03/13)

La seule solution qui nous parait faisable alors est l'utilisation du SIT. Il a fallu contacter National Instrument pour avoir une version d'évaluation vu que ce module n'est pas disponible sur les postes de l'école. Après l'acquisition de ce dernier il a fallu chercher des documentations sur l'utilisation de ce module. Les configurations sur Matlab/Simulink ont été rapidement faites mais du côté de Labview le module n'était toujours pas détecté. Le module "Real Time Module" n'était pas disponible sur la version fournie. Après mise à jour, nous avons réalisé une simple interface Labview communicante avec Simulink pour illustrer les fonctionnalités de ce module.

Il s'agit d'un signal sinusoïdal créé à partir d'un modèle Simulink et dont la fréquence et l'amplitude sont commandables à partir d'une interface Labview qui contient deux potentiomètres et un graphe déroulant.

Semaine 5 (07/03/13)

Au cours des séances de cette semaine, l'objectif est d'appliquer les mêmes méthodes pour l'exemple de la sinusoïde sur le modèle fournie.

Ci-dessous une image du modèle Simulink initial.

Pour que le modèle soit exploitable par Labview il faut le compiler en un fichier DLL. La compilation s'est faite sans problème pour notre exemple, cependant en faisant la même démarche pour notre modèle Simulink initial la compilation ne se fait pas et on obtient un message d'erreur.

Semaine 6 (13/03/13)

Les objectifs de cette semaine étaient de repérer les sources d'erreur et de les corriger.

En premier temps il a fallu déterminer lequel des blocs de notre modèle qui n'est pas compilable. Intuitivement, les blocs qui doivent poser problèmes sont les entrées et sorties analogiques, pour valider cette hypothèse on les a remplacé par de simples échelons. Résultat: le système est bien compilé.

La première conclusion qu'on a tirée est que les pilotes des entrées sorties analogiques ne sont pas correctement installé ou mise à jour. Nous avons contacté le support Matlab France et National Instrument et d'après eux tout est bien installé.

Semaine 7 (20/03/13)

En se référant aux principes de fonctionnement de la RTW et du Module NIDLL (SIT), nous avons trouvé qu'il est impossible d'utiliser deux configurations en même temps pour le même modèle: La RTW créé elle aussi un fichier C à partir du modèle Simulink qui est implémenté dans la carte d'acquisition, et lorsque le modèle est en fonctionnement temps réel les configurations de la simulation sont changées pour fonctionner avec la RTW or ces configurations ne sont pas bonnes pour fonctionner avec le SIT.

Pour résoudre les problèmes de la solution précédente, nous avons utilisé deux modèles Simulink en communication entre eux. Le premier ne contient que les entrées sorties analogiques et ne s'occupe que de l'acquisition des données temps réel puis de les envoyer au deuxième modèle qui lui configuré pour le SIT et la communication avec Labview.

Les deux modèles fonctionnent chacun à part mais Matlab ne propose aucune fonction pour envoyer en temps réel les données d'un modèle vers un autre. Le système ainsi crée n'est pas en temps réel et cette solution était donc rejetée.

Semaine 8 (25/03/13)

Au cours des deux séances de cette semaine, nous avons fait une modélisation d'un des deux réservoirs en effectuant une identification, on trouve un système de premier ordre. Puis on a élaboré une interface Labview commandant le système dans Simulink.

La compilation se fait correctement mais au niveau de Labview lors du mapping des entrés sorties le PID n'est pas considéré comme une entité complète mais comme trois correcteurs; le proportionnel, l'integral et le dérivateur.

On a donc remplacer le PID par un autre correcteur (observateur Floue) pour éviter ce problème. Le réglage de ce correcteur n'était pas fait car il était juste question de tester la faisabilité de cette solution. En simulation, on arrive donc a créé une interface Labview en liaison avec le modèle Simulink tout en respectant le cahier des charges. Il reste valider ce modèle en temps réel.

Semaine 9 (28/03/13)

Dans cette semaine, on a créer des objets dans Labview capables de recevoir et de commander la pompe directement à partir de l'interface; L'idée est de n'utiliser que la partie correction de Simulink. Pour cela on a du utiliser les assistants DAQ (Data Acquisition) et le module NI Max qui s'occupe des périphériques National Instrument. La vidéo montre comment on commande le système hydraulique directement à partir de notre interface de Labview.

Théoriquement la liaison doit se faire en temps réel, mais lors du mapping du modèle Simulink qui est exactement comme le modèle de Simulation la compilation s'arrête et ne nous autorise pas valider le modèle car la version d'évaluation ne permet ce genre d'exécution. Ci-dessus le message ainsi affiché.

Semaine 10 (04/04/13)

Les séances de cette semaines sont réservées pour la deuxième partie du projet: La commande.

Dans cette semaine on a réalisé la commande du prédicateur de Smith. L’intérêt de cette commande est que lorsqu'on introduit un retard (simulé par un serpentin dans notre système hydraulique) le système reste stable et ne présente pas de dépassement.

Pour pouvoir réaliser cette commande on a d'abord effectué une identification en envoyant un échelon au système en boucle ouverte. La réponse temporelle trouvée est celle d'un première ordre. Ci-dessous le schéma de principe pour la boucle ouverte utilisée pour l'identification.

On réalise la commande et après l'ajout d'un retard de 5s on retrouve le résultat suivant:

Le correcteur satisfait aux objectifs.

Semaine 22 (10/04/13)

Dans cette semaine on a réalisé la commande floue pour le réservoir T1. Ci dessus les résultats obtenus.

Semaine 24 (29/04/13)

Réalisation de la vidéo et finalisation du rapport.

Fichier:Rapport final XING MABROUL.pdf