Logiciel de vol des N-DPU de PLATO

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

Processus d’acquisition PLATO N-DPU ASW

© LESIA

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)

Logiciel d’application PLATO N-DPU GSE

© LESIA

Outil de contrôle des paquets TC/TM

© LESIA

Banc d’essai N-DPU

© LESIA

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

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

Contact : Philippe Plasson