Co je MQTT a k čemu slouží ve IIoT? Popis protokolu MQTT
S rychlým rozvojem průmyslu se zvyšuje počet zařízení, která je třeba sledovat a přijímat z nich různá data. Pro řešení problému komunikace mezi četnými zařízeními a kombinací zařízení v jedné síti byl vytvořen koncept Internetu věcí (Internet of Things, IoT) - to je, když jsou zařízení sloučeny podle určité funkce nebo charakteristiky do jedné sítě, pak je několik podobných sítí jsou sloučeny do jiné velké sítě atd.
V takových sítích zařízení interagují navzájem prostřednictvím různých rozhraní a datových protokolů. Vzhledem k tomu, že uvažujeme o průmyslovém použití konceptu IoT, ve kterém by mělo být použito průmyslové zařízení s vlastními protokoly a hardwarem, přejdeme ke konceptu průmyslového internetu věci nebo IIoT (Industrial Internet of Things).
Pro vzájemnou interakci zařízení používají různé průmyslové protokoly, a protokol MQTT patří mezi oblíbené.
Co je MQTT?
MQTT nebo Message Queue Telemetry Transport je lehký, kompaktní a otevřený protokol výměny dat určený pro přenos dat na vzdálená místa, kde je vyžadována malá velikost kódu a existují omezení šířky pásma. Tyto výhody umožňují jeho použití v systémech M2M (machine-to-machine) a IIoT Systems (Industrial Internet of Things).
Existuje také verze protokolu MQTT-SN (MQTT for Sensor Networks) dříve známá jako MQTT-S, která je určena pro vestavěné bezdrátové zařízení bez podpory sítí TCP/IP, jako je ZigBee.
Vlastnosti protokolu MQTT
Základní vlastnosti protokolu MQTT:
- Asynchronní protokol
- Kompaktní zprávy
- Provoz v podmínkách nestabilního připojení datové přenosové linky
- Podpora několika úrovní kvality služeb (QoS)
- Snadná integrace nových zařízení
Podle hierarchie aplikací, protokol MQTT postavený nad TCP/IP a jako výchozí používá port 1883 (8883, při připojení přes SSL).
V protokolu MQTT probíhá výměna zpráv mezi klientem (client), který může být publisher (poskytovatelem zpráv) nebo subscriber (příjemcem zpráv), a brokerem zpráv (např. Mosquitto MQTT).
Publisher odesílá data na centrální bod – brokeru (MQTT Broker), ukazuje ve zprávě určité téma (topic). Subscribeři mohou přijímat různá data od více publisherů v závislosti na předplatném odpovídajících témat.
Zařízení MQTT používají určité typy zpráv ke komunikaci s brokerem, níže jsou uvedeny základní:
- Connect – navázat spojení s brokerem
- Disconnect – přerušit spojení s brokerem
- Publish – publikovat zprávu do tématu
- Subscribe – přihlášení k odběru tématu
- Unsubscribe – odhlášení od odběru tématu
Schéma jednoduché komunikace mezi Subscriberem, Publisherem a Brokerem.
Sémantika témat
Témata jsou znaky s kódováním UTF-8. Hierarchie témat má stromovou podobu, což usnadňuje jejich organizaci a přístup k datům. Témata se skládají z jedné nebo více úrovní, které jsou odděleny lomítkem („/“).
Příklad tématu, ve kterém snímač teploty umístěný v ložnici publikuje data brokeru.
/home/living-space/living-room1/temperature
Subscriber může také přijímat data z několika témat současně. Pro tyto účely existují zástupné znaky (# a +). Existují dva typy zástupných znaků: jednoúrovňové a víceúrovňové. Abychom jim lépe porozuměli, podívejme se na příklady každého z nich:
- Jednoúrovňový zástupný znak. K označení se používá znak «+».
Např. potřebujeme získat data o teplotě ve všech ložnicích:
/home/living-space/+/temperature
Výsledkem je, že dostáváme data z témat:
/home/living-space/living-room1/temperature
/home/living-space/living-room2/temperature
/home/living-space/living-room3/temperature
- Víceúrovňový zástupný znak. K označení se používá znak «#».
Např. musíme získat data z různých snímačů ve všech ložnicích v domě:
/home/living-space/#
Výsledkem je, že dostáváme data z témat:
/home/living-space/living-room1/temperature
/home/living-space/living-room1/light1
/home/living-space/living-room1/light2
/home/living-space/living-room1/humidity
/home/living-space/living-room2/temperature
/home/living-space/living-room2/light1
…
Struktura zpráv
Zpráva MQTT se skládá z několika částí:
- Fixní hlavička (přítomná ve všech zprávách)
- Variabilní hlavička (přítomná pouze v určitých zprávách)
- Data, "náklad" (přítomné pouze v určitých zprávách)
Fixní hlavička
Typ zprávy – například: CONNECT, SUBSCRIBE, PUBLISH atd.
Příznaky specifické pro každý MQTT „paket“ – tyto 4 bity se používají pro pomocné příznaky, jejichž přítomnost a stav závisí na typu zprávy.
Remaining Length (zbývající délka) – představuje aktuální délku zprávy (variabilní hlavička + data), velikost je od 1 do 4 bajtů.
Celkem v protokolu MQTT 15 typů zpráv:
Typ zprávy | Hodnota | Směr přenosu | Popis |
---|---|---|---|
Reserved | 0000 (0) | Rezervováno | |
CONNECT | 0001 (1) | C* -> S** | Žádost klienta o připojení k serveru |
CONNACK | 0010 (2) | C | Potvrzení připojení |
PUBLISH | 0011 (3) | C S | Publikace zprávy |
PUBACK | 0100 (4) | C S | Potvrzení publikace |
PUBREC | 0101 (5) | C S | Publikace přijata |
PUBREL | 0110 (6) | C S | Povolení k odstranění zprávy |
PUBCOMP | 0111 (7) | C S | Dokončení publikace |
SUBSCRIBE | 1000 (8) | C -> S | Žádost o odběr |
SUBACK | 1001 (9) | C | Potvzení k odběru |
UNSUBSCRIBE | 1010 (10) | C -> S | Žádost o odhlášení |
UNSUBACK | 1011 (11) | C | Potvrzení odhlášení |
PINGREQ | 1100 (12) | C -> S | Žádost o PING |
PINGRESP | 1101 (13) | C | Odezva PING |
DISCONNECT | 1110 (14) | C -> S | Odpojení od serveru |
Reserved | 1111 (15) | Rezervováno |
*C – Client, **S – Server
Příznaky
První 4 nejvýznamnější bity fixního záhlaví se používají jako specifické příznaky:
DUP – duplikát je nastaven, když klient nebo broker MQTT provede opětovné odeslání paketu (používá se v PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL).
QoS – kvalita služeb (0,1,2).
RETAIN – při publikování dat s nastaveným příznakem Retain, broker to uloží. Při dalším odběru na toto téma, broker okamžitě odešle zprávu s tímto příznakem. Používá se pouze ve zprávách typu PUBLISH.
Variabilní hlavička
Variabilní hlavička je obsažena v některých záhlavích.
Obsahuje následující údaje:
- Packet identifier – identifikátor paketu přítomný ve všech typech zpráv, kromě: CONNECT, CONNACK, PUBLISH (QoS<1), PINGREQ, PINGRESP, DISCONNECT.
- Protocol name – název protokolu (pouze ve zprávách typu CONNECT).
- Protocol version – verze protokolu (pouze ve zprávách typu CONNECT).
- Connect flags – příznaky, které určují chování klienta během připojení.
User name – pokud je tento příznak v " nákladu", musí být uvedeno uživatelské jméno (používá se pro autentifikaci klienta).
Password – pokud je tento příznak v "nákladu", musí být zadáno heslo (používá se pro autentifikaci klienta).
Will Retain – pokud je příznak nastaven na 1, broker udržuje Will Message.
Will QoS – kvalita služeb pro Will Message, pokud je nastaven příznak Will Flag, jsou Will QoS a Will Retain povinné.
Will Flag – pokud je nastaven příznak, poté, co se klient odpojí od brokera bez odeslání příkazu DISCONNECT (v případě nepředvídatelného přerušení komunikace atd.), broker oznámí to všem připojeném klientům prostřednictvím tzv. Will Message.
Clean Session – zničit relaci. Pokud je příznak nastaven na «0», broker relaci uloží, všechny odběry klienta, a při příštím připojení předá mu všechny zprávy z QoS1 a QoS2, které byly přijaty brokerem během odpojení klienta. Pokud je tedy příznak nastaven na «1», při opětovném připojení se klient bude muset znovu přihlásit k odběru témat.
- Session Present – používá se ve zprávě typu CONNACK. Pokud broker přijímá spojení s Clean Session =1, musí Session Present (SP) nastavit na «0». Pokud broker přijímá spojení s Clean Session =0, pak hodnota bitu SP závisí na tom, zda broker dříve uložil relaci s tímto klientem (pokud ano, pak je SP nastaveno na 1 a naopak). To znamená, že tento parametr umožňuje klientovi určit, zda byla předchozí relace uložena brokerem.
- Connect Return code – pokud broker z nějakého důvodu nemůže od klienta přijmout správně vytvořený CONNECT paket od klienta, pak ve druhém bajtu CONNACK paketu musí nastavit odpovídající hodnotu z níže uvedené tabulky:
Hodnota |
Návratový kód |
Popis |
0 |
0x00 Connection Accepted |
Připojení přijato |
1 |
0x01 Connection Refused, unacceptable protocol version |
Broker nepodporuje verzi protokolu klienta |
2 |
0x02 Connection Refused, identifier rejected |
Client ID připojeného klienta není v seznamu povolených |
3 |
0x03 Connection Refused, Server unavailable |
Připojení je navázáno, ale služba MQTT není k dispozici |
4 |
0x04 Connection Refused, bad user name or password |
Nesprávné přihlašovací jméno nebo heslo |
5 |
0x05 Connection Refused, not authorized |
Přístup k připojení je zakázán |
6-255 |
|
Rezervováno |
- Topic Name – Název tématu
Data, náklad
Obsah a formát dat přenášených ve zprávách MQTT jsou definovány v aplikaci. Velikost dat lze vypočítat odečtením od Remaining Length délky variabilní hlavičky.
Kvalita služeb v protokolu MQTT (QoS)
MQTT podporuje tři úrovně kvality služeb (QoS) při přenosu zpráv.
QoS 0 At most once. Na této úrovni publisher posílá brokeru zprávu jenom jednou a nečeká na žádnou odpověď, tj. odešle a zapomene.
QoS 1 At least once. Tato úroveň zajišťuje, že zpráva bude přesně doručena brokeru, ale existuje možnost duplicitních zpráv od publishera. Po obdržení duplicitní zprávy broker znovu odešle tuto zprávu subscriberům, a odešle potvrzení o přijetí zprávy publisheru. Pokud publisher neobdržel PUBACK zprávy od brokera, pokusí se znovu odeslat tento paket, v tomto případě je DUP nastaven na "1".
QoS 2 Exactly once. Na této úrovni je zaručeno doručení zpráv klientovi a je vyloučeno možné duplikování odeslaných zpráv.
Publisher posílá zprávu brokeru. Tato zpráva obsahuje jedinečný Packet ID, QoS=2 a DUP=0. Publisher ukládá zprávu bez potvrzení, dokud neobdrží odpověď PUBREC od brokera. Broker odpoví zprávou PUBREC obsahující stejný Packet ID. Po obdržení této zprávy publisher odesílá PUBREL se stejným Packet ID. Broker musí si nechat kopii zprávy, než obdrží PUBREL. Jakmile broker obdrží PUBREL, odstraní kopii zprávy a odešle publisherovi zprávu PUBCOMP o dokončení transakci.
Ochrana přenosu dat
Pro zajištění bezpečnosti jsou v protokolu MQTT uskutečněný následující metody ochrany:
- Autentifikace klienta. Paket CONNECT může obsahovat pole USERNAME a PASSWORD. Při realizaci brokera je možné tato pole použít k autentifikace klienta.
- Kontrola přístupu klienta pomocí Client ID.
- Připojení k brokeru prostřednictvím TLS/SSL.