V monitorovacích systémech je nutné sdílení naměřených dat, abychom mohli reagovat na rychlé změny v dané aplikaci. Na trhu je mnoho monitorovacích jednotek, které umožňují měřit jakékoli fyzikální veličiny. Když potřebujeme naměřené hodnoty sdílet s ostatními zařízeními nebo systémy třetích stran, potřebujeme univerzální protokol, například MQTT. Ten v poslední době integruje většina výrobců pokročilých IoT zařízení i aplikací, protože si uvědomují jeho silné stránky. Výhody si ukážeme na zařízení Poseidon2/Damocles2 a také na Raspberry Pi.

Rodina Poseidon2 - umožňuje nejen měřit teplotu, vlhkost, intenzitu světla, ale umožňuje detekci zaplavení či nepřítomnost vody, měření proudění vzduchu (průvanu) a další. Dokáže posílat informační emaily, odesílat naměřené hodnoty do počítače nebo na speciální internetový server SensDesk, kde jsou data zobrazeny v přehledných grafech a tím přístupná z libovolného počítače, tabletu či mobilního telefonu přes internet (např. WiFi internet).

Rodina Damocles2 disponuje mnoha digitálními vstupy (například verze 2404 má 24 vstupů) pro připojení bezpotenciálových detektorů. Všechny DI vstupy jsou vybaveny čítačem S0 pulzů s pamětí pro připojení měřičů (např. vodoměr, plynoměr, elektroměr atd.). Digitální vstupy mohou monitorovat otevření/zavření dveří nebo oken. Taková otevřená dvířka v mrazícím boxu dokáží napáchat nemalé problémy. Pokud použijme výstup z detektoru pohybu, získáme navíc bezpečnostní systém, který nás upozorní na nezvané návštěvníky. Zabudovaný čítač impulsů pomůže získat přehled o celkové spotřebě energií monitorovaného objektu.

Obě rodiny umožňují sdílení svých naměřených hodnot pomocí protokolu MQTT. Kompatibilita s MQTT umožňuje připojení do IoT Hub, MS Azure, AWS IoT, Bluemix Internet of Things a dalších cloudových služeb nebo do zařízení, systémů 3.stran.

MQTT: základní myšlenka

V IoT systémech by snímače neměly určovat, co kdo má udělat. Snímače jsou od toho, aby výsledky své práce posílali do centrálního místa, a tím mají splněno. O víc se nestarají. Ti, kteří tyto zprávy potřebují se přihlásí k jejich odběru a po vyhodnocení na ně nějakým způsobem reagují. Může se přidat další vrstva, kde například relé reaguje na pokyny vypni/zapni. Vypínač informuje o tom, že byl stisknut nebo snímač teploty informuje o tom, kolik teploty naměřil a centrální místo tyto informace rozešle příslušným odběratelům. Tím lze jednoduše reagovat na změnu požadavků dané aplikace a doplnit různé funkce, jako například sepnutí relé se zpožděním nebo přemapování fyzických zařízení tak, aby logicky fungovaly lépe.

Historie MQTT

Na počátku se vymýšlelo, který protokol použít pro komunikaci a bylo zvolen zcela jednomyslně protokol HTTP. Všichni ho znají a je rozšířen do celého světa. Postupem času se ukázalo, že HTTP má pro využití v internetu věcí mnoho nevýhod. Komunikace je hodně upovídaná a jeho implementace není jednoduchá. HTTP protokol je založen na principu „dotaz-odpověď “. Takže pro komunikaci typu „server posílá “ je potřeba řešit různé finty typu long polling, heartbeat, použít HTTP/2 apod. Nemá vyřešené různé úrovně QoS a pro dvě zařízení s protokolem HTTP je vždy nutné mít nějakou serverovou aplikaci, která jim umožní vzájemnou komunikaci, protože samotný HTTP server nedokáže sám data předávat mezi klienty.  Proto vznikla jeho binární podoba CoAP, která zjednoduší implementaci v MCU. Sníží množství přenášených dat, protože textové hlavičky byli nahrazeny binárními příznaky. S volitelnými doplňky ale CoAP opět nabobtnala, čímž hlavní výhoda zmizela.

Proto vznikl protkol MQTT (dříve: Message Queuing Telemetry Transport, dnes MQ Telemetry Transport), který je jednoduchý a nenáročný pro předávání zpráv mezi klienty prostřednictvím centrálního bodu – brokeru. Díky této nenáročnosti a jednoduchosti je snadno implementovatelný i do zařízení s „malými“ procesory a poměrně rychle se rozšířil. Navržen byl v IBM, dnes za ním stojí Eclipse foundation a před nedávnem proběhla standardizace OASIS.

MQTT je ve svém principu založen na předávání zpráv mezi klienty prostřednictvím centrálního serveru – MQTT brokeru, který se stará o výměnu zpráv. Přenos zpráv probíhá pomocí TCP a používá strukturu Publisher – Subscribers. Zprávy jsou tříděny do tzv. témat (topic) a zařízení buď publikuje v daném tématu (publish), to znamená, že posílá data do MQTT brokeru nebo je přihlášeno k odběru daných témat (subscribe).

Teoreticky každý klient může být současně publisher i subscriber, ale dost často bývají tyto funkce rozděleny. Publisher obvykle reprezentuje nějaký snímač či měřící jednotku, která vysílá naměřeného hodnoty na MQTT broker, zatímco subscriber obvykle tvoří nějaká řídící jednotka, která hodnoty odebírá (přijímá) a dále s nimi pracuje nebo je zobrazuje.

Obsah zprávy

Samotný obsah zpráv není nijak definovaný. Jsou jím prostě nějaká binární data, která mají být přenesena. Nejčastěji se používá formát (způsob zápisu) dat JSON (JavaScript Object Notation), BSON (Binary JSON) nebo textové zprávy. Ale v zásadě to mohou být data libovolného formátu, protože MQTT broker tyto data nijak nezpracovává, jen je přeposílá. Záleží tak čistě jen na příjemci dat (subscriberu), aby je "pochopil". Velikost zprávy je v aktuální verzi protokolu omezena na necelých 256 MB, ale vzhledem k zaměření na "Internet of Things" bývá většina zpráv mnohem menší.  MQTT minimalizuje množství přenášených dat, což byl od začátku cíl. Přidává jen minimum servisních dat.  Proto se velmi hodí pro přenos jen občasných, na rychlost přenosu méně náročných informací a hodnot, což je právě ideální pro účel IoT.

Přenosový model

Protokol MQTT sám o sobě popisuje jen samotný popis struktury přenášených zpráv, ale nedefinuje způsob přenosu. K tomu využívá běžný TCP/IP protokol, tedy prakticky využívá běžnou lokální LAN ethernetovou i globální WAN internetovou síť. MQTT protokol tvoří tak pouze tzv. aplikační vrstvu OSI modelu. Protože MQTT protokol má velmi jednoduchou strukturu a využívá běžné ethernetové komunikační rozhraní, je snadno implementovatelný i do zařízení s „malými“ procesory a rychle se rozšiřuje. Ze stejného důvodu se začíná i rychle implementovat a rozšiřovat v průmyslu, protože implementace MQTT do firmwaru PLC, které již obsahují TCP/IP rozhraní (Ethernet s RJ-45 konektorem), je poměrně jednoduchá a není nutné nijak modifikovat hardware CPU jednotky.

V souvislosti se samotným přenosem zpráv pak MQTT protokol definuje tři úrovně potvrzování zpráv QoS (Quality of Service):

• Nejnižší "QoS 0" znamená, že zpráva je odeslána bez potvrzení a není zaručeno její doručení (at-most-once).
• Prostřední úroveň "QoS 1" říká, že zpráva je doručena alespoň jednou (at least once).
• Nejvyšší úroveň "QoS 2" znamená, že každá zpráva je doručena právě jednou (exactly once).

Klient však nemusí podporovat všechny tři uvedené úrovně QoS, protože samotný MQTT protokol to nepožaduje. 

Bezpečnost

Protokol MQTT sám o sobě žádné zabezpečení nevynucuje ani nevyžaduje, stejně jako u ostatní IP komunikace. Je jen na každém klientovi nebo správci zařízeních, zda využijí nějaké šifrování či ne. Pozornost je tak potřeba věnovat veřejně dostupným brokerům a aplikacím, zejména z podezřelých nebo neznámých zdrojů. Pokud data svěříme veřejnému brokeru, neexistuje žádná účinná kontrola nad tím, kolik dalších brokerů se k nim třeba i dočasně připojuje.

V uzavřených sítích nebo IT systémech, je bezpečnost řádně ošetřena. Pro zabezpečení přenášeného obsahu dává MQTT na výběr několik možností. Každá komunikace mezi klientem a brokerem začíná přihlášením klienta (režim "CONNECT"). V přihlašovací sekvenci se využívá identifikace každého klienta pomocí "ClientID" a pak volitelně i pomocí uživatelského jména "Username" a hesla "Password". Pokud nám to dovolují možnosti klienta, je vhodné nastavit "ClientID" jako jednoduchý řetězec, který jej co nejlépe identifikuje a přispívá k lepší orientaci v síti.

MQTT díky podpoře SSL/TLS umožňuje přihlášení pomocí klientského SSL certifikátu. Podporovány jsou protokoly TLS v1.2, v1.1 nebo v1.0 s x509 certifikáty. Je důležité si uvědomit, že protokol MQTT je čistě textový, a proto bez použití SSL/TLS bude komunikace zcela nešifrovaná (nebezpečí se týká hlavně přenášeného hesla).

Podle požadované úrovně šifrování komunikace pak MQTT protokol předepisuje následující TCP kanály:

• 1883 = MQTT nešifrovaný přenos (unencrypted) - základní a nejběžnější MQTT komunikační kanál, kde komunikace je zcela nešifrovaná (nebezpečí se týká hlavně přenášeného hesla). Po tomto kanálu by tak neměla zasílat žádná citlivá data.
• 8883 = MQTT šifrovaný přenos (encrypted) - narozdíl od kanálu 1883 jsou data zde šifrována SSL/TLS protokolem a navázání komunikace tak vyžaduje podporu klienta.
• 8884 = MQTT šifrovaný přenos (encrypted) + certifikát klienta (client certificate) - toto je speciální a nejvyšší úroveň zajištění MQTT komunikace, protože nejen, že jsou data opět šifrována protokolem SSL/TLS, ale klient musí poskytnout i certifikát o autenticitě vydávaný brokerem. Tento kanál však zatím podporuje jen málo veřejných brokerů (např. Mosquitto - server "test.mosquitto.org").

Nastavení MQTT jednoduše

Zařízení Poseidon2 a Damocles2 mají tento protokol již implementovaný a jeho nastavení nevyžaduje žádné programátorské zkušenosti. Stačí jen zapnout podporu MQTT protokolu v zařízení, nastavit IP adresu MQTT brokeru, jméno, heslo a vybrat příslušné připojené senzory, které chceme, aby publikovali do daného MQTT brokeru. Z předešlého popisu již víme, že je nutné vybrat topic, ve kterém budeme publikovat, a ze kterého pak můžeme na druhé straně odebírat tyto zprávy. Pro výběr MQTT brokeru můžeme zvolit z https://github.com/mqtt/mqtt.github.io/wiki/public_brokers. Komunikaci lze jedním kliknutím zabezpečit pomocí SSL.

Sdílení dat s ostatními zařízeními a systémy

Jak již bylo napsáno, díky MQTT lze data posílat do IoT Hub, MS Azure, AWS IoT, Bluemix Internet of Things a dalších cloudových uložišť. Nastavení zvládne i laik a jeho popis naleznete na adrese https://www.hw-group.com/cs/podpora/pouziti-jednotek-poseidon2-a-damocles2-s-ms-azure.  

MQTT zajisti i interoperabilitu jinak zcela odlišných zařízení. Protokol MQTT je tak masivně rozšířen, že existuje mnoho knihoven, které usnadňují implementaci do procesorů. Například Digikey nabízí návod jak MQTT implementovat do Raspberry PI 3 s ESP8266. Kombinací produktů HW Group s Raspberry získáte efektivní systém, kde Poseidon2 a Damocles2 se postarají o přenos dat ze senzorů do brokeru a Raspberry si tyto hodnoty přečte, vyhodnotí a provede příslušnou akci.  Tím získáte profesionální řešení na straně měření a můžete se věnovat jen aplikační části.

Detailní informace o produktech: https://www.hw-group.com/devices/monitoring 
Poseidon2 a Damocles 2 na obchod.hw.cz: http://obchod.hw.cz/eshop/produkty/kategorie/monitoring-prostredi?brand=4-hw-group-s-r-o

Pro více informací nebo řešení pro vaši aplikaci kontaktujte p. Petra Burdu, email: burda@hw.cz, mobil: 607 090 474.

Zdroje informací:

• Webové stránky MQTT protokolu s kompletním jeho popisem v angličtině: http://mqtt.org/
• Vývoj MQTT v čase: https://www.ibm.com/
• Popis MQTT protokolu na stránkách internetového brokera http://www.hivemq.com
• Článek o MQTT na serveru Root.cz: https://www.root.cz/clanky/protokol-mqtt-komunikacni-standard-pro-iot/
• Informace o MQTT v Raspberry: https://www.digikey.com/en/maker/blogs/2019/how-to-use-mqtt-with-the-raspberry-pi
• Detailní informace o protokolu MQTT: https://www.element14.com/community/docs/DOC-89715/l/tech-spotlight-the-mqtt-protoco
• Informace o produktech HW Group: https://www.hw-group.com