Je suis engagé dans le développement, la mise en œuvre et l'exploitation de systèmes de contrôle automatique de processus (ACS TP). Au départ, il a travaillé avec les systèmes SCADA. Puis il est rapidement passé à travailler avec des protocoles d'échange d'appareils industriels. Pilotes à auto-écriture et mise en place de systèmes de collecte de données. En ce moment, mon travail passe par l'atmosphère de Modbus-s, IEC-101/104-s, OPC et d'autres protocoles.
Fig. 1. La variété des protocoles de communication utilisés dans les systèmes de contrôle industrielsEn bref sur le fonctionnement d'un système de collecte de données typique (un peu simplifié).
Fig. 2. Système d'acquisition de donnéesUn logiciel spécial appelé serveur OPC interroge les appareils connectés à l'interface RS-485. Le serveur OPC est une sorte de couche entre le système SCADA et les périphériques, traduisant la langue dans laquelle les périphériques communiquent dans une langue compréhensible pour le système SCADA. Le convertisseur Ethernet / RS-485 est utilisé pour convertir les paquets TCP / IP en paquets qui transitent par l'environnement physique de RS-485.
Ce schéma présente plusieurs inconvénients:
- Définissez, par exemple, dans le serveur OPC un délai d'attente pour une réponse de 200 ms. Dans le cas idéal, lorsque les paquets vont sur Ethernet sans retards, la communication avec les appareils se fait à une bonne vitesse (intensité). Mais si le paquet contenant la réponse est retardé, par exemple, de 300 ms (c'est plus que le délai de réponse de 200 ms), le serveur OPC considère que la réponse à la demande n'est pas arrivée et envoie la demande suivante. À ce moment, la réponse à la demande précédente arrive, mais le serveur OPC pense que c'est la réponse à la demande actuelle et envoie les mauvaises données vers le haut. En conséquence, les données sur le poste de travail "sautent". Pour échapper à de telles situations, nous allons définir un délai d'expiration plus. Prenez avec une marge de 3000 ms. Si la réponse arrive plus tôt que 3000 ms, alors nous n'attendons pas le temps restant, nous passons à la demande suivante. Jusqu'à présent, tout se passe bien, mais dès que plusieurs appareils cessent de répondre, il y a des délais de 3000 ms pour chaque appareil. Le temps de scrutin augmente.
- La plupart des protocoles utilisés dans les systèmes de contrôle de processus (Modbus, compteurs électriques) sont basés sur une interrogation séquentielle des mêmes paramètres. Étant donné que la plupart du temps les valeurs des paramètres restent inchangées, le réseau de données est utilisé pour les transmettre. Cela est irrationnel si le support de transmission est GPRS et que le trafic coûte de l'argent. De plus, dans un support de transmission GPRS, les retards de paquets peuvent atteindre plusieurs secondes. Pourquoi perdre du temps et des ressources à transférer la même chose?
Pour les situations ci-dessus, un protocole est plus approprié dans lequel les données sont transmises vers le haut par changement (sporadiquement) et regroupées par plusieurs valeurs dans un seul paquet TCP. Ces protocoles sont IEC-60870-5-104 et OPC UA. ModBus-TCP convient également, il n'y a pas de transfert de changement, mais s'il n'y a pas beaucoup de données, ils peuvent être regroupés dans un seul paquet. Ce serait bien d'avoir une sorte de contrôleur qui peut être accroché sur un rail DIN, y connecter des appareils via RS-485 et transférer des données via Ethernet au système SCADA.
En général, il existe des passerelles matérielles en nombre considérable. Mais sous la forme de solutions indivisibles toutes faites. Tout en un. Et je n'aime pas vraiment ça. Une fois, j'avais besoin d'une passerelle pour convertir les protocoles des compteurs SET-4TM en OPC UA avec six ports RS-485 et deux Ethernet. Un fabricant a une passerelle qui prend en charge les protocoles de communication nécessaires, mais peu de ports RS-485, l'autre a le bon nombre de ports RS-485, mais il n'y a pas deux ports Ethernet. Le troisième a deux ports Ethernet, mais pas tous les protocoles de communication. Le quatrième a presque tout, mais il n'y a pas d'OPC UA, disponible à bord de l'IEC-60870-5-104 ou ModBus-TCP nécessite un serveur OPC pour ces protocoles.
Et comme ce serait merveilleux: acheter un contrôleur ou un mini-PC avec OS d'un fabricant. Achetez un logiciel pour le contrôleur d'un autre. Si un fabricant de logiciels ne prend pas en charge quelque chose, achetez l'un des logiciels d'un autre, combinez les composants logiciels via une interface logicielle standard. Il semblerait qu'ici c'est un bel avenir!
C'est pourquoi les passerelles de protocole sont utilisées moins fréquemment que le serveur OPC et l'ensemble de convertisseurs Ethernet vers RS-485 en raison de leur indivisibilité dans les composants.
L'une des raisons pour lesquelles SCADA pour Linux est sous-développé: SCADA est disponible, peu de protocoles d'échange y sont pris en charge et il n'y a pas de serveurs OPC pour la communication avec l'équipement. SCADA laisse l'intégrateur un à un avec le matériel.
Le lecteur peut déjà poser une question: que pouvez-vous offrir? Qu'est-ce qui est déjà là? Il existe des serveurs OPC UA pour Linux pour les protocoles suivants:
Afin de transmettre des données au niveau supérieur non seulement via le protocole OPC UA, les «
OPC UA to Modbus Converter and IEC 60870-5-104 » ont été créés. En plus de la fonction de transfert de données de ces protocoles, le «Converter» possède un serveur Web intégré. À l'aide d'un éditeur spécial, vous pouvez dessiner un diagramme, afficher les valeurs des balises dessus, puis l'ouvrir dans un navigateur. Il s'avère que le mini-SCADA directement dans le contrôleur. Comment fonctionne l'animation du circuit, j'ai déjà écrit
ici , à propos de l'éditeur
ici . À l'avenir, «OPC UA to MQTT Converter» est prévu.
Les serveurs et convertisseurs OPC UA fonctionnent sur les architectures x64, ARMv7 et AARCH64.
Ainsi, pour le matériel, vous pouvez utiliser à la fois des solutions éprouvées basées sur des mini-ordinateurs industriels et toutes sortes de mini-ordinateurs ARM "compatibles raspberry pi". Comment installer et configurer le logiciel avec des exemples peut être lu
ici ou
ici .
En général, la structure du complexe ressemble à ceci:
Le système est évolutif. Les composants nécessaires uniquement à la résolution du problème actuel sont utilisés.
En utilisant le serveur OPC UA, notre schéma est transformé:
Nous avons ce qui suit:
- Le serveur OPC UA collecte les données des appareils via RS-485 sans délai important entre les demandes;
- Les données dans SCADA sont émises en plusieurs morceaux dans un paquet TCP pour modification;
- Vous pouvez connecter plusieurs postes de travail également configurés au serveur OPC UA. Utile si une duplication est nécessaire.
Ainsi, au lieu d'un ensemble de serveur OPC et de «convertisseur Ethernet vers RS-485», nous obtenons un appareil qui combine leurs fonctionnalités. J'aime plus ce schéma. Et vous?