n°16
Mai
2011
L’IN2P3 participe au défi scientifique du LSST

L’IN2P3 contribue à la conception et au développement de la caméra du télescope LSST. En particulier, l’IN2P3 est responsable du logiciel de contrôle commande de la caméra, le CCS. Ce premier article présente le projet LSST, puis dans la prochaine édition de la Lettre IN2P3, un article donnera les points forts du cahier des charges du CCS, décrira l’architecture générale, et expliquera les motivations de la collaboration LSST dans son choix de développer un logiciel spécifique en Java.

Le Télescope LSST, Large Synoptic Survey Telescope, (http://lsst.in2p3.fr) sera installé au Cerro Pachón, près de La Serena au Chili, en 2018. Il est actuellement en cours de conception aux États-Unis et en France. Ce télescope, de très large ouverture (10 degrés carrés) intègre une caméra CCD de 3,2 Gpixels et un miroir principal de 8,4 m de diamètre. Il photographiera les objets célestes de faible luminosité dans six longueurs d’onde dans le domaine du visible. Il effectuera un balayage systématique du ciel en trois nuits à raison de deux poses de 15 secondes pour chaque parcelle du ciel. Il recueillera ainsi 15 To de données par nuit, un volume de même grandeur que celui du LHC.

Un des enjeux scientifiques de ce télescope pour l’IN2P3, outre la cartographie des galaxies, est de caractériser l’équation d’état de l’énergie noire.

Ce projet est un projet international de financement public-privé. Les fonds publics américains viennent de la NSF et la DOE et en France, il est financé par le CNRS via l’IN2P3.

C’est un très grand instrument du CNRS et le « Committee for a Decadal Survey of Astronomy » aux États-Unis l’a classé en premier sur la liste des projets prioritaires au sol pour les dix prochaines années.

Les responsabilités de l’IN2P3 dans la caméra de LSST

Le projet est piloté par la LSST Corporation (http://www.lsst.org). Il est divisé en trois sous-projets : Telescope, Camera, Data Management. Un MOU entre la LSST Corporation et l’IN2P3 a été signé en octobre 2009. Les équipes techniques de l’IN2P3 sont impliquées dans le sous-projet Camera. Sept laboratoires contribuent actuellement à LSST : l’APC, le CC, le LAL, le LMA, le LPNHE, le LPSC et le CPPM.

Le responsable scientifique est Pierre Antilogus, du LPNHE et le responsable technique est Christophe Vescovi du LPSC. Notre contribution couvre les trois domaines de la mécanique, l’électronique et l’informatique.

La mécanique

L’IN2P3 est responsable de la conception et du développement du système d’échangeur de filtres de la caméra.

Puisque la collaboration a besoin d’images dans six bandes photométriques, la caméra est équipée de six filtres. Cinq d’entre eux pourront loger autour de la caméra, suspendus à un carrousel qui tourne autour de la caméra. Un sixième filtre sera en réserve dans un changeur manuel et pourra être introduit dans la caméra à la demande. Un système mécanique appelé « auto-changeur » permettra de venir saisir un filtre sur le carrousel pour venir le mettre devant l’objectif.

L’électronique

En électronique, l’IN2P3 est impliqué du développement de l’électronique front-end des CCD jusqu’au banc de caractérisation de la caméra CCD.

L’informatique (contrôle commande)

En informatique, l’IN2P3 a en charge la conception et le développement du logiciel de contrôle commande de la caméra (CCS : Camera Control System) et de l’échangeur de filtres (FCS : Filter exChanger System).

Le logiciel de contrôle commande de la caméra : le CCS

Le projet Camera est subdivisé en une quinzaine de sous-systèmes tels que :

  • l’échangeur de filtres ;
  • l’obturateur ;
  • la gestion du froid ;
  • la gestion du vide ;
  • la gestion de la température ;
  • la gestion de la puissance électrique ;
  • l’acquisition de données.

Le CCS a pour objectif de contrôler et coordonner les actions des différents sous-systèmes de la caméra. Le CCS est l’interface entre le logiciel de contrôle du télescope, le TCS, et les sous-systèmes de la caméra. Il doit fournir aux utilisateurs de la caméra et du télescope tous les outils informatiques permettant de contrôler, commander et configurer la caméra. Cela implique des consoles, des bases de données télémétriques et de la configuration.

Le CCS doit gérer différents modes opératoires :

  • mode normal ou automatique lorsque la prise de données se fait de manière automatique pendant le balayage du ciel lorsqu’il n’y a pas d’incidents,
  • mode engineering (maintenance) lors de la construction de la caméra ou lors des opérations de maintenance de la caméra,
  • mode emergency, lorsqu’un incident majeur intervient (panne de courant électrique ou tremblement de terre imminent) Il s’agit alors de mettre le matériel dans un état où le risque de dommages est le plus faible.

Le CCS n’est pas un système d’acquisition de données, il est l’interface entre le logiciel d’acquisition de données et le logiciel de contrôle du télescope. Ainsi le CCS ne gère pas le grand flux de données générées par les prises d’images.

Les contraintes d’environnement

Du fait que ce logiciel ne gère pas le flot de données, il n’y a pas de contraintes « temps réel dur », mais plutôt de « slow control ». La contrainte la plus importante est la durée de vie du logiciel. En effet, depuis les premières études en 2006 et la fin d’exploitation du télescope autour de 2030, il se sera écoulé bien plus de quinze ans. Il est vraisemblable que les personnes qui auront à maintenir ce logiciel ne seront pas les mêmes que ceux qui le développent. Cette longue durée de vie impose d’une part une grande qualité dans l’écriture de la documentation technique et utilisateur et du code, d’autre part de concevoir le logiciel de manière à le rendre indépendant des briques de logiciel libre que nous utilisons pour le construire.

La fréquence d’estampillage des événements internes de la caméra doit être réalisée avec une précision relative (temps entre deux événements) d’une milliseconde et une précision absolue (temps par rapport au temps externe) de dix millisecondes. L’observatoire fournit le référentiel de temps et le CCS est chargé de distribuer ce temps à tous les sous-systèmes. Le CCS doit être capable de fonctionner lors de la construction ou les opérations de maintenance sur les bancs de test de la mécanique ou de l’électronique lorsque nous ne disposons que d’un environnement minimal. Il doit pouvoir tourner sur une machine fonctionnant sous unix, de type PC104.

Rendez-vous dans la prochaine lettre informatique pour une description du CCS et des choix techniques effectués.

Éric AUBOURG, Françoise VIRIEUX