Réunions de la thematique "Online" et minutes

Qu'est ce que le "online"

Une première approximation de la définition du "online" pourrait être : "Ensemble des systèmes informatiques sollicités avant le stockage des données d’expérience."

Cela prend en compte :

Spécificités

Données "volatiles"

Les systèmes dit "online" gèrent des données non encore sauvegardées et dont la perte est irréversible.

Plateformes matérielles

RI3 : Thématique Online

Voir la présentation de Eric Legay (février 2014)et tous les échanges et annonces sur ce site

2013-11-20 - Kick off meeting

Présents :
• Thierry Le Flour (LAPP)
• Frederique Magniette (LLR)
• Frederic Saillant, Dominique Touchard, Nicolas Menard (GANIL)
• Christian Helft (LAL)
• Nicolas Dosme, Eric Legay (CSNSM)
• Sylvain Ferriol (IPNL)
• Shebli Anvar (IRFU)
• Dirk Hoffmann (CPPM)

Excusés :
• Philippe Gauron (LAL)
• Giovanni Lamana (IN2P3 - CMI)

Rapide exposé de C. Helft de la dernière réunion du CCRI

Depuis l'arrivée de Giovanni en tant que CMI, il y a une structuration de l'activité réseau en fonction de thématiques. Actuellement, mis à part les groupes historiques, il n'y a pas encore beaucoup d'activités visibles.

Tour de table et présentation de chacun

ATTENTION : Il m'est très difficile de retranscrire simplement les points de vues échangées durant cette réunion. Les échanges ont été denses et riches.

GANIL

Support aux expériences (6 ingénieurs ????)

Différents types de collaborations déjà actives :
• collaborations "verticales" au sein de projet (ex GET avec l'IRFU)
• collaborations "horizontales" avec DAQ4NP (DAQ for Nuclear Physics) avec l'IPNO et le CSNSM

Accélérateur (8 ingénieurs)

Le projet SPIRAL 2 a débuté en 2007, et la livraison de la première phase devrait avoir lieu en 2014.
Pour la phase un du projet, une collaboration entre l'IRFU, l'IPHC a été créée dès l'avant-projet détaillé. Pour la phase 2, des contacts ont pris avec le CENBG, le LPC CAEN, et le LPSC.
Le contrôle/commande de SPIRAL2 s'appuie sur la technologie EPICS.

Lors du démarrage du projet SPIRAL2, les ingénieurs du contrôle/commande découvriront certainement des solutions différentes des préconisations émises durant la phase de conception (malheureusement situation vécue par la quasi-totalité des participants). L'équipe a éprouvé beaucoup de difficultés à identifier les besoins des utilisateurs.
Pour pallier à cet état, une démarche UML se focalisant essentiellement sur les diagrammes d'utilisation, d'états, et de déploiement a été préconisée auprès des laboratoires partenaires. Au GANIL, à chaque fois que cette démarche a été utilisée, les résultats se sont avérés positifs, malgré une certaine difficulté à appréhender la démarche lors des premières tentatives. Le GANIL concède que cette démarche demande un effort important d'apprentissage de la part des concepteurs/développeurs. Elle permet néanmoins pendant ou après la conception de formaliser plus correctement les besoins et de documenter les développements.

LAPP (???? ingénieurs)

CTA a initié une démarche UML basée sur les use cases, principalement utilisée pour "forcer" la description des objets et obtenir des informations.
Un document ICD (Interface Control Document) est en cours de mise en place. Son objectif est de décrire les matériels d'un point de vue fonctionnel, données entrantes et sortantes, connectiques, mécaniques, ...
Ce document devrait être fourni avec tout module électronique.

IPNL (3 ingénieurs acquisitions + 2 ingénieurs contrôle/commande)

Très souvent confronté au problème de la mise devant le fait accompli, demande d'intervenir dans les projets plus en amont.

LLR (3 ingénieurs)

Problème du positionnement de l'informaticien vis à vis de l'électronicien et de la définition des métiers.
A mis en place un outil basé sur de petits modules python (pyrame) et ainsi facilement reconfigurable permettant de s'adapter aux évolutions plus ou moins documentées du design des électroniciens.
Très souvent confronté à des évolutions inopinées des interfaces, aimerait que des blocs / interfaces soient proposables avec des outils associées.
Pense que les méthodologies basées sur l'UML, même simplifiées, sont trop rigides par rapport à nos conditions de travail.

IRFU (??? ingénieurs)

Afin de définir nos métiers, il faut définir les distinctions entre software, firmware et électronique.
Au sein de projets collaboratifs, ils ont mis en place un framework de test permettant de s'adapter à des configurations très variables.
L'objectif était de fournir une couche d'abstraction aux électroniciens leur permettant d'accéder à leur hardware / firmware de façon quasi transparente.

Discussions

Un des enjeux du groupe est de dégager des éléments de réponses à apporter aux collègues informaticiens confrontés à la problématique d’avoir constamment à s’adapter, en tant que « dernière roue du carrosse », aux spécifications changeantes, quand elles existent, des éléments de hardware auxquelles on leur demande de s’interfacer à des fins de contrôle-commande et/ou acquisition de données.
Ces éléments de réponses se situent tant au niveau d’une spécification, voire d’une normalisation, des interfaces informatique / électronique qu’au niveau de la méthodologie projet et la gestion des codes. En effet les méthodes de développement en informatique ont évoluées au cours des 10 dernières années afin de s’adapter aux spécificités de l’informatique et sont maintenant relativement standardisées, ou portées par des outils standardisés et pourraient être mises en pratique pour le développement des firmwares et autres codes embarqués. ...

Un autre objectif sera de réussir à construire un annuaire uptodate des compétences "online" au sein du RI3. La question du lieu où poser cet annuaire est ouverte. Tous les participants se préoccupent peu du lieu, mais il ne faut pas qu'il soit remis en question sous peu. [PMN de Christian : le CCRI doit définir les modalités d’un tel dépôt]

J'ai proposé de ne pas intensifier le rythme de réunions pour le plaisir, et de garder un rythme trimestriel afin que cette activité reste une activité secondaire tout en nous laissant travailler sur différents points entre chaque réunion.

Actions

Pour le prochain rdv, les personnes ayant décrit des outils facilitant le dialogue informaticiens/électroniciens doivent envoyer / fournir des informations sur ces outils, avec les bons pointeurs.
Les personnes visées sont :
* S. Anvar - Outil de test
* T. Le Flour - ICD
* D. Touchard - Méthodologie UML utilisée
* F. Saillant - Format de données MFM
* F. Magniette Bibliothèque de modules Python

2014-03-24 - xTCA, MFM

Ordre du jour

Compte-rendu

Présents :

Réseau xTCA-DAQ

Format MFM

Framework Pyrame

Actions