Aktuální vydání

celé číslo

11

2020

Systémy řízení výroby a výrobních podniků

Elektrické, pneumatické a hydraulické pohony

celé číslo

Vplyv komunikačného rozhrania na kvalitu internetového monitorovania činnosti agregátov

číslo 4/2003

Vplyv komunikačného rozhrania na kvalitu internetového monitorovania činnosti agregátov

Pavel Horovčák

Príspevok sa zaoberá hodnotením vplyvov získavania a prenosu meraných hodnôt cez internet na kvalitu procesu monitorovania činnosti agregátov pri rôznych spôsoboch implementácie komunikačného rozhrania. V príspevku je porovnaná implementácia komunikačného rozhrania vo forme súborovej štruktúry a vo forme komunikácie TCP/IP. Je porovnaný vplyv dôb oneskorení pri rôznych podmienkach monitorovania na strane zberu, ako aj na strane klientského počítača. Sú diskutované možnosti monitorovania technologických údajov vzhľadom na ich meranie. Z experimentov vyplýva, že spotreba času na prenos meranej hodnoty v režime TCP je takmer vždy vyššia ako v režime súborovej štruktúry typu INI. V prípade moderných počítačov a rýchlej siete (100 Mb/s) sa pomer týchto dôb mení od 1 : 1 až po 14 : 1 (komunikácia typu INI je štrnásťkrát rýchlejšia ako komunikácia TCP).

1. Úvod

Pri hodnotení kvality procesu monitorovania činnosti agregátov s využitím internetu (teda vlastne rýchlosti a presnosti – v zmysle periódy vzorkovania – procesu komunikácie medzi aplikáciou zberu monitorovaných údajov, dátovým serverom a internetovým klientom) je potrebné uvažovať niekoľko faktorov kvality [6]. Tieto faktory možno podľa miesta ich vzniku rozdeliť na tri skupiny.

Do prvej skupiny možno zaradiť zaťaženie počítača vykonávajúceho zber monitorovaných údajov (počet bežiacich úloh, čerpanie zdrojov systému) a rýchlosť prenosu komunikačného rozhrania medzi počítačom zberu a počítačom dátového servera.

Obr. 1.

Do druhej skupiny patrí zaťaženie počítača dátového servera, ktoré ovplyvňuje časovú presnosť vysielania vzoriek signálu smerom na klienta. Na zaťaženie servera majú vplyv vnútorné a vonkajšie faktory. Vnútorné faktory reflektujú aktuálnu situáciu na serverovom počítači, ako je počet bežiacich úloh a čerpanie jednotlivých zdrojov systému. Vplyv vonkajších faktorov reprezentuje počet klientov súčasne pripojených k serveru a monitorujúcich daný technologický proces. Ďalej sa tu uplatňuje vplyv pripojenia viacerých zdrojov zberu monitorovaných údajov, teda v tomto zmysle tiež klientov dátového servera v smere k zberu dát.

Do tretej skupiny faktorov patrí rýchlosť prenosu v sieti medzi dátovým serverom a klientom plus analogicky okamžitá situácia (počet bežiacich úloh, čerpanie zdrojov) na lokálnom počítači, kde beží klient [5]. Distribúcia zložiek www monitorovania je znázornená na obr. 1.

Obr. 2.

2. Hodnotenie kvality monitorovania

Pre účely hodnotenia kvality monitorovania prostredníctvom internetu bola aplikácia zberu upravená tak, že do komunikačného rozhrania zapisuje iba čas zberu signálu (a z neho len sekundy a milisekundy – Delphi ukladá dátum a čas do typu TdateTime, ktorý je typu double, pričom jeho celá časť udáva počet dní od 30. 12. 1899, desatinná časť udáva čas dňa), ktorý sa mení v zmysle periódy vzorkovania aplikácie zberu (obr. 2)

hod:=frac(time*24*60)*60.0;
// na sekundy a milisekundy (1)

Aplikácia dátový server číta z komunikačného rozhrania nameranú hodnotu, zapisuje ju do soketu a pridáva k nej aktuálny čas jej vyslania z dátového servera. Tento čas je vysielaný na pomocnom kanáli číslo 9 a je generovaný analogickým spôsobom ako v aplikácii zberu (1).

Aplikácia klienta prijíma v rámci soketovej komunikácie tieto dve hodnoty a pre účely vyhodnotenia generuje aktuálny čas ich prijatia, tiež len sekundy a milisekundy:

cas:=System.currentTimeMillis();
// systemovy cas v ms
caspom:=(cas % (1000*60))/1000.0;
// iba s a ms, udaj v s (2)

Pre účely testovania kvality prenosu a vplyvu sieťových faktorov na priebeh monitorovania je prijímaný signál (hodnota času, t. j. sekundy a milisekundy) na strane klienta transformovaný z reťazca na číselný tvar

hodv[i]:=Double.valueOf(ret[i]).doubleValue();
// prijata hodnota zo servera [s]

kde ret je prijatá hodnota (reťazec) vyslaná z dátového servera a hodv je prevod na double. Priebeh monitorovaného signálu je zobrazovaný ako prvý graf (obr. 2) a označený textom monitorovany priebeh (hodv[0]).

Kvalitu monitorovania signálu je možné hodnotiť z hľadiska presnosti dodržania zadanej periódy vzorkovania a z hľadiska oneskorenia signálu na jednotlivých úsekoch jeho cesty na klientský počítač.

Dodržanie zadanej periódy vzorkovania je hodnotené na strane aplikácie zberu a na strane dátového servera, v oboch prípadoch vzhľadom na periódu vzorkovania dátového servera.

Dodržanie periódy vzorkovania na strane aplikácie zberu je dané porovnaním dvoch po sebe nasledujúcich hodnôt signálu vyslaného aplikáciou zberu a periódy vzorkovania podľa príkazu

hodv[1]:=hodv[0]–hodv[1]–dt;
// presnost zberu dat e_zb (3)

kde hodv[0] je aktuálny čas merania, hodv[1] predstavuje predchádzajúci čas merania a dt je perióda vzorkovania na strane dátového servera. Priebeh nepresnosti vysielania aplikácie zberu je zobrazovaný ako druhý graf označený presnost vzorkovania zberu dat e_zb.

Kvalitu dátového servera vyjadruje presnosť dodržania zadanej periódy vzorkovania na strane servera. Ide o jeho vysielanie v správnom čase a zohľadňuje sa tým okamžitá situácia na serverovom počítači ako aj vplyv počtu pripojených klientských počítačov (popr. počtu jednotlivých aplikácií zberu). Hodnotenie je založené na porovnaní dvoch po sebe nasledujúcich prijatých hodnôt signálu vyslaného dátovým serverom (t. j. hodv[9] a starej hodnoty hodv[2]) so zadanou periódou vzorkovania (dt) podľa príkazu

hodv[2]:=hodv[9]–hodv[2]–dt;
// presnost casoveho
vysielania servera (4)

Tab. 1. Zoznam použitých skratiek
dzb perióda vzorkovania na strane aplikácie zberu
dds perióda vzorkovania aplikácie dátového servera
e_dz oneskorenie medzi dátovým serverom a zberom
e_kd oneskorenie medzi klientom a dátovým serverom
e_kz oneskorenie medzi klientom a zberom
e_zb presnosť zberu
e_ds presnosť dátového servera
ini údaje získané pomocou komunikácie cez rozhranie INI
tcp údaje získané pomocou komunikácie cez rozhranie TCP/IP

Priebeh nepresnosti vysielania servera je zobrazovaný ako tretí graf a označený presnost vzorkovania datoveho servera e_ds.

Presnosť prijímania vzoriek vzhľadom na zadanú periódu vzorkovania na strane klienta je možné vyjadriť analogickým spôsobom. Nakoľko jej vplyv je zanedbateľný [3], upustili sme od jej grafickej prezentácie v podobe grafu.

Určenie trvania prenosu medzi serverom a klientom je podmienené synchronizáciou systémového času servera a klienta. Túto synchronizáciu možno zabezpečiť napr. pomocou aplikácie AboutTime [4], ktorá získava aktuálnu hodnotu času z internetu a nastavuje počítačový čas s presnosťou do 50 ms, v prípade iného protokolu ako SNTP (Simple Network Time Protocol) s presnosťou 1 s. Môže slúžiť ako server aj ako klient a pracovať so štyrmi protokolmi: Daytime/TCP – port 13, Time/TCP – port 37, Time/UDP – port 37 a SNTP – port 123.

Oneskorenie signálu je hodnotené na úseku zber – dátový server, na úseku dátový server – klient a nakoniec celkové ako súčet oboch.

Oneskorenie na prvom úseku je definované ako rozdiel času merania a času vysielania signálu z dátového servera podľa príkazu

hodv[3]:=hodv[9]-hodv[0];
// oneskorenie
dat.server – zber e_dz (5)

Priebeh oneskorenia na prvom úseku medzi dátovým serverom a zberom je zobrazovaný ako štvrtý graf a označený textom oneskorenie datovy server – zber e_dz.

Oneskorenie na druhom úseku je definované ako rozdiel systémového času klienta a času vysielania signálu z dátového servera a počíta sa podľa príkazu

hodv[4]:=caspom-hodv[9];
// oneskorenie klient
dat.server e_kd (6)

kde caspom je systémový čas klienta, hodv[9] je čas vysielania signálu na dátovom serveri. Priebeh trvania prenosu paketov medzi serverom a klientom je zobrazovaný ako štvrtý graf a označený textom oneskorenie klient – datovy server e_kd.

Celkové oneskorenie monitorovaného signálu na klientovi vzhľadom na zber je dané rozdielom času vzniku a príchodu signálu na klienta

hodv[5]:=caspom-hodv[0];
// oneskorenie
klient zber e_kz (7)

Priebeh oneskorenia medzi aplikáciou zberu a serverom je zobrazovaný ako piaty graf a označený textom oneskorenie klient – zber e_kz.

Grafy druhý až piaty by teoreticky v ideálnom prípade boli tvorené nulovým priebehom, v skutočnosti sú tvorené viac alebo menej náhodnými priebehmi, ktoré sa v istých časových úsekoch môžu týmto ideálnym priebehom približovať, inokedy nastáva značný rozkmit priebehu, čo poukazuje na zníženie kvality prenosu signálu, a teda monitorovaného priebehu.

Tab. 2. Porovnanie priemerných oneskorení klient – zber pre podmienky monitorovania B (ms)

dds 2 000 1 000 500 200 100 10
  e_kz priemery podmienky A
dzb tcp ini tcp ini tcp ini tcp ini tcp ini tcp ini
1 130 95 133 420 140 22 137 340 219 153 240 180
5 138 47 148 52 140 8 144 52 237 180 242 163
10 139 59 133 67 130 41 138 50 227 153 244 152
20 136 73 134 88 143 75 131 68 251 155 255 171
50 133 70 137 80 131 92 130 78 251 191 254 161
100 180 70 170 98 191 110 151 100 280 195 268 201
200 95 161 83 160 55 149 117 150 165 280 194 237
500 240 340 258 305 176 120 236 310 380 385 363 420
1 000 482 572 774 150 988 550 493 540 594 680 611 672
2 000 1 650 1 915 1 016 1 180 1 001 1 050 970 2 010 820 1 120 1 200 1 040
5 000 2 640 2 197 2 674 2 450 2 420 480 3 600 2 530 3 030 2 823 2 550 1 180

3. Implementácia komunikačného rozhrania v tvare súborovej štruktúry

Komunikačné rozhranie v tvare súborovej štruktúry môže byť realizované dvoma spôsobmi. Prvý spôsob predstavuje využitie súborov typu .INI, druhý spôsob využitie štandardných súborov. Využitie súborovej štruktúry spočíva v zápise odpovedajúcich hodnôt aplikáciou zberu do súboru a v následnom čítaní nameraných hodnôt aplikáciou dátového servera. Súbory typu .INI sú obyčajné textové súbory. Ich hlavným využitím je uchovávanie konfiguračných informácií. Informácie sú v týchto súboroch uchovávané v logických skupinách, nazývaných sekcie. Názvy sekcií sú uvádzané v hranatých zátvorkách. V rámci sekcie sú aktuálne údaje ukladané v tvare pomenovaných kľúčov. Kľúč má tvar <meno kľúča> = <hodnota>. Delphi poskytuje celý rad vlastností a metód, ktoré podstatným spôsobom zjednodušujú zápis, čítanie a manipuláciu so súbormi .INI (8 + 15 metód). Stručne možno charakterizovať prednosti práce so súbormi .INI jednoduchosťou obsluhy, prehľadnosťou zápisu a možnosťou uchovávania viacerých meraných alebo monitorovaných veličín (dôsledok použitia pomenovaných kľúčov).

Štandardné súbory je možné využiť v každom programovacom či vývojovom prostredí. Ich rýchlosť je obyčajne vyššia ako v prípade využitia databázového systému, čo je ich podstatnou prednosťou. K istým nevýhodám ich použitia patrí zvýšená náročnosť pri programovaní, potreba synchronizácie v prípade viacerých procesov a využitie najvhodnejších štandardných funkcií pri práci so súborom, ktoré môže podstatne zrýchliť alebo spomaliť výmenu informácií medzi komunikujúcimi subjektami.

Obr. 3.

Pri práci so súborom je možné pre zápis meranej hodnoty využiť dva postupy. Prvý postup zapisuje jedinú (vždy poslednú) nameranú hodnotu, ktorá sa následne prečíta. Tento postup je plne vyhovujúci a dostatočne rýchly [2]. Druhý postup zapisuje do súboru postupne všetky merané hodnoty, pričom pre účely ďalšieho spracovania sa vyberá vždy posledná nameraná hodnota. Takto sa do súboru dostane vlastne celý monitorovaný priebeh, čo umožní prípadné neskoršie prezeranie off-line. To možno pokladať za výhodu takéhoto prístupu. Podstatnou nevýhodou tohto postupu je narastajúca pomalosť, ktorá sa s rastúcim počtom nameraných hodnôt zvyšuje exponenciálne, ako je to znázornené na obr. 3. Údaje boli získané v zostave Pentium MMX 166 MHz, 32 MB RAM, operačný systém Windows NT 4.0, pričom bol využitý mechanizmus súborov typu .INI. Na základe skúseností možno očakávať podobný priebeh nárastu doby čítania poslednej hodnoty aj v prípade štandardných súborov.

Vo všetkých uvedených prípadoch je možné monitorovať jeden alebo viacej sledovaných priebehov technologického procesu.

4. Implementácia komunikačného rozhrania vo forme aplikácie TCP/IP

Komunikačné rozhranie vo forme aplikácie TCP/IP prestavuje moderný spôsob komunikácie dvoch alebo viacerých aplikácií, ktorý môže prebiehať aj v prostredí rôznych operačných systémov. Implementácia TCP/IP je založená na vytvorení soketovej komunikácie medzi všetkými navzájom komunikujúcimi aplikáciami. Soketová komunikácia umožňuje komunikovať s iným systémom na báze protokolu TCP/IP a príbuzných protokolov. Pomocou soketov je možné čítať a zapisovať cez prepojenie do iného počítača bez ohľadu na detaily aktuálneho sieťového softvéru. Sokety poskytujú prepojenie na báze protokolu TCP/IP, ale sú dostatočne univerzálne aj pre prácu s inými príbuznými protokolmi.

Obr. 4.

Pre komunikáciu medzi aplikáciou zberu a aplikáciou dátového servera bolo zvolené vývojové prostredie Delphi. Serverová časť komunikácie je realizovaná v aplikácii dátového servera, klientská časť v aplikácii zberu. Tento prístup umožní pripojiť viacero aplikácií zberu, a teda monitorovať viacero technologických procesov alebo agregátov s využitím toho istého dátového servera. Soketová komunikácia je implementovaná s využitím štandardných komponentov knižnice VCL (Visual Component Library) TServerSocket a TClientSocket.IP je založená na vytvorení soketovej komunikácie medzi všetkými navzájom komunikujúcimi aplikáciami. Soketová komunikácia umožňuje komunikovať s iným systémom na báze protokolu TCP/IP a príbuzných protokolov. Pomocou soketov je možné čítať a zapisovať cez prepojenie do iného počítača bez ohľadu na detaily aktuálneho sieťového softvéru. Sokety poskytujú prepojenie na báze protokolu TCP/IP, ale sú dostatočne univerzálne aj pre prácu s inými príbuznými protokolmi. Obe aplikácie môžu navzájom komunikovať obojsmerne, pričom hlavný tok dát predstavuje prenos monitorovaných údajov z aplikácie zberu do aplikácie dátového servera. V opačnom smere sú prenášané iba riadiace informácie. Aplikácia zberu využíva komponent Obe aplikácie môžu navzájom komunikovať obojsmerne, pričom hlavný tok dát predstavuje prenos monitorovaných údajov z aplikácie zberu do aplikácie dátového servera. V opačnom smere sú prenášané iba riadiace informácie. Aplikácia zberu využíva komponent konkrétne jeho metódu Socket.SendText pre vysielanie monitorovaných hodnôt, a metódu Socket.ReceiveText pre príjem riadiacej informácie z dátového servera. Aplikácia dátového servera pracuje s komponentom TServerSocket v troch režimoch. V prvom číta monitorovanú hodnotu z aplikácie zberu pomocou metódy Socket.ReceiveText, v druhom nadväzuje spojenie s klientom zberu pomocou metódy Socket.SocketHandle a vysiela späť riadiacu informáciu pomocou metódy Socket.SendText. V treťom režime sa uskutočňuje „upratovanie“ pri odpojení klienta zberu tiež pomocou metódy Socket.SocketHandle. Okrem toho je v aplikácii dátového servera sledovaný celkový počet klientov zberu pomocou metódy Socket.ActiveConnections. Podobným spôsobom je v aplikácii dátového servera riešená aj komunikácia s internetovým klientom, takže táto aplikácia pracuje s dvoma komponentami TserverSocket. Jeden je určený na obsluhu klientov zberu a druhý na obsluhu klientov monitorovania. Ukážka „dispečerskej obrazovky“ aplikácie dátového servera pre dvoch klientov zberu a piatich klientov monitorovania je znázornená na obr. 4. Každá aplikácia zberu vysiela svoj vlastný monitorovaný priebeh, z ktorých si aplikácia klienta monitorovania môže vybrať požadovaný priebeh. V súčasnosti sú vysielané všetky monitorované priebehy na klientov, výber požadovaného priebehu na strane klienta je potrebné ešte dopracovať.

Tab. 3. Porovnanie priemerných oneskorení klient – zber pre podmienky monitorovania B (ms)

dds 2 000 1 000 500 200 100 10
  e_kz priemery podmienky B
dzb tcp ini tcp ini tcp ini tcp ini tcp ini tcp ini
1 133 12 76 10 95 34 2 000 54 800 12 158 26
5 143 32 83 10 105 10 150 47 167 12 158 26
10 143 21 82 10 105 10 176 18 167 12 158 26
20 143 12 82 10 113 10 227 10 176 11 158 26
50 152 17 123 20 114 40 257 11 177 20 152 420
100 152 102 92 20 165 81 257 25 247 30 212 63
200 253 105 102 50 146 55 317 170 207 80 203 113
500 173 230 33 480 75 280 297 260 268 256 301 280
1 000 904 417 22 200 706 350 500 570 541 280 561 507
2 000 233 1 439 1 154 950 1 066 1 001 1 020 1 017 7 000 955 1 031 1 037
5 000 2 380 2 012 2 250 3 238 1 923 2 767 2 800 3 250 2 500 2 530 2 937 3 228

5. Hodnotenie prenosových dôb

Hodnotenie prenosových dôb a tým kvality monitorovania [1] pri jednotlivých podmienkach bolo realizované voľbou kritéria maximálnych a priemerných hodnôt jednotlivých priebehov týchto dôb za dostatočne dlhú dobu. Za dostatočne dlhú dobu bola považovaná doba okolo 60 sekúnd. Rozsah časovej osi grafov je 60 sekúnd, hodnota času od začiatku monitorovania je uvedená pred začiatkom časovej osi. Pre vybrané podmienky monitorovania bolo vykonané porovnanie hodnotenia cez kritérium maximálnych a priemerných hodnôt. Podmienky monitorovania boli:

  • A – všetky tri aplikácie (aplikácia zberu, dátového servera a klienta) pracujú na rovnakom počítači (procesor Pentium MMX 166 MHz, 64 MB RAM, Microsoft Windows 98).

  • B – aplikácia zberu pracuje na jednom počítači (procesor Pentium 166 MHz, 64 MB RAM, Microsoft Windows 2000), aplikácia dátového servera a klienta na druhom počítači (procesor Celeron 850 MHz, 512 MB RAM, Microsoft Windows 2000). Synchronizácia systémových časov oboch počítačov je zabezpečená pomocou programu AboutTime.

Porovnávané sú hodnoty priemerných a maximálnych oneskorení získané pri realizácii komunikačného rozhrania vo forme TCP/IP a vo forme súborov .INI. Periódy vzorkovania na strane aplikácie zberu boli dzb = 1; 5; 10; 20; 50; 100; 200; 500; 1 000; 2 000 a 5 000 ms, periódy vzorkovania aplikácie dátového servera dds = 10; 100; 200; 500; 1 000; 2 000 a 5 000 ms. Hodnotenie prenosových dôb je vykonané pre podmienky monitorovania A, pretože tu sa neuplatňuje vplyv premenlivého zaťaženia siete. Možno však konštatovať, že priebehy jednotlivých sledovaných faktorov pre podmienky monitorovania A aj B majú takmer identický charakter.

5.1 Presnosť zberu
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 10 po 100 ms, kritérium maximálnych hodnôt – nepresnosti sú od 100 do 5 000 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 10 po 200 ms, kritérium maximálnych hodnôt – nepresnosti sú od 50 do 6 000 ms.

Celkové hodnotenie: súbory priemerných aj maximálnych hodnôt sú veľmi podobné, nepresnosti v prípade priemerných hodnôt sú takmer rovnaké, v prípade maximálnych hodnôt v niektorých prípadoch (dds = 1 000, 2 000 ms) boli hodnoty pre TCP približne dvakrát väčšie ako pre INI.

Tab. 4. Porovnanie maximálnych oneskorení klient – zber pre podmienky monitorovania A (ms)

dds 2 000 1 000 500 200 100 10
  e_kz maxima podmienky A
dzb tcp ini tcp ini tcp ini tcp ini tcp ini tcp ini
1 280 110 220 770 280 110 220 110 280 270 330 330
5 280 110 280 110 280 110 280 110 330 330 330 280
10 280 170 270 160 270 110 330 110 280 280 330 280
20 280 170 280 160 280 110 280 110 330 280 330 330
50 220 110 220 120 220 170 270 170 330 330 330 330
100 280 170 280 220 280 170 330 170 380 330 390 330
200 220 280 170 280 110 280 170 390 380 440 440 440
500 500 550 550 550 220 330 500 610 720 770 660 770
1 000 990 1 100 830 280 990 1 040 990 1 050 1 210 1 210 1 200 1 320
2 000 1 710 1 980 1 980 1 980 2 020 2 030 1 980 2 040 2 150 2 300 2 200 2 250
5 000 5 000 4 610 6 270 4 980 4 950 5 760 4 950 6 150 6 860 6 210 5 110 5 110

5.2 Presnosť dátového servera
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 9 po 110 ms, kritérium maximálnych hodnôt – nepresnosti sú od 50 do 210 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 10 po 60 ms, kritérium maximálnych hodnôt – nepresnosti sú od 40 do 590 ms.

Celkové hodnotenie: podobne ako v prípade presnosti zberu možno hodnotiť súbory priemerných aj maximálnych hodnôt ako veľmi podobné, nepresnosti v oboch prípadoch sú takmer rovnaké.

5.3 Doba prenosu zber – dátový server
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 80 po 3 600 ms, kritérium maximálnych hodnôt – nepresnosti sú od 110 do 6 860 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 45 po 2 750 ms, kritérium maximálnych hodnôt – nepresnosti sú od 60 do 6 150 ms.

Celkové hodnotenie: priemerné hodnoty pre TCP sú vo väčšine prípadov väčšie ako pre INI, a to približne dvojnásobne. Podobne to platí aj pre maximálne hodnoty – hodnoty pre TCP a INI sú niekde rovnaké, niekde sú pre TCP až dvojnásobne väčšie.

5.4 Doba prenosu dátový server – klient
TCP/IP: Kritérium priemerných hodnôt – pre dds = 200 až 2 000 ms sa nepresnosti pohybujú asi od 0 po 18 ms, pre dds = 10 až 100 ms je to 90 až 125 ms, kritérium maximálnych hodnôt – pre dds = 200 až 2 000 ms je to 0 až 60 ms, pre dds = 10 až 100 ms je to 220 ms.

INI: Kritérium priemerných hodnôt – pre dds = 200 až 2 000 ms sú nepresnosti od 0 do 22 ms, pre dds = 10 až 100 ms je to 100 až 124 ms, kritérium maximálnych hodnôt – pre dds = 200 až 2 000 ms je to 0 až 60 ms, pre dds = 10 až 100 ms je to 220 ms.

Celkové hodnotenie: priemerné aj maximálne hodnoty pre TCP sú vo väčšine prípadov rovnaké ako pre INI.

5.5 Doba prenosu zber – klient
TCP/IP: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 60 po 3 140 ms, kritérium maximálnych hodnôt – nepresnosti sú od 110 do 6 860 ms.

INI: Kritérium priemerných hodnôt – nepresnosti sa pohybujú asi od 0 po 2 750 ms, kritérium maximálnych hodnôt – nepresnosti sú od 60 do 6 150 ms.

Celkové hodnotenie: priemerné hodnoty pre TCP sú vo väčšine prípadov väčšie ako pre komunikáciu INI.

Tab. 5. Porovnanie priemerných oneskorení klient – dátový server pre podmienky monitorovania A (ms)

dds 2 000 1 000 500 200 100 10
  e_kd priemery
dzb tcp ini tcp ini tcp ini tcp ini tcp ini tcp ini
1 5 0 8 4 0 3 3 33 90 102 120 123
5 5 22 11 0 0 6 16 2 110 120 111 118
10 5 0 8 10 0 19 1 2 98 100 111 105
20 2 13 11 10 3 5 2 15 115 103 111 124
50 6 5 3 0 2 10 1 5 120 108 120 117
100 5 0 5 20 13 5 1 2 125 105 107 121
200 3 8 0 22 0 1 9 1 105 115 106 107
500 5 9 3 9 12 2 8 0 97 100 115 112
1 000 12 6 0 0 4 2 1 1 102 100 113 121
2 000 0 3 3 0 0 2 4 0 100 100 120 121
5 000 18 0 8 10 2 5 2 5 102 102 100 110

6. Hodnotenie vplyvu komunikačného rozhrania

Na základe vysokého počtu vykonaných experimentov a ich vyhodnotenia je možné konštatovať, že na celkové oneskorenie monitorovaného signálu má vo všetkých prípadoch podstatný vplyv doba prenosu signálu medzi aplikáciou zberu a aplikáciou dátového servera. Toto oneskorenie je rádovo päť až dvadsaťkrát väčšie ako oneskorenie medzi aplikáciou dátového servera a klienta. Preto je opodstatnené sústrediť pozornosť na skúmanie mechanizmov prenosu medzi aplikáciou zberu a aplikáciou dátového servera.

Porovnávané boli dva komunikačné mechanizmy – prenos formou TCP s využitím soketovej komunikácie a prenos s využitím komunikácie cez súbor typu .INI. Z experimentov vyplýva, že spotreba času na prenos meranej veličiny vo forme TCP je takmer vždy väčšia ako u súborov typu .INI. V prípade kvalitných počítačov a rýchlej siete (100 Mb/s) sa ich pomer pohybuje od 1 : 1 až po 14 : 1.

Výhodou použitia TCP je možnosť zadania IP adresy (na ktorej pracuje aplikácia dátového servera) do aplikácie zberu. Tým je aplikácia zberu v podstate nezávislá od jej umiestnenia na sieti. Nevýhodou je väčšie časové oneskorenie meranej hodnoty v klientskej aplikácii.

Výhodou použitia súboru typu INI je vo väčšine prípadov vyššia rýchlosť spracovania ako pri TCP. Nevýhodou je nutnosť „konštantnej“ konfigurácie siete, v ktorej chceme experimentovať. Táto konfigurácia sa priamo premieta do cesty, kde je umiestnený súbor použitia. Cesta je zadaná v tvare \CompNameDisk_NameFolderData.ini, kde CompName je meno počítača v sieti, Disk_Name označenie disku, Folder označenie zložky a Data.ini označenie súboru typu .INI. Je samozrejmé, že v prípade zmeny počítača je nutná opätovná kompilácia aplikácie, čo je ďalšou nevýhodou použitia súboru typu .INI.

Tab. 6. Porovnanie priemerných oneskorení dátový server – zber pre podmienky monitorovania A (ms)

dds 2 000 1 000 500 200 100 10
  e_kd priemery
dzb tcp ini tcp ini tcp ini tcp ini tcp ini tcp ini
1 125 69 125 423 140 18 134 380 121 50 120 50
5 133 45 137 50 140 0 135 50 130 60 130 45
10 135 56 128 60 130 22 136 50 127 50 130 47
20 142 60 126 72 139 66 126 56 135 50 130 48
50 140 60 131 80 128 85 130 75 135 83 130 48
100 150 71 165 80 170 100 150 100 160 90 150 80
200 93 152 82 140 155 150 109 135 60 160 85 129
500 230 320 241 275 164 120 230 305 277 280 245 310
1 000 350 572 770 150 480 589 470 520 480 600 492 552
2 000 1 650 1 920 1 016 1 180 990 1 050 950 1 050 1 070 1 080 980 1 030
5 000 3 140 2 013 2 664 2 450 2 314 460 3 600 2 520 3 010 2 750 2 350 700

V tab. 3 sú tieňovaním vyznačené hodnoty oneskorenia väčšie ako periódy vzorkovania aplikácie zberu a aplikácie dátového servera, ktoré zhoršujú kvalitu procesu monitorovania. Je zrejmé, že pracovný rozsah je podstatne väčší pre komunikáciu cez súbory typu .INI ako pre komunikáciu TCP/IP. Dostávame sa tak k typickému protirečeniu: rýchlosť kontra univerzálnosť.

7. Záver

Obidva sledované postupy riešenia komunikačného rozhrania potvrdili svoju funkčnosť. Výhodou komunikácie TCP je jej univerzálnosť, ktorá umožňuje umiestniť aplikáciu zberu na hociktorý sieťový počítač. Jej nevýhodou je vyššia hodnota oneskorenia monitorovaného signálu. Výhodou komunikácie cez súbory typu .INI je jej podstatne vyššia rýchlosť, nevýhodou viazanosť skompilovanej aplikácie na konkrétne podmienky siete LAN. Preto je nevyhnutné, aby súbor typu .INI bol umiestnený na počítači, kde pracuje aplikácia dátového servera.

Jednou z perspektívnych možností zrýchlenia komunikácie TCP je využitie vlákien (threads). Osobitné vlákna na čítanie a zápis do soketov v aplikácii dátového servera môžu prispieť ku skráteniu režijných dôb spracovania jednotlivých konekcií.

Literatúra:

[1] HOROVČÁK, P. – BALUCH, D.: Hodnotenie kvality vzdialeného monitorovania. Acta mechanica Slovaca, 3/2000, ISSN 1335-2393, RAVYP a SE-EPP, s. 531–536.

[2] HOROVČÁK, P.: Aplikácia web technológií na monitorovanie činnosti agregátov. Acta mechanica Slovaca, 3/2000, ISSN 1335-2393, RAVYP a SE-EPP, s. 537–540.

[3] HOROVČÁK, P.: The Influence of Network Factors on Process Monitoring. Acta Tehnica Napocensis, Electronics and Telecommunications, 2001, Vol. 41, N. 2, ISSN 1221–6542, s. 36–45.

[4] LUTUS, P.: AboutTime 1998. Rev. 19. 11. 1999 [cit. 27. 1. 2003]. Dostupné na http://www.arachnoid.com/abouttime

[5] HOROVČÁK, P. – BALUCH, D.: The analysis of acquisition and transfer time influence at various conditions of www monitoring. In: Proceedings of International Carpathian Control Conference 2001, Krynica, Poland, 2001, ISBN 89-91340-07-4, s. 273–278.

[6] TERPÁK, J. – DORČÁK, Ľ. – KOŠTIAL, I.: Modeling, Monitoring and Control of the Agglomeration Process. Transactions of the TU of Košice, 1997, No. 1, ISSN 0960 6076, s. 37–42.

Pozn.: Príspevok bol riešený v rámci grantu Sokrates Minerva 90511-CP-1-2001-UK-MINERVA-M.

Pavel Horovčák,
Technická univerzita v Košiciach,
Fakulta baníctva, ekológie, riadenia a geotechnológií,
katedra informatizácie a riadenia procesov
(Pavel.Horovcak@tuke.sk)

Lektoroval:
Ing. Zdeněk Bradáč, ÚAMT FEKT VUT

Inzerce zpět