MQTT – univerzális protokoll felhő- és IoT-alkalmazásokhoz

A monitorozó rendszerekben a mért adatokat meg kell osztani, hogy gyorsan lehessen reagálni a változásokra. Számos monitorozó egység van a piacon, amely bármilyen fizikai mennyiséget képes mérni. Olyan univerzális protokollra, mint az MQTT, akkor van szükség, ha a mért értékeket meg kell osztani más eszközökkel vagy harmadik féltől származó rendszerekkel. Az MQTT-t különösen erősségeinek köszönhetően ma a fejlett IoT-eszközök és -alkalmazások legtöbb gyártója integrálja. Az előnyek bemutatására vegyük példának a Poseidon2/Damocles2 eszközöket és egy Raspberry Pi-t.

Poseidon2 család – a hőmérséklet, a páratartalom vagy a fényerősség mérése mellett ezek az eszközök árvízet vagy a víz hiányát is észlelik, mérik a légáramlást és egyébet. E-mail értesítéseket tudnak küldeni, és a mért értékeket feltölthetik egy számítógépre vagy a dedikált SensDesk portálra, ahol az adatok könnyen érthető grafikonokon jelennek meg, amelyek az interneten keresztül bármely számítógépről, táblagépről vagy mobiltelefonról elérhetők.

Damocles2 család eszközei sok digitális bemenetet biztosítanak szárazkontaktusok csatlakoztatásához (pl. 24 bemenet a 2404-es modellen). Minden digitális bemenet memóriával rendelkező S0 impulzusszámlálóval rendelkezik víz-, gáz-, villany- vagy más mérők csatlakoztatásához. A digitális bemenetek ajtók vagy ablakok nyitását/zárását is figyelhetik. Például egy kissé nyitva maradt fagyasztóajtó sok problémát okozhat. Mozgásérzékelővel kombinálva a rendszer a nem kívánt látogatókra is riaszthat. A beépített impulzusszámlálók segítenek áttekintést adni a figyelt helyszín teljes energiafogyasztásáról.

Mindkét termékcsalád az MQTT-n keresztül képes megosztani a mért értékeket. Az MQTT-kompatibilitás lehetővé teszi a csatlakozást az IoT Hubhoz, az MS Azure-hoz, az AWS IoT-hoz, a Bluemix Internet of Thingshez és más felhőszolgáltatásokhoz, valamint harmadik féltől származó rendszerekhez.

MQTT: az alapötlet

Az IoT-rendszerekben a szenzorok nem döntenek arról, mit tegyenek. A szenzorok egyszerűen elküldik munkájuk eredményét egy központi helyre, és semmi többet. Aki szükségesnek tartja ezeket az üzeneteket, feliratkozik rájuk, feldolgozhatja és reagálhat. Például hozzáadható egy második réteg, ahol egy relé a be-/kikapcsolási kérésekre reagál. Egy kapcsoló jelezheti, hogy átkapcsolták, egy hőmérséklet-szenzor tájékoztathat a mért hőmérsékletről, a központi hely pedig mindezt továbbítja az érintett feliratkozóknak. Így könnyen reagálhatunk a változó alkalmazási igényekre, és új funkciókat adhatunk hozzá, például egy relé késleltetéssel történő kapcsolását, vagy a fizikai eszközök logikusabb működésű átképezését.

Az MQTT története

Kezdetben, amikor a kommunikációhoz használandó protokollra gondoltak, a HTTP egyhangú választás volt. Mindenki ismeri, és világszerte elterjedt. Hamar kiderült azonban, hogy a HTTP-nek sok hátránya van a dolgok internetehez. Sok a kommunikáció, a megvalósítás pedig bonyolult. Ráadásul a HTTP-protokoll a „kérés–válasz” paradigmán alapul, ezért a szerver által kezdeményezett kommunikációhoz különféle kerülőmegoldásokra (long polling, heartbeat, HTTP/2 stb.) van szükség. Nincsenek QoS-szintek, és két HTTP-eszköznek mindig szerveralkalmazásra van szüksége a kölcsönös kommunikációhoz, mert egy HTTP-szerver önmagában nem tud adatot átadni a kliensek között. Ezért fejlesztették ki a bináris változatot, a CoAP-ot, hogy egyszerűsítse a megvalósítást mikrokontrollereken. A szöveges fejlécek bináris jelzőkre cserélésével csökkentette az adatmennyiséget. Az opcionális kiterjesztésekkel azonban a CoAP is felduzzadt, és elvesztette fő előnyét.

Ezen okokból jött létre az MQTT-protokoll (korábban: Message Queuing Telemetry Transport, ma: MQ Telemetry Transport). Egyszerű és könnyű protokoll üzenetek továbbítására kliensek között egy központi ponton – a brókeren (közvetítőn) – keresztül. Ezeknek a jellemzőknek köszönhetően egyszerű mikrokontrolleres eszközökben is könnyen megvalósítható, és gyorsan népszerűvé vált. Az IBM tervezte, jelenleg az Eclipse Foundation gondozza. Újabban OASIS-szabvánnyá vált.

Alapelve szerint az MQTT az üzenetek cseréjén alapul a kliensek között egy központi szerveren – az MQTT-brókeren – keresztül. Az üzeneteket TCP-n keresztül továbbítják Publisher – Subscribers (közzétevő – feliratkozók) szerkezetben. Az üzenetek „témákra” (topic) vannak osztva; az eszköz vagy „közzétesz” egy adott témát, vagyis adatot küld az MQTT-brókernek, vagy „feliratkozik” a témára az adatok fogadásához.

Elméletben egy kliens egyszerre lehet közzétevő és feliratkozó is, ezeket a funkciókat általában szétválasztják. A közzétevő általában egy szenzor vagy mérőeszköz, amely a mért értékeket az MQTT-brókernek küldi, a feliratkozó pedig általában egy vezérlőegység, amely a további feldolgozáshoz vagy megjelenítéshez fogadja (feliratkozik) az értékeket.

Az üzenet tartalma

Az üzenet tartalma semmilyen módon nincs meghatározva. Egyszerűen tetszőleges bináris adat, amelyet tovább kell adni. A leggyakoribb adatformátumok a JSON (JavaScript Object Notation), a BSON (Binary JSON) vagy az egyszerű szöveg. A formátum azonban semmilyen módon nem korlátozott, mivel az MQTT nem dolgozza fel az adatokat, csak továbbítja őket. Kizárólag a feliratkozón múlik, hogy „értse” az adatokat. A jelenlegi protokollverzióban az üzenet mérete valamivel 256 MB alá esik; a „dolgok internetére” összpontosítás miatt azonban a legtöbb üzenet jóval rövidebb. Az MQTT egyik célja az adatmennyiség minimalizálása. A többletadat minimális. Az MQTT ezért alkalmas információk és értékek alkalmi átvitelére, ahol az átviteli sebesség nem kritikus – IoT-célokra ideális.

Adatátviteli modell

Az MQTT-protokoll önmagában csak az üzenet szerkezetét határozza meg, az adatátviteli módot nem. Erre a célra a szokásos TCP/IP-protokollt használja szokásos Ethernet LAN-on vagy interneten keresztül. Az MQTT az OSI-modell alkalmazási rétegében van. Az egyszerű szerkezetnek és a szokásos Ethernet interfész használatának köszönhetően az MQTT könnyen megvalósítható kis teljesítményű, kis számítási kapacitású processzorokat tartalmazó eszközökben, és gyorsan elterjed. Ugyanezen okokból gyorsan népszerűvé válik az iparban is; az MQTT viszonylag könnyen megvalósítható a TCP/IP interfésszel (Ethernet és RJ-45 csatlakozó) már rendelkező PLC-kben a CPU-egység hardverének bármilyen módosítása nélkül.

Az üzenetátvitelhez az MQTT az üzenet visszaigazolásának három QoS (szolgáltatásminőségi) szintjét határozza meg:

• A legalacsonyabb „QoS 0” szint azt jelenti, hogy az üzenet visszaigazolás nélkül kerül elküldésre, és a kézbesítés nem garantált (legfeljebb egyszer).
• A középső „QoS 1” szint azt jelenti, hogy az üzenet legalább egyszer kézbesítésre kerül.
• A legmagasabb „QoS 2” szint azt jelenti, hogy minden üzenet pontosan egyszer kerül kézbesítésre.

Egy kliensnek azonban nem kell mindhárom QoS-szintet támogatnia; az MQTT-protokoll ezt nem írja elő.

Biztonság

Az MQTT-protokoll önmagában nem kényszerít ki és nem követel meg semmilyen biztonságot. A kliensen vagy az eszköz kezelőjén múlik, hogy megvalósít-e titkosítást. Ezért tanácsos óvatosnak lenni a nyilvános brókerekkel és alkalmazásokkal, különösen gyanús vagy ismeretlen forrásból. Ha az adatokhoz nyilvános brókert használnak, nincs érdemi ellenőrzés más brókerek felett, amelyek akár átmenetileg is csatlakozhatnak hozzá.

A biztonságot általában zárt hálózatokban vagy IT-rendszerekben biztosítják. Az átvitt tartalom védelmére az MQTT több lehetőséget kínál. A kliens és a bróker közötti minden kommunikáció a kliens bejelentkezésével kezdődik („CONNECT” mód). A bejelentkezési folyamatban a klienst a „ClientID”-je azonosítja, opcionálisan pedig a „Username” (felhasználónév) és a „Password” (jelszó). Ha a kliens képességei megengedik, célszerű a „ClientID”-t olyan egyszerű karakterláncra állítani, amely jól azonosítja az eszközt, és segít átlátni a hálózatot.

Az SSL/TLS támogatásnak köszönhetően az MQTT támogatja a bejelentkezést kliens SSL-tanúsítvánnyal. A támogatott protokollok közé tartozik a TLS v1.2, v1.1 vagy v1.0 x509-tanúsítványokkal. Fontos szem előtt tartani, hogy az MQTT-protokoll tisztán szövegalapú; SSL/TLS nélkül a kommunikáció teljesen nyílt (és a jelszó a fő gond).

A kívánt biztonsági szinttől függően az MQTT-protokoll a következő TCP-csatornákat írja elő:

• 1883 = titkosítatlan MQTT – az alapvető és leggyakoribb MQTT-kommunikációs csatorna; a kommunikáció semmilyen módon nincs titkosítva (a jelszót is beleértve, amelyet nyíltan küldenek). Ez a csatorna nem használható érzékeny adatokhoz.
• 8883 = titkosított MQTT – az 1883-as csatornával ellentétben az adatok SSL/TLS-protokollal vannak titkosítva, és a kapcsolat létrehozásához kliensoldali támogatás szükséges.
• 8884 = titkosított MQTT + kliens-tanúsítvány – ez az MQTT-kommunikációhoz elérhető legmagasabb biztonsági szint; az adatok SSL/TLS-protokollal való titkosítása mellett a kliensnek a bróker által kiállított tanúsítvánnyal is hitelesítenie kell magát. Ezt a csatornát azonban eddig csak néhány nyilvános bróker támogatja (pl. a Mosquitto – „test.mosquitto.org” szerver).

Egyszerű MQTT-beállítás

A Poseidon2 és a Damocles2 eszközökben (külső link) ez a protokoll már megvalósítva van, a beállításhoz nem kell programozási tapasztalat. Egyszerűen engedélyezze az MQTT-támogatást az eszközben, adja meg az MQTT-bróker IP-címét, felhasználónevét és jelszavát, és válassza ki, mely csatlakoztatott szenzorok adatait tegye közzé az MQTT-brókeren. Az előző leírásból világos, hogy ki kell választani a közzétételi (és a másik oldalon a feliratkozási) témát (topic). Az MQTT-bróker ebből a listából választható: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers (külső link). Egyetlen kattintással a kommunikáció SSL-lel védhető.

MQTT engedélyezése

– Engedélyezi vagy letiltja az MQTT-támogatást a Poseidon2 és a Damocles2 eszközökben.

Szerver (Server)

– Az MQTT-bróker (szerver) IP-címe vagy tartományneve.

Port

– A TCP-port, amelyen a bróker figyel.

Felhasználónév (Username)

– Felhasználónév a TCP-kommunikáció hitelesítéséhez.

Jelszó (Password)

– Jelszó a TCP-kommunikáció hitelesítéséhez.

Biztonságos SSL-mód (Secure SSL mode)

– Engedélyezi/letiltja az SSL-módot.

Kliensazonosító (Client ID)

– A kliens azonosítója az MQTT-ben való használatra.

Közzétételi időszak (Publish Period)

– A mért adatok továbbításának időszaka.

Témaelőtag (Topic Prefix Name)

– A téma előtagja. A teljes téma az előtag és az alábbi téma összefűzésével jön létre.

Közzététel (Publish)

– A küldendő információk kiválasztása.

Felhasználói téma (User Topic)

használható olyan felhasználói téma (üzenet) létrehozására, amely az egyedi alkalmazáshoz szükséges adatokat tartalmazza (JSON, XML, CSV stb.). Erre makróparancsokat használnak – lásd ezt a

cikket

.

Adatmegosztás más eszközökkel és rendszerekkel

Az MQTT az IoT Hubra, az MS Azure-ra, az AWS IoT-ra, a Bluemix Internet of Thingsre és más felhőkbe képes adatot küldeni. A beállítás nagyon egyszerű, a leírást lásd ebben a cikkben.

Az MQTT biztosítja a különben nagyon eltérő eszközök együttműködését. Az MQTT népszerűségének köszönhetően számos programkönyvtár áll rendelkezésre a különféle processzorokon való megvalósítás megkönnyítésére. A Digikey például útmutatót kínál arról, hogyan valósítható meg az MQTT Raspberry Pi 3-on ESP8266-tal. A HW group termékeinek és a Raspberry Pi-nek a kombinációja hatékony rendszer, ahol a Poseidon2 és a Damocles2 gondoskodik a szenzoradatok brókernek való elküldéséről, a Raspberry Pi pedig beolvassa, feldolgozza az értékeket, és cselekszik rájuk. Az eredmény egy professzionális alkalmazás a mérési oldalon, az ügyfél pedig az alkalmazási részre koncentrálhat.

Letölthető fájlok