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


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

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

Contrôle temps-réel pour l'instrumentation sol et le calcul haute performance

Arnaud Sevin — 2016-11-24T09:25:03Z

Contexte

L'Optique Adaptative (OA) est une technique instrumentale pour la correction d'aberrations dues à la turbulence atmosphérique et évoluant dynamiquement dans le temps. Elle se retrouve au cœur des opérations des télescopes de diamètre extrême (ELT) qui nécessitent le contrôle, à une cadence de l'ordre de la milliseconde, de miroirs déformables (DM) avec des milliers de degrés de liberté. Pour assurer une compensation de la turbulence suffisante, avec une grande stabilité, le temps de calcul du contrôleur temps-réel (RTC) doit être déterministe à l'échelle de quelques dizaines de microsecondes, et la latence dans les transferts de données entre les capteurs, les noyaux de calcul et l'optique déformable doit être minimisée.

Pour concevoir cet élément essentiel de l'opération des télescopes géants, la communauté astronomique est confrontée à des défis techniques, émergeant de la combinaison d'une bande passante élevée pour le transfert de données, d'une faible latence et des exigences de haut débit.

Répondre aux spécifications de ces systèmes temps réel multi-capteurs traitant des données de manière intensive, revient à aborder deux thèmes stratégiques du calcul haute performance (HPC) :

optimiser l'équilibre entre les performances des processeurs, la capacité de mémoire et l'accès aux données entre les capteurs, les nœuds de calcul et de stockage, avec des performances déterministes ;
construire des systèmes modulaires, évolutifs et hétérogènes.

Le RTC d'un système d'OA l'échelle de l'European ELT (E-EL) peut ainsi être considéré comme une facilité HPC interagissant en temps réel avec des capteurs et des éléments actifs pour s'adapter à l'évolution des conditions d'observation dans le but de fournir des données scientifiques à l'utilisateur.

Savoir-faire du LESIA

Le LESIA dispose d'une longue histoire dans l'OA. Par le passé, il a participé aux projets pionniers comme :

Plus récemment, le LESIA a été impliqué dans le développement ainsi que dans la validation des RTC dans les projets suivants, et continue à en assurer la maintenance :

SPHERE, spécification et validation de SPARTA pour SAXO ;
GRAVITY, spécification, développement et validation du suiveur de franges ;
OEIL, validation et optimisation du calculateur temps-réel d'ALPAO (ACE).

Actuellement, les projets prioritaires de l'équipe sont :

R&D GreenFlash (financement européen H2020), avec au LESIA l'accent mis sur les calculateurs à base de GPUs
MICADO/MAORY-SCAO : Spécification/développement/intégration du RTC

Technologies associées

Ces calculateurs sont généralement hétérogènes afin d'obtenir le maximum de performance de chaque composant. Suivant les besoins, ils peuvent utiliser les technologies suivantes :

CPU
GPU
FPGA
DSP

Les développements au sein de l'équipe se font essentiellement en langage objet (C++/CUDA) pour la performance tout en s'appuyant sur des langages interprétés (Python) pour la souplesse d'utilisation et de validation.

Responsable de l'équipe : Arnaud Sevin

Le SII (Service Informatique Instrumentale)

Philippe Plasson — 2015-05-04T09:57:14Z

Le Service Informatique Instrumentale (SII) du LESIA regroupe les informaticiens du laboratoire participant au développement de logiciels embarqués spatiaux, de calculateurs temps-réel pilotant les instruments équipant les grands télescopes (VLT, E-ELT) et d'outils logiciels de tests.

Missions

Le Service Informatique Instrumentale du LESIA regroupe trois entités :

L'équipe « Logiciels de vol » (5 personnes) qui est en charge de la réalisation des logiciels embarqués dans les instruments spatiaux du LESIA. Les missions de l'équipe « Logiciels de vol » couvrent les aspects suivants :
- Prototypage algorithmique, étude de faisabilité, dimensionnement logiciel / matériel et participation à la définition des architectures des systèmes numériques durant les phases 0/A des projets.
- Spécification des logiciels bord et des interfaces TC/TM.
- Conception, développement, validation et qualification de logiciels embarqués spatiaux scientifiques selon les standards des agences spatiales pour des cibles de type LEON (projets CNES / ESA / NASA) ou ARM (projets de type CubeSat).
- Production et maintenance d'outils génériques (process, frameworks, bibliothèques logicielles), via la plate-forme GERICOS, pour le développement de logiciels embarqués spatiaux scientifiques.
- R&D dans le domaine des logiciels embarqués spatiaux.
- Développement de bases données instrument livrées aux agences spatiales pour intégration dans les bases de données mission des satellites.

L'équipe « Logiciels de tests et validation » (3 personnes) qui est en charge de la réalisation de la plate-forme de tests utilisée dans le cadre du développement des logiciels de vol, ainsi que de la réalisation de tous les outils logiciels utilisés dans le cadre des AIT/AIV des instruments spatiaux du LESIA. Les missions de l'équipe « Logiciels de tests et validation » couvrent les aspects suivants :
- Conception et développement de moyens logiciels de test et de validation des logiciels de vol et des instruments spatiaux.
- Production et maintenance d'une plate-forme générique (GAUSS) et d'un framework de méta-définition des données (PALISADE) pour le test et la validation des instruments réutilisables à travers les projets et adaptés à différents types de cibles : instruments pour les missions de type CNES / ESA / NASA, projets CubeSat, instrumentation sol.
- Développement d'outils couplés aux bases de données instrument pour la génération automatique :
  - de code embarqué,
  - d'interfaces graphiques pour les systèmes de commande / contrôle,
  - de documents décrivant les paquets TC/TM,
  - de tables relationnelles au format SCOS-2000 (Satellite Control and Operation System) utilisé par les centres de mission de l'ESA.

L'équipe « Contrôle temps-réel pour l'instrumentation sol et le calcul haute performance » (4 personnes) qui participe au développement des instruments sol équipant les grands télescopes (VLT, E-ELT) et qui possède une expertise pointue dans le domaine de la mise en oeuvre des GPU pour la simulation numérique et le développement de calculateurs temps-réel. Les missions de l'équipe « Contrôle temps-réel pour l'instrumentation sol et le calcul haute performance » couvrent les aspects suivants :
- Développement de logiciels temps-réel pour l'instrumentation sol.
- Développement de logiciels pour le pilotage de bancs d'optique adaptative.
- Développement d'algorithmes et de bibliothèques pour l'optique adaptative.
- Simulation sur GPU de systèmes d'optique adaptative.
- Spécification, conception, prototypage et développement de calculateurs temps-réel pour l'optique adaptative des instruments des grands télescopes (VLT / E-ELT).
- R&D dans le domaine des calculateurs temps-réel et des architectures à base de GPU.

Personnels impliqués

Responsable du service : Philippe Plasson
Responsable de l'équipe « Logiciels de vol » : Philippe Plasson
Responsable de l'équipe « Logiciels de tests et validation » : Loïc Gueguen
Responsable de l'équipe « Contrôle temps-réel pour l'instrumentation sol et le calcul haute performance » : Arnaud Sevin

Personnels impliqués :
- 6 ingénieurs permanents (2 IR, 4 IE)
- 3 CDD
- 3 ingénieurs prestataires

Implication dans les projets

Les projets auxquels participent les membres du SII sont les suivants :

Projets spatiaux :
- RPW sur Solar Orbiter : logiciel de vol du calculateur de bord (DPU), moyens logiciels d'essai de la MEB (Main Electronic Box), base de données de l'instrument ;
- PLATO : logiciel de vol des calculateurs de bord (N-DPU) et moyens logiciels de tests associés ;
- Pollux sur LUVOIR : études de phase A du logiciel bord.
Projets sol :
- OEIL : logiciel de pilotage du banc d'OA ;
- GRAVITY sur le VLT : logiciel temps-réel ;
- COMPASS : simulation sur GPU de systèmes d'optique adaptative ;
- MICADO sur l'E-ELT : RTC (Real Time Computer) ;
- Green Flash : prototypage des calculateurs temps-réel pour l'optique adaptative des instruments de première lumière de l'E-ELT.

PALISADE

Loïc Gueguen — 2009-01-27T09:17:52Z

Contexte

Lorsque l'on transmet des commandes vers un instrument (les télécommandes) ou lorsque l'on reçoit les données transmises par cet instrument (les télémétries), il y a un échange de données qui s'établit entre deux systèmes, l'instrument et les moyens de test, selon un protocole de communication précis qui définit le format des échanges (structure des paquets, valeurs des différents champs, etc.). Tous ces échanges se font dans un format binaire et non dans un langage naturel directement exploitable : il est nécessaire d'utiliser des logiciels pour transformer ces données dans un format utilisable par les ingénieurs et les scientifiques.

Chaque nouvel instrument possède son propre langage dépendant de différents facteurs comme le protocole utilisé pour la communication ou la structure des données échangées. Cela signifie donc qu'il est nécessaire, pour chaque nouvel instrument, de réécrire de nouveaux logiciels à même d'interpréter les données échangées. Ce besoin est encore plus flagrant quand on considère que les mêmes données seront interprétées différemment selon les corps de métiers (là où un électronicien verra une tension au sortir d'un capteur, un scientifique lira une intensité lumineuse) et que leur format pourra évoluer dans le temps (le format peut changer pendant les phases de conception, d'intégration et même pendant l'utilisation de l'instrument en cas de modification volontaire de son fonctionnement).

Il devenait donc nécessaire de faciliter et d'accélérer le développement de ces logiciels.

Le projet PALISADE

Pour répondre à ce besoin, l'équipe Logiciel instrumentaux a développé un ensemble d'outils rassemblés dans le projet PALISADE (Parsing Library and Structural Description).

Ce projet est constitué de deux entités :

un langage de description,
une bibliothèque de composants logiciels.

L'idée est d'utiliser le langage pour décrire le format des données. Nous appellerons par la suite cette description une méta-définition. Les composants logiciels sont capables de récupérer cette méta-définition et de se structurer de manière à pouvoir interpréter correctement les données. Si une méta-définition différente est fournie, les composants se restructurent dynamiquement et s'adaptent au nouveau format. Par la suite nous utiliserons l'anglicisme parser pour désigner ces composants.

Les données binaires présentées au parser seront interprétées et rendues dans un format générique facilement utilisable par le programme de traitement (processus d'analyse), et des données fournies dans ce format générique seront interprétées pour obtenir un format binaire (processus de compilation).


PALISADE

Le langage de méta-définition

Ce méta langage a été entièrement défini via XML et XML Schema. Il fournit un ensemble de structures classiques (boucles, expressions conditionnelles, gestion de variables, utilisation de formules…) qui permettent de simplement décrire la structure des différents flux de données associés à l'instrument. La simplicité d'utilisation de XML, associée à l'expressivité du langage défini par PALISADE, permet d'écrire simplement une méta-définition, facile à comprendre et à modifier.

La bibliothèque de composants logiciels

La bibliothèque est construite autour d'un ensemble de composants coopérants que nous avons nommé parser, chargé des opérations d'analyse et de compilation. Outre ces composants, la bibliothèque fournit différents outils périphériques permettant, par exemple, de traiter en aval les données produites par le parser ou de gérer les différents fichiers de méta-définition.

La bibliothèque a été développée en C++ en utilisant les différents paradigmes de la programmation objet. Fortement modulaire, elle peut rapidement et simplement être enrichie.

Contact : Loïc Gueguen

Les SGSE de CoRoT

Philippe Plasson — 2009-01-27T09:17:33Z

Contexte et objectifs

Les SGSE (Software Ground Support Equipment) de CoRoT correspondent à un ensemble cohérent d'outils logiciels qui ont été utilisés pour mener à bien les activités de tests et de validation de l'unité de traitement numérique de l'instrument CoRoT (sous-système incluant le logiciel de vol du DPU - Digital Process Unit - et le logiciel de vol du Boîtier Extracteur de données). La polyvalence et la modularité de ces outils logiciels, qui ont été développés sur mesure pour le projet CoRoT, leur ont en fait permis d'être utilisés durant toutes les activités d'intégration, de tests et de validation de l'instrument et de ses sous-systèmes CorotCase et CorotCam.

Les SGSE de CoRoT ont été spécifiés, conçus et développés entièrement par le LESIA (excepté le composant critique pilotant le bus satellite MIL-STD-1553 dont la conception détaillée et le codage ont fait l'objet d'une sous-traitance industrielle). La durée totale du développement des SGSE de CoRoT a été de l'ordre de trois années et demie. Six ingénieurs informaticiens ont participé aux développements.

Les SGSE de CoRoT ont été utilisés intensément par plusieurs équipes les trois années durant lesquelles se sont déroulées les activités de tests de l'instrument et de ses sous-systèmes. Ils seront utilisés pendant toute la durée de la mission CoRoT (cinq ans) par le Centre de Mission de CoRoT (CNES) dans le cadre du banc instrument (modèle d'ingénierie de l'instrument permettant de valider, avant transmission au satellite, les télécommandes et les différents scénarios opérationnels) et par l'équipe Logiciels de vol à des fins d'expertise.

Les SGSE de CoRoT forment un système logiciel permettant à un utilisateur (équipe de validation des logiciels de vol, équipe AIT instrument, etc.) de piloter et surveiller à distance l'instrument dans sa totalité (cas des essais instrument) ou seulement un des sous-systèmes de l'instrument comme le DPU couplé à un simulateur du Boîtier Extracteur de données (cas de la validation des logiciels de vol). Ils permettent d'interagir en temps réel avec le système sous test en pilotant les différents EGSE, mais aussi de programmer des scénarios de test sous la forme de scripts de commandes envoyées à l'instrument via un simulateur de la plate-forme satellite Proteus. Les procédures de test et les scripts sont organisés en bibliothèques stockées dans un référentiel unique et centralisé. Les télémétries scientifiques et techniques (housekeepings ou encore HK) sont aussi stockées au sein d'une base unique gérée par un serveur de base de données. Les SGSE de CoRoT permettent de réaliser en temps réel ou de manière post-mortem, via un outil de traitement des télémétries, des analyses donnant lieu à des rapports d'essais.

Le module d'analyse des télémétries du logiciel de vol a été conçu pour pouvoir aussi être alimenté via le Centre de Mission de CoRoT. Il peut ainsi être utilisé à des fins d'expertise durant toute la mission par les ingénieurs du LESIA.

Architecture générale

Les SGSE de CoRoT ont été conçus comme un ensemble de composants client/serveur répartis sur un réseau ethernet et formant une architecture à base de composants, fortement modulaire, évolutive et reconfigurable, comme le montre la figure ci-dessous.


L'architecture des SGSE de CoRoT

Le choix d'une approche orientée composants a permis de fournir aux utilisateurs un produit modulable en fonction de leurs besoins et a permis aussi d'inscrire les développements dans une logique d'ingénierie simultanée, chaque développeur devenant responsable d'un ou plusieurs composants. L'objectif poursuivi était que les différents composants du système puissent être développés simultanément et puissent évoluer à des rythmes différents.

Tous les composants logiciels en interface avec la charge utile jouent le rôle de serveurs. Ils sont connectés à la charge utile via des cartes du commerce (carte PCI DDC 1553, cartes National Instruments) ou via des EGSE réalisés sur mesure par le LESIA. Ils peuvent être répartis sur plusieurs machines afin d'optimiser la charge CPU ou l'utilisation des ressources matérielles. Ils sont accessibles à travers un réseau Ethernet via des appels à des procédures distantes (RPC).

Le composant Script Interpreter and Command Dispatcher joue le rôle de chef d'orchestre du système. Ses tâches principales consistent à interpréter les scripts de test, à formater les commandes et à les transmettre aux différents serveurs pilotant le matériel. Il est connecté, à travers le réseau, au composant Script Editor and Test Driver qui est une application ayant une interface utilisateur élaborée permettant de préparer les tests et de piloter finement les essais.

Le composant TM Storer and Dispatcher est responsable de la bufferisation des télémetries transmises par la charge utile, de leur encapsulation basée sur l'utilisation de XML, de leur stockage dans un serveur de base données et de leur dispatchage en temps-réel vers le composant Monitoring and Analysis System.

Préparation et conduite des tests

La figure ci-dessous donne un aperçu de l'interface homme-machine (IHM) de l'application Script Editor and Test Driver.


L'outil d'édition des télécommandes et de conduite des tests

L'IHM de cet outil est avant tout constituée par un éditeur de scripts multifenêtres (2). Un script SGSE est une séquence de commandes qui peuvent être destinées directement aux équipements testés ou qui peuvent être des commandes de configuration des composants en charge du pilotage des EGSE. Le cadencement d'un script est défini à l'aide d'instructions de pause ou à l'aide de timetags. Un script peut appeler un script enfant, et ce sur plusieurs niveaux. Des structures itératives (boucles) peuvent être programmées afin de répéter un certain nombre de fois le même bloc de commandes. Une procédure de test peut être implémentée à l'aide d'un script ou de plusieurs scripts SGSE.

Plusieurs scripts peuvent être édités simultanément. L'édition des scripts se fait par glisser-déposer (drag and drop) des commandes de la zone de sélection des commandes (1) vers la fenêtre d'édition de script active (2). La zone de sélection des commandes (1) revêt la forme d'un arbre dans lequel les commandes sont organisées par catégorie et par type : on trouve ainsi, par exemple, sous le noeud DPU l'ensemble des 84 télécommandes à destination des DPU classées selon leur catégorie. L'édition des paramètres des commandes se fait à l'aide du panneau (3).

Les commandes pouvant être utilisées au sein d'un script SGSE, ainsi que leur structure (liste, nom et type des paramètres) sont définies dans des documents de méta-définition. Un langage de méta-définition basé sur XML a été conçu spécialement pour la description des données manipulées par les SGSE. L'éditeur de scripts utilise ces méta-données pour construire dynamiquement l'arbre des commandes et mettre à jour la zone d'édition des paramètres en fonction de la commande pointée dans le script par l'utilisateur. Des commandes peuvent être ajoutées au système ou modifiées sans avoir à recompiler l'ensemble de l'application.

L'outil dispose aussi d'un gestionnaire de projets (4) permettant de regrouper de façon logique des scripts apparentés. Plusieurs projets peuvent être ouverts simultanément. Le gestionnaire de projet permet aussi de définir et gérer les descripteurs d'essai dans lesquels sont enregistrés la configuration matérielle et logicielle du système sous test et du système de test lui-même. Pour des raisons de traçabilité et de qualité, ces descripteurs sont automatiquement attachés aux instances des tests.

Enfin, l'outil agrège différents modules permettant d'automatiser la production des scripts de chargement du code du logiciel de vol du DPU (plus de 8000 télécommandes), ainsi que la production des scripts de chargement des descripteurs des fenêtres de la voie astéro et de la voie exoplanètes de l'instrument (6000 descripteurs de fenêtres identifiant sur le CCD de la voie exoplanètes 6000 étoiles).

Monitoring et analyse des essais

L'application Monitoring and Analysis System constitue l'oeil du système. Elle permet de visualiser en temps réel les échanges avec le système sous test grâce à de nombreux synoptiques et historiques. Elle permet aussi d'accéder aux données stockées dans la base de données une fois l'essai terminé et de produire de façon semi-automatique des analyses post mortem.


L'outil de monitoring et d'analyse

Principales fonctionnalités

L'application Monitoring and Analysis System gère plusieurs fichiers journaux dont le fichier journal traçant les échanges TC/TM (1), le fichier journal des événements DPU élaboré à partir des paquets TM techniques (2) et le fichier journal reprenant les informations transmises par le Boîtier Extracteur de données via ses paquets HK.

L'utilisateur peut interagir avec ces fichiers journaux directement à travers l'IHM de l'application (arrêt du défilement, retour en arrière, rejeu post mortem avec mise à jour des synoptiques, etc.), mais il peut aussi exporter ces fichiers journaux sous la forme de fichiers Excel, ce qui permet de profiter des fonctionnalités offertes par cet outil.

Chaque paquet (TC, TM, HK, etc.) tracé dans un fichier journal peut être visualisé individuellement à l'aide d'un outil donnant accès au contenu brut du paquet et à son arbre de décommutation (voir ci-dessous un exemple). L'affichage de ces fichiers journaux est par ailleurs entièrement configurable à l'aide de filtres construits à partir d'une vue représentant les données sous une forme arborescente comme le montre la figure ci-dessous.


Boîte de décommutation et boîte de configuration des filtres

A côté de ces fichiers journaux, l'application Monitoring and Analysis System offre des panneaux de contrôle permettant de visualiser l'état des différents équipements comme l'état des DPU (3), des Boîtiers Extracteur de données (4), des Boîtiers de Contrôle de la Caméra et des Boîtiers de Servitude. D'autres panneaux de contrôle permettent de visualiser l'état des différents composants du système SGSE lui-même.

Les mesures de tensions, de températures et de courants transmises dans les HK de l'instrument sont visualisables sous la forme de tableaux ou de courbes dont le contenu est configurable par l'utilisateur (voir la figure ci-dessous). La surveillance des différents capteurs de l'instrument est entièrement automatisable et configurable (détection selon des plages de surveillance avec gestion d'alarmes selon différents niveaux de criticité).


Outil de suivi des capteurs instrument

La décommutation des paquets de données qui alimentent les différentes vues de l'application Monitoring and Analysis System est réalisée par un parser configuré à l'aide de méta-données décrites en XML (via le langage de méta-définition qui est aussi utilisé pour la description des TC). Ce parser est donc entièrement reconfigurable sans avoir à recompiler l'application (lire cet article pour plus de détails sur la technologie utilisée).

Toutes les fonctions de l'application Monitoring and Analysis System sont accessibles en ligne, c'est-à-dire durant un essai, ou hors ligne, c'est-à-dire une fois l'essai joué et les données stockées dans la base de données SGSE.

Identifiables par leur nom et leur date d'exécution, les essais stockés dans la base de données SGSE sont accessibles à travers un navigateur dédié offrant des fonctionnalités de tri et de filtrage.

Les outils d'analyse

L'application Monitoring and Analysis System propose un ensemble d'outils destinés à l'analyse des données produites par l'instrument. Les données analysées peuvent être des données techniques ou des données issues de la télémétrie scientifique. On peut citer par exemple l'outil d'audit de la mémoire DPU, outil qui permet de comparer automatiquement le contenu d'une zone mémoire DPU avec ce qui a été réellement chargé dans les TC (voir figure ci-dessous).


Outil de comparaison mémoire

En ce qui concerne l'exploitation des données scientifiques, le Moniteur/Analyseur propose un outil (voir la figure ci-dessous) permettant de reconstruire les images plein cadre CCD ou les fenêtres acquises avec l'instrument afin de les visualiser, de les exporter dans des fichiers au format FITS ou encore de les comparer avec les images ou fenêtres injectées en entrée des simulateurs (simulateur du Boîtier Extracteur de Données, simulateur du Boîtier de Contrôle Caméra ou simulateur Vidéo).


Outil de visualisation/comparaison des images

Parallèlement à cet outil de visualisation et de comparaison d'images, un outil de suivi photométrique a spécialement été développé pour les essais EMC (Electromagnetic Compatibility). Cet outil a pour fonction de construire en temps réel une courbe photométrique à partir des fenêtres CCD transmises par l'instrument, courbe permettant de visualiser et d'évaluer l'influence des perturbateurs électromagnétiques injectés dans le système (voir figure ci-dessous).


Outil de suivi photométrique temps-réel

L'application Monitoring and Analysis System dispose aussi d'un outil permettant d'exporter sous la forme de courbes stockées dans des fichiers FITS compatibles avec les outils de l'équipe scientifique l'ensemble des paquets TM scientifiques correspondant à un essai. Ces données sont exploitées par l'équipe scientifique ainsi que par l'équipe de validation du logiciel de vol. L'outil permet aussi de comparer automatiquement les données en sortie du DPU avec les données produites en sortie du modèle du logiciel de vol (outil utilisé dans le cadre de l'activité de validation des algorithmes scientifiques).

Traitement par lots

Tous les outils d'analyse de l'application Monitoring and Analysis System ont été développés sous la forme de plugins. Ces différents plugins ont été réutilisés pour développer un outil de traitement par lots permettant d'analyser automatiquement un grand nombre d'essais et de réaliser les tests de non régression des logiciels de vol. Cet outil produit un rapport de synthèse sous la forme d'un classeur excel.

Interfaçage avec le système sous test

Simulation de la plate-forme Proteus

Les SGSE de CoRoT sont connectés à la charge utile grâce à 3 composants logiciels qui simulent la plate-forme satellite Proteus et jouent le rôle de serveurs pour le reste du système.

Le premier composant pilote une carte PCI DDC BU-65549. Il gère la communication sur le bus MIL-STD-1553 et prend en charge la transmission des TC à destination du DPU et la réception des TM produites par le DPU.

Le deuxième composant gère tous les liens spécifiques à la plate-forme Proteus à travers un EGSE réalisé sur mesure par le LESIA (l'EGSE LEVTEAU).

Le troisième composant pilote un rack PXI de chez National Instruments et a pour tâche de réaliser l'acquisition des données transmises par les 128 capteurs de tensions et de température embarqués dans la charge utile.

Simulation du Boîtier Extracteur de données de l'unité de traitement numérique

Le simulateur du Boîtier Extracteur de données est utilisé dans le cadre de la validation du logiciel de vol DPU et plus particulièrement dans le cadre de la validation des algorithmes scientifiques vis-à-vis du modèle instrument car il permet d'envoyer en entrée du DPU, via des liens SpaceWire, des séquences d'images dont le contenu varie dans le temps en fonction d'une simulation donnée de l'environnement (images plus ou moins bruitées, étoiles à flux variable, etc.).

Le simulateur du Boîtier Extracteur de données a été conçu comme un simulateur universel de liens SpaceWire et peut très facilement être réutilisé dans un autre contexte.

Contact : Philippe Plasson

Logiciels de test et d'intégration

Philippe Plasson — 2008-09-29T19:45:07Z

Présentation générale

Contexte

Dans le cadre des projets spatiaux aussi bien que dans celui des projets sol, les phases de test, de validation et d'intégration des instruments sont des phases cruciales qui nécessitent le développement, parallèlement à celui des instruments eux-mêmes, d'équipements de test (appelés EGSE pour Electrical Ground Support Equipment) et de systèmes logiciels permettant de préparer, conduire et automatiser les tests (appelés SGSE pour Software Ground Support Equipment).

Le LESIA dispose d'une longue expérience dans le domaine de la conception et du développement des logiciels de test et d'intégration. Les techniques employées pour le développement de ces systèmes varient en fonction des besoins des équipes instrumentales et de la nature des projets : certains instruments sont pilotés et testés à travers des applications développées en LabView, d'autres nécessitent des systèmes de test complexes dont le développement fait appel à des techniques de programmation avancées basées sur l'emploi de langages objets comme C++ ou Java (voir les SGSE de CoRoT).

Hétérogénéité et volatilité des besoins

Les logiciels de test et d'intégration sont développés en prenant en compte la grande diversité des utilisateurs. Ces derniers, en fonction de leur métier, ont des cultures différentes et des besoins hétérogènes : les besoins des spécialistes des détecteurs ne sont pas forcément les mêmes que ceux des électroniciens ou que ceux des ingénieurs responsables de la validation des logiciels embarqués.

Par ailleurs, les plannings des projets instrumentaux sont toujours extrêmement tendus et les besoins parfois volatils. Il est donc nécessaire, pour les équipes en charge du développement des logiciels de test, de faire preuve d'une grande réactivité, et surtout, de hiérarchiser les besoins en fixant les priorités grâce à un dialogue étroit avec l'ensemble des utilisateurs.

Les développements génériques

Malgré la grande diversité des projets instrumentaux, il est possible d'identifier un certain nombre d'outils dont le besoin est récurrent. C'est pourquoi, à côté des développements spécifiques, Le LESIA développe des composants logiciels génériques pouvant être utilisés pour produire plus rapidement et avec une qualité accrue des logiciels de test et d'intégration.

Par exemple, le projet PALISADE offre une solution sur étagère pour la description et l'interprétation des données échangées avec n'importe quel type d'instrument.

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