Logiciel de Tests des Bancs de puissances Antennes (Ligne de Produits Antennes) THALES ALENIA SPACE Toulouse

Transcription

1 Logiciel de Tests des Bancs de puissances Antennes (Ligne de Produits Antennes) THALES ALENIA SPACE Toulouse Julien DELAUNAY Responsable Projets, ARCALE Thomas GRABIE, Jérome SINIGAGLIA Responsables Projets, THALES ALENIA SPACE

2 Moyens de Test Antennes - Ligne de Produits Antennes (TAS) Présentation Équipe de 25 personnes 7 Bases de Mesures Antennes (2 Bases longues, 2 champs proches, 3 chambres sourdes) 7 moyens de tests de puissance

3 Historique du Logiciel PIMP 1999 : Début en CVI 5 Besoin Initial : 2 porteuses, 1 PowerMeter, 1 Analyseur de Spectre. séquenceur 2011 : CVI 9 Besoin : 20 porteuses, +de 40 instruments pilotés. 3 Threads : séquenceur, surveillance mesures avec gestion des alarmes, affichage continu des données.

4 Présentation du Besoin Objectifs Tester en puissance les équipements Modèles de Vol, en environnement spatial simulé Appliquer un signal RF forte puissance dans un dispositif sous test (DUT) Observer le comportement thermique de ce DUT Préserver l intégrité des DUT selon des seuils d alarme

5 Présentation du Besoin Les moyens matériels 7 moyens de tests complets Etuve / Enceinte thermique (+/- 150 C sous 10-6 mbar) Banc RF de Forte Puissance (Jusqu à 5KWatts) Fréquence jusqu à 20GHz Divers appareils de mesures Environ une dizaine de familles (Synthétiseurs, Analyseur de spectre, AWG, milliwattmètre, sondes, ) Plusieurs appareils distincts par famille (Marque, référence, )

6 Les moyens de test Test de Produits d intermodulation Etude phénomènes RF Test en environnement spatial 17 porteuses RF en bande Ku

7 Présentation du Besoin Les contraintes Appliquer un signal RF forte puissance dans un DUT Jusqu à 30 porteuses possibles. Gérer l obsolescence et l accroissement des appareils et équipements. Une trentaine d appareils toutes familles confondues. Jusqu à 80 simultanément en cours d essai. Sécurisation des équipements MV Fiabilisation des tests et des données sauvegardées

8 Résumé du Besoin Les aspects importants du logiciel Facilité de prise en main (multi-utilisateurs) Interchangeabilité des équipements Evolutif (maj des appareils de mesures et équipements) Fiabilité (tests forte puissance donc à risque pour les MV) Sécurité des équipements Sauvegarde des données fiabilisée

9 La solution logicielle Le choix technique Utilisation des classes et de la programmation orientée objet sous LabVIEW Créer une application basée sur l architecture d une HAL spécifique Hardware Abstraction Layer

10 Les avantages Gestion de l obsolescence Ajout de futurs équipements sans modifier le code source de l application principale. Dissocier complètement : la partie logicielle (les tests) des moyens de mesure (les instruments)

11 Le Logiciel : Présentation Développé sous LabVIEW Doit être unique et configurable Exécutable sur différents moyens (bancs de test) En fonction du moyen sur lequel il est installé Types de test spécifiques Fonctionnalités accessibles ou non La modularité du logiciel se fait au travers de fichiers de configuration lors de l installation sur le moyen concerné.

12 Le Logiciel : Synoptique Menu principal PIM Login Essai Tâche Acquisition Tâche Séquenceur Tâche Visualisation Configuration Etuves Injections Télémesures Mesures Sécurités AWG Centrales Voies Etalonnage Rx Tx Séquenceur Edition Création de séquences de tests

13 Le Logiciel : Synoptique suite Acquisition Exécution Suivi Mode Edition Mode Graphique Télécommandes Graphes automatiques Thermocouples Pressions Visualisations Tensions Resistances TOS Télémesures Graphes manuels Graph Spécifique 1 Graph Spécifique N Exploitation des essais Exportation Visualisation Erreurs

14 Le Logiciel : Menu et interfaces Logo Société

15 Le logiciel : Interfaçage avec les équipements Pour réaliser les fonctions principales du logiciel PIM, l application doit s interfacer avec un ensemble d équipements de différentes familles : 7 enceintes vides thermiques 4 synthétiseurs 1 générateur de fonctions arbitraires 4 milli-wattmètres 4 sondes milli-wattmètres 5 coupleurs étalons 5 analyseurs de spectres 3 centrales d'acquisition de données + Equipements futurs

16 L architecture HAL : Principe La HAL est constituée de deux couches logicielles : L ASL (Application Separation Layer) Appelée par l application principale La DSSP (Device-Specific Software Plug-in) Appelée par l ASL

17 L architecture HAL : Synoptique Application PIM ASL Consigne étuve Régler puissance Mesurer TOS HAL DSSP Plug-in spécifique Eurtoherm Plug-in spécifique Synthétiseur 1 Plug-in spécifique Milliwattmètre 1 Driver d'instruments Driver RS 485 Eurotherm Driver IVI Synthétiseur 1 Driver VISA Milliwattmètre 1 Instruments Eurotherm Synthétiseur 1 Milliwattmètre 1

18 L architecture HAL : ASL Appelée par l application principale Ne présente pas les détails de l instrument mis en œuvre Fournit les fonctions de l application qui correspondent exactement aux actions proposées pour la mise en œuvre des séquences de tests. Une séquence est constitué d un ensemble d actions L ASL représente ses actions

19 L architecture HAL : ASL et ses actions Liste non exhaustive des actions regroupées par catégorie Température Consigne étuve Rampe Palier Mesures PIM TOS ASA Réglages Puissance Source RF : Niveau Source RF : Fréquence et Phase Divers Temporisation Envoie script (mnémonique appareil) Copie d écran

20 L architecture HAL : DSSP La DSSP (Device-Specific Software Plug-in) Appelée par l ASL Fournit l interface spécifique des différents instruments Intègre et utilise les drivers d instruments existants Classiques : IVI, VISA (liaison RS, GPIB, USB, Ethernet) Permet l interchangeabilité du matériel Gérée par des fichiers de configuration matériel Développée avec la programmation orientée objet (GOOP) offerte par LabVIEW Principe de classes et d héritages.

21 HAL : DSSP : Hiérarchie des classes Niveau 1 DSSP Classe parent Driver générique Définie par : Sa définition de type (Cluster représentant son type et ses data) Ses méthodes (jeu de fonctions génériques et communes)

22 HAL : DSSP : Hiérarchie des classes Niveau 2 Classe enfant Driver spécifique à la famille Définie par : Sa définition de type (Cluster représentant son type et ses data) Ses méthodes (jeu de fonctions spécifiques à la famille) Niveau 3, Sous Classe Driver spécifique à l instrument

23 HAL : Implémentation dans l environnement LabVIEW

24 HAL : Implémentation dans l environnement LabVIEW

25 Application finale : l exécutable PIM.exe Modules Code ASL DSSP Classes : Application figée et validée Driver générique Driver spécifique à la famille d instrument Arborescence fichiers Autres classes

26 Application finale : Evolution et ajout de nouveaux instruments Création d un nouveau driver d instrument d une famille déjà existante. Création d une source de distribution sous forme d une LLB dans le répertoire de la famille concernée Marque_Modele.llb contient : La sous classe de ce driver héritée de la classe de la famille d instrument (classe mère). Les jeux de fonctions hérités directement de la classe mère mais surchargés («overridés»). Les fonctions et sous fonctions spécifiques au driver fournies par le constructeur ou développées en interne.

27 Application finale : Evolution et ajout de nouveaux instruments Ajout de ce nouvel instrument dans l application [SPIRALE1] Media=RS232 PathClass = ETUVE\Spirale1.llb\Spirale1.lvclass [SPIRALE2] Media=RS232 PathClass = ETUVE\Spirale2.llb\Spirale2.lvclass [Eurotherm_2704] Media=GPIB PathClass = ETUVE\Eurotherm XXXX.llb\Eurotherm XXXX.lvclass [Eurotherm_35XX] Media=USB PathClass = ETUVE\Eurotherm 35XX.llb\Eurotherm 35XX.lvclass

28 CONCLUSION & QUESTIONS?