Kā pārvērst PLC un SCADA diagnostiku uzticamā apkopē, neizjaucot vadības sistēmu.
Signāls jau pastāv vadības slānī
PLC bieži turpina darboties, kamēr tā stāvoklis pasliktinās. Vispirms aplūkojiet diagnostikas vēsturi, nevis mimikas ekrānu. Sakaru pārtraukumi pakāpeniski kļūst biežāki. Attālinātais I/O modulis ziņo par periodiskām kļūmēm. SCADA slānī savienojuma pārtraukumi atkārtojas, pirms tiek apturēta ražošana. Tie ir agrīni brīdinājumi, nevis troksnis. Mūsdienu kontrolleri šos datus jau nodrošina. Jauns sensoru tīkls ne vienmēr ir nepieciešams. Sarežģītākais ir piešķirt katram signālam lietderīgu galamērķi. Šis galamērķis ir apkopes ieraksts, kas piesaistīts reālam aktīvam.
1. darbība — Iegūstiet reālus kontrollera stāvokļa signālus
Prognozēšanas loģikā jāizmanto signāli, kurus ierīce patiešām atbalsta. Neuzskatiet, ka katrs PLC nodrošina vienādus stāvokļa datus. Allen-Bradley ControlLogix (piemēram, Allen-Bradley ControlLogix procesorā) vai CompactLogix sistēmā uzraugiet EtherNet/IP porta kļūdu skaitītājus sakaru kartēs, piemēram, 1756 ControlLogix sakaru modulī. Izsekojiet novēršamo kļūmju skaitu katrai attālajai stacijai. Woodward kontrollerī, kas pieejams, izmantojot Modbus TCP (uzraugot sistēmas ar Woodward I/O moduļiem), nolasiet apkopes nepieciešamības un kalpošanas ilguma ierobežojuma reģistrus. Dažas ierīces tieši ziņo par iekšējām kļūmēm vai nestandarta barošanu.
-
1. darbība — Uzskaitiet katru diagnostikas rādītāju, ko mērķa ierīce patiešām nodrošina.
-
2. darbība — Katru nedēļu analizējiet skaitītāju tendences, jo biežums labāk atklāj pasliktināšanos nekā viens notikums.
-
3. darbība — Aktivizējiet trauksmi tikai pieaugošas tendences vai noteikta ilguma gadījumā, nevis pēc viena īslaicīga traucējuma.
-
4. darbība — Piesaistiet katru skaitītāju vienam marķētam aktīvam, nevis vispārīgam statīvam.
2. darbība — Nepārvērtiet katru trauksmi darba uzdevumā
SCADA piesaista operatora uzmanību. Apkopes darbinieki izlemj, kurš dosies novērst problēmu. Sajaucot šīs lomas, būtiska pasliktināšanās tiek aprakta nevajadzīgu darba uzdevumu kaudzē. Augstas temperatūras trauksme var būt tikai normāla ražošanas procesa izpausme. Īss savienojuma pārtraukums var novērsties pats. Tāpēc pirms darba izveides izvērtējiet stāvokli. Atkārtošanās ir nozīmīgāka par vienu notikumu. Ilgums bieži ir svarīgāks par maksimālo intensitāti. Lēna novirze zem trauksmes sliekšņa joprojām var būt iemesls pārbaudei. Turklāt nošķiriet apstiprināšanu no izpildes. Operators apstiprina, ka kļūme ir pamanīta. Tas nepierāda, ka iekārta ir salabota.
-
1. darbība — Pievienojiet noteikumu, kas darba uzdevuma izveidei pieprasa trīs atkārtojumus septiņu dienu laikā.
-
2. darbība — Pievienojiet kontekstu: aktīvu, tendenci un iepriekšējos remontdarbus.
-
3. darbība — Aizveriet darba uzdevumu tikai pēc darba izpildes un reģistrēšanas.
Remontdarbu vēsture uzlabo modeli
Vēsturisko datu sistēmas dati parāda, kas notika pirms kļūmes. Apkopes vēsture parāda, kas notika pēc tam, kad kāds veica pārbaudi. Pieņemsim, ka sakaru kļūda atkārtoti ģenerē darba uzdevumus. Tehniķi katru reizi neatrod aparatūras defektu. Iespējams, aktivizēšanas nosacījums ir pārāk jutīgs. Tomēr, ja viens un tas pats notikums vienmēr beidzas ar viena savienotāja nomaiņu, uzticieties šai sakarībai. Tam jāpievērš uzmanība agrāk. Pabeigtie darbi nošķir simptomu no cēloņa. Šķietama I/O kļūme var būt saistīta ar lauka ierīci, kurai pārtrūkusi barošana. Moduļa nomaiņa novērstu problēmu nepareizajam aktīvam. Noslēguma piezīme saglabā patieso cēloni nākamajai maiņai.
Integrējiet, neradot risku
CMMS nedrīkst kļūt par privileģētu vadības sistēmas klientu. Novirziet diagnostikas datus ārpus vadības sistēmas, izmantojot datu slāni. Iegūstiet tendences datus no SCADA vai vēsturisko datu sistēmas. Izmantojiet tikai lasāmu OPC UA savienojumu standartizētai stāvokļa un diagnostikas informācijai. Pēc tam integrācijas pakalpojums, izmantojot API, nodod kvalificētus notikumus apkopes platformai. Tas novērš apkopes datu plūsmu no laika ziņā kritiskās loģikas. Prognozējošiem aprēķiniem nav jādarbojas kontrollerī. Turklāt aizsargājiet tīklu. Apkopes lietotnei reti ir nepieciešama iespēja rakstīt PLC atmiņā. Ierobežojiet tai piekļuvi tikai lasīšanai. Pirms jebkādas automatizētas saites savienošanas ar ražošanu ievērojiet rūpnīcas izmaiņu vadības procesu. Visbeidzot, sinhronizējiet pulksteņus. SCADA notikums, kas no CMMS ieraksta atšķiras par vairākām minūtēm, izjauc kļūmes rekonstrukciju.
Secinājumi un ieteikumi rīcībai
Prognozējošā apkope balstās uz pacietību un tīru datu plūsmu, nevis izsmalcinātiem informācijas paneļiem. Vispirms iegūstiet tikai tos stāvokļa signālus, ko jūsu ierīces patiešām nodrošina. Otrkārt, pirms darba uzdevuma izveides izvērtējiet stāvokli, ņemot vērā atkārtošanos un ilgumu. Turklāt ļaujiet pārbaudītajai remontdarbu vēsturei laika gaitā uzlabot aktivizēšanas nosacījumus. Tomēr nekad neļaujiet CMMS rakstīt vadības loģikā vai apiet izmaiņu vadības procesu. Tāpēc izveidojiet tikai lasāmu ceļu caur vēsturisko datu sistēmu un OPC UA, izmantojot sinhronizētu laiku. Visbeidzot, uzskatiet pašu vadības infrastruktūru par apkopjamu aprīkojumu. Šonedēļ sāciet ar vienu kritisku EtherNet/IP savienojumu. Pārbaudiet visu procesu no sākuma līdz beigām, pirms to paplašināt visā rūpnīcā.
Autors: Sun Yifei ir industriālās automatizācijas inženieris ar vairāk nekā 10 gadu pieredzi PLC, DCS un vadības sistēmu jomā.
