Protocole de communication Smart-Devices – Client

Protocole de communication Smart-Devices – Client

Protocole de communication Smart-Devices – Client

Le contrôle des différentes expériences se faisant via une interface web, la communication entre le client et le Smart Devices est basée sur un protocole IP (Internet Protocol). « Internet est un réseau de réseaux développé par le ministère de la Défense aux États-Unis dans la fin des années 70 et le début des années 80 pour interconnecter les différentes machines informatiques de ce ministère. La solution a été de développer un protocole commun que l’ensemble des réseaux et des machines connectées doit posséder. Ce protocole commun, c’est précisément le protocole IP (Internet Protocol). Les réseaux interconnectés, que nous avons appelés les sousréseaux, peuvent être quelconques. Il leur est juste demandé de transporter d’une extrémité à l’autre des paquets IP, c’est-à-dire des paquets conformes aux spécifications du protocole IP.» [4] Pour que cette communication virtuelle puisse avoir lieu, les deux appareils doivent parler le même langage et suivre les mêmes règles. Pour ce faire, chaque appareil possède des composants qui implémentent ces différentes règles plus communément appelées protocoles. Un appareil qui possède plusieurs composants peut donc communiquer avec un autre appareil sous différents protocoles. Les protocoles HTTP, TCP, UDP et IP font partie des plus utilisés. LabVIEW, qui peut être considéré comme un composant, est capable de communiquer avec, entre autres, les protocoles précédemment cités. Il s’agit donc ici de déterminer quel est le meilleur protocole à adopter dans le cas des laboratoires à distance. 5.1 Architecture de la communication La communication peut être séparée en deux parties. Il y a tout d’abord une communication entre les différents « Smart-Devices » et le serveur, puis une autre communication entre le serveur et les différents clients. Le Web-Server ainsi que les Smart-Devices sont programmés en LabVIEW. Côté client, la programmation est exclusivement faite en HTML5. Le schéma suivant représente les canaux de transmission des données entre les différents acteurs du MOOLs. La machine virtuelle permet aux clients d’accéder depuis l’extérieur aux Smart-Devices qui sont dans l’infrastructure réseau de la HES-SO Valais à Sion. Pour des questions de sécurité, les automates cRIO ne peuvent pas être visibles depuis un réseau externe à l’école. La solution proposée par le service informatique de l’école est de passer par une machine virtuelle. Celle-ci est accessible depuis l’extérieure par le port TCP 8793 à l’adresse « remotemools.hevs.ch ». Cette adresse est le nom DNS publique visible depuis l’extérieur donné à la machine pour les MOOLs. En interne, la machine virtuelle accède aux automates via le port TCP 8792. L’adresse IP de ces automates est fixe et dépend de leur emplacement physique dans l’infrastructure de l’école. Dans le but de simplifier la programmation, un nom DNS leur est attribué et a la forme suivante : « moolscrioxx.hevs.ch ». Comme il est prévu de connecter plusieurs automates au laboratoire, deux caractères sont réservés (« xx ») pour le numéro de l’automate. Pour que cette communication soit possible, le service informatique a ajouté des règles aux Firewalls situés entre les automates et le serveur, ainsi qu’entre le serveur et l’extérieur. 5.2 Communication Smart-Devices – Serveur Plusieurs types de communications peuvent être implémentés entre les deux applications LabVIEW du SmartDevice et du serveur. Il s’agit ici de déterminer lequel des protocoles de communication est le plus adapté pour cette application. Pour ce faire, différents protocoles sont implémentés est comparés. 5.2.1 TCP Le premier protocole à faire l’objet d’une étude est le TCP/IP. Son implémentation est native à LabVIEW et est relativement simple à mettre en place. « Le protocole TCP (Transmission Control Protocol) a été initialement défini dans la RFC 793 de l’IETF (Internet Engineering Task Force). Le protocole TCP fournit un service de transport fiable, basé sur la connexion et le « bytestream », en plus des connexions non fiables service réseau fourni par IP. TCP est employé par un grand nombre d’applications comme par exemple : — Email (SMTP, POP, IMAP) — World Wide Web ( HTTP, …) Sur internet, la plupart des applications utilises le protocole TCP. De nombreuses études ont rapportées que TCP était responsable de plus de 90% des données échangées sur Internet.»

Communication Serveur – Client

La communication serveur-client se situe entre la machine virtuelle et la page Web de contrôle (voir fig. 5.1). Le protocole de communication entre ces deux parties ne peut être le même que celui utilisé entre le serveur et les Smart-Devices, etant donné que de l’interface client programmée en HTML5 n’intègre pas directement le protocole TCP « brut ». C’est pour cette raison qu’une couche additionnelle (WebSocket) est implémentée par-dessus le TCP. 5.3.1 WebSocket Le protocole WebSocket est celui employé pour les laboratoires distants de l’EPFL. Il est donc judicieux de l’employer plutôt qu’un autre afin de se standardiser avec le travail déjà effectué par l’EPFL et ainsi de faciliter la mise en commun des ressources entre cette école et la HES-SO Valais. Le WebSocket, qui est un standard du Web, a été normalisé en 2011. Il est développé par-dessus une connexion TCP. « Le protocole WebSocket permet une communication bidirectionnelle entre un client exécutant du code non fiable dans un environnement contrôlé vers un hôte distant qui a opté pour les communications de ce code. Le model de sécurité utilisé pour cela est le modèle « origin-based security model » couramment utilisé par les navigateurs Web. Le protocole envoi tout d’abord un « handshake » (établissement d’une liaison) suivi d’un message de base, superposé sur TCP. L’objectif de cette technologie est de fournir un mécanisme pour navigateur basé sur les applications qui nécessitent une communication bidirectionnelle avec des serveurs qui ne compte pas sur l’ouverture de plusieurs connexions HTTP. » [3] Dans le cadre des MOOLs, l’intérêt principal de ce protocole est le fait que le client n’a pas besoin d’envoyer une requête au serveur pour recevoir un paquet de données. En d’autres termes, après avoir établi la communication avec le serveur, le client peut recevoir les données du « SmartDevice » sans envoyer une requête pour chaque mesure ou chaque image. Ce type de communication est appelée « Real-time ». La figure 5.8 représente ce type d’échange de données en comparaison avec des échanges traditionnels. Un autre avantage de ce protocole est le fait qu’il soit directement intégré à HTML5. L’application du client peut ainsi être développée en HTML5 et être plus facilement intégrée à une page web existante qui serait hébergée dans le cours en ligne du laboratoire. Le client doit simplement ouvrir une page web pour accéder aux infrastructures du MOOLs et n’a pas besoin de télécharger d’application. Cela permet également une compatibilité maximale entre avec le différents systèmes d’exploitation. La seule condition requise est d’avoir un navigateur web à jour. Pour les raisons évoquées en début de chapitre, ce protocole est choisi pour la communication entre le serveur et le client et aucun autre protocole n’est étudié. 5.3.2 WebSocket et LabVIEW Le protocole WebSocket n’est pas nativement intégré à LabVIEW. Les paquets doivent par conséquent être mis en forme avant d’être envoyés via une connexion TCP. Pour la réception, ils doivent également être décryptés pour pouvoir exploiter leurs données. De plus, à l’initialisation de la communication, une clé doit être échangée entre le serveur et le client pour que la communication puisse avoir lieu. Ces différentes fonctionnalités ont été développées à l’EPFL dans le cadre de leurs MOOLs. Ce projet se faisant en collaboration avec eux, leur développement LabVIEW sur le WebSocket nous a été fourni. La figure suivante représente le principe de programmation de la communication côté serveur.

Table des matières

1 Introduction
2 Cahier des charges
3 Description générale de l’infrastructure des MOOLs
3.1 Web Server
3.2 Smart Devices
3.3 Moodle
3.4 Clients
4 Environnement de développement LabVIEW
5 Protocole de communication Smart-Devices – Client
5.1 Architecture de la communication
5.2 Communication Smart-Devices – Serveur
5.2.1 TCP
5.2.2 DataSocket
5.2.3 UDP
5.2.4 Comparaison des ressources et choix du protocole
5.3 Communication Serveur – Client.
5.3.1 WebSocket
5.3.2 WebSocket et LabVIEW
5.3.3 WebSocket et HTML5
6 Web Serveur 
6.1 Gestion des connexions client
6.2 Gestion des connexions des Smart-Devices
6.3 Installation du programme LabVIEW sur la machine virtuelle
7 Smart-Devices
7.1 Maquette de régulation du moteur DC
7.2 Régulation en vitesse (tachymètre) du moteur D .
7.2.1 Dimensionnement du régulateur
7.2.2 Simulations
7.2.3 Mesures
7.2.4 Calcul de la résolution de la vitesse
7.3 Régulation de vitesse (codeur) du moteur DC
7.3.1 Dimensionnement du régulateur
7.3.2 Simulations
7.3.3 Mesures
7.3.4 Calcul de la résolution de la vitesse .
7.4 Régulation en position (potentiomètre) du moteur D
7.4.1 Dimensionnement du régulateu .
7.4.2 Simulations
7.4.3 Mesures
7.4.4 Calcul de la résolution
7.5 Régulation de position (codeur) du moteur DC
7.5.1 Dimensionnement du régulateur
7.5.2 Simulations .
7.5.3 Mesures
7.5.4 Calcul de la résolution
Thomas Moniquet 1 16 août 2018
Travail de bachelor Power & Control
7.6 Maquette de régulation de système instable à bille
7.6.1 Dimensionnement du régulateur
7.6.2 Simulations
7.6.3 Mesures
8 Programmation du cRIO 
8.1 Programmation de la FPGA .
8.1.1 Algorithme des codeurs incrémentaux
8.1.2 Boucle de régulation de l’entraînement électrique
8.1.3 Boucle de régulation du système instable à bille
8.2 Programmation de la CPU
8.2.1 Communication avec la FPG.
8.2.2 Acquisition des images de la Webcam
8.2.3 Communication avec le Web-Serveur
9 Interface Client 
9.1 HTML
9.2 CSS
9.2.1 Position du « parent »
9.2.2 Position des « enfants »
9.3 JavaScript
9.3.1 JSON
9.3.2 Initialisation
9.3.3 Programme en fonctionnement
9.3.4 Fermeture
10 Tests de l’infrastructure
10.1 Mesures du temps entre les paquets
10.2 Mesures de l’utilisation de la CPU du cRIO
10.3 Mesures de l’utilisation réseau et processeur de la machine virtuelle
11 Conclusion et perspectives
12 Annexes
A Planning
B Datasheet capteur optique
C Datasheet Webcam Logitech C270
D Datasheet cRIO-9067, NI-9201, NI-9263, NI-94
E Création d’un exécutable LabVIEW
F Création d’un installeur LabVIEW
G Entraînement Electrique Open-Loop
H Système instable à bille Open-Loop
I Système instable à bille Closed-Loop

Télécharger le rapport complet