.png)
info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
12.5.2025
Koncept zjednoteného menného priestoru - Unified Namespace UNS
Koncept zjednoteného menného priestoru - Unified Namespace UNS
Dnes by som chcel trochu pomeditovať nad konceptom zjednoteného menného priestoru (Unified Namespace - UNS). Je to iba jedno z módnych slov alebo je za ním niečo viac – niečo, čo stojí za uváženie?
Na začiatku si povedzme, čo o UNS hovoria jeho podporovatelia. Google nájde viacero blogov a prezentácií, napr. na stránkach hivemq.com, emqx.com, clarify.io či inductiveautomation.com. Na Youtube je asi najznámejším evanjelizátorom UNS Walker Reynolds na svojom kanále 4.0 Solutions.
Takže – aké sú základné tézy konceptu UNS a aký problém rieši?
1. Komunikácia medzi jednotlivými vrstvami v klasickej automatizačnej „pyramíde“ vyžaduje konfigurovanie komunikácií bod-bod na jednotlivých úrovniach (PLC, SCADA, MES, ERP, Cloud). Najlepšie to vyjadrí obrázok:
2. Pridávanie nových zdrojov dát a zverejnenie do horných vrstiev pyramídy vyžaduje súčinnosť odborníkov na všetkých nižších úrovniach pyramídy (niektorí z nich môžu byť externí dodávatelia). Tento proces môže byť preto pomalý, drahý a nespoľahlivý.
3. Preto je nutné prejsť z komunikácie bod-bod na kvalitatívne vyššiu komunikáciu, ktorú predstavuje protokol MQTT a architektúra hub-spoke (tu začína byť jasnejšie, prečo medzi presadzovateľmi UNS sú výrobcovia MQTT brokerov ako hivemq.com a emqx.com). Centrom architektúry je MQTT broker, ku ktorému sú pripojení jednak producenti informácií (PLC, RTU a iné zariadenia z procesnej úrovne), ako aj systémy z vyšších úrovní automatizačnej pyramídy (SCADA, MES, ERP), ktorí sú konzumenti týchto informácií, ale môžu byť aj producenti (napr. agregovaných dát).
4. Veľkou výhodou architektúry hub-spoke je, že na pripojenie ďalšieho systému (prípadne nahradzovanie napr. jedného SCADA systému iným) stačí vytvoriť spojenie medzi ním a centrálnym hubom (MQTT brokerom). Tento centrálny hub je vnímaný ako „the single source of truth“ (jediný zdroj pravdy) pre všetky dáta a informácie v podniku.
5. Navyše, dáta musia byť štruktúrované – organizované (hierarchicky). Napríklad emqx.com udáva štyri typy UNS:
a. Funkcionálne namespace – organizácia zariadení a dátových bodov podľa funkcie alebo účelu. Zariadenia a dátové body sú zoskupené na základe konkrétnej úlohy, ktorú vykonávajú, a nie na základe ich fyzického umiestnenia alebo siete.
b. Informatívne namespace - organizácia zariadení a dátových bodov podľa informačného kontextu – napríklad vo výrobnom podniku sú zariadenia a dátové body spojené s teplotou zoskupené v jednom mennom priestore, body spojené s tlakom v ďalšom priestore.
c. Definičné namespace - organizácia zariadení a dátových bodov podľa ich definícií a charakteristík (typ, veľkosť, funkcia) - napríklad vo výrobnom podniku sú zariadenia a dátové body spojené s motormi sú v jednom mennom priestore, body spojené so senzormi v oddelenom priestore.
d. Ad-hoc namespace – dočasné alebo neformálne organizovanie zariadení a dátových bodov, použité, ak nebolo ešte zriadené formálne namespace, alebo ak zariadenia a dátové body musia byť rýchlo zoskupené pre špecifický účel (napr. v prípade zlyhania zariadenia bude vytvorené ad-hoc namespace pre všetky zariadenia a dátové body týkajúce sa zlyhaného zariadenia kvôli rýchlej diagnostike a vyriešeniu problému).
Walker Reynolds používa hierarchickú štruktúru podľa štandardu ISA-95 časť 2 (Enterprise/Site/Area/Line/Cell) – táto teda priamo kopíruje fyzické umiestnenie zariadení v rámci výrobného podniku.
Jedná sa teda o zaujímavý a príťažlivý koncept. Kto by nechcel mať jednoducho dostupné dáta, ktoré môže ľahko pripojiť do či do SCADA alebo MES systému, prípadne poslať na analýzu a archiváciu do cloudu? A vzhľadom k otvorenosti a jednoduchosti MQTT protokolu je to určite lepšie ako proprietárne protokoly ... alebo komplikované OPC UA. Navyše, akonáhle sú dáta na MQTT brokeri, sú dostupné pre ľubovoľného z klientov – naproti tomu, ak aj PLC implementuje OPC UA server, výkonnostné limity PLC (a prípadne licencovanie) môžu výrazne obmedziť počet pripojených OPC UA klientov.
A teraz námietky:
- Väčšina výrobných podnikov má za sebou históriu dlhú niekoľko rokov alebo desaťročí. Používa zariadenia od rôznych výrobcov, disponujúce rôznymi komunikačnými protokolmi. Je nerealistické očakávať, že každé z týchto zariadení bude podporovať MQTT. Obídením by mohlo byť nasadenie „edge devices“, ktoré by komunikovali proprietárnymi protokolmi s PLC a zverejňovali dáta cez MQTT protokol. Nasadenie týchto zariadení by si samozrejme vyžiadalo ďalšie náklady (navyše, nesmú zasahovať do existujúcej komunikácie medzi PLC a lokálnymi SCADA systémami).
- Keď hovoríme o lokálnych SCADA systémoch: vo výrobných podnikoch sú malé SCADA systémy často súčasťou technológie. Ich dodávateľom je dodávateľ technológie a PLC. Často sú jediným rozhraním, cez ktoré je možné získavať informácie z PLC, pretože tak to dodávateľ navrhol a zásahy do komunikácie nie sú povolené a spôsobili by stratu záruky. Pokiaľ napríklad implementujeme EMS (Energy Management System), je nutné dohodnúť sa s jednotlivými dodávateľmi, akým spôsobom zverejnia energetické dáta pre EMS.
- Keď vo výrobnom podniku implementujeme EMS či veľký SCADA/MES systém, často tak vytvárame vlastný „hub“, do ktorého privádzame desiatky rôznych komunikácií (PLC, RTU, lokálne SCADA systémy, údaje z elektromerov a iné). Takéto systémy potom slúžia (bežne aj desaťročia) a v priebehu rokov sa k nim pripájajú nové technologické celky. Pokiaľ má náš „hub“ dostačujúce komunikačné schopnosti a dokáže zverejňovať dáta spôsobom vyhovujúcim ďalším systémom (MES, ERP) – napr. cez OPC server, OPC UA server, komunikačné protokoly ako Modbus Server, IEC-104 server, ICCP/TASE-2 server, cez REST API, ODBC rozhranie, prípadne pomocou pluginov (MS Excel) alebo ich dokáže dátovými pumpami kopírovať do databáz pre ERP systémy – tak sa značne znižuje dopyt po nezávislom MQTT hube, ktorý by síce tiež slúžil všetkým – ale iba za predpokladu, že podporujú MQTT protokol! Navyše, ak na implementáciu SCADA aj MES systémov použijeme technológiu Ipesoft D2000, je možné ich prepojiť pomocou transparentného gatewaya a pridávať ďalšie dátové body do MES systému jednoduchým XML exportom zo SCADA a importom do MES systému – a na porovnanie konfigurácií, XML export a import sa dá použiť modul Sysmirror.
- Z mojej skúsenosti vyššie úrovne automatizačnej pyramídy často nemajú záujem o surové dáta najspodnejších úrovní (napr. údaje o spotrebe jednotlivých elektromerov), ale o agregované dáta, generované vyššou úrovňou (napr. celkové spotreby technologických celkov/výrobných hál/celého podniku, ktoré agreguje EMS systém). V takom prípade je síce tiež možné použiť hub-spoke architektúru realizovanú MQTT serverom, ale zrejme nebude platiť téza o veľkom počte záujemcov o dáta.
- Rôzne prístupy k organizovaniu dátových bodov v rámci UNS (funkcionálne, informatívne, definitívne, ad-hoc alebo hierarchicky organizované) môžu spôsobiť ďalšie komplikácie pri integrovaní nových zariadení do existujúceho UNS.
- No a nakoniec, okrem existujúcich systémov je nutné spravovať aj nový systém – MQTT server. Konfigurovať prístupové práva pre jednotlivých klientov, udržovať ho (aktualizovať softvér). Pokiaľ sa stane dôležitým komunikačným centrom, bude nutné riešiť jeho výpadky (plánované aj neplánované) implementovaním redundancie. Skrátka, nič nie je zadarmo.
Nechápte ma zle – uznávam, že UNS je zaujímavý koncept a v konkrétnych prípadoch aj užitočný a prínosný. Na druhej strane, existuje veľké množstvo komunikačných protokolov a riešení – od proprietárnych až cez otvorené protokoly ako OPC UA. Nájdu si UNS a MQTT svoje miesto pod slnkom? Určite áno – aj naše systémy už u viacerých zákazníkov komunikujú s MQTT servermi (napr. batériové úložiská PowerShaper).
Čo sa týka podpory MQTT zo strany výrobcov, tak už existujú napríklad MQTT knižnice pre Simatic S7-1500 ako aj pre PLC firiem Rockwell, WAGO, Beckhoff a iné.
Preto vnímam koncept UNS ako zaujímavú alternatívu klasickej automatizačnej pyramídy. Osobne by som uvítal rozšírenie MQTT – keďže tento protokol má Ipesoft D2000 už implementovaný, podporujeme prácu s textovým aj JSON payloadom, podporujeme dokonca aj štandard MQTT Sparkplug-B, ktorý definuje binárny payload. Vytlačí ale v dohľadnom čase sériové protokoly ako Modbus či proprietárne protokoly firiem vyrábajúcich PLC? To si viem iba ťažko predstaviť. Ako ukazuje diel webového komixu xkcd.com z roku 2011, štandardy (medzi ktoré protokoly patria) umierajú iba ťažko a pomaly.
Ale aby sme neboli obviňovaní, že riadiace systémy postavené na aplikačnom serveri reálneho času Ipesoft D2000 sa bránia UNS: pred niekoľkými dňami bola do našej implementácie komunikačného protokolu MQTT dorobená možnosť, fungovania D2000 ako klient typu „Edge Node“ (a prípadne niekoľko podriadených „Device“/“Sensor“ zariadení), t.j. aby bol producentom dát, ktoré spracúvajú klienti typu „Host Application“.
A ešte poznámka na koniec: Walker Reynolds nazýva UNS „the single source of truth“, pretože všetky dáta a informácie v podniku sú zhromaždené na jednom mieste, hierarchicky zorganizované a dostupné pre všetkých spotrebiteľov, ktorí ich potrebujú. Pritom sa jedná iba o aktuálne hodnoty jednotlivých datapointov a implicitne sa predpokladá, že spotrebitelia podporujú MQTT protokol. Rozmýšľam, ako by sa dala nazvať situácia, keď v našich MES systémoch sú pre ich používateľov dostupné všetky (relevantné) dáta – nielen aktuálne hodnoty ale aj história (niektoré aplikácie majú v archívnych a trezorových databázach aj vyše 20 rokov primárnych a agregovaných dát), organizované aj vizuálne na schémach, s grafmi, tabuľkami a nákresmi technológie? S podporou historického režimu schém umožňujúceho prehrávanie dát v čase, s možnosťou exportu dát do viacerých formátov, aktuálne aj historické dáta dostupné nielen pre MS Excel ale aj pre rôzne iné produkty a systémy pomocou vyššie spomenutých rozhraní (OPC, OPC UA, REST API, ODBC a iné) ... nie, nechcem vymýšľať novú terminológiu, iba upozorniť na to, že naši užívatelia už často dostávajú všetky potrebné dáta aj s vizuálnou prezentáciou a širším technickým kontextom.
Čo sa týka vytvárania hierarchie – pomocou tzv. Logických skupín je možné v Ipesoft D2000 vytvoriť ľubovoľné množstvo hierarchií a zaradiť do nich D2000 objekty (dokonca v rámci hierarchie môže byť objekt zaradený na viacerých miestach, ak je to potrebné).
29.4.2025, Ing. Peter Humaj, www.ipesoft.com
Iné blogy