Embed Size (px)
Citation preview
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
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
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é
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
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…
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
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
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
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ésIdentifiantNuméro de sérieDernière valeur lue
MéthodesInitialiserEcrireLireLibérer
Objet 1• AG34401• B254255• 1.4 V
Objet 2• DPG 10• DH1389B• 1.1 bar
Objet 3• CPC 6000• PN001MENS• 1088 Pa
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
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
EXEMPLE D’HÉRITAGE
Architecture plug-ins avec LabVIEW
Ancêtres
Descendants
Instrument
Multimètre
AG 34401 AG 34970
Multiplexeur
Keithley7002 AG 3499B
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
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
CHARGEMENT DYNAMIQUE DES PLUG-INS
Architecture plug-in avec LabVIEW
Plug-in générique
Répertoire de stockage desPlug-ins sur le disque
Objets chargés en mémoire
Parent (Interface)
Enfants ( Plug-ins)
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
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
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
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
METROLAB : PRINCIPE DE L’ÉTALONNAGE
Architecture plug-in avec LabVIEW
Etalonnage en température :
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
METROLAB : PLUG-IN INSTRUMENTS
> Exemple : configuration d’un multimètre sur le banc de température
Architecture plug-in avec LabVIEW
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
METROLAB : PLUG-IN INSTRUMENTS
> Architecture :
Architecture plug-in avec LabVIEW
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
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
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
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
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
Par Mathilde VINCENT et Sylvain JOURDAN
Stand NIDays numéro 28
