hirdetés
hirdetés

Gyártási termelékenység

OEE-mérés – az ipar 4.0 előszobája (2. rész)

Az OEE-mutató (Overall Equipment Effectiveness) jelentősége nem csak abban áll, hogy a termelő berendezésekről, gépekről, folyamatokról információt lehet összegyűjteni és megjeleníteni. A valós idejű OEE-mérés gyakran az ipar 4.0 felé vezető út első lépésének is tekinthető amiatt, hogy – a többi alkalmazáshoz képest legalábbis – könnyen érthető minden fél számára, jól mérhető a megtérülése és egyszerűen megoldható informatikai feladat. Cikkünk második részében Bóna Péter, a Com-Forth Kft. ügyvezetője elmondja, mikor van értelme az OEE-mutatónak és milyen elvárásoknak kell megfelelnie egy jó OEE-rendszernek. 

hirdetés

Az OEE a gyártási termelékenységre vonatkozó mutató, mely egyszerűen jeleníti meg a valóban hatékony gyártási idő hányadát. Cikkünk első részében többek között beszámoltunk arról, hogy mi is a valós idejű OEE-mérés, hogyan számoljuk azt, illetve mi számít OEE-mutatónak. Most további hasznos tudnivalókkal folytatjuk. 

Mikor van az OEE-mutatónak értelme?

Az OEE-mutató önmagában nem jelent semmit. Értelmet akkor nyer, ha a mélyére ásunk, megpróbáljuk beazonosítani a szokatlan eseteket, anomáliákat, gyártási veszteségeket. Például, ha szokatlanul megugrik a selejtek száma egy adott gépen, ahol egyébként nem szokott, vagy egy műszakban többször is leállt az a gép, amire korábban ez nem volt jellemző. De az is megfigyelhető, ha csúcsra akarják járatni a gépet, mert be akarnak hozni egy lemaradást a tervekhez képest. Ilyen esetekben a szoftveres megoldásoktól minimális elvárás, hogy riasztásokat küldjön e-mailben vagy más formában. Vagy ha pl. a leállások vagy a selejtek darabszáma vagy időtartama elért egy adott értéket, akkor arról kapjon egy riasztást a műszakvezető, amit lehet eszkalálni is, ha a műszakvezető nem nyugtázza a riasztást, illetve ha a helyzet drámaivá fokozódik. Ugyanígy gyorsan rá lehet szűrni az olyan esetekre, amikor 100% feletti volt a futásteljesítmény. Volt olyan partnerünk, ahol a 7,5 órás műszak lényegében kb. 6 órát tartott, ez alatt legyártották a betervezett mennyiséget, majd a "jól" végzett munka után egyéb tevékenységeket végeztek üzemen belül. Ez nem derült ki addig, amíg a kockás füzetben vezették az állásokat és a selejteket.

Bóna Péter az OEE-ről ad elő
Bóna Péter az OEE-ről ad elő

Amire reményeink szerint senki nem használja az OEE mutatót...

  • Az üzemvezető vagy gyárigazgató lobogtatja a zöld zónában lévő OEE-mutatót egy meetingen / a központnak / bárkinek. Ez adott esetben tud fontos lenni a belső politikai játszmák miatt, ugyanakkor ettől nem fog senki eredményesebben gyártani.
  • Átalakítjuk az elméleti maximális rendelkezésre állási időt / kiveszünk vagy hozzárakunk a rendszerhez gépet / máshogy számoljuk a tervezett leállásokat annak érdekében, hogy jobban nézzen ki a helyzet, azaz a mutatót növeljük, de tartalom nincs mögötte, csak a kalkuláció módja változott.

Alapvető elvárások egy modern OEE-rendszerrel szemben

Egy modern OEE-rendszer valós idejű adatokon alapul. Ezek az adatok feldolgozásra kerülnek, és nagyon egyszerűen és átláthatóan megjeleníthető a lényeg azon a felületen, amely a felhasználó számára a legkönnyebben elérhető. Itt jön képbe a UX (User Experience), azaz a felhasználói élmény. Sokáig az iparban mostoha gyerek volt, amelynek oka, hogy a kezelők rá vannak kényszerítve a rendszer használatára, nem dönthetnek úgy, hogy egy másik, ergonómikusabb rendszerrel dolgoznak. Mára viszont az y generáció jelentős részt képvisel a döntéshozói (vezetői vagy akár tulajdonosi) szegmensben is. Ők már belátják, hogy a jó UX hatékonyabb munkát és kevesebb hibát eredményez.

Egy OEE-rendszer felépítése

Egy OEE rendszer az alábbi elemekből épül fel:

  • Connectivity – az adatkapcsolat kiépítése. Ideális esetben a PLC-kből lehet gyűjteni közvetlenül az adatokat, hiszen a vezérlőkben általában elérhető minden adat, amire szükségünk van (állások, azok típusai, okai, selejtek kategóriái, okai, termék számláló stb.). Természetesen van, amikor ez nem kivitelezhető, és ekkor félautomata hibrid megoldásokkal is lehet dolgozni, például szenzoradatból érkezik a leállás vagy a selejt ténye, de az operátor egy helyi kijelzőn vagy tableten kategorizál, illetve adja meg az okokat. Ez kvázi valós idejű megoldás, és nagyságrendekkel jobb, mint papírra felírni, aztán átmásolni Excel táblába, de azért a direkt PLC-kapcsolat az igazi.
    Ez a legnagyobb kihívást jelentő rész, hiszen egy tipikus gyárban a PLC-k teljesen eltérő korúak (a legfiatalabb 1 éves, a legidősebb pedig 40), eltérő gyártmányúak, eltérő vezérléssel rendelkeznek (Siemens, Omron, GE Fanuc, Allen-Bradley stb., vagy valamilyen egyedi) és eltérő protokollon kommunikálnak (Modbus, Profibus, Profinet, EtherNet/IP, DeviceNet, stb.). Itt a kihívásokat növeli, ha például egy új gép esetében még a garanciális időn belül szeretnénk elkérni a gépgyártótól a hozzáférést a gépi adatokhoz – ilyenkor meglehetősen borsos áron juthatunk ezekhez hozzá. Ha viszont szeretnénk emiatt néhány szenzort felszerelni a gépre, az pedig könnyen garanciavesztéssel járhat. Ugyanakkor a tapasztalat azt mutatja, hogy kellő szakértelem, rutin, kitartás és némi kapcsolatrendszer általában segít abban, hogy kihozzuk az adott helyzetből a legtöbbet.
  • A hálózat: valahogy el kell juttatni az adatokat a központi számítógépre, vagy a felhő-alapú platform számára, ahol az adatfeldolgozás történik. Ez sajnos általában adottság, és az esetek túlnyomó többségében egy másik divízió (IT, OT) ettől a feladattól teljesen független projektje. Jó hír, hogy egy OEE-mérőrendszernek nincsenek nagy IT igényei. Kis adatmennyiségről beszélünk, nem gond, ha van némi késleltetés, és még kisebb mértékű adatvesztésbe sem halunk bele. Ugyanakkor – ha másért nem, a további MES-modulok és az ipar 4.0 felé vezető további lépések miatt is – érdemes egy megbízható, üzemi körülményekre és a mérnök kollégák számára tervezett, ipari kivitelű hálózati eszközökből álló infrastruktúrát kiépíteni.
  • Innentől a szoftveres adatfeldolgozást és -vizualizációt tekintve már számtalan megoldás létezik a piacon. Ez talán az az ok, ami miatt nehéz helyzetbe kerül a felhasználó, amikor választania kell a megoldások közül. Amit ugyanis meg tud tekinteni valamilyen prezentáció vagy élő demó formájában, az a UI (User Interface). Ezt látja, és erről tudja eldönteni, hogy tetszik vagy sem, látja-e a kívánt információt vagy sem. A motorháztető alá azonban a tárgyalás során nagyon ritkán van lehetőség betekinteni.
    OEE-hez UI-t sokan tudnak mutatni, számtalan megoldás létezik rá, és bár fontos eleme a rendszernek, maga a kihívás nem itt rejlik, hanem az adatkapcsolat kiépítésében.

Mire érdemes odafigyelni egy OEE-mérőrendszer kiválasztásakor?

Tíz évvel ezelőtt a megbeszéléseket még úgy kellett kezdeni, hogy elmeséltük, hogy mire jó az OEE, és hogy miért jobb az automatikus adatgyűjtés, mint a papír alapú. Ma már ez általában fel sem merül kérdésként, mindenki tisztában van vele. Ugyanakkor az elérhető megoldások száma is igen szerteágazó, és a ma már igen széles kínálatból fontosnak tartjuk néhány elemre felhívni a figyelmet.

Lerakunk egy szenzort, és már megy is az OEE!

Ha nincs lehetőség direkt PLC kapcsolatra vagy az operátor mellé helyezett adatbeviteli kijelzőre, akkor már azzal is szép eredményeket tudunk elérni, ha lerakunk egy szenzort, amivel az áll/megy jeleket le tudjuk kérdezni, és ebből már tudunk rendelkezésre állást és ciklusidőket számolni. Ez több, mint a semmi, de ez még nem OEE, hiszen nem tudjuk, épp melyik terméket gyártjuk, nem tudjuk kiszűrni az indulás utáni próbagyártást, a selejteket, az újramunkálandó darabok számát, és az állás és selejt okokat sem. Így egy ilyen megoldással csak akkor érdemes elindulni, ha nincs lehetőség ennél részletesebb adatgyűjtésre.

A hálózatba kapcsolt robotok gyűjtik az adatot (123rf)
A hálózatba kapcsolt robotok gyűjtik az adatot (123rf)

Pár nap alatt bármilyen gépből gyűjtünk adatot!

Hallottam már több cégtől ilyen ajánlatot, ennek is érdemes a mélyére nézni. Ugyanis ez a mondat szintén nagyon jól hangzik, ugyanakkor –  ahogy korábban is írtam – több hétig vagy hónapig is eltarthat, mire sikerül kialakítani az adatgyűjtést azért, mert a gépgyártóval és/vagy annak telepítőjével, továbbá a PLC programozóval is kell egyeztetni, árajánlatot bekérni, majd elvégezni a munkát. Ráadásul a mai leterheltségi szintek mellett sokan nem is vállalnak be ilyen jellegű elfoglaltságot. Ekkor előfordulhat az is, hogy más mód nincs az adatgyűjtés kialakítására, mint egy szenzort telepíteni, és azzal az előző pont szerint az adatgyűjtést kialakítani. Emiatt érdemes alaposan megvizsgálni a marketingajánlatok során felmerülő konkrét műszaki tartalmat, továbbá referencia látogatást is kérni valamely ügyfelükhöz, ahol már megvalósult alkalmazásokat lehet megtekinteni. Ezen kívül szintén javasolt konzultatív jelleggel a témában szakértőt igénybe venni, akinek ugyan van napidíja, másrészt viszont –  ha tényleg ért hozzá – rengeteget tud lendíteni a projekt előkészítésén, és ki lehet kerülni számos zsákutcát, amelybe az első alkalmak során oly könnyű belefutni.

Legyen a rendszer bővíthető!

Az OEE a MES előszobája. Sok ügyfél az OEE-n keresztül tanul bele, milyen változatos formában lehet kihasználni a digitális ikret. Bevezetés után sorra születnek igények a bővítésre:

  • Ne kelljen kézzel bevinni a tervezett gyártási időt, hanem szedje át automatikusan a tervezőből.
  • Ne csak egy állásidő eseményt nyisson a rendszer, hanem küldjön értesítést a karbantartónak vagy az anyagmozgatónak, és mérje, hogy mennyi idő alatt reagálnak.
  • Sokszor felmerül, hogy operátorok szerint is lehessen megjeleníteni a selejt arányt és az állás időket, ezért jó lenne, ha kiegészülne a rendszer kártyaolvasós bejelentkezéssel.
  • Ha már van kártyás bejelentkezési lehetőség, tiltson le a PLC, ha a dolgozónak nincs arra a gépre és termékre vizsgája,
  • és így tovább...

Ahogy jönnek az új fejlesztési igények, úgy növi ki az üzem az egyszerűbb megoldásokat. Érdemes tehát egyből olyan megoldást választani, amely a későbbiekben akár teljes MES-funkcionalitással is felruházható. Ellenkező esetben csak lesz egy n-edik sziget rendszer, amelynek gyorsan el lehet érni a korlátait, és lehet újra kezdeni a projektet.

A lényeg a részletekben rejlik

Ne felejtsük el, hogy a lényeg a részletekben rejlik! A cél az, hogy időben észleljük, a szokásostól vagy az elvárttól eltérő mértékű állásidőt, átállási időt, selejt mennyiséget tapasztalunk. Meg kell tudnunk határozni, hogy ezeknek mi a gyökéroka, az adott géppel van probléma, az alapanyaggal, esetleg az egyik operátor jobban teljesít, mint a többi? Ha időben értesülünk ezekről az eseményekről, akkor be tudunk avatkozni, akkor el tudjuk hárítani a hibát. Ha csak papíron vezetjük az állásidőt, ami 2 nap múlva bekerül egy Excel táblába, akkor csak reménykedni tudunk, hogy nem történik tragédia, amit amúgy el tudtunk volna kerülni, ha időben értesülünk. Ezért nem elegendő az egyszerűsített számítási mód, illetve ha csak egy szenzor adatot használunk OEE kalkulációra.

Cikkünk első részét itt olvashatja. 

A szerző a Com-Forth Kft. ügyvezetője, amely 30 éve szállít adatgyűjtő rendszereket és 17 éve MES-t.

A MES-rendszerek bevezetésével kapcsolatban itt olvashat bővebben. 

Bóna Péter, Com-Forth
a szerző cikkei

hirdetés
Ha hozzá kíván szólni, jelentkezzen be!
 
hirdetés
hirdetés
hirdetés

Kiadónk társoldalai

hirdetés