Table of Contents

Supervision REFIMEVE

L'outil de supervision REFIMEVE a plusieurs enjeux impliquant des acteurs différents :

Administration technique

Administration de la base de données

Page admin de supervision

L'administration client consiste à gérer la base de données de supervision. Elle est composée d'un ensemble d'objets permettant de décrire le réseau REFIMEVE.

La base de données de Supervision est dite relationnelle. Un objet peut donc être lié à un ou plusieurs objets qui doivent donc, si nécessaire, être créés avec l'objet initial. Mais ces objets liés peuvent eux-mêmes être liés à d'autres… La procédure de mise à jour de la base de données peut donc vite conduire à avoir de nombreux onglets ouverts, ce qui n'est vraiment pas pratique..
Note : Une base de données de type NoSQL (MongoDB) simplifierait la phase de saisie, mais apporterait son lot de contraintes pour assurer la robustesse des informations saisies.
Pour cette raison, il est conseillé de créer les nouveaux objets dans l'ordre suivant :

Infrastructure

Définition : C'est l'objet le plus global dans la hiérarchie. Une infrastructure peut contenir un ou plusieurs (sous-)réseaux.
Exemples :

Liaisons : Aucune

Site

Définition : Un site représente un lieu géographique et structurel. Un site peut contenir un ou plusieurs noeuds.
Exemples :

Liaisons : Aucune

Network

Définition : La notion de réseau désigne un ensemble de noeuds qui dépendent d'un même point d'entrée. Un sous-réseau n'a pas de source de signal propre.
Exemples:

Liaisons :

Node

Définition : Un noeud est un lieu (une pièce) dans lequel transitent les signaux REFIMEVE. Dans un noeud, on trouve des modules et des instruments de mesure.
Exemples :

Liaisons:

Technique

Définition : Une technique représente une méthode/technologie matérielle/logicielle de transfert Temps/Fréquence.
Exemples :

Liaisons : Aucune

File access

Définition : Cet objet contient les métadonnées nécessaires pour accéder à un fichier de mesurandes en lecture (serveur hôte, chemin du répertoire, format du fichier, …). Il permet l'automatisation de la lecture des fichiers.
Liaisons : Aucune

Measuring Instrument

Infos

Définition : Un instrument de mesure désigne un appareil permettant l'acquisition de données (mesures/mesurandes). Ces données mesurées sont stockées dans des fichiers dont on connaît la localisation et la manière de les lire grâce aux métadonnées présentes dans les file access.
Exemples :

Liaisons :

Créer un objet


Chaque nouvel instrument newInstrument s'accompagne d'un serveur d'acquisition de données serverAcq avec une synchronisation NTP de son horloge locale localClock. Pour cette raison, on crée d'abord la logique NTP si ce n'est pas déjà fait, avant de créer newInstrument:

Maintenant que la logique NTP est en place, vous avez tout en main pour créer l'instrument newInstrument

Mesurand

Infos

Définition : Une mesurande désigne n'importe quelle donnée acquise - par un instrument de mesure- utile dans le cadre de REFIMEVE.
Exemples :

Liaisons :

Créer un objet

Chaque nouvelle mesurand newMesurand s'accompagne d'un instrument newInstrument. On doit donc créer newInstrument d'abord.
output_value_column : starting from 0 (python-wise)

Counter

Définition : Un compteur est un type d'instrument de mesure mesurant des données Temps/Fréquence.
Exemples:

Liaisons :

Module

Infos

Définition : Un module est un terme générique pour désigner tout système matériel appartenant à un réseau de transfert Temps-Fréquence en lien avec REFIMEVE : (ré)génération / comparaison / transmission / étalon / …
On peut dire qu'un module est un intermédiaire dans un réseau technique possèdant une sortie mesurée (délai, offset, sortie fréquence, sortie temps, …).
Exemples :

Liaisons :

Créer un objet

maintainer_id: ID of the object in the SI of the external contractor if any.
Example : ID of RLS Lyon DC4 in iXBlue SI is 26

Campaign Request

Définition :

Campaign

Infos

Définition : Une campagne désigne un intervalle de temps pendant lequel les utilisateurs peuvent s'attendre à avoir un signal reçu des plus performants en stabilité et en précision du fait d'une attention accrue des équipes du SYRTE. Une campagne est souvent synonyme de comparaisons d'horloges atomiques|optiques.
Exemples

Liaisons :

Clock Comparison

Définition : Une comparaison d'horloges désigne un couple de modules (horloges atomiques|optiques) dans le cadre d'une campagne. Pour pouvoir réaliser une comparaison entre deux horloges A et B, il faut avoir un jeu de comparateurs qui, mis dans le bon ordre, forment une chaîne allant de A à B.
Cas explicatif : Le seul intérêt de cet objet est de déclarer des comparaisons à effectuer automatiquement. Exemples :

Liaisons :

Comparator Output

Infos

Définition : Un comparateur désigne une mesure entre deux modules successifs. Cette mesure peut être un ratio, une différence, une modulation, … Cela dépend de la nature des modules dans le camparateur.
Exemples:

Liaisons :

Créer un objet

Le point d'attention est : qui est moduleA et qui est moduleB.
La nomenclature adoptée depuis la publication du formalisme défini par Jérôme Lodewyck et al. (https://hal.science/hal-02997778) est telle que : COMPARATOR_LABEL = ModuleB-ModuleA.
Exemple :

Infos

Définition : Un lien désigne une connexion - physique, immatérielle ou conceptuelle - entre deux noeuds. A un lien on associe :

Exemples :

Liaisons :

Créer un objet

Le point d'attention ici est : qui est from_node et qui est to_node.
Le sens à donner dépend du type d'information transmise :

Exemples:

Infos

Définition : Cet objet rassemble les propriétés des liens qui varient dans le temps.
Cas explicatif : à cause d'une défaillance technique, la station RLS-A à Lyon est remplacée par la RLS-B. Pour autant, le lien optique “Lyon-Grenoble” reste le même. Ainsi on ne modifie pas l'objet "lien" mais on ajoute un objet liens info qui va décrire ce changement dans le temps.
Exemples :

Liaisons :

Créer un objet

Le point d'attention ici est : qui est from_module et qui est to_module.
Le sens à donner dépend du type d'information transmise :

Exemples:

Définition : Cet objet représente le système de stabilisation (mesure Freelink) et de vérification (mesure E2E) associé à un ensemble de liens optiques fibrés pour le transfert de fréquence via REFIMEVE.
Exemples :

Liaisons :

Two Way

Définition : Cet objet représente, comme son nom l'indique, le système de Two Way entre deux Modules.
Exemples :

Liaisons :

Paramétrage des filtres par défaut d'un observable

A chaque observable doit être associé un fichier .yml sur le serveur de calcul contenant la liste des méthodes de filtrage par défaut pour évaluer la qualité de la trace fournie, ainsi que les paramètres pour chacune d'entre elles. Ces fichiers sont présents dans le dossier /opt/palantir/conf/filters/

Pour un observable donné, on trouve sous forme de liste les méthodes de filtrage et la valeur des paramètres sous l'attribut “methods” : 

- carrier_value: 194.4e12
  counting_value: 21.4e6
  description: Default config
  end: null
  label: Default
  methods:
  - label: palantir.filters.fat_filter.FatFilterMethod
    parameters:
      filter_fat: 8e-15
  - label: palantir.filters.good_periods.GoodPeriodsMethod
    parameters:
      cut_f: 1e-16
      cut_mean_factor: 2
      cut_q_factor: 3
      cut_rstd_q_factor: 10000
      filter_a: 3e-15
      window_mean: 9
      window_rmean_q: 271
      window_rstd_q: 1000
      window_std: 200
  - label: palantir.filters.good_periods.RestrictMethod
    parameters:
      cut_f: 1e-16
      cut_mean_factor: 30
      window_mean: 1000
  - label: palantir.filters.cycle_slips.CycleSlipsMethod
    parameters:
      filter_m_factor: 6e-15
      window_rm: 5
  multiplication_factor: 1
  start: null
  window_dedrift: 100
  alerts:
  - label: palantir.filters.differential.DiscrepancyMethod
    critical: True
    parameters:
      filter_fat: 10

Pour modifier les paramètres de filtre par défaut: il faut éditer ces fichiers directement.

Pour modifier les paramètres de filtre dans le code, à la volée : voir documentation utilisateur de Palantir

Paramétrage des alertes par défaut d'un observable

A chaque observable doit être associé un fichier .yml sur le serveur de calcul contenant la liste des types d'alerte à vérifier, ainsi que les paramètres pour chacune d'entre elles. Ces fichiers sont présents dans le dossier /opt/palantir/conf/filters/

Pour un observable donné, on trouve sous forme de liste les méthodes de filtrage et la valeur des paramètres sous l'attribut “alerts” : 

- carrier_value: 194.4e12
  counting_value: 21.4e6
  description: Default config
  end: null
  label: Default
  ...
  alerts:
  - label: palantir.filters.differential.DiscrepancyMethod
    critical: True
    parameters:
      filter_fat: 10

Pour modifier les paramètres d'alerte par défaut: il faut éditer ces fichiers directement.