Mit érdemes valóban MI-vel automatizálni egy gyárban

Egy gyári MI-projekt sorsát többnyire nem a modellezés dönti el. Hanem az, hogy megnevezzük, milyen típusú problémáról van szó, megnézzük, elbírja-e ezt a végrehajtási adat, és megtervezzük, mi történik akkor, amikor a modell téved.

Szabályok, gépi tanulás, optimalizálás és nyelvi modellek: melyik melyik problémára való

A szabályok és a statisztika jönnek először, és több tiszteletet érdemelnek, mint amennyit kapnak. Ha az érték nagy részét egy olyan szabály hozza, amelyet egy mérnök le tud írni, akkor bármelyik modellt tisztességesen ehhez a szabályhoz kell mérni, nem ahhoz, hogy nem csinálunk semmit.

A gépi tanulás ott érdemli ki a helyét, ahol a bemenetek és az eredmény közötti összefüggés valós, de senki nem tudja leírni: több tucat, egymással kölcsönható folyamatparaméter, egy hiba, amely az anyagtételtől, a levegő páratartalmától és a fészek pozíciójától függ. Azokat a körülményeket ismeri, amelyeket megmutattak neki, és semmi hasznosat nem mond olyan körülményekről, amelyeket sosem látott.

Az optimalizálás külön szakterület, és rendszeresen MI-ként címkézik fel. Egy véges kapacitású üzem ütemezése, a sorrendezés az átállások minimalizálására, a képesített kezelők hozzárendelése: ezek célfüggvénnyel rendelkező korlátozásos feladatok. Címkézett példákra nincs szükségük, tisztességes műveleti időkre és korlátokra viszont igen, és ezeket általában meg kell mérni, nem feltételezni. Tervezéshez szinte mindig az a jó eszköz, amelyik ki tudja fejezni a valódi szerszám- és száradási korlátait, mert a tervezés korlátozásos, nem előrejelzési feladat.

A nyelvi modellek a legfrissebb jövevények, és nagyon konkrét helyre illenek. A dokumentum- és beszélgetésszerű munkához valók: egy beérkező érdeklődés elolvasása és strukturált formába öntése, egy hosszú karbantartási előzmény olyanra sűrítése, amit a technikus el tud olvasni, mielőtt a géphez indul, vagy annak megválaszolása, mit mond a munkautasítás egy beállításról. Nem mérőeszközök: egy csapágy meghibásodását rezgésadatból megjósoltatni velük annyi, mint kalapáccsal csavart beverni.

Milyen adat kell valójában egy gyári MI-projekthez

A modellnek olyan példák kellenek, amelyek egy helyzetet egy eredménnyel párosítanak, és annyi kontextust hordoznak, amennyiből az egyik helyzet megkülönböztethető a másiktól: egy jel vagy feltételkészlet, amely egy megrendeléshez, géphez, szerszámhoz, anyagtételhez, kezelőhöz kötődik, és egy időbélyeg, amely igaz. Az időbélyeg többet számít, mint gondolnánk. Ha a visszajelentések a műszak végén, utólag kerülnek be, akkor az adott műszak minden eseménye nagyjából ugyanazt az időpontot kapja, és minden, ami sorrendtől vagy időtartamtól függ, az adatrögzítési szokást tanulja meg, nem a folyamatot.

Az eredményoldal általában rosszabb állapotban van. A prediktív karbantartáshoz meghibásodásként rögzített meghibásodások kellenek, okkal és dátummal, nem üres okmezővel ellátott nem tervezett leállások. A minőség-előrejelzéshez a selejtet a műveletre és az azt okozó hibatípusra kell könyvelni, nem havi számmá összevonni. Az előrejelzéshez olyan felhasználási előzmény kell, amelyet nem írtak csendben felül a készletkorrekciók. A legtöbb üzemben a bemenetek a historianben vannak, az eredmények pedig egy karbantartási füzetben vagy valakinek a táblázatában.

A próba nem az, hány gigabájt van a historianben, hanem az, hogy ki tud-e nyerni egyetlen gyártósorra és egyetlen termékcsaládra egy évnyi adatsort, amelyben minden sor hordozza a körülményeket és az eredményt, és két folyamatismerő ember egyetért abban, hogy a sorok igazak. Ha ez a lekérés egyheti kézi egyeztetés, akkor nem a modell a projekt, hanem a rögzítés. Ezért a MES- és historian-adatok minősége a valódi szűk keresztmetszet, és semmilyen modellezési kifinomultság nem pótolja azt, amit soha nem rögzítettek.

Kereslet- és fogyasztás-előrejelzés, ahol a megtérülés a legközelebb van

Az előrejelzésnél a legrövidebb az út a pénzig, mert az alternatíva láthatóan gyenge: a legtöbb üzem a tavalyihoz hozzáad néhány százalékot, vagy elkér az értékesítéstől egy számot, ami valójában célszám. Egy olyan modell, amely rendeléselőzményt, szezonalitást, vevőmixet, nyitott pipeline-t és naptárhatásokat használ, a rendszeres, ismétlődő keresletű cikkeknél ezt megveri. A szakaszos és projektvezérelt cikkeknél — amelyek gyakran a cikkszámok többségét, de a volumen kis részét adják — általában nem, és egy naiv vagy Croston-féle alapvonalat nehéz felülmúlni. A tisztességes megoldás először szegmentálja a katalógust, és ezeket a cikkeket készletezési szabályra és józan ítéletre hagyja.

Az érték nem magában az előrejelzésben, hanem tőle lejjebb jelenik meg: mozdul a biztonsági készlet, változik a hosszú átfutású tételek beszerzési időzítése, és ritkulnak azok a vészátállások, amelyek szétverik az ütemtervet. Egy előrejelzési pontossági százalék egy dián nem haszon; a készletnapok és a sürgősségi beszerzések száma az.

Prediktív karbantartás, csak ott, ahol a hibamód valóban előre jelezhető

Itt minden azon múlik, hogy a meghibásodás fokozatosan alakul-e ki, és hagy-e nyomot valamiben, amit mérni tudunk. Csapágykopás, kiegyensúlyozatlanság, tengelyvonal-eltérés, egy szűrő vagy hűtőkör fokozatos eltömődése, a hidraulikanyomás elsodródása, ugyanazon a műveleten lassan felkúszó motoráram: ezek hetek vagy hónapok alatt alakulnak ki — néha csak órák alatt, ami rendszerint már túl késő ahhoz, hogy érdemes legyen műszerezni —, és meglátszanak a rezgésen, az áramon, a hőmérsékleten vagy a nyomáson. Egy modell észreveszi őket, és sokszor egy jól megválasztott küszöbérték is, ezért számít itt az egyszerű statisztikával való összevetés.

Egy tönkremenő vezérlőpanel, egy rossz lapka miatt eltört szerszám, egy kezelői hibából eredő sérülés: ezek gyakorlatilag pillanatszerűek, és egyetlen modell sem jelzi előre őket olyan trendből, amely nem létezik.

A második feltétel az, hogy a figyelmeztetés olyan időt nyerjen, amivel kezdeni is tud valamit. Ha az alkatrésznek hosszú az átfutási ideje, és a sor hétvége előtt nem állhat le, akkor a megtérülő beruházás egy pótalkatrész-készletezési szabály, nem egy modell. A beavatkozási ablakot még a szenzorköltségvetés előtt számolja ki.

Minőség-előrejelzés és selejtcsökkentés

A minőségben van általában a legtöbb pénz, és itt a legszigorúbbak az adatkövetelmények. A vonzó változat a futás közbeni körülményekből jelzi előre, mely darabok vagy tételek vannak veszélyben, hogy valaki még a selejt keletkezése előtt tudjon beavatkozni, ne a végellenőrzésen szembesüljön vele.

Akkor működik, ha a folyamat olyan felbontásban van műszerezve, mint amilyen felbontásban előre akarunk jelezni, és ha a selejt valódi okkóddal, a műveletre könyvelve kerül rögzítésre. Csendben akkor bukik meg, ha a selejtet a megrendelés végén, a megrendelés egészére könyvelik, mert akkor a modell nem tudja megmondani, melyik körülmény melyik hibát okozta.

Egy látványtalan lépés még minden modell előtt megtéríti magát: a selejtokok rögzítése a gépnél, abban a pillanatban, egy rövid, a kezelő számára értelmes oklistából. Sok olyan üzem, amely minőség-előrejelzést kér, már pusztán ebből az adatból rájön, hogy kevés ok adja a veszteség nagy részét, és a legnagyobbat egy műszaki változtatással lezárja. Ez jó eredmény, nem bukott projekt.

MI a gyártásütemezésben: miért optimalizálási és nem előrejelzési feladat

Ha a terv minden héten megcsúszik, annak ritkán az intelligencia hiánya az oka, hanem általában a korlátoké. Az változtat rajta, ha az ütemező figyelembe veszi a közösen használt szerszámokat, az átállási családokat, a kezelői képesítéseket, a kötési időket és azokat a karbantartási ablakokat, amelyeket tartani is szándékozik.

A tanulás itt egy szűk, de valós módon segít: a műveleti időknél. Egy olyan ütemterv, amely évek óta újra nem mért normaidőkre épül, pontosan rossz számokat használ, a MES-en át rögzített tényleges időtartamok pedig frissíteni tudják azt, amivel az ütemező dolgozik. Egy ütemezési ajánlatot aszerint ítéljen meg, milyen korlátokat tud kifejezni, és milyen gyorsan tervez újra, ha valami elromlik: azt a tervet, amelynek újragenerálása egy éjszakát vesz igénybe, a reggeli megbeszélésen kézzel felülírják.

Anomáliadetektálás energia- és folyamatjeleken

Az anomáliadetektálás megtanulja, hogy néz ki a normális, és jelzi az eltérést. Olyan folyamatos jelekhez való, ahol sok a jó viselkedés és kevés a címkézett hiba: ciklusonkénti energiafelvétel, sűrítettlevegő-fogyasztás, hűtőgép teljesítménye, egy olyan folyamatjel, amelynek alakja stabil, amikor minden rendben van.

Az erőssége az, hogy arra is reagál, amire senki nem számított. A gyengesége, hogy csak annyit mond, valami szokatlan, azt sosem, hogy mi a baj — és az az üzem, amely megmagyarázhatatlan riasztásokat kap, megtanulja figyelmen kívül hagyni őket. A tervezői munka nem a detektor, hanem az útvonal: melyik riasztás kihez megy, mi az első ellenőrzés, és hogyan rögzül a reakció, hogy a következő ugyanilyen riasztás már előzménnyel együtt érkezzen.

MI az értékesítésben és a vevőkiszolgálásban, ahol a munka dokumentumszerű

Egy gyártó cég kereskedelmi oldala dokumentumokon és beszélgetéseken fut: érdeklődések, specifikációk, árajánlatok, rendelés-visszaigazolások, szállítási kérdések, reklamációk. Valóban ide illenek a nyelvi modellek, mert a munka olvasás, kinyerés, fogalmazás és összefoglalás.

Konkrétan: egy beérkező érdeklődés lebontása cikkre, mennyiségre, kért határidőre és különleges követelményekre, a korábbi árajánlatokkal egymás mellett. Egy e-mail-szál CRM-rekorddá sűrítve, amely hordozza a tett vállalást és a következő lépést.

Két szabály óvja meg ezt az elromlástól. A modell fogalmaz, és ember küld, legalábbis addig, amíg az adott munkafolyamatban ki nem derül a hibaarány. És minden tényszerű adat — ár, átfutási idő, készlet, ígért dátum — a nyilvántartó rendszerből jön, nem a modelltől, amelynek egy kikeresett értéket kell idéznie, sosem generálnia. Az a CRM-automatizálás, amely átfutási időt talál ki, rosszabb a semmilyennél, mert elkötelezi a céget.

A várható haszon nagyságának felmérése, mielőtt bármit megvenne

Nevezze meg a veszteséget olyan egységekben, amelyeket az üzeme már most is mér: havi selejtköltség az adott termékcsaládon, nem tervezett állásidő órái a szűkkeresztmetszet-gépen, megszorozva azzal, amit ott egy óra fedezetben ér — nem gépórarátában —, sürgősségi fuvarköltség, az előrejelzéssel mozdítható alkatrészekben álló készlet, és a rendszerek közötti újragépelésre fordított heti órák.

Ezután pesszimistán becsülje meg, ennek a veszteségnek hány százalékát tudná az alkalmazás egyáltalán megfogni. A prediktív karbantartás nem szünteti meg az állásidőt; legjobb esetben néhány nem tervezett leállást tervezetté alakít, azokra a hibamódokra, amelyeket lefed. Egy minőségi modell nem tünteti el a selejtet; lerövidíti az időt aközött, hogy a folyamat elromlik, és hogy valaki ezt észreveszi.

Ha ez a tisztességes szám a teljes, tényleges élettartamra számolt költséggel szemben — beleértve az integrációt és azokat az embereket, akik üzemeltetni fogják — nem éri el azt a küszöböt, amelyet a pénzügy bármely más, ekkora beruházásra alkalmaz, akkor a projekt tudományos kísérlet. Ez megengedett, de akkor így is kell finanszírozni és megítélni.

Mennyibe kerül valójában az integráció

A modell általában az olcsó rész; a költség az illesztéseknél keletkezik. Először a jeleket kell levenni a gépekről, és egy valódi üzem vegyes géppark: van, ami OPC UA-t beszél, van, ami Modbust vagy egy soros protokollt, van, amelyik egy száraz kontaktust kínál, és van néhány zárt vezérlés, ahová retrofit szenzor kell az orsóra, a hidraulikakörre vagy a tápvezetékre. Utána a kimenetnek olyan helyre kell megérkeznie, ahol cselekvést vált ki: egy képernyőre, amelyet a kezelő amúgy is néz, egy karbantartásban megnyitott munkamegrendelésbe, egy korlátba, amelyet az ütemező megkap, egy minőségi zárolásba.

Ezután jön a törzsadat-egyeztetés, amelyet senki nem árazik be. Rendszerenként utótaggal eltérő cikkszámok, egymásnak nem megfelelő mértékegységek, két helyen karbantartott darabjegyzék, gépazonosítók, amelyek megváltoztak a sor átrendezésekor. Semmi ebből nem nehéz, és mindegyik tovább tart, mint a szoftver. Az az ajánlat, amely a modellt beárazza, az illesztéseket pedig „később pontosítandó integrációként” hagyja ott, nem ár.

Ki üzemelteti a modellt, és mi történik, ha téved

Minden üzembe helyezett modellnek kell egy névvel megnevezett gazda, és a beszerzési kérdés az, hogy ez ki lesz az Ön szervezetében. Ennek az embernek tudnia kell, mire tanították, mely körülmények esnek ezen kívül, miért adott egy adott kimenetet, és hogyan lehet kivenni a hurokból anélkül, hogy a termelés leállna. Egy modellnek, amely megszűnik válaszolni, arra kell visszaesnie, ami előtte vezérelte a folyamatot — a mintavételi tervre, a küszöbértékre, a kezelői ellenőrzésre —, nem pedig nyitott kapura vagy leblokkolt sorra. Élesítés előtt döntse el, melyik lesz ez.

A magyarázhatóság az üzemben nem filozófiai kérdés, hanem az elfogadás feltétele. Egy olyan javaslat, amely megmondja, melyik jel mozdult, mennyivel, és milyen alapvonalhoz képest, meg is valósul. Egy indoklás nélküli pontszámot felülírnak, és amint a felülírás rutinná válik, a rendszer díszlet.

A túlriasztás gyorsabban rombolja a bizalmat, mint az elmulasztott észlelés — ugyanazért, amiért az ellenőrzőállomáson a szükségtelen selejtezés (a jó darabok kiszűrése): a téves riasztás azonnal és mindenki számára látható, egy elmulasztott eset pedig láthatatlan marad, amíg a meghibásodás be nem következik. A riasztási rátát az üzemben ténylegesen rendelkezésre álló figyelemhez tervezze, a bizonytalan sávot pedig emberhez irányítsa, ne a sorhoz.

Irányítás, elsodródás és a karbantartási teher, amelyet senki nem tervez be

A modell pillanatfelvétel a folyamatáról abban a pillanatban, amikor betanították — a folyamat pedig mozog: új beszállító, felújított szerszám, alkatrészrevízió, átrendezett sor, megváltozott termékmix, egy kicsit másmilyenre cserélt szenzor. Mindegyik annyit tolhat a bemeneteken, hogy a tegnapi modell ma már csendben téved, és a hibamód nem hibaüzenet, hanem fokozatosan romló tanács.

A bemeneteket is figyelje, ne csak a kimeneteket, mert a bemeneti elsodródás előbb látszik, mint az eredmény romlása. Tartson félretett tesztkészletet valódi esetekből, határeseteket is beleértve, hogy egy új modellt tisztességesen össze lehessen hasonlítani a jelenlegivel. Verziózza a modellt, és rögzítse, melyik verzió adta melyik javaslatot; egy újratanítás után a tegnapi kimenetek más bírótól származnak.

És tervezze be a folyamatos ráfordítást. Egy éles modell karbantartott eszköz, közelebb áll egy termelőberendezéshez, mint egy megvásárolt riporthoz. Ha senkinek nincs beosztott ideje az újratanításra, a riasztások átnézésére és annak ellenőrzésére, hogy az adat még mindig megérkezik, addig romlik, amíg az emberek abba nem hagyják a használatát.

Egy reális első projekt, átvételi kritériumokkal

Válasszon egyetlen megnevezett veszteséget egyetlen gyártósoron vagy termékcsaládon, olyan mondatban megfogalmazva, amelyben szám is van: ennyit selejtezünk ezen a műveleten, ennyi szűkkeresztmetszet-órát veszítünk ezen a gépen, ennyi készletet tartunk, mert ezt a családot nem tudjuk előre jelezni. Ha a projektet nem lehet így megfogalmazni, akkor még nem áll készen.

Mielőtt bármit megvenne, csinálja meg az adatkinyerést. Egy év, egy gyártósor, körülmények és eredmények ugyanabban a sorban, és két folyamatismerő ember, aki megerősíti, hogy a sorok igazak. Utána mérje össze az egyszerű alternatívával: egy küszöbértékkel, egy szabályozókártyával vagy a jelenlegi tervező ítéletével.

Az átvételi kritériumokat élesítés előtt írja meg üzemi mértékegységekben, párokban, hogy a kompromisszum kimondott legyen. Prediktív karbantartásnál: megnevezett számú lefedett hibamód elkapása legalább egyheti előjelzéssel, egy havi téves riasztásszám felső korlátjával szemben. Előrejelzésnél: megadott készletnap-csökkenés a modellezett családokon, a készlethiányok növekedése nélkül. Minőségnél: megadott selejtcsökkenés a célműveleten a tavalyi ugyanezen hónapokhoz képest, a folyamatváltoztatásokkal együtt rögzítve.

Nevezze meg a gazdát, a hibaesetre szóló viselkedést és az újratanítási ütemezést ugyanabban a dokumentumban, és tűzzön ki felülvizsgálati dátumot, tisztességes leállítási lehetőséggel. Egy olyan első projekt, amely bizonyítékok alapján hozott „nem bővítjük” döntéssel zárul, siker. Egy pilot, amely tartós bemutatóvá válik, nem.

Hol illeszkedik a Meta Smart Factory

A Meta Smart Factory moduláris, és ez itt azért számít, mert az MI- és gépitanulás-modul a végrehajtási rétegre ül rá, nem mellé. A MES adja az eseményeket és a kontextust, az IIoT-konnektivitás és az OPC UA a gépjeleket, a Minőség a selejtet az okokkal, a Karbantartás a meghibásodási előzményt, az APS pedig fogyasztja a kimenetet ott, ahol a válasz ütemterv és nem előrejelzés.

Egy modullal, egyetlen megnevezett korlát ellen is elindulhat, és a következőt akkor teheti hozzá, amikor az első már használatban van. Amit egyetlen platform sem vesz le a válláról, az a nehéz rész: megegyezni abban, mit jelentenek a számok, elérni, hogy az okok a gépnél rögzüljenek, és eldönteni, ki a modell gazdája akkor, amikor téved. Egy konkrét üzemre végiggondolni ezt a sorrendet hasznosabb első beszélgetés, mint egy bemutató — mert a bemutató mindig működni fog.