Cuprins

CAPITOLUL 1 INTRODUCERE ....................................................................................... 2 1.1 STRUCTURA DOCUMENTULUI ............................................................................................ 3 CAPITOLUL 2 ASPECTE TEHNOLOGICE ................................................................... 4 2.1 PLATFORMA MOZILLA ....................................................................................................... 4 2.1.1 Arhitectura platformei Mozilla.................................................................................. 4 2.1.2 NSPR ......................................................................................................................... 6 2.1.3 XPCOM ..................................................................................................................... 6 2.2 JAVASCRIPT ...................................................................................................................... 8 2.3 DHTML............................................................................................................................ 8 CAPITOLUL 3 PREZENTAREA APLICAIEI ............................................................ 10 3.1 DIAGRAMA CAZURILOR DE UTILIZARE............................................................................. 10 3.2 ARHITECTURA SISTEMULUI DE MONITORIZARE I CONTROL ............................................ 12 3.3 COMUNICAREA CU ECHIPAMENTELE................................................................................ 13 3.4 MONITORIZAREA VIDEO .................................................................................................. 15 3.5 APLICAIA CLIENT........................................................................................................... 16 3.6 CONTROLUL BENZII ......................................................................................................... 20 CAPITOLUL 4 IMPLEMENTARE.................................................................................. 24 4.1 TEHNOLOGII FOLOSITE .................................................................................................... 24 4.2 COMPONENTA ESSHANDLER .......................................................................................... 25 4.3 COMPONENTA LIVEVIDEO .............................................................................................. 28 4.4 COMPONENTA REPLAYVIDEO ......................................................................................... 30 4.5 COMPONENTA CONTROLSERVICE ................................................................................... 31 4.6 INTERFAA GRAFIC ....................................................................................................... 31 CAPITOLUL 5 TESTAREA PERFORMANELOR..................................................... 33 CAPITOLUL 6 CONCLUZII ............................................................................................ 37 BIBLIOGRAFIE .................................................................................................................... 38

Universitatea Petru Maior 2006

Cuprins

Universitatea Petru Maior 2006

Capitolul 1 Introducere

Capitolul 1 Introducere
World Wide Web-ul s-a schimbat dramatic n ultima decad, astfel ceea ce era n trecut un sistem rudimentar pentru distribuia coninutului static s-a transformat ntr-o platforma pentru aplicaii cu un grad ridicat de complexitate. La ora actual exist o cerere tot mai mare pentru aa numitele Cldiri inteligente, cldiri care ncorporeaz sisteme de monitorizare i control, care s fie accesate, dac este posibil, i de la distan. Aplicaia prezentat n continuare utilizeaz tehnologii Web pentru a rspunde la aceast cerere. Pornind iniial ca un studiu privind posibilitatea utilizrii unor tehnologiilor Web ntr-un domeniu nou, diferit de situaiile clasice n case se aplic, s-a concretizat n final ntr-o aplicaie complet funcional care prin modalitatea de abordare a problemei i prin soluiile oferite poate fi foarte competitiv n mediul concurenial existent pe piaa de software. Aplicaia realizat nu reprezint dect interfaa pentru utilizator a unui sistem de monitorizare i control al cldirilor mult mai complex cu un numr mare de elemente componente. Interfaa este total independent de restul sistemului, dup cum este ilustrat n Figura 1.1, din aceast arhitectur rezultnd o libertate foarte mare n alegerea tehnologiilor de implementare. Cerinele pentru ea au fost portabilitatea pe principalele sisteme de operare utilizate n momentul de faa adic Windows, Linux i MacOS, o interfaa grafic particularizabil, utilizabil ntr-un mod intuitiv fr necesitatea unei perioade de pregtire pentru utilizator i nu n ultimul rnd posibilitatea afirii n timp real a mai multor fluxuri video. Ultima cerina enumerat a reprezentat cea mai mare provocare, mai ales n contextul tehnologiilor Web utilizate pentru implementare.

Figura 1.1 Soluie complet pentru monitorizarea i controlul cldirilor

Universitatea Petru Maior 2006

Capitolul 1 Introducere

1.1 Structura documentului

Primul capitol prezint cteva noiuni introductive referitoare la problema dat, scopurile urmrite i setul de cerine. Capitolul 2 descrie sumar principalele tehnologii folosite pentru implementarea aplicaiei. Fundaia acesteia o reprezint platforma Mozilla a crei arhitectur este prezentat pe scurt. Urmeaz apoi o introducere n NSPR, API-ul pe care este construit ntreaga platform, cel care-i asigur portabilitatea, XPCOM sistemul de administrare al componentelor, cel care confer modularitate i JavaScript limbajul care anim interfeele grafice ale aplicaiilor i furnizeaz legtura acestora cu nivelurile inferioare ale platformei. n finalul capitolului sunt cteva remarci despre DHTML tehnica de implementare a interfeei grafice. Capitolul 3 ncepe cu diagrama cazurilor de utilizare, cea care descrie viziunea utilizatorului asupra aplicaiei, continu cu o prezentare a arhitecturii ntregului sistem, apoi prezint structura aplicaiei client, cu cele patru componente ale sale i a interfeele prin care acestea comunic. Finalul capitolului este dedicat mecanismului de control al benzii pentru partea de monitorizare video. Capitolul 4 este dedicat implementrii i abordeaz pe rnd fiecare component prezentnd clasele, funcionalitatea ncapsulat de fiecare, relaiile dintre ele i tehnicile de programare folosite. Capitolul 5 prezint i interpreteaz rezultatele testelor de performan fcute pentru a demonstra eficacitatea mecanismului de control al benzii propus. Capitolul 6, final, conine cteva concluzii.

Universitatea Petru Maior 2006

Capitolul 2 Aspecte tehnologice

Capitolul 2 Aspecte tehnologice

2.1 Platforma Mozilla

Mozilla este o platform portabil, gratuit, open-source creat pentru a facilita dezvoltarea rapid a aplicaiilor vizuale cu un grad ridicat de interactivitate. Ea ofer fundaia pe care programatorii pot s dezvolte uor aplicaii de nivel nalt fr a mai irosi timp preios implementnd funcionaliti de baz, oferite acum de platform. Cele patru tehnologii de baz nglobate n platform sunt: XUL (un dialect al limbajului XML utilizat pentru descrierea interfeelor grafice), JavaScript (un limbaj pentru script-uri cu o sintax asemntoare cu cea a limbajului C), RDF (un dialect al XML utilizat pentru salvarea datelor) i XPCOM (un sistem pentru descoperirea i administrarea obiectelor).

2.1.1 Arhitectura platformei Mozilla

Pentru a rspunde nevoilor ct mai multor programatori platforma Mozilla a fost organizat pe mai multe niveluri semi-independente dup cum se poate vedea din Figura 2.1. Nivelurile inferioare reprezint interfaa dintre platform i sistemul de operare accesul la serviciile oferite de acesta fcndu-se n trei moduri: printr-un API (Application Programming Interface) portabil numit NSPR (Netscape Portable Runtime), prin cod Java interpretat de JVM (Java Virtual Machine) sau prin implementarea unor plugin-uri. Pentru o flexibilitate i o deschidere mai mare a sistemului funcionalitatea nivelurilor inferioare este nglobat n mai multe componente independente, administrarea lor fiind realizat de un sistem de mediere foarte portabil numit XPCOM (Cross Platform Component Object Model). Portabilitatea tehnologiilor folosite n aceste niveluri inferioare conduce la o portabilitate crescut a ntregii platforme i implicit a tuturor aplicaiilor dezvoltate pe ea. n momentul de fa Mozilla este disponibil pe principalele trei sisteme de operare existente pe pia: Microsoft Windows, Linux i Mac OS. Nivelurile superioare ofer servicii de securitate prin utilizarea certificatelor digitale i portabilitate prin descrierea interfeelor componentelor ntr-un limbaj independent de platform numit XPIDL (Cross Platform Interface Definition Language, o variant a limbajului IDL utilizat de sistemul de administrare a obiectelor CORBA). Tehnologia XPConnect asigur accesul limbajelor pentru script-uri (cum este JavaScript) la interfeele componentelor de la nivelurile inferioare acestea fiind identificare printr-un identificator unic

Universitatea Petru Maior 2006

Capitolul 2 Aspecte tehnologice

de tipul UUID (Universally Unique Identifier, un numr pe 128 de bii), sau printr-un identificator specific platformei numit ContractID, care se salveaz n format text ntr-o form uor de reinut pentru utilizatori. Legtura funcioneaz i n sens invers permind interaciunea unor obiecte implementate n JavaScript cu alte obiecte implementate de obicei n limbaje de programare clasice cum ar fi C sau C++.

Figura 2.1 Arhitectura platformei Mozilla Platforma pune la dispoziia programatorilor un format portabil pentru salvarea datelor numit RDF care este o particularizare a limbajului XML. Interfaa cu utilizatorul este implementat sub forma unor documente scrise n XUL (limbajul derivat din XML specific platformei) sau mult mai cunoscutul limbaj HTML. Universitatea Petru Maior 2006

Capitolul 2 Aspecte tehnologice

2.1.2 NSPR
Fundaia platformei Mozilla, cea care i confer mare parte din puterea sa i care i asigur portabilitatea, este un API-ul numit NSPR (Netscape Portable Runtime). Acesta ofer o serie de faciliti specifice sistemelor de operare cum ar fi: administrarea proceselor: funcii pentru lansarea sau oprirea din execuie a proceselor. fire de execuie: NSPR implementeaz un sistem de administrare i planificare al firelor de execuie independent de cel al sistemului de operare reuind emularea acestora chiar i pe sisteme de operare care nu le suport nativ; planificarea firelor se face dup un sistem propriu de prioriti; ofer posibilitatea crerii unor fire de execuie native pe sistemele de operare care permit acest lucru. servicii de sincronizare: asigur posibilitatea sincronizrii firelor de execuie prin obiecte de tip mutex sau monitor. operaii de intrare/ieire: permite att operaii la nivel de fiier ct i operaii la nivel de SOCKET. operaii atomice: implementeaz mecanisme care pot conferi un caracter atomic, indivizibil, unor operaii. msurarea intervalelor: exist faciliti pentru msurarea precis a intervalelor de timp. administrarea memoriei: implementeaz propriul mecanism portabil pentru alocarea i dealocarea memoriei. comunicare ntre procese: ofer mecanisme pentru comunicarea ntre procese, un exemplu fiind memoria partajata. Utilizarea exclusiv a facilitilor oferite de NSPR, coroborat cu respectarea regulilor de accesare a acestora, asigur o portabilitate total, pe cele trei sisteme de operare suportate, oricrei aplicaii care ruleaz pe platforma Mozilla.

2.1.3 XPCOM
Flexibilitatea ridicat a platformei a fost obinut prin organizarea codului sub forma unor componente independente accesibile printr-un set de interfee pe care le implementeaz. Aceast abordare faciliteaz adugarea de funcionaliti noi la momente ulterioare cu eforturi i costuri minime cu o singur condiie ca toate componentele s implementeze un set de Universitatea Petru Maior 2006

Capitolul 2 Aspecte tehnologice

interfee standard care s poat face posibil comunicarea dintre ele. Pentru ca aceast abordare s poat fi utilizat cu succes n practic, era necesar un sistem performant pentru administrarea, regsirea i instanierea n timpul rulrii a diverselor componente, astfel a fost dezvoltat XPCOM (Cross Paltform Component Object Model), tehnologia prin care platforma Mozilla i administreaz propriile componente sau pe cele implementate de alte aplicaii. XPCOM este ntr-o anumit msur similar cu alte sisteme pentru tranzacionarea obiectelor cum ar fi CORBA (Common Object Request Broker Architecture) sau Microfost COM (Component Object Model). CORBA permite utilizarea obiectelor implementate ntr-o varietate larg de limbaje de la C/C++ pan la Ada sau Python din acest motiv interfeele trebuie s fie descrise ntr-un limbaj unic, portabil. n acest scop platforma CORBA utilizeaz pentru descrierea interfeelor limbajul IDL (Interface Definition Language). Mozilla utilizeaz XPIDL (Cross Platform Interface Definition Language) o variant a CORBA IDL. XPCOM este foarte similar cu Microsoft COM din punct de vedere al modalitii de administrare a duratei de via a obiectelor i al descoperirii interfeelor suportate de un obiect n timpul rulrii. Toate interfeele XPCOM la fel ca i cele COM sunt derivate din aceeai interfa nsISupports respectiv IUnknown, care definesc trei metode pe care trebuie s le implementeze orice obiect: AddRef(), Release() i QueryInterface(). Primele dou incrementeaz respectiv decrementeaz contorul de referine al obiectului, iar cnd valoarea lui ajunge la zero nseamn c nu mai exist nici o referin la obiect deci acesta poate fi distrus fr probleme. QueryInterface() se folosete pentru interogarea celorlalte interfee suportate de obiect permind astfel descoperirea tuturor capabilitilor acestuia n timpul rulrii aplicaiei. COM are i o versiune distribuita, DCOM, dar n XPCOM nu exist nc aceast posibilitate, utilizarea obiectelor fiind restricionat la acelai calculator i n momentul de fa chiar la aceeai aplicaie. De asemenea, spre deosebire de COM, sistemul XPCOM nu implementeaz n mod implicit mecanisme de sincronizare a accesului concurent la obiecte, orice facilitate de acest tip trebuind sa fie implementat de ctre programator pentru fiecare obiect n parte. Att componentele ct i interfeele sunt identificate printr-un UUID (un numr pe 128 de bii) sau un ContractID, o secven de caractere ntr-o form uor de reinut de utilizatori. Majoritatea componentelor XPCOM sunt scrise n C sau C++ cu NSPR la baz, dar dac interfeele lor utilizeaz exclusiv tipuri de date definite de XPIDL ele pot fi accesate uor de limbaje ca JavaScript prin intermediul tehnologiei XPConnect. JavaScript este de obicei Universitatea Petru Maior 2006

Capitolul 2 Aspecte tehnologice

limbajul care asigur legtura dintre interfaa cu utilizatorul i componentele de la baza platformei.

2.2 JavaScript
JavaScript este numele implementrii de ctre corporaia american Netscape a limbajului pentru scripturi ECMAScript, standardizat de ECMA (European Computer Manufacturers Association), organizaia european pentru standardizare n domeniul calculatoarelor. Dei limbajul a fost implementat i popularizat de Netscape numele su JavaScript este o marc nregistrat a Sun Microsystems. Contrar ideilor preconcepute existente JavaScript nu este o versiune a limbajului Java, de fapt n afara numelui i o parte a sintaxei nu au nimic n comun. Este un limbaj interpretat, netipizat, cu faciliti obiectuale rudimentare, utilizat cel mai des n scopul dinamicizrii coninutului, iniial static, al paginilor web sau pentru accesul la obiecte expuse de alte aplicaii. Printre capabilitile lui sunt: controlul comportamentului browser-ului, controlul documentului i aspectul acestuia, interaciunea cu documentul i coninutul acestuia, interaciunea cu utilizatorul sau interaciunea cu obiecte incluse n documente. Sintaxa este similar cu cea a limbajului C, dar variabilele nu au un tip atribuit n mod static n momentul declarrii, ele pot indica spre diverse tipuri de date de-a lungul existenei lor. Facilitile sale obiectuale foarte reduse, comparativ cu cele oferite de limbajele orientate obiect clasice ca C++ sau Java, din acest motiv nu se poate spune despre JavaScript c este cu adevrat un limbaj obiectual. Nu prezint instruciuni pentru operaii de intrare ieire trebuind s se bazeze pe mediul gazd pentru acest lucru. n cadrul platformei Mozilla JavaScript asigur dinamismul interfeei cu utilizatorul precum i legtura dintre aceasta i serviciile oferite de nivele inferioare (prin tehnologia XPConnect).

2.3 DHTML
La nceputurile existenei sale World Wide Web-ul oferea acces la documente cu un coninut static, compus n mare parte din text formatat, imagini i legturi ctre alte documente. n timp cerinele s-au schimbat, iar coninutul static nu a mai fost satisfctor

Universitatea Petru Maior 2006

Capitolul 2 Aspecte tehnologice

pentru utilizatorii de Internet. Pentru a satisface nevoia de dinamism n paginile web a aprut DHTML (Dynamic HyperText Markup Language) care nu este o tehnologie nou, ci doar o nou modalitate de a utiliza tehnologiile existente mai exact HTML, CSS (Cascading Style Sheets) i JavaScript. Coninutul documentelor este descris n limbajul HTML i sunt formatate utiliznd CSS, limbajul care descrie modul de prezentare al unui document scris ntr-un limbaj de adnotare. Dinamismul paginii este oferit de scripturile ncrcate de client care modific coninutul documentului n urma interaciunii cu utilizatorul. Scripturile sunt scrise de obicei n limbajul JavaScript.

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

10

Capitolul 3 Prezentarea aplicaiei

La ora actual sistemele pentru controlul cldirilor sunt nite aplicaii foarte complexe care nglobeaz o gam larg de tehnologii i echipamente, iar utilizarea lor, n lipsa unei interfee adecvate, reprezint o sarcin dificil chiar i pentru utilizatorii care posed cunotine tehnice de specialitate. Aplicaia Web prezentat n continuare a fost astfel proiectat nct utilizarea ei s se fac ntr-un mod intuitiv, uor de neles, oferind o interfa grafic interactiv, prin care utilizatorul acceseaz serviciile oferite de sistemul de monitorizare i control. De asemenea, tehnicile de programare i tehnologiile folosite n implementare au fost astfel alese nct aplicaia s poat fi portat cu uurin pe mai multe sisteme de operare i n acelai timp s ofere performane bune atunci cnd ruleaz pe sisteme de calcul mai puin performante.

3.1 Diagrama cazurilor de utilizare

Diagrama cazurilor de utilizare, prezentat n Figura 3.1 descrie aplicaia din punctul de vedere al utilizatorului ei. Aciunile posibile sunt: autentificare: sistemul de control ofer faciliti de stabilire a unor drepturi la nivel de utilizator sau grupuri de utilizatori astfel nainte de executarea oricrei operaii asupra sistemului este nevoie de o autentificare; aceasta se face prin parol sau printr-un terminal pentru iButton. acionare mecanism nchidere/deschidere u: dac ua este dotat cu un mecanism electro-mecanic care s permit deschiderea sau nchiderea acesta poate fi comandat cu ajutorul calculatorului. vizualizare jurnal intrri/ieiri: dac deschiderea uii se face cu ajutorul unui iButton atunci sistemul poate nregistra ntr-o baz de date un jurnal care s conin momentul accesului n cldire precum i identitatea persoanei. activare/dezactivare alarm: aplicaia permite activarea sau dezactivarea sistemului de alarma anti-efracie. stabilire zone de alarm: sistemul permite definirea unor zone de alarm i activarea sau dezactivarea lor n mod individual.

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

11

Figura 3.1 Diagrama cazurilor de utilizare acionare ntreruptor lumin: aplicaia ofer posibilitatea utilizatorilor s acioneze comutatoarele becurilor din cldire. vizualizare temperatur curent/grafic temperatur: sistemul monitorizeaz o serie de senzori de temperatur plasai n cldire, iar aplicaia poate s ofere utilizatorului informaii despre temperatura curent sau un istoric al acesteia sub form de grafic. ajustare temperatur maxim: sistemul implementeaz i o component de control al temperaturii astfel cu ajutorul aplicaiei utilizatorul poate stabili temperatura maxim pentru o ncpere din cldire. vizualizare evenimente de micare: prin instalarea unor senzori de micare utilizatorul poate vedea n timp real dac exist evenimente de Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

12

micare n cldire; de asemenea sistemul menine un jurnal al acestor evenimente care poate fi consultat la momente ulterioare. vizualizare imagini camer de supraveghere: dac n cldire sunt instalate camere video de supraveghere aplicaia permite vizualizarea n timp real a imaginilor primite de la acestea; sistemul salveaz nregistrri ale imaginilor primite de la aceste camere, nregistrri care pot fi vizualizate n orice moment. ajustare poziie camer supraveghere: exist camere de supraveghere care permit utilizatorului ca prin intermediul aplicaiei s ajusteze poziia camerei sau ali parametrii ai imaginii.

3.2 Arhitectura sistemului de monitorizare i control

n Figura 3.2 este prezentat arhitectura general a ntregului sistem de monitorizare i control al cldirilor.

Figura 3.2 Arhitectur general sistem Se disting urmtoarele componente: echipamente de monitorizare i control: reprezint totalitatea senzorilor, traductoarelor, mecanismelor i a circuitelor electronice utilizate pentru monitorizarea i controlul cldirii.

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei -

13

baza de date: este locaia n care se salveaz toate datele necesare funcionrii sistemului ncepnd cu setrile iniiale, echipamentele existente, utilizatorii autorizai, grupurile de utilizatori, drepturile utilizatorilor i grupurilor, zonele de alarm, jurnalele de acces sau evenimente etc.

camere video: acestea sunt plasate n diverse puncte ale cldirii i transmit imagini, n mod continuu sau doar n cazul unor evenimente prestabilite, n funcie de setri.

server principal: este componenta central a sistemului responsabil de comunicarea cu toate echipamentele din cldire, comunicarea cu baza de date, controlul accesului, administrarea drepturilor utilizatorilor, administrarea alarmei i a zonelor de alarm, meninerea jurnalelor de acces sau evenimente, salvarea parametrilor raportai de echipamente etc.

server video: se afl n conexiune cu toate camerele de supraveghere instalate recepioneaz toate imaginile i le retransmite, la cerere spre aplicaia client pentru a putea fi urmrite n timp real; n acelai timp imaginile recepionate sunt salvate n fiiere pentru a putea fi vizualizate ulterior.

server reluare: aplicaia client se conecteaz la acest server cnd se dorete vizualizarea imaginilor de la o camer nregistrate la un moment din trecut. aplicaia client: reprezint interfaa utilizatorilor ctre ntregul sistem i-i permite acestuia n funcie de drepturile pe care le are accesul la serviciile oferite.

3.3 Comunicarea cu echipamentele

Structura subsistemului de comunicare cu echipamentele este prezentat n Figura 3.3. Dup cum se poate observa din figur, toate echipamentele sunt conectate la aceeai magistral mpreun cu un echipament special numit Monitor, acesta reprezentnd interfaa dintre server si ele. Comunicarea ntre Monitor i echipamente se poate face prin diverse tehnici, dou soluii posibile fiind reelele CAN sau prin reeaua de distribuie a energiei electrice folosind protocolul X10. Fiecare echipament are un set de variabile a cror valori determin att starea ct i comportamentul acestuia. Monitorul este conectat la server printrun modul de comunicare de care sunt legate mai multe obiecte numite Peer. Fiecrui Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

14

echipament din sistem i corespunde un Peer n server care menine o replic fidel a strii echipamentului. Valorile variabilelor pot fi citite sau scrise, deci n final toate operaiile de monitorizare sau control se vor rezuma la operaii de citire respectiv scriere asupra variabilelor unuia sau mai multor echipamente.

Figura 3.3 Comunicarea cu echipamentele n server mai exist un numr oarecare de interfee prin care se realizeaz comunicarea cu celelalte entiti din sistem cum ar fi baza de date sau aplicaia client, de obicei prin conexiuni TCP/IP. Figura 3.4 prezint componentele sistemului implicate n operaia de setare a valorii unei variabile. Iniiatorul este aplicaia client, de unde valoarea (val) mpreun cu numele

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

15

variabilei (var) i numele echipamentului (echip) trec prin interfa ajung la obiectul Peer asociat echipamentului, apoi trec mai departe prin modulul de comunicare i monitor pn ajung la echipamentul vizat.

Figura 3.4 Setarea unei variabile

3.4 Monitorizarea video

n monitorizarea video sunt implicate cele trei servere video i aplicaia client dup cum se poate vedea i din Figura 3.5.

Figura 3.6 Monitorizarea video Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

16

Camerele sunt legate direct la unul sau mai multe servere de captur, care preiau imaginile de la acestea i le transmit la serverul video printr-o conexiune TCP/IP. n momentul n care serverul a recepionat o imagine capturat de la o camer oarecare o salveaz ntr-un fiier i imediat o transmite mai departe oricrei aplicaii client care este conectat i a cerut vizualizarea camerei respective. Aceleai imagini pot fi revzute mai trziu, dar de aceast dat printr-o conexiune la serverul pentru reluri care va retransmite imaginile salvate n fiiere de serverul video.

3.5 Aplicaia client

Aplicaia client este interfaa dintre utilizator i sistemul de monitorizare i control. Structura ei este prezentat n Figura 3.7 i dup cum se poate vedea este alctuit din 4 pri majore: ESSHandler componenta responsabil de comunicarea cu serverul principal, LiveVideo componenta care asigur comunicarea cu serverul video, ReplayVideo componenta care realizeaz comunicarea cu serverul pentru reluare i interfaa grafic.

Figura 3.7 Structura aplicaiei client Legturile dintre componente i serverele corespunztoare sunt conexiuni TCP/IP, iar comunicarea dintre componente i interfaa grafic se face prin perechi de interfee pentru ca fiecare legtur s fie bidirecional. Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

17

Componenta ESSHandler este accesibil prin interfaa IESSHandler, n continuare sunt enumerate cele mai reprezentative metode: connect(server, port, user, pass): stabilete o conexiune TCP/IP cu serverul principal; argumentele sunt adresa IP a serverului, portul, numele sub care este nregistrat utilizatorul i parola. disconnect(): ntrerupe conexiunea stabilit cu serverul. getMonitors(): interogheaz monitoarele conectate la serverul principal. getPeers(monitor): interogheaz toate obiectele de tip Peer conectate la monitorul dat ca argument. getVariables(monitor, peer): interogheaz lista variabilelor disponibile pentru obiectul de tip Peer i monitorul dat ca argument. getVariable(monitor, peer, variable): interogheaz valoarea variabilei al crei nume este n argumentul variable. setVariable(monitor, peer, variable): seteaz valoarea variabilei dat ca argument. requestNotification(): cere o notificare de la component. Din cauza unor limite impuse de tehnologia folosit, notificri despre apariia unor evenimente nu pot fi trimise n mod asincron ctre interfaa grafic. Pentru a ocoli aceast restricie toate evenimentele i imaginile primite (n cazul componentelor LiveVideo i ReplayVideo) se depun ntr-o coad de ateptare intern, urmnd ca din interfaa grafic s se apeleze la intervale regulate de timp metoda requestNotification(). La apelul acesteia se va extrage primul eveniment din coad i n funcie de tipul lui se va apela metoda corespunztoare din interfaa IESSHandlerNotify. Secvena de apeluri pentru primirea notificrilor apare n Figura 3.8.

Figura 3.8 Secven notificare

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

18

Notificrile venite de la componenta ESSHandler ajung la interfaa grafic prin interfaa IESSHandlerNotify. n continuare sunt enumerate cteva metode: notifyError(error): notific apariia unei erori n component. notifyDisconnect(): notific ntreruperea conexiunii cu serverul principal. notifyMonitor(monitor): dup ce se apeleaz funcia pentru interogarea monitoarelor conectate numele acestora sunt transmise de ctre server sub forma de notificri care trec prin coada de ateptare a componentei i n final ajung pn la interfaa grafic. notifyPeer(monitor, peer): notific existena unui obiect de tip Peer dup o interogare n acest sens. notifyPeerVariable(monitor, peer, variable): notific existena unei variabile pentru un anumit obiect Peer. notifyPeerVarValue(monitor, peer, variable, value): notific modificarea valorii unei anumite variabile pentru un anumit Peer. Componenta LiveVideo este accesibil prin interfaa ILiveVideo care definete urmtoarele metode: connect(server, port): stabilete o conexiune cu serverul video; primete ca argumente adresa IP a serverului i portul pe care ascult. disconnect(): ntrerupe o conexiune stabilit cu serverul video. getCameras(): interogheaz numele camerelor disponibile. addCamera(cameraName): cere imagini de la camera al crei nume este dat ca argument. removeCamera(cameraName): oprete recepia imaginilor de la camera al crei nume este dat ca argument. requestNotification(): metoda are aceeai semnificaie ca cea din interfaa IESSHandler. Notificrile sunt expediate interfeei grafice printr-un mecanism similar celui implementat n componenta ESSHandler. Interfaa pentru notificri este ILiveVideoNotify, iar metodele ei sunt: notifyError(error): notific apariia unei erori. notifyDisconnect(): notific ntreruperea conexiunii cu serverul video. notifyCameraName(cameraName): n urma interogrii numele camerelor disponibile sunt transmise interfeei grafice sub forma unor notificri.

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei -

19

notifyFrame(frame, cameraName): notific sosirea unei imagini de la serverul video; argumentele metodei sunt imaginea efectiv i numele camerei care a capturat imaginea respectiv.

Componenta ReplayVideo se acceseaz prin interfaa IReplayVideo. Metodele definite de aceast interfa sunt: connect(server, port): stabilete o conexiune cu serverul pentru reluare video; primete ca argumente adresa IP a serverului i portul. disconnect(): ntrerupe conexiunea cu serverul video. getCameras(): interogheaz numele camerelor disponibile. addCamera(cameraName): adaug numele unei camere n lista meninut de component. removeCamera(cameraName): scoate o list din lista de camere. removeAllCameras(): scoate toate camerele din list; startSession(startTime, endTime): pornete o sesiune de reluare video; serverul pentru reluare va retransmite imaginile salvate n intervalul de timp dat ca argument, de la toate camerele aflate n lista. stopReplaySession(): oprete o sesiune de reluare video. jump(time): execut un salt n sesiune pn la momentul de timp dat ca argument. fastForward(speed): modific viteza de redare. requestNotification(): are acelai cop ca metodele cu acelai nume din celelalte interfee prezentate. Notificrile din aceast component vin prin interfaa IReplayVideoNotify. Metodele definite de aceasta sunt: notifyError(error): notific apariia unei erori. notifyDisconnect(): semnaleaz ntreruperea conexiunii cu serverul. notifyCameraName(cameraName): numele camerelor disponibile sunt transmise ca notificri. notifyFrame(frame, cameraName, subtitle, timestamp): notific recepionarea unei imagini de la server; spre deosebire de serverul video, serverul pentru reluare transmite pentru fiecare imagine o subtitrare i o marc de timp utilizat pentru operaiile de salt. notifyTimeStamps(startTime, endTime): la nceputul unei sesiuni serverul pentru reluare trimite clientului mrcile de timp pentru prima i Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

20

ultima imagine din sesiune; aceste mrci de timp vor fi folosite pentru calculul poziiei de salt. Fiecare component poate s stabileasc cel mult o conexiune, deci conectarea la mai multe servere presupune existena mai multor instane ale componentelor corespunztoare.

3.6 Controlul benzii

O parte important a sistemului de monitorizare i control o reprezint monitorizarea video care presupune afiarea n timp real a unui flux video. Prezentarea fluxurilor multimedia este o problem general a tuturor aplicaiilor web datorit faptului c acestea ruleaz peste aplicaii browser i sunt implementate n general cu limbaje pentru scripturi, care fiind limbaje interpretate sunt mai lente dect codul compilat i executat direct de procesor. Exista astfel posibilitatea, confirmat de cteva teste, ca pe unele platforme rata maxima de prezentare a imaginilor pe care o poate asigura interfaa grafic s nu fie suficient de mare comparativ cu rata de recepionare de la serverul video. Meninerea constant a diferenei dintre rata de prezentare i cea de recepie are ca rezultat suprancrcarea aplicaiei client i acumularea imaginilor n coada de ateptate a componentei care va conduce la apariia unor ntrzieri considerabile n fluxul video. n aceste condiii era preferabil o scdere a calitii imaginilor n beneficiul eliminrii ntrzierilor i pstrarea caracteristicii de timp real a fluxului video. n consecina s-a implementat un mecanism de control a benzii care, n colaborare cu serverul video, pe baza unor parametrii msurai va limita rata de transfer a datelor pn la un nivel acceptabil pentru aplicaia client astfel nct s se reduc la maxim ntrzierile cauzate de rata de prezentare mai mic. Acest mecanism de control are la baz o nou component numit ControlService al crei scop este colectarea valorilor unor parametrii msurai de componente i luarea unor decizii de limitare a ratei de transfer n concordan cu acestea. Structura modificat a aplicaiei client este prezentat n Figura 3.9. Parametrii msurai de componentele LiveVideo i ReplayVideo sunt: rata de intrare BI reprezentnd totalitatea datelor recepionate de la server n unitatea de timp, banda de ieire
B

BO contorizat la ieirea din component spre interfaa grafic i numrul imaginilor din
B

coada de ateptare a componentei N. Cei trei parametrii sunt trimii la intervale regulate de timp componentei de control al benzii prin interfaa IControlService.

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

21

BI =

NI [Bps] , unde NI reprezint totalitatea octeilor recepionai, iar t este intervalul t

de timp n care au fost recepionai. BO = NO [Bps] , unde NO reprezint totalitatea octeilor trimii spre interfaa grafic, t

iar t intervalul de timp n care au fost trimii.

Figura 3.9 Controlul benzii

Metodele definite de interfaa IControlService sunt descrise n continuare: register(): nainte de a putea raporta valorile parametrilor msurai, fiecare

component trebuie s se nregistreze.

unregister(id): dup fiecare nregistrare trebuie apelat aceast metoda

pentru a opri raportarea parametrilor.

reportInBand(id, band): raporteaz banda de intrare (msurat n octei

pe secund).
reportOutBand(id, band): raporteaz banda de ieire din component

(msurat n octei pe secund).

reportQueueSize(id, size): folosit pentru a raporta numrul de elemente

(imagini) acumulate n coada de ateptare.

requestMaxBandwidth(id): cere valoarea maxim acceptabil pentru

banda de intrare.

Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

B B

22

innd cont de cei trei parametrii raportai BI, BO i N componenta ControlService estimeaz valoarea maxim acceptabil pentru banda de intrare BMAX. La intervale regulate de
B

timp aceast valoare este transmis serverului video care va limita prin aruncarea unor imagini rata de transfer a datelor care pleac spre aplicaia client. Limitarea ratei de transfer conduce n mod inevitabil la o scdere a calitii fluxului video. Mecanismul de reglare este evideniat n Figura 3.10.

Figura 3.10 Mecanismul de reglare al benzii

Componenta ControlService menine o istorie a valorilor parametrilor raportate de celelalte componente pentru a putea fi luate n calcul tendinele de variaie ale acestor mrimi. Algoritmul de reglare este relativ simplu astfel dac numrul de elemente acumulate n coad depete o anumit valoare i tendina este de cretere, valoarea maxim pentru rata de transfer, BMAX, va fi automat sczut. Diferene ntre banda de ieire i cea de intrare apar n
B

general atunci cnd se urmresc simultan mai multe camere i volumul datelor primite depete capacitatea de prezentare a interfeei grafice. Datorita faptului c numrul camerelor urmrite simultan variaz n mod dinamic pe parcursul funcionrii aplicaiei se poate imagina urmtorul scenariu: iniial este activ doar o camer video caz n care rata de intrare BI este mai mic dect valoarea maxim a BO; utilizatorul activeaz o nou camer, i
B B

n acest caz BI este mai mic dect capacitatea de afiare; se activeaz a treia camer i BI
B B

devine prea mare, iar imaginile ncep s se acumuleze n coada; mecanismul de reglare detecteaz acumularea i tendina de cretere a dimensiunii cozii i limiteaz automat banda maxim; serverul reacioneaz n consecin i limiteaz rata de transfer, scznd calitatea fluxului video, pn cnd aceasta ajunge la un nivel sub capacitatea de prezentare a interfeei grafice; n aceste condiii dimensiunea cozii de ateptare ncepe s scad pn atinge valoarea minima, dar n momentul respectiv rata de intrare este sub capacitatea de afiare, deci posibilitile aplicaiei nu sunt exploatate la maxim; pentru creterea calitii mecanismul de reglare va cere severului creterea n trepte a ratei de transfer pn cnd se atinge limita capacitii de afiare; dac n acest interval utilizatorul dezactiveaz o camer rata maxim de Universitatea Petru Maior 2006

Capitolul 3 Prezentarea aplicaiei

23

intrare nu va atinge niciodat capacitatea maxim de afiare, iar mecanismul de reglare va continua s cear creterea ratei de transfer chiar dac acest lucru nu este fizic posibil; pentru ieirea din acest impas se impune aplicarea unei condiii suplimentare care s mpiedice cererea mririi ratei de transfer la infinit. Cu ajutorul acestor reguli simple mecanismul de reglare menine rata intrare BI la o
B

valoare acceptabil astfel nct rata maxim de prezentare posibil s nu fie depit chiar cu riscul scderii calitii fluxului video, dar cu pstrarea caracteristicii de timp real a acestuia. n acelai timp se ncearc exploatarea la maxim a posibilitilor interfeei grafice.

Universitatea Petru Maior 2006

Capitolul 4 Implementare

24

Capitolul 4 Implementare

4.1 Tehnologii folosite

Aplicaia a fost dezvoltat pe platforma Mozilla i poate s ruleze ca aplicaie Web ntr-unul din browser-ele bazate pe aceast platform (Firefox, Mozilla) instalndu-se foarte uor ca o extensie a lor sau poate s ruleze ca aplicaie de sine stttoare utiliznd motorul (XULRunner) pus la dispoziie de grupul care a dezvoltat platforma. ESSHandler,
LiveVideo, ReplayVideo i ControlService sunt componente XPCOM scrise n limbajul

C++ i au la baz API-ul NSPR. Interfaa grafic este realizat utiliznd tehnica DHTML, o combinaie ntre HTML i JavaScript. Alegerea acestor tehnologii ofer o serie de avantaje cel mai important dintre ele fiind portabilitatea conferit de platform i de NSPR, API-ul peste care sunt dezvoltate componentele XPCOM, nucleul care nglobeaz cea mai mare parte din funcionalitatea aplicaiei. Al doilea avantaj major provine din modul de implementare al interfeei grafice, aceasta prezint multiple posibiliti de particularizare astfel nct utilizarea sistemului s se fac n mod natural, s fie ct mai intuitiv, ct mai uor de neles chiar i pentru utilizatorul neiniiat. Acest aspect este de multe ori ignorat de ctre dezvoltatori care nu in cont c interfaa grafic este panoul de comand prin care utilizatorul manipuleaz aplicaia, iar puterea acesteia nu poate fi exploatat la maxim dect dac este utilizat corespunztor. De asemenea trebuie inut cont c interfaa grafic este cea care intr prima n contact cu utilizatorul i dac este proiectat corespunztor poate s creeze o prima impresie pozitiv care s se generalizeze apoi asupra ntregii aplicaii contribuind astfel n mod decisiv la succesul de pia al acesteia. Combinaia DHTML JavaScript pe lng avantajele enumerate anterior aduce cu sine i un dezavantaj destul de important, mai ales pentru o aplicaie care afieaz fluxuri video, este relativ lent comparativ cu aplicaiile implementate n limbaje compilate utiliznd tehnologii dependente de platform. Aceast problem este evident atunci cnd utilizatorul dorete s vizualizeze mai multe fluxuri video simultan, motiv pentru care a fost necesar introducerea mecanismului de control al benzii (descris n seciunea 3.6) care introduce n mod inevitabil o scdere a calitii fluxului. Platforma Mozilla este un proiect open-source pus la dispoziie n mod gratuit oricui dorete s o utilizeze. De aici apare o mic problem, din punctul de vedere al dezvoltatorilor,

Universitatea Petru Maior 2006

Capitolul 4 Implementare

25

mai exact lipsa unei documentaii cuprinztoare i a unui suport tehnic prompt care este disponibil de obicei n cazul tehnologiilor comerciale. Acest aspect ngreuneaz puin dezvoltarea aplicaiilor i poate s duc la creterea timpului necesar implementrii. Apare i problema calitii soft-ului, n general pentru tehnologii gratuite nu se asigur nici un fel de garanie.

4.2 Componenta ESSHandler

ESSHandler este o component XPCOM, deci respect regulile impuse de

proiectanii sistemului privind structura i modul de implementare. Diagrama de clase este prezentat n Figura 4.1.

Figura 4.1 Diagrama de clase pentru componenta ESSHandler

Clasa Thread ncapsuleaz datele necesare i funcionalitatea unui fir de execuie aa cum este el definit de NSPR. Datele membre sunt m_Thread, descriptorul firului de execuie i dou variabile booleene m_bRunning i m_bRun utilizate pentru a semnala starea Ruleaz a firului, respectiv pentru a semnaliza oprirea acestuia. Funciile Create(), Stop() i IsRunning() se folosesc pentru a porni, opri, respectiv interoga starea firului de execuie. Funciile virtual InitInstance(), Run() i StopInstance() pot fi suprascrise n clasele derivate i se vor apela n ordinea n care au fost enumerate.

Universitatea Petru Maior 2006

Capitolul 4 Implementare

26

Clasa Socket ncapsuleaz funcionalitatea unui SOCKET utilizat pentru a stabili conexiuni TCP/IP. Datele membre sunt m_Socket, descriptorul obiectului SOCKET, m_bListening, variabil boolean care semnalizeaz starea Ascultare, m_bConnected tot o

Figura 4.2 Clasa Thread

Figura 4.3 Clasa Socket

variabil boolean care semnalizeaz starea Conectat i m_pRecvBuffer, zona de memorie n care se depun datele recepionate. Funciile Create() i Destroy() creeaz, respectiv distrug obiectul, iar toate celelalte funcii publice implementeaz operaii specifice SOCKET-urilor. Funciile OnAccept(), OnClose(), OnReceive() i OnError() sunt virtuale, pot fi suprascrise de

Universitatea Petru Maior 2006

Capitolul 4 Implementare

27

clasele derivate i se apeleaz din firul de execuie asociat obiectului n cazul urmtoarelor evenimente: acceptarea unei conexiuni (pentru un SOCKET aflat n starea de Ascultare), nchiderea unei conexiuni, recepionarea unor date sau apariia unei erori. Clasa ClientAPI motenete n mod indirect clasa Socket i realizeaz conexiunea cu serverul principal. Definete cte o funcie pentru fiecare tip de mesaj care poate fi trimis serverului i la fel cte o funcie virtual care va fi apelat pentru fiecare tip de mesaj primit. Clasa principal este ESSHandler, cea care implementeaz interfaa IESSHandler i implicit n urma relaiei de motenire nsISupports, interfa care trebuie implementat de orice component XPCOM.

Figura 4.4 Clasa ESSHandler

Printre datele membre conine m_lstMessages, coada de ateptare n care se depun mesajele primite de la server (prin apeluri ale funciei PostNotification()), urmnd ca la fiecare apel al metodei requestNotification() implementat de clas i definit de interfaa IESSHandler, s se extrag primul mesaj din coad i s se apeleze metoda corespunztoare din interfaa
IESSHandlerNotify, implementat n JavaScript de un obiect din interfaa grafic. Apelurile

pentru interfaa grafic se fac cu funcia FireEvent() care primete ca argument mesajul care trebuie transmis. Clasa ESSHandler suprascrie funciile virtuale definite de clasa de baza
ClientAPI, cum este ESSOnNewMonitors() pentru a primi notificri n funcie de mesajele

recepionate de la server. De asemenea tot aceast clas este cea care implementeaz toate metodele definite de interfaa componentei XPCOM. Clasele ApiParser i ApiParserLevel1 se folosesc pentru procesarea datelor i compunerea mesajelor utilizate n comunicarea cu serverul. Acestea sunt formatate ca un set de iruri de caractere terminate cu '\n' cum se poate vedea n Figura 4.5. Din datele recepionate prin canalul de comunicaie n format brut, ApiParserLevel1 extrage elementele componente ale unui mesaj pentru a face procesarea acestora mai uoar.

Universitatea Petru Maior 2006

Capitolul 4 Implementare

28

Figura 4.5 Structura mesajului

Clasele ApiObject, ApiString i ApiVector sunt folosite la manipularea irurilor de caractere i a tablourilor de obiecte tot n cadrul operaiilor de procesare a datelor recepionate prin SOCKET. Clasele ApiSemaphore i ApiRWSemaphore ncapsuleaz obiecte de sincronizare de tipul LOCK, oferite de NSPR. n timp ce ApiSemaphore ofer o funcionalitate de tipul MUTEX care permite accesul unui singur fir de execuie n seciunea critic definit, ApiRWSemaphore permite accesul mai multor fire de execuie i se preteaz la probleme de sincronizare de tipul productor-consumator. Fiind o aplicaie pe mai multe fire de execuie prezena unor obiecte de sincronizare este absolut necesar pentru a proteja accesul la resurse utilizate n comun. n plus trebuie inut cont i de faptul c XPCOM nu ofer mecanisme de sincronizare al accesului la componente cum exist definite n Microsoft COM, tocmai n acest scop, modelele de apartament. Lucrul cu iruri de caractere este dificil greoi avnd ca efect scderea performanelor aplicaiei, astfel, n scopul eficientizrii operaiilor efectuate asupra mesajele primite de la sau trimise spre server, s-a introdus clasa
Message care menine toate componentele unui mesaj ntr-o list pentru un acces mai rapid.

4.3 Componenta LiveVideo

LiveVideo este componenta care comunic cu serverul video, decodeaz imaginile

primite i le transmite pentru afiare interfeei grafice. Diagrama de clase a componentei este prezentat n Figura 4.6.

Figura 4.6 Diagrama de clase pentru componenta LiveVideo

Universitatea Petru Maior 2006

Capitolul 4 Implementare

29

Clasele Thread i Socket sunt identice cu cele folosite de componenta ESSHandler fiind suficient de generale pentru a putea fi refolosite. Protocolul de comunicare cu serverul este unul bazat pe mesaje, iar clasa ServerConnection, responsabil de comunicare, este cea care proceseaz datele primite, izoleaz mesajele i extrage elementele constitutive ale acestora. Tot n aceast clas sunt definite metode virtuale ca OnDisconnect(), OnCommunicationError() sau OnMessage() care vor fi apelate n cazul deconectrii, apariiei unei erori respectiv recepionarea unui mesaj.

Figura 4.7 Clasa ServerConnection

Funcia SendMessage() trimite un mesaj serverului. Clasa Message ncapsuleaz un mesaj, iar definiia ei reflect formatul mesajului.
LiveVideo este clasa central care implementeaz toate metodele definite de interfaa ILiveVideo i menine coada de mesaje m_lstMessages i lista camerelor active

m_lstAccessList. Tot n aceast clas sunt suprascrise funciile virtuale definite de clasa de baz care se vor apela n cazul apariiei evenimentelor corespunztoare. Cea mai important este OnMessage() care va fi apelat atunci cnd se primete un mesaj nou de la server. Mesajul primit va fi depus n coada de ateptare, apelnd PostNotification(), pn la apelul metodei requestNotification(), definit de ILiveVideo, cnd va fi extras i n funcie de tipul lui se va apela metoda corespunztoare dintre cele definite de interfaa ILiveVideoNotify.

Universitatea Petru Maior 2006

Capitolul 4 Implementare

30

Aceasta din urm este implementat de un obiect din interfaa grafic, iar apelul metodelor se face prin funciile FireFrameEvent(), FireDisconnectEvent() i celelalte.

Figura 4.8 Clasa LiveVideo

Spre deosebire de componenta ESSHandler, LiveVideo are un fir de execuie n plus,

MonitorThread, care la intervale prestabilite de timp raporteaz parametrii msurai

serviciului de monitorizare i control denumit ControlService. MonitorParams calculeaz i salveaz parametrii monitorizai, rata de intrare, rata de ieire i numrul mesajelor din coada de ateptare. Tot aici se salveaz i valorile intermediare utilizate n timpul msurtorilor.
TimeInterval intervine n msurarea intervalelor de timp utilizate n calculul parametrilor

care depind de timp (rata de intrare i rata de ieire).

4.4 Componenta ReplayVideo

Cele doua servere cel pentru flux video n timp real i cel pentru reluarea imaginilor nregistrare, sunt asemntoare din punct de vedere al protocolului folosit si al structurii mesajelor astfel componenta ReplayVideo este aproape identic din punct de vedere al implementrii cu LiveVideo. Singura diferen este clasa LiveVideo care n acest caz este nlocuit de clasa ReplayVideo care implementeaz metodele definite de interfaa
IReplayVideo meninea coada de ateptare i transmite notificrile spre interfaa grafic.

Universitatea Petru Maior 2006

Capitolul 4 Implementare

31

4.5 Componenta ControlService

Este tot o component XPCOM, dar spre deosebire de celelalte aceasta este utilizat ca un serviciu, adic nu poate fi instaniat dect ntr-un singur exemplar. Diagrama de clase apare n Figura 4.9.

Figura 4.9 Diagrama de clase pentru componenta ControlService

Clasa

central

este

ControlService,

implementeaz

metodele

interfeei

IControlService salveaz parametrii raportai de celelalte componente i implementeaz

algoritmul de reglare. Queue implementeaz funcionalitatea unei cozi de valori i pe lng operaiile obinuite de adugare i tergere definete i funcii pentru estimarea tendinei de cretere sau scdere a valorilor stocate. MOParams stocheaz parametrii unei singure componente nregistrate folosind obiecte de tipul Queue pentru a oferi o viziune asupra evoluiei n timp a acestora. IDSource este un generator de numere unice fiecrei component nregistrat fiindu-i asociat un astfel de numr care va fi folosit ulterior pentru identificarea ei.
Mutex ncapsuleaz un obiect de sincronizare necesar pentru a proteja accesul la serviciul de

monitorizare i control mpiedicnd apariia unor date corupte care pot conduce la un reglaj eronat al benzii.

4.6 Interfaa grafic

Este implementat n limbajul HTML i animat cu scripturi scrise n JavaScript. Cea mai mare parte a funcionalitii aplicaiei este implementat de componentele XPCOM astfel c rolul interfeei grafice este unul relativ simplu. Scripturile ncrcate mpreun cu documentul iniial trebuie sa instanieze toate cele patru componente s implementeze interfeele pentru notificri ILiveVideoNotify, IReplayVideoNotify i IESSHandlerNotify. Universitatea Petru Maior 2006

Capitolul 4 Implementare

32

Pe msur ce vor sosi notificri prin cele trei interfee scripturile vor modifica documentul HTML n mod dinamic, fr rencrcarea lui, oferind astfel dinamism interfeei i reflectnd schimbrile survenite n starea sistemului. Scripturile transform aciunile utilizatorului n apeluri de metode ale componentelor care prin trimiterea de mesaje serverelor vor opera modificri asupra sistemului. Tot scripturile vor afia la cerere imaginile provenite de la camerele de supraveghere. Interfaa grafic este foarte uor particularizabil, elementele sale constitutive sunt salvate sub forma unor imagini care pot fi nlocuite schimbnd astfel nfiarea interfeei dar pstrndu-i neschimbat funcionalitatea. Aspectul acesteia mai exact modul de grupare al componentelor sau poziia lor pe ecran este cuantizat printr-un set de valori care se salveaz n baza de date. Schimbarea acestor valori va conduce la schimbarea aspectului, dar la fel ca i n cazul anterior, va pstra neschimbata funcionalitatea. Modul de realizare al interfeei grafice i confer o flexibilitate foarte mare ea putnd fi astfel adaptat uor oricrei configuraii a sistemului de monitorizare i control.

Universitatea Petru Maior 2006

Capitolul 5 Testarea performanelor

33

Capitolul 5 Testarea performanelor

n cadrul acestei aplicaii monitorizarea video ridic cele mai mari probleme deoarece afiarea unui flux video presupune un efort de calcul destul de nsemnat. Mai mult dificultile sunt amplificate de tehnologia folosit care a fost proiectat pentru cu totul alte scopuri. Exista suspiciunea, confirmat ulterior de msurtori, c interfaa grafic nu este suficient de rapid pentru a permite afiarea simultan a imaginilor provenite de la mai multe camere video. n figurile de mai jos sunt prezentate rezultatele testelor iniiale. Msurtorile au fost efectuate pe cele trei platforme suportate de aplicaie Windows, Linux i MacOS activnd una, doua sau trei camere simultan pe durata a 10 minute. Parametrii msurai sunt rata de intrare [octei/secund], rata de ieire [octei/secund] i numrul de elemente din coada de ateptare.

Figura 5.1 Variaia ratelor de intrare i ieire pe platforma Windows

Msurtorile au artat c pe Windows i MacOS dei diferena dintre rata de intrare i cea de ieire variaz n timp, valoarea ei medie rmne mic, apropiat de 0, astfel nu apar acumulri nedorite n coada de ateptare. Pe Linux ns, mai ales cnd sunt active trei camere video simultan, aceast diferen este semnificativ, lucru ilustrat de Figura 5.3, ceea ce va conduce la o acumulare a imaginilor n coada de ateptare a componentei, dup cum arat
Figura 5.4. Acumularea imaginilor se produce ntr-un ritm destul de ridicat ajungnd la un

nivel de peste 3000 de imagini ntr-un interval de 10 minute. La o rat de captur medie de 7 Universitatea Petru Maior 2006

Capitolul 5 Testarea performanelor

34

8 imagini pe secund, provenite de la 3 camere video, genereaz o ntrziere de 125 de secunde, total inacceptabil pentru un sistem de monitorizare video n timp real.

Figura 5.2 - Variaia ratelor de intrare i ieire pe platforma MacOS

Figura 5.3 - Variaia ratelor de intrare i ieire pe platforma Linux

Universitatea Petru Maior 2006

Capitolul 5 Testarea performanelor

35

Figura 5.4 Dimensiunea cozii de ateptare pe platforma Linux

Mecanismul de control al benzii reuete s rezolve aceast problem prin impunerea unei limite pentru rata de transfer atunci cnd numrul de imagini acumulate n coada de ateptare depete un anumit prag. Testele au fost repetate n aceleai condiii, dar de aceast dat cu mecanismul de control al benzii prezent. Dup cum era de ateptat pe Windows si MacOS unde aplicaia s-a comportat bine iniial nu s-a observat nici o modificare, dar pe Linux mbuntirile sunt vizibile. n Figura 5.6 este reprezentat evoluia n timp a dimensiunii cozii de ateptare care dup o cretere iniial scade, iar dimensiunea ei se stabilizeaz sub valoarea de 20 de elemente, corespunztoare unei ntrzieri mici, mai mic de o secund.

Universitatea Petru Maior 2006

Capitolul 5 Testarea performanelor

36

Figura 5.5 - Variaia ratelor de intrare i ieire pe platforma Linux n prezena controlului de banda

Figura 5.6 Dimensiunea cozii de ateptare pe platforma Linux n prezena controlului de banda

Universitatea Petru Maior 2006

Capitolul 6 Concluzii

37

Capitolul 6 Concluzii
Aplicaia realizat demonstreaz aplicabilitatea tehnologiilor Web n implementarea unor soluii performante ntr-un domeniu diferit de cel pentru care au fost concepute. Toate cerinele iniiale au fost realizate. Aplicaia este portabil, ea ruleaz fr nici o modificare a codului pe mai multe platforme. A fost testat cu succes pe trei sisteme de operare diferite Windows, Linux, MacOS oferind performane apropiate, fr nici o degradare a caracteristicilor. Acesta este un avantaj major deoarece mai ales din punct de vedere comercial pentru c o aplicaie portabil se adreseaz unui segment mai larg de utilizatori. Aplicaia asigur interfaa dintre utilizator i sistemul de monitorizare i control ea contribuind foarte mult la uurina n utilizarea a acestuia. innd cont de acest aspect interfaa grafic a fost astfel proiectat nct s fie particularizabil, din mai multe puncte de vedere, ea putnd fi uor adaptat conform cu nevoile utilizatorului contribuind astfel la utilizarea eficient a sistemului. A treia cerina pentru aplicaie era s ofere posibilitatea vizualizrii mai multor fluxuri video n timp real. Acest lucru este posibil graie mecanismul de control al benzii implementat, a crui eficien a fost demonstrat prin msurtori. n acelai timp aplicaia este foarte flexibil datorit structurii sale modulare. Funcionalitatea acesteia este grupat n mai multe componente independente accesibile printr-un set de interfee bine definite. n orice moment oricare dintre componente poate fi nlocuit i n condiiile n care se pstreaz neschimbat interfaa acesteia, funcionarea aplicaiei nu va fi deloc afectat. Independena componentelor permite chiar reducerea sau completarea funcionalitii conform cu nevoile specifice ale utilizatorilor doar prin eliminarea sau adugarea de componente.

Universitatea Petru Maior 2006

Bibliografie

38

Bibliografie
1. Alan Grosskurth, Ali Echihabi, Concrete Architecture of Mozilla. 2. Doug Turner, Ian Oeschger, Creating XPCOM Components, Brownhen Publishing, 2003. 3. Nigel McFarlane, Rapid Application Development with Mozilla, Prentice Hall, 2003. 4. Danny Goodman, JavaScript Bible, Hungry Minds Publishing, 2001 5. Gilorien, DHTML and JavaScript, Prentice Hall. 6. http://www.mozilla.org/projects/nspr/reference/html/index.html

Universitatea Petru Maior 2006