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