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