Modbus, MQTT, OPC-UA: welk industrieel protocol moet je in 2026 kiezen?

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

De vraag „Welk protocol moet ik gebruiken voor mijn industriële IoT-project?“ komt steevast terug bij projecten voor fabrieksmodernisering. Modbus, MQTT en OPC-UA zijn de drie meest genoemde protocollen — maar ze zijn geen gelijkwaardige alternatieven. Ze werken op verschillende lagen, voorzien in verschillende behoeften en vullen elkaar vaak aan in plaats van met elkaar te concurreren.

Dit artikel belicht de fundamentele verschillen, de sterke punten en de beperkingen ervan, en biedt u een hulpmiddel bij het kiezen van het juiste protocol voor uw specifieke toepassing.

Eerst begrijpen: protocollen van verschillende aard​

Voordat we een vergelijking maken, moeten we beseffen dat Modbus, MQTT en OPC-UA niet op hetzelfde niveau werken:

Modbus is een protocol voor het uitlezen van gegevens: hiermee kan een apparaat worden ondervraagd om de registers ervan (meetwaarden, statussen) uit te lezen. Het is een veldprotocol van het type master/slave, dat is ontworpen voor het verzamelen van gegevens uit industriële apparatuur.

MQTT is een berichtenprotocol: hiermee kun je gegevensstromen publiceren en je daarop abonneren via een gecentraliseerde broker. Het is een protocol voor het verzenden van berichten, niet voor het rechtstreeks ophalen van gegevens van apparatuur.

OPC-UA is een servicearchitectuur: het combineert gegevensverzameling, toegang tot het gegevensmodel, beveiliging, alarmen en historiek in één enkele, uniforme industriële standaard. Het is de meest complete — en meest complexe — oplossing.

In de praktijk: De meeste moderne industriële IoT-architecturen maken gebruik van alle drie. Modbus om veldapparatuur uit te lezen. MQTT om de gegevens naar de cloud te verzenden. OPC-UA voor interoperabiliteit tussen complexe systemen.

Modbus RTU en Modbus TCP​

Wat is Modbus?​

Modbus werd in 1979 ontwikkeld door Modicon (tegenwoordig Schneider Electric). Het is het oudste industriële protocol dat nog steeds actief in gebruik is — en veruit het meest verspreid in de Franse industriële sector.

Modbus RTU werkt via een seriële RS-485-verbinding (of RS-232). Het is een asynchroon, master/slave-systeem met een lineaire bustopologie (multidrop). Er kunnen maximaal 247 slaves op één RS-485-bus worden aangesloten.

Modbus TCP is Modbus ingekapseld in TCP/IP-pakketten. Het werkt via Ethernet, poort 502. Het behoudt het master/slave-model, maar maakt willekeurige netwerktopologieën mogelijk (ster, boom). Er is geen strikte limiet voor het aantal slaves op netwerkniveau.

Wat je met Modbus kunt uitlezen​

Modbus biedt 4 soorten gegevens:

  • Coils (0x): digitale uitgangen (lezen/schrijven) (booleaanse waarden)
  • Discrete Inputs (1x): digitale ingangen (alleen lezen) (booleaanse waarden)
  • Input Registers (3x): 16-bits registers (alleen-lezen) (sensormetingen)
  • Holding Registers (4x): 16-bits registers (lezen/schrijven) (instelwaarden, parameters)

Om een temperatuurwaarde van een sensor uit te lezen: de master stuurt een verzoek „lees de registers 3x01 tot en met 3x02”, waarna de slave antwoordt met de twee registers die de waarde bevatten (meestal een 32-bits float verdeeld over twee aaneengesloten registers).

Voordelen van Modbus​

Absolute universaliteit: Als u industriële apparatuur hebt met een RS-485-poort of een ethernetpoort en niet weet welk protocol deze gebruikt, probeer dan eerst Modbus. De kans is zeer groot dat het apparaat Modbus ondersteunt.

Eenvoud: Het protocol is eenvoudig — genummerde registers, standaard lees- en schrijffuncties. Elke ontwikkelaar kan binnen een paar uur een Modbus-client implementeren.

Veerkracht: Geen afhankelijkheid van een broker of een centrale server. De master vraagt rechtstreeks informatie op bij elke slave. Een storing bij de master heeft geen invloed op de onderlinge communicatie tussen de slaves.

Volwassenheid: 45 jaar industriële toepassing. Er bestaan Modbus-bibliotheken voor alle programmeertalen (Python, C, Java, JavaScript...).

Beperkingen van Modbus​

Uitsluitend pull-architectuur: De master moet elke slave proactief opvragen. De apparaten sturen niet uit zichzelf gegevens. Op een bus met 50 slaves die elke seconde worden opgevraagd, kan de werkelijke frequentie per slave dalen tot 20 seconden.

Geen ingebouwde beveiliging: Modbus RTU en Modbus TCP beschikken niet over authenticatie- of versleutelingsmechanismen. Elk apparaat in het netwerk kan de registers van een blootgestelde Modbus-apparatuur lezen of schrijven. Beveiliging moet op netwerkniveau worden toegevoegd (VPN, segmentatie).

Geen automatische detectie: Er is geen mechanisme om Modbus-apparaten op een bus te detecteren. U moet het slave-adres en de registeradressen van elk apparaat kennen.

Geen semantische naamgeving: Register 40001 geeft niet aan wat het bevat — je hebt de documentatie van de fabrikant nodig om te weten dat het om de „temperatuur van het binnenkomende water“ gaat. Geen zelfbeschrijving.

Wanneer moet Modbus worden gebruikt?​

  • Uitlezen van gegevens uit veldapparatuur (energiemeters, druksensoren, frequentieregelaars, PLC’s)
  • Bestaande veldnetwerken met RS-485-bekabeling
  • Projecten met heterogene apparatuur van verschillende fabrikanten (Modbus is het meest universeel)
  • Beperkte budgetten of teams zonder gespecialiseerde expertise

MQTT (Message Queuing Telemetry Transport)​

Wat is MQTT?​

MQTT is in 1999 door IBM ontwikkeld voor telemetrie via satellietverbindingen met een lage bandbreedte. Het is in 2014 (MQTT 3.1.1) en 2019 (MQTT 5.0) door OASIS gestandaardiseerd.

MQTT is een publish/subscribe-protocol: publishers versturen berichten naar topics, subscribers ontvangen de berichten op de topics waarop ze zijn geabonneerd. Een centrale MQTT-broker stuurt de berichten door tussen publishers en subscribers.

MQTT-architectuur​

De broker vormt het hart van de MQTT-architectuur. De clients (publishers en subscribers) maken verbinding met de broker — ze communiceren nooit rechtstreeks met elkaar.

Sterke punten van MQTT​

Push-architectuur: Uitgevers sturen gegevens wanneer ze iets te melden hebben. Er vindt geen polling plaats — de abonnee ontvangt de gegevens onmiddellijk na publicatie. Typische latentie: 10-50 ms end-to-end.

Lightweight: Het protocol is ontworpen voor apparaten met beperkte middelen (microcontrollers, 2G-modems). Een MQTT-bericht kan in 2 bytes passen (minimale header). Zeer zuinig met bandbreedte.

Configureerbare QoS: Drie niveaus van servicekwaliteit: QoS 0 (hoogstens één keer), QoS 1 (minstens één keer), QoS 2 (precies één keer). Voor kritieke toepassingen garandeert QoS 2 dat de gegevens precies één keer worden afgeleverd.

Cloud-interoperabiliteit: Alle grote cloudproviders (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) bieden een native MQTT-broker aan. MQTT is het de facto-protocol voor IoT-cloudarchitecturen.

Native TLS: MQTT ondersteunt TLS 1.3 native. Beveiliging is in het protocol ingebouwd, het is geen toevoeging.

Beperkingen van MQTT​

Kan apparaten niet rechtstreeks uitlezen: Een Modbus RTU-apparaat ondersteunt MQTT niet standaard. Er is een gateway nodig die de Modbus-gegevens uitleest en deze via MQTT publiceert. Daarom worden Modbus en MQTT vaak samen gebruikt in industriële IoT-architecturen.

Afhankelijkheid van de broker: Als de MQTT-broker uitvalt, stort de hele berichtenarchitectuur in. De veerkracht van de broker is van cruciaal belang. Beheerde brokers (AWS IoT, HiveMQ Cloud) zijn zeer betrouwbaar, maar zorgen voor een afhankelijkheid van een externe dienst.

Geen gestandaardiseerd gegevensmodel: MQTT legt noch het formaat van de berichten, noch de structuur van de topics vast. Elke implementatie is vrij — wat de interoperabiliteit in de weg staat. Twee MQTT-systemen van verschillende leveranciers communiceren niet noodzakelijkerwijs met elkaar zonder aanpassingen.

Geen native vraag-antwoord-mechanisme: MQTT is gericht op unidirectionele gebeurtenissen. Om een vraag-antwoordpatroon te implementeren (bijv. een parameter opvragen bij een apparaat), moet MQTT 5.0 worden gebruikt met gecorreleerde antwoordtopics — dit is mogelijk, maar complexer.

Wanneer moet je MQTT gebruiken?​

  • Gegevensoverdracht van het veld naar de cloud (Modbus → Gateway → MQTT → Cloud)
  • Gebeurtenisgestuurde architecturen waarbij gegevens onregelmatig veranderen
  • Embedded IoT-implementaties op microcontrollers of apparaten met beperkte capaciteit
  • Integratie met native cloudbrokers (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

Wat is OPC-UA?​

OPC-UA (IEC 62541) is vanaf 2006 door de OPC Foundation ontwikkeld als opvolger van OPC Classic (gebaseerd op COM/DCOM van Windows). Het is de meest ambitieuze industriestandaard: het combineert gegevensverzameling, een semantisch model, beveiliging, historiek, alarmen en toegang tot methoden in één enkel protocol.

OPC-UA is tegenwoordig het favoriete protocol van PLC-fabrikanten voor Industry 4.0-architecturen: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation — ze ondersteunen OPC-UA al 5 tot 10 jaar standaard.

Sterke punten van OPC-UA​

Semantisch gegevensmodel: In tegenstelling tot Modbus (anonieme, genummerde registers) biedt OPC-UA een boomstructuur van benoemde en getypeerde objecten. Het knooppunt "ns=2;i=1001" kan bijvoorbeeld "Machine1/Hoofdmotor/Lagertemperatuur" heten, met bijbehorende metadata (eenheid, bereik, beschrijving). Zelfbeschrijving is standaard ingebouwd.

Ingebouwde beveiliging: authenticatie, autorisatie, versleuteling, integriteit van berichten — alles is in het protocol opgenomen. OPC-UA ondersteunt verschillende beveiligingsprofielen (None, Sign, SignAndEncrypt) met moderne algoritmen (AES-256, RSA-2048+).

Publish/Subscribe via OPC-UA PubSub (2017): OPC-UA kan nu niet alleen in de vraag-antwoordmodus (pull), maar ook in de asynchrone publicatiemodus (push) werken. Het kan gegevens publiceren naar MQTT-brokers, waardoor OPC-UA en MQTT elkaar aanvullen in plaats van met elkaar te concurreren.

Toegang tot methoden: Met OPC-UA kunnen methoden op apparaten worden aangeroepen — het gaat niet alleen om het uitlezen van waarden. Het bedienen van een klep, het starten van een motor — alles wordt gemodelleerd als een OPC-UA-object.

Semantiek en interoperabiliteit: De OPC-UA „Companion Specifications“ definiëren gestandaardiseerde modellen per sector: OPC-UA voor kunststoffen, voor robotica, voor PackML (verpakking), voor mijnbouw... SCADA-software die OPC-UA for PackML ondersteunt, kan verbinding maken met elke conforme verpakkingslijn, zonder dat daarvoor een specifieke configuratie nodig is.

Beperkingen van OPC-UA​

Complexiteit: OPC-UA is het meest complexe protocol om te implementeren en te configureren. De specificaties beslaan meer dan 1000 pagina’s. De leercurve is aanzienlijk voor teams die nog geen ervaring hebben met OPC-UA.

Vereiste middelen: Een volledige OPC-UA-server vereist meer middelen dan een Modbus-slave. Oudere PLC’s of microcontrollers met beperkte capaciteit kunnen geen volledige OPC-UA-stack ondersteunen (er bestaan echter vereenvoudigde „nano”-profielen).

Niet universeel in het veld: Oudere apparatuur (van vóór 2010-2015) ondersteunt OPC-UA niet. In een heterogeen industrieel apparaatpark zult u bij bestaande veldapparatuur veel vaker Modbus tegenkomen dan OPC-UA.

Netwerk-overhead: OPC-UA-berichten zijn omvangrijker dan Modbus-berichten (XML of binair, afhankelijk van het transportprotocol). Bij 4G-verbindingen met een lage bandbreedte kan dit een rol spelen.

Wanneer moet OPC-UA worden gebruikt?​

  • Recente Siemens S7-1200/1500-PLC’s met TIA Portal (native OPC-UA)
  • Industry 4.0-architecturen met interoperabiliteit tussen SCADA, MES en ERP
  • Projecten die een hoge mate van beveiliging en traceerbaarheid van de toegang vereisen
  • Omgevingen met apparatuur van verschillende fabrikanten waar semantische interoperabiliteit vereist is

Beslissingsgids: welke combinatie past bij uw project?​

Eenvoudige, typische industriële IoT-architectuur​

Toepassing: Procesbewaking, waarschuwingen, historiek. 80% van de Franse industriële IoT-projecten past in dit patroon.

Architectuur met cloud-integratiebus​

Toepassing: Projecten met meerdere gegevensgebruikers (SCADA + ERP + BI). MQTT als integratiebus.

Industrie 4.0-architectuur met OPC-UA​

Toepassing: Fabrieken met moderne besturingssystemen, Industry 4.0-projecten, MES-integratie.

Beslissingsmatrix​

BehoefteModbus RTUModbus TCPMQTTOPC-UA
RS-485-veldsensoren uitlezen✓✓———
PLC's via het netwerk uitlezen✓✓✓—✓
Gegevens naar de cloud verzenden——✓✓✓
SCADA/MES-interoperabiliteit✗✗Gedeeltelijk✓✓
Geïntegreerde beveiliging✗✗TLS✓✓
Oude apparatuur✓✓✓—✗
Recente PLC's (>2015)✓✓—✓✓
Cloud-native architecturen✗✗✓✓✓
MKB zonder protocolexpertise✓✓✓✓✓✗

Hoe Eziwan de drie protocollen beheert​

De Eziwan-gateway is protocolonafhankelijk wat betreft de veldapparatuur:

  • Modbus RTU: ingebouwde RS-485-poort, mastermodus, maximaal 247 slaves per bus, polling instelbaar van 1 s tot 15 min
  • Modbus TCP: Modbus TCP-client, gelijktijdige verbindingen met meerdere Modbus-servers
  • MQTT: MQTT-publisher (publicatie van verzamelde gegevens), abonnee mogelijk voor opdrachten
  • OPC-UA: OPC-UA-client (uitlezen van knooppunten, abonneren op waardeveranderingen) — beschikbaar op aanvraag voor OPC-UA-implementaties

Wat de cloud betreft, worden de gegevens intern gestandaardiseerd en beschikbaar gesteld via:

  • REST-API (JSON) voor cloudtoepassingen
  • Webhooks voor realtime gebeurtenissen
  • MQTT (uitgaand) voor busintegraties

U kunt Modbus RTU op de veldapparatuur combineren met MQTT naar uw AWS/Azure-cloud zonder iets te hoeven wijzigen — de gateway zorgt voor de conversie.

Conclusie​

In 2026 is het antwoord op de vraag „Modbus of MQTT of OPC-UA?“ meestal „alle drie samen“:

  • Modbus om uw veldapparatuur uit te lezen (zo noemen ze het)
  • MQTT om de gegevens naar uw cloud te verzenden en ze naar meerdere applicaties te distribueren
  • OPC-UA als u over recente PLC's van Siemens/Rockwell/Beckhoff beschikt en SCADA/MES-interoperabiliteit nodig hebt

Het is geen wedstrijd — het is een gelaagde architectuur. De keuze is niet „welk protocol”, maar „welk protocol op welke laag voor welke apparatuur”.

Veelgestelde vragen — Modbus, MQTT en OPC-UA​

Kan men Modbus en MQTT tegelijkertijd op dezelfde gateway gebruiken?

Ja, en dat is de meest gangbare architectuur in het IIoT. De gateway verzamelt de gegevens van de PLC’s via Modbus TCP of RTU (veldlaag) en publiceert deze via MQTT naar de cloud (transportlaag). Modbus stopt bij de gateway — het wordt nooit op het internet blootgesteld. MQTT neemt het vervolgens over voor het transport naar de cloud, met TLS 1.3 en authenticatie.

Kan OPC-UA Modbus vervangen op bestaande PLC’s (S7-1200, M340)?

Op de Siemens S7-1200 is de OPC-UA-server pas beschikbaar vanaf firmwareversie V4.4 en moet deze expliciet worden geconfigureerd in TIA Portal. Op de S7-1500 is deze functie standaard aanwezig vanaf firmwareversie V2.0. Op de Schneider M340 is OPC-UA niet standaard ingebouwd — hiervoor is een extra module nodig. In de praktijk blijft Modbus TCP voor bestaande installaties de universele oplossing; OPC-UA is vooral relevant voor nieuwe projecten met recente besturingssystemen.

MQTT met QoS 0 versus QoS 1 versus QoS 2 — wat is de beste keuze voor industriële monitoring?

Voor het monitoren van procesgegevens (temperaturen, drukken) biedt QoS 1 (At Least Once) de juiste balans: de levering is gegarandeerd, zelfs na het herstellen van de verbinding, met het risico op enkele duplicaten (wat acceptabel is voor monitoringgegevens). QoS 2 (Exactly Once) is zwaarder vanwege de heen-en-terug-bevestiging en is zelden nodig voor metingen. QoS 0 (At Most Once) is geschikt voor zeer frequente gegevens (> 1/s) waarbij incidenteel verlies aanvaardbaar is.

Is een openbare MQTT-broker (HiveMQ, EMQX cloud) voldoende voor de industriële sector?

Voor proefprojecten of niet-kritieke toepassingen, ja. Maar voor een productieomgeving met vertrouwelijkheidsvereisten (procesgegevens, identificatiegegevens van apparatuur) verdient een in Frankrijk gehoste privé-broker de voorkeur. MQTT-gegevens die via Amerikaanse openbare brokers worden verzonden, vallen mogelijk onder de CLOUD Act — dit moet worden beoordeeld op basis van de gevoeligheid van de gegevens en de sector waarin men actief is.

Heeft OPC-UA invloed op de prestaties van de PLC in vergelijking met Modbus?

OPC-UA vraagt aanzienlijk meer CPU-vermogen en geheugen dan Modbus TCP. Op een S7-1500 CPU 1511 met een actieve OPC-UA-server en 50 clientverbindingen kan de cyclustijd met 5 tot 15 % toenemen. Op een S7-1200 zijn de middelen beperkter — test daarom altijd de impact met het volledige productieprogramma voordat u OPC-UA in productie implementeert.

Meer informatie​

Aanvullende bronnen​