Pont roulant OPC UA : acquisition de données

La passerelle intelligente et le système d’informatique en périphérie du pont roulant constituent le nœud clé entre la couche équipement et la couche information — ils assurent la conversion de protocoles, la collecte de données, le calcul en périphérie et la reprise après coupure réseau entre les automates (PLC), les variateurs de fréquence et les systèmes MES, SCADA et plateformes cloud. Kelude Industries Lourdes a développé, sur la base de la passerelle industrielle Siemens IOT2050 et de sa plateforme de données périphériques propriétaire, une architecture standardisée de collecte de données et de conversion de protocoles pour ponts roulants. Celle-ci prend en charge l’interconversion en temps réel de cinq protocoles — PROFINET, OPC UA, Modbus TCP, MQTT et REST API — avec une capacité de collecte simultanée sur 8 ponts roulants par passerelle, une latence de traitement en périphérie inférieure à 50 ms et une reprise sans perte de données après coupure réseau. Cet article expose de manière systématique cette pratique d’ingénierie, du choix du matériel à la configuration de la pile protocolaire, en passant par la modélisation des données et le déploiement opérationnel.

1. Choix du matériel et architecture système de la passerelle industrielle

Le composant matériel central du système de collecte de données du pont roulant est la passerelle industrielle, déployée dans l’armoire de commande du pont roulant ou dans un poste de commande local adjacent. Elle se connecte vers le haut au réseau de l’atelier et, vers le bas, directement à l’automate du pont roulant via l’interface PROFINET. Kelude Industries Lourdes a retenu la passerelle industrielle Siemens IOT2050 comme plateforme matérielle principale dans sa solution standardisée. Celle-ci embarque un processeur ARM Cortex-A72 quadricœur (1,5 GHz) et 4 Go de RAM DDR4, intègre deux ports Ethernet RJ45 gigabit, deux ports USB 3.0 et un emplacement pour carte SD industrielle, et exécute Siemens Industrial Edge ainsi que des Edge Apps basées sur des conteneurs Linux. L’IOT2050 fonctionne dans une plage de températures étendue de -20 °C à 60 °C, avec un indice de protection IP20, et se monte sur rail DIN dans l’armoire de commande.

L'architecture du système repose sur un déploiement en trois couches : périphérie, edge et cloud. La couche périphérique comprend, dans l'armoire de commande de chaque pont roulant, un automate S7-1500, un variateur de fréquence G120, des modules d'interface codeur et un ensemble de capteurs. L'automate publie les données de fonctionnement vers la passerelle via PROFINET IO avec un cycle de 10 ms, tandis que le variateur G120 transmet, via le profil d'entraînement PROFINET, la vitesse de rotation du moteur, le courant, la température et les codes de défaut. La couche edge déploie une passerelle IOT2050 exécutant quatre applications Edge App centrales : un serveur OPC UA (agrégeant les données UA de tous les nœuds d'automates), un moteur de conversion de protocoles (PROFINET, OPC UA, Modbus, MQTT), une unité de traitement de données en périphérie (file d'attente tampon, reprise sans perte de données après interruption et compression des données) ainsi qu'un module de sécurité des données (chiffrement TLS et liste de contrôle d'accès). La couche cloud comprend le système d'exécution de la production MES, la plateforme de surveillance SCADA et l'écran de supervision de maintenance via le Jumeau Numérique, communiquant avec la passerelle edge par client OPC UA ou courtier MQTT.

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

OPC UA constitue le protocole de communication central reliant les automates du pont roulant aux systèmes de niveau supérieur. Kelude a conçu, dans le serveur OPC UA de la passerelle edge, un modèle d'information normalisé pour le pont roulant. Conformément à la spécification OPC UA for Machinery (IEC 62541-100), les nœuds de données du système de commande sont regroupés et nommés de manière cohérente, garantissant une structure de données uniforme pour chaque pont roulant. Le MES et le SCADA n'ont ainsi pas besoin d'adaptation individuelle par appareil.

Le modèle d'information est organisé en quatre niveaux hiérarchiques. Le premier niveau, Site, correspond à l'atelier ou au bâtiment d'usine — le chemin de nœud « /Site/Workshop_01 » regroupe l'ensemble des ponts roulants de cet atelier. Le deuxième niveau, Area, correspond au groupe de ponts roulants opérant dans une même travée ou sur un même poste de travail — le chemin « /Area/Bay_A » contient les 3 ponts roulants de cette travée. Le troisième niveau, Device, correspond à un pont roulant individuel — le chemin « /Device/Crane_01 » regroupe toutes les données de cet appareil. Le quatrième niveau, Function, correspond aux unités fonctionnelles du système de commande : le groupe Motion (mode de fonctionnement, position cible, position réelle, vitesse, état d'accélération), le groupe Drive (courant moteur de chaque mécanisme, vitesse de rotation, température, état de fonctionnement, codes d'alarme), le groupe Brake (état ouvert/fermé des deux freins, courant électromagnétique, compteur d'usure, indicateur de désynchronisation), le groupe Safety (états STO/SLS/SBC/SDI, compteur de déclenchements d'arrêt d'urgence, journal des événements de sécurité) et le groupe Diagnosis (durée de fonctionnement du système, file de codes de défaut, horodatage de l'automate).

La dénomination des nœuds de données adopte le format CamelCase, chaque nœud comprenant 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 = frein ouvert / False = frein fermé), Brake.UnsyncCount (UInt16), Safety.STO_Active (Boolean), Safety.EventCount (UInt32). Lors du déploiement sur site, les 26 nœuds OPC UA standard de chaque pont roulant font l'objet d'un mappage d'adresses et d'une validation des types de données. Une fois le mappage terminé, l'outil UA Expert est utilisé pour vérifier la lisibilité et la conformité des types de données de l'ensemble des nœuds.

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

La conversion de protocole est la fonction centrale de la passerelle périphérique. L'API du pont roulant publie ses données vers la passerelle via PROFINET IO en cycle temps réel (10 ms). Le moteur de conversion de la passerelle analyse les trames PROFINET IO, les transforme en un format de données interne unifié, puis les réencapsule selon les exigences de chaque protocole cible. La passerelle exécute simultanément trois sorties protocolaires : un serveur OPC UA, un serveur Modbus TCP et un client MQTT, desservant respectivement le système MES, le système SCADA et la Plateforme Cloud.

Configuration de la sortie OPC UA. Le serveur OPC UA de la passerelle repose sur 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 politique de sécurité du serveur est configurée en signature et chiffrement Basic256Sha256 (SecurityMode=SignAndEncrypt). L'authentification des clients repose sur une liste blanche de certificats X.509 : seuls les clients OPC UA dont le certificat figure 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 du pont roulant mentionnés précédemment. Un client UA (par exemple le client OPC UA du système MES) découvre l'intégralité de l'arborescence des nœuds par une opération Browse, puis s'abonne pour lire les données temps réel par lots. L'intervalle d'échantillonnage minimal pris en charge pour les abonnements est de 50 ms.

Configuration de la sortie Modbus TCP. La passerelle mappe les données standard du pont roulant dans une table de registres Modbus, avec des adresses attribuées de manière contiguë à partir de 40001 : 40001 à 40006 correspondent aux 6 registres du groupe fonctionnel Motion, 40007 à 40014 aux 8 registres du groupe Drive, 40015 à 40019 aux 5 registres du groupe Brake et 40020 à 40023 aux 4 registres du groupe Safety. Chaque registre occupe 2 octets ; les données 32 bits (Real, Int32) occupent deux registres consécutifs. Le système SCADA, agissant en tant que maître Modbus TCP (port par défaut 502), interroge périodiquement chaque adresse de registre. Une seule instruction de lecture peut récupérer par lots les données d'une plage d'adresses contiguës, réduisant ainsi la charge réseau.

Configuration de la sortie MQTT. L'unité de traitement des données périphériques de la passerelle se connecte, en tant que client MQTT, au courtier MQTT de la Plateforme Cloud (par exemple EMQX ou VerneMQ, port par défaut 8883), avec une communication chiffrée par TLS. Les sujets MQTT sont conçus selon la hiérarchie des équipements du pont roulant, avec 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 QoS=1 pour garantir une livraison au moins une fois. La charge utile est encapsulée au format JSON et contient trois champs : horodatage, valeur de données et indicateur de qualité. La fréquence de publication MQTT typique est de 1 s, avec un volume d'environ 200 octets par publication et par pont roulant. Pour 8 ponts roulants fonctionnant simultanément, le trafic réseau est d'environ 1,6 Ko/s.

4. Traitement des données périphériques et reprise après coupure réseau

La fiabilité de la collecte des données de fonctionnement du pont roulant repose sur le cache de données local de la passerelle périphérique et sur son mécanisme de reprise après coupure réseau. L'environnement réseau industriel — en particulier les interruptions de liaison lors des handovers WiFi provoqués par les déplacements du pont roulant le long du Rail, ou les interférences harmoniques des Variateurs de fréquence de l'Atelier — peut entraîner des coupures brèves de la connexion entre la passerelle et la Plateforme Cloud. La plateforme de données périphériques de Kelude a donc conçu un mécanisme de cache en anneau et de reprise après interruption.

La couche de cache de données utilise une architecture à deux niveaux : mémoire vive + carte SD. Le premier niveau est un cache en anneau en mémoire (Ring Buffer) d'une capacité de 10 000 enregistrements de données (soit environ 2 Mo de mémoire, sur la base de 200 octets par enregistrement). La latence d'écriture en mémoire est inférieure à 1 ms. Le fonctionnement suit un modèle producteur-consommateur : les threads de sortie OPC UA / Modbus / MQTT, en tant que consommateurs, lisent les données du cache et les transmettent, puis les marquent comme traitées après un transfert réussi. Le second niveau est un cache fichier sur carte SD. Lorsqu'une coupure réseau provoque un backlog de données dépassant le seuil mémoire (80 % par défaut), l'unité de traitement des données périphériques écrit automatiquement les données accumulées dans des fichiers de cache sur la carte SD. La capacité de ce cache dépend de la taille de la carte SD (32 Go recommandés pour une carte de qualité industrielle). Sur la base d'un besoin d'environ 1,2 Go pour 7 jours de cache maximum, une carte SD de 32 Go peut stocker plus de 180 jours de données de fonctionnement du pont roulant.

La stratégie de reprise après coupure réseau couvre trois scénarios. Interruption brève (≤ 30 s) : le cache mémoire suffit à absorber les données accumulées ; à la restauration du réseau, la connexion TCP des threads de sortie se rétablit automatiquement et les données en cache sont envoyées en une seule fois, rapidement et dans l'ordre chronologique. Interruption moyenne (30 s à 2 h) : après saturation de la mémoire, les données sont automatiquement transférées vers le cache fichier sur carte SD ; à la restauration du réseau, le module de synchronisation des fichiers analyse la carte SD pour identifier les fichiers non envoyés et les téléverse à raison de 500 enregistrements par seconde (soit un besoin de bande passante montante d'environ 212 Ko/s, compatible avec un réseau d'Atelier à 10 Mbit/s). Interruption prolongée (≥ 2 h) : lorsque le cache SD est plein (le nombre de fichiers atteint le seuil d'alerte), la plateforme périphérique exécute automatiquement une politique d'éviction du cache — les enregistrements les plus anciens sont supprimés selon l'ordre FIFO (horodatage), et une alerte locale est déclenchée sur le Panneau de commande du pont roulant pour informer le personnel de maintenance. Après la restauration du réseau, la passerelle transmet au système MES la plage horaire des enregistrements manquants ; c'est le MES qui décide s'il faut procéder à un rattrapage des données à partir de l'historique de l'API.

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

La sécurité des données de la plateforme périphérique du pont roulant est conforme à la norme ISA/IEC 62443 relative à la cybersécurité des systèmes industriels. Les mesures de sécurité sont organisées en trois niveaux : sécurité des transmissions, contrôle d'accès et journaux d'audit.

La couche de sécurité des transmissions applique le chiffrement TLS 1.3 à toutes les liaisons de communication externes. Le serveur OPC UA est configuré pour une communication signée et chiffrée Basic256Sha256, et les connexions non chiffrées sont interdites (SecurityPolicy=None est bloqué). Le client MQTT utilise TLS pour se connecter au courtier MQTT, avec validation du certificat serveur par chaîne de Certification : la passerelle est préchargée avec le certificat CA de l'usine, et les connexions avec des certificats auto-signés sont interdites. Le protocole Modbus TCP ne prenant pas en charge le chiffrement nativement, un tunnel VPN (WireGuard) est établi entre la passerelle périphérique et le serveur SCADA pour créer un canal chiffré dans lequel transitent les trames Modbus. Le tunnel VPN utilise une authentification par clé pré-partagée (PSK), avec rotation de la clé tous les 90 jours.

Les certificats OPC UA des trois rôles sont téléchargés et liés via l'interface de gestion Web de la passerelle. Lors de la connexion d'un client UA, la passerelle vérifie le champ Common Name du certificat client pour déterminer le rôle et applique les permissions correspondantes. Le contrôle d'accès MQTT est implémenté via des règles ACL. Chaque client MQTT est authentifié par nom d'utilisateur et mot de passe, et les règles ACL définissent les sujets MQTT que le client peut publier ou auxquels il peut s'abonner.

La couche de journalisation d'audit enregistre tous les événements d'accès aux données. Chaque connexion/déconnexion d'un client OPC UA, chaque abonnement/désabonnement d'un client MQTT, et chaque dépassement du seuil de 20 requêtes de lecture Modbus TCP par seconde (déclenchant une limitation de débit) sont consignés dans le fichier 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 rotatif, avec une période de conservation de 90 jours. Les fichiers journaux sont stockés chiffrés et ne peuvent être téléchargés et consultés que par le rôle Admin via l'interface de gestion Web de la passerelle.

Déploiement, Tests et Maintenance

Le déploiement et la mise en service de la passerelle Edge pour pont roulant suivent un processus standardisé. Première étape : l'installation matérielle. L'IOT2050 est monté sur le rail DIN de l'armoire de commande (occupant 4 modules de largeur standard). La passerelle est connectée au commutateur réseau PROFINET de l'atelier via un câble réseau blindé CAT6A, et à un commutateur du réseau de bureau de l'atelier (pour le téléchargement MQTT et la gestion à distance) via un second câble réseau. L'alimentation électrique de la passerelle est assurée par une source 24V DC provenant de l'alimentation à découpage de l'armoire de commande. Un filtre EMC (courant nominal 0,5 A) est installé à l'entrée d'alimentation.

Deuxième étape : le déploiement de l'environnement logiciel Edge. Les images Edge App sont poussées à distance vers l'IOT2050 via la plateforme Siemens Industrial Edge Management (IEM). 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 Edge, application module de sécurité des données. Après le déploiement de chaque application, un script d'auto-test vérifie l'état du conteneur et l'état d'écoute des ports. Pour la solution nationale, les fichiers de configuration Docker Compose et les images sont poussés via SSH, et le déploiement est effectué en une commande avec docker-compose up -d.

Troisième étape : la vérification de la communication OPC UA. UA Expert est utilisé pour se connecter au serveur OPC UA de la passerelle (port par défaut 4840). Le certificat client signé par l'AC est importé, et la fonction Browse est utilisée pour parcourir les 26 nœuds standard. Une opération Read est effectuée sur chaque nœud pour confirmer l'exactitude du type de données et de la plage de valeurs. La fonction Subscription d'UaExpert est utilisée pour s'abonner au nœud Motion.Position (intervalle d'échantillonnage 50 ms), observer la stabilité du rafraîchissement des données en temps réel et vérifier que le taux de perte de paquets d'abonnement est ≤ 0,1 %.

Quatrième étape : la vérification de la remontée de données. Dans un 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. Utilisez Modbus Slave pour simuler un système SCADA lisant les adresses de registre 40001 à 40023, et vérifiez que les valeurs de données correspondent à celles affichées côté PLC. Test de déconnexion : débranchez le câble réseau de la passerelle pendant 30 secondes, vérifiez que le fichier de cache sur carte SD est créé automatiquement, puis, après la restauration du réseau, le module de reprise sur interruption télécharge automatiquement les données en cache. Confirmez côté MES qu'il n'y a aucune perte de données et que les horodatages sont continus.

Cinquième étape : la configuration de la maintenance. Dans l'interface de gestion Web de la passerelle (HTTPS://192.168.x.x:8443), configurez les règles d'alarme : dépassement du délai de connexion du client OPC UA (30 secondes par défaut) déclenche une alarme e-mail ; perte du heartbeat du courtier MQTT (aucun PINGRESP pendant 60 secondes par défaut) déclenche une alarme ; taux d'utilisation du cache de la carte SD supérieur à 80 % déclenche une alarme ; utilisation CPU de la passerelle constamment supérieure à 80 % pendant 5 minutes déclenche une alarme. Toutes les alarmes sont envoyées via SMTP à l'ingénieur de maintenance. De plus, le voyant LED sur le panneau de commande local (vert pour normal / rouge pour alarme / jaune pour maintenance) fournit une indication d'état sur site.

Questions Fréquentes (FAQ)