Fonctionnement informatique de Necam

DESCRIPTION

La caméra Necam (nov 2019) est une caméra CCD comportant un système de refroidissement autonome utilisant un cryocooler (CC) (fabricant Thales) ne nécessitant aucun apport d'azote liquide. Son prédécesseur Ecam, possédait un cryostat utilisant le même CCD, avec apport bi-journalier d'azote liquide.

Necam est composé de:

• Un cryostat sous vide comportant:
• un CCD 4k x 4k
• une sonde de température (CCD2)
• une sonde de température de rechange (CCD1)
• un système de régulation thermique , controlé par un régulateur (marque Lakeshore)
• un system d'absorption (charbon actif)
• Une machine à froid, le CryoCooler, dont l'élément essentiel est un moteur Stirling
• Un contrôleur du CryoCooler (CC) (marque Thales)
• Un contrôleur de température (marque Lakeshore)
• Un système de mesure du vide (contrôleur Pfeiffer avec gauge dpg109)
• Un réseau de capteurs de température PT100 lue par un Adam 6015
• 6 ventilateurs pour l'évacuation de la chaleur dégagée par le CC, dont les vitesses sont mesurées par un Adam 6051
• Un rack électronique comportant les éléments ci-dessus ainsi que les alimentations de puissance du cryostat et de l'électronique en générale

Modes de fonctionement

Architecture Informatique Necam

Voir ce shéma

Stratégie:

L'environnement de Necam est monitoré en permanence par le Local Control Unit glsserv (LCU: PC) et deux services lui sont dédiés: necam et necamfans.

Les fichiers services sont lus régulièrement par le programme necamwatch qui effectue les actions d'urgence en cas de problème et fourni un status du CC daté dans un fichier de status.

La machine principale de la station (glslogin1) surveille le contenu du fichier de status avec le programme necamstatuswatch. Cette machine envoie un mail d'urgence dans le cas où le status est périmé, ce qui signifie que necamwatch de fonctionne plus. Soit le LCU glsserv a une faille majeure soit un bug software empêche la terminaison de necamwatch.

Suivant les principes généraux des services, les services necam, sont insérés dans les bases de données SQL euler de La Silla et de Genève. Ces bases permettent un affichage des données sous forme graphique, l'affichage du monitoring en station sous forme de tableau de valeurs et l'envoi d'un rapport journalier.

GESTION DU CRYO-COOLER

Gestion automatique

La gestion de Necam en mode opération est automatique. Sous réserve que le programme de gestion necamwatch (lien vers l'algorithme) tourne sur glsserv.

Remarque: chaque action entreprise par necamwatch envoie un mail d'information

La gestion automatique:

• passe le CC en mode dégradé s'il n'y a pas de données récentes (<60[s])
• passe le CC en mode dégradé si il y a une surchauffe du CC, dans ce cas la consigne passe de -150 à -140 [degré]
• stoppe le CC s'il y a une surchauffe du CC alors que le mode dégradé est établi
• stoppe le CC en cas de perte de pression du cryostat
• passe le CC en mode dégradé si le CCD n'est pas stabilisé
• stoppe le CC si le CCD n'est pas stabilisé alors que le mode dégradé est établi
• fait un reset de l'acquisition des services en cas de données aberrantes

Stratégie: afin de limiter les risques de blocages liés à un programme de contrôle tournant "sans fin", necamwatch est lancé toutes les 2 minutes, il analyse la situation courante et prend des décisions de manière autonome. Afin de garder trace des actions en cours, necamwatch utilise des fichiers de status qui indiquent par leur présence l'attitude que doivent adopter necamwatch et les utilitaires Necam.

Ces fichiers sont:

• /tmp/INIB_SERVICE_NECAM: stoppe l'acquisition de données de service
• /tmp/INIB_CCD_STABILITY_CHECK: ne teste pas l'environnement, car le sytème est soit en train de démarrer soit en train de s'arrêter
• /tmp/INIB_HEATING_CRYO_COOLER_TO_DEGRADED_MODE: ne passe pas en mode dégradé, car le sytème est déjà en train de passer en mode dégradé

Le script necamwatch est lancé par le cron system et définit dans la crontab de root sur glsserv (extrait de la crontab):

[root@glsserv ~]# crontab -l
*/2 * * * * /opt/t4/beta/scripts/necamwatch >> /gls/data/services/MAINTENANCE/necam/necamwatch.log 2>&1

necamwatch fourni un statut comprenant un temps unix, un texte de statut et un delta-T à la consigne du CCD dans le fichier $TDATA/services/MAINTENANCE/necam/necamwatch.log qui a cette apparence:

1585660441.713717 necamwatch: ALL OK (delta = 0 [deg])
1585660561.717635 necamwatch: ALL OK (delta = 0 [deg])
1585660681.824976 necamwatch: ALL OK (delta = -0.0109999999999957 [deg])
1585660801.800805 necamwatch: ALL OK (delta = -0.0109999999999957 [deg])
1585660922.493219 necamwatch: ALL OK (delta = 0 [deg])
1585661041.422368 necamwatch: ALL OK (delta = 0 [deg])
1585661161.380026 necamwatch: ALL OK (delta = 0 [deg])

Ce fichier est sur le serveur de disque SynologyCluster. Accessible de tout autres ordinateurs de La Silla.

La surveillance du bon fonctionnement de necamwatch et de glsserv se fait en vérifiant le dernier temps Unix de la dernière ligne de status de ce fichier.

Cette surveillance est faite toutes les 2 minutes par le script necamstatuswatch qui est lancé par le cron system et définit dans la crontab de root sur glslogin (extrait de la crontab):

glslogin1:~# crontab -l
*/2 * * * * /opt/t4/beta/scripts/necamstatuswatch > /gls/data/services/MAINTENANCE/necam/necamstatuswatch.log 2>&1 

necamstatuswatch envoie un mail lorsque le fichier de statut est plus vieux de 3 minutes. Tant que le problème n'est pas résolu, ce mail est renvoyé chaque 30 minutes.

necamstatuswatch a également un fichier de log d'une ligne qui lui n'est testé que manuellement.

Commandes de gestion manuelles

La gestion de Necam se fait par l'intermédiaire de commandes tapées dans un terminal dans le monde Linux.

Attention ces commandes se lancent uniquement sur glsserv car une partie du hardware est accédé par des liaisons liaisons série dont les drivers sont uniquement sur cette machine

D'un manière générale, il est préférable de connaitre le comportement de ces commandes avant de les lancer. Les commande se lancent sous le nom de l'utilisateur. Certaines se lance en mode setuid root car elles accèdent les sémaphores ou les fichiers services crée par root.

Fichiers de log: dès nov 2020, toutes les commandes ont un fichier de log mensuel, nommé comme la commande sous $TDATA/services/MAINTENANCE/necam/

Suivre les liens pour visualiser l'organigramme

SERVICES

A l'instar des autres services de la station Euler, les senseurs et paramètres de Necam sont monitorés 24h/24 à différentes fréquences et leurs valeurs stockées dans des fichiers appelé fichier service de type rdb (Ascii file, tab separated values). Necam en possède 2:

• $TDATA/services/necam/necam_<YYYYMM.rdb> 5 [mesures/minute] pour senseurs et paramètres
• $TDATA/services/necam/necamfans_<YYYYMM.rdb> 6 [mesures/heure] pour les vitesses des ventilateurs de refroidissement

Le relevé de ces valeurs est realisé par 2 scripts lancés par le cron system et définit dans la crontab de root sur glsserv (extrait de la crontab):

[root@glsserv ~]# crontab -l
* * * * *    /opt/t4/beta/scripts/service_necam     >> /gls/data/services/MAINTENANCE/necam/service_necam.log 2>&1
*/10 * * * * /opt/t4/beta/scripts/service_necamfans >> /gls/data/services/MAINTENANCE/necam/service_necamfans.log 2>&1

Note: service_necam est lancé chaque minute, mais ce script lance 5 fois la commande

/home/weber/miniconda3/bin/python /opt/t4/beta/scripts/necam.py >> <fichier_service>

Table Necam

Table Necamfans

Remarque: l'environnement fortement magnétique du CC conjointement avec la position du ventilateur No 4 semble influencer la vitesse de ce dernier. Pas de solution à priori.

Visualisation des services

L'utilitaire java meulplot permet la visualisation des services.

L'usage de cet utilitaire le plus aisé est d'établir une connexion avec x2go sur glslogin1.ls.eso.org (ou glslogin2) et lancer:

meulplot

ACTIONS D'URGENCE

Perte de glsserv

glsserv est responsable de la gestion des services et du management automatique de Necam. Une panne de glsserv laisse un système non contrôlable dont les températures de fonctionnement sont inconnues.

La première action est de s'assurer que glsserv ne peut pas être redémarré.

Dans le cas d'une perte confirmée de glsserv:

Les 2 Adams responsables de la lecture des températures externe du cryostat et des vitesses des ventilateurs peuvent être lus depuis une autre machine (type LCU) par un accès direct à leur IP. Les températures externes du CC sont certainement les valeurs les plus importantes pouvant découler sur un arrêt du CC en cas de surchauffe.

Des températures inférieures à 50[d] sont considérées comme normales, entre 50 et 60. Un sérieux suivit s'impose.

ATTENTION des valeurs supérieures à 60[degré] demandent l'arrêt du CC

Températures du cryostat; l'information donne les températures de 4 PT100 disposées sur la structure du CC.

[weber@glscora ~]$ Nadam 
1585565270.237936 We work in the Swiss telescope At La Silla
chan[ 0 ]  =  -19.93057145037003  [deg]
chan[ 1 ]  =  150.0  [deg]
chan[ 2 ]  =  19.61776150148775  [deg]
chan[ 3 ]  =  14.057373922331578  [deg]
chan[ 4 ]  =  37.66613260090028  [deg]
chan[ 5 ]  =  150.0  [deg]
chan[ 6 ]  =  150.0  [deg]

Rem: les valeurs à 150.0[deg] sont les entrées sans capteurs. chan[0]=Rad_shield, chan[2]=CC_Up, chan[3]=CC_down, chan[4]=CC_Head

Vitesse des ventilateurs; l'information donne le temps unix, la date et les 6 vitesses en tours/minutes. Le 4eme ventilateur est connu pour avoir une vitesse anormale.

[weber@glscora ~]$ Necamfans
1585565087	20200330-07:44:47	 9810	 9750	 9990	 2727	 9690	 9510

L'accès aux contrôleurs Thales, Lakeshore et Pfeiffer demande un effort software afin d'installer les drivers séries sur d'autres LCUs. Fondamentalement pas compliqué, mais pas fait à ce jour.

Arrêt manuel du cryocooler

Mettre l'interrupteur du CC sur OFF

ANNEXE: SOURCES DES PROGRAMMES

Les commandes de gestion sont principalement écrites en perl et python, et Nlakeshore historiquement est écrit en C.

Le scripts python sont lancés par des scripts interfaces type csh permettant d'éviter de taper la commande python (/home/weber/miniconda3/bin/python)

Remarque, on utilise miniconda3 sur les LCUs et anaconda3 sur les Workstations, ceci solutionne les problèmes d'architectures.

Une petite librairie necam_utilities.pm contient des fonctions communes au scripts Perl N*_CC.pl

LOGFILE

Afin d'obtenir les log des commandes, la solution (la plus simple sous Unix) est de passer par un scripts interface qui redirige les sorties vers un fichier de log nommé comme la commande sous $TDATA/services/MAINTENANCE/necam/

necamwatch

cron ->
  (Link) /opt/t4/beta/scripts/necamwatch -> 
  (code) /opt/t4/beta/src/weber/necam/necamwatch.pl -> 
  (run)  Ndegrad_CC, Nstop_CC, Nreset_CC, sendmail 
  (use)  necam_utilities.pm

necamstatuswatch

cron ->
  (Link) /opt/t4/beta/scripts/necamstatuswatch -> 
  (code) /opt/t4/beta/src/weber/necam/necamstatuswatch.pl -> 
  (run)  sendmail

service_necam

cron -> 
  (run) /opt/t4/beta/scripts/service_necam -> 
  (link) /opt/t4/beta/src/weber/services/necam/service_necam.csh -> 
  (code) /opt/t4/beta/scripts/necam.py 
         (import necam_adam_ctrl, pythales, pydpg109)

service_necamfans

cron -> 
  (run)  /opt/t4/beta/scripts/service_necamfans -> 
  (link) /opt/t4/beta/src/weber/services/necam/service_necam.csh -> 
  (code) /opt/t4/beta/scripts/necamfans.py 
         (import pynecamfans)

NStart_CC

(Link) /opt/t4/beta/bin/$OPSYS/Nstart_CC -> 
(suid) /opt/t4/beta/src/weber/necam/Nstart_$OPSYS ->
(code) /opt/t4/beta/src/weber/necam/Nstart_CC.c -> 
(run)  /opt/t4/beta/src/weber/necam/Nstart_CC.csh -> 
(code) /opt/t4/beta/src/weber/necam/Nstart_CC.pl -> 
(run)  Nthales, Lakeshore, sendmail 
(use)  necam_utilities.pm

NStop_CC

(Link) /opt/t4/beta/scripts/Nstop_CC -> 
(code) /opt/t4/beta/src/weber/necam/Nstop_CC.csh -> 
(code) /opt/t4/beta/src/weber/necam/Nstop_CC.pl -> 
(run)  Nthales, sendmail 
(use)  necam_utilities.pm

Ndegrad_CC

(Link) /opt/t4/beta/scripts/Ndegrad_CC -> 
(code) /opt/t4/beta/src/weber/necam/Ndegrad_CC.csh -> 
(code) /opt/t4/beta/src/weber/necam/Ndegrad_CC.pl -> 
(run)  Nthales, sendmail  
(use)  necam_utilities.pm

Nreset_CC

 
(Link) /opt/t4/beta/bin/$OPSYS/Nreset_CC -> 
(suid) /opt/t4/beta/src/weber/necam/Nreset_CC_$OPSYS ->
(code) /opt/t4/beta/src/weber/necam/Nreset_CC.c -> 
(run)  /opt/t4/beta/src/weber/necam/Nreset_CC.csh -> 
(code) /opt/t4/beta/src/weber/necam/Nreset_CC.pl -> 
(run)  Nthales, Ndpg109, sendmail  
(use)  necam_utilities.pm

Nthales

(Link) /opt/t4/beta/bin/$OPSYS/Nthales -> 
(suid) /opt/t4/beta/src/weber/necam/Nthales_$OPSYS ->
(code) /opt/t4/beta/src/weber/necam/Nthales.c -> 
(run)  /opt/t4/beta/scripts/Nthales.csh ->
(intf) /opt/t4/beta/src/weber/necam/Nthales.csh -> 
(code) /opt/t4/beta/src/weber/necam/pythales.py -> 
       (import)  serial, pynecamsema 

Nadam

(Link) /opt/t4/beta/scripts/Nadam -> 
(intf) /opt/t4/beta/src/weber/necam/Nadam.csh -> 
(code) /opt/t4/beta/src/weber/necam/necam_adam_ctrl.py -> 
       (import)  pymodbus 

Ndpg109

(Link) /opt/t4/beta/bin/Linux_2.6_i686/Ndpg109 -> 
(suid) /opt/t4/beta/src/weber/necam/Ndpg109_Linux_2.6_i686 ->
(code) /opt/t4/beta/src/weber/necam/Ndpg109.c ->
(run)  /opt/t4/beta/scripts/Ndpg109.csh ->
(intf) /opt/t4/beta/src/weber/necam/Ndpg109.csh -> 
(code) /opt/t4/beta/src/weber/necam/pydpg109.py -> 
       (import)  serial, pynecamsema 

Necam

(Link) /opt/t4/beta/scripts/Necam -> 
(intf) /opt/t4/beta/src/weber/services/necam/Necam.csh -> 
(code) /opt/t4/beta/src/weber/necam/necam.py -> 
         (import necam_adam_ctrl, pythales, pydpg109)

Necamfans

(Link) /opt/t4/beta/scripts/Necamfans -> 
(intf) /opt/t4/beta/src/weber/necam/Necamfans.csh -> 
(code) /opt/t4/beta/src/weber/necam/necamfans.py -> 
         (import pynecamfans)

Nlakeshore

(Link) /opt/t4/beta/scripts/Nlakeshore -> 
(intf) /opt/t4/beta/src/weber/necam/Nlakeshore.csh -> 
(code) /opt/t4/beta/src/weber/necam/Nlakeshore.py -> 
(link) /opt/t4/beta/bin/Linux_2.6_i686/c2_lakeshore -> 
(exe)  /opt/t4/beta/src/weber/services/c2_lakeshore/c2_lakeshore_Linux_2.6_i686 ->
(code) /opt/t4/beta/src/weber/services/c2_lakeshore/c2_lakeshore.c ->
       (include termio.h)

ANNEXE: SÉMAPHORES

Les accès au contrôleur Thales et au contrôleur Pfeiffer se font au travers de 2 jeux de sémaphores.

Rappel: les sémaphores sont des entités informatiques globales dans un système représentées sous la forme d'un simple nombre intialisé à "1". On associe un sémaphore à une ressource et on décide que l'accès à cette ressource doit se faire au travers de ce sémaphore. Ainsi lorsqu'on veut utiliser une ressource, la première action est de décrémenter le sémaphore (fonction système).

Un sémaphore a la caractéristique de bloquer le processus qui effectue la décrémentation si le résultat de l'opération devait devenir négatif. Le processus bloqué est libéré lorsque l'autre processus ayant obtenu la ressource (passage réussi de 1 à 0 par la décrémentation) libère le sémaphore en fin de travail par une incrémentation. À ce moment le sémaphore passe de 0 à 1, mais immédiatement revient à zéro suite à la réussite de la décrémentation du processus bloqué. Ce dernier, ayant obtenu la ressource bloquera tout processus tentant une decrémentation du sémaphore et ainsi de suite.

Un sémaphore suspend et libère les processus dans l'ordre d'arrivée.

Le choix d'utiliser des sémaphores s'est imposé (et devrait s'imposer pour toutes les laissions séries) car le contrôleur Thales n'accepte qu'une commande par seconde. Ainsi une demande de status générale demande une vingtaine de seconde et interfère avec les mesures des services. Grâce aux sémaphore, une demande de status, fige durant un moment la mesure des services sans générer des problèmes de communication.

Le cas problématique: lorsque pour une raison quelconque un sémaphore réservé n'est pas libéré (crash du programme appelant et surtout lors du développement). Il devient indéfinitivement bloquant, empêchant l'accès à la ressource.

La solution standard consiste à incrémenter le sémaphore depuis un autre programme. Attention, si cette action est prise à la légère et que l'incrementation n'était pas nécessaire, le sémaphore va obtenir un valeur de 2, permettant un accès concurrent à 2 processus sur la même ressource, ce qui générera des problèmes de communication.

La solution dans notre cas est de suspendre les services de Necam, tuer les processus liés au services, supprimer les sémaphores et permettre la reprise des activités des services. Le programme Nreset_CC exécute cette séquence.

Semaphore ID

On liste les sémaphores avec la commande ipcs -s

ANNEXE: PROGRAMMATION DE L'ADAM 6051

Le module Adam 6051 (12 ch digital inputs) doit être configuré avant son emploi afin de programmer 6 entrées digitales en 6 entrées type fréquencemètre.

Cette configuration se fait sur PC Windows avec le logiciel Advantech AdamApax NET Utility

QUICK REFERENCE and COOK BOOK

Travail sur glsserv sous votre nom

Arrêt du CryoCooler (ATTENTION: l'arrêt demandera un pompage)

Nstop_CC

Suspension des services

Arrêt avec: touch /tmp/INIB_SERVICE_NECAM
Reprise IMPÉRATIVEMENT avec: Nreset_CC

LW 01/04/2020