České vysoké učení technické v Praze Fakulta elektrotechnická
ˇ VUT FEL katedra pocˇı´tacˇu˚ C
Diplomová práce
Klientské rozhraní aplikací SCADA Jaroslav Baláš
Vedoucí práce: Doc. Ing. Jan Janeček, CSc.
Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpočetní technika září 2006
II
Poděkování Doc. Ing. Janu Janečkovi, CSc., vedoucímu této diplomové práce, děkuji za jeho rady a čas, který mně věnoval. Rovněž děkuji pracovníkům firmy EGÚ ČB a. s., především panu řediteli Ing. Františku Mejtovi, za návrh zajímavého tématu. III
IV
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu § 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Horní Stropnici dne 12. ledna 2007
.............................................................
V
VI
Abstract The work contains a general description of SCADA systems and a short summary of their history. The requirements of these systems are analyzed in the scope of modern distributed applications. The possibility of using web browser as a runtime environment for client application and proper technologies are analyzed in detail. The already implemented systems are briefly described. The evaluation of their attributes is based on formulated general requirements. The rest of work deals with implementation of application, which consists of server and client part. The client part uses web browser for visualization of technology.
Abstrakt Práce obsahuje obecný popis SCADA systémů a stručný přehled jejich historie. Jsou rozebrány požadavky na ně kladené v moderním prostředí distribuovaných aplikací. Podrobně je analyzována možnost použít webový prohlížeč jako prostředí pro klientskou aplikaci a technologie, které jsou k tomuto účelu vhodné. Stručně jsou popsány již implementované takovéto systémy. Jejich vlastnosti jsou zhodnoceny na základě formulovaných obecných požadavků. Ve zbytku práce je popsána implementace aplikace, která se skládá ze serverové a klientské části. Klientská část používá webový prohlížeč pro vlastní vizualizaci technologie.
VII
VIII
Obsah 1 Úvod 1.1 Cíl práce . . . . . . . . . . . . . . . . . . . . . 1.2 Vymezení pojmů . . . . . . . . . . . . . . . . 1.2.1 SCADA . . . . . . . . . . . . . . . . . 1.2.2 HMI/MMI . . . . . . . . . . . . . . . . 1.3 Historie systémů SCADA/HMI . . . . . . . . 1.4 Výhody řízení pomocí SCADA/HMI systémů
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
1 1 1 1 2 2 3
2 Struktura SCADA/HMI systémů 2.1 Tradiční řešení . . . . . . . . . . . . . . . . . . 2.1.1 RTU . . . . . . . . . . . . . . . . . . . . 2.1.2 MTU . . . . . . . . . . . . . . . . . . . . 2.1.3 Centrální server(y) se SCADA softwarem 2.1.4 Komunikační infrastruktura a vybavení . 2.1.5 HMI aplikace . . . . . . . . . . . . . . . 2.1.6 Nevýhody tradičního řešení . . . . . . . 2.2 Představa moderního řešení . . . . . . . . . . . 2.3 HMI aplikace podrobněji . . . . . . . . . . . . . 2.3.1 Vizualizace technologie . . . . . . . . . . 2.3.2 Přehledové tabulky . . . . . . . . . . . . 2.4 Návrh moderního řešení . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
5 5 6 6 6 6 7 7 7 8 8 8 8
3 Komunikace klient – server 3.1 Obecné požadavky . . . . . . . . . . . . . . . . . 3.2 Webový prohlížeč v roli HMI aplikace . . . . . . . 3.2.1 Aplikace a dokument . . . . . . . . . . . . 3.2.2 Klient-server architektura obecně . . . . . 3.3 Tloušťka klienta . . . . . . . . . . . . . . . . . . . 3.3.1 Tenký klient . . . . . . . . . . . . . . . . . 3.3.2 Tlustý klient . . . . . . . . . . . . . . . . 3.3.3 Role serveru . . . . . . . . . . . . . . . . . 3.4 Rozdělení funkcí mezi server a klienta . . . . . . . 3.4.1 Tenký versus tlustý klient v HMI aplikaci . 3.4.2 Návrh řešení . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
11 11 11 11 12 13 13 13 13 14 14 15
4 Realizace zobrazení dynamických hodnot 4.1 Technologie použitelné pro RIA aplikace . 4.1.1 AJAX . . . . . . . . . . . . . . . . 4.1.2 Macromedia Flash player . . . . . . 4.1.3 Java applety . . . . . . . . . . . . . 4.1.4 Java aplikace (Java Web Start) . . 4.1.5 ActiveX . . . . . . . . . . . . . . . 4.1.6 .NET . . . . . . . . . . . . . . . . . 4.2 Webové služby . . . . . . . . . . . . . . . 4.2.1 SOAP . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
17 17 17 20 21 22 23 23 26 27
IX
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
4.2.2
WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Existující implementace 5.1 Reliance . . . . . . . . 5.1.1 Popis . . . . . . 5.1.2 Zhodnocení . . 5.2 Control Web . . . . . . 5.2.1 Popis . . . . . . 5.2.2 Zhodnocení . . 5.3 TirsWeb . . . . . . . . 5.3.1 Popis . . . . . . 5.3.2 Zhodnocení . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
6 Aplikace ScadaClient 6.1 Vytyčení základních rysů aplikace . . . 6.1.1 Funkční požadavky . . . . . . . 6.1.2 Analýza přenášených dat . . . . 6.2 Vybrané technologie . . . . . . . . . . 6.2.1 Serverová část . . . . . . . . . . 6.2.2 Klientská část . . . . . . . . . . 6.3 Popis serverové části . . . . . . . . . . 6.4 Popis appletu ScadaClient . . . . . . . 6.4.1 Činnost appletu obecně . . . . . 6.4.2 Tvorba klienta webové služby . 6.4.3 Vnitřní struktura appletu . . . 6.5 Popis appletu AnalogMeterApplet . . . 6.6 Tvorba vizualizace . . . . . . . . . . . 6.6.1 Vizualizace první – „elementarÿ 6.6.2 Vizualizace druhá – „basicÿ . . 6.6.3 Vizualizace třetí – „destilÿ . . . 6.7 Závěrečné shrnutí praktických ukázek .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . .
29 29 29 30 30 30 31 32 32 34
. . . . . . . . . . . . . . . . .
35 35 35 36 36 36 37 37 42 42 44 45 49 50 50 52 54 57
7 Závěr
59
8 Literatura
61
Rejstřík
67
Seznam použitých zkratek
69
A Uživatelská / instalační A.1 Požadavky na systém A.2 Součásti aplikace . . A.3 Postup instalace . . . A.4 Uživatelská příručka
příručka . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
B Obsah přiloženého CD
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
73 73 73 74 74 79
X
Seznam obrázků 1.1 1.2
Základní funkce SCADA/HMI systému . . . . . . . . . . . . . . . . . . . Příklady vizualizace technologického procesu . . . . . . . . . . . . . . . .
1 2
2.1 2.2
Struktura SCADA/HMI systému . . . . . . . . . . . . . . . . . . . . . . Návrh moderního řešení SCADA/HMI aplikace . . . . . . . . . . . . . .
5 9
3.1
Architektura klient-server . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8
Klasická vs. AJAX web aplikace . . . . . . . . . . . . . . Způsob interakce web aplikace . . . . . . . . . . . . . . . Architektura Flex . . . . . . . . . . . . . . . . . . . . . . Architektura OpenLaszlo . . . . . . . . . . . . . . . . . . Životní cyklus appletu a volání jeho metod . . . . . . . . Pohled na .NET . . . . . . . . . . . . . . . . . . . . . . . Architektura .NET Framework . . . . . . . . . . . . . . . Vztah tří základních technologií (SOAP, WSDL a UDDI)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webových služeb
18 19 20 21 22 24 25 26
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13
Struktura požadavku na webovou službu . . . . Struktura odpovědi webové služby . . . . . . . . ER model databáze ukázkové aplikace . . . . . . Diagram tříd webové služby . . . . . . . . . . . Sekvenční diagram činnosti webové služby . . . Sekvenční diagram činnosti appletu ScadaClient Diagram tříd appletu ScadaClient . . . . . . . . Sekvenční diagram činnosti appletu . . . . . . . Ukázka vizualizace pomocí appletu . . . . . . . Ukázka první vizualizace – „elementarÿ . . . . Ukázka druhé vizualizace – „basicÿ . . . . . . . Ukázka třetí vizualizace – „destilÿ . . . . . . . . Základní obrázek pro vizualizaci destilace . . . .
. . . . . . . . . . . . .
38 38 39 40 41 43 47 48 49 51 53 54 55
XI
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
XII
KAPITOLA 1. ÚVOD
1
1 Úvod 1.1
Cíl práce
Cílem práce je přinést přehled o SCADA/HMI systémech, jejich možnostech a vývoji. Druhým úkolem je seznámit zájemce s dnešními technologiemi, které se týkají komunikace klient-server v prostředí Internetu/Intranetu s ohledem na specifičnost SCADA/HMI aplikací, a posoudit jejich vhodnost. Třetím úkolem je rešeršní zpracování již hotových řešení. Závěrem je nutné vybrat vhodné technologie a implementovat v nich základní prvky řešení dovolující komunikaci se vzdáleným serverem přes Internet/Intranet a výstavbu uživatelského rozhraní.
1.2
Vymezení pojmů
SCADA HMI systémy mají za úkol řídit a kontrolovat průmyslové procesy a operátorům poskytnout kritická data v člověku srozumitelné a ergonomicky přijatelné formě, a tak mu usnadnit případný zásah do řízení. Pohled na SCADA HMI systém v nejobecnějším pohledu nabízí následující obrázek.
Obrázek 1.1: Základní funkce SCADA/HMI systému
1.2.1
SCADA
Pod pojmem SCADA (Supervisory Control and Data Acquisition) rozumíme počítačové systémy, které slouží, jak již jejich název napovídá, k řízení a kontrole stavů vzdálených technologických procesů. Tyto systémy jsou nasazovány k řízení jak velmi rozsáhlých systémů (výroba a distribuce elektrické energie, těžba, přeprava a zpracování ropy a jiných nerostných surovin, farmaceutické, chemické, potravinářské závody, systémy pro řízení a kontrolu vodárenských rozvodů a vodních toků atd.), tak i pro realizaci malých a jednodušších systémů (klimatizace a vytápění budov, řízení a monitoring menších výrobních linek atd.).
2 1.2.2
KAPITOLA 1. ÚVOD HMI/MMI
Pojmy HMI (Human – Machine Interface) či MMI (Man – Machine Interface) se v anglické terminologii označují systémy pro vizualizaci technologických procesů pracující jako rozhraní mezi technologickým zařízením a jeho obsluhou, česky – krátce operátorská rozhraní. HMI aplikace je vrstva mezi SCADA softwarem a operátorem. Nabízí operátorovi schéma technologického procesu doplněné o naměřená data a různé přehledové tabulky. Systém musí vhodně oznamovat vznik alarmů, umožnit pohled do databází na historii dat, na trendy změn apod. Cílem je operátorovi umožnit a maximálně usnadnit důležitá rozhodnutí při řízení. Moderní HMI systémy bývají vybaveny i detailními schématy jednotlivých částí technologie a expertními systémy, které pomáhají obsluze řešit mimořádné události.
Obrázek 1.2: Příklady vizualizace technologického procesu
1.3
Historie systémů SCADA/HMI
Počátky vývoje SCADA systémů se dají vysledovat až k počátku 20. století, kdy přichází potřeba telemetrie, tj. měření veličin na dálku. Díky dalšímu vývoji telefonu, telegrafu a bezdrátového spojení se stává dálkové měření uskutečnitelným. Časem se dálková měření pro např. plynařské, ropné, elektrárenské společnosti stala nezbytně nutnými. SCADA systémy se začínají stavět v brzkých 60. letech minulého století, kdy vzrůstá potřeba stále složitější technologické procesy kontrolovat a monitorovat efektivněji. Jsou řešeny jako složité elektronické vstupně-výstupní systémy, které zajišťují přenos signálů pomocí telemetrické sítě. Hlavní stanice přijímá naměřená data od jednotlivých vzdálených koncových systémů RTU (Remote Terminal Unit) a ukládá je v počítači typu mainframe. Vývoj, údržba a provoz těchto systémů jsou náročné na lidské zdroje, přesto jsou ve výsledku levnější, než technologie, které SCADA nepoužívají. V 70. letech jsou vyvinuty distribuované řídící systémy DCS (Distributed Control Systems). Standard ANSI/ISAS5.1 definuje distribuovaný řídící systém jako systém, který funkčně integruje jednotlivé subsystémy, které mohou být fyzicky odděleny a nacházet se v jiných lokalitách. Velké provozy začaly upřednostňovat DCS, protože byl požadován velký objem analogového řízení.
KAPITOLA 1. ÚVOD
3
Další vývoj přispěl k tomu, že se jako DCS začaly používat programovatelné automaty PLC (Programmable Logic Controller), které nabízejí více možností než RTU, jsou schopny řídit i bez pokynů z hlavní stanice. V druhé polovině devadesátých let se rozdíl mezi SCADA a DCS stírá. SCADA má schopnosti DCS a naopak. Vyvíjejí se univerzální systémy, pomocí kterých si je každý zákazník schopen vytvořit svou vlastní SCADA aplikaci na základě připravených knihoven komponent. S možnostmi Internetu, který je něčím víc než jen jednoduchým komunikačním kanálem, vzrůstá interkonektivita komponent systémů, možnosti distribuovatelnosti a přístupnosti k informacím o procesu. Označení HMI se nejprve používalo pro hardware (typicky operátorské panely), avšak s rychlým rozvojem programových prostředků se počátkem 90. let dvacátého století začalo používat i pro programy, které zajišťovaly stále komfortnější vizualizaci, splňující neustále rostoucí požadavky uživatelů. Nezanedbatelnou výhodou se stala také cena počítačů, na které HMI aplikace běží. Díky masové výrobě je skutečně velmi nízká. Moderní SCADA/HMI systém je řešen jako otevřený a standardizovaný. To umožňuje vyvinout jeden univerzální systém, pomocí kterého se dá výsledná aplikace snadno vytvořit a v případě potřeby rozšiřovat s co nejmenšími náklady.
1.4
Výhody řízení pomocí SCADA/HMI systémů
Ve stručnosti se dají výhody shrnout do těchto bodů: • výrazné snížení výdajů, • úspora pracovních sil, • včasná diagnostika poruchy, • možnost předpovědět poruchu dříve než nastane, • sofistikovanější možnosti řízení založené na dlouhodobém sběru dat a jejich vyhodnocování, • modularita systému a možnost autonomní funkce jeho subsystémů, • zvýšení bezpečnosti práce, • rozsáhlé možnosti při hlášení a řešení kritických stavů (alarmy), • snadné rozšiřování systému a jeho modernizace, atd.
4
KAPITOLA 1. ÚVOD
KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ
2 Struktura SCADA/HMI systémů 2.1
Tradiční řešení
Základní komponenty každého SCADA systému jsou: • jedna či několik RTU (Remote Terminal Unit), • MTU (Main Terminal Unit), • centrální velín s hostitelským serverem/servery, • komunikační infrastruktura.
Obrázek 2.1: Struktura SCADA/HMI systému
5
6 2.1.1
KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ RTU
RTU jednotky propojují na jedné straně jednotlivá fyzická zařízení jako jsou motory, čerpadla, ventily, čidla atd. s MTU na straně druhé. MTU obsluhuje jednotlivé RTU, které na požadavek předají ze své paměti naměřená data a přijmou povely, které potom předá vlastním fyzickým zařízením. RTU jednotky bývají realizovány jako mikropočítače a programovatelné automaty PLC (Programmable Logic Controller), které dovolují řešit jednodušší úkoly na vzdálené straně (tj. na straně fyzických zařízení) autonomně, tj. bez účasti MTU. Umožňuje to výraznou modularitu a rozšiřitelnost systému. RTU jsou k MTU připojeny buď přímo, nebo pomocí nějaké sítě či sběrnice. Protokol může být buď otevřený (např. Modbus, Transmission Control Protocol and Internet Protocol (TCP/IP)), nebo chráněný průmyslovým vlastnictvím (např. Siemens H1). 2.1.2
MTU
MTU komunikuje se všemi připojenými RTU a s centrálním serverem a s rozhraním operátora. Někdy bývá MTU přímo součástí serveru. Data ze vzdálených fyzických zařízení jsou pomocí RTU předána MTU, která je dále zpracuje, popř. předá dalším systémům. 2.1.3
Centrální server(y) se SCADA softwarem
Centrální servery umožňují běh SCADA softwaru. Starají se o vlastní řízení, o ukládání dat do databází (databáze hodnot, logů, alarmů, atd.), výpočty a komunikaci s operátorským software (HMI). 2.1.4
Komunikační infrastruktura a vybavení
Na komunikační infrastrukturu a vybavení SCADA systému jsou kladeny vysoké nároky. Musí zajistit obousměrnou komunikaci mezi MTU a jednotlivými RTU. Požadována je vysoká spolehlivost spojení a u geograficky rozlehlých systémů je třeba komunikovat na značné vzdálenosti. Systémy řízení distribuce elektrické energie či vodohospodářské aplikace jsou typickým příkladem takto rozsáhlých aplikací. Z hlediska návrháře takovéto aplikace můžeme komunikační prostředky rozdělit do dvou základních kategorií: veřejné a soukromé. Veřejné komunikační prostředky jsou komunikační služby, za které uživatel platí provozovateli (telekomunikační společnosti). Do této kategorie spadají spojení realizovaná vytáčeným propojením (dial-up), pronajaté pevné linky, ISDN, ADSL linky a datová spojení nabízená mobilními operátory. Soukromé komunikační prostředky jsou vlastněny a spravovány uživatelem. Spojení může být realizováno natažením vlastního kabelu (ať už metalického nebo optického) či bezdrátově. Bezdrátové spojení bývá realizováno buď mikrovlnnými point-to-point spoji, nebo VHF/UHF radiovým spojením. Mezi ostatní komunikační prostředky můžeme zařadit WiFi technologii, která poskytuje rychlou komunikaci, ale vyžaduje spojení pokročilými protokoly jako je TCP/IP a síťový typ spojení. Další možností pro extrémní nároky je využití komunikačních geostacionárních družic, nebo družic LEO (Low Earth Orbit). Tento typ družic obíhá, jak
KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ
7
název napovídá, na nízké oběžné dráze, a proto nemohou být geostacionární. Proto družice mezi sebou komunikují a přenášená data si předávají, aby bylo zabezpečeno trvalé pokrytí signálem. Jejich výhodou je menší časová latence než mají družice geostacionární. Vzhledem k požadavku vysoké spolehlivosti a bezporuchovosti spojení může být použito více komunikačních prostředků. Vypadne-li jeden typ komunikace, může být použit jiný, záložní. 2.1.5
HMI aplikace
Není součástí SCADA systému, ale její funkce je klíčová: umožňuje styk člověka se systémem. Vhodným způsobem naměřená data zprostředkovává operátorovi, který se na jejich základě rozhoduje o dalším postupu řízení. 2.1.6
Nevýhody tradičního řešení
Položíme-li si do systému pomyslnou dělící rovinu na úroveň SCADA serveru, v části od fyzických zařízení až k (a včetně) serveru budeme hledat asi těžko nějakou vážnou nevýhodu. Systémy se stávají stále více modulární a jejich části umožňují v případě poruchy nebo výpadku komunikace i do jisté míry autonomní činnost. Rezervy najdeme v druhé části systému - tedy ve vrstvě HMI a její komunikace se SCADA serverem. Každý, kdo chce přistupovat k systému, musí mít nainstalovaný speciální HMI software a navíc jsou data dostupná pouze z vnitřní sítě. Klientské aplikace je nutné při každé změně technologie znovu nastavit, přičemž standardní popis vizualizace procesů neexistuje – co výrobce, to řešení.
2.2
Představa moderního řešení
• Distribuovatelnost systému – jednotlivé komponenty systému mohou být rozprostřeny na různých počítačích propojených do sítě. Sítí není myšlena jen vnitropodniková síť, ale i globální síť Internet. Zejména klademe důraz na HMI část. Požadujeme přístup k aplikaci skutečně ze kteréhokoli počítače připojeného k Internetu (počítačem rozumíme i přenosná zařízení typu PDA, „chytréÿ mobilní telefony apod.). Z tohoto důvodu vyvstává požadavek, aby jako klientská aplikace nebyl použit žádný speciální software. • Bezpečnost systému – aplikace by měla umožnit plný přístup k technologii, ale jen pověřeným osobám s příslušnými právy. Komunikace přes internet by měla být v maximální míře kryptována, aby se zabránilo úniku dat či dokonce útokům na systém. • Snadná údržba a další rozšiřování aplikace – díky distribuovanému řešení jsou možná různá uspořádání systému, která se navíc mohou dynamicky měnit. Všechna konfigurační data by měla být soustředěna na jednom místě, aby je stačilo změnit jen jednou a změněné parametry byly okamžitě k dispozici všem ostatním uživatelům. Ve shodě s požadavkem na distribuovatelnost by mělo být možné i tyto administrátorské činnosti provádět vzdáleně. • Standardizovaná řešení – tvorba vizualizací technologie by měla být založena na již zažitých standardech – klesají tak náklady na výrobu a rozšiřování vizualizací.
8
KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ • Efektivnost – požadujeme-li rozprostření aplikace po síti, musíme pamatovat na omezenou rychlost přenosu a výkonnost serveru (má-li být obsluhováno větší množství klientů).
2.3
HMI aplikace podrobněji
Každá rozsáhlejší HMI aplikace musí poskytnout operátorovi data ve dvou základních tvarech: • ve schématické vizualizaci technologie, • v přehledových tabulkách, popř. grafech. 2.3.1
Vizualizace technologie
Pohled na technologii je realizován jako grafické schéma, které je doplněno aktuálními daty a řídícími mechanismy umožňující povelování. Například operátor vidí soustavu trubek, čerpadel a ventilů. U čerpadla je číselně vyjádřen průtok, u ventilu jeho stav, u trubek teplota kapaliny atd. Při překročení povolených mezí či poruše by se, kromě samozřejmé alarmovací hlášky, měl chybový stav promítnout i do vizualizace (nekomunikující komponentu např. přeškrtnout, překročení normálního stavu měřidla indikovat jeho výrazným podbarvením atd.). U rozsáhlých projektů je nutné vizualizaci rozčlenit do přiměřených částí. Je třeba dbát na to, aby zůstala zachována přehlednost, ale je nanejvýš vhodné, když jedna obrazovka vizualizace zobrazuje určitou logickou část technologie. Jsme-li nuceni vizualizaci takto rozčlenit, je nutné navrhnout takový způsob procházení vizualizací, aby uživatel měl ke každé části snadný, rychlý a intuitivní přístup. 2.3.2
Přehledové tabulky
I pro zobrazení přehledových tabulek platí podobné zásady jako pro vlastní schéma technologie. Rovněž je vhodné uživatele informovat o chybových a mezních stavech např. podbarvením příslušné buňky tabulky. Tabulky musejí poskytnout operátorovi ten druh informace, kterou není možné zobrazit na schematické vizualizaci: různé souhrny, součty, výsledky výpočtů atd. Např. v aplikaci, která řídí vytápění města bude určitě užitečná přehledová tabulka, ve které budou uvedeny průtoky a teploty vody na vstupech a výstupech jednotlivých výměníkových stanic a z nich spočítané dodané teplo.
2.4
Návrh moderního řešení
Porovnáme-li výše uvedené požadavky s možnostmi, které nám poskytuje současný stav IT technologií, nabízí se pro toto řešení použít jako klientskou aplikaci standardního prohlížeče www stránek, který skutečně nechybí na absolutní většině počítačů připojených k Internetu. Serveru SCADA aplikace tak přibývá ještě jedna funkce. Kromě sběru dat od jednotlivých technologií, jejich zpracování, uložení do databází, musí klientovi poskytnout i www projekt, který odpovídá vizualizaci stavu řízeného technologického procesu.
KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ
9
Operátoři přímo v podniku rovněž používají jako klientský software standardní www prohlížeč. S ohledem na bezpečnost je vhodné umísit internetovou aplikaci na veřejný (veřejně přístupný) www server mimo síť Intranetu. Internetová aplikace by neměla mít přístup ke zdroji on-line dat – k MTU. Téměř úplnou bezpečnost zajišťuje způsob, kdy na SCADA serveru běží speciální komponenta, která se stará o zápis aktuálních hodnot signálů do databáze na web serveru, odkud jsou dány k dispozici všem klientům veřejného Internetu. Navrhnutou strukturu vystihuje obr. 2.2.
Obrázek 2.2: Návrh moderního řešení SCADA/HMI aplikace
10
KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ
KAPITOLA 3. KOMUNIKACE KLIENT – SERVER
11
3 Komunikace klient – server V této kapitole bude soustředěna pozornost na komunikaci mezi klientskou aplikací a serverem, speciálně pak přihlédnu ke specifikům SCADA/HMI systémů. Konkrétně se soustředím na to, jak v prostředí Internetu dostát požadovaným nárokům na komunikaci SCADA – HMI v případě, že klientskou aplikací HMI je standardní webový prohlížeč.
3.1
Obecné požadavky
• Efektivita – komunikace mezi serverem a klientem musí být efektivní. Způsob, jak toho dosáhnout, spočívá v minimalizaci přenášených dat a tzv. událostním rozesíláním (event processing). Server rozesílá klientům jen hodnoty dat, nikoli již znovu celou vizualizaci, byť se změněnými parametry. Zjednodušeně řečeno: při změně dat je klientovi odeslána pouze hodnota, kterou má např. nějaké měřidlo zobrazit a ne znovu celý obrázek měřidla s ručičkou v příslušné poloze. • Bezpečnost – případný útočník nesmí být schopen zachycená data zneužít, nepozorovaně pozměnit, či – v tom nejhorším případě – vniknout do sytému a mít možnost povelování. Otázka zabezpečení je v mnoha SCADA aplikacích klíčová. Kdyby např. hacker najednou vypustil celou Vltavskou kaskádu, následky by byly nedozírné. • firewall-friendly politika – musíme brát v úvahu, že při přístupu ze sítě Internet může stát mezi serverem a klientem i několik firewallů. Komunikace musí projít firewally bez toho, aniž by byla odfiltrována. Tento požadavek nás může donutit veškerá přenášená data „zabalitÿ do protokolu HTTP. Samozřejmě tento požadavek můžeme vypustit, pokud se budeme pohybovat v prostředí Intranetu, kde si můžeme dovolit mnohem efektivnější komunikaci např. pomocí TCP spojení.
3.2
Webový prohlížeč v roli HMI aplikace
V předchozích kapitolách byla HMI aplikace označena za klíčovou část řídícího systému, která zprostředkovává styk operátora se SCADA serverem. V minulosti toto pole ovládaly specializované aplikace od různých výrobců, ale v současnosti se stále více prosazuje „obyčejnýÿ webový prohlížeč. Výhodou je jeho obrovská rozšířenost a dostupnost. Při použití tohoto řešení tak získáváme možnost prakticky bezpracně rozšířit aplikaci i do prostředí Internetu. 3.2.1
Aplikace a dokument
Primárním úkolem prohlížeče je zobrazování webových dokumentů. K tomuto úkolu byl také vyvinut v době, kdy byl web statický a založený především na zobrazování akademického obsahu. V poslední době ale stále více sílí snaha využít prohlížeč více aplikačně (a to je i náš případ s HMI aplikací). Pokusíme-li se o definici pojmu internetová-intranetová aplikace, můžeme říci, že je to software, který umí: • vytvářet, zpracovat, manipulovat a ovládat grafické uživatelské prostředí (GUI) jako prostředek pro splnění cílů uživatele,
12
KAPITOLA 3. KOMUNIKACE KLIENT – SERVER • zachycovat a zpracovávat uživatelské podněty, vstupy a výstupy, • pracovat s daty a z externích zdrojů je načítat a ukládat, • zpracovávat zadané úkoly lokálně nebo vzdáleně, • komunikovat se vzdálenými uzly a využívat jejich prostředky.
3.2.2
Klient-server architektura obecně
Software na bázi klient server je většinou možné rozdělit na tři vrstvy a nejinak je tomu i u HMI aplikace. Pro srozumitelnost modelu předpokládejme, že vytváříme internetovou aplikaci, která ve shodě s výše uvedenými bezpečnostními opatřeními získává aktuální data z databáze, která je umístěna na veřejném internetovém serveru. Architektura klient-server se skládá z těchto vrstev: • prezentační vrstva – uživatelské rozhraní (GUI), • vrstva aplikační logiky – provádí výpočty, • datová vrstva – systém řízení báze dat (SŘBD). Oddělením jednotlivých vrstev získáváme výhody ve zjednodušeném a zpřehledněném vývoji a údržbě. Dříve souborový server je v architektuře klient-server nahrazen databázovým. Výsledkem je mimo jiné snížení zatížení sítě, protože se přenášejí pouze výsledky požadované dotazy klienta a nikoli celé soubory.
Obrázek 3.1: Architektura klient-server Architektury klient – server se dělí podle toho, kde se nachází vrstva aplikační logiky: • Tlustý klient. Přístup spojuje prezentační vrstvu s vrstvou aplikační logiky. Ta běží spolu na klientovi a datová vrstva běží na serveru. Náklady na změnu typu databáze nebo logiky jsou vysoké, protože je potřebné aktualizovat software na všech klientech.
KAPITOLA 3. KOMUNIKACE KLIENT – SERVER
13
• Tenký klient. Výpočty běží spolu s SŘBD na serveru. To zvyšuje rychlost a snadnost správy aplikace. Tenký klient jenom pasivně zobrazuje přijímané výsledky. Jak je vidět na výše uvedeném obrázku, model klient-server není přísně diskrétní, ale má několik stupňů. Prohlížeč je mixem tenkého a tlustého klienta, kdy rozhraní generuje server, avšak zobrazuje klient. Část aplikace se provádí na straně serveru, část u klienta pomocí skriptů.
3.3
Tloušťka klienta
Ačkoli jsou webové prohlížeče označovány jako tencí klienti, úvaha na téma tloušťka klientské aplikace je zcela na místě, neboť díky různým pluginům, appletům a skriptům můžeme i z prohlížeče vytvořit relativně tlustého klienta. 3.3.1
Tenký klient
V modelu tenkého klienta předpokládáme, že klient má minimální vlastní schopnosti; že je opravdu pouhým prohlížečem a server mu musí předložit data tak, aby je bylo možné pouze zobrazit. Tento model předpokládá, že klient obdrží již naformátovaná data ve formě XHTML a CSS, tj. server generuje GUI, vzhled a data. Při tvorbě webové aplikace tímto stylem vycházíme v podstatě z teorie klasických webových stránek. Výhodou tohoto řešení je univerzálnost – takto vytvořené stránky bude umět zobrazit celá řada klientů webu – od naprosté většiny prohlížečů na platformě PC, přes mobilní zařízení až po webovou televizi apod. Nevýhodou je velká zátěž serveru (každá stránka je znovu vytvářena včetně designu) a komunikační náročnost – nepříznivý code-to-content-ratio tedy poměr mezi režijními daty a požadovanými informacemi. 3.3.2
Tlustý klient
V tomto modelu se úloha serveru redukuje. Při prvním požadavku na aplikaci se nahraje klientská část, ale pak už se klientovi posílají jen „surováÿ data. O jejich další zpracování a prezentaci v prohlížeči už se stará klient. Výhody jsou zřejmé – klesá zátěž serveru a vytížení komunikační cesty. Tím je urychlen běh aplikace. Nevýhodná je nutnost použití „inteligentnějšíchÿ prohlížečů, které budou schopny nabídnout podporu náročnějším programovacím prostředkům (JavaScript, Java VM, Flash, .NET Framework. . . ). Možnosti moderních prohlížečů vzrůstají a budeme-li hovořit zejména o platformě PC, můžeme tvrdit, že podpora prvních tří výše uvedených prostředků se stává standardem. Zejména v prostředí Intranetu víme, pomocí jakých prohlížečů bude k aplikaci přistupováno a tomu můžeme přizpůsobit vývoj. 3.3.3
Role serveru
Na předcházející úvahy o tloušťce klienta se nyní zkusme podívat s pohledu serveru. V případě tenkého klienta server generuje GUI, naproti tomu tlustému klientovi posílá nezpracovaná data a jeho funkce se tak omezuje prakticky jen na připojení k databázi.
14
KAPITOLA 3. KOMUNIKACE KLIENT – SERVER
Druhý způsob popisuje Martin Kopta ve svém článku [27], kde tvrdí, že HTTP protokol se zneužívá jako transport dalších „nadprotokolůÿ. Funkci serverů pro oba klienty zkusím ukázat na konkrétním případě. Předpokládejme aplikaci setříděného seznamu dat z databáze. Kód pro obsluhu tenkého klienta: // připojení na databázi a získání dat // setříděni dat // tisk celé (X)HTML stránky, GUI ..... // Tisk setříděného seznamu osob for($x=0; $x
Osoba ".$x." : ".$lide[$x]; } Kód pro obsluhu tlustého klienta: // připojení na databázi a získání dat // tisk seznamu osob v~Javascriptu for($x=0; $x
či nověji . Z bezpečnostních důvodů platí pro applet některá omezení1 a naopak má applet některé funkce rozšířeny: • Applet nemůže nahrávat knihovny ani definovat nativní metody. • Applet nemůže navazovat síťové spojení na jiný než domovský server. • Applet nemůže zapisovat do souborů na straně klienta (prohlížeče). • Applet nemůže spouštět programy na domovském serveru. • Applet nemůže číst některé systémové proměnné. • Applet může přehrávat zvuky. • Applet může požádat prohlížeč o zobrazení libovolné www stránky. • Applet může volat veřejné metody appletů umístěných na téže www stránce. 1, za nímž následuje popis prvku a jednotlivé parametry; celý objekt se pak uzavře tagem . Když při načítání www stránky narazí prohlížeč na takové „voláníÿ ActiveX prvku, nejprve se podívá, zda se vyskytuje na lokálním disku. Pokud hledaný prvek nenajde, pokusí se jej stáhnout z místa (ať už na Internetu, či firemní sítě), kde se ActiveX Control nachází. To může být např. domovská stránka firmy, která prvek vyrobila. Aby jednotlivé prvky www stránky (ActiveX Controls, Java applety a další) plnily vůbec nějakou funkci, musejí mezi sebou vzájemně komunikovat. Vytvoření těchto vzájemných vazeb mezi prvky www stránky lze provést pomocí skriptování, a to buď s pomocí Visual Basic Scriptu (VB Script), nebo JavaScriptu. Stručně můžeme shrnout, že použití ActiveX komponent je stejné jako u Java appletů. Rozdíl je v tom, že ActiveX komponenty jsou spustitelné pouze na platformě Win32. Nižší přenositelnost je však vyvážena v současné době stále ještě vyšším výkonem oproti Javě. Kromě různých multimediálních aplikací se dnes ActiveX používá například v GISech, které mají být přístupné pomocí Webu. Komponenta zajišťuje právě poměrně náročnou část zobrazovaní mapy a navigace v ní. ActiveX komponenty dovolují dosáhnout nároky kladené na komunikaci ve SCADA/HMI systému. Omezení pouze na jednu platformu ale odsouvá jejich použití spíše do oblasti Intranetu. 4.1.614.5 V ukázkách SOAP zpráv je použit jmenný prostor http://schemas.xmlsoap.org/ soap/encoding/, který identifikuje způsob kódování přenášených dat do XML. Se SOAPem můžeme použít libovolný způsob serializace, standard SOAPu jeden rovnou definuje. Standardní serializace je schopná do XML převést graf obsahující otypované definice datových typů, • <message> komunikační zpráva – odpovídá zavolání nebo návratu z funkce, • <portType> souhrn operací – odpovídá interface (Java) nebo header souboru (C), • odpovídá metodě (Java) nebo funkci (C), • definuje možný způsob přístupu různými protokoly, • <service> a <port> pro každý definují adresu na kterou se má příslušný protokol spojit. Podrobnější popis lze nalézt na stránkách W3C [61].analog.sig5 analog.sig1 12 40,0202388452445 <param name="serviceURI" value="http://localhost/scada/Resolve.asmx"/> <param name="namespace" value="http://tempuri.org/"/> <param name="nameOfWebmethod" value="resolve"/> <param name="nameOfParameterOfWM" value="req"/> <param name="refresh" value="1000"/> <param name="visibility" value="true"/> Applet, s id SCA (podle ScadaClientApplet) bude komunikovat se službou, která se nachází na tomto počítači v adresáři scada, jmenuje se Resolve.asmx, leží ve jmenném prostoru http://tempuri.org/, poskytuje webovou metodu resolve a parametr webové metody se jmenuje req. Kontaktovat službu bude každých 1000 ms a bude vypisovat hlášení o své činnosti. Rád bych upozornil na atribut mayscript, který je nutné uvést, aby applet mohl volat JavaScriptové funkce. Jako další uvedu JavaScriptovou funkci, která se spustí při načtení stránky a která zaregistruje požadované zdroje dat a jejich obslužné funkce a zahájí komunikaci se serverem. function onLoad() { document.SCA.registerAnalogFunction(’auto_1’,’onAuto_1’); document.SCA.registerAnalogFunction(’auto_2’,’onAuto_2’); document.SCA.startCommunication(); } Dále je nutné napsat obslužné funkce, které jsme zaregistrovali apletu v předchozí funkci a které budou volány v případě, že se hodnota daného signálu změní.Elementar demonstration of Scada client auto_1 = ... Podíváme-li se na zdrojový kód první vizualizace, uvidíme, že opravdu v něm nic víc není. Nyní můžeme spustit aplikace DBWriter a sledovat měnící se hodnoty signálů auto 1 a auto 2. (První z nich je zlomek sekundy z aktuálního času a druhý signál je sinus prvního.) Confirm alarm_3! function confirmAlarm(alarm, button) { button.style.display = ’none’; document.SCA.confirmAlarm(alarm,button.name); } v Internet Exploreru. <param name="caption" value="Teplota ◦ [C]"/> <param name="LabelsString" value="20,30,40,50,60,70,80,90,100,110"/> Ve funkci onLoad() je třeba ještě nastavit podbarvení stupnice: document.am.setColorRange(’#BBBBBB’,0,40); document.am.setColorRange(’#FF9900’,39,48); document.am.setColorRange(’#FF0000’,47,65); document.am.setColorRange(’#FF9900’,76,87); document.am.setColorRange(’#FF0000’,86,100); A už stačí jen volat metodu setValue() z funkce, která je volána appletem při změně teploty baňky. Argument je nutné přepočítat z hodnoty ve stupních Celsia na odpovídající výchylku ručičky vyjádřenou v procentech. function onTeplotaBanka(val) { if ( isNaN(val) ) { document.getElementById(’teplotaBanka’).value = ’???’; document.am.setValue(-1); } else { document.getElementById(’teplotaBanka’).value = val; document.am.setValue(Math.round((val-20)*1.11111)); } } [2] ADOBE SYSTEM INCORPORATED: Macromedia Flash Player Statistics. [online], 2005, [cit. 12. 2. 2006]. [6] COMB, G.: Ethereal. [software], 2005, [cit. 3. 9. 2006]. [9] CORERA, A.; FRASER, S.; McLEAN, S.; aj.: Visual C++.NET pro programátory v C++. Brno: Computer Press, první vydání, 2003, ISBN 80-7226-860-0, 400 s. [10] DANEELS, A.; SALTER, W.: What is SCADA? [online], 2000, [cit. 12. 2. 2006]. [13] DENNISON, R.: SCADA System Assessment. [online], 2005, [cit. 12. 2. 2006]. [14] DOSTÁLEK, L.; KABELOVÁ, A.: Velký průvodce protokoly TCP/IP a systémem DNS. Brno: CP Books, třetí vydání, 2005, ISBN 80-722-6675-6, 542 s. [16] EAGLE, M.: Integrating Macromedia Flex with Java. [online], 12. 1. 2004, [cit. 12. 2. 2006]. [17] van ENGELEN, R. A.: gSOAP: C/C++ Web Services and Clients. [online], 2006, [cit. 25. 12. 2006]. [18] FREILIGH, L.: Flex Intorduction. [online], 2006, [cit. 12. 2. 2006]. [20] GEOVAP s.r.o.: Reliance, Industrial SCADA/HMI system. [online], 2006, [cit. 3. 9. 2006]. [22] van HEESCH, D.: Doxygen, source code documentation generator tool. [software], 2006, [cit. 26. 12. 2006]. [25] KANISOVÁ, H.; MÜLLER, M.: UML srozumitelně. Brno: Computer Press, druhé vydání, 2006, ISBN 80-251-1083-4, 176 s. [26] KOFRÁNEK, J.: Control Web - Objektové vývojové prostředí (nejen) pro průmyslové aplikace. [online], 3. 3. 2005, [cit. 3. 9. 2006]. [27] KOPTA, M.: Web ovládnou aplikace. [online], 2002, [cit. 12. 2. 2006]. [30] KOTALA, Z.; TOMAN, P.: Programovací jazyk [cit. 12. 2. 2006]. [32] KUSÝN, M.: Webový prohlížeč jako platforma pro Internet a Intranet aplikace. [online], 2004, [cit. 12. 2. 2006]. [33] LACKO, Ľ.: ASP.NET pre začiatočníkov. Praha: Microsoft, 1. 3. 2002, 165 s. [34] MARSHALL, D.: The .NET Architecture. [online], 2004, [cit. 12. 2. 2006]. [35] MICROSOFT CORPORATION: Přehled architektury .NET. Redmond: Microsoft Corporation, 2001, 146 s. [36] MICROSOFT CORPORATION: Co je platforma [cit. 12. 2. 2006]. [39] MORAVSKÉ PŘÍSTROJE: Co je Control Web? [online], 28. 8. 2006, [cit. 3. 9. 2006]. [40] MOUTOVIC, V.: Programování ve VB.NET (4.) - Co je .NET Framework. [online], 13. 7. 2004, [cit. 12. 2. 2006]. [41] MYWISEOWL: SCADA. [online], 2004, [cit. 12. 2. 2006]. [42] NAIMAN, M.: Mé jméno je .NET. [online], 1. 3. 2002, [cit. 12. 2. 2006]. [43] NAKHIMOVSKY, A.; MYERS, T.: Google, Amazon, and Beyond: Creating and Consuming Web Services. Berkeley: Apress, první vydání, 2004, ISBN 1-59059-1313, 324 s. [44] Netbeans: NetBeans IDE 5.0 Quick Start Guide for Web Service Clients. [online], 2005, [cit. 25. 12. 2006]. [46] PATRNÝ, V.: Java Web Start. [online], 2. 4. 2003, [cit. 12. 2. 2006]. [47] PETŘÍK, M.: Programujeme ve Visual Basic .NET - 13. díl - letem světem .NET Frameworku. [online], 16. 11. 2004, [cit. 12. 2. 2006]. [48] PICHLÍK, R.: Rich Internet Application. [online], 14. 6. 2005, [cit. 12. 2. 2006]. [49] PUŠ, P.: Poznáváme C# a Microsoft .NET, seriál. [online], 2004 – 2006, [cit. 26. 12. 2006]. [50] Přispěvatelé projektu Jade: JADE, library for scientific applications. [software], 2006, [cit. 26. 12. 2006]. [52] SEMECKÝ, J.: Realtime komunikace Java appletů přes firewall. [online], 10. 12. 2002, [cit. 12. 2. 2006]. [53] SHARP, J.: Microsoft Visual C# 2005 Step by Step. Redmond: Microsoft Corporation, první vydání, 2006, ISBN 0-7356-2129-2, 555 s. [54] SHODJAI, P.: Web Services and the Microsoft Platform. [online], 2006, [cit. 25. 12. 2006]. [55] SNÍŽEK, M.: AJAX - kde jsou hrannice? [online], 13. 9. 2005, [cit. 12. 2. 2006]. [57] TOMÁŠEK, R.: Řízení modelu s využitím Internetu. [online], 27. 5. 2004, [cit. 3. 9. 2006]. [58] VRÁNA, J.: AJAX. [online], 3. 10. 2005, [cit. 12. 2. 2006]. [60] WISZCZOR, T.: .NET Remoting pod lupou. [online], 2003, [cit. 12. 2. 2006]. [61] World Wibe Web Consorcium: Web Services Description Language (WSDL) 1.1, W3C Note. [online], 15. 3. 2001, [cit. 3. 9. 2006]. [64] ŠIMEK, P.: Rich Internet Applications a Flash Remoting. [online], 3. 4. 2003, [cit. 12. 2. 2006].
