LESIA - Observatoire de Paris

PALISADE

Loïc Gueguen — 2009-01-27T09:17:52Z

Contexte

Lorsque l'on transmet des commandes vers un instrument (les télécommandes) ou lorsque l'on reçoit les données transmises par cet instrument (les télémétries), il y a un échange de données qui s'établit entre deux systèmes, l'instrument et les moyens de test, selon un protocole de communication précis qui définit le format des échanges (structure des paquets, valeurs des différents champs, etc.). Tous ces échanges se font dans un format binaire et non dans un langage naturel directement exploitable : il est nécessaire d'utiliser des logiciels pour transformer ces données dans un format utilisable par les ingénieurs et les scientifiques.

Chaque nouvel instrument possède son propre langage dépendant de différents facteurs comme le protocole utilisé pour la communication ou la structure des données échangées. Cela signifie donc qu'il est nécessaire, pour chaque nouvel instrument, de réécrire de nouveaux logiciels à même d'interpréter les données échangées. Ce besoin est encore plus flagrant quand on considère que les mêmes données seront interprétées différemment selon les corps de métiers (là où un électronicien verra une tension au sortir d'un capteur, un scientifique lira une intensité lumineuse) et que leur format pourra évoluer dans le temps (le format peut changer pendant les phases de conception, d'intégration et même pendant l'utilisation de l'instrument en cas de modification volontaire de son fonctionnement).

Il devenait donc nécessaire de faciliter et d'accélérer le développement de ces logiciels.

Le projet PALISADE

Pour répondre à ce besoin, l'équipe Logiciel instrumentaux a développé un ensemble d'outils rassemblés dans le projet PALISADE (Parsing Library and Structural Description).

Ce projet est constitué de deux entités :

un langage de description,
une bibliothèque de composants logiciels.

L'idée est d'utiliser le langage pour décrire le format des données. Nous appellerons par la suite cette description une méta-définition. Les composants logiciels sont capables de récupérer cette méta-définition et de se structurer de manière à pouvoir interpréter correctement les données. Si une méta-définition différente est fournie, les composants se restructurent dynamiquement et s'adaptent au nouveau format. Par la suite nous utiliserons l'anglicisme parser pour désigner ces composants.

Les données binaires présentées au parser seront interprétées et rendues dans un format générique facilement utilisable par le programme de traitement (processus d'analyse), et des données fournies dans ce format générique seront interprétées pour obtenir un format binaire (processus de compilation).


PALISADE

Le langage de méta-définition

Ce méta langage a été entièrement défini via XML et XML Schema. Il fournit un ensemble de structures classiques (boucles, expressions conditionnelles, gestion de variables, utilisation de formules…) qui permettent de simplement décrire la structure des différents flux de données associés à l'instrument. La simplicité d'utilisation de XML, associée à l'expressivité du langage défini par PALISADE, permet d'écrire simplement une méta-définition, facile à comprendre et à modifier.

La bibliothèque de composants logiciels

La bibliothèque est construite autour d'un ensemble de composants coopérants que nous avons nommé parser, chargé des opérations d'analyse et de compilation. Outre ces composants, la bibliothèque fournit différents outils périphériques permettant, par exemple, de traiter en aval les données produites par le parser ou de gérer les différents fichiers de méta-définition.

La bibliothèque a été développée en C++ en utilisant les différents paradigmes de la programmation objet. Fortement modulaire, elle peut rapidement et simplement être enrichie.

Contact : Loïc Gueguen

Les SGSE de CoRoT

Philippe Plasson — 2009-01-27T09:17:33Z

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

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'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

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

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

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

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

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

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

Logiciels de test et d'intégration

Philippe Plasson — 2008-09-29T19:45:07Z

Présentation générale

Contexte

Dans le cadre des projets spatiaux aussi bien que dans celui des projets sol, les phases de test, de validation et d'intégration des instruments sont des phases cruciales qui nécessitent le développement, parallèlement à celui des instruments eux-mêmes, d'équipements de test (appelés EGSE pour Electrical Ground Support Equipment) et de systèmes logiciels permettant de préparer, conduire et automatiser les tests (appelés SGSE pour Software Ground Support Equipment).

Le LESIA dispose d'une longue expérience dans le domaine de la conception et du développement des logiciels de test et d'intégration. Les techniques employées pour le développement de ces systèmes varient en fonction des besoins des équipes instrumentales et de la nature des projets : certains instruments sont pilotés et testés à travers des applications développées en LabView, d'autres nécessitent des systèmes de test complexes dont le développement fait appel à des techniques de programmation avancées basées sur l'emploi de langages objets comme C++ ou Java (voir les SGSE de CoRoT).

Hétérogénéité et volatilité des besoins

Les logiciels de test et d'intégration sont développés en prenant en compte la grande diversité des utilisateurs. Ces derniers, en fonction de leur métier, ont des cultures différentes et des besoins hétérogènes : les besoins des spécialistes des détecteurs ne sont pas forcément les mêmes que ceux des électroniciens ou que ceux des ingénieurs responsables de la validation des logiciels embarqués.

Par ailleurs, les plannings des projets instrumentaux sont toujours extrêmement tendus et les besoins parfois volatils. Il est donc nécessaire, pour les équipes en charge du développement des logiciels de test, de faire preuve d'une grande réactivité, et surtout, de hiérarchiser les besoins en fixant les priorités grâce à un dialogue étroit avec l'ensemble des utilisateurs.

Les développements génériques

Malgré la grande diversité des projets instrumentaux, il est possible d'identifier un certain nombre d'outils dont le besoin est récurrent. C'est pourquoi, à côté des développements spécifiques, Le LESIA développe des composants logiciels génériques pouvant être utilisés pour produire plus rapidement et avec une qualité accrue des logiciels de test et d'intégration.

Par exemple, le projet PALISADE offre une solution sur étagère pour la description et l'interprétation des données échangées avec n'importe quel type d'instrument.

Contact : Philippe Plasson