n°17
Juillet
2011
LSST - La suite

L’IN2P3 contribue à la conception et au développement de la caméra du télescope LSST. Lors de la derniere lettre, un premier article a présenté le projet LSST. Dans cet article, nous détaillerons les points forts du cahier des charges du CCS, décrirons l’architecture générale, et expliquerons les motivations de la collaboration LSST dans son choix de développer un logiciel spécifique en Java.

Le projet de logiciel de contrôle commande de la caméra, le CCS, 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.

Ce que ne fait pas le CCS

Le CCS ne fait pas d’acquisition de données mais 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

Du fait que nous ne faisons pas d’acquisition de données, nous n’avons pas de contraintes « temps réel », 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 requise impose d’une part une grande qualité dans l’écriture du code et de la documentation, 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.

Description générale du fonctionnement du CCS

Le cœur du CCS repose sur trois bus de communication (Command, Status et Log). Ces trois bus relient entre eux les sous-systèmes au-dessus d’un réseau TCP/IP sur Ethernet.

Command bus

Le bus de commandes permet d’acheminer les commandes à chaque sous-système, et les accusés de réception de ces commandes.

Status bus

Chaque sous-système publie à intervalle régulier les données décrivant son état (position, température, pression, type du filtre en ligne) sur le bus de status. Au démarrage, il publie aussi ses données de configuration. Les données qui circulent sur le bus de status sont ensuite consolidées dans une base de données locale puis transmises à l’observatoire.

Log bus

Le bus de log recueille toutes les données jugées utiles pour chaque sous-système à des fins de détection d’erreur et de diagnostic. Ces données sont conservées dans une base de données locale et permettent une analyse plus fine du comportement de la caméra, principalement pendant les phases de maintenance et de construction.

En mode opératoire normal, automatique, des ordres de haut niveau, s’adressant à la caméra vue dans son ensemble, viennent du logiciel de contrôle du télescope, OCS (Observatory Control System). Ces ordres de haut niveau sont transformés par le cœur du CCS en une séquence de commandes dont chacune s’adresse plus particulièrement à un sous-système de la caméra. Par exemple, l’ordre : « Take a single science exposure of 15 seconds with filter g » se traduit par une série de commandes adressées :

  • au FCS : « move filter g online »,
  • au DAQ (Data Acquisition system) : « clear CCD »
  • à l’obturateur : « open shutter 15s »,
  • puis, « close shutter »
  • au système d’acquisition de données : « read out CCD »
  • etc...

En mode de maintenance, des commandes peuvent être adressées à chaque sous-système par l’intermédiaire d’une console. Ces consoles peuvent être locales ou distantes. Pour garantir la sécurité des personnes et du matériel, un système de verrou est implémenté afin que ces commandes ne puissent venir que d’une seule console à la fois. Le CCS est conçu comme un canevas permettant aux développeurs Java des sous-systèmes de se concentrer sur leur développement spécifique. Ainsi les principales fonctions prises en charge par le cœur du CCS sont les suivantes :

  • communication sur les trois bus,
  • sauvegarde automatique dans les bases de données,
  • description de la configuration du sous-système en XML.

Cependant, un développeur de sous-système peut utiliser le langage de son choix. L’équipe de développement du cœur lui offrira du support pour écrire une interface communiquant avec les trois bus du CCS. Cette pratique n’est pas recommandée car elle rend les opérations de maintenance du code plus complexes.

Nos choix technologiques et les raisons de ces choix

Dès la conception du logiciel, nous avons choisi d’utiliser des briques de logiciel libre chaque fois que c’était possible. Pour rendre notre logiciel indépendant de ces briques, nous avons écrit une interface au sens Java du terme afin de n’avoir à réécrire que cette interface en cas de changement.

Ainsi :

  • la communication autour des trois bus est réalisée par Java Message Service ;
  • la population des bases de données est réalisée avec Hibernate ;
  • la description de la configuration des sous-systèmes est réalisée avec Spring ;
  • la réalisation de contraintes entre des éléments des sous-systèmes (par exemple le verrou A ne peut être ouvert que si le verrou B est fermé) peut-être réalisée avec AspectJ, un outil Aspect Oriented Programming.

Pourquoi développer un logiciel spécifique et ne pas utiliser des outils commerciaux disponibles sur étagère (COTS ou SCADA) ?

Nous avons envisagé PVSS et EPICS et étudié les expériences heureuses ou malheureuses de ces logiciels pour différents télescopes. Or dans l’équipe du SLAC avec laquelle travaillons sur ce projet, les expériences malheureuses avec EPICS sont plus fréquentes que les heureuses.

Nos conclusions sont les suivantes :

  • la courbe de prise en main de ces logiciels est souvent exponentielle : pour faire des choses basiques tout va bien, mais dès que c’est plus complexe, la difficulté augmente très vite ;
  • ces logiciels ont souvent une documentation insuffisante ;
  • cela peut être très ardu de coder des fonctionnalités qui n’ont pas été prévues par le concepteur du logiciel ;
  • adapter ces logiciels à nos besoins requiert souvent l’écriture de beaucoup de code de haut et de bas niveau ;
  • il y a une incertitude sur la durée de vie de ces logiciels, or c’est une contrante forte de notre projet de produire un logiciel avec une très longue durée de vie.

Pourquoi JAVA ?

  • de plus en plus de logiciels sont codés en Java dans tous les domaines, de l’industrie aux télécommunications en passant par la finance, sa longévité ne fait pas de doute ;
  • Java est facile à débugguer ;
  • les performances des codes écrits en JAVA n’ont plus rien à envier à ceux écrits en C++ ou même en C ;
  • le nombre et la richesse des librairies disponibles en Java sont énormes, en particulier pour la communication, ce qui fait que réécrire les fonctionnalités d’EPICS n’est pas un gros travail ;
  • communiquer avec les pilotes du matériel est facilité par JNI et cela a été démontré par la réalisation du tout premier prototype ;
  • nous avions une bonne compétence de JAVA dans l’équipe ;
  • nous avions la possibilité de réutiliser le code écrit par le SLAC pour le projet Fermi, autour de JAS pour la réalisation des consoles et écrans de contrôle et l’analyse des données télémétriques (affichage de courbes)

Description détaillée du logiciel

Le cœur du système : un canevas pour construire les sous-systèmes

Le cœur du CCS fournit des classes Java permettant de construire rapidement un sous-système sous la forme d’un système modulaire assemblant des modules réutilisables. L’assemblage des modules est réalisé par Spring Framework et décrite par XML. Chaque module communique avec les trois bus pour recevoir des commandes ou publier son status. Les modules s’observent les uns les autres (pattern Observer). Parmi ces modules l’un deux, le « main Module », joue le rôle de façade (pattern Façade) pour le sous-système. En mode normal, seul ce module principal reçoit des commandes venant du CCS. En mode maintenance tous les modules peuvent recevoir des commandes individuellement depuis une console.

Un des modules joue le rôle d’interface avec le matériel, soit directement avec les librairies d’entrée-sortie de Java (Java IO), soit par JNI si le pilote est écrit en C ou un autre langage.

Exemple d’un sous-système : le contrôle commande de l’échangeur de filtre.

Le FCS est construit avec le framework. Il est composé de quatre principaux modules : le « main » et trois modules gérant les différents composants mécaniques de l’échangeur de filtres :

  • le « carrousel »,
  • l’ « autochanger »
  • le « loader »

Chacun de ces modules peut fonctionner indépendamment des autres sur leur banc de test respectif ou lorsqu’on passe en mode maintenance. La communication avec les moteurs et les capteurs est régie selon le protocole CANopen au-dessus d’un bus CAN via un contrôleur. Le choix de CANopen a été fait par l’équipe de mécaniciens, et nous l’avons validé. En effet, le choix d’un protocole largement répandu dans le milieu industriel ouvre un large éventail de fournisseurs. Dans le FCS le protocole CANopen est modélisé par une interface Java, ainsi il suffit de changer la classe implémentant le contrôleur en cas de changement.

Où nous en sommes (notre plan de développement)

Actuellement dans une phase de conception, nous avons développé plusieurs prototypes dont un prototype de FCS avec un simulateur du matériel. Le logiciel de contrôleur de l’obturateur, pour lequel un prototype mécanique existe depuis longtemps, fonctionne déjà dans une version simplifiée, adaptée au prototype. Ainsi l’ensemble de la chaîne de commandement depuis les ordres de haut niveau jusqu’aux ordres de bas niveau pour commander le moteur est validé.

Parallèlement aux développements du cœur du logiciel, nous adaptons le prototype du FCS pour un banc de test de la mécanique qui sera installé au CPPM début 2012. Au cours de l’année 2012, nous disposerons d’un banc de test à l’échelle un du système d’échangeur de filtres. Ces tests permettront de valider la mécanique et le contrôle.

Conclusion

Le télescope LSST devrait voir sa première lumière en 2019 et sa caméra doit être assemblée durant l’année 2017 et testé au Slac en Californie, puis au Chili au cours de l’année 2018. D’ici là, des choix différents peuvent être faits par les différentes équipes techniques construisant la caméra. Notre pari est qu’avec notre logiciel maison écrit en Java, réutilisant beaucoup de pièces de logiciel libre sans jamais y être liés, nous réussirons à nous adapter rapidement aux changements. C’est autant de temps gagné pour la documentation et le « refactoring » permanent du code pour produire un code de qualité. Verdict en 2019 !

Éric AUBOURG, Françoise VIRIEUX

Grand instrument

LSST - La suite

Controle/commande

Institut Laue-Langevin
Rechercher
     

Responsables éditoriaux : Dominique Boutigny et Cristinel Diaconu
Comité de rédaction : Dominique Cathala, Virginie Dutruel, Sébastien Grégoire, Eric Legay, et Gaëlle Shifrin

logo CCIN2P3
© CCIN2P3