← Összes cikk
MES

Az MES a hiteles nyilvántartás arról, mi történt az üzemben

📅 · 4 perc olvasás · Meta Smart Factory csapat

A gyártásvégrehajtási rendszer (MES) legtöbb definíciója pontos és használhatatlan. Felsorolnak egy tucat funkciót, és az olvasó ettől sem lesz képes megmondani, mi változna hétfőn a saját munkahelyén. Ez az oldal a másik utat választja: azt írja le, miért felel az MES abban a pillanatban, amikor egy alkatrész elkészül. Ez a hiteles nyilvántartás arról, mi történt az üzemben, és ha ez a nyilvántartás hibás, felette semmi nem lehet helyes.

Mit csinál az MES: munkakiadás, végrehajtás rögzítése, visszajelentés és nyomon követhetőség

Kezdjük a munkakiadással, amit gyakran összetévesztenek a nyomtatással. A tervezés lead egy rendelést és egy technológiai útvonalat; az MES dönti el, melyik erőforrás melyik műveletet futtatja, milyen sorrendben adódik ki, és egyáltalán elindulhat-e. Az üzem egészére napokkal előre, szerszámra, munkaerőre és átállási családokra kiszámolt sorrend más feladat, és a fejlett tervezéshez és ütemezéshez, az APS-hez tartozik, akár MES-modulként, akár külön rendszerként szállítják. A végtelen kapacitással készült terv, amit egyenesen kiadnak az üzembe, a műszak közepére fikció.

A kiadásnak előfeltételei vannak, és mindegyiknél az a kérdés, hogy a rendszer tudja-e, vagy csak közlik vele. Azt, hogy az előző műveletet leigazolták, és hogy a kezelő képesítése érvényes, az MES a saját nyilvántartásaiból tudja. Azt, hogy a megfelelő tétel ki van készítve, be kell olvasni, vagy interfész kell ahhoz a rendszerhez, amelyik a foglalást tartja. Azt, hogy a helyes szerszám van befogva, a szerszámgazdálkodás, a befogóban lévő chip vagy egy szerszám-beállítógép interfésze adja meg — vagy egy kezelő, aki visszaigazolja, amitől az ellenőrzés pontosan annyit ér, amennyit a visszaigazolás. Az az előfeltétel, amely mögött forrás van, kontroll; amelyik mögött pipa van, az csak egy időbélyeges bejegyzés.

Aztán a végrehajtás: beállítás és gyártás a munkaidőtől elkülönítve, jó darabok, selejt okkal, utómunka valahová irányítva, leállások okkal és időtartammal. A minőség ugyanebbe a folyamatba tartozik, a művelethez definiálva, azzal elvégeztetve, aki a munkát végzi, olyan eredménnyel, amely megállíthatja a darab továbbhaladását. A végellenőrzés ugyanazt a hibát négy művelettel később találja meg, miután mind a négyet kifizette.

A visszajelentés zárja a hurkot az üzleti rendszerek felé: az anyagot a rendelésre, a munkaidőt a műveletre könyvelik, és ebből a két könyvelésből lesz a tényleges költség és a tényleges készlet. A nyomon követhetőség mindezek alatt fekszik, az OEE pedig adódik belőle, mert nem külön rendszer, hanem aritmetika azokon az eseményeken, amelyeket a végrehajtás már előállított.

Mi tartozik az MES-re, és mi az ERP-re, a SCADA-ra vagy a PLC-re

Az ISA-95, amelyet nemzetközileg IEC 62264 néven adtak ki, itt nem a rétegábrája miatt hasznos, hanem az objektummodelljei miatt — termelési terv, termelési teljesítmény, anyagtétel, személyzet, berendezés —, mert ezek azok, amelyek az üzem és az üzleti oldal között átjárnak, és ettől lesznek egy interfész-specifikáció ellenőrzőlistája.

A legnehezebb határ a legalsó. A biztonsági funkciók — védőburkolat-reteszelések, fényfüggönyök, kétkezes indítók, területi szkennerek — huzalozott biztonsági körbe vagy biztonsági vezérlőbe valók, azon a teljesítményszinten vagy SIL-en, amelyet az ISO 13849-1 vagy az IEC 62061 szerinti kockázatértékelés állapított meg. Semmilyen hálózati determinizmus nem teszi az e réteg fölötti szoftvert egy ilyen funkció jogszerű helyévé. A technológiai reteszelések azok, amiken érdemes vitatkozni: ne induljon el rossz szerszámmal, ne menjen a paraméterablakon kívülre. Ott a fizikai megakadályozás a PLC-é, mert egy szabály, amelynek tíz-egynéhány ezredmásodperc alatt kell működésbe lépnie, nem lakhat egy adatbázis és egy hálózati switch mögött, a következmény pedig az MES-é: nem nyitja meg a következő műveletet, és zárolja a tételt.

E határ fölött a feladatmegosztás ismerős: vizualizáció, riasztáskezelés és felügyeleti alapjelek a SCADA-nak; rendelésazonosság, technológiai útvonal, genealógia, minőségi döntés és munkaidő az MES-nek; igény, beszerzés, önköltség és a vevői vállalás az ERP-nek. Egy határeset eldöntéséhez két kérdés elég: milyen gyorsan kell megszületnie a döntésnek, és kell-e majd valakinek két év múlva bizonyítania, hogy megtörtént.

Mit jelent valójában a valós idő a gépinterfészen

A valós idő itt nem szabályozókör-determinizmus. Azt jelenti, hogy a bejegyzés elég közel kerül az eseményhez ahhoz, hogy aki okozta, még ott álljon — másodperces vagy annál sűrűbb olvasási ütem, ahol az számít jobban, hogyan olvas, nem az, hogy milyen gyorsan.

Gyűjtőszámlálókat olvasson, és különbségeket képezzen, ne éleket számoljon. A mintavételi időnél rövidebb impulzus egy lekérdezéses olvasás számára láthatatlan, az előfizetés pedig csak akkor menti meg, ha a sorhosszt és a mintavételi sebességet erre állították be, ami alapértelmezetten nem így van: egy egyes sorhosszú monitorozott elem a legfrissebb átmenetet tartja meg, a többit eldobja. Egy csak felfelé lépő számláló immunis erre, és a felbontáson kívül semmibe nem kerül. A PLC-számlálók gyakran tizenhat bites szavak, amelyek körbefordulnak, így a túlcsordulást tudatosan kell kezelni, az értéket pedig újra kell horgonyozni minden áramtalanítás vagy reset után.

A gépállapot szinte soha nem egy bit. Egyetlen futásjel általában a hajtásengedélyezés, ami akkor is igaz marad, amíg az orsó üresen jár és a kezelőre vár; a használható felismerés a „ciklus aktív” és a „hajtás engedélyezve” jeleket kombinálja azzal, hogy mozdult-e a számláló egy időablakon belül. Ez az ablak adja a felismerési küszöböt: a nála rövidebb leállások állásidőként láthatatlanok, és megmagyarázatlanul, teljesítményveszteségként jönnek elő újra. Egy órának kell időbélyegeznie az eseményeket, a peremnek pedig puffereznie kell, hogy egy switch újraindulása után hiány maradjon, ne egy óra fantomállásidő.

Állásidő-okkódok: amit egy gépi jel nem tud megmondani

Az interfész tudja, hogy a gép megállt, és mennyi időre. Azt nem tudja, hogy miért, sem azt, hogy az imént számolt darabot a következő állomáson selejtezni fogják, sem azt, hogy a kezelő darura várt, nem anyagra.

Ezt a hiányt ember tölti ki, és ennek a pillanatnak a kialakítása dönt el mindent, ami fölötte van. Az okkódok a szokásos eszköz és a szokásos kudarc. Ha túl sokat kínál, a kezelő minden alkalommal az első hihető tételt választja, és onnantól a lista sorrendje írja a Pareto-diagramját. Ha túl keveset, minden Egyéb lesz. A besorolásnak a műszakon belül kell megtörténnie, amíg a bizonyíték megvan, és valaminek vissza kell jutnia cserébe a kezelőhöz.

A papírmentes üzem és az elektronikus sarzsdokumentáció

A papírmentes nem azt jelenti, hogy ugyanazok az űrlapok PDF-ként a képernyőn. Azt jelenti, hogy az állomáson lévő dokumentum az adott rendeléshez érvényes revízió, amelyet a rendszer választ ki, így az állomásra csak az aktuális revízió kerülhet — és azt, hogy a bejegyzés a munka elvégzésével keletkezik, nem utólag másolják át, mert itt vész el az egyidejűség, és vele a hitelesség. Amit egyetlen dokumentumkezelő rendszer sem tud kontrollálni, az a papír. A múlt kedden kinyomtatott és fiókban tartott rajz definíció szerint ellenőrizetlen, és a fiók csak akkor veszít, ha a rendszert gyorsabb megkérdezni.

Szabályozott gyártásban ez a nyilvántartás az elektronikus sarzsdokumentáció, a termék jogi életrajza. A szabályozói keret — az FDA 21 CFR Part 11 előírása az elektronikus nyilvántartásokról és aláírásokról, valamint az EU GMP 11. melléklete — a szokásos szoftveres kérdésekből tervezési követelményt csinál: nem szerkeszthető audit nyomvonal, kifejezett jelentéssel bíró aláírások, névhez rendelhető és a történés idejében rögzített bejegyzések. A kivételalapú felülvizsgálat, ahol a valódi megtakarítás van, csak akkor működik, ha a rendszer már a bevitelnél kikényszerítette a határokat, mert csak akkor mond bármit az, hogy egy sarzsra nem érkezett jelzés.

Nyomon követhetőség és genealógia mint tervezési követelmény, nem mint funkció

A genealógia két irányban fut, és mindkettőnek működnie kell: visszafelé, egy kész darabtól minden alkatrésztételig, gépig, szerszámig, kezelőig, paraméterig és ellenőrzésig, amely hozzájárult, és előre, egy gyanús beérkező tételtől minden darabig, amelybe bekerült, és minden vevőig, ahová azok a darabok kimentek. Az előre irányt azon a délutánon teszik próbára, amikor egy beszállító telefonál, és rendszerint ez a gyengébb.

A granularitás a tervezési döntés, és az rögzíti, amit a felhasználás pillanatában rögzítenek. Sorozatszám darabonként, tétel raklaponként, sarzs műszakonként vagy egy időablak: mindegyik alsó korlátot szab annak, milyen kicsi lehet egy visszahívás, mert a körülhatárolás költsége annak a halmaznak a mérete, amelyet nem tud kizárni. A műszakszintűről raklapszintű azonosságra lépés nem riportálási változás, hanem annak megváltoztatása, amit a kezelő beolvas.

Egy összefolyási pont nem éles vágást csinál, hanem átmeneti időszakot indít. Töltsön rá egy silóra gyártás közben, és ami utána ürül ki, az keverék; hogy a régi tétel meddig jelenik meg, a tartály térfogatától, a benne maradt anyagtól, az átbocsátástól és az áramlási formától függ, mert tölcséres áramlásnál a régi anyag nagyon sokáig szivárog le a falak mentén. Tehát rögzítse a rátöltést a tételével, jelölje meg mindkét tétellel mindazt, ami ettől az eseménytől addig készül, amíg a régi tétel bizonyíthatóan ki nem fogy, és írja le a kifogyásra tett feltételezést. Egy keverő egyáltalán nem ez a probléma: az egy sarzs több bemeneti tétellel és több-az-egyhez genealógiával, és a modellben több tételes bemeneti listát tartalmazó sarzsként a helye. Ebből semmit nem lehet utólag ráhúzni a már kiszállított termékre, ezért tesztelje élesítés előtt: vegyen le egy darabot a rakodóról, és kérje el a teljes visszafelé menő genealógiáját egy órán belül.

Hogyan mérjünk őszintén OEE-t, és mitől lesz hazugság egy OEE-szám

A teljes berendezéshatékonyság a rendelkezésre állás, a teljesítmény és a minőség szorzata, mindháromnak megvan a bevett módja, ahogy fel lehet fújni, a definíciónak és az időalapnak pedig írásban kell léteznie, mielőtt az első számot megmutatják.

Az időalap a legnagyobb emelő. Az OEE-t hagyományosan a tervezett termelési időhöz mérik, így minden óra, amelyet kivesz a tervezett termelési időből — ütemezési veszteségnek nyilvánítva állásidő helyett —, elhagyja a nevezőt, míg azok az órák, amelyeket nem tervezettnek jelöl, bent maradnak, és pontosan ezek húzzák le a rendelkezésre állást. Hagyja ki az alapból a próbagyártásokat és a személyzet nélküli műszakokat, és a szám kényelmessé válik, miközben az eszköz a hét nagy részében áll. Az átállás egyáltalán nem szürke zóna: a hat nagy veszteség szerint a beállítás és a beszabályozás a tervezett termelési időn belül van, és a rendelkezésre állás rovására kell mennie, ezért a kihagyása az OEE-szám kozmetikázásának leggyakoribb módja. A teljes hatékony berendezésteljesítmény (TEEP), amelyet naptári időhöz mérnek, mellette a helye: a különbség az a kapacitás, ami az öné, és nem használja.

A teljesítményt az ideális ciklusidő torzítja. A klasszikus definíció és az ISO 22400 az elméleti vagy tervezési ciklusból veszi; a legtöbb üzem a technológiai útvonalból, ahol egy évekkel ezelőtt kalkulációhoz rögzített norma tele van pótidőkkel. Ha a norma ötvenöt másodpercet mond, a gép bizonyított legjobbja pedig negyven, a jelentett teljesítmény nagyjából harminchét százalékkal fut magasan — és mivel a legtöbb rendszer száz százaléknál levágja a teljesítményt, a képernyőre nem jó eredmény jut ki, hanem levágott hiba. Szedje ki az eseményadatokból a leggyorsabb tartósan hozott ciklust, és vesse össze az útvonalon lévő normával, mielőtt teljesítményszámot publikál.

A minőséget az rontja el, ha az utómunkát jónak számolják azon a műveleten, amelyik előállította, miközben az elsőre jó aránynak meg kellene mutatnia a hibát. A rendelkezésre állást a fenti felismerési küszöb rontja el, meg az az állásidő, amelyet ugyan besoroltak, de többnyire Egyébnek.

Két aggregálási hiba marad. Az OEE gépek közötti átlagolása összekever egy szűk keresztmetszetet jelentő eszközt egy olyannal, amely tervezetten áll, így az üzemi szám olyan okokból mozdul el, amelyekre senki nem tud reagálni. Egy nem szűk keresztmetszeten pedig, amelynek már van védőkapacitása, az OEE emelése nem kibocsátást eredményez, hanem befejezetlen terméket halmoz fel a szűk keresztmetszet előtt — ez a szabály három gyakori kivétellel él: a védőkapacitás híján lévő nem szűk keresztmetszet kiéhezteti a szűk keresztmetszetet, ami elvesztett kibocsátás, nem WIP; a szűk keresztmetszet a termékmixszel vándorol, így az e havi nem szűk keresztmetszet a következő negyedév szűk keresztmetszete; egy közös nagyberendezés pedig — hőkezelés, festés vagy az az egy készülék — időszakosan szűk keresztmetszet. Mérjen rendelkezésre állást mindenhol, OEE-t csak ott hajszoljon, ahol a veszteség átbocsátássá konvertálódik, és azonosítsa újra a szűk keresztmetszetet, amikor a mix változik.

Mit jelent valójában az MES–ERP integráció

A konnektor a kisebbik rész. A munka az, hogy mezőről mezőre eldöntsék a tulajdonlást, és le is írják. Cikktörzs, darabjegyzék, technológiai útvonal, munkahely, vevői rendelés, gyártási rendelés: mindegyiknél az egyik rendszer a mérvadó, a másik a fogyasztó, definiált viselkedéssel arra az esetre, ha eltérnek. Az a projekt, amelyik ezt kihagyja, az első hónapban fedezi fel, amikor valaki abban a rendszerben módosít egy darabjegyzéket, amelyik nem birtokolja.

A következő a visszajelentés granularitása. Műveletenként, rendelésenként, óránként vagy darabonként: az ERP tranzakciószámát váltja arra, mennyire lehet elavult a készletpozíció. A backflush és a beolvasott felhasználás ugyanez a váltás anyagi formában: a backflush, vagyis a retrográd anyagkivét, visszajelentéskor a darabjegyzék szerinti mennyiséget könyveli le, gyorsan és a kihozatal ingadozásával, minden helyettesítéssel és minden le nem könyvelt selejttel tévesen, míg a beolvasott kiadás azt könyveli, amit fizikailag elvittek. A nyomon követhető és drága anyagokat olvassa be, a kötőelemeket backflusholja.

Aztán a látványtalan mérnöki munka. Minden üzenethez kell idempotenciakulcs, mert az interfészek újrapróbálkoznak, és egy kétszer lekönyvelt árubevételezés hetekkel később egy leltárban bukkan fel. Valakinek látnia kell a hibás üzenetek sorát, és fejlesztő nélkül újra kell tudnia futtatni egy tételt, a mértékegységekhez pedig explicit átváltások és megegyezésen alapuló kerekítés kell. Az interfésznek mindkét oldalon nevesített gazdája kell legyen, mert a gazdátlan integráció csendben romlik: hozzáadnak egy mezőt, egy leképezés nem talál többé, a hibák pedig egy sorban gyűlnek, amit senki nem olvas.

Miért buknak el az MES-bevezetések, és mi jelzi előre

A törzsadat a leggyakoribb ok és a legkevésbé tárgyalt. Technológiai útvonalak, amelyek olyan sorrendet írnak le, amit évek óta senki nem futott, rossz granularitáson modellezett munkahelyek, soha újra nem mért normaidők, három írásmóddal szereplő anyagok. Az MES nem ezeket a problémákat hozza létre, hanem az első napon láthatóvá teszi őket, és ekkor azért a rendetlenségért hibáztatják, amit feltárt. Mérjen meg egy valódi gyártást és egy valódi átállást élesítés előtt, és számítson rá, hogy újra kell írnia az útvonalakat.

A második a kezelői elfogadás, a fenti beviteli tervezés okaiból; a válasz az, hogy a visszajelentési lépéseket saját maga mérje ki, valódi átállás közben, azzal a kezelővel, aki majd elvégzi őket. A harmadik a gazdátlan interfész. A negyedik az a hatókör, amely először a kivételt modellezi: hónapok egy ritka tételmegbontáson, miközben a normál folyamat még befejezetlen. Az ötödik az élesítés a szűk keresztmetszeten a legforgalmasabb negyedévben. Az utolsó definíciós: két rendszer különböző számokat jelent ugyanarra a műszakra, mert senki nem egyezett meg abban, hogy a tervezett állásidő beleszámít-e, és a megbeszélés a szám körüli vitává válik a mögötte lévő veszteség helyett.

Hogyan vezessen olyan MES-kiválasztást, amely mond is valamit

A forgatókönyv szerinti bemutató a boldog utat mutatja, amit minden MES-szoftver kezel. A kiválasztás azt jelenti, hogy a csúnya utakat kényszeríti látótérbe, a saját adataival. Vigyen négy esetet: egy rendelést, amely félúton gépet vált; egy műveletet, amelyet az egyik műszakban kezdtek el, és a következőben fejezett be valaki más; egy két rendelésre szétosztott tételt; és egy visszamenőleges javítást, ahol valaki két órával ezelőtt rossz leállási okot választott, és tudni akarja, ki javíthatja, mit mutat az audit nyomvonal, és eljut-e a javítás a már lejelentett számokig.

Kérje meg őket, hogy a genealógiát a saját adataikon futtassák le, aztán azt, mi kellene ahhoz, hogy az önén fusson. Kérdezze meg, mit csinál a gépinterfész, ha egy PLC-t rendelés közben áramtalanítanak. Kérje, hogy azzal a mérnökkel beszélhessen, aki az ön integrációját csinálná, ne az értékesítési csapattal. Referencialátogatáson az idejét egy kezelővel töltse, és kérdezze meg, mit kerülnek ki. Kereskedelmileg: mibe kerül egy második gyár, mibe kerül egy verziófrissítés, mit ad az API — a folyamata szokatlan darabjai erre épülnek, nem megveszik őket —, és ki tudja-e exportálni a saját nyers eseményadatait használható formában. Ez utóbbi a valódi próbája annak, hogy a nyilvántartás az öné-e.

Hol illeszkedik a Meta Smart Factory MES-modulja

A Meta Smart Factory MES-modulja lefedi a fenti területet: munkakiadás és kiadás előfeltételekkel, a végrehajtás rögzítése az állomáson, állásidő és selejt okokkal, munkaidő- és anyagvisszajelentés, a művelethez kötött minőség-ellenőrzések, genealógia, és ugyanabból az eseményfolyamból származtatott OEE, nem egy párhuzamosból.

A gépoldalon a Siemenst S7comm-on, a Rockwellt AB-ETH-n, Logixen és DF1-en, a Schneidert UMAS-on, a Beckhoffot ADS-en, a Mitsubishit MC Protocollal és az Omront FINS-szel olvassa, mindegyiket natívan, a többihez pedig OPC UA-t, Modbus TCP-t és RTU-t, EtherNet/IP-t és MQTT-t beszél, beleértve egy meglévő OPC UA- vagy DA-szervert ott, ahol senki nem akar még egy eszközt a hálózatra. Azok a gépek, amelyekben nincs olvasásra érdemes vezérlő, retrofit I/O modulokat kapnak, a már meglévő diszkrét jelekre kötve — egy futás-kontaktus, egy ciklus-kimenet, egy hibarelé —, amelyek annak a huzalozásnak a felbontásán adnak állapotot és darabszámot, és a fenti okokból soha nem adják meg egy leállás okát.

Közös adatmodellen osztozik a Minőség, a Karbantartás, a WMS és a Gépi látás modulokkal, valamint az ERP-integrációs réteggel. A véges kapacitású sorrendezés az APS-modulban él, a fent leírt határon, nem a végrehajtáson belül, az MRP-futás pedig azoknak az üzemeknek van ott, amelyek ERP-je nem csinál ilyet.

Ebből semmi nem veszi el azokat a részeket, amelyek valóban nehezek, és ez az oldal többnyire ezekről szólt: megegyezni abban, mit jelentenek a számok, kijavítani az útvonalakat, amelyek soha nem voltak jók, olyan nyomonkövetési granularitást választani, amivel együtt lehet élni, és olyan beviteli lépést tervezni, amelyet a kezelő kétszeri kérés nélkül elvégez.

Beszélje meg szakértőinkkel