IN2P3-Forge: Issueshttps://forge.in2p3.fr/https://forge.in2p3.fr/favicon.ico?16780521162021-05-12T10:47:07ZIN2P3-Forge
Redmine PyROS - Story #45160 (New): REQ-012 PYROS-10 limiter les temps morts entre requêteshttps://forge.in2p3.fr/issues/451602021-05-12T10:47:07ZPallier Etienne
<p><strong>Origine</strong><br />Utilisateurs TAROT</p>
<p><strong>Besoin</strong><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.</p>
<p><strong>Finalité</strong><br />Augmenter la capacité de production des télescopes</p>
<p><strong>Test</strong><br />Lancement de plusieurs requêtes à des dates très proches --> Consultation de la programmation<br />Annulation d'une requête --> consultation de la reconfiguration de la programmation après annulatio</p> PyROS - Story #45159 (New): REQ-003 Interface avec les données CNRS de manière authentifiéehttps://forge.in2p3.fr/issues/451592021-05-12T10:46:09ZPallier Etienne
<p>En tant que responsable du système OSMOSE, j'ai besoin que les échange avec le CNRS se fassent de manière authentifiée afin de garantir une meilleure sécurité du système.</p>
<p>Ceci sera validé par la mise en place et la démonstration d'un accès authentifié avec le CNRS</p> PyROS - Story #45158 (New): REQ-006 Notification de changement d'état d'une requêtehttps://forge.in2p3.fr/issues/451582021-05-12T10:45:45ZPallier Etienne
<p>En tant que responsable OSMOSE, j'ai besoin d'être notifié à chaque changement d'état d'une requête côté CNRS afin d'adapter ma planification en fonction de celle-ci.</p>
<p>Ceci sera validé par une démonstration de la solution.</p> PyROS - Story #45156 (New): REQ-004 POC GTRS et websockethttps://forge.in2p3.fr/issues/451562021-05-12T10:44:46ZPallier Etienne
<p>EXIGENCE LIÉE A OSMOSE-1686</p>
<p>En tant que responsable OSMOSE, j'ai besoin de connaître l'effort et le gain attendu par la mise en place de websockets pour GTRS, afin de proposer une amélioration sur la fréquence de mise à jour des statuts envers les utilisateurs osmose.</p>
Cette story sera validée
<ul>
<li>par une maquette de téléchargement des fichiers s'appuyant sur une websocket (avec serveur web local simulant le serveur web du CNRS)</li>
<li>un GTRS fonctionnant "en temps réel" (intégrant directement le téléchargement ou en passant par incron)</li>
<li>un document de description de l'architecture à adapter côté OSMOSE et CNRS</li>
</ul>
<p>----<br />Ressources :</p>
<p>[<a class="external" href="http://shzhangji.com/blog/2017/07/15/log-tailer-with-websocket-and-python/">http://shzhangji.com/blog/2017/07/15/log-tailer-with-websocket-and-python/</a>]</p>
<p>[<a class="external" href="https://c-mh.fr/posts/websockets-en-php-plus-simple-qu-il-n-y-parait">https://c-mh.fr/posts/websockets-en-php-plus-simple-qu-il-n-y-parait</a>]</p>
<pre><code>[<a class="external" href="https://github.com/dunglas/mercure">https://github.com/dunglas/mercure</a>]</code></pre>
<pre><code>TODO : Compléter la DOD</code></pre> PyROS - Story #45155 (New): REQ-001 planification de tâches récurrenteshttps://forge.in2p3.fr/issues/451552021-05-12T10:44:13ZPallier Etienne
<p>Actuellement, toutes les requêtes OSMOSE sont envoyées à CADOR 19h en avance (tâche de planification). Le logiciel REPLICA sur CADOR planifie toutes les requêtes sur les télescopes.<br />Lorsque CADOR n'est pas accessible, REPLICA ne tourne pas donc les requêtes OSMOSE ne peuvent pas être planifiées. Cela peut entraîner des interruptions de production alors que les télescopes fonctionnent, lorsque CADOR n'est pas disponible pendant plus de 19h.</p>
<p>Le nouvel ordonnanceur doit pouvoir accepter des observations récurrentes avec une date de fin lointaine voire indéfinie. Ceci permettra au télescope de continuer à travailler sur les tâches de routine en cas de coupure réseau</p> PyROS - Story #45152 (New): REQ-068 ACCEPT_010 Plan de validation et d'essaihttps://forge.in2p3.fr/issues/451522021-05-12T10:42:40ZPallier Etienne
<p>Le titulaire rédigera le plan de validation et d’essais. Ce plan proposera une logique de validation s’appuyant selon le besoin sur des analyses et des tests. Le titulaire sera responsable de la mise en application de ce plan de validation. Il y aura deux validations. La première s’effectuera en métropole (endroit à définir), et la deuxième après l’installation en Nouvelle Calédonie du système de mesure</p> PyROS - Story #45151 (New): REQ-069 Plan de validation et d'essaihttps://forge.in2p3.fr/issues/451512021-05-12T10:42:11ZPallier Etienne
<p>Le titulaire rédigera le plan de validation et d’essais. Ce plan proposera une logique de validation s’appuyant selon le besoin sur des analyses et des tests. Le titulaire sera responsable de la mise en application de ce plan de validation. Il y aura deux validations. La première s’effectuera en métropole (endroit à définir), et la deuxième après l’installation en Nouvelle Calédonie du système de mesure</p> PyROS - Story #45150 (New): REQ-066 QUALIF_030 Exigencehttps://forge.in2p3.fr/issues/451502021-05-12T10:41:26ZPallier Etienne
<p>Les phases de qualification doivent montrer que le système répond bien à l’ensemble des exigences de la STB.</p> PyROS - Story #45149 (New): REQ-067 Qualification des exigenceshttps://forge.in2p3.fr/issues/451492021-05-12T10:41:02ZPallier Etienne
<p>Les phases de qualification doivent montrer que le système répond bien à l’ensemble des exigences de la STB.</p> PyROS - Story #45148 (New): REQ-063 Qualification opérationnellehttps://forge.in2p3.fr/issues/451482021-05-12T10:40:39ZPallier Etienne
<p>La qualification opérationnelle aura lieu sur le site du Calern. Elle durera 3 mois et aura lieu au second semestre 2022. Un plan de tests et de qualification sera développé avant les essais par le titulaire et validé par le CNES avant réalisation.</p>
<p>Un plan de test et de qualification est demandé au titulaire.</p> PyROS - Story #45147 (New): REQ-059 Qualification techniquehttps://forge.in2p3.fr/issues/451472021-05-12T10:40:12ZPallier Etienne
<p>Le logiciel PYROS sera utilisé pour la qualification technique de TAROT NC à partir de juin 2022.</p>
<p>Sa qualification technique sur simulateur de télescope ou autre télescope devra avoir été réalisée avant cette date.</p>
<p>Un plan de tests et de qualification sera développé avant les essais par le titulaire et validé par le CNES avant réalisation.</p> PyROS - Story #45146 (New): REQ-064 Déploiementhttps://forge.in2p3.fr/issues/451462021-05-12T10:39:46ZPallier Etienne
<p>L'équipe PYROS devra avoir terminé le déploiement sur TCA, TCH et TRE avant fin juin 2023.</p> PyROS - Story #45145 (New): REQ-062 QUALIF_020 Qualification opérationnellehttps://forge.in2p3.fr/issues/451452021-05-12T10:39:16ZPallier Etienne
<p>Qualification opérationnelle<br />La qualification opérationnelle aura lieu sur son site d’exploitation finale en Nouvelle Calédonie. Elle commencera en avril 2023 et durera 3 mois. Un plan de tests et de qualification sera développé avant les essais par le titulaire et validé par le CNES avant réalisation.</p>
<p>Un plan de test et de qualification est demandé au titulaire.</p> PyROS - Story #45144 (New): REQ-060 JUSTIF_010 Justification de la définitionhttps://forge.in2p3.fr/issues/451442021-05-12T10:38:45ZPallier Etienne
<p>Nous demandons au titulaire de fournir les rapports de tests effectués tout au long de la conception du système de mesure, ainsi que les rapports de conception. Le titulaire devra mettre en place un plan de justification de la définition regroupant toutes les données nécessaires à la compréhension et la vérification des différentes étapes de conception.<br />Ce plan de justification de la définition doit comprendre tous les éléments de calculs théorique, modélisation et les éléments expérimentaux ayant conduit à la conception et au développement du système de mesure.</p>
<p>Un plan de justification de la définition est demandé au titulaire.</p> PyROS - Story #45143 (New): REQ-061 Justification de la définitionhttps://forge.in2p3.fr/issues/451432021-05-12T10:37:55ZPallier Etienne
<p>Nous demandons au titulaire de fournir les rapports de tests effectués tout au long de la conception du logiciel PYROS, ainsi que les rapports de conception. Le titulaire devra mettre en place un plan de justification de la définition regroupant toutes les données nécessaires à la compréhension et la vérification des différentes étapes de conception.<br />Ce plan de justification de la définition doit comprendre tous les éléments de modélisation et les éléments expérimentaux ayant conduit à la conception et au développement du logiciel PYROS.</p>
<p>Un plan de justification de la définition est demandé au titulaire.</p> PyROS - Story #45142 (New): REQ-058 QUALIF_010 Qualification techniquehttps://forge.in2p3.fr/issues/451422021-05-12T10:37:21ZPallier Etienne
<p>La qualification technique aura lieu en métropole après sa fabrication. Elle s’effectuera surement sur le site de Aussaguel. La qualification sur le site en métropole commencera en juin 2022 et devrait durer 7 mois. Un plan de tests et de qualification sera développé avant les essais par le titulaire et validé par le CNES avant réalisation.</p>
<p>Un plan de test et de qualification est demandé au titulaire.</p> PyROS - Story #45141 (New): REQ-056 INTERFACE_010 Interfaçage avec PyROShttps://forge.in2p3.fr/issues/451412021-05-12T10:36:55ZPallier Etienne
<p>Le titulaire doit équiper le télescope du logiciel PyROS et de l'infrastructure informatique et réseau nécessaire à son bon fonctionnement en terme de performance, de fiabilité et de maintenabilité.<br />Les utilisateurs et administrateurs du télescope l'accèderont par le biais du logiciel PyROS dont la conception et le développement font l'objet d'une autre STB.</p> PyROS - Story #45140 (New): REQ-057 Interfaçage avec TAROT NChttps://forge.in2p3.fr/issues/451402021-05-12T10:36:20ZPallier Etienne
<p>Le titulaire doit se concerter avec l'équipe de développement TAROT NC afin de s'assurer que PyROS répondra à l'ensemble des besoins logiciels de TAROT NC.</p> PyROS - Story #45139 (New): REQ-054 Documentation et Formationhttps://forge.in2p3.fr/issues/451392021-05-12T10:35:49ZPallier Etienne
<p>Lors de la fourniture du logiciel PYROS, l'équipe de développement PYROS fournira<br />- une documentation à destination des utilisateurs de télescopes,<br />- une documentation à destination des administrateurs de télescopes,<br />- une documentation à destination des développeurs et mainteneurs de télescopes</p>
<p>Il organisera une session de formation des équipes CNES pour chacun de ces trois publics.</p> 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 #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 #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 #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 #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 #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 #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> Atrium - 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>