Ceci est le recueil de l'ensemble des réunions menées au sein du RI3 ...
Voir aussi : la section Indico "RI3 + CCRI", sur https://indico.in2p3.fr/categoryDisplay.py?categId=467.
Objectifs de la cellule "Formation et Evènements"
La cellule " Formation et Evènements" a pour objectifs de réfléchir aux actions de formation à mener au sein de notre communauté, et être force de proposition auprès du CCRI et du chargé de mission formation de l'IN2P3. Par action de formation, il faut entendre ce terme au sens large : toute action visant à améliorer le niveau de pratique de notre métier.
Cette cellule doit s'assurer que l'information sur les formations circulent bien et s'efforcer de valoriser le plus possible le matériel de formation dont nous disposons. Ce matériel constitué de tutoriaux, documentation, guides est le plus souvent rassemblé à l'occasion des Ecoles Informatiques, de présentations dans des conférences ou de participation à des évènements "réseau" tels les JI, les JRES, les JDEV etc. Une de nos missions consiste à proposer des actions de formation plus courtes que les écoles et sous des formes différentes afin de rendre ce matériel accessible à une plus large audience que les participants à l'école.
Une autre de nos missions est de s'assurer que Les Journées Informatique soient organisées et aient lieu tous les 2 ans. En effet, ces journées sont un temps fort de la vie de notre réseau et peuvent s'apparenter à une action de formation par bien des aspects.
Fréquence et modalité des réunions
Les réunions ont lieu le plus souvent en téléconférence. Notre première réunion (kick off meeting) a eu lieu en marge de l'école informatique Big Data à Roscoff en juin 2013. Cette première réunion tenue autour d'une bière nous a permis de nous mettre d'accord sur nos objectifs, ce qui prouve que la bière n'empêche pas de réfléchir et d'être créatif.
En Septembre 2015, Valérie Givaudan a accepté de prendre la suite de Françoise Virieux et d'animer la Cellule "Formation & Evénements"
Les comptes-rendus sont désormais gérés dans Atrium.
Les actions de communication dans le cadre du RI3 s'articulent autour des axes suivants :
http://informatique.in2p3.frUne 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 :
Les systèmes dit "online" gèrent des données non encore sauvegardées et dont la perte est irréversible.
Voir la présentation de Eric Legay (février 2014)et tous les échanges et annonces sur ce site
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)
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.
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.
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
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.
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.
Très souvent confronté au problème de la mise devant le fait accompli, demande d'intervenir dans les projets plus en amont.
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.
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.
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.
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
Présents :