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: 

• 1-En mode local en interaction avec un utilisateur. 
• 2-En mode distant. 
• 3-Et en mode de script, c'est à dire automatique et plannifié. 

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:

• Fragmenter le système en sous-systèmes simples, donc diminuer la complexité globale.
• Faciliter les tests unitaires, puisque à un jeu de commandes simple correspond un jeu de bonnes réponses.
• Avoir une visibilité du fonctionnement dynamique est possible.  
•