Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra kybernetiky. klienta

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra kybernetiky

Bakal´ aˇ rsk´ a pr´ ace V´ yvoj webov´ eho OPC klienta

Plzeˇ n 2012

Jiˇr´ı Faist

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem bakaláˇrskou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 23. kvˇetna 2012 Jiˇr´ı Faist

Abstract The goal of this work is to implement an thin client application that would serve for web clients to communicate and manipulate with OPC Servers. In first chapter there are discussed technologies usable for implementation. There are mentioned various approaches to bidirectional communication in web applications with a focus on WebSocket technology. In the next chapter there are exposed some implementation principles along with their advantages and disadvantages. In final chapters there are shown some performance test results of demanding components of application along with the performance statistics of reading various numbers of items from the REX Control OPC server and briefly described example of use of the application with SVG graphic in web browser. C´ılem práce je implementace aplikace typu tenkého klienta, která umoˇzn´ı webov´ ym klient˚ um komunikaci a manipulaci s OPC Servery. V prvn´ı ˇcásti práce jsou diskutovány technologie, které jsou pouˇzitelné pro v´ yvoj aplikace. Jsou zde také zm´ınˇeny r˚ uzné pˇr´ıstupy k obousmˇerné komunikaci mezi webov´ ymi klienty a servery se zvláˇstn´ım zamˇeˇren´ım na technologii WebSocket. V dalˇs´ı kapitole jsou poodhaleny v´ yznamné principy implementace spoleˇcnˇe s jejich v´ yhodami a nev´ yhodami. V závˇeru práce jsou uvedeny v´ ysledky mˇeˇren´ı v´ ykonu aplikace se zamˇeˇren´ım na jednotlivé nároˇcné komponenty spoleˇcnˇe s v´ ysledky testován´ı ˇcten´ı r˚ uzného poˇctu poloˇzek z OPC Serveru ˇr´ıd´ıc´ıho systému REX. V závˇeru práce je struˇcnˇe popsán pˇr´ıklad pouˇzit´ı aplikace s vyuˇzit´ım SVG grafiky ve webovém prohl´ıˇzeˇci. Key words: opc, opcbridge, webov´ y klient, tenk´ y klient, websocket, rex control

Obsah ´ 1 Uvod

1

2 Pouˇ zit´ e technologie 2.1 Opc Servery a Opc .NET API . . . . . 2.1.1 Standardy OPC . . . . . . . . . 2.1.2 OPC .NET API . . . . . . . . . 2.2 .NET a Reflexe . . . . . . . . . . . . . 2.2.1 .NET Framework . . . . . . . . 2.2.2 Metadata a Reflexe . . . . . . . 2.3 WebSocket . . . . . . . . . . . . . . . . ´ 2.3.1 Uvod do WebSocket technologie 2.3.2 Principy komunikace . . . . . . 2.3.3 WebSocket API . . . . . . . . . 2.4 JSON . . . . . . . . . . . . . . . . . . 2.4.1 Protokol JSON . . . . . . . . . 2.4.2 Pˇr´ıklady JSON formátu . . . .

. . . . . . . . . . . . .

3 Implementace 3.1 Schéma aplikace . . . . . . . . . . . . . . 3.2 Promˇenná workspace . . . . . . . . . . . 3.3 Rozhran´ı aplikace . . . . . . . . . . . . . 3.4 Datov´ y formát JSON a serializace funkc´ı 3.5 Zjednoduˇsené API pro pˇr´ıstup k OPC . . 3.6 Zpˇetné odezvy a chybové hláˇsky . . . . . 4 Testov´ an´ı v´ ykonu aplikace 4.1 Reflexe vs. pˇr´ım´ y pˇr´ıstup 4.2 Pˇrenos dat . . . . . . . . 4.3 Serializace a deserializace 4.4 Celkov´ y v´ ykon aplikace .

. . . . . . . . . . objekt˚ u . . . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

. . . . . .

. . . .

. . . . . . . . . . . . .

2 2 2 3 6 6 6 8 8 10 11 13 13 14

. . . . . .

15 15 16 16 21 24 26

. . . .

27 27 28 28 30

OBSAH

OBSAH

5 Uk´ azka

31

6 Z´ avˇ er

34

4

´ 1 Uvod Základn´ım c´ılem této práce je vytvoˇrit uˇzivatelsky pˇrátelskou aplikaci, která usnadn´ı pˇr´ıstup k dat˚ um na Opc Serverech(viz. 2.1). Vzniklá aplikace by mˇela co nejv´ıce odpov´ıdat charakteristikám aplikace tenkého klienta. Tyto aplikace jsou zpravidla spuˇstˇeny na serveru a klient k nim pˇristupuje pomoc´ı snadno dostupného softwarového prostˇredku, typicky webového prohl´ıˇzeˇce. Tento pˇr´ıstup má mnoho v´ yhod, z nichˇz nejd˚ uleˇzitˇejˇs´ı je, ˇze veˇskerá v´ ypoˇcetn´ı zátˇeˇz je provádˇena na serveru a klient je zat´ıˇzen pouze s´ıt’ovou komunikac´ı. Klient také nen´ı nucen instalovat na svém poˇc´ıtaˇci ˇza´dn´ y dodateˇcn´ y software. Tato aplikace by mohla naj´ıt vyuˇzit´ı zvláˇstˇe pro pˇr´ıstup k dat˚ um ˇr´ıd´ıc´ıho systému REX Controls, kter´ y v sobˇe má základn´ı implementaci Opc Serveru. Opc Servery maj´ı definované API1 (rozhran´ı) v .NET Frameworku, pˇres které se k dat˚ um pˇristupuje. Je tedy nasnadˇe toto rozhran´ı vyuˇz´ıt. Z poˇzadavku na tenkost klienta je dalˇs´ım logick´ ym poˇzadavkem, aby rozhran´ı vytvoˇrené aplikace bylo pˇr´ıstupné z programovac´ıho jazyce JavaScript, kter´ y je hlavn´ım programovac´ım jazykem webov´ ych prohl´ıˇzeˇc˚ u. Aplikace tedy bude m´ıt tvar jakéhosi mostu mezi klientem v JavaScriptu a OPC Serverem, ke kterému bude pˇristupováno z prostˇred´ı .NET Framework. Z této u ´vahy vypl´ yvá druh´ y poˇzadavek na aplikaci a t´ım je vytvoˇrit ji natolik obecnˇe, aby mohla b´ yt v budoucnu snadno pˇrizp˚ usobena pro práci i s jin´ ymi rozhran´ımi neˇz je rozhran´ı OPC Server˚ u. V prvn´ı ˇca´sti práce jsou diskutovány pouˇzité technologie, které jsou v implementovaném ˇreˇsen´ı vyuˇzity. V navazuj´ıc´ıch kapitolách se jiˇz nacházej´ı popis princip˚ u funkce aplikace spoleˇcnˇe s v´ ysledky testován´ı aplikace. Souˇca´st´ı práce je také jednoduchá ukázka s vizualizac´ı v podobˇe vektorové SVG grafiky ve webovém prohl´ıˇzeˇci, po jej´ımˇz prostudován´ı by mˇel b´ yt ˇctenáˇr schopen aplikaci aktivnˇe vyuˇz´ıvat.

1

API - Application Programming Interface

1

2 Pouˇzité technologie 2.1 2.1.1

Opc Servery a Opc .NET API Standardy OPC

OPC je soubor specifikac´ı, které popisuj´ı standardy naplˇ nuj´ıc´ı specifické potˇreby pr˚ umyslu. O udrˇzován´ı tˇechto otevˇren´ ych standard˚ u se stará na1 dace OPC Foundation. Prvn´ı standart OPC Data Access vznikl na základˇe spolupráce mnoha svˇetov´ ych podnik˚ u, zajiˇst’uj´ıc´ıch automatizaci, za pomoci Microsoftu. Tato specifikace je p˚ uvodnˇe postavená na technologi´ıch Micro2 3 softu OLE COM a DCOM . Tyto technologie umoˇzn ˇuj´ı softwarov´ ym komponentám vzájemnou komunikaci a jsou vyuˇz´ıvány v´ yvojáˇri pro vytváˇren´ı znovupouˇziteln´ ych komponent, slinkován´ı komponent dohromady a vyuˇz´ıván´ı v´ yhod Windows servis˚ u[Mic(2012a)]. Specifikace definuje základn´ı set objekt˚ u, rozhran´ı a metod pro pouˇzit´ı pˇri ˇr´ızen´ı proces˚ u a automatizaci tak, aby zajistila vzájemnou kompatibilitu[OPC(2012)]. OPC aplikace jsou implementovány jako dvojice server/klient. OPC server je program, kter´ y konvertuje hardwarov´ y komunikaˇcn´ı protokol pouˇz´ıvan´ y v PLC4 na OPC protokol[Cog(1995-2010)]. OPC klient je program, kter´ y se potˇrebuje pˇripojit k hardwarovému zaˇr´ızen´ı. Pouˇz´ıvá OPC server pro z´ıskán´ı dat ze zaˇr´ızen´ı nebo pro vyslán´ı pˇr´ıkazu do zaˇr´ızen´ı (viz. obr. 2.1). K d˚ uleˇzit´ ym vlastnostem OPC patˇr´ı to, ˇze se jedná o otevˇren´ y standard, z ˇcehoˇz vypl´ yvá, ˇze v´ yrobce hardwaru mus´ı poskytnout jedin´ y OPC server pro svá zaˇr´ızen´ı, aby mohla komunikovat s kter´ ymkoliv klientem. Z opaˇcného pohledu je patrné, ˇze rovnˇeˇz v´ yvojáˇr˚ um aplikac´ı staˇc´ı zanést do svého produktu vlastnosti OPC klienta a t´ım budou kompatibiln´ı s mnoha hardwarov´ ymi zaˇr´ızen´ımi. 1

p˚ uvodnˇe naz´ yvan´ y OPC Specification OLE- Object Linking and Embedding; COM - component object model 3 distributed component object model 4 Programmable Logic Controller - mal´ y pr˚ umyslov´ y poˇc´ıtaˇc kontroluj´ıc´ı jedno ˇci v´ıce hardwarov´ ych zaˇr´ızen´ı 2

2

Pouˇzité technologie

Opc Servery a Opc .NET API

Windows

Hardware

PLC

OPC Server

OPC Client Software

Obrázek 2.1: jednoduché OPC s jedn´ım server/klient pˇripojen´ım

2.1.2

OPC .NET API

OPC .NET(WCF5 )6 je API pro pˇr´ıstup k OPC server˚ um z prostˇred´ı Microsoft .NET Frameworku. OPC .NET 3.0 je v´ ysledkem spolupráce nˇekolika spoleˇcnost´ı, kter´ y poskytuje jednoduché .NET rozhran´ı pro OPC Classic servery. Bylo vyvinuto tak, aby umoˇznilo klientsk´ ym aplikac´ım vyuˇz´ıvat pˇrednosti .NET prostˇred´ı pˇri pˇristupován´ı k existuj´ıc´ım OPC Classic server˚ um [OPC(2012)]. Rozhran´ı OPC .NET 3.0 kombinuje sémantiku základn´ıch OPC specifikac´ı OPC Data Access, OPC Alarms and Events a OPC Historical Data Access 7 . Rozhran´ı také umoˇzn ˇuje automatické znovupˇripojen´ı k serveru, jestliˇze dojde ke ztrátˇe spojen´ı. Tato vlastnost rovnˇeˇz zachovává na serveru povˇedom´ı o klientu, takˇze klient nemus´ı znovu vytváˇret své nastaven´ı na serveru. OPC .NET 3.0 API je navrˇzeno tak, aby klientská aplikace byla oddˇelena od s´ıt’ového rozhran´ı. Klientská aplikace uˇz se nemus´ı vypoˇrádávat s vˇecmi kolem s´ıt’ového pˇripojen´ı jako napˇr´ıklad s v´ ymˇenami poˇzadavk˚ u a odezev(request/response). Tyto u ´kony obstarává zdrojov´ y kód, kter´ y je distribuován s API, a WCF rozhran´ı. OPC .NET je distribuováno se tˇremi generick´ ymi klientsk´ ymi aplikacemi, které byly vytvoˇreny jako model pro v´ yvoj klientsk´ ych aplikac´ı a slouˇz´ı také pro testován´ı novˇe vyvinut´ ych server˚ u pro ovˇeˇren´ı správné funkˇcnosti. Na stranˇe serveru je pˇr´ıtomn´ y generick´ y wrapper pro OPC DA, A&E 5

Windows Communication Foundation - souˇcást .NET Framework urˇcená pro tvorbu servisovˇe orientovan´ ych aplikac´ı 6 dˇr´ıve naz´ yvané OPC Express Interface (Xi) 7 d´ ale pouˇz´ıv´ ano ve zkratk´ ach DA, A&E, HDA

3



nebo HDA servery. Wrapper je rozdˇelen do dvou ˇcást´ı, prvn´ı obstarává WCF rozhran´ı a druhá se stará o mapován´ı mezi OPC .NET a OPC Classic funkcemi (viz. obr.2.2). Zdrojov´ y kód, kter´ y zajiˇst’uje WCF rozhran´ı serveru je oznaˇcen jako báze serveru. Tato ˇca´st definuje stejné chován´ı vˇsech OPC .NET server˚ u a je tedy vˇzdy stejná. Pro vyhledáván´ı pˇr´ıpustn´ ych server˚ u obsahuje OPC .NET Discovery server, kter´ y vytváˇr´ı seznam server˚ u dostupn´ ych pro klientskou aplikaci. K tomu vyuˇz´ıvá technologii Microsoft Peer Name Resolution Protocol (PNRP), která je dostupná na systémech Windows XP a vyˇsˇs´ıch. Klientská API

Rozhraní WCF

Standardní Wrapper

Generický Klient

Klientská báze

Class API Klient

OPC COM Server

Báze Serveru

Class API Adhoc Klient

OPC Wrapper

WCF

alternativní implementace .NET serveru

Adhoc API

Standardní kód klienta

Standardní kód serveru

Specifický kód vývojáře

Obrázek 2.2: OPC .NET klient a server

Funkˇ cn´ı architektura Na obrázku 2.3 jsou pˇribl´ıˇzeny principy funkce vztahu OPC server/klient. Základem jsou jakési pˇr´ıstupové body serveru definované rozhran´ımi Spraˇ vuj(Manage), Cti(Read), Zapiˇs(Write) a Pˇrihlaˇs se k odbˇeru(Subscribe). Kaˇzd´ y klient si vytváˇr´ı vlastn´ı seznamy ze zdroj˚ u v systému. Ty jsou pro vˇsechny klienty stejné na rozd´ıl od vznikl´ ych seznam˚ u, které má kaˇzd´ y klient vlastn´ı. Klient poté tyto seznamy m˚ uˇze pˇriˇradit k pˇr´ıstupov´ ym bod˚ um. Kaˇzd´ y klient m˚ uˇze m´ıt v´ıce pˇr´ıstupov´ ych bod˚ u a ke kaˇzdému pˇr´ıstupovému bodu m˚ uˇze b´ yt pˇriˇrazeno v´ıce seznam˚ u[Neitzel(2009)]. Server tedy disponuje následuj´ıc´ımi rozhran´ımi: • ServerDiscovery - pouˇz´ıvané pro nalezen´ı server˚ u 4



Zdroje v systému stejné pro všechny klienty

Spravuj

filter filter

Klientská aplikace

Runtime data

Historická data

Alarms &Events

Historical Alarms &Events

Čti Zapiš Odebírej Oblast specifická pro každého klienta

Obrázek 2.3: Schéma funkˇcn´ı architektury OPC .NET • ResourceManagement - umoˇzn ˇuje prohledáván´ı zdroj˚ u serveru, vytváˇren´ı seznam˚ u z tˇechto zdroj˚ u, vytváˇren´ı pˇr´ıstupov´ ych bod˚ u a pˇridˇelován´ı seznam˚ u pˇr´ıstupov´ ym bod˚ um • Subscribe pˇr´ıstupové body mohou b´ yt dva typy urˇcené hlavnˇe druhem pouˇzitého protokolu: – Callback - urˇcené pro pˇr´ıstup k dat˚ um v rámci jednoho stroje pˇr´ıpadnˇe m´ıstn´ı s´ıtˇe, protokol TCP – Poll - urˇcené pro pˇr´ıstup z internetu, webov´ ych aplikac´ı atd., protokol HTTP • Read - obsahuje metody pro ˇcten´ı hodnot ze serveru • Write - obsahuje metody pro zmˇenu stavu serveru a pro zápis hodnot na server

5


2.2

.NET a Reflexe

2.2.1

.NET Framework

.NET a Reflexe

.NET Framework8 je technologie vyvinutá spoleˇcnost´ı Microsoft. Podporuje ˇradu programovac´ıch jazyk˚ u a snaˇz´ı se mezi nimi zajistit vzájemnou interoperabilitu. Pˇri kompilaci v .NET se zdrojov´ y kód programu pˇrekládá do Common Intermediate Language(CIL), coˇz je nejniˇzˇs´ı pro ˇclovˇeka ˇciteln´ y programovac´ı jazyk. Do binárn´ıho kódu je program v CIL pˇreloˇzen aˇz za bˇehu. CIL je ukládán do assembly, která je bud’ ve tvaru spustitelného souboru .exe nebo ve tvaru .dll 9 . Kromˇe CIL kódu assembly jeˇstˇe obsahuje sv˚ uj Manifest, Metadata a Reference.

2.2.2

Metadata a Reflexe

Kaˇzdá assembly obsahuje svá Metadata, která jsou tvoˇrena automaticky pˇri pˇrekladu. Metadata popisuj´ı kaˇzd´ y datov´ y typ a ˇclen, kter´ y je v modulu nebo v assembly definován nebo je na nˇej odkazováno a jsou základem pro reflexi v .NET Frameworku. Reflexe v programován´ı je proces, pˇri kterém je dan´ y program schopn´ y za bˇehu sledovat a modifikovat svou vlastn´ı strukturu a chován´ı[Hurlbut(1998)]. V .NET zajiˇst’uje reflexi jmenn´ y prostor System.Reflection, jehoˇz objekty zaobaluj´ı assembly, moduly a datové typy. Tyto objekty mohou b´ yt vyuˇzity k dynamickému vytváˇren´ı instanc´ı objekt˚ u, z´ıskáván´ı informace o typu existuj´ıc´ıho objektu, vyvoláván´ı jeho metod nebo k pˇr´ıstupu k jeho poloˇzkám a vlastnostem[Mic(2012b)]. Jediné co mus´ı uˇzivatel pro pouˇzit´ı reflexe znát je jméno datového typu objektu a informace o assembly, ve které je objekt definován. V .NET reflexe funguje na základˇe parsován´ı v´ yˇse zmiˇ novan´ ych Metadat z assembly.

Pˇri v´ yvoji aplikace se nab´ızeli dva r˚ uzné zp˚ usoby implementace. Prvn´ı moˇznost´ı bylo celé (a nebo znaˇcnou ˇca´st) OPC .NET API pˇr´ımo zpˇr´ıstupnit v klientu JavaScriptu. V JavaScriptu by tedy musel b´ yt obraz kaˇzdého objektu a kaˇzdé metody, které jsou definované v OPC .NET API. Vzhledem 8

framework - podp˚ urn´ y prostˇredek pro programátora obsahuj´ıc´ı v´ yvojové prostˇred´ı, podp˚ urné knihovny atd. 9 Dynamic Link Library

6


.NET a Reflexe

k velikosti API se to ale jev´ı jako znaˇcnˇe nevhodné ˇreˇsen´ı, nebot’ rozhran´ı aplikace v JavaScriptu by muselo b´ yt rozsáhlé a komplikované. Jako druhé ˇreˇsen´ı se nab´ız´ı vytvoˇrit ˇca´st aplikace, která v prostˇred´ı .NET manipuluje s OPC .NET API za vyuˇzit´ı reflexe. Hlavn´ı v´ yhodou tohoto ˇreˇsen´ı je moˇznost velice jednoduˇse vymˇenit API, ke kterému se klient pˇripojuje. Toto ˇreˇsen´ı dokonce umoˇzn ˇuje pˇripojovat se k nˇekolika API nezávisle na sobˇe. JavaScriptová ˇcást nav´ıc mus´ı v základn´ı verzi obsahovat pouze obecné metody pro vytvoˇren´ı objektu, zavolán´ı metody nad objektem a nastaven´ı ˇclenu objektu na urˇcitou hodnotu. Na druhou stranu zde existuj´ı i nev´ yhody. Nejzávaˇznˇejˇs´ı z nich je skuteˇcnost, ˇze pˇreˇcten´ı hodnoty nˇejakého ˇclenu objektu pˇres reflexi nebo vyvolán´ı metody objektu pouˇzit´ım reflexe je mnohem pomalejˇs´ı neˇz pˇri pˇr´ımém pˇr´ıstupu (viz. sekce 4.1). Dalˇs´ı nev´ yhodou jsou vˇetˇs´ı pamˇet’ové nároky, protoˇze do pamˇeti se mus´ı naˇc´ıst mnoˇzstv´ı Metadat o vyuˇz´ıvan´ ych objektech.

7


2.3

WebSocket

WebSocket ´ Uvod do WebSocket technologie

2.3.1

Navrhovanou aplikace si lze pˇredstavit jako most mezi JavaScriptem a OPC Serverem. K OPC Serveru se pˇristupuje pˇres rozhran´ı definované v .NET. Data mezi prostˇred´ımi jazyka JavaScriptu a .NET jsou pˇrenáˇsena pˇres WebSocket server. WebSocket je protokol, kter´ y umoˇzn ˇuje obousmˇernou komunikaci mezi klientsk´ ym skriptem a vzdálen´ ym serverem, kter´ y byl v tomto skriptu zvolen [Ian Fette(2011)]. Klientem jsou ve vˇetˇsinˇe pˇr´ıpad˚ u webové prohl´ıˇzeˇce s podporou HTML5. Základn´ı architektura je nast´ınˇena na obrázku 2.4. Protokol se skládá z otev´ırac´ıho ”handshake”, po kterém zpravidla následuje v´ y10 mˇena informac´ı zaloˇzená na základˇe komunikaˇcn´ıho protokolu TCP . C´ılem této technologie je poskytnout mechanismus pro webové aplikace komunikuj´ıc´ı obousmˇernˇe se servery, kter´ y nebude závisl´ y na otev´ırán´ı velkého poˇctu HTTP pˇripojen´ı.

Trading Gateway

Platební systém

Databáze

Internet Web Service

Messaging Service

ERP/CRM Systémy

atd...

Webové prohlížeče

WebSocket Server

Obrázek 2.4: Základn´ı architektura technologie Websocket

10

Transmission Control Protocol

8


WebSocket

Alternativn´ı metody obousmˇ ern´ e s´ıt’ov´ e komunikace WebSocket by mˇel poskytnout náhradu za doposud pouˇz´ıvané technologie HTTP polling, long-polling a streaming. Vˇsechny tyto metody zahrnuj´ı pos´ılán´ı HTTP poloˇzek (headers), které obsahuj´ı mnoho zbyteˇcn´ ych dat, ˇc´ımˇz docház´ı ke zv´ yˇsen´ı latence nad minimáln´ı u ´roveˇ n. WebSocket je navrˇzen tak, aby mohl zuˇzitkovat existuj´ıc´ı infrastrukturu (proxy servery, ovˇeˇrován´ı, atd.)

polling Pˇri pollingu klient v pravideln´ ych intervalech pos´ılá serveru HTTP poˇzadavky a okamˇzitˇe pˇrij´ımá odpovˇed’. Tato technika je pouˇz´ıvána pro zisk dat z real-time aplikac´ı. Poskytuje dobré ˇreˇsen´ı, pokud je znám´ y interval, po jehoˇz uplynut´ı jsou na serveru poskytována nová data. Bohuˇzel tento interval je ˇcasto nepravideln´ y a nepˇredv´ıdateln´ y. Proto docház´ı k otev´ırán´ı zbyteˇcn´ ych HTTP pˇripojen´ı, obzvláˇstˇe pokud nové informace nejsou dostupné pˇr´ıliˇs ˇcasto.

long-polling Pˇri long-pollingu prohl´ıˇzeˇc pos´ılá serveru poˇzadavek a ten ho nechá otevˇren´ y tak dlouho, neˇz bude m´ıt pro klienta nˇejaká data. Pokud se tak ve zvoleném vymezeném ˇcase nestane, server poˇsle odpovˇed’ pro ukonˇcen´ı pˇripojen´ı. Z principu long-polling vypl´ yvá, ˇze nepˇrináˇs´ı ˇza´dné zlepˇsen´ı v˚ uˇci polling v pˇr´ıpadˇe, ˇze se data na serveru ˇcasto obnovuj´ı.

streaming Dalˇs´ı z moˇzn´ ych pˇr´ıstup˚ u je streaming, pˇri kterém prohl´ıˇzeˇc poˇsle serveru poˇzadavek a server mu jako odpovˇed’ pr˚ ubˇeˇznˇe pos´ılá data. Nemus´ı tedy ˇcekat na vygenerován´ı kompletn´ı odpovˇedi, aby ji mohl poslat najednou. Streaming nesniˇzuje latenci pˇripojen´ı, jeho v´ yhodou ale je, ˇze klient m˚ uˇze na pˇr´ıchoz´ı data reagovat uˇz v pr˚ ubˇehu pˇrij´ımán´ı dat. Streaming je ale stále zaloˇzen´ y na technologii HTTP, coˇz m˚ uˇze zp˚ usobit, ˇze firewally a proxy servery si mohou zvolit, ˇze budou data bufferovat, coˇz zp˚ usob´ı zv´ yˇsen´ı latence doruˇcen´ı zprávy. Nav´ıc server je nucen pouˇz´ıvat nˇekolik r˚ uzn´ ych TCP pˇripojen´ı pro kaˇzdého klienta: jeden pro pos´ılán´ı informac´ı a dalˇs´ı pro kaˇzdou novˇe pˇr´ıchoz´ı zprávu. WebSocket oproti tomu umoˇzn ˇuje pro komunikaci v obou smˇerech vyuˇz´ıt pouze jedno TCP pˇripojen´ı [web(2011)].

9


2.3.2

WebSocket

Principy komunikace

Handshake Term´ın handshake v komunikaˇcn´ıch technologi´ıch oznaˇcuje proces, pˇri kterém mezi u ´ˇcastn´ıky komunikace docház´ı k dohodnut´ı se na hodnotách dynamick´ ych parametr˚ u pˇred vlastn´ım zapoˇcet´ım komunikace. Moˇzná podoba handshake klienta a serveru pro technologii WebSocket je uvedena v Pˇr´ıloze 1. Handshake v protokolu WebSocket má tvar HTTP Upgrade poˇzadavku. D´ıky tomu je tato technologie kompatibiln´ı s HTTP servery a s prostˇredn´ıky na HTTP bázi. Dalˇs´ım d˚ usledkem je moˇznost vyuˇzit´ı jednoho portu pro HTTP i WebSocket klienty. Klient ve svém handshake specifikuje poˇzadovanou adresu URI11 , ke které se chce pˇripojit. Tento zp˚ usob umoˇzn ˇuje, aby z jedné IP adresy mohlo b´ yt obslouˇzeno v´ıce domén a aby v´ıce WebSocket klient˚ u mohlo b´ yt obslouˇzeno jedin´ ym serverem[Ian Fette(2011)]. Pro URI Websocketu jsou definována dvˇe schémata. Pro klasické Websocket pˇripojen´ı má URI prefix ws:// a pro zabezpeˇcenou verzi se pouˇz´ıvá prefix wss://. Kromˇe poˇzadované URI klientsk´ y handshake obsahuje i dalˇs´ı poloˇzky pro upˇresnˇen´ı zp˚ usobu následné komunikace. • Sec-WebSocket-Protocol - urˇcen´ı aplikaˇcn´ıho protokolu, kter´ y znaˇc´ı formát, v jakém budou data pˇrenáˇsena • Sec-WebSocket-Extensions - seznam ˇza´dan´ ych rozˇs´ıˇren´ı protokolu(napˇr. komprese dat atd.) • Origin - poloˇzka slouˇz´ıc´ı k filtrován´ı webov´ ych stránek, ze kter´ ych má b´ yt server pˇr´ıstupn´ y • Sec-WebSocket-Version - verze protokolu Po odeslán´ı svého handshake klient mus´ı poˇckat na odpov´ıdaj´ıc´ı handshake serveru, dˇr´ıve neˇz zaˇcne pos´ılat dalˇs´ı data. Server si z klientova handshake mus´ı vyjmout poloˇzku Sec-WebSocketKey v n´ıˇz se nacház´ı náhodn´ y klientem vybran´ y ˇretˇezec a uprav´ı ho podle stanoven´ ych pravidel. Tak z´ıská ˇretˇezec, kter´ y poté odeˇsle ve svém handshake v poloˇzce Sec-WebSocket-Accept. T´ımto zp˚ usobem si klient ovˇeˇruje, ˇze pˇrijat´ y handshake pocház´ı od j´ım zvoleného serveru. Jakmile klient pˇrijme handshake serveru, mohou si obˇe strany komunikaˇcn´ıho kanálu nezávisle na sobˇe pos´ılat data. 11

Uniform Resource Identifier

10


WebSocket

Data Framing Po u ´spˇeˇsném handshake si mohou klient se serverem vymˇen ˇovat data. Tato data jsou sdruˇzována do celk˚ u oznaˇcovan´ ych jako ”messages”, které jsou dále rozdˇelené do jednotliv´ ych rámc˚ u neboli fram˚ u. V Pˇr´ıloze 2 je zobrazen základn´ı tvar pro jeden rámec. Vysvˇetlen´ı jednotliv´ ych ˇca´st´ı rámce je v Pˇr´ıloze 3. Hlavn´ı v´ yhoda fragmentován´ı zpráv spoˇc´ıvá v tom, ˇze server m˚ uˇze zaˇc´ıt pos´ılat fragmenty zprávy jeˇstˇe pˇred t´ım, neˇz má celou zprávu k dispozici. Pokud by zpráva nebyla fragmentována, odes´ılatel by musel poˇckat aˇz bude m´ıt celou zprávu a spoˇc´ıtat jej´ı velikost dˇr´ıve, neˇz by mohl b´ yt odeslán prvn´ı byte. D´ıky fragmentaci m˚ uˇze server nebo prostˇredn´ık zvolit rozumnou velikost bufferu a jakmile se buffer napln´ı rámec odeslat.

Ukonˇ cen´ı spojen´ı Po u ´spˇeˇsném otev´ırac´ım handshake a pˇrenosu potˇrebn´ ych dat spojen´ı ukonˇcuje uzav´ırac´ı handshake. Kter´ ykoliv z koncov´ ych bod˚ u m˚ uˇze vyvolat uzav´ırac´ı handshake t´ım, ˇze odeˇsle svému protˇejˇsku uzav´ırac´ı rámec, jehoˇz tvar lze odvodit z Pˇr´ılohy 3. Po odeslán´ı tohoto rámce jiˇz nesm´ı pokraˇcovat v odes´ılán´ı ˇzádn´ ych dat a vyˇckává na odezvu také v podobnˇe uzav´ırac´ıho rámce. Po pˇrijet´ı odpovˇedi iniciátor ukonˇcen´ı komunikace ukonˇc´ı spojen´ı.

2.3.3

WebSocket API

HTML5 WebSocket specifikace definuje jednoduché API, které umoˇzn ˇuje webov´ ym stránkám pouˇz´ıt WebSocket protokol pro komunikaci se vzdálen´ ym hostitelem. Kompletn´ı podoba rozhran´ı v sémantice WebIDL12 lze naj´ıt v Pˇr´ıloze 4.

Konstruktor Konstruktor WebSocket(url, protocols) má jeden nebo dva argumenty. Prvn´ı z nich, url, urˇcuje URL adresu, ke které se má WebSocket pˇripojit. Parametr protocols je nepovinn´ y a je typu string nebo pole string˚ u. Tyto ˇretˇezce maj´ı v´ yznam subprotokol˚ u a jsou obsaˇzeny v klientském handshake v poloˇzce Sec-WebSocket-Protocol [Hickson(2012)]. ´ Ukolem konstruktoru je na základˇe pˇredan´ ych parametr˚ u vytvoˇrit nové pˇripojen´ı k serveru a vrátit nov´ y WebSocket objekt. 12

WebIDL - jazyk zamˇeˇren´ y na popis rozhran´ı technologi´ı urˇcen´ ych pro webové prohl´ı-

ˇzeˇce

11


WebSocket

Atribut readyState c´ıch hodnot:

reprezentuje stav spojen´ı a m˚ uˇze nab´ıvat následuj´ı-

• CONNECTING(ˇc´ıselná hodnota 0) - pˇripojen´ı jeˇstˇe nebylo vytvoˇreno • OPEN(ˇc´ıselná hodnota 1) - pˇripojen´ı je vytvoˇreno a pos´ılán´ı dat je moˇzné • CLOSING(ˇc´ıselná hodnota 2) - pˇripojen´ı je ve stavu prob´ıhaj´ıc´ıho closing handshake • CLOSED(ˇc´ıselná hodnota 3) - pˇripojen´ı je uzavˇrené a nebo nemohlo b´ yt otevˇreno

Atribut bufferedAmount Atribut bufferedAmount obsahuje poˇcet byt˚ u, které byly pˇridány do fronty pouˇzit´ım metody send a nebyly jeˇstˇe odeslány.

Metoda send(data) ného pˇripojen´ı.

Tato metoda pos´ılá data prostˇrednictv´ım vytvoˇre-

Metoda close() Tato metoda spouˇst´ı proceduru uzav´ırac´ıho handshake a ukonˇcuje spojen´ı se serverem. Voliteln´ ym parametrem je integer s kódem chyby, která zp˚ usobila ukonˇcen´ı spojen´ı. V následuj´ıc´ı tabulce jsou event handlery13 , které obsahuje WebSocket rozhran´ı. Tyto handlery jsou zpravidla pˇrepisovány uˇzivatelem, kter´ y rozhran´ı vyuˇz´ıvá. Event handler onopen() onmessage() onerror() onclose()

13

událost, pˇri které je handler spuˇstˇen u ´spˇeˇsné vytvoˇren´ı pˇripojen´ı pˇrijet´ı nové zprávy pˇr´ıjet´ı rámce s chybov´ ym hláˇsen´ım pˇrijet´ı uzav´ırac´ıho rámce

metody pro zpracov´ an´ı vznikl´ ych asynchronn´ıch událost´ı

12


2.4

JSON

JSON

V sekci 2.3 je popsána technologie WebSocket vyuˇz´ıvaná pro pˇrenos dat ve tvaru textov´ ych ˇretˇezc˚ u. Ve smˇeru od prohl´ıˇzeˇce tyto ˇretˇezce obsahuj´ı jen jednoduché pˇr´ıkazy pro OPC .NET API. V opaˇcném smˇeru je ale nutné pos´ılat data reprezentuj´ıc´ı v´ ysledky vykonán´ı tˇechto pˇr´ıkaz˚ u. Pro reprezentaci tˇechto dat byl vybrán protokol JSON.

2.4.1

Protokol JSON

JSON (JavaScript Object Notation) je odlehˇcen´ y formát pro v´ ymˇenu ” 14 dat a serializaci objekt˚ u . Je jednoduˇse ˇciteln´ y i zapisovateln´ y ˇclovˇekem a snadno analyzovateln´ y i generovateln´ y strojovˇe“ [jso()]. JSON je vytvoˇren na základech jednoho z moˇzn´ ych zp˚ usobu vytváˇren´ı objekt˚ u v programovac´ım jazyce JavaScript. J e textov´ y formát, kter´ y, pˇrestoˇze vycház´ı z JavaScriptu, je na pouˇzitém jazyce zcela nezávisl´ y.

JSON podporuje dvˇe struktury: • Struktura reprezentuj´ıc´ı objekt. Objekt je brán jako mnoˇzina pár˚ u obsahuj´ıc´ı název ˇclenu objektu a jeho hodnoty. Pˇri deserializaci objekt˚ u v JSON formátu do jin´ ych jazyk˚ u neˇz JavaScriptu se obvykle vyuˇz´ıvaj´ı struktury typu objekt, záznam, struktura, slovn´ık, hash tabulka a dalˇs´ı. • Struktura reprezentuj´ıc´ı pole. Obˇe struktury se vyskytuj´ı v nˇejaké formˇe v podstatˇe ve vˇsech programovac´ıch jazyc´ıch a proto je JSON podporovan´ y vˇetˇsinou programovac´ıch jazyk˚ u a znaˇcnˇe rozˇs´ıˇren´ y. Kromˇe tˇechto struktur se v JSON mohou objevit jeˇstˇe textové ˇretˇezce, ˇc´ıselné hodnoty, hodnoty boolean a hodnota null.

14

serializace objektu - zpracov´ an´ı a uloˇzen´ı instance do perzistentn´ıho uloˇziˇstˇe

13


2.4.2

JSON

Pˇ r´ıklady JSON form´ atu

• Pˇr´ıklad zápisu jednoduchého pole ˇc´ıseln´ ych hodnot [ 10, 5, 98, 20, 30 ] • Pˇr´ıklad zápisu jednoduchého objektu { color: "red", value: "#f00" array: [ 10, 5, 98, 20, 30 ] } • Pˇr´ıklad zápisu pole objekt˚ u [ { color: "red", value: "#f00" }, { color: "green", value: "#0f0" }, { color: "blue", value: "#00f" } ]

14

3 Implementace 3.1

Sch´ ema aplikace

Aplikace funguje jako most propojuj´ıc´ı klienta v JavaScriptu a prostˇred´ı OPC Server˚ u, ke kter´ ym se pˇristupuje prostˇrednictv´ım OPC .NET API. Mezi JavaScriptem a OPC Servery tedy mus´ı existovat meziˇclánek v .NET, kter´ y bude zpracovávat pˇr´ıkazy z JavaScriptu a podle nich manipulovat s rozhran´ım OPC server˚ u. Z podporovan´ ych programovac´ıch jazyk˚ u prostˇred´ı .NET byl vybrán C#, kter´ y byl vytvoˇren spoleˇcnost´ı Microsoft právˇe pro u ´ˇcely .NET Frameworku. Na obrázku 3.1 je nast´ınˇeno základn´ı schéma aplikace. V JavaScriptu je vytvoˇren objekt s urˇcit´ ym rozhran´ım, které dále vyuˇz´ıvá klient z webového prohl´ıˇzeˇce. Hlavn´ım u ´kolem tohoto objektu je pos´ılat zprávy s pˇr´ıkazy prostˇrednictv´ım WebSocket serveru do prostˇred´ı .NET, kde jsou tyto pˇr´ıkazy vykonány. Rozhran´ı v JavaScriptu a v .NET jsou stejná, protoˇze ke kaˇzdému pˇr´ıkazu je v JavaScriptu metoda , která tento pˇr´ıkaz odeˇsle, a v .NET metoda, která tento pˇr´ıkaz vykoná. Pˇr´ıkazy obsahuj´ı pokyny pro manipulaci s OPC .NET API, která prob´ıhá dynamicky na základˇe reflexe (viz. sekce 2.2.2).

Klientská aplikace ve webovém prohlížeči

AddToWorkspace()

AddToWorkspace()

Invoke()

Invoke()

SetValue()

SetValue()

Refresh()

Refresh()

Remove()

Remove()

workspace

workspace .NET (C#)

JavaScript WebSocket Server

Obrázek 3.1: Schéma aplikace.

15

Reflexe

OPC .NET API

Implementace

3.2

Promˇenná workspace

Promˇ enn´ a workspace

Jak jiˇz bylo ˇreˇceno, aplikace má podobu pomyslného mostu mezi klientem v JavaScriptu a OPC .NET API, se kter´ ym manipuluje jak´ ysi meziˇclánek implementovan´ y v jazyce C#. Základem funkce aplikace je promˇenná workspace, která se nacház´ı v JavaScriptové ˇca´sti a v ˇca´sti aplikace implementované v C#(viz. obr.3.1). Na stranˇe JavaScriptu se jedná o datov´ y typ objekt. Objekty v JavaScriptu jsou v podstatˇe mnoˇziny pár˚ u kl´ıˇc|hodnota, kde kl´ıˇce jsou ˇretˇezce a hodnota m˚ uˇze b´ yt jak´ ykoliv datov´ y typ. Na stranˇe C# je tato struktura reprezentována slovn´ıkem Dictionary<string,object> ze jmenného prostoru System.Collections.Generic. Kl´ıˇce v tomto slovn´ıku jsou rovnˇeˇz ˇretˇezce a hodnotami, které odpov´ıdaj´ı kl´ıˇc˚ um, mohou b´ yt libovolné objekty. V promˇenné workspace se uchovávaj´ı veˇskeré uˇzivatelem vytváˇrené objekty. Uˇzivatel v JavaScriptu zavolá metodu pro vytvoˇren´ı objektu, ten se na stranˇe C# vytvoˇr´ı, uloˇz´ı se do promˇenné workspace v C# a zpˇetnˇe se zrcadl´ı do promˇenné workspace na stranˇe JavaScriptu. Nav´ıc se ke kaˇzdému objektu ve workspace v JavaScriptu pˇridává poloˇzka dotnettype, která obsahuje ˇretˇezec s datov´ ym typem, jenˇz odpov´ıdá typu objektu v C#, podle kterého tento obraz vznikl. Tato poloˇzka je zavedena z d˚ uvodu absence typové kontroly v JavaScriptu pˇri volán´ı metod (v´ıce o volán´ı metod pozdˇeji v sekci 3.4). Zrcadlen´ı objekt˚ u prob´ıhá v´ ymˇennou dat ve formátu JSON(viz. 2.4) pˇres WebSocket server(viz. 2.3).

3.3

Rozhran´ı aplikace

Pˇri návrhu aplikace bylo c´ılem vytvoˇrit co nejjednoduˇsˇs´ı rozhran´ı, které umoˇzn´ı snadno vytváˇret objekty a vyvolávat jejich metody. Velmi obecné ˇreˇsen´ı vyuˇz´ıvaj´ıc´ı reflexi(viz. 2.2) na stranˇe C# umoˇzn ˇuje, aby základn´ı rozhran´ı objektu v JavaScriptu mˇelo pouze 5 metod. Témˇeˇr kaˇzdá metoda rozhran´ı aplikace v JavaScriptu má jako prvn´ı argument poloˇzku callback, která oznaˇcuje název funkce v JavaScriptu, která bude vyvolána po vyplnˇen´ı p˚ uvodn´ı funkce. Toto opatˇren´ı je nutné, protoˇze JavaScript je pouze jednovláknov´ y jazyk. To znamená, ˇze pokud by se v pr˚ ubˇehu skriptu muselo ˇcekat na dokonˇcen´ı nˇejaké ˇcasovˇe nároˇcné operace, vyˇradilo by to vˇsechny komponenty webové stránky, které jsou na JavaScriptu závislé. Z tohoto d˚ uvodu mus´ı vˇsechny ˇcasovˇe nároˇcné operace prob´ıhat asynchronnˇe. V naˇsem pˇr´ıpadˇe je asynchronn´ı pˇr´ıstup obzvláˇstˇe nutn´ y 16

Implementace


pˇri vytváˇren´ı objektu a následném volán´ı metody tohoto objektu, která mus´ı b´ yt spuˇstˇena aˇz po u ´spˇeˇsném zrcadlen´ı nového objektu do JavaScriptu, tedy v callbacku. Aplikace podporuje vytváˇren´ı objekt˚ u jednoduch´ ych datov´ ych typ˚ u ve funkc´ıch primárnˇe urˇcen´ ych pro jiné u ´ˇcely, neˇz je vytváˇren´ı objekt˚ u. Napˇr´ıklad pokud v parametru vyvolávané metody bude ˇretˇezec ”int:5”, vytvoˇr´ı se doˇcasn´ y objekt typu System.Int32 s hodnotou 5 a tento objekt se pˇredá vyvolávané metodˇe jako parametr. Tato vlastnost je vˇzdy uvedena v popisu parametr˚ u dané funkce. Dalˇs´ı vlastnost, kterou rozhran´ı má, je moˇznost potlaˇcen´ı serializace funkc´ı (v´ıce o serializaci funkc´ı v sekci 3.4). Serializace je ˇcasovˇe nároˇcná operace a t´ımto zp˚ usobem je moˇzné ji ˇcásteˇcnˇe urychlit. Napˇr´ıklad nen´ı potˇreba serializovat metody u ˇcten´ ych dat ze serveru, jejichˇz metody nehodláme pouˇz´ıt. Serializace metod se potlaˇc´ı tak, ˇze v daném ˇretˇezci pˇredávaném metodˇe bude prvn´ı znak roven ’*’. Napˇr´ıklad chceme-li nov´ y objekt uloˇzit pod jménem ”dummy” a chceme-li potlaˇcit serializaci funkc´ı u tohoto objektu, pˇredáme metodˇe parametr s hodnotou ”*dummy”. U parametr˚ u, kter´ ych se tato vlastnost t´ yká je to vˇzdy uvedeno dále v popisu rozhran´ı.

Z´ akladn´ı rozhran´ı aplikace v JavaScriptu: Tyto metody vys´ılaj´ı prostˇrednictv´ım WebSocket serveru poˇzadavky na vyvolán´ı stejnojmenné metody v meziˇclánku aplikace implementované v C#. • AddToWorkpace(callback, itemName, itemType) – Pˇridává nov´ y objekt do workspace zavolán´ım vhodného konstruktoru, vyb´ıraného podle dan´ ych vstupn´ıch parametr˚ u. Pˇri chybném zvolen´ı parametr˚ u metoda vyvolá v´ yjimku s popisem moˇzn´ ych kombinac´ı parametr˚ u. – Popis parametr˚ u: ∗ callback - jméno funkce, která bude spuˇstˇena po u ´spˇeˇsném vytvoˇren´ı objektu. ∗ itemName - Jméno, pod kter´ ym bude objekt uloˇzen v promˇenné workspace. M˚ uˇze obsahovat poˇzadavek na potlaˇcen´ı serializace metod. ∗ itemType - Jméno datového typu objektu. M˚ uˇze obsahovat deklaraci jednoduch´ ych datov´ ych typ˚ u. Také m˚ uˇze obsahovat deklaraci generick´ ych datov´ ych typ˚ u (napˇr.: ”System.Collections.Generic.Dictionary<string,int>”) 17

Implementace


∗ Metodu je moˇzné volat s promˇenliv´ ym poˇctem parametr˚ u. Vˇsechny dalˇs´ı parametry jsou povaˇzovány za jména parametr˚ u ve workspace, se kter´ ymi má b´ yt volán konstruktor. – Pˇr´ıklad volán´ı: opcClient.AddToWorkspace("connectRexServer", serverName, "Opc.Da.Server", "Factory", "URL"); – Pˇr´ıklad protokolu dat pˇrenáˇsen´ ych pˇres WebSocket server: "connectRexServer_|_AddToWorkspace~rexServer; Opc.Da.Server;Factory,URL" • Invoke(callback, itemName, methodName, saveResultName, argsArray) – Vyvolává zvolenou metodu nad vybran´ ym objektem s poˇzadovan´ ymi argumenty. Pokud se uˇzivatel pokouˇs´ı vyvolat metodu se ˇspatn´ ymi argumenty, metoda vyvolá v´ yjimku s informacemi o moˇzn´ ych zp˚ usobech volán´ı dané metody. – Popis parametr˚ u: ∗ callback - jméno funkce, která bude spuˇstˇena po u ´spˇeˇsném vyvolán´ı metody a které bude pˇredán obraz návratové hodnoty vyvolané metody. ∗ itemName - Jméno objektu ve workspace, nad kter´ ym se bude vyvolávat metoda. ∗ methodName - Jméno metody, která má b´ yt vyvolána. ∗ saveResultName - Jméno, pod jak´ ym se do workspace uloˇz´ı návratová hodnota metody. M˚ uˇze obsahovat poˇzadavek na potlaˇcen´ı serializace metod. ∗ argsArray - pole jmen parametr˚ u, které maj´ı b´ yt metodˇe pˇredány. M˚ uˇze obsahovat deklaraci jednoduch´ ych datov´ ych typ˚ u. – Pˇr´ıklad volán´ı: opcClient.Invoke("callbackFce","rexServer","Connect", null,["ConnectData"]); – Pˇr´ıklad protokolu dat pˇrenáˇsen´ ych pˇres WebSocket server: "callbackFce_|_Invoke~rexServer;Connect; null;ConnectData" • SetValue(callback, itemName, valueName) – Metoda nastavuje objekt ve wokrspace na urˇcenou hodnotu. 18

Implementace


– Popis parametr˚ u: ∗ callback - Jméno metody, která bude vyvolána po u ´spˇeˇsném nastaven´ı objektu na poˇzadovanou hodnotu. ∗ itemName - Jméno objektu, jehoˇz hodnota má b´ yt pˇrenastavována. ∗ valueName - Jméno objektu ve workspace, jehoˇz hodnota se pouˇzije pro nastaven´ı objektu. M˚ uˇze obsahovat deklaraci jednoduch´ ych datov´ ych typ˚ u. – Pˇr´ıklad volán´ı: opcClient.SetValue(null, "URL.Scheme", "string:opcda"); – Pˇr´ıklad protokolu dat pˇrenáˇsen´ ych pˇres WebSocket server: "null_|_SetValue~URL.Scheme;string:opcda" • Refresh(callback, itemName, boolWithFunctions) – Aktualizuje objekt ve workspace v JavaScriptu. Aktualizace je nutná, pokud se hodnoty ˇclen˚ u objektu mˇen´ı po vytvoˇren´ı objektu jin´ ym zp˚ usobem neˇz prostˇrednictv´ım metody SetValue(). Dalˇs´ım moˇzn´ ym vyuˇzit´ım je dodateˇcná serializace metod, pokud jsme pˇri vytvoˇren´ı objektu tuto moˇznost potlaˇcili. – Popis parametr˚ u: ∗ callback - Jméno funkce, která bude spuˇstˇena po u ´spˇeˇsné aktualizaci objektu. ∗ itemName - Jméno objektu, kter´ y má b´ yt aktualizován. ∗ boolWithFunctions - Hodnota typu boolean urˇcuj´ıc´ı, zda se má objekt aktualizovat vˇcetnˇe funkc´ı. To m˚ uˇze b´ yt nutné, pokud objekt s dan´ ym jménem pˇrep´ıˇseme ve workspace jin´ ym objektem. – Pˇr´ıklad volán´ı: opcClient.Refresh(null,"group.ReadResults",false); – Pˇr´ıklad protokolu dat pˇrenáˇsen´ ych pˇres WebSocket server: "null_|_Refresh~group.ReadResults;false" • Remove(callback, itemName) – Odstraˇ nuje objekty z promˇenné workspace. 19

Implementace


– Popis parametr˚ u: ∗ callback - Jméno funkce, která bude spuˇstˇena po odstranˇen´ı daného objektu. ∗ itemName - Jméno objektu, kter´ y má b´ yt odstranˇen. – Pˇr´ıklad volán´ı: opcClient.Remove(null, "URL"); – Pˇr´ıklad protokolu dat pˇrenáˇsen´ ych pˇres WebSocket server: "null_|_Remove~URL"

Specifick´ e metody rozhran´ı: Tyto metody jsou specifické pro JavaScriptovou ˇca´st aplikace a nemaj´ı svého protˇejˇska v meziˇclánku implementovaném v C#. • Connect(host) – Metoda pro pˇripojen´ı objektu v JavaScriptu k WebSocket serveru. – Popis parametr˚ u: ∗ host - URI adresa serveru, ke kterému se má objekt pˇripojit • OnConnectedToWS() – Metoda, která je spuˇstˇena po u ´spˇeˇsném pˇripojen´ı k WebSocket serveru. Pˇredpokládá se, ˇze klient tuto metodu pˇrep´ıˇse sv´ ym kódem. • ConnectToREX(callback, serverName) – Metoda speciálnˇe urˇcená pro pˇripojen´ı k OPC serveru v ˇr´ıd´ıc´ım systému REX. Vyuˇz´ıvá k tomu v´ yˇse zm´ınˇené metody pro vytváˇren´ı objekt˚ u, nastaven´ı hodnoty a volán´ı funkce. – Popis parametr˚ u: ∗ callback - Jméno funkce, která bude spuˇstˇena po pˇripojen´ı OPC .NET API k OPC serveru ˇr´ıd´ıc´ıho systému REX. ∗ serverName - Jméno, pod kter´ ym bude server uloˇzen ve wokspace. • getItem(name) – Metoda pro z´ıskán´ı poloˇzky z promˇenné workspace. 20

Implementace

Datový formát JSON a serializace funkc´ı

– Popis parametr˚ u: ∗ name - jméno poloˇzky nebo ˇretˇezec obsahuj´ıc´ı cestu k poloˇzce ve workspace • getWorkspace() – Metoda, která vrac´ı promˇennou workspace. • SubscriptionCallback(itemsArray) – Metoda, která slouˇz´ı pro zpracován´ı asynchronnˇe ˇcten´ ych dat objektem OpcSimpleIO (viz. sekce 3.5). Pˇredpokládá se, ˇze uˇzivatel pˇrep´ıˇse metodu sv´ ym kódem. – Popis parametr˚ u: ∗ itemsArray - pole, které obsahuje asynchronnˇe ˇctená data

3.4

Datov´ y form´ at JSON a serializace funkc´ı

Rozhran´ı definované v sekci 3.3 je dostateˇcné pro základn´ı komunikaci s libovoln´ ym rozhran´ım v .NET. Na druhou stranu nen´ı pˇr´ıliˇs uˇzivatelsky pˇra´telské, nebot’ uˇzivatel mus´ı rozhran´ı v .NET znát do té m´ıry, aby vˇedˇel jaká metoda se volá s jak´ ymi parametry. Pro vyˇreˇsen´ı tohoto problému byl rozˇs´ıˇren datov´ y formát JSON tak, aby kromˇe textov´ ych ˇretˇezc˚ u, ˇc´ıseln´ ych hodnot, boolean hodnot a hodnoty null umoˇzn ˇoval nav´ıc pouˇzit´ı funkc´ı jako hodnoty v páru kl´ıˇc:hodnota (v´ıce o JSON v sekci 2.4). Rozˇs´ıˇren´ı JSON formátu umoˇzn ˇuje zrcadlen´ı objektu ze C# do JavaScriptu vˇcetnˇe vlastn´ıch veˇrejn´ ych metod . Samozˇrejmˇe tyto obrazy metod neprovád´ı stejné u ´kony, ale pouze ve svém nitru volaj´ı metodu Invoke() s pˇr´ısluˇsn´ ymi parametry. Tento zp˚ usob nav´ıc umoˇzn ˇuje provádˇet typovou kontrolu parametr˚ u uˇz v JavaScriptu pˇred zavolán´ım metody Invoke() a t´ım zabraˇ nuje nadbyteˇcné s´ıt’ové komunikaci, která by nastala v pˇr´ıpadˇe, kdy by se uˇzivatel pokouˇsel zavolat metodu s nesprávn´ ymi parametry pˇr´ımo prostˇrednictv´ım metody Invoke() a o chybném zvolen´ı parametr˚ u by se poté dozvˇedˇel aˇz po vyvolán´ı v´ yjimky v C# a jej´ı propagaci do JavaScriptu. Serializace funkc´ı umoˇzn ˇuje aby uˇzivatel pˇristupoval k zvolenému API v .NET pomoc´ı obraz˚ u funkc´ı samotného API a manipulovat tak s n´ım v JavaScriptu témˇeˇr stejnˇe, jako by sn´ım manipuloval v prostˇred´ı .NET.

21

Implementace


Pˇ r´ıklady serializace metod Hlaviˇ cky metod v C#: public void bar(double d, object obj); public double foo(int i); public int foo(double d, string str);

Obrazy funkc´ı v JavaScriptu: Obraz ukázkového objektu je ve workspace uloˇzen pod jménem ”dummy”. U pˇret´ıˇzen´ ych metod se nejprve kontroluje poˇcet parametr˚ u obsaˇzen´ ych v poli opcB_argsArray. Poté se kontroluj´ı datové typy jednotliv´ ych parametr˚ u. Parametry mohou b´ yt bud’ null, nebo to mohou b´ yt ˇretˇezce obsahuj´ıc´ı deklaraci nového objektu jednoduchého datového typu (napˇr.: ”int:5 ”), nebo je parametrem jméno objektu, pod kter´ ym je uloˇzen ve workspace. V tom pˇr´ıpadˇe se objekt vyhledá ve wokspace a zkontroluje se jeho ˇclen .dotnetType. V´ yjimku tvoˇr´ı pˇr´ıpad, kdy má b´ yt poˇzadovan´ y argument typu object. V tom pˇr´ıpadˇe m˚ uˇze b´ yt parametrem hodnota null nebo libovolná deklarace jednoduchého typu a nebo jméno libovolného objektu, kter´ y je definovan´ y ve workspace. Pokud jsou vˇsechny parametry u ´spˇeˇsnˇe zkontrolovány, je zavolána funkce Invoke(). Pokud se typová kontrola nevydaˇr´ı, dojde k vyvolán´ı v´ yjimky.

Obraz metody bar() function (js_callback, d, obj) { if (d === null || d.split(’:’)[0] === "double" || opcClient.getItem(d).dotnetType === "double") { if (obj === null || obj.split(’:’).length === 2 || opcClient.getItem(obj) !== ’undefined’) { opcClient.Invoke(js_callback, "dummy", "bar", "null", [d, obj]); return; } } throw "There is no ’bar’ method callable with given arguments!"; }

22

Implementace


Obraz pˇ ret´ıˇ zen´ e metody foo() function (js_callback, opcB_saveResultName, opcB_argsArray) { if (opcB_argsArray.length === 1) { if (opcB_argsArray[0] === null || opcB_argsArray[0].split(’:’)[0] === "int" || opcClient.getItem(opcB_argsArray[0]).dotnetType === "int") { opcClient.Invoke(js_callback, "dummy", "foo", opcB_saveResultName, opcB_argsArray); return; } } if (opcB_argsArray.length === 2) { if (opcB_argsArray[0] === null || opcB_argsArray[0].split(’:’)[0] === "double" || opcClient.getItem(opcB_argsArray[0]).dotnetType === "double") { if (opcB_argsArray[1] === null || opcB_argsArray[1].split(’:’)[0] === "string" || opcClient.getItem(opcB_argsArray[1]).dotnetType === "string") { opcClient.Invoke(js_callback, "dummy", "foo", opcB_saveResultName, opcB_argsArray); return; } } } throw "There is no ’foo’ method callable with given arguments!"; }

23

Implementace

3.5

Zjednoduˇsené API pro pˇr´ıstup k OPC

Zjednoduˇ sen´ e API pro pˇ r´ıstup k OPC

D´ıky serializaci funkc´ı nemus´ı uˇzivatel pouˇz´ıvat metodu Invoke() ze základn´ıho rozhran´ı aplikace, ale m˚ uˇze volat poˇzadované metody v C# prostˇrednictv´ım jejich obraz˚ u v JavaScriptu. M˚ uˇze tak vyuˇz´ıvat API, ke kterému se aplikace pˇripojuje, v jeho p˚ uvodn´ı podobˇe. Dalˇs´ı moˇznost´ı, která se uˇzivateli nab´ız´ı, je vytvoˇrit si v C# objekt, kter´ y bude poˇzadované API libovolnˇe zaobalovat a nadále se z JavaScriptu pˇripojovat pˇr´ımo k tomuto objektu. T´ımto zp˚ usobem si uˇzivatel m˚ uˇze rozhran´ı, se kter´ ym bude nadále pracovat, libovolnˇe pˇrizp˚ usobovat podle sv´ ych vlastn´ıch poˇzadavk˚ u. Pro pˇr´ıstup k OPC DataAccess Serveru (jehoˇz implementaci obsahuje ˇr´ıd´ıc´ı systém REX) byl vytvoˇren jednoduch´ y objekt, kter´ y si klade za c´ıl ulehˇcovat základn´ı operace zápis a ˇcten´ı dat vˇcetnˇe asynchronn´ıho ˇcten´ı.

Zjednoduˇ sen´ e rozhran´ı - objekt OpcSimpleIO • OpcSimpleIO(Opc.Da.Server server ) – Konstruktor objektu. – parametr server - pˇripojen´ y server typu Opc DA. Pro vytvoˇren´ı Opc serveru systému REX staˇc´ı zavolat metodu ConnectToREX() z rozhran´ı aplikace v JavaScriptu . • Add R Item(string itemName) – Metoda pˇridává poloˇzku pro ˇcten´ı. – parametr itemName - jméno poloˇzky, která má b´ yt pˇridána • Remove R Item(string itemName) – Metoda odeb´ırá poloˇzku pro ˇcten´ı. – parametr itemName - jméno poloˇzky, která má b´ yt odebrána • Add W Item(string itemName, object value) – Metoda pˇridává poloˇzku pro zápis. – parametry: ∗ itemName - jméno poloˇzky, která má b´ yt pˇridána ∗ value - hodnota, která má b´ yt zapsána na server 24

Implementace

Zjednoduˇsené API pro pˇr´ıstup k OPC

• Remove W Item(string itemName) – Metoda odeb´ırá poloˇzku pro zápis. – parametr itemName - jméno poloˇzky, která má b´ yt odebrána • Read() – Metoda pˇreˇcte poloˇzky pˇridané metodou Add R Item(). • Write() – Metoda zapisuje poloˇzky pˇridané metodou Add W Item(). • ChangeState(string propertyName, object value) – Metoda mˇen´ı hodnoty podm´ınek pro asynchronn´ı ˇcten´ı. – parametry: ∗ propertyName - jméno vlastnosti, jej´ıˇz hodnota má b´ yt zmˇenˇena Nˇekteré moˇzné hodnoty: · Active - aktivace asynchronn´ıho ˇcten´ı · UpdateRate - perioda obnovován´ı dat · KeepAlive - pr˚ ubˇeˇzná aktualizace hodnot pro udrˇzen´ı spojen´ı · Deadband - urˇcuje pásmo necitlivosti na zmˇeny dat · SamplingRate - frekvence ˇcten´ı dat ∗ value - hodnota, kterou má daná vlastnost nab´ yvat • SwitchSubscriptionState() – Metoda aktivuje nebo deaktivuje asynchronn´ı ˇcten´ı.

25

Implementace

3.6

Zpˇetné odezvy a chybové hláˇsky

Zpˇ etn´ e odezvy a chybov´ e hl´ aˇ sky

Aplikace je navrˇzena tak, aby jak´ ykoliv poˇzadavek z JavaScriptové strany vˇzdy vyvolal odpovˇed’ nebo chybovou hláˇsku na stranˇe C#, která je poté poslána zpˇet. Z d˚ uvodu snadného rozliˇsen´ı odezev bylo kaˇzdé pˇridˇeleno identifikaˇcn´ı ˇc´ıslo, které se pˇridává ke zprávˇe s odezvou.

Identifikaˇ cn´ı ˇ c´ısla odezev: 100x 1001 1002 1003 1004 1005 1006

Mnoˇzina odezev potvrzuj´ıc´ıch korektn´ı pr˚ ubˇeh operac´ı u ´spˇeˇsnˇe pˇridán nov´ y objekt do promˇenné workspace u ´spˇeˇsné nastaven´ı objektu na poˇzadovanou hodnotu u ´spˇeˇsné vyvolán´ı metody u ´spˇeˇsné odebrán´ı objektu z workspace asynchronn´ı upozornˇen´ı na zmˇenu hodnoty prvku OPC serveru u ´spˇeˇsné obnoven´ı objektu

200x 2001 2002 2003 2004 2005 2006

Mnoˇzina bˇeˇzn´ ych chyb neznám´ y pˇr´ıkaz neoˇcekávaná v´ yjimka pokus o pˇr´ıstup k objetu, kter´ y nen´ı ve workspace definovan´ y datov´ y typ objektu nemohl b´ yt identifikován chybná deklarace generického datového typu chybná deklarace jednoduchého datového typu

300x 3001 3002

Chyby vzniklé pˇri vytváˇren´ı nového objektu chybn´ y tvar odeslaného poˇzadavku snaha o zavolán´ı neexistuj´ıc´ıho konstruktoru

400x 4001 4002 4003

Chyby vzniklé pˇri nastavován´ı objektu na danou hodnotu chybn´ y tvar odeslaného poˇzadavku snaha o nastaven´ı objektu na neexistuj´ıc´ı objekt pokus o nastaven´ı objektu na hodnotu jiného datového typu

500x 5001 5002 5003

Chyby vzniklé pˇri vyvoláván´ı metod chybn´ y tvar odeslaného poˇzadavku volán´ı neexistuj´ıc´ı metody volán´ı metody se ˇspatn´ ymi parametry

26

4 Testován´ı výkonu aplikace 4.1

Reflexe vs. pˇ r´ım´ y pˇ r´ıstup

Reflexe mus´ı b´ yt z principu své funkce (viz. sekce 2.2.2) znatelnˇe pomalejˇs´ı neˇz pˇr´ım´ y pˇr´ıstup. Otázkou je ale o kolik je pomalejˇs´ı a do jaké m´ıry to ovlivˇ nuje v´ ykon aplikace. V tabulce 4.1 jsou v´ ysledky testován´ı rychlosti volán´ı metody. Testovac´ı metoda neprovádˇela ˇza´dné operace, jen vracela sv˚ uj argument, kter´ ym byl integer. Metoda byla volána 106 -krát. Z v´ ysledk˚ u je patrné ˇze samotné vyvolán´ı metody reflex´ı je pˇribliˇznˇe 100-krát pomalejˇs´ı, pˇr´ımé zavolán´ı. V tabulkách 4.2 a 4.3 jsou v´ ysledky porovnáván´ı reflexivn´ıho a pˇr´ımého pˇr´ıstupu pˇri volán´ı metod pouˇz´ıvan´ ych pro zisk dat z OPC Serveru. Pˇri prvn´ım mˇeˇren´ı byla volána metoda Add_R_Item(string name) pro pˇridán´ı prvku do skupiny pro ˇctená data, v druhém pˇr´ıpadˇe byla zvolena metoda Read(), která vyˇc´ıtá data ze serveru. Metoda Read() byla vˇzdy spouˇstˇena 1000-krát s r˚ uzn´ ymi poˇcty ˇcten´ ych prvk˚ u. Metoda Add_R_Item() byla spuˇstˇena tolikrát, kolik prvk˚ u bylo pˇridáváno. V ˇcástech tabulek Pˇr´ır˚ ustek je v procentech vyˇc´ısleno o kolik je pr˚ ubˇeh metody vˇcetnˇe zavolán´ı delˇs´ı pˇri pouˇzit´ı metody Invoke() vyuˇz´ıvaj´ıc´ı reflexi neˇz pˇri pˇr´ımém zavolán´ı. Metoda Invoke() je vˇzdy o nˇeco pomalejˇs´ı, ale maximáln´ı namˇeˇren´ y rozd´ıl o hodnotˇe nav´ yˇsen´ı rovné 32% nen´ı nijak závaˇzn´ y. Toto zpoˇzdˇen´ı nav´ıc nen´ı zp˚ usobeno pouze reflex´ı, nebot’ metoda Invoke() provád´ı i dalˇs´ı operace jako napˇr´ıklad manipulaci s promˇennou workspace nebo zisk hodnoty parametr˚ u z ˇretˇezc˚ u obsahuj´ıc´ıch deklaraci jednoduch´ ych datov´ ych typ˚ u a dalˇs´ı. Ze z´ıskan´ ych v´ ysledk˚ u se dá vyvodit, ˇze opoˇzdˇen´ı pˇri zavolán´ı metody reflex´ı je takˇrka zanedbatelné. Pr˚ ubˇeh a rychlost metod daleko v´ıce závis´ı na operac´ıch, které metoda provád´ı, neˇz na zp˚ usobu zavolán´ı metody. doba trván´ı [s] Reflexe Pˇr´ımé volán´ı 1.5109 0.0184 Tabulka 4.1: V´ ysledky testován´ı rychlosti reflexe.

27

Testován´ı výkonu aplikace

Pˇrenos dat

doba trván´ı [s] Poˇcet pˇridan´ ych prvk˚ u Reflexe Pˇr´ımé volán´ı Pˇr´ır˚ ustek [%] 10 0.148 0.121 22 50 0.598 0.493 21 100 1.196 0.911 31 500 5.848 4.401 32 1000 11.159 8.848 26 Tabulka 4.2: V´ ysledky testován´ı rychlosti volán´ı metody Add_R_Item(). doba trván´ı [s] Poˇcet ˇcten´ ych prvk˚ u Reflexe Pˇr´ımé volán´ı Pˇr´ır˚ ustek [%] 10 0.411 0.347 18 50 1.109 1.079 3 100 1.942 1.939 <1 500 8.156 7.615 7 1000 17.185 15.106 14 Tabulka 4.3: V´ ysledky testován´ı rychlosti volán´ı metody Read().

4.2

Pˇ renos dat

Dalˇs´ım faktorem, kter´ y ovlivˇ nuje v´ ykonnost aplikace je pˇrenos dat pˇres WebSocket server (viz. sekce 2.3). Objem dat pˇrenáˇsen´ ych z prohl´ıˇzeˇce na server je velmi mal´ y, nebot’ obsahuje jen pˇr´ıkazy, které se maj´ı na serveru vykonat. Naopak ˇretˇezce obsahuj´ıc´ı serializované objekty, které jsou pos´ılány ze serveru prohl´ıˇzeˇci, mohou b´ yt velice rozsáhlé. Rychlost pˇrenosu byla testována po lokáln´ı s´ıti. V reáln´ ych podm´ınkách bude samozˇrejmˇe v´ ykonnost záviset na rychlosti pˇripojen´ı. Testována byla rychlost pˇrenáˇsen´ı serializovan´ ych objekt˚ u pro r˚ uzné poˇcty objekt˚ u. Pˇrenos dat byl provádˇen 1000-krát. V´ ysledky jsou zanesené v tabulce 4.4.

4.3

Serializace a deserializace objekt˚ u

Dalˇs´ı ˇcasovˇe nároˇcnou operac´ı v bˇehu aplikace je nutnost serializace objekt˚ u do formátu JSON v C# a následná deserializace v JavaScriptu. Pˇri 28


Serializace a deserializace objekt˚ u

Poˇcet pˇrenáˇsen´ ych prvk˚ u doba trván´ı [s] 10 0.259 50 1.359 100 3.275 500 25.741 1000 80.838 Tabulka 4.4: V´ ysledky testován´ı rychlosti pˇrenáˇsen´ı dat ze serveru. testován´ı byla serializace i deserializace provedena 1000krát. Pro serializaci nemohla b´ yt vyuˇzita ˇzádná knihovn´ı funkce jazyka C#, protoˇze aplikace vyuˇz´ıvá specificky upraven´ y formát JSON rozˇs´ıˇren´ y o funkce (viz. sekce 3.4). Proto byl implementován vlastn´ı objekt pro serializaci, kter´ y vyuˇz´ıvá reflexi. Pro deserializaci je vyuˇz´ıvána funkce eval(), která je pˇrirozenou souˇca´st´ı JavaScriptu. Pouˇz´ıván´ı této funkce nen´ı obecnˇe pˇr´ıliˇs doporuˇcováno, protoˇze sebou nese jistá bezpeˇcnostn´ı rizika. V naˇsem pˇr´ıpadˇe je ale tato funkce pouˇz´ıvána jen pro zpracován´ı ˇretˇezc˚ u z vlastn´ıho serveru, takˇze k ˇza´dnému ohroˇzen´ı doj´ıt nem˚ uˇze. Nemohli b´ yt vyuˇzity ˇza´dné moduly pro JavaScript, které zajiˇst’uj´ı zpracován´ı JSON formátu kv˚ uli obsahu funkc´ı, coˇz tyto moduly nepodporuj´ı. V´ ysledky mˇeˇren´ı lze nalézt v tabulce 4.5. doba trván´ı [s] Poˇcet prvk˚ u Serializace Deserializace 10 0.662 0.160 50 3.392 0.834 100 7.499 1.585 500 33.191 8.054 1000 71.897 17.566 Tabulka 4.5: V´ ysledky testován´ı rychlosti serializace a deserializace objekt˚ u

29


4.4

Celkový výkon aplikace

Celkov´ y v´ ykon aplikace

Lze pˇredpokládat, ˇze aplikace najde nejvˇetˇs´ı vyuˇzit´ı pˇri vyˇc´ıtán´ı dat z OPC Serveru. Z toho d˚ uvodu byl celkov´ y v´ ykon aplikace testován na metodˇe Read(). Ze serveru byla 1000-krát ˇctena skupina dat a mˇeˇrena byla doba od prvn´ıho odeslán´ı poˇzadavku na ˇcten´ı dat z JavaScriptu aˇz po posledn´ı pˇr´ıjem dat. Testován´ı bylo provedeno po lokáln´ı s´ıti. V´ ysledky jsou v tabulce 4.6. V ˇca´sti frekvence ˇcten´ı je pˇribliˇzná hodnota v herz´ıch, která odpov´ıdá frekvenci s jakou je aplikace schopna ˇc´ıst dané mnoˇzstv´ı prvk˚ u. Pro dosaˇzen´ı lepˇs´ıch v´ ysledk˚ u je moˇzné vyuˇz´ıt asynchronn´ı ˇcten´ı (viz. sekce 3.5), kde odpadá neustálé pos´ılán´ı pˇr´ıkaz˚ u z JavaScriptu a následné volán´ı metody pro ˇcten´ı. Poˇcet ˇcten´ ych prvk˚ u doba trván´ı [s] Frekvence ˇcten´ı [Hz ] 10 1.893 528 50 6.149 162 100 11.939 83 500 68.992 14 1000 167.257 6 Tabulka 4.6: V´ ysledky testován´ı rychlosti ˇcten´ı dat z OPC serveru.

30

5 Ukázka Pro ukázku funkce aplikace byla vytvoˇrena jednoduchá SVG grafika (viz. obr. 5.1) ve webovém prohl´ıˇzeˇci v podobˇe hodin, která je ˇr´ızena daty pˇrij´ıman´ ymi prostˇrednictv´ım vytvoˇrené aplikace z ˇr´ıd´ıc´ıho systému REX Control. Schéma zapojen´ı algoritmu v systému REX lze nalézt v Pˇr´ıloze 5. Algoritmus prob´ıhá s periodou 1s.

Popis v´ yznamn´ ych ˇ c´ ast´ı k´ odu webov´ e str´ anky:

Inicializace pˇ ripojen´ı - V prvn´ım kroku, kter´ y je nutné provést pˇred pˇripojen´ım k OPC Serveru, se pˇrekr´ yvá metoda OnConnectedToWS(), která se vykoná po u ´spˇeˇsném pˇripojen´ı k WebSocket serveru, a vytvoˇr´ı se pˇripojen´ı. Dalˇs´ım krokem je vytvoˇren´ı pˇripojen´ı k OPC serveru systému REX metodou ConnectToREX(). Po u ´spˇeˇsném pˇripojen´ı se vyvolá metoda addGroup(), ve které se vytváˇr´ı objekt OpcSimpleIO konstruktorem, kter´ y pˇrij´ımá OPC server jako sv˚ uj argument. opcClient.Connect("ws://localhost:8181/"); opcClient.OnConnectedToWS = function () { opcClient.ConnectToREX("opcClient.addGroup", "rexServer"); } opcClient.addGroup = function () { opcClient.AddToWorkspace("opcClient.initIO", "group", "OPCBridge.OpcSimpleIO", "rexServer"); }

Inicializace ˇ cten´ı a z´ apisu dat - Pouˇzit´ım metod Add_R_Item(), respektive Add_W_Item(), se inicializuje ˇcten´ı, respektive zápis, poloˇzek na server. Zapisuj´ı se data, která odpov´ıdaj´ı aktuáln´ımu ˇcasu. opcClient.initIO = function () { var date = new Date(); var group = opcClient.getItem("group"); group.Add_R_Item(null, "string:rex_clock.Seconds.y"); 31

Ukázka

group.Add_R_Item(null, "string:rex_clock.Minutes.y"); group.Add_R_Item(null, "string:rex_clock.Hours.y"); group.Add_W_Item(null, "string:rex_clock.InitSeconds.ycn", "int:" + (date.getSeconds() + 1)); group.Add_W_Item(null, "string:rex_clock.InitMinutes.ycn", "int:" + date.getMinutes()); group.Add_W_Item(null, "string:rex_clock.InitHours.ycn", "int:" + date.getHours()); group.Write("opcClient.WaitForInitRex", null); } ˇ Cten´ ı dat ze serveru - Ze serveru jsou pˇreˇctena data a následnˇe ve funkci StartClock() jsou podle nich nastaveny hodiny v SVG grafice. Je aktivováno asynchronn´ı ˇcten´ı dat metodou SwitchSubscriptionState(). opcClient.InitClock = function () { var group = opcClient.getItem("group"); group.SwitchSubscriptionState(null); group.Read("opcClient.StartClock", null); }

Spuˇ stˇ en´ı algoritmu a asynchronn´ı pˇ r´ıjem dat - Po u ´spˇeˇsném nastaven´ı hodin v SVG grafice je do skupiny dat pro zápis pˇridána poloˇzka rex_clock.Start.YCN a je na ni zapsána hodnota true, ˇc´ımˇz se spust´ı algoritmus v systému REX. Zmˇenami hodnot v systému REX docház´ı ke generován´ı asynchronn´ıch událost´ı, které o tom informuj´ı uˇzivatele v JavaScriptu. Uˇzivatel na tyto události reaguje pˇrekryt´ım metody SubscriptionCallback(). V naˇsem pˇr´ıpadˇe se v této metodˇe manipuluje s ruˇciˇckami hodin. opcClient.StartClock = function (itemsArray) { ... group.Add_W_Item(null, "string:rex_clock.Start.YCN", "bool:true"); group.Write(null, null); } opcClient.SubscriptionCallback = function (itemsArray) { ... }

32

Ukázka

11

12

1 2

10

3

9 8

4 7

6

5

Obrázek 5.1: Pˇr´ıklad jednoduché vektorové SVG grafiky.

33

6 Závˇer V souˇcasné dobˇe je velk´ ym trendem vytváˇret aplikace v podobˇe tenk´ ych klient˚ u, protoˇze to pˇrináˇs´ı ˇradu v´ yhod. Implementovaná aplikace také vznikla v tomto duchu a d´ıky tomu jediné, co klient na svém poˇc´ıtaˇci potˇrebuje v pˇr´ıpadˇe, ˇze je aplikace spuˇstˇena na serveru, je internetov´ y prohl´ıˇzeˇc. V´ ysledky testován´ı v´ ykonnosti aplikace z kapitoly 4 jsou pro porovnán´ı zaneseny do grafu 6.1. Je patrné, ˇze aplikace je nejv´ıce limitována serializac´ı prvk˚ u v programovac´ım jazyce C#. To by mohlo b´ yt problematické pˇri ˇcten´ı velkého poˇctu dat s poˇzadavkem na vysokou frekvenci ˇcten´ı. Pˇri dalˇs´ım v´ yvoji aplikace by tedy bylo vhodné implementovat serializaci efektivnˇejˇs´ım zp˚ usobem neˇz jak´ y je pouˇzit v aktuáln´ı verzi nebo aktuáln´ı ˇreˇsen´ı patˇriˇcnˇe optimalizovat. Nároˇcná serializace je jistˇe nejvˇetˇs´ı nev´ yhodou zvoleného zp˚ usobu implementace. Pro dosaˇzen´ı vyˇsˇs´ıho v´ ykonu je moˇzné potlaˇcit serializaci metod pro objekty, jejichˇz metody uˇzivatel nehodlá pouˇz´ıvat. Dalˇs´ı moˇznost´ı je pro vyvoláván´ı metod pˇr´ımo vyuˇz´ıvat metodu Invoke(), která nen´ı na serializaci metod závislá. T´ım se ale uˇzivatel pˇriprav´ı o typovou kontrolu argument˚ u v JavaScriptu. K pˇrednostem aplikace jistˇe patˇr´ı nezávislost na pouˇzitém API, ke kterému se aplikace pˇripojuje. Pro jeho zmˇenu nebo pˇridán´ı nového API staˇc´ı odpov´ıdaj´ıc´ım zp˚ usobem upravit dané pole s informacemi o assemblies1 , ze kter´ ych má aplikace zpracovávat Metadata a vytváˇret podle nich objekty. D´ıky tomu m˚ uˇze b´ yt aplikace v budoucnu pouˇzita s novˇejˇs´ımi verzemi OPC .NET API nebo pracovat s nˇekolika r˚ uzn´ ymi API zároveˇ n. Dalˇs´ı v´ yhodou je moˇznost si poˇzadované API libovolnˇe zaobalit do objektu v .NET a pro práci s API nadále pouˇz´ıvat rozhran´ı tohoto objektu prostˇrednictv´ım obraz˚ u jeho metod v JavaScriptu. Aplikace umoˇzn ˇuje pˇripojen´ı libovolného mnoˇzstv´ı klient˚ u zároveˇ n, pˇriˇcemˇz kaˇzd´ y z nich má k dispozici vlastn´ı promˇennou workspace. Z vlastnost´ı OPC .NET API dále vypl´ yvá, ˇze kaˇzd´ y z tˇechto klient˚ u se m˚ uˇze pˇripojit na libovolné mnoˇzstv´ı OPC Server˚ u. Funkˇcnost aplikace byla ovˇeˇrena na OPC Serveru ˇr´ıd´ıc´ıho systému REX a na Matrikon OPC Simulation Serveru. Práce by dle mého názoru mˇela splˇ novat poˇzadavky, které na ni byly kladeny. Aplikace by se nyn´ı mˇela dostat do stavu d˚ ukladného testován´ı v praxi, coˇz pravdˇepodobnˇe povede k dalˇs´ım optimalizaˇcn´ım zásah˚ um. Pˇri v´ yvoji byla vyuˇzita základn´ı implementace WebSocket serveru, kterou mi poskytl m˚ uj vedouc´ı práce Ing. Miroslav Kocánek. 1

string[] _assembliesFullNames

34

Závˇer

90 80 70

Čtení prvků Serializace Deserializace Přenos dat

čas [ t ]

60 50 40 30 20 10 0 1 10

2

10 Počet prvků

10

3

Obrázek 6.1: Porovnán´ı v´ ykonu jednotliv´ ych souˇca´st´ı aplikace

35

Literatura ´ [jso()] Uvod do JSON. Dostupné z: http://www.json.org/json-cz.html. [web(2011)] WebSocket.org, 2011. org/.

Dostupné z: http://www.websocket.

[Cog(1995-2010)] What is OPC? Cogent Real-Time Systems Inc., 1995-2010. Dostupné z: http://www.opcdatahub.com/WhatIsOPC.html#note1. [Hickson(2012)] HICKSON, I. May 2012. W3C, 2012. websockets/.

The WebSocket API - Editor´s Draft 2 Dostupné z: http://dev.w3.org/html5/

[Hurlbut(1998)] HURLBUT, M. A Tutorial on Behavioral Reflection and its Implementation, 1998. Dostupné z: http: //www2.parc.com/csl/groups/sda/projects/reflection96/docs/ malenfant/ref96/ref96.html. [Ian Fette(2011)] IAN FETTE, A. M. The WebSocket Protocol. Google Inc., Isode Ltd., 2011. Dostupné z: http://tools.ietf.org/html/rfc6455. [Mic(2012a)] COM:Component Object Model Technologies. Microsoft, 2012a. Dostupné z: http://www.microsoft.com/com/default.mspx. [Mic(2012b)] Reflection (C# Programming Guide). Microsoft, 2012b. Dostupné z: http://msdn.microsoft.com/en-us/library/ms173183% 28v=vs.80%29.aspx. [Neitzel(2009)] NEITZEL, L. EXPRESS interface - Technical Overview, 2009. Dostupné z: http://www.slideshare.net/JimCahill/ express-interface-xi-technical-overview. [OPC(2012)] OPC Foundation - The Interoperability Standart for Industrial Automation & Related Domains. OPC Foundation, 2012. Dostupné z: http://www.opcfoundation.org/. 36

Pˇ r´ıloha

37

ˇ ILOHA ´ PR

ˇ ILOHA ´ PR

Handshake klienta: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Handshake pocházej´ıc´ı ze strany serveru: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat Pˇr´ıloha 1: Pˇr´ıklad handshake klienta a serveru technologie WebSocket. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+ Pˇr´ıloha 2: Podoba jednoho rámce protokolu WebSocket. 38

ˇ ILOHA ´ PR

ˇ ILOHA ´ PR

Pˇr´ıloha 3: Legenda k jednotliv´ ym ˇ c´ astem r´ amce. FIN: 1 bit • Tento bit znaˇc´ı zda se jedná o posledn´ı rámec zprávy. RSV1, RSV2, RSV3: kaˇzd´ y 1 bit • Tyto bity mus´ı b´ yt nastaveny na hodnotu 0, pokud pˇri handshake nedoˇslo k dojednán´ı nˇejak´ ych rozˇs´ıˇren´ı protokolu. Opcode: 4 bity • Popisuje druh a tvar dat, pˇrenáˇsen´ ych rámcem. Definované jsou následuj´ıc´ı moˇzná nastaven´ı: – %x0 - navazuj´ıc´ı rámec – %x1 - textov´ y rámec – %x2 - binárn´ı rámec – %x3-7 - hodnoty rezervované pro budouc´ı nekontroln´ı rámce – %x8 - poˇzadavek na uzavˇren´ı pˇripojen´ı – %x9 - ping – %xA - pong – %xB-F - hodnoty rezervované pro budouc´ı kontroln´ı rámce Mask: 1 bit • Popisuje zda jsou pˇrenáˇsená data maskována. Pˇri nastaven´ı na hodnotu 1 mus´ı v ˇcásti rámce Masking-key b´ yt pˇr´ıtomen kl´ıˇc pro odmaskován´ı dat. Maskována jsou data, pos´ılaná klientem. Payload length: 7 bit˚ u, 7+16 bit˚ u nebo 7+64 bit˚ u

39

ˇ ILOHA ´ PR

ˇ ILOHA ´ PR

• Sekvence bit˚ u, obsahuj´ıc´ı velikost pˇrenáˇsen´ ych dat. Pokud tato hodnota je v intervalu [0,125], pak odpov´ıdá délce pˇrenáˇsen´ ych dat. Pokud je ale tato hodnota 126, následuj´ıc´ı 2 byty obsahuj´ı 16 bitov´ y unsigned integer, jehoˇz hodnota odpov´ıdá délce pˇrenáˇsen´ ych dat. Pokud je tato hodnota dokonce 127, poté se na dalˇs´ıch 8 bytech nacház´ı 64 bitov´ y unsigned integer, jehoˇz hodnota odpov´ıdá délce pˇrenáˇsen´ ych dat. Masking-key: 0 nebo 4 byty • Vˇsechny rámce pos´ılané klientem serveru jsou maskované 32 bitovou hodnotou, která je souˇca´st´ı rámce. Tuto poloˇzku rámec obsahuje pouze tehdy, je-li poloˇzka rámce Mask nastavena na hodnotu 1. • Maskovac´ı kl´ıˇc je 32-bitová hodnota náhodnˇe zvolená klientem. Klient mus´ı vˇzdy pˇri pˇr´ıpravˇe nového rámce vytvoˇrit nov´ y kl´ıˇc, kter´ y mus´ı b´ yt nepˇredv´ıdateln´ y. Payload data • V posledn´ı ˇca´sti rámce se nacházej´ı samotná data, která maj´ı b´ yt pˇrenesena. Tato data vzniknou spojen´ım libovoln´ ych aplikaˇcn´ıch dat spolu s daty rozˇs´ıˇren´ı protokolu, pokud toto rozˇs´ıˇren´ı bylo domluveno v otev´ırac´ım handshake.

40

ˇ ILOHA ´ PR

ˇ ILOHA ´ PR

[Constructor(DOMString url, optional DOMString protocols), Constructor(DOMString url, optional DOMString[] protocols)] interface WebSocket : EventTarget { readonly attribute DOMString url; // ready state const unsigned short CONNECTING = 0; const unsigned short OPEN = 1; const unsigned short CLOSING = 2; const unsigned short CLOSED = 3; readonly attribute unsigned short readyState; readonly attribute unsigned long bufferedAmount; // networking [TreatNonCallableAsNull] attribute Function? onopen; [TreatNonCallableAsNull] attribute Function? onerror; [TreatNonCallableAsNull] attribute Function? onclose; readonly attribute DOMString extensions; readonly attribute DOMString protocol; void close([Clamp] optional unsigned short code, optional DOMString reason); // messaging [TreatNonCallableAsNull] attribute Function? onmessage; attribute DOMString binaryType; void send(DOMString data); void send(ArrayBuffer data); void send(Blob data); }; Pˇr´ıloha 4: WebSocket rozhran´ı

41

ˇ ILOHA ´ PR

ˇ ILOHA ´ PR

0 CNR_1 u1 u2 y SW SSW_2

1 CNR_4

off

0 InitSeconds

Start

u1 y u2 Seconds

uc uo OR1 y OR2 OR3 OR4 SWU_1

u1 y u2 SW SSW_1

u1 Y u2 REL_1

60 CNR_8

0 CNR_3 0 CNR_5

0 InitMinutes

u1 y u2 SW SSW_3


1 CNR_6

u1 y u2 Minutes u1 y u2 SW SSW_4

u1 y u2 SW SSW_5 0 InitHours


u1 Y u2 REL_2

0 CNR_2

60 CNR_7

0 CNR_9 1 CNR_10

u1 y u2 Hours

u1 y u2 SW SSW_6

u1 Y u2 REL_3

12 CNR_11

0 CNR_12

Pˇr´ıloha 5: Schéma zapojen´ı ukázkového pˇr´ıkladu v systému REX Control.

42

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra kybernetiky. klienta

Recommend Documents