Rūpniecisko datu vēsturnieka arhitektūra: lokāla vai servera datu apkopošana

Kāpēc vēstures datu servera arhitektūra ir svarīga?

Rūpnieciskās automatizācijas sistēmas nepārtraukti ģenerē mērījumu, darbības stāvokļu, trauksmju un ražošanas notikumu plūsmas. Šie ieraksti palīdz inženieriem izmeklēt kļūmes, pārbaudīt procesa apstākļus un izprast iekārtu veiktspēju.

Tomēr datu apkopošana pati par sevi negarantē pilnīgu vai noderīgu vēsturisko ierakstu. Tīkla pārtraukumi, servera apkope, ierobežota krātuve un nepiemēroti datu apkopošanas iestatījumi var radīt iztrūkumus.

Izvēloties starp iekārtas līmeņa un serverī balstītu vēstures datu serveri, vispirms jāizvērtē paredzētais lietojums. Katra arhitektūra atbilst atšķirīgām datu apkopošanas, saglabāšanas un analīzes prasībām.

Iekārtas līmeņa vēstures datu serveris apkopo detalizētu informāciju iekārtu tuvumā. Serverī balstīts vēstures datu serveris apkopo ierakstus no vairākiem avotiem un nodrošina plašākas analīzes iespējas.

Kas ir iekārtas līmeņa vēstures datu serveris?

Iekārtas līmeņa vēstures datu serveris vāc un glabā laikrindu datus pie atsevišķas iekārtas, ražošanas šūnas vai vadības sistēmas. Atkarībā no risinājuma tas var iegūt datus no PLC un atbalstītiem rūpnieciskajiem tīkliem. Biežākie datu avoti ir tādi kontrolieri kā Allen-Bradley 1756-L1 ControlLogix PLC kontrolieris un Siemens 6ES7214 PLC kontroliera modulis.

Šāds risinājums ir noderīgs, ja inženieriem nepieciešami detalizēti ieraksti par apstākļiem pirms un pēc apturēšanas, iekārtas kļūmes vai negaidītas notikumu secības.

• Iekārtu diagnostika: Saglabā atlasītas kontroliera vērtības saistībā ar kļūmēm un ražošanas pārtraukumiem.
• Izsekojamība: Saista procesa mērījumus ar ražošanas cikliem, partijām vai atsevišķiem izstrādājumiem.
• Procesa verifikācija: Saglabā ierakstus, ko izmanto, lai pārbaudītu, vai darbības apstākļi atbilda noteiktajām prasībām.
• Lokāla datu apkopošana: Samazina atkarību no nepārtrauktas saziņas ar attālinātu vēstures datu serveri.

Lokāla datu apkopošana var uzlabot noturību, ja augšupējais serveris vai tīkla savienojums kļūst nepieejams. Tomēr šis ieguvums ir atkarīgs no vēstures datu servera faktiskās arhitektūras un pieejamās krātuves.

Inženieriem jāpārbauda datu glabāšanas ietilpība, datu eksportēšanas metodes, apkopošanas veiktspēja un darbības atjaunošana. Lokālā krātuve nenovērš visus iespējamos kļūmju veidus.

Kas ir servera vēsturisko datu sistēma?

Servera vēsturisko datu sistēma apkopo vēsturisko informāciju no vairākām ražošanas iekārtām un citiem atbalstītiem datu avotiem. Tā parasti piedāvā plašākas pārskatu veidošanas, tendenču analīzes, glabāšanas un analīzes iespējas.

Rūpnīcu inženieri var salīdzināt iekārtu veiktspēju, izpētīt atkārtotus ražošanas zudumus un salīdzināt procesu mērījumus dažādās iekārtās.

Centralizētas vēsturisko datu sistēmas atbalsta arī lietotnes, kas apvieno operatīvos datus ar ražošanas vai uzņēmējdarbības informāciju. Tas var palīdzēt sasaistīt procesa norisi ar ražošanas grafikiem, partijām un kvalitātes rezultātiem.

Tomēr datu apkopošanas ceļš rada papildu atkarības. Tīkla kļūmes, servera apkope, saskarņu problēmas un krātuves ierobežojumi var pārtraukt datu apkopošanu. Savienojamībai ar lauka iekārtām bieži izmanto Ethernet sakaru moduļus, piemēram, Yokogawa ALE111-S51, Schneider 140NOE21100 vai Foxboro FBM232, tāpēc to konfigurācija un darbspēja ir svarīga datu ierakstīšanai.

Nedomājiet, ka ikviena vēsturisko datu sistēma automātiski buferē datus darbības pārtraukuma laikā. Pārbaudiet, vai konkrētais datu savācējs atbalsta buferēšanu, cik ilgi tas glabā neapstrādātos ierakstus un kā tas rīkojas pēc savienojuma atjaunošanas.

Kā salīdzināmas abas arhitektūras?

Tās ir arhitektūras iezīmes, nevis universālas produkta garantijas. Pirms projekta galīgās izstrādes pārbaudiet izvēlētās platformas darbību.

Kā izvēlēties piemērotu vēstures datu sistēmu?

Uz kādu inženiertehnisku jautājumu jāatbild ar datiem?

Vispirms nosakiet, kādi lēmumi jāpieņem, balstoties uz vēsturiskajiem datiem. Kļūmju izmeklēšanai var būt nepieciešami augstas izšķirtspējas ieraksti par īsu notikumu. Ražošanas analīzei var būt vajadzīgs ilgāks glabāšanas periods un konsekventi dati no vairākiem aktīviem.

Dokumentējiet nepieciešamos tagus, vākšanas intervālus, notikumu aktivizētājus, laikspiedolu precizitāti, glabāšanas periodu un atskaišu prasības.

Kur datu vākšanas ceļā dati var pazust?

Izsekojiet datu vākšanas ceļu no katra kontrollera līdz datu glabāšanas vietai. Nosakiet tīkla komutatorus, vārtejas, datu vākšanas pakalpojumus, serverus un citus komponentus, kas var pārtraukt ierakstīšanu.

Noskaidrojiet, kas notiek tīkla darbības pārtraukuma, servera pārstartēšanas vai plānotas apkopes laikā. Pārliecinieties, vai dati tiek īslaicīgi uzkrāti lokāli un vai pēc darbības atjaunošanas sistēma var apvienot datus par iztrūkstošajiem intervāliem.

Cik daudz krātuves vietas nepieciešams?

Aprēķiniet nepieciešamo krātuves apjomu, ņemot vērā punktu skaitu, vākšanas biežumu, ieraksta lielumu, saspiešanas īpatnības un nepieciešamo glabāšanas periodu. Paredziet arī darbības pieskaitāmās izmaksas un atbilstošu ietilpības rezervi.

Nenovērtējiet nepieciešamo krātuves apjomu, balstoties tikai uz tagu skaitu. Divas sistēmas ar vienādu tagu skaitu var ģenerēt atšķirīgu datu apjomu atšķirīgu vākšanas iestatījumu un procesu norises dēļ.

Vai laikspiedoli ir konsekventi un labi izprasti?

Vēsturiskā analīze kļūst mazāk uzticama, ja saistītajos ierakstos izmantoti nesinhronizēti pulksteņi vai slikti izprasti laikspiedolu avoti. Pārbaudiet laika sinhronizāciju starp kontrolleriem, datu savācējiem un serveriem.

Noskaidrojiet, vai laikspiedoli norāda uz datu iegūšanu avotā, vākšanu vai saņemšanu serverī. Šī atšķirība ir svarīga, rekonstruējot notikumu secību, ja tie notikuši ar nelielu laika atstarpi.

Vai kiberdrošība un atjaunošana ir nodrošināta?

Pārskatiet autentifikāciju, piekļuves kontroli, tīkla segmentēšanu, ielāpu pārvaldību, dublēšanas procedūras un atjaunošanas testēšanu. Vēstures datu sistēmā var būt vērtīga operatīvā informācija, tāpēc tā pienācīgi jāaizsargā.

Pārbaudiet faktisko atjaunošanas procesu. Dublējumkopija ir noderīga tikai tad, ja nepieciešamos datus un konfigurāciju var atjaunot pieņemamās darbības robežās.

Kad apvienot lokālu un centralizētu datu vākšanu?

Dažām lietojumprogrammām ir noderīgas abas arhitektūras. Iekārtas līmeņa datu vēsturnieks var saglabāt detalizētus ierakstus iekārtu tuvumā, savukārt uz servera balstīts datu vēsturnieks apkopo atlasīto informāciju rūpnīcas mēroga analīzei.

Piemēram, ražošanas līnijai, kuras pamatā ir tādi kontrolleri kā GE Mark VIe IS400AEBMH3A PLC kontrollera modulis, var būt vajadzīgi detalizēti notikumu ieraksti kļūmju diagnostikai un centralizēti partiju vēstures dati kvalitātes pārskatīšanai. Vietējā glabāšana un centralizēta apkopošana var kopīgi nodrošināt šīs vajadzības.

Rūpīgi izstrādājiet datu pārsūtīšanas mehānismu. Nosakiet, kuri ieraksti tiek pārsūtīti uz augstāka līmeņa sistēmu, kā tiek saglabāti laika zīmogi, kā tiek apstrādāti dublēti ieraksti un kas notiek, ja sakari tiek pārtraukti.

Apsveriet arī, vai lokālās un centrālās sistēmas saglabā vienāda līmeņa detalizāciju. Apkopošana vai saspiešana var mainīt vēlākām izmeklēšanām pieejamo informāciju.

Kas jāiekļauj nodošanas ekspluatācijā un apkopes kontrolsarakstā?

• Pārbaudiet, vai tiek vākti vajadzīgie kontrollera tagi.
• Salīdziniet datu vēsturnieka vērtības ar uzticamu avotu vērtībām.
• Pārbaudiet datu vākšanas intervālus un notikumu aktivizēšanas darbību.
• Pārbaudiet laika sinhronizāciju attiecīgajās ierīcēs.
• Pārbaudiet darbību tīkla pārtraukumu laikā un atkopšanas procesu.
• Pārskatiet atmiņas ietilpību, glabāšanas politikas un arhīvu rotāciju.
• Pārbaudiet piekļuves vadīklas, dublējumus un atjaunošanas procedūras.
• Dokumentējiet datu vākšanas ceļus un katra komponenta atbildīgo.

Dokumentējiet testa rezultātus un pieņemšanas kritērijus. Atkārtojiet būtiskākās pārbaudes pēc nozīmīgām tīkla, kontrollera vai datu vēsturnieka konfigurācijas izmaiņām.

Secinājums: vēsturisko datu pārvēršana par uzticamu inženiertehnisko resursu

Izvēlieties rūpniecisko datu vēsturnieku atbilstoši pierādījumiem, kas jāsaglabā jūsu uzņēmumam, un lēmumiem, kas jāpieņem, pamatojoties uz šiem pierādījumiem. Vietējā datu vākšana ir noderīga detalizētai iekārtu diagnostikai, savukārt uz servera balstīta datu vākšana nodrošina plašākas atskaites un dažādu aktīvu analīzi. Apvienojot abus risinājumus, var iegūt savstarpēji papildinošas priekšrocības, ja datu pārsūtīšana, glabāšana un atkopšana ir rūpīgi izplānota. Pirms ieviešanas dokumentējiet datu prasības, pārbaudiet darbību pārtraukumu laikā, pārliecinieties par laika zīmogu kvalitāti un pārbaudiet, vai dublējumus iespējams atjaunot. Šīs darbības palīdz pārvērst vēsturiskos datus par uzticamu inženiertehnisko resursu.