Klientské rozhraní aplikací SCADA

České vysoké učení technické v Praze Fakulta elektrotechnická ČVUT FEL katedra počítačů 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.1 Cíl práce.................................... 1 1.2 Vymezení pojmů............................... 1 1.2.1 SCADA................................ 1 1.2.2 HMI/MMI............................... 2 1.3 Historie systémů SCADA/HMI....................... 2 1.4 Výhody řízení pomocí SCADA/HMI systémů............... 3 2 Struktura SCADA/HMI systémů 5 2.1 Tradiční řešení................................ 5 2.1.1 RTU.................................. 6 2.1.2 MTU.................................. 6 2.1.3 Centrální server(y) se SCADA softwarem.............. 6 2.1.4 Komunikační infrastruktura a vybavení............... 6 2.1.5 HMI aplikace............................. 7 2.1.6 Nevýhody tradičního řešení..................... 7 2.2 Představa moderního řešení......................... 7 2.3 HMI aplikace podrobněji........................... 8 2.3.1 Vizualizace technologie........................ 8 2.3.2 Přehledové tabulky.......................... 8 2.4 Návrh moderního řešení........................... 8 3 Komunikace klient server 11 3.1 Obecné požadavky.............................. 11 3.2 Webový prohlížeč v roli HMI aplikace.................... 11 3.2.1 Aplikace a dokument......................... 11 3.2.2 Klient-server architektura obecně.................. 12 3.3 Tloušťka klienta................................ 13 3.3.1 Tenký klient.............................. 13 3.3.2 Tlustý klient............................. 13 3.3.3 Role serveru.............................. 13 3.4 Rozdělení funkcí mezi server a klienta.................... 14 3.4.1 Tenký versus tlustý klient v HMI aplikaci.............. 14 3.4.2 Návrh řešení.............................. 15 4 Realizace zobrazení dynamických hodnot 17 4.1 Technologie použitelné pro RIA aplikace.................. 17 4.1.1 AJAX................................. 17 4.1.2 Macromedia Flash player....................... 20 4.1.3 Java applety.............................. 21 4.1.4 Java aplikace (Java Web Start)................... 22 4.1.5 ActiveX................................ 23 4.1.6.NET.................................. 23 4.2 Webové služby................................ 26 4.2.1 SOAP................................. 27 IX

4.2.2 WSDL................................. 28 5 Existující implementace 29 5.1 Reliance.................................... 29 5.1.1 Popis.................................. 29 5.1.2 Zhodnocení.............................. 30 5.2 Control Web.................................. 30 5.2.1 Popis.................................. 30 5.2.2 Zhodnocení.............................. 31 5.3 TirsWeb.................................... 32 5.3.1 Popis.................................. 32 5.3.2 Zhodnocení.............................. 34 6 Aplikace ScadaClient 35 6.1 Vytyčení základních rysů aplikace...................... 35 6.1.1 Funkční požadavky.......................... 35 6.1.2 Analýza přenášených dat....................... 36 6.2 Vybrané technologie............................. 36 6.2.1 Serverová část............................. 36 6.2.2 Klientská část............................. 37 6.3 Popis serverové části............................. 37 6.4 Popis appletu ScadaClient.......................... 42 6.4.1 Činnost appletu obecně........................ 42 6.4.2 Tvorba klienta webové služby.................... 44 6.4.3 Vnitřní struktura appletu...................... 45 6.5 Popis appletu AnalogMeterApplet...................... 49 6.6 Tvorba vizualizace.............................. 50 6.6.1 Vizualizace první elementar................... 50 6.6.2 Vizualizace druhá basic..................... 52 6.6.3 Vizualizace třetí destil...................... 54 6.7 Závěrečné shrnutí praktických ukázek.................... 57 7 Závěr 59 8 Literatura 61 Rejstřík 67 Seznam použitých zkratek 69 A Uživatelská / instalační příručka 73 A.1 Požadavky na systém............................. 73 A.2 Součásti aplikace............................... 73 A.3 Postup instalace................................ 74 A.4 Uživatelská příručka............................. 74 B Obsah přiloženého CD 79 X

Seznam obrázků 1.1 Základní funkce SCADA/HMI systému................... 1 1.2 Příklady vizualizace technologického procesu................ 2 2.1 Struktura SCADA/HMI systému...................... 5 2.2 Návrh moderního řešení SCADA/HMI aplikace.............. 9 3.1 Architektura klient-server.......................... 12 4.1 Klasická vs. AJAX web aplikace....................... 18 4.2 Způsob interakce web aplikace........................ 19 4.3 Architektura Flex............................... 20 4.4 Architektura OpenLaszlo........................... 21 4.5 Životní cyklus appletu a volání jeho metod................. 22 4.6 Pohled na.net................................ 24 4.7 Architektura.NET Framework........................ 25 4.8 Vztah tří základních technologií (SOAP, WSDL a UDDI) webových služeb 26 6.1 Struktura požadavku na webovou službu.................. 38 6.2 Struktura odpovědi webové služby...................... 38 6.3 ER model databáze ukázkové aplikace.................... 39 6.4 Diagram tříd webové služby......................... 40 6.5 Sekvenční diagram činnosti webové služby................. 41 6.6 Sekvenční diagram činnosti appletu ScadaClient.............. 43 6.7 Diagram tříd appletu ScadaClient...................... 47 6.8 Sekvenční diagram činnosti appletu..................... 48 6.9 Ukázka vizualizace pomocí appletu..................... 49 6.10 Ukázka první vizualizace elementar.................. 51 6.11 Ukázka druhé vizualizace basic..................... 53 6.12 Ukázka třetí vizualizace destil...................... 54 6.13 Základní obrázek pro vizualizaci destilace.................. 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 KAPITOLA 1. ÚVOD 1.2.2 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Ů 5 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

6 KAPITOLA 2. STRUKTURA SCADA/HMI SYSTÉMŮ 2.1.1 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<count($lide); ++$x) { echo "<br />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<count($lide); ++$x) { echo "seznam[".$x."]"=".$x; } Jak je ve zdrojovém kódu pro tlustého klienta zřetelně vidět, vypuštěním setřídění dat a generováním GUI se významně omezila náročnost procesu. Klesá taktéž zátěž serveru a tzv. code-to-content ratio, tedy poměr režijních dat a požadovaných informací. Dosáhneme tak rozhodně vyšších rychlostí odpovědí a celkově živějšího běhu aplikace. Zvláštní úlohou serveru je služba úložiště aplikace. Ačkoliv je velká část aplikační logiky v tomto případě přesunuta na bedra prohlížeče, pořád je při každé inicializaci aplikace stahována ze serveru. Správa celé aplikace je řízena z jednoho centrálního bodu, což má nesporné výhody. 3.4 Rozdělení funkcí mezi server a klienta Po předchozím obecném rozboru se podívejme na konkrétní SCADA/HMI aplikaci. V obecném případě, pro který se snažím navrhnout řešení, musíme předpokládat nejen jednoduché výpisy dat a událostí, ale také vizualizaci složitých výrobních postupů. HMI aplikace má technologické procesy přiblížit člověku operátorovi, který se musí rozhodovat rychle a správně. My mu k tomu musíme poskytnout data v přehledné, snadno čitelné a vyhodnotitelné formě v příslušném zobrazení, nikoliv jen v číselné podobě. Předpokládá se tvorba různých grafů, simulace analogových měřidel, znázornění lineárních hodnot atd. 3.4.1 Tenký versus tlustý klient v HMI aplikaci Představa architektury s tenkým klientem, kde by server pro každý okamžik změny zdrojových dat generoval nové obrazy vizualizačních prvků, které by potom zas a znovu

KAPITOLA 3. KOMUNIKACE KLIENT SERVER 15 odesílal klientovi, vede k domněnce, že tento model je pro použití ve SCADA/HMI aplikacích přinejmenším neefektivní. Naopak tlustý klient, který má sice větší požadavky na vybavení prohlížeče a je tím pádem náročnější na stroj, na němž běží, si při prvním přístupu načte nutné programové vybavení (skripty, aplety... ). Zaplatí sice za svou tloušťku pomalejším startem, ale po něm již od serveru dostává jen čistá data. Vizualizaci číselných dat už provádí sám klient, neroste zátěž serveru ani komunikační sítě. 3.4.2 Návrh řešení Pro HMI aplikaci se přikláním k řešení s tlustým klientem. Na serveru bude uložen www projekt pro vizualizaci dané technologie. Takový projekt bude obsahovat menu, které dovolí operátorovi zvolit danou část technologie nebo zobrazení tabulek, trendů, historie různých dat apod. Dále potom vlastní vizualizaci. Ta se bude skládat z obrázku technologie, do kterého budou umístěny různé vizualizační komponenty fyzických přístrojů (měřidla analogová a digitální, ventily a jejich stav, přepínače a jejich stav, apod.) a přehledových tabulek, ve kterých budou data vhodným způsobem zvýrazněna (podbarvení buňky, sazba různých ikonek). Nedílnou součástí bude speciální komponenta, která bude zabezpečovat spojení se serverem, od kterého bude dostávat holá data, která bude předávat jednotlivým vizualizičním komponentám. Samozřejmostí je i obrácený směr spojení, který zajistí povelování.

16 KAPITOLA 3. KOMUNIKACE KLIENT SERVER

KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT 17 4 Realizace zobrazení dynamických hodnot V této části se pokusím navrhnout možnosti, na jakých principech by mohla být založena výše zmíněná část systému, která zajišťuje komunikaci mezi www stránkou a serverem. Obecně můžeme říci, že se snažím o návrh tzv. RIA (Rich Internet Application), tedy aplikace, která se snaží překlenout rozdíly mezi klasickou webovou a desktopovou aplikací. RIA aplikace se snaží v rámci webového prohlížeče napodobovat desktopové aplikace svým vzhledem i chováním a poskytnout vyšší uživatelský komfort. To vše musí být realizováno s omezeným rozsahem možností běžně rozšířených technologií Internetu. 4.1 Technologie použitelné pro RIA aplikace Současné a dostatečně rozšířené technologie, které se dají použít pro HMI RIA aplikaci, shrnuje následující seznam: AJAX (Asynchronous JavaScript and XML) Macromedia Flash Player Java applety Java aplikace (Java Web Start) ActiveX.NET V následujících odstavcích stručně popíši jednotlivé technologie a jejich vlastnosti; potom se pokusím zhodnotit jejich použití pro HMI aplikaci, jejíž podoba byla načrtnuta výše. 4.1.1 AJAX Zkratka AJAX znamená Asynchronous JavaScript and XML. AJAX není sám o sobě implementací technologie či softwarovým produktem, ale jedná se o obecný koncept nebo lépe návrhový vzor pro RIA. AJAX je představitel cesty využívající maximální možné hodnoty dnešních technologií. AJAX si můžeme představit jako pomyslný deštník, pod kterým se skrývají následující technologie: Document Object Model (DOM), XMLHttpRequest, HTML, CSS a JavaScript. Proti klasickému webovému modelu má AJAX rozdílný koncept využití těchto technologií a to především XMLHttpRequest k volání serveru. Bližší srovnání klasického přístupu oproti AJAXu ilustruje obrázek 4.1. V klasickém webovém modelu každá změna stavu na klientovi vyžaduje obnovení celého uživatelského rozhraní. Nejdříve je tedy žádost o změnu stavu, odeslání požadavku

18 KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT na server, vyřízení požadavku a vše končí zasláním kompletního uživatelského rozhraní s daty, přičemž jednotlivé kroky jsou vzájemně synchronizovány. Naopak AJAX, díky XMLHttpRequest (který je základním stavebním kamenem AJAXu), může vyvolat libovolný počet nezávislých požadavků, jejichž výsledky mohou ovlivnit pouze patřičné části uživatelského rozhraní bez nutnosti jeho celkového znovunačítání. Tedy žádost o změnu stavu, vygenerování požadavku přes XMLHttpRequest, vyřízení požadavku serverem a zpracování vrácené odpovědi XMLHttpRequestem a změna patřičné části uživatelského rozhraní. (Logika obsluhující XMLHttpRequest je na obrázcích znázorněna jako AJAX engine.) Podrobnější popis jak klasického, tak AJAX přístupu ke komunikaci aplikace se serverem ukazuje obrázek 4.1. Obrázek 4.1: Porovnání klasického přístupu pro webovou aplikaci (vlevo) s přístupem AJAXu (vpravo) Nesmíme ale zapomínat, že AJAX je stále pouze nadstavbou nad stávajícími webovými technologiemi, která se snaží překonat některá jejich omezení. A především protokol HTTP vůbec není vhodný pro aplikace spolupracující intenzivně se serverem. Problémem je, že se při každém požadavku musí navázat spojení se serverem, které se po jeho vyřízení ukončí. To aplikaci zpomaluje. Vzhledem k požadavku na firewall-friendly politiku nám ale zejména v internetových aplikacích mnohdy nic jiného nezbývá. U AJAXu také není možné, aby server sám kontaktoval uživatele, když je potřeba (to neumožňuje protokol HTTP). Zkusíme-li na tuto technologii pohlédnout přes síto požadavků uvedených výše, musíme bohužel konstatovat, že striktní požadavek na efektivitu příliš nesplňuje. Základním nedostatkem zůstává stále model požadavek - odpověď, ačkoli jsou tyto operace prováděny na pozadí a reload stránky se neprovádí. Klientská aplikace se musí periodicky dotazovat serveru, nezměnil-li se stav řízené technologie, protože událostní rozesílání není možné. Nicméně jsou transportovány pouze hodnoty signálů, které v porovnání s celými obrázky vizualizací mají velmi malou velikost.

KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT 19 Přes tyto nedostatky je možné toto řešení použít jako součást SCADA/HMI aplikace. Nevýhodou je snadná čitelnost zdrojových kódů a hlavně poměrně malá robustnost JavaScriptové aplikace. Toto řešení by bylo vhodné pro realizaci neoperátorské části systému bez možnosti povelování např. pro veřejnou vizualizaci systému dostupnou z Internetu. Pro toto řešení hovoří zejména použití pouze JavaScriptu, jehož podpora je velmi rozšířená. Obrázek 4.2: Synchronní způsob interakce klasické webové aplikace (nahoře) a asynchronní přístup AJAX aplikace (dole)

20 KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT 4.1.2 Macromedia Flash player Macromedia Flash Player je univerzální klient, který umožňuje běh interaktivních aplikací. Z pohledu RIA můžeme nahlížet na Flash Player jako na klientské běhové prostředí. Macromedia Flash Player měl v počátcích svého vývoje za cíl oživit web vektorovou grafikou a chytře řešenými animacemi. Verze 4 však přinesla zvýšení možností skriptování na straně klienta a také funkci loadvariables, která umožnila dynamicky načítat do běžící animace data ze serveru. Verze 5 zdokonalila komunikační schopnosti: vytvoření XML- Socketu umožnilo vytvoření obousměrného kanálu mezi klientem a serverem. V šesté generaci představila Macromedia Flash Communication Server MX, který je ve spolupráci s klientským flashem schopný v závislosti na událostech v aplikaci synchronizovat data, distribuovat a přijímat multimediální formáty, a dokonce umožňuje i spolupráci jednotlivých klientských aplikací navzájem. V případě Macromedia Flash Playeru jako běhového kontejneru nejsou vývojáři tak těsně svázáni s technologiemi klasického přístupu (HTML, CSS a JavaScript), respektive různorodou úrovní jejich implementace. Díky tomuto a bohatým možnostem co do tvorby uživatelského rozhraní a mocnými možnostmi komunikace klienta se serverem a naopak, se stal Macromedia Flash Player klientem RIA pro komerční framework Macromedia Flex a open source framework OpenLaszlo s komerční podporou firmy Laszlo Systems. Obrázek 4.3: Architektura Flex Architektura frameworků je víceméně stejná. Za pozornost stojí Laszlo Presentation server, respektive Flex server. Flex i OpenLaszlo řeší, na rozdíl od AJAXu, serverovou část. Z hlediska třívrstvé architektury sedí na vrcholku prezentační vrstvy. Serverová část tak může držet stavy jednotlivých klientských komponent, zajišťovat komunikaci v datově efektivním formátu a umožnit napojení aplikační logiky na jednotlivé události uživatelského rozhraní. Oba frameworky podporují integraci přes SOAP a XML-RPC. Popisovaná platforma se jeví pro HMI aplikace takřka ideální. Jedinou nevýhodou se může jevit nutnost existence přehrávače Flash v prohlížečích. Macromedia ale uvádí, že jeho rozšířenost je takřka 98% viz. [2].

KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT 21 Obrázek 4.4: Architektura OpenLaszlo 4.1.3 Java applety Java applet je program napsaný v Javě určený, pro umístění na www server, kde je pomocí speciální značky včleněn do HTML dokumentu tvořícího www stránku. Při návštěvě této stránky Java kompatibilním prohlížečem se applet automaticky nahraje do klientského počítače, kde se spustí. Nespouští se přímo (jako aplikace), nýbrž otevřením HTML dokumentu, kde je na něj umístěn odkaz pomocí speciální značky <applet> či nověji <object>. 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 pokud applet digitálně podepíšeme, lze dosáhnout toho, že applet bude mít větší práva

22 KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT Základní strukturu appletu tvoří třída java.applet.applet, která definuje základní metody tvořící rozhraní mezi prohlížečem a appletem. Program, který má fungovat jako applet, musí být potomkem této třídy. Životní cyklus appletu závisí na prohlížeči, který během své činnosti volá tyto metody appletu: public void init() - při inicializaci, public void start() - při spuštění, public void paint(java.awt.graphics g) - při překreslování, public void stop() - při zastavení, public void destroy() - při ukončení. Tyto metody jsou ve třídě java.applet.applet definovány jako prázdné a pro smysluplnou činnost je třeba v potomkovi překrýt alespoň jednu z nich. Obrázek 4.5 znázorňuje volání metod appletu v závislosti na stavu prohlížeče [30]. Obrázek 4.5: Životní cyklus appletu a volání jeho metod I přes bezpečnostní omezení je Java applet mocnou platformou k realizaci požadovaných funkcí. Java applet má přístup k většině knihoven jazyka Java, a proto může pro komunikaci s nějakou další aplikací používat téměř libovolný protokol. Nejsme tak limitování protokolem HTTP. Pestrou kolekci tříd realizujících komunikaci po síti obsahuje balíček java.net. Realizace komunikační komponenty pro HMI aplikaci pomocí Java appletu je bezesporu přijatelné řešení. Pokud applet digitálně nepodepíšeme, serverová část aplikace obsluhující komunikaci musí běžet na stejném stroji jako www server, ale to není nedostatek. 4.1.4 Java aplikace (Java Web Start) Aplikace Java Web Start je klasická java aplikace. Nemusí mít tedy žádného předka typu Applet a její provoz není závislý na webovém prohlížeči. I když pro činnosti, které vyžadují další práva musí být použito speciální API. Web Start aplikace používají prohlížeč pouze jako prostředek k instalaci. V praxi to probíhá tak, že koncový uživatel klikne na spouštěcí skript Java Web Start (soubor jnlp) a aplikace se sama nainstaluje a spustí. Potom ji můžete spouštět také z prostředí Java Web Start, které vytváří jakousi druhou pracovní plochu s aplikacemi.

KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT 23 Technologie Web Start se vymyká z vymezeného rámce a je uvedena jen pro úplnost. Dále se jí nebudu zabývat. 4.1.5 ActiveX ActiveX je technologie vyvinutá firmou Microsoft a podporována jen v prohlížečích Microsoft Internet Explorer od verze 3.0. To je zásadní nevýhodou této technologie - je omezena jen na jednu platformu a jeden prohlížeč. Základ technologie ActiveX tvoří jednotlivé softwarové komponenty nazývané ActiveX Controls. Ovládací prvky ActiveX jsou spustitelné prvky navrhnuté standardními prostředky (C, C++, Visual Basic, Java atd.) tak, aby se mohly vložit buď do okna, nebo na www stránku, kde budou představovat určitou nezávislou funkci (v našem případě starat se o komunikaci se serverem). ActiveX stavějí na základech COM (Component Object Model). ActiveX Controls jsou opakovatelně použitelné softwarové komponenty založené na stejných základech jako OLE. Ty jsou ovšem primárně určeny pro vzájemnou komunikaci jednotlivých programových objektů mezi aplikacemi. Naproti tomu ActiveX svými vlastnostmi (menší velikost, pružnost) vyhovují pro použití v sítích, ať už jde o Internet, či firemní Intranety. Do HTML se vkládá požadavek, že chcete zvolený ActiveX prvek spustit s danými parametry. Tento zápis se provádí tagem <OBJECT>, za nímž následuje popis prvku a jednotlivé parametry; celý objekt se pak uzavře tagem </OBJECT>. 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 SCA- DA/HMI systému. Omezení pouze na jednu platformu ale odsouvá jejich použití spíše do oblasti Intranetu. 4.1.6.NET.NET je nejnovější technologie firmy Microsoft. Z toho opět plyne omezení na jednu platformu (Windows), ale dlužno podotknout, že se vyvíjejí i portace na jiné systémy (projekt Mono.NET Framework pro Linux, projekt Mano.NET Framework pro PalmOS). Co to ale.net tedy je? Microsoft na svých stránkách [36] uvádí, že Microsoft.NET je sada softwarových technologií, jejichž cílem je propojení světa informací, lidí, systémů a zařízení. Umožňuje nebývalý stupeň integrace software prostřednictvím webových XML

24 KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT Obrázek 4.6: Pohled na.net služeb: malých samostatných aplikací stavebních bloků, které jsou pomocí internetu propojeny mezi sebou a také s většími aplikacemi..net Framework je nová počítačová platforma, která zjednodušuje vývoj aplikací v silně distribuovaném prostředí Internetu. Prakticky to znamená, že každý počítač, na kterém je nainstalován.net Framework, je vybaven soudržným prostředím pro spouštění, zaručujícím určité parametry výkonu, vzhledu a zabezpečení. Detailní popis architektury.net je zcela mimo rozsah této práce, proto jenom stručně. V nejvyšší vrstvě vidíme některé používané.net jazyky používá se jich ale mnohem více. Programy v různých jazycích jsou překládány do CIL (Common Intermediate Language), což je jakýsi mezijazyk obdoba Javovského bytecode. CIL je prováděn CLR (Common Language Runtime), ale není interpretován, ale je použita tzv. Just In Time (JIT) kompilace tj. kompilace až v okamžiku spuštění a jen toho, co je potřeba. Common Type System (CTS) umožňuje kooperaci mezi softwarem napsaným v různých jazycích. Pokud v každém jazyce existuje obdoba každého datového typu, pak je možno data mezi jazyky sdílet. Tím je pak umožněna celková kompatibilita mezi jazyky. Z našeho pohledu je důležitá technologie ASP.NET, která umožňuje tvorbu dynamických webových aplikací za použití všech.net jazyků. Pro realizaci komunikace v distribuovaných systémech nabízí.net dvě podpory (webové služby a.net Remoting). Pro naše účely jsou vhodné obě technologie (popis webových služeb viz. 4.1.6 Webové služby)..net Remoting, který můžeme definovat jako soubor služeb a technik, jež umožňují navázat komunikaci mezi dvěma a více vzdálenými objekty. Přenášení zpráv mezi klientem a serverem je realizováno přes kanály. Kanál je speciální objekt, zpravidla složený z klientské a serverové části. Klientská část kanálu posílá požadavky na služby vzdálenému objektu, případně vrací návratové hodnoty a serverová část kanálu naslouchá na příslušném portu přicházejícím požadavkům. Kanál musí být založen jak na straně volajících, tak na straně vzdálených objektů ještě dříve, než se uskuteční volání..net platforma poskytuje standardně dva druhy kanálů (TCP

KAPITOLA 4. REALIZACE ZOBRAZENÍ DYNAMICKÝCH HODNOT 25 Obrázek 4.7: Architektura.NET Framework a HTTP kanál; třídy TcpChannel a HttpChannel). Mohou být samozřejmě definovány i kanály pracující na jiných protokolech. Názvy těchto kanálů jsou odvozeny od protokolu, na kterém probíhá zasílání zpráv. Kanál HTTP se používá většinou v prostředí Internetu ve spojení s webovým serverem (IIS) a kanál TCP v prostředí Intranetu (kvůli omezení ze strany firewallů). Přenášení kanálem TCP ve spojení s binárním formátovačem je také výkonnější než u kanálu HTTP. Detailnější pohled na kanál si popíšeme na případu klientské části kanálu. U serverové je to totiž přesně naopak. Kanál je vlastně složen z několika částí (sinks). Na vstupu je formátovač, jenž serializuje zprávu na proud bytů. Při formátování se provádí transformace zpráv. Druh transformace (formátovače) odpovídá většinou druhu kanálu (ale nemusí to tak být). Pokud tedy například používáme HTTP kanál, tak implicitní formátovač bude typu SOAP (třída SOAPFormatter). Následně se zpráva předá dalším částem kanálu (zákaznicky definovaným), pokud existují. Zde se může například provést šifrování zprávy apod. Poslední části v kanálu je TransportSink, což je ta část kanálu, která je fyzicky zodpovědná za přenos zprávy mezi aplikačními doménami. Nesmíme zapomenout ani na klasické metody síťové komunikace, které poskytuje i.net ve jmenných prostorech: System.Net, System.Net.Cache, System.Net.Configuration V tomto oboru názvů umístěné třídy zprostředkovávají přístup k řadě sítových protokolů, zejména těch založených na rodině TCP/IP protokolu. Nejčastěji používané jsou třídy System.Net.WebRequest a System.Net.WebResponse umožňující komunikovat s webovými aplikacemi a službami přes protokol HTTP.