Une passerelle Revolution Pi MQTT vous offre la pile logicielle Raspberry Pi que vous connaissez, dans un boîtier rail DIN conçu pour les armoires électriques, avec alimentation 24 V, modules d'E/S industriels et un cycle de vie produit plus long. Cet article explique où se placent les contrôleurs industriels à base de Pi, comment lire des signaux terrain sur un Revolution Pi en Python et les publier en MQTT, et ce qui change lorsqu'un prototype devient une passerelle de production. Les mêmes principes s'appliquent aux autres appareils industriels basés sur les Compute Module 4 et Compute Module 5.
Pourquoi un Raspberry Pi industriel
Un Raspberry Pi standard est excellent pour prototyper, mais une armoire électrique est un tout autre environnement : alimentation 24 V DC, bruit électrique, larges plages de température, vibrations et équipes de maintenance qui attendent un montage sur rail DIN et des borniers à vis. Les contrôleurs industriels basés sur le Raspberry Pi Compute Module résolvent ces problèmes tout en conservant Raspberry Pi OS (ou un dérivé proche), Python, Node-RED et le reste de l'écosystème que vous connaissez déjà.
La famille Revolution Pi de KUNBUS en est l'exemple le plus connu. Un module de base comme le RevPi Connect contient le Compute Module, des ports Ethernet et le conditionnement de l'alimentation. Des modules d'extension pour E/S numériques, E/S analogiques et passerelles de bus de terrain se clipsent sur le côté et communiquent avec la base via un connecteur de fond de panier. D'autres fabricants proposent des contrôleurs à base de CM4 et CM5 avec leurs propres E/S, et l'approche d'intégration de cet article se transpose avec une autre bibliothèque d'E/S.
| Besoin | Pi standard | Contrôleur industriel à base de Pi |
|---|---|---|
| Alimentation | 5 V USB-C | 24 V DC, souvent avec large plage d'entrée |
| Montage | Boîtier ou adaptateur DIN | Rail DIN natif |
| E/S | GPIO 3,3 V | Entrées/sorties numériques 24 V, analogiques 0-10 V et 4-20 mA |
| Stockage | Carte SD | eMMC sur le Compute Module |
| Environnement | Bureau | Tenue en température et CEM pour armoire électrique |
| Cycle de vie | Rythme grand public | Disponibilité à long terme comme objectif de conception |
Architecture type
Dans la plupart des déploiements, le Pi industriel ne remplace pas l'automate (PLC) qui pilote la machine. Il se place à côté, en tant que passerelle edge :
- Les signaux terrain arrivent au contrôleur directement via les modules d'E/S (un contact de porte, une impulsion de débitmètre, un transmetteur de pression 4-20 mA) ou indirectement via Modbus TCP, Modbus RTU ou un autre protocole depuis l'automate existant.
- L'application passerelle échantillonne les valeurs, applique mise à l'échelle et bandes mortes, détecte les changements d'état et horodate le tout.
- MQTT transporte les données en sortie vers un broker dans le cloud ou sur le réseau de l'usine, où tableaux de bord, historiens et outils d'alerte s'abonnent.
- Des commandes optionnelles reviennent par MQTT vers les sorties, mais uniquement pour des fonctions non liées à la sécurité et avec une validation explicite.
Cette répartition est essentielle. L'automate garde un contrôle déterministe et certifié sécurité, tandis que la passerelle gère la connectivité et la modélisation des données, deux domaines où un automate est souvent mal à l'aise. Si vos signaux proviennent d'un automate plutôt que d'E/S directes, le guide Raspberry Pi Modbus MQTT détaille la partie interrogation.
Lire les E/S du RevPi en Python
Le Revolution Pi expose toutes les valeurs des modules via une image process gérée par le pilote piControl. Vous configurez les modules et nommez chaque E/S dans l'outil web PiCtory, puis vous lisez et écrivez ces noms depuis n'importe quel langage. La commande piTest est le moyen le plus rapide de tout vérifier :
piTest -d # lister les modules détectés
piTest -r I_1 # lire l'entrée I_1
piTest -w O_1,1 # activer la sortie O_1
En Python, la bibliothèque revpimodio2 associe l'image process à des objets nommés d'après votre configuration PiCtory. Elle prend en charge à la fois l'interrogation cyclique et les callbacks d'événements, ce qui convient bien à MQTT : les entrées changent rarement, donc publier sur changement limite le trafic.
import json
import os
import time
import paho.mqtt.client as mqtt
import revpimodio2
BROKER = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "1883"))
USERNAME = os.getenv("MQTT_USERNAME")
PASSWORD = os.getenv("MQTT_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "revpi-gw-r2d7k1")
PREFIX = os.getenv("TOPIC_PREFIX", "connectmq/demo/r2d7k1/plant1/packaging/line2/revpi1")
DIGITAL_INPUTS = ["I_1", "I_2", "I_3"] # noms issus de PiCtory
ANALOG_INPUTS = {"InputValue_1": 0.001} # nom -> facteur d'échelle (ex. mV vers V)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
if USERNAME:
client.username_pw_set(USERNAME, PASSWORD)
if PORT == 8883:
client.tls_set()
client.will_set(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.reconnect_delay_set(1, 60)
def on_connect(client, userdata, flags, reason_code, properties):
client.publish(f"{PREFIX}/status", "online", qos=1, retain=True)
client.subscribe(f"{PREFIX}/cmd/O_1", qos=1)
def on_message(client, userdata, msg):
value = msg.payload.decode().strip().lower()
if value in ("1", "true", "on"):
rpi.io.O_1.value = True
elif value in ("0", "false", "off"):
rpi.io.O_1.value = False
client.on_connect = on_connect
client.on_message = on_message
client.connect_async(BROKER, PORT, keepalive=30)
client.loop_start()
rpi = revpimodio2.RevPiModIO(autorefresh=True)
rpi.handlesignalend(rpi.cleanup)
def publish_digital(ioname, iovalue):
payload = {"value": bool(iovalue), "ts": round(time.time(), 3)}
client.publish(f"{PREFIX}/di/{ioname}", json.dumps(payload), qos=1, retain=True)
for name in DIGITAL_INPUTS:
rpi.io[name].reg_event(publish_digital)
publish_digital(name, rpi.io[name].value) # état initial
rpi.mainloop(blocking=False)
while not rpi.exitsignal.wait(5):
analog = {n: round(rpi.io[n].value * f, 3) for n, f in ANALOG_INPUTS.items()}
client.publish(f"{PREFIX}/ai", json.dumps({**analog, "ts": int(time.time())}), qos=1)
client.publish(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.loop_stop()
client.disconnect()
Les entrées numériques sont publiées immédiatement à chaque changement et en mode retained, de sorte qu'un abonné connaît toujours l'état courant. Les valeurs analogiques sont échantillonnées toutes les cinq secondes. Le gestionnaire de commandes n'accepte que des valeurs explicites pour une seule sortie nommée et ignore tout le reste. Notez que l'abonnement aux commandes utilise par convention un topic non retained : si une commande « on » retained restait stockée sur le broker, la sortie basculerait à chaque redémarrage de la passerelle.
Conception des topics pour les données d'usine
Les passerelles industrielles gagnent à utiliser une hiérarchie de topics qui reflète l'usine : entreprise, site, zone, ligne, cellule ou machine. Cette structure de type ISA-95 est la colonne vertébrale d'un Unified Namespace et rend les abonnements naturels (plant1/packaging/# pour tout ce qui concerne une zone). ConnectMQ reconnaît les topics de type ISA-95 et affiche les appareils connectés selon ces niveaux dans son portail, ce qui facilite la navigation dans une grande flotte de passerelles. Le guide MQTT Sparkplug B et Unified Namespace explique quand ajouter Sparkplug B au-dessus du simple JSON.
Quelques règles gardent l'espace de noms utile au fil des années :
- Placez le chemin de l'équipement dans le topic et les mesures dans le payload, et non l'inverse.
- Utilisez des noms de signaux stables issus de PiCtory ou d'une table de correspondance, jamais des adresses de registres brutes.
- Publiez l'état et les métadonnées (version du firmware, empreinte de la configuration d'E/S) sur des topics retained.
- Séparez les topics de commande (
.../cmd/...) et documentez précisément qui a le droit d'y publier.
Du pilote à la production
Le code ci-dessus suffit pour un pilote sur le serveur MQTT public gratuit, mais les données d'usine n'ont rien à faire sur un broker public, réservé aux tests et prototypes. Les passerelles de production exigent un broker privé, TLS et quelques habitudes opérationnelles :
- Identifiants privés sur TLS. Créez un broker sur ConnectMQ, utilisez le nom d'utilisateur, le mot de passe et le client ID générés dans le portail, et connectez-vous sur le port 8883. Les client IDs sont liés aux identifiants émis : une passerelle ne peut donc pas en usurper une autre.
- Réseau sortant uniquement. La passerelle ouvre la connexion vers le broker ; aucune règle de pare-feu entrante n'est nécessaire sur le réseau OT.
- Stockage et retransmission. Conservez une file locale pour que les coupures réseau ne créent pas de trous dans les données. Le modèle de mise en tampon MQTT hors ligne en Python fonctionne tel quel sur un RevPi.
- Gestion du service. Exécutez le script comme unité systemd avec redémarrage automatique, et utilisez le watchdog matériel.
- Durcissement. Clés SSH, pare-feu, mises à jour régulières et utilisateur de service dédié, comme décrit dans la checklist de sécurisation du Raspberry Pi IoT.
- Gestion des changements. Versionnez ensemble votre configuration PiCtory et le code de la passerelle, afin que les noms d'E/S du code correspondent toujours au matériel.
Un broker MQTT managé prend en charge le côté serveur : certificats, disponibilité et quotas. Pour les usines plus importantes, les offres Dedicated et BYOC maintiennent le trafic sur un cluster isolé ou dans votre propre compte cloud.
Là où les passerelles Pi industrielles excellent
Les contrôleurs industriels à base de Pi sont un excellent choix pour équiper d'anciennes machines de capteurs que l'automate n'a jamais eus, surveiller les utilités comme l'air comprimé, l'eau et les compteurs d'énergie, collecter les états machine pour le calcul du TRS (OEE), et convertir des protocoles là où une passerelle constructeur serait coûteuse ou fermée. Ils ne remplacent pas les automates de sécurité et ne doivent pas fermer des boucles de régulation rapides dépendant d'un timing déterministe. Laissez celles-ci au contrôleur conçu pour cela et laissez la passerelle rendre compte de ce qui se passe.
Pour une vue plus large des passerelles edge sur la plateforme Pi, consultez le tutoriel Raspberry Pi MQTT et la documentation officielle du Compute Module.
Connectez vos passerelles industrielles à ConnectMQ
Lancez un pilote sur l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, et voyez vos signaux RevPi apparaître dans l'explorateur de topics en direct en quelques minutes. Lorsque le pilote a fait ses preuves, migrez les mêmes passerelles vers un broker Dedicated ou BYOC sans modifier le code.
Questions fréquentes
Puis-je utiliser Node-RED au lieu de Python sur un Revolution Pi ?
Oui. Node-RED tourne sur le RevPi et dispose de nœuds pour l'image process, et ses nœuds MQTT intégrés publient vers n'importe quel broker. Python vous donne davantage de contrôle sur la mise en tampon et les tests.
Le Revolution Pi remplace-t-il un automate ?
Il peut exécuter une logique de commande simple, mais la plupart des usines conservent leurs automates existants pour la commande et la sécurité, et utilisent le RevPi comme passerelle de données à leurs côtés.
À quelle fréquence une passerelle RevPi peut-elle publier des données ?
Le cycle d'E/S est assez rapide pour la surveillance, mais la vraie question est de savoir à quelle fréquence les consommateurs ont besoin des données. Publiez sur changement pour les signaux numériques et à intervalle fixe pour les valeurs analogiques.
MQTT est-il assez sûr pour les données d'usine ?
MQTT sur TLS avec des identifiants uniques par passerelle, des connexions uniquement sortantes et un broker privé constitue une conception solide. Ne publiez jamais de données d'usine sur un broker public.
