Kako pretvoriti PLC i SCADA dijagnostiku u pouzdano održavanje bez narušavanja upravljanja.
Signal već postoji unutar upravljačkog sloja
PLC često nastavlja raditi dok mu se stanje pogoršava. Najprije pregledajte povijest dijagnostike, a ne mimiku. Prekidi komunikacije polako se povećavaju. Modul udaljenog I/O-a prijavljuje povremene kvarove. Na razini SCADA-e ispadi se ponavljaju prije bilo kakvog zaustavljanja proizvodnje. To su rana upozorenja, a ne šum. Suvremeni upravljači već izlažu te podatke. Ne treba vam uvijek nova senzorska mreža. Teži je dio svakom signalu dodijeliti korisno odredište. To je odredište zapis o održavanju povezan sa stvarnom imovinom.
1. korak — Prikupite stvarna stanja ispravnosti upravljača
Prediktivna logika mora koristiti signale koje uređaj doista podržava. Nemojte pretpostaviti da svaki PLC izlaže iste podatke o stanju. Na sustavu Allen-Bradley ControlLogix (kao što je procesor Allen-Bradley ControlLogix) ili CompactLogix pratite brojače pogrešaka priključaka EtherNet/IP na komunikacijskim karticama kao što je komunikacijski modul 1756 ControlLogix. Pratite broj popravljivih kvarova po udaljenoj stanici. Na upravljaču Woodward dostupnom putem Modbusa TCP-a (u sustavima za nadzor s Woodward I/O modulima) očitavajte registre za potrebno održavanje i ograničenje vijeka trajanja. Neki uređaji izravno prijavljuju unutarnje kvarove ili abnormalno napajanje.
-
1. korak — Navedite svaku dijagnostičku informaciju koju ciljni uređaj doista pruža.
-
2. korak — Pratite brojače tjedno jer učestalost bolje otkriva propadanje nego jedan događaj.
-
3. korak — Alarmirajte samo na rastući trend ili trajanje, a ne na jedan kratkotrajni skok.
-
4. korak — Povežite svaki brojač s jednom označenom imovinom, nikad s općim postoljem.
2. korak — Prestanite svaki alarm pretvarati u radni nalog
SCADA privlači pozornost operatera. Održavanje odlučuje tko će zasukati rukave. Miješanje tih dviju uloga zatrpava stvarno propadanje nepotrebnim radnim nalozima. Alarm visoke temperature možda je samo uobičajeno ponašanje tijekom proizvodnje. Kratkotrajni ispad može se sam oporaviti. Stoga procijenite stanje prije nego što izradite radni nalog. Ponavljanje je važnije od jednog događaja. Trajanje je često važnije od najveće ozbiljnosti. Sporo odstupanje ispod granice alarma i dalje može zahtijevati pregled. Osim toga, odvojite potvrdu od završetka. Operater potvrđuje da je kvar uočen. To ne dokazuje da je oprema popravljena.
-
1. korak — Dodajte pravilo prema kojem su potrebna tri ponavljanja u sedam dana za pokretanje rada.
-
2. korak — Dodajte kontekst: imovinu, trend i prethodne popravke.
-
3. korak — Zatvorite radni nalog tek nakon što je rad obavljen i evidentiran.
Povijest popravaka izoštrava model
Podaci iz historičara pokazuju što se dogodilo prije kvara. Povijest održavanja pokazuje što se dogodilo nakon pregleda. Pretpostavimo da komunikacijska pogreška stalno generira radne naloge. Tehničari svaki put ne pronađu kvar hardvera. Okidač je vjerojatno preosjetljiv. Međutim, ako isti događaj uvijek završi zamjenom jednog konektora, vjerujte tom obrascu. Zaslužuje raniju pozornost. Evidentirani obavljeni rad razdvaja simptom od uzroka. Naizgled lažni I/O kvar može se pokazati posljedicom gubitka napajanja terenskog uređaja. Zamjenom modula popravila bi se pogrešna imovina. Bilješka o zatvaranju čuva stvarni uzrok za sljedeću smjenu.
Integrirajte bez uvođenja rizika
CMMS ne smije postati privilegirani klijent upravljačkog sustava. Usmjerite dijagnostiku prema van kroz podatkovni sloj. Trend preuzmite iz SCADA-e ili historičara. Koristite OPC UA samo za čitanje za standardizirane informacije o stanju i dijagnostici. Integracijska usluga zatim prosljeđuje kvalificirane događaje platformi za održavanje putem API-ja. Time se promet održavanja drži podalje od vremenski kritične logike. Prediktivni izračuni ne moraju se izvršavati unutar upravljača. Osim toga, zaštitite mrežu. Aplikaciji za održavanje rijetko je potrebno upisivati u memoriju PLC-a. Ograničite joj pristup na čitanje. Slijedite postupak upravljanja promjenama u postrojenju prije nego što bilo koja automatizirana poveznica dosegne proizvodnju. Na kraju uskladite satove. SCADA događaj označen vremenom koje se od zapisa u CMMS-u razlikuje nekoliko minuta onemogućuje rekonstrukciju kvara.
Zaključak i savjeti za djelovanje
Prediktivno održavanje nagrađuje strpljenje i čist protok podataka, a ne domišljate nadzorne ploče. Najprije prikupljajte samo stanja ispravnosti koja vaši uređaji doista pružaju. Zatim procijenite stanje ponavljanjem i trajanjem prije nego što otvorite radni nalog. Osim toga, dopustite da provjerena povijest popravaka s vremenom usavršava vaše okidače. Međutim, nikad nemojte dopustiti CMMS-u upisivanje u upravljačku logiku niti zaobići upravljanje promjenama. Stoga izgradite put samo za čitanje kroz historičar i OPC UA, uz usklađeno vrijeme. Na kraju tretirajte samu upravljačku infrastrukturu kao opremu koju treba održavati. Ovog tjedna počnite s jednom kritičnom vezom EtherNet/IP. Dokažite ispravnost cijelog lanca prije proširenja na cijelo postrojenje.
Autor: Sun Yifei industrijski je inženjer automatizacije s više od 10 godina iskustva u PLC, DCS i upravljačkim sustavima.
