Utilisation du bon protocole réseau

Chaque type de communication implique des cibles (généralement un système d’acquisition de données ou des contrôleurs) et des hôtes (généralement affichant l’IHM) qui peuvent être configurés de plusieurs façons. Vous pouvez établir une communication entre une seule cible et un seul hôte (1:1), entre plusieurs cibles et un seul hôte (N:1) ou entre une seule cible et plusieurs hôtes (1:N). La section suivante décrit chaque type de communication utilisé dans les applications de contrôle/commande de machines, leurs configurations système courantes et leurs exigences en matière de réseau et de transfert de données.

Communication par commande ou message

La communication par commande ou message est un transfert d’informations peu fréquent, déclenché par un événement spécifique. Il peut s’agir d’une pression sur un bouton ou d’une alarme, qui déclenche alors une réponse spécifique. Dans une architecture basée sur les commandes, deux types de systèmes sont concernés : un système de commande (hôte) et un système subordonné (cible). Le système de commande envoie des instructions au système subordonné pour qu’il les exécute. Les commandes doivent être transmises sans perte et avec une latence minimale. Par exemple, lorsqu’un opérateur appuie sur un bouton, il s’attend à ce que l’action associée soit exécutée sans avoir à appuyer à nouveau sur le bouton. Il s’attend également à ce que le système réponde dans un délai raisonnable. La configuration la plus courante est 1:1, mais N:1 et 1:N sont également possibles.

Communication des données de processus

La communication des données de processus consiste à transférer périodiquement les dernières valeurs des variables de processus. Ce type de communication est le plus courant et est utile pour les applications de contrôle et les IHM utilisés pour afficher les états actuels du système.  Par exemple, elle serait utilisée pour les mises à jour périodiques envoyées par un ou plusieurs contrôleurs embarqués à une IHM qui surveille l’état de la ou des machines.  L’opérateur doit consulter l’état actuel des machines. La transmission sans perte n’est donc pas nécessaire car le contrôleur temps réel ou l’IHM traite uniquement la dernière valeur.

Ce type de transfert de données peut être utilisé entre des contrôleurs embarqués et peut nécessiter une exécution à haute vitesse.  Cependant, la communication de données de processus est le plus souvent utilisée pour mettre à jour une IHM.  Ce type de communication implique des fréquences de mise à jour plus lentes car les données sont visualisées par des humains. Des fréquences de mise à jour de 1 à 30 Hz sont généralement suffisantes ; toute fréquence supérieure sollicite les ressources du processeur et de la mémoire, et représente plus d’informations que l’opérateur humain ne peut traiter visuellement. En règle générale, les affichages numériques ne doivent pas être mis à jour à une fréquence supérieure à 1 ou 2 Hz. Pour les affichages graphiques, une fréquence de 30 Hz permet des mises à jour régulières.

Communication en continu/bufférisée

Lors de la transmission de données en continu, de grandes quantités d’informations sont envoyées en continu, mais pas nécessairement en temps réel. Ce type de communication est utile lorsque vous souhaitez envoyer de nombreuses données et que vous devez capturer chaque point de données. Souvent, mais pas toujours, le streaming est unidirectionnel et présente une configuration 1:1. Il implique une bufférisation continue des données afin qu’aucune donnée ne soit perdue. La communication en continu est couramment utilisée lorsqu’une cible effectue une acquisition de données à haute vitesse et que les données doivent être transférées à l’hôte pour l’enregistrement ou le post-traitement.

Tableau 1.1. Résumé des types de communication pour le contrôle des machines

Lorsque vous choisissez un protocole réseau pour votre application, vous devez évaluer un certain nombre de facteurs, notamment :

• Type de communication
• Configuration système
• Performances
• Simplicité d’emploi
• API ^tierces prises en charge

Les types de communication et les configurations système évoqués ci-dessus seront le facteur le plus déterminant dans le choix du protocole réseau pour votre application. Les exigences en matière de performances et de convivialité dépendront de votre application et de votre expérience en programmation. Enfin, si vous envisagez de développer votre application pour communiquer avec des applications tierces, telles que celles développées en C ou VB, vous devrez utiliser des protocoles réseau capables de s’interfacer avec des API ^tierces. En examinant ces facteurs, vous serez en mesure de prendre la bonne décision pour votre application. Reportez-vous au tableau 1.2 pour obtenir un résumé de chaque protocole réseau en fonction des facteurs ci-dessus.

Tableau 1.2. Résumé des protocoles réseau ( = Meilleur, = Mieux, = Bon, * = dépend de l’action effectuée dans le service Web)

TCP et UDP

Les protocoles Internet TCP et UDP sont des éléments de bas niveau utilisés par tous les protocoles réseau abordés dans ce document. Tous les autres protocoles fournissent une abstraction conviviale en plus de ces protocoles. C’est pourquoi TCP et UDP offrent les meilleures performances et fournissent un contrôle de bas niveau permettant la plus grande flexibilité. TCP et UDP peuvent être utilisés pour construire votre propre protocole personnalisé, tel que STM.

TCP

TCP est un protocole de communication point à point fiable ; il permet une communication sans perte et ordonnée des données. C’est un protocole de connexion, ce qui signifie qu’une connexion entre le client et le serveur doit être établie avant le transfert des données. Pour assurer la transmission des données, TCP les retransmet jusqu’à ce qu’il reçoive un accusé de réception. Le client et le serveur TCP communiquent via un port spécifié.

UDP

Le protocole UDP diffère du TCP car il publie des données sur un port spécifié, mais ne nécessite pas de connexion avec un client avant d’envoyer les données. S’il n’y a pas de connexion pour recevoir les données à leur destination, les données sont simplement supprimées ; aucune vérification de la réussite de la transmission n’est effectuée. Par conséquent, le protocole UDP ne doit pas être utilisé dans les applications où le transfert de données sans perte est essentiel.

Les fonctions UDP peuvent être utilisées pour communiquer avec un seul client, ou les données peuvent être transmises à plusieurs clients. UDP multicast est un mode utilisé pour communiquer efficacement entre un expéditeur unique et plusieurs clients sur un réseau, sans que l’expéditeur ait besoin de maintenir une liste de clients. UDP a les vitesses de transfert les plus élevées de tous les protocoles abordés ici, mais ne garantit pas une transmission de données sans perte.

TCP et UDP sont des protocoles réseau à haut débit, mais leur implémentation est moins aisée. La connexion réseau nécessite une gestion manuelle et chaque connexion consomme un port. TCP et UDP exigent que toutes les données soient envoyées sous forme de chaîne. L’expéditeur doit donc aplatir toutes les données en une chaîne et le récepteur doit redresser les données de la chaîne. Cela accroît la complexité de la transmission de données hors chaîne.

TCP et UDP sont de bons outils pour la communication par messages et les applications de streaming personnalisées. Ils prennent en charge tous les types de configurations et, comme il s’agit de normes industrielles, peuvent être utilisés avec des applications tierces.

Variables partagées publiées sur réseau

Les variables partagées publiées sur réseau constituent un outil LabVIEW convivial pour le partage de données. Elles sont simples à implémenter et prennent en charge la plupart des types de données LabVIEW et des définitions de types personnalisées.

Dans LabVIEW, la variable réseau est composée de trois parties : les nœuds de variables réseau, le moteur de variables partagées et NI-PSP (NI Publish-Subscribe Protocol). Les nœuds de variables réseau sont placés sur le diagramme pour effectuer les opérations de lecture et d’écriture de la variable. Le moteur de variables partagées est le composant logiciel qui héberge les données publiées. Il peut être hébergé sur des cibles temps réel ou des PC Windows, mais doit s’exécuter sur au moins une machine réseau.  NI-PSP est un protocole réseau propriétaire qui optimise le transport des variables partagées réseau. Ce protocole est basé sur TCP/IP, ce qui lui permet de transmettre des données de manière efficace et fiable sur le réseau.

Vous pouvez activer la bufférisation sur les variables partagées publiées sur réseau, ce qui est approprié lorsque vous avez besoin d’un moyen facile d’implémenter une communication N:1 et 1:N sans pseudo-perte. La bufférisation de variables partagées peut permettre d’éviter les pertes de données dues aux retards temporaires du réseau, mais ne garantit pas un transfert de données sans perte. Si un client écrit des données plus rapidement qu’un autre client ne les lit, un débordement finira par se produire et les données seront perdues. Le flux de données n’est pas géré pour éviter le débordement. Même si tous les clients lisent les données à une vitesse suffisante, celles-ci peuvent être perdues si elles sont transmises lorsque la connexion TCP sous-jacente est interrompue en raison de pannes de réseau. Les flux réseau sont recommandés lorsqu’un transfert de données point à point sans perte est souhaité. Les variables partagées publiées sur réseau sont les plus adaptées à la communication de données de processus lorsque la dernière valeur d’une variable de processus est importante.

Flux réseau

Les flux réseau sont une fonctionnalité LabVIEW disponible dans LabVIEW 2010 et conçue pour fournir un streaming de données efficace.  Ils fournissent des abstractions de niveau supérieur faciles à utiliser pour gérer les connexions, les déconnexions et le contrôle du flux de données, tout en maintenant un débit similaire à celui du TCP/UDP brut. Il s’agit d’une voie de communication unidirectionnelle entre deux points, une extrémité scripteur et une extrémité lecteur. En raison de l’absence de perte, ils peuvent également servir de base à la communication basée sur des messages.

Les flux réseau peuvent transférer la plupart des types de données LabVIEW, y compris les clusters et les tableaux sur le réseau, mais ceux-ci sont plus efficaces avec les types de données suivants :

• Scalaires numériques
• Booléens
• Tableaux 1D de scalaires numériques
• Tableaux 1D de booléens

Vous pouvez utiliser les flux réseau pour transmettre des données d’un ordinateur à un autre, d’un ordinateur à une cible temps réel ou d’une cible temps réel à une autre. Les flux réseau étant unidirectionnels, si vous souhaitez transmettre des données dans les deux sens entre vos extrémités, vous devez ouvrir deux flux. De même, si vous souhaitez transmettre des données à plusieurs cibles, vous devez ouvrir plusieurs flux.

Services Web

Les services Web vous permettent de créer des applications Web qui communiquent sur le réseau avec n’importe quel client Web compatible HTTP, y compris les navigateurs Web standard. LabVIEW vous permet de publier un VI en tant que service Web côté serveur. Ce VI est appelé VI de méthode Web. Ce service Web est déployé sur un serveur Web propre aux exécutables ou sur le serveur Web d’applications, et peut être hébergé sur des PC Windows et des plates-formes informatiques NI Real-Time. Cette fonctionnalité de LabVIEW présente l’avantage de pouvoir s’interfacer avec de nombreux périphériques et applications compatibles HTTP, qui ne se limitent pas aux produits National Instruments. De nombreux utilisateurs peuvent surveiller une ou plusieurs applications à partir de plusieurs plates-formes et emplacements différents. La convivialité et l’efficacité dépendront du client Web et de votre maîtrise de la programmation d’applications Web.

Les données sont échangées avec le VI de méthode Web en utilisant une URL et des méthodes HTTP standard. Par exemple, vous pouvez fournir des données en entrée pour les commandes du VI de méthode Web à partir d’un client Web en utilisant des méthodes HTTP standard, telles que POST. Les données sont renvoyées au client HTTP via les terminaux de sortie du VI ou en continu via le serveur Web.  Avec la méthode de terminal, lorsque le serveur Web reçoit une requête, il renvoie au client Web toutes les données câblées à un terminal de sortie sous forme de chaîne XML (Extensible Markup Language). Le service Web peut également être configuré pour renvoyer des données au format HTML (Hypertext Markup Language), JSON (JavaScript Object Notation) ou texte. Un VI de méthode Web peut aussi être configuré pour utiliser le mode de sortie de flux. Ce mode de sortie vous permet de renvoyer des données dans un format personnalisé ; vous pouvez implémenter la bufférisation et utiliser des en-têtes HTML personnalisés. Avec ces deux modes de sortie disponibles, les services Web sont adaptés aux applications de surveillance ou de streaming.

Les points suivants résument le protocole réseau le mieux adapté à chaque type de communication dans les applications de contrôle/commande des machines.

Communication par commande ou message

La communication basée sur des messages requiert une transmission fiable et des vitesses de transfert rapides. Le tableau 1.3 énumère toutes les options de communication par messages. Les flux réseau sont les mieux adaptés à cette application car ils sont fiables, faciles à utiliser et peuvent offrir des vitesses de transfert rapides. Cependant, si vous avez besoin d’une configuration système 1:N ou N:1, ou si vous devez transférer des données avec des applications tierces, les protocoles TCP/UDP sont plus appropriés. Pour faciliter l’utilisation, il est toujours possible d’utiliser plusieurs flux réseau si N est petit. Les services Web peuvent être utilisés avec des performances similaires à celles du TCP avec analyse, mais peuvent être plus conviviaux.

Tableau 1.3 Protocoles réseau adaptés à la communication par messages

Communication des données de processus

La communication des données de processus ne s’intéresse qu’à la dernière valeur. Par conséquent, les taux de livraison et de transfert garantis ne sont pas aussi importants. Le tableau 1.4 énumère toutes les options de communication de données de processus. Les variables partagées sont les fonctionnalités LabVIEW recommandées pour cette application. Elles sont faciles à utiliser et permettent de nombreuses configurations système. Elles gèrent également automatiquement la connexion réseau. Les services Web doivent être utilisés lorsque les données doivent être surveillées à partir de plusieurs emplacements sur des ordinateurs sans LabVIEW. De même, TCP/UDP doit être utilisé si les données doivent être surveillées par des applications tierces.

Tableau 1.4 Protocoles réseau adaptés à la communication de données de processus

Communication en continu/bufférisée

La communication en continu requiert des vitesses de transfert rapides et une transmission fiable. Le tableau 1.5 énumère toutes les options de communication en continu/bufférisée. Les flux réseau sont recommandés pour cette application. TCP/UDP doit être utilisé pour les configurations N:1 ou 1:N et si vous devez transférer des données en continu vers une application tierce.

Tableau 1.5 Protocoles réseau adaptés à la communication en continu/bufférisée