Rapport de Stage - 3ème année d`IUP ISI - Nacelles pointées

Transcription

Rapport de Stage - 3ème année d'IUP ISI
Contrôle Commande de nacelles pointées à base de technologies standards
Version 1.0
Auteur : Adrien Lafont de Sentenac
Table des Révisions
Révision
Date
Auteur(s)
1.0
07/07/2003
Adrien Lafont de Sentenac
Description
Création du document
Table des Matières
Préface...........................................................................................................................................1
Chapitre 1 : Objet, but et domaine d'application........................................................................2
1. Objet............................................................................................................................................2
2. But...............................................................................................................................................2
3. Domaine d'application.................................................................................................................2
4. Présentation du document..........................................................................................................2
Chapitre 2 : Documents et vocabulaire de base........................................................................3
1. Documents applicables...............................................................................................................3
2. Documents de référence.............................................................................................................3
3. Terminologie................................................................................................................................3
Chapitre 3 : Présentation du CNES.............................................................................................5
1. La division Ballons.......................................................................................................................5
2. Les Nacelles Pointées.................................................................................................................7
Chapitre 4 : Présentation du stage..............................................................................................9
1. Contexte initial du stage..............................................................................................................9
2. Sujet............................................................................................................................................9
3. Etude de l'existant.......................................................................................................................9
4. Choix technologiques..................................................................................................................10
5. Etude des outils existants............................................................................................................10
6. Conception..................................................................................................................................11
7. Pistes pour la réalisation.............................................................................................................16
8. Récapitulatif de l'avancé du travail..............................................................................................20
Chapitre 5 : Méthode et outils utilisés.........................................................................................22
1. Environnement............................................................................................................................22
2. Outils...........................................................................................................................................22
Chapitre 6 : Bilan...........................................................................................................................23
Chapitre 7 : Annexe.......................................................................................................................24
1. Réalisation de Widget composés aidée grâce aux concepts d'Ada et de GtkAda, exemple du
Widget d'oscilloscope......................................................................................................................24
2. DTD des fichiers XML des pages d'affichage..............................................................................25
i
Liste des Figures
3-1 : Photo de ballons stratosphériques..........................................................................................5
3-2 : Photo d'une nacelle en cours d'intégration.............................................................................6
4-1 : Vue globale du système..........................................................................................................11
4-2 : Vue en couches......................................................................................................................12
4-3 : Schéma explicatif d'une page d'affichage...............................................................................14
4-4 : Widget Oscilloscope................................................................................................................16
4-5 : Fenêtre principale du Générateur...........................................................................................17
4-6 : Fenêtre palette du Générateur................................................................................................18
4-7 : Fenêtre de propriétés du Générateur......................................................................................18
4-8 : Fenêtre principale du Centre de Contrôle (avec shéma de ce à quoi la liste des pages doit
ressembler).....................................................................................................................................19
ii
Préface
Préface
Remerciements :
Je tiens à remercier André Laurens, mon maître de stage, pour son accueil, son soutien et
l'ensemble des connaissances dont il a su me faire profiter.
Je tiens à remercier Jean Evrard pour son accueil et sa bonne humeur qui a grandement
contribué à créer des condition de travail agréable.
Je remercie Jean Audoubert pour sa participation à ma découverte du CNES et des nombreuses activités dans le monde spatial.
Enfin je remercie l'ensemble de l'équipe nacelle pour leur accueil et leur bonne humeur tout au
long de mon stage.
1
Chapitre 1 : Objet, but et domaine d'application
Chapitre 1
Objet, but et domaine d'application
1. Objet
L'objet du projet est de contribuer à la conception et la réalisation du segment sol du contrôle
commande de nacelles pointées.
2. But
L'objectif du logiciel est l'affichage et le contrôle de différentes télémesures fournies par la nacelle pointée en vol, et la saisie et l'envoi de télécommandes. Le logiciel doit pouvoir afficher les
informations selon les besoins de l'utilisateur, grâce à des pages personnalisables. Pour créer
ces pages, un générateur devra être conçu et réalisé. De plus, un outil indépendant devra être
réalisé pour convertir les fichiers binaires stockant les télémesures et télécommandes en des fichiers ASCII pour relecture ultérieure.
3. Domaine d'application
Le domaine d'application est le spatial, ce logiciel sert à controler les nacelles pointées qui ont
pour mission d'embarquer des charges utiles scientifiques.
4. Présentation du document
Le Chapitre 2 présente le vocabulaire technique ainsi que les documents utilisés au cours du
projet. Le chaptre 3 présente l'entreprise où j'ai effectué mon stage, suivi du chapitre 4 qui décrit
le travail que j'ai réalisé lors de mon stage. Le chapitre 5 présente les méthodes et outils dont je
me suis servi lors de mon stage, et pour conclure le chapitre 6 présente un bilan personnel de
mon stage.
2
Chapitre 2 : Documents et vocabulaire de base
Chapitre 2
Documents et vocabulaire de base
1. Documents applicables
Contrat : convention de stage
2. Documents de référence
- Guide utilisateur de GtkAda (version 2.0 et 2.2)
- Manuel de référence de GtkAda (version 2.0 et 2.2)
- Manuel de référence d'Ada
3. Terminologie
CNES :
Centre National d'Etudes Spatiales
Télémesure :
Données envoyées par la nacelle pointée au sol.
Télécommande :
Données envoyées du sol à la nacelle pointée.
API :
Application and Programming Interface. Interface pour la programmation d'applications, Ensemble de bibliothèques permettant une programmation plus aisée en offrant des fonctions de
haut niveau qui permettent de s'affranchir du matériel.
GTK+ :
The GIMP ToolKit, il a été développé et utilisé à l'origine pour The GIMP (GNU Image Manipulation Program, un outil de retouche d'images) d'où son nom, de nos jours c'est devenu une boite
à outils (toolkit) multi-plateforme et existant dans de nombreux langages pour réaliser des interfaces graphiques.
GtkAda :
"Binding" (liaison) de GTK+ en Ada
Widget :
Contraction de Window gadget (gadget de fenêtre), c'est un élément d'une interface graphique
(tel un bouton, un menu...).
XML :
eXtensible Markup Language, il s'agit d'un langage de définition de données.
DTD :
Document Type Declaration, Déclaration d'un type de document en XML.
3
Chapitre 2 : Documents et vocabulaire de base
4
Chapitre 3 : Présentation du CNES
Chapitre 3
Présentation du CNES
1. La division Ballons
La division Ballons du CNES est constituée : du département Véhicules, qui conçoit les ballons,
du département Nacelles qui développe des nacelles scientifiques, des systèmes de conduite
du vol et de télécommunication pour les systèmes aérostatiques, et du département Opérations
qui a en charge les lancements. L'activité Nacelles Pointées est intégrée au département Nacelles.
Une nacelle est un véhicule d'emport d'expériences scientifiques sous ballons stratosphériques.
La particularité de ce type de nacelles est la présence d'un système de pointage destiné à
orienter et maintenir la charge utile (l'instrument scientifique) dans une direction bien précise.
Figure 3-1: Photo de ballons stratosphériques
Les domaines scientifiques intéressés par les vols stratosphériques sont nombreux, car le ballon est un véhicule peu coûteux qui permet à une expérience de s'affranchir de l'essentiel de
5
l'atmosphère, donc des inconvénients qui y sont souvent liés comme l'atténuation du signal
scientifique et l'émissivité parasite. Néanmoins, les clients des nacelles pointées appartiennent
essentiellement à deux domaines :
- les instruments d'observation astronomique ou astrophysique. Le rôle du système de pointage sera de diriger ces instruments dans la direction des objets astronomiques souhaités,
et ce avec la précision et la stabilité requises. Il peut y avoir plusieurs objets à observer au
cours d'un même vol.
- les expériences de chimie atmosphérique ont pour but essentiel d'identifier les espèces
chimiques qui composent l'atmosphère, et d'en déterminer les concentrations en fonction
de l'altitude. Une des méthodes de mesure les plus fréquentes est la spectrométrie par occultation : en visant un astre (typiquement, le soleil qui traverse les différentes couches de
l'atmosphère) du zénith jusqu'à son coucher, on verra le spectre du soleil se modifier en
fonction de la "quantité" d'atmosphère traversée, donc des espèces rencontrées et de leur
concentration. Dans ce cas, le rôle du système de pointage sera d'orienter et maintenir la
charge utile dans la direction de l'astre en question.
Quelle que soit la nature de la mission, la nacelle transporte :
- des équipements de mesure et de traitement scientifique (instrument scientifique)
- une source d'énergie électrique : piles ou batteries
- des équipements d'acquisition et de surveillance de paramètres de servitude (capteurs de
température, gyromètres, magnétomètres, inclinomètres, etc)
- un système de localisation (GPS le plus souvent)
- un système de télécommunication avec le sol (équipements de télécommande/télémesure
ou TM/TC)
- les équipements constituants le système de pointage (capteurs et actionneurs)
6
Figure 3-2: Photo d'une nacelle en cours d'intégration
Elle embarque à son bord un ou deux calculateurs : dans tous les cas, le module de commande, logiciel (MC) qui réalise les fonctions de pointage primaire en azimut et la gestion des
servitudes : contrôle des bus d'alimentation, acquisition des mesures de température, tensions
et courants, et selon la mission, le module de pointage fin, logiciel (MPF) qui réalise les fonctions de pointage primaire en élévation et un pointage très précis.
2. Les Nacelles Pointées
L'équipe Nacelles pointées a en charge la définition, la réalisation et la mise en oeuvre des nacelles qui nécessitent un pointage solaire ou stellaire pour les besoins scientifiques des utilisateurs. C'est elle qui va analyser les besoins de la mission, évaluer sa faisabilité et mettre en
place les différents dispositifs pour assurer la meilleure intégration de l'expérience à la nacelle.
D'une mission à l'autre, les équipements sont récupérés afin de les réutiliser. Mais certains projets scientifiques peuvent nécessiter des développements spécifiques. L'ensemble relève de
façon claire d'un concept générique.
7
L'équipe réalise :
- le système de pointage
- la chaîne de contrôle commande qui comprend, entre autre, le sous-système informatique
de bord (calculateurs embarqués, bus de communication, périphériques informatiques, logiciels)
- l'intégration de l'expérience scientifique
- le test et la validation de la nacelle
- l'opération de la nacelle en vol
8
Chapitre 4 : Présentation du stage
Chapitre 4
Présentation du stage
1. Contexte initial du stage
Actuellement, André Laurens, ingénieur en informatique de l'équipe, prend en charge l'évolution
et la maintenance du logiciel de vol et du sol. Les logiciels de vol et de sol sont tous les deux
programmés en C++, mais tournent sous des environnements différents. Le premier dispose du
système d'exploitation VxWorks et le second de Windows 98.
Son objectif est de faire évoluer l'architecture du système informatique afin :
- d'obtenir une application plus flexible vis-à-vis des missions (flexibilité des fonctions) et
des équipements (diversité des interfaces)
- de réduire les coûts et les délais
- de disposer d'un environnement de développement (matériel et logiciel) qui permet
d'uniformiser les technologies utilisées entre bord et sol, en s'appuyant sur des solutions
standards, puissantes, peu coûteuses et pérennes
2. Sujet
L'intitulé du stage est : "Contrôle Commande de nacelles pointées à base de technologies standards". L'objectif du stage est de rechercher et maquetter des solutions d'IHM pour le segment
sol du logiciel de Contrôle Commande des nacelles pointées. Le segment sol est chargée
d'afficher et de contrôler les télémesures envoyées par la nacelle pointée et de saisir et envoyer
des télécommandes à la nacelle pointée. Ces échanges entre le sol et la nacelle ont besoin
d'être archivés dans des fichiers pour étude ultérieure.
Cela a entrainé la nécessité d'avoir trois applications "indépendantes".
* Un générateur de pages qui permet à l'utilisateur de créer des pages d'affichages ponrédant à ses besoins, c'est à dire n'affichant que les télémesures et les télécommandes
dont il a besoin.
* L'application principale qui utilise les pages générées par le générateur pour afficher à
l'utilisateur les données échangées avec la nacelle pointée et qui stocke les télémesures
dans un fichier binaire.
* Un outil de dépouillement qui permet de convertir les fichiers binaires de stockage en fichiers ASCII par mesure.
3. Etude de l'existant
Jusqu'à présent, les plateformes bord et sol étaient différentes. La plateforme sol fonctionnait
sur Windows et la plateforme bord sur VxWorks. La volonté présente est d'uniformiser les plateformes bord et sol pour les faire fonctionner toutes deux sur GNU/Linux.
La solution d'un GNU/Linux offre trois avantages. Tout d'abord, étant gratuit, il permet une coénomie non négligeable par rapport à VxWorks. De plus, étant soutenu par une vaste commu9
nauté, il garantit une certaine pérennité des outils de développement. Pour finir il permet la
création de composants logiciels communs au bord et au sol puisqu'ils bénéficient de la même
plateforme.
De plus, André Laurens a mis à ma disposition les sources du Centre de Contrôle
Nacelle-Télescope de PRONAOS, un de ses projets précédents, écrit en Ada83 et qui m'a permis d'étudier la façons dont les télémesures et les télécommandes étaient décrites.
4. Choix technologiques
Dans un soucis de portabilité et de maintenabilité, les choix de langages se sont portés sur
Ada95 et GtkAda pour l'interface graphique.
En effet, Ada lui même est parfaitement portable sur simple recompilation d'un système
d'exploitation à l'autre : grâce à sa normalisation, on sait qu'un programme réalisé en Ada
réagira de la même façon quelque soit le système d'exploitation sur lequel il tourne. De plus,
Ada95 offre des fonctionnalités avancées, que ce soit en terme de tasking (ou multi-tache) pour
le temps réel aussi bien que du point de vue objet.
GtkAda, quant à lui, est un binding de GTK+ pour Ada95. GTK+ est une API pour la réalisation
d'interfaces graphiques (initialement réalisée en C), il est prévu pour être portable grâce à une
réalisation en couche, fournissant à l'utilisateur de l'API des fonctions de haut niveau qui le
libère des appels systèmes. GtkAda profitant du fort typage et de l'extension objet d'Ada95, il
offre des garanties et une souplesse plus importante que la version originelle de GTK+ en C. Le
choix de GtkAda2 (basé sur GTK+2) a été fait dans un souci de confort, aussi bien pour
l'utilisateur final que pour le développement, GTK+2 ayant été nettement amélioré par rapport à
GTK+1.2
GTK+ est une API pour la création d'interfaces graphiques modernes. C'est à dire que contrairement à d'autres systèmes qui demandent à ce que les widget soient placés à une position fixe
sur la fenêtre, GTK+ encourage à placer les widget dans des zones définies mais sans position
fixe. La première chose que l'on place dans une fenêtre est un conteneur qui définit les zones
(par exemple un tableau de deux colonnes et trois lignes, qui offre donc 6 zones). Ensuite dans
ces zones on peut soit placer un widget soit placer un nouveau conteneur pour définir des sous
zones. L'avantage de ce système est qu'il permet un redimensionnement automatique de la
fenêtre, en effet les widgets étant placés les uns par rapport aux autres, changer la taille de le
fenêtre ne demande pas d'avoir à recalculer les nouvelles tailles de chaque widget ainsi que
leurs nouvelles positions. L'ordre des widgets reste le même il n'y a donc pas de risque de chevauchements.
5. Etude des outils existants
J'ai donc cherché des solutions pour le maquettage de l'IHM. Il existe un outil de création
d'interfaces graphiques en GTK+2 nommé Glade-2, il permet de réaliser de manière relativement simple des interfaces graphiques et de générer soit le code correspondant soit un fichier
XML décrivant l'interface. Malheureusement, bien que Glade (pour GTK+1.2) soit capable de
générer directement du code Ada, Glade-2 (pour GTK+2) n'en était pas capable. Ce problème a
été résolu quand la dernière version de GtkAda est parue (GtkAda 2.2.0) car elle comprenait un
outil de conversion des fichiers XML produits par Glade-2 en code Ada.
L'objectif de l'application de centre de contrôle est de permettre l'affichage de télémesures. Il a
fallu réfléchir à la manière de les présenter. Certaines télémesures sont présentables sous la
forme : "Libellé Valeur Unité" donc en utilisant des widgets standards de GtkAda, mais pour cer10
taines il était interessant de pouvoir afficher l'évolution de leur valeur dans le temps. J'ai donc
cherché s'il existait des widgets déjà réalisés qui permettraient d'afficher des valeurs sous forme
d'oscilloscope. Une des contraintes principale étant que cet affichage supporte une mise à jour
en temps réel.
Ne trouvant de widget répondant exactement à mes besoins, j'ai donc réalisé un widget personnalisé en me basant sur GtkPlot, qui est un ensemble de paquetages faisant parti des GtkExtra,
qui sont eux même fournis par GtkAda. Pour comprendre leur utilisation, je me suis appuyé sur
des exemples d'utilisation présents dans les tests de GtkAda et sur WinIO (une bibliothèque,
sous licence GPL, facilitant la réalisation de graphes fixes).
6. Conception
Le système fonctionne sur trois périodes des temps séparées. La première, le "Temps Anticipé"
se situe avant l'opération de lancement de la nacelle, c'est à ce moment là que les utilisateurs
créent leurs pages grâce au générateur de pages. Ensuite vient la période appelé "Temps
Réel", c'est durant cette période qu'est utilisé le logiciel de Contrôle Commande. Puis, pour finir,
on trouve le "Temps Différé" où l'outil de dépouillement est utilisé a postériori pour transformer
les fichiers binaires de stockages en fichiers ASCII par mesure surveillée, fichiers ASCII qui
pourront être utilisés pour analyser le vol.
Figure 4-1: Vue globale du système
J'ai donc eu à travailler dans le cadre de deux applications, le générateur de pages et le logiciel
11
de Centre de Contrôle. Ces deux applications, bien que devant se lancer séparément,
possèdent des couches communes. En effet le générateur de pages et le visualisateur partagent les mêmes définitions de widgets personnalisés, mais ont aussi besoin tous deux des
définitions des télémesures et des télécommandes.
Figure 4-2: Vue en couches
6.1. Centre de Contrôle
C'est l'application de base, elle permet à l'utilisateur de lancer et d'arrêter l'acquisition des
télémesures provenant de la nacelle, elle permet aussi de visionner les télémesures et de saisir
et d'envoyer les télécommandes. L'application affiche un ensemble de pages qui sont choisies
par l'utilisateur. Ces pages sont créées par le générateur de pages pour que l'utilisateur ait à
12
cran les données qui l'interessent.
La structure globale de l'application suit une structure du type MVC (Modèle Vue Contrôleur)
pour permettre le découpage de l'application entre d'une part les données et leur définition, qui
seront globales aux différentes applications, et l'interface spécifique et paramêtrable.
L'application est constituée de quatre couches :
6.1.1. La couche Interface
C'est la couche avec laquelle l'utilisateur interagit. Elle a comme premier but de permettre le
lancement et l'arrêt de l'acquisition de données. Elle permet ensuite de sélectionner les pages
que l'utilisateur souhaite voir afficher, et une fois ces pages sélectionnées, elle affiche les
données et permet à l'utilisateur de saisir les télécommandes à envoyer à la nacelle.
6.1.2. La couche Application
Cette couche est divisée en trois parties principales qui sont liées au fonctionnement de
l'application.
1. Acquisition et Traitement :
C'est la partie centrale de l'application, elle est chargée de recevoir les télémesures, de
leur appliquer des traitements éventuels, d'en calculer les pseudo-mesures et
d'acheminer ces données au reste de l'application.
Pour traiter une télémesure reçue, cette couche fait appel à la couche Domaine qui
possède les définitions des télémesures ainsi que celles de leurs traitements.
2. Chargement des Pages :
Cette partie a pour rôle de lire les fichiers créés par le générateur de pages pour reconstituer la page voulue. En plus de créer dynamiquement les widgets correspondants, elle
doit automatiquement les rattacher aux données souhaitées.
3. Stockage :
Cette partie est relativement indépendante du reste de l'application, elle reçoit les
données de manière asynchrone et à pour mission de les stocker dans un fichier binaire.
6.1.3. La couche Domaine
Cette couche concerne la partie métier de l'application, elle définit les télémesures, leurs traitements et pseudo mesures éventuelles ainsi que les télécommandes.
1. Description des télémesures et télécommandes :
Sur cette partie les avantages d'Ada95 se sont fait fortement sentir. Le fait qu'Ada95 soit
orienté objet notamment a beaucoup aidé. En effet, toutes les télémesures (et il en va de
même pour les télécommandes) ont une base commune qui privilégie la réalisation d'un
objet parent dont toutes les télémesures (respectivement pour les télécommandes)
héritent. Par contre, la liaison série entre le sol et la nacelle pointée impose des clauses
de représentation sur l'ensemble des télémesures et empêche de ce fait l'utilisation de
types étiquetés car il n'est pas possible de réaliser une clause de représentation sur til'équette. Il est donc nécessaire de créer un type avec discriminant pour les télémesures
et les télécommandes, et des fonctions de transfert depuis ce type à discriminant vers le
type étiqueté de la télémesure ou de la télécommande correspondante au discriminant
en question.
2. Définition des traitements :
13
Cette partie définit les différents traitements et calculs de pseudo-mesures réalisables
sur les différentes télémesures et les calculs de télécommandes.
6.1.4. La couche Infrastructure
Cette couche est commune avec le générateur de pages, elle définit les différents widgets personnalisés qui serviront à afficher les télémesures. La plupart des widgets personnalisés sont
de la forme libellé d'intitulé, champ de valeur et libellé d'unité, mais il a aussi fallu réaliser un
widget d'oscilloscope pour permettre d'afficher des valeurs sous forme de courbe en temps réel.
6.2. Générateur de pages
Le générateur de pages permet à l'utilisateur de créer les pages d'affichages qu'il voudra avoir
dans le visualisateur. L'application se présente sur le même modèle que Glade (le générateur
d'interfaces graphiques en GTK+). Au démarrage, l'utilisateur est face à la fenêtre principale qui
lui permet de gérer la page d'affichage (la créer, la sauver...), d'une fenêtre listant tous les widgets disponibles et d'une fenêtre permettant d'éditer les propriétés d'un widget donné. La page
d'affichage est une grille de deux colonnes dont le nombre de lignes est fixé par l'utilisateur à la
création. Chaque widget se place sur une ligne.
La colonne de gauche est prévue pour les widgets qui affichent les télémesures, soit le widget
personnalisé qui affiche la mesure instantanée, soit le widget d'oscilloscope. La seconde colonne est prévu pour l'insertion de boutons pour lancer une fenêtre de saisie de télécommande.
Une page se présente de cette façon :
14
Figure 4-3: Schéma explicatif d'une page d'affichage
Lorsque l'utilisateur a fini la page d'affichage il peut la sauvegarder sous forme de fichier XML
qui sera lu par le Centre de Contrôle.
Le format XML a été choisi car il permet de décrire de façon simple et facilement modifiable les
données, de plus le fait que Glade utilise ce format pour ses fichiers de sauvegarde a aidé à
confirmer l'intérêt de ce choix. Le fichier doit contenir suffisament d'informations pour indiquer le
widget à afficher mais pour aussi pour pouvoir connecter ces widgets aux données correspondantes à l'affichage.
Le logiciel est composé de quatre couches principales :
6.2.1. La couche Interface
C'est la couche avec laquelle l'utilisateur interagit et qui lui permet de créer les pages
d'affichage
6.2.2. La couche Application
C'est la couche qui gère la création des pages d'affichage, leur sauvegarde et leur chargement
s'il y a besoin de les modifier.
Elle s'assure que les pages soient correctement formées en ne permettant de placer les widgets de visualisation de télémesure que dans la colonne de droite et les widgets qui permettent
de lancer les pages de télécommande que dans la colonne de gauche. Elle est aussi chargée
de permettre de sélectionner parmi la liste des télémesures existantes, lorsque l'on ajoute ou
édite un widget, ainsi que les unités qui lui sont liées.
Le fichier XML définit chaque widget avec sa télémesure attachée, les information qui y sont
liées et sa position sur la grille. La DTD XML est présente en annexe.
6.2.3. La couche Domaine
Cette couche est commune avec l'application de Centre de Contrôle. Elle fournit la définition
des télémesures et pseudo-mesures affichables et permet de connaitre leur unités correspondantes.
En effet, contrairement à un générateur d'interface classique, celui ci est fortement lié au domaine. Les widgets d'affichage sont liés aux télémesures qu'ils doivent afficher puisque les
données seront rattachées à l'affichage dynamiquement.
6.2.4. La couche Infrastructure
Elle est aussi commune avec l'application de Centre de Contrôle, elle définit les widgets personnalisés qui pourront être affichés dans les pages que l'utilisateur créera.
Deux widgets personnalisés sont nécessaires, l'un pour afficher les valeurs instantannées,
l'autre pour afficher l'évolution de la valeur d'une télémesure sous forme d'oscilloscope.
6.3. Outil de dépouillement
L'outil de dépouillement permet de transférer les télémesures qui ont été stockées durant les
échanges entre le bord et le sol dans un fichier binaire en un fichier ASCII. Cela permet de relire
après coup ces échanges, où de les traiter avec des outils scientifiques. C'est une application
en ligne de commande. Je n'ai pas travaillé de manière plus poussée sur cet outil.
15
6.4. Widget Spécifiques
6.4.1. Affichage de valeurs instantanées
C'est la composition de trois widgets de base pour l'affichage. Il est composé de deux champs
de texte et un champ d'affichage. Les champs de texte permettent d'afficher l'intitulé et l'unité de
la télémesure, et le champ d'affichage sa valeur.
6.4.2. Oscilloscope
Il fait parti des widget spécifiques nécessaires à l'affichage des télémesures. Il a demandé plus
d'effort que le widget d'affichage de valeurs instantanées car il n'est pas la simple composition
de widgets de base.
Ce widget doit permettre d'afficher des valeurs en temps réel sous la forme d'un oscilloscope. Il
doit aussi permettre de changer le "zéro" sur l'axe des y et de "zoomer" sur la courbe (ie changer l'intervalle de valeurs en x et en y).
Il est basé est basé sur Gtk.Extra.Plot, Gtk.Extra.Plot_Data et Gtk.Extra.Plot_Canvas pour
l'affichage strict du graphe, couplés avec d'autres widgets pour pouvoir agir sur le graphe.
Figure 4-4: Widget Oscilloscope
16
7. Pistes pour la réalisation
7.1. Widget Oscilloscope
C'est sur la réalisation de cet outil que je me suis principalement confronté à GtkAda, en effet il
comprend toutes les caractéristiques graphiques principales. Il est composé des composants de
base de GTK+ jusqu'aux plus spécifiques, il devait être temps réel et donc assurer un affichage
régulier.
Grâce au fait qu'il soit orienté objet, Ada95 facilite la création de nouveau widgets, notamment
lorsque le widget que l'on veut créer est composé de widget déjà existants. Il faut alors d'hériter
d'un widget père qui forme la base du widget personnalisé et de le compléter avec les widgets
déjà existants ou créés sur mesure. Ceci est illustrer par le code du widget en annexe.
J'ai passé beaucoup de temps à essayer de réaliser ce widget en GtkAda 2.0. En effet, aucune
version suivante n'étant initialement annoncée, cela semblait la seule version utilisable. Malheureusement, cette version était incomplète en rapport à l'API GTK+ sans que cela ne soit indiqué
où que ce soit. Cela posait notamment des problèmes pour réaliser un outil temps réel car la
gestion des threads n'était pas correctement implémenté au niveau de GtkAda.
Il a fallu attendre la version 2.2 de GtkAda, sortie tardivement, pour qu'il implémente correctement GTK+.
Le widget doit permettre d'afficher deux courbes en simultanée, de faire varier le zéro en Y pour
pouvoir centrer les courbes et d'avoir plus où moins de valeurs affichées à l'écran (en fournissant un intervalle plus ou moins grand en X).
7.2. Générateur de pages
Son interface a été réalisée grâce à Glade-2, et comme son objectif est sensiblement le même,
il en reprend l'apparence, c'est à dire qu'il présente trois fenêtres séparées.
La première est celle qui permet de gérer l'application et qui permet de gérer les pages
(Création, Sauvegarde...). Elle permet aussi de donner directement un nom à la page (qui peut
être différent du nom de fichier) et de taper un commentaire qui décrit la page.
17
Figure 4-5: Fenêtre principale du Générateur
La deuxième présente les différents widgets qui pourront être insérés sur la page. Il suffit de cliquer sur l'icone d'un widget puis ensuite de sélectionner une case de la grille de la page que
l'on veut créer pour y placer le widget correspondant.
Figure 4-6: Fenêtre palette du Générateur
La troisième permet d'éditer les propriétés des widgets qui se trouvent sur la page. En fonction
du widget cela permet de choisir la télémesure concernée, l'unité de grandeur désirée, voir les
deux dans le cas d'un widget d'oscilloscope. La télémesure étant une donnée métier,
l'utilisateur doit choisir dans la liste des télémesures existantes. En fonction de ce choix, il a
accès aux unités possibles pour cette télémesure. De même le champs intitulé est prérempli
lorsque l'utilisateur choisit la télémesure, il a cependant la possibilité de le modifier.
18
Figure 4-7: Fenêtre de propriétés du Générateur
Une fois la page finie, il suffit de sauvegarder pour créer le fichier XML qui sera lisible par
l'application de Centre de Contrôle.
Le fichier XML reprend partiellement la DTD du format XML de glade-2. C'est en fait une version simplifiée, car il y a moins de widget à gérer et, surtout, pas d'arbre de descendance, et
modifiée pour répondre aux besoins spécifiques de l'application. Notamment le placement des
widgets étant fixé sur une grille, chaque représentation du widget dans le fichier XML à un un
numéro de ligne, le numéro de colonne étant déduit du type du widget.
7.3. Contrôle Commande
7.3.1. Interface
L'interface graphique permet de gérer l'acquisition et les pages à charger. Le lancement et
l'arrêt de l'acquisition se fait directement par le menu toujours disponible. La fenêtre principale
se présente sous forme d'une liste des différentes pages accessibles avec leur nom et leur
commentaire. Grâce à cette liste il est possible d'effectuer les opérations de base sur ces
pages. Double cliquer sur la ligne d'une page doit la lancer ou la repasser en avant plan en
fonction de son état. Un clic droit sur la ligne doit donner accès à un menu contextuel qui permet de lancer et de fermer la page. Chaque page bénéficie donc d'une fenêtre indépendante.
De plus, ces pages d'affichages peuvent appeler des fenêtres qui permettent la saisie et l'envoi
de télécommandes.
19
Figure 4-8: Fenêtre principale du Centre de Contrôle (avec shéma de ce à quoi la liste des
pages doit ressembler)
7.3.2. Application
Le coeur du système est la partie Acquisition et Traitement, c'est elle qui est chargée d'envoyer
les données qu'elle reçoit de la nacelle aux autres parties de l'application. Pour l'acheminement
des données aux autres parties, principalement l'interface et l'unité de stockage, nous utiliserons un système de rendez-vous asynchrone. Ceci est possible car il est toléré de perdre certaines télémesures. En effet, les télémesures décrivant généralement des phénomènes cycliques, la perte de l'une d'elle n'est pas pénalisant car on aura son équivalent à la période suivante. Ainsi grâce à se système la partie Acquisition n'a pas besoin d'acquitements de la part
des autres parties du système. Ce système de rendez vous asynchrone est réalisé grâce à une
thread "messagère" qui reçoit les données de la partie Acquisition et est chargé d'aller l'apporter
à la partie destinataire. Si le destinataire est trop occupé pour recevoir les données elles finissent par être abandonnées.
La partie stockage a pour unique but de récuperer les données que la partie Acquisition lui envoie et de les écrire dans un fichier binaire.
La partie de Chargement des pages a un travail plus complexe. Elle doit lire le fichier XML créé
par le générateur de page pour réaliser l'affichage dynamiquement et connecter les widgets,
provenant entre autre de la couche Infrastructure pour les widgets spécifiques, correspondants
aux données souhaitées reçues par la partie Acquisition.
7.3.3. Domaine
La couche domaine définit les différentes télémesures et télécommandes, les calculs de
pseudo-mesures et les différents traitement à effectuer, elle fournit aussi les fonctions de
conversions entre les télémesures stockées dans un type à discriminant qui est reçu de la nacelle en un type étiqueté qui est utilisé dans l'application.
20
8. Récapitulatif de l'avancé du travail
8.1. Centre de Contrôle
J'ai réalisé une vue globale de la conception du Centre de Contrôle.
J'ai défini les paquetages principaux des différentes couches.
- Pour la couche d'interface, j'ai réalisé l'interface de départ, il manque la réalisation de la
listes de pages. Les pages d'affichages sont définies mais ne sont pas réalisées.
Pour la couche d'application, j'ai défini l'architecture globale sur trois parties principales. Je
n'ai pas du tout touché à la partie sur le stockage.
Pour la partie acquisition et traitement j'ai principalement regardé comment cela était fait
dans PRONAOS, un précédent projet d'André Laurens qui traitait des mêmes maproblétiques en Ada83.
Pour la partie chargement des pages, j'ai défini le format de stockage qui puisse permettre
un chargement le plus facile possible et j'ai défini comment les pages devraient s'afficher
- Pour la couche infrastructure, j'ai défini et réalisé les deux widgets personnalisé. Une fois
les télémesures completement définies il faudra probablement réalisé les fonctions de
conversion pour permettre l'affichage des valeurs.
- Pour la couche domaine, j'ai regardé comment cela était fait dans Pronaos, et j'ai adapté
la structure des télémesures pour permettre de profité de la vue objet apparue dans
Ada95.
8.2. Générateur de Pages
Les couches Domaine et Infrastructures sont les mêmes que pour le Centre de Contrôle.
L'interface pour permettre la réalisation de page est définie et réalisée. Il manque par contre la
création des pages d'affichage.
La conception de la page d'affichage est réalisé de telle façon que la sauvegarde vers le format
XML soit aisée
Les concepts de création des widgets personnalisés à partir des télémesures sont définis mais
n'ont pas été réalisés.
21
Chapitre 5 : Méthode et outils utilisés
Chapitre 5
Méthode et outils utilisés
1. Environnement
- Matériel : PC standard
- Système d'exploitation : GNU/Linux (Mandrake 9.0 et 9.1)
2. Outils
- Environnement de développement : GNAT 3.15p
- Création d'interfaces : Glade-2
- Editeur : Kate
22
Chapitre 6 : Bilan
Chapitre 6
Bilan
Tout d'abord ce stage a été une première expérience dans le monde du spatial et de l'industriel.
J'ai pu en apprendre beaucoup de choses, que ce soit sur le plan culturel ou technique.
Ce stage m'a permis d'approfondir directement mes connaissances en Ada95 et en GTK+ à travers GtkAda. Dans un projet de ce genre, Ada offre des attrait indéniables :
- Un fort typage qui permet la détection de bugs dès la compilation et qui assure que les
données sont bien celles que l'on attend.
- Le tasking (ou multi-tache) qui facilite la réalisation d'applications temps réels. En effet
Ada95 prend en compte au niveau du langage les enjeu du temps réel et offre les fonctions nécessaires à sa mise en oeuvre de façon efficace.
- Une vue objet qui a permis de factoriser le modèle de certains paquetages et qui a facilité
l'intégration de GtkAda.
Et l'utilisation de GtkAda permet de garder la portabilité d'Ada, avec une interface graphique qui
conserve les principes d'Ada tels que le fort typage et l'héritage.
Cependant, il m'a aussi permis de me rendre compte à quel point les outils sur lesquels on se
base pour le développement sont vitaux, et que si ceux ci ne sont pas aussi bien maintenus
qu'annoncé, un temps précieux est perdu. Cela a été le cas avec GtkAda 2.0 qui semblait
répondre parfaitement à nos besoins, mais ayant été réalisé seulement partiellement, de nombreux problèmes sont apparus dans les utilisations un peu poussées telles que le multi-tache. Il
a fallu attendre la version 2.2 de GtkAda pour résoudre ces problèmes.
Ensuite travailler dans un système bord et sol a été très enrichissant, avoir une vue globale permet de mieux comprendre l'objectif de ce que l'on fait. Cela permet aussi de se rendre compte à
quoi servira dans la pratique le logiciel sur lequel on travaille.
En participant à la conception de la partie sol, j'ai pu me rendre compte de différents enjeux à
prendre en compte, et l'on se rend compte que la façon dont le bord fonctionne impose des
choses au sol. Comprendre ces interactions est très enrichissant et permet de mieux comprendre le fonctionnement interne des logiciels.
Sur un plan humain, j'ai aussi pu apprendre beaucoup de choses au contact d'une équipe qui
mêle des métiers différents autour d'un même projet, chose assez rare pour être relevée. Notamment, l'intérêt de pouvoir confronter des points de vues totalement différents sur un même
problème pour arriver à des solutions auxquels on ne serait probablement pas arrivé seul.
23
Chapitre 7 : Annexe
Chapitre 7
Annexe
1. Réalisation de Widget composés aidée grâce aux concepts
d'Ada et de GtkAda, exemple du Widget d'oscilloscope
On définit ici le Widget Oscilloscope comme un fils d'un Box GTK+, c'est à dire un tableau à une
dimension.
package Oscilloscope is
type Oscilloscope_Record is new Gtk_Box_Record with record
On définit ensuite tous les sous widget qui vont former le widget complet d'oscilloscope. On
note au passage qu'il n'est pas formé que de widgets standards, Mon_Graphe est un widget
crée basé sur les widget de Gtk_Plot.
Scrolledwindow : Gtk_Scrolled_Window;
Graphe : Mon_Graphe.Mon_Graphe;
Table1 : Gtk_Table;
Label_Intervalle_X : Gtk_Label;
Entry_Intervalle_X : Gtk_Entry;
Bouton_Valider_Intervalle_X : Gtk_Button;
Label_Amplitude : Gtk_Label;
Entry_Amplitude : Gtk_Entry;
Bouton_Valider_Amplitude : Gtk_Button;
Label_Centrer_Y : Gtk_Label;
Entry_Centrer_Y : Gtk_Entry;
Bouton_Valider_Centrer_Y : Gtk_Button;
end record;
On définit ensuite les procédures de bases nécessaire à un widget pour qu'il puisse être créé
comme un widget classique.
type Oscilloscope_Access is access Oscilloscope_Record'Class;
procedure Gtk_New (Oscilloscope1 : out Oscilloscope_Access);
procedure Initialize (Oscilloscope1 : access Oscilloscope_Record'Class);
end Oscilloscope;
On écrit ensuite les fonctions qui vont permettre la création du widget.
Gtk_New suit un modèle obligatoire pour la création d'un widget, il l'alloue et l'initialise.
package body Oscilloscope is
procedure Gtk_New (Oscilloscope1 : out Oscilloscope_Access) is
begin
24
Chapitre 7 : Annexe
Oscilloscope1 := new Oscilloscope_Record;
Oscilloscope.Initialize (Oscilloscope1);
end Gtk_New;
procedure Initialize (Oscilloscope1 : access Oscilloscope_Record'Class) is
pragma Suppress (All_Checks);
begin
On initialise ensuite l'oscilloscope en faisant appel directement à la fonction Initialize de son
père, ainsi l'oscilloscope se comporte comme un VBox (tableau à une dimension verticale)
Gtk.Box.Initialize_Vbox(Oscilloscope1, False, 0);
Gtk_New (Oscilloscope1.ScrolledWindow);
Set_Policy (Oscilloscope1.ScrolledWindow, Policy_Always, Policy_Always);
Gtk_New (Oscilloscope1.Graphe);
Set_Shadow_Type (Oscilloscope1.Graphe, Shadow_In);
Add (Oscilloscope1.ScrolledWindow, Oscilloscope1.Graphe);
On ajoute donc les sous widget à l'oscilloscope comme on les ajouterai à une VBox classique.
Pack_Start
(Oscilloscope1,
Oscilloscope1.ScrolledWindow,
Expand => True,
Fill
=> True,
Padding => 0);
Et on répète l'opération pour chaque sous widget.
Gtk_New (Oscilloscope1.Table1, 2, 6, False);
Set_Row_Spacings (Oscilloscope1.Table1, 0);
Set_Col_Spacings (Oscilloscope1.Table1, 0);
Pack_Start
(Oscilloscope1,
Oscilloscope1.Table1,
Expand => False,
Fill
=> False,
Padding => 0);
[...]
Pour finir, on demande l'affichage de l'oscilloscope, on a maintenant un widget complet.
Show_All (Oscilloscope1);
end Initialize;
end Oscilloscope;
2. DTD des fichiers XML des pages d'affichage
25

Rapport de Stage - 3ème année d`IUP ISI - Nacelles pointées

Transcription

Documents pareils

TP 2 - Youssef RIDENE

Annexe 4 : Créer un widget de type flux RSS

ajout d`un post-it - Premiers pas Konica Minolta

Fréquences VHF et UHF utilisables pour les équipements non

Plateforme de consultations juridiques AVOCAT.FR

UTILISATION DES WIDGETS : AFFICHAGE DES

Mapa Web - Alimentación.es

Oscilloscope Numérique

Mode d`emploi

Book widgets