ARCCTEL

Architecture de Réseau pour le Controle Commande de TELelescope


Cette page et ses liens me servent de cahier des charges. En les partageant, elles peuvent être relues et s'améliorer. Et à terme, elles serviront de manuel utilisateur.

 

Elles décrivent la solution réseau pour le controle commande de télescopes destinés à être pilotés: 

Le choix technique est clairement celui d'une architecture distribuée sur réseau Ethernet, en raison de :

  1. La progression constante des performances des matériels connectés sur Ethernet.
  2. Une série de protocoles définis et remarquablement stables parmis toutes les technologies éphémères que nous avons vu défiler depuis 30ans.
  3. La facilité d'investigation des communications, (Normes connues, outils d'analyses gratuits, tests plus faciles à réaliser)
  4. Donc facilité d'intégration ou de dépannage (parce que les compétences existent).
  5. La modularité et l'extensibilité du système.
  6. L'indépendance par rapport aux opportunités d'approvisionnement ou de solution technique (systèmes d'exploitation).
  7. Une possibilité de liaison radio qui donne un avantage pratique pour l'utilisateur local.
  8. La redondance dans le système est possible.
  9. Les distances entre sous systèmes plus grandes que les autres bus "consummer" genre USB. 
  10. Chaque service est indépendant des autres, la complexité du logiciel global est plus faible => fiabilité accrue.
  11.  

Dernier argument de poids : cette architecture me semble plus résistante à l'obscolescences des matériels et des logiciels. Bien que beaucoup d'astronomes amateurs rêvent de ce système, le problème pour nous c'est le temps; déveloper module par module puis voir que des solutions techniques ne sont plus disponibles laisse ouvert le chantier encore plus longtemps, et rien ne se termine.   

Remarque Juridique : 

Il est possible qu'un certain nombre d'idées communes et logiques compte tenu des technologies dont nous disposons soient couvertes par un ou des brevets d'invention, mais celui que j'ai trouvé par hasard déposé par une société Américaine (que je ne citerai pas), a été publié le 4 Mai 2000, il n'y a donc plus que 4 ans à attendre avant qu'il rentre dans le domaine publique.  Quoiqu'il en soit, il ne s'agit pas ici d'une application commerciale, mais personnelle. Et ce qui est brevetable aux US, ne l'est pas forcement en France. En France un brevet est recevable lorsqu'il ne rentre pas dans l'exercice normal de la fonction d'ingénieur.

On peut aussi rappeler que l'architecture distribuée porte un autre nom depuis des décennies: systèmes interopérables. Donc ce brevet n'a rien inventé. 

 

Pour ne pas changer de stratégie en cours de dévelopement, il faut garder ces définitions à l'esprit :

  1. Le SYSTEME  est constitué de tous les sous systèmes connectés au réseau local.
  2. Un SOUS-SYSTEME est un système électronique qui a une adresse IP unique sur le LAN.
  3. Un SERVICE est un programme installé sur un sous-système, il est distingué par un N° de port.
  4. Un USAGE est la définition pratique, concrète de ce qui est fait avec un des composants du sous système.

On en déduit que: 

  1. Le nombre de sous-systèmes est indéfini.
  2. Deux services identiques ne peuvent pas exister sur un même sous-système mais ils peuvent aller sur 2 sous-systèmes.
  3.  

Les sous systèmes communiquent entre eux par des messages en ASCII, un langage simple. Des mots clefs principaux comme RESET, SET, GET, suivis de propriétés des sous systemes et leurs valeurs. Bien sur chaque sous système possède son interpréteur. On pourrait reprocher un temps de latence à cette méthode, mais elle a aussi ses intérêts:

On pourrait donc ranger dans cette structure (Architecture statique), tous les besoins connus pour le contrôle-commande d'un telescope.

Nous pourrions écrire un fichier de configuration .H  ou INF  ou XML (exemple ici) pour qu'elle soit connu de tous les sous systèmes, ou bien avec cette table pour les utilisateurs:

Sous Systeme Adresse IP Service N° port Usage Localisation physique Consommation Commentaire
WLAN Box 192.168.1.1       Mur intérieur 1A/5Vcc Passerelle avec WLAN. Par le 3G+
Mini PC 1 192.168.1.9       Armoire électrique 1,6A/19Vcc Mini PC HP.
    serveur IHM 80       Serveur HTTP pour les IHM sur tablettes tactiles  wifi.
    scheduler 49010       Va chercher les emails dans lesquels sont écrites les demandes de téléscopes. Exécute les scripts. Renvoie les images.
Switch         Armoire électrique 0,5A/12Vcc Netgear 8ports 1Mb.
Carte Relais  192.168.1.6 relays   R1 Armoire électrique 1A/12Vcc Alimentation électrique de l'éclairage extérieure.
        R2     Alimentation électrique de la station météo.
        R3     Alimentation des systèmes sur le téléscope T600.
        R4     Alimentation électrique des caméras du garage.
        R5     Réservé.
        R6     Réservé.
        R7     Réservé.
        R8     Réservé.
Camera IP 1 192.168.1.3       Abri 2A/5vcc Surveille le terrain en champs large, et le ciel. Caméra Grandtec.
Camera IP 2 192.168.1.4       Abri   Surveille le téléscope depuis le local technique.
Camera IP 3 192.168.1.5       Tube T600   Embarquée sur le tube.  Camera Axis.

Surveille le miroir principal, la buée, les volets de protection.

Caméra IP4 192.168.1.7       Tube T600 12Vcc Capture les images du foyer du téléscope.
Routeur GigE

Switch configurable

192.168.1.2 DHCP 67   Abri   Donne l'adresse IP aux clients.
Station météo         Abri   Station sur port USB. Marque INFACTORY.
APN 192.168.1.20         3A/8Vcc Réglage de sensibilité...
RaspBerry PI2 -Carte N°3 192.168.1.10 intervalonet 49000 L1 Tube T600 2A/5Vcc LED de flashage.   
        S1     Signal de relèvement du miroir.
        S2     Signal de déclenchement d'exposition.
    NTP server 123       Serveur NTP stratum-1. 
RaspBerry-PI1 B+ Carte N°2 192.168.1.11 gpioda 49003 R1 Monture T600 2A/5Vcc Eclairage sur la monture. Eclaire le tube.
        R2     Eclairage écran de flats..
        R3     .
        R4     Collage de ventouse Electromagnétique de l'axe de hauteur.
        R6     Collage de ventouse Electromagnétique de l'axe Verticale (Azimuth).
        R7     Verouillage de la coupole.
        R8     Rotation de la coupole.
        R9     Ouverture de fenêtre de coupole.
        R10     Fermeture de fenêtre de coupole.
        R11     .
    coordinates 49001       Calcul de transformation de coordonnées équatoriales en azimutale.
    NTP client 123       Donne l'heure UTC pour les calculs de transformation de coordonnées.
RaspBerry-PI2 Carte N°4 192.168.1.12 stepmotor 49002 M1 Monture T600 2A/5Vcc Moteur de l'azimuth.
        M2     Moteur de la hauteur.
        M3     Moteur équatorial.
RaspBerry PI1 B+ Carte N° 192.168.1.13 stepmpi 49005 M1.1 Tube T600   Ouverture du volet 1 de protection du miroir principal.
        M1.2     Ouverture du volet 2 de protection du miroir principal.
      M2.1     Moteur pas à pas N°1 du barillet. Ce service "stepmpi" fournit des impulsions pour cartes de moteur pas à pas asiatiques.
        M2.2     Moteur pas à pas N°2 du barillet.
        M2.3     Moteur pas à pas N°3 du barillet.
    gpioda 49003 R1     Chauffage miroir principal.
        R2     Chauffage miroir secondaire.
        R3     .
Banana PI 192.168.1.8 FTP serveur 21 NAS Abri   NAS = Network Access Storage
PC desq 1 Dynamique Cartes du Ciel.exe   IHM Abri 1A/220Vac Sélection par l'utilisateur d'objets à pointer.
    RaquetteXP.exe   IHM     Interface utilisateur fixe en mode local.
    WireShark.exe   IHM     Journal des échanges de messages entre sous systèmes.
    NTP client 123       Met le PC à l'heure.
Tablette 1 W8 Dynamique Navigateur   IHM Terrain 2A/5Vcc Interface utilisateur mobile en mode local.
Tablette 2 Android Dynamique Navigateur   IHM Terrain 2A/5cc Interface utilisateur mobile en mode local.

Tous les clients obtiennent leur adresse IP grace au serveur DHCP  entre 192.168.1.128 et  192.168.1.254.

Tous les serveurs ont une adresse IP fixe entre 192.168.1.1 et  192.168.1.127.

Les sous systèmes ou services ou logiciels écrits en blanc sont ceux que l'on trouve sur internet et n'ont pas besoin d'être développés. 

Les autres sont dévelopés par moi ou mes amis. 

Les N° de port commencent à partir de 49000, là ou plus aucun service n'est connu (à ce jour).

Nous pourrions ajouter à cette liste de services de quoi obtenir des darks, des flats, changer des filtres, tourner un réseau de diffraction, etc...

La station météo est le seul système sur port USB, parce que la seule station qui fonctionnait sur Ethernet était conçue pour aller chercher sur internet les prévisions météo mais pas pour transmettre les relevés locaux à un PC local. 

 

Voici une traduction graphique de tout cet ensemble:

 La prochaine version de ce dessin intègrera un NAS et fera quelques mises à  jour (Adresse IP du Mini PC).

DESCRIPTION DYNAMIQUE

Comment ça marche ? Comment ça communique dans chaque cas d'utilisation et dans le temps ?

Dans les modes 1 et 2 listés au tout début de cette page, l'ordonnancement, la sécurité et la logique de fonctionnement reposent sur le bon sens d'un opérateur.

Dans le mode 3, automatique et planifié, il faut détacher 3 temps :

La collecte des requêtes de téléscope(s). C'est le role d'un site web logé dans un FAI pour garantir le meilleur taux de disponibilité. C'est un projet que j'ai réalisé pour obtenir une UE du CNAM (NFE114 Systèmes d'information Web) en 2007. Ce serveur était écrit en PHP et MySQL. Il dort depuis des années mais se trouve encore à cette adresse

La planification. C'est le role d'un service dans le Mini PC. Il reçoit les requêtes par email, les met dans l'ordre et vérifie qu'il n'y a pas impossibilité ou collisions. Et quand l'heure a sonné, il lance l'exécution. 

L'exécution. C'est l'ordonnancement des activités des services, donc des sous systèmes. Un diagramme d'activité avec des lignes de vie de chaque service permettrait de donner une vue des charges de travail et des flux de données (occupation de la bande passante du réseau) et guiderait la distribution des services sur les cartes à microprocesseurs.

(On pourrait ajouter un 4ieme temps qui est la récupération des fichiers par FTP, mais il n'y a pas de quoi en faire un chapitre :-)  )

 

Diagramme d'activité de l'exécution 

Vous le saurez bientot... au prochain épisode...

 

Contactez moi pour vos remarques ou les erreurs qui se seraient glissées dans cette page.

mailto:gerald.mauboussin@free.fr

 

Retour au SOMMAIRE


Copyright 2015- 2016. Cet article ne peut être reproduit totalement ou partiellement sans le consentement de ses auteurs.

Page crée le 03.01.2016 - - - - -Dernière mise à jour 31.05.2016