Implementarea algoritmilor IPAC
Īn acest capitol, sunt prezentate rezultatele cercetarilor īn domeniul analizei si al rationamentului cauzal, pentru determinarea modelului cauzal al circuitului si al functionarii lui. Astfel, sunt stabilite modelele primare ale componentelor si arborele de functiuni - comportament - structura, īn care fiecare rezolvator de problema este constituit īntr-un agent inteligent, care actioneaza īn conformitate cu regulile din baza de cunostinte.
Caracteristicile modelului ingineresc
Procesul de proiectare, īn acceptiunea ingineriei concurente, este un proces de evolutie a metamodelelor. Astfel, solutia proiectarii poate fi privita ca o evolutie a specificatiilor de proiectare, iar specificatiile de proiectare - ca o mapare inversa a solutiilor.
Metamodelul este modelul obiectului "proiect", caracterizat printr-un numar finit de atribute, care da un cadru de descriere al modelului definit ca entitate. Specificatiile de proiectare sunt descrise prin topologia functiei de conceptie a setului de entitati "concept", iar solutia este descrisa prin topologia conceptelor atribut. Stadiile intermediare ale procesului de proiectare determina īntregul proces evolutionist īn care proiectantul confirma daca specificatiile de proiectare sunt satisfacute sau nu de catre "candidata" la solutia de proiectare.
Īn timpul procesului de evolutie al proiectarii, descrierea metamodelului este detaliata, creāndu-se modele intermediare, si cantitatea de informatie este īn crestere, metamodelul creānd modelul corespunzator fiecarei faze si generānd o metoda de descriere unitara de date. Īn fiecare faza, proiectarea progreseaza īn asa fel īncāt proiectantul alege un model intermediar (varianta metamodelului) si apoi, cel rezultat din evolutia lui????. Deci, descrierea metamodelului si structura lui se schimba dinamic si īn mod corespunzator cu evolutia activitatii de proiectare.
Astfel, faza de proiectare conceptuala corespunde elaborarii structurii metamodelului si fixarii scopurilor sau solutiilor temporare ale proiectarii. Apoi, procesul de proiectare continua si se verifica, īn cadrul evolutiei proiectului, daca scopul propus satisface specificatiile date. Daca acesta nu este corespunzator, metamodelul este schimbat cu unul nou, mai potrivit specificatiilor date. Aceasta schimbare se face asistat de expert. Exista situatii cānd este preferabil sa se pastreze metamodelul si sa se rezolve cerintele utilizatorului. Ambele procese necesita rationamente facute pornind de la un scop dat la cauzele sale originale (backward reasoning). Cunostintele care controleaza procesul de rationament sunt un amestec de experienta si logica, iar cele utilizate īn procesul de luarea deciziilor este fragmentar, īn special, īn faza de proiectare conceptuala.
Astfel, un sistem bazat pe metamodel trebuie sa dispuna de posibilitatea de a descrie metamodelul, domeniul, modelul curent, evaluarea lui, de a construi o structura de metamodel din specificatiile date, de a suporta evolutia metamodelului, adica detalierea acestuia, de a conduce evaluarea modelului curent, utilizānd metamodelul si domeniul de actiune
Principalele trasaturi a modelului sunt: includerea multitudinii surselor de cunostinte care trebuie utilizate pentru rezolvarea problemei la diferite niveluri de abstractizare sau detaliere, asigurarea cooperarii si comunicarii īntre modele instantiate si rezolvarea diferentelor.
Doua componente diferite, structura si atributul, reprezinta modelul.
Structura este un set de relatii īntre componentele obiectelor; printre ele, conceptul de structura ierarhica fiind indispensabil īn conceptul de model.
Atributul este un termen generic de reprezentare a diferitelor aspecte ale obiectelor cum ar fi caracteristica, functia, comportamentul etc.
Īn schema generala de modelare, sunt utilizate 3 tipuri de concepte:
structura ierarhica pentru reprezentarea relatiilor multinivel obiect - comp 343j98d onente,
graful de reprezentare a setului de relatii omogene, existent īntre entitatile aflate pe acelasi nivel īn structura ierarhica, si
predicatul logic pentru a reprezenta orice atribut sau relatie, care nu poate fi reprezentat prin conceptele anterioare.
Astfel, modelul de proces se poate reprezenta folosind structuri de date, ce implica aceste concepte si unde atributele pot fi adaugate, sterse sau actualizate fara sa afecteze celelalte componente sau caracteristici ale modelului. Modelul se poate mari sau micsora īn cadrul aceleiasi reguli de structurare.
Analizarea unei probleme prezentate sub forma de obiect specific, caracterizat de o structura data, de relatiile īntre componente, de atribute si comportamente cu caracter dinamic, se realizeaza īn mai multe etape:
se genereaza, asistat de calculator, modele generale de reprezentare īn acord cu regulile ingineresti, date si informatii incluse, implicit īn modelul primar, prin instantierea acestuia;
se reduc posibilitatile de generare ipotetica de modele ineficace prin introducerea modulelor de propagare a restrictiilor
se determina solutiile de rezolvare iterativa pentru fiecare faza de detaliere a modelului si, īn final, se realizeaza programe specifice.
O caracteristica a modelului este aceea ca trebuie sa asigure accesul simultan al mai multor proiectanti, ca si posibilitatea de a permite accesul automat la colectiile de date relationale si experimentale pentru generarea si achizitia cunostintelor.
Deci, problema care se pune este aceea de a gasi o metoda generala de modelare a procesului, care sa poate defini si genera diferite tipuri de modele si sa poata manipula metode, si nu cea de a gasi modele specifice subproblemelor existente īn fiecare faza a procesului de proiectare, deci, o schema generala de modelare analizānd metodele folosite si extragānd principiile ce privesc metoda de reprezentare a modelului.???? Datorita existentei diferitelor structuri de date, formalizate si dinamice structural, este necesara o functie de mapare īntre acestea.
Schema generala de modelare a procesului proiectare se bazeaza pe stabilirea ierarhiilor de clasificare pentru:
informatiile structurale si atributive - functionale si de comportament,
conceptele de "vedere" (viewpoint),
analiza strategiilor si a obiectivelor.
Nodurile īn cadrul ierarhiei reprezinta o componenta sau o functie sau un comportament, iar arcele sunt relatii de mostenire clasa-subclasa. Selectarea unei clase sau a unei componente din ierarhie determina nivelul de generalitate sau de detaliere a proiectarii (īn urma procesului de instantiere). Localizarea īn ierarhia de clasificare reprezinta conceptul de "viewpoint" si depinde de punctul de vedere din care este privit proiectul - structural, de comportament etc.
Obiectivele determinate de proiect sunt asociate componentei, functiei, comportamentului, deciziilor de proiectare etc. Obiectivele sunt structurate īn subobiective, stabilirea acestora constituind sarcina expertului. Acestea sunt īnlantuite īntre ele prin relatii de precedenta.
"Viewpoint"-ul unui obiectiv reprezinta localizarea acestuia pe un nod al ierarhiilor de clasificare, iar "domeniul nominal" al lui este partea de proces aferenta.
Analiza strategiilor foloseste aceste relatii analizānd ierarhia functionala pentru a stabili "conectarile" functionale vecine, punctele de "articulatie", care divizeaza domeniul si caile posibile de conectare (alternative).
Problema care se pune este aceea de a gasi o functie de mapare īntre strategiile disponibile, "domeniul nominal" si "viewpoint"-ul aferent. De aici, rezulta necesitatea de a structura strategiile īn pasi.
Elementul de originalitate īl constituie crearea unui mediu multiagent, care cuprinde domeniu structura, functiuni, comportament (FCS) ce mapeaza īntre ele, mediu cu rezolvatori rationali, care coopereaza īntre ei.
Īn continuare, este prezentata proiectarea inteligenta pentru modulul solar al unei surse fotovoltaice, utilizānd modelarea de tip FCS.
Proiectarea propriu zisa īncepe cu:
structurarea informatiei īn raport cu problema de rezolvat (definirea marimilor de intrare si rezultatele proiectarii primare, algoritmice, ale circuitului (topologia circuitului, alura marimilor de iesire);
definirea claselor aferente structurii, functiunilor si comportamentului ce caracterizeaza proiectul; atributele si relatiile dintre clase;
crearea modelului cauzal pentru descompunerea de tip Functiuni - Comportament - Structura si definirea regulilor de proiectare sau de simulare a functionarii;
executarea motorului de inferenta si determinarea solutiei simbolice primare;
stocarea solutiei īn baza de cunostinte.
Pentru achizitia si elicitarea cunostintelor (crearea ierarhiei proiectului si a arborelui FCS structura - functiuni-comportament) s-a folosit Visual Basic; pentru reprezentarea cunostintelor mediul de programare M4, realizat īn C.
7.1. Crearea proiectului
Crearea modelului proiectului se realizeaza īn urmatorii pasi:
definirea claselor aferente structurii, functiunilor si comportamentului; atributele si relatiile dintre clase;
realizarea descompunerii ierarhice de componente si functiuni;
crearea modelului cauzal pentru descompunerea de tip Functiuni - Comportament - Structura;
crearea bazei de cunostinte (definirea variabilelor si claselor sau stabilirea regulilor atāt pentru componenta, cāt si functiuni
7.1.1. Definirea Ierarhiilor (structura, functiuni, comportament)
Definirea ierarhiei se face specificānd nodurile acesteia si caracteristicile, precum si instantierile lor. Definirea sau actualizarea unei ierarhii presupune actualizarea nodurilor, a legaturilor ce se stabilesc īntre noduri, precum si a informatiilor asociate elementelor.
Nodurile unei ierarhii reprezinta abstractizari structurale pentru concepte, evenimente, stari. Arcele reprezinta relatiile de descriere a conceptelor, relatiile dintre concepte si componentele lor, dintre concepte si instantele la clase, dintre obiecte si actiuni, dintre componente si modalitatile de atasare la concepte. Astfel, informatiile asociate nodurilor ierarhiei sunt de genul: tipul nodului din ierarhie, valorile elementelor conexe etc.
Pentru definirea sau actualizarea unei structuri ierarhice se apeleaza la baza de cunostinte sau baza de date, specifice modelului, pentru a se verifica corectitudinea/compatibilitatea variantelor īn raport cu solutia initiala. Daca o noua legatura este introdusa īn ierarhie, utilizatorul dispune de posibilitatea de a alege din meniu functiile īnrudite si atributele corespunzatoare.
Īn urma definirii noii ierarhii, corespunzatoare structurii, utilizatorul va avea posibilitatea de a testa compatibilitatea noilor functii definite, putānd alege diferite variante propuse. Īn cazul īn care una sau mai multe alternative propuse au functii compatibile, se poate solicita īncarcarea bazei de cunostinte a noilor atribute si instantele lor.
Īnregistrarea definitiei unei ierarhii se face prin prelucrarea īn program a pozitiei pe ecran a unei descrieri sau ierarhii, a continutului determinat prin cuvinte cheie, a īnlantuirii admise a meniurilor si/sau ferestrelor, a dreptului la acces la anumite portiuni din baza de cunostinte pentru a extrage informatii spre a fi vizualizate.
Descrierea ierarhiei se face pentru tipurile de ierarhii, si anume: structura, functiuni, comportament. Structura unei ierarhii este definita īn anexa.
Īn continuare, sunt prezentate structurile de date,
manipulate de ierarhii.
Arborele de structura
7.1.2. Modelarea FCS (Functiuni Comportament Structura)
Un prim pas īn "obtinerea solutiei" este parcurgerea ierarhiilor, ceea ce presupune extragerea subarborilor din toate arborescentele referitoare la o anumita problema.
Cautarea īn arbori, īntr-o secventa predeterminata, pentru care cautarea propriu-zisa este segmentata pe verticala (īn adāncime) sau orizontala, se desfasoara astfel: se porneste de la "radacina" sau de la un nod arbitrar, altul decāt radacina, si se traverseaza graful de la un nivel la altul prin urmarirea arcelor. Procesul continua pāna la un nod dorit sau nodul "frunza". Daca nu s-a ajuns la obiectiv, iar nodul nu are nod_fiu, controlul se īntoarce la nodul_parinte si, de acolo, la urmatorul nod_fiu.
Modalitatea de realizare presupune asocierea la fiecare nod a unui pointer catre nodul sau parinte. Cānd obiectivul este gasit, calea de atingere a acestuia este determinata prin parcurgerea īnapoi, ghidata de secventa pointer-ilor.
Īn rezolvarea problemei, se "expandeaza" nodurile ce au fost atinse, dar nu au fost expandate, si se marcheaza. Nodurile_fiu sunt introduse īn lista, īntr-o prioritate bine determinata, īn functie de parintele de care apartin.
Grafurile partiale rezultante se numesc grafuri candidate. Un arbore este evaluat si expandat repetat prin determinarea nodurilor candidate solvabile si expandarea lor propriu-zisa. Grafurile candidate expandate sunt tinute īn liste deschise pentru a fi combinate cu alte grafuri.
Evaluarea grafurilor presupune un proces de examinare: daca nodurile terminale ale unui arbore candidat corespund unei probleme rezolvate, se marcheaza. Daca punctele terminale ale unui graf candidat sunt puncte finale ale problemei initiale, si nu noduri terminale, problemele corespunzatoare acestui arbore sunt insolvabile (un singur nod_fiu determina un graf partial la un moment dat - procesul de backtracking).
Modalitatea de achizitie a cunostintelor prin analiza si elicitarea acestora este una din trasaturile principale īn modelarea procesului de proiectare. Prin elicitare se defineste modalitatea de a extrage cunostintele, indiferent de metoda, pentru ca sa poata fi usor analizate si grupate pe ierarhii sau similitudini. Cunostintele īn domeniul proiectarii, caracterizate de multitudinea surselor, neuniformitatea lor si dinamica īn evolutia modelului, trebuie sa fie prezentate īntr-un format inteligibil pentru expert, sa fie verificate, testate, clasificate īn ierarhii pe domeniu si interpretate, ca apoi, sa fie reprezentate īn baza sau bazele distribuite de cunostinte.
Elicitarea cunostintelor se face prin mai multe procedee:
abstractizarea si interpretarea inteligenta, de catre expertul sau expertii īn domeniu, a informatiilor utile, transferate īn mod selectiv, īn functie de similitudini, din bazele de date constituite de aplicatiile analitice ale sistemului;
introducerea de catre expertul sau expertii īn domeniu a faptelor, atributelor sau regulilor īn baza unei grile repertoar specifice (repertory grid), organizate pe niveluri de abstractizare si similitudini.
Analiza cunostintelor conduce la inductia de reguli sau concepte (inductive learning) si la construirea de arbori de ierarhizare/ clasificare de concepte cu relatiile de mostenire aferente.
Arborele FCS rezultant al maparii domeniilor structura - functiuni si comportamente pentru sursa fotovoltaica.
Obiective
Obiective
Comportament Componente Functiuni
7.1.3. Reprezentarea cunostintelor de proiectare (crearea bazei de cunostinte
Problema principala ramāne īn domeniul modelarii si reprezentarii cunostintelor (datorita diversitatii, cantitatii mari de informatie, neuniformitatii si a posibilitatilor mari de expresie), precum si īn domeniul conceptelor legate de ea cum ar fi: achizitia cunostintelor prin analiza si elicitarea lor, utilizarea si īntretinerea acestora, mecanismul de inferenta īn conditiile de concurenta a rezolvarilor de probleme. Problemele inferentei si controlului ei sunt īn relatie directa cu īnsesi caracteristicile de gāndire ale proiectantului, precum si de comportament ale acestuia īn fazele de proiectare (decizii, rationamente, justificari), caracteristici care sunt observate si analizate pentru a se regasi apoi printre functiile sistemului
Īn continuare, sunt prezentate caracteristicile sistemelor de reprezentare a cunostintelor folosite īn modelarea procesului de proiectare.
Reprezentarea prin obiecte si relatii īntre obiecte
Īn procesul de proiectare, conform principiilor de analiza si descompunere proprii ingineriei concurente, diversitatea problemelor si aplicatiilor de proiectare conduce la o mare diversitate de tipuri de expresii ale obiectelor, fapt ce impune generarea acestora printr-o metoda de descriere unitara de date. Aceasta conduce la necesitatea construirii unui model de date evolutionist, caracterizat de schimbari dinamice si care este capabil:
sa descrie entitatile, relatiile dintre ele, structura ierarhica a acestora,
sa fie potrivit pentru controlul inferentei, si
sa corespunda metamodelului domeniului si a evaluarii acestuia, adica modelului curent.
Cunostintele euristice, achizitionate de la experti, sunt constituite īntr-un model "mental" al cunostintelor de catre inginerul de cunostinte. Pentru a face modelul mental mai tangibil, acesta este rafinat la un nivel intermediar de cunostinte pentru a fi utilizat īn procesul de comunicare cu expertii si de validare a presupunerilor lor. Īn literatura, aceasta este definita ca fiind diagrama Ishikawasi, folosita ca o metoda de rezolvare a problemei bazate pe rafinarea de tip top-down pentru descompunerea problemei īn subprobleme mai simple.
Ea este utilizata pentru: structurarea domeniului problemei, determinarea specificului cunostintelor euristice de achizitionat de la experti si organizarea lor īn ierarhii si identificarea sablonului (pattern) de inferenta.
Reprezentarea cunostintelor pentru inferenta se poate face folosind metode dezvoltate de ingineria de cunostinte cum ar fi circuite semantice, sisteme bazate pe reguli, sisteme bazate pe frame-uri sau sisteme bazate pe logica sau logica intuitiva. Alegerea unei metode de reprezentare trebuie sa corespunda scopului propus, si anume:
sa reprezinte empiric si logic informatia structurata īn mod unic;
sa descrie obiectele proiectarii cu o structura care se poate schimba īn timpul proiectarii;
sa nu distinga diferenta dintre specificatiile de proiectare, exprimate īntr-un limbaj apropiat de cel natural, si solutiile de proiectare, care contin informatii atributive.
O problema importanta, care trebuie rezolvata de modulul de reprezentare a cunostintelor, este verificarea completitudinii si consistentei cunostintelor. Altfel spus, un utilizator care nu este expert īn proiectare, si foloseste sistemul, poate introduce informatii eronate, informatii ce necesita confruntarea cu regulile corecte, existente īn baza de cunostinte. Deci, trebuie ca sistemul sa furnizeze functii care sa permita expertului īn proiectare, nespecialist īn programare, sa scrie reguli fara greseli. Un verificator automat de reguli este mult mai dificil de realizat, deoarece sistemul bazat pe reguli īsi schimba starea tranzitionala īn mod dinamic. Īn aceasta situatie, solutia este aceea de restrāngere a cadrului problemei.
Intrarile relevante īn baza de cunostinte sunt: faptele, metafaptele si regulile. Ele sunt utilizate pentru a obtine informatii din baza de cunostinte si sunt testate īn ordinea producerilor lor īn baza de cunostinte. Cānd o intrare relevanta se produce, motorul de inferenta o utilizeaza pentru a stabili informatia.
Faptele furnizeaza valori pentru expresii. Metafaptele furnizeaza informatii sau directii pentru determinarea altor informatii (de ex., īntrebarile).
Regulile sunt de forma premisa atunci concluzie īn care premisa poate fi constituita din propozitii sau metapropozitii ce contin starea consultarii. Īn urma producerii unei reguli, se pot extrage toate concluziile posibile sau inferenta poate sa se opreasca la o singura concluzie sau supozitie. Concluziile se noteaza īn memoria cache.
Īn afara de intrarile descrise, reprezentarea cunostintelor se face prin utilizarea variabilelor, structurilor si listelor. Variabilele sunt folosite īn reguli, fapte si metafapte pentru procesul de instantiere si inferenta (pattern-matching). Pe lānga acestea, sunt utilizate variabile de domeniu (anonime).
Structurile sunt de forma functor si componentii lui, si anume:
clasa
Motorul de Inferenta
Īn aceasta procedura, se balanseaza criteriile de analiza solicitate si se determina valorile asociate pentru fiecare criteriu; intrarea este constituita din baza de cunostinte si optiunile utilizator. Inferenta se realizeaza pe baza regulilor de inferenta din procedura, utilizānd regulile din baza de cunostinte. Din multimea regulilor ce se refera la aceeasi problema, trebuie selectata regula cea mai potrivita. Aceasta este o situatie diferentiala, care se produce īntre instantele aceleiasi reguli si dintre reguli diferite, care candideaza cu succes la solutie ca urmare a aplicarii mesajului.
Rezolvarea diferentelor se face pe baza informatiilor din context (baza de reguli sau biblioteca de strategii) utilizānd numarul de utilizari si coeficientul de utilitate sau ponderea acordata unor reguli printr-un mecanism de evaluare a prioritatilor.
Propagarea si rezolvarea diferendului se face dupa urmatoarea structura:
diferent
Inferenta consta īn maparea īntre arborescente pentru extragerea subarborilor aferenti problemei, selectia din baza de reguli si fapte, filtrarea lor, controlul datorat valorii de adevar al conditiei, rezolvarea diferentelor.
O problema importanta īn inferenta o constituie discordanta dintre obiectivele problemei, complexitatea arborilor ce descriu modelul, dificultatea executarii algoritmului de extragere a subarborilor, existenta regulilor, faptelor si metodelor disponibile īn baza de cunostinte.
Definirea claselor si a obiectelor
Definirea claselor consta īn interpretarea ierarhiilor utilizate de inginerul de cunostinte prin marcarea componentei unei probleme, a caracteristicilor, legaturilor si a atributelor ce definesc problema.
Pentru fiecare clasa:
se asociaza un nume si adresa de regasire (nume ierarhie, numar nivel, numar nod);
se definesc clasa "parinte" de pe nivelul imediat superior din ierarhie sau clasele "parinte" pentru cazul īn care mostenirea se face de la clase (ierarhie) diferite numite superclase;
se definesc slot-urile*)
Prin slot se defineste perechea obiect - atribute asociate.
Definirea claselor-obiect consta īn stabilirea metodelor/mesajelor pentru o clasa. O data cu crearea instantelor, se creeaza o mapa a slot-urilor ce contine lista tuturor slot-urilor si a valorilor lor pentru instanta la care au fost definite īn cadrul clasei proprii sau a superclaselor. Un slot poate fi accesat chiar daca a fost eliminata definitia superclaselor sau a slot-urilor.
Redefinirea claselor se face īn urma consultarii. Instantele create pe baza definitiei anterioare nu sunt actualizate. Cānd o clasa este redefinita, se marcheaza toate subclasele corespunzatoare clasei ca invalide. La trimiterea unui mesaj catre o clasa invalida sau catre o instanta a unei clase invalide se reface lantul de superclase si mapa slot-urilor.
Slot-urile noi sunt definite o data cu definitiile de noi clase. Ele nu sunt valabile pentru vechile instante, nefiind prezente īn mapa slot-urilor pentru acele instante.
Crearea instantelor unei clase se poate face static, prin declaratie, realizāndu-se si legatura instantei la o clasa, sau dinamic, īn timpul consultarii, prin trimiterea unui mesaj nou catre clasa.
Instantele create pot fi sterse. stergerea unei instante statice ramāne valabila numai pe perioada consultarii, dupa care ea este recreata conform definitiei. Instantele create dinamic se sterg īn timpul consultarii. O instanta statica poate fi si ea schimbata prin trimiterea unui mesaj la instanta īn timpul consultarii. Astfel, se construieste o mapa a tuturor instantelor legate de slot-urile dintr-o clasa.
Relatia de mostenire se transmite instantei nou create, la toate slot-urile si valorile initiale de la prima clasa din lantul de superclase. Slot-urile fara valoare initiala sunt declarate necunoscute.
Definirea metodelor se face īn legatura cu mesajele ce urmeaza a fi rezolvate la nivelul claselor sau al instantelor. Instanta sau clasa primeste un mesaj pentru crearea unei noi instante a unei clase (noua instanta "margineste" variabila corespunzatoare clasei) si atribuie valoare unui slot corespunzator unei clase.
Algoritm de creare a unei metode:
se verifica daca instanta respectiva are metoda definita pentru rezolvarea mesajului;
īn cazul īn care nu are metoda definita, se "traverseaza" lantul superclasei corespunzatoare clasei sau instantei si se verifica daca prima clasa/instanta are definita metoda;
daca nici la nivelul acesta nu este definita metoda, se defineste o metoda noua.
Daca mesajul este multivaloare, se executa toate metodele definite.
Definitia metodei se poate schimba prin modificarea clasei īn ierarhie. Metodele definite la clasa_obiect sunt mostenite de toate instantele pentru ca aceasta este o superclasa pentru toate instantele. Fiecare clasa sau instanta poate avea propriile definitii de metode, desi, īn mod curent, o metoda este definita la o superclasa.
Metoda poate fi poate fi definita ca procedura sau ca regula. Metoda care reprezinta cunostinta euristica este definita ca o regula. Metoda care reprezinta cunostinta strategica sau pasii de rezolvare a unei strategii este definita ca o procedura.
Metoda definita ca procedura este apelata īn mesaj cu argumente (aceleasi ca si īn definitia metodei). Definirea metodei se face pornind de la expresiile ce reprezinta specificatiile de mesaj, reprezentate de numele clasei sau al instantei si numele mesajului. Mesajul este urmat de corpul procedurii corespunzatoare metodei. Īn acest fel, mesajul precum si metodele de rezolvare se aplica clasei si subclaselor din ierarhie. Metoda poate rezolva determinarea valorii unei expresii, crearea unei instante, schimbarea valorii pentru slot-ul unei instante, trimiterea mesajului la o instanta, atribuirea valorilor pentru o variabila.
Metoda definita ca regula īntoarce o valoare conform specificatiei de mesaj.
Lucrarea de fata īsi propune sa creeze mediul de dezvoltare a unui instrument de asistare a proiectantului īn procesul de conceptie, utilizānd principiile ingineriei concurente, punāndu-se accent pe construirea modelului de reprezentare a cunostintelor si pe strategiile de cooperare pentru rezolvarea diferentelor utilizānd cunostintele expertului, stocate īn baze de cunostinte tehnice.
Instrumentul proiectat se ocupa de problematica legata de modelarea proiectarii ingineresti, asistate conform conceptiei ingineriei concurente, respectiv, analiza strategiilor de evaluare a unui proiect. Īn continuare, vom analiza, din punct de vedere functional si structural, modelele care compun instrumentul de proiectat.
Descompunerea problemei de proiectare īn subdomenii si subprobleme, stabilirea specificatiilor si a obiectivelor pentru fiecare subdomeniu sau subproblema constituie functiile modulului de analiza si elicitare a cunostintelor. Tehnica de elicitare va conduce la determinarea obiectivelor pentru fiecare agent, a solutiei de aplicat pentru reprezentarea cunostintelor si a tehnicilor de mapare a acestora īntre diferite domenii, si va stabili situatiile diferentiale si strategiile de aplicat. Sistemul contine aplicatiile analitice proprii proiectarii asistate (de exemplu, Spice) si bazele de date constituite de aceste aplicatii. Modulul de elicitare si analiza a cunostintelor va realiza abstractizarea si interpretarea inteligenta a informatiilor utile, transferate īn mod selectiv, īn functie de similitudini, din aceste baze de date si introducerea de catre expertul īn domeniu al faptelor, atributelor sau regulilor īn baza unei grile repertoar specifice (repertory grid), organizate pe niveluri de abstractizare si similitudini.
Cunostintele de tip structural, functional sau atributiv, ce apartin expertului īn domeniu, au o structura ierarhica si sunt reprezentate ca modele-obiect cu caracter dinamic, instantiate īn procesul de proiectare. Modelarea procesului de proiectare este realizat de modelatorul sistemului si de modulul de reprezentare a cunostintelor. Sistemul de reprezentarea a cunostintelor va fi de tip MBR (Model Based Reasoning) pentru controlul analizei idealizarilor īn proiectarea asistata, urmānd ca versiunile ulterioare sa foloseasca tehnicile de tip CBR (Case Based Reasoning). Pentru analiza strategiilor de evaluare a unui proiect, se utilizeaza reprezentarea cunostintelor de tip RBS (Rule Based Reasoning).
Strategiile de rezolvare a problemelor dintr-un domeniu si cele de evaluare a proiectelor sunt reprezentate ca reguli si restrictii (constrāngeri) care pot sa fie folosite fie pentru generarea accesului automat la baza de date tehnice, fie pentru generarea unei solutii extrase din procesarea modelelor sau interpretarea regulilor. Tehnica de inferenta folosita este de tip "backward chaining" (de la obiectiv, se determina specificatiile corespunzatoare) si de tip "forward chaining" (plecānd de la specificatiile determinate īn urma procesului de tip backward, se determina subobiectivele necesare atingerii obiectivului).
Īn urma generarii, īn baza de cunostinte, a regulilor conform modelului FCS al proiectului, se obtin o multitudine de alternative de solutionare a proiectului. Proiectantul poate alege, īn functie de cazul particular, o anumita alternativa īnsotita de explicatii adecvate. Īn urma inferentei regulilor reprezentate īn baza de cunostinte a proiectului, se determina solutii alternative īn urmatorii pasi:
selectarea componentelor din arborele de structura, folosind legaturile catre arborele de functiuni asociat;
zona de procesare
reguli/ afisare rezultate zona de fapte
selectare componentei selectate pentru anumite obiective
S-a avut īn vedere transpunerea algoritmilor de descompunere a proiectului, de reprezentare a cunostintelor si de procesare a acestora pentru reteaua Internet.
Achizitia de cunostinte si evaluarea cunostintelor
Plecānd de la clasele definite, se construieste ierarhia proiectului cu definirea structurii si a legaturii cu arborele de functiuni si comportament asociate.
Crearea arborelui Functiuni Comportament Structura
Crearea viewpoint-ului proiectului, la un obiectiv dat
Ca urmare a testarii variantei Visual Basic - M4, s-a constatat ca exista mari probleme pentru programarea modulelor de legatura īntre cele doua medii, precum si pentru transpunerea aplicatiei īn reteaua Internet.
De aceea, s-a recurs la utilizarea mediilor de programare Visual C++ si Clips.
Mediul Clips (C Language Integrated Production System) dateaza din anul 1984 si este creatia echipei de la Centrul Spatial Jonson NASA. La acea data, Sectia de Inteligenta Artificiala a dezvoltat peste o duzina de prototipuri de aplicatii sistem expert, utilizānd cele mai bune produse hardware si software. Cu toate acestea, īn ciuda īncercarilor repetate de a demonstra potentialul sistemelor expert, putine din aceste aplicatii au intrat īn cotidian. Esecul s-a datorat, īn principal, utilizarii pe scara larga a limbajului LISP ca baza a dezvoltarii sistemelor expert. Acest fapt aducea o serie de dezavantaje: imposibilitatea folosirii limbajului LISP pe majoritatea calculatoarelor conventionale, costul ridicat al instrumentelor LISP si slaba integrare a limbajului LISP cu alte limbaje.
Din aceasta cauza, s-a decis ca folosirea limbajului C va elimina multe din aceste inconveniente. Īn anexa, sunt prezentate caracter??????
CLIPS-ul este proiectat pentru a facilita dezvoltarea de software destinat modelarii cunostintelor si experientelor umane
Exista trei modalitati de reprezentare a cunostintelor īn CLIPS:
reguli (rules), care sunt destinate, īn principal, pentru cunostinte euristice, bazate pe experienta;
functii definite si functii generice (deffunctions, generic functions), care sunt destinate, īn principal, cunostintelor procedurale;
programarea orientata - obiect, care este destinata pentru cunostinte procedurale; cele cinci trasaturi ale conceptului de programare orientata-obiect si suportate de CLIPS sunt: clasa, metoda (message-handler), abstractizarea, īncapsularea, mostenirea si polimorfismul; regulile pot avea potriviri de pattern-uri sub forma de obiecte sau fapte.
Se poate dezvolta un software utilizānd numai reguli, obiecte sau o mixtura de obiecte si reguli.
Limbajul orientat - obiect integrat īn CLIPS (CLIPS Object-Oriented Language) este un hibrid īntre diferite sisteme OOP, dar contine si multe idei noi. De exemplu, conceptul de īncapsulare este similar celui din Smalltalk, iar Common Lisp Object System (CLOS) ofera regulile mostenirii multiple. O mixtura formata din idei from Smalltalk, CLOS si din alte sisteme formeaza fundamentul pentru mesaje.
COOL ofera saptesprezece clase sistem: OBJECT, USER, INITIAL-OBJECT, PRIMITIVE, NUMBER, INTEGER, FLOAT, INSTANCE, INSTANCE-NAME, INSTANCE-ADDRESS, ADDRESS, FACT-ADDRESS, EXTERNAL-ADDRESS, MULTIFIELD, LEXEME, SYMBOL si STRING. Utilizatorul nu poate modifica sau sterge aceste clase.
Īn plus fata de clasele predefinite, pentru aplicatia noastra au mai fost introduse urmatoarele clase utilizator: DISPOZITIV, DIODA, BATERIE, AMPLIFICATOR-INVERTOR, CONTROLDC, MODUL_SOLAR, SISTEM_DE_PROTECTIE, MATRICE_SOLARA, SUSTINERE, CELULA_PHOTOVOLTAICA, FUNDATIE, PANEL
Toate aceste clase sistem cu exceptia INITIAL-OBJECT sunt clase abstracte, ceea ce īnseamna ca unica lor folosire este pentru mostenire (crearea de instante direct din aceste clase este ilegala). Nici una din clase nu are atribute si, cu exceptia clasei USER, nici una nu are handlere de mesaje. Clasele definite pentru aplicatia noastra mostenesc direct din clasa USER, deoarece aceasta clasa are atasate toate handlerele de mesaje (message-handlers), cum ar fi initializarea si stergerea. Īn anexa, sunt descrise caracteristicile limbajului CLIPS.
Descrierea interfetei de prezentare a rezultatelor
Interfata este īmpartita īn trei zone care corespund celor trei clase Visual C++: CStructuraSplitFrame, CFunctiaSplitFrame si CElectricCASEView.
Prima fereastra corespunzatoare clasei CStructuraSplitFrame are asignata o clasa CStructuraFormView, īn care s-a introdus un obiect antet corespunzator clasei CDialogHeader, si un control OCX Structura_Circuit, care afiseaza imaginea structurii de ansamblu a circuitului.
La apasarea butonului mouse_dreapta, apare un meniu din care se poate
opta pentru vizualizarea structurii unui circuit_bloc (circuitul Control DC,
Amplificator Invertor DC-AC sau Modul Solar). Aceste circuite de detaliu se
modifica īn functie de stadiul curent de executie al rutinelor
CLIPS, ele depinzānd de parametrul de iesire din libraria CLIPS.DLL
A doua fereastra corespunzatoare clasei CFunctiaSplitFrame are rolul de a prezenta functiunile circuitului prin intermediul unui control OCX Functie_Circuit. Controlul OCX primeste ca intrare rezultatele rularii comenzilor CLIPS, el modificāndu-si starea īn functie de iesirea modulului CLIPS.DLL.
Ultima fereastra corespunzatoare clasei CElectricCASEView cuprinde controale pentru modificarea comenzilor CLIPS, pentru vizualizarea codului CLIPS si pentru afisarea rezultatelor furnizate de CLIPS.DLL.
Īn continuare, este prezentata diagrama succesiunii a trei momente semnificative corespunzatoare modelului de functiuni si comportamente asa cum rezulta din procesarea motorului de inferenta al mediului CLIPS
Paginile urmatoare contin capturile ecranelor īn urma procesarii cunostintelor al modelului FCS al sursei fotovoltaice.
Figura 25b. Executia CLIPS pentru moment_timp=zi, iluminare=maxima
Figura 26b. Executia CLIPS pentru moment_timp=zi, iluminare=mica.
Figura 27b. Executia CLIPS pentru moment_timp=noaptea
7.2. Rationament bazat pe "cazuri"
Rationament bazat pe "cazuri" īsi propune sa utilizeze solutiile problemelor anterioare pentru dezvoltarea solutiilor noilor probleme. Principalul avantaj al acestei abordari este acela ca, la aparitia unei probleme similare, sistemul de rationamentul bazat pe "cazuri" nu reface rationamentele din setul initial de fapte si reguli, ci utilizeaza solutia care īncorporeaza rationamentul aplicat īn rezolvarea problemelor similare. Aplicarea sistemului rationamentului bazat pe "cazuri" necesita stocarea, regasirea si asamblarea solutiilor tinānd cont de strategiile de rezolvare a problemelor, strategii existente īn solutiile individuale, si nu aplicarea unei strategii existente īntr-o solutie particulara. Conditia esentiala este aceea ca solutiile trebuie sa conduca la adoptarea unui mecanism general, care sa partajeze informatia si sa reprezinte īn ele īnsele constrāngerile (sistemul rationamentul bazat pe "cazuri" nu poate asigura existenta tuturor "cazurilor").
Trebuie subliniata abilitatea unui sistem de rationament bazat pe "cazuri" de a opera īn afara strategiei rezolvarii unei probleme particulare ceea ce face ca acest sistem sa lucreze independent de domeniu. Combinānd aceasta flexibilitate cu abilitatea de a "achizitiona" īn mod automat solutii, sistemul se poate dezvolta ca o desfasurare a unui domeniu anumit. Abordarea utilizarii sistemelor de rationamentul bazat pe "cazuri" presupune rezolvarea a 4 probleme legate de procesul de instantiere:
identificarea caracteristicilor unui "caz"; compunerea unei solutii sau a unui "caz" presupune determinarea atāt a componentelor si a relatiilor dintre ele, cāt si a modulelor sistemului;
definirea mecanismului de regasire a "caz"-urilor si a celui optim, ceea ce presupune existenta bazelor de cunostinte si a metodelor de determinare a celui "mai bun caz" din mai multi candidati;
realizarea unei scheme coerente de adaptare (adaptarea este procesul de a face ca solutia gasita sa fie aplicabila la problema curenta; solutia completa poate proveni din compunerea, īn diferiti pasi, a subsolutiilor);
integrarea solutiei de tip rationament bazat pe "cazuri" cu alte solutii similare.
Scopul principal este de a asista inginerul īncepator la rezolvarea problemelor, sprijinindu-se pe solutiile dezvoltate pentru problemele de proiectare anterioare. Cel mai puternic concept consta īn construirea unei noi solutii prin asamblarea solutiilor subproblemelor īntr-o structura a planului de proiectare. De fapt, structura planului de proiectare poate fi compusa atāt din planuri regasite īn baza de cunostinte, cāt si din planuri "īnvatate" (induse). Aceasta facilitate permite ca proiectantul sa interactioneze direct cu baza de cunostinte, unde pot fi regasite planurile pentru subproblemele cunoscute. Īn acest fel, pot fi generate planuri pentru "probleme" noi. Astfel, atāt planurile noi, cāt si cele existente īn baza de cunostinte pot conduce la determinarea unui plan de structura, care sa reprezinte solutia problemei. O data determinata o noua solutie, planurile "īnvatate" sunt cuprinse ca reguli si fapte īn baza de cunostinte.
Rezolvarea unei probleme de proiectare porneste de la problema propriu - zisa, si anume de la obiectivele, constrāngerile si specificatiile ei. Proiectantul solicita cautarea īn baza de cunostinte a unui proiect similar sau "apropiat". Daca īn "baza de cazuri" se gaseste un proiect similar, acesta este stocat īn memoria de lucru si este administrat de sistemul de Structura a Proiectului prin analizarea similitudinilor fata de cerintele proiectului de baza si identificarea modificarilor necesare pentru obtinerea parametrilor impusi de proiect. Daca nu se gaseste un proiect similar īn "baza de cazuri", proiectantul introduce noul Plan de Structura a Proiectului utilizānd cunostintele si interfetele existente īn baza de cunostinte, adica "produce" cunostintele necesare pentru noul proiect, īnvatānd astfel sistemul sa abordeze un nou "caz". Secventa de operatii, care conduce la nou proiect, este convertita si stocata ca un nou Plan de Structura a Proiectului īn Baza de Plan_Structura a Proiectelor.
Transformarea planurilor de proiect, de la contextul lor original la contextul curent se numeste adaptare. Mecanismul de adaptare trebuie sa identifice si sa rectifice īn mod automat problemele referite īntre componentele unei structuri a planului de proiect. Īn timp, baza de cunostinte a Plan_Structura a Proiectelor se īmbogateste cu noi structuri de proiecte. Daca la īnceput, activitatea de proiectare, deci de "īnvatare" a noilor proiecte, este predominanta. Cu timpul, activitatea de refolosire a cazurilor existente īn baza de cunostinte devine predominanta.
Algoritmul īntr-un sistem de Rationament bazat pe "cazuri" consta īn:
analiza problemei de proiectare (specificatii, obiective);
abstractizarea si generalizarea cunostintelor determinarea metacunostintelor;
regasirea planurilor pentru proiecte similare mapare cereri;
evaluarea si maparea diferentelor stocarea indicilor de regasire proiect (memoria de lucru);
analiza structurii de proiect constituirea secventelor de transformare.
Problema de proiectare Meta_cunostinte
Proiectant
(obiectivele,
constrāngerile, 
specificatiile)
Regasire, mapare Analizare Secvente de transformare
Evaluare cereri structura proiect ale proiectului
Etapele de rezolvare a rationamentului bazat pe cazuri sunt:
Proiectare_Automata - furnizeaza metoda prin care este analizat un proiect; elementele esentiale ale procesului de proiectare sunt supuse procesului de transformare, fiind convertite sub forma unui plan al proiectului, retinut īn memoria de lucru; planul proiectului contine obiectivele, conditiile initiale si constrāngerile aferente proiectului. Planul proiectului astfel transformat devine o parte a sistemului Structura Planului de Proiectare;
Memoria de lucru permite stocarea si regasirea planurilor de proiectare din baza de cunostinte a planurilor de proiecte; o data regasite, planurile de proiect sunt afisate de interfata sistemului;
Structura Planului de Proiectare permite elaborarea structurilor planurilor de proiect fie din planurile regasite, fie din cele asimilate din planurile noi de proiecte;
Sistemul contine interfete pentru prelucrarea cererilor de extragere din baza de cunostinte a planurilor de proiecte si evaluarea acestora.
Fiecare problema/subproblema este referita ca un agent inteligent.
Arhitectura PAC Inteligent de tip Case
Specificatii (Sub)problemele
ptr. noul proiect ptr.noul proiect
Problemele &
(Sub)problemele
Selectarea
"cazurilor
Memoria "cazurilor"
Transformarea "cazurilor"
Generalizarea
Cunostintelor de
Proiectare
descompunere,
Noua solutie constrāngeri
Fiecare agent are structura si functii standard, continutul fiind particularizat pe tip de problema.
Translatorul de reguli īn
Baza de cunostinte Regasirea "cazurilor"
similare
Informatiile Specificatiile
de proiectare de proiectare
(proiectant)
Adaptarea Descompunerea Reinstantierea Prototipuri
Proiect vechi
Vizualizare
adaptarilor
"Caz" adaptat
Proiectul Final
Functia de Mapare si Evaluare a Structurii Planului de Proiectare cu rolul de integra planurile "asemanatoare" existente īn sistemul de Structura a Planului de Proiectare īntr-un proiect coerent
Functia de extragere, din baza de proiecte
(ierarhii), a proiectelor similare si de a afisa modelul lor FCS;
proiectantul alege din lista proiectul cel mai adecvat cerintelor
noului proiect
7.2.1. Algoritm pentru analiza si detectarea diferentelor
Expertiza unei probleme de proiectare din diferite puncte de vedere poate conduce la divergente īntre agenti. Aceste divergente trebuie solutionate pentru ca procesul de proiectare sa fie un succes. De aceea, este necesar ca agentii sa fie capabili sa detecteze si sa rezolve divergentele.
Scopul principal īl constituie determinarea interactiunilor, diferentelor, ca si modul de solutionare a acestora īn sistemul multiagent, prin semnalare, detectare, clasificare.
Astfel, oricare agent trebuie sa aiba acces la modelul cunostintelor (obiective - dorinte-certitudini) ca si asupra rationamentelor privind obiectivele - dorintele-certitudinile si influenta lor asupra agentilor. Definirea diferentelor este un proces iterativ, care se realizeaza pentru fiecare entitate agent.
Algoritmul de definire a ierarhiei*) de "obiective - dorinte-certitudini" pentru fiecare entitate agent consta īn:
analizarea atributelor si a valorilor acestora īn cadrul tuturor componentelor din subierarhia de definitie a agentului,
crearea ierarhiei de "obiective - dorinte-certitudini".
Aceasta ierarhie contine: pointer la entitate, tip entitate -->obiectiv/dorinta/certitudine cantitatea cu care "obiective-dorinte-certitudini" trebuie sa creasca sau scada obiectiv/dorinta/certitudine, importanta atasata "obiective-dorinte-certitudini", coeficient euristic justetea "obiective-dorinte-certitudini", coeficient euristic.
Algoritmul de definire a ierarhiei de "obiective - dorinte-certitudini" se repeta fiecare Agent si se construiesc ierarhiile "obiective - dorinte-certitudini" pentru toti agentii existenti īn procesul de proiectare.
Se analizeaza ierarhia de "obiective - dorinte-certitudini" a fiecarui Agent determināndu-se situatiile diferentiale. Diferentele se īnscriu īn ierarhia de diferente, ce constituie obiectul urmatorului capitol.
7.2.2. Algoritm de construire a ierarhiilor de diferente
Modelul de rezolvare a diferentelor porneste de la o ierarhie a diferentelor, avānd diferentele cele mai abstracte spre nodul "radacina" si cele mai concrete spre "frunze".
Ierarhia diferentelor este corespondenta ierarhiei de rezolvare a acestora, rezultānd diferentele dependente si independente de domeniu si strategiile de rezolvare a diferentelor asociate lor.
Radacina ierarhiei reprezinta diferentele independente de domeniu, īn timp ce spre "frunze" se regasesc diferentele dependente de domeniu.
Informatia care reprezinta ierarhia de diferente este structurata astfel:
relatia AGENT critic si valoarea*) existenta / estimata a unui parametru;
sugestii incompatibile pentru aceeasi valoare*) a unui parametru, coeficient euristic al unei entitati vazuta din diferite puncte de vedere sau a unor entitati diferite.
7.2.3. Algoritm de rezolvare a "diferentelor"
Rezolvarea constituie cea mai banala abordare pentru rezolvarea diferentelor, prin care se īncearca solutionarea inconsistentelor pentru a determina setul coerent de decizii de proiectare. Procesul de rezolvare este precedat de generarea de propuneri si contrapropuneri bazate pe reactia agentilor, precum si comunicarea justificarilor si suportul evidentei.
Un compromis initial este generat si prezentat fiecarui "expert" sau "perspectiva". Fiecare agent evalueaza propunerea din punctul sau de vedere si īnregistreaza reactiile sale (evaluari, obiectii si sugestii). Procesul se termina atunci cānd toti agentii accepta propunerea de proiectare.
Fiecare agent desfasoara, īn timpul procesului de rezolvare, urmatoarele activitati:
recomandarea deciziilor de proiectare: exprima acceptul compromisului; recomandarile sunt, īn principal, generate prin combinarea solutiilor, existente īn baza, corespunzatoare proiectelor anterioare similare, precum si avantaje rezultate din propagarea constrāngerilor;
justificarea recomandarilor: pentru ca propunerea de proiectare sa devina inteligibila pentru toti agentii, uneori ghidati doar de propriile lor solutii si criterii, si pentru a mari sansa ca solutia propusa sa fie acceptata, este folositor ca justificarile sa fie comunicate; aceste justificari ajuta agentul sa evalueze acceptul deciziei de proiectare din punctul sau de vedere; justificarile pot fi obtinute din modelul PAC sau accesānd proiecte anterioare similare;
explorarea alternativelor acceptabile īsi propune sa optimizeze compromisul propus; se utilizeaza baza cu solutiile proiectelor anterioare similare;
modificarea compromisului respins se realizeaza folosind cazuri anterioare si reguli de modificare.
Īn procesul de rezolvare se cunosc:
setul de obiective diferentiale si constrāngeri pentru diferiti agenti de proiectare;
contextul de proiectare (constrāngerile apartinānd unor agenti accesate de alti agenti).
Informatiile auxiliare cunoscute sunt: nod ierarhie (component - structura), faza de proiectare, recomandari ale deciziilor, justificari ale recomandarilor, solutii alternative de proiectare, procedura de modificare a solutiei respinse.
Īn urma rezolvarii diferentelor, se determina fie un set de decizii (solutii) de proiectare, agreate de agenti, fie indicarea esecului, daca procesul de rezolvare nu ajunge la un compromis, dupa un numar dat de propuneri.
Procesul de rezolvare consta īn selectarea, rafinarea si executia strategiei de rezolvare. Fiecare agent are atasati coeficienti de utilitate corespunzatori fiecarui atribut al proiectului. Totalitatea coeficientilor atasati atributelor reprezinta coeficientul general asociat unui agent.
Fiecare agent alege solutiile alternative de proiectare īn asa fel īncāt sa maximizeze coeficientul de utilitate din punctul sau de vedere. Rezolvarea se realizeaza īntre seturile de valori diferentiale īn ideea de a se ajunge la un compromis. Īn acest sens, este important ca utilitatile agentilor sa fie folositoare propriului agent ca si celorlalti agenti. Aceasta face ca un agent sa poata prezice compromisul pe care un alt agent este dispus sa-l accepte ca si implicatiile unei respingeri, din punctul de vedere al celuilalt agent.
Modelul de rezolvare multiagent propus se bazeaza pe:
a). cunostintele din proiectele anterioare,
b). comunicari ale rationamentelor proiectarii, justificarilor si obiectiilor la deciziile de proiectare propuse,
c). propagarea si relaxarea constrāngerilor,
d). "traversarea" ierarhiei (graf-ul) obiectivelor ("goal"-urilor).
Interogarea Planului de Structura Structura
Planului de Proiectare
Adaptarea Proiectului (Mapare si Evaluare)
Planul de Proiect
Ramurile īn graf reprezinta relatiile īntre obiective, īn ideea ca fiecare participa (pozitiv sau negativ) la realizarea altor obiective. Rezolvarea unei probleme de coordonare a agentilor īn problema de proiectare, īn care actioneaza n agenti care impun constrāngerile C1, C2, ... Cn implica n variabile x1, x2, ... xn.
Pasii de rezolvare sunt: (a) crearea ierarhiei, (b) detectarea consistentei diferentelor (c) relaxarea constrāngerilor si analiza implicatiilor asupra celorlalte constrāngeri (de exemplu, reducerea valorilor unui atribut poate conduce la cresterea valorilor pentru alte atribute) (d) determinarea ierarhiei īn urma relaxarii constrāngerilor (reducerea valorilor pentru atribute). Agentii avānd diferite puncte de vedere evalueaza diferit sugestiile pentru parametrii de proiectare; ceea ce face necesara utilizarea unui arbitru ca mijloc central de control prin care agentii comunica.
Detectarea si rezolvarea diferentelor īn cazul sistemelor multiagent include o schema cu un proces general de rezolvare a diferentelor īntre agenti. Agentii actioneaza secvential, diferentele sunt anticipate si eliminate. Procesul contine o programare pe baza de agenda, care face vizibili parametrii īntre agenti.
procesul de evaluare euristica
Date evaluare euristica Solutii evaluare euristica Solutii
Generale 
Generale Generale
Manager solutie Clase diferente Mapare directa Cautare Generala
Ierarhie
diferente
Rafinare
Agent Proiectare Recomandare
Decizii Proiectare Solutie Plan RD& Rationamente
principiu de generare a planului de diferente
Evaluare
Diferent Context Analiza
euristica*) Goal preferinte
Identificare NU Generare
problema plan
DA
Context
Modificare
Plan Evaluare plan
Esuare
NU
Plan acceptat
Evaluare euristica*)
Utilizare DA
Similaritati Analiza
Argumentare Propunere
Preferinte
NU NU
Argumente Decizie De acord ? Reactie
Selectarea "cazului" pentru un nou proiect
Cautatorul
de "caz
Problema Proiecte
Selector
de "cazuri"
de rezolvat
similare
Functia Diferente are rolul de a asista proiectantul īn analiza ierarhiei si de a stoca diferentele īn arborescenta "diferente", cu structura similara cu o ierarhie. Parametrul tip_dif reprezinta tipul diferentei FCS [modelor] si BC[Baza de Cunostinte].
evaluarea si maparea cererilor īn baza de cunostinte
Se compara proiectul dat cu proiectele dintr-o categorie anumita; se extrag proiecte similare (planul de structura); proiectantul alege proiectul cel mai adecvat.
rezolvarea diferentelor: se extrage, din baza de
cunostinte, modelul proiectului ales; prin dialogul dintre
agentii corespunzatori (sub)problemei, se fac modificari ale
obiectelor sau atributelor:
Partea a III-a cuprinde exemple de implementare a algoritmilor de Proiectarea Inteligenta Asistata de Calculator si anume: modelarea proiectului pentru o sursa fotovoltaica, prin modelare structurala (construirea ierarhiei proiectului, a modelului Functii - Comportament - Structura si a bazei de cunostinte aferente), precum si modelarea cauzala a circuitelor nelineare.
Īn multe cazuri, procesul de proiectare creativa necesita cunostinte de tip interdisciplinar (corespunzatoare interdomenii) pentru a "inspira" rezultatele īntr-un nou proiect. Īn acest sens, utilizarea bazelor de cunostinte īn procesul de proiectare pentru reprezentarea cunostintelor de tip interdisciplinar reprezinta cheia rezolvarii acestei probleme. Necesitatea de a se deprinde īnsusirea tehnicilor de proiectare a circuitelor sau de a se proiecta circuite cu un ciclu de viata cāt mai lung si care sa nu prezinte defectari pe timpul functionarii lor, face obligatorie integrarea proiectarii asistate a acestora cu elemente de inteligenta artificiala, precum si procesarea concurenta a diferitelor module din domeniu.
Teza de doctorat se bazeaza pe rezultatele cercetarilor īntreprinse pe parcursul a 20 de ani de experienta īn domeniul Proiectarii Asistate si a Proiectarii Asistate Inteligente īn domeniul circuitelor electronice.
Elementele de originalitate cuprinse īn teza constau īn:
modelarea cauzala a informatiilor referitoare la circuit si transformarea acestora īn cunostinte;
construirea modelului FCS (Functiuni - Comportament - Structura) si aplicarea acestuia īn IPAC;
modelarea mecanismului de īnsusire a tehnicilor de proiectare;
interactiunea dintre proiectant si modelul Functiuni - Comportament - Structura al proiectului (regasiri de proiecte analoge, mapari si transferuri de elemente analoge īntre proiecte).
Principalul element de originalitate īl constituie rezolvarea concurenta si distribuita de probleme de catre echipe de "proiectanti" constituiti īn agenti. Fiecare rezolvator este autonom īn comportare, are strategii de cooperare si comunicare pentru controlul si rezolvarea situatiilor conflictuale, are scopuri si abilitati proprii. Acesta poate fi definit ca un mediu multiagent cu rezolvatori rationali ce coopereaza īntre ei. Cunostintele sunt achizitionate de la "expertul" īn domeniile ce constituie obiectul proiectarii, iar studentul va utiliza programe care "genereaza" automat proiectarea propriu-zisa. De asemenea, el are la īndemāna instrumentele inteligente care asista proiectantul īn timpul procesului de proiectare si care, īn urma analizarii solutiei propuse, completeaza proiectarea propriu-zisa sugerānd īmbunatatiri, īn principal, pentru respecificarea produsului (alternative) sau chiar renegocierea cerintelor proiectului.
Proiectarea Inteligenta Asistata de Calculator foloseste baza de date a sistemului ce contine caracteristicile constructive si tehnice ale produsului, rezultate īn urma proiectarii asistate, si baza de cunostinte, care contine modelul procesului de proiectare si regulile referitoare la procesul de proiectare, sugestii de evaluare si īmbunatatire a solutiei propuse. Īn urma procesarii cunostintelor (metareguli si reguli), este generata o multitudine de alternative propuse ca solutie sau de interogari pentru baza de date.
Abordarea propusa are flexibilitate deoarece prezinta avantajul ca tine cont, īnca din faza de conceptie - proiectare a produsului, de elemente simulate ale functionarii acestuia (cum ar fi, de exemplu, prelucrarea concurenta a modulelor, posibilitati de modificare, tehnica tinānd cont si de cerinte de acuratete, eventual cost si tolerante etc.).
Metoda de analiza cauzala este utila pentru instruirea asistata fiind destinata proiectantilor īncepatori sau studentilor, constituind si o metoda de control īn procesul de achizitionare de cunostinte de la utilizatorul novice īn domeniu. Īn acest mod, se poate stimula gāndirea creatoare, implicit si proiectarea.
Īn cazul proiectarii bazate pe modelul Functie - Comportament - Structura nu sunt partajate aspectele comune superficiale, iar relatiile cauzale furnizeaza o īntelegere profunda a procesului de proiectare si furnizeaza o platforma pentru īntelegerea analogica. Generalizarea cunostintelor furnizeaza informatie suficienta pentru realizarea rationamentului. Functiunea, Comportamentul si Structura sunt caracterizate ca entitati ale procesului de proiectare si joaca un rol diferit īn īntelegerea acestuia.
Nu s-a avut īn vedere epuizarea subiectului sau o tratare exhaustiva, ci doar furnizarea unei modalitati de a reflecta la aspectele teoretice, prezentate anterior prin prisma realizarilor practice.
Tehnicile de programare ale inteligentei artificiale sunt necesare cānd se doreste obtinerea solutiilor la probleme care implica dificultati inerente pentru algoritmi numerici, denumite probleme polinomiale complet nedeterministe pentru care, īn baza algoritmilor cunoscuti, timpul de rezolvare creste exponential cu marimea problemei. Aceste cercetari sunt destinate inginerului īncepator sau studentului care trebuie sa deprinda tehnici moderne de proiectare.
Cartianu, G. s. a.: Analiza si sinteza circuitelor electrice, Editura Didactica si Pedagogica, Bucuresti, 1972.
Nicolau, E.: Stabilitatea oscilatoarelor, Editura Didactica si Pedagogica, Bucuresti, 1970.
Petrescu, Th.: Semnale si circuite, Editura Didactica si Pedagogica, Bucuresti, 1980.
Cartianu G., N. Savescu, C. Constantin, D. Stanomir: Teoria semnalelor, circuitelor, sistemelor, Editura Tehnica, Bucuresti, 1980.
Mateescu, A.: Analiza si sinteza circuitelor electrice, Editura Tehnica, Bucuresti, 1978.
Stanomir, D.: Analiza si sinteza circuitelor electrice", Editura Tehnica, Bucuresti, 1977.
Liu, D.: Filters and Fast Fourier Transform, Editura ???, 1975.
Callahan, W.: Modern network synthesis, Editura ???, 1972.
Director, S.W.: Circuit Theory", Editura ???, 1974.
Director, S.W.: Circuit Design, Simulation and Optimization", Editura ???, 1974.
Desoer, S.: Basic Circuit Theory", Editura ???, 1972.
Hayt, W., H. Kemmerly H.: Engineering Circuit Analysis", Editura ???, 1973.
Valkenburg, A.: Network Analysis", Editura ???, 1974.
Jensen, J.: Network Analysis Theory", Editura ???, 1974.
Kinariwala, Y.: Linear Circuits", Editura ???, 1973.
Gupta, I.: Circuit Analysis - Problem Solving", Editura ???, 1972.
Narayanan, S.: Transistor Distorsion Analysis". IEEE Transactions on Circuits and Systems, Vol 26/1979.
Director, S.W.: An Integral Charge Control Model of BJT. IEEE Transactions on Circuits and Systems, Vol. 2/1974.
Lindholm, F.: Modelling of BJT Using Integral Charge Model. IEEE Transactions on Circuits and Systems, Vol. 5/1972.
Kida, T.: New Time Domain Sensitivity Formulas. IEEE Transactions on Circuits and Systems, Vol. 8/1980.
Shien, S.: Topological Formulation of Symbolic Network. IEEE Transactions on Circuits and Systems, Vol. 12/1974.
Endy, C.: Sensitivity Minimization of Network. IEEE Transactions on Circuits and Systems, Vol. 2/1974.
Chua, L.: Sensitivity - Old Questions, Some new Answers. IEEE Transactions on Circuits and Systems, Vol. 2/1974.
Ciocoiu, L : Modelling and Simulation in Computer-Aided-Design. Proc. Of the European Conference of Simulation, ECS'86, Praga.
Ciocoiu, L., C. Sāmbotin: An Algorithm for an electronic Network. Proc. Of the European Conference of Simulation, ECS'88 (European Computer Simulation) Praga, 1988.
Ciocoiu, L., N. Olariu Algoritmi de Proiectare Asistata a circuitelor nelineare. Analele Universitatii Tārgoviste, 1995.
II. Proiectarea Inteligenta Asistata de Calculator
Addanki, S., Graph of Models. Artificial Intelligence, 1991.
Borning, A.: Constraint Hierarchies. Data & Knowledge Engineering, 1990.
Brown, D.C., B. Chandrasekaran: Expert Systems for Engineering Activity. Knowledge Engineering in CAD, 1991.
Brown, D.C., B. Chandrasekaran: Design Problem Solving. Artificial Inteligence, 1990.
Carbonell, J.G.: A Theory of Reconstructive Problem Solving and Expertise Acquisition. Machine Learning, 1986
Decker, K.: Distributed Problem Solving Techniques. IEEE Transactions on Systems, Man, Cybernetics, 1987.
DecHTer, R.: Network-based Heuristics for Constraint-satisfaction Problems. Artificial Inteligence, 1989.
DekLeer, J.: How Circuits Work. Artificial Inteligence, 1989.
Decker, K DeKleer J., Qualitative reasoning about Physical Systems , Artificial Inteligence, 1990.
Dym, C., R. Lewitt: Knowledge-Based Systems in Engineering, Mc-Graw-Hill, New York, 1990.
Dym, C., R. Lewitt: Toward the Integration of Knowledge for Engineering Modelling. Engineering with Computers, 1991.
Erman, L.D.: Integrating Knowledge to Solve Uncertainty. Computer Survey, 1990.
Falkenhainer, B., K.D. Forbus: Compositional Modelling. Artificial Inteligence, 51/1991.
Finger, S A Case of Study in Concurrent Engineering for Transformer Design. Proc. of ICED'90.
Forbus, K.D.: Qualitative Process Theory. Artificial Inteligence, 1992.
Harmon, P., R. Maus, W. Morrisson: Expert Systems Tools and Applications, Willey &Sons, 1988.
Klein, M.: Conflict Resolution in Cooperative design. Artificial Inteligence, 1991.
Kusiak, A.: Concurrent Engineering, Tools and techniques, Willey &Sons, 1993.
Iwasaki, Y.: Qualitative Reasoning, Handbook of Artificial Intelligence, 1989.
Iwasaki, Y.: An Architecture for Model-based Evaluation of a Preliminary Design. Artificial Inteligence, 1992.
Mittal, S., A. Araya: A Knowledge-based Framework for Design. Proc. of AAAI'90.
Niebur, D.: Expert Systems for Power System Control. IEEE on Intelligent Control, 1990.
Nil, H.P.: Blackboard Systems: Application for Knowledge Engineering. AI Magazine, 1990.
Pfau-Wagenbauer, M. Process-oriented Techniques for Power Systems Control. Artificial Intelligence, 1992
Simmons, R.: Commonsense Reasoning. Proc. of AAAI'89.
Stallmam, R. Forward Reasoning and Dependency-directed Backtracking in a System for Computer-aided Circuit Analysis. Artificial Inteligence, 1992.
Stallmam, R. Constraints in Expressing Hierarchical Descriptions. Artificial Intelligence, 1992.
Tokoro, M.: An Object-oriented Approach to Knowledge System. Artificial Intelligence, 1992.
Tomiyama, T.: Meta-model: a Key to Intelligent CAD Systems. Artificial Intelligence, 1989.
Viswanath, R.: Knowledge-based System for CAD. Engineering with Computers, 1991.
Zhang, C.: A Framework for Heterogeneous Cooperative Distributed Expert Systems. Data & Knowledge Engineering, 1990.
Zienkiewicz, O.C., J.Z. Zhu: The Three R's of Engineering Analysis and Error Estimation and Adaptivity, Computer Methods in Engineering, 82/ 1990.
Sāmbotin, C, L. Ciocoiu: Achizitia cunostintelor specifice procesului de proiectare, achizitie bazata pe frame-uri. Raport de cercetare. 1994.
Ciocoiu, L., S. Colesca, N. Olariu Intelligent Idealization Control Systems. Proc. of IFAC - LSS London'95.
Ciocoiu, L. Sistem privind Ingineria Concurentiala īn proiectarea conceptuala, instrument utilizānd sistemul expert īn īnvatarea proiectarii ingineresti. Raport de cercetare 1995&96.
Ciocoiu, L. Simularea Procesului de Predare - Circuite de Propagare a Constrāngerilor. Raport de cercetare 1996
Ciocoiu, L., N. Olariu Proiectare Inteligenta Asistata - Ingineria de cunostinte. Analele Universitatii Tārgoviste 1996.
Ciocoiu, L. Acquisition and Elicitation in Model Based Knowledge, West Virginia University, 1997.
Ciocoiu, L. L.Ciocoiu - Java Programming in Internet for Interactive Teaching , West Virginia University, WV, SUA, 1997.
Ciocoiu, L. Model based Knowledge for Intelligent Computer-Assisted Design, Worcester Polytechnic Institute, MA, SUA, 1997.
Ciocoiu, L. Interactive Teaching of Engineering Design, Worcester Polytechnic Institute, MA, SUA, 1997.
Ciocoiu, L. Sistem Inteligent utilizat īn Procesul de Proiectare - conexiuni interdisciplinare, tehnici si metode ale ingineriei de cunostinte. Raport de cercetare 1997 - 1998.
Ciocoiu, L. Intelligent Agents in Interactive Teaching, Institute D'Informatique Entreprise, Evry, Franta, 1998.
Ciocoiu, L. Tehnici si instrumente pentru Sistem Inteligent de Proiectare Asistata īn Internet. Raport de cercetare, 1999.
Ciocoiu, L. Intelligent Agents in Virtual World, Laboratoire d'Intelligence Artificielle, Universite Paris 5, Franta, 2001.
Anexa
Despre limbajul Clips Versiunea prototip de CLIPS a fost dezvoltata īn mai putin de trei luni īn primavara lui 1985. O atentie deosebita s-a acordat compatibilitatii cu alte sisteme expert īn dezvoltare la acea data, fapt care a atras o asemanare a sintaxei limbajului CLIPS de cea a sistemului expert ART.
Limbajul CLIPS a fost dezvoltat cu intentia de a cāstiga suficiente cunostinte despre modul de realizare a sistemelor expert si de a consacra o alternativa la produsele comerciale, folosite la aceea data. Versiunea 1.0 demonstreaza fezabilitatea proiectului. Dupa dezvoltari ulterioare, a devenit evident faptul ca limbajul CLIPS va deveni un instrument sistem expert ideal pentru teste. Īnca un an de dezvoltari si teste au īnsemnat īmbunatatirea portabilitatii, performantei si functionalitatii. Versiunea 3.0 a devenit disponibila pentru publicul larg īn vara anului 1986.
Dezvoltari ulterioare au transformat limbajul CLIPS dintr-un instrument de test īntr-unul util dezvoltarii de sisteme expert. Versiunile 4.0 si 4.1 ale limbajului au devenit disponibile īn vara, respectiv toamna lui 1987, oferind performante semnificativ īmbunatatite, integrare externa a limbajului si a capacitatii de transmitere. Versiunea 4.2, disponibila din vara lui 1988, a fost o rescriere completa a limbajului pentru modularizarea codului.
Īn versiunea originala, metodologia de reprezentare īn CLIPS a fost cea a unui limbaj bazat pe lanturi de reguli ale algoritmului Rete. Versiunea 5.0 a CLIPS, disponibila īn primavara lui 1991, a introdus doua noi paradigme: programarea procedurala si programarea orientata pe obiect. Limbajul de programare orientat pe obiect din limbajul CLIPS este denumit CLIPS Object-Oriented Language (COOL). Versiunea 5.1, disponibila din 1991, a fost o dezvoltare necesara pentru interfetele XWindow, MS-DOS si Macintosh. Versiunea 6.0, disponibila din 1993, oferea suport pentru dezvoltarea de programe modulare si integrare strānsa a capabilitatilor programarii orientate pe obiect cu cea bazata pe reguli. Versiunea 6.1, disponibila īn 1998, a eliminat suportul pentru compilatoarele non-ANSI C si a adaugat suport pentru compilatoarele C++.
Versiunea 6.2 contine doua īmbunatatiri majore. Īn primul rānd, limbajul CLIPS ofera acum un mecanism care permite unei aplicatii īncapsulate sa creeze medii multiple, īn care programele pot fi īncarcate. Īn al doilea rānd, interfata Windows este disponibila, iar interfata Macintosh a fost extinsa pentru a suporta MacOS X.
CLIPS a fost proiectat pentru a oferi o integrare totala cu alte limbaje precum C si Ada. Regulile si obiectele formeaza, de asemenea, un sistem integrat deoarece regulile pot face potriviri de pattern-uri pentru fapte si obiecte. CLIPS poate fi folosit ca un instrument de sine statator, mai putānd fi apelat si de un alt limbaj de programare, executānd functiile apelate si apoi returnānd controlul programului apelant. Reciproc, codul procedural poate fi definit ca functii externe si apoi apelat din CLIPS. Dupa executia codului extern, controlul este returnat CLIPS.
Despre CLIPS.DLL
Aplicatia ElectricCASE este un sistem cu baze de cunostinte CLIPS, accesate prin intermediul unei librarii DLL. Īn cea mai mare parte, DLL este o librarie care a preluat toate functiile CLIPS, dar adaugate si uneori modificate. Nu exista nici o diferenta īntre folosirea DLL si īncapsularea directa a motorului de CLIPS īn aplicatia noastra. Includerea motorului CLIPS īn aplicatie este posibila ca urmare a liberei distributii a surselor CLIPS. Cu toate acestea, exista avantaje ale folosirii DLL fata de solutia cu īncapsularea directa. Īn primul rānd, el este un obiect de sine statator, care nu trebuie recompilat si ale carui functii pot fi direct apelate din aplicatie. Īn plus, mai multe procese pot folosi īn comun DLL, īn consecinta, aceasta ducānd la scaderea necesarului de memorie alocata pe aplicatie. De notat ca functiile exportate din librarie sunt extrase cu directiva cdecl. Pentru a interfata cu alte limbaje, altele decāt C, exista interfete disponibile VB./HLL.
Toate versiunile librarie prezinta un management extins al memoriei. Versiunile DLL nu pot fi īncapsulate īn obiecte COM. Daca se īncearca rularea REGSVR32 peste ea, operatia va esua. Tot ceea ce trebuie facut pentru instalarea DLL este copierea acestuia īn sistem.
Versiunea 6.04.24 si cele ulterioare suporta construirea propriilor functii utilizator, fara a fi necesara o recompilare a librariei, fapt posibil ca urmare a folosirii unei alte librarii DLL externe, construita de utilizator, denumita CLPUSRFN.DLL si care este apelata, la rāndul ei, de CLIPS.DLL. Ea trebuie sa exporte functia int UserFunctions(void) si orice alte functii noi definite. Tot ceea ce trebuie facut este construirea propriei librarii DLL cu functiile utilizator definite īn ea si īnregistrarea ei ca punct de intrare astfel īncāt noua librarie va fi īncarcata si folosita automat de CLIPS.DLL.
Versiunea 6.04.33 si cele ulterioare suporta nume lungi de fisiere. Versiunea 6.05.x adauga nucleul de CLIPS 6.05. Versiunea 6.10.45 include noua versiune de CLIPS 6.1. Versiunile 6.10.46 si 6.10.47 au fost recompilate folosind Visual C++ 6.x, drept urmare ea are nevoie de versiunea 6.x a MSVCRT.DLL.
O posibilitate de folosire a motorului CLIPS, ar fi īncarcarea de fisiere ce contin setul de comenzi (*.clp) existente pe disc asa cum se vede īn exemplul urmator:
#include "ClipsEng.h"O alta posibilitate ar fi apelul functiei execCommand, care executa comenzi CLIPS:
eng.execCommand("(deffacts fact1 (age 10))");
|
