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.
|
(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
|
Memoria "cazurilor"
 |
|
Generalizarea
Cunostintelor de
Proiectare
descompunere,
Noua solutie constrângeri
Fiecare agent are structura si functii standard, continutul fiind particularizat pe tip de problema.
|
|||
|
|||
Informatiile Specificatiile
de proiectare de proiectare
(proiectant)
|
 |
|
 |
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
 |
 |
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).
|
|
|
 |
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
|
|
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.
 |
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))");
|
