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 certif...
JANVIER 2015 : CRÉATION DE QMT GROUP
Architecture plug-in avec LabVIEW
L’expert en acquisition et traitement de signaux po...
QUELS DOMAINES
Architecture plug-in avec LabVIEW
Système distribué,
Client-Serveur, Plug-
ins…
Applications sur mesure
Exp...
DES COMPÉTENCES
Architecture plug-in avec LabVIEW
Système distribué,
Client-Serveur, Plug-
ins…
Acquisition et
traitement ...
INTRODUCTION
> Dans quels cas mettre en place une architecture plug-in ?
> Prérequis : quelques rappels sur la programmati...
QU’EST-CE QU’UNE ARCHITECTURE PLUG-IN ?
> Module d'extension qui complète un logiciel hôte pour lui apporter de
nouvelles ...
LE CHOIX D’UNE ARCHITECTURE PLUG-IN
> Modification/Ajout de fonctionnalités, sans recompiler l’ensemble du code
> Ouvertur...
PRÉ-REQUIS : OOP
> Une classe est un ensemble de propriétés (données) et de méthodes
(fonctions) qui interagissent sur ces...
PRÉ-REQUIS : HÉRITAGE
> Utilisation de la programmation objet pour bénéficier de l’héritage
> Les enfants héritent des mét...
PRÉ-REQUIS : REDÉFINITION
> Redéfinition : Capacité de modifier le comportement d’une méthode parente
Architecture plug-in...
EXEMPLE D’HÉRITAGE
Architecture plug-ins avec LabVIEW
Ancêtres
Descendants
Instrument
Multimètre
AG 34401 AG 34970
Multipl...
PRÉ-REQUIS : DISPATCH DYNAMIQUE
> Dispatch dynamique :
> LabVIEW décide lors de l’exécution quelle fonction appeler
> Le c...
PLUG-INS : LE PRINCIPE
> Classe mère = INTERFACE = lien entre l’application et les plug-ins
> Classes filles = PLUG-INS
> ...
CHARGEMENT DYNAMIQUE DES PLUG-INS
Architecture plug-in avec LabVIEW
Plug-in générique
Répertoire de stockage des
Plug-ins ...
PLUG-INS : DÉMO 1
> Exemple :
> Utilisation de l’interface (classe mère)
> Chargement dynamique des plug-ins (classes fill...
PLUG-INS : PROBLÉMATIQUE DES DÉPENDANCES
> Problématique : Une fois construite, l’application ne connait pas à l’avance
le...
DEMO : HARDWARE ABSTRACTION LAYER (HAL)
> Démo :
> création d’une interface « Instrument » et de plug-ins à partir d’une
«...
EXEMPLE : METROLAB
> Contexte : Pilotage d’un banc d’étalonnage pour capteurs de température et
pression
> Client : EDF-DT...
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 »...
METROLAB : PLUG-IN INSTRUMENTS
> Exemple : configuration d’un multimètre sur le banc de température
Architecture plug-in a...
METROLAB : PLUG-IN INSTRUMENTS
> Avantages :
Pour le client :
> Facilité pour ajouter/modifier/supprimer des instruments
>...
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
(...
METROLAB : PLUG-IN BANCS
> Avantages :
Pour le client :
> Possibilité de personnaliser l’installation de l’application sel...
METROLAB : INSTALLEUR
> L’installation des plug-ins doit être indépendante de l’installation du noyau
> Soit créer plusieu...
INSTALLEUR : INNO SETUP
> Possibilité de sélectionner les plug-ins à installer
> Possibilité de créer des configurations t...
RETOUR D’EXPÉRIENCE
> Temps de développement :
> Gain pour toutes les fonctionnalités communes entre les plug-ins
> Attent...
Par Mathilde VINCENT et Sylvain JOURDAN
mathilde.vincent@saphir.fr
sylvain.jourdan@saphir.fr
Stand NIDays numéro 28
Prochain SlideShare
Chargement dans…5
×

Architecture Plug-in en LabVIEW : de la conception à la réalisation

1 504 vues

Publié le

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.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 504
Sur SlideShare
0
Issues des intégrations
0
Intégrations
585
Actions
Partages
0
Téléchargements
18
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Présentation
    Mathilde -> CLA
    Sylvain -> CLD

    Présenter SAPHIR…

  • Aperçu des compétences de SAPHIR
  • Architecture plugin => extension d’un noyau de base

    Qu’est-ce qu’une architecture plug-in ? (exemples concrets : ex : google chrome)
    Dans quels cas mettre en place une architecture plug-in ?
    Pré-requis : rappels (OOP, héritage, dispatch dynamique)

    Qu’est-ce qu’une packed library ?
    Comment créer un plug-in ?
    Hardware abstraction Layer (HAL)
    Exemple concret : Métrolab
    Installeur : InnoDB
    Retour d’expérience


  • Une problématique sui revient souvent : le gestion d’instruments
    Dans la suite, nous prendrons cet exemple, le but est de créer une architecture plug’in pour les instruments afin d’avoir une couche d’abstraction matérielle


    Application stable qui doit évoluer (limitation de l’impact de modifications)
    Architecture permettant de définir une interface figée avec certains modules (permet de cadrer le développement)
    Installation personnalisée selon les utilisateurs, les bancs, …

    Attention : le choix doit être justifié !

    Ouverture du développement de modules à d’autres développeurs : + Protection du noyau de l’application

    Qualité : factorisation du code  développé et testé une seule fois
  • Demander :
    Qui développe en objet ou connait la POO en LV ?

  • Rajout de propriétés et méthodes aux classes filles

  • Redéfinition de méthodes
  • Wahou!!!! : 3 fils différents buildé dans le même tableau

    Chargement dynamique des classes filles


    Contrainte de redéfinition : Bien pour cadrer le développement des plugins
  • Basé sur une programmation orientée objet avec héritage : Différentes façons d’implémenter des plugins : choix de l’OOP
  • Les VI publics d’une librairie compilée en packed library peuvent être appelés depuis un code source LabVIEW


    TODO LV2014

    (Attention Dépendances classe mère en LV < 2014 => Obligation de builder la classe mère en LVLIBP)

  • Attention : une packed library est compilée pour une version de LV

    Hal : Separate test application from the instrument hardware


  • Principe d’un étalonnage :
    1 sonde de température de référence (étalon) et N sondes à étalonner
    Toutes les sondes sont trempées dans un bain ou un four, avec un générateur de température + régulateur
    Le logiciel pilote des paliers de température et effectue des mesures via un multimètre et un multiplexeur sur l’ensemble des sondes.
    Le but étant de qualifier chacune des sondes à étalonner par rapport à la sonde étalon et de « classifier » ces sondes

    Idem en pression avec soit un étalonnage manuelle (balance avec des masses) soit un étalonnage automatique (le logiciel pilote un générateur de presssion)


    Expliquer étalonnage :
    Exemple en température : Profil de température (« paliers »), et à chaque palier de température comparaison par rapport à un sonde étalon
    Calculs de caractéristiques pour chaque sonde, classe de la sonde, incertitude
    Interface de mesure du banc de température + image rapport (données simulées)



    COFRAC : Comité Français d’Accréditation
    Le Comité français d’accréditation (Cofrac) est l'unique instance chargée de délivrer les accréditations aux organismes intervenant dans l'évaluation de la conformité en France.
    Les accréditations sont gérées par des sections spécialisées :
    La section "Laboratoires" assure l'accréditation pour les étalonnages en métrologie


    Gestion de processus d’étalonnage :
    - Traçabilité
    - Calculs d’incertitude
    - Répétabilité
    - Contraintes COFRAC

  • Facilité pour ajouter/modifier/supprimer des instruments : évolutivité
  • Interface : fait partie du noyau, qui est buildé en exe

    Plugins : chargé dynamiquement au moment de l’exécution

    HAL : couche d’abstraction matérielle
  • Nombreux points communs entre les différents bancs
  • Possibilité d’installer 1 ou plusieurs bancs : typiquement 1 banc sur chaque PC relié à une installation (température, pression manuelle ou pression automatique) + 1 PC spare avec tous les bancs

    Transition : Contrainte : fournir un installeur adapté à l’architecture plugin
    Pas facile avec l’installeur de base LabVIEW

     Inno Setup
  • Inno Setup :
    installeur plus évolué que celui proposé par National Instruments
  • Attention : architecture plug’in à mettre en place seulement si le besoin est réel car surcout engendré par la mise en place d’une architecture plug-in (architecture complexe)

    Gain de développement pour toutes les fonctionnalités communes entre les plug-ins
    Attention au surcout engendré par la mise en place d’une Architecture plug-in : bien évaluer si ce besoin est nécessaire par rapport au temps gagné par le non développement de fonctionnalités communes
    Architecture
    Développement
    Debug
    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 LV permettant d’appeler la classe LV plug-in lors d’un appel en sources et la packed library lors d’un appel en exe
    Architecture très structurée : facilité pour le travail en équipe, pour la maintenabilité, l’évolutivité
  • Architecture Plug-in en LabVIEW : de la conception à la réalisation

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. METROLAB : PRINCIPE DE L’ÉTALONNAGE Architecture plug-in avec LabVIEW Etalonnage en température :
    21. 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. 22. METROLAB : PLUG-IN INSTRUMENTS > Exemple : configuration d’un multimètre sur le banc de température Architecture plug-in avec LabVIEW
    23. 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. 24. METROLAB : PLUG-IN INSTRUMENTS > Architecture : Architecture plug-in avec LabVIEW
    25. 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. 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. 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. 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. 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. 30. Par Mathilde VINCENT et Sylvain JOURDAN mathilde.vincent@saphir.fr sylvain.jourdan@saphir.fr Stand NIDays numéro 28

    ×