OPC serveris ir savienots, bet tagi netiek atjaunināti: praksē pārbaudīti risinājumi Yokogawa un ABB sistēmām

Kāpēc iezīmes sastingst, lai gan savienojums joprojām ir zaļš

Ikviens vadības inženieris ir saskāries ar šādu simptomu. OPC serveris ziņo par veselīgu savienojumu. Tomēr SCADA ekrānā redzamas nemainīgas vērtības. Vairākas iezīmes vienkārši pārstāj atjaunināties. Vispirms jāsaprot, ka zaļš statuss pierāda tikai transporta slāņa darbību. Tas neko nepasaka par datu kvalitāti. Tāpēc “savienots, bet novecojis” jāuzskata par konfigurācijas vai slodzes problēmu, nevis tīkla kļūmi. Šī atšķirība ļauj ietaupīt stundas, kas citādi tiktu pavadītas nepareizai problēmu novēršanai. Esmu meklējis šo kļūmi Yokogawa CENTUM VP un ABB System 800xA iekārtās. Pamatcēloņi gandrīz vienmēr ir šie astoņi vaininieki.

Astoņi pamatcēloņi, kas jāizslēdz

Otrkārt, pirms pieskaršanās jebkuram rīkam iegaumējiet kļūmju režīmus. Adrešu kartējuma neatbilstība ir galvenais cēlonis. PLC programmas modernizācijas laikā mainās, bet OPC konfigurācijas — ne. Nākamā ir nepareizi konfigurēta skenēšanas frekvence. Agresīva 100 ms aptauja tūkstošiem iezīmju gadījumā pārslogo draiveri. Turklāt PLC sakaru slodzes piesātinājums aizkavē nolasīšanas pieprasījumus, kad SCADA, HMI, arhivētājs un apkopes klēpjdatori visi aptaujā vienu un to pašu kontrolleri. Nejutības joslas filtrēšana paslēpj nelielas analogās izmaiņas. Ierīču grupas nepareiza konfigurācija izolē tikai viena kanāla iezīmes. Sarakstu noslēdz kešatmiņas atsvaidzināšanas kļūmes, PLC loģika, kas atkarīga no skenēšanas, un tīkla pakešu fragmentācija. Tomēr katrs cēlonis atstāj atšķirīgu nospiedumu. Jūsu uzdevums ir šo nospiedumu ātri nolasīt.

• 1. darbība: Vispirms pārbaudiet iezīmju kvalitātes karodziņus. “Slikta” kvalitāte norāda uz adrešu kartējumu. “Laba, bet novecojusi” kvalitāte norāda uz skenēšanas nosacījumiem vai nejutības joslu.
• 2. darbība: Salīdziniet PLC eksporta failu ar OPC servera adrešu telpu. Meklējiet nobīdītus datu blokus un mainītus datu tipus.
• 3. darbība: OPC klientā pārskatiet skenēšanas frekvences. Nekritiskām analogajām vērtībām mainiet 250 ms uz 1000 ms vai 2000 ms.
• 4. darbība: Nolasiet draivera diagnostikas skaitītājus. Pieaugoši nolasīšanas taimauti norāda uz PLC sakaru slodzes piesātinājumu.
• 5. darbība: Uz laiku atspējojiet nejutības joslu (iestatiet to uz 0%) vienai iesaldētai analogajai iezīmei. Ja tā sāk atjaunināties, cēlonis ir atrasts.
• 6. darbība: Zemas slodzes periodā piespiedu kārtā restartējiet ierīču grupu. Lielākajā daļā serveru tas notīra novecojušos kešatmiņas ierakstus.

Gadījuma izpēte: Yokogawa CENTUM VP un EXAOPC siena

Nesenā naftas pārstrādes rūpnīcas projektā sistēma Yokogawa CENTUM VP caur EXAOPC padod datus trešās puses arhivētājam. Savienojums palika veselīgs. Tomēr katru pēcpusdienu iesaldējās 200 no 8 000 iezīmēm. Nospiedums bija saistīts ar laiku. Turklāt visas iesaldētās iezīmes piederēja vienai ierīču grupai. Noskaidrojām, ka grupas atjaunināšanas intervāls bija iestatīts uz 200 ms. Pēc pusdienlaika FCS sakaru kartes slodze sasniedza maksimumu. Tāpēc palielinājām grupas intervālu līdz 1000 ms un pārvietojām tendenču datus uz grupu, kas balstīta uz abonēšanu. Iesaldēšana pazuda vienas dienas laikā. Yokogawa vadlīnijas ierobežo iezīmju atjauninājumu skaitu vienai sakaru kartei. Ievērojiet šo ierobežojumu. Visbeidzot, lielu iezīmju skaitu vienmēr sadaliet vairākās ierīču grupās, nevis ievietojiet vienā pārmērīgi lielā grupā.

Gadījuma izpēte: ABB System 800xA un nemanāma aspekta maiņa

ABB 800xA vadības datus savienojamības serverī atklāj, izmantojot Aspect Objects. Elektrostacijas klients ziņoja par novecojušām motoru statusa iezīmēm pēc kontrollera programmaparatūras jaunināšanas. OPC saite palika zaļa. Vispirms pārbaudījām tīklu. Tas bija kārtībā. Otrkārt, salīdzinājām objektu adreses vadības struktūrā. Jaunināšana bija pārkārtojusi kontrollera datu izkārtojumu, ietekmējot tādus moduļus kā ABB DSQC I/O Module. Turklāt vairākas ABB Connection Units joprojām atsaucās uz vecajiem statnes un slota numuriem. Tāpēc no jauna ģenerējām aspektu adreses un veicām atkārtotu izvietošanu. Iezīmes atjaunojās nekavējoties. Mācība ir universāla. Pēc jebkuras kontrollera jaunināšanas vienmēr pārbaudiet OPC adrešu telpu. Nekad nepieņemiet, ka jaunināšana ir saglabājusi atmiņas izkārtojumu. Turklāt versiju kontrolējiet OPC konfigurācijas eksportus, lai izmaiņas varētu salīdzināt dažu minūšu laikā.

Protokola parametri, ko vērts iegaumēt

• Analogajām iezīmēm saglabājiet OPC DA atjaunināšanas frekvenci 500 ms vai lēnāku. 100–250 ms rezervējiet tikai kritiski svarīgam bloķējuma statusam.
• Iestatiet analogās nejutības joslu uz 0,2–0,5% no diapazona. Nulles nejutības josla pārpludina klientu ar trokšņa izraisītiem atjauninājumiem.
• Ja iespējams, klienta aptaujas vietā izmantojiet OPC UA abonementus ar servera puses publicēšanas intervālu. Tas ievērojami samazina datplūsmu.
• Ierobežojiet katru ierīču grupu līdz aptuveni 1 000–2 000 iezīmēm atkarībā no kontrollera sakaru jaudas.
• Arhivētājā iespējojiet kvalitātes laika zīmogus. Novecojušu vērtību noteikšana ir atkarīga no tiem.

Secinājumi un ieteikumi rīcībai

Zaļš OPC savienojums neko nepierāda par datu aktualitāti. Tāpēc izveidojiet pastāvīgu diagnostikas kārtību: vispirms kvalitātes karodziņi, otrkārt adrešu kartējums, treškārt skenēšanas frekvences. Turklāt dokumentējiet visas kontrollera izmaiņas, kas skar atmiņas izkārtojumu, jo adrešu neatbilstība ir galvenais iesaldētu iezīmju cēlonis. Visbeidzot, katru ceturksni paredziet laiku nejutības joslu iestatījumu un ierīču grupu slodzes pārbaudei. Iekārtās, kurās ievēro šo disciplīnu, novecojušas iezīmes tiek pamanītas dažu minūšu laikā.