Universitatea Transilvania din BraşovŞcoala Doctorală Interdisciplinară

Centrul de cercetare: Sisteme pentru Controlul Proceselor

Ing. Cosmin-Septimiu Nechifor

Cercetări privind mecanismele cognitive bazate pe

constrângeri şi aplicarea acestora la sistemele de control

autonomice

Applied research regarding constraints based cognitive

computing mechanisms and their usage on autonomic

control systems

Conducător ştiinţific

Prof. dr. ing. Florin MOLDOVEANU

BRAŞOV, 2016

MINISTERUL EDUCAŢIEI, CERCETĂRII, TINERETULUI ŞI SPORTULUIUNIVERSITATEA TRANSILVANIA DIN BRAŞOV

BRAŞOV, B-DUL EROILOR NR. 29, 500036,TEL. 0040-268-413000, FAX 0040-268-410525

RECTORAT

D-lui (D-nei) ……….........................................................................................................

COMPONENŢAcomisiei de doctorat

numită prin ordinul Rectorului Universităţii Transilvania din BraşovNr. 7723 din 17.11.2015

PREŞEDINTE:

Conf. Univ. Dr. Ing. Carmen GERIGANDecan al facultăţii de Inginerie Electrică şi Ştiinţa CalculatoarelorUniversitatea Transilvania din Braşov

CONDUCĂTOR ŞTIINŢIFIC:

Prof. univ. dr. ing. Florin MOLDOVEANUUniversitatea Transilvania din Braşov

REFERENŢI:

Prof. univ. dr. ing. Ioan SALOMIEUniversitatea Tehnică din Cluj-Napoca

Prof. univ. dr. ing. Decebal POPESCUUniversitatea Politehnică din Bucureşti

Prof. univ. dr. ing. Sorin-Aurel MORARUUniversitatea Transilvania din Braşov

Susţinerea publică a tezei de doctorat va avea loc în data de 14.01.2016, la ora 12.00,în copul V al Universităţii Transilvania din Braşov, str. Mihai Viteazu nr. 5, etajul III,sala V III 9.

Eventualele aprecieri sau observaţii asupra conţinutului lucrării vă rugăm să letransmiteţi în timp util, pe adresa de e-mail septimiu.nechifor@siemens.com.

Totodată vă invităm să luaţi parte la şedinţa publică de susţinere a tezei de doctorat.

Vă mulţumim.

ro1v0340

Text Box

157

Content

1 Introduction 1

1.1 Description of the domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 The opportunities of the research topic . . . . . . . . . . . . . . . . . . . . 2

1.3 The Ph.D. thesis objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 The Ph.D. thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Dissemination activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Autonomic computing based control systems 9

2.1 Principles. The analogy with the nervous autonomic system . . . . . . . . 9

2.2 The self* functions. The MAPE-K model . . . . . . . . . . . . . . . . . . . 11

2.2.1 The MAPE-K model . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Autonomic networking as particular case of autonomic computing . . . . . 17

2.3.1 The control loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 Rules and models for operation . . . . . . . . . . . . . . . . . . . . 21

2.3.3 Knowledge modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.4 The feedback loop implementation . . . . . . . . . . . . . . . . . . 23

2.4 Known limitation. The CAP theorem . . . . . . . . . . . . . . . . . . . . . 24

2.5 Implementations of autonomic functions . . . . . . . . . . . . . . . . . . . 25

2.6 The autonomic management of autonomic systems. Overlay systems . . . . 29

2.7 Cognitive functions in autonomic systems . . . . . . . . . . . . . . . . . . . 30

2.7.1 Cognitive functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.2 Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7.3 The connection between autonomic computing and cognitive functions 33

vii

viii Content

2.7.4 Machine learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Usage of MAPE-K model on distributed environments 39

3.1 Support scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Distributed autonomic environment . . . . . . . . . . . . . . . . . . . . . . 42

3.3 The architecture of autonomic distributed control system . . . . . . . . . . 42

3.3.1 Analogia cu sistemele clasice de reglare . . . . . . . . . . . . . . . . 44

3.3.2 Monitoring and analysis mechanisms . . . . . . . . . . . . . . . . . 46

3.3.3 Planning mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3.4 Execution mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3.5 Execution and communication environments for autonomic nodes . 54

3.3.6 Functional patterns and reuse mechanisms . . . . . . . . . . . . . . 56

3.3.7 Knowledge bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 The monitoring step of the autonomic distributed nodes 67

4.1 System knowledge and real world knowledge . . . . . . . . . . . . . . . . . 67

4.2 Service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.3 Use CEP for monitoring the autonomic nodes . . . . . . . . . . . . . . . . 72

4.3.1 Complex event processing . . . . . . . . . . . . . . . . . . . . . . . 74

4.3.2 System perception for the distribution systems . . . . . . . . . . . . 78

4.3.3 Real world perception for the delivery system . . . . . . . . . . . . 84

4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5 Autonomic nodes recon�gurations. Usage of constraints programming 93

5.1 Constraints systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.1.1 Constraints de�nition. Models . . . . . . . . . . . . . . . . . . . . . 95

5.1.2 Constraints solving . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.1.3 Algorithms for constraints solving . . . . . . . . . . . . . . . . . . . 100

5.1.4 Models and platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.2 Distributed autonomic nodes con�guration for logistics scenario . . . . . . 104

Content ix

5.2.1 Locations sequence selection for a distribution agent . . . . . . . . . 104

5.2.2 Planning of logistics scenario . . . . . . . . . . . . . . . . . . . . . . 108

5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6 Cognitive mechanisms and knowledge base 111

6.1 Cognitive mechanisms. Introduction . . . . . . . . . . . . . . . . . . . . . . 111

6.2 Prediction models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2.1 Data sets schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2.2 Data preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.2.3 Time series prediction models . . . . . . . . . . . . . . . . . . . . . 114

6.2.4 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.3 Knowledge bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.3.1 Monitoring patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.3.2 Planning patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.3.3 Scheduling and execution patterns . . . . . . . . . . . . . . . . . . . 123

6.3.4 Semantic description of SCDA resources . . . . . . . . . . . . . . . 125

6.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

7 Experimental validation 129

7.1 Platforms used for architecture validation . . . . . . . . . . . . . . . . . . . 130

7.1.1 CoReMo platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

7.1.2 Logistics domain emulator . . . . . . . . . . . . . . . . . . . . . . . 131

7.2 Testing of monitoring and analysis module . . . . . . . . . . . . . . . . . . 132

7.3 Testing of recon�guration module for autonomic nodes . . . . . . . . . . . 133

7.4 Testing of prediction models . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.5 Complete prototype testing . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

8 Conclusions 139

8.1 Personal contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.2 Dissemination of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

x Content

8.3 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

A Prototype for distributed autonomic systems 149

A.1 Monitoring of the termo-sensitive materials distribution process . . . . . . 149

A.2 Integration of ML models into the monitoring precess . . . . . . . . . . . . 153

References 157

List of �gures 171

Capitolul 1.

Introducere

1.1 Scurt  introducere în domeniu

În toat  istoria sa intens  ³i plin  de provoc ri, tehnologia ce adreseaz  procesarea,

comunicarea ³i stocarea datelor a oferit ³i ofer  imaginea unei continue diversi�c ri, ete-

rogenit µi ³i distribuiri în toate sferele vieµii. Interacµia dintre tehnologie ³i modul în care

ea este folosit  genereaz  inovaµie ³i asimilarea în funcµiuni a "naturalului", a soluµiilor

³i exemplelor oferite de lumea vie. Precum cum observa în cazul indivizilor a diferite

specii cât ³i grupurile sociale formate din oameni ori animale, sistemele tehnice eterogene

presupun o complexitate sporit  a controlului ³i o capacitate continu  de a reacµiona ori

de a înv µa, infera ³i a prezice, de a se adapta în faµa mediului în schimbare. De aseme-

nea, devine critic  tratarea performanµelor variabile ale sistemelor participante de ordin

inferior ori de a reacµiona în faµa pericolului. Din acest motiv, înµelegerea ³i adoptarea

unor soluµii potrivite optimiz rilor funcµionale ³i de costuri devine esenµial  pentru func-

µionarea optim  a acestor artefacte complexe. Pornind de la capabilit µi disponibile la

nivel de nod ³i pân  la cele expuse de grupuri de noduri ce coopereaz , se poate observa

oportunitatea de a aplica modele inspirate din sistemul nervos neurovegetativ (vom folosi

1

2 Capitolul 1. Introducere

termenul englezesc, autonomic) , responsabil cu menµinerea incon³tient  a funcµiunilor

vitale asociate. Dac , de exemplu, în cazul anatomiei umane se poate observa rolul sis-

temului autonomic în ceea ce înseamn  controlul b t ilor inimii, al respiraµiei în timpul

somnului, al reacµiei sistemului imunitar prin febr  în cazul unei boli, în cazul sisteme-

lor tehnice putem vorbi de indicatorii de performanµ  ai acestora cum ar � num rul de

tranzacµii �nalizate cu succes într-un interval de timp, sesizarea ³i reacµia la atacuri de

tip "Distributed Denial of Services", supraînc lzirea componentelor, etc.

Sistemele IT complexe au devenit parte din viaµa noastr , �e c  ne referim la industrie,

transport, s n tate, infrastructur  public  precum sunt c ile ferate, reµelele de utilit µi

ori echipamente domestice. În toate formele în care tehnologia ne este livrat  ³i conec-

tat  la procese: sisteme cloud, centre de date, sisteme embedded, computere personale,

televizoare ori telefoane avem a³tept ri similare cu privire la disponibilitate, siguranµa

funcµion rii, rezistenµa la ³ocuri ori atacuri cibernetice. Mai mult, datorit  interconec-

t rii masive ne a³tept m ca aceste funcµionalit µi sa se manifeste de la sine, automat ³i

adaptate contextului.

1.2 Actualitatea ³i oportunitatea temei

Sistemele de calcul ³i comunicaµie implic , prin natura misiunii lor, un volum crescut

de atenµie cu privire la funcµionarea lor corect . Presiunea asupra calit µii con�gur rii,

administr rii ³i mentenanµei lor este cu atât mai mare cu cât corectitudinea trebuie s 

�e asumat  faµ  de un context de execuµie în continu  schimbare. Acest fapt introduce

un stres suplimentar în ceea ce înseamn  atât adaptarea percepµiei mediului de utilizare

cât ³i a înµelegerii acestuia ori adapt rii corecte a comportamentului sistemului, iar în

cazul în care sistemele considerate sunt distribuite ³i conµin atât actori IT cât ³i non-IT

necesitatea adapt rii paradigmei controlului este ³i mai important .

Sistemele de control autonomice vin s  ofere o perspectiv  practic  în ceea ce înseamn 

auto-reglajul adaptat contextului de lucru. Este un concept ce abordeaz  ³i încorporeaz 

complexitatea în managementul sistemelor ³i al c rui efect imediat îl vedem în ceea ce

înseamn  în ultiimii 15 ani, sistemele SOA (eng. Service Oriented Architectures, ar-

hitecturi orientate pe servicii) ori cele cloud. Dup  rezultatele evidente documentate ³i

experimentate în domenii precum managementul reµelelor de telecomunicaµii, sistemele de

1.3. Obiectivele tezei 3

baze de date enterprise ori infrastructurile exclusiv IT, controlul autonomic poate aborda

integrarea cu lumea real , a a³a numitelor sisteme ciber-�zice ori a celor aparµinând de

arhitecturi din Internetul Lucrurilor (eng. Internet of Thing, IoT).

Exist  un num r de iniµiative care dezvolt  în cercetarea academic  ori industrial  di-

ferite abord ri ale capabilit µilor autonomice atât în etapa de proiectare ³i implementare

(design time) cât ³i în etapa de execuµie efectiv  (run time), �ecare abordare favorizând

anumite tipuri de sisteme ³i domenii de aplicaµie. Din acest motiv, g sirea unui mod

�exibil capabil s  conduc  la un model productiv ³i care s  extrag  corect ³i e�cient ce-

rinµele, plus adaptivitatea necesar , reprezint  un subiect relevant, la intersecµia ³tiinµelor

controlului, ingineriei software ³i a sistemelor hardware con�gurabile.

Tema propus  în tez  încorporeaz  într-o arhitectur  autonomic  distribuit  meca-

nisme ce µin de calculul cognitiv sprijinit de o monitorizare continu , adaptiv . Arhitec-

tura propus  adreseaz  ³i acoper  cazuri de încorporare a lumii reale în Internetul Lu-

crurilor. Tematica identi�cat  este susµinut  ca ³i necesitate de faptul c  a fost abordat 

într-un num r de 9 proiecte de cercetare FP7 ³i Horizon 2020, fapt ce certi�c  necesitatea

³i validitatea conceptelor considerate ³i utilizate.

1.3 Obiectivele tezei

Ultimele decenii au cunoscut apariµia ³i dezvoltarea unui num r semni�cativ de teh-

nologii orientate pe rezolvarea punctual  a unor probleme cu o arie larg  de aplicabilitate:

con�gurarea sigur  a sistemelor de scar  larg  precum sunt cele de interconectare a ele-

mentelor de telecomunicaµii sau a elementelor de control pentru c i ferate ori a plani�c rii

ordinii de execuµie a operaµiilor de producµie în fabrici, monitorizarea performanµei sis-

temelor bazat  pe evenimente ³i procesarea acestora, precum sunt sistemele de "agenµi

robotici" implicaµi în pieµele �nanciare (algorithmic trading) sau aplicaµiile pe baz  de

prelucrare statistic , Data Mining, Machine learning, Deep Learning în cazul optimiz rii

datelor disponibile masiv, variabile ³i cu ritmuri impredictibile de generare - Big Data.

În acela³i timp, obiectele conectate - Internet of Things ³i sistemele de calcul de tip

Cloud au adus la dispoziµia celor ce creeaz  aplicaµii ³i servicii dou  tipuri de resurse cri-

tice: putere de calcul ³i de stocare nelimitate, precum ³i disponibilitatea aproape în timp

real a datelor primite de la senzori masiv distribuiµi ³i respectiv comanda unor infrastruc-

4 Capitolul 1. Introducere

turi de lucru diverse. Aceste aspecte genereaz  o schimbare major  de paradigm  în ceea

ce înseamn  relaµia între procese �zice, controlul lor ³i infrastructura de comand . Devine

evident c  fragmentarea �zic  ³i eterogenitatea genereaz  provoc ri majore administr rii

corecte, coerente ³i adaptive a sistemelor IT de suport.

În acest context, teza prezint  investigaµiile întreprinse de autor într-un num r de pro-

iecte de cercetare precum ³i rezultatele asociate soluµiilor propuse. Teza este fundamentat 

pe tehnologii suport cu grad diferit de maturitate a c ror combinare ³i extindere repre-

zint  una din contribuµiile inovative ale tezei. Nivelul de oportunitate al subiectului ales

este reprezentat de num rul ridicat de proiecte de cercetare cu �nanµare european  (FP7

³i Horizon 2020) în care obiectivele tezei au fost abordate ³i investigate. Se prezint  un

model de arhitectur  autonomic  distribuit  ³i se detaliaz  un caz complex analizat din

domeniul Internet of Things destinat Ora³elor Inteligente.

1.4 Prezentarea capitolelor

Structura tezei este urm toarea:

Capitolul 1 face o introducere general  a temei precum ³i a modului în care a fost ales

subiectul tratat.

Capitolul 2, intitulat Sisteme de control bazate pe calcul autonomic prezint  o

descriere în detaliu a modului de construcµie al sistemelor autonomice precum ³i a principi-

ilor ce le guverneaz . S-au prezentat ³i argumentat în detaliu logica caracteristicilor auto*

(Self*) ³i modul complementar în care acestea contribuie la automanagementul sistemelor.

În continuare, a fost detaliat modelul MAPE-K ³i s-a documentat modul în care �ecare

etap  a modelului contribuie la realizarea funcµiunilor generale. În capitol se trateaz ,

de asemenea, extensia modelelor Autonomic Computing spre Autonomic Networking ³i a

schimb rilor necesare adapt rii la mediul distribuit. Ultima parte a capitolului abordeaz 

detalii referitoare la implementarea buclelor de control, a reacµiei ³i s-au expus câteva

exemple de arhitecturi autonomice implementate industrial ori experimental. În �nal au

fost introduse funcµiile cognitive ³i s-a expus relaµia acestora cu modelul de reglaj speci�c

controlului autonomic.

Capitolul 3, intitulatUtilizarea modelului MAPE-K în medii distribuite descrie

în detaliu scenariul suport considerat pentru demonstrarea arhitecturii propuse, precum

1.4. Prezentarea capitolelor 5

³i structura acestei arhitecturi. Au fost detaliate considerentele ce pot � analizate în con-

textul mediului distribuit pentru modelul MAPE-K, precum ³i elementele de tehnologie

potrivit a � selecµionate pentru utilizare. În continuare au fost prezentate tiparele func-

µionale identi�cate în cadrul arhitecturii ³i modul în care acestea pot � asamblate pentru

a livra funcµionalitatea necesar .

Capitolul 4, intitulatMonitorizarea ³i analiza st rii nodurilor distribuite auto-

nomice trateaz  detaliile speci�ce modului de concepere ³i implementare destinate asi-

mil rii cuno³tinµelor din sistemele IT monitorizate ³i precum si din lumea real . Au fost

introduse formalismele asociate si cercetate in proiectul iCORE, ³i s-a detaliat modul în

care un sistem autonomic distribuit î³i construie³te mecanisme de percepµie contextual 

asupra mediului (context awareness), în toate aspectele relevante pentru leg tura între

resurse, date ³i procese. Capitolul prezint , de asemenea, aspecte ce µin de cerinµele non-

funcµionale ³i modul în care acestea se re�ect  în serviciile oferite ³i contractele lor (Service

Level Agreements - SLA). În capitol se introduce tehnologia aleas  pentru implementarea

monitoriz rii - procesarea evenimentelor complexe - Complex Event Processing (CEP),

CEP ³i ilustreaz  modul cum se poate utiliza aceast  tehnologie în cadrul scenariului ales.

Capitolul 5, intitulat Utilizarea constrângerilor pentru recon�gurarea noduri-

lor autonomice distribuite introduce mecanismele de plani�care bazate pe rezolvarea

constrângerilor programabile, modelarea ³i rezolvarea acestora. Cu ajutorul scenariului

suport a fost evidenµiat modul în care acµiunile unui sistem distribuit sunt plani�cate ori

replani�cate spre execuµie, precum ³i modul cum acest proces devine adaptiv cu ajutorul

monitoriz rii ³i al analizei de context.

Capitolul 6, intitulat Mecanisme cognitive ³i baze de cuno³tinµe a prezentat

modul in care tehnologiile cognitive (bazate în principal pe tehnici de înv µare) pot �

executate în contextul unui mediu de control distribuit. Pe baza implement rii propuse

în proiectul iCORE, a fost detaliat modul în care etapele de monitorizare ³i analiz  se

adapteaz  mediului prin combinarea tehnicilor de CEP cu cele de Machine Learning (ML).

În continuare, în capitol a fost prezentat suportul oferit de c tre diferite modele de repre-

zentare a cuno³tinµelor atât pentru modelarea proceselor cât ³i pentru cea a resurselor.

În acest scop a fost introdus suportul semantic asociat necesar descoperirii automate a

resurselor necesare execuµiei unui proces.

6 Capitolul 1. Introducere

Capitolul 7, intitulat Validare experimental  descrie platforma pe care s-a realizat

implementarea scenariului suport. Au fost trecute în revist  opµiunile tehnice alese pentru

�ecare funcµionalitate precum ³i rezultatele experimentale obµinute.

Capitolul 8 prezint  concluziile generale ale tezei ³i expune câteva din subiectele con-

siderate a � de interes pentru investigaµii ulterioare. Parte din subiectele prezentate fac

deja parte din temele unor cercet ri industriale dar ³i subiecte ce µin de proiecte Horizon

2020 în derulare ori care vor începe în perioada imediat urm toare.

1.5 Lista publicaµiilor

Lista lucr rilor publicate pe parcursul elabor rii tezei de doctorat în strict  leg tur 

cu subiectul tezei:

a. Lucr ri ISI:

� E. Z. Tragos, V. Angelakis, A. G. Fragkiadakis, D. Gundlegard, S. Nechifor, G.

C. Oikonomou, H. C. Pohls, and A. Gavras, �Enabling Reliable and Secure IoT-

based Smart City Applications�, in 2014 IEEE International Conference on Pervasive

Computing and Communication Workshops, PerCom 2014 Workshops, Budapest,

Hungary, March 24-28, 2014. IEEE, 2014, pp. 111-116.

� S. Nechifor, B. Tarnauca, L. Sasu, D. Puiu, �Autonomic Monitoring Approach

based on CEP and ML for Logistic of Sensitive Goods�, 18th IEEE International

Conference on Intelligent Engineering Systems (INES), Tihany, Ungaria, 2014�pp:

67-72,.

� S. Nechifor A. Petrescu, D. Damian, D. Puiu, and B. Tarnauca, �Predictive Ana-

lytics based on CEP for Logistic of Sensitive Goods�, 14th International Conference

on Optimization of Electrical and Electronic Equipment OPTIM, Brasov, Romania,

May 2014.

� J. Poncela, P. Vlacheas, R. Giafreda, S. De, M. Vecchio, S. Nechifor, R. Barco, M.

C. A. Torres, V. Stavroulaki, K. Moessner, and P. Demestichas, �Smart Cities via

Data Aggregation�, Wireless Personal Communications, vol. 76, no. 2, 2014, pp.

149-168.

1.5. Lista publicaµiilor 7

� A. Gîrbea, C. Suciu, S. Nechifor, and F. Sisak, �Design and Implementation of

a Service-Oriented Architecture for the Optimization of Industrial Applications�,

IEEE Transactions on Industrial Informatics, Vol. 10, No. 1, 2014, pp. 185-196.

� A. Gîrbea, S. Nechifor, F. Sisak, �E�cient Address Space Generation for an OPC

UA Server�, Software Practice and Experince, Vol 42, Issue 5, May, 2014, pp. 543-

557.

� A. Gîrbea, S. Nechifor, F. Sisak, and L. Perniu, �Design and Implementation of

an OLE for Process Control Uni�ed Architecture Aggregating Server for a Group of

Flexible Manufacturing Systems�, IET Software, vol. 5, no. 4, 2011, pp. 406-414.

� I. Cobeanu, B. Tarnauca, S. Nechifor, and V. Comnac, �Real-time Scheduling of

Mobile Agents Using Answer Set Programming�, 13th International Conference on

Optimization of Electrical and Electronic Equipment OPTIM, Brasov, Romania,

May, 2012, pp. 1505-1510.

� A. Manzalini, P. H. Deussen, S. Nechifor, M. Mamei, R. Minerva, C. Moiso,

A. Salden, T. Wauters, and F. Zambonelli, �Self-Optimized Cognitive Network of

Networks�, Oxford Computer Journals, Vol. 54, No. 2, 2011, pp. 189-196.

b. Lucr ri BDI

� S. Nechifor, D. Puiu, B. Târnauca, and F. Moldoveanu, �Prescriptive Analytics

based Autonomic Networking for Urban Streams Services Provisioning�, IEEE 81st

Vehicular Technology Conference, VTC Spring 2015, Glasgow, United Kingdom,

11-14 May, 2015. IEEE, 2015, pp. 1-5.

� D. Ardagna, E. D. Nitto, G. Casale, D. Petcu, P. Mohagheghi, S. Mosser, P. Mat-

thews, A. Gericke, C. Ballagny, F. D'Andria, C. Nechifor, and C. Sheridan, �Mo-

daclouds: a Model-Driven Approach for the Design and Execution of Applications

on Multiple Clouds�, Proceedings of the 4th International Workshop on Modeling in

Software Engineering, MiSE 2012, Zurich, Switzerland, June 2-3, 2012, pp. 50-56.

� G. Baldini, R. R. V. Prasad, A. R. Biswas, K. Moessner, M. Eteläperä, J. Soininen,

S. Nechifor, V. Stavroulaki, and P. Vlacheas, �A cognitive Management Framework

8 Capitolul 1. Introducere

to Support Exploitation of the Future Internet of Things�, Scalable Computing:

Practice and Experience, vol. 13, no. 2, 2012.

c. Capitol de carte publicat  în editur  internaµional 

� S. Nechifor, D. Puiu, B. Tarnauca, and F. Moldoveanu, �Autonomic Aspects of

IoT Based Systems: A Logistics Domain Scheduling Example�, Interoperability and

Open-Source Solutions for the Internet of Things, ser. Lecture Notes in Computer

Science, I. Podnar Zarko, K. Pripuzic, and M. Serrano, (Eds.), Springer Internatio-

nal Publishing, 2015, Vol. 9001, pp. 153-168.

� V. Foteinos, D. Kelaidonis, G. Poulios, V. Stavroulaki, P. Vlacheas, P. Demesti-

chas, R. Giareda, A. R. Biswas, S. Ménoret, G. Nguengang, M. Eteläperä, S. Ne-

chifor, M. Roelands, F. Visintainer, and K. Moessner, �A Cognitive Management

Framework for Empowering the Internet of Things�, The Future Internet - Future

Internet Assembly 2013: Validated Results and New Horizons, ser. Lecture Notes

in Computer Science, A. Galis and A. Gavras, (Eds.), Vol. 7858. Springer, 2013,

pp. 187-199.

� S. Nechifor �How to Manage and Search/Retrieve Information Objects�, Archi-

tecture and Design for the Future Iinternet: 4WARD PROJECT�, Book Series:

Signals and Communication Technology, Edited by: L.M. Correia; H. Abramowicz;

M. Johnsson, (Eds.); et al., 2011, pp. 201-223.

Capitolul 2.

Sisteme de control bazate pe calcul

autonomic

Acest capitol conµine o descriere detaliat  a argumentelor, funcµiunilor identi�cate, a

modului curent de înµelegere, de implementare a controlului autonomic abordând de ase-

menea posibilele aspecte cognitive ce îl conduc.

2.1 Principii. Analogia cu sistemul nervos autonomic

Ultimii 30 de ani au adus schimb ri excepµionale în modul în care producem ³i utiliz m

tehnologia. Începând cu capacitatea intrinsec  de procesare, stocare ³i comunicare a

crescut într-o m sur  cel puµin similar  necesitatea de a controla sigur dar, totu³i, în mod

�exibil, adaptabil sistemele tehnice ³i interacµiunea acestora cu factorul uman ³i mediul în

care sunt folosite în general. Încercând s  separ m logic spaµiul sistemelor implementate

putem observa existenµa unei specializ ri pe dou  zone: cea a infrastructurii reprezentat 

de hardware, software-ul sistemelor de operare (putând ad uga apoi sistemele de baze de

date, de indexare a conµinutului, driverele, etc.) ³i cea a aplicaµiilor.

Drept consecinµ , un set speci�c de funcµionalit µi în zona managementului sistemelor

9

10 Capitolul 2. Sisteme de control bazate pe calcul autonomic

a devenit critic de a � pus la dispoziµie începând cu capacitatea de a asimila diversitatea

f r  s  sacri�c m disponibilitatea serviciilor oferite, balansarea înc rc rii cu task-uri de

procesare între diferite noduri ori repornirea automat  cu conservarea sesiunilor pentru

un server web, de exemplu. Per total funcµiunea poate � numit  automanagement (self-

management) ³i implic  gestiunea dup  un set de norme (policies) a funcµiilor alocate

într-un nod de calcul considerat.

Dup  cum se observ , pentru primele dou  familii de funcµionalit µi modelate siste-

mele imit  un comportament intenµional, con³tient la nivelul individului sau al grupului cu

scopul realiz rii unui obiectiv dat. Pentru cazul dat, al infrastructurii sistemelor IT, func-

µionalit µile a³teptate au fost ³i sunt similare celui oferit de sistemul nervos autonomic,

sistem ce controleaz  staza, funcµiile re�ex ale organismului. Funcµia de baz  a oric -

rei capabilit µi autonomice este bucla de control care colecteaz  detalii din interiorul ³i

exteriorul sistemului ³i reacµioneaz  în baza unor speci�caµii. De³i ³tiinµa sistemelor docu-

menteaz  numeroase tipuri de bucl  de control, sistemele autonomice refer  fundamental

patru categorii de funcµii: autocon�gurare (self-con�guring), autovindecare (self-healing),

autooptimizare (self-optimizing) ³i autoprotecµie (self-protecting). În cele ce urmeaz  se

vor prezenta principiile de baz  ale implement rii ³i funcµion rii sistemelor autonomice

precum ³i funcµiunile auxiliare considerate.

2.2 Functii self*. Modelul MAPE-K

Conceptul de baz  al calculului autonomic a fost prezentat prima dat  de c tre cerce-

t torii de la IBM în 2001 ³i ra�nat formal doi ani mai târziu în [1], [2]. Scopul principal al

acestei iniµiative a fost ³i este oferirea de servicii c tre utilizatori la un nivel de siguranµ 

³i transparenµ  a funcµion rii imposibil de atins prin implicarea intensiv  ³i continu  a

controlului uman. Altfel spus, automanagementul î³i propune s  automatizeze sarcini

complexe, inclusiv modele de decizie avansate încercând s  probeze îmbun t µirile m -

surând un num r de metrici precum timpul de execuµie al unui program, corectitudinea

rezultatelor ori costul asociat (costul spaµiului închiriat în cazul folosirii unui Data Center

sau costul energiei consumate).

Funcµiile auto* (self*) anterior enumerate sunt complementare ³i acoper  toate etapele

de viaµ  ale unui sistem funcµional: design, implementare, instalare, modi�care, revenirea

2.2. Functii self*. Modelul MAPE-K 11

din eroare. Ca ³i funcµionalitate unic  �ecare acoper  urm toarele capabilit µi:

- Autocon�gurarea� are ca scop capacitatea de a menµine funcµional mixul de har-

dware, software sistem ³i software de aplicaµie utilizat coerent. Ca ³i prim  cerinµ ,

este de a³teptat ca un sistem autonomic s  î³i identi�ce propriile propriet µi ale unei

noi componente ³i s  utilizeze un posibil set de cuno³tinµe (policies) de nivel înalt

pentru a face o con�gurare corect  a componentei.

- Autooptimizarea� reprezint  o funcµionalitate complementar  autocon�gur rii ce

trebuie s  �e înµeleas  în termeni de ajustare a parametrilor de con�gurare. În

cazul acestei componente devine critic modelul semantic al cuno³tinµelor.

- Autovindecarea � Dac  autocon�gurarea ³i autooptimizarea sunt esenµiale etapei

de iniµializare ³i pornire a unui sistem, de³i nu sunt executate strict doar în faza

iniµial , sistemul are nevoie de un sistem de monitorizare e�cient ³i detaliat.

- Autoprotecµia � În mod uzual autoprotecµia reprezint  setul de activit µi comple-

mentar autovindec rii, dar luând în considerare posibile cauze externe. Din punct

de vedere logic putem observa c  exist  o similaritate mare între elasticitatea ante-

rior de�nit  a sistemului ³i capacitatea de management al disfuncµionalit µilor (fault

management).

2.2.1 Modelul MAPE-K

Pentru a putea implementa componentele funcµionale descrise mai sus modelul concep-

tual propus de IBM identi�c  un set de tipuri de elemente de baz : senzori, interpretori,

controlori, efectori.

În viziunea prezentat  în [3], [4] ³i [5] implementarea unui sistem autonomic identi�c 

un num r de manageri asociaµi �ec rei zone funcµionale. În scopul implement rii ma-

nagerilor autonomici se de�ne³te bucla de control a acestora ca �ind compus  din (vezi

�g.2.1):

- Monitorizare � Funcµia de monitorizare este responsabil  de gestionarea diferiµilor

senzori care ofer  informaµii cu privire la performanµa sistemului.

- Analiza � Funcµia de analiz  este responsabil  pentru procesarea informaµiei cap-

tate în faza de monitorizare având ca rezultat evenimente complexe ca ³i conµinut

12 Capitolul 2. Sisteme de control bazate pe calcul autonomic

de informaµie (cum ar � detectarea tendinµei de înc lzire a unei componente moni-

torizate);

- Plani�care � Funcµia de plani�care este responsabil  de selectarea acµiunilor ³i a

ordinii lor, necesar a � aplicate cu scopul de a corecta posibilele deviaµii de la planul

operaµional (care poate � parte a unui contract de furnizare a unui serviciu). Acest

proces se bazeaz  pe cuno³tinµe de nivel înalt care descriu planul de adaptare al

sistemului.

- Execuµia � Funcµia de plani�care aplic  acµiunile re�ectate de subsistemul de plani-

�care asupra elementelor afectate. Adiµional, cuno³tinµele comune includ informaµii

relevante ³i pentru celelalte subcomponente.

Figura 2.1: Un model generic MAPE-K.

Modelul MAPE-K generalizeaz  diferite posibile strategii de control ³i distribuµie a

funcµionalit µilor aferente. Din aceast  cauz  el trebuie considerat ca �ind un model de

sistem, nu ca o combinaµie obligatorie de funcµionalit µi dependente de o implementare

speci�c .

2.3 Autonomic networking ca ³i caz de autonomic computing

Sistemele de calcul distribuite, în reµea, au devenit esenµiale pentru aplicaµiile ³i servi-

ciile zilelor noastre, deschizând oportunit µi de conectare ³i control unor terminale etero-

2.3. Autonomic networking ca ³i caz de autonomic computing 13

gene, atât din punct de vedere al capabilit µilor informatice (calcul, procesare ³i stocare

de date) cât ³i în ceea ce prive³te protocoalele de conectare suportate. Trebuie observat

faptul c  pe lâng  avantajele evidente ale livr rii de servicii de c tre noduri de calcul

corelate o astfel de abordare implic  o cre³tere semni�cativ  a complexit µii activit µii de

management a comportamentului ³i st rii de funcµionare al noului sistem compus [11].

În timpul investigaµiilor f cute pentru aceasta tez , funcµiuni de monitorizare distri-

buit  au fost evaluate în cursul proiectului FP7 ICT MODAClouds (corespunz toare unei

abord ri Model Driven în ceea ce înseamn  modelul de cuno³tinµe) ori în domeniul teh-

nicilor cognitive destinate gestion rii platformelor de tip Internet of Things în proiectele

FP7 ICT iCORE [15], Cosmos [16] ³i CityPulse [17]. Rezultatele echipei de cercetare al

c rei membru sunt au contribuit la analiza, proiectarea ³i implementarea unor rezultate

relevante [18], [19]. Ca ³i efort preliminar acestor proiecte în [20] s-a demonstrat modul în

care sistemele pe baz  de constrângeri pot contribui la consistenµa unui mediu distribuit

SOA.

2.3.1 Bucla de control

Modelele de cuno³tinµe folosite de c tre implement rile de sisteme autonomice nu au

doar rolul de a stabili cum anume î³i reprezint  percepµiile ³i modul de reprezentare

acestea, ci stabilesc ³i scopurile (goal driven) dup  care se conduce ³i îµi face plani�carea.

În acest sens bucla de control are rolul de a asigura prelevarea prin senzori a infor-

maµiilor relevante pentru evaluarea consecinµelor planurilor curente ³i adapt rii lor. În

[14] se propune o structur  de lucru conceptual  bazat  pe un set de manageri �ecare cu

un rol ³i o zon  de responsabilitate bine stabilite: context, reguli ³i scopuri (policies and

goals) ³i controlul autonomic efectiv, ra�nat  ca ³i componente speci�ce.

Efectul principal al acestei abord ri este capacitatea de a avea un set de bucle de

control specializate per domeniu având în comun o baz  de cuno³tinµe coerent . O com-

ponent  esenµial  a implement rii unor bucle de control consistente este reprezentat 

de existenµa unor sisteme de monitorizare capabile s  gestioneze intr rile de la senzori.

Sistemul de monitorizare poate � responsabil inclusiv de împachetarea datelor primite

în alarme ³i evenimente complexe, distribuirea selectiv  a acestora ³i oferirea unei pre-

clasi�c ri a lor în funcµie de scopul ³i nivelul de utilitate al datelor în bucla considerat .

14 Capitolul 2. Sisteme de control bazate pe calcul autonomic

Cu scopul de a oferi sisteme productive având capacit µi autonomice, este necesar s  se

implementeze sisteme de monitorizare performante. Tehnici din zona ML pot compensa ³i

îmbun t µi semni�cativ cazurile în care evenimentele detectate sunt incerte sau incomplet

de�nite [21].

2.3.2 Reguli ³i modelarea funcµion rii

Dupa cum s-a speci�cat anterior atât pentru cazul funcµiunilor autonomice la nivel

de nod cât ³i la nivel de reµea, modul în care sistemul î³i modeleaz  starea ³i obiectivele

³i regulile care le exprim  formal, existenµa unui limbaj coerent ³i consistent sunt foarte

importante.

2.3.3 Modelarea cuno³tinµelor

Precum s-a demonstrat în proiectul FP7 ICT iCORE [27], [28], [29], modelarea cu-

no³tinµelor referitoare la resursele unui sistem cunoa³te trei aspecte distincte ³i poate �

considerat un proces de virtualizare al acelor resurse, de generare al unei imagini digitale

cu un ciclu de viaµ  dependent de serviciile ce o folosesc. Asupra datelor ³i serviciilor ex-

puse de resursele observabile prin senzori putem s  aplic m : agregarea lor într-o resurs 

virtual  compus , abstractizare � când se observ  modele comun aplicabile unei familii

de resurse ori îmbog µirea funcµional  ata³ând imaginii digitale cuno³tinµele acumulate în

prealabil prin observaµii ³i reasoning.

2.3.4 Implementarea reacµiei

Scopul buclei de control în sistemele autonomice este atins atunci când sistemul reac-

µioneaz  dup  caz atât asupra ajust rii parametrilor propriilor subcomponente (în cazul

autooptimiz rii, de exemplu, ori pentru cazul când dou  sau mai multe noduri î³i coordo-

neaz  funcµiile interne ori cele oferite) dar ³i asupra exteriorului în cazul autoprotecµiei. În

mod uzual sistemul are de�niµi o serie de efectori/actuatori asociaµi funcµiei de plani�care

din MAPE-K. Se poate observa c  actuatorii într-un sistem autonomic sunt independenµi

de nivelul la care este implementat controlul autonomic. Drept consecinµ  se poate întâm-

pla ca actuatorii s  �e legaµi în cascad  ³i chiar s  �e necesar  implementarea rezolv rii

unor actualiz ri concurente. În astfel de cazuri sistemele autonomice implementeaz  mo-

2.4. Limite cunoscute. Teorema CAP 15

dele cu cozi de procesare ori algoritmi de decizie care coreleaz  mai mult de o decizie în

privinµa actualiz rii.

2.4 Limite cunoscute. Teorema CAP

Sistemele ce încearc  s  ofere capabilit µi de tip autonomic networking se supun acelu-

ia³i tip de provoc ri precum cele enunµate de Teorema CAP [32]. Acest  teorem  speci�c 

faptul c  într-un sistem de calcul distribuit sunt imposibil de garantat simultan: consis-

tenµa � toate nodurile au disponibile acelea³i date la un moment de timp arbitrar ales,

disponibilitatea (availability) � orice cerere c tre o funcµiune expus  prime³te un r spuns

indiferent dac  funcµia este încheiat  cu succes sau nu, ³i toleranµa la partiµionare � sis-

temul va continua s  opereze în ciuda unei partiµion ri arbitrare datorit  erorilor din

reµeaua de comunicaµie.

2.5 Implement ri de funcµii autonomice

De³i funcµiunile descrise anterior au fost demonstrate ca �ind necesare atât în ceea

ce înseamn  autonomic computing cât ³i autonomic networking, implementarea lor real 

prezint  un num r de di�cult µi atât în ceea ce înseamn  execuµia dar mai ales nevoia

de cuno³tinµe specializate din partea dezvoltatorilor. Practica a demonstrat c  pentru

a bene�cia de aspectele autonomice este nevoie de echipe complexe, cu abilit µi multi-

disciplinare ³i de o expertiz  avansat  în a combina funcµiunile autonomice la nivel de

infrastructur  cu cele la nivel de aplicaµie. Putem menµiona ca implement ri de refe-

rinµ  industriale ori destinate cercet rii: IBM DB2 [34], GPAC � General Purpose

Autonomic Computing [13], , FOCALE [35], OpenIOT [36].

2.6 Managementul autonomic al sistemelor distribuite. Sisteme overlay

În ultimii ani cercet rile în domeniul sistemelor distribuite au fost axate în marea lor

majoritate pe realizarea platformelor de tip Cloud. Fie c  vorbim de PaaS (Platform as

a Service), IaaS (Infrastructure as a Service) ori SaaS (Software as a Service), paradigma

cloud a promis disponibilitate practic nelimitat  de stocare, procesare ³i comunicaµie

oriunde, oricând, la cerere. Dup  cum se poate observa, disponibilitatea se înscrie în

provoc rile menµionate de teorema CAP, ³i cer o elasticitate maxim  a implement rii. În

16 Capitolul 2. Sisteme de control bazate pe calcul autonomic

acest sens accentul s-a pus ³i se pune pe paradigme de virtualizare ³i acces al resurselor în

care monitorizarea ³i controlul s  se fac  distribuit ³i cât mai aproape de reacµia în timp

real.

2.7 Funcµii cognitive în sistemele autonomice

Sistemele autonomice prezentate anterior au fost iniµial proiectate pentru a oferi un

control reactiv ³i a permite automatizarea unor strategii administrative formate din pa³i

bine determinaµi. Din acest motiv, dup  cum se poate observa din structurarea funcµiilor

self-*, interesul principal este în garantarea serviciului ³i a disponibilit µii. Totu³i, în

funcµie de gradul de complexitate ³i risc, în buclele de control se pot introduce ³i funcµio-

nalit µi complexe ce pot sau nu include operatorul uman (în funcµie de riscul potenµial al

unei erori).

2.7.1 Funcµii cognitive

Calculul cognitiv (cognitive computing) reprezint  o etap  de sintez  a evoluµiei inte-

ligenµei arti�ciale în care, pe baza tehnicilor de DM, ML ori Natural Language Processing

(NLP) se caut  moduri de complementare a factorului uman ori a proceselor automate

implementate încercând s  se pun  în evidenµ  în datele culese în timpul utiliz rii sis-

temelor posibile corelaµii. Din acest motiv funcµiile cognitive sunt asociate cu metodele

analitice din jurul ecosistemelor Big Data. Acest mod de lucru este asumabil etapei ana-

litice, în special celei prescriptive, ³i are ca efect, în cazul în care aceasta e parte din

MAPE-K adaptarea infrastructurii la evoluµiile aplicaµiilor ³i serviciilor din realitatea în

care sistemul funcµioneaz .

2.7.2 Adaptarea

Din punct de vedere conceptual calculul cognitiv prive³te adaptabilitatea ca �ind un

proces de explorare ³i descoperire a soluµiilor, în fond modele, în condiµiile unor date

în continu  schimbare ³i incertitudine ca ³i calitate ³i relevanµ . Calculul autonomic se

bazeaz  pe disponibilitatea acestor modele în faza de analiz , pe baza c rora s  poat 

s  plani�ce cu un grad ridicat de certitudine pa³ii urm tori în strategia de execuµie a

actuatorilor sistemului. Dup  cum se poate observa adaptarea poate � interpretat  ca

2.7. Funcµii cognitive în sistemele autonomice 17

�ind o funcµie cost ce cuanti�c  m sura în care procesul de plani�care este capabil s 

genereze un plan util pe baza etapei de analiz , altfel spus, de calitatea întelegerii ³i

deciziei.

Adaptarea poate � privit  ca o bucl  imbricat  în etapa de analiz  a�at  într-o stare

de continu  generare ³i evaluare a ipotezelor construite pe baza analizei datelor culese

atât din sistem cât ³i din lumea real . Rezultatul acestei etape îl reprezint  modelele de

lucru pentru etapa de plani�care.

2.7.3 Relaµia calcului autonomic cu funcµiile cognitive

Funcµiunile cognitive au ca scop generarea ³i validarea unui model dintr-un domeniu

anume pentru a putea prezice rezultatele potenµiale. Identi�carea, proiectarea ³i imple-

mentarea unui sistem cognitiv coerent implic  o serie de pa³i corelaµi. În primul rând

implic  înµelegerea datelor disponibile, tipul de scenarii care merit  s  �e explorate ³i

generarea unui set de cuno³tinµe certe (observed facts). Drept consecinµ , un sistem cog-

nitiv genereaz  ipoteze din datele disponibile, analizeaz  ipoteze alternative ³i determin 

disponibilitatea dovezilor factuale ori a argumentelor factuale pentru a rezolva problema

într-un anumit mod ori altul.

Implementarea funcµiunilor cognitive în bucla MAPE-K î³i g se³te, în principal, re-

prezentarea în zona de Analiz  dar nu se limiteaz  acolo. Se poate observa c  gestionarea

³i contextualizarea datelor reprezint  etapa de Monitorizare, iar actualizarea modelului în

raport cu problema are un impact direct asupra Plani�c rii. Binenµeles, K � cunoa³terea

este prezent  ca ³i conµinut al modelului ³i a modului de înµelegere ³i contextualizare a

datelor ³i ipotezelor.

2.7.4 Modele de înv µare automat 

Modelele de înv µare sunt tradiµional încadrate în trei categorii: înv µare supervizat ,

nesupervizat  ³i prin înt rire.

Înv µarea supervizat  este modul cel mai uzitat de instruire a unui sistem. Mulµi-

mea de date folosit  pentru înv µare const  în perechi de exemple de forma intrare�ie³ire

asociat . Pe baza unor algoritmi speci�ci, modelul de predicµie evolueaz  astfel încât

valorile de ie³ire produse s  �e cât mai similare cu valorile de ie³ire precizate în setul de

18 Capitolul 2. Sisteme de control bazate pe calcul autonomic

instruire.

Înv µarea nesupervizat  vizeaz  cazurile în care din setul de instruire lipsesc valorile

de ie³ire asociate. Cele mai frecvente tipuri de probleme sunt gruparea datelor pe baza

similarit µilor (clustering ³i estimare de densitate de probabilitate) ³i analiza de asocieri.

Finalmente, înv µarea prin înt rire este util  atunci când lipse³te eticheta asociat 

�ec rei intr ri, dar mediul furnizeaz  un r spuns care arat  cât de potrivit  este ie³irea

modelului (un semnal critic, o recompens ) [50].

2.8 Concluzii

În acest capitol au fost prezentate fundamentele problemei calculului autonomic ³i al

aspectelor calculului cognitiv asociat etapei de analiz . Au fost expuse principiile fun-

damentale precum ³i modul în care acestea au fost identi�cate. Au fost explicate ³i

comentate etapele modelului autonomic precum ³i restricµiile asociate. A fost documen-

tat ³i explicat modelul MAPE-K folosit ca ³i compoziµie generic  destinat  sintetiz rii

funcµiunilor autonomice.

A fost detaliat modelul MAPE-K ³i au fost detaliate câteva din implement rile cunos-

cute, precum ³i aspectele practice în care aceste implement ri au fost folosite. Au fost

explicate familiile de funcµiuni auto-*, precum ³i modul în care acestea pot � distribu-

ite. Asociat s-a detaliat modul în care se poate face pasul de la autonomic computing la

autonomic networking precum ³i relaµia cu sistemele distribuite.

Au fost detaliate aspecte speci�ce ale funcµiilor cognitive posibil a � asociate ciclului

autonomic. A fost evidenµiat  relaµia calculului autonomic cu calculul cognitiv, precum

³i rolul acestuia în bucla de reglare.

Modelele de înv µare asociate calculului cognitiv au fost documentate împreun  cu

limitele asociate. S-a precizat zona de aplicabilitate ³i avantajele asociate.

Capitolul 3.

Utilizarea modelului MAPE-K în medii

distribuite

Acest capitol este dedicat prezent rii mediului în care opereaz  nodurile ce expun func-

µiuni autonomice precum ³i a arhitecturii SDCA, pe baza c reia se realizeaz  managemen-

tul întregului ansamblu de noduri autonomice. Pentru a facilita înµelegerea conceptelor

³i a sistemului propus vom prezenta un scenariu suport, exempli�cator pentru sisteme

autonomice.

3.1 Scenariul suport

Dup  cum s-a menµionat anterior, SDCA dezvoltat în cadrul acestei teze de doctorat

poate � aplicat într-o gam  larg  de domenii. Pe parcursul prezent rii conceptelor SDCA

se va face exempli�carea aplic rii acestora pentru un scenariu din domeniul transporturi-

lor. Din acest motiv în urm toarele paragrafe se va descrie pe scurt problema considerat .

Scenariul este descris, de asemenea, ³i în lucrarea [19].

O companie de transport ofer  servicii de distribuµie a materialelor de construcµie la

diferite ³antiere din ora³. Deoarece suprafaµa de stocare a materialelor de construcµie în

19

20 Capitolul 3. Utilizarea modelului MAPE-K în medii distribuite

³antier este limitat  constructorul are nevoie de livrarea materialelor necesare cu puµin

timp înainte de începerea stagiului de construcµie în care acestea vor � efectiv utilizate.

Compania de transport ofer  o gam  larg  de servicii de distribuµie, dup  cum urmeaz :

- livrarea materialelor într-un anumit interval de timp (care poate avea o durat  de

30 de minute), respectiv livrarea acestora cu o zi înainte;

- posibilitatea de a crea cereri cu câteva zile înainte, respectiv cu câteva ore înainte;

- livrarea de materiale cu gabarite, respectiv greut µi, mici sau mari;

- livrarea de materiale care necesit  condiµii speciale de stocare ³i transport (de exem-

plu: materiale cu temperatura de stocare mai mic  de o anumit  valoare, materiale

in�amabile; materiale fragile, etc.);

- livrarea în zone speciale ale ora³ului, unde se aplic  anumite limit ri de vitez ,

greutate ³i gabarit;

- livrarea materialelor de la diferiµi furnizori (de exemplu, depozite de materiale de

construcµii) din ora³ sau din afara acestuia;

- utilizarea de permise de liber  trecere pentru a putea transporta materiale volumi-

noase sau grele în zone unde se aplic  anumite restricµii de circulaµie (de exemplu,

accesul interzis pentru vehiculele cu o greutate mai mare de 3500 kg).

De la început se poate identi�ca faptul c  în cazul sistemului de coordonare a �otei de

autovehicule o parte din decizii/plani�c ri sunt luate la nivel global, iar restul sunt decizii

locale. Mai exact, deciziile globale sunt acelea în care se realizeaz  plani�carea sarcinilor

de distribuµie în a³a fel încât s  se respecte cererile de transport stabilite prin contract cu

clienµii companiei. În urma unei astfel de decizii este posibil ca starea unuia sau a mai

multor agenµi de transport s  �e afectat .

3.2 Mediul autonomic distribuit

Dup  cum menµionam în capitolul 1, SDCA vizeaz  managementul nodurilor autono-

mice distribuite. Acesta se bazeaz  la rândul lui pe modelul MAPE-K, putând astfel spune

c  ansamblul nodurilor formeaz  un mediu autonomic distribuit dup  cum se observ  ³i

3.2. Mediul autonomic distribuit 21

din �gura 3.1 care prezint  arhitectura sistemului. În cadrul MAD, nodurile autonomice

prezint  interacµiuni atât cu mediul în care opereaz  cât ³i cu alte noduri autonomice.

Figura 3.1: Arhitectura SDCA.

Conform secµiunii 2.2 modul de operare a unui nod autonomic poate � structurat pe

trei nivele. Primul nivel combin  funcµiile de monitorizare ³i analiz , acestea �ind strâns

legate între ele, al doilea se refer  la plani�care iar cel de-al treilea corespunde execuµiei.

Analizând îns  interacµiunile dintre noduri, se poate observa c  acestea se produc la

22 Capitolul 3. Utilizarea modelului MAPE-K în medii distribuite

�ecare dintre niveluri, iar topologiile reµelelor care descriu aceste interacµiuni sunt de cele

mai multe ori diferite. Altfel spus, direcµia �uxurilor de date dintre noduri la nivelul NMA

poate s  difere faµ  de cele din nivelul NP sau NE.

Din perspectiva comportamentului autonomic, în cadrul MAD vom avea atât un com-

portament autonomic local, aferent �ec rui nod, precum ³i unul global, sistemic, care

acoper  întreg ansamblul nodurilor autonomice.

3.3 Arhitectura sistemului distribuit de control autonomic

SDCA adreseaz  managementul nodurilor autonomice prin introducerea unor struc-

turi dedicate de control pentru �ecare dintre cele trei niveluri descrise anterior atât la

nivel local cât ³i la nivel global. Aceste structuri permit astfel managementul e�cient ³i

optimizarea sistemelor autonomice mari, distribuite.

Arhitectura SDCA conµine componente speci�ce unei abord ri MAPE-K pentru orice

nod autonomic îns  extinde aceste mecanisme pentru o abordare global , necesar  nodu-

rilor. Astfel, întreg ansamblul nodurilor autonomice este tratat la rândul lui ca un nod

autonomic.

3.3.1 Mecanisme de monitorizare ³i analiz 

Orice mecanism decizional utilizat într-o abordare autonomic  necesit  accesul la date

de intrare relevante ³i validate. În caz contrar, urm toarea component  în bucla autono-

mic , cea de plani�care, nu poate funcµiona. Dup  cum va � detaliat în secµiunea 3.3.3,

componenta de plani�care ia în calcul atât informaµii privind starea intern  a nodului

autonomic precum ³i informaµii externe, de context.

Folosind diferite mecanisme de procesare a datelor se poate face trecerea de la date

elementare la informaµie. Aceasta are o înc rc tur  informaµional  mai ridicat  decât da-

tele elementare. Informaµia se obµine prin �ltrarea, validarea, transformarea ³i agregarea

datelor elementare.

Având în vedere faptul c  un sistem autonomic, prin de�niµie, trebuie s  �e capabil

s  ia decizii f r  intervenµia unui utilizator sau operator uman, funcµiile de monitori-

zare ³i analiz  devin astfel critice. Aceast  a�rmaµie este valabil  atât pentru nodurile

autonomice luate individual cât ³i pentru întregul SDCA.

3.3. Arhitectura sistemului distribuit de control autonomic 23

3.3.1.1 Funcµia de monitorizare

Monitorizarea acoper  funcµia de percepµie direct , care furnizeaz  date ce µin de

nodul autonomic, precum ³i colectarea de date elementare obµinute din surse externe (de

exemplu, de la alte noduri autonomice sau din alte surse). Monitorizarea include îns ,

pe lâng  aceast  funcµie de colectare a datelor, ³i operaµiuni de procesare. Rolul acestor

operaµiuni este acela de a face tranziµia de la date la informaµie.

Un alt rol important al funcµiei de monitorizare este acela de a colecta date despre

starea ³i interacµiunile nodurilor autonomice. Prin colectarea ³i analiza acestor date se

obµine o imagine a st rii sistemului autonomic ³i se iau decizii de management al nodurilor

³i a reµelei de noduri. Din perspectiva operaµional  vorbim practic de o colectare de KPI

(Indicatori cheie de performanµ , din eng. Key Performance Indicators), indicatori care

sunt comparaµi cu valorile de referinµ  stabilite prin SLA. Acest mecanism al SDCA este

prezentat în detaliu în secµiunea 4.2.

3.3.1.2 Funcµia de analiz 

Funcµia de analiz  extinde procesarea realizat  de c tre blocurile de monitorizare ³i

pune accent pe agregarea datelor din surse multiple ³i utilizarea mecanismelor de predicµie.

Pe lâng  informaµiile de stare curent  local  (la nivel de nod autonomic) sau global 

(dat  de contextul în care nodul autonomic opereaz ) funcµia de monitorizare a unui nod

autonomic poate include ³i mecanisme de predicµie pentru a estima modul în care diferite

variabile de stare sau de context pot evolua în timp. Aceste mecanisme de predicµie sunt

bazate pe modele obµinute prin tehnici de înv µare automat , ML.

În cadrul blocului de analiz  al SDCA, al turi de aceast  funcµionalitate de ra�nare

a datelor, se întâlnesc ³i mecanismele prin care SDCA identi�c  necesitatea actualiz rii

topologiei sistemului autonomic. Pe baza KPI, obµinuµi prin funcµia de analiz , ³i a

angajamentelor contractule indicate de c tre SLA, blocul de analiz  poate recomanda

ad ugarea sau eliminarea unor noduri autonomice, modi�care a �uxurilor de date în

cadrul reµelei de noduri sau doar modi�carea parametrilor de funcµionare a acestora.

24 Capitolul 3. Utilizarea modelului MAPE-K în medii distribuite

3.3.1.3 Monitorizarea ³i analiza folosind procesarea evenimentelor complexe

Datele consumate în procesul de monitorizare ³i analiz  de c tre nodurile autonomice

au de cele mai multe ori forma de reprezentare digital  a evenimentelor. Conform [58]

un eveniment corespunde unei înregistr ri la un moment dat a unui fapt petrecut într-un

sistem sau un domeniu. Tot sub denumirea de eveniment întâlnim ³i structura de date

care înregistreaz  acest fapt.

Datorit  modului ³i mediului de operare a nodurilor autonomice funcµia de monito-

rizare ³i analiz  opereaz , de fapt, cu evenimente multiple ce descriu starea intern  a

nodurilor sau contextul de operare al acestuia. Volumul datelor de intrare, natura ope-

raµiunilor care se efectueaz  asupra acestor date precum ³i rezultate dorite recomand 

utilizarea tehnicilor de procesare a evenimentelor complexe, CEP.

3.3.2 Mecanisme de plani�care

Precum se poate observa ³i parµial s-a argumentat anterior, din schema funcµional 

MAPE-K aplicat  atât nodurilor autonomice cât ³i reµelelor autonomice grup rile func-

µionale sunt asociate într-un singur nod de execuµie din punct de vedere al punerii în

funcµiune (deployment-ului). În cel mai generic sens plani�carea implic  luarea unei de-

cizii cu privire la schimb rile ³i adaptarea necesar a � implementat  de componentele

gestionate cu scopul de a se apropia cât mai mult de starea în care unul sau o combinaµie

de scopuri ale sistemului sunt servite.

Un plan de acµiune poate � static sau s  includ  o anumit  pondere calculabil  de di-

namicitate. La minim, un plan const  dintr-un set de pa³i �c³i ce trebuie s  �e executaµi

atunci când o anumit  condiµie ori un set de condiµii corelate în timp sunt satisf cute.

Astfel de situaµii sunt detectate folosind sisteme bazate pe reguli ori bazate pe procesarea

evenimentelor complexe. O abordare cu un grad ridicat de so�sticare implic  utiliza-

rea unui model corelativ bazat pe constrângeri în care poate s  determine o con�guraµie

optim  chiar în cazul unui num r semni�cativ de mare de elemente gestionate în interde-

pendenµ  5.1.1.

În baza monitoriz rii ³i a analizei un plani�cator, implementat local sau într-un over-

lay, decide noi pa³i de realizat. Mecanismele de plani�care cunosc câteva dimensiuni ³i

constrângeri tipice. Putem identi�ca probleme de plani�care a ordinii în timp a execuµiei,

3.3. Arhitectura sistemului distribuit de control autonomic 25

ceea ce uzual cunoa³tem ca scheduling, ³i are ca scop corelarea execuµiei în diferiµi pa³i,

inclusiv ca alternative paralele a diferitelor componente ce livreaz  corelat un serviciu.

3.3.3 Mecanisme de execuµie

Activit µile de plani�care ³i execuµie sunt complementare, deoarece validarea rezul-

tatelor plani�c rii se face în m sura în care acµiunile propuse pot � transpuse în pa³i

realizabili de c tre execuµie. Din acest motiv, plani�carea poate � v zut  ca un sistem de

recomand ri (recommender system) în timp ce execuµia, în funcµie de context, înt re³te,

reorganizeaz , aproximeaz  ori anuleaz  anumiµi pa³i dac  execuµia lor efectiv  nu con-

tribuie la momentul în care este posibil s  �e executaµi la atingerea scopurilor globale ale

sistemului.

Din acest punct de vedere, în cazul unei implement ri reale este de a³teptat s  existe

efectori care pot s  nu funcµioneze corespunz tor sau deloc. Asta înseamn , în �nal, c 

acµiunile cerute de managerul autonomic nu sunt executate. De³i în domenii precum IoT

sau Cloud Computing se studiaz  o serie de abord ri complexe care s  garanteze perfor-

manµa oferit  [61], [25], soluµia comun acceptat  este virtualizarea accesului la resurse din

lumea real  ³i generarea unui model de consum asociat acestora ca parte din Percepµia

Contextual  (Contextual Awareness).

3.3.4 Medii de execuµie ³i comunicare pentru nodurile autonomice

Dup  cum s-a introdus în secµiunile anterioare, sistemele de management autonomic

î³i dovedesc relevanµa, în special, în cazul unei eterogenit µi ³i distribuµii crescute în ceea

ce înseamn  contactul cu resursele gestionate din lumea real . Dac  în cazul monitoriz rii

³i analizei se poate face o uniformizare iar centralizarea poate � considerat  un avantaj al

corel rii unor surse diverse de date, în cazul plani�c rii, ³i mai ales al execuµiei, realitatea

impune o distribuµie inteligent  a funcµiunilor µinând cont atât de aspectele speci�ce

domeniului real de aplicare cât ³i de disponibilitatea ³i capacit µile infrastructurii de

calcul considerate.

Una dintre problemele relevante ale structurii de control ierarhic const  în gestionarea

integr rii de noi elemente monitorizate. Aceast  acµiune presupune un proces de desco-

perire, identi�care, numire ³i înregistrare atât din punct de vedere al adresabilit µii în

26 Capitolul 3. Utilizarea modelului MAPE-K în medii distribuite

sistem cât ³i din punct de vedere al semn turii funcµionale realizate semantic.

Fiecare din aceste structuri poate � adnotat  semantic pe baza unor vocabulare ex-

plicite ³i a unor reguli veri�cabile. Fundamental, bazele de cuno³tinµe vor descrie aceste

structuri la nivel de tipar ³i instanµ , ceea ce va facilita construirea de instrumente de

calcul logic, reasoning logic independente de domeniul de aplicare al serviciilor.

3.3.5 Tipare funcµionale ³i mecanisme de reutilizare

În structura sistemelor autonomice distribuite se vor întâlni de multe ori instanµe

multiple ale unor noduri de acela³i tip. Logica funcµional  a acestor noduri este identic ,

îns  starea lor la un moment dat, precum ³i con�guraµia este determinat  de contextul în

care opereaz .

SDCA are ca obiectiv gestionarea e�cient  a sistemelor autonomice cu un num r mare

de noduri. Pentru a facilita acest lucru, SDCA se bazeaz  pe tipare funcµionale atât la

nivel de nod autonomic cât ³i la nivel de management global. Un tipar funcµional de�ne³te

un model de execuµie care poate � utilizat direct sau prin adaptare în faza iniµial , de

c tre sau asupra unor entit µi distincte de acela³i tip, sau care au funcµionalit µi similare.

În cazul de faµ  aceste entit µi vor � nodurile autonomice precum ³i SDCA, care, a³a cum

menµionam anterior, funcµioneaz , de asemenea, asemeni unui nod autonomic.

Marele avantaj al utiliz rii tiparelor îl constituie potenµialul de reutilizare al acestora

atunci când o anumit  funcµionalitate este aplicabil  mai multor noduri de acela³i tip sau

chiar de tipuri diferite.

Secµiunile urm toare sunt dedicate tiparelor funcµionale disponibile în SDCA precum

³i mecanismelor prin care acestea pot � reutilizate.

3.3.5.1 Tipare de monitorizare ³i analiz 

Din poziµia unui nod autonomic putem vorbi de dubl  o perspectiv  atunci când ne

referim la monitorizare ³i analiz . În prima dintre ele, nodul autonomic este cel care

efectueaz  monitorizarea ³i analiza. A³a cum s-a menµionat ³i în secµiunea 3.3.1 acesta

colecteaz  ³i analizeaz  date atât despre starea intern  dar ³i despre mediul în care ope-

reaz .

În cea de-a doua dintre perspective, nodul autonomic este cel supus monitoriz rii ³i

3.3. Arhitectura sistemului distribuit de control autonomic 27

analizei de c tre SDCA. Aceste operaµiuni sunt dictate de necesitatea gestion rii nodurilor

autonomice, indiferent c  vorbim de gestionare cu impact local (atunci când SDCA solicit 

schimbarea unor parametri interni) sau cu impact global, sistemic (atunci când SDCA

solicit  schmbarea topologiei nodurilor ³i a interacµiunilor dintre ele).

În ambele cazuri îns  este necesar , de cele mai multe ori, colectarea unor date de

acela³i tip, asupra c rora se aplic  operaµiuni similare (�ltrare, validare, agregare).

Dup  cum este prezentat în detaliu în secµiunea 4.1, SDCA folose³te CEP pentru

implementarea mecanismelor de monitorizare ³i analiz .

Dup  cum menµionam anterior, funcµiile de monitorizare ³i analiz  sunt strâns legate

între ele având în vedere c  datele obµinute în urma monitoriz rii sunt furnizate spre

analiz . Ambele sunt implementate în cazul SDCA folosind tehnici CEP. Cu toate acestea,

³i în cazul funcµiei de analiz , SDCA permite utilizarea modelelor predictive ca suport

pentru mecanismele decizionale. Din acest motiv, în cazul funcµiei de analiz  se pot folosi

atât tipare bazate strict pe sintaxa CEP îns , prin utilizarea mecanismelor descrise în

secµiunea 4.3.1, se pot integra modele predictive care de�nesc, de fapt, un tipar.

3.3.5.2 Tipare de plani�care

Tiparele de plani�care sunt în strâns  leg tur  cu funcµiile de analiz  ³i plani�care

precum ³i cu cea de execuµie. Dup  cum s-a indicat ³i în secµiunea 3.3.1.3, blocul de analiz 

al SDCA nu va furniza o soluµie nou  referitoare la con�guraµia sistemului autonomic.

Acest bloc construie³te doar setul de constrângeri pe care plani�catorul trebuie s  le

rezolve pentru a se obµine o soluµie valid  de recon�gurare.

Aceste constrângeri conµin, pe lâng  relaµiile propriu-zise care de�nesc constrângerile,

limitele acceptabile stabilite prin interpretarea condiµiilor din SLA.

Realizând analogia cu tiparele de monitorizare ³i de analiz  în implementarea SDCA

(care folose³te tehnici CEP) constrângerile sunt tipare de plani�care unde relaµiile care de-

�nesc constrângerile reprezint  echivalentul regulilor ³i interog rilor CEP neparametrizate

iar limitele acceptabile reprezint  parametrii funcµionali ai acestor reguli ³i interog ri.

Astfel, funcµia de analiz  preia tiparele de plani�care elaborate de c tre expertul de

domeniu ³i impuse de stare curent  a sistemului autonomic, le parametrizeaz  prin apli-

carea limitelor dictate de SLA ³i le transmite blocului de plani�care pentru a se obµine o

28 Capitolul 3. Utilizarea modelului MAPE-K în medii distribuite

nou  con�guraµie valid  a sistemului.

3.3.5.3 Tipare de execuµie

Într-o manier  similar  tiparelor de monitorizare ³i analiz  sau celor de plani�care,

SDCA permite utilizarea tiparelor de execuµie. Acestea de�nesc integral sau parµial logica

de funcµionare atât la nivel de nod autonomic cât ³i la nivel global.

La nivel de nod autonomic, instanµele tiparelor de execuµie de�nesc funcµionalitatea

operaµional  a nodurilor. Prin acest mecanism se poate elimina abordarea de tip hard-

coding, unde logica de execuµie este �x  ³i nu poate � modi�cat  decât prin înlocuirea

nodului autonomic, cu o abordare �exibil  de tip plug-in, unde logica de execuµie, sau

o parte din ea, poate � actualizat  în funcµie de necesit µi, f r  a � necesar  înlocuirea

nodului autonomic.

La nivel de sistem autonomic, tiparele de execuµie de�nesc diferite structuri de orches-

trare a nodurilor f r  a speci�ca în mod explicit care sunt nodurile executante. Un

mecanism de orchestrare are ca scop, dup  cum indic  ³i numele, legarea nodurilor auto-

nomice ³i funcµionalit µii lor într-o structur  unitar  cu obiective ³i scopuri bine de�nite.

Tiparul de execuµie, la fel ca ³i la tiparele mai sus menµionate, de�ne³te o structur  de

orchestrare în care elementele de execuµie sunt descrise funcµional dar f r  a se face o

numire cu privire la nodul executant. În cadrul SDCA, modulul de plani�care, pe baza

constrângerilor de�nite în faza de analiz  va "popula" tiparul de execuµie cu funcµiile

nodurilor autonomice cerute de logica tiparului.

3.3.5.4 Modele predictive

Predicµia este folosit  în arhitectura propus  pentru a putea reduce costul asociat pla-

ni�c rii ³i a utiliz rii containerelor mediilor de execuµie. În acest sens bazele de cuno³tinµe

sunt permanent reevaluate în baza diferenµelor observate din compararea rezultatelor efec-

tive ale execuµiei cu cele prezumate de predicµie. O etapa relevant  a formul rii cu succes

a unui model de predicµie este asocierea e�cient  a informaµiilor monitorizate în lumea

real  cu modelul pe care îl urmeaz  cel mai bine. În acest sens, în arhitectur  se poate

identi�ca drept parte a monitoriz rii o capabilitate de observare a situaµiei.

Modelele de predicµie considerate sunt relevante în cadrul aspectelor congitive din

3.3. Arhitectura sistemului distribuit de control autonomic 29

sistemele autonomice prin prisma faptului c  µintesc adaptarea modelelor de cuno³tinµe

³i acµiune la realitatea observabil . Într-un mediu dinamic, noi tipuri de comportament

pot � observate în timp ori putem constata c  alte modele nu mai sunt susµinute de

evidenµa statistica observat  pe o perioada su�cient  de timp. Din acest motiv, modelele

preantrenate nu pot lucra cu exactitate garantat  pentru o perioada de timp inde�nit .

În cazul arhitecturii propuse se poate observa modul în care cuno³tinµele despre sistem

(System Knowledge -SK) sunt folosite pentru autooptimizarea funcµiilor expuse precum ³i

a mediului de execuµie. În cazul ultimelor, autooptimizarea refer  modul în care resursele

sunt folosite � inclusiv cele din lumea real  ³i formalizate prin cuno³tinµele despre lumea

real  (Real World Knowledge -RWK). În acest sens execuµia modelului predictiv ales este

de a³teptat s  contribuie în faza de plani�care la preselecµia unor constrângeri capabile

s  reduc  spaµiul de soluµii disponibil la execuµie.

3.3.6 Baze de cuno³tinµe

Orice arhitectur  de sistem conµine implicit ori explicit un model, o colecµie de tipare

semantice agreate referitoare la relaµiile acceptate între resurse, procese ³i servicii expuse.

Aceast  semantic  se poate folosi în dou  moduri: codat  direct în procese �xe f r 

posibilitatea de recon�gurare, reevaluare ³i adaptare, ³i în depozite formale care codeaz 

cuno³tinµele despre sistem.

Dup  cum s-a descris anterior, în sisteme autonomice considerate, un pas important

este cel referitor la uniformizarea accesului la resurse. Aceast  uniformizare este rele-

vant  deoarece separ  accesul pe baz  de protocol speci�c ³i con�guraµie speci�c  �ec rui

produc tor de componente conectate în structuri de tip gateway ³i expunerea acestora

uni�cat ca servicii REST adnotate semantic [37].

Trecând la un nivel de complexitate diferit putem observa c  tipurile de procese ges-

tionate la nivel de servicii compuse impun un alt model semantic. În acest caz, aspectul

important de gestionat în cadrul unui serviciu compus µin de gestionarea �uxului de lu-

cru, a disponibilit µii resurselor precum ³i a strategiilor de înv µare online din experienµa

execuµiei. De asemenea, aceste modele pot include strategii de aproximare ³i înlocuire

a serviciilor ce nu satisfac SLA la un moment dat. Din punct de vedere autonomic,

compoziµia unui work�ow de lucru este asociat  funcµiunii de plani�care.

30 Capitolul 3. Utilizarea modelului MAPE-K în medii distribuite

3.4 Concluzii

Acest capitol a introdus conceptul suport al arhitecturii sistemului autonomic. A fost

prezentat un scenariu suport ales pentru a ilustra fezabilitatea ³i utilitatea abord rii.

Au fost subliniate restricµiile speci�ce, precum ³i diferenµierea aspectelor IT ³i non-IT

considerate.

Au fost detaliate funcµiile esenµiale ³i s-a discutat rolul �ec rei etape în parte. S-au

discutat abord ri posibile asupra componentelor cheie.

A fost prezentat rolul pe care îl au tiparele funcµionale ata³ate mecanismelor buclei de

control autonomice ³i s-a expus dependenµa dintre acestea.

S-a f cut o prezentare a modelelor de înv µare considerate în arhitectur  precum ³i

relaµia acestora cu datele disponibil a � procesate de c tre sistem cu scopul realiz rii

funcµiunilor obiectiv autonomice. S-a prezentat structura cerinµelor impuse bazei de cu-

no³tinµe ce codeaz  cunoa³terea explicit  din sistem ³i s-a f cut o analiz  a acestora.

Capitolul 4.

Monitorizarea ³i analiza st rii nodurilor

distribuite autonomice

Acest capitol descrie în am nunt realizarea etapelor de monitorizare ³i analiz  în SDCA.

Al turi de discuµia tehnic  a soluµiilor de implementare sunt prezentate concepte de lu-

cru realizate în proiecte de cercetare ³tiinµi�c  în derulare precum ³i modul în care este

soluµionat studiul de caz propus.

4.1 Percepµia sistemic  ³i a mediului exterior

Dup  cum se poate observa în secµiunile anterioare ³i s-a demonstrat în [9], [29], [61],

[72] sistemele autonomice implementeaz  prin intermediul funcµiunilor de tip self-* ca-

pabilit µi de prelevare, prelucrare, clasi�care ³i adnotare a mediului în care evolueaz .

Aceste funcµiuni reprezint  baza unei �con³tiinµe de sine� a sistemelor. Dac  monitori-

zarea este o funcµiune comun , capacitatea de a identi�ca o situaµie complex  pe baza

unei experienµe anterioare (Situation Awareness - SA) ³i capacitatea de înv µare ³i adap-

tare ofer  sistemelor autonomice capabilit µi cognitive. Sistemele ce implementeaz  SA

cunosc diferite moduri de reprezentare a cuno³tinµelor manipulate. De regul , acestea

31

32 Capitolul 4. Monitorizarea ³i analiza st rii nodurilor distribuite autonomice

folosesc o serie de tipare ³i modele formale iniµiale (cunoa³tere apriori) pe baza c rora

se pot construi prin ajustare asupra lor ³i a prelucr rii instanµelor observate (most likely

neighbourhood) ³i a inferenµei acestora noi cunostinµe ³i capabilit µi. Cu scopul identi-

�c rii facile ale celor dou  categorii de cuno³tinµe le vom denumi cuno³tinµe de sistem

(SK) ³i cuno³tinµe despre lumea real  (RWK). Conform investigaµiilor f cute în proiectul

FP7 ICT iCORE arhitectura propus  în aceast  tez  se poate structura u³or diferit într-o

perspectiv  privind de sus în jos:

- Un nivel care s  permit  apelul funcµionalit µilor ³i serviciilor oferite de un astfel de

sistem, în baza unor tipare disponibile corespunz toare aplicaµiilor din lumea real .

Astfel de tipare sunt instanµiate în funcµie de cuno³tinµele acumulate ³i compuse la

momentul apel rii;

- Un mediu de execuµie plus funcµionalit µile de gestionare a acestora ce gestioneaz 

pe baza SK resursele disponibile, sau compune pe baza necesit µilor servicii noi;

- Un nivel de monitorizare a lumii reale prin senzori direcµi ori senzori virtuali.

În �gura 4.1 este prezentat  arhitectura platformei iCore. Aici se pot identi�ca cu

u³urinµ  cele dou  componente SK, respectiv RWK, iar mai multe am nunte se pot g si

în livrabilul [74].

Observ m c  o funcµiune important  a sistemului este capacitatea de a diferenµia

între interacµia intenµional  a unui actor extern (solicitarea execuµiei unui serviciu) ³i cea

neintenµional  (observarea continu  a mediului de c tre sistem).

O alt  funcµionalitate pe care o putem observa este legat  de capacitatea sistemului

de a avea memorie episodic  [75], [76]. Din punct de vedere al capabilit µilor autonomice

sistemul încearc  s  exploateze optimal mediul de rulare folosit ³i elementele active din el,

detectând astfel c i prin care, în afara solverelor care pot consuma un timp considerabil

pentru a identi�ca o soluµie, s  poat  aproxima contextul curent în experienµele trecute

³i s  identi�ce oportunit µile de refolosire ale artefactelor active. În acest mod se evit 

generarea de la zero a artefactelor/serviciilor active ³i înt rirea importanµei componentelor

cele mai utilizate [77], oferind o scalabilitate crescut  ³i un timp de r spuns îmbun t µit.

4.2. Contracte la nivel de serviciu 33

Figura 4.1: Arhitectura platformei iCore. [74].

4.2 Contracte la nivel de serviciu

Odat  cu dezvoltarea sistemelor software distribuite cu resurse partajate cum ar �

arhitecturile de tip SOA (Service Oriented Architectures) sau Cloud, s-a observat ³i ne-

cesitatea instituirii unor mijloace speci�ce destínate gestion rii performanµei acestora în

raport cu cererile de servicii ³i aplicaµii g zduite. SLA este subiectul complementar cheie

al turi de funcµionalitatea direct  oferit  ³i agreeaz  modul în care funcµionalitatea este

oferit . SLA face posibil  diferenµierea ca ³i bun economic a funcµionalit µilor unei plat-

forme de execuµie pentru servicii software ³i se caracterizeaz  prin:

- Predictibilitate ³i control la execuµie run-time;

- Management transparent a sistemului SLA din punct de vedere al utilizatorilor �

unde SLA de�ne³te cu precizie condiµiile în care serviciile sunt oferite ³i consumate,

iar valabilitatea lor este gestionat  uniform în platforma gazd  ³i are un înµeles

neechivoc pentru interacµia cu aplicaµiile clientului;

- Automatizarea proceselor � începând de la negociere, termeni agreaµi, implemen-

tarea în sistem, livrare ³i monitorizare permit automatizarea ³i înscrierea în bucla

autonomic  de control cu scopul de a putea reacµiona rapid într-un mediu dinamic

34 Capitolul 4. Monitorizarea ³i analiza st rii nodurilor distribuite autonomice

³i cu cerinµe de scalabilitate ridicate.

Pentru cazul arhitecturii SCDA prezentate în aceast  tez  conceptul de SLA se asoci-

az  natural ³i deschide implementarea pentru domenii de aplicaµie diverse. Conceptul nu

este izolat ³i genereaz  impact în toate nivelele descrise. Aceast  abordare este extrem

de �exibil  ³i induce costuri reduse ³i transparenµ  în momentul asocierii cu uneltele po-

trivite (acces la resurse, softuri suport ³i pentru integrare, unelte de formale de de�nire a

regulilor ³i a modului de interoperare între componente), toate având posibilitatea de a

avea asociate reguli SLA, inclusiv pentru interacµia dintre ele ³i modul cum contribuie la

interacµia SLA de nivel înalt.

4.3 Utilizarea CEP la implementarea monitoriz rii nodurilor distribuite auto-

nomice

Percepµia sistemic  ³i a mediului exterior presupune utilizarea unor mecanisme ³i

a unor tehnici prin intermediul c rora s  se poat  procesa cât mai aproape de timp-

real �uxurile de date ³i evenimente venite din exteriorul SDCA sau de la nodurile ce

implementeaz  funcµiuni autonomice interne. Scopul acestei proces ri este de a extrage

informaµiile care permit îmbun t µirea ³i optimizarea modului de operare al SDCA.

În cazul scenariului practic prezentat în capitolul 3 percepµia sistemic  reprezint 

activitatea de monitorizare a st rii agenµilor de transport (reprezentând de fapt nodurile

autonomice) ³i a procesului de distribuµie cu scopul de a identi�ca eventualele abateri de

planul de livrare sau incapacitatea unor agenµi de a-³i îndeplini funcµia. Rezultatele acestui

proces de monitorizare sunt folosite pentru a de�ni staza sistemului la nivel global urmând

ca în pasul urm tor al buclei autonomice s  se realizeze, dac  este nevoie, replani�carea

nodurilor distribuite autonomice.

La nivel de nod autonomic percepµia sistemic  are dou  componente. În primul rând

nodul autonomic trebuie s  î³i monitorizeze starea intern , cum ar � parametri de func-

µionare ai autovehiculului cu scopul identi�c rii eventualelor disfuncµionalit µi. Pentru

autovehiculele care transport  produse speciale (de exemplu, termosensibile), trebuiesc

monitorizate inclusiv condiµiile de transport ale produselor cu scopul identi�c rii eventu-

alelor abateri de la cerinµele speci�cate prin contract.

Cea de-a doua component  a percepµiei sistemice la nivel de nod autonomic const  în

4.3. Utilizarea CEP la implementarea monitoriz rii nodurilor distribuite autonomice 35

monitorizarea activit µii nodurilor a�ate în vecin tate, �e ea geospaµial  sau logic . În

acest fel un agent de transport poate s  identi�ce, de exemplu, starea tra�cului în diferite

zone ale ora³ului unde el ar trebui s  transporte materiale în viitorul apropiat conform

plani�c rii livr rilor sale ori posibilelor sale misiuni.

4.3.1 Procesarea evenimentelor complexe

O de�niµie a evenimentelor este dat  de c tre Etzion ³i Niblett [58]: o întâmplare

într-un anumit sistem sau domeniu, ceva ce s-a întâmplat sau este contemplat ca �ind

întâmplat în acel domeniu. O variant  mai condensat  este oferit  de c tre Candy [82]:

orice lucru care se întâmpl  sau s-a întâmplat.

În acest context, a ap rut un nou model de procesare a datelor de acest tip numit

CEP. De ce atributul complex? Paradigma CEP ³i soluµiile de procesare aferente vizeaz 

extragerea de informaµie sau de date cu înc rc tur  informaµional  ridicat  din date

aparent disparate sau care, luate individual, nu permit tragerea unor concluzii cu privire

la fenomenul care le-a generat. Obµinem astfel, prin procesarea evenimentelor elementare,

informaµii care reprezint  evenimente complexe. Conceptul de eveniment complex a fost

introdus de c tre David Luckham [83] ³i, precum evenimentele elementare pe baza c rora

a fost obµinut, cap t  semni�caµie real  doar prin ata³area dimensiunii temporale.

Etzion ³i Niblett [58] au identi�cat, de asemenea, o serie de tehnologii ³i soluµii care

împrumut , într-o m sur  mai mic  sau mare, tr s turi speci�ce CEP, dintre care putem

aminti: Business Process Management, Business Activity Monitoring, Business Intelli-

gence, Business Rule Management Systems, Network and System Management, Message

Oriented Middleware, Stream Computing. Dup  cum se observ , majoritatea acestor

soluµii sunt dedicate sectorului business, sector care opereaz  intens cu evenimente.

Structura tipic  a unei aplicaµii CEP este prezentat  în [58]. Motorul CEP permite

construirea unei reµele de procesare a evenimentelor EPN (Event Processing Network) ,

o structur  cu care permite tratarea evenimentelor de intrare ³i generarea evenimentelor

complexe. Reµeaua conµine produc tori ³i consumatori de evenimente, agenµi de procesare,

canale de evenimente.

Agenµii de procesare reprezint  nodurile reµelei de procesare ³i sunt blocurile logice

care efectueaz  diferitele operaµiuni de procesare a evenimentelor. Logica de procesare

36 Capitolul 4. Monitorizarea ³i analiza st rii nodurilor distribuite autonomice

este exprimat  cu ajutorul unui limbaj de procesare a evenimentelor EPL (eng. Event

Processing Language).

Se observ  tendinµa includerii motoarelor CEP în soluµii integratoare de procesare a

�uxurilor de evenimente, fapt care con�rm  faptul c  tehnologia CEP a ajuns la un nivel

de maturitate su�cient de ridicat.

4.3.2 Percepµia sistemic  în cazul sistemului de distribuµie

În continuare se vor prezenta dou  tipare care pot � utilizate pentru a se monito-

riza procesul de transport al produselor termosensibile conform scenariului prezentat în

secµiunea 3.1. Nu se vor descrie ³i celelalte categorii de procese de monitorizare siste-

mic  (prezentate în secµiunea 4.3) deoarece logica de detecµie a evenimentelor este relativ

simpl .

În cadrul experimentelor practice s-a considerat c  pentru transportul produselor ter-

mosensibile autovehiculele sunt dotate cu urm torul set de senzori, respectiv actuatori:

un senzor de temperatur  instalat pe produsul transportat; trei senzori de temperatur 

instalaµi în interiorul autovehiculului; un senzor pentru m surarea temperaturii externe a

autovehiculului, un senzor de curent; ³i un sistem de r cire.

Se va considera c  un produs este stocat în condiµii optime dac  temperatura acestuia

este mai mic  de o valoare speci�cat  cu ajutorul parametrului pragTemperatura1. De

asemenea, se poate dep ³i aceast  limit  de temperatur  dac  sunt îndeplinite urm toarele

dou  condiµii:

- temperatura este mai mic  de valoarea speci�cat  de parametrul pragTemperatura2

(unde pragTemperatura1 < pragTemperatura2 );

- intervalul de timp în care are loc dep ³irea temperaturii este mai scurt decât valoarea

speci�cat  prin parametrul lungimeDepasire;

În �gura 4.2 se a�  tiparul de monitorizare care detecteaz  momentele de timp în care

produsele nu sunt transportate conform cerinµelor precizate mai sus.

În primul rând, cu ajutorul interog rii din listing-ul 4.1, se veri�c  dac  temperatura

produsului transportat este mai mic  de valoarea parametrului pragTemperatura2. În caz

contrar se genereaz  o alarm .

4.3. Utilizarea CEP la implementarea monitoriz rii nodurilor distribuite autonomice 37

Figura 4.2: Tiparul de monitorizare care detecteaz  momentele de timp în care produselenu sunt transportate conform cerinµelor.

1 i n s e r t i n to FluxAlarmaProdusStocatNecorespunzator s e l e c t temperatura ,

momentDeTimp , IDsenzor from FluxMasuratoriDeTemperatura ( temperatura >

pragTemperatura2 )

Listing 4.1: Detectarea momentelor de timp în care temperatura este mai mare de

pragTemperatura2.

În continuare pentru a se detecta situaµia în care produsele sunt stocate la o tem-

peratur  mai mare de pragTemperatura1 pentru un interval de timp mai lung de lungi-

meDepasire trebuie s  se identi�ce momentele de timp în care temperatura produsului

tranziteaz  acest prag. Acest lucru se realizeaz  prin intermediul listingurilor 4.2 ³i 4.3.

1 i n s e r t i n to FluxEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 s e l e c t

temperatura , momentDeTimp , IDsenzor from FluxMasuratoriDeTemperatura (

temperatura > pragTemperatura1 )

Listing 4.2: Detectarea momentelor de timp în care temperatura este mai mare de

pragTemperatura1.

38 Capitolul 4. Monitorizarea ³i analiza st rii nodurilor distribuite autonomice

1 i n s e r t i n to FluxEvenimenteTemperaturaProdusMaiMicaCaPragTemperatura1 s e l e c t

temperatura , momentDeTimp , IDsenzor from FluxMasuratoriDeTemperatura (

temperatura < pragTemperatura1 )

Listing 4.3: Detectarea momentelor de timp în care temperatura este mai mic  de

pragTemperatura1.

De asemenea, se declar  o fereastr  cu evenimente care va stoca primul eveniment

care semnaleaz  c  temperatura este mai mare de pragTemperatura1 care urmeaz  dup 

o secvenµ  de evenimente în care temperatura a fost în limite normale (vezi listing 4.4).

1 c r e a t e window

FereastraCuEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 . win :

k e epa l l ( ) as temperatura , momentDeTimp , IDsenzor from

FluxEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1

Listing 4.4: Declararea unei fereastre cu evenimente care va stoca primul eveniment care

semnaleaz  c  temperatura este mai mare de pragTemperatura1 care urmeaz  dup  o

secvenµ  de evenimente în care temperatura a fost în limite normale.

În aceast  fereastr  se va introduce primul evenimentul generat pe �uxul FluxEveni-

menteTemperaturaProdusMaiMareCaPragTemperatura1 în momentul în care aceasta este

goal  (nu conµine niciun eveniment), iar fereastra va � golit  de �ecare dat  când este

generat un eveniment în �uxul FluxEvenimenteTemperaturaProdusMaiMicaCaPragTem-

peratura1. Aceste operaµiuni sunt realizate de interog rile din listing-urile 4.5 ³i 4.6.

1 i n s e r t i n to FereastraCuEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1

s e l e c t temperatura , momentDeTimp , IDsenzor from

FluxEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 where ( ( s e l e c t

count (* ) from

FereastraCuEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 ) = 0)

Listing 4.5: În fereastr  se va introduce primul evenimentul generat pe �uxul

FluxEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 în momentul în care

aceasta este goal .

1 on FluxEvenimenteTemperaturaProdusMaiMicaCaPragTemperatura1 d e l e t e from

FereastraCuEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1

4.3. Utilizarea CEP la implementarea monitoriz rii nodurilor distribuite autonomice 39

Listing 4.6: Fereastra este golit  de �ecare dat  când este generat un eveniment în

FluxEvenimenteTemperaturaProdusMaiMicaCaPragTemperatura1.

În �nal se calculeaz  durata de timp dintre �ecare eveniment venit pe FluxEvenimen

teTemperaturaProdusMaiMareCaPragTemperatura1 cu evenimentul stocat în Fereastra

CuEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 (dac  fereastra nu este

goal ). Iar în momentul în care durata de timp obµinut  este mai mare decât lungimeDe-

pasire se va genera o alarm  (listing 4.7).

1 i n s e r t i n to FluxAlarmaProdusStocatNecorespunzator s e l e c t

masuratoareTemperaturaCurenta . temperatura as temperatura ,

masuratoareTemperaturaCurenta . IDsenzor as IDsenzor ,

masuratoareTemperaturaCurenta .momentDeTimp as momentDeTimp from

FluxEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 . std : l a s t e v en t ( )

as masuratoareTemperaturaCurenta ,

FereastraCuEvenimenteTemperaturaProdusMaiMareCaPragTemperatura1 as

masuratoareDeTemperaturaVeche where ( masuratoareTemperaturaCurenta .

momentDeTimp − masuratoareDeTemperaturaVeche .momentDeTimp >

lungimeDepas ire )

Listing 4.7: Generarea alarmei în momentul în care produsul este stocat la o temperatuar 

mai mare ca pragTemperatura1 pentru o perioad  de timp mai lung  de lungimeDepasire.

Metoda prezentat  anterior detecteaz  situaµia în care produsele nu sunt stocate co-

respunz tor exact în momentul în care acest lucru se întâmpl . Ar � util pentru ³oferii

autovehiculelor s  �e noti�caµi cu o perioad  de timp înainte ca acest lucru s  se întâmple.

În acest sens se pot folosi diferite modele de predicµie cu ajutorul c rora se pot prezice

condiµiile de stocare ale produselor peste un interval de timp (de exemplu, 30 de minute).

Un astfel de model de predicµie este prezentat în secµiunea 6.2.

În continuare, predicµia de temperatur  se poate realiza folosind interogarea din listing-

ul 4.8.

1 i n s e r t i n to PredictieDeTemperatura s e l e c t r e a l i z a r e P r e d i c t i e (* ) as

pred ict i eTemperatura from FluxMasurator iA l in ia te

Listing 4.8: Apelul modelului de predicµie pentru a se realiza o predicµie de temperatur .

40 Capitolul 4. Monitorizarea ³i analiza st rii nodurilor distribuite autonomice

Dup  cum se poate observa, pentru generarea unei predicµii a fost apelat operatorul

realizarePredictie. Acesta a fost de�nit în prealabil ³i a fost înregistrat în momentul în

care a fost pornit motorul de CEP. În urma înregistr rii s-a realizat, de fapt, leg tura

între metoda forecast() ³i operatorul CEP realizarePredictie.

4.3.3 Percepµia mediului exterior în cazul sistemului de distribuµie

În acest subcapitol sunt descrise tiparele de monitorizare care sunt folosite pentru a

realiza percepµia mediului exterior în cadrul sistemului de distribuµie a materialelor de

construcµie prezentat în secµiunea 3.1.

Pentru a detecta producerea unui ambuteiaj folosind detectoare în bucl  plasate la

intrare, respectiv ie³irea, unui tronson de drum, trebuie calculat  diferenµa dintre num rul

de ma³ini care a intrat în tronsonul respectiv de drum ³i num rul de ma³ini care au ie³it.

În situaµia în care a intrat un num r foarte mare de ma³ini pe tronsonul de drum dar a

ie³it un num r redus înseamn  c  pe tronsonul respectiv s-a produs un ambuteiaj [96].

Dup  cum se poate poate observa ³i în �gura 4.3 tiparul de detectare a ambuteiajelor

conµine mai multe noduri de procesare a evenimentelor.

Figura 4.3: Tiparul de detectare al ambuteiajelor pentru un tronson de drum care conµinedetectoare în bucl  la intrare, respectiv ie³ire.

Interog rile care sigur  etapele de procesare reprezentate de blocurile din �gura 4.3

au fost excluse din aceast  form  restrâns  a tezei de doctorat.

Tiparul de detectare din �gura 4.4 se poate folosi pentru detecµia de ambuteiaje în

zona unde este instalat un senzor care detecteaz  num rului de autovehicule ³i viteza

medie a acestora într-un interval de perioadaAchizitie minute.

4.3. Utilizarea CEP la implementarea monitoriz rii nodurilor distribuite autonomice 41

Figura 4.4: Tiparul pentru detecµia de ambuteiaje în zona unde este instalat un senzorcare detecteaz  num rului de autovehicule ³i viteza medie a acestora.

Interog rile care sigur  etapele de procesare reprezentate de blocurile din �gura 4.4

au fost excluse din aceasµ form  restrâns  a tezei de doctorat.

Pentru situaµia în care pe autovehicule sunt instalate terminale inteligente care permit

raportarea anonim  a locaµie acestora, se pot considera nenum rate moduri care permit

detectarea de ambuteiaje. În continuare se va prezenta o metod  de detectare a unui

ambuteiaj într-o intersecµie din ora³ pentru care se cunosc coordonatele GPS. Se de�nesc

urm torii parametrii ca �ind:

- pragNumarDeMasini : num rul minim de ma³ini care trebuie s  se a�e în intersecµie

pentru ca aceasta s  �e blocat ;

- razaZonaDeTest : raza zonei care împrejmuie³te intersecµia (aceasta are form  de

cerc cu centrul pe coordonatele GPS ale intersecµie);

- latitudineIntersectie, longitudineIntersectie: coordonatele GPS ale intersecµiei;

- perioadaRaportare: intervalul de timp la care se realizeaz  testarea condiµie de creare

a ambuteiajului.

Tiparul de detectare a ambuteiajului pentru situaµia considerat  este prezentat în

�gura 4.5.

Interog rile care sigur  etapele de procesare reprezentate de blocurile din �gura 4.5

au fost excluse din aceasµ form  restrâns  a tezei de doctorat.

42 Capitolul 4. Monitorizarea ³i analiza st rii nodurilor distribuite autonomice

Figura 4.5: Tiparul pentru detecµia de ambuteiaje în zona unei intersecµii pentru situaµiaîn care vehiculele care tranziteaz  intersecµia genereaz  rapoarte anonime de poziµie.

4.4 Concluzii

În acest capitol sunt trecute în revist  principale tipuri de tehnici de procesare a

informaµie achiziµionate de senzori cu scopul de a permite sistemul SCDA s  perceap 

starea sa intern , respectiv starea mediului înconjur tor. În acest scop s-a avut în vedere

utilizarea tehnicilor CEP deoarece reprezint  o soluµie viabil  pentru procesarea aproape

în timp-real a unor �uxuri mare de date. Pe lâng  acest avantaj, un motor CEP pune

la dispoziµie o sintax  foarte �exibil  care permite descrierea constrângerilor spaµiale ³i

temporale dintre evenimentele brute cu scopul de a se identi�ca informaµii cu valoare

ad ugat  pentru sistem sau utilizator.

Pentru implementarea practic  s-a utilizat motorul de CEP Esper, iar în acest capitol

sunt prezentate principalele tipare de monitorizare care trebuie executate pentru a percepe

sistemul, respectiv mediul înconjur tor, în cadrul sistemului de distribuµie a materialelor

de construcµie (secµiunea 3.1).

Majoritatea tiparelor realizeaz  analitica descriptiv  a factorilor care intervin asupra

sistemului de distribuµie ³i aici se pot aminti: tehnicile de detecµie a ambuteiajelor, res-

pectiv tehnica de monitorizare a st rii produselor transportate.

În scopul de a îmbun t µi procesul de distribuµie s-a prezentat ³i un model de tipar

care permite analitica predictiv . Mai exact se poate realiza prezicerea st rii produselor

care sunt transportate ³i în felul acesta se pune la dispoziµia mecanismului decizional

informaµie a c rei utilizare conduce la reducerea cantit µii de materiale care sunt distruse

în timpul transportului. Acest lucru s-a obµinut prin integrarea in motorul CEP a unui

model de predicµie. Se poate observa faptul c  în ceea ce prive³te procesele din lumea

real , prezenµa decidentului uman poate � obligatorie sau nu în ceea ce prive³te deciziile

posibile, parµial sau total.

Capitolul 5.

Recon�gurarea nodurilor autonomice.

Utilizarea constrângerilor

Continuând explicitarea implement rii MAPE-K în medii distribuite capitolul curent va

prezenta design-ul detaliat al etai de plani�care. Se face o argumentare a tehnologiei

selectate ³i a modului în care a fost folosit  pentru generarea de planuri valide ³i adaptate

în cazul ales.

5.1 Sisteme cu constrângeri

Problema con�gur rii ³i recon�gur rii spaµiale, temporale ³i funcµionale ale unor re-

surse este un subiect comun multor domenii de aplicare ce încearc  gestionarea predictibil 

³i e�cient  a resurselor �zice ori a potenµialului de execuµie. Un exemplu simplu este cel

al coordon rii unor operaµiuni militare în care sunt implicate un num r diferit de unit µi

cu abilitaµi, poziµion ri ³i e�cienµ  diferit  cu scopul realiz rii unuia sau a mai mult obiec-

tive comune simultan ori într-o anumit  ordine: ap rarea grupului. Observ m c  astfel

de probleme expun o serie de constrângeri atât globale cât ³i între diferitele elemente ale

con�guraµiei de resurse.

43

44 Capitolul 5. Recon�gurarea nodurilor autonomice. Utilizarea constrângerilor

Solverele de constrângeri preiau o astfel de problem  speci�c  exprimat  formal în

termeni de variabile ³i constrângeri asupra lor ³i caut  valorile permise asupra tuturor

variabilelor în a³a fel încât constrângerile s  �e satisf cute. Una dintre calit µile evidente

ale sistemelor construite pe baza constrângerilor programabile o reprezint  validitatea

funcµional  a soluµiei generate deoarece acestea sunt speci�cate de la început ³i propagate

riguros în timpul rezolv rii. Precum s-a demonstrat în [98] am considerat c  o astfel de

abordare ce ³i-a ar tat utilitatea în sistemele multiagent poate � extins  în cazul sisteme-

lor autonomice deoarece poate garanta respectarea continu  a funcµiilor auto* (self-*). În

cazul problemelor tratate de aceast  tez  se va demonstra modul în care constrângerile

programabile permit con�gurarea ³i recon�gurarea relaµiilor dintre funcµiunile ³i propri-

et µile expuse de noduri. Acest mod de lucru ne va putea conduce la ceea ce se poate

cali�ca drept con�guraµie autonomic . Se va demonstra modul cum procesele de plani�-

care sunt abordate ca probleme de constrângeri ce automatizeaz  ³i valideaz  procesul de

decizie în cadrul buclelor autonomice.

5.1.1 De�nirea constrângerilor. Modelare

Privit  într-o perspectiv  generic  o constrângere poate � de�nit  drept �o relaµie

complet de�nibil  între anumite variabile� [99]. Ca parte a unui model de reprezentare a

realit µii se poate considera c  variabilele nu sunt toate libere, vizibile global, ci se pot

structura de o manier  orientat  pe obiecte în tipuri de obiecte de�nite dup  anumite

tipare. Fiecare variabil  are tip propriu ³i este restricµionat  s  aib  asignat  o valoare

într-un anumit interval din acest tip în timp ce constrângerile pot restrânge plaja de

variaµie ³i dependenµa între diferitele valori luate de un set de variabile. Se observ , în

acest caz, faptul c  datorit  caracterului declarativ al constrângerilor acestea speci�c 

strict relaµiile ce trebuiesc a � satisf cute f r  a se speci�ca o procedur  de programare

care s  pun  în aplicare acea relaµie. CSP poate � considerat  ca �ind format  dintr-o

reµea de constrângeri de�nite pe un set de variabile [100], iar o soluµie reprezint  o instanµ 

a variabilelor care satisface totalitatea constrângerilor, despre care se poate speci�ca dac 

sunt constrâgeri obligatorii (hard constraints), trebuiesc acoperite strict ³i complet de

soluµie, ori constrângeri cu obligativitate parµiala - soft constraints, atunci când soluµia

este considerat  acceptat  chiar ³i în cazul acoperirii parµiale a acestora [101].

5.1. Sisteme cu constrângeri 45

Din punct de vedere al modelului implementabil o reµea de constrângeri poate � re-

prezentat  de un graf (graful constrângerilor) [97], unde �ecare nod reprezint  o variabil 

iar arcele conectând toate nodurile ale c ror variabile aparµin sistemului de constrângeri

al problemei exprimate. Absenµa unui arc între dou  noduri indic  faptul c  nu exist 

constrângere direct  între acestea. Acest mod de percepµie a constrângerilor ne conduce

la constatarea c  dou  reµele de constrângeri sunt echivalente dac  se manifest  asupra

unui set identic de variabile ³i expun aceea³i familie de soluµii indiferent de modul în care

sunt implementate.

5.1.2 Rezolvarea constrângerilor

Conceptual, de³i soluµiile reµelelor de constrângeri sunt g site prin c utarea în spa-

µiul de soluµii, valoarea real  a abord rii const  în capacitatea solverului de a propaga

schimb rile de-a lungul constrângerilor in�uenµate cu scopul de a satisface complet toate

constrângerile componente. În perspectiva percepµiei ca graf, acest lucru înseamn  vizi-

tarea complet , aciclic  a tuturor nodurilor ³i includerea în soluµie a variabilelor având

valori conforme dependenµelor dintre ele.

Euristicile de c utare acµioneaz  asupra tuturor opµiunilor din spaµiul de soluµii pro-

pagând întreg subsetul de constrângeri prealabil determinat prin inferenµ . În mod tipic

se poate constata c  �ecare tip de constrângere identi�cat are asociat un anumit algoritm

de propagare capabil s  asigure nivelul de consistenµ  impus. Propagarea constrângerilor

continu  pân  când nicio alt  constrângere nu este activat  de variabilele nou �xate ³i

toate constrângerile active se a�  în starea de consistenµ  a³teptat  � adic  satisf cute în

toate variabilele componente. În cazul spaµiului de c utare segmentat se poate considera

c  soluµia unui subspaµiu de c utare este consistent  local dac  subsetul de constrângeri

identi�cat ³i izolat este satisf cut. Dac  la orice etap  din c utare propagarea constrân-

gerilor conduce la o valoare nevalid  a uneia sau a mai multor variabile, c utarea face

un pas înapoi într-un subset valid anterior (backtracking) ³i exploreaz  o alt  variant  de

propagare ³i incrementare a spaµiului de soluµii. Astfel de decizii se bazeaz  pe experienµa

anterior acumulat  în observarea balanµei de câ³tig în ceea ce înseamn  timpul ³i memo-

ria necesare pentru a menµine constrângeri globale complexe ori în a impune consistenµa

în �ecare etap  de propagare tuturor constrângerilor. În acest sens se poate considera

46 Capitolul 5. Recon�gurarea nodurilor autonomice. Utilizarea constrângerilor

c  un solver realizeaz  un compromis posibil între e�cienµ  ³i completitudine. În funcµie

de domeniul de aplicare un solver poate � direcµionat pentru a alege diferite strategii.

Se observ  faptul c  o problem  poate � modelat  în termeni de constrângeri în moduri

diferite ducând la strategii posibil divergente de rezolvare. Din acest punct de vedere, mo-

delarea e�cient  pe baza de constrângeri reprezint  un rezultat combinat al cunoa³terii

domeniului de modelat precum ³i al mecanismelor solverului selectat.

5.1.3 Algoritmi destinaµi rezolv rii constrângerilor

În cele ce urmeaz  se vor prezenta, pe scurt, o serie de algoritmi reprezentativi folosiµi

la rezolvarea reµelelor de constrângeri. În literatura de specialitate [100], [108], [109] este

identi�cat un num r de familii de algoritmi folosiµi de solvere: c utarea prin salt înapoi

(backtracking/backjumping), c utarea local  ³i programarea dinamic .

Algoritmii de c utare de tip backtracking sunt cei mai folosiµi în mod curent în prac-

tic . De³i ofer  soluµii complete ³i optimale, acestea vin cu preµul unui cost exponenµial

în raport cu dimensiunea problemei în ceea ce înseamn  timpul de rezolvare ³i memoria

necesar , deoarece se poate întâmpla ca spaµiul de c utare s  �e explorat ine�cient, în

orb. Oricum, în practic  este o situaµie destul de rar  necersitatea de a se g si toate

soluµiile posibile la o CSP. Deoarece exploreaz  incremental spaµiul de c utare, algoritmii

de tip backtracking vor g si secvenµial soluµiile posibile. În cei peste 40 de ani de când

este studiat, algoritmul backtracking a cunoscut diferite adapt ri destinate îmbun t µirii

locale a modului de alegere a c ii de c utare.

În ciuda progresului evident f cut domeniul algoritmilor compleµi, sistematici, meto-

dele de c utare reprezint  de foarte multe ori singura cale practic  de a rezolva instanµele

CSP de mari dimensiuni. De asemenea, datorit  �exibilit µii ace³ti algoritmi speci�ci

pot � adaptaµi pentru a optimiza modul de lucru pentru domenii speci�ce. Algoritmii de

c utare local  sunt potriviµi în mod natural pentru a rezolva probleme de optimizare în

probleme practice, cum ar � cele de plani�care a ocup rii unei linii �exibile de fabricaµie

[20].

5.2. Con�gurarea nodurilor distribuite cu funcµiuni autonomice în cazul scenariului de

distribuµie a materialelor47

5.1.4 Modele ³i platforme

Precum s-a menµionat anterior, CSP presupune o corelare corect  între model ³i sol-

ver. În aceast  secµiune se vor prezenta o serie de strategii ³i pachete de soluµii mai des

folosite în practic . Solverele au, în general, ca scop g sirea unei soluµii, optime sau nu,

dependent de precizarea unei funcµii de cost ori a tuturor soluµiilor posibile. În ceea ce

prive³te satisfacerea constrângerilor, de obicei liniare, metoda ce s-a impus este cea a pro-

gram rii liniare [100], care cunoa³te câteva categorii de soluµii documentate de literatura

de specialitate.

5.2 Con�gurarea nodurilor distribuite cu funcµiuni autonomice în cazul sce-

nariului de distribuµie a materialelor

În aceast  secµiune sunt prezentate, pentru un scenariu de distribuµie a materialelor

de construcµie, dou  template-uri care pot � utilizate pentru:

- alegerea secvenµei de locaµii în funcµie de orele la care trebuie s  se fac  distribuµia;

- selectarea autovehiculelor de transport în funcµie de cerinµele de stocare ale produ-

selor.

Pentru simpli�carea exprim rii se va folosi sintagma noduri autonomice cu privire

la nodurile ce fac parte din con�guraµii ce expun funcµiuni autonomice. Prin utilizarea

constrângerilor distribuite se garanteaz  con�gurarea ³i recon�gurarea valid  a sistemelor

distribuite ³i garantarea disponibilit µii funcµiilor sistemului de noduri de lucru, în cazul

dat al unui sistem logistic � autovindecarea ³i autocon�gurarea.

5.2.1 Alegerea secvenµei de locaµii prin care trebuie s  treac  un agent de

distribuµie

Dup  cum a fost menµionat în secµiunea 3.1 clienµii au posibilitatea s  selecteze un

anumit interval în care s  �e livrate produsele. Din acest motiv nodurile autonomice

au nevoie de un tipar de plani�care cu ajutorul c ruia s  poat  identi�ca secvenµa de

parcurgere a locaµiilor. descrierea acestui tipar a fost exclus  din acest  form  restrâns 

a tezei de doctorat.

48 Capitolul 5. Recon�gurarea nodurilor autonomice. Utilizarea constrângerilor

5.2.2 Plani�carea distribuµiei de materiale de construcµie

Un alt tipar de plani�care, utilizat pentru scenariul practic considerat, are rolul de a

obµine combinaµia de autovehicule care trebuie considerat  pentru a distribui materialele

de construcµie. Fiecare camion poate transporta doar un anumit volum, respectiv catego-

rie de produse în funcµie de caracteristicile acestora. Dup  cum a fost menµionat anterior

produsele au diverse cerinµe de transport. Categoriile produselor respectiv volumele aces-

tora sunt de�nite pe baza mulµimilor C={1,...,c} ³i V={1,...,v}. Acest lucru se declar  în

motorul de constrângeri cu ajutorul instrucµiunilor din listing-ul 5.1.

1 ncategory (C) .

nvolume (V) .

Listing 5.1: De�nirea categoriilor de materiale de construcµie ³i a volumelor acestora.

Se va considera c  trebuie transportate un set de produse de�nite prin mulµimea P

= {1,...,p}. Fiecare produs este caracterizat printr-un identi�cator PI{pi}, volum PV{v}

³i o categorie PC { c }, acestea �ind cuprinse în setul dat P= {1,...,p}, V={1,...,v},

C={1,...,c}. Instrucµiunile din listing-ul 5.2 sunt folosite pentru a înregistra materialelor

de construcµii care trebuiesc transportate în motorul de constrângeri.

nproducts (P) .

2 product (PI ,PC,PV) :− #in t (PI ) , PI>0, PI<=P, nproducts (P) ,

#in t (PC) , PC>0, PC<=C, ncategory (C) ,

4 #in t (PV, PV>0, PV<=V, nvolume (V) .

Listing 5.2: Înregistrarea materialelor de construcµii care trebuiesc transportate în motorul

de constrângeri.

În vederea livr rii materialelor de construcµie la clienµi se are la dispoziµie un set de

autovehicule T={1,...,t} care pot transporta produse având un volum maxim VTruck{v},

pentru �ecare categorie CTruck{c} pe care o poate livra. Un autovehicul este identi�cat

prin intermediul variabilei TI{pi} ³i are volumul TV{v}, respectiv categoria TC{c}, aces-

tea �ind cuprinse în setul dat P = {1,...,p}, V = {1,...,v}, C = {1,...,c}. Listing-ul 5.3

prezint  instrucµiunile folosite pentru a înregistra în motorul de constrângeri autovehicule

care sunt disponibile pentru a realiza distribuµia.

ntrucks (T) .

5.3. Concluzii 49

2 truck (TI ,TC,TV) :− #in t (TI ) , TI>0, TI<=T, ntrucks (T) ,

#in t (TC) , TC>0, TC<=C, ncategory (C) ,

4 #in t (TV, TV>0, TV<=V, nvolume (V) .

Listing 5.3: Înregistrarea în motorul de constrângeri a autovehiculelor care sunt

disponibile pentru a realiza distribuµia.

Un camion poate s  transporte un set de produse, de�nit ca o submulµime a lui P

dac  acestea respect  urm toarele constrângeri:

- nu dep ³e³te volumul acestuia;

- nici un produs nu este asociat pentru livrare unui al autovehicul;

- autovehiculul, respectiv produsele trebuie s  aib  aceea³i categorie.

Cele trei constrângeri de�nite anterior, se pot înc rca în motorul de constrângeri fo-

losind instrucµiunile prezentate în listing-ul 5.4.

:− truck (T,C1 ,V1) , not #sum {V: at (P,T,V) } <= V1 .

2 :− product (P,C,V) , not #count{T : at (P,T,V) }=1.

:− trunk (T,C,V) , product (P,C1 ,V1) , C=C1 , at (P,T,V) .

Listing 5.4: Setul de constrângeri pe care trebuie s  le îndeplineasc  un produs P pentru

a putea s  �e transportate de un camion T.

Variabila de decizie a problemei este reprezentat  de setul at(P,T,V) (v. listing 5.4)

prin care sunt reprezentate asocierile dintre autovehicule ³i produselor ce urmeaz  a �

transportate.

5.3 Concluzii

În capitolul curent au fost parcurse fundamentele teoretice ³i practice ale program rii

bazate pe constrângeri precum ³i a modului în care se genereaz  con�guraµii valide de

scar  larg . Au fost prezentate avantajele fundamentale ale utiliz rii mecanismelor de

con�gurare ³i recon�gurare dinamic  utile implement rii capabilit µilor de autocon�gu-

rare ³i autovindecare ale sistemelor autonomice compuse din noduri distribuite.

S-au trecut în revist  ³i au fost comentate tehnicile ³i algoritmii relevanµi utilizaµi

în problemele de rezolvare a constrângerilor ³i au fost puse în evidenµ  euristicile prin

50 Capitolul 5. Recon�gurarea nodurilor autonomice. Utilizarea constrângerilor

care sunt abordate probleme de mari dimensiuni în relaµie cu modul de modelare al

constrângerilor din obiectele participante la con�guraµie.

Au fost prezentate platformele industriale de modelare ³i rezolvare a constrângerilor

precum ³i cele open source, ³i s-au pus în evidenµ  domeniile în care diferite platforme au

dat rezultate optime.

Pentru ilustrarea modului de lucru a fost ales un scenariu din domeniu logisticii care

a permis modelarea folosind Answer Set Programming a constrângerilor aplicabile unui

set de noduri autonomice a�at în interacµie cu scopul realiz rii unui scenariu comun.

S-a putut observa faptul c  abordarea aleas  nu depinde de capacit µile de calcul ale

�ec rui nod participant la con�guraµia autonomic , permiµând astfel dezvoltarea unui

model extins capabil s  acopere atât sisteme IT cât ³i non-IT funcµionând coerent.

Capitolul 6.

Mecanisme cognitive ³i baze de

cuno³tinµe

6.1 Mecanisme cognitive. Noµiuni introductive

În arhitectura iCore [61] (v. �g. 4.1) cogniµia joac  un rol central în îmbog µirea

comportamentului sistemului. Dincolo de a � un agregat de elemente ce reacµioneaz 

la stimulii de mediu conform unor reµete prefabricate, sistemul include suport pentru

modelele de predicµie.

Un exemplu relevant de implementare a arhitecturii este use case-ul �Smart Business�.

Modelele de predicµie folosesc ca date de intrare valorile m surate furnizate de diverse

tipuri de senzori: temperatur , umiditate, etc. Principalul scop este predicµia pe termen

scurt ³i mediu a evoluµiei temperaturii, dat  �ind perisabilitatea unor tipuri de m rfuri

transportate.

Un expert în domeniul logistic este a³teptat s  precizeze care sunt tr s turile (featu-

res) relevante în predicµia evoluµiei temperaturii. Ulterior, un expert în domeniul înv µ rii

automate (ML) este capabil ca, pe baza datelor monitorizate de c tre senzori s  propun 

unul sau mai multe modele de predicµie a temperaturii. Problema de rezolvat este una

51

52 Capitolul 6. Mecanisme cognitive ³i baze de cuno³tinµe

de înv µare supervizat  (se cunosc datele istorice, precum ³i valorile ulterioare ale tem-

peraturii), de predicµie a seriilor de timp multivariate, cu posibile date lips  (missing

values).

Esenµial în scenariul considerat este urm rirea modului în care se comport  modelul

de predicµie. Mai clar, se confrunt  periodic predicµiile modelului cu valorile actuale.

6.2 Modele de predicµie

În scenariul practic, prezentat în secµiunea 3.1 a fost menµionat faptul c  în ceea ce

prive³te compania de transport aceasta ofer  ³i servicii de transport a produselor speciale

(de exemplu, produse termosensibile). În aceast  situaµie pe lâng  monitorizarea st rii

produselor este oportun  ³i utilizarea unor mecanisme de predicµie a st rii viitoare pentru

acestea. În acest fel, pe baza predicµiilor, se pot genera alarme în timp util pentru angajaµii

companiei de transport.

În aceast  secµiune a tezei au fost prezentate pe larg detaliile de implementare ³i

modul în care a fost dezvoltat un model de predicµie care permite estimarea temperaturii

în interiorul unui camion în funcµie de m sur torile obµinute de la senzorii instalaµi pe

acesta.

6.3 Baze de cuno³tinµe

6.3.1 Tipare de monitorizare

Tiparele de monitorizare reprezint  o component  important  a bazei de cuno³tinµe

aferente SCDA. Acestea reprezint  un set de mecanisme generice care pot � con�gurate ³i

instanµiate pentru a monitoriza starea intern  a sistemului SCDA, respectiv a factorilor

relevanµi din mediul înconjur tor. Mai exact, aceste tipare sunt folosite pentru a asigura

etapele de monitorizare ³i analiz  din cadrul modelului MAPE-K. Capitolul 4 este dedicat

tehnicilor de monitorizare ³i analiz  a nodurilor autonomice ³i sunt date mai multe exem-

ple de tipare de monitorizare utilizate în cadrul implement rii scenariului de distribuµie

a materialelor de construcµie.

6.3. Baze de cuno³tinµe 53

6.3.2 Tipare de plani�care

Acest tip de tipare sunt con�gurate ³i instanµiate în cadrul etapei de plani�care a

modelului MAPE-K. Tiparele de plani�care sunt utilizate de c tre nodurile autonomice

pentru a decide care sunt acµiunile pe care trebuie s  le urmeze în momentul în care starea

acestora se modi�c . Capitolul 5 prezint  pe larg tiparele de plani�care, care, pe lâng 

tiparele de monitorizare, reprezint  o component  important  a bazei de cuno³tinµe din

cadrul SCDA.

6.3.3 Tipare de orchestrare ³i execuµie

Ultima etap  a modelului MAPE-K o reprezint  cea de execuµie. În acest moment

nodul autonomic trebuie s  pun  în aplicare soluµia rezult  din etapa de plani�care. În

cele mai multe cazuri soluµia care trebuie executat  este reprezentat  de o secvenµ  de

activit µi care trebuiesc îndeplinite. Din acest motiv se preteaz  utilizarea unui format

standard, care s  descrie succesiunea etapelor din secvenµa de execuµie, ³i care s  poat 

s  �e interpretat cu u³urinµ  de aplicaµiile software, respectiv utilizatorul uman. La ora

actual  exist  mai multe limbaje, cu mediile de dezvoltare aferente, care permit modelare

proceselor, dintre care se pot aminti: BPMN (Business Process Model and Notation)

[122], EPC (Event-driven Process Chain) [123], UML (Uni�ed Modeling Language) [124].

În �gura 6.1 este prezentat tiparul de execuµie, utilizând standardul BPMN, care

poate � utilizat de un nod autonomic pentru a duce la bun sfâr³it procesul de distribuµie

a materialelor de construcµie.

Tiparul de execuµie porne³te în momentul în care este generat evenimentul Start proces

distribuµie.

Prima activitate pe care o realizeaz  agentul este cea de contactare a clientului. În

cazul în care clientul nu este disponibil se trece la clientul urm tor sau se �nalizeaz 

procesul de distribuµie (dac  nu mai sunt clienµi disponibili).

Pentru situaµia în care clientul este disponibil, agentul va calcula ruta optim  c tre

locaµia clientului folosind algoritmul prezentat în secµiunea 5.2.1. Dup  ce se obµine ruta

se pornesc în paralel dou  activit µi: achiziµia ³i �ltrarea evenimentelor de tra�c cu scopul

de a identi�ca eventualele incidente care ar putea perturba activitatea de deplasare, ³i

deplasarea c tre locaµie.

54 Capitolul 6. Mecanisme cognitive ³i baze de cuno³tinµe

Figura 6.1: Tiparul utilizat de un nod autonomic pentru a executa procesul de distributiea materialelor.

6.4. Concluzii 55

Ambele activit µi se opresc în momentul în care agentul de distribuµie ajunge la des-

tinaµie. În continuare, în cazul în care comanda de distribuµie nu este �nalizat  se con-

tacteaz  urm torul client.

În �nal, dup  ce agentul a trecut pe la toµi clienµii disponibili se genereaz  raportul

procesului de distribuµie ³i se emite evenimentul care marcheaz  �nalizarea acestui proces.

6.3.4 Descrierea semantic  a resurselor din sistemul SCDA

Sistemul SCDA conµine ³i un ansamblu de algoritmi/modele care pot � utilizaµi pentru

a monitoriza ³i controla sistemul, cum ar �: tiparele de monitorizare, plani�care, execuµie

³i modelele de predicµie.

Având în vedere speci�cul autonomic al sistemului SCDA, acesta trebuie s  aib  po-

sibilitatea de a identi�ca caracterisiticile �ec rei resurse. De exemplu, pentru un spaµiu

de stocare este util s  poat  s  obµin  informaµii despre adresa acestuia, dimensiunile

acestuia ³i eventual dac  are sau nu instalat un sistem de climatizare.

Pe lâng  descrierea efectiv  a resurselor, trebuie de�nite diferite constrângeri între

acestea.

În cadrul SCDA au fost folosite tehnologiile semantice pentru a descrie, de�ni con-

strângeri de compatibilitate ³i descoperii resursele sistemului. Documentele RDF astfel

rezultate sunt stocate într-o baz  de data specializat  în persistarea datelor care respect 

formatul de triple (triple store).

6.4 Concluzii

Acest capitol este dedicat mecanismelor cognitive ³i a bazelor de cuno³tinµe care tre-

buiesc avute în vedere ³i proiectate corespunz tor în momentul în care se dezvolt  un

sistem SCDA. Luând în considerare faptul c  sistemul SCDA este bazat pe arhitectura

MAPE-K, bazele de cuno³tinµe reprezint  acele mecanisme generice care sunt utilizate

de nodurile autonomice pentru a executa etapele de monitorizare, analiz , plani�care ³i

execuµie.

Din acest motiv, în cadrul sistemului SCDA baza de cuno³tinµe conµine:

- tipare de monitorizare bazate pe tehnicile CEP pentru a implementa procedurile de

percepµie sistemic , respectiv percepµie a mediului înconjur tor, care sunt rulate în

56 Capitolul 6. Mecanisme cognitive ³i baze de cuno³tinµe

etapele de monitorizare ³i analiz ;

- tipare de plani�care bazate pe constrângeri pentru a implementa etapa de plani�-

care;

- tipare de execuµie bazate pe modele BPMN care le permit nodurilor autonomice s 

îndeplineasc  sarcinile alocate acestora;

- modele de predicµie care, în combinaµie cu tiparele de monitorizare, asigur  compo-

nenta de analitic  predictiv  a sistemului SCDA;

- cuno³tinµe despre sistem ³i mediul înconjur tor care folosesc tehnologiile seman-

tice pentru a descrie infrastructura (senzori, infrastructur  mobil /imobil ), modele

(diversele tipare ³i modele de predicµie) care sunt disponibile în sistemul SCDA (de

asemenea, tehnologiile semantice permit descoperirea cu u³urinµ  a acestor resurse.)

În cadrul sistemului SCDA modele de predicµie combinate cu cuno³tinµele de sistem,

respectiv diversele tipare, reprezint , de fapt, mecanismele cognitive ale acestuia.

Capitolul 7.

Validarea experimental 

Sistemul SDCA, a c rui arhitecur  este propus  în capitolul 3, a fost utilizat pentru

a dezvolta o aplicaµie cu ajutorul c reia se pot coordona agenµii de distribuµie ai unei

companii care livreaz  materiale de construcµie. Descrierea complet  a scenariului este

prezentat  în secµiunea 3.1.

Dezvoltarea, ³i mai ales testarea, unui astfel de prototip impune accesul la o infras-

tructur  dintr-un ora³ de la care se pot achiziµiona date de tra�c ³i la un grup de agenµi

de distribuµie care s  execute comenzile generate de sistem. Pe lâng  aceasta se im-

pune testarea sistemului sub diferite condiµii de tra�c, ³i mai ales înc rcare a procesului

de transport. Din acest motiv, s-a utilizat platformele CoReMo (Constrains Responsive

Mobility) ³i un emulator din domeniul logistic.

Emulatorul din domeniul logistic permite emularea condiµiilor de transport din inte-

riorul unui autovehicul. În felul acesta se pot emula procesele de înc rcare/desc rcare

ale unor produse în autovehicul, se poate modi�ca starea instalaµiei de climatizare ³i se

poate modi�ca temperatura extern . În plus, platforma permite instalarea de senzori

pe produsele transportate ³i în felul acesta se pot achiziµiona în timp-real m sur tori de

temperatur  ³i umiditate.

57

58 Capitolul 7. Validarea experimental 

7.1 Platforme utilizate pentru testarea SDCA

Pentru testarea experimental  a sistemului SDCA au fost folosite platfoma CoREMo

³i un emulator din domeniul logistic. Simularea tra�cului din mediul urban a fost f -

cut  cu ajutorul platformei CoReMo. Aceasta permite personalizarea comportamentelor

pentru diferiti agenµi care pot juca rolul de autovehicule sau elemente de infrastructur 

(semafoare, indicatoare rutiere etc.). Emulatorul din domeniul logistic a permis emularea

condiµiilor de transport a materialelor de construcµie în interiorul unui autovehicul.

7.1.1 Platforma CoReMo

CoReMo este o platform  software dezvoltat  de c tre Siemens Corporate Technology

Romania cu scopul de a furniza un mediu de testare pentru sisteme cu recon�gurare

dinamic . Componenta cadru CoReMo Core, a c rei schem -bloc este prezentat  în

Figura ??, este construit  folosind platforma de simulare Repast Simphony [130], [131] ³i

derivat  din simulatorul RepastCity [132].

Ea este compus  dintr-un simulator de tra�c urban, cu module de generare ³i procesare

a datelor ce pot � ata³ate ulterior. CoReMo urm re³te paradigma sistemelor multiagent în

care modelarea ³i execuµia comportamentului agenµilor se realizeaz  folosind formalismul

reµelelor Petri. Platforma furnizeaz  capacitatea de procesare a datelor (starea agenµilor,

condiµiile mediului simulat, interacµiunile dintre agenµi etc.) în dou  moduri: centralizat

� prin transmiterea datelor c tre o entitate care proceseaz  date din surse multiple (mai

precis un server CEP); distribuit � la nivel de agenµi sau la entit µi de procesare distribuite.

De asemenea, sunt incluse ³i mecanisme decizionale atât la nivelul agenµilor cât ³i globale,

cu scop de coordonare.

7.1.2 Emulatorul din domeniul logistic

Emulatorul pune la dispoziµie o interfaµ  REST ( Representational State Transfer) ³i

una MQTT (Message Queue Telemetry Transport) prin intermediul c rora o aplicaµie se

poate conecta la resursele emulate.

De asemenea, emulatorul îi permite utilizatorului s  încarce ³i s  ruleze diferite scenarii

de simulare. Pe baza acestor scenarii, generatorul de stimuli va varia temperatura extern 

a autovehiculului emulat ³i va modi�ca modul de lucru al instalaµiei de climatizare. În

7.2. Testarea modulului de monitorizarea ³i analiza a st rii SCDA 59

plus, emulatorul pune la dispoziµia utilizatorului o interfaµ  gra�c  cu care acesta poate

transmite diverse comenzi suplimentare ³i poate monitoriza variaµia temperaturii interne

prin intermediul unei h rµi termice. Interfaµa gra�c  este prezentat  în �gura 7.1.

Figura 7.1: Interfaµa gra�c  a emulatorului din domeniul logistic.

7.2 Testarea modulului de monitorizarea ³i analiza a st rii SCDA

Testarea modulului de monitorizare ³i analiz  a st rii nodurilor distribuite autonomice

a constat de fapt în evaluarea puterii de procesare consumate de acesta în scopul g sirii

unei valori limite. S-a considerat un scenariu în care 1000 de camioane, având �ecare 50

de senzori si actuatori, generau �uxuri continue de evenimente. În aceast  situaµie vârful

ratei de evaluare a evenimentelor a dep ³it 1200 de evenimente pe secund . De asemenea,

în motorul de CEP au fost înc rcate 1400 de interog ri active reprezentate de listing-urile

din secµiunea 4.3.2.

Din punct de vedere al infrastructurii de testare s-a utilizat un calculator Intel i5-2410

cu procesor 2.30 GHz, 4GB de Ram, interfaµ  ethernet de 1GB pe care a fost instalat

sistemul de operare Windows pe 64 biµi.

60 Capitolul 7. Validarea experimental 

7.3 Testarea modului de recon�gurare a nodurilor autonomice

În aceast  situaµie s-a avut în vedere determinarea timpului maxim necesar pentru

obµinerea unei soluµii de recon�gurare a rutei la nivel de agent sau a modului de plani�care

a procesului de distribuµie la nivel de dispecer.

7.4 Testarea modelelor de predicµie

În aceast  secµiune este prezentat modul în care au fost validate modelele de predicµie

utilizate în cadrul SCDA. S-a avut în vedere demonstrarea ³i validarea modului în care

se pot înc rca modele de predicµie în motorul de CEP în timp ce acesta funcµioneaz .

7.5 Testarea prototipului

Pentru testarea prototipului, platforma CoReMo a fost con�gurat  s  emuleze tra�cul

din ora³ul Bra³ov. De asemenea, au fost activaµi un set de agenµi care pot realiza distribu-

µia materialelor ³i au fost transmise cererile de transport. În �gura 7.2 este prezent  ruta

recomandat  unui agent de distribuµie pentru a duce la bun sfâr³it procesul de livrare.

Figura 7.2: Ruta recomandat  unui agent de distribuµie pentru a duce la bun sfâr³itprocesul de livrare.

De asemenea, în �gura 7.3 este prezentata ruta alternativ  recomandat  agentului de

distribuµie, în momentul în care a fost detectat un ambuteiaj care perturb  procesul de

distribuµie.

7.6. Concluzii 61

Figura 7.3: Ruta alternativ  recomandat  agentului de distribuµie, în momentul în carea fost detectat un ambuteiaj care perturb  procesul de distribuµie.

7.6 Concluzii

În acest capitol au fost prezentate rezultatele experimentale obµinute în urma im-

plement rii sistemului SDCA folosit  platforma CoReMo ³i un emulator din domeniul

logistic. De asemenea, a fost prezentat modul în care scenariul suport se mapeaz  pe

aceast  platform  ³i modul în care funcµiunile autonomice sunt puse în evidenµ .

Luând în considerare faptul c  toate experimentele practice au fost realizate pe un

calculator de uz general ³i c  num rul de agenµi folosiµi este comparabil cu cel ar unei

cu cel al unei companii de dimensiuni medii, se poate concluziona c  aplicaµia care im-

plementeaz  scenariul considerat are performanµele de funcµionare necesare unei aplicaµii

mature.

De asemenea, prin scalarea pe orizontal  sau pe vertical  a resurselor de procesare

aplicaµia dezvoltat  are posibilitatea s  asigure cerinµele necesare de funcµionare pentru

un sistem de distribuµie de mari dimensiuni.

În ultima parte a capitolului s-a ar tat modul în care se poate monitoriza în timp

real un proces (în acest caz particular cel de distribuµie a materialelor termosenzitive)

prin intermediul unui model de predicµie integrat într-o interogare dintr-un motor de

CEP. Acest lucru faciliteaz  în primul rând trecerea de la monitorizarea descriptiv  a

62 Capitolul 7. Validarea experimental 

unui proces la cea predictiv . Acest  abordare poate � utilizat  cu succes în multe alte

domenii nu doar cel de distribuµia a materialelor.

De asemenea, modulul de monitorizare predictiv a unui proces pune la dispoziµia uti-

lizatorului o interfaµ  gra�c  prin care se pot evalua performaµele modelului de predicµie.

În plus, pentru situaµia în care performaµele modelului nu sunt satisf c toare se poate

reantrena ³i desc rca modelul f r  s  �e nevoie ca sistemul s  �e oprit.

Capitolul 8.

Concluzii

Arhitecturile bazate pe calcul autonomic ³i extensia acestora la mediul distribuit , inclusiv

în ceea ce este considerat autonomic networking reprezint  un important pas înainte în

ceea ce înseamn  controlul automat adaptiv al infrastructurilor complexe. Astfel de arhi-

tecturi prezint  provoc ri speci�ce date de eterogenitatea inerent  a sistemelor ce ajung

s  interacµioneze. Din acest motiv, complexitatea observat  trebuie s  �e tratat  ³i dis-

tribuit  realist atât în ceea ce înseamn  abordarea etapelor de monitorizare ³i analiz  cât

³i consistenµa dorit  a plani�c rii adapt rii ³i a modului de propagare minim con�ictuale

a acesteia în toate componentele sistemului. Aceste cerinµe ridic  un num r de provoc ri

speci�ce în ceea ce prive³te consistenµa la nivel de modelare, guvernanµa ³i monitorizarea

continu  a rezultatelor execuµiei dorite.

Funcµiunile autonomice au ³ansa de a schimba semni�cativ modelele de business ale

unor companii orientate intensiv c tre necesit µile operaµionale curente. În acest context

industria telecomunicaµiilor a reprezentat ³i reprezint  un exemplu de adaptare ³i deschi-

dere �ind una dintre cele ce au cercetat ³i au adoptat devreme strategii de valori�care ale

elementelor speci�ce controlului autonomic. Aceasta abordare este dat  de necesitatea de

a avea politici controlabile ale eterogenit µii echipamentului (scump dar cu o rat  mare

63

64 Capitolul 8. Concluzii

de depreciere pe o piaµ  intens concurenµial ), dar mai ales pentru a putea inova în ceea

ce înseamn  modelele de business, unde serviciile tradiµionale de voce ³i transport de date

nu pot genera pro�t adiµional.

În aceast  lucrare am tratat subiectul încorpor rii mecanismelor cognitive în funcµiu-

nea de analiz  a sistemelor de control autonomice ³i aplicarea mecanismelor bazate pe

constrângeri pentru realizarea unei plani�c ri sensibile la context.

În mod similar conceptului iniµial al controlului autonomic, teza ³i-a propus s  extind 

arhitectura existent  în a³a fel încât s  �e încorporate atât artifacte IT conectate cât ³i

procese ³i actori din lumea tangibil . Pentru a face acest lucru s-au folosit referinµe teh-

nologice cu rezultate dovedite în domenii de activitate ³i a c ror performanµ  era critic .

Teza a fost structurat  în a³a fel încât s  se permit  introducerea gradual  a compo-

nentelor arhitecturale, a modului în care ciclul de control autonomic este implementat, a

tehnologiilor ata³ate ³i scenariului suport considerat. S-au prezentat, în �nal, validarea

experimental  a scenariului propus ³i au fost comentate detaliile de implementare.

Alegerea a fost motivat  de observarea unor oportunit µi practice derivate din expe-

rienµa direct  cât ³i din proiectele de cercetare la a c ror elaborare conceptual , imple-

mentare ³i valorizare am participat ³i particip. Deoarece subiectul este într-o continu 

extindere ³i maturizare se poate considera c  subiectele speci�ce de cercetare ³i de valo-

ri�care industrial  sunt considerabile.

8.1 Contribuµii personale

La elaborarea acestei teze am bene�ciat de interacµia direct  ³i extrem de util  atât cu

echipa din care fac parte cât ³i cu experµi de renume din centre ce cercetare industrial  ori

universitar  din Europa ³i SUA. Acest fapt a ajutat semni�cativ la focusarea subiectelor

abordate ³i la abordarea subtemelor tehnice relevante. Faptul c  cele mai multe din

proiectele abordate au fost ori sunt parte din domeniul IoT ori Cloud/Data Centers a

ajutat la elaborarea unei arhitecturi pragmatice ³i sincrone cu capabilit µile reale ale unui

mediu distribuit.

Contribuµiile personale listate mai jos reprezint  rezultate elaborate ³i testate având,

de asemenea, ca obiectiv utilizarea rezultatelor în proiecte industriale. Domeniul general

de cercetare adresat este cel la monitoriz rii ³i controlului automat al unor infrastructuri

8.1. Contribuµii personale 65

distribuite.

Deoarece urm toarea secµiune prezint  lista tuturor lucr rilor ce conµin total sau par-

µial rezultatele muncii depuse la elaborarea tezei acestea au fost numerotate pentru u³u-

rinµa identi�c rii. Toate aceste lucr ri se a�  ³i în bibliogra�a consolidat  ata³at .

Cele mai relevante contribuµii sunt:

- analiza modelelor ³i implement rilor curente de sisteme autonomice;

Subiectul a fost abordat in-extenso în cadrul proiectelor de cercetare citate în tez 

³i a detaliat atât aspecte ale platformelor tehnice (IoT, Cloud, Data Centers) cât ³i

ale domeniilor de aplicare, cu prec dere în ceea ce înseamn  Ora³ele Inteligente cât

³i infrastructuri speci�ce precum Smart Grids. Rezultatele au fost diseminate în 1,

2, 4, 8, 9, 10, 12, 13, 14.

- arhitectura de sistem distribuit cu caracteristici autonomice;

Precum s-a expus in capitolul 7, platformele CoReMo ³i iCORE au fost dezvoltate

de-a lungul tezei ³i au fost utilizate pentru a valida funcµiunile propuse. Subiectul

a fost tratat ³i diseminat în 2,3,4 10, 12, 13, 14.

- de�nirea ³i implementarea fazelor conceptuale calculului autonomic;

Acest subiect este strâns legat de primele dou  subiecte ³i a fost diseminat în acelea³i

publicaµii.

- modelarea ³i implementarea fazei de monitorizare pe baz  de CEP;

Monitorizarea ³i analiza reprezint  etape critice în realizarea buclei MAPE-K. Su-

biectul a fost detaliat prioritar în capitolul 4. Rezultatele cercet rii au fost disemi-

nate în 2,3,8,10,13.

- modelarea ³i implementarea fazei de analiz  cu suport de calcul cognitiv pentru

realizarea analizei predictive;

Acest subiect de cercetare este corelat celui anterior ³i rezultatele au fost tratate în

acelea³i publicaµii.

- arhitectura unui sistem distribuit cu capabilit µi de calcul cognitiv bazat pe inte-

grarea Machine Learning în �ltrarea CEP;

66 Capitolul 8. Concluzii

Acest subiect a fost abordat în proiectele CoReMo, iCORE ³i CityPulse ³i reprezint 

abordarea propus  în tez  pentru optimizarea etapelor de monitorizare ³i analiz .

Rezultatele obµinute au fost tratate în 2, 4, 8, 9, 10, 12, 13, 14.

- modelarea ³i implementarea plani�c rii ³i replani�c rii pe baz  de Constrângeri

Distribuite;

Tematica plani�c rii a fost abordat  în contextul cazurilor din logistic / transport

³i optimizarea sistemelor de fabricaµie. Rezultatele au fost prezentate în 5, 6, 7, 8.

- modelarea ³i implementarea execuµiei ca mediu de calcul distribuit de tip IoT;

Dup  cum s-a prezentat de-a lungul tezei ecosistemele de tip IoT au fost alese pentru

a ilustra problema abordat  în tez  deoarece ridic  provoc ri speci�ce sistemelor

distribuite ce pot bene�cia direct de autonomic networking. Subiectul a fost abordat

în proiectele iCORE, IOT.est, CityPulse, COSMOS ³i RERUM, iar rezultatele au

fost prezentate în 1,2,3, 4, 10, 11, 12, 13, 14, 15.

- modelarea bazelor de cuno³tinµe pe baza tehnologiilor semantice;

Modelele de cuno³tinµe ata³ate atât resurselor de observaµie, actualizare ³i comuni-

caµie , proceselor ori �uxurilor de date ³i evenimente produse ³i consumate, au fost

utilizate pentru a sprijini selecµia optimizat  a acestora ³i deciziile dependente de

context. Rezultatele au fost prezentate în 4,9,11, 12, 14.

- modelarea ³i implementarea unui studiu de caz din domeniul logisticii;

Subiectul a fost prezentat în detaliu în capitolele Precum s-a expus in capitolele 6

³i 7.

8.2 Diseminarea rezultatelor

Rezultatele prezentate în aceasta tez  reprezint  o parte din efortul depus în ultimii

ani într-un num r relevant de proiecte de cercetare �nanµate de c tre Comisia European 

dar ³i rezultate obµinute din cercetarea industrial . Datorit  amplitudinii subiectelor

abordate, acestea sunt re�ectate pe segmente corelate în articolele publicate. De aseme-

nea, efortul a contribuit atât la teza prezentat  cât ³i la rezultatele unui întreg grup de

cercetare.

8.2. Diseminarea rezultatelor 67

Aceste rezultate s-au materializat prin publicarea în calitate de prim autor sau coautor

a unui num r de 15 lucr ri ³tiinµi�ce. Lista bibliogra�c  proprie conµine: 9 lucr ri ISI, 3

lucr ri indexate în bazele de date internationale ³i 3 capitole de c rµi publicate în edituri

internaµionale recunoscute.

a. Lucr ri ISI:

� (1) E. Z. Tragos, V. Angelakis, A. G. Fragkiadakis, D. Gundlegard, S. Nechifor, G.

C. Oikonomou, H. C. Pohls, and A. Gavras, �Enabling Reliable and Secure IoT-

based Smart City Applications�, in 2014 IEEE International Conference on Pervasive

Computing and Communication Workshops, PerCom 2014 Workshops, Budapest,

Hungary, March 24-28, 2014. IEEE, 2014, pp. 111-116.

� (2) S. Nechifor, B. Tarnauca, L. Sasu, D. Puiu, �Autonomic Monitoring Approach

based on CEP and ML for Logistic of Sensitive Goods�, 18th IEEE International

Conference on Intelligent Engineering Systems (INES), Tihany, Ungaria, 2014�pp:

67-72,.

� (3) S. Nechifor A. Petrescu, D. Damian, D. Puiu, and B. Tarnauca, �Predictive Ana-

lytics based on CEP for Logistic of Sensitive Goods�, 14th International Conference

on Optimization of Electrical and Electronic Equipment OPTIM, Brasov, Romania,

May 2014.

� (4) J. Poncela, P. Vlacheas, R. Gia�reda, S. De, M. Vecchio, S. Nechifor, R. Barco,

M. C. A. Torres, V. Stavroulaki, K. Moessner, and P. Demestichas, �Smart Cities

via Data Aggregation�, Wireless Personal Communications, vol. 76, no. 2, 2014,

pp. 149-168.

� (5) A. Gîrbea, C. Suciu, S. Nechifor, and F. Sisak, �Design and Implementation of

a Service-Oriented Architecture for the Optimization of Industrial Applications�,

IEEE Transactions on Industrial Informatics, Vol. 10, No. 1, 2014, pp. 185-196.

� (6) A. Gîrbea, S. Nechifor, F. Sisak, �E�cient Address Space Generation for an OPC

UA Server�, Software Practice and Experince, Vol 42, Issue 5, May, 2014, pp. 543-

557.

� (7) A. Gîrbea, S. Nechifor, F. Sisak, and L. Perniu, �Design and Implementation of

68 Capitolul 8. Concluzii

an OLE for Process Control Uni�ed Architecture Aggregating Server for a Group of

Flexible Manufacturing Systems�, IET Software, vol. 5, no. 4, 2011, pp. 406-414.

� (8) I. Cobeanu, B. Tarnauca, S. Nechifor, and V. Comnac, �Real-time Scheduling of

Mobile Agents Using Answer Set Programming�, 13th International Conference on

Optimization of Electrical and Electronic Equipment OPTIM, Brasov, Romania,

May, 2012, pp. 1505-1510.

� (9) A. Manzalini, P. H. Deussen, S. Nechifor, M. Mamei, R. Minerva, C. Moiso,

A. Salden, T. Wauters, and F. Zambonelli, �Self-Optimized Cognitive Network of

Networks�, Oxford Computer Journals, Vol. 54, No. 2, 2011, pp. 189-196.

b. Lucr ri BDI

� (10) S. Nechifor, D. Puiu, B. Târnauca, and F. Moldoveanu, �Prescriptive Analytics

based Autonomic Networking for Urban Streams Services Provisioning�, IEEE 81st

Vehicular Technology Conference, VTC Spring 2015, Glasgow, United Kingdom,

11-14 May, 2015. IEEE, 2015, pp. 1-5.

� (11) D. Ardagna, E. D. Nitto, G. Casale, D. Petcu, P. Mohagheghi, S. Mosser, P. Mat-

thews, A. Gericke, C. Ballagny, F. D'Andria, C. Nechifor, and C. Sheridan, �Mo-

daclouds: a Model-Driven Approach for the Design and Execution of Applications

on Multiple Clouds�, Proceedings of the 4th International Workshop on Modeling in

Software Engineering, MiSE 2012, Zurich, Switzerland, June 2-3, 2012, pp. 50-56.

� (12) G. Baldini, R. R. V. Prasad, A. R. Biswas, K. Moessner, M. Eteläperä, J. Soininen,

S. Nechifor, V. Stavroulaki, and P. Vlacheas, �A cognitive Management Framework

to Support Exploitation of the Future Internet of Things�, Scalable Computing:

Practice and Experience, vol. 13, no. 2, 2012.

c. Capitol de carte publicat  în editur  internaµional 

� (13) S. Nechifor, D. Puiu, B. Tarnauca, and F. Moldoveanu, �Autonomic Aspects of

IoT Based Systems: A Logistics Domain Scheduling Example�, Interoperability and

Open-Source Solutions for the Internet of Things, ser. Lecture Notes in Computer

Science, I. Podnar Zarko, K. Pripuzic, and M. Serrano, (Eds.), Springer Internatio-

nal Publishing, 2015, Vol. 9001, pp. 153-168.

8.3. Direcµii viitoare de cercetare 69

� (14) V. Foteinos, D. Kelaidonis, G. Poulios, V. Stavroulaki, P. Vlacheas, P. Demesti-

chas, R. Gia�reda, A. R. Biswas, S. Ménoret, G. Nguengang, M. Eteläperä, S.

Nechifor, M. Roelands, F. Visintainer, and K. Moessner, �A Cognitive Manage-

ment Framework for Empowering the Internet of Things�, The Future Internet -

Future Internet Assembly 2013: Validated Results and New Horizons, ser. Lecture

Notes in Computer Science, A. Galis and A. Gavras, (Eds.), Vol. 7858. Springer,

2013, pp. 187-199.

� (15) S. Nechifor �How to Manage and Search/Retrieve Information Objects�, Archi-

tecture and Design for the Future Iinternet: 4WARD PROJECT�, Book Series:

Signals and Communication Technology, Edited by: L.M. Correia; H. Abramowicz;

M. Johnsson, (Eds.); et al., 2011, pp. 201-223.

8.3 Direcµii viitoare de cercetare

Urm toarele subiecte prezentate reprezint  un num r de direcµii de cercetare ce sunt

parte a unor teme de actualitate practic . Ele nu sunt singurele subiecte relevante având

leg tur  cu controlul autonomic, ci doar teme pe care le consider a � de utilitate ridicat 

în urm torii 5 - 10 ani.

Subiectul controlului autonomic distribuit se a�  într-o faz  de maturizare ³i asimi-

lare industrial . Noi concepte arhitecturale precum Software De�ned Networks � SDN,

genereaz  oportunit µi de interes precum sunt:

- Transferul funcµiunilor analitice aproape de proces simultan cu generarea capacit µii

de federare a funcµiunilor f r  un control overlay;

- Modele de �abilitate ³i încredere în rezultate, atunci când monitorizarea distribuit 

se execut  în noduri de calcul diferite;

- Conceperea unor modele de imunitate la nivelul sistemelor, capabile s  înveµe din

experienµa altor reµele;

- Corelarea cu concepte precum Cloud Robotics, în care sisteme compuse din sisteme

IT, roboµi autonomi ³i infrastructuri de comunicaµii învaµ  s  coopereze pentru

atingerea unor obiective comune;

70 Capitolul 8. Concluzii

A doua direcµie interesant  de lucru poate � extinderea sistemelor de recomandare

cu capacit µi de analiz  a datelor de timp real ³i folosirea e�cient  în comun a unor

resurse precum sunt cele din zona Ora³elor Inteligente. Aceast  abordare poate ad uga

abilit µi de predicµie ³i adaptabilitate platformelor de servicii ³i deschiderea acestora spre

integrarea cu mediul non-IT.

O a treia oportunitate tehnologic  este reprezentat  de optimizarea automat  ³i ana-

liza modelelor de decizie. De³i astfel de abord ri nu sunt noi în implementarea sistemelor

informatice moderne, utilizarea lor în medii distribuite, zgomotoase, cu o eterogenitate

mare ³i cu modele de securitate ³i con�denµialitate a accesului la date ³i procese gene-

reaz  provoc ri relevante. Tehnologic, provoc rile speci�ce ating modul de utilizare al

constrângerilor discrete ori continue, selecµia modelelor de predicµie ³i evaluare a contex-

tului în medii cu grad sc zut de predictibilitate. Domeniile µint  posibile sunt cele din

mega-infrastructuri speci�ce aglomer rilor urbane, servicii de monitorizare ³i intervenµie

în sisteme de îngrijire personalizat  a s n t µii ori abord ri sustenabile de protecµie ³i

utilizare a resurselor naturale.

Dup  cum s-a detaliat de-a lungul tezei, procesele de autoap rare ³i autovindecare

sunt complementare, iar implementarea lor impune componente comune ori corelate ca ³i

funcµiune individual . De asemenea, s-a observat c  �abilitatea ³i disponibilitatea resur-

selor de procesare ori a surselor de date relevante ³i de încredere pot altera semni�cativ

calitatea ³i rezultatul proceselor vizate. Prin aplicarea în mecanismele cognitive servind

etapa de analiz  a unor strategii inspirate din lumea vie, se poate decide selecµia pre-

emptiv  de resurse ³i date, precum ³i ap rarea activ  a sistemului în faµa unor posibili

agresori. În aceast  direcµie va � interesant de descoperit modele de atac complexe ³i

disimularea funcµiilor sistemului autonomic.

Nu în ultimul rând o oportunitate relevant  de cercetare este cea legat  de modelele

de business prin care funcµiunile autonomice expuse de sisteme din domenii speci�ce pot

� valori�cate în domenii conexe ori complet noi. De exemplu, sistemele de calcul au

cunoscut o valori�care superioar  în cazul managementului de tip Cloud Computing ³i

acela³i lucru se întâmpl  prin virtualizarea ca ³i servicii web a obiectelor conectate - IoT.

Aceste subiecte reprezint  un pas important în dep ³irea limitelor de domeniu, atât în ceea

ce înseamn  domeniu internet/intranet cât ³i în ceea ce înseamn  domeniul de aplicare.

8.3. Direcµii viitoare de cercetare 71

Funcµiunile autonomice pot � folosite utilizând modele de contracte inovative (de ex.

închirierea temporar  de spaµiu securizat de efectuare a unor analize complexe de date)

ori apariµia unui nou rol în modelele de business, acela de broker infrastructuri temporare

capabile s  expun  un comportament autonomic. Un astfel de actor ar intermedia între

nevoia de funcµiuni ale actorilor economici ³i oferta de putere de calcul, spaµiu de stocare

a provider-ilor de Cloud ori a celor ce ofer  algoritmi performanµi.

Bibliogra�e

[1] J. O. Kephart and D. M. Chess, �The vision of autonomic computing,�

Computer, vol. 36, no. 1, pp. 41�50, Jan. 2003. [Online]. Available:

http://dx.doi.org/10.1109/MC.2003.1160055

[2] S. Dobson, R. Sterritt, P. Nixon, and M. Hinchey, �Ful�lling the vision of autonomic

computing,� IEEE Computer, vol. 43, no. 1, pp. 35�41, Jan 2010.

[3] D. A. Menasc and J. O. Kephart, �Guest editors' introduction: Autonomic compu-

ting,� IEEE Internet Computing, vol. 11, no. 1, pp. 18�21, 2007.

[4] M. Nami and M. Shari�, �A survey of autonomic computing systems,� in Intelligent

Information Processing III, ser. IFIP International Federation for Information

Processing, Z. Shi, K. Shimohara, and D. Feng, Eds. Springer US, 2007, vol. 228,

pp. 101�110. [Online]. Available: http://dx.doi.org/10.1007/978-0-387-44641-7_11

[5] R. Sterritt, �Autonomic computing,� Innovations in Systems and Software

Engineering, vol. 1, no. 1, pp. 79�88, 2005. [Online]. Available: http:

//dx.doi.org/10.1007/s11334-005-0001-5

[6] T. Beer, J. Rasinger, W. Höpken, M. Fuchs, and H. Werthner, �Exploiting

e-c-a rules for de�ning and processing context-aware push messages,� in Advances

in Rule Interchange and Applications, ser. Lecture Notes in Computer Science,

A. Paschke and Y. Biletskiy, Eds. Springer Berlin Heidelberg, 2007, vol. 4824, pp.

199�206. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-75975-1_19

[7] T. M. Mitchell, �The need for biases in learning generalizations,� Rutgers University,

New Brunswick, NJ, Tech. Rep., 1980.

73

74 Bibliogra�e

[8] ***, �Autonomic network architecture,� http://www.ana-project.org/, 2009.

[9] A. Manzalini and F. Zambonelli, �Towards autonomic and situation-aware commu-

nication services: the cascadas vision,� in Distributed Intelligent Systems: Collective

Intelligence and Its Applications, 2006. DIS 2006. IEEE Workshop on, June 2006,

pp. 383�388.

[10] R. Calinescu, General-Purpose Autonomic Computing. Springer, April 2009,

pp. 3�29. [Online]. Available: http://web.comlab.ox.ac.uk/people/Radu.Calinescu/

ACNchapter2008.pdf

[11] P. Cong-vinh, Formal and Practical Aspects of Autonomic Computing and Networ-

king: Speci�cation, Development, and Veri�cation, 1st ed. Hershey, PA: Informa-

tion Science Reference - Imprint of: IGI Publishing, 2011.

[12] M. Calisti, S. v. d. Meer, and J. Strassner, Advanced Autonomic Networking and

Communication (Whitestein Series in Software Agent Technologies and Autonomic

Computing), 1st ed. Birkh&#228;user Basel, 2008.

[13] ***, �Gpac autonomic framework,� http://www-users.cs.york.ac.uk/ raduc/project-

s/GPAC/gpac.html, 2014.

[14] J. Strassner, S. Kim, and J. W. Hong, �The design of an autonomic communication

element to manage future internet services,� in Management Enabling the Future

Internet for Changing Business and New Computing Services, 12th Asia-Paci�c

Network Operations and Management Symposium, APNOMS 2009, Jeju, South

Korea, September 23-25, 2009, Proceedings, 2009, pp. 122�132. [Online]. Available:

http://dx.doi.org/10.1007/978-3-642-04492-2_13

[15] ***, �D4.3 cvo and management fabric design,� iCore project deliverable, 2013. [ON-

LINE]: http://www.iot-icore.eu/public-deliverables.

[16] ***, �Fp7 ict cosmos,� http://iot-cosmos.eu/, 2014.

[17] ***, �Citypulse,� http://www.ict-citypulse.eu/page/, 2014.

Bibliogra�e 75

[18] S. Nechifor, A. Petrescu, D. Damian, D. Puiu, and B. Tarnauca, �Predictive Ana-

lytics based on CEP for Logistic of Sensitive Goods,� in 2014 14th International

Conference on Optimization of Electrical and Electronic Equipment (OPTIM), 2014.

[19] S. Nechifor, D. Puiu, B. Tarnauca, and F. Moldoveanu, �Autonomic aspects of

iot based systems: A logistics domain scheduling example,� in Interoperability

and Open-Source Solutions for the Internet of Things, ser. Lecture Notes in

Computer Science, I. Podnar Zarko, K. Pripuzic, and M. Serrano, Eds. Springer

International Publishing, 2015, vol. 9001, pp. 153�168. [Online]. Available:

http://dx.doi.org/10.1007/978-3-319-16546-2_12

[20] A. Gîrbea, C. Suciu, S. Nechifor, and F. Sisak, �Design and implementation of a

service-oriented architecture for the optimization of industrial applications,� IEEE

Trans. Industrial Informatics, vol. 10, no. 1, pp. 185�196, 2014. [Online]. Available:

http://dx.doi.org/10.1109/TII.2013.2253112

[21] B. Tarnauca, D. Puiu, V. Comnac, and C. Suciu, �Modelling a Flexible Manu-

facturing System Using Recon�gurable Finite Capacity Petri Nets,� in 2012 13th

International Conference on Optimization of Electrical and Electronic Equipment

(OPTIM), May 2012, pp. 1079�1084.

[22] J. Strassner, J. W. Hong, and S. van der Meer, �The design of an autonomic

element for managing emerging networks and services,� in Proceedings of the

International Conference on Ultra Modern Telecommunications, ICUMT 2009,

12-14 October 2009, St. Petersburg, Russia, 2009, pp. 1�8. [Online]. Available:

http://dx.doi.org/10.1109/ICUMT.2009.5345533

[23] ***, �Omg cim,� http://www.dmtf.org/sites/default/�les/standards/documents/DSP0231_1.0.0.pdf,

2010.

[24] ***, �Ponder,� http://www-dse.doc.ic.ac.uk/Research/policies/ponder.shtml, 2009.

[25] ***, �D3.2.2 modaclouds architecture � �nal version,� MODAClouds project delive-

rable, 2014.

76 Bibliogra�e

[26] E. D. Valle, �C-sparql platforms,� http://streamreasoning.org/download, 2013.

[27] ***, �D4.4 cvo proof of concept and validation,� iCore project deliverable, 2013.

[ONLINE]: http://www.iot-icore.eu/public-deliverables.

[28] G. Baldini, R. R. V. Prasad, A. R. Biswas, K. Moessner, M. Eteläperä,

J. Soininen, S. Nechifor, V. Stavroulaki, and P. Vlacheas, �A cognitive management

framework to support exploitation of the future internet of things,� Scalable

Computing: Practice and Experience, vol. 13, no. 2, 2012. [Online]. Available:

http://www.scpe.org/index.php/scpe/article/view/775

[29] V. Foteinos, D. Kelaidonis, G. Poulios, V. Stavroulaki, P. Vlacheas, P. Demestichas,

R. Gia�reda, A. R. Biswas, S. Ménoret, G. Nguengang, M. Eteläperä, S. Nechifor,

M. Roelands, F. Visintainer, and K. Moessner, �A cognitive management

framework for empowering the internet of things,� in The Future Internet - Future

Internet Assembly 2013: Validated Results and New Horizons, ser. Lecture Notes

in Computer Science, A. Galis and A. Gavras, Eds., vol. 7858. Springer, 2013,

pp. 187�199. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-38082-2_16

[30] ***, �W3c owl,� http://www.w3.org/TR/2012/REC-owl2-mapping-to-rdf-

20121211/, 2012.

[31] A. Calì, G. Gottlob, and A. Pieris, �Querying conceptual schemata with expressive

equality constraints,� in Conceptual Modeling - ER 2011, 30th International

Conference, ER 2011, Brussels, Belgium, October 31 - November 3, 2011.

Proceedings, 2011, pp. 161�174. [Online]. Available: http://dx.doi.org/10.1007/

978-3-642-24606-7_13

[32] E. Brewer, �Lessons from giant-scale services,� Internet Computing, IEEE, vol. 5,

no. 4, pp. 46�55, Jul 2001.

[33] ***, �Apache cassandra,� http://cassandra.apache.org/, 2015.

[34] L. et .all, �Toward autonomic computing with db2 universal database,�

http://www.sigmod.org/publications/sigmod-record/0209/lensilegman2.pdf, 2003.

Bibliogra�e 77

[35] J. Strassner, �Using autonomic principles to manage converged services in next

generation networks,� in Engineering of Autonomic and Autonomous Systems, 2007.

EASe '07. Fourth IEEE International Workshop on, March 2007, pp. 176�186.

[36] ***, �Openiot,� www.openiot.eu, 2014.

[37] Semantic Sensor Networks, http://www.w3.org/2005/Incubator/ssn/ssnx/ssn Std.

[38] ***, �Rerum: Reliable, resilient and secure iot for smart city applications,�

https://ict-rerum.eu/, 2015.

[39] S. Tarkoma, Overlay Networks, A. Publications, Ed. CRC Press, 2010.

[40] P. McKinley, F. Samimi, J. Shapiro, and C. Tang, �Service clouds: A distributed

infrastructure for constructing autonomic communication services,� in Dependable,

Autonomic and Secure Computing, 2nd IEEE International Symposium on, Sept

2006, pp. 341�348.

[41] J. E. S. B. Z. Chen, S. Haykin, Correlative Learning - A Basis for Brain and

Adaptive Systems, J. W. . Sons, Ed. Wiley, 2007.

[42] N. Capodieci, E. Hart, and G. Cabri, �Designing self-aware adaptive systems: From

autonomic computing to cognitive immune networks,� in Self-Adaptation and Self-

Organizing Systems Workshops (SASOW), 2013 IEEE 7th International Conference

on, Sept 2013, pp. 59�64.

[43] C. Bishop, Pattern Recognition and Machine Learning, ser. Information Science and

Statistics. Springer, 2006.

[44] V. Vapnik and A. Vashist, �A new learning paradigm: Learning using privileged

information,� Neural Networks, vol. 22, no. 5-6, pp. 544�557, 2009.

[45] S. Fouad, P. Tino, S. Raychaudhury, and P. Schneider, �Learning using privileged

information in prototype based models,� in Arti�cial Neural Networks and Ma-

chine Learning � ICANN 2012, ser. Lecture Notes in Computer Science, A. Villa,

W. Duch, P. Érdi, F. Masulli, and G. Palm, Eds. Springer Berlin Heidelberg, 2012,

vol. 7553, pp. 322�329.

78 Bibliogra�e

[46] Y. Bengio, �Learning deep architectures for AI,� Foundations and Trends in Machine

Learning, vol. 2, no. 1, pp. 1�127, 2009, also published as a book. Now Publishers,

2009.

[47] Y. Bengio, A. Courville, and P. Vincent, �Representation learning: A review and new

perspectives,� IEEE Transactions on Pattern Analysis and Machine Intelligence,

vol. 35, no. 8, pp. 1798�1828, 2013.

[48] Y. Bengio, A. C. Courville, and P. Vincent, �Unsupervised feature learning and deep

learning: A review and new perspectives,� CoRR, vol. abs/1206.5538, 2012.

[49] P. Vincent, H. Larochelle, Y. Bengio, and P. A. Manzagol, �Extracting and Com-

posing Robust Features with Denoising Autoencoders,� in Proceedings of the 25th

International Conference on Machine Learning, ser. ICML '08. New York, NY,

USA: ACM, 2008, pp. 1096�1103.

[50] R. S. Sutton and A. G. Barto, Introduction to Reinforcement Learning, 1st ed.

Cambridge, MA, USA: MIT Press, 1998.

[51] B. Settles, �Active learning literature survey,� University of Wisconsin�

Madison, Computer Sciences Technical Report, 2009. [Online]. Available:

http://axon.cs.byu.edu/~martinez/classes/778/Papers/settles.activelearning.pdf

[52] E. Lughofer, �Hybrid active learning for reducing the annotation e�ort of operators

in classi�cation systems,� Pattern Recognition, vol. 45, no. 2, pp. 884 � 896, 2012.

[53] D. H. Wolpert, �The lack of a priori distinctions between learning algorithms,�

Neural Comput., vol. 8, no. 7, pp. 1341�1390, Oct. 1996. [Online]. Available:

http://dx.doi.org/10.1162/neco.1996.8.7.1341

[54] V. Mnih, K. Kavukcuoglu, D. Silver, A. A. Rusu, J. Veness, M. G. Bellemare,

A. Graves, M. Riedmiller, A. K. Fidjeland, G. Ostrovski, S. Petersen,

C. Beattie, A. Sadik, I. Antonoglou, H. King, D. Kumaran, D. Wierstra,

S. Legg, and D. Hassabis, �Human-level control through deep reinforcement

learning,� Nature, vol. 518, no. 7540, pp. 529�533, 02 2015. [Online]. Available:

http://dx.doi.org/10.1038/nature14236

Bibliogra�e 79

[55] D. C. Ciresan, U. Meier, L. M. Gambardella, and J. Schmidhuber, �Convolutional

neural network committees for handwritten character classi�cation,� in ICDAR,

2011, pp. 1135�1139.

[56] D. C. Ciresan, U. Meier, J. Masci, and J. Schmidhuber, �Multi-column deep neural

network for tra�c sign classi�cation,� Neural Networks, vol. 32, pp. 333�338, 2012.

[Online]. Available: http://dx.doi.org/10.1016/j.neunet.2012.02.023

[57] J. van den Berg, S. Miller, D. Duckworth, H. Hu, A. Wan, X. Fu, K. Goldberg,

and P. Abbeel, �Superhuman performance of surgical tasks by robots using itera-

tive learning from human-guided demonstrations,� in International Conference on

Robotics and Automation (ICRA), 2010.

[58] O. Etzion and P. Niblett, Event Processing in Action, 1st ed. Greenwich, CT,

USA: Manning Publications Co., 2010.

[59] L. Goldberg and B. von Halle, The Decision Model: A Business Logic Framework

Linking Business and Technology, C. Press, Ed. CRC Press, 2010.

[60] R. Calinescu, K. Johnson, and Y. Ra�q, �Developing self-verifying service-based

systems,� in Automated Software Engineering (ASE), 2013 IEEE/ACM 28th Inter-

national Conference on, Nov 2013, pp. 734�737.

[61] ***, �D2.5 icore �nal architecture,� http://www.iot-icore.eu/public-deliverables,

2014.

[62] ***, �Iot.est - iot environment for service creation and testing,� http://ict-

iotest.eu/iotest/, 2014.

[63] M. Nagao and T. Miki, �Cooperative behavior generation method using local com-

munication for distributed multi-agent systems,� in Systems Man and Cybernetics

(SMC), 2010 IEEE International Conference on, Oct 2010, pp. 2886�2892.

[64] S. Nechifor, D. Puiu, B. Târnauca, and F. Moldoveanu, �Prescriptive analytics

based autonomic networking for urban streams services provisioning,� in IEEE

81st Vehicular Technology Conference, VTC Spring 2015, Glasgow, United

80 Bibliogra�e

Kingdom, 11-14 May, 2015. IEEE, 2015, pp. 1�5. [Online]. Available:

http://dx.doi.org/10.1109/VTCSpring.2015.7146030

[65] Sensor Model Language (SensorML), Open Geospatial Std.

[66] Industrial automation systems and integration �Parts library � Part 32 Implemen-

tation resources: OntoML: Product Ontology markup language, ISO � International

Organization for Standardization Std.

[67] ***, �Ontosensor device ontology,� http://mmisw.org/ont/univmemphis/sensor,

2009.

[68] B. M. F. M. K. T. v. K. R. L. S. M. S. Bassi, A., Enabling Things to talk, B. M. F.

M. K. T. v. K. R. L. S. M. S. Bassi, A., Ed. Springer, 2013.

[69] ***, �Apache jena fuseki,� https://jena.apache.org/documentation/fuseki2/index.html,

2014.

[70] ***, �Sesame rdf,� http://rdf4j.org/, 2015.

[71] ***, �Sparql query language for rdf,� http://www.w3.org/TR/rdf-sparql-query/,

2008.

[72] A. Manzalini, P. H. Deussen, S. Nechifor, M. Mamei, R. Minerva, C. Moiso,

A. Salden, T. Wauters, and F. Zambonelli, �Self-optimized cognitive network of

networks,� Comput. J., vol. 54, no. 2, pp. 189�196, 2011. [Online]. Available:

http://dx.doi.org/10.1093/comjnl/bxq032

[73] J. Mitola, �Cognitive radio architecture evolution,� Proceedings of the IEEE, vol. 97,

no. 4, pp. 626�641, April 2009.

[74] S. Menoret, M. Roelands, S. Nechifor, M. Etelaper, R. Gia�red, and et .all, �D2.5

�nal architecture reference model,� FP7 iCore consortium, Tech. Rep., 2014.

[75] D. Tecuci and B. Porter, �Using an episodic memory module for pattern capture

and recognition,� Capturing and Using Patterns for Evidence Detection: Papers

Bibliogra�e 81

from the 2006 Fall Symposium. Menlo Park, CA: AAAI Press. Technical Report

FS-06-02, 2006.

[76] U. Waltinger, D. Tecuci, M. Olteanu, V. Mocanu, and S. Sullivan, �Natural language

access to enterprise data,� AI Magazine, vol. 35, no. 1, p. 38, 2014.

[77] G. A. Kaminka, A. Yakir, D. Erusalimchik, and N. Cohen-Nov, �Towards collabo-

rative task and team maintenance,� 2007.

[78] ***, �Reservoir - resources and services virtualization without barriers,�

http://www.reservoir-fp7.eu/, 2009.

[79] ***, �Sla@soi - empowering the service industry with sla-aware infrastructures,�

http://sla-at-soi.eu/, 2011.

[80] ***, �Dol�n - green data centres,� http://www.dol�n-fp7.eu/, 2015.

[81] M. Biancani, A. Kollaras, S. C. Nechifor, A. Nistor, A. Reale, S. Clayman, A. Ga-

lis, L. Mamatas, E.Angelou, G.Goumas, J.Siakavaras, C. Georgiou, S. Aristeides,

G. Spyroglou, A.Voulkidis, A. Aravanis, K. P. Ch, Tsiopoulou, T. Zahariadis, I. B.

Rodrigues, I. Canyameres, and A. Legarrea, �Deliverable d4.1 synergetic data cen-

tres for energy e�ciency (design),� Dol�n consortium, Tech. Rep., 2015.

[82] K. Chandy and W. Schulte, Event Processing: Designing IT Systems for Agile

Companies, 1st ed. New York USA: McGraw-Hill, Inc., 2010.

[83] D. C. Luckham, The Power of Events: An Introduction to Complex Event Processing

in Distributed Enterprise Systems. Boston, MA, USA: Addison-Wesley Longman

Publishing Co., Inc., 2001.

[84] ***, �Esper Complex Event Processing Engine,� EsperTech, 2012, accessed October

2015. [Online]. Available: http://www.espertech.com/products/esper.php.

[85] ***, �Drools,� JBoss Comunity, accessed October 2015. [Online]. Available:

http://www.drools.org/

82 Bibliogra�e

[86] ***, �InfoSphere Platform,� IBM, accessed October 2015. [Online]. Available:

http://www-01.ibm.com/software/data/infosphere/

[87] ***, �SAP Sybase Event Stream Processor,� SAP Sybase, accessed October

2015. [Online]. Available: http://www.sap.com/pc/tech/database/software/sybase-

complex-event-processing/index.html

[88] ***, �TIBCO BusinessEvents,� TIBCO, accessed Aug. 2013. [Online]. Available:

http://www.tibco.com/products/event-processing/complex-event-processing.

[89] ***, �Oracle Event Processing,� Oracle, accessed October 2015. [Online]. Availa-

ble: http://www.oracle.com/technetwork/middleware/complex-event-processing/

overview/index.html

[90] ***, �RulePoint,� Informatica, accessed October 2015. [Online].

Available: https://www.informatica.com/products/data-integration/real-time-

integration/rulepoint-complex-event-processing.html

[91] ***, �Apache Spark Streaming,� Apache Software Foundation, accessed October

2015. [Online]. Available: http://spark.apache.org/streaming/

[92] ***, �Starview Enterprise Platform,� Starview, accessed October 2015. [Online].

Available: https://www.starviewinc.com/operational-intelligence-platform/.

[93] ***, �Software AG Apama Streaming Analytics,� SoftwareAG, accessed October

2015. [Online]. Available: http://www.softwareag.com/resources/complex-event-

processing.asp

[94] ***, �D6.1 speci�cation of proof of concept prototypes for four application do-

mains,� iCore project deliverable, 2013. [ONLINE]: http://www.iot-icore.eu/public-

deliverables.

[95] ***, �D6.4 �nal proof of concept prototype for smart city: transportation,� iCore

project deliverable, 2013. [ONLINE]: http://www.iot-icore.eu/public-deliverables.

Bibliogra�e 83

[96] B. Tarnauca, D. Puiu, D. Damian, and V. Comnac, �Tra�c Condition Monitoring

Using Complex Event Processing,� in 2013 International Conference on System

Science and Engineering (ICSSE), 2013, pp. 123�128.

[97] R. Dechter, Constraint Processing, R. Dechter, Ed. Morgan Kaufmann Publishers

Inc., 2003.

[98] I. Cobeanu, B. Tarnauca, S. Nechifor, and V. Comnac, �Real-time Scheduling of

Mobile Agents Using Answer Set Programming,� in 2012 13th International Confe-

rence onOptimization of Electrical and Electronic Equipment (OPTIM), 2012, pp.

1505�1510.

[99] B. R., �Constraint programming: In pursuit of the holy grail�,� Proceedings �Week

of Doctoral Students (WDS99)�, Part IV, Proceedings �Week of Doctoral Students

(WDS99)�, Part IV, pp. 555-564, Praga, Cehia, 1999.

[100] F. Rossi, P. v. Beek, and T. Walsh, Handbook of Constraint Programming (Fo-

undations of Arti�cial Intelligence). New York, NY, USA: Elsevier Science Inc.,

2006.

[101] K. Apt, Principles of Constraint Programming, K. Apt, Ed. Cambridge University

Press, 2003.

[102] ***, �Ilog,� http://www-01.ibm.com/software/info/ilog/, 2015.

[103] ***, �CHOCO - CSP and CP Solver,� CHOCO, accessed June 2014. [Online].

Available: http://www.emn.fr/z-info/choco-solver/.

[104] ***, �The eclipse constraint programming system,� http://eclipseclp.org/, 2015.

[105] ***, �Jacop - java constraint programming solver,� http://jacop.osolpro.com/, 2015.

[106] ***, �B-prolog,� http://www.picat-lang.org/bprolog/index.html, 2014.

[107] A. Schrijver, Theory of Linear and Integer Programming. Wiley, 1998.

[108] N. Neagu, Constraint Satisfaction Techniques for Agent-Based Reasoning. Bir-

khäuser Verlag, 2005.

84 Bibliogra�e

[109] B. S. P. B. K. Francesco Ricci, Lior Rokach, Ed., Recommender Systems Handbook.

Springer, 2011.

[110] B. Sy and J. Deller, J.R., �A frame architecture for a certain class of graph search

problems,� Systems, Man and Cybernetics, IEEE Transactions on, vol. 18, no. 5,

pp. 815�824, Sep 1988.

[111] J. Li, Y. Liu, and H. Gao, �E�cient algorithms for summarizing graph patterns,�

Knowledge and Data Engineering, IEEE Transactions on, vol. 23, no. 9, pp. 1388�

1405, Sept 2011.

[112] M. Dorigo, M. Birattari, and T. Stutzle, �Ant colony optimization,� Computational

Intelligence Magazine, IEEE, vol. 1, no. 4, pp. 28�39, Nov 2006.

[113] ***, �Potassco, the potsdam answer set solving collection, bundles to-

ols for answer set programming developed at the university of potsdam,�

http://potassco.sourceforge.net/, 2015.

[114] P. Domingos and G. Hulten, �Mining high-speed data streams,� in Proceedings of the

Sixth ACM SIGKDD International Conference on Knowledge Discovery and Data

Mining, ser. KDD '00. New York, NY, USA: ACM, 2000, pp. 71�80.

[115] H. Wang, W. Fan, P. S. Yu, and J. Han, �Mining concept-drifting data streams

using ensemble classi�ers,� in Proceedings of the Ninth ACM SIGKDD International

Conference on Knowledge Discovery and Data Mining, ser. KDD '03. New York,

NY, USA: ACM, 2003, pp. 226�235.

[116] L. L. Minku and X. Yao, �DDD: A New Ensemble Approach for Dealing with

Concept Drift,� IEEE Transactions on Knowledge and Data Engineering, vol. 24,

no. 4, pp. 619�633, 2012.

[117] D. Brzezinski and J. Stefanowski, �Combining Block-based and Online Methods in

Learning Ensembles from Concept Drifting Data Streams,� Inf. Sci., vol. 265, pp.

50�67, May 2014.

Bibliogra�e 85

[118] J. Read, A. Bifet, B. Pfahringer, and G. Holmes, �Batch-incremental Versus

Instance-incremental Learning in Dynamic and Evolving Data,� in Proceedings of

the 11th International Conference on Advances in Intelligent Data Analysis, ser.

IDA'12. Berlin, Heidelberg: Springer-Verlag, 2012, pp. 313�323.

[119] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. Witten, �The

WEKA Data Mining Software: An Update,� SIGKDD Explorations, vol. 11, no. 1,

2009.

[120] ***, �Time Series Analysis and Forecasting with Weka,� Pentaho, Retrieved

2013, accessed Aug. 2013. [Online]. Available: http://wiki.pentaho.com/display/

DATAMINING/Time+Series+Analysis+and+Forecasting+with+Weka

[121] ***, �D6.5 �nal proof of concept prototype for smart business,� iCore project deli-

verable, 2013. [ONLINE]: http://www.iot-icore.eu/public-deliverables.

[122] ***, �Business process model and notation (bpmn),� OMG - Object Management

Group, Tech. Rep. formal/2011-01-03, 2011. [Online]. Available: http://

www.omg.org/spec/BPMN/2.0

[123] ***, �Event-driven process chain (epc),� ARIS COMMUNITY, Tech. Rep., 2015.

[Online]. Available: http://www.ariscommunity.com/event-driven-process-chain

[124] ***, �Uni�ed modeling language (uml),� OMG - Object Management Group, Tech.

Rep. formal/15-03-01, 2015. [Online]. Available: http://www.omg.org/spec/UML/

2.5

[125] J. Hebeler, M. Fisher, R. Blace, and A. Perez-Lopez, Semantic Web

Programming. Wiley, 2009. [Online]. Available: https://books.google.at/books?id=

Dnl36lmPDXEC

[126] ***, �Resource description framework (rdf),� World Wide Web Consortium - W3C,

Tech. Rep., 25 February 2014. [Online]. Available: http://www.w3.org/RDF/

[127] ***, �Rdf schema 1.1,� World Wide Web Consortium - W3C, Tech. Rep., 25

February 2014. [Online]. Available: http://www.w3.org/TR/rdf-schema/

86 Bibliogra�e

[128] ***, �Web ontology language (owl),� World Wide Web Consortium - W3C, Tech.

Rep., 11 December 2012. [Online]. Available: http://www.w3.org/2001/sw/wiki/

OWL

[129] ***, �Citypulse: Real-time iot stream processing and large-scale data analytics for

smart city applications,� in [ONLINE]: http://www.ict-citypulse.eu/page/.

[130] E. Tatara, A. �nar, and F. Teymour, �Control of Complex Distributed Systems

with Distributed Intelligent Agents,� Journal of Process Control, vol. 17, no. 5, pp.

415�427, 2007.

[131] M. J. North and C. M. Macal, Managing Business Complexity Discovering Stra-

tegic Solutions with Agent-Based Modeling and Simulation. Oxford, UK: Oxford

University Press, 2007.

[132] N. Malleson, �Agent-Based Modelling of Burglary,� Ph.D. dissertation, University

of Leeds, UK, 2010.

Cercetări privind mecanismele cognitive bazate pe constrângeri şiaplicarea acestora la sistemele de control autonomice

Applied research regarding constraints based cognitive computing mechanisms and their usage on

autonomic control systems

Conducator ştiinţific: Doctorand:Prof. dr. ing. Florin MOLDOVEANU Dipl. Ing. Cosmin-Septimiu NECHIFOR

Rezumat

Sistemele de calcul şi comunicaţie implică un volum crescut de atenţie cu privire la funcţionarea lor corectă. Presiuneaasupra calităţii configurării, administrării şi mentenanţei lor este cu atât mai mare cu cât corectitudinea trebuie să fieasumată faţă de un context de execuţie în continuă schimbare. Acest fapt introduce un stres suplimentar în ceea ceînseamnă atât adaptarea percepţiei mediului de utilizare cât şi a înţelegerii acestuia ori adaptării corecte acomportamentului sistemului, iar în cazul în care sistemele considerate sunt distribuite şi conţin atât actori IT cât şinon-IT necesitatea adaptării paradigmei controlului este şi mai importantă. Sistemele de control autonomice oferă operspectivă practică în ceea ce înseamnă auto-reglajul adaptat contextului de lucru. Este un concept ce abordează şiîncorporează complexitatea în managementul sistemelor şi al cărui efect îl vedem în ceea ce înseamnă, de exemplu,sistemele SOA ori cele cloud.

Tema propusă în teză încorporează într-o arhitectură autonomică distribuită mecanisme ce ţin de calculul cognitivsprijinit de o monitorizare continuă, adaptivă şi de o planificare a acţiunilor bazată pe programarea constrângerilor.Arhitectura propusă adresează şi acoperă cazuri de încorporare a lumii reale în Internet of Things. Tematicaidentificată este susţinută ca şi necesitate de faptul că activităţile de cercetare asociate acestei teze sunt şi rezultatulunui număr de 9 proiecte de cercetare FP7 şi Horizon 2020, fapt ce certifică necesitatea şi validitatea conceptelor.

Validarea experimentală a fost realizată prin intermediul unor demonstratoare ce au permis simularea unor mediidistribuite de scară largă capabile să evidentieze conceptele dezvoltate pentru toate etapele controlului autonomic:modelarea semantică a cunoştintelor, monitorizare şi analiză a datelor de stare bazate pe Complex Event Processingşi Machine Learning (facilitând caracterul dinamic al calculului cognitiv), planificare bazată pe constrângeri capabilă săofere validitate logică soluţiilor generate şi conectarea la medii de execuţie specifice Internet of Things. Platformele dereferinţă sunt CoReMo şi iCORE, ambele dezvoltate în cadrul Siemens Corporate Technology România.

Abstract

Computing and communication systems involves a relevant volume of detail with regard to correct and safe executionof functionalities. The relevance of configuration, operational management and maintenance in this case is augmentedby the correctness needed to be observed on a perpetual change of contextual execution environment. Those factslead to additional stress regarding both tailoring of perception on usage ecosystem and associated meaning forexpected functionality, and behavioral adjustments. For the specific case when the target systems and also distributedreferring both IT and non-IT resources and actors, the paradigm of change on control strategy become highly relevant.Autonomic control systems aim to realize a pragmatic approach for self-adjustments adapted to contextual data. It’s aconcept formulated to target and solve the complexity of systems management with a relevant results, for example inSOA or Cloud Computing.

The subject addressed in this thesis build on distributed autonomic architecture mechanisms from Cognitive Computingbacked by continuous and adaptive monitoring plus activity planning based on Constraints Programming. Proposedarchitecture address and satisfy cases of enablement of real world applications in Internet of Things. A relevantargument for the actual importance of identified subjects is the fact that research executed in this thesis is also a resultof 9 FP7 and Horizon 2020 research projects.

Experimental validation have been done over some demo platforms allowing the simulation of large-scale distributedenvironments facilitating the exposure of developed concepts, for all steps of autonomic control: semantic knowledgemodeling, data monitoring and analysis based on Complex Event Processing and Machine Learning, planning basedon constraints programming and connectivity for execution on Internet of Thing compatible environments. Referenceplatforms are CoReMo and iCORE, both developed by Siemens Corporate Technology Romania.

Curriculum vitae

INFORMAŢII PERSONALE Cosmin Septimiu Nechifor

V. Cetatii 13, Brasov (România)

septimiu .nechifor@siemens.com

Sexul Masculin | Data naşterii 31/07/1974 | Naţionalitatea română

EXPERIENŢA PROFESIONALĂ

01/03/2010–Prezent Research Group HeadSiemens SRL - Siemens Corporate Technology, Brasov (România)

Responsabil pentru formarea viziunii si implementarea strategiei de dezvoltare a unui grup de cercetare parte din departamentul multinational al Siemens Corporate Technology - Business Analytics and Monitoring. Responsabilitatea implica identificarea de teme de cercetare industriala, identificarea si dezvoltarea talentelor ce pot face parte din echipa, achizitia si managementul tehnic si financiar al proiectelor executate, atat proiecte in colaborare cu alte grupuri de cercetare cat si cu business unit-urile Siemens, ori cu finantare publica prin FP7 si Horizon 2020.

Grupul pe care il conduc este format din 15 experti cu un nivel ridicat de experienta atat in ceea ce inseamna dezvoltarea software cat si ceea ce priveste cercetarea in domenii precum: Constraints Programming, Artificial Intelligence, Big Data Analytics, Semantic Technologies, Internet of Things, Machine Learning, Statistics, Complex Event Processing, Control Engineering. Tematica abordata se regaseste in jurul conceptului de Continuous Configuration, referind domenii unde configuratiile de scara larga de resurse si procese sunt capabile de adaptare inteligenta asimiland si contextualizand schimbarile din mediu pastrandu-si consistenta si capacitatea de raspuns.

Proiecte reprezentative:

S'UPREME - sistem de generare de configuratii bazate pe constrangeri programabile generative. Aceste sisteme reprezinta State-of-the-art in sistemele de control automate ale automatizarilor feroviare produse de Siemens. Proiectul este realizat cu o echipa de experti de talie mondiala din Siemens Corporate Technology Viena.

WatchCAT - sistem de analiza a volumelor mari de date prelevate din infrastructuri industriale precum turbine ori sisteme de control. Sistemul detecteaza erori de configurare, pattern-uri de defectare a unor componente si subansamble. Proiectul este realizat impreuna cu o echipa de experti din Siemens Corporate Technology Munchen.

Proiecte cu finantare publica:

* FP7 ICT iCORE (2011 - 2014) - Internet of Things

* FP7 ICT IOT.est (2011 - 2014) - Internet of Things

* FP7 ICT MODAClouds (2012 - 2015) - Model Driven Multi-Clouds

* FP7 ICT CityPulse (2013 - 2016) - Internet of Things

* FP7 ICT RERUM (2013 - 2016) - Internet of Things

* FP7 ICT COSMOS (2013 - 2016) - Internet of Things

* FP7 ICT DOLFIN (2013 - 2016) - Green Data Centers

* AAL NITICS (2013 - 2015)

* H2020 PaaSword (2015 - 2018) - Secure Data in PaaS

* H2020 UNCAP (2015 - 2018) - ICT for AAL

* H2020 TagItSmart! (2016 - 2019) - Internet of Things

01/09/2001–03/2010 Project ManagerSiemens, Brasov (România)

In aceasta perioada am facut parte dintr-un numar relevant de proiecte ocupand diverse roluri: Sotware Developer, Requirements Engineer, Project Manager, Quality Manager, Delivery Manager. Consider aceasta perioada deosebit de utila pentru formarea mea ca cercetator deoarece mi-a dat sansa sa lucrez direct cu un numar mare de experti din industrii diverse si sa pot participa direct la

2/12/15 © Uniunea Europeană, 2002-2015 | http://europass.cedefop.europa.eu Pagina 1 / 3

Curriculum vitae Cosmin Septimiu Nechifor

generarea de servicii si produse folosind o scara larga de tehnologii. Dintre industriile abordate:

* sector public (aplicatii de criptare si document management)

* utilitati (migrare si consolidare de date pentru un operator canadian)

* logistica (management al flotelor auto, al consumurilor unor fabrici de componente de echipamente electronice)

* telecomunicatii (end to end delivery manager in cel mai mare program de functionalitati broadband al British Telecom)

EDUCAŢIE ŞI FORMARE

01/10/1998–01/07/1999 Studii Aprofundate Tehnici avansate de proiectare in electronica

Universitatea Transilvania, Facultatea de Electrotehnica, Brasov (Romania)

* Analiza si proiectare VLSI

* Procesarea digitala a semnalelor

* Modelarea si sinteza circuitelor

* Tehnici orientate obiect pentru sisteme de timp real

01/10/1993–10/07/1998 Inginer Electronist Inginer specializarea Electronica Aplicata

Universitatea Transilvania, Facultatea de Electrotehnica, Brasov (România)

* Procesarea analogica si digitala a semnalor

* Arhitectura sistemelor de calcul

* Limbaje de programare si compilatoare

* Analiza si sinteza circuitelor electronice

* Masuratori electronice

* Testare si testabilitate

* Procesarea imaginilor

* Electrotehnica si masini electrice

* Baze de date

COMPETENŢE PERSONALE

Limba(i) maternă(e) română

Alte limbi străine cunoscute ÎN ELEGEREȚ VORBIRE SCRIERE

Ascultare CitireParticipare la conversaţie

Discurs oral

engleză C2 C2 C1 C2 C2

franceză B2 B2 B1 B1 B1

Niveluri: A1 i A2: Utilizator elementar - B1 i B2: Utilizator independent - C1 i C2: Utilizator experimentatș ș șCadrul european comun de referinţă pentru limbi străine

Competenţe de comunicare Expunerea la un mediu intensiv multi-cultural mi-a facilitat dezvoltarea unor abilitati de comunicare eficienta, de intelegere rapida a interlocutorilor.

Competenţe organizaţionale/manageriale

De-a lungul carierei am avut placerea de a construi echipe eficiente si performante. Competentele in domeniu sunt reflectate de rezultatele constant relevante obtinute atat in ceea ce inseamna dezvoltarea viziunii tehnologice a echipei, cat si a modului de a coopera si de a atinge tintele tehnice

2/12/15 © Uniunea Europeană, 2002-2015 | http://europass.cedefop.europa.eu Pagina 2 / 3

Curriculum vitae

PERSONAL INFORMATION Cosmin Septimiu Nechifor

13, Valea Cetatii, Brasov (Romania)

(+40) 400 171

septimiu.nechifor@siemens.com

PERSONAL STATEMENT

WORK EXPERIENCE

01/03/2010–Present Research Group HeadSiemens SRL - Siemens Corporate Technology, Brasov (Romania)

In charge to establish and drive the vision and associated strategy implementation for a research group, part of cross-country department of Siemens Corporate Technology - Business Analytics and Monitoring. Performed activities : industrial research subjects identification and acquisition, new talents identification,team integration and development, acquisition, technical and financial management of research project - both`Siemens business funded and public funding via EC programmes like FP7 ICT and Horizon 2020.

Managed team rely on valuable contribution of 15 experts with a high degree of experience and skills on both practical hardware/software engineering and research topics like: Constraints Programming, Artificial Intelligence, Big Data Analytics, Semantic Technologies, Internet of Things, Machine Learning, Statistics, Complex Event Processing, Control Engineering. Those fields contribute around the concept of Continuous Configuration, referring application domains where large scale configurations of resources and processes are capable to expose intelligent adaptiveness, able to assimilate and contextualize changes fom environment but keeping the consistency and responsiveness.

Relevant projects:

S'UPREME - Configuration generator based on Constraints Programming. Those systems represents State of the art reference on control systems for railway automation portfolio of Siemens. This project is realized together with a team of wolrd class experts from Siemens Corporate Technology Vienna.

WatchCAT - analytics platform, targeting the processing of large volumes of data generated by industrial infrastructures like turbines or control systems. Implemented functions include: configuration errors, failure patterns for whole installation or specific parts, functional and maintenance trends. The project is realized together with a team of experts from Siemens Corporate Technology Munchen.

EC funded projects:

* FP7 ICT iCORE (2011 - 2014) - Internet of Things

* FP7 ICT IOT.est (2011 - 2014) - Internet of Things

* FP7 ICT MODAClouds (2012 - 2015) - Model Driven Multi-Clouds

* FP7 ICT CityPulse (2013 - 2016) - Internet of Things

* FP7 ICT RERUM (2013 - 2016) - Internet of Things

* FP7 ICT COSMOS (2013 - 2016) - Internet of Things

* FP7 ICT DOLFIN (2013 - 2016) - Green Data Centers

* AAL NITICS (2013 - 2015)

* H2020 PaaSword (2015 - 2018) - Secure Data in PaaS

* H2020 UNCAP (2015 - 2018) - ICT for AAL

* H2020 TagItSmart! (2016 - 2019) - Internet of Things

17/12/15 © European Union, 2002-2015 | http://europass.cedefop.europa.eu Page 1 / 3

Curriculum vitae Cosmin Septimiu Nechifor

01/09/2001–03/2010 Project ManagerSiemens, Brasov (Romania)

Involved in a broad range of business related projects filling various roles: Software Developer, Requirements Engineers, Project Manager, Quality Manager, Delivery Manager. All those activities offered a relevant practical background for my current research oriented profile due to high exposure to interaction with experts from different industries and direct experience in the generation of added value services and products over a large scale of technological options. Most relevant industries approached:

* public sector

* utilities

* logistics

* telecom

EDUCATION AND TRAINING

01/10/1998–01/07/1999 Master of ScienceTransilvania University, Brasov (Romania)

* VLSI analysis and design

* Digital signal processing

* Artifical Intelligence in EDA

01/10/1993–10/07/1998 Electronics EngineerTransilvania University, Brasov (Romania)

* Analog and digital signal processing

* Computers architecture

* Programming and software design

* Electronic measurements

* Testing and testability

* Image processing

* Electrotechnics

* Databases

PERSONAL SKILLS

Mother tongue(s) Romanian

Other language(s) UNDERSTANDING SPEAKING WRITING

Listening Reading Spoken interaction Spoken production

English C2 C2 C1 C2 C2

French B2 B2 B1 B1 B1

Levels: A1 and A2: Basic user - B1 and B2: Independent user - C1 and C2: Proficient userCommon European Framework of Reference for Languages

Communication skills Very effective multi-cultural profile, fast and reliable interaction, long term exposure to both formal and less formal enviroments.

Organisational / managerial skills Proven experience regarding successful build up of teams and competences. Long term strategic perspective and agile win-win business relationships.

17/12/15 © European Union, 2002-2015 | http://europass.cedefop.europa.eu Page 2 / 3