Hogyan alakítsuk a PLC- és SCADA-diagnosztikát megbízható karbantartássá a vezérlés veszélyeztetése nélkül.
A jel már létezik a vezérlési rétegen belül
Egy PLC gyakran akkor is tovább működik, amikor az állapota romlik. Először a diagnosztikai előzményeket nézze meg, ne a mimikát. A kommunikációs megszakadások lassan gyakoribbá válnak. Egy távoli I/O-modul időszakos hibákat jelez. A SCADA-rétegen a kiesések már bármilyen termelésleállás előtt ismétlődnek. Ezek korai figyelmeztetések, nem zajok. A modern vezérlők már eleve hozzáférhetővé teszik ezeket az adatokat. Nem mindig van szükség új szenzorhálózatra. A nehéz rész az, hogy minden jelhez hasznos célt rendeljünk. Ez a cél egy valós eszközhöz kapcsolt karbantartási rekord.
1. lépés — A vezérlő valódi állapotjelzéseinek begyűjtése
A prediktív logikának olyan jeleket kell használnia, amelyeket az eszköz ténylegesen támogat. Ne feltételezze, hogy minden PLC ugyanazokat az állapotadatokat teszi elérhetővé. Egy Allen-Bradley ControlLogix (például egy Allen-Bradley ControlLogix Processor) vagy CompactLogix rendszerben figyelje az olyan kommunikációs kártyák EtherNet/IP-portjának hibaszámlálóit, mint a 1756 ControlLogix Communications Module. Kövesse a javítható hibák számát minden távoli állomásnál. Egy Modbus TCP-n elérhető Woodward vezérlőnél (a Woodward I/O modules egységeket figyelő rendszerekben) kérdezze le a karbantartás szükségességét és az élettartamkorlátot jelző regisztereket. Egyes eszközök közvetlenül jelzik a belső hibákat vagy a rendellenes tápellátást.
-
1. lépés — Listázza az összes olyan diagnosztikai adatot, amelyet a célzott eszköz valóban biztosít.
-
2. lépés — Hetente kövesse nyomon a számlálók alakulását, mivel a gyakoriság jobban megmutatja a romlást, mint egyetlen esemény.
-
3. lépés — Csak emelkedő trend vagy meghatározott időtartam esetén adjon riasztást, ne egyetlen rövid kiugrásra.
-
4. lépés — Minden számlálót egyetlen azonosított eszközhöz kapcsoljon, soha ne egy általános rackhez.
2. lépés — Ne alakítson minden riasztást munkajeggyé
A SCADA felkelti a kezelő figyelmét. A karbantartás dönti el, ki fogja meg a szerszámot. Ha összekeveri a kettőt, a valódi romlás eltűnik a felesleges munkajegyek között. A magas hőmérsékletre vonatkozó riasztás egyszerűen lehet a normál termelési működés része. Egy rövid kiesés magától is helyreállhat. Ezért a munkavégzés létrehozása előtt minősítse az állapotot. Az ismétlődés többet számít egyetlen eseménynél. Az időtartam gyakran fontosabb, mint a csúcserősség. A riasztási határérték alatti lassú eltolódás még indokolhat helyszíni ellenőrzést. Emellett különítse el a nyugtázást a befejezéstől. A kezelő a hiba észlelését nyugtázza. Ez nem bizonyítja, hogy a berendezést megjavították.
-
1. lépés — Olyan szabályt adjon hozzá, amelynek a munkavégzés kiváltásához hét napon belül három ismétlődésre van szüksége.
-
2. lépés — Adja hozzá a környezetet: az eszközt, a trendet és a korábbi javításokat.
-
3. lépés — Csak a munka elvégzése és rögzítése után zárja le a munkajegyet.
A javítási előzmények pontosítják a modellt
A historizáló adatok megmutatják, mi történt a hiba előtt. A karbantartási előzmények pedig azt mutatják meg, mi történt azután, hogy valaki megvizsgálta a berendezést. Tegyük fel, hogy egy kommunikációs hiba folyamatosan munkajegyeket generál. A technikusok minden alkalommal hardverhibától mentesnek találják a rendszert. Valószínűleg túl érzékeny a kiváltó feltétel. Ha azonban ugyanaz az esemény mindig egy csatlakozó cseréjével végződik, bízzon ebben a mintázatban. Ez korábbi beavatkozást érdemel. Az elvégzett munkáról szóló adatok különválasztják a tünetet az októl. Egy látszólagos I/O-hiba például visszavezethető egy tápellátását elvesztő terepi eszközre. A modul cseréje ilyenkor nem a megfelelő eszközt javítaná. A lezárási megjegyzés megőrzi a valódi okot a következő műszak számára.
Integráljon a kockázatok növelése nélkül
Egy CMMS nem válhat kiemelt jogosultságú vezérlőrendszer-klienssé. A diagnosztikai adatokat adatkapcsolati rétegen keresztül vezesse ki. A trendet SCADA-ból vagy historizálóból származtassa. Szabványosított állapot- és diagnosztikai információkhoz használjon csak olvasási jogosultságú OPC UA-t. Ezután egy integrációs szolgáltatás API-n keresztül továbbítja a minősített eseményeket a karbantartási platformnak. Így a karbantartási forgalom távol marad az időkritikus logikától. A prediktív számításoknak nem kell a vezérlőben futniuk. Emellett védje a hálózatot. Egy karbantartási alkalmazásnak ritkán van szüksége PLC-memória írására. Korlátozza csak olvasási jogosultságra. Mielőtt bármilyen automatizált kapcsolat elérné az éles rendszert, kövesse az üzem módosításkezelési folyamatát. Végül szinkronizálja az órákat. Ha egy SCADA-esemény időbélyege percekkel eltér a CMMS-rekordétól, a hiba rekonstrukciója meghiúsul.
Összegzés és gyakorlati tanácsok
A prediktív karbantartás türelmet és tiszta adatáramlást igényel, nem ötletes irányítópultokat. Először csak azokat az állapotjelzéseket gyűjtse be, amelyeket az eszközei valóban biztosítanak. Másodszor ismétlődéssel és időtartammal minősítse az állapotot, mielőtt munkajegyet hoz létre. Emellett hagyja, hogy az igazolt javítási előzmények idővel finomítsák a kiváltó feltételeket. A CMMS azonban soha ne írjon a vezérlési logikába, és ne hagyja ki a módosításkezelést. Ezért építsen szinkronizált idővel rendelkező, csak olvasási jogosultságú útvonalat a historizálón és az OPC UA-n keresztül. Végül magát a vezérlési infrastruktúrát is kezelje karbantartható berendezésként. Kezdje ezen a héten egy kritikus EtherNet/IP-kapcsolattal. Bizonyítsa a folyamat működését elejétől a végéig, mielőtt az egész üzemre kiterjesztené.
Szerző: Sun Yifei ipari automatizálási mérnök, több mint 10 éves PLC-, DCS- és vezérlőrendszer-tapasztalattal.
