Teollisuuden ja maatalouden automaatiossa Unified Namespace (UNS) eli yhtenäinen nimiavaruus on nykypäivää. UNS kokoaa yrityksen kaiken datan – oli kyseessä tehdas tai älykäs säätösalaojitettu pelto – yhteen selkeään, hierarkkiseen puurakenteeseen.
Kun UNS-puu toteutetaan MQTT Sparkplug -protokollalla, törmätään usein väärinkäsitykseen, että Sparkplug B pakottaa UNS-puun matalaksi (koska osoite on matala: Group / Edge / Device). Miten ihmeessä voimme rakentaa syvän ja vapaasti skaalautuvan UNS-puun, jos tiedonsiirtoprotokolla määrittää raamit näin tiukasti? (lisätietoa: www.hivemq.com)
Vastaus on kuitenkin yksinkertainen: MQTT Sparkplug -osoite on vain tiedon kuljetusmekanismi, ei UNS-puun lukittu muotti. Mitään esteitä vapaalle UNS-hierarkialle ei ole, kun tiedonsiirto ja looginen sijainti erotetaan toisistaan.
Miten tämä eroaa alan tunnetuista malleista?
Teollisuusautomaatiossa tähän haasteeseen on perinteisesti tarjottu kahta johtavaa mallia, joista kumpaankin liittyy omat haasteensa:
- Parris-malli (Matthew Parris) pyrkii ahtamaan koko syvän hierarkian yhteen Sparkplug-osoitteeseen käyttämällä Group ID:n sisällä erikoismerkkejä (kuten Tehdas:Alue:Linja). Tämä kuitenkin siirtää ongelman kooditasolle, sillä se vaatii raskasta ja virhealtista merkkijonojen parsimista järjestelmän molemmissa päissä.
- Schultz-malli (David Schultz) puolestaan ratkaisee tilanteen fyysisellä arkkitehtuurilla: pystyttämällä useita eri MQTT-välittäjiä organisaation eri tasoille ja replikoimalla dataa niiden välillä ylöspäin. Tämä puolestaan synnyttää monimutkaisen palvelinviidakon ja vaatii erillisen integraatioalustan datan siirtelyyn.
SSOT-automaation lähestymistapa: Ohjelmistokeskeinen kytkentäeditori
Me olemme valinneet kolmannen tien, joka ottaa molempien maailmojen parhaat puolet ilman niiden varjopuolia. Erotamme matalan tason tiedonsiirron ja syvän loogisen UNS-hierarkian kokonaan toisistaan tietokantatasolla.
Kuvitellaan peltomallinnus, jossa meillä on syvä hierarkia: Galileo-palvelut / Seinäjoen alue / Alajoki / Kastelualue 2 / Säätökaivo.
Kentällä oleva älykäs ohjausyksikkö kommunikoi MQTT-välittäjän kanssa käyttäen matalaa ja lyhyttä Sparkplug-osoitetta, kuten Edge ID ”AA” ja Device ID ”1” (Sparkplugin otsikko: spBv1.0/galileo/DDATA/AA/1).
Kun laite ilmoittautuu ensimmäistä kertaa, se nousee väliaikaiseen Inboxiin. Järjestelmän kytkentäeditorissa tämä laitteen Edge ID tunniste ”AA” sidotaan suoraan tietokannassa siihen kohtaan syvää UNS-hierarkiaa, jonne se loogisesti kuuluu. DuckDB tietokannan uns_nodes taulussa on jokaiselle solmulle määritelty uns_key, uns_id, name ja sparkplugin_edge_id, mikäli kyseiseen solmuun on kytketty MQTT Sparkplugin Edge_id (esim. ”AA”).
Kaikki solmujen väliset lapsi ym. kytkökset on määritelty uns_edges taulussa.
Tämän arkkitehtuurin hyödyt:
- Edge voi ilmoittautua kantaan lyhyellä Edge ID-tunnuksella (esim: ”AA”) ilman kikkailua maastossa, koska ei tarvitse tietää UNS-hierarkian polkua. Laiteet kytkeytyvät automaattisesti, jos niiden Edge ID on UNS-hierarkiassa.
- Laite voidaan kytkeä, siirtää tai vaihtaa UNS-puussa ilman, että laitteen sisäistä koodia tai MQTT-aihetta (topic) tarvitsee koskaan muuttaa.
- Vältämme Parris-mallin merkkijononparsimiset ja Schultz-mallin raskaan palvelininfrastruktuurin.
Tietograafi täydentää kokonaisuuden
UNS -puurakenne kertoo loistavasti, missä laite sijaitsee, mutta se ei osaa kertoa, miten laitteet vaikuttavat toisiinsa. Tähän tarvitaan tietograafia.
Tietograafin avulla voimme luoda solmujen välille vapaita suhteita, kuten ”Säätökaivo 3 FLOWS_TO Säätökaivo 4” tai laskennallisia arvoja UNS-tiedoista esim. ”Kastelupumpun kustannukset tunnissa”. Kun nämä fysiikan ja logiikan säännöt sidotaan osaksi UNS-puuta, järjestelmästä tulee elävä digitaalinen kaksonen, joka ymmärtää prosessien todelliset riippuvuudet.
Tieto voittaa aina – kunhan se on järjestetty oikein. Erottamalla matalan tason tiedonsiirron ja syvän loogisen UNS-hierarkian toisistaan saamme keveän tiedonsiirron ja rajattoman skaalautuvuuden.