DEZVOLTAREA UNUI PROGRAM DE SIMULARE PENTRU CONTROLUL HOLONIC

dezvoltarea unui program de simulare pentru Controlul Holonic

Control orientat pe Agenti si Reguli

1 Introducere

Propunem o arhitectura ca solutie pentru controlul holonic al procesului. Un HDCS ( Holonic Discrete Control System) pentru proces trebuie sa indeplineasca controlul cooperarii Resource-HL, pentru a termina complet pasii de productie. Fiecare moment din coordonare ar trebui sa fie bazat pe decizia HDCS precedenta asupra momentului corect de coordonare, pentru a evita blocajele si / sau pentru a respecta prioritatile productiei. Pe scurt, un set de decizii ar trebui sa determina seturi potrivite de coordonari, care se numesc relatii cauzale.

Deciziile sunt luate prin evaluare propietatilor sistemului, folosind o cunoastere specializata asupra sistemul controlat.

Un set de relatii cauzale grupate si corelate intr-o singura entitate se numeste control monolitic, iar un set de entitati separate dar corelate, fiecare ocupandu-se de o relatie cauzala diferita, se numeste un control decuplat. Controlul holonic trebuie sa fie decuplat, compus din entitati decuplate precum soft-holons. Fiecare soft-holon este compus dintr-un subholon pentru partea deciziei din relatia cauzala, numit Conditie, iar alt subholon se va ocupa de partea concluziei, numit Actiune.

Entitatile de relatii cauzale sunt exprimate printr-un set de reguli, numite reguli de productie. Un sistem format din reguli, se numeste Rule Based System (RBS) si/sau Expert System (ES). Structural un ES este compus din probe despre sistemul observat, relatii cauzale ce specifica diferite solutii de a schimba probele, si un Interface Engine (IE) care le schimba eficient pe baza probelor si a regulilor, ce trec prin interfata de proces.

2 Control orientat pe reguli

O solutie de control orientata pe reguli permite expertilor umani sa proiecteze controlul si sa il inteleaga intr-un mod intuitiv, pentru ca este natural sa gandim in termeni de relatii cauzale precum regulile. Aceasta abordare este deci mai potrivita pentru problemele cauzate de implicarea oamenilor in proces, care este o problema importanta pe langa obtinerea agilitatii cand se vorbeste despre o solutie holonica.

3 Problemele solutiei de control

O solutie corecta de control trebuie sa aiba un grad bun de reactivitate, care este in directa legatura cu complexitatea computationala a procesului de inferenta. Complexitatea trebuie vazuta ca o problema importanta fata de procesul de inferenta a ES sau a RBS.

In IE pentru ES este importanta evitarea redundantelor temporale in procesul de alegere a regulilor si a probelor, de exemplu potrivirea probelor cu premisele ar trebui facuta o singura data in acest proces. Este importanta si evitarea redundantelor structurale, adica cunostintele despre premise ar trebui sa fie impartite corect intre obiectele ce reprezinta diferite reguli.

4 Holoni ca reguli

Un control orientat pe reguli poate fi compus dintr-un set de agenti, de exemplu un agent pentru incaspularea cunostinelor pentru fiecare regula. Astfel in aceasta abordare regulile nu trebuie considerate un de set de control de informatii intr-un bloc monolitic.

Fiecare regula poate fi eficient atribuita unui agent numit Regula, care tine si directioneaza independent cunostintele, permitand decuplarea regulilor.

Cunostinta unei reguli expert este esenta holonului Regula. Regula serveste la evaluarea Atibutelor in partea de decizie numita Conditie si investigheaza Metodele in partea numita Actiune.

O Regula de control se considera a fii adevarata cand determina momentul potrivit pentru colaborarea cu setul Resource-HL. Pe scurt, o Regula de control este responsabila pentru investigarea serviciilor intr-un Resource-HL, pentru a atinge cooperarea dorita, cand se aplica doua conditii: (1) se afla in starea de adevar (2) nu este in conflict cu alte reguli.

5 Colaboratorii regulilor

Premisele sunt subholoni conectati la Conditii, dar nu sunt componente agregate in Conditii. O Premisa colaboreaza in evaluarea Conditiilor cand primeste notificari de la una sau doua Atribute despre starea lor si le evelueaza.

Investigatiile sunt subholoni conectati la Actiuni, dar nu sunt agregate in Actiuni. O Investigatie colaboreaza in activitatea de coordonare a unei actiuni deoarece investigheaza una sau mai multe Metode pentru a executa aceste servicii, asigurand parametrii corecti si necesari pentru aceste Metode.

6 Structura regulilor

Figura 34 descrie un model de clasa holonica.Acest model contine clasele entitatilor resposabile cu cunoasterea regulilor.

Rule Holonic-Class are o relatie de agregare cu condition Holonic-Class si alta relatie de agregare cu Action Holonic-Class.

O Conditie este legata la un set de Premise. Fiecare Premisa cunoaste valoare discreta a unui Atribut numit Referinta, un operator logic numit Operator, si alta valoare, numita Valoare, care poate fi o constanta sau o valoare discreta a unui alt Atribut. Premisele fac un calcul logic comparand Referinta cu Valoarea, folosind Operatorul.

O Actiune este responsabila de o fractiune din toate coordonarile privind controlul cooperarii Resurse-HL. Actiunea este legata de Investigatii, instantele Instigation Holonic-Class, care colaboreaza cu ea pentru a isi ideplini responsabilitatile.

7 Sumarul procesului inference

Se propune un alt proces de inferenta, bazat pe colaborarea entitatilor decuplate: Atributele anunta numai Premisele implicate despre schimbarile de stare si Premisele anunta numai Regulile implicate despre schimbarile starilor, evitand redundanta temporala, si permitand astfel o inferenta rapida. Mai mult, impartirea colaborarilor ajuta la optimizare in procesul de notificare pentru ca elimina redundantele structurale. Pe scurt impartirea colaborarilor consta din:

Un set de Premise poate imparti colaborari cu Atribute si Conditiile pot imparti colaborari cu Premise.

Un set de Investigatii pot investiga aceeasi Metoda si Actiunea poate imparti colaborari cu Investigatiile.

8 Mecanismul de notificare

Mecanismul de informare are urmatoarele subtilitati:

Premisele primesc informari cu privinta la schimbarea starilor

Dupa ce o Premisa a primit o informare cu data privind o updatare a starii, va folosi aceasta informatie pentru a face o ocmparatie.

Daca noua valoare booleana sau stare a Premisei este diferita de valoarea precedenta, atunci Premisa va informa Conditiile interesate despre valoarea curenta.

Calculul logic a Conditiei este facuta prin conjunctia valorii booleene a tuturor Premiselor conectate. Daca rezultatul acestui calcul este adevarat atunci Conditia pune Regula respectiva in starea de adevarata.

9 Instanta de control.

9.1 Introducere

Controlul este de tipul Holonic Supervisory Control (HSC) pentru celula de resurse holonica. Aceasta celula produce doua produse virtuale. HSC este implementat ca un control bazat pe reguli si pe agenti, prin Reguli de decizie si Reguli de coordonare. In plus pentru a evita conflictele dintre Reguli s-a definit o politica in timpul constructiei HSC.

Regulile de coordonare

Un set de Reguli a fost creat pentru coordonarea cooperarii intre Resursele-HL, activand astfel productia V1 si V2.

Planul proceselor pentru V1 si V2 sunt definite mai jos, detailand astfel informatiile procesului legate de pozitia de buffer, informatii ce sunt folositoare pentru crearea Regulilor.

Fiecare Regula de coordonare considera un Transport-HL ce transporta un produs dintr-un loc in altul.

Reguli in conflict

Regulile din figura 37 au fost create in mod interlocker pentru a evita conflictele cauzate de impartirea Resurse-HL. De exemplu, toate Regulile folosesc Premisa "Puma560.1 Status = Free", dar numai o Regula aprobata ce poate investiga eficient serviciul de transport in Puma560.1 datorita restrictiilor fizice.

Un mecanism de rezolvare a conflictelor poate fi dezvoltat si implementat ca un conflict solver. Conflict solver ar percepe conflictele dintre Reguli ce invoca Resurese-HL si ar rezolva aceste conflice, acordand prioritate numai uneia din Regulile conflictuale.

Proprietatile Regulilor

Regulile sunt foarte asemanatoare. Singura diferenta dintre ele este cunoasterea fiecarei Premise (i.e. Referinta, Operatorul, sau Valoarea) si cunoasterea fiecararei Instigatii conectate, ca si a numarului de Premise si Instigatii conectate.

Entitatile similare faciliteaza atat intelegerea sistemului, ca si interactiunile din sistem.

Reguli decizionale

In aceasta instanta de control se presupune ca Depozitul este umplut cu elemente pentru produsele V1 si V2, intr-o pozitie corect predeterminata, dar Depozitul este complet gol. Astfel Regula 0 din figura 39     este elaborata pentru a semnala ca este nevoie de elemente noi. In mod normal Reguli din alta parte a holarchiei considera Atributul Status pentru a decide daca Depozitul trebuie incarcat.

Similar se presupune ca elementele din Table.3 Pos2 si din Table.2 Pos1 sau Pos2 ar trebui luate din celula de productie. Momentul exact pentru inlaturarea elementelor este calculata de Regula 1.1, Regula 1.2 si Regula 2.

Regulile prezentate evalueaza si schimba doar Atributele intr-un Resurse-HL. Astfel fiecare Regula poate fi agregata in respectivul Resurse-HL.

Aditional, Machining-Cell-HL ar putea avea Atribute care sa se ocupe de statusul intrarilor si iesirilor, care ar fi communicate Atributelor corespunzatoare incapsulate in Echipament-HL.

10 Compozitia Regulilor

O Regula este creata pentru a atinge o implicare logica relevanta a sistemului considerat, Crearea regulilor implica concentrarea pe un obiectiv specific. Primul pas necesar pentru crearea unei Reguli de coordonare este de a identifica activitatile implicate in respectivul pas de productie, <operation into the Lathe.1>. Aceste activitati sunt:

- Transportarea elementului din Table2P.1 Pos2 la Lathe.1 via ERIII.q

- Pregatirea Lathe.1 pentru producerea elementele de tip V2

Activitatile identificate servesc ca baza pentru definirea partii de decizie a Regulii. Compozitia decizii este intai implicata in definirea Premiselor corespunzatoare pentru evaluarea conditiilor necesare pentru executarea activitatilor.

Dupa ce Premisele au fost definite, Condtiile trebuie create unde Premisele sunt conectate. Dupa ce partea decizionala este elaborata, trebuie elaborata si concluzia bazandu-se pe activitatile identificate anterior. Compozitia concluziei este intai implicata in definirea Instigatiilor potrivite.

Dupa definirea Instigatiilor, trebuie create Actiunile unde Instigariile sunt conectate. In sfarsit trebuie creata Regula ce contine Conditia si Actiunea.

Pentru compozitia Conditiei, trebuie deterinat daca Premisele nu exista deja in holarchie. Daca exista deja, este conectata la Conditie, altfel ea este creata, conectata la Conditie, si introdusa in holarchie.

Pentru compozitia Actiunii, aceeasi idee este aplicata si la Instigatii. Aceasta tehnica permite impartirea informatiilor si colaborarilor, care contribuie in dinamicile interactiunilor holonilor.

Cand se creaza Premisa, cel putin un Atribut este considerat Referinta sa. Dupa ce un Atribut este referinta intr-o Premisa, Premisa este considerata automat de catre Atribut ca interesat in statusul sau, astfel o va anunta de orice schimbare.

Similar, cand o Premisa este conectata la o Conditie, Premisa considera automat ca acea Conditie este interesata sa primeasca anunturi referitoare la schimbarile de stare.

In inferenta de proces propusa, informatiile inferentei sunt luate de la formatia de Reguli, decat sa fie descoperite in timpul executiei, ca in cazul inferentei de proces bazate pe metode de cautare.

11 Regulile si Agilitatea

Un sistem de fabricatie (MS) este considerat agil daca timpul de raspuns este mic in relatie cu cererile productiei. Adaptabilitatea productiei se refera la abilitatea de a exploata flexibilitatile activate in MS. Flexibilitatea ar trebui exploatata, de exemplu, pentru a optimiza productia, sau pentru a tolera mai bine erorile de sistem. Exista mai multe tipuri de flexibilitati intr-un sistem, de exemplu: flexibilitatea de buffer, de transport si de procesare.

Flexibilitatea de buffer si cea de transport sunt considerate pentru folosirea locurilor de depozitare si a rutelor de transport alternative. Flexibilitatea de procesare se refera la folosirea resurselor artenative de procesare pentru a produce diferite tipuri de produse.

Agilitatea productiei depinde de cunoastintele despre Reguli, Regulile pot fi imbunatatite pentru a suporta schimbarile din sistem, cu scopul de a obtine adaptabilitate prin mentinerea agilitatii. De exemplu introducerea tipului de produs V1.2 in familia V1, produs de Machine-Tool.1.

Modificarile Regulilor sunt bazate pe un plan de proces definit.

Practic, mai multe informatii despre proces sunt incluse in Reguli, permintand acestora sa faca un control adaptat, pentru a exploata posibilele flexibilitati ale MS,

Un alt exemplu de imbunatatire a Regulilor este cazul in care in sistem este adaugat un Lathe secund. Acest Lathe ar fi conectat prin ERRIII, cum se prezinta in figura 41. In acest caz sistemul ar avea o flexibilitate mai buna, lucru folositor pentru producerea elemetelor de tip V1.

Pe langa adaugarea cunostintelor corespunzatoare Regulilor, exista alte mijloace de a investiga pentru exploatarea flexibilitatii. O cale ar fi folosirea altor entitati pentru activarea si dezactivarea Regulilor sau stabilirea prioritatilor in Reguli, daca se considera ca un conflict solver a fost stabilit. De exemplu:

numai parti din tipul V1 si V1.2 sunt produse, Regulile privind tipul V2 se pot dezactiva

Daca partile pentru V1.2 trebuie produse cu prioritare, Regulile privind Stocarea lor vor avea prioritatile modificate.

Acest tip de manipularea a Regulilor este inteles ca adaptare cu scopul de a mari agilitatea. Manipularea Regulilor poate fi facuta si de alti holoni, precum cei de flow management, ce stiu ce produse sunt produse si in ce ordine.

12 Consideratii

RBS si EX au determinat solutia controlului holonic pentru aceasta teza. Din punctul de vedere holonic, o proprietate folositoare a controlului unui RBS este intergrarea umana din moment ce regulile cauzale sunt o modalitate umana de gandire.

In abordarea propusa, controlul agilitatii poate fi obtinut prin includerea cunostintelor potrivite in Reguli si prin manipularea lor in functie de schimbarile prioritatilor si a validitatilor.

Pentru a obtine o solutie bazata pe reguli pentru controlul holonic, s-a propus ca inferenta procesului sa fie bazata pe decuplarea agentilor pentru cunoastere cauzala. Un agent numit Regula trateaza fiecare regula ca o entitate specifica. Cunostintele Regulii sunt organizate folosind agenti colaboratori. Ei impart informatii si evita redundantele din inferenta procesului. Inferenta procesului orientata pe notificari inlocuieste metodele standard de cautare. Cuplarea regulilor in inferenta procesului facut de metodele de cauitare poate complica deschiderea sistemul de control pentru a ajunge la implementare distribuita, care este scopul intr-un sistem holonic de control.

Holonic Supervisory Controlol ( HSC) a fost implementat folosind abordarea propusa si executata folosind ANALYTICE II cu resurse holonice. Regulile si colaboratorii au fost implementati pentru construirea HSC.

Arhitectura a fost implementata intr-un mod nedistribuit. Totusi poate fi aplicata si pe un sistem distribuit datorita decuplarii intre Reguli si baza de fapte. Mai multe detalii sunt prezentate in capitolul urmator.

Regulile ce au Conditii si Actiuni similare, cu aceeasi colaboratori, sunt considerate un tipar pentru decizie si coordonare in aceasta solutie de control. Comanda si monitorizarea au fost tipizate prin Atribute si Metode ale Resurse-HL. Aceste doua tipare sunt folosite pentru tiparul arhitectural al sistemelor de control discrete.

Ideea principala a acestei abordari este de a defini un proces de inferenta diferentiat si eficient executat prin entitatile de control, si aplicarea acestei abordari prin prelucrarea relatiilor cauzale de control peste Resurse-HL omogenizate, cu scopul de a obtine solutia de controlul holonic cu deschidere catre caracteristica de corectitudine.

Capitolul 5: Control Holonic

5.1 Introducere

In acest capitol, prima sectiune prezinta structura sistemului de productie ca esenta a RBS. Aceasta permite o intelegere efectiva a arhitecturi propuse pentru control ca un tip de arhitectura RBS.

Solutia procesului de inferenta, bazat pe anunturi, prezinta un set de proprietati folositoare pentru atingerea caracteristicii de corectitudine a sistemului de control holonic.

Proprietatile sunt urmatoarele:

* posibilitatea unei implementari distribuite, nedistribuite sau mixe, datorita decuplarii entitatilor si a complexitatii computationale reduse

* identificarea si rezolvarea conflictelor prin mecanisme bazate tot pe mesaje

* fezabilitatea folosirii unui formalism de control al evenimentelor discret, mai exact Retelele Petri care sunt compatibile cu RBS.

5.2 Rule Based Systems

5.2.1 Introducere

Multe din Sistemele Expert de scala mare precum sustemul CLIPS de la NASA sunt bazate pe conceptul Sistemelor de Productie (PS). Compozitia PS-urilor este de obicei urmatoare:

o memorie de lucru (WM) pentru date si evenimente

o memorie de productie (PM) pentru reguli.

un motor de inferenta (IE) pentru procesul de inferenta

Un IE implica noi evenimente, prin potrivirea regulilor si a evenimentelor existente, inserandu-le in WM. Noile evenimente permin noi inferente, si acest ciclu se termina cand nu mai exista evenimente ce pot fi potrivite.

Un ES sau RBS poate fi considerat un PS datorita ciclului de operare a IE-urilor. Acest ciclu consta in trei pasi numiti potrivire, selectie si executie, cum sunt prezentate in figura 42. Acest pasi sunt structura PS-ului:

pasul de potrivire propaga ultimile evenimente in WM si gaseste ce reguli trebuie activate determinand un set de conflicte, numit si agenda

pasul de selectie ordoneaza regulile in agenda, folosind parametrii, si regulile cu o punctuatie mai buna sunt, in ordine, selectate din agenda

executia efectueaza actiunile determinate de regulile selectate. Aceste actiuni pot insera noile evenimente in WM sau invoca functii.

5.2.2 Motorul de inferenta

Pentru aplicatiile RBS in ES-urile de scala larga, este nevoie de polite avansate pentru construirea IE-uli evitanda exploziile exponentiale, pregum retelele Rete propuse de Forgy. O retea Rete elimina redundantele temporale, in timp ce redundanta structurale este eliminata pentru premise simple, dar nu si pentru premise combinate. La o premisa simpla un "atribut de obiect" este comparat cu o constanta, in timp ce la o premisa combinata cu doua "atribute de obiecte" sunt corelate prin comparatie.

Algoritmul Rete implementeaza un proces de cautare optimizat, plasand toate componentele regulilor intr-o retea de sortare structurata pe arbori.

5.2.3 Evitarea cautarilor

Folosirea distributiei controlului este motivata de cateva avantaje din sistemele computationale distribuite, ce sunt folosite pentru pastrarea agilitatii sistemului. Un exemplu folositor ar fi evitarea opririi sistemului cand o parte a sistemului de control nu este activa. De asemenea exista si alte beneficii, precum o robistete la elimnarea erorilor prin redundanta entitatilor. De exemplu , Regulile proiectate in Figura 44 ar putea fi clonate in alte locuri fizice cu scopul de a inlocui matrigea de Reguli ce s-ar afla in stare de inoperabilitate, pastrand astfel sistemul operabil.

Pe scurt, implementarea unui control bazat pe reguli ca unul agil ar trebui sa cuprinda o politica de inferenta ce faciliteaza distributia entitatilor de control. Trebuie sa se permita totusi si implementari nedistribuite.

Metodele uzuale aplicate pentru motorul de inferenta in RBS folosesc un fel de cautare pentru potrivirea Regulilor si a Faptelor. Cel putin baza faptelor este implicit distribuita in MS. Cautarile dintr-o baza de fapte distribuita spot fi mai complicate decat in una centralizata. Dezavantajele ar putea fi:

cresterea in timp a ciclului de inferenta datorita factorilor ca timpul folosit pentru schimbul de informatii intre punctele din retea si chiar pentru rezolvarea erorilor de comunicatie

cresterea traficului retelei in relatie cu complexitatea computationala a metodei de cautare folosita pentru procesul de inferenta

Procesul de inferenta definit in arhitectura controlului holonic trebuie sa evite metodele de cautare. Arhitectura pentru un control agil trebuie sa fie distribuita. Acest lucru este un prim argument pentru procesul de inferenta bazat pe mesaje. Folosind mesajele, cautarile in setul de date nu mai sunt necesare. Astfel entitatile atentioneaza direct alte entitati, fiind mai independente functional si reducand nevoia generala de comunicare. Prin faptul ca aceste mesaje se transmit fara a tine cont de localizarea destinatiei, face ca aceasta metoda sa fie folosita atat pentru sistemele distribuite cat si pentru cele nedistribuite.

5.2.4 Principiul mesajelor

Conceptul mesajelor este un element cheie in dezvoltarea procesului de inferenta propus unde regulile si faptele sunt entitati computationale. In cazul faptelor, faptele foarte legate sunt incapsulate si folosite de un agent numit Atribut. Aceste fapte, stari sau valori legate de un Atribut definesc statile discrete posibile, ce sunt prezentate in figura 45

Un set de Atribute ce fac referinta la aceeasi entitate, intr-un sistem observat, poate fi transformat intr-un Agent Bazat pe Fapte (FBA) ce devine Atributele respective. De exemplu toate Atributele referitoare la o masina specifica pot fi incluse intr-un FBA specific.

Atributele atentioneaza Premisele si Premisele atentioneaza Conditiile Regulilor ca in figura 46. Cand Conditia unei Reguli este dovedita, atunci respectiva Actiune va fi efectuata. Cand o Actiune este efectuata, Instigatiile corespunzatoare sunt activate, iar ele la randul lor instiga Metodele ce pot schimba starile Atributului.

Procesul de inferenta propus este unul rapid deoarece nu foloseste cautari, dar foloseste propagarea mesajelor de la Atribute, prin Premise, catre Reguli, ajungand la Actiuni. In aceasta abordare a procesului de inferenta, elementele sunt agenti independent din punct de vedere functional. Aceasta independenta se datoreaza mecanismului de mesaje, care este in acelasi timp o solutie pentru implementarea sistemelor distribuite.

5.3 Complexitate Computationala

5.3.1 Introducere

In cazul arhitecturilor implementate intr-un mod distribuit, performanta sistemului este legata de numarul de comunicatii si de gradul de paralelism al executiilor Acesta este la randul lui legat de gradul real de distributie al agentilor.

In cazul in care arhitectura este implementata intr-un mod nedistribuit, poate fi importanta a se lua in considerare complexitatea computationala pentru a garanta functionalitatea si reactivitatea buna, garantand astfel o performanta corespunzatoare. De fapt intr-o implementare nedistribuita fiecare resursa virtuala se ocupa si trimite mesaje numai pentru faptele corespunzatoare.

5.3.2 Analiza asimptotica a Complexitatii

Analiza complexitatii computationala a arhitecturii poate fi facutat folosind analiza amsimptotica. Pentru aceasta trebuie luat in considerare numarul n de mesaje dintre Atribute si Premise si dintre Premise si Reguli in fiecare ciclu.

Cel mai rau caz al propusului algoritm, toate Atributele atentioneaza toate Premisele si acestea atentioneaza toate Regulile. T_worst(x)=x³, unde x este numarul de elemente notificate. Complexitatea computationala O() este in acest caz O(n³). Acest caz nu este totusi realistic.

Analiza complexitatii unui caz obisnuit incepe prin analizarea expedierii unui mesaj a unui Atribut.

FB_AT()=NumPremises+NumRules

NumPremises este suma Premiselor conectate la Atribute si NumRules este suma Regulilor conectate la fiecare Premisa din Num Premises. In medie avem deci:

T_medium(x)=(FB_AT.1()+ . +FB_AT.w()/w, w este numarul tuturor Atributelor existente. Rezultatul este o constanta, ce implica complexitatea O(n).

5.3.3 Complexitate si Timp

Analiza complexitatii intr-o implementare nedistribuita poate fi mai precisa cand consideram alte Atribute implicate in momentul declansarii transmiterii mesajului Atributelor. Ecuatia urmatoare se refera la sintetizarea Atributului AT in momentul i.

F_AT(i)=NumPremises_(i)+NumRules_(i)+F_AT(i-1), cu i > 0.

NumPremises_(i) este suma Premiselor conectate la AT, in momentul i

NumRules_(i) este suma Regulilor conectate la fiecare Premisa numarata in NumPremises_(i) la acelasi moment i

F_AT(i-1) este gradul de complexitate referitoare la Atributele sintetizate inainte de AT, respectiv in momentele dinainte de i-1 pana la 0.

Partea F_AT() din ecuatie are urmatoarele proprietati:

F_AT(0) poate fi interpretat ca amintire a complexitatii lui AT. F_AT(0)=NumPremises₍₀₎+NumRules₍₀₎, adica cel mai rau caz

F_AT(i) este NumPremises_(i)+NumRules_(i) cand nu exista Atribute sintetizate inainte de AT la momentul i

F_AT(i-1) are o tendinta la medie mica faca algoritmul este aplicat in contextul in care faptele sunt schimbate intr-nu mod independent si orientat pe timp, ca in cazul sistemului de fabricatie.

Numarul β al Premiselor si Regulilor neimplicate in ecuatia F_AT(i) este indiferent la complexitatea schimbarii starilor a Atributelor implicate in momentul i. Ecuatia prezinta solutia propusa ca o complexitate a fiecarui Atribut sintetizat, la momentul I, numai intre (K+0) si (K+α), cu K = NumPremises_(i)+NumRules_(i) si α= F_AT(n-1), unde α are o tendinta de complexitate mica sau nula.

5.4 Corectitudinea controlului

5.1 Introducere

Acum solutia controlului a fost detaliata, cateva detalii generice despre arhitectura au fost discutate. Totusi sunt si alte probleme ce trebuie discutate precum deschiderea solutiei catre mecanismul de implementare pentru identificarea si rezolvarea conflictelor, reactivitate versus determinism, si anumte trasaturi de robustete.

5.2 Problemele de conflict

O problema importanta ce trebuie rezolvata pentru arhitectura controlului propus este identificarea si rezolvarea conflictelor. In cazul holonic, conflictele sunt legate de Resursele-HL impartite. De exemplu Robot-HL poate fi folosit de doua Resurse-HL distincte. In cazul solutiei de control propuse, fiecare activitate de cooperare a Resurse-HL este controlata de o Regula specifica. Astfel , Regulile pentru cooperare implicate in impartirea Resurse-HL sunt potential conflictuale. In cazul in care nu exista un mecanism de interblocare, este necesar sa definim unul de indentificare si rezolvare a conflictelor.

Se va crea un tip special de Atribut pentru Resurse-HL impartite, numit Exclusive-Atribut, ce este o expresie de folosire exclusivista a Resurse-HL impartite. Se va dezvolta si un tip special de Premise, numit Exclusive-Premise.

O Exclusive-Premise colaboreaza in aprobarea unui conflict potential de Reguli si in tratarea problemelor conflictuale. Pentru a identifica conflictul, de fiecare data cand o Conditie conectata la o Exclusive-Premise face un calcul logic, anunta Exclusive-Premise de schimbarea starii. Dupa fiecare anunt referitor la starea Conditiei, Exclusive-Premise are un numarator care se incrementeaza sau decrementeaza corespunzator. Pe scurt, daca e adevarat se incrementeaza altfel se decrementeaza. Cand numaratorul este mai mare decat unu, atunci apare o situatie de conflict. Aceasta poate fi rezolvata de Exclusive-Premise sau trimisa catre Conflict-Solver-HL.

Cand Exclusive-Premise rezolva singura conflictul, foloseste prioritatilr Conditiilor pentru a lua o decizie. Cand conflictul este rezolvat de catre Conflict-Solver-HL, Exclusive-Premise foloseste solutia propusa de catre Conflict-solver-HL pentru a rezolva conflictul. Conflict-Solver-HL ar putea fi un Holonic Flow Management (HFM) ce joaca rolul unui organizator on-line.

Mecanismul propus pentru rezolvarea conflictelor poate fi considerat unul potrivit, deoarece nu influenteaza procesul de inferenta din moment ce genereaza putine mesaje. Mai mult, implementarea acestui mecanism poate facilita compozitia controlului si mecanismul poate fi incadrat in crearea Regulilor.

5.3 Reactivitate si Determinism

O alta problema se refera la controlul discret, mai exact la gasirea unei cai de mijloc pentru reactivitate si determinism. Reactivitatea este legata de timpul de raspus al controului in timp ce determinismul este legat de evolutia determinista a controlului si decizia determinista:

* evolutia determinista se refera la toate entitatile din relatia cauzala ce trebuie sa aiba aceeasi oportunitate de a evalua schimbarile de stare aparute la o decizie determinista

* decizia determinista se refera la decizia luata ce trebuie sa fie la fel intr-o situatie ce are aceleasi informatii de evaluare.

Se propune un mecanism pentru evolutia determinista in procesul de inferenta propus unde Atributele asteapta confirmarea mesajelor de la Premise si Premisele asteapta mesaje de confirmare de la Conditii. Acest mecanism se refera atat la implementari distribuite cat si secventiale si cuprinte un set de pasi:

Fiecare Conditie care a fost anuntata confirma primirea si folosirea informatiilor primite catre Premisa corespunzatoare.

Fiecare Premisa ce a fost anuntata confirma primirea si folosirea informatiilor primte catre Atributul corespunzator.

Fiecare Conditie aprobata intreaba fiecare Atribut ce se gaseste in Premisele colaboratoare daca si-a terminat activitatea de mesaje.

Fiecare Atribut intrebat raspunde Conditiilor interesate daca si-a terminat de trimis mesajele.

Fiecare Conditie aprobata cu toate confirmarile necesare referitoare la terminarea mesajelor, anunta Regula corespunzatoare ca este aprobata

Acest mecanism garanteaza ca toate Regulile sunt updatate cu noile fapte deoarece Conditiile sunt fortate sa isi astepte toti evaluatorii. Mai mult, acest mecanism poate fi incadrat in crearea Regulilor, crescand complexitatea computationala cu doar cateva constante.

O imbunatatire in rezolvarea erorilor de comunicare ar putea fi crearea unui pas intermediar inainte de pasul 1. Acest pas ar fi: a) fiecare Premisa ce este anuntata de Atribut preconfirma anuntul; si b) fiecare Atribut reanunta toate Premisele permitanda stfel anuntarea Conditiilor.

5.4 Proprietatile Robustetii

Proprietatile robustetii sunt legate de toleranta erorilor si evitarea lor si de asemenea sunt legate de trasatura corectitudinii. Pentru robustetea controlului si toleranta la erori se considera entatiati redundante ce se pot substitui entitatilor principale in cazul in care acestea devin inoperabile. Un exemplu este cel de clonare a Regulilor. Regulile clonate sunt asemanatoare cu cele principale cu diferenta ca au Actiunile dezactivate. Actiunile sunt activate cand Regulile principale devin inactive. Totusi trebuie creat un dinamism intre Regulile clonate si Regulile principale.

Acest dinamism va permite anuntarea clonelor ca Regulile principale sunt dezactivate. De asemenea daca clonele nu primesc nici un mesaj de la Regulile principale se vor activa automat considerand ca Regulile principale sunt inactive.

Se presupune ca acest control distribuit faciliteaza functia de balansare, din moment ce entitatile functioneaza independent. O balansare buna poate ajuta in robustete prin optimizarea comunicatiilor si chiar prin procesare, garantand si redundanta entitatilor in locuri diferite.

5.5 Formalismul pentru Expresia Controlului

5.5.1 Introducere

Reteaua Petri (PN) este o unealta generica ce permite modelarea sistemelor discrete distribuite intr-un mod grafic si simularea comportamentului elementelor in aceasta structura grafica. In unele clase ale PN este posibilia analiza matematica a unor proprietati de sistem.

Retelele Petri sunt notificari formare pentru modelarea si analizarea sistemelor distribuite si concurente, si sunt aplicate in multe domenii. PN sunt considerate o familie de de formalisme care asigura framework si paradigme functionale folositoare pentru proiectarea si operarea in problemele sistemelor de productie.

5.5.2 Regulile si Retelele Petri

PN pot fi considerate un RBS in logica propozitionala si ca retelele Predicate-transitions pot fi considerate RBS in logica de ordine. Un exemplu de PN este prezentat in figura 52. PN este compusa din tranzitii ce au pozitiile conecatae prin sageti orientate.

Dupa declansarea unei tranzitii, pozitiile de input pierd un numar specific de tokenuri si pozitiile de output primesc un numar de tokenuri. Tokenurile in pozitii sunt ca o baza de fapte in timp ce tranzitiile T₁ . T_n sunt ca regulile R₁ . R_n.

O regula R are urmatoarea forma R Q, unde P si Q sunt antecedentul si consecinta. Pentru fiecare regula R o structura echivalenta se poate gasi intr-o retea Petri. De exemplu in figura 52 aceasta PN reprezinta regula R, care, daca este adevarata, faptele antecedente sunt negate si noile fapte sunt generate.

5.5.3. Playerul pentru Reteaua Petri

Exista o preocupare legata de "distanta" dintre modelul de control PN si implementarea controlului. Prima problema este legata de modelul de control high-level al MS, proiectat cu PN, ce considera fiecare resursa a MS intr-un high-level fara a se preocupa de detalii precum monitorizare si comanda. Acest lucru poate fi rezolvat prim omogenizarea resurselor si integrarea lor high-level, prin Resurse-HL. Astfel starea Atributelor din Resurse-HL poate fi folosita pentru marcarea Pozitiilor, de exemplu starea ocupat sau liber a unui Atribut poate fi marcarea unei pozitii numita Status.

O alta preocupare este ca implementarea IE se face folosind metode de cautare pentru potrivirea faptelor cu regulile in timp ce PN este conceptual bazata pe sintetizarea tranzitiilor in legatura doar cu marcarea pozitiilor respective. Aceasta diferenta poate genera anumite distante intre PN si implementare. Arhitectura propusa prezinta potrivirea Regulilor prin mijlocare de anuntare numai cu privire la starea elementelor interesate, similar deci cu conceptul PN.

5.5.4 Rularea Retelei Petri

PN prezentate in figurile 53 si 54 sunt folosite pentru a modela controlul aplicat al coordonarii Resurse-HL simulate in ANALYTICE II. Fiecare Regula este ca o Tranzitie si fiecare set de Pozitii este ca un Atribut din Echipament-HL.

Procesul de inferenta executat prin mijloace de anuntare intre elementele de control permite simularea PN. La schimbarea starii unui Atribut(marcare), Regulile(tranzitiile) corespunzatoare sunt anuntate prin Premise(Arce). Astfel fiecare Tranzitie stie daca o Pozitie este marcata sau nu, adica daca un Atribut a ajuns in starea dorita sau nu.

Procesul descris permite simularea tranzitiilor sintetizate deoarece fiecare Tranzitie poate sti daca marcajul de care are nevoie pentru declasare este atins doar prin anunturile primite de la Pozitii. PN prezinta de asemenea o P-temporizare a unor Pozitii, ce se refera la timpul in care Resurse-HL executa o Metoda. Pentru a simula aceasta P-temporizare, Atributul modificat de acest tip de Metoda poate aproba o Regula dar trebuie sa transmita mesaje pentru a dezaproba o Regula.

Astfel fiecare Metoda a Resurse-HL pune respectivul Atribut intr-o stare intermediara si genereaza intern o comanda pentru simularea echipamentului respectiv. In starea intermendiara Atributul nu poate permite nici unei Reguli sa fie aprobata, dar permite Regulii sa fie deazaprobata.

Dupa ce Metoda termina executia, permite Atributului sa ajunga in starea efectiva. Acesta transmite anunturile corecte catre Regulile interesate. Acest mecanism permite emularea P-temporizarilor

5.5.5 Reteua Petri si Generalitatile Solutiei

Daca o parte a arhitecturii controlului poate fi rulata in PN, cu structurile fundamentale, atunci se indica generalitatile solutiei ce poate fi executata in coordonare cu Sistemul Discret de Evenimente (DES) . Experimentul prezentat anterior reprezinta structrura fundamentale a PN.

Aditional, o implementare alternativa a fost facuta subretelei in PN prezentat in figura 53. Implementare a fost facuta folosind doar doua Reguli, ca in figura 55. Totusi s-a stabilit o ordine pentru iesirea tokenurilor din Store.1. O alternativa la luarea tokenului ar putea insemna o politica random, fara a considera controlul deterministic.

Un player PN se dezvolta acum la LSIP folosind o adaptare a programului C++ folosit pentru a executa exemplul de control din capitolul trecut. Pentru acest player, implementare entitatilor din aceasta arhitectura in threaduri separate are scopul de a obtine un anumite grad de paralelism.

5.5.6 Agilitatea si Reteaua Petri

Cand instanta de control este modelata folosind modelul PN, ca un pas in proiectare, este posibila rularea acestei PN pentru observarea comportamentului cu referire la agilitate. De exemplu, PN prezentata in figura 53 poate fi rulata si analizata pentru a observa daca exista flexibilitate sau alternative de productie pentru o anumita piesa, in cazul in care resursa preferata este ocupata.

Din acest punct de vedere cand un sistem primeste o resursa aditionala, aceasta trebuie considerata in proiectarea controlului. De exemplu, in figura 56, PN se schimba la introducerea noi Resurse-HL (Lathe.2), unde flexibiliatea noului scenariu poate fi observata ruland PN marita. Din punct de vedere al controlului, asta inseamna mai multe Resurse-HL (pozitii) si Reguli (tranzitii) pentru o exploatarea a noii flexibilitati.

Daca sistemul de control ar fi implementat luand in considerare modelul PN, atunci ar avea flexibilieatea observata in modelul PN, inainte de implementare. Arhitectura propusa prezinta o anumita natura tendentioasa pentru sistemele care ruleaza precum PN.

5.5.7 Arhitectura Playerului

Pentru ca PN sa fie o metoda buna de modelare a instantelor a arhitecturii de control propuse, arhitectura este interpretata de asemenea ca arhitectura playerului pentru PN standard. Se doreste ca aceasta interpretare a arhitecturii de control sa fie folositoare pentru intelegerea mai buna a executiei acestor instante in rualrea PN si pentru a aproxima rularea PN si conceptul de executie a controlului propus.

Arhitectura ar trebui interpretata in felul urmator:

fiecare transmisie este prelucrata ca o Regula unde: a) setul de sageti input sunt Conditii; b) setul de sageti output sunt parti din Actiune

fiecare pozitie este prelucrata ca FBA (acum numit Poztie) ce are: a) doar un Atribut numit Token-Number; b) numai doua Metode numite Put-Token si Get-Token

fiecare tranzitie sageata input este prelucrata ca Premisa unde: a) numarul de tokenuri necesare este Valoarea b) Token-Number a Pozitiei este Referinta c) Operatorul este tot timpul un operator de comparatie

fiecare tranzitie sageata output este prelucrata ca un tip de Instigatie care: instigeaza un Put-Token folosind ca parametru numarul de token a respectivei sageti output

fiecare tranzitie sageata input este prelucrata tot ca o Instigatie careL instiga la Get-Token al unei Pozitii folosind ca parametru numarul de token a sagetii input

fiecare parte secunda a Actiunii este compusa dintr-un set de Input-Arrow-Its

fiecare FBA ar putea fi vazut ca un set de Pozitii relatate.

Aceasta interpretare a arhitecturii de control descrie, de fapt, o mapare restrictiva la arhitectura playerului PN. PN standard pot fi rulate folosind aceasta arhitectura. Maparea ar putea fi imbunatatita prin permiterea rularii altor clase din PN, ca PN termporizata, daca aceste clasa nu au permisiunea deja in arhitectura propusa de control.

In cazul in care arhitectura ia in considerare temporizarea in tranzitii, fiecare Tranzitie ar trebui declansata numai dupa un timp predefinit. In cazul in care arhitectura ia in calcul temporizarea in pozitii, Token-Number a fiecarei Pozitii sintetizate ar trebui anunta Premisele corespunzatoare numai dupa o perioada de timp determinata.

Pozitia ar fi sintetizat real numai putea perioada te timp in care respectivele Resurse-HL au lucrat. La finalul executiei Metodelor, metoda Put-Token ar primi semnal de final pentru a activa sintetizarea Pozitiilor. In acest fel , controlul va fi facut intr-o maniera ascunsa in executia PN, ca un tip de PN interpretat. De fapt, deviatia arhitecturii de control la arhitectura playerului PN se intoarce la aplicatia de control dar nu la natura PN.

5.6 Sumar

Solutia propusa in aceasta lucrare are cateva proprietati potrivite pentru controlul holonic. Compozitia, schimbarea si intelegerea cunoasterii Regulilor sunt naturale pentru gandirea umana. Integrarea umana este legata de integrarea sistematica a cautarilor in HMS.

In aceasta solutie de control deschisa, potentiala cunoastere a Regulilor si integrarea sistematica permit atingerea obiectivelor de agilitate, cat si exploatarea flexibilitatii MS. Solutia prezinta elementele de baza pentru a compune instante de control agil peste Resurse-HL ca cele testate in ANALYTICE II.

Conceptul de entitate Regula si colaborarile acesteia respecta implicit compromisul intre toti (holos) si specifici (on) in sistemele holonice. Mecanismul de inferenta este generic si aplicabil direct. Pe scurt, solutia prezinta o caracteristica meta implicand generalitati si aplicabilitati, fiind considerat un meta-model.

Mesajele dintre agenti permit imitarea unui comportament distribuit interiorul implementarii nedistribuite. Mecanismul de anuntare permite atingerea unor alte caracteristici de corectitudine, ca mecanisme aditionale de tratare a conflictelor si a determinismului si de asemnea    expresiei de control de formalism DEC.

Un mecanim pentru conflicte, bazat pe mesaje a fost propus pentru conlucrarea cu procesul de inferenta bazat pe anunturi. De asemenea un mecanism pentru evolutie deterministica a fost definit pentru imbunatatirea procesului de inferenta.

Aditional, mecanismul de atentionare este similar cu rularea unei retele PN. Compatibilitatea este oportuna deoarece regulile cauzale pot fi considerate un formalism de control express.

Se presupune ca solutia propusa poate fi folosita pentru a prelucra anumite clase de sistem DEC in care PN si relatiile cauzale sunt folosite ca unealta de modelare. Meta-modelul prezentat este considerat deschis catre corectitudine si caracteristici holonice a caror existenta au fost testate in ANALYTICE II.