🔗 Une passerelle Python qui traduit en temps réel entre Modbus TCP ; le protocole encore massivement utilisé dans l’industrie depuis plus de 40 ans et OPC-UA, le standard moderne de supervision. Pas de simulation : de vrais capteurs et actionneurs, pilotés en direct sur un Raspberry Pi 4.
💡 Pourquoi ce projet ?
Je suis diplômé en informatique industrielle, et ce qui m’intéresse particulièrement, c’est l’interopérabilité entre les protocoles industriels historiques et les standards modernes de supervision. Le Modbus TCP reste partout dans l’industrie; simple, fiable, mais limité (pas de sécurité, pas de structure de données riche). L’OPC-UA, lui, est le standard actuel de l’IIoT.
Beaucoup d’usines tournent encore avec du matériel qui ne parle que Modbus et qu’on ne peut pas simplement remplacer. Plutôt que de choisir entre les deux mondes, j’ai voulu construire le pont qui les relie en Python, avec de vrais capteurs et actionneurs câblés sur un Raspberry Pi 4, pas une simulation.
💡 Ce projet m’a permis de manipuler les deux côtés d’une vraie passerelle industrielle : serveur Modbus, client Modbus, serveur OPC-UA; les mêmes rôles qu’on retrouve dans une installation de supervision réelle.
🔧 Matériel utilisé
Raspberry Pi 4
Héberge l’esclave Modbus TCP et la passerelle OPC-UA
Pilotage GPIO/I2C réel
Capteurs
DHT11 (température/humidité)
HC-SR04 (distance)
PIR (détection de présence)
Actionneurs
Module 4 relais
Servomoteur 9g
Moteur pas-à-pas 28BYJ-48 + ULN2003
Python
pymodbus (serveur/client Modbus)
python-opcua (serveur OPC-UA)
gpiozero + pigpio
🗂️ Carte des registres Modbus
Chaque capteur et chaque actionneur correspond à une zone précise de la table Modbus en lecture seule pour les capteurs, en lecture/écriture pour les actionneurs :
| Composant | Zone Modbus | Type | Accès |
|---|---|---|---|
| PIR | Discrete Input | 1 bit | Lecture seule |
| Température / Humidité / Distance | Input Register | 16 bits | Lecture seule |
| Relais (×4) | Coil | 1 bit | Lecture / Écriture |
| Servo / Pas-à-pas | Holding Register | 16 bits | Lecture / Écriture |
📝 La logique du scénario, en clair
Au-dessus de la passerelle Modbus/OPC-UA, un scénario autonome réagit directement aux capteurs sans rien changer à la lecture de base. Voici l’idée, en pseudo-code, avant de voir le détail :
tant que le programme tourne :
si présence détectée (PIR) et pas déjà signalée :
activer relais "LED présence"
afficher "PRESENCE !" sur l'écran
sinon si plus de présence :
désactiver le relais
effacer le message
si objet proche détecté (HC-SR04 < 4cm) :
servo -> 180°
sinon si objet vient de disparaître :
servo -> 0° (repos)
attendre 5 secondes
faire tourner le pas-à-pas 10s
pause 3s
faire tourner le pas-à-pas en sens inverse 10s
💡 Ce scénario écrit directement dans les mêmes registres Modbus qu’un client externe utiliserait; c’est ce qui lui permet de rester visible et synchronisé avec la passerelle OPC-UA, sans rien casser du fonctionnement de base.
📊 L’architecture, étape par étape
Deux programmes Python tournent ensemble sur le Raspberry Pi. Voici comment une donnée circule, dans les deux sens :
L’esclave Modbus lit le matériel
modbus_hardware_slave.py lit en continu les capteurs physiques via GPIO/I2C, et écrit les valeurs dans ses registres Modbus (serveur TCP sur le port 5020).
La passerelle interroge l’esclave
gateway.py, en tant que client Modbus, relit ces registres toutes les secondes et republie les mêmes valeurs comme variables OPC-UA.
Une commande redescend vers le matériel
À l’inverse, une commande écrite côté OPC-UA (par exemple l’angle du servo) redescend vers le Modbus, qui pilote réellement le GPIO ; le matériel réagit pour de vrai.
Le scénario automatique vient se greffer dessus
Un troisième thread réagit directement aux capteurs (PIR, HC-SR04) et écrit lui aussi dans les registres exactement comme le ferait un client externe, sans rien remplacer de la lecture de base.
🎯 Ce que ça donne en pratique
Quand le PIR détecte une présence, un relais s’active et un message apparaît sur l’écran LCD visible en temps réel côté OPC-UA. Quand un objet s’approche du capteur à ultrasons, le servomoteur réagit, puis quelques secondes plus tard, le moteur pas-à-pas se met en mouvement avant de revenir à l’état initial.
🎯 Rien n’est simulé : chaque réaction part des mêmes registres Modbus lus et écrits en continu, exactement comme le ferait une vraie installation de supervision industrielle.
💻 Stack technique
🐍 Python
🔌 Modbus TCP
🌐 OPC-UA
📦 pymodbus
📦 python-opcua
⚡ gpiozero / pigpio
🔧 GPIO / I2C
📚 Ce que j’ai appris
Implémentation d’un serveur ET d’un client Modbus TCP en Python (pymodbus)
Mise en place d’un serveur OPC-UA (python-opcua) exposant des variables en temps réel
Synchronisation bidirectionnelle sans boucle d’écrasement (logique « push sur changement »)
Câblage et debug de capteurs/actionneurs réels (DHT11, HC-SR04, PIR, relais, servo, pas-à-pas)
PWM matériel via pigpio pour un servomoteur parfaitement stable
Architecture multi-thread Python (lecture capteurs, pilotage actionneurs, scénario autonome)
🚀 Prochaine étape
Sécuriser le serveur OPC-UA (certificats, authentification)
Brancher un vrai logiciel de supervision SCADA sur le serveur OPC-UA
Historiser les données (InfluxDB + Grafana) pour du monitoring dans le temps
Étendre la passerelle à plusieurs esclaves Modbus simultanés
📦 Code source disponible !
Le code complet de la passerelle Modbus/OPC-UA est disponible gratuitement sur GitHub !
Projet réalisé par Angelbert Fankep · Diplômé en Informatique Industrielle
Raspberry Pi 4 · Python · Modbus TCP · OPC-UA