arhitecturi adaptive bazate pe agenți pentru conducerea fluxurilor de … · 2013-10-10 · În...
TRANSCRIPT
UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI
MINISTERUL MUNCII, FAMILIEI ŞI PROTECŢIEI SOCIALE
AMPOSDRU
Fondul Social European
POSDRU 2007-2013
Instrumente Structurale
2007-2013 OIPOSDRU UNIVERSITATEA TEHNICĂ
“GHEORGHE ASACHI” DIN IAŞI
UNIVERSITATEA TEHNICĂ “GHEORGHE ASACHI” DIN IAȘI
Școala Doctorală a Facultății de Automatică și Calculatoare
Arhitecturi adaptive bazate pe agenți pentru conducerea fluxurilor de activități
- REZUMATUL TEZEI DE DOCTORAT -
Conducător de doctorat:
Prof. univ. dr. ing. Octavian Păstrăvanu
Doctorand:
Ing. Carlos Mihai Pascal
IAȘI - 2011
UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI
MINISTERUL MUNCII, FAMILIEI ŞI PROTECŢIEI SOCIALE
AMPOSDRU
Fondul Social European
POSDRU 2007-2013
Instrumente Structurale
2007-2013 OIPOSDRU UNIVERSITATEA TEHNICĂ
“GHEORGHE ASACHI” DIN IAŞI
Teza de doctorat a fost realizată cu sprijinul financiar al
proiectului „Burse Doctorale - O Investiţie în Inteligenţă (BRAIN)”.
Proiectul „Burse Doctorale - O Investiţie în Inteligență (BRAIN)”,
POSDRU/6/1.5/S/9, ID 6681, este un proiect strategic care are ca
obiectiv general „Îmbunătățirea formării viitorilor cercetători în cadrul
ciclului 3 al învățământului superior - studiile universitare de doctorat
- cu impact asupra creșterii atractivității şi motivației pentru cariera în
cercetare”.
Proiect finanţat în perioada 2008 - 2011.
Finanţare proiect: 14.424.856,15 RON
Beneficiar: Universitatea Tehnică „Gheorghe Asachi” din Iași
Partener: Universitatea „Vasile Alecsandri” din Bacău
Director proiect: Prof. univ. dr. ing. Carmen TEODOSIU
Responsabil proiect partener: Prof. univ. dr. ing. Gabriel LAZĂR
UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI
MINISTERUL MUNCII, FAMILIEI ŞI PROTECŢIEI SOCIALE
AMPOSDRU
Fondul Social European
POSDRU 2007-2013
Instrumente Structurale
2007-2013 OIPOSDRU UNIVERSITATEA TEHNICĂ
“GHEORGHE ASACHI” DIN IAŞI
Mențiuni
Teză curentă constituie rezultatul activității de cercetare în perioada
octombrie 2008 – septembrie 2011 în domeniul Ingineriei Sistemelor din
cadrul Facultății de Automatică și Calculatoare, Universitatea Tehnică
„Gheorghe Asachi” din Iași. Întreaga perioadă de cercetare a fost
finanțată prin proiectul „Burse Doctorale – O Investiție în Inteligență
(BRAIN)” și doresc, pe această cale, să adresez mulțumiri către
director și managerii acestui proiect. De asemenea, doresc să amintesc
despre proiectul de cercetare SOFHICOR (Contract nr. 11-042/2007) în
care am fost implicat pe o perioadă de doi ani, și să mulțumesc
coordonatorului general, prof. dr. ing. Theodor Borangiu.
Doresc să exprim sincere mulțumiri domnului prof. dr. ing. Octavian
Păstrăvanu pentru îndrumarea acordată, modul atent și perseverent, și
pentru suportul moral oferit în toată această perioadă de cercetare. De
asemenea, adresez întreaga recunoștință domnului prof. dr. ing. Doru
Pănescu pentru timpul alocat și munca depusă în formarea mea, fără de
care nu ar fi fost posibilă concretizarea acestei lucrări. Mulțumesc
domului prof. dr. ing. Radu Călinescu de la Universitatea Aston din
Marea Britanie pentru îndrumarea profesională din timpul stagiului de
cercetare extern de la universitatea menționată. Mulțumiri sincere
adresez doamnei conf. dr. ing. Gabriela Varvara pentru formarea mea
pe durata studiilor de licență și masterat, pentru colaborarea pe durata
doctoratului. Îmi exprim, în aceeași măsură, recunoștința față de
colegul meu, drd. ing. Marius Șutu, de al cărui sprijin am beneficiat.
După nouă ani petrecuți în Facultatea de Automatică și
Calculatoare, din care șapte în Departamentul de Automatică și
Informatică Aplicată, mulțumesc sincer tuturor membrilor facultății
pentru formarea mea. În final, transmit prietenilor și colegilor:
Mulțumesc mult!
i
Cuprins
Cuprins ....................................................................................................................................... i
Capitolul 1 Introducere ............................................................................................................ 3
1.1. Importanţa continuă a arhitecturilor adaptive ...................................................................... 3
1.2. Formularea problemei. Obiective ......................................................................................... 3
1.3. Organizarea tezei .................................................................................................................. 4
Capitolul 2 Arhitecturi de conducere pentru sistemele de fabricaţie .................................. 6
2.1. Introducere ........................................................................................................................... 6
2.2. Sisteme de fabricaţie ............................................................................................................ 6
2.3. Clasificarea arhitecturilor de control .................................................................................... 6
2.4. Sisteme multiagent ............................................................................................................... 8
2.4.1. Conceptele de agent şi sistem multiagent ..................................................................... 8
2.4.2. Agenţi deliberativi – model BDI................................................................................... 8
2.4.3. Relaţii dintre entităţi ..................................................................................................... 9
2.4.4. Scheme de coordonare ................................................................................................ 10
2.5. Sisteme holonice ................................................................................................................ 10
2.5.1. Conceptele de holon si holarhie .................................................................................. 10
2.5.2. Sistemele de fabricaţie holonice ................................................................................. 11
2.5.3. Arhitecturi holonice de control ................................................................................... 13
2.6. Etape în conducerea fluxurilor de activităţi ....................................................................... 13
2.7. Concluzii ............................................................................................................................ 14
Capitolul 3 Propunerea unei arhitecturi de conducere – HAPBA ..................................... 15
3.1. Introducere ......................................................................................................................... 15
3.2. Model structural al unui holon ........................................................................................... 15
3.3. Clase de holoni consideraţi ................................................................................................ 16
3.4. Model structural al unui sistem holonic ............................................................................. 16
3.5. Elemente principiale privind proiectarea agenţilor holonici .............................................. 17
3.6. Relaţii intre holoni .............................................................................................................. 19
3.7. Strategii de coordonare ...................................................................................................... 19
3.8. Structura unui agent holonic de tip JACK. Ciclu de lucru. ................................................ 21
3.9. Concluzie............................................................................................................................ 23
Capitolul 4 Dezvoltarea unui model Petri pentru HAPBA ................................................. 24
4.1. Introducere ......................................................................................................................... 24
4.2. Introducere în formalismul reţelelor Petri .......................................................................... 24
4.3. Modele Petri pentru acţiune şi plan .................................................................................... 24
4.4. Model operaţional al agentul holonic ................................................................................. 25
4.5. Formalizarea execuţiei ....................................................................................................... 27
ii
4.6. Model Petri pentru flux de execuţie ................................................................................... 29
4.7. Formalizarea planificării .................................................................................................... 31
4.8. Model Petri pentru flux de planificare ............................................................................... 33
4.9. Conexiunile dintre planificare şi execuţie .......................................................................... 34
4.10. Model al mecanismului de raţionare BDI ........................................................................ 36
4.11. Extinderea modelului operaţional cu implicarea holonului staff ..................................... 36
4.12. Extinderea la modele Petri colorate ................................................................................. 37
4.13. Concluzii .......................................................................................................................... 38
Capitolul 5 Adaptabilitatea în HAPBA ................................................................................ 39
5.1. Introducere ......................................................................................................................... 39
5.2. Mijloace de obţinere a flexibilităţii. Flexibilitatea de tip obiect. ....................................... 39
5.3. Strategii de planificare în gestionarea flexibilităţii de tip obiect ........................................ 39
5.4. O comparaţie asupra strategiilor propuse ........................................................................... 41
5.5. Concluzii ............................................................................................................................ 46
Capitolul 6 Evaluarea arhitecturi HAPBA prin mijloacele reţelelor Petri ....................... 47
6.1. Introducere ......................................................................................................................... 47
6.2. Experiment I – un holon produs şi un singur scop ............................................................. 47
6.3. Experiment II – doi holoni produs și un singur scop ......................................................... 48
6.4. Experiment III – un holon produs şi două scopuri ............................................................. 50
6.5. Experiment IV – rezolvarea unei sarcini de asamblare ...................................................... 52
6.6. Concluzii ............................................................................................................................ 54
Capitolul 7 Concluzii; contribuţii ale tezei; posibilităţi de continuare a cercetării .......... 55
7.1. Contribuţii .......................................................................................................................... 55
7.2. Direcţii viitoare de cercetare .............................................................................................. 57
Anexă I – Listă lucrări ........................................................................................................... 58
Bibliografie selectivă .............................................................................................................. 59
3
„Beyond the age of information is the age of choices”
Charles Eames
Capitolul 1 Introducere
1.1. Importanţa continuă a arhitecturilor adaptive
În ultimul deceniul lumea cunoaşte o nouă formă de interacţiune, una globală, antrenată de
progresul tehnologic, cunoscută sub numele de revoluţia virtuală (BBC, 2010). Această formă se
propagă pe toate domeniile societăţii şi declanşează formarea naturală şi dinamică a sistemelor
distribuite şi cooperante, care conduc spre globalizarea întregii societăţi. Fabricaţia este ramura
economiei atinsă şi ea de acest val, în care se generează un nou trend, cel al produselor diversificate
şi personalizate, cu calităţi superioare, costuri competitive şi cu cicluri de fabricaţie reduse. Această
tendinţă impune noi standarde asupra companiilor, şi anume în termeni ai calităţii, adaptabilităţii,
agilităţii şi flexibilităţii. Standardele menţionate au existat dintotdeauna, însă acum, datorită
progresului informatic, devin teme curente atât în industrie cât şi în mediul academic.
În dezvoltarea sistemelor distribuite şi cooperante, una din principalele preocupări este
dezvoltarea unor entităţi individuale, autonome, cooperante şi reconfigurabile, care să realizeze
activităţi specifice în beneficiul respectivelor sisteme. În cele mai multe soluţii, autorii au urmat şi
urmează abordării euristice în dezvoltarea acestora, sub umbrela unor concepte care în general
satisfac pe moment probleme existente şi, mai mult, sunt strâns legate de mediile specifice avute la
dispoziţie. Aceste soluţii necesită a fi generalizate, complete şi susţinute de formalisme teoretice,
adecvate încât să permită obţinerea acelor proprietăţi care să poată garanta adaptabilitatea şi
agilitatea în viitor. Atingerea acestei caracteristici implică îmbinarea mai multor domenii, şi anume,
în principal, Inteligenţa Artificială Distribuită (prin orientarea spre entităţi autonome) şi Ingineria
sistemelor, mai ales prin aria arhitecturilor de control al fabricaţiei. În ultimul deceniu, cercetările au
asigurat progresul celor două domenii, dar şi explorarea frontierelor dintre acestea, care oferă o
viziune nouă spre soluţionarea problemelor curente.
În domeniul sistemelor de fabricaţie, unde această lucrare se încadrează, abordările din aria
Inteligenţei Artificiale au fost utilizate de mai bine de două decenii în adresarea acestor provocări ale
economie globale. Şi anume, controlul sistemelor de fabricaţie bazat pe agenţi şi holoni reprezintă
soluţii curente, adecvate acestor cerinţe, descentralizarea controlului, cu utilizarea unor structuri
distribuite, autonome, modulare şi reutilizabile. Atunci când se recurge la o proiectate şi
implementare corespunzătoare, sistemele de control bazate pe agenţi obţin performanţe care satisface
proprietăţile de flexibilitate, adaptabilitate şi agilitate. Astfel, cercetătorii manifestă un interes sporit
faţă de noi abordări privind sistemele de fabricaţie şi abordează domeniul sub următoarele
paradigme: sisteme de manufacturare bionice (Okino, 1993), sisteme de manufacturare
genetice/biologice (Ueda et al., 1997), sisteme de manufacturare fractale (Warnecke, 1993; Sihn,
1995), sisteme de manufacturare stohastice (Iwata şi Onosato, 1994), sisteme de manufacturare
holonice (Suda, 1989; Mathews, 1995; Valckenaers et al., 1997), sisteme de manufacturare virtuale
şi sisteme de manufacturare inteligente, distribuite. Sub aceste paradigme, structura tradiţională de
control predispusă la rigiditate este transformată, conform unor noi coordonate caracterizate prin
autonomie şi inteligenţă.
1.2. Formularea problemei. Obiective
Teza se adresează sistemelor de execuţie a fabricaţiei. Prin natura lor, aceste sisteme
prezintă cele mai multe constrângeri legate de timp şi de resurse fizice, şi constituie mediul ideal
pentru dezvoltarea unor arhitecturi de conducere a fluxurilor de activităţi, întrucât soluţiile
4
obţinute vor putea fi aplicate cu succes, ulterior, pe alte sisteme căror rigiditate va fi diminuată.
În aria sistemelor de fabricaţie se visează o nouă generaţie, care va fi caracterizată prin
proiectarea şi implementarea bazată pe entităţi inteligente, autonome şi cooperante, pentru a
forma sisteme distribuite cu structură adaptivă şi reconfigurabilă. Noua generaţie trebuie să
satisfacă o serie de criterii de performanţă, care visează realizarea unor fluxuri de producţie
eficiente, stabile, flexibile şi adaptabile la cerinţele în permanenţă schimbare ale pieţelor de
desfacere. O paradigma aplicată în această direcţie este cea holonică, care introduce o nouă
abordare ce tinde să satisfacă cerinţele actuale ale fabricaţiei. Aplicarea conceptelor holonice se
materializează, în special, prin mijloacele sistemelor multiagent şi fundamentele teoretice
aferente acestora.
Obiectivul acestei lucrări îl constituie proiectarea şi dezvoltarea unei noi arhitecturi de
control pentru sistemele de execuţie a fabricaţiei de tip holonic, care va grupa elemente şi
strategii conducând către o soluţie favorabilă pentru mediul de manufacturare. Se urmăreşte
dezvoltarea unui sistem cu entităţi autonome şi cooperante, în care se pune accentul pe trei
elemente: planificarea în spaţiul planurilor, coordonarea prin protocolul Contract Net şi folosirea
unor entităţi care dispun de un mecanism de raţionament de tip BDI. De asemenea se doreşte ca
arhitectura propusă să fie validată de rezultate obţinute pe baza analizelor efectuate prin
mijloacele reţelelor Petri.
Sintetizând şi continuând o idee din secţiunea 1.1, un al doilea obiectiv al acestei teze a
fost acela de a dezvolta un mecanism fundamentat teoretic pentru proiectarea şi implementarea
sistemelor holonice de fabricaţie. Elementele pe care se sprijină formalismul propus sunt cele din
analiza sistemelor cu evenimente discrete prin reţele Petri; din capitolul de planificare al
Inteligenţei Artificiale, precum şi din strategiile de coordonare folosite în sistemele multiagent.
1.3. Organizarea tezei
Lucrarea este formată din şapte capitole, dintre care cinci sunt principale, unul este cel
curent şi altul care concretizează contribuţiile şi indică direcţiile viitoare de cercetare.
Capitolul 2 intitulat „Arhitecturi de control pentru sistemele de fabricaţie”, este dedicat
domeniului de bază şi elementelor care sunt explorate în principal cercetarea curentă. Sunt
descrise sistemele de fabricaţie şi sunt clasificate arhitecturile de control aplicate pentru aceste
sisteme. Sunt expuse conceptele de sistem multiagent şi holonic, fiind în principal discutate
elementele de interes pentru teză: mecanismul de raţionament BDI şi coordonarea prin
protocolul Contract Net. De asemenea, sunt prezentate arhitecturile holonice dezvoltate pentru
mediul de fabricaţie, care au la bază entităţi autonome şi cooperante.
Capitolul 3, intitulat „Propunerea unei arhitecturi de conducere - HAPBA”, descrie
viziunea unei noi arhitecturi holonice. Se prezintă structura modelul structural al unui holon şi se
trasează structura unui sistem holonic. Sunt detaliate clasele de holoni şi rolurile acestora ajustate
specific. Secţiunea 6 prezintă elementele esenţiale şi condiţiile pe care se bazează noua
arhitectură: planificarea în spaţiu planurilor, mecanism de raţionament de tip BDI, coordonarea
prin Contract Net şi conceptele de holon şi holarhie. Secţiunea 7 prezintă relaţiile între holoni şi
modul de formare a bibliotecii de planuri aferente agenţiilor holonici. Secţiunea 8 propune o
serie de strategii de coordonare şi accentuează necesitatea unei componente centralizate în
sistemul holonic. Secţiune 8 prezintă structura unui agent holonic de tip JACK, ciclul de lucru şi
modul de agentificare a unei resurse de execuţie.
5
Capitolul 4, intitulat „Dezvoltarea unui model Petri pentru HAPBA”, este dedicat
dezvoltării unui model de tip reţea Petri pentru arhitectura propusă. Într-o scurtă prefaţare se
pune în evidenţă necesitatea modelării din reţele Petri, urmată de prezentarea formalismului
aferent reţelelor Petri monocolore, colorate şi ierarhice. Se dezvoltă pas cu pas un model al
arhitecturii, plecând de la definirea unei legături între elementele planificării în spaţiul planurilor
şi reprezentarea lor prin formalismul reţelelor Petri. Se propune un model operaţional nou pentru
agenţii holonici, care este strâns legat de protocolul de coordonare Contract Net şi care este valid
pentru trei clase de holoni şi pentru rolurile de manager, contractor şi contractor manager. De
asemenea se formulează formalisme pentru fazele de execuţie şi planificare, pe bază cărora se
propun modele pentru fluxurile de execuţie şi planificare, şi sunt exprimate conexiunile dintre
acestea la formarea agentului holonic şi operarea acestuia. Se schiţează un model pentru
mecanismul de raţionament BDI şi legătura acestuia cu modelele fluxurilor de planificare. De
asemenea se pune în evidentă considerarea componentei centralizate prin extinderea modelului
operaţional şi cel al fluxului de planificare. În finalul capitolul se extind toate modeleul propuse
prin transpunerea lor în modele Petri colorate şi utilizarea lor în dezvoltarea unui model complex
al întregului sistem holonic, care va fi utilizat în capitolul 6 pentru analiza arhitecturii dezvoltate.
Capitolul 5 intitulat „Adaptabilitatea în HAPBA” prezintă metodele de obţinere a
adaptabilităţii în structurile holonice. Se propune un nou tip de flexibilitate în sistemele de
fabricaţie, care ţine cont de existenţa unor surse multiple ce pot fi considerate în fluxurile de
producţie. Sunt propuse patru strategii de planificare care ţin cont de noul tip de flexibilitate şi se
prezintă o comparaţie între aceste strategii din punct de vedere al complexităţii. Capitolul se
închide printr-o serie de concluzii care accentuează importanţa adaptabilităţii pentru sistemele de
fabricaţie holonice.
Capitolul 6 este intitulat „Evaluarea arhitecturi HAPBA prin mijloacele reţelelor Petri”,
în care sunt prezentate o serie de analize şi experimente care evidenţiază anumite interferenţe
negative între procesele de planificare, şi care vor valida strategiile de coordonare propuse.
Primul experiment (secţiunea 6.2) demonstrează existenţa unui posibil conflict în procesul de
alocare şi care este soluţionat prin aplicarea strategiei de ofertare relaxată. Al doilea experiment
(secţiunea 6.2), efectuat pe o structură holonică extinsă, prezintă un alt conflict ce poate să apară
la nivelul proceselor de planificare şi care se rezolva prin utilizarea strategiei de coordonare ce
implică o componentă centralizată. De asemenea, se demonstrează necesitatea aplicării
concomitente a celor două strategii. Secţiunea 6.3 prezintă un alt caz, în care starea conflictuală
apare între două sau mai multe procese din interiorul aceluiaşi agent holonic. Ultimul experiment
constituie un caz real de fabricaţie în care, de asemenea, interferenţe negative apar când
strategiile de coordonare nu sunt aplicate.
Capitolul 7 subliniază contribuţiile aduse prin această lucrare şi prezintă o serie de
direcţii viitoare de cercetare.
Diseminarea rezultatelor cercetării
O parte din studiile realizate în această lucrare apar în mai multe publicaţii (vezi Anexa
I): o lucrare este acceptată pentru publicare într-o revistă indexată ISI, una este publicată într-o
revistă indexată BDI, una este publicată într-un volum al editurii Springer, două sunt publicate în
volume ISI Proceedings, una este acceptată pentru publicare la o revistă internaţională cotată ISI,
iar 8 articole publicate la conferinţe organizate atât în ţară cât şi în străinătate (5 articole la
conferinţe sub egida IEEE).
6
Capitolul 2 Arhitecturi de conducere pentru sistemele de fabricaţie
2.1. Introducere
În acest capitol se prezintă principalele concepte şi elemente, care stau la baza unei noi
arhitecturi de control. În prima secţiune se prezintă succint modelul abstract al unui sistem de
fabricaţie. O clasificare a arhitecturilor de control este de asemenea prezentată, iar apoi se
discută despre sistemele bazate pe agenţi şi despre sistemele holonice. În final, se prezintă
metodele de planificare tradiţionale.
2.2. Sisteme de fabricaţie
Sistemele de fabricaţie constituie procese complexe orientate spre fabricarea de produse
cu valoare în piaţă. În fluxul de producţie sunt implicate echipamente fizice şi resurse umane.
Forma de organizare a unui sistem de fabricaţie integrează activităţi precum proiectare, procesare,
distribuţie, etc., care sunt strâns legate de doua bucle de reacţie. Prima se referă la o considerare
rapidă a cerinţelor pieţii şi respectiv a două la informaţiile senzoriale ale echipamentelor de
producţie. În Figura 1, adaptată după (Baker, 1998), sunt puse în evidenţă cele două bucle. Astfel,
sistemelor de fabricaţie au nevoie de o structură de control, care să permită ca sistemul să fie
adaptiv la cerinţele pieţii. Sistemele de fabricaţie sunt clasificate în cele cu procesare continuă şi
respectiv în sisteme cu procesare discretă.
Figura 1. Diagramă sistem de control în fabricaţie
2.3. Clasificarea arhitecturilor de control
În literatură se disting două principii de clasificare a arhitecturilor de control după
proprietăţile structurale (Dilts et al., 1991; Trentesaux, 2009). O primă clasificare se face după
numărul de entităţi decizionale, care separă arhitecturile în două categorii: centralizate şi
distribuite. Principalele caracteristici pentru cele două categorii sunt evidenţiate în Tabelul 1. O
arhitectură cu un control centralizat (global) are o singură entitate decizională care înglobează
toate funcţiile necesare conducerii unui proces. În controlul distribuit, abilităţile procesului
decizional global sunt distribuite mai multor unor entităţi decizionale. Relaţia formată între
aceste entităţi decizionale defineşte al doilea principiu de clasificare, unde arhitecturile de
control distribuit sunt grupate în: ierarhice, heterarhice şi semi-heterarhice (hibride). Termenul
„distribuit” este uneori asignat la distribuţia fizică, spaţială a resurselor, şi astfel el este adesea
implicit considerat în sistemele de manufacturare. Imaginea de ansamblu a clasificării acestor
arhitecturi este ilustrată în Figura 2.
7
Figura 2. Clasificarea arhitecturilor clasice de control (Trentesaux, 2009)
Tabelul 1. O comparaţie între arhitecturile centralizat (tradiţională) şi distribuit
Tradiţional Distribuit
Control centralizat distribuit cu cooperare
Arhitectură rigidă, statică (ierarhică) flexibilă, dinamică (ierarhică +
heterarhică)
Abordare top-down botton-up
Relaţie între entităţi client – server entitate – entitate
Comunicare 1 – N M – N
Eficienţă maximă specializare (volum
ridicat, varietate redusă)
flexibilitate (volum ridicat-mic,
varietate medie-mare)
Arhitectura de control tip ierarhic cuprinde elemente decizionale, între care sunt formate
relaţii ierarhice prin abordarea descendente (în engleză, top-down), unde entitatea superioară
controlează entitatea/entităţile inferioare. O primă extensie este arhitectura ierarhică modificată,
unde se introduce comunicarea între elementele fizice. Prin aceasta se încearcă o sincronizare
sau o reacţie eficientă între procese pe nivelul inferior. Această metodă sporeşte rigiditatea şi
complexitatea sistemului şi limitează aplicabilitatea în sisteme complexe de fabricaţie. O altă
extensie este arhitectura de control/coordonare distribuită. Aici, relaţia rigidă între nivele este
relaxată la forme interactive ale coordonării, care permite extinderea mai facilă.
Arhitectura de control de tip heterarhic are la bază elemente decizionale autonome şi
cooperante, unde fiecare entitate controlează un subsistem şi are cunoştinţe proprii şi complete
despre subsistem. La nivelul unui subsistem variabile sunt strâns legate, iar între subsisteme
acestea sunt slab legate, astfel că fiecare entitate are cunoştinţe parţiale sau minime despre alte
entităţi. Tipul de arhitectură caracterizează sistemele bazate pe agenţi, care sunt tratate pe larg în
secţiunea 2.4.
Arhitectura de control semi-heterarhică combină primele două arhitecturi – ierarhică şi
heterarhică – prin slăbirea autonomie elementelor decizionale din structura heterarhică, cu
introducerea unor elemente decizionale centralizate. Se constată în literatură două moduri de
implicare a elementelor centrale. În (Bongaerts, 1998; Bongaerts et al., 2000; Leitao, 2004) rolul
8
acestora este de a obţine optimul global în condiţii de bună funcţionalitate, încât avem o
arhitectură ierarhică de control/coordonare distribuită. Atunci când o disfuncţionalitate apare se
comută spre o funcţionalitate heterarhică. Un alt mod este cel descris în (Babiceanu, 2005), în
care elementele centrale monitorizară sistemul şi pe baza informaţiilor obţinute pot ajuta la
obţinerea soluţiilor optime prin propunerea de modificări. Aplicarea acestei scheme promite
atingerea atât a flexibilităţii cât şi a optimalităţii. Sistemele holonice sunt dezvoltate după acest
tip de arhitectură şi sunt tratate pe larg în secţiunea 2.5.
2.4. Sisteme multiagent
2.4.1. Conceptele de agent şi sistem multiagent
Termenul de agent indică un sistem computaţional ce reprezintă obiecte fizice sau logice,
capabil să perceapă şi să acţioneze autonom asupra unui mediu în mod potrivit pentru atingerea
propriilor scopuri. Într-un sens abstract, agentul este „o entitate care percepe şi acţionează într-un
mediu”, caracterizat printr-o măsură a performanţei care „evaluează comportamentul acestuia în
mediu” (Russell şi Norvig, 2009). Agenţii sunt propuşi ca entităţi/componente rezolvitoare de
probleme, capabili de o funcţionalitate eficientă în medii complexe, dinamice, impredictibile şi
deschise. Aceasta înseamnă că agentul primeşte o intrare de la mediul său prin dispozitive
senzoriale şi acţionează asupra mediului prin efectorii săi.
Agentul inteligent este agentul capabil de acţiune autonomă flexibilă în vederea
îndeplinirii obiectivelor sale (Wooldridge, 2001), unde flexibilitatea defineşte proprietăţile de
reactivitate, proactivitate şi abilitate socială. Pe lângă proprietăţile comportamentale enunţate,
alte proprietăţi sunt atribuite agenţiilor implicaţi în rezolvarea unor probleme, gradul de
satisfacere al acestora fiind unul variabil: situare adecvată, autonomie, reactivitate,
proactivitate, abilitate socială, bunăvoinţă, raţiune, adaptabilitate, flexibilitate, robusteţe.
Agenţii inteligenţi sunt clasificaţi în (Wooldridge şi Jennings, 1995; Nwana, 1996): agenţi
deliberativi, reactivi, hibrizi şi mobili.
Sistemul format din mai mulţi agenţi, numit sistem multiagent (SMA) sau sistem bazat pe
agenţi, este un sistem în care agenţii interacţionează prin diverse mecanisme (vezi secţiunea
2.4.3 cu relaţiile care se pot forma între agenţi) pentru atingerea scopurilor individuale sau
colective. SMA au în general o arhitectură heterarhică, unde atingerea scopurilor depinde de
aptitudinea, capacitatea şi cunoştinţele individuale. Arhitectură este uşor transpusă în una semi-
heterarhică, când se introduc agenţi coordonatori prin care gradul de autonomie al agenţilor
coordonaţi se limitează.
În prezenta lucrare se face referire la agenţii hibrizi, ne mobili, în special agenţii cognitivi
de tip BDI. Modelul BDI se detaliază în secţiunea următoare.
2.4.2. Agenţi deliberativi – model BDI
Un model comportamental al unui agent deliberativ este definit în (Rao şi Georgeff,
1992; 1995) prin trei caracteristici: convingeri/credinţe (în engleză, beliefs), dorinţe/scopuri (în
engleză, desires) şi intenţii (în engleză, intentions). Se consideră modelul a fi o adaptare după o
filosofie a raţionamentului practic, care implică în primă fază stabilirea unui scop, printr-un
proces deliberativ, şi se continuă cu evidenţierea mijloacelor/planurilor disponibile care ar
conduce la atingerea acelui scop. Raţionament de tip BDI are următorul flux de execuţie: la
existenţa unei dorinţe (scop), agentul printr-un proces deliberativ identifică opţiunile care ar
conduce către atingerea dorinţei şi, apoi, din lista de opţiuni alege una, după un criteriu sau nu,
9
care devine intenţie; la baza procesului deliberativ stau convingerile care ajută la filtrarea
opţiunilor. O asemenea funcţionare tinde să definească un echilibru între comportamentele pro-
activ şi reactiv ale unui agent. Modelul software BDI pentru dezvoltarea agenţilor BDI prezintă
un mecanism pentru separarea activităţii (1) de selectarea unui plan dintr-o bibliotecă de planuri
(selectarea unei intenţiei), (2) de execuţie a activităţilor din planul curent. În Figura 3 este
prezentată principial arhitectura software BDI, care este utilizată în aplicaţiile multiagent JACK
(Winikoff, 2005) şi JADEX (Pokahr et al., 2005). Elementele componente ale arhitecturii sunt:
baza de cunoştinţe, planuri, evenimente şi mecanism de raţionament.
Figura 3. Arhitectura software BDI
În realizarea unui scop, fiecare plan din biblioteca de planuri prezintă o funcţie care va
preciza dacă planul este aplicabil în starea curentă, şi un corp al planului care poate fi executat
în vederea realizării scopului (sau încercării de realizare a scopului); corpul unui plan este
structurat în paşi. Fiecare scop poate fi realizabil prin planuri diferite. În timpul execuţiei, un
agent va selecta un plan pentru realizarea unui scop (subscop) dat. Dacă planul selectat eşuează,
atunci un alt plan va fi încercat. Prin acest mecanism se consideră că agenţii sunt flexibili,
întrucât aceştia pot avea multiple planuri în realizarea unui scop, şi sunt robuşti, întrucât eşecul
unui plan nu înseamnă în mod necesar că scopul nu poate fi atins.
2.4.3. Relaţii dintre entităţi
În literatură, pentru SMA se regăsesc definiţii pentru potenţialele relaţii între două sau
mai multe entităţi din diferite arhitecturi bazate pe agenţi (D'Inverno şi Luck, 2004). În principal
sunt utilizaţi termenii: comunicaţie, colaborare, coordonare, cooperare, negociere şi competiţie.
În diagramă Venn ilustrată în Figura 4 (după Babiceanu, 2005) se prezintă tipurile de relaţii şi
caracteristicile definiţiilor care indică o suprapunere în cele mai multe cazuri; relaţia de
competiţie nu este prezentată în figură.
În prezenta teză accentul se pune pe comunicare, cooperante, colaborare şi coordonare.
Negocierea şi competiţia între agenţi sunt puţin atinse în mediul de fabricaţie în partea de
procesare.
10
Coordonare
Cooperare
Colaborare Colaborare
Negociere
Colaborare
Comunicație
Figura 4. Diagrama Venn cu relaţiile dintre entităţi într-un sistem multiagent
2.4.4. Scheme de coordonare
Coordonarea în sistem multiagent se referă la metodele de obţinere a unei comportări
coerente şi eficiente la nivel de sistem. În obţinerea coordonării vor fi implicate mai multe
aspecte. Astfel, este necesară o metodă de modelare care să permită evidenţierea interacţiunilor
între agenţi. Apoi, coordonarea pleacă de la felul în care agenţii tratează scopurile pe care le au
de rezolvat, ceea ce implică etapa de planificare. În funcţie de planurile elaborate vor fi necesare
măsuri corespunzătoare de sincronizare în faza de execuţie. Aceasta înseamnă că, atât în etapa de
planificare cât şi în cea de execuţie, coordonarea presupune şi mecanisme adecvate de
comunicaţie între agenţi. Dacă fiecare agent aplică un mecanism de planificare adecvat, acesta
trebuie să fie corelat şi cu un protocol de coordonare, în care printr-un schimb adecvat de
informaţii între agenţi să se obţină comportarea coerentă a sistemului multiagent.
Un protocol de coordonare frecvent utilizat în domeniul agenţilor este protocolul Contract
Net (Smith, 1980). În esenţă, CNP oferă o soluţie pentru aşa numita problemă de conectare:
găsirea agenţilor cu capabilităţi necesare care sunt dispuşi să colaboreze în rezolvarea unor
scopuri. Două roluri se disting: manager şi contractor. Un manager îşi asumă rolul de divizare a
unei probleme în sub-probleme, de căutare contractori şi coordonarea contractori alocaţi. Un
contractor are rol de îndeplinire scop contractat şi de asemenea poate deveni manager pentru o
nouă descompunere. Mecanismul include următoarele etape: (1) anunţarea de către un manager a
existenţei unui task cu timp de expirare, (2) evaluarea scopului şi propunerea unor oferte de către
posibilii contractori, (3) analizarea ofertelor primite în intervalul asociat şi acordarea unui
contract de către manager, (4) execuţia contractului de către contractor şi înştiinţarea
managerului despre îndeplinirea sau eşuarea scopului. Acest protocol este considerat în această
lucrare.
2.5. Sisteme holonice
2.5.1. Conceptele de holon si holarhie
Filosoful Arthur Koestler1 observă în urma studiilor sale asupra diferitelor tipuri de
organizare socială, că sistemele reale sunt construite pe o structură ierarhică, în care unele
entităţi sunt părţi ale unor entităţi mai largi şi nu există o separare clară între părţi şi întreg atunci
când se privesc sistemele sociale sau biologice. Pentru descrierea unei unităţi de bază a
organizării în sistemele biologice şi sociale, Koestler propune termenul de holon, care se referă
la asocierea a doi termeni din limba greacă, „holos” însemnând un întreg, iar sufixul „on”
1 Referitor la conceptul de holon, autorul îl detaliază în cartea sa, The Ghost In The Machine (1967).
11
însemnând parte; un holon este o entitate de sine stătătoare în contextul de său de bază, dar poate
fi o parte a unei alte entităţi într-un context mai larg. Legat de organizarea holonilor, autorul
propune în acest sens conceptul de holarhie nemărginită ca o arhitectură formată din holoni, care
nu este mărginită în amândouă direcţiile. O altă definiţie a holarhiei este propusă în (Spangler,
2008), unde o holarhie este o structură ierarhică temporară; diferenţa primară faţă de o ierarhie
este dată de faptul că într-o ierarhie în sens clasic entităţile pot fi comparate şi evaluate pe baza
poziţiei, rangului, puterii relative, vechimii, iar intr-o holarhie fiecare valoare a entităţii vine din
individualitatea şi unicitatea ei, şi de asemenea, din capacitatea acesteia să se angajeze şi să
interacţioneze cu alte entităţi pentru a valorifica unicitatea disponibilităţii. Conform cu cele
menţionate, existenţa unui holon într-o holarhie este provizorie şi se întinde pe intervalul cât
holonul este necesar holarhiei.
2.5.2. Sistemele de fabricaţie holonice
Adoptarea iniţială a conceptelor holonice în fabricaţie se datorează incapacităţii
sistemelor existente de producţie de a face faţă cu (1) evoluţia continuă a produselor în mediile
existente şi (2) menţinerea unor performanţe înafara unor condiţii normale de operare
(Bussmann, 1998). Prin urmare, adaptabilitatea, flexibilitatea şi stabilitatea în faţa schimbărilor,
utilizarea eficientă a resurselor, securitatea şi extinderea soluţiilor constituie obiective ale
sistemelor holonice aplicate în fabricaţie (în engleză, Holonic Manufacturing Systems - HMSs ).
Se vizează o nouă generaţie de sisteme de fabricaţie inteligente, care ar urma prin implementarea
bazată pe holoni inteligenţi, autonomi şi cooperativi. Termologia primară formată în această
direcţie cuprinde următoarele definiţii:
holon – o entitate autonomă şi cooperantă a unui sistem de producţie folosite pentru
prelucrarea, transportarea, stocarea şi/sau validarea informaţiei şi pentru controlul
unor entităţi fizice; holonul este o componentă ce cuprinde o parte procesatoare de
informaţii şi uneori o parte de procesare fizică; un holon poate fi parte a altui holon.
autonomia – capacitate a unei entităţi să creeze şi controleze execuţia planurilor sau
strategiilor proprii.
cooperare – un proces unde o mulţime de entităţi dezvoltă şi execută planuri comune.
holarhie – un sistem format din holoni ce cooperează pentru atingerea unui scop;
holarhia defineşte regulile primare pentru cooperare şi limitele autonomiei.
sistem holonic de execuţie a fabricaţiei (în engleză, Holonic Manufacturing Execution
System - HMES) – reprezintă un subdomeniu al HMS, în care accentul cade pe
aspectele legate de fabricarea propriu-zisă a produselor, pe sistemul de fabricaţie de la
nivelul „shop-floor” al unei companii.
Datorită similitudinii între termenul de holon şi cel agent, Bussmann propune în
(Bussmann, 1998) o arhitectură pentru agentul holonic2 în concordanţă cu viziunea holonică
(vezi Figura 5). Autorul argumentează necesitatea înzestrării fiecărui agent holonic cu o serie de
elemente:
Algoritmi pentru planificare şi control prin care agenţii holonii îşi creează şi execută
propriile planuri, urmând ciclurile interne de planificare şi execuţie.
Mecanisme de comunicare şi coordonare prin care se asigură cooperarea ori de câte ori
este nevoie.
2 Termenul de agent holonic face referite la agentul din componența holonului.
12
Încorporarea acestor elemente în fiecare entitate decizională conduce spre o arhitectura
heterarhice, specifică sistemelor multiagent, însă organizarea structurii este una ierarhică,
datorită caracterului cooperant al fiecărei entităţi. Toate acestea conduc la dezvoltarea unor
tehnici specifice de organizare/formare a holarhiilor.
social individual
tehnici
cooperare
bloc decizional
tehnici
organizare
control
comportamentaltehnici
comunicare
comunicare fizică control parte fizică
opţional
Procesarea
Informaţiei
Figura 5. Arhitectură bazată pe agent pentru un holon (Bussmann, 1998)
Introducerea holonilor în mediul de fabricaţie reprezintă în esenţă un concept care este
materializat prin mijloacele abordării bazate pe agenţi şi tehnologia aferentă sistemelor
multiagent (Babiceanu şi Chen, 2006; Leitao, 2009). În Tabelul 2 este prezentată o paralelă între
cele două concepte, unde se poate observa o strânsă legătură între acestea. Domeniul HMS
include toate aspectele ce aparţin unui sistem de fabricaţie (adică inclusiv management,
distribuţie, etc.). Această teză se limitează la aspectul de execuţie (fabricaţie), adică la
subdomeniul sistemelor de execuţie în fabricaţie de tip holonic. Trebuie remarcat felul în care
holarhia înglobează holoni, care sunt calificaţi la momentul formării holarhiei, iar posibilitatea
găsirii unui holon mai adecvat după stabilirea acesteia conturează necesitatea unor abordări pe
termen scurt, mediu, şi lung de formare a holarhiei.
Tabelul 2. O comparaţie între termenul de agent şi cel de holon
Agent Holon
Origine (domeniu) Inteligentă Artificială CIM (Computer Integrated
Manufactuing)
Stare curentă concept şi tehnologie concept
Proprietăţi autonomie, reactivitate,
pro-activitate, abilitate
socială
autonomie, reactivitate, pro-
activitate, abilitate socială,
auto-configurare, recursivitate
Model entitate (atom) entitate şi parte din altă entitate
Integrare dispozitiv fizic nu da
Constrângere de timp real da/nu da
Sistem sistem multiagent holarhie
Apartenenţa sistem multiagent grupuri multiple/temporare
13
2.5.3. Arhitecturi holonice de control
Arhitecturile holonice sunt propuse în special pentru mediile de fabricaţie unde este
necesară realizarea unui flux de producţie eficient, stabil, flexibil şi adaptiv sub existenţa unor
factori perturbatori. În acest sens, există mai multe arhitecturi holonice prezente în literatura de
specialitate, apărând diferenţe în ceea ce priveşte rolurile asociate holonilor şi relaţiile dintre
aceştia. Câteva arhitecturi, PROSA, ADACOR şi HCBA sunt mai des menţionate, fiind de
interes şi pentru dezvoltările din prezenta teză, şi sunt discutate sumar în paragrafele următoare.
Arhitectura holonică PROSA (în engleză, Product-Resource-Order-Staff Architecture)
este o arhitectură de referinţă (Van Brussel et al., 1998; Wyns, 1999; Valckenaers şi Van
Brussel, 2005) pentru mai multe abordări şi implementări holonice. Prin PROSA sunt
identificate şi definite tipurile de holoni necesari şi respectiv structura de interacţiune, pentru
dezvoltarea sistemelor de fabricaţie prin abordarea holonică. În urma unor studii asupra
proceselor de fabricaţie, autorii definesc patru clase de holoni, unde una dintre acestea este
opţională: holoni resursă, produs, ordin şi holonii staff care sunt opţionali. Aceşti holoni sunt
specializaţi şi corespund unor aspecte distincte de control în fabricaţie. Forma de organizare a
structurii holonice este una heterarhică. Structura semi-heterarhică se atinge odată cu
considerarea holonilor staff (Bongaerts et al., 2000), cei având funcţii de alocare în timp
(scheduling) a operaţiilor şi de control online global.
Arhitectura ADACOR (în engleză, ADAptive holonic COntrol aRchitecture for
distributed manufacturing systems) este propusă pentru HMES şi introduce o organizare
adaptivă, care balansează dinamic între o structură centralizată şi una descentralizată, şi care
permite combinarea optimizării globale a producţiei cu o reacţie agilă la perturbaţiile neaşteptate
(Leitao, 2004; Leitao şi Restivo, 2006). Faţă de arhitectura PROSA, Leitao schimbă denumirea
holonilor, astfel încât holonii resursă, ordin şi staff sunt etichetaţi prin holon operaţional, holon
task şi holon supervizor (HSup). Prin HSup se introduce coordonarea şi optimizarea globală în
abordarea controlului descentralizat. În condiţii normare, HSup supervizează şi reglementează
activitatea holonilor din domeniul lui. În cazul unei perturbaţii, holonii din domeniu trebuie să
găsească o soluţie şi să o adapteze fără ajutorul HSup.
Arhitectura HCBA (în engleză, Holonic Component Based Architecture) elaborată la
Universitatea Cambridge, este derivată din dezvoltarea bazată pe componente şi HMS (Chirn şi
McFarlane, 2001). Autorii definesc două clase de holoni: produs şi resursă. Holonii resursă sunt
echipamente fizice cu sisteme de operare integrate, care execută operaţii fizice specifice
echipamentelor. Holonii produs cuprind componente fizice (semi-fabricate, paleţi sau piese
brute) cuplate la sisteme de control. În HCBA, agenţii sunt utilizaţi pentru a controla în mod
cooperant un sistem de fabricaţie. Pe lângă agenţii produs şi resursă, în schema HCBA este
introdus un agent broker, ca o infrastructură de comunicaţie. În (Covanich şi McFarlane, 2009)
se prezintă o comparaţie între o dezvoltare HCBA şi una centralizată.
2.6. Etape în conducerea fluxurilor de activităţi
Principalele etape în conducerea fluxurilor de activităţi implică implicit două faze:
planificare fluxurilor şi execuţia acestora. Pentru sistemele multiagent trebuie găsite metode
adecvate de planificare; acestea trebuie să contribuie la evitarea acţiunilor inconsistente şi
conflictuale. Planificarea în sistemele multiagent se poate descrie ca o abordare a coordonării, în
care din faza de proiectare a secvenţei de acţiuni care rezolva un scop trebuie să se ţină seama de
14
interacţiunile dintre agenţi. Această abordare trebuie să permită agenţilor să construiască un plan
multiagent care să conţină detalii ale tuturor acţiunilor şi interacţiunilor viitoare. Agenţii pot în
acest fel să realizeze propriile scopuri şi să întrepătrunde execuţia cu mai multe procese de
planificare şi re-planificare. Faţă de varianta mai des utilizată în cazul sistemelor centralizate,
aceea a planificării în spaţiul stărilor (Ghallab et al., 2004), pentru cazul sistemelor multiagent
planificarea în spaţiul planurilor (Ghallab et al., 2004) poate furniza soluţii adecvate, aşa cum se
prezintă în această lucrare.
Accentul în această teză se pune pe planificarea în spaţiul planurilor. Aceasta constă în
rafinarea pas cu pas a unui plan parţial iniţial aplicând-se principiul celei mai mici angajări (în
engleză, least commitment principle) până la atingerea unui plan complet sau parţial ordinat care
constituie soluţie la problema planificării. Un plan parţial implicit se formează din setul de
acţiuni fictive {a0, a∞} care reprezintă sub o formă codificată starea iniţială s0 şi starea scop sg.
Efectele acţiunii a0 definesc starea iniţială s0, iar precondiţiile acţiunii a∞ sunt condiţiile necesare
atingerii sg. Principiul celei mai mici angajări impune ca o alegare (o operaţie) să fie făcută doar
atunci când este strict necesară. În planificare, principiul separă partea rigidă a planului, dată de
constrângerile impuse, de partea flexibilă care dă soluţiile multiple ale problemei de planificare.
O operaţie de rafinare constă în: adăugare acţiuni, adăugare constrângere de ordonare, adăugare
legătură cauzală, adăugare constrângeri de legare variabile şi rezolvarea conflictelor. O legătură
cauzală între acţiunile aj şi ai apare implicit când o precondiţie a acţiunii aj este susţinută de un
efect al acţiunii ai, sau când o constrângere de ordonare între acţiuni este stabilită (ai ≺ aj).
Metodă planificării în spaţiul planurilor este aplicată însă într-o formulă specifică.
Dezvoltarea unui mecanism planificator care să plece de la zero într-un mediul de fabricaţie este
puţin probabil a fi una practică. De exemplu, un produs are deja un plan dezvoltat de proiectant
şi deci putem vorbi de o planificare offline deja efectuată, cunoscută. Planificarea offline va
continua cu o planificare online în care planul dezvoltat este completat astfel încât să fie pregătit
pentru execuţie. Aceste aspecte vor fi tratate pe larg în următorul capital.
2.7. Concluzii
Studiile şi experimentele efectuate, aplicând abordarea holonică bazată pe agenţi, au
condus la câteva concluzii. Proiectarea şi dezvoltarea ad-hoc a unor agenţi holonici complecşi,
dependenţi de mediul de fabricaţie considerat, va conduce în timp la un sistem ineficient. De
asemenea, s-a observat că modul de lucru, operare, al agenţilor holonici – produs, resursă şi
ordin – este în mare măsură identic. Ţinând seama de aceste aspecte s-a ajuns în prezenta teză la
proiectarea şi dezvoltarea unei noi arhitecturi de conducere a fluxurilor de activităţi, sub
abordarea holonică. În noua arhitectură sunt adunate elemente extinse necesare în sistemele de
execuţie a fabricaţiei, pentru operarea sigură. În următoarele două capitole este prezentată o nouă
arhitectura din punct de vedere structural (capital 3) şi comportamental (capitol 4).
15
Capitolul 3 Propunerea unei arhitecturi de conducere – HAPBA
3.1. Introducere
În acest capitol se introduce o nou arhitectură holonică, sub care sunt propuse principii şi
strategii pentru planificarea şi controlul fabricaţiei. Arhitectura este o implementare a arhitecturii
PROSA; aceasta este numită HAPBA - Holonic Adaptive Plan-Based Architecture - în vederea
sugerării importanţei unei soluţii adecvate pentru faza de planificare, care trebuie să faciliteze o
operare adaptivă şi sigură pentru HMES. Noua abordare se bazează pe combinarea mai multor
ingrediente: planificarea în spaţiul planurilor, mecanismul de raţionament de tip BDI,
coordonarea prin protocolul Contract Net şi pe conceptele de holon şi holarhie; toate aceste
elemente sunt adaptate şi completate cu elemente specifice abordării holonice.
3.2. Model structural al unui holon
Modelul generic al unui holon, aşa cum este considerat în HAPBA, este prezentat în
Figura 6 (Pănescu et al., 2008; Pănescu et al., 2009c). Holonul se compune dintr-o componentă
deliberativă şi una de structură. Partea deliberativă este dată de un agent software, numit agent
holonic. Componenta de structură reprezintă partea de execuţie, care se formează dinamic pe
baza stării curente a sistemului holonic, din alţi holoni colaboratori. Holonii implicaţi, numiţi
holoni contractori, sunt aleşi printr-un protocol de coordonare adecvat, în urma unui proces de
planificare, astfel încât holonii selectaţi au capabilităţi în soluţionarea scopurilor propuse. O
excepţie există în cazul unor holoni, la care componenta de structură cuprinde implicit un
dispozitiv fizic de execuţie, dar pe lângă această parte fizică pot fi implicaţi alţi holoni. Într-o
manieră recursivă, holonii contractori îşi formează componenta de structură (vezi Figura 7).
Figura 6. Structura unui holon generic
(Pănescu et al., 2008)
H1
H2 H3
H4
H5
D2
D4
D5
agent holonic
componentă de structură
echipament fizic de execuție
Figura 7. Formarea recursivă a componentelor
de structură
Astfel, structura ierarhică temporară formată dinamic într-un mod recursiv din holoni
contractori şi subcontractori, după un proces de planificare rezultat în urma unui scop, constituie
holarhia. Holarhia este formată astfel încât valoarea fiecărui holon este dată din individualitate şi
unicitate, şi din capacitatea de implicare în vederea folosirii în mod avantajos a resurselor
disponibile. Prin modul de formare a holarhiei se permite implicarea unui holon la una sau mai
16
multe holarhii. Cele două componente ale holonului, agentul holonic şi componenta de structură,
sunt conectate prin mijloacele unei interfeţe de comunicaţie, care facilitează comunicarea între
agenţii holonici sau acolo unde este cazul între agent şi partea fizică de execuţie. În sistemul
holonic există excepţii faţă de modelul generic, în care componenta de structură lipseşte. Este
cazul holonilor introduşi în sistem pentru prevenirea unor conflicte sau pentru eficientizarea
procesului de manufacturare. Cu acest rol, astfel de holoni nu prezintă parte de execuţie
3.3. Clase de holoni consideraţi
În arhitectura holonică HAPBA, clasele de holoni sunt aceleaşi cu cele propuse în
arhitectura de referinţă PROSA, dar rolurile holonilor sunt ajustate în mod specific.
Holonul resursă (HR) corespunde unei resurse fizice din sistemul de fabricaţie (robot
industrial, dispozitiv de stocare, maşină de prelucrare, etc.), resursă care constituie implicit
componenta de structură. Agentul holonic, prin mijloace proprii, gestionează resursa şi expune
serviciile acesteia în sistem.
Holonul produs (HP) corespunde unui produs, semi-fabricat ce urmează a fi realizat
printr-un proces tehnologic specific. Agentul corespunzător menţine în baza de cunoştinţe piese
de cunoaştere despre modelul şi procesul de fabricaţie a produsului. Este implicat activ în
alegerea combinaţiei optime de operaţii şi de resurse, determinând colaborarea cu alţi holoni
produs şi/sau holoni resursă în vederea formarii părţii de structură (părţii de execuţie). Evoluţia
stării de fabricaţie a produsului este menţinută pe parcursul procesului de execuţie.
Holonul ordin (HO) este responsabil cu primirea şi gestionarea comenzilor de producţie,
prin emiterea scopurilor potrivite şi monitorizarea îndeplinirii acestora; reprezintă nivelul curent
într-un nivel superior sub forma unui holon produs complex.
Holonul staff (HS) este responsabil cu menţinerea unei baze de cunoştinţe cu
capabilităţile holonilor; oferă informaţii despre posibili contractori şi este implicat activ în
prevenirea conflictelor dintre holoni în procesul de coordonare.
3.4. Model structural al unui sistem holonic
Structura holonică propusă în HAPBA pentru un sistem HMES este prezentată un mediu
de fabricaţie în Figura 8 (Pănescu şi Pascal, 2010b). Nivelele de producţie (nivel celulă de
fabricaţie, nivel shop floor, nivel întreprindere, etc.) au aceeaşi structură holonică. Legătura între
nivele se face prin holoni ordin. Modul în care un holon ordin este considerat este unul consistent
cu principiul holonic, conform căruia holonul este o entitate cu două feţe: una îndreptată spre
partea interioară, când ne gândim la entitate ca la un holon ordin, şi o altă faţă îndreptată spre
exterior, spre o holarhie de nivel superior, când acelaşi holon se comportă ca un holon produs. În
acest mod, fiecare celulă de fabricaţie este integrată dinamic într-un sistem de fabricaţie ca o
componentă de structură comandată de un holon ordin. Stabilirea unor legături specifice între
celulele de fabricaţie este astfel posibilă şi unde holonul ordin este singurul tip de holon care
poate reprezenta o holarhie şi care poate exista simultan în mai multe structuri holonice, acolo
unde serviciile acestuia sunt necesare. Holonii produs şi resursă au instanţe diferite, adaptate
corespunzător mediului de producţie respectiv. Astfel un holon produs într-un sistem holonic
poate să aibă mijloace diferite în soluţionarea scopului faţă de alt sistem holonic (altă celulă de
fabricaţie). Acest aspect de generalitate şi configurabilitate specific mediului a impus dezvoltarea
unui agent holonic cu o structură generală şi un ciclu de lucru identic pentru toate clasele de
17
holonii – produs, ordin şi resursă, exceptând holonul staff. Acest aspect este unul din principiile
arhitecturii HAPBA.
Figura 8. Modelul structurii holonice
3.5. Elemente principiale privind proiectarea agenţilor holonici
Proiectarea şi dezvoltarea agenţiilor holonici în HAPBA privesc următoarele aspecte:
protocolul Contract Net ca mecanism de coordonare, aplicarea unui mecanism de raţionament de
tip BDI şi considerarea unui mecanism al planificării în spaţiul planurilor. Aceste elemente
necesită a fi extinse şi adaptate mediului de execuţie al fabricaţiei.
Exceptând holonii fără componentă de structură, holonii staff, şi ţinând seama de
arhitectura BDI şi schema de coordonare Contract Net, se consideră trei stări primare, necesare
ale agentului holonic: planificare, execuţie şi aşteptare. În planificare, agentul holonic îşi
construieşte componenta de structură, prin validarea unui plan pentru execuţie. În execuţie,
există o comunicare cu partea de execuţie pentru execuţia acţiunilor (scopurilor) din planul
deliberat (hotărât în urma trecerii holonului prin prima stare menţionată, cea de planificare).
Starea de aşteptare reprezintă intervalul în care agentul holonic nu este implicat într-o activitate
deliberativă/ de comunicaţie cuprinsă în fazele de planificare sau execuţie. Aceste procese,
pentru un scop, pot fi întrerupte şi continuate, astfel încât agentul poate trece în mod repetat prin
starea de aşteptare.
Nevoia unui protocol de coordonare Contract Net extins
Protocolul de coordonare Contract Net (CNP) aplicat în sistemele de execuţie a
fabricaţiei trebuie adaptat corespunzător. Implicarea unui contractor în soluţionarea unui scop
implică două condiţii. Întâi, acesta trebuie să fie adecvat rezolvării scopului şi, apoi, trebuie să
poată să-şi valideze un plan de execuţie (adică să găsească resursele necesare). Se accentuează
faptul că un posibil contractor existent în sistem nu va garanta şi implicarea acestuia. O altă
nuanţă este legată de aspectul de alocare. La existenţa unui scop, un contractor încearcă să-şi
valideze un plan, prin care acesta ar putea efectua scopul. Când un plan a fost validat, putem
afirma despre contractor că s-a alocat scopului. Astfel, resursele acestuia (subcontractori şi/sau
partea fizică) rămân alocate până când managerul va decide neacceptarea ofertei sau până la
utilizarea lor când contractul a fost atribuit. Un alt aspect legat de CNP este privitor la modul de
anunţare a scopurilor în sistem. Anunţarea se face către toţi contractorii care prezintă abilităţi în
soluţionarea scop. Aceste aspecte au condus la stabilirea unor condiţii specifice în utilizarea
coordonării prin CNP:
18
un contractor îşi anunţă intenţia de implicare prin propunerea unei oferte, dacă are un
plan validat şi alocat; în caz contrar răspunde cu o oferă negativă;
un manager are obligaţia ca în urma propunerii unui scop şi primirii ofertelor aferente să
anunţe contractorii în privinţa acceptării sau nu;
un manager va trece la faza de execuţie după ce întregul plan a fost validat şi alocat;
un posibil contractor, fără a primi contractul, poate deveni manager pentru subscopurile
care sunt rezolvabile prin colaborare; fiecare posibil contractor/subcontractor trebuie să
propună o oferă chiar dacă nu poate efectua scopul (în acest caz se numeşte oferă
negativă).
Necesitatea unui mecanism de raţionament BDI extins
Soluţia din arhitectura HAPBA se distinge faţă de cea propusă în (Jarvis et al., 2008) prin
modul în care mecanismul de inferenţă al agentului este integrat în mod activ în procedurile de
planificare şi control. Holonii prin natura lor sunt orientaţi spre cooperare. Acest aspect reiese şi
din modelul generic al holonului propus în secţiunea 3.2., unde structura holonică se formează
din holonii dispuşi să îşi ofere serviciile. Astfel planurile din bibliotecile de planuri ale holonilor
sunt planuri de execuţie, care cuprind şi acţiuni soluţionabile de către alţi holoni. În cazul
special, acela al holonilor resursă, acţiunile lor sunt executate de componenta fizică de execuţie
sau de alţi holoni. Alocarea şi validarea acestor planuri în funcţie de scop şi de starea sistemului
este în sarcina procesului de planificare. Succesiunea de acţiuni a fazei de planificare este, de
asemenea, un plan. Astfel, întregul flux de activităţi de la primirea unui scop până la finalizarea
acestuia constituie un plan; acesta prezintă în prima parte acţiuni cu scop de instanţiere a
şabloanelor de acţiuni din partea a doua. Sub această formă, mecanismul de raţionament este în
principal implicat în procesul de planificare: acesta va determina alocarea unui plan de
planificare relevant scopului şi în context cu starea sistemului de fabricaţie. Atunci când fluxul
de planificare eşuează în validarea fluxului de execuţie, întregul flux este abandonat. Fazele de
planificare şi execuţie sunt întrerupte, introducându-se stări de aşteptare, astfel încât fluxurile a
două sau mai multe scopuri se pot intercala. În Figura 9 se prezintă diagrama de interacţiune-
operare dintre doi holoni, manager şi contractor, considerând protocolul de coordonare Contract
Net. În concluzie, rezultatul mecanismului de raţionament de tip BDI va fi un flux de activităţi ce
va cuprinde partea de planificare şi cea de execuţie
Figura 9. Diagrama de interacţiune-operare holoni
19
3.6. Relaţii intre holoni
Două elemente principiale stabilesc necesitatea unei relaţii apriorice între holoni.
Aplicarea unei metode tradiţionale de planificare din IA (Inteligenţă Artificială), care implică
dezvoltarea planurilor online, nu este adecvată în luarea deciziilor în timp real, în mediul de
fabricaţie. Metoda considerată este aceea a utilizării unei colecţii de planuri parţial formate, într-
un proces offline, şi care sunt ulterior completate online. Între holoni există o relaţie de
cooperare; holonii produs necesită holoni resursă în fabricarea produsului, iar cooperarea între
resurse diversifică modurile de procesare a produselor. Astfel, proiectarea şi dezvoltarea
planurilor unui holon depinde de capabilităţile resurselor şi de cerinţele din sistem. Spre
exemplu, introducea un nou holon produs în sistemul holonic necesită cunoaşterea mediului de
fabricaţie, a capabilităţilor holonilor resursă şi a scopurilor pe care holonii resursă deja existenţi
le pot rezolva. Rezultă astfel modalităţile în care se ajunge la dezvoltarea de holarhii: existenţa
resurselor multiple care pot gestiona un scop şi a planurilor multiple prin care un scop poate fi
atins cu sau fără colaborare. Modurile multiple de formare a holarhiilor depind de capabilităţile
fizice ale resurselor. Atunci când un holon părăseşte sistemul, schema holarhică în care acesta
apare nu va mai putea fi aplicată dacă în sistem nu există un alt holon cu servicii similare.
3.7. Strategii de coordonare
Anticipând elementele care vor fi detaliate în capitolele următoare, atât în urma validării
arhitecturii prin considerente teoretice (Capitolul 4), cât şi în urma analizelor şi experimentelor
efectuate (Capitolul 6), s-au evidenţiat unele dezavantaje ale structurii holonice. Acestea au
condus la completarea schemei de coordonare aplicate în HABPA, prin propunerea următoarelor
strategii: strategia bazată pe holonul staff, strategia ofertării relaxate şi cea a etichetării
scopurilor.
Nevoia unor componente holonice centralizate
Datorită nevoii unei componente centralizate într-un sistem heterarhic se defineşte
strategia bazată pe holonul staff. Nevoia apare din faptul că la nivelul fluxurilor de planificare
pot apărea interferenţe negative, şi acest lucru rezultă din modul în care CNP este o schemă de
coordonare care nu returnează întotdeauna o soluţie pentru o problemă, chiar dacă aceasta există.
Pentru soluţionare, o formă cu o nouă extindere a protocolului CNP este utilizată în HAPBA.
Aceasta implică trei tipuri de entităţi – holonii manager, contractor şi staff. Deoarece operarea
unui contractor nu este afectată de introducerea holonului staff, ciclul acestuia este cel a unui
CNP normal. Pentru agentul holonic care are rolul de manager, la ciclu de lucru este adăugată o
comunicare iniţială şi finală cu holonul staff (vezi Figura 10, unde managerul este un holon
produs şi contractorii sunt holonii resursă), prin care se solicită iniţial lista de posibili contractori
din sistem, care pot soluţiona un set de scopuri, iar în final după finalizarea planificării, holonul
manager va indica acest fapt holonului staff. Elementul de noutate este faptul că holonul staff va
da lista doar atunci când nu pot exista conflicte cu procese de planificare aflate în derulare.
Holonul staff trebuie să asigure nu numai mesajul de validare, ci şi mulţimea de
contractori potenţiali pentru fiecare acţiune (sub-scop). În HAPBA, prin utilizarea acestei
mulţimi, un manager anunţă un scop numai contractorilor indicaţi. Pentru a fi în măsură să
furnizeze astfel de informaţii, este necesar ca holonul staff să primească şi să menţină datele
corespunzătoare de la toţi agenţii holonici care aparţin domeniului său. Oricare holon trebuie să
20
înceapă operarea prin anunţarea (înregistrarea) tipurilor de scopuri pe care acesta este capabil să
le rezolve către holonul staff. În consecinţă, este clar că holonul staff poate detecta cazul când nu
există niciun holon capabil să execute o acţiune cuprinsă în planul unui manager şi poate furniza
un mesaj potrivit. Informaţiile din baza de cunoştinţe a holonului staff sunt folosite în dublu
scop: în ghidarea comunicaţiei în CNP (determinarea contractorilor) şi în mecanismul de blocare
al holonului staff. În legătură cu acesta, abordarea simplă este să se oprească un plan când printre
posibili contractori pentru acesta sunt unii deja implicaţii într-un proces de planificare, în curs de
desfăşurare. Condiţia de blocare pentru un plan πi poate fi exprimată prin:
πj , πj PIP, astfel încât Hπi ∩ Hπj ≠ (2)
unde Hπk este mulţimea care conţine nume ale holonilor:
Hπk = {H | H un holon care rezolva o acţiune din πk } (3)
şi PIP (Planuri în Progres) este o mulţime a tuturor planurilor deja permise, validate (care sunt în
planificare şi nu sunt finalizate încă). Aplicarea acestui algoritm presupune menţinerea
informaţiilor despre holonii implicaţi în procesele de planificare de către holonul staff; aceste
informaţii sunt actualizate de mesajele primite de la manager în primul pas şi al cincilea pas al
ciclului. Condiţia (2) este suficientă şi verificarea ei implică complexitatea O(n), unde n este
cardinalul reuniunii mulţimilor Hπk , pentru toate planurile πk aparţinând mulţimii PIP. Înseamnă
că holonul staff are de-a face cu mai multe sau mai puţine teste înainte de a lua decizia de a
valida o cerere, depinzând de numărul de planuri care sunt în procesare la acel moment.
Figura 10. Diagrama de interacţiune pentru protocolul de coordonare cu holonul staff
Un plan supus procesării care este în aşteptare va fi considerat şi validat pentru tratarea în
CNP, când planurile cu care poate interfera sunt finalizate. În ceea ce priveşte această situaţie,
după ce holonul staff primeşte un mesaj de la un manager despre terminarea unui proces de
planificare, acesta trebuie să-şi actualizeze mulţimea PIP şi să reaplice testul de validare pentru
toate planurile din lista cu planuri întârziate. Oricare ar fi un astfel de plan, dacă nu satisface
21
condiţia de blocare (2), este îndepărtat din listă şi managerul care a făcut cererea primeşte
mesajul de validare de la holonul staff.
Nevoia de ofertare relaxată şi etichetare scopuri
Strategia prezentată anterior necesită a fi aplicată într-un sistem holonic, dar nu este
întotdeauna suficientă. Un efect negativ poate să apară atunci când posibilii contractori au
resurse limitate pentru implicarea lor în diverse acţiuni ale managerului. Este posibil ca un
contractor să poată soluţiona două sau mai multe acţiuni dintr-un plan al managerului, însă într-
un mod secvenţional, sau numai o parte din acţiuni. De exemplu, un holon manager are un plan
cu două acţiuni pentru contractori. În sistemul holonic există doi holoni contractori; primul poate
soluţiona numai prima acţiune, iar al doilea are mijloace să soluţioneze ambele acţiuni, dar nu
simultan. Dacă managerul după anunţarea primului scop alege oferta celui de-al doilea
contractor, a doua acţiune rămâne fără nicio ofertă. Conflictul este unul destul de clar, în care o
alegere greşită va conduce la nerezolvarea scopului, deşi în sistem există o soluţie. Acest caz
reiese din rezultate prezentate în secţiunea 6.2.
Soluţia propusă pentru un asemenea caz, numită strategia de ofertare relaxată, constă în
asigurarea pentru un contractor a posibilităţii de a efectua o ofertă chiar atunci când capacitatea
acestuia este diminuată, la momentul propunerii unei oferte anterioare, cu condiţia ca oferta
suplimentară să se refere la acelaşi plan al managerului. Evident, în acest caz soluţia determinată
de strategia de ofertare relaxată presupune o planificare secvenţială a acţiunilor implicate, aspect
ce este rezolvat de mecanismul de planificare folosit în HAPBA.
Un efect negativ care se poate constata într-un sistem holonic este şi acela care apare
atunci când un scop propus de un manager nu are nicio soluţie, iar în sistem există holoni
contractori care pot fi implicaţi într-o tentativă de soluţionare a scopului, intrând într-un proces
de contractare în care se apelează reciproc şi creează o buclă infinită (Pănescu et al., 2009a).
Strategia propusă în HAPBA pentru eliminarea acestei situaţii, numită strategia de etichetare
scopuri, constă în ataşarea unor etichete însoţitoare ale scopurilor, pe baza cărora holonii
contractori pot detecta apariţia unei bucle în procesul de negociere. Astfel ei pot sista
contractarea, eliminând deficienţa semnalată. Detalii legate de materializarea şi exemplificarea
acestor strategii sunt date în capitolul al şaselea al tezei.
3.8. Structura unui agent holonic de tip JACK. Ciclu de lucru.
În această secţiune se pune în evidenţă o implementare a arhitecturii HAPBA prin
mijloacele platformei JACK (JACK, 2005) sau JADEX (Winikoff, 2005). Structura a unui agent
holonic în JACK, care ţine seama de toate elementele precizate în secţiunile anterioare, este
aceea din Figura 11 (Pănescu et al., 2009b). Se evidenţiază patru blocuri funcţionale (notate de la
I la IV), care sunt corelate cu clasificarea stărilor agentului precizată anterior. Există o
corespondenţă între elementele structurii de implementare şi etapele pe care le presupune
protocolul reţelei de contractare, cu extinderile ce au fost considerate. Blocul I serveşte la
primirea mesajelor de anunţare a scopurilor şi de acordare a contractelor. Blocul II se ocupă de
acţiunile privind planificarea referitoare la selectarea scopurilor, la calcularea şi trimiterea
costului ofertelor. Blocul III selectează scopurile care au primit contractele de execuţie şi
transmite comenzi de acţiune spre componenta de structură a holonului, într-un mod iterativ.
Blocul IV apare numai la holonii resursă şi reprezintă canalul de comunicaţie între agentul
holonic şi dispozitivul fizic de execuţie.
22
Bazele de cunoştinţele ale agentului sunt formate prin utilizarea a trei entităţi de tip
BeliefSet (acestea sunt reprezentate grafic în figură prin cilindri) despre: scopuri şi contractele
primite/acordate, starea mediului, despre istoria mesajele de colaborare cu alţi holoni. Planurile
sunt reprezentate din dreptunghiuri cu colţuri rotunjite. Prin săgeţi sunt reprezentate evenimente,
care sunt declanşate la apariţia unui eveniment extern (de exemplu, un mesaj de la alt agent
holonic), la existenţa unei piese de cunoaştere în bazele de cunoştinţe sau de la acţiune dintr-un
plan. Suplimentar, blocul I cuprinde un mecanism pentru primirea unui set de scop prin
recepţionarea de mesaje consecutive. De asemenea, structura proiectată pune în evidentă
posibilitatea alegerii unui scop sau unui contract după prioritate (planurile SelectGoalByPriority
şi SelectContractByPriority). Mecanismul BDI este declanşat de evenimentul
SelectedGoalEvent, prin care se selectează un plan de planificare relevant cu scopul şi în context
cu cunoaşterea agentului
MsgBulkStart
Message
MsgBulkStop
Goals
BeliefSet
update
update
update
SelectGoal
View
NewGoal
CostOfNewGoal
FinalCostOfGoal
CostOfGoal
CostOfSelectedGoal
(PartialGoal)
uses
uses
usesSelectGoal
I
II
SelectedContractPlan
(CompletContract)
III
SelectContractByPriority
uses
uses
uses
SelectContract
update Communication
middleware
SetBulkFlag
AddMessage
ResetBulkFlag
SelectContract
Environment
BeliefSet
CostOfSelectedGoal
(CompletGoal)
usesSelectedGoalEvent
SelectedContractEvent
IV
Messages
BeliefSet
View
SelectGoalByPriority
SelectedContractPlan
(PartialContract)
Figura 11. Structura de proiectare şi implementare a unui agent holonic
Structura de proiectare şi implementare din Figura 11, reprezintă o schemă de referinţă
pentru mediile de dezvoltare de agenţi de tip BDI, şi diferă de alte variante prin vederea
agentului ca o entitate capabilă să comunice cu nivelele superior, inferior, şi cu entităţile de pe
acelaşi nivel. O implementare după schema prezentată s-a realizat în mediul de dezvoltare
JACK. Această schemă a fost utilizată cu succes în dezvoltarea soluţiilor pentru roboţi mobili
care prezentau nucleul decizional agenţi JACK (Pănescu et al., 2010; Pănescu et al., 2011).
Model de interfaţare cu partea fizică de execuţie
Prin modelul propus pentru agentificare (Pascal et al., 2009) ilustrat în Figura 12 se
urmăreşte adaptarea soluţiei oferite de producător echipamentelor fizice cu un format uşor
conectabil la o aplicaţie externă. Pentru agentificarea resurselor este necesară proiectarea şi
dezvoltarea unor aplicaţii driver care să permită controlul dispozitivului de execuţie. Faţă de
soluţiile clasice, în abordarea propusă se pun în evidenţă două canale de comunicare prin care
agentul comunică cu dispozitivul sau cu controlerul care comanda echipamentul (AEI – agent,
echipament interfaţă), şi prin care dispozitivul poate trimite evenimente către agent (EAI –
echipament, agent interfaţă). Al doilea canal este important şi necesar pentru procesarea în partea
de agent a evenimentelor neaşteptate. Agentul obţine în momentul apariţiei perturbaţiei
23
informaţiile despre posibilele cauze, iar pe baza lor agentul reacţionează într-un mod adecvat. În
(Pascal et al., 2009) se prezintă modul în care un robot industrial este cuplat cu un agent holonic
de tip JACK (Winikoff, 2005) prin mijloacele arhitecturii CORBA, ca o soluţie de comunicare
de nivel inferior. Această soluţie a fost adecvată şi în alte arii, precum în dezvoltarea de
arhitecturi de control de tip servoing (Burlacu et al., 2011),care se doreşte a fi integrată în
arhitectura HAPBA.
aplicaţie
driver EAIAEI
control eveniment
device
bloc
de control
componenta
de structură
IIOP over TCP/IP
Figura 12. Model agentificare dispozitiv fizic
3.9. Concluzie
În diverse cercetării asupra HMES, tehnicile bazate pe agenţi sunt considerate ca
principalele mijloace pentru soluţiile holonice; cu toate acestea, posibilităţile mecanismelor
tehnicilor de planificare din Inteligenţă Artificială nu sunt în întregime folosite şi adaptate la
cerinţele specifice holonilor, şi HAPBA este o încercare în această direcţie. Astfel,
funcţionalitatea holonilor se bazează pe câteva elemente de bază: aceştia funcţionează ca entităţi
autonome, deliberative şi cooperante, cu activităţile sociale care determină organizarea
grupurilor de holoni, numite holarhii, necesare în rezolvarea scopurilor de producţie.
Instanţierea pe care am propus-o pentru arhitectura de tip PROSA are ca elemente
distinctive rolul extins, activ, acordat holonilor de tip produs, aplicarea unor strategii specifice de
coordonare, incluzând şi o extindere şi adaptare a protocolului CNP la cerinţele operării
holonice, luarea în considerare a unei interacţiuni bine definite cu o componentă centralizată, de
tip holon staff şi folosirea proiectare şi implementare a unei platforme multiagent, care să
faciliteze mecanismul de raţionament BDI.
Aşa cum au fost prezentate elementele arhitecturii HAPBA în acest capitol, o continuare
posibilă ar fi aceea a unei dezvoltări ad-hoc, fără o susţinere teoretică adecvată. Însă, în
următorul capitol, se tratează în profunzime aspectele comportamentale ale arhitecturii,
dezvoltându-se elementele teoretice necesare.
24
Capitolul 4 Dezvoltarea unui model Petri pentru HAPBA
4.1. Introducere
În acest capitol se pune în evidenţă unele caracteristici arhitecturii HAPBA prin
mijloacele metodologiei de modelare şi analiză de tip reţea Petri (RP). Se dezvoltă pas cu pas,
pornind de la elementele teoretice legate de planificarea în spaţiul planurilor, de la schema de
interacţiune Contract Net şi de la mecanismul de raţionament BDI, un suport care permite
dezvoltarea logică şi clară a arhitecturii HAPBA.
4.2. Introducere în formalismul reţelelor Petri
În această secţiune sunt prezentate succint formalismele reţelelor Petri monocrome
(Murata, 1989; Păstrăvanu et al., 2002; Hrz şi Zhou, 2007), colorate (Jensen şi Kristensen, 2009)
şi ierarhice. Aşa cum sunt definite, reţelele Petri monocolore permit analiza unor procese cu un
grad de complexitate redus sau a principiului logic de funcţionare; în special se caută sau se
demonstrează existenţa unor efecte negative în sistem (de exemplu, deadlock, bucle, depăşirea
unor capacităţi, încărcarea unor procese etc.). Avantajul major în folosirea reţelelor Petri colorate
îl constituie posibilitatea modelării sistemelor complexe implicând un număr redus de tranziţii şi
poziţii. Un alt aspect favorabil este cel al combinării cu un limbaj de programare Standard ML
(Harper, 2005), care permite procesarea de informaţii pe lângă execuţia efectivă a tranziţiilor.
Această facilitate dă posibilitatea ca modelul obţinut să fie în realitate un prototip care poate fi
analizat atât calitativ, cât şi cantitativ prin mijloacele reţelelor Petri, în special prin studierea
grafului de accesibilitate. În ceea ce priveşte sistemele multiagent, reţelele Petri colorate permit
dezvoltarea bazelor de cunoştinţe ale agenţiilor şi dezvoltarea mecanismelor de interacţiune, în
care prin pasarea jetoanelor se transmite informaţii de la un agent la altul. Aceste aspecte se vor
ilustra pe larg în secţiune 4.12. În practică, complexitatea modelelor mari poate fi structurară pe
sub-modele. Acest avantaj permite dezvoltarea de modele la nivel de mecanisme, de entitate şi la
nivel de sistem prin utilizarea reţelelor Petri ierarhice.
4.3. Modele Petri pentru acţiune şi plan
O primă legătură între elementele planificării în spaţiul planurilor şi reprezentarea lor prin
formalismul reţelelor Petri se detaliază în continuare. Aceste aspecte necesită a fi evidenţiate
deoarece în literatură există o anumită ambiguitate între termenul de acţiune din teoria
planificării şi modelul Petri al acesteia. În (Leitao, 2004; Hsief, 2008; Hsief şi Chang, 2009;
Celaya et al., 2009), autorii afirmă că „o execuţie de tranziţie” este o acţiune (o activitate sau
operaţie) şi, deci, reprezentarea constituie o tranziţie Petri. Sub acest aspect, ambiguitatea există
la interpretarea poziţiilor din model Petri dezvoltat. Distribuţia jetoanelor descrie starea
sistemului prin descrierea stărilor acţiunilor, prin descrierea legăturilor dintre acţiuni şi/sau prin
descrierea combinată a stărilor acţiunilor şi relaţiile lor, aşa cum va rezulta din paragrafele
următoare.
Pentru o construcţie logică trebuie înţeles felul în care se reprezintă o acţiune, respectiv
un plan prin formalismul reţelelor Petri pornind de la planificarea în spaţiul planurilor. O acţiune
(operaţie) pentru un scop este caracterizată prin proprietăţile de relevanţa şi aplicabilitate. Efectul
sau efectele acţiunii dau relevanţa acţiunii, iar aplicabilitatea este dată în funcţie de satisfacerea
precondiţiilor definite.
25
Pornind de la elementele planificării în spaţiul planurilor se poate construi treptat legătura
între aceste elemente şi interpretarea lor în reţele Petri. Existenţa unei acţiuni aj este materializată
în formalismul reţelelor Petri printr-o tranziţie tj. Precondiţiile şi efectele acţiunii aj constituie
poziţiile de intrare, respectiv poziţiile de ieşire. Notam cu Pi-j o precondiţia i a acţiunii aj şi cu Pj-
k un efectul k al lui aj, unde k≠j, i≠j; în sens pur logic, un efect nu va satisface o precondiţie a
aceleaşi acţiuni. Reprezentarea grafică a acţiunii aj împreună cu precondiţiile şi efectele ei este
ilustrată în Figura 13(a) (notaţiile conţin în plus litera a de la acţiune, care uneori va fi omisă).
Totuşi modelul nu reflectă stare în care acţiunea se execută. Notând cu tj şi tj evenimentele care
încep şi termină acţiunea aj, şi prin Pj stare de execuţie, se propune modelul din Figura 13(b),
unde tranziţia tj a fost expandată astfel încât să includă starea de execuţie. Acum tranziţiile Petri
reprezintă în mod clar evenimente care notifică începerea sau terminarea acţiunilor, iar poziţiile
reflectă satisfacerea sau nu a unor precondiţii, stările de execuţie ale acţiunilor sau atingerea unor
efecte.
Figura 13. Model de reprezentare acţiune aj fără (a) şi cu stare (b)
Într-un plan rezultat în urma aplicării unei strategii de planificare, acţiunile sunt legate
prin constrângeri de ordonare sau prin legături cauzale. Legătura cauzală se formează atunci
când o precondiţie a unei acţiuni este satisfăcută de un efect al altei acţiuni; implicit se constituie
o constrângere de ordonare între respectivele două acţiuni . Ţinând cont de acest aspect, poziţia
notată cu Pi-j este o poziţie comună ce reflectă pentru ai un efect, respectiv pentru aj o
precondiţie. Un jeton în Pi-j indică starea de satisfacere a precondiţii i a acţiunii aj, prin efectul
acţiunii ai. În cazul constrângerii simple de ordonare se introduce o poziţie suplimentară legată
de tranziţiile acţiunilor. Poziţie de tip Pi-j prezintă o singură tranziţie de intrare şi una de ieşire.
Un caz particular al unui plan este acela în care planul este format dintr-o singură acţiune.
Un plan la fel ca o acţiune, se caracterizează prin proprietăţile de relevanţă şi
aplicabilitate. Relevanţa este dată de efectul sau efectele unui plan, iar aplicabilitatea este dată
prin satisfacerea precondiţiilor definite.
4.4. Model operaţional al agentul holonic
Un punct distinct în metodologia propusă se referă la dezvoltarea modelelor Petri valide
pentru trei tipuri de holoni – ordin, produs şi resursă. Aceste tipuri au implicit două faze de
operare pentru un agent holonic: planificarea şi execuţie. Faza de planificare începe din
momentul primirii unui scop şi se finalizează fie la găsirea unui plan care să soluţioneze scopul
sau la abandonare, când se consideră lipsa unei soluţii. Faza de execuţie începe din momentul
când un plan complet este validat în schema holonică şi priveşte efectuarea şi monitorizarea
setului de acţiuni stabilite. Cele două faze sunt întrerupte şi continuate atunci când planul ales
implică colaborarea cu alţi agenţi holonici. Un regim special îl au holonii staff pentru care se
considera modele Petri specifice.
Modelul proiectat ce descrie funcţionalitatea agentului holonic (Pănescu şi Pascal, 2010a;
Pănescu şi Pascal, 2011b) este reprezentat în Figura 14 şi reflectă activităţile de baza ale
agentului: planificare în partea stângă şi execuţie în partea dreaptă. Prin urmare, prezenţa unui
26
jeton în poziţia P1 indica implicarea agentului într-o activitate de planificare, respectiv realizarea
de către agent a unei activităţi deliberative în partea de execuţie, când un jeton este prezent în
poziţia P2. Pe lângă aceste activităţi, agentul holonic poate fi într-o state de aşteptare notată prin
P0; aceasta indică disponibilitatea pentru o acţiune deliberativă. Prin tranziţii Petri sunt indicate
evenimente care încep, întrerup, continuă şi termină fazele de planificare şi execuţie, în
conformitate cu protocolul de coordonare Contract Net. Aceste tranziţii sunt prezentate succint în
0. Pentru un scop secvenţa de tranziţii executate în planificare este dată de τ1 = t1{t2 t3}t4 şi
continuată în execuţie, dacă planificarea a fost cu succes, fie de secvenţa τ2 = t5 t6 dacă oferta a
fost refuzată, sau de secvenţa τ3 = t5 t8 t7 {t8 t7} t6. Pentru mai multe scopuri secvenţele se pot
întrepătrunde şi putem anticipa încă de pe acum necesitatea unor tranziţii prioritare pe care le
putem clasifica în două clase: evenimente referitoare la scopuri/contracte interne, respectiv
externe. Prioritare sunt acelea generate intern, iar în aceeaşi clasă prioritatea este stabilită în
următoarea ordine: reacţia la feedback (t7), contracte (t5), oferte (t3) şi mai puţin prioritară reacţia
la scopuri noi (t1). La baza ordonării stau următoare aspecte. Apariţia unei disfuncţionalitate
trebuie tratată prima, dealocarea resurselor la primirea mesajului de neacordare contract este a
doua prioritate, iar în partea de planificare, continuare planificării este prioritară. Între două
evenimente de acelaşi tip pentru scopuri diferite prioritar este evenimentul primului scop sosit
sau considerat.
Figura 14. Model Petri primar pentru agent holonic
În timpul procesului de planificare pot apărea alte acţiuni legate de schema de contractare
şi care nu întrerup procesul de planificarea; de exemplu, acţiuni de trimitere mesaje de refuzare
oferte. Aceste acţiuni sunt prinse în tranziţiile care întrerup sau termină planificarea, adică t2 şi t4,
şi locul lor este dat de strategia de planificare aplicată. Abandonarea planificării este indicată de
asemenea de tranziţia t4 şi are efect de propunere a unei oferte negative.
Tabelul 3. Descriere tranziţii pentru modelul primar al agentului holonic
Tranziţie Eveniment Moment Prioritate
t1 începere planificare primire scop 4
t2 întrerupere planificare propunere sub-scopuri -
t3 continuare planificare primire oferte 3
t4 terminare planificare propunere ofertă/contract intern -
t5 începere execuţie primire contract 2
t7 continuare execuţie primire feedback-uri 1
t8 întrerupere execuţie trimitere comenzi/contracte -
t6 terminare execuţie trimitere feedback/scopuri interne -
27
În concluzie, modelul propus în Figura 14 reflectă două aspecte importante: evidenţierea
stărilor de planificare, execuţie şi de aşteptate în care agentul holonic poate fi, şi indicarea
evenimentelor care încep, întrerup, continuă şi termină fazele de planificare şi execuţie. În plus,
modelul va sta la baza modelelor de detaliu pentru planificare, execuţie şi respect pentru
mecanismul de raţionament de tip BDI.
4.5. Formalizarea execuţiei
Noţiunea de acţiune din metodologia de planificare în spaţiul planurilor este considerată
prin Definiția 1 în formalizarea execuţiei (Pănescu şi Pascal, 2011a):
Definiția 1. O acţiune de execuţie aj a unui holon este o operaţie pentru componenta sa
fizică sau pentru alt holon, exceptând acţiunile fictive a0 şi a.
Acţiunile fictive a0 şi a simbolizează în spaţiul planurilor starea iniţială, respectiv starea
finală (starea scop) la care se ajunge din starea iniţială după aplicarea unui set de acţiuni.
Structura de acţiuni între a0 şi a constituie un plan complet pentru faza offline (presupune
precizarea tuturor acţiunilor), cu acţiuni parţial ordonate şi variabile neasignate, pentru care s-a
aplicat principiul celei mai mici angajări (în engleză, least commitment principle). Planul poate fi
exprimat cu ajutorul unor reguli derivate din notaţia BNF (în engleză, Backus-Naur Form) prin
Definiția 2:
Definiția 2. Un plan de execuţie al unui holon se defineşte prin:
0:: " " _ " "a part a (4.1)
_ :: | "(" _ ")"| " " _ |
" " _ | _ " " |_ " "
j j
j j
j
part a part a parta part part a
part a
(4.2)
unde a0, a şi aj au semnificaţia din Definiția 1, în timp ce simbolurile ≺ şi ≼
reprezintă operatori de ordonare a acţiunilor.
Operatorul de ordonare ≺ restricţionează începerea acţiunilor din partea dreaptă după ce
acţiunile din partea stângă sunt finalizate. Operatorul ≼ indică faptul că nu există nicio restricţie
de ordonare între două acţiuni sau părţi din acţiuni. Acest operator este utilizat explicit în scopul
evidenţierii grupurilor de acţiuni sau seturi de acţiuni între care nu sunt stabilite constrângeri.
Totuşi, planurile complexe nu pot fi exprimate numai prin operatorii de ordonare şi atunci este
necesară utilizarea parantezelor pentru delimitarea unui set de acţiuni pentru care se aplică un
operator. Simbolul „|” din relaţia (4.2) delimitează posibilităţile de formare a unui plan parţial
prin reflectarea relaţiile sub-planului cu celelalte componente ale planului (definiţia este de tip
recursiv).
În abordarea considerată, acţiunile fictive ale unui plan de execuţie sunt utilizate de
mecanismul de raţionare BDI la selectarea intenţiei, unde a priveşte condiţia de relevanţă, în
timp ce a0 reprezintă condiţia de filtrare de context (vezi (4.1)). Această posibilitate este dată
prin înţelegerea că un plan este aplicabil dacă şi numai dacă este relevant scopului şi
precondiţiile iniţiale sunt satisfăcute. În abordarea propusă, din punct de vedere al planificării,
planul nu este obţinut pornind de la zero, ci fiecare agent holonic este înzestrat cu o bibliotecă de
planuri în funcţie de rolul şi capabilităţile holonului. Pentru fiecare plan din bibliotecă acţiunea
28
a va indica relevanţa faţă de un scop, iar acţiunea a0 va indica condiţiile necesare aplicării
planului.
În expresia (4.3) (vezi Figura 15), parantezele nu sunt necesare întrucât se subînţelege
despre acţiunile a2 şi a3 că sunt ordonate după acţiunea a1 şi ordonează acţiunea a4.
3 0 1 2 3 4e a a a a a a
(4.3)
Utilizarea planurilor parţial ordonate flexibilizează posibilităţile de operare ale unui
sistem holonic. Lipsa ordonării între acţiunile a2 şi a3 permite acestora o execuţie simultană de
către holoni diferiţi sau una secvenţială a unui singur holon, unde este posibilă alegerea ordinii
de execuţie.
Figura 15. Plan simplu de execuţie ordonat parţial
Conform cu Definiția 1 planurile de execuţie conţin acţiuni pentru alţi holoni şi/sau
pentru componenta fizică de execuţie. Implicarea agentului holonic în aceste planuri va fi în
continuare ilustrată prin considerarea activităţilor adiţionale, deliberative, de coordonare,
sincronizare sau de analiză, necesare acţiunilor de execuţie. Pentru planurile de execuţie aceste
activităţi adiţionale sunt cele de acordare contracte sau trimitere comenzi către dispozitivul de
execuţie, de analiză feedback, de generare feedback la terminarea planului de execuţie sau
emitere de scopuri interne la apariţia unor factori perturbatori. Diferenţa între acţiunile propriu-
zise (acţiuni definite în planul de execuţie) şi cele adiţionale constă în: prima categorie preocupă
activităţi în ceea ce priveşte mediul de fabricaţie, unde actorii sunt alţi holoni sau dispozitivele
fizice de execuţie, în timp ce a doua categorie cuprinde toate operaţiile interne, deliberative ale
agentului holonic. Conform cu afirmaţiile anterioare, acţiunile adiţionale se definesc prin
(Pănescu şi Pascal, 2011a):
Definiția 3. O acţiune adiţională a unui holon este o activitate efectuată de agentul holonic la
rezolvarea unui task deliberativ, de coordonare sau comunicare.
Un plan de execuţie completat cu acţiunile adiţionale formează un flux de execuţie (în
engleză, workflow). Termenul de flux de execuţie este preferat întrucât planul obţinut în urma
completării cuprinde atât acţiuni ale agentului holonic cât şi ale altor entităţi, care împreună
conduc la soluţionarea scopului.
Un mod sistematic de construcţie a unui flux de execuţie constă în considerarea a două
acţiuni adiţionale adiacente (aj’ şi aj”) pentru fiecare acţiune de execuţie: o acţiune ca
precondiţie aj’ care conţine toate activităţile necesare agentului holonic înaintea începerii acţiunii
propriu-zise aj, şi o acţiune post-condiţie aj” constând în toate activităţile necesare agentului
holonic după terminarea acţiunii aj (vezi Figura 16). O detaliere a unei acţiuni adiţionale permite
evidenţierea în mod explicit a activităţilor ce compun acţiunea. Două acţiuni adiţionale
neseparate printr-o acţiune propriu-zisă (de exemplu, o post-condiţie a unei acţiuni şi o
precondiţie a altei acţiuni) pot fi considerate într-un flux ca o singură acţiune adiţională, deoarece
acestea sunt efectuate de aceeaşi entitate – agentul holonic. Luând în considerare acţiunile
29
adiţionale şi noţiunea de plan de execuţie dată de Definiția 2, fluxul de execuţie este materializat
prin Definiția 4 (Pănescu şi Pascal, 2011a).
Figura 16. Acţiuni adiţionale pentru o acţiune de execuţie
Definiția 4. Un flux de execuţie se obţine dintr-un plan de execuţie prin aplicarea
următoarelor reguli:
Regula 1. Toate acţiunile unui plan de execuţie apar în flux împreună cu acţiunile lor
adiţionale, ca precondiţie şi post-condiţie, exceptând acţiunile fictive.
Regula 2. Toate acţiunile planului de execuţie care sunt ordonate parţial (acele acţiuni
conectate prin operatorul ≼) şi preced aceeaşi acţiune, considerând şi acţiunea fictivă
a∞, vor avea acţiunile lor adiţionale ca post-condiţie grupate într-o singura acţiune
adiţională ca post-condiţie.
Regula 3. Toate acţiunile planului de execuţie care sunt ordonate parţial şi succed
aceeaşi acţiune, considerând şi acţiunea fictivă a0, vor avea acţiunile lor adiţionale ca
precondiţie grupate într-o singură acţiune adiţională ca precondiţie.
Regula 4. Toate acţiunile adiţionale adiacente de forma post-condiţie şi precondiţie
vor fi grupate ca acţiuni adiţionale.
În acest mod fluxul de execuţie include toate operaţiile necesare rezolvării unui scop.
Explicaţia pentru regulile anterioare priveşte redundanţa tuturor acţiunilor pre şi post condiţie
considerate. În consecinţă, toate activităţile de coordonare şi deliberare ale agentului holonic, fie
de finalizare a unei acţiuni de execuţie ori de începere a următoarei acţiuni de execuţie sunt
grupate într-o singură activitate a agentului holonic. Aplicarea regulilor 1 - 4 asupra planurilor de
execuţie din (4.3), reprezentate în Figura 15, a condus la obţinerea fluxurilor de execuţie din
Figura 17, având expresiile din (4.4).
3 0 1 1 1 2,3 2 3 2,3 4 4 4we a a a a a a a a a a
(4.4)
Figura 17. Flux de execuţie simplu
4.6. Model Petri pentru flux de execuţie
Continuând formalizarea execuţiei cu aspecte de modelare, un flux de execuţie poate fi
modelat printr-o reţea Petri, unde o poziţie reprezintă starea unei acţiunii – prezenţa unui jeton
indică execuţia acţiunii, iar o tranziţie înseamnă un eveniment spre/din mediul holonic. Cum
schema holonică este ghidată de evenimente, o tranziţie poate grupa o serie de evenimente pentru
reducerea gradului de detaliere a modelului (vezi secţiunea 3.2). Astfel, unde este posibil, o
tranziţie defineşte terminarea unei acţiuni împreună cu începerea următoarei acţiuni. În acest fel
se grupează evenimentul de terminare acţiune cu cel de începere al altei acţiuni. Vom numi în
30
primă fază modelul primar al unui flux de execuţie, modelul Petri obţinut din fluxul de execuţie
fără să considerăm actorii (resursele) care vor fi implicaţi în execuţia acţiunilor.
Definiția 5. Un model primar al unui flux de execuţie este reprezentat printr-o reţea Petri
de tip graf marcat, fără marcaj iniţial, în care sunt considerate toate acţiunile
fluxului.
Modelul primar al fluxului de execuţie din Figura 17 este transpus în model Petri
corespunzător în Figura 18 şi este strâns legat de modelul de bază al agentului holonic (vezi
Figura 14). Poziţiile P2(i) sunt stările acţiunilor adiţionale la care agentul holonic se implică şi
toate aceste poziţii reflectă poziţia P2 din modelul de bază. Stările sunt indexate întrucât definesc
acţiuni deliberative distincte într-un flux, iar numărul lor indică de câte ori agentul holonic este
implicat în flux. Stările acţiunilor de execuţie sunt notate prin Paj. Evenimentele care indică
începerea, terminarea sau terminarea-începerea (prin grupare) acţiunilor sunt definite prin
tranziţii, care sunt în relaţie cu protocolul de coordonare conform explicaţiilor date la modelul de
bază al agentului holonic. Un flux de execuţie este început în urma evenimentului de acordare
contract (marcat prin t5) şi este terminat după execuţia tranziţiei t6. Acţiunea fictivă a0 din fluxul
de execuţie reprezintă condiţia de execuţie a tranziţiei t5, indicând necesitatea unor premise
pentru începerea unui flux de execuţie. La acţiunea a se ajunge în urma execuţie tranziţiei t6,
indicând finalizarea cu succes a fluxului de execuţie. Acţiunile fictive pot fi reprezentate prin
poziţii corespunzătoare de intrare ale tranziţiei t5, respective de ieşire ale tranziţiei t6. Modelul
rezultat este unul de tip graf marcat, corect format, fără marcaj iniţial.
Figura 18. Model primar al fluxului de execuţie din Figura 17
Următorul pas în completarea modelul primar constă în specificarea resurselor (actorilor)
care soluţionează acţiunile. Modelul primar este completat cu poziţii suplimentare care vor
marca disponibilitatea sau nu a actorilor. În cazul acţiunilor adiţionale, agentul holonic reprezintă
resursa care se implică în acestea; astfel, poziţia notată prin P0 – indicând disponibilitatea
agentului holonic (vezi Figura 14) – este conectată la tranziţiile de intrare şi de ieşire ale
poziţiilor acţiunilor adiţionale (P2(i)) în modul firesc de alocare şi respectiv dealocare a resursei.
Pentru fiecare acţiune propriu-zisă Paj, o poziţie PRaj este adăugată şi conectată ca poziţie de
intrare pentru tranziţia de intrare corespunzătoare poziţiei Paj. Un jeton în poziţia PRaj va marca
existenţa unui contractor alocat pentru acţiunea aferentă. Sarcina de alocare revine mecanismului
de planificare, al cărui model va fi prezentat în secţiune 4.8. Eliberarea actorului după finalizarea
acţiunii de execuţie nu va fi ilustrată (arc de la tranziţia de ieşire a poziţiei Paj la PRaj) din simplul
motiv că ar conduce la înţelegerea că din fluxul de execuţie este posibil alocarea resurselor. Un
caz special există şi se referă la holonul resursă unde un actor este propriul dispozitiv fizic de
execuţie. Eliberarea resursei în acest caz necesită a fi prinsă în model şi dacă există mai multe
acţiuni care se rezolvă prin resursa proprie, atunci acestea se reprezintă printr-o singură poziţie.
Marcajul iniţial înainte de planificare nu va conţine jetoane pentru poziţiile PRaj şi va conţine
31
jetoane după ce procesul de planificare s-a terminat cu succes. Rezultatul completării modelului
primar din Figura 18 este ilustrat în Figura 19 şi definit în (Pănescu şi Pascal, 2011a) prin:
Definiția 6. Un model final al unui flux de execuţie este reprezentat prin o reţea Petri
obţinută din modelul primar, completată corespunzător în aşa fel încât să reflecte
condiţiile de necesitate a resurselor.
Modelul primar, aşa cum este ilustrat în Figura 18, este completat cu un număr de poziţii
egal cu numărul de acţiuni de execuţie, plus o poziţie pentru agentul holonic. Arcele care
modelează angajarea şi eliberarea agentului holonic pentru acţiunile adiţionale şi cele care indică
condiţiile de disponibilitate actori pentru acţiunile de execuţie sunt de asemenea considerate. În
cazul particular când o acţiune sau mai multe vor fi executate de propriul dispozitiv fizic (cazul
unui holon resursă), poziţiile acestora vor primi jetoane de la procesul de planificare, fără
aplicarea procesului de contractare.
Figura 19. Model final al fluxului de execuţie din Figura 18
Fluxul de execuţie este complet alocat dacă şi numai dacă toate poziţiile PRaj ale
modelului final au câte un jeton. Modelul prezentat nu cuprinde cazul când o entitate alocată
unei acţiuni eşuează în execuţie. Agentul holonic, aşa cum s-a prezentat în această secţiune, este
pentru fluxurile de execuţie o resursă partajată secvenţial şi formează o excludere mutuală
secvenţial. împreună cu perechile de tranziţii de începere şi terminare ale acţiunilor adiţionale.
4.7. Formalizarea planificării
Un plan de execuţie conform cu Definiția 2 apare în biblioteca de planuri ca o structură
de acţiuni parţial ordonate, cu variabile neasignate, la care s-a aplicat principiul celei mai mici
angajări în legătură cu constrângerile impuse. Ultima parte din procesul de planificare este
efectuată de agentul holonic şi implică două etape: (1) căutarea unui plan aplicabil scopului
primit prin încercarea de legare a parametrilor din scop cu variabile din plan şi (2) asignarea
variabilelor – etapă cunoscută în literatură sub numele de proces de alocare resurse. Se impune
ca rezultatul planificării să constituie o soluţie optimă, fie prin utilizarea propriei resurse fizice
(cazul holonilor resursă), fie apelând la colaborare prin contractarea de sub-scopuri. În această
secţiune se consideră cazul contractării, în care accentul este pus în procesul de planificare pe
găsirea şi selectarea contractorilor. Rezultatul planificării va fi un plan de execuţie validat şi cu
toate acţiunile alocate. De notat este faptul că planificarea nu implică modificări directe în
mediul de fabricaţie, ci poate căuta şi aloca actori (contractori).
Vom considera o acţiune de planificare ap
j ca fiind o activitate de planificare pe care o
exercită fiecare posibil contractor în vederea implicării sau nu în soluţionarea acţiunii de execuţie
aj. Formularea acţiunii de planificare este similară cu aceea a acţiunii de execuţie întrucât alţi
holoni o execută. În execuţia acţiunii de planificare, o parte din contractori, prin propriul lor
32
proces de planificare, se alocă pentru acţiunea de execuţie. Pentru manager, rezultatul unei astfel
de acţiunii de planificare este alocarea individuală a contractorilor. Atunci când pentru o acţiune
de execuţie s-au alocat mai mulţi contractori, managerul va selecta un singur contactor şi va
declanşa evenimente privind dealocarea pentru restul. Prin cele enunţate, o acţiune de planificare
are Definiția 7.
Definiția 7. O acţiune de planificare ap
j este o activitate de planificare pe care o exercită
fiecare posibil contractor în vederea implicării sau nu în soluţionarea acţiunii de
execuţie aj.
Considerând pentru fiecare acţiune de execuţie o acţiune de planificare, planul rezultat
trebuie transformat într-un plan complet ordonat, unde există posibilitatea ca două sau mai multe
acţiuni să fie comasate. Prin comasare se înţelege aici anunţarea simultană în sistem a scopurilor
pentru acţiuni, iar procesul de planificare este continuat după primirea întregului set de oferte. În
acest fel se simplifică şi se generalizează planul de planificare prin propunerea simultană de
scopuri. Un plan de planificare este definit prin:
Definiția 8. Un plan de planificare p se defineşte prin relaţia (4.5), unde Si , i = 1…p,
sunt subseturi disjuncte de acţiuni ordonate complet pentru care se anunţă scopuri,
şi reflectă procesele de planificare ale contractorilor pentru planul de
execuţie e aferent.
0 1... ...p p p pS Si Spa a a a a (4.5)
În continuare, se consideră ca suport pentru exemplificare planul de execuţie dat de
relaţia (4.3) şi ilustrat în Figura 15. Cazul avut în vedere este cu planul vând toate cele patru
acţiuni pentru contractare. În (4.6), (4.7) şi (4.8) sunt prezentate trei variante de planuri de
planificare, în care se pune în evidenţă posibilitatea ca două sau mai multe acţiuni să fie
comasate (grupate). Planul din (4.8) este un caz extrem prin faptul că se anunţă în sistem
simultan scopuri pentru toate acţiunile din planul de execuţie. Această variantă este des întâlnită
în schemele de contractare şi poate fi aplicată doar atunci când nu există restricţii între acţiuni.
Spre exemplu, variabile de legare impun restricţii în sensul că oferta unui contractor va influenţa
modul de formulare scop pentru o acţiune care succede. În acest sens se propune Teorema 1.
p p p p p
a a a a a a03a 1 2 3 4
(4.6)
p p p p
a a a a a0 1 2,3 43b
(4.7)
p p
a a a03c 1,2,3,4
(4.8)
Teorema 1. Dăcă între două acţiuni nu există variabile de legare, atunci ele pot fi anunţate
simultan (demonstrația teoremei este dată în teza de doctorat).
Implicarea agentului holonic în planul de planificare se indică prin considerarea
acţiunilor adiţionale ( pSia ) înainte şi ( p
Sia ) după fiecare set de acţiuni pSia . Aceste acţiuni
adiţionale grupează toate activităţile deliberative înaintea propunerii setului de scopuri şi,
33
respectiv, acele activităţi ce apar după primirea ofertelor. Planul obţinut în urma considerării
acţiunilor adiţionale formează un flux de planificare, în care două acţiuni adiţionale adiacente
sunt grupate sub o singură acţiune.
Definiția 9. Un flux de planificare al unui plan de execuţie este o secvenţă de acţiuni
total ordonată, sub forma:
0 1 1 1 2 ( 1) ( 1).... ...wp p p p p p p pS S S S Si SpS i Si Si S ia a a a a a a a a (4.9)
unde ( 1)p
Si S ia este o acţiune adiacentă formată prin gruparea acţiunilor p
Sia şi ( 1)p
S ia .
Fluxul de planificare pentru planul din (4.7) este dat în (4.10) şi reprezentat în Figura 20,
unde 1pa este acţiunea adiţională anunţare scop pentru acţiune 1a , 1
pa reprezintă acţiunile de
planificare ale altor holoni, 1-2,3pa este acţiunea adiţională de analizare oferte şi anunţate scopuri
pentru acţiunile a2 şi a3. Restul acţiunilor din flux se explică similar.
wp p p pa a a a a a a a a0 1 1 2,3 2,3 4 41 2,3 43b
(4.10)
Figura 20. Flux de planificare al unui plan de execuţie
În planul de planificare, acţiunea fictivă a∞ va indica stare în care un plan de execuţie este
complet definit şi pregătit pentru execuţie, iar a0 va indica starea iniţială necesară pentru
considerarea planului de execuţie. Acţiunea a∞ este atinsă atunci când fluxul de planificare
reuşeşte să valideze un flux de execuţie corespunzător, ceea ce înseamnă alocarea resurselor,
considerând constrângerile aferente pentru toate acţiunile de execuţie din plan.
Aşa cum se prezintă fluxul de execuţie, acestea ar trebui întotdeauna să conducă către o
soluţie. În realitate, un flux de execuţie poate fi abandonat din lipsă de contractori pentru o
acţiune din plan. În cadrul execuţiei acţiunilor adiţionale, fluxul de planificare se poate abandona
şi, atunci, o acţiune adiţională ad trebuie să urmeze. La execuţia lui ad se dealocă variabile
asignate, în special contractorii selectaţi, iar apoi se poate considera un alt flux de planificare sau
refuzarea în implicarea rezolvării scopului. Acţiunea ad nu a fost reprezentată explicit într-un
flux de planificare, dar aceasta întotdeauna există.
Alegerea unui plan de planificare cu acţiuni complet ordonate are la bază trei motive:(1)
un proces de planificare este de obicei unul secvenţial, (2) frecvenţa de solicitare a agentului
holonic într-un task deliberativ este mai mare într-un flux de planificare decât într-un flux de
execuţie, (3) un flux de planificare foarte reactiv la ofertele primite este greu de realizat şi
studiat.
4.8. Model Petri pentru flux de planificare
Modelul Petri al unui flux de planificare se obţine din fluxul corespunzător prin
abstractizarea stării de execuţie a fiecărei acţiuni printr-o poziţie. Se notează prin P1(j) starea unei
acţiuni adiţională, respectiv prin Pap
j starea unei acţiuni de planificare. Evenimentele care indică
începerea şi terminarea acţiunilor sunt reprezentate prin tranziţii. Unele dintre tranziţii reprezintă
atât terminarea unui set se acţiuni cât şi începerea altui set de acţiuni (vezi 4.3). Aceste
evenimente sunt strâns legate de evenimentele prezentate la modelul primar al agentului holonic
34
(vezi Figura 14), unde se pune în evidenţă legătura cu protocolul Contract Net; astfel, terminarea
unei acţiuni adiţională în planificare indică întreruperea sau terminarea fluxului, sau începerea
acţiunii va reprezenta începerea sau continuarea fluxului. În acest mod, modelul primar pentru
fluxul de planificare din (4.10) (vezi Figura 20) este prezentat în Figura 21 cu linie continuă. Se
ajunge la modelul final prin indicarea stărilor actorilor pentru acţiunile adiţionale, în acest caz –
agentul holonic (P0). Stările actorilor pentru acţiunile de planificare nu vor apărea în model
deoarece existenţa unui contractor nu garantează şi implicarea acestuia în soluţionarea acţiunii de
execuţie. Modelul final este reţeaua Petri completă din Figura 21, definită prin (Pănescu şi
Pascal, 2011a):
Figura 21. Model final al fluxului de planificare din Figura 20
Definiția 10. Un model final al unui flux de planificare este obţinut prin cuplarea
modelului său primar cu o poziţie corespunzătoare disponibilităţii agentului holonic
şi arce care conectează această poziţie cu tranziţiile de intrare şi ieşire, în
conformitate cu angajamentul agentului în procesul de planificare.
4.9. Conexiunile dintre planificare şi execuţie
Conexiunile dintre planificare şi execuţie apare la formarea agentului holonic şi la
operarea acestuia.
Formarea agentului holonic
Procesul de proiectare începe prin stabilirea planurilor de execuţie care compun
biblioteca de planuri ale agentului holonic. Fiecare plan este completat corespunzător la
obţinerea fluxului de execuţie, unde acest flux are un model echivalent dat printr-o reţele Petri
(vezi Figura 22). De asemenea, planul de execuţie poate fi transformat într-un flux de planificare,
cu un model Petri corespunzător.
Figura 22. Schemă de formare fluxuri de execuţi şi planificare
Operarea agentului holonic
A doua conexiune între planificare şi execuţie apare în timpul operării agentului holonic.
De această dată, procesul de planificare are ca obiectiv de a validare şi completa cu elemente
necesare un flux de execuţie. Când scopul este îndeplinit, fluxul de execuţie are toate variabilele
asignate, ceea ce implică stabilirea actorilor pentru acţiunile de execuţie în relaţie cu
35
constrângerile existente. În Figura 23 se prezintă sub formă de model Petri conexiunea pentru
planul de execuţie din (4.3) (vezi Figura 17), care cuprinde patru acţiuni de execuţie ce trebuie
alocate. După cum se observă, modelul are în partea superioară pentru fluxul de planificare şi în
partea inferioară modelul fluxului execuţiei. Reţeaua a fost completată cu elemente care pun în
evidenţă: felul în vare fluxul poate fi abandonat şi, în cazul abandonării, un mecanism pentru
dealocarea actorilor alocaţi până atunci.
Modelul propus scoate în evidentă două aspecte. Când procesul este abandonat după
primirea ofertelor la primul set de acţiuni propuse, atunci se poate sări peste activitatea de
dealocare (tranziţia t4a(1) este conectată direct la poziţia PDE). Al doilea aspect constă în lipsa
dealocării pentru ultimul set de acţiuni. Când pentru ultimul set o acţiune nu are contractor,
atunci pentru restul de acţiuni din set nu se mai asignează contractori.
P2(1) P2(2) P2(3) P2(4)Pa1 Pa2
Pa3
Pa4
PRa2
PRa3
PRa4PRa1
t8(3)t8(2)t8(1)t7(3)t7(2)t7(1)
t5t6
PP
PP
PDE
tDRa3
tdRa1
tdRa2
t 4a(1)
t 4a(2) t 4a(3)
t4a
1(1)P 1(2)P 1(3)P 1(4)Pp1aP p
2,3aP p4aP1t 3(1)t2(1)t 2(3)t2(2)t 3(2)t 3(3)t 4t
Pad
t de
Figura 23. Exemplu de cuplare planificare-execuţie
În concluzie, modelele prezentate anterior definesc şi modelează comportamentul
agentului holonic – de planificare şi execuţie. Modelul fluxului de execuţie poate fi analizat după
completarea acestuia cu câteva elemente. Acestea apar în Figura 24 cu linie întreruptă, unde:
poziţia Pp are aceeaşi semnificaţie cu cea din Figura 23 şi are tranziţie de intrare pe t6 pentru a
putea analiza repetabilitatea fluxului. Poziţiile resurselor (PRaj) sunt completate cu tranziţii de
intrare pentru a indica eliberarea resurselor după utilizarea lor în flux. Situaţia ce poate fi
analizată este atunci când se consideră procesul de planificare terminat cu succes, ceea ce
înseamnă ca starea iniţială să cuprindă jetoane în poziţiile PRaj, Pp şi P0.
Figura 24. Model Petri folosit la analizarea corectitudini unui flux de execuţie
36
Cu ajutorul aplicaţiei CPN Tool (CPN Tools, 2011) s-a obţinut graful de accesibilitate al
modelului din Figura 24, arătând următoarele rezultate: reţeaua Petri este viabilă şi mărginită, şi
marcajul reprezentând fluxul terminat cu succes este atins. Dacă starea iniţială este schimbată,
spre exemplu se consideră două jetoane în poziţia PP, atunci aceeaşi procedură de analiză indică
un blocaj (un deadlock) ce poate apărea (trei marcaje deadlock s-au găsit). Din fericire, o astfel
de situaţie nu este posibilă în metodologia dezvoltată: dacă două jetoane sunt în poziţia PP atunci
înseamnă că procesul de planificare validează fluxul de execuţie pentru două scopuri şi are efect
asignarea unui număr egal de resurse pentru fiecare acţiune. Aceasta semnifică faptul că modelul
de reţea Petri va avea două jetoane în fiecare poziţie a resurselor şi astfel deadlock-ul este
eliminat. Alte rezultate au fost obţinute şi acestea sunt prezentate în capitolul referitor la
experimente.
4.10. Model al mecanismului de raţionare BDI
Din punct de vedere al procesului de efectuare a raţionamentelor Belief Desire Intention
(BDI) al agentului, modelul aferent va indica principalele activităţi: selectarea şi alocarea
planurilor relevate unui scop (această activitate este notată prin A), selectarea unui plan relevant
în vederea execuţiei (notată prin S), deselectarea planurilor relevante (notată prin D) după
execuţia cu succes a unui plan relevant, şi activitatea de finalizare proces (notată prin E). În
modelul propus (vezi Figura 25), activităţile sunt modelate prin poziţii care vor arăta starea
acestora, iar evenimentele care încep sau termină o activitate sunt reprezentate prin tranziţii.
Modelul este conectat la trei planuri (fluxuri) de planificare prin care se indică posibilitatea de
expandare a modelului la n-planuri (n>1). Exceptând ultimul planul n, fluxurile pot fi
abandonate.
Figura 25. Model mecanism BDI
4.11. Extinderea modelului operaţional cu implicarea holonului staff
Modelul operaţional al agentului holonic este extins prin considerarea interacţiunii cu
holonul staff. Interacţiunea apare atunci când planul de execuţie ales în soluţionarea scopului va
implica o colaborare. Astfel în Figura 26, modelul operaţional apare extins prin considerarea a
două tranziţii, t9 şi t10, prin care procesul de planificare este întrerupt, se aşteaptă răspuns de la
holonul staff, respectiv procesul este reluat când răspunsul este primite de la holonul staff.
37
Figura 26. Model operaţional extins al agentului holonic
Modelul fluxul de planificare ilustrat în Figura 21 este completat şi prezentat în Figura 27,
unde s-au inclus două stări, P1(5) şi Pas. Prima stare este o acţiunea deliberativă în care agentul
holonic desfăşoară activităţi în vederea anunţării intenţiei sale de planificare către holonul staff.
A doua stare indică activitatea holonii staff în vederea acordării lista cu posibili contractori
pentru planul primit. Se poate observa că în această stare, agentul holonic intră starea de
aşteptare. Acest model de flux este în continuare considerat.
t10
PRa2PRa1
1(1)P 1(2)Pp1aP p
2,3aP3(1)t2(1)t 2(2)t 1(3)P 2(3)t3(2)t
4a(1)t4a(4)t 4a(2)t
PRa3
1(5)P1t 9t asP
0P
Figura 27. Model flux de planificare considerând holonul staff
4.12. Extinderea la modele Petri colorate
Modelul schemei holonice ce a fost folosită în experimente este ilustrat în Figura 28;
acesta conţine entităţi diferite care sunt cuplate prin poziţiile de intrare (Ii) şi de ieşire (Oi) la un
model al reţelei de comunicare. Acest model transferă jetoane (mesaje) de la poziţiile de ieşire
ale entităţilor la poziţiile de intrare ale altor entităţi. Pentru a face posibilă analiza unor
experimente este necesar ca anumite modele să fie reduse; de exemplu, la analiza sistemului
holonic propus, în scopul reducerii spaţiul stărilor, toţi holonii resursă sunt abstractizaţi la o
singură tranziţie, care modelează comportamentul lor (vezi Figura 28). Ca urmare, a fost posibil
de simulat şi analizat comportamentul întregului sistem holonic sau anumite părţi din acesta.
Două aspecte sunt considerate pentru analiză pe baza grafului de accesibilitate: proprietăţile de
viabilitate şi mărginire, şi reacţia sistemului la evenimente specifice. Ultimul aspect presupune
examinarea conţinutului din jetoane, ceea ce permite distingerea rezultatelor date de sistemul
holonic.
38
Figura 28. Model al structurii holonice - nivel superior
4.13. Concluzii
Formalismul dezvoltat pentru execuţie şi planificare, plecând de la teoria planificării în
spaţiul planurilor, permite reprezentarea fluxurilor de planificare şi execuţie prin modelele de tip
reţea Petri. Această reprezentare este consecventă cu legătura dezvoltată între elementele
planificării şi reprezentarea lor prin reţele Petri, şi cu modelul operaţional al agentului holonic.
Legătura cu un model al mecanismului de raţionament BDI completează modelul unui agent
holonic. Se obţine astfel un model care înglobează toate aspectele operării agentului holonic.
Transpunerea modelelor în reţele Petri colorate şi ierarhice a condus la obţinerea unui model
complex pentru structurile holonice, care este apropiat de un prototip software. Formalismul
astfel dezvoltat poate ghida proiectarea şi implementarea unui HMES, respectiv poate fi folosit
pentru analiza performanţelor, aşa cum se va arata şi în capitolele următoare.
39
Capitolul 5 Adaptabilitatea în HAPBA
5.1. Introducere
Adaptabilitatea pentru fabricaţie, se referă la modul de obţinere a unui proces de
manufacturare flexibil şi la o reducere a timpului de reconfigurare a resurselor pentru adaptarea
la un nou tip de producţie. În HAPBA adaptabilitatea rezultă din stabilirea dinamică a unei
ierarhii temporare (holarhie), din mecanismul BDI, din utilizarea planurilor parţiale, din
introducerea facilă a unor noi holoni în schema holonică sau a unor noi planuri de soluţionare a
scopurilor, şi prin corelarea cu flexibilitatea. În acest capitol, accentul se pune pe un nou tip de
flexibilitate, care este introdus în prima secţiune, fiind denumit flexibilitate de tip obiect (Pascal
şi Pănescu, 2010). Aceasta priveşte existenţa în sistem a mai multor surse (de exemplu, depozite)
în care pot exista piese brute, semi-fabricate sau alte componente necesare unei operaţii, sau a
mai multor zone în care anumite produse se pot asambla/depozita, sau în general zone în care se
poate realiza o anumită operaţie; considerarea acestui nou tip de flexibilitate poate conduce la
îndeplinirea unor criterii de optim. Ţinându-se cont de flexibilitatea de tip obiect, se propun în a
doua secţiune patru strategii de planificare: strategia centralizată, strategia de operare, strategia
hibridă şi strategia set-scop. Strategiile vor fi analizate şi comparate în ultima secţiune.
5.2. Mijloace de obţinere a flexibilităţii. Flexibilitatea de tip obiect.
Caracteristica principală necesară sistemelor actuale de producţie priveşte flexibilitatea.
Flexibilitatea se atinge când sistemul de fabricaţie are mijloace fizice (echipamente) prin care un
sistem de control dezvoltat poate satisface criteriile impuse şi se poate adapta la diferite
schimbări în mediul de manufacturare. În literatură sunt evidenţiate trei tipuri de flexibilitate,
considerate în general în sistemele de producţie (Li et al., 2010): flexibilitatea în operare,
flexibilitatea în ordonarea operaţiilor şi flexibilitatea în prelucrare.
În procesul de proiectare şi dezvoltare a arhitecturii HAPBA s-a observat existenţa nou
tip de flexibilitate - flexibilitatea de tip obiect. Acesta priveşte existenţa în sistem a mai multor
surse (depozite) în care pot exista piese brute sau semi-fabricate necesare unei operaţii, sau a
unor zone în care anumite produse se pot asambla sau depozita. Sub acest aspect, un criteriu de
performanţă al structurii holonice implică alegerea unei piese brute (numită în continuare obiect)
sau a unei zone de asamblare/depozitare astfel încât per ansamblu costul de producţie să fie unul
minimizat. Criteriul apare întrucât în sistemul de producţie considerat semi-produsele necesar
unui produs apar în surse diferite, dar transferul şi utilizarea lor într-o secvenţă specifică de
operaţii se face cu costuri diferite. Această problemă este una care poate apărea în general într-un
sistem de fabricaţie şi care influenţează atât flexibilitatea, cât şi optimalitatea unui sistem
holonic. În consecinţă, în următoarele secţiuni se analizează flexibilitatea de tip obiect prin
studierea interacţiunilor dintre holonii produs şi resursă. Mai întâi, sunt propuse câteva strategii
de planificare. Acestea diferă în ceea ce priveşte operarea eficientă a unui proces şi reflectă atât
încărcarea comunicării, cât şi complexitatea computaţională.
5.3. Strategii de planificare în gestionarea flexibilităţii de tip obiect
Concentrând studiul flexibilitatea de tip obiect, s-a observat necesitatea unor strategii de
planificare care să reducă fluxul de interacţiuni între holoni când soluţia optimă necesită a fi
atinsă în flexibilitatea de tip obiect. Mai precis, numărul de scopuri anunţate în sistem trebuie
redus la minim, întrucât un scop ajuns la un posibil contractor va declanşa un proces de
40
planificare în care agentul holonic va fi antrenat în căutarea unei soluţii care poate fi una prin
colaborare, determinând o complexitate mare. Este evident că încărcarea inutilă a unui holon
poate avea consecinţe asupra performanţelor.
În HABPA s-au dezvoltat patru strategii de planificare în gestionarea flexibilităţii de tip
obiect, numite: strategia centralizată, strategia de operare, strategia hibridă şi strategia set-
scop. Acestea sunt ilustrate sumar în Figura 29. Strategiile se bazează pe trei categorii propuse
de scopuri pentru care holonii resursă necesită să aibă capabilităţi în perceperea lor. Categoriile
sunt etichetate ca scopuri de rezervare, operare şi informare. Scopul de rezervare se referă la
acţiunea de rezervare a unei entităţi, care poate fi o locaţie (de exemplu, o poziţie într-un depozit,
masă de asamblare, unde o piesă va fi plasată) sau un obiect necesar într-o operaţie viitoare. Al
doilea tip de scop, de operare, are ca obiectiv execuţia unei operaţii predefinite în schema
holonică: transport, asamblare, procesare sau inspecţie produs. Scopul de informare este necesar
când o informaţie este cerută fără a implica procesul de planificare (spre exemplu, un holon
produs verifică dacă în sistem există sau nu un semi-produs, fără însă al rezerva). Relaţii
specifice între aceste categorii de scopuri există; înaintea asamblării unui produs este necesar să
se verifice dacă semi-fabricat sunt în sistem, dacă există o locaţie disponibilă pentru operaţiile ce
vor urma, rezervarea acestora şi abia apoi propunerea de scopuri operaţionale.
Considerând în sistem existenţa a n obiecte necesare, strategiile propuse se explică astfel
(vezi Figura 29). În strategia centralizată un holon produs anunţă înainte n scopuri de rezervare
în care descrie obiectele necesare şi, apoi, propune scopuri n operaţionale conţinând prescrierea
obiectelor rezervate anterior, astfel încât soluţia optimă să poate fi atinsă. Termenii descriere şi
prescriere permit să definim modul în care într-un scop un obiect sau o operaţie este rigidă sau
nu. Dacă ne raportam la un obiect, prin descriere se precizează că un obiect oarecare din sistem,
având anumite caracteristici, poate fi utilizat. Contrar, prin prescriere se indică precis care obiect
va fi utilizat în procesul de fabricaţie. În strategia de operare se mută nivelul decizional în
selectarea obiectelor la nivelul holonilor resursă. Astfel, un holon produs propun un scop
operaţional prin care descrie obiectul sau obiectele necesare, lăsând holonii resursă să anunţe
scopuri de rezervare la sursele cu care se află în legătură. Fiecare dintre cele două strategii are
avantaje şi dezavantaje şi atunci este normal să se studieze o combinaţie a acestora; astfel, a fost
introdusă strategia hibridă. Când în sistemul de producţie nu există sau există un singur obiect,
strategia centralizată este utilizată, iar pentru alte cazuri strategia operaţională este de preferat. O
alternativă la strategia centralizată este strategia set-scop, în care scopurile de operare care se
referă la aceeaşi operaţie, dar au prescrise obiecte diferite, sunt grupate într-un singur scop de
operare, numit set de scopuri. La primirea unor seturi de scopuri, holonii resursă trebuie să
răspundă pentru fiecare set numai cu o singură ofertă, cea mai optimă, la unul din scopurile din set.
Fiecare din strategiile propuse va conduce către aceeaşi soluţie optimă, dar numărul de
scopuri interschimbate în sistem este diferit, ceea ce înseamnă o complexitate a procesării
diferite. Performanţa acestor strategii este discutată în secţiunea următoare.
41
Figura 29. Succesiunea de scopuri în patru strategii de planificare 1. centralizată, 2. de operare, 3.
hibridă şi 4. set-scop
5.4. O comparaţie asupra strategiilor propuse
Strategiile descrie anterior sunt analizate pe o schema holonică dezvoltată pe un mediu
experimental de testate. Sistemul de fabricaţie include doi roboţi industriali, cu o zonă comună
de lucru, capabili să efectueze operaţii de transfer piese şi semifabricate, şi asamblare. În jurul
roboţilor sunt iniţial prezente trei dispozitive de stocare. Fiecare robot are câte două depozite în
zona de lucru, dintre care un depozit este plasat în zona comună. Fiecare entitate fizică (robot,
depozit) este gestionată de un holon resursă. În structura holonică se consideră un holon produs
care are de efectuat un scop de operare: un obiect (semi-fabricat) cu anumite caracteristici
trebuie să fie plasat într-o poziţie specificată într-un dispozitiv de stocare existent; acest scop va
fi numit scop de transfer obiect (TO) şi este propus către holonii resursă de tip robot. Scopul este
completat cu un scop de rezervare obiect (RO), care în funcţie de strategia aleasă este propus în
sistem de holonul produs sau de către holonii resursă către holonii resursă de tip depozit. Un
scop de informaţii obiect se etichetează prin IO.
Pe structura holonică considerată, au fost selectate trei cazuri care cuprind situaţiile când
schema holonică este capabilă să ofere pentru scopul de producţie propus o singură soluţie, două
soluţii sau niciuna. Soluţiile sunt date de către holonii de tip robot şi depind de poziţionarea
obiectului în sistem. Obiectivul experimentelor constă în analiza performanţei fiecărei strategii
astfel încât să se poate prezenta o comparaţie între acestea la nivelul numărului de scopuri
propuse în sistem pentru fiecare caz considerat. Această structură poate fi considerată ca un test
pentru capacitatea sistemului holonic de a face faţă la schimbările mediului, când: 1) un număr
variabil de depozite există în sistem şi 2) existenţa sau nu a obiectului căutat.
Rezultatele obţinute pentru primul caz sunt sintetizate în Tabelul 4, iar primele două
strategii sunt detaliate pe mediul considerat în Figura 30, unde dreptunghiul negru reprezintă
obiectul necesar, un dreptunghi cu linie continuă indică locaţia finala pentru obiect, şi un
dreptunghi cu linie întreruptă reprezintă o poziţie intermediară, prin care se face transferul
obiectului. Scopurile anunţate între holoni sunt indicate prin săgeţi, care sunt orientate de la
manager la contractor. O săgeată cu linie întreruptă marchează un scop care primeşte o ofertă
negativă. Scopurile de rezervare pentru poziţia intermediară şi cea finală nu sunt reprezentate şi,
de asemenea, nu sunt considerate în analiză pentru că introduc o valoare constantă
42
Figura 30. Schema de interacţiune dintre holoni pentru cazul 1 - a) strategia centralizată şi b)
strategia de operaţie
Tabelul 4. Numărul de scopuri necesar în cazul 1
Tip
Strategie
Secvenţa/
Tip Scop
Nr.
Scopuri
Nr.
oferte
Nr. oferte
negative
+ HR - depozit
A* B* C* D*
1. strategia
centralizată
I RO 3 1 2 1 - 1 1
II TO 2 1 1 0 - 0 2
III STO 1 1 0 0 - 0 1
total 6 +1 - +1 +4
2. strategia
de operare
I TO 2 1 1 0 - 0 0
II RO 2 0 0 1 - 0 0
III STO 1 1 1 0 - 0 0
IV SRO 2 1 1 0 - 1 1
total 7(6) +1 - +1 +1
3. strategia
hibridă
I IO 3 - - 1 - 1 1
II RO 1 1 0 0 - 0 x
III TO 2 1 1 0 - 0 x
IV STO 1 1 0 0 - 0 x
total 7(4) 0 - 0 x
4. strategia
set-scop
I RO 3 1 2 1 - 1 1
II TO 2 1 1 0 - 0 0
III STO 1 1 0 0 - 0 0
total 6 +1 - +1 +1
*A – un depozit nou fără piesă adăugat în zona comună
*B – un depozit nou cu piesă adăugat în zona comună
*C – un depozit nou fără piesă adăugat în zona specifică
*B – un depozit nou cu piesă adăugat în zona specifică
În Tabelul 4 apar numărul total de scopuri necesare fiecărei strategii, şi suplimentat, în
ultima coloana este indicat cu cât creşte numărul de scopuri atunci când se introduce un nou
holon de tip depozit în sistem. O îmbunătăţire pentru strategia operaţională poate fi făcut la
nivelul honului resursă de tip robot când apare un sub-scop pentru cooperare. Holonul contractor
ar trebui să caute obiectul numai atunci când acesta este în aria lui specifică de lucru şi să
43
excludă aria comună cu holonul manager, deoarece această posibilitate a fost deja verificată la
nivelul holonului manager. Această simplificare considerată reduce numărul de scopuri de la 7 la
6 (vezi Tabelul 4) şi aceasta abordare este în continuare considerat în restul cazurilor. Pentru
strategia hibridă două valori apar la numărul de scopuri în Tabelul 4. Şi anume, un număr de
scopuri redus poate fi considerat (numai patru scopuri) dacă scopurile de informare nu sunt
numărate. Această reducere este justificată de faptul că aceste scopuri nu implică un proces de
planificare. Rezultatele arată o depreciere pentru strategia centralizată când un depozit cu o piesă
este adăugat în zona de lucru a agentului care controlează robotul 1 (de văzut Figura 30b), şi
anume agentul care este subcontractor. Prin introducerea acelui depozit cu o piesă se atinge
flexibilitatea de tip obiect.
Figura 31. Schema de interacţiune dintre holoni pentru cazul 2 - a) strategia centralizată şi b)
strategia de operaţie
Tabelul 5. Numărul de scopuri necesar în cazul 2
Tip Strategie Secvenţa/
Tip Scop
Nr.
Scopuri
Nr.
oferte
Nr. oferte
negative
+ HR - depozit
A B C D
1. strategia
centralizată
I RO 3 2 1 1 1 1 1
II TO 4 4 0 0 2 0 2
III STO 2 2 0 0 0 0 1
total 9 +1 +3 +1 +4
2. strategia de
operare
I TO 2 2 0 0 0 0 0
II RO 4 2 2 2 2 1 1
total 6 +2 +2 +1 +1
4. strategia
set-scop
I RO 3 2 1 1 1 1 1
II TO 2 2 0 0 0 0 0
total 5 +1 +1 +1 +1
Flexibilitatea de tip obiect este scoasă în evidenţă de al doilea caz, când structura
holonică este capabilă să ofere două soluţii pentru un scop, în concordanţă cu obiectele existente
în dispozitivele de stocare. Acest caz este detaliat în Figura 31, iar rezultate sunt prezentate în
Tabelul 5. Aici, poziţia finală a obiectului este în zona comună a roboţilor, două piese sunt locate
în zonele specifice ale roboţilor. În Tabelul 5, strategia hibridă nu a fost reprezentată deoarece
aceasta determină aceleaşi rezultate ca strategia de operare (nu apare comutare între strategii). În
acest caz, strategia tip set-scop oferă cele mai bune rezultate.
44
Ultimul caz când structura holonică nu oferă nicio soluţie pentru scopul propus este
ilustrat în Figura 32. Se poate observa în mod clar cum strategia operaţională necesită un număr
sporit de scopuri pentru atingerea soluţiei. Aceasta se datorează modului în care fiecare agent
încearcă să devină manager şi propună scopuri suplimentare. Numărul de scopuri diferă între
strategia operaţională şi alte strategii; acest lucru se poate observa în Tabelul 6. Ultimele două
strategii nu au fost reprezentate, deoarece produc acelaşi rezultat ca strategia centralizată. Prin
compararea ultimelor două cazuri se remarcă faptul că strategia centralizată prezintă un număr redus
de scopuri când sistemul determină o soluţie sau niciuna (există o singură ofertă sau niciuna pentru
scopul de rezervare), şi un număr sporit de scopuri când flexibilitatea de tip obiect este posibilă.
Figura 32. Schema de interacţiune dintre holoni pentru cazul 3 - a) strategia centralizată şi b)
strategia de operaţie
Rezultatele prezentate în tabelele anterioare pot fi completate cu următoarea analiză
referitoare la modificarea numărului de depozite din sistem. Rezultatele analizei sunt prezentate
pentru fiecare caz în Figura 33, Figura 34 şi Figura 35. Axa x reprezintă numărul de depozite. Se
începe de la mediul experimental cu trei depozite. Etichetele folosite pentru depozitele adăugate
au aceeaşi semnificaţie cu cele folosite în tabelele deja prezentate. Axa y reprezintă numărul de
scopuri propuse în sistem.
Tabelul 6. Numărul de scopuri necesar în cazul 3
Tip
Strategie
Secvenţa/
Tip Scop
Nr.
Scopuri
Nr.
oferte
Nr. oferte
negative
+ HR - depozit
A B C D
1. strategia
centralizată
I RO 3 0 3 1 - 1 -
total 3 +1 - +1 -
2. strategia
de operare
I TO 2 0 2 0 - 0 -
II RO 4 0 4 2 - 1 -
III STO 2 0 2 0 - 0 -
IV SRO 4 0 4 0 - 1 -
total 12(10) +2 - +2 -
În Figura 33, referitoare la cazul cu o soluţie (o singură ofertă trimisă către holonul produs), este
de remarcat cum flexibilitatea de tip obiect apare când un depozit care conţine un obiect este
adăugat în aria robotului 1 - linia verticală. La acel moment, strategia hibridă schimbă de la
folosirea iniţială a strategiei centralizate la strategia operaţională, evitându-se în acest fel
creşterea numărului de scopuri. Un avantaj al strategiei hibride care poate fi remarcat în Figura
33 este modul în care aceasta păstrează un număr constant al scopurilor când există un singur
obiect. Graficul din Figura 34 reflectă comportamentul diferitelor strategii în al doilea caz.
Flexibilitatea de tip obiect apare în structura iniţială a mediului de producţie, deoarece holonul
45
produs poate alege din două soluţii. Aceasta explică de ce strategia hibridă este setată pe
strategia operaţională de la început, acest fapt fiind confirmat de grafic. Pentru acest caz,
strategia set-scop necesită un număr redus de scopuri, întrucât strategia grupează scopurile
operaţionale. Ultimul grafic, pentru cazul cu nicio soluţie (Figura 35) indică faptul că strategia
centralizată este necesară într-un astfel de caz extrem, prin evitarea unei căutări care nu este
necesară la nivelul holonilor resursă. Aceasta justifică în continuare necesitatea strategiei hibride.
În fapt, toate graficele arată rezultate bune pentru strategia hibridă, exceptând cazul al doilea.
Utilizarea strategiei de tip set-scop creează probleme specifice (contractorii trebuie să deţină
capabilitatea pentru administrarea scopurilor în set). Din acest motiv strategia hibridă este
preferată în cazurile considerate.
Figura 33. Evoluţia numărului de scopuri când un depozit este adăugat în caz 1 pentru fiecare
strategie
Figura 34. Evoluţia numărului de scopuri când un depozit este adăugat în caz 2 pentru fiecare
strategie
46
Figura 35. Evoluţia numărului de scopuri când un depozit este adăugat în caz 3 pentru fiecare
strategie
5.5. Concluzii
Această analiză asupra numărului de scopuri propuse în sistem pe parcursul unei operaţii
este importată, întrucât fiecare scop primit declanşează un proces de planificare la nivelul
contractorului. Astfel, reducerea scopurilor sporeşte eficacitatea unui sistem holonic (răspuns
rapid al planificării, evitarea unor căutări de soluţii inexistente, etc.) Pe baza rezultatelor obţinute
s-a ajuns la impunerea strategiei hibride, întrucât acesta conduce către o încărcare minimă cu
scopuri a sistemului holonic; consecinţa va fi aceea a unei complexităţi a calculelor mai mică şi
deci performanţe de timp real mai bune. De asemenea, noul tip de flexibilitate propus este
materializabil prin arhitectura HAPBA şi pune în evidenţă încă un avantaj al abordării holonice.
47
Capitolul 6 Evaluarea arhitecturi HAPBA prin mijloacele reţelelor Petri
6.1. Introducere
Obiectivul principal al experimentelor realizate a constat în detectarea anomaliilor pur
logice ale operării sistemului holonic proiectat în conformitate cu mecanismul de coordonare
dezvoltat folosind planificarea în spaţiul planurilor şi protocolul Contract Net. Într-un plan
secundar, experimentele au permis şi unele analize cantitative. Graful de accesibilitate obţinut
dintr-o stare iniţială permite verificarea proprietăţilor de siguranţă: absenţa stării de deadlock,
păstrarea consistenţei bazei de cunoştinţe, răspunsul sistemului la diferite scopuri de fabricaţie.
Primele două proprietăţi au fost luate în considerare pe durata implementării modelelor, astfel
încât rezultate care urmează a fi prezentate provin din modele viabile şi mărginite. Rezultatele au
fost obţinute prin includerea în starea iniţială a scopurilor pentru unul sau mai mulţi holoni, în
vederea observării felul în care sistemul reacţionează şi răspunde la scopurile primite. În
următoarele secţiuni sunt analizate patru experimente, prin care se ajunge a se evidenţia
necesitatea unui componente centralizate în sistemele holonice.
6.2. Experiment I – un holon produs şi un singur scop
În acest experiment (Pănescu şi Pascal, 2011a) se considerată o structură holonică
formată din patru holoni resursă (HR1 - HR1) şi un holon produs (HP1). Holonii resursă sunt de
capacitate unitară, ceea ce implică o utilizare secvenţială a resursei fizice, şi pot soluţiona
scopuri pentru acţiuni specifice, după cum urmează: HR1 → a1, a4, HR2 → a1, HR3 → a2 şi HR4
→ a3. Se observă că HR1 are o capabilitate duală, situaţie des întâlnită în sistemele de fabricaţie.
Holonul produs (HP1) conţine în biblioteca de planuri un plan de execuţie (6.1) care, după cum
se observă, care se referă la acţiuni ce sunt acoperite de holonii resursă. Pentru planul de execuţie
se consideră fluxul de planificare din (6.2) (vezi Figura 15). Holonii resursă prezintă planuri de
execuţie simple, cu acţiuni pentru dispozitivele lor fizice, iar fluxurile de planificare nu implică o
schemă de contractare.
a a a a a a1 0 1 2 3 4 (6.1)
wp p p p
a a a a a a a a a0 1 1 2,3 2,3 4 41 1 2,3 4 (6.2)
Pentru această configuraţie, în Tabelul 7 sunt prezente rezultatele extrase din graful de
accesibilitate şi obţinute când HP1 primeşte un scop g1 soluţionabil prin planul (6.1). Informaţii
generale privitoare la graf apar în partea superioară; acestea fac referire la numărul de stări şi
tranziţii ale sistemului pentru marcajul iniţial. Timpul de construcţie al grafului la utilizarea
instrumentului CNP Tool este, de asemenea, indicat. În partea inferioară se grupează informaţii
despre marcajele finale (stări finale). Pentru fiecare stare finală se pune în evidenţă semnificaţia
şi numărul de mesaje transmise între holoni. După cum se remarcă în tabel, două marcaje finale
apar şi sunt etichetate conform răspunsului dat de HP1 pentru g1. Starea notată cu eşec reprezintă
cazul când HP1 răspunde cu o oferă negativă, prin care se indică incapacitatea de a găsi o soluţie.
Starea notată prin succes indică situaţia când HP1 reuşeşte să rezolve g1, finalizându-se inclusiv
etapa de execuţie. Etapa de execuţie este inclusă în scopul identificării erorilor de proiectare, în
special colectarea inutilă de informaţii (acumularea unor jetoane).
Rezultate obţinute conduc la următoarele remarci. În primul rând, erorile de proiectare au
fost înlăturate şi aici se poate constata că întotdeauna HP1 oferă un răspuns. De asemenea, în
urma comparării marcajului iniţial cu cele două finale, singura deosebire este că HP1 în starea
48
iniţială are la poziţia de intrare un jeton scop şi în stările finale există la poziţia de ieşire un jeton
răspuns; fie un răspuns de ofertă negativă, fie terminarea cu succes. Cu toate acestea, punctul
slab îl constituie starea de eşec, care indică posibilitatea ca HP1 să nu găsească soluţie, chiar dacă
aceasta există. O asemenea situaţie se explică printr-un mod deficitar de alocare a resurselor.
Tabelul 7. Rezultate experiment cu un singur holon produs
Informaţii graf
de accesibilitate
Nr. Stări Nr. Tranziţii Timp
583 985 0 s
Nr.
Stări Finale
Etichetă
Stare
Semnificaţie Stare Nr. Mesaje
PH1
1 448 eşec 18
2 583 succes 23
Prin aplicarea strategiei de ofertare relaxată (SOR), HR1 va putea propune o ofertă
pentru acţiunea a4 chiar dacă capacitatea sa a fost setată pe zero după oferta făcută pentru a1.
Principiul este simplu. După ce s-a făcut o ofertă ne-negativă, un holon poate propune în
continuare o ofertă ne negativă dacă cele două scopuri primite derivă din acelaşi plan de execuţie
al managerului. Rezultate obţinute aplicând SOR sunt prezentate în Tabelul 8. Starea de eşec este
înlăturată. Situaţia în care sistemul HMES nu este capabil să obţină soluţie pentru un scop,
folosind şi strategia SOR, încă există atunci când doi sau mai mulţi manageri planifică pe un set
comun de contractori. Exemplu următor va ilustra această situaţie.
Tabelul 8. Rezultate experiment cu un singur holon produs şi SOR
Informaţii graf
de accesibilitate
Nr. Stări Nr. Tranziţii Timp
727 951 1 s
Nr.
Stări Finale
Etichetă
Stare
Semnificaţie Stare Nr. Mesaje
PH1
1 727 succes 23
6.3. Experiment II – doi holoni produs și un singur scop
Structura holonică de la experimentul anterior este completată cu un holon produs (HP2)
având planul de execuţie şi fluxul de planificare din (6.3) şi (6.4). Acţiunile a1 şi a2 coincid cu
acţiunile din planul de execuţie (6.1) al lui HP1, iar holonii resursă au aceleaşi capabilităţi (HR1
→ a1, a4, HR2 → a1, HR3 → a2 şi HR4 → a3).
a a a a2 0 1 2 (6.3)
wp p
a a a a a0 1,2 1,22 1,2 (6.4)
În acest experiment, intrarea în HMES o constituie două scopuri: g1 este scopul posibil de
rezolvat de către HP1, fiind la fel ca în experimentul anterior, şi g2 este posibil rezolvabil de HP2.
Acum sistemul HMES este mai complex, aşa după cum apare şi din graful de accesibilitate (vezi
Tabelul 9). De notat este cum se acoperă întreaga clasă de răspunsuri: fie cei doi holoni produs
finalizează scopurile cu succes (acest caz este posibil numai dacă holonii planifică şi execută
operaţiile secvenţial), fie unul dintre ei, sau amândoi eşuează prin conflictul creat între procesele
lor de planificare.
49
Tabelul 9. Rezultate experiment cu doi holoni produs
Informaţii graf
de accesibilitate
Nr. Stări Nr. Tranziţii Timp
177393 538994 2701 s
Nr.
Stări Finale
Etichetă
Stare
Semnificaţie Stare Nr. Mesaje
PH1 PH2
1 132394 eşec succes 23
2 144283 eşec eşec 26
3 163881 eşec eşec 29
4 165460 eşec succes 28
5 173626 eşec succes 31
6 176786 succes eşec 33
7 177393 succes succes 36
Chiar dacă alte marcaje finale din Tabelul 9 se referă la situaţiile când HMES finalizează
cu succes cel puţin un scop, punctul slab arătat prin acest experiment este posibilitatea ca schema
holonică să termine cu un eşec total (niciun scop rezolvat). Următorul test pe aceeaşi structură
holonică constă în aplicarea strategiei de ofertare relaxată (SOR). Rezultatele obţinute sunt
prezentate în Tabelul 10 şi sunt identice ca formă cu cele anterioare; diferenţa constă în
dimensiunea grafului de accesibilitate, care în acest caz, este mai amplu indicând mai multe
posibilităţi. Explicaţia pentru lipsa vreunei îmbunătăţiri adusă de SOR este: procesele de
planificare ale celor doi holoni produs interferează şi determină condiţii de blocare reciproce.
Tabelul 10. Rezultate experiment cu doi holoni produs şi SOR
Informaţii graf
de accesibilitate
Nr. Stări Nr. Tranziţii Timp
291639 870074 7824 s
Nr.
Stări Finale
Etichetă
Stare
Semnificaţie Stare Nr. Mesaje
PH1 PH2
1 230365 eşec succes 23
2 246177 eşec eşec 26
3 275781 eşec eşec 29
4 276027 eşec succes 28
5 287845 eşec succes 32
6 291212 succes eşec 33
7 291639 succes succes 26
Prin aplicarea strategiei bazate pe holonul staff (SBHS) pe aceeaşi structură holonică considerată
s-au obţinut rezultatele din Tabelul 11. În Tabelul 12 apar rezultatele când strategiile SBHS şi
SOR (strategia de ofertare relaxată) au fost utilizate împreună. Îmbunătăţirea este clară atunci
când HS este considerat. Cel puţin un holon produs finalizează cu succes scopul primit datorită
prevenirii interferării celor două fluxuri de planificare prin lăsarea unui singur flux să exercite
funcţia de alocare asupra resurselor. Marcajele finale din Tabelul 11 şi Tabelul 12 când un singur
holon produs răspunde negativ sunt explicabile. În timpul când un holon produs este în faza de
execuţie, contractorii lui sunt încă dedicaţi. În acest timp, celălalt holon produs are posibilitatea
să contracteze subscopurile si să primească oferte negative de la contractorii dedicaţi în execuţie.
Concluzia este că sistemul holonic poate fi sigur dacă HS permite începerea procesului de
50
planificare pentru un holon care cere resurse comune cu un alt holon căruia i s-a permis
începerea planificării, numai atunci când acesta termină planificarea şi execuţia.
Tabelul 11. Rezultate experiment cu doi HP şi SBHS
Informaţii graf
de accesibilitate
Nr. Stări Nr. Tranziţii Timp
116526 342203 1251 s
Nr.
Stări Finale
Etichetă
Stare
Semnificaţie Stare Nr. Mesaje
PH1 PH2
1 111327 eşec succes 34
2 115022 succes eşec 35
3 116526 succes succes 39
4 99775 eşec succes 31
În concluzie, un anumit efect al strategiilor SOR şi SBHS asupra complexităţii spaţiului
de stări este arătat prin acest experiment. Ţinând cont de faptul că topologia modelului nu a fost
schimbată pe parcursul experimentelor şi trecerea de la un experiment în altul s-a făcut prin
activarea sau dezactivarea unor proceduri, complexitatea apare astfel: SBHS introduce o
constrângere faţă de experimentul implicit, şi acest lucru se observă la dimensiunea grafului de
accesibilitate, care este mai redus (atât numărul de noduri, cât şi numărul de tranziţii este redus);
în contrast SOR relaxează sistemul prin creşterea dimensiunii grafului faţă de varianta implicită
(vezi Tabelul 9, Tabelul 10 şi Tabelul 11). Potrivit rezultatelor din Tabelul 12 când amândouă
strategiile au o fost aplicate simultan, numărul de stări şi tranziţii are o valoare între folosirea
numai SBHS şi cazul implicit (cel fără vreo strategie). Relaţia dintre complexitatea strategiilor,
aşa cum se reflectă în numărul de stări şi tranziţii, urmează expresia (6.5):
SBHS SBHS SOR implicit SOR (6.5)
O concluzie importantă este că niciuna din aceste strategii nu poate fi utilizată
independent, aşa cum se poate remarca din experimentele efectuate, şi trebuie să fie aplicate
împreună.
Tabelul 12. Rezultate experiment cu doi HP, SBHS şi SOR
Informaţii graf
de accesibilitate
Nr. Stări Nr. Tranziţii Timp
157654 453669 2473 s
Nr.
Stări Finale
Etichetă
Stare
Semnificaţie Stare Nr. Mesaje
PH1 PH2
1 137802 eşec succes 31
2 152323 eşec succes 34
3 156406 succes eşec 35
4 157654 succes succes 39
6.4. Experiment III – un holon produs şi două scopuri
În acest experiment (Pascal şi Pănescu, 2011) structura holonică este formată dintr-un
holon produs (HP1) şi doi sau patru holoni resursă (HR1 → a1, HR2 → a2, HR3 → a1, HR4 → a2),
cu capacitate unitară. Interferenţa între două fluxuri de planificare ale acelui holon (holonul
primeşte consecutiv două scopuri – g1 şi g2) constituie elemente interes în experimentul de faţă,
unde s-au considerat patru cazuri. Diferenţa dintre acestea este dată de disponibilitatea holonilor
resursă şi de tratamentul scopurilor primite. În cazul 1 şi 2, HP1 are la dispoziţie o structură
holonică cu holonii resursă limitaţi, care îi permite numai unui singur scop să fie planificat;
51
această restricţie este înlăturată în cazurile 3 şi 4. Pe de altă parte, HP1 încearcă planuri de
execuţie similare în cazurile 1 şi 3, respectiv 2 şi 4 (prin fluxurile de planificare se încearcă
contractarea acţiunilor din planurile de execuţie aferente).
Tabelul 13. Rezultate experiment caz 1
Stare holon produs Scop g1 (a1≺a2) Scop g2 (a1≺a2)
Stare holoni resursă RH1→a1, RH2→a2
Nr. Stări 13525 Nr. Tranziţii 23030
Nr. Stări Finale 80
Scop g1 Scop g2 %
succes succes 0
succes eşec 50
eşec succes 50
eşec eşec 0
Rezultatele cazurilor considerate sunt prezentate în Tabelele 13-16. Acestea conţin trei
categorii de informaţii. Primele două linii indică starea iniţială a structurii holonice: scopul
primit de HP1, acţiunile incluse în planul de execuţie (în fiecare caz planul de execuţie este
complet ordonat) şi planul de execuţie prin care se soluţionează acesta. Informaţiile sunt utilizate
în stabilirea marcajului iniţial al modelului Petri. HP1 două scopuri g1 şi g2; rezultatele
planificării, reflectând procesul de alocare resurse, sunt clasificate în trei clase, şi anume:
procesul de planificare reuşeşte să aloce două planuri de execuţie, numai un plan dintre ele, sau
niciunul.
Tabelul 14. Rezultate experiment caz 2
Stare holon produs Scop g1 (a1≺a2) Scop g2 (a2≺a1)
Stare holoni resursă RH1→a1, RH2→a2
Nr. Stări 55271 Nr. Tranziţii 116622
Nr. Stări Finale 186
Scop g1 Scop g2 %
succes succes 0
succes eşec 48.39
eşec succes 48.39
eşec eşec 3.23
Pentru fiecare clasă, procentul indicat reprezintă cât la sută din numărul total de stări
finale corespund clasei respective. Când amândouă scopurile sunt soluţionate prin acelaşi plan de
execuţie (plan care cuprinde succesiunea de acţiuni a1, a2) şi doi holoni resursă sunt în sistem
(HR1 şi HR2), atunci numai un singur scop poate fi îndeplinit (vezi Tabelul 13). În acest prim
experiment niciun conflict nu apare între fluxurile de planificare. Când structura holonică este la
fel, exceptând planurile de execuţie folosite de HP1, sunt obţinute rezultatele din Tabelul 14.
Acestea indică existenţa unui conflict între planificări: există 3,23 % din marcaje finale care
indică cazul când niciun scop nu este îndeplinit. Înseamnă că HP1 eşuează în realizarea a cel
puţin unui scop, în ciuda faptului că o soluţie există. Această situaţie nu apare în experimentul
52
considerat în Tabelul 13, deoarece în acel caz fluxul de planificare este abandonat când HP1 nu
primeşte ofertă pentru prima acţiune, şi în acest fel situaţia de eşec complet este evitată.
Tabelul 15. Rezultate experiment caz 3
Stare holon produs Scop g1 (a1≺a2) Scop g2 (a1≺a2)
Stare holoni resursă RH1→a1, RH2→a2, RH3→a1, RH4→a2
Nr. Stări 63257 Nr. Tranziţii 139552
Nr. Stări Finale 164
Scop g1 Scop g2 %
succes succes 39.02
succes eşec 30.49
eşec succes 30.39
eşec eşec 0
Cazul din Tabelul 15 este similar cu primul experiment, dar de această dată există
marcaje finale care indică finalizarea pentru amândouă scopurile, şi acest lucru este posibil
datorită structurii holonice care a fost completată cu încă doi holoni resursă. Aici se observă
posibilitatea ca amândouă scopurile să fie soluţionate cu un procent de 39,02%. Totuşi în sistem
există resurse suficiente pentru amândouă planurile, ceea ce indică faptul că 60,98% din stările
finale cuprind un conflict în planificare între cele două fluxuri. Acelaşi lucru este arătat de
rezultate din Tabelul 16.
Experimentele scot în evidenţă necesitatea unui mecanism la nivel de holon prin care,
conform cazurile prezentate, să se înlăture stările nedorite (stări care nu prezintă soluţii, chiar
dacă în sistem există una).
Tabelul 16. Rezultate experiment caz 4
Stare holon produs Scop g1 (a1≺a2) Scop g2 (a2≺a1)
Stare holoni resursă RH1→a1, RH2→a2, RH3→a1, RH4→a2
Nr. Stări 174575 Nr. Tranziţii 396964
Nr. Stări Finale 324
Scop g1 Scop g2 %
succes succes 23.26
succes eşec 38.37
eşec succes 38.37
eşec eşec 0
6.5. Experiment IV – rezolvarea unei sarcini de asamblare
În experimentul din această secţiune, mediul de fabricaţie considerat este cel descris în
(Pănescu şi Pascal, 2011b). Scopul de fabricaţie priveşte produse ca acela ilustrat în Figura 36.
Produsul este alcătuit din patru piese (obiecte) şi este asamblat în următoarea ordine: piesa de tip
A se plasează prima, după care două piese de tip B pot fi ataşate în orice ordine, chiar simultan,
53
şi în final produsul este obţinut prin asamblarea piesei de tip C. La procesul de asamblarea sunt
consideraţi doi holonii resursă care reprezintă doi roboţii industriali.
Figura 36. Exemplu produs de asamblare
Anumite experimente simulate au fost considerate, care au presupus prin utilizarea
modelului produs din Figura 36. Există doi holoni produs (HP1 şi HP2) care se referă la
fabricarea a două produse având planul de asamblare similar cu cel din Figura 36, dar cu
diferenţe privind la caracteristicile pieselor utilizate şi privind felul în piesele vor fi utilizare de
holonii resursă la asamblare. În acest mod, rezultă că planurile de execuţie ale holonilor produs
sunt similare cu planul din expresia (1) (execuţia simultană a celor două acţiuni este posibilă
când cei doi roboţi sunt implicaţi), dar cu acţiuni diferite: planul pentru PH1 conţine acţiunile a1
şi a2, iar pentru PH2 acţiunile a3 si a4. Există un scenariu simplu care dezvăluie în mod clar
nevoia unei componente centralizate – holonul staff. Acesta apare atunci când cei doi roboţi,
văzuţi ca holoni resursă HR1 şi HR2, sunt capabili să realizeze acţiunile care sunt indicate în
prima linie din Tabelul 17; se consideră că în aria de lucru a primului robot există o piesă ce
poate fi utilizată în realizarea oricăreia din acţiunile a1 şi a3, în timp ce în legătură cu piesa
disponibilă la doilea robot, aceasta poate fi utilizată pentru acţiunile a2 şi a4. Tabelul 17 conţine
date ce permit o comparaţie între operarea sistemului holonic fără şi cu implicarea holonului
staff. În partea superioară a tabelului, sunt prezentate informaţiile referitoare la graful de
accesibilitate obţinut în acest experiment. Se poate observa că implicarea holonului staff are
efect de reducere a grafului de accesibilitate prin diminuarea numărului de stări şi tranziţii.
Marcajele terminale sunt stările finale din care nicio tranziţie nu este posibilă. Pe baza
informaţiilor din jetoane, marcajele terminale pot fi clasificate în trei categorii. Este posibil ca
unul dintre holonii produs să finalizeze planificarea cu succes, sau niciunul. Procentul prezent în
tabel priveşte numărul de marcaje terminale care aparţin la fiecare din cele trei categorii.
Cum era de aşteptat, rezultatele din Tabelul 17 arată că implicarea holonului staff în
planificarea holonilor produs elimină cazul nedorit. Se poate observa că proprietăţile de
mărginire şi viabilitate ale reţelelor Petri sunt necesare, dar nu şi suficiente pentru operarea
sigură a sistemului holonic. În exemplu analizat, aceste condiţii sunt îndeplinite, dar chiar şi aşa
funcţionarea defectuoasă a componentei de planificare holonică este posibilă.
54
Tabelul 17. Rezultate experimente
Stare holon produs Scop g1 (a1≼a2) Scop g2 (a2≼a1)
Capabilităţi holoni resursă RH1→{a1, a3}, RH2→{a2, a4}
Metoda implicit cu staff implicit* cu staff*
Nr. Stări 11148 5700 9643 4583
Nr. Tranziţii 24180 11018 16406 6626
Nr. Stări Finale 50 32 50 32
HP1 HP2 % % % %
succes succes 0 0 0 0
succes eşec 48 50 48 50
eşec succes 48 50 48 50
eşec eşec 4 - 4 -
Tabelul 17 conţine, de asemenea, şi un alt tip de comparaţie. S-a constatat că modelul
reţelei contribuie de comunicaţie la creşterea dimensiunii grafului de accesibilitate şi această
influentă poate fi redusă la minim prin considerarea tranziţiilor acestui model cu prioritate mare
faţă de restul tranziţiilor. Acest lucru implică o constrângere de ordonare a evenimentelor. Se
poate afirma că agenţii holonici folosesc reţeaua într-un mod secvenţial. După compararea
rezultatelor obţinute în acest mod (rezultatele sunt etichetate cu * în tabel) cu versiunea clasică,
se constată o reducere cu 13,5 – 19,6% a numărului de stări şi cu 32,1 – 39,8% a numărului de
tranziţii, iar rezultatele privind marcajele finale sunt aceleaşi.
6.6. Concluzii
Deşi protocolul de coordonare a sistemelor multiagent Contract Net este un mecanism
esenţial de coordonare în acest tip de sisteme, s-a dovedit că aplicarea sa în sistemele de
fabricaţie poate crea deficienţe în funcţionare; de aceea, s-a impus adaptarea şi completarea
protocolului de coordonare, în concordanţă cu celelalte elemente specifice ale arhitecturii
holonice dezvoltate. După cum se ilustrează în această capitol, prin analiza performanţelor
sistemelor de fabricaţie holonice conform studierii grafului de accesibilitate s-au putut verifica
proprietăţi de siguranţă: absenţa stării de deadlock, păstrarea consistenţei bazei de cunoştinţe,
răspunsul adecvat al sistemului la diferite tipuri de scopuri. Aplicarea strategiilor de ofertare
relaxată şi cea bazată pe holonul staff, arhitectura HAPBA nu prezintă defecte pur logice. Astfel,
elementele propuse şi demonstrate teoretic privind partea de planificare în capitolul 4, sunt
completate prin validarea obţinută experimental, conform celor explicate în acest capitol.
55
Capitolul 7 Concluzii; contribuţii ale tezei; posibilităţi de continuare a cercetării
7.1. Contribuţii
În prezenta teză de doctorat, contribuţiile principale se încadrează în ariile de cercetare:
1. Arhitecturi bazate pe agenţi pentru sistemele de producţie;
2. Strategii de coordonare a sistemelor multiagent/holonice;
3. Planificarea sistemelor multiagent/holonice;
4. Aplicaţii ale mecanismului de raţionament de tip BDI;
5. Modelarea şi analiza sistemelor holonice de execuţie prin reţele Petri;
6. Flexibilizarea sistemelor de producţie.
1. Arhitecturi bazate pe agenţi pentru sistemele de producţie
Propunerea unei noi arhitecturi adaptive bazată pe agenţi de tip holonic, obţinută
prin combinarea mai multor elemente: planificarea în spaţiul planurilor, mecanism
de raţionament de tip BDI, coordonarea prin protocolul Contract Net şi pe
conceptele de holon şi holarhie; toate aceste elemente au fost adaptate şi
completate cu elemente specifice abordării holonice.
Se propune un model structural pentru un holon, unde diferenţa apare faţă de alte
modele la componenta de structură. Aceasta se defineşte dinamic în urma unui
proces de planificare iniţiat în urma primirii unui scop, şi care constituie o
holarhie; excepţia apare în cazul holonilor resursă unde componenta de structură
cuprinde un dispozitiv fizic de execuţie.
Se propune o structură holonică formată din patru clase de holoni (ordin, produs,
resursă şi staff), în care spre deosebire de alte abordări toţi holonii sunt implicaţi
activ şi au rolurile ajustate în mod specific. Fiecare holon are ca nucleu deliberativ
un agent holonic.
S-a proiectat şi dezvoltat o aplicaţie driver, prin care s-a facilitat agentificarea
holonilor resursă de tip robot, conveior şi depozite. Aplicaţia este folosită şi în alte
domenii de cercetare, precum în dezvoltarea de arhitecturi de control de tip
servoing.
S-a proiectat un model de acces la serviciile oferite de resursele sistemului de
fabricaţie holonică.
S-a proiectat şi dezvoltat arhitectura HAPBA pe un sistem multiagent de tip
JACK.
2. Strategii de coordonare a sistemelor multiagent/holonice.
Deşi protocolul de coordonare a sistemelor multiagent Contract Net este un
mecanism esenţial de coordonare în sistemele multiagent, s-a dovedit că aplicarea
acestuia în sistemele de fabricaţie poate crea deficienţe în funcţionare; de aceea s-
a impus adaptarea şi completarea protocolului de coordonare, în concordanţă cu
celelalte elemente specifice ale arhitecturii holonice dezvoltate.
S-a proiectat şi dezvoltat o extensie a protocolului de coordonare Contract Net, în
vederea aplicării unor strategii de coordonare care să reducă interferenţele
negative de la nivelul proceselor de planificare. Aceste strategii dezvoltate sunt:
56
strategia bazată pe holonul staff, strategia de ofertate relaxată şi cea de
etichetare scopuri.
3. Planificarea sistemelor multiagent/holonice;
Formularea şi demonstrarea unei teoreme care fundamentează o modalitate de
planificare distribuită pentru sistemele holonice în care apare necesitatea
conducerii mai multor fluxuri de activităţi; sunt precizate condiţiile în care
planificarea mai multor scopuri se poate desfăşura simultan fără posibilitatea unor
interacţiuni negative.
S-a fundamentat o metodă de planificare adaptată unor sisteme în care apar mai
multe fluxuri de activităţi, metodă originală prin felul în care îmbină planificarea
în spaţiul planurilor cu o fază deliberativă bazată pe mecanismul BDI şi o
coordonare între entităţile (agenţii) implicaţi în planificare prin CNP.
Propunerea unui mecanism de analiză şi validare a planificării, bazat pe modele
specifice, de tip reţele Petri.
4. Aplicaţii ale mecanismului de raţionament de tip BDI
Un elemente de noutate îl constituie legătura dintre protocolul de coordonare
Contract Net şi mecanismul de raţionament BDI.
Prin arhitectura HAPBA, s-a proiectat un ciclu de lucru al agent holonic care
implică mecanismul BDI la nivelul planificării; astfel, alegerea procesului de
planificare se face printr-un raţionament BDI.
5. Modelarea şi analiza sistemelor holonice de execuţie prin reţele Petri
Modelarea şi analiza prin formalismul reţelelor Petri, monocolore şi colorate, constituie
un suport esenţial în dezvoltarea şi îmbunătăţirea arhitecturii de control pentru fabricaţie.
Definirea unei legături între elementele planificării în spaţiul planurilor şi
reprezentarea lor prin formalismul reţelelor Petri.
Proiectarea unui model operaţional pentru agenţi holonici, în relaţie cu protocolul
de coordonare Contract Net; modelul este unul general din două puncte de vedere:
valid pentru trei tipuri de holoni (ordin, produs şi resursă) şi valid pentru rolurile
de manager, contractor şi contractor-manager.
Dezvoltarea unui formalism pentru procesul de execuţie; definirea noţiunilor de
acţiune de execuţie, plan de execuţie, acţiune adiţională (deliberativă) şi flux de
execuţie, şi relaţiilor dintre acestea.
Definirea unei legături între elementele rezultate din formalizarea execuţiei şi
reprezentarea lor prin reţele Petri; modelul rezultat este în relaţie cu modelul
operaţional al agentului holonic.
Dezvoltarea unui formalism pentru procesul de planificare; definirea noţiunii de
acţiune de planificare, plan de planificare şi flux de planificare;
Definirea unei legături între elementele din formalizarea planificării şi
reprezentarea lor prin reţele Petri; modelul rezultat este în relaţie cu modelul
operaţional al agentului holonic.
Proiectarea unui model pentru mecanismul de raţionament de tip BDI.
57
Proiectarea unui model operaţional extins, prin considerarea implicării holonului
staff.
Dezvoltarea unui model Petri complex pentru structuri holonice, prin transpunerea
modelelor proiectate ca reţele Petri monocolore în modele Petri colorate.
Proiectarea şi dezvoltarea de funcţii pentru obţinerea unui executabil, apropiat de
un prototip software.
Analiza performanţelor sistemelor de fabricaţie holonice prin studierea grafului de
accesibilitate; astfel s-au putut pentru verifica proprietăţi de siguranţă: absenţa
stării de deadlock, păstrarea consistenţei bazei de cunoştinţe, răspunsul sistemului
la diferite tipuri de scopuri.
Limitarea efectului modelului reţelei de comunicaţie a structurii holonice prin
introducerea unor tranziţii de prioritate ridicată.
Dezvoltarea de scripturi în vederea automatizării analizei grafului de accesibilitate.
Considerarea de cazuri care pun în evidenţă necesitatea unui componente
centralizate care să prevină interferenţele dintre procesele de planificare şi
validarea strategiilor de coordonare propuse prin rezolvarea corectă a cazurilor
respective.
6. Flexibilizarea sistemelor de producţie
S-a propus un nou tip de flexibilitate în sistemele de producţie, denumit
flexibilitate de tip obiect. Aceasta priveşte existenţa în sistem a mai multor surse
(depozite) în care pot exista piese brute, semi-fabricate sau alte componente
necesare unei operaţii, sau a mai multor zone în care anumite produse se pot
asambla/depozita, sau în general zone în care se poate realiza o anumită operaţie;
considerarea acestui nou tip de flexibilitate poate conduce la îndeplinirea unor
criterii de optim.
Ţinându-se cont de flexibilitatea de tip obiect, s-au propus patru strategii de
planificare: strategia centralizată, strategia de operare, strategia hibridă şi
strategia set-scop. Strategiile au fost analizate şi comparate, şi pe baza rezultatelor
obţinute s-a ajuns la impunerea strategiei hibride, întrucât conduce către o
încărcare minimă cu scopuri a sistemului holonic; consecinţa va fi aceea a unei
complexităţi a calculelor mai mică şi deci performanţe în timp real mai bune.
Se pot rezuma contribuţiile aduse de această teză în ideea că abordarea propusă prin
arhitectura HAPBA elimină unele mecanisme ad-hoc folosite în proiectarea şi implementarea
unor sisteme holonice. S-a introdus un formalism pe baza căruia se pot demonstra / garanta unele
performanţe ale planificării şi execuţiei holonice; de asemenea, modele propuse şi procedura de
proiectare şi implementare sunt generale, nefiind legate de elemente specifice unui proces
tehnologic sau de anumitelor elemente de implementare, ceea ce este un alt avantaj important
pentru HAPBA.
7.2. Direcţii viitoare de cercetare
Metoda aplicată în proiectarea şi dezvoltarea arhitecturii HABPA, susţinută de partea de
modelare prin formalismul reţelelor Petri, a clarificat o parte din aspectele sistemelor holonice.
Multe aspecte au fost analizate din punct de vedere calitativ. O direcţie de cercetare va fi analiza
58
modelului din punct de vedere cantitativ, prin considerarea reţelelor Petri temporale. O altă
direcţie o constituie utilizarea arhitecturii pe alte medii de fabricaţie, extinderea spre sisteme de
transport inteligent sau spre sisteme de distribuţie energetice. O posibilitate care ar urma să fie
analizată este şi aceea a beneficiilor pe care le poate aduce într-un HMES introducerea unor
holoni cu rol de monitorizare, care să stabilească eficienţa holonilor existenţi în sistem şi să ofere
asemenea analize holonilor manageri pentru ghidare a viitoarelor procese de contractare. De
asemenea, pot fi vizate în viitor metode de analiză prin care diferite abordări holonice să poată fi
comparate şi îmbunătăţite.
Anexă I – Listă lucrări
Reviste indexate ISI
1. Pănescu D, Pascal C (2011b) On a holonic adaptive plan-based architecture: planning scheme and
holons’ life periods. International Journal of Advanced Manufacturing Technology (acceptată pentru
publicare), ISI Journal, 2010 Impact Factor 1,068.
Capitol carte
1. Pănescu D, Pascal C (2011a) HAPBA – a Holonic Adaptive Plan-Based Architecture. Service
Orientation in Holonic and Multi-Agent Manufacturing Control, Editori: Theodor Borangiu, Andre
Thomas, Damein Trentesaux, Studies in Computational Intelligence, Springer (acceptată pentru
publicare).
Reviste cotate ISI
1. Pănescu D, Kloetzer M, Burlacu A, Pascal C (2011) Artificial Intelligence based Solutions for
Cooperative Mobile Robots. Control Engineering and Applied Informatics Journal, (acceptată spre
publicare) – Revista categoria A, cotată ISI, fără indicatori scientometrici.
Reviste cotate B+
1. Pănescu D, Pascal C (2010b) On Resource Service Access in a Holonic Manufacturing System,
Buletinul Institutului Politehnic din Iaşi, Tom LVI (LX), Fasc. 3, Secţia Automatică şi Calculatoare, pp.
95 – 108, 2010, ISSN 1220 2169, Revista categoria B+, indexată în bazele de date: Zentralblatt şi
Copernicus.
Conferințe ISI Proceedings
1. Pănescu D, Pascal C, Şutu M, Varvara G (2009a) Collaborative Robotic System Obtained by
Combining Planning and Holonic Architecture, Proceedings of AT-EQUAL 2009 (Advanced
Technologies for Enhanced Quality of Life), pp. 138-143. (ISI Proceedings)
2. Pănescu D, Varvara G, Pascal C, Sutu M (2009c) On the design and implementation of the resource
holons in a PROSA based architecture. Proceedings of the IEEE 13th International Conference on
Intelligent Engineering Systems, pp. 101-106. (ISI Proceedings)
59
Conferințe
1. Burlacu A, Copot C, Panainte A, Pascal C, Lazar C (2011) Real-time image based visual servoing
architecture for manipulator robots, International Conference on Computer Vision Theory and
Applications, ISBN: 978-989-8425-47-8.
2. Pascal C, Şutu M, Pănescu D (2009) On the communication mechanism in a robot based holonic
manufacturing system. Proceedings of 18th International Workshop on Robotics in Alpe-Adria-Danube
Region, Braşov, Romania, ISSN 2066-4745 (pe CD).
3. Pascal C, Pănescu D (2010) A Study on the Holons’s Interaction for Manufacturing Flexibility. 14th
International Conference on System Theory and Control, Sinaia, Romania, pp. 361 – 366, ISSN 2068-
0465, IEEE – Control Systems Society.
4. Pascal C, Pănescu D (2011) On resource allocation in a Holonic Manufacturing Execution System.
15th International Conference on System Theory, Control and Computing, Sinaia, Romania, (acceptată
spre publicare), IEEE – Control Systems Society.
5. Pănescu D, Kloetzer M, Burlacu A, Pascal C (2010) A multiagent based solution for mobile robots
path planning. 14th International Conference on System Theory and Control, Sinaia, Romania, pg. 355 –
360, ISSN 2068-0465, IEEE – Control Systems Society.
6. Pănescu D, Pascal C (2010a) Some issues on holonic systems analysis, design and implementation,
19th International Workshop on Robotics in Alpe-Adria-Danube Region, pp. 199-204, IEEE Catalog
Number: CFP1075J-CDR.
7. Pănescu D, Şutu M, Pascal C (2009b) On the Design and Implementation of Holonic Manufacturing
Systems. Proceedings of The 2009 World Congress on Computer Science and Information Engineering,
vol. 5, pp. 456-461, IEEE Computer Society. (Indexată în baza de date EI/ISTP).
8. Varvara G, Pascal C, Pănescu D (2009) Service Oriented Architecture Considerations for Distributed
Intelligent Control of Modern Manufacturing Systems. Proceedings of the First International Conference
on Modelling and Development of Intelligent Systems, „Lucian Blaga" University Press, pp. 299 – 307,
ISSN 2067 – 3965.
Bibliografie selectivă
Babiceanu RF (2005) Holonic-based control system for automated material handling systems. Blacksburg, Virginia
(teză).
1. Babiceanu, 2005
Babiceanu RF, Chen FF (2006) Development and applications of holonic manufacturing systems: a survey. Journal
of Intelligent Manufacturing 17:111-131.doi:10.1007/s10845-005-5516-y
2. Babiceanu şi
Chen, 2006
Baker AD (1998) A survey of factory control algorithms that can be implemented in a multi-agent heterarchy:
dispatching, scheduling, and pull. Journal of Manufacturing Systems 17:297–320.
3. Baker, 1998
BBC (2010) The Virtual Revolution http://en.wikipedia.org/wiki/ The_Virtual_Revolution 4. BBC, 2010
Bongaerts L (1998) Integration of scheduling and control in holonic manufacturing systems. Katholieke Universiteit
Leuven (teză).
5. Bongaerts, 1998
Bongaerts L, Monostori L, McFarlane D, Kadar B (2000) Hierarchy in distributed shop floor control. Computers in
Industry 43:123-137.doi:10.1016/S0166-3615(00)00062-2
6. Bongaerts et al.,
2000
Burlacu A, Copot C, Panainte A, Pascal C, Lazar C (2011) Real-time image based visual servoing architecture for
manipulator robots, International Conference on Computer Vision Theory and Applications, ISBN: 978-
7. Burlacu et al.,
2011
60
989-8425-47-8.
Bussmann S (1998) An Agent-Oriented Architecture For Holonic Manufacturing Control. Proc. First International
WorkShop on Intelligent Manufacturing Systems, Lausanne, Switzerland, pp. 1-12.
8. Bussmann, 1998
Celaya JR, Desrochers AA, Graves RJ (2009) Modeling and analysis of multi-agent systems using petri nets,Journal
of Computers 4:981-996. doi:10.4304/jcp.4.10.981-996.
9. Celaya et al.,
2009
Cheng FT, Chang CF, Wu SL (2004) Development of holonic manufacturing execution systems. Journal of
Intelligent Manufacturing 15:253-267.
doi:10.1023/B:JIMS.0000018037.63935.a1
10. Cheng et al.,
2004
Chirn JL, McFarlane DC (2000) A holonic component-based approach to reconfigurable manufacturing control
architecture. In: Proceedings of the 11th International Workshop on Database and Expert Systems
Application, pp 219-223.
11. Chirn şi
McFarlane, 2000
Covanich W, McFarlane D (2009) Assessing ease of reconfiguration of conventinal and Holonic manufacturing
systems: Approach and case study. Engineering Application of Artificial Intelligence,
doi:10.1016/j.enpappai.2009.01.001.
12. Covanich şi
McFarlane, 2009
CPN Tools (2011) Webpage. Online: cpntools.org. 13. CPN Tools,
2011
Dilts D, Boyd N, Whorms H (1991) The evolution of control architectures for automated manufacturing systems.
Journal of Manufacturing Systems 10:79-93.
doi:10.1016/0278-6125(91)90049-8
14. Dilts et al., 1991
D'Inverno M, Luck M (2004) Understanding agent systems. Springer. 15. D'Inverno şi
Luck, 2004
Doran JE, Franklin S, Jennings NR, Norman TJ (1997) On cooperation in multi-agent systems. The Knowledge
Engineering Review 12:309-314.
16. Doran et al.,
1997
Ghallab M, Nau D, Traverso P (2004) Automated Planning – Theory and Practice. Morgan Kaufmann, Amsterdam 17. Ghallab et al.,
2004
Harper R (2005) Programming in Standard ML. Carnegie Mellon University. 18. Harper, 2005
Hrz B, Zhou MC (2007) Modeling and Control of Discrete-event Dynamic Systems: with Petri Nets and Other
Tools. Springer.
19. Hrz şi Zhou,
2007
Hsieh FS (2008) Holarchy formation and optimization in holonic manufacturing systems with contract net.
Automatica 44:959-970. doi:10.1016/j.automatica.2007.09.006
20. Hsieh, 2008
Hsieh FS, Chiang CY (2009) Workflow Planning in Holonic Manufacturing Systems with Extended Contract Net
Protocol. Next-Generation Applied Intelligence, (Been-Chian Chien et al., Eds.) 5579:701-710.
10.1007/978-3-642-02568-6_71.
21. Hsieh şi Chiang,
2009
Iwata K, Onosato M (1994) Random Manufacturing System: a New Concept of manufacturing systems for
production to order. Annals of the CIRP 43:79–384.
22. Iwata şi
Onosato, 1994
JACK (2005) Intelligent Agents - Agent Manual. Agent Oriented Software, Carlton South, Victoria, Australia. 23. JACK, 2005
Jarvis J, Jarvis D, Ronnquist R, Jain LC (2008) Holonic execution: A BDI approach. Springer Verlag,vol. 106. 24. Jarvis et al.,
2008
Jensen K, Kristensen LM (2009) Coloured Petri Nets: Modeling and Validation of Concurrent Systems.Springer-
Verlag New York Inc.
25. Jensen şi
Kristensen, 2009
Leitao P (2004) An Agile and Adaptive Holonic Architecture for Manufacturing Control. Faculty of Engineering of
University of Porto (teza).
26. Leitao, 2004
Leitao P (2009) Agent-based distributed manufacturing control: A state-of-the-art survey. Engineering Applications
of Artificial Intelligence 22:979 – 991. doi:10.1016/j.engappai.2008.09.005
27. Leitao, 2009
Leitao P, Restivo F (2006) ADACOR: a holonic architecture for agile and adaptive manufacturing control.
Computers in Industry, 57:121-130.
28. Leitao şi
Restivo, 2006
Li X, Zhang C, Gao L, Li W, Shao X (2010) An agent-based approach for integrated process planning and
scheduling. Expert Systems with Applications 37:1256–1264.
29. Li et al., 2010
Mathews J (1995) Organizational foundations of intelligent manufacturing systems - the holonic
viewpoint.Computer Integrated Manufacturing Systems 8:237-243.
30. Mathews, 1995
61
Murata T (1989) Petri nets: Properties, Analysis and Applications. Proceedings of the IEEE 77:541-580.
doi:10.1109/5.24143
31. Murata, 1989
Nwana HS (1996) Software Agents: An Overview. Knowledge Engineering Review, 11:205-244.
doi:10.1017/S026988890000789X
32. Nwana, 1996
Okino N (1993) Bionic Manufacturing Systems. Flexible Manufacturing Systems, Past, Present, Future, Ed. J
Peklenik, CIRP, pp. 73–95.
33. Okino, 1993
Pascal C, Şutu M, Pănescu D (2009) On the communication mechanism in a robot based holonic manufacturing
system. Proceedings of 18th International Workshop on Robotics in Alpe-Adria-Danube Region, Romania,
ISSN 2066-4745 (pe CD)
34. Pascal et al.,
2009
Pascal C, Pănescu D (2010) A Study on the Holons’s Interaction for Manufacturing Flexibility. 14th International
Conference on System Theory and Control, pp. 361 – 366, ISSN 2068-0465, IEEE – Control Systems
Society.
35. Pascal şi
Pănescu, 2010
Pascal C, Pănescu D (2011) On resource allocation in a Holonic Manufacturing Execution System. 15th
International Conference on System Theory, Control and Computing, (acceptată spre publicare)
36. Pascal şi
Pănescu, 2011
Pănescu D, Kloetzer M, Burlacu A, Pascal C (2010) A multiagent based solution for mobile robots path planning.
14th International Conference on System Theory and Control, pg. 355 – 360, ISSN 2068-0465, IEEE –
Control Systems Society.
37. Pănescu et al.,
2010
Pănescu D, Kloetzer M, Burlacu A, Pascal C (2011) Artificial Intelligence based Solutions for Cooperative Mobile
Robots. Control Engineering and Applied Informatics Journal, (acceptată spre publicare)
38. Pănescu et al.,
2011
Pănescu D, Pascal C (2010a) Some issues on holonic systems analysis, design and implementation, 19th
International Workshop on Robotics in Alpe-Adria-Danube Region, pp. 199-204.
39. Pănescu şi
Pascal, 2010a
Pănescu D, Pascal C (2010b) On Resource Service Access in a Holonic Manufacturing System, Buletinul
Institutului Politehnic din Iaşi, Tom LVI (LX), Fasc. 3, Secţia Automatică şi Calculatoare, pp. 95 – 108,
2010, ISSN 1220 2169.
40. Pănescu şi
Pascal, 2010b
Pănescu D, Pascal C (2011a) HAPBA – a Holonic Adaptive Plan-Based Architecture. Service Orientation in
Holonic and Multi-Agent Manufacturing Control, Editori: Theodor Borangiu, Andre Thomas, Damein
Trentesaux, Studies in Computational
Intelligence, Springer (acceptată pentru publicare).
41. Pănescu şi
Pascal, 2011a
Pănescu D, Pascal C (2011b) On a holonic adaptive plan-based architecture: planning scheme and holons’ life
periods. International Journal of Advanced Manufacturing Technology (acceptată pentru publicare).
42. Pănescu şi
Pascal, 2011b
Pănescu D, Pascal C, Şutu M, Varvara G (2009a) Collaborative Robotic System Obtained by Combining Planning
and Holonic Architecture, Proceedings of AT-EQUAL 2009 (Advanced Technologies for Enhanced Quality
of Life), pp. 138-143. (ISI Proceedings)
43. Pănescu et al.,
2009a
Pănescu D, Şutu M, Pascal C (2009b) On the Design and Implementation of Holonic Manufacturing Systems.
Proceedings of The 2009 World Congress on Computer Science and Information Engineering, vol. 5, pp.
456-461.
44. Pănescu et al.,
2009b
Pănescu D, Varvara G, Pascal C, Sutu M (2009c) On the design and implementation of the resource holons in a
PROSA based architecture. Proceedings of the IEEE 13th International Conference on Intelligent
Engineering Systems , pp. 101-106. (ISI Proceedings)
45. Pănescu et al.,
2009c
Pănescu D, Varvara G, Sutu M (2008) On Holonic Manufacturing Systems and Implementation. Bul. Inst. Polit.,
Iasi. LVI (LX), 3-4, s. Automatic Control and Computer Science, pp. 49-74.
46. Pănescu et al.,
2008
Păstrăvanu O, Matcovschi M, Mahulea C (2002) Aplicatii ale Retelelor Petri în Studierea Sistemelor cu Evenimente
Discrete. Editura Gh. Asachi.
47. Păstrăvanu et
al., 2002
Pokahr A, Braubach L, Lamersdorf W (2005) Jadex: A BDI Reasoning Engine. In: Weiss G (ed) Multi-Agent
Programming 15:149-174. Springer US. doi:10.1007/0-387-26350-0_6
48. Pokahr et al.,
2005
Rao AS, Georgeff MP (1992) An abstract architecture for rational agents. Proceedings of knowledge representation
and reasoning, pp. 439-449.
49. Rao şi Georgeff,
1992
Rao AS, Georgeff MP (1995) BDI agents: From theory to practice. Proceedings of the first international conference
on multi-agent systems, pp. 312-319.
50. Rao şi Georgeff,
1995
Russell SJ, Norvig P (2009) Artificial intelligence: a modern approach. Prentice Hall (3rd ed.). 51. Russell şi
Norvig, 2009
62
Sihn W (1995) Re-engineering Through Fractal Structures. In proceedings of IFIP WG5.7 working conference Re-
engineering the Enterprise, pp. 21–30.
52. Sihn, 1995
Smith R (1980) The contract net protocol: High-level communication and control in a distributed problem solver.
IEEE Transactions on Computers 100:1104-1113. doi:10.1109/TC.1980.1675516
53. Smith, 1980
Spangler D (2008) A Vision of Holarchy. Seven Pillars. (accesat 2011)
http://www.sevenpillarshouse.org/index.php/article/a_vision_of_holarchy1
54. Spangler, 2008
Suda H (1989) Future Factory System Formulated In Japan. Techno Japan 22:15-25. 55. Suda, 1989
Talukdar SN (1999) Collaboration rules for autonomous software agents, Decision Support Systems, 24:269-278. 56. Talukdar, 1999
Trentesaux D (2009) Distributed control of production systems. Engineering Applications of Artificial Intelligence
22:971-978. doi:10.1016/j.engappai.2009.05.001
57. Trentesaux,
2009
Ueda K, Vaario J, Ohkura K (1997) Modelling of Biological Manufacturing Systems for Dynamic Reconfiguration.
Annual of the CIRP 46: 343–346.
58. Ueda et al., 1997
Valckenaers P, Van Brussel H, Bongaerts L, Wyns J (1997) Holonic manufacturing systems. Integrated Computer-
Aided Engineering 4:191-201.
59. Valckenaers et
al., 1997
Valckenaers P, Van Brussel H (2005) Holonic manufacturing execution systems. CIRP Annals-Manufacturing
Technology 54:427-432. doi:10.1016/S0007-8506(07)60137-1
60. Valckenaers şi
Van Brussel, 2005
Van Brussel H, Wyns J, Valckenaers P, Bongaerts L, Peeters P (1998) Reference architecture for holonic
manufacturing systems: PROSA. Computers in Industry 37:255-274. doi:10.1016/S0166-3615(98)00102-X
61. Van Brussel et
al., 1998
Varvara G, Pascal C, Pănescu D (2009) Service Oriented Architecture Considerations for Distributed Intelligent
Control of Modern Manufacturing Systems. Proceedings of the First International Conference on Modelling
and Development of Intelligent Systems, „Lucian Blaga" University Press, pp. 299 – 307, ISSN 2067 –
3965.
62. Varvara et al.,
2009
Warnecke HJ (1993) The Fractal Company, Springer, Berlin. 63. Warnecke, 1993
Weiss G (2000) Multiagent systems: a modern approach to distributed artificial intelligence. The MIT Press. 64. Weiss, 2000
Winikoff M (2005) Jack™ Intelligent Agents: An Industrial Strength Platform. In: Weiss G (ed) Multi-Agent
Programming 15:175-193. Springer US. doi:10.1007/0-387-26350-0_7
65. Winikoff, 2005
Wooldridge M (2001) Intelligent Agents. In: Weiss G (ed) Multiagent Systems. A Modern Approach to Distributed
Artificial Intelligence, pp 54-60. MIT Press, Cambridge
66. Wooldridge,
2001
Wooldridge M, Jennings N (1995) Agent theories, architectures, and languages: a survey. Intelligent agents, pp. 1-
39.
67. Wooldridge şi
Jennings, 1995
Wyns J (1999) Reference for holonic manufacturing systems – The key to support evolution and reconfiguration.
Katholieke Universiteit Leuven (teză).
68. Wyns, 1999
69. Xu et al., 2002