IoT-dossier

Modbus RTU naar MQTT — conversie en industriële bridge

Modbus RTU omzetten naar MQTT JSON: QoS 0/1/2, TLS, AWS IoT Core, Azure IoT Hub, Mosquitto, Sparkplug B. Architectuur, configuratie en beveiliging.

In het kort
Een Modbus RTU-naar-MQTT-bridge controleert uw apparatuur RS485/RS232 via Modbus-polling, verpakt elke meting in een bericht JSON MQTT met tijdstempel, configureerbare QoS en versleuteling TLS 1.3, en publiceert vervolgens naar de MQTT-broker van uw keuze (AWS IoT Core, Azure, HiveMQ, Mosquitto of Eziwan). De conversie is volledig configureerbaar zonder code.

Waarom Modbus RTU naar MQTT converteren?​

Modbus RTU is de taal van de machine. MQTT is de taal van de cloud. De Modbus RTU → MQTT-bridge vormt de schakel tussen deze twee werelden: hiermee kunnen uw oudere industriële apparaten communiceren met moderne IoT-platforms zonder dat er iets aan de bestaande installatie hoeft te worden aangepast.

Voordelen van MQTT voor de overdracht van industriële gegevens:

  • Compactheid: minimaal 2 bytes header, ideaal voor 4G en dure verbindingen
  • Publish/subscribe: ontkoppeling tussen productie (gateway) en consumptie (dashboard, API)
  • Persistente sessie: berichten worden in de wachtrij geplaatst tijdens netwerkonderbrekingen
  • Configureerbare QoS: afleveringsgarantie aangepast aan elk type gegevens
  • Native TLS: versleuteling en authenticatie zonder applicatie-overlay

Architectuur van de Modbus RTU → MQTT-bridge​

De bridge werkt in twee afzonderlijke en onafhankelijke fasen:

Fase 1 — Modbus RTU-gegevensverzameling (veldzijde) De gateway fungeert als Modbus-master. Deze verstuurt leesverzoeken (FC01/02/03/04) naar de RS485-slaves volgens een configureerbaar polling-schema. Elk antwoord wordt lokaal gedecodeerd, geschaald en van een tijdstempel voorzien.

Fase 2 — MQTT-publicatie (cloudzijde) De gedecodeerde waarden worden ingekapseld in JSON-berichten en gepubliceerd op de MQTT-broker. Als de verbinding niet beschikbaar is, worden de berichten lokaal gebufferd (72 uur) en bij het herstellen van de verbinding opnieuw verzonden met hun oorspronkelijke tijdstempel.

RS485-bus, Eziwan-gateway, MQTT-broker
────────── ────────────────── ────────────
Esclave 1 ──┐ ┌── Modbus RTU master AWS IoT Core
Esclave 2 ──┤── RS485 ──►│ Polling FC03/FC04 MQTT Azure IoT Hub
Esclave 3 ──┤ │ Decode + Scale ──TLS► HiveMQ
Esclave n ──┘ └── JSON builder Mosquitto
Buffer 72h Eziwan Cloud

Structuur van MQTT-topics voor Modbus RTU​

De indeling van MQTT-topics is van cruciaal belang voor de onderhoudbaarheid en de integratie:

Aanbevolen conventie:

{site}/{zone}/{uitrusting}/{tag}

Voorbeelden:

usine/atelier_a/variateur_01/frequence_hz
usine/atelier_a/variateur_01/courant_a
usine/tgbt/compteur_principale/puissance_active_kw
usine/tgbt/compteur_principale/energie_kwh

Metadata-onderwerpen (Sparkplug B):

spBv1.0/fabriek/NBIRTH/gateway_01 ← Inlogmelding
spBv1.0/fabriek/NDATA/gateway_01 ← Procesgegevens
spBv1.0/fabriek/NDEATH/gateway_01 ← Afmelden (LWT)

MQTT-compatibele brokers​

De Eziwan-gateway is compatibel met de belangrijkste MQTT-brokers op de markt:

BrokerHostingProtocolToepassingsvoorbeelden
AWS IoT CoreAWS-cloudMQTT TLSAWS-integratie (Lambda, S3, Timestream)
Azure IoT HubAzure-cloudMQTT / AMQPAzure-integratie (Stream Analytics, Cosmos DB)
HiveMQ CloudBeheerde cloudMQTT 5.0 + TLSSparkplug B, UNS, multi-broker
MosquittoZelf gehostMQTT 3.1.1Lokale SCADA, minimale latentie
Eziwan CloudBeheerde cloudMQTT TLSKant-en-klaar, geïntegreerd dashboard

Beheer van het loskoppelen en buffering​

Industriële netwerken (4G, wifi in veeleisende omgevingen) zijn gevoelig voor storingen. De Modbus RTU → MQTT-bridge gaat hiermee om door:

  • Last Will Testament (LWT): automatisch bericht dat door de broker wordt verzonden wanneer de verbinding met de gateway wordt verbroken
  • Persistente sessie: de broker bewaart de abonnementen en de in de wachtrij staande QoS 1/2-berichten
  • Lokale buffer: de gateway slaat de metingen tijdens de onderbreking op in het flashgeheugen
  • Hersynchronisatie: bij het opnieuw verbinden worden de berichten in chronologische volgorde opnieuw verzonden

Dit mechanisme garandeert geen gegevensverlies, zelfs niet bij langdurige netwerkstoringen — wat van cruciaal belang is voor toepassingen op het gebied van energiemeting of productiemonitoring.

Integratie met cloud-TSDB’s​

MQTT-gegevens worden doorgaans opgeslagen in een tijdreeksdatabase (Time Series Database):

  • InfluxDB: open source, uitstekend geschikt voor industriële meetgegevens
  • AWS Timestream: serverloos, geïntegreerd met AWS IoT Core
  • Azure Data Explorer: hoge prestaties voor grote volumes
  • TimescaleDB: uitgebreide PostgreSQL, native SQL
  • Eziwan Storage: opslag inbegrepen, configureerbare bewaartermijn

Vanuit de TSDB worden de gegevens doorgegeven naar de Grafana-dashboards, de prestatierapporten en de modellen voor voorspellend onderhoud.

Veelgestelde vragen

Zie ook