n°16
Mai
2011
Un système d’acquisition pour Spiral2

Les détecteurs autour de SPIRAL2, le nouvel accélérateur en construction au GANIL, sont à différent stades de conception, certains à l’étape de projet, d’autres au stade de démonstrateur (ex. : AGATA). Au sein du comité de coordination pour l’instrumentation de SPIRAL2, un groupe de travail, composé de membres de chacune des collaborations et de représentants du GANIL, a été chargé de considérer les problèmes liés à l’acquisition de données, de recommander des solutions et, si besoin, de définir des standards pour le développement des logiciels d’acquisition de ces instruments. Cet article résume les premières recommandations de ce groupe de travail. Un rapport complet est en cours d’écriture.

Définition de la problématique

La problématique est d’intégrer dans le système d’acquisition de GANIL-SPIRAL2 ces ensembles de détection de plusieurs milliers de voies chacun, construits dans différents laboratoires, destinés pour certains uniquement à SPIRAL2, mais pour d’autres appelés à voyager auprès de différents accélérateurs. Ces instruments complexes doivent pouvoir être couplés afin de constituer un super instrument. Les recommandations doivent donc permettre une grande modularité et simplifier l’association de ces instruments tant du point de vue commande et contrôle que du point de vue des flux de données.

Le système proposé est basé sur une architecture client serveur avec pour principales composantes :

  1. le contrôle de l’électronique (Electronics Control),
  2. le flux de données assurant le transport et le traitement des données des modules électroniques jusqu’au stockage
  3. le contrôle de l’ensemble du système (Global Run Control) pendant les expériences.

L’ « Electronics Control » est une application en charge du contrôle complet du matériel. C’est une application client/serveur qui communique d’une part avec les différentes cartes électronique et d’autre part avec des clients tels qu’une interface homme-machine ou le « Global Run Control ».

Le flux de données est construit à partir du système NARVAL, développé à l’origine par X. Grave (IPN Orsay). Ce système assure le transport de données entre différents acteurs pouvant être répartis sur différentes machines, par simple description d’une topologie par un fichier XML. Son concept modulaire permet d’intégrer facilement dans le flux de données les acteurs nécessaires au filtrage et à la reconstruction des événements. L’analyse en ligne se fait entre autre via un process externe client d’un des acteurs. Le GANIL propose de réaliser ces programmes d’analyse, spécifiques à chaque expérience, avec GRU (GANIL ROOT Utilities) et Vigru (Visualisation GRU), des outils largement basés sur ROOT.

Le « Global Run Control » (GRCC), basé sur les mêmes paradigmes client/serveur, est associé à une interface graphique cliente, et est le poste de pilotage de l’expérience. Il coordonne les différentes activités nécessaires pour mettre le système en état de fonctionnement. Il interagit avec le ou les process « Electronics Control » pour initialiser l’électronique avant la prise de données. Il fournit également les outils de contrôle, de report d’alarmes et de journalisation pour l’ensemble du système. Il a été conçu pour être évolutif et pour contrôler les systèmes des différents instruments construits par les collaborations. Pour cette raison, il est construit autour du concept de gestionnaire d’instruments.

Les échanges de commandes entre GRCC et les applications de contrôle de l’électronique, se font par l’intermédiaire de services WEB utilisant le protocole SOAP. La journalisation des messages et la propagation des alarmes se fait via log4Cxx initialement développé en Java, disponible pour différents langages (Java, C++, ADA,…).

Recommandations

Un certain nombre de recommandations ont été définies par le groupe de travail, afin de faciliter l’intégration des équipements dans le système d’acquisition de GANIL-SPIRAL2. On peut citer en particulier les points suivants :

  • Pour pouvoir être contrôlées par le « Global Run Control », les applications d’ « Electronics Control » devront répondre à un lot minimum de commandes SOAP et respecter une machine d’état décrits dans un document de référence. Les mécanismes log4Cxx devront être utilisés pour la journalisation des messages et la propagation des alarmes.
  • Une spécification de format de données commun a été adoptée, le MultiFrame Metatformat (MFM), basé sur un concept de multi-frames permettant de définir des formats binaires autosuffisants, en couche, adaptés au transfert réseau et évolutifs. Cette spécification autorise une description complète de tout type de données, y compris l’encapsulation de format de données autres. Il est recommandé pour les nouveaux instruments d’adopter ce format de données à la construction.

Le système d’acquisition standard actuellement en exploitation au GANIL est entièrement basé sur cette architecture et sert de banc d’expérimentation grandeur réel. Il a déjà permis d’intégrer et de coupler avec succès différents systèmes grâce à sa conception entièrement modulaire. Les débits de données actuellement traitées sont de l’ordre de quelques Moctets/sec. Reste à transformer l’essai avec des systèmes plus complexes et demandant des performances d’acquisition de plusieurs centaines de Moctets/sec. L’infrastructure réseau ainsi que les capacités de stockage devront être adaptées à de telles quantités de données. Les premières expériences sont prévues pour début 2014.

Bruno RAINE