Ipari adatgyűjtési rendszer útmutató üzemeknek

A műszak végén a termelési vezető még mindig papírlapokról, gépnaplókból és több Excel-táblából próbálja összerakni, mi történt aznap. Mennyi volt a tényleges állásidő? Melyik rendelés késik? Miért romlott a selejtarány? Egy ipari adatgyűjtési rendszer útmutató akkor hasznos, ha nem a szenzorokkal vagy a képernyőkkel kezdődik, hanem ezekkel a kérdésekkel.

Sok üzemben már rendelkezésre áll az adat valamilyen formában. A PLC-k jeleket kezelnek, a gépek eseményeket rögzítenek, az ERP-ben vannak rendelési és készletadatok, a karbantartás pedig saját nyilvántartást vezet. A probléma nem feltétlenül az adathiány. Inkább az, hogy az információ szétszórt, eltérő időpontokban frissül, és az embereknek kell összekötniük a részeket.

Mit oldjon meg az ipari adatgyűjtési rendszer?

Az adatgyűjtés önmagában nem üzleti cél. Attól, hogy egy gyártósor másodpercenként több száz értéket tárol, még nem lesz gyorsabb a gyártás, kevesebb a selejt vagy kiszámíthatóbb a szállítás. A rendszer értékét az adja, hogy egy felelős vezető vagy operátor időben és megbízhatóan tud-e dönteni belőle.

Érdemes ezért először egy konkrét működési helyzetet kijelölni. Például a gyártási terv rendszeresen teljesülni látszik délelőtt, majd délután kiderül, hogy egy visszatérő géphiba miatt a műszak már nem hozható be. Vagy a vállalat tudja, hogy sok a rövid megállás, de nem tudja, melyik termék, szerszám, alapanyag vagy művelet áll mögötte.

Jó kiinduló kérdések lehetnek:

• Mely döntésekhez kell ma több forrásból manuálisan adatot gyűjteni?
• Hol keletkeznek olyan kiesések, amelyeket csak utólag vesznek észre?
• Mely adatokat írják be többször különböző rendszerekbe?
• Mely mutatók körül alakul ki rendszeresen vita, mert nincs egységes adatforrás?

Ha ezekre nincs egyértelmű válasz, a projektet nem érdemes eszközlistával indítani. Előbb fel kell tárni a folyamatot: hol keletkezik az információ, ki használja, ki módosítja, és hol vész el a jelentése.

Milyen adatot érdemes gyűjteni?

A leggyakoribb hiba a túl széles indulás. Egy új rendszerrel könnyű elkezdeni minden elérhető gépjelet, hőmérsékletet, ciklusidőt és állapotváltozást eltárolni. Ennek lehet műszaki indokoltsága, különösen minőségbiztosítási, visszakövethetőségi vagy karbantartási környezetben. Operatív fejlesztési célra azonban a túl sok, értelmezetlen adat gyakran csak újabb jelentési terhet hoz létre.

A legtöbb termelő vállalatnál néhány alapvető kategória már jelentős átláthatóságot ad: a gép vagy cella állapota, a termelt mennyiség, a selejt és annak oka, az állásidő oka, a ciklusidő, valamint az adott időszakhoz rendelt termék vagy rendelés. Ezeket szükség esetén egészítheti ki energiafelhasználás, környezeti adat, szerszámállapot vagy alapanyag-azonosító.

Nem minden adat gyűjthető ugyanolyan megbízhatósággal. A gépből automatikusan érkező állapotjel például objektívnek tűnik, de attól még tisztázni kell, mit jelent. A „fut” jel valóban termelést jelent, vagy a gép üresjáratban működik? A „hiba” jel egy konkrét zavart jelöl, vagy többféle eseményt von össze? Az adatmodellnek a fizikai folyamatot kell pontosan leírnia, nem csak a vezérlőben meglévő címkéket lemásolnia.

Az is reális, hogy bizonyos okokat emberi visszajelzésből lehet csak megérteni. Egy állásidő automatikus érzékelése és az állás tényleges üzemi oka két különböző információ. Az operátornak ezért rövid, egyértelmű és a munkavégzésbe illeszthető választási lehetőségekre van szüksége. Ha tíz percig kell kategóriákat keresnie egy terminálon, az adatminőség is romlik, és a rendszerrel szembeni ellenállás is nő.

Az ipari adatgyűjtési rendszer útmutatója: a folyamat feltérképezése

Egy eredményes bevezetés jellemzően nem azzal indul, hogy milyen SCADA, gyártásirányítási vagy felhőplatform legyen. Először a jelenlegi információáramlást kell végignézni egy teljes műszakon vagy rendelési cikluson keresztül.

Ki jelzi, hogy egy gép leállt? Hol rögzítik az okot? Mikor kerül át az információ a termelési tervbe, a karbantartáshoz vagy a műszakvezetőhöz? A termelési mennyiség mikor és hogyan kerül az ERP-be? Ha eltérés van a fizikai valóság és a rendszer között, ki javítja, milyen szabály alapján? Ezek a kérdések sokszor többet árulnak el a fejlesztés irányáról, mint egy berendezés adatlapja.

A feltérképezés során gyakran kiderül, hogy nem a mérés hiányzik, hanem a felelősségi határ bizonytalan. Például a gépkezelő papíron vezeti a darabszámot, a műszakvezető Excelben összesít, az adminisztráció pedig később rögzíti az eredményt egy vállalatirányítási rendszerben. Ilyenkor három külön adatforrás jön létre ugyanarról az eseményről, és egyik sem garantáltan aktuális.

A jó célállapot nem feltétlenül teljes automatizálás. Lehet, hogy elegendő a gépadat automatikus begyűjtése, az eltérések operátori jóváhagyása, majd a hitelesített eredmény átadása az ERP felé. A lényeg az, hogy minden adatnak legyen világos forrása, tulajdonosa és felhasználási célja.

Integráció nélkül csak újabb adatsziget keletkezik

Egy önálló termelési kijelző látványos lehet, de kevésbé értékes, ha a rendelések, cikkszámok, műveleti előírások és készletmozgások továbbra is manuálisan kerülnek át egyik rendszerből a másikba. Az ipari adatgyűjtési rendszernek ezért az üzemi és az üzleti rendszerek kapcsolatát is kezelnie kell.

A gépszint és a vállalati rendszer között eltérő az adat ritmusa. A PLC másodpercek alatt jelez állapotváltozást, míg az ERP-nek lehet, hogy csak a lezárt művelet, a jóváhagyott mennyiség és a selejt oka szükséges. Nem célszerű minden nyers jelet az ERP-be továbbítani. A megfelelő architektúra szétválasztja a valós idejű üzemi adatokat, az értelmezett gyártási eseményeket és a pénzügyi vagy logisztikai jelentőségű tranzakciókat.

Ez azért is fontos, mert az integráció hibái az üzem működésében jelennek meg. Ha egy rendeléshez rossz cikkszám kapcsolódik, a kimutatás félrevezető lesz. Ha a termelési visszajelzés késik, a készlet és a beszerzés rossz döntésekből dolgozhat. Ha az átadás nem ellenőrzött, ugyanaz a tétel akár kétszer is megjelenhet a rendszerben.

Az interfészeknél ezért szükség van azonosítókra, időbélyegekre, hibakezelésre és visszaellenőrzésre. A kérdés nem csak az, hogy az adat átmegy-e, hanem az is, hogy hiba esetén észlelhető-e a hiány, újraküldhető-e az esemény, és egyértelműen rekonstruálható-e, mi történt.

Megbízhatóság, jogosultság és üzembiztonság

Egy termelési környezetben az adatgyűjtés nem állhat a folyamatos működés útjába. Ha a hálózati kapcsolat megszakad, a gyártásnak ettől még folytatódnia kell. Ha egy központi szolgáltatás nem elérhető, nem veszíthetnek el ellenőrizetlenül események. Ezért már a tervezéskor tisztázni kell, mely funkciók igényelnek valós idejű működést, mely adatok tárolhatók helyben átmenetileg, és hogyan történik a későbbi szinkronizáció.

Az adatbiztonság sem kizárólag informatikai részletkérdés. A termelési adatok üzleti szempontból érzékenyek lehetnek, a jogosulatlan módosítás pedig minőségi, elszámolási vagy megfelelőségi problémát okozhat. Egy jól kialakított rendszerben szerepkörök szabályozzák, ki láthatja, rögzítheti, javíthatja vagy hagyhatja jóvá az adatot. A kritikus módosítások naplózhatók, így utólag nem emlékezetből kell megállapítani, miért változott egy érték.

A technológiai választás itt valóban helyzetfüggő. Van, ahol a helyi, üzemi infrastruktúra a megfelelő döntés a késleltetés, a kapcsolati korlátok vagy a szabályozási elvárások miatt. Más vállalatnál a központi, több telephelyet összekötő környezet ad jobb áttekintést. Gyakori megoldás a kettő kombinációja: helyi adatfeldolgozás, központi riportolás és kontrollált adatátadás.

Hogyan mérhető, hogy a fejlesztés megtérül-e?

A megtérülés nem csak a munkaórák csökkenése. Egy adatgyűjtési rendszer értéke megjelenhet abban, hogy hamarabb észlelnek egy romló trendet, kevesebb a sürgős egyeztetés, pontosabb a vállalási idő, vagy a karbantartás nem kizárólag hibabejelentésekre reagál. Ezeket már a kezdéskor érdemes mérhető célokhoz kötni.

Lehet cél például az állásidők hiteles rögzítési arányának növelése, a műszakjelentés elkészítési idejének csökkentése, a készleteltérések mérséklése vagy a termelési terv teljesítésének korábbi előrejelezhetősége. A jó mutató nem pusztán azt jelzi, hogy mennyi adat gyűlt össze. Azt mutatja meg, javult-e a működés.

Érdemes egy jól körülhatárolható területtel kezdeni, ahol az üzleti fájdalom ismert, az érintettek bevonhatók, és az eredmény összehasonlítható. Egy gépsor, egy kritikus művelet vagy egy visszatérő minőségi probléma gyakran jobb első lépés, mint a teljes üzem egyszerre történő lefedése. A tapasztalatok alapján aztán pontosítható az adatmodell, a kezelői felület és az integrációs szabályrendszer.

A legjobb rendszer végül nem az, amelyik a legtöbb adatot gyűjti. Hanem az, amelyik egy műszak közben is megmutatja, hol kell beavatkozni, és amelyre a termelés, a karbantartás és a vezetés ugyanazzal a bizalommal tud támaszkodni.