Adaptarea Robotilor Intr-Un Sistem Senzitiv La Context Pentru o Casa Inteligenta

UNIVERSITATEA TEHNIC CLUJ-NAPOCA
FACULTATEA DE AUTOMATIC I CALCULATOARE

SECIA CALCULATOARE
LUCRARE DE DIPLOM
ADAPTAREA ROBOILOR
NTR-UN SISTEM SENZITIV LA CONTEXT
PENTRU O CAS INTELIGENT
MIHAI GABRIEL RAIU
2009
UNIVERSITATEA TEHNIC CLUJ-NAPOCA

FACULTATEA DE AUTOMATIC I CALCULATOARE
SECIA CALCULATOARE
VIZAT DECAN
Prof.Dr.Ing. Sergiu NEDEVSCHI
VIZAT EF CATEDR
Prof.Dr.Ing. Rodica POTOLEA
ADAPTAREA ROBOILOR NTR-UN SISTEM

SENZITIV LA CONTEXT PENTRU O CAS INTELIGENT
Absolvent: Mihai Gabriel Raiu
1.
CONINUTUL PROIECTULUI:
A. Piese Scrise
Introducere
Studiu bibliografic
Fundamentare teoretic
Specificaiile i arhitectura sistemului
Proiectarea de detaliu
Utilizarea sistemului
Punerea n funciune i rezultate experimentale
Concluzii
Bibliografie
B. Anexe
CD coninnd piesele scrise, codul surs i uneltele folosite
2.
LOCUL DOCUMENTAIEI: Universitatea Tehnic Cluj-Napoca
3.
CONSULTANI: Asist. Ing. Lucia Vcariu
4.
DATA EMITERII TEMEI: 1.10.2008
5.
TERMEN DE PREDARE: 19.06.2009
CONDUCTOR DE PROIECT
Asist. Ing. Lucia Vcariu
SEMNTUR ABSOLVENT
Mihai Gabriel Raiu
Cuprins
1
INTRODUCERE...............................................................................................................1
STUDIU BIBLIOGRAFIC..............................................................................................3
2.1
Case inteligente...........................................................................................................3
2.2
Sisteme senzitive la context........................................................................................5
2.2.1 Concepte de baz....................................................................................................5
2.2.1.1 Context............................................................................................................5
2.2.1.2 Senzitivitate la context....................................................................................5
2.2.1.3 Sistem Senzitiv la Context..............................................................................5
2.2.2 Paradigma Ubiquitous Computing..........................................................................6
2.2.2.1 Definiii...........................................................................................................6
2.2.2.2 Caracteristici...................................................................................................6
2.2.3 Ontologie.................................................................................................................7
2.2.3.1 Definiii...........................................................................................................7
2.2.3.2 Caracteristici...................................................................................................7
2.2.4 Ageni senzitivi la context......................................................................................8
2.2.4.1 Paradigma agentului........................................................................................8
2.2.4.2 Ageni BDI......................................................................................................8
2.3
Arhitecturi de sisteme senzitive la context.................................................................9
2.3.1 Arhitecturi de sisteme senzitive la context locale...................................................9
2.3.1.1 Modelul arhitectural stratificat Context Stack.............................................9
2.3.2 Arhitecturi de sisteme distribuite senzitive la context..........................................11
2.3.2.1 Serviciile Web Semantice.............................................................................12
2.3.2.2 Arhitectura Serviciilor Web Semantice.........................................................13
2.4
Medii de dezvoltare ale aplicaiilor senzitive la context...........................................15
2.5
Aplicaii n domeniul caselor inteligente..................................................................16
2.6
Dificulti i riscuri ntmpinate n crearea aplicaiilor senzitive la context............18
2.7
Proiecte ample de cercetare n desfurare...............................................................20
FUNDAMENTARE TEORETIC...............................................................................22
3.1
Modelarea formal a contextelor..............................................................................22
3.1.1 Ageni bazai pe cunotine...................................................................................22
3.1.1.1 Baze de date de cunotine............................................................................22
3.1.2 Reprezentarea cunotinelor..................................................................................23
3.1.3 Folosirea ontologiilor n modelarea contextelor...................................................24
3.1.3.1 Modelarea contextului cu ontologii..............................................................24
3.1.3.2 Proiectarea ontologiilor de context...............................................................25
3.1.3.3 Limbajul OWL..............................................................................................28
3.1.4 Extensii probabilistice ale ontologiilor.................................................................29
3.2
Metode folosite pentru modelarea bazelor de cunotine.........................................32
3.2.1 Metodologii existente pentru crearea bazelor de cunotine.................................32
3.2.2 Unelte de dezvoltare a ontologiilor.......................................................................33
3.2.2.1 Protg 4.......................................................................................................34
3.3
Metode folosite pentru dezvoltarea agenilor...........................................................35
3.3.1 Platforme de dezvoltare a agenilor......................................................................35
3.3.2 Platforma JADE....................................................................................................37
3.3.3 Mediul JADEX 0.96.............................................................................................38
3.3.3.1 Modelul BDI definit n Jadex.......................................................................38
3.3.3.2
Definirea agenilor n Jadex..........................................................................40
SPECIFICAII I ARHITECTUR SISTEM............................................................41

4.1
Specificaiile sistemului............................................................................................41
4.1.1 Controlul casei inteligente....................................................................................41
4.1.1.1 Coordonarea aciunilor..................................................................................41
4.1.1.2 Executarea operaiilor...................................................................................41
4.1.1.3 Interaciunea cu utilizatorii...........................................................................41
4.1.2 Monitorizarea casei inteligente.............................................................................42
4.1.2.1 Achiziia datelor de context..........................................................................42
4.1.2.2 Procesarea datelor de context........................................................................42
4.1.2.3 Propagarea datelor de context.......................................................................42
4.1.3 Adaptarea roboilor la casa inteligent.................................................................43
4.1.3.1 Reprezentarea adecvat a roboilor...............................................................43
4.1.3.2 Comunicarea dintre roboi............................................................................43
4.1.3.3 Serviciile roboilor din casa inteligent........................................................43
4.2
Arhitectura sistemului...............................................................................................44
4.2.1 Nivelul Senzorial..................................................................................................44
4.2.2 Nivelul Dispozitivelor...........................................................................................44
4.2.3 Nivelul Roboilor..................................................................................................45
4.2.4 Nivelul Decizional................................................................................................45
4.2.5 Nivelul de control i monitorizare........................................................................46
4.2.6 Nivelul fizic..........................................................................................................46
PROIECTARE DE DETALIU.......................................................................................47
5.1
Analiza cerinelor......................................................................................................47
5.2
Proiectarea arhitecturii..............................................................................................48
5.2.1 Sistemul de roboi.................................................................................................48
5.2.1.1 Agentul Robot Manager................................................................................49
5.2.1.2 Agentul Robot Supraveghetor.......................................................................50
5.2.1.3 Agentul Robot Misiune.................................................................................51
5.2.1.4 Agentul Robot Divertisment.........................................................................54
5.2.2 Sistemul de senzori...............................................................................................54
5.2.3 Sistemul de dispozitive.........................................................................................55
5.2.4 Sistemul de control...............................................................................................56
5.2.5 Sistemul de monitorizare......................................................................................56
5.2.6 Proiectarea bazei de cunotine.............................................................................57
5.3
Detalii de implementare............................................................................................57
5.3.1 Caracteristici generale legate de implementarea sistemului.................................57
5.3.1.1 Pachetele aplicaiei........................................................................................58
5.3.2 Implementarea agenilor.......................................................................................58
5.3.2.1 Implementarea fiierelor de descriere a agenilor.........................................58
5.3.2.2 Implementarea planurilor..............................................................................60
5.3.3 Interfee Utilizator.................................................................................................61
5.4
Scenariu de testare....................................................................................................61
UTILIZAREA SISTEMULUI.......................................................................................62
PUNERE N FUNCIUNE I REZULTATE EXPERIMENTALE..........................64

7.1
Tehnologii folosite....................................................................................................64
7.1.1 Cerine Hardware..................................................................................................64
7.1.2 Cerine Software...................................................................................................64

7.1.3 Instalarea aplicaiilor folosite................................................................................64
7.1.4 Configurarea proiectului.......................................................................................65
7.1.5 Pornirea Platformei de Ageni...............................................................................65
7.1.6 Pornirea agentului pentru baza de cunotine a sistemului...................................66
7.1.7 Pornirea agentului manager de senzori.................................................................66
7.1.8 Pornirea agentului manager de dispozitive...........................................................66
7.1.9 Pornirea agentului de monitorizare.......................................................................66
7.1.10
Pornirea agentului manager pentru roboi.........................................................67
7.2
Probleme ntmpinate i modul de rezolvare............................................................67
7.2.1 Probleme de pornire a platformei de ageni..........................................................67
7.2.2 Probleme de pornire a agenilor............................................................................67
7.3
Rezultate experimentale............................................................................................67
7.3.1 Crearea roboilor...................................................................................................67
7.3.2 Adaptarea roboilor...............................................................................................70
8
CONCLUZII...................................................................................................................72
8.1
Realizri....................................................................................................................72
8.2
Direcii de dezvoltare................................................................................................73
BIBLIOGRAFIE.............................................................................................................75
Cuprins
Lista de Tabele
Tabel 2.1 Clasificarea roboilor utilizai n locuine...................................................................4
Tabel 3.1 Comparaie ntre SOCAM i CoOL privind modelarea ontologiilor de context......27
Tabel 3.2 O parte din regulile de argumentare OWL................................................................29
Cuprins
Lista de Figuri
Figura 2.1 Tendina n vnzarea roboilor de cas pe piaa japonez.........................................4
Figura 2.2 Modelul arhitectural Context Stack.........................................................................10
Figura 2.3 Comparaie ntre SemanticURS i sistemele tradiionale........................................12
Figura 2.4 Clasele componente ale unei ontologii de tip OWL-S............................................13
Figura 2.5 Arhitectura detaliat a Semantic URS.....................................................................14
Figura 2.6 Procedura de integrare automat a unui agent SemanticURS.................................15
Figura 2.7 Diagrama de interaciune ntre modulele componente ale JCAF............................15
Figura 2.8 Arhitectura general cu diagrame de colaborare a JCAF........................................16
Figura 2.9 Arhitectura de tip OSGi pentru o cas senzitiv la context.....................................17
Figura 3.1 Cazul general de programare a unui agent bazat pe cunotine...............................23
Figura 3.2 Exemplu de modelare a unei ontologii superioare..................................................24
Figura 3.3 Definire ontologii specifice reprezentate prin reele Bayesiene..............................26
Figura 3.4 Model de proiectare a ontologiilor contextuale, folosind SOCAM........................26
Figura 3.5 (a) Schema relaional i (b) Modelul probabilistic pentru o cas inteligent........30
Figura 3.6 Arhitectura SOCAM cu ontologii specifice i modele probabilistice.....................31
Figura 3.7 Procesul de dezvoltare a unei baze de cunotine folosind Methontology..............32
Figura 3.8 Arhitectura general a unei platforme de ageni i comunicarea ntre platforme....36
Figura 3.9 Platforma, depozitele i comunicaiile ntre platforme JADE................................38
Figura 3.10 Diagrama de colaborare ntre componentele unui agent Jadex.............................39
Figura 4.1 Diagrama arhitectural a sistemului........................................................................45
Figura 5.1 Diagrama de interaciune ntre actorii i sistemul casei inteligente........................48
Figura 5.2 Diagrama de obiective a sub-sistemului de roboi..................................................49
Figura 5.3 Obiectivele robotului transportor n casa inteligent...............................................52
Figura 5.4 Sistemul de senzori al casei inteligente...................................................................55
Figura 5.5 Sistemul de dispozitive al casei inteligente.............................................................56
Figura 5.6 Obiectivele sistemului de control al casei inteligente.............................................56
Figura 5.7 Antetul fiierului de descriere a agenilor ADF.......................................................59
Figura 5.8 Schema de definire a unui agent Jadex....................................................................59
Figura 5.9 Definirea planului de micare pentru robotul transportor.......................................60
Figura 6.1 Reprezentarea robotului transportor........................................................................62
Figura 6.2 Panoul de control al simulatorului...........................................................................62
Figura 6.3 Consola agentului pentru baza de cunotine..........................................................63
Figura 7.1 Pornirea platformei de ageni din Eclipse...............................................................65
Figura 7.2 Platforma de ageni Jadex........................................................................................66
Figura 7.3 Clasele ontologice specifice agenilor roboi..........................................................68
Figura 7.4 Proprieti individuale specificate n modelul ontologic - robot supervizor...........68
Figura 7.5 Mesajul trimis ctre agentul bazei de cunotine pentru identificarea roboilor.....69
Figura 7.6 Mesajul cu coninutul instanelor de roboi trimis de agentul bazei de cunotine. 69
Figura 7.7 Mesaje ACL transmise ntre agentul robot transportor i sistemul casei inteligente
...................................................................................................................................................70
Figura 7.8 Consola agentului Manager pentru roboii casei inteligente i planurile executate 71
Introducere
INTRODUCERE
Acest capitol prezint motivaiile temei, ncadrarea temei n domeniile pe care le

acoper, problemele aprute n elaborarea sistemelor senzitive la context pentru case
inteligente, abordarea acestor probleme n elaborarea sistemului dezbtut n lucrarea curent.
Cercetrile curente n domeniul sistemelor senzitive la context adaug unele soluii
problemelor legate de adaptarea contextual a serviciilor, dispozitivelor electronice sau
sistemelor la mediile fizice sau computaionale. Tema de fa propune o soluie pentru crearea
unui sistem senzitiv la context pentru o cas inteligent i o soluie de adaptare a roboilor
ntr-un astfel de mediu.
Tehnologiile pentru case inteligente se refer la un domeniu colectiv care cuprinde
tehnologii informaionale i comunicaionale care pot fi folosite n locuine, unde diferite
componente comunic printr-o reea local. Tehnologia este folosit pentru a supraveghea,
ateniona sau facilita diferite aciuni care se petrec n locuin, actorii principali fiind locuitorii
acesteia. Tehnologiile pentru case inteligente druiesc o flexibilitate i funcionalitate total
diferit fa de instalaiile convenionale, datorit integrrii unitilor programabile care
comunic prin mesaje de reea.
Crearea sistemelor senzitive la context, distribuite i omniprezente se confrunt cu un
numr mare de probleme care se ridic n momentul proiectrii lor, ncepnd de la problemele
specifice care apar n momentul construirii unui sistem distribuit, probleme care au legtur
cu integrarea diferitelor componente, asigurarea interoperabilitii ntre dispozitive de calcul
eterogene, scalabilitatea, extensibilitatea, securitatea sau tolerana la erori. Pe lng
problemele enumerate se mai adaug problemele specifice tehnologiilor senzitive la context
care adaug problemele legate de procesarea datelor de context achiziionate, care de cele mai
multe ori conin zgomote sau erori care trebuie identificate i filtrate, iar din aceste date venite
de la nivelul fizic al aplicaiei este necesar deducerea de noi contexte bazate pe procedee
preluate din domeniul inteligenei artificiale.
Unul din cele mai interesante puncte de cercetare n domeniul sistemelor senzitive la
context pentru case inteligente este centrat pe descoperirea inteniilor locatarilor casei i
reacia sistemului care va furniza un rspuns optim pentru a satisface nevoile i doleanele
locatarilor. Chiar dac n ultimii ani s-au construit multe sisteme senzitive la context, lipsete
nc un model general care s fie stabilit ca un ghid al proiectrii. Acest lucru a determinat
duplicarea efortului construirii unui astfel de sistem, precum i mari probleme de
interoperabilitate ntre cei care au construit astfel de sisteme. Soluiile curente de modelare a
informaiilor contextuale sunt bazate pe diferite reprezentri, de exemplu XML, grafuri,
diagrame UML i alte soluii mprumutate din alte domenii ale tiinelor informatice. Tendina
general abordat n acest caz este folosirea ontologiilor. Ontologiile furnizeaz un limbaj
comun pentru entitile implicate n sistem, care trebuie s colaboreze pentru a atinge anumite
obiective legate de adaptarea informaiilor de context. Alte avantaje ale folosirii ontologiilor
sunt crearea de inferene i argumentri logice, refolosirea contextelor, prin crearea de
ontologii comune domeniului i ontologii specifice.
Un alt aspect important n crearea unor astfel de sisteme este configurarea contextelor,
care se refer la faptul c sistemul se bazeaz pe nite reguli fixe, neconfigurabile care
guverneaz rspunsul su la schimbri succesive de context, fr posibilitatea de
reconfigurare dinamic a acestora. Odat ce sistemul detecteaz contextul curent, trebuie s
decid ce tip de comportament s aplice pentru a satisface nevoile locatarilor. Astfel roboii
inteligeni, chiar dac ar putea nva din situaiile trecute pentru a repeta comportamentul,
trebuie s ia n considerare i situaia n care se ateapt un alt tip de comportament pentru
situaiile noi sau ntlnite n prealabil. n aceast lucrare se va demonstra c pentru adaptarea
1
Universitatea Tehnic din Cluj-Napoca
Introducere
roboilor la sistemul senzitiv la context al casei nu este de ajuns folosirea cunotinelor despre
context i regulile predefinite sau cele deduse ulterior, toate acestea nu vor conduce de fiecare
dat la rspunsul optim care s satisfac preferinele utilizatorului. Dar de multe ori acest
rspuns al sistemului se poate apropia de cerine.
Pentru satisfacerea cerinelor exprimate n problema propus este necesar ca n primul
rnd din soluia de proiectare a arhitecturii s rezulte o arhitectur flexibil, care permite
adaptarea a noi componente. Astfel soluia propune construirea unui sistem multi-agent
distribuit descentralizat bazat pe agent, fiecare component a sistemului fiind un agent, iar
comunicarea ntre componente fiind realizat prin comunicarea de mesaje ntre ageni.
Folosirea agenilor aduce o generalizare mare a problemei, deoarece prin ageni se pot
reprezenta diferite tipuri de entiti sau actori, printre care i roboi, agenii putnd fi
configurai s emuleze comportamentul unui robot din sistemul senzitiv la context.
Cerinele i direciile de proiectare i cercetare abordate n aceast lucrare sunt
urmtoarele:
Studiul conceptelor de baz folosite n domeniul senzitivitii la context i a
roboilor Lucrarea furnizeaz un dicionar cu explicaii i amnunte legate de
conceptele de baz privind senzitivitatea la context, sisteme senzitive la context i
roboi;
Studiul metodelor de modelare a contextelor i folosirea ontologiilor Se face o
analiz a avantajelor i dezavantajelor proiectrii contextelor cu ontologii;
Studiul diferitelor arhitecturi existente de sisteme senzitive la context i o
comparaie ntre acestea Se studiaz diferite modele arhitecturale pentru sisteme
senzitive la context. De asemenea se valorific aportul adus de proiectarea cu
ageni la infrastructura sistemului;
Studiul metodelor i metodologiilor de realizare a adaptrii agenilor la un sistem
senzitiv la context Pentru a ndeplini obiectivele lucrrii este necesar studierea
diferitelor metode de dezvoltare a agenilor, unelte folosite pentru crearea agenilor
precum i platforme de simulare a sistemelor multi-agent. Se face i un studiu de
fezabilitate pentru toate aceste platforme, n ncercarea de a alege cea mai bun
metod pentru atingerea scopului lucrrii;
Proiectarea arhitecturii senzitive la context n compatibilitate cu adaptarea
roboilor n partea de proiectare a arhitecturii trebuie luate n considerare tipurile
de ageni folosii pentru modelarea entitilor din sistemul senzitiv la context al
casei inteligente, tipurile de ageni folosii pentru roboi, modul de colaborare ntre
ei, cunotinele mprite, obiectivele i planurile executate pentru atingerea
obiectivelor i dependenele dintre ei;
Implementarea unei aplicaii care s simuleze adaptarea roboilor n sistemul
senzitiv la context al casei inteligente Construirea unui sistem multi-agent este
un proces complex care include provocrile i problemele referitoare la sisteme
distribuite, probleme rezultate din flexibilitatea i comunicarea la distan ntre
componente i simularea adaptrii ntr-o aplicaie vizual demonstrativ;
Descoperirea i tratarea provocrilor existente i a dezvoltrilor ulterioare pentru
sistemul senzitiv la context cu roboi Prezentarea unor direcii de dezvoltare
ulterioar a sistemului.
Implementarea unei adaptri complete a roboilor este n afara scopurilor lucrrii
deoarece acest lucru implic cercetri i expertize complexe n domeniul electronicii,
ciberneticii, psihologiei i alte domenii auxiliare care pot interveni n proiectarea roboilor
inteligeni.
2
Introducere
3
Introducere
2
2.1
STUDIU BIBLIOGRAFIC
Case inteligente
Ultimii ani au fost martorii avansrii rapide a tehnologiilor ce privesc casele

inteligente, printre care maturizarea tiinelor privind reelele, totodat cu creterea varietii
protocoalelor de comunicaii prin cablu i wireless (fr fir), precum i pe sisteme senzoractuator omniprezente. Utilizatorii locali au dorit servicii din ce n ce mai personalizate pentru
casele lor, precum automatizri, securitate, servicii de monitorizare, divertisment i medicale.
n particular, multe proiecte ce refereau case inteligente au avut ca int utilizatori din
categoria persoanelor n vrst i a persoanelor cu dizabiliti, cu scopul de a le uura traiul i
pentru a le oferi ct mai mult independen prin asistarea lor n viaa de zi cu zi [10]. O
component esenial n tehnica computaional ce privete casele inteligente i nu numai este
senzitivitatea la context. Serviciile n medii omniprezente i mobile trebuie s fie senzitive la
context pentru a se putea adapta la schimbri rapide de situaie. Prin context ne referim la
orice informaie fizic sau conceptual legat de mediul executiv al unui serviciu.
Datorit progresului n comunicaiile prin reea, muli cercettori au propus sisteme de
roboi bazate pe Internet, care au ca scop controlul de la distan i monitorizarea
dispozitivelor i senzorilor prin reea. Folosind avantajele date de Internet, aceste sisteme
permit utilizatorilor din toate colurile lumii s viziteze muzee, s navigheze pe mare, i multe
alte faciliti, toate acestea fr a fi necesar prezena la faa locului. Aceste faciliti au un
foarte mare potenial pentru industrie, educaie, timp liber, securitate.
Datorit creterii rapide a tehnologiilor computaionale de tip pervaziv a aprut o nou
paradigm numit ubiquitous computing technology (omniprezena dispozitivelor de
calcul), care este o extensie a paradigmei desktop computing (dispozitive de calcul locale),
n care informaia procesat a fost integrat complet n obiectele i activitatea de zi cu zi, n
care utilizatorul poate folosi simultan mai multe sisteme, fr a fi contient c acioneaz n
acest fel. Paradigma mai este numit i everyware ca un joc de cuvinte inspirat din
paradigmele existente i deja celebre software, hardware .a.m.d.
Ubiquitous Robotic Companion (URC) este un concept prin care roboii care
ntreprind servicii (service robots) [06], furnizeaz utilizatorilor serviciile dorite, oricnd i
oriunde n mediile computaionale pervazive. Pentru a ndeplini viziunea URC, una din
cerinele eseniale ale sistemelor de roboi este s suporte omniprezena serviciilor. Acest
lucru nseamn c robotul trebuie s fie folosibil chiar dac apar modificri n sistemul
pervaziv, care trebuie s permit ca roboii s opereze cu senzorii i dispozitivele existente, nu
s fie preprogramai pentru ele.
Conceptul de service-robot [13] include toi roboii care vin n ajutorul locatarilor
unei case. O clasificare a acestui tip de roboi poate fi observat n Tabelul 2.1. Astfel n
ultimii ani s-au creat cu succes roboi care execut aciuni precum splarea hainelor, aspirare
n cas, comunicare, precum i susinerea i ajutarea persoanelor vrstnice.
Studiu Bibliografic
Tabel 2.1 Clasificarea roboilor utilizai n locuine
Arie de interes
Roboi pentru comunicare
Roboi existeni
NEC PaPeRo
Hitachi EMIEW/EMIW2
AIST PARO
ART Robovie
Roboi pentru ajutor casnic
Fuji Heavy Industry
iRobot Roomba
Toshiba ApriPoko
Mitsubishi Heavy Industry
Wakamaru
Roboi folosii pentru munci Matsushita Electric
mai grele
Works HOSPI
Secom Secom Robot X
Cyberdyne
Toyota IRT
Aplicabilitate
Securitatea domiciliului
Monitorizare la distan
Terminal de informare
ngrijire medical / ddac
Ajutor casnic
Aerisirea
i
reglarea
temperaturii ncperilor
Curenie
Securitate i monitorizare
Servicii n instiuii publice
(coli, spitale, etc.)
Ddcire
ngrijire medical
Securitate
n Japonia, conform companiei Seed Planning Company, cota de pia pentru roboii
de tip service-robot a crescut de la 1,9 miliarde yeni la 6,7 miliarde yeni n 2006. n 2007
deoarece marile companii s-au retras de la a mai comercializa roboi de amuzament precum
roboi de companie, vnzrile au sczut per total, ns, vnzarea roboilor de menaj i a celor
ddac a continuat s creasc aa cum se poate vedea i n Figura 2 .1.
Figura 2.1 Tendina n vnzarea roboilor de cas pe piaa japonez
5
Studiu Bibliografic
2.2
2.2.1
Sisteme senzitive la context

Concepte de baz
2.2.1.1
Context
n general, contextul reprezint orice informaie care poate fi folosit pentru a
caracteriza starea unei entiti [16]. O entitate poate s fie la rndul ei o persoan, un loc, o
situaie sau un obiect care este relevant interaciunii dintre un utilizator i o aplicaie.
Aplicaiile senzitive la context caut rspuns pentru circumstanele n care o entitate se poate
afla, i folosesc aceste informaii pentru a determina ce situaii apar n aceste circumstane.
n [15] este dat urmtoarea definiie pentru un context: Un context se refer la ceea ce
furnizeaz surse adiionale de informaie, aduce contribuie la nelegerea situaiei, pentru un
anumit punct de interes vizat.
Conceptul de context a fost introdus n multe domenii din tiina calculatoarelor,
acestea incluznd, procesarea limbajelor formale i naturale (gramatici dependente/
independente de context), grafic pe calculator, procese decizionale, procesare de informaii,
dispozitive de calcul omniprezente sau securitate. Scopul utilizrii contextului este adugarea
adaptabilitii sistemelor i suport n luarea deciziilor.
2.2.1.2
Senzitivitate la context
Senzitivitatea la context este un punct foarte important i esenial n mediile
computaionale omniprezente, pentru adaptarea entitilor computaionale la schimbrile care
pot interveni, cum ar fi schimbrile necesitilor utilizatorilor sau a capacitilor tehnice [17].
Fundamentul senzitivitii la context este un model de reprezentare ct mai formal al
contextului, care este necesar pentru a reprezenta contextul ntr-o manier interpretabil de
ctre calculator. n medii distribuite, este primordial ca aceast informaie contextual s
poat fi interpretat de entitile computaionale diferite, ceea ce ofer interoperabilitate. Mai
mult, este necesar argumentarea cunotinelor despre context, de exemplu, pentru a rezolva
inconsistenele datelor venite de la senzori, sau pentru a deduce context de nivel nalt, din
informaii vagi i eronate venite de la senzori.
Senzitivitatea la context este un subiect care trateaz modul n care dispozitivele pot
interfera i nelege contextul curent bazat pe informaiile preluate de la senzori [18]. Prin
nelegerea contextului curent (o situaie, un mediu) n care se afl utilizatorul sau
dispozitivul, sistemul poate lua n mod inteligent o decizie pentru a face un anumit tip de
aciune sau cel puin s notifice i s cear permisiunea utilizatorului pentru a confirma
aciunea pe care o va executa.
Sistemele senzitive la context bazate pe recomandri sunt o component esenial n
acest tip de medii pervazive. Scopul acestor ageni inteligeni este s determine prioriti sau
s sugereze aciunile de care utilizatorul este interesat, lund n calcul contextul interaciunii.
2.2.1.3
Sistem Senzitiv la Context

Schilt, n 1995, spunea c sistemele senzitive la context sunt construite astfel nct s
se adapteze locaiei sau locaiilor n care sunt folosite, ansamblului de persoane i obiecte,
dispozitivelor accesibile, precum i modificrilor acestor entiti de-a lungul timpului. Un
sistem cu astfel de capaciti monitorizeaz mediul i reacioneaz la modificrile aprute n
acel mediu [22].
Senzitivitatea la context permite sistemelor s ntreprind aciuni automate, reducnd
excesul de implicare din partea utilizatorilor i furniznd soluii proactive de asisten
inteligent.
6
Studiu Bibliografic
Informaia perceptual despre mediu este ingredientul esenial al sistemelor senzitive

la context, ceea ce le distinge de sistemele computaionale clasice. Aplicabilitatea acestor
tipuri de sisteme este foarte mare, incluznd extragerea informaiilor senzitive la context,
sisteme notificatoare, servicii mobile senzitive la context, precum i medii senzitive la context
cu poteniale beneficii aduse societii, de la ngrijire automat i proactiv a sntii, comer
electronic (e-commerce), la sisteme militare i automobile mai sigure [22]. De asemenea, se
poate utiliza senzitivitatea la context i n sisteme de securitate de acas sau din locuri
publice.
2.2.2
Paradigma Ubiquitous Computing
2.2.2.1
Definiii
Cuvntul ubiquitous (n traducere care se mprtie peste tot, omniprezent) poate fi
transpus nspre domeniul tehnic ca a fi sau a exista peste tot n acelai timp, ntlnit n mod
frecvent, rspndit peste tot, referindu-se la faptul c tehnologia este peste tot i o folosim
tot timpul [19].
Din cauza omniprezenei acestor tehnologii tindem s le folosim fr a ne gndi la un
anumit dispozitiv, la o anumit unealt gen calculator sau telefon mobil. n schimb ne gndim
doar la aciunea pe care vrem s o ntreprindem, fcnd astfel acest tip de tehnologii invizibile
din punctul de vedere al utilizatorului.
Cercettorii de la Research Center for Educational Technology [19], n urma muncii
lor i a observaiilor bazate pe experien i pe cunotinele existente au dezvoltat o definiie
care poate fi aplicat n domeniul nvmntului pentru a rspndi aceast noiune nou n
rndul studenilor: Mediile computaionale pervazive sunt medii de nvare n care toi
studenii au acces la o varietate de servicii i dispozitive digitale, incluznd calculatoare
conectate la Internet, precum i dispozitive mobile, oriunde i oricnd au nevoie de ele.
Noiunea noastr de ubiquitous computing este mai mult axat pe relaia: de la mai muli-la
mai muli (many-to-many) dect pe unu-la-unu (one-to-one) sau unu la-mai muli (one-tomany) i include ideea de tehnologie oricnd la dispoziia studenilor.
Mark Weiser, cercettor la Xerox, a fost primul care a introdus termenul de ubiquitous
computing i a definit termenul astfel: Ubiquitous computing este metoda prin care se
mbuntete utilizarea calculatorului, fcnd mai multe dispozitive disponibile prin mediul
fizic, acestea fiind invizibile pentru utilizator [20].
Marcia Riley, de la Georgia Institute of Technology, Atlanta, spunea c UC, sau
tehnologia calm este o schimbare de paradigm, n care tehnologia devine practic
invizibil, dar este peste tot prezent n vieile noastre [20].
2.2.2.2
Caracteristici
Folosind dispozitivele aprute n ultima perioad utilizatorii tind s comunice prin
diferite metode, s fie mult mai activi, s foloseasc spaiul geografic i temporal n mod
diferit, i s dein mai mult control. Astfel, datorit nevoilor utilizatorilor, UC a fost
conceput avnd urmtoarele caracteristici:
Dispozitivele sunt prezente peste tot n jurul nostru;
Sunt interconectate i comunic unul cu cellalt;
Nu necesit atenie continu din partea utilizatorului pentru a funciona;
Fiecare dispozitiv tinde s fie ct mai specializat;
Sunt invizibile, fiind ascunse n mediul n care sunt folosite;
7
Studiu Bibliografic
n [20] se d urmtoarea caracterizare pentru UC. Astfel paradigma permite

tehnologiei s fie:
global i local;
social i personal;
public i privat;
invizibil i vizibil;
creatoare de cunotine i rspnditoare a informaiilor.
Datorit naturii sale UC este strns legat de noiunea de context i senzitivitate la
context. Principalul motiv al acestei corelri este eterogenitatea i rspndirea ubicuitar a
entitilor n acest tip de medii. Aceste dou aspecte necesit adaptare la run-time a serviciilor
i dispozitivelor, depinznd de locaia i rolul lor, adaptarea la rndul ei fiind dependent n
multe situaii de folosirea contextului.
Cnd aceast paradigm este aplicat n contextul casei, o cas normal se transform
ntr-o cas inteligent. Ceea ce locuitorii ei vor putea observa este doar cum casa i aplicaiile
i mediul se ajusteaz pentru a se adapta cerinelor dinamice ale rezidenilor avnd nevoie de
o interaciune minimal ntre utilizatori i aplicaiile casei inteligente.
2.2.3
Ontologie
2.2.3.1
Definiii
Termenul ontologie i are originile n filosofie i se refer la disciplina care se
ocup cu existena i cu lucrurile care exist. n tiina calculatoarelor lucrurile care exist
sunt cele care pot fi reprezentate prin date [17].
Diferite definiii pentru ontologiile legate de tiina calculatoarelor pot fi gsite n
literatur [23]. Ca un exemplu, o definiie dat de J. Vo [24] este: O ontologie este un sistem
definit formal de concepte i relaiile dintre aceste concepte. Ontologiile conin, cel puin n
mod implicit, reguli. Se pot deosebi trei probleme cnd punem aceast definiie pentru
ontologii n relaie cu modelarea contextelor i argumentarea:
Un model de context este de asemenea un sistem de concepte (entiti) i relaii
care fac din ontologie o unealt bun pentru modelarea conceptelor;
Ontologia este definit formal, ceea ce este o precondiie pentru ca un computer
s o poat interpreta, de exemplu, pentru motive de argumentare;
Regulile pot fi folosite pentru a implementa argumentarea contextului.
2.2.3.2
Caracteristici
M. Gruninger i J.Lee [25] despart aplicabilitile ontologiilor n 3 grupuri mari:
Comunicaii i mprirea cunotinelor: o ontologie servete ca un vocabular
comun pentru ageni diferii (entiti computaionale sau oameni).
Inferen i argumentare logic: O ontologie poate fi folosit pentru a deduce
cunotinele implicite din cunotinele explicite, aplicnd reguli.
Refolosirea cunotinelor: Ontologiile comune pot fi folosite cnd se construiesc
ontologii specifice domeniului.
Elementele tipice ale unei ontologii sunt:
Conceptele i atributele lor.
Taxonomii pentru a clasifica conceptele prin generalizare i specificare.
Relaii ntre concepte.
8
Studiu Bibliografic
2.2.4
Axiome pentru a defini formule care sunt ntotdeauna adevrate. Ele sunt folosite
pentru a demonstra consistena cunotinelor modelate de o ontologie i pentru a
deduce lucruri ulterioare.
Faptele sunt instane ale conceptelor i relaiile dintre ele.
Se deosebesc mai multe limbaje diferite ce pot fi folosite pentru a defini ontologii.
Dintre acestea amintim Ontolingua [28], LOOM [29] i OWL Web Ontology
Language [26, 27]. OWL este limbajul cel mai folosit pentru a definii ontologii
pentru sisteme senzitive la context, incluznd i serviciile Web semantice [26].
Ageni senzitivi la context
Construirea aplicaiilor sistemelor senzitive la context i omniprezente din domeniul

locuinelor inteligente a ajuns la un punct comun prin folosirea n implementarea lor a
paradigmei sistem multi-agent.
Paradigma agentului inteligent este corelat cu conceptul de sistem senzitiv la context
prin faptul c fiecare agent posed cunotine incomplete n sisteme fr control global, cu
date descentralizate. Tehnologiile multi-agent sunt un punct comun n construirea unor
sisteme care se pot adapta foarte uor la schimbrile de mediu, care sunt capabile s integreze
componente eterogene, furniznd flexibilitate n controlarea unor sisteme distribuite
complexe, i de scar larg.
2.2.4.1
Paradigma agentului
Cercettorii n domeniul sistemelor agent au definit n diferite maniere noiunea de
agent, deosebindu-se dou dintre aceste abordri n funcie de proprietile care sunt dorite
pentru agentul definit: Noiunea de agent simplu i noiunea de agent BDI Belief-DesireIntention (Convingere Dorin Intenie) care extinde agentul simplu adugnd proprieti.
n descrierea agentului simplu Wooldridge [38] puncteaz o definiie descriind
proprietile eseniale ale agentului Un sistem de calcul hardware sau cel mai des software
care satisface urmtoarele proprieti:
autonomie: agenii opereaz fr intervenia direct a omului sau altfel, i au un
nivel de control asupra aciunilor i a strii interne;
abiliti sociale: agentul interacioneaz cu ali ageni printr-un anumit limbaj de
comunicare;
reaciune: agenii percep mediul n care se afl i reacioneaz la schimbrile care
au loc n el;
proactivitate: agenii nu doar c iau decizii ca rspuns la schimbri, ei sunt capabili
s aplice comportamente obiective prelund iniiativa.
O definiie mai general a agentului a fost elaborat de Russell i Norvig [39]: Un
agent este orice care poate fi s perceap mediul prin senzori, i s acioneze n acel mediu
prin efectori. Ei specific c noiunea de agent este prevzut pentru a fi o unealt pentru a
analiza sistemele, nu o caracterizare absolut care desparte lumea n ageni i non-ageni.
2.2.4.2
Ageni BDI
Modelul BDI aa cum este descris n [40] este bazat pe 3 concepte: Convingere,
Dorin i Intenie (tradus Belief-Desire-Intention). Ideea are baze filosofice n conceptul
analog din teoria argumentrii umane. Convingerile reprezint cunotinele agentului despre
starea curent a mediului, starea intern a lui, informaii despre ali ageni. n mediile reale, cu
un grad mare de incertitudine convingerile agentului sunt incomplete i inexacte.
9
Studiu Bibliografic
Convingerile agentului se deosebesc de cunotinele lui, deoarece acestea nu trebuie

neaprat s fie adevrate. La nivelul fiecrui agent din mediu se construiete o viziune parial
asupra mediului n care el opereaz, convingerile furniznd o abstractizare a entitilor
relevante.
Dorinele agentului sunt strile de fapt n care agentul vrea s ajung sau s le
foloseasc. Strile trebuie s fie consistente una fa de cealalt.
Inteniile reprezint strile deliberative ale agentului, activitile pe care agentul le-a
executat pentru a nfptui o dorin. n unele situaii un agent poate alege mai multe planuri de
execuie diferite. Planul selectat mpreun cu ncrederea de a executa acel plan devin o
intenie.
Obiectivul este conceptul central al unei arhitecturi BDI, reprezentnd o anumit stare
final n care agentul vrea s ajung. Obiectivele sunt dorinele alese pe care agentul vrea s le
nfptuiasc, dac pot s considere c din starea curent se poate ajunge la aceste stri. Cnd
unele dintre aceste obiective eueaz agentul poate s determine dac starea poate fi nc
atins pentru a rencerca intenia sau trebuie s ncerce un alt set de intenii pentru a ajunge n
starea dorit. Obiectivele permit modelarea agenilor care s acioneze proactiv. Planurile
reprezint mijloacele prin care se poate stabili un obiectiv, incluznd secvena de aciuni care
trebuie executate pentru a ajunge la acel obiectiv.
Modelul BDI s-a dovedit a fi extrem de eficient la modelarea unor ageni care ruleaz
n medii dinamice i care opereaz ntr-o manier flexibil n ciuda informaiilor incomplete
despre mediu i ceilali ageni.
2.3
2.3.1
Arhitecturi de sisteme senzitive la context

Arhitecturi de sisteme senzitive la context locale
Sistemele orientate pe reea sunt uor de implementat din cauza standardului ISO
Open System Interconnection (OSI), care este un model stratificat n care fiecare nivel este
independent i are funcionalitatea sa specific. n acest fel, n [33] se propune un model
stratificat pentru arhitectura unui sistem senzitiv la context, Context Stack.
2.3.1.1
Modelul arhitectural stratificat Context Stack

Modelul este un model referin pentru arhitectura sistemelor pervazive. Acest model
este similar cu modelul pe 7 nivele ISO-OSI pentru reele de calculatoare. Modelul stratificat
combin elementele funcionale ale sistemelor senzitive la context:
Nivelul achiziie;
Nivelul reprezentare;
Nivelul agregare;
Nivelul interpretare;
Nivelul utilizare.
Acestea se combin ntr-o arhitectur coerent i generic la care majoritatea
sistemelor senzitive la context actuale se pot mapa. Figura 2.2 ilustreaz cele 5 nivele ale
arhitecturii Context Stack i exemplul concret al unui serviciu senzitiv la context pentru un
telefon inteligent (smart phone).
10
Studiu Bibliografic
Figura 2.2 Modelul arhitectural Context Stack
Nivelul achiziie
Este nivelul cel mai de jos n care contextul este preluat ntr-un format neprocesat,
fiind preluat de la o multitudine de tipuri de senzori pervazivi. De exemplu, locaia n cas a
unui locatar poate fi obinut de la un sistem de senzori RFID, care detecteaz apariia unei
modificri n configuraia RFID, nivelul luminii fiind detectat de senzorii de lumin, iar
nivelul zgomotului este obinut de la senzorii de zgomot. Datele preluate pot s nu ofere
context care s poat fi neles i utilizat de serviciile senzitive la context, astfel el trebuie
trimis la nivelele de mai sus pentru procesri ulterioare.
Nivelul Reprezentare
ncepnd de la acest nivel, toate nivelele se bazeaz pe un model de context comun,

care formeaz baza pentru managementul contextului, pentru a facilita o reprezentare
expresiv i interoperabilitate ntre entitile computaionale eterogene. Modelele de contexte
existente variaz n funcie de tipul de context pe care l reprezint i expresivitatea lor. Aa
cum este prezentat n Figura 2.2 s-a folosit un model de context orientat pe entitate-relaie,
pentru a ilustra rolul modelului n sistemele senzitive la context. n asemenea modele de
context, informaia contextual este structurat n jurul unui set de entiti fiecare descriind un
obiect fizic sau conceptual, precum o persoan sau o activitate, iar toate aceste entiti sunt
legate cu celelalte entiti prin relaii.
n nivelul de reprezentare al contextului, datele neprelucrate venite de la senzori sunt
reprezentate ntr-o form care poate fi neleas, dup modelul de context stabilit n prealabil.
Acest nivel este un nivel de abstractizare a datelor, care adun datele de la senzori, venite de
la diferite surse, i apoi le combin cu semantici care sunt structurate n jurul unui set de
entiti contextuale i relaiile dintre ele.
Nivelul Agregare
Acest nivel se ocup de agregarea datelor contextuale, adunnd datele de la senzori

contextuali distribuii ntr-o baz de contexte centralizat. Agregarea contextelor ajut la
simplificarea procedurii de interogare a contextului, centraliznd astfel entitile
computaionale i furnizeaz o baz pentru interpretri ulterioare ale cunotinelor
contextuale. Astfel, agregarea contextelor prin natura sa furnizeaz funcionalitile unei baze
de cunotine. O alt funcie a nivelului de agregare este de a salva o arhiv de contexte,
11
Studiu Bibliografic
pentru a se putea ulterior s se fac interpretri, bazate pe contextele curente i pe cele din
trecut.
Nivelul Interpretare
Cnd se stabilete un model de context pentru a reprezenta i prelucra contexte,

contextele pot fi interpretate prin mai multe metode de argumentare i/sau nvare, pentru a
deriva contexte adiionale de nivel nalt. Nivelul de interpretare a contextului adaug tehnici
de argumentare/nvare pentru a deduce contexte implicite de nivel nalt din contextele
explicite provenite de la nivelele inferioare i care sunt folosite de serviciile inteligente.
De exemplu, modulul de argumentare bazat pe reguli poate deduce situaia curent a
utilizatorului bazndu-se pe locaia sa i contextul mediului n care se afl. Contextul inferat
poate sugera c utilizatorul e posibil s doarm n momentul actual, avnd n vedere c este
ora 11 PM i c el st n ntuneric, e linite, iar patul este ocupat. Un alt exemplu de
interpretare a contextului ar putea fi nvarea i predicia comportamentului. Sistemul
inteligent poate nva abloane ale aciunilor ntreprinse de utilizator din secvene trecute de
date contextuale, care mai trziu pot fi folosite pentru a prezice urmtorul eveniment. De
exemplu, se poate prezice c odat ce utilizatorul a terminat duul (nchiznd nclzitorul
electronic de ap) dup ora 10:30 PM, el i va verifica emailurile folosind telefonul, pentru ca
ulterior s se aeze n pat dup ce le-a citit.
Nivelul Utilizare
La nivelul cel mai de sus, serviciile senzitive la context utilizeaz att contexte de
nivel jos, ct i contexte de nivel nalt pentru a-i ajusta comportamentul. Lund exemplul dat
n Figura 2.2, telefonul inteligent (smart phone-ul) preia contextul utilizatorului i decide s
redirecioneze toate apelurile telefonice nspre csua vocal. De asemenea el ia n considerare
contextul prezis pentru a nfptui unele aciuni.
2.3.2
Arhitecturi de sisteme distribuite senzitive la context
Au fost cteva ncercri de a construi astfel de sisteme de roboi i monitorizare prin

Internet, folosind tehnologiile World-Wide-Web i de obiecte distribuite. Sistemele de tip
WWW foloseau protocolul HTTP n combinaie cu CGI (Common Gateway Interface) sau
Java pentru controlul la distan a senzorilor i actuatorilor. Exemple ale unor astfel de
ncercri pot fi vzute mai jos:
University of Californias tele - excavation system, Mercury [01]
Carnegie Mellon Universitys indoor mobile robot, Xavier [02]
Ecole Polytechnique Fdrale de Lausannes maze robot, KhepOnTheWeb [03]
Roger Williams Universitys PumaPaint [04]
Pohang University of Science and Technologys XNMS [05]
Exist i implementri realizate cu ajutorul tehnologiilor obiectelor distribuite precum
CORBA (Common Object Request Broker Architecture) i Java RMI (Remote Method
Invocation) [07]:
NRSP (network robot service platform);
DAIR (distributed architecture for Internet robot).
Datorit limitrilor soluiilor expuse mai sus, s-a propus o nou metod i s-a dezvoltat
un nou framework pentru sistemele robotice pervazive, acesta fiind bazat pe semantic i
numit SemanticURS [06]. Aceast metod permite integrarea automat a roboilor conectai la
reea n sistemele pervazive, printr-o metod orientat pe servicii Web. Astfel SemanticURS
exploateaz serviciile Web semantice (Semantic Web Services), care sunt ultima apariie n
12
Studiu Bibliografic
domeniul tehnologiilor Web, i o metod de planificare preluat din inteligena artificial,

pentru a automatiza procesul de interoperare ntre roboii conectai la reea i sistemele
pervazive.
Astfel serviciile Web, senzorii i dispozitivele din reea, implementeaz o interfa
unic pentru a se accesa reciproc. Ulterior cunotinele legate de aceste servicii Web sunt
descrise n limbajul ontologic Web pentru servicii (OWL-S), care este un limbaj semantic de
descriere a serviciilor Web, i salvate n baza de cunotine (KB Knowledge Base) pentru ca
un agent robot s poat descoperi n mod automat cunotinele necesare pentru a compune un
plan de servicii fezabil pentru mediul n care este conectat. Ulterior, agentul furnizeaz
servicii interacionnd n mod automat cu roboii, senzorii, i dispozitivele prin protocolul
SOAP (Simple Object Access Protocol) [64], precum n Figura 2 .3.
Figura 2.3 Comparaie ntre SemanticURS i sistemele tradiionale
2.3.2.1
Serviciile Web Semantice

Reeaua World Wide Web iniial conceput pentru ca utilizatorii s schimbe fiiere text
i imagini a evoluat spre un furnizor de servicii. Programele accesibile prin Web realizeaz
aceste servicii cu ajutorul tehnologiilor CGI, Java, ActiveX sau prin Web Services. O cerin
fundamental pentru a realiza interoperabilitatea acestor tip de servicii este necesitatea de a
13
Studiu Bibliografic
realiza aceste servicii interpretabile de computere, de a crea servicii Web semantice ale cror
semantic, precum proprieti, capaciti i interfee, s fie codificate ntr-un mod neambiguu,
ntr-o form inteligibil de ctre maini. Serviciile Web Semantice sunt construite astfel nct
s ndeplineasc aceste cerine, descriind serviciile Web folosind ontologii OWL, numite
generic OWL-S. OWL-S este structurat n 3 clase eseniale: Service Profile, Service Model,
Service Grounding [06] (Figura 2.4).
Figura 2.4 Clasele componente ale unei ontologii de tip OWL-S
Service Profile aceast component a unei ontologii OWL-S specific ce face

serviciul. Ea are rolul de a informa agentul care cere servicii despre serviciile oferite de web
service-ul pe care vrea s l acceseze. Se folosesc urmtoarele noiuni pentru a marca
proprietile unui Service Profile: profile, serviceName, textDescription, hasInput, hasOutput,
has Precondition, hasEffect, serviceCategory .a.m.d.
Service Model Aceast component specific cum funcioneaz serviciul. Se descrie
ce se ntmpl cnd este alocat un serviciu atomic sau compus. Aceast descriere poate fi
folosit de un agent care necesit servicii pentru a realiza o analiz mai amnunit a
serviciului i dac i poate satisface nevoile. De asemenea se poate folosi pentru a compune
multiple servicii pentru a atinge un anumit obiectiv. Se folosete i pentru monitorizarea
execuiei unui serviciu. Procesul ontologic furnizeaz modelului serviciului urmtoarele
procese:
ProcessModel,
AtomicProcess,
CompositeProcess,
SimpleProcess,
ProcessComponent, ControlConstruct, Sequence, Choice, Repeat-Until.
Service Grounding Aceast component detaliaz cum poate un agent accesa un
serviciu. Astfel componenta specific protocolul de comunicaie, formatul mesajelor i alte
detalii specifice, precum numrul portului prin care serviciul poate fi accesat. Procesul
ontologic al componentei de configurare are interfeele descrise n Web Services Description
Language (WSDL): WsdlGrounding, WsdlAtomicProcessGrounding, WsdlOperation,
WsdlDocument, WsdlOperationRef, portType.
2.3.2.2
Arhitectura Serviciilor Web Semantice

Aa cum se poate vedea n Figura 2.5 arhitectura SemanticURS [06] este compus din
3 componente majore: un agent robotic RA (Robotic Agent), serviciile web ale dispozitivelor
DWS (Device Web Services) i baza de date de cunotine a mediului EKR (Enviromental
Knowledge Repository).
RA robotic agent este un agent apelator de servicii i de planificare inteligent. El
are un rol important n integrarea automat n arhitectura SemanticURS. RA este alctuit
dintr-o interfa utilizator, un modul de alctuire a planului, un modul de descoperire a
cunotinelor, un modul de inferen OWL, un modul de executare a planului i stiva de
comunicare pentru executarea serviciilor Web, de exemplu SOAP [08], XML i HTTP. Un
utilizator poate introduce o cerere de executare a unui serviciu folosind interfaa utilizator i
eventual poate iniializa contextele serviciilor. Apoi, cererea este transformat folosind
14
Studiu Bibliografic
vocabularul OWL-S, n ontologiile procesului OWL-S, pentru ca modulul de alctuire a

planului s poat nelege cerina de servicii i s descopere n mod automat cunotinele
necesare pentru a face planificare folosind modulul de descoperire a cunotinelor. Pentru a
cuta baze de date de cunotine n EKR pentru a prelua cunotinele necesare pentru cererea
actual, modulul de descoperire a cunotinelor creeaz interogri semantice de descoperire
codificate n Resource Description Framework (RDF).
Figura 2.5 Arhitectura detaliat a Semantic URS
RDF folosete limbajul de interogare Data Query Language (RDQL) [09], [10]. Dup
ce planul a fost compus cu succes, modulul de execuie a planului transform planul ntr-un
format executabil pentru ca ulterior s fie pus ca cerere pe stiva de comunicare a serviciului
Web.
EKR Enviromental Knowledge Repository conine o baz de cunotine a domeniilor
(Domain Knowledge Base - DoKB) i o baz de cunotine a dispozitivelor (Device
Knowledge Base - DeKB) utilizate pentru nregistrarea i descoperirea cunotinelor. DoKB
conine cunotine OWL-S despre conceptele generale legate de servicii i task-urile compuse
care descriu modelele comune ale serviciilor pentru un anumit domeniu. DeKB conine
cunotine salvate n format OWL-S despre task-urile atomice care reprezint serviciile oferite
de dispozitive i senzori, n medii specifice serviciilor. EKR conine de asemenea i obiectele
de descoperire a serviciilor, pentru a manipula n mod automat interogrile de descoperire a
cunotinelor cu predicate semantice despre cunotinele OWL-S formate de RA. EKR
conine i stiva de comunicare Web Service, componenta comportndu-se ca un Web Service
independent, fiind accesat de RA prin SOAP.
DWS Device Web Service este o implementare specific a Web Service-urilor pentru
dispozitive ubicuitare incluznd roboi, senzori, actuatori .a.m.d. Fiecare DWS poate avea
obiecte de control pentru unul sau mai multe dispozitive, care pot lucra mpreun, de pild un
dispozitiv de aer condiionat i un senzor de temperatur. DWS dispune de asemenea de
servicii Web pentru a comunica cu RA.
Proiectarea aa cum este descris n Figura 2.6 mparte procesul de integrare automat
al unui agent SemanticURS n 3 faze:
Descoperirea cunotinelor;
Planificarea Serviciului;
Executarea planificrii.
15
Studiu Bibliografic
Figura 2.6 Procedura de integrare automat a unui agent SemanticURS
2.4
Medii de dezvoltare ale aplicaiilor senzitive la context
Java Context Awareness Framework (JCAF) [36] este un mediu de dezvoltare

inspirat din J2EE desemnat exclusiv pentru a dezvolta aplicaii senzitive la context. Scopul
acestui mediu de dezvoltare este s suporte servicii distribuite i coordonate, controlul
accesului i o infrastructur modular pentru a permite extensii. Dintre caracteristicile JCAF
care l difereniaz este faptul c este independent de semantic i c pune n calcul calitatea
informaiilor despre context, iar evenimentele sunt interceptate de ctre modulele care
detecteaz schimbrile (vezi Figura 2.7). De exemplu, se detecteaz schimbrile de context i
ulterior sunt apelate funcii prin care schimbrile sunt trimise la aplicaii care prelucreaz
informaia.
Figura 2.7 Diagrama de interaciune ntre modulele componente ale JCAF
Astfel mediul JCAF nu are construit nici un modul inteligent el fiind responsabil doar
de controlul traficului, schimbrile de mediu i transportul informaiilor ctre aplicaiile
senzitive la context. Nivelul cel mai important al mediului JCAF o constituie serviciile de
context, care formeaz o reea interconectat de tip punct-la-punct, fiecare serviciu fiind
specializat pentru un anumit tip de informaie de context, aceste servicii putnd comunica
16
Studiu Bibliografic
ntre ele pentru a schimba informaii de context. O arhitectur general poate fi vzut n
Figura 2.8, mpreun cu arhitectura unui serviciu.
Figura 2.8 Arhitectura general cu diagrame de colaborare a JCAF
Mai exist i alte medii de dezvoltare a aplicaiilor senzitive la context, cu diferite

funcionaliti. Dintre acestea amintim Maythofers context prediction framework [37]
concentrat pe recunoaterea i deducerea unor informaii consistente de context, folosind
informaiile cu zgomot venite de la senzori. Scopul acestui mediu este de a fi folosit n scop
local pe dispozitive cu resurse limitate, fr a fi necesar constituirea unei infrastructuri n
prealabil. Se folosesc algoritmii Growing Neural Gas pentru nvare i algoritmi Active LeZi
pentru deducerea contextelor.
2.5
Aplicaii n domeniul caselor inteligente
n aceast seciune va fi prezentat proiectarea i implementarea unei arhitecturi

generale de tip service-oriented precum cele descrise anterior, aplicat n cazul unei case
inteligente.
Obiectivele proiectrii
Proiectarea infrastructurii serviciului adopt modelul stratificat prezentat n Figura 2.2
Context Stack, ca i abstracia de proiectare pentru a furniza middleware pentru servicii
reutilizabil. Proiectarea respect urmtoarele convenii [33]:
1) Arhitectura middleware bazat pe componente are ca rol combinarea elementelor
funcionale independente ale sistemelor senzitive la context (achiziia, agregarea,
interpretarea, utilizarea i descoperirea) i contopirea acestor elemente ntr-un middleware
coerent i reutilizabil.
2) Proiectarea cerceteaz infrastructura Semantic Web pentru a colecta informaii
contextuale. Argumentarea ontologiilor Semantic Web (CONON, COBRA-ONT sau
SOUPA), interogri Semantic Web i mecanisme de inferen sunt ncorporate n aceast
infrastructur pentru a facilita modelarea contextelor, mprirea cunotinelor, interogri
semantice, argumentarea contextual i descoperirea semantic a contextelor.
17
Studiu Bibliografic
Argumentarea ontologiilor (Ontologic Reasoning) este un pas foarte important n

dezvoltarea unei aplicaii senzitive la context pentru o cas inteligent, deoarece se ocup de
evaluarea cunotinelor de context (contextual knowledge).
Abordrile existente pentru modelare sunt aa cum au fost amintite i mai sus
CONON [32] bazat pe ideea de dezvoltare a unui model de context din ontologii, folosind
capacitile de inferene logice, refolosirea i mprirea cunotinelor. Wand a dezvoltat o
ontologie superioar, care capteaz trsturile generale ale entitilor contextuale i o colecie
de ontologii specifice mpreun cu trsturile lor n subdomenii. CANON folosete un
mecanism de serializare a ontologiilor n OWL-DL, care are o echivalen semantic cu
logica descriptiv foarte bine definit. Astfel se poate verifica consistena i argumentarea
contextelor folosind modulele de inferen dezvoltate n limbaje descriptive. Un sistem mai
complex i mai nou este CoBrA care furnizeaz o colecie de concepte ontologice pentru a
caracteriza entiti precum persoane, locuri sau alte tipuri de obiecte aflate n contextele lor.
Sistemul CoBrA are o arhitectur de tip broker [32] pentru a furniza suport la momentul
rulrii pentru sisteme senzitive la context, n mod particular n sli de conferine inteligente.
Folosirea standardelor existente incluznd OSGi sau UpnP pentru a simplifica
programarea componentelor reutilizabile ale serviciilor are ca scop furnizarea unui standard
API i implementarea unor servicii senzitive la context utilizabile pentru o cas inteligent.
Structur OSGi de tip Service pentru o cas inteligent
Arhitectura de tip OSGi propus pentru case inteligente este prezentat Figura 2.9 i a
fost descris n detaliu n [34][35]. Punctul central al arhitecturii este OSGi gateway aflat n
reedin, care este responsabil pentru conectarea la Internet a aplicaiilor din cas, terminale
mobile, dispozitive senzor/actuator, prin tehnologii de acces broadband. O varietate mare de
tehnologii legate de reelele din locuine, cum ar fi Ethernet, X.10, IEEE 1394, Lonworks,
WLAN sau Bluetooth, pot fi utilizate pentru a conecta diferite tipuri de dispozitive.
Framework-ul OSGi standardizeaz furnizarea de servicii pentru a le realiza ntr-o
manier sigur i fiabil. El constituie un intermediar ntre diferitele standarde de reele ce se
pot afla n cas.
Figura 2.9 Arhitectura de tip OSGi pentru o cas senzitiv la context
Pentru a obine partajarea cunotinelor i inferenele logice necesare informaiilor

contextuale, sunt legate n arhitectura OSGi sub form de servicii nmnunchiate (bundles)
urmtoarele 4 module funcionale cheie:
18
Studiu Bibliografic
Serviciul Web (SW) Semantic Serviciul SW furnizeaz API-uri Semantic Web pentru
accesarea i manipularea contextelor codificate n OWL, pentru a persista i interoga
modelele semantice ale contextelor n baze de date relaionale i pentru a infera contexte
adiionale din contextele existente n KB. Implementrile curente sunt bazate pe Jena
Semantic Web Toolkit, totui implementri alternative pot fi expuse printr-o interfa generic
pentru a fi ataate arhitecturii. SW service bundle furnizeaz fundamentele urmtoarelor 3
servicii.
Serviciul de Context Acquisition - Acest serviciu este responsabil pentru colectarea
informaiilor despre context de la o gam variat de surse i transform descrierile ad-hoc ale
contextelor n reprezentri semantice folosind ontologii. Acest serviciu furnizeaz
funcionalitile nivelului achiziie i nivelul reprezentare semantic al arhitecturii stratificate
descris n Capitolul 2.3.1.
Serviciul Context KB Baza de date de cunotine despre contexte furnizeaz un
mediu de stocare pentru cunotinele despre contexte prin folosirea bazelor de date relaionale.
Aceasta stocheaz i manipuleaz att ontologii de context statice (descrierile ontologice ale
claselor sau tipurilor de entiti relaionale) ct i contexte dinamice (instane ale situaiilor
sau indivizi reprezentai bazai pe ontologiile de context existente). Astfel are suport pentru
argumentare despre ontologiile de context, ct i pentru informaiile contextuale situaionale.
Serviciul KB permite arhitecturii serviciului s agrege i relaioneze contexte dinamice de la
surse contextuale distribuite i astfel furnizeaz funcionalitatea nivelului agregare din
arhitectura prezentat n Capitolul 2.3.1.
Serviciul de Context Inference Acest serviciu este un modul de argumentare care
poate fi folosit de serviciile senzitive la context pentru a deduce contexte de nivel nalt din
contextele de baz. Serviciul de inferen este bazat pe Jena API, care furnizeaz inferen
bazat pe reguli pentru OWL. Acest serviciu furnizeaz funcionalitatea nivelul inferen de
context al arhitecturii prezentate n Capitolul 2.3.1.
2.6
Dificulti i riscuri ntmpinate n crearea aplicaiilor

senzitive la context
Una dintre cele mai mari dificulti n crearea aplicaiilor ubiquitous i senzitive la
context robuste este dezvoltarea unor algoritmi care pot detecta contexte din date senzoriale
ambigue i cu zgomote.
Provocarea pentru astfel de sisteme const n complexitatea capturrii, reprezentrii i
procesrii datelor de context. Pe lng abilitatea de a obine informaiile despre context
aplicaiile trebuie s includ logic adiional pentru a procesa informaia i pentru a deduce
scopul acestora. Aceasta este probabil cel mai provocator lucru, deoarece este de cele mai
multe ori indirect i poate fi dedus prin combinarea unor diferite piese de informaie
contextual [41].
n [42] se descriu dificultile ce apar cnd se folosesc informaiile de context n
aplicaii pe calculator:
Informaia de context este adeseori achiziionat de la senzori neconvenionali care nu
sunt gsii n viaa de zi cu zi: termostat, GPS .a.m.d.
Datele preluate de la senzori trebuie s fie abstractizate ntr-o reprezentare de nivel
nalt pentru a deveni folositoare. Lund exemplul unui termostat, temperatura citit n grade
trebuie abstractizat n frig, mediu, cald, foarte cald. Dar, o aplicaie poate s abstractizeze
informaiile venite de la mai muli senzori, de exemplu, pe lng temperatur aplicaia poate
s aib nevoie de informaii despre umiditate pentru a determina nivelul de confort al unei
camere.
19
Studiu Bibliografic
Informaia de context poate fi achiziionat de la surse multiple distribuite i

eterogene. Aplicaiile au nevoie de mai mult de un senzor pentru a nelege un anumit context.
Informaia de context este dinamic. O aplicaie senzitiv la context are nevoie de
multe ori s detecteze modificrile n timp real pentru a se adapta la schimbrile care au loc n
mod frecvent. De exemplu, o aplicaie pentru o locaie mobil trebuie s detecteze
modificrile frecvente ale utilizatorului pentru a furniza acestuia informaii relevante legate de
locaia curent
Acestor dificulti li se adaug riscurile i provocrile n procesul crerii acestui fel de
aplicaii:
Aplicaiile senzitive la context trebuie s neleag intenia utilizatorului.
Acest proces este crucial n faza de adaptare la context. Odat ce o aplicaie senzitiv
la context s-a adaptat contextului curent, trebuie s decid cum s optimizeze acea adaptare. O
aplicaie trebuie s presupun ct mai aproape de adevr ce fel de comportament al acesteia
este dorit de ctre utilizator, n contextul curent. Unele tehnici din Inteligena Artificial
folosite n aplicaiile senzitive la context permit nvarea din trecut a comportamentelor
repetitive sau asemntoare, totui, aplicaia poate s neleag mai greu atunci cnd intervine
un comportament nou.
Aplicaiile senzitive la context sunt multidisciplinare
Construirea unor astfel de sisteme senzitive la context precum casele inteligente, de
obicei implic i necesit cunotine din tiina calculatoarelor, arhitectur, inginerie electric
i mecanic, tiine sociale i poate altele. Totodat construirea unui astfel de tip de aplicaii
necesit experi din diferite domenii, fiind nevoie de o echip de oameni cu cunotine
diferite.
Costurile sunt ridicate
Unele dispozitive gen biosenzori folosite pentru a construi infrastructuri senzitive la
context nu sunt foarte uzuale, astfel ele cost n general mai mult dect orice alt dispozitiv
comun. Acest fapt creeaz o barier pentru persoanele care doresc s dezvolte astfel de
aplicaii care necesit dispozitive i infrastructur specific. Deci, de cele mai multe ori
proiectarea unei astfel de aplicaii este dictat de ce dispozitive sunt accesibile dezvoltatorilor.
Un fapt foarte important n construirea unui mediu cu resurse limitate este decizia de a
distribui diferite componente ale sistemului ntre client i server. O soluie evident, dar
sensibil, este ncrcarea majoritii proceselor computaionale pe server, dar fr a se calcula
atent acest fapt ar putea rezulta n suprancrcarea serverului. O mbuntire semnificativ a
performanei se poate realiza dac agenii pot gsi momentul n care se poate face migrarea de
date de la server la client pentru realizarea unei anumite operaii.
O alt problem important care trebuie luat n calcul este alegerea sistemului de
operare pentru dispozitivele mobile. Dei Linux ofer o performan mrit, WindowsCE este
suportat de o gam mai variat de dispozitive mobile.
Pe lng aceste probleme de balansare client/server, calitate/pre mai intervin i alte
cerine minimale pentru o aplicaie de acest gen: interoperabilitate, portabilitate, flexibilitate,
robustee. Toate aceste probleme sunt menionate i detaliate n [43].
Construirea sistemelor multi-agent este un proces dificil i complex deoarece
integreaz n mod direct sau indirect provocrile i riscurile existente din sistemele distribuite
i concurente i n plus dificultile rezultate din cerinele de flexibilitate i interaciune
intensiv. Problemele construirii unor astfel de sisteme sunt detaliate n [44].
20
Studiu Bibliografic
2.7
Proiecte ample de cercetare n desfurare
Dintre proiectele ample de cercetare n legtur cu casele inteligente, i mai general cu

cldiri inteligente, le amintim pe cele de mai jos.
The Adaptive House (University of Colorado)
Scopul experimentului Adaptive House este s exploreze conceptul unei case
autoprogramabil, eliberndu-i pe locuitorii ei de necesitatea efecturii acestei munci.
Cercettorii au pus accent pe faptul c software-ul necesar pentru o cas automat trebuie s
fie programat pentru fiecare familie i cas n parte i reactualizat odat cu modificrile
survenite n stilul lor de via. Lund n considerare c la vremea aceea pentru mult lume era
destul de dificil s i programez DVD-playerele, se considera ca programarea unei case
inteligente ar fi mult sub interesul i capacitile lor, iar angajarea unui specialist care s fac
aceste lucruri ar fi foarte neconvenabil i costisitoare.
Prototipul a fost instalat n casa unuia dintre cercettori i controleaz temperatura
camerei, temperatura apei, nivelul luminii, a sunetului, deschiderea ferestrelor i totodat
controleaz aparatele responsabile pentru nclzire, lumin, curent .a.m.d. Sistemul
monitoriza aciunile luate de rezideni precum stabilirea unei anumite configuraii a luminii,
sau pornirea unui termostat i cuta abloane n acel mediu, pentru ca ulterior s poat prezice
acele aciuni. O reea neuronal este cea responsabil pentru a nva acele abloane pentru ca
apoi sistemul s fac acele aciuni nvate n mod automat.
ComHome (The Interactive Institute, Suedia)
Proiectul ComHome este descris de cercettori ca un model de scar larg construit
dintr-un numr de scenarii preluate din camere diferit configurate. Casa este echipat cu
tehnologii senzoriale, precum i tehnologii bazate pe control prin voce. n acest context,
cercettorii investigheaz diferite sfere ale activitilor casnice, precum munca la distan i
activitile sociale, n special comunicrile mediate prin video (VMC Video Mediated
Communications), explornd impactul pe care tehnologiile l pot avea asupra lor.
House_n (Massachusets Institute of Technology)
House_n este un proiect colaborativ i multi-disciplinar condus de Departamentul de
Arhitectur al MIT. Scopurile globale ale acestui proiect includ crearea unor medii care
acoper anumite nevoi pentru persoane din diferite categorii de vrst, crearea unui mediu
dinamic i obinuit, dezvoltarea unor algoritmi care interpreteaz datele venite de la senzori
pentru a detecta aciunile nfptuite de oameni, explorarea impactului tehnologic asupra
mediilor de nvare tradiionale, precum i impactul avut de comandarea de la distan a unor
anumite aciuni. Principalele iniiative ale grupului House_n sunt The PlaceLab i Open
Source Building Alliance (OSBA).
The PlaceLab este un ansamblu rezidenial aflat n Cambridge, Massachusetts,
proiectat pentru a fi un mediu foarte flexibil i multi-disciplinar pentru cercetare i observare
pentru studiul tiinific al omului i abloanelor lui de interaciune cu tehnologii noi i cu
condiiile noi oferite de mediu. Casa experimental este ocupat pentru o perioad de timp de
un anumit voluntar care nu are interaciune cu cercetrile, ele fiind fcute din afar, pentru ca
el s poat aciona ct mai natural. Cercettorii au capacitatea de a monitoriza aproape fiecare
aspect al vieii n cas, n particular ce aciuni ia locuitorul pe durata unei zile. Unii ocupani
sunt studiai i anterior n propriile lor locuine acetia purtnd o baterie portabil de senzori
dezvoltat de ctre cercettorii MIT. Aceste dispozitive monitorizeaz de la distan aciunile
21
Studiu Bibliografic
svrite de subiecii care particip la experiment, att nainte de a locui n cas, precum i
dup aceea. Principalele probleme care se ridic n cadrul experimentului sunt:
Ce influeneaz comportamentul oamenilor n propria lor cas?
Cum se poate eficientiza aportul tehnologic n cadrul traiului n cas pe perioade
mai ntinse de timp?
Poate tehnologia s modeleze schimbrile de comportament din timpul vieii?
n ce msur, monitorizarea i msurarea activitilor din cas pot fi cuantificate n
aa manier nct se pot crea noi aplicaii pe calculator utile casei?
Cum poate tehnologia s fie folosit pentru a facilita controlul caselor din prezent
i viitor, s se economiseasc resurse i s se mbunteasc sntatea?
Ce influeneaz modul n care oamenii se adapteaz la noi medii?
Care este modul de nvare al oamenilor n contextul casei?
Ce inovaii aduse unei case ar putea mbunti cel mai semnificativ maniera
noastr de a tri viaa de zi cu zi?
OSBA Open Source Building Alliance are scopul de a dezvolta componente cheie ale
unui model reactiv cu ajutorul cruia s se poat crea locuine n care:
Dezvoltatorii devin integratori i membri ai alianei i ofer soluii adaptate
indivizilor;
Arhitecii concep abloane de proiectare pentru a crea n mod eficient mii de medii
inteligente unice;
Productorii aprob standardele interfeelor i devin furnizori de componente de
primul nivel;
Constructorii devin instalatori i asamblori;
Clienii sunt cei din centrul procesului primind informaii personalizate legate de
proiectare, produse i servicii n funcie de deciziile lor.
Dintre implementrile realizate de ctre aliana OSBA amintim:
OSBA: Integrated Interior Infill (I3);
Sisteme OSBA care ofer soluii gen work-at-home, sisteme acustice integrate,
sisteme interactive, elemente transformabile, aplicaii i dispozitive conectate n
reea .a.m.d.
OPEN Prototype House Initiative
A fost format pentru a crea nite prototipuri de locuine care testeaz un nou model
pentru design-ul i fabricarea unor locuine cu reactivitate mare. Aceast alian, condus de
MIT House_n Open Source Building Alliance i Bensonwood Homes, va permite partenerilor
industriali s colaboreze pentru prototipizarea i crearea unor noi materiale, sisteme,
dispozitive utile pentru casele inteligente.
Just-In-Time Persuasive User Interfaces for Motivating Healthy Behaviors
Acest program investigheaz tehnologiile i proiectarea interfeelor utilizator pentru a
crea dispozitive i spaii persuasive. Programul dezvolt o tehnologie care detecteaz automat
un anumit punct de decizie (point-of decision) folosind senzori de mediu. Interfeele utilizator
folosesc aceste informaii just-in-time despre ce aciune efectueaz un anumit individ, i
idei preluate din psihologia social i alte tiine sociale, pentru a motiva o schimbare a
comportamentului n perioade lungi de timp aplicnd o metod neiritant, educaional.
Astfel, domeniile n care se aplic aceast idee sunt conservarea energiei, regim
alimentar sntos, activitate fizic, sigurana personal i la locul de munc i nvarea.
Informaiile pot fi expuse cel mai eficient pe un dispozitiv pervasiv, precum un telefon mobil.
22
Studiu Bibliografic
23
FUNDAMENTARE TEORETIC
3.1
3.1.1
Modelarea formal a contextelor

Ageni bazai pe cunotine
Aplicaia curent are la baz folosirea agenilor inteligeni. Precum oamenii cunosc,
nva i raioneaz, cunotinele i raionamentele sunt aplicate i n cazul agenilor bazai pe
cunotine. Astfel ei i pot nsui comportamente foarte greu de atins ntr-o alt manier. De
exemplu [39], un agent-reflex poate s gseasc o rut valid ntre 2 orae doar prin noroc,
sau un agent bazat pe rezolvarea problemelor poate rezolva probleme foarte complexe, dar
cunotinele sale sunt limitate i inflexibile. Cunotinele unui agent pot fi exprimate n
diferite forme generale, combinnd i recombinnd informaii pentru diferite scopuri, nu de
fiecare dat dintre cele mai folosite, la fel cum un matematician poate dezvolta o nou
teorem, care nu neaprat trebuie s satisfac anumite nevoi din acel moment.
Agenii bazai pe cunotine joac un rol crucial n cazul mediilor observabile parial
precum casele inteligente. Acetia pot combina cunotinele generale cu informaiile curente
pentru a infera aspecte nevizibile ale strii curente, nainte de a decide o anumit aciune, la
fel cum un doctor diagnosticheaz un pacient pentru a infera boala cu care se confrunt
pacientul, care nu este direct observabil, nainte de a i prescrie un anumit tratament [39].
Agenii bazai pe cunotine sunt foarte flexibili. Acetia sunt capabili s accepte noi
ntrebuinri sub forma unor obiective descrise i pot deveni competeni pentru a le ndeplini
doar spundu-li-se sau nvnd noi cunotine despre mediu, putndu-se adapta schimbrilor
mediului reactualiznd cunotinele relevante despre acesta.
3.1.1.1
Baze de date de cunotine

Componenta central i esenial a unui agent bazat pe cunotine este baza de
cunotine sau prescurtat KB (Knowledge Base). O baz de cunotine este la modul cel mai
simplist, un set de propoziii. Propoziiile se folosesc n acest cadru ca i termen tehnic,
acestea fiind exprimate ntr-un limbaj numit limbaj de reprezentare a cunotinelor, care poate
fi un limbaj ontologic, i reprezint nite adevruri formale pe care vrem ca agentul s le tie.
Principalele funcionaliti ale unei baze de cunotine sunt:
Adaug propoziii noi n baza de cunotine;
Interogheaz cunotinele existente.
Aceste 2 funcionaliti sunt numite n [39] TELL, respectiv ASK. n Figura 3 .10
poate fi vizualizat structura general a programrii unui agent bazat pe cunotine. Ambele
funcionaliti pot implica inferena, care este derivarea unor noi propoziii din cele existente.
Ca un orice alt agent, agenii bazai pe cunotine preiau la intrare o informaie perceput (n
cazul unei case inteligente o informaie primit de la senzorul de temperatur, de exemplu) i
returneaz o aciune. Agentul folosete baza de cunotine pentru a efectua orice operaiune.
De fiecare dat cnd programul prezentat n Figura 3 .10 este apelat, se efectueaz 3 lucruri.
Prima dat, se adaug informaiile percepute n baza de cunotine. Ulterior, este interogat
baza de date pentru a cere ca rspuns o aciune pe care ar trebui s o nfptuiasc, n acest
proces putnd fi implicate mai multe aciuni de argumentare n legtur cu starea curent a
mediului, despre diferite scenarii posibile ale concretizrii aciunii returnate .a.m.d., acest
proces decizional fiind cel mai pretenios dintre paii concrei ai programului. n final, agentul
executa aciunea i informeaz KB dac aciunea a fost concretizat i care au fost
consecinele.
Fundamentare Teoretic
Figura 3.10 Cazul general de programare a unui agent bazat pe cunotine
Programul iniial al agentului, nainte de a primi informaii de la mediu, este construit

adugnd una cte una propoziiile care reprezint cunotinele celui care a fcut proiectarea
despre mediul n care va aciona agentul. Limbajul folosit pentru a exprima aceste propoziii
este un limbaj declarativ. O abordare mai veche sugera folosirea unui limbaj procedural
pentru a exprima aceste propoziii direct prin cod de program. n cazul aplicaiei de fa vom
folosi un limbaj declarativ pentru a reprezenta cunotinelor. El va fi detaliat n seciunile
urmtoare.
n plus, pe lng aceste aciuni din program prin care i se spune unui agent ce s fac,
se pot aduga acestui agent mecanisme care i permit s nvee de la sine. Aceste cunotine
pot fi ncorporate n baza proprie de cunotine putnd fi folosite pentru luarea deciziilor,
astfel putnd construi un agent autonom.
3.1.2
Reprezentarea cunotinelor
n seciunea anterioar am prezentat agenii bazai pe cunotine. Aceste cunotine

trebuie reprezentate ntr-un limbaj declarativ. Aici vom detalia conceptul de ontologie, cu
ajutorul creia se poate organiza mediul i entitile componente ntr-o ierarhie generalizat i
structurat de clase.
Domeniile complexe, precum controlarea unui robot ntr-un mediu schimbtor,
precum o cas inteligent, necesit o reprezentare generalizat i flexibil a informaiilor.
Conceptele generale ce trebuie reprezentate sunt Aciune, Timp, Obiect Fizic, Presupunere.
Reprezentarea acestor concepte este domeniul ingineriei ontologice.
Este duntor s ncercm s reprezentm o descriere complet a tuturor lucrurilor,
existente, dar e binevenit s reprezentm conceptele de baz, care ulterior s fie detaliate, n
funcie de necesiti. Colecia general de concepte reprezentate, se numete ontologie
superioar, datorit conveniei de a reprezenta conceptele generale n partea de sus, n timp
ce conceptele specifice completeaz partea de jos a modelului, ca n Figura 3 .11.
Figura 3.11 Exemplu de modelare a unei ontologii superioare
Pentru orice ontologie specializat este posibil s se fac schimbri pentru a putea
conecta aceast ontologie ntr-una mai generalizat. Aceast proprietate confer reprezentrii
ontologice a cunotinelor o flexibilitate foarte mare, fiind exact ceea ce este nevoie pentru
modelarea bazei de cunotine a unui agent bazat pe cunotine care acioneaz ntr-o cas
inteligent. O problem care se pune este dac toate ontologiile ar putea converge la o
ontologie generalizat [25]. Acest lucru este un subiect de controvers. Totui, exist nite
caracteristici ale ontologiilor de uz general care le face s fie distincte fa de ontologiile
specializate:
O ontologie generalizat trebuie s poat fi aplicat n orice domeniu specializat;
ntr-un domeniu suficient de complex cunotinele diferite trebuie unificate
deoarece argumentarea i rezolvarea problemelor poate s implice mai multe
domenii simultan.
3.1.3
3.1.3.1
Folosirea ontologiilor n modelarea contextelor
Modelarea contextului cu ontologii

n trecut, integrarea senzitivitii la context n sistemele ubiquitous s-a dovedit a fi o
munc complex i foarte costisitoare datorit lipsei de infrastructura necesar, cum ar fi
componente hardware, sisteme de operare, precum i inexistena unui model de contexte
comune care s permit reutilizarea [45].
n [21] sunt expuse cerinele de infrastructur i de reutilizare pentru a crea servicii
senzitive la context pentru o cas inteligent:
Un model comun de reprezentare a contextelor, care poate fi mprtit de toate
dispozitivele i serviciile. Aceast component e necesar deoarece fiecare
component ca parte din sistemul casei inteligente trebuie s aib aceeai
interpretare a datelor schimbate. Folosirea unui model comun dintr-un singur
domeniu sau ntre mai multe domenii eficientizeaz schimbul de informaii ntre
componente.
Un set de servicii care execut achiziie de context, descoperire de context i
interpretare de context.
Reprezentarea folosind ontologii se dovedete a fi cea mai bun abordare n rezolvarea
problemelor de independen a componentelor, mpreun cu limbajul de exprimare, sistemul
de operare i componentele middleware. Avantajele modelrii contextelor folosind ontologii
aplicate i n proiectul curent sunt [46]:
3.1.3.2
Permit analiza formal a cunotinelor prin argumentarea contextelor;

Prin argumentare, concepte de nivel nalt pot fi derivate din concepte de nivel jos;
Ontologiile pot fi verificate pentru consisten i pot fi validate n funcie de
celelalte ontologii existente;
Pot fi introduse relaii inter-ontologice i ierarhii implicite bazate pe reguli.
Proiectarea ontologiilor de context

Dei exist multe propuneri de proiectare a ontologiilor de context, se pune problema
ce model este cel mai potrivit i care aduce cele mai multe avantaje cnd se creeaz un sistem
senzitiv la context nou. Astfel se ridic urmtoarele ntrebri:
Ct de bine poate o ontologie s reprezinte concepte, atribute i relaii ntr-o form
exact i bine definit?
Ct de capabil este limbajul pentru a crea interogri eficiente pentru argumentare?
Care este cea mai eficient proiectare n arhitectura ontologic?
Cum pot fi extinse aceste ontologii pentru a suporta incertitudinea?
Care este ctigul de performan folosind alegerea de proiectare?
Propunerile existente de proiectare, unele fiind n curs de standardizare, susin un
model ierarhic i stratificat.
Contextele pot fi organizate n dou categorii majore, context direct i indirect.
Contextul direct, achiziionat direct de la un furnizor. Mai departe contextul direct poate fi
clasificat n context senzorial i context predefinit. Contextul senzorial este achiziionat de la
senzorii casei inteligente sau de la senzorii virtuali, cum ar fi serviciile. Contextul definit este
cel mai des predefinit de ctre utilizator n mod particular. Folosind un mecanism de
argumentare a contextelor, se pot infera contexte indirecte, bazate pe cele directe. De
exemplu, statutul curent al unei persoane care este la du ntr-o cas inteligent poate fi inferat
din locaia sa, starea nclzitorului de ap i starea uii. n Figura 3.3 se pot observa ontologii
specifice pentru o cas inteligent.
Diferitele tipuri de contexte au caracteristici temporale diferite, de exemplu contextul
senzorial este dinamic odat cu trecerea timpului, n timp ce contextul predefinit este static.
De asemenea, pot interveni inconsistene sau conflicte ntre diferitele tipuri de contexte,
datorit erorilor de tehnologie sau ntrziere n procesare. Doar clasificnd contextele variate
i tiind caracteristicile se poate efectua argumentare de contexte pentru a elimina conflictele
i a menine consistena [13].
Figura 3.12 Definire ontologii specifice reprezentate prin reele Bayesiene
Unul dintre cele mai cunoscute modele este SOCAM (Service Oriented Context
Aware Middleware) detaliat n [21]. Specificaiile acestuia presupun o arhitectur natural pe
dou nivele ca Figura 3 .13:
Nivelul superior - pentru ontologii superioare comune, n care sunt ncadrate
conceptele generale;
Nivelul inferior - pentru ontologii specifice, care sunt aplicate n cteva domenii
inteligente.
Figura 3.13 Model de proiectare a ontologiilor contextuale, folosind SOCAM
Ontologiile sunt scrise n OWL (Ontology Web Description Language), limbajul

pentru ontologii Web propus de W3C. Ontologiile definite n OWL pot fi referite prin
serverele Web de ctre alte ontologii i descrcate de ctre aplicaii care folosesc ontologiile.
Faptul c aceste ontologii pot fi accesate prin diferite servere Web, furnizeaz flexibilitatea i
extensibilitatea necesar unui sistem distribuit.
Avantajele folosirii unei astfel de arhitecturi stratificate este faptul c numrul
cunotinelor de context este redus, iar procesarea contextului de ctre mecanismul de
argumentare este limitat, prin rencrcarea dinamic a ontologiilor de nivel inferior atunci
cnd apari modificri de mediu. Ontologiile inferioare specifice se pot ataa ontologiei
generale pentru a crea prin deducie concepte de nivel nalt.
O alt abordare specific n elaborarea ontologiilor de context este CoOL[46]. Precum
SOCAM acesta se bazeaz tot pe o arhitectur pe dou nivele:
Nivelul inferior CoOL Core. Acest nivel se bazeaz pe limbajele OWL, DAML +
OIL de descriere a ontologiilor, de altfel, oferind extensii pentru folosirea i a altor
limbaje descriptive;
Nivelul superior CoOL Integration o colecie de extensii de scheme i
protocoale.
Autorii argumenteaz c flexibilitatea alegerii limbajului de reprezentare a ontologiilor
favorizeaz dezvoltatorii de programe care au posibilitatea de a alege pe cel mai potrivit
planurilor lor. Mecanismul de argumentare este construit n limbajul F-Logic, n principiu
pentru c F-Logic este un limbaj orientat obiect, expresiv, avnd posibilitatea de extensie la
argumentare bazat pe reguli.
Modelul contextual propus este bazat pe modelul ASC (Aspect Scalabilitate Context).
Modelul ASC este construit n jurul acestor trei concepte de baz, entitile fiind instane ale
informaiilor contextuale. Un aspect agreg una sau mai multe modele scalare i ncapsuleaz
obiecte avnd aceleai semantici. Informaia contextual ncapsuleaz datele propriu-zise
mpreun cu meta-datele care caracterizeaz datele propriu zise.
Tabel 3.2 Comparaie ntre SOCAM i CoOL privind modelarea ontologiilor de context
Limbaj de descriere
SOCAM
OWL
Specificaii Model
Proiectat pe 2 nivele
Modeleaz contexte i relaii cu
tipuri de date i obiecte
Extensii
probabilistice
ale
predicatelor
Mecanism de
argumentare
Argumentare ontologic
Argumentare cu reguli
Concluzii
Fiabilitatea ontologiilor se
folosesc
numai
ontologiile
inferioare
n
procesul
de
argumentare.
Model foarte bine acceptat n
dezvoltarea sistemelor ubiquitous
CoOL
OWL sau alte limbaje
(DAML, F-Logic .a.m.d.)
Proiectat pe 2 nivele
Utilizeaz modelul ASC
Modelul ASC poate fi folosit
ca un model de transfer ntre
diferite tipuri de modele de
context
Mecanism de inferen Onto
Broker
F-Logic ca limbaj de
interogare
ASC este un model flexibil
ce poate folosi ca vocabular
de baz pentru alte modele.
ASC se poate folosi cu valori
eterogene
care
descriu
aceeai entitate
3.1.3.3
Limbajul OWL
a) Introducere
Limbajul OWL se afl ntre specificaiile World Wide Web Consortium (W3C) i este
folosit ca o component fundamental a iniiativei Semantic Web [30]. Limbajul se bazeaz
pe Extensible Markup Language (XML), XML Schema[31], Resource Description
Framework (RDF) i pe RDF Schema (RDF-S) [09]. Este divizat n 3 sub-limbaje diferite
prin expresivitate: OWL-Lite, OWL-DL i OWL-Full. OWL-DL este folosit cel mai frecvent,
pentru c este cel mai expresiv, fr a pierde completitudinea i decidabilitatea, spre deosebire
de OWL-Full.
Au fost dezvoltate mai multe unelte pentru a putea lucra cu OWL:
Protg, care este un editor grafic;
Jena, care este un Java API pentru a accesa ontologiile OWL;
Racer, un modul de inferen care poate fi integrat cu Jena i Protg.
Mai multe detalii despre aceste unelte vor fi furnizate n seciunile ulterioare.
b) Elementele limbajului OWL
Cele mai importante elemente ale limbajului OWL vor fi descrise aici. O specificare
detaliat poate fi gsit n [26]. Cuvntul cheie Class este folosit pentru a defini concepte
ontologice. Cuvntul cheie subClassOf definete concepte specializate, deci poate fi folosit
pentru a construi taxonomii. Cuvntul cheie DataTypeProperty este folosit pentru a defini
atribute i concepte. Scopul variabilei se specific prin schem XML. Cuvntul cheie
ObjectProperty definete relaii ntre concepte. Acestea pot fi marcate ca i tranzitive,
simetrice sau funcionale. Dou relaii pot fi marcate ca una fiind inversa celeilalte. Relaiile
pot fi specializate folosind subPropertyOf n analogie cu subClassOf pentru concepte.
Att relaiile ct i atributele pot fi modificate prin restricii de cardinalitate i noi
valori. De asemenea este posibil s se defineasc fapte despre conceptele, atributele i relaiile
definite anterior prin instanierea lor. Aceste instane se numesc indivizi. Mai mult, este
posibil s definim concepte specializate, dependente de valorile relaiilor i atributelor.
OWL furnizeaz de asemenea mijloace pentru a clasifica ontologiile i pentru a marca
conceptele, atributele, relaiile i indivizii n analogie cu elementele altor ontologii. Acest
lucru furnizeaz interoperabilitatea sistemelor care folosesc ontologii diferite.
c) Argumentare folosind OWL
Potrivit semanticii diferitelor elemente ale limbajului se pot deduce cunotine n mod
explicit folosind faptele deja definite. Conform proprietilor subClassOf, subPropertyOf,
intersectionOf, unionOf i disjointWith se poate calcula ce indivizi aparin unui concept i
vice-versa, ce concepte se mapeaz unui obiect dat. O list mai complet de reguli poate fi
gsit n [32].
Mai mult, valorile unor atribute i relaii pentru un individ pot fi calculate n cazul n
care acestea nu sunt explicit precizate, folosind subPropertyOf, inverseOf i proprietile de
tranzitivitate i simetrie.
Exist mai multe metode cu care se face modelarea i argumentarea contextelor.
Dintre acestea amintim SOCAM, CoOL, CONON, COBRA-ONT i SOUPA. SOCAM i
CoOL fac parte din scopul acestei teme fiind detaliate n capitolul precedent. Toate aceste
metode, folosesc semantica ontologic pentru a face argumentare logic. Totui, beneficiul
real al folosirii ontologiilor pentru informaii despre context n sistemele pervazive, nu va
deveni efectiv nainte ca s se propun un standard general valabil pentru ontologia
contextelor.
Tabel 3.3 O parte din regulile de argumentare OWL
3.1.4
Extensii probabilistice ale ontologiilor
n domeniul caselor inteligente incertitudinea este un aspect inerent. De exemplu, cel

mai evident caz de incertitudine este incorectitudinea i imperfeciunea datelor preluate de la
senzori. Agenii, n aproape nici un caz nu au acces n ntregime la toate informaiile din
mediu. De asemenea, aceti ageni raionali trebuie s poat crea raionamente n incertitudine
ntr-o manier eficient. Toate aceste aspecte privind incertitudinea n modelarea contextelor
se traduc n interpretare eronat a datelor de context de nivel inferior i implicit a datelor
derivate de nivel superior.
nc de la apariia sa, modelul probabilistic sau modelul reelelor Bayesiene [39] s-a
dovedit a fi o tehnic bine ntemeiat pentru reprezentarea i raionarea n incertitudine. n
particular o reea Bayesian reprezint o distribuie uniform a unui set de variabile aleatoare.
Cu ajutorul acestui model se poate rspunde la interogri complexe despre oricare dintre
aceste variabile. Astfel reelele Bayesiene furnizeaz diferite tipuri de raionamente:
Predicie Raionare de la cauz la efect;
Abducie Inferarea unei cauze din efect;
Explicare Evidenele privind cauza unui eveniment reduc posibilitatea
consumrii unui alt eveniment datorit rezultatelor lor comune. Acest lucru este
dificil de modelat n sistemele cu raionamente bazate pe reguli.
Totui o limitare fundamental a reelelor Bayesiene n cazul reprezentrii
cunotinelor este faptul c acestea nu pot reprezenta informaia structural i relaional [49].
Deci o reea Bayesian nu este potrivit pentru a reprezenta date contextuale corelate i
dinamice n mediile computaionale omniprezente.
n [48] se prezint un model unificat care motenete avantajele folosirii att a
modelului probabilistic, ct i al ontologiilor, aceste dou tehnici fiind integrate. Cu ajutorul
acestui model se va putea construi o ontologie care va reprezenta att structural ct i
probabilistic cunotinele contextuale, iar raionamentele n incertitudine vor fi construite tot
cu ajutorul reelelor Bayesiene.
O mare parte a cercetrii n domeniul caselor inteligente s-a adresat problemei de

incertitudine. Printre primele eforturi a fost ncercarea de a modela incertitudinea
informaiilor contextuale folosind atribute precum imperfeciunea, acurateea .a.m.d. Astfel
acest model unificat este compus din dou pri eseniale:
Schema relaional Reprezint structura i organizarea informaiilor sub form
de clase, relaii i proprieti.
Model probabilistic care adnoteaz dependenele probabilistice condiionale
dintre proprietile claselor.
Un exemplu de reprezentare a acestor dou scheme poate fi vzut n Figura 3.5:
Figura 3.14 (a) Schema relaional i (b) Modelul probabilistic pentru o cas inteligent
Bazat pe modelul propus mai sus putem construi o ontologie de context pentru a capta
cunotinele preluate dintr-o cas inteligent. Precum se specific i n cazul arhitecturii
SOCAM, i aici se pot modela ontologii de context folosind acel model stratificat, cu
ontologiile generale pe nivelul superior, iar cele specifice pe nivelul inferior.
Acest model are dou componente:
Ontologie generic este ontologia de nivel superior la fel ca i n cazul SOCAM;
Ontologie specific o colecie de ontologii de nivel inferior care definesc detalii
despre conceptele i proprietile din fiecare sub-domeniu. O ontologie specific
pentru un sub-domeniu este compus din dou pri:
o Schema relaional care specific relaiile i cascadrile ntre relaii
pentru sub-domeniu;
o Modele probabilistice care reprezint dependenele probabilistice
condiionale dintre proprietile acelui sub-domeniu.
n Figura 3.6 ontologia generic definete conceptele de CompEntity, Location,
Person, Activity. Detaliile fiecrui concept generic precum relaiile sau dependenele
probabilistice sunt redefinite n ontologii specifice domeniului (pe un nivel inferior), care pot
varia de la un domeniu la altul.
Figura 3.15 Arhitectura SOCAM cu ontologii specifice i modele probabilistice
Contextul ontologic se reprezint folosind limbajul OWL, cruia i-au fost adugate
cteva elemente pentru a modela conceptele noi, privind relaiile ntre entitile probabilistice
i modelele probabilistice. Limbajul este numit de cercettori PROWL (Probabilistic
Annotated OWL, tradus OWL cu adnotri pentru probabiliti).
Folosind aceast structur de modelare probabilistic a contextelor, se pot face 3 tipuri
de raionamente:
Raionamente din schema de baz a modelului:
o Raionament bazat pe reguli;
o Raionament ontologic.
Raionamente inovative adugate de modelul extins:
o Raionament Bayesian.
Raionamentele bazate pe reguli au aceeai logic precum n schema clasic, dar cu
meniunea c n acest model sunt aplicate claselor probabilistice i nu unor clase normale.
Raionamentele ontologice sunt asemenea cu cele din schema clasic, doar ca ele sunt
reprezentate acum n PROWL. Totui se pot face raionamente tip OWL fr probabiliti,
folosind OWL, deci nu se va ajunge la o constrngere de limbaj n cazul n care nu se vrea
folosirea probabilitilor pentru astfel de raionamente.
Raionamentele Bayesiene se fac pe baza reelelor Bayesiene construite din modelul
contextului. n funcie de domeniu se pot construi una sau mai multe reele derivate care
corespund fiecrui model probabilistic. Aceste reele se construiesc folosind algoritmul
Construct-BN [50].
Avantajele acestui model sunt introducerea probabilitilor n modelarea iniial a
contextelor. Deoarece ontologiile reprezint conceptele dintr-un domeniu, acest model de
context poate ngloba ntr-o manier facil. Folosind aceast abordare se poate modela un
domeniu al bazei de cunotine comun pentru casele inteligente fr a fi necesar construcia
unei baze de cunotine noi de fiecare dat. Deci aceast modelare suport scalabilitatea.
3.2
3.2.1
Metode folosite pentru modelarea bazelor de cunotine

Metodologii existente pentru crearea bazelor de cunotine
Ingineria proiectrii cunotinelor se ocup cu structurarea, dezvoltarea i

standardizarea bazelor de cunotine. Aa cum a fost precizat i n capitolele anterioare
ontologiile sunt un model comun i cel mai folosit pentru reprezentarea cunotinelor i
crearea bazelor de cunotine.
n [51] se descriu multiple metodologii create de-a lungul timpului pentru a defini
baze de cunotine folosind ontologii. Metoda folosit de ctre Cyc KB [52] este compus din
3 faze. Prima faz const din codificarea manual a cunotinelor existente, n care
cunotinele comune sunt preluate manual. A doua i a treia faz se refer la achiziionarea
noilor cunotine utiliznd limbajul natural, respectiv unelte de nvare folosite de
dispozitivele de calcul. Diferena dintre aceste dou faze este faptul c cunotinele noi sunt
achiziionate de dezvoltatori folosind unelte n faza a doua, respectiv automat de ctre maini
n faza a treia.
n metoda KACTUS [53] ontologiile se construiesc pe baza unei baze de cunotine a
unei aplicaii existente, la care se aplic un proces de abstractizare. Astfel, cu ct mai multe
aplicaii vom construi, cu att mai general va deveni baza de cunotine. Cu alte cuvinte,
metoda presupune crearea unei baze de cunotine pentru o aplicaie, pentru ca mai trziu dac
o baz nou de cunotine va fi necesar pentru un domeniu similar, se va generaliza baza de
date existent ntr-o ontologie i se va adapta ambelor aplicaii. Aceasta este o metod
bottom-up (de jos n sus).
Metoda Sensus [54] este o abordare top-down (de sus n jos) pentru a deriva
ontologii specifice din ontologii mari. Autorii propun identificarea unui set de termeni cheie
care sunt relevani pentru un anumit domeniu.
Methontology [55] este o metodologie cu ajutorul creia se pot crea baze de cunotine
fie de la nceput, fie printr-un proces de reutilizare. Acest mediu de dezvoltare include mai
muli pai n construirea lor aa cum se poate vedea n Figura 3.7: identificarea procesului de
dezvoltare ontologic, un ciclu de via bazat pe prototipuri evolutive i tehnici particulare
pentru executarea fiecrei activiti.
Figura 3.16 Procesul de dezvoltare a unei baze de cunotine folosind Methontology
Pe lng aceste metodologii enumerate mai sus, mai exist i altele, niciuna dintre
aceste abordri neatingnd nc stadiul de maturitate, comparnd, de exemplu cu ingineria
software. Totui, se poate considera Methontology cea mai matur abordare n construirea
bazelor de cunotine, recomandat i de FIPA. Toate aceste metodologii nu sunt unificate,
deoarece fiecare grup de cercettori aplic abordarea proprie n procesul creaional.
Colaborarea ntre aceste grupuri pentru a unifica abordrile lor ar fi cea mai rezonabil
metod pentru a ajunge la un proces unificat i matur de creare a ontologiilor specifice
aplicate n cazul bazelor de cunotine.
3.2.2
Unelte de dezvoltare a ontologiilor
n ultimii ani numrul de unelte pentru construirea de ontologii a crescut exponenial.

Aceste unelte au scopul de a oferi suport pentru dezvoltarea de ontologii i pentru folosirea
acestora. Astfel vor fi prezentate cele mai importante unelte pentru ca mai apoi s fie descris
mai amnunit unealta folosit pentru crearea ontologiilor pentru casa inteligent dezvoltat n
lucrarea de fa i anume Proteg.
Ontoligua Server [56] a fost prima unealt creat pentru dezvoltarea ontologiilor. A
fost dezvoltat la Universitatea din Stanford i a aprut n 1990, pentru a facilita dezvoltarea
ontologiilor de tip Ontoligua folosite pentru nite aplicaii de tip Web. Iniial, Ontoligua
Server se comporta ca un editor pentru ontologii pentru ca mai apoi s fie adugate noi
module precum Webster, care era un rezolvitor de ecuaii sau OKBC (Open Knowledge Base
Conectivity) care era un modul de conectare la baza de cunotine, mai trziu standardizat ca
i protocol de comunicaie. Editorul funciona de asemenea ca un translator inter-limbaje,
precum LOOM, Prolog, CORBA IDL, CLIPS .a.m.d.
Tot din acea generaie de unelte a aprut Ontosaurus [57] dezvoltat la Institutul de
tiine Informaionale de la Universitatea South-California. Acesta avea n componena sa
dou module: un server de ontologii, care folosea LOOM pentru reprezentarea cunotinelor i
un client Web care avea i suport de translatare din LOOM n Ontoligua, KIF, KRSS i C++.
Ontologiile puteau fi de asemenea accesate folosind protocolul OKBC.
Aceste unelte din prima generaie au dezavantajul de a fi create ca fiind neextensibile,
dependente de limbaj, fiind create pentru a fi folosite doar la nivel de proiect de cercetare, nu
pentru uz comun.
A doua generaie de unelte de dezvoltare de ontologii a aprut recent. Ele au fost
construite ca fiind medii robuste integrate n sisteme care aduc suport tehnologic pe toat
durata de via a activitii unei ontologii. Acestea au fost concepute prin arhitecturi
extensibile, bazate pe componente, unde noi module se pot integra uor pentru a aduga
ntrebuinri noi. Pe lng toate acestea, modelele de reprezentare a cunotinelor sunt
independente de limbaj. Protg 2000 [65 dezvoltat la Universitatea din Stanford, este un
program gratuit, independent de platform, cu o arhitectur extensibil. Partea esenial a
acestuia o constituie editorul de ontologii, dar se pot importa module pentru a edita ontologii
n diferite limbaje (F-Logic, Jess, OIL, XML, Prolog), dispune de acces OKBC, creare i
execuie de constrngeri (PAL), fuzionare de ontologii (PROMPT) .a.m.d. WebODE [66] este
succesorul lui ODE i a fost dezvoltat la Universitatea Tehnic din Madrid. Este o unealt
asemntoare cu Protg i implementeaz metodologia Methontology prezentat n seciunea
anterioar. Ontologiile sunt pstrate n baze de date relaionale i de asemenea suport
introducerea de limbaje ontologice diferite (XML, RDF, OIL, DAML+OIL, F-Logic, Jess).
n ultima generaie au aprut extensii ale editoarelor enumerate mai sus pentru a edita
ontologii i a crea baze de cunotine specifice serviciilor Web semantice.
3.2.2.1
Protg 4
Mediul de dezvoltare a ontologiilor Protg, ajuns la a 4-a versiune, este un mediu
complet i stabil pentru dezvoltarea bazelor de cunotine i a ontologiilor oferind facilitatea
de a integra o varietate mare de module adiionale, care pot fi dezvoltate i de ctre utilizatorii
de rnd, codul surs al aplicaiei fiind pus la dispoziie.
Protg dispune de 2 editoare separate fiecare avnd un anumit scop. Editorul
Protg-Frames faciliteaz dezvoltarea bazelor de cunotine compatibile cu standardul
OKBC. Acest editor furnizeaz interfee utilizator, care pot fi modificate pentru a modela
cunotinele dup bunul plac al utilizatorului, precum i module pentru vizualizare,
management, inferen sau raionare. De asemenea este pus la dispoziie i un API Java care
poate fi folosit pentru a crea alte aplicaii pentru accesarea cunotinelor modelate cu Protg
Frames.
Editorul Protg-OWL face posibil dezvoltarea de ontologii folosind standardul W3C
OWL. Acesta ofer uneltele necesare pentru a folosi ontologiile OWL i RDF, suport pentru
vizualizarea claselor, expresii OWL i alte faciliti. Platforma Protg ofer flexibilitatea de a
integra module adiionale. Aceste module sunt de trei tipuri: module de stocare, module
grafice i panouri.
Un modul de stocare este un modul care salveaz sau ncarc modele dintr-un format
fiier sau baze de date (XML, XML Schema, RDF .a.m.d.).
Un modul grafic se ocup de partea grafic a aplicaiei, fiind o component cu ajutorul
creia se pot vizualiza imagini, sunete sau chiar imagini video.
Panourile pot fi vizualizate n fereastra principal Protg. Exist mai multe subtipuri
de panouri n Protg:
Panouri de vizualizare:
o OntoWiz vizualizare grafic configurabil sub form de graf pentru
ontologii i relaiile ntre ele. Se formeaz o diagram similar cu UML.
o TGWiz vizualizare grafic a metodelor claselor.
o Jambalaya o unealt de rsfoire a ontologiilor care permite editarea
acestora.
Panouri pentru managementul fiierelor sau a proiectului:
o BeanGenerator genereaz clase Java (Java Beans) dintr-un model de
clase ontologice specificate n Protg.
o Prompt permite manipularea a diferite modele care pot fi unificate,
comparate, sau compuse.
o DataGenie ntrete interaciunea dintre Protg i baze de date furniznd
un modul JDBC de conectare la baze de date.
Panouri pentru motoare de raionare:
o QueryTab pentru interogarea bazei de cunotine.
o PAL mecanism de editare i evaluare a axiomelor PAL (Protg Axiom
Language Limbajul Axiomelor Protg).
Conceptul de ontologie are n Protg o form asemntoare cu cea a claselor din
proiectarea orientat-obiect. Clasele Protg sunt similare cu clasele Java i pot fi aezate ntro structur ierarhic, diferena fiind c aceste clase nu conin definiii de metode. Acestea pot
fi abstracte sau concrete, doar cele concrete putnd fi instaniate. Protg suport de asemenea
motenirea multipl. Atributele sunt definite ca perechi nume-valoare: valori primitive (logic,
ntreg, flotant, ir de caractere); numele se reprezint printr-un ir de caractere. Aceste atribute
pot fi de asemenea referine la alte clase sau instane de clase. Cu ajutorul atributelor se
construiesc relaiile ntre clase.
3.3
Metode folosite pentru dezvoltarea agenilor
Dei numrul de medii de dezvoltare a agenilor a crescut mult n anii cureni, medii
care furnizeaz unelte vizuale i interfee pentru a uura proiectarea agenilor i realizarea a
diverse sisteme de ageni, eforturile i investiiile n acest sens sunt considerabil mai mici,
dect n dezvoltarea uneltelor menite altor ramuri ale industriei software.
Totui, metodologiile existente elaborate de diferite laboratoare de cercetare n
domeniul sistemelor multi-agent sugereaz mprirea procesului de dezvoltare a agenilor n
faze similare cu dezvoltarea unui alt produs software. Astfel procesul este mprit n 5 faze:
cerinele primare, cerinele secundare, proiectarea arhitecturii, proiectarea detaliat,
implementarea.
Cerinele primare identific actorii i obiectivele reprezentate de dou modele diferite.
Se construiesc diagrame care depicteaz implicrile i relaiile dintre actorii modelului,
numite dependine. Aceste dependine depicteaz modul n care actorii depind unii de alii
pentru a ndeplini obiectivele sau pentru a executa planurile. Diagramele obiectivelor
nfieaz analiza obiectivelor i planurilor referitoare la un actor responsabil s le
ndeplineasc.
Toate aceste modele sunt extinse n faza de cerine secundare, care modeleaz sistemul
ncadrat n mediul n care va aciona. n aceast faz obiectivele sunt descompuse n subobiective.
n faza de proiectare detaliat se construiesc specificaiile obiectivelor, capacitilor i
a raionamentelor agenilor. De asemenea, comunicarea ntre ageni este specificat n detaliu.
n aceast faz se proiecteaz sistemul strict dependent de platforma de dezvoltare folosit,
fiind adaptat la trsturile programrii adaptate a agenilor.
Faza de implementare are ca obiectiv generarea codului de construire a agenilor din
specificaiile oferite folosind proiectarea de detaliu.
3.3.1
Platforme de dezvoltare a agenilor
Datorit existenei unui numr mare de platforme i unelte de dezvoltare a agenilor,

fiecare oferind diferite faciliti, este binevenit o evaluare a acestora nainte de a alege una
care s satisfac necesitile sistemului dezvoltat. n principiu, criteriile de evaluare a
diferitelor medii de dezvoltare sunt necesitate, popularitate, ntreinere, documentaie.
Platformele pentru ageni furnizeaz un mediu n care se pot crea ageni executabili i
faciliteaz i servete la coordonarea agenilor prin platform, de exemplu, timpul de execuie
al unui agent, facilitnd totodat comunicarea cu alte module necesare n ansamblul
sistemului, unele platforme implicnd i elemente de securitate.
Fundaia pentru ageni fizici inteligeni FIPA [53] (The Foundation for Intelligent
Physical Agents) este o organizaie care promoveaz i standardizeaz tehnologiile folosite n
construirea agenilor. FIPA a completat un proces de standardizare a platformelor de
dezvoltare a agenilor. Acest proces include 5 cerine pe care o platform trebuie s le
ndeplineasc: comunicarea ntre ageni, transportul ntre ageni, managementul agenilor,
arhitectura abstract a platformei, respectiv aplicaii care extind platforma.
Arhitectura abstract a unei platforme precum i comunicarea ntre mai multe
platforme precizat n standardele FIPA poate fi vzut n Figura 3.8..
Figura 3.17 Arhitectura general a unei platforme de ageni i comunicarea ntre platforme
n [56] sunt analizate diferite platforme dup urmtoarele trsturi:

Standardizare standardele comune pentru dezvoltarea agenilor sunt FIPA i
(OMG) MASIF;
Comunicare suport pentru comunicare prin mesaje ntre platforme;
Liceniere ce tip de liceniere necesit;
Accesibilitate;
Mobilitate abilitatea de a migra un agent n stare de execuie;
Securitate securitatea intr i inter-platforme;
Documentare la nivel utilizator sau dezvoltator .
FIPA-OS [58] este o platform bazat pe componente, care faciliteaz dezvoltarea
rapid a agenilor conformi FIPA. FIPA-OS suport majoritatea specificaiilor experimentale
FIPA, fiind mbuntit n mod regulat ca proiect open-source.
Standardizare FIPA;
ntreieere Ultima versiune 2.2.0;
Comunicare Tehnologiile de comunicaie puse la dispoziie sunt ACL, IIOP,
RMI, XML;
Liceniere - licen public EPL (Emorphia Public License);
Accesibilitate orice sistem de operare, necesit minim Java 4;
Mobilitate suport ageni mobili, doar ca prototip;
Securitate RMI este criptat cu SSL pentru comunicare securizat inter-platforme;
Documentare la nivel utilizator sau dezvoltator.
Jack [60] este un mediu de dezvoltare orientat agent integrat n totalitate cu mediul de
dezvoltare Java. JACK furnizeaz o extensie orientat agent limbajului de programare Java,
avnd un mediu de dezvoltare i furniznd un set de clase utile dezvoltrii de aplicaii. Codul
surs JACK este compilat mai nti n cod surs Java nainte de a fi compilat mai departe n
cod-main pentru a fi executat.
Standardizare FIPA;
ntreinere Ultima versiune 3.5;
Comunicare Necesit o reea DCI pentru comunicare, similar cu TCP/IP;
Liceniere licen public;
Accesibilitate orice sistem de operare;

Mobilitate nu suport mobilitatea agenilor;
Securitate profit de securitatea oferit de JDK;
Documentare detaliat.
Zeus [61] are ca scop dezvoltarea rapid a aplicaiilor multi-agent furniznd un set de
unelte i componente care sunt folosite pentru a proiecta, dezvolta i organiza sistemele de
ageni. Mai mult, acesta furnizeaz un mediu care permite efectuarea de statistici i rapoarte,
vizualizarea agenilor, o interfa bine realizat, permite repararea agenilor, furnizeaz librrii
de strategii predefinite i multe alte faciliti. n schimb, documentaia disponibil este foarte
redus, ceea ce duce la multe dificulti n crearea aplicaiilor de ctre nceptori.
Standardizare FIPA;
ntreinere Ultima versiune 3.5;
Comunicare KQML i ACL;
Liceniere licen public;
Accesibilitate orice sistem de operare;
Mobilitate criptare prin cheie public sau privat;
Securitate codare MIME;
Documentare la nivel utilizator sau dezvoltator.
Platforma cea mai folosit pentru dezvoltarea agenilor este JADE [59]. Aceasta fiind
platforma folosit n proiectul curent, vom detalia specificaiile ei n seciunea urmtoare.
3.3.2
Platforma JADE
JADE (Java Agent Development Framework) a fost dezvoltat pentru a fi compatibil

cu specificaiile FIPA pentru sisteme multi-agent inteligente i interoperabile. Scopul acestuia
este de a simplifica dezvoltarea, asigurnd n acelai timp cerinele standardului printr-un set
de servicii sistem pentru ageni. Acest produs poate fi considerat un middleware care
implementeaz o platform pentru ageni i un mediu de dezvoltare pentru ageni. Sunt luate
n considerare toate aspectele care nu au de a face cu cerinele de construire ale unui agent, i
care sunt independente de aplicaie, precum transportul de mesaje, codarea mesajelor, sau
ciclul de via al unui agent.
JADE creeaz depozite multiple pentru ageni, fiecare dintre acestea poate fi pe
aceeai main sau pe maini diferite. mpreun, toate aceste containere formeaz platforma
JADE precum n Figura 3.9. Fiecare platform trebuie s aib un depozit principal, care deine
doi ageni speciali:
AMS (Agent Management System) Sistemul de management al agenilor este
agentul care deine autoritatea n platform, fiind agentul care creeaz sau distruge
ali ageni, distruge depozite de ageni sau oprete platforma.
DF (Directory Facilitator) Agenda de servicii a agentului care funcioneaz ca
un serviciu dup paradigma pagini aurii, care public serviciile agenilor din
platform, astfel nct ceilali ageni care au nevoie de aceste servicii, s le poat
gsi.
Platforma JADE dispune de nite servicii care furnizeaz tehnologii de creare a
agenilor specifice aplicaiilor multi-agent distribuite:
Controlul ciclului de via al agenilor;
Mobilitatea agenilor;
Transport punct-la-punct de mesaje;
Securitate, toleran la erori, suport pentru ageni replicai;
Planificarea mai multor aciuni simultane;

Unelte grafice care suport monitorizarea, controlul i depanarea aplicaiilor:
Ageni de monitorizare la distan, Ageni introspectori .a.m.d.
Figura 3.18 Platforma, depozitele i comunicaiile ntre platforme JADE
JADE furnizeaz de asemenea o integrare complet cu ontologiile create folosind

Protg. n terminologia JADE ontologiile mpreun cu reprezentarea lor se numesc scheme.
Aceste scheme se refer la clase Java proiectate pentru a reprezenta structura static a
ontologiilor. Elementele specifice ale unei scheme sunt obiecte care descriu structura
conceptelor, aciunilor i predicatelor permise n mesaje. De asemenea, pentru crearea acestor
scheme JADE furnizeaz un mecanism de transformare a ontologiilor direct din limbajul
descriptiv OWL n clase JAVA. Aceast unealt face ca integrarea dintre ontologiile descrise
n Protg i JADE s fie simpl.
3.3.3
Mediul JADEX 0.96
Jadex (JADE eXtension) este o aplicaie JADE, care este folosit pentru a crea
raionamente de tip BDI (Belief-Desire-Intention Convingere-Dorin-Intenie) pentru
ageni BDI, implementai folosind platforma JADE [62]. Ultima versiune aprut n 2007 este
0.96 care este o versiune stabil. Recent, Jadex a ajuns la versiunea 2.0 care este nc n faz
beta.
3.3.3.1
Modelul BDI definit n Jadex

Jadex faciliteaz folosirea modelul BDI pentru ageni introducnd presupuneri,
obiective i planul ca obiecte foarte importante care pot fi create i manipulate n interiorul
unui agent. n Jadex agenii au presupuneri care sunt modelate sub forma obiectelor Java i
memorate ntr-o baz de cunotine. Obiectivele reprezint strile de atins care influeneaz
comportamentul agenilor. Pentru a atinge obiectivele, un agent execut planuri care sunt
transpuse prin metode procedurale n Java. Arhitectura abstract prin care se pot vizualiza i
componentele descrise mai sus poate fi vzut n Figura 3 .19 [63].
Figura 3.19 Diagrama de colaborare ntre componentele unui agent Jadex
Aa cum se poate observa raionamentele agenilor Jadex se construiesc folosind cele

dou componente inter-conectate. Pe de o parte agentul reacioneaz la mesajele venite,
evenimente interne i obiective selectnd i executnd planuri, pe cealalt parte interpretorul
de raionamente proceseaz obiectivele curente pentru a vedea ce sublan consistent ar trebui
urmat.
Cele 3 concepte de baz ale unui agent Jadex sunt presupunerile, obiectivele i
planurile, acestea 3 fiind definite de ctre dezvoltator pentru a defini comportamentul
agentului BDI. Realizarea acestor 3 concepte este descris pe scurt n continuare.
Baza de presupuneri memoreaz faptele care se presupun a fi adevrate i este un
punct de acces pentru datele coninute de agent. Astfel, aceast component abstractizeaz
cunotinele i reprezint o vedere unificat a cunotinelor agentului. Reprezentarea
presupunerilor n Jadex este foarte simplificat i nu suport niciun mecanism de inferen.
Baza de presupuneri conine iruri de caractere care reprezint un identificator pentru o
presupunere specific (similar cu numele tabelei dintr-o baz de date relaional). Aceti
identificatori sunt mapai valorilor presupunerilor, numite de aceast dat fapte, care pot fi
convertite n obiecte Java. Jadex suport n acest moment dou tipuri de astfel de presupuneri:
presupuneri singulare i seturi de presupuneri. Deci baza de presupuneri fiind tare tipizat,
poate verifica n momentul rulrii dac obiectele care respect tipurile prezentate mai sus sunt
memorate.
Obiectivele sunt tratate n mediul Jadex ca fiind dorinele concrete ale unui agent la un
moment dat n timp. Pentru fiecare obiectiv pe care l are, un agent va nfptui aciuni, pn n
momentul n care consider obiectivul ca fiind atins, sau c acesta nu poate fi atins, sau c nu
se mai dorete atingerea acelui obiectiv. Spre deosebire de alte sisteme n Jadex nu trebuie ca
toate obiectivele s fie consistente unul cu cellalt. Pentru a distinge ntre obiectivele nou
propuse i obiectivele pentru care deja se ndeplinesc aciuni, s-a creat conceptul de ciclu de
via al obiectivului, obiectivele putndu-se astfel afla n 3 stri: activ, suspendat i opional.
Cnd un nou obiectiv este introdus el intr n sistem cu starea opional. Mecanismul de
deliberare a obiectivelor, este responsabil pentru determinarea tranziiilor pentru obiectivele
active. Unele obiective pot fi valide doar n contexte specifice determinate de presupunerile
agentului. Cnd un obiectiv devine invalid pentru contextul curent, acesta este marcat ca
suspendat pn la validarea contextului.
Patru tipuri de obiective sunt suportate de ctre mediul Jadex. Primul tip se refer la
obiectivele care definesc o aciune care trebuie executat, dar care nu neaprat conduce la un
rezultat specific. Al doilea tip se refer la obiectivele care definesc un scop sau care au o int
fr ns a se specifica cum se atinge acel obiectiv. Al treilea tip se refer la obiectivele care
reprezint o nevoie pentru informaii noi. Dac informaiile cerute nu sunt la dispoziie,
planurile sunt selectate i executate pentru a aduna informaiile necesare. Al patrulea tip i
ultimul reprezint obiectivele care specific o stare a agentului care trebuie pstrat odat ce a
fost atins. Toate obiectivele sunt reprezentate ca obiecte care au cteva atribute. Starea final
poate fi specificat ca o expresie evaluat pentru a verifica dac obiectivul a fost atins.
Structura obiectivelor care sunt n starea activ este memorat ntr-o baz de obiective. Un
agent BDI specificat n Jadex are cteva obiective de nivel nalt, care servesc ca puncte de
intrare n baza de obiective. Obiectivele pot fi separate n sub-obiective, formndu-se astfel o
structur arborescent de obiective.
Planurile descriu aciunile concrete pe care un agent le poate executa pentru a
ndeplini obiective. Un dezvoltator dezvolt un plan specificnd antetul planului i planul
propriu-zis. Antetul conine condiiile sub care planul poate fi executat i este specificat n
fiierul de descriere a agentului. Corpul planului este o structur secvenial, care descrie
aciunile care trebuie executate pentru a atinge un obiectiv sau pentru a reaciona la un
eveniment. n timpul execuiei unui plan se pot defini noi sub-obiective i atepta ca alte
evenimente s apar.
3.3.3.2
Definirea agenilor n Jadex

Definirea complet a unui agent se face n fiierul de definire a agentului. Acest fiier
este un fiier n format XML care conine toate proprietile relevante pentru un agent
(presupuneri, obiective, planuri). Pe lng descriptorii XML folosii pentru componentele
agentului, dezvoltatorul poate folosi expresii ntr-o variant Java pentru a specifica valori sau
parametri. Acest fiier este un fel de descriere a clasei agentului. Din acest fiier se instaniaz
agenii precum obiectele se instaniaz din clasele lor. De exemplu, planurile sunt declarate
specificnd cum s fie instaniate folosind clasele Java de descriere i un trigger cu care se
determin condiiile n care planul se execut. Tot n acest fiier se definete starea iniial a
unui agent folosind o configuraie iniial. Scrierea corect a fiierului de definiie a agentului
va fi detaliat n seciunea de implementare a lucrrii curente.
SPECIFICAII I ARHITECTUR SISTEM
4.1
Specificaiile sistemului
Principalele specificaii ale sistemului sunt controlarea i monitorizarea mediului,

dispozitivelor i aplicaiilor din casa inteligent. Sistemul va avea n componen trei tipuri de
roboi care vor trebui adaptai la contextul casei inteligente.
4.1.1
Controlul casei inteligente
Sistemul Smart House va furniza control automat al unor obiecte casnice (aparat de
aer condiionat, nclzirea central) mpreun cu controlul factorilor de confort din cas
(luminozitate, umiditate, cldur), sistemul fiind capabil s ia o decizie asupra aciunilor sau
misiunilor care trebuie nfptuite bazate pe datele contextuale procesate.
Cerinele funcionale ale sistemului dezvoltat curent vor fi prezentate n continuare.
4.1.1.1
Coordonarea aciunilor
Aplicaia va integra planuri de aciuni predefinite n vederea efecturii anumitor
execuii complexe i totodat va permite facilitatea de a crea aciuni definite de utilizator.
Utilizatorul va avea abilitatea de a stabili obiectivele primare ale sistemului, precum
maximizarea confortului locuitorilor casei inteligente. Obiectivele care trebuie atinse cnd se
vorbete de coordonarea aciunilor sunt:
Crearea sau anularea unei aciuni Utilizatorul va putea s introduc noi aciuni
sau s replanifice sau s anuleze misiunea curent. n cazul n care se produc
dependene n executarea unei misiuni planificate, sistemul va putea crea aciuni
care s fie executate naintea aciunii specificate.
Executarea aciunilor Aplicaia va executa n mod automat aciunile planificate
sau va putea s replanifice aciunile care nu au fost terminate cu succes.
Crearea de rapoarte Orice aciune nfptuit n sistem va fi detaliat ntr-un
raport de execuie.
4.1.1.2
Executarea operaiilor
Sistemul va putea s execute operaii de baz ca rspuns la schimbrile de context sau
aciuni primitive, ca operaii unitare ale unei misiuni. Dintre operaiile care se vor putea
nfptui n sistemul dezvoltat identificm:
Manipularea de obiecte Roboii vor putea manipula obiecte, prelua i muta
diferite obiecte ntre diferite locaii ale casei.
Controlul dispozitivelor Sistemul poate s i adapteze comportamentul n mod
automat, modificnd starea diferitelor dispozitive ubiquitous n acord cu situaia
curent sau intervenia direct a utilizatorilor. Cerina primordial a sistemului este
s creeze o atmosfer ct mai confortabil pentru locuitorii casei inteligente, prin
controlarea dispozitivelor, n funcie de anumii parametri preluai ca date de
context (de ex. temperatura). Printre parametrii care pot fi manipulai se numr
intensitatea luminoas, volumul muzicii ambientale, temperatura, umiditatea etc.
4.1.1.3
Interaciunea cu utilizatorii
Specificaii i arhitectur sistem
Utilizatorii trebuie s poat interveni n sistemul casei inteligente, dup bunul plac,
astfel sistemul necesit o interfa utilizator pentru crearea de aciuni utilizator sau controlarea
aciunilor i parametrilor cureni. Informaiile pot fi prezentate la cererea utilizatorului sau
automat cnd se execut o anumit aciune specific.
4.1.2
Monitorizarea casei inteligente
4.1.2.1
Achiziia datelor de context

Sistemul va putea extrage informaii contextuale de nivel inferior de la un numr mare
de furnizori de informaie, prin senzori fizici sau programe software. Aceste informaii de
context care vor fi urmrite sunt:
Urmrirea locaiei unei persoane, robot, sau obiect Locaia este cea mai
important dat contextual care este procesat. Sistemul trebuie s poat detecta
prezena membrilor familiei sau a intruilor, locaia acestor persoane n timp-real,
precum i locaia roboilor casei inteligente sau a altor dispozitive relevante.
Identificarea persoanelor, obiectelor, roboilor Persoanele sau roboii trebuie
identificai de sistemul casei inteligente, pentru a programa aciuni specifice
fiecrui actor din casa inteligent n mod separat.
Monitorizarea condiiilor de mediu din interiorul sau exteriorul casei inteligente
Monitorizarea acestui tip de condiii va fi posibil prin achiziionarea informaiilor
de la diferitele tipuri de senzori: luminozitate, umiditate, zgomot, presiune etc..
Monitorizarea dispozitivelor i a aplicaiilor casei inteligente Deoarece
dispozitivele i actuatorii n sistemul casei inteligente pot furniza informaii
contextuale valoroase, monitoriznd care dintre dispozitive este folosit precum i
starea lor actual este foarte important pentru ndeplinirea obiectivelor sistemului
curent. Astfel sistemul va monitoriza:
o Starea uilor nchis / deschis / ncuiat;
o Starea porii de la garaj nchis / deschis;
o Starea sistemului de nclzire nchis / deschis / nivel de nclzire;
o Starea sistemului de iluminare nchis / deschis;
o Starea ferestrelor nchis / deschis .a.m.d.
4.1.2.2
Procesarea datelor de context

Raionamentele aplicate pe datele contextuale, infer date contextuale de nivel
superior din date de context senzoriale i atomice, meninnd consistena bazei de cunotine.
Sistemul va ngloba reguli de inferen i de asemenea reguli auto-configurabile, pentru a
putea raiona asupra informaiilor contextuale.
Determinarea tipului de activitate nfptuit de un locuitor al casei inteligente este o
problem complex pentru sistemul senzitiv la context al casei i este bazat pe achiziia
informaiilor atomice de nivel inferior precum locaia, monitorizarea condiiilor de mediu sau
a dispozitivelor folosite.
Aceste date sunt procesate i n timp sistemul stabilete preferinele personale ale
fiecrui locuitor, pentru ca ulterior s determine programul zilnic al fiecrui locuitor. Astfel
sistemul va ngloba i funcia de nvare, pentru a deduce i actualiza preferinele
utilizatorilor.
4.1.2.3
Propagarea datelor de context

Dup achiziionarea informaiilor contextuale relevante, datele contextuale trebuie s
fie propagate la dispozitive, roboi, aplicaii. De asemenea aceste informaii necesit s fie
adaptate n funcie de tipul dispozitivului, n cazul n care un anumit dispozitiv al casei

inteligente necesit acele informaii.
4.1.3
Adaptarea roboilor la casa inteligent
Cele trei tipuri de roboi cu care va fi prevzut sistemul casei inteligente sunt robotul
supervizor, robotul care ndeplinete misiuni i robotul de companie, care se ocup de
divertismentul locuitorilor casei.
Aceti 3 roboi vor trebui adaptai la sistemul casei inteligente. Provocrile construirii
adaptabilitii roboilor la sistemul casei inteligente se rezum la dou motivaii-cheie. Prima,
un model adecvat sistemului casei inteligente, proiectat pentru a ndeplini misiunile pentru
care ei au fost introdui, respectiv, descrierea modelului folosind un limbaj cunoscut
sistemului.
4.1.3.1
Reprezentarea adecvat a roboilor

Unul din rolurile eseniale ale unei reprezentri este ca aceasta s ndeplineasc rolul
de substitut al obiectului real care trebuie controlat. O reprezentare bun a roboilor face de
asemenea posibil raionarea pe baza modelului, putnd astfel executa diferii algoritmi de
raionare pentru a infera cunotine noi pentru a reflecta ct mai bine cu putin evoluia
ulterioar a lumii n care acioneaz sistemul.
Elaborarea unui astfel de model a fost tot timpul o provocare pentru oricine a fost
interesat de reprezentarea unei pri din lumea real. Faptul c trebuie s reprezentm de
exemplu elementele reprezentative ale strii n care un membru al familiei, este suprat sau
gnditor, pentru a putea alerta robotul de companie s nceap s i fac datoria poate fi de
multe ori o problem complex i greu de atins.
4.1.3.2
Comunicarea dintre roboi

n plus fa de reprezentarea adecvat a roboilor, inteligena sistemului robotic const
de asemenea n interaciunea acestuia cu mediul casei inteligente. Roboii care execut
servicii pentru un mediu casnic inteligent, trebuie s aib mai multe funcionaliti cheie:
localizare, navigare, cartografiere, interaciune om-robot, recunoatere de obiecte i
manipulare de obiecte. Pentru a executa aceste funcionaliti roboii trebuie s fie n legtur
cu sistemul senzorial al casei, precum i cu ceilali roboi pentru a prelua informaii relevante.
4.1.3.3
Serviciile roboilor din casa inteligent

Scenariile pentru roboi dorite n casa inteligent tratat n lucrarea de fa sunt:
Mutarea obiectelor Acest scenariu are la baz mutarea obiectelor din camera
copiilor cnd acetia sunt plecai de acas, precum i a altor obiecte din diferite
camere, n contextul n care robotul este ntiinat c aceste obiecte nu se afl la
locul lor. Robotul (mission robot) desemnat pentru a nfptui aceast sarcin
navigheaz prin camer i identific respectivele obiecte folosind semnale RFID,
ridic, transport i depoziteaz obiectele n poziia desemnat. Printre obiectivele
urmrite din acest scenariu sunt depozitarea jucriilor n cutii i depozitarea lor n
locul lor de depozitare, de exemplu, garaj.
Servicii de divertisment pentru copii Acest serviciu este un serviciu complex,
n care se detecteaz starea de spirit a copiilor, n cazul n care se detecteaz c
unul dintre acetia ar fi suprat, robotul de divertisment (pet robot) intr n
aciune, ndeplinind anumite planuri preluate din baza sa de cunotine i ducndu-
4.2
le la finalitate, pn cnd se atinge unul din obiectivele fixate i anume ca starea de

spirit a copilului suprat s se schimbe ntr-una mai vesel.
Patrularea prin diferite ncperi ale casei Acest scenariu este menit s ajute la
supravegherea casei inteligente, s detecteze sosirea sau plecarea unui membru de
acas, s detecteze eventuali intrui. Robotul (supervisor robot) menit s
nfptuiasc acest scenariu supravegheaz buna funcionare a celorlali roboi i
detecteaz schimbri de mediu pentru a putea alerta sistemul sau ceilali roboi de
noile planuri i obiective care trebuie ndeplinite.
Arhitectura sistemului
Cum a fost detaliat n capitolele anterioare, dezvoltarea sistemelor multi-agent

omniprezente trebuie sa ia n considerare o serie de factori:
Omniprezena dispozitivelor folosite;
Interoperabilitate;
Comportament proactiv;
Scalabilitate;
Acuratee;
Mobilitate;
Securitate.
Pentru flexibilitate i scalabilitate arhitectura aleas este o arhitectur orientat pe
ageni, distribuit i ierarhic. Este alctuit din 5 componente legate ntre ele, precum n
Figura 4 .20 Diagrama arhitectural a sistemului.
4.2.1
Nivelul Senzorial
Acest nivel controleaz traficul de informaii captate de la senzori i le transmite la

sistem prin platforma unde urmeaz s fie prelucrate. Agenii logici software de la acest nivel
transform informaiile preluate de la nivelul fizic, transformndu-le n informaii inteligibile
pentru calculator.
Agenii senzor de la acest nivel achiziioneaz datele specifice i controleaz
acurateea lor fiind capabili s detecteze funcionarea maliioas a senzorilor sau alte tipuri de
erori.
Pentru fiecare tip de senzor din sistem este responsabil un agent logic, care
monitorizeaz schimbrile de context i eventualele erori aprute.
Un agent supervizor supravegheaz ciclul de via a agenilor logici senzoriali i este
responsabil de pornirea acestora i de controlarea lor.
4.2.2
Nivelul Dispozitivelor
Nivelul dispozitivelor are un scop asemntor cu nivelul senzorilor, cu deosebirea c

agenii specifici acestui nivel manipuleaz datele venite de la nivelul fizic legate de celelalte
dispozitive senzitive la context acestea fiind achiziionate la acest nivel nainte de a fi trimise
la sistem.
Un agent este responsabil pentru fiecare dispozitiv omniprezent, astfel toate datele
preluate de la unul dintre aceste dispozitive fiind procesate la acest nivel i trimise mai
departe la sistem
De asemenea un agent supervizor este responsabil de ciclul de via al agenilor pentru

dispozitive i este responsabil de pornirea i oprirea acestora.
Figura 4.20 Diagrama arhitectural a sistemului
4.2.3
Nivelul Roboilor
n acest nivel se mapeaz la nivel de ageni roboii din sistem prelund informaiile de
la nivelul fizic legate de roboi i introducndu-le n sistem. Cei trei roboi monitorizai prin
ageni logici sunt:
Pet Robot robotul preocupat de divertismentul din cas;
Mission Robot mutarea diferitelor obiecte din cas;
Supervisor Robot care monitorizeaz activitatea roboilor precum i alte
schimbri legate de locuitorii casei.
Agentul logic Robot Manager este responsabil de controlarea agenilor logici pentru
roboi, fiind senzitiv la modificrile aprute n activitatea roboilor activi din cas.
4.2.4
Nivelul Decizional
La acest nivel, prin introducerea regulilor de inferen, informaiile despre context de

nivel nalt sunt deduse din informaiile de context preluate de la diferitele dispozitive
ubiquitous. Tot acest nivel este responsabil de crearea, meninerea i actualizarea bazei de
cunotine.
Astfel baza de cunotine furnizeaz informaii actualizate salvate ca urmare a unor
diferite aciuni din sistem i salveaz informaiile contextuale specifice fiecrei entiti din
sistem. Agentul logic responsabil pentru baza de cunotine are responsabilitatea de a raiona
n privina contextelor existente. Rezultatele raionamentelor fcute de acest agent sunt

comunicate celorlali ageni prin platform, acestea fiind concretizate prin aciuni.
Tot acest nivel are i funcia de nvare, nvnd preferinele actorilor umani ai casei
inteligente.
4.2.5
Nivelul de control i monitorizare
Acest nivel concretizeaz interaciunea dintre roboi i oameni, precum i dintre

oameni i sistem, furniznd capaciti de nivel nalt pentru interaciunea dintre entitile din
casa inteligent.
Dintre facilitile oferite de acest nivel enumerm: nregistrarea a noi entiti fizice n
sistem, precum un dispozitiv utilizator, nregistrarea unor noi aciuni sau misiuni,
reprezentarea grafic a mediului casei pentru utilizator.
4.2.6
Nivelul fizic
Acest nivel reprezint senzorii la nivel fizic, diferite obiecte, dispozitive, actuatori care
furnizeaz informaii de cele mai multe ori eronate sau inconsistente despre sistem. Fiecare
informaie provenit de la o categorie de dispozitive fizice este controlat i prelucrat de un
anumit nivel din arhitectura curent, nainte de a fi trimis la nivelul de achiziionare de
context din sistem.
PROIECTARE DE DETALIU
n acest capitol se detaliaz procedura de proiectare a sistemului Smart House. Aici se

va explicita proiectarea sistemului ncepnd de la nivelul inferior pn la proiectarea
sistemului n ansamblu. De asemenea se vor prezenta detaliile de arhitectur, diagramele de
clase, cazurile de utilizare precum i detaliile de implementare i dificultile ntmpinate n
decursul dezvoltrii sistemului.
5.1
Analiza cerinelor
n aceast faz se organizeaz actorii i obiectivele majore, se definesc participanii la

sistemul curent, precum i legturile ntre acetia. Aceast faz de analiz se completeaz
rspunznd la cteva ntrebri i modelarea rspunsului la acestea n mod vizual n diagrama
de interaciune a sistemului (Figura 5.1).
Cine sunt actorii principali ai sistemului?
Etapa de identificare a participanilor la sistemul casei inteligente a demonstrat c
actorii principali care interacioneaz cu sistemul sunt membrii familiei care au autoritate
asupra sistemului, putnd face modificri i lua decizii, precum i ali membri care nu aparin
familiei i care pot fi tratai ca invitai sau intrui. Oaspeii au privilegii limitate, n timp ce
intruii nu au privilegii n sistem.
Care sunt obiectivele lor?
Membrii familiei au urmtoarele obiective n sistemul casei inteligente:
A. Managementul Misiunilor membrii familiei vor putea planifica sau anula
anumite misiuni;
B. Controlul Casei inteligente reprezint abilitatea unui actor de a controla
aparatele, senzorii, actuatorii sau roboii casei inteligente;
C. Vizualizarea hrii casei inteligente reprezint abilitatea de a vizualiza mediul
inteligent al casei incluznd poziia oamenilor, roboilor, statusul
dispozitivelor, al senzorilor i informaii deduse despre context, precum starea
emoional dedus.
Cum pot acetia s le ndeplineasc, depinznd sau nu de ceilali actori ai
sistemului?
Pentru a ndeplini starea de fapt dorit de membrii familiei, se pot asigna
responsabilitile i obiectivele agentului de interaciune cu sistemul casei inteligente. Acesta
ndeplinete rolul de agent de proximitate, fiind cel care interacioneaz cu sistemul cernd o
planificare a noilor obiective cerute de ctre membrul familiei.
Urmtorul pas n aceast faz este analiza fiecrui obiectiv i descompunerea lui n
sub-obiective cu ct mai atomice posibil, privind din perspectiva unui singur actor, i artnd
mijloacele de a le ndeplini, adic alte obiective care ar putea preveni sau ar putea contribui la
atingerea obiectivului curent.
Dup ce s-a rspuns la aceste ntrebri, urmtorul pas este identificarea actorilor
secundari care contribuie la sistemul Smart House. Actorii secundari ai sistemului sunt
sistemul casei inteligente cu cele dou ramificaii: sistemul de control i sistemul de
monitorizare.
Sistemul de control se bazeaz pe agenii de management ai senzorilor, dispozitivelor,
roboilor i actuatorilor pentru execuia de planuri n vederea atingerii obiectivelor.
Sistemul de monitorizare construiete harta mediului casei inteligente furniznd
informaii personalizate actorilor familiei prin mijlocirea oferit de agentul de interaciune.
Proiectare de detaliu
Harta mediului este procesat de ctre sistemul de control care include mecanisme decizionale
pentru a se adapta n mod dinamic la noile informaii contextuale preluate.
Figura 5.21 Diagrama de interaciune ntre actorii i sistemul casei inteligente
5.2
Proiectarea arhitecturii
Proiectarea i implementarea arhitecturii sistemului multi-agent prezentat n capitolul

anterior va fi detaliat n aceast seciune. Agenii implicai la nivelul fiecrui modul sunt
responsabili pentru a atinge anumite obiective, pentru aceasta ei efectund anumite planuri
care sunt cerute de ctre sistemul de roboi. Anumii ageni suplimentari sunt introdui pentru
a contribui la ndeplinirea unor cerine funcionale sau non-funcionale.
Mijloacele prin care se pot atinge obiectivele, i anume planurile i presupunerile
iniiale, pot fi descompuse pn la activiti unitare. Proiectarea arhitectural cuprinde
urmtoarele faze:
Descompunerea i detalierea diagramei arhitecturale general aceast faz
implic apariia a noi actori i noi sub-obiective i planuri care au ca scop
ndeplinirea cerinelor funcionale ale sistemului;
Includerea de noi actori specifici stilului arhitectural;
Includerea de noi actori care s contribuie proactiv la ndeplinirea cerinelor nonfuncionale;
Identificarea capacitilor.
5.2.1
Sistemul de roboi
Sistemul SmartHouse dezvoltat fiind echipat cu 3 roboi, un subsistem multi-agent a

fost proiectat pentru a se ocupa cu aciunile specifice roboilor. Roboii trebuie s poat s
nfptuiasc misiuni de manipulare a obiectelor, dar au i capaciti de raionare pentru a
putea opera n mod autonom, expunnd astfel un comportament senzitiv la context.
Agentul manager al roboilor are rolul de a iniia misiunea celor trei ageni roboi.
Fiecare dintre aceti trei ageni are responsabiliti bine definite, i poate s execute misiuni
planificate sau chiar i neplanificate, n funcie de contextul curent. Diagrama de obiective

majore pentru sub-sistemul de roboi poate fi vzut n Figura 5 .22. Fiecare dintre cei trei
roboi are planuri i obiective diferite. n continuare vom detalia arhitectura agenilor roboi.
Figura 5.22 Diagrama de obiective a sub-sistemului de roboi
5.2.1.1
Agentul Robot Manager

Misiunea acestui agent este crearea sistemului de ageni roboi al sistemului multiagent al casei. Atunci cnd pornete sistemul Smart House ndeplinete urmtoarele aciuni:
nregistrare agent la platforma de ageni Acest lucru se face printr-un sistem
request-response prin care se cere platformei autorizarea pornirii agentului
manager.
Cutare ageni roboi n baza de cunotine Dup ce nregistrarea acestui agent
s-a nfptuit cu succes el este responsabil cu cutarea n baza de cunotine a
agenilor de tip robot pe care trebuie s ii porneasc.
Pornire ageni roboi Dup ce au fost gsite toate posibilele instane de ageni,
managerul de roboi caut misiunile fiecruia dintre roboi i pornete fiecare tip
de agent robot cu misiunea asignat.
Supraveghere funcionare ageni roboi Dup procesul de pornire a acestor
ageni, dac procesul a fost terminat cu succes, se supravegheaz din punct de
vedere funcional software buna funcionare a agenilor de tip robot.
Oprire ageni roboi Dac se declaneaz procesul de oprire a sistemului multiagent, acest agent este alertat cu acest lucru i oprete toi agenii logici aflai n
subordinea sa.
Agentul manager de roboi are asignate urmtoarele ipoteze, planuri i obiective:

Ipoteze (beliefs)
o Tipul roboilor aceasta ipotez este necesar pentru a ti ce tip de
cunotine s caute n baza de cunotine;
o Creare robot nou aceast ipotez specific tipul de obiect cu care va fi
instaniat robotul;
o Distrugere roboi aceast ipotez permite agentului manager distrugerea
celorlali ageni folosind agentul AMS.
Planuri (plans)
o Plan de gsire a agenilor roboi Acest plan se concretizeaz printr-o
operaie de extragere a tipurilor de roboi din baza de cunotine folosind
un mecanism de tip request-response ntre acest agent i agentul
responsabil cu baza de cunotine;
o Plan de distrugere a agenilor roboi Acest plan se concretizeaz prin
distrugerea agenilor roboi creai.
Obiective (goals)
o Creare agent Acest obiectiv este o referin spre unul din obiectivele
agentului master al platformei numit AMS (Agent Management Service);
o nregistrare agent Acest obiectiv este o referin spre unul din obiectivele
agentului de tip DF al platformei de ageni.
Dup cum s-a vzut mai sus acest agent manager de roboi joac un rol esenial n
crearea sub-sistemului multi-agent pentru roboii casei. El nu este implicat direct n vreuna
din misiunile de baz ale sistemului multi-agent al casei, dar se comport ca un agent master
care comunic cu sistemul de control al casei, fiind responsabil pentru managementul
celorlali ageni robotici ai casei.
5.2.1.2
Agentul Robot Supraveghetor

Agentul robot supraveghetor este agentul care mapeaz la nivel software aciunile pe
care robotul supervizor trebuie s le ndeplineasc, el avnd misiunea de a supraveghea
aciunile celorlali roboi care particip activ la misiunea casei, efectund aciuni n scopul de
sporire a confortului locatarilor.
Aciunile acestui agent robot sunt:
Cutare ageni roboi n baza de cunotine Aceast operaiune se execut odat
cu crearea acestuia de ctre agentul manager, el cutnd instanele de roboi pe
care va trebui s i supravegheze, cutnd toate detaliile (ipoteze, planuri,
obiective) despre ei i monitoriznd buna funcionare a acestora;
Procesarea schimbrilor de context Schimbarea sau adugarea de noi cunotine
care au impact direct asupra sub-sistemului de roboi vor fi sesizate i procesate de
ctre acest agent;
nregistrarea aciunilor efectuate de robotul misiune i robotul divertisment
Planurile i obiectivele care trebuie atinse de ctre roboii supervizai sunt sesizate
de ctre acest robot;
Planificarea de noi aciuni n cazul unor schimbri de cerine sau alte schimbri
de context, robotul supervizor va putea planifica noi aciuni pe care roboii
supervizai s le ndeplineasc;
nregistrarea de noi ipoteze n cazul n care n baza de ipoteze a subsistemului de
roboi apar ipoteze acestea vor fi sesizate de ctre agent i vor fi procesate;
Stabilirea de noi obiective Obiectivele noi vor fi planificate de ctre acest agent
pentru a fi atinse.
Acest agent are asignate urmtoarele ipoteze, planuri i obiective:
Ipoteze (beliefs)
o Locaie locaia iniial n care se afl robotul;
o Tipul robotului tipul robotului;
o nceput misiune timpul n care pornete misiunea;
o Sfrit misiune timpul n care se sfrete misiunea;
o Mediul curent al casei inteligente aceast ipotez se mapeaz printr-un
obiect de tip singleton care conine toate cunotinele despre cas;
o Mediul vizual curent al casei inteligente aceast ipotez creeaz mediul
casei inteligente n mod vizual.
Planuri (plans)
o Supravegheaz inte supravegheaz roboii int;
o Patrulare Patruleaz ncperile casei.
Obiective (goals)
o nregistrare DF nregistrare robot la registrul de tip pagini aurii;
o Deregistrare DF denregistrare robot de la serviciul de tip pagini aurii;
o Red cunotinele despre cas roboilor care ndeplinesc aciuni Aceast
funcie red toate cunotinele despre mediu existente n baza de cunotine
tuturor actorilor de tip robot.
5.2.1.3
Agentul Robot Misiune

Agentul Robot pentru misiuni este un robot specializat care are ca scop executarea
diferitelor munci prin casa inteligent. Capacitile de comunicare a acestui robot cu ceilali
ageni roboi i cu mediul Smart House sunt:
Cerere de vizualizare a mediului i nregistrare a acestuia Robotul de tip
misiune cere robotului supervizor informaii despre casa inteligent, coordonate de
micare, harta casei, i alte informaii;
Descoperire obiecte utile n cazul n care robotul are nevoie de anumite obiecte
pentru a duce la capt o misiune (o cutie, un loc de depozitare), n cazul n care
acesta trece pe lng vreunul dintre aceste obiecte, le identific i le adaug n baza
proprie de cunotine;
Cerere de actualizare a mediului casei inteligente n cazul n care se produce o
schimbare n mediul robotul de tip misiune, cere robotului supervizor rencrcarea
viziunii asupra lumii i implicit a mediului casei inteligente.
Obiectivele majore ale acestui agent robot sunt proiectate astfel nct robotul misiune
s poat ndeplini obiectivele majore prezentate n Figura 5.3. Astfel obiectivele majore ale
acestui robot de tip misiune sunt:
Menine acumulatorul ncrcat Dac nivelul acumulatorului scade sub un anumit
nivel, celelalte obiective devin ignorate pentru moment, singurul obiectiv al
robotului de tip misiune rmnnd obiectivul de a menine acumulatorul peste
nivelul de urgen. Astfel se spune c acest tip de obiectiv este inhibant. Este
obiectivul de tip obiectiv de meninut setat pentru robotul misiune;
Menine camera copiilor curat Dac n camera copiilor se afl o cutie cu
jucrii, mut aceast cutie n locul de depozitare cunoscut. Acest obiect este
blocant fa de celelalte obiective, n cazul n care robotul identific o cutie care
trebuie transportat acesta i seteaz ca obiectiv mutarea acelei cutii, n pasul
urmtor, indiferent dac robotul se afl ntr-o alt misiune de depozitare a vreunei
cutii. Acest obiectiv are asignat un plan de cutare a cutiilor, nregistrnd n baza
proprie de cunotine noile cutii aprute n mediul casei inteligente;
Figura 5.23 Obiectivele robotului transportor n casa inteligent
Patruleaz casa pentru atingerea obiectivelor Se seteaz anumite puncte de

patrulare ale robotului care sunt urmrite n modul normal cnd robotul nu se afl
n misiune de rencrcare sau n alt tip de misiune. n mod normal dac apare o
schimbare de context, robotul iese din modul de patrulare, ndeplinind obiectivele
prioritare.
Ipotezele, obiectivele i planurile acestui tip de robot sunt:
Ipoteze (beliefs)
o Mediul curent Robotul transportor are referin spre mediul curent;
o Cutiile reperate n cazul n care robotul transportor a reperat o cutie el
adaug acest reper n baza de ipoteze;
o Locurile de depozitare reperate Dac robotul a trecut prin raza locului de
depozitare acesta adaug acel loc de depozitare ca un fapt cunoscut n baza
lui de ipoteze;
o Puncte de ncrcare Robotul repereaz cu ajutorul senzorilor de locaie
punctele de ncrcare a acumulatorilor;
o Locaia Locaia curent a robotului. Aceast ipotez se actualizeaz cu
fiecare micare a robotului;
o Raza vizual Aceast ipotez reprezint un factor care determin aria
vizual a robotului. Toate obiectele de interes care se vor afla n interiorul
acestei arii vizuale vor fi reperate i salvate ca ipoteze;
o Nivelul acumulatorului Aceast ipotez reprezint procentul de ncrcare
a acumulatorului robotului actualizat odat cu micarea robotului sau
ncrcarea lui;
o Punctele de patrulare Aceste constante reprezint coordonatele de

micare ale robotului. Robotul se va mica ntre aceste puncte dac nu are
un alt obiectiv mai prioritar de ndeplinit;
o Mediul curent n mod vizual Aceast ipotez se concretizeaz prin
instanierea unei ferestre de vizualizare a aciunilor robotului transportor.
Planuri (plans)
o Planul de patrulare prin cas Patrularea prin cas se concretizeaz prin
executarea unui plan n care robotul itereaz n mod ciclic nite sub-planuri
prin care robotul se mic de la locaia sa curent la locaia urmtoare
specificat;
o Planul de ridicare a unei cutii Acest plan se concretizeaz prin cererea
ctre robotul supervizor de actualizare a mediului i crearea unei noi
ipoteze a robotului. Obiectivul final care trebuie ndeplinit ca urmare a
executrii planului este obiectivul de ridicare a cutiei;
o Planul de depozitare a unei cutii Acest plan se execut avnd ca obiectiv
final depozitarea cutiei n garaj, fiind actualizate ipotezele legate de cutiile
transportate de robot, ct i ipotezele legate de mediu;
o Planul de micare ntr-o alt locaie Acest plan este folosit ca sub-plan n
cazul patrulrii i se concretizeaz prin actualizarea ipotezelor legate de
locaie, precum i actualizarea mediului casei inteligente;
o Planul de ncrcare a acumulatorului Acest plan se concretizeaz prin
stabilirea sub-obiectivului de micare a robotului spre locaia locului de
ncrcare i ncrcarea acumulatorului pn la nivelul stabilit. Acest plan se
execut cu scopul de a ndeplini obiectivul de ncrcare a bateriei.
Obiective (goals) Obiectivele n mediul de dezvoltare a agenilor se despart n
trei tipuri: obiective de meninut (maintain goals), obiective de atins (achieve
goals), obiective de efectuat (perform goals) i obiective de tip interogare
(query goals).
o Obiective de meninut
Menine bateria ncrcat Acest obiectiv este obiectivul de
cea mai nalt prioritate n sistem, toate celelalte execuii de planuri
pentru a ndeplini obiective fiind oprite pentru a se executa planul
de mutare a robotului transportor nspre acumulator. Nivelul de
energie care trebuie meninut este un nivel mai mare de 20% din
valoarea total a acumulatorului. Nivelul optim de energie este
100%, astfel la fiecare ncrcare robotul ateapt pentru a se atinge
acest nivel.
o Obiective de atins
Obiectivul de a cura camera copiilor Este obiectivul esenial
pentru robotul de tip transportor, pentru executarea sa fiind create
planurile descrise mai sus. Sub-obiectivele fixate, care trebuie
ndeplinite pentru a putea atinge acest obiectiv major, sunt
obiectivul de a ridica o cutie, obiectivul de a depozita o cutie i
obiectivul de micare;
Obiectivul de a ridica o cutie Obiectivul se atinge prin efectuarea
cu succes a planului desemnat pentru acest lucru;
Obiectivul de a depozita o cutie Obiectivul se atinge prin
executarea planului de depozitare a cutiei;
Obiectivul de a se mica ntr-o anumit locaie Obiectivul este

concretizat prin efectuarea planului de schimbare a locaiei
robotului.
o Obiective de efectuat
Patrulare Acesta este un obiectiv de prioritate joas care se
execut atunci cnd nici un alt obiectiv mai prioritar nu trebuie
ndeplinit;
Efectueaz cutarea cutiilor n micarea sa prin camera copiilor
robotul identific cutiile care trebuie depozitate.
o Obiective de tip interogare
Caut staii de ncrcare Acest obiectiv este un obiectiv de tip
interogare, deoarece robotul cere informaii despre mediu legate de
staiile de ncrcare;
Caut locuri de depozitare Robotul cere informaii despre mediu
prin robotul supervizor, legate de locurile de depozitare din cas.
5.2.1.4
Agentul Robot Divertisment

Agentul robot divertisment este un agent mai complex ,care trebuie s detecteze starea
de spirit a copiilor, iar n cazul n care se consider c trebuie s schimbe starea de spirit a
acestora s o fac. Locul acestuia este tot n camera copiilor. Obiectivul su este ndeplinirea
aciunii de nveselire a copiilor. Pentru aceasta robotul de divertisment va executa diferite
planuri n funcie de ipotezele formate i de cerinele venite de la robotul supervizor.
5.2.2
Sistemul de senzori
Sub-sistemul de senzori conine ageni logici care furnizeaz funcii de achiziie de

context. n mod mai specific, ei adun informaii despre context de nivel inferior, de la
anumii senzori. Agentul senzor de lumin, agentul senzor de temperatur, agentul senzor de
umiditate, precum i agentul senzor de zgomot proceseaz informaiile venite de la senzori,
care de cele mai multe ori sunt eronate, conin zgomote. Se folosesc diferite metode specifice
pentru a le interpreta i se comunic rezultatele agentului de monitorizare a sistemului.
Agentul manager de senzori are rolul de a detecta i monitoriza agenii de tip senzor,
detectnd eventualele erori sau funcionaliti anormale.
Managerul de senzori are obligaia de notifica sistemul de monitorizare a casei prin
agentul de monitorizare dac un comportament anormal a fost detectat i totodat sistemul de
control al casei, care ia msurile specifice n vederea tratrii acestui caz. O vedere detaliat
despre relaia dintre componentele sub-sistemului de senzori este detaliat n Figura 5 .24.
Totodat, sistemul de monitorizare trebuie s fie capabil s dicteze aciuni sistemului
de senzori, prin agentul manager, aciuni legate de funcionarea acestora precum i de
parametrii de funcionare.
Figura 5.24 Sistemul de senzori al casei inteligente
5.2.3
Sistemul de dispozitive
Sub-sistemul de dispozitive monitorizeaz informaiile contextuale furnizate de

echipamentele interioare ale casei (frigider, televizor .a.m.d.), supraveghind care dintre
dispozitive sunt n folosin i care este starea lor de funcionare. Pentru fiecare dispozitiv un
agent specific este delegat pentru a interpreta semnalele venite de la dispozitive i pentru a
executa operaii precum pornirea sau oprirea dispozitivului. Diagrama de activitate n subsistemul multi-agent pentru dispozitive poate fi vizualizat n Figura 5.5.
Figura 5.25 Sistemul de dispozitive al casei inteligente
5.2.4
Sistemul de control
Sistemul de control este responsabil de execuia de planuri decizionale bazate pe

reguli. Acest sistem este sistemul de raionare a casei inteligente. Din baza de cunotine n
care se adun cunotine de nivel inferior despre casa inteligent prin mecanismele de
raionare se deduc cunotine de nivel nalt. Obiectivele majore ale acestui sistem sunt precum
cele prezentate n Figura 5.6.
Figura 5.26 Obiectivele sistemului de control al casei inteligente
5.2.5
Sistemul de monitorizare
Sistemul de monitorizare al casei inteligente folosete informaiile relevante precum

locaia persoanelor sau a roboilor, identificarea actorilor sau statutul dispozitivelor sau a
senzorilor. Agentul responsabil pentru monitorizarea casei, folosete aceste informaii de nivel
inferior pentru a le trimite mai departe la sistemul de control al casei, care deduce contexte de
nivel superior din aceste informaii primite, integrnd aceste informaii n sistemul de
informaii al casei.
Sistemul cuprinde cteva interfee utilizator menite s furnizeze o reprezentare vizual
a informaiilor contextuale furnizate de senzori, dispozitive sau obiecte i de asemenea
interactivitate vizual pentru sistemul luat ca un ntreg, prin crearea de noi planuri sau misiuni
sau prin eliberarea comenzilor specifice pentru obiectele interioare.
Interfeele utilizator sunt proiectate ca fiind ipoteze pentru anumii ageni Jadex,
acestea instaniindu-se odat cu nregistrarea cu succes a agentului la platforma de ageni.
Aceste interfee extrag informaii contextuale din sistem folosind agenii specifici pentru
fiecare domeniu specific. Urmtoarele funcionaliti sunt furnizate de sistemul de
monitorizare al casei:
Reprezentare vizual a locuitorilor, roboilor, obiectelor sau dispozitivelor;
Reprezentare vizual a camerelor din cas;
Reprezentare vizual a informaiilor contextuale deduse, precum activitatea

curent sau starea emoional;
Monitorizarea statutului senzorilor i dispozitivelor interioare (ui, geamuri,
senzori, dispozitive electronice .a.m.d.);
Monitorizarea strii emoionale a locuitorilor casei;
Trimiterea de rspunsuri ctre sistem specificnd starea emoional a locuitorilor
casei;
Managementul misiunilor.
Ecranele interfeelor utilizator vor putea fi vizualizate n seciunea de anexe a
documentului.
5.2.6
Proiectarea bazei de cunotine
Pentru a suporta mecanismele decizionale i de raionare pentru agentul aflat la nivelul

de raionamente i decizii ale arhitecturii curente, sistemul se ramific i trebuie s integreze
dou sub-sisteme: un mediu persistent pentru reguli i pentru o istorie a informaiilor
contextuale, precum i un sistem decizional.
Sistemul de reguli este un motor de inferen care permite integrarea mai multor tipuri
de motoare de raionare i inferen, dar aplicabil pentru sistemul curent fiind doar sistemul
pentru RDFS i OWL. Sistemul aplic regulile salvate n baza de reguli i monitorizeaz
fiecare schimbare care are loc la nivelul datelor reprezentate prin ontologii. Acest modul
suport inferena a noi reguli i apoi regulile deduse sunt actualizate la nivelul modelului
ontologic.
Ontologiile salveaz conceptele reprezentate sub form de perechi entitate-relaie.
Deoarece modelul ontologic este actualizat cu noi informaii sau cu noi valori pentru
informaiile deja existente, vechile valori sunt nregistrate n mediul persistent al sistemului,
n asociere cu secvena de timp asociat.
Sistemul expert folosit, preluat dintr-un model, are i capacitatea s nvee care ar fi
cel mai bun rspuns pe care utilizatorul l ateapt de la sistem. Sistemul expert este construit
cu ajutorul reelelor neuronale, care vor fi antrenate cu ajutorul unor exemple i vor fi apoi
adaptate bazat pe rspunsul utilizatorului, msurnd nivelul de satisfacie n cazul ndeplinirii
unor anumite aciuni. Totui aceast caracteristic este la nivel cercetare i nu intr n scopul
acestei lucrri.
5.3
5.3.1
Detalii de implementare
Caracteristici generale legate de implementarea sistemului
Sistemul a fost implementat folosind limbajul Java i mediul de dezvoltare Eclipse

pentru crearea proiectului.
S-a folosit mediul de dezvoltare a agenilor Jadex care se poate instala ca o extensie
Eclipse. Dup instalarea mediului n Eclipse va aprea n interfa un buton nou cu ajutorul
cruia se va putea porni platforma de ageni.
Regulile de dezvoltare a agenilor Jadex specific faptul c descrierea agenilor cu
toate caracteristicile lor s se fac folosind fiiere de descriere XML. Descrierea unui agent
BDI prin fiiere de descriere care s poat fi executat n Jadex va fi detaliat n seciunea
urmtoare.
Planurile specifice care ajut la ndeplinirea obiectivelor stabilite pentru ageni n

particular i pentru sistemul Smart House n general sunt descrise n limbajul Java, n toate
planurile extinznd clasa abstract Plan i implementnd metoda body().
Pentru crearea ontologiilor s-a folosit limbajul OWL specificat sub form de schem
RDF, iar editarea acestora s-a fcut folosind mediul de dezvoltare Protg.
Pentru crearea claselor ontologice n reprezentarea Java s-a folosit o extensie Jadex a
mediului Protg numit Jadex Beanynizer care convertete clasele ontologice n clase
Nuggets, toate clasele implementnd interfaa INuggets.
Nuggets XML este o tehnologie proprietar Jadex referitoare la serializarea i
deserializarea ntre obiecte Java i formatul XML. Are la baz tehnologia de transformare din
clase n fiiere XML i invers JibX, i are un modul de encodare, numit bean-encoder
disponibil n pachetul JDK care transform clasele Java specificate dup standardul Java
Beans n XML standard. Aceste XML-uri sunt trimise apoi agentului destinatar din platform
care le deserializeaz napoi n obiecte i trimite napoi un rspuns.
Folosirea uneltei Beanynizer faciliteaz crearea de clase Java dup standardul Nuggets
fiind uor de folosit i crend clase de date, nemodificabile, apoi clasele propriu-zise
echivalente cu clasele ontologice, care pot fi modificate pentru a aduga noi atribute utile.
Crearea mediului vizual s-a fcut folosind unealta JformDesigner, care faciliteaz
crearea interfeelor utilizator, programatorul mai trebuind doar s adauge funcionalitile
aferente fiecrui tip de obiect. Pentru crearea mediului vizual s-a folosit tehnologia Java
Swing.
5.3.1.1
Pachetele aplicaiei
Toate pachetele aplicaiei conin prefixul smarthouse urmtorul nume relevant fiind
modulul arhitectural din care acestea fac parte. Astfel pachetul smarthouse.robots definete
toate definiiile legate de roboii din sistemul casei inteligente. Celelalte pachete tind s
respecte modelul arhitectural specificat prin componente, astfel alte pachete relevante sunt
smarthouse.sensors, smarthouse.devices, smarthouse.ontology, smarthouse.knowledge.base.
Ontologiile i clasele Nuggets generate sunt specificate n pachetul smarthouse.ontology iar
partea vizual i de monitorizare a aplicaiei n pachetul smarthouse.monitoring.
5.3.2
Implementarea agenilor
Pentru a crea aplicaii cu Jadex dezvoltatorul trebuie s creeze dou tipuri de fiiere:
Fiiere de definire a agenilor(Agent Definition Files, prescurtat ADF);
Clase Java prin care se implementeaz planurile.
5.3.2.1
Implementarea fiierelor de descriere a agenilor

Fiierele ADF de descriere a agenilor pot fi privite ca o specificare a tipului unei clase
de ageni care vor fi instaniai. La momentul pornirii unui agent, n primul rnd se ncarc
fiierul ADF i apoi se iniializeaz ipotezele, planurile i obiectivele aa cum au fost ele
specificate.
Antetul unui ADF este obligatoriu i are o structur bine stabilit care trebuie
respectat. Un exemplu de astfel de fiier definit n proiectul curent poate fi vzut n Figura
5 .27.
<agent xmlns="http://jadex.sourceforge.net/jadex"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jadex.sourceforge.net/jadex
http://jadex.sourceforge.net/jadex-0.96.xsd"
name="MissionRobot"
package="smarthouse.robots.world.mission">
Figura 5.27 Antetul fiierului de descriere a agenilor ADF
n primul rnd tag-ul agent specific faptul c documentul XML respect definiia
de schem jadex-0.96.xsd care permite verificarea faptului c documentul este un fiier valid
ADF, nu doar un XML corect formulat. Numele tipului agentului este specificat prin atributul
name i trebuie s fie acelai cu numele dat n definirea numelui fiierului, dar nlturnd
sufixul .agent.xml. Este de asemenea folosit ca un nume din oficiu pentru noi instane ale
aceluiai agent cnd ADF este ncrcat din aplicaia grafic Jadex. Definiia pachetului
specific locul n care agentul trebuie s caute prima dat clasele necesare pentru planuri i
ipoteze, i trebuie s corespund cu locul n care fiierul XML este locat. n plus, pachete
adiionale pot fi specificate folosind directiva imports.
Motorul Jadex necesit anumite proprieti pentru iniializare, care sunt n mod
implicit preluate din directorul jadex/config/runtime.properties.xml. n mod normal acest
lucru nu este de interes pentru dezvoltatorii de ageni, dar uneori, precum este i cazul de fa,
a fost necesar o schimbare a comportamentului motorului Jadex.
n Figura 5 .28 se prezint schema de definire a unui agent Jadex folosind fiierul
ADF, toate acestea fiind elementele care pot fi specificate n interiorul fiierului ADF.
Eticheta <imports> este folosit pentru a specifica ce clase i pachete pot fi folosite de
expresiile din fiierul ADF. Pentru a modulariza funcionalitatea agentului, agenii pot fi
descompui dup capaciti. Capacitile folosite de un agent sunt refereniate cu ajutorul tagului <capabilities>. Partea esenial a specificrii unui agent se refer la definirea ipotezelor,
obiectivelor i planurilor agentului, care sunt plasate n tag-urile <beliefs>, <goals>, respectiv
<plans>.
Figura 5.28 Schema de definire a unui agent Jadex
Evenimentele cunoscute de ctre agent sunt definite n seciunea <events>. Seciunea

<expressions> permite specificarea expresiilor i condiiilor care pot fi folosite ca interogri
predefinite pentru planuri. Seciunea <properties> este folosit pentru a crea setri legate de
pild, de logarea aplicaiei sau de depanarea ei. n sfrit n seciunea de <configurations>
configuraii predefinite care conin ipotezele, obiectivele i planurile iniiale sau obiectivele i
planurile finale sunt specificate.
Este de notat faptul c ordinea apariiilor seciunilor mai sus este fix, fiind exact aa
cum a fost specificat n schema XML. De asemenea se pot omite acele elemente care nu sunt
necesare n definirea agenilor cureni.
Cnd fiierul ADF este ncrcat, obiecte Java sunt create pentru elementele din
XML(ex. ipoteze, obiective, planuri). Interfeele care specific modelul acestor elemente sunt
specificate n pachetul jadex.model. Exemple de astfel de interfee sunt IMBelief, IMGoal,
IMPlan. n cele mai multe cazuri, nu trebuie accesate aceste interfee. Cnd un agent este
executat, instane ale modelelor predefinite pentru elementele sale sunt create sub form de
elemente runtime. Acest lucru asigur ca n momentul rulrii mai multe instane ale aceluiai
model s poat fi create n mod simultan.
5.3.2.2
Implementarea planurilor
Planurile reprezint mijloacele prin care agenii acioneaz n mediu. Astfel planurile
compun librria de aciuni specifice agentului care le descrie. Depinznd de situaia curent
planurile sunt selectate ca un rspuns la evenimentele sau obiectivele curente. Selecia
planului care se execut se face n mod automat de ctre sistem i reprezint unul din
aspectele eseniale ale infrastructurii BDI. n Jadex planurile sunt mprite n dou
componente: antetul planului definit n ADF i etalarea circumstanelor n care un plan
propriu-zis va fi instaniat i executat.
Implementarea antetului planurilor n fiierul ADF
n ADF poate fi definit un numr arbitrar de planuri n funcie de specificaiile

agentului. Pentru fiecare antet cteva atribute sunt necesare pentru definirea valid a planului.
Pentru fiecare plan, trebuie definit atributul prin care se specific numele planului. De
asemenea pentru fiecare plan, trebuie definit corpul propriu zis al planului prin clasa Java
ataat. Un exemplu de definire a planului poate fi vizualizat n Figura 5.9. Tipul planului
definete ce fel de plan a fost specificat. Acesta poate fi plan standard sau plan mobil.
Directiva <trigger> specific condiiile n care planul se va instania i executa.
Directiva <parameter> specific parametrii de intrare pentru planul curent, dac este nevoie
de acetia. Directiva <contextcondition> reprezint condiii care trebuie validate pe tot
parcursul executrii planului, n caz contrar planul anulndu-se.
<plan name="moveto">
<parameter name="location" class="Location">
<goalmapping ref="achievemoveto.location"/>
</parameter>
<body class="MoveToLocationPlan"/>
<trigger>
<goal ref="achievemoveto"/>
</trigger>
<contextcondition>$beliefbase.my_chargestate >
0</contextcondition>
</plan>
Figura 5.29 Definirea planului de micare pentru robotul transportor
Implementarea planului propriu-zis n Java
Planul propriu-zis reprezint o parte din funcionalitatea agentului i ncapsuleaz o

suit de aciuni. n Jadex planurile sunt scrise n limbajul Java, astfel e foarte uoar scrierea
planurilor avnd la dispoziie oricare dintre librriile Java existente i de a specifica planurile
n Java Integrated Development Environment (IDE), adic n mediul de dezvoltare preferat.
Conexiunea dintre planul propriu zis i antetul planului este stabilit n descrierea fcut n
antetul planului, astfel planurile propriu-zise putnd fi reutilizabile n diferite configuraii sau
planuri specificate. Pentru a spori reutilizabilitatea planurilor, este recomandat folosirea
parametrilor planului, n combinaie cu maprile planului pentru anumite evenimente sau
obiective ale cror succes depind de execuia planului.
Orice plan extinde clasa abstract jadex.runtime.AbstractPlan, n timp ce planurile
standard implementeaz metoda body() aa cum a fost specificat mai sus. Metoda body() este
executat o singur dat de-a lungul apelrii unui plan, apoi planul ateptnd terminarea
execuiei evenimentelor descrise prin triggere apelnd directiva waitFor().
Dac planul se termin fr producerea vreunei excepii, este considerat ca i succes.
Dup terminarea cu succes, eec sau anularea planului se apeleaz metoda passed(), failed(),
respectiv aborted().
Excepia care indic o anomalie n execuia planului este PlanFailureException care
se apare de fiecare dat cnd planul nu se execut cu succes.
Scrierea planurilor permite de asemenea executarea de poriuni de cod atomice, n
cazul n care nu vrem ca prin concuren s producem anomalii de citire sau scriere pentru
anumite ipoteze eseniale pentru buna funcionare a agentului BDI n care este specificat
planul.
5.3.3
Interfee Utilizator
Exist trei interfee utilizator disponibile n sistemul curent, prima fiind interfaa de
monitorizare, cu ajutorul creia se monitorizeaz i controleaz senzorii i dispozitivele
disponibile n casa inteligent.
Interfaa de monitorizare a robotului supervizor reprezint o hart 2D a casei i robotul
care se plimb pe harta casei.
Interfaa de monitorizare explicit a robotului misionar reprezint un plan simplu pe
care sunt aezate obiectivele identificate de ctre robotul transportor, precum i robotul
transportor mpreun cu raza lui de aciune.
5.4
Scenariu de testare
Scenariul de testare urmrit cnd s-a dezvoltat sistemul curent este:

Un cuplu de oameni cstorii s-au decis s nceap s foloseasc sistemul Smart
House n reedina lor. Ei au doi copii: Ioana, o feti de 14 ani, i pe micuul Ionu de doar 4
ani. Pentru a fi ajutai i a eficientiza muncile casnice de zi cu zi familia s-a decis s
foloseasc 3 roboi: Locke, robotul supervizor, Sawyer, robotul transportor i pe Dolly,
robotul de divertisment.
Sawyer, robotul transportor are ca scop transportul de obiecte dintr-o camer n alta i
amplasarea lor n locul de depozitare potrivit. Dolly, robotul de divertisment are ca rol
supravegherea micuului casei i meninerea unei stri de bucurie pentru bieel. Locke este
robotul supraveghetor i elaboreaz comenzi sau monitorizeaz activitatea celorlali 2 roboi.
UTILIZAREA SISTEMULUI
Aplicaia se pornete din mediul Eclipse sau individual a platformei pentru ageni
pentru ca ulterior s se porneasc fiecare agent pe rnd. Pentru a realiza acest lucru se
acceseaz fiierele .bat existente n directorul surs al aplicaiei.
Odat ce toi agenii au fost pornii cu succes vor aprea cele trei interfee utilizator:
interfaa de monitorizare i control a senzorilor i dispozitivelor, interfaa specific robotului
supervizor i interfaa specific robotului misiune.
Pentru a testa pornirea cu succes a senzorilor casei se verific consola pentru ageni,
pentru a vedea toi agenii pornii.
Simularea roboilor ncepe odat cu pornirea agentului manager de roboi. Pentru ca
rezultatele rulrii simulatorului pentru roboi s fie edificate, este nevoie ca celelalte procese
costisitoare care ruleaz pe maina de test s fie oprite.
Pentru a testa adaptarea se urmrete vizualizarea grafic a micrii robotului precum
i faptul c el i ndeplinete cu succes obiectivele i anume:
Micarea robotului transportor este urmrit de ctre robotul supervizor i mediul
se actualizeaz de fiecare dat;
Cutiile care intr n raza vizual a robotului transportor vor fi transportate una cte
una la locul de depozitare;
Robotul i menine starea de patrulare prin cas att timp ct nu ndeplinete alt
misiune;
Robotul se ndreapt spre staia de acumulare a energiei atunci cnd bateria este la
nivelul minim acceptat;
La fiecare micare nivelul bateriei robotului scade cu 1%. Acest lucru se
monitorizeaz prin eticheta energy ataat robotului;
Dac robotul transport o cutie atunci acest lucru este semnalizat pe interfaa
grafic prin eticheta carries box.
n Figura 6.1 este reprezentarea robotului transportor aa cum este el vizualizat n
simulatorul pentru roboi al casei inteligente.
Figura 6.30 Reprezentarea robotului transportor
Pentru a monitoriza numrul de cutii care trebuie s fie preluate de ctre robotul
transportor se vizualizeaz panoul aflat n partea de jos a imaginii, care are aceeai structur
ca n Figura 6.2:
Figura 6.31 Panoul de control al simulatorului
Utilizarea Sistemului
Tot cu ajutorul simulatorului se poate seta starea depozitului de cutii. n cazul n care
depozitul este plin robotul este informat de sistemul casei de acest lucru, drept urmare el
anulnd planul de a depozita cutia n depozitul respectiv.
Pe consola agentului bazei de cunotine trebuie s apar anumite loguri prin care se
explic ce roboi au fost gsii n casa inteligent, aceste informaii de context fiind transmise
agentului manager de roboi pentru a porni agenii roboi subsecveni. Cu ajutorul consolei
agentului bazei de cunotine putem vedea toate instanele de clas Robot create, mpreun cu
proprietile aferente acestora (Figura 6.3).
Figura 6.32 Consola agentului pentru baza de cunotine
PUNERE N FUNCIUNE I REZULTATE

EXPERIMENTALE
7.1
Tehnologii folosite
7.1.1
Cerine Hardware
Sistemul dezvoltat ca urmare a lucrrii curente este un sistem software, care implic
utilizarea unei maini de tip PC cu sistemul de operare Windows sau Linux. Pentru rularea
aplicaiilor cerinele hardware minimale pentru maina utilizat sunt:
Procesor: Frecven 1GHz, Spaiu de adresare 32-bit (x86);
Memorie RAM: 512 MB;
Spaiu hard-disk: minimum 1GB.
7.1.2
Cerine Software
Produsul curent este dependent de urmtoarele produse software:
Java VM Version 6 - Pentru rularea sistemului este nevoie de instalarea mainii
virtuale Java (Java Virtual Machine) pe maina folosit. Instalarea mainii virtuale
Java poate fi fcut accesnd adresa http://www.java.com/en/download/index.jsp;
Platforma Jade Platforma de ageni Jade poate fi descrcat de la adresa
http://jade.tilab.com/;
Jadex Aplicaia pentru ageni Jadex poate fi descrcat de la adresa
http://sourceforge.net/project/showfiles.php?group_id=80240&package_id=81901;
Eclipse Ganymede Pentru a descrca mediul Eclipse se poate accesa pagina
http://www.eclipse.org/downloads/.
7.1.3
Instalarea aplicaiilor folosite
Pentru punerea n funciune a aplicaiei este nevoie de instalarea extensiei Jadex

pentru Eclipse Ganymede. Pentru efectuarea acestui lucru trebuie executai urmtorii pai:
Instalare manual
o Se
descarc
pachetele
de
la
adresa
http://sra.itc.it/tools/taom4e/download.php?action=register;
o Se extrag pachetele din arhiva descrcat;
o Cele 2 pachete it.itc.sra.taom4e.model_0.5.0.jar i it.itc.sra.taom4e.
platform_0.5.0.jar se copiaz n directorul <dir_eclipse>/eclipse/ plugins
din Eclipse;
o Se pornete mediul Eclipse.
Instalare automat
o Se pornete mediul Eclipse;
o Se acceseaz meniul Help/Software Updates...
o n panoul Available Software se apas butonul Add Site...
o Se adaug http://sra.itc.it/tools/taom4e/eu.fbk.se.taom4e.updateSite/ n
spaiul destinat adresei web;
o Se apas OK i apoi Install.
Punere n funciune i rezultate experimentale
7.1.4
Configurarea proiectului
Pentru a configura proiectul se efectueaz urmtorii pai:
La pornirea mediului Eclipse se configureaz calea spre workspace-ul n care se
afl proiectul. Astfel se adaug calea <dir_workspace> /<nume_workspace> /
workspace. Workspace-ul Eclipse cu sursele i configuraia proiectului se afl n
distribuia aplicaiei. Numele implicit este WSBB;
Se configureaz o nou librrie utilizator Eclipse din meniul Project /Properties
apoi seciunea Java Build Path ->Add Library.... Se adaug toate fiierele cu
extensia .jar din directorul <dir_workspace>/<nume_workspace> /
workspace/SmartHouse/lib. Dup adugare se ataeaz aceast librrie la proiectul
curent pentru a compila sursele.
7.1.5
Pornirea Platformei de Ageni
Punerea n funciune a platformei pentru ageni Jadex se poate face dup ce s-a pornit
Eclipse mpreun cu pachetele auxiliare care necesit instalarea. Dac instalarea a avut loc cu
succes, n bara de butoane a mediului Eclipse va aprea un buton cu ajutorul cruia se poate
porni platforma, locat ca n Figura 7.1:
Figura 7.33 Pornirea platformei de ageni din Eclipse
Dac platforma a pornit cu succes va aprea o nou fereastr n care vor exista cei trei
ageni master din Jadex AMS, DF i RMA. Fereastra are forma din Figura 7.2:
Figura 7.34 Platforma de ageni Jadex
7.1.6
Pornirea agentului pentru baza de cunotine a sistemului
Pentru pornirea agentului pentru baza de cunotine a sistemului se folosete fiierul

cu extensia .bat numit KnowledgeBaseAgent. Acest fiier se afl la calea
<dir_workspace>/<nume_workspace>/workspace/SmartHouse. Pornirea acestui agent are ca
rezultat nregistrarea sa n platforma de ageni. Acest agent este primul care trebuie pornit
pentru ca ceilali ageni s poat interoga acest agent n vederea extragerii informaiilor de
context necesare.
7.1.7
Pornirea agentului manager de senzori
Pentru punerea n funciune a agentului pentru reeaua de senzori a sistemului casei

inteligente se folosete fiierul cu extensia .bat numit SensorManager. Acest fiier se afl la
calea <dir_workspace>/<nume_workspace>/workspace/SmartHouse. Pornirea acestui agent
are ca rezultat nregistrarea sa n platforma de ageni Jadex. n plus, dup stabilirea
comunicrii cu agentul bazei de cunotine se mai nregistreaz la platform prin instane
specifice diferitele tipuri de senzori definii pentru sistemul curent. Astfel prin pornirea
agentului de manager a senzorilor se creeaz reeaua senzorial a casei.
7.1.8
Pornirea agentului manager de dispozitive
Pentru punerea n funciune a agentului pentru reeaua de dispozitive a sistemului

casei inteligente se folosete fiierul cu extensia .bat numit DeviceManager. Acest fiier se
afl la calea <dir_workspace>/<nume_workspace>/workspace/SmartHouse. Pornirea acestui
agent are ca rezultat nregistrarea sa n platforma de ageni Jadex. n plus dup stabilirea
comunicrii cu agentul bazei de cunotine se mai nregistreaz la platform prin instane
specifice diferitele tipuri de dispozitive definite pentru sistemul casei inteligente. Astfel prin
pornirea agentului de manager a senzorilor se creeaz reeaua de dispozitive a casei
inteligente.
7.1.9
Pornirea agentului de monitorizare
Agentul de monitorizare se pune n funciune prin executarea fiierului cu extensia

.bat numit MonitoringAgent. Fiierul se afl la calea <dir_workspace> /<nume_workspace>/
workspace/SmartHouse. n urma punerii n funciune a agentului de monitorizare, se va crea
mediul vizual cu ajutorul cruia vor putea fi monitorizate reeaua de senzori i reeaua de
dispozitive a aplicaiei. De asemenea acest agent monitorizeaz i starea de spirit a locatarilor
casei inteligente.
7.1.10 Pornirea agentului manager pentru roboi

i pentru punerea n funciune a agentului manager al sistemului de roboi este pus la
dispoziie un fiier cu extensia .bat numit ManagerRobot. Fiierul se afl la calea
<dir_workspace> /<nume_workspace>/workspace/SmartHouse. n urma punerii n funciune
a acestui agent responsabil pentru roboii casei inteligente se vor nregistra dup comunicarea
cu baza de cunotine i agenii pentru roboii specifici ai casei i anume robotul supervizor,
robotul transportor i robotul de divertisment. Ca urmare a instanierii roboilor specifici, se
vor crea i interfeele vizuale specifice celor doi roboi prin care se poate vizualiza activitatea
roboilor n casa inteligent.
7.2
7.2.1
Probleme ntmpinate i modul de rezolvare

Probleme de pornire a platformei de ageni
Dac dup pornirea platformei nu apare fereastra de control care asigur pornirea cu
succes a platformei de ageni, iar pe consol apare o excepie numit AlreadyBoundException
atunci este cazul excepiei de nregistrare a aplicaiei n registrul RMI, datorit faptului c
portul implicit pe care se pune n funciune RMI i anume 1099 este ocupat.
De asemenea i o oprire forat a platformei de ageni poate duce la ocuparea de ctre
procesul javaw n stare inactiv a portului 1099.
Pentru rezolvarea problemei se distruge procesul javaw care ine ocupat portul 1099,
folosind o aplicaie de management a porturilor numit Cports. O alt modalitate de rezolvare
a problemei este restartarea platformei Eclipse care distruge toate procesele copil create la
nchiderea sa.
7.2.2
Probleme de pornire a agenilor
Dac la pornirea agenilor apar erori pe consol, atunci trebuie verificat n primul rnd
dac consola pentru ageni funcioneaz corect. Ulterior se verific dac toi agenii
dependeni, precum agentul pentru baze de cunotine, funcioneaz corect.
Dac eroarea de pornire nu este cauzat de unul din cazurile de mai sus atunci se
editeaz fiierul .bat specific agentului, pentru a verifica dac toate cile spre pachetele care
se seteaz ca i Java Classpath sunt corecte. Dac acele ci nu exist se actualizeaz cu cile
valide spre pachetele folosite la pornirea agenilor.
Dac nici acest lucru nu rezolv problemele de punere n funciune, atunci se verific
dac numele pachetelor corespunztoare locaiei agenilor i dac numele agenilor exist.
7.3
7.3.1
Rezultate experimentale
Crearea roboilor
n faza de creare a roboilor dup crearea instanei de agent manager pentru roboi i
nregistrarea lui la platforma de ageni se face un apel la agentul bazei de cunotine pentru
gsirea instanelor de ageni roboi specifici casei inteligente i crearea lor ca ageni logici
pentru casa inteligent.
Crearea agenilor roboi se face printr-un apel de tip creare agent spre agentul master
al platformei, AMS.
Clasele ontologice specifice roboilor create n contextul ontologic al sistemului casei
inteligente sunt precum n Figura 7.3:
Figura 7.35 Clasele ontologice specifice agenilor roboi
De asemenea fiecare robot are specificate anumite proprieti, care vor fi luate n
considerare la crearea instanelor. Proprietile robotului supervizor sunt legate de locaie,
nume, descriere, activitate, precum n Figura 7.4:
Figura 7.36 Proprieti individuale specificate n modelul ontologic - robot supervizor
Crearea efectiv a roboilor se poate valida prin vizualizarea mesajelor trimise ntre
agentul manager pentru roboi i agentul responsabil pentru baza de cunotine.
Agentul Manager trimite un mesaj tip ACL cu coninutul getRobots agentului pentru
baza de cunotine aa cum poate fi vizualizat n Figura 7.5.
Figura 7.37 Mesajul trimis ctre agentul bazei de cunotine pentru identificarea roboilor
Mesajul primit de ctre agentul manager de roboi este ca n Figura 7.6:
Figura 7.38 Mesajul cu coninutul instanelor de roboi trimis de agentul bazei de cunotine
7.3.2
Adaptarea roboilor
Odat ce instanele de ageni roboi au fost create cu succes, ncepe adaptarea roboilor
la contextul casei inteligente. Acest lucru poate fi vizualizat interognd consola de pornire a
agenilor pentru a vedea planurile executate i mesajele transmise ntre agenii roboi i
sistemul casei inteligente, precum n Figura 7.7.
Figura 7.39 Mesaje ACL transmise ntre agentul robot transportor i sistemul casei inteligente
De asemenea pe consola agentului manager pentru roboi pot fi vzute toate aciunile
efectuate de ctre roboii din casa inteligent, cele mai relevante informaii fiind planurile care
se execut la un moment dat de ctre acetia, cel mai interesant de urmrit fiind planurile
robotului transportor (Figura 7.8).
Figura 7.40 Consola agentului Manager pentru roboii casei inteligente i planurile executate
8 CONCLUZII
8.1 Realizri
Cerinele lucrrii exprimate n introducere au fost atinse prin proiectarea adaptrii
roboilor la sistemul senzitiv la context pentru casa inteligent i prin argumentarea tuturor
conceptelor i metodelor folosite, care au condus la validarea proiectrii cerinei de adaptare a
roboilor la sistemului senzitiv la context, multi-agent i distribuit.
n primele capitole ale lucrrii s-a abordat problema adaptrii n toat complexitatea ei
prin prezentarea noiunilor teoretice legate de conceptele folosite n scopul adaptrii roboilor.
S-au detaliat noiuni bine stabilite legate de domeniul senzitiv la context, domeniul ubicuu
care este o aplicaie practic a senzitivitii la context, precum i de noiunile de baz folosite,
unele dintre ele fiind mprumutate din domeniul inteligenei artificiale, precum noiunea de
agent, sistem multi-agent, noiuni legate de incertitudine.
S-au identificat problemele existente i provocrile aprute n timpul proiectrii unei
aplicaii senzitive la context, precum i provocrile aprute n comunicarea dintre roboi i o
aplicaie senzitiv la context.
S-a motivat nevoia de a folosi o metod flexibil i extensibil pentru a modela datele
contextuale, un limbaj comun neles de toi participanii la arhitectur, imperios necesar
pentru a putea realiza comunicarea dintre sistemul de roboi i sistemul casei inteligente.
Folosirea ontologiilor faciliteaz de asemenea i deducerea de noi informaii prin raionarea
asupra datelor contextuale. Din punct de vedere a raionamentelor deduse, folosirea
ontologiilor permit ierarhizarea datelor de context, n contexte de nivel superior, generale i
reutilizabile, i contexte de nivel inferior, specifice, care conin validri de consisten.
Derivarea de noi contexte de nivel superior din datele de nivel inferior se poate obine
folosind tehnicile mprumutate din inteligena artificial legate de algoritmi de raionare i
mecanisme de inferen. Dup aprofundarea metodei de modelare a contextelor s-a studiat i
un model derivat care adaug suport pentru incertitudine n modelul contextual iniial,
aprofundarea acestui model ajutnd la rezolvarea problemelor de incertitudine deschise n
proiectarea adaptrii roboilor la sistemul casei inteligente.
Au fost studiate i diferite abordri i metodologii de proiectare ale unui sistem
senzitiv la context extensibil i flexibil, n care se pot integra foarte uor noi componente,
lucru care faciliteaz adaptarea rapid a agenilor roboi n structura sistemului. S-a studiat
arhitectura stratificat Context Stack, care are la baz modelul folosit n construcia reelelor
de calculatoare i avantajele aduse de acesta.
Abordarea problemei centrale a lucrrii legat de adaptarea de noi componente, n caz
particular, roboi, n sistemul senzitiv la context a condus, printr-o aprofundare a
metodologiilor existente pentru crearea de baze de cunotine i crearea sistemelor multiagent, la rezolvarea ei prin folosirea metodologiilor existente cele mai potrivite pentru cazul
de fa. Astfel studiind diferite metodologii de creare a agenilor i obinnd o comparaie din
punct de vedere a standardizrii, a ntreinerii, a protocoalelor de comunicare folosite, a
documentaiei disponibile s-a concluzionat c folosirea platformei Jade cu extensia Jadex este
cea mai potrivit pentru atingerea obiectivelor propuse n scopul temei curente. Astfel s-a ales
ca paradigm de implementare programarea cu ageni, n care toate modulele componente ale
arhitecturii reprezint un agent cu diferite funcionaliti inclusiv ageni care funcioneaz ca
rol de interfa utilizator, cum este cazul agentului de monitorizare. Agenii folosii sunt ageni
de tip Ipotez-Obiectiv-Plan sau BDI (Belief-Desire-Intention), care pornind de la anumite
ipoteze, ating obiectivele setate prin executarea de planuri de execuie.
Concluzii
Pentru modelarea bazei de cunotine folosit de sistem s-a folosit reprezentarea

cunotinelor de context prin ontologii, fiind aprofundate mai multe metodologii i limbaje de
descriere a ontologiilor, precum i modul de integrare i folosire a acestora pentru
comunicarea ntre agenii implicai n arhitectur. Dup studierea limbajelor n funcie de
ntreinere, naturalee i uurin a scrierii s-a ajuns la concluzia c limbajul OWL este cel mai
potrivit pentru scrierea de ontologii specifice pentru sistemul senzitiv la context i pentru
adaptarea ontologiilor legate de roboi cu ontologiile sistemului casei inteligente, fcndu-se
astfel legtura ntre nivelul roboi i sistemul senzitiv la context al casei inteligente. Pentru
crearea i editarea de ontologii s-a folosit editorul Protg care este ntreinut i modern fiind
cel mai bine dezvoltat editor pentru ontologii, beneficiind i de multe extensii vizuale, unelte
pentru efectuarea de raionamente. Deoarece agenii din sistemul multi-agent creat pentru casa
inteligent comunic prin protocolul Nuggets bazat pe XML-uri, ontologiile au fost
transformate n clase Java de tip Java Beans ale cror instane de tip obiect vor putea fi
serializate n format XML i transmise prin reea ca mesaje celorlali ageni conectai la
platform. Astfel s-a folosit extensia Beanynizer a mediului Protg prin care s-a fcut
transformarea sub forma de unu la unu din clase ontologice n clase Java.
Avnd toate specificaiile formate i uneltele necesare stabilite n prealabil s-a creat o
arhitectura descentralizat, bazat pe componente corespunztoare unui anumit tip de ageni
care pot comunica unul cu cellalt. Astfel componenta legat de agenii roboi s-a integrat n
mod natural cu restul componentelor arhitecturii, colaborarea ntre diferiii ageni fcndu-se
prin mesaje de tip Nuggets. Astfel, prin folosirea uneltelor studiate i construirea arhitecturii
s-a rezolvat deja problema principal a temei, prin simplificarea problemei la adaptarea
agenilor care reprezint roboii casei inteligente la sistemul senzitiv la context al casei
inteligente.
Scenariul propus pentru testarea i simularea adaptrii roboilor const n realizarea
robotului transportor i robotului superzivor, care au misiuni bine specificate n casa
inteligent, misiuni care sunt ndeplinite folosind informaiile de context oferite de ceilali
ageni, precum agentul responsabil pentru reeaua senzorial. Astfel au fost specificate
ipoteze, obiective i planuri pentru cei doi roboi. Robotul transportor are misiunea de a
transporta cutii din camera copiilor pn n locul de depozitare aflat n garaj, iar robotul
supervizor supravegheaz mediul casei, identific schimbrile de context din cas i comand
noi misiuni pentru robotul transportor.
Aceast lucrare a prezentat toate detaliile necesare pentru proiectarea, construirea i
realizarea adaptrii roboilor prin ageni Jadex la sistemul multi-agent al casei inteligente. De
asemenea arhitectura este extensibil i scalabil, ulterior putnd fi adaptate i alte tipuri de
ageni roboi, de exemplu roboii de divertisment. De asemenea arhitectura las loc explorrii
de noi domenii de cercetare din domeniul aplicaiilor ubicue i senzitive la context, pornind de
la arhitectura de tip multi-agent a sistemului n conjuncie cu modelarea contextelor sub form
de ontologii i folosirea tehnicilor mprumutate din inteligena artificial precum nvarea, i
procesul de luare a deciziilor, toate aceste arii de cercetare avnd ca obiectiv final sporirea
confortului locatarilor unei case inteligente.
8.2
Direcii de dezvoltare
Dezvoltrile ulterioare ale aplicaiei pot lua diferite direcii, dar cele mai importante
vor fi subliniate n paragrafele urmtoare.
Un prim aspect este legat de implementarea unei aplicaii complete pentru case
inteligente, care implic i roboi antrenai activ n atingerea obiectivelor finale. Aceasta este o
chestiune n curs de cercetare i o perspectiv bun de dezvoltare ulterioar. Astfel sistemul ar
trebui s integreze componente noi, precum un detector a strii emoionale, care n consecin
Concluzii
ar putea valorifica misiunea robotului de divertisment, integrarea unui sistem-expert complet

funcional, care s poat folosi reguli de inferen complexe, adugarea nivelului fizic prin
care aplicaia s fie valorificat, care implic i adugarea de reguli i mecanisme de deducie
pentru a procesa informaiile eronate preluate de la nivel fizic.
Un alt aspect legat de adaptarea roboilor sau a altor dispozitive de tip eterogen este
interoperabilitatea modelelor de context, care ar facilita adaptarea de noi roboi fr a fi
necesar cunoaterea modelului de context curent, deci ar fi nlturat rigiditatea folosirii unui
singur limbaj de reprezentarea a contextelor.
Tot un aspect de luat n considerare este mobilitatea agenilor roboi creai n Jadex,
adaptarea acestora ntr-un mediu senzitiv la context nou este o munc dificil, acest lucru
afectnd instalarea aplicaiei ntr-un mediu senzitiv la context real.
Alte provocri aflate nc n faza de cercetare sunt:
Incertitudinea Adaptarea roboilor sau a altor ageni ntr-un mediu incert, mediu
care mapeaz cel mai bine lumea real rmne o provocare pentru cercettorii n
domeniul sistemelor senzitive la context. Nu exist nc un model unificat pentru
modelarea probabilistic a contextelor.
Securitatea datelor Mobilitatea agenilor adaug probleme complexe de
securitate, deoarece posibilitatea executrii de misiuni la distan poate duce la
bree mari de securitate. Un agent logic trebuie s fie autentificat nainte s
comande de exemplu un robot de la distan.
BIBLIOGRAFIE
[01] K. Goldberg, S. Gentner, and C. Sutter et al., The Mercury Project: A Feasibility Study
for Internet Robotics, IEEE Robotics and Automation Magazine, vol. 7, no. 1, 2000, pp. 3540.
[02] R. Simmons, Xavier: An Autonomous Mobile Robot on the Web, Proc. IEEE/RSJ
Conf. on Intelligent Robots and Systems; Robots, Victoria, B.C. Canada, Oct. 1998, URL:
http://www.ri.cmu.edu/pub_files/pub1/simmons_reid_1999_1/simmons_reid_1999_1.pdf.
[03] P. Saucy and F. Mondada, Open Access to a Mobile Robot on the Internet, IEEE
Robotics and Automation Magazine, vol. 7, no. 1, 2000, pp. 41-47.
[04] M.R. Stein, Interactive Internet Artistry, IEEE Robotics and Automation Magazine,
vol. 7, no. 1, 2000, pp. 28-32.
[05] M. Choi, J. Hong, and H. Ju, XML-Based Network Management for IP Networks,
ETRI J., vol. 25, no. 6, Dec. 2003, pp. 445-463.
[06] Young-Guk Ha, Joo-Chan Sohn, Young-Jo Cho, and Hyunsoo Yoon, Towards a
Ubiquitous Robotic Companion: Design and Implementation of Ubiquitous Robotic Service
Framework, Sept. 15, 2005.
[07] D. Wang, X. Ma, and X. Dai, Web-Based Robotic Control System with Flexible
Framework, Proc. IEEE Intl Conf. on Robotics and Automation (ICRA 2004), New Orleans,
LA, Apr. 2004, pp. 3351 - 3356.
[08] W3C Recommendation,
http://www.w3c.org/TR/ws-arch/.
Web
Services
Architecture,
W3C,
2004,
URL:
[09] W3C Recommendation, RDF Primer, W3C, 2004, URL:http://www.w3c.org/TR/rdfprimer/.

[10] L. Miller, A. Seaborne, and A. Reggiori, Three Implementations of SquishQL, a Simple
RDF Query Language, Proc. 1st Intl Semantic Web Conf. (ISWC 2002), LNCS 2342,
Springer-Verlag, 2002, pp. 423-435.
[11] Z. Zenn Bien. Human-friendly Man-Machine Interaction in Smart Home. Keynote
speech at the 3rd International Conference On Smart homes and health Telematic,
Sherbrooke, Qubec, Canada, July 4-6, 2005.
[12] A. Helal, W. Mann, H. Elzabadani, J. King, Y. Kaddourah and E. Jansen, "Gator Tech
Smart House: A Programmable Pervasive Space", IEEE Computer magazine, March 2005, pp.
64-74.
[13] Mohamed Ali Feki, Stphane Renouard, Bessam Abdulrazak, Grard Chollet, Mounir
Mokhtari. Coupling Context Awareness and Multimodality in Smart Homes Concept. The
10th International Conference on Computers Helping People with Special Needs. Lecture
Bibliografie
Notes in Computer Science 3118 Springer 2004, ISBN 3-540-22334-7. Paris, France, July,
2004.
[14] Kensuke Murai and Akira Okubo, Government Policy for Next Generation Robots in
Journal of the Robotics Society of Japan, Vol. 26. No.5, 2008.
[15] Ghita Kouadri Mostefaoui, Jacques Pasquier-Rocha, Patrick Brezillon Context-Aware
Computing: A Guide for the Pervasive Computing Community, Pervasive Services, ICPS
2004 IEEE/ACS International Conference, July 2004.
[16] Dey Anind K. & Gregory D. Abowd, Towards a Better Understanding of Context and
ContextAwareness, GVU Technical Report GIT-GVU-00-18, GIT, 1999.
[17] Ay Feruzan, Context Modeling and Reasoning using Ontologies, University of
Technology Berlin, Berlin , July 2007.
[18] Ronny Haryanto, Context Awareness in Smart Homes to Support Independent Living,
Master of Science in Internetworking, University of Technology, Sydney, 2005
[19] Research Center for Educational Technology, Ubiquitous Computing Where it came
from, RCET, 2006, URL: http://www.rcet.org/ubicomp/what.htm.
[20] Boehm Barry, Ubiquitous Computing, Center for Systems and Software Engineering,
University
of
Southern
California,
2007,
URL:
http://sunset.usc.edu/classes/cs599_2002/Week3_c.ppt.
[21] Tao Gua, Hung Keng Punga, Da Qing Zhangb, A service-oriented middleware for
building context-aware services, Journal of Network and Computer Applications, archive
Volume 28 , Issue 1, January 2005.
[22] Seng Loke , Context-aware pervasive systems: architectures for a new breed of
applications, CRC Press, 2006.
[23] T. Wahl: Konzeption und Realisierung einer Ontologie zur Modellierung und Ableitung
von Geschftsprozessen, TU Berlin, 2005.
[24] J. Vo: Begriffssysteme Ein Vergleich verschiedener Arten von Begriffssystemen und
Entwurf des integrierenden Datenmodells, HU, Berlin, 2004.
[25] M. Gruninger, and J. Lee: Ontology Applications and Design, in Communications of
the ACM, 2002.
[26] M. K. Smith, C. Welthy, and D. L. McGuinness: OWL Web Ontology Language
Guide, URL: http://www.w3.org/TR/owl-guide.
[27] S. Bechhofer, F. v. Harmelen, J. Hendler, I. Horrocks, et al.: OWL Web Ontology
Language Reference, URL: http://www.w3.org/TR/owl-ref.
[28] T. R. Gruber: Ontolingua: A Mechanism to Support Portable Ontologies, Stanford
University, 1992.
Bibliografie
[29] R. M. MacGregor: Inside the LOOM description classifier, in ACM SIGART Bulletin,
1991.
[30] T. Berners-Lee, J. Hendler, et al.: The Semantic Web, Scientific American, 2001.
[31] Bray, T., J. Paoli, et al.: Extensible Markup Language (XML) 1.0 (Third Edition) - W3C
Recommendation. URL: http://www.w3.org/TR/2004/RECxml-20040204, 2004.
[32] X. H. Wang, T. Gu, D. Q. Zhang, and H. K. Pung: Ontology Based Context Modeling
and Reasoning using OWL, Pervasive Computing and Communications Workshops, March
2004.
[33] Daqing Zhang, Tao Gu, Xiaohang Wang: Enabling Context-Aware Smart Home with
Semantic Web Technologies, Institute for Infocomm Research, June 2005.
[34] Daqing Zhang, Xiaohang Wang: OSGi Based Service Infrastructure for Context Aware
Connected Home. Proceeding of 1st International Conference On Smart Homes and Health
Telematics (ICOST2003), IOS Press, Paris, France, 2007.
[35] T. Gu, H. K. Pung, D. Q. Zhang, Towards an OSGi-Based Infrastructure for ContextAware Applications in Smart Homes, IEEE Pervasive Computing, Vol. 3, Issue 4, 2004.
[36] Bardram, Jakob E. The Java Context Awareness Framework (JCAF) A Service
Infrastructure and Programming Framework for ContextAware Applications,Third
International Conference on Pervasive Computing, vol. 3468 of Lecture Notes in Computer
Science, Munich, Germany, May 2005.
[37] Mayrhofer Rene, An Architecture for Context Prediction, PhD Thesis,University Linz,
Austria, 2004.
[38] Wooldridge, Michael and Nicholas R. Jennings (1995), "Agent Theories, Architectures,
and Languages:a Survey", Wooldridge and Jennings Eds., Intelligent Agents, Berlin: SpringerVerlag, 1-22.
[39] Russell, Norvig, Artificial Intelligence: a Modern Approach, Russell and Norvig, 1995.
[40] Rem Collier, Gregory OHare,Terry Lowen, Colm Rooney, Beyond Prototyping in the
Factory of Agents, 3rd Central and Eastern European Conference on Multiagent Systems
(CEEMAS'03), Lecture Notes in Computer Science (LNCS), 2691, 2003.
[41] Kavi Kumar Khedo, Context-Aware Systems for Mobile and Ubiquitous Networks,
International Conference on Systems and International Conference on Mobile
Communications and Learning Technologies, 2006.
[42] Salber, Daniel, Anind K. Dey & Gregory D. Abowd. 1999, The Context Toolkit: Aiding
then Development of ContextEnabled Applications, Pittsburgh, USA, May 1999.
Bibliografie
[43] N. Hristova, G.M.P. OHare & T. Lowen, Agent-based Ubiquitous Systems: 9 Lessons
Learnt, In Proceedings of the System Support for Ubiquitous Computing Workshop , Fifth
Annual Conference on Ubiquitous Computing (UbiComp'2003) Seattle, Washington, 2003.
[44] Strang, T. and Linnhoff-Popien, C., A Context Modeling Survey, First International
Workshop on Advanced Context Modelling, Reasoning and Management, UbiComp, 2004.
[45] Chen, Guanling, David Kotz, A Survey of Context-Aware Mobile Computing
Research, Dartmouth Computer Science, Technical Report, 2000.
[46] Thomas Strang, Claudia Linnho-Popien, Korbinian Frank, CoOL: A Context Ontology
Language to enable Contextual Interoperability, Distributed Applications and Interoperable
Systems (DAIS2003), 2003.
[47] M. K. Smith, C. Welthy, and D. L. McGuinness: OWL Web Ontology Language
Guide, URL: http://www.w3.org/TR/owl-guide.
[48] Binh An Truong, Young Koo Lee, Sung Young Lee, A Unified Context Model: Bringing
Probabilistic Models to Context Ontology, EUC Workshops, 2005.
[49] J. Pearl, "Belief Networks Revisited", Artificial intelligence in perspective, p. 49-56,
1994.
[50] Gregory D. Abowd and Anind K. Dey, "Towards a Better Understanding of Context and
Context-Awareness", Workshop on the what, who, where, when and how of context-awareness
at CHI 2000, Aprilie 2000.
[51] Corcho, O., Fernandez-Lopez, M., Gomez-Perez, A., Methodologies, tools, and
languages for building ontologies. Where is their meeting point?, Data and Knowledge
engineering, 2003.
[52] D.B. Lenat, R.V. Guha, Building Large Knowledge-Based Systems: Representation and
Inference in the Cyc Project, Addison-Wesley, Boston, 1990.
[53] A. Bernaras, I. Laresgoiti, J. Corera, Building and reusing ontologies for electrical
network applications, Proc. European Conference on Artificial Intelligence (ECAI_96),
Budapest, Hungary, 1996, pp. 298302.
[54] B. Swartout, P. Ramesh, K. Knight, T. Russ, Toward Distributed Use of Large-Scale
Ontologies, AAAI Symposium on Ontological Engineering, Stanford, 1997.
[55] M. Fernandez-Lopez, A. Gomez-Perez, A. Pazos-Sierra, J. Pazos-Sierra, Building a
chemical ontology using METHONTOLOGY and the ontology design environment, IEEE
Intelligent Systems & their applications, 1999, p. 3746.
[56] Nguyen G., Dang T.T, Hluchy L., Laclavik M., Balogh Z., Budinska I. Agent platform
evaluation and comparison, Jun 2002.
[57] FIPA standards and specification, FIPA, IEEE Computer Society Standards for Agent
Based Technologies, http://www.fipa.org/specifications/index.html.
Bibliografie
[58] FIPA-OS, Agent Platform Development Tool, IEEE Computer Society Standards for
Agent Based Technologies, http://fipa-os.sourceforge.net/.
[59] ***, JADE, Tutorial for beginners, JADE Board, http://jade.tilab.com.
[60] ***, JACK, http://www.agent-software.com/.
[61] ***, Zeus BT Intelligent Agent Research, http://www.opensource.org/.
[62] Lars Braubach, Jadex User Guide, Distributed Systems Group University of Hamburg,
Germany, http://prdownloads.sourceforge.net/jadex/userguide-0.96.pdf.
[63] Lars Braubach, Jadex Tool Guide, Distributed Systems Group University of Hamburg,
Germany, http://prdownloads.sourceforge.net/jadex/toolguide-0.96.pdf.
[64] ***, W3C Recommendation, SOAP Version 1.2 Primer, W3C, 2003, URL:
http://www.w3c.org/TR/%20soap12-part0/.
[65] N.F. Noy, R.W. Fergerson, M.A. Musen, The knowledge model of protege-2000:
combining interoperability and flexibility, 12th International Conference in Knowledge
Engineering and Knowledge Management (EKA 2000), Lecture Notes in Artificial
Intelligence, vol. 1937, Springer, Berlin, 2000, pp. 1732.
[66] J.C. Arpirez, O. Corcho, M. Fernandez-Lopez, A. Gomez-Perez, WebODE: a scalable
ontological engineering workbench, First International Conference on Knowledge Capture
(KCAP01), ACM Press, Victoria, 2001, pp.613.

Adaptarea Robotilor Intr-Un Sistem Senzitiv La Context Pentru o Casa Inteligenta

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Adaptarea Robotilor Intr-Un Sistem Senzitiv La Context Pentru o Casa Inteligenta

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA TEHNIC CLUJ-NAPOCA

FACULTATEA DE AUTOMATIC I CALCULATOARE

MIHAI GABRIEL RAIU

UNIVERSITATEA TEHNIC CLUJ-NAPOCA

ADAPTAREA ROBOILOR NTR-UN SISTEM

Absolvent: Mihai Gabriel Raiu

LOCUL DOCUMENTAIEI: Universitatea Tehnic Cluj-Napoca

CONSULTANI: Asist. Ing. Lucia Vcariu

DATA EMITERII TEMEI: 1.10.2008

TERMEN DE PREDARE: 19.06.2009

Definirea agenilor n Jadex..........................................................................40

SPECIFICAII I ARHITECTUR SISTEM............................................................41

PUNERE N FUNCIUNE I REZULTATE EXPERIMENTALE..........................64

7.1.2 Cerine Software...................................................................................................64

Acest capitol prezint motivaiile temei, ncadrarea temei n domeniile pe care le

Ultimii ani au fost martorii avansrii rapide a tehnologiilor ce privesc casele

Tabel 2.1 Clasificarea roboilor utilizai n locuine

Figura 2.1 Tendina n vnzarea roboilor de cas pe piaa japonez

Sisteme senzitive la context

Sistem Senzitiv la Context

Informaia perceptual despre mediu este ingredientul esenial al sistemelor senzitive

Paradigma Ubiquitous Computing

n [20] se d urmtoarea caracterizare pentru UC. Astfel paradigma permite

Universitatea Tehnic din Cluj-Napoca

Ageni senzitivi la context

Construirea aplicaiilor sistemelor senzitive la context i omniprezente din domeniul

Convingerile agentului se deosebesc de cunotinele lui, deoarece acestea nu trebuie

Arhitecturi de sisteme senzitive la context

Modelul arhitectural stratificat Context Stack

Figura 2.2 Modelul arhitectural Context Stack

ncepnd de la acest nivel, toate nivelele se bazeaz pe un model de context comun,

Acest nivel se ocup de agregarea datelor contextuale, adunnd datele de la senzori

Cnd se stabilete un model de context pentru a reprezenta i prelucra contexte,

Arhitecturi de sisteme distribuite senzitive la context

Au fost cteva ncercri de a construi astfel de sisteme de roboi i monitorizare prin

domeniul tehnologiilor Web, i o metod de planificare preluat din inteligena artificial,

Figura 2.3 Comparaie ntre SemanticURS i sistemele tradiionale

Serviciile Web Semantice

Figura 2.4 Clasele componente ale unei ontologii de tip OWL-S

Service Profile aceast component a unei ontologii OWL-S specific ce face

Arhitectura Serviciilor Web Semantice

vocabularul OWL-S, n ontologiile procesului OWL-S, pentru ca modulul de alctuire a

Figura 2.5 Arhitectura detaliat a Semantic URS

Figura 2.6 Procedura de integrare automat a unui agent SemanticURS

Medii de dezvoltare ale aplicaiilor senzitive la context

Java Context Awareness Framework (JCAF) [36] este un mediu de dezvoltare

Figura 2.7 Diagrama de interaciune ntre modulele componente ale JCAF

Figura 2.8 Arhitectura general cu diagrame de colaborare a JCAF

Mai exist i alte medii de dezvoltare a aplicaiilor senzitive la context, cu diferite

Aplicaii n domeniul caselor inteligente

n aceast seciune va fi prezentat proiectarea i implementarea unei arhitecturi

Argumentarea ontologiilor (Ontologic Reasoning) este un pas foarte important n

Figura 2.9 Arhitectura de tip OSGi pentru o cas senzitiv la context

Pentru a obine partajarea cunotinelor i inferenele logice necesare informaiilor

Dificulti i riscuri ntmpinate n crearea aplicaiilor

Informaia de context poate fi achiziionat de la surse multiple distribuite i

Proiecte ample de cercetare n desfurare

Dintre proiectele ample de cercetare n legtur cu casele inteligente, i mai general cu

Modelarea formal a contextelor

Baze de date de cunotine

Figura 3.10 Cazul general de programare a unui agent bazat pe cunotine

Programul iniial al agentului, nainte de a primi informaii de la mediu, este construit

n seciunea anterioar am prezentat agenii bazai pe cunotine. Aceste cunotine