n°35
Novembre
2016
Prototypage pour le futur trajectographe de CMS
Le trajectographe de CMS

Alors que le LHC est entré dans sa seconde période d’exploitation (Run 2), des équipes sont déjà à pied d’œuvre pour préparer les phases futures à très haute luminosité de l’accélérateur prévues à l’horizon 2025. Des évolutions importantes des détecteurs (augmentation de la granularité, résistance à des taux de radiation accrus) mais aussi des systèmes de lecture, de déclenchement et d’acquisition sont prévues. Depuis 2012, notre équipe, Systèmes de Mesure et d’Acquisition de l’Institut Pluridisciplinaire Hubert Curien est impliquée dans les travaux de prototypage du système d’acquisition de données pour la jouvence du trajectographe de CMS. Dans ce contexte, il est inévitable de procéder par itérations successives, tout l’enjeu pour le développement logiciel étant d’arriver à gérer les évolutions imposées par les changements de matériel et de firmware (microcode embarqué), l’ajout de nouvelles fonctionnalités et la succession des tests en faisceaux.

La phase d’installation du HL-LHC (High Luminosity Large Hadron Collider) se déroulera pendant l’arrêt prolongé "Long Shutdown 3" qui devrait commencer en 2024 et à la fin duquel les performances de l’accélérateur seront maximales en termes de luminosité, énergie et empilement des événements pour l’exploitation des Run 4, 5, et au-delà.

L’expérience CMS (Compact Muon Solenoid) et en particulier le Trajectographe (ou Tracker), qui est la deuxième couche de détection en partant du centre de ce détecteur, est comme les autres parties concerné par cette mise à jour appelée "upgrade phase-2".

La mise au point de chaque étage de sa future chaîne d’acquisition nécessite la mise en œuvre et le test de nombreux prototypes dont chacun est une étape nécessaire pour atteindre les performances finales désirées.

Notre équipe est présente sur les parties électronique, firmware et logicielle de ce projet, et participe régulièrement à des faisceaux test qui impliquent différents corps de métier. Ceux-ci vont de la conception des modules de détection en silicium en passant par la mécanique, le refroidissement... jusqu’au traitement des données acquises par les physiciens. Ces données font l’objet d’une véritable analyse scientifique qui donne généralement lieu à une publication.

Une stratégie a dû être élaborée pour permettre au logiciel de contrôle et d’acquisition de suivre à la fois les changements de matériel et les successives augmentations de performance.

Ce logiciel, écrit en C++, doit évoluer en même temps que le firmware embarqué dans le processeur FPGA (Field-Programmable Gate Array) des cartes mère utilisées. Celles-ci peuvent être de plusieurs types puisqu’aux cartes génériques GLIB (Gigabit Link Interface Board) équipées d’un Virtex 6 succèdent maintenant les CTA (aussi appelées FC7) équipées d’un Kintex 7. Issues d’un développement effectué par le CERN, ces cartes comprenant un FPGA sur carte mère répondant à des besoins 100% génériques et deux emplacements dits mezzanines pour les besoins spécifiques sont conçues pour être flexibles, évolutives et destinées à être utilisées dans différentes expériences. Elles sont au format Advanced Mezzanine Card pour châssis µTCA mais permettent aussi des premiers développements hors crate ou sur table. Le standard microTCA (micro Telecommunications Computing Architecture), très utilisé dans le secteur des télécommunications, a été choisi pour remplacer l’actuel VMEbus en fonction de ses performances mais également pour sa pérennité en regard des échelles de temps particulièrement longues des expériences du LHC. Le CERN est d’ailleurs partie prenante dans la mise au point de ses spécifications, au même titre que l’IN2P3.

Pour gérer ces changements, notamment les générations successives de cartes électroniques, nous avons proposé d’écrire une couche logicielle intermédiaire permettant de présenter une interface commune aux fonctions supérieures. Cette couche intermédiaire, le middleware Ph2_ACF (Phase-2 Acquisition & Control Framework) comporte une partie de description du matériel de détection des particules et une partie interface permettant de le contrôler.

En plus des différences au niveau des cartes mère génériques, ce middleware doit également gérer une grande diversité de cartes mezzanine spécifiques.

En effet, les cartes mères peuvent accueillir chacune deux mezzanines au format FMC (FPGA Mezzanine Card) qui apportent des fonctionnalités spécifiques : entrées / sorties nécessaires à l’acquisition, communication avec une autre carte, contrôle de modules de détection. Ces modules de détection comportent une électronique frontale commune, totalement incluse dans un circuit intégré, le CMS Binary Chip (CBC). Chacun de ces circuits CBC pilote 254 pistes de détection et possède de nombreux paramètres à configurer.

Pour permettre la mise en œuvre de plusieurs cartes, de types différents avec des mezzanines contrôlant chacune un nombre variable de CBC, le format de sortie des données devra, dans sa version définitive, gérer cette modularité. Ce format à l’élaboration duquel nous participons intégrera donc de nombreux modes de fonctionnement parmi lesquels l’ajout de paramètres optionnels ou la simulation de fonctions assurées par des éléments matériels non présents comme la concentration des données.

Des classes sont donc régulièrement ajoutées au modèle pour assurer ces traitements et de nombreuses autres évolutions sont encore à prévoir.

Ce middleware est ainsi devenu un projet à part entière au développement duquel participent maintenant plusieurs laboratoires de différents pays, ce qui a nécessité de basculer le dépôt « git » des sources vers une organisation où chaque proposition de modification passe par la soumission d’une requête de tirage (pull request). Le middleware sert de base à plusieurs systèmes d’acquisition, parmi lesquels notre propre logiciel d’acquisition.

Celui-ci fonctionne sous XDAQ, une plate-forme logicielle développée par le CERN et utilisée pour le Online CMS, présentant l’interface utilisateur dans un navigateur et permettant l’envoi des données vers les autres couches logicielles de CMS assurant leur distribution, traitement et stockage. L’ensemble des couches constitue le CMS Software (CMSSW).

Les faisceaux test qui se succèdent au rythme d’un ou deux par an sont également un bon moyen de mesurer les avancées en terme de performances et de technologies employées. Ainsi pour le nombre de pistes, nous sommes passés en 2012 de 254 pistes de détection à deux fois 254, puis quatre fois, puis huit, pour arriver à seize fois fin 2015.

Ce nombre ainsi que les autres caractéristiques gérées par nos systèmes d’acquisition vont continuer à augmenter nous rapprochant petit à petit de la configuration de production définitive.

Christian BONNIN (IPHC)