Arhitecturi Orientate Pe Servicii Pentru Optimizarea Aplica?iilor Industriale

Arhitecturi orientate pe
servicii pentru optimizarea

aplica iilor industriale
COLEC IA DE AUTOMATIC
Alina GRBEA
Arhitecturi orientate pe servicii

pentru optimizarea
aplica iilor industriale
Editura Universit ii Transilvania

Bra ov, 2013
CUPRINS
1 ARHITECTURI ORIENTATE PE SERVICII.......................................................................... 1
1.1 INTRODUCERE .................................................................................................................... 1
1.2 ISTORIA SOA ....................................................................................................................... 2
1.3 SERVICII............................................................................................................................... 3
1.3.1 Generalit i ...................................................................................................................... 3
1.3.2 nregistrarea i contractarea serviciilor ............................................................................. 4
1.3.3 Servicii web ..................................................................................................................... 5
1.3.4 Managementul calit ii serviciilor .................................................................................... 5
1.4 ARHITECTURA PE NIVELE A CONCEPTULUI SOA ....................................................... 6
1.5 SECURITATEA SOA O PROBLEM DE CONFIDEN IALITATE, INTEGRITATE I
DISPONIBILITATE .................................................................................................................... 7
1.5.1 Introducere n securitatea informa ional ......................................................................... 7
1.5.2 Securitatea SOA .............................................................................................................. 8
1.5.3 Utilizarea standardelor n contextul securit ii SOA ......................................................... 8
1.6 APLICAREA CONCEPTULUI SOA N INDUSTRIE........................................................... 9
1.6.1 Telecomunica ii ............................................................................................................... 9
1.6.2 Produc ie ....................................................................................................................... 10
1.6.3 Colaborarea business-to-business ................................................................................... 17
1.7 CONCLUZII ........................................................................................................................ 17
2 PROBLEME DE SATISFACERE A CONSTRNGERILOR ............................................... 19
2.1 INTRODUCERE .................................................................................................................. 19
2.1.1 No iuni generale ............................................................................................................ 19
2.1.2 Algoritmi de c utare ...................................................................................................... 21
2.1.3 Tehnici de consisten .................................................................................................... 22
2.1.4 Propagarea constrngerilor............................................................................................. 23
2.2 NO IUNI GENERALE ALE PROBLEMELOR DE SCHEDULING .................................. 25
2.2.1 Introducere .................................................................................................................... 25
2.2.2 Clasificarea lui Graham ................................................................................................. 25
2.2.3 Modelarea CSP a unei probleme de scheduling .............................................................. 26
2.3 SOLVERE CSP.................................................................................................................... 29
2.3.1 Solver-ul JaCoP ............................................................................................................. 29
2.3.2 Solver-ul Choco ............................................................................................................. 29
2.3.3 Solver-ul JLPI................................................................................................................ 30
2.4 UTILIZAREA PROBLEMELOR DE SATISFACERE A CONSTRNGERILOR N
MEDIUL INDUSTRIAL............................................................................................................ 30
2.5 CONCLUZII ........................................................................................................................ 33
3 ARHITECTUR ORIENTAT PE SERVICII PENTRU OPTIMIZAREA
APLICA IILOR INDUSTRIALE .............................................................................................. 35
3.1 INTRODUCERE .................................................................................................................. 35
3.2 PREZENTAREA GENERAL A ARHITECTURII ............................................................ 36
VII
3.3 SERVERUL OPC UA ..........................................................................................................38

3.4 SERVICIILE SOFTWARE ...................................................................................................40
3.5 NIVELUL CSP .....................................................................................................................41
3.6 CONCLUZII.........................................................................................................................41
4 SERVERUL OPC UA ...............................................................................................................43
4.1 INTRODUCERE ..................................................................................................................43
4.2 COMPARA IE OPC CLASIC OPC UA ...........................................................................43
4.2.1 OPC clasic .....................................................................................................................43
4.2.2 Necesitatea introducerii standardului OPC UA ...............................................................44
4.2.3 OPC UA prezentare general .......................................................................................46
4.2.4 Nivelele software OPC UA ............................................................................................47
4.2.5 Strategii de migrare OPC clasic OPC UA ....................................................................49
4.2.5.1 Wrapper i Proxy.....................................................................................................49
4.2.5.2 Dezvoltare nativ .....................................................................................................50
4.2.5.3 Gateway-uri OPC UA..............................................................................................50
4.2.5.4 Software special de adaptare....................................................................................50
4.3 DEZVOLTAREA UNUI SERVER AGREGATOR FOLOSIND SOLU IA SOFTWARE
SPECIAL DE ADAPTARE ..........................................................................................................51
4.3.1 Arhitectura .....................................................................................................................51
4.3.2 Implementarea ...............................................................................................................53
4.3.2.1 Modelele de informa ii ............................................................................................53
4.3.2.2 Spa iul de adrese......................................................................................................54
4.3.2.3 Comunica ia cu serverul COM ................................................................................56
4.3.2.4 Securitatea...............................................................................................................57
4.3.3 Testarea performan ei solu iei bazate pe software special de adaptare.............................58
4.3.3.1 Testul ciclu ..............................................................................................................58
4.3.3.2 Testul alarm ..........................................................................................................59
4.4 GENERAREA AUTOMATA A SPA IULUI DE ADRESE ................................................59
4.4.1 Introducere .....................................................................................................................59
4.4.2 Procedura de start a serverului OPC UA .........................................................................59
4.4.3 Generarea automat a spa iului de adrese .......................................................................61
4.4.3.1 Activit i preliminarii ..............................................................................................61
4.4.3.2 Tipuri de noduri.......................................................................................................62
4.4.3.3 Noduri obiect i variabil .........................................................................................64
4.4.3.4 Noduri metod .........................................................................................................66
4.4.3.5 Noduri vedere ..........................................................................................................68
4.4.3.6 Referin e suplimentare.............................................................................................69
4.4.3.7 Sursa de date ...........................................................................................................69
4.5 REZULTATE .......................................................................................................................72
4.6 CONCLUZII.........................................................................................................................74
5 DEZVOLTAREA UNUI SET DE SERVICII SOFTWARE PENTRU ARHITECTURI
INDUSTRIALE ............................................................................................................................77
5.1 INTRODUCERE ..................................................................................................................77
5.2 SERVICII WEB SOAP .........................................................................................................78
5.2.1 Stilurile de comunica ie SOAP .......................................................................................79
5.2.2 Fi ierul WSDL ...............................................................................................................79
5.2.3 Alegerea framework-ului pentru dezvoltarea serviciilor web SOAP ...............................80
VIII
5.2.3.1 Framework-ul Apache Axis2 .................................................................................. 80

5.2.3.2 Framework-ul Apache CXF .................................................................................... 81
5.2.3.3 Concluzii ................................................................................................................ 84
5.3 SERVICII WEB REST ......................................................................................................... 85
5.4 SERVICII JAVA APACHE RIVER ..................................................................................... 87
5.4.1 Concepte cheie .............................................................................................................. 88
5.4.2 Arhitectura serviciilor .................................................................................................... 90
5.5 SERVICIILE DE BAZ ...................................................................................................... 92
5.5.1 Gestionarea conexiunilor cu serverul OPC UA .............................................................. 93
5.5.2 Prezentarea setului de servicii de baz ........................................................................... 94
5.6 TESTE DE PERFORMAN .............................................................................................. 95
5.6.1 Timpii de execu ie ai serviciilor de baz ........................................................................ 95
5.6.2 Citirea i scrierea variabilelor booleene .......................................................................... 96
5.6.3 Concluzii ....................................................................................................................... 96
5.7 SERVICIILE COMPLEXE .................................................................................................. 97
5.7.1 Servicii complexe pentru monitorizarea i controlul produc iei ...................................... 97
5.7.2 Servicii complexe pentru gestionarea erorilor ................................................................ 99
5.7.3 Servicii complexe pentru determinarea valorilor parametrilor KPI ............................... 100
5.8 CONCLUZII ...................................................................................................................... 101
6 UTILIZAREA ARHITECTURII ORIENTATE PE SERVICII PENTRU OPTIMIZAREA
UNUI PROCES INDUSTRIAL DE FABRICARE A MECANISMELOR DE ROTA IE .... 103
6.1 PREZENTAREA PROBLEMEI ......................................................................................... 103
6.2 LINIA FLEXIBIL FMS 200 ............................................................................................ 105
6.2.1 Celula de plasare a uruburilor ..................................................................................... 106
6.2.2 Celula robot ................................................................................................................. 107
6.2.3 Celula de inspec ie ....................................................................................................... 108
6.3 MODELUL MIP ................................................................................................................ 109
6.3.1 Modelul LAS1a ........................................................................................................... 111
6.3.2 Modelul L1a ................................................................................................................ 113
6.3.3 Model S|L1 .................................................................................................................. 114
6.4 IMPLEMENTARE ............................................................................................................. 115
6.4.1 Spa iul de adrese al serverului OPC UA ....................................................................... 116
6.4.2 Serviciul complex ........................................................................................................ 118
6.4.3 Modific ri ale programelor automatelor programabile ................................................. 121
6.5 REZULTATE..................................................................................................................... 121
6.6 CONCLUZII ...................................................................................................................... 124
BIBLIOGRAFIE ........................................................................................................................ 127
IX
Prefa
Lucrarea prezint elementele unei cercet ri realizate n domeniul automatiz rilor industriale. Ideea
cercet rii a fost de a proiecta, implementa i testa o arhitectur software orientat pe servicii pentru
optimizarea aplica iilor industriale. Arhitectura propus poate fi utilizat pentru o gam larg de
aplica ii, n cadrul activit ilor de testare aceasta fiind folosit pentru optimizarea unui proces de
fabrica ie desf urat pe un sistem de fabrica ie flexibil. Automatizarea este o ramur a ingineriei
electrice i prin urmare se poate argumenta c aceast cercetare, ale c rei elemente principale vor fi
prezentate de-a lungul lucr rii, apar ine domeniului ingineriei electrice.
Componentele principale ale unei automatiz ri sunt n mod tradi ional clasificate sau organizate
folosind o piramid de automatizare dup cum este prezentat n figura de mai jos [Harjunkoski I.,
2009].
Nivelul inferior este format din dou sub-nivele (nivelul de proces i nivelul de senzori i actuatori)
i poate fi numit generic nivelul dispozitivelor de control al echipamentelor. n general acest nivel
include att echipamentele hardware ct i programele de automatizare utilizate pentru
monitorizarea i controlul procesului. De asemenea la acest nivel sunt achizi ionate datele din
proces, se realizeaz ac iuni de control simple i autonome (de exemplu men inerea constant a unei
temperaturi) dar pot fi realizate i evalu ri de performan locale mpreun cu func ionalit i de
monitorizare i diagnosticare.
Urm torul nivel este nivelul MES (Manufacturing Execution System). La acest nivel se realizeaz
gestionarea i monitorizarea opera iilor de fabricare realizate la nivelul ntreprinderii. Un sistem
MES urm re te n timp real toate informa iile referitoare la procesul de produc ie. De i aceste
sisteme obi nuiau s opereze ca entit i de sine st toare, la momentul actual ele sunt integrate tot
mai mult n cadrul sistemelor software utilizate la nivelul superior al piramidei de automatizare. De
asemenea protocolul de comunica ie dintre dispozitivele de control ale procesului de produc ie
trebuie s fie sigur i s permit transmisia rapid i f erori chiar i n cele mai dificile condi ii de
perturba ie electromagnetic . Scopul nivelului MES este acela de a mbun i productivitatea, deci
printre altele timpul total de produc ie nregistrat de la primirea unei comenzi.
Nivelul superior al piramidei este numit ERP (Enterprise Resource Planning) i cuprinde toate
activit ile de planificare care asigur buna func ionare a ntreprinderii. La acest nivel se asigur
vizibilitatea indicatorilor cheie de performan , care sunt critici pentru ndeplinirea obiectivelor
organiza iei. Aplica iile ERP sunt folosite pentru gestionarea planului de produc ie, achizi ionarea de
componente i materiale, inventar, interac iune cu furnizori, etc. Tot la nivelul ERP se pot realiza
analize ale timpilor de lucru, analize ale defectelor, monitorizarea stocurilor i a produc iei sau
analize ale costurilor. Nivelul ERP poate include i aplica ii ale departamentului financiar sau de
resurse umane i este n mod tipic integrat cu un sistem de baze de date rela ionale. Prin cuplarea
nivelelor MES i ERP, managerii pot asigura livrarea eficient i la timp a unor produse de calitate.
Nivelele nu sunt complet standardizate, acest lucru depinznd n mare parte de companie, de tipul
produc iei, de structura cump torilor i de modul n care sunt distribuite opera iile de business.
XI
PREFA
La nivelul inferior se g sesc n principal programele produc torilor de componente hardware iar n
cazul unei ntreprinderi cu o gam variat de echipamente doar o mic parte a acestora sunt intercompatibile. Acest aspect a fost mbun it considerabil n ultimii ani deoarece mai multe companii
au convenit asupra standardelor pentru a permite inter-compatibilitatea echipamentelor. Cealalt
extrem , nivelul ERP, este relativ omogen , deoarece o companie fie dispune de sisteme proprii, fie
contacteaz furnizori ERP (SAP, Oracle, i2, IFS) pentru a ndeplini un minim de sarcini esen iale ale
vnz rilor, lan ului de aprovizionare sau a gestion rii clien ilor.
Piramida de automatizare [Harjunkoski I., 2009].
Conform studiilor de pia [Harjunkoski I., 2009], nivelul de la mijlocul piramidei de automatizare
are o cifr anual de cre tere dubl (14%) n compara ie cu nivelul ERP i cu nivelul de
automatizare. Aceasta este o indica ie clar c sarcina de integrare devine crucial pentru mul i
produc tori.
Principalul scop al nivelului MES este de a nl tura acest neajuns, de exemplu prin asigurarea
faptului c sarcinile de afaceri sunt transferate corect la nivelul de produc ie. Aceasta nseamn c
nivelul MES trebuie s se adapteze la mediul nconjur tor i c trebuie s includ orice func ie de
decizie care implic controlul predictiv sau bazat pe modele precum i activit i de planificare i de
scheduling. Num rul de opera ii indic faptul c MES nu poate fi definit ntr-un mod ambiguu,
deoarece rolul i existen a multor componente poate varia foarte mult ntre companii i fabricile lor.
Multe din func ionalit ile MES sunt nc efectuate manual, ceea ce le determin s fie dificil de
integrat.
MESA (Manufacturing Enterprise Solutions Association) Interna ional define te MES dup cum
urmeaz : Sistemele de execu ie n fabricare furnizeaz informa ii care permit optimizarea
proceselor de produc ie de la generarea comenzii pn la finalizarea produsului. MES gestioneaz i
ini iaz activit i n fabric prin utilizarea de date actualizate i precise. Nivelul r spunde la aceste
activit i i le raporteaz n timp real n timpul produc iei.
XII
PREFA
Acest lucru semnific faptul c MES realizeaz o leg tur de integrare prin conectarea activit ii de
procesare a comenzii recep ionate de la client la nivelul ERP i activitatea de fabricare sau de
prelucrare la nivelul dispozitivelor. Rolul MES pentru integrare devine astfel de necontestat.
n [Harjunkoski I., 2009] se specific faptul c o alternativ de integrare a celor trei
nivele/componente poate fi bazat pe framework-ul OPC UA (OPC Unified Architecture).
Un sistem de fabrica ie este format din totalitatea mijloacelor i a rela iilor dintre aceste mijloace,
utilizate pentru rezolvarea unei sarcini sau a unei mul imi de sarcini cu scopul de a realiza unul sau
mai multe produse care vor fi oferite pe pia [Chiri B., 2007].
Un sistem flexibil de fabrica ie este o unitate func ional , integrat , autoreglabil , care are
capacitatea de a prelucra automat orice produs apar innd unei familii de produse [Popescu G.,
2007]. Acesta este constituit dintr-un grup de celule care pot fi robo i, ma ini-unelte cu automate
programabile sau cu comand numeric . Celulele sunt legate ntre ele printr-un sistem de transport
automatizat, care este de obicei coordonat de un dispozitiv de control supra-ordonat, numit master.
Sistemul flexibil de fabrica ie, numit n continuare i linie flexibil de fabrica ie, prelucreaz
automat orice pies care apar ine unei familii de piese cu caracteristici similare pe baza unui
algoritm de fabrica ie predefinit [Mehrabi M. G., 2002].
Flexibilitatea sistemului poate fi mp it n dou categorii: flexibilitatea ma inii i flexibilitatea de
direc ionare [***SMC International Training, 2011]. Un astfel de sistem flexibil de fabrica ie
prezint o serie de avantaje [Chiri B., 2007], dintre care amintim: reducerea num rului de
operatori umani de pn la cinci ori fa de produc ia conven ional , reducerea num rului de utilaje
tehnologice cu 50%, cre terea productivit ii muncii cu 200% pn la 400% i scurtarea ciclurilor de
preg tire tehnologic a produc iei.
n mediul economic actual, companiile trebuie s reac ioneze rapid la modific rile ap rute n cerin a
de pe pia i s respecte termenele limit stabilite de clien i.
Prin urmare speciali tii au ajuns la concluzia c sistemele de fabrica ie trebuie s fie bazate i
orientate pe timp iar ntreaga strategie de fabrica ie trebuie adaptat pentru a suporta inovarea i
introducerea u oar a unor noi produse. n general, pentru a face fa acestui nou context, este
necesar o mai mare adaptabilitate i flexibilitate.
Principalele cerin e care trebuie satisf cute de c tre ntreprinderile de produc ie i de sistemele de
control includ urm toarele [Jammes F., 2005 a)]:
Capacit i de integrare dinamic a entit ilor n interiorul ntreprinderii;
Cooperare ntre ntreprinderi;
Suport pentru mediile hardware i software eterogene i inter-operabile;
Agilitate prin adaptabilitate i reconfigurare;
Scalabilitate prin ad ugare de resurse f a ntrerupe opera iile;
Toleran la eroare i revenire rapid de la e ecuri.
S-a concluzionat c , n economia global de azi, pentru a men ine competitivitatea i productivitatea,
optimizarea proceselor de fabrica ie este chiar mai important dect n trecut [Bohn H., 2006].
Statisticile curente arat c o treime din costul total de fabrica ie al unei companii este dat de
activit ile de instalare i configurare a echipamentelor [Jammes F., 2005 b)].
Pe de alt parte internetul i tehnologiile web devin din ce n ce mai mult elementele centrale ale
unei lumi n care dispozitivele sunt interconectate n diferite moduri. Limbajul XML (Extensible
Markup Language) i mecanismele bazate pe acesta au pavat drumul pentru dezvoltarea standardelor
XIII
PREFA
de transfer de date. Introducerea paradigmei de servicii web bazate pe XML, folosit pentru a
interconecta diverse aplica ii eterogene prin intermediul unei infrastructuri u oare, a permis
realizarea conexiunilor independente de platform i limbaj.
n literatura de specialitate au fost identificate o serie de cerin e i provoc ri referitoare la
ecosistemele de interconectare a dispozitivelor [Jammes F., 2005 a)]:
Standardele web trebuie folosite de cte ori este posibil;
Dispozitivele trebuie s furnizeze interfe e universale, interoperabile i cu acces securizat;
Dispozitivele trebuie s poat fi integrate u or n cadrul sistemelor complexe i integrarea
trebuie s fie scalabil ;
Fiecare subsistem trebuie s fie expus precum un singur dispozitiv astfel nct s poat fi
integrat n sisteme mult mai complexe;
Interac iunile dintre dispozitive trebuie s fie previzibile.
n cadrul lucr rii se prezint o arhitectur orientat pe servicii care optimizeaz aplica iile industriale
din mai multe puncte de vedere. Aceasta permite aducerea mai aproape de proces a deciziilor luate
la nivelele superioare ale piramidei de automatizare i poate fi aplicat ntr-o gam larg de procese
industriale.
n acest sens au fost identificate obiectivele principale la dezvoltarea arhitecturii:
optimizarea proceselor de fabrica ie prin determinarea unor planuri de fabrica ie optime;
utilizarea automat , f interven ia unui operator uman, a planurilor de fabrica ie optime;
construirea unei arhitecturi flexibile, adaptabile i reutilizabile, care s reduc timpii de
instalare i setare la valori minime.
Cartea este format din ase capitole.
n Capitolul 1 este prezentat o descriere a stadiului actual al cercet rilor n domeniul arhitecturilor
orientate pe servicii. Se prezint un scurt istoric al acestor arhitecturi, se realizeaz o descrierea
detaliat a conceptului de serviciu software i a aspectelor implicate n utilizarea acestor servicii:
contractarea serviciilor, calitatea serviciilor i securitatea acestora. De asemenea se prezint
arhitectura generalizat pe nivele a conceptului SOA. O parte important a capitolului este dedicat
aplic rii conceptului de arhitectur orientat pe servicii n industrie. n acest sens sunt prezentate
progresele recente realizate n domeniul telecomunica iilor, produc iei i a colabor rii business-tobusiness. n sec iunea de concluzii a capitolului se realizeaz o analiz critic a cercet rilor efectuate
i se identific posibile mbun iri.
n Capitolul 2 este prezentat o descriere a stadiului actual al cercet rilor n domeniul problemelor
de satisfacere a constrngerilor. Se prezint no iunile principale ale acestui concept precum i o
descriere detaliat a problemelor de scheduling, care sunt folosite pentru a determina orare de lucru
optimizate n cadrul aplica iilor industriale. Se introduc de asemenea pe scurt cele trei solver-e care
sunt folosite de-a lungul lucr rii pentru implementarea problemelor de optimizare. Din nou, o parte
important a capitolului este dedicat prezent rii progreselor recente realizate n domeniul aplic rii
conceptului de CSP n diverse domenii industriale. n sec iunea de concluzii a capitolului se
realizeaz o analiz critic a cercet rilor efectuate i se identific posibile noi direc ii de cercetare.
Capitolul 3 introduce conceptul general al arhitecturii orientate pe servicii, propuse n cadrul
lucr rii. Aceast arhitectur adreseaz principalele probleme identificate de-a lungul capitolelor 1 i
2 i ndepline te obiectivele men ionate n capitolul introductiv. Arhitectura este format din trei
XIV
PREFA
nivele: nivelul de baz este reprezentat de o serie de servere OPC UA care sunt folosite pentru a
modela datele de la nivelul dispozitivelor de control ale instala iilor industriale. Nivelul intermediar
este format dintr-un set de servicii software organizate n dou nivele (servicii de baz i servicii
complexe) iar nivelul superior este format din probleme de satisfacere a constrngerilor.
Capitolul 4 prezint aspectele esen iale ale nivelului serverelor OPC UA. Tehnologia OPC UA a
fost introdus ca i nlocuitor al conceptului clasic OPC. n acest sens se realizeaz o scurt
introducere a acestei noi tehnologii precum i o compara ie cu OPC-ul clasic. La acest nivel a fost
dezvoltat o solu ie software numit software special de adaptare, care este folosit pentru
modelarea dispozitivelor de control actuale n cadrul serverelor OPC UA. De asemenea au fost
defini i o serie de 5 algoritmi care sunt utiliza i pentru generarea automat a spa iului de adrese al
unui server OPC UA. Acest nivel reprezint baza arhitecturii care permite utilizarea automat a
orarelor optime de lucru determinate la nivelul superior al arhitecturii, f
interven ia unui operator
uman.
Capitolul 5 prezint detalii referitoare la proiectarea i implementarea nivelului intermediar al
arhitecturii, care este format din dou subnivele de servicii software. Deoarece timpul de execu ie
reprezint un aspect critic n aplica iile industriale, se evalueaz trei solu ii diferite de implementare
(servicii web SOAP, servicii web REST i servicii Java). Cu ajutorul a dou teste de performan
dezvoltate pentru serviciile de baz , se determin solu ia optim din punctul de vedere al timpului de
execu ie. De asemenea sunt prezentate i cele patru tipuri de servicii complexe care sunt folosite la
nivelul intermediar al arhitecturii, mpreun cu o serie de solu ii software inovatoare de
implementare.
Capitolul 6 prezint aplica ia principal pentru care a fost dezvoltat arhitectura, i anume
optimizarea unui proces industrial care folose te o serie de linii flexibile de fabrica ie. Este
prezentat problema care trebuie optimizat precum i detaliile de implementare la fiecare nivel al
arhitecturii propuse. Aplica ia a fost testat cu ajutorul liniei flexibile disponibile n cadrul
laboratorului universit ii.
XV
1 ARHITECTURI ORIENTATE PE SERVICII
1.1 INTRODUCERE
Termenul de arhitectur este folosit pentru a defini un plan pentru construirea unor sisteme care
ndeplinesc cerin e precise i bine definite sau pentru construirea unor sisteme mai detaliate care
posed caracteristicile necesare ndeplinirii cerin elor men ionate.
Prin arhitectur software se face referire la modul de construire al unui sistem software (componente
principale, rela ii dintre componente i interfa a fiec rei componente). Este foarte important ca
arhitectura software s fie bine definit datorit complexit ii sistemelor software i mai ales datorit
posibilelor modific ri care trebuie realizate pentru un asemenea sistem. Aceste modific ri pot s
devin necesare datorit schimb rilor realizate n mediul tehnic, organizatoric sau de afaceri.
Elementul de noutate n cazul arhitecturii orientate pe servicii este abordarea diferit : construirea
sistemelor care se concentreaz pe realizarea de aplica ii ca o combina ie de servicii [Erl T., 2005].
Mai precis, SOA i propune construirea independent a serviciilor dedicate activit ilor economice.
Aceste servicii pot fi apoi combinate n cadrul unor aplica ii coerente i de nivel nalt care s se
integreze perfect n contextul companiei pentru a pune n eviden o serie de avantaje: agilitate, o
mai mare flexibilitate i un timp de reac ie mai mic. Aceste sisteme nou definite vor oferi apoi
capabilit i sub form de servicii.
Beneficiul real al conceptului SOA apare atunci cnd serviciile reutilizabile sunt combinate pentru a
crea procese economice agile i flexibile. Din p cate, acest lucru nu este u or de realizat. Atingerea
acestui obiectiv ar fi posibil n cazul n care o singur organiza ie (un singur grup) ar crea toate
serviciile, dar acest lucru nu este practic n cazul organiza iilor mari. Ca i consecin , o parte din
arhitectura SOA este responsabil de crearea mediului necesar pentru dezvoltarea i folosirea
serviciilor definite n cadrul organiza iei.
Cu alte cuvinte, arhitectura orientat pe servicii permite diferitelor organiza ii s implementeze n
mod independent serviciile care r spund necesit ilor lor imediate, dar care pot fi de asemenea
combinate n procese de domeniu de nivel superior.
SOA nu este o tehnologie, este doar o abordare utilizat pentru a modela i remodela sisteme:
Aplica iile construite cu o arhitectur software orientat pe servicii integreaz mai multe
aplica ii diferite, dar care au interfe e comune, asigurndu-se astfel mbun irea reutiliz rii i
a mentenan ei;
Cnd se face referire la o arhitectur , exist trei aspecte importante:
o Indicarea rela iei dintre componente;
1. ARHITECTURI ORIENTATE PE SERVICII
o Descoperirea componentelor principale ale sistemului;

o Combinarea componentelor ntr-un mod care furnizeaz valoare sporit pentru
nivelul superior.
Alte aspecte importante n raport cu conceptul SOA sunt:
Procese func ii economice de nivel nalt, care deseori cuprind aplica ii esen iale pentru
succesul unei companii;
Servicii unit i modulare de func ionalitate n domeniul economic;
Integrarea conectarea la i expunerea aplica iilor i/sau a datelor existente ca servicii;
Sistemele existente sistemele existente (mo tenite sau preluate din trecut), cele comerciale
achizi ionate din exterior i datele pe care ntreprinderea trebuie s le gestioneze;
Documente unit i de informa ii de domeniu de nivel nalt, precum un ordin de cump rare
sau un document EDI (Electronic Data Interchange);
Semantica sensul de baz al informa iilor care sunt interschimbate ntre procese;
Transformare conversia informa iilor dintr-un format specific ntr-un altul;
Comunica ii capacitatea serviciilor de a comunica ntre ele.
1.2 ISTORIA SOA
Termenul de arhitectur orientat pe servicii a fost definit n 1996 [Hurwitz J., 2007], dar
conceptul SOA a fost folosit chiar mai devreme. Companii financiare (precum b nci) i companiile
de telecomunica ii au fost n m sur s defineasc servicii i s le combine n aplica ii folosind
tehnologii distribuite (precum CORBA sau DCOM Distributed Common Object Model care este o
extensie a lui COM Component Object Model introdus de Microsoft).
Analiznd primele ncerc ri, exist dou motive principale care sunt responsabile pentru e ecul lor:
Majoritatea companiilor nu aveau un colectiv de programatori i de proiectan i de aplica ii
pentru a putea gestiona aceste noi tehnologii;
Nimeni nu tia n ce const un serviciu corect. Chiar dac se descoperiser caracteristicile unui
serviciu el trebuia mai nti descris n mod abstract i apoi implementat.
Cele mai multe tentative au e uat chiar nainte ca programatorii s poat testa func ionalitatea
serviciilor. Mul i nu tiau cu adev rat ceea ce nsemn SOA i, prin urmare, nici implementarea
conceptului nu putea fi de succes [Reddy V. K., 2009].
n figura 1.1 este prezentat o cronologie a evolu iei SOA. Au existat i alte tehnologii, precum
Tuxedo (care este orientat pe servicii), care au stat la baza unor aplica ii performante i distribuite.
Unele companii au reu it s implementeze SOA cu succes, dar num rul proiectelor reu ite este mult
mai mic dect al celor e uate.
Mai trziu, companii precum IBM, Oracle sau Sun au dezvoltat acest concept i au definit termenul
de SOA. Analiznd situa ia actual , trebuie recunoscut faptul c a avut loc o evolu ie a conceptului,
iar serviciile web din ziua de azi sunt mai u or de utilizat. Tehnologia nu a devenit mai simpl dar
instrumentele i mediile moderne de lucru le-au permis programatorilor s fac un mare pas nainte.
Se poate spune c este posibil s se realizeze servicii de calitate chiar dac nu se cunoa te cu
exactitate ce nseamn un serviciu sau nu se cunosc prea multe despre tehnologia folosit .
Informa iile legate de distribu ie i de servicii sunt integrate n ziua de azi ntr-o platform care
poatefi bazat pe Java,. Net sau pe orice alt tehnologie disponibil .
2
Fig. 1.1. Evolu ia SOA [Rosen, M., 2008].
1.3 SERVICII
1.3.1 Generalit i
Dup cum s-a precizat, serviciul reprezint conceptul fundamental SOA. n primul rnd
programatorul trebuie s afle condi iile care trebuie respectate de c tre un serviciu corect definit
[Tinny N., 2009]. Organiza ia pentru promovarea standardelor de informa ii structurate (OASIS)
define te un serviciu ca fiind un mecanism care s permit folosirea uneia sau mai multor
capabilit i, accesul fiind realizat prin intermediul unei interfe e scrise anterior i care se comport
conform constrngerilor i politicilor specificate n descrierea serviciului. Un serviciu corect definit
trebuie s implementeze un set de caracteristici speciale.
Cnd se descrie un serviciu, trebuie avute n vedere dou aspecte distincte [Turner M., 2003]:
Implementarea serviciului: specific modul n care vor fi asigurate capabilit ile serviciului
(informa iile de ie ire). Aici se face referire la func ionalitatea intern a serviciului, care se
poate baza pe alte aplica ii existente, pe servicii sau pe cod scris special pentru acest serviciu.
Un serviciu va avea ntotdeauna i date interne folosite pentru a furniza informa iile
specificate ca ie iri;
Interfa a serviciului: specific opera iile executate de c tre un serviciu, intr rile i ie irile
serviciului, precum i protocoalele care definesc modul n care capabilit ile trebuie utilizate
(de exemplu: tipurile de date care trebuie s fie furnizate la intrare i tipurile de date
disponibile la ie ire).
Aceste dou aspecte sunt complet separate, a a cum se poate observa i n figura 1.2. Prin
introducerea acestei separ ri, consumatorii nu au acces la sec iunea de implementare a unui serviciu
[Rosen M., 2008]. Singurul aspect de care trebuie s fie preocupa i este contractul de interfa (adic
tipul i num rul intr rilor i ie irilor) i o dat ce acest contract este specificat, serviciul poate fi
utilizat f
restric ii. Produc torul de servicii poate schimba apoi implementarea serviciului, dar
acest aspect nu va afecta consumatorul, att timp ct interfa a nu este modificat .
n plus fa de structura specific a unui serviciu, serviciile corect alc tuite prezint i urm toarele
propriet i:
Interdependen limitat : aceast caracteristic poate fi considerat ca fiind cea mai
important proprietate a unui serviciu. ntre consumatorul de servicii (o persoan , un sistem
software sau un alt serviciu) i furnizorul de servicii exist n mod implicit o rela ie, dar
3
num rul acestor rela ii trebuie men inut la un nivel sc zut astfel nct administrarea sistemului
fie ct mai simpl ;
Modularitate i granularitate: procesele de domeniu sunt alc tuite din servicii modulare, care
pot la rndul lor s fie compuse din alte servicii. Granularitatea se refer la diversitatea
func ional a unui serviciu. Serviciile trebuie definite n a a fel nct s ofere func ionalit i
ct mai generale pentru a se asigura o reutilizare ct mai dezvoltat ;
ncapsulare: implementarea intern i datele unui serviciu sunt ascunse;
Reutilizare: aceast proprietate este de fapt rezultatul celor trei propriet i anterioare
(interdependen limitat , modularitate i ncapsulare) i se refer la faptul c un singur
serviciu poate fi utilizat n procese de domeniu diferite sau poate fi accesat de consumatori
diferi i;
Izolarea responsabilit ii: fiecare serviciu va fi responsabil pentru una sau mai multe func ii
specifice. Ca urmare, fiecare func ie va fi efectuat ntr-un singur loc. Astfel redundan a este
redus , fiind n acela i timp asigurat i coeren a.
Fig. 1.2. Structura unui serviciu [Rosen, M., 2008].
1.3.2 nregistrarea i contractarea serviciilor

Acesta este un aspect esen ial atunci cnd se construiesc aplica ii bazate pe SOA. Figura 1.3 prezint
modelul find bind execute (g se te conecteaz execut ) utilizat de SOA.
Fig. 1.3.Paradigma find bind execute (g se te conecteaz execut ) [***Oracle: SOA & Web Services,
2011].
Conform acestui model, furnizorii de servicii vor nregistra serviciile lor ntr-un registru public.
Apoi consumatorul va c uta n cadrul acestui registru serviciile necesare. Dac serviciul dorit este
sit, consumatorul va primi un contract i o adres de endpoint pentru serviciul respectiv (pentru a
putea apela serviciul i pentru a fi informat atunci cnd serviciul este modificat).
1.3.3 Servicii web
Serviciile web au reprezentat un aspect important n evolu ia conceptului SOA i reprezint cel mai
utilizat tip de servicii software la momentul actual. Serviciile web furnizeaz de obicei o solu ie
bazat pe XML pentru conectarea sistemelor software de diferite tipuri.
Un serviciu web este un serviciu pe partea de server a c rui interfa este definit prin limbajul XML
(de fapt prin limbajul WSDL specific serviciilor web, dar care se bazeaz pe XML), care expune una
sau mai multe opera ii prin RPC (Remote Procedure Call), care sunt independente de implementarea
lor i care sunt accesibile prin intermediul unor protocoale open source precum HTTP (HyperText
Transfer Protocol), SMTP (Simple Mail Transfer Protocol) i FTP (File Transfer Protocol).
Din punct de vedere principial, un serviciu web st la baza aplica iilor eterogene i interoperabile.
Deoarece serviciile web sunt bazate pe XML, ele pot fi descrise n mod abstract. Scenariul clasic al
utiliz rii serviciului web se bazeaz pe paradigma
se te conecteaz execut prezentat
anterior.
Tehnologiile actuale contribuie la stabilirea unei funda ii solide care s faciliteze implementarea
serviciilor web. Protocoalele de comunica ie, standardele bazate pe XML, precum i facilit ile de
gestionare ofer un suport bun pentru interoperarea serviciilor web. Num rul tot mai mare de
servicii web utilizate pe internet declan eaz o modificare important de la web-ul centrat pe date la
web-ul centrat pe servicii.
1.3.4 Managementul calit ii serviciilor
Adoptarea pe scar larg a serviciilor a crescut cererile pentru noi moduri de utilizare n special a
tehnologiei serviciilor web. Utilizatorii ncep s recombine i s medieze serviciile altor furnizori de
servicii n moduri care nu au fost anticipate de c tre furnizorii originali ai serviciilor. n cadrul
organiza iilor i comunit ilor inter-organiza ionale, serviciile care pot fi puse la dispozi ia
utilizatorilor sunt organizate n containere, oferind un acces convenabil la procese care pot fi puse n
leg tur . Aceast idee este surprins n termenul ecosistem de servicii. n lucrarea [Riedl C., 2009]
se adreseaz realizarea managementului calit ii n astfel de ecosisteme de servicii. Managementul
calit ii serviciului este o provocare esen ial atunci cnd serviciile sunt compuse dintr-un set
dinamic de sub-servicii eterogene de la diferi i furnizori de servicii.
La furnizare serviciile sunt livrate unor consumatori de servicii necunoscu i (printr-o gam larg de
canale). Calitatea este foarte important deoarece ea este direct legat de beneficiile ob inute. Prin
selectarea dinamic a sub-serviciilor, furnizorii trebuie s se asigure c serviciile lor sunt selectate n
defavoarea celor oferite de concuren i.
Acest el poate fi atins numai printr-o calitate excep ional , care satisface n mod constant att
clien ii (de exemplu, un broker) ct i consumatorii de servicii.
1.4 ARHITECTURA PE NIVELE A CONCEPTULUI SOA

Figura 1.4 prezint nivelele semantice care pot fi definite ntr-un mediu SOA [Lawler J., 2008]. n
partea de jos se afl nivelul sistemelor opera ionale (aici se reg sesc componentele care vor furniza
func ionalitatea: aplica ii i date). La acest nivel este asigurat posibilitatea de reutilizare a
serviciilor iar registrul va stoca informa ii i metadate referitoare la aspectele reutilizabile.
Urm torul nivel prezint serviciile disponibile. Acestea pot fi combina ii ale datelor i aplica iilor de
la nivelul inferior dar pot fi i combina ii de servicii din exterior. Serviciile vor oferi interfe e, astfel
nct s poat fi combinate n aplica ii complexe, f
ca programatorul s fie preocupat de
elementele care implic logica aplica iei.
Al treilea nivel prezint procese de domeniu care reprezint activit ile unei companii. Un proces de
domeniu reprezint o serie de opera ii care trebuie executate secven ial sau paralel, urmnd un set de
reguli. n literatua de specialitate se folose te adesea termenul de orchestra ie pentru a face referire
la selec ia, succesiunea i executarea opera iilor. n mod normal, un proces de domeniu va folosi mai
multe servicii i va realiza pentru consumatori diferite ac iuni i activit i.
Fig. 1.4. Arhitectura stratificat SOA [***IBM, 2007].
Nivelul superior prezint moduri sau canale care pot fi folosite pentru a accesa serviciile de baz . n
figur sunt prezentate cteva exemple: servicii web, dispozitive, aplica ii business-to-business, etc.
Dup cum se poate observa, n afar de nivelele descrise anterior, n figura 1.4 sunt prezentate i o
serie de cadre. Cadrul de guvernan SOA i management al ciclului de via se refer la setul de
politici pe care consumatorii i furnizorii de servicii trebuie s le respecte i la practicile care trebuie
realizate pentru a se asigura c acele politici sunt aplicate corespunz tor.
Cadrul situat n mijloc, infrastructura i managementul SOA se refer la extensii minore pe care
companiile trebuie s le implementeze pentru ca infrastructura existent s sus in conceptul SOA
6
ntr-un mod organizat. Etapele pentru structurarea i gestionarea mediului SOA vor fi descrise n
cadrul ciclului de via SOA.
Ciclul de via SOA con ine urm toarele etape [Marks E., 2008]:
Faza de modelare: identificarea necesit ilor de domeniu i apoi proiectarea serviciilor care s
asigure performan e maxime. n final, serviciile trebuie s fie simulate i n cazul n care se
descoper probleme, acestea trebuie rezolvate.
Faza de asamblare: definirea procesului de domeniu prin asamblarea serviciilor nou create ct
i a celor existente;
Faza de lansare: lansarea proceselor de domeniu n mediul n care acestea vor fi utilizate.
Ulterior trebuie definite alte servicii care vor asigura integrarea persoanelor i a altor procese;
Faza de gestionare: Monitorizarea proceselor de domeniu din punctul de vedere al
furnizorului i al consumatorului. Problemele identificate n aceast faz pot fi apoi utilizate
pentru mbun irea serviciilor i a proceselor de domeniu.
Cadrul interior din figura 1.4 se refer la conectivitatea serviciilor. Unul dintre principalele avantaje
oferite de SOA este flexibilitatea. O mare parte din acest avantaj se pierde n cazul n care serviciile
sunt conectate punct-la-punct. nlocuirea unui singur serviciu poate avea efecte dezastruoase n
cazul n care serviciile prezint interdependen ridicat .
1.5 SECURITATEA SOA O PROBLEM DE CONFIDEN IALITATE, INTEGRITATE
I DISPONIBILITATE
1.5.1 Introducere n securitatea informa ional
Confiden ialitatea, integritatea i disponibilitatea (CIA) reprezint un punct de referin utilizat pe
scar larg pentru evaluarea securit ii sistemelor informatice. Triada CIA, prezentat n figura 1.5,
reprezint principiile de baz ale securit ii informa iilor [Menzel M., 2009]. GASSP (Generally
Accepted System Security Principles principiile de securitate general acceptate ale sistemelor)
define te principiile de securitate ale informa iilor ntr-un context mai larg. Acesta include principii,
standarde, conven ii i mecanisme. GAASP consider triada CIA o entitate fundamental pentru
toate sistemele de informa ie.
O alt organiza ie, Institutul Na ional de Standarde i Tehnologie (NIST) define te securitatea
calculatorului ca fiind protec ia acordat unui sistem informa ional automatizat cu scopul de a
atinge obiectivele de conservare a integrit ii, disponibilit ii i confiden ialit ii resurselor de
informa ii din sistem. Aceste principii se aplic indiferent de platforma de tehnologie (hardware,
software sau firmware), de canalele de comunica ie, de dimensiunea organiza iei, etc. Conform
NIST, cele trei principii pe baza c rora securitatea este m surat pot fi descrise dup cum urmeaz :
Confiden ialitate: O cerin conform c reia informa iile confiden iale nu trebuie dezv luite
unor persoane neautorizate;
Integritate: Integritatea datelor este o cerin conform c reia informa iile i programele sunt
modificate doar ntr-o manier specific i autorizat . Integritatea sistemului i a aplica iei
sunt cerin e conform c rora sistemul sau aplica ia trebuie s i ndeplineasc func iile ntr-o
manier irepro abil , f manipulare neautorizat deliberat sau accidental ;
Disponibilitate: Asigurarea c un sistem lucreaz prompt i c cerin a de ndeplinire a
serviciilor nu le este respins utilizatorilor autoriza i.
7
In ciuda necesit ii lor, aceste aspecte cruciale ale securit ii nu sunt suficiente pentru crearea unui
mediu SOA securizat.
Fig. 1.5. Triada CIA [Menzel, M., 2009].
1.5.2 Securitatea SOA

Func ionarea SOA impune consumatorului de servicii s fie capabil s se conecteze la broker-ul de
servicii (func ia de g sire a serviciului) i, ulterior, la produc torul de servicii (func ia de invocare a
serviciului). n mod similar, produc torul de servicii trebuie s fie capabil s se conecteze la brokerul de servicii (s publice servicii) i la consumatorul de servicii (s -i furnizeze servicii). Acest lucru
presupune c exist posibilitatea ca toate domeniile de servicii s se poat conecta ntre ele f a lua
n seam considerentele de securitate i de ncredere. n cazul arhitecturii tradi ionale client-server,
aplica ia server se presupune a fi con tient de modelul de securitate adecvat i este de asemenea
responsabil pentru deciziile luate privind securitatea. Prin urmare, aplica ia server este demn de
ncredere pentru a monitoriza toate datele, inclusiv informa iile confiden iale pe care clientul le
transmite. Expunerea crescut de servicii n contextul SOA genereaz un poten ial mai mare de
compromis, deoarece fiecare serviciu devine un punct vulnerabil atacurilor [Pajevski M., 2004]. n
acela i timp, daunele provocate sunt mai mari datorit expunerii crescute de date care trebuie s fie
protejate att n momentul transmisiei ct i n timpul p str rii acestora ntr-o loca ie stabil .
n cazul SOA, o aplica ie poate fi compus din servicii sau din mai multe aplica ii. Un serviciu poate
fi invocat n contexte diferite, de c tre diverse aplica ii client, ceea ce nseamn c nu se poate spune
niciodat cine ar trebui s gestioneze sau s garanteze securitatea. Aplica iile nu mai pot fi
responsabile singure de securitate i modelele de securitate nu pot fi implementate n codul
aplica iilor [Ramarao K. 2008]. De asemenea, succesul SOA implic transmiterea unor volume mari
de informa ii critice n timp real, aspect care intensific vulnerabilitatea aplica iei fa de
amenin rile de securitate.
Infrastructura de securitate trebuie s fie accesibil independent de tehnologie, folosind standarde
deschise. O serie de noi tehnologii i standarde sunt n curs de dezvoltare pentru a oferi mai multe
modele adecvate de securitate n contextul SOA. Un neajuns al acestor standarde este c acestea se
concentreaz mai degrab pe rezolvarea problemei de securitate n etapele de implementare n loc s
se concentreze asupra aspectelor legate de proiectarea securit ii. Prin urmare este esen ial s se ia n
considerare impedimentele de securitate din punct de vedere arhitectural i s se rezolve problema
securit ii printr-o abordare holistic .
1.5.3 Utilizarea standardelor n contextul securit ii SOA
Deoarece SOA se bazeaz pe standarde, este necesar ca standardele s aib o securitate accentuat .
Standardele utilizate n SOA (n principal standarde ale serviciilor web precum XML, SOAP i
8
UDDI) nu subliniaz sau nu scot n eviden securitatea. Unele protocoale permit folosirea
securit ii n cadrul acestor standarde, precum SSL (Secure Socket Layer) pentru HTTP sau
criptarea pentru XML. Un exemplu n care utilizarea standardelor poate conduce la probleme este i
cazul n care se folosesc firewall-uri. Majoritatea companiilor folosesc firewall-uri care controleaz
traficul de la o organiza ie extern la organiza ia intern . Cnd se implementeaz SOA cu ajutorul
serviciilor web, sunt folosite n mod normal HTTP i SSL. Aceste protocoale utilizeaz porturile
TCP 80 i 443, care, de obicei, pot trece prin firewall. Prin urmare, trebuie s fie puse n aplicare
caracteristici de securitate suplimentare pentru a preveni posibilele amenin ri.
Serviciile necesit un limbaj de descriere pentru a prezenta ceea ce acestea pun la dispozi ie i ceea
ce acestea a teapt s primeasc n urma apelului. Unul dintre limbajele utilizate n mod obi nuit n
SOA este WSDL. Limbajele de descriere trebuie s utilizeze standarde deschise pentru a se asigura
compatibilitatea complet cu poten ialii consumatori de servicii. Pe de alt parte standardele
deschise permit unui eventual adversar s scaneze posibilele vulnerabilit i ale unui serviciu.
Folosirea standardelor n exclusivitate nu ofer siguran aplica iilor SOA.
Se poate observa c una dintre dificult ile cele mai mari n dezvoltarea arhitecturilor orientate pe
servicii o reprezint rezolvarea problemelor de securitate, deoarece responsabilit ile securit ii SOA
se bazeaz att pe furnizorii de servicii ct i pe consumatori. n ultimii ani au fost implementate
multe solu ii pentru aceste probleme, precum Web Services Security Standards, incluznd WSSecurity i WS-Policy. Cu toate acestea, aceste standarde sunt insuficiente pentru noua genera ie de
tehnologii Web, inclusiv aplica ii Web 2.0. n [Yamany H. F., 2010] se propune un framework
inteligent pentru securitatea SOA prin introducerea a dou servicii: serviciul de autentificare i
securitate (NSS) i serviciul de autorizare (AS). Serviciile autonome si reutilizabile sugerate sunt
construite ca extensie pentru standardele de securitate WS-*, cu ad ugarea unor tehnici de c utare i
procesare inteligent , cu scopul de a mbun i performan a i eficien a. Aceste servicii, cel de
autentificare i securitate i serviciul de autorizare, con in un nucleu de procesare inteligent care
ajut la prezicerea atacurilor ascunse ntr-un mesaj de cerere SOAP. n plus, acestea completeaz
tehnicile de autorizare existente, prin introducerea unei noi structuri OLAP (OnLine Analytical
Processing) care s poat gestiona toate tipurile de roluri de autorizare, constnd din roluri obi nuite
i rolurile de domeniu.
Pentru a avea o aplica ie SOA sigur , pe lng principiile de baz ale securit ii i anume
confiden ialitatea, integritatea i disponibilitatea (CIA) sunt necesare i alte principii de securitate,
precum autentificarea, autorizarea, auditul i non-repudierea.
1.6 APLICAREA CONCEPTULUI SOA N INDUSTRIE
1.6.1 Telecomunica ii
Conceptul SOA are aplicabilitate n utilizarea protocoalelor inovatoare la nivelul de transport sau de
re ea. Chiar dac aceste protocoale sunt disponibile, cele mai multe aplica ii nu sunt capabile s le
utilizeze, deoarece protocolul TCP/IP (Transfer Control Protocol / Internet Protocol) este
implementat n codul aplica iei. Scopul SOCS (sistemele de comunica ie orientate spre servicii) este
de a decupla aplica iile de protocoalele de la nivelele inferiore. Conform [Reuter B., 2008] trebuie
introdus o interfa orientat pe servicii ntre aplica ii i nivelul de transport.
Un broker mediaz cererile de transport c tre configura iile corespunz toare ale prestatorilor de
servicii de transport. O schem de specifica ie flexibil i independent de protocol pentru definirea
necesit ilor i ofertelor serviciilor este considerat ca fiind un element cheie pentru o astfel de
interfa . Scopul SOCS este acela de a sprijini introducerea de noi protocoale prin simplificarea
modului de utilizare a protocoalelor noi sau modificate. Pentru a realiza acest lucru, SOCS
decupleaz aplica iile de protocoale, p strnd totu i posibilitatea de a optimiza furnizorii de servicii
de transport (Transport Service Providers TSN) n func ie de necesit ile utilizatorilor i
aplica iilor precum i n func ie de contextul dat. Pentru a putea fi folosit ntr-o gam larg de
aplica ii, se pot realiza att specifica ii precise i foarte detaliate ct i descrieri simple i abstracte.
De exemplu, propriet ile serviciilor pot fi evaluate att pe baza unor estim ri subiective ct i pe
baza m sur torilor obiective. Func ionalit ile oferite de servicii pot con ine referin e la date externe
astfel nct s se ia n considerare i informa ii dinamice ale contextului.
Conform [Kim J. W., 2007], conceptual, SOA a fost deja implementat n sistemele de suport ale
opera iilor (OSS) furnizorilor de servicii de telecomunica ie. Lucrarea propune o abordare a
conceptului SOA prin utilizarea serviciilor web n domeniul furniz rii de servicii n zona proiect rii
i implement rii OSS. Se definesc activit ile opera ionale necesare pentru a deservi clien ii, pentru
a rearanja aceste activit i astfel nct s sprijine serviciile autonome i se proiecteaz un proces care
este compus din numeroase servicii.
Sistemul de livrare a serviciilor dezvoltat de autori con ine trei p i care asigur furnizarea
serviciilor WLAN c tre clien i. Prima parte este procesul de domeniu precum i sub-procesele corect
definite. A doua parte este o regul de domeniu care define te condi ia de decizie care influen eaz
procesul. Cea de-a treia parte este un serviciu care este implementat ca i component software, de
exemplu ca i component a metodologiilor CBD (Component-Based Development).
1.6.2 Produc ie
Exist mai multe aspecte care trebuie avute n vedere atunci cnd se face referire la posibilele
avantaje ale folosirii conceptului SOA n industrie [Hong H., 2006]. Companiile energetice sau
furnizoare de utilit i au nevoie de procese care s permit managerilor s monitorizeze aspectele
critice ale companiei. Aceste procese trebuie s achizi ioneze datele corespunz toare, s le
prelucreze i apoi s furnizeze informa ii pentru manageri, astfel nct ace tia s adopte deciziile
corecte. Foarte adesea managerii trebuie s ia decizii bazate pe informa ii eronate i n acest caz
conceptul SOA poate fi aplicat pentru a rezolva problema. Trebuie definite servicii corespunz toare,
care n combina ie vor fi capabile s prelucreze datele brute i s ofere rezultate reale i utilizabile
[Blum N., 2009], [Josuttis N. M., 2007]. Aceste aspecte se refer la nivelul ERP al piramidei de
automatizare.
Din punctul de vedere al nivelului MES al piramidei de automatizare, companiile trebuie s fie
foarte flexibile. Ele trebuie s fac fa situa iilor n care clien ii doresc fabricarea unui num r mic
de piese sau de piese diferite. Astfel, companiile trebuie s fie la fel de flexibile ca i b ncile sau alte
societ i n care consumatorii sunt persoane.
Lucrarea [Veiga G., 2009] descrie integrarea echipamentelor n celulele robo ilor industriali, ac iune
care reprezint n tot mai mare m sur interfa area tehnologiilor Ethernet moderne cu dispozitive
ieftine, fabricate n mas , precum sisteme de vedere artificial , camere cu laser, senzori de for cuplu, software-ul automatelor programabile, etc. Programarea eficient a tuturor acestor dispozitive
10
necesit prea multe cuno tin e despre acestea, despre arhitecturile hardware i limbajele lor specifice
de programare, despre protocoalele de nivel fizic, precum i despre alte detalii la nivel de sistem.
Pentru a aborda aceste probleme, lucrarea prezint i analizeaz dou dintre cele mai interesante
arhitecturi orientate pe servicii (SOA) disponibile, care prezint caracteristici bine adaptate la
celulele robo ilor industriali: UPnP (Universal Plug-n-Play) i DSSP (Decentralized Service
Structure Protocol).
UPnP se bazeaz substan ial pe protocoale standard de re ea, precum TCP/IP, UDP, HTTP, SOAP,
XML i tehnologii web. Prin urmare, acesta este independent de platform i de limbaj, ceea ce
reprezint un avantaj major pentru adoptarea sa. Formatele XML sunt larg folosite i acceptate i
ofer mecanisme moderne de transfer i comunicare a datelor.
DSSP este un protocol simplu, bazat pe SOAP, care define te un model de serviciu n stilul REST i
care se bazeaz n mare parte i pe tehnologia web.
Stilurile de arhitectur sunt radical diferite la DSSP i UPnP. Acest lucru este vizibil n MSRS
(MicroSoft Robotics Studio) deoarece nu exist metode tip RPC (Remote Procedure Call) n DSSPul Microsoft. n aceast arhitectur totul este un mesaj i totul este condus sau conduce la schimb ri
de stare.
n ceea ce prive te independen a limbajului/platformei, UPnP este mai avantajos. Construit pe
standarde comune, exist extensii disponibile pentru toate platformele majore (Windows, Linux)
precum i diverse pentru limbaje (C #, Java, C++). n plus, MSRS se bazeaz exclusiv pe platforma
.NET. Rezultatele ob inute arat n mod clar c folosind schemele de integrare bazate pe SOA se
reduce timpul de integrare a sistemului.
Din lucrarea [Veiga G., 2009] putem concluziona c prin concentrarea aten iei asupra
automatiz rilor industriale i n special asupra program rii celulelor robo ilor industriali, SOA poate
sprijinii inginerii de automatizare, permi ndu-le s utilizeze n continuare platforma/limbajul lor
favorit, s se bazeze pe tehnologiile standard i s reduc aten ia acordat sarcinilor dificile de
interconectare.
Programarea celulelor robo ilor industriali folosind SOA ca framework i interfe e grafice pentru
specificarea logicii sistemului s-a dovedit, n condi iile acelora i set ri, a necesita mai pu in timp
dect tehnicile tradi ionale orientate pe obiecte.
adar, provenind din lumea afacerilor, paradigma SOA i extinde gama sa de aplicare n mai
multe medii. Conform [Candido G., 2009] automatizarea industrial este tot mai interesat de
adoptarea acesteia ca abordare unificatoare, furniznd diverse avantaje n compara ie cu
automatizarea tradi ional . Arhitectura SOA este indicat n special pentru sprijinul lan urilor de
aprovizionare agile i reconfigurabile datorit naturii sale dinamice. n acest sens, principalele
obiective sunt un interval de timp scurt pn la apari ia pe pia a, (re)configurare rapid a aplica iei,
mai multe dispozitive inteligente cu suport pentru ciclul lor de via , deschidere fa de noi
tehnologii, integrare IT, etc.
Mathes introduce framework-ul Time-Constrained Services (TiCS) [Mathes M., 2008], care const
din patru nivele func ionale: nivelul hardware, nivelul de infrastructur de timp real, nivelul de
servicii de timp real i nivelul de suport. Aspectul cheie al arhitecturii TiCS este interfa de servicii
web cu nivelul hardware [Mathes M., 2009 a)]. Se introduc trei abord ri diferite pentru realizarea
acestei interfe e: dispozitive inteligente, automate programabile (AP) care prezint capabilit i de
servicii web, sau PC-uri industriale (IPC) care ofer servicii web. Prima abordare nu necesit
11
software suplimentar, dar exist pu ine astfel de dispozitive utilizate momentan n industrie. A doua
i a treia abordare necesit un mecanism SOAP adaptat la caracteristicile automatelor programabile i
al IPC-urilor [Mathes M., 2009 b)].
Mecanismele SOAP4PLC i SOAP4IPC dou componente cheie ale framework-ului TiCS
permit procesarea serviciilor web la nivelul AP-urilor i repectiv a IPC-urilor. SOAP4IPC este bazat
pe profilare i monitorizare n timp ce SOAP4PLC este bazat pe abordarea denumit servicii web
controlate prin secven .
Alte componente similare care au ca scop automatizarea industrial nu au fost introduse pn n
prezent. Cu toate acestea exist mai multe ini iative de cercetare orientate spre folosirea serviciilor
web pe sisteme nglobate i cu resurse limitate. Cele mai importante ini iative n acest sens sunt
Devices Profile for Web Services (DPWS) [***DPWS, 2006] i WebServices for Devices (WS4D)
[***WS4D, 2007].
Devices Profile for Web Services (DPWS) reprezint un subset al stivei de protocoale a serviciilor
web numit profilul serviciului web adaptate la cerin ele dispozitivelor cu resurse limitate.
Protocoalele de baz ale DPWS sunt WS-Discovery, WS-Eventing, WS-MetadataExchange, WSTransfer, WS-Security, WS-Policy i WS-Addressing.
WS-Discovery este folosit pentru a descoperi servicii web prin intermediul mai multor mesaje
multicast (transmise c tre toate dispozitivele). Mesajul de prob este utilizat de consumatorul de
servicii web pentru a descoperi un serviciu web. Un serviciu web corespunz tor spunde cu un
mesaj prob potrivit . Un produc tor de servicii web anun disponibilitatea sa sau lipsa acesteia
prin intermediul mesajelor Hello i respectiv Bye. WS-Discovery ofer mesaje rezolv respectiv
rezolvare potrivit pentru rezolvarea problemelor de adresare.
WS-Policy este folosit pentru a descrie caracteristicile serviciilor web ntr-un mod generic. WSPolicy define te un element numit ExactlyOne pentru a descrie mai multe propriet i alternative
precum i un element All pentru a defini mai multe propriet i obligatorii.
WS-Eventing permite o interac iune de tip publicare/abonare ntre servicii. Un serviciu web se poate
abona la evenimente specifice care sunt publicate de surse de evenimente. n consecin , o
interac iune cu interdependen e limitate devine posibil ntre serviciile web.
WS-MetadataExchange i WS-Transfer sunt utilizate n combina ie pentru a transfera metadatele
unui serviciu web. WS-MetadataExchange define te trei perechi de mesaje cerere/r spuns pentru a
ob ine WS-Policy, descrierea WSDL, i schema XML a unui serviciu web specific. A adar
elementele GetPolicy, GetWSDL, i GetSchema sunt definite de WS-MetadataExchange. WSTransfer poate fi folosit pentru a ob ine toate metadatele unui serviciu web ntr-un singur pas. WSTransfer pune la dispozi ie mesaje HTTP pentru a primi metadatele (Get i Put). WS-Security
permite semnarea i criptarea unor p i sau chiar a ntregului mesaj SOAP. WS-Addressing
define te a a numitele referin e ale punctelor de conexiune precum i anteturile mesajelor folosite la
identificarea furnizorilor de servicii web precum i mesajele folosite ntr-o interac iune bazat pe
servicii web. WS-Addressing pune la dispozi ie o schem de adresare neutr din punctul de vedere
al transportului, adic adresarea furnizorilor i a mesajelor nu depinde de protocolul de transport
utilizat.
Deoarece DPWS este doar un profil de serviciu web, utilizarea DPWS pe dispozitive cu resurse
limitate necesit o implementare adecvat . Web Services for Devices (WS4D) [***WS4D, 2007]
este o implementare open source a specifica iei DPWS furnizat de Universitatea Rostock i
12
Universitatea Dortmund. WS4D este disponibil pentru trei platforme diferite (respectiv limbaje de
programare). WS4D-gSOAP permite implementarea aplica iilor DPWS n C i C++ i este bazat pe
motorul de servicii web gSOAP. Java Multi Edition DPWS Stack (JMEDS) permite implementarea
aplica iilor DPWS pe orice platform a limbajului Java.
Scopul principal al DPWS i WS4D este acela de a oferi o interfa de servicii pentru dispozitive cu
resurse limitate. n consecin , DPWS con ine doar un mic subset din toate specifica iile de servicii
web disponibile, i implement rile DPWS se concentreaz pe o utilizare redus de memorie. n
cadrul automatiz rilor industriale, utilizarea unei cantit i reduse de memorie este de dorit deoarece
automatele programabile pun la dispozi ie pu in memorie principal . Pe de alt parte o cerin
important este aceea de a procesa serviciile web n termene limit predefinite. DPWS nu ofer nici
o func ionalitate pentru a descrie sau a garanta ndeplinirea termenelor limit .
Utilizarea WS4D limiteaz protocoalele de servicii web disponibile la acelea definite n DPWS.
Acesta este principalul dezavantaj n compara ie cu arhitectura TiCS. TiCS permite utilizarea
protocoalelor de servicii web atta timp ct acestea au fost integrate n motoarele SOAP4PLC i
SOAP4IPC. n consecin , utiliznd TiCS, o aplica ie de servicii web arbitrar nu doar acelea care
folosesc protocoale pornind de la DPWS poate fi rulat n timp real.
Utilizarea DPWS necesit cuno tin e aprofundate despre tehnologiile de servicii web. n plus,
WS4D sau implement ri asem toare necesit , de asemenea, o perioada de familiarizare din partea
inginerilor automati ti. Deoarece DPWS nu a fost integrat pn acum ntr-un mediu de dezvoltare
tipic IEC 61131-3 spre deosebire de SOAP4PLC utilizarea sa este problematic din punctul de
vedere al unui inginer automatist.
Proiectul SIRENA reprezint o parte din programul de cercetare ITEA (Information Technology for
European Advancement) i are ca obiectiv dezvoltarea unui framework pentru integrarea de
dispozitive eterogene cu resurse limitate din automatiz ri industriale i din domotic precum i din
domeniile auto i ale telecomunica iilor [Jammes F., 2005 b)]. Eforturile de a integra SIRENA au la
baz dou premise: (1) interac iunea este bazat pe orientarea pe servicii (mai precis servicii web) i
(2) dispozitivele nglobate ofer suficient putere de calcul pentru a procesa serviciile web [Bohn H.,
2006].
Framework-ul SIRENA const din SIRENA Basic Framework, SIRENA Framework Enhancements i
SIRENA Framework Extension Interface [***SIRENA, 2011]. SIRENA Basic Framework utilizeaz
specifica ia Devices Profile for Web Services pentru a integra dispozitive nglobate. SIRENA
Framework Enhancements reprezint un set de instrumente care faciliteaz dezvoltarea,
implementarea, integrarea i ntre inerea dispozitivelor ntr-o re ea bazat pe SIRENA. SIRENA
Framework Extension Interface descrie cerin ele pentru ca dispozitivele disponibile care nu sunt
bazate pe SIRENA s poat fi integrate n framework-ul SIRENA.
SIRENA distinge dispozitivele de control i dispozitive controlate precum i ase modele de
interac iune dintre aceste dispozitive:
adresare: Fiec rui dispozitiv de control i controlat i se atribuie o adres unic pentru a
permite comunicarea determinist ntre echipamente.
descoperire: Un dispozitiv controlat care intr ntr-o re ea SIRENA public serviciile sale,
ntruct un dispozitiv de control va c uta servicii dac intr ntr-o re ea SIRENA.
descriere: Un dispozitiv de control necesit informa ii detaliate despre propriet ile unui
dispozitiv controlat, de ex. servicii oferite, produc tor, versiune sau num r de serie. Aceste
13
metadate sunt cerute de c tre dispozitivul de control iar dispozitivul controlat r spunde cu o
descriere a acestora.
control: Dispozitivul de control trimite un mesaj de control c tre dispozitivul controlat pentru
a declan a un serviciu. Dispozitivul controlat poate r spunde cu un mesaj corespunz tor.
evenimente: Evenimentele faciliteaz comunicarea asincron ntre dispozitivele de control i
dispozitivele controlate. Un dispozitiv controlat ofer evenimente care corespund st rii sale
interne. Un dispozitiv de control se aboneaz la un eveniment specific. Imediat ce un nou
eveniment este publicat de c tre un dispozitiv controlat, fiecare dispozitiv de control care s-a
abonat la acest eveniment prime te notific ri asupra evenimentelor.
prezentare: Dispozitivele controlate ofer o interfa de prezentare, de ex. pentru scopuri de
mentenan , care permite efectuarea unor cereri de stare a dispozitivului.
Proiectul SIRENA a fost finalizat in septembrie 2005. Proiectul Service-Oriented Device and
Delivery Architecture (SODA) a continuat cercetarea i dezvoltarea n acela i domeniu.
SIRENA prezint mai multe similarit i cu framework-ul TiCS: dispozitivele nglobate, care pot fi
de asemenea AP-uri n cadrul automatiz rilor industriale sunt interconectate folosind servicii web;
SIRENA Framework Enhancements ofer instrumente pentru a integra dispozitivele n re elele
bazate pe SIRENA, aspect comparabil cu nivelul de suport al framework-ului TiCS; serviciile web
sunt procesate direct pe dispozitivele nglobate, aspect permis de asemenea de motorul SOAP4PLC.
Cu toate acestea, realizarea concret a celor dou framework-uri difer . SIRENA folose te doar un
set restric ionat de protocoale de servicii web (a a numitul Devices Profile for Web Services), n
vreme ce framework-ul TiCS permite utilizarea ntregii stive de protocoale de servicii web. Chiar
dac SIRENA vizeaz domeniul automatiz rilor industriale, acesta nu ofer func ionalit i pentru a
gestiona constrngerile de timp (mai ales constrngeri care apar n cazul aplica iilor de timp real) i
func ionalit i pentru a compune mai multe servicii web n cadrul unui proces. n final, SIRENA
prezint doar un model conceptual pentru integrarea dispozitivelor nglobate. Nu exist alt
implementare a prototipului n afar de existen a stivei DPWS.
Gilart-Iglesias [Gilart-Iglesias V., 2006a] a introdus protocolul Industrial Machinery Normalization
Process (IMNP). Acesta define te un model de serviciu pentru dispozitivele industriale al c rui
obiectiv principal este de a realiza o abstractizare a acestor dispozitive. Acest proces de normalizare
este compus din trei pa i [Gilart-Iglesias V., 2006b]:
normalizare fizic : pasul de normalizare fizic echipeaz un dispozitiv industrial cu
capabilit i de comunicare i func ionalit i de calcul prin utilizarea unor dispozitive integrate
specializate.
normalizare middleware: n pasul de normalizare middleware, este implementat un container
de serviciu de baz . Acesta poate fi folosit pentru a implementa i invoca servicii pe ma inile
industriale. n acest scop, dispozitivul nglobat implementeaz o stiv complet de protocoale
de servicii web pentru a permite rularea i invocarea de servicii web.
normalizarea serviciilor: Pasul de normalizare a serviciilor web define te toate serviciile
necesare pentru a expune func ionalitatea echipamentului industrial. Gilart-Iglesias et al. fac
distinc ia ntre produc ie, management i serviciile de utilitate. Un serviciu de produc ie
expune func ionalitatea principal a dispozitivului industrial, un serviciu de management
permite monitorizarea dispozitivului, n timp ce serviciile de utilitate sunt folosite pentru a
accesa elemente de execu ie i senzori.
14
Dup realizarea cu succes a IMNP-ului, un dispozitiv arbitrar industrial poate fi accesat

direct de c tre nivelul de business folosind servicii [Gilart-Iglesias V., 2007].
Uniunea European a sus inut proiectul Service-Oriented Cross-Layer Infrastructure for Distributed
Smart Embedded Devices (SOCRADES) care este bazat pe principiul de automatizare prin
colaborare i vizeaz trei obiective principale [***SOCRADES, 2007], [Karnouskos S., 2007]:
defini ia unei arhitecturi pentru o infrastructur de comunica ii de servicii web n cadrul
ntreprinderilor industriale;
descrierea serviciilor web printr-o semantic similar celei utilizate n cazul arhitecturilor
bazate pe agen i, pentru a simplifica procesul de compunere a serviciilor;
investigarea existen ei i dezvoltarea unor noi protocoale de comunica ii f
fir pentru
interconectarea dispozitivelor nglobate.
SOCRADES mparte ntreprinderea industrial n nivelul de dispozitive, nivelul de compunere,
nivelul middleware i nivelul de aplica ii [Karnouskos S., 2008]. Nivelul de dispozitive con ine
dispozitive nglobate, capabile s furnizeze servicii web. Deoarece SOCRADES folose te rezultatele
ob inute n cadrul proiectului SIRENA, aceste dispozitive folosesc DPWS pentru a expune serviciile
web la nivelele cele mai nalte. Nivelul de compunere combin mai multe dispozitive integrate
pentru a oferi func ionalit i suplimentare (aspect asigurat tot prin intermediul DPWS). Nivelul
middleware realizeaz integrarea nivelului de dispozitive i al celui de compunere cu nivelul de
aplica ie. Nivelul de aplica ie corespunde nivelului de business dintr-o ntreprindere industrial
tradi ional .
Nivelul de dispozitive de la proiectul SOCRADES prezint similitudini cu nivelul de fabrica ie din
cadrul arhitecturii TiCS ntruct nivelul de compunere i cel de middleware SOCRADES ofer
func ionalit i similare nivelelor de timp real de infrastructur i de serviciu din cadrul arhitecturii
TiCS. Pe de alt parte, SOCRADES nu ia deloc n calcul o cerin cheie a automatiz rilor industriale:
procesarea n timp real. Pn n prezent SOCRADES nu are o implementare prototip, o dovad sau o
evaluare a conceptului.
Kalogeras [Kalogeras A. P., 2006] introduce o arhitectur de sistem bazat pe servicii web pentru
integrarea pe vertical n cadrul ntreprinderilor industriale. Aceast arhitectur nu men ioneaz
cerin ele de timp real de la nivelul de fabrica ie precum i suport pentru inginerii de automatizare.
Delamer [Delamer I. N., 2007] examineaz utilizarea arhitecturilor orientate pe evenimente i a
acelora orientate pe servicii la nivelul de dispozitive. n plus sunt investigate serviciile web
semantice, care permit selectarea automat a serviciilor. Cerin ele de sincronizare sunt ignorate
complet i de aceea aceast arhitectur nu poate fi utilizat n cadrul automatiz rilor industriale.
Helander [Helander J., 2005] prezint o metod pentru programarea i controlul sarcinilor distribuite
bazat pe a a numitele modele comportamentale. Un model comportamental este definit de o
aplica ie i reprezint caracteristicile sale temporale. Acesta este folosit pentru a anticipa i rezerva
automat necesarul de resurse pentru aplica ie. Utilizarea modelelor comportamentale permite
distingerea entit ilor executate i momentul de timp la care acestea sunt executate, adic se
realizeaz o separare a logicii aplica iei de logica temporal . Nu sunt oferite detalii de implementare
chiar dac Helander et al. au sus inut faptul c implementarea prototipului este bazat pe un motor
SOAP n timp real. De asemenea lipse te si o evaluare detaliat a performan elor motorului SOAP.
Proiectul Open Real-Time Linux [Helander J., 2005] investigheaz i determin informa ii referin
de performan pentru distribu ii Linux de timp real de la diferi i furnizori.
15
Exist mai multe limbaje de programare pentru descrierea formal a comportamentului aplica iilor
critice din punctul de vedere al securit ii i al timpului de execu ie, precum Hume [Hammond K.,
2000] i Timber [Black A. P., 2002]. Hume este format din trei nivele: nivelul de expresie, nivelul
de coordonare i nivelul de declara ie. Nivelul de expresie este un limbaj de programare func ional
folosit pentru descrierea proceselor i acesta permite specificarea unui comportament limitat n timp
i spa iu. Nivelul de coordonare este un limbaj de programare cu st ri finite care descrie
interac iunea ntre procese. Nivelul de declara ie este folosit pentru definirea func iilor, valorilor,
expresiilor, etc. Toate cele trei nivele permit deducerea comportamentului temporal al aplica iei.
Timber este un limbaj de programare imperativ, orientat pe obiecte, paralel i pur func ional care
permite analizarea comportamentului de sincronizare al unei aplica ii. Timber ofer diverse expresii
care pot fi folosite pentru a defini propriet i de timp real. Chiar dac ambele limbaje ofer abord ri
interesante pentru a deduce automat comportamentul temporal, acestea nu sunt utilizate pe scar
larg la implementarea arhitecturilor orientate pe servicii, n special a celor bazate pe servicii web.
Filho et al. [Filho F. Sd. L., 2006] au utilizat serviciile web pentru a comunica direct cu dispozitivele
de control (automate programabile). S-a subliniat faptul c tehnologia OPC (OLE for Process
Control) este modul principal de asigurare a accesului de la nivelele superioare ale piramidei de
automatizare c tre dispozitivele de control, dar deoarece tehnologia OPC clasic era dependent de
platform i de tehnologie, nivelul OPC a fost nlocuit i s-au introdus serviciile web, care au fost
dezvoltate folosing Java Native Interface i Apache Axis.
n [Sasa A., 2008] se subliniaz necesitatea automatiz rii activit ilor realizate de operatori umani.
n acest sens se introduce o arhitectur orientat pe servicii care mbun
te execu ia sarcinilor
realizate de operatori prin automatizarea complet sau par ial a acestora prin intermediul
ontologiilor i al agen ilor. Avantajul abord rii este faptul c aceasta este generic i poate fi aplicat
n orice domeniu industrial. n [Idoughi D., 2010] se introduce o abordare nou bazat pe o
arhitectur orientat pe servicii i pe servicii web, care asigur o interac iune flexibil i transparent
ntre dispozitivele de control i operatorii umani. n plus se subliniaz conceptele cheie ale
serviciilor web, necesare unui sistem complex de supervizare.
n lucrarea [Cucinotta T., 2009] accentul este pus asupra calit ii serviciilor n contextul
comunica iei realizate n timp real. Arhitectura propus permite negocierea calit ii serviciului
solicitat de client i realizeaz ncapsularea temporal a activit ilor individuale. Aceasta permite
realizarea unei analize apriori a comportamentului temporal al fiec rui serviciu, astfel nct s se
evite o interferen nedorit ntre acestea.
Un alt aspect este abordat n lucrarea [Candido G., 2011], unde se prezint paradigma EPS
(Evolvable Production System) care are ca scop identificarea direc iilor i solu iilor pentru designul, operarea, mentenan a i evolu ia infrastructurilor industriale. Lucrarea analizeaz asocierea dintre
paradigmele SOA i EPS, cu scopul de a g si o solu ie arhitectural comun care s sprijine
diferitele faze ale ciclului de via al unui produs. n [Nylund H., 2010] se prezint o alt utilitate a
conceptului SOA, i anume n modelarea i simularea sistemelor de fabrica ie pentru sporirea
eficien ei oper rii acestor sisteme. Miniaturizarea continu permite translatarea inteligen ei nspre
nivelul dispozitivelor, favoriznd astfel adoptarea paradigmei SOA n domeniul dispozitivelor
ncorporate [Smit H., 2006].
16
1.6.3 Colaborarea business-to-business

Conform [Touzi J., 2009] integrarea partenerilor industriali depinde profund de capacitatea acestora
de a folosi o arhitectur colaborativ cu scopul de a interac iona eficient. n vederea mbun irii
acestei integr ri, partenerii colabor rii trebuie s respecte conceptul SOA [Grbea A., 2010 a)]. O
astfel de arhitectur de colaborare poate fi proiectat conform unei arhitecturi orientate pe modele
(model driven architecture MDA). Metodologia MDA prezentat n articol rezolv problema
distan ei dintre nivelul analistului de domeniu (modelul de proces de colaborare BPMN) i nivelul
dezvoltatorului IT (model de colaborare SOA).
[Decker G., 2009] prezint serviciile interactive ca fiind componenta esen ial n integrarea
proceselor de domeniu la diferi i parteneri de afaceri prin intermediul schimbului de mesaje
electronice. Pentru a oferi integrarea perfect a acestor servicii, mesajele schimbate, precum i
dependen ele acestora trebuie s fie corect definite. Coregrafiile de servicii sunt un mijloc de a
descrie conversa iile permise.
Un alt proiect orientat c tre mediul industrial a fost proiectul GRIA (Grid Resources for Industrial
Application), a c rui middleware bazat pe servicii web a fost dezvoltat pentru a satisface necesit ile
de securitate i de cooperare business-to-business ale industriei [Surridge M., 2005].
Complexitatea sistemelor software a crescut rapid odat cu dezvoltarea unor noi tehnologii software.
n acest context tehnologiile de integrare nu se pot adapta la cre terea sus inut a sistemelor de
informa ie din cadrul ntreprinderilor. Folosind paradigma SOA, ns , diferite unelte de dezvoltare
pot colabora pentru a realiza integrarea [He X., 2009].
1.7 CONCLUZII
n acest capitol s-a realizat o prezentare sintetizat n ceea ce prive te stadiul actual al cercet rii n
domeniul arhitecturilor orientate pe servicii (SOA).
n prima parte a capitolului s-au prezentat no iunile de baz ale paradigmei SOA precum i istoria
apari iei acestei arhitecturi software. Conceptul de baz al acestei arhitecturi este serviciul. Acesta
este format din dou aspecte fundamentale, i anume: implementarea i interfa a serviciului, care
trebuie s fie complet separate. Avantajul separ rii este faptul c n acest fel utilizatorii sunt
preocupa i doar de contractul de interfa al serviciului i nu trebuie s acorde aten ie modului de
implementare. Propriet ile cheie ale unor servicii corect definite sunt: interdependen a limitat ,
modularitatea, granularitatea i ncapsularea.
n continuare a fost prezentat paradigma se te conecteaz execut , care este un concept SOA
fundamental i care permite g sirea serviciilor de c tre consumatori. S-au men ionat pe scurt
serviciile web, care n prezent reprezint modalitatea cea mai des utilizat n construirea unei
arhitecturi orientate pe servicii (detalii referitoare la serviciile web vor fi introduse n capitolul 5).
ntr-un mediu SOA pot fi definite o serie de nivele semantice: sistemele opera ionale, serviciile,
procesele de domeniu (compunerea serviciilor) i canalele pentru accesarea serviciilor de baz . Pe
lng aceste nivele se pot identifica i o serie de cadre n interiorul arhitecturii stratificate SOA:
guvernan a SOA i management al ciclului de via , infrastructura i managementul SOA i
conectivitatea serviciilor.
Un aspect cheie al aplic rii paradigmei SOA n practic l reprezint securitatea serviciilor.
Elementele esen iale n acest context sunt: confiden ialitatea, integritatea i disponibilitatea (triada
17
CIA). Deoarece SOA se bazeaz pe standarde, este nevoie ca aceste standarde (XML, SOAP, UDDI,
WSDL) s aplice corect conceptele securiz rii informa iei.
n final s-au descris progresele recente realizate n aplicarea conceptului SOA n industrie.
Cercet rile pot fi mp ite n trei mari direc ii:
telecomunica ii;
produc ie;
colaborarea business-to-business.
Deoarece accentul n cadrul lucr rii este pus asupra nivelului MES al piramidei de automatizare,
unde se realizeaz monitorizarea i controlul produc iei, cea de-a doua direc ie a fost detaliat . Au
fost astfel introduse o serie de proiecte de cercetarea finan ate de Uniunea European care au avut ca
scop aplicarea conceptului SOA direct la nivelul dispozitivelor (SIRENA, SOCRADES) sau la
nivelul ERP al piramidei de automatizare (GRIA). Pe lng acestea, diverse activit i de cercetare au
fost direc ionate c tre utilizarea serviciilor web la nivelul dispozitivelor, fie c acestea sunt automate
programabile sau calculatoare de proces (precum arhitecturile TiCS, UPnP, DSSP). Se dore te astfel
ob inerea unei flexibilit i sporite la nivelul dispozitivelor care s creasc agilitatea i viteza de
implementare a modific rilor n produc ie (de exemplu protocolul IMNP [Gilart-Iglesias V.,
2006a]).
De asemenea, exist o serie de limbaje de programare pentru descrierea formal a comportamentului
aplica iilor critice din punctul de vedere al securit ii i al timpului de execu ie: Timber i Hume.
Acestea nu sunt ns utilizate n mod uzual la implementarea arhitecturilor orientate pe servicii.
Analiznd toate aceste aspecte se poate identifica una din problemele fundamentale ale migr rii
tre o arhitectur orientat pe servicii: integrarea dispozitivelor existente. Direc iile care trebuie
urmate la crearea unei astfel de arhitecturi au fost stabilite n mai multe lucr ri, dar ncorporarea
echipamentelor existente n noile arhitecturi r mne o problem dificil .
Dup cum a fost prezentat n lucrarea [Filho F. Sd. L., 2006], unul din motivele principale de a
utiliza serviciile web direct la nivelul dispozitivelor este acela c OPC-ul clasic a fost foarte rigid i
dependent de platform i tehnologie. Aceste limit ri au fost ns eliminate odat cu apari ia noii
specifica ii OPC UA, care este sus inut de principalele companii n domeniul automatiz rilor
industriale (Siemens, ABB, Schneider, etc.).
Un alt aspect care trebuie abordat l reprezint ntrzierile introduse de utilizarea serviciilor web
direct la nivelul dispozitivelor. n [Cucinotta T., 2009] se realizeaz o analiz a calit ii serviciilor n
contextul comunic rii n timp real. Se evalueaz astfel comportamentul temporal al serviciilor
pentru a evita interferen ele nedorite dintre servicii. Se poate astfel identifica o problem principal
a utiliz rii serviciilor web la nivelul dispozitivelor, i anume apari ia unor ntrzieri nedorite.
n plus, exist o serie de alte framework-uri de servicii (pe lng serviciile web) care pot conduce la
timpi de execu ie superiori, precum arhitectura Apache River, care se bazeaz pe servicii Java
(capitolul 5 va detalia aceste aspecte).
n acest context, unul din scopurile principale ale arhitecturii introduse n aceast lucrare, l
reprezint aplicarea conceptelor SOA pentru a ob ine adaptabilitate, flexibilitate i reutilizabilitate
sporite, dar f
a pierde din performan ele solu iilor clasice bazate pe automate programabile sau
calculatoare de proces.
18
2 PROBLEME DE SATISFACERE A
CONSTRNGERILOR
2.1 INTRODUCERE
2.1.1 No iuni generale
Problemele de satisfacere a constrngerilor reprezint un subdomeniu al inteligen ei artificiale care
are ca obiectiv g sirea unei solu ii, eventual optime, care s satisfac un set de constrngeri i
priorit i [Cristea D., 2007].
Satisfacerea constrngerilor s-a consacrat actualmente ca un domeniu important i de sine st tor n
informatica teoretic i aplicat datorit multitudinii de situa ii din lumea real care genereaz
probleme care impun respectarea simultan a mai multor cerin e. O list a domeniilor care apeleaz
regulat la astfel de probleme include: planificarea automat , configurarea resurselor, design,
diagnosticare, ra ionare temporal i spa ial , etc. [Dechter R., 2003].
O constrngere reprezint o rela ie logic ntre mai multe variabile, unde fiecare variabil are un
domeniu de valori. Astfel, o constrngere restric ioneaz valorile pe care variabilele le pot lua i
con ine informa ii par iale referitoare la variabilele implicate n constrngere [Apt K., 2003].
n general constrngerile prezint urm toarele caracteristici [Marriot K., 1998]:
sunt asociative, ceea ce nseamn c pot fi definite n orice ordine;
sunt declarative, se definesc doar constrngerile care se impun variabilelor, nu i algoritmii de
rezolvare a acestora;
sunt bidirec ionale, ceea ce nseamn c domeniile variabilelor implicate n constrngeri se
restric ioneaz reciproc;
constrngerile sunt de obicei interdependente.
O problem de satisfacere a constrngerilor (Constraint Satisfaction Problems CSP) este n mod
uzual definit printr-o re ea de constrngeri R = {X, D, C} unde:
X reprezint un set de variabile X = {x1,x2,, xn};
D reprezint un set de valori posibile pentru fiecare variabil din mul imea X, i anume D =
{D1, D2,, Dn};
C ={C1, C2, , Cn} reprezint o mul ime finit de constrngeri.
Solu ia unei astfel de probleme const din tuplul v = {v1, v2, ..., vn} care asociaz cte o valoare
fiec rei variabile astfel nct s fie satisf cute toate constrngerile.
n general un sistem CSP este format din dou componente: solver i model [Tack G., 2009].
Modelul este compus din definirea variabilelor i a constrngerilor iar solver-ul preia modelul,
19
2. PROBLEME DE SATISFACERE A CONSTRNGERILOR
rezolv constrngerile i furnizeaz solu iile. Solver-ele sunt sisteme automate de rezolvare care
determin solu iile problemelor modelate prin intermediul re elelor de constrngeri.
Trebuie men ionat faptul c nu se impun condi ii asupra tipului variabilelor i a modului de definire
a constrngerilor. Astfel, variabilele pot fi ntregi, reale, booleene, mul imi, etc., iar constrngerile
pot fi definite fie explicit prin specificarea tuplurilor de valori permise, fie implicit prin specificarea
rela iilor (de ex. x1 > 2) [Rossi F., 2006].
n cazul n care o problem are solu ie atunci ea este denumit consistent , n caz contrar este
denumit inconsistent . n practic , pentru un model se determin fie toate solu iile posibile (de
obicei atunci cnd se caut solu ia optim conform unui anumit criteriu de optimizare) sau o singur
solu ie [Benhamou F., 2007].
Constrngerile pot fi clasificate n felul urm tor n func ie de num rul variabilelor implicate:
unare implic o singur variabil (de ex.: x > 10);
binare implic dou variabile (de ex.: 2x - y < 16);
n-are implic n variabile (unde n > 2).
Majoritatea algoritmilor de satisfacere a constrngerilor fac referire la probleme care utilizeaz
constrngeri unare sau binare. Astfel de probleme sunt denumite CSP binare i pot fi reprezentate
printr-un graf, numit graf de consisten unde variabilele reprezint noduri iar arcurile care leag
nodurile reprezint constrngeri binare.
Constrngerile unare se aplic asupra cte unui singur nod i pot fi satisf cute prin reducerea
domeniului variabilelor n cauz . Aceast metod poart denumirea de consisten a nodurilor (node
consistency). Pentru simplificarea problemelor, constrngerile unare nu sunt reprezentate n cadrul
grafurilor de constrngeri. Un nod are o valoare consistent dac acea valoare satisface toate
constrngerile n care este implicat nodul respectiv.
Orice constrngere n-ar poate fi redus la una unar ceea ce nseamn c orice problem poate fi
redus la o problem CSP binar . Pentru a realiza acest lucru se introduce o variabil suplimentar
care ncapsuleaz toate variabilele originale, domeniul s u fiind egal cu produsul cartezian al
domeniilor variabilelor originale.
n continuare va fi prezentat un exemplu pentru transformarea unei constrngeri n-are ntr-una
unar . Fie constrngerea ternar (figura 2.1):
x + y = z, unde x < y
Fig. 2.1. Transformarea unei constrngeri n-are ntr-o constrngere unar .
20
(3.1)
Domeniile variabilelor implicate sunt: x: [1,2]; y: [3,4]; z: [5,6]. Pentru a transforma constrngerea
(3.1) ntr-o constrngere unar se introduce variabila u care ncapsuleaz cele trei variabile implicate
n constrngere (x, y, z). Domeniul variabilei u va fi egal cu produsul cartezian al domeniilor
variabilelor x, y i z. Astfel u = {(1, 3, 5), (1, 3, 6), (1, 4, 5), (1, 4, 6), (2, 3, 5), (2, 3, 6), (2, 4, 5), (2,
4, 6)} i constrngerea ternar va fi nlocuit cu o constrngere unar asupra variabilei nou
introduse. Pentru ca nodul corespunz tor variabilei u s fie consistent aplic m constrngerea unar i
prin urmare u va avea urm torul domeniu u = {(1,4,5), (2,3,5), (2,4,6)}.
2.1.2 Algoritmi de c utare
Algoritmii de c utare sistematic garanteaz g sirea unei solu ii (n cazul n care aceasta exist ). Un
posibil dezavantaj al abord rii bazate pe constrngeri este timpul mare de determinare a unei solu ii.
Cei mai simpli i n consecin cei mai utiliza i algoritmi de c utare sistematic pentru solu ionarea
problemelor de satisfacere a constrngerilor sunt Genereaz i Testeaz i Backtracking.
Dup cum sugereaz i numele acestuia, algoritmul Genereaz i Testeaz const din dou etape:
n etapa Genereaz se realizeaz produsul cartezian ntre domeniile tuturor variabilelor
D1xD2 x...Dn, acest lucru conducnd la generarea tuturor combina iilor posibile de valori;
n etapa Testeaz se ia fiecare combina ie de valori i se verific dac satisface toate
constrngerile problemei. Solu ia problemei este reprezentat de prima combina ie de valori
care satisface toate constrngerile problemei.
Ineficien a acestui algoritm const n faptul c restric iile impuse de constrngeri nu sunt luate n
calcul n momentul gener rii tuturor combina iilor posibile de valori i de aceea sunt generate multe
combina ii eronate de valori, care sunt apoi eliminate n faza de testare.
Algoritmul Backtracking atribuie succesiv valori unui subgrup al variabilelor re elei i verific dac
acele valori reprezint o solu ie par ial sau nu (dac acele valori satisfac toate constrngerile n care
sunt implicate variabilele c rora le-au fost asociate valori). Dac solu ia par ial este corect , se
ncearc extinderea solu iei par iale prin asocierea unei valori unei variabile neinstan iate pn la
acel moment; n caz contrar se va asocia ultimei variabile instan iate urm toarea valoare din
domeniul acesteia i se reia testarea solu iei par iale. Aceast metod este superioar metodei
descrise anterior, deoarece n faza de testare sunt excluse subspa ii mari din spa iul solu iilor
problemei.
Totu i algoritmul backtracking prezint o serie de dezavantaje:
revenire repetat la ultima variant corect n urma unor e ecuri succesive. Acest dezavantaj
apare att datorit inconsisten ei nodurilor ct i a inconsisten ei arcelor grafului de
consisten al problemei CSP;
realizarea de efort redundant (un conflict, r mas valabil, nu se detecteaz n c ut rile viitoare);
conflictele sunt detectate doar n momentul apari iei i nu sunt anticipate;
timpul de execu ie cre te exponen ial cu complexitatea modelului, aspect care limiteaz
utilitatea metodei n cazul problemelor complexe (cu num r mare i foarte mare de variabile).
De aceea, de-a lungul timpului, s-a ncercat mbun irea algoritmului, elementele cheie fiind cele
dou faze ale algoritmului: pasul de avansare/naintare (schemele privire-nainte) i pasul de
ntoarcere (schemele privire-napoi). Cele mai utilizate extensii ale algoritmului sunt:
backmarking care reduce num rul de verific ri a consisten ei;
backjumping care mbun
te alegerea variabilei pentru pasul de ntoarcere;
21
forward-checking care aplic tehnica de consisten a arcelor ntre valoarea actual a ultimei
variabile instan iate i domeniile variabilelor nc neinstan iate. Astfel se verific
constrngerile care implic variabila instan iat la momentul actual i variabilele neinstan iate
care sunt legate prin arcuri de aceasta i prin urmare se reduc domeniile variabilelor
neinstan iate.
O alt posibilitate de a cre te eficien a c ut rii este reprezentat de a a-numitele euristici de
ordonare a variabilelor, care sunt folosite pentru selectarea variabilelor care urmeaz a fi
instan iate. Astfel, s-au introdus o serie de tehnici care nva prin generarea unor constrngeri
suplimentare pe parcursul c ut rii. Prin urmare aceste euristici mbun esc pasul de alegere a
variabilei urm toare n algoritmul backtracking.
2.1.3 Tehnici de consisten
Spre deosebire de metodele de c utare, care sunt nedeterministe, tehnicile de consisten sunt
deterministe. Obiectivul acestor tehnici este de a elimina ct mai multe arcuri din graful de
consisten stabilind ntr-un fel sau altul c acestea sunt inconsistente.
Cele mai utilizate tehnici de consisten sunt:
consisten a de nod (tehnic cunoscut n literatura de specialitate sub denumirea node
consistency);
consisten a de arc (arc consistency);
consisten a de drum (path consistency).
Consisten a de nod este cea mai simpl tehnic i const n reducerea domeniului fiec rei variabile
astfel nct s fie satisf cute toate constrngerile unare care implic variabila n cauz .
Consisten a de arc const n reducerea domeniilor variabilelor astfel nct s fie satisf cute toate
constrngerile binare. Din punct de vedere matematic arcul (Vi, Vj) adic arcul care pleac din
nodul Vi i ajunge n nodul Vj este consistent dac pentru fiecare valoare x din domeniul Vi exist
o valoare y n domeniul Vj astfel nct Vi = x i Vj = y satisfac constrngerea binar dintre Vi i Vj.
n acest sens n figura 2.2 este prezentat un exemplu.
Fig. 2.2. Consisten de arc.
Dup cum se poate observa pentru valoarea 1 a variabilei x exist valoarea 2 n domeniul variabilei
y, care satisface constrngerea x
y iar pentru valoarea 2 a variabilei x exist valoarea 1 n
domeniul variabilei y care satisface constrngerea x y. Asigurnd consisten a de arc de la Vi la Vj,
domeniul de valori al lui Vi va fi redus: se terg acele valori pentru care nu exist valori n domeniul
lui Vj astfel nct constrngerea s fie satisf cut .
Totu i dac un arc este consistent nu nseamn neap rat c exist i o solu ie. n acest sens este
prezentat exemplul din figura 2.3. Dup cum se poate observa toate arcurile sunt consistente dar nu
exist nici o solu ie care s satisfac simultan toate cele trei constrngeri.
22
Fig. 2.3 Consisten a de arc nu garanteaz existen a unei solu ii.
O generalizare a celor dou tipuri de consisten descrise anterior este reprezentat de conceptul de
k-consisten . Un graf este k-consistent dac pentru orice grup de k variabile i pentru orice set de
valori asociate unui subgrup de k-1 variabile exist o valoare n domeniul variabilei k pentru care
sunt satisf cute toate constrngerile care implic cele k variabile. Se spune c un graf este puternic
k-consistent dac este i-consistent pentru toate valorile i cel mult egale cu k [Tack G., 2009].
n acest caz consisten a de nod este echivalent cu puternic 1-consisten a, consisten a de arc este
echivalent cu puternic 2-consiten a iar puternic 3-consisten a este echivalent cu consisten a de
drum. De obicei nu se aplic k-consisten cu k > 3 deoarece necesit prea mult timp pentru
asigurarea consisten ei.
Nu este suficient asigurarea consisten ei arcelor la g sirea unei solu ii CSP i n consecin
necesitatea aplic rii unei c ut ri de tip backtracking nu este eliminat .
Ca urmare a aplic rii tehnicilor de consisten se va ob ine una din urm toarele trei situa ii:
domeniul uneia sau mai multor variabile devine vid, ceea ce nseamn c problema este supraconstrns i nu are solu ie;
domeniul fiec rei variabile con ine o singur valoare, ceea ce nseamn c setul acestor valori
reprezint o solu ie a problemei;
domeniile variabilelor con in valori multiple, ceea ce nseamn c nu se poate determina dac
problema are sau nu solu ie i prin urmare trebuie aplicat o metod de c utare a unei solu ii.
Exist totu i o excep ie care asigur faptul c solu ia unei probleme CSP poate fi determinat i f
aplicarea tehnicii de backtracking. Astfel, dac o problem CSP binar are o structur de arbore (cu
alte cuvinte graful de consisten este de fapt un arbore) i condi iile de consisten a nodurilor i
arcelor sunt satisf cute, atunci o solu ie a problemei se poate determina f
backtracking [Van
Hentenryck P., 1992].
2.1.4 Propagarea constrngerilor
Un alt concept aplicat n problemele de satisfacere a constrngerilor este propagarea
constrngerilor, care a ap rut sub diferite denumiri in func ie de momentul public rii i de autori.
Printre aceste denumiri se g sesc: relaxare, algoritmi de filtrare, inferen a constrngerilor, reguli de
iterare, simplificarea algoritmilor, for area consisten ei locale etc. [Zweben M., 1994].
Propagarea constrngerilor reprezint practic orice abordare care duce la interzicerea explicit a
valorilor sau a combina iilor de valori ale unor variabile ale unei probleme pe motivul c n caz
contrar un subset de constrngeri care apar in problemei nu pot fi satisf cute. Practic, aceast tehnic
reprezint o alt modalitate de a reduce spa iul de combina ii care va fi explorat printr-un mecanism
de c utare.
23
n ultimii 30 de ani, comunitatea tiin ific a depus un efort mare att n formalizarea i
caracterizarea acestui concept omniprezent, ct i n formularea unor algoritmi pentru propagarea
constrngerilor. Aceast formalizare poate fi prezentat pe dou linii principale:
consisten ele locale;
reguli de itera ie.
Consisten ele locale definesc propriet i pe care problema de constrngeri trebuie s le ndeplineasc
dup ce s-a finalizat etapa de propagare a constrngerilor. n acest fel, comportamentul opera ional,
este l sat complet deschis, singura cerin fiind s se satisfac proprietatea dat la ie ire. Pe de alt
parte se define te abordarea bazat pe reguli de itera ie, pe propriet i ale procesului de propagare,
precum i propriet i ale tipului/ordinului opera iilor de reducere aplicate problemei.
Ca i concluzie, prin propagarea constrngerilor, se realizeaz verific ri de constrngeri i cu ct se
realizeaz mai multe verific ri de constrngeri la fiecare nod, cu att arborele de c utare devine mai
mic (cu mai pu ine noduri), dar costul total (timpul) poate fi mai mare deoarece pentru fiecare nod se
efectueaz mai multe c ut ri.
n figura 2.4 se prezint comportamentul general al unei probleme de satisfacere a constrngerilor.
Ini ial este construit modelul problemei (se definesc variabilele, domeniile acestora i
constrngerile), dup care se ncepe c utarea solu iilor modelului. Propagarea constrngerilor nu
permite determinarea tuturor consecin elor care apar ca urmare a aplic rii constrngerilor, adic nu
se pot detecta toate inconsisten ele. De aceea trebuie aplicat o strategie de c utare pentru a
determina dac ntr-adev r modelul are o solu ie. Deciziile care se iau la momentul c ut rii unei
solu ii formeaz a a numita euristic de c utare. De obicei se folose te un arbore de c utare iar
utarea este format din dou tipuri de ac iuni: avansarea n arbore (se decide care variabil i care
valoare a acesteia va fi testat ) i revenirea (n general modul de aplicare a strategiei de
backtracking). Deciziile luate la acest pas reprezint constrngeri suplimentare. Practic, n timpul
ut rii se aplic tehnica de propagare a constrngerilor asupra constrngerilor originale i asupra
noilor constrngeri ad ugate la aplicarea strategiei de c utare. Cnd se detecteaz o contradic ie,
adic se determin faptul c valorile actuale ale variabilelor nu satisfac constrngerile, se aplic
strategia de backtracking pentru a reveni la o stare anterioar lipsit de contradic ii. Prin urmare,
dup cum este prezentat i n figura 2.4, definirea problemei, propagarea constrngerilor i strategia
de c utare mpreun cu strategia de backtracking sunt componente separate ntr-o problem CSP.
Fig. 2.4. Comportamentul unei probleme de satisfacere a constrngerilor [Baptiste P., 2001].
24
Exist numeroase publica ii care descriu n detaliu algoritmii prezenta i n acest subcapitol [Marriot
K., 1998], [Benhamou F., 2007], ace tia au fost prezenta i datorit faptului c sunt implementa i i
utiliza i de solverii CSP (de ex. Choco, JaCoP) pentru a oferi o solu ie a modelelor CSP. Accentul
va fi pus n continuare pe construirea modelelor CSP i pe solver-ele care vor fi folosite pentru
solu ionarea modelelor.
2.2 NO IUNI GENERALE ALE PROBLEMELOR DE SCHEDULING
2.2.1 Introducere
Baker [Baker K. R., 1974] a definit o problem de scheduling ca fiind o problem de alocare a unor
resurse limitate anumitor activit i de-a lungul unui interval de timp. n contextul resurselor limitate
trebuie s se decid care activit i s se execute la fiecare moment de timp astfel nct s se
minimizeze un cost total. nc de la nceput trebuie f cut distinc ia ntre termenii de planificare i
de scheduling: planificarea realizeaz doar alocarea unor resurse anumitor activit i, n timp ce prin
scheduling se n elege i determinarea exact a momentelor de timp la care se execut activit ile
[Pinedo M. L., 2009], [Timpe C., 2002]. De-a lungul lucr rii, accentul va fi pus pe probleme de tip
scheduling, deoarece scopul este de a determina un orar de lucru precis pentru aplica iile adresate.
Din punctul de vedere al tipurilor de resurse se poate face distinc ia ntre [Le Pape C., 1996]:
scheduling disjunctiv: toate resursele au capacitate unitar (aceste resurse sunt n general
numite ma ini);
scheduling cumulativ: resursele permit execu ia simultan a mai multor activit i n paralel
(resursele au o capacitate 1).
Din punctul de vedere al activit ilor se poate face distinc ia ntre [Baptiste P., 2001]:
scheduling non-preemptiv: activit ile se execut f ntrerupere dup nceperea lor;
scheduling preemptiv: activit ile pot fi ntrerupte la orice moment i reluate la un moment
ulterior;
scheduling elastic: activit ile consum o cantitate variabil din resurs de-a lungul timpului.
n plus, se mai face distinc ia ntre probleme de decizie i de optimizare. n cazul problemelor de
decizie scopul este doar de a determina dac exist un orar de lucru care satisface toate
constrngerile iar n cazul problemelor de optimizare scopul este de a minimiza o anumit func ie
obiectiv.
n cadrul lucr rii se vor adresa probleme de scheduling disjunctive i cumulative, non-preemptive
sau elastice i de optimizare, deoarece acestea sunt de obicei ntlnite n aplica iile industriale.
2.2.2 Clasificarea lui Graham
Majoritatea problemelor de scheduling pot fi descrise prin clasificarea lui Graham
[Graham R.
E., 1979]. Proprietatea descrie ma inile disponibile i este format din doi parametrii: 1 (1 o
singur ma in , P ma inile problemei sunt identice, R ma inile sunt necorelate adic trebuie
specificat timpul de procesare al fiec rei activit i pentru fiecare ma in , etc.) i 2 (num rul de
ma ini). Pentru multe probleme se folose te termenul de job: acesta reprezint un set de activit i
ordonate {Ai,1, , Ai,n} precum i ma ina ui,j pe care trebuie executat fiecare activitate Ai,j
[Baptiste P., 1995]. Se pot distinge probleme de tip: job-shop [Baptiste P., 2006] (se precizeaz
constrngeri de preceden ntre toate activit ile job-ului), flow-shop (caz special de job-shop la
25
care fiecare job are aceea i ordine a activit ilor) i open-shop (nu exist constrngeri de preceden
dar activit ile aceluia i job nu pot fi executate simultan).
Proprietatea precizeaz caracteristicile job-ului. Termenul job este folosit cnd activit ile pot fi
rearanjate ntr-un subset, job-urile putnd fi i ele la rndul lor rela ionate prin constrngeri de
preceden . Natura grafului de preceden indus de aceste constrngeri este indicat prin unul din
cuvintele chain (lan ), tree (arbore), prec, ceea ce nseamn c graful de preceden este un lan , un
arbore sau un graf nestructurat.
Proprietatea
reprezint criteriul de optimalitate. n cele ce urmeaz Ci indic momentul de
finalizare al unui job Ji. Cele mai multe dintre criteriile de scheduling clasice specific o dat
preferen ial i de finalizare a job-ului sau un termen limit fix de finalizare di ( i reprezint o
preferin n timp ce di reprezint o constrngere care trebuie obligatoriu ndeplinit ). ntrzierea Ti a
job-ului Ji este definit ca fiind Ti = max(0, Ci - i). Nota ia Ui este folosit pentru a indica o
penalizare unitar pentru fiecare job ntrziat, adic Ui este egal cu 0 dac C i
i i 1 altfel.
n continuare se define te criteriul de optimizare F care este formulat fie ca o sum , fie ca un maxim
(pentru detalierea criteriului se poate asocia o pondere wi fiec rui job). Se disting urm toarele
criterii:
Makespan: F = Cmax = max Ci;
Timpul total ponderat: F
wi C i ;
ntrziere maxim : F = Tmax = max Ti;
ntrziere maxim ponderat : F
wi Ti ;
Num r total ponderat al job-urilor cu ntrziere: F
wiU i ;
n figura 2.5 sunt reprezentate cteva no iuni fundamentale:
Fig. 2.5. Func ii obiectiv [Baptiste P., 2001].
2.2.3 Modelarea CSP a unei probleme de scheduling

Activit i
Problemele de scheduling non-preemptive pot fi modelate eficient ca probleme CSP. Pentru fiecare
activitate sunt introduse trei variabile: start(Ai), end(Ai) i proc(Ai), care reprezint momentul de
start, momentul de final i respectiv durata de procesare a activit ii Ai [Hendler J., 2006].
Avnd ca date de intrare pentru problema de scheduling pe ri (data de lansare) i pe di (termen limit
de ncheiere a activit ii Ai), [ri, di] reprezint intervalul de timp n care activitatea Ai trebuie
executat . Pe baza acestora, domeniile ini iale ale variabilelor start(Ai) i end(Ai) sunt [ri, lsti] i
respectiv [eeti, di] (lsti i eeti reprezint cel mai ntrziat moment de start i respectiv cel mai recent
moment de ncheiere a activit ii Ai).
26
Durata de procesare a unei activit ii este definit ca fiind diferen a dintre timpul de final i timpul
de start al activit ii: proc(Ai) = end(Ai) start(Ai). pi indic cea mai mic valoare din domeniul
variabilei proc(Ai). Toate datele corespunz toare unei activit i sunt sintetizate n figura 2.6.
Culoarea gri deschis este folosit pentru a indica intervalul de timp posibil al unei activit i [ri, di],
iar culoarea gri nchis este folosit pentru a reprezenta intervalul de timp efectiv de procesare a unei
activit i.
Fig. 2.6. Datele corespunz toare unei activit i [Sawik T., 2011].
Rela iile temporale

Rela iile temporale dintre activit i pot fi exprimate prin constrngeri liniare care implic variabilele
start i end ale activit ilor. De exemplu, o constrngere de preceden ntre dou activit i Ai i A j
este modelat printr-o constrngere liniar end(Ai)
start(Aj). Astfel de constrngeri pot fi
propagate cu u urin cu ajutorul unui algoritm standard de consisten de arc [Bucker P., 2002].
Constrngerile de resurse
Constrngerile de resurse modeleaz faptul c activit ile necesit o anumit cantitate de resurse dea lungul execu iei lor. Fiind dat o activitate Ai i o resurs R a c rei capacitate este cap(R),
cap(Ai,R) este variabila care reprezint cantitatea de resurs R necesar activit ii Ai. n cazul
activit ilor elastice, variabila cap(Ai,R) nu este semnificativ i de aceea trebuie introdus o
variabil E(Ai,R) care reprezint energia necesar activit ii Ai de la resursa R. n cazul activit ilor
non-elastice condi ia este E(Ai,R) = cap(Ai,R)proc(Ai). Pentru a reprezenta un orar de lucru, este
nevoie de o variabil E(Ai,t,R) care indic num rul de unit i din resursa R folosite de activitatea Ai
la momentul de timp t. Trebuie impus constrngerea care exprim faptul c activit ilor li se aloc
suficiente resurse astfel nct cerin a de energie s fie satisf cut :
E ( Ai , R)
E ( Ai , t , R)
(3.2)
De asemenea constrngerea de resurs trebuie respectat la orice moment de timp t:

n
E ( Ai , t , R)
cap( R)
(3.3)
i 1
Extensii ale modelului

De i modelul descris mai sus acoper o clas larg de probleme ntlnite n lumea real , n
continuare vor fi introduse dou posibile extensii ale acestora care se reg sesc frecvent n cazul
aplica iilor industriale, i anume: resurse alternative i timp i cost de tranzi ie.
27
n anumite situa ii de scheduling o activitate Ai poate fi programat pe orice resurs dintr-un set de
resurse S (S este setul de resurse alternative ale activit ii Ai). Pentru fiecare set de resurse alternative
este introdus o variabil altern(Ai). Pentru a simplifica nota ia, se presupune c resursele sunt
numerotate de la 1 la m i c altern(Ai) indic variabila a c rei valoare reprezint indexul resursei pe
care este executat Ai. Frecvent, timpul de procesare al unei activit i depinde de resursa pe care este
executat acea activitate. Un alt tip comun de constrngeri adreseaz interdependen a aloc rii de
resurse, putndu-se astfel formula constrngeri de genul dac A1 este programat pe resursa R1
atunci A3 trebuie s fie programat pe resursa R2.
Un aspect important n automatiz rile industriale l reprezint scheduling-ul cu set ri dependente de
secven ale aplica iilor [Allahverdi A., 1999]. n acest sens accentul trebuie pus mai ales asupra
timpului i al costului de tranzi ie.
Timpul de tranzi ie dintre dou activit i A1 i A2 este definit ca fiind intervalul de timp setup(A1, A2)
care trebuie s se scurg ntre momentul de final al activit ii A1 i momentul de start al activit ii
A2, atunci cnd A1 o precede pe A2. Costul de tranzi ie setupCost(A1, A2) poate fi de asemenea
asociat cu tranzi ia dintre A1 i A2. Astfel obiectivul unei probleme de scheduling poate fi de
exemplu de a minimiza suma costurilor de tranzi ie.
Considera iile referitoare la tranzi ii (cost i timp) pot fi combinate cu resursele alternative. n acest
caz se consider faptul c doi parametrii sunt asocia i cu fiecare tuplu (Ai, Aj, Mu): timpul de tranzi ie
setup(Ai, Aj, Mu) i costul de tranzi ie setupCost(Ai, Aj, Mu) ntre activit ile Ai i A j dac Ai i A j sunt
programate secven ial pe aceea i ma in Mu. ntr-un astfel de caz se poate exprima inegalitatea:
start ( A uj ) end ( Aiu ) setup( Ai , A j , M u ) . De asemenea se poate defini un timp de start setup(, Ai,
Mu) (cu costul de start corespunz tor setupCost(, Ai, Mu)) care trebuie s se scurg nainte de
momentul de start a lui Ai, cnd Ai este prima activitate pe ma ina M u i, similar, un timp de oprire
setup(Ai, , Mu) (cu costul corespunz tor de oprire setupCost(Ai, , Mu)) care trebuie s se scurg
dup momentul de final a lui Ai, cnd Ai este ultima activitate pe Mu.
Func ia obiectiv
Pentru a modela func ia obiectiv, se ad ug o variabil criteriu n cadrul modelului, care este
constrns s fie egal cu valoarea func iei obiectiv. Pentru majoritatea problemelor, func ia obiectiv
este o func ie dependent de variabilele de final ale activit ilor:
criteriu
F (end ( A1 ),..., end ( An ))
(3.4)
Dup ce sunt create toate constrngerile problemei, o tehnic obi nuit de a c uta solu ia optim este
aceea de a rezolva variante succesive de decizie ale problemei. Pot fi considerate mai multe strategii
de minimizare a valorii criteriu. Un mod de a itera printre posibilele valori ale variabilei este fie de
la limita inferioar la limita superioar a domeniului variabilei pn cnd este g sit o solu ie, sau
invers de la limita superioar spre limita inferioar stabilind de fiecare dat dac mai exist o solu ie.
O alt cale este aceaa de a folosi un algoritm special pentru variabila criteriu, la nceputul c ruia se
calculeaz limita superioara ini ial ls(criteriu) i limita inferioar ini ial li(criteriu) a variabilei:
1. Se seteaz D = [(li(criteriu) + ls(criteriu))/2].
2. Se seteaz constrngerea ca variabila criteriu s fie cel mult egal cu D. Apoi este rezolvat
problema CSP rezultat , adic se determin o solu ie cu criteriu D sau se dovede te c nu
28
exist o astfel de solu ie. Dac se g se te o solu ie atunci limitei ls(criteriu)) i se asociaz
valoarea g sit pentru variabila criteriu; altfel limitei li(criteriu) i se asociaz valoarea D+1.
3. Se itereaz pa ii 1 i 2 pn cnd ls(criteriu)) = li(criteriu).
2.3 SOLVERE CSP
Al turi de model (care introduce variabilele, domeniile acestora precum i constrngerile), solver-ul
reprezint cel mai important concept n paradigma CSP. Acesta permite determinarea unei solu ii, a
tuturor solu iilor sau a solu iei optime pe baza unei anumite func ii de cost sau a unui criteriu.
O ramur important a domeniului de satisfacere a constrngerilor este reprezentat de programarea
liniar [Williams H.P., 1999], care este practic o metod matematic de determinare a solu iei
optime (pe baza unei func ii de cost). O caracteristic esen ial a acestor tipuri de probleme o
reprezint liniaritatea constrngerilor (n cazul modelelor CSP generale constrngerile pot fi i
neliniare). Programarea liniar este n general mp it n trei categorii [Darby-Dowman K., 2002]:
programare liniar cu ntregi (ILP integer linear programming): toate variabilele sunt de tip
ntreg;
programare cu ntregi binari (BIP binary integer programming): toate variabilele sunt de tip
boolean;
programare mixt cu ntregi (MIP mixed integer programming): variabilele pot fi att ntregi
ct i booleene.
Liniaritatea constrngerilor permite implementarea unor tehnici specializate de c utare a solu iilor
care n general conduc la solu ii mai rapide. n continuare vor fi prezentate pe scurt trei solvere care
au fost considerate i utilizate pentru lucrare:
JaCop: solver Java CSP general;
Choco: solver Java CSP general;
JLPI: solver Java MIP.
2.3.1 Solver-ul JaCoP
Dezvoltarea solver-ului JaCoP a nceput n 2001, este implementat n Java i este furnizat sub forma
unei biblioteci Java open source [***JaCoP, 2010]. Aceast bibliotec a fost dezvoltat datorit
lipsei instrumentelor de constrngere la momentul respectiv, care s fie u or extinse i manipulate. A
fost ales limbajul Java att pentru c ofer modalit i u oare pentru ntre inerea i scrierea codului
ct i pentru c nu apar dificult i de interoperabilitate. Prin natura sa, limbajul Java este portabil i
n consecin JaCoP poate fi folosit cu u urin pe diferite tipuri de ma ini i sisteme de operare. De
asemenea s-a avut n vedere utilizarea API-ului n diferite aplica ii web.
JaCoP a fost mbun it continuu i momentan de ine o colec ie mare de constrngeri globale care
permit o modelare u oar a diferitelor probleme. Acest lucru s-a datorat faptului c obiectivul
principal al solver-ului JaCop a fost acela de a facilita aplicarea paradigmei CSP n domeniul
design-ului electronic automatizat.
2.3.2 Solver-ul Choco
Choco este o bibliotec Java folosit la rezolvarea problemelor bazate pe re ele de constrngeri i la
programarea pe constrngeri [***Choco, 2010]. Este construit pe baza program rii pe evenimente
29
iar implementarea sa a nceput n 1999, prima versiune fiind n limbajul C++. n 2003 Choco a
suferit prima modificare major i a fost implementat n Java pentru o mai bun portabilitate. n
2008 Choco a suferit o a doua modificare major cnd s-a realizat o separare clar ntre partea de
modelare i partea de solver.
n [Benavides D., 2005] s-a realizat o compara ie a celor dou solvere. Astfel s-a determinat c
solver-ul JaCoP este mai rapid dect Choco n cazul problemelor mici i Choco este mai rapid ca
JaCoP n cazul problemelor complexe. Choco ofer o metod simpl care permite ob inerea
num rului de solu ii posibile pentru o anumit problem (Solver.getNbSolutions()) n timp ce
implementarea JaCoP trebuie s g seasc ini ial toate solu iile, abia apoi putnd furniza num rul
acestora. De asemenea s-a determinat faptul c Choco utilizeaz mai multe resurse de sistem fa de
JaCoP, de i nu exist o diferen remarcabil ntre cele dou solvere din acest punct de vedere.
Dup o analiz atent a celor dou API-uri s-a ales utilizarea solver-ului Choco deoarece ofer o
documenta ie mai bun i codul poate fi n eles mai u or i astfel i ntre inut mai u or. De asemenea
s-a inut cont de faptul c API-ul s u con ine mai multe constrngeri dect solver-ul JaCoP care
ofer o colec ie minimal de constrngeri. O caracteristic important a solver-lui Choco este
posibilitatea de a defini o variabil obiectiv care este utilizat la determinarea celei mai bune solu ii
a problemei. Un alt element cheie este faptul c Choco permite utilizarea tipului de variabil
TaskVariable care este foarte folositor n cazul problemelor de scheduling care au fost dezvoltate n
cadrul lucr rii.
2.3.3 Solver-ul JLPI
JLPI (Java Linear Programming Interface) este o interfa Java care permite accesul la mai multe
solvere de programare liniar (Linear Programmming LP) i de programare mixt cu variabile
ntregi (Mixed Integer Programming MIP) precum SCIP i SOPLEX [Achterberg T., 2004].
Interfa a a fost creat de Siemens CT C CEE i momentan este disponibil doar pentru utilizatorii
interni Siemens. JLPI este livrat sub forma unei arhive Java (jlpi.jar) mpreun cu DLL-uri
suplimentare (LPI4Java.dll i *Plugin.lpi). JLPI a fost creat ca r spuns la interfa a open source
existent n C++ i anume LP-Interface introdus de Siemens CT T PRO MSO.
Solver-ul SCIP este momentan considerat a fi cel mai evoluat solver n domeniul program rii
liniare. De aceea, n cadrul lucr rii, solver-ul SCIP ( i n consecin biblioteca JLPI) a fost utilizat
pentru implementarea mai multor modele liniare (n special de tip MIP).
2.4 UTILIZAREA PROBLEMELOR DE SATISFACERE A CONSTRNGERILOR N
MEDIUL INDUSTRIAL
Paradigma CSP mpreun cu subcategoriile sale a fost aplicat ntr-o multitudine de probleme
practice. n continuare se va realiza o scurt trecere n revist a acestora precum i a progreselor
recente realizate n domeniul CSP.
O prezentare detaliat a meta-euristicilor utilizate n problemele de scheduling utilizate n industrie
este realizat n [Xhafa F., 2008]. Modelele MIP care se pot aplica pentru diverse tipuri de aplica ii
au fost introduse n [Sawik T., 2011].
Pentru problemele de tip job-shop [Hansmann K. W., 1997], care sunt cunoscute a fi unele dintre
cele mai complicate probleme de combinatoric , s-a introdus recent un algoritm memetic, care
30
reprezint practic un algoritm hibrid i care combin tehnici de c utare global i local [Gao L.,
2011]. Noutatea const n modificarea sistematic a loca iei de c utare pentru a evita solu ii optime
local. n acela i domeniu, s-a introdus o modalitate mai eficient de minimizare a condi iei de
makespan, n condi iile n care ma inile pentru care urmeaz s se stabileasc orarul de lucru nu sunt
disponibile pe ntreaga durat a planific rii [Mati Y. 2010]. Tot pentru minimizarea condi iei de
makespan, n [Zribi N. ., 2008] se introduc att o euristic bazat pe reguli prioritare ct i un
algoritm genetic pentru rezolvarea problemei de secven iere.
n [Lei D., 2011] se prezint cu rezultate promi toare aplicarea unui algoritm genetic pentru o
problem de tip job-shop cu timp de execu ie exponen ial n raport cu complexitatea modelului.
n condi iile n care paradigma CSP a fost aplicat pentru probleme de complexitate tot mai mare i
timpii de c utare au crescut exponen ial, o parte important a activit ilor de cercetare a fost
ndreptat nspre reducerea complexit ii modelelor CSP [Medland A.J., 2011]. O alt metodologie
bazat pe constrngeri, care este aplicat n cazul modelelor complexe a fost introdus n [Edmunds
R., 2011], unde se pot modela si rezolva sisteme largi cu peste 100 de grade de libertate printr-o
combina ie de algoritmi direc i sau de evolu ie. Tehnica poate fi aplicat n diverse domenii: ma ini
industriale, modelare uman , modelare geologic , etc.
Un aspect foarte important n mediul industrial este luarea de decizii n timp-real (n timpul
func ion rii instala iilor). Un sistem de scheduling n timp real a fost introdus n [Frantzen M.,
2011], care a fost aplicat n uzina unui produc tor auto din Suedia. Acest sistem determin orare de
lucru n timp real i transmite sugestii c tre operatorii umani. Modelele sunt robuste i permit o
reconfigurare rapid n cazul n care sistemul modelat se modific .
Un domeniu foarte important pentru aplicarea paradigmei CSP n domeniul industrial este acela al
sistemelor flexibile de fabrica ie (flexibilitatea acestora permite o reconfigurare rapid a produc iei).
Se pot astfel identifica patru tipuri de aplica ii [Stecke K. E., 1985]:
design: determinarea num rului optim de sta ii i unelte, dimensiunea buffer-elor, etc.;
planificare: determinarea componentelor procesate simultan, mp irea sta iilor n grupuri,
determinarea asocierilor dintre opera ii i ma ini;
scheduling: determinarea secven ei optime a componentelor la fabricarea acestora;
control: monitorizarea sistemului pentru a avea certitudinea c termenele limit sunt respectate
i c problemele de fiabilitate sunt gestionate corect.
Un model axat pe monitorizare este prezentat n [Finkelstein L., 2001] n care un set de interog ri
sunt transmise procesului monitorizat pentru a detecta satisfacerea unui el. Aceste interog ri
consum timp de la procesul monitorizat, ceea ce duce la o ntrziere a momentului de timp la care
este ndeplinit condi ia obiectivului. n acest sens este prezentat un model formal pentru aceste
tipuri de probleme, se realizeaz o analiz teoretic a claselor de orare de lucru optime i se
introduce un algoritm pentru construirea unor orare optime de monitorizare.
Intr-una din primele lucr ri publicate n acest domeniu a fost prezentat aplicarea paradigmei CSP
ntr-un sistem de fabrica ie flexibil pentru haine [Tomastik R. N., 1996]. Modelul introdus rezolv o
problem de scheduling prin care se decide cte i care ma ini s fie alocate fiec rei sarcini
(componenta de scheduling i cea de alocare a resurselor sunt strns corelate).
n [Zeballos L. J., 2010 a)], [Zeballos L. J., 2010 b)] se introduc att un model ct i o strategie de
utare pentru planificarea produc iei unei linii flexibile. Modelul ia n considerare o serie de
aspecte esen iale ale liniilor flexibile: num rul uneltelor, durata de via a acestora, capacitatea
31
magaziilor de unelte, planificarea ma inilor i a uneltelor, direc ionarea componentelor, etc. O alt
activitate de cercetare s-a concentrat n special asupra problemei de nc rcare a sta iilor dintr-un
sistem de fabrica ie flexibil [Abazari A.M., 2012]. Lucrarea propune un model matematic liniar
compus att din variabile ntregi ct i din variabile booleene care este apoi rezolvat prin aplicarea
unui algoritm genetic, care conduce la timpi de solu ionare mai mici. n [Sawik T., 2004], se
prezint un model MIP general utilizat pentru a determina simultan solu ii de nc rcare i de
planificare a sta iilor unei linii flexibile (fiecare sta ie este compus din mai multe ma ini paralele).
Un aspect important neglijat n aceast lucrare l reprezint timpii de instalare ai ma inilor (timpul
necesar ca o sta ie s comute de la un tip de opera ie la altul). Aceast problem este adresat n
[Andrs C., 2008], iar modelul MIP introdus anterior n [Sawik T., 2004] a fost extins prin
introducerea unor timpi de instalare dependen i de secven a de execu ie [Ozturk C., 2010]. Lucrarea
[Magnusson P., 2011] n schimb se concentreaz asupra activit ilor de transport dintre sta iile unui
sistem de fabrica ie. Se introduce o metod care identific , creeaz i vizualizeaz aceste activit i
pe baza datelor de intrare furnizate de un program virtual de fabrica ie. O problem axat exclusiv
pe planificarea activit ilor a fost introdus n [zcan U., 2009], scopul fiind acela de a planifica
simultan mai multe linii de asamblare n contextul unor resurse limitate i de a distribui n mod
echilibrat volumul total de lucru.
Numeroase activit i de cercetare s-au concentrat n special asupra modelelor MIP. n [Mosadegh
H., 2012] se adreseaz probleme de planificare i secven iere, scopul final fiind acela de minimiza
cantitatea total de lucru. [Unlu Y., 2010] evalueaz patru formul ri diferite ale modelelor MIP cu
aplicabilitate n problemele de scheduling cu ma ini paralele. ntr-o alt lucrare, [Dolgui A., 2012],
se descrie utilizarea unui model MIP n cazul unei instala ii industriale multi-ax (multi- pindlu).
Modelul determin pindlul care trebuie utilizat pentru o anumit opera ie la un anumit moment dat,
scopul fiind acela de a minimiza costul total. Un alt model este prezentat n [Westerlund J., 2007],
unde este adresat n special problema de depozitare a produselor ntre sta iile unei linii de produc ie
complexe. Modelul propus este o combina ie ntre modele cu timp continuu i timp discret i poate
gestiona att probleme cu durata de lucru scurt ct i modele periodice. Astfel, se combin
flexibilitatea i eficien a modelelor de timp continuu cu grid-ul temporal de referin , care este
utilizat n reprezent rile cu timp discret.
O evaluare interesant a diverselor modele utilizate n probleme de secven iere este realizat n
[Baker K. R., 2010]. Lucrarea se concentreaz n special asupra problemelor cu o singur ma in la
care criteriul de optimizare este dat de ntrzierea total fa de termenul limit . Concluzia este c
modelele generale MIP nu pot concura cu cele specializate asupra anumitor aplica ii n cazul n care
num rul de job-uri dep
te cteva sute; daca modelul con ine ns 40-50 de job-uri, performan ele
sunt comparabile.
Modelele CSP men ionate mai sus adreseaz aspecte ale nivelului MES al piramidei de
automatizare. Paradigma CSP poate fi ns aplicat cu succes i la nivelul ERP al unui ntreprinderi,
dup cum este prezentat n lucr rile [Nieuwenhuyse I.V., 2011] i [Hvolby H.-H., 2010]. Scopul n
cazul acestor aplica ii este n general de simplifica luarea deciziilor n ceea ce prive te achizi iile
realizate de ntreprindere dar i de a onora comenzi efectuate de clien i. n [Jiao J. R., 2009] se
prezint un model pentru coordonarea produc iei, a proceselor implicate precum i a lan ului de
aprovizionare. Modelul adreseaz situa ia n care o ntreprindere i desf oar activit ile n loca ii
diferite i realizeaz o coordonare optim a acestora.
32
Paradigma CSP a fost aplicat cu succes i n alte domenii, precum: irigare ([Clarke D., 2000]
prezint dou modele MIP pentru o aplica ie de scheduling care determin orarul de irigare al unui
sistem de canale) sau transport feroviar ([Tormos P., 2006] prezint divizarea unui model de
complexitate mare n mai multe modele de dimensiuni reduse, independente n mare m sur ;
divizarea este f cut n func ie de graful de constrngeri, de grupuri de trenuri sau de sta ii).
n ceea ce prive te g sirea unei solu ii optime a unui model CSP, n [Duffany J. L., 2009] s-a
introdus un algoritm nou bazat pe o tehnic de substitu ie similar celei utilizate la rezolvarea
sistemelor mari de ecua ii. Ineficien a ini ial a acestuia, dat de necesitatea calculului p tratului
matricei A la fiecare pas, este eliminat ulterior printr-o tehnic de incrementare succesiv .
2.5 CONCLUZII
n acest capitol au fost introduse conceptele de baz ale problemelor de satisfacere a constrngerilor
(CSP). O problem de satisfacere a constrngerilor este n general format dintr-un model i un
solver. Modelul con ine variabilele, domeniile acestora, dar i constrngerile formulate asupra
variabilelor iar solver-ul aplic o serie de concepte precum algoritmi de c utare, tehnici de
consisten sau propagare a constrngerilor pentru a g si un set de valori ale variabilelor modelului
care satisfac constrngerile formulate. n plus, n cazul multor probleme practice scopul este nu doar
de a g si o solu ie, ci de a g si solu ia care optimizeaz o anumit func ie de cost. n figura 2.4 s-a
prezentat modul general de func ionare al unui solver CSP care combin tehnica de propagare a
constrngerilor cu algoritmi de c utare pentru a g si o solu ie (optim ) ntr-un timp ct mai scurt.
n continuare au fost introduse aspecte legate de problemele de scheduling care reprezint un
subdomeniu important al domeniului CSP i care sunt aplicate cu predilec ie n domeniul industrial.
S-au introdus de asemenea trei solvere care au fost evaluate n contextul lucr rii i care au fost
folosite pentru rezolvarea modelelor CSP introduse de-a lungul lucr rii: JaCoP, Choco i JLPI.
n final s-au prezentat progresele recente realizate n domeniu n ceea ce prive te aplicarea
paradigmei CSP n mediul industrial. Lucr rile men ionate pot fi mp ite n mai multe categorii,
precum: scheduling pentru probleme de tip job-shop, rezolvarea modelelor cu grad nalt de
complexitate, probleme de scheduling n timp real, probleme de scheduling pentru sistemele
flexibile de fabrica ie, modele MIP, modele pentru nivelul ERP al piramidei de automatizare, etc.
Toate aspectele prezentate n acest capitol indic faptul c domeniul CSP este un domeniu de
cercetare care a ajuns la maturitate i care poate fi aplicat cu succes n rezolvarea problemelor
practice. Progresele men ionate sunt remarcabile i au permis rezolvarea unor modele de
complexitate tot mai mare n intervale de timp mai scurte.
Un aspect important care a fost ns neglijat aproape n totalitate n lucr rile men ionate l reprezint
utilizarea automat n produc ie a solu iilor problemelor CSP. n cazul n care nu exist o leg tur
direct ntre solu iile problemelor CSP i dispozitivele de control ale ma inilor industriale,
necesitatea unui operator uman care s realizeze aceast sarcin duce la sc derea semnificativ a
eficien ei unei astfel de abord ri. n plus, mediul industrial este unul dinamic, n interiorul c ruia pot
mereu s apar modific ri datorit schimb rii produselor fabricate, a activit ilor de mentenan sau
a unor defecte ale instala iilor. Astfel, conexiunea dintre un solver CSP i dispozitivele de control
rora le sunt destinate solu iile modelelor CSP nu este necesar doar pentru a utiliza automat aceste
solu ii, dar i pentru a realiza o reconfigurare continu i dinamic a modelelor CSP. Eficien a i
33
elegan a paradigmei CSP poate fi aplicat cu succes n mediul industrial doar n cazul n care este
stabilit aceast conexiune bidirec ional .
n lucrarea [Frantzen M., 2011] a fost sugerat o astfel de abordare dar solu iile problemei CSP erau
trimise ca sugestii c tre operatorii umani i nu direct c tre dispozitivele de control. Singura lucrare
n domeniu care propune o abordare bazat pe utilizarea automat a solu iilor este [Ferrolho A.,
2007], unde orarele de lucru optim sunt determinate prin algoritmi genetici.
Un alt aspect neglijat n lucr rile din domeniu l reprezint combina ia dintre nivelul MES i nivelul
ERP al piramidei de automatizare. Prin realizarea unei conexiuni directe dintre dispozitivele de
control i modelele CSP utilizate pentru determinarea unor orare de lucru optime, se deschid i o
serie de oportunit i pentru nivelul ERP: se pot determina valorile indicatorilor cheie de performan
i se pot construi modele CSP la nivelul ERP care s interac ioneze cu modelele CSP de la nivelul
MES.
n acest context, unul din scopurile principale ale lucr rii este acela de a introduce o arhitectur
industrial care permite utilizarea automat a solu iilor modelelor CSP dar i reconfigurarea
dinamic a acestora n func ie de starea curent a dispozitivelor de control precum i a sta iilor
comandate de acestea. De i arhitectura este dezvoltat n principal pentru nivelul MES,
caracteristicile acesteia simplific sarcinile organizatorice i de supraveghere ale nivelului ERP.
34
3 ARHITECTUR ORIENTAT PE SERVICII

PENTRU OPTIMIZAREA APLICA IILOR
INDUSTRIALE
3.1 INTRODUCERE
n prefa s-a realizat o scurt descriere a orient rii actuale a aplica iilor industriale (sistemele de
fabrica ie trebuie s fie bazate i orientate pe timp iar ntreaga strategie de fabrica ie trebuie adaptat
pentru a suporta inovarea i introducerea u oar de noi produse). Au fost astfel identificate
principalele cerin e care trebuie satisf cute de ntreprinderi (capacitate de integrare dinamic a
entit ilor n interiorul ntreprinderii, agilitate prin adaptabilitate i reconfigurare, etc.). Deoarece o
treime din costul total de fabrica ie al unei companii este determinat de activit ile de instalare i
configurare a echipamentelor, optimizarea proceselor de fabrica ie este mai important dect n
trecut [Jammes F., 2005 a)].
S-au identificat de asemenea cerin ele i provoc rile referitoare la ecosistemele de interconectare a
dispozitivelor: dispozitivele trebuie s furnizeze interfe e universale, interoperabile i cu acces
securizat, dispozitivele trebuie s poat fi integrate u or n cadrul sistemelor complexe i integrarea
trebuie s fie scalabil , fiecare subsistem trebuie s fie expus precum un singur dispozitiv astfel nct
poat fi integrat n sisteme mult mai complexe, etc.
n sec iunile ce urmeaz este introdus o arhitectur orientat pe servicii care ndepline te cerin ele
men ionate mai sus ale sistemelor de fabrica ie i care reprezint practic tema central a c ii. n
acest sens se subliniaz obiectivele principale la dezvoltarea arhitecturii:
optimizarea proceselor de fabrica ie prin determinarea unor planuri de fabrica ie optime;
utilizarea automat , f interven ia unui operator uman, a planurilor de fabrica ie optime;
construirea unei arhitecturi flexibile, adaptabile i reutilizabile, care s reduc timpii de
instalare i setare la valori minime.
Pentru determinarea unor planuri de fabrica ie optime i avnd n vedere cele prezentate n prefa ,
s-a ales metodologia bazat pe probleme de satisfacere a constrngerilor deoarece pe de o parte
permite construirea unor modele flexibile liniare ct i neliniare, iar pe de alt parte exist o serie de
solvere open source bine dezvoltate care pot fi folosite pentru optimizarea aplica iilor industriale.
Detaliile introduse n capitolul 2 au demonstrat nu doar fezabilitatea acestei abord ri, dar i
multitudinea de domenii i aplica ii industriale n care aceast tehnic a fost aplicat cu succes.
n continuare, pentru a permite utilizarea automat a planurilor de fabrica ie, solu ia ob inut trebuie
comunicat dispozitivelor de control. n acest sens a fost aleas specifica ia OPC Unified
Architecture care a fost introdus n 2006 ca nlocuitor al vechiului standard OPC bazat pe
tehnologia COM. Standardul OPC clasic a fost creat ca interfa de comunicare dintre drivere,
35
3. ARHITECTUR
ORIENTAT
PE SERVICII PENTRU OPTIMIZAREA APLICA IILOR INDUSTRIALE
permi nd citirea standardizat ct i acces de scriere asupra datelor curente din dispozitivele de
automatizare. Astfel, caracteristicile necesare ndeplinirii celui de-al doilea obiectiv al arhitecturii
prezentate n continuare erau deja prezente n specifica ia clasic , deoarece aceasta permitea un
acces standardizat, independent de produc tor, la dispozitivele de control. Vechea specifica ie avea
ns o serie de dezavantaje, dintre care cel mai important era dependen a de platforma Windows,
dat de utilizarea tehnologiei COM introdus de Microsoft. Noua specifica ie OPC UA a nl turat
acest dezavantaj i a introdus o serie de alte avantaje, care vor fi detaliate n special n capitolul 4.
n final, pentru atingerea celui de-al treilea obiectiv s-a ales folosirea serviciilor software. Dup cum
a fost subliniat n capitolul 1, introducerea logicii n cadrul unor servicii software permite
construirea unor aplica ii flexibile i mai ales reutilizarea codului. Serviciile software sunt utilizate
n principal pentru a facilita comunicarea dintre serverele OPC UA i solver-ele utilizate pentru
determinarea solu iilor optime. Prin introducerea serviciilor, cele dou nivele pot fi programate i
ntre inute independent. Flexibilitatea i reutilizabilitatea componentelor software nu este dat doar
de prezen a serviciilor ci i de modul de realizare i implementare al nivelului bazat pe constrngeri
(la acest nivel modelele definite trebuie s fie flexibile pentru a ine cont de starea actual a
dispozitivelor i sta iilor de fabrica ie) i al nivelului serverelor OPC UA (aceste servere modeleaz
dispozitivele de control i modelele astfel ob inute, numite n continuare spa ii de adrese, trebuie i
ele s fie construite n mod eficient dar i s permit o ntre inere u oar ).
Figura 3.1 prezint cele trei obiective ale arhitecturii introduse n lucrare precum i tehnologiile care
contribuie la ndeplinirea fiec rui scop. Se poate astfel observa cum fiecare tehnologie ndepline te
n principiu un anumit obiectiv, dar toate cele trei tehnologii contribuie la asigurarea flexibilit ii
arhitecturii [Grbea A., 2012 b)].
Fig. 3.1. Contribu ia tehnologiilor la ndeplinirea obiectivelor arhitecturii.
3.2 PREZENTAREA GENERAL A ARHITECTURII

Arhitectura este construit n jurul componentelor cheie SOA (Arhitectur Orientat pe Servicii), ale
rei caracteristici principale sunt: autonomia i interoperabilitatea. Lucrarea [Jammes F., 2005 a)] a
identificat principiile care permit combinarea ambelor propriet i, dintre care cele mai importante
sunt:
interfa a proiectat printr-o abordare din exterior nspre interior;
implementarea serviciilor s poat fi modificat n orice moment f a afecta interfa a sau alte
servicii.
36
3. ARHITECTUR
ORIENTAT
Figura 3.2 prezint designul conceptual al arhitecturii, care este compus din trei nivele principale,
reprezentnd cele trei tehnologii ilustrate n figura 3.1 [Grbea A., 2012 d)]. Serverul OPC UA
colecteaz datele de la dispozitive, senzori sau elemente de execu ie, le modeleaz ntr-un mod
unificat i standardizat i de asemenea asigur comunica ia n timp real cu dispozitivele. Cea de-a
doua component este format din mai multe nivele de servicii, care reprezint stlpii de sus inere ai
arhitecturii i care prin urmare garanteaz flexibilitatea i adaptabilitatea sa. Cea de-a treia
component a arhitecturii (solver-ul CSP) adreseaz scopul principal al acesteia i anume
optimizarea planurilor de produc ie i a orarelor de lucru. Astfel, prin combinarea celor trei
concepte, arhitectura optimizeaz att produc ia ct i activit ile de instalare i de setare.
Dezvoltarea arhitecturii a fost bazat pe convingerea c trebuie urmat o cale de mijloc care s
men in rolul actual al automatelor programabile i al dispozitivelor de control similare, dar care pe
de alt parte ndepline te noile cerin e ale mediilor de fabrica ie.
Fig. 3.2. Arhitectura propus pentru optimizarea proceselor de fabrica ie.
37
3. ARHITECTUR
ORIENTAT
Figura 3.2 ilustreaz interac iunile conceptuale dintre cele trei nivele ale arhitecturii. Se porne te de
la ideea c un client (sau inginerul responsabil de planificarea produc iei) plaseaz o comand (pasul
1), dup care solver-ul CSP calculeaz un plan de fabrica ie optimizat prin utilizarea datelor de
configurare i mentenan stocate n interiorul serverelor UA i ob inute prin intermediul serviciilor
(pa ii 2, 3 i 4). Imediat ce planul de fabrica ie este stabilit, un serviciu complex este lansat pentru a
transfera solu ia c tre serverul OPC UA corespunz tor ( i implicit dispozitivelor, din nou tot prin
intermediul serviciilor pasul 5) i pentru a monitoriza execu ia comenzii (pasul 6). Dac apar erori
sau alarme, serviciul complex va efectua activit i de gestionare a acestora (pasul 7).
nc de la nceput trebuie subliniat faptul c opera iile critice din punct al timpului de execu ie sunt
strate pe dispozitivele de control, arhitectura construit deasupra acestor dispozitive avnd rolul
de a transmite comenzi de fabrica ie optimizate i de a monitoriza func ionarea dispozitivelor.
Arhitectura introdus n figura 3.2 este o arhitectur orientat pe servicii, care prezint toate
caracteristicile fundamentale ale conceptului SOA. Serviciile software sunt cele care asigur
respectarea cerin elor prezentate n prefa . ndeplinirea acestor cerin e reprezint o premis
esen ial pentru succesul arhitecturii propuse n mediul economic actual.
Cele trei componente principale ale arhitecturii au fost implementate folosind limbajul Java i
mediul de programare Eclipse IDE [***Eclipse, 2012]. De i de obicei pentru sisteme de
monitorizare i control industrial limbajul C/C++ este mai eficient dect limbajul Java, n ziua de azi
nu exist mari diferen e ntre aplica iile realizate n C sau n Java. Limbajul Java a fost optimizat n
mod accentuat de la apari ia sa i n multe situa ii conduce chiar la performan e mai bune dect
limbajul C. De exemplu, este mai u or s se construiasc aplica ii cu mai multe fire de execu ie, care
la rndul lor simplific utilizarea efectiv a echipamentelor hardware care con in mai multe
procesoare/unit i de calcul. De asemenea, aplica iile Java sunt mai u or de dezvoltat i de ntre inut
(erorile pot fi detectate mai simplu) i prin urmare sunt mai eficiente. C++ desigur a adus
mbun iri importante limbajului C, dar Java este mai robust i mai pu in predispus erorilor.
3.3 SERVERUL OPC UA
Nivelul inferior este reprezentat de serverele OPC UA care modeleaz datele de la nivelul
dispozitivelor i astfel fiecare informa ie devine u or accesibil ntr-un mod unificat. Noua
arhitectur OPC UA a fost introdus ca un nlocuitor al specifica iilor existente bazate pe COM, f
a pierde din caracteristici sau din performan [***The OPC Foundation, 2011 a)]. OPC UA
furnizeaz toate datele ntr-un spa iu de adrese unificat, spre deosebire de specifica iile OPC-ului
clasic, care erau separate. n concluzie, datele curente, alarmele & evenimentele i datele istorice pot
fi accesate n acela i mod i sunt corelate. Pe de alt parte OPC UA introduce un meta model
extensibil n care fiecare element are un tip, precum n programarea orientat pe obiecte. Noua
specifica ie UA este independent de platform i de limbaj.
Datorit situa iilor diferite n care OPC este utilizat, noul standard este scalabil de la sisteme
nglobate la SCADA i DCS (Distributed Control Systems), la MES (Manufacturing Execution
Systems) i chiar ERP (Enterprise Resource Planning).
Unul dintre cele mai importante aspecte n ceea ce prive te migrarea de la OPC-ul clasic la
specifica ia UA a fost dezvoltarea unei strategii de migrare potrivite. n literatura de specialitate au
fost men ionate numeroase strategii [Mahnke W., 2009], iar pentru arhitectura curent s-a utilizat
38
3. ARHITECTUR
ORIENTAT
solu ia software special de adaptare [Grbea A., 2011 d)]. Aceast solu ie reprezint o cale de mijloc
ntre abord rile wrapper-proxy (dezvoltare rapid , capabilit i de modelare reduse) i abordarea
dezvoltare nativ (timp mare de dezvoltare, capabilit i maxime de modelare) deoarece poate fi
dezvoltat rapid i furnizeaz capabilit i maxime de modelare. Singurul dezavantaj este c trebuie
utilizat un server clasic COM, aspect care conduce la cre terea timpului de comunica ie, dar testele
de performan care au fost efectuate i care vor fi prezentate n sec iunea 4.3.4 demonstreaz c
acest lucru nu afecteaz performan a ntregii arhitecturi. Server-ele UA nglobeaz un client clasic
OPC dezvoltat pe baza SDK-ului open source JEasyOPC [***JEasyOPC, 2011] pentru a permite
comunicarea cu server-ele OPC clasice bazate pe COM. Pentru dezvoltarea serverelor UA s-a
utilizat SDK-ul (Software Development Kit) JAVA UA dezvoltat de c tre Prosys. Serverele UA
dezvoltate pentru aceast arhitectur profit de capabilit ile de modelare unificate, ceea ce
nseamn c nglobeaz specifica iile alarme & evenimente i date istorice [***The OPC
Foundation, 2011 h)], [***The OPC Foundation, 2011 i)]. n arhitectura propus implementarea
specifica iei alarme & evenimente este crucial , n special pentru gestionarea erorilor.
Spa iul de adrese este cel mai important concept pentru specifica ia UA i toate celelalte func ii bloc
trebuie s fie realizate pe baza acestuia [***The OPC Foundation, 2011 c)]. Unit ile de baz ale
spa iului de adrese sunt nodurile i referin ele care leag nodurile. Fiecare nod are atribute care sunt
determinate de tipul s u, dar exist i un set de atribute comune tuturor nodurilor, precum NodeId
(identificatorul nodului). Exist un nod de baz , care este un tip de nod abstract i nu poate fi
instan iat. Toate celelalte noduri din spa iul de adrese sunt derivate de la nodul de baz : tip de
referin , obiect, tip de obiect, variabil , tip de variabil , metod , tip de date i vedere. Prin
intermediul referin elor, toate nodurile din spa iul de adrese sunt organizate ntr-un mod structurat i
sunt conectate ntre ele. Serverele UA complet func ionale con in mii de noduri cu scopul de a oferi
clien ilor toate informa iile de care au nevoie i de aceea este important s se implementeze o
modalitate eficient de generare a spa iului de adrese, care s faciliteze de asemenea o ntre inere
oar a acestuia.
O serie de cinci algoritmi au fost dezvolta i i folosi i pentru a genera n mod automat i eficient
spa iul de adrese al unui server UA [Grbea A., 2012 a)] (algoritmii vor fi prezenta i n sec iunea
4.4). Ideile de baz ale algoritmilor sunt: divizarea nodurilor n grupuri i ad ugarea secven ial a
grupurilor n spa iul de adrese, precum i numirea unei referin e principale pentru fiecare nod int .
Serverele OPC UA comunic direct cu serviciile, care din punctul de vedere al serverului reprezint
clien i OPC UA, i cu dispozitivele, fie direct, n cazul n care protocolul de comunica ie cu acestea
este implementat n serverul UA, fie indirect prin intermediul unui server OPC clasic, caz n care se
folose te solu ia software special de adaptare [Grbea A., 2011 d)].
n general, pentru o aplica ie se recomand folosirea unui singur server OPC UA, deoarece pe de o
parte caracteristicile acestuia permit gestionarea unui num r relativ mare de echipamente, iar pe de
alt parte coordonarea procesului de fabrica ie este simplificat . n cazul unei uzine cu numeroase
sisteme de fabrica ie, se recomand folosirea mai multor servere OPC UA, nu doar datorit
performan elor sporite, dar i datorit separ rii clare a instala iilor.
n capitolul 4 vor fi prezentate n detaliu aspectele legate de migrarea de la standardul clasic OPC la
noul standard OPC UA precum i algoritmii dezvolta i pentru generarea automat a spa iului de
adrese.
39
3. ARHITECTUR
ORIENTAT
3.4 SERVICIILE SOFTWARE

Cel de-al doilea nivel al arhitecturii este reprezentat de servicii care sunt organizate pe dou nivele
(n general num rul nivelelor este nelimitat, dar cantitatea corect de granularitate a serviciilor este
crucial pentru succesul arhitecturii [Krammer A., 2011]). Ideea de a dezvolta o arhitectur SOA n
jonc iune cu un server OPC UA pare natural deoarece specifica ia UA a fost dezvoltat pe baza
elementelor cheie SOA [Virta J., 2010]. Spre deosebire de vechea specifica ie, UA define te 51 de
servicii ca mijloc principal de comunica ie i abstractizare dintre clien ii i serverele UA. Prin
introducerea serviciilor ca nivel intermediar, ntreaga arhitectur devine mult mai flexibil i asigur
timpi de reac ie mai mici cnd sunt necesare diverse modific ri.
Primul nivel de servicii este compus din servicii de baz care efectueaz opera ii precum read, write,
etc. i care vor fi integrate n orice scenariu de utilizare a arhitecturii: WriteVariableNode, ReadVariableNodeService, CallMethodService, ReadAlarmStateService, ReadAlarmEvent-Service,
ReadRawDataService, ReadProcessedService, ReadAtTimeService.
Toate serviciile de baz , ct i unele complexe se comport ca i clien i din punctul de vedere al
unui server UA. Fiecare serviciu, care simultan reprezint un client UA, trebuie s stabileasc o
conexiune cu serverul UA pentru a putea extrage datele necesare clientului serviciului. Setarea unei
conexiuni cu server-ul UA implic mai mul i pa i i de asemenea necesit un anumit timp: trebuie
generat o descriere a aplica iei, dup care pe baza acestei descrieri se va genera o identitate a
aplica iei. n consecin a fost folosit o abordare bazat pe sesiuni pentru a reduce timpul de
spuns pentru clientul serviciului: fiecare serviciu ine o eviden a conexiunilor, ceea ce nseamn
fiecare serviciu va con ine un set de conexiuni pentru entit ile/utilizatorii care l apeleaz .
Aceast abordare este simpl i poate fi u or programat la nivel de serviciu. n plus pot fi stabilite
conexiuni specializate, particularizate pentru fiecare tip de serviciu. Cre terea num rului de
conexiuni nu reprezint un dezavantaj deoarece serverele UA pot gestiona un num r mare de
conexiuni f a suferi pierderi de performan .
Serviciile complexe pot fi mp ite n patru categorii: servicii care controleaz i monitorizeaz
produc ia, servicii de gestionare a erorilor, servicii care citesc date de configurare pentru modelele
CSP aflate la nivelul superior al arhitecturii i servicii care furnizeaz informa ii generale despre
procesul de fabrica ie.
De obicei aceste servicii complexe interac ioneaz cu mai multe servicii de baz pentru a- i finaliza
opera iile. Serviciile complexe din prima categorie recep ioneaz solu iile de la modelele CSP i
controleaz i monitorizeaz procesele de fabrica ie (acestea sunt n general servicii cu durat de
execu ie mai lung ).
nainte de determinarea solu iilor optimizate, modelul CSP apeleaz unul sau mai multe servicii
pentru a determina starea curent a dispozitivelor fizice i a parametriza astfel modelul. De
asemenea, serviciile pot fi folosite pentru a determina valorile indicatorilor de performan KPI de
la nivelul ntreprindere. O problem specific referitoare la primul grup de servicii a fost
monitorizarea alarmelor i evenimentelor. De i aceste servicii vor apela mai multe servicii de baz
pentru a realiza opera iile, serviciile de baz nu pot fi folosite pentru a detecta st rile de urgen i
alarmele.
Astfel, cnd un serviciu complex este apelat, ini ial acesta stabile te o conexiune cu serverul UA i
se aboneaz la alarmele i evenimentele care corespund ac iunii curente efectuate de serviciul
40
3. ARHITECTUR
ORIENTAT
complex. Apoi, in timpul execu iei sale, acesta apeleaz mai multe servicii de baz pentru a controla
procesul de fabrica ie n conformitate cu solu ia optimizat propus de modelul CSP. n cazul n care
apare o eroare n timpul procesului de fabrica ie, serviciul complex fie opre te execu ia procesului i
notific inginerul n leg tur cu evenimentul respectiv, fie apeleaz un serviciu special care
gestioneaz eroarea.
Se poate observa faptul c , dup cum este prezentat n figura 3.2, serviciile furnizeaz date att
nivelului superior (CSP) ct i nivelului inferior (UA), ndeplinind astfel practic rolul de comunicare
ntre nivelul CSP (care determin solu ii optime de fabrica ie) i nivelul UA (care folose te solu iile
optime de fabrica ie).
Serviciile au fost implementate folosind dou framework-uri de servicii web: Apache CXF (servicii
bazate pe SOAP Simple Object Access Protocol ) i Jersey (servicii web bazate pe REST
Representational State TRansfer) i un framework de servicii Java denumit Apache River (cunoscut
si sub numele de Jini). Pentru determinarea framework-ului optim n cazul arhitecturii propuse, s-au
dezvoltat o serie de teste de performan , n urma c rora s-a ales framework-ul Apache River.
n capitolul 5 vor fi prezentate n detaliu aspectele legate de implementarea serviciilor de baz i a
serviciilor complexe precum i testele de performan care motiveaz decizia de a folosi frameworkul Apache River.
3.5 NIVELUL CSP
Nivelul superior al arhitecturii propuse este reprezentat de un set de modele CSP precum i de un set
de solver-e care sunt folosite pentru rezolvarea acestor modele. Dup cum a fost descris n capitolul
2, programarea bazat pe constrngeri este o paradigm utilizat la rezolvarea problemelor
combinatorice de optimizare iar o instan a unei probleme CSP, numit de obicei model, este
descris de un set de variabile, un set de valori posibile pentru fiecare variabil i un set de
constrngeri asupra variabilelor.
Pentru rezolvarea modelelor au fost evaluate solver-ele open source Choco i Jacop precum i
biblioteca JLPI (Java Linear Programming Interface) care este o interfa Java care este n prezent
dezvoltat de Siemens i care este disponibil pentru utilizare intern . Primele dou solvere sunt
generale i pot rezolva att modele liniare ct i neliniare n timp ce biblioteca JLPI este optimizat
pentru modele liniare, pentru care conduce la timpi de execu ie mai mici, dar nu poate fi folosit
pentru modele neliniare. O dificultate important n g sirea unei solu ii optime pentru un anumit
model CSP este faptul c timpul de execu ie cre te exponen ial cu cre terea complexit ii modelului.
Detaliile generale ale celor trei solvere au fost prezentate n capitolul 2 mpreun cu conceptele
utilizate pentru determinarea solu iei optime.
3.6 CONCLUZII
n acest capitol a fost introdus conceptul general al arhitecturii software orientate pe servicii, care
reprezint tematica central a lucr rii. Au fost prezentate obiectivele propuse la dezvoltarea
arhitecturii, precum i tehnologiile alese pentru ndeplinirea acestor obiective (arhitectura combin
n mod unic trei concepte i tehnologii complet diferite, fiecare dintre tehnologii ndeplinind un
41
3. ARHITECTUR
ORIENTAT
anumit obiectiv). n continuare a fost prezentat structura general a arhitecturii, interac iunea dintre
nivelele acesteia precum i o scurt descriere a nivelelor.
Scopul lucr rii este de a construi o arhitectur orientat pe servicii care s optimizeze aplica iile
industriale din mai multe puncte de vedere. Aceasta trebuie se permit aducerea mai aproape de
proces a deciziilor luate la nivelele superioare ale piramidei de automatizare i s poat fi aplicat
ntr-o gam larg de procese industriale.
Scopul acestui capitol este de a furniza o imagine de ansamblu asupra arhitecturii, asupra scopului i
obiectivelor pe care le ndepline te aceasta precum i asupra componentelor sale, urmnd ca n
capitolele urm toare s fie prezentate detaliile fiec rui nivel i validarea conceptului pe baza unor
aplica ii industriale reale.
Capitolul ce urmeaz va prezenta n detaliu nivelul de baz al arhitecturii (serverele OPC UA),
avantajele utiliz rii acestui nivel precum i inova iile introduse.
42
4 SERVERUL OPC UA
4.1 INTRODUCERE
Utilizarea sistemelor de automatizare bazate pe software i pe calculatoare (PC) a crescut rapid de la
nceputul anilor nou zeci, PC-urile bazate pe Windows fiind utilizate n special pentru monitorizarea
i controlul proceselor. Astfel, o mare parte a eforturilor depuse pentru dezvoltarea unor programe
de automatizare standardizate a fost ndreptat c tre accesul la datele din dispozitivele de
automatizare produse de diferite companii.
Pentru a rezolva aceast problem , n 1995 a fost fondat un grup de c tre companiile FisherRosemount, Rockwell Software, Opto 22, Intellution i Intuitive Technology. Scopul acestui grup a
fost definirea unui standard de tip plug&play (care nu necesit activit i de configurare) pentru
driverele dispozitivelor care s asigure un acces standardizat la datele de automatizare a sistemelor
bazate pe Windows. Rezultatul a constat n apari ia specifica iei OPC Data Access n august 1996
(organiza ia non-profit OPC Foundation este cea care ntre ine acest standard). Aproape to i
furnizorii care pun la dispozi ie sisteme pentru automatiz rile industriale au devenit membrii n
cadrul funda iei OPC. Astfel, funda ia a fost n m sur s defineasc i s adopte standarde relevante
n practic mult mai rapid dect alte organiza ii. Unul dintre motivele succesului a fost impunerea
unei restric ii conform c reia API-urile trebuiau definite cu ajutorul tehnologiilor Microsoft
Windows: Component Object Model (COM) i Distributed COM (DCOM). Accentul pe
caracteristicile esen iale i utilizarea tehnologiilor Windows de baz au permis o adoptare rapid a
standardului pentru cazul de utilizare adresat.
De-a lungul timpului au fost dezvoltate trei genera ii OPC: OPC-ul clasic (prima versiune), OPC
XML i OPC Unified Architecture.
Tehnologia OPC UA a fost introdus n cadrul arhitecturii n principal pentru a permite utilizarea
automat , f
interven ia unui operator uman, a planurilor de fabrica ie optime. n plus, aceast
tehnologie contribuie i la flexibilitatea i reutilizabilitatea arhitecturii prin structura spa iilor de
adrese (care faciliteaz flexibilitatea modelelor CSP de la nivelul superior al arhitecturii) i prin
simplitatea definirii acestor spa ii de adrese (asigurat n principal de algoritmii de generare
automat a spa iului de adrese care vor fi prezenta i n una din sec iunile urm toare).
4.2 COMPARA IE OPC CLASIC OPC UA
4.2.1 OPC clasic
n ultimele decenii, funda ia OPC a definit o serie de interfe e software pentru standardizarea
fluxului de informa ii de la nivelul de proces pn la nivel de management. Pe baza diferitelor
cerin e din aplica iile industriale au fost dezvoltate trei specifica ii majore OPC: Accesul Datelor
43
4. SERVERUL OPC UA
(cunoscut n literatura de specialitate ca Data Acces DA), Alarme i Evenimente (Alarms &
Events A&E) i Accesul la Datele Istorice (Historical Data Access HDA). Accesul la proces n
timp real este descris n specifica ia DA, A&E descrie o interfa pentru informa iile bazate pe
evenimente incluznd i alarmele de proces iar HDA descrie func iile de acces la datele istorice.
Toate interfe ele ofer un mod de a naviga prin spa iul de adrese i de a furniza informa ii referitoare
la datele disponibile.
OPC utilizeaz arhitectura client-server pentru schimbul de informa ii. Un server OPC ncapsuleaz
sursa de informa ii de proces la fel ca un dispozitiv i pune la dispozi ie informa iile prin intermediul
interfe ei sale. Un client OPC se conecteaz la serverul OPC i astfel poate accesa i utiliza datele
oferite. Aplica iile consumatoare i furnizoare de date pot fi att client ct i server.
Avantajul utiliz rii tehnologiilor Microsoft COM i DCOM a fost reducerea caietului de sarcini la
definirea de API-uri diferite pentru necesit i diferite, f obliga ia de a defini un protocol de re ea
sau un mecanism de intercomunicare ntre procese. Pentru un anumit client, COM i DCOM
furnizeaz un mecanism transparent de a apela metodele unui obiect COM dintr-un server care
ruleaz n acela i proces, ntr-un alt proces sau pe un alt nod de re ea. Utiliznd aceast tehnologie,
care este disponibil pe toate PC-urile bazate pe Windows, s-a redus timpul de dezvoltare a
specifica iilor i produselor. Acest aspect a fost foarte important pentru succesul OPC.
Principalele dou dezavantaje ale standardului OPC clasic sunt dependen a de platforma Windows i
problemele DCOM atunci cnd se utilizeaz comunicarea la distan cu OPC.
4.2.2 Necesitatea introducerii standardului OPC UA
Primul i cel mai de succes standard OPC (OLE for Process Control) OPC Data Access a fost
creat ca interfa de comunicare dintre drivere, permi nd citirea standardizat ct i acces de scriere
asupra datelor curente n dispozitivele de automatizare [Itu L. M, 2010]. Cazurile cel mai des
ntlnite au fost HMI (Human Machine Interface) i sistemele SCADA (Supervisory Control And
Data Aquisition), care accesau date provenite de la diferite tipuri de echipamente de automatiz ri
provenite de la furnizori diferi i, folosind o interfa software pus la dispozi ie de c tre furnizor.
Standardele ce au ap rut mai trziu, precum OPC Alarm&Events ct i OPC HDA (Historical Data
Access) au fost de asemenea concepute pentru a accesa informa ii furnizate de c tre sisteme
SCADA.
Datorit adopt rii cu succes a standardului OPC n mii de produse, OPC este folosit ast zi ca
interfa standardizat ntre sistemele de automatizare de la diferite nivele ale piramidei de
automatizare.
OPC este folosit chiar ntr-o mul ime de domenii pentru care acesta nu a fost proiectat, i exist mult
mai multe domenii n care produc torii doresc s utilizeze un standard precum OPC, dar nu au fost
n m sur s -l utilizeze deoarece OPC este dependent de COM sau din cauza limit rilor de acces de
la distan folosind DCOM.
OPC XML-DA a fost prima ncercare a funda iei OPC de a introduce o infrastructur de comunicare
neutr i independent de furnizor, dar n acela i timp de a men ine cu succes caracteristicile OPC.
Exist mai multe motive pentru care simpla creare a unor versiuni tip servicii web pentru
specifica ia OPC nu acoper cerin ele unei noi genera ii OPC. Unul dintre motive a fost dat de
performan ele slabe oferite de specifica ia XML Web Service n compara ie cu versiunea COM
original . n plus, folosirea unor diferite stive XML Web Service cauzeaz probleme de
44
4. SERVERUL OPC UA
interoperabilitate. Pe lng problema de independen de platforma, companiile membre OPC au

raportat dorin a de a expune date complexe i sisteme complexe, eliminndu-se astfel limit rile
OPC-ului clasic.
OPC Unified Arhitecture a ap rut din dorin a de a crea un nlocuitor adev rat pentru toate
specifica iile existente bazate pe COM, f
a pierde din caracteristicile existente sau din
performan [***The OPC Foundation, 2011 a)]. Unul din elementele de noutate ale acestei
arhitecturi a fost acoperirea tuturor cerin elor pentru o interfa are independent de platform a
sistemelor. De asemenea posibilit ile de modelare au fost extinse pentru a permite descrierea unor
sisteme de control i monitorizare complexe.
Datorit situa iilor numeroase n care este folosit OPC, noul standard este scalabil i poate fi utilizat
pentru sistemele nglobate sau sistemele SCADA, care pot fi folosite n interiorul tuturor celor trei
nivele ale piramidei de automatizare.
Cerin ele adresate noului standard OPC UA pot fi grupate n cerin e pentru comunicare ntre sisteme
distribuite (care s fie astfel capabile s fac schimb de informa ii) i cerin e pentru modelarea
datelor ce descriu un sistem i informa iile disponibile. OPC-ul clasic a fost conceput ca interfa
pentru comunica ia cu diverse drivere. OPC-ul este utilizat ns n ziua de azi ca interfa de sistem
i prin urmare fiabilitatea pentru comunicarea ntre sisteme distribuite a devenit foarte important .
Deoarece comunica ia prin re ea nu este fiabil prin defini ie, robuste ea i toleran a la erori sunt
cerin e importante.
Independen a de platforma i scalabilitatea sunt necesare pentru a putea integra interfe ele OPC
direct n sistemele care ruleaz pe mai multe platforme. O cerin important este ntotdeauna
performan nalt n medii intranet pentru a nlocui comunica ia prin protocoale proprietare. De
asemenea, comunica ia prin internet prin intermediul firewall-urilor trebuie s fie posibil f
opera ii de configurare suplimentare. Prin urmare, securitatea i controlul accesului trebuie i ele
asigurate. Cea mai important cerin o reprezint n continuare interoperabilitatea dintre sistemele
de la diferi i furnizori. Tabelul 4.1 prezint cerin ele UA fundamentale.
Tab. 4.1. Cerin ele OPC UA [Mahnke W., 2009].
Comunica ia ntre sistemele distribuite

Fiabilitate prin:
Robuste e i toleran a la erori
Redundan
Independen de platform
Scalabilitate
Performan de nivel nalt
Internet i firewall-uri
Securitate i acces controlat
Interoperabilitate
Modelarea datelor
Model comun pentru toate datele OPC
Orientat pe obiecte
Sistem de tipuri extensibil
Metainforma ii
Date complexe i metode
Scalabilitate de la modele simple la cele
complexe
Model de baz abstract
Baz pentru alte modele de date standardizate
Modelarea datelor a fost limitat n OPC-ul clasic i trebuia consolidat prin furnizarea unui model
comun, orientat pe obiecte pentru toate datele OPC. Acest model include un sistem de tipuri
extensibil care ofer meta informa ii i care poate descrie sisteme complexe.
45
4. SERVERUL OPC UA
Disponibilitatea metodelor furnizate i descrise de servere, i apelate de clien i reprezint o

caracteristic important , necesar pentru asigurarea flexibilit ii i extensibilit ii specifica iei OPC.
Datele complexe sunt necesare pentru a sprijini descrierea i transportul consistent de structuri de
date complexe.
Un obiectiv major a fost mbun irea capacit ilor de modelare, dar a fost la fel de important s se
men in posibilitatea utiliz rii unor modele simple cu concepte simple. De aceea este necesar
existen a unui model de baz extensibil, simplu i abstract pentru a putea scala de la modele simple
la unele complexe.
Pentru noua genera ie OPC, grupul ini ial de peste 40 de reprezentan i convoca i pentru definirea
cerin elor i a cazurilor de utilizare a standardului OPC Unified Arhitecture nu a fost format numai
din membri OPC. Au fost implicate n procesul de proiectare i alte organiza ii de standardizare
precum IEC (International Electrotechnical Committee) i ISA (Industry Standard Architecture),
acestea fiind interesate de utilizarea OPC-ului ca mecanism de transport al informa iilor. n acest
grup funda ia OPC define te modul de descriere i transport al datelor iar organiza iile colaboratoare
definesc, n func ie de modelul lor de informa ii, ce date doresc s fie descrise i s fie transportate.
Un alt obiectiv important pe parcursul proiect rii a fost acela de a permite o migrare u oar la noul
standard UA pentru a consolida investi iile de succes realizate pentru standardul clasic OPC i
pentru dezvoltarea bazei OPC existente.
4.2.3 OPC UA prezentare general
Pentru a ndeplini obiectivele definite, OPC Unified Architecture se bazeaz pe diferite nivele, care
sunt prezentate n figura 4.1. Componentele fundamentale ale standardului OPC UA sunt
mecanismele de transport i de modelare a datelor. Transportul define te diferite mecanisme
optimizate pentru diferite cazuri de utilizare. Prima versiune OPC UA define te un protocol TCP
binar optimizat, ce ofer comunicare intranet de nalt performan precum i asocierea cu diversele
tehnologii utilizate pe internet precum servicii web, XML i HTTP.
ntotdeauna se utilizeaz acela i model de securitate bazat pe mesaje, cunoscut de la serviciile web.
Modelul de comunica ie abstract nu depinde de un protocol specific de mapare i permite ad ugarea
de noi protocoale n viitor [Hadlich T., 2006].
Partea de modelare a datelor define te regulile i blocurile de construc ie de baz necesare pentru a
expune un model de informa ii prin OPC UA. De asemenea sunt definite punctele de intrare n
spa iul de adrese i tipurile de baz folosite pentru construirea unei ierarhii de tipuri. Aceast baz
poate fi extins prin construirea unor modele de informa ii pe baza conceptelor de modelare
abstracte. n plus, se definesc unele concepte noi precum descrierea ma inilor de stare utilizate n
modele de informa ii diferite.
Serviciile UA reprezint interfa a dintre servere (furnizori ai unor modele de informa ii) i clien i
(consumatori ai acestor modele de informa ii) [***The OPC Foundation, 2011 d)]. Serviciile sunt
definite ntr-un mod abstract i folosesc mecanismele de transport pentru schimbul de date dintre
client i server.
Acest concept de baz al OPC UA permite unui client OPC UA s acceseze cele mai mici entit i de
date f
a fi nevoie s cunoasc ntregul model expus de sistemele complexe. Clien ii OPC UA,
folosind modele specifice, pot utiliza numeroase caracteristici mbun
ite i definite pentru
domenii i cazuri de utilizare speciale.
46
4. SERVERUL OPC UA
Fig. 4.1. Elementele fundamentale ale specifica iei UA [Mahnke W., 2009].
4.2.4 Nivelele software OPC UA

OPC UA utilizeaz un concept similar, de tip client-server, ca i cel folosit de OPC-ul clasic. O
aplica ie care dore te s i expun propriile informa ii altor aplica ii se nume te server UA i o
aplica ie care vrea s consume informa ii de la alte aplica ii este numit client UA. Prin intermediul
noii specifica ii se sus ine ns i dezvoltarea unor aplica ii mixte care s fie att server UA ct i
client UA.
Unul din motivele dezvolt rii unor astfel de aplica ii este faptul c mai multe servere UA vor fi
integrate direct n dispozitive de control sau de monitorizare. De asemenea, implementarea unui
client UA permite stabilirea unei comunica ii directe ntre dispozitive. Un alt motiv ar fi acela de a
utiliza OPC UA ca interfa de configurare, n cazul n care clien ii UA sunt, de asemenea, servere
UA care sunt configurate prin specifica ia UA.
Un exemplu tipic de aplica ie OPC UA este compus din trei nivele software, prezentate n
figura 4.2. ntreaga stiv software poate fi implementat n C/C++, .NET sau JAVA. OPC UA nu
este limitat la aceste limbaje de programare i la platformele lor de dezvoltare, ns doar aceste
medii sunt utilizate n cadrul implement rii realizate de funda ia OPC UA.
O aplica ie OPC UA este un sistem care dore te s expun sau s consume date prin OPC UA.
Aceasta con ine func ionalitatea specific a aplica iei precum i asocierea acestei func ionalit i cu
OPC UA folosind stiva OPC UA i un SDK (Software Development Kit) OPC UA.
SDK-ul de client sau de server OPC UA implementeaz func ionalit ile obi nuite OPC UA,
func ionalit i care fac parte din nivelul de aplica ie, deoarece stivele UA implementeaz doar
canalele de comunica ie. SDK-ul OPC UA reduce efortul de dezvoltare i faciliteaz
interoperabilitatea rapid pentru o aplica ie OPC UA.
47
4. SERVERUL OPC UA
Stiva OPC UA implementeaz diversele map ri de transport. Stiva este folosit pentru a invoca
servicii dincolo de grani ele procesului sau ale re elei. OPC UA define te trei nivele n interiorul
stivei precum i diferite profiluri pentru fiecare nivel. Nivelul de codare a mesajelor define te
serializarea parametrilor serviciului ntr-un format binar sau XML. Nivelul de securitate al mesajelor
define te modul n care trebuie asigurat securitatea folosind standardele de securitate ale serviciilor
web sau o versiune UA binar a acestora. Nivelul de transport al mesajelor define te protocolul de
re ea folosit, care poate fi UA TCP sau HTTP i SOAP pentru servicii web.
Fig. 4.2. Nivelele software OPC UA [Mahnke W., 2009].
Figura 4.3 ilustreaz diferitele niveluri de comunica ie ale stivei UA. Implementarea nivelurilor ntro stiv UA i API-ul (Application Programming Interface) rezultant al aplica iei nu fac parte din
specifica ia OPC UA. Stivele UA furnizeaz API-uri dependente de limbaj pentru aplica iile client i
server ns serviciile i parametrii lor sunt similari i baza i pe defini ia abstract a serviciului.
Fig. 4.3. Nivelele stivei de comunica ie UA definite in UA Part 6 [***The OPC Foundation, 2011 f)].
Prin implement rile n ANSI C/C++, .NET i JAVA, principalele medii de dezvoltare i limbaje de
programare sunt acoperite de stivele UA dezvoltate i ntre inute de c tre funda ia OPC.
OPC UA este mai flexibil i are mai multe caracteristici dect ntregul ansamblu al specifica iilor
OPC clasice, ncorporeaz toate conceptele de succes ale acestora, rezolv problemele cunoscute din
standardele existente i adaug standardizare pentru o mul ime din cazurile de utilizare
suplimentare.
48
4. SERVERUL OPC UA
Migrarea u oar de la OPC-ul clasic la OPC UA a fost un obiectiv important pe parcursul

dezvolt rii. Din acest motiv, majoritatea caracteristicilor cunoscute de la OPC-ul clasic pot fi
reg site i n OPC UA. Nu este posibil s se expun toate caracteristicile UA prin intermediul
interfe elor OPC-ului clasic, dar se poate realiza cu u urin o asociere ntre caracteristicile OPCului clasic i cele ale OPC UA.
4.2.5 Strategii de migrare OPC clasic OPC UA
nc de la anun area apari iei noii specifica ii OPC UA, una dintre marile preocup ri a fost s se
permit trecerea ct mai u oar de la standardul OPC clasic (n special OPC DA) la standardul UA.
Acesta este un aspect foarte important deoarece interfe ele OPC bazate pe COM sunt implementate
n mai mult de 15000 de produse la momentul actual. De aceea, pentru a garanta succesul
conceptului OPC UA, este crucial s se permit produselor deja dezvoltate s profite de avantajele
arhitecturii unificate i s furnizeze vnz torilor de produse OPC o strategie de migrare u oar .
[Mahnke W., 2009] sugereaz i introduce dou strategii de migrare diferite (sec iunile 4.2.5.1 i
4.2.5.2). Alte dou strategii sunt introduse n [Hannelius T., 2008] (sec iunile 4.2.5.3 i 4.2.5.4).
4.2.5.1 Wrapper i Proxy
Wrapper
Aceast component a fost dezvoltat pentru a permite unui client UA s acceseze un server COM.
O component wrapper (figura 4.4) este de fapt un client OPC clasic pentru unul din standardele
clasice OPC, care acceseaz un server clasic. n acela i timp wrapper-ul este i un server OPC UA,
care i expune punctele de conexiune UA, administreaz codarea/decodarea datelor, securitatea i
transportul.
Fig. 4.4. UA wrapper.
Proxy
Ca i wrapper-ul, proxy-urile furnizeaz un mod rapid de adaptare la standardul UA. Aceste
componente reprezint elementele complementare ale wrapper-ilor permi nd clien ilor OPC s
acceseze serverele OPC UA. Ca rezultat, o component proxy (figura 4.5) este pe de o parte un
client OPC UA care acceseaz un server UA iar pe de alt parte proxy-ul reprezint un server OPC
clasic, care expune o interfa COM. Astfel, acesta permite clien ilor care folosesc unul dintre
standardele OPC-ului clasic s acceseze serverele OPC UA.
Fig. 4.5. UA proxy.
49
4. SERVERUL OPC UA
Wrapper-ii i proxy-urile sunt componente care pot fi dezvoltate foarte rapid, ns au cteva limit ri
majore, precum: lipsa de acces unificat la informa iile DA, A&E i HDA sau absen a meta
informa iilor din interiorul spa iul de adrese.
Utilizarea wrapper-ilor i a proxy-urilor este limitat la aplica iile mo tenite i la produsele existente
att din cauza limit rilor descrise mai sus ct i din cauza modulelor software suplimentare introduse
care conduc la sc derea performan ei.
4.2.5.2 Dezvoltare nativ
SDK-urile (Software Development Kit) i stivele UA care au fost dezvoltate sau care sunt n curs de
dezvoltare pentru diferite limbaje de programare fac posibil implementarea clien ilor i a serverelor
UA folosind strategia de dezvoltare nativ (native development). n acest mod poate fi implementat
n aplica ie func ionalitatea complet a specifica iei UA, toate situa iile de utilizare descrise n
sec iunea precedent sunt suportate i modelele de informa ii specifice pot fi implementate n spa iul
de adrese. Problema major n ceea ce prive te aceast solu ie o reprezint timpul de dezvoltare care
cre te considerabil datorit faptului ca protocoalele folosite pentru comunica ia cu numeroasele
dispozitive trebuie reimplementate.
4.2.5.3 Gateway-uri OPC UA
Aceast solu ie particular trebuie considerat mpreun cu componentele de tip wrapper. Atunci
cnd utilizatorii vor s acceseze simultan date n timp real [***The OPC Foundation, 2011 g)],
evenimente i alarme [***The OPC Foundation, 2011 h)] i date istorice [***The OPC Foundation,
2011 i)] sunt necesare trei servere OPC n cazul utiliz rii unor produse bazate pe COM. Pentru
rezolvarea problemei se pot dezvolta gateway-uri (figura 4.6) OPC UA care s integreze diferitele
componente wrapper.
Fig. 4.6. UA Gateway.
4.2.5.4 Software special de adaptare

Aceast solu ie este de fapt un caz special al abord rii gateway, eliminnd neajunsurile primelor
dou solu ii deoarece profit de toate caracteristicile furnizate de c tre noua specifica ie. Pe de alt
parte dezvoltarea sa nu trebuie s ia n considerare sau s implementeze protocoalele necesare pentru
comunica ia cu dispozitivele modelate, permi nd astfel o implementare mai rapid . n acest caz
software-ul special de adaptare este nglobat ntr-un server OPC UA care furnizeaz acces la unul
sau mai multe servere OPC clasice (aceasta este solu ia aleas pentru serverele descrise n lucrare).
50
4. SERVERUL OPC UA
4.3 DEZVOLTAREA UNUI SERVER AGREGATOR FOLOSIND SOLU IA SOFTWARE

SPECIAL DE ADAPTARE
4.3.1 Arhitectura
Conceptul unui server agregator este deja integrat n specifica ia OPC UA. Un server agregator
unific datele mai multor servere UA i furnizeaz informa iile puse la dispozi ie de acestea (sau
numai o parte din ele) n spa iul s u de adrese. n acest mod clientul nu trebuie s mai comunice
separat cu toate serverele, ci poate solicita datele necesare de la un singur client. Acest concept este
ideal n special n urm toarele situa ii: mai multe servere sunt integrate direct n cadrul
dispozitivelor i acestea sunt apoi modelate de un singur server care distribuie clien ilor informa iile
necesare (clien i care pot rula de exemplu la nivelul MES al piramidei de automatizare). n cazul de
fa conceptul de agregare este folosit pentru a colecta informa iile de la mai multe servere OPC
clasice i pentru a expune informa iile lor prin intermediul unui spa iu de adrese complet dezvoltat.
n figura 4.7 se prezint cele trei situa ii tipice care apar n cazul unui server agregator. La nivelul
inferior au fost introduse ca exemplu diferite sisteme de fabrica ie flexibil , fiecare dintre ele
constnd dintr-o serie de module de control (de exemplu automate programabile). Fiecare linie
flexibil con ine de asemenea un dispozitiv master care coordoneaz celelalte module de control,
comunica ia dintre acestea realizndu-se prin intermediul unei re ele Profibus.
n primul caz, urm torul nivel con ine un server OPC clasic, care folose te protocolul proprietar al
modulelor master i furnizeaz datele conform specifica iei OPC DA. Acest server comunic cu
modulul master prin intermediul protocolului MPI. Aceast prim situa ie tipic pentru un server
agregator este practic arhitectura folosit n cadrul aplica iilor descrise n capitolele 6 i 7.
Prin p strarea serverului OPC clasic n arhitectur se profit de efortul depus pentru dezvoltarea
specifica iei OPC DA i astfel nu mai este nevoie s se implementeze protocoalele proprietare n
interiorul serverului UA. Astfel, dezvoltarea serverului agregator poate fi realizat foarte rapid.
Aceast situa ie, n care se comunic doar cu masterul fiec rei linii flexibile, este avantajoas
deoarece masterul schimb deja informa ii critice cu numeroasele dispozitive de control coordonate
de c tre el. Ca rezultat, prin intermediul masterului se pot citi sau scrie valori de la/n dispozitivele
de control individuale.
Pentru ca serverul agregator s poat comunica cu serverul clasic acesta nglobeaz un client OPC
clasic care comunic prin specifica ia COM/DCOM cu serverul clasic (COM dac att serverul UA
ct i serverul clasic se afl pe acela i calculator iar n caz contrar DCOM).
Pentru dezvoltarea serverului UA s-a folosit limbajul de programare Java i SDK-ul Java UA
dezvoltat de c tre compania Prosys [***Prosys Java UA SDK, 2011]. S-a ales acest limbaj de
programare nu numai din cauza experien ei anterioare n utilizarea lui, dar i datorit aspectelor
orientate pe obiect nglobate n specifica ia UA, aspecte care permit o corelare clar ntre clasele
orientate pe obiecte i tipurile de obiecte complexe folosite n spa iul de adrese al serverului.
Utilizarea limbajului Java nu a oferit doar avantaje [Paljakka M., 2009]. A a cum a mai fost
men ionat, specifica ia OPC se bazeaz pe componentele Microsoft COM/DCOM i astfel este
dependent de platform . Ca rezultat, nc de la nceput au ap rut dificult i n proiectarea unui
client OPC clasic n limbajul Java dar prin intermediul SDK-ului JEasyOPC [***JEasyOPC, 2011]
(care este disponibil open source) s-a realizat comunicarea cu serverele clasice. Avantajele utiliz rii
limbajului Java n raport cu limbajul C/C++ au fost prezentate n capitolul 3.
51
4. SERVERUL OPC UA
Cazurile doi i trei prezentate n figura 4.7 pot fi implementate direct folosind strategia de dezvoltare
nativ . n al doilea caz se folose te un server UA care comunic direct cu masterul liniei flexibile,
iar n interiorul serverului UA agregator este construit un client UA care preia informa iile de la
serverul UA aflat la nivel inferior. n cel de-al treilea caz, s-a introdus un dispozitiv de control care
pune la dispozi ie datele sale prin intermediul unui server UA nglobat n acesta. Aceasta este
situa ia ideal , deoarece nu este nevoie s se implementeze un protocol proprietar care s comunice
cu dispozitivul de control. Practic, pentru dispozitivele dezvoltate n viitor, aceasta va fi abordarea
utilizat cel mai des.
Fig. 4.7. Arhitectura unui server UA agregator.
Serverul agregator, care reprezint componenta principal a structurii din figura 4.7, utilizeaz n
mod extensiv posibilit ile oferite de noua specifica ie UA i ndepline te toate cerin ele acesteia,
att din punct de vedere al model rii datelor ct i al cerin elor de comunica ie. Prin urmare, acesta
este complet independent de platform , ofer un model comun pentru toate datele OPC (DA, A&E,
HDA, etc.) i furnizeaz un sistem extensibil bazat pe tipuri i un model de baz abstract. n ceea ce
prive te cerin ele de comunicare, OPC-ul clasic a fost proiectat pentru a realiza interfa area cu
drivere dar la momentul actual este folosit ca interfa de sistem. Fiabilitatea comunica iei dintre
sistemele distribuite a devenit foarte important i deoarece comunica ia prin re ea nu este fiabil
prin defini ie, robuste ea i toleran a la erori sunt aspecte esen iale. Ca rezultat este posibil
comunica ia prin intranet i internet prin intermediul firewall-urilor i se folosesc specifica ii de
securitate foarte stricte precum i acces controlat.
Nivelul superior din figura 4.7 este reprezentat de clien ii UA care comunic cu serverul UA i
pentru care componentele aflate la nivelele inferioare sunt complet ascunse. Ace ti clien i comunic
cu serverul prin intermediul serviciilor i pot rula pe orice calculator, indiferent dac se afl n
52
4. SERVERUL OPC UA
cadrul aceleia i re ele intranet sau oriunde altundeva pe internet. n plus, clien ii pot opera att la
nivelul MES ct i la nivelul ERP. Dup cum a fost prezentat n capitolul 3, ace ti clien i vor fi
serviciile de baz i serviciile complexe dezvoltate la nivelul intermediar al arhitecturii dezvoltate.
4.3.2 Implementarea
4.3.2.1 Modelele de informa ii
Un model de informa ii [***The OPC Foundation, 2011 e)] furnizeaz un set de noduri
standardizate, de tipuri de referin i de instan e. Acesta define te modul n care trebuie construit
spa iul de adrese al serverului [***The OPC Foundation, 2011 c)]. De-a lungul dezvolt rii s-a
nceput cu modelul de informa ii de baz , apoi s-a implementat modelul de informa ii DI (Device
Integration) [***The OPC Foundation, 2011 j)] i modelul de informa ii IEC 61131-3
[***PLCOpen and the OPC Foundation, 2011] dezvoltat de c tre organiza ia PLCOpen. n
documenta ia [***PLCOpen and the OPC Foundation, 2011] sunt specificate patru situa ii de
utilizare diferite pentru folosirea unui model de informa ii: observare (citirea sau monitorizarea
datelor), control (asocierea de valori/date variabilelor), inginerie (scrierea de programe) i service.
Pentru exemplificare se vor descrie n continuare modelele de informa ii dezvoltate i implementate
pentru serverul agregator folosit n cadrul aplica iei descrise n capitolul 6 (n total sunt patru modele
de informa ii, prezentate n figura 4.8). La nivelul superior al ierarhiei se afl modelul de informa ii
de baz , care este deja implementat n obiectul NodeManagerRoot al clasei UAServer furnizate de
Prosys [***Prosys Java UA SDK, 2011]. Celelalte trei modele de informa ii au fost implementate n
cadrul acestei lucr ri. Urm torul model de informa ii, situat pe cel de-al doilea nivel, prezint
tipurile din specifica ia OPC UA Device Integration [Grossmann D., 2008]. Se poate observa c n
mare parte acesta con ine tipuri de obiecte simple i complexe. Cel de-al treilea nivel expune tipurile
de obiecte pentru standardul IEC 61131-3. Pentru a evita conflictele de nume cu termenii OPC UA,
este folosit prefixul Ctrl pentru dispozitivele de control mpreun cu cei mai mul i termeni ai acestui
model de informa ii. De exemplu, CtrlConfigurationType reprezint un dispozitiv de control
complet programat i monitorizat care furnizeaz acces la toate datele uneia sau mai multor
configura ii IEC 61131-3. Desigur, serverul poate prezenta configura ii incomplete, de exemplu n
timpul monitoriz rii, sau pur i simplu pentru c nu trebuie conferit acces din exterior asupra tuturor
datelor. La acest nivel au fost introduse mai multe elemente care sunt men ionate n standardul IEC
61131-3 dar care nu sunt incluse n modelul de informa ii (de exemplu CtrlFCType, care reprezint
tipul de func ie). n documenta ia [***PLCOpen and the OPC Foundation, 2011] este specificat
faptul c este permis extinderea dar nu eliminarea componentelor tipurilor de obiecte standard.
n final, cel de-al patrulea nivel con ine modelul de informa ii definit special pentru linia flexibil de
fabrica ie. Acesta poate fi denumit FMS sau FMS 200 deoarece con ine informa ii specifice
sistemului de fabrica ie flexibil din laborator ct i al automatelor programabile folosite de c tre
acesta. Ca rezultat, acest model de informa ii con ine tipuri de obiecte complexe pentru toate sta iile
(de exemplu ScrewFittingStationType tipul sta iei de asamblare de uruburi), pentru toate tipurile
de procesor folosite de dispozitivele de control (automate programabile Siemens) i pentru
componentele programelor (OB organization blocks blocuri de organizare n cazul automatelor
Siemens). n plus acesta con ine tipuri de variabile pentru cele trei zone de memorie ale unui
automat programabil (intrare, ie ire i memorie intern ).
53
4. SERVERUL OPC UA
nafara tipurilor de obiecte reprezentate n figura 4.8 au mai fost definite noi tipuri de referin (care
sunt reprezentate de asemenea ca noduri n spa iul de adrese). Cteva dintre cele mai folosite tipuri
de referin sunt: HasInputVar, HasOutputVar, HasInOutVar, HasLocalVar, HasExternalVar (toate
sunt referin e ierarhice) sau With (care este o referin non-ierarhic i care este folosit pentru a
exprima task-ul n interiorul c ruia este executat un program).
Fig. 4.8. Modele de informa ie implementate n server.
4.3.2.2 Spa iul de adrese

Spa iul de adrese este considerat a fi cel mai important concept n specifica ia OPC UA, prin urmare
toate celelalte blocuri func ionale trebuie construite pe baza acestuia [Huiming L., 2010].
Elementele de baz ale spa iului de adrese sunt nodurile i referin ele care definesc rela iile cu
celelalte noduri [***The OPC Foundation, 2011 c)]. Fiecare nod are atribute care sunt determinate
de tipul s u. Totu i exist cteva atribute comune tuturor nodurilor, precum: NodeId (valoarea sa
trebuie sa fie unic n spa iul de adrese), NodeClass, BrowseName, etc. Exist un nod de baz
abstract i toate celelalte noduri sunt derivate din acest nod de baz , precum: ObjectType, Object,
ReferenceType, VariableType, Variable, Method sau View. Prin intermediul referin elor toate
nodurile spa iului de adrese sunt organizate ntr-o re ea [Lu H., 2010]. n interiorul spa iul de adrese
nu poate exista nici un nod care s nu fie conectat la cel pu in un alt nod. Referin ele nu pot fi
accesate direct, clientul doar navigheaz prin intermediul lor n spa iul de adrese de la un nod surs
la un nod int . Cel mai important tip de nod din spa iul de adrese este nodul obiect, care
organizeaz alte obiecte, variabile i metode i care de asemenea genereaz evenimente. Variabilele
reprezint practic atribute tip de dat ale obiectelor. Acestea au o valoare, o unitate de m sur i un
54
4. SERVERUL OPC UA
moment de timp la care a fost nregistrat acea valoare. Pe de alt parte metodele pot fi apelate de
clien i, ndeplinesc o anumit ac iune i returneaz una sau mai multe valori.
n continuare aten ia se va ndrepta c tre particularit ile implementate n spa iul de adrese al
serverului agregator. n primul rnd, pe lng cele trei reguli de modelare definite de specifica ie
(Mandatory, Optional i ExposesItsArray) a fost definit o a patra regul de modelare pentru
instan ele de declara ie, numit Cardinality i care are un NamingRule cu valoarea 0-N. Aceast
regul de modelare este folosit de mai multe instan e de declara ie din modelul de informa ii IEC
61131-3 i specific faptul c o instan a unui tip de obiect complex care con ine o astfel de instan
de declara ie poate face referire la orice num r de obiecte de acel tip.
O alt particularitate este modul n care sunt afi ate variabilele analogice n spa iul de adrese al
serverului agregator (figura 4.9). Variabila AnalogInput1 con ine valoarea i are alte patru
propriet i: adres fizic , unitate de m sur i valorile minime i maxime ale domeniului. n acest fel
clientul poate s citeasc nu doar valoarea ci i informa ii adi ionale importante cu privire la
semnifica ia i posibilele valori ale variabilelor. Pe de alt parte variabilele booleene au doar prima
proprietate dintre cele patru afi ate n figura 4.9.
Fig. 4.9. Reprezentarea unei intr ri analogice n spa iul de adrese.
Pentru exemplificare se prezint n figura 4.10 spa iul de adrese corespunz tor sta iei de montare a
uruburilor, care face parte din linia flexibil men ionat anterior.
Structura spa iului de adrese corespunde modelelor de informa ie descrise anterior. Un avantaj al
standardului OPC UA este faptul c pot fi ad ugate oricnd noduri n spa iul de adrese care nu se
sesc n ierarhiile de tipuri. Nodurile din interiorul dreptunghiului punctat au fost ad ugate datorit
func iei speciale realizate de aceast sta ie i nu apar in nici unui tip complex (ele nu sunt incluse n
nici un model de informa ii).
n plus, figura 4.10 nu prezint propriet ile variabilelor de intrare i de ie ire men ionate mai sus,
dar ele au fost incluse n spa iul de adrese.
Practic dintre cele patru cazuri de utilizare posibile pentru un server OPC UA, serverele UA
dezvoltate n cadrul lucr rii le implementeaz pe primele dou , i anume observare i control. Cazul
de observare este suportat prin intermediul numeroaselor variabile din spa iul de adrese, cu ajutorul
rora un client poate monitoriza toate sta iile liniei flexibile n timp real.
Pe de alt parte, cazul de control este suportat att prin intermediul variabilelor ct i prin
intermediul metodelor. Clientul poate atribui valori direct variabilelor (doar acelor variabile care
permit suprascrierea; variabilele de intrare pot fi doar citite) sau poate apela metode care execut o
anumit ac iune n cadrul sta iei.
Mai multe detalii referitoare la spa iul de adrese vor fi furnizate n sec iunea 4.4 mpreun cu
algoritmii de generare automat a nodurilor UA.
55
4. SERVERUL OPC UA
Fig. 4.10. Spa iul de adrese corespunz tor sta iei de asamblare a uruburilor.
4.3.2.3 Comunica ia cu serverul COM

Unul dintre aspectele majore implementate n server-ul UA l reprezint comunicarea cu serverul
COM (clientul COM integrat). Pentru stabilirea conexiunii s-a folosit SDK-ul open source
JEasyOPC [***JEasyOPC, 2011].
Exist dou alternative prin care clientul clasic (construit n interiorul serverului UA agregator)
poate citi valori de la serverul COM:
clientul se aboneaz la variabile i este notificat cnd apare o schimbare;
clientul decide singur cnd vrea s citeasc valorile variabilelor.
n faza de testare s-a determinat c prima solu ie poate conduce la probleme atunci cnd sunt
monitorizate multe articole i n special cnd starea lor se schimb cu o frecven mare. n
consecin , variabilele de prioritate nalt (de exemplu cele asociate alarmelor) sunt citite prin
intermediul primei variante pentru a evita orice ntrziere suplimentar , iar restul variabilelor sunt
citite prin cea de-a doua variant . Pentru cel de-al doilea caz s-a decis crearea a cte unui task (fir de
execu ie) diferit pentru fiecare linie flexibil , task care este executat periodic la un interval de timp
56
4. SERVERUL OPC UA
de 200ms. Fiecare task cite te articolele de la serverul COM, actualizeaz valorile variabilelor din
spa iul de adrese i apoi realizeaz scrierile corespunz toare modific rilor realizate de clien ii OPC
UA asupra valorilor variabilelor. Pe lng aceste opera ii sunt executate opera ii de scriere
suplimentare atunci cnd clien ii OPC UA apeleaz diverse metode UA.
4.3.2.4 Securitatea
n ultimii ani, securitatea a devenit o problem prioritar pentru tehnologia de automatizare [Leitner
S.H., 2006]. Acest lucru se datoreaz faptului c aplica iile de automatizare sunt combinate i
interconectate cu re elele de la nivelul de ntreprindere [Renjie H., 2010]. n astfel de situa ii
problemele de securitate pot cauza pagube importante pentru companii [***The OPC Foundation,
2011 b)], cel mai bun exemplu fiind piramida de automatizare unde programele MES i ERP sunt
interconectate i unde problemele de securitate pot cauza pagube severe pentru companii.
n continuare sunt descrise aspectele de securitate implementate pentru serverele dezvoltate. n
primul rnd, serverul trebuie s defineasc un certificat al instan ei de aplica ie, care este folosit de
aplica iile cu care comunic , de obicei clien ii UA, pentru validarea serverului. Certificatele pot fi
auto-semnate sau semnate de autoritatea de certificare (n cazul serverului agregator se folosesc
certificate auto-semnate). Figura 4.11 ilustreaz aceast situa ie.
Fig. 4.11. Modelul de ncredere direct .
Acest certificat con ine caracteristici precum: numele aplica iei, limba, aplica ia i URI-ul (Uniform
Resource Identifier) produsului. Ace ti patru parametrii reprezint de fapt descrierea aplica iei care
este folosit cnd certificatul aplica iei este creat.
Mai nti este generat o cheie privat , apoi serverul folose te aceast cheie privat i certificatul
pentru a crea un simbol (token) secret care va fi trimis clientului. Clientul folose te certificatul sau
mai exact cheia public situat n interiorul acestuia pentru a decripta simbolul, validnd astfel
serverul.
Cel lalt aspect al problemelor de securitate este de a valida certificatele furnizate de c tre clien ii
care ncearc s stabileasc o conexiune cu serverul. n acest sens s-a folosit validatorul PKI bazat
pe fi iere i furnizat de SDK-ul UA de la Prosys i s-a definit un ascult ror (listener) de validare,
care este apelat de fiecare dat cnd un client ncearc s stabileasc o conexiune. Aceast metoda
testeaz parametrul passedChecks i pe baza rezultatului decide dac accept sau respinge
certificatul.
57
4. SERVERUL OPC UA
4.3.3 Testarea performan ei solu iei bazate pe software special de adaptare

Dup cum a fost descris n sec iunea 4.3.1, serverul agregator dezvoltat pentru aplica ia bazat pe
linia flexibil din laborator folose te solu ia bazat pe un software special de adaptare care introduce
un server OPC clasic ntre dispozitive i serverul UA. Deoarece aceast solu ie poate duce la
ntrzieri n comunica ie, s-au dezvoltat dou teste de performan .
4.3.3.1 Testul ciclu
Primul test de performan a fost proiectat pentru a evalua viteza i capacitatea de reac ie a
conexiunii dintre serverul UA i dispozitivele de control i este ilustrat n figura 4.12. Acest test este
destinat primei variante de comunica ie descrise n sec iunea 4.3.2.3, care este folosit n cazul
variabilelor de prioritate nalt . Exist dou variabile (Var1 i Var2 care sunt prefixate cu c n
interiorul server-ului clasic i cu p n interiorul automatului programabil care a fost ales ca entitate
reprezentativ a dispozitivelor de control) care sunt introduse n spa iul de adrese al serverului UA i
al serverului clasic i la nivelul automatului programabil unde valoarea variabilei Var1 este asociat
variabilei Var2. Conexiunea dintre serverul UA i serverul clasic este realizat prin intermediul unui
client OPC clasic construit n interiorul serverului UA. Cnd este asociat o nou valoare variabilei
Var1, n primul pas aceast valoarea este asociat variabilei cVar1. n timpul celui de-al doilea pas
aceast nou valoare este trimis automatului programabil i este asociat variabilei pVar2. n
consecin , n cel de-al treilea pas, noua valoare a celei de-a doua variabile va fi asociat variabilei
cVar2. n final, deoarece clientul clasic din interiorul serverului UA este abonat la cVar2, acesta va
recep iona noua valoare pe care apoi o va asocia variabilei UA denumit Var2. Timpul mediu
necesar acestui test a fost de 101.2 8.63 ms. Acest lucru demonstreaz faptul c de i este necesar
un server clasic care intervine ca entitate de comunica ie intermediar , comunica ia este rapid i
modific rile de la nivelul dispozitivelor sunt reflectate imediat la nivelul serverului UA.
Fig. 4.12. Testul ciclu.
58
4. SERVERUL OPC UA
4.3.3.2 Testul alarm

Cel de-al doilea test a fost proiectat pe baza scenariului de test descris anterior i este destinat
serviciilor software care efectueaz controlul i monitorizarea prelucr rii comenzilor (acest tip de
serviciu complex va fi detaliat n capitolul urm tor). Scopul este de a determina ct de rapid poate s
reac ioneze acest serviciu la o alarm care este generat la nivelul dispozitivelor. Figura 4.13
ilustreaz scenariul de test (structura existent sub serverul UA este aceea i ca i n cazul testului
anterior). Mai nti serviciul complex se aboneaz la variabila Var2, dup care apeleaz serviciul
WriteVar pentru a asocia o nou valoare variabilei Var1 (pasul 1) i WriteVar scrie aceast nou
valoare n interiorul spa iului de adrese (pasul 2). Ulterior, pa ii 3-6 sunt identici cu pa ii 1-4 din
figura 4.12 i n final, la pasul 7, serviciul complex este notificat referitor la modificarea valorii
variabilei Var2. Timpul mediu necesar pentru acest test de alarm a fost de 128.2 13.4ms ceea ce
demonstreaz faptul c arhitectura este agil i ntr-un interval de timp scurt serviciul complex este
capabil s apeleze un serviciu special care gestioneaz eroarea. n realitate alarmele de obicei nu
apar datorit unei ac iuni efectuate de unul dintre servicii ci datorit erorilor care apar la nivelul
dispozitivelor i n acest caz timpul de reac ie este chiar mai scurt deoarece doar pa ii 5-7 trebuie
parcur i.
Fig. 4.13. Testul alarm .
4.4 GENERAREA AUTOMATA A SPA IULUI DE ADRESE

4.4.1 Introducere
Serverele OPC UA complet func ionale con in mii de noduri pentru a putea furniza clien ilor toate
informa iile de care au nevoie. Acesta este motivul pentru care s-a hot rt implementarea unui mod
eficient de generare a spa iului de adrese, care s faciliteze de asemenea o mentenan mai u oar .
n continuare va fi prezentat dezvoltarea unui algoritm generalizat care permite generarea
automat , i deci eficient , a spa iului de adrese al unui server OPC UA [Grbea A., 2012 a)]. Pentru
algoritmii descri i se poate folosi orice tip de sistem de stocare a datelor (n cazul de fa s-a ales un
sistem rela ional de gestionare de baze de date).
4.4.2 Procedura de start a serverului OPC UA
n aceast sec iune va fi descris procedura de start a unui server UA astfel nct s poat fi
identifica i pa ii specifici care sunt rezolva i prin algoritmi. Figura 4.14 prezint n partea stng
59
4. SERVERUL OPC UA
principalele etape care trebuie parcurse iar n partea dreapta sunt prezentate ac iunile detaliate ale
etapei de generare a spa iului de adrese [Grbea A., 2011 a)].
Fig. 4.14. Etapele de creare a unui server UA.
Primul pas care trebuie parcurs este acela de a genera un validator de certificate. Acesta este folosit
de c tre server pentru a verifica certificatele clien ilor care doresc s se conecteze la server. Dup
aceea serverul trebuie s genereze un certificat care va fi folosit de clien i pentru validarea
serverului. Acesta este realizat n pa ii doi i trei. Mai nti este generat o descriere a aplica iei i
apoi o identitate a aplica iei (certificatul). Ace ti primi trei pa i fac parte din noile standarde de
securitate introduse n specifica ia UA.
Apoi trebuie setate propriet ile serverului: portul, numele serverului, adresele IP prin intermediul
rora acesta poate fi accesat precum i serverul de identificare (pasul 4). Dup aceea, n cursul
pasului 5, serverul este ini ializat i spa iul de adrese este generat.
Primele dou activit i, 5.1 i 5.2, afi ate n dreptunghiul din partea dreapta reprezint pa i
preliminari. n timpul tuturor celorlalte activit i sunt ad ugate noduri i/sau referin e n cadrul
spa iul de adrese.
Este important de observat faptul c toate nodurile generate n timpul activit ii de creare a spa iului
de adrese sunt stocate in Map-uri (mai precis HashMap-uri) ca perechi cheie-valoare. Cheia fiec rui
obiect este o variabil de tip ir de caractere compus astfel: namespaceindex_NodeId (adic indexul
spa iului de nume urmat de NodeId-ul nodului). NodeId-ul fiecarui nod este unic n spa iul s u de
nume i ca rezultat combina ia index al spa iului de nume-NodeId este unic n spa iul de adrese.
Exist dou motive pentru care este important s se stocheze toate nodurile n interiorul acestor
Map-uri: nodurile sunt necesare n timpul gener rii spa iului de adrese (de ex. pentru a preciza tipul
i nodul p rinte) i anumite atribute trebuie s fie accesate i schimbate n timpul func ion rii
ulterioare a serverului, fie din cauza ac iunilor efectuate de c tre clien i sau doar pentru c valorile
dispozitivelor modelate n spa iul de adrese sunt schimbate (de ex. atributul valoare al nodurilor
variabil ).
60
4. SERVERUL OPC UA
Este important de re inut faptul c nodurile care au clase de noduri diferite trebuie s fie ad ugate
ntr-o ordine specific n spa iul de adrese i chiar i nodurile care au aceea i clas de noduri nu pot
fi ad ugate n spa iul de adrese ntr-o ordine aleatoare.
Obiectele NodeManager trebuie create nainte de a ncepe definirea nodurilor de diferite clase de
noduri (pasul 5.3). Exist un NodeManager care reprezint r cina ierarhiei, care con ine toate
nodurile de baz definite de specifica ia UA. Pe lng acesta utilizatorul poate defini oric i
NodeManager-i dore te, fiecare dintre ei avnd un spa iu de nume diferit. Fiecare nod trebuie s
apar in unui NodeManager, justificndu-se astfel crearea sa la nceputul procedurii. De asemenea,
nodurile i referin ele au cte un tip. Din aceast cauz ierarhiile de tipuri (modelele de informa ii)
sunt definite nainte de a crea nodurile propriu-zise. Deoarece tipurile de noduri sunt de asemenea
conectate prin intermediul referin elor, se vor crea mai nti ReferenceTypes (pasul 5.4). Apoi pe
parcursul pa ilor 5.5 i 5.6 sunt definite ObjectTypes (tipuri de obiecte) i VariablesTypes (tipuri de
variabile), att cele simple ct i cele complexe. n specifica ia UA nu exist MethodTypes (tipuri de
metode). Trebuie subliniat faptul c declara iile de instan sunt ad ugate n cursul urm toarelor
activit i, deci dup ce ntreaga ierarhie a tipurilor a fost creat . Fiecare declara ie de instan a unui
supertip este valabil i pentru subtip. n acest caz funda ia OPC a ales o abordare similar celei a
limbajelor de programare orientate pe obiecte, i anume variabilele supertipurilor sunt mo tenite i
astfel nu este nevoie s se copieze codul n subtip. Prin urmare declara iile de instan nu sunt
duplicate n subtip (acest lucru se ntmpl doar dac ele trebuie suprascrise). Pentru a ob ine o
imagine clar a subtipului, clien ii trebuie s solicite declara iile de instan ale supertipurilor.
Acesta a fost aspectul care a permis generarea declara iilor de instan dup ce a fost generat
ntreaga ierarhie de tipuri.
n continuare sunt create nodurile obiect i nodurile variabil (pa ii 5.7 i 5.8). n cursul fiec rei
activit i, declara iile de instan sunt generate naintea nodurilor obi nuite ale clasei respective de
noduri. n final sunt generate nodurile metod i nodurile vedere (pa ii 5.9 i 5.10) i de asemenea
sunt modelate n spa iul de adrese i referin ele suplimentare (pasul 5.11).
Revenind n partea stng a figurii 4.14, se observ c au mai r mas doi pa i de parcurs. n cursul
pasului 6, sunt dezvoltate implement rile metodelor (se va defini un CallListener ad ugat la fiecare
NodeManager: acesta con ine implement rile tuturor nodurilor metod definite n NodeManagerul
respectiv). n final serverul este pornit i clien ii se pot conecta la acesta (pasul 7).
4.4.3 Generarea automat a spa iului de adrese
4.4.3.1 Activit i preliminarii
n partea dreapt a figurii 4.14 sunt afi ate dou activit i preliminare (n pasul de creare a spa iului
de adrese). S-a precizat n sec iunea anterioar faptul c toate nodurile spa iului de adrese vor fi
stocate n obiecte HashMap. Ca rezultat, prima activitate este reprezentat de crearea a apte
HashMap-uri avnd o cheie format din obiecte String i ca valoare se folosesc diferite tipuri de
noduri UA. Cea de-a doua activitate este de a popula aceste map-uri cu nodurile din modelul de
informa ii de baz , adic din versiunea de baz a spa iului de adrese, noduri care apar in
NodeManager-ului r cin . Aceast activitate este foarte important deoarece utilizatorii vor defini
noduri care vor fi conectate la nodurile din modelul de informa ii de baz i vor folosi referin e care
de asemenea apar in aceluia i model de informa ii. Dac acest pas nu este realizat corect, unele
dintre nodurile definite de utilizator nu vor fi ad ugate corect n spa iul de adrese.
61
4. SERVERUL OPC UA
Suplimentar se desf oar o a treia activitate preliminar , care nu a fost men ionat n figura 4.14
deoarece nu apar ine procedurii de generare a spa iului de adrese, dar care joaca un rol important n
cazul algoritmilor dezvolta i. Aceasta se refer la stabilirea unei conexiuni cu sursa de date.
4.4.3.2 Tipuri de noduri
Tipurile de noduri reprezint baza modelelor de informa ii incluse n serverul UA. n continuare vor
fi descrise cele mai importante trei tipuri de noduri i anume: ObjectType, VariableType i
ReferenceType (figura 4.15 prezint conven iile de modelare general acceptate [Mahnke W., 2009]).
ReferenceTypes sunt folosite pentru a reprezenta semantica referin elor. Acestea sunt mp ite n
dou grupuri i anume referin e ierarhice i referin e non-ierarhice. Referin ele ierarhice sunt n
principal folosite pentru a organiza spa iul de adrese i reflect clasificarea spa ial i logic a
dispozitivelor. Spre deosebire de ierarhiile ObjectType i VariableType, exist deja o ierarhie de
tipuri n ceea ce prive te ReferenceTypes dar utilizatorul poate decide oricnd faptul c are nevoie de
noi referin e, cu noi semantici.
Fig. 4.15. Tipuri de noduri.
n continuare va fi descris algoritmul folosit pentru a genera ierarhia tipurilor de referin

(algoritmul 4.1). Deoarece acest algoritm este foarte asem tor cu cele pentru generarea tipurilor
de obiecte i a tipurilor de variabile, acestea din urm nu vor fi prezentate.
Se subliniaz faptul c tipurile de referin
i n general toate nodurile nu pot fi ad ugate ntr-o
ordine aleatoare n spa iul de adrese, deoarece n acest caz ar putea ap rea situa ii n care ele trebuie
conectate la noduri care nu sunt nc definite. n plus, nu se poate presupune faptul c nodurile sunt
introduse n ordinea corect n baza de date i c aceast ordine asigur o generare corect a
spa iului de adrese. Prin urmare este responsabilitatea algoritmului s asigure c nodurile sunt
ad ugate n ordinea corect n spa iul de adrese. Astfel, ini ial se definesc dou tablouri de tipuri de
referin . Primul va fi folosit pentru a stoca datele tipurilor de referin care trebuie ad ugate n
spa iul de adrese (RT), iar al doilea pentru a stoca tipuri de referin deja ad ugate n spa iul de
adrese (RT_AdaugateUA). Apoi tipurile de referin conectate la tipurile de referin de baz sunt
citite din baza de date (n fiecare algoritm ac iunile de citire realizeaz interog ri asupra bazei de
date). n continuare se ini ializeaz o bucl n interiorul c reia fiecare itera ie gestioneaz un tip de
referin . Se determin NodeManager-ul tipului de referin curent RT[contor] (nm), nodul p rinte
(pn) i referin a prin intermediul c reia acest nod va fi conectat la nodul p rinte (r). n continuare
sunt determinate alte propriet i importante, precum BrowseName (bn), Symmetry (si) i dac tipul
de referin respectiv este abstract sau nu (ab). Apoi se creeaz un nod UA pentru tipul de referin
curent i se seteaz toate propriet ile determinate anterior. n cele din urm tipul de referin este
ad ugat n spa iul de adrese i la map-ul de tipuri de referin . Ac iunea final din interiorul buclei
for este de a ad uga tipul de referin la un grup de referin e care vor fi folosite n pasul urm tor al
algoritmului. Dup finalizarea primei bucle for au fost ad ugate n spa iul de adrese toate tipurile de
referin conectate la cele de baz . n plus, grupul de referin e alc tuit n timpul buclei for este
folosit pentru a interoga baza de date i pentru a determina tipurile de referin conectate la tipurile
62
4. SERVERUL OPC UA
de referin con inute n grup. Astfel se garanteaz faptul c aceste noduri se pot ad uga spa iului de
adrese deoarece nodurile lor p rinte au fost deja create. Dup ce au fost citite aceste tipuri de
referin , grupul, care a fost stabilit anterior, este resetat pentru a preg ti generarea unui nou grup.
Apoi aceste noduri sunt ad ugate spa iului de adrese i un nou grup este stabilit, grup care va fi
folosit la urm toarea interogare. n acest fel se continu ad ugarea grupurilor la ierarhia tipurilor de
referin pn cnd nu mai exist noduri de extras din baza de date. Acesta este motivul pentru care
dup prima bucl for se utilizeaz o bucla while cu un num r nedeterminat de itera ii. Fiecare itera ie
a buclei while con ine o bucla for similar cu cea folosit anterior buclei while.
n consecin , prin intermediul acestui algoritm ierarhia de referin e va fi generat corect, indiferent
de ct de complicat este, respectiv indiferent de ct de multe nivele con ine (bucla while poate
executa n general zeci de itera ii pn la finalizarea execu iei acesteia).
Prima bucl for nu a fost inclus n buclele for executate n interiorul buclei while deoarece tipurile
de referin ad ugate prin intermediul primei bucle for sunt legate de tipurile de referin de baz ,
care nu sunt reprezentate ca rnduri n tabelul corespunz tor din baza de date.
Prin urmare ele trebuie tratate diferit, de i aparent func iile reprezentate n pseudo-cod sunt acelea i.
Alte detalii referitoare la acest aspect vor fi descrise n sec iunea 4.4.3.7 mpreun cu structura bazei
de date.
Algoritmul 4.1. Tipuri de referin
Definire tablou tipuri de referinte RT
Definire tablou tipuri de referinte RT_AdaugateUA
RT = citire tipuri de referinte conectate la tipurile de referinta de baza
Seteaza n egal cu numarul de tipuri referinte citite
For contor = 0 pana la n-1 do
nm = obtine NodeManager pentru tip de referinta RT[contor]
pn = obtine ParentNode pentru tip de referinta RT[contor]
r = obtine Referinta pentru tip de referinta RT[contor]
bn= obtine BrowseName pentru tip de referinta RT[contor]
si = obtine Symmetry pentru tip de referinta RT[contor]
ab = obtine Abstract pentru tip de referinta RT[contor]
RTnodUA = creeaza un nod UA tip de referinta
Seteaza proprietati RtnodUA
Adauga RTnodUA la spatiul de adrese UA
Adauga RTnodUA la tabloul RT_AdaugateUA
End for
Do while tabloul RT_AdaugateUA contine cel putin un element
RT = citire tipuri de referinte conectate la tipurile de referinta din
tabloul RT_AdaugateUA
Reseteaza tablou RT_AdaugateUA
nm = obtine NodeManager pentru tip de referinta RT[contor]
pn = obtine ParentNode pentru tip de referinta RT[contor]
r = obtine Referinta pentru tip de referinta RT[contor]
bn= obtine BrowseName pentru tip de referinta RT[contor]
si = obtine Simetrie pentru tip de referinta RT[contor]
ab = obtine Abstract pentru tip de referinta RT[contor]
RTnodUA = creeaza un nod UA tip de referinta
Seteaza proprietati RTnodUA
Adauga RTnodUA la spatiul de adrese
Adauga RTnodUA la tabloul RT_AdaugateUA
End for
63
4. SERVERUL OPC UA
End while
4.4.3.3 Noduri obiect i variabil

Aceste dou clase de noduri, prezentate n figura 4.16, sunt cele mai importante noduri din spa iul de
adrese, al turi de nodurile metod . Nodurile obiect sunt folosite pentru a structura spa iul de adrese.
Ele nu con in date (pe lng atributele care descriu nodul: displayname i description). De obicei
obiectele sunt folosite pentru a grupa sau organiza variabile, metode i/sau alte obiecte. De i
specifica ia UA nu men ioneaz acest aspect n mod explicit, metodele i variabilele apar in
ntotdeauna unui obiect (sau tip de obiect, daca sunt declara ii de instan ). Valorile obiectelor sunt
expuse prin intermediul variabilelor.
Nodurile variabil sunt folosite pentru a reprezenta o valoare. Fiecare variabil are un tip de dat iar
clien ii pot s citeasc valoarea, s se aboneze la modific rile acesteia i/sau s suprascrie valoarea
ei. Valoarea reprezentat poate fi determinat prin m sur tori sau s reprezinte un parametru de
configurare (metadate suplimentare care descriu nodul).
Fig. 4.16 Noduri obiect i variabil .
n cele ce urmeaz va fi descris algoritmul folosit la generarea ierarhiei nodurilor obiect, algoritm
care este foarte asem tor cu cel pentru generarea nodurilor variabil . Pe lng clasificarea
obiectelor n obiecte simple i complexe, mai exist o clasificare care este foarte important pentru
generarea automat a nodurilor obiect, i anume: noduri care reprezint declara ii de instan
i
noduri obiect comune (obi nuite). Declara iile de instan sunt obiecte (simple sau complexe) care
sunt incluse n ierarhia tipurilor de obiecte, adic ele sunt conectate direct sau indirect la un tip de
obiect complex.
Principala diferen dintre obiectele comune i declara iile de instan este faptul c cele din urm
trebuie s fac referire la cel pu in o regul de modelare (ModellingRule). Acesta este motivul pentru
care obiectele comune i declara iile de instan sunt tratate separat n algoritmul 4.2.
Algoritmul ncepe prin citirea declara iilor de instan conectate la nodurile de baz . Se prezint
doar diferen ele fa de algoritmul anterior, de aceea pseudo-codul nu con ine selectarea
nodemanager-ului, a nodului p rinte, a referin ei principale i a propriet ilor nodului. n primul rnd
fiecare obiect are un tip, care trebuie specificat la crearea sa (tn). n al doilea rnd trebuie ad ugate
regulile de modelare care sunt referite de c tre declara iile de instan (se determin regulile de
modelare ale declara iei de instan MR, i se adaug o referin ntre declara ia de instan
OID[contor] i regula de modelare MR[contor2]). n mod normal se face referire la o singur
regul de modelare (obligatoriu sau op ional), dar utilizatorul poate decide s defineasc mai multe
reguli de modelare i acesta este motivul pentru care s-a ad ugat o bucl suplimentar for n cadrul
algoritmului. La fel ca i n cazul algoritmului anterior, declara iile de instan sunt apoi ad ugate la
spa iul de adrese i la un grup care este folosit n etapele urm toare ale algoritmului. Strategia de
baz este aceea i ca i pentru primul algoritm, adic ini ial sunt ad ugate n spa iul de adrese
declara iile de instan conectate la tipurile de obiecte complexe de baz i apoi restul declara iilor
de instan sunt ad ugate n interiorul buclei while.
64
4. SERVERUL OPC UA
n final nodurile obiect comune sunt ad ugate n spa iul de adrese, mai nti obiectele care sunt
conectate la nodurile obiect de baza definite n specifica ia UA i apoi restul nodurilor obiect.
Algoritmul 4.2. Obiecte
Definire tablou obiecte declaratii de instanta OID
Definire tablou obiecte declaratii de instanta OID_AdaugateUA
Definire tablou obiecte comune Ob
Definire tablou obiecte comune Ob_AdaugateUA
Definire tablou reguli de modelare MR
OID = citire obiecte declaratii de instanta conectate la nodurile de baza
Seteaza n egal cu numarul obiectelor citite
...
tn = obtine TypeNode pentru obiectul OID[contor]
...
MR = determin regulile de modelare pentru OID[contor]
Seteaza m egal cu numarul regulilor de modelare
For contor2 = 0 pana la m-1 do
Adauga referin
ntre declara ia de instan
OID[contor] i regula
de modelare MR[contor2]
End for
OIDnodUA = creeaza un nod UA obiect
Seteaza proprietati OIDnodUA
Adauga OIDnodUA la spatiul de adrese UA
Adauga OIDnodUA la tabloul OID_AdaugateUA
End for
Do while tabloul OID_AdaugateUA contine cel putin un element
OID = citire obiecte conectate la tabloul OID_AdaugateUA
Reseteaza tablou OID_AdaugateUA
...
tn = obtine TypeNode pentru OID[contor]
...
MR = determin regulile de modelare pentru OID[contor]
Seteaza m egal cu numarul regulilor de modelare
Adauga referin
ntre declara ia de instan
OID[contor] i
regula de modelare MR[contor2]
End for
OIDnodUA = creeaza un nod UA obiect
Seteaza proprietati OIDnodUA
Adauga OIDnodUA la spatiul de adrese
Adauga OIDnodUA la tabloul OID_Adaugate
End for
End while
Ob = citire obiecte comune conectate la nodurile de baza
Seteaza n egal cu numarul obiectelor comune citite
...
tn = obtine TypeNode pentru obiect comun Ob[contor]
...
ObnodUA = creeaza un nod UA obiect comun
Seteaza proprietati ObnodUA
Adauga ObnodUA la spatiul de adrese UA
Adauga ObnodUA la tabloul Ob_AdaugateUA
65
4. SERVERUL OPC UA
End for
Do while tabloul Ob_AdaugateUA contine cel putin un element
Ob = citire obiecte comune conectate la tabloul Ob_AdaugateUA
Reseteaza tablou Ob_AdaugateUA
...
tn = obtine TypeNode pentru obiect comun Ob[contor]
...
ObnodUA = creeaza un nod UA obiect comun
Adauga ObnodUA la spatiul de adrese
Adauga ObnodUA la tabloul Ob_Adaugate
End for
End while
Algoritmul pentru nodurile variabil este foarte asem tor, singur diferen fiind aceea c
variabilele au de asemenea i un tip de dat , care trebuie citit din sursa de date i specificat pentru
nodurile create.
4.4.3.4 Noduri metod
Nodurile metod (figura 4.17) reprezint metode software, adic entit i care pot fi apelate de un
client i care returneaz un rezultat. Pentru fiecare metod trebuie specificate argumentele de intrare
i de ie ire. Metodele au fost introduse n ideea c reprezint elemente de cod care se execut foarte
rapid. n mod normal ele fac parte din structura unui obiect complex sau a unui tip de obiect, ceea ce
nseamn c i metodele pot fi declara ii de instan .
Fig. 4.17. Nod metod .
Algoritmul 4.3 ilustreaz pa ii necesari pentru generarea nodurilor metod . Astfel, nodurile care
reprezint declara ii de instan
i metodele comune trebuie din nou tratate separat. Deoarece
metodele nu pot avea ca nod p rinte alte metode, nu mai este nevoie s se aplice o strategie similar
celei utilizate pentru primii doi algoritmi, adic s se adauge noduri n grupuri succesive. Prin
urmare, declara iile de instan (MID[i]) sunt citite din baza de date i dup ce sunt determinate
propriet ile comune tuturor nodurilor (nodemanager, nod p rinte, referin principal , propriet ile
nodului, etc.), sunt specificate argumentele de intrare i de ie ire. Deoarece, n general, o metod
poate avea mai multe argumente de intrare i de ie ire, acestea sunt stocate n loca ii separate. Ini ial
sunt citite argumentele de intrare (IArg), apoi sunt setate propriet ile fiec rui argument (nume, tip
de dat , descriere, etc.) i n final se seteaz tabloul de argumente de intrare metodei MID[contor].
Dup ce sunt efectuate acelea i opera ii i pentru argumentele de ie ire (OArg), sunt specificate
regulile de modelare referite de c tre metod , la fel ca i pentru declara iile de instan de tip
variabil sau obiect: mai nti acestea sunt citite de la sursa de date i apoi se adaug referin e ntre
nodul metod i regulile de modelare. n final, declara iile de instan sunt ad ugate la spa iul de
adrese.
n cele din urm , sunt ad ugate la spa iul de adrese i metodele comune folosind un algoritm
asem tor, singura diferen fiind faptul c nu au fost precizate reguli de modelare.
66
4. SERVERUL OPC UA
Algoritmul 4.3. Metode

Definire tablou metode de instanta MID
Definire tablou metode comune M
Definire tablou argumente de intrare IArg
Definire tablou argumente de iesire OArg
Definire tablou reguli de modelare MR
MID = citire metode de instanta din baza de date
Seteaza n egal cu numarul metodelor de instanta citite
...
IArg = citire argumente de intrare pentru metoda MID[contor]
Seteaza m egal cu numarul argumentelor de intrare pentru metoda curenta
Seteaza proprietati pentru argumentul IArg[contor2]
End for
Seteaza argumente de intrare pentru metoda MID[contor]
OArg = citire argumente de iesire pentru metoda MID[contor]
Seteaza m egal cu numarul argumentelor de iesire pentru metoda MID[contor]
Seteaza proprietati pentru argumentul OArg[contor2]
End for
Seteaza argumente de iesire pentru metoda MID[contor]
MR = citire reguli de modelare MID[contor]
Seteaza m egal cu numarul regulilor de modelare citite
Adauga referin
ntre nodul metoda MID[contor] si regula de
modelare MR[contor2]
End for
MIDnodUA = creeaza un nod UA metoda
Seteaza proprietati MIDnodUA
Adauga MIDnodUA la spatiul de adrese
End for
M = citire metodele comune din sursa de date
Seteaza n egal cu numarul metodelor comune
For contor = n to n-1
...
End for
n specifica ia UA, nu se precizeaz un mod standardizat pentru realizarea implement rii unei
metode n interiorul unui server OPC UA. Trebuie men ionat faptul c prin intermediul SDK-ului
oferit de Prosys [Hannelius, T., 2008], care a fost folosit la crearea serverului UA, metodele au fost
implementate folosind limbajul Java n interiorul unui CallListener (ascult tor de apeluri de metode)
care este asociat fiec rui NodeManager. Revenind la deosebirea dintre metode comune i declara ii
de instan , trebuie men ionat faptul c n mod normal declara iile de instan nu au o implementare,
doar metodele comune, care sunt referite de obiectele complexe, au i o implementare. Totu i exist
o excep ie, i anume cnd toate instan ele unui tip de obiect complex folosesc aceea i implementare
a unei metode. n acest caz metoda care reprezint o declara ie de instan este implementat i
referit i de obiectele complexe (un mecanism similar metodelor statice din programarea orientat
pe obiecte).
67
4. SERVERUL OPC UA
4.4.3.5 Noduri vedere

Nodurile vedere (figura 4.18) reprezint o alt clas important de noduri UA, deoarece acestea sunt
folosite pentru a restric iona num rul nodurilor i al referin elor vizibile ntr-un spa iu de adrese
mare. Prin utilizarea vederilor, serverul poate asista clien ii n timpul activit ii lor de navigare astfel
nct ace tia s acceseze doar noduri utile activit ii lor (de exemplu, o vedere poate oferi acces
numai la noduri care sunt importante pentru activitatea de mentenan a unor echipamente).
Fig. 4.18. Nod vedere.
n cele ce urmeaz va fi descris algoritmul 4.4 folosit la generarea ierarhiei de noduri vedere.
Nodurile vedere, ca i toate celelalte noduri nu pot fi ad ugate n spa iul de adrese ntr-o ordine
aleatoare, de aceea i ele vor fi ad ugate n grupuri succesive.
Mai nti vor fi citite vederile conectate la vederile de baz (V). Apoi, fiecare nod vedere selectat
(V[contor]) va fi tratat ntr-o itera ie separat a buclei for care urmeaz (determinarea propriet ilor
comune precum nodemanager, parentnode, reference, browsename, displayname, etc. nu este afi at
n algoritm). nainte de a ad uga nodul la spa iul de adrese, sunt setate atributele specifice vederii:
containsnoloops (cnl indic dac nodurile vederii con in sau nu o bucl ), eventnotifier (en indic
dac vederea poate fi utilizat de un client pentru a se abona la evenimente).
n cele din urm vederea este ad ugat la spa iul de adrese i la HashMap-ul corespunz tor.
Ac iunea final este de a ad uga vederea la grupul de vederi ce va fi folosit la pasul urm tor al
algoritmului. A doua jum tate a algoritmului adopt ideile prezentate anterior, adic grupul de
vederi alc tuit n timpul primei bucle for este utilizat pentru a interoga sursa de date i pentru a
determina vederile conectate la vederile con inute n grup. Apoi, grupul este resetat pentru a preg ti
alc tuirea noului grup.
Noile noduri vedere selectate vor fi ad ugate n spa iul de adrese prin intermediul unei bucle for
similare cu cea din prima jum tate a algoritmului. Prin urmare, bucla while va ad uga la spa iul de
adrese toate grupurile de noduri vedere r mase.
Se subliniaz faptul c de obicei va exista doar un singur grup de vederi dar algoritmul trateaz i
cazurile speciale n care noduri vedere sunt ad ugate sub alte noduri vedere.
n urma recomand rilor oferite de Prosys, va exista o ierarhie separat pentru vederi, iar referin a
principal a fiec rui nod vedere este aceea care adaug vederea la aceast ierarhie specific .
Celelalte referin e care indic nodurile vizibile prin intermediul vederilor vor fi ad ugate cu ajutorul
algoritmului descris n sec iunea urm toare.
Algoritmul 4.4. Vederi
Definire tablou V
Definire tablou V_AdaugateUA
V = citire vederi conectate la vederile de baza
Seteaza n egal cu numarul vederilor citite
...
cnl = verifica daca nodurile vederii V[contor] con in sau nu o bucla
en = obtine EventNotifier pentru vederea V[contor]
68
4. SERVERUL OPC UA
VnodUA = creeaza un nod UA vedere

Seteaza proprietati VnodUA
Adauga VnodUA la spatiul de adrese
Adauga VnodUA la tabloul V_AdaugateUA
End for
Do while tabloul V_AdaugateUA contine cel putin un element
V = citire vederi conectate la vederile din tabloul V_AdaugateUA
Reseteaza tablou V_AdaugateUA
...
VnodUA = creeaza un nod UA vedere
Seteaza proprietati VnodUA
Adauga VodUA la spatiul de adrese
Adauga VnodUA la tabloul V_AdaugateUA
End for
End while
4.4.3.6 Referin e suplimentare

n spa iul de adrese al unui server UA nu exist nici o restric ie n ceea ce prive te num rul
referin elor dintre noduri (acesta este unul din avantajele specifica iei UA care permite ad ugarea
nelimitat de informa ii semantice n spa iul de adrese). De exemplu, un dispozitiv poate fi referit de
dou ori n spa iul de adrese, o dat n interiorul unei ierarhii logice de dispozitive i nc o dat n
interiorul unei ierarhii spa iale a dispozitivelor. Acesta este un exemplu banal, dar care subliniaz
faptul c un nod poate fi nod int a dou noduri surs (de fapt pot exista i dou referin e ntre
acelea i dou noduri). Remarcnd acest aspect, este evident c algoritmii descri i anterior nu sunt
suficien i pentru generarea unui spa iu de adrese complet.
De aceea s-a hot rt stabilirea unei referin e principale pentru fiecare nod, referin care este folosit
de algoritmii anteriori pentru a ad uga nodul la spa iu de adrese. Restul referin elor sunt ad ugate
apoi la spa iul de adrese dup ce toate nodurile au fost ad ugate, permi ndu-se astfel ad ugarea lor
ntr-o ordine aleatoare.
n acest caz algoritmul este foarte simplu (algoritmul 4.5): se citesc nodurile surs (sn) i nodurile
int (tn), apoi referin ele dintre ele (r) i n final se adaug referin ele n spa iu de adrese .
Algoritmul 4.5. Referin e
Definire tablou de referinte suplimentare RS
RS = citire referinte suplimentare din sursa de date
Seteaza n egal cu numarul referintelor suplimentare
For contor=0 pana la n-1 do
sn = obtine nodul sursa pentru referinta RS[contor]
tn = obtine nodul tinta pentru referinta RS[contor]
r = obtine referinta care conecteaza nodul sursa si nodul tinta pentru
RS[contor]
Adauga in spatiul de adrese referinta r intre nodul sn si nodul tn
End for
4.4.3.7 Sursa de date

Ca surs de date s-a folosit un sistem de baze de date rela ional (mai precis baza de date MySQL
[***MySQL Database, 2010]). S-a decis utilizarea acestui tip de surs de date deoarece furnizeaz
un mecanism de validare puternic datorit constrngerilor de care dispune (rela ii cheie primar
cheie extern , valori permise, valori implicite). De asemenea, serverul UA dezvoltat pentru linia de
69
4. SERVERUL OPC UA
fabrica ie flexibil , con ine aspecte istorice: date istorice, alarme i evenimente istorice i spa iul de
adrese istoric. Din nou, pentru aceste aspecte, o baz de date rela ional reprezint cea mai bun
alegere. n acest mod, nu doar spa iul de adrese este unul unificat dar de asemenea se folose te o
baz de date unificat unde sunt stocate toate informa iile relevante.
Figura 4.19 prezint structura simplificat a tabelelor din baza de date, structur care va fi folosit n
continuare pentru explicarea unor aspecte interesante (s-au afi at doar coloanele i tabelele necesare
pentru relatarea aspectelor legate de algoritmi).
Liniile continue reprezint rela ii tip cheie extern care au fost impuse n baza de date, n timp ce
liniile punctate n-au fost specificate la crearea tabelelor datorit mai multor motive, ns sunt valide
i trebuie respectate.
n centrul structurii exist un tabel NodeManager care este conectat la toate celelalte tabele care
reprezint noduri UA. Fiecare astfel de tabel trebuie legat de tabelul ReferenceType pentru a
specifica referin a prin care este conectat la nodul p rinte. O astfel de leg tur este reprezentat prin
intermediul liniei punctate dintre tabelul Variable i tabelul ReferenceType. Motivul pentru care
aceast leg tur n-a putut fi impus a fost acela c nici un tip de referin de baz nu este inclus n
tabel. Ca rezultat, valorile coloanei Reference din tabelul Variable pot fi de dou tipuri:
cheie extern reprezentat printr-un num r ntreg (care corespunde coloanei ID_RT) stocat ca
ir de caractere;
ir de caractere de tipul 0ReferenceType (de ex. 0HasComponent).
Fig. 4.19. Structura bazei de date.
Acesta reprezint de asemenea unul din motivele pentru care primele bucle for din algoritmii unu i
doi au fost plasate i executate naintea buclelor for din bucla while.
70
4. SERVERUL OPC UA
Cazul prezentat anterior este doar un exemplu, exist mai multe astfel de leg turi reprezentate prin
linii punctate ntre tabele, precum conexiunea TypeNode care indic faptul c tipul unui nod
variabil poate fi un tip de baz sau unul definit de utilizator, conexiunea ParentNode de tip unu-lamul i care n cazul tabelului variabilelor are partea mul i conectat la tabelul variabilelor iar partea
unu poate fi conectat la unul din tabelele ObjectType/VariableType (dac este declara ie de
instan ) sau la unul din tabelele Object/Variable (dac este un nod variabil obi nuit), sau
conexiunea InstDecl de tip unu-la-mul i care are partea mul i ntotdeauna conectat la tabelul
ModelingRule, iar partea unu poate fi conectat la un tabel obiect, variabil sau metod . n
consecin exist mai multe motive, din cauza c rora conexiunile reprezentate prin linii punctate nu
pot fi impuse ca rela ii de cheie extern n baza de date.
n col ul din dreapta sus este afi at tabelul corespunz tor algoritmului cinci. Coloanele
corespunz toare nodurilor int i surs pot fi conectate de orice alt tabel nod.
n cele din urm trebuie men ionat faptul c spa iul de adrese al unui server UA poate fi foarte u or
schimbat, fie offline sau online. n modul offline, tabelele din baza de date trebuie doar actualizate
(fie direct prin intermediul interog rilor executate asupra bazei de date fie prin intermediul
aplica iilor cu interfa grafic ). Pentru cazul online exist 2 situa ii: administratorul serverului sau
utilizatorul (clientul OPC UA) poate decide s schimbe structura spa iului de adrese (numai dac
serverul permite acest lucru). n ultimul caz, pentru a salva modific rile realizate asupra spa iului de
adrese, la nchiderea serverului, trebuie inclus i un pas de salvare a con inutului spa iului de adrese
n interiorul bazei de date.
Pentru gestionarea mai simpl a unui server OPC UA i pentru editarea spa iului de adrese s-a
realizat o interfa grafic . Dou dintre ferestrele acestei interfe e sunt prezentate n figura 4.20.
Fig. 4.20. Fereastra principal a interfe ei grafice a serverului (stnga) i fereastra utilizat pentru ad ugarea
unui nod nou n spa iul de adrese al serverului (dreapta).
71
4. SERVERUL OPC UA
4.5 REZULTATE
n cadrul lucr rii au fost dezvoltate mai multe servere (agregatoare) UA, dintre care cel mai complex
este cel destinat aplica iei descrise n capitolul 6, care a fost dezvoltat pentru o linie flexibil (FMS
Flexible Manufacturing System). Software-ul KEPServerEx, care a fost furnizat o dat cu linia
flexibil , a fost folosit ca i server clasic COM. S-a folosit modul de simulare al serverului clasic
pentru a testa serverul n conexiune cu mai multe linii flexibile (au fost simulate i alte 3 linii
flexibile [Greppi P., 2010]), garantndu-se astfel operarea arhitecturii ntr-un mediu complex dar i
func ionarea acesteia pn la nivelul dispozitivelor. n sec iunea 4.3.2.3 au fost descrise dou
posibilit i de implementare diferite n ceea ce prive te comunica ia. Dup ce au fost testate ambele
op iuni, s-a descoperit faptul c citirea valorilor la un anumit interval de timp este de aproximativ
patru ori mai eficient n compara ie cu varianta notific rii la apari ia modific rilor. Acest lucru se
datoreaz n special urm toarelor dou aspecte:
serverul UA este notificat prea des despre modific ri atunci cnd articolele la care acesta s-a
abonat i schimb starea cu o frecven mare;
variabilele binare, care apar predominant n spa iul de adrese al serverului, pot fi citite doar
prin elementele de tip cuvnt, care con in 16 bi i.
n acest fel, dac una dintre cele 16 valori se modific , ntregul cuvnt se modific i serverul este
notificat. Acest ultim aspect reprezint un dezavantaj pentru solu ia de abonare dar reprezint un
avantaj pentru cealalt variant , deoarece serverul UA determin starea a pn la 16 variabile binare
diferite printr-o singur opera ie de citire.
Din acest motiv s-a decis ca doar variabilele cu prioritate nalt s fie actualizate prin varianta de
abonare, restul fiind citite periodic la un anumit interval de timp.
n continuare sunt prezentate performan ele maxime ale serverului n ceea ce prive te comunicarea
cu un num r diferit de servere COM, adic timpul de e antionare minim la comunicarea cu acestea
(tabel 4.2).
Tab. 4.2. Performan maxim .
Nr. de linii flexibile

Interval de e antionare minim [ms]
1
10
2
10
3
15
4
30
6
50
8
80
10
120
Pentru una sau dou linii flexibile, intervalul de e antionare minim (intervalul de timp n care este
executat task-ul) este de 10ms. Aceast limit este determinat de KEPServerEx, care nu poate
actualiza elemente cu o rat de scanare cu peioada mai mic de 10 ms. Pentru trei sau mai multe
FMS-uri intervalul de e antionare minim cre te continuu cu num rul de linii flexibile reprezentate n
spa iul de adrese.
Un rol cheie n dezvoltarea rapid i direct a serverului agregator UA a fost ndeplinit generarea
automat a spa iului de adrese care s-a realizat pe baza algoritmilor descri i n sec iunea 4.4.
Utilizarea algoritmilor a permis salvarea unui timp considerabil n condi iile n care spa iul de adrese
al unui server poate con ine peste 1000 de noduri.
Folosind SDK-ul Java furnizat de Prosys, fiecare nod al spa iului de adrese este programat n cod
Java. De-a lungul fazei de dezvoltare s-a determinat un num r mediu de linii de cod (9) folosit la
generarea unui nod. Prin utilizarea algoritmilor de mai sus, num rul de linii de cod este aproximativ
72
4. SERVERUL OPC UA
egal cu 2400. Astfel, prin utilizarea algoritmilor, odat ce codul de generare a spa iului de adrese a
fost scris, num rul de linii de cod va fi ntotdeauna acela i indiferent de num rul nodurilor generate.
Cel mai mare avantaj este acela de a putea folosi acela i cod pentru toate serverele UA (doar
con inutul bazei de date trebuie modificat). Figura 4.21 prezint evolu ia num rului de linii de cod n
func ie de num rul de noduri din spa iul de adrese. Cele dou grafice se intersecteaz la aproximativ
267 de noduri, punct n care num rul de linii de cod este aproximativ egal cu 2400.
S-au realizat 3 teste pentru a estima mbun
irile aduse prin utilizarea algoritmilor, precum i
timpul economisit. Toate cele trei teste au constat n generarea unui spa iu de adrese pentru un
server OPC UA. n timpul primului scenariu de test, care a fost preluat din [Mahnke W., 2009], a
fost generat spa iul de adrese al unei instala ii complexe de aer condi ionat (70 noduri). n cel de-al
doilea scenariu de test s-a generat spa iul de adrese corespunz tor sistemului de transport al liniei
flexibile din laborator (100 de noduri). n cadrul ultimului scenariu s-a generat spa iul de adrese al
sta iei patru a liniei flexibile (200 noduri). Tabelul 4.3 prezint rezultatele fazei de testare.
Fig. 4.21. Num r de linii de cod utilizate la generarea spa iului de adrese.
n toate cele 3 cazuri, spa iul de adrese a fost generat att prin metoda clasic (indicat de Prosys)
ct i prin intermediul algoritmilor (insernd date n baza de date). Timpii afi i n tabel sunt
sura i n minute i deoarece num rul nodurilor variaz de la un scenariu la altul s-a calculat de
asemenea i timpul normalizat corespunz tor unui spa iu de adrese de 100 de noduri. Toate cele 3
situa ii au indicat o mbun ire important n ceea ce prive te timpul de dezvoltare (o accelerare de
aproximativ 2.2-2.3x).
Tab. 4.3. mbun
Scenariu
de test
Aer
condi ionat
Band de
transport
Sta ia 4
73
iri ale timpului de dezvoltare.
Num r
de
noduri
70
Timp
Timp norm.
algoritmi
365
100
200
Timpi cu
algoritm
Timp norm.
cu algoritmi
mbun
ire
(accelerare)
algoritmi
521
157
224
2.32
495
495
217
217
2.28
958
479
430
215
2.23
4. SERVERUL OPC UA
n continuare s-a ncercat estimarea mbun irilor datorate algoritmilor n timpul fazei de
ntre inere, adic atunci cnd con inutul bazei de date trebuie schimbat. S-au utilizat cele trei scenarii
de test descrise mai sus i s-au modificat/eliminat 10 noduri din spa iu de adrese. Tabelul 4.4
afi eaz rezultatele testelor (din nou timpii sunt m sura i n minute). De i rezultatele nu sunt la fel
de impresionante ca cele de dinainte, se poate observa, din nou, o accelerare important de
aproximativ 1.4-1.6x.
Astfel, odat ce algoritmii au fost implementa i, att duratele opera iilor de dezvoltare ct i duratele
activit il ilor de ntre inere sunt reduse semnificativ. n plus, prin utilizarea aplica iilor GUI
(Graphical User Interface), nu vor fi necesare deprinderi de programare la setarea spa iului de
adrese.
Tab. 4.4. mbun
iri ale timpului de ntre inere.
Secenariu de test
Aer condi ionat
Band transportatoare
Sta ia 4
Timpul f
algoritmi
34
32
35
Timpul cu algoritmi
21
22
24
mbun
ire
(accelerare)
1.62
1.45
1.46
4.6 CONCLUZII
Funda ia OPC furnizeaz standarde pentru schimbul de date n automatizarea industrial . Aceasta
include specifica ia OPC DA pentru date curente, specifica ia pentru alarme si evenimente (OPC
A&E) ct i specifica ia pentru datele istorice (OPC HDA). Toate specifica iile men ionate se bazau
n trecut pe tehnologia COM/DCOM. Un prim pas spre stadiul actual a fost specifica ia OPC XMLDA, care folosea servicii web.
Pornind de la OPC XML-DA funda ia OPC a creat un nou standard numit Unified Architecture
(UA). Cu ajutorul acestei noi specifica ii transportul poate fi realizat fie folosind serviciile web prin
intermediul standardelor SOAP i HTTP sau un protocol TCP binar i optimizat pentru a realiza o
comunica ie rapid . Comunica ia realizat prin intermediul specifica iei OPC UA este independent
de platform , de nalt performan , scalabil i fiabil .
Trecerea de la tehnologia Microsoft COM/DCOM la stadiul actual i la protocoalele de transport
independente de platform permite aplica iilor OPC UA s ruleze pe dispozitive i controlere
inteligente precum i n sisteme DCS i SCADA i chiar la nivelul ntreprinderii n interiorul
sistemelor MES i ERP.
nafara transportului, cea de-a doua mare realizare a noului standard este reprezentat de modelarea
informa iei. OPC UA unific func ionalit ile diferitelor specifica ii ale OPC-ului clasic prin
expunerea datelor curente, a notific rilor de evenimente, ct i a datelor istorice ntr-un singur spa iu
de adrese.
Se ofer suplimentar un model de informa ii bogat i extensibil folosind concepte orientate pe
obiect, permi nd ca att metadatele ct i datele complexe s fie expuse. Mecanismele extensibile
permit definirea modelelor de informa ii standard de c tre alte organiza ii care pot folosi
infrastructura de comunica ie OPC UA i astfel se pot concentra asupra standardiz rii informa iilor
ce urmeaz s fie expuse. Ca i capacit ile de transport, capacit ile de modelare ale OPC UA sunt
74
4. SERVERUL OPC UA
scalabile. Exist posibilitatea de a p stra informa iile oferite ntr-o form simple, similar cu OPC-ul
clasic dar de asemenea se poate defini o ierarhie complex de tipuri care s fie refolosit pentru
multe scenarii ale aplica iei.
De-a lungul capitolului s-au introdus avantajele majore ale abord rii UA i s-a demonstrat c aceste
aspecte reprezint o mbun ire real pentru un mediu ce const din mai multe sisteme de
fabrica ie flexibil , adic o fabric , sau mai general pentru bine cunoscuta piramid de automatizare.
Cea mai mare mbun ire a fost capabilitatea de modelare unificat (accesul la date, alarme i
evenimente ct i accesul la date istorice), mpreun cu meta modelul extensibil. Serverul dezvoltat
pentru linia flexibil include patru modele de informa ii. Cel de baz si cel pentru integrarea
dispozitivelor sunt modele de informa ii dezvoltate de c tre funda ia OPC, modelul de informa ii
IEC 61131-3 a fost dezvoltat de PLCOpen mpreun cu funda ia OPC i n plus a fost introdus un
model de informa ii FMS dezvoltat special pentru linia flexibil . Ca rezultat, spa iul de adrese cu
structura sa de noduri, ofer o perspectiv complet diferit asupra obiectelor modelate.
Astfel, dispozitivele modelate n spa iul de adrese devin accesibile i pe direc ia vertical n
interiorul piramidei de automatizare (pn la nivelul MES sau chiar ERP) [Schleipen M, 2008].
Un alt aspect important n timpul activit ilor de cercetare a fost acela de a utiliza ct mai mult
posibil eforturile depuse la dezvoltarea specifica iei COM de accesare a datelor curente (DA) . De
aceea au fost analizate toate strategiile de migrare i s-a decis implementarea strategiei bazate pe un
software special de adaptare. Aceast strategie a oferit posibilitatea implement rii tuturor aspectelor
aduse de noua specifica ie dar de asemenea i reducerea timpului de dezvoltare folosind
implementarea protocoalelor proprietare, realizat n interiorul serverelor COM. Un aspect
important n atingerea acestui scop a fost utilizarea SDK-ului JEasyOPC care permite stabilirea unei
conexiuni ntre serverul UA bazat pe Java (implementat cu Prosys UA SDK) i serverele COM. S-a
decis comunicarea doar cu masterul fiec rei linii flexibile deoarece masterul colecteaz deja datele
de la toate celelalte dispozitive i de asemenea coordoneaz ac iunile lor.
Revenind la spa iul de adrese, se men ioneaz cteva aspecte mai speciale care au fost
implementate: s-a introdus o nou regul de modelare (0-N), s-a profitat de posibilitatea de a
ad uga noduri care nu sunt specificate de modele de informa ii i, astfel, s-a demonstrat flexibilitatea
spa iului de adrese.
Cel mai important aspect legat de spa iul de adrese a fost ns dezvoltarea unui set de algoritmi care
au permis generarea eficient i automat a spa iului de adrese. Prin intermediul acestor algoritmi nu
exist restric ii n ceea ce prive te design-ul spa iului de adrese n raport cu standardele publicate n
specifica ia UA i de asemenea descrise n literatura de specialitate [Mahnke W., 2009].
Algoritmii pot fi utiliza i cu orice tip de surs de date (baz de date, fi iere XML, fi iere text, fi iere
Excel, etc.), singurele modific ri care trebuie implementate se afl n metodele care citesc datele din
sursa de date (metodele care ncep cu cuvntul read n interiorul algoritmilor).
Deoarece nu este impus nici o restric ie, serverul UA poate fi folosit pentru oricare din cazurile de
utilizare cunoscute: observare, monitorizare, control, inginerie i service.
Ca avantaje principale ale algoritmilor dezvolta i se men ioneaz :
timp de dezvoltare scurt (codul nu trebuie modificat dup ce algoritmii au fost implementa i;
nodurile adi ionale trebuie doar incluse n baza de date): accelerare de aproximativ 2.2-2.3x;
75
4. SERVERUL OPC UA
ntre inere u oar (cnd trebuie realizate anumite modific ri, nu va mai fi necesar verificarea
a mii de linii de cod ci va fi suficient inspectarea i modificarea informa iilor stocate n sursa
de date): accelerare de aproximativ 1.4-1.6x;
nodurile pot fi ad ugate/modificate sau terse fie de administratorul UA n modul online sau
offline sau de client n modul online.
n plus, s-a decis stocarea st rii spa iului de adrese la nchiderea serverului astfel nct starea
spa iului de adrese s devin persistent . Ca i concluzie pentru spa iul de adrese, se men ioneaz
faptul c serverul suport cazurile de utilizare observa ie i control.
n ceea ce prive te aspectele legate de securitate, care reprezint o alt mbun ire important a
specifica iei UA, s-a folosit un model de ncredere direct , cu certificate auto-semnate.
n timpul perioadei de testare, aten ia a fost ndreptat asupra unei arhitecturi cu patru linii flexibile,
una real i alte trei sisteme simulate, dar de asemenea s-au testat capacit ile serverului raportat la
un num r variabil de linii flexibile, pentru a determina performan ele de vrf ale arhitecturii
(detaliile aplica iei sunt prezentate n capitolul 6).
Au fost luate n considerare dou versiuni de implementare diferite pentru comunica ia dintre
serverul UA i serverul COM. Prima a utilizat conceptul de abonare i astfel, datorit num rului
mare de noduri i actualiz ri simultane care trebuiau s fie efectuate, comunica ia dintre aplica ii a
fost foarte lent .
n cea de-a doua variant serverul UA cite te periodic valorile din serverele COM. Astfel, num rul
de conversa ii este mult redus i timpul de e antionare poate fi mult mai bine controlat. Deoarece
prima variant duce la ntrzieri mai mici, aceasta a fost folosit n cazul variabilelor cu prioritate
ridicat , iar cea de-a doua s-a folosit pentru restul variabilelor.
n capitolul urm tor vor fi introduse serviciile software care formeaz nivelul imediat superior
nivelului UA n cadrul arhitecturii introduse n capitolul 3. Aceste servicii software reprezint
practic clien ii UA care comunic cu serverele OPC UA.
76
5 DEZVOLTAREA UNUI SET DE SERVICII

SOFTWARE PENTRU ARHITECTURI
INDUSTRIALE
5.1 INTRODUCERE
Arhitectura industrial , introdus n capitolul 3, este construit n jurul conceptelor de baz ale
paradigmei SOA. Unul dintre cele trei obiective principale formulate n sec iunea 3.1, a fost de a
construi o arhitectur flexibil , adaptabil i reutilizabil , care s reduc timpii de instalare i setare
la valori minime. Dintre cele trei nivele ale arhitecturii, serviciile software joac rolul cel mai
important n atingerea acestui obiectiv (avantajele unei arhitecturi orientate pe servicii au fost
prezentate n lucrarea [Grbea A., 2010 b)]). Serviciile ncorporeaz func ionalit i cheie ale
arhitecturii, permi nd astfel crearea rapid a unor noi aplica ii i modificarea eficient a celor
existente. Avantajele utiliz rii serviciilor software n medii industriale au fost prezentate n diverse
lucr ri de specialitate [Jammes F., 2005 a); Jammes F., 2005 b); Karnouskos S., 2007].
Pe baza func ionalit ilor oferite de servicii, acestea au fost mp ite n dou categorii: servicii de
baz i servicii complexe. Cele de baz sunt refolosite n toate scenariile de utilizare a arhitecturii i
asigur flexibilitatea i reutilizabilitatea acesteia. Serviciile complexe pot fi mp ite n patru
categorii principale: servicii pentru monitorizarea i controlul execu iei (cu durat de execu ie
lung ), servicii pentru gestionarea erorilor, servicii pentru citirea datelor de configurare necesare
modelelor CSP definite la nivelul superior al arhitecturii i servicii pentru furnizarea parametrilor
KPI pentru nivelul ERP al unei ntreprinderi.
Deoarece arhitectura propus este dezvoltat pentru mediul industrial, timpul de execu ie i de
spuns al serviciilor joac un rol important [Surridge M., 2005; Idoughi D., 2010; Candido G.,
2011]. Dup cum a fost subliniat n capitolul 3, una din ideile care a stat la baza dezvolt rii
arhitecturii a fost de a p stra opera iile critice din punct de vedere al timpului de execu ie pe
dispozitivele de control. Aceasta nseamn c nu exist limite fixe pentru intervalul de execu ie al
serviciilor utilizate la nivelul intermediar al arhitecturii (spre deosebire de arhitectura introdus n
[Cucinotta T., 2009]). Cu toate acestea, activit ile de dezvoltare a serviciilor i mai ales de alegere a
framework-ului pentru implementarea serviciilor au fost orientate c tre un timp de execu ie minim.
Timpul de execu ie trebuie s fie redus deoarece pe de o parte se dore te ca un procentaj ct mai
mare din timpul total de execu ie s fie destinat procesului de fabrica ie n sine, iar pe de alt parte
este important ca arhitectura s reac ioneze prompt la apari ia unor erori.
Din acest motiv au fost evaluate trei concepte diferite (prin intermediul a trei framework-uri diferite)
pentru implementarea serviciilor:
servicii web SOAP Framework-ul Apache CXF [***Apache CXF, 2012];
77
5. DEZVOLTAREA UNUI SET DE SERVICII SOFTWARE PENTRU ARHITECTURI INDUSTRIALE
servicii web REST Framework-ul Jersey REST [***Jersey REST, 2012];

servicii Java Framework-ul Apache River [***Apache River, 2012], [***Sun, 2001].
Decizia final a fost luat pe baza unor teste de performan e efectuate pentru determinarea
framework-ului care permite dezvoltarea serviciilor cu timpul de execu ie cel mai mic.
n continuare vor fi prezentate pe scurt cele trei concepte pentru dezvoltarea serviciilor. Apoi se
introduc serviciile de baz dezvoltate pentru arhitectur i testele de performan . n final se prezint
serviciile complexe precum i concluziile acestui capitol.
5.2 SERVICII WEB SOAP
Conceptul de serviciu web implic trei tipuri de roluri un consumator de servicii, un produc tor de
servicii i un registru de servicii (component op ional ). Figura 5.1 reia conceptul introdus n figura
1.3, prezentnd interac iunea dintre cele trei roluri.
Fig. 5.1. Interac iunea dintre rolurile implicate n utilizarea serviciilor web.
Produc torii de servicii furnizeaz serviciile pe web i r spund la cererile de servicii web.
Consumatorul de servicii utilizeaz serviciile oferite de produc torul de servicii. Se poate astfel
observa faptul c serviciile web SOAP respect paradigma
se te conecteaz execut
prezentat n capitolul 1.
n cazul serviciilor web bazate pe SOAP [***W3C SOAP, 2007], produc torul de servicii este
responsabil de publicarea contractului serviciului (a fi ierului WSDL [***W3C WSDL, 2006]) pe
web, de unde un consumator l poate accesa direct sau c utndu-l n registrul de servicii web. De
obicei serviciul consumator genereaz codul clientului serviciului web pornind de la fi ierul WSDL
i folosind uneltele oferite de framework-ul de servicii web utilizat.
n cazul serviciilor web bazate pe REST nu exist un contract formal ntre produc torul i
consumatorul de servicii web. n acest caz, consumatorul (clientul) trebuie s cunoasc att formatul
mesajului (de exemplu XML [***W3C SOAP XML, 2006]) ct i opera iile suportate de
produc tor. Produc torul de servicii web i expune setul de opera ii folosind metodele HTTP: GET
i POST. Consumatorul serviciului va invoca apoi una din aceste metode folosind URI (Uniform
Resource Identifier) i prin intermediul protocolului HTTP.
Alegerea de a adopta SOAP sau REST depinde de cerin ele aplica iei. Dac sarcina aplica iei este de
a transmite i de a primi mesaje XML simple, atunci abordarea REST este de preferat. Abordarea
SOAP este folosit atunci cnd sarcina aplica iei const din numeroase contracte care trebuie
definite i negociate ntre produc tor i consumator folosind WSDL i cnd este necesar aderarea la
78
diverse specifica ii WS precum cele referitoare la securitate (care sunt indispensabile n cazul unei
ntreprinderi). n acest caz diversele stiluri de comunica ie SOAP trebuie de asemenea luate n
considerare.
5.2.1 Stilurile de comunica ie SOAP
Stilul de comunica ie SOAP joac un rol important n comunica ia mesajelor SOAP bazate pe XML
ntre produc torul i consumatorul de servicii web. Exist dou stiluri de mesaje SOAP: Document
i RPC (Remote Procedure Call). Stilurile de mesaje SOAP sunt definite ntr-un document WSDL
sub forma unei leg turi SOAP.
O leg tur SOAP poate avea o reprezentare codat (bazat pe un anumit format) sau literal (f
codare). Stilul Document, dup cum sugereaz i numele, gestioneaz documentele XML ca i
componente utile care respect cu exactitate contractele bine definite i create folosind defini iile
XML Schema [***W3C XML Schema, 2004].
Formatul XML Schema precizeaz contractul mesajelor de business care sunt interschimbate ntre
produc tor i consumator i pe care consumatorul le poate apela (XML Schema define te formatul
mesajelor de cerere i de r spuns dintre produc tor i consumator). Deoarece asigur o
interoperabilitate maxim , stilul de document literal reprezint metoda preferat pentru comunica ia
serviciilor web.
Pe de alt parte stilul RPC (Remote Procedure Call) indic faptul c n corpul mesajului SOAP se
se te o reprezentare XML a unei metode. Specifica ia SOAP define te un set standard de reguli de
codare utilizate pentru serializarea parametrilor unei metodei n mesaje SOAP astfel nct
deserializarea s poat fi realizat de orice implementare de servicii web. Deoarece RPC este folosit
n conjunc ie cu regulile de codare SOAP, combina ia folosit este RPC/codat. Se poate folosi de
asemenea i stilul de comunica ie RPC/literal dac nu sunt necesare formate codate, dar mesajele
sunt limitate la metoda de comunica ie bazat pe RPC, unde mesajele nu pot fi validate deoarece nu
sunt legate de o defini ie XML Schema. Utilizarea stilului RPC trebuie n general evitat deoarece
poate crea probleme de interoperabilitate.
5.2.2 Fi ierul WSDL
WSDL este un standard bazat pe XML folosit pentru a descrie serviciile web. Conform standardului
WSDL, un serviciu web este descris ca fiind un set de endpoint-uri de comunica ie care sunt
capabile s interac ioneze prin schimb de mesaje. Aceste endpoint-uri de comunica ie sunt numite
porturi. Un endpoint este alc tuit din dou p i:
Defini iile abstracte ale opera iilor furnizate de servicii (similare metodelor din Java) i
mesaje (parametrii de intrare i de ie ire ai metodelor) care sunt necesare la invocarea
serviciului. Setul cu defini iile abstracte ale opera iilor este numit generic tip de port;
Leg tura concret a acestor defini ii abstracte cu protocoalele de re ea, localizarea serviciului
precum i formatul mesajului pentru serviciu.
Leg tura WSDL descrie modul n care un serviciu web este legat de un protocol de mesaje, n
particular protocolul de mesaje SOAP. De obicei, fi ierele WSDL vor fi create folosind diferite
unelte furnizate de framework-ul de servicii web utilizat.
79
5.2.3 Alegerea framework-ului pentru dezvoltarea serviciilor web SOAP

Alegerea unui framework este ntotdeauna o sarcin dificil . Exist multe framework-uri open
source disponibile. Ini ial a fost introdus Axis1 care a evoluat i a fost transformat in Axis2
[***Apache Axis 2, 2012], furniznd astfel o flexibilitate mai mare i suport pentru standardele de
servicii web. Alte framework-uri utilizate pe scar larg sunt: Apache CXF, GlassFish, Metro, Glue,
JBossWS, etc. Fiecare framework de servicii web SOAP i propune s ofere o infrastructur robust
pentru ca programatorul s poat construi, implementa i publica servicii ct mai simplu. n
continuare vor fi prezentate cele mai utilizate dou framework-uri SOAP, i anume Apache Axis2 i
Apache CXF, motivndu-se n final alegerea f cut pentru dezvoltarea serviciilor web de tip SOAP.
5.2.3.1 Framework-ul Apache Axis2
Axis2 este bazat pe o arhitectur nou i dezvoltarea sa a fost realizat de la zero. n compara ie cu
arhitectura Axis1.x, noua arhitectur este mult mai flexibil , eficient , modular i mai mult
orientat spre formatul XML. De exemplu, ac iunea de legare de date, care este responsabil de
serializarea obiectelor Java n XML nu este limitat la o singur tehnologie ci sunt disponibile mai
multe op iuni, prezentate n tabelul 5.1.
Tab. 5.1. Leg turile de date disponibile prin Axis2.
Leg tur de date Descriere

ADB
Framework-ul Axis2 Databinding are o amprent de calcul redus i este
simplu, dar nu acoper toate func iile XML Schema
JiXB
Permite utilizarea POJO-urilor (Plain Old Java Object) f
nici o
modificare. O mapare define te modul n care POJO-urile sunt serializate n
documente XML
XMLBeans
Ofer suport complet pentru XML Schema
Apache Axis2 ofer suport att pentru SOAP 1.1 i SOAP 1.2, ct i pentru cel lalt stil popular de
dezvoltare a serviciilor web, i anume REST (aceea i implementare a logicii de business poate oferi
simultan att o interfa a WS-* ct i o interfa de tip REST/POX). Apache Axis2 a fost conceput
astfel nct s permit ad ugarea i ncorporarea de module suplimentare care extind func ionalitatea
unor caracteristici precum securitate i fiabilitate. Modulele care sunt disponibile momentan sau care
sunt n curs de dezvoltare includ: WS-ReliableMessaging (suportat deApache Sandesha2), WSCoordination i WS-AtomicTransaction (suportate de Apache Kandula2), WS-Security (suportat de
Apache Rampart) i WS-Addressing (modul inclus ca parte a lui Axis2).
Apache Axis2 este construit pe baza lui Apache AXIOM, care este un nou model performant de
rela ionare XML-obiect. Astfel Axis2 prezint noi caracteristici, precum:
Vitez Pentru a atinge o vitez semnificativ mai mare dect versiunile Apache Axis
anterioare, Axis2 folose te propriul s u model de obiecte i StAX (Streaming API for XML);
Amprent de memorie redus Axis2 a fost proiectat de jos n sus, efortul fiind ntotdeauna
ndreptat nspre reducerea cantit ii de memorie utilizat ;
AXIOM Axis2 are propriul s u model de obiecte, AXIOM, pentru procesarea mesajelor.
Acesta este extensibil, performant i este convenabil pentru programator;
80
Hot Deployment Axis2 este echipat cu capacitatea de a nc rca servicii web i alte elemente
de manipulare n timp ce sistemul ruleaz . Astfel, noi servicii pot fi ad ugate n cadrul
sistemului f a fi nevoie ca severul s fie repornit;
Servicii web asincrone Axis 2 suport serviciile web asincrone i invocarea acestor tipuri
de servicii f a bloca clien ii sau mediul de transport;
Flexibilitate Arhitectura Axis2 ofer programatorului libertate complet n inserarea unor
extensii n procesarea antetelor, n managementul sistemului sau a altor componente ale
arhitecturii.
Stabilitate Axis2 define te un set de interfe e publice care se schimb foarte rar;
nc rcare orientat pe componente Pot fi definite cu u urin re ele reutilizabile de
gestionare pentru a implementa modele de procesare comune pentru diversele aplica ii, sau
pentru ca acestea s fie distribuite partenerilor;
Framework de transport Exist o abstractizare simpl pentru integrarea i utilizarea
transporturilor (de exemplu expeditori i ascult tori SOAP prin diferite protocoale precum
SMTP, FTP, mesaj orientat middleware etc.), iar nucleul motorului este complet independent
de transport;
Suportul WSDL Axis2 suport WSDL n versiunile 1.1 i 2.0, versiuni care permit o creare
mai u oar a stub-urilor pentru a accesa serviciile de la distan precum i pentru a exporta
automat descrierile serviciilor nc rcate;
Alte elemente suplimentare Au fost ncorporate mai multe specifica ii de servicii web
inclusiv WSS4J pentru securitate (Apache Rampart), Sandesha pentru mesaje de ncredere, i
Kandula care este o ncapsulare de WS-Coordination, WS-AtomicTransaction i WSBusinessActivity.
Dup cum a fost precizat i anterior, serviciile web asincrone sunt suportate de Axis2a, nefiind
necesar nici o modificare pentru folosirea acestei func ionalit i. n acest caz serviciul va utiliza o
referin c tre un endpoint care este primit ca r spuns la cererea de a adresa un callback la
finalizarea cererii asincrone.
Modul de realizare a nc rc rii pe server a serviciilor pentru Axis1 a fost adesea criticat i de aceea
Axis2 a introdus un mod de nc rcare complet nou. Mediul de execu ie Axis2 reprezint de fapt o
aplica ie web i poate fi instalat pe orice aplica ie server JEE. Aplica ia web Axis2 n sine este un
container pentru servicii web. Serviciile web sunt mpachetate ntr-un format de fi ier propriu cu
extensia de fi ier .aar. Datorit acestor arhive, serviciile web pot fi instalate i configurate printr-o
simpl interfa utilizator n timpul rul rii. Un serviciu web este considerat un pachet independent
care poate fi instalat n mediul de execu ie Axis2. Serviciile sunt configurate folosind fi ierul de
configurare service.xml.
5.2.3.2 Framework-ul Apache CXF
Apache CXF a fost proiectat de c tre Apache Software Foundation i a rezultat din fuziunea a dou
proiecte open source: Celtix dezvoltat de IONA Technologies i XFire dezvoltat de o echip
zduit la Codehaus (numele CXF provine din combinarea numelor proiectelor Celtix i XFire).
Framework-ul CXF suport toate standardele web i furnizeaz un model de programare simplificat
pentru dezvoltarea serviciilor web bazate pe SOAP i REST mpreun cu o serie de protocoale de
81
aplica ii. CXF furnizeaz un model de implementare flexibil pentru implementarea serviciilor web.
Cele mai importante caracteristici ale sale sunt:
Suport pentru standarde de servicii web
Standardele de servicii web definesc normele implement rii unui serviciu web n raport cu
interoperabilitatea sa. Standardele asigur faptul c un serviciu web este accesat independent de
platforma clientului.
Framework-ul furnizeaz suport pentru urm toarele standarde: Java API for XML Web Services
(JAX-WS), SOAP, Web Services Description Language (WSDL), Message Transmission
Optimization Mechanism (MTOM), WS-Basic Profile, WS-Addressing, WS-Policy, WSReliableMessaging i WS-Security.
Una dintre cele mai importante tehnologii de servicii web este JAX-WS (o specifica ie conceput
pentru a simplifica construirea de servicii web bazate pe SOAP i a clien ilor de servicii web n
Java). JAX-WS include de asemenea JAXB (Java Arhitecture for XML Binding) i SAAJ (SOAP
with Attachments API for Java). JAXB ofer capabilit i de legare de date prin furnizarea unui mod
convenabil de mapare a schemei XML cu o reprezentare n cod Java. JAXB ascunde conversia
mesajelor schemei XML din interiorul mesajelor SOAP n cod Java f
ca programatorii s aib
acces la prelucrarea XML i SOAP. Specifica ia JAXB define te leg tura dintre Java i schema
XML. SAAJ ofer o modalitate standard de a gestiona ata amentele XML con inute ntr-un mesaj
SOAP. CXF ofer suport complet pentru stiva JAX-WS.
WS-Addressing, WS-Policy, WS-ReliableMessaging i WS-Security sunt toate p i al specifica iei
de servicii web menite s asigure consisten n diverse domenii ale serviciilor web. De exemplu,
specifica ia WS-Security se refer la modul n care integritatea i confiden ialitatea datelor pot fi
asigurate n cazul serviciilor web prin utilizarea unei metode standard. WS-I Basic Profile este o
specifica ie a WS-I (Web Services Interoperability industry consortium) care furnizeaz un set
important de reguli i direc ii pentru asigurarea interoperabilit ii serviciilor web. Regulile i
specifica iile se aplic asupra fi ierului WSDL, fi ier care serve te ca i contract ntre furnizorul de
servicii i consumatorii de servicii web baza i pe SOAP. Aderarea la profilurile WS-I de baz
asigur faptul c serviciile pot interopera ntre platforme diferite.
Suport pentru POJO (Plain Old Java Object)
Prin POJO se n elege un obiect Java simplu care nu implementeaz interfe ele specifice ale unui
framework sau de infrastructur precum JMS (Java Message Service) sau EJB (Enterprise Java
Beans). POJO faciliteaz integrarea cu alte framework-uri precum Spring, care ofer diverse alte
servicii, precum i gestionarea simpl a tranzac iilor. CXF implementeaz JAX-WS i specifica ia
JAX-RS (Java API for RESTful services) care ofer un set de adnot ri pentru a converti POJO-urile
n servicii web SOAP sau RESTful.
Frontend programming API
CXF frontends sunt API-uri care pot fi folosite pentru a dezvolta servicii web (pe baza POJO-urilor)
i clien i de servicii web. CXF accept dou tipuri de frontend-uri, i anume unul standard ce se
bazeaz pe JAX-WS i un frontend simplu.
82
Instrumente de sprijin
CXF furnizeaz diferite instrumente pentru conversa ia dintre JavaBeans, servicii web i WSDL.
Aceste instrumente sprijin programatorii n generarea clien ilor serviciilor web baza i pe Java i
JavaScript pornind de la WSDL sau n generarea unui fi ier WSDL pornind de la implementarea
unui serviciu. CXF ofer suport pentru integrarea Maven i Ant, pentru managementul compil rii i
al dependen elor. Unele dintre instrumentele suportate sunt urm toarele: Java to Web Service, Java
to WSDL, WSDL to Java, WSDL to JavaScript, WSDL to Service, WSDL to SOAP, WSDL to
XML, WSDL Validator i XSD to WSDL.
Suport pentru serviciile RESTful
CXF suport conceptul de servicii RESTful (Representational State Transfer) i specifica ia JAX-RS
care furnizeaz semantica pentru crearea serviciilor web n concordan cu stilul arhitectural REST.
Specifica ia JAX-RS nu furnizeaz nici un detaliu cu privire la clien ii RESTful. CXF merge un pas
mai departe i ofer diverse op iuni pentru a crea clien i care pot interac iona cu servicii web JAXRS. CXF suport formatul de date JSON (Java Script Object Notation) care este un format utilizat
pe scar larg pentru dezvoltarea aplica iilor Web 2.0.
Suport pentru diferite transporturi i leg turi de date
Leg tura de date este cheia pentru dezvoltarea tuturor serviciilor web. Aceasta reprezint asocierea
dintre obiecte Java i formatul mesajelor care sunt expuse de c tre implementarea serviciului, de
exemplu XML sau JSON (Java Script Object Notation). Serviciile web bazate pe SOAP folosesc
XML ca format de date, n timp ce n cazul serviciilor RESTful se poate alege ntre XML i JSON.
CXF furnizeaz componente de leg tur de date, care gestioneaz asocierea ntr-un mod transparent.
n afar de SOAP i HTTP, CXF suport de asemenea JAXB (Java Arhitecture for XML Binding) i
AEGIS. CXF suport diferite tipuri de protocoale de transport precum HTTP, HTTPs, JMS, i
protocolul CXF Local care permite comunica ia serviciu-serviciu n interiorul aceleia i ma ini
virtuale Java.
Suport pentru leg tura de date non-XML
CXF suport leg turi de date non-XML precum JavaScript Object Notation (JSON) i Common
Object Request Broker Architecture (CORBA). De asemenea suport arhitecturile Java Business
Integration (JBI) i Service Component Architectures (SCAs). Leg turile de date non-XML ofer
mai multe op iuni pentru integrarea cu infrastructura existent care accept aceste formate.
or de utilizat
Framework-ul a fost conceput cu scopul de a furniza o infrastructur robust pentru dezvoltarea
serviciilor web ct i pentru simplificarea procesului de realizare a serviciilor. CXF furnizeaz
suport complet de integrare cu framework-ul Spring, astfel nct o clas POJO expus ca serviciu
web prin intermediul framework-ului CXF s poat utiliza pe deplin avantajele oferite de
framework-ul Spring (de exemplu: capabilit ile de tranzac ii pot fi aplicate declarativ claselor
POJO care reprezint servicii web, prin intermediul infrastructurii Spring). Utiliznd framework-ul
Spring, ntreaga procedur de configurare a serviciilor web este simplificat i nc rcarea pe server a
serviciilor se simplific prin utilizarea fi ierelor de configurare bazate pe XML.
83
nc rcare flexibil pe server

CXF ofer un model de nc rcare pe server flexibil unde serviciile pot fi dezvoltate i testate ntr-un
mediu independent, i apoi nc rcate pe o aplica ie server. Serviciile web dezvoltate prin CXF pot fi
nc rcate pe servere precum Tomcat [***Apache Tomcat, 2012] sau n containere bazate pe J2EE
precum Websphere, WebLogic, JBoss, Geronimo i Jonas. De asemenea CXF permite integrarea n
containere SCA (Service Component Architecture) precum Toscana.
5.2.3.3 Concluzii
n general nici un framework utilizat la dezvoltarea serviciilor web SOAP nu este superior altuia. La
compararea acestor framework-uri este important att modul lor de abordare la dezvoltarea
serviciilor web ct i caracteristicile descrise mai sus. Din punctul de vedere al unui programator
cele dou framework-uri sunt similare.
Axis2 a adoptat o abordare care l determin s fie asem tor unui server de aplica ii n miniatur .
Axis2 este mpachetat sub form de WAR i astfel poate fi nc rcat pe un container de servlet-uri
precum Tomcat, care este proiectat pentru a simplifica implementarea i gestionarea serviciilor web.
Modulul Web Administration i permite lui Axis2 s fie configurat dinamic, n timp ce aplica iile se
execut noi servicii pot fi nc rcate, activate sau dezactivate, iar parametrii lor pot fi modifica i.
Interfa a de administrare permite modulelor s fie activate pe unul sau mai multe servicii care se afl
n execu ie. Singurul dezavantaj al utiliz rii unei interfe e grafice n aceste scopuri este faptul c
modific rile de configura ie efectuate prin intermediul acestuia nu sunt persistente acestea dispar
atunci cnd containerul de servlet-uri este repornit.
Axis2 se preteaz pentru servicii web care sunt de sine st toare, independente de alte aplica ii i
care ofer o varietate larg de func ionalit i i un model bun pentru a ad uga mai multe
func ionalit i o dat cu trecerea timpului prin arhitectura sa modular . Dezavantajele lui Axis2 sunt
complexitatea sa i suport JAX-WS insuficient.
Cei care prefer o integrare perfect cu framework-ul Spring sunt sf tui i s foloseasc Apache CXF
(CXF a fost dezvoltat innd cont de Spring iar Axis2 nu). n plus CXF este mai u or de utilizat i se
concentreaz pe capacit ile de integrare a serviciilor i n general simplific sarcinile
programatorului. Astfel majoritatea configur rilor se realizeaz prin API-uri care elimin necesitatea
manipul rii manuale a fi ierelor XML.
CXF este varianta optim n cazul n care un motor SOAP trebuie ncorporat ntr-un software
existent. De asemenea un API proprietar precum i interfa a standardizat JAX-WS sunt disponibile
pentru dezvoltarea i utilizarea serviciilor web.
Pentru dezvoltarea serviciilor web SOAP s-a ales framework-ul Apache CXF, motivele principale
fiind:
1. Integrarea aspectelor legate de specifica ia UA este mai u or de realizat. n perioada de
testare cnd au fost evaluate ambele framework-urile s-au ntmpinat dificult i la
construirea unui client UA n interiorul unui serviciu web Apache Axis, respectiv la
realizarea conexiunii cu serverul UA. Pe de alt parte, prin intermediul framework-ului CXF,
realizarea conexiunii cu serverul UA a fost realizat similar cu cazul unui client OPC UA
obi nuit [***OPC Foundation, 2011 a)] i nu a necesitat modific ri.
2. CXF este strns corelat cu framework-ul Spring. Acesta ofer o serie de avantaje n
opera iile cu baza de date deoarece simplific gestionarea tranzac iilor. n cazul aplica iei
84
dezvoltate n cadrul lucr rii, baza de date reprezint o component important deoarece este
folosit att pentru generarea automat a spa iului de adrese ct i pentru stocarea datelor,
alarmelor i evenimentelor istorice. n acest context, suportul oferit de Spring n gestionarea
tranzac iilor cu baza de date este indispensabil.
3. Efortul general de dezvoltare al serviciilor web folosind Apache CXF este mai mic dect cel
depus pentru dezvoltarea serviciilor prin Apache Axis2 (timpul de dezvoltare este mai scurt).
n plus CXF permite o trecere mai u oar c tre serviciile de tip RESTful (serviciile care vor
fi prezentate n continuare se bazeaz pe SOAP, dar CXF este avantajos n perspectiva unei
eventuale treceri c tre servicii de tip RESTful).
4. Dup cum s-a precizat anterior, Apache Axis este de preferat n cazul n care serviciile web
sunt aplica ii de sine st toare. n cazul de fa serviciile web sunt strns corelate att cu
serverul OPC UA aflat la primul nivel al arhitecturii, ct i cu modelele CSP aflate la nivelul
superior al arhitecturii. n astfel de situa ii este de preferat abordarea bazat pe CXF.
5.3 SERVICII WEB REST
REST (Representational State Transfer) este un stil de arhitectur software pentru sisteme distribuite
n hipermedia precum World Wide Web. A fost introdus i definit n 2000 de Roy Fielding n teza sa
de doctorat [Fielding R., 2000] i de atunci a c tigat tot mai mult aten ie din partea utilizatorilor.
REST define te un set de concepte i principii care pot fi folosite la proiectarea serviciilor web care
se concentreaz asupra resurselor sistemului, inclusiv asupra modului n care sunt adresate i
transferate prin HTTP st rile resurselor de c tre o serie de clien i ai c ror clase au fost implementate
n diferite limbaje de programare.
Considernd num rul actual de servicii web care folosesc REST, se poate remarca faptul c REST a
devenit op iunea predominant n dezvoltarea serviciilor web [Allamaraju S., 2010 a)]. Practic,
REST a avut un impact a a de mare asupra mediului web c aproape a nlocuit interfe ele bazate pe
SOAP i WSDL [Pautasso C., 2008].
Mai multe companii de internet, precum Amazon i Google, au trecut de la serviciile web
tradi ionale bazate pe SOAP la a a numitele servicii web REST. Acest lucru se datoreaz n
principal faptului c aplica iile construite n stilul REST au mai multe avantaje, inclusiv faptul c
acestea consum pu ine resurse de calcul, sunt declarative i u or de accesat [Allamaraju S., 2010
b)]. Stilul arhitectural REST este considerat o tehnic de comunicare bazat pe web care folose te
doar HTTP i XML.
Serviciile web REST gestioneaz datele de business i func ionalit ile ca resurse identificate (de
aici rezult avantajul unui consum redus de resurse de calcul). R spunsul unui serviciu este
reprezentarea resursei i nu necesit ncapsulare suplimentar (precum SOAP). Serviciile REST
folosesc direct protocolul HTTP i ofer o interfa de invocare uniform prin utilizarea setului de
metode HTTP. Serviciile web REST sunt u or de accesat deoarece exist un set standard de coduri
de stare HTTP, care sunt folosite pentru a interpreta r spunsul invoc rii.
Datorit faptului c serviciile REST se concentreaz pe propriile date i resurse, acestea sunt
cunoscute ca fiind auto-declarative. n [Wilde E., 2007] autorul demonstreaz faptul c aplica iile
orientate pe servicii construite folosind abordarea declarativ sunt modulare i ofer o scalabilitate i
flexibilitate mai mare n compara ie cu cele construite folosind abordarea imperativ .
85
Abordarea REST este compus din cinci concepte (resurs , reprezentare, identificator uniform,
interfa unificat
i contextul execu iei) i trei principii (adresabilitate, lipsa unei st ri i
conectivitate).
Resursa
O resurs este o abstractizare relevant n domeniul unui anumit serviciu. Proiectantul de servicii
poate alege orice obiecte de domeniu, de la cele abstracte pn la cele concrete (o resurs poate fi
compus dintr-o colec ie de obiecte). n plus, unele servicii lucreaz cu mai multe tipuri de resurse
dar acest aspect nu afecteaz calitatea serviciului.
Reprezentarea
Serviciile web nu manipuleaz direct resursele ci doar reprezent rile acestora deoarece resursele
reprezint doar abstractiz ri ale unor concepte. Teoretic, o reprezentare este orice informa ie util
referitoare la starea unei resurse [Richardson L., 2007]. Din punct de vedere tehnic, o reprezentare
este o serializare a resursei ntr-un format dat precum XML, XHTML (Extensible Hypertext Markup
Language), JSON (JavaScript Object Notation), RDF (Resource Description Framework), etc.
Limbajele bazate pe XML sunt deosebit de importante n contextul semantic deoarece ele permit
utilizarea adnot rilor de date extensibile.
Identificator uniform
Fiecare resurs este asociat cu cel pu in un URI (Uniform Resource Identifier) care reprezint
simultan att numele ct i localizarea resursei. Pe de o parte, un obiect care nu are un URI nu poate
fi considerat o resurs REST iar pe de alt parte un obiect poate fi identificat de un set de URI-uri
diferite. Identificatorii trebuie s fie descriptivi i s respecte o serie de restric ii predefinite asupra
structurii, ierarhiei i modului de notare.
Interfa unificat
n conformitate cu paradigma REST, ac iunea care trebuie executat este definit de metoda HTTP.
Acest protocol ofer cinci metode principale i anume: GET, HEAD, POST, PUT i DELETE (toate
metodele sunt aplicate resurselor). Mai precis, o metod HTTP este executat pe baza unui URL dat.
n ciuda simplit ii sale, aceast caracteristic este extrem de puternic deoarece define te o interfa
unificat pentru toate serviciile. Dac o aplica ie consumator cunoa te resursele oferite de un anumit
serviciu atunci n mod automat va fi capabil s extrag , s creeze, s actualizeze i s tearg aceste
resurse.
Contextul execu iei
n ceea ce prive te contextul execu iei, paradigma REST sus ine utilizarea URI-ului cererii HTTP.
n concluzie, URI-ul nu con ine doar calea serviciului ci i al i parametrii care identific n mod unic
resursa care va fi manipulat .
Pe lng respectarea conceptelor de mai sus serviciile REST trebuie s fie create n conformitate cu
principii enun ate n continuare.
86
Adresabilitatea
Un serviciu web este clasificat ca fiind adresabil dac expune aspectele interesante ale datelor sale
prin intermediul resurselor, fiecare dintre acestea avnd propriul URI [Richardson L., 2007].
Considernd c o resurs poate suporta reprezent ri diferite, se recomand asocierea unui URI
diferit fiec rei reprezent ri. Opus acestui principiu, n mod tipic, serviciile non-adresabile prezint
un singur URI, care nume te i adreseaz serviciul ca o singur entitate iar obiectele nu sunt expuse
consumatorilor. Aceast situa ie este ntlnit n cazul serviciilor RPC i i mpiedic pe consumatori
fac referire la o resurs particular (situa ie care trebuie evitat ).
Lipsa unei st ri
Abordarea REST define te dou tipuri de st ri: prima este starea resursei care reprezint informa ii
despre resurs i cea de-a doua este starea aplica iei care reprezint informa ii despre opera iile pe
care clientul le-a efectuat anterior n cadrul aplica iei. Un serviciu web este lipsit de stare dac nici o
stare a aplica iei nu este stocat pe server. Acest lucru semnific faptul c aplica ia client este
responsabil de transmisia tuturor informa iilor necesare execu iei cu succes a metodei.
Conectivitate
Resursele trebuie s se indice reciproc, ndrumnd astfel clientul c tre alte st ri ale aplica iei. O
conexiune este stabilit de fiecare dat cnd o reprezentare a unei resurse ofer o valoare de atribut
care reprezint de fapt URI-ul unei alte resurse. [Fielding R., 2000] define te acest tip de sistem
hipermedia ca fiind motorul st rii aplica iei. Nivelurile ridicate de conectivitate ntre resurse
faciliteaz descoperirea acestora. ntr-adev r, ntr-un serviciu care nu este conectat clientul trebuie
utilizeze reguli predefinite pentru a construi fiecare URI pe care dore te s -l acceseze.
Pentru implementarea serviciilor web REST s-a folosit framework-ul Jersey. Acesta este open
source i ofer suport pentru adnot rile definite n specifica ia JSR-311, simplificnd astfel
dezvoltarea serviciilor web REST pe baza limbajului Java. Pe lng implementarea API-ului JSR331, Jersey furnizeaz i un API suplimentar care nu este inclus n JSR-331 i care permite
programatorilor s dezvolte API-ul JSR conform necesit ilor lor.
5.4 SERVICII JAVA APACHE RIVER
Scopul arhitecturii Apache River (ini ial a fost cunoscut sub denumirea Jini) este acela de a
organiza grupuri de dispozitive i componente software ntr-un singur sistem distribuit i dinamic.
Ca rezultat al reorganiz rii se simplific accesul i administra ia i se ofer suport pentru utilizarea
n comun a resurselor.
Jini a ap rut ca urmare a evolu iei limbajului Java, scopul fiind acela de a simplifica execu ia
distribuit a aplica iilor. Jini reprezint un mediu de calcul distribuit care asigur interconectarea i
comunica ia direct ntre componentele software f
a necesita set ri suplimentare. Un dispozitiv
sau un serviciu software se poate conecta la o astfel de re ea i i poate anun a prezen a iar clien ii
care doresc s foloseasc un astfel de serviciu, l pot localiza i apoi apela pentru a efectua anumite
opera ii.
87
Jini nu este un acronim i nu are o semnifica ie aparte. Un sistem Jini este o colec ie de clien i i
servicii care comunic prin intermediul protocoalelor Jini. De obicei, aceasta const n aplica ii
scrise n Java care comunic prin intermediul mecanismului Java Remote Method Invocation (RMI).
De i Jini este implementat n Java, nici clien ii i nici serviciile nu sunt constrnse s fie n limbajul
Java. Ace tia pot include metode de cod nativ sau pot ac iona ca i obiecte nveli (wrapper) pentru
obiecte non-Java. Jini furnizeaz un nivel intermediar pentru a conecta serviciile i clien ii dintr-o
varietate de resurse.
5.4.1 Concepte cheie
Serviciile
Cel mai important concept al arhitecturii Jini este acela de serviciu [Waldo J., 1999]. Un serviciu
reprezint o entitate care poate fi folosit de o persoan , program sau de alt serviciu. Un serviciu
poate efectua un calcul, poate con ine un canal de comunica ie c tre un alt utilizator, un filtru
software, un dispozitiv hardware sau chiar un alt utilizator.
Un sistem Jini const n servicii care pot fi utilizate mpreun pentru efectuarea unei anumite sarcini
[Kadowaki, K., 2008]. Serviciile pot folosi alte servicii, i un client al unui serviciu poate de
asemenea s fie un serviciu care poate avea proprii lui clien i. Natura dinamic a unui sistem Jini
permite serviciilor n orice moment s poat fi ad ugate sau retrase din organiza ie n conformitate
cu cererile sau necesit ile schimb toare ale grupului care folose te sistemul. Sistemele Jini
furnizeaz mecanisme pentru construirea, comunicarea i utilizarea serviciilor ntr-un sistem
distribuit.
Serviciile dintr-un sistem Jini comunic unele cu altele folosind un protocol de serviciu, care
reprezint un set de interfe e scrise n limbajul de programare Java. Setul de protocoale este
nelimitat dar sistemul de baz Jini define te un num r mic de astfel de protocoale care reprezint
aspectele critice ale interac iunii.
Serviciul de c utare
Serviciile sunt g site i solu ionate de un serviciu de c utare cunoscut sub denumirea de lookup
service [Waldo J., 2000]. Serviciul de c utare este mecanismul central al sistemului i furnizeaz
punctul principal de contact dintre sistem i utilizatorii acestuia. Mai exact, un serviciu de c utare
asociaz interfe e care indic func ionalitatea furnizat de un serviciu cu seturi de obiecte care
implementeaz serviciul. n plus, intr rile descriptive asociate unui serviciu permit o selec ie mai
precis a serviciilor pe baza propriet ilor u or de n eles de c tre operatorii umani. Obiectele dintrun serviciu de c utare pot include alte servicii de c utare, aspect care conduce la c utare ierarhic .
Un serviciu este ad ugat la un serviciu de c utare (lookup service) de o pereche de protocoale
denumite discovery (descoperire) i join (al turare) ini ial serviciul localizeaz un serviciu de
utare corespunz tor (utiliznd protocolul discovery) i apoi i se al tur (folosind protocolul join).
Java Remote Method Invocation (RMI)

Comunica ia dintre servicii poate fi realizat prin mecansimul Java Remote Method Invocation
(RMI). Infrastructura care sprijin comunica ia dintre servicii nu este un serviciu care este descoperit
i apoi folosit ci mai degrab o parte a infrastructurii tehnologiei Jini. RMI furnizeaz mecanisme
88
pentru a g si, activa i elimina grupurile de obiecte. La baz , RMI este o extensie disponibil a
limbajului de programare Java care furnizeaz mecanisme tradi ionale pentru apeluri de proceduri de
la distan . n cadrul re elei, RMI permite nu doar ca date s fie trecute de la un obiect la altul ci
chiar obiecte care con in cod.
Marea parte a simplit ii sistemului Jini se datoreaz acestei abilit i de a muta codul n cadrul unei
re ele sub forma ncapsul rii ntr-un obiect.
Securitatea
Modelul de securitate al tehnologiei Jini este construit pe baza no iunilor principal i list de control
al accesului [Venners B., 1998]. Serviciile Jini sunt accesate n numele unei entit i principalul
care n general reprezint un anumit utilizator al sistemului.
Serviciile pot solicita acces la alte servicii pe baza identit ii obiectului care implementeaz
serviciul. Permisiunea accesului la un serviciu depinde de con inutul listei de acces care este
asociat obiectului.
Leasing
Accesul la multe dintre serviciile sistemului Jini se realizeaz pe baza contractului de leasing. Un
contract de leasing este o conven ie pentru accesul garantat pe o perioad de timp. Fiecare contract
de leasing este negociat ntre utilizatorul serviciului i furnizorul de servicii ca parte a protocolului
serviciului: un serviciu este apelat pentru o anumit perioad de timp iar accesul este asigurat pentru
o anumit perioad presupunnd c perioada solicitat este luat n calcul. n cazul n care contractul
de leasing nu este rennoit nainte de termenul limit de func ionare, fie datorit faptului c resursa
nu mai este necesar , clientul sau re eaua e ueaz , fie pentru c nu este permis rennoirea
leasingului, atunci att utilizatorul ct i furnizorul de resurse elibereaz resursa.
Contractele de leasing sunt exclusive sau neexclusive. Contractele de leasing exclusive asigur
faptul c nimeni altcineva nu poate ncheia un contract de nchiriere pe resursa n cauz pe durata
perioadei de leasing. n schimb, contracte de leasing neexclusive permit mai multor utilizatori s
mpart o resurs .
Tranzac ii
O tranzac ie este format fie din mai multe opera ii care apar in aceluia i serviciu sau din opera ii
care apar in mai multor servicii. Interfe ele de tranzac ie Jini furnizeaz un protocol de serviciu care
poate coordona o ac iune de comitere efectuat n dou etape. Modul n care sunt implementate
tranzac iile este l sat la latitudinea serviciului care folose te acele interfe e.
Evenimente
Arhitectura Jini suport evenimentele distribuite. Un obiect poate permite altor obiecte s prezinte
interes asupra evenimentelor nregistrate pentru obiectul n cauz i de asemenea s primeasc
notific ri la apari ia unui astfel de eveniment. Acest lucru permite programelor bazate pe evenimente
distribuite s fie scrise cu garan ii de fiabilitate i scalabilitate.
89
5.4.2 Arhitectura serviciilor

Serviciile constituie baza unui sistem interactiv Jini att la nivelul de programare ct i la nivelul de
interfa cu utilizatorul. Protocoalele discovery (de descoperire) i lookup (de c uatre) oferite de Jini
permit n elegerea arhitecturii unui serviciu.
Protocoalele de descoperire i c utare
Elementele cheie ale unui sistem Jini sunt protocoalele: descoperire, al turare i utare. Perechea
descoperire i al turare se folose te atunci cnd este conectat un dispozitiv. Descoperirea are loc
atunci cnd un serviciu caut un serviciu lookup la care s se nregistreze. Al turarea apare cnd un
serviciu a localizat un serviciu lookup i vrea s i se al ture. utarea are loc cnd un client sau un
utilizator trebuie s localizeze sau s invoce un serviciu descris de tipul s u de interfa (scris n
limbajul de programare Java) i eventual de alte atribute. Figura 5.2 prezint procesul de
descoperire.
Fig. 5.2. Procesul de descoperire.
Descoperirea/al turarea Jini este procesul de ad ugare a unui serviciu la un sistem Jini. Un furnizor
de serviciu este ini iatorul serviciului de exemplu un dispozitiv sau un modul software.
Ini ial furnizorul de servicii localizeaz un serviciu de c utare prin multicasting, adic o cerere
adresat tuturor serviciilor pentru ca acestea s se auto-identifice (figura 5.2). Apoi este nc rcat un
obiect specific serviciului n serviciul de c utare (figura 5.3). Acest obiect specific serviciului
con ine interfa a Java a serviciului, incluznd metodele pe care utilizatorii i aplica iile le vor invoca
pentru a executa serviciul precum i alte atribute descriptive ale serviciului.
Fig. 5.3. nregistrarea instan ei serviciului la serviciul de c utare.
Serviciile trebuie s fie capabile s g seasc un serviciu de c utare, cu toate acestea ns un serviciu
poate delega sarcina de g sire a unui serviciu de c utare c tre o a treia entitate. Dup cum se poate
vedea n figura 5.4 serviciul este acum preg tit pentru a fi utilizat.
90
Fig. 5.4. Preluarea de c tre client a unei copii a instan ei serviciului.
Clientul localizeaz serviciul corespunz tor necesit ii sale pe baza interfe ei acestuia, scris n
limbajul de programare Java mpreun cu atributele descriptive care sunt folosite ntr-o interfa
Java pentru serviciul de lookup. Serviciul obiect este apoi nc rcat n client. Dup cum se poate
observa n figura 5.5, etapa final este aceea de invocare a serviciului.
Fig. 5.5. Invocarea de c tre client a serviciului.
Metodele obiectului care reprezint serviciul pot implementata un protocol privat ntre acesta i
furnizorul original de servicii. Implement ri diferite ale aceleia i interfe e de serviciu pot folosi
diferite protocoale de interac iune.
Abilitatea de a muta obiecte i cod de la un furnizor de servicii la serviciul de c utare i de acolo la
clientul serviciului, ofer furnizorului de servicii libertate n alegerea modului de comunicare dintre
serviciu i clien ii s i [Pota S., 2006].
De asemenea aceast mutare a codului asigur faptul c obiectul serviciului, de inut att de c tre
client ct i de c tre serviciul n sine, sunt ntotdeauna sincronizate, deoarece obiectul serviciului
este furnizat de c tre serviciu. Clientul cunoa te doar faptul c serviciul realizeaz o implementare a
unei interfe e scrise n limbajul de programare Java. Pentru c acest cod are ca surs serviciul, codul
poate profita de detaliile de implementare ale serviciului, care sunt cunoscute doar n interiorul
acestuia.
Clientul interac ioneaz cu serviciul prin intermediul unui set de interfe e scrise n limbajul de
programare Java. Aceste interfe e definesc setul de metode care pot fi folosite pentru a interac iona
cu serviciul.
Interfe ele sunt identificate prin tipul de sistem al limbajului de programare Java i serviciile pot fi
site ntr-un serviciu de c utare prin c utarea acelor servicii de c utare care suport o anumit
interfa . G sirea unui serviciu n acest mod asigur faptul c programul care caut serviciul va
91
cunoa te modul de invocare al acestuia, deoarece utilizarea este definit de setul de metode care sunt
definite dup tip.
Interfe ele pot fi implementate ca referin e RMI c tre obiectul aflat la distan care implementeaz
serviciul, ca metode de calcul local care furnizeaz toate capabilit ile serviciului n mod local sau
ca o combina ie a celor dou aspecte. Astfel de combina ii, numite proxy-uri inteligente,
implementeaz o parte din func ii local iar pentru restul func iilor se realizeaz apeluri la distan
tre o implementare centralizat a serviciului.
O interfa utilizator poate de asemenea fi stocat ntr-un serviciu de c utare sub forma unui atribut
al serviciului nregistrat. O astfel de interfa a unui serviciu Jini este o implementare care permite
serviciului s fie manipulat direct de c tre un utilizator al sistemului.
De fapt, o interfa utilizator pentru un anumit serviciu este o form specializat a interfe ei
serviciului care acord unui program, precum un browser, posibilitatea s permit utilizatorului
uman s interac ioneze direct cu serviciul.
n situa ia n care nu poate fi g sit nici un serviciu de c utare, un client poate folosi o tehnic
denumit
utare peer. n astfel de situa ii, clientul trimite un pachet de identificare, identic cu cel
folosit de serviciul de c utare, pentru a solicita furnizorilor de servicii s se nregistreze. Furnizorii
de servicii vor ncerca apoi s se nregistreze la client la fel ca la un serviciu de c utare. Clientul
poate alege serviciile de care are nevoie din cererile de nregistrare pe care le prime te ca r spuns,
refuzndu-le pe restul.
Obiectele care implementeaz un serviciu pot fi proiectate s ruleze ntr-un spa iu de adrese unic cu
alte obiecte, mai ales cnd exist o anumit loca ie sau cerin e bazate pe securitate [Changyi
L., 2009]. Astfel de obiecte formeaz un a a numit grup de obiecte. Este garantat faptul c un grup
de obiecte se va afla ntotdeauna ntr-un spa iu de adrese unic sau pe aceea i ma in virtual atunci
cnd sunt executate obiectele din componen a sa. Obiectele care nu se afl n acela i grup de obiecte
sunt izolate unul de altul, de obicei prin rularea lor pe diferite ma ini virtuale sau n alt spa iu de
adrese.
Un serviciu poate fi implementat direct sau indirect de c tre un hardware specializat (astfel de
dispozitive pot fi contactate de codul asociat cu interfa a serviciului). Din punctul de vedere al
clientului serviciului nu exist diferen e ntre serviciile care sunt implementate de obiecte pe diferite
ma ini, serviciile care sunt desc rcate n spa iul de adrese local i serviciile care sunt implementate
n hardware. Toate aceste servicii vor ap rea ca fiind disponibile n re ea, ca fiind obiecte scrise n
limbajul de programare Java, i, numai n m sura n care func ionarea corect este principala
preocupare, un tip de implementare ar putea fi nlocuit cu un altul, f
o n tiin are a clientului
(trebuie re inut faptul c permisiunile de securitate trebuie s fie acordate).
5.5 SERVICIILE DE BAZ
Pentru arhitectura introdus n capitolul 3 a fost dezvoltat un set de servicii care se comport ca i
clien i din punctul de vedere al serverului UA, dar care din punctul de vedere al utilizatorului final
se afl pe partea de server (serviciile au fost introduse ini ial n lucrarea [Grbea A., 2011 c)]).
Deoarece fiecare serviciu reprezint un client UA, trebuie s se stabileasc o conexiune cu serverul
UA pentru a extrage informa iile cerute de clientul serviciului.
92
Setarea unei conexiuni cu serverul UA implic mai mul i pa i importan i i de asemenea necesit un
anumit timp. n primul rnd trebuie generat o descriere a aplica iei, dup aceea, pe baza acestei
descrieri, trebuie creat identitatea aplica iei care de fapt reprezint un certificat. Acest certificat
este apoi folosit de server pentru a valida clientul. n final clientul trebuie de asemenea s valideze
certificatul serverului pentru a determina dac serverul este unul de ncredere [Stopper M., 2009].
Comunica ia dintre cele dou instan e ncepe doar dup efectuarea acestor pa i.
5.5.1 Gestionarea conexiunilor cu serverul OPC UA
Pentru a reduce timpul de r spuns pentru un serviciu client s-a folosit o abordare bazat pe sesiuni.
n faza de dezvoltare au fost testate dou abord ri diferite care vor fi expuse pe scurt n continuare.
n cazul primei abord ri, n timpul primului apel al serviciului, va fi stabilit o conexiune cu serverul
UA care va fi salvat ntr-o sesiune, i toate apelurile ulterioare, realizate de acela i client al
serviciului, vor folosi conexiunea deja stabilit . Figura 5.6 prezint schema de comunica ie
generalizat a serviciului, care const din cinci pa i principali:
Fig. 5.6. Gestionarea sesiunii, versiunea 1.
1. Clientul serviciului apeleaz serviciul;

2. Dac este primul apel al clientului, serviciul creeaz o conexiune UA. n caz contrar extrage
conexiunea creat anterior pentru acel client;
3. Serviciul folose te conexiunea din pasul doi pentru a extrage datele cerute de client sau
pentru a efectua o anumit ac iune;
4. Serverul UA returneaz rezultatul cererii, care poate fi doar un semnal de stare care indic
succesul sau insuccesul ac iunii efectuate;
5. Serviciul returneaz rezultatul final c tre client.
n cazul de mai sus, gestionarea conexiunilor UA a fost realizat la nivelul serverului de servicii. n
cazul celei de-a doua strategii s-a decis schimbarea modului de gestionare a conexiunilor UA,
permi nd fiec rui serviciu s realizeze aceast opera ie (figura 5.7).
93
Fig. 5.7. Gestionarea sesiunii, versiunea 2.
n acest caz fiecare serviciu va con ine o list de conexiuni pentru entit ile/utilizatorii care-l
apeleaz (desigur conexiunile vor fi nchise dup un anumit timp n cazul n care nu mai exist
activitate, aspect valabil pentru ambele abord ri). Schimbarea efectuat are o serie de avantaje dar i
un dezavantaj.
Avantajele sunt:
versiunea are o amprent de calcul mai mic i poate fi u or programat /implementat direct
n codul fiec rui serviciu;
se pot folosi diferite conexiuni UA specializate deoarece fiecare serviciu efectueaz o ac iune
specific .
Singurul dezavantaj este acela c utiliznd aceast tehnic vor exista mai multe conexiuni UA cu
serverul UA. Acest neajuns nu are nici o influen deoarece SDK-ul serverului UA furnizat de
Prosys [***Prosys Java UA SDK, 2011], i utilizat n cadrul implement rii, permite clien ilor UA
stabilirea simultan a peste 1000 de conexiuni.
5.5.2 Prezentarea setului de servicii de baz
n ceea ce prive te dezvoltarea serviciilor, s-a ncercat alegerea unei cantit i corecte a volumului de
calcul pentru fiecare dintre ele astfel nct pe de o parte acestea s nu fie prea specializate i s poat
fi folosite n situa ii variate iar pe de alt parte s nu realizeze opera ii prea generale deoarece acest
lucru ar conduce la servicii cu prea mul i parametrii i cu o implementare care ar fi dificil de
modificat i ntre inut [Krammer A., 2011]. Ca rezultat a fost dezvoltat un set de opt servicii de
baz , i anume:
WriteVariableNodeService: asociaz valoarea specificat de client nodului variabil corespunz tor
din spa iul de adrese UA. Nodul variabil este identificat prin intermediul unui NodeId i al unui
index al spa iului de nume. Combina ia celor dou cmpuri este unic n spa iul de adrese al
serverului UA, de aceea nu va exista nici o incertitudine n ceea ce prive te variabila c reia trebuie
i se asocieze valoarea specificat de client. To i parametrii sunt specifica i ca iruri de caractere i
apoi transforma i n tipul de dat corect.
ReadVariableNodeService: cite te valoarea variabilei nod specificat de client i o returneaz
clientului serviciului.
94
CallMethodService: apeleaz o metod UA, care este din nou identificat prin combina ia dintre un
index al spa iului de nume i un NodeId. n plus, acest serviciu preia un num r variabil de valori ca
parametrii de intrare pentru metoda UA. De asemenea, returneaz un num r variabil de parametrii
care reprezint valorile returnate de metod .
ReadAlarmStateService: cite te starea curent a unui nod alarm .
ReadAlarmEventService: cite te evenimentele/alarmele dintr-un interval de timp specificat de
client i i le returneaz acestuia. Clientul trebuie s specifice din nou un index al spa iului de nume
i NodeId-ul, care poate reprezenta fie un nod surs pentru eveniment/alarm , fie un nod notificator
de evenimente (n cazul n care clientul specific un nod notificator de evenimente, toate
evenimentele nregistrate de c tre nodurile surs de evenimente, referite direct sau indirect prin
referin a HasNotifier de c tre nodul notificator, vor fi returnate de acest serviciu). Un parametru de
tip ntreg permite clientului s specifice dac dore te s citeasc evenimente, alarme sau ambele (0
evenimente, 1 alarme, 2 ambele).
ReadRawDataService: cite te valorile istorice ale unui nod variabil dintr-un interval de timp i le
returneaz clientului. Variabila nod este identificat n acela i mod ca i n cazul celorlalte servicii.
ReadProcessedService: returneaz clientului o valoare procesat care corespunde valorilor
nregistrate n intervalul de timp specificat. Acest serviciu suport patru tipuri de func ii agregat
identificate prin valori ntregi (0 maxim, 1 minim, 2 sum , 3 medie).
ReadAtTimeService: returneaz clientului o valoare care corespunde momentului de timp exact
specificat. De obicei nu va exista nici o valoare n sursa de date pentru momentul de timp specificat
i n acest caz serviciul returneaz fie ultima valoare nregistrat , fie o valoare determinat prin
interpolare liniar a celor dou valori nvecinate (se folose te un parametru suplimentar al
serviciului: 0 ultima valoare nregistrat , 1 valoarea interpolat ). Calculul valorii este efectuat n
interiorul serverului UA i nu n interiorul serviciului, serviciul doar apeleaz metoda
corespunz toare a serverului UA.
5.6 TESTE DE PERFORMAN
Toate cele opt servicii de baz au fost implementate prin intermediul celor trei framework-uri de
servicii prezentate n sec iunile 5.2, 5.3 i 5.4 iar pentru a determina framework-ul de servicii cel
mai adecvat arhitecturii propuse pentru optimizarea aplica iilor industriale, s-au dezvoltat dou teste
de performan [Grbea A., 2012 c)].
5.6.1 Timpii de execu ie ai serviciilor de baz
Primul test evalueaz timpii de execu ie ai celor opt servicii de baz . Dintre cele opt servicii descrise
n sec iunea anterioar , doar primele patru sunt opera ii de timp real, ultimele patru fiind legate de
aspectele istorice i sunt ndeosebi folosite pentru a evalua valorile KPI (au fost alese opera ii
reprezentative pentru fiecare tip de serviciu). Trebuie precizat faptul c exist o diferen important
ntre primul apel al unui serviciu de c tre un anumit utilizator i apelurile sale ulterioare deoarece n
timpul primului apel trebuie s se stabileasc o conexiune cu serverul OPC UA (n cazul apelurilor
ulterioare se vor utiliza conexiunile deja stabilite conform procedurii prezentate n figura 5.7).
Valorile din tabelul 5.2 sunt valorile medii pentru apelurile ulterioare primului apel i valorile afi ate
n paranteze reprezint valoarea medie pentru primul apel al unui anumit serviciu.
95
Tab. 5.2. Timpii de execu ie a serviciilor de baz .
Serviciu
WriteVariable
ReadVariable
CallMethod
ReadAlarmState
ReadAlarmEvent
ReadRawData
ReadProcessed
ReadAtTime
Apache CXF [ms]

280.9 10.5 (1102.8)
244.2 2.83 (1259.3)
312.3 12.7 (1167.6)
245.4 2.56 (1243.7)
289.8 15.8 (1197.5)
295.6 6.84 (1223.8)
301.8 13.7 (1217.1)
278.3 11.9 (1145.0)
Jersey REST [ms]

309.7 7.59 (907.7)
233.0 3.36 (1312.1)
318.5 23.9 (1078.3)
235.9 2.78 (1308.2)
284.4 12.3 (1296.2)
298.5 10.6 (1287.4)
297.6 12.2 (1278.8)
272.2 8.11 (1285.3)
Apache River (Jini) [ms]

10.1 0.94 (1097.3)
6.2 0.41 (1142.8)
13.4 0.56 (1112.5)
6.6 0.32 (1245.9)
7.6 0.48 (1215.3)
8.2 0.71 (1267.0)
8.3 0.62 (1208.1)
7.9 0.69 (1207.3)
Rezultatele indic faptul c serviciile implementate prin intermediul framework-ului Apache River
sunt mult mai rapide n compara ie cu serviciile realizate cu celelalte dou framework-uri de servicii
(ntre cele dou framework-uri de servicii web, Apache CXF i Jersey REST, nu exist practic
diferen e semnificative de performan ). Toate cele trei framework-uri se comport asem tor n
ceea ce prive te primul apel al serviciilor deoarece marea parte a timpului de execu ie este dedicat
conect rii la serverul OPC UA.
5.6.2 Citirea i scrierea variabilelor booleene
Cel de-al doilea test de performan a fost efectuat pentru a evalua performan a serviciilor de citire i
de scriere a variabilelor booleene care sunt folosite cel mai des n aplica iile industriale [Filho F. Sd.
L., 2006]. Toate variabilele booleene sunt stocate n grupuri de cte 16 n interiorul variabilelor
Int16. Astfel, mai multe variabile booleene pot fi scrise i citite simultan i timpul necesar
scrierii/citirii unui num r mare de astfel de variabile este redus semnificativ (rezultatele testului sunt
prezentate n tabelul 5.3).
Tab. 5.3. Citirea i scrierea variabilelor booleene.
Serviciu de baz
Citirea a 100 de
variabile booleene
Scrierea a 100 de
variabile booleene
Apache
CXF [ms]
Jersey
REST [ms]
Apache River
(Jini) [ms]
1059 34
918 32
37.8 2.1
1217 28
1340 57
59.3 3.2
i de aceast dat serviciile realizate cu framework-ul Apache River sunt mult mai rapide n
compara ie cu cele realizate cu framework-urile de servicii web.
5.6.3 Concluzii
n urma efectu rii celor dou teste de performan s-a luat decizia de a folosi n continuare serviciile
de baz dezvoltate prin intermediul framework-ului Apache River precum i de a dezvolta serviciile
complexe cu ajutorul aceluia i framework pentru a asigura timpi de reac ie ct mai mici. n ceea ce
prive te compara ia dintre framework-urile Apache CXF i Jersey REST, acestea prezint rezultate
96
asem toare, cu u oare avantaje pentru Apache CXF n cazul opera iilor de scriere i pentru Jersey
REST n cazul opera iilor de citire.
5.7 SERVICIILE COMPLEXE
Serviciile complexe poart aceast denumire deoarece pe de o parte ele sunt compuse de obicei din
servicii de baz , respectiv dintr-o serie de apeluri ale acestor servicii de baz , iar pe de alt parte
efectueaz opera ii complexe. Dup cum a fost precizat i n introducerea capitolului, serviciile
complexe pot fi mp ite n patru categorii:
servicii care controleaz i monitorizeaz produc ia;
servicii pentru gestionarea erorilor;
servicii care citesc date de configurare pentru modelele CSP aflate le nivelul superior al
arhitecturii;
servicii care furnizeaz informa ii generale despre procesul de fabrica ie.
Serviciile complexe utilizate pentru citirea datelor de configurare a modelelor CSP constau practic
dintr-o serie de apeluri ale serviciului de baz ReadVariableNodeService. Celelalte trei tipuri de
servicii complexe vor fi detaliate n sec iunile urm toare.
5.7.1 Servicii complexe pentru monitorizarea i controlul produc iei
Primul tip de servicii complexe recep ioneaz solu ia de la un model CSP i controleaz i
monitorizeaz produc ia unui set de piese. De obicei aceste servicii ruleaz un interval timp mai
lung. O problem particular a primului grup de servicii a fost monitorizarea alarmelor i
evenimentelor. De i serviciile complexe apeleaz numeroase servicii de baz pentru a ndeplini o
anumit sarcin , serviciile de baz nu pot fi utilizate pentru a detecta st rile de alarm . Figura 5.8
prezint solu ia utilizat pentru rezolvarea acestei probleme.
Fig. 5.8. Monitorizarea alarmelor i a evenimentelor prin intermediul serviciilor web.
Astfel, cnd un serviciu complex este apelat, acesta stabile te mai nti o conexiune cu serverul UA
i se aboneaz la alarmele i evenimentele care corespund ac iunii curente efectuate de serviciul
complex astfel nct s fie notificat de orice situa ie neprev zut . Apoi, n timpul execu iei, acesta
apeleaz mai multe servicii de baz pentru a controla procesul de fabrica ie conform solu iei
optimizate propuse de modelul CSP. n cazul n care apare o eroare n timpul procesului de
97
produc ie, serviciul complex fie opre te execu ia procesului i informeaz inginerul de apari ia
erorii, fie apeleaz un serviciu special utilizat pentru tratarea erorii [Sasa A., 2008].
A fost dezvoltat cte un serviciu complex pentru fiecare aplica ie utilizat la testarea arhitecturii
propuse. Astfel, trei servicii de acest gen sunt descrise n detaliu n capitolele 6 mpreun cu
aplica ia corespunz toare. Pentru a prezenta ns structura general a unui astfel de serviciu
complex, se va folosi una din aplica iile simple utilizate la testarea arhitecturii, care a fost utilizat
ca exemplu la prezentarea arhitecturii n figura 3.2.
Se presupune c o ntreprindere poate fabrica patru tipuri de uruburi i c ntreprinderea dispune de
trei sta ii de lucru pe care pot fi fabricate aceste uruburi. Tabelul 5.4 afi eaz timpii de fabricare
pentru fiecare ma in i pentru fiecare tip de urub. Clientul comand un anumit num r de uruburi
din fiecare tip i scopul este de a determina un plan de fabricare a uruburilor cu timp minim de
execu ie. Planul de fabricare este determinat prin realizarea i rezolvarea unui model CSP iar tabelul
5.5 prezint rezultatele pentru comanda din figura 3.2.
Tab. 5.4. Timp de fabricare (exprimat n minute) pentru fiecare tip de urub i pentru fiecare sta ie.
Tipul
urubului
R1
R2
R3
R4
Sta ia de
lucru 1
3
2
2
5
Sta ia de
lucru 2
2
4
3
6
Sta ia de
lucru 3
4
5
7
4
Tab. 5.5. Rezultatele problemei pentru comanda din figura 3.2.
Tipul
urubului
R1
R2
R3
R4
Timpul de
execu ie [min]
ST
1
0
2
5
0
14
ST 2
ST 3
4
0
0
1
0
1
0
2
14
13
Num rul total de

uruburi
4
3
5
3
Timpul de execu ie
total (max): 14
Dup determinarea solu iei, se apeleaz serviciul complex care controleaz fabricarea uruburilor
conform solu iei ob inute anterior. Figura 5.9 prezint structura simplificat a spa iului de adrese
corespunz tor acestui scenariu.
Punctul de intrare este reprezentat de obiectul Scenariu de test. La acest obiect sunt conectate alte
trei noduri obiect care sunt folosite pentru a organiza spa iul de adrese. Pentru fiecare nod Sta ie de
lucru exist patru variabile, una pentru fiecare tip de urub. n plus exist dou variabile Start i
Final, care sunt folosite pentru a ncepe procesul de fabricare i pentru a indica finalul s u. Serviciul
complex se va conecta la serverul UA i se va abona pentru a fi notificat referitor la modific rile
care apar asupra variabilei Final. Acesta se va abona i la obiectul Scenariu de test pentru a fi
notificat referitor la apari ia unei alarme sau a unui eveniment. Apoi, serviciul complex asociaz
valorile determinate prin modelul CSP celor 12 variabile apelnd succesiv serviciul
98
WriteVariableNode i de asemenea acesta porne te procesul de fabricare a uruburilor setnd

variabila Start la valoarea 1 (st rile celor 12 variabile sunt reflectate automat n interiorul
dispozitivelor de control prin intermediul serverului OPC UA [Leitner S.H., 2006]). n continuare,
serviciul a teapt s fie notificat n leg tur cu finalizarea procesului de fabricare. Se poate observa
astfel cum conexiunea UA dintre serviciul complex i serverul UA (figura 5.8) nu este necesar
numai pentru gestionarea erorilor ci i pentru a a tepta apari ia unei modific ri n proces (de
exemplu finalizarea procesului). Pentru scenariul de test prezentat, ordinea n care uruburile sunt
fabricate pe sta iile de lucru nu este important , scopul fiind doar acela de a distribui timpul de lucru
n mod echilibrat pe sta iile disponibile.
Fig. 5.9. Spa iul de adrese pentru scenariul de test i serviciul complex corespunz tor utilizat pentru
monitorizarea i controlul execu iei.
5.7.2 Servicii complexe pentru gestionarea erorilor

Aceste servicii sunt apelate de serviciile complexe utilizate pentru controlul i monitorizarea
execu iei dup cum a fost prezentat n figura 5.9. Pentru a exemplifica modul de func ionare al
acestor servicii, s-a ales un exemplu bazat pe aplica ia descris n capitolul 6. n cadrul acelei
aplica ii s-a folosit o sta ie de montare a uruburilor pe diverse piese, sta ie care face parte din linia
flexibil aflat n laboratorul universit ii. Figura 5.10 prezint opera iile realizate de serviciul
complex precum i acea parte a spa iului de adrese care este de interes pentru gestionarea erorii care
va fi detaliat n continuare. Opera ia const n montarea a dou , trei sau patru uruburi n g urile
piesei. Nodul variabil Nr. uruburi reprezint num rul de uruburi care trebuie montate pe piesa
curent . Variabila uruburi montate reprezint num rul de uruburi montate pe pies la un anumit
moment dat. n plus, exist o metod (Setare) care poate fi folosit pentru setarea variabilei uruburi
montate la o anumit valoare. Aceast metod suprascrie valoarea contorului stocat n interiorul
automatului programabil care controleaz sta ia respectiv .
99
Fig. 5.10. Exemplu de serviciu complex pentru gestionarea erorilor i spa iul de adrese corespunz tor.
Ini ial serviciul se conecteaz

la severul UA, apoi apeleaz
serviciul de baz
ReadAlarmEventService pentru a determina momentul exact de timp la care a ap rut eroarea. n
continuare, apeleaz serviciul de baz ReadAtTimeService pentru a determina valoarea nodului
variabil uruburi montate la momentul apari iei erorii. Apoi, se alc tuie te un raport cu aceste
informa ii, care se transmite inginerului de mentenan corespunz tor. Acesta este un exemplu de
gestionare pasiv a erorii, care practic doar ntrerupe func ionarea instala iei i transmite un raport
tre persoana responsabil . Se pot n schimb dezvolta i servicii de gestionare activ a erorilor. n
acest caz, n locul alc tuirii unui raport, dac se poate elimina automat cauza erorii, procesul de
fabricare se poate relua, de la un anumit num r de uruburi montate (setat prin apelul metodei
Setare).
5.7.3 Servicii complexe pentru determinarea valorilor parametrilor KPI
Att arhitectura propus ct i serviciile prezentate sunt destinate nivelului MES al piramidei de
automatizare. Unul din avantajele cheie ale arhitecturii este c prin configura ia acesteia, ea poate fi
utilizat i pentru a determina valorile unor parametri cheie ai produc iei, necesari la nivelul ERP al
arhitecturii [Nieuwenhuyse I.V., 2011].
Pentru exemplificare, s-a dezvoltat un serviciu complex care colecteaz o serie de informa ii cheie
de la serverul UA i care se bazeaz pe aceea i sta ie de montare a uruburilor (figura 5.11 prezint
att opera iile serviciului complex ct i spa iul de adrese corespunz tor). Serviciul preia ca
parametrii de intrare momentul de start i de final al unui anumit interval de timp. Ini ial serviciul se
conecteaz la serverul UA i apoi apeleaz de dou ori serviciul de baz ReadAtTimeService pentru
a determina num rul de piese prelucrate n intervalul de timp specificat pe baza nodului variabil
Piese prelucrate. Practic, serviciul de baz este apelat de dou ori, o dat cu momentul de start i o
dat cu momentul de final al intervalului de timp, iar parametrul suplimentar are n ambele cazuri
valoarea 0, ceea ce nseamn c se returneaz ultima valoare nregistrat nainte de momentul de
specificat. Din diferen a celor dou valori rezult num rul de piese prelucrate. n continuare se
apeleaz serviciul de baz ReadProcessedService, pentru nodul variabil Timp prelucrare, iar
parametrul suplimentar are valoarea 3, ceea ce nseamn c se determin media timpilor de
prelucrare pentru intervalul de timp specificat. n final se apeleaz serviciul de baz
ReadAlarmEventService pentru a determina num rul de alarme nregistrate n intervalul de timp
specificat.
100
Fiecare dintre cele trei ac iuni conduce la determinarea valorii unui parametru KPI, n final
alc tuindu-se un raport cu cele trei valori, care este transmis persoanei corespunz toare de la nivelul
ERP al ntreprinderii.
Fig. 5.11. Exemplu de serviciu complex care furnizeaz informa ii generale despre procesul de fabrica ie i
spa iul de adrese corespunz tor.
5.8 CONCLUZII
n acest capitol au fost introduse detaliile nivelului intermediar al arhitecturii propuse n capitolul 3.
Acest nivel este format dintr-o serie de servicii software de baz i servicii software complexe.
n prima parte a capitolului au fost introduse trei concepte diferite pentru implementarea serviciilor
software, i anume: servicii web SOAP (framework-ul Apache CXF), servicii web REST
(framework-ul Jersey REST) i servicii Java (framework-ul Apache River).
Dup prezentarea caracteristicilor principale ale celor trei framework-uri, s-au introdus serviciile de
baz dezvoltate pentru arhitectur . Acestea au fost dezvoltate pentru a simplifica comunica ia cu
serverele UA care se afl la nivelul de baz al arhitecturii. Toate serviciile de baz reprezint clien i
OPC UA i din acest motiv trebuie s realizeze conexiuni cu serverul UA corespunz tor. Deoarece
realizarea unei astfel de conexiuni necesit un timp substan ial, s-au dezvoltat dou strategii bazate
pe sesiuni pentru a reutiliza conexiunile stabilite. Versiunea adoptat n final propune memorarea
unei conexiuni UA n interiorul fiec rui serviciu pentru fiecare client care apeleaz acel serviciu.
Aceast variant este mai u or de implementat i permite de asemenea realizarea unor conexiuni
specializate pentru fiecare serviciu.
Serviciile de baz realizeaz opera ii de citire i scriere att pentru datele curente ct i pentru datele
istorice. n plus, au fost definite i servicii pentru citirea st rilor curente i istorice ale alarmelor.
Pentru alegerea unui framework de servicii care s fie utilizat n continuare n interiorul arhitecturii,
cele opt servicii de baz au fost implementate prin intermediul celor trei framework-uri descrise
anterior i au fost dezvoltate dou teste de performan . n urma efectu rii testelor a rezultat c
framework-ul Apache River conduce la timpi de execu ie mai scur i cu cel pu in un ordin de m rime
i prin urmare toate serviciile prezentate n continuare au fost implementate prin intermediul acestui
framework (att serviciile complexe ct i serviciile de baz ).
101
n continuare au fost prezentate cele patru tipuri de servicii complexe utilizate n interiorul
arhitecturii. Cea mai important categorie o reprezint serviciile utilizate pentru monitorizarea i
controlul produc iei. Aceste servicii preiau solu ia optim furnizat de un model CSP, o seteaz n
interiorul spa iului de adrese al serverului UA corespunz tor i pornesc fabricarea pieselor. Pe
timpul produc iei se monitorizeaz erorile i se apeleaz serviciile complexe corespunz toare pentru
gestionarea acestora. S-a prezentat cte un exemplu reprezentativ pentru categoria serviciilor
complexe de gestionare a erorilor i pentru categoria serviciilor complexe care furnizeaz informa ii
generale despre procesul de fabrica ie.
Serviciile software au fost introduse ca i component median n arhitectur pentru a asigura
flexibilitatea, adaptabilitatea i reutilizabilitatea acesteia. De i n acest fel num rul total al
componentelor software necesare pentru controlul produc iei a crescut i astfel i aspectele de
comunica ie dintre componente pot duce la ntrzieri, s-a ar tat c prin intermediul framework-ului
Apache River timpii de r spuns sunt foarte scur i i practic nu mpiedic func ionarea corect a
arhitecturii. Acest aspect va fi demonstrat n urm toarele dou capitole, care prezint dou aplica ii
concrete pentru arhitectura propus .
102
6 UTILIZAREA ARHITECTURII ORIENTATE

PE SERVICII PENTRU OPTIMIZAREA UNUI
PROCES INDUSTRIAL DE FABRICARE A
MECANISMELOR DE ROTA IE
6.1 PREZENTAREA PROBLEMEI

n cadrul acestui capitol este prezentat aplica ia principal pentru care a fost dezvoltat arhitectura
introdus n capitolul 3. Aplica ia a fost formulat pe baza liniei flexibile FMS-200 care este
disponibil n cadrul unui laborator al universit ii.
Pentru a testa arhitectura n contextul unei aplica ii complexe, s-a formulat o problem care
utilizeaz mai multe linii flexibile, una dintre ele fiind linia FMS 200. Astfel se presupune c o uzin
dispune de patru linii flexibile care pot efectua n total cinci opera ii diferite pentru fabricarea a trei
tipuri diferite de mecanisme de rota ie (figura 6.1 prezint un astfel de mecanism de rota ie). Primele
dou linii flexibile pot efectua primele dou opera ii: frezare i g urire. Celelalte dou linii flexibile
efectueaz cele trei opera ii r mase: plasarea uruburilor, fixarea uruburilor i inspec ia produsului
final. Diferen a principal dintre cele trei tipuri de produse este dat de num rul de uruburi care
trebuie montate i n urubate (dou , trei sau patru uruburi).
Un client plaseaz o comand prin care specific num rul de piese dorite din fiecare tip. n aceste
condi ii se va formula o problem de scheduling al c rei scop este de a determina un orar de lucru
care s permit fabricarea automat a pieselor, f
interven ia unui operator uman, ntr-un timp ct
mai scurt.
Fig. 6.1. Mecanism de rota ie.
Trei dintre cele patru linii flexibile vor fi simulate iar cea de-a patra linie este linia flexibil FMS
200. Aceast linie con ine trei celule de fabrica ie care efectueaz ultimele trei opera ii necesare
103
6. UTILIZAREA ARHITECTURII ORIENTATE PE SERVICII PENTRU OPTIMIZAREA UNUI PROCES INDUSTRIAL DE

FABRICARE A MECANISMELOR DE ROTA IE
pentru finalizarea produsului. Figura 6.2 prezint structura complet utilizat n cadrul aplica iei. Un
server OPC UA agregator, construit dup principiile prezentate n capitolul 4, modeleaz n
interiorul spa iului s u de adrese toate datele corespunz toare celor patru linii flexibile.
Simulatoarele construite n interiorul serverului OPC UA reac ioneaz la modific rile valorilor
con inute n spa iul de adrese, introducnd timpi de ntrziere egali cu suma dintre durata opera iilor
i timpii de comunicare cu dispozitivele de control. Astfel, din punctul de vedere al arhitecturii
software, pentru care serverul OPC UA reprezint nivelul de baz , nu se face nici o distinc ie ntre
liniile flexibile simulate i cea real . Pentru stabilirea comunica iei dintre serverul OPC UA i linia
flexibil FMS 200 se folose te solu ia software special de adaptare introdus n capitolul 4, ceea ce
nseamn c se introduce un server OPC clasic ntre serverul OPC UA i dispozitivele de control ale
celulelor.
Fig. 6.2. Structura aplica iei bazate pe linia flexibil FMS 200.
Dispozitivele de control ale celulelor liniei flexibile FMS 200 sunt automate programabile Siemens
S7-300. Pe lng automatele programabile ale celulelor exist i un master (tot un automat
programabil S7-300) care coordoneaz ac iunile celulelor i care controleaz banda de transport
utilizat pentru mutarea pieselor de la o celul la alta. Comunica ia ntre toate dispozitivele de
control se realizeaz printr-o re ea Profibus. Celulele liniei flexibile pot fi folosite att individual, ct
i n cadrul unui scenariu de fabrica ie complex, caz n care opera iile celulelor sunt controlate de
master.
104

Situa ia prezentat n figura 6.2 este una avantajoas deoarece este suficient ca serverul OPC UA s
comunice cu master-ul liniei flexibile. Acesta colecteaz toate datele relevante de la dispozitivele de
control ale celulelor, astfel nct nu mai este nevoie s se stabileasc separat conexiuni directe cu
acestea. Comunica ia dintre serverul OPC clasic i master se realizeaz printr-un adaptor MPIRS232 iar comunica ia dintre serverul OPC clasic i serverul OPC UA agregator se realizeaz prin
intermediul unui client OPC clasic construit n cadrul serverului, care comunic cu serverul clasic cu
ajutorul SDK-ului JEasyOPC.
Tabelul 6.1 prezint timpii de execu ie ai celor cinci opera ii, pentru cele trei produse diferite i
pentru cele patru sta ii (n continuare prin sta ii se va face referire la liniile flexibile ale aplica iei).
Se poate observa faptul c ace ti timpi difer n func ie de opera ie, de sta ie dar i de piesa
fabricat . n plus, pentru a modela corect procesul de fabrica ie trebuie inclu i i timpi de transport,
att ntre celulele unei sta ii (unde se folose te o band transportoare controlat de c tre master) ct
i ntre sta ii. Timpii de transport sunt prezenta i n tabelul 6.2. Ace ti timpi sunt independen i de
sta ii, de aceea se prezint doar timpii de transport ntre cele cinci opera ii.
Tab. 6.1. Timpii de execu ie ai opera iilor pe cele patru sta ii [s].
Sta ie
Produs
Frezare
urire
Sta ie
Plasare uruburi
Robot
Inspec ie
Mec. de
Rota ie 1
80s
15s
10s
40s
10s
Sta ia A
Mec. de
Rota ie 2
80s
20s
Sta ia C
15s
50s
15s
Mec. de
Rota ie 3
80s
25s
Mec. de
Rota ie 1
60s
20s
20s
60s
20s
15s
30s
10s
Sta ia B
Mec. de
Rota ie 2
60s
30s
Sta ia D
20s
40s
15s
Mec. de
Rota ie 3
60s
40s
25s
50s
20s
Tab. 6.2. Timpi de transport ntre celulele sta iilor [s].
Opera iile ntre care se

face transportul
Frezarea
G urire
urire
Plasare uruburi
Plasare uruburi Robot
Robot
Inspec ie
Timp
[s]
5
20
4
5
6.2 LINIA FLEXIBIL FMS 200

Linia flexibil FMS 200 este produs de SMC International Training, unul din liderii mondiali n
domeniul ac ion rilor pneumatice. Aceast linie flexibil este una didactic , destinat instruirii
inginerilor automati ti. n total sunt disponibile nou celule diferite, o posibil configura ie a liniei
flexibile fiind prezentat n figura 6.3.
Dup cum a fost precizat anterior, din totalul celor nou celule, pentru aplica ia curent se folosesc
trei celule care vor fi prezentate pe scurt n continuare. Fiecare celul dispune de un automat
105

programabil care controleaz opera iile acesteia i care permite operarea celulei de la un panou de
comand local sau n mod automat, coordonat de c tre master.
Fig. 6.3. Linia flexibil FMS 200.
6.2.1 Celula de plasare a uruburilor

Aceast celul efectueaz una din opera iile finale asupra mecanismelor de rota ie care const n
introducerea a dou , trei sau patru uruburi n g uri filetate n corpul de baz al mecanismului aflat
sub asamblare. Elementele principale ale celulei sunt prezentate n figura 6.4.
Fig. 6.4. Celula de plasare a uruburilor.
106

Tehnologia utilizat pentru efectuarea ac iunilor de la aceast celul este bazat pe diferi i cilindrii
pneumatici ceea ce nseamn c uruburile pot fi preluate i desc rcate doar n puncte fixe. n
consecin este necesar un element suplimentar pentru schimbarea succesiv a pozi iei piesei aflate
sub asamblare, astfel nct cele dou , trei sau patru cicluri de inserare de uruburi s conduc la
plasarea acestora n loca iile corespunz toare. Componentele utilizate pentru aceast opera ie sunt
un cilindru pneumatic de ridicare i un element de execu ie rotativ montat deasupra cilindrului
pneumatic, ambele fiind comandate similar de c tre master.
Spre deosebire de celelalte celule, unde comunica ia dintre dispozitivele de control i master este
limitat la transmisia unor mesaje de nceput i de finalizare a opera iilor, n cazul celulei de plasare
a uruburilor, trebuie realizat o sincronizare la fiecare ciclu de plasare a unui urub. Prin urmare se
utilizeaz extensiv posibilit ile de comunicare oferite de re eaua Profibus care conecteaz toate
dispozitivele de control ntre ele.
Func ia de plasare a unui urub implic o serie de opera ii care sunt descrise n continuare:
Modulul de furnizare a uruburilor: uruburile care trebuie inserate sunt stocate ntr-o
magazie vertical , de unde sunt desc rcate pe o carcas prin intermediul unui sistem de
alimentare pas cu pas care implic doi cilindrii pneumatici situa i unul deasupra celuilalt i
care se afl n permanen n pozi ii complementare (dac un cilindru este avansat, cel lalt este
retras i invers), astfel c atunci cnd cilindrul inferior este retras pentru a permite urubului s
ias din magazie, cilindrul superior este avansat pentru a men ine n pozi ia curent celelalte
uruburi ale magaziei. Ambii cilindrii revin n pozi ia ini ial dup ce urubul a p sit
magazia.
Modulul de transfer: Carcasa pe care sunt plasate uruburile este montat pe un cilindru
pneumatic cu dubl ac iune a c rui construc ie i permite s fie fixat de pl ci la fiecare cap t,
astfel nct partea mobil a cilindrului poate ac iona ca o sanie. Cilindrul este folosit pentru a
transfera uruburile de la punctul la care sunt eliberate din magazie pn la punctul n care
urm torul modul le preia pentru a le plasa pe pies .
Modulul de plasare a uruburilor pe pies : Odat ce elementele men ionate mai sus au
preluat i transferat un urub n punctul de preluare, un element pneumatic potrive te urubul
ntr-una din g urile piesei aflate n asamblare. Construit cu ajutorul a doi cilindri paraleli,
acest manipulator are dou grade de libertate corespunz toare axelor orizontale i verticale. La
cap tul manipulatorului se afl un gripper, care este folosit pentru a fixa uruburile cnd
acestea sunt transportate.
6.2.2 Celula robot
Spre deosebire de celula anterioar care folosea elemente de execu ie pneumatice, aceast celul
folose te tehnologii specifice domeniului roboticii. Opera ia efectuat de c tre robotul celulei const
n strngerea celor dou , trei sau patru uruburi montate n corpul mecanismului de rota ie la celula
precedent . Celula este prezentat n figura 6.5.
Controlul mi rilor robotului ntre diferitele puncte, pe care acesta trebuie s le ating , este realizat
prin intermediul unui dispozitiv de control, care a fost conceput special pentru comanda robotului
(acesta ndepline te func ia de a controla mi rile tuturor motoarelor ncorporate n robot).
107

Dispozitivul de control este comandat de c tre automatul programabil utilizat pentru celula aceasta.
Este de asemenea posibil ca mi rile robotului s fie programate direct n interiorul dispozitivului
de control. Programarea dispozitivului se realizeaz cu ajutorul unui software specializat care
ruleaz pe un calculator obi nuit i care comunic cu dispozitivul de control printr-o conexiune
serial .
Exist i o consol de programare pe care este posibil fie introducerea unui set de comenzi fie
definirea punctelor la care robotul trebuie s se mute. Precizia pozi ion rii permite plasarea capului
urubelni ei montate n vrful bra ului robotului deasupra fiec ruia dintre uruburile plasate pe
mecanismul de rota ie. Odat ce pozi ia este atins , n urubarea fiec rui urub se realizeaz pn la o
anumit adncime prestabilit .
Fig. 6.5. Celula robot.
6.2.3 Celula de inspec ie

Aceast celul realizeaz opera ia final , i anume inspec ia pieselor finale. Celula este prezentat n
figura 6.6.
Tehnologia utilizat pentru a efectua mi rile de la aceast celul este bazat pe diferite elemente
de execu ie pneumatice. Astfel, piesele sunt preluate de pe banda transportoare i sunt aduse n fa a
unei camere digitale care realizeaz inspec ia acestora.
n cazul acestei celule, sincronizarea cu master-ul const doar n transmisia/recep ionarea unor
mesaje de pornire i de finalizare a opera iilor de inspec ie.
Func ia de inspec ie implic o serie de opera ii care sunt descrise n continuare:
Modulul de preluare a mecanismelor de rota ie: elementul principal al acestui modul este
un actuator pneumatic rotativ, care printr-o mi care circular preia piesa de pe banda
transportoare i o plaseaz pe un stativ n fa a unei camere digitale. Mi carea rotativ
formeaz un semicerc i se desf oar ntre dou limitatoare de curs . Pentru a putea ridica
piesa se folosesc patru cupe de cauciuc care se plaseaz pe pies i n interiorul c rora se poate
genera o presiune sc zut .
108

Motorul pas cu pas: Stativul pe care sunt plasate piesele poate fi rotit cu ajutorul unui motor
pas cu pas, astfel nct s se inspecteze toate laturile piesei. Comenzile de deplasare pentru
motorul pas cu pas sunt generate de c tre automatul programabil utilizat pentru controlul
celulei prin intermediul unui bloc software special destinat motorului. La finalizarea
inspec iei, automatul programabil prime te un semnal binar care indic rezultatul pozitiv sau
negativ al inspec iei.
Modulul de evacuare a pieselor: n cazul n care rezultatul inspec iei este unul negativ,
pentru evacuarea piesei se folose te un mecanism pneumatic construit cu ajutorul a doi cilindri
pneumatici care ofer dou grade de libertate corespunz toare axelor verticale i orizontale.
Pentru ridicarea piesei se folose te un mecanism similar cu cel al primului modul, bazat pe
patru cupe de cauciuc n interiorul c rora se genereaz o presiune sc zut . n cazul n care
rezultatul inspec iei este unul pozitiv, primul modul este folosit pentru a plasa piesa napoi pe
banda transportoare.
Fig. 6.6. Celula de inspec ie.
6.3 MODELUL MIP

n cadrul acestui subcapitol se vor prezenta dou modele MIP care pot fi utilizate pentru a determina
un orar de lucru optim. Modelele generalizate au fost preluate din [Sawik T., 2011] i au fost apoi
adaptate la problema curent . Unul din cele mai importante aspecte care a necesitat modific ri a fost
introducerea unui timp de transport, att ntre sta ii ct i ntre celulele unei sta ii. Un sistem flexibil
de fabrica ie flexibil (FAS) poate fi considerat ca fiind o problem de tip job-shop flexibil. Dup
cum a fost prezentat n capitolul 2, un job shop reprezint o problem de optimizare clasic din
domeniul problemelor de scheduling. Problema este NP-hard i este considerat ca fiind una dintre
cele mai dificile probleme combinatorice de optimizare. Orarul de executare a opera iilor pe
ma inile existente trebuie s respecte urm toarele constrngeri: o sta ie poate procesa cel mult o
opera ie la un moment dat i procesarea unei opera ii nu poate fi ntrerupt de o alt opera ie.
Func ia obiectiv are ca scop ob inerea unui timp de final al produc iei care s fie minim.
109

Un FAS generalizat este o re ea de etape de asamblare care sunt interconectate prin elemente de
transport, unde fiecare etap const dintr-un num r de ma ini identice i paralele. Fiecare
sta ie/ma in are un spa iu de lucru finit pentru furnizorii de componente i pentru zonele tampon de
intrare i de ie ire care trebuie s stocheze produsele care a teapt s fie procesate i respectiv care
trebuie s fie trimise c tre alte sta ii.
Trebuie subliniat faptul c un sistem FAS este un sistem de produc ie multidirec ional care permite
revenirea la sta iile parcurse anterior. Un alt aspect important este acela c un sistem FAS poate
asambla simultan i la o rat ridicat , o varietate larg de tipuri de produse, ceea ce reprezint un
avantaj important n compara ie cu liniile de transfer conven ionale care sunt proiectate pentru
volume mari de lucru dar cu varietate de fabricare sc zut .
Cei mai importan i termeni pentru un sistem FAS, din punct de vedere al determin rii orarului de
lucru, sunt planificare i scheduling. Presupunnd c trebuie asamblate diverse produse, obiectivul
problemei de planificare este acela de a asocia opera ii de asamblare i furnizori de componente
sta iilor de asamblare cu spa ii de lucru limitate, scopul fiind acela de a determina rutele de
asamblare pentru diverse produse astfel nct s se ob in un volum de lucru echilibrat ntre sta ii.
Obiectivul problemei de scheduling este acela de a determina secven a detaliat i momentele de
timp pentru toate opera iile de asamblare ale fiec rui produs, astfel nct productivitatea sistemului
fie maximizat .
La implementarea modelelor MIP din aceast sec iune au fost folosite dou abord ri: o abordare
integrat i una ierarhic . La abordarea integrat deciziile de planificare i de scheduling se iau
simultan folosind un model MIP monolitic. La abordarea ierarhic sunt folosite dou modele, mai
nti unul pentru a echilibra volumul de lucru al sta iilor i apoi un model pentru a determina orarul
de lucru cu durata cea mai scurt de realizare a opera iilor, folosindu-se asocierea dintre opera ii i
sta ii determinat n cadrul primului model.
n total vor fi prezentate trei modele MIP:
LAS1a: model monolitic pentru planificare i scheduling simultan;
L1a: model ierarhic pentru planificare;
S|L1: model ierarhic pentru scehduling.
Datele de intrare ale algoritmilor LAS1a, L1a, S|L1 sunt prezentate n cele ce urmeaz :
Indici:
f = opera ie de asamblare f
i = sta ie de asamblare, i
k = produs, k
F;
{1,..., m} ;
{1,..., n} .
Parametrii de intrare:
aif = spa iul de lucru necesar efectu rii opera iei f pe sta ia i;
bi = spa iul de lucru total al sta iei i;
eifk = timpul de finalizare cel mai mic pe sta ia i a opera iei f, realizate pentru produsul k;
qifk = timpul de asamblare pe sta ia i a opera iei f, realizate pentru produsul k;
110

t fg = timpul de transport dintre opera ia f i opera ia g;

I f = subsetul de sta ii capabile s efectueze opera ia f;
Fk = subsetul de opera ii necesare produsului k;
Q = o constant pozitiv mai mare dect timpul total de produc ie;

R k = un set de perechi de opera ii predecesor-succesor (f, g) ale produsului k unde f i g sunt
opera ii succesive n interiorul subsetului Fk.
Variabile de decizie
cifk = timpul de finalizare pe sta ia i a opera iei f, realizate pentru produsul k;
xifk = variabil de asociere a produselor, care este egal cu 1 dac produsul k este asociat
sta iei i pentru a efectua opera ia f; altfel xifk
0;
y ifkgl = variabil de secven iere a opera iilor, care este egal cu 1 dac pe sta ia i opera ia f a
produsului k precede opera ia g a produsului l cnd ambele opera ii sunt asociate aceleia i
sta ii; altfel y ifkgl 0 (variabila este folosit n cazul abord rii monolitice);
y fkgl = variabil de secven iere a opera iilor, care este egal cu 1 dac opera ia f a produsului k
precede opera ia g a produsului l cnd ambele opera ii sunt asociate aceleia i sta ii; altfel
y fkgl 0 (variabila este folosit n cazul abord rii ierarhice);
z if = variabil de asociere a opera iilor, care este egal cu 1 dac opera ia f este asociat sta iei
i
I f ; altfel z if
0.
6.3.1 Modelul LAS1a

Acest model este utilizat pentru a realiza simultan planificarea i scheduling-ul opera iilor. Se
define te func ia obiectiv: minimizarea variabilei cmax, care reprezint cel mai mare timp de
finalizare a unei opera ii. n continuare sunt definite constrngerile modelului.
Constrngeri pentru asocierea opera iilor
Fiecare opera ie este asociat cel pu in unei sta ii de asamblare (sunt permise rute alternative).
Spa iul de lucru total necesar efectu rii unei opera ii pe fiecare sta ie de asamblare nu poate dep i
spa iul de lucru finit disponibil pentru sta ia respectiv .
z if
1;
(7.1)
i If
aif z if
bi ; i
(7.2)
i If
Constrngeri pentru atribuirea produselor

Fiecare opera ie a unui produs poate fi asociat unei singure sta ii. Fiecare produs poate fi
direc ionat c tre sta iile unde opera iile necesare finaliz rii produsului pot fi efectuate.
111

xifk
1; k
K, f
Fk
(7.3)
i If
xifk
z if ; k
K, f
Fk , i
(7.4)
If
n plus, se adaug un set de constrngeri care asigur c pentru sta iile identice din punctul de vedere
al opera iilor care pot fi executate, opera iile unui anumit produs se efectueaz mereu pe aceea i
sta ie.
xijk
xi ( j
1) k
; k
K,i
If, j
(7.5)
0,2,3
Constrngeri pentru finalizarea produsului

n cazul n care un produs este direc ionat de mai multe ori la o anumit sta ie pentru a-i fi efectuate
opera iile necesare finaliz rii sale, atunci pentru fiecare opera ie a acelui produs, momentul
finaliz rii opera iei pe sta ia respectiv nu poate fi mai mic dect momentul de finalizare cel mai
recent determinat pentru acea sta ie. Procesarea fiec rei opera ii a fiec rui produs nu poate fi
nceput nainte de momentul de finalizare a proces rii opera iei precedente la care se adaug i
timpul de transport.
Prima constrngere impune limite inferioare i superioare asupra timpilor de finalizare. Cea de-a
doua constrngere men ine rela ii de precedent ntre opera iile fiec rui produs.
eifk xifk
c ifk
cigk
i Ig
Qx ifk ; k
qifk xigk
K, f
cifk
i Ig
Fk , i
t fg ; k
(7.6)
If
K , ( f , g)
Rk
(7.7)
i If
Constrngeri pentru evitarea suprapunerii proces rii pieselor

Nu pot fi procesate simultan dou opera ii pe aceea i sta ie.
cifk
Q (2
y ifkgl
xifk
xigl )
c igl
q ifk ; k , l
K, f
Fk , g
Fl , i
If
Ig ;k
(7.8)
cigl
Q (3
y ifkgl
xifk
xigl )
cifk
qigl ; k , l
K, j
Fk , g
Fl , i
If
Ig ;k
(7.9)
Aceste rela ii reprezint constrngeri de disjunc ie impuse asupra ma inilor. Fiind dat o anumit
secven de opera ii, cel mult o constrngere este activ i anume doar n cazul n care att opera ia f
a produsului k ct i opera ia g a produsului l sunt asociate aceleia i sta ii i.
Constrngeri pentru timpul maxim de finalizare a fabric rii pieselor
Prin acest tip de constrngere este determinat cel mai mare timp de finalizare a unui anumit produs
pe o anumit sta ie.
cifk
c max ; k
K, f
Fk , i
If
Constrngeri de pozitivitate i integritate a variabilelor

cifk
112
0; k
K, f
Fk , i
If
(7.10)

xifk
{0,1}; k
y ifkgk
z ifk
K, f
{0,1}; k , l
{0,1};
cmax
Fk , i
K, f
K,i
If
Fk , i
If
Ig : k
(7.11)
If
Timpul cel mai recent de finalizare pe sta ia i a opera iei f realizate pentru produsul k, eifk, este o
constant a modelului i reprezint suma dintre qifk i timpul minim de asamblare a tuturor
opera iilor f ' Fk care preced opera ia f.
eifk
qifk
min i
f ' Fk : f ' f
f'
(qif 'k )
(7.12)
6.3.2 Modelul L1a

Acest model este utilizat pentru a realiza planificarea opera iilor. Se define te func ia obiectiv:
minimizarea volumului de lucru maxim reprezentat prin variabila W. n continuare sunt definite
constrngerile modelului.
Constrngeri de asociere a opera iilor
Aceste constrngeri asigur faptul c fiecare opera ie este asociat cel pu in unei sta ii de asamblare
(aceea i opera ie poate fi efectuat pe sta ii diferite pentru produse diferite deoarece sunt admise rute
alternative) i c spa iul de lucru total, necesar efectu rii opera iilor pe fiecare sta ie de asamblare,
nu poate dep i spa iul de lucru finit al fiec rei sta ii.
z if
1;
(7.13)
i If
aif z if
bi ; i
(7.14)
i If
Constrngeri pentru asocierea produselor

Cel de-al doilea pas const n definirea constrngerilor pentru asocierea produselor. Acestea asigur
faptul c fiecare produs este asociat unei singure sta ii pentru a efectua o anumit opera ie i c
fiecare produs poate fi direc ionat c tre sta iile unde vor fi efectuate opera iile necesare finaliz rii
sale:
xifk
1; k
K, f
Fk
(7.15)
i If
xifk
z if ; k
K, f
n plus trebuie ad ugat
113
Fk , i
If
i constrngerea exprimat prin ecua ia (7.5).
(7.16)

Constrngeri referitoare la volumul de lucru maxim

Cel de-al treilea pas const n specificarea constrngerilor care iau n calcul volumul de lucru maxim
al fiec rei sta ii. Astfel, pentru fiecare sta ie, timpul total de asamblare necesar efectu rii opera iilor,
nu poate dep i volumul de lucru maxim (care urmeaz a fi minimizat).
qifk xifk
W; i
(7.17)
k K f Fk

xifk
{0,1}; k
K, f
z if
{0,1};
F,i
Fk , i
If
(7.18)
If
6.3.3 Model S|L1

Acest model este utilizat pentru scheduling-ul opera iilor. Se define te func ia obiectiv: minimizarea
variabilei cmax, care reprezint cel mai mare timp de finalizare a unei opera ii. n continuare sunt
definite constrngerile modelului.
Constrngeri pentru evitarea suprapunerii proces rii pieselor
Aceste constrngeri asigur faptul c oricare dou opera ii a dou produse diferite asociate aceleia i
sta ii nu pot fi prelucrate simultan:
cifk
Qy fkgl
cigl
cigl
Q (1 y fkgl )
q ifk ; k , l
K, f
q igl ; k , l
cifk
Fk , g
K, f
Fl , i
Fk , g
L
l , x ifkL xigl
I :k
Fl , i
I :k
(7.19)
L
l , xifkL x igl
(7.20)
Constrngerile sunt definite doar pentru acele perechi de opera ii (f, g) care sunt asociate aceleia i
sta ii i (opera ia f apar ine produsului k i opera ia g ce apar ine produsului l), adic n cazul n care
L
1.
xifkL xigl
Constrngeri pentru finalizarea produsului
Aceste constrngeri asigur faptul c timpul de finalizare a fiec rei opera ii a unui produs pe o
anumit sta ie nu poate fi mai mic dect timpul cel mai recent de finalizare pe acea sta ie, c
efectuarea fiec rei opera ii a fiec rui produs nu poate fi nceput nainte de momentul de finalizare a
proces rii opera iei precedente, la care se adaug i timpul de transport, i c opera iile succesive ale
fiec rui produs, asociate aceleia i sta ii, sunt efectuate f pauze.
K, f
Fk , i
I f : x Ljfk
(7.21)
cifk
eifk ; k
c hgk
q hgk
cifk
t fg ; k
K, ( f , g)
Rk , i , h
cigk
q igk
c ifk
t fg ; k
K, ( f , g)
Rk , i
I :i
L
h, x Ljfk x hgk
L
I : x Ljfk x hgk
(7.22)
(7.23)
Ultimele dou constrngeri men in rela iile de preceden dintre opera iile aceluia i produs.
114

Constrngeri referitoare la timpul maxim de finalizare a produselor

Cel de-al treilea pas al modelului const n specificarea timpului maxim de finalizare a produselor.
Astfel, durata de prelucrare este determinat de timpul maxim de finalizare a tuturor produselor i
durata de prelucrare nu poate fi mai mic dect volumul de lucru maxim.
cifk
cmax
c max ; k
K, f
Fk , i
I f : xifkL
(7.24)
WL
(7.25)
unde W L este valoarea solu iei ob inute ca urmare a rezolv rii modelului L1a.
cifk
y fkgl
K, f
Fk , i
I f : xifkL
{0,1}; k , l
K, f
Fk , g
0; k
(7.26)
1
L
xifkL xigl
Fl :
i I
Timpul de finalizare cel mai mic eifk se calculeaz cu urm toarea formul
modelului MIP:
eifk
min (q if 'k )
q ifk
f ' Fk : f ' f
i If'
i reprezint o constant a
(7.27)
Aceast expresie semnific faptul c timpul de finalizare cel mai mic eifk este suma dintre timpul de
asamblare pentru sta ia, produsul i opera ia curent i timpul minim total de asamblare al tuturor
opera iilor f ' Fk ale produsului curent, care preced opera ia curent .
Cele dou modele prezentate n aceast sec iuni pot fi implementate cu oricare din solver-ele
descrise n capitolul 2 (Choco, JaCoP i JLPI).
6.4 IMPLEMENTARE
n figura 6.7 este prezentat secven a de opera ii urmate pentru a fabrica piesele comandate de un
client.
Fig. 6.7. Opera ii executate pentru fabricarea pieselor.
Ini ial se apeleaz un serviciu complex care cite te datele de configurare ale modelelor MIP din
spa iul de adrese al serverului OPC UA (acest serviciu complex este format din apeluri succesive ale
serviciului de baz de citire ReadVariableNodeService). Apoi se execut modelul MIP i se
115

determin un orar de lucru optim. n continuare se porne te serviciul complex care preia solu ia
modelelor MIP i o insereaz n spa iul de adrese al serverului prin apelul repetat al serviciului de
baz de scriere (WriteVariableNodeService apelarea se realizeaz din interiorul firului de execu ie
al solver-ului MIP). n final se porne te fabricarea pieselor, se monitorizeaz execu ia, interveninduse n cazul apari iei unei erori.
n urm toarele sec iuni vor fi prezentate pe rnd detaliile spa iului de adrese, ale serviciului complex
de monitorizare, precum i modific rile realizate la nivelul automatelor programabile.
6.4.1 Spa iul de adrese al serverului OPC UA
Spa iul de adrese este unul dintre cele mai importante concepte ale ntregii arhitecturi. Dup cum se
poate observa n figura 6.2, a fost folosit un singur server UA pentru ntreaga aplica ie. n general
alegerea unui singur sau a mai multor servere UA depinde de complexitatea aplica iei i a
dispozitivelor, aspecte reflectate i de complexitatea spa iului de adrese. n general se recomand
utilizarea unui singur server UA pentru o aplica ie, dar aceasta nu este o abordate obligatorie.
Figura 6.8 ilustreaz spa iul de adrese simplificat al aplica iei curente. La pornirea serverului OPC
UA, acesta este creat prin intermediul algoritmilor de generare a spa iului de adrese prezenta i n
capitolul 4. Spa iul de adrese este divizat n trei p i principale:
Opera ii: date privind cele cinci opera ii care trebuie efectuate: spa iul de lucru, timpul de
procesare al fiec rei opera ii i timpul de transport. Deoarece spa iul de lucru ocupat de o
opera ie depinde de sta ia pe care se va executa acea opera ie, aceast variabil reprezint de
fapt un tablou unidimensional de variabile, al c rui dimensiune este dat de num rul sta iilor
(patru n cazul de fa ). Deoarece sunt cunoscute sta iile pe care se pot efectua opera iile,
spa iul de lucru al unei opera ii pentru o anumit opera ie va fi egal cu 1 dac opera ia se poate
executa pe acea sta ie i 1000 n caz contrar (1000 este considerat o valoare ntreag foarte
mare i este folosit n loc de infinit). De exemplu, opera ia de frezare va avea spa iul de lucru
egal cu 1 pentru sta iile A i B i egal cu 1000 pentru sta iile C i D. Pe baza informa iilor
con inute n aceste variabile se va ini ializa parametrul de intrare aif al modelelor MIP. n ceea
ce prive te timpul de procesare, acesta depinde att de produs ct i de sta ie. n aceste condi ii
variabilele Timp procesare de sub fiecare opera ie sunt de fapt tablouri bidimensionale, care
con in timpul de procesare al opera iei respective pe fiecare sta ie i pentru fiecare produs. n
cazul n care o opera ie nu se poate efectua pe o anumit opera ie (de exemplu frezarea nu se
poate efectua pe sta iile C i D), atunci se va introduce o valoare foarte mare (1000) n loca ia
respectiv . Pe baza informa iilor con inute n aceste variabile se va ini ializa parametrul de
intrare qifk. n ceea ce prive te timpul de transport se folose te o variabil care reprezint de
fapt un tablou bidimensional i care stocheaz timpii de transport ntre oricare dou opera ii
succesive. Pe baza informa iilor con inute n aceste variabile se va ini ializa parametrul de
intrare tfg. n cazul n care nu se poate efectua transportul ntre anumite opera ii, se va
introduce valoarea 1000 n loca ia corespunz toare.
Produse: date privind opera iile necesare fiec rui produs. Variabilele Op. 1 Op. 5 sunt
variabile booleene ale c ror valori indic dac o anumit opera ie este necesar la fabricarea
unui anumit produs. n cazul de fa toate opera iile sunt necesare pentru fiecare produs, ns
116

folosind aceast abordare, spa iul de adrese cu aceast structur poate fi folosit i pentru alte
procese tehnologice, unde nu trebuie executate toate opera iile pentru fiecare produs.
Sta ii: date privind opera iile efectuate pe fiecare sta ie i spa iul de lucru total disponibil
pentru acea sta ie. Pe baza spa iului de lucru total, se va ini ializa parametrul de intrare bi al
modelelor MIP. Deoarece pentru aplica ia curent spa iul de lucru ocupat de fiecare opera ie
este egal cu 1 dac opera ia se poate efectua pe sta ia respectiv , spa iul total de lucru al unei
sta ii va fi egal cu num rul total de opera ii care se pot efectua pe acea sta ie (2 pentru sta iile
A i B i 3 pentru sta iile C i D). n plus, pentru fiecare sta ie exist o serie de obiecte care
reprezint celulele de fabrica ie ale sta iei respective.
Pe baza informa iilor extrase din spa iul de adrese se pot astfel ini ializa to i parametri de intrare ai
modelelor MIP utilizate pentru aceast aplica ie. Ini ializarea parametrilor aif, bi, qifk i tfg a fost deja
descris , parametrul eifk este calculat cu ajutorul ecua iilor (7.12), respectiv (7.26) iar parametrii If,
Fk i Rk sunt calcula i pe baza parametrilor de intrare determina i din spa iul de adrese.
Variabila Componente procesate a fost inclus ca exemplu de variabil KPI: aceasta num
cte
piese au fost procesate pe sta ia respectiv . Aceast valoare poate fi apoi citit la sfr itul lunii (sau
dup un anumit interval de timp) de c tre un serviciu pentru a fi raportat la nivelul ERP al
ntreprinderii.
Fig. 6.8. Spa iul de adrese corespunz tor aplica iei.
Figura 6.9 prezint spa iul de adrese corespunz tor celulei 1 a liniei flexibile FMS 200. n primul
rnd acesta con ine toate semnalele de intrare i de ie ire ale sta iei. Semnalele de intrare reprezint :
capetele de curs ale modulului de plasare a uruburilor pe direc ia orizontal (a_0, a_1) i vertical
(b_0, b_1), starea gripper-ului (c_0, c_1), pozi ia modulului de transfer (e_0, e_1) i senzorul de
prezen pies (p_t). Semnalele de ie ire reprezint : mi carea modulului de plasare a pieselor pe
direc ie orizontal (A+, A-) i vertical (B+), nchiderea gripper-ului (C+), schimbarea pozi iei
117

cilindrilor modulului de furnizare uruburi (D+) i mi carea modulului de transfer (E+, E-). St rile
tuturor acestor semnale sunt actualizate periodic, conform descrierii din sec iunea 4.3.2.3.
n spa iul de adrese al acestei celule sunt de asemenea reprezentate cele trei alarme care pot s apar
la aceast sta ie, i anume lipsa condi iilor ini iale (cilindrii pneumatici nu se afl n pozi ia ini ial
atunci cnd trebuie pornit un ciclu de plasare a unui urub), lipsa uruburilor din magazie i ciclu
nefinalizat (dac apare o problem pe parcursul ciclului de plasare a unui urub i celula se
blocheaz sau se opre te). Tot n spa iul de adrese al celulei se stocheaz rezultatele modelului MIP:
prima coloan reprezint tipul produsului, cea de-a doua reprezint momentul de start al plas rii
uruburilor, n timp ce cea de-a treia coloan reprezint momentul de final al plas rii uruburilor (n
realitate timpii ar putea varia u or, dar aspectul important n acest caz este ordinea pieselor). n plus,
au mai fost create trei noduri suplimentare (dou variabile i o metod : Nr. uruburi, uruburi
montate i Setare), care reprezint num rul total de uruburi care trebuie plasate (dou , trei sau
patru), num rul de uruburi plasate la un moment dat pe piesa curent precum i o metod care
permite suprascrierea num rului de uruburi plasate pn n prezent. Aceste trei noduri sunt folosite
de c tre un serviciu complex de gestionare a erorilor, care a fost prezentat n capitolul 5 n figura
6.10. Spa iul de adrese al celorlalte celule este structurat asem tor.
Fig. 6.9. Spa iul de adrese corespunz tor celulei 1 (de plasare a uruburilor).
6.4.2 Serviciul complex

Procesul de fabricare a mecanismelor de rota ie comandate de client este supervizat de un serviciu
complex dezvoltat special pentru aceast aplica ie i prezentat n figura 6.10.
Ini ial serviciul se conecteaz la serverul UA i se aboneaz la variabila Final precum i la alarmele
tuturor sta iilor i celulelor utilizate n aplica ie. Apoi, rezultatele MIP preluate ca parametru de
intrare (variabila cifk reprezint momentele de final ale execu iei opera iilor, dar fiind date duratele
de procesare, se pot determina i momentele de start) sunt nscrise n nodurile variabil
corespunz toare celor trei sta ii (nodurile Rezultate MIP ale celulelor). n continuare este setat
variabila Start i prin urmare procesul de fabrica ie ncepe.
Pe parcursul proces rii serviciul complex are rolul de a informa fiecare sta ie i fiecare celul de
piesa care trebuie procesat la momentul respectiv (ac iunea Seteaz tip pies n figura 6.10). Astfel,
118

la nceputul fiec rui interval de procesare, serviciul complex va apela serviciul de baz
WriteVariableNodeService pentru a asocia valoarea corect nodului Nr. uruburi afi at n figura 6.9.
Pentru realizarea acestei ac iuni, serviciul complex va lansa cte un fir de execu ie pentru fiecare
pies care va fi fabricat , apelul serviciul de baz realizndu-se din interiorul acestui fir de execu ie.
n timpul proces rii, serviciul este capabil s intervin n cazul n care apare o alarm prin apelarea
unui serviciu special (precum cel prezentat n figura 5.10). Dac nu este generat nici o alarm ,
atunci fabricarea pieselor se termin normal, dup cum a fost programat i ca urmare variabila
Final devine 1 i serviciul complex i termin opera ia (variabila Final devine 1 atunci cnd
nodurile variabil Ciclu nefinalizat ale celulelor de inspec ie ale sta iilor C i D devin 0 dup
inspec ia ultimei piesei conform planului de fabricare con inut n variabilele Rezultate MIP).
Fig. 6. 10. Serviciul complex utilizat pentru monitorizarea i controlul procesului de fabricare a mecanismelor
de rota ie.
Acest serviciu complex arat c o conexiune UA ntre un serviciu complex i serverul UA, dup
cum este ilustrat n figura 5.8, nu este necesar doar pentru gestionarea erorilor ci i pentru a
tepta o notificare din partea procesului, referitoare la finalizarea fabric rii.
n figura 6.11 este prezentat interfa a grafic utilizat pentru plasarea unei comenzi de c tre client
sau de c tre inginerul care gestioneaz procesul de fabricare. n partea din stnga sus a ferestrei se
introduce cantitatea dorit de piese din fiecare tip dup care se apas butonul Start. n continuare se
citesc datele de configurare din spa iul de adrese i se rezolv modelul MIP. Ca urmare se afi eaz
timpul total de fabricare al fiec rei sta ii precum i planul detaliat de fabrica ie al tuturor piese. n
figura 6.11 este prezentat ca i exemplu o comand format din nou piese (cte trei din fiecare tip).
Se poate observa c pentru fiecare pies sunt afi ate nou opera ii: cinci opera ii de procesare i
patru opera ii de transport.
Pentru fiecare opera ie se afi eaz intervalul de timp n care va avea loc opera ia respectiv precum
i sta ia pe care va avea loc opera ia. Suplimentar, pentru fiecare opera ie, se afi eaz i o c su tip
119

led, care poate avea patru culori: gri dac nc nu a nceput, portocaliu dac se afl n desf urare,
verde dac s-a ncheiat sau ro u dac a ap rut o eroare.
Fig. 6.11. Interfa a grafic utilizat pentru plasarea unei comenzi.
120

Astfel, pe parcursul desf ur rii procesului de fabrica ie, serviciul complex de monitorizare i
control va trebui s comunice fiec rei sta ii ce pies se prelucreaz la momentul respectiv, pentru a
putea realiza opera iile corespunz toare.
6.4.3 Modific ri ale programelor automatelor programabile
La livrarea liniei flexibile FMS 200, programele automatelor programabile erau configurate n a a
fel nct nu era posibil dect asamblarea mecanismelor de rota ie cu patru uruburi. Pentru a putea
testa problema descris n acest capitol pe linia flexibil , programele celor trei celule utilizate pentru
sta ia D au necesitat modific ri.
Modificarea cea mai ampl a avut loc la opera iile executate de c tre celula de plasare a uruburilor.
Dup cum s-a precizat anterior, la aceast celul este nevoie de o sincronizare suplimentar ntre
master-ul liniei flexibile i dispozitivul de control al celulei. Master-ul realizeaz rotirea piesei iar
dispozitivul de control al celulei asigur plasarea unui urub din magazie n pies . Master-ul este cel
care contorizeaz num rul de piese i care comand plasarea unui nou urub n pies . n acest sens
se folose te octetul MB47 din memoria intern a master-ului i pentru fiecare urub plasat, bit-ul
egal cu 1 logic este deplasat la dreapta (ini ial valoarea 1 logic este plasat n bit-ul 0 al octetului). n
cazul n care piesa necesit trei uruburi, se realizeaz deplasarea suplimentar la dreapta cu un bit
dup plasarea primului urub. n cazul n care piesa necesit doar dou uruburi, se realizeaz
deplasarea suplimentar la dreapta cu doi bi i dup plasarea primului urub. Instruc iunile necesare
efectu rii acestor opera ii sun prezentate n figura 6.12. Programul celulei de plasare a uruburilor nu
necesit nici o modificare. Pentru celelalte dou celule ale liniei flexibile, modific rile sunt mai
simple: n cazul celulei robot nu se precizeaz dect dou , trei sau patru seturi de coordonate,
corespunz toare celor dou , trei sau patru uruburi ale piesei. n cazul celulei de inspec ie trebuie de
asemenea doar specificat num rul total de uruburi care trebuie s se afle pe pies , astfel nct
decizia, dac piesa a fost corect fabricat sau nu, s fie luat corect.
Fig. 6.12. Re elele ad ugate n interiorul programului master-ului liniei flexibile.
6.5 REZULTATE
nainte de a testa efectiv arhitectura cu ajutorul aplica iei descrise n acest capitol, au fost rezolvate
urm toarele dou aspecte:
121

Determinarea modelului MIP cu o mai mare eficien (abordarea monolitic sau abordarea
ierarhic );
Determinarea solver-ului care conduce la timpul de execu ie cel mai scurt: deoarece modelul
este liniar acesta poate fi rezolvat cu oricare dintre cele trei solvere prezentate n capitolul 2.
n acest sens modelele MIP ale celor dou abord ri au fost rezolvate ini ial cu ajutorul celor trei
solver-e i rezultatele sunt prezentate n tabelul 6.3 pentru diferite numere de piese comandate
(ntotdeauna a fost specificat un num r egale de piese din fiecare tip). Timpii afi i n tabel pentru
abordarea ierarhic reprezint suma timpilor de execu ie ai celor dou modele (L1a i S|L1),
solu ionarea problemei de scheduling (S|L1) reprezentnd ntotdeauna aproximativ 80% din timpul
total. Rezultatele din tabel arat c solver-ul JLPI este cel mai rapid att n cazul abord rii ierarhice,
ct i n cazul abord rii monolitice, deoarece acesta este un solver special destinat modelelor liniare.
Celelalte dou solvere sunt apropiate ca i performan , cu u oare avantaje pentru solver-ul JaCoP.
Totu i, dac solver-ul JLPI nu poate fi utilizat (dac modelul este neliniar), solver-ul Choco este de
preferat deoarece acesta dispune de mai multe constrngeri, modelul este mai u or de construit i se
economise te timp important la implementarea problemei.
Tab. 6.3. Timpii de execu ie ai solver-elor pentru cele dou abord ri de modelare [s].
Solver
Abordare monolitic
Choco JaCoP JLPI
Abordare ierarhic
Choco JaCoP JLPI
0.88
13.74
59.23
421.4
0.19
3.45
14.62
97.38
Piese
9
18
36
72
0.85
13.12
57.63
412.9
0.21
5.08
17.67
91.34
0.18
3.25
13.78
95.42
0.06
1.34
4.87
27.13
Din tabelul 6.3 se poate observa c , pentru solver-ul JLPI, abordarea ierarhic este mai rapid dect
cea monolitic , raportul timpilor variind n func ie de num rul de piese ntre 3.36 i 3.79. Din acest
punct de vedere abordarea ierarhic este de preferat, ns aceasta conduce i la timpi de fabricare
mai mari (deoarece modelul este practic divizat n dou p i nu se poate determina solu ia optim ).
Pentru a lua o decizie corect n ceea ce prive te modelul folosit pentru aceast aplica ie, n tabelul
6.4 se prezint timpii totali de fabricare corespunz tori celor dou abord ri
Tab. 6.4. Timpii de fabricare ob inu i prin cele dou abord ri diferite de modelare [s].
Piese
9
18
36
72
Abordare
ierarhic
544.0
1060
2108
4210
Abordare
monolitic
538.0
1048
2096
4194
Se poate observa c diferen a dintre cele dou abord ri este foarte mic . n plus, aceast diferen
mne aproape constant odat cu cre terea num rului de piese de i diferen a timpilor de execu ie
122

cre te liniar. n aceste condi ii s-a luat decizia de a folosi n continuare modelul ierarhic. n tabelul
6.5 sunt prezenta i timpii de execu ie ai componentelor principale ale aplica iei.
Tab. 6.5. Timpii de execu ie ai componentelor principale ale aplica iei.
Piese
9
18
36
72
Opera ie
Citirea parametrilor de intrare
Rezolvarea modelelor MIP
Scrierea solu iei MIP n spa iul de adrese
Fabricarea pieselor
Fabricarea pieselor
Fabricarea pieselor
Fabricarea pieselor
Timp [s]
3.23
0.21
2.98
544.0
3.23
5.08
3.45
1060.0
3.23
17.67
4.23
2108.0
3.23
91.34
5.47
4210.0
Procentaj [%]
0.587
0.038
0.541
98.83
0.301
0.474
0.322
98.90
0.151
0.828
0.198
98.82
0.075
2.119
0.127
97.678
Rezultatele arat c peste 97.5% din timpul total este reprezentat de fabricarea efectiv a pieselor.
Dup cum este prezentat n tabel, acest procentaj se schimb odat cu modificarea num rului de
piese fabricate, n general fiind mai mic pentru un num r mai mare de piese deoarece timpul de
execu ie al solver-ului cre te exponen ial iar timpul de fabricare cre te liniar. n cazul comenzilor
foarte mari, pentru a evita sc derea semnificativ a procentajului reprezentat de timpul destinat
fabric rii efective a pieselor, se recomand mp irea comenzii n mai multe arje (de cte 50 sau
100 de piese). n acest fel se poate garanta c ntotdeauna majoritatea timpului este destinat
fabric rii pieselor.
n cazul fiec rui proces de fabricare, opera iile 1 (citirea parametrilor de intrare) i 3 (scrierea
solu iei MIP n spa iul de adrese) sunt bazate n principal pe nivelul serviciilor, opera ia 2
(rezolvarea modelelor MIP) are loc la nivelul superior al arhitecturii iar opera ia 4 (fabricare piese)
are loc la nivelul server-ului OPC UA i al dispozitivelor de control ale sta iilor i celulelor.
Opera ia 1 are aceea i durat indiferent de num rul de piese comandate, deoarece parametrii de
intrare citi i din spa iul de adrese sunt independen i de comand . Opera ia de scriere a solu iei MIP
n spa iul de adrese necesit timpi mai mari odat cu cre terea num rului de piese deoarece
matricele nscrise n nodurile variabil Rezultate MIP (figura 6.9) devin mai mari. n figura 6.13 este
prezentat solu ia complet ob inut prin aplicarea modelelor MIP ale abord rii ierarhice n cazul n
care se prime te o comand de nou piese (trei din fiecare tip). Se poate observa faptul c att
duratele de procesare (tabel 6.1) ct i timpii de transport (tabel 6.2) sunt respecta i cu stricte e i
volumul de lucru este distribuit n mod echilibrat ntre cele patru sta ii i zece celule.
123

Fig. 6.13. Orar de lucru pentru o comand de 9 piese.
6.6 CONCLUZII
n cadrul acestui capitol a fost prezentat pe larg un exemplu de utilizare a arhitecturii introduse n
capitolul 3, i anume optimizarea unui proces industrial de fabricare a mecanismelor de rota ie.
Ini ial au fost introduse datele problemei, adic tipurile de piese care trebuie fabricate, instala iile
industriale (liniile flexibile) pe care acestea sunt fabricate precum i timpii de execu ie ai opera iilor.
Fiecare mecanism de rota ie necesit cinci opera ii care se pot executa pe patru linii flexibile. Pentru
a testa func ionalitatea arhitecturii ntr-un mediu industrial real, s-a folosit linia flexibil disponibil
n laboratorul universit ii, celelalte trei linii flexibile fiind simulate la nivelul serverului OPC UA.
Aceast simulare nu a afectat ns testele efectuate deoarece din punctul de vedere al arhitecturii nu
s-a f cut distinc ia intre linia flexibil real i liniile simulate. Totu i existen a unor dispozitive reale
a fost necesar pentru a testa func ionalitatea solu iei software special de adaptare, care permite
modelarea echipamentelor n interiorul serverului OPC UA prin intermediul unui server OPC clasic.
Dup prezentarea detaliat a celulelor s-au introdus modelele MIP utilizate pentru a determina orarul
de lucru optim (aceste modele con in exclusiv constrngeri liniare, ceea ce permite determinarea
unei solu ii optime a modelului ntr-un timp mai scurt). S-au evaluat dou abord ri diferite, i anume
o abordare monolitic n interiorul c reia opera iile de planificare i de scheduling se realizeaz cu
ajutorul unui singur model i o abordare ierarhic , n interiorul c reia se folosesc modele separate
pentru planificare i scheduling.
n continuare au fost prezentate o serie de detalii de implementare: construirea spa iului de adrese al
sta iilor i celulelor, serviciul complex, modific rile realizate la nivelul automatelor programabile
pentru a permite fabricarea unor diferite tipuri de piese, precum i interfa a grafic utilizat pentru
plasarea comenzii i monitorizarea execu iei.
n sec iunea urm toare au fost prezentate rezultatele ob inute, evalundu-se o serie de aspecte:
Solver-ul care conduce la timpul cel mai scurt de rezolvare a modelelor: solver-ul JLPI a fost
superior solver-elor Choco i JaCoP, deoarece a fost special dezvoltat pentru modele liniare;
124

Abordarea ierarhic , de i conduce la timpi de fabricare mai mari dect aceia ob inu i prin
abordarea monolitic , a fost preferat deoarece timpii de determinare a solu iei optime sunt
mult mai scur i dect timpii ob inu i prin abordarea monolitic .
n continuare au fost prezentate o serie de detalii folosind solver-ul JLPI i abordarea ierarhic :
Timpii necesari fiec rei opera ii majore (tabel 6.5): s-a putut astfel observa c pentru toate
comenzile testate, peste 97% din timpul total de execu ie al aplica iei este destinat fabric rii
efective a pieselor;
Orarul de lucru detaliat pentru o comand format din nou piese (figura 6.13).
Aplica ia demonstreaz capacitatea arhitecturii propuse de a conduce un proces de fabrica ie
automatizat (f
interven ia unui operator uman) conform unui plan de produc ie optimizat. Prin
structura spa iului de adrese, dar mai ales prin natura general a modelului introdus n sec iunea 6.3,
s-a asigurat o flexibilitate sporit a aplica iei. Modelul MIP este configurat dinamic nu numai prin
comanda provenit de la client dar i prin informa iile extrase din spa iul de adrese, ceea ce asigur
adaptarea automat a modelului n func ie de informa iile con inute n spa iul de adrese.
n concluzie s-a demonstrat faptul c toate obiectivele men ionate n capitolul 3 sunt ndeplinite de
tre arhitectur , i anume:
procesele de fabrica ie se execut conform unui orar de lucru optim;
nu este necesar interven ia unui operator uman odat ce o comand a fost plasat ;
arhitectura este flexibil , adaptabil i reutilizabil : aceste trei aspecte se reg sesc la fiecare
nivel al arhitecturii.
125
126
BIBLIOGRAFIE
[***Apache Axis 2, 2012] ***Apache Axis 2, Project Homepage, 2012. [Online]. Available at:
http://ws.apache.org/axis2/.
[***Apache CXF, 2012] ***Apache CXF: An Open-Source Services Framework, 2012. [Online].
Available at: http://cxf.apache.org/.
[***Apache River, 2012] ***Apache River News, 2012. [Online]. Available at:
http://river.apache.org/.
[***Apache Tomcat, 2012] ***Apache Tomcat, 2012. [Online]. Available at:
http://tomcat.apache.org/.
[***Choco, 2010] ***The Choco CSP solver, 2010. [Online]. Available at: http://choco.emn.fr.
[***DPWS, 2006] ***Devices Profile for Web Service Specification, 2006. [Online]. Available at:
http://specs.xmlsoap.org/ws/2006/02/devprof/devicesprofile.pdf.
[***Eclipse, 2012] ***Eclipse, 2012. [Online]. Available at: http://www.eclipse.org/.
[***IBM, 2007] *** IBM, Instructor Guide: Getting Started with SOA, WebSphere Education,
2007.
[***IETF, 1994] ***IETF: Integrated Services in the Internet Architecture: An Overview, 1994.
[Online]. Available at: http://tools.ietf.org/rfc/rfc1633.txt.
[***JaCoP, 2010] ***The JaCoP CSP solver, 2010. [Online]. Available at:
http://jacop.osolpro.com/.
[***Java JSR 311, 2011] ***Java Community Process, 2011. [Online]. Available at:
jcp.org/jsr/detail/311.jsp.
[***JEasyOPC, 2011] ***JEasyOPC, 2011. [Online]. Available at: http://jeasyopc.sourceforge.net.
[***Jersey REST, 2012] ***Jersey, 2012. [Online]. Available at: http://jersey.java.net/.
[***Sun, 2001] ***Sun Microsystems: Jini Architecture Specification, 2001. [Online]. Available
at: http://www-csag.ucsd.edu/teaching/cse291s03/Readings/jini1_2.pdf.
[***MySQL Database, 2010] ***MySQL Database, 2010. [Online]. Available at:
http://www.mysql.com.
[***Oracle: SOA & Web Services, 2011] ***Oracle: Service-Oriented Architecture (SOA) and
Web Services, 2011. [Online]. Available at: http://www.oracle.com/technetwork/articles/javase/soa142870.html.
[***PLCOpen and the OPC Foundation, 2011] ***PLCOpen and the OPC Foundation: OPC UA
Information Model for IEC 61131-3, 2011. [Online]. Available at: http://www.plcopen.org.
[***Prosys Java UA SDK, 2011] ***PROSYS OPC UA Java SDK, 2011. [Online]. Available at:
http://www.prosysopc.com/opc-ua-java-sdk.php?gclid=CJDqocn-mq8CFQdG3wodJyIebA.
[***SIRENA, 2011] ***Service Infrastructure for Real-time Embedded Networked Applications
(SIRENA), 2011. [Online]. Available at: http://www.sirena-itea.org/.
127
[***SMC International Training, 2007] ***SMC International Training: Flexible Integrated

Assembling
Systems
FMS-200,
2007.
[Online].
Available
at:
http://www.smctraining.com/ENG/news/?p=34.
[***SOCRADES, 2007] ***Service-Oriented Cross-Layer Infrastructure for Distributed Smart
Embedded Devices (SOCRADES), 2007. [Online]. Available at http://www.socrades.eu/.
[***The OPC Foundation, 2011 a)] ***The OPC Foundation: OPC UA Specification: Part 1
Concept, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 b)] ***The OPC Foundation: OPC UA Specification: Part 2 Security Model, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 c)] ***The OPC Foundation: OPC UA Specification: Part 3 Address Space Model, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 d)] ***The OPC Foundation: OPC UA Specification: Part 4
Services, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 e)] ***The OPC Foundation: OPC UA Specification: Part 5
Information Model, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 f)] ***The OPC Foundation: OPC UA Specification: Part 6
Concepts, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 g)] ***The OPC Foundation: OPC UA Specification: Part 8 - Data
Access, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 h)] ***The OPC Foundation: OPC UA Specification: Part 9 Alarms and Conditions, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 i)] ***The OPC Foundation: OPC UA Specification: Part 11 Historical Access, 2011. [Online]. Available at: http://opcfoundation.org/.
[***The OPC Foundation, 2011 j)] ***The OPC Foundation: OPC Unified Architecture for
Devices (DI), 2011. [Online]. Available at: http://opcfoundation.org/.
[***W3C SOAP XML, 2006] ***W3C: Extensible Markup Language (XML) 1.1 (Second Edition),
2006. [Online]. Available at: http://www.w3.org/TR/2006/REC-xml11-20060816/.
[***W3C SOAP, 2007] ***W3C: SOAP Version 1.2 Part 2: Adjuncts (Second Edition), 2007.
[Online]. Available at: http://www.w3.org/TR/soap12-part2/.
[***W3C WSDL, 2006] ***W3C: Web Services Description Language (WSDL) 2.0, 2006.
[Online]. Available at: http://www.w3.org/TR/wsdl20/.
[***W3C XML Schema, 2004] ***W3C: XML Schema Part 0: Primer Second Edition, 2004.
[Online]. Available at: http://www.w3.org/TR/xmlschema-0/.
[***WS4D, 2007] ***Web Services for Devices (WS4D), Project Homepage, 2007. [Online].
Available at: http://ws4d.e-technik.uni-rostock.de/.
[Abazari A.M., 2012] Abazari, A.M., Solimanpur, M., Sattari, H. Optimum loading of machines in
a flexible manufacturing system using a mixed-integer linear mathematical programming model and
genetic algorithm, Computers & Industrial Engineering, Vol. 62, 2012, pp. 469-478.
[Achterberg T., 2004] Achterberg, T. SCIP - a framework to integrate constraint and mixed
integer programming, ZIB-Report 04-19, June 2004.
[Allahverdi A., 1999] Allahverdi, A., Gupta J., Aldowaisan, T. A review of scheduling research
involving setup considerations, Omega, Vol. 27, 1999, pp. 219-239.
128
BIBLIOGRAFIE
[Allamaraju S., 2010 a)] Allamaraju, S. RESTful Web Services Cookbook, OReilly Media,
Sebastopol, California, USA, 2010.
[Allamaraju S., 2010 b)] Mulligan, G., Gracanin, D. A comparison of SOAP and REST
implementations of a service based interaction independence middleware framework, Proceedings
of the Winter Simulation Conference, Austin, Texas, USA, Dec. 2009, pp. 1423-1432.
[Andrs C., 2008] Andrs, C., Miralles, C., Pastor, R. Balancing and scheduling tasks in assembly
lines with sequence-dependent setup times, European Journal of Operational Research, Vol. 187,
2008, pp. 1212-1223.
[Apt K., 2003] Apt, K. Principles of Constraint Programming, Cambridge University Press, New
York, New York, USA, 2003.
[Apt K., 2010] Apt, K., Marek, V. W., Truszczynski, M., Warren, D. S. The Logic Programming
Paradigm: A 25-Year Perspective, Springer, Heidelberg, Germany, 2010.
[Arnold K., 1999] Arnold, K. The Jini architecture: dynamic services in a flexible network,
Design Automation Conference, New Orleans, Los Angeles, USA, June 1999, pp. 157-162.
[Baker K. R., 1974] Baker, K. R. Introduction to Sequencing and Scheduling, Wiley & Sons, New
York, New York, USA, 1974.
[Baker K. R., 2010] Bakerm, K. R., Keller, B. Solving the single-machine sequencing problem
using integer programming, Computers & Industrial Engineering, Vol. 59, 2010, pp. 730-735.
[Balani N., 2009] Balani, N., Hathi, R. Apache CXF Web Service Development, Packt Publishing,
Birmingham, United Kingdom, 2009.
[Baptiste P., 1995] Baptiste, P., Le Pape, C., Nuijten, W. Constraint-based optimization and
approximation for job-shop scheduling, Proceedings of the AAAISIGMAN Workshop on
Intelligent Manufacturing Systems IJCAI, Vol. 95, 1995, pp. 10691072.
[Baptiste P., 2001] Baptiste, P., Le Pape, C., Nuijten, W. Constraint-Based Scheduling - Applying
Constraint Programming to Scheduling Problems, Kluwer Academic Plublishers, Boston, USA,
2001.
[Baptiste P., 2006] Baptiste, P., Le Pape, C., Nuijten, W. Constraint-based Optimization and
Approximation for Job-shop Scheduling, SIGMAN Workshop on Intelligent Manufacturing
Systems, Montreal, Canada, Aug. 1995, pp. 21-27.
[Bedford B. D., 1964] Bedford, B. D., Hoft R. G. Principles of Inverter Circuits, John Wiley and
Sons, New York, New York, USA, 1964.
[Benavides D., 2005] Benavides, D., Segura, S., Trinidad, P., Ruiz-Corts, A. Using Java CSP
Solvers in the Automated Analyses of Feature Models, Proc. of the 2005 Inter. Conf. on Generative
and Transformational Techniques in Software Engineering, Braga, Portugal, July 2005, pp. 399-408.
[Benhamou F., 2007] Benhamou ,F., Jussien, N., OSullivan, B. Trends in Constraint
Programming, International Society for Technology in Education, London, UK, 2007.
[Black A. P., 2002] Black, A.P., Carlsson, M., Jones, M.P., Kieburtz, R., Nordlander, J. Timber: A
Programming Language for Real-Time Embedded Systems, Technical report, Oregon Health &
Science University, 2002.
[Blum N., 2009] Blum, N. Journal of Network and Systems Management, Journal of Network and
Systems Management, Vol. 17, 2009, pp. 33-52.
[Bohn H., 2006] Bohn, H., Bobek, A., Golatowski, F. SIRENA - service infrastructure for realtime embedded networked devices: a service oriented framework for different domains, Inter. Conf.
129
BIBLIOGRAFIE
on Systems and Inter. Conf. on Mobile Communications and Learning Technologies, Le Morne,
Mauritius, Apr. 2006, pp. 43-47.
[Bucker P., 2002] Bucker, P. Scheduling and constraint propagation, Discrete Applied
Mathematics, Vol. 123, 2002, pp. 227-256.
[Candido G., 2011] Candido, G., Colombo, A.W., Barata, J., Jammes, F. Service-oriented
infrastructure to support the deployment of evolvable production systems, IEEE Trans. on
Industrial Informatics, Vol. 7, 2011, pp. 759-767.
[Candido G., 2009] Candido, G., Barata, J., Colombo, A. W., Jammes, F. SOA in reconfigurable
supply chains: A research roadmap, Engineering Applications of Artificial Intelligence, Vol. 22,
2009, pp. 939949.
[Changyi L., 2009] Changyi, L., Tingting, L. JINI-based design for dynamic scheduling decision
system, IEEE International Conference on Grey System and Intelligent Services, Nanjing, China,
Nov. 2009, pp. 1406-1410.
[Chirita B., 2007] Chirit , B. Sisteme Flexibile de Fabrica ie, Alma Mater, Bac u, Romania,
2007.
[Clarke D., 2000] Clarke, D., Anwar, A. A. Irrigation scheduling using mixed integer linear
programming, European Journal Of Operational Research, Vol. 98, 2000, pp. 473-484.
[Cristea D., 2007] Cristea, D., Ionita, M., Pistol, I. Inteligenta Artificiala, Editura Universit ii
Al.I.Cuza, Ia i, Romania, 2007.
[Cucinotta T., 2009] Cucinotta, T., Mancina, A., Anastasi, G.F., Lipari, G., Mangeruca, L.,
Checcozzo, R., Rusina, F. A real-time service-oriented architecture for industrial automation,
IEEE Trans. on Industrial Informatics, Vol. 5, 2009, pp. 257-266.
[Darby-Dowman K., 2002] Darby-Dowman, K., Wilson, J. M. Developments in linear and integer
programming, Journal of the Operational Research Society, Vol. 53, 2002, pp. 1065-1071.
[Dechter R., 2003] Dechter, R. Constraint Processing, Elsevier Science, San Francisco, CA,
USA, 2003.
[Decker G., 2009] Decker, G., Kopp, O., Leymann, F., Weske, M. Interacting services: From
specification to execution, Data & Knowledge Engineering, Vol. 68, 2009, pp. 946-972.
[Delamer I. N., 2007] Delamer, I.M., Lastra, J.L.M. Loosely-Coupled Automation Systems Using
Device-Level SOA, In Proceedings of the IEEE International Conference on Industrial Informatics
(INDIN), Vienna, Austria, Nov. 2007, pp. 743748.
[Dolgui A., 2012] Dolgui, A., Guschinsky, N., Levin, G. Enhanced mixed integer programming
model for a transfer line design problem, Computers & Industrial Engineering, Vol. 62, 2012, pp.
570-578.
[Duffany J. L., 2009] Duffany, J. L. Optimal Solution of Constraint Satisfaction Problems,
Engineering and Technology, Vol. 37, 2009, pp. 1369-1373.
[Edmunds R., 2011] Edmunds, R., Feldman, J. A., Hicks, B. J., Mullineux, G. Constraint -based
modelling and optimization to support the design of complex multi-domain engineering problems,
Engineering with Computers, Vol. 27, 2011, pp. 319-336.
[Erl T., 2005] Erl, T. Service-Oriented Architecture: Concepts, Technology, and Design, Prentice
Hall PTR, NY, NY, USA, 2005.
[Ferrolho A., 2007] Ferrolho, A., Crisostomo, M. Intelligent control and integration software for
flexible manufacturing cells, IEEE Trans. on Industrial Informatics, Vol. 3, 2007, pp. 3-11.
130
BIBLIOGRAFIE
[Fielding R., 2000] Fielding, R.T. Architectural Styles and the Design of Network-based Software
Architectures, PhD Thesis, University of California, 2000.
[Filho F. Sd. L., 2006] Filho, F. Sd. L., da Fonseca, A. L. T. B., de Souza, A. J., Couto, F.A., dos
Santos, R. P. R., Guedes, L. A. Industrial processes supervision using service oriented
architecture, 32nd IEEE Conf. Industrial Electronics, Paris, France, Nov. 2006, pp. 4552-56.
[Finkelstein L., 2001] Finkelstein, L., Markovitch, S. Optimal schedules for monitoring anytime
algorithms, Artificial Intelligence, Vol. 126, 2001, pp. 63-108.
[Fransua, A., 1986] Fransua, A., M gureanu, N. Ma ini i ac ion ri electrice. Elemente de
execu ie, Editura Tehnic , Bucure ti, Romania, 1986.
[Frantzen M., 2011] Frantzen, M., Ng, H. C., Moore, P. R. A simulation-based scheduling system
for real-time optimisation and decision making support, Robotics and Computer Integrated
Manufacturing, Vol. 27, 2011, pp. 696-705.
[Gao L., 2011] Gao, L., Zhang, G., Zhang, L., Li, X. An efficient memetic algorithm for solving the
job shop scheduling problem, Computers & Industrial Engineering, Vol. 60, 2011, pp. 699-705,
[Gilart-Iglesias V., 2006 a)] Gilart-Iglesias, V., Macia-Perez, F., Capella-Dalton, A., Gil-MartinezAbarca, J. A., Industrial Machines as a Service: A Model Based on Embedded Devices and Web
Services, Proc. of the IEEE Inter. Conf. on Industrial Informatics, Singapore, Singapore, Aug.
2006, pp. 630635.
[Gilart-Iglesias V., 2006 b)] Gilart-Iglesias, V., Macia-Perez, F., Mora-Gimeno, F. J., BernaMartinez, J. V. Normalization of Industrial Machinery with Embedded Devices and SOA, Proc.
of the IEEE Conf. on Emerging Technologies and Factory Automation, Prague, Cehia Sept. 2006,
pp. 173180.
[Gilart-Iglesias V., 2007] Gilart-Iglesias, V., Macia-Perez, F., Marcos-Jorquera, D., Mora-Gimeno,
F. J. Industrial Machines as a Service: Modelling industrial machinery processes, Proc. of the 5th
IEEE Inter. Conf. on Industrial Informatics, Vienna, Austria, June 2007, pp. 737742.
[Grbea A., 2010 a)] Grbea, A., Sisak, F., Perniu, L. Design, implementation and monitoring of a
screw order handling process using business process management tools, International Conference
on Optimization of Electrical and Electronic Equipment (OPTIM), Bra ov, Romnia, May 2010, pp.
760767, ISSN 1842-0133, ISBN 978-1-4244-7019-8, doi: 10.1109/OPTIM.2010.5510565,
Available at: http://ieeexplore.ieee.org/xpl/login.jsp?arnumber=5510565.
[Grbea A., 2010 b)] Grbea, A., Sisak, F., Perniu, L. Service oriented architecture: a promise to
the future, Bulletin of the Transilvania University of Brasov - Series I Engineering Sciences, Vol.
3, 2010, pp. 237-244, ISSN 2065-2119, Available at:
http://but.unitbv.ro/BU2010/Series%20I/BULETIN%20I%20PDF/Electrical%20Engineering,%20El
ectronics%20and%20Automatics/Girbea%20A.pdf.
[Grbea A., 2011 a)] Grbea, A., Demeter, R., Sisak, F. Automatic address space generation for an
OPC UA server of a flexible manufacturing system, 6th IEEE International Symposium on Applied
Computational Intelligence and Informatics SACI 2011, Timi oara, Romania, May 2011, pp. 483
488,
ISBN 978-1-4244-9108-7,
doi:
10.1109/SACI.2011.5873052,
Available
at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5873052.
[Grbea A., 2011 b)] Grbea, A., Suciu, C., Sisak, F. Design and implementation of a fully
automated planner-scheduler constraint satisfaction problem, 6th IEEE International Symposium
on Applied Computational Intelligence and Informatics SACI 2011, Timi oara, Romania, May
131
BIBLIOGRAFIE
2011, pp. 477482, ISBN 978-1-4244-9108-7, doi: 10.1109/SACI.2011.5873051, Available at:

http://ieeexplore.ieee.org/xpl/login.jsp?arnumber=5873051.
[Grbea A., 2011 c)] Grbea, A., Suciu, C., Sisak, F. Remote monitoring and control of a flexible
manufacturing system through a service oriented architecture, Proc. of the 10th RoEduNet
International Conference - Networking in Education and Research, Iasi, Romania, June 2011, pp. 16, ISSN 2068-1038, ISBN 978-1-4577-1233-3, doi: 10.1109/RoEduNet.2011.5993694, Available
at: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5993694.
[Grbea A., 2011 d)] Grbea, A., Nechifor, S., Sisak, F., Perniu, L. Design and implementation of
an OLE for process control unified architecture aggregating server for a group of flexible
manufacturing systems, IET Software, Vol. 5, 2011, pp. 406-411, ISSN 1751-8806, doi:
10.1049/iet-sen.2010.0147,
Available
at:
http://ieeexplore.ieee.org/xpl/login.jsp?arnumber=5977135.
[Grbea A., 2011 e)] Grbea, A., Suciu, C., Sisak, F. Constraint based approach for optimized
planning-scheduling problems, Bulletin of the Transilvania University of Brasov - Series I
Engineering Sciences, Vol. 4, 2011, pp. 123-130, ISSN 2065-2119, Available at:
http://webbut.unitbv.ro/Bulletin/Series%20I/BULETIN%20I/Girbea_A.pdf.
[Grbea A., 2012 a)] Grbea, A., Nechifor, S., Sisak, F., Perniu, L. Efficient address space
generation for an OPC UA server, Software-Practice and Experience, Vol. 42, 2012, pp. 543-557,
ISSN
0038-0644,
doi:
10.1002/spe.1076,
Available
at:
http://onlinelibrary.wiley.com/doi/10.1002/spe.1076/abstract.
[Grbea A., 2012 b)] Grbea, A., Suciu, C., Sisak, F. An innovative and flexible architecture for
industrial automation, Proc. of the 13th Inter. Conf. on Optimization of Electrical and Electronic
Equipment OPTIM 2012, Bra ov, Romania, May 2012, pp. 1085-1092, ISSN 1842-0133, ISBN
978-1-4673-1650-7,
doi:
10.1109/OPTIM.2012.6231762,
Available
at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6231762.
[Grbea A., 2012 c)] Grbea, A., Suciu, C., Sisak, F. Evaluation of software service frameworks for
industrial applications, Bulletin of the Transilvania University of Brasov - Series I Engineering
Sciences, Vol. 5, 2012 pp. 77-84, ISSN 2065-2119, Available at: http://webbut.unitbv.ro/
Bulletin/Series%20I/Content_2012%20series%20I_%20No.%201.pdf.
[Grbea A., 2012 d)] Grbea, A., Suciu, C., Nechifor, S., Sisak, F. Design and implementation of a
service oriented architecture for the optimization of industrial applications, IEEE Transaction on
Industrial Informatics, accepted with minor revision.
[Grbea A., 2012 e)] Grbea, A., Sisak, F., Suciu, C., Arhitectur pentru optimizarea proceselor de
fabrica ie din cadrul ntreprinderilor (cerere de brevet inven ie depus c tre oficiul de Stat pentru
Inve ii i M rci OSIM).
[Graham R. E., 1979] Graham, R. E., Lawler, E. L., Lenstra, J. K., Rinnooy Kan, A. H. G.
Optimization and approximation in deterministic sequencing and scheduling: a survey, Annals of
Discrete Mathematics, Vol. 4, 1979, pp. 287-326.
[Greppi P., 2010] Greppi, P. Process simulation as a domain-specific OPC Unified Architecture
information model, Computer Aided Chemical Engineering, Vol. 28, 2010, pp. 667-672.
[Grossmann D., 2008] Grossmann, D., Bender, K., Danzer, B. OPC UA based Field Device
Integration, SICE Annual Conference, Tokyo, Japonia, Aug. 2008, pp. 933-938.
132
BIBLIOGRAFIE
[Hadlich T., 2006] Hadlich, T. Providing device integration with OPC UA, IEEE International
Conference on Industrial Informatics, Singapore, Singapore, Aug. 2006, pp. 263-268.
[Hammond K., 2000] Hammond, K. Hume: A Bounded Time Concurrent Language. In: Proc. of
the 7th IEEE Inter. Conf. on Electronics, Circuits and Systems (ICECS), Jounieh, Lebanon, June
2000, pp. 407411.
[Hannelius T., 2008] Hannelius, T., Salmenpera, M., Kuikka, S. Roadmap to adopting OPC UA,
Proc. IEEE International Conference on Industrial Informatics, Daejeon, China, July 2008, pp. 756761.
[Hansmann K. W., 1997] Hansmann, K. W., Hoeck, M., Production Control of a Flexible
Manufacturing System in a Job Shop Environment, International Transactions in Operational
Research, Vol. 4, 1997, pp. 341-351.
[Harjunkoski I., 2009] Harjunkoski, I., Nystrm, R., Horcha, A. Integration of scheduling and
control - Theory or practice?, Computers and Chemical Engineering, Vol. 33, 2009, pp. 19091918.
[He X., 2009] He, X., Li, H., Ding, Q., Wu, Z. The SOA-Based Solution for Distributed Enterprise
Application Integration, International Forum on Computer Science-Technology and Applications,
Chongqing, China, 2009, pp. 330-336.
[Helander J., 2005] Helander, J., Sigurdsson, S. Self-Tuning Planned Actions Time to Make RealTime SOAP Real, In: Proc. of the 8th IEEE Inter. Symp. on Object-Oriented Real-Time Distributed
Computing (ISORC), Seattle, Washington, USA, May 2005, pp. 80-89.
[Hendler J., 2006] Hendler, J., Kitano, H., Nebel, B. Handbook of Constraint Programming,
Elsevier, Amsterdam, Netherlands, 2006.
[Hong H., 2006] Hong, H. A low cost tax SOA infrastructure in Grid applications, Wuhan
University Journal of Natural Sciences, Vol. 11, 2006, pp. 1320-1324.
[Huiming L., 2010] Huiming, L., Zhifeng, Y. Research on Key Technology pf the Address Space
for OPC UA Server, Proc. International Conference on Advanced Computer Control, Shenyang,
China, March 2010, pp. 278-281.
[Hurwitz J., 2007] Hurwitz, J., Baroudi, J., Bloor, R., Kaufman, M. Service Oriented Architecture
For Dummies, John Wiley & Sons, Indianapolis, Indiana, USA, 2007.
[Hvolby H.-H., 2010] Hvolby, H.-H., Steger-Jensen, K. Technical and industrial issues of
Advanced Planning and Scheduling (APS) systems, Computers in Industry, Vol. 61, 2010, pp. 845851.
[Idoughi D., 2010] Idoughi, D., Kerkar, M., Kolski, C. Towards new web services based
supervisory systems in complex industrial organizations: basic principles and case study,
Computers in Industry, Vol. 61, 2010, pp. 235-249.
[Itu L. M, 2010] Itu, L.M., Margineanu, I., Cobeanu, I., Grbea, A. Positioning systems for
geodesic monitoring devices, Proc. of the 9th RoEduNet International Conference, Sibiu, Romania,
June 2010, pp. 67-73, ISSN 2068-1038, ISBN 978-1-4244-7335-9, Available at:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5541598&url=http%3A%2F%2Fieeexplore.i
eee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5541598.
[Jammes F., 2005 a)] Jammes, F., Smit, H. Service oriented paradigms in industrial automation,
IEEE Transaction on Industrial Informatics, Vol. 1, 2005, pp. 62-70.
133
BIBLIOGRAFIE
[Jammes F., 2005 b)] Jammes, F., Smit, H. Service-Oriented Architectures for Devices - the
SIRENA View, Proc. of the 3rd Inter. Conf. on Industrial Automation, Perth, Australia, Aug. 2005,
pp. 140147.
[Jiao J. R., 2009] Jiao, J. R., Xu, Q., Wu, Z., Ng, N. K. Coordinating product, process, and supply
chain decisions: A constraint satisfaction approach, Engineering Applications of Artificial
Intelligence, Vol. 22, 2009, pp. 992-1004.
[Josuttis N. M., 2007] Josuttis, N. M. SOA in Practice, OReilly, Sebastopol, California, USA,
2007.
[Kadowaki K., 2008] Kadowaki, K., Koita, T., Sato, K., Hayakawa, H. Design and Implementation
of Adaptive Jini System to Support Undefined Services, Communication Networks and Services
Research Conference, Halifax, NS, UK, May 2008, pp. 577-583.
[Kalogeras A. P., 2006] Kalogeras, A.P., Gialelis, J., Alexakos, C., Georgoudakis, M., Koubias, S.
Vertical Integration of Enterprise Industrial Systems Utilizing Web Services, IEEE Transactions
on Industrial Informatics, Vol. 2, 2006, pp. 120-128.
[Karnouskos S., 2007] Karnouskos, S., Colombo, A., Jammes, F., Strand, M. Towards Service
oriented Smart Items in Industrial Environments, Microsystems Technology, Vol. 2, 2007, pp. 11
12.
[Karnouskos S., 2008] Karnouskos, S, Tariq, M. M. J. An Agent-Based Simulation of SOA-Ready
Devices, Proc. of the 10th Inter. Conf. on Computer Modeling and Simulation, Cambrige, UK,
April 2008, pp. 330335.
[Kim J. W., 2007] Kim, J. W., Lim, K. J. An approach to service-oriented architecture using web
service and BPM in the telecom-OSS domain, Internet Research, Vol. 17, 2007, pp. 99-107.
[Krammer A., 2011] Krammer, A., Heinrich, B., Henneberger, M., Lautenbacher, F. Granularity of
services an economic analysis, Bussiness & Information Systems Engineering, Vol.3, 2011, pp.
345-358.
[Lawler J., 2008] Lawler, J. Service-oriented arhitecture: SOA strategy, methodology, and
technology, Auerbach Publications, NY, NY, USA, 2008.
[Le Pape C., 1996] Le Pape, C. Constraint-based scheduling: principles and application, IEEE
Colloquium on Intelligent Planning and Scheduling Solutions, London, UK, 1996, pp. 1-6.
[Lei D., 2011] Lei, D. Simplified multi-objective genetic algorithms for stochastic job shop
scheduling, Applied Soft Computing, Vol. 11, 2011, pp. 4991-4996.
[Leitner S.H., 2006] Leitner, S.H., Mahnke, W. OPC UA - Service-oriented Architecture for
Industrial Applications, Softwaretechnik-Trends, Vol. 26, 2006, pp.27-33.
[Lu H., 2010] Lu, H., Zhifeng, Y. Research on key technology of the address space for OPC UA
Server, Proc. International Conference on Advanced Computer Control, Shenyang, China, March
2010, pp. 278-281.
[Magnusson P., 2011] Magnusson, P., Sundstrm, N., Bengtsson, K., Lennartson, B., Falkman, P.,
Fabian, M. Planning transport sequences for flexible manufacturing systems, Proceedings of the
18th IFAC World Congress, Milano, Italy, Aug. 2011, pp. 9494-9499.
[Mahnke W., 2009] Mahnke, W., Leitner, S.H., Damm, M. OPC Unified Architecture, Springer
Press, Berlin, Germany, 2009.
[Marks E. A., 2008] Marks, E. A. Service-Oriented Architecture Governance for the Services
Driven Enterprise, John Wiley & Sons, Hoboken, New Jersey, USA, 2008.
134
BIBLIOGRAFIE
[Marriot K., 1998] Marriott, K., Stuckey, P.J. Programming with Constraints. An Introduction,
The MIT Press, London, UK, 1998.
[Mathes M., 2008] Mathes, M., Heinzl, S., Freisleben, B. Towards a Time-Constrained Web
Service Infrastructure for Industrial Automation, Proc. of the 13th IEEE Inter. Conf. on Emerging
Technologies and Factory Automation, Hamburg, Germany, Sept. 2008, pp. 846-853.
[Mathes M., 2009 a)] Mathes, M., Stoidner, C., Schwarzkopf, R., Heinzl, S., Drnemann, T.,
Dohmann, H., Freisleben, B. Time-constrained services: a framework for using real-time web
services in industrial automation, Service Oriented Computing and Applications, Vol. 3, 2009, pp.
239-262.
[Mathes M., 2009 b)] Mathes, M., Stoidner, C., Freisleben, B. SOAP4PLC: Web Services for
Programmable Logic Controllers, Proc. of the 17th Euromicro International Conference on
Parallel, Distributed, and Network-Based Processing, Weimar, Germany, Feb. 2009, pp. 210219.
[Mati Y. 2010] Mati, Y. Minimizing the makespan in the non-preemptive job-shop scheduling with
limited machine availability, Computers & Industrial Engineering, Vol. 59, 2010, pp. 537-543.
[Medland A.J., 2011] Medland, A.J., Matthews, J. The implementation of a direct search
approach for the resolution of complex and changing rule-based problems, Engineering with
Computers, Vol. 27, 2011, pp. 105-115.
[Mehrabi M. G., 2002] Mehrabi, M. G., Ulsoy, A. G., Koren, Y., Heytler, P. Trends and
perspectives in flexible and reconfigurable manufacturing systems, Journal of Intelligent
Manufacturing, Vol.13, 2002, pp. 135-146.
[Menzel M., 2009] Menzel, M., Meinel, C. A Security Meta-model for Service-Oriented
Architectures, IEEE International Conference on Services Computing , Bangalore, India, Sept.
2009, pp. 251-259.
[Mohan N., 1995] Mohan, N., Underland T., Robbins, W. Power Electronics, John Wiley and
Sons, New York, New York, USA, 1995.
[Moltgen G., 1970] Moltgen, G. Tiristoarele n practica. Mutatoare cu comuta ie la re ea, Editura
Tehnic , Bucure ti, Romania, 1970.
[Mosadegh H., 2012] Mosadegh, H., Zandieh, M., Fatemi Ghomi, S. M. T. Simultaneous solving of
balancing and sequencing problems with station-dependent assembly times for mixed-model
assembly lines, Applied Soft Computing, Vol. 12, 2012, pp. 1359-1370.
[Muntean N., 1998] Muntean, N. Convertoare Statice, Editura Politehnica, Timi oara, Romania,
1998.
[Nieuwenhuyse I.V., 2011] Nieuwenhuyse, I. V., Boeck, L. D., Lambrecht, M., Vandaele, N. J.
Advanced resource planning as a decision support module for ERP, Computers in Industry, Vol.
62, 2011, pp. 1-8.
[Nylund H., 2010] Nylund, H., Andersson, P. H. Simulation of service-oriented and distributed
manufacturing systems, Robotics and Computer Integrated Manufacturing, Vol. 26, 2010, pp. 622628.
[zcan U., 2009] zcan, U., erio lu, H., Gken, H., Toklu, B. Balancing and sequencing of
parallel mixed-model assembly lines, International Journal of Production Research, Vol. 48, 2009,
pp. 5089-5113.
135
BIBLIOGRAFIE
[Ozturk C., 2010] Ozturk, C., Tunali, S., Hnich, B., Ornek, A. M. Simultaneous Balancing and
Scheduling of Flexible Mixed Model Assembly Lines with Sequence-Dependent Setup Times,
Electronic Notes in Discrete Mathematics, Vol. 36, 2010, pp. 65-72.
[Pajevski M., 2004] Pajevski, M. A Security Model For Service-Oriented Architectures, 2004.
[Online].
Available
at
http://www.oasis-open.org/committees/download.php/17573/06-0400008.000.pdf.
[Paljakka M., 2009] Paljakka, M., Kalajainen, T., Aro, J., Hannelius,T., Salonen, E.,Suihkonen, K.,
Salmenper, M., Salonen, M.K., Seilonen, I. Java implementation of OPC unified architecture,
Seminar of the Finish Society of Automation, Helsinki, Finland, March 2009, pp.1-6.
[Pautasso C., 2008] Pautasso, C., Zimmermann, O., Leymann, F. Restful web services vs. big
web services, Proceeding of the 17th International conference on World Wide Web, Beijing,
China, Apr. 2008, pp. 805-814.
[Pinedo M. L., 2009] Pinedo, M. L. Planning and Scheduling in Manufacturing and Services,
Springer, NY, NY, USA, 2009.
[Popescu G., 2007] Popescu, G. Sisteme flexibile de fabrica ie, Ed. Academic Brncu i, TrguJiu, Romania, 2007.
[Pota S., 2006] Pota, S., Juhasz, Z. The Benefits of Java and Jini in the JGrid System, Proceedings
of the 20th IEEE International Parallel and Distributed Processing Symposium, Rhodes Island,
Greece, Apr. 2006, pp. 1-6.
[Ramarao K., 2008] Ramarao, K., Prasad, C. SOA requires new approaches to security, Manning
Publications Co., Greenwich, UK, 2008.
[Reddy V. K., 2009] Reddy, V. K., Dubey, A., Lakshmanan, S., Sukumaran, S., Sisodia, R.
Evaluating legacy assets in the context of migration to SOA, Software Quality Journal, Vol. 17,
2009, pp. 51-63.
[Renjie H., 2010] Renjie, H., Feng, L., Dongbo, P. Research on OPC UA Security, Proc. IEEE
Conference on Industrial Electronic and Applications, Taichung, China, June 2010, pp. 1439-1444.
[Reuter B., 2008] Reuter, B., Henrici, D., A model for service-oriented communication systems,
Journal of Systems Architecture, Vol. 54, 2008, pp. 594-606.
[Richardson L., 2007] A. Richardson, and S. Ruby, RESTful Web Services. Web services for the
real world, O'Reilly Media, Sebastopol, CA, USA, 2007.
[Riedl C., 2009] Riedl, C., Bohmann, T., Rosemann, M., Krcmar, H. Quality management in
service ecosystems, Information Systems and en-Business Management, Vol. 7, 2009, pp. 199
221.
[Rosen M., 2008] Rosen, M. Applied SOA: Service-Oriented Architecture and Design Strategies,
Wiley Publishing, Indianapolis, Indiana, USA, 2008.
[Rossi F., 2006] Rossi. F., Van Beek, P., Walsh, T. Handbook of Constraint Programming,
Elsevier Science, Oxford, UK, 2006.
[Sasa A., 2008] Sasa, A., Juric, M.B., Krisper, M. Service-oriented framework for human task
support and automation, IEEE Trans. on Industrial Informatics, Vol. 4, 2008, pp. 292-302.
[Sawik T., 2004] Sawik, T. Loading and scheduling of a flexible assembly system by mixed integer
programming, European Journal of Operational Research, Vol. 154, 2004, pp. 1-19.
[Sawik T., 2011] Sawik, T. Scheduling in supply chains using mixed integer programming, Wiley,
Hoboken, NY, USA, 2011.
136
BIBLIOGRAFIE
[Schleipen M, 2008] Schleipen, M. OPC UA supporting the automated engineering of production

monitoring and control systems, Proc. IEEE Confrence on Emerging Technologies and Factory
Automation, Hamburg, Germany, Sept. 2008, pp 640-647.
[Simonis H., 2001] Simonis, H. "Building Industrial Applications with Constraint Programming",
Lecture Notes in Computer Science, 1999, Vol. 2002, pp. 271-309.
[Smit H., 2006] Smit, H., Delamer, I. Service-oriented Architectures in Industrial Automation,
IEEE International Conference on Industrial Informatics, Singapore, Singapore, Aug. 2006, pp. 3233.
[Stecke K. E., 1985] Stecke, K. E. Design, planning, scheduling, and control problems of flexible
manufacturing systems, Annals of Operations Research, Vol. 3, 1985, pp. 112.
[Stopper M., 2009] Stopper, M., Katalinic, B. Service-oriented Architecture Design Aspects of
OPC UA for Industrial Applications, Proc. of the International MultiConference of Engineers and
Computer Scientists, Hing Kong, Hong Kong, March 2009, pp. 11-14.
[Surridge M., 2005] Surridge, M., Taylor, S., De Roure, D., Zaluska, E. Experiences with GRIA
Industrial applications on a Web Services Grid, 1st Inter. Conf. on e-Science and Grid Computing,
Melbourne, Australia, July 2005, pp. 98-105.
[Tack G., 2009] Tack, G. Constraint Propagation - Models, Techniques, Implementation, PhD
Thesis, Saarland University, Germany, 2009.
[Thiagarajan R., 2009] Thiagarajan, R., Mayer, W., Stumptner, M. A Generative Framework for
Service Process Composition, 7th International Joint Conference on Service Oriented Computing,
Stockholm, Sweden, Nov. 2009, pp. 24-27.
[Timpe C., 2002] Timpe, C. Solving planning and scheduling problems with combined integer and
constraint programming, OR Spectrum, Vol. 24, 2002, pp. 431-448.
[Tinny N., 2009] Tinny, N. Undestanding IBM SOA Foundation Suite: Learning Visually
Examples, Pearson Education, Indiana , USA, 2009.
[Tomastik R. N., 1996] Tomastik, R. N., Luh, P. B., Liu, G. Scheduling flexible manufacturing
systems for apparel production, IEEE Transactions on Robotics and Automation, Vol. 12, 1996,
pp. 789-799.
[Tormos P., 2006] Tormos, P., Abril, M., Salido, M. A., Barber, F., Ingolotti, L., Lova, A.
Distributed constraint satisfaction problems to model railway scheduling problems, Computers in
Railways X, 2006, pp. 289-297.
[Touzi J., 2009] Touzi, J., Benaben, F., Pingaud, H., Lorr, J. P. A model-driven approach for
collaborative service-oriented architecture design, International Journal of Production Economics,
Vol. 121, 2009, pp. 5-20.
[Turner M., 2003] Turner, M., Budgen, D., Brereton, P. Turning software into a service,
Computer, Vol. 36, 2003, pp. 38-44.
opa I., 2005] opa , I., D nil , A., Diaconu, L. Elemente de execu ie electrice, Matrix Rom,
Bucure ti, Romnia, 2005.
opa I., 2007] opa , I., D nil , A., Diaconu, L. Ac ion ri electrice reglabile cu ma ini
asincrone, Matrix Rom, Bucure ti, Romnia, 2007.
[Unlu Y., 2010] Unlu, Y., Mason, S. J. Evaluation of mixed integer programming formulations for
non-preemptive parallel machine scheduling problems, Computers & Industrial Engineering, Vol.
58, 2010, pp. 785-800.
137
BIBLIOGRAFIE
[Van Hentenryck, P., 1992] Van Hentenryck, P., Simonis, H., Dincbas, M. Constraint Satisfaction
using constraint logic programming, Artificial Intelligence, Vol. 58, pp. 113-159, 1992.
[Veiga G., 2009] Veiga, G., Pires, J. N., Nilsson, K. Experiments with service-oriented
architectures for industrial robotic cells programming, Robotics and Computer Integrated
[Venners B., 1998] Venners, B. Jini Technology, Out of the Box, JavaWorld IDGs magazine for
the Java community, 1998. [Online]. Available at: http://www.javaworld.com/javaworld/jw-121998/jw-jbe-jini.html.
[Virta J., 2010] Virta, J., Seilonen, I., Tuomi, A., Koskinen, K. SOA-Based integration for batch
process management with OPC UA and ISA-88/95, IEEE Conference on Emerging Technologies
and Factory Automation ETFA, Bilbao, Spania, Sept. 2010, pp. 1-8.
[Waldo J., 1999] Waldo, J. The Jini Architecture for Network-Centric Computing,
Communications of the ACM, Vol. 42, 1999, pp. 76-82.
[Waldo J., 2000] Waldo, J. Alive and well: Jini technology today, Computer, Vol. 33, 2000, pp.
107-109.
[Westerlund J., 2007] Westerlund, J., Hstbacka, M., Forssell, S., Westerlund, T. Mixed-Time
Mixed-Integer Linear Programming Scheduling Model, Industrial & Engineering Chemistry
Research, Vol. 46, 2007, pp. 2781-2796.
[Wilde E., 2007] Wilde, E. "Declarative Web 2.0", IEEE International Conference on Information
Reuse and Integration (IRI 2007), Las Vegas, Nevada, USA, Aug. 2007, pp. 612-617.
[Williams H.P., 1999] Williams, H.P. Model Building in Mathematical Programming, John
Wiley & Sons Ltd, Baffins Lane, West Sussex, England, 1999.
[Xhafa F., 2008] Xhafa, F., Abraham, A. Metaheuristics for Scheduling in Industrial and
Manufacturing Applications, Springer, Berlin, Germania, 2008.
[Yamany H. F., 2010] Yamany, H. F., Capretz, M., Allison, D. Intelligent security and access
control framework for service-oriented architecture, Information and Software Technology, Vol.
52, 2010, pp. 220236.
[Yu Q., 2006] Yu, Q., Liu, X., Bouguettaya, A., Medjahed, B. Deploying and managing Web
services: issues, solutions, and directions, The VLDB Journal, Vol. 17, 2006, pp. 537-572.
[Zeballos L. J., 2010 a)] Zeballos, L. J. A constraint programming approach to tool allocation and
production scheduling in flexible manufacturing systems, Robotics and Computer Integrated
[Zeballos L. J., 2010 b)] Zeballos, L. J., Quiroga, O. D., Henning, G. P. A constraint programming
model for the scheduling of flexible manufacturing systems with machine and tool limitations,
Engineering Applications of Artificial Intelligence, Vol. 23, 2010, pp. 229-248.
[Zribi N. ., 2008] Zribi, N. ., Kamel, A. E., Borne, P. Minimizing the makespan for the MPM
job-shop with availability constraints, International Journal of Production Economics, Vol. 112,
2008, pp. 151-160.
[Zweben M., 1994] Zweben, M., Fox, M. Intelligent Scheduling. Technology, Morgan Kaufman,
Burlington, New Jersey, USA, 1994.
138

Arhitecturi Orientate Pe Servicii Pentru Optimizarea Aplica?iilor Industriale

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arhitecturi Orientate Pe Servicii Pentru Optimizarea Aplica?iilor Industriale

Încărcat de

Drepturi de autor:

Formate disponibile

Arhitecturi orientate pe

servicii pentru optimizarea

Arhitecturi orientate pe servicii

Editura Universit ii Transilvania

3.3 SERVERUL OPC UA ..........................................................................................................38

5.2.3.1 Framework-ul Apache Axis2 .................................................................................. 80

Piramida de automatizare [Harjunkoski I., 2009].

1 ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

o Descoperirea componentelor principale ale sistemului;

1. ARHITECTURI ORIENTATE PE SERVICII

Fig. 1.1. Evolu ia SOA [Rosen, M., 2008].

1. ARHITECTURI ORIENTATE PE SERVICII

Fig. 1.2. Structura unui serviciu [Rosen, M., 2008].

1.3.2 nregistrarea i contractarea serviciilor

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1.4 ARHITECTURA PE NIVELE A CONCEPTULUI SOA

Fig. 1.4. Arhitectura stratificat SOA [***IBM, 2007].

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

Fig. 1.5. Triada CIA [Menzel, M., 2009].

1.5.2 Securitatea SOA

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

Dup realizarea cu succes a IMNP-ului, un dispozitiv arbitrar industrial poate fi accesat

1. ARHITECTURI ORIENTATE PE SERVICII

1. ARHITECTURI ORIENTATE PE SERVICII

1.6.3 Colaborarea business-to-business

1. ARHITECTURI ORIENTATE PE SERVICII

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

Fig. 2.1. Transformarea unei constrngeri n-are ntr-o constrngere unar .

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

Fig. 2.2. Consisten de arc.

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

Fig. 2.3 Consisten a de arc nu garanteaz existen a unei solu ii.

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

n figura 2.5 sunt reprezentate cteva no iuni fundamentale:

Fig. 2.5. Func ii obiectiv [Baptiste P., 2001].

2.2.3 Modelarea CSP a unei probleme de scheduling

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

Rela iile temporale

De asemenea constrngerea de resurs trebuie respectat la orice moment de timp t:

Extensii ale modelului

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

F (end ( A1 ),..., end ( An ))

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

2. PROBLEME DE SATISFACERE A CONSTRNGERILOR

3 ARHITECTUR ORIENTAT PE SERVICII

PE SERVICII PENTRU OPTIMIZAREA APLICA IILOR INDUSTRIALE

Fig. 3.1. Contribu ia tehnologiilor la ndeplinirea obiectivelor arhitecturii.