Houston we have a problem Malgr les avancements
Houston, we have a problem! • Malgré les avancements sur le FSC vu pendant les PK / PA en 2016, on n’avance pas à un rythme qui satisfait les besoins projet • On entend trop souvent que les scientifiques n’ont pas les infos dont ils ont besoin et inversement pour les ingénieurs sol • Vue du CNES, on ne voit pas une architecture FSC complète ni une descriptif des chaines / modules techniques ET scientifiques • Expérience des autres missions (notamment GAIA / EUCLID) montrent qu’on n’a plus de marge
Solution proposée • Une structure simple pour l’organisation du système sol, suivie/coordonnée par le CNES – Responsable système sol – Responsable des I/F et d’AIV • Càd, le CNES renforce les ressources pour permettre un suivi et un accompagnement scientifique ET technique • Piloté par une groupe système sol – Composé des membres de chaque centre scientifique – Animé par les réunions téléphoniques régulières / RDVs – Responsable pour la coordination de la compilation de la base des données science
Organisation Ingénierie Sys. Sol • Le RSS n’est pas responsable pour le développement des centres mais à s’assurer la cohérence et la compatibilité des moyens sol et qu’ils satisfassent les exigences système – • • Ces taches seront effectuées via le groupe Système Sol et avec le support des différents intervenants au CNES Le RSS, par délégation de tache du Cd. P, va rédiger les conventions avec les différents labos et va suivre l’exécution de ces conventions pendant les ph. C/D/E 1 L’organisation ingénierie ne change rien par rapport l’organisation hiérarchique (contractuel / scientifique) déjà en place – RSS prend la direction du group system délégué par le Cd. P qui tient le porte monnaie
Mais comment construire un pont entre la science et l’ingénierie ? • Aujourd’hui, la priorité est à bien comprendre l’architecture proposé pour le FSC plateforme d’OPS et mettre en place les règles pour le développement de code scientifique, comment faire et avec quoi… • Dans la sens inverse, il faut que l’équipe technique FSC comprendre la réalité des chaines à tourner, les contraintes en terme du volumétrie, mémoire instantanée, les infos que vous devrez remonter (ici on parle des erreurs, info de traçabilité, etc) • Et, il faut essayer à parler la même langage… d’ici, on ne parle pas de JAVA, ni Python; XMPP dit autant à un astrophysicien que PHZ à un ingénieur Big. Data! • On propose 2 postes pour aider ces dialogues : • • R. Sys FSC amène les infos techniques de ses systèmes RSS écrit la schéma de documentation pour identifier les besoins scientifiques vers exigences techniques et soutien aussi le R. Sys FSC
Pipelines en détail • Les pipelines scientifiques seront coordonnées par l’IRFU (AC) – Sortie est un doc qui décrire le schéma globale des pipelines et la science – Gérer les interdépendances entre chaque ‘pipeline’ (càd la modèle des données) • Chaque pipeline sera gérer pas un responsable – Il va produire a SDD (Software Description Document) • • Définir la découpage du pipeline en modules qui va définir la responsabilité de chaque scientifique / développeur Définir les entrées / sorties du pipeline (données brut, données ancillaires, modèles, techniques, etc) – Dépendant de comment le code sera intégré sur la PF, il faut peut-être aussi gérer l’organisation de code / voir entre pipelines avec d’autres responsables • Chaque module sera gérer par un responsable : – Il va produire un SRD pour son module • • Définir les entrées / sorties; les transformations génériques utilisées; les contraints de perf; les besoins techniques, etc Expliquer la science effectué pour que les développeurs / scientifiques en amont puissent bien comprendre
Exemples science > technique • Vous avez besoin d’utiliser les librairies externe en tant que paramètre d’entré de votre module. Mais le fichier est 5 Go. Il faut dimensionner les besoins techniques pour que la système puisse répondre, sinon, cela pourrait compromettre vos traitements. • On va utiliser un même bout de code dans CP et GP; comment on gère la configuration des différents versions du même code (et quand le modèle des données sera mis-àjour)… • Vous avez besoin d’utiliser une méthode pour calculer ‘x’; et ton module voisin aussi, mais vous ne travailler pas dans la même labo et vous ne savez pas que cela existe… c’est mieux de partager un bibliothèque des méthodes ou chacun fait à leur façon chez eux… • Vous avez besoin de faire un MC dans votre code et les données d’entré sont très grosses. Vous filtrez vous-même l’objet d’entré d’avoir qqch d’une taille acceptable pour traiter les données rapidement puis reconstruire les données en sortant pour la prochaine module, ou c’est une tache de l’intégration…
FSC System en détail À m co p t lé r e
Exemples techniques > science • On parle d’utiliser les interfaces REST – comment une scientifique puissent appeler les données d’entré pour sa chaine ? • Le développeur télécharge qqs outils depuis l’internet pour avoir une environnement de test ‘représentative’ du FSC; au moment de livraison labo > FSC ca ne marche pas. Qui a tort et qui corrige ? • L’implémentation ‘logging’ au FSC permet les pipelines à remonter les infos pertinents au système mais il n’y a pas d’API pour les 3 langages proposées (JAVA, C++, Python). Comment faire, écrire une API ou exclure une langage ? • Les modules pour une pipeline sont livrés sur Github au FSC. Ensuite les ing’s du FSC les posent dans les containers Docker et mettre en musique la séquencement. Mais les labos les déposent sur Github comment ils veulent et l’ing au FSC ne retrouve pas. Faut-il pas mettre en place une arborescence ?
Comment ca va fonctionner ? • Coordination – Un téléconf d’environ 1 h toutes les 2 semaines entre la groupe système (organisé + CR par GW) – Un téléconf d’environ 1 h les autres 2 semaines entre la groupe science sol (organisé + CR par AC) • Le RSS, RIF et Cd. P FSC vont y participer pour s’assurer de la cohérence entre la technique et de la science (accompagnement scientifique). – Une CRA sera fournit par le responsable de chaque entité aux RSS en fin de chaque mois (modèle à définir) – Les infos à échanger / stocker sera sur un seul wiki, pas plusieurs
Planning • • • • 7 octobre : présentation des travaux spécifications SVOM sol (J 3 ) (JPLF) 20 -21 octobre : Science related GIM IAP Paris (F/C) 03/11/2016 : Revue des moyens pour ph. C/D/E 1 Début novembre : Jalon J 3 livré au CNES 14/11/2016 : science ECL + simu Mi-Novembre / Décembre : Préparation des conventions 15 -16 novembre : WS Développeurs – Marseille (Andrea Formica) 17 novembre : CIO Decembre 2016 : presentation SVOM au CNES Mi-janvier 2017, KO ph. C Chinois; Sanya, Chine 21 -23 fevrier 2017 : PDR System Sol au CNES Juin 2017 : PDR FPOC Juin 2017 : PDR FSC • …et sans doute plein d’autres RDV manquants
• Les planches suivantes sont extrait d’une présentation effectué au FSC (BC/AC/JPLF/AF) en juin 2016
Documentation ð Liste de documentation minime pour PDR Sept 2016 Spec FSC ð Spécification FSC ð Schedule Spec Tech FSC User manual FSC Dev / Ops ð Plan de Développement ð ICD-144 Architecture et Interfaces (et les IRDs…) SDD Pipeline x SRS Module 1 ð SDD pour tous les pipelines SRS Module 2 SRS Module 3 SDD : Software Design Description SRS : Software Requirement Specification SRS Module 4
Spécification FSC ð Voir squelette déjà envoyé ð Fonctions þ þ þ þ Développement/maintenance des modules scientifiques Interface avec la reste du monde Hébergement et exécution des modules Enchainement / automatisation Centralisation des logs Préparation des données brut pour processing scientifique Besoins opérationnel / burst advocate ð Qui : Science - Arnaud / Bertrand; Tech - Jean-Paul / Andrea
Pipeline x : SDD ð Pour le PDR il faut pour chaque pipeline au minimum : þ Introduction þ Pipeline x Functional Description + Diagram þ Data Products (e. g. MXT, ECLAIRS, GRM, VT) èModule description (functional overview) + diagram èInputs / Outputs (incl. Data preparation) èActivation Criteria / dependancies èParameters (chain variables) ð Producteur : le responsable scientifique du pipeline ð Consommateur(s) : développeur / technique FSC / Bd. D
Example interface module x from F. Daigne
Base des Données FSC ð Elément clé du système FSC ð Besoin pour dev þ Interface pour insérer / modifier les données þ Qui va gérer / coordonner la base ? ð Besoin pour ops ð Plan de dev associé ð Modèle des données ð Integration dans FSC þ JP à présenté interface broker / est-il possible avec solution proposé par LAM ? ð Reprendre planches / doc de LAM du janvier 2016? ? ? !!! Doodle
Example : GAIA MDB Dictionary Tool
- Slides: 17