Gyönyörűen működik! Az adatok másodpercenként érkeznek, az áttekintő kép szépen frissül!
Bajcsa külterületéről a legközelebbi toronyig, onnan némi tekergőzés után a Microsoft nyugat-európai adatközpontjába. Érkezéskor a szervereken kisebb átalakulás, majd pár másodperc pihenő után irány újra Magyarország, a Com-Forth irodája, a laptopom képernyője. És mindez percek alatt kész, szinte költségek nélkül.
Bajcsa külterületén működik a MOL egyik gázkútja. Az ilyen gázkutak nagy előnye, hogy éjjel-nappal termelnek, különösebb erőfeszítés nélkül. Nem kell melléjük ember.
Viszont messze van mindentől és mindenkitől. Ha mégis szükség van emberi beavatkozásra, a riasztás csak valamilyen rádiós kapcsolaton keresztül juthat el a karbantartóhoz.
A másik probléma, hogy egy-egy nem várt meghibásodás rendkívül költséges tud lenni. Tíz- vagy akár százmilliós nagyságrendű. Ez a kettő együtt (messze van a karbantartó, és nagyon sokba kerül, ha nem tudnak időben közbelépni) gyilkos kombináció. Tapasztalataink szerint ez nem csak az olajipar problémája. Ezzel küzd a vízügy is.
Mi lenne, ha nem lenne ennyire bonyolult? Mi lenne, ha mobil internettel váltanánk ki a hagyományos rádió frekvenciákat? Ha sikerülne mobil internetre váltani, akkor nem lenne szükség a különleges rádiós hardverekre, a rádió engedélyre, hirtelen megugrana a kommunikációs sebesség, és a kúttól a számítógépemig különösebb erőfeszítés nélkül kiépíthető a redundancia is. A karbantartó sokkal gyorsabban, és sokkal pontosabb adatok alapján kaphat információt arról, hogy be kell-e avatkoznia. Ezt próbáltuk ki a bajcsai kútnál.
Arra kaptunk megbízást, hogy a kút mellett üzemelő Scadapack rendszerből szedjük ki az adatokat, és azokat jelenítsük meg a telephelytől távoli számítógépen vagy mobil eszközön, pont úgy, ahogy a Scadapack képernyőjén is látható. Hasonló adatgyűjtés már működött, a cél a meglévő rádiós rendszer lecserélése volt.
A Scadapack szerencsére szabványos, Modbus kommunikációra képes. A Modbuson érkező adatokat kellett valós időben megjelenítenünk, és azok alapján grafikonokat rajzolnunk.
A Scadapack mellé letettünk egy Moxa UC-8220-t. Ez a Moxa nem más, mint egy ipari beágyazott számítógép.
A beágyazott számítógép egy apró PC. Ilyen pl. a Raspberry Pi. És ilyen a Moxa UC is, csak ipari igényekre tervezték. Gyakran az edge computing jelzővel is illetik ezeket a viszonylag alacsony teljesítményű, 1-1 célszoftver számára viszont tökéletes, mindeközben nagyon megbízható eszközöket.
Ahogy egyik ügyfelünk mondta, és ezzel mi, a Com-Forth fejlesztői is maximálisan tudunk azonosulni: “Azért szeretjük a Moxát, mert olyan eszközöket gyárt, amelyeket ha egyszer letelepítünk, el is felejthetjük, hogy ott van, mert soha nincs vele semmi baj. Bírja az időjárást, nem fagy le a szoftver, nem hibázik a működésben. Ha bonyolult hibával küzdünk, abban mindig biztosak lehetünk, hogy nem a Moxával van a baj.”
A Moxa beépített Modbus és MQTT klienssel rendelkezik, ezért csak meg kellett adni a Scadapack Modbus címeket és az MQTT kommunikációs paramétereket, és már küldte is a felhőbe az adatokat. Nem is csodálkoztunk, hogy elsőre működött, hiszen a Moxánál ez megszokott!
A feladatnak azt a részét, hogy az adatok jussanak el a felhőig, ezzel akár késznek is nyilváníthattuk volna. Csakhogy az Azure-ban az is megoldható, hogy Docker konténereket küldjünk le a csatlakoztatott eszközökbe, ráadásul anélkül, hogy a tűzfalon portot kellene nyitnunk. Ez azt jelenti, hogy nem kell rést ütnünk a pajzson, ha távolról, Interneten keresztül akarjuk módosítani az adatgyűjtést. A másik nagy előnye ennek az eljárásnak akkor jelentkezik, ha nem csak egy-két eszközünk van az Azure-ra kötve, hanem akár több tucat, száz vagy ezer. Ugyanis ekkor igazán látványos annak az eredménye, hogy az összeset egy helyről monitorozhatjuk, és ha valamin mégis módosítani kell, akkor azt központilag tehetjük meg. Nem álltunk meg tehát, hanem megírtuk ugyanazt, amit a Moxa már amúgy is tudott: Modbuson kérdezgetni a SCADA-t, és az adatokat felküldeni MQTT-n. Mindez nagyon könnyű, ha az ember Node-REDet használ. A Node-RED projektet becsomagoltuk konténerbe, és feltettük az Azure konténertárjába. A Moxát beállítottuk, hogy Azure Edge eszközként működjön, ami azt jelenti, hogy ő maga kezdeményezi a kapcsolatot az Azure-ral, jelenti az állapotát, és engedi, hogy az Azure le tudjon küldeni konténereket. A leküldött konténereket azután a Moxa futtatja. Az a szép ebben a megoldásban, hogy kétféle kapcsolat is kiépül (a konténer leküldés miatt és az MQTT miatt), de mindkettőt a Moxa kezdeményezi, ezért a tűzfalat befelé irányban hermetikusan zárva tartjuk, és ezzel a legnagyobb biztonsági kockázatot kizárhatjuk.
A virtuális gépekről a legtöbben már hallottatok. (Aki még nem, az jobban teszi, ha utánanéz.) Sokan szeretjük, és használjuk is. Van viszont egy nagy hátrányuk: az erőforrásigényük. Sok GB memória, még több GB HDD/SSD és egy nagy szelet processzor szükséges hozzá. És mindez csak azért, mert akármire is használjuk, egy teljes oprendszert kell futtatnunk. A Docker konténer egy olyan "virtuális gép", amely nem tartalmazza az operációs rendszert, csak azt a programot, amit futtatni akarunk rajta. Ezért az erőforrás-igényük csak annyi, amennyit a feladatuk igényel. Ezek az előnyök miatt a felhő technológiában sokkal népszerűbb, mint a virtuális gép. Beágyazott számítógépeknél pedig a virtuális gép szóba sem jöhet a kevés erőforrás miatt.
Zanzásítva ott tartunk tehát, hogy a Moxán fut egy konténerben egy Node-RED, amely Modbuson kérdezi a SCADA-t, és MQTT-n küldi fel az adatokat az Azure IoT Hubba. A konténert az Azure-ból küldtük le.
Az MQTT csak valósidejű kommunikációra alkalmas. Nekünk trend görbéket is rajzolnunk kellett. El kellett tárolni az adatokat, legalább egy-két hónapig. Eddig se voltunk lehetőségek szűkében, de ha adattárolásról van szó, akkor aztán zavarba ejtő mennyiségű eszköz áll a rendelkezésünkre… és mindegyik tökéletesen megfelelő lehet. Mi az Azure Data Explorert (ADX) választottuk. Ezzel a legegyszerűbb a munka, hiszen natívan kapcsolódik az IoT Hubhoz, és közvetlenül olvasható Power BI-ból, ahova majd tovább kell küldenünk az adatokat megjelenítésre.
Ugyanitt, az ADX-ben lehet definiálni azokat a függvényeket, amelyek a 30 napos trend görbékhez kigyűjtik az adatokat.
Ilyen, kevéssé bonyolult függvényeket kell írni az adatok aggregálásához.
Ha pedig az ADX-ben rendelkezésre áll minden valósidejű és trend adat, akkor a Power BI-ban igazán egyszerű dolgunk van, hiszen a Direct Query-vel közvetlenül olvashatjuk az ADX-et. Már csak el kellett készíteni a megjelenítést. Ehhez a szokásos “lusta” megoldást választottuk: megkértük a kedves Megrendelőt, hogy küldje el a meglévő képernyőképet. Azt betettük háttérképnek, és ráhelyeztük az adatokat. Így előállt ugyanaz a kép, amit a telephelyen láthatnak, csak már bárhol megtekinthető a világban... megfelelő jogosultsággal.
A Power BI-ban sem kell veszélyes mutatványokat végezni. Megadjuk az ADX szerver és az adatbázis nevét, majd bepipáljuk, hogy DirectQuery-vel akarunk dolgozni.
Az eredeti kép megtisztított változata. A képszerkesztéshez ezúttal az ingyenes és mindentudó GIMP-et használtuk.
Ilyen lett az eredeti Scadapack kép másolata a Power BI-ban. Ha nulláról kellett volna készíteni a képet, akkor már a High Performance HMI irányelveit követve készítettük volna el.
A Node-RED egy olyan nyílt forráskódú fejlesztői környezet, amelyet azért fejlesztettek ki, hogy az IoT-zás közben felmerülő adatfeldolgozást megkönnyítsék. Hiszen miről szól az IoT? Jönnek adatok, azokkal pedig kezdenünk kell valamit (például szűrni, kalkulációt végezni velük, összevetni más adatforrásokkal), aztán a létrejövő új adatokat valahova el kell küldenünk. Ehhez a Node-RED előtt programozási, kódolási tudás kellett. A Node-RED óta viszont mindössze józan ész. A Node-RED fejlesztés jelentős részét az IBM mérnökei végzik, és az IBM hivatalosan is elkötelezte magát a projekt mellett, ami az open-source világban egy életbiztosítással ér fel. A Node-RED-es fejlesztéshez csak böngészőre van szükség, a futtatáshoz pedig - IoT alkalmazás lévén - egy Raspberry is elég, de saját szórakoztatásunkra mi a telefonunkra is feltelepítettük, és egymás lámpáját kapcsolgattuk (lásd jobbra és alább).
Ma már jobbnál jobb eszközök állnak rendelkezésünkre, ha adatgyűjtést akarunk kiépíteni. Mi három okból választottuk a Microsoft és a Moxa megoldását. Egyrészt a MOL rendkívül szigorú biztonsági követelményeket támaszt a hálózatokkal kapcsolatban. A Moxát és az Azure-t viszont már számtalanszor használták, ismerik, szeretik.
A másik ok, hogy mind a Moxa, mind a Microsoft gyors és szakmailag kiváló terméktámogatást nyújt.
A harmadik ok pedig, hogy - hála a Microsoft és a Moxa között néhány évvel ezelőtt létrejött stratégiai együttműködésnek - az UC beágyazott számítógép nagyon jól működik együtt az Azure-ral. FW-szintű támogatás van rá, részletes leírást adnak az Azure és a Moxa beállításához, és nem utolsó sorban külön intenzív tesztelésnek vetik alá az eszközöket Azure kapcsolattal beállítva.
Az eddigiekből úgy tűnhet, hogy az egész projektbe mindössze pár percet kellett ölnünk. Félrevezettem a Kedves Olvasót! A megvalósítás érdemi része (a fejlesztés) valóban nagyon hamar megvolt. Mi vitt el a sok időt? Persze, minden munka során akad szöszölős feladat is, de nem ez volt a bűnös. Hát akkor mi? Aki ismer minket, az már ki is találhatta a választ: a tervezés.
Azért rakhattuk össze ennyire pillanatok alatt, mert előtte órákon, napokon át beszélgettünk az igényekről, a lehetőségekről; végeztünk kisebb próbákat az egyes részfeladatokra, hogy a saját bőrünkön érezzük a feladatok megvalósíthatóságát. Persze rengeteget tanulmányoztuk a dokumentációt is, és hosszú órákon keresztül fárasztottuk a Microsoft műszaki támogatását (ezúton is köszönjük a segítséget)! Bár ez a rendszer nagyon pici és egyszerű, olyan architektúrát kellett kialakítani, amely a következő 30 évben stabil alapot nyújthat ahhoz, hogy a MOL világszerte beköthesse a kútjait. Ilyen rendszer megvalósításának még akkor sem szabad alapos tervezés nélkül nekilátni, ha végtelen a költségvetés. A mi esetünkben sajnos ez nem állt fenn, ezért azt is számba kellett venni, hogy már egyetlen kút bekötésénél megtérüljön a beruházás. Összességében tehát az alapos tervezésnek köszönhetjük a projekt sikerét.
Ez a történet valójában 2018-ban kezdődött. Ekkor keresett meg először a MOL egyik beszállítója, hogy dolgozzuk ki, milyen módon lenne lehetséges a meglévő adatgyűjtő rendszereket kivinni a felhőbe.
Nagyon örültünk a megkeresésnek, mert már 2 éve dolgoztunk a felhő népszerűsítésén, mégis, a kérés jól mutatja azt az általános félreértést (vagy inkább értetlenséget), amely a felhő szolgáltatásokat övezte akkoriban. A kérés ugyanis kb. így hangzott: "Hogyan lehetne megoldani felhővel, hogy a karbantartók akkor is hozzáférhessenek az üzemek adataihoz, amikor úton vannak? A már iFIX SCADA-ban meglévő adatokhoz kellene hozzáférést nyújtani. Telepítsünk iFIX SCADA-t a felhőbe, mert ott bárhonnan elérhető."
Itt jegyzem meg, hogy a MOL beszállítónak az adott körülmények között teljesen igaza volt, hogy ezt kérte tőlünk, és azóta is hálásak vagyunk, hogy minket talált meg ezzel a feladattal!
A GE iFIX SCADA egy olyan szoftver, amelyet arra találtak ki, hogy PLC-khez és egyéb valósidejű vezérlőkhöz csatlakoztassunk. A feladata, hogy összekösse a gépet és az embert. A gépek nyelvére lefordítja, amit a kezelő tenni szeretne, és az ember számára érthetővé teszi, amit a gép közölni akar. Tehát egyrészt valós időben ír és olvas a gépekből, és szintén valós időben frissíti a felhasználói felületeket. Így a gépkezelő tájékozódhat a gép állapotáról, és beavatkozhat, ha szükséges. A SCADA valós időben kommunikál a PLC-kel. valósidejű kommunikációt Interneten keresztül végezni nyűgös dolog, és elég kockázatos is. Ha van rá mód, el kell kerülni. Ha nincs rá mód, akkor kifejezetten erre készült technológiát kell használni. Az iFIX SCADA kommunikációja a gépekkel nem ilyen.
Velejéig mérnökök vagyunk, ezért már a kérdéssel sem értettünk egyet. Miért kéne iFIX-et telepíteni a felhőbe? Mit oldana ez meg?
A megoldandó probléma az, hogy az adat bent van az üzemben, a karbantartó pedig valahol a mobil interneten lóg. Tehát a (1) távoli adatokat (2) biztonságosan, kontrolláltan kell elérhetővé tenni. És valóban, az iFIX mellesleg valóban tud másik, távoli iFIX-ekhez kapcsolódni. A távoli adatelérés (1) problémáját tényleg megoldja. És valóban, bármilyen művelet köthető bejelentkezéshez, ezért a kontrollált hozzáférésre (2) is megoldás. Akkor mégis mi volt a problémánk? Erre a választ az ősi Kínában kell keresnünk.
A szúacsói herceg egyszer többnapos vadászatra indult hercegsége északi határához. Tudta, hogy neki és a kíséretének élelmet kell biztosítani addig is, amíg elejtik az első vadat. Előre küldte tehát földműveseit, hogy vessék be rizzsel az északi határ menti földeket. Tudta azt is, hogy a földművesek sem maradhatnak éhen, ezért utasította szolgáit, hogy mielőtt az északi határt felszántanák, először egynapi járásra vessenek rizst. Ácsokat is küldetett a rizsföldek mellé, hogy építsenek kunyhókat és rizstárolókat. Ezekben a kunyhóban fognak majd lakni a parasztok, és azt a rizst fogják enni, amíg még egy napi járásnyira beszántják a földeket, és ezekben a kunyhókban fognak lakni az ácsok, amíg új kunyhókat építenek még egy napi járásnyira. A kétnapi járásnyira lévő kunyhókban fognak lakni a földművesek, amíg 3 nap járásnyira újabb földet szántanak fel, és vetnek be rizzsel.
A harmadik évben, amikor már a három napnyi távolságra elvetett rizs is beérett, a herceg összeszedte kísérőit, és vállára akasztotta az íját. Kezdődhetett a vadászat!
Útközben a herceg a bölcs Csáong Mú mesterrel beszélgetett. Dicsekedett neki, hogy milyen okosan mindent megtervezett előre. Arra számított, hogy Csáong Mú megdícséri, de ő nem szólt egy szót sem.
- Miért nem szólsz semmit, Csáong Mú mester? Te is láthatod, hogy sokat tanultam tőled, előre megterveztem mindent.
- Azért nem szólok, mert szégyellem magam. Én tanítottalak. Enyém a szégyen.
- Miről beszélsz, mesterem?
- Egyszerűbb, gyorsabb, takarékosabb lett volna otthonról elvinni a rizst egy tarisznyában.
Azóta tudjuk, hogy attól még, hogy egy megoldás helyes, nem biztos, hogy jó is.
Most pedig vissza az ősi Kínából 2018-ba!
Esetünkben az iFIX Windows operációs rendszert igényelt. A Windows pedig licencet és egy virtuális gépet. A virtuális gép egy rendszergazdát.
Ahhoz, hogy a felhőben futó iFIX elérje az üzem iFIX szerverét, az üzemi tűzfalon portot kell nyitni; azaz rést a pajzson!
Tehát egy tapodtat sem vagyunk előrébb, mintha ugyanott megnyitjuk a portot, és közvetlenül mobiltelefonnal érjük el az üzemi iFIX-et. Merthogy az iFIX ezt is támogatja.
A felhő előnye nem abban rejlik, hogy kint van az Interneten, ezért bárhonnan elérhető (hiszen minden kint lehet az Interneten, ami felé portot nyitunk). Hát akkor miben?
A felhő szolgáltatásokat úgy alakították ki, hogy a legkisebb funkcionális egységtől a legnagyobbig minden elérhető legyen benne, és a mindezek mögött rejlő infrastruktúra, a szerver hardverek, switchek és szünetmentes tápok minél inkább rejtve maradjanak a fejlesztők és üzemeltetők számára.
Mit jelent a legkisebb funkcionális egység és a legnagyobb? A legnagyobb egység gyakorlatilag az előre feltelepített virtuális gép. Tehát ha szükségünk van egy linuxos virtuális gépre, amin fut egy Apache webszerver MySQL-lel, akkor azt egy kattintásra meg is kapjuk. Persze a Linux és a MySQL nem fogja patchelni magát, ezért amellé továbbra is kell valaki, aki ért a Linux üzemeltetéséhez. Nyerni pl. a rugalmasságot tudjuk, hogy egy kattintással kész. Emellett persze nem kell vesződni a hardver vásárlással és karbantartással sem.
De lehet ennél többet is nyerni! Mi lenne, ha Linux nélkül szeretnénk egy webszervert és egy MySQL-t? Lehet! A Linuxhoz, amin fut, nem férek hozzá. Cserébe nem is kell hozzáférnem, mert megcsinálják helyettem. És ez a Microsoftnak is jó, hiszen egyetlen virtuális gépen futtathat akár 1000 adatbázist is. Vagy többet. Vagy kevesebbet. Engem nem is kell, hogy érdekeljen. Úgy oldják meg, ahogy akarják, amíg garantálják, hogy az én adatbázisom megkapja a beígért erőforrásokat.
Na de akkor mi a legkisebb egység? A függvény! Ha tehát egy programozó vagyok, és csak annyit szeretnék, hogy megírhassam a létező legkisebb funkcionális egységet, a függvényt, akkor én megírom csak azt, és beállítom, hogy milyen eseményre fusson le. Ennyi. Nem kell hozzá se szerver, se semmi más.
A dolog pikantériája, hogy minél kisebb egységet használunk, annál kevesebb dologhoz kell értenünk, és mégis: annál olcsóbban kapjuk meg. A Microsoft tehát gyakorlatilag fizet nekünk azért, hogy az ő rendszergazdáik üzemeltethessék a rendszerünket.
Ennek fényében látható tehát, hogy egy iFIX-et futtatni felhőben lehet, de rettentő drága, és semmit nem nyerünk vele. Na mindegy, az ügyfélnek mindig igaza van. Akkor is, ha nincs.
Elkészítettünk egy PoC-t a megadott igényekre. Sőt, ha már őrültködtünk, kipróbáltunk több hasonló, de jobb architektúrát is:
Ennél az elrendezésnél a felhőbe egy iFIX iClientet telepítettünk, amely belelátott a helyi iFIX szerverbe. Az iFIX tabletről és telefonról a WebSpace-en keresztül, asztali gépről távoli asztali kapcsolattal (RDP) volt elérhető.
Konklúzió: megvalósítható, de semmi értelme, mert tabletről és asztali gépről is ugyanezzel a módszerrel közvetlenül is olvashatnánk a helyi szerverről. Ehhez nem az iFIX-ek közötti kommunikációhoz használt portokat kell megnyitni, hanem az WebSpace-hez és RDP-hez használtakat.
Az Ignition az iFIX-hez hasonlóan egy SCADA szoftver. Különlegessége, hogy viszonylag új fejlesztés, ezért azt már kifejezetten felhőbarátnak készítették. Kipróbáltuk tehát, hogy tényleg annyira kezes-e, mint ahogy azt ígérik.
Konklúzió:
Ha SCADA-t kell telepítenünk a felhőbe, és van választásunk, akkor inkább az Ignitiont ajánlanánk, mert sokkal kisebb költséggel lehet üzemeltetni.
Alapvetően nem értünk egyet azzal, hogy SCADA-t a felhőben futtassunk, hiszen ez egy gépközeli szoftver. Logikusabb csak az adatokat felküldeni. Ezekből az adatokból azután táplálhatunk mobil appot, web appot vagy kiszolgálhat akár komplett adatelemző platformokat.
Az OPC szerver képes beleolvasni a helyi iFIX-es rendszerbe, és azokat OPC protokollon bármilyen kliens ki tudja olvasni. Erre alkalmas lehet egy mobil app vagy egy sima weboldal is.
Konklúzió:
Ez is megvalósítható, de ugyancsak felesleges, hiszen ugyanezeket az adatokat tudjuk közvetlenül a helyi hálóról is az Internet felé elérhetővé tenni, ugyanúgy port nyitással.
A másik probléma, hogy az OPC is gépközeli szoftver. A gépekkel egy hálózaton van a helye.
Az MQTT nagyon hasonlít az OPC-hez. Mindkettő valósidejű kommunikációra használható protokoll. Van viszont pár különbség, amely mégis alkalmassá teszi arra, hogy felhőben futtassuk az MQTT brokert (a broker az OPC szerver megfelelője).
Egyrészt instabil hálózati kapcsolatra tervezték, ezért jobban tűri, ha szakadozik az Internet az üzem és a felhő között. De van egy különbség, amely még ennél is fontosabb: a kapcsolatot a terepi eszköz és a broker között a terepi eszköz kezdeményezi. Miért fontos ez? Azért, mert nem kell az Internet felől az üzem felé portot nyitni. Ez óriási különbség, hiszen úgy lehet kommunikálni kifelé, hogy nem adunk a hackereknek támadási felületet a tűzfalon.
Kipróbáltuk hát a Chariot brokert. Ezt telepítenünk sem kellett, hiszen az Opto22[https://opto22.com] jóvoltából hozzáférésünk van egyhez. Csak azt a problémát kellett áthidalni, hogy az iFIX akkor még nem ismerte az MQTT protokollt. Ehhez az Opto22 csodaeszközét használtuk fel, a groov EPIC-et. Ennek a csodának az egyik fele egy PLC, a másik fele egy Linux szerver. Ebben az esetben csak a Linux oldalt vettük igénybe, kihasználva, hogy bele van építve gyárilag az OPC szerver és az MQTT kliens is. Könnyen tudtuk kiolvasni az adatokat OPC-vel iFIX-ből, és tudtuk továbbküldeni a felhőbe MQTT-vel.
Konklúzió:
Ezzel az architektúrával már közel jártunk az ideálishoz. Hiányossága, hogy az MQTT csak valósidejű adatokhoz használható. Kéne mellé még egy adatbázis is, amely kiolvassa és letárolja az adatokat.
Próbára tettük a felhőben a GE Historian nevű programját, amely idősorokat tárol nagyon jó hatékonysággal. A Historiannak van egy adattovábbítási üzemmódja, a Server-to-Server collector.. Ez pont arra való, amire mi akartuk használni: a helyi Historianből az adatok másolatát toltuk fel a felhőben futó Historianra.
Konklúzió:
Bár a Historian nagyon jól használható program idősorok tárolására, akkor még teljes windowsos virtuális gépet igényelt (időközben megjelent a Historian for Linux), ezért nem ez volt a legköltséghatékonyabb megoldás adattárolásra a felhőben. Jobban jártunk az MQTT-vel és egy felhőre optimalizált noSQL-lel.
Még mindig adott tehát a probléma, hogy ne csak valós-időben legyenek elérhetők az adatok a felhőben, hanem le is legyenek ott tárolva. Szerencsére a GE-nek van egy eszköze éppen erre. A Predix egy Azure-ban futó automatizálási platform. Gyorsan, egyszerűen és rendkívül költséghatékonyan lehet vele felküldeni az adatokat, és azokat változatos módszerekkel lehet visszaolvasni.
Konklúzió:
Pont, amit el akartunk érni: az üzleti logika az üzemben fut, az adatok viszont biztonságos csatornán kerülnek az Azure-ba. Tárolni is tudjuk, és könnyen felhasználhatjuk a céljainkra. Azért nem Predixet használtunk végül, mert a feladat most egyrészt annyira egyszerű volt, hogy a Predix ágyú lett volna a verébre irányítva, másrészt a Predixet a MOL még nem használja, ezért lelassította volna a bevezetést, ha meg kell várni az IT csapat jóváhagyását.
Nagyon jót szórakoztunk a fenti feladatok átbeszélésekor és megvalósításakor. Szeretjük az újdonságokat és a határterületeket. Mindkettőből akadt bőven. Rengeteg tapasztalatot szereztünk. Mindenkinek ajánljuk, hogy használja ki az Azure-ban kapható ingyenes kezdőcsomagot, és kísérletezzen önfeledten!
Bár a blogbejegyzést én írtam, a háttérmunka jelentős részét kollégáim és a Microsoft támogató csapata végezte. Hatalmas köszönet nekik érte!
A cikk megjelent a GyártásTrend oldalán is.