MQTT, RS485, Modbus: welk protocol is geschikt voor uw veldsensoren?

· 13 minuten leestijd
13 min read
Eziwan-team
Eziwan-team
IoT-infrastructuur

Het aansluiten van industriële sensoren op de cloud komt vaak neer op het met elkaar in verbinding brengen van twee werelden: de OT met zijn robuuste seriële bussen, PLC’s en bestaande apparatuur; en de IT met zijn IP-netwerken, brokers, realtime databases en cloud-dashboards.

De juiste aanpak hoeft niet per se te bestaan uit het vervangen van de installatie in het veld. Bij veel IIoT-projecten is het het meest efficiënt om RS485/Modbus in het veld te behouden en MQTT in de cloud te gebruiken, met een gateway die de gegevens correct kan vertalen, filteren en publiceren.

RS485, Modbus, MQTT: drie begrippen die je niet door elkaar moet halen​

Voordat je een protocol kiest, moet je onderscheid maken tussen drie niveaus die vaak door elkaar worden gehaald:

TermFunctieGebruiksvoorbeeld
RS485Seriële fysieke laagMeerdere apparaten aansluiten op een tweedraadsbus
Modbus RTUToepassingsprotocol via seriële verbindingRegisters van een meter of sensor uitlezen
MQTTPublish/subscribe-protocol via IPMeetwaarden naar een cloudbroker verzenden

Belangrijk om te onthouden RS485 verzorgt de signaaloverdracht, Modbus RTU regelt de communicatie met de veldapparatuur en MQTT stuurt de gegevens door naar IT- of cloudsystemen.

RS485 / Modbus: de basis voor industriële apparatuur​

RS485: een robuuste seriële verbinding voor gebruik in het veld​

De RS485 is een differentiële seriële verbinding die al geruime tijd in de industrie wordt gebruikt. Deze verbinding wordt nog steeds veel toegepast omdat ze robuust en voordelig is en geschikt is voor omgevingen waarin apparatuur verspreid staat in een schakelkast, een werkplaats of een externe locatie.

Het wordt vaak gebruikt om het volgende aan te sluiten:

  • industriële besturingssystemen;
  • energiemeters;
  • omvormers;
  • frequentieomvormers;
  • sensoren voor temperatuur, druk, debiet of vochtigheid;
  • analyseapparatuur voor lucht, water of energie.

De theoretische maximale afstand van een RS485-bus kan onder gunstige omstandigheden oplopen tot ongeveer 1 200 meter, maar deze is sterk afhankelijk van de overdrachtssnelheid, de kwaliteit van de kabel, de topologie, de afsluiting en het niveau van elektromagnetische ruis.

Modbus RTU: registers lezen en schrijven​

Op RS485 is Modbus RTU het meest gangbare protocol. Het definieert een gestandaardiseerde manier om slave-apparaten vanaf een master te benaderen: slave-adres, lees- of schrijffunctie, registeradres, waarde, foutcontrole.

Voordelen en beperkingen van Modbus RTU​

PuntMeting ter plaatse
RobuustheidGeschikt voor industriële omgevingen en gecontroleerde lange afstanden
InteroperabiliteitZeer wijdverbreid bij sensoren, meters, regelaars en PLC's
EenvoudDuidelijke uitlezing van registers, eenvoudig te diagnosticeren met de juiste tools
Belangrijkste beperkingNiet native IP: er is een gateway nodig om het in de cloud te integreren
AandachtspuntEen verkeerde afsluiting, een stervormige bekabeling of inconsistente seriële instellingen kunnen de communicatie sterk verslechteren

MQTT: het protocol dat geschikt is voor publicatie in de cloud​

MQTT is een publish/subscribe-protocol dat is ontworpen om lichte berichten via TCP/IP te verzenden. Het wordt veel gebruikt in IoT- en IIoT-architecturen, omdat het de gegevensproducenten scheidt van de gegevensverbruikers.

Het principe is eenvoudig:

  • een MQTT-client publiceert berichten;
  • de berichten worden naar topics verzonden;
  • een MQTT-broker ontvangt, distribueert en beveiligt de communicatie;
  • de geabonneerde applicaties verwerken de gegevens: monitoring, tijdreeksdatabase, waarschuwingen, datalake, bedrijfsapplicaties.

Waarom MQTT een goede aanvulling is op Modbus​

Modbus is zeer geschikt voor het opvragen van gegevens van veldapparatuur. MQTT is beter geschikt voor het publiceren van gegevens naar externe applicaties.

BehoefteMeest geschikte protocol
De registers van een RS485-sensor uitlezenModbus RTU
Een PLC via Ethernet opvragenModbus TCP
Meetwaarden naar de cloud verzendenMQTT
Het verzamelen van gegevens in het veld loskoppelen van de IT-verwerkingMQTT
Bestaande industriële apparatuur behoudenRS485 / Modbus

MQTT is dus geen directe vervanging voor RS485. Het fungeert veeleer als transportlaag voor de applicatie naar de IT, nadat de veldgegevens zijn verzameld, gestandaardiseerd en in context geplaatst.

De rol van de Eziwan-gateway: een brug slaan tussen OT en de cloud​

Met de Eziwan-gateway kunnen apparaten in het veld worden aangesloten en kunnen hun gegevens naar externe diensten worden verzonden. In een typische architectuur vervult deze drie rollen:

  1. OT-gegevensverzameling: opvragen van gegevens van Modbus RTU-apparatuur via RS485 of Modbus TCP via het lokale netwerk.
  2. Standaardisatie: omzetting van registers naar bruikbare waarden met tag, eenheid, tijdstempel en kwaliteit.
  3. IT-publicatie: verzending van de gegevens naar een MQTT-broker, een cloudplatform of een bewakingssysteem.

Modbus-naar-MQTT-configuratie: de instellingen die je onder de knie moet krijgen​

1. De Modbus-polling instellen​

De eerste stap bestaat uit het beschrijven van de apparatuur die moet worden ondervraagd:

  • Modbus-adres van elke slave;
  • registertype: holdingregister, invoerregister, spoel, discrete invoer;
  • registeradres;
  • gegevensformaat: 16-bits geheel getal, 32-bits geheel getal, 32-bits drijvende komma, booleaanse waarde;
  • volgorde van woorden en bytes, indien nodig;
  • fysieke eenheid;
  • uitleesinterval;
  • naam van de tag die aan de MQTT-zijde wordt gepubliceerd.

Let op Twee apparaten kunnen dezelfde meting in verschillende formaten weergeven. Controleer daarom altijd de documentatie van de fabrikant: het exacte adres, de indexbasis, het type register, de schaalfactor en de endianness.

2. Voorbeeld van een JSON-configuratie​

{
  "modbus": {
    "baud_rate": 9600,
    "parity": "none",
    "stop_bits": 1,
    "slaves": [
      {
        "slave_id": 1,
        "registers": [
          {
            "address": "0x0001",
            "type": "holding",
            "format": "float32",
            "tag": "temperature",
            "unit": "°C"
          },
          {
            "address": "0x0003",
            "type": "holding",
            "format": "float32",
            "tag": "humidity",
            "unit": "%"
          }
        ]
      },
      {
        "slave_id": 2,
        "registers": [
          {
            "address": "0x0010",
            "type": "input",
            "format": "int16",
            "tag": "pressure",
            "unit": "mbar"
          }
        ]
      }
    ]
  },
  "mqtt": {
    "broker": "mqtt.example.com",
    "port": 8883,
    "tls": true,
    "base_topic": "site/{site_id}/gateway/{device_id}/sensors"
  }
}

3. Gestructureerde gegevens publiceren​

Zodra de waarde is uitgelezen, kan de gateway een gestructureerd MQTT-bericht verzenden:

Onderwerp: site/paris/gateway/eziwan-01/sensors/temperature
Payload: {"value":23.4,"unit":"°C","timestamp":"2025-02-20T14:32:01Z","quality":"good"}

Een onversleutelde payload vergemakkelijkt vervolgens de integratie met:

  • een database met tijdreeksen;
  • een Grafana-dashboard;
  • een Node-RED-workflow;
  • een cloud-SCADA-systeem;
  • een bedrijfsapplicatie;
  • een platform voor gecentraliseerd toezicht.

Modbus RTU versus Modbus TCP: wat is het verschil?​

Modbus komt in industriële projecten voornamelijk in twee vormen voor: Modbus RTU en Modbus TCP.

CriteriumModbus RTUModbus TCP
OndersteuningRS485 / RS232Ethernet of IP-netwerk
AdresseringswijzeSlave-adresIP-adres + poort
FrameCompact, met CRCIngekapseld in TCP
Typisch gebruikSensoren, meters, veldapparatuurPLC's, frequentieregelaars, Ethernet-apparatuur
DiagnoseSeriële analysator, Modbus RTU-testerPing, netwerkscan, Modbus TCP-client
AandachtspuntenBekabeling, afsluiting, snelheid, pariteitRouting, firewall, VLAN, netwerklatentie

In een Eziwan-architectuur kunnen beide benaderingen naast elkaar bestaan: de RS485-bus voor bestaande veldapparatuur en het lokale IP-netwerk voor Ethernet-apparatuur.

Voorbeeld van een architectuur: fabriek met gemengde apparatuur​

Op een industrieterrein kunnen verschillende generaties apparatuur naast elkaar staan:

  • een energiemeter via Modbus RTU;
  • een PLC via een seriële bus;
  • een frequentieregelaar die via Modbus TCP bereikbaar is;
  • een cloudgebaseerd bewakingssysteem dat de gegevens via MQTT ophaalt.

Dankzij deze architectuur hoeven apparaten die al in gebruik zijn niet te worden vervangen. De gateway fungeert als verzamel-, vertaal- en publicatiepunt.

Hoe kiest u het juiste protocol, afhankelijk van uw situatie?​

Situatie ter plaatseAanbevolen keuzeWaarom
Bestaande apparatuur met RS485-poortModbus RTUCompatibel met talrijke sensoren, meters en PLC's
Industriële apparatuur met Ethernet-poortModbus TCPEenvoudiger te integreren in een lokaal IP-netwerk
Nieuwe, verbonden sensorenNative MQTT indien beschikbaarDirecte publicatie naar een broker of cloudplatform
Bestaand SCADA-systeem dat onderhouden moet wordenBeveiligde toegang op afstand of VPNContinuïteit met de reeds bestaande architectuur
Gegevens naar Grafana, InfluxDB of Node-REDMQTTDuidelijke scheiding tussen gegevensverzameling en -verwerking
Afgelegen of mobiele locatieGateway met mobiele connectiviteitGegevensverzameling in het veld zonder afhankelijk te zijn van een lokaal bekabeld netwerk

Beveiliging: essentiële punten voor een veldgateway​

Het koppelen van de OT aan de cloud vereist een voorzichtige aanpak. Het doel is niet alleen om gegevens door te sturen, maar om dit te doen met een mate van controle die is afgestemd op de industriële context.

Aanbevolen goede praktijken​

  • IT- en OT-netwerken segmenteren om te voorkomen dat er vanuit de cloud te ruime toegang tot de veldapparatuur ontstaat.
  • Beperk uitgaande datastromen tot de noodzakelijke diensten: MQTT-broker, monitoring, updates of beheer.
  • Pas het principe van minimale rechten toe: apparatuur of gebruikers mogen alleen toegang hebben tot de benodigde bronnen.
  • Log verbindingen en gebeurtenissen om audits en diagnoses te vergemakkelijken.
  • Zorg voor de intrekking van toegangsrechten in geval van een verandering van dienstverlener, verlies van apparatuur of een incident.
  • Versleutel MQTT-communicatie wanneer gegevens het lokale netwerk verlaten.
  • Houd de connectiviteitsstatus in de gaten: latentie, herverbindingen, signaalverlies, lokale wachtrijen.

Belangrijk Een 4G- of LTE-verbinding kan onderbroken worden, afhankelijk van de dekking, de antenne, de radio-omgeving en de netwerkbelasting. Het is daarom noodzakelijk om een strategie te hebben voor het opnieuw verbinden, het gebruik van een lokale buffer en het tijdstempelen van gegevens wanneer de continuïteit van de meting van belang is.

Veelvoorkomende fouten bij een Modbus-naar-MQTT-project​

Het verwarren van registeradres en documentadres​

Sommige fabrikanten documenteren de registers in basis 1, andere in basis 0. Een verwachte meting op 40001 kan dus, afhankelijk van de gebruikte tool, overeenkomen met een ander daadwerkelijk adres.

De woordvolgorde negeren​

32-bits waarden, met name drijvende-kommagetallen, kunnen met verschillende woordvolgordes worden gecodeerd. Een verkeerde configuratie kan leiden tot inconsistente waarden, zonder dat er sprake is van een fout in de Modbus-communicatie.

Te vaak stemmen​

Een gedeelde RS485-bus mag niet worden gepolld zoals een HTTP-API. Te agressief pollen kan de bus overbelasten, het aantal CRC-fouten doen toenemen of de langzamere apparaten blokkeren.

Te vage MQTT-onderwerpen publiceren​

Een onderwerp met een naam als data/value1 wordt al snel onbruikbaar. Het is beter om de onderwerpen te structureren op basis van de locatie, de gateway, de apparatuur en de tag.

site/{site_id}/gateway/{gateway_id}/equipment/{asset_id}/metric/{tag}

De kwaliteit van de gegevens vergeten​

Een waarde zonder kwaliteitsindicator kan verkeerd worden geïnterpreteerd. Door een veld quality, een tijdstempel en eventueel een foutcode toe te voegen, wordt de verwerking aan de supervisiezijde vergemakkelijkt.

Aanbevolen standaardarchitectuur​

LaagFunctieVoorbeeld
VeldMeting en automatiseringSensoren, meters, PLC's, regelaars
Edge-gegevensverzamelingModbus-uitlezing, filtering, tijdstempelsEziwan-gateway
TransportBeveiligde MQTT-publicatieMQTT-broker
VerwerkingLogboekregistratie, waarschuwingen, transformatieInfluxDB, Node-RED, cloudplatform
VisualisatieMonitoring en besluitvormingGrafana, cloud-SCADA, bedrijfsapplicatie

Door deze scheiding wordt de architectuur overzichtelijker: het terrein blijft stabiel, de gateway vertaalt de gegevens en de cloud verwerkt ze.

Veelgestelde vragen — MQTT, RS485 en Modbus​

Kunnen Modbus RTU en MQTT naast elkaar op dezelfde gateway worden gebruikt?​

Ja. Dat is zelfs een van de klassieke scenario’s voor een IIoT-gateway: veldgegevens verzamelen via Modbus RTU over RS485 en deze vervolgens via MQTT naar een broker of een cloudplatform verzenden. De twee protocollen hebben niet dezelfde functie: Modbus wordt gebruikt om apparatuur te ondervragen, MQTT om de gegevens naar de applicaties te verzenden.

Wat is het verschil tussen RS485 en Modbus RTU?​

RS485 is de fysieke laag: bekabeling, elektrische signalen, bustopologie. Modbus RTU is het applicatieprotocol: framestructuur, adressering van slaves, lees- en schrijffuncties, foutcontrole. RS485 kan met andere protocollen worden gebruikt, maar de combinatie RS485 + Modbus RTU blijft zeer gangbaar in industriële omgevingen.

Hoeveel apparaten kunnen er op een RS485-bus worden aangesloten?​

Het antwoord hangt af van de transceivers, de elektrische belasting van de bus, de kabellengte, de overdrachtssnelheid en de kwaliteit van de installatie. De vaak genoemde limiet voor een klassiek RS485-segment is 32 afzonderlijke belastingen, maar moderne apparatuur met een lage belasting en repeaters kunnen uitgebreidere architecturen mogelijk maken. In de praktijk moet de topologie worden getoetst aan de specificaties van de apparatuur en de beperkingen van de locatie.

Is MQTT geschikt als de 4G-verbinding onregelmatig is?​

MQTT kan worden aangepast aan onderbrekingen in de verbinding, mits de architectuur correct is ontworpen: aangepaste servicekwaliteit, correcte herverbinding, lokale tijdstempels, wachtrij aan de gatewayzijde en bewaking van de netwerkstatus. Protocolrobuustheid mag echter niet worden verward met radiodisponibiliteit: de kwaliteit van de mobiele dekking blijft een doorslaggevende factor.

Moet je kiezen voor MQTT of OPC UA?​

De twee protocollen voorzien niet precies in dezelfde behoefte. MQTT is lichtgewicht en zeer efficiënt voor het publiceren van berichten naar een broker. OPC UA biedt meer mogelijkheden voor het modelleren van apparatuur, het weergeven van industriële semantiek en het integreren van bepaalde automatiseringssystemen. In veel projecten wordt MQTT gekozen voor publicatie in de cloud, terwijl OPC UA relevant blijft voor industriële monitoring of machine-integratie.

Hoe beveilig je een industriële MQTT-publicatie?​

Er moet op zijn minst versleuteling van de verbindingen plaatsvinden wanneer gegevens het lokale netwerk verlaten, clients moeten worden geauthenticeerd, rechten moeten per topic worden beperkt, verbindingen moeten worden gelogd en er moet voorzien worden in het intrekken van toegangsrechten. De beveiliging moet ook de gateway zelf omvatten: beveiligd beheer, gecontroleerde updates, netwerksegmentatie en monitoring van gebeurtenissen.

Nog een stap verder met Eziwan​

Heeft u RS485-, Modbus RTU-, Modbus TCP- of MQTT-apparatuur die u in een cloudarchitectuur wilt integreren? De juiste aanpak bestaat erin de bestaande protocollen in kaart te brengen, de beperkingen in de praktijk te identificeren en vervolgens een geschikte gateway tussen OT en IT te definiëren.

Aanvullende bronnen​