Le contrôle/commande modulaire et connecté avec LabVIEW

Emmanuel LANDRIVON et Florian CHAPON, IRCELYON, CNRS

"Les instruments disponibles dans la fenêtre de paramétrage sont tous développés avec une architecture identique de manière à pouvoir facilement en ajouter de nouveaux."

- Emmanuel LANDRIVON et Florian CHAPON, IRCELYON, CNRS

Le défi:

Développer un logiciel configurable depuis un exécutable capable de s’adapter aux nombreux bancs de test de notre équipe « Ingénierie des procédés catalytiques ». Permettre à l’opérateur d’être alerté lors de dysfonctionnements (matériels ou logiciels) et aux données d’être enregistrées (au niveau local et distant) triées et analysées afin que l'utilisateur reçoive des informations pertinentes.

La solution​:

Réaliser un programme sous LabVIEW s'adaptant à l'environnement du banc de test avec une fenêtre de configuration qui permet de sélectionner les instruments à ajouter ainsi que leur paramétrage. Créer un mode séquence qui permet un fonctionnement autonome de l'expérimentation sur une longue durée.

L’application a été développée au sein de l’IRCELYON, (UMR 5256, CNRS-Université de Lyon), le plus grand laboratoire de catalyse de France et d’Europe. Structurées en cinq équipes de recherche, les activités du laboratoire sont au cœur du développement durable avec pour préoccupations majeures l’énergie, l’environnement et la chimie verte. La spécificité de l’équipe réside dans la maîtrise et la volonté de couvrir la chaîne de valeur de l'intégration d’un procédé catalytique, de l’échelle moléculaire jusqu’au démonstrateur.

 

La mise en place d’un banc de test (ou BT) nécessite l’utilisation d’instruments liés à la manipulation des gaz, d’organes de régulation, ainsi que différents capteurs de contrôle pour permettre un travail en toute sécurité et assurer la reproductibilité des mesures effectuées (Figure 1).

 

LabVIEW étant un langage principalement axé sur l’instrumentation, le choix de cet environnement était tout particulièrement indiqué pour le développement d’une application de contrôle/commande. La solution envisagée devait être suffisamment modulaire au vu des similarités instrumentales entre les unités de test, mais également interopérable de manière à consulter les données à distance.

 

Une solution configurable

Pour garantir une solution adaptable à tous nos BT, le logiciel doit s'adapter à son environnement instrumental. Le mode paramétrage (Figure 2) est accessible via un VI dynamique dans lequel l'utilisateur sélectionne les instruments qui équipent son banc. Il peut alors les configurer : ports de communications, valeurs minimales et maximales pour obtenir un report d'alarme, et correction offset. L’ensemble des paramètres et des sélections est enregistré dans un fichier d’initialisation grâce à l’utilisation de la bibliothèque « OpenG Variant Configuration File Library ». Cette dernière facilite le développement, l’architecture du variant étant guidée par le CTL de l’instrument.

 

Des drivers facilement intégrables

Les instruments disponibles dans la fenêtre de paramétrage ont été développés avec une architecture identique et l'ajout d'un nouvel instrument est réalisé en modifiant un instrument existant. Ces drivers contiennent tous un CTL pour la mise en forme de l’interface de configuration, des VIs spécifiques à l’enregistrement/lecture des différents paramètres au niveau du fichier d’initialisation, ainsi qu’un VI d’exécution. Début 2016, l’application incluait 31 drivers, de l’instrument de contrôle et de régulation, à la récupération d’informations provenant d’équipement analytique.

 

Une interface de contrôle/commande optimisée

L’interface principale de l’application regroupe plusieurs sections : un tableau contenant les valeurs et informations des instruments, un graphique permettant de voir l’évolution des tendances, ainsi qu’un bloc contextuel selon l'instrument sélectionné (Figure 3). L’actualisation des valeurs se fait de manière séquentielle, c’est-à-dire que le logiciel « scanne » les instruments un à un et consigne les informations dans le tableau. L’application inclut également un mode « séquence » permettant de programmer l’envoi de différentes consignes (rampe, palier…), permettant d’automatiser des manipulations sur plusieurs semaines sans intervention extérieure.

 

L’enregistrement local et distant

L’ensemble des informations, saisies et générées par l’application (set point, valeur, seuil…) sont enregistrées régulièrement dans des fichiers TDMS afin de faciliter le retraitement des données. Les tendances actuelles facilitant la mise à disposition de l’information, nous avons également travaillé sur l’interopérabilité du système. Pour ce faire, nous avons développé une API reposant sur les services web de manière à pouvoir récupérer les données depuis un ordinateur distant, mais également à les transmettre à d’autres services, comme par exemple des services cloud. L’application va en effet générer un fichier XML (format standard d’API comme le json) à chaque requête qui pourra être alors réinterprété et redistribué (Figure 4).

 

Conclusions et perspectives

Concernant les problématiques initiales, l’application développée répond à la totalité des attentes. La facilité de configuration des équipements ainsi que de leurs contrôles permet aux utilisateurs de travailler de manière autonome sans avoir à connaître les bases du développement sous LabVIEW. L’application est destinée à évoluer, tant au niveau de l’ajout ou de la modification de drivers, qu’au niveau de son noyau pour gagner en rapidité d’exécution, facilité d’utilisation, et ajout de fonctions génériques. Enfin, une attention particulière sera portée à l’évolution des systèmes cloud et des services annexes de manière à ce que l’application conserve une haute interopérabilité. 

 

Informations sur l’auteur:

Emmanuel LANDRIVON et Florian CHAPON
IRCELYON, CNRS
2, Avenue Albert Einstein
69100 Villeurbanne
France
Tel: +33 (0)4 72 44 53 84
MBC@ircelyon.univ-lyon1.fr

Banc de test catalytique comprenant plusieurs instruments de mesures et de contrôles (températures, pressions, vannes…).
Fenêtre de paramétrage de l’application. Configuration des différents paramètres des instruments.
Fenêtre principale de l’application.
Des données brutes aux données connectées et sécurisées (API).