Komunikácia - MQTT Sparkplug

Čo je to MQTT Sparkplug? A má niečo spoločné s MQTT? Prípadne ho má nahradiť? Aj na tieto otázky sa dozviete odpovede z dnešného blogu.

V blogu MQTT v praxi, ktorý má už takmer tri roky, som popísal základy fungovania protokolu MQTT. Správy v MQTT protokole majú tému (Topic) a telo (Payload).

Topic musí byť UTF8-kódovaný reťazec. Môže mať ľubovoľnú štruktúru definovanú lomítkami (napr. ‘závod A/prevádzka B/linka C/plc D/TeplotaOkolia’) a MQTT klienti (záujemci o správu) môžu požiadať o zasielanie správ s konkrétnym Topicom (prípadne s maskou, napr. maska ‘závod A/+/+/+/TeplotaOkolia’ zodpovedá všetkým zariadeniam na všetkých linkách v závode A).

Telo (Payload) môžu byť ľubovoľné dáta, ktoré MQTT protokol nedefinuje.

V minulosti sme ako prvý krok implementovali MQTT protokol takým spôsobom, že Topic/Payload boli prijaté do textových meraných bodov s adresami IN_TOPIC a IN_DATA – a všetko spracovanie a prípadná extrakcia dát sa museli vykonať v rámci ESL skriptu (prípadne v počítaných bodoch).

Neskôr, keď sme sa stretli s klientami, ktorí posielali JSON Payload, sme podporili parsovanie JSON správ priamo v D2000 KOM procese – cez merané body s adresou JA=json_address (napr. adresa JA=rx.current vyparsuje JSON element current nachádzajúci sa v štruktúre rx).

Štandard MQTT Sparkplug sa snaží o „dodefinovanie „ MQTT pre potreby priemyselných zariadení (IIoT). Aby nebolo nutné pre každé zariadenie definovať napr. JSON alebo XML schému – a zároveň aby dáta boli zakódované efektívnejšie, ako to dokážu textové formáty.

Typy zariadení (alebo skôr aplikácií)

Na úvod si ukážme, aké typy aplikácií Sparkplug definuje. Napísal by som typy zariadení, ale nemôžem, keďže zariadenie (Device) je jeden z definovaných typov. Takže:

Edge Node - má podporu MQTT protokolu a pripája sa k MQTT serveru. Posiela mu údaje získané z Device alebo vlastné, prípadne agregované.

Device/Sensor - reprezentuje fyzické alebo logické zariadenie pripojené k Edge Node a poskytujúce údaje, procesné dáta alebo metriky (metrikou nazýva norma konkrétny údaj, napr. meranú teplotu).

Host Application - reprezentuje spotrebiteľa dát (SCADA/MES systém, historian, analytický nástroj), ktorý sa pripája k MQTT serveru, prijíma MQTT dáta od Edge Node/Device a prípadne posiela povely. (D2000 aplikácia je Host Application). Konkrétny Edge Node/Device môže nastavený jednu konkrétnu Host Application ako primárnu (Primary) – ak nie je táto k dispozícii, neposiela žiadne PUBLISH správy, ale dočasne ukladá všetky hodnoty lokálne a pošle ich až po pripojení sa Primary Host Application (toto sa nazýva Store & Forward).

Obrázok 1 - Model prepojenia aplikácií v Sparkplug štandarde. MQTT Server je v strede.

Jedno fyzické zariadenie môže obsahovať Edge Node a zároveň niekoľko logických Device.

Definície tém a správ

Sparkplug špecifikuje presný formát Topicu pre Edge Node/Device. Topic je v tvare namespace/group_id/message_type/edge_node_id/[device_id], kde:

• namespace je konštanta spBv1.0 (pre Sparkplug B verziu 1.0)

• group_id je ľubovolný názov logickej skupiny (napr. podľa typu zariadenia, prevádzky, organizačnej štruktúry atď)

• message_type je typ správy

• edge_node_id je identifikátor Edge Node

• device_id je identifikátor Device (iba ak je správa od/pre Device)

Sparkplug zároveň špecifikuje typy správ, ktoré jednotlivé aplikácie posielajú:

• NBIRTH – Birth certificate for Sparkplug Edge Nodes (informácia o pripojení sa Edge Node k MQTT Serveru obsahujúca všetky metriky Edge Node).

• NDEATH – Death certificate for Sparkplug Edge Nodes (informácia o strate spojenia MQTT Servera s Edge Node).

• DBIRTH – Birth certificate for Devices (informácia o nadviazaní komunikácie medzi Device a Edge Node, ktorá obsahuje všetky metriky konkrétneho Device).

• DDEATH – Death certificate for Devices (informácia o strate spojenia Edge Node s Device).

• NDATA – Edge Node data message (dáta, ktoré obsahujú zmenené metriky z Edge Node).

• DDATA – Device data message (dáta, ktoré obsahujú zmenené metriky od Device).

• NCMD – Edge Node command message (príkaz Host Application pre Edge Node).

• DCMD – Device command message (príkaz Host Application pre Device).

• STATE – Sparkplug Host Application state message (informácia od stave Host Application pre Edge Node/Device [online/offline]).

Keď sa Edge Node pripojí k MQTT serveru, vygeneruje NBIRTH a DBIRTH správy, ktoré obsahujú všetky metriky (zasielané údaje). Následne posiela iba zmenené dáta pomocou správ NDATA/DDATA. Pri strate spojenia Edge Node s MQTT serverom tento automaticky generuje správu NDEATH (pomocou mechanizmu WILL protokolu MQTT). Pri zámernom a korektnom ukončení spojenia musí Edge Node správu NDEATH generovať explicitne. Záujemcovia (Host Application) tak vedia, že došlo ku strate komunikácie (a napr. D2000 KOM proces zmení stav staníc s adresami reprezentujúcimi Edge Node a jeho podriadené Devices na StHARDERR).

Ak Edge Node stratí spojenie s Device, pošle DDEATH správu.

Správy NCMD a DCMD generuje Host Application a slúžia na povelovanie, teda zápis do Edge Node/Device. Pre zaujímavosť – na zápis do metriky s názvom ‘Node Control/Rebirth’ by mal Edge Node zareagovať poslaním NBIRTH/DBIRTH správy. Toto sa deje, keď Host Application štartuje/pripája sa k MQTT serveru a potrebuje zistiť aktuálne hodnoty metrík.

Správu STATE (vo formáte JSON) generuje Host Application a oznamuje ňou svoje pripojenie k MQTT serveru (alebo ňou MQTT server oznamuje odpojenie Host Application). Ak je pre konkrétny Edge Node aplikácia primárnou, môže sa Edge Node napríklad odpojiť od aktuálneho MQTT servera a skúsiť pripojiť k ďalšiemu MQTT serveru, aby našiel svoju Primary Host Application (táto funkcionalita je užitočná pre redundantné MQTT systémy).

Payload

Payload všetkých typov správ (s výnimkou správ STATE) je v binárnom formáte, ktorý definujú Google Protocol Buffers. Binárny formát umožňuje efektívnejšie zakódovanie dát ako napr. JSON. To je výhodou na úzkopásmových linkách, prípadne v situáciách, keď sa platí za prenesené dáta – napr. v sieti mobilných operátorov.

Payload obsahuje časovú značku odoslania a sériu metrík. Každá metrika obsahuje meno (prípadne numerický alias), typ hodnoty, samotnú hodnotu, voliteľne čas získania hodnoty a ďalšie príznaky (napr. príznak is_null hovorí, že hodnota je null – v D2000 tento príznak mapujeme na Invalid).

Ak sú použité numerické aliasy, tak NBIRTH/DBIRTH správa musí obsahovať aj názvy metrík aj aliasy. Na základe toho si Host Application (napr. D2000) vytvorí mapovaciu tabuľku.

Sparkplug podporuje jednoduché hodnoty, polia hodnôt aj komplexné dátové štruktúry. Implementácia v D2000 zatiaľ podporuje čítanie jednoduchých hodnôt a polí a zápis jednoduchých hodnôt.

Obrázok 2 - Komunikačná linka pripojená k test.mosquitto.org

Testovanie

Testovanie a vývoj MQTT Sparkplug protokolu sme uskutočnili s pomocou webov test.mosquitto.org a broker.hivemq.com, ktoré poskytujú MQTT servery so simulovanými aj reálnymi Sparkplug klientami a servermi.

Obrázok 3 - Niekoľko vstupných meraných bodov so Sparkplug adresou.

Jedným z pripojených klientov bol IIoT gateway Moxa AIG-301 (datasheet), ktoré podporuje aj MQTT Sparkplug štandard.

Browsovanie

Pre uľahčenie konfigurácie meraných bodov v D2000 sme ku zoznamu protokolov podoporujúcich browsovanie (viď blog) pridali aj MQTT.

Je možné vybrať si ako adresu stanice pre MQTT protokol Topic zo zoznamu prijatých. Ak je Topic v Sparkplug formáte, je ponúknutá jeho skrátená verzia (v tvare group_id/edge_node_id/[device_id], t.j. vynechaná je konštanta spBv1.0 a message_type).

Obrázok 4 - Zoznam Topicov získaných z test.mosquitto.org.

Pre Sparkplug payload sú ponúknuté názvy metrík spolu s typom metriky, aktuálnou hodnotou, časovou značkou (jedná sa o časovú značku odoslania správy, prípadne o časovú značku poslanú s metrikou – ak nie je prítomná ani jedna, tak o aktuálny čas prijatia správy). V poslednom stĺpci je názov meraného bodu, ak je už metrika nakonfigurovaná.

Obrázok 5 - Zoznam metrík získaných zo zariadenia pripojeného k test.mosquitto.org.

Šablóny

Šablóny (templates) umožňujú prácu so štruktúrovanými hodnotami (ekvivalent štruktúr v jazyku C), ktoré sa nazývajú aj UDT (User Defined Types). Tieto štruktúry môžu byť aj viacnásobne vnorené. Podporili sme v D2000 čítanie položiek štruktúr (tj. hodnôt s jednoduchými typmi) do meraných bodov.

Nasledujúci obrázok ukazuje jednoduchú metriku „sec“ (typu Int32) ako aj metriku „secUDT“ (typu Template) a jej položku „sec“ (typu Int32) s adresou „secUDT->sec”. Adresácia v D2000 spočíva v uvedení všetkých úrovní štruktúr až po koncovú položku, pričom sú oddelené dvojicou znakou („->”). Táto dvojica je konfiguračný parameter linky, keďže sa nedá vylúčiť, že niektoré metriky by mohli mať takúto kombináciu znakov v názve a v takom prípade by bolo nutné vybrať iný oddeľovač.

Obrázok 6 - Zoznam metrík získaných zo zariadenia pripojeného k broker.hivemq.com.

Datasety

Dataset je niečo veľmi podobné štruktúrovanej premennej v D2000. Má pomenované stĺpce (každý z nich má zadefinovaný jednoduchý typ) a riadky. Dataset môže byť súčasťou šablóny alebo byť priamo metrikou. Takže aj adresácia v D2000 je intuitívna s použitím syntaxe structure[row]^column, napr. MyMetric[2]^Temperature. Pokiaľ zadáme namiesto konkrétneho čísla riadku hviezdičku [*] a na meranom bode nakonfigurujeme cieľový stĺpec štruktúry, môžeme pomocou jedného meraného bodu naplniť celý stĺpec štruktúrovanej premennej hodnotami zo stĺpca datasetu. Na nasledujúcom obrázku je niekoľko takýchto bodov (napr. s adresou SA=DHS/Formation Data->Reservoir Parameter[*]^Layer).

Obrázok 7 - Zoznam metrík včítane datasetu a jeho položiek získaný z broker.hivemq.com.

Prečo MQTT?

MQTT je jednoduchý komunikačný protokol (rádovo jednoduchší ako OPC UA), takže je nenáročný na implementáciu. Podporuje autentifikáciu (užívateľské meno a heslo) aj kryptovanie. MQTTS je MQTT zabalené do TLS vrstvy, ktoré sa dá implementovať jednoducho napr. pomocou utility stunnel, ako to popisuje blog o MQTT (implementácia kryptovania v OPC UA je oveľa komplikovanejšia).

Výhodou MQTT protokolu voči bežným komunikačným protokolom je, že vytvorený „dátový hub“, t.j. MQTT server, je nezávislý od konkrétnej aplikácie. Takže pridanie novej aplikácie (napr. analytický nástroj alebo MES systém) nevyžaduje sprístupnenie dát napr. zo SCADA systému (čo môže byť spojené s požiadavkami na licencie, cenou za prácu dodávateľa a pod), ale iba pripojenie ďalšieho klienta k existujúcemu MQTT serveru (a nakonfigurovanie jeho prístupových práv).

Samozrejme, každá minca má dve strany – cenou za takúto flexibilitu je nutnosť prevádzkovať MQTT server – ako aj zabezpečiť jeho pripojenie ku všetkým potrebným zariadeniam (PLC, RTU) pomocou zariadení typu Edge Node (pokiaľ priamo MQTT protokol nepodporujú).

Ak má nejaký zákazník napr. SCADA systém postavený na D2000 technológii, tak nakomunikované dáta dokáže sprístupniť ďalším systémom viacerými spôsobmi – napr. pomocou transparentného gatewaya (ak sa jedná o systém postavený takisto na D2000 technológii), cez OPC DA server alebo OPC UA server, prípadne cez rôzne komunikačné protokoly (IEC 870-5-104 Server, Modbus server), cez D2000 REST API alebo D2000 OBJApi.

Záver

MQTT protokol svojou jednoduchosťou a nenáročnosťou priťahuje výrobcov rôznych zariadení. Jeho nadstavba, štandard MQTT Sparkplug, umožňuje zjednotiť komunikáciu priemyselných zariadení cez MQTT a čítanie/zápis hodnôt z/do zariadení. D2000 KOM proces k podpore textového a JSON payloadu pridáva aj podporu MQTT Sparkplug, aby opätovne rozšíril množinu podporovaných komunikačných štandardov.

30.9.2024, Ing. Peter Humaj, www.ipesoft.com

‍

Komunikácia - MQTT Sparkplug

Peter Humaj

Komunikácia - MQTT Sparkplug

Iné blogy

Komunikácia - optimalizácia v protokole Ethernet/IP

Diagnostika a ladenie databázových operácií v D2000

D2000 a práca s databázami