Réunion GTAL sur la terminologie des tâches et fonctions pour le pilotage et l'automatisme des lidars ACTRIS-FR === ###### tags: `Lidars` `Réunion` `Visio` `ACTRIS-FR` `Automatisme` :::info - **Location:** Visio Zoom - **Date:** Nov 17, 2020 1:30 PM (CET) - **Agenda** 1. Terminologie 2. Listes pour mise à jour du document excel google drive 3. Discussion sur les pilotages et automatismes des différents sites - **Participants:** - [x] C. Pietras (CP) - [x] Guillaume Payen (GP) - [x] Thierry Podvin (TP) - [x] Nicolas Marquestaut (NM) - [x] Patick Freville (PF) - **Contact:** C, Pietras <christophe.pietras@lmd.ipsl.fr> - **Host:** C. Pietras - **References:** - [CR de la précédente réunion du 4 novembre 2020](https://hackmd.io/GfcBoll9T7q1JPYLlEVQjQ) - Accéder au [dossier partagé google drive](https://drive.google.com/drive/folders/1msoFrJiVAhlPuxlYPcOxBGnu6e5pu233?usp=sharing) ::: :dart: Objectifs du groupe pour cette réunion en visio --- - Discuter de la terminologie à utiliser pour caractériser ce que l'on considère comme automatismes les fonctions et les tâches pour opérer les lidars - Discuter de l'architecture à adopter pour décrire aux mieux les fonctions et les tâches afin de décrire au mieux l'état de fonctionnement (Manuel, piloté ou atomatisé) des lidars d'ACTRIS-FR - Proposer un plan de travail jusqu'à la date de mi-décembre :closed_book: Tâches à accomplir pour les semaines à venir -- 1. Chaque responsable de système du groupe décrit dans le [document forum](https://drive.google.com/file/d/1WqF_pZI_TrFKS5rsvp4koVJzxiM-bZTO/view?usp=sharing) sur le drive les différentes fonctions puis tâches unitaires qui doivent être réalisées pour opérer leur système. En indiquant si la tâche est M/P/A pour Manuel, Pilotable, Automatisée. Chacun mentionne aussi succintement le dispositif utilisé pour le pilotage ou l'automatisme. 2. Lien vers le [document forum](https://drive.google.com/file/d/1WqF_pZI_TrFKS5rsvp4koVJzxiM-bZTO/view?usp=sharing) 3. CP commence à préparer un template excel sheet sous google qui permettra de synthétiser les éléments notés dans le document forum 4. CP propose une prochaine visio du groupe pour fin novembre-début décembre. Doodle à faire :open_book: Notes -- <!-- Other important details discussed during the meeting can be entered here. --> 1. Discussion générale - TP: description des automatismes et pilotages actuels du système LILA. TP mentionne qu'il attaque directement le programme main32 de licel pour permettre des automatismes plus ciblés comme l'alignement ou la détection de nuages. TP mentionne que LILA est presque en automate complet. Reste à coupler le système avec un dispositif de détection jour/nuit. Pour l'instant l'opérateur doit encore manuellement ou à distance activer ou désactiver les détecteurs de voies raman - PF décrit pour COPLID certains automatismes. - SUr les automatismes/pilotage, GP souligne les differences significatives pour l'OPAR et l'OHP par rapport aux autres systèmes: le superviseur ne peut être juste un programme d'acquistion, mais nécessité d'avoir une "sur-couche" car par ex, l'OPAR doit gérer 4 pc d'acuistion donc il faut un serveur pour discuter avec ces PCs. Il y a une logique client/serveur pour opérer les différentes fonctions. --> D'ou Question sur la mualisation des fonctions. - GP souligne aussi par ex, que le programme main32 licel adapté par Lille pour LILA es tpour l'instant difficilement trasportable sur un autre système car il est spécifique. Il faudra réfléchir aux moyens de mutualiser ce genre d'outils. - PF mentionne que pour COPLID, le software d'acquisition permettant les automatismes actuels devra être adapté et il est donc intéressé par ce travail fait sur main32 exe. GP propose aussi à PF de lui présenter les travaux fait à l'OPAR sur le superviseur qui pourrait s'adapter au système COPLID. 2. Discussion plus spécifique sur la terminologie et l'architecture à adopter pour décrire les pilotages/automatismes des systèmes - GP propose que les fonctions soient plus generalistes avecc plusieurs tâches pour réaliser la fonction. Les Tâches sont proche de l'unitaire. Le groupe s'accorde sur cette idée. - Il faut trouver des fonctions identiques pour tous les lidars et avoir des tâches par contre qui soient plus proche de l'unitaire et qui seront différentes selon les systèmes. Ainsi on pourra indiquer si les tâches sont M/P/A ou N pour inutilisé pour le système concerné. - GP suggère de lister entre nous les grandes fonctions. et chacun fait la liste des tâches pour son système et ensuite on voit ce qui est potentiellement mutualisable ou unique pour le système concerné - Par ex colonne B liste des fonctions, colonne C, liste des taches. Je note colonne avec status qui sera MPA ou N et donc l'idée on ne touche pas le document excel actuel. - GP suggère que l'on complète plutôt pour le moment le [document forum](https://drive.google.com/file/d/1WqF_pZI_TrFKS5rsvp4koVJzxiM-bZTO/view?usp=sharing) - NM verait bien en fonction les parties emission, réception, acquisition, batiment, condition extérieure mais CP souligne que cela fait très généraliste alors qu'il y a plus de fonctions. On s'accorde alors de parler de lots qui auraient les fonctions en sous hiérarchie puis les tâches. - On prend pour illustrer l'exemple de la tâche contrôle de l'alignement pour LILAS avant l'acquisition des signaux. - GP souligne que l'on pourrait aussi parler de fonctions plus évoluée: genre alignement qui font appel à plusieurs actionneurs détecteurs. Selon les fonctions, on peut agir sur plusieurs actionneurs ou détecteurs mais qui seraient les mêmes. Intérêt de cette architecture est que l'on se rapprocherait d'un fonctionnement automatique mais ca peut se révéler plus compliqué à faire. 3. Discussion sur l'idée de superviseur - GP et NM mentionne que Le superviseur va lancer les fonctions selon plusieurs paramêtres. - Actuellement pour la plupart des systèmes, le superviseur est notre système d'acquisition qui lance tout. Mais GP et NM décrive leur travail actuel de réaliser un superviseur qui passe par un serveur communquant avec plusieurs clients pour avoir soit des informations soit lancer des tâches. Donc Connection entre plusieurs points. On peut découper plusieurs parties qui communiquent avec le serveur global. - La Philisophie: un serveur, plusieurs clients autour, et à l'intérieur pleins de sous-clients. - On illustre avec l'exemple d'installer un client sur le PC d'acquitiion d'un ceilometre par ex pour récupérer une information (ce qui est fait à l'OPAR) - On s'accorde sur les tâches du groupe pour les prochaines semaines, notemment remplir le document forum avec la liste des tâches les plus unitaires.