Passerelle intelligente pour ponts roulants et informatique en périphérie : mise en œuvre pratique de l'acquisition de données OPC UA et de la conversion de protocoles

La passerelle intelligente et le système de calcul en périphérie des ponts roulants constituent le maillon clé reliant la couche des équipements à la couche d’information : ils assurent la conversion de protocoles, la collecte de données, le calcul en périphérie et la transmission des données en cas de coupure de connexion entre les automates programmables (PLC) et les variateurs de fréquence, d’une part, et les systèmes MES, SCADA et les plateformes cloud, d’autre part. S'appuyant sur la passerelle industrielle de périphérie IOT2050 de Siemens et sur sa propre plateforme de données de périphérie, Krude Heavy Industry a mis en place une architecture standardisée de collecte de données et de conversion de protocoles pour les ponts roulants, prenant en charge la conversion en temps réel entre cinq protocoles : PROFINET, OPC UA, Modbus TCP, MQTT et REST API. une seule passerelle pouvant collecter simultanément les données de fonctionnement de 8 ponts roulants, avec un temps de latence de traitement en périphérie inférieur à 50 ms et une transmission des données en cas de coupure de réseau sans aucune perte. Cet article expose de manière systématique cette mise en œuvre technique, depuis le choix du matériel et la configuration de la pile de protocoles jusqu’à la modélisation des données, en passant par le déploiement et l’exploitation.

I. Choix du matériel pour les passerelles industrielles de périphérie et architecture du système

Le matériel central du système d'acquisition de données des ponts roulants est une passerelle industrielle de périphérie, déployée dans l'armoire de commande du pont roulant ou dans un poste de commande de terrain adjacent ; elle est connectée en amont au réseau de l'atelier et, en aval, directement au PLC du pont roulant via une interface PROFINET. Dans le cadre de sa solution standardisée, Krud Heavy Industry a choisi la passerelle industrielle de périphérie IOT2050 de Siemens comme plateforme matérielle principale. Celle-ci est équipée d’un processeur quadricœur ARM Cortex-A72 (1,5 GHz) et de 4 Go de mémoire vive DDR4, et intègre deux ports Ethernet RJ45 Gigabit, deux ports USB 3.0 et un emplacement pour carte SD de qualité industrielle ; elle exécute les applications « Industrial Edge » de Siemens et « Edge Apps » basées sur des conteneurs Linux. L’IOT2050 prend en charge une plage de températures de fonctionnement étendue allant de -20 °C à 60 °C et présente un indice de protection IP20 ; il est adapté à une installation sur un rail DIN dans une armoire de commande.

L'architecture du système repose sur un déploiement à trois niveaux : terminal, périphérie et cloud. La couche des équipements terminaux comprend l'automate S7-1500 situé dans chaque armoire de commande de pont roulant, le variateur G120, le module d’interface codeur et l’ensemble des capteurs situés dans chaque armoire de commande du pont roulant — l’automate transmet les données d’exploitation à la passerelle via le cycle PROFINET IO (10 ms), tandis que le variateur G120 transmet la vitesse du moteur, le courant, la température et les codes d’erreur via le profil de configuration PROFINET pour les variateurs. Au niveau de la périphérie, une passerelle IOT2050 est déployée et exécute quatre applications Edge principales : un serveur OPC UA (agrégeant les données UA de tous les nœuds API), un moteur de conversion de protocoles (PROFINET ↔ OPC UA ↔ Modbus ↔ MQTT), une unité de traitement des données en périphérie (file d’attente de mise en cache + reprise après interruption + compression des données) et un module de sécurité des données (cryptage TLS + liste de contrôle d’accès). La couche cloud comprend le système d’exécution de la production (MES), la plateforme de supervision SCADA et le grand écran de gestion et d’exploitation du jumeau numérique, qui communiquent avec la passerelle périphérique via un client OPC UA ou un courtier MQTT.

II. Configuration du serveur OPC UA et modélisation des nœuds de données

OPC UA est le protocole de communication central qui relie l'automate programmable (PLC) du pont roulant au système de niveau supérieur. Krud Heavy Industry a conçu un modèle d’information standardisé pour les ponts roulants au sein du serveur OPC UA de la passerelle périphérique. Conformément à la norme complémentaire OPC UA for Machinery (IEC 62541-100), les nœuds de données du système de commande des ponts roulants ont été regroupés et nommés de manière à garantir la cohérence de la structure des données entre les différents ponts roulants, les systèmes MES et SCADA n’ont donc pas besoin d’être adaptés individuellement pour chaque pont roulant.

Le modèle d'information est divisé en quatre niveaux selon la hiérarchie des équipements. Le premier niveau est le niveau ” Site ”, qui correspond à un atelier ou à un bâtiment : le chemin d'accès ” /Site/Workshop_01 ” regroupe l'ensemble des ponts roulants de cet atelier. Le deuxième niveau est le niveau « Ligne de production » (Area), qui correspond à un groupe de ponts roulants situés sous la même travée ou au même poste de travail — le chemin d’accès « /Area/Bay_A » regroupe les 3 ponts roulants de cette travée. Le troisième niveau est le niveau « Équipement » (Device), qui correspond à un pont roulant individuel — le chemin d’accès « /Device/Crane_01 » contient l’ensemble des données de ce pont roulant. Le quatrième niveau est celui des blocs fonctionnels (Function), qui correspond aux différentes unités fonctionnelles du système de commande du pont roulant — notamment le groupe de commande de mouvement (Motion) (comprenant le mode de fonctionnement, la position cible, la position réelle, la vitesse et l’état d’accélération), le groupe de variateurs de fréquence (Drive) (comprenant le courant, la vitesse de rotation, la température, l’état de fonctionnement et les codes d’alarme des moteurs de chaque mécanisme) et le groupe de freins (Brake) (comprenant l’état d’activation/ fermé des deux jeux de freins, le courant des électroaimants, le nombre de cycles d’usure et les indicateurs de désynchronisation), le groupe d’état de sécurité (comprenant les états STO/SLS/SBC/SDI, le nombre de déclenchements d’arrêt d’urgence et le journal des événements de sécurité) et le groupe de diagnostic (comprenant la durée de fonctionnement du système, la file d’attente des codes d’erreur et l’horodatage du PLC).

Les nœuds de données sont nommés selon la convention « camel case » ; chaque nœud contient la définition du type de données et une description. Motion.ActualPosition (Int32, unité : mm), Motion.Speed (Real, unité : m/s), Drive.Current_A (Real, unité : A), Brake.Status_A (Boolean, True = activé / Brake fermé), Brake.UnsyncCount (UInt16), Safety.STO_Active (Boolean), Safety.EventCount (UInt32). Lors du déploiement sur site, un mappage d’adresses et une vérification des types de données sont effectués pour les 26 nœuds OPC UA standard de chaque pont roulant. Une fois le mappage terminé, l’outil UA Expert est utilisé pour analyser et vérifier la lisibilité de tous les nœuds ainsi que l’exactitude des types de données.

III. Couche de conversion de protocole : conversion PROFINET vers OPC UA/Modbus/MQTT

La conversion de protocole est la fonction principale de la passerelle périphérique. Le PLC du pont roulant transmet des données à la passerelle selon le cycle en temps réel de PROFINET IO (10 ms) ; le moteur de conversion de protocole de la passerelle analyse les données PROFINET IO pour les convertir en un format de données interne unifié, puis les réencapsule en fonction des exigences des différents protocoles cibles. La passerelle exécute simultanément trois interfaces de sortie : un serveur OPC UA, un serveur Modbus TCP et un client MQTT, qui desservent respectivement trois types de clients : le système MES, le système SCADA et la plateforme cloud.

Configuration de sortie OPC UA. Le serveur OPC UA de la passerelle est développé à partir de la pile open source open62541 et prend en charge le protocole binaire OPC UA (port par défaut 4840) ainsi que le protocole HTTPS (port 443). La stratégie de sécurité du serveur est configurée avec un cryptage et une signature Basic256Sha256 (SecurityMode=SignAndEncrypt) ; l’authentification des clients s’effectue via un mode de liste blanche de certificats X.509 : seuls les clients OPC UA dont les certificats figurent dans la liste de confiance de la passerelle sont autorisés à se connecter et à lire les données. Le serveur publie les 26 nœuds standard de pont roulant mentionnés ci-dessus. Une fois que le client UA (tel que le client OPC UA d’un système MES) a découvert l’intégralité de la structure des nœuds via l’opération « Browse », il lit les données en temps réel par lots sous forme d’abonnement, l’intervalle d’échantillonnage minimal pris en charge étant de 50 ms.

Configuration de la sortie Modbus TCP. La passerelle mappe les données standard du pont roulant vers la table des registres Modbus ; les adresses de registres sont attribuées de manière consécutive à partir de 40001 : 40001 à 40006 correspondent aux 6 registres du groupe de fonctions « Motion », 40007 à 40014 correspondent aux 8 registres du groupe de fonctions « Drive », 40015 à 40019 aux 5 registres du groupe de fonctions « Brake » et 40020 à 40023 aux 4 registres du groupe de fonctions « Safety ». Chaque registre occupe 2 octets ; les données 32 bits (telles que Real ou Int32) occupent deux registres consécutifs. Le système SCADA, en tant que maître Modbus TCP (port par défaut 502), interroge périodiquement les différentes adresses de registres ; une seule instruction de lecture permet de récupérer en bloc les données d’un segment d’adresses consécutives, ce qui réduit la charge réseau.

Configuration de la sortie MQTT. L'unité de traitement des données en périphérie de la passerelle se connecte en tant que client MQTT au broker MQTT de la plateforme cloud (tel que EMQX ou VerneMQ, port par défaut 8883), en utilisant le protocole TLS pour le chiffrement des communications. Les sujets MQTT sont organisés selon la hiérarchie des équipements de grue et adoptent une structure à trois niveaux : topic/workshop_id/crane_id/function/parameter, par exemple “ krunde/workshop01/crane_01/motion/position ”. La publication des données utilise un QoS = 1 pour garantir au moins une livraison ; la charge de données est encapsulée au format JSON et comprend trois champs : l’horodatage, la valeur des données et l’indicateur de qualité. La fréquence typique de publication MQTT est de 1 seconde par transmission, avec un volume de données d’environ 200 octets par transmission et par pont roulant ; le trafic réseau généré par 8 ponts roulants fonctionnant simultanément est d’environ 1,6 Ko/s.

IV. Traitement des données en périphérie et reprise du transfert après une interruption de connexion

La fiabilité de la collecte des données d'exploitation des ponts roulants repose sur la mise en cache locale des données par la passerelle périphérique et sur le mécanisme de transmission différée en cas de coupure de connexion. L’environnement des réseaux industriels — en particulier le roaming Wi-Fi provoqué par le déplacement des ponts roulants le long des rails ou les interférences harmoniques des variateurs de fréquence dans l’atelier — peut entraîner des interruptions temporaires de la connexion réseau entre la passerelle et la plateforme cloud. La plateforme de données en périphérie de Krud Heavy Industry a donc mis au point un mécanisme de mise en cache à tampon circulaire et de reprise de transfert après interruption.

La couche de mise en cache des données utilise une architecture de cache à deux niveaux : mémoire vive et carte SD. Le cache de premier niveau est un tampon circulaire (Ring Buffer) en mémoire vive, d'une capacité de 10 000 enregistrements (soit environ 2 Mo de mémoire, en supposant que chaque enregistrement occupe 200 octets). Le délai d’écriture dans la mémoire cache est inférieur à 1 ms ; il est mis en œuvre via le modèle producteur-consommateur : les threads de sortie OPC UA/Modbus/MQTT, en tant que consommateurs, lisent les données dans la mémoire cache et les transmettent ; une fois la transmission réussie, les données sont marquées comme traitées. Le cache de deuxième niveau est constitué d’un fichier de cache sur la carte SD. Lorsqu’une interruption du réseau entraîne une accumulation de données dépassant le seuil de mémoire (80% par défaut), l’unité de traitement des données en périphérie écrit automatiquement les données en attente dans le fichier de cache de la carte SD. La capacité de la mémoire tampon sur carte SD dépend de la taille de la carte (carte SD de qualité industrielle de 32 Go recommandée) ; en comptant une durée maximale de mise en mémoire tampon de 7 jours, environ 1,2 Go d’espace est nécessaire ; une carte SD de 32 Go permet ainsi de stocker plus de 180 jours de données d’exploitation du pont roulant.

La stratégie de reprise du transfert après une coupure de connexion se divise en trois cas de figure. Interruption brève (≤ 30 secondes) : la mémoire cache est suffisante pour contenir les données en attente ; une fois la connexion rétablie, la connexion TCP du thread de sortie de la pile de protocoles se reconnecte automatiquement, et les données en cache sont envoyées rapidement en une seule fois, par ordre chronologique (horodatage). Interruption modérée (30 secondes à 2 heures) : une fois la mémoire saturée, les données sont automatiquement transférées vers le cache de fichiers de la carte SD ; dès le rétablissement de la connexion, le module de synchronisation des fichiers en reprise de transfert analyse la carte SD à la recherche des fichiers en cache non encore envoyés et les télécharge à un débit de 500 enregistrements par seconde (ce qui nécessite une bande passante montante d’environ 212 Ko/s, une connexion d’atelier de 10 Mbps étant suffisante). Interruption prolongée (≥ 2 heures) : lorsque la mémoire cache de la carte SD est pleine (le nombre de fichiers en cache atteint le seuil d’alerte), la plateforme périphérique applique automatiquement une stratégie d’élimination du cache — les enregistrements les plus anciens sont supprimés selon le principe FIFO (premier entré, premier sorti) en fonction de l’horodatage — tout en déclenchant une alerte locale transmise au panneau de commande du pont roulant pour avertir le personnel de maintenance. Une fois le réseau rétabli, la passerelle signale au système MES la plage de horodatages des enregistrements manquants ; c’est alors au MES de décider s’il est nécessaire de récupérer ces données à partir de l’historique de l’automate programmable (PLC).

V. Sécurité des données et contrôle d'accès

La sécurité des données de la plateforme de données en périphérie « Tianche » est conforme à la norme de cybersécurité industrielle ISA/IEC 62443. Les mesures de sécurité s'articulent autour de trois niveaux : la sécurité des transmissions, le contrôle d'accès et les journaux d'audit.

La couche de sécurité de transmission active le chiffrement TLS 1.3 sur toutes les liaisons de communication externes. Le serveur OPC UA est configuré pour un chiffrement des communications avec signature Basic256Sha256 ; les connexions non chiffrées sont désactivées (SecurityPolicy=None est interdit). Le client MQTT utilise une connexion TLS pour se connecter au broker MQTT ; la vérification du certificat du serveur s'effectue via une chaîne de certification CA — la passerelle est préinstallée avec un certificat CA d'usine, et les connexions via des certificats auto-signés sont interdites. Modbus TCP ne prenant pas en charge le chiffrement, un tunnel VPN (WireGuard) est utilisé pour établir un canal chiffré entre la passerelle périphérique et le serveur SCADA ; les paquets Modbus sont transmis à l’intérieur de ce tunnel. L’authentification du tunnel VPN s’effectue à l’aide d’une clé pré-partagée (PSK), qui est renouvelée tous les 90 jours.

Les certificats OPC UA correspondant aux trois rôles sont téléchargés et associés via l'interface d'administration Web de la passerelle. Lorsqu'un client UA se connecte, la passerelle détermine son rôle en vérifiant le champ « Common Name » du certificat client, puis applique les autorisations correspondantes. Le contrôle d'accès MQTT est mis en œuvre via des règles ACL. Chaque client MQTT est authentifié à l'aide d'un nom d'utilisateur et d'un mot de passe, et les règles ACL limitent l'étendue des sujets MQTT que le client est autorisé à publier ou à souscrire.

La couche de journal d'audit enregistre tous les événements d'accès aux données. Chaque connexion et déconnexion d’un client OPC UA, chaque abonnement ou désabonnement d’un client MQTT, ainsi que chaque requête de lecture Modbus TCP dépassant 20 fois par seconde et déclenchant une limitation de débit — tous ces événements sont consignés dans le fichier de journal d’audit de la passerelle. Le format du journal comprend l’horodatage, l’adresse IP source, le type de protocole, le type d’opération et le résultat de l’opération. Le journal d’audit est automatiquement renouvelé, avec une durée de conservation de 90 jours. Les fichiers journaux sont stockés sous forme cryptée et seuls les utilisateurs disposant du rôle « Admin » peuvent les télécharger et les consulter via l’interface d’administration Web de la passerelle.

VI. Déploiement, mise au point et gestion de l'exploitation et de la maintenance

Le déploiement et la mise en service de la passerelle périphérique Tianche suivent un processus standardisé. Première étape : installation matérielle — installation de l’IOT2050 sur le rail DIN de l’armoire de commande (occupant la largeur de 4 modules standard) ; la passerelle est connectée au commutateur PROFINET de l’atelier via un câble Ethernet CAT6A blindé, et au commutateur du réseau de bureau de l’atelier via un autre câble Ethernet (pour le transfert MQTT et la gestion à distance). L’alimentation de la passerelle est assurée par une tension de 24 V CC provenant de l’alimentation à découpage de l’armoire de commande ; un filtre CEM (courant nominal de 0,5 A) est installé à l’entrée de l’alimentation.

Deuxième étape : déploiement de l'environnement logiciel en périphérie — Diffusion à distance des images des applications Edge vers l'IOT2050 via la plateforme Industrial Edge Management (IEM) de Siemens. L'ordre de déploiement des applications est le suivant : environnement d'exécution de base (Docker et configuration réseau) → application serveur OPC UA → application moteur de conversion de protocole → application de traitement des données en périphérie → application module de sécurité des données. Une fois chaque application déployée, un script d’autotest est exécuté pour vérifier l’état de fonctionnement du conteneur et l’écoute des ports. La solution chinoise utilise SSH pour transférer le fichier de configuration Docker Compose et l’image, puis exécute la commande « docker-compose up -d » pour un déploiement en un seul clic.

Troisième étape : vérification de la communication OPC UA — Connectez-vous au serveur OPC UA de la passerelle (port par défaut 4840) à l'aide d'UA Expert, importez le certificat client émis par CA, vérifiez que la fonction « Browse » permet de parcourir l'ensemble des 26 nœuds standard, puis effectuez une opération « Read » sur chaque nœud pour confirmer que les types de données et les plages de valeurs sont corrects. À l’aide de la fonction « Subscription » d’UA Expert, s’abonner au nœud Motion.Position (intervalle d’échantillonnage de 50 ms), observer si l’actualisation des données en temps réel est stable et vérifier que le taux de perte de paquets de l’abonnement est inférieur ou égal à 0,11 TP3T.

Étape 4 : Vérification de la transmission des données — Dans le client de test MQTT, abonnez-vous au sujet ” krunde/workshop01/+/motion/position ” et vérifiez que le format JSON des données publiées par la passerelle est correct. À l’aide d’un esclave Modbus simulant un système SCADA, lisez les adresses de registres 40001 à 40023 et vérifiez que les valeurs correspondent à celles affichées côté API. Test de coupure de connexion : débranchez le câble réseau de la passerelle pendant 30 secondes, puis vérifiez que le fichier de mise en cache sur la carte SD est créé automatiquement. Une fois la connexion rétablie, le module de reprise après interruption télécharge automatiquement les données mises en cache ; vérifiez sur le système MES qu’aucune donnée n’a été perdue et que les horodatages sont continus.

Étape 5 : Configuration de la gestion de l'exploitation et de la maintenance — Configurer les règles d'alerte dans l'interface d'administration Web de la passerelle (HTTPS://192.168.x.x:8443) : un délai d'attente de connexion du client OPC UA (30 secondes par défaut) déclenche une alerte par e-mail ; une perte de signal de « heartbeat » du broker MQTT (par défaut : 60 secondes sans réponse au ping) déclenche une alerte ; un taux d’utilisation de la mémoire cache de la carte SD supérieur à 80% déclenche une alerte ; une utilisation du processeur de la passerelle supérieure à 80% pendant 5 minutes consécutives déclenche une alerte. Toutes les alertes sont envoyées via SMTP à l’adresse e-mail des ingénieurs d’exploitation, tandis que l’état sur site est indiqué par les voyants LED du panneau de commande local (vert : fonctionnement normal / rouge : alerte / jaune : maintenance).

Foire aux questions (FAQ)