Les logiciels embarqués spatiaux au LIRA
La complexité croissante des projets scientifiques spatiaux met de plus en plus au premier plan les traitements numériques effectués par les instruments eux-mêmes (les traitements bord). Ceux-ci sont habituellement implémentés dans des logiciels embarqués au sein d’unités de traitement numérique appelées DPU (Digital Process Unit). Ces logiciels, appelés logiciels de bord ou logiciels de vol, ont pour principales tâches de :
- gérer la communication avec la plate-forme satellitaire qui héberge l’instrument,
- prendre en charge le pilotage et le monitoring des modules matériels en interface directe avec les détecteurs (CCD, bolomètres, antennes, etc.),
- piloter et synchroniser les sous-systèmes instrumentaux (modules à effet Peltier, obturateurs, etc.),
- réaliser des traitements visant à extraire l’information pertinente dans le flot de données transmis par les détecteurs, en améliorant le rapport signal sur bruit ou encore en corrigeant les données d’un certain nombre de perturbations dues à l’environnement ou au bougé du satellite,
- réduire, réguler et compresser le flot de données qui est transmis au sol par le satellite sous la forme de télémétries,
- fournir éventuellement à la plate-forme satellitaire des informations issues de calculs d’écartométrie qui serviront à accroître la précision du pointage.
Les logiciels de vol présentent un certain nombre de caractéristiques et de spécificités qui rendent leur développement, leur utilisation et leur maintenance relativement complexes.
Savoir-faire du LIRA
Le LIRA, à travers l’équipe Logiciels de vol du SII, dispose d’un savoir-faire qui couvre l’ensemble du cycle de vie des logiciels embarqués spatiaux . En particulier, l’équipe Logiciels de vol du SII possède une expertise dans les domaines suivants :
- études de faisabilité et de dimensionnement,
- gestion des exigences techniques et scientifiques,
- spécification des interfaces bord-bord (entre la plate-forme et l’instrument ou au sein de l’instrument) et des interfaces bord-sol (télécommandes et télémétries),
- conception architecturale et conception détaillée,
- mise au point d’algorithmes avancés de traitement d’images et de traitement du signal,
- tests et validations,
- suivi technique durant les missions.
L’équipe Logiciels de vol du SII est impliquée dans plusieurs missions en cours d’exploitation ou en phase de préparation.
Dans le cadre du projet CoRoT, le LIRA a participé au dimensionnement, à la spécification et à la validation du logiciel de vol. Durant toute la phase d’exploitation du satellite CoRoT, l’équipe Logiciels de vol du SII a régulièrement été consultée sur des points nécessitant une expertise fine sur le fonctionnement de l’unité de traitement numérique.
En ce qui concerne les projets en préparation, le LIRA est actuellement responsable de l’étude et du développement de plusieurs logiciels de vol pour les missions suivantes :
- RPW sur Solar Orbiter (en exploitation depuis février 2020) :
- développement du logiciel de vol du calculateur de l’instrument RPW (commande/contrôle des sous-systèmes instrumentaux, compression des données scientifiques, détection d’événements de type "shock crossing" et "type III", surveillance active de l’instrument, gestion des mécanismes FDIR, etc.) ;
- PLATO (en développement) :
- développement du logiciel de vol des N-DPU.
Dans le domaine des logiciels embarqués spatiaux, disposer de technologies, d’outils et de processus offrant un fort degré de généricité et de productivité est un véritable enjeu. En effet, plus que jamais, il devient nécessaire d’avoir simultanément la possibilité de mener des études de dimensionnement coûteuses, d’être en mesure de répondre correctement aux appels d’offres lancés par les agences spatiales et de mener à bien les développements des projets sélectionnés.
Parallèlement à sa participation aux projets spatiaux instrumentaux, l’équipe Logiciels de vol du SII mène des d’études de R&D et réalise une veille technologique permanente dans le but de concevoir et mettre en place des technologies, des outils et des processus génériques pour le développement des logiciels embarqués spatiaux.
Ces études de R&D s’articulent essentiellement autour de trois axes :
- les composants logiciels génériques pour l’embarqué spatial ;
- les outils logiciels pour le développement, les tests et la simulation ;
- les méthodes et les processus de développement.
Les objectifs poursuivis sont de :
- diminuer la durée du développement des logiciels de vol,
- réduire l’effort pour le développement des systèmes de tests et d’intégration,
- minimiser le besoin en termes de ressources humaines,
- améliorer la qualité des produits livrés,
- permettre le prototypage rapide des logiciels de vol et le dimensionnement du matériel de vol.
Dans le cadre de ces études, l’équipe Logiciels de vol du SII a conçu une plate-forme générique pour le développement des logiciels scientifiques embarqués dans des instruments spatiaux : la plate-forme GERICOS. Cette plate-forme est actuellement utilisée dans le cadre des projets RPW (Solar Orbiter) et PLATO. Cette plate-forme intègre les technologies incontournables de l’industrie spatiale comme le processeur LEON ou les liens SpaceWire, mais elle agrège aussi de nombreux concepts, pratiques et outils issus des technologies de l’information comme la programmation objets ou l’ingénierie basée sur les modèles.
Contact : Philippe Plasson
++++
Caractéristiques et spécificités des logiciels embarqués spatiaux
Des logiciels temps réel
Les logiciels de bord ont pour principale caractéristique technique d’être des logiciels temps réel. Ils doivent interagir avec leur environnement (détecteurs, capteurs, actionneurs, …) en respectant des temps de réponse "contractuels" et doivent traiter les données acquises en respectant des échéances temporelles strictes. Ils sont généralement construits autour de noyaux temps réel qui offrent un support pour la programmation multi-tâches (RTEMS, ThreadX, etc.). Ils sont développés à l’aide de langages comme le C ou le C++ en suivant des règles de codage standardisées (voir par exemple, les standards de codage en C et C++ produits par l’ESA Board for Software Standardisation and Control). Certaines portions de code critiques peuvent être écrites directement en assembleur.
La conception des logiciels de bord, pour des raisons de sûreté de fonctionnement et de vérificabilité, doit être guidée par la recherche d’un maximum de déterminisme dans le comportement lors de l’exécution. De même, l’architecture mémoire doit être entièrement maîtrisée : on interdit toute allocation dynamique de mémoire et l’occupation de chaque case mémoire est déterminée à l’avance.
Des ressources contraintes
Dans le cadre des instruments spatiaux, les ressources disponibles en termes de consommation électrique, d’encombrement, de poids sont toujours extrêmement contraintes. Cela a un impact direct sur la quantité de mémoire et la puissance CPU dont on peut disposer. Il faut toujours garder à l’esprit ces contraintes lorsque l’on conçoit des logiciels de bord : les ressources, tant en termes de mémoire que de puissance de calcul, sont limitées et il faut composer avec.
Par ailleurs, le choix des cibles matérielles est très limité : les technologies employées doivent être tolérantes aux radiations (rad-hard) et tolérantes aux fautes. Sous l’impulsion de l’ESA, on assiste à une standardisation des technologies spatiales : la famille des processeurs LEON basée sur une architecture SPARC-V8 est en train de s’imposer, de même que la technologie SpaceWire / RMAP. Le processeur LEON est disponible sous la forme d’un modèle VHDL pouvant être synthétisé au sein d’un circuit logique programmable (FPGA) ou dans des circuits intégrés spécialisés (ASIC). Il existe plusieurs SoC (system-on-chip), disponibles sur étagère, intégrant le processeur LEON et des interfaces SpaceWire (AT697-F, SpaceWire-RTC, Aeroflex UT699, COLE ASIC). La convergence des technologies spatiales a pour conséquence de faciliter l’harmonisation des outils de développement et l’adoption de certaines pratiques et techniques issues du monde des technologies de l’information.
Une opérabilité limitée
Une autre caractéristique importante des logiciels de bord tient à leur opérabilité limitée. Le centre de contrôle (segment sol) qui pilote et surveille les opérations du satellite n’est en contact avec celui-ci que durant des périodes de temps relativement courtes, appelées des visibilités. La durée et la fréquence de ces visibilités dépendent de l’orbite suivie par le satellite. Durant ces visibilités, le centre de contrôle peut interagir en temps réel, en fonction des télémétries reçues, avec le logiciel de vol de la charge utile via l’envoi de télécommandes. Mais, toutes les opérations ne peuvent pas être faites durant ces seules périodes de visibilité. Une grande partie des opérations devra être programmée pour être réalisée hors visibilité, ce qui introduit un retard dans le diagnostic des anomalies et défaillances éventuelles. Cette interactivité intrinsèquement faible et les limites existant sur le volume de données pouvant être transmis quotidiennement du sol vers le bord, ainsi que du bord vers le sol (entre 2 Gbits/jour et 400 Gbits/jour), doivent être prises en compte durant la conception des logiciels de bord : on essaiera de minimiser les échanges bord-sol en développant un maximum l’autonomie des logiciels de bord.
Contact : Philippe Plasson
++++
Cycle de vie des logiciels embarqués spatiaux
Le processus de développement des logiciels embarqués spatiaux, du fait de la criticité de ces derniers, est toujours très lourd et s’étale sur plusieurs années. Entre les premières études de faisabilité et la première utilisation en vol des logiciels développés, il peut s’écouler une dizaine d’années. Par ailleurs, des opérations de maintenance peuvent avoir lieu durant toute la phase d’exploitation (entre trois et six ans). Ceci implique de maintenir les équipes sur une très longue durée et surtout de mettre en place des méthodes de travail rigoureuses qui s’appuient sur les standards de l’industrie spatiale.
Le processus de développement des logiciels embarqués spatiaux est formalisé dans des documents de standardisation maintenus par l’ECSS (European Cooperation For Space Standardization). Ces recommandations définissent les différentes phases du processus et, pour chacune des phases, les documents de spécification et de justification qui doivent être fournis, ainsi que l’ensemble des revues devant être mises en place.
Phase 0-A
Durant la phase 0-A des projets, l’activité se concentre autour des études de faisabilité et de dimensionnement. Il s’agit de maintenir un dialogue étroit avec l’équipe scientifique en charge des spécifications scientifiques de l’instrument afin de dresser une première mouture des exigences fonctionnelles et non fonctionnelles des traitements bord. L’objectif est aussi de déterminer l’ensemble des ressources matérielles nécessaires et de vérifier si elles sont en adéquation avec ce qui est disponible. Des bilans de charge CPU et d’occupation mémoire doivent être menés à bien durant cette phase. Ces bilans sont complémentaires de ceux réalisés par les architectes électriques concernant la consommation électrique, l’encombrement, le poids, etc.
Phase B
Les spécifications logicielles définitives, en termes de définition des interfaces et de définition des exigences utilisateurs, sont produites durant la phase B. Ces spécifications n’évolueront qu’à la marge durant les phases ultérieures du projet et de façon très encadrée. Durant la phase B, l’activité de prototypage et de validation des choix techniques mène à une première définition de l’architecture logicielle.
Phases C et D
Les phases C et D sont consacrées à la conception détaillée, à l’implémentation et aux tests. Les activités de tests, de validation et d’intégration des logiciels de bord sont particulièrement lourdes car elles recouvrent à la fois les aspects scientifiques et les aspects techniques. Les algorithmes scientifiques qui ont été implémentés sont validés par rapport à des modèles maintenus par les équipes scientifiques et à l’aide de données produites par des simulateurs. La couche technique des logiciels de bord et leurs interfaces sont testées à l’aide d’outils offrant un fort degré d’automatisation. Un suivi qualité pointu est mis en place durant ces activités critiques.
Phase E
Durant la phase d’exploitation de l’instrument, un suivi technique régulier est assuré par les équipes responsables des logiciels de bord. Ce suivi est basé sur l’analyse des télémétries techniques et scientifiques transmises par l’instrument. Différents niveaux de maintenance des logiciels de bord peuvent avoir lieu durant les missions : on parle de maintenance corrective quand il s’agit de corriger une anomalie et de maintenance adaptative quand il s’agit d’ajouter une nouvelle fonctionnalité ou de modifier une fonctionnalité existante.
Contact : Philippe Plasson
++++
La plate-forme GERICOS
Présentation de la plate-forme GERICOS
La plate-forme GERICOS (GEneRIC Onboard Software) est constituée :
- d’un ensemble de composants logiciels réutilisables et personnalisables permettant de développer rapidement des applications de vol,
- d’un système de tests et de simulations adaptable en fonction du contexte de l’instrument, appelé Banc logiciel bord GEDEON,
- d’une boîte à outils pour l’ingénierie basée sur les modèles permettant d’aborder les développements selon une approche de type MDE (Model Driven Engineering),
- d’un ensemble de règles méthodologiques organisées dans un référentiel qualité.
Composants logiciels génériques pour l’embarqué spatial
Le framework GERICOS
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.).
Logiciel de vol générique
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 :
Le Banc logiciel bord GEDEON
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" :
Boîte à outils pour l’ingénierie pilotée par les modèles
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 :
- génération automatique du modèle UML d’implémentation à partir du modèle UML de conception ;
- génération automatique du code C++ de déclaration des classes et du code de marshalling/unmarshalling utilisé par les objets actifs dans la gestion des échanges de messages ;
- génération automatique de la documentation du code C++ à partir de la documentation des diagrammes UML ;
- génération automatique des classes de tests unitaires CppUnit ;
- génération automatique du modèle de vérification de l’ordonnançabilité des tâches temps réel.
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.
Méthodes, processus et assurance qualité
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
