Nanosatellite OUFTI-1 : optimisation du logiciel de bord et développement d un mode de tests au sol. Alexei Dick

Transcription

1 Nanosatellite OUFTI-1 : optimisation du logiciel de bord et développement d un mode de tests au sol. Alexei Dick

2 Préambule Le présent document symbolise l achèvement d un stage de quatre mois, au sein de l équipe OUFTI-1 dans le cadre de mon travail de fin d études. Le sujet de mon travail fut le perfectionnement de l ordinateur de bord du nanosatellite OUFTI-1, ainsi que le développement d un mode qui permet le test complet de celui-ci sans émissions radios. Le premier chapitre introduit le domaine spatial en présentant les différents types de satellites à budget réduit. La suite de ce chapitre est consacrée à l explication du projet OUFTI-1. Le deuxième chapitre permet de rentrer plus dans les détails du nanosatellite. Il s agira de présenter différentes cartes qui composent le nanosatellite, ensuite, une explication du fonctionnement du logiciel de bord. Le troisième chapitre présente la première partie de mon travail : le perfectionnement du logiciel de bord. Cette partie détaille les différents moyens mis en œuvre afin d optimiser l exécution du logiciel à bord de OUFTI-1. Le chapitre qui suit est consacré à la résolution d un problème au niveau du fonctionnement de la redondance des ordinateurs de bord. 1. Enfin le dernier chapitre développe l implémentation du mode de test de OUFTI- 1

3 Remerciements J exprime ma vive reconnaissance à toutes les personnes qui ont collaboré de près ou de loin à la réalisation de ce travail. Je remercie particulièrement mon maître de stage, Thomas Langohr, qui s est toujours montré à l écoute et très disponible tout au long de la réalisation de ce travail. Merci aussi à mon professeur superviseur, Valery Broun, qui m a suivi et encouragé tout au long de ma période de stage. Mes remerciements s adressent également à toute l équipe système du projet OUFTI-1, à savoir Amandine Denis, Jérôme Wertz, Jonathan Pisane, Laurent Chiarello, Nicolas Marchal et Xavier Werner pour leur accueil et leur soutien. Je tiens à exprimer ma reconnaissance envers Kathy Fraiture et Christian Vandermeer qui ont eu la gentillesse de lire et corriger ce travail. Je n oublie pas mes parents pour leur contribution, leur soutien et leur patience. Enfin, j adresse mes plus sincères remerciements à tous mes proches et amis, qui m ont toujours soutenu et encouragé au cours de la réalisation de ce mémoire. Merci à tous et à toutes. 2

4 Liste des acronymes ACK Acknowledgement. ADC Analog to Digital Converter. AM Active Mode. AX.25 Amateur X.25. BCN Beacon. COM Télécommunication. D-STAR Digital Smart Technologies for Amateur Radio. DAC Digital to Analog Converter. EEPROM Electrically Erasable Programmable Read-Only Memory. EPS Electrical Power Supply. I 2 C Inter Integrated Circuit. ICC Individual Current Consumption. JARL The Japan Amateur Radio League. JTAG Joint Test Action Group. LPM Low-Power Mode. MCLK Master Clock. OBC On-Board Computer. OBSW On-Board Software. 3

5 4 OUFTI-1 Orbital Utility For Telecommunication Innovations - 1. P-POD Poly Picosatellite Orbital Deployer. PC Program Counter. POR Power-On Reset. PUC Power-Up Clear. RAM Random Access Memory. RISC Reduced Instruction Set Computer. SCL Serial Clock. SDA Serial Data. SMCLK Sub-Main Clock. SPI Serial Peripheral Interface. SR Status Register. TxRx Transmission-Reception. ULg Université de Liège. USB Universal Serial Bus. USART Universal Synchronous & Asynchronous Receiver Transmitter. WDTCTL Watchdog Control. WDTIFG Watchdog Interrupt Flag. xeps experimental Electrical Power Supply.

6 Table des matières 1 Introduction Les satellites de petite taille Le standard CubeSat Le P-POD Le Projet OUFTI Les charges utiles de OUFTI D-STAR xeps Cellules solaires OUFTI Hardware Le bus PC/ Ordinateur de bord redondant EPS xeps COM

7 TABLE DES MATIÈRES BCN Software Systeme d exploitation temps réel On-Board Software Perfectionnement du logiciel de bord existant Gestion mémoire RAM Analyse de l occupation en mémoire Module Monitor Evénements synchrones Evénements asynchrones Optimisation supplémentaire Redondance Mécanisme de fonctionnement Observation du fonctionnement Explication du problème Le Watchdog Reset du MSP Bloc d initialisation de l OBSW Différentes solutions proposées Redémarrage POR Redémarrage PUC Tests

8 TABLE DES MATIÈRES Simulation de panne software Simulation de panne hardware Développement du Mode sol Le Mode sol Les tests à réaliser Connexion USB Passage en Mode sol Communication des OBC vers l USB Application de l ordinateur superviseur Développement d une application dédiée Fonctionnement du Mode sol sur l OBSW Conclusions 57 Appendices 59 A Sources : 60 B Documents : 62

9 Chapitre 1 Introduction Depuis le lancement de Spoutnik en orbite autour de la Terre le 4 octobre 1957, on a recensé pas moins de satellites envoyés dans l espace. Le domaine spatial s est ainsi vite diversifié, on peut aujourd hui observer trois types de satellites. D abord, ceux destinés à la recherche scientifique comme l observation de l atmosphère terrestre, l étude des différentes lois physiques ou encore l observation de l espace. Ensuite, on retrouve les satellites dits commerciaux, c est-à-dire des dispositifs qui ont été développés par des sociétés privées afin de pouvoir proposer différents services comme la télécommunication ou le positionnement. Enfin, il y a les satellites militaires. Malgré les énormes bonds en avant dans le domaine de la technologie qui ont permis de sécuriser les mises en orbite, le domaine spatial reste très peu accessible. En effet, le budget à consacrer pour un projet d une telle envergure est colossal et dépasse de loin celui d une petite organisation. Néanmoins, grâce à la miniaturisation des composants électroniques, il est depuis peu devenu possible de développer un satellite à budget réduit. 1. Source [1] 8

10 CHAPITRE 1. INTRODUCTION Les satellites de petite taille. La solution implique le développement d un satellite de petite taille, accordant une forte diminution des dépenses engendrées par le lancement. Réduire la masse permet d utiliser des lanceurs plus petits et moins chers. L économie est d autant plus remarquable quand la miniaturisation du satellite tend vers le maximum, ce qui a pour avantage de ne pas monopoliser tout l espace disponible dans la fusée et de profiter du peu d espace libre accordé lors d un lancement de satellite de taille traditionnelle. Voici le classement 2 des satellites de petite taille qui a été fait suivant la masse ainsi que le coût total [1.1] : 31 M 9 M 1.3 M 0.13 M < 0.13 M Minisatellite Microsatellite Nanosatellite Picosatellite Futur 500kg 100kg 10kg 1kg 0,1kg Figure 1.1 Classement de différents satellites de petite taille. Source [3] Minisatellite : Satellite de masse comprise entre 100 et 500kg. Le développement est simplifié par rapport aux gros satellites mais la même technologie est souvent utilisée, des propulseurs peuvent donc y être installés afin de pouvoir contrôler son altitude. Microsatellite : Satellite de masse comprise entre 10 et 99,99kg. Le développement à base de nouvelles technologies et la miniaturisation afin d optimiser l espace se fait ressentir. Des propulseurs plus petits peuvent toutefois être embarqués. 2. Source [2]

11 CHAPITRE 1. INTRODUCTION 10 Nanosatellite : Satellite de masse comprise entre 1 et 9,99kg. La technologie la plus avancée est largement utilisée afin de réduire la masse et le volume, les propulseurs sont abandonnés. Ce type de satellite peut être embarqué en tant que passager secondaire d un lanceur destiné à un gros satellite. Picosatellite : Satellite de masse comprise entre 0,1 et 0,99kg. Réduction du poids et du volume au maximum grâce à la miniaturisation maximale. Les Picosatellites profitent également d un lanceur destiné à un gros satellite. Les plus petits satellites comme les Nano ou les Pico embarquent souvent une technologie innovante à bord, pour pouvoir en tester le fonctionnement dans un environnement spatial. Pour être acceptés en tant que passagers secondaires, ces satellites doivent assurer qu aucun dommage ne sera occasionné sur le satellite principal entre le décollage et la mise en orbite. 1.2 Le standard CubeSat. En 1999, les universités de Californie et de Stanford ont collaboré sur la mise en place d un standard de satellite de petite taille : le standard CubeSat. Le but principal de cette association était de fournir une norme pour la conception de petits satellites afin d en réduire le coût de production et les délais de développement, et ainsi accroitre l accessibilité à l espace et avoir un rythme de lancement soutenu. La standardisation fut un succès, car à l heure actuelle, le projet CubeSat rassemble plus d une centaine d universités et entreprises privées. Pour être considéré comme CubeSat, un satellite doit répondre favorablement à tous les critères imposés par la spécification du standard [1.2].

12 CHAPITRE 1. INTRODUCTION 11 Figure 1.2 Structure métallique d un CubeSat. Source [4] Voici quelques critères importants du standard : Le Cubesat doit avoir le volume d un litre et peser moins de 1,33kg. Le CubeSat doit se présenter sous la forme d un cube de 100mm de côté. Il faut aussi ajouter à cela la hauteur des pieds du satellite qui est de 13,5mm [1.3]. Le centre de gravité doit se trouver à maximum 2cm du centre géométrique du CubeSat. Le CubeSat ne peut pas être un danger pour les CubeSats avoisinants, pour le lanceur ou pour le satellite principal. Aucune partie du CubeSat ne peut être amovible. Aucun système pyrotechnique ne peut se trouver à bord du CubeSat. Le déploiement des antennes ne peut être effectué que 30 minutes après la mise en orbite du CubeSat. Aucune émission radio ne peut être effectuée avant la mise en orbite du CubeSat.

13 CHAPITRE 1. INTRODUCTION 12 Figure 1.3 Dimensions imposées par le standard CubeSat. Source [5] Ces critères sont applicables au CubeSat de format 1U. Néanmoins, il existe d autres formats qui correspondent à 1.5, 2 ou 3 fois la taille d un CubeSat 1U. Ces différents formats sont représentés sur la figure [1.4]. Les critères pour le standard restent bien évidemment les mêmes, seule la hauteur varie. Figure 1.4 Differents formats de CubeSat. Source [6]

14 CHAPITRE 1. INTRODUCTION Le P-POD. Afin que les CubeSats puissent intégrer un lanceur en tant que passager secondaire, un standard de déployeur a également été développé pour assurer la sécurité des CubeSats et celle du satellite principal, le Poly Picosatellite Orbital Deployer (P-POD). Le P-POD a une contenance de 3U, il est équipé d une porte et d un ressort compressé dans le fond. Le fonctionnement du déployeur est assez simple : dès que le lanceur a atteint l altitude désirée, la porte s ouvre et le contenu du P-POD est expulsé à l aide du ressort. La figure [1.5] montre à gauche le P-POD en entier et à droite une coupe faisant apparaitre le ressort. Figure 1.5 P-POD. Source [5] 1.4 Le Projet OUFTI-1. Le projet OUFTI-1 (Orbital Utility For Telecommunication Innovations - 1) est un projet de nanosatellite de type CubeSat développé à l Université de Liège (ULg) depuis Le projet est mené entièrement par des étudiants dans le cadre de travaux de fin d études. C est le premier projet étudiant de CubeSat belge et l objectif principal de cette initiative est de fournir aux étudiants une expérience aussi bien théorique que pratique dans la conception d un satellite.

15 CHAPITRE 1. INTRODUCTION Les charges utiles de OUFTI-1. Le satellite embarque trois charges utiles de démonstration technologique. Les données de ces tests vont être enregistrées et envoyées à la station sol pour analyse D-STAR. Digital Smart Technologies for Amateur Radio (D-STAR) est un protocol de communication développé par l association des radioamateurs japonais (JARL) en C est un protocole numérique qui permet la communication de voix et données simultanément sur les bandes radioamateurs classiques (VHF, UHF et micro-ondes). Le D-STAR propose également une connexion réseau permettant aux radios d être connectées à Internet et à d autres réseaux, ainsi que des moyens de router des flux voix ou données grâce aux indicatifs radioamateurs. OUFTI-1 sera donc le premier relais D-STAR grâce auquel deux individus pourront être reliés à des distances beaucoup plus grandes que celles offertes par des antennes terrestres xeps. La seconde payload est l experimental Electric Power Supply (xeps), une alimentation électrique nouvelle génération dont la particularité est le convertisseur de tension numérique chargé de réguler du 3,3V. L intérêt de l expérimentation à bord de OUFTI-1 est que l xeps n a jamais encore été testée dans un environnement spatial. La réussite de la mission pourrait ouvrir des portes à une meilleure gestion d alimentation dans les satellites du futur.

16 CHAPITRE 1. INTRODUCTION Cellules solaires. Pour assurer son alimentation électrique, OUFTI-1 utilise des cellules solaires à haut rendement fournies par la société AZUR SPACE Solar Power. Ces cellules peuvent atteindre un rendement de 30%.

17 Chapitre 2 OUFTI-1 Ce chapitre présente les différentes composantes qui permettent le bon fonctionnement de OUFTI-1. Il passera en revue les cartes dont est constitué le satellite ainsi que la connectique qui permet l intercommunication. Ensuite, le fonctionnement du logiciel de gestion sera détaillé. 2.1 Hardware. OUFTI-1 est composé de plusieurs cartes interconnectées par un bus PC/104 [2.1] : OBC Backup. OBC Default. EPS. xeps. COM. 16

18 CHAPITRE 2. OUFTI-1 17 COM xeps EPS OBC Default OBC Backup Figure 2.1 Agencement des cartes de OUFTI-1. Source [7] Le bus PC/104. Toutes ces cartes qui constituent le satellite sont équipées d un connecteur PC/104. Ces cartes se connectent entre elles. En effet, l extrémité femelle est placée au dessus de la carte et l extrémité male est placée en dessous. Il y a une exception : la carte qui se situe à la base du satellite ne possède qu un connecteur femelle pour des raisons évidentes. Ce bus constitue la colonne vertébrale de OUFTI-1. Le flux de communication interne ainsi que l alimentation des cartes (OBC Default, OBC Backup et COM) sont assurées par le PC/104. Différentes fonctions ont été attribuées au 104 broches du connecteur, ces fonctions sont décrites dans le document [B] Ordinateur de bord redondant. Afin d améliorer la fiabilité du satellite, la solution d intégrer deux ordinateurs de bord avec une gestion de la redondance a été adoptée. La carte OBC Backup est l ordinateur de bord de secours de OUFTI-1, sa fiabilité n est plus à prouver étant donné qu elle possède déjà un héritage de vol. Elle est distribuée par la société PUMKIN sous le nom FM430. La carte FM430 [2.2] est une carte polyvalente car

19 CHAPITRE 2. OUFTI-1 18 elle possède beaucoup de composants. Cependant, la plupart de ceux-ci ne sont pas utiles pour la mission de OUFTI-1. Figure 2.2 OBC Backup. Source [8] L OBC Default [2.3] est l ordinateur de bord par défaut. C est lui qui contrôlera la totalité du satellite tant qu aucune panne n est détectée. Dans le cas d un disfonctionnement, l OBC Backup doit être en mesure de reprendre la main, continuer l exécution et rendre la main à l OBC Default dès que celui-ci est de nouveau opérationnel. La carte de l ordinateur de bord principal a été complètement développée par les étudiants du projet OUFTI-1 des années précédentes. Cette carte est une copie de la partie utile de la FM430. De plus une mémoire de stockage (EEPROM) y a été installée afin de pouvoir sauvegarder les différentes mesures.

20 CHAPITRE 2. OUFTI-1 19 Figure 2.3 OBC Default. Source [8] Le Microcontrôleur MSP430. La carte FM430 est construite autour d un microcontrôleur MSP340 distribué par la société Texas Instrument. Cette famille de microcontrôleurs est particulièrement bien adaptée à une application telle qu un nanosatellite. D une part par son faible coût et d autre part grâce à sa basse consommation. Le MSP430 posséde plusieurs modes de fonctionnement qui sont représentés sur la figure [2.4] avec leurs consommations si le microcontrôleur est alimenté en 3 ou 2.2V. Voici les caractéristiques des MSP430 : Architecture RISC 16-Bit. Plage d alimentation faible, de 1.8 à 3.6V. Consommation très faible. Bascule du mode basse consommation vers le mode actif en moins de 6ms.

21 CHAPITRE 2. OUFTI-1 20 ADC 12-Bit. 2 DAC. Timer A 16-Bit. Timer B 16-Bit. Interface de communication série (USART0), fonctionne en asynchrone USART ou synchrone en SPI ou I2C. Interface de communication série (USART1), fonctionne en asynchrone USART ou synchrone en SPI. Figure 2.4 Consommation MSP430. Source [9] ICC : Individual Current Consumption AM : Active Mode LPM : Low-Power Mode La figure [2.5] représente l architecture des microcontrôleurs MSP430.

22 CHAPITRE 2. OUFTI-1 21 Figure 2.5 Architecture MSP430.Source [9] Le bus I 2 C. Inter Integrated Circuit (I 2 C) est un bus de communication série synchrone. Cette technologie utilise deux fils : SDA pour les données, SCL pour le signal sur lequel la communication sera synchronisée. Une hiérarchie maître multi-escalve est utilisée à bord d OUFTI-1 pour permettre la communication entre les composants suivants : Les deux ordinateurs de bord (gestion de la redondance). La mémoire EEPROM. Les différents convertisseurs A/D pour la récupération des données comme le voltage des batteries ou les différentes températures (batteries, carte EPS ou encore la température des différentes faces du satellite).

23 CHAPITRE 2. OUFTI-1 22 Le bus UART. Universal Asynchronous Receiver Transmitter (UART), est un bus de communication série utilisé dans OUFTI-1 pour faire communiquer la carte COM et l ordinateur de bord. La communication peut s effectuer dans deux sens en même temps, en utilisant un fil pour l émission et un autre pour la réception. La mémoire EEPROM La Electrically-Erasable Programmable Read-Only Memory (EEPROM) est connectée au bus I2C de sorte à être accessible depuis n importe quel OBC grâce à la connectique PC/104. La mémoire est un modèle 24xx1025 de chez MAXIM TM. Voici la liste de ses principales caractéristiques : Capacité de 1Mo (2 x 512Ko). Basse consommation (5mA en écriture / 500µA en lecture / 100nA au repos). Compatible I 2 C. Différents modes d écriture, par octets ou par pages(128 octets maximum). L EEPROM sert à enregistrer tous les flags utiles à la bonne exécution de l ordinateur de bord, par exemple l état des antennes ou le temps écoulé depuis la mise en orbite. Elle sert également à la sauvegarde du Log et de toutes les mesures. L espace de l EEPROM a été divisé comme représenté sur la figure [2.6].

24 CHAPITRE 2. OUFTI EPS. Figure 2.6 Division EEPROM. Source [10] La Electrical Power Supply (EPS) est la carte chargée de la gestion de l énergie électrique à bord de OUFTI-1. Ces différentes fonctions sont : Distribution de trois tensions électriques (3.3V, 5V, 7.2V) via le connecteur PC/104 (Annexe [B]). Génération de puissance électrique grâce aux panneaux solaires. Stockage du surplus d énergie dans les batteries.

25 CHAPITRE 2. OUFTI-1 24 Les convertisseurs A/D de l EPS sont accessibles via le bus I 2 C afin de pouvoir récupérer la valeur de la tension des batteries ou la température des différentes faces du satellite xeps. L xeps est une charge utile secondaire du satellite (voir charges utiles) COM. Constituée d émetteurs et récepteurs, la carte COM est le lien qui relie le satellite à la Terre. L ordinateur de bord d OUFTI-1 a la possibilité de recevoir des télécommandes et d émettre des télémétries sur les ondes radio en utilisant le protocole AX.25. L encodage et le décodage des trames AX.25 est de sa responsabilité. Pour pouvoir recevoir et envoyer ces trames, l ordinateur de bord doit configurer les émetteursrécepteurs ADF7021 qui sont mis à disposition par la carte COM. La carte COM gère également la charge utile principale du satellite : le répéteur Digital Smart Technologies for Amateur Radio (D-STAR) en mode voix pour les télécommunications radioamateur BCN. La Beacon (BCN) n est pas vraiment une carte séparée, c est un ensemble de composants qui occuperont la place vide sur la carte OBC Default afin d optimiser l espace. La Beacon est la balise morse de secours du satellite. Une transmission continue de douze mesures caractéristiques du satellite sera assurée indépendamment de l ordinateur de bord.

26 CHAPITRE 2. OUFTI Software Systeme d exploitation temps réel. Le fonctionnement de l ordinateur de bord est assuré par un système d exploitation temps réel. Le système FreeRTOS 1 a été choisi pour les raisons suivantes : Il est compatible avec le microcontrôleur utilisé. Programmation en langage C. C est un système qui gère le multitâche. Les tâches peuvent avoir des niveaux de priorités différentes. Toute exécution est préemptible par une exécution de plus haute priorité. C est-à-dire qu une tâche en exécution peut immédiatement être interrompue par une tâche de plus haute priorité ou une interruption. Une protection peut être mise en place grâce aux sémaphores. Les sémaphores peuvent être utilisés avec un délai d attente afin d éviter un inter blocage. L image binaire ne dépasse pas les 9Kbytes. Il s agit d un système d exploitation gratuit On-Board Software. L On-Board Software (OBSW) est le logiciel de gestion de l ordinateur de bord. L ensemble du satellite dépend de ce logiciel, seules l alimentation (EPS) et la balise morse (BCN) peuvent fonctionner de façon autonome. Tout comme le système d exploitation sur lequel il s exécute, l OBSW est écrit en langage C. Le logiciel est constitué de six modules et de drivers. Les modules représentent la 1. Source [13]

27 CHAPITRE 2. OUFTI-1 26 partie applicative. Chaque module contient une tâche qui s exécute en boucle à une fréquence régulière et des fonctions qui lui permettent de remplir le rôle qui lui a été attribué. Les drivers sont quand à eux, la couche d abstraction entre les modules et le matériel. Voici six modules de l OBSW [2.7] avec leurs rôles respectifs ainsi que l exécution de celui-ci, soit par interruption soit par demande de la tâche en exécution. Référence temporelle Interruptions Réception AX.25 COM UART Sous-syst. FAULT et NMI Envoie AX.25 Modules COM Rx Sequencer Measurement Monitor Log COM Tx Config. ADF Rx Exécution des TC Prise des mesures Déploiement des antennes Entretien journal Configuration ADF Tx Rôles Décodage AX.25 Envoie corrections Doppler Stockage des mesures Gestion redondance Rapatriement journal Encodage AX.25 Stockage TC Rapatriement des mesures Surveillance Drivers I²C UART ADC EEPROM USB Figure 2.7 Composition de l OBSW. En ce qui concerne la référence temporelle, toutes les secondes, une interruption est générée grâce au Timer B du microcontrôleur. L interruption lance une routine qui est chargée d incrémenter un compteur qui sert de référence temporelle. La référence temporelle est codée sur 32 bits, ce qui permet d atteindre un nombre non signé d une valeur de secondes soit environ 136 ans. La durée de la mission de OUFTI-1 étant d un an, c est plus que nécessaire.

28 CHAPITRE 2. OUFTI-1 27 Log. Le module Log est responsable de l enregistrement d un journal d événements survenant à bord du satellite dans la EEPROM. Ces données sont enregistrées avec une référence temporelle. Elles peuvent ensuite être récupérées par le module COM Tx pour être encodées dans une trame AX.25 et être envoyées au sol. Measurement. Le module Measurement est le module responsable de la prise des mesures hardware et software de l ensemble du satellite. Ces mesures sont ensuite stockées dans l EEPROM avec la référence temporelle correspondant au moment où elles ont été prises. Ce module est aussi responsable du rapatriement de ces mesures. Monitor. Le Monitor est la tâche la plus prioritaire du satellite. Une fois OUFTI-1 expulsé dans son orbite, le monitor s exécute et met en pause toutes les autres tâches pour pouvoir attendre 30 minutes avant le déploiement des antennes. Dès que les antennes sont déployées ou que le délais d attente a été dépassé, le Monitor débloque les tâches et se met en surveillance de certains paramètres vitaux du satellite. La réinitialisation du Watchdog de l ordinateur de bord est efféctuée par le Monitor. Ce module est également responsable du changement de mode de OUFTI-1 qui sont repris dans le tableau [2.1].

29 CHAPITRE 2. OUFTI-1 28 EPS BCN OBC Rx AX.25 Tx AX.25 D-STAR xeps OFF SAFE ON ON ON ON DEFAULT ON ON ON ON ON SILENCE ON ON ON D-STAR ON ON ON ON ON XEPS ON ON ON ON ON ON FUNMODE ON ON ON ON ON ON Table 2.1 Modes de fonctionnement de OUFTI-1 Sequencer. Le Sequencer surveille la table des télécommandes en boucle et se charge d exécuter celles qui sont prêtes à être exécutées. Il est également responsable de l envoi des corrections Doppler au sous-système COM. COM Rx. COM Rx est le module est qui est chargé de la réception des télécommandes encodées en AX.25. La réception s effectue grâce à une routine d interruption. Dès qu une télécommande est recue, le module la décode. Si elle ne contient pas d erreur, elle est placée dans la table des télécommandes en attendant d etre exécutée par le Sequencer. Dans le cas contraire, un message d erreur AX.25 est renvoyé au sol. COM Rx doit aussi ponctuellement reconfigurer l ADF Rx de la carte COM. COM Tx. Le module COM Tx est responsable de l encodage des télémétries en AX.25 et leurs émissions. Dès qu une télémétrie est prête à être envoyée, une routine d interruption est chargée de transmettre ces données à l ADF Tx de la carte COM. COM Tx doit aussi ponctuellement reconfigurer l ADF Tx.

30 Chapitre 3 Perfectionnement du logiciel de bord existant bord. Ce chapitre va exposer les différentes phases de perfectionnement du logiciel de 3.1 Gestion mémoire RAM Analyse de l occupation en mémoire. Le tableau [3.1] montre la capacité mémoire du microcontrôleur (MSP430F1612), ainsi que l espace utilisé avant toute modification dans le code de l ordinateur de bord : MSP43OF1612 OBSW Flash 55KB 30KB RAM 5KB 4.9KB Table 3.1 Occupation de la mémoire RAM. 29

31 CHAPITRE 3. PERFECTIONNEMENT DU LOGICIEL DE BORD EXISTANT30 La mémoire RAM devient insuffisante pour les fonctionnalités qui doivent encore être implémentées. Une lecture du code source de l ordinateur de bord a permis de détecter quelques consommations de mémoire inutiles, comme par exemple des déclarations de variables inutilisées ou des fonctions de test et debugging non commentés. Ainsi quelques octets ont pu être épargné. Or, comparé au besoin du projet, c est insuffisant. Une optimisation plus poussée pourrait occasionner des erreurs et rendre le code quasiment illisible. Etant donné que le code de OUFTI-1 est modifié par des developpeurs différents chaque année, il est souhaité de garder un code bien documenté et lisible. De plus, il n est pas certain que l espace gagné par une optimisation plus poussée suffira pour les fonctionnalités qu il reste à implémenter. Une autre solution a été étudiée, celle d un éventuel changement de microcontrôleur pour un autre, équipé davantage d espace RAM. Par soucis de compatibilité, la recherche a été effectuée parmi les microcontrôleurs MSP430 et c est le MSP430F1611 qui a été retenu comme candidat idéal. En effet, les seules différences qu il existe entre les deux microcontrôleurs sont les suivantes : Le MSP430F1611 possède 10KB d espace RAM, c est-à-dire le double du microcontrôleur utilisé jusqu à présent. Le MSP430F1611 est équipe d un peu moins de mémoire flash servant à accueillir le code source du logiciel. Mais vu la taille réduite de celui-ci (30KB), l espace mémoire proposé (48KB) est plus que suffisant. Contrairement au MSP430F1612, le 1611 ne possède pas d héritage de vol. Cependant, le procédé de fabrication est exactement le même pour les deux microcontrôleurs, seule la capacité mémoire change. Il n y a donc aucune raison valable pour que ce microcontrôleur ne fonctionne pas correctement. Le changement des cartes (voir photo [3.1]) a été effectué par la société Microsys

32 CHAPITRE 3. PERFECTIONNEMENT DU LOGICIEL DE BORD EXISTANT31 situé dans le parc scientifique de Liège. Figure 3.1 Changement des microcontrôleurs. 3.2 Module Monitor. Le module monitor est la tâche la plus prioritaire du satellite, elle doit donc être en mesure de surveiller tous les paramètres vitaux de OUFTI-1 et réagir à chaque type d événement Evénements synchrones. Les mesures des paramètres vitaux sont enregistrés par le module Measurement et stockés en RAM avant d être archivés dans la mémoire EEPROM. Le monitor a accès à la RAM et peut consulter les valeurs enregistrées par le module Measurement. C est un avantage en terme de temps d accès par rapport à une lecture de la dernière valeur enregistrée en EEPROM.

33 CHAPITRE 3. PERFECTIONNEMENT DU LOGICIEL DE BORD EXISTANT32 La figure [3.2] représente la chaine complète d acquisition des mesures au sein de OUFTI-1 : I_SC1 I_SC2 EPS I_SC3 I_SC4 I_SC5 T_BAT1 T_BAT2 T_EPS T_F6 T_F5 T_F4 T_F3 T_F2 T_F1 V_BAT V_3.3 V_5.0 V_7.2 ADS7830 Addr : 0X0090 MAX1039 Addr : 0X0065 I2C SCL I2C SDA OBC (I2C MASTER) Measurement (task) Acquisition xeps V_OUT_EPS2 I_OUT_EPS2 V_DIG_EPS2 I_DIG_EPS2 T_FLY_EPS2 T_DIG_EPS2 ADS7830 Addr : 0x0096 EEPROM Enregistrement RAM MEAS COM I_COM_DSTAR I_COM_AX25 I_COM_TX T_COM7.2 TOS1_COM TOS2_COM ADC MSP COM UART Figure 3.2 Acquisitions des mesures au sein de OUFTI-1. Toutes ces mesures sont sauvegardées sur la EEPROM. Cependant, elles ne sont pas toutes prises en considération par le module Monitor. Jusqu à maintenant, il a été convenu que seule la mesure de la tension des batteries est cruciale et mérite une action particulière. En effet, si la tension des batteries n est pas contenue dans une plage de valeurs acceptables, le Monitor met le satellite en SAFE MODE. Pour les autres données, toute valeur particulière entraînera l enregistrement d une alerte dans le journal des événements. L action du monitor est une action synchrone, c est-à-dire que le monitor ne pourra agir que quand il exécute une surveillance, pas forcément au moment même de l événement.

34 CHAPITRE 3. PERFECTIONNEMENT DU LOGICIEL DE BORD EXISTANT Evénements asynchrones. Hormis les événements synchrones gérées par le Monitor, il se peut qu un événement asynchrone soit déclenché. Ce genre d alerte exige une réaction immédiate, la gestion doit donc se faire dans une routine d interruption. Voici les différentes alertes et les actions correspondantes : Interruption MEAS FAULT EEPROM FAULT xeps FAULT COM 7.2 FAULT COM 3.3 FAULT Non-Maskable Interrupt(NMI) Action Demande de redémarrage du sous-système Demande de redémarrage du sous-système Demande de redémarrage du sous-système Demande de redémarrage du sous-système Demande de redémarrage du sous-système Redémarrage de l ordinateur de bord Table 3.2 Interruptions critiques Une NMI peut être déclenchée par une violation d accès à la mémoire flash ou une anomalie avec l oscillateur. Dans les deux cas, un redémarrage de l ordinateur de bord est nécessaire. 3.3 Optimisation supplémentaire. Les fonctionalités suivantes ont été ajoutées au code de l ordinateur de bord : Sauvegarde perpetuelle de la référence temporelle. Ainsi, même si l ordinateur de bord redémarre, la valeur est récuperée pour la suite de l exécution. Sauvegarde des compteurs de démarrage des deux OBC. Chaque OBC s est vu attribuer un compteur qui est incrémenté à chaque démarrage. La valeur du compteur est sauvegardée avec la référence temporelle qui y correspond. Ainsi, il sera possible, en récuperant la valeur, de savoir combien de fois chaque OBC a démarré et à quand date le dernier démarrage. La tache Monitor est chargée de sauvegarder ces données dans la mémoire EE- PROM.

35 Chapitre 4 Redondance Un mécanisme de redondance de l ordinateur de bord a été développé les années précédentes. Sa robustesse n a toutefois pas été démontrée car il subsiste un problème dans son fonctionnement. Ce chapitre sera consacré à l élaboration d une solution. D abord, une explication du fonctionnement de la redondance. Ensuite, une observation du problème et de la source de celui-ci. Et enfin, les différentes solutions proposées et celle qui à été retenue. 4.1 Mécanisme de fonctionnement. Les broches des deux OBC sont connectées entre elles. Pour éviter les courtscircuits dans le cas où les deux OBC auraient la même broche configurée en sortie, des résistances ont été placées en série sur chacune des broches. Lors de la mise sous tension du satellite, les microcontrôleurs des deux ordinateurs de bord démarrent l exécution de leur software. Etant donné que la communication entre les deux OBC via I 2 C est possible seulement si une hiérarchie maître- 34

36 CHAPITRE 4. REDONDANCE 35 esclave est configurée, une temporisation différente a été mise en place sur chaque OBC. Ainsi au démarrage, ils sont tous les deux configurés en esclaves. Puis l ordinateur ayant la temporisation la plus courte démarrera en premier et sera configuré en tant que maître du bus I 2 C. L OBC Default a été configuré pour prendre la main en premier sur le bus I 2 C, comme illustré sur la figure [4.1]. Boot Boot Esclave I²C Esclave I²C 1xT Maitre I²C 2xT Maitre I²C Default OBC Backup OBC Figure 4.1 Configuration maître/esclave du bus I 2 C A partir du moment où le Default est maître du bus I 2 C, il signale son exécution en envoyant périodiquement un message appelé ALIVE1 à destination de l OBC Backup. Dès que ce message est reçu par le Backup, une routine d interruption est exécutée. Elle remet le compteur de la temporisation à 0 en retardant ainsi son

37 CHAPITRE 4. REDONDANCE 36 démarrage. Le Backup reste en mode faible consommation (LPM1 voir figure [2.4]). La figure [4.2] représente le maintien du Default en veille. Boot Boot Esclave I²C LPM1 Routine d interruption: reception ALIVE 1 cptbackup = 0 Esclave I²C LPM1 FAUX FAUX cptdefault > 1xT cptbackup > 2xT VRAI Maitre I²C Via I²C VRAI Maitre I²C Envoie ALIVE1 Default OBC Backup OBC Figure 4.2 Maintien de Backup en veille Si une panne survient sur l OBC Default et qu il est dans l incapacité d envoyer le message ALIVE1, le compteur de Backup arrivant à terme le fait sortir de veille et le configure en tant que maître de l I 2 C. L ordinateur de bord de secours va périodiquement envoyer un message appelé ALIVE2 sur le bus I 2 C à déstination de l ordinateur Default. Dans le cas où celui-ci est de nouveau opérationnel, il recevra le message et répondra avec un ACK. Dès que cet ACK est capté, Backup redémarre laissant ainsi Default reprendre la

38 CHAPITRE 4. REDONDANCE 37 main. La figure [4.3] représente une séquence complète de la gestion de redondance. Boot Boot Esclave 1xT I²C 2xT Maitre I²C ALIVE1 ALIVE1 Esclave I²C 2xT ALIVE2 ALIVE2 Maitre I²C Esclace I²C ACK ALIVE2 Maitre I²C ALIVE1 Esclave I²C ALIVE1 Default OBC ACTIVE MODE LOW POWER MODE OFF Backup OBC Figure 4.3 Séquence complète de redondance 4.2 Observation du fonctionnement. Après avoir effectué quelques tests un problème est apparu. Pour vérifier le fonctionnement de la redondance, il a fallu simuler une panne logicielle. Cette panne est une boucle infinie placée dans le code source. Une fois entré dans la boucle, l ordinateur de bord principal n est plus capable d envoyer ALIVE1 à l ordinateur de bord de secours. A ce moment-là, l OBC Backup prend bien la main et commence

39 CHAPITRE 4. REDONDANCE 38 son exécution. Le problème se pose quand l ordinateur principal doit reprendre la main, aucun signe de vie n est reçu même après une très longue période. Pour prouver que l ordinateur de bord est capable de redémarrer lorsque celui-ci a perdu la main, des tests ont été pratiqués sur une carte séparée. Il est apparu que le système de redémarrage agit bien mais que le microcontrôleur n arrive jamais à lancer les tâches de l OBSW. Sur le schéma [4.4] on peut observer l exécution de l OBSW ainsi que le problème du redémarrage. Redémarrage MAIN Bloc d initialisation Execution des tâches de l OBSW Création tâches Mise en place du Scheduler Première exécution Deuxième exécution Panne Rupture d exécution Figure 4.4 Problème de la redondance Il a été observé qu après le redémarrage, c est dans le bloc d initialisation que l exécution s arrête et fait redémarrer l ordinateur en boucle. 4.3 Explication du problème. Pour comprendre le phénomène, il faut se pencher davantage sur le système qui permet au microcontrôleur de redémarrer.

40 CHAPITRE 4. REDONDANCE Le Watchdog. Watchdog ou chien de garde est un compteur qui permet d assurer que l OBSW ne sera pas bloqué à une étape particulière. Ce compteur est régulièrement remis à zéro par la tâche Monitor. Si jamais il déborde, le Watchdog déclenche un redémarrage du système et positionne WDTIFG à 1. Le Watchdog du MSP430 peut être configuré de deux manières : Mode Timer : Ce mode permet de déclencher une routine d interruption à chaque débordement du compteur. Mode Watchdog : Le débordement du compteur provoque un redémarrage. (configuration actuelle) Reset du MSP430. Sur la figure [4.5] il apparaît que ce microcontrôleur démarre de façon différente s il s agit de la mise sous tension ou s il s agit d un redémarrage suite à un débordement du Watchdog. Figure 4.5 MSP430 POR et PUC

41 CHAPITRE 4. REDONDANCE 40 POR. Power-On Reset (POR) est un redémarrage complet du microcontrôleur qui ne peut être déclenché que par deux événements : Mise sous tension du microcontrôleur. Un signal bas sur RST/NMI quand celui-ci est configuré en mode reset. PUC. Power-Up Clear (PUC) est un redémarrage partiel du microcontrôleur. Voici les événements qui peuvent déclencher ce genre de reset : Un POR est toujours suivi d un PUC. Déclenchement du Watchdog après débordement du compteur. Violation d accès au registre de contrôle du Watchdog. En effet, la configuration de celui-ci doit être accompagnée d un mot de passe, auquel cas une violation d accès est déclenchée. L opération suivante (WDTCTL = 0) permet de générer une violation et donc de redémarrer l ordinateur de bord manuellement. Violation d accès de la mémoire flash. Dans le cas d un PUC, seul le software est réinitialisé, c est-à-dire : Status register (SR) est reseté. Program counter (PC) est initialisé avec la valeur (FFFEh) localisation du vecteur de redémarrage. Toutes les interruptions sont inhibées. La figure [4.6] montre la machine à états du microcontrôleur, le passage dans modes d execution ainsi que les événements qui déclenchent les différents resets.

42 CHAPITRE 4. REDONDANCE 41 Figure 4.6 MSP430 exécution Bloc d initialisation de l OBSW. Dès le démarrage du programme dans le main, une séquence d initialisation est exécutée. Celle-ci contient les initialisations suivantes : msp430 initclocks() - Initialisation de l oscillateur (XT2) suivi de sa définition en tant que Master clock (MCLK) et que Sub-main clock (SMCLK). i2c init() - Configuration de l USART0 pour la communication I 2 C. communication init() - Initialisation de la communication via la connectique USB. sequencer init() - Création de sémaphore et initialisation du tableau qui va accueillir les futures télécommandes. ComRx init() - Reset des différentes variables utilisées pour la récéption de télécommandes.

43 CHAPITRE 4. REDONDANCE 42 ComTx init() - - Reset des différentes variables utilisées pour la transmission des télémétries. msp430 initio() Initialisation de toutes les broches du MSP430. Désactivation des coutaux thérmiques et de l xeps. Activation de l acquisition des mesures, la COM et la mémoire EEPROM. clock init() - Initialisation du Timer B qui sert à la référence temporelle. Etant donné qu après un redémarrage toutes les interruptions sont inhibées, tout se passe bien. C est au moment de l activation de celles-ci que la panne survient. En effet, les interruptions sont réactivées lors de l exécution de la séquence d initialisation. La panne apparaît car un reset complet n a pas été effectué. Comme expliqué précédemment, le microcontrôleur a redémarré par un PUC et non un POR. Les routines d interruptions subsistent toujours et elles font appel à certaines fonctions du système d exploitation. Lors de la réactivation de ces routines dans le bloc d initialisation, une interruption survient et fait appel au système d exploitation qui n a pas encore été mis en place. En effet, FreeRTOS ne sera opérationnel qu une fois que les différentes tâches seront crées et le Scheduler lancé. 4.4 Différentes solutions proposées. Deux propositions de solutions ont été énoncées afin de pouvoir choisir celle qui sera la plus adaptée et qui demandera le moins de modifications Redémarrage POR. La première solution est de provoquer un redémarrage complet du microcontrôleur aussi appelé redémarrage à froid. Ce type de redémarrage ne peut être provoqué que

44 CHAPITRE 4. REDONDANCE 43 par deux événements (voir [4.6]). Couper la source de courant puis la restaurer étant impossible, la seule solution serait d agir sur la broche RST/NMI qui pour rappel, à l état bas provoque un Power-On Reset. Pour pouvoir agir sur cette broche, il faut configurer le Watchdog en mode Timer. Si une panne survient, le Watchdog exécute sa requête d interruption qui agit sur RST/NMI. La figure [4.7] représente l accès à cette broche du microcontrôleur sur la carte FM430. Figure 4.7 Accès RST/NMI Cette solution est très dure à réaliser puisque l accès à RST/NMI s effectue uniquement par JTAG et une modification de la carte FM430 n est pas envisageable Redémarrage PUC. La deuxième solution proposée utilise le redémarrage dit à chaud, le PUC. Le code de l ordinateur de bord est modifié de sorte à retarder l initialisation. Etant donné que la panne se déclenche parce que le Scheduler n est pas encore mis en place, il suffit d effectuer la création des tâches et le lancement du Scheduler avant d effectuer les initialisations. La séquence d initialisation doit donc être placée dans une des tâches de l OBSW. Vu que le monitor est la tâche exécutée en premier lieu et la plus prioritaire, c est elle qui a été choisie pour accueillir l initialisation du satellite.

45 CHAPITRE 4. REDONDANCE 44 Cette solution a été préférée pour sa facilité d implémentation et parce qu il n y a aucune intervention à effectuer sur les cartes des OBC. La figure [4.8] représente l exécution de la redondance après la correction de la panne. Redémarrage MAIN Bloc d initialisation Rupture d exécution Création tâches Mise en place du Scheduler Monitor COM Rx COM Tx Sequencer Log Measurement Exécution des tâches de l OBSW Première exécution Deuxième exécution Panne Figure 4.8 Exécution redondance corrigée 4.5 Tests. Afin de prouver la robustesse de la redondance de OUFTI-1 plusieurs tests ont été réalisés. Pour ces tests les deux ordinateurs ont été connectés et la surveillance de l exécution est assurée par une application HyperTerminal [4.9] qui reçoit les données via le câble USB.

46 CHAPITRE 4. REDONDANCE 45 Figure 4.9 Application HyperTerminal Simulation de panne software. Pour pouvoir tester la redondance suite à une panne software, il a fallu insérer dans le code de l OBC Default un bout de code qui fait en sorte d interrompre l exécution de celui-ci. Une boucle infinie a donc été placée dans la tâche Monitor. Le Monitor étant la tâche la plus prioritaire, il ne devrait jamais rendre la main et faire déborder le compteur du Watchdog, ce qui entraînera un PUC. L exécution [4.10] a été observée via l HyperTerminal. Le test a également été effectué sur une durée plus longue Simulation de panne hardware. Pour pouvoir simuler une panne hardware, des câbles [4.11] servant au bus I 2 C ont été placés entre les deux cartes afin de pouvoir observer le comportement de l OBC backup dans le cas où la connexion serait débranchée. Comme pour le test précédent, l exécution [4.12] a été observée via l HyperTerminal.

47 CHAPITRE 4. REDONDANCE 46 D: DEFAULT ON D: MONITOR TIME OUT, UNLOCK TASKS B: BACKUP ON B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 D: DEFAULT ON D: MONITOR TIME OUT, UNLOCK TASKS Démarrage OBC Default Réception de ALIVE1 depuis Default Exécution normale de l OBSW OBC Backup reprend la main Redémarrage de l OBC Default réussi, il reprend la main. Reception de ALIVE1 depuis Default Tache Monitor arrivée à la boucle infinie => déclanchement Watchdog Figure 4.10 Résultat du test de la redondance, simulation de panne software. Figure 4.11 Connexion des deux cartes pour le test d une panne hardware

48 CHAPITRE 4. REDONDANCE 47 D: DEFAULT ON D: MONITOR TIME OUT, UNLOCK TASKS B: BACKUP ON B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: MONITOR WAIT VBAT B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 B: NO ALIVE1 D: MONITOR TIME OUT, UNLOCK TASKS Démarrage OBC Default Réception de ALIVE1 depuis Default Câble I²C détaché => plus de réception de ALIVE1 Cable I²C de nouveau connecté, OBC Default ne redémarre pas mais continue simplement son exécution Reception de ALIVE1 depuis Default Exécution normale de l OBSW Exécution normale de l OBSW OBC Backup reprend la main Exécution normale de l OBSW Figure 4.12 Résultat du test de la redondance, simulation de panne hardware

49 Chapitre 5 Développement du Mode sol. Ce chapitre est consacré au développement d un batterie de tests au sol. D abord, une explication sur les raisons et les buts de ces test. Ensuite, les choix qui ont été faits pour permetre le bon deroulement des test. Enfin, une explication sur le developpement du mode. 5.1 Le Mode sol Pour comprendre les raisons d un tel mode, il faut se projeter dans un futur proche. Le jour du lancement, le satellite sera complètement terminé et integré dans un P-POD, il sera donc impossible d accéder aux cartes. Les émissions radio étant interdites, le seul moyen de connexion avec le satellite restera le connecteur USB situé sur la carte FM430. Le Mode sol devra être en mesure de faire communiquer un ordinateur de supervision et OUFTI-1 en utilisant l USB, afin de vérifier le fonctionnement complet de OUFTI-1. 48

50 CHAPITRE 5. DÉVELOPPEMENT DU MODE SOL Les tests à réaliser. Le Mode sol de OUFTI-1 a les fonctionalités suivantes : Prendre et rapatrier les mesures. Vérifier émission et réception AX.25. Vérifier exécution des télécommandes. Monitorer et commander la redondance des OBC. Monitorer et commander le changement de mode du satellite. Fournir l état de santé des différents sous-systèmes. Diagnostiquer la séquence d allumage. 5.3 Connexion USB. Pour commencer, une connexion entre un ordinateur superviseur et le satellite a été établie. Deux problèmes se sont posés quand à la mise en place de cette connexion : Les transmissions radio étant interdites, la connexion USB est le seul moyen de communication avec OUFTI-1. Il est donc impossible de fournir au satellite la demande de passage en Mode sol. L OBC Default dépourvu d une connectique USB, il ne peut ni recevoir ni envoyer aucune information vers l ordinateur superviseur Passage en Mode sol. Afin d assurer que le satellite ne passera en Mode sol que si l USB est branché, une détection de la connexion a été mise en place dans le code de l ordinateur de

51 CHAPITRE 5. DÉVELOPPEMENT DU MODE SOL. 50 bord. Le microcontrôleur MSP430 possède quelques broches (tableau [5.1]) qui indiquent l état de la connexion usb. Nom Position PC/104 I/O Description 1 RST USB H2-3 Input Reset input to transceiver 2 RI USB H2-4 Input Ring Indicator 3 CTS USB H2-5 Input Clear To Send 4 DTR USB H2-7 Output Data Terminal Ready 5 RTS USB H2-8 Output Request To Send Table 5.1 Indicateurs d état de la connexion USB. Source [12] Après quelques tests, il apparaît que seul la broche RST USB change d état quand le câble USB est branché. Elle passe à 1 si le câble est branché et à 0 si celui-ci est débranché. Puisque le bus PC/104 est commun [5.1] à toutes les cartes, RST USB est accessible depuis les deux OBC. RST_USB PC/104 PC/104 JTAG MSP430 Regulator 5V / 3.3V Power protect JTAG MSP430 EEPROM Power protect Clock GROUND_MODE ON Clock GROUND_MODE ON Clock Clock RST_USB GROUND_MODE OFF GROUND_MODE OFF Backup OBC Default OBC USB Câble USB Câble USB connecté Câble USB déconnecté Ordinateur superviseur Figure 5.1 Passage des deux OBC en Mode sol

52 CHAPITRE 5. DÉVELOPPEMENT DU MODE SOL. 51 RST USB est utilisé pour signaler au satellite que le câble USB est branché, et que le passage en Mode sol est attendu. A chaque interruption générée par le Timer B, les deux OBC vérifient l état de la connexion USB et mettent à jour leur variable globale Ground mode. Toutefois, cette vérification sera effectuée tant que les antennes ne seront pas déployées. Si elles sont déployées, cela veut dire que le satellite est en orbite et que cette vérification n a plus aucun sens Communication des OBC vers l USB. L OBC Default étant dépourvu d une connexion USB, il ne sait pas communiquer avec l ordinateur superviseur. La solution d utiliser l OBC Backup comme relais entre Default et l ordinateur superviseur a été choisie. Cette connexion est assurée par le bus I 2 C [5.2]. I2C SDA I2C SCL PC/104 PC/104 JTAG MSP430 Regulator 5V / 3.3V Power protect JTAG MSP430 EEPROM Power protect Clock Clock Transfère de message Clock Clock MESSAGE à envoyer Backup OBC Default OBC USB Câble USB Ordinateur superviseur MESSAGE de Default OBC Figure 5.2 Transfère de message via I 2 C

53 CHAPITRE 5. DÉVELOPPEMENT DU MODE SOL. 52 Tous les messages que OBC Default aura besoins d envoyer à Backup sont connus, c est-à-dire qu il n enverra jamais un flux de données mais juste des messages d information. Pour éviter que Default ne soit obligé d envoyer le message entier caractère par caractère, tous les messages se sont vu attribuer un code. C est ce même code [5.2] qui est reçu par Backup et qui est ensuite transféré vers l ordinateur superviseur. Code Nom Description 1 DEFAULT ON OBC Default a démarré son exécution 2 BACKUP ON OBC Backup a démarré son exécution 3 MONIT 30M Attente de 30 min avant déploiement des antennes 4 MONIT W VBAT Voltage insuffisant 5 MONIT TO UNCK Time-out, déblocage des tâches 6 MONIT TK1 Allumage du couteau thermique 1 7 MONIT TK2 Allumage du couteau thermique 2 8 MONIT ANT FG Réinitialisation du flag des antennes 9 MONIT UNCK DEPL Antennes déployés 10 SAFE M VBAT Passage en SAFE MODE 11 I2C BUSY WR Ecriture erroné sur le bus I 2 C 12 I2C TO WR Time-out en écriture sur le bus I 2 C 13 I2C NOACK WR Pas d acquittement après une écriture sur le bus I 2 C 14 I2C BUSY RD Lecture erronée sur le bus I 2 C 15 I2C TO RD Time-out en lecture sur le bus I 2 C 16 ALIVE1 DEF Message ALIVE1 reçu 17 NO ALIVE1 Pas de message ALIVE1 reçu 18 ALIVE2 BAC Message ALIVE2 reçu 19 ACK DEF SH DOWN Acquittement reçu pour le message ALIVE2 20 COM RX AX25 ERR Erreur réception AX COM TX TM SD Télémétrie envoyée 22 MEAS CLEARING Initialisation mesures 23 MEAS IDX OK Index mesures ok 24 MEAS IDX NOK Index mesures erroné 25 SEQ MEAS ENBL Enregistrement des mesures enclenché 26 SEQ GET MEAS Récupération des mesures 27 SEQ MEAS DEF Module Measurement réinitialisé 28 SEQ GET LOG Récupération Log 29 SEQ GET LOG ERR Erreur de récupération de Log 30 SEQ LOG DEF Module Log réinitialisé 31 SEQ GET MODE Récupération du mode de fonctionnement du satellite 32 SEQ CHANGE MODE Changement de mode de fonctionnement du satellite 33 SEQ GET COM REP Récupération rapport de COM 34 SEQ FCT DEF Module Sequencer réinitialisé 35 SEQ SCHD ENBL Shceduler télécommandes activé 36 SEQ SCHD DSBL Shceduler télécommandes désactivé 37 SEQ SCHD RES Shceduler réinitialisé 38 SEQ DEL CMD Suppréssion télécommande 39 SEQ DEL CMD TM Suppression télécommande avec option 40 SEQ GET SCHD SUM Récupération des infos du Scheduler OBSW 41 SEQ SCHD DEF Configuration du Scheduler OBSW par défaut 42 SEQ DEF Configuration Sequencer par défaut Table 5.2 Différents messages envoyés par Default

54 CHAPITRE 5. DÉVELOPPEMENT DU MODE SOL Application de l ordinateur superviseur. Maintenant que les deux ordinateurs de bord savent passer en Mode sol. Et qu ils peuvent tous les deux communiquer avec l ordinateur superviseur, il faut se pencher sur le software de celui-ci. Ce software permettra l envoi des commandes au satellite par l USB et l affichage des données reçues. Précédemment, c est une application HyperTerminal qui était employée pour remplir ce rôle. Cependant un inconvénient fut remarqué dans l utilisation de celuici pour le Mode sol. Lorsque le câble USB est connecté, le bit RST USB passe bien à l état haut entraînant le passage du satellite en Mode sol. Puis, quand la communication s établit entre le HyperTerminal et OUFTI-1, le bit RST USB repasse à l état bas et le satellite reprend son exécution normale. Dans certains logiciels HyperTerminal, il est possible d agir sur ce bit afin de demander au satellite le passage en mode test, mais tous ne le permettent pas Développement d une application dédiée. Le développement d une application dédiée au Mode sol, pour l ordinateur superviseur, est donc le plus approprié. Les avantages d une telle application sont les suivants : Une interface graphique facilite grandement l utilisation. En effet, l envoi des commandes peut se faire à l aide d un menu, tandis que dans un HyperTerminal toute la commande doit être tapée à la main. La réception des données peut être traitée pour un affichage plus clair. Les informations reçues peuvent être plus facilement archivées. La gestion du bit RST USB est possible.

55 CHAPITRE 5. DÉVELOPPEMENT DU MODE SOL. 54 L application Ground a été développée en langage Java. L utilisation de la librairie RxTx 1 a permis de faciliter la gestion de la communication USB. Cette librairie permet de se connecter à un port série et d envoyer des octets à celui-ci ou d en recevoir. L application est constituée d une interface graphique et d un thread. Ce thread se charge d écouter en boucle sur la partie réception du port série et de reconstituer les trames envoyées depuis OUFTI-1. L interface graphique Figure 5.3 Interface graphique de l application Ground L interface graphique [5.3] est divisée en plusieurs parties : 1. Le contrôle de la connexion permet de se connecter au port COM qui correspond à la connexion USB. Une fois connecté, le bouton d activation du Mode sol devient accessible. Dès que le celui-ci est activé, les autres contrôles sont débloqués. 1. Source [14]