Introduction aux protocoles de communication des données en logique des échelles

L'automatisation industrielle moderne dépend de l'échange de données sans faille entre les contrôleurs logiques programmables (PLC), les capteurs, les actionneurs, les lecteurs, les interfaces homme-machine (HMI) et les systèmes de contrôle de supervision. La mise en œuvre de protocoles de communication de données dans les systèmes logiques d'échelle est une compétence fondamentale pour les ingénieurs en automatisation qui doivent construire des solutions de contrôle fiables, interopérables et durables.

La logique de la ladder, conçue à l'origine pour imiter les circuits de relais électriques, a évolué pour soutenir des capacités de réseautage complexes. Les ingénieurs doivent comprendre non seulement le flux logique de leurs programmes, mais aussi les règles sous-jacentes qui régissent la circulation des données à travers les réseaux industriels.

Principes fondamentaux de la communication des données industrielles

Les protocoles de communication des données fonctionnent comme les règles de trafic pour les réseaux industriels. Ils définissent la façon dont les appareils formatent, transmettent, reconnaissent et vérifient les messages d'erreur. Dans un système automatisé typique, plusieurs CPL peuvent devoir partager les comptes de production, les états d'alarme ou les valeurs de consigne.

Couches de modèles OSI pertinentes à la logique des échelles

Alors que les programmeurs logiques d'échelle fonctionnent rarement directement avec les sept couches du modèle Open Systems Interconnection (OSI), la compréhension des couches physiques, de données, réseau et application aide à diagnostiquer les défaillances de communication. La couche physique couvre le câblage et les tensions de signal, la couche de liaison de données gère la détection des erreurs, la couche réseau gère l'adressage et le routage, et la couche application définit la structure des données pour des fonctions spécifiques telles que la lecture d'un registre ou l'écriture d'une bobine.

Dans la pratique, la plupart des bibliothèques de communication PLC abstractionnent ces couches. Cependant, lorsqu'une défaillance de communication survient, sachant qu'un problème de couche physique présente une différence par rapport à une erreur de configuration de couche d'application peut réduire de façon spectaculaire le temps de dépannage.

Modèle client-serveur et modèle producteur-consommateur

Dans le modèle client-serveur, un appareil maître (généralement le PLC ou le HMI) demande des données à partir d'un appareil esclave (un capteur ou un bloc d'E/S à distance). Ce modèle fonctionne bien pour les systèmes basés sur des sondages où le timing déterministe n'est pas critique. Le modèle producteur-consommateur, utilisé par des protocoles tels qu'EtherNet/IP et PROFINET, permet à tout appareil de publier des données au réseau sans attendre de demande. Ce modèle réduit les frais généraux du réseau et améliore les performances en temps réel, en particulier dans les boucles de contrôle à grande vitesse.

Lors de la mise en œuvre de la logique échelle, le choix entre ces modèles influence la structure des routines de communication. Les implémentations client-serveur utilisent souvent des blocs de lecture/écriture séquentielle, tandis que les implémentations producteur-consommateur reposent sur des mises à jour de données programmées qui déclenchent les échelons échelles asynchrones.

Protocoles industriels communs en profondeur

Le choix d'un protocole de communication dépend de la topologie du réseau, du volume de données, des exigences en temps réel et de la compatibilité des équipements existants.

Modbus TCP/IP et Modbus RTU

Modbus RTU fonctionne sur des lignes série (RS-232 ou RS-485) en encodage binaire, tandis que Modbus TCP/IP fonctionne sur Ethernet en utilisant un port TCP standard. Les implémentations logiques de la ladder utilisent généralement des codes de fonction pour lire des bobines (sorties numériques), lire des entrées discrètes, lire des registres de tenue (valeurs analogiques 16 bits) et écrire sur des bobines ou des registres.

Une routine typique d'échelle Modbus TCP/IP implique de configurer le PLC en tant que client ou serveur. En tant que client, le PLC lance des requêtes de lecture et d'écriture sur des périphériques distants. En tant que serveur, le PLC répond aux demandes des HMI ou d'autres PLC. De nombreux PLC modernes fournissent des blocs de fonctions tels que MB Client ou MB Server qui encapsulent la gestion du protocole, exigeant du programmeur seulement pour spécifier l'adresse IP, l'adresse de registre et la longueur des données.

Un écueil commun dans les implémentations Modbus est le registre de la confusion. La spécification Modbus utilisait historiquement des adresses à 5 chiffres (p. ex. 40001 pour la tenue de registres), tandis que les implémentations plus récentes utilisaient des adresses à 6 chiffres (p. ex. 400001). Certains appareils utilisent également des adresses à zéro où le registre 0 correspond à l'adresse 40001.

EtherNet/IP

EtherNet/IP, développé par Allen-Bradley et désormais géré par ODVA, est un protocole important dans la fabrication nord-américaine. Il utilise le modèle producteur-consommateur et fonctionne sur l'infrastructure Ethernet standard. EtherNet/IP prend en charge à la fois les données implicites (données d'entrées-sorties en temps réel) et explicites (configuration et diagnostic).

La mise en œuvre d'EtherNet/IP en logique d'échelle nécessite une configuration minutieuse des rôles de scanner (maître) et d'adaptateur (esclave). Le scanner demande des données à un rythme spécifié appelé l'intervalle de paquets demandés (IRP). La configuration de l'IPR trop faible peut surcharger le réseau, tout en le réglant trop haut retarde les données critiques.

Les routines logiques de ladder comprennent souvent des vérifications de l'état de la connexion et des erreurs de temps. Lorsqu'une connexion EtherNet/IP tombe, le PLC doit gérer gracieusement la faute, soit en maintenant les dernières sorties valides, en passant à un état sûr, soit en signalant une alarme.

PROFIBUS et PROFINET

PROFIBUS, un protocole série de bus de terrain, est un standard en automatisation européenne depuis des décennies. Il utilise un mécanisme de passage à jetons où les appareils transmettent à tour de rôle des données. PROFINET, son successeur Ethernet, offre une bande passante et des capacités en temps réel plus élevées pour le contrôle des mouvements et les lignes d'emballage à grande vitesse.

PROFINET distingue trois niveaux de performance : RT (Real-Time) pour l'automatisation typique, IRT (Isochronous Real-Time) pour le contrôle de mouvement synchronisé, et NRT (Non-Real-Time) pour le trafic TCP/IP standard. Dans la logique échelle, la configuration PROFINET est généralement gérée par le logiciel d'ingénierie PLC, qui génère automatiquement la configuration matérielle et les paramètres de communication. Le programmeur mappera ensuite les données de l'interface PROFINET vers les emplacements de mémoire interne.

Lors de l'intégration d'un dispositif PROFINET, le nom de l'appareil et son adresse IP doivent correspondre à la configuration de l'outil d'ingénierie. La logique de la ladder peut surveiller l'état de l'appareil en utilisant des blocs de diagnostic qui signalent la santé de la connexion, la cohérence des données et les défauts matériels.

CANouvert

CANopen, construit sur la couche physique du réseau de contrôleurs (CAN), est largement utilisé dans les machines mobiles, les appareils médicaux et les systèmes d'automatisation plus petits. Il définit les dictionnaires d'objets, les objets de communication (AOP pour les données de processus et AOD pour les données de configuration) et les fonctions de gestion de réseau.

La mise en œuvre de la logique de l'échelle CANopen implique souvent des blocs de fonctions de niveau supérieur qui abstractionnent les détails de communication. Le programmeur configure l'ID de nœud, le taux de baud et la cartographie des objets. La logique de la ladder peut alors lire ou écrire dans des entrées spécifiques du dictionnaire d'objets en utilisant des SDO pour des modifications de paramètres ou des AOP peu fréquentes pour des données de processus cycliques.

Un avantage de CANopen est son comportement déterministe et sa faible latence. Cependant, sa bande passante limitée (généralement 1 Mbps maximum) la rend inapte pour les grands transferts de données. Les ingénieurs devraient réserver CANopen pour les boucles de contrôle en temps réel et les signaux d'état, et non pour l'enregistrement de données en vrac ou les téléchargements de configuration.

Mise en œuvre des protocoles de communication en logique des échelles

L'intégration d'un protocole de communication dans un programme logique d'échelle va au-delà de la simple mise en place d'un bloc de fonction sur un échelon. L'implémentation doit tenir compte de la cohérence des données, du moment, de la récupération des erreurs et des transitions de l'état système.

Configuration du matériel et adresse

La première étape consiste à configurer le matériel et l'interface réseau de PLC, ce qui comprend l'attribution d'adresses IP, de masques sous-nets et de paramètres de passerelle pour les protocoles Ethernet. Pour les protocoles série comme Modbus RTU, configurer le taux de baud, la parité, les bits d'arrêt et le mode de transmission (ASCII ou RTU).

Les PLC modernes stockent ces paramètres dans un fichier de configuration matérielle que le logiciel d'ingénierie télécharge au contrôleur. Le programme logique d'échelle renvoie à l'interface réseau à l'aide d'un identifiant logique. Par exemple, un PLC Siemens peut utiliser l'instruction pour établir une connexion TCP, en se référant à un descripteur de connexion qui contient l'adresse IP et le numéro de port.

Cartographie des données et répartition des registres

Une fois l'interface réseau configurée, définissez les zones de mémoire pour les données entrantes et sortantes. La plupart des PLC utilisent des blocs de données globaux, des balises ou des registres à cette fin.

Envisager d'utiliser une approche structurée comme un type d'utilisateur défini (UDT) ou un bloc de données structuré pour organiser les paramètres connexes. Par exemple, une structure de contrôle de lecteur peut contenir des champs statut, vitesse de réglage, rétroaction actuelle et code défaut. Cette organisation simplifie le débogage et fait l'auto-documentation du programme.

Lors de la cartographie des registres entre différents appareils, prêtez une attention particulière aux types de données et à la commande des octets. Les registres Modbus sont de 16 bits, tandis qu'une valeur de point flottant de 32 bits nécessite deux registres consécutifs. Certains appareils utilisent l'ordre des octets Big Endian (le plus important octet en premier), tandis que d'autres utilisent Little Endian. La logique des échelles doit inclure des instructions d'échange ou s'appuyer sur des fonctions intégrées pour réorganiser correctement les octets.

Construction de routines de communication

Les routines de communication s'exécutent généralement de manière cyclique, déclenchée par un minuteur ou la fin de la numérisation du programme principal. La routine vérifie d'abord l'état de la connexion. Si la connexion est saine, elle émet des requêtes de lecture et d'écriture.

Voici une séquence de base pour une routine cliente Modbus TCP/IP :

  1. Activer le bloc de fonction client Modbus avec une gâchette de bord ascendant ou une impulsion cyclique.
  2. Spécifiez l'adresse IP, le port (généralement 502) et le code de fonction.
  3. Fournir les adresses tampons locales pour les données de demande et de réponse.
  4. Surveillez les sorties de la fonction et les sorties d'erreur.
  5. Si vous réussissez, déplacez les données reçues vers les balises mondiales désignées.
  6. Si une erreur se produit, incrémentez un compteur d'erreurs, enregistrez le code d'erreur et reessayez éventuellement après un délai.

Pour les protocoles producteur-consommateur comme EtherNet/IP, la routine peut être plus simple car les données arrivent asynchronement. Le programme logique d'échelle traite de nouvelles données lorsqu'un changement de données d'entrée est détecté ou à chaque balayage. Cependant, le programmeur doit toujours mettre en œuvre des contrôles de cohérence, comme la vérification que les timestamps d'âge des données ne dépassent pas un seuil.

Gestion des erreurs et diagnostics

La manipulation d'erreurs robustes distingue le code prêt à la production de la logique du prototype. Les erreurs de communication courantes comprennent les temps de connexion, la réponse non valide CRC, l'appareil occupé et la congestion du réseau.

Implémenter une machine d'état qui gère les rétrigues de communication et les comportements de repli. Par exemple:

  • État 0: Idle – aucune communication active; attendre qu'un minuteur déclenche un scan.
  • État 1: Request – envoie la requête de lecture ou d'écriture; démarre un timeout timer.
  • État 2 : Attendez la réponse – vérifiez si vous avez terminé ou si vous avez terminé votre examen.
  • État 3: Réponse au processus – déplacer les données vers la mémoire de travail; vérifier les erreurs.
  • État 4: Gestion des erreurs – log de l'erreur; déterminer si vous devez réessayer ou définir des sorties dans un état sûr.

Inclure des informations diagnostiques dans l'écran de l'IMH, comme l'état de la communication (connecté, déconnecté, défectueux), le dernier code d'erreur et les compteurs pour les transactions réussies et ratées.

Techniques de communication avancées

Après avoir établi une communication de base, les ingénieurs doivent souvent mettre en place des modèles plus sophistiqués pour répondre aux exigences de performance et de fiabilité.

Sondage et calendrier de plusieurs appareils

Lorsqu'un PLC communique avec de nombreux appareils, le sondage de chaque appareil dans chaque balayage peut dépasser la bande passante de communication ou causer des décalages. Implémenter un calendrier de sondage à la ronde, où chaque appareil est sonné à un taux proportionnel à sa criticité.

Créez une table de vote en mémoire qui stocke l'adresse IP de l'appareil, la carte de registre et l'intervalle de vote. Une routine de l'échelle de routine par les entrées de table, en émettant une demande pour le prochain appareil dont le chronomètre de vote a expiré. Cette approche distribue uniformément la charge réseau et assure des mises à jour opportunes pour tous les appareils.

La consommation de données et la cohérence

Dans les applications à grande vitesse, le PLC peut recevoir de nouvelles données d'un appareil avant que le scanner précédent n'ait terminé le traitement des données anciennes. Cette condition de course peut corrompre des ensembles de données cohérents, surtout lors de la lecture de plusieurs registres qui doivent être mis à jour atomiquement.

Si le protocole ne garantit pas la cohérence, implémentez un mécanisme double tampon en logique échelle. Les données entrantes sont écrites dans un tampon intermédiaire. Une fois toutes les données d'un groupe logique reçues, un drapeau de contrôle signale la logique d'application pour copier le tampon intermédiaire dans le tampon de travail atomiquement. Cette approche garantit que la logique de contrôle voit toujours un instantané cohérent des données.

Redondance et échec

Certains PLC prennent en charge les ports Ethernet doubles pour la redondance des médias en utilisant des protocoles tels que MRP (Media Redundancy Protocol) ou PRP (Parallel Redundancy Protocol). Dans la logique des échelles, la redondance consiste généralement à surveiller les deux canaux de communication et à passer au canal de sauvegarde lorsque le primaire échoue.

Pour une redondance de niveau supérieur, connectez le PLC à deux réseaux distincts ou utilisez plusieurs piles de protocole. Par exemple, un système critique en matière de sécurité peut utiliser EtherNet/IP pour le contrôle standard et PROFIsafe pour les données de sécurité, avec le programme logique d'échelle arbitrer entre les deux canaux.

Conception de la sécurité dans la mise en œuvre du Protocole

Les réseaux industriels sont de plus en plus connectés aux systèmes informatiques d'entreprise et à Internet, les exposant aux menaces de cybersécurité. Bien que la logique de l'échelle ne puisse à elle seule résoudre tous les défis de sécurité, les ingénieurs peuvent mettre en place des mesures de base dans leurs programmes.

Authentification et contrôle d'accès

Dans la logique de l'échelle, restreindre l'accès à l'écriture des registres critiques en fonction des jetons de session ou des autorisations de niveau de superviseur. Par exemple, exiger qu'un opérateur entre un mot de passe sur l'HMI avant que la logique de l'échelle ne permette aux requêtes d'écriture de définir des points. Cela empêche les changements accidentels ou non autorisés.

Intégrité et validation des données

Valider toutes les données reçues du réseau avant de les utiliser dans les calculs de contrôle. Vérifier que les valeurs analogiques se situent dans les plages prévues, que les mots d'état contiennent des motifs valides et que les numéros de séquence augmentent correctement. Si une valeur reçue échoue, la logique de l'échelle doit rejeter les données, enregistrer un événement diagnostique et utiliser la dernière valeur valide ou une valeur de sécurité par défaut.

Le CRC vérifie au niveau du protocole les erreurs de transmission des captures, mais la validation sémantique capture les problèmes de niveau d'application tels qu'un dispositif qui envoie une lecture de pression de 10 000 PSI lorsque le capteur a une portée maximale de 100 PSI.

Segmentation du réseau et considérations relatives aux pare-feu

Bien que ce ne soit pas directement mis en œuvre dans la logique des échelles, les ingénieurs doivent comprendre l'architecture du réseau. Placer des dispositifs d'automatisation sur un VLAN séparé ou utiliser des pare-feu industriels réduit la surface d'attaque. Dans la logique des échelles, envisager d'ajouter des messages de battement cardiaque que les appareils doivent envoyer périodiquement.

Dépannage des problèmes de communication

Même des systèmes de communication bien conçus rencontrent des problèmes. Développer une approche systématique de dépannage permet d'économiser des heures d'arrêt.

Modes courants de défaillance

Les problèmes de couches physiques comprennent les connecteurs lâches, les câbles endommagés ou les interférences électromagnétiques causant des images corrompues. Ceux-ci présentent souvent des erreurs de communication intermittentes. Utilisez un commutateur géré pour surveiller les statistiques de port pour détecter les erreurs CRC, les gouttes de paquets et les volets de liaison.

Les erreurs de configuration surviennent lorsque les adresses IP, les masques sous-net ou les paramètres de protocole du périphérique ne correspondent pas à la configuration du PLC. Un exemple commun est un périphérique configuré pour le mode Modbus ascii alors que le PLC attend le mode RTU.

Les problèmes de couche d'application comprennent les adresses incorrectes des registres, les types de données mal appariés ou les erreurs de commande par octets. Par exemple, une valeur de 32 bits flottant-point peut être lue comme deux entiers 16 bits et mal interprétée.

Logique des échelles de diagnostic

Inclure des échelons de diagnostic dans votre programme qui surveillent les statistiques de communication. Affichez les éléments suivants sur l'IMH :

  • État de la communication pour chaque appareil (connecté, déconnecté, défectueux)
  • Nombre d'opérations réussies de lecture et d'écriture depuis le démarrage
  • Nombre d'opérations ayant échoué depuis le démarrage
  • Dernier code d'erreur et timestamp
  • Âge des données actuelles (temps depuis la dernière réception des données valides)
  • Durée du cycle de scrutin pour chaque dispositif

Ces diagnostics permettent aux exploitants de cerner les problèmes de développement avant qu'ils ne causent des arrêts de production. Par exemple, un nombre de défaillances sans cesse croissant peut indiquer un câble dégradant qui a besoin d'être remplacé.

Utilisation d'outils d'ingénierie pour le débogage

La plupart des environnements d'ingénierie PLC fournissent des outils intégrés pour la surveillance de la communication. Utilisez la table de veille ou la vue des données pour inspecter directement les adresses tampons. Comparez les valeurs attendues avec les valeurs réelles pour repérer les écarts.

Pour une analyse plus approfondie, connectez un analyseur de protocole au réseau. Capturez le trafic pendant le fonctionnement normal et les événements de défaillance. Comparez les paquets capturés avec les spécifications du protocole pour vérifier que le PLC et le périphérique à distance échangent correctement les données.

Meilleures pratiques pour les systèmes de communication prêts à la production

S'inspirant de l'expérience acquise sur le terrain dans plusieurs industries, les pratiques suivantes conduisent systématiquement à des mises en œuvre plus fiables et plus durables.

Normes de documentation

Maintenez une matrice de communication qui énumère chaque appareil, son adresse IP ou son ID de noeud, le protocole utilisé et une carte complète du registre. Inclure le type de données, les facteurs de graduation, les unités et les plages de valeurs valides pour chaque registre. Conservez ce document dans un emplacement contrôlé par la version accessible à tous les membres de l'équipe.

Dans le programme logique échelle, utilisez des noms de tags significatifs au lieu d'adresses brutes. Une balise nommée est infiniment plus utile que . Inclure des commentaires expliquant le but de chaque bloc de fonction de communication et toute logique non évidente.

Essais et validation

Avant de déployer la logique de communication à la production, créez un environnement de test qui simule les périphériques distants. Utilisez des simulateurs logiciels disponibles auprès des fabricants de PLC ou des outils de test génériques Modbus/EtherNet/IP. Vérifiez que la logique d'échelle gère correctement les communications normales, les temps d'arrêt, les réponses non valides et les déconnexions des appareils.

Lors de la mise en service, testez chaque appareil individuellement avant de permettre la communication à l'échelle du système. Vérifiez que les valeurs écrites atteignent l'appareil et que les valeurs lues sont mises à jour correctement dans la mémoire PLC.

Considérations relatives à l'entretien

Concevoir des routines de communication pour que les appareils puissent être ajoutés, supprimés ou remplacés sans reprogrammer le système entier. Par exemple, stocker les paramètres de configuration des appareils dans les tables de données plutôt que les coder dur dans la logique d'échelle.

Planifier périodiquement les contrôles de santé de la communication qui se déroulent pendant les pauses de production. Ces contrôles peuvent exercer tous les chemins de communication et vérifier que les données circulent correctement.

Conclusion

La mise en œuvre de protocoles de communication de données dans les systèmes logiques d'échelle exige une compréhension solide des principes de réseautage et des techniques de programmation PLC. En sélectionnant les protocoles appropriés, en configurant correctement le matériel de communication, en construisant des routines logiques d'échelle robustes et en suivant les meilleures pratiques de l'industrie, les ingénieurs peuvent créer des systèmes d'automatisation qui échangent des données de façon fiable même dans des environnements industriels exigeants.

Le paysage de la communication industrielle continue d'évoluer, les technologies telles que l'OPC UA, le MQTT et le Réseau sensible au temps (TSN) étant adoptées. Les ingénieurs qui maîtrisent les fondamentaux couverts par ce guide seront bien préparés à adopter ces nouveaux protocoles à mesure qu'ils deviendront courants.

Pour plus de détails, consultez la spécification Modbus Application Protocol v1.1b3 et la spécification ODVA EtherNet/IP. De nombreux fabricants de PLC fournissent également des notes d'application et un code d'exemple pour la mise en œuvre de protocoles de communication, qui servent d'excellents points de départ pour vos propres projets.