LESIA - Observatoire de Paris

PLATO N-DPU Flight Software

Luc Heintze — 2024-01-15T20:29:27Z

The N-DPU flight software is the software that drives the 24 normal cameras on the PLATO payload. This software implements photometry algorithms that reduce the flow of data produced by calculating directly on board the flux of stars that will be used by the ground segment to construct light curves and detect exoplanets. This software was designed and produced by LESIA's flight software team.

Sommaire

The PLATO mission

PLATO (“PLAnetary Transits and Oscillations of stars”) is a M-class mission of the European Space Agency foreseen to be launched at the end of 2026. PLATO aims to characterize exoplanetary systems by detecting planetary transits and conducting asteroseismology of their parent stars.

The PLATO payload concept is based on a multi-camera approach, involving a set of 24 normal instruments monitoring stars fainter than mV=8, plus a smaller set of 2 fast instruments observing extremely bright stars with magnitudes brighter than mV=8.


The PLATO satellite and its 26 cameras: © ESA

PLATO on-board Data Processing System

The PLATO Data Processing System, called DPS, is the sub-system of PLATO payload module in charge of the on-board data processing (data acquisition, data reduction, data compression, monitoring, etc.). The DPS is a set of several on-board computer boards connected via a SpaceWire network. The DPS architecture is composed of:

12 Normal Data Processing Units (N-DPU) embedding a GR712RC dual-core LEON3FT processor.
two Fast Data processing Units (F-DPU).
two Instrument Control Units (ICU) working in cold redundancy.


The PLATO on-board data processing system: © DLR

The N-DPU and F-DPU are in charge of processing respectively the data of two normal cameras for each N-DPU and the data of one fast camera for each F-DPU. The ICU are in charge of managing the payload, the communication with the Service Module (SVM) and the compression of scientific data before transmitting them as telemetry to the SVM.

N-DPU boards and MEU

The N-DPU board is made up of the following parts:

1 dual core LEON3FT GR712RC SoC clocked at 50MHz
1 SDRAM of 256 MiB (64 M x (32b+16b))
4 SpaceWire interfaces


PLATO N-DPU board: © LESIA

The MEU device is an integrated box made up of:

6 N-DPU (Normal Data Processing Units)
2 PSU (Power Supply Units, main and redundant)
2 SpaceWire router units

The MEU H/W is provided by Spain (IAA-CSIC / IAC / Thales Alenia Space).


Block diagram of the MEU: © DLR


MEU box: © IAA

PLATO N-DPU flight software overview

The N-DPU Flight Software (or N-DPU ASW for N-DPU Application Software) is the embedded software deployed in each of the 12 N-DPU boards. The N-DPU ASW has been specified, designed, implemented, validated and qualified by LESIA.

Each N-DPU ASW manages two cameras (four 21-million pixel detectors per camera) and collects science and housekeeping data from their front-end electronics (N-FEE).

During the Observation mode, each N-DPU unit is receiving window segments of observed stars from both N-FEE as inputs. The window segments are transferred every 6.25 seconds through a single SpaceWire link per N-FEE. The window segments are then reconstructed back using a lookup table into windows and are processed by the N-DPU ASW.

In the observation mode, the N-DPU ASW role is to produce 6x6-pixel square-shaped windows (i.e. raw star windows called "imagettes" not transformed on-board) for 21% of the incoming stars (out of 132350 stars per camera) and photometry products using binary mask algorithms for 79% of them. The photometry products are made up of star fluxes and centers of brightness of stars. The N-DPU ASW computes also the offset, background, smearing and performs outlier detection to improve the SNR of the products. The N-DPU ASW calculates light fluxes and centers of brightness every 25 seconds. These photometry products are then averaged over 50 and 600 seconds (samples of 2 and 24 measurements respectively). The averaged photometry is then sent to the ICU. The other 21% stars (27500) of each N-cameras are directly transmitted to the ICU.


PLATO N-DPU ASW processing pipeline: © LESIA

The definition of all the scientific algorithms is made by the PLATO DPA-WG.

In support of the "Observation" mode, the N-DPU flight software features a mode that automatically calculates the positioning of the star windows on the CCDs, based on the telescopes' attitude and the star catalog giving their positions in the barycentric celestial reference system (BCRS).

In addition to the science services, the N-DPU ASW offers services dedicated to the calibration activities: full-image acquisition service and window acquisition service.

Last but not least, the N-DPU ASW implements the standard PUS services for checking the telecommand packets, managing the production of housekeeping reports and event reports, handling the time, accessing to the N-DPU and N-FEE memories (load, dump and check), managing and monitoring the on-board parameters, etc.

N-DPU flight software architecture

A multi-core architecture built with GERICOS framework

The architecture of the N-DPU ASW is built according to an Asymmetric Multi-Processing approach (AMP) using the GERICOS framework running on top of the RTEMS 4.8 real-time kernel (Edisoft version). The GERICOS (GEneRIC Onboard Software) platform is a generic LESIA platform for the development of software for space payloads.

With the GERICOS::CORE framework, a real-time application is built as a set of active objects (called "tasks"), each active object having its own message queue and its own computational thread. Each Thread processes incoming messages one by one by executing the function associated with the message.

The support of the AMP architecture in the GERICOS framework relies on the intrinsic features of the active object paradigm of the GERICOS::CORE layer. With this paradigm, two objects communicate via marshalled messages. Each object is split in an implementation object (which implements the services offered by the object) and in a stub object which is responsible for the marshalling aspects (message serialization / unserialization). The marshalling process implemented in the stub has been extended so that the objects are able to communicate from a CPU core to another one using simple communication mechanisms based on shared memory for passing the messages and spin locks based on the LEON3 atomic compare-and-swap operation (CASA instruction) to make safe the inter-core concurrent access to the memory.

The dual-core AMP architecture of the N-DPU ASW means that two applications coexist.

The first application, which acts as the master, is deployed on the LEON3-FT CPU core #0 and is in charge of managing the ICU interfaces (telecommand and telemetry packets), processing the data of camera #A, managing modes and technical services. This first application is made up of 20 realtime tasks.

The second application is deployed on the LEON3-FT CPU core #1 and is in charge of processing the data of camera #B and scrubbing the memory. This second application is made up of 8 realtime tasks.


N-DPU Application Software Dual Core Architecture: © LESIA

A real-time software

In terms of real-time sequencing, the fundamental period to consider is 6.25 seconds: the software receives every 6.25s a new set of star windows to process. The transmission of these star windows is spread over the 4.1 seconds corresponding to the readout of the detector (1). Up to 25 packets of 32 kilobytes are transmitted per second by the camera over the readout period. At the end of the packet reception, the software has to extract the window segments from the packets and reconstruct the windows in less than 2.15 seconds, that is to say before the end of the cycle of 6.25 seconds (2). Once the reconstruction phase is complete, the software can start the photometric processing. These photometric treatments are carried out during the transmission of the star windows of the next detector and must imperatively be finished 4.1 seconds after the starting of the following cycle (3).


PLATO N-DPU ASW timeline: © LESIA

During the observation mode, both applications communicate through the circular buffers containing the telemetry packets. The second application builds the telemetry packets corresponding to the data from camera B and stores them in a shared queue. The first application retrieves these packets from the shared queue and transmits them to the ICU. There can also be inter-core message exchanges when, for example, an event is detected by the second application and a report must be transmitted by the first application.

N-DPU application software GSE

The PLATO N-DPU Application Software GSE (Ground Support Equipment) are a set of hardware and software components used for validating the N-DPU ASW and testing the MEU system.

The GSE software part is based on the GAUSS platform (Generic Api for ground Support Software), a project developed at LESIA, which offers generic and flexible GSE features:

SpaceCraft interface simulator
System commanding (TC script editor)
TM visualization and monitoring
Assertion language for automatic test checking
Distributed architecture
SQL Database management

In addition to these software components, the PLATO N-DPU Application Software GSE also contain several hardware components:

STAR-Dundee SpaceWire Bricks
PLATO camera simulator (SIMUCAM) provided by the MAUA Institute (IMT, São Paulo)


PLATO N-DPU Application Software GSE: © LESIA


Tool for monitoring the TC/TM packets: © LESIA


ASW N-DPU ASW Test Bench: © LESIA

Key Dates

Date	Event
July 2014	PLATO selection by ESA
March 2016	N-DPU ASW development kick-off
June 2017	PLATO "adoption" by ESA
September to December 2018	Software SRR (System Requirement Review)
September to December 2019	Software PDR (Preliminary Design Review)
July 2020	Delivery to the PLATO consortium of PLATO N-DPU ASW V0.4 (full-image calibration mode)
July 2021	Delivery to the PLATO consortium of PLATO N-DPU ASW V0.8 (window calibration mode)
September 2022	Delivery to the PLATO consortium of PLATO N-DPU ASW V0.9 (science services partially implemented)
October to December 2022	Software CDR (Critical Design Review)
September 2023	Delivery to the PLATO consortium of PLATO N-DPU ASW V1.0 (100% of functionalities are implemented)

People involved in the N-DPU flight software project

Name	Role
Aliocha Amerge	Flight software development (trainee)
Gaele Barbary	MEU functional testing
Kimberley Berisha	Flight software development (trainee)
Alexandre Crignola	GSE software development (ASTEK)
Florent Ducellier	Flight software specification and validation (ASTEK)
Gary Gabriel	GERICOS framework development
Nicolas Gauthier	Flight software development
Loic Gueguen	GSE software management
Pierre-Vincent Gouel	Flight software development
Baptiste Gouesbet	Flight software development (ASTEK)
Lee-Roy Malac-Allain	Flight software development
Aymeric Menager	Flight software development (trainee)
Thibault Lamborot	GSE software development
Gaelle Palandri	GSE software development
Philippe Plasson	Project management
Hugo Pompougnac	Flight software development (trainee)
William Recart	Flight software product assurance management (Hensoldt Space Consulting)

Contact : Philippe Plasson

Logiciel de vol des N-DPU de PLATO

Philippe Plasson — 2024-01-15T20:25:58Z

Le logiciel de vol des N-DPU est le logiciel embarqué qui pilote les 24 caméras normales de la charge utile du satellite PLATO. Il met en œuvre des algorithmes de photométrie qui permettent de réduire le flot de données produit par les caméras en calculant, directement à bord, le flux des étoiles ou en transmettant des fenêtres de 6x6 pixels centrées autour des étoiles. Ce sont ces données qui seront utilisées par le segment sol pour construire les courbes de lumière des étoiles et détecter des exoplanètes. Ce logiciel a été conçu et réalisé par l'équipe "Logiciels de Vol" du LESIA.

Sommaire

La mission PLATO

PLATO ("PLAnetary Transits and Oscillations of stars") est une mission de classe M de l'Agence spatiale européenne dont le lancement est prévu fin 2026. L'objectif scientifique de la mission est de détecter, grâce à la méthode des transits planétaires, des planètes rocheuses dans la zone habitable et – simultanément – de déterminer, grâce à la sismologie, les caractéristiques des étoiles hôtes des planètes.

Le concept instrumental de PLATO est basé sur une approche multi-caméras, comprenant un ensemble de 24 caméras observant à la cadence d'une image toutes les 25 secondes plus un ensemble de deux caméras observant un champ plus petit, à la cadence de 2.5 secondes, dédiées à la mesure des étoiles les plus brillantes.


Le satellite PLATO avec ses 26 cameras: © ESA

Système de traitement de données bord de PLATO

Le système de traitement des données de PLATO, appelé DPS (Data Processing System), est le système de la charge utile de PLATO responsable du traitement des données à bord (acquisition des données, réduction des données via des algorithmes de photométrie, compression des données, surveillance, etc.). Le DPS est constitué d'un ensemble de plusieurs cartes électroniques équipées de processeurs et interconnectées via un réseau SpaceWire. L'architecture du DPS est composée de :

12 unités de traitement gérant les caméras normales (N-DPU : Normal Data Processing Units) et intégrant un processeur double cœur LEON3FT GR712RC. Chaque carte N-DPU gère deux caméras.
Deux unités de traitement gérant les caméras rapides (F-DPU : Fast Data processing Units).
Deux unités de contrôle des instruments (ICU : Instrument Control Units) fonctionnant en redondance froide. L'ICU est chargé de la gestion de la charge utile, de la communication avec le module de service (SVM) du satellite et de la compression des données scientifiques avant transmission au SVM sous forme de télémétries.


Le système de traitement des données embarqué PLATO: © DLR

Cartes N-DPU et boîtiers MEU

Une carte électronique N-DPU contient les composants suivants :

1 processeur bi-coeur LEON3FT GR712RC cadencé à 50MHz
1 SDRAM de 256 MiB (64 M x (32b+16b))
4 interfaces SpaceWire


Carte PLATO N-DPU: © LESIA

Le MEU est un boîtier intégrant en son sein :

6 cartes N-DPU
2 cartes PSU (Power Supply Unit)
2 routeurs SpaceWire

Le boîtier MEU, avec ses différentes cartes électroniques, est fourni par l'Espagne (IAA-CSIC / IAC / Thales Alenia Space).


Schéma fonctionnel du MEU: © DLR


Boîtier MEU: © IAA

Aperçu du logiciel de vol des N-DPU de PLATO

Le logiciel de vol des N-DPU est le logiciel embarqué déployé dans chacune des 12 cartes N-DPU. Le logiciel de vol N-DPU a été spécifié, conçu, mis en œuvre, validé et qualifié par le LESIA.

Chaque logiciel de vol des N-DPU gère deux caméras, chaque caméra comportant quatre détecteurs de 21 millions de pixels. Le logiciel de vol N-DPU pilote les électroniques de proximité des caméras (N-FEE), gère leurs modes de fonctionnement, acquiert les pixels numérisés ainsi que les données techniques utiles pour la surveillance (tensions, températures, états, etc.).

En mode observation, chaque logiciel de vol des N-DPU reçoit, en provenance des deux caméras, un flux de segments de fenêtres contenant l'image des étoiles observées. Les segments de fenêtre sont transférés toutes les 6,25 secondes via une liaison SpaceWire. Les segments sont assemblés entre eux afin de reformer des fenêtres à l'aide d'une table de recherche (LUT). Ces fenêtres contenant les taches images des étoiles sont ensuite traitées par le logiciel de vol.

Dans son mode "observation", le rôle du logiciel de vol des N-DPU est de générer des fenêtres carrées de 6x6 pixels (c'est-à-dire des fenêtres contenant une tache image de l'étoile appelée "imagette" non transformée à bord) pour 21% des étoiles traitées (sur 132 350 étoiles par caméra) et de calculer des produits photométriques en utilisant des algorithmes à base de masques binaires (photométrie d'ouverture) pour 79% d'entre elles. Les produits photométriques correspondent au flux des étoiles et à leur centre de luminosité. Le logiciel de vol des N-DPU calcule également, afin de corriger les flux, le décalage des électroniques de lecture, le fond de ciel et le smearing (propagation de la charge d'un pixel saturé vers les pixels adjacents).

Le logiciel de vol des N-DPU calcule les flux lumineux et les centres de luminosité toutes les 25 secondes. Ces produits photométriques sont ensuite moyennés sur 50 et 600 secondes (échantillons de 2 et 24 mesures respectivement). Avant de moyenner temporellement les flux, le logiciel de vol des N-DPU effectue une détection des valeurs aberrantes. Les données moyennées sont ensuite envoyées à l'ICU sous forme de paquets télémétriques. Les autres 21% d'étoiles (27 500) de chaque N-caméra sont directement transmis à l'ICU sous forme d'imagettes de 6 par 6 pixels. Le logiciel de vol des N-DPU est aussi capable de transmettre des fenêtres dont la forme est très étirée verticalement et qui sont utilisées pour les étoiles dites "saturées" (étoiles extrêmement brillantes).


Pipeline de traitement PLATO N-DPU ASW: © LESIA

La définition "théorique" de tous les algorithmes scientifiques mis en œuvre dans le logiciel de vol des N-DPU a été faite par le groupe DPA-WG de PLATO piloté par le LESIA.

Le logiciel de vol des N-DPU, outre le mode "Observation", dispose d'un mode permettant de calculer automatiquement le positionnement des fenêtres étoiles sur les CCD à partir de l'attitude des télescopes et du catalogue des étoiles donnant leurs positions dans le système de référence céleste barycentrique (BCRS).

En plus des services scientifiques, le logiciel de vol des N-DPU offre des services dédiés aux activités d'étalonnage : service d'acquisition d'images complètes et service d'acquisition de fenêtres.

Enfin, le logiciel de vol des N-DPU met en œuvre des services techniques comme le "scrubbing" (parcours en boucle de la mémoire afin de détecter les erreurs mémoire et de les corriger) ou encore les services du standard PUS de l'ESA :

vérification des paquets de télécommandes ;
test de communication ;
gestion de la production de rapports périodiques contenant les paramètres instrumentaux de type "housekeepings" ;
gestion de la production de rapports sporadiques (événements liés à la progression d'une activité ou à la détection d'une erreur) ;
gestion de l'heure ;
gestion de la mémoire (chargement de la mémoire bord, lecture et vérification) ;
gestion des paramètres bord (lecture / écriture) ;
surveillance des paramètres instrumentaux.

Architecture du logiciel de vol des N-DPU

Une architecture multi-cœurs construite avec la plateforme GERICOS

Le logiciel de vol des N-DPU est construit selon une architecture multi-cœurs de type AMP (Asymmetric Multi-Processing) en utilisant la plateforme GERICOS fonctionnant au-dessus du noyau temps réel RTEMS 4.8 (version Edisoft). La plateforme GERICOS (GEneRIC Onboard Software) est une plateforme générique du LESIA pour le développement de logiciels embarqués pour les instruments scientifiques spatiaux.

Avec la plateforme GERICOS, une application temps réel est construite comme un ensemble d'objets actifs (appelés "tâches"), chaque objet actif ayant sa propre queue de messages et son propre fil d'exécution. Chaque tâche traite les messages entrants un par un, en exécutant la fonction associée au message.

Le support des architectures multi-cœurs AMP dans la plateforme GERICOS repose sur les caractéristiques intrinsèques du paradigme "objets actifs" de la couche GERICOS::CORE. Avec ce paradigme, deux objets communiquent via des messages sérialisés. Chaque objet est divisé en un objet d'implémentation (qui met en œuvre les services offerts par l'objet) et en un objet "stub" qui est responsable des aspects de sérialisation et désérialisation des messages. Le processus de sérialisation et désérialisation mis en œuvre dans le "stub" a été étendu de manière à ce que les objets puissent communiquer d'un cœur de CPU à un autre en utilisant des mécanismes de communication simples basés sur la mémoire partagée pour transmettre les messages et des spin locks basés sur l'opération atomique de comparaison et d'échange du processeur LEON3 (instruction CASA) pour sécuriser l'accès concurrent à la mémoire entre les différent cœurs.

L'architecture AMP à deux cœurs du logiciel de vol des N-DPU ASW implique que deux applications coexistent.

La première application, qui joue le rôle de maître, est déployée sur le cœur #0 du processeur LEON3-FT et est chargée de gérer les interfaces avec l'ICU (paquets de télécommandes et de télémétries), de traiter les données de la caméra #A, de gérer les modes et les services techniques. Cette première application est composée de 20 tâches temps réel.

La seconde application est déployée sur le cœur #1 du processeur LEON3-FT et est en charge du traitement des données de la caméra #B et du nettoyage de la mémoire. Cette deuxième application est composée de 8 tâches temps réel.


Logiciel d'application N-DPU Architecture à double cœur: © LESIA

Un logiciel temps-réel

En termes de séquencement temps-réel, la période fondamentale à considérer est de 6,25 secondes : le logiciel reçoit toutes les 6,25 secondes une nouvelle série de fenêtres de 6x6 pixels à traiter. La transmission de ces fenêtres est répartie sur les 4,1 secondes correspondant à la lecture du détecteur (1). Jusqu'à 25 paquets de 32 kilo-octets sont transmis par seconde par la caméra pendant la période de lecture. À la fin de la réception des paquets, le logiciel doit extraire les segments de fenêtre des paquets et reconstruire les fenêtres en moins de 2,15 secondes, c'est-à-dire avant la fin du cycle de 6,25 secondes (2). Une fois la phase de reconstruction terminée, le logiciel peut commencer les traitements photométriques. Ces traitements photométriques sont effectués pendant la transmission des fenêtres du détecteur suivant et doivent impérativement être terminés 4,1 secondes après le début du cycle suivant (3).

En mode observation, les deux applications communiquent par l'intermédiaire de files d'attente de type FIFO contenant les paquets de télémétrie. La seconde application crée les paquets de télémétrie correspondant aux données de la caméra B et les stocke dans une file d'attente partagée. La première application récupère ces paquets dans la file d'attente partagée et les transmet à l'ICU. Il peut également y avoir des échanges de messages entre les cœurs lorsque, par exemple, un événement est détecté par la deuxième application et qu'un rapport doit être transmis par la première application.

Plateforme de tests du logiciel de vol des N-DPU

La plateforme de tests du logiciel de vol des N-DPU est un ensemble de composants matériels et logiciels utilisés pendant les activités de développement et de validation.

La partie logicielle de cette plateforme est basée sur GAUSS (Generic Api for ground Support Software), un projet développé au LESIA, qui offre des fonctionnalités génériques et flexibles :

Simulateur d'interface satellite
Commande du système (éditeur de scripts de télécommandes)
Visualisation et surveillance de la télémétrie
Langage d'assertion pour la vérification automatique des tests
Architecture distribuée
Gestion de la base de données SQL

En plus de ces composants logiciels, la plateforme de tests du logiciel de vol des N-DPU contient également plusieurs composants matériels :

Brique SpaceWire STAR-Dundee
Simulateur de caméra PLATO (SIMUCAM) fourni par l'institut MAUA (IMT, São Paulo)


Vue d'artiste du satellite PLATO: © ESA (acknowledgement : work performed by ATG under contract to ESA), CC BY-SA 3.0 IGO

Dates clés

Date	Evénement
Juillet 2014	Sélection de PLATO par l'ESA
Janvier 2016	Démarrage des activités de développement du logiciel de vol des N-DPU
Juin 2017	"Adoption" de PLATO par l'ESA
Septembre à décembre 2018	Software SRR (System Requirement Review)
Septembre à décembre 2019	Software PDR (Preliminary Design Review)
Juillet 2020	Livraison au consortium PLATO de la version 0.4 du logiciel de vol (mode de calibration plein-cadre)
Juillet 2021	Livraison au consortium PLATO de la version 0.8 du logiciel de vol (mode de calibration fenêtré)
Septembre 2022	Livraison au consortium PLATO de la version 0.9 du logiciel de vol (services scientifiques partiellement implémentés)
Octobre à décembre 2022	Software CDR (Critical Design Review)
Septembre 2023	Livraison au consortium PLATO de la version 1.0 du logiciel de vol (100% des fonctionnalités sont implémentées)

Personnes impliquées dans le projet logiciel de vol des N-DPU de PLATO

Nom	Rôle
Aliocha Amerge	Développement du logiciel de vol (stagiaire)
Gaele Barbary	Tests fonctionnels du MEU
Kimberley Berisha	Développement du logiciel de vol (stagiaire)
Alexandre Crignola	Développement de la plate-forme de tests (ASTEK)
Florent Ducellier	Spécification et validation du logiciel de vol (ASTEK)
Gary Gabriel	Développement du framework GERICOS
Nicolas Gauthier	Développement du logiciel de vol
Loic Gueguen	Gestion de projet : plate-forme de tests
Pierre-Vincent Gouel	Développement du logiciel de vol
Baptiste Gouesbet	Développement du logiciel de vol (ASTEK)
Lee-Roy Malac-Allain	Développement du logiciel de vol
Aymeric Menager	Développement du logiciel de vol (ASTEK)
Thibault Lamborot	Développement de la plate-forme de tests
Gaelle Palandri	Développement de la plate-forme de tests
Philippe Plasson	Gestion de projet : logiciel de vol
Hugo Pompougnac	Développement du logiciel de vol (stagiaire)
William Recart	Gestion assurance produit (Hensoldt Space Consulting)

Contact : Philippe Plasson

Logiciels embarqués spatiaux

Philippe Plasson — 2008-09-29T19:39:28Z

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.

Sommaire

1 2 3 4

Les logiciels embarqués spatiaux au LESIA

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 LESIA

Le LESIA, à 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.

Projets

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

R&D et veille technologique

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

1 2 3 4