Développement du logiciel sol - OUFTI-1 - Université de Liège

UNIVERSITÉ DE LIÈGEFaculté des Sciences AppliquéesDépartement d’Électricité, Électronique et InformatiqueProjet de nanosatellite OUFTI-1 :Développement du logiciel solNgoc An NguyenPromoteur :Professeur Bernard BoigelotMémoire présenté en vue del’obtention du grade deLicencié en Sciences InformatiquesAnnée académique 2009 - 2010

RemerciementsJe remercie tout d’abord le Professeur Bernard Boigelot pour son encadrementlors de ce travail de fin d’études, ainsi que ses conseils portant sur le contenu dutravail.J’exprime toute ma reconnaissance au Professeur Jacques G. Verly et au ProfesseurGaëtan Kerschen de m’avoir permis d’intégrer l’équipe OUFTI-1 et de m’avoirproposé un travail de fin d’études original et très intéressant.J’ai eu le plaisir et la chance de travailler dans une équipe motivée et sympathique.Je remercie tous les membres de l’équipe pour les nombreuses discussionstechniques au cours de l’année.Je remercie également toute l’équipe système pour la gestion du projet, les activitéset les réunions organisées dans le cadre du projet ; à savoir : Amandine Denis,Jonathan Pisane, Laurent Chiarello, Laurent Rainaut et Jérôme Wertz. Plus particulièrement,je remercie Laurent Chiarello pour nos nombreuses discussions surle développement de la station sol.Je tiens également à remercier Florian George de l’équipe SwissCube pour seséclairages techniques au niveau de la station sol.Une reconnaissance toute particulière à ma famille qui m’a soutenu et encouragétout au long de mes études.Enfin, un grand merci aussi à toutes les personnes qui ont contribué de loin oude près à la réussite de ce travail.Nguyen Ngoc Ani

Table des matières1 Introduction 11.1 Sujet et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Plan du document . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Projet nanosatellite OUFTI-1 42.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Le concept CubeSat . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Radioamateur, AX.25 et D-STAR . . . . . . . . . . . . . . . . . . . 62.3.1 Radioamateur . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 Protocole AX.25 . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3 Protocole D-STAR . . . . . . . . . . . . . . . . . . . . . . . 72.3.4 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Objectifs de la mission . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Opérations spécifiques de OUFTI-1 . . . . . . . . . . . . . . . . . . 92.5.1 Canal de commandement . . . . . . . . . . . . . . . . . . . . 92.5.2 Canal D-STAR . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.3 Mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.4 Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Station sol 123.1 Description générale de la station sol . . . . . . . . . . . . . . . . . 123.2 Ground Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.1 Equipement RF . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Antennes et système de tracking . . . . . . . . . . . . . . . . 133.2.3 Architecture du GS . . . . . . . . . . . . . . . . . . . . . . . 133.3 Mission Control Center . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.3 Architecture du MCC . . . . . . . . . . . . . . . . . . . . . 184 Automatisation du Mission Control Center 204.1 Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.1 Représentation d’un planning . . . . . . . . . . . . . . . . . 214.3 Langage de développement . . . . . . . . . . . . . . . . . . . . . . . 26ii

TABLE DES MATIÈRESiii4.4 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 Outil de planification . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.2 Les modules de l’outil planification . . . . . . . . . . . . . . 314.5.3 Module planning . . . . . . . . . . . . . . . . . . . . . . . . 314.5.4 Module générateur de code . . . . . . . . . . . . . . . . . . . 324.5.5 Module parser . . . . . . . . . . . . . . . . . . . . . . . . . . 344.5.6 Module afficheur de plannings . . . . . . . . . . . . . . . . . 354.5.7 Module interface graphique . . . . . . . . . . . . . . . . . . 354.5.8 Communication entre scripts Python et MCS . . . . . . . . 374.5.9 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Développement du Mission Control Center 405.1 Architecture du MCC . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Communication clients et MCS . . . . . . . . . . . . . . . . . . . . 425.2.1 Java Remote Method Invocation . . . . . . . . . . . . . . . . 425.3 Mission Control Software . . . . . . . . . . . . . . . . . . . . . . . . 455.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 465.4 Outil d’envoi manuel de télécommandes . . . . . . . . . . . . . . . . 475.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 475.5 Mission Data Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . 505.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.5.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 516 Base de données de mission 556.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.1.1 Système de gestion de base de données . . . . . . . . . . . . 566.2 Structure de la base de données de mission . . . . . . . . . . . . . . 567 Protocoles de communication 607.1 Protocoles utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.2 Protocole PUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.3 Service de vérification de télécommandes . . . . . . . . . . . . . . . 627.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.3.2 Sous-types du service 1 . . . . . . . . . . . . . . . . . . . . . 637.4 Service de génération de rapports de données . . . . . . . . . . . . . 637.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.4.2 Sous-types du service 3 . . . . . . . . . . . . . . . . . . . . . 647.5 Service de gestion de fonctions . . . . . . . . . . . . . . . . . . . . . 647.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

TABLE DES MATIÈRESiv7.5.2 Sous-types du service 8 . . . . . . . . . . . . . . . . . . . . . 657.6 Service d’ordonnancement à bord . . . . . . . . . . . . . . . . . . . 657.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.6.2 Sous-types du service 11 . . . . . . . . . . . . . . . . . . . . 657.7 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668 Activités du projet OUFTI-1 688.1 Interface Technical Review . . . . . . . . . . . . . . . . . . . . . . . 688.2 Présentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689 Conclusion et développements futurs 699.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.2 Idées pour les futurs développements . . . . . . . . . . . . . . . . . 70Bibliographie 71Appendices 73A Liste des mesures à bord de OUFTI-1 74B Diagramme logiciel statique 76B.1 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76B.2 Outil d’envoi manuel de télécommandes . . . . . . . . . . . . . . . . 77B.3 Outil de planification . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.4 Mission Data Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . 79C Code source 80

Chapitre 1IntroductionOUFTI-1 est le premier nanosatellite développé à l’Université de Liège et enBelgique. OUFTI-1 a été récompensé d’une place sur le vol inaugural VettoreEuropeo di Generazione Avanzata (VEGA) après une défense du projet au CentreEuropéen de Recherche et de Technologie Spatiale (ESTEC) aux Pays-Bas.La particularité principale de OUFTI-1 est l’implémentation du protocole DigitalSmart Technologies for Amateur Radio (D-STAR) dans l’une de ses chargesutiles. D-STAR est un protocole radioamateur innovant développé par l’associationdes radioamateurs japonais (JARL), complètement numérique, permettantdes transferts simultanés de la voix et de données. Le protocole D-STAR devientde plus en plus populaire dans le monde mais il n’a jamais été utilisé dans le cadrespatial. Cette caractéristique spécifique du projet suscite un intérêt chez le publicmais également renforce notre envie de développer quelque chose d’unique.Le projet est en développement à l’Université de Liège depuis deux ans. Chaqueannée, un groupe d’étudiants participent au développement du projet lors de leurdernière année d’études, où chacun des étudiants est responsable d’un sous-systèmedu projet. L’équipe participant au projet OUFTI-1 lors cette année académique estconstituée de quatorze étudiants, tous travaillant sur leur travail de fin d’études.Le document présent fait partie des travaux de fin d’études contribuant à l’avancementdu projet unique OUFTI-1.1.1 Sujet et objectifsLors d’une mission spatiale, il est important d’avoir un endroit d’où on peutcontrôler et surveiller le satellite en orbite. Cet endroit est appelé la station sol. Lastation sol peut être divisée en deux parties. La première partie, appelée GroundStation (GS), est constituée de tout l’équipement matériel permettant la communicationavec le satellite, c’est-à-dire les antennes, les émetteurs-récepteurs, etc. Laseconde partie, appelée Mission Control Center (MCC), est composée en grandepartie de logiciels qui sont utilisés par les opérateurs dans l’objectif de contrôler lesatellite par l’envoi de télécommandes et la réception de télémétries. Le travail defin d’études présent porte sur le MCC.1

CHAPITRE 1. INTRODUCTION 2L’objectif de ce travail de fin d’études est le développement du centre de contrôlede mission d’où les opérateurs pourront contrôler le satellite.Le projet OUFTI-1 est à sa troisième année de développement, il a été doncnécessaire de voir ce qui a été développé lors des années précédentes par rapport àla station sol et ensuite de déterminer les objectifs spécifiques de ce mémoire. Lestravaux de fin d’études des années précédentes ont permis de voir l’état d’avancementdu projet et ont également servi de base à la réalisation du travail de find’études présent. Bien que le titre de [8] est similaire au travail de fin d’études présent,le travail est différent. En effet dans [8], le travail a porté sur les protocoles decommunication utilisées dans la mission OUFTI-1, la conception de haut niveaudu Mission Control Software (MCS) qui est un élément du MCC et l’architecturedu GS.La station sol du satellite joue un rôle important et son développement requiertune organisation rigoureuse et soignée.Voici les objectifs qui ont été définis et qui sont atteints tout au long du parcoursdu document.1. Identifier les éléments nécessaires à l’automatisation du MCC.2. Définir l’architecture du MCC et les modules basiques qui en font partie.3. Définir, avec certains sous-systèmes, des interfaces de communication.4. Développer et optimiser les logiciels faisant partie du MCC.Des efforts ont été fournis afin d’avoir des logiciels modulaires, génériques et commentésqui permettront une meilleure et rapide compréhension des logiciels etégalement d’adapter ceux-ci ultérieurement si cela s’avère nécessaire.Dans les chapitres suivants, les logiciels développés dans le cadre de ce mémoiresont décrits de la manière la plus claire possible dans l’objectif de faire comprendreaux lecteurs leurs fonctionnements. Cela permettra également aux étudiants del’année suivante de gagner du temps.1.2 Plan du documentAprès cette brève introduction, le chapitre 2 présente le contexte et les motivationsdu projet.Le chapitre 3 donne un aperçu global de la station sol, incluant le matériel et leslogiciels utilisés dans la station sol.Le chapitre 4 explique les mécanismes mis en place permettant l’automatisationdu MCC. Ensuite, le chapitre 5 abordera la structure du MCC et le développementdes unités en faisant partie.Ensuite, le chapitre 6 présente la base de données de la mission, son interactionavec les éléments du MCC et son contenu.

CHAPITRE 1. INTRODUCTION 3Le chapitre 7 décrit brièvement les protocoles de communication et les servicesdu protocole Packet Utilization Standard (PUS) utilisés dans le cadre de la missionOUFTI-1.Finalement, les chapitres 8 et 9 abordent les activités relatives au projet, lesdéveloppements qui pourront être réalisés dans le futur, et enfin la conclusion.

Chapitre 2Projet nanosatellite OUFTI-1Ce chapitre présente le contexte dans lequel le projet est apparu, sa descriptionet ses objectifs de base.2.1 Contexte du projetDepuis des années, l’Université de Liège (ULg) a un rêve qui est de développerdes satellites dans un cadre éducatif. L’initiative nanosatellite a été lancée en 2004,avec comme nom Leodium qui a pour signification “Lancement En Orbite de DémonstrationsInnovantes d’une Université Multidisciplinaire” et qui est égalementle nom latin de Liège. L’objectif de cette initiative est de créer une série de nanosatellitesdéveloppés par des équipes d’étudiants venant de différentes branchesen sciences appliquées (par exemple, ingénieur civil en aérospatiale, licencié ensciences informatiques, ingénieur industriel, etc.).Le projet d’un nanosatellite complètement belge, idée proposée par Luc Halbach,directeur commercial de Spacebel, est devenu officiellement une réalité en2007. Son développement commença en 2008 incluant quatorze étudiants venantde l’Université de Liège, l’institut HELMo Gramme et l’Haute École de la Provincede Liège ISIL. Les étudiants travaillaient sur les différents sous-systèmes du satelliteselon leur domaine de formation. Ce projet est également en développementlors de cette année académique.OUFTI-1 est un nanosatellite construit respectant le format CubeSat. Ce formatest décrit dans la section suivante.Son lancement était initialement programmé lors du lancement du vol inauguralVEGA en novembre 2009 mais, étant reporté, la nouvelle date de lancement n’estpas connue pour l’instant. Le lanceur VEGA est réalisé par l’agence spatiale européenne(ESA) et l’agence spatiale italienne (ASI). La particularité de ce lanceurest son faible coût par l’exploitation matérielle et technologique déjà existante.4

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 52.2 Le concept CubeSatUn CubeSat désigne une famille de petit satellites respectant un format particulier(voir [19]). Le format CubeSat a été défini par l’Université polytechniquede Californie (CalPoly) et les laboratoires des systèmes spatiaux de l’UniversitéStanford (SSDL).TypePicosatelliteNanosatelliteMicrosatelliteMinisatelliteMasseMoins d’1 kg1 à 10 kg100 à 500 kg100 à 500 kgTable 2.1 – Classification des familles de petits satellitesUn CubeSat est un cube de 10 cm avec une masse maximale de 1 kg.Un tableau reprenant les différents types de familles de petits satellites est représentéà la table 2.1. En plus des dimensions, le format CubeSat décrit égalementune interface spécifique avec le lanceur, facilitant l’intégration des CubeSats commecharges utiles secondaires.La plupart des CubeSats envoyés sont fabriqués par des universités car ces dernièresveulent en faire un projet éducatif idéal. C’est un projet réaliste mais celademande également beaucoup d’ambition et de motivation. En effet, le budget requisn’est pas si élevé comparé au développement de satellites de taille normale etle temps de développement est raisonnable.Grâce à ce projet, les étudiants ont la possibilité de travailler sur toutes les phasesde conception d’un satellite, de la définition de la mission à la communication D-STAR avec le satellite en orbite. Ces satellites n’offrent pas que des opportunitéséducatives mais également des opportunités scientifiques. Des scientifiques aurontla possibilité de pouvoir effectuer des expériences scientifiques dans l’espace etensuite de consulter les données stockées relatives à ces expériences dans la basede données de mission.Les CubeSats sont généralement lancés comme charges utiles secondaires d’unlanceur. Les lanceurs amènent généralement les CubeSats dans l’orbite terrestrebasse (LEO).Le système de déploiement standard est appelé Poly Picosatellite Orbital Deployer(P-POD). Ce système est constitué d’un container avec une porte pouvantcontenir trois CubeSats et un mécanisme de ressort (voir figure 2.2). Il assureégalement la communication entre les CubeSats et le lanceur lors des opérationsd’éjection des CubeSats en orbite.La structure de chaque CubeSat doit inclure des petit ressorts, appelés separationsprings, à sa base pour s’assurer que les CubeSats seront séparés après leur éjectiondu container.Les CubeSats ne doivent pas être allumés lors du décollage pour des raisons desécurité. Par conséquent, un mécanisme a été mis en place afin d’activer l’électro-

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 6Figure 2.1 – CubeSat typique en orbite (source : AAU CubeSat site web officiel)nique sur chaque CubeSat après son éjection du P-POD. Ce mécanisme est réaliséà l’aide de deployment switches ou launch switches à la base des CubeSats (Figure2.3). Ces deployment switches sont ouverts électriquement durant le lancement etlors de l’éjection, les interrupteurs se ferment, allumant ainsi l’électronique sur leCubeSat venant de sortir.L’ESA offre parfois des opportunités de places sur un lanceur aux CubeSats etle nanosatellite OUFTI-1 a été sélectionné avec huit autres CubeSats pour fairepartie du vol inaugural du lanceur VEGA.Figure 2.2 – Poly Picosatellite Orbital Deployer (source : [19])2.3 Radioamateur, AX.25 et D-STAR2.3.1 RadioamateurLe radioamateurisme est un passe-temps relatif aux communications radio. Lesradioamateurs sont familiarisés avec les signaux RF (Radio Frequency) et l’électro-

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 7nique. Le principal objectif des radioamateurs, souvent appelés ham, est d’établirun lien avec d’autres radioamateurs dans le monde. Ils possèdent les équipementsnécessaires pour émettre et recevoir des ondes radio. Dans notre cas, il faudraque les radioamateurs possèdent des équipements supportant le D-STAR s’ils souhaitentcommuniquer via le satellite.La communauté des radioamateurs ont de l’expérience dans les systèmes de communicationanalogique et numérique qui va être profitable pour le projet OUFTI-1.2.3.2 Protocole AX.25Le mode de communication numérique le plus populaire est le radio packet quiest réalisé à partir du protocole AX.25 et du Frequency-Shift Keying (FSK). Leprotocole AX.25 a été conçu et développé par la communauté des radioamateursafin de fournir un mécanisme fiable de transport de données entre deux terminaux.Ce protocole est conforme au standard International Standard Organization (ISO)et couvre les deux couches les plus basses du modèle Open Systems Interconnection(OSI) c’est-à-dire la couche physique et la couche liaison.Ce protocole est utilisé dans le cadre de la mission pour l’envoi de télécommandeset la réception de télémétries.Voir [34] pour plus d’informations sur le protocole AX.25.2.3.3 Protocole D-STARUn autre mode de communication numérique, connu sous le nom de D-STAR,devient également populaire. Il est basé sur le Gaussian Minimum Shift KeyingFigure 2.3 – Dessin du CubeSat avec ses interrupteurs de déploiement et lesressorts de séparation (source : [19])

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 8(GSMK) et utilise des codes de correction d’erreurs. Le protocole D-STAR est unprotocole packed-based qui couvre les communications sur les bandes radio HF,VHF et UHF et qui définit des interfaces pour les radios, les répéteurs, les interconnexionsInternet (Gateways) et les ordinateurs. Cela permet aux radioamateursd’être connectés à Internet et à différents réseaux.Le protocole D-STAR permet la transmission simultanée de données et de voix.Deux modes de communications sont définis :• Digital Voice (DV) avec une vitesse de 4.8 kbps, données et voix entremêlées,• Digital Data (DD) avec une vitesse de 128 kbps, seulement des données.Le schéma simple d’une communication D-STAR est la communication directeentre deux appareils supportant le D-STAR quand les deux opérateurs sont assezproches pour établir un lien RF. Pour des communications de longue distance, unrépéteur D-STAR peut être utilisé pour étendre ce lien, à condition que les deuxopérateurs soient dans la zone radio couverte par le répéteur. Dans le cadre de lamission OUFTI-1, le répéteur permettant d’étendre le lien entre deux opérateursest le satellite.Voir [20] pour plus d’informations sur le protocole D-STAR.2.3.4 AvantagesLes opérateurs radio amateur du monde entier communiquent de plus en plusavec des équipements supportant le protocole D-STAR. Leur expérience venantde cette utilisation du protocole D-STAR et AX.25 pourra nous être bénéfique,puisque le projet OUFTI-1 utilise ces deux protocoles.Leur expérience n’est pas le seul avantage provenant des communautés radioamateurs.En effet, étant donné la répartition des radioamateurs à travers le monde,un tracking constant de notre satellite est possible. Il sera envisageable de recevoirdes nouvelles du satellite constamment, même si la station sol se trouve horsde la zone que le satellite couvre. En contrepartie, les radioamateurs pourront,par exemple, utiliser le satellite comme répéteur D-STAR pour communiquer avecquelqu’un avec qui il n’aurait pas pu communiquer avec des moyens ordinaires.Les communications satellite seront réalisées dans les bandes Very High Frequency(VHF) et Ultra High Frequency (UHF), respectivement 145 MHz et 435MHz en termes de fréquence du signal, ou 2 m et 70 cm en termes de longueurd’onde du signal.2.4 Objectifs de la missionLe principal objectif du projet OUFTI-1 est éducatif. Le but est de donner lapossibilité aux étudiants d’acquérir de l’expérience sur le terrain et de leur donnerl’opportunité de travailler, du début à la fin ou partiellement, sur une mission

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 9spatiale réelle. Par conséquent, toutes les tâches possibles doivent être réalisées parles étudiants impliquant donc la conception, les tests, le lancement et la gestiond’un nanosatellite. Tout cela se résulte par le développement complet du systèmedu nanosatellite et de la station sol. Lorsque le nanosatellite sera en orbite et qu’ilsera possible de communiquer avec à partir de la station sol, l’objectif principalpourra être considéré comme rempli avec succès.Les objectifs secondaires de la mission est d’utiliser le satellite pour tester desnouvelles technologies dans l’espace. Voici les objectifs secondaires du projet.• Utiliser OUFTI-1 comme un répéteur spatial D-STAR.• Tester une alimentation électrique expérimentale.• Tester un nouveau type de cellules solaires à rendement élevé.Le premier objectif permet les communications longue distance entre deux opérateursqui utilisent des équipements supportant le D-STAR et qui se servent dusatellite comme répéteur.Le second objectif permet de tester une alimentation électrique expérimentaledans l’espace. Il est clair que le satellite dispose d’un autre système d’alimentationélectrique. L’alimentation électrique expérimentale ne sera pas toujours active etles données en rapport seront téléchargées au sol pour être analysées par les scientifiques.Le dernier objectif permet de mettre à épreuve un nouveau type de cellulessolaires dont le traitement est similaire à l’objectif deux. En effet, plusieurs capteursont été placés sur les cellules solaires dans l’objectif de pouvoir analyser leurscomportements dans l’espace.2.5 Opérations spécifiques de OUFTI-1Cette section présente les quatre communications type entre le satellite et lesopérateurs au sol.2.5.1 Canal de commandementIl est nécessaire d’avoir un système de communication dédié à la surveillanceet au contrôle du satellite. Ce système devra constamment tourner même durantles communications D-STAR. Ce système utilise le protocole AX.25 afin de transmettredes télécommandes au satellite et de recevoir des télémétries venant de cedernier. Ce canal de commande du satellite permet de s’assurer que le satellitereste toujours sous contrôle de la station sol et que ce dernier peut demander ausatellite ce qu’il veut durant une passe du satellite (une passe du satellite est unepériode de temps durant laquelle la station sol peut communiquer avec le satellite).

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 102.5.2 Canal D-STARL’intégration du D-STAR dans le satellite permet aux radioamateurs de l’utilisercomme répéteur vers n’importe quel radioamateur, à condition que les deux setrouvent dans la zone couverte par le satellite et qu’ils aient des équipementssupportant le protocole D-STAR. Ce mode D-STAR du satellite n’est actif qu’aprèsavoir reçu via le canal de commandement l’ordre d’activer ce mode. Contrairementau canal de commandement, le canal D-STAR n’est pas constamment actif.Un problème lié à ce genre de communication est le changement de fréquenceinduit par l’effet Doppler. En effet, l’effet Doppler est présent en raison de la vitesserelative du satellite par rapport aux opérateurs. Les équipements supportant le D-STAR ne sont pas capables de gérer l’effet Doppler. Par conséquent, le problèmesera résolu à bord afin que le satellite soit accessible à beaucoup de personnes.Lors des communications D-STAR, cette correction de changement de fréquenceest calculée au sol et est transmise au satellite afin qu’il compense l’effet Doppleren changeant les fréquences de transmission.Cette intégration du protocole D-STAR dans le satellite permet d’étendre laportée des communications. Le plus long lien D-STAR qui pourrait être mis enplace est le cas où il y a deux intermédiaires entre deux radioamateurs. Le premierest le satellite OUFTI-1 jouant le rôle de répéteur et le second est le répéteur(ON0ULG) mis en place à l’Université de Liège.2.5.3 MesuresL’opération régulière qu’effectue le satellite est le prélèvement régulier de différentesmesures telles que la température d’une face du satellite, la tension desbatteries, etc. Il n’est intéressant de prendre ces mesures que si l’on peut les stockeren attendant que la station sol soit dans la zone couverte par le satellite. C’estla raison pour laquelle l’ordinateur de bord est doté d’une capacité de stockageadaptée pour la mission. La fréquence de prises de mesures et d’envoi des donnéesau sol sont prédéfinies. Ces prises de mesures seront téléchargées à la station solet permettra d’étudier les charges secondaires du projet en environnement spatial.Un ensemble de listes de mesures est défini avant la mission. Ces listes de mesuressont chacune différentes et ont un objectif particulier, si bien qu’une listede mesures reprend toutes les mesures propres à l’alimentation expérimentale, uneautre liste reprend les mesures propres à l’ordinateur de bord, etc. Chacune deces listes est représentée par un identifiant. La définition de ces listes de mesurespermet le filtrage des données téléchargées du satellite. Par exemple, si on est intéresséque par les mesures propres à l’ordinateur de bord, on enverra une requêtequi est l’activation d’envoi des valeurs des paramètres apparaissant dans la listeregroupant les paramètres de l’ordinateur de bord.Toutes les valeurs des paramètres ne sont pas constamment stockées. En effet,celles-ci ne sont stockées et envoyées que si le satellite reçoit l’ordre de la stationsol. Toutefois, une série de paramètres sera toujours prise et transmise pour descas d’urgence.

CHAPITRE 2. PROJET NANOSATELLITE OUFTI-1 112.5.4 BeaconEn plus des moyens de communication décrits ci-dessus, un module indépendant,appelé la beacon, se trouve sur le satellite.Ce module indépendant est un émetteur qui sera toujours actif et sa seule tâcheest de prendre des mesures critiques à bord du satellite et de les envoyer viaun canal de communication basique pouvant être considéré comme un canal desecours.Il est important que cette balise soit indépendante de tous les autres soussystèmesdu satellite afin qu’elle ne soit pas affectée par les autres sous-systèmes, sides problèmes surviennent sur le satellite. Ce signal est très utile dans les momentsoù le satellite et ses sous-systèmes sont défectueux. Les mesures spécialement choisiessont reçues par la station au sol et ce dernier pourra se servir de ces mesurespour déterminer l’origine du dysfonctionnement. Une liste des mesures définitivesprises par la beacon n’a pas encore été définie.

Chapitre 3Station solDans ce chapitre, la station sol du projet OUFTI-1 est décrite généralement.La section 3.1 présente une vue globale de la station sol. Les sections 3.2 et 3.3décrivent les deux principales parties constituant la station sol, le Ground Stationet le Mission Control Center.3.1 Description générale de la station solLa vue de la station sol OUFTI-1 peut être divisée selon les deux unités suivantes :• le Ground Station (GS), emplacement où se trouve tout le matériel RF avecles antennes ainsi que le système de tracking lié à ces antennes.• le Mission Control Center (MCC), emplacement d’où les opérateurs de la missionOUFTI-1 contrôlent le satellite. Les logiciels faisant partie du MCC permettentaux opérateurs de surveiller et de contrôler le satellite. Par exemple,les opérateurs auront à leur disposition un logiciel permettant d’envoyer manuellementdes télécommandes au satellite, un logiciel permettant de visualiserles données reçues du satellite, etc.Cette vue est représentée à la figure 3.1. Le travail de fin d’études porte particulièrementsur la conception et l’implémentation du MCC mais une description duGS est quand même écrite afin d’avoir une bonne compréhension et vue globalede la station sol.3.2 Ground StationLa GS est l’unité en communication directe avec le satellite. Les deux sectionssuivantes portent sur le chemin et le traitement des données passant par la GS.Ces données sont les télécommandes envoyées et les télémétries reçues. Le cheminet le traitement des données peuvent être divisés selon les deux grandes partiesconstituant la GS.12

CHAPITRE 3. STATION SOL 13Figure 3.1 – Vue générale de la station sol3.2.1 Equipement RFTous les appareils appartenant à cette partie interviennent dans le processus deconversion des données en série (télécommandes sous forme numérique) vers unsignal RF (analogue) assez puissant pour être envoyé au satellite et, inversement,d’un signal RF (télémétries) du satellite vers des données en série. Cette conversionest effectuée en plusieurs étapes (décrite plus en détails dans [27]).3.2.2 Antennes et système de trackingLe signal RF est envoyé et reçu par les antennes. Les antennes doivent pointervers le satellite, la position des antennes est sous la responsabilité du système detracking. Le rôle de ce dernier est de poursuivre le satellite en mouvement durantchaque passe.3.2.3 Architecture du GSL’architecture du GS est représentée à la figure 3.2. Les éléments sur le schémaont été groupés selon leurs fonctions :• les dispositifs du système de tracking constitués des rotateurs, du contrôleurdes rotateurs et de la carte de tracking sont colorés en rouge ;• les éléments de contrôle d’émission et de réception, utilisés majoritairementpour ajuster les fréquences afin de compenser l’effet Doppler, sont colorés envert ;

CHAPITRE 3. STATION SOL 14Figure 3.2 – Architecture du GS (source [8]).• la chaîne complète Receive/Transmit (Rx/Tx), depuis les appareils de modulationaux antennes, est représentée en bleu.Le matériel faisant partie du GS est détaillé dans le document [8]. Après unebrève présentation du matériel du GS, voici la liste des logiciels pilotant les élémentsmatériel du GS :OrbitronIl est utilisé pour le tracking du satellite. Connaissant les positions géographiquedes antennes et du satellite, il envoie des informations à la carte detracking qui va corriger la position vers laquelle les antennes pointent ;

CHAPITRE 3. STATION SOL 15ARSWINIl pilote la carte de tracking à partir d’un ordinateur via une ligne parallèle ;WispDDEIl est utilisé pour interconnecter Orbitron avec ARSWIN. Orbitron enverrales informations à propos de la position que doit avoir ARSWIN et ce derniercommuniquera ces données à la carte de tracking pour contrôler les antennes ;TNC SoftwareCe logiciel permet de piloter le Terminal Node Controller (TNC). Le TNC estun appareil qui se connecte par port USB sur un ordinateur et permet l’envoiet la réception de paquets de type AX.25. Le TNC Software agit commeun serveur TCP auquel le MCC se connecte pour communiquer toutes lestélécommandes/télémétries (TC/TM).Les logiciels énoncés ci-dessus permettent l’automatisation du GS. La majoritéde ces logiciels sont des logiciels gratuits développés par et pour la communautédes radioamateurs. Tous ces programmes tournent sous Windows XP. Ces logicielspermettent principalement le tracking automatique du satellite, la correctionautomatique de l’effet Doppler et la communication avec le TNC.Le logiciel Orbitron aura également un autre rôle mais indirect avec le MCC.En effet, étant donné qu’il calcule les prévisions des passes du satellite, il seraégalement nécessaire d’interagir avec lui afin de stocker ces prévisions dans la basede données de mission. Ces informations sur les prévisions des passes du satellitesont nécessaires à l’automatisation du MCC.Des captures d’écran des logiciels énoncés ci-dessus sont présentées à la figure 3.3.3.3 Mission Control Center3.3.1 DescriptionLe MCC est l’endroit où les opérateurs communiquent avec le satellite. Les opérationseffectuées lors des communications avec le satellite sont, par exemple, lavérification des paramètres de santé du satellite, l’activation de la fonctionnalitéD-STAR, la transition vers un mode du satellite, la réalisation de manœuvres,l’activation de l’alimentation expérimentale, etc.Le MCC stocke également toutes les données relatives à la mission (toutes les télécommandeset les télémétries). Rappelons que le satelite a été développé dans unbut éducatif mais également afin de pouvoir mener des expériences dans l’espace.En effet, les données relatives aux charges utiles seront traitées par des scientifiquesmais le reste des données sera utilisé par les opérateurs de la mission. Parexemple, si l’on souhaite vérifier que l’activation de l’alimentation expérimentale aété effectuée avec succès, il suffit de consulter les données correspondant au courantdes cellules solaires stockées dans la base de données de mission.

CHAPITRE 3. STATION SOL 16Figure 3.3 – Captures d’écran de Orbitron, WispDDE et ARSWIN3.3.2 Contraintes3.3.2.1 Contraintes de l’orbitePour les petites missions avec un CubeSat, il est intéressant d’avoir une stationsol totalement automatisée. Les CubeSats sont presque toujours embarqués surdes dispositifs de lancement comme charges secondaires. Par conséquent, ils onttendance à devoir s’adapter avec l’orbite choisie pour la charge utile principaledu dispositif de lancement. Dans notre cas, le CubeSat sera situé dans une orbiteterrestre basse excentrique avec les paramètres suivants :• altitude périgée : 354 km ;• altitude apogée : 1447 km ;• inclinaison : 71 ◦ .Avec ces paramètres, la période orbitale du satellite est de 103 minutes, ce quiveut dire que le satellite fait approximativement 14 révolutions par jour, comprenant3 à 5 passes au-dessus de Liège en moyenne. Des simulations ont été réaliséespour estimer la durée moyenne d’accès de la station au sol (voir [4]), montrant

CHAPITRE 3. STATION SOL 17que le satellite sera visible en moyenne 47 minutes par jour, chacune de ces passesayant une durée moyenne de 14,33 minutes. La durée minimale d’une passe est de7,42 minutes et la durée maximale est de 20,35 minutes. Les durées courtes despasses et leur répartition dans le temps ont pour conséquences :• les décisions lors d’une passe du satellite doivent être prises rapidement afind’échanger le maximum de données,• les opérateurs ne peuvent pas être présents à toutes les passes du satelliteCes problèmes seraient résolus par l’automatisation complète de la station sol.Figure 3.4 – Traces de l’orbite OUFTI-1 durant 12 heures (source :[12])La courte durée des sessions de communication avec le satellite vont influencerfortement la conception du MCC et se traduit par le besoin d’un logiciel decontrôle au sol automatisé. Cette automatisation permet d’envoyer et de recevoirdes données à n’importe quelle heure mais également d’augmenter la quantité d’informationéchangée en éliminant le besoin d’interventions humaine.3.3.2.2 Contraintes du satelliteD’autres facteurs sont à prendre compte lors de la réalisation de la station solcomme les contraintes du satellite. Les contraintes sur le satellite sont beaucoupplus contraignantes que les contraintes applicables au sol. Par exemple, le satellitene dispose pas d’une puissance de calcul équivalente à celle au sol.Les services supportés par le On-Board Software (OBSW) influenceront égalementla station sol, puisque ce dernier devra également les supporter et s’adapterà leurs capacités. Voici une liste des modules et une description brève de ceux-ci :• Le module Measurement est responsable de la prise des housekeeping mesureset d’autres mesures sur le satellite.• Le module Log s’occupe du stockage des données reprises par le module Measurement.• Le module Scheduler programme des actions à effectuer ultérieurement. Ilest essentiel d’avoir un tel module dans le cadre d’une mission comme celled’OUFTI-1 où le temps de visibilité du satellite par jour est faible.

CHAPITRE 3. STATION SOL 18• Le module Monitor prend en charge les fonctions critiques à exécuter indépendamment,tels que le changement de modes de comportement du satellite,l’activation du mode D-STAR, etc.• Le module Clock représente une référence de temps à bord du satellite. Cemodule est utilisé comme référence pour exécuter les opérations planifiées.Cette référence de temps sera téléchargée à toutes les passes du satellite, afinque la station sol puisse faire la corrélation entre le temps à bord et le tempssur terre.• Le module Beacon Interface donne les ordres à la beacon d’envoyer les donnéescritiques.• Le module Communication s’occupe des émetteurs-récepteurs et traite lestrames de communication. Il supporte le décodage des trames D-STAR etAX.25.• Le module Reprogramming est un module optionnel qui n’est pas implémenté.Il permet la reprogrammation du OBSW. Par exemple, la station solpourra mettre à jour le OSBW en mettant un fichier dans sa mémoire.3.3.3 Architecture du MCCL’architecture du MCC doit être conçue en tenant compte des contraintes relativesau satellite, les services qui sont implémentés à bord, etc.Afin de répondre au besoin d’un MCC automatisé, deux logiciels sont développés.Le premier est un scheduler dont le rôle est d’exécuter un ensemble d’opérationslors d’une passe du satellite. Il connaît toutes les passes à venir du satellite etpropose donc à l’utilisateur s’il souhaite exécuter un planning constitué d’un ensembled’opérations lors d’une passe. Le second outil est un outil de planificationdont le rôle est de permettre à l’utilisateur de définir un ensemble d’opérationsreprésentant un planning sous forme de fichiers script. La relation entre les deuxoutils est que le scheduler exécute un fichier script généré par l’outil de planificationlors d’une passe, à condition que l’opérateur ait assigner ce script à une passedu satellite par le biais du scheduler.Il faut également une alternative à cette communication automatisée avec le satellite.En effet, un outil d’envoi manuel de télécommandes est développé dont lebut est de permettre aux opérateurs, s’ils le souhaitent, d’envoyer des télécommandesau satellite lorsque le scheduler est désactivé ou alors qu’aucun planningn’est associé à une passe.Un élément important du MCC est le Mission Control Software (MCS) qui s’occupede la création et l’envoi de télécommandes. En effet, les clients envoientune requête au MCS lorsqu’il souhaite envoyer une télécommande. Un autre rôledu MCS est le stockage des télécommandes et des télémétries passant en sonpoint dans la base de données de mission mais également l’extraction des donnéescontenues dans les télémétries. La base de données de mission contient toutes lesinformations relatives à la mission.

CHAPITRE 3. STATION SOL 19Il est nécessaire de développer un outil permettant la visualisation des donnéesdans la base de données. Cet outil est appelé Mission Data Viewer (MDV).Le lien entre le MCC et le GS se fait par une connexion entre le MCS et unserveur tournant dans le GS. Les télécommandes et les télémétries sont transmispar ce lien.L’architecture du MCC sera développée de manière plus approfondie dans lechapitre 5.

Chapitre 4Automatisation du MissionControl CenterCe chapitre présente aux sections 4.1 et 4.2 les besoins d’un MCC automatisé,les représentations possibles d’un planning et le raisonnement sur le choix de lareprésentation d’un planning. La section 4.3 aborde le cadre de développement desapplications. Les sections 4.4 et 4.5 présentent les outils développés permettantl’automatisation du MCC, leurs responsabilités et leurs fonctionnements.4.1 BesoinsComme mentionné précédemment au point 3.3.2, les contraintes de l’orbite dusatellite ont pour effet que les passes de ce dernier soient de courte durée. Dans l’objectifde maximiser la quantité d’information échangée lors d’une passe du satelliteet d’éviter qu’un opérateur ne doive être présent à chaque passe, l’automatisationdu MCC est nécessaire.4.2 PlanningÉtant donné la courte durée des passes, il est intéressant que les actions qu’onsouhaite exécuter lors d’une passe soient planifiées à l’avance. L’automatisation apour effet l’introduction du concept de planning.Un planning est une série d’actions que l’on souhaite exécuter lors d’une passedu satellite. Une action représente l’envoi d’une télécommande au satellite. Dansun planning, les actions sont reliées entre elles par des liens. Ces liens relient deuxactions et sont constitués de conditions de transition qui sont vérifiées après l’exécutionde l’action source d’un lien. L’action destinataire d’un lien sera exécutéeseulement si les conditions de transition sont vérifiées et ainsi de suite. Il est égalementpossible qu’il y ait plusieurs transitions possible. On considère que la transitionse fera sur le premier lien dont les conditions de transition sont respectées. Unplanning peut être une suite d’actions sans aucune condition de transition entre20

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 21elles, ou alors un scénario complexe où l’exécution de chaque action est conditionnéepar des opérations telles que la vérification de l’état d’exécution d’une autreaction, la comparaison de la valeur d’une mesure à bord du satellite récupérée etstockée dans la base de données de mission avec une certaine valeur, etc.La figure 4.1 représente un schéma d’un planning de façon conceptuelle.Figure 4.1 – Schéma conceptuel d’un planningEn pratique, un planning pourrait être la suite d’opérations suivantes. La premièreaction serait de demander au satellite l’envoi de mesures dans l’objectif dedéterminer son état de santé. Des conditions de transition vers une autre actionpeuvent être la comparaison des valeurs reçues à des seuils. Si les conditions sontvérifiées, l’action suivante sera d’activer l’alimentation électrique expérimentale.Après l’exécution de cette action, on peut vérifier si les valeurs des mesures relativesà l’alimentation électrique expérimentale sont normales. Si elles ne le sontpas, une action se chargera de désactiver l’alimentation électrique expérimentale.Si elles le sont, on peut laisser le satellite s’alimenter avec l’alimentation électriqueexpérimentale. La transition entre deux actions peut être constituée d’aucunesconditions de transition. Ensuite, une action qui peut être exécutée est l’activationdu mode D-STAR dans l’objectif de préparer une communication entre deuxradioamateurs. Après la communication D-STAR, une action sera de changer lemode de comportement du satellite avant que celui-ci soit hors de portée de lastation sol.4.2.1 Représentation d’un planningUn problème s’est présenté lors du choix de la représentation d’un planning. Eneffet, le choix de sa représentation aura un impact sur toute l’implémentation desoutils intervenant dans l’automatisation du MCC, ces outils sont décrits plus tarddans le chapitre.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 22Deux solutions de base ont été considérées. La première solution consiste à l’utilisationd’un langage de script permettant l’automatisation de tâches. La secondeserait d’utiliser un langage standard permettant facilement le transfert d’information.Il est également préférable que les langages utilisés dans ces solutions soientfortement utilisés pour la portabilité, l’apprentissage du langage par les opérateurs,la documentation et les outils à disposition pour travailler avec.Un planning à exécuter lors d’une passe peut être représenté par :• Un script Python ;• Un fichier eXtensible Markup Language (XML).Comme mentionné ci-dessus, un planning peut être un scénario complexe d’opérationsà effectuer. C’est pourquoi il est intéressant d’analyser ces deux solutionsafin de déterminer celle qui permettra de définir les plannings les plus flexiblestout en essayant de garder un aspect “user-friendly”. Malheureusement ces deuxcaractéristiques sont généralement concurrentes, il faut choisir ou adapter une desdeux solutions afin qu’elle soit un compromis entre ces deux caractéristiques. Dansles sections suivantes, une analyse des deux représentations d’un planning va êtreprésentée. Cette analyse regroupera les avantages et les inconvénients des solutions.4.2.1.1 Script PythonLa première solution serait qu’un planning soit défini par un script Python. Lelangage Python est un langage de programmation interprété de plus en plus utilisé,il est même utilisé comme langage d’apprentissage à la programmation à l’Universitéde Liège. Il peut être utilisé comme un langage de script afin d’automatiserdes tâches.Avantages. L’avantage d’utiliser un planning représenté par un script Pythonest qu’elle permet une flexibilité considérable aux niveaux des actions d’un planninget des transitions entre ces actions. Typiquement, une action d’un planningreprésente l’envoi d’une télécommande et une transition, un ensemble de conditionsà vérifier afin de pouvoir transiter vers une nouvelle action. Dans le cas dela solution envisagée ici, l’utilisateur aurait la possibilité de définir des scénarioscomplexes incluant des conditions complexes pour le déclenchement d’une certaineaction telle que le nombre d’essais de l’envoi d’une télécommande avant de passerà une autre action, la comparaison de la valeur d’une mesure par rapport à uncertain seuil, etc.Un autre avantage est que l’utilisation de cette solution rendra l’implémentationdu scheduler simple. Le scheduler est l’élément essentiel à l’automatisation duMCC. Son rôle est d’exécuter les plannings définis par les opérateurs aux passes dusatellite. Puisque les opérations complexes et la logique d’exécution du planningsont contenues dans le script, la tâche principale du scheduler sera « juste » delancer ces scripts aux bons moments. Des interfaces jouant le rôle de librairies

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 23pour les scripts Python sont définies selon les télécommandes et les télémétriesque les opérateurs peuvent envoyer ou recevoir.Inconvénients. En contrepartie, les utilisateurs devront écrire un fichier scripten Python et donc avoir une connaissance du langage Python. La flexibilité dansla conception des plannings a pour effet de rendre le système moins “user-friendly”.Un autre inconvénient est qu’une telle flexibilité lors de la conception de planningspeut ne pas être nécessaire. En effet, les courtes durées des passes ne permettentpeut-être pas aux opérateurs d’élaborer des scénarios complexes. Ces scénariosseront fortement similaires commençant par l’essai d’établir le contact avecle satellite et le téléchargement de certaines mesures du satellite afin de vérifierl’état du satellite. Ces étapes indispensables réduisent le temps de communicationavec le satellite et donc diminuent le nombre d’actions possibles pour les opérateurs.Toutefois, le facteur “user-friendly” peut être atténuer en proposant des modèlesde planning à l’utilisateur afin de favoriser l’adaptation à cette solution.Une autre solution pour que la solution n’ait plus le défaut de ne pas fournir unaspect “user-friendly” est de développer un outil de planification. Cet outil proposeraà l’utilisateur de définir le planning qu’il souhaite. L’aspect “user-friendly”sera garanti par la possibilité de pouvoir visualiser le planning défini sous forme degraphe. L’utilisateur n’aura également pas besoin de connaître le langage Pythoncar l’outil de planification générera le code Python à partir du planning conçu parl’utilisateur via ce logiciel.Il est toujours préférable d’avoir la possibilité de concevoir des plannings complexes,même si cela s’avère peut-être pas nécessaire. Cette solution pourra êtreapplicable à un autre satellite dont les durées des passes sont plus longues.4.2.1.2 Fichier XMLLa seconde solution serait d’utiliser un fichier XML afin de représenter un planning.Pourquoi un fichier XML ? Le langage XML est un langage informatique destructuration générique des données à l’aide de balises. Le langage est typiquementutilisé pour stocker des données dans une structure d’arbre. C’est un langagefortement utilisé dans le monde et donc nous a semblé être une solution à envisager.Les actions et les conditions de transitions d’un planning seraient encodées dansle fichier XML pour être traitées dans le scheduler qui s’occupera de l’exécutiondu planning.Avantages. Un avantage est que le langage XML est un standard fortementutilisé. Les données dans un fichier XML, structurés en champs arborescents, permettentplus facilement la visualisation du planning et l’exécution d’un planningpourrait se résumer au parcours d’un arbre de la racine vers une feuille. Les outilspermettant de traiter ce genre de fichiers ne manquent pas, tels que JDom,Dom4j, JAXP, Xerces-C++, etc. Les fichiers XML pourraient être également gé-

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 24nérés à partir d’un outil de planification proposant une interface graphique afin derendre le système “user-friendly”.Inconvénients. Le développement du scheduler sera moins simple par rapportà la solution où un planning est représenté par un script Python. En effet, lorsd’une passe du satellite, le scheduler devra analyser le fichier XML et exécuter lesactions. Par conséquent, les actions et les conditions de transition d’un planningseront limitées à ce qui a été fixé à la conception du scheduler. Par exemple, siun opérateur souhaite définir une condition de transition qui n’a pas été pris encompte lors de la conception, il n’y aura aucun moyen de supporter cette conditionde transition, à moins d’aller modifier le programme. Tandis que dans le cas duscript Python, c’est le script Python qui se charge de d’exécuter cette conditionde transition et non le scheduler qui n’a pas besoin de connaître l’ensemble desconditions de transition qui peuvent être effectuées.La condition d’utilisation de cette solution est d’avoir une liste exhaustive desactions et des conditions de transition qui pourraient être planifiées lors d’unepasse du satellite.Solution hybride. Une autre solution qu’on aurait pu considérer est celle utiliséepar l’équipe SwissCube de l’École Polytechnique Fédérale de Lausanne.Dans cette solution, un planning est représenté par un fichier XML. Une actionest un script Python qui utilise l’ensemble des télécommandes mises à dispositionpar le MCS et accède au contenu d’une télémétrie en temps réel afin de connaîtrel’état d’exécution de la télécommande envoyée. L’exécution d’une action peut êtreun succès ou un échec. Deux autres actions sont liées aux résultats de l’exécutiond’une action. La logique d’exécution derrière les scénarios de l’équipe SwissCubeest simple et léger. Un schéma d’un planning où les actions sont conditionnées parun succès ou un échec est représenté à la figure 4.2.Un exemple d’action typique dans un de leurs plannings est la récupération desparamètres de santé du satellite qui se traduit par l’envoi de télécommandes pouractiver la récupération de ces paramètres. Cette action est un succès si les valeursont bien été reçues et stockées dans la base de données et est un échec si aucunevaleur n’a été reçue. L’action pouvant suivre dans le cas d’un succès peut êtrel’activation du mode D-STAR et dans le cas d’un échec, une nouvelle exécutionsupplémentaire de l’action.La solution est une solution hybride basée sur les deux solutions décrites cidessus.Elle ne nous a pas semblé appropriée parce que la logique d’exécutiond’un planning doit être gérée par le scheduler, ce qui rend son implémentationfastidieuse et il faut également avoir pris en compte tous les cas possibles lors deson développement. Les scripts contenant des actions seraient également courts,étant donné qu’il contiendrait juste des opérations d’accès à des télémétries etd’envois de télécommandes.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 25Figure 4.2 – Schéma planning de l’équipe SwissCube4.2.1.3 Choix représentation d’un planningL’analyse des solutions pèse le pour et le contre de chaque solution et sert debase au choix de la solution utilisée au final.Rappelons que l’objectif est de trouver un compromis entre la flexibilité desplannings et l’aspect “user-friendly”, cet objectif pointe vers la solution où lesplannings seraient représentés par des scripts Python.La solution permet une grande flexibilité dans la conception de plannings etfacilite le rôle du scheduler. L’aspect “user-friendly” serait atteint, comme mentionnédans la section 4.2.1.1, à l’aide d’un outil de planification qui générerait desscripts Python et fournirait une interface graphique à l’utilisateur pour la créationde plannings. La solution d’utiliser un script Python pour représenter un planningremplit les deux caractéristiques tandis que l’utilisation d’un fichier XML ne lesremplirait pas. L’utilisation de fichier XML ne permettrait un tel degré de liberté,comparé aux scripts Python.Avec la solution choisie et à l’aide d’un outil de planification, les utilisateursconnaissant ou non le langage Python pourront construire des plannings qui pourrontêtre exécutés lors des passes du satellite.La différence est que les utilisateurs connaissant le Python pourront créer desplannings d’un niveau de complexité plus élevé que ceux utilisant l’outil de planification.En effet, ces derniers seront limités aux actions proposées par le logiciel.Toutefois, rien n’empêche d’intégrer petit à petit les actions qui ont été oubliéesdans l’outil de planification.Il sera également possible de sauvegarder et de réouvrir des anciens plannings.Si un planning a été écrit par un utilisateur, le logiciel sera dans l’incapacité dereconstruire le graphe représentant le planning. Les scripts Python générés par lelogiciel contiendront des « patterns »permettant au logiciel lors l’ouverture d’unplanning généré de reconstruire l’instance du planning correspondant et donc degénérer le graphe du planning.Un script Python généré pourrait également être utilisé par un utilisateur quisouhaite ajouter quelques actions en plus dans le script. Dans ce cas-là, si onsouhaite charger ce fichier, l’outil de planification générera le graphe représentant

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 26le planning à partir des informations qu’il a su extraire et mentionnera les lignesde code que l’utilisateur a introduit et dont il n’a pas été possible de traiter.Les plannings auraient pu être sauvegardés sous forme d’objets “serialisés” cependantl’ajout d’actions supplémentaires dans un planning généré aurait été impossible.4.3 Langage de développementLes logiciels faisant partie du MCC sont développés dans le langage de programmationJava, utilisant les Application Programming Interface (API) telles queJava DataBase Connectivity (JDBC), Java Remote Method Invocation (RMI),etc. Une des raisons de l’utilisation de ce langage est également due au fait quecertains modules développés l’année passée ont été réalisés en Java. Les interfacesgraphiques des applications développés ont été réalisées avec l’environnement dedéveloppement intégré NetBeans 6.8 et de la librairie graphique Swing.4.4 SchedulerLa section précédente 4.2 a montré la nécessite d’avoir un planning pour l’automatisation.Cependant, il a été mentionné plusieurs fois l’outil scheduler sansdécrire vraiment à quoi il sert. Le scheduler est un un logiciel qui sert à exécuterdes plannings lors des passes du satellite. Dans la section 4.4.1, le scheduler seradécrit complètement ainsi que les détails de son implémentation.4.4.1 DescriptionLorsqu’un opérateur souhaite exécuter un planning lors d’une passe du satellite,il faut qu’il y ait un module qui s’occupe de lancer un planning lorsque le contactpeut être établi avec le satellite. Ce module porte le nom de scheduler.Cet outil a connaissance de toutes les passes à venir du satellite grâce aux calculsdu programme Orbitron décrit à la section 3.2.3. Le programme Orbitron peutproduire un fichier texte contenant des informations sur les prévisions des passesdu satellite, telles que l’Acquisition of Signal (AoS), le Loss of Signal (LoS), ladistance du satellite, l’élévation du satellite, etc. Ce fichier sera analysé et lesdonnées extraites relatives aux passes du satellite seront stockées dans la base dedonnées de mission.Le scheduler est un programme qui fonctionnera en permanence en arrière-plan ;ce type de programme est appelé daemon ou démon. Son rôle principal est de lancerles scripts représentant les plannings d’actions que l’utilisateur souhaite exécuterlors des passes du satellite.L’utilisateur a à sa disposition une interface graphique pour interagir avec ledémon. Cette interface graphique affiche à l’utilisateur l’ensemble des passes àvenir et ceux qui sont déjà effectuées.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 27Le programme propose à l’utilisateur les actions suivantes :• Assigner un planning à exécuter à une certaine passe ;• Consulter un rapport d’exécution d’un planning d’une ancienne passe ;• Rafraîchir les deux listes, celle des passes à venir et celle des anciennes passes.Le logiciel affichera à l’utilisateur les passes à venir dans une limite raisonnableet rafraîchira la liste des passes à venir au fil du temps.Si aucun script Python n’est associé à une passe, aucune opération est effectuée.Dans le cas où aucun planning n’est associé une passe, cela peut vouloir dire quel’utilisateur souhaite envoyer les télécommandes manuellement. L’utilisateur peutégalement couper le scheduler et le redémarrer ensuite s’il le souhaite.La fonctionnalité de pouvoir consulter un rapport d’exécution d’un planning associéà une ancienne passe permet à l’utilisateur de connaître le chemin d’exécutionque le planning a effectué.Par défaut, le rafraîchissement des tables contenant les passes se font à intervallesréguliers mais l’option de rafraîchissement manuel est également proposée.4.4.2 ImplémentationL’implémentation du scheduler est basée partiellement sur deux classes de l’ApplicationProgramming Interface (API) Java, les classes Timer et TimerTask.La classe Timer permet aux threads de planifier des tâches à exécuter ultérieurement.Elle permet la planification de tâches à exécution à intervalles réguliers ouà exécution unique. L’instance de Timer est un thread tournant en arrière-plan quiattend d’avoir des tâches à exécuter et exécute ces tâches aux heures spécifiées lorsde leurs insertions. Les tâches sont exécutées de manière séquentielle. Donc, si lestâches se chevauchent, alors la seconde tâche ne sera pas exécutée tant que la premièren’a pas fini son exécution. Cela ne posera sans doute pas de problèmes dansle cadre de la mission OUFTI-1, vu que l’espace entre deux passes successives estassez important. Mais il est également possible également d’insérer un mécanismequi s’occupera de couper une tâche planifiée en cours d’exécution afin que la tâcheplanifié suivante ne soit pas en retard sur son exécution. Le thread de l’instanceTimer peut être configuré pour tourner en tant que démon. Celui-ci ne se couperapas tant que le processus principal tourne. Cette classe correspond parfaitement àce qu’on désire effectuer dans le cas du développement du scheduler.La classe TimerTask permet de créer des objets représentant des tâches quiseront exécutées une fois ou à plusieurs reprises. Les instances de cette classe sontassociées à une instance de Timer. L’instance Timer se chargera de lancer les objetsTimerTask à la date spécifiée lors de leurs insertions.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 284.4.2.1 FonctionnementDans cette section, les principales opérations du scheduler sont présentées sousforme de diagramme (figure 4.3). Le diagramme ne montre que la partie autonomedu scheduler et non la partie interaction avec l’utilisateur.Figure 4.3 – Flowchart du schedulerLe fonctionnement du scheduler avec l’utilisateur est le suivant. L’utilisateurpeut, à partir de l’interface graphique, associer un planning à exécuter lors d’unepasse du satellite. Lorsqu’un planning a été associé à une passe du satellite, leprogramme ajoute une tâche à effectuer à l’heure correspondante de la passe venantjuste d’être associée avec un planning dans l’instance Timer. Le thread de l’instanceTimer se chargera d’exécuter la tâche à l’heure donnée. La tâche lancera le scriptPython spécifié contenant le scénario d’actions défini par l’utilisateur. Les tâchesqui sont ajoutées à l’instance Timer sont la plupart similaires, à l’exception prèsque leurs dates d’exécution diffèrent. Rien n’empêche d’exécuter le même scriptplusieurs fois, surtout que la majorité des scripts auront une partie commune quiest d’établir le contact et la vérification des paramètres de santé du satellite.Les tableaux contenant les anciennes passes et à venir sont rafraichis à intervallesréguliers (constante définie dans le programme). Le nombre maximum de passesaffichées par le programme et le nombre maximal de tâches ajoutées dans la filede tâches à exécuter de l’instance Timer sont également des constantes au sein duprogramme.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 294.4.2.2 Interface graphiqueUne capture d’écran de l’interface graphique développée pour le scheduler estprésentée à la figure 4.4. L’interface graphique est constituée principalement dedeux onglets. Chacun des onglets affiche une table : un affiche la table des passes àvenir et l’autre, la table des anciennes passes. Aucun bouton visuel n’a été intégréà l’interface, tout passe par des clics droits sur les éléments des tableaux. Lapossibilité de voir le chemin d’exécution d’un planning n’est disponible que pourles anciennes passes.Figure 4.4 – Capture d’écran du scheduler4.4.3 TestÉtant donné la faible complexité et le faible nombre de fonctionnalités du scheduler,les tests ont été rapides. Les tests réalisés sur l’outil, tant au niveau interfacegraphique que fonctionnement, ont été réalisés avec succès. Le programme a ététesté avec des milliers de tâches à exécuter pendant une journée entière. Ce test permetégalement de vérifier si la mémoire consommée par le programme n’augmentepas indéfiniment jusqu’à atteindre la mémoire maximale de la machine virtuelleJava. Ce type de test est essentiel pour ce genre de logiciels car il devra sûrementfonctionner constamment lors de la mission OUFTI-1. Au départ, les tâches planifiéesétaient des écritures de fichiers. Après développement des plannings sousforme de scripts Python, les tâches planifiées consistaient en l’exécution des fichiersscript.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 30Un exemple de test consistait à assigner des scripts Python à des passes dusatellite espacées de 10 secondes. Après assignation de plannings à des passes, onvérifiait que le scheduler exécutait bien les scripts Python aux heures des passesassociées à des scripts.Un autre type de test a été également effectué afin de tester les accès aux informationssur les prévisions des passes du satellite générées par Orbitron dans labase de données de mission. Ces tests consistaient à aller chercher les informationssur les passes du satellite dans la base de données et de remplir les tableaux despasses à venir qui sont affichées aux opérateurs. La base de données de mission estdécrite au chapitre 6.4.5 Outil de planificationDans cette section, l’outil de planification, mentionné dans la section 4.2, estdécrit plus en détails, c’est-à-dire les fonctionnalités de ce dernier, ses différentsmodules et son implémentation. Le rôle de l’outil de planification est la générationde scripts Python représentant des plannings définis par un opérateur.4.5.1 DescriptionL’outil de planification permet la génération de scripts Python. Ces scripts représententdes planning contenant des scénarios d’actions à exécuter. L’utilisateurn’aura plus qu’à utiliser le scheduler pour assigner le script qu’il vient de générer àune ou plusieurs passes du satellite. Grâce à ces outils, la présence des opérateursà toutes les passes du satellite n’est plus nécessaire et la quantité d’informationéchangée est maximale.Cet outil est constitué d’une interface graphique permettant de respecter l’aspect“user-friendly” lors de la construction d’un planning. En effet, l’utilisateur pourraafficher s’il le souhaite le graphe représentant le planning qu’il est en train deconstruire.L’outil de planification est également utile pour les personnes ne connaissantpas le langage en Python ou alors qui n’ont pas envie de l’apprendre. Par contre,comme mentionné à la section 4.2, les scripts Python générés sont de complexitélimitée. Toutefois, il est tout à fait possible d’écrire son propre script permettantainsi une grande flexibilité dans la logique d’exécution des actions d’un planning. Ilest également possible de compléter un script généré par des lignes de code propresà l’utilisateur. Cependant, il faut que l’utilisateur, avant d’écrire le script, prenneconnaissance des fonctions disponibles pour communiquer avec le satellite.L’outil de planification n’est pas un processus tournant en arrière-plan. On ledémarre que lorsqu’on a besoin de créer un planning.L’utilisation typique est la suivante :1. L’utilisateur lance l’outil de planification,2. Il construit un planning,

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 313. Ensuite, il demande au logiciel de générer le script Python correspondant auplanning défini,4. Finalement, il ouvre le scheduler et assigne le script Python à une ou plusieurspasses du satellite.Il est intéressant également de faire remarquer qu’il est possible de faire des modèlesde base pour les plannings car certaines opérations seront toujours exécutéeslors d’une passe du satellite (par exemple, la vérification des paramètres de santédu satellite, etc.). Par exemple, on pourrait construire un planning de base reprenantles opérations qui sont exécutées à toutes les passes du satellite. À partir de cemodèle de base, l’utilisateur ajouterait les actions supplémentaires qu’il souhaiteeffectuer ; ainsi, il ne perdrait pas son temps à redéfinir ces actions répétitives.Il sera également possible de catégoriser les différents types de plannings selonles scénarios d’actions. Par exemple, un groupe pourrait reprendre les planningsdont le but est l’activation du mode D-STAR, un autre serait l’activation de l’alimentationexpérimentale et l’analyse des paramètres relatives à cette alimentation,etc.4.5.2 Les modules de l’outil planificationL’outil de planification peut être décomposé en cinq différents modules de façonconceptuel. Les cinq modules sont les suivants :• Planning,• Générateur de code,• Parser,• Afficheur de plannings,• Interface graphique.Ces modules faisant partie de l’outil de planification sont décrits dans les sectionssuivantes.4.5.3 Module planningCe module représente le projet de planning en cours, c’est-à-dire le planning surlequel l’utilisateur est en train de travailler en utilisant l’outil de planification.Un planning est constitué d’un ensemble d’actions et de transitions entre cesactions.Les actions sont les télécommandes possibles qui peuvent être envoyées par lastation sol. Les différentes télécommandes que la station sol peut envoyer au satellitesont décrites à la section 7.2. Les opérateurs devront bien connaître lesdifférentes télécommandes et télémétries afin de pouvoir interagir avec le satellite.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 32En effet, l’ajout d’une action peut se résumer à la complétion des différents champsdu paquet dans la télécommande.Les transitions entre les actions peuvent être représentées sous la forme de liens.Un lien entre deux actions peut être accompagné d’un ensemble de conditions àrespecter pour pouvoir passer de l’action source à l’action destination. Un planningpeut être vu comme un graphe. Les cycles dans un planning sont autorisés. Unlien entre deux actions peut être dépourvu de conditions de transition. Deux liensdans le même sens reliant les mêmes actions sont interdits.Les conditions de transition sont limitées aux valeurs des mesures à bord dusatellite téléchargées dans la base de données. Un exemple d’utilisation de cesconditions serait l’activation de l’alimentation expérimentale au début d’un planninget ensuite, la vérification des valeurs du courant de cette alimentation et siles valeurs sont mauvaises et néfastes au satellite, une action sera de désactiverl’alimentation expérimentale. Si les valeurs sont bonnes, une action en sortie serade laisser le satellite fonctionner sur l’alimentation électrique expérimentale. Laliste des mesures prises à bord du satellite se trouve dans l’annexe A. Les outilsdéveloppés dans le cadre de ce travail de fin d’études se sont basés sur cette liste.Il est important de faire remarquer qu’un mécanisme de tentatives d’envoi detélécommandes au satellite a été mis en place. En effet, il faut prendre en considérationqu’il soit possible d’avoir des problèmes de communication avec le satellite,tels qu’un mauvais positionnement des antennes à la station sol, un non acheminementdes données entre le satellite et la station sol, etc. Le mécanisme de tentatived’envoi de télécommandes renvoie une télécommande tant qu’il n’a pas reçu l’acquittementque celle-ci a été exécutée. Le mécanisme est configuré tel quel pourl’instant mais il est également possible d’intégrer la fonctionnalité où l’opérateuraurait la possibilité de spécifier le nombre de fois que la télécommande doit êtreenvoyée avant de passer à une autre action. Cette configuration par défaut peutêtre problématique dans le cas où l’opération est d’incrémenter un compteur maispas dans les cas où on active un élément qui est déjà activé.4.5.4 Module générateur de codeLe module générateur de code a la responsabilité de traduire un planning conçupar l’utilisateur en un script Python, mais pas n’importe quel type de scriptsPython. En effet, l’idée qui a voulu être développée ici est que les scripts pourraientêtre réutilisés ultérieurement. Typiquement, un script généré par un utilisateurpourra être rechargé dans le programme et être généré de nouveau avec de nouvellesmodifications si l’utilisateur en a fait. Cette possibilité de réutiliser les scriptsgénérés par l’outil de planification a pour conséquence, implicitement, de devoirmettre un mécanisme permettant de reconstruire une instance planning à partird’un script Python.4.5.4.1 Réutilisation des plannings générésDeux mécanismes sont possibles. Une analyse des solutions est faite ci-dessous.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 33La première solution est de construire un analyseur syntaxique capable de reconstruirel’instance planning en analysant le code du script Python. Il est évidemmenttrès fastidieux de développer un tel outil, même si la structure des lignes de codegénérés est statique. Il y aurait beaucoup de cas à prendre en compte, comme parexemple le cas où l’utilisateur changerait le script Python. La robustesse seraitdifficile à supporter.La seconde solution est de définir un langage qui décrirait un planning. Le planningserait défini dans ce langage et placé dans l’en-tête du fichier Python. Lastructure du fichier Python serait donc un bloc de commentaires dans lequel leplanning est défini dans le langage qu’on définit nous-mêmes et ensuite, le codedu script. Le langage est simple : il permet aux utilisateurs de comprendre rapidementce que fait le planning et également qu’un analyseur syntaxique le traitefacilement.C’est la seconde solution qui a été choisie. Afin de supprimer tout souci de robustesse,une valeur de hachage sera calculée à partir de l’en-tête représentant leplanning dans le langage défini et sera ajoutée au début de cet en-tête. L’authentificationn’est pas ici l’objectif de l’utilisation d’une fonction de hachage mais desimplement de détecter si une personne a modifié l’en-tête. La fonction de hachageutilisée est le Secure Hash Algorithm 512 (SHA-512).Si une modification a eu lieu au niveau de l’en-tête, l’outil de planification refuserade travailler avec le script que l’utilisateur voulait charger au sein du programme.4.5.4.2 FonctionnementLa figure 4.5 représente les étapes générales de la génération de code.Figure 4.5 – Flowchart de la génération de codeLe corps du script Python aura la structure suivante. En premier lieu, les importsnécessaires seront effectués (archives java propres au projet, librairie standard java,

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 34...). Les scripts Python utilisent des classes Java et cela grâce à l’utilisation de latechnologie Jython. Jython est décrit à la section 4.5.8.1. Ensuite, étant donné quele script Python joue le rôle d’un client dans le MCC, il faut établir une connexionavec le MCS. Cette connexion est indirecte car il y a un intermédiaire entre le scriptPython et le MCS. La raison d’un intermédiaire est expliquée à la section 4.5.8.Après l’établissement de la connexion entre le script Python et le MCS, les envoisde télécommandes dans le planning vont démarrer. Chaque action définie dans leplanning sera écrite sous forme de fonction. Les conditions de transitions entreles actions se trouvent également dans les fonctions. Ensuite, un dictionnaire estdéfinie avec des paires dont la clé est l’identifiant de l’action et la valeur, la fonctioncorrespondante. Et pour finir, une boucle se chargera de lancer le planning.Le principe est que lors de chaque appel à une fonction, un index est modifié etlors du début de chaque itération de la boucle, la fonction correspondante à l’indexest exécutée.4.5.5 Module parserLe module parser a le rôle d’analyser les scripts Python que l’utilisateur souhaitecharger au sein du programme et de construire l’instance du planning correspondant.Comme mentionné au point précédent 4.5.4.2, si l’utilisateur change quoi que cesoit dans l’en-tête du fichier ou que des lignes de code générées ont été enlevées oumodifiées, le programme refusera de charger le planning.Étant donné le langage défini et fixé pour définir un planning, des expressionsrégulières ont été développées en fonction du langage pour traiter l’en-tête dufichier. Une instance planning sera construite au fur et à mesure de l’analyse dufichier.Le module parser est utilisé lors des opérations de chargement d’un planning àpartir d’un fichier script Python.Les étapes essentielles qui sont effectuées sont les suivantes :1. Extraction de la valeur de hachage au début de l’en-tête, calculer la valeurde hachage de l’en-tête en enlevant la ligne contenant la valeur de hachageet comparer leurs valeurs.2. Si les valeurs ne sont pas égales, l’utilisateur sera notifié qu’il n’est pas possiblede charger le fichier source.3. Si les valeurs sont égales, la construction du planning à partir de l’en-tête sedéroule.4. À partir du planning construit, on va créer un fichier temporaire contenantle code généré correspondant au planning.5. Comparaison du fichier temporaire et du code dans le fichier source afinde déterminer les lignes non-générées par le programme et donc venant des

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 35utilisateurs. Il est possible également qu’à ce stade le programme refuse decharger le planning car l’utilisateur a supprimé ou modifié des lignes de codegénérées.La figure 4.6 montre l’exécution du module parser lors d’un chargement d’unfichier.Ce module est tout à fait utile pour les cas où un utilisateur, après avoir généréun planning, souhaite encore modifier ce dernier via l’outil de planification ; parexemple, pour redéfinir une seule action de ce planning. Cela évite de reconstruireun planning en entier.C’est également un élément intervenant dans la visualisation de plannings sousforme de graphes. En effet, lorsqu’un utilisateur souhaite charger un script Python,le module parser construit l’instance planning correspondant et le module afficheurde plannings se base sur cette instance pour la construction du graphe. Le moduled’affichage de plannings sera expliqué à la section suivante.Il est également possible de charger les scripts générés dont certaines lignes decode ont été ajoutées par l’utilisateur dans l’outil de planification mais seuls leséléments reconnus seront affichés. Néanmoins, les lignes de code introduites parun utilisateur seront quand même affichées par l’outil de planification dans unefenêtre spécifique.4.5.6 Module afficheur de planningsLe module d’affichage de plannings permet à l’utilisateur de visualiser le scénariod’exécution qu’il conçoit. Son utilité vient de la raison qu’il n’est pas évidentde s’y retrouver avec des tableaux d’actions et de liens, surtout quand ceux-cisont nombreux, et également pour respecter l’aspect “user-friendly”. Néanmoins,ce module n’est pas activé par défaut : l’utilisateur peut tout à fait faire sans s’ille désire.La construction du graphe se base sur le planning conçu où chaque action estreprésentée par un noeud et chaque transition par un lien. Les noeuds sont accompagnésd’un texte décrivant l’action : identifiant de l’action, le type de télécommandeenvoyée, etc. Les liens sont juste accompagnées de leurs identifiants afin dene pas trop surcharger le graphe. Par exemple, si un utilisateur souhaite modifierun lien, il a juste à regarder l’identifiant afin de modifier ce lien.Il existe de nombreuses librairies externes qui sont conçues pour la génération degraphes, telles que JFreeCharts, Java Universal Network/Graph (JUNG), JGraph,etc. La bibliothèque de génération d’organigrammes et de schémas, JGraph, a étésélectionnée car elle est la plus utilisée pour ce genre de développement et proposedes algorithmes d’organisation des graphes pour une meilleure vue des graphes.4.5.7 Module interface graphiqueCe module représente le programme principal puisque tous les modules sont reliésà celui-ci. Dans cette section, les responsabilités du module vont être décrites, des

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 36Figure 4.6 – Flowchart du chargement d’un fichier sourcescénarios typiques d’utilisation vont être présentés avec les modules décrits cidessuset une capture d’écran du programme sera fournie.Les responsabilités du module est d’interagir avec les utilisateurs et que les différentsmodules décrits ci-dessus se communiquent entre eux quand il le faut.La conception via l’outil de planification est basique. En effet, le logiciel propose,

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 37pour la construction d’un planning, deux options : l’ajout d’une action ou d’unlien.Il propose également la possibilité de voir le planning en cours de traitement sousforme de graphe. Lorsque l’utilisateur active cette fonctionnalité, le module d’affichagede plannings construit le graphe sur base du planning courant en construction.À chaque ajout d’une action ou d’un lien au planning, cette fenêtre affichantle graphe est rafraîchie.La fonctionnalité essentielle est la génération de code sur demande de l’utilisateur.Le programme demandera, à chaque fois, où l’utilisateur souhaite enregistrerle script Python.Un exemple typique d’utilisation serait qu’un utilisateur conçoit un planning,demande la génération de code et assigne le script généré à une passe grâce auscheduler décrit à la section 4.4. Il est fort probable que les types de planningne soient pas si nombreux. Après un certain temps de communication avec lesatellite, l’opération la plus effectuée avec l’outil de planification sera probablementle chargement de plannings dont il faut juste modifier certains paramètres desactions car un répertoire de plannings aura été constitué.La figure 4.7 présente une capture d’écran de l’outil de planification développépour OUTFI-1.Figure 4.7 – Capture d’écran de la fenêtre principale de l’outil de planification4.5.8 Communication entre scripts Python et MCSCette section donne une description de Jython et son rôle dans la communicationentre les scripts Python et le MCS. Il sera également abordé l’interface de communicationentre les scripts Python et le MCS mais brièvement. La communication

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 38entre les clients et le MCS dans l’architecture du MCC sera expliquée en détailsdans le chapitre suivant.4.5.8.1 Description de JythonJython permet l’utilisation des technologies Java avec le langage Python. C’estun interprète Python qui est développé en Java afin de permettre l’intégration dela machine virtuelle Java.Ses principales fonctionnalités sont les suivantes :• La compilation de code Python en bytecode Java.• Hériter des classes Java en Python.• Pouvoir manipuler les objets Java.• Il permet également l’inverse donc d’utiliser des modules Python et la syntaxedans des programmes Java.• Jython a été développé entièrement en Java (portabilité).4.5.8.2 Utilisation de JythonÉtant donné que le MCS est développé en Java, il nous faut un moyen de communicationentre les scripts Python et le MCS. Ce moyen de communication estla technologie Java RMI qui sera expliquée au chapitre suivant. Cependant, pourutiliser le langage Java dans le langage Python, il est nécessaire d’utiliser Jython.Il est possible d’utiliser des classes de la librairie Java standard mais égalementdes classes propres au projet.Un module a été développé pour faire l’intermédiaire entre le script Pythonexécuté et le MCS afin de ne pas augmenter la complexité des scripts Python.En effet, cela permet d’avoir une certaine transparence pour la gestion de JavaRMI au niveau des scripts Python. La demande d’envoi de télécommandes passerapar donc par ce module qui se chargera d’acheminer ces requêtes vers le MCS. Cemodule est en quelque sorte un client spécifique pour les plannings. La personne quivoudra écrire son propre script Python devra être conscient des fonctions fourniespar ce client intermédiaire et connaître l’utilisation de Jython.Comme mentionné au point 4.5.3, les conditions de transition sont limitées auxaccès à la base de données. Toutefois, il est également possible d’étendre le domainedes conditions de transition. Il faut, par conséquent, que le client spécifique auxplannings intègre des fonctions permettant d’aller consulter des valeurs dans labase de données de mission. Ces fonctions ont été définies pour juste obtenir ladernière valeur des mesures à bord du satellite. L’API Java utilisée pour accéderà la base de données de mission est JDBC.

CHAPITRE 4. AUTOMATISATION DU MISSION CONTROL CENTER 394.5.9 TestLes tests ont été effectués d’abord isolément sur les modules constituant l’outilde planification.Les tests sur le générateur de code consistaient généralement à voir si les scriptsPython générés étaient valides.Le module parser a été longuement testé pour vérifier que les expressions régulièressoient bien correctes dans l’objectif de pouvoir reconstruire l’instance planningà partir de l’en-tête et afin de tester les mécanismes de comparaison de fichiers(valeurs de hachage et détection de lignes de code entrelacées). Un exemple de testconsistait en le chargement d’un script Python généré mais légèrement modifié parun utilisateur au sein du programme, dans l’objectif de vérifier le bon chargementd’un planning, la détection des lignes provenant de l’utilisateur et la visualisationdu graphe correspondant au planning.L’affichage de plannings a été testé avec des graphes constitués d’un nombreimportant de noeuds et de liens. Il a été également testé après un chargementd’un script Python dans l’objectif de visualiser le graphe représentant le planningcorrespondant.Le module planning est le plus important de tous car les autres modules se basenttous dessus. Les tests sur ce module ont été réalisé rigoureusement de telle sortequ’il n’y ait aucun problème lors de la mise en relation avec les autres modules.Les simulations de création de planning ont essayé de couvrir tous les cas deconstructions cohérentes. Les résultats de ces tests ont été satisfaisants.Étant donné que le programme principal se base sur les modules ci-dessus, lestests effectués sur l’outil de planification complet ont porté généralement sur l’interactionentre ces modules et ceux-ci ont été satisfaisants.Un autre test s’est avéré intéressant dans cette phase de test. Un planning utilisépar l’équipe SwissCube lors d’une passe de leur satellite nous a été fourni et nousa servi de base comme test. La création de plannings similaires à celui fourni estpossible avec l’outil de planification développé.Les derniers tests consistaient à vérifier que les scripts Python générés s’exécutaientcorrectement. Différents plannings ont été générés afin de couvrir tous lescas cohérents. Afin de vérifier le bon fonctionnement des scripts Python et du clientspécifique aux plannings, une version du MCS a été implémentée. Cela permet desimuler la communication entre les scripts Python et le MCS. La communicationentre les scripts Python et le MCS est abordée à la section 5.2. Il a fallu égalementfaire attention de bien intégrer la technologie Jython car les scripts Python utilisentla classe Java du client spécifique aux plannings pour communiquer avec lesatellite. Un exemple de planning généré est la création d’un planning contenanttoutes les télécommandes qui peuvent être envoyées et de différentes conditions detransition afin de vérifier que chaque type d’action soit correctement généré sousforme de code Python et que ces actions soient toutes bien exécutées.

Chapitre 5Développement du MissionControl CenterCe chapitre présente l’architecture du MCC et son développement. La section5.1 présente l’architecture du MCC avec un schéma. Une description des élémentsconstituant le MCC est également donnée. La section 5.2 aborde les détails surla communication entre les clients et le MCS. La section 5.3 décrit le rôle duMCS dans le MCC. Les sections 5.4 et 5.5 présentent l’outil d’envoi manuel detélécommandes, le MDV et les détails de leurs implémentations.5.1 Architecture du MCCL’architecture du MCC respecte une topologie client/serveur où le serveur est leMCS et les clients sont des scripts Python représentant des plannings, des logicielsqui envoient des télécommandes, etc. La figure 5.1 représente l’architecture duMCC avec les éléments y faisant partie.Les éléments de la figure 5.1 sont décrits brièvement ci-dessous.Operator :Toute personne qui interagit avec le satellite durant la mission.Manual TC Sender : C’est un outil qui permet l’envoi de télécommandes ausatellite de manière manuelle. Étant qu’un mode de communication automatiquea été mis en place au chapitre 4, cet outil est une alternative au modede communication automatique.Planning Tool : L’outil de planification permet la génération de plannings représentéssous forme de scripts Python. Ces derniers pourront être exécutéslors des passes du satellite à condition qu’un opérateur ait assigné un scriptà l’une de ces passes.Planning : Un planning représente un ensemble d’opérations à exécuter sousforme de script Python. Un planning peut être créé en utilisant l’outil deplanification ou alors en écrivant soi-même le script. Le seul module autoriséà exécuter un planning est le scheduler.40

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 41Figure 5.1 – Architecture du Mission Control Center

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 42Scheduler : Le scheduler a connaissance de toutes les passes du satellite et offrela possibilité aux opérateurs d’exécuter un script Python à une ou plusieursde ces passes.Mission Data Viewer : Le MDV permet aux opérateurs de visualiser les donnéesrelatives à la mission OUFTI-1, telles que les valeurs des mesures àbord du satellite, l’état d’exécution d’une télécommande, les télécommandesenvoyées, etc. Il est constitué de deux modes d’affichage : un permettant lavisualisation des données en temps réel et un autre permettant la visualisationde l’historique des données depuis le début de la mission.Mission Control Software : Le MCS joue le rôle de serveur sur lequel tous lesclients se connectent pour pouvoir envoyer des télécommandes au satellite.Mission Database : La base de données de mission contient toutes les donnéestransmises lors de la mission, c’est-à-dire toutes les télécommandes et lestélémétries transitant par le MCS.Mission Information Base : La MIB est un ensemble d’information structurésur les formats des paquets des différents services du protocole PUS utilisés,les fonctions qu’on peut faire exécuter par un processus à bord, etc. Ellecontient des informations qui ont été définies avant le lancement du satellite.GS Server : Le MCS se connecte au serveur GS pour envoyer et recevoir desinformations du satellite. Le serveur GS fait partie de l’unité GS représentéeà la figure 3.1.5.2 Communication clients et MCSLe moyen de communication utilisé entre les clients et le MCS est important cartous les clients devront intégrer ce système de communication s’ils souhaitent seconnecter au MCS.Dans l’environnement Java, il est possible d’établir une connexion entre deuxprogrammes, généralement un serveur et un client, soit par l’utilisation de la communicationpar sockets ou par l’utilisation de la technologie Java RMI.Java RMI est basé sur l’utilisation de sockets mais, à la différence de la premièresolution, elle facilite le développement des applications distribuées en rendanttransparente aux développeurs la communication entre clients et serveur. Eneffet, le choix de la première solution impliquerait la définition d’un protocole decommunication entre les clients et le serveur. C’est pourquoi nous avons utiliséJava RMI pour développer la communication entre les clients et le MCS.5.2.1 Java Remote Method Invocation5.2.1.1 DescriptionJava RMI est un outil de haut niveau permettant aux développeurs de travaillerdirectement avec des objets Java distants sans se soucier de l’implémentation auniveau de la communication entre ceux-ci.

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 43Un scénario typique de fonctionnement de Java RMI est qu’un serveur crée desobjets sur la machine où il est lancé, rende ces objets accessibles à distance etattende que les clients demandent l’exécution de méthodes sur ces objets. Du côtédu client, il va demander au serveur une ou plusieurs références vers les objets setrouvant sur le serveur et invoquer des méthodes sur celles-ci. En effet, le client,après avoir obtenu une référence sur un objet distant, pourra travailler avec cetobjet comme s’il se trouvait sur la machine elle-même, alors qu’il se trouve surla machine où le serveur tourne. Les deux applications peuvent fonctionner sur lamême machine, c’est juste qu’il y aura deux machines virtuelles Java différentes.Java RMI fournit un mécanisme permettant aux objets Java de se communiquerentre eux.Par quels moyens les clients peuvent-ils obtenir les références vers ces objetsdistants ?Java RMI propose une fonctionnalité, appelée le registre RMI, qui permet de lierun objet distant avec un identifiant dans un registre. Ce registre se trouve du côtédu serveur. Le client obtient une référence vers un objet distant selon l’identifiantqu’il introduit dans le registre.Une autre solution est que l’application retourne directement des références versces objets distants. Le développeur n’aurait pas besoin à chaque fois d’accéder auregistre et introduire un identifiant pour obtenir la référence vers un objet distant.La communication entre objets distants est supportée par Java RMI. Du pointde vue du développeur, la communication à distance ressemble à un simple appelde fonction standard sur un objet. Toutefois, pour pouvoir utiliser ce mécanisme, ilest nécessaire de définir, dans les interfaces des objets que l’on manipule à distance,toutes les fonctions que l’on peut invoquer sur ces objets.Java RMI offre une autre fonctionnalité qui permet aux clients de passer desobjets en arguments aux objets distants. En effet, Java RMI fournit des mécanismesqui transfèrent le code des objets passés en argument vers le serveur etleurs données.Le schéma, à la figure 5.2, représente un exemple où le serveur lie un objet distantà un identifiant dans le registre RMI, et le client va chercher la référence vers cetobjet dans le registre et invoque l’exécution d’une méthode sur cet objet. Le clientdoit également connaître les détails sur l’emplacement du serveur dans l’objectifde contacter le registre RMI se trouvant sur le serveur.5.2.1.2 Utilisation de Java RMI dans le MCCEn faisant l’analogie entre l’exemple dans la section précédente et le MCC, leserveur est le MCS et les clients sont les scripts Python, l’outil d’envoi manuel detélécommandes, etc.Le serveur lie un objet représentant une fabrique de télécommandes avec unidentifiant dans le registre RMI. Les clients obtiennent la référence vers cette fabriquegrâce au registre RMI. La fabrique de télécommandes, par invocation deméthodes sur elle-même, crée des objets représentant des télécommandes et renvoiedes références vers ces objets aux clients. Une fois que le client est en possession

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 44Figure 5.2 – Exemple d’une application utilisant Java RMId’une référence vers une télécommande, il remplit les informations propres à latélécommande et demande son envoi par le biais des méthodes qui ont été définiescomme étant des fonctions qu’on peut invoquer à distance sur l’objet. Le serveurse chargera de la construction du paquet contenant la télécommande et de sonenvoi au satellite.Le rôle principal du MCS est la création et l’envoi de télécommandes mais il aégalement d’autres rôles qui sont le stockage de toutes les informations transitanten son point (télécommandes et télémétries) et la notification à ses clients lorsquedes nouvelles informations arrivent (la réception d’une télémétrie, l’envoi d’unetélécommande, etc.).La notification en temps réel entre le MCS et les clients est réalisée sur basedu patron de conception observateur/observable implémentée avec Java RMI. Enpratique, le MCS gardera en mémoire une liste de références vers des objets distantsse trouvant chez les clients. Ensuite, par exemple, lorsqu’il y a des télémétriesqui viennent d’être reçues, le serveur se sert de la liste contenant les référenceset appellent des méthodes spécifiques sur ces objets distants afin que les clientssoient à jour sur les informations récemment reçues. Les objets distants chez lesclients sont responsables d’aller chercher les nouvelles informations sur le MCS àchaque notification. L’appel de méthodes sur des objets distants se fait dans lesdeux sens. En effet, le client devient serveur et le serveur devient client. Ce genred’appels est appelé RMI Callbacks.

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 455.3 Mission Control Software5.3.1 DescriptionLe MCS est l’élément central du MCC. En effet, toutes les données transitenten ce point et presque tous les éléments dans le MCC y sont connectés. Il estimportant d’énoncer les rôles fondamentaux du MCS :1. Création et envoi de télécommandes,2. Sauvegarde de toutes les télécommandes et les télémétries dans la base dedonnées de mission,3. Extraction des données dans les télémétries et les stocker dans la base dedonnées de mission,4. Notification au MDV des informations récemment envoyées ou reçues etmettre ces informations à sa disposition.Le premier rôle est la création et l’envoi de télécommandes sur la demande desclients. La création des paquets représentant les télécommandes est réalisée par leMCS. Les paquets ont un format spécifique défini par le protocole PUS (voir [25]pour les détails sur l’implémentation du protocole PUS).Le second rôle est la sauvegarde de toutes les données transitant par le MCS. Eneffet, les informations stockées dans la base de données de mission servira au MDVpour afficher les données aux opérateurs et aux scripts Python pouvant contenirdes opérations qui sont des accès à ces informations.Le troisième rôle est indispensable pour la visualisation des valeurs des paramètresà bord du satellite via le MDV. Il faudra, à un moment ou un autre, extraireles données des télémétries mais pour le faire, il est nécessaire de connaîtrele format des paquets. Le MCS se chargera de l’extraction des données contenuesdans les télémétries. Par exemple, il peut extraire des informations d’un paquet duservice 1 (décrit à la section 7.3). Les informations d’un paquet du service 1 permetde suivre l’état d’évolution d’une télécommande récemment envoyée. L’utilisateurpourra, par exemple, s’assurer que le mode D-STAR du satellite est bien activé enregardant si la télécommande a bien été exécutée par le MDV.Le quatrième rôle permet d’avoir les données mises à jour en temps réel dansle MDV. En effet, il est intéressant de pouvoir consulter des données en tempsréel. Par exemple, l’évolution d’exécution d’une télécommande pourra être suivieen direct ou alors il sera également possible de voir l’arrivée des valeurs des paramètresà bord en direct après activation du service de génération de rapports dedonnées. Le service de génération de rapports de données permet aux opérateursd’activer une génération automatique de rapports contenant les valeurs de certainsparamètres à bord du satellite.

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 465.3.2 ImplémentationLe MCS assure l’envoi de télécommandes et la notification aux clients par l’utilisationde Java RMI.Le scénario de création et d’envoi d’une télécommande peut se résumer parl’exemple de fonctionnement suivant. Un objet distant, se trouvant sur le MCS,joue le rôle de fabrique de télécommandes. Les clients obtiennent la référence verscet objet via le registre RMI. À partir de là, lorsqu’un client souhaite envoyerune télécommande, il envoie une requête à la fabrique de télécommandes et cellecirenvoie une référence vers l’objet télécommande qu’elle vient juste de créer.Le client complétera les paramètres propres à cette télécommande et demanderason envoi. Ensuite, le MCS s’occupera de la construction du paquet à partir desinformations données par le client et enverra le paquet contenant la télécommande.Toutes les télécommandes utilisées pour la mission et leurs paramètres sont décritsau point 7.2.Le MCS joue également le rôle de observable dans le modèle de conception observateur/observable.Les clients s’inscrivent pour être "abonnés" aux informationstransitant par le MCS. Tous les clients abonnés seront notifiés lorsque des nouvellestélécommandes sont envoyées ou des nouvelles télémétries sont reçues ou que desnouvelles valeurs des mesures à bord du satellite sont extraites des télémétries.Le MCS contient une liste de références vers des objets distants se trouvant surchaque client qui lui est connecté. Lorsqu’il y a du changement, le MCS utilise cesréférences pour invoquer une méthode qui a pour effet que les clients vont allerchercher l’information sur le MCS. Il est nécessaire pour cela que ces objets référencésse trouvant dans les clients possèdent une référence permanente vers le MCS.Les données observées sont les télécommandes, les télémétries et les paramètres àbord du satellite.La MIB contient toutes les informations sur les services du protocole PUS telsle nombre de bits pour tel champ d’un tel paquet, les valeurs possibles pour un telchamp, l’ensemble des paramètres définis pour la mission, etc (voir 7.2). Le MCSse base sur la MIB pour construire les paquets et également pour en extraire lesdonnées.L’idée de base était que le MCS soit assez générique pour fonctionner avec n’importequelle information encodée dans la MIB, c’est-à-dire qu’il pourrait supporterun nouveau service PUS en ajoutant simplement les informations de ce service dansla MIB, mais c’est impossible. Ce genre de changements impliquerait égalementdes changements au niveau du code du MCS. Toutefois, il y a quand même uncôté générique tel que l’ajout d’une nouvelle valeur possible pour un champ d’unetélécommande ne posera aucun problème d’intégration dans le fonctionnement duMCS.En ce qui concerne les détails d’implémentation de la création et l’envoi detélécommande, l’extraction des données des paquets, la conception de la MIB etle mécanisme d’interaction entre la MIB et le MCS, voir [25].

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 475.4 Outil d’envoi manuel de télécommandes5.4.1 DescriptionL’outil d’envoi manuel de télécommandes permet l’envoi direct de télécommandesau satellite. L’opérateur a, à sa disposition, une interface graphique lui proposantla création d’un ensemble de télécommandes qui peuvent être utilisées dans lecadre de la mission OUFTI-1 (voir section 7.2 pour connaître l’ensemble des télécommandesdisponibles). Lors de la création d’une télécommande, l’opérateurdevra spécifier les paramètres de la télécommande.Pour chaque télécommande envoyée, l’opérateur a un retour l’informant si latélécommande a été acceptée ou non par le satellite. Cette acceptation correspondà une télémétrie du service 1 du PUS. Le service 1 permet de suivre l’évolutiond’exécution d’une télécommande à bord du satellite.L’outil d’envoi manuel de télécommande informe juste l’opérateur si la télécommandea été acceptée ou non par le satellite, tandis que le MDV affiche les différentesphases d’exécution de la télécommande. Elle permet donc un suivi completde la télécommande.À la section 4.5, un mode de communication automatique a été réalisé mais grâceà l’outil d’envoi manuel de télécommandes, un autre système de communication aété également réalisé, un mode de communication manuel.Les opérateurs ont la possibilité de se passer des outils permettant l’automatisationdu MCC pour interagir manuellement avec le satellite. Toutefois, il estévident que la quantité d’information échangée ne sera pas maximale et qu’il seranécessaire d’avoir un opérateur présent à toutes les passes du satellite pour vérifierl’état de santé du satellite.Ainsi, deux modes de communication sont disponibles, automatique et manuel.5.4.2 ImplémentationL’implémentation de l’outil d’envoi manuel de télécommandes est basée partiellementsur l’utilisation Java RMI. L’outil d’envoi manuel de télécommandes est unclient qui se connecte sur le MCS. La création et l’envoi de télécommandes se fontà distance sur le MCS.Il est important que le sous-système Telemetry/Telecommand (TC/TM) et quele sous-système Ground (GND), dont je suis responsable, se mettent d’accord surles interfaces des objets qui sont utilisés à distance, afin de faciliter la mise encommunication entre le MCS et les clients, tel que l’outil d’envoi manuel de télécommandes.Le sous-système TC/TM est responsable du développement du MCSet des protocoles de communication dans le cadre de la mission OUFTI-1. Les interfacesdes objets définissent les méthodes qui peuvent être exécutées à distance.Par exemple, l’interface de l’objet représentant la fabrique de télécommandes seramajoritairement constituée de fonctions de création de télécommandes. Ces fonctionsretournent aux clients des références vers les objets télécommandes venantjuste d’être créés par le MCS.

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 48L’implémentation du MCS ne fait pas partie du travail de fin d’études présentmais y est étroitement liée pour le développement futur du projet. De nombreusesréunions ont eu lieu pour définir toutes les interfaces des objets qui sont manipulésà distance c’est-à-dire les différents types de télécommandes, la fabrique detélécommandes, etc.Il aurait été intéressant de pouvoir tester le comportement de l’outil d’envoimanuel de télécommandes connecté au MCS dans sa version finale mais, fautede temps, cela n’a pas été possible. Toutefois, afin de pouvoir tester l’outil, uneimplémentation légère du MCS a été réalisée. Bien qu’elle soit incomplète, cetteversion du MCS implémente les fonctions utilisées à distance par l’outil d’envoimanuel de télécommandes afin de tester toutes ces fonctionnalités.Une amélioration possible de cet outil est l’ajout d’un module qui irait chercherles heures des prévisions des passes du satellite, permettant ainsi la désactivationde l’envoi de télécommandes lorsque la station sol est hors de la zone couverte parle satellite. Cette amélioration n’est peut-être pas nécessaire car, de toute façon,même si l’on envoie une télécommande en étant hors de la zone couverte par lesatellite, ce dernier ne répondra pas.5.4.2.1 FonctionnementLe schéma à la figure 5.3 décrit le fonctionnement de l’outil d’envoi manuel detélécommandes.Dans ce schéma, on peut voir que l’outil, avant toute création et envoi de télécommandes,se connecte au MCS pour prendre des informations qui seront utiles pourla création de télécommandes. Par exemple, il est intéressant, pour les opérateurs,d’avoir la liste et la description des fonctions supportées par les processus à bordainsi que leurs paramètres. Grâce à ces informations, l’application proposera lesvaleurs possibles pour certains paramètres, au lieu de laisser les opérateurs spécifierces valeurs augmentant ainsi le risque de refus d’exécution d’une télécommandepour des raisons d’arguments invalides.La suite du schéma montre une boucle constituée de la création et l’envoi d’unetélécommande, et si cette dernière a été acceptée ou non par le satellite.5.4.2.2 Interface graphiqueUne capture d’écran de l’outil d’envoi manuel de télécommande est présentée àla figure 5.4. La fenêtre principale permet d’accéder à la création des différentestélécommandes utilisées dans la mission. Pour chaque type de télécommande quel’opérateur souhaite envoyer, il y a une fenêtre dédiée à la spécification des paramètresde ce type de télécommande.Toutes les télécommandes envoyées avec cet outil sont notées dans une zoneappropriée ainsi que le retour de ses télécommandes, c’est-à-dire si elles ont étéacceptées ou non par le satellite.

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 49Figure 5.3 – Flowchart de l’outil d’envoi manuel de télécommandes5.4.2.3 TestEn premier lieu, les tests ont été effectués sans connexion avec le MCS. Ces testsont surtout porté sur l’interface graphique afin de déceler des dysfonctionnements.Par la suite, une implémentation simple et très légère du MCS a été réalisée afinde pouvoir développer le code adéquat pour une future imbrication et de simulerla connexion entre le MCS et l’outil d’envoi manuel de télécommandes. Les testsconsistaient en la création et l’envoi de chaque type de télécommande possible.La liste de télécommandes qu’il est possible d’utiliser dans la mission OUFTI-1est décrite à la section 7.2. En effet, ces tests permettent de vérifier qu’aucunargument des télécommandes n’a été oublié lors de l’implémentation de l’outilet lors des définitions des interfaces avec le sous-système TC/TM. Cela permetégalement de tester la communication Java RMI avec le MCS.Un exemple de test consistait en la création d’une télécommande qui active lagénération automatique de rapports de données sur certaines mesures à bord dusatellite. Il a fallu vérifier que le MCS renvoie une référence vers l’objet télécommandedistant, après une demande de création de télécommande provenant del’outil d’envoi manuel de télécommandes. Ensuite, on doit spécifier les argumentsde la télécommande via les méthodes qu’on peut invoquer à distance sur l’objet.Après chaque spécification d’un argument à la télécommande, on vérifie du côté

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 50Figure 5.4 – Capture d’écran de l’outil d’envoi manuel de télécommandesdu MCS que l’objet a bien été mis à jour afin de vérifier que la connexion entrel’outil d’envoi manuel de télécommandes et le MCS fonctionne bien. Finalement,on vérifie que la méthode demandant l’envoi de la télécommande par l’outil a bienété reçue par le MCS.Les tests effectués avec cette version du MCS ont été réalisés avec succès.L’implémentation du MCS ne fait pas partie du travail de développement de cemémoire et les détails de son développement se trouvent dans [25].En attente du développement complet du MCS, le code relatif à la connexionentre l’outil et le MCS a été placé en commentaires. Ce code a été développé enrespectant les interfaces de communication définies entre le MCS et l’outil d’envoimanuel de télécommandes.5.5 Mission Data Viewer5.5.1 DescriptionLe Mission Data Viewer est un outil qui permet la visualisation des données relativesà la mission, telles que les télécommandes, les télémétries, etc. Au cours de lamission, les opérateurs auront la possibilité de visualiser deux types d’informationsavec cet outil. Les informations historiques et en temps réel.Ces deux catégories se différencient par l’absence de mises à jour automatiquesdes données affichées. En effet, prenons par exemple, un scientifique qui souhaite

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 51consulter les valeurs de paramètres relatifs à l’alimentation électrique expérimentale,il ne voudra sûrement pas être dérangé par les mises à jour automatiquesqui provoqueront des décalages dans les tableaux de données. Par contre, le modetemps réel sera utile lorsqu’un opérateur souhaite, par exemple, voir l’état d’évolutiond’exécution d’une télécommande qu’il vient d’envoyer.Une autre différence est que les données en temps réel se limitent aux cinquantedernières télécommandes, cinquante dernières valeurs d’un paramètre à bord, etc.Tandis que le mode historique affiche toutes les données depuis le début de lamission. Si l’on souhaite modifier la limite fixée pour les données en temps réel, ilfaut changer une constante dans le programme.La façon d’afficher les données est importante. En effet, il serait difficile pourun opérateur de regarder toutes les télémétries depuis le début de la mission dansun seul tableau et de s’y retrouver. C’est pourquoi le MDV intègre un systèmed’affichage où l’utilisateur sélectionne le nombre d’éléments qu’il souhaite afficherpar page (5, 20, 50, ...). Dans le cas des données en temps réel, cet argument estlimité à 50.Le mode historique implique que le MDV soit relié à la base de données de mission.Le MDV ira chercher les informations dans la base de données de missionselon les requêtes de l’utilisateur. Le mode historique n’est pas dépourvu de fonctionsde mises à jour : il y a un bouton permettant à l’utilisateur de mettre à jourles données historiques affichées.Afin de pouvoir supporter la fonctionnalité d’avoir les données en temps réel,le MDV est connecté au MCS. En effet, il s’inscrit auprès du serveur, comme uninternaute s’abonnant à un flux RSS, pour être averti de toutes nouvelles informationstransitant par le MCS. Les informations qui sont disponibles en temps réeldans le MDV sont les télécommandes, les télémétries et les valeurs de toutes lesmesures à bord du satellite.Une fonctionnalité supplémentaire qui aurait pu être intégrée au MDV est unsystème de messages venant du MCS. Cette fonctionnalité peut être intéressantesi l’on souhaite que le MDV informe le client de l’état du serveur. Par exemple,informer les opérateurs que le serveur va redémarrer à telle heure ou que les informationsen temps réel ne sont plus disponibles à cause d’un problème sur leserveur. Une autre idée serait d’utiliser ce canal de communication pour afficher lelog du MCS mais du côté MDV. Le MDV serait au courant en temps réel de tousles traitements se passant dans le MCS.5.5.2 ImplémentationPour accéder aux informations se trouvant dans la base de données de mission,l’API JDBC est utilisée. Cette bibliothèque permet d’effectuer des opérations avecles bases de données relationnelle les plus connues. Ces opérations sont l’insertionde données, la consultation de données dans la base de données, etc.Bien que dans [8], le choix s’était fixé à utiliser le framework open source JavaHibernate permettant le mapping objet-relationnel. Java Hibernate, en bref, permetle stockage d’objets Java dans une base de données. Ce choix a été revu et

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 52s’est porté sur l’utilisation de l’API JDBC, un outil de plus bas niveau que Hibernate.L’utilisation de Java Hibernate évitait d’avoir à utiliser le Structured QueryLanguage (SQL) dans le code. Cependant, étant la faible complexité des requêtesSQL et sa faible présence dans le code, il ne nous a pas semblé nécessaire d’utiliserJava Hibernate, mais le programme pourrait tout à fait intégrer dans le futurcette librairie de mapping objet-relationnel dans l’objectif que le programme soitportable vers d’autres bases de données.Une autre alternative, si l’on veut minimiser la présence de code SQL, est destocker des procédures dans la base de données. Une procédure est un ensembled’instructions SQL pré-compilées. Dans le code de développement de l’application,on fait appel à cette procédure au lieu d’écrire toutes les instructions SQL faisantexactement la même chose. Cela permet d’éviter la redondance importante de codeSQL.Dans l’objectif que le MDV soit informé en temps réel des nouvelles télécommandesenvoyées, des nouvelles télémétries reçues et des nouvelles valeurs desparamètres à bord du satellite, le modèle de conception observateur/observablea été appliqué. Le MCS possède une référence vers un objet se trouvant dans leMDV et invoquera une méthode sur cet objet lorsqu’il y a des changements. Laméthode de l’objet consiste, par exemple, à aller chercher sur le MCS un tableaudes 50 dernières valeurs d’une mesure. Il y a une fonction de mise à jour spécifiquepour chaque type de données. La relation client/serveur se fait dans les deux sens.En effet, le MCS et le MDV possède chacun une référence vers un objet se trouvantchez l’autre.Des interfaces ont dû être définies pour permettre l’implémentation de ce mécanisme.Il a fallu définir une interface pour l’objet qui se trouve dans le MCS dontles fonctions seraient l’inscription et la désinscription de clients aux notificationsvenant du serveur. Une autre interface a dû également être définie pour l’objet setrouvant chez les clients dont les fonctions sont des fonctions de mises à jour desdonnées auprès du serveur.Il est clair que le nombre de notifications sera très important lors des passes dusatellite et le reste du temps, il sera nul.5.5.2.1 FonctionnementUn schéma de fonctionnement de l’outil est présenté à la figure 5.5. On peut voirque le fonctionnement du MDV peut être divisé deux parties. La première s’occuped’afficher les informations historiques en fonction de ce que l’utilisateur choisit devoir avec le MDV, et la seconde s’occupe d’afficher les données récentes mises àjour en temps réel. La seconde partie n’est active que si l’utilisateur a ouvert unefenêtre affichant des données en temps réel. L’étape « requêtes utilisateurs » dansle schéma reflète les sélections de données que l’utilisateur souhaite voir dans leMDV.Si une des deux phases de connexion (base de données de mission et MCS)échoue, le programme en informe l’utilisateur et se ferme.

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 53Figure 5.5 – Flowchart du Mission Data Viewer5.5.2.2 Interface graphiqueUne capture d’écran du Mission Data Viewer développé dans le cadre de lamission OUFTI-1 est présentée à la figure 5.6.La fenêtre principale propose six rubriques permettant la visualisation des télécommandes,des télémétries et des mesures à bord du satellite.5.5.2.3 TestIl y a deux choses importantes à tester : la communication avec la base de donnéeset le mécanisme de notification.Les tests ont été effectués avec une base de données de type PostgreSQL. Lechoix de l’utilisation d’une base de données de ce type est expliqué au chapitresuivant.Des données fictives ont été insérées dans la base de données de mission afin depouvoir tester le programme.Les tests se sont révélés satisfaisants tant bien au niveau des requêtes SQL qu’auniveau de l’affichage des données. Il est important que le MDV connaisse la struc-

CHAPITRE 5. DÉVELOPPEMENT DU MISSION CONTROL CENTER 54Figure 5.6 – Capture d’écran du Mission Data Viewerture des tables se trouvant dans la base de données, afin de pouvoir faire lesrequêtes SQL adéquates. Les tests consistaient en la vérification que l’applicationallait bien chercher les informations dans la base de données selon les sélectionsdes utilisateurs. Elles portaient également sur la vérification du bon affichage deces informations dans l’interface graphique. Toutes les informations qui peuventêtre visualisées avec le MDV ont été effectuées.Un exemple de test consistait en la visualisation des télécommandes stockéesdans la base de données de mission. On lance le programme, on vérifie que l’applications’est bien connectée à la base de données et s’est bien inscrite auprèsdu MCS. Ensuite, on clique sur la rubrique “Telecommands History” et on choisitque le nombre maximum d’éléments affiché par page est de 5. On vérifie que lesinformations affichées sont bien 5 éléments par page et qu’elles correspondent bienaux télécommandes stockées dans la base de données. Afin de vérifier la correspondancedes données, on utilise l’outil pgAdmin qui permet également la visualisationdes données dans la base de données. La mise en place de la base de données demission est abordée au chapitre 6.Il a fallu également tester le mécanisme de notification en temps réel. Pour cela, ila fallu encore implémenter une version légère MCS dont le seul rôle était de notifierle MDV, lorsqu’il y avait des nouvelles informations transitant en son point.Les simulations consistaient en une notification à fréquence régulière au MDVet la vérification que ce dernier allait bien chercher les données sur le MCS aprèschaque notification.Un exemple de simulation était l’envoi d’une notification toutes les cinq secondesau MDV de la part du MCS. Toutes les cinq secondes, le MCS ajoute uneinformation dans les tableaux reprenant les dernières télécommandes, les dernièrestélémétries, etc. Afin de vérifier que le MDV se mette bien à jour, on affiche àchaque notification les tableaux des données observées. Les tests vérifiant le bonfonctionnement et la robustesse de ce mécanisme ont été un succès.En attente du développement complet du MCS, le code relatif à la connexionentre ce dernier et le MDV a été placé en commentaires. Ce code a été développéen respectant les interfaces de communication définies entre ces deux applications.

Chapitre 6Base de données de missionCe chapitre donnera une description du rôle la base de données de mission dansle MCC à la section 6.1 et sa mise en place à la section 6.2.6.1 DescriptionDans le cadre d’un projet spatial tel que OUFTI-1, il est important d’avoir unsystème qui enregistre toutes les données relatives à la mission, c’est-à-dire toutesles télémétries reçues du satellite et toutes les télécommandes envoyées par lesopérateurs.Tous les logiciels qui doivent stocker des informations ont un besoin communqui est la persistance des données. Sans une persistance des données, toutes applicationsdont les informations sont stockées dans la mémoire de ces programmessont sujettes à une perte de ces données lorsque ces applications sont coupées.Généralement, pour répondre à ce besoin, on utilise une base de données où lesinformations manipulées par les applications seront stockées. Par exemple, si uneapplication est coupée et puis relancée, elle consultera, lors de son démarrage, labase de données permettant ainsi de reprendre où elle en était avant sa coupure.Les bases de données sont également conçues pour contenir une grande quantitéd’information.Dans le cadre du projet OUFTI-1, on utilise une base de données, appelée basede données de mission, qui contient toutes les informations propres à la mission.La base de données de mission est reliée à plusieurs éléments du MCC. En premierlieu, elle est reliée au MCS car rappelons que l’un des rôles de ce dernier estde stocker toutes les informations transitant en son point, les télécommandes etles télémétries. Il est également chargé d’extraire les données contenues dans destélémétries et les stocker dans la base de données de mission. Un exemple d’extractionde données est l’extraction des valeurs des paramètres à bord contenuesdans une télémétrie.Un autre lien se trouve entre le logiciel Orbitron, décrit au point 3.2.3, et labase de données. En pratique, Orbitron peut fournir les prévisions des passes dusatellite dans un fichier texte. Un module développé l’an passé permet d’extraire55

CHAPITRE 6. BASE DE DONNÉES DE MISSION 56de ce fichier les informations sur les passes à venir du satellite et de les stockerdans la base de données de mission.Les informations sur les passes du satellite sont utilisées par le scheduler pour, parexemple, afficher aux utilisateurs les informations des passes à venir ou pour avoirle Acquisition Of Signal (AOS) d’une passe pour l’exécution d’un planning. Lesinformations sur les passes ne sont utilisées que par le scheduler pour le momentmais il est fort probable que d’autres modules utiliseront ces informations. Parexemple, on pourrait développer un module interdisant la communication de lastation sol vers le satellite tant que l’on ne se trouve pas dans l’une de ces passes.Le MDV et la base de données de mission sont également reliés. Le rôle principaldu MDV est de permettre la visualisation aux opérateurs des informationsstockées dans la base de données de mission. Plusieurs MDV peuvent égalementêtre connectés à la base de données.Grâce à cette base de données centralisée et à des interfaces définies avec unepensée pour les futurs développements du projet, il sera possible de développer plusaisément des clients web qui partageraient les mêmes fonctionnalités que le MDV.Les opérateurs pourront consulter les données relatives à la mission OUFTI-1 viaInternet.6.1.1 Système de gestion de base de donnéesIl y a plusieurs Systèmes de Gestion de Base de Données (SGBD) dont on pourraitse servir pour le projet, tels que MySQL, Oracle, PostgreSQL, SQL Server,... Étant donné les simples opérations utilisées sur la base de données lors de lamission, tous ces SGBD peuvent être utilisés. Toutefois, on a préféré également unlogiciel libre, ce qui a pour effet de restreindre la liste des SGBD qui pourraientêtre utilisés.Notre choix comme SGDB dans le cadre du projet est PostgreSQL 8.4. Il fournitun outil, nommé pgAdmin III, qui permet d’effectuer des opérations sur les basesde données telles que l’ajout de tables, l’insertion de données, la consultation dedonnées, etc.Il est également important que Java JDBC ait un driver lui permettant de travailleravec une base de données de type PostgreSQL ; sinon, il n’aurait pas étépossible de développer une application Java communiquant avec ce type de basede données.6.2 Structure de la base de données de missionLa structure de la base de données de mission doit être connue de tous ceux quisont en relation avec, mais tout d’abord il faut définir cette structure.Une base de données relationnelle est composée d’un ensemble de tables et desliens entre ces tables sont possibles.Dans le cadre du projet, la structure de l’ensemble des tables dans la base dedonnées est simple. Il y a deux tables pour les télécommandes : la première stocke

CHAPITRE 6. BASE DE DONNÉES DE MISSION 57les télécommandes de manière binaire et encodées dans leur format ConsultativeCommittee on Space Data System (CCSDS), et la seconde stocke les donnéescontenues dans les télécommandes sous une forme où il est possible de spécifierdes critères de sélection pour retrouver une télécommande dans la table.Pour les télémétries, il y a également deux tables du même type que pour lestélécommandes.Pour les mesures à bord du satellite, il y a une table pour chaque mesure. L’ensembledes mesures se trouvant dans la base de données est basé sur la liste setrouvant dans l’annexe A.Afin de passer des télémétries sous forme binaire à des données qui seront, parexemple, utilisées par le MDV, le MCS traite les paquets et remplit les tables avecles données se trouvant les paquets.Par exemple, le MCS reçoit une télémétrie, décortique le paquet, trouve desvaleurs sur les mesures à bord du satellite et met à jour les tables des mesurescorrespondantes avec les valeurs venant d’être extraites du paquet. Il sauvegardeégalement les informations relatives à la télémétrie dans les deux tables qui luisont spécifiques.Un autre concept important en base de données est le concept de clé. Lors de ladéfinition d’une table, le développeur peut spécifier une clé primaire. Dans le casdes tables des télécommandes et des télémétries, la clé primaire est un identifiantentier permettant d’éviter les doublons dans les tables et peut être utilisée commecritère de recherche. Chaque entrée dans les tables est associée à un identifiantunique.Les valeurs des paramètres à bord du satellite se trouvaient à l’origine dans destélémétries. Or, il est intéressant de pouvoir connaître de quelle télémétrie provienttelle valeur pour telle mesure. Le concept de clé étrangère permet de satisfaire cebesoin. Lors de la création d’une table, une ou plusieurs colonnes d’une tablepeuvent référencer une ou plusieurs colonnes d’une autre table. Dans notre cas,il y aura une colonne dans chaque table des mesures qui référence la colonne desidentifiants des télémétries, permettant ainsi d’établir un lien entre les télémétrieset les mesures.Cette relation est utilisée lors de l’affichage des mesures dans le MDV permettantainsi de savoir l’heure à laquelle les valeurs d’une mesure sont arrivées, puisqueque l’heure d’arrivée des valeurs est liée à l’heure d’arrivée des télémétries.La structure de la base de données de mission est représentée à la figure 6.1.Comme on peut le voir, la clé primaire de la table TC, ID Token, est utiliséecomme clé étrangère dans la table TC Raw. En effet, une entrée dans la table TCest un ensemble d’information constituant une télécommande stockée dans la tableTC Raw.La table TC dans le schéma possède différentes colonnes contenant des informationsà propos des télécommandes envoyées. Ces colonnes représentent l’heured’envoi d’une télécommande, à quelle application à bord elle s’adresse, à quel serviceelle appartient, à quel sous-service elle correspond, son évolution d’exécutionà bord du satellite, un code d’erreur si son exécution à bord a été un échec et sesdonnées. La table TM possède des colonnes similaires à la table TC.

CHAPITRE 6. BASE DE DONNÉES DE MISSION 58Les tables TC Raw et TM Raw sont utilisées pour former un historique mais égalementpour des raisons telles qu’il est possible d’avoir besoin d’autres informationsqu’on n’a pas nécessairement extraite la première fois.Chacune des tables représentant une mesure possède une clé étrangère qui faitréférence à la colonne des identifiants de la table TM. En effet, chaque valeurextraite pour une mesure provient d’une télémétrie. Cette relation permet donc delier les valeurs d’une mesure avec les informations des télémétries qui contiennentces valeurs.Il y a également une table Pass qui contient toutes les prévisions sur les passesdu satellite. Celle-ci est remplie par un module qui est chargé de traiter les donnéesfournies par le programme Orbitron. Orbitron génère les prévisions des passes dusatellite. Les données stockées dans cette table est la Acquisition of Signal (AoS) etla Loss of Signal (LoS) de chaque passe. Ces données sont utilisées par le schedulerpour afficher aux opérateurs l’heure des passes du satellite et pour exécuter lesscripts Python.

CHAPITRE 6. BASE DE DONNÉES DE MISSION 59Figure 6.1 – Structure de la base de données de mission

Chapitre 7Protocoles de communicationCe chapitre aborde les protocoles de communication utilisés entre la station solet le satellite. La section 7.1 fait un rappel des protocoles utilisés dans le cadrede la mission selon le modèle OSI. La section 7.2 décrit l’ensemble des servicessélectionnés du protocole PUS pour la mission OUFTI-1.7.1 Protocoles utilisésLes protocoles utilisés dans la mission sont présentés dans le cadre du modèleOSI. Le modèle OSI est un modèle de communication standard entre les ordinateurs.Il est composé de sept couches : Application, Présentation, Session, Transport,Réseau, Liaison et Physique. Ce modèle est présenté à la table 7.1.Modèle OSIApplicationPrésentationSessionTransportRéseauLiaisonPhysiqueTable 7.1 – Modèle OSILes couches Présentation et Session peuvent être omises car les fonctionnalitésqu’elles fournissent aux applications, tels que le déchiffrage, la compression,la récupération de données, ... peuvent être implémentées dans la couche applicationou alors ne sont pas nécessaires pour la mission OUFTI-1. Le modèle OSI,ôté des couches Présentation et Session, correspond au modèle Internet, connusous le nom de modèle TCP/IP, composé de cinq couches. Afin que les lecteursaient une idée à quelle couche appartiennent les protocoles les plus connus, desexemples vont être donnés. Les protocoles File Transfer Protocol (FTP), Post OfficeProtocol (POP) et HyperText Transfer Protocol (HTTP) font partie de la60

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 61couche Application. Les protocoles Transmission Control Protocol (TCP) et UserDatagram protocol (UDP) se trouvent à la couche Transport. Le protocole le plusconnu au niveau Réseau est le protocole Internet Protocol (IP). Les protocolesPoint-to-Point Protocol (PPP) et Ethernet font partie de la couche Liaison.Dans le cadre du projet, le modèle TCP/IP n’est pas applicable et une variantede ce modèle est utilisée. Ce modèle est composé de quatre couches : Application,Transport, Liaison et Physique. La couche Réseau est omise parce que la communicationse passe entre deux hôtes uniquement, la station sol et le satellite ; etdonc, il n’y a pas besoin d’une couche s’occupant de la transmission de données àtravers un réseau. Cette communication entre deux hôtes uniquement est appeléeune liaison point à point. Le modèle et les protocoles utilisés dans le cadre de lamission sont présentés à la figure 7.2.Modèle OUFTI-1ApplicationTransportLiaisonPhysiqueProtocolePacket Utilisation Standard (PUS)Space Packet Protocol (SPP)AX.25Lien RF avec le satelliteTable 7.2 – Protocoles utilisés dans le projet OUFTI-1Les choix et les descriptions de ces protocoles se trouvent dans des travaux desannées précédentes (voir [15] et [8]).Après la brève présentation du modèle intervenant dans la communication entrela station sol et le satellite, la section suivante donnera une description complètedes services du protocole PUS à disposition des opérateurs.7.2 Protocole PUSLe protocole PUS définit une interface au niveau de la couche application pourcontrôler et surveiller le satellite à partir de la station sol. Il propose un largeensemble de services afin de pouvoir satisfaire les besoins de tout type de missionspatiale. Un service est constitué d’un ensemble de télécommandes et/ou de télémétries.Chaque service a une fonction particulière. Par exemple, un service estdédié à la gestion de la mémoire à bord du satellite, un autre à la génération derapports contenant les valeurs des mesures extraites à bord du satellite, etc.Bien entendu, il n’est pas nécessaire d’utiliser tous les services proposés parle protocole PUS dans le cas de la mission OUFTI-1. Le protocole PUS spécifieles règles et les structures aux utilisateurs afin que ces derniers puissent utiliserles services du protocole dont le but est de répondre aux besoins de la mission.Les sections suivantes vont décrire généralement les services du protocole PUSsélectionnés pour la mission OUFTI-1. Ces services devront être connus par lesopérateurs s’ils souhaitent pouvoir communiquer avec le satellite. Pour plus d’informationsur le choix des services sélectionnés du protocole du PUS et de son

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 62implémentation, voir [8] et [25]. Ces services sont les suivants :• Service de vérification de télécommandes,• Service de génération de rapports de données,• Service de gestion de fonctions,• Service d’ordonnancement à bord du satellite.7.3 Service de vérification de télécommandes7.3.1 DescriptionLe service de vérification de télécommandes, appelé également service 1, permetaux opérateurs à la station sol de suivre l’évolution d’exécution d’une télécommande,de son acceptation à bord à son exécution complète. C’est un service fondamentalà toutes les missions spatiales. Toutefois, la notification de l’évolutiond’exécution des télécommandes peut être désactivée. Le parcours d’une télécommandeest divisé en quatre étapes :• Acceptation : à cette étape, le processus recevant la télécommande, effectuetoutes les vérifications sur la télécommande avant son exécution. Les vérificationssont, par exemple, la vérification du checksum du paquet, la vérificationque le processus auquel s’adresse la télécommande existe bel et bien, etc.• Démarrage : cette étape marque le départ de l’exécution d’une télécommande.Généralement, cette étape s’exécute directement après la phase d’acceptation.Cependant, elle peut être retardée, à cause de vérifications, telles que la vérificationque les paramètres de la télécommandes sont bien encodés, les valeursdes paramètres se trouvent dans des limites, etc.• En cours : cette étape peut être utile dans le cas de télécommandes dont letemps d’exécution est long. Les opérateurs peuvent alors suivre l’exécution dela télécommande via des rapports qui sont générés et envoyés aux différentesétapes d’exécution.• Fin : exécution de la télécommande finie.Dans le cas où l’une des étapes est un échec, un rapport sera généré afin d’informerl’opérateur sur l’origine du problème. Les rapports d’échec sont automatiquementgénérés. Par contre, les rapports caractérisant le succès d’une étape ne sontgénérés que si l’opérateur l’a défini lors de la construction de la télécommande.Ce service n’est constitué que de télémétries informant les opérateurs sur l’étatd’exécution des télécommandes reçues par le satellite. Toutefois, ces télémétriespeuvent être divisées selon les étapes d’exécution et les résultats de ces étapes ;

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 63des sous-services ont été définis afin de caractériser ces différentes télémétries.7.3.2 Sous-types du service 1Il n’y a pas télécommandes pour ce service mais uniquement des télémétries.Chaque sous-type d’un service représente une télécommande ou une télémétrieaccompagnée de paramètres ou non.Liste des sous-types du service 1 :1. Rapport d’acceptation d’une télécommande - Succès (1, 1),2. Rapport d’acceptation d’une télécommande - Échec (1, 2),3. Rapport de démarrage d’une télécommande - Succès (1, 3),4. Rapport de démarrage d’une télécommande - Échec (1, 4),5. Rapport de progression d’une télécommande - Succès (1, 5),6. Rapport de progression d’une télécommande - Échec (1, 6),7. Rapport de fin d’exécution d’une télécommande - Succès (1, 7),8. Rapport de fin d’exécution d’une télécommande - Échec (1, 8).La paire se trouvant à la fin de chaque ligne ci-dessus représente, par son premierchiffre, le service auquel la télémétrie appartient et son second, le sous-type duservice.L’ensemble de ces télémétries sont accompagnées de différents paramètres selonleur type.Toutes les télémétries, énoncées ci-dessus, sont accompagnées de champs permettantd’identifier la télécommande en cours de traitement.Dans le cas d’un rapport d’échec, des champs dans le paquet fournissent un coded’erreur permettant ainsi d’identifier le type de problème. Par exemple, un rapportd’échec peut signaler à l’opérateur au sol qu’il a introduit un argument invalidedans la télécommande.Un champ additionnel est utilisé pour informer l’opérateur de la progression del’exécution de la télécommande (champ indiquant à quelle étape d’exécution estla télécommande).7.4 Service de génération de rapports de données7.4.1 DescriptionCe service, appelé également service 3, permet de collecter des données sur l’ensembledes paramètres à bord du satellite.Les ensembles de paramètres à mesurer sont représentés par des définitions stockéesà bord. Ces définitions sont identifiées par un Structure IDentification (SID).

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 64La définition d’un SID contient donc l’ensemble des paramètres à échantillonner, lafréquence de génération des rapports et les fréquences d’échantillonnage de chaqueparamètre.Les rapports générés contiennent d’abord le SID suivi d’une liste de valeurs,respectant l’ordre des paramètres se trouvant dans la définition SID. Chaque paramètrea été échantillonné selon sa fréquence d’échantillonnage contenue dans ladéfinition du SID.Tous les sous-types de ce service ne sont pas utilisés mais pourront être utilisésen cas de nécessité. Les sous-types qui ne sont pas utilisés sont, par exemple, destélécommandes permettant de définir, modifier et de supprimer des SIDs durantla mission.Dans le cas de la mission OUFTI-1, tous les SIDs et leurs définitions serontconstruits avant la mission et chargés à bord. Ces derniers pourront être activésou désactivés durant la mission. Il est idéal que chaque liste de paramètres dénotéepar un SID ait chacun un objectif particulier. Par exemple, il faudra définir uneliste de paramètres destinée à surveiller l’alimentation électrique expérimentale.7.4.2 Sous-types du service 3Liste des sous-types du service 3 :1. Activation de la génération de rapports de données (3, 5),2. Désactivation de la génération de rapports de données (3, 6),3. Rapport de données (3, 25).Les sous-types 5 et 6 ont pour paramètres une liste de SIDs à activer ou désactiver.Le sous-type 25 est une télémétrie contenant un champ SID qui permet auxopérateurs, à partir de la définition correspondant à cet SID, de déterminer quelssont les paramètres dans le paquet et un autre champ contenant la liste des valeursdes paramètres.7.5 Service de gestion de fonctions7.5.1 DescriptionLe service de gestion de fonctions, appelé également service 8, est utilisé pourdemander l’exécution d’une fonction supportée par un processus à bord. Il fournitaux opérateurs un ensemble de fonctions spécifiques à la mission qui peuvent êtreexécutées par l’ensemble des processus à bord du satellite.Un exemple de fonction est une fonction qui permet l’activation du mode D-STAR du satellite, l’activation du système d’alimentation expérimentale, etc.Chaque fonction relative à un processus à bord possède un identifiant unique,Function ID. À partir de cet identifiant, une description de la fonction et de sesparamètres peuvent être obtenues.

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 657.5.2 Sous-types du service 8Il n’y a qu’un sous-type du service qui est utilisé :1. Exécution d’une fonction (8, 1).Cette télécommande prend en paramètres, un identifiant de fonction et les paramètresrelatifs à la fonction correspondant à cet identifiant.7.6 Service d’ordonnancement à bord7.6.1 DescriptionLe service d’ordonnancement à bord, appelé également service 11, permet deplanifier des opérations à exécuter à des moments spécifiques à bord du satellite.Cela est possible grâce à un scheduler développé à bord contenant des télécommandesqui seront exécutées à une date ultérieure. Ce service est très utile puisque,la majorité du temps, la station sol ne se trouvera pas dans la zone couverte parsatellite.Le service supporte différents types de télécommandes permettant d’interagiravec le scheduler à bord. Par exemple, l’activation du scheduler ou sa désactivation,l’ajout et la suppression de télécommandes planifiées, la réinitialisation duscheduler, etc.7.6.2 Sous-types du service 11Liste des sous-types du service 11 :1. Activation du scheduler (11, 1),2. Désactivation du scheduler (11, 2),3. Réinitialisation du scheduler (11, 3),4. Insertion de télécommandes (11, 4),5. Suppression de télécommandes (11, 5),6. Suppression de télécommandes sur une période de temps (11, 6),7. Rapport reprenant les télécommandes planifiées à bord (11, 13),8. Demande de rapport reprenant les télécommandes planifiées à bord (11, 17).Les télécommandes de type 1, 2 et 3 n’ont aucun paramètre.Les télécommandes de type 4, à la base, permettait l’insertion d’un ensemble detélécommandes à exécuter à bord. Cependant, ce sous-type a été modifié à causede contraintes techniques au niveau du scheduler à bord du satellite et ne permetfinalement que d’insérer une télécommande à la fois.

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 66Les télécommandes de type 5 ont en paramètre la paire (APID, Sequence Count)qui identifie une télécommande dans la file d’attente du scheduler et un entier représentantle nombre de télécommandes à supprimer à partir de la télécommandeidentifiée par la paire (APID, Sequence Count). APID a pour signification ApplicationProcess Identifier et correspond à un processus à bord du satellite.Les télécommandes de type 6 permet de supprimer des télécommandes sur unepériode de temps. Elle prend en argument un entier, qu’on appelle “portée”, etdeux autres paramètres qui sont des dates. Ces champs, appelons les t 1 et t 2 , sontoptionnels en fonction de la valeur du champ “portée”. Les différentes valeurs dupremier argument ont les significations suivantes :• 0 = Suppression de toutes les télécommandes contenues dans le scheduler àbord,• 1 = Suppression des télécommandes dont les dates d’exécution se trouvententre t 1 et t 2 ,• 2 = Suppression des télécommandes dont les dates d’exécution se trouventavant t 1 ,• 3 = Suppression des télécommandes dont les dates d’exécution se trouventaprès t 1 .Comme on peut le constater, les champs t 1 et t 2 sont parfois optionnels selon lavaleur du champ “portée”.La télécommande de type 17 ne prend aucun argument. La télémétrie de type 13est la réponse à la télécommande de type 17 : elle contient le nombre de télécommandesplanifiées à bord du satellite, leurs dates d’exécution et les paires (APID,Sequence Count) les identifiant.7.7 RésuméLe tableau 7.3 est un tableau récapitulatif des télécommandes et des télémétriesfaisant partie des quatre services décrits dans les sections précédentes. Ces quatreservices ont été sélectionnés afin de répondre à tous les besoins essentiels de lamission OUFTI-1. Si ces besoins évoluent, il faudra ajouter des services supplémentairesafin de satisfaire ces besoins.

CHAPITRE 7. PROTOCOLES DE COMMUNICATION 67Type et Sous-Type TC/TM Nom(1, 1) TM Rapport d’acceptation d’une télécommande - Succès(1, 2) TM Rapport d’acceptation d’une télécommande - Échec(1, 3) TM Rapport de démarrage d’une télécommande - Succès(1, 4) TM Rapport de démarrage d’une télécommande - Échec(1, 5) TM Rapport de progression d’une télécommande - Succès(1, 6) TM Rapport de progression d’une télécommande - Échec(1, 7) TM Rapport de fin d’exécution d’une télécommande - Succès(1, 8) TM Rapport de fin d’exécution d’une télécommande - Échec(3, 5) TC Activation de la génération de rapports de données(3, 6) TC Désactivation de la génération de rapports de données(3, 25) TM Rapport de données(8, 1) TC Exécution d’une fonction(11, 1) TC Activation du scheduler à bord(11, 2) TC Désactivation du scheduler à bord(11, 3) TC Réinitialisation du scheduler à bord(11, 4) TC Insertion de télécommandes(11, 5) TC Suppression de télécommandes(11, 6) TC Suppression de télécommandes sur une période de temps(11, 13) TM Rapport reprenant les télécommandes planifiées à bord(11, 17) TC Demande de rapport des télécommandes planifiéesTable 7.3 – Tableau récapitulatif des télécommandes et télémétries de la mission OUFTI-1

Chapitre 8Activités du projet OUFTI-18.1 Interface Technical ReviewUne Interface Technical Review (ITR) est un document qui porte sur les interfacesentre les différents sous-systèmes et blocs fonctionnels d’un projet. En effet,dans des projets de grande envergure, tels que OUFTI-1, il est important de définirles interfaces entre les différents sous-systèmes afin de faciliter le travail futur etcela permet également de connaître le statut d’avancement global du projet.Durant cette année académique, chaque étudiant a dû élaborer un document appeléData Package qui décrit son sous-système et les différentes interfaces qu’il peutavoir avec d’autres sous-systèmes. Après avoir fourni ces documents, l’équipe systèmeOUFTI-1 et des personnes extérieures venant du domaine spatial ont analyséces documents pour faire ressortir les divergences entre les différentes interfaces.Durant un week-end, toute l’équipe s’est réunie à l’Eurospace Center à Redupour résoudre toutes les divergences détectées dans les interfaces.8.2 PrésentationsDurant cette année académique, l’équipe OUFTI-1 a fait plusieurs présentationset a participé à des conférences.Par exemple, l’équipe a participé au forum Union Radio-Scientifique Internationale(URSI) qui a eu lieu à Bruxelles au mois de mai. Cette participation a impliquéla rédaction de résumés sur une partie du sous-système dont chaque membre del’équipe est responsable. Ensuite, ces résumés ont été lus par un jury. Après avoirété sélectionnés, des posters ont été préparés pour cet évènement.Durant l’année académique, chaque étudiant a présenté son sous-système à toutel’équipe afin que chaque membre prenne connaissance du rôle de chaque soussystèmedans le projet et d’acquérir un peu de connaissance dans un autre domaineque leur domaine respectif.68

Chapitre 9Conclusion et développementsfuturs9.1 ConclusionCe travail de fin d’études porte sur le développement du MCC de la station soldu projet OUFTI-1.Une analyse des besoins a été réalisée afin d’identifier les éléments faisant partiedu MCC. Ces différents éléments permettent de satisfaire des besoins tels quel’automatisation de la station sol, la sauvegarde de toutes les données relatives à lamission, l’envoi et la réception de données au satellite, etc. Il a fallu également fixerl’architecture du MCC avec une pensée aux développements futurs. Par exemple,il sera intéressant de pouvoir développer des clients web permettant de voir lesdonnées relatives au satellite.L’ensemble des logiciels développés dans le cadre de ce travail de fin d’études estune base solide pour la suite du projet. Même si des détails spécifiques à la missionsont encore inconnus et ont donc eu un impact sur le développement des logiciels,ces derniers ont été développés de façon modulaire afin que les changements futurspossibles seront facilement intégrés.Une autre face d’un projet comme OUFTI-1 est le travail en équipe. En effet, il afallu également penser aux interactions avec les autres sous-systèmes. Des réunionsavec d’autres personnes responsables d’autres sous-systèmes ont été nécessaires afinde prendre conscience de possibles contraintes mais principalement pour définir lesinterfaces entre ces sous-systèmes. Dans le cadre du travail de fin d’études présent,il a été nécessaire de définir des interfaces avec le sous-système TC/TM.Le nombre d’applications développées dans le cadre de ce travail de fin d’étudesest de cinq. Le lien où sont disponibles le code source et le nombre total de lignesde code de ces logiciels se trouvent dans l’annexe C.Le projet OUFTI-1 est à sa troisième année de développement avec quatorzeétudiants, chacun responsable d’un sous-système du satellite. Même si le projetn’est pas encore opérationnel, des étudiants sont déjà intéressés de travailler surce projet dans le cadre de leur travail de fin d’études.Au final, ce travail de fin d’études m’a permis d’acquérir des connaissances sur69

CHAPITRE 9. CONCLUSION ET DÉVELOPPEMENTS FUTURS 70les éléments composant une station sol dans le cadre d’une mission spatiale maiségalement d’agrandir mon expérience pratique en résolvant des problèmes et enapprenant de nouvelles techniques.9.2 Idées pour les futurs développementsUne idée serait de développer des clients web qui auraient les mêmes fonctionnalitésque le MDV. Les opérateurs pourraient donc passer par Internet pour voirles données relatives au satellite.Le projet OUFTI-1 possède une autre station sol se trouvant à Redu qu’onappelle station backup. Il serait intéressant de mettre en place un système quigérerait ces deux stations. Les rôles de ce système seraient les suivants :1. Assurer la coordination entre les deux stations,2. Sécuriser les données en créant une redondance des données dans les deuxstations.Le premier rôle serait de s’assurer que les deux stations ne communiquent pasen même temps avec le satellite.Le second rôle serait une sécurisation des données relatives à la mission en créantune redondance des données dans les bases de données des deux stations. Parconséquent, lorsqu’une station reçoit des informations du satellite, elle doit envoyerces informations à l’autre station. Un lien sera établi entre les deux stations.Comme mentionné à la section précédente, des données n’étaient précisémentdéfinies lors de l’écriture de ce document, telles qu’une liste exhaustive des mesuresà bord, une liste des SIDs pour la mission, etc. Cela aura une répercussion mineuresur la base de données de mission et également sur le MDV. En effet, il faudramettre à jour la liste des mesures qui peuvent être consultées et les tables de labase de données de mission.Une fois les SIDs définis, on pourrait également intégrer un module supplémentairede visualisation de données en fonction des SIDs dans le MDV.Au final, la tâche la plus importante sera la phase de test après développementde tous les éléments au niveau de la station sol et après imbrication avec les autressous-systèmes. L’objectif de cette étape est de déceler les mauvais comportementsde la station sol dans différentes situations. Une énorme quantité de temps devraêtre réservée à cette phase afin de favoriser les chances de succès du projet.

Bibliographie[1] G. Alder. The JGraph Tutorial. JGraph Ltd, 2003.[2] T. A. Banh. Cryptographie et sécurité informatique. Université de Liège,2008.[3] M. Baron. Java pour le développement de clients lourds - Visualisation d’informations: JTree, JTable et JGraph, Janvier 2009.[4] V. Beukelaers. From Mission Analysis to Space Flight Simulation of OUFTI-1Nanosatellite. Master’s thesis, Université de Liège, Juin 2009.[5] B. Boigelot. Programmation orientée-objet. Université de Liège, 2006.[6] B. Boigelot. Ingénierie du logiciel orienté-objet. Université de Liège, 2008.[7] D. Bosanac. Job scheduling in java. http://oreilly.com/pub/a/java/archive/quartz.html.[8] L. Chiarello. Design and implementation of the control and monitoring systemfor the ground station of nanosatellite OUFTI-1 of the University of Liège.Master’s thesis, Université de Liège, Juin 2009.[9] B. Cosandier and F. George. The TM & TC Packet Definition. Technicalreport, Ecole Polytechnique Fédérale de Lausanne (EPFL), Octobre 2008.[10] L. Danichert. Prise en main de PostgreSQL avec pgAdmin III. http://postgresql.developpez.com/articles/pgdebutants/.[11] H. Etiévant. Expressions régulières en Java avec l’API Regex, Août 2004.[12] S. Galli. Mission Design for the CubeSat OUFTI-1. Master’s thesis, Universitéde Liège, Juin 2008.[13] F. George. SwissCube Ground Segment Software. Présentation à l’ESOC,Août 2008.[14] D. Grimshaw. RMI Introduction. http://www.ryerson.ca/~dgrimsha/courses/cps841/RMIIntro.html.[15] L. Hallbach. OUFTI-1 Mission and System definition, Ver 2.0, Février 2009.[16] C. Jollivet and I. Calapodescu. La FAQ JDBC. http://java.developpez.com/faq/jdbc/, Août 2004.[17] J. Juneau, J. Baker, V. Ng, L. Soto, and F. Wierzbicki. The Definitive Guideto Jython. http://jythonpodcast.hostjava.net/jythonbook/en/1.0/,Mars 2010.71

BIBLIOGRAPHIE 72[18] R. Krpoun, M. Nova, and N. Scheidegger. Mission, Space and Ground SystemDescription. Technical report, Ecole Polytechnique Fédérale de Lausanne(EPFL), Juin 2006.[19] S. Lee, A. Hutputanasin, A. Toorian, W. Lan, and R. Munakata. CubesatDesign Specification, REV.11. Technical report, California Polytechnic StateUniversity, Février 2008.[20] P. Loveall. D-STAR Uncovered.[21] Sun Microsystems. Designing a Swing GUI in Netbeans IDE. http://netbeans.org/kb/docs/java/quickstart-gui.html.[22] Sun Microsystems. Java Remote Method Invocation (Java RMI). http://java.sun.com/javase/6/docs/technotes/guides/rmi/.[23] Sun Microsystems. The Java Tutorials. http://java.sun.com/docs/books/tutorial/.[24] Sun Microsystems. The Swing Tutorial. http://java.sun.com/docs/books/tutorial/uiswing/.[25] J.-Y. Nicolas. Implémentation du protocole PUS au sol et à bord du satellite.Master’s thesis, Université de Liège, 2009.[26] M. Noca, G. Roethlisberger, F. Jordan, N. Scheidegger, T. Choueiri,B. Consandier, F. George, M. Dumont, and R. Krpoun. Project, Mission,Space and Ground System Overview. Technical report, Ecole PolytechniqueFédérale de Lausanne (EPFL), Août 2007.[27] L. Questiaux. Design and implementation of radio frequency equipment ofstudent nanosatellite OUFTI-1. Master’s thesis, University of Liège, 2009.[28] A. Shah and M. Willms. Ground Station Operations. Présentation à l’ESOC,2009.[29] ECSS-E-79-41A Space engineering. Ground systems and operations - Telemetryand telecommand packet utilization. ESA, January 2003.[30] S. Stoff. Orbitron. http://www.stoff.pl.[31] G. Swinnen. Apprendre à programmer avec Python, 2005.[32] D. Teney. Design and implementation of on-board processor and softwareof student nanosatellite OUFTI-1. Master’s thesis, Université de Liège, Juin2009.[33] A. Verheyden. PROBA 2 Ground Segment, Mars 2008.[34] Jack Taylor William A. Beech, Douglas E. Nielsen. AX.25 Link Access Protocolfor Amateur Packet Radio. Technical report, Tucson Amateur PacketRadio Coroporation, Juillet 1998.[35] P. Wolper. Bases de données (organisation générale). Université de Liège,2007.

Annexes73

Annexe AListe des mesures à bord deOUFTI-1Le tableau ci-dessous présente la liste des mesures à bord de OUFTI-1. Ce tableauest extrait du wiki du projet OUFTI-1.74

ANNEXE A. LISTE DES MESURES À BORD DE OUFTI-1 75Identifiant Nom TypeSystème alimentation électrique (EPS)I_SC1 Courant cellule solaire 1 CourantI_SC2 Courant cellule solaire 2 CourantI_SC3 Courant cellule solaire 3 CourantI_SC4 Courant cellule solaire 4 CourantI_SC5 Courant cellule solaire 5 CourantI_SCT Courant cellule solaire total CourantT_BAT Température batteries TempératureT_EPS Température des transistors des batteries CourantV_BAT1 Tension des batteries VoltageV_BAT2 Tension des batteries (redondance) VoltageT_7.0 Température convertisseur 7V TempératureV_3.3 Voltage du bus 3.3V VoltageV_5.0 Voltage du bus 5.0V (OBC1) VoltageV_7.2 Voltage du bus 7.2V (COM/BCN) VoltageT_F1 Température face 1 TempératureT_F2 Température face 2 TempératureT_F3 Température face 3 TempératureT_F4 Température face 4 TempératureT_F5 Température face 5 TempératureT_F6 Température face 6 TempératureSystème de télécommunication (COM)I_COM3.3 Courant 3.3V CourantI_COM7.2 Courant 7.2V (COM) CourantI_BCN7.2 Courant 7.2V (BCN) CourantT_COM7.2 Température amplificateur (COM) TempératureT_BCN7.2 Température amplification (BCN) TempératureTOS1_COM COM TOS (1) -TOS2_COM COM TOS (2) -Système alimentation électrique expérimentale (EPS2)V_OUT_EPS2 Tension convertisseur VoltageI_OUT_EPS2 Courant invertisseur CourantV_DIG_EPS2 Tension circuit digital VoltageI_DIG_EPS2 Courant circuit digital CourantT_FLY_EPS2 Température convertisseur TempératureT_DIG_EPS2 Température circuit digital TempératureI_BCN3.3 Courant 3.3V (BCN) CourantOrdinateur de bord (OBC)T_OBC Température du MSP 430 F1611 TempératureTable A.1 – Liste des mesures à bord de OUFTI-1

Annexe BDiagramme logiciel statiqueB.1 SchedulerFigure B.1 – Diagramme logiciel statique du scheduler76

ANNEXE B. DIAGRAMME LOGICIEL STATIQUE 77B.2 Outil d’envoi manuel de télécommandesFigure B.2 – Diagramme logiciel statique de l’outil d’envoi manuel de télécommandes

ANNEXE B. DIAGRAMME LOGICIEL STATIQUE 78B.3 Outil de planificationFigure B.3 – Diagramme logiciel statique de l’outil de planification

ANNEXE B. DIAGRAMME LOGICIEL STATIQUE 79B.4 Mission Data ViewerFigure B.4 – Diagramme logiciel statique du Mission Data Viewer

Annexe CCode sourceLe code source développé pour ce travail de fin d’études est disponible à l’adressesuivante :http://www.student.montefiore.ulg.ac.be/~nnguyen/tfe/Afin de mesurer la taille des logiciels développés, le nombre de lignes de codesource est utilisé. Le calcul du nombre de lignes de code source est réalisé à l’aidedu logiciel LocMetrics. Deux nombres sont donnés, le premier (non filtré) représentesimplement la somme des lignes dans chaque fichier, tandis que le second(filtré) représente le nombre total de lignes dans chaque fichier en n’incluant pasles lignes de types suivants :• lignes vides,• lignes avec que des commentaires.Les résultats sont représentés dans le tableau C.1.Totalnon filtré 22408filtré 13839Table C.1 – Nombre de lignes de code source.80

Table des figures2.1 CubeSat typique en orbite (source : AAU CubeSat site web officiel) 62.2 Poly Picosatellite Orbital Deployer (source : [19]) . . . . . . . . . . 62.3 Dessin du CubeSat avec ses interrupteurs de déploiement et les ressortsde séparation (source : [19]) . . . . . . . . . . . . . . . . . . . 73.1 Vue générale de la station sol . . . . . . . . . . . . . . . . . . . . . 133.2 Architecture du GS (source [8]). . . . . . . . . . . . . . . . . . . . . 143.3 Captures d’écran de Orbitron, WispDDE et ARSWIN . . . . . . . . 163.4 Traces de l’orbite OUFTI-1 durant 12 heures (source :[12]) . . . . . 174.1 Schéma conceptuel d’un planning . . . . . . . . . . . . . . . . . . . 214.2 Schéma planning de l’équipe SwissCube . . . . . . . . . . . . . . . . 254.3 Flowchart du scheduler . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Capture d’écran du scheduler . . . . . . . . . . . . . . . . . . . . . 294.5 Flowchart de la génération de code . . . . . . . . . . . . . . . . . . 334.6 Flowchart du chargement d’un fichier source . . . . . . . . . . . . . 364.7 Capture d’écran de la fenêtre principale de l’outil de planification . 375.1 Architecture du Mission Control Center . . . . . . . . . . . . . . . . 415.2 Exemple d’une application utilisant Java RMI . . . . . . . . . . . . 445.3 Flowchart de l’outil d’envoi manuel de télécommandes . . . . . . . . 495.4 Capture d’écran de l’outil d’envoi manuel de télécommandes . . . . 505.5 Flowchart du Mission Data Viewer . . . . . . . . . . . . . . . . . . 535.6 Capture d’écran du Mission Data Viewer . . . . . . . . . . . . . . . 546.1 Structure de la base de données de mission . . . . . . . . . . . . . . 59B.1 Diagramme logiciel statique du scheduler . . . . . . . . . . . . . . . 76B.2 Diagramme logiciel statique de l’outil d’envoi manuel de télécommandes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.3 Diagramme logiciel statique de l’outil de planification . . . . . . . . 78B.4 Diagramme logiciel statique du Mission Data Viewer . . . . . . . . 7981

Liste des tableaux2.1 Classification des familles de petits satellites . . . . . . . . . . . . . 57.1 Modèle OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.2 Protocoles utilisés dans le projet OUFTI-1 . . . . . . . . . . . . . . 617.3 Tableau récapitulatif des télécommandes et télémétries de la missionOUFTI-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.1 Liste des mesures à bord de OUFTI-1 . . . . . . . . . . . . . . . . . 75C.1 Nombre de lignes de code source. . . . . . . . . . . . . . . . . . . . 8082