Wat is MQTT?
MQTT is een lichtgewicht, open publish/subscribe-berichtenprotocol waarmee apparaten via een centrale broker berichten uitwisselen over netwerken met beperkte bandbreedte, hoge latency of een onbetrouwbare verbinding. Een sensor, PLC of gateway publiceert data op een topic, en elke toepassing die op dat topic is geabonneerd ontvangt het bericht, zonder dat zender en ontvanger elkaar kennen. MQTT is uitgegroeid tot een van de belangrijkste protocollen van het Industrial Internet of Things (IIoT) en verbindt SCADA, MES, edge en cloud in moderne OT-architecturen.
🕰️ Waar komt MQTT vandaan?
MQTT werd in 1999 ontwikkeld door Andy Stanford-Clark (IBM) en Arlen Nipper (Arcom, nu Eurotech) om olie-pijpleidingen te bewaken via SCADA-verbindingen over satelliet. Die verbindingen waren duur, traag en onbetrouwbaar, en de veldapparatuur werkte vaak op batterijen. Daaruit volgen de ontwerpeisen die MQTT nog steeds kenmerken: minimale overhead, weinig rekenkracht en tolerantie voor wegvallende verbindingen. Daardoor draait een MQTT-client ook op kleine embedded systemen en veldapparatuur, wat het protocol geschikt maakt voor telemetrie.
De naam kwam oorspronkelijk van MQ Telemetry Transport, naar IBM’s productlijn MQSeries. De vaak gebruikte uitleg Message Queuing Telemetry Transport is misleidend: MQTT gebruikt geen berichtenwachtrijen maar publish/subscribe. Sinds de standaardisatie bij OASIS is MQTT gewoon de naam van het protocol en geen afkorting meer.
| Jaar | Mijlpaal |
|---|---|
| 1999 | Eerste versie door IBM en Arcom voor pijpleidingbewaking |
| 2010 | IBM publiceert MQTT 3.1 royaltyvrij |
| 2013 | IBM brengt MQTT onder bij standaardisatieorganisatie OASIS |
| 2014 | MQTT 3.1.1 wordt op 29 oktober een OASIS-standaard |
| 2016 | MQTT 3.1.1 wordt internationale norm ISO/IEC 20922:2016 |
| 2019 | MQTT 5.0 wordt op 7 maart een OASIS-standaard |
| 2023 | Sparkplug 3.0 wordt internationale norm ISO/IEC 20237 |
🧠 Hoe werkt het publish/subscribe-model van MQTT?
In plaats van dat een systeem elk apparaat periodiek uitvraagt (polling, zoals bij Modbus TCP), stuurt elk apparaat zelf een bericht zodra er iets verandert. Dit subscribe-patroon kent drie rollen:
- Publisher - een client die berichten op een topic plaatst, bijvoorbeeld een edge device met temperatuurwaarden
- Subscriber - een client die zich abonneert op één of meer topics, zoals een historian of dashboard
- Broker - de centrale server die alle berichten ontvangt, filtert op topic en doorstuurt naar de juiste abonnees; bekende brokers zijn Mosquitto, HiveMQ en EMQX
Elke client kan zowel publiceren als abonneren. De broker ontkoppelt de partijen in ruimte (ze kennen elkaars adres niet) en in tijd (een abonnee hoeft niet gelijktijdig online te zijn als de sessie persistent is). MQTT draait normaal over TCP/IP, eventueel via WebSockets; de vaste header is minimaal 2 bytes en een bericht kan tot circa 256 MB groot zijn. Voor netwerken zonder TCP bestaat de variant MQTT-SN.
Topics en wildcards
Topics zijn hiërarchische tekstpaden, gescheiden door een /, bijvoorbeeld fabriek/hal2/lijn3/oven1/temperatuur. Abonnees kunnen twee wildcards gebruiken:
-
+- één niveau:fabriek/+/lijn3/#vangt lijn 3 in elke hal -
#- alle onderliggende niveaus, alleen aan het eind:fabriek/hal2/#
Topics die met $ beginnen, zoals $SYS/ voor brokerstatistieken, vallen buiten
wildcards op het eerste niveau.
🔧 Welke QoS-niveaus en functies biedt MQTT?
MQTT laat u per bericht kiezen hoeveel leveringszekerheid nodig is. Hogere QoS betekent meer berichtenverkeer en meer vertraging.
| QoS | Garantie | Handshake | Typisch gebruik |
|---|---|---|---|
| 0 | Hoogstens één keer (fire and forget) | Geen bevestiging | Frequente meetwaarden waarbij een gemiste waarde niet erg is |
| 1 | Minstens één keer, duplicaten mogelijk | PUBLISH → PUBACK | Alarmen, statusberichten, de meeste IIoT-data |
| 2 | Precies één keer | Vier stappen: PUBLISH, PUBREC, PUBREL, PUBCOMP | Tellerstanden, transacties, opdrachten |
Naast QoS zijn vier functies belangrijk voor industriële toepassingen:
- Retained messages - de broker bewaart het laatste bericht op een topic en stuurt het direct naar elke nieuwe abonnee, zodat een dashboard meteen de actuele waarde toont
- Last Will and Testament - bij het verbinden registreert een client een testamentbericht dat de broker publiceert als de client onverwacht wegvalt
- Keep alive - client en broker controleren met PINGREQ/PINGRESP of de verbinding nog leeft
- Persistent sessions - de broker onthoudt abonnementen en bewaart QoS 1/2-berichten voor een tijdelijk offline client (in MQTT 5 via Clean Start en Session Expiry Interval)
🆕 Wat is er nieuw in MQTT 5.0?
MQTT 5.0 voegt functies toe die vooral grote en industriële installaties helpen, terwijl het basismodel gelijk blijft:
- Reason codes - elke bevestiging meldt waarom iets lukte of mislukte
- Shared subscriptions - meerdere clients verdelen de berichten van één topic voor load balancing
- Message en session expiry - berichten en sessies verlopen na een ingestelde tijd
- Topic aliases - lange topicnamen worden vervangen door een kort getal om bandbreedte te sparen
- User properties - eigen metadata als sleutel-waardeparen in de header
- Request/response en enhanced authentication - o.a. voor challenge-response-authenticatie
Veel industriële software ondersteunt nog alleen 3.1.1; brokers als Mosquitto, HiveMQ en EMQX kunnen beide versies tegelijk bedienen.
🏭 Hoe wordt MQTT in OT en IIoT gebruikt?
| Toepassing | Voorbeeld |
|---|---|
| Sensorcommunicatie | Een temperatuur- of trillingssensor stuurt data naar de Cloud voor condition monitoring |
| Procesdata ontsluiten | Een PLC of edge-gateway publiceert procesdata naar MES, historian of cloud |
| Externe Monitoring | Een SCADA-systeem zoals Ignition ontvangt MQTT-berichten van edge-devices op afgelegen locaties |
| Onderhoud en analytics | Machines sturen status, storingen of onderhoudsdata naar AI-toepassingen |
| Integratie en prototyping | Node-RED vertaalt Modbus- of OPC UA-data naar MQTT-topics |
Sparkplug B en de Unified Namespace
MQTT schrijft niet voor hoe topics en payloads eruitzien. Daardoor bedenkt elk project zijn eigen
structuur. MQTT Sparkplug B, beheerd door de Eclipse Foundation en sinds 2023 norm ISO/IEC 20237,
standaardiseert dat: een vaste topicstructuur (spBv1.0/groep/berichttype/edge-node/device),
payloads in Google Protocol Buffers, birth- en death-berichten (NBIRTH, NDEATH, DBIRTH,
DDEATH) en report by exception. Het NDEATH-bericht wordt als Last Will geregistreerd, zodat SCADA
direct ziet wanneer een edge node offline gaat.
In een event-driven architectuur kunnen nieuwe clients eenvoudig aansluiten zonder bestaande koppelingen te wijzigen. Een Unified Namespace (UNS), een begrip dat rond 2020 werd gepopulariseerd door Walker Reynolds, gebruikt een MQTT-broker als centrale, actuele databron voor de hele organisatie. De topics volgen daarbij meestal de ISA-95-hiërarchie (onderneming/site/gebied/lijn/cel), zodat MES, ERP en analytics dezelfde structuur gebruiken.
🔄 Wat is het verschil tussen MQTT, OPC UA en AMQP?
| Kenmerk | MQTT | OPC UA | AMQP |
|---|---|---|---|
| Model | Publish/subscribe via broker | Client/server, plus PubSub | Berichten via queues in een broker (exchanges in AMQP 0-9-1) |
| Norm | OASIS, ISO/IEC 20922 | IEC 62541 | OASIS, ISO/IEC 19464 |
| Datamodel | Geen, payload vrij (Sparkplug voegt het toe) | Uitgebreid informatiemodel met types en methoden | Geen, payload vrij |
| Overhead | Zeer laag | Middel tot hoog | Middel |
| Beveiliging | TLS + broker-ACL’s | Ingebouwd: certificaten, signing, encryptie | TLS + SASL |
| Typische rol | Edge-naar-cloud, IIoT, UNS | Machine- en systeemintegratie in OT | Enterprise-messaging, IT-integratie |
In de praktijk vullen ze elkaar aan. OPC UA PubSub kan MQTT zelfs als transport gebruiken, en veel architecturen lezen machines uit via OPC UA en publiceren de data verder via MQTT. Voor grote stromen naar IT worden brokers vaak gekoppeld aan Apache Kafka; voor zeer beperkte apparaten is CoAP een alternatief.
🔐 Hoe beveiligt u MQTT in OT-omgevingen?
MQTT zelf heeft weinig ingebouwde beveiliging: authenticatie is optioneel en verkeer op poort 1883 is onversleuteld. Zoekmachines als Shodan indexeren honderdduizenden brokers die openstaan op internet, vaak zonder wachtwoord, waardoor iedereen kan meelezen of zelfs commando’s kan publiceren. Beveilig MQTT daarom met deze stappen:
- Versleutel altijd - gebruik TLS op poort 8883 en schakel poort 1883 uit buiten testomgevingen; encryptie beschermt ook wachtwoorden in het CONNECT-bericht.
- Authenticeer elke client - met gebruikersnaam en wachtwoord, of beter met X.509-clientcertificaten (mutual TLS) en goed certificaatbeheer; zet anonieme toegang uit.
-
Autoriseer per topic - leg in ACL’s vast welke client op welke topics mag publiceren of abonneren, volgens least privilege. Een sensor mag alleen zijn eigen topic beschrijven en nooit
#lezen. - Plaats de broker goed - zet de broker in een eigen zone of de IDMZ volgens het Purdue Model en het Zone and Conduits-model, afgeschermd met een firewall en VLAN’s. Laat OT-clients uitgaand verbinden, zodat geen inkomende poorten nodig zijn.
- Scheid lezen en schrijven - commando’s naar besturingen (zoals Sparkplug NCMD/DCMD) vragen extra controle; de regelkring zelf blijft lokaal in de PLC.
- Bewaak en patch - log verbindingen en mislukte aanmeldingen, voer ze naar security monitoring en houd brokersoftware actueel.
Deze maatregelen passen in Defense in Depth en sluiten aan op IEC 62443. Voor organisaties onder NIS2 horen open of onversleutelde brokers bij de risico’s die u aantoonbaar moet beheersen, en de Cyber Resilience Act eist dat fabrikanten producten met digitale elementen, zoals apparaten en software met MQTT-functionaliteit, standaard veilig geconfigureerd leveren.
❓ Veelgestelde vragen
Waar staat MQTT voor?
MQTT kwam oorspronkelijk van MQ Telemetry Transport, naar IBM’s productlijn MQSeries. De uitleg Message Queuing Telemetry Transport wordt vaak gebruikt, maar MQTT werkt niet met wachtrijen. Sinds de standaardisatie bij OASIS is MQTT de naam van het protocol en geen officiële afkorting meer.
Welke poort gebruikt MQTT?
MQTT gebruikt standaard TCP-poort 1883 voor onversleuteld verkeer en poort 8883 voor MQTT over TLS; beide zijn bij IANA geregistreerd. In productie- en OT-omgevingen hoort MQTT uitsluitend over poort 8883 met TLS te lopen.
Is MQTT een realtime protocol?
MQTT levert berichten met lage latency, vaak binnen milliseconden op een lokaal netwerk, maar is niet deterministisch. Het is daarom geschikt voor monitoring, data-acquisitie en integratie, niet voor realtime regelkringen of safety-functies. Die blijven in de PLC of het veldbussysteem.
Wat is een MQTT-broker?
Een MQTT-broker is de centrale server die alle berichten van publishers ontvangt en doorstuurt naar de clients die op het betreffende topic zijn geabonneerd. Bekende MQTT-brokers zijn Eclipse Mosquitto, HiveMQ en EMQX. Omdat alles via de broker loopt, moet u deze redundant uitvoeren en goed beveiligen.
Wat is het verschil tussen MQTT en Sparkplug B?
MQTT is het transportprotocol en laat de inhoud van topics en berichten vrij. Sparkplug B is een specificatie bovenop MQTT die een vaste topicstructuur, een binair payloadformaat en statusberichten voor edge nodes vastlegt. Daardoor worden MQTT-apparaten van verschillende leveranciers zonder maatwerk uitwisselbaar.
Moet ik MQTT 3.1.1 of MQTT 5.0 kiezen?
MQTT 5.0 is de nieuwste versie en biedt betere foutmeldingen, shared subscriptions en verlooptijden, wat helpt bij grote installaties. MQTT 3.1.1 wordt nog breder ondersteund door industriële apparaten en volstaat voor de meeste toepassingen. Veel brokers ondersteunen beide versies, zodat u ze naast elkaar kunt gebruiken.
📌 Samengevat
MQTT is het lichtgewicht publish/subscribe-protocol dat via een centrale broker sensoren, PLC’s, edge, SCADA en cloud met elkaar verbindt. Met QoS-niveaus, retained messages en Last Will, aangevuld met Sparkplug B en een Unified Namespace, vormt MQTT de ruggengraat van moderne IIoT-architecturen. Veilig gebruik in OT vraagt wel om TLS, client-authenticatie, topic-ACL’s en een goed afgeschermde broker.
