Au cœur des instruments scientifiques spatiaux
jeudi 7 décembre 2023, par Philippe Plasson
Le LESIA, à travers l’équipe Logiciels de vol du SII, dispose d’un savoir-faire pointu dans le domaine du développement et de la validation des logiciels à forte composante temps réel qui sont au cœur des instruments scientifiques spatiaux.
La plate-forme GERICOS (GEneRIC Onboard Software) est constituée :
La plate-forme GERICOS : une plate-forme générique pour le développement des logiciels scientifiques embarqués dans des instruments spatiaux
L’équipe Logiciels de vol du SII a développé un framework C++ dédié à la construction des logiciels de bord : le framework GERICOS. Ce framework est implémenté sous la forme d’une bibliothèque de composants réutilisables formant un cadre de conception pour les logiciels embarqués spatiaux. Il est constitué de deux couches.
La première couche (Active Object Layer for Embedded Software) offre une implémentation extrêmement légère, optimisée et "compatible spatial" (faible empreinte mémoire, faible coût CPU) du concept d’objets actifs au-dessus d’un noyau temps-réel. Cette couche intègre aussi les concepts liés au temps réel et à l’embarqué, comme le concept d’interruptions, de drivers ou encore de ressources partagées.
La seconde couche (Building Blocks for Space Software) offre un ensemble de briques logicielles réutilisables permettant de construire des logiciels de vol en se basant sur des solutions génériques apportées à des problèmes récurrents (gestion des télécommandes, gestion des télémétries, gestion de la maintenance en vol, gestion des modes instrumentaux, etc.).
Un logiciel de vol est habituellement constitué de deux produits distincts mais interdépendants : un logiciel de boot et un logiciel applicatif. Le logiciel de boot est stocké en PROM (mémoire programmable une seule fois) et ne peut pas être mis à jour ou corrigé en vol : c’est un logiciel critique dont la tâche principale est de charger en RAM, sur la réception d’une télécommande, le logiciel applicatif stocké en EEPROM (mémoire effaçable et programmable électriquement). Le logiciel de boot offre aussi un ensemble de fonctionnalités permettant d’assurer en vol la maintenance du logiciel applicatif. Le logiciel applicatif, quant à lui, implémente l’ensemble des traitements bord propres à la mission : ces traitements peuvent être modifiés durant l’exploitation.
Du fait de la convergence des technologies spatiales et de leur standardisation (généralisation de l’utilisation du processeur LEON et de la technologie SpaceWire), il est désormais envisageable de concevoir une architecture générique pour les logiciels de vol, architecture qui puisse être utilisée comme un produit sur étagère dans le cadre des projets spatiaux à venir. Cette architecture générique doit intégrer de façon unifiée la couche liée à la gestion du boot (logiciel de boot) et la couche liée à l’application proprement dite (logiciel applicatif).
L’équipe Logiciels de vol du SII a conçu une telle architecture générique en se basant sur le framework GERICOS. Un prototype de logiciel de vol générique a été développé autour de cette architecture. D’une mission à l’autre, la couche liée à la gestion du boot qui a été implémentée dans ce prototype pourra être réutilisée au prix d’adaptations mineures. La couche applicative aura, quant à elle, un degré de généricité forcément moins élevé et devra être adaptée en fonction des besoins spécifiques aux missions et des traitements bord devant être implémentés. La figure ci-dessous donne un aperçu de l’architecture générique pour les logiciels de vol :
L’architecture GERICOS intégre de façon unifiée la couche liée à la gestion du boot et la couche liée à l’application proprement dite.
Le Banc logiciel bord GEDEON est une infrastructure logicielle et matérielle, conçue par l’équipe "Logiciels de Tests et Validation" du SII conjointement avec l’équipe "Logiciels de vol" du SII, pour le développement et les tests des logiciels embarqués spatiaux. Le Banc logiciel bord intègre les technologies standardisées du spatial comme le SpaceWire ou le processeur LEON.
Dans le cadre des projets instrumentaux spatiaux, le matériel n’est disponible que très tard. Cependant, en ce qui concerne le développement des logiciels de vol, il est nécessaire de réaliser des prototypes dès la phase d’évaluation des projets, c’est-à-dire bien avant que le matériel soit conçu. Ces prototypes permettent justement de dimensionner le matériel en évaluant la charge CPU requise, la quantité de mémoire nécessaire, les débits de données entrant et sortant. Par ailleurs, entre le moment où l’architecture matérielle de l’unité de traitement numérique (DPU) est figée et le moment où les premiers modèles sont disponibles, il peut s’écouler encore de nombreux mois durant lesquels l’équipe en charge du logiciel de vol a besoin d’une cible pour mettre au point et tester les prototypes qu’elle développe. Le Banc logiciel bord a été conçu pour répondre à ces différents besoins.
Le Banc logiciel bord est architecturé autour d’outils logiciels et de simulateurs développés par l’équipe Logiciels de vol du SII, ainsi qu’autour de produits commerciaux comme TSIM, le simulateur de processeur LEON.
Le simulateur TSIM est un outil logiciel reproduisant au niveau instruction le fonctionnement du processeur LEON. Il permet de faire fonctionner un logiciel embarqué compilé pour la cible LEON dans un environnement purement logiciel. Il offre un certain nombre de services permettant d’observer de façon non intrusive le fonctionnement du logiciel embarqué et d’interagir avec lui (points d’arrêt, dumps et chargement mémoire, mesures de performance, profiling, etc.). Le simulateur TSIM peut recevoir des modules plug-in simulant les entrées/sorties (modules I/O) et donc le matériel en interface avec le processeur.
L’équipe Logiciels de vol du SII a développé sur mesure, pour les besoins du Banc logiciel bord, un certain nombre de modules I/O compatibles avec le simulateur TSIM. Une première catégorie de modules permet de simuler les interfaces détecteurs : ces modules peuvent, par exemple, être alimentés par un flux d’images FITS produites par des modèles scientifiques et émettre ce flux vers le logiciel de bord selon un cadencement entièrement programmable. Une seconde catégorie de modules permet de simuler les interfaces vers la plate-forme satellitaire : ces modules sont capables de transmettre des télécommandes selon des scripts écrits dans un dialecte XML spécifique et d’acquérir les télémétries transmises par le logiciel de vol. Ces modules I/O permettent de simuler différents types d’interface : SpaceWire, MIL-STD-1553, CAN, FIFO, DPRAM, mémoires partagées, etc.
Le Banc logiciel bord permet de mener à bien des tests de type "boîte blanche" qui viennent en complément des tests plus classiques dits "boîte noire". Il permet d’automatiser les tests fonctionnels, les tests de performance et les tests d’interfaces via un moteur de tests utilisant des scripts GDB et un outils d’analyse automatique des fichiers traces produits par GDB. Les aspects liés à la non régression des tests sont pris en charge par le moteur de tests.
Le Banc logiciel bord offre aussi la possibilité de basculer vers une cible purement matérielle en remplaçant le simulateur du LEON par une carte processeur et les modules I/O par des simulateurs matériels (EGSE) et logiciels (SGSE) des sous-systèmes instrumentaux.
Actuellement utilisé dans le cadre de l’étude et du développement du logiciel de vol de la mission SMESE/DESIR, ainsi que dans le cadre de la phase d’évaluation de PLATO, le Banc logiciel bord sera, du fait de sa généricité, réutilisé dans le cadre des missions à venir.
Le diagramme ci-dessous donne un aperçu de l’architecture du Banc logiciel bord dans sa configuration "simulation end-to-end" :
Un profil UML a spécialement été créé pour modéliser les différents concepts portés par le framework C++ GERICOS. Avec l’adoption du framework GERICOS, qui met en œuvre une technologie à base d’objets actifs, la transition de l’activité de modélisation vers l’activité d’implémentation est quasi-immédiate. Il n’y a pas de vraie rupture dans cette transition contrairement à ce qui peut se voir dans d’autres approches visant à concilier UML et la programmation temps réel.
En résumé, l’utilisation du profil UML GERICOS, dans le cadre d’une approche de type MDE (Model Driven Engineering), permet d’automatiser un grand nombre de tâches, et donc d’améliorer la productivité et la qualité du processus de développement des logiciels de bord :
Les règles de transformation et de génération sont actuellement implémentées à l’aide du langage de transformation spécifique à l’atelier UML Entreprise Architect de SparxSystems. Une solution alternative basée sur EMF (Eclipse Modeling Framework) et QVT est actuellement à l’étude.
L’objectif est de modéliser et formaliser le processus de développement des logiciels de bord, en définissant, via des outils comme EPF (Eclipse Process Framework), et en suivant une approche de type SPICE ou CMMI, un référentiel unique mais évolutif, qui pourra permettre à termes une certification des activités logiciels de bord du SII.
Contact : Philippe Plasson
