Essais & Simulations n°124

dossier
RETouR d’ExPéRiEncE
Un système pour superviser la température
des enceintes climatiques
L’objectif du laboratoire alsacien était le suivant : développer un système permettant
d’évaluer la conformité des produits et d’optimiser l’utilisation et la maintenance d’un parc
d’enceintes climatiques. Pour ce faire, il s’est rapproché de national instrument.
Le principe d’un test en enceinte climatique est de
soumettre un produit (équipement sous tension ou
non) à des contraintes de température et d’humidité.
Il est important de connaître précisément les valeurs
atteintes par les enceintes aÿn d’éliminer les e° ets de bord et
de garantir la qualité de l’essai. Il peut arriver qu’une étuve n’atteigne
pas la température de consigne demandée et rende un
essai incomplet, des défauts pouvant apparaître sur le produit
dans la plage de température ou d’humidité non testée.
Pour s’a° ranchir de ces dérives potentielles, l’utilisateur peut
e° ectuer, au préalable du test du produit, un test des équipements.
Ce test du test garantit la conformité du test ÿnal.
Les logiciels de gestion de parc d’enceintes existent et sont livrés
par les constructeurs. Par contre, aucun d’entre eux n’assure un
autocontrôle indépendant. Pour réaliser ce test d’autocontrôle,
notre client souhaite réutiliser du matériel existant, notamment
des modules Cansas et des sondes PT100 pour la mesure des
températures. Ce projet peut néanmoins être réalisé avec des
châssis NI Ethernet RIO et des cartes NI- 9217.
UNE ArchITEcTUrE MATérIELLE cLASSIqUE,
UN LOgIcIEL évOLUTIf
L’architecture est très classique. Des sondes sont placées dans
les enceintes et reliées à des conditionneurs Cansas. Le réseau
Enceintes thermiques
CAN permet de multiplexer les données et de relier les enceintes
de façon évolutive. Les températures sont transmises au PC via
le réseau CAN.
Le choix de la programmation orientée objet avec LabVIEW
s’est imposé tout naturellement pour le développement de cette
application. Chaque enceinte représente un objet auquel on a
a° ecté des propriétés et des méthodes. Cette méthodologie de
programmation permet de gérer plus facilement la diversité du
parc des enceintes. En e° et, les méthodes peuvent varier et des
propriétés peuvent être ajoutées en fonction du type d’enceinte.
La programmation orientée objet permet également d’avoir
une application très évolutive, nécessitant peu de modiÿcations
dans l’architecture principale du programme si l’on veut
ajouter des fonctionnalités aux objets « enceintes », comme
l’ajout de la surveillance de l’humidité dans les enceintes ou
de la fonction de pilotage.
dérOULEMENT dU TEST dE vérIfIcATION
Avant chaque essai de pièce, un test de vériÿcation peut être
réalisé pour vériÿer les caractéristiques de l’enceinte, comme
la température de consigne, la tolérance, le temps de stabilisation,
le temps de mesure… On déÿnit un cycle de mesure et
selon les résultats obtenus, des ajustements de consignes (gain,
o° set) sont réalisés pour que l’enceinte réponde aux exigences
de l’essai ÿnal. Des mesures de température sont e° ectuées régulièrement
(toutes les trente secondes) aÿn de garder un historique.
Cet autocontrôle garantit la qualité des tests et évite une
dérive en température des enceintes qui peut rendre des tests
non conformes aux spéciÿcations. Pour coller encore plus à la
réalité, les sondes PT100 sont placées directement au contact
« Chaque enceinte représente un objet auquel
on a affecté des propriétés et des méthodes.
Cette méthodologie de programmation permet
de gérer plus facilement la diversité du parc
des enceintes. » – Josselin Feld (Ineva)
36 IESSAIS & SIMULATIONS N°124 Mars-Avril 2016