• Aucun résultat trouvé

Calculateur ` a bord l’UGTS et logiciel des algorithmes de d´etection

2.4 M´ethodes de d´etection et localisation

2.4.6 Calculateur ` a bord l’UGTS et logiciel des algorithmes de d´etection

Dans cette section est pr´esent´ee l’architecture mat´erielle du syst`eme de d´etection et de lo- calisation. Les algorithmes ont ´et´e cod´es et test´es scientifiquement sur des machines utilisant le syst`eme d’exploitation Linux (Schanne et al., 2014). C’est cette version que j’ai utilis´ee du- rant ma th`ese pour ´evaluer les performances de d´etection. Le mˆeme code des algorithmes peut ´egalement ˆetre compil´e sur le processeur cibl´e pour le syst`eme de vol. Pour ´evaluer les perfor- mances de calcul de ces algorithmes sur ces cibles, en particulier le taux d’occupation de ces processeurs en terme de puissance de calcul, l’´equipe du CEA `a Saclay a r´ealis´e un prototype de l’UGTS.

Calculateur `a bord

Premi`ere architecture : UTS. Jusqu’au d´ebut 2015, l’´equipe du CEA Saclay ´etait en charge du d´eveloppement et de la r´ealisation d’un boˆıtier d’ECLAIRs appel´e UTS (Unit´e de Traitement Scientifique). Les fonctions de l’UTS se d´eclinaient de la sorte :

— acquisition des donn´ees depuis les d´etecteurs d’ECLAIRs et leur mise en paquet pour ensuite les envoyer vers la m´emoire de masse, via un boitier appel´e FCU (French Control Unit) et sous responsabilit´e du CNES.

— traitements scientifiques (trigger image et taux de comptage). S’il trouvait et localisait une nouvelle source transitoires sur le ciel, l’UTS demanderait le repointage du satellite et cr´eerait la s´equence de message d’alertes via le boitier FCU.

— surveillance du bon fonctionnement des fonctions d’acquisition et des fonctions de trai- tement scientifique. Les fonctions de configuration et de contrˆole du fonctionnement des d´etecteurs ´etaient assur´ees par un boitier s´epar´e appel´e UGD (Unit´e de Gestion des D´etecteurs), dont l’IRAP `a Toulouse avait la responsabilit´e.

Figure 2.15 – Sch´ema de l’ancienne architecture ´electrique d’ECLAIRs (jusqu’en 2014), em- ployant 3 boˆıtiers distincts : l’UGD pour la gestion des d´etecteurs, le FCU pour le dialogue avec la partie chinoise et l’UTS pour le trigger et l’acquisition des donn´ees. Ce sch´ema d´etaille aussi l’architecture mat´erielle interne de l’UTS (Schanne & Le Provost, 2010).

Un premier mod`ele du mat´eriel de l’UTS, d´enomm´e DPM (Data Processing Model ), utilisait un FPGA commercial Field Programmable Gate Array) de la marque am´ericaine Xilinx et un CPU de type Leon2 (pouvant quant `a lui ˆetre embarqu´e `a bord du satellite). Les deux composants ´etaient int´egr´es sur des cartes ´electroniques reli´ees entre elles par un bus PCI. Sur le FPGA du DPM, avait ´et´e d´evelopp´e un firmware, impl´ementant une grande partie des fonctionnalit´es de pr´e-traitement des donn´ees de la cam´era, requises pour les traitements scientifiques. L’´equipe UGTS avait aussi transpos´e les traitements scientifiques (trigger taux de comptage et trigger image) sur le CPU Leon2 en utilisant le mˆeme code scientifique que celui qui avait ´et´e test´e sur une machine dˆot´ee du syst`eme d’exploitation Linux.

Un second mod`ele du mat´erial de l’UTS a ´et´e r´ealis´e `a partir de 2012. D´enomm´e UTS-ML pourMod`ele de Laboratoire(derni`ere version de l’UTS avant celle de qualification et de vol,

voir figure 2.4), il se composait d’une carte ´equip´ee de deux FPGAs cibl´es pour le vol (Atmel ATF280, op´er´e `a 20 MHz), et d’une carte CPU ´equip´ee du Leon2 d’Atmel, op´erant `a 100 MHz et d´elivrant une puissance de calcul de 23 Mflops (million d’op´erations flottantes par seconde).

Architecture actuelle : UGTS. A partir de 2013, suite au nouvel accord franco-chinois sur` SVOM, la maˆıtrise d’œuvre d’ECLAIRs a ´et´e reprise par le CNES (voir section 1.3.1). Une r´eorganisation de l’instrument s’est op´er´ee dans le but d’une simplification du syst`eme. Elle permet ´egalement une r´eduction des coˆuts. Les trois boitiers UGD, FCU et UTS ont ´et´e re- group´es en un boˆıtier unique, l’UGTS, sous maˆıtrise d’œuvre du CNES. La r´ealisation de la partie mat´erielle de l’UGTS est sous-trait´ee par le CNES `a la soci´et´e EREMS pr`es de Toulouse. Le CEA Saclay a la responsabilit´e de la conception et de la r´ealisation du logiciel de vol com- plet impl´ement´e dans ce mat´eriel. Il r´ealise aussi le banc de test fonctionnel et contribue aux campagnes de validation de l’UGTS.

L’UGTS emploie une nouvelle version de processeur, appel´ee Leon3, entre temps devenue disponible, dot´ee de 2 cœurs de calcul et d´elivrant chacun 53 Mflots de puissance de calcul, ce qui permet de d´egager des marges pour les traitements scientifiques.

La figure 2.16 repr´esente la nouvelle architecture mat´erielle de l’UGTS telle qu’elle sera r´ealis´ee par EREMS. Outre les alimentations du plan d´etecteur DPIX et de l’UGTS lui-mˆeme (non repr´esent´ees sur cette figure), le boˆıtier UGTS comporte une carte d’interface I/O (pour Input/Output) ´equip´ee d’un FPGA ATF280 d’Atmel, et une carte CPU ´equip´ee du processeur Leon3 et d’un autre FPGA ATF280 d´edi´e aux pr´e-traitements scientifiques. Le logiciel de vol du CEA comporte le software du Leon3 et le firmware du FPGA de la carte CPU.

Les nouvelles fonctions de l’UGTS comportent :

— l’acquisition des donn´ees d’ECLAIRs et leur mise en paquets, leur m´emorisation tempo- raire avant envoi direct `a la m´emoire de masse.

— la configuration et la surveillance de la cam´era d’ECLAIRs, y compris le contrˆole ther- mique et la gestion de pixels qui doivent ˆetre coup´es en vol s’ils deviennent trop bruyants. — les traitements scientifiques.

— la d´etection et la r´ecup´eration autonome de d´efaillances du syst`eme. — la surveillance du bon fonctionnement d’ECLAIRs.

Figure 2.16 – Architecture ´electrique de l’UGTS d’ECLAIRs,(Schanne et al., 2016)

Logiciel de simulation

Les algorithmes de d´etection ont ´et´e impl´ement´es en C++, sous forme d’un logiciel compilable `

a la fois sur processeur Intel sous le syst`eme d’op´eration Linux et sur processeur Leon sous Rtems. Sous Linux, les trigger image et taux de comptage sont ainsi disponibles sous forme de deux programmes ex´ecutables disjoints.

Le simulateur CxgSim (employant la librairie Root), permet `a partir d’une liste de photons d’une source et du bruit de fond, de g´en´erer une liste de coups tels qu’ils seraient d´etect´es par le d´etecteurs d’ECLAIRs (pour chaque ´ev´enement : son temps, le pixel touch´e et l’´energie d´etect´ee). Les listes d’´ev´enements r´esultants (appel´es fichiers  evbin ) peuvent ensuite ˆetre inject´ees

photons , un mod`ele ´electronique qui permet de placer en entr´ee de l’UGTS en temps r´eel

chaque ´ev´enement `a son temps. Dans le DPM, ces ´ev´enements sont d’abord pr´e-trait´es par le FPGA, puis par le logiciel du trigger sur le processeur Leon.

Les mˆemes listes d’´ev´enements peuvent aussi ˆetre trait´e sur station Linux par les programmes ex´ecutables du trigger image et trigger taux de comptage, qui lisent dans ces fichiers ´ev´enement par ´ev´enement pour y appliquer les traitements scientifiques. Le syst`eme de g´en´eration des messages d’alertes n’est pas encore impl´ement´e. Les r´esultats des triggers sont enregistr´es sous forme de fichier texte, et exploit´es par mes analyses.