Karbantartás-menedzsment rendszer (CMMS)

META Smart I/O eszközökből vagy meglévő PLC-kből származó szenzoradatokra. Jellemző bemenetek a rezgés, a hőmérséklet, az áramerősség és a ciklusszám.

Igen, a munkalapok, ellenőrzőlisták és géptörténet elérhetők telefonokon, táblagépeken és MSF-paneleken.

Igen. A MES-ben rögzített állásidő-okok automatikusan karbantartási bejelentéseket hoznak létre.

A megelőző tervek dátum vagy számláló alapján, a munkalapok, a pótalkatrész-foglalások és a géptörténet mind pusztán a rögzített adatokból működnek, szenzoradat nélkül. Az első hónapok hozzák a hibakódolást, a terv szerinti teljesítést és az állásidő-történetet, és később pontosan ehhez az alapvonalhoz lehet mérni bármilyen állapotfigyelést. Az elmúlt tizenkét hónap saját nem tervezett leállásainak besorolásából derül ki, melyik gépre éri meg egyáltalán rezgésérzékelőt tenni.

Mindazt, ami progresszív, mérhető előjel nélkül következik be. A vezérlőpanelek, az I/O-kártyák és a legtöbb kétállapotú érzékelő nagyjából véletlenszerűen megy tönkre, az ütközés, a beállítási hiba és a kezelői rongálás pedig esemény, nem folyamat. Egy védelmi elem, például egy biztonsági szelep vagy egy reteszelés semmit nem ad magáról egészen addig, amíg be nem következik az, ami ellen véd, ezért azt időszakos működéspróbával ellenőrzik, nem monitorozzák. A rezgés és az áramfelvétel a forgó alkatrészek mechanikai kopását olvassa jól, ezeket a hibamódokat egyáltalán nem.

Kevesebb, mint amit a modellközpontú ajánlatok sugallnak, mert az első használható határértékek mérnöki számításból jönnek, történeti adat nélkül is: a csapágy hibafrekvenciái a geometriából és a fordulatszámból, a szűrőn eső nyomáskülönbség, a gép saját, azonos terhelésen mért normáljához képesti hőmérséklet-emelkedés. Az anomáliadetektáláshoz annyi egészséges üzemóra kell, amennyi lefedi a termék, a sebesség és a műszakok szerinti normális szórást. A hátralévő élettartam becsléséhez viszont tönkremenetelig futtatott esetek kellenek, amilyenekkel a legtöbb üzem egyszerűen nem rendelkezik.

Nevesített gazdával számoljon a karbantartás oldalán, ne azzal, hogy mindenki hetéből lecsípünk egy szeletet. A neheze az elején van: géphierarchia, a valós gyakorlathoz illeszkedő megelőző tervek és egy egyszer közösen elfogadott hibakódrendszer. Az éles indulás után a visszatérő munka a riasztások szűrése és a munkalapok lezárása strukturált megállapítással, felhasznált alkatrésszel és számlálóállással. A riasztások mennyiségét ahhoz igazítsa, amennyit egy ember ténylegesen ki tud vizsgálni, különben egy idő után senki nem nyitja meg őket.

Az MTBF az üzemidő osztva a meghibásodások számával, az MTTR a teljes javítási idő osztva a javítások számával, mindkettő a munkalap mezőiből áll össze: bejelentés időpontja, javítás kezdete és vége. Üzemóra-számláló vagy MES-ből érkező futásjel nélkül csak a meghibásodások közti naptári idő áll rendelkezésre, így egy keveset járó gép saját magának szépíti az MTBF-jét. A javítási mutató is mást jelent, ha a bejelentéstől mérjük, mert abban benne van a várakozás és az alkatrész-beszerzés, mintha a javítás kezdetétől, ami a tényleges szerelési idő.

Nem kell, önállóan is működik. A kezelők HMI-ről vagy böngészőből adják fel a bejelentéseket, a tervek, a munkalapok és a pótalkatrész-nyilvántartás pedig semmilyen további rendszert nem igényel. Az APS annyit tesz hozzá, hogy az egyeztetett karbantartási időablak ütemezési korlátként jut el a tervezőhöz, így nem múlik egy folyosói megbeszélésen, amit valaki elfelejt. Enélkül kézzel egyeztet időablakot a termeléssel, ami teljesen szokásos indulás, és sok üzemben hosszú távon is elég.

Önmagában ritkán. Egy előjel csak akkor segít, ha megbízhatóan hosszabb időt ad, mint az adott alkatrész beszállítói átfutási ideje, és a meghibásodás bizonytalan időpontja csak az egyik oka annak, hogy biztonsági készletet tartunk: az átfutási idő ingadozása, a minimális rendelési mennyiség és az egy cikkszám több gépre is ott van mellette. A modul lefoglalja az alkatrészt a munkalapra, és beszerzési igényt indít, ha a készlet nem elég. Először az előjelekből csináljon tervezett időablakot, a készletszintekhez pedig egy év tapasztalat után nyúljon hozzá.