IN2P3-Forge: Issueshttps://forge.in2p3.fr/https://forge.in2p3.fr/favicon.ico?16780521162021-05-12T10:35:22ZIN2P3-Forge
Redmine PyROS - Story #45138 (New): REQ-055 ERGO_040 Documentationhttps://forge.in2p3.fr/issues/451382021-05-12T10:35:22ZPallier Etienne
<p>La documentation utilisateur suivante sera fournie par le titulaire :<br />- Dossier de conception<br />- Schéma fonctionnel du système<br />- Manuel utilisateur<br />- Manuel d’installation</p> PyROS - Story #45137 (New): REQ-053 ERGO_030 Formationhttps://forge.in2p3.fr/issues/451372021-05-12T10:35:03ZPallier Etienne
<p>Lors de la fourniture du système développé, le titulaire devra former les utilisateurs finaux du système. Cela correspond à deux ou trois personnels CNES. La formation portera sur la prise en main du système de mesure et de sa maintenance. Concernant le logiciel PyRos, une autre STB a été rédigée et la formation des personnels nécessaires est déjà prévue et ne rentre pas en compte dans celle-ci.</p>
<p>La formation des personnels utilisateurs permettra une bonne prise en main du système de mesure.</p> PyROS - Story #45136 (New): REQ-052 ERGO_020 Operabilitéhttps://forge.in2p3.fr/issues/451362021-05-12T10:34:30ZPallier Etienne
<p>Le système doit être opérable et exploitable à distance, du fait que le système sera placé en Nouvelle Calédonie.</p>
<p>L’opérabilité du système à distance est nécessaire pour le bon fonctionnement du système.</p> PyROS - Story #45135 (New): REQ-050 SURETE_260 Système informatique (SSI)https://forge.in2p3.fr/issues/451352021-05-12T10:33:49ZPallier Etienne
<p>Les systèmes informatiques mis en œuvre devront respecter les règles de SSI nécessaires et suffisantes pour garantir la sécurité des systèmes informatiques. Une documentation spécifiant les règles de SSI applicables au système sera fournie au titulaire par le CNES.</p>
<p>Le respect des règles de SSI permet de garantir la protection des données.</p>
<p>document#1207</p> PyROS - Story #45134 (New): REQ-043 SURETE_180 Sécurité des personnes : lumièrehttps://forge.in2p3.fr/issues/451342021-05-12T10:33:27ZPallier Etienne
<p>Lorsque le toit du bâtiment est en mouvement une lumière clignotante doit le spécifier pour supprimer le risque d’accident.</p>
<p>La sécurité des personnels sur site lors des maintenances doit être garantie.</p> PyROS - Story #45133 (New): REQ-042 SURETE_170 Sécurité des personnes : système d’arrêt automatiquehttps://forge.in2p3.fr/issues/451332021-05-12T10:33:06ZPallier Etienne
<p>Le système final dans toutes ses configurations ne doit pas nuire à la sécurité des personnes.<br />Le toit du bâtiment ne doit pas se fermer sur un obstacle. Dès qu’un obstacle est détecté lors de sa fermeture il doit se rouvrir et signaler le problème aux opérateurs.</p>
<p>La détection d’obstacle pour la fermeture du toit permet à la fois de protéger les personnes et le télescope.</p> PyROS - Story #45132 (New): REQ-031 SURETE_040 Automatisation du bâtimenthttps://forge.in2p3.fr/issues/451322021-05-12T10:32:46ZPallier Etienne
<p>Pour des questions de fiabilité et de protection, le système devra être protégé par un bâtiment (coupole, shelter…) pouvant s’ouvrir et se fermer avec un pilotage à distance. Afin de permettre les observations il devra s’ouvrir automatiquement en début de nuit, et se fermer en fin de nuit.</p>
<p>Un système d’ouverture / fermeture automatique est requis sur le bâtiment afin de faciliter l’opérabilité à distance du télescope.</p> PyROS - Story #45131 (New): REQ-049 SURETE_250 Transfert des donnéeshttps://forge.in2p3.fr/issues/451312021-05-12T10:32:23ZPallier Etienne
<p>Les données prises par le télescope devront être transférées en temps réelle de façon automatique après chaque mesure si cela est possible et après chaque nuit d’observation. Ce transfert s’effectuera par internet sur un serveur https protégé pouvant répondre aux interrogations des utilisateurs.</p>
<p>La demande d’un transfert par internet permet une récupération rapide des images pour analyse.</p> PyROS - Story #45130 (New): REQ-047 SURETE_240 Sauvegarde des données bruteshttps://forge.in2p3.fr/issues/451302021-05-12T10:31:55ZPallier Etienne
<p>Pour chaque nuit d’observation une sauvegarde des données est nécessaire. Cette sauvegarde permettra en cas de coupure réseau ou autre problème éventuel de conserver les données prises par le télescope et de les transmettre par la suite pour analyse.</p>
<p>Les données doivent être sauvegardées sur un support physique afin de garantir leur enregistrement et accessibilité en cas de coupure du réseau permettant leur transmission en temps réel.</p> PyROS - Story #45129 (New): REQ-046 SURETE_210 Arrêt du système en cas de condition météorologiqu...https://forge.in2p3.fr/issues/451292021-05-12T10:31:33ZPallier Etienne
<p>Le système sera soumis à des tempêtes tropicales ou des cyclones, il faudra que le système soit arrêté à ce moment-là pour ne pas être endommagé. Cet arrêt doit pouvoir s’effectuer à distance depuis la métropole. Le télescope et le bâtiment doivent être configurer dans une position de « sauvegarde des systèmes » qui sera déclenchée par l’équipe en France suite à l’annonce des conditions météorologiques défavorables par les services compétents. Il est demandé au titulaire de préciser à partir de quel moment une intervention humaine est requise pour la mise en sécurité du matériel, et si celle-ci est indispensable du fait de la résistance du bâtiment.</p>
<p>La mise en place d’une prise en compte des conditions météorologiques défavorables permet de garantir la protection des instruments.</p> PyROS - Story #45128 (New): REQ-045 SECURITE_200 Système d'alertehttps://forge.in2p3.fr/issues/451282021-05-12T10:31:02ZPallier Etienne
<p>Dans le cas de la détection d’un problème sur le système, le système devra être capable d’envoyer une alerte à l’équipe en métropole, ainsi qu’à une personne sur place qui pourra prévenir les autorités compétentes le cas échéant.</p>
<p>La mise en place d’un système d’alerte permet une gestion rapide du problème détecté.</p> PyROS - Story #45127 (New): REQ-044 SURETE_190 Sécurité des personnes : système d’arrêt d’urgencehttps://forge.in2p3.fr/issues/451272021-05-12T10:30:37ZPallier Etienne
<p>Sécurité des personnes : système d’arrêt d’urgence<br />Si un incident est détecté, le système devra s’arrêter de fonctionner automatiquement. Si ce système ne fonctionne pas, il doit y avoir sur place un système d’arrêt d’urgence manuel.</p>
<p>La sécurité des personnels sur site lors des maintenances doit être garantie.</p> PyROS - Story #45126 (New): REQ-048 sauvegarde des données bruteshttps://forge.in2p3.fr/issues/451262021-05-12T10:29:49ZPallier Etienne
<p>Le système PyROS doit sauvegarder les données sur le télescope afin de les mettre à disposition suite à une coupure réseau ou autre problème éventuel.</p> PyROS - Story #45125 (New): REQ-041 information sur les composants (ajout)https://forge.in2p3.fr/issues/451252021-05-12T10:29:23ZPallier Etienne
<p>*Informations complémentaires à traiter avec [#PYROS-16] *:<br />. non fermeture de l'obturateur, problème caméra.</p>
<p>*Elements à tracer pour chaque événement traité dans le cadre de [#PYROS-16] : *<br />images, valeur max et min du paramètre en défaut, renvoie de code d’erreur, date et heure d’apparition du problème, composant touché</p> PyROS - Story #45124 (New): REQ-038 focalisation, alignement, ...https://forge.in2p3.fr/issues/451242021-05-12T10:29:01ZPallier Etienne
<p>PyROS sera équipé pour que les utilisateurs puissent lancer des séquences d'observation de calibration (focalisation, alignement, ...) préprogrammées et enchaîner ensuite les traitements de dépouillement des images afin de produire les informations de calibration en base.</p>
<p>Ces traitements pourront être lancés soit par les utilisateurs "classiques", soit par un utilisateur spécifique dédié aux tâches de calibration.</p> PyROS - Story #45123 (New): REQ-036 logiciel pour la maintenance à distancehttps://forge.in2p3.fr/issues/451232021-05-12T10:28:30ZPallier Etienne
<p>- Toutes les pannes logicielles doivent pouvoir être gérées à distance :<br />. lancement en mode debug, analyse de logs, patch ou mise à jour de logiciel<br />. restauration de la base de données à un état antérieur<br />- PyROS doit offrir aux administrateurs les moyens logiciels de diagnostic des pannes matérielles et de reconfiguration du système pour fonctionner sans les éléments en panne.</p>
<p>Cette tâche nécessite des échanges avec l'équipe en charge de la mise en place des procédures de maintenance des télescopes.</p> PyROS - Story #45122 (New): REQ-032 automatisation du bâtiment et du télescopehttps://forge.in2p3.fr/issues/451222021-05-12T10:27:58ZPallier Etienne
<p>PYROS doit fournir les éléments logiciels d'automatisation du bâtiment et du télescope :<br />- pilotage à distance<br />- ouverture et fermeture automatique selon conditions météo paramétrables.<br />- mise en position de sécurité du télescope et du bâtiment en cas de coupure électrique prolongée (pour une coupure de courte durée on fonctionne sur l'onduleur et on met en sécurité si ça dure)<br />- système de réouverture automatique et d'alerte aux administrateurs si le toit rencontre un obstacle lors de la fermeture<br />- signal lumineux lors des mouvements du toit<br />- si un incident impactant la sécurité des personnes est détecté, le système doit s'arrêter de fonctionner.<br />- le système doit être capable d'envoyer une alerte à l'équipe en métropole ainsi qu'à une personne sur place<br />- l'équipe en métropole doit pouvoir placer le télescope et le bâtiment dans une position "sauvegarde des systèmes".</p> PyROS - Story #45121 (New): REQ-009 requêtes de calibrationhttps://forge.in2p3.fr/issues/451212021-05-12T10:27:19ZPallier Etienne
<p><strong>Origine</strong><br />Tous utilisateurs</p>
<p><strong>Besoin</strong><br />Intégrer à PyROS un système de programmation d'images de calibration dark ou flat avec une durée et un filtre choisi par l’utilisateur.</p>
<p><strong>Finalité</strong><br />Afin que chaque utilisateur puisse utiliser des darks et flats adaptés à son mode d'utilisation.</p>
<p><strong>Test</strong><br />. Soumission de requêtes de dark et flats<br />. Vérification du stockage dans PyROS des darks et flats demandés</p> PyROS - Story #45120 (New): REQ-017 Information sur les requêtes soumises par l’utilisateurhttps://forge.in2p3.fr/issues/451202021-05-12T10:26:47ZPallier Etienne
<p>Pour chaque requête, indiquer :<br />- A-t-elle été planifiée par l’ordonnanceur ?<br />- Sinon pourquoi ? (Élévation au-dessus de l’horizon du télescope, élévation du soleil, distance de la lune, date dans le passé, date trop loin dans le futur, quota dépassé…)<br />- A-t-elle été exécutée par le télescope ? Sinon pourquoi (pas encore l’heure, télescope fermé pour cause météo, télescope fermé pour panne, échec lors de l’exécution) ?<br />- Les images ont elle été traitées, sinon pourquoi (en file d’attente, panne du service de traitement d’images, échec lors du traitement d’images) ?</p> PyROS - Story #45119 (New): REQ-008 requêtes SST flexibleshttps://forge.in2p3.fr/issues/451192021-05-12T10:25:38ZPallier Etienne
<p><strong>Origine du besoin</strong><br />chaîne de traitement OSMOSE du CNES utilisant les télescopes TAROT pour la surveillance de l'espace.</p>
<strong>Besoin</strong>
<ul>
<li>Créer un nouveau format de description de série (par exemple en JSON) permettant de décaler la date des requêtes de surveillance de l’espace.</li>
</ul>
Remplacer l’information « coordonnées à l’ouverture de la première image » par une éphéméride de direction de la cible sur toute la plage sur laquelle on accepte de décaler la date de l’observation.
<ol>
<li>L’éphéméride comprendra une liste d’éléments ‘date,angle1,angle2’</li>
<li>L’éphéméride sera associée à un repère parmi ceux-ci-dessous :<br />AZEL_OBSERVED : azimut/élévation visés par le télescope (référence terrestre).<br />C’est le repère naturel d’un télescope à monture AZEL.<br />HADEC_OBSERVED : angle horaire et déclinaison visés par le télescope (référence terrestre).<br />C’est le repère naturel d’un télescope à monture HADEC.<br />ALTALT_OBSERVED : altitude/altitude (référence terrestre).<br />C’est le repère naturel d’un télescope à monture ALTALT.<br />RADEC_ICRS : ascension droite et déclinaison (référence céleste).<br />C’est le repère naturel des catalogues d’objets stellaires.<br />Entre les points de l’éphéméride, la trajectoire sera interpolée. L’entête de l’éphéméride indiquera l’interpolateur à utiliser. Le système implémentera au moins l’interpolation linéaire.<br />Si l’éphéméride ne contient qu’un point, la date d’exécution est imposée ; si l’éphéméride contient plusieurs points, la date d’exécution doit être choisie entre les deux dates extrêmes.</li>
</ol>
<ul>
<li>Pour chaque image de la série, le format prévoira :</li>
</ul>
<ol>
<li>Le filtre à utiliser pour l’image</li>
<li>Le temps d’intégration de l’image. Ce temps sera indiqué en secondes avec la possibilité de spécifier des durées non entières (par exemple 0,125 s).</li>
<li>La possibilité d’un « filage de la cible » pendant l’image :<br />Indiquer la longueur en X et en Y que doit parcourir la cible dans le champ de vue pendant l’intégration.<br />Indiquer si avant le début de l’image suivante le télescope doit revenir sur l’éphéméride de référence ou s’il doit garder le dépointage du au filage de la cible.</li>
<li>La possibilité d’un décalage en X et Y avant l’image suivante afin d’éviter de confondre une détection d’objet nouveau avec un pixel chaud. (TNCFONC_020)</li>
</ol>
<ul>
<li>Prévoir dans le format de description des séries une sous structure spécifique à chaque modèle de caméra afin de pouvoir adresser les fonctions avancées des caméras (binning, choix de la durée du readout, mode de rolling shutter, …)</li>
</ul>
<ul>
<li>Créer un service web indiquant la validité d’une requête et son temps d’exécution sans la lancer :</li>
<ol>
<li>Avant de lancer une requête, l’utilisateur peut vouloir déterminer le temps télescope qui sera nécessaire à son exécution (le temps d’exécution de la requête dépendra des temps de vidage des caméras, des temps de changement de filtre, des temps de décalage du pointage entre les images, du recouvrement entre ces actions…)</li>
</ol></li>
</ul>
<p><strong>Finalité</strong><br />La version ROS actuelle permet de donner les coordonnées célestes à l’ouverture du diaphragme de la première image, la vitesse de motorisation en ascension droite et déclinaison, la date d’ouverture du diaphragme et l’écart possible à la date demandée.<br />Ceci permet de décaler les dates des requêtes d’observation d’objets célestes car les coordonnées célestes utiles sont les mêmes quelle que soit la date d’exécution de la requête. En revanche, ceci ne permet pas de décaler les dates des requêtes d’observation d’objets en orbite terrestre car les coordonnées célestes utiles dépendent de la date d’exécution de la requête.<br />Cette évolution permettra de :<br />- passer à l'ordonnanceur PyROS des informations lui permettant de limiter les temps morts dans la programmation des télescopes<br />- limiter les risques de confusion entre détections et artefacts<br />- profiter des fonctions avancées des caméras</p>
<p><strong>Test de validation</strong><br />Etape 1 : validation du format de fichier à transférer et de l'interface des services REST de soumission de requête et de validation de requête.<br />Etape 2 :<br />- test de validation d'une requête et consultation du retour (temps d'exécution prévu)<br />- test de soumission de requête et vérification que les informations transmises sont stockées dans la BD PyROS sous une forme exploitable par l'ordonnanceur PyROS.<br />Etape 3 :<br />- vérification que PyROS comble bien les temps morts par décalage des requêtes<br />- vérification que les télescopes insèrent bien les dépointages demandés par l'interface<br />- vérifcation qu'on peut règler les paramètres avancées des caméras</p> PyROS - Story #45118 (New): REQ-016 informations sur les composants de l'observatoirehttps://forge.in2p3.fr/issues/451182021-05-12T10:23:20ZPallier Etienne
<p>Développer un module avec d’une part une interface graphique et d’autre part une possibilité d’accès aux données brutes par un service web pour consulter l’état du système et son historique. Donner la possibilité de fixer des seuils d’alerte sur les valeurs des capteurs. Afficher un état synthétique de l’observatoire basé sur les seuils d’alerte.<br />- Configuration matérielle et logicielle : dimensionnement des machines virtuelles, emplacement des composants logiciels, interconnexions électriques et réseau…<br />- Données de la station météo<br />- Images des webcams avec mémoire des n dernières heures<br />- Position du toit<br />- Position du télescope<br />- capteurs positionnés sur les moteurs de toit, télescopes, …<br />- état des commutateurs électriques, des onduleurs<br />- état des équipements informatiques et réseau<br />- état des disques, barrettes mémoires et alimentations<br />- état des services logiciels de Pyros</p> PyROS - Story #45117 (New): REQ-019 Mise à disposition des images et mesureshttps://forge.in2p3.fr/issues/451172021-05-12T10:21:36ZPallier Etienne
<p>Le module de mise à disposition des images et mesures doit gérer les droits de chaque utilisateur :<br />Chaque utilisateur doit pouvoir accéder à ses images et mesures via un serveur https avec authentification.<br />Il doit pouvoir demander les images soit en donnant un nom d’image, soit une plage de dates, soit un fichier contenant une liste de noms d’images.<br />Il doit pouvoir demander les mesures en précisant la date de production des mesures à partir de laquelle il veut tout récupérer (il s’agit de la date de production de la mesure et non de la date de la prise de vue). Si des images sont traitées en retard, leur date de production est celle à laquelle les mesures ont été mises à disposition. L’idée est que l’utilisateur puisse récupérer les mesures de façon exhaustive sans avoir à faire de requête particulière pour les mesures produites avec retard.</p> PyROS - Story #45116 (New): REQ-039 SURETE_160 Sauvegarde des panneshttps://forge.in2p3.fr/issues/451162021-05-12T10:19:48ZPallier Etienne
<p>Il est demandé au titulaire de pouvoir sauvegarder dans un fichier ou tout autre support l’historique des pannes logicielles et matérielles. Le fichier de sauvegarde devra contenir tous les éléments nécessaires à la compréhension et la résolution de la panne (images, valeur max et min du paramètre en défaut, renvoie de code d’erreur, date et heure d’apparition du problème, composant touché, …). L’administrateur pourra également visualiser par internet l’état global du système et recevra des alertes sur les paramètres surveillés : panne de disques ou d’alimentation, surchauffe de moteurs, dérive de capteurs, non fermeture de l’obturateur, problème caméra ... Il peut explorer en détail le fonctionnement du système.</p>
<p>La sauvegarde des événements (par exemple sous forme de JdB) devra être consultable en temps réel et à postériori. Pour le temps réel un système d’alerte sera mis en place pour que les opérateurs puissent corriger rapidement les problèmes rencontrés.</p> PyROS - Story #45115 (New): REQ-035 SURETE_130 Maintenance à distancehttps://forge.in2p3.fr/issues/451152021-05-12T10:17:55ZPallier Etienne
<p>Le système devra être opérable à distance et s’interfacer avec PyRos. Au niveau des pannes logicielles, tout doit pouvoir être géré à distance par les équipes dédiées en métropole. Tout ce qu’il est possible d’effectuer à distance doit l’être, ce qui implique que le système doit être pensé de manière à pouvoir tester et débugger des fonctions à distance avec le moins d’intervention humaine sur site.</p>
<p>Le système doit être opérable à distance et les pannes légères doivent pouvoir être réglées sans intervention humaine sur site.</p> PyROS - Story #45114 (New): REQ-021 FONC_020 Saut en déclinaison entre chaque imagehttps://forge.in2p3.fr/issues/451142021-05-12T10:15:13ZPallier Etienne
<p>Un saut en déclinaison de quelques pixels entre chaque image peut aider à faire la différence entre un pixel chaud et un artefact du senseur. Ce saut en déclinaison n’est utile que dans le cas de l’utilisation en champ large car en champ étroit, la multiplicité des capteurs permet de faire la différence.<br />Il arrive sur les TAROT actuels dans le cas des satellites, mais également dans le cas des observations astronomiques qu’on hésite entre la détection d’un nouvel objet et un artefact du senseur.</p> PyROS - Story #45113 (New): REQ-024 FONC_080 Directions et trajectoires accessibleshttps://forge.in2p3.fr/issues/451132021-05-12T10:11:53ZPallier Etienne
<p>Les télescopes doivent pouvoir pointer toutes les élévations entre 0 et 180 degrés pour tous les angles horaires. Pyros présentera via une API la plage d’angles horaires utilisables.<br />La poursuite des objets défilants nécessite la bonne connaissance de la mécanique du système pour écrire les extraits d’éphémérides de pointage sur lesquels seront basées les poursuites.</p> PyROS - Story #45112 (New): REQ-023 FONC_030 Délai de reprogrammationhttps://forge.in2p3.fr/issues/451122021-05-12T10:00:31ZPallier Etienne
<p>Après chaque réception de requête, le télescope TNC met à jour sa programmation et la met en œuvre dès la fin de l’observation en cours.<br />Un temps court de reprogrammation est utile pour répondre aux demandes urgentes et programmer rapidement des poursuites des objets nouvellement découverts.</p> PyROS - Story #45103 (New): REQ-033 SURETE_050 Prise en compte de la météohttps://forge.in2p3.fr/issues/451032021-05-11T16:48:16ZPallier Etienne
<p>Le bâtiment devra également en cas de conditions météorologiques défavorables, les détecter et demander sa fermeture dans le but de préserver l’intégrité des instruments. Ce bâtiment doit permettre la protection du système de mesure. Il faudra intégrer l’équivalent d’une station météo temps réel permettant d’autoriser la fermeture ou l’ouverture du bâtiment pour les observations. Une recherche d’optimisation des paramètres au plus juste en fonction des facteurs extérieurs sera mise en place afin d’obtenir les meilleures performances possibles.</p>
<p>L’intégrité des instruments de mesure doit toujours être préservée.</p> PyROS - Story #45102 (New): REQ-029 Métadonnées des imageshttps://forge.in2p3.fr/issues/451022021-05-11T16:42:46ZPallier Etienne
<p>Cette story est constituée par les deux exigences FONC_170 et FONC_180 de TAROT NC</p> PyROS - Story #45101 (New): REQ-034 SURETE_080 Coupure électriquehttps://forge.in2p3.fr/issues/451012021-05-11T16:40:37ZPallier Etienne
<p>Le système doit pouvoir se mettre automatiquement en position de sécurité dans le cadre d’une coupure du réseau électrique prolongée.</p>
<p>Le télescope ne doit pas subir de dommage liés à une coupure de courant.</p> PyROS - Story #45100 (New): REQ-026 Plage d'angles horaires et ligne d'horizonhttps://forge.in2p3.fr/issues/451002021-05-11T16:38:43ZPallier Etienne
<p>Pyros présentera via une API la plage d’angles horaires utilisables sur le télescope.<br />Il présentera également une ligne d'horizon indiquant les élévations les plus basses observables pour chaque angle horaire (par une table d'interpolation)</p> PyROS - Story #45099 (New): REQ-037 SURETE_140 Vérification du fonctionnement du télescope : cali...https://forge.in2p3.fr/issues/450992021-05-11T16:35:41ZPallier Etienne
<p>Le titulaire devra fournir au CNES une procédure de vérification de bon fonctionnement à mettre en place dans les requêtes Pyros concernant les différents tests à effectuer pour s’assurer que le télescope fonctionne dans les conditions optimales (focalisation, alignement…). Il devra préciser dans sa procédure à quelle fréquence et comment ces vérifications doivent être effectuées.</p>
<p>La mise en place d’une procédure de vérification de configuration et de calibration du télescope permet de s’assurer d’une prise d’image optimale chaque nuit d’observation.</p> PyROS - Story #45098 (New): REQ-030 SURETE_30 Répartition des nuitshttps://forge.in2p3.fr/issues/450982021-05-11T16:27:24ZPallier Etienne
<p>Un accord pourra être mis en place entre le CNES et l’IRAP (CNRS) pour permettre une utilisation partagée du télescope. Si cela est le cas, cet accord stipulera la répartition du temps d’utilisation du télescope entre les différents utilisateurs. Etant donné que l’utilisation pour des besoins scientifiques par l’IRAP est basé sur un système d’alerte, une mise en place de priorité d’utilisation devra être spécifiée et discutée entre les deux parties. Cette gestion des priorités devra être prise en compte en parallèle dans l’amélioration de PyRos.</p>
<p>La définition de cet accord déterminera la façon dont les priorités seront prises en compte dans PyRos, et la gestion du télescope pour le choix des requêtes envoyées par le CNES via OSMOSE.</p> PyROS - Story #45097 (New): REQ-028 FONC_180 Métadonnées pour les poursuites LEO (optionnelle)https://forge.in2p3.fr/issues/450972021-05-11T16:25:49ZPallier Etienne
<p>Dans les métadonnées des séries d'images LEO, insérer les informations nécessaires pour calculer la direction de pointage de chacune des images.<br />Ceci est utile pour extraire les mesures de direction dans le cas où le nombre d'étoiles détectées est trop faible pour effectuer la calibration astrométrique dans chacune des images. Ceci permettrait la "navigation à l'estime" entre les images qui permettent une mesure absolue de la direction de l'objet.</p> PyROS - Story #45096 (New): REQ-027 FONC_170 Métadonnéeshttps://forge.in2p3.fr/issues/450962021-05-11T16:21:30ZPallier Etienne
<p>Les images produites doivent être accompagnées de métadonnées indiquant les conditions de la prise de vue. En particulier : position du capteur, modèle du tube, modèle et numéro de série de la caméra, focale, nombre de pixels en X et Y, taille des pixels, position du centre optique dans la matrice de pixels, rotation de la caméra, direction de pointage, informations de datation, température, pression et humidité).<br />Plus la caractérisation à priori de la prise de vue est précise et complète, plus son interprétation sera facilitée.</p> PyROS - Story #45095 (New): REQ-018 Cloisonnement des donnéeshttps://forge.in2p3.fr/issues/450952021-05-11T16:17:47ZPallier Etienne
<p>L’accès au réseau TAROT nécessitera une authentification.<br />Le paramétrage de l’ordonnanceur, la liste des requêtes soumises et leur durée sera publique.<br />Le contenu des requêtes, les images et les mesures extraites ne seront consultables que par les utilisateurs autorisés par l’émetteur de la requête.</p> PyROS - Story #44817 (New): REQ-202 Deux types de connexion utilisateurs (LDAP ou sans)https://forge.in2p3.fr/issues/448172021-04-27T11:53:20ZPallier Etienne
<p>via un LDAP<br />ou sans LDAP<br />(mais pas les 2 à la fois)</p> PyROS - Story #44816 (New): REQ-201 Définir une esthétique Tarothttps://forge.in2p3.fr/issues/448162021-04-27T11:52:01ZPallier EtiennePyROS - Story #44815 (New): REQ-015 Ajustement dynamique des quotas utilisateurshttps://forge.in2p3.fr/issues/448152021-04-27T11:49:54ZPallier Etienne
<p>Dans le système actuel, chaque utilisateur a une priorité qu’il garde constante tant qu’il n’a pas atteint son quota et qu’il perd lorsque son quota est atteint. Ceci oblige les utilisateurs à forte priorité à adapter leur rythme de soumission aux besoins des utilisateurs à faible priorité afin qu’ils puissent utiliser leurs créneaux.<br />Afin de permettre une gestion plus dynamique, prévoir un module ajustant le « quota dynamique » des utilisateurs en fonction du taux de satisfaction de leur « quota statique » fixé au départ.<br />Ainsi, parmi deux utilisateurs de priorité égale, chaque utilisateur se voit attribuer une pénalité proportionnelle au temps qui lui a été attribué sur un horizon à choisir divisée par son quota. C’est l’utilisateur le moins pénalisé qui a le droit de placer une requête. On recalcule les pénalités après chaque soumission de requête.<br />Pour ne pas pénaliser les utilisateurs qui ont soumis des requêtes à des dates ou les télescopes ne se sont pas ouverts, on comptabilise le temps de toutes les requêtes positionnées dans le futur, mais pour les requêtes positionnées dans le passé on ne compte que celles qui ont été satisfaites.<br />Afin de tenir compte de plusieurs nuits d’observation sans pour autant bloquer les utilisateurs soumettant régulièrement des requêtes, on peut introduire un taux de décroissance de la prise en compte du temps consommé pour les dates du passé.<br />Exemple d’implémentation :</p>
<ul>
<li>Pour chaque utilisateur :</li>
<ol>
<li>Un compteur « temps consommé les nuits précédentes »</li>
<li>Un compteur « temps consommé la nuit courante »</li>
<li>Un compteur « temps programmé dans le futur » (fin de la nuit ou nuits suivantes)</li>
</ol></li>
</ul>
<ul>
<li>A chaque soumission de requête, le « temps programmé dans le futur » est incrémenté de la durée de la requête »</li>
</ul>
<ul>
<li>A chaque date de fin d’exécution de requête, le « temps programmé dans le futur » est décrémenté de la durée de cette requête et si la requête a été satisfaite, le « temps consommé la nuit courante » est incrémenté de la durée de la requête.</li>
</ul>
<ul>
<li>A chaque fin de nuit, le temps consommé la nuit courante est ajouté au temps consommé les nuits précédentes puis remis à zéro.</li>
</ul>
<ul>
<li>Le temps consommé les nuits précédentes est multiplié par le facteur de décroissance. Le taux de décroissance est 2-1/t avec t la demi-vie de la prise en compte du temps.<br />Exemple de d’utilisation de ce mécanisme :</li>
<ol>
<li>Pour une demi-vie de 1 jours, le temps consommé la dernière nuit compte pour 50% de la somme ; le temps de l’avant dernière nuit pour 25% ; le temps de la dernière semaine pour 99% de la somme.</li>
<li>Si deux utilisateurs ont chacun un quota de 50%, un utilisateur qui cède sa part à l’autre utilisateur pendant une nuit aura droit à 75% la nuit suivante ; un utilisateur qui cède sa part 2 nuits consécutives aura droit à 87% la nuit suivante et un utilisateur qui cède sa part 6 nuits aura droit à 99% la nuit suivante.</li>
<li>Un utilisateur qui aurait cédé sa part depuis la nuit des temps n’aurait jamais droit à plus d’une nuit dédiée, les proportions se trouvant rétablies dès le lendemain.</li>
<li>Pour une demi-vie de n jours, un utilisateur absent depuis longtemps peut utiliser jusqu’à n nuits consécutives à 100% avant le rétablissement des quotas initiaux.</li>
</ol></li>
</ul>
<p>Ce système permettrait de gérer l’équilibre entre les observations d’événements célestes transitoires qui sont intermittentes et non programmées et les observations de surveillance de l’espace et autres projets scientifiques à l’activité plus régulière. Ça permettrait également aux utilisateurs ayant un quota faible de positionner plus facilement des observations entre les observations des utilisateurs à gros quota.</p> PyROS - Story #44814 (New): REQ-101 Logshttps://forge.in2p3.fr/issues/448142021-04-27T11:47:29ZPallier Etienne
<p>On doit logger les connexions FTP, les actions et erreurs des agents</p> PyROS - Story #44813 (New): REQ-123 Architecture extensible et Extensions privatisableshttps://forge.in2p3.fr/issues/448132021-04-27T11:43:29ZPallier Etienne
<p>Programmes externes indépendants, tels que Grenouille, ou Triton…</p>
<p>Solution proposée :<br />Extension par plugins :<br />Une partie PyROS core publique<br />une partie PyROS plugins privée (code spécifique)</p>
<p>Plugin = Agent</p>
<p>Commande de création dédiée (PYROS create-plugin myplugin) qui créera un squelette du plugin (squelette Agent, table, Model PluginMyPlugin, vue)<br />On enregistre le nouveau plugin via la page de configuration (en indiquant son chemin absolu, qui doit être hors pyros)</p> PyROS - Story #44812 (New): * REQ-200 FOR TAROT NETWORK INTEGRATIONhttps://forge.in2p3.fr/issues/448122021-04-27T11:18:46ZPallier EtiennePyROS - Story #44811 (New): * REQ-100 FROM CCTP TAROT-NC & MEETINGShttps://forge.in2p3.fr/issues/448112021-04-27T11:17:46ZPallier EtienneAtrium - IPNO - Story #44732 (New): Fermeture du projet ?https://forge.in2p3.fr/issues/447322021-04-21T07:38:12ZGenolini Bernard
<p>Bonjour,<br />Je regarde la liste de mes projets dans la Forge, et je trouve celui-ci, qui mériterait d'être clos.</p>
<p>Merci d'avance !</p> PyROS - Story #44719 (New): REQ-010 Ordonnancement des requêteshttps://forge.in2p3.fr/issues/447192021-04-20T10:49:01ZPallier Etienne
<p><strong>Origine</strong><br />utilisateurs du réseau TAROT</p>
<p><strong>Besoin</strong><br />Ordonnancement des requêtes :<br />. Le module qui fait l’ordonnancement de requêtes destinées à un télescope doit tourner sur le site de ce télescope. Ceci limite l’impact d’une panne sur le système central de supervision ou de la liaison réseau entre le système de supervision et le télescope.<br />. Dans la mesure ou les requêtes sont décalables dans le temps, le module d’ordonnancement doit limiter les temps morts entre les requêtes.<br />Le module d’ordonnancement doit être réactivée à chaque modification de la liste des requêtes à traiter, des priorités ou des quotas des utilisateurs. On pourra fixer un délai minimal entre deux réévaluations de la planification afin d’éviter de surcharger les ressources informatiques.<br />Chaque utilisateur a un ou plusieurs couples « priorité ; quota ». Plusieurs utilisateurs peuvent avoir un même niveau de priorité. L’ordonnanceur satisfait prioritairement les demandes de série du niveau de priorité le plus élevé à concurrence du quota de chaque utilisateur. Il passe ensuite au niveau de priorité suivant.</p> PyROS - Story #44718 (New): ** REQ-025 AJOUT TNChttps://forge.in2p3.fr/issues/447182021-04-20T10:45:06ZPallier EtiennePyROS - Story #44717 (New): ** REQ-022 TAROT NChttps://forge.in2p3.fr/issues/447172021-04-20T10:44:43ZPallier EtiennePyROS - Story #44716 (New): ** REQ-071 AJOUT OSMOSEhttps://forge.in2p3.fr/issues/447162021-04-20T10:44:18ZPallier EtiennePyROS - Story #44715 (New): ** REQ-065 AJOUT UPGRADEhttps://forge.in2p3.fr/issues/447152021-04-20T10:43:32ZPallier EtiennePyROS - Story #44713 (New): ** REQ-020 CCTPhttps://forge.in2p3.fr/issues/447132021-04-20T10:42:46ZPallier Etienne
<p>CCTP du contrat CNES-CNRS sur PyROS</p>