OEE mérés - az ipar 4.0 előszobája

Az OEE mutató 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 - 1) könnyen megérthető minden fél számára 2) jól mérhető a megtérülése 3) viszonylag egyszerűen megoldható informatikai feladat.

Az alábbi blogpostban azokat a legfontosabb döntési pontokat és potenciális zsákutcákat szedtem össze, amelyek egy OEE adatgyűjtési projekt elindítása során felmerülhetnek. 

Kezdjük az alapokkal: mi az OEE mutató jelentése?

Az OEE a gyártási termelékenységre vonatkozó mutató, mely egyszerűen megmutatja a valóban hatékony gyártási idő hányadát. A 100%-os OEE annyit jelent, hogy megállás nélkül, maximális teljesítményen (vagyis olyan gyorsan amilyen gyorsan csak lehet) kizárólag jó terméket gyártunk. Az OEE méréssel és a különböző veszteségek naplózásával fontos betekintést nyerhetünk gyártási folyamatunk optimalizálásának eredményébe. Az OEE, mint egyetlen mérőszám segít a veszteségek beazonosításában, az előrehaladás mérésében és a gyártóberendezések termelékenységének javításában. Magával a kifejezéssel egyébként írásban először már 1988-ban találkozhattunk Seiichi Nakajima Introduction to TPM: Total Productive Maintenance című könyvében, mely az 1982-es TPM tenkai című japán nyelvű kiadvány angol fordításából született. 

Overall Equipment Effectiveness

Az OEE az angol Overall Equipment Effectiveness kifejezés rövidítése. Habár a Wikipédián megtalálhatjuk a Teljes eszközhatékonyság kifejezést, a gyakorlatban szinte mindenki az angol rövidítést (OEE mutató) használja - ezért a továbbiakban én is ezt a gyakorlatot követem -, de ha mégis magyarra fordítjuk, gyakran az átfogó eszközhatékonyság kifejezéssel is találkozhatunk.

A nem angol anyanyelvűek gyakran összetévesztik az efficiency és effectiveness szavakat, a különbségekről többek között itt is olvashatunk, de röviden a lényeg: az effectiveness szó egy számszerűsített, mérhető eredményre utal, tehát nem is annyira a hatékonyság, mint inkább az eredményesség a jelentése (do the right things). Ezzel szemben az efficiency alatt pedig azt a fajta hatékonyságot értjük, amikor például egyre jobb minőségű terméket szeretnénk gyártani (doing things right). Tehát, ha már tudjuk, hogy mit kell gyártanunk, abból próbáljuk a lehető legtöbbet a rendelkezésre álló erőforrások alapján megtenni, a lehető legkevesebb állásidővel, az optimális futásteljesítménnyel és a legkevesebb selejttel. Ugyanakkor, ha például egy prediktív karbantartó rendszerrel szeretnénk az üzemeltetési feladatokat optimalizálni, akkor az efficiency, azaz a hatékonyság növelése a cél.

Hogyan történik az OEE mutató számítása?

Az OEE mutató kalkulációjára létezik egy, a végtelenségig leegyszerűsített számítási mód: a teljes értékű termelési idő és a tervezett termelési idő hányada. A teljes értékű termelési idő alatt azt az időtartamot értjük, ami alatt selejt és leállás nélkül a lehető leggyorsabban (elvárt ciklus idő szerint) gyártottunk. Ez alapján az egyenlet a következő:

OEE = (Jó darab * Elvárt ciklus idő) / Tervezett gyártási idő

Habár ez a számítás érvényes és az egyszerűségében rejlik az előnye, ugyanakkor nem ad információt arra vonatkozóan, hogy mi okozza a veszteségeket, és hogy mit lehet fejleszteni a magasabb OEE érték eléréséhez.

Az OEE mutató kiszámításához létezik egy ennél részletesebb számítási mód: a rendelkezésre állási mutató (mennyit mentek a gépek), a teljesítménymutató (a 100%-os futáshoz képest, azaz az elvárt normához képest milyen sebességgel járatták a gépeket) és a minőségi mutató (jó termékek, azaz a nem selejtek aránya az összes legyártott termékhez képest) szorzata. Ennek alkalmazásával - és ha kellően mélyre tudunk ásni - már megtalálhatjuk egy adott veszteség gyökérokát, és ha már tudjuk, hogy mi a hiba oka, jó eséllyel ki is tudjuk javítani.

A rendelkezésre állási mutatóhoz meg kell határoznunk, hogy mi volt az az elméleti maximális időtartam, amelyben teoretikusan lehet gyártani, és ebből kell kivonni az összes nem tervezett leállást, átállást, kismegállást (ez utóbbit gyakran mikrostopnak is nevezik). Ha például egy műszak 8 órás, és ebből van összesen 30 perc tervezett állás (műszakváltás, illetve egyéb munkaközi szünet miatt), akkor 7 óra és 30 perc (450') a teljes rendelkezésre álló idő. Ez lenne a 100%, amivel a gyártástervezők is kalkulálnak. Ha ez idő alatt volt egy 40 perces átállás, 2 hosszabb megállás (összesen 20 perc) és 5 mikrostop (összesen 8 perc), akkor összesen 6 óra és 22 perc (382') alatt történt ténylegesen gyártás, ami összességében kb. 84,9%-os rendelkezésre állást jelent.

A teljesítménymutatót a ténylegesen gyártott idő alatt a normákhoz viszonyított darabszámok alapján tudjuk kiszámolni. Ha percenként 10 darab a norma, akkor a 6 óra és 22 perc ténylegesen gyártással töltött idő alatt 3820 terméknek kellett elkészülnie. Ha ez a szám például 3600, akkor kb. 94,2%-os teljesítményről beszélhetünk. A szakirodalmak, illetve a marketing anyagok ritkán említik a 100% feletti teljesítmény mutatót, ami lehetséges ugyan, és ha önmagára az OEE mutatóra tekintünk, akkor javít is rajta, de a gép "túlpörgetése", az ideális ciklusnál gyorsabb gyártás veszélyes lehet, a karbantartási költségeket hosszú távon jelentősen megnövelheti. Ez például az egyik oka - amelyről majd a későbbiekben bővebben is írunk -, hogy az OEE mutató monitorozása önmagában miért nem ér semmit.

A minőségi mutató esetében azt vizsgáljuk, hogy a ténylegesen legyártott 3600 termékből összesen hány ment át úgy az elsődleges minőségellenőrzésen (QC), hogy azt nem minősítették selejtnek. Ezt a mondatot szándékosan fogalmaztam meg ilyen nyakatekert módon, hiszen ha itt a szám pl. 3500, és a minőségi mutató emiatt 97,2%, az nem jelenti azt, hogy ez 3500 ténylegesen jó termék lett, mert lehet, hogy a gép vezérlője jó terméknek minősítette az adott alkatrészt, de később megsérül, vagy valaki észrevesz rajta egy hibát egy következő, vizuális inspekció során, vagy - legrosszabb esetben - vevői reklamációból derül ki, hogy mégis selejtet gyártottunk.

A fenti adatok alapján a rendelkezésre állási * teljesítmény- * minőségi mutató szorzataként 84,9% * 94,2% * 97,2% = 77,75%-os OEE mutatót kapunk.

Az OEE mutatót szinte mindenki eltérő módon, a saját gyártására vonatkoztatva használja. Ezért fontos olyan szoftvert választani, ami teljesen egyedi kalkulációkat is képes elvégezni.

Mi számít jó OEE mutatónak?

Több helyen találkoztam már az ún. world-class OEE fogalmával, amelynek értéke 85%, és amelyet sokan benchmarknak tekintenek. Én azonban úgy gondolom, hogy ezt mindig a saját gyártásunkhoz és a korábbi eredményeinkhez kell hasonlítani, és semmiképpen sem szabad messzemenő következtetést levonni egyetlenegy százalékos értékből (erről bővebben a "Három érv, ami miatt önmagában értelmetlen a World-Class OEE fogalma" cikkünkben írtunk).

Van olyan vállalat, ahol kis árréssel, nagy sorozatokban gyártanak, és tökélyre fejlesztették a technológiát, így már kevés selejt keletkezik. Nem csoda, ha 80-90%-os OEE mutatóval rendelkeznek. Ugyanakkor van olyan gyártó partnerünk, ahol a kiszerelő üzemben rengeteg az átállás, mivel kis szériás termékeket is csomagolnak, így ők örülnek egy 40-45% körüli OEE értéknek. Máshol az átállást eleve nem számítják bele az OEE-be, mert a tervekre nincs ráhatásuk, és egyébként is szinte mindenki egy kicsit másképp számolja az OEE-t. Ezért önmagában azt nem lehet megmondani, hogy a mért OEE mutató jó vagy sem, legfeljebb annyit, hogy a kiinduló állapothoz jó ütemben javul-e.

Mikor van (és mikor nincs) 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 amúgy nem szokott, vagy egy műszakban többször is leállt az a gép, pedig máskor ez nem jellemző rá. 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, 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.

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 gy 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, akkor 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.

A 2019. szeptemberében megrendezett Manufacture IT konferencián is az OEE mérés témáját jártam körbe az előadásom során, az előadásom kivonata innen tölthető le.

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.

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, hiszen ez az ipari automatizálási cégeknek nem a kedvenc munkája, sokkal szebb projekt pl. egy új gépet leszállítani vezérléssel együtt. Ekkor előfordulhat az is, hogy nincs más mód 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 marketing ajá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, amelyekbe az első alkalmak során oly könnyű belefutni. A tervezésbe való kezdeti befektetés sokszorosan megtérül, ahogy erről a Tervezni? Kell! című blogpostunkban is részletesen írtunk.

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 szigetrendszer, amelynek gyorsan el lehet érni a korlátait, és lehet újra kezdeni a projektet.

A MES rendszerek bevezetésével kapcsolatban ajánlom Sós András fejlesztő mérnök kollégám átfogó írását, melyet itt találsz.

Mennyibe kerül egy OEE adatgyűjtő rendszer?

Egy ilyen rendszer - a költségeit tekintve, ahogy a fent írtakból is látható - első ránézésre a licenc díjakból és a fejlesztői mérnöknapok együtteséből áll össze, és ezt viszonylag gyorsan meg is lehet becsülni. Ugyanakkor fontos hangsúlyozni, hogy maga az adatgyűjtés kiépítésének költségei meglehetősen szórnak attól függően, hogy mennyire komplex az adatokat a gépekből, gyártósorokból illetve folyamatokból kinyerni. Ez az átfutási időt tekintve is nagyon változó.

Mindezek mellett nem szabad elfeledkezni a további költségekről, hiszen egy OEE mérőrendszer bevezetéséről is, mint minden beruházásról TCO (Total Cost of Ownership) alapján kell dönteni.

A TCO-ról átfogóan a Mennyibe kerül egy MES? című blogpostunkban írtunk, de dióhéjban, amire első körben általában nem szoktak a partnereink gondolni, pedig a MES szállítójának fizetett díj elenyésző az alábbiakhoz képest:

• Az IT-OT infrastruktúra kiépítése a biztonsági irányelvek figyelembe vételével;
• A belső munka, amit a csapat, a kulcsemberek beletesznek a rendszer tervezésébe és tesztelésébe;
• Az üzemeltetési, szoftverkövetési, karbantartási illetve egyéb támogatási díjak a beüzemelés utáni évekre;
• Egy megbízhatatlan MES hibás működéséből adódó adatvesztés vagy leállás költségei.
• A zsákutcákba való behajtás illetve az elhalt projektek költségei;
• és így tovább.

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, hogy 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.

Egyetértesz a leírtakkal? Esetleg más a tapasztalatod? Szívesen várjuk a hozzászólásodat, vagy foglalj időpontot a naptáramban, és látogass el hozzánk egy finom kávéra az új irodánkba, és beszélgessünk a gyártási folyamataidról!

--------

Ez a  blogpost eredetileg 2019.10.05-én került publikálásra, azóta folyamatosan bővül, ahogy jönnek az újabb és újabb tapasztalatok a mindennapok során. Legutolsó frissítés: 2023.08.20.

--------

Ezúton is szeretném megköszönni Hrubi Gyula fejlesztő mérnök kollégámnak a szakmai támogatást a cikk írása során!

--------

A Com-Forth Kft. egy magyar tulajdonú ipari informatikai vállalat, amely több mint 30 éve szállít adatgyűjtő rendszereket és 2002 óta MES-t. Az első kifejezetten OEE adatgyűjtő rendszert 2006-ban szállítottuk egy autóipari beszállítónak. Azóta adtunk át különféle dobozos szoftverekkel készült megoldásokat valamint saját fejlesztésűt rendszereket is.

--------

A cikk megjelent a GyártásTrend oldalán is.