Az ipar 4.0 előszobája
Felmerülő kihívások, zsákutcák és jó gyakorlatok OEE adatgyűjtő rendszerek bevezetése során.

 

Az OEE mutató jelentősége nem csak abban áll, hogy a termelő berendezésekről, gépekről, folyamatokról valós idejű információt lehet összegyűjteni és megjeleníteni. A valós idejű OEE monitorozá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) egyszerűen megoldható informatikai feladat.

Nézzük az elején: mit értünk OEE alatt?

Az OEE (Overall Equipment Effectiveness) 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% OEE annyit jelent, hogy megállás nélkül, maximális teljesítményen (vagyis olyan gyorsan, amilyen gyorsan csak lehet) és 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 részletes betekintést nyerhetünk gyártási folyamatainkba, lehetővé téve azok optimalizálását.

Hogyan számoljuk az OEE mutatót?

A legegyszerűbb számítási mód a teljes értékű termelési idő és tervezett termelési idő hányada. A teljes értékű termelési idő alatt azt az időtartamot értjük, ami alatt selejt és megállás nélkül a lehető leggyorsabban (elvárt ciklusidő szerint) gyártottunk. Ez alapján az egyenlet a következő:

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

Habár az előző 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 (mennyit mentek a gépek), a teljesítmény- (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 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.

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.

Az alábbi eseteket ugyanakkor érdemes elkerülni:

– 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áadunk 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 mostohagyerek 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, ergonomikusabb alkalmazással 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.

Legyen bővíthető a rendszer!

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 az igények a bővíthetésre, pl. arra, hogy ne kelljen kézzel bevinni a tervezett gyártási időt, hanem szedje át automatikusan a tervező szoftverből. Ne csak egy állásidő eseményt nyisson a rendszer, hanem küldjön róla értesítést is a karbantartónak vagy az anyagmozgatónak, és mérje, hogy mennyi idő alatt reagálnak.

Sokszor felmerül, hogy dolgozónként is meg lehessen jeleníteni a selejtarányt és az állásidőket, ezért jó lenne, ha kiegészülne a rendszer kártyaolvasós bejelentkezéssel. Ha már van 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, ezért érdemes egyből olyan megoldást választani, amely akár teljes MES funkcionalitással is felruházható.

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

– 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ékszá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 kategorizálja, 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 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ú platformba, ahol az adatfeldolgozás történik. Egy OEE rendszernek nincsenek nagy 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 miatt is – érdemes egy megbízható, üzemi körülményekre és üzemi 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), és amiről el tudja dönteni, hogy tetszik, vagy sem, látja-e a kívánt információt, vagy sem. OEE-hez UI-t azonban 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.

Emiatt érdemes a tetszetős felhasználói felületek mögé tekinteni. Ha a „csak lerakunk egy szenzort, és máris megy az OEE” típusú megoldások közül választunk, akkor gyorsan korlátok közé szorulhatunk, azaz: 1) nem tudunk a mélyére ásni az OEE mutatónak, így nem találjuk meg a gyökérokokat, 2) nem lesz bővíthető a rendszer, ezért akármennyire is időigényes egy ilyen rendszer bevezetésének a megtervezése, hosszú távon többszörösen megtérül.

Egerbe helyezi át brémai termelését a Bosch
A megváltozott piaci feltételek miatt a Bosch átszervezi kormányoszlop üzletágát Európában, a gyártás a jövőben a vendôme-i (Franciaország) és az egri telephelyen koncentrálódik
Az ipari digitalizációs oktatást elősegítő program indul öt egyetemen
Öt évre szóló együttműködést írt alá öt hazai egyetemmel az S&T Consulting Hungary (S&T), melynek keretében piaci áron számítva több milliárd forint értékű ipari digitalizációs szoftver adománnyal és képzéssel támogatja az intézményeket.
Kopásálló műanyag alkatrészek három nap alatt
A 3D-nyomtatóval készült, beépítésre kész és tartós különleges alkatrészeknek köszönhetően szabadabbá válik a tervezés az autóiparban.
Egy univerzális ipari szoftver újrapozicionálása
A zenon szoftvert 30 évvel ezelőtt az a gondolat hívta életre, hogy a programozást konfigurációra cseréljék le. Az 1987-ben megjelent HMI/SCADA rendszer azóta egyetemesen használható szoftverplatformmá vált.
Új kompakt frekvenciaváltó az Omrontól
A szinte minden AC motorhoz alkalmazható Q2V az egyszerű telepíthetőséget és sokoldalúságot ötvözi a nagy hatékonyságú vezérléssel, miközben a karbantartási igényeket is csökkenti.