Ipar 4.0 és Ipar 5.0 a gyártósoron: mi változik valójában

Ez az oldal fordított irányban épül fel: a gépek és az operátorok felől kifelé.

Mit jelent az Ipar 4.0 a gyártósoron

A szóhasználatot lehántva az Ipar 4.0 egyetlen elmozdulás: olyan gépektől, amelyek semmit nem jeleznek vissza, olyanokig, amelyek adata döntést mozdít meg.

Vegyünk egy présgépet, amelyik leáll. Abban az üzemben, ahol ez az elmozdulás nem történt meg, a leállás felkerül a műszaknaplóra, másnap reggel valaki beüti egy táblázatba, majd bekerül a havi riportba egy "állásidő" nevű tömbbe, ok nélkül. Addigra a művezető, aki tudta, mi történt, már elfelejtette. A szám igaz, és használhatatlan.

Abban az üzemben, ahol megtörtént, a leállást a PLC jeléből másodperceken belül érzékeli a rendszer, az operátor a gépnél besorolja az okát, amíg az ok még látszik, a tervezőrendszer látja, hogy a művelet nem fér bele az ablakába, és a következő rendelés átütemeződik, vagy az anyag visszatartásra kerül. Ugyanannak az eseménynek most már következménye van.

A különbséget nem a szenzor adja. A legtöbb gyár ma is jóval több adatot állít elő, mint amennyit felhasznál; a darabszámlálók, a hajtások és a PLC-k évek óta ontják a jeleket. A különbség a zárt hurok: az adatot az esemény pillanatában és helyén rögzítik, kontextust kap, egy nyilvántartó rendszerben marad, és van valami, ami cselekszik belőle.

A gyártás digitalizálása önmagában sem ugyanez: ha a papíralapú munkalap helyére PDF kerül, a nyomtató tűnik el, nem a késés. Az Ipar 4.0 ott kezdődik, ahol az adat strukturált, időbélyeges, és rendeléshez, géphez, szerszámhoz és operátorhoz van kötve — mert csak ekkor tud vele bármi számolni a lánc további részén.

A rétegek, és hogy melyik hol helyezkedik el

Az Ipar 4.0 körüli félreértések javarészt abból származnak, hogy a felek különböző rétegekről beszélnek. Az ISA-95 használható szótárat ad ahhoz, hogy szét lehessen tartani őket.

Gépi jelek — szenzorok, PLC-k, gateway-ek. Egy valódi üzemben ez a réteg vegyes. Van gép, amelyik OPC UA-t beszél; a régebbiek Modbust, valamilyen soros protokollt, vagy egy száraz kontaktust és semmi mást. A zárt vezérlőkhöz, amelyeket a gyártó nem nyit meg, utólagos szenzor kell az orsóra, a hidraulikakörre vagy a betápra. Ne számítsunk egyetlen egységes protokollra, és tervezzünk pénzt arra a makacs kisebbségre, amelyik külső műszerezést igényel. Az IIoT gateway-ek ide tartoznak, és ide tartozik az RTLS is, ha tudni kell, hol van fizikailag egy kocsi, egy szerszám vagy egy tétel, nem pedig azt, hogy a papír szerint hol kellene lennie.

Adatgyűjtés és kontextus. A nyers jel még nem információ. Egy darabszám akkor lesz információ, ha tudjuk, melyik rendeléshez tartoznak a darabok, melyik szerszám készítette őket, ki vitte a cellát, és melyik műszak volt. Ez a réteg dönti el csendben, hogy a fölötte lévők működnek-e: ha a kontextust műszak végén, kézzel írják hozzá, minden fölötte lévő réteg örökli ezt a bizonytalanságot.

MES — végrehajtás. Itt megy a tényleges üzemirányítás: rendelések kiadása a cellákra, műveletek visszaigazolása, gép- és emberi idő rögzítése, selejt és utómunka felvétele okkal együtt, a technológiai sorrend és a beállítás betartatása, valamint az a nyomonkövetés, amivel egy tétel visszafelé végigjárható. A minőségellenőrzés (QMS), a karbantartási triggerek (CMMS) és az anyagmozgások (WMS) ugyanerre az eseményfolyamra épülnek. Az MES az a nyilvántartó rendszer, amely rögzíti, mi történt a gyártósoron. Az elemzéseket később újra lehet építeni; a nyilvántartást nem.

Tervezés — MRP, APS, SCP. Az MRP és az ERP arra válaszol, mit kell gyártani és nagyjából mikor, napos felbontásban. Az APS véges kapacitásra és a ténylegesen szűkítő korlátokra ütemez: közösen használt szerszámokra, átállási családokra, minősített operátorokra, száradási vagy kikeményedési időkre. Az SCP ennél távolabbra néz, beszállítókon és telephelyeken át. A tervezés minőségének felső korlátja a végrehajtásból érkező visszajelzés — egy véges kapacitású terv, amely évek óta nem újramért normaidőkre épül, egy napon belül kézzel lesz átütemezve.

Elemzés, AI/ML és gépi látás. Ez ül a tetején, és az alatta lévő rétegek nélkül nagyon keveset ér. Velük viszont az érték jelentős része itt keletkezik: gépi látás felületi hibákra, meglét-hiány vizsgálatra és címkeellenőrzésre, ahol egy kamera következetesebb, mint egy szem egy hosszú műszak végén; AI/ML rezgés- vagy energiaképek anomáliáinak felismerésére. Az energiamérés is ide tartozik, és akkor válik hasznossá, ha a fogyasztás a termelési kibocsátáshoz van kötve, nem egy mérőóra állásához, mert így az egy darabra jutó energia műszakok és gépek között összehasonlítható.

ERP-integráció. Szigorúan véve ez nem réteg, hanem illesztés a végrehajtás és az üzleti rendszerek között. Rendelések, darabjegyzékek, technológiai sorrendek, cikktörzsek és visszajelentések haladnak át rajta mindkét irányba. A projektidő tekintélyes részét felemészti, és rendszerint ezt a részt tervezik meg utoljára.

Mit tesz hozzá az Ipar 5.0, és mit nem lehet megvenni

Az Ipar 5.0 nem egy gyártó terméktervéből származik. Az Európai Bizottság szakpolitikai munkájából jött, és inkább korrekcióként olvasható, mint utódként. Az Ipar 4.0 azt kérdezte, mennyi mindent lehet összekötni és automatizálni. Az Ipar 5.0 azt kérdezi, mi az ember szerepe az automatizált üzemben (emberközpontúság), hogyan viselkedik az üzem, ha az ellátás, a kereslet vagy az energiaár hirtelen elmozdul (ellenállóképesség), és mibe kerül a termelés energiában és anyagban, nem csak pénzben (fenntarthatóság).

Ez azért számít, mert az "Ipar 5.0" kezd megjelenni terméklapokon. Ipar 5.0-t nem lehet megvenni. Olyan dolgokat lehet megvenni, amelyek a céljait szolgálják, és jogos bármelyik szállítótól megkérdezni, hogy ezek közül melyikre gondol:

Operátori felületek, amelyeket a munkát végző ember köré terveztek, nem az adatbázis-séma köré — kevés lépés, a gépnél, és cserébe adnak is vissza valami hasznosat azért, amit beírtak.

Rendelésre és gépre bontott energiamérés, hogy egy folyamatmódosítást ne csak ciklusidőben, hanem fogyasztásban is meg lehessen ítélni.

Olyan tervezés, amely megváltozott korláttal újrafuttatható — kiesett beszállító, álló sor, előrehozott szállítási határidő —, mégpedig annyi idő alatt, hogy használható legyen azon a megbeszélésen, ahol a döntés születik.

Olyan nyomonkövetés, amely elég jó egy célzott visszahíváshoz, nem kényszerít egész tétel leírására.

Az emberközpontúság az a rész, amelyet a leggyakrabban kihagynak, és éppen ez dönti el az elfogadottságot. Azt a rendszert, amely az operátort adatbeviteli eszközként kezeli, egy hónapon belül kikerülik.

Hol érdemes kezdeni, és hogyan ne vegyünk kihasználatlan platformot

A valódi kérdés a sorrend. Egy működőképes sorrend:

Korlátból induljunk, ne technológiából. Nevezzük meg a szűk keresztmetszetet jelentő cellát, a legtöbb megmagyarázatlan állásidőt termelő sort, vagy azt a termékcsaládot, ahol a selejt a legrosszabb. Ha a projekt nem fogalmazható meg úgy, hogy "nem tudjuk X-et Y-ról, és ez Z-be kerül nekünk", akkor még nem áll készen.

Előbb legyen valós alaphelyzet, aztán felismerés. Gépállapot és leállási okok, ahol lehet automatikusan rögzítve, ahol nem, ott az operátor sorolja be. Szinte minden későbbi képesség ezen áll.

A végrehajtás előbb jöjjön, mint az elemzés. Az MES és az üzemi nyilvántartás megelőzi a dashboardokat és a modelleket. Az a modell, amelyet műszaknaplóról újragépelt adatokon tanítanak, a műszaknaplót fogja megtanulni.

Az ERP-illesztést az elején határozzuk meg. Döntsük el, ki birtokolja a cikktörzset, hogyan működik a munkarendelés-számozás mindkét oldalon, melyik rendszer a mérvadó a darabjegyzék változásainál, és mi történik, ha a kettő ellentmond egymásnak. Ennek a pilot utánra hagyása a leggyakoribb oka az elakadt bevezetésnek.

Olyan pilotot válasszunk, amely skálázható. Egy sor, de olyan, amelynek géptípusai és termékáramlása hasonlít az üzem többi részére — előre leírt kilépési kritériumokkal és megnevezett bevezetési felelőssel, még indulás előtt megállapodva.

A modularitás a gyakorlati védekezés a polcon maradó szoftver ellen: egy olyan platform, amelyet modulonként lehet bekapcsolni, kevesebbe kerül elhagyni, ha tévedtünk, és könnyebb szakaszosan finanszírozni.

Mi szokott elromlani

Adat, amiben senki nem bízik. Két rendszer más számot mutat ugyanarra a műszakra, és a termelési megbeszélés a számról szóló vitává válik a mögötte lévő veszteség helyett. A javítás nem látványos: bevezetés előtt, írásban, meg kell állapodni minden KPI egyetlen definíciójában — beleértve azt, hogy az OEE hogyan kezeli a tervezett állásidőt és az utómunkát —, és meg kell nevezni egyetlen nyilvántartó rendszert.

Az operátorok kikerülik a rendszert. A terminál messze van a géptől, a visszaigazolás több lépés, mint maga a rögzített munka, és semmi nem érkezik vissza ahhoz, aki beírta. Ha a műszak befejezésének leggyorsabb módja az, hogy a végén mindent utólag pótolunk, akkor pontosan ez fog történni, az időbélyegek pedig fikcióvá válnak. Mérjük meg magunk, stopperrel, a beviteli lépéseket egy valódi átálláskor.

Pilot, amely soha nem lép ki egy sorról. A pilotokat a kíváncsiság finanszírozza; a bevezetéshez keret, felelős és üzemi idő kell. Előre leírt kilépési kritériumok nélkül a sikeres pilotból állandó bemutató lesz.

Utólag méretezett integráció. Nem egyező mértékegységek, utótagban eltérő cikkszámok, két helyen karbantartott darabjegyzék. Egyik sem nehéz, és mindegyik tovább tart, mint maga a szoftver.

Platform olyan problémára, amelyet senki nem nevezett meg. Ha az üzleti indok annyi, hogy "Ipar 4.0-nak kell lennünk", akkor a rendszert telepítik, bemutatják, aztán lassan abbamarad a megnyitása.

Hogyan különböztethető meg a valódi projekt a dashboard-projekttől

A dashboardokkal semmi baj. Ez a látható rész, és ha ez az egész, akkor egy tükröt vettünk. Hat kérdés választja szét a kettőt:

1. Bármelyik szám kivált-e cselekvést, vagy csak annyit ér el, hogy egy ember észrevesz valamit? 2. Az adat az esemény pillanatában és helyén keletkezik, vagy később gépelik be jegyzetekből? 3. Ha változik a gyártósor helyzete, változik-e a terv — vagy marad úgy, ahogy kinyomtatták, miközben a valóság elsodródik tőle? 4. Van-e nyilvántartó rendszer arról, mi történt, vagy csak egy nézet más rendszerek fölött? 5. Túlélné-e, ha az elkészítője elmenne? Egyetlen karbantartott táblázatra épülő függőség figyelmeztető jel. 6. Mi történik, ha a hálózat egy órára kiesik — pufferel és utólag egyeztet az edge, vagy elveszik a műszak?

Ha az őszinte válaszok azok, hogy "észrevesz", "utólag gépelik", "marad, ahogy kinyomtatták" és "csak egy nézet", akkor a projekt riportolás. A riportolás hasznos. De nem az az elmozdulás, amelyről az oldal elején szó volt.

A digitális transzformáció a gyártásban ritkán azon bukik el, hogy nincs elég adat. Rendszerint azon, hogy az adat nem az esemény helyén keletkezik, és nem ér el semmit, ami dönt.

Hol illeszkedik ide a Meta Smart Factory

A Meta Smart Factory moduláris platform, amely a fenti rétegeket fedi le: MES, APS és MRP, SCP, WMS és logisztika, minőség (QMS), karbantartás (CMMS), gépi látás, AI/ML, energia, IIoT hardver, RTLS és ERP-integráció — helyben telepítve vagy SaaS formában.

A modulok felsorolásának oka a fenti sorrendérv: el lehet kezdeni egyetlen modullal, egyetlen megnevezett korlát ellen — gépadatgyűjtéssel a szűk keresztmetszetet jelentő cellán, vagy minőséggel azon a műveleten, ahol a selejt koncentrálódik —, és akkor jöhet a következő, amikor az első valóban használatban van, ahelyett hogy a teljes rendszert megrendelnénk azelőtt, hogy bárki beírt volna egyetlen leállási okot.

Az okos gyár építésében a platform egyik része sem veszi le a válláról azt, ami ténylegesen nehéz: megállapodni abban, mit jelentenek a számok, rendbe tenni a törzsadatokat, és olyan beviteli lépéseket tervezni, amelyeket az operátorok második kérés nélkül elvégeznek. Ezek közös munkát igényelnek, és egy konkrét üzem sorrendjéről beszélgetni hasznosabb első lépés, mint egy termékbemutató.