Modele de reprezentare a contextului i mecanisme de descoperire dinamic a elementelor de context

- Proiect Idei cod 1062 / 2008 -

Autori: Marcel Cremene, Anca Raru, Iulian Bena, Valeriu Todica, Costin Miron, Alin Drimu

Data: 31.10.2008 Versiune: Final

Cuprins: Modele de reprezentare a contextului i mecanisme de descoperire dinamic a elementelor de context ........................................................................................................ 1 - Proiect Idei cod 1062 / 2008 -................................................................................... 1 1 Introducere .................................................................................................................. 4 1.1 Situarea raportului n contextul proiectului.......................................................... 4 1.2 Concepte utilizate................................................................................................. 4 1.3 Funciile unui sistem de descoperire automat a elementelor de context ............ 6 1.4 Organizarea raportului.......................................................................................... 7 2 Contextul: definire i modelare................................................................................... 8 2.1 Modelarea contextului.......................................................................................... 8 2.2 Caracteristici ale modelelor de context ................................................................ 8 2.2.1 Compoziia distribuit................................................................................... 9 2.2.2 Validarea ....................................................................................................... 9 2.2.3 Cantitatea i calitatea informaiei.................................................................. 9 2.2.4 Completitudinea.......................................................................................... 10 2.2.5 Suportul pentru raionare ............................................................................ 10 2.3 Principalele clase de modele .............................................................................. 10 2.3.1 Modele bazate pe perechi atribut-valoare ................................................... 11 2.3.2 Modele bazate pe tehnologie web............................................................... 12 2.3.3 Modele ce folosesc scheme de marcare ...................................................... 13 2.3.4 Modele grafice ............................................................................................ 19 2.3.5 Modele bazate pe logic.............................................................................. 21 2.3.6 Modele orientate obiect............................................................................... 23 2.3.7 Modele bazate pe ontologii......................................................................... 24 2.4 Comparaie ntre clasele de modele de context.................................................. 28 2.5 De ce sunt potrivite ontologiile n reprezentarea contextului?........................... 29 2.5.1 Raionarea ontologic ................................................................................. 29 3 Mecanisme de descoperire a contextului .................................................................. 32 3.1 Protocoale de descoperire a contextului............................................................. 32 3.1.1 R-CDP......................................................................................................... 32 3.1.2 Directed diffusion ....................................................................................... 34 3.1.3 SPIN............................................................................................................ 37 3.1.4 Filtre Bloom ................................................................................................ 39 3.2 SOCAM (Service-Oriented Context-Aware Middleware)................................. 39 3.3 Context Toolkit .................................................................................................. 40 3.4 SCI...................................................................................................................... 40 3.5 Concluzii ............................................................................................................ 40 4 Observarea contextului n cazul aplicaiilor adaptive implementate ........................ 42 4.1 Observarea contextului n cazul platformei SOA .............................................. 42 4.1.1 Scenariu....................................................................................................... 42 4.1.2 Reprezentarea contextului........................................................................... 42 4.1.3 Detectarea contextului ................................................................................ 43 4.1.4 Transmiterea contextului ............................................................................ 43 4.2 Observarea contextului n cazul platformei de ageni........................................ 45 2

4.2.1 Reprezentarea preferinelor utilizatorului ................................................... 45 4.2.2 Mecanisme de descoperire a preferinelor .................................................. 46 4.2.3 Soluii propuse ............................................................................................ 47 Folosirea unui sistem multiagent este justificat de faptul c exist pri componente cu roluri specifice, cu necesiti de resurse de calcul diferite i distribuite spaial (chiar mobile), relativ autonome. ................................................................................................ 57 Limbajul de interogare Jadex (Jadex Query Language) ................................................... 57 4.3 Observarea contextului in cazul platformei WComp......................................... 57 4.3.1 Arhitectura aplicaiei realizate .................................................................... 57 4.3.2 Modelarea i observarea contextului .......................................................... 58 4.3.3 nregistrarea dispozitivelor ......................................................................... 59 4.3.4 Observarea i filtrarea contextului .............................................................. 60 4.3.5 Testarea aplicaiei ....................................................................................... 60 5 Concluzii i dezvoltri viitoare ................................................................................. 62 Bibliografie ....................................................................................................................... 64

1 Introducere
Acest raport i propune s prezinte o serie de soluii propuse pentru problema modelrii contextului, respectiv a descoperirii dinamice a elementelor de context. Totodat, soluiile propuse de noi vor fi comparate cu soluiile existente la ora actual n acest sens.

1.1 Situarea raportului n contextul proiectului

Obiectivul acestui raport este stabilirea unui model de reprezentare a contextului i a unor mecanisme de descoperire automat a acestuia, adic n principal obiectivul O2/2008 i o partea din obiectivul O3/2008. Activitile asociate acestui obiectiv sunt urmtoarele: 2.1. Studiul de modele de reprezentare a contextului i de soluii de descoperire automat a contextului. 2.2. Propunerea unei metode de descoperire automat a contextului pe baza caracteristicilor serviciului. 2.3. Implementarea metodei propuse i integrarea acesteia n platforma de test realizat la obiectivul 1/ 2008. 3.1. Testarea de scenarii de adaptare complexe. 3.2. Interpretarea rezultatelor i redactarea de articole. 3.3. Propuneri de optimizare pe baza rezultatelor obinute. ntrebrile eseniale legate de tema acestui raport sunt urmtoarele: - Ce nelegem prin context? Din ce este compus acesta? - Ce probleme ridic modelarea contextului? Ce fel de modele de context exist, ce avantaje/dezavantaje prezint acestea? - Ce nelegem prin observarea dinamic a contextului? Ce metode/soluii exist la ora actual? Ce inconveniente prezint acestea? - Care este problema tiinific pe care o tratm? n ce const particularitatea i originalitatea soluiei noastre?

1.2 Concepte utilizate

Sistem autonom. Un sistem poate fi autonom n sine ci numai fa de un anumit lucru (o anumit problem). De exemplu, un avion poate avea o autonomie de zbor de 6 ore (nu necesit alimentare) dar nu este neaprat autonom fa de pilotul su (adic nu zboar unde vrea el). n modul pilot automat, acelai avion are o autonomie fa de comenzile pilotului dar nu are libertatea de a-i alege singur ruta. Domeniul, nc n curs de maturizare, numit Autonomic Computing, i propune ca prim obiectiv rezolvarea problemei gestiunii complexitii sistemelor: To deal with the increasing business, system, and technical complexity of computing systems, devices, networks and applications must learn to manage themselves in accordance with high-level guidance from humans (lozica conferinei ICAC08 pe tema Autonomic Computing). Utilitatea unui sistem autonom provine din aceea c acesta 4

este capabil s rezolve fr intervenie uman o anumit problem. Din contr, aceeai problem necesit intervenia unui operator uman n cazul unui sistem neautonom. Gestiunea complexitii este o consecin a faptului c anumite probleme sunt rezolvate fr intervenie uman. n acelai timp, este necesar ca operatorul uman s aib control asupra sistemului dar prin interaciune pe care o numim de nivel nalt, apropiat de limbajul natural, i nu de nivel jos, adic legat de detaliile interne ale sistemului. Context. Contextul este, la limit, ntregul univers. Fiind imposibil s lucrm practic un astfel de concept fr limite, n practic, contextul se reduce la cteva elemente care caracterizeaz mediul nconjurtor (ex. poziie, temperatur, luminozitate, ambian etc.). Aceste elemente se selecteaz n general de ctre un operator uman pe baza semnificaiei lor fa de un sistem. Sistem senzitiv la context. Un sistem senzitiv la context este un sistem compus din componente hardware i software, care reacioneaz la mediul su nconjurtor numit context. Senzitivitatea sistemului poate fi neleas prin analogie cu senzitivitatea organismelor biologice. Astfel, un sistem senzitiv la context posed anumite componente specializate cum ar fi: a) Componente-senzori (analog organelor de sim), care achiziioneaz date despre context, b) Componente de analiz i decizie (analog creierului) c) Componente-efector care permit efectuarea unor aciuni interne (n sistem) i/sau externe, asupra contextului, (analog muchilor). Sistem senzitiv n mod autonom la context. Conform definiiei unui sistem autonom, autonomia apare atunci cnd o problema care era rezolvat nainte de ctre un operator uman, este acum automatizat deci o rezolv maina de calcul fr intervenie uman. Activitile principale care sunt rezolvate de ctre dezvoltator n cazul sistemelor senzitive la context neautonome sunt urmtoarele: a) Stabilirea i modificarea contextului, ceea ce nseamn determinarea acelei pri din univers care este semnificativ pentru sistem. Exist o submulime a acestei pri semnificative: partea semnificativ i sesizabil. De exemplu, dac temperatura i presiunea atmosferic sunt aspect semnificative pentru un sistem dar posedm numai un senzor de temperatur atunci contextul este determinat numai de temperatur. b) Scrierea i modificarea de politici de adaptare (reguli i strategii). Un sistem senzitiv la context posed o senzitivitate autonom dac sistemul respectiv automatizeaz cel puin parial activitile descrise mai sus. Descoperire autonom a contextului. Prin descoperirea autonom a contextului nelegem automatizarea activitii, specific umane, de determinare a elementelor din univers care sunt semnificative pentru un sistem senzitiv la context. Pentru ca acest lucru s fie posibil, conceptul de semnificaie trebuie s fie neles de ctre main. Descoperirea autonom a contextului se poate nelege, de exemplu, printr-o analogie cu organismul uman care este dotat cu un set finit de senzori ce percep n mod egocentric universul. O alt variant este ca senzorii s fie distribuii n mediul nconjurtor, disponibili n funcie de localizare. Acest lucru este posibil, de exemplu, ntr-o cas inteligent. 5

O posibil metod pentru descoperirea autonom a contextului, bazat pe ipoteza senzorilor distribuii, este urmtoarea: - Se presupune c n mediu exist senzori distribuii care pot fi accesai, - Se definete un protocol de descoperire a senzorilor disponibili din apropiere, - Senzorii emit att informaii despre mediu ct i informaii despre semnificaia lor, altfel spus sunt descrii d.p.d.v. semantic, - Pe baza informaiei semantice i pe baza semanticii interne a sistemului (care se presupune a fi descris), se determin care dintre senzorii descoperii sunt semnificativi pentru sistemul respectiv, - Se stabilete conexiunea cu senzorii selectai ca fiind semnificativi i se colecteaz date, datele colectate se folosesc de ctre componentele de analiz i decizie (creierul sistemului senzitiv).

1.3 Funciile unui sistem de descoperire automat a elementelor de context

Pentru a nelege mai clar modul particular n care privim problema observrii contextului n raport cu tema proiectului, este necesar s reamintim justificarea introducerii acestei probleme n propunerea de proiect. Adaptare static (la design sau implementare) System adaptiv CE? Adaptare dinamic (la runtime) CUM? Bazat pe un mecanism de generare de noi politici (ex. abordare model ServiciuContext)

Bazat pe politici de adaptare definite a priori (ex. EventCondition-Action)

Abordarea bazat pe un model ServiciuContext, probleme: P1. Observarea ansamblului Serviciu-Context P2. Gsirea de soluii de adaptare a Serviciului la Context

Figura 1.1. Problema observrii contextului n raport cu tema proiectului

Figura 1.1 ilustreaz plasarea temei generale a proiectului, care este propunerea unei platforme sau sistem de reconfigurare dinamic i autonom a serviciilor. Aa cum putem observa din aceast figura, ne intereseaz sistemele adaptive n mod dinamic, adic n timpul execuiei, care se bazeaz pe un mecanism de generare de noi politici de adaptare. Dup studierea mai multor lucrri din domeniu, concluzia la care am ajuns este c autonomia adaptrii presupune existena unui mecanism de generare de noi politici (reguli, strategii) de adaptare, astfel nct sistemul s poat s se adapteze i la stri neprevzute ale contextului. n teza [Crem05phd] am propus o abordare care se baza pe modelul ansamblului Serviciu-Context. O condiie esenial pentru ca aceast abordare s funcioneze este ca acest ansamblu Serviciu-Context s poat fi observat n mod dinamic, n timpul execuiei. Din studiile efectuate asupra problemei descoperirii contextului, i n conformitate cu aceeai abordare, propus n teza [Crem05phd], a rezultat faptul c exist dou probleme eseniale distincte legate de observarea contextului, enunate mai jos. P1) Determinarea profilului P al unui serviciu S, dac se cunosc arhitectura intern a serviciului i profilele componentelor sale interne Ci. Acest lucru este necesar deoarece, conform abordrii din [Crem05phd], tocmai profilul unui serviciu este cel care face legtura dintre serviciu S i contextul sau C. Aceast problema este una de compunere a profilelor i implicit a contextelor mai multor componente. P2) Identificarea surselor de informaie (senzori, servicii de observare) care pot furniza informaii despre contextul indicat de ctre profilul P al serviciului S. Aceast problem este apropiat de domeniul numit Context Discovery. Bineneles, exist i o a treia problem esenial, P3), care este modelarea contextului. Aceast problem este cvasi-independent de celelalte evocate anterior, P1 i P2 dar ea trebuie s faciliteze pe ct se poate rezolvarea acestora. n teza [Crem05phd] sa propus un model de reprezentare a ansamblului Serviciu-Context bazat pe un graf dar este necesar s comparm acest model cu alte modele existente pentru o eventual mbuntire a acestuia.

1.4 Organizarea raportului

Acest raport este organizat n felul urmtor: capitolul urmtor face o trecere n revist a mai multor modele de context. Capitolul trei prezint un studiu asupra descoperirii i compunerii contextului. Capitolul patru ilustreaz modul n care observarea contextului intervine n aplicaiile pe care le-am dezvoltat. Raportul se ncheie cu discuii i concluzii.

2 Contextul: definire i modelare

n acest capitol descriem caracteristicile principalelor modele de context. Aceste modele sunt grupate n clase. n continuare descriem aceste clase i prezentm cteva exemple semnificative pentru fiecare din aceste clase. n final, prezentm o comparaie ntre aceste clase de modele de context pe baza unor criterii de analiz.

2.1 Modelarea contextului

Contextul este asociat, n general, cu ideea de mediu nconjurtor. n experiena noastr de zi cu zi ca oameni, inem seama de context n cel puin dou situaii: cnd selectm din mediu doar informaiile de care avem nevoie la acel moment i n acel loc i cnd dorim s acionm ct mai adecvat situaiei n care ne aflm. Noiunea de context n cazul unui sistem de calcul a fost deja prezentat n subcapitolul 1.2. Pentru ca un astfel de sistem de calcul s se comporte adecvat informaiilor din mediu, pe lng senzori i "creier electronic" are nevoie de o reprezentare a contextului ntr-un mod pe care sistemul de calcul l nelege. Odat modelat, contextul poate fi: completat cu informaia preluat de la senzori; stocat (pentru a i se analiza evoluia n timp sau pentru utilizare ei ulterioar); actualizat sau optimizat; folosit pentru deducerea elementelor de context de nivel ridicat pentru a rspunde ntr-un mod ct mai apropiat de cel presupus de utilizator la situaia dat. n aceast lucrare, prin context de nivel ridicat se nelege contextul abstract. Spre deosebire de acesta, contextul de nivel sczut este preluat direct de la senzori. Exemple de context de nivel ridicat sunt situaiile din realitate, pentru a cror definire este necesar informaia de la mai muli senzori. De pild, se poate deduce c o persoan doarme din faptul c se afl n dormitor, ntins pe pat, iar lumina din camer este stins. n acest exemplu, contextul de nivel sczut este format din elementele localizare, poziie (ntins pe pat) i luminozitate, n timp ce activitatea (doarme) reprezint contextul de nivel ridicat.

2.2 Caracteristici ale modelelor de context

n continuare se face o comparaie a modelelor de context din perspectiva urmtoarelor caracteristici, avnd ca punct de pornire lucrarea de referin [Thom04]: 1. compoziia distribuit; 2. validarea; 3. cantitatea i calitatea informaiei; 4. completitudinea; 5. suportul pentru raionare.

2.2.1 Compoziia distribuit

Compoziia distribuit se refer la capabilitatea unui model de context de a facilita: unificarea modelului (i a datelor pe care le conine) din pri de model i/sau modificarea (suprascrierea) lui (i/sau a datelor pe care le conine) n diferitele noduri ale reelei distribuite ale unui sistem omniprezent. Dispozitivele mobile au limitri importante a capacitii de prelucrare i stocare a datelor, a debitului pe canalele de comunicaii i a alimentrii cu energie, comparativ cu calculatoarele personale. Mai mult, din cauza mobilitii, acestea sunt obligate s cunoasc valorile actuale ale elementelor de context i s fac fa variaiei n timp i n spaiu a resurselor disponibile de calcul, reea, alimentare etc. Ca urmare, este important ca modelele de context s poat fi compuse i valorile lor administrate n cadrul sistemului distribuit, n fiecare nod. De exemplu, fie un sistem distribuit format dintr-un telefon mobil i un calculator legate ntr-o reea local (prin wireless LAN). Ne intereseaz elementul de context memorie_disponibil pe telefon. Prelum o imagine cu camera foto a telefonului mobil, care va avea o anumit dimensiune n bii. O aplicaie manager de memorie ruleaz pe telefon. Se pune problema locului de stocare a imaginii. La momentul iniial, n memorie_disponibil este menionat doar memoria intern cu o valoare de 64 MB. Dac adugm o memorie extern sau dac accesm memoria calculatorului prin wireless LAN de pe telefonul mobil, atunci aceste resurse de memorie trebuie s fie actualizate n modelul de context. De asemenea, trebuie actualizate valorile acestor resurse de memorie (ex. capacitate de memorare de 1GB pentru memoria extern) pentru ca aplicaia de gestiune a resursei de memorie s decid unde poate stoca imaginea n funcie de spaiul de memorie pe care l ocup n memorie.

2.2.2 Validarea
Validarea se refer la capabilitatea unui model de context de a permite verificarea consistenei structurii lui i a tipului de date i a domeniului valorilor datelor din model. Modelele de context pot s ajung s fie inconsistente datorit evoluiei n timp a modelului i a valorilor lui cu att mai mult cu ct acestea sunt compuse din mai multe pri n nodurile sistemului distribuit. Cu ct contextul pe care vrem s l modelm este mai complex (este compus din mai multe elemente de context legate ntre ele), cu att validarea ne poate ajuta s evitm erorile de modelare i utilizare a modelului. De exemplu, se pune problema schimbrii unui model de context cu unul nou, ambele reprezentate sub form de fiier XML. Dac n fiierul cu modelul nou una dintre etichete (tag-uri) nu se nchide, atunci noul model nu va putea fi considerat validat. O cauz posibil a acestei situaii ar fi o transmisie de date cu erori. n acest caz avem de a face cu o validare de tip sintactic.

2.2.3 Cantitatea i calitatea informaiei

Cantitatea i calitatea informaiei se refer la capabilitatea unui model de context de a exprima caracteristici ale cantitii i calitii informaiei. Valorile pe care le au elementele de context din model sunt preluate de la senzori. Unii dintre acetia produc o cantitate mai mare de informaie dect alii, cum este cazul unei camere n care exist un senzor care raporteaz poziia unei persoane (parametru care se modific rapid) i un senzor de temperatur (parametru cu modificri lente). De asemenea, fiecare dintre senzori are caracteristici ale calitii cum ar fi: o anumit rezoluie, precizie, grad de ncredere, durat de valabilitate a valorii citite, care determin calitatea informaiei de context. De exemplu, o persoan care se plimb ntr-un mare spaiu expoziional unde are loc un trg de carte caut o anumit editur cu ajutorul dispozitivului ei mobil. Sistemul de localizare din pia este considerat mai de ncredere dect sistemul global de poziionare (GPS) deoarece ofer o precizie mai mare.

2.2.4 Completitudinea
Completitudinea se refer la capabilitatea unui model de context de face fa lipsei unor date din model. Este posibil ca din diverse cauze informaia s nu ajung de la senzori la dispozititivul mobil. Modelul de reprezentare a contextului trebuie s ofere suport pentru rezolvarea acestor situaii. De exemplu, energia electric din bateria unui senzor de temperatur dintr-o reea de senzori ce monitorizeaz o pdure s-a terminat. Putem considera o medie ntre ultima valoare de temperatur citit i valorile de la senzorii de temperatur din proximitatea senzorului pn la nlocuirea sursei de alimentare. Este important ca modelul de context s exprime aceast lips.

2.2.5 Suportul pentru raionare

Suportul pentru raionare se refer la capabilitatea unui model de context de a facilita determinarea de informaii noi din informaiile existente n modelul de context. Putem distinge dou tipuri de modelele: cele n care valorile provin doar din surse externe modelului (de la senzori prin detecie sau de utilizatori prin declaraie) i cele n care valorile pot proveni i din prelucrarea informaiilor existente deja n modelul de context prin operaii logice. Pentru a ajuta la aceasta, n unele modele se permite exprimarea diferitelor relaii ntre elementele de context (ierarhice, de apartenen etc.). De exemplu, din faptul c un sistem de localizare detecteaz o persoan ntr-o ncpere i din faptul c ncperea este ntr-un anumit imobil, se poate deduce, pe baza tranzitivitii (reprezentat n mod specific n model), c acea persoan se afl i n acel imobil, ncperea fiind o parte a imobilului (relaia de incluziune fiind indicat n modelul de context).

2.3 Principalele clase de modele

n acest subcapitol analizm clasele de modele prezentate n [Thom04], la care adugm clasa de modele bazate pe tehnologie web [Bill93]. Facem analiza ntr-o ordine 10

care merge de la simplu la complex, urmrind cum au fost abordate caracteristicilor enunate mai sus. Precizm c n urma analizrii caracteristicilor, se observ ca unele sunt satisfcute, iar altele nu. Dar exist cteva situaii n care caracteristicile ar putea s fie satisfcute, dei modelele nu au fost gndite n acest scop, fapt pe care l vom evidenia prin formulri de genul "ar putea".

2.3.1 Modele bazate pe perechi atribut-valoare

Este cea mai simpl modalitate de reprezentare a contextului. Const n reprezentarea fiecrui parametru ce descrie contextul ca o pereche atribut-valoare, n final rezultnd o list neierarhic de perechi atribut-valoare. Un exemplu este: temperatura = 21C, zgomot_ambiental = 50 dB. Compoziia distribuit s-ar putea face doar la nivelul instanelor. Un exemplu ar fi pentru elementul de context temperatura. Astfel, mai nti aplicaia citete datele de la un server (nod de reea) la care dispozitivul mobil este conectat. Valoarea temperaturii, n acest nod, este 21C. Dac s-ar schimba serverul (aplicaia s-ar conecta ntr-un alt nod din reea) valoarea citit pentru temperatur ar fi 20C. Atunci acea nou valoare ar putea deveni valoarea curent pentru elementul de context temperatura. Validarea nu poate fi fcut, deoarece lipsete definirea termenilor i a domeniilor de valori ai parametrilor. Cantitatea i calitatea informaiei pot fi considerate, dar n lipsa unei structuri ierarhice este dificil de gestionat. Completitudinea se poate considera la nivelul instanelor. Un exemplu ar fi situaia n care valoarea elementului de context temperatura nu s-ar mai ti odat cu deconectarea temporar a senzorului de temperatur, caz n care se poate folosi ca valoare curent ultima valoare citit de senzor. Aceast soluie de reprezentare nu prezint suport pentru raionare. Exemple. Este important ca datele despre context s fie sub un acelai format (n toate nodurile reelei distribuite) i s fie uor de folosit de diverse unelte soft ce ruleaz pe platforme diferite. Una dintre primele propuneri de modelare a contextului cu perechi atribut valoare, care rezolv aceste probleme, i este atribuit n literatur lui Schilit i colaboratorilor lui [Bill93],[Bill94],[Bill95]. Acetia propun utilizarea de variabile de mediu pentru reprezentarea informaiei de context ca o soluie la cererea de adaptabilitate a aplicaiei. Detaliem modelul propus de Schilit n teza s de doctorat [Bill95]. Mai nti, el definete un obiect de date dinamic ca un container de informaii care poate stoca informaii din lumea real sau abstracte: persoane, dispozitive, echipamente, ncperi, debit, temperatur, nivel de luminozitate etc. Acest tip de obiect difer de cel definit n programarea orientat obiect, deoarece nu se aplic conceptul de motenire sau apelul de metode. Numele fiecrui atribut este un text simplu, fr a se preciza tipul de date, iar valoarea acestuia este un ir alfanumeric sau o list de astfel de iruri (cuprinse ntre ghilimele doar dac n interiorul irului se gsete simbolul acolad) ntre dou acolade i cu spaii ca elemente de delimitare, ca n exemplul din [Bill95]: {Name Badge:802} {PublicKey "R0lGODdhDAMdAc}Yd"} {With {schilit spreitzer theimer}} 11

Atributele pot fi locale sau globale. Cele globale i pstreaz semnificaia pentru mai multe obiecte. Un exemplu este Location, care se aplic att utilizatorilor ct i echipamentelor. Convenia propus de autor este ca atributele globale s se scrie ncepnd cu liter mare, celelalte atribute fiind notate cu litere mici. Obiectele pot fi refereniate n interiorul altora, ca n exemplu de mai jos, folosind numele obiectului: {operatori {utilizator:u1 utilizator:u2 utilizator:u3}} Aici, atributul operatori are ca valoare o list de trei perechi atribut-valoare, atributul fiind acelai (utilizator), valorile fiind: u1, u2, u3. Dei este un model simplu i flexibil, el impune respectarea aceleiai convenii de reprezentare, cu aceleai cuvinte cheie pentru a permite interoperabilitatea. Modalitatea de reprezentare a contextului din Mobisaic [Voel94] pornete de la ideea de variabile de mediu dinamice ce pot fi accesate i modificate pentru a se adecva mediului mobil al utilizatorului. Aceste variabile sunt atribuite utilizatorilor i locaiilor pe o perioad nelimitat, fiind modificabile doar de aplicaiile ce dein acest drept. Sintaxa propus este $(mediu.variabil), iar un exemplu este: $(bershad.Location) unde bershad este mediul, iar Location este variabila. Ei mai propun utilizarea URL-urilor dinamice pentru a gsi informaiile ce concord cu contextul n care se afl utilizatorul. Un exemplu este: http://www/offices/$(Location).html. Din acest punct de vedere, putem spune c acest model face parial parte i din clasa de modele web. Context Toolkit, discutat n [Anind00] i [Anind01], vede contextul ca avnd entiti (locuri, oameni, lucruri) i atribute. O prezentare, care este un lucru, poate fi susinut ntr-o anumit camer (atribut) i la un anumit moment de timp (alt atribut). Acest model se inspir n modelarea informaiei de context din mecanismele proiectrii grafice de unde mprumut termenul de widget. La nivelul acestuia, datele de context sunt sub form de DataObject format din nume i date, unde date poate fi o valoare sau un alt DataObject. Mai departe, aceste DataObject sunt codate XML i trimise prin HTTP. Ca urmare, putem afirma c soluia acesta beneficiaz parial i din avantajele modelelor cu scheme de marcare i cele orientate obiect.

2.3.2 Modele bazate pe tehnologie web

Fiecare entitate (persoan, loc, lucru) din model are o anumit descriere web (pagini HTML) ce poate fi accesat la o adres URL [Ghita04], [Fabi04]. Dei nu a fost prevzut iniial, acest tip de model poate rspunde la problemele formulate anterior astfel: compoziia distribuit i completitudinea este rezolvabil doar la nivel de instan (ca n exemplul cu temperatura de la clasa atribut-valoare); validarea coninutului unei pagini web se poate face pe baza structurii specifice HTML; cantitatea i calitatea informaiei pot fi, de asemenea, considerate i descrise n cadrul unei pagini web. 12

n cazul acestei clase de modele nu exist suport pentru raionare. Exemplu. n proiectul CoolTown de la HP [Tim00] ideea de baz este ca lucrurile, locurile i persoanele s aib fiecare o reprezentare web care ofer acces la alte pagini web sau la servicii. Lucrurile se identific prin etichete electronice (iButton, RFID, coduri de bare etc.), iar apoi coninutul de prezentare al fiecrui lucru, memorat sub form de pagin web, este afiat. Locurile sunt modelate astfel nct ele ofer, n plus fa de lucruri, accesul la servicii (tot prin intermediul unor pagini web), similar portalurilor web. Un exemplu, prezentat n [Tim00], este comunicarea ntre dou persoane, caz n care apelul (de tip telefonie prin Internet) va fi redirectat n funcie de resursele de comunicare aflate la dispoziia persoanei de contactat. Pentru persoane, intereseaz s se tie datele curente i mijloacele prin care se poate comunica cu ele. Mijloacele pot varia n funcie de locul n care se afl persoana i istoricul datelor. Avantajul acestei clase de modele fa de cea atribut-valoare const n faptul c se bazeaz pe tehnologia web de reprezentare (HTML) i accesare a datelor (URL) i pe unelte dedicate (editoare i respectiv navigatoare web).

2.3.3 Modele ce folosesc scheme de marcare

Specificul schemelor de marcare este structurarea ierarhic a datelor cu ajutorul unor etichete ce numesc un atribut i care cuprind (ntre cele dou marcaje, de nceput i sfrit) fie alte atribute, fie valorile acelui atribut. Un exemplu binecunoscut este limbajul de marcare XML. n cazul modelrii contextului, de obicei avem de-a face cu o structurare a prilor componente ale modelului dup anumite caracteristici comune, numite profile. Alte soluii de reprezentare sunt fie proprietare i ca urmare nu putem cunoate detaliile de realizare, fie bazate pe un numr mic de elemente de context distincte. O problem a modelelor din aceast clas este limitarea dat de utilizarea fiierelor DTD (Document Type Definitions), care nu permit redefinirea sau fuziunea noiunilor din surse diferite. Totui, compoziia distribuit este posibil n unele dintre modele i la nivel structural (de clase) prin separarea prii stabile (implicite) de partea care este posibil s se modifice i prin implementarea unui mecanism de actualizare bazat pe reguli ce sunt memorate n model (de exemplu cscp:resRule ale crei valori pot indica o fuziune sau o suprascriere a subarborilor din structura modelului de context [Henri03]). O alt soluie este nlocuirea DTD-ului cu XML Schema. Validarea este cea mai important trstur a acestor modele datorit existenei schemelor de definire i a uneltelor pentru validare ce permit verificarea tipului atributelor i, ntr-o oarecare msur, chiar a domeniului valorilor numerice a variabilei reprezentate. Cantitatea i calitatea informaiei poate fi precizat uor n asociere cu sursa care a generat-o, datorit structurii ierarhice a schemelor de marcare. Pentru completitudine aceste modele nu dau o soluie, acest criteriu trebuie s fie rezolvat de ctre aplicaia care folosete modelul. Prezena schemelor de definire (XML Schema) ar permite parial raionarea pe baza relaiilor ierarhice dintre elementele schemei de marcare.

13

Exemple. Modelele de context bazate pe scheme de marcare concur pentru a rspunde la ntrebrile: 1. cum se ierarhizeaz contextul i care sunt prile principale ale acestuia? 2. cum se menine la zi modelul? 3. cum se aliniaz standardelor existente? ConteXtML [Nick] descrie contextul folosind mesaje descrise n documente de tip XML (eXtensible Markup Language). Eticheta <context> marcheaz o pereche de date de trimis de la client i, respectiv, cerute de la server. Exemplul din [Nick] ilustreaz o actualizare pe care o face un client mobil care i comunic poziia n spaiu (cu <spatial> i subelementul <point x=... y=... z=...>) i solicit date cu privire la o dat numit landuse cu valoarea pasture: <context session="123" action="update"> <spatial proj="UTM" zone="33" datum="Euro 1950 (mean)"> <point x="281993" y="4686790" z="205" />> </spatial> <require> <note> <data name="landuse" value="pasture" /> </note> </require> </context> Elementele de context menionate n [Nick] sunt: poziia, viteza, detalii legate de persoanele implicate n activitate i alte date relevante pentru activitatea curent. Nu se pune problema actualizrii modelului i nici alinierea la vreun standard de reprezentare a datelor pentru context. Un alt exemplu este Comprehensive Structured Context Profiles (CSCP) [Held02]. Acest model este bazat pe RDF (Resource Description Framework), la fel ca CC/PP (Composite Capability/Preference Profile), de la care motenete capacitatea de interschimbare, cea de descompunere i extensibilitatea. CSCP ns permite structurarea pe mai multe nivele i are un mecanism de exprimare a preferinelor utilizatorului ce are posibilitatea atarii de condiii i prioriti atributelor entitilor. Un exemplu de profil CSCP este urmtorul [Held02]: <?xml version="1.0"?> <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cscp = "http://example.org/CSCPProfileSyntax#" xmlns = "http://example.org/SessionProfileSyntax#" xmlns:dev = "http://example.org/DeviceProfileSyntax#" xmlns:net = "http://example.org/NetworkProfileSyntax#"> <SessionProfile rdf:ID="Session"> <cscp:defaults rdf:resource= "http://localSessionContext/CSCPProfile/previous#Sessio n"/> 14

<device> <dev:DeviceProfile> <dev:hardware> <dev:Hardware> <dev:memory>9216</dev:memory> </dev:Hardware> </dev:hardware> </dev:DeviceProfile> </device> </SessionProfile> </rdf:RDF> n acest caz avem adecvare la standard, dar actualizarea modelului nu se trateaz, considernd-l fixat. Tot CC/PP se afl i la baza propunerii din [Indul03], n care se definete un set de componente i atribute care descriu contextul i relaiile dintre elementele sale componente. Exemplele de extensie ale CC/PP se refer la reprezentarea poziiei, caracteristicilor reelei, cerinelor pentru aplicaie, sesiunii curente, relaiilor i dependenelor. n continuare prezentm o parte din extensia CC/PP propus de autori pentru caracteristicile reelei (am nlocuit cu "..." detalii ale acestei scheme): [DeviceProfile [NetworkCharacteristics [DisconnectionStatus [ConnectionStatus, Disconnection Type, ...]] [NetworkInterface [QoS [Bandwidth, ...], InterfaceType, IPAddress]] ] ] n [Indul03] se evideniaz limitrile pe care CC/PP le are atunci cnd este folosit pentru modelarea contextului. Dintre acestea menionm: lipsa unor caracteristici ale informaiei de context (aspecte temporare, precizie, rezoluie, ncredere n corectitudinea informaiei, tipuri diverse de informaii); lipsa posibilitii de a defini constrngeri asupra metodei de actualizare a unui atribut sau a unei valori din profil; lipsa posibilitii de a defini constrngeri relaionale asupra existenei sau absenei mai multor atribute din profilul componentei. n [Indul03] se concluzioneaz c limitrile CC/PP nu l recomand ca cel mai potrivit pentru modelarea contextelor complexe pentru sistemele omniprezente. Pervasive Profile Description Language (PPDL) [Fers06] este o alt abordare bazat pe scheme de marcare, altele dect CC/PP. PPDL permite descrierea contextului n-dimensional sub form XML ca profile, pentru a face fa variabilitii dinamice a autodescrierii caracteristicilor dispozitivelor mobile. n lucrarea citat se prezint patru tipuri de profile: privat, public, interes i schimb de roluri. Pentru descrierea interesului se d urmtorul exemplu, n care observm dou modaliti de cutare de elemente de 15

context, dup similaritate i dup potrivire de text cu format parial necunoscut (partea marcat cu "*"): <preferences> <match element="LastName" similarity="0.76"/> <match element="FirstName" text="Mil*"/> </preferences> Avantajul PPDL este c permite o mai mare flexibilitate i ca urmare modelul poate fi cu uurin modificat. Faptul c nu folosete un standard este un dezavantaj. Proiectul Simplicity [Enrico04] rspunde cel mai bine ntrebrilor 1-3. n modelul de context folosit se propun urmtoarele soluii: 1. consider patru tipuri de profile: utilizator (User), dispozitiv (Device), serviciu (Service), reea (Network). Fiecare dintre aceste profile au n componen subelemente. De exemplu, utilizator are: identitate, contact, organizaie etc. 2. folosete XML Schema care este mai flexibil permind n plus fa de DTD extinderi ulterioare i transformri folosind XSLT. 3. modelarea contextului urmeaz metodologia 3GPP (Generic User Profile) pentru profilul utilizatorului i CC/PP pentru profilele dispozitivelor. Figura 2.1 ilustreaz gramaticile pentru diferitele profile i componente de profile ca schema XML (Schema XML).

16

Figura 2.1. Schema XML pentru descrierea utilizatorului, dispozitivelor, serviciilor i reelei [Enrico04]

Fiecare component a profilului se descrie prin atribute specifice. Exemplul pe care l reproducem mai jos este detalierea prii din schema XML pentru dispozitiv: <schema targetNamespace=http://www.ist-simplicity.org/GUP/Device xmlns="http://www.w3.org/2001/XMLSchema" xmlns:device="http://www.istsimplicity.org/GUP/Device"> . <element name="Device" type="device:DeviceType"/> <complexType name="DeviceType"> <sequence> <element name="HardwarePlatform" /> <element name="SoftwarePlatform" /> <element name="NetworkCharacteristics" /> <element name="BrowserUA" /> <element name="WapCharacteristics" /> </sequence> </complexType> . <complexType name="SoftwarePlatformType"> 17

<annotation> <documentation xml:lang="en">The SoftwarePlatform component contains properties of the device's application environment, operating system, and installed software. </documentation> </annotation> <all> <element name="AcceptDownloadableSoftware" type="boolean" inOccurs="0"/> </all> . </complexType> . </schema> Se observ c elementul Device este de tipul complex DeviceType compus din secvena de elemente HardwarePlatform, SoftwarePlatform, NetworkCharacteristics, BrowserUA, WapCharacteristics i mai apoi sunt detaliate componentele SoftwarePlatform. Alegerea acestor componente se bazeaz pe UAProf Schema de la WAP Forum. Formatul XML permite transformarea cu uurin a unui document UAProf ntr-o component de tip Device. Reproducem mai jos un exemplu de profil realizat dup gramatica prezentat n figura 2.1. Aici sunt descrise profilele User i Device n care apar identitatea (nume i prenume), informaiile de contact (email, adresa paginii Internet, numrul de telefon) ale utilizatorului i respectiv caracteristicile platformei hardware (dimensiunea ecranului, modelul etc.) ale dispozitivului: <Profile > <user: User> <user:Identity> <user:FirstName>Enrico</user:FirstName> <user:LastName>Rukzio</user:LastName> </user:Identity> <user:Contact> <user:Email>Enrico.Rukio@ifi.lmu.de</user:Email> <user:Homepage>http://www.mimuc.de</user:Homepage > <user:TelephoneWork>+49 89 21804656</user:TelephoneWork> </user:Contact> </user:User> <device:Device> <device:HardwarePlatform> <device:ScreenSize>101x80</device:ScreenSize> <device:Model>T68R1</device:Model> <device:ImageCapable>true</device:ImageCapable> <device:Keyboard>PhoneKeypad</device:Keyboard> 18

<device:Vendor>Ericsson Mobile </device:Vendor> </device:HardwarePlatform> </device:Device> .. </Profile>

2.3.4 Modele grafice

Modelele grafice fac parte din categoria metamodelelor (modele despre modele). Modelele grafice faciliteaz crearea la nivel de concept (pe suport de hrtie sau folosind unelte software specializate) a modelelor sub form vizual. Mai apoi acestea sunt implementate fie n limbaj de programare sau marcare, fie ca elemente specifice bazelor de date (tabele, relaii, interogri etc.). Exist posibilitatea ca n urma proiectrii cu o unealt grafic s se translateze modelul dintr-o reprezentare grafic ctre o reprezentare a contextului uor de folosit de ctre un sistem de calcul (cum ar fi un fiier XML). Un exemplu de model grafic, dar nespecific modelrii contextului, este UML (Unified Modeling Language) care folosete diagrame ca instrumente grafice de proiectare. Deoarece modelele din aceast clas vor primi o form concret ulterior, la implementare, criteriile 1-5 din subcapitolul 2.2 nu pot fi aplicate. Exemple. Context Modelling Language (CML) este un model ORM extins pentru a fi utilizat n reprezentarea contextului. El este prezent ntr-o serie de articole (din care citm doar [Sheng05], [Rob07] n care autorii pleac de la un model folosit pentru proiectarea grafic a bazelor de date ORM (Object-Role Modeling). Prin elipse se reprezint tipuri de obiecte sau fapte, prin dreptunghiuri rolurile, iar relaiile leag tipurile de fapte de roluri. CML extinde notaiile iniiale prin setul descris prin exemple n figura 2.2. Sunt astfel descrise urmtoarele relaii abstracte: de tip static (atribute ale unui obiect); de tip profil (stabilesc relaiile ntre un obiect i utilizatorul lui); specifice senzorilor (indic valoarea curent a senzorului care msoar un anumit element de context pentru un anumit persoan); de tip temporal (indic momentul la care se desfoar o activitate); de tip derivare (deducerea unei anumite relaii pe baza altor relaii); dependena faptic (stabilete o legtur ntre dou fapte); de tip adnotarea calitii (avnd parametrii: prospeimea datelor (momentul de timp al evalurii), precizia (eroarea standard)) i ambiguitatea (permite notarea gradului certitudinii unei relaii). ntr-o lucrare mai recent [Rob07] autorii caut o soluie de reprezentare a modelului grafic folosind fie ontologii (RDF-OWL), fie XML. Ei aleg XML artnd c translatarea CML la RDF/OWL s-ar face cu pierderi, noul limbaj numindu-se XCML.

19

Tip de fapt static is of type Device (id) Tip de fapt profil permitted to use Person (name) Device (id) s Device Type (code)

Tip de fapt derivat Person (name)

located at

located at

Location (name)

Device (id) Dependen faptic

Tip de fapt de la senzori located at Person (name) Tip de fapt temporal Person (name) engaged in Activity (name) Location (name)

engaged in Activity (name) [] located at Location (name)

Person (name)

[] Adnotarea calitii Production Time (timestamp) Freshness Accuracy Standard Error (nr)+

Person (name) located at Tip de fapt ambiguu sau alternativ Certainty

Location (name)

Probability (nr)+

a Device (id) located at Location (name)

Figura 2.2. Exemple de modelare n Context Modelling Language [Henri03], [Henri06]

ContextUML [Sheng05] const ntr-un metamodel i o notaie ce descriu att contextul ct i modalitatea de rspuns la context a aplicaiei. n continuare detaliem modelul ce definete sintaxa abstract a limbajului i notaia ce definete formatul concret al limbajului pentru reprezentarea contextului. La nivel abstract, contextul este modelat prin clasa Context care poate s provin din mai multe surse ContextSource, ca n figura 2.3. Ambele clase de mai sus au cte dou clase derivate: AtomicContext i CompositeContext, respectiv ContextSource i ContextServiceCommunity.

20

Context

* *

SourceAssignment

1..*

ContextSource

* ContextSource ContextServiceCommunity

AtomicContext

CompositeContext

* Member

Figura 2.3. Metamodelul contextului descris cu ContextUML [Sheng05]

Notaia pentru reprezentarea contextului se reprezint tot cu clase UML prin stereotipul conuml.atomicContext, dac este atomic (adic nu mai poate fi desfcut n pri componente) i cu conuml.compositeContext dac este compus. Contextul atomic are dou atribute: nume context i surs context, pe cnd contextul compus are doar un singur atribut.

2.3.5 Modele bazate pe logic

Faptele, regulile i expresii logice sunt conceptele fundamentale ale unui model bazat pe logic. Elementele de context sunt reprezentate n dinamica evoluiei lor ca lund noi valori (provenite de la senzori) care determin, n funcie de reguli, anumite valori ale altor elemente de context. Aceste modele ar putea permite compoziia distribuit la nivelul instanelor. Lipsa mecanismelor de verificare a consistenei definiiilor din model face ca validarea s fie dificil. Cantitatea i calitatea informaiei i completitudinea ar putea fi tratate, ns soluiile propuse pn acum de ctre cercettorii din domeniu nu au avut ca scop satisfacerea acestor caracteristici. Suportul pentru raionare este o caracteristic forte a acestei clase de modele de context deoarece reprezentarea contextului prin fapte legate ntre ele prin reguli i expresii logice uureaz aplicarea unui demers logic (de exemplu, deducia valorii unui element de context). Exemple. Unul dintre primele modele bazate pe logic este cel propus n [McCar93], [McCar97]. Aici se descrie contextul abstract prin obiecte de prima clas. Relaia de baz ist(c,p) arat c propoziia p este adevrat n contextul c. Chiar dac are un mecanism de deducere a unui context din altul, acest model este prea simplu i prea general pentru a fi utilizat n sisteme omniprezente. Dintre modelele mai noi prezentm LogicCAP (bazat pe Prolog) [Loke04], [Loke06] i un altul care descrie contextul prin situaii exprimate prin operatori temporali [Brdi06]. S.W. Loke propune o extensie a Prolog-ului numit LogicCAP [Loke04], [Loke06] pentru programarea aplicaiilor senzitive la context n care situaiile sunt entiti de prim clas. Regulile descriu n mod natural, spune autorul, situaiile. La apariia unei 21

situaii, anumite condiii i constrngeri sunt activate, ca n exemplul de mai jos ce descrie o ntlnire care are loc acum: predicatele senzorului sunt: - location*(E,L) poziia entitii E n variabila L; - diary*(E, Event, entry(StartTime, Duration)) intrrile din jurnal pentru entitatea E i care se potrivesc cu evenimentul Event; - people in room*(L,N) numrul de oameni N, dintr-un loc L; - current time*(T) timpul curent; constrngerile pe care situaia (n exemplul de mai jos o ntlnire) le impune asupra valorilor citite de la senzorilor sunt descrise logic astfel: situation program meeting1: in_meeting_now(E) -e-> with_someone_now(E), has_entry_for_meeting_in_diary(E). with_someone_now(E) -e-> location*(E,L), people_in_room*(L,N), N > 1. has_entry_for_meeting_in_diary(E) -e-> current_time*(T1), diary*(E,meeting,entry(StartTime,Duration) ), within_interval(T1, StartTime, Duration). nelegem definirea situaiei in_meeting_now ca fiind condiionat de with_someone_now(E) i has_entry_for_meeting_in_diary(E), care la rndul lor sunt declarate ca fiind condiionate de prezena entitii E n locaia L i a unui numr de cel puin dou persoane n acea locaie: location*(E,L), people_in_room*(L,N), N>1. Autorii articolului [Brdi06] propun modelarea contextul ca situaii exprimate prin operatori temporali i apoi implementarea lor determinist cu ajutorul reelelor Petri i probabilistic cu modele Marcov ascunse. Ei definesc o situaie ca o stare temporar a contextului i exemplific cu o prezentare n care se pun ntrebri ca n figura 2.4:
meets Prezentare meets

START

meets

meets

END

meets

Formulare ntrebare

meets

Figura 2.4. Exemplu de context modelat cu operatori temporali [Brdi06]

22

2.3.6 Modele orientate obiect

Modelarea orientat obiect a contextului caut s exploateze avantajele date de ncapsulare i reutilizare. Astfel nct detaliile procesrii datelor de context sunt ncapsulate la nivelul obiectului i sunt ascunse altor componente care au acces la acele informaii doar prin intermediul unei interfee. Compoziia distribuit este facilitat de modelarea orientat obiect, deoarece att elementele de context (modelate sub form de clase) ct i instanele acestora (obiectele) pot fi gestionate de un sistem distribuit. Validarea structurii se face de ctre compilator, iar a valorilor instaniate la rulare de ctre mediul de execuie. Cantitatea i calitatea informaiei i completitudinea sunt rezolvate prin adugarea de parametri specifici i prelucrarea lor de ctre aplicaia care folosete modelul. Raionarea se face n pri ale programului (metode) unde instruciunile condiionale (dac atunci) testeaz prin construcii logice valorile atributelor obiectelor de context i rspund prin apeluri la alte metode din program. Exemple. n proiectul TEA contextul este modelat pornind de la trsturi (cues) (vezi figura 2.5), care prelucreaz datele brute obinute de la senzori i dau rezultatul spre utilizare ctre nivelul de mai sus, unde se gsete reprezentarea abstract a contextului. Dintre trsturile menionate de autori ca exemple amintim: valoarea medie, deviaia standard, frecvena de baz, derivatele de ordinul nti. Reprezentarea contextului const aici dintr-un set de vectori bidimensionali. Fiecare vector are o valoare simbolic prin care este descris situaia i o valoare numeric ce exprim certitudinea cu care persoana sau utilizatorul se afl n acea situaie [Schm01].
Aplicaii i scrpturi software Spaiul de tuple ale contextului Context Spaiul de tuple ale trsturilor Trs- Trs- Trs- Trs- Trs- Trstura tura tura tura tura tura 1,1 1,2 1,n 2,1 2,2 2,n Senzor 1 Senzor 2 Trs- Trs- Trstura tura tura n,1 n,2 n,n Senzor n

Figura 2.5. Arhitectura pe nivele a sistemului senzitiv la context din proiectul TEA [Schm01]

Modelul de obiect senzitiv la context propus n [Fitz02] vede contextul ca fiind un consumator de date de la senzori pe care le prelucreaz, le reprezint i n final aplic un

23

set de reguli de reacie care produc o modificare a mediului nconjurtor prin intermediul actuatorilor, aa cum se poate observa n figura 2.6. Reprezentarea contextului ntr-un obiect senzitiv se face ierarhic pe baza paradigmei CxBR (Context Based Reasoning), care afirm c aciunile pe care le face o entitate sunt n mare msur dependente de contextul curent al acelei entiti. Utilizarea CxBR face s scad numrul de reguli de inferen necesare pentru a determina aciunea de ntreprins ntr-o anumit situaie.
Mediu extern Senzor Preluarea Reprezen- Motor de valorilor de tarea inferen la senzori Contextului

Coordonare prin modificarea mediului Actuator

Consum

Produce

Senzor Obiect senzitiv Eveniment

Actuator

Figura 2.6. Model de obiect senzitiv la context [Fitz02]

ubi-UCAM 2.0 este un model de aplicaie senzitiv la context unificat [Oh05] n care se propune un alt model orientat obiect al contextului. Contextul unificat numit 5W1H este constituit din ase obiecte care sunt desemnate dup partea din context pe care o acoper, astfel: Who (cine) stocheaz datele despre utilizator (de exemplu numele utilizatorului); What (ce) se refer la un obiect (un exemplu de atribut este numrul lui de identificare); Where (unde) indic locaia (un exemplu este setul de coordonate x,y,z); When (cnd) precizeaz momentul de timp absolut sau abstract; How (cum) reprezint gesturile utilizatorului (de exemplu poziia corpului sau a unei pri a corpului, cum ar fi minile); Why (de ce) reprezint starea utilizatorului.

2.3.7 Modele bazate pe ontologii

Ontologiile sunt folosite n sistemele de calcul pentru a reprezenta realitatea nu doar ca un set de concepte distincte, ci ca un ansamblu de concepte ntre care exist relaii diverse (nu doar ierarhice i de apartenen). n modelarea contextului, ontologiile faciliteaz o reprezentare precis a elementelor de context, a parametrilor acestora i a legturilor dintre ele i permit 24

raionarea asupra conceptelor existente i a relaiilor dintre ele pentru a deduce noi valori ale elementelor de context i pentru verificarea consistenei modelului. Ontologiile folosesc clase pentru a reprezenta concepte i ofer suport pentru raionare (ca cele bazate pe logic). De aceea motenesc caracteristicile acestor dou tipuri de modele, dovedind n privina validrii calitile modelelor bazate pe scheme de marcare. Ca urmare, compoziia distribuit, validarea, cantitatea i calitatea informaiei, completitudinea, suportul pentru raionare sunt cel mai bine rezolvate de aceast clas. Preul de pltit pentru aceste performane este ns, n acest caz, creterea complexitii. Exemple. SOUPA (Standard Ontology for Ubiquitous and Pervasive Applications) a fost definit [Chen04], [perv04] pentru a deveni un standard pentru aplicaii omniprezente. Ea permite soluionarea urmtoarelor probleme: deducerea altor elemente de context din surse externe; descrierea conceptelor persoan, locuri, intenii; inconsistena informaiilor de context; distribuirea cunoaterii (datorit reutilizrii unor ontologii existente); controlul pentru pstrarea confidenialitii; reutilizarea contextului pentru alte tipuri de aplicaii.

Document [doc] Device [dev] Agent [agt] Region Conn Calc [rcc] BDI [bdi]

Digital-Doc [ddc] ImgCapture [icap] Person [per] Policy [pol] Action [act] Meeting [mtg]

Event [eve]

Location [loc]

Space [spc] Geo-M [geo] Knowledge [know]

Schedule [sch] Time [tme]

Legenda: owl:import Partea central a ontologiei SOUPA Extensia SOUPA [ ] Spaiul de nume XML

Figura 2.7. Reprezentarea grafic a ontologiei SOUPA [perv04]

25

Menionm ca neajuns al SOUPA faptul c nu permite reprezentarea clasificrii n tipuri de context (dedus, detectat, declarat) i a dependenei ntre diferitele elemente de context. SOUPA (vezi figura 2.7) este proiectat din dou pri: una central (considerat a fi acoperitoare pentru toate aplicaiile omniprezente) i o extensie (unde se poate aduga acel vocabular specific acelei aplicaii particulare pe care o dezvoltm). Fiecare din ontologiile componente este notat, pe ct posibil, folosind OWL (Web Ontology Language). n SOUPA Core se refolosesc, de exemplu, ontologiile FOAF (Friend-of-aFriend) pentru conceptul persoan, DAML-Time pentru conceptul timp, OpenCyc i Open GIS pentru conceptul spaiu. Redm parte a unui exemplu de fiier OWL din [Gu05]:

<rdf:RDF > <owl:Ontology rdf:about="&cobra;contextbroker"> <owl:imports rdf:resource="&soupa;person"/> <owl:imports rdf:resource="&cobra;ebiquity-meetings"/> </owl:Ontology> <per:Person rdf:about="http://www.gl.umbc.edu/~yim1"> <per:name rdf:datatype="&xsd;string">Gigi Yim</per:name> <per:knows rdf:resource="http://www.cs.umbc.edu/~finin"/> </per:Person> <per:Person rdf:about="http://www.cs.umbc.edu/~finin"> <per:name rdf:datatype="&xsd;string">Tim Finin</per:name> </per:Person> <ebm:EbiquityMember rdf:about="http://www.cs.umbc.edu/~finin"/> <ebm:EbiquityMember rdf:about="http://www.cs.umbc.edu/~hchen4"/> <ebm:EbiquityMember rdf:about="http://www.cs.umbc.edu/~joshi"/> </rdf:RDF>
Un alt exemplu de reprezentare ontologic a contextului este SOCAM (Service Oriented Context Aware Middleware) [Gu05]. Aceast reprezentare rezolv urmtoarele: reduce complexitatea reprezentrii contextului prin separarea ontologiei ntr-o parte general (care poate fi folosit de ctre orice aplicaie) i o parte specific domeniului aplicaiei; permite deducerea valorilor contextului superior prin inferen asupra valorilor contextului inferior; 26

permite rezolvarea conflictelor dintre diferitele surse de context; faciliteaz meninerea consistenei bazei de cunotine; detecteaz i corecteaz inconsistenele informaiei de context pe baza mecanismului de inferen; permite reprezentarea claselor de surse de informaii de context, de exemplu context direct (detectat, declarat) i context indirect (dedus).

Ontologia SOCAM este mprit n dou: o ontologie general i ontologii corespunztoare domeniilor aplicaie, ca n figura 2.8. Ea este descris n OWL, la care au fost adugate elementele proprietate rdfs:dependsOn i owl:classifiedAs. Prezentm un extras din ontologia de nivel general n care se definete clasa de baz ContextEntity i din care se deriv clasa Activity (ca subClassOf), iar mai jos se arat c o entitate de calcul (CompEntity) va fi folosit (proprietatea use figurat ca o linie n figura 2.8) ntr-o anumit activitate (Activity):

Ontologie generalizat n nivelul superior Comp Entity Application Network Service Device Agent locatedIn Location

Context Entity use own locatedIn engagedIn locatedIn IndoorSpace OutdoorSpace Person Activity ScheduledActivity DeducedActivity

Ontologie a domeniului vehiculelor Ontologii specifice domeniului Ontologie a domeniului casei Legend: owl:Class rdfs:subClassOf owl:Property

Figura 2.8. Reprezentarea ontologiei SOCAM cu detalierea claselor din nivelul general [Gu05]

<rdf:RDF xmlns=http://www.comp.nus.edu.sg/socam/ConOnt# ... xmlns:socam=http://www.comp.nus.edu.sg/socam/ConOnt# ...> <owl:Class rdf:ID="ContextEntity"/>

27

<owl:Class rdf:ID="Activity"> <rdfs:subClassOf rdf:resource="#ContextEntity"/> </owl:Class> ... <owl:ObjectProperty rdf:ID="use"> <rdfs:domain rdf:resource="#Activity"/> <rdfs:range rdf:resource="#CompEntity"/> </owl:ObjectProperty> ... </rdf:RDF>

2.4 Comparaie ntre clasele de modele de context

n tabelul de mai jos sintetizm modul n care clasele de modele de context rspund la caracteristicile enunate n seciunea 2.2:
Tabel 2.1. Comparaie ntre modele de context dup criteriile 1-5 enunate n seciunea 2.2.
Clas de model de context Perechi atribut-valoare Web Scheme de marcare Grafice Logice Orientate obiect Ontologice Compoziia distribuit + ++ ++ ++ Validarea + ++ + ++ Cantitatea i calitatea informaiilor + + + + Completitudinea + + Suportul pentru raionare ++ + ++

Analiznd acest tabel ne ntreba cnd este recomandat s folosim un model dintr-o anumit clas i cnd dintr-o alta i de ce? Rspundem la aceste ntrebri n continuare. Aplicaiile simple cu un numr redus de elemente de context (unu, dou), ntre care nu se pot stabili uor relaii, pot beneficia de simplitatea claselor de modele atributvaloare i bazate pe web. Acestea din urm vin cu un mic avantaj, acela de a permite, ntr-o mic msur, validarea coninutului paginii web n care sunt prezente atributele modelului. Lipsa suportului pentru raionare nu este aici critic, deoarece avem un numr redus de elemente de context care sunt independente. Modelele bazate pe scheme de marcare sunt potrivite aplicaiilor n care elementele de context sunt puternic ramificate, cu majoritatea relaiilor ntre ele de tip ierarhic, dar care se bazeaz pe surse de informaii de ncredere i care sunt relativ puin distribuite n reea. Situaiile simple de context nu cer acestei clase de modele de context suport pentru raionare. 28

Modelele bazate pe grafic i gsesc utilitatea ca baz de proiectare a aplicaiilor mai complexe. Tot unealt poate fi considerat clasa de modele bazate pe logic, deoarece ele permit o testare n avans a regulilor ce descriu comportamentul aplicaiei senzitive la context folosind limbaje dedicate. Modelele orientate obiect sunt o soluie bun cnd numrul elementelor de context este mediu sau mare cu reguli de comportament relativ puine i simple, structura modelului de context fiind uor de gestionat de ctre proiectant. Aplicaiile cu multe elemente de context care au relaii complexe ntre ele, care provin din surse diferite ca debit i calitate, susceptibile de a fi incomplete i ca urmare cu reguli ce au muli parametri, gsesc o fundaie solid n modelele de context ontologice.

2.5 De ce sunt potrivite ontologiile n reprezentarea contextului?

n cazul reprezentrii contextului ontologiile: i. n articolele [Xiao04][Yau06] se spune c: - permit reprezentarea formal a contextului [Xiao04] - permit distribuirea cunoaterii i reutilizarea ei [Yau06] - permit raionarea logic asupra contextului (verificarea consistenei, subsumarea, raionarea pentru cunoatere implicit [Yau06]) ii. lucrare [Ejigu07] despre descrierea ontologic a contextului se dau argumentele: - au putere de expresie (OWL suport restricii de cardinalitate) - permit organizarea ierarhic a informaiei - permit descrierea formal - sunt standardizate - ofer suport pentru raionare eficient, abstractizarea programrii i interoperabilitate iii. despre ontologii se spune n [Gu05] c: - au independen fa de limbajele de programare - permit analiza formal a domeniului cunoaterii iv. referina [Luca06] spune c: - folosind mecanismele de raionare (inferena intra-context (ex. definirea contextului de ordin superior), raionarea asupra contextului pentru rezolvarea informaiei imprecise sau pariale), contextul poate fi mrit, mbogit, sintetizat, distribuit. v. n articolul [Reto07] mai apare i ideea c ontologiile de context: - rezolv problema heterogenitii datelor, ambiguitii, calitii i validitii datelor de context

2.5.1 Raionarea ontologic

Pentru a prezenta mai clar cum se face raionarea ontologic ne-am ghidat dup urmtoarele ntrebri: 1. Cum se face verificarea consistenei? 2. Cum se face raionarea ontologic pentru clasificare a conceptelor i a instanelor? 29

3. Cum se face raionarea folosind caracteristicile proprietilor? 4. Cum se face raionarea cu reguli utilizator? Iat n continuare rspunsurile la aceste ntrebri: 1.Verificarea consistenei unei ontologii se face astfel: pe baza descrierii claselor (condiiilor) motorul de inferen verific dac este posibil ca o anumit clas s aib instane sau nu. O clas este inconsistent dac nu poate avea nici o instan. Ex. O ontologie care are o clas care aparine (este subclas) simultan la dou clase disjuncte, este inconsistent. 2. ntr-o ontologie exist clase primitive i definite. ntre clase pot exista relaii de: - subsumare (subclas) - disjuncie Clasele se descriu folosind operatori logici (reuniune, intersecie, complement) i restricii (existenial, universal, cardinalitate i are_valoare (hasValue)) aplicate asupra claselor de baz. Restricii: - existenial: clasa de indivizi care au cel puin o (some) instan (individ) ca obiect al unei relaii descrise printr-o proprietate (ex. toate pizzele cu adaos doar adaos_picant) - universal: clasa de indivizi care, pentru o anumit proprietate, au relaii doar cu (only) indivizii clasei specificate (ex. fiecare pizza are cel puin un aluat) - cardinalitate: proprietatea clasei ia exact (=), este mai mic (<) sau mai mare (>) dect o valoare numeric (ex. pizza are_adaos exact 2) - are_valoare (hasValue): proprietatea clasei are_valoare o anumit instan (ex. pizza are_pizzar Luigi) Definirea claselor se face prin condiii: - necesare (clase primitive): arat c pentru ca un individ s aparin unei clase el trebuie s ndeplineasc anumite condiii - necesare i suficiente (clase definite): arat c dac toi indivizii clasei B ndeplinesc aceste condiii necesare i suficiente ale clasei A, clasa B este subclas a clasei A.

Raionarea ontologic pentru clasificarea conceptelor (claselor) se face prin determinarea tuturor relaiilor de subsumare din ontologie, pe baza definiiilor claselor definite. Raionarea ontologic pentru clasificarea instanelor (indivizilor) se face prin determinarea tuturor claselor din ontologie, care pe baza definiiilor lor, pot s aib acea instan ca membru. Observaie: OWL DL folosete logica de ordinul nti (FOL) care opereaz pe baza presupunerii unei lumi deschise (open world assumption), adic un fapt nu este fals pn nu se dovedete aceasta.

30

3. Raionarea folosind caracteristicile proprietilor se face folosind reguli generice n funcie de specificul caracteristicii: - funcional: are o valoare sau niciuna (ex. adaos_pizza se_aeaz_pe pizza) - invers (ex. pizza are_adaos adaos_pizza) (?a proprietate ?b)->(b? proprietate_inversa ?a) - simetric (?a proprietate ?b)->(b? proprietate ?a) - tranzitiv (?a proprietate ?b) (?b proprietate ?c)->(a? proprietate ?c) 4. Raionarea cu reguli utilizator se face, similar celei cu caracteristici ale proprietilor, indicnd setul de necunoscute (variabile precedate de semnul ?) i un lan logic de proprieti i valori ale proprietilor instanelor claselor care determin o valoare a unei proprieti a unui individ dintr-o clas. Ex. [USER_ACTIVITY_SLEEPING: (?user rdf:type pre:Human), (?user, pre:hasLocation, pre:Bedroom1), (?lightSensor, pre:hasLocation, pre:Bedroom1), (?lightSensor rdf:type pre:LightSensor), (?lightSensor pre:sensorValue "LOW"), (?noiseSensor, pre:hasLocation, pre:Bedroom1), (?noiseSensor rdf:type pre:NoiseSensor), (?noiseSensor pre:sensorValue "LOW"), -> (?user pre:hasActivity pre:Sleeping1), print(?user)] Regula numit USER_ACTIVITY_SLEEPING stabilete ca pentru fiecare utilizator (necunoscuta user) care este instan a lui pre:Human dac se afl (proprietatea pre:hasLocation) n dormitorul 1 (instana pre:Bedroom1) i dac orice senzor de lumin (necunoscuta lightSensor de tipul (aparinnd clasei) pre:LightSensor) situat n (proprietatea hasLocation) n dormitorul 1 are valoarea (proprietatea pre:sensorValue) LOW i, similar, dac orice senzor de zgomot din dormitorul 1 indic valoare LOW s fie impus valoarea pre:Sleeping1 pentru activitatea curent (pre:hasActivity) a acelui utilizator.

31

3 Mecanisme de descoperire a contextului

Unul dintre modulele arhitecturii unui sistem senzitiv la context este cel care se ocup de colecionarea i procesarea (interpretarea, agregarea etc.) contextului. Uneori modulului i se specific, din faza de proiectare, de ctre dezvoltator, de unde s colecioneze elementele de context de interes. De exemplu i se specific adresa IP a senzorului care msoar temperatura. Alteori modulului i se specific numai elementul de context de care are nevoie sistemul (de exemplu sistemul are nevoie de temperatur), dar sursa acestui element de context trebuie descoperita de ctre modul n timpul funcionrii. n acest caz spunem ca modulul descoper contextul. Autonomia, tema principal a acestui proiect, are ca premis abilitatea sistemului de a descoperi contextul n timpul funcionrii. De aceea, n acest raport, vom face o analiz a protocoalelor de descoperire a contextului existente. n esen, descoperirea contextului are la baz aceleai mecanisme ca descoperirea serviciilor. Enumerm cteva protocoale cunoscute de descoperire a serviciilor SLP, Jini, Salutation, UPnP etc. Pornind de la definiia protocolului de descoperire a serviciilor, folosim n acest raport urmtoarea definiie pentru protocolul de descoperire a contextului.

3.1 Protocoale de descoperire a contextului

Protocolul de descoperire a contextului este un protocol care permite detectarea automat a furnizorilor de context (senzori) ntr-un mediu pervasiv. n continuare vom analiza cteva protocoale de descoperire a contextului precum i cteva sisteme senzitive la context care au nglobate mecanisme de descoperire a contextului.

3.1.1 R-CDP
R-CDP [Steph04] este un protocol proiectat pentru mediile ubicomp n care conectivitatea ntre dispozitivele mobile se schimb frecvent, iar dispozitivele au resurse de energie i de calcul limitate. n aceste medii, se consider c senzorii se gsesc pe dispozitivele mobile. Protocolul urmrete descoperirea acelor dispozitive pe care exist senzori care pot s furnizeze informaii despre un anumit context. Accentul se pune pe economisirea energiei i pe solicitarea a ct mai puin din resursele de calcul ale dispozitivelor. Cteva dintre caracteristicile protocolului R_CDP: - comunicare push i pull pentru descoperirea i extragerea contextului: un Requester descoper contextul oferit de Provider folosind mecanismul pull, iar un Provider folosind mecanismul push disemineaz contextul ctre Requester, ntr-o maniera proactiv, atunci cnd contextul se modific; - n funcie de condiiile reelei R-CDP tie s modifice intervalul la care se transmit cererile (Request) pentru aflarea contextului. De asemenea R-CDP tie s reduc rspunsurile (Result) redundante.

32

R-CDP folosete funcia Refresh Priority (RP) pentru a determina cnd trebuie s trimit Provider-ii actualizri ale contextului, iar pentru aceasta ia n considerare energia pe care o au Provider-ii.

Descriere protocol din punctul de vedere al modului care cere informaii despre context Requester. Cnd o aplicaie care se execut pe un dispozitiv Requester are nevoie de un element de context C anun la R-CDP acest lucru. R-CDP verific n Context Repository dac C este disponibil local. Context Repository stocheaz toate informaiile despre contextele pe care le cunoate dispozitivul Requester. Dac contextul solicitat este disponibil local atunci acesta este livrat aplicaiei. Altfel, Requester trimite un Request prin care anun c are nevoie de valoarea pentru contextul C. Requester v-a atepta un interval de timp primirea unui mesaj Result care conine valoarea contextului C. Dac timpul s-a scurs fr ca s se primeasc mesajul Result, atunci protocolul se termin aici, iar aplicaia nu primete valoarea contextului cutat. Altfel, dac sunt mai muli Provider-i care furnizeaz contextul C, toate valorile sunt agregate de Requester i livrate apoi aplicaiei. Dup aceea dispozitivul Requester trimite la intervale regulate mesaje Neighbor Validation Becon (NVB) la dispozitivul Provider pentru a-i spune ca are nevoie n continuare de actualizri ale lui C. Mesajele NVB conin: numrul de Provider-i care furnizeaz contextul C, numr notat cu Np i o valoare de prag T (threshold) prin care Requester-ul specific Provider-ului faptul c dorete s primeasc actualizri ale contexului atunci cnd contextul s-a modificat cu mai mult de T (de la ultima actualizare). Mesajele NVB sunt trimise prin broadcast. Acest lucru face ca i dispozitivele care au intrat mai nou n reea s primeasc mesaje NVB, permind astfel Requester-ului s descopere noi dispozitive care pot constitui surs de context C. Descrierea protocolului din punctul de vedere al modului care ofer informaii despre context Provider. Un nou senzor se nregistreaz la R-CDP (de pe dispozitivul la care este conectat senzorul) anunndu-i numele, tipul de context pe care l poate furniza, metodele de achiziionare a contextului precum i frecvena cu care poate s achiziioneze contextul. La primirea unei astfel de nregistrri, R-CDP actualizeaz Context Repository local. La nregistrare se specifica i o marca de timp care indica momentul n care contextul devine invalid i trebuie ters din Context Repository. La primirea unui Request, un Provider caut n Context Repository contextul C. Dac C este disponibil se trimite un mesaj Result care conine C. Provider-ul analizeaz periodic Context Repository calculnd valoarea refresh priority RP pentru contextul C. Comparnd valoarea RP cu T se determina dac trebuie trimisa o actualizare a contexului pentru C la Requester. Dac RP > T, Provider-ul va decide formarea i trimiterea unui mesajul Result care conine noua valoare a contextului C. Trimiterea mesajului Result mai este condiionat i de probabilitatea de transmisie (aa cum se va explic mai jos) pe care o calculeaz pe baza valorii Np.
R-CDP nu necesit putere de calcul mare pentru c implic numai operaii simple de cutare i ntreinere a Context Repository-ului. R-CDP nu necesit mult energie pentru c folosete urmtoarele mecanisme:

33

Refresh priority. Cu aceast funcie, un Provider stabilete cnd trebuie s trimit o actualizare de context ctre un Requester. Funcia calculeaz ct de stabil este modificarea contextului ntr-un interval de timp. Expresia funciei este de aa natur nct elimin situaiile n care valoarea contextului variaz brusc (pentru un interval foarte scurt de timp). Se evit astfel situaia n care orice modificare a contextului este trimis ctre Provider, situaie n care traficul prin reeaua ar deveni foarte ncrcat i s-ar folosi mult din resursa de energie a dispozitivelor. De asemenea situaia n care orice modificare a contextului este trimisa ctre Provider trebuie evitat i pentru ca unele aplicaii sunt interesate numai de acele valori ale contextului care s-au stabilizat n timp. Ca urmare, valoarea funciei refresh repository se folosete pentru a determina, pentru un anumit context, la un anumit moment de timp, dac valoarea contextului s-a modificat i s-a stabilizat n timp peste valoarea de prag T. Dac da, atunci se trimite un mesaj Result de actualizare a valorii contexului ctre Requester. n cazul n care mai multe actualizri de context trebuie trimise simultan, se calculeaz refresh priority i pe baza lor se stabilete ordinea de trimitere a actualizrilor de context. Probabilitate de transmisie adaptiv. n cazul n care exist N Provider-i care pot furnizeze contextul C atunci N mesaje Result care conin valoarea contextului C se vor transmite prin reea. Dac N este mare atunci dispozitivele vor consuma mult energie. Un mecanism de coordonare prin care s se stabileasc unul dintre Provider-i cruia s i revin sarcina de a rspunde ar implica cel puin tot att consum de energie. Soluia propus n [Steph04] pentru reducerea numrului de mesaje Result redundante se bazeaz pe noiunea de probabilitate de transmitere: cu ct numrul de Provider-i este mai mare cu att scade probabilitatea de transmitere. Pentru a explica aceast noiune prezentm un exemplu din [Steph04]. Presupunem c un Requester are nevoie de intensitatea luminii dintr-o camer, iar intensitatea poate s i fie oferit de trei Provider-i. Dac reducem probabilitatea ca Requester-ul s primeasc cel puin un mesaj Result de la 100% (toi cei trei Provider-i trimit Result) la 99% (fiecare Provider va trimite Result cu o probabilitate de [1-(1-0.991/3)] = 0.78) se poate economisi 22% din energia consumat pentru transmiterea mesajelor Result. Selecie adaptiv a intervalului de transmitere a mesajelor NVB. Mesajele NVB sunt trimise prin broadcast. Dac mai muli Requester-i trimit simultan mesaje pot s apar coliziuni i ca urmare pierderi de mesaje care vor trebui retransmise producnd att consum de energie ct i ntrzieri. Pentru a reduce probabilitatea de coliziune n [Steph04] se propune modificarea intervalului de trimitere a mesajelor NVB.

3.1.2 Directed diffusion

Difuzia direct [Inta00, Inta03] este o paradigm de comunicare propus pentru reelele de senzori, care are n vedere difuzarea datelor n reeaua de senzori. Noiunile de baz ale difuziei directe sunt: mesaj de interogare (interest), mesaj de date, gradient i reinforcement (determinarea cii de ntoarcere a datelor de la senzori la nodul care a cerut datele). Mesajul de interogare este o cerere lansat de utilizator pentru ndeplinirea unui anumit task care presupune achiziionarea de date de la senzori. Mesajele de interogare 34

sunt mesaje cu nume. Un nume poate s fie dat de o list de perechi atribut-valoare. De exemplu un task de urmrire a unui vehicul poate fi descris astfel [Gu04]:
type = wheeled vehicle interval = 20 ms duration = 10 s rect = [-100; 100; 200; 400] // // // // detect vehicle location send events every 20 ms for the next 10 s from sensors within rectangle.

Datele trimise ca rspuns la un mesaj de interogare sunt i ele cu nume, adic sunt la rndul lor descrise prin perechi atribut-valoare. De exemplu un senzor care detecteaz un vehicul va rspunde astfel [Inta03]:
type = wheeled vehicle instance = truck location = [125; 220] intensity = 0:6 intensity = 0:85 timestamp = 01 : 20 : 40 // // // // // // type of vehicle seen instance of this type node location signal amplitude measure confidence in the match event generation time.

Vom descrie n continuare cum se propag o interogare i respectiv cum se propag datele rspuns la interogare.

Propagarea interogrii. Un mesaj de interogare este lansat de la un nod al reelei (numit sink) de unde se propag (se difuzeaz) mai departe n reea. Nodul de plecare a interogrii trimite interogarea periodic prin broadcast. Interogarea iniial este vzut ca o interogare exploratorie care detecteaz dac exist senzorii capabili s furnizeze datele care s rspund interogrii. De exemplu, prima interogare poate s arate astfel:
type = wheeled vehicle interval = 1 s rect = [-100; 200; 200; 400] timestamp = 01 : 20 : 40 // hh:mm:ss expiresAt = 01 : 30 : 40

Fiecare nod al reelei conine un cache n care se pstreaz interogrile. Pentru fiecare interogare exist un element (o intrare) separat n cache. Elementele nu conin informaii despre nodul de pornire a interogrii ci numai despre nodul imediat anterior prin care a trecut interogarea. Dou interogri sunt considerate distincte dac atributele lor type difer sau dac atributele lor rect indic zone (parial) distincte. Un element din cache are cteva cmpuri, i anume: timestamp indic ultimul momentul de timp la care s-a primit interogarea; gradient exist cte un astfel de cmp pentru fiecare vecin de la care s-a primit interogarea (aceeai interogare poate s fie primit de la mai muli vecini). Gradientul specific o direcie care indic nspre nodul de la care s-a primit interogarea. Fiecare gradient conine cmpul datarate (derivat din atributul interval al interogrii) i cmpul duration (calculat pe baza atributelor timestamp i expiresAt ale interogrii). Un gradient specific pe lng o direcie de trimitere a datelor rezultate ca urmare a faptului c s-a rspuns la interogare i o frecven cu care se dorete trimiterea datelor. Cnd un nod primete o interogare, verific dac interogarea exist n cache. Dac nu exist se creeaz o intrare n cache pentru aceast interogare, parametrii ei sunt calculai pe baza parametrilor interogrii, iar numrul de gradieni este egal cu unu. Gradientul 35

corespunde vecinului de la care a primit interogarea. Dac exist intrare n cache pentru interogare, dar nu exist un gradient pentru nodul care a trimis interogarea atunci se adaug un astfel de gradient i se actualizeaz timestamp i duration. Dac exist att intrarea n cache ct i gradientul atunci doar se actualizeaz timestamp i duration. Cnd un gradient expir este ters din intrare, iar cnd toi gradienii pentru o intrare expir, intrarea este tears la rndul ei. Dup ce primete interogarea, nodul poate s decid s o trimit mai departe unei submulimi formate din o parte sau chiar din toate nodurile vecine. Un nod poate s decid s nu mai trimit o interogare dac recent a mai trimis una identic (chiar dac aceasta are un alt nod iniial de plecare). n lucrarea [Gu04, Gu05] se descrie situaia n care nodul trimite interogarea la fiecare vecin, deci i la nodul de la care a primit interogarea. Cnd un nod primete o interogare, nu tie dac aceasta este primit ca urmare a unei interogri pe care el a trimis-o mai devreme sau este o interogare identic trimis de un alt nod. Ca urmare pentru fiecare pereche de vecini (Ni, Nj) se stabilesc gradieni i de la Ni la Nj, dar i de la Nj la Ni.

Propagarea datelor. Un nod care are senzori i care este n aria specificat prin atribute poate s prelucreze interogrile care ajung la el. nti nodul va identifica cea mai mare frecven de date a gradienilor la care trebuie s trimit datele provenite de la senzori. Apoi va cere senzorului s genereze datele cu aceast frecven. Nodul trimite apoi la fiecare nod pentru care are un gradient valoarea obinut de la senzor sub urmtoarea forma:
type = wheeled vehicle // type of vehicle seen instance = truck // instance of this type location = [125; 220] // node location intensity = 0:6 // signal amplitude measure confidence = 0:85 // confidence in the match timestamp = 01 : 20 : 40 // local event generation time

La primirea unui astfel de mesaj de rspuns care conine date, un nod va caut n cache o intrare care conine interogarea care se potrivete cu rspunsul. Dac nu exista o astfel de intrare n cache atunci mesajul de rspuns este abandonat. Dac exist o astfel de intrare n cache, datele sunt trimise ctre nodurile vecine pentru care intrarea conine gradieni. Frecvena de transmitere a datelor din mesajul rspuns este adaptat la rata de transmitere a datelor specificat n gradieni.

Stabilirea cii de transmitere a mesajului de rspuns Pn acum s-a descris interogarea iniial trimis de un nod de plecare (sink) i difuzat apoi n ntreaga reea. Aceast interogarea specific de obicei o frecven de transmitere a datelor mic. Interogarea iniial se folosete n aceast faz de explorare n care se stabilete dac exist noduri cu senzori care pot s rspund la interogare. Rspunsurile pot s se ntoarc la nodul de plecare pe mai multe ci. Dup ce nodul de pornire ncepe s primeasc rspunsuri, el va selecta un vecin care urmeaz s colecteze datele, dar de data aceasta cu o frecven mai mare (suficient de mare pentru ca datele obinute s fie de folos pentru aplicaie). Nodul de plecare retrimite nodului selectat interogarea original ns cu o valoare mai mic pentru atributul interval, aa cum se arat mai jos:
type = wheeled vehicles

36

interval = 10 ms rect = [-100; 200; 200; 400] timestamp = 01 : 22 : 35 expiresAt = 01 : 30 : 40

Nodul vecin, care primete interogarea, va vedea c rata de transfer a datelor este mai mare dect nainte i va verifica dac are vreun gradient care s aib o rat de transfer date mai mare sau egal cu cea din interogarea pe care a primit-o. Dac nu are astfel de gradieni va alege un vecin cruia i va transmite interogarea cu noua frecven de transfer. Se construiete astfel calea pe care va veni napoi rspunsul la interogare.

3.1.3 SPIN
SPIN (Sensor Protocols for Information via Negotiation) [Heinz99] este un protocol de diseminare eficient a datelor ntre senzori, eficienta din punctul de vedere al energiei consumate de reeaua de senzori wireless. Ceea ce este specific pentru SPIN este faptul ca nodurile reelei folosesc meta-date pentru a descrie datele. Negocierea bazat pe meta-date st la baza transmiterea eficienta a datelor. Exist dou idei fundamentale ale protocolului SPIN: 1. pentru a economisi energia reelei, senzorii trebuie s poat s comunice ntre ei despre datele pe care le au deja i despre cele de care au nevoie; 2. nodurile trebuie s fie capabile s monitorizeze nivelul de energie pe care l au i s acioneze n conformitate cu acest nivel.

Meta-date Meta-datele sunt folosite pentru a descrie pe scurt, dar complet datele care sunt colectate de la senzori. Bineneles c meta-data care descrie o dat trebuie s aib o lungime mai mic dect data n sine. Meta-data este de fapt o reprezentare succint pentru o colecie mare de informaii. La dou date diferite trebuie s le corespund dou meta-date diferite. Dou date care nu se pot distinge una de alta vor fi descrise de aceeai meta-data. Protocolul SPIN nu specific un format pentru meta-date revenindu-i aplicaiei sarcina s specifice acest format. Un exemplu simplu de meta-data este ID-ul senzorilor astfel nct toate datele colectate de la un senzor sunt descrise de ID-ul lui. Un alt exemplu pe care l prezentm se refer la un senzor aparat de filmat. n acest caz, meta-data poate consta din tripletul (x, y, ) unde x i y reprezint coordonatele geografice ale poziiei aparatului, iar reprezint orientarea lui. Mesajele SPIN Protocolul folosete trei tipuri de mesaje: ADV mesaj prin care se anun c un nod dorete s fac publice noi date, mesajul conine de fapt nu datele n sine ci meta-data care le descrie REQ mesaj prin care se formuleaz o cerere pentru date, un nod trimite un astfel de mesaj atunci cnd are nevoie de anumite date DATA mesaj care conine data, mesajul are ca header meta-data care descrie datele

37

Managementul resurselor n SPIN Aplicaiile SPIN sunt contiente de resurse i se pot adapta resurselor. Aplicaiile pot s interogheze resursele sistemului pentru a afla ct energie mai este disponibil. De asemenea ele pot s calculeze de ct energie este nevoie pentru a efectua anumite calcule i pentru a trimite sau primi date. SPIN nu furnizeaz o anumit politic de management a resurselor ci ofer aplicaiilor interfee care pot s fie folosite pentru a interoga resursele sistemului. SPIN este o librrie situat la nivel middleware. Aplicaiile folosesc aceast librrie pentru a dezvolta propriile protocoale SPIN. Prezentm n continuare dou variante ale protocolului SPIN. SPIN-1: Protocolul 3-Stage handshake SPIN-1 este un protocol handshake pentru diseminarea datelor printr-o reea fr pierderi (lossless network) care folosete trei pai: ADV-REQ-DATA. Vom descrie n continuare acest protocol. Un nod A care are date pe care dorete s le fac publice trimite un mesaj ADV la vecini. La primirea acestor date, fiecare vecin verific dac are aceste date. s notm cu B unul dintre vecinii lui A. Dac B nu are toate datele pe care A dorete s le fac publice, atunci rspunde cu un mesaj REQ pe care l trimite nodului A. Acesta va rspunde cu un mesajul DATA care conine de fapt datele de la A. Protocolul continu prin faptul c acum B va trimite la toi vecinii lui (cu excepia lui A) un mesaj ADV pentru aceste date. Dac nodul B are propriile lui date, le poate agrega cu cele ale lui A i va publica nu datele primite de la A ci datele lui agregate cu cele primite de la A. Dei acest protocol a fost proiectat s lucreze n reele fr pierderi el poate s fie uor adaptat pentru reele cu pierderi i pentru reele mobile. Nodurile pot s i fac n mod repetate publice datele (mesaj ADV) n felul acesta se rezolva problema mesajelor ADV care s-au pierdut. Nodurile pot s ceara nc o dat datele dac acestea nu sosesc ntr-un interval de timp specificat, n felul acesta se rezolv problema pierderilor mesajelor REQ i DATA. Reelele mobile sunt caracterizate de faptul c topologia reelei se schimb frecvent. Dac o modificare (local) de topologie produce modificarea listei de vecini a unui nod, atunci nodul trimite din nou mesajul prin care face publice datele lui. SPIN-2: SPIN-1 cu prag de energie SPIN-2 adaug o euristic de conservare a energiei protocolului SPIN-1. Cnd energia este suficient atunci SPIN-2 se comport ca SPIN-1. Cnd ns un nod observ c energia lui se apropie de un prag specificat, atunci i reduce participarea la protocol pentru a conserva energie. Mai exact nodul va participa la o etap a protocolului numai dac crede c va putea termina i ceilali pai ai protocolului fr ca nivelul lui de energie s scad sub pragul specificat. Astfel dac un nod primete date, el va iniia protocolul cu cei trei pai ai lui numai dac are destul energie pentru a termina protocolul cu toi vecinii lui. n aceeai abordare, dac un nod primete un mesaj ADV, el nu va trimite mesajul de cerere REQ numai dac are suficient energie nu numai s trimit mesajul, dar s i primeasc datele rspuns la mesaj. SPIN-2 nu evit situaiile n care un nod recepioneaz (si ca urmare i consum energia sub pragul specificat) ADV sau REQ. ns SPIN-2 evit situaiile n care un nod lucreaz cu mesajul DATA avnd energia sub pragul specificat.

38

3.1.4 Filtre Bloom

Protocolul [Liu07] este folosit n reetele ad-hoc. Informaia despre context se reprezint prin structuri de date Bloom filter care au avantajul c au dimensiuni mici. Filtrele Bloom sunt folosite pentru a face public informaia de context la mai multe noduri (hop-uri) distanta i pentru a ghida descoperirea informaiei de context. Datorit faptului c filtrele Bloom reprezint datele ntr-un mod compact traficul prin reea este redus. Informaia despre context (tipul contextului i sursa lui) nu este trimis prin broadcast ci se trimit numai filtre Bloom care conin tipul contextului la toate nodurile aflate la o distan de cteva hop-uri. Interogrile sunt trimise numai n direciile n care s-ar putea afla informaia cerut.

3.2 SOCAM (Service-Oriented Context-Aware Middleware)

n SOCAM [Gu04, Gu05] mecanismul de descoperire a contextului este implementat n dou module ale arhitecturii Furnizorii de context i Serviciul de localizare. Descriem n continuare aceste dou module.

Furnizorii de context. Aceste module sunt de dou tipuri: furnizori de context intern i furnizori de context extern. Ambele tipuri de furnizori obin date de la senzori i convertesc aceste date n reprezentare OWL, pe care o trimit nivelelor superioare ale arhitecturii. Diferena dintre cele dou tipuri de module este dat de senzorii de la care se obin datele. Furnizorii interni achiziioneaz datele de la senzorii fizici din interiorul domeniului de interes. De exemplu, n cazul n care domeniul de interes este maina aceti senzori colecteaz date de la sistemul de navigare GPS sau de la ali senzori din main. Dac domeniul de interes este o cas, furnizorii interni colecteaz date de la senzorii de prezen, senzorii de temperatur, zgomot etc. Furnizorii externi colecteaz informaii despre contextul din afara domeniului de interes (de exemplu informaii despre starea vremii care se pot colecta de la un senzor virtual de tipul servicii web). De asemenea, tot de la un serviciul web se pot colecta date despre condiiile de trafic. Serviciul de localizare. La acest modul se nregistreaz furnizorii de context, serviciile senzitive la context, precum i intrepretorii de context. Modulele arhitecturii pot s descopere i apoi s foloseasc acele componente care sunt nregistrate. Tipic, utilizatorii i aplicaiile descoper furnizorii i interpretorii de context. Un furnizor de context i poate anuna setul de elemente de context de la care culege informaie n mai multe moduri: prin abloane sau prin expresii OWL. Serviciul de localizare ofer suport pentru ambele. De asemenea, furnizorii de context i pot modifica n timp elementele de context de la care pot s afle informaie. i n aceast situaie serviciul de localizare ofer suport pentru administrarea acestor modificri.
n arhitectura SOCAM, diseminarea contextului se face att n modul push ct i n modul pull. 39

3.3 Context Toolkit

n Context Toolkit [Dey00, Dey01] mecanismul de descoperire a contextului este implementat n Componenta de descoperire. Rolul Componentei de descoperire este s localizeze n reea componentele arhitecturii. Aplicaiile nu trebuie s cunoasc de la nceput unde se gsesc componentele de care au nevoie. Dac infrastructura care lucreaz cu senzorii se modific (adic apar sau dispar componente), aplicaiile se pot adapta uor pentru c ele pot cere Componentei de descoperire s le anune atunci cnd au loc astfel de evenimente. Cnd un Widget sau un Agregator se nregistreaz, va anuna Componentei de descoperire identificatorul, numele staiei gazd, numrul portului, atributele, callbackuri i servicii. Cnd un Interpretor se nregistreaz, va anuna Componentei de descoperire identificatorul, numele staiei gazd, numrul portului, atributele pe care le poate interpreta i atributele pe care le poate genera ca i ieiri. De exemplu, o component poate fi interesat de un Widget sau de un Agregator care are o anumit mulime de atribute i/sau o anumit mulime de atribute constante i/sau o anumit mulime de servicii. Un alt exemplu este cel al unei componente interesate de Interpretori care au o anumit mulime de atribute de intrare/ieire. Cnd componentele Widget, Agregator i Interpretor se instaniaz, ele se nregistreaz la Componenta de descoperire. Cnd aplicaia pornete, contacteaz Componenta de descoperire pentru a localiza componentele de care are nevoie.

3.4 SCI
SCI [Glass03] este organizata n dou nivele. Nivelul inferior se numete Range, i este o arie care conine noduri, iar n interiorul ariei se produc, administreaz i utilizeaz informaii de context. Nivelul superior se numete SCINET i este responsabil cu interaciunea care are loc ntre dou sau mai multe Range cu scopul schimbului de informaii de context. Entitile care sunt ntr-un Range pot s fie interesate de informaiile de context care pot s fie furnizate de entitile dintr-un alt Range. Modulul principal din fiecare Range se numete Context Server CS. Un senzor este reprezentat de o entitate numit context entity CE al crui profil este descris cu ajutorul meta-datelor. La un moment dat un CE este nregistrat ntr-un Range. CE se nregistreaz la o entitate centrala Registrar de unde apoi pot s fie gsite de alte module care au nevoie de ele. CE produce i consum evenimente care au asociate tipuri. Un element definitoriu pentru SCI este faptul ca informaiei de context se agreg nainte de a ajunge la entitatea care a solicitat-o. De fapt, se combina CE (pe baza profilelor lor) ntr-un graf.

3.5 Concluzii
Descoperirea contextului trebuie s fie o caracteristica a sistemelor autonome senzitive la context. n literatura de specialitate au fost propuse foarte multe mecanisme pentru descoperirea contextului. n capitolul 3 al acestui raport s-a fcut o selecie 40

analizndu-se numai acele mecanisme care s-au considerat c sunt de interes pentru proiect. Din studiul acestor mecanisme se observ c ele difer prin arhitectura, mediul pentru care au fost proiectate precum i descrierea informaiei de context. Arhitectura poate s fie centralizat, exemple sunt SOCAM i ContextToolkit, sau distribuit, aa cum este n cazul Directed diffusion i SPIN. Se observ c arhitectura distribuit este folosit atunci cnd protocolul este proiectat pentru mediile ubicomp n care conectivitatea dintre dispozitivele implicate n interaciune se schimb des. n astfel de medii se pune de asemenea problema optimizrii consumului de energie. n acest sens protocolul R-CDP tie s modifice intervalul la care se transmit cererile de context, tie s reduc rspunsurile redundante i ia n considerare energia pe care o au Provider-ii pentru a determina cnd trebuie s se trimit actualizri ale contextului. n SPIN folosirea eficienta a resurselor de energie se face prin negocierea bazat pe meta-date. Ajungem astfel la descrierea informaiei de context. n SPIN sunt folosite meta-datele pentru a descrie complet i succint informaiile de context. Protocolul nu specific un format anume pentru meta-date ci las aceast sarcina dezvoltatorului de aplicaii. Protocolul Directed diffusion folosete mesajele cu nume pentru formularea interogrilor i a rspunsurilor de la senzori. n protocolul bazat pe filtre Bloom informaia despre context se reprezint prin structuri de date Bloom filter a cror avantaj este acela ca reprezint informaia ntr-un mod foarte compact.

41

4 Observarea contextului n cazul aplicaiilor adaptive implementate

4.1 Observarea contextului n cazul platformei SOA
n aceast seciune este prezentat modul de interaciune al platformei de test propuse cu elementele de context.

4.1.1 Scenariu
Scopul acestui scenariu este de a ilustra modul de adaptare a serviciilor software considernd o arhitectur de genul celei din figura urmatoare.

Figura 4.1. Platforma de adaptarea a serviciilor arhitectura de principiu

Pentru scenariul propriu-zis considerm un magazin virtual sub forma unui serviciu Web, numit Virtual Store Service. Acest serviciu ofer trei operaii: - Aflarea produselor disponibile. - Aflarea detaliilor despre un anumit produs n funcie de numele acestuia. - Aflarea preului unui produs n funcie de numele acestuia. Aceast operaie este cea care ne intereseaz i pe care dorim s o adaptam n acest scenariu. O aplicaie client se poate conecta la acest serviciu i poate invoca, cele trei operaii de mai sus. Serviciul folosete limba englez i EURO ca i moneda de specificare a preurilor. Dac un client folosete o alt unitate monetar atunci apare o dezadaptare. Considerm adaptare returnarea preului unui produs convertit la moneda clientului.

4.1.2 Reprezentarea contextului

Dup cum s-a specificat mai sus, rolul scenariului este de a realiza adaptarea unui serviciu la context. Pentru modelarea contextului s-a ales o schem simplist bazat pe 42

perechi cheie-valoare (key-value pairs). Acest mod de reprezentare este ilustrat, n format XML, n exemplul urmtor: <Context> <Currency>RON</Currency> </Context>

4.1.3 Detectarea contextului

n cazul acestui scenariu, clientul este responsabil de detectarea contextului n care evolueaz i de transmiterea acestuia la server. Clientul a fost dezvoltat folosind tehnologia .NET. Modul de determinare a monedei (currency) curente pe o masin Windows este ilustrat n urmtoarea secven de cod (folosind limbajul C#):
using System.Globalization; CultureInfo currentCultureInfo = CultureInfo.CurrentCulture; NumberFormatInfo numberFormatInfo = currentCultureInfo.NumberFormat; string currencySymbol = numberFormatInfo.CurrencySymbol;

4.1.4 Transmiterea contextului

Ideea de trasmitere a contextului este ilustrat n figura urmtoare. Clientul dispune de un detector de context, ilustrat n seciunea precedent. Contextul astfel detectat este ncapsulat n mesajul SOAP folosit pentru invocarea metodelor serviciului. Acest mesaj este transmis serviciului Web. nainte de a ajunge la acesta, mesajul SOAP este prelucrat de ctre Observer/Controler, prin intermediul componentei ContextHandler, dup care este mai departe trimis serviciului Web.

Figura 4.2 Modul de trasmitere a contextului de la client la serviciu

ntregul mesaj SOAP folosit pentru invocarea metodei de aflare a preului unui anumit produs arat astfel: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://quickstart.samples/xsd"> <soap:Header> <Context> <Currency>RON</Currency> </Context> 43

</soap:Header> <soap:Body> <xsd:getPrice> <xsd:param0>product</xsd:param0> </xsd:getPrice> </soap:Body> </soap:Envelope> Contextul este ncapsulat n header-ul mesajului SOAP i poate fi ignorat de serviciile web care nu l inteleg deorece nu este specificat ca fiind o seciune obligatorie a mesajului (atributul mustUnderstand din specificaiile SOAP este false n acest caz). Serverul preia contextul transmis de ctre client i consult ontologia pe care o are la dispoziie. Aceast ontologie este ilustrat n figura urmtoare.

Owl:Thing

Software Entity

Network Entity

Software Operation Name Description Software Application Currency Language Transformation Operation Parameter IP Address Network Protocol

Desktop Application Mobile Application

Web Application

TCP HTTP

Conversion To Service EndPoint Service Operations From

Web Service

Figura 4.3. Ontologie pentru clasificarea serviciilor Web

Din aceast ontologie se poate deduce faptul c VirtualStoreService este o instan a clasei WebService iar VirtualStoreClient (clientul care se conecteaz la serviciul web) este o instan a clasei DesktopApplication. Ambele clase deriv din clasa SoftwareApplication care este caracterizat de atributul Currency.

44

n acest mod se determin faptul c exist o dezadaptare. Pe scurt, adaptarea se realizeaz prin cautarea i invocarea unui serviciu care s realizeze conversia necesar.

4.2 Observarea contextului n cazul platformei de ageni

4.2.1 Reprezentarea preferinelor utilizatorului
n momentul actual n literatura de specialitate exist mai multe articole care trateaz reprezentarea preferinelor. Noi ne focalizm asupra reprezentarea acestor preferine n coresponden cu contextul, n scopul adaptrii comportamentului. Exist un prim studiu [Henri06] care face o trecere n revist a soluiilor de pn n acel moment (2006) pentru reprezentarea preferinelor, dar arat c pentru reprezentarea preferinelor n scopul adaptrii comportamentului, n cazul sistemelor omniprezente (senzitive la context), nu exist soluii pentru a reprezenta aceste preferine n dependena lor fa de context. Autorii articolului citat mai sus [Henri06] propun ei nii o astfel de soluie. Ea se bazeaz pe un mecanism de scoruri, fiecrei posibile preferine i se aloc un scor ce poate fi fie o valoare numeric real din intervalul [0,1], fie un scor special predefinit (veto, indiferent, obligatoriu, situaie de eroare). Dac un anumit context este prezent i un set de variabile asociate sunt prezente, scorul va fi o funcie score(p.s,C,v), unde p.s este expresia scorului preferinei p, C este contextul, iar v este setul de variabile asociate; altfel scorul este indiferent. n acest model elementele de context sunt considerate distincte, fr relaii ntre ele, nu avem o reprezentare ontologic. O reprezentare ontologic a preferinelor este prezentat n [Kim05]. Acest model se bazeaz pe relaii ontologice ntre preferine i elementele de context. Clasa Preferences are relaii cu toate clasele principale (Time, Agent, Location, Activity). Preferina poate fi pozitiv sau negativ, poate indica o alegere potrivit sau nepotrivit. Acest model are dezavantajul de a avea doar dou valori posibile (pozitiv sau negativ) pentru a indica relaia dintre context i preferine. O alt soluie pentru reprezentarea preferinelor vine din acelai colectiv de cercettori [Kamr06]. Modelul propus folosete o reprezentare neontologic a contextului, dar propun un mecanism bazat pe meta-reele Bayes i considerarea reaciei utilizatorului la deciziile sistemului. Meta-reelele Bayes sunt o structurare pe mai multe nivele a reelelor Bayes, care au ca fundament matematic probabilitile condiionate. Problema care apare aici este c probabilitile apriori necesit un calcul iniial, o estimare pe care trebuie s o realizeze un operator uman la proiectarea sistemului sau la introducerea unui nou element de context, ceea ce este dificil de rezolvat pentru un numr mare de elemente de context. Un alt articol [Flan05] prezint o soluie cu reele asociative context-aplicaie. Fiecrui element de context i se asociaz toate cele N posibile aplicaii pentru un utilizator dat. Asocierea este modelat printr-o pondere variabil w care indic tria conexiunii dintre un anumit element de context i aplicaia cu care este asociat. Mai mult considernd matricea tuturor ponderilor i un context anume, se poate estima care va fi aplicaia pe care utilizatorul o va prefera. Aceast soluie ns nu beneficiaz nici de avantajele reprezentrii ontologice a contextului i nici de cele ale unui mecanism de readaptare a ponderilor folosind reacia utilizatorului. 45

Reelele neuronale sunt folosite n [Youn05] pentru a descrie relaii ponderate ntre elemente de context (care rspund ntrebrilor: cine?, cum?, unde?, cnd?, de ce?) i elementele de context (care rspund ntrebrii: ce?), servicii i parametri ai seviciilor. Se folosesc perceptroni multistrat cu un nivel ascuns. Aceasta permite ca relaiile ponderate s fie modificate. Totui aceast posibilitate este utilizat de autori doar parial, antrenarea sistemului fcndu-se doar nainte de rulare. Un alt dezavantaj este c reprezentarea contextului este aici neontologic. n tabelul 4.1 avem o comparaie sintetic a diferitelor soluii de reprezentare a preferinelor:
Tabel 4.1. Comparaie a diferitelor soluii de reprezentare a preferinelor Soluie CtxPrefScor06 [Henri06] OWLPref05 [Kim05] Bayes Meta-Net06 [Kamr06] NNAssoc05 [Flan05] UPM05 [Youn05] Context.ontologic + Relaia context-serviciu scor relaie ontologic probabilistic ponderi reele asociat. ponderi PMS* Actualizare la rulare ++ +

* PMS Perceptron MultiStrat (din limba englez: MLP-MultiLayer Perceptron)

Remarcm utilizarea modelrii ontologice a contextului doar ntr-un singur caz [Kim05], dar la care lipsete posibilitatea modificrii dinamice a preferinelor la rulare. Pentru exprimarea preferinelor unui serviciu dat fiind contextul exist mai multe soluii. Ultima coloan a tabelului permite evaluarea soluiei din perspectiva obiectivului nostru de a oferi posibilitatea personalizrii, a modificrii preferinelor n funcie de nevoile utilizatorului. Astfel c soluia cu perceptronul multistrat [Youn05] este superioar celei n care se folosesc doar ponderi ce indic asocieri ntre context i servicii [Flan05] deoarece permite modificarea ponderilor printr-un mecanism de propagare invers a erorilor (back propagation); dar are dezavantajul c nu face aceasta la rulare n funcie de reacia utilizatorului. Soluia cu meta-reele Bayes este cea mai apropiat de obiectivul precizat mai sus. Dezavantajul ce apare la nivelul reprezentrii la aceast soluie este c aici modelul contextului nu este ontologic. Concluzia studiului este c modelarea ontologic a contextului este bine s fie combinat cu o soluie pentru reprezentarea ontologic a relaiei context-serviciu care s permit modificarea valorilor i nainte (antrenare), dar mai ales la rulare.

4.2.2 Mecanisme de descoperire a preferinelor

n urma studiului prezentat mai sus (seciunea 4.2.1) am constat c sunt puine soluii care iau n calcul reprezentarea i apoi modificarea valorilor relaiei contextserviciu. n lucrrile [Flan05] i [Youn05] se propune folosirea datelor istorice nregistrate ca perechi context (vectori de elemente de context) servicii. Mecanismul fiind bazat pe reele neuronale care sunt astfel antrenate s rspund cu un anumit serviciu la un context dat.

46

Un element unic al soluiei [Kamr06] este considerarea unei bucle de reacie de la utilizator prin care valorile relaiei context-serviciu sunt modificate la rulare. Astfel c sistemul va descoperii preferina utilizatorului. n concluzie, pentru soluia cu meta-reele Bayes, observm urmtoarele: -avantaje: i. preferinele fiecrui utilizator sunt separate i reutilizabile ii. se pot stabili prioriti ntre utilizatori -dezavantaj: probabilitile condiionate iniiale trebuie completate (calculate de proiectant i editate manual sau utiliznd expresii, sau obinute cumva (nu se tie nc n ce fel) din istoric) nefiind dat nc o soluie de iniializare automat a lor.

4.2.3 Soluii propuse

4.2.3.1 Ontologia casei inteligente i raionarea ontologic

Pentru reprezentarea cunoaterii am fcut urmtoarele alegeri: 1. Contextul va fi modelat ontologic 2. Relaia context-serviciu o reprezentm prin ponderi, modelate n ontologie 3. Actualizarea preferinelor se face prin interpretarea rspunsului afectiv al utilizatorului la fiecare decizie a sistemului. Principial, soluia pe care o propunem consider contextul C, format din elemente de context legate ntre ele prin relaii (model ontologic), un serviciu S (sau mai multe), un vector de ponderi w, prin care modelm preferinele i pe ale cror valori le stocm tot n ontologie i stare afectiv a utilizatorului U, ca n figura 4.4:

t1 U

t0

Figura 4.4. Diagrama de principiu a modelrii ontologice a preferinelor w pe care le are un utilizator U pentru un anumit serviciu S, dat fiind un context C prin reacie afectiv la deciziile sistemului

Funcional, la momentul t0 sistemul va rspunde cu un anumit serviciu la contextul dat, n funcie de o matrice de ponderi aleatoare sau preantrenat din date istorice de comportament ale acelui utilizator la contexte similare. Decizia oferirii unui anumit serviciu la momentul t0 va determina o reacie a utilizatorului la moment imediat urmtor t1. Aceast reacie, din care pe noi ne intereseaz partea ei afectiv, va fi interpretat mai nti ca exprimnd un acord sau un dezacord cu decizia sistemului. Acest acord sau dezacord determin modificarea corespunztoare a (adecvarea) ponderilor w (fapt simbolizat prin sgeata oblic). Astfel sistemul se adapteaz la noile preferine prin pai succesivi.
47

4.2.3.1.1 Proiectarea i implementarea ontologiei de context i a raionrii ontologice

1. 2. 3. 4. 5. Am cutat s rspundem la urmtoarele ntrebri: Cum s-a fcut proiectarea ontologiei? a. Cum am proiectat ontologia modelului de context? b. Ce legtur este ntre ontologii i mesajele schimbate ntre ageni? Cum s-a fcut verificarea consistenei cu Jena? Cum am folosit raionarea ontologic pentru clasificare n cazul ontologiei Smart House? Cum am folosit raionarea bazat pe caracteristicile proprietilor? Cum am folosit regulile utilizator?

1. Pentru proiectarea ontologiei modelului de context am pornit de la ontologia SOCAM [Gu05] pe care am extins-o: - am nlocuit clasa User cu clasa Actor cu subclasele Group i Individ, Human i NonHuman - am adugat clasa State, cu subclasele Mental, Physiological i Affective - am adugat clasele NeuralNetwork i Sensitivity. Am pstrat ideea de ontologie de nivel superior (upper) i de nivel inferior (lower) din [Gu05] aa cum se poate observa din figura 4.5. a) i b).

48

Figura 4.5. Ontologia de context pentru casa inteligent: a) n stnga, partea superioar i b) n dreapta, partea inferioar

b. ntre ontologii i mesajele schimbate ntre ageni legtura este c mesajele folosesc un cadru comun de discuie care este reprezentat n ontologie. La noi Jadex a impus acest format care are o limitare important: este doar RDF i nu OWL, ca urmare este mai puin expresiv (indic doar relaii subiect-predicat-obiect, fr restricii existeniale, universale, cardinalitate etc. i nici caracteristici ale proprietilor). n cazul aplicaiei noastre, ontologia pentru comunicarea dintre ageni este cea din figura 4.6. Aceast ontologie este distinct de cea a casei inteligente din cauza diferenei ntre OWL i RDF, dar cuprinde clasele necesare care s permit comunicarea agenilor din cas. La nivel de coninut se folosete limbajul Nuggets XML Content Language. Acesta este specific Jadex. Ontologia de comunicare ntre ageni permite att accesul la un model structurat al domeniului cunoaterii ct i facilitarea crerii de obiecte JavaBean. Beanynizer este o unealt care se integreaz n editorul de ontologii Protege i permite exportarea conceptelor sub un format compatibil Nuggets XML.

49

Figura 4.6. Ontologie responsabil cu comunicarea ntre ageni

Un exemplu de cod de comunicare interageni pentru schimbul unui obiect de tip este urmtorul:
public class InitSensorPlan extends Plan { public void body() { IMessageEvent request = (IMessageEvent)getInitialEvent(); AgentIdentifier aId = (AgentIdentifier)request.getParameter("sender").getValue(); Sensor sensor=(Sensor)request.getContent(); getBeliefbase().getBelief("sensor").setFact(sensor); getLogger().info("Sensor object exchange"); } }

2. Verificarea consistenei se face cu Jena la momentul ncrcrii ontologiei (fiierul OWL) n modelul Jena:
String ONT = "http://www.owl-ontologies.com/Ontology1207603095.owl#"; jenaModel = new CreateModel(ONT,"file:src/ontology/smarthouse_lower.owl");

50

3. Raionarea ontologic pentru clasificare n cazul ontologiei SmartHouse s-a fcut prin definirea claselor pe baza claselor de primitive. Un exemplu este clasa Father (Tat) (vezi figura 4.7). Definirea clasei Father s-a fcut plecnd de la clasa de baz Human, condiia necesar i suficient este ca acel om (Human) s aib cel puin un copil (proprietatea hasChild) care, desigur, este un om i s aib valoarea proprietii (hasGender) Male (sex masculin).

Figura 4.7. Definirea clasei Man

Figura 4.8. Definirea clasei Father

n urma raionrii (a se vedea figura 4.9), se subsumeaz Father clasei Man (Brbat), la acelai nivel cu Brother (Frate) i Son (Fiu).

51

Figura 4.9. Ontologia rezultat n urma raionrii ontologice

Figura 4.10. Raionarea pentru instane

52

n figura 4.10 se arat un exemplu de raionare prin care membri familiei Smith sunt recunoscui ca membri ai familiei printr-o raionare ce se bazeaz pe proprietatea familyName a crei valoare este Smith pentru John, Jane i LittleJohn, dar nu i pentru Mary, care este invitata familiei Smith. 4. Raionarea bazat pe caracteristicile proprietilor este demonstrat prin urmtorul exemplu de tranzitivitate aplicat pentru acordarea de drepturi pentru utilizatorii casei: [RIGHTS: (?b pre:isAuthenticatedBy ?a), (?c pre:isAuthenticatedBy ?b), -> (?c pre:isAuthenticatedBy ?a), print(?c)] Astfel dac sistemul ofer drepturi membrilor casei, acetia le pot transfera i invitailor lor. 5. O regul de tip utilizator este cea de mai jos: [USER_LOCATION: (?user rdf:type pre_upper:Human), (?user pre:hasRFIDTag ?tag), (?rfid rdf:type pre:RFIDReader), (?rfid pre:hasCurrentTag ?ctag), (?rfid pre:hasLocation ?room), -> (?user pre:hasLocation pre:RoomNo2), print(?room)] Ea permite identificarea locaiei (room) unui utilizator (user) pe baza unei etichete RFID (tag) care i este asociat (hasRFIDTag), citit de un cititor (RFIDReader) aflat ntr-o anumit locaie (hasLocation) atunci cnd utilizatorul se autentific (hasCurrentTag).

4.2.3.2 Reprezentarea preferinelor

Reprezentarea ponderilor n ontologie se face n strns legtur cu tipul de sistem expert pe care l-am ales: o reea neuronal de tip perceptron cu straturi ascunse. Raiunea acestor decizii este dat de rspunsul la urmtoarele dou ntrebri: 1. Care sunt avantajele utilizrii reelelor neuronale fa de meta-reelele Bayes? 2. Care sunt argumentele pentru a stoca parametri reelei neuronale care face adaptarea comportamentului sistemului (comportamentul este o tupl (C,S) context-serviciu) la preferinele utilizatorului n ontologie? Rspundem pe rnd celor dou ntrebri: 1. Reelele neuronale fa de meta-reelele Bayes prezint urmtoarele avantaje: - reelele neuronale permit antrenarea valorilor iniiale fr ca utilizatorul sau proiectantul s calculeze i s editeze valori iniiale de probabiliti - reelele neuronale nu solicit completarea tuturor combinaiilor de situaii (elemente de context - servicii) posibile - reelele neuronale permit generalizarea, adic sistemul va putea s rspund i la reguli pentru care nu a fost antrenat. Totui la reelele neuronale dificultatea const n partea de proiectare a reelei, a selectrii datelor pentru antrenare. La soluia cu meta-reelele Bayes [Kim05] avem o cretere foarte mare a numrului de probabiliti iniiale odat cu creterea numrului de valori ale elementelor 53

de context. Aceasta este rezonabil la un numr mic de elemente de context. Pentru scenariul nostru am avea de completat, pentru un utilizator, care poate fi autorizat/nu, cu dou nivele de luminoziate (luminos/ntuneric) pentru camer i exteriorul casei i dou activiti posibile ale utilizatorului (doarme/treaz) 21*21*21*21 combinaii posibile pentru situaia cu jaluzelele nchise i nc attea cu jaluzelele deschise. n total 24*22=64. ns dac mai adugm un element de context cu dou valori binare posibile (de exemplu zi/noapte sau n timpul sptmnii/sfrit de sptmn) numrul valorilor de calculat pentru probabilitile iniiale se dubleaz, adic ajung la 128. Deci este o cretere exponenial. Dei nu este n scopul cercetrii noastre, conflictul dintre mai muli utilizatori, rezolvat prin meta-reele Bayes, nseamn c pentru n utilizatori este necesar un numr de n+1 nivele Bayes. Astfel pentru 2 utilizatori s-ar ajunge la 3*128 = 348 de valori de calculat. Reelele neuronale nu solicit un calcul iniial pentru valorile ponderilor (acestea se genereaz aleator) ns solicit un set de perechi intrare (valori ale elementelor de context) ieire (aciuni sau servicii dorite) pe care l poate lua din date istorice i cu care se antreneaz. Meta-reelele Bayes au un ordin de complexitate de O(Npq + q Np ) [Kim05], unde N este numrul de utilizatori, p este probabilitatea ca un utilizator s fie la o anumit locaie, q este numrul de valori ale serviciilor sau aciunilor posibile, este o valoare proporional cu numrul de valori ale elemente de context (echivalent n cazul scenariului nostru). Pentru exemplul considerat, ordinul de complexitate ar fi O(1*1*28+28*1*1)=O(64). n cazul soluiei cu reele neuronale, acestea permit o reducere la un ordin de complexitate O(e*q), unde e este numrul de elemente de context. Calculnd pe exemplul dat O(4*1)=O(4). Deci putem observa o reducere a nivelului de complexitate de 8 ori. 2. Argumentele pentru a stoca preferinele utilizatorului ca parametri ai reelei neuronale n ontologie sunt urmtoarele: i) permite reutilizarea preferinelor nvate de ctre reeaua neuronal: - ntr-o alt aplicaie n care se regsesc aceleai elemente de context i servicii - ntr-o alt aplicaie n care se regsesc parial elementele de context iniiale i serviciile (ca punct de pornire) ii) permite reconfigurarea dinamic (la rulare) a parametrilor reelei (numrul de nivele ascunse, numrul de neuroni de pe fiecare strat, tipul de funcie de activare la fiecare nivel) iii) dac generalizm aceast modalitate de reprezentare cu relaii ponderate actualizate dinamic se poate utiliza pentru a face predicii asupra: - activitii curente, plecnd de la elemente de context de ordin inferior (definit de utilizator, adic personalizat) - preferinele asupra resurselor care s fie folosite de ctre sistem (parametri serviciului)

4.2.3.3 Mecanismul de descoperire a preferinelor propus

Ideea: Se propune nlocuirea parii bazate pe reguli care nu se modific cu un nou mecanism, bazat pe reguli care se modific astfel nct comportamentul sistemului s fie mai adaptat. 54

4.2.3.3.1 Implementarea
4.2.3.3.1.1 Arhitectura sistemului multiagent

Cerinele impuse unui sistem senzitiv la context sunt s permit identificarea persoanelor i obiectelor, interoperativitatea, s aib un comportamentul proactiv, s fie mobil i securizat. Pentru a oferi flexibilitate i reconfigurabilitate sistemul Smart House este bazat pe o arhitectur de ageni distribuit, ierarhic, auto-organizat. Aceasta se compune din apte pri componente care colaboreaz ntre ele, ca n figura 4.11.
Componenta de Raionare i Decizie Knowledge Base Agent Brain Agent Componenta de Interaciune Console Agent
A C L

Componenta pentru Informaii de Context

Information Map Agent

PLATFORMA de AGENI JADE

Componenta de Aciune Mission Agent ACL Action Agent

ACL Location Agent Identity Agent Interpreter Agent Affectivity Agent

White page Services

Yellow Page Services

Authentication Services

Robot Agent Actuator Agent

A C L

Componenta pentru Senzori

Sensor Manager Agent

Componenta fizic Devices Actuators Robots

Temperature Agent

Lightning Agent

Humidity Agent

Proximity Agent

Sensors

Figura 4.11. Arhitectura sistemului multiagent

Componenta de interaciune Permite utilizatorului monitorizarea i controlul asupra dispozitivelor din Casa Inteligent prin intermediul unei interfee grafice. Permite nregistrarea de noi senzori i actuatori, monitorizarea valorilor senzorilor i controlul strii actuatorilor de ctre utilizatori i ofer suport pentru stabilirea de sarcini i misiuni pentru roboi.
55

Componenta pentru informaii de context Componenta pentru informaii de context gestioneaz procesul de achiziie a informaiilor de la componenta pentru senzori i permite celorlalte componente accesul la o aceeai baz de cunotine. Agentul Interpreter agreg datele ce provin de la componenta Senzor, iar agentul Information Map adun informaiile ce provin de la diferite surse din interiorul sau exteriorul casei pentru a fi disponibile componentei de interaciune cu utilizatorul. Componenta de raionare i decizie Aceast component este format din agentul bazei de cunotine (Knowledge Base Agent) i agentul de raionare i decizie (Brain Agent). Primul agent asigur o aceeai baz de cunotine actual, pe ansamblul platformei de ageni. Agentul Brain are dou sarcini: cea de rulare a regulilor folosind Jena i cea de a nva preferinele utilizatorului, cu ajutorul unui sistem expert accesat de ctre acest agent. Agentul de raionare i decizie transmite componentei de aciuni i misiuni care sunt sarcinile pe care este necesar s le ndeplineasc. Componenta de aciuni i misiuni Componenta de aciuni i misiuni opereaz modificri asupra mediului prin actuatori i/sau roboi la modificarea valorilor diferitelor elemente de context. Componenta pentru senzori Aceast component asigur preluarea informaiei brute de la senzorii fizici i transmiterea ei la componenta pentru informaii de context. Agenii senzor preiau urmtoarele date: identificatorul senzorului, valoarea actual citit, eticheta de timp, senzitivitatea. Componenta fizic Aceast component cuprinde senzori, actuatori, dispozitive, obiecte, roboi. Fiecare dintre acestea trebuie conectate la agenii corespunztori, deoarece au platforme de rulare i formate de date diferite. O integrare parial la acest nivel fizic este asigurat de platforma de senzori i actuatori Phidgets pe care am utilizat-o. Platforma de ageni JADE Aceasta asigur comunicarea dintre agenii distribuii pe sisteme diferite de calcul. Pentru aceasta exist un sistem de publicare a agenilor disponibili n cadrul platformei i un mecanism de comunicare i un limbaj specific (Agent Communication Language). Proiectarea sistemului n proiectarea aplicaiei Smart House, s-a decis folosirea platformei multiagent JADE, a descrierii ontologice folosind OWL (Web Ontology Language) a contextului i preferinelor, iar pentru reguli i accesul la informaiile din ontologie pachetul Jena, care are un mecanism de interogare numit SPARQL RDF Query Language.

56

Folosirea unui sistem multiagent este justificat de faptul c exist pri componente cu roluri specifice, cu necesiti de resurse de calcul diferite i distribuite spaial (chiar mobile), relativ autonome. S-a ales platforma JADE deoarece este scris n Java, ceea ce a uurat integrarea cu alte pri ale sistemului bazate de asemenea pe Java. Mai mult, pentru partea de comunicare cu dispozitivele mobile, exist o variant redus a platformei JADE ca numr de funcii disponibile, numit JADE LEAP.

Raionarea Jadex meta-nivel Jadex este o variant de platform JADE pentru ageni BDI (Belief Desire Intention), capabil s comunice cu agenii JADE. Jadex permite raionarea meta-nivel prin folosirea de meta-scopuri i meta-planuri. De fiecare dat cnd are loc un eveniment sau se activeaz un scop, se pune problema gsirii planului optim din mai multe planuri existente printr-un proces de raionare. Evenimentele i scopurile pot fi legate de metascopuri care vor determina executarea unor meta-planuri. n sistemul Smart House s-a decis s se foloseasc raionarea meta-nivel pentru a determina strategia agentului la rulare. Au fost implementate planuri ce corespund diferitelor strategii ale agenilor pentru a decide care este aciunea optim. Limbajul de interogare Jadex (Jadex Query Language) Jadex permite interogarea cunotinelor agenilor dup o sintax similar OQL (Object Query Language) (care este la rndul ei similar SQL, dar extins). n cazul aplicaiei noastre, agenii hrii de informaii de context interogheaz agenii care dein informaia despre contextul curent: senzorii nregistrai, starea senzorilor, valorile citite. Un exemplu, pentru oprirea citirii valorilor de la senzor este urmtorul:
((Sensor)getBeliefbase().getBelief("sensor").getFact()).setDeviceStatus ("OFF");

4.3 Observarea contextului in cazul platformei WComp

Aplicaia descris n aceast seciune const dintr-un modul care se integreaz cu platforma WComp [Cheung06], dezvoltat de partenerii notri de la Universite de Nice, Sophia-Antipolis. Acest modul adaug platformei WComp funcii suplimentare ce privesc gestiunea contextului. Pentru a realiza aceast aplicaie s-a dezvoltat un nou modul numit ContextualDesigner. Acest modul are rolul de a menine o list cu elementele de context i de a seleciona numai acele elemente de context care sunt relevante pentru o anumit aplicaie/serviciu.

4.3.1 Arhitectura aplicaiei realizate

Figura 4.12 ilustreaz componentele principale ale aplicaiei dezvoltate. Platforma de baz utilizat este WComp iar serviciile care se pot construi sunt compuse prin asamblarea de dispozitive UPnP. Exist o baz de date care menine informaii pentru toate aceste dispozitive. Aceast baz de date este accesata de ctre aplicaia Contextual Designer.

57

Aplicaia poate s scrie informaii legate de elementele de context direct n baza de date, la efectuarea iniializrilor (pentru parametri statici), sau prin intermediul unor componente dedicate numite Observatori, care au rolul de a reactualiza informaia de context pentru dispozitivele observate. Utilizatorul definete Observatorii de context, fcnd asociaii ntre observatori, ce dispozitiv este observat, i ce element de context este monitorizat. Un set de reguli de filtrare pot fi definite de ctre utilizator. Aceste reguli permit ngustarea contextului aplicaiei prin eliminarea dispozitivelor care nu sunt de interes pentru un anumit serviciu. Aplicaia comunic cu un container WComp i ii transmite acestuia comenzi de instaniere a componentelor din acelai context, respectiv de eliminare a componentelor ce nu mai aparin contextului. Aplicaia citete din baza de date i reactualizeaz lista dispozitivelor din acelai context cu noi de fiecare dat cnd n reea apare o modificare de dispozitive (un dispozitiv UPnP apare sau dispare), sau n cazul n care un observator a observat o modificare a contextului unui anumit dispozitiv. n acest caz, containerul WComp va fi ntiinat dac s instanieze sau nu dispozitivul. Observatorii pot fi reprezentai de diverse dispozitive UpnP, n principal este vorba despre senzori (temperatur, lumin, prezen etc.).

Figura 4.12. Arhitectura aplicaiei Contextual Designer

4.3.2 Modelarea i observarea contextului

Informaia contextual este compus din elemente de context, grupate n structura arborescent, fiecare frunz avnd o anumit informaie contextual ataat. n figura 4.13 este descris interfaa grafic care permite editarea descrierii contextuale. 58

Utilizatorul poate adaug sau terge frunze, sau poate s modifice structura modelului contextual. Aceasta este o reprezentare foarte simpl, dar este totodat i eficient, deoarece elementele importante i legate se pot reprezenta mpreun i se pot grupa uor n mod ierarhic pentru a reflecta un scenariu real. Modelul contextului, care poate fi construit de utilizator/administrator, se numete context_skeleton i este un fiier xml care are coninut echivalent cu arborele construit de utilizator. Acest context_skeleton poate fi ncarcat de fiecare dat ce aplicaia este modificat, poate fi construit de la zero, poate fi editat sau importat ntre utilizatori.

Figura 4.13. Interfaa grafica a modulului Contextual Designer

Abordarea aleas este una centralizat: exist o baz de date care menine informaia despre context. S-a ales varianta utilizrii unei baze de date cu stocare n format XML deoarece este puin costisitoare i ofer o alternativ simpl la un limbaj structurat mai sofisticat. Aplicaia folosete baza de date ca un registru central pentru o mai bun reprezentare a contextului.

4.3.3 nregistrarea dispozitivelor

Dispozitivele care vor fi folosite de ctre aplicaie vor trebui s treac printr-un proces de nregistrare. Dup acest proces de nregistrare, dispozitivul sau serviciul poate fi asociat unui context, iar acest context poate suferi schimbri de-a lungul timpului, schimbri ce vor fi observare de ctre componentele-observatori. Acest proces de nregistrare de dispozitive presupune adugarea unei nregistrri n baza de date local. nregistrarea va conine toate informaiile necesare despre dispozitivul real. Dispozitivul

59

nregistrat poate fi apoi interogat pentru a obine informaii despre acesta sau poate fi folosit pentru a executa diverse servicii pe care le ofer. Cnd dispozitivele sunt adugate n registrul central, acestea sunt de asemenea adugate n fiierul xml, care are o structur asemntoare fiierului context skeleton. Pentru a iniializa un anumit dispozitiv, acesta trebuie s fie prezent n reea. Dac dispozitivul prsete reeaua dar a fost deja nregistrat n baza de date, acesta va rmne acolo pentru folosiri ulterioare. n cazul n care dispozitivul este prezent, acest lucru este vizibil. Putem construi servicii doar cu dispozitivele prezente i nregistrate. n cazul n care un dispozitiv reintra n funciune, acesta va anuna n reea prezenta sa prin mijloace specifice protocolului UpnP. Acest lucru declaneaz un eveniment ce va duce la modificarea statusului dispozitivului n baza noastr de date, fiind apoi vzut ca prezent. Dup aceasta, este posibil construirea de aplicaii i servicii cu acest dispozitiv n interiorul platformei WComp.

4.3.4 Observarea i filtrarea contextului

Observatorii. S presupunem c lucrm cu senzori statici care sunt iniializai i au toi parametrii stabili i nu se modific n timp. n acest caz nu avem de-a face cu un context dinamic, deoarece nimic nu se schimb pentru nici un dispozitiv. Dac am vrea s lucrm cu dispozitive mobile de exemplu, sau alte tipuri de dispozitive care i schimb contextul foarte uor, putem ajunge ntr-o situaie n care nu putem urmri toate modificrile mediului nconjurtor (deoarece se schimb prea repede) i trebuie s avem un sistem care s actualizeze informaia despre utilizatorii mobili, n baza de date. O soluie este s definim serviciile UPnP din reea care observ alte dispozitive i, pentru o modificare a contextului acestora, baza de date s fie actualizat. Pentru aceasta, este necesar s meninem un tabel n care asociem unui element de context un anumit dispozitiv de observare. Filtrarea. Filtrarea este procesul de definire a contextului de interes pe baza unui set de reguli. Acest context nu trebuie s aib neaprat structura modelului de context, dar trebuie s conin elemente similare. De exemplu, am putea considera ca fiind contextul de interes mulimea dispozitivele din cldirea universitii, sau numai pe cele dintr-o singura sal. Putem de asemenea construi contexte compuse, care privesc 2 sau 3 camere i numai anumite tipuri de dispozitive. Adaptarea. n aceast aplicaie, adaptarea este o instaniere, n interiorul platformei Wcomp, a dispozitivelor care sunt n contextul de interes. n cazul n care avem deja dispozitive instaniate, iar contextul lor este diferit dup actualizare, se procedeaz la o eliminare a acestor dispozitive din platforma WComp. Adaptarea este rezultatul aplicrii filtrrii asupra dispozitivelor din baza de date, care este actualizat de ctre observatori pentru a reflecta situaia curent a contextului fiecrui dispozitiv monitorizat.

4.3.5 Testarea aplicaiei

Scenariul 1. S presupunem c avem o mulime de senzori prezeni n cldirea universitii. Aceti senzori au poziii fixe i sunt montate n diverse ncperi i nu se
60

mic. Dispozitivele-senzori ader la standardul UPnP i sunt conectai la reea, avnd adrese IP i sunt n stare de funcionare. S presupunem c vrem s crem o aplicaie cu ajutorul WComp care va folosi doar senzorii din camera 101 de la etajul 1 n interiorul cldirii principale. Cu ajutorul modulului Contextual Designer, putem filtra contextul definind regulile care specific aceast locaie. Se presupune c am iniializat dispozitivele pe care le vom folosi n coal, avnd informaie contextual asociat caracteristicilor statice. Filtrarea va fi realizat n interiorul WComp, adic pentru fiecare dispozitiv care aparine contextului nostru s avem o instaniere a unei componente n WComp, iar pentru o component cu contextul schimbat i care nu mai este de interes s obinem o instaniere.

Scenariul 2. S presupunem c ne aflm n cldirea Universitii. Studenii sunt dotai cu carduri de identificare RFID care pot fi citite de un sistem de tipul Badge Reader UPnP. s presupunem c aceti studeni dein laptopuri sau dispozitive mobile, asociate lor, compatibile cu standardul UPnP. n cazul n care un profesor intr n sala 203 i vrea s creeze o aplicaie n WComp, pe laptopul su, ar putea defini urmtoarele reguli: se utilizeaz toate dispozitivele mobile apartinnd studenilor din sala 203 i cu videoproiectorul din sala 203. Dup definirea cererii prin reguli simple, el va obine n WComp componente ce sunt instane ale dispozitivelor din sala 203. n cazul n care un student prsete camera, dispozitivul su va fi deinstaniat din cadrul platformei WComp. Acest scenariu presupune c avem deja o baz de date cu dispozitive i informaia lor contextual. Aceste dispozitive au parametri statici deja definii i vom vrea s asociem nite observatori care vor actualiza parametrii dinamici pentru fiecare dispozitiv.

61

5 Concluzii i dezvoltri viitoare

n acest raport se trateaz problema modelrii i descoperirii contextului din punct de vedere al autonomiei adaptrii. Spre deosebire de soluiile tradiionale contextaware unde contextul este stabilit a priori de ctre dezvoltatorul de servicii, ntr-un sistem cu adaptare autonom, este necesar s existe un mecanism de descoperire a contextului. Aa cum am artat n introducere, pentru a atinge acest deziderat este necesar soluionarea a dou probleme fundamentale: P1) Determinarea profilului P al unui serviciu S, dac se cunosc arhitectura intern a serviciului i profilele componentelor sale interne Ci. P2) Identificarea surselor de informaie (senzori, servicii de observare) care pot furniza informaii despre contextul indicat de ctre profilul P al serviciului S. La aceste dou probleme se adaug o a treia problem, P3, transversal fa de cele dou enunate mai sus, i care privete modul de reprezentare (modelare) a informaiei despre serviciu i context. Problema P1 are o rezolvare propus n teza [Crem05phd], dar care prezint limitri n ceea ce privete expresivitatea descrierii componentelor/serviciilor. n acelai timp, n urma studiilor efectuate, a rezultat c aceast problema este foarte puin abordat n literatura de specialitate. Acest problem va fi reluat n urmtoarea faz a proiectului. Problema P2 se identific cu ceea ce n literatura de specialitate se numete context discovery. O serie de soluii existente sunt prezentate n capitolul 3. O soluie de principiu este s considerm descoperirea contextului ca fiind de fapt descoperirea de servicii ce ofer informaii despre context. Un rol important l joac aici modul n care sunt descrise aceste servicii, meta-datele asociate acestor servicii. n ceea ce privete a treia problema, a modelrii serviciilor i contextului, concluziile studiului nostru sunt c la ora actual modelul considerat a fi cel mai expresiv i bogat este cel ontologic. Totui, n funcie de tipul de aplicaie, dac nu este neaprat necesar descrierea de relaii complexe ntre elementele de context, se pot utiliza cu succes i liste simple sau ierarhizate de elemente/atribute de context. Au fost dezvoltate urmtoarele aplicaii ce pun n eviden problema observrii contextului: - O aplicaie de adaptare a unei aplicaii de comer electronic n funcie de tipul de moned utilizat, folosind o reprezentare a contextului de tip list simpl atributvaloare. - O aplicaie de adaptare a comportamentului unei case inteligente n funcie de nevoile utilizatorului, bazat pe ageni, unde se utilizeaz o reprezentare ontologic complex a contextului. - O aplicaie de adaptare prin filtrarea contextului relevant pentru un serviciu i un utilizator, bazat pe platforma WComp, unde se utilizeaz o reprezentare a contextului bazat pe o list ierarhizat. - O aplicaie de compunere de servicii la cerere (descris detaliat n raportul tehnic referitor la scenarii/2008), unde contextul este descris printr-o list de cuvinte utilizate de utilizator pentru a-i exprima cererea n limbaj natural.

62

O concluzie care a rezultat n urma evalurii rezultatelor acestor aplicaii este c modelul cel mai potrivit pentru reprezentarea contextului este un model care poate fi extins uor, de la o simpla list de atribute pn la un model ontologic, n funcie de specificul aplicaiei. Un astfel de model ar trebui actualizat folosind un protocol de descoperire a serviciilor ce furnizeaz informaii despre context. Rmne ca dezvoltare viitoare problema agregrii i interpretrii automatizate a informaiilor despre serviciu i context.

63

Bibliografie
[Anind00] Anind, K. D., Providing Architectural Support for Building Context-Aware Applications, PhD thesis, College of Computing, Georgia Institute of Technology, December 2000. [Anind01] Anind, K. D., Daniel, S., Gregory, D. A., A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications, Anchor article of a special issue on context-aware computing in the Human-Computer Interaction (HCI) Journal, Volume 16 (2-4), 2001. [Bill93] Bill, N. S., Marvin, M., Theimer and Brent, B. W., Customizing Mobile Application. Proceedings of the USENIX Symposium on Mobile and Locationindependent Computing, Cambridge, MA, August 1993. [Bill94] Bill, N. S., Norman, A., RoyWant, Context-aware computing applications. Proceedings Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, US, Decembrie 1994. [Bill95] Bill, N. S., A Context-Aware System Architecture for Mobile Distributed Computing. PhD Thesis, Columbia University, Mai 1995. [Brdi06] Brdiczka, O., Reignier, P., Crowley, J. L., Vaufreydaz, D., Maisonnasse, J., Deterministic and Probabilistic Implementation of Context. Proceedings of Fourth IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW'06), 2006. [Chen04] Chen, H., Finin, T., Joshi, A., Kagal, L., Perich, F., Chakraborty, D., Intelligent Agents Meet the Semantic Web in Smart Spaces. IEEE Internet Computing 8(6), 2004. [Crem05pdh] Teza Adaptation Dynamique de Services, conducator prof. Dr, ing. Costin MIRON, (Traian Muntean, rapporteur, Universite de la Mediterranee, Marseille, Florian-Mircea Boian, rapporteur, Universite Babes-Bolyai,Cluj-Napoca, Mircea Florin Vaida, rapporteur, Universite Technique de Cluj-Napoca, Michel Riveill, directeur, Universite de Nice, Christian Martel, co-directeur, Universite de Savoie, Costin Miron, directeur, Universite Technique de Cluj-Napoca), co-tutela cu Universite de Savoie, FRANCE. [Dey00] A. K. Dey, Providing Architectural Support for Building Context-Aware Applications. PhD Thesis, Georgia Institute of Technology, Noiembrie, 2000. [Dey01] A. K. Dey, D. Salber, G. Abowd, A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Special Issue on Context-Aware Computing Human-Computer Interaction (HCI) Journal, 16(2-4), 2001.

64

[Ejigu07] Ejigu, D., Scuturici, M., Brunie, L., An Ontology-Based Approach to Context Modeling and Reasoning in Pervasive Computing,Proceedings of the Fifth IEEE international Conference on Pervasive Computing and Communications Workshops, March 19 - 23, 2007, PERCOMW. IEEE Computer Society, Washington, DC, 14-19. [Enrico04] Enrico, R., George, N. P., Giovanni, C., Eleftherios, K., Sofia, K., Context for Simplicity: A Basis for Context-aware Systems Based on the 3GPP Generic User Profile. Proceedings of International Conference on Computational Intelligence, Istanbul, Turkey, Decembrie 2004. [Fabi04] Fabian, A., Jan, B., Using Semantic Web Technologies for context-aware Information Providing to Mobile Devices. Technical Report, Distributed Systems Institute - Knowledge Based Systems, Leibniz University Hannover, 2004. [Fers06] Ferscha, A., Hechinger, M., Riener, A., Schmitzberger, H., Franz, M., dos Santos Rocha, M., Zeidler, A., Context-Aware Profiles. Proceedings of the international Conference on Autonomic and Autonomous Systems, Washington, DC, USA, Iulie 2006. [Fitz02] Fitzpatrick, A., Biegel, G., Clarke, S., Cahill, V., Towards a Sentient Object Model. Workshop on Engineering Context-Aware Object Oriented Systems and Environments (OOPSLA/ECOOSE'02), Seattle, Washington, USA, 2002. [Flan05] John Flanagan, Context awareness in a mobile device: Ontologies versus unsupervised/supervised learning, in Timo Honkela, Ville Knnen, Matti Pll, and Olli Simula, editors, Proceedings of AKRR'05, International and Interdisciplinary Conference on Adaptive Knowledge Representation and Reasoning, pages 167-170, Espoo, Finland, June 2005. [Ghita04] Ghita, K. M., Jacques, P. R., Patrick, B., Context-Aware Computing: A Guide for the Pervasive Computing Community. ICPS '04: Proceedings of the The IEEE/ACS International Conference on Pervasive Services, 2004. [Glass03] R. Glassey, G. Stevenson, M. Richmond, P. Nixon, S. Terzis, F. Wang, I. Ferguson, Towards a Middleware for Generalised Context Management. First International Workshop on Middleware for Pervasive and Ad Hoc Computing (Middleware 2003), 2003. [Gu04] T. Gu, H. K. Pung, D. Q. Zhang, A middleware for building context-aware mobile services. Proceedings of IEEE Vehicular Technology Conference, Italia, 2004. [Gu05] T. Gu, H. K. Pung, D. Q. Zhang, A Service-oriented middleware for building context-aware services. Journal of network and computer applications, 28(1), 2005. [Guan07] Guan, D. Yuan, W. Cho, S. J. Gavrilov, A. Lee, Y.-K. Lee, S. Devising a Context Selection-Based Reasoning Engine for Context-Aware Ubiquitous Computing

65

Middleware, LECTURE NOTES IN COMPUTER SCIENCE, 2007, No 4611, pages 849-857, SPRINGER-VERLAG, Germany ISBN 978-3-540-73548-9, ISSN 0302-9743 [Heinz99] W. R. Heinzelman, J. Kulit, H. Balakrishnan, Adaptive protocols for information dissemination in wireless sensor networks. International Conference Mobile Computing and Networking MOBICOM, Seattle, WA, 1999. [Held02] Held, A., Buchholz, S., Schill, A., Modeling of Context Information for Pervasive Computing Applications. Proceedings of the 6th World Multiconference on Systemics, Cybernetics and Informatics (SCI2002), Orlando, Florida, USA, iulie 2002. [Henri03] Henricksen, K., Indulska, J., Rakotonirainy, A., Generating Context Management Infrastructure from High-level Context Models. Proceedings of the 4th International Conference on Mobile Data Management, Melbourne, January 2003. [Henri06] Henricksen, K., Indulska, J., Developing context-aware pervasive computing applications: Models and approach. Journal of Pervasive and Mobile Computing, 2(1), February 2006. [Henri06] Henricksen, K., Indulska, J., Rakotonirainy, A., Using context and preferences to implement self-adapting pervasive computing applications, Softwarepractice & Experience, vol 36, issue 11-12, pag. 1307-1330, Ed. John Wiley & Sons Ltd, 2006. [Indul03] Indulska, J., Robinson, R., Rakotonirainy, A., Henricksen, K., Experiences in using CC/PP in context-aware systems. Proceedings of the 4th International Conference on Mobile Data Management, LNCS 2574. Melbourne, Australia, Januarie, 2003. [Inta03] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Heidemann, F. Silva, Directed Diffusion forWireless Sensor Networking. IEEE/ACM Transactions on Networking, Vol 11, No.1, Februarie 2003. [Inta00] C. Intanagonwiwat, R. Govindan, D. Estrin, Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks. Proceedings of the 6th Annual ACM/IEEE International Conference on Mobile Computing and Networking, Statele Unite, 2000. [Kamr06] Md. Kamrul Hasan, Kim Anh, Lenin Mehedy, Young-Koo Lee and Sungyoung Lee, Conflict Resolution and Preference Learning in Ubiquitous Environment, In the 2006 International Conference on Intelligent Computing (ICIC 2006, LNAI 4114 0355), Kunming Yunnan Province, China. http://www.ic-ic.org/2006/, August 16-19, 2006 [Kim05] Kim Anh Pham Ngoc, Young-Koo Lee, Sungyoung Lee, OWL-Based User Preference and Behavior Routine Ontology for Ubiquitous System, pag. 1615-1622, Springer, Lecture Notes in Computer Science, vol.3761, 2005, ISBN 3-540-29738-3. 66

[Kim05] Kim Anh Pham Ngoc, User Preference Learning in Context-aware Computing, master thesis, Department of Computer Engineering, Faculty of Graduate School of Kyung Hee University, Korea, November 2005. [Liu07] F. Liu, G. Heijenk, Context Discovery Using Attenuated Bloom filters in Ad-hoc Networks. Journal of Internet Engineering, Vol. 1, No. 1, 2007. [Loke04] Loke, S.W., Logic Programming for Context-Aware Pervasive Computing: Language Support, Characterizing Situations, and Integration with the Web. Web Intelligence Conference, 2004. [Loke06] Loke, S.W., On Representing Situations for Context-Aware Pervasive Computing: Six Ways to Tell if You are in a Meeting. Proceedings of 3rd Workshop on Context Modeling and Reasoning, Pisa, Italia, Martie 2006. [Luca06] Luca Buriano, Marco Marchetti, Francesca Carmagnola, Federica Cena, Cristina Gena, Ilaria Torre, "The Role of Ontologies in Context-Aware Recommender Systems", Mobile Data Management, IEEE International Conference on, vol. 0, no. 0, pp. 80, 7th International Conference on Mobile Data Management (MDM'06), 2006. [McCar93] McCarthy, J., Notes on formalizing context. Proceedings of the Thirteenth international joint conference on artificial intelligence, Chambery, France, 1993. [McCar97] McCarthy, J., Buvac, S., Formalizing Context (Expanded Notes). Working Papers of the {AAAI}, Fall Symposium on Context in Knowledge Representation and Natural Language, American Association for Artificial Intelligence, Menlo Park, California, 1997. [Nick] Nick, R., ConteXtML: Exchanging Contextual Information between a Mobile Client and the FieldNote Server. Computing Laboratory, University of Kent at Canterbury, http://www.cs.kent.ac.uk/projects/mobicomp/fnc/ConteXtML.html [Nish05] Nishigaki, K.; Yasumoto, K.; Shibata, N.; Ito, M.; Higashino, T., "Framework and rule-based language for facilitating context-aware computing using information appliances," Distributed Computing Systems Workshops, 2005. 25th IEEE International Conference on , vol., no., pp. 345-351, 6-10 June 2005. [Oh05] Oh, Y., Shin, C., Jang, S., Woo, W., ubi-UCAM 2.0: A Unified Context-aware Application Model for Ubiquitous Computing Environments. Proceedings of the First Korea/Japan Joint Workshop on Ubiquitous Computing & Networking Systems (ubiCNS2005), Jeju, Korea, Iunie, 2005. [perv04] http://pervasive.semanticweb.org/soupa-2004-06.html

67

[Reto07] Reto Krummenacher, Thomas Strang, Ontology-Based Context Modeling, 3rd Workshop on Context Awareness for Proactive Systems, June 2007. [Rob07] Robinson, R., Henricksen, K., Indulska, J., XCML: A runtime representation for the Context Modelling Language. Proceedings of 4th International Workshop on Context Modelling and Reasoning (CoMoRea), PerCom'07 Workshop Proceedings, IEEE Computer Society, Martie 2007. [Schm01] Schmidt, A., Laerhoven, K. V., How to Build Smart Appliances?. IEEE Personal Communications 8(4), August 2001. [Sheng05] Sheng, Q. Z. and Benatallah, B., ContextUML: A UML-Based Modeling Language for Model-Driven Development of Context-Aware Web Services Development. Proceedings of the international Conference on Mobile Business (Icmb'05) - Volume 00 (July 11 - 13, 2005), ICMB, IEEE Computer Society, Washington, DC, 206-212. [Steph04] Stephen S. Yau, Deepak Chandraseka, Dazhi Huang, An Adaptive, Lightweight and Energy-Efficient Context Discovery Protocol for Ubiquitous Computing Environments. 10th IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS'04), China, 2004. [Thom04] Thomas, S., Claudia, L .P., A Context Modeling Survey. Workshop on Advanced Context Modelling, Reasoning and Management, Nottingham/England, Septembrie 2004. [Tim00] Tim, K., John, B., Jeff, M., Gene, B., Debbie, C., Philippe, D., Gita, G., Marcos, F., Venky, K., Howard, M., John, S., Bill, S., People, Places, Things: Web Presence for the Real World. Proceedings of the Third IEEE Workshop on Mobile Computing Systems and Applications (WMCSA'00), 2000. [Voel94] Voelker, G. M., Bershad, B. N., Mobisaic: An Information System for a Mobile Wireless Computing Environment. Proceedings of the IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, California, USA, Decembrie 1994. [Xiao04] Xiaohang Wang, Daqing Zhang, Tao Gu, and Hung Keng Pung. Ontology Based Context Modeling and Reasoning using OWL. In Proceedings of Workshop on Context Modeling and Reasoning (CoMoRea '04), in conjunction with the 2nd IEEE International Conference on Pervasive Computing and Communications (PerCom '04), Orlando, Florida USA, March 2004. [Yau06] Yau, S. S., Liu, J., Hierarchical Situation Modeling and Reasoning for Pervasive Computing, Proceedings of the the Fourth IEEE Workshop on Software Technologies For Future Embedded and Ubiquitous Systems, and the Second international Workshop on Collaborative Computing, integration, and Assurance (Seus-

68

Wccia'06), vol. 00, April 27 - 28, 2006. SEUS-WCCIA. IEEE Computer Society, Washington, DC, 5-10. [Youn05] Youngjung Suh, Dongoh Kang, Woontack Woo, Context-based User Profile Management for Personalized Services, ubiComp, workshop ubiPCMM, 2005. [Cheung06] Cheung-Foo-Wo (D.), Tigli (J.-Y.), Lavirotte (S.), and Riveill (M.). Wcomp: a multi-design approach for prototyping applications using heterogeneous resources. In 17th IEEE Intern. Workshop on Rapid Syst. Prototyping, pages 119125, Crete, 2006.

69