Az értesítési funkció (alerting) a termelésfelügyeleti rendszerek alapvető funkciójává vált. Egyre szélesebb körben elterjedt követelmény, hogy a gyártási adatok elemzése, értelmezése és közlése, illetve az esetleges reakció ma már közel valós időben történjen, hiszen az idő pénz – pláne, ha egy gyárról van szó!
„Az információ latin eredetű szó, amely értesülést, hírt, üzenetet, tájékoztatást jelent. (…) Az információ önmagában értéket képvisel, ez lehet társadalmi, tudományos, termelési – gazdasági vagy akár hatalmi érték. Az információval képesek vagyunk egy meglévő értéket növelni, így értéknövelő. Mivel értéket képvisel, így profitot, illetve extraprofitot is termelhet. Jellemző tulajdonsága még a mennyisége, minősége, felhasználhatósága, hozzáférhetősége, érthetősége, védelme.” – Wikipedia
Amint azt a közismert online lexikon is összefoglalja, a jó minőségű információk segítségével gazdasági előnyhöz juthatunk – akár a gyártás során is.
Minél részletesebb információval rendelkezünk a folyamatunk minden részletéről, annál nagyobb felbontással lehet annak rendellenességeit elemezni és azokra a szükséges válaszokat kidolgozni.
Mára az IIoT és az ipar4.0, mint technológiai-innovációs irányzatok, éppen erre a megközelítésre alapozva köteleztek el maguk mellett gyártó cégeket és megoldásszállítókat egyaránt. De vajon elég önmagában a tény, hogy elengedő mennyiségű, minőségű, felhasználható, hozzáférhető, érthető és védett információt birtoklunk?
Az idő pénz – pláne egy gyárban
Az IT térhódításával az információ alapvető tulajdonságai mellett megjelent egy újabb dimenzió: a sebesség. Mindent tudni szeretnénk, és lehetőség szerint azonnal. Az idő pénz – pláne, ha egy gyárba belépünk! Rengeteg példával lehetne élni, hogy milyen szektorban, milyen volumen mellett, mennyi idő alatt, mennyi veszteség képződhet valamilyen anomália miatt, de egy átlagos autógyárban ez a metrika nagyságrendileg több millió HUF/perc (hiszen ennyi idő alatt körülbelül le is gurul(na) egy új jármű a gyártósorról). Arról már nem is beszélve, hogy például egy erőmű esetében az információáramlás hiánya vagy lassúsága akár környezeti és biológiai katasztrófákat is okozhat… Nem is kérdés, hogy
releváns eseménynél a szükséges területeket, személyeket azonnal informálni kell a történtekről.
Az ilyen kihívásokra választ nyújtó, ún. értesítési rendszerek a mi értelmezésünkben a termelésfelügyeleti platformok elengedhetetlen funkciói (mely természetesen a WaMeWo-ban is megtalálható).
Az értesítési rendszerek működésének alapvető feltételei:
- legyenek már digitálisan gyűjtött adataink,
- azokon végezzünk aggregációkat
- és egy mögöttes rendszer „eseményekkel tudja etetni” az értesítési réteget.
Tételezzük fel, hogy ezekkel rendelkezünk!
Az értesítési rendszer tényleges működése sokféle lehet, de jellemzően az alábbi láncolatból áll:
Riasztási szabályok
Első lépésben definiálnunk kell a riasztási szabályokat, amelyekről úgy gondoljuk, hogy számunkra hírértékkel bírnak, és azok bekövetkezéséről mindenképp a lehető leggyorsabban informálódni szeretnénk. A riasztási szabály egy vagy több lekérdezésből és kifejezésből, egy feltételből, az értékelés gyakoriságából és opcionálisan abból az időtartamból áll, amely alatt a feltétel teljesül.
Néhány tipikus példa ilyen jellegű eseményekre:
- Jelváltozás figyelése (trigger): megadott bit szintű esemény bekövetkezése esetén (például egy szenzor bekapcsol a gyártósoron) azonnali riasztást kérünk. Ennek lehet idővel paraméterezett módja is, amikor megadjuk, hogy a jel X mp-ig tartó fennállását követően kérünk riasztást.
- Diszkrét érték figyelése, összehasonlítása: megfigyelhetjük bizonyos változók numerikus értékét is, és amennyiben az a beállított határértéket átlépi, akkor arról riasztást generálhatunk. Ennek a megfigyelésnek egyik tipizált verziója, amikor egy nominális érték és egy megfigyelt érték egyenlőségét monitorozzuk (például, hogy egy hegesztőrobot megfelelő beállításokkal hegeszt-e).
- Beállított trend figyelése, torzulása: ebben a megfigyelésben nem a határértékeket definiáljuk előre, amelyek között normál esetben az értékek mozoghatnak, hanem a normál működés során jelentkező trendeket rögzítjük (milyen ciklikussággal, milyen értékek jellemzőek stb.) és az ebben megjelenő torzulásokat igyekszünk detektálni.
- Események sorozatos előfordulása: bizonyos jelzések, figyelmeztetések egyszeri bekövetkezése önmagában nem mindig üti meg az ingerküszöböt, viszont, ha azok egymás után sorozatban jelentkeznek, utalhatnak egy leendő hibára, amely komolyabb megállást is okozhat a későbbiekben. Ezek megelőzésére tetszőlegesen paraméterezett számú események (gépből nyert üzenet, vagy állásidő) előfordulására is feliratkozhatunk.
- Helyreállás: legtöbb esetben a normál állapottól való eltérést tekintjük „incidensnek”, amelyről tudni szeretnénk. Van lehetőség viszont az OK állapotba visszatérést is riasztásként konfigurálnunk, azaz ha a korábbi anomália helyreáll, arról is kérhetünk értesítést.
- Emlékeztető: az időben beütemezett bizonyos feladatokhoz kérhetünk emlékeztetőt, így például ha egy karbantartási eseményre a holnapi napon sort kell keríteni, emlékeztetheti a karbantartókat, akik számára a feladatot delegálták.
- Riportok: nem tipikus riasztási szabály, de jellemző igény például a termelés részéről, amikor műszakok végén olyan automatikus hatékonysági (OEE és részletei) riport készül az egyes gépekről, amely nemcsak az alkalmazás felhasználói felületén tekinthető meg, hanem azt a rendszer e-mailben is eljuttatja (XLSX, PDF formátumban) a feliratkozott felhasználóknak.
Súlyosság
A WaMeWo-ban jelenleg, a leggyakoribb ügyféligényekhez igazodva, 4 szinten definiálhatjuk a súlyosságot az egyes riasztási szabályokhoz:
- hiba
- figyelmeztetés
- info
- ok
Ez a 4 szint segít az értesítések hisztorikus áttekintésében aszerint, hogy saját preferenciáink alapján melyik esemény milyen mértékben kritikus számunkra.
Értesítés módja
Végül, de nem utolsósorban a feliratkozás során megadhatjuk, hogy az egyes értesítésekről (mely típusonként konfigurálható) milyen csatornán szeretnénk üzenetet kapni. Ennek számos módja lehet az üzenet méretétől, tartalmától, valamint attól függően, hogy milyen a felhasználói környezet, azaz hálózati lefedettség várható az alkalmazás és a végfelhasználó között).
Jelenleg az alábbi három a leginkább elterjedt:
- Alkalmazásban: miközben meg van nyitva a felhasználói felület a böngészőnkben, lehetséges ezen belül különböző vizuális megoldásokkal felhívni a felhasználó figyelmét a bekövetkezett eseményekre. Ezek a sémák az utóbbi években közösségi oldalakon forrtak ki. Az alkalmazás tetején egy ikon jelzi, ha új esemény következett be, és azok közül a legutóbbiak ki is listázódnak az ikonra kattintva. Ezen kívül súlyosság szerint színezett felugró címkéket is megjeleníthetünk bármelyik oldalon, attól függetlenül, hogy a felhasználó épp melyik menüpontban van, és ahhoz képest melyik funkcionalitást érinti a riasztás.
- Chat: a kifejezetten mobilra fejlesztett alkalmazások többségre tud ún. push értesítést küldeni, amelyek a mobiltelefonunkon rendszerszinten képesek megjelenni. Amennyiben a mobilapp nem elérhető, úgy megannyi lehetőség létezik már arra, hogy közkedvelt (pl. Viber) csevegő alkalmazásokba egy API-n keresztül értesítést küldjünk, így extra alkalmazás fejlesztése, telepítése nem szükséges.
- E-mail: a legközkedveltebb értesítési formátum, amelyhez csupán egy (többnyire meglévő) e-mail szerver kell. Előnye, hogy a szükséges infrastruktúra szinte mindenhol adott hozzá a világon, valamint akár hosszabb üzeneteket, nagyobb file-okat (riportokat) is célba juttathatunk így.
Útravaló jótanács: információból se túl sokat, se túl keveset!
Egy jól konfigurált értesítési rendszer patikamérlegen kimért mennyiségű információt kell, hogy szállítson, méghozzá jó minőségben. Első fellángolásban a legtöbb felhasználó szeret mindenre (is) feliratkozni, a legapróbb eseményekről is értesítést kapni… Miért nem jó ez? Ha a felhasználó számára özönvíz módjára, (főképp egy nagyobb gyárban, sok géppel) tömegesen érkeznek irreleváns értesítések, azok könnyen idegesítővé válhatnak. Ilyenkor válik kritikussá annak a kockázata, hogy a felhasználó némítja az értesítéseket, vagy akár le is iratkozik róluk, s így később fontos történésekről maradhat le.
Igyekezzünk tehát minden olyan eshetőséget előre átgondolni, ami a gyártásunk zavartalansága szempontjából kritikus lehet, és azokra készítsünk szabályokat! Emellett fontoljuk meg, ezek közül melyik esemény milyen súllyal bír, valamint vegyük figyelembe személyes tájékozódási preferenciáinkat is, és aszerint iratkozzunk fel a számunkra legkomfortosabb csatornákra.
Ami viszont a legfontosabb: a kapott információk alapján cselekedjünk helyesen!
Miről szól ez a cikksorozat?
Cikksorozatunkat szakmai- és üzleti know-how szomjoltásra egyaránt ajánljuk az ipari szektor digitalizációjával foglalkozó szakemberei számára. A fejezetek tartalmának összeállításakor két vezérelvünk volt:
- feltárni a felhasznált gyártásdigitalizációs szoftvertechnológiák miértjeit
- és bemutatni azok üzleti hasznosulásának lehetőségeit.
Bízunk benne, hogy tartalmaink építő szakmai diskurzust váltanak ki. Az info@indeveyes.com-on vagy közösségi felületeinken örömmel veszünk visszajelzést, véleményt, vagy kérdéseket a témával kapcsolatban!
- A sorozat előző cikkében az Robotdiagnosztikáról írtunk.
- Következő cikkünkben az IIoT eszközökről, mint gyártási minőségfelügyeleti eszközökről lesz szó.
