info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
22.11.2024
MQTT v praxi
Protokol MQTT je zaujímavý z viacerých pohľadov. Je pomerne jednoduchý na implementáciu a nenáročný na zdroje PLC – v porovnaní s inými ako napr. OPC UA.
Na rozdiel od väčšiny iných protokolov nie je to protokol typu klient – server, ale client – broker. V tomto prípade sú PLC aj SCADA klienti centrálneho servera nazývaného broker, ktorého úlohou je výmena správ medzi klientami a ďalšie pomocné funkcie (autentifikácia, nastavenie prístupových práv, logovanie).
Takíto konfigurácia má pre PLC ďalšie výhody. Po prvé, PLC nie je zaťažované viacerými paralelnými komunikáciami – všetky dáta sú poslané brokerovi iba raz, ten ich následne sprostredkuje záujemcom. Po druhé všetky mená a heslá (alebo certifikáty) sú spravované centrálne brokerom.
MQTT klient používa na reportovanie dát princíp „report by exception“, čo je v podstate zmenový princíp používaný aj v iných protokoloch (IEC-101, IEC-104, OPC, OPC UA). Toto znamená ďalšie šetrenie zdrojmi PLC v porovnaní so štandardným pollingom používaným napr. Modbus protokolom.
MQTT v D2000
Protokol MQTT bol implementovaný v D2000 v roku 2017 ako vedľajší produkt pri implementácii protokolu LoRaWAN. Zariadenia používajúce úsporný protokol LoRaWAN komunikovali buď priamo s IoT gatewayom, alebo s infraštruktúrou cloudov (loriot.io, loralink.slovanet.sk alebo TheThings.Network), odkiaľ ich D2000 KOM proces čítal s použitím MQTT protokolu.
Nasadenie
Pred pár dňami sa mi naskytla možnosť konfigurovať MQTT komunikáciu. Na druhej strane bol batériový systém PowerShaper od firmy PIXII, ktorý obsahuje MQTT server (broker).
Komunikácia používa TLS šifrovanie – od firmy PIXII sme dostali aj certifikát servera (súbor pixii.crt) a klientský verejný kľúč (mqtt_client.crt) a súkromný kľúč (mqtt_client.key), ktorý sme mali pri komunikácii použiť.
V prvom rade bolo nutné riešiť firewally. Pri skúšaní komunikácie bol MQTT server pomocou prekladu adries (NAT) „vystrčený“ do Internetu na statickej verejnej IP adrese, na štandardnom TCP porte 8883, ktorý je rezervovaný pre kryptovaný MQTT. Takže sme poprosili našeho sieťara, aby nám povolil prístup z vyhradeného aplikačného servera na tento port.
Keďže sa jedná o komunikáciu zabezpečenú TLS a D2000 KOM proces podporuje iba nekryptovanú verziu, na aplikačnom serveri sme nainštalovali utilitu stunnel do štandardného adresára C:\Program Files (x86)\stunnel.
Dodaný certifikát a kľúče sme nakopírovali do podadresára config a upravili sme konfiguračný súbor stunnel.conf, ktorý sa v ňom nachádza.
Na obrázku môžete vidieť obsah konfiguračného súboru. Na začiatku je zapnutá najvyššia úroveň logovania (7) a definovaný logovací súbor (štandardne tiež vznikne v podadresári config).
Následne je definovaná služba mqtt. Stunnel má počúvať na porte 1883 na lokálnom rozhraní a po pripojení klienta (procesu D2000 KOM) sa pripojiť na IP adresu a port udané parametrom connect (IP adresa na obrázku nie je skutočná 😊).
Ďalšie riadky hovoria o certifikáte servera (CAfile), verejnom a súkromnom kľúči pre stunnel (cert/key) použitých na autentifikáciu voči MQTT brokerovi.
Pomocou utility telnet (telnet localhost 1883) sme si overili funkčnosť spojenia.
Ďalej už budeme pokračovať v prostredí D2000 CNF. Vytvorili sme novú linku L.Battery typu TCP/IP-TCP a nastavili pripájanie sa na lokálny port 1883, kde počúva stunnel.
V protokolových parametroch linky sme nenastavovali nič – nebolo potrebné ani užívateľské meno a heslo, keďže na autentifikáciu sa využíva TLS úroveň.
Na tejto linke sme vytvorili stanicu B.Battery. Na nej sme nastavili komunikačný protokol MQTT Client Protocol a na záložke Address zadali adresu #, čo znamená, že do stanice budú smerované správy s ľubovolnou témou (Topic) poslané MQTT brokerom.
Na tejto stanici sme vytvorili 5 meraných bodov s adresami podľa dokumentácie MQTT protokolu:
- Textový bod s adresou IN_TOPIC bude obsahovať tému (topic) prijatej správy.
- Textový bod s adresou IN_DATA bude obsahovať textové dáta prijatej správy.
- Celočíselný bod s adresouIN_ID bude obsahovať číselné ID prijatej správy. Ak je úroveň potvrdzovania aspoň 1 (štandardná hodnota parametra Subscribe QoS nastaviteľného v parametroch linky je QoS 1), tak sa jedná o 16-bitové celé číslo. Pokiaľ by bola úroveň potvrdzovania QoS 0, meraný bod by mal hodnotu 0.
Ak je úroveň potvrdzovania vyššia a zároveň existuje celočíselný meraný bod s adresou ACK_ID, tak D2000 KOM proces očakáva potvrdenie spracovania každej správy zápisom hodnoty bodu IN_ID do bodu ACK_ID. Tak je možné dosiahnuť, že správa bude potvrdená MQTT brokeru až po jej spracovaní v D2000 (napr. parsovanie a uloženie do databázy). Ak takýto bod neexistuje, správa je potvrdená hneď po prijatí. - Výstupné textové body s adresami OUT_TOPIC a OUT_VALUE budú slúžiť na posielanie príkazov.
Komunikácia sa rozbehla bez problémov. Na obrázku č. 5 je vidieť aktuálnu hodnotu meraného bodu M.Battery.IN_DATA– je zrejmé, že dáta (payload) sú JSON reťazec. Aby kolegovia nemuseli riešiť jeho parsovanie v ESL skripte, implementovali sme do MQTT protokolu parameter linky PayloadType. Prednastavená hodnota parametra je Text only – v takom prípade D2000 KOM proces nerobí ďalšiu analýzu dát. Pokiaľ ale zmeníme hodnotu parametra na JSON, tak D2000 KOM bude dáta parsovať ako JSON reťazeca je možné zadefinovať merané body s adresami JA=adresa, kde JA znamená „JSON adresa“ a adresa je adresa položky v JSON dátach.
V budúcnosti bude možné podľa potreby pridávať ďalšie spôsoby parsovania a adresácie meraných bodov (napr. pre formáty XML, CSV alebo Protocol Buffers, ktoré používa MQTT Sparkplug).
Pre jednotlivé témy (Topic) sme vytvorili samostatné stanice. Nasledovný obrázok ukazuje konfiguráciu meraných bodov pre status konkrétnej batérie. Téma správy má hierarchickú štruktúru – obsahuje názov firmy, sériové číslo batérie a informáciu, že sa jedná o jej status: pixii/200599000012/status/battery.
Aby táto stanica „ožila“, zmenili sme adresu B.Battery z “#” na “.*”. Do takejto stanice chodia “zvyšné“ správy, ktorých téma nesedí s adresou žiadnej inej stanice.
Keďže niekedy môže byť výhodné spracovať rôzne témy v rámci jednej stanice, podporili sme aj interpretáciu adresy stanice ako regulárny výraz. Pokiaľ teda téma nie je rovnaká ako adresa žiadnej stanice, prehľadajú sa stanice ešte raz, ale tentokrát sa ich adresa interpretuje ako regulárny výraz. Ak ani takto nie je nájdená zhoda, použije sa stanica s adresou “.*” ako „posledná možnosť“.
Kolega následne nastavil linkový parameter Publish QoS na hodnotu QoS 1 (aby naše zapisované správy boli potvrdzované) a vyskúšal riadenie batérie. Pri zápise je potrebné najskôr nastaviť meraný bod s adresou OUT_TOPIC (ak sa topic opakuje, stačí jednorázovo) a následne zápis do meraného bodu s adresou OUT_VALUE funguje ako trigger a spôsobí poslanie PUBLISH správy.
V trace súbore linky bolo možné vidieť poslanie PUBLISH správy s číslom 12 a jej potvrdenie správou PUBACK.
Záver
MQTT protokol sa pre svoju jednoduchosť a nenáročnosť začína presadzovať nielen v IoT oblasti, ale aj v „home automation“ a postupne sa tlačí aj do priemyselnejších aplikácií. Výhodou je, že centrálny broker môže správy jedného zariadenia distribuovať viacerým prijímateľom, riešiť centrálne autentifikáciu, správu užívateľov, prístupové práva, logovanie a podobne. S vysokou pravdepodobnosťou budú nasledovať ďalšie nasadenia a rozširovania MQTT protokolu v aplikačnom serveri reálneho času Ipesoft D2000.
28.10.2021, Ing. Peter Humaj, www.ipesoft.com
Iné blogy