PROFINET vers MQTT : les options de passerelle pour envoyer les données terrain vers le cloud

PROFINET vers MQTT : c'est une question que se posent de nombreuses équipes d'automatisme dès qu'elles veulent afficher les données machines dans des tableaux de bord, un jumeau numérique ou le cloud, et la réponse est moins évidente que pour Modbus ou OPC UA. Ce guide explique pourquoi les données PROFINET ne peuvent pas simplement être interrogées, compare les quatre options de passerelle réalistes et déroule un exemple fonctionnel qui lit des valeurs process dans un automate Siemens S7 et les publie vers un broker MQTT. À la fin, vous saurez quelle option convient à votre usine et à quoi faire attention.

Pourquoi PROFINET est différent

PROFINET IO est une norme Ethernet industrielle d'échange cyclique en temps réel entre un IO controller (généralement un automate) et des IO devices (E/S déportées, variateurs, îlots de distribution, capteurs). Le contrôleur établit une relation applicative avec chaque équipement selon la configuration matérielle définie dans l'outil d'ingénierie, puis échange les données process à cycle fixe, souvent toutes les quelques millisecondes. Les alarmes et les données acycliques d'enregistrement circulent en parallèle.

Trois caractéristiques comptent pour l'intégration MQTT :

• Le contrôleur est propriétaire des équipements. Un IO device échange des données cycliques avec le contrôleur pour lequel il a été configuré. Un client quelconque du réseau ne peut pas simplement demander sa vitesse à un variateur comme un maître Modbus lit un registre sur un compteur.
• Les données process sont des octets bruts. Les données cycliques forment un bloc d'octets d'entrée et de sortie dont la signification est définie dans le projet automate et dans les fichiers de description d'équipement (GSDML), pas sur le réseau.
• Le réseau temps réel est précieux. Ajouter du trafic ou des équipements sur un réseau PROFINET doit se planifier avec l'automaticien, jamais s'improviser.

Conséquence pratique : dans presque tous les cas, la meilleure source de données PROFINET est l'automate qui pilote déjà les équipements, car il dispose des données, du contexte et des noms.

Les quatre options PROFINET vers MQTT

L'option 4 figure ici parce qu'elle revient souvent dans les discussions, mais c'est une technique de diagnostic, pas une base saine pour construire un pipeline de données. La suite de ce guide porte sur les trois premières.

Option 1 : lire l'automate depuis une passerelle edge

C'est l'approche la moins intrusive, et celle par laquelle commencent la plupart des équipes. La passerelle est placée sur le réseau de l'usine, lit les valeurs dans l'automate et les publie en MQTT. Deux voies d'accès sont courantes sur les automates Siemens :

• Serveur OPC UA. Les automates S7-1500 (et S7-1200 avec un firmware récent) peuvent exécuter un serveur OPC UA. Vous l'activez dans la configuration matérielle et choisissez les tags à exposer. La passerelle utilise alors un client OPC UA, comme dans notre tutoriel passerelle OPC UA vers MQTT. C'est la voie à privilégier quand elle est disponible : sécurisée, symbolique et supportée.
• Communication S7 (PUT/GET). Des bibliothèques open source comme python-snap7 lisent les blocs de données par adresse. Sur S7-1200 et S7-1500, il faut activer l'accès PUT/GET dans les paramètres de protection de la CPU et configurer le bloc de données en accès non optimisé pour que les offsets d'octets soient fixes. Activer PUT/GET réduit le niveau de protection de la CPU : validez-le avec le responsable de la sécurité de l'automate.

Les autres constructeurs de contrôleurs PROFINET proposent des choix similaires, généralement un serveur OPC UA ou un protocole de lecture propriétaire.

Exemple : d'un bloc de données S7 vers MQTT avec python-snap7

Supposons que l'automaticien ait créé un bloc de données non optimisé DB10 qui rassemble les valeurs à partager, un modèle courant et recommandé appelé bloc d'interface :

pip install python-snap7 "paho-mqtt>=2.0"

# s7_profinet_mqtt.py - lire un DB d'interface S7 et publier vers MQTT
import json, logging, time, uuid
import paho.mqtt.client as mqtt
import snap7
from snap7.util import get_real, get_dint, get_bool

logging.basicConfig(level=logging.INFO)
log = logging.getLogger("s7")

PLC_IP, RACK, SLOT = "192.168.0.10", 0, 1   # S7-1200/1500 : rack 0, emplacement 1 en général
DB_NUMBER, DB_SIZE = 10, 14
TOPIC_ROOT = "connectmq/demo/p3x8/plant1/assembly/line3"   # votre propre identifiant aléatoire
MQTT_HOST, MQTT_PORT = "broker.connectmq.com", 1883        # production : 8883 avec TLS
MQTT_USER, MQTT_PASS = None, None                          # production : "YOUR_USERNAME", "YOUR_PASSWORD"
CLIENT_ID = f"s7-bridge-{uuid.uuid4().hex[:8]}"            # production : "YOUR_CLIENT_ID"


def decode(buf):
    return {
        "line_speed": round(get_real(buf, 0), 2),
        "motor_current": round(get_real(buf, 4), 2),
        "good_count": get_dint(buf, 8),
        "running": get_bool(buf, 12, 0),
        "fault": get_bool(buf, 12, 1),
    }


def main():
    mq = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
    if MQTT_USER:
        mq.username_pw_set(MQTT_USER, MQTT_PASS)
        mq.tls_set()
    mq.will_set(f"{TOPIC_ROOT}/bridge", "offline", qos=1, retain=True)
    mq.on_connect = lambda c, u, f, rc, p: c.publish(f"{TOPIC_ROOT}/bridge", "online", qos=1, retain=True)
    mq.connect(MQTT_HOST, MQTT_PORT, keepalive=30)
    mq.loop_start()

    plc = snap7.client.Client()
    last = {}
    while True:
        try:
            if not plc.get_connected():
                plc.connect(PLC_IP, RACK, SLOT)
                log.info("connected to PLC %s", PLC_IP)
            values = decode(plc.db_read(DB_NUMBER, 0, DB_SIZE))
            ts = time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())
            for name, value in values.items():
                if last.get(name) != value:            # publier uniquement sur changement
                    mq.publish(f"{TOPIC_ROOT}/{name}",
                               json.dumps({"value": value, "ts": ts}), qos=1, retain=True)
                    last[name] = value
        except Exception as exc:                       # snap7 lève RuntimeError en cas d'erreur de communication
            log.error("PLC read failed: %s", exc)
            plc.disconnect()
            time.sleep(5)
        time.sleep(1)


if __name__ == "__main__":
    main()

Pour les grandeurs analogiques qui fluctuent en permanence, ajoutez une bande morte afin que la passerelle ne publie pas chaque variation infime ; notre guide sur le report by exception montre comment faire. Pour observer le résultat, abonnez-vous sur le serveur MQTT public gratuit, en gardant à l'esprit que tout le monde peut le lire : utilisez uniquement des données de test.

mosquitto_sub -h broker.connectmq.com -p 1883 -i s7-viewer-p3x8 -t "connectmq/demo/p3x8/#" -v

Option 2 : laisser l'automate publier directement en MQTT

Plusieurs constructeurs d'automates fournissent des blocs fonctionnels clients MQTT. Sur Siemens S7-1500 et S7-1200, par exemple, une bibliothèque cliente MQTT est disponible pour TIA Portal ; elle s'appuie sur l'open user communication de la CPU, avec prise en charge de TLS. Le programme automate décide alors précisément quand publier, ce qui est idéal pour les données événementielles comme les fins de lot ou les alarmes.

Points à prévoir :

1. Certificats. Pour TLS, la CPU doit faire confiance à l'AC du broker. Le broker utilise un certificat Let's Encrypt : chargez le certificat racine correspondant dans le magasin de certificats de l'automate.
2. Charge CPU et de communication. Publier beaucoup de valeurs à haute fréquence depuis l'automate entre en concurrence avec les tâches de commande. Publiez des synthèses et des événements, pas chaque cycle.
3. Gestion des reconnexions. Le programme doit gérer proprement les déconnexions du broker sans bloquer la logique de commande.
4. Gestion des modifications. Chaque changement de topic ou de payload implique un chargement de l'automate. Gardez le côté automate simple et effectuez le mapping plus lourd en aval.

Notre article Siemens S7 MQTT approfondit la configuration côté automate.

Option 3 : une passerelle équipement PROFINET

Des passerelles matérielles de plusieurs constructeurs se comportent comme un IO device PROFINET d'un côté et comme un client MQTT de l'autre. Vous importez le fichier GSDML de la passerelle dans l'outil d'ingénierie, l'ajoutez à la configuration matérielle et mappez les données de l'automate dans sa zone cyclique d'entrées/sorties. La passerelle convertit ces octets en messages MQTT selon sa propre configuration.

Vous obtenez ainsi une interface propre et déterministe : l'automate copie simplement les valeurs dans la zone de sortie de la passerelle à chaque cycle, et rien n'interroge l'automate. En contrepartie, il faut une modification matérielle, un chargement de l'automate pour ajouter l'équipement, et un second endroit (l'interface web de la passerelle) où réside le mapping des données. Cette option convient aux sites dont les règles interdisent strictement d'activer PUT/GET ou OPC UA sur les contrôleurs.

Choisir la bonne option

Parcourez cette checklist avec l'automaticien :

1. L'automate dispose-t-il d'un serveur OPC UA que vous pouvez activer ? Option 1 avec OPC UA.
2. PUT/GET est-il acceptable au regard de votre politique de sécurité ? L'option 1 avec la communication S7 est rapide et peu coûteuse.
3. Avez-vous besoin de données événementielles définies dans la logique automate ? Option 2.
4. Les paramètres des contrôleurs sont-ils verrouillés, mais une modification matérielle est-elle acceptable ? Option 3.
5. S'agit-il d'un pilote sur une seule ligne ? Commencez par l'option 1 ; vous pourrez toujours passer à l'option 2 ou 3 lors du déploiement à grande échelle.

Quel que soit votre choix, donnez aux données une structure de topics de type ISA-95, afin que les valeurs issues de PROFINET côtoient les données Modbus, EtherNet/IP et OPC UA dans un même espace de noms ; consultez notre guide sur les topics MQTT ISA-95.

Côté broker

Les trois options aboutissent à un client MQTT qui publie vers un broker : le choix du broker est donc indépendant du protocole terrain. Un broker MQTT managé comme ConnectMQ prend en charge MQTT 3.1.1 et 5.0 sur TLS (port 8883), détecte les topics ISA-95 et Unified Namespace, et les affiche dans un explorateur de topics en direct ainsi que dans une vue des équipements organisée selon les niveaux ISA-95. Des règles d'alerte à seuil peuvent ensuite signaler un bit de défaut ou un courant moteur au-dessus de sa limite, sans code supplémentaire. Pour l'architecture de référence globale, lisez le guide MQTT pour l'IoT industriel.

Démarrer avec ConnectMQ

Choisissez votre voie PROFINET et laissez le broker être la partie facile. Inscrivez-vous sur app.connectmq.com, choisissez le plan gratuit Serverless (sans carte bancaire), créez un broker et utilisez le nom d'utilisateur, le mot de passe et le client ID générés dans votre passerelle ou dans le client MQTT de votre automate. Les données de votre ligne seront visibles dans le portail ConnectMQ en quelques minutes.

Questions fréquentes

Une passerelle MQTT peut-elle lire directement les équipements PROFINET ?

Pas à la manière d'un maître Modbus qui interroge un compteur. Les IO devices PROFINET échangent des données cycliques avec leur contrôleur configuré : les passerelles lisent donc soit le contrôleur, soit sont elles-mêmes configurées comme IO devices.

Activer PUT/GET sur un S7-1200 ou un S7-1500 est-il sûr ?

Cela abaisse la protection d'accès de la CPU : ce doit être une décision délibérée et documentée, avec une segmentation réseau en place. Lorsqu'il est disponible, le serveur OPC UA de l'automate est l'alternative la plus sûre.

Ai-je besoin de fichiers GSDML pour une passerelle PROFINET vers MQTT ?

Uniquement pour l'option 3, où la passerelle est ajoutée à la configuration matérielle de l'automate en tant qu'IO device. La lecture de l'automate via OPC UA ou la communication S7 n'en nécessite pas.

La lecture de l'automate affecte-t-elle les performances temps réel de PROFINET ?

Les lectures passent par l'interface de communication de la CPU, pas par l'échange d'E/S cyclique, et une interrogation modérée a peu d'impact. Gardez des fréquences d'interrogation raisonnables et lisez des blocs d'interface compacts.