Kutatás + fejlesztés - 3. rész: ipari teljesítmény mutatószám monitorozása valós időben

Attila | 2022. 05. 16. 18:20 | Olvasási idő: 4 perc

Címkék: #Chart.js #Digitalizáció (Digitalization) #Integráció (Integration) #IoT (Internet of Things) #Ipar 4.0 (Industry 4.0) #Kutatás (Research) #Laravel #Microsoft SQL #SPA #Társadalmasítás #ÚNKP #Üzleti Intelligencia (Business Intelligence)

A Laravel nem csak egy népszerű, sok látogatóval rendelkező weboldal alapját tudja adni, hanem egy céges belső használat esetén egy drága üzleti intelligencia (adatelemző, adatmegjelenítő) rendszert is tud "helyettesíteni". Ebben a bejegyzésben bemutatok egy olyan ipari fejlesztést, amely egy olyan mutatószámot monitoroz, amely a gyártósor mellett dolgozókat képes tájékoztatni az aktuális teljesítményükről és jelez nekik, ha valami nem megfelelő.
k+f-03

Általános cél: a gyártósori dolgozók figyeljenek oda a munkájukra, kevesebb veszteséges működést produkáljanak. Fejlődjenek energiahatékonyság szempontjából, ezáltal a vállalatnak kevesebb veszteséget termeljenek. - a rendszerrel "Energiatudatosságra nevelünk."

Az általános cél elérése a következők miatt fontos: „Megfelelés az ISO 50001-es ipari szabványnak: Valós idejű eredmény- és teljesítménykövetés. Célkitűzés: közel valós időben látszódjanak az operátor gépeknél a hatékonysági arányszámok (kWh / m2). Az alkalmazás folyamatosan mutassa a friss teljesítmény mutatószámot az operátor gépénél és még jelez is neki, ha nem teljesít megfelelően (például: le kellene kapcsolnia a gépet, mert nem termel rajta).”

A fenti célokat határoztuk meg munkánk kezdetén, ezt a projektet fogom ismertetni a blogbejegyzésben. Ismét energiahatékonyságról fogok írni egy termelő vállalatnál: bútort gyártanak, úgyhogy a villamosenergia fogyasztási adatokat a gyártott bútordarab alapanyagok négyzetméter mennyiségére vetítve kell értelmeznünk.

Mindenekelőtt lássuk az alkalmazással szemben támasztott funkcionális követelményeket:

  • A webes alkalmazás egy adatmegjelenítő felületet biztosít a gyárban dolgozók számára.
  • A célfelhasználók köre több részre oszlik:
    1. A termelésben dolgozó operátor közel valós időben tudja majd látni a teljesítmény mutatószámokat az aktuálisan használt termelő gépéről, és kapjon visszaigazolást munkája hatékonyságáról;
    2. A termelést menedzselő személyek is képesek legyenek nyomon követni a mutatószám alakulását bármelyik termelő gép kapcsán;
    3. A gyár közösségi tereiben is el tudunk helyezni olyan kijelzőket (nagy tv vagy monitor), amely a látogatók számára mutatja, hogy milyen hatékonysággal dolgoznak például a legnagyobb igénybevétellel működő gépeknél. Ennek jelentőségéről ez a bejegyzés sorozat szól Kővári Attila elismert BI (Business Intelligence, Üzleti Intelligencia) szakértő blogjában.
  • Funkcionális oldalon fontos meghatározás még, hogy ha huzamosabb ideig (paraméterezhető) pazarlóan működik az adott termelő gép, akkor módosuljon a webalkalmazás kinézete és figyelmeztesse erre a felhasználóját, hogy a pazarló működést szüntesse be.

Technológiai oldalról is számos követelménynek kellett megfelelni:

  • Szoftveresen "bolondbiztosnak" (poka-yoke, lásd a Toyota Termelési Rendszert és a Lean menedzsmentet) kellett elkészíteni az alkalmazást, hogy az operátorok ne tudjanak véletlenül vagy szándékosan beleavatkozni a működésébe, ne tudják esetleg szabotálni a monitorozást. Az alkalmazás indulásakor egy bejelentkezési felület segítségével lehet azonosítani, hogy melyik termelő gép teljesítményét szeretnénk nyomon követni.
  • Mivel ez egy "önkiszolgáló" üzleti intelligencia (adatmegjelenítő) eszköz, ezért a másik fontos elvárás volt vele kapcsolatban, hogy különböző adatforrásokhoz közel valós időben tudjon csatlakozni és tőlük adatot lekérni. Jelen projektben az adatok két forrásból érkeznek:
    1. A cég vállalatirányítási rendszerének alapját képező Microsoft SQL Server alapú adatbázisból.
    2. Az általam és a cég kulcsfelhasználói által kialakított keretrendszer adatrétegéből, amely a gyár által használt erőforrások felhasználásait gyűjti és tárolja el (ide tartoznak a következők: villamosenergia, víz, termelt sűrített levegő, elszívott levegő stb., ebben a projektben most ezek közül a villamosenergia fogyasztásokra koncentrálunk). Ez szintén egy Microsoft SQL Server alapú adatbázisban van, amelyből ki kell nyerni a webes alkalmazás számára az adatokat.
  • Az imént felsorolt adatbázisok elérését biztosítani kell a webes alkalmazás számára, olvasási jogosultsággal férek ezekhez hozzá.
  • Emellett mindig fókuszálnunk kell arra a projektekben, hogy olyan rendszereket használjunk, amivel rendelkezik a vállalat, vagy pedig ha nincs nekik valamilyen szoftver, akkor ingyenes megoldással helyettesítsük.


Tervezés: rendszerelemek

A jobb átláthatóság miatt a fenti követelményeket számításba véve megterveztem azt az integrált keretrendszert, amelynek elemeivel megvalósítható a feladat és elérhetjük a kitűzött célokat.

Legalul helyezkednek el a Microsoft SQL Server alapú adatbázisok. A villamosenergia fogyasztásokat tartalmazó adatbázist a szenzoros mérések automatikusan töltik fel, ugyanígy a termelési adatok pedig a gyártó gépektől szintén érkeznek be automatikusan. Az adatok beérkezésének az intenzitása viszont eltérő: amíg friss energiafogyasztási adatokat 10 percenként mérünk (így van értelme), addig termelési adatok rendszertelenül érkeznek be. Ahhoz, hogy össze lehessen vetni a két adatsort 10 perces szakaszokban összegezzük a termelési számokat és így rendeljük mellé a fogyasztási értékeket.

A Backend részen elhelyezkedő Laravel biztosítja nekünk a webalkalmazás hátterét, úgy mint az adateléréseket, a felhasználói (gyakorlatilag termelő gép) azonosítást, a beérkező felhasználói kérések kiszolgálását, az üzleti logikát (adatkalkulációkat) stb.

Az Inertia JS látja el a közvetítő szerepét a Frontend-Backend részek között. Ennek segítségével tud egyszerűen kommunikálni egymással az alatta és felette lévő két réteg. Így egy hatékony SPA-t (Single Page Application-t) tudunk létrehozni és működtetni. (Megjegyzés: terveim szerint az Inertia JS-ről fogunk még tanulni a blogom bővítése során, mint ahogy a mindjárt említésre kerülő Vue.js-ről is.)

Kliens oldalon a Chart.js osztálykönyvtár segíti a munkámat, a Vue.js keretrendszerrel együtt. A Chart.js használatát már az előző Kutatás+Fejlesztésről szóló blogbejegyzésemben is ismertettük és használtuk. Talán ha nagyon röviden kellene ismertetnem, akkor azt mondanám, hogy ennek segítségével interaktív diagramokat (oszlop, vonal, kör stb.) tudunk létrehozni valós időben. Az osztálykönyvtár folyamatosan bővül, ezáltal egyre többmindenre leszünk képesek általa, de ha az alapfunkcionalitások nem lennének elegendőek, akkor még léteznek hozzá bővítő modulok (plugin-ok) is. Ezeket használom én is ebben a projektben azért, hogy a diagramomat valós időben tudjam frissíteni (streaming), felcímkézni az adatokat a diagramon (datalabels) és ilyen vonaldiagram esetén küszöbértéket is tudunk beállítani (annotation). Mindezeket természetesen programozottan tudjuk megtenni kliens oldalon, amelyhez a Vue.js keretrendszer komponens alapú fejlesztési technikái segítenek minket. Talán egy példa részlet tud a legbeszédesebb lenni azzal kapcsolatban, amit működésre szeretnénk bírni az alkalmazásunkban:

Ugye?

Az alkalmazás megvalósításának részleteibe ennél mélyebben nem szeretnék belemenni, inkább szemléltetem és magyarázatokkal látom el az általános működését.

Itt látható a bejelentkezési felület. Ahogy említettem az alkalmazás futtatása egy szerveren történik, amelyhez belső hálózaton keresztül a vállalaton belül bármelyik gép hozzá tud férni. Egy azonosítás szükséges ahhoz, hogy melyik termelő gép hatékonyságáról szeretnénk közel valós idejű képet kapni:

A gépneveket és a hozzájuk tartozó jelszavakat csak az arra jogosult személyek ismerik. Fontosnak tartottam, hogy ne egy új jogosultsági rendszert alakítsak ki, amit újra csak meg kell jegyezni, fel kell "írni" egy jelszavakat tartalmazó fájlba. Hanem olyan neveket és jelszavakat használjak, amelyek a két érintett adatbázisból (fogyasztások és termelések) tudhatók, ellenben a gépnél dolgozó operátorok nem ismerik őket.

A kezdőoldal kinézete abszolút egyszerű és letisztult, mivel itt nem a minél szebb megvalósítás volt a lényeg, hiszen egy operátornak majd a lényeget kell látnia, nem szabad, hogy elterelje a figyelmüket bármiféle design elem. A szürkeség sem véletlen, hiszen ez egy közömbös szín, viszont a későbbiekben a színeket többletjelentéssel ruházzuk fel, így azok fontosak lesznek a használat során.

Említettem, hogy közel valós időben működik az alkalmazás, ami azt jelenti, hogy a bejelentkezés után egy termelő géphez 10 percenként érkezik valós teljesítmény mutatószám, itt azonban én most a példa kedvéért felgyorsítottam ezt a folyamatot és néhány másodpercenként generálok példaadatot, hogy látható legyen az alkalmazás példa működése. Elindítok tehát egy példafuttatást, példaadatokkal, amelyek képesek szemléltetni hatékony és veszteséges működést is. Kezdjük a hatékonnyal:

A termelő gép nevét kitakartam. A hatékonysági arányszámokra 1-5 közötti véletlenszerű (random) értékeket generálok 5 másodpercenként. A limitet a példa kedvéért 2.5-re állítottam be. Látható, hogy voltunk a limit alatt is, de ha a legutóbbi mért értékek megfelelőek, az kWh/m2 arányszám elfogadható, akkor nincsen különösebb dolga a gépet üzemeltető operátornak. A következő ábrán már egy pazarlóbb működést látunk (átállítottam a véletlen szám generálást 1-3 közé):

Az operátor itt már az alkalmazás háttérszínéből láthatja, hogy pazarlóan működteti a termelő gépét, szükséges lehet a beavatkozás.

Az utolsó ábránkon pedig az látszódik, hogy a legutóbbi mért értékek mind a limit alatt voltak, így mindenképpen be kell avatkozni a működésbe. A beavatkozás lehet a gép készenléti állapotba helyezése vagy leállítása, esetleg a termelés megkezdése, ha lehetséges.

Itt a piros háttérszín mellett egy üzenetet is kap az operátor, ami figyelmezteti a pazarló működésre. Én egy küszöbértéket definiáltam (konkrétan a hármat), ami azt jelenti, hogy 3 limit alatti mért értékekből adódó mutatószámot "elfogad még", tehát csak sárga lesz a háttérszín, de ha utána is limit alatti érték érkezik, akkor már pirosra vált és megjelenik a figyelmeztető üzenet is.

Ha a gép pazarló működése visszatér az elfogadható, limit feletti szintre, akkor automatikusan visszaállunk az alapállapotra és már nem kap figyelmeztetést az operátor:

Ahogy a bejegyzés elején említettem, a vállalat célja az volt a projekttel, hogy megpróbálja energiatudatosságra nevelni, így elérve a hatékony, kevesebb energia veszteséggel járó működést. Ezen felül a további felhasználói csoportok (menedzserek) is profitálnak a fejlesztésből. Nem utolsó sorban pedig a cég egy korábbi elvárásnak is meg tud így már felelni az ISO-50001-es auditálás során.

A fejlesztésekhez a legkorszerűbb, legújabban elérhető webes technológiákat használtam fel. Emellett a megvalósításhoz csak ingyenesen elérhető osztálykönyvtárakat, program komponenseket alkalmaztam (az adatbáziskezelő már korábban rendelkezésre állt), így nem volt szükség drága üzleti intelligencia rendszerre, hanem egy "önkiszolgáló" megoldás működik valós időben a vállalat gépein.


Együttműködés, köszönetnyilvánítás

A kutatást természetesen nem egyedül végeztem. Munkám során a vállalat szakembereivel mindig együttműködve haladtam a megoldás felé, míg kutatási szempontból Koncz Adrienn doktorandusz hallgatómmal együttesen tevékenykedtem.