Observatoire de Paris Institut national de recherche scientifique français Univerité Pierre et Marie Curie Université Paris Diderot - Paris 7

Les SGSE de CoRoT

lundi 15 janvier 2018, par Philippe Plasson

Contexte et objectifs

Les SGSE (Software Ground Support Equipment) de CoRoT correspondent Ă  un ensemble cohĂ©rent d’outils logiciels qui ont Ă©tĂ© utilisĂ©s pour mener Ă  bien les activitĂ©s de tests et de validation de l’unitĂ© de traitement numĂ©rique de l’instrument CoRoT (sous-système incluant le logiciel de vol du DPU - Digital Process Unit - et le logiciel de vol du BoĂ®tier Extracteur de donnĂ©es). La polyvalence et la modularitĂ© de ces outils logiciels, qui ont Ă©tĂ© dĂ©veloppĂ©s sur mesure pour le projet CoRoT, leur ont en fait permis d’ĂŞtre utilisĂ©s durant toutes les activitĂ©s d’intĂ©gration, de tests et de validation de l’instrument et de ses sous-systèmes CorotCase et CorotCam.

Les SGSE de CoRoT ont Ă©tĂ© spĂ©cifiĂ©s, conçus et dĂ©veloppĂ©s entièrement par le LESIA (exceptĂ© le composant critique pilotant le bus satellite MIL-STD-1553 dont la conception dĂ©taillĂ©e et le codage ont fait l’objet d’une sous-traitance industrielle). La durĂ©e totale du dĂ©veloppement des SGSE de CoRoT a Ă©tĂ© de l’ordre de trois annĂ©es et demie. Six ingĂ©nieurs informaticiens ont participĂ© aux dĂ©veloppements.

Les SGSE de CoRoT ont Ă©tĂ© utilisĂ©s intensĂ©ment par plusieurs Ă©quipes les trois annĂ©es durant lesquelles se sont dĂ©roulĂ©es les activitĂ©s de tests de l’instrument et de ses sous-systèmes. Ils seront utilisĂ©s pendant toute la durĂ©e de la mission CoRoT (cinq ans) par le Centre de Mission de CoRoT (CNES) dans le cadre du banc instrument (modèle d’ingĂ©nierie de l’instrument permettant de valider, avant transmission au satellite, les tĂ©lĂ©commandes et les diffĂ©rents scĂ©narios opĂ©rationnels) et par l’Ă©quipe Logiciels de vol Ă  des fins d’expertise.

Les SGSE de CoRoT forment un système logiciel permettant Ă  un utilisateur (Ă©quipe de validation des logiciels de vol, Ă©quipe AIT instrument, etc.) de piloter et surveiller Ă  distance l’instrument dans sa totalitĂ© (cas des essais instrument) ou seulement un des sous-systèmes de l’instrument comme le DPU couplĂ© Ă  un simulateur du BoĂ®tier Extracteur de donnĂ©es (cas de la validation des logiciels de vol). Ils permettent d’interagir en temps rĂ©el avec le système sous test en pilotant les diffĂ©rents EGSE, mais aussi de programmer des scĂ©narios de test sous la forme de scripts de commandes envoyĂ©es Ă  l’instrument via un simulateur de la plate-forme satellite Proteus. Les procĂ©dures de test et les scripts sont organisĂ©s en bibliothèques stockĂ©es dans un rĂ©fĂ©rentiel unique et centralisĂ©. Les tĂ©lĂ©mĂ©tries scientifiques et techniques (housekeepings ou encore HK) sont aussi stockĂ©es au sein d’une base unique gĂ©rĂ©e par un serveur de base de donnĂ©es. Les SGSE de CoRoT permettent de rĂ©aliser en temps rĂ©el ou de manière post-mortem, via un outil de traitement des tĂ©lĂ©mĂ©tries, des analyses donnant lieu Ă  des rapports d’essais.

Le module d’analyse des tĂ©lĂ©mĂ©tries du logiciel de vol a Ă©tĂ© conçu pour pouvoir aussi ĂŞtre alimentĂ© via le Centre de Mission de CoRoT. Il peut ainsi ĂŞtre utilisĂ© Ă  des fins d’expertise durant toute la mission par les ingĂ©nieurs du LESIA.

Architecture générale

Les SGSE de CoRoT ont été conçus comme un ensemble de composants client/serveur répartis sur un réseau ethernet et formant une architecture à base de composants, fortement modulaire, évolutive et reconfigurable, comme le montre la figure ci-dessous.

L'architecture des SGSE de CoRoT
L’architecture des SGSE de CoRoT

Le choix d’une approche orientĂ©e composants a permis de fournir aux utilisateurs un produit modulable en fonction de leurs besoins et a permis aussi d’inscrire les dĂ©veloppements dans une logique d’ingĂ©nierie simultanĂ©e, chaque dĂ©veloppeur devenant responsable d’un ou plusieurs composants. L’objectif poursuivi Ă©tait que les diffĂ©rents composants du système puissent ĂŞtre dĂ©veloppĂ©s simultanĂ©ment et puissent Ă©voluer Ă  des rythmes diffĂ©rents.

Tous les composants logiciels en interface avec la charge utile jouent le rĂ´le de serveurs. Ils sont connectĂ©s Ă  la charge utile via des cartes du commerce (carte PCI DDC 1553, cartes National Instruments) ou via des EGSE rĂ©alisĂ©s sur mesure par le LESIA. Ils peuvent ĂŞtre rĂ©partis sur plusieurs machines afin d’optimiser la charge CPU ou l’utilisation des ressources matĂ©rielles. Ils sont accessibles Ă  travers un rĂ©seau Ethernet via des appels Ă  des procĂ©dures distantes (RPC).

Le composant Script Interpreter and Command Dispatcher joue le rĂ´le de chef d’orchestre du système. Ses tâches principales consistent Ă  interprĂ©ter les scripts de test, Ă  formater les commandes et Ă  les transmettre aux diffĂ©rents serveurs pilotant le matĂ©riel. Il est connectĂ©, Ă  travers le rĂ©seau, au composant Script Editor and Test Driver qui est une application ayant une interface utilisateur Ă©laborĂ©e permettant de prĂ©parer les tests et de piloter finement les essais.

Le composant TM Storer and Dispatcher est responsable de la bufferisation des tĂ©lĂ©metries transmises par la charge utile, de leur encapsulation basĂ©e sur l’utilisation de XML, de leur stockage dans un serveur de base donnĂ©es et de leur dispatchage en temps-rĂ©el vers le composant Monitoring and Analysis System.

Préparation et conduite des tests

La figure ci-dessous donne un aperçu de l’interface homme-machine (IHM) de l’application Script Editor and Test Driver.

L'outil d'édition des télécommandes et de conduite des tests
L’outil d’édition des télécommandes et de conduite des tests

L’IHM de cet outil est avant tout constituĂ©e par un Ă©diteur de scripts multifenĂŞtres (2). Un script SGSE est une sĂ©quence de commandes qui peuvent ĂŞtre destinĂ©es directement aux Ă©quipements testĂ©s ou qui peuvent ĂŞtre des commandes de configuration des composants en charge du pilotage des EGSE. Le cadencement d’un script est dĂ©fini Ă  l’aide d’instructions de pause ou Ă  l’aide de timetags. Un script peut appeler un script enfant, et ce sur plusieurs niveaux. Des structures itĂ©ratives (boucles) peuvent ĂŞtre programmĂ©es afin de rĂ©pĂ©ter un certain nombre de fois le mĂŞme bloc de commandes. Une procĂ©dure de test peut ĂŞtre implĂ©mentĂ©e Ă  l’aide d’un script ou de plusieurs scripts SGSE.

Plusieurs scripts peuvent ĂŞtre Ă©ditĂ©s simultanĂ©ment. L’Ă©dition des scripts se fait par glisser-dĂ©poser (drag and drop) des commandes de la zone de sĂ©lection des commandes (1) vers la fenĂŞtre d’Ă©dition de script active (2). La zone de sĂ©lection des commandes (1) revĂŞt la forme d’un arbre dans lequel les commandes sont organisĂ©es par catĂ©gorie et par type : on trouve ainsi, par exemple, sous le noeud DPU l’ensemble des 84 tĂ©lĂ©commandes Ă  destination des DPU classĂ©es selon leur catĂ©gorie. L’Ă©dition des paramètres des commandes se fait Ă  l’aide du panneau (3).

Les commandes pouvant ĂŞtre utilisĂ©es au sein d’un script SGSE, ainsi que leur structure (liste, nom et type des paramètres) sont dĂ©finies dans des documents de mĂ©ta-dĂ©finition. Un langage de mĂ©ta-dĂ©finition basĂ© sur XML a Ă©tĂ© conçu spĂ©cialement pour la description des donnĂ©es manipulĂ©es par les SGSE. L’Ă©diteur de scripts utilise ces mĂ©ta-donnĂ©es pour construire dynamiquement l’arbre des commandes et mettre Ă  jour la zone d’Ă©dition des paramètres en fonction de la commande pointĂ©e dans le script par l’utilisateur. Des commandes peuvent ĂŞtre ajoutĂ©es au système ou modifiĂ©es sans avoir Ă  recompiler l’ensemble de l’application.

L’outil dispose aussi d’un gestionnaire de projets (4) permettant de regrouper de façon logique des scripts apparentĂ©s. Plusieurs projets peuvent ĂŞtre ouverts simultanĂ©ment. Le gestionnaire de projet permet aussi de dĂ©finir et gĂ©rer les descripteurs d’essai dans lesquels sont enregistrĂ©s la configuration matĂ©rielle et logicielle du système sous test et du système de test lui-mĂŞme. Pour des raisons de traçabilitĂ© et de qualitĂ©, ces descripteurs sont automatiquement attachĂ©s aux instances des tests.

Enfin, l’outil agrège diffĂ©rents modules permettant d’automatiser la production des scripts de chargement du code du logiciel de vol du DPU (plus de 8000 tĂ©lĂ©commandes), ainsi que la production des scripts de chargement des descripteurs des fenĂŞtres de la voie astĂ©ro et de la voie exoplanètes de l’instrument (6000 descripteurs de fenĂŞtres identifiant sur le CCD de la voie exoplanètes 6000 Ă©toiles).

Monitoring et analyse des essais

L’application Monitoring and Analysis System constitue l’oeil du système. Elle permet de visualiser en temps rĂ©el les Ă©changes avec le système sous test grâce Ă  de nombreux synoptiques et historiques. Elle permet aussi d’accĂ©der aux donnĂ©es stockĂ©es dans la base de donnĂ©es une fois l’essai terminĂ© et de produire de façon semi-automatique des analyses post mortem.

L'outil de monitoring et d'analyse
L’outil de monitoring et d’analyse

Principales fonctionnalités

L’application Monitoring and Analysis System gère plusieurs fichiers journaux dont le fichier journal traçant les Ă©changes TC/TM (1), le fichier journal des Ă©vĂ©nements DPU Ă©laborĂ© Ă  partir des paquets TM techniques (2) et le fichier journal reprenant les informations transmises par le BoĂ®tier Extracteur de donnĂ©es via ses paquets HK.

L’utilisateur peut interagir avec ces fichiers journaux directement Ă  travers l’IHM de l’application (arrĂŞt du dĂ©filement, retour en arrière, rejeu post mortem avec mise Ă  jour des synoptiques, etc.), mais il peut aussi exporter ces fichiers journaux sous la forme de fichiers Excel, ce qui permet de profiter des fonctionnalitĂ©s offertes par cet outil.

Chaque paquet (TC, TM, HK, etc.) tracĂ© dans un fichier journal peut ĂŞtre visualisĂ© individuellement Ă  l’aide d’un outil donnant accès au contenu brut du paquet et Ă  son arbre de dĂ©commutation (voir ci-dessous un exemple). L’affichage de ces fichiers journaux est par ailleurs entièrement configurable Ă  l’aide de filtres construits Ă  partir d’une vue reprĂ©sentant les donnĂ©es sous une forme arborescente comme le montre la figure ci-dessous.

Boîte de décommutation et boîte de configuration des filtres
Boîte de décommutation et boîte de configuration des filtres

A cĂ´tĂ© de ces fichiers journaux, l’application Monitoring and Analysis System offre des panneaux de contrĂ´le permettant de visualiser l’Ă©tat des diffĂ©rents Ă©quipements comme l’état des DPU (3), des BoĂ®tiers Extracteur de donnĂ©es (4), des BoĂ®tiers de ContrĂ´le de la CamĂ©ra et des BoĂ®tiers de Servitude. D’autres panneaux de contrĂ´le permettent de visualiser l’Ă©tat des diffĂ©rents composants du système SGSE lui-mĂŞme.

Les mesures de tensions, de tempĂ©ratures et de courants transmises dans les HK de l’instrument sont visualisables sous la forme de tableaux ou de courbes dont le contenu est configurable par l’utilisateur (voir la figure ci-dessous). La surveillance des diffĂ©rents capteurs de l’instrument est entièrement automatisable et configurable (dĂ©tection selon des plages de surveillance avec gestion d’alarmes selon diffĂ©rents niveaux de criticitĂ©).

Outil de suivi des capteurs instrument
Outil de suivi des capteurs instrument

La dĂ©commutation des paquets de donnĂ©es qui alimentent les diffĂ©rentes vues de l’application Monitoring and Analysis System est rĂ©alisĂ©e par un parser configurĂ© Ă  l’aide de mĂ©ta-donnĂ©es dĂ©crites en XML (via le langage de mĂ©ta-dĂ©finition qui est aussi utilisĂ© pour la description des TC). Ce parser est donc entièrement reconfigurable sans avoir Ă  recompiler l’application (lire cet article pour plus de dĂ©tails sur la technologie utilisĂ©e).

Toutes les fonctions de l’application Monitoring and Analysis System sont accessibles en ligne, c’est-Ă -dire durant un essai, ou hors ligne, c’est-Ă -dire une fois l’essai jouĂ© et les donnĂ©es stockĂ©es dans la base de donnĂ©es SGSE.

Identifiables par leur nom et leur date d’exĂ©cution, les essais stockĂ©s dans la base de donnĂ©es SGSE sont accessibles Ă  travers un navigateur dĂ©diĂ© offrant des fonctionnalitĂ©s de tri et de filtrage.

Les outils d’analyse

L’application Monitoring and Analysis System propose un ensemble d’outils destinĂ©s Ă  l’analyse des donnĂ©es produites par l’instrument. Les donnĂ©es analysĂ©es peuvent ĂŞtre des donnĂ©es techniques ou des donnĂ©es issues de la tĂ©lĂ©mĂ©trie scientifique. On peut citer par exemple l’outil d’audit de la mĂ©moire DPU, outil qui permet de comparer automatiquement le contenu d’une zone mĂ©moire DPU avec ce qui a Ă©tĂ© rĂ©ellement chargĂ© dans les TC (voir figure ci-dessous).

Outil de comparaison mémoire
Outil de comparaison mémoire

En ce qui concerne l’exploitation des donnĂ©es scientifiques, le Moniteur/Analyseur propose un outil (voir la figure ci-dessous) permettant de reconstruire les images plein cadre CCD ou les fenĂŞtres acquises avec l’instrument afin de les visualiser, de les exporter dans des fichiers au format FITS ou encore de les comparer avec les images ou fenĂŞtres injectĂ©es en entrĂ©e des simulateurs (simulateur du BoĂ®tier Extracteur de DonnĂ©es, simulateur du BoĂ®tier de ContrĂ´le CamĂ©ra ou simulateur VidĂ©o).

Outil de visualisation/comparaison des images
Outil de visualisation/comparaison des images

Parallèlement Ă  cet outil de visualisation et de comparaison d’images, un outil de suivi photomĂ©trique a spĂ©cialement Ă©tĂ© dĂ©veloppĂ© pour les essais EMC (Electromagnetic Compatibility). Cet outil a pour fonction de construire en temps rĂ©el une courbe photomĂ©trique Ă  partir des fenĂŞtres CCD transmises par l’instrument, courbe permettant de visualiser et d’Ă©valuer l’influence des perturbateurs Ă©lectromagnĂ©tiques injectĂ©s dans le système (voir figure ci-dessous).

Outil de suivi photométrique temps-réel
Outil de suivi photométrique temps-réel

L’application Monitoring and Analysis System dispose aussi d’un outil permettant d’exporter sous la forme de courbes stockĂ©es dans des fichiers FITS compatibles avec les outils de l’Ă©quipe scientifique l’ensemble des paquets TM scientifiques correspondant Ă  un essai. Ces donnĂ©es sont exploitĂ©es par l’Ă©quipe scientifique ainsi que par l’Ă©quipe de validation du logiciel de vol. L’outil permet aussi de comparer automatiquement les donnĂ©es en sortie du DPU avec les donnĂ©es produites en sortie du modèle du logiciel de vol (outil utilisĂ© dans le cadre de l’activitĂ© de validation des algorithmes scientifiques).

Traitement par lots

Tous les outils d’analyse de l’application Monitoring and Analysis System ont Ă©tĂ© dĂ©veloppĂ©s sous la forme de plugins. Ces diffĂ©rents plugins ont Ă©tĂ© rĂ©utilisĂ©s pour dĂ©velopper un outil de traitement par lots permettant d’analyser automatiquement un grand nombre d’essais et de rĂ©aliser les tests de non rĂ©gression des logiciels de vol. Cet outil produit un rapport de synthèse sous la forme d’un classeur excel.

Interfaçage avec le système sous test

Simulation de la plate-forme Proteus

Les SGSE de CoRoT sont connectés à la charge utile grâce à 3 composants logiciels qui simulent la plate-forme satellite Proteus et jouent le rôle de serveurs pour le reste du système.

Le premier composant pilote une carte PCI DDC BU-65549. Il gère la communication sur le bus MIL-STD-1553 et prend en charge la transmission des TC à destination du DPU et la réception des TM produites par le DPU.

Le deuxième composant gère tous les liens spĂ©cifiques Ă  la plate-forme Proteus Ă  travers un EGSE rĂ©alisĂ© sur mesure par le LESIA (l’EGSE LEVTEAU).

Le troisième composant pilote un rack PXI de chez National Instruments et a pour tâche de rĂ©aliser l’acquisition des donnĂ©es transmises par les 128 capteurs de tensions et de tempĂ©rature embarquĂ©s dans la charge utile.

Simulation du BoĂ®tier Extracteur de donnĂ©es de l’unitĂ© de traitement numĂ©rique

Le simulateur du BoĂ®tier Extracteur de donnĂ©es est utilisĂ© dans le cadre de la validation du logiciel de vol DPU et plus particulièrement dans le cadre de la validation des algorithmes scientifiques vis-Ă -vis du modèle instrument car il permet d’envoyer en entrĂ©e du DPU, via des liens SpaceWire, des sĂ©quences d’images dont le contenu varie dans le temps en fonction d’une simulation donnĂ©e de l’environnement (images plus ou moins bruitĂ©es, Ă©toiles Ă  flux variable, etc.).

Le simulateur du Boîtier Extracteur de données a été conçu comme un simulateur universel de liens SpaceWire et peut très facilement être réutilisé dans un autre contexte.

Contact : Philippe Plasson


  • PALISADE

    15 janvier 2018, par LoĂŻc Gueguen