Tema Händelsedriven IT/OT-integration
MQTT i korthet
MQTT är ett lättviktigt client/server-protokoll för publish/subscribe-meddelanden. En klient publicerar ett meddelande till ett topic. En server, ofta kallad broker, matchar det mot prenumerationer och förmedlar det vidare. Producenten behöver därför inte känna till konsumenterna.
I sitt sammanhang
Det gör MQTT användbart när många enheter och system ska utbyta små händelser över länkar där bandbredd, kodstorlek eller stabilitet spelar roll. Men protokollet är en transport, inte en färdig informationsmodell. Det kan flytta ett värde effektivt utan att förklara vad värdet betyder.
Från punkt-till-punkt till händelseflöde
Tänk en energimätare som publicerar site/line-2/meter-7/power. Driftbilden, energianalysen och ett larmsystem kan prenumerera oberoende av varandra. En ny konsument kan läggas till utan att mätaren byggs om. Den lösa kopplingen är MQTT:s stora styrka.
Det moderna valet är inte mellan data i realtid och ordnad information. Bra arkitektur kräver båda.
De fyra beslut som formar lösningen
1. Topic-strukturen
Topics är adresser för leverans, inte automatiskt stabila objektidentifierare. Bestäm namnregler, hierarki, versionering och vilka nivåer som får användas i behörigheter. Undvik att baka in tillfälliga organisationsnamn i en struktur som ska leva längre än organisationen.
2. Payloadens kontrakt
MQTT är agnostiskt till innehållet. JSON, binärdata eller andra format kan användas, men schema, enhet, tidsstämpel, kvalitet och källidentitet måste definieras utanför kärnprotokollet. Det är här en informationsmodell eller ett etablerat tillägg som Sparkplug B kan bli relevant.
3. Leveransnivå och livslängd
MQTT definierar tre QoS-nivåer: QoS 0 är ”högst en gång”, QoS 1 ”minst en gång” och QoS 2 ”exakt en gång” i protokollets leveransflöde. Högre QoS innebär mer tillstånd och fler paket. Det ersätter inte idempotent behandling i mottagande affärslogik. Retained messages, sessions- och message expiry samt Last Will måste också väljas utifrån värdets livslängd och konsekvens.
4. Tillit och drift
MQTT 5.0 rekommenderar autentisering, auktorisering och säker kommunikation för känsliga tillämpningar men lämnar teknikvalet till implementationen. TLS, klientidentiteter och topic-baserade rättigheter behöver kombineras med certifikatrotation, övervakning, kapacitetsgränser och en plan för brokerbortfall.
När passar MQTT?
- När producenter och konsumenter ska kunna utvecklas oberoende.
- När små, frekventa händelser ska distribueras till en eller flera mottagare.
- När anslutningar kan vara begränsade eller periodvis brutna.
- När teamet kan äga topic-, payload- och säkerhetskontrakten över tid.
För synkrona frågor, komplexa resursoperationer eller stora historiska uttag är ett REST API, en frågetjänst eller en dataplattform ofta ett bättre komplement. MQTT behöver inte vinna varje integrationssituation för att vara rätt där händelsen föds.
HubMinds kontrollfrågor före pilot
- Vilket stabilt objekt identifierar varje topic och payload?
- Vad händer med dubbletter, luckor, gamla retained-värden och omordning?
- Vilken QoS kräver konsekvensen, inte magkänslan?
- Vem får publicera och prenumerera på varje del av topic-trädet?
- Hur upptäcks schemaändringar och inkompatibla klienter?
- Hur återställs flödet efter nät- eller brokerbortfall?
HubMinds syn
MQTT är ett nervsystem för händelser, inte organisationens minne. Koppla protokollet till stabila objektidentiteter, explicita datakontrakt och mätbar förvaltning. Då kan händelseflödet växa utan att betydelsen löses upp.
Relaterade begrepp
Relaterat: OPC UA, JSON, broker och Sparkplug B.
Omfattning och aktualitet
Sidan avser MQTT 5.0 och de grundprinciper som även präglar MQTT 3.1.1. Granskad 31 augusti 2026; ny granskning krävs när OASIS publicerar en ny huvudversion eller när säkerhetsrekommendationerna ändras.