Cette présentation explique la manière de mettre en oeuvre une architecture plug-in en LabVIEW. Basée sur la programmation Orientée Objet et l'utilisation de "Packed Libraries", la solution est décrite et commentée pour mettre en avant les points clés. Un exemple concret démontre son utilisation dans la vie réelle et permet de faire un retour d'expérience important.

1. D U C O N C E P T À L A R É A L I S A T I O N
ARCHITECTURE PLUG-IN AVEC
LABVIEW :
NIDays/ Paris / 03 Février 2015

2. SAPHIR
Architecture plug-in avec LabVIEW
Création en 1989
• 25 ans
• Partenaire Gold
21 personnes
• 15 développeurs certifiés
• + de 80% de l’équipe a plus de 3 ans d’ancienneté
En France
• Entre Chambéry et Grenoble

3. JANVIER 2015 : CRÉATION DE QMT GROUP
Architecture plug-in avec LabVIEW
L’expert en acquisition et traitement de signaux pour la
mesure, le test et le contrôle qualité

4. QUELS DOMAINES
Architecture plug-in avec LabVIEW
Système distribué,
Client-Serveur, Plug-
ins…
Applications sur mesure
Expertise / Accompagnement
Formations
Toolkits LabVIEW et application
88 %
du CA
2%
du CA
10%
du CA

5. DES COMPÉTENCES
Architecture plug-in avec LabVIEW
Système distribué,
Client-Serveur, Plug-
ins…
Acquisition et
traitement de
signaux
Pilotage de banc
de test,
supervision
Contrôle qualité en
chaine de
production
Systèmes
embarqués, Client-
Serveur…

6. INTRODUCTION
> Dans quels cas mettre en place une architecture plug-in ?
> Prérequis : quelques rappels sur la programmation objet
> Comment créer un plug-in ?
> Exemple concret : Métrolab
Architecture plug-in avec LabVIEW

7. QU’EST-CE QU’UNE ARCHITECTURE PLUG-IN ?
> Module d'extension qui complète un logiciel hôte pour lui apporter de
nouvelles fonctionnalités.
> Exemples : Google Chrome, Mozilla Firefox, Notepad++, LabVIEW…
Architecture plug-in avec LabVIEW

8. LE CHOIX D’UNE ARCHITECTURE PLUG-IN
> Modification/Ajout de fonctionnalités, sans recompiler l’ensemble du code
> Ouverture du développement de modules à d’autres développeurs
> Installation personnalisée
 Permet d’améliorer l’évolutivité, la maintenabilité et la qualité d’une
application
Architecture plug-in avec LabVIEW

9. PRÉ-REQUIS : OOP
> Une classe est un ensemble de propriétés (données) et de méthodes
(fonctions) qui interagissent sur ces données
> Un objet est une instance spécifique d’une classe
Architecture plug-ins avec LabVIEW
Classe Instrument
Propriétés
Identifiant
Numéro de série
Dernière valeur lue
Méthodes
Initialiser
Ecrire
Lire
Libérer
Objet 1
• AG34401
• B254255
• 1.4 V
Objet 2
• DPG 10
• DH1389B
• 1.1 bar
Objet 3
• CPC 6000
• PN001MENS
• 1088 Pa

10. PRÉ-REQUIS : HÉRITAGE
> Utilisation de la programmation objet pour bénéficier de l’héritage
> Les enfants héritent des méthodes et des propriétés du parent
> Les enfants peuvent ajouter des méthodes et des propriétés
Architecture plug-ins avec LabVIEW
Enfants
Parent Multimètre
AG 34401 AG 34970

11. PRÉ-REQUIS : REDÉFINITION
> Redéfinition : Capacité de modifier le comportement d’une méthode parente
Architecture plug-ins avec LabVIEW
Enfants
Parent Multimètre
AG 34401 AG 34970

12. EXEMPLE D’HÉRITAGE
Architecture plug-ins avec LabVIEW
Ancêtres
Descendants
Instrument
Multimètre
AG 34401 AG 34970
Multiplexeur
Keithley7002 AG 3499B

13. PRÉ-REQUIS : DISPATCH DYNAMIQUE
> Dispatch dynamique :
> LabVIEW décide lors de l’exécution quelle fonction appeler
> Le choix est dicté par le type de l’objet
> Possibilité de contraindre une classe fille à redéfinir une fonction
Architecture plug-ins avec LabVIEW
1.5V
2.34V
-0.8V

14. PLUG-INS : LE PRINCIPE
> Classe mère = INTERFACE = lien entre l’application et les plug-ins
> Classes filles = PLUG-INS
> Les classes filles redéfinissent les méthodes « interface » de leur mère
> Les classes filles sont chargées dynamiquement
> Le « dispatch dynamique » définit la méthode qui doit être appelée au
moment de l’exécution
Architecture plug-ins avec LabVIEW

15. CHARGEMENT DYNAMIQUE DES PLUG-INS
Architecture plug-in avec LabVIEW
Plug-in générique
Répertoire de stockage des
Plug-ins sur le disque
Objets chargés en mémoire
 Parent (Interface)
 Enfants ( Plug-ins)

16. PLUG-INS : DÉMO 1
> Exemple :
> Utilisation de l’interface (classe mère)
> Chargement dynamique des plug-ins (classes filles)
> Génération d’un exécutable
Architecture plug-in avec LabVIEW

17. PLUG-INS : PROBLÉMATIQUE DES DÉPENDANCES
> Problématique : Une fois construite, l’application ne connait pas à l’avance
les plug-ins à charger. Les plug-ins doivent donc contenir l’ensemble des
ressources nécessaires à leur exécution.
> Solution : distribuer les plug-ins sous forme de packed library (*.lvlibp)
> Packed library = code compilé (*.lvlibp) construit à partir d’une librairie
(*.lvlib), et contenant toutes ses dépendances
Architecture plug-in avec LabVIEW

18. DEMO : HARDWARE ABSTRACTION LAYER (HAL)
> Démo :
> création d’une interface « Instrument » et de plug-ins à partir d’une
« packed library »
Architecture plug-in avec LabVIEW

19. EXEMPLE : METROLAB
> Contexte : Pilotage d’un banc d’étalonnage pour capteurs de température et
pression
> Client : EDF-DTG, laboratoire MPSH (accrédité COFRAC)
> Application : Etalonnage des capteurs de pression et température des
centrales nucléaires
Architecture plug-in avec LabVIEW

20. METROLAB : PRINCIPE DE L’ÉTALONNAGE
Architecture plug-in avec LabVIEW
Etalonnage en température :

21. METROLAB : PLUG-IN INSTRUMENTS
> Contrainte numéro 1 :
> Evolutivité au niveau du matériel (ajout d’instruments « facile »)
> Installation personnalisée des instruments
« <L’application> devra se présenter sous forme modulaire,
permettant une installation partielle ou complète des fonctionnalités
demandées et surtout permettant une grande évolutivité, pour
l’intégration simplifiée de futurs équipements »
Architecture plug-in avec LabVIEW

22. METROLAB : PLUG-IN INSTRUMENTS
> Exemple : configuration d’un multimètre sur le banc de température
Architecture plug-in avec LabVIEW

23. METROLAB : PLUG-IN INSTRUMENTS
> Avantages :
Pour le client :
> Facilité pour ajouter/modifier/supprimer des instruments
> Installation personnalisée des instruments selon les bancs
Pour le développeur :
> Plug-in de simulation pour tests d’intégration sans matériel, pour chaque
instrument
Architecture plug-in avec LabVIEW

24. METROLAB : PLUG-IN INSTRUMENTS
> Architecture :
Architecture plug-in avec LabVIEW

25. METROLAB : PLUG-IN BANCS
> Contrainte numéro 2:
> Une application commune pour s’interfacer avec tous les types de bancs
(banc de température, banc de pression manuel, banc de pression
automatique)
> Possibilité d’installer seulement l’un ou plusieurs des bancs
Architecture plug-in avec LabVIEW

26. METROLAB : PLUG-IN BANCS
> Avantages :
Pour le client :
> Possibilité de personnaliser l’installation de l’application selon les besoins
(installation de un ou plusieurs bancs sur le même PC)
Pour le développeur :
> Code commun pour toutes les fonctionnalités communes entre les bancs
 gain en temps de développement et test
Architecture plug-in avec LabVIEW

27. METROLAB : INSTALLEUR
> L’installation des plug-ins doit être indépendante de l’installation du noyau
> Soit créer plusieurs installeurs avec LabVIEW
> Soit utiliser InnoSetup pour proposer un installeur plus évolué
Architecture plug-in avec LabVIEW

28. INSTALLEUR : INNO SETUP
> Possibilité de sélectionner les plug-ins à installer
> Possibilité de créer des configurations types d’installation
> Possibilité d’installer d’autres composants
> Multiples possibilités de personnalisation
Architecture plug-in avec LabVIEW

29. RETOUR D’EXPÉRIENCE
> Temps de développement :
> Gain pour toutes les fonctionnalités communes entre les plug-ins
> Attention au surcout engendré par la mise en place d’une Architecture
plug-in
> Attention aux dépendances (LV2012 en particulier, mais beaucoup
d’évolutions en LV2013 et LV2014 pour mieux gérer les dépendances)
> Pour faciliter le debug : mise en place d’un VI LabVIEW permettant
d’appeler la classe LV plug-in lors d’un appel en sources et la packed library
lors d’un appel en exécutable
> Architecture très structurée : facilité pour le travail en équipe, pour la
maintenabilité, l’évolutivité
Architecture plug-in avec LabVIEW

30. Par Mathilde VINCENT et Sylvain JOURDAN
mathilde.vincent@saphir.fr
sylvain.jourdan@saphir.fr
Stand NIDays numéro 28