Lors des dernières journées informatiques, une table ronde a été organisée sur la thématique du Online pour nos expériences. Cette table ronde a réuni plus de 30 personnes représentant l’ensemble des laboratoires et de l’IRFU et couvrant ainsi toutes les thématiques des instituts.

Cette table ronde a été animée par S. Anvar, P.-Y. Duval, X. Grave, T. Le Flour et E. Legay.

3 sujets inégaux

Les discussions se sont organisées autour de trois points : le contrôle de l’électronique, le flot de données et les interactions avec les autres systèmes d’acquisition.

Autant la première question fut riche en avis et discussion, autant les deux autres points furent plus succinctement traités. L’ensemble des participants a rapidement convergé sur l’importance d’un format de données le plus léger possible, mais contenant un maximum de métadonnées permettant d’identifier les données simplement dans les différents outils ayant à traiter ou gérer ce flot de données. Le format de données MFM recommandé par l’ICC pour Spiral 2 a été cité plusieurs fois.

La discussion autour des interactions entre les systèmes d’acquisition a été encore plus simple : cette problématique ne concerne que le monde de la physique nucléaire. Le type de détecteurs utilisés en physique des particules et en astrophysique ne nécessite pas la souplesse que les systèmes d’acquisition pour les expériences de physique nucléaire doivent apporter.

Contrôle de l’électronique

Ce point fut celui amenant le plus de débats. La discussion est partie d’une remarque de S. Anvar sur l’adaptabilité des cartes électroniques au contexte : tests, banc d’essai, expériences … La question est, entre autre, de savoir comment on pourrait plus simplement prendre le contrôle d’une carte développée au sein de l’IN2P3/IRFU.

La notion de framework de développement permettant la montée en puissance d’un projet sans avoir à redévelopper de code a été mise en avant. Cela permet de gérer de l’électronique en développement et de fournir des outils aux électroniciens lors de cette première phase, ce même framework servant ensuite aux bancs de tests, puis aux expériences. Mais cela implique de penser, dès la première phase, aux contraintes finales d’utilisation des cartes.

L’architecture globale mise en place dans plusieurs laboratoires/expériences est composée de deux niveaux : une couche logicielle de gestion du hardware et une couche d’abstraction pour simplifier la gestion des cartes. Le premier niveau gère les accès au matériel électronique et fournit une interface se basant sur des standards vers le reste du système d’acquisitions. Le second niveau collecte les informations des éléments de premier niveau et propose des outils / interfaces pour les utilisateurs finaux. Nous savons faire cela, mais pour pouvoir offrir encore plus de souplesse, un de nos principaux problèmes est l’hétérogénéité des interfaces à contrôler. Ne serait-il pas possible au sein de l’IN2P3/IRFU de définir une interface minimale permettant de comprendre le fonctionnement d’une carte et ainsi d’effectuer le contrôle de cette carte plus simplement ?

Une évolution du métier

Les développeurs en physique des particules ont remarqué la simplification de leur travail, l’essentiel du contrôle et de l’intelligence étant embarqué sur les cartes numériques embarquant de nombreux processeurs. Avec la propagation du numérique et des processeurs généralistes embarqués (hard ou soft), la limite entre le firmware des électroniciens et le software des informaticiens se fait de plus en plus mince. Nous devrions discuter plus avec nos collègues électroniciens pour améliorer nos collaborations. Nous devons leur apporter la méthodologie en développement qui leur manque parfois, et améliorer notre connaissance des systèmes reprogrammable. En physique nucléaire, ce rapprochement des deux mondes est moins marqué. Cela est probablement dû à des expériences trop courtes pour permettre le développement de cartes dédiées, le software devant continuer à apporter la souplesse et l’adaptabilité d’une expérience à l’autre.

Cette table ronde, fructueuse, nous laisse avec beaucoup de questions sans réponses :
 Faut-il définir un format de données type IN2P3 ou partager les connaissances sur ce sujet pour améliorer la gestion des données individuellement au sein de chaque expérience ?
 Comment fournir des outils plus souple et plus tôt aux expériences ?
 Comment travailler avec les électroniciens dans les collaborations sur les interfaces communes ?

A suivre donc.

Eric LEGAY (CSNSM)