THESlS .2001 This is to certify that the dissertation entitled An Approach to the Development of Intelligent Systems through Integrating Function—Based Reasoning with the Generic Tasks Methodology presented by Oleg Yurievich Lukibanov has been accepted towards fulfillment of the requirements for Doctor of Philosophy degree in Computer Science and Engineering / : 4 MS Major professor mm MS U is an Affirmative Action/Equal Opportunity Institution 0.12771 LIBRARY Michigan State University PLACE IN REI'URN BOX to remove this checkout from your record. TO AVOID FINES return on or before date due. MAY BE RECALLED with earlier due date if requested. DATE DUE DATE DUE DATE DUE u ‘,‘ .‘ .14‘l‘§§\-2‘,“:‘\ i‘ i i. i-._ ‘ 1 " i. I ‘,....‘ , out}... 1 ‘ ‘ y _ _ - w 1A. ,f’ ii. J1 Ki“ ‘1 A’W'!’ I 1 "W" Ail?) moo woman.“ LP .Hfi “I“! 'f‘ M HFVRVHVEH I \, ?' NAIIAII I'PA' ih‘vudfi l: I [0’ C AN APPROACH TO THE DEVELOPMENT OF INTELLIGENT SYSTEMS THROUGH INTEGRATING FUNCTION-BASED REASONING WITH THE GENERIC TASKS METHODOLOGY By Oleg Yurievich Lukibanov A DISSERTATION Submitted to Michigan State University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Computer Science and Engineering 2000 w mmmnu TOT? 'H nr’nvnv. I v «Am. IN" I‘Hav I‘m-ivy»): n .50.".H. f‘f't UCI ? . fie 'esea'cfi :r. K‘ ’5'? 299:“ v .I, r FP‘AA F VHVV‘: h ._fl 7 ‘ 'leia"1”h.h. “w J! .. t‘ ‘ \ J,“ 0" ”KI! Ci . .' ‘ ~‘p ma.”""‘h aw 'Vo- JV: . ram VHU 'v ‘ . V. ' I‘ u a “ U'e VI'ID". ABSTRACT AN APPROACH TO THE DEVELOPMENT OF INTELLIGENT SYSTEMS THROUGH INTEGRATING FUNCTION-BASED REASONING WITH THE GENERIC TASKS METHODOLOGY By Oleg Yurievich Lukibanov The research in knowledge-based systems have advanced to a degree where different schools of thought have developed as well as described a number of useful methods that solve various kinds of problems. However powerful these methods are they cannot solve complex problems working alone. Complex problems require the cooperation of a number of problem-solvers each contributing to the overall solution. This dissertation refers to such systems as Integrated Knowledge-Based Systems (I-KBS). This dissertation research defines a methodology, language, and tool set that could be used for the description of integrated architectures of l-KBS. The core of the approach is a modified function-based reasoning theory that enables decomposition of a modeled entity, its functionality, and a causal network that explains the functionality of the overall unit. This dissertation describes the changes that have been made to the traditional function-based reasoning theory and application of the proposed methodology to the development of a shell for constructing integrated “ah-m . L52; :ased 5pc: ..u:p;¢> {SF '36 251' iii-"'39:: redes :~ u U ' users to' 9679?}. h; "r ;' ~:’“A‘IM :1: u '.' 'V‘UVI' -StNE. 5132595 a Wares 31 :5"? :~93: Ufw ~52" EX knowledge-based systems - S-Force. The description of the features and functionality of S-Force is then given on an example construction of an integrated knowledge-based system. The dissertation describes the application of the proposed methodology and S-Force to re—designing the knowledge-based core of the K88 Socharis - a systems for generating multiple conceptual manufacturing plans for mechanical assemblies made of polymer composite materials. In the conclusion, this dissertation compares the developed approach to other methodologies that promote cooperation between multiple software entities and poses a hypothesis that the reported research may serve as a basis for the development of complex, reusable integrated problem-solving architectures. " oi the uses. 39:53:23,211 (ONR. -’ wilt tire to tar I "" 'V"\VUII .. "“m‘pn‘ II A rngm ): Q We. J A. ,9“, a a 2.: s 35:91:; 3 (I) _ lenano imec to M) c: :1; 0" II 5" a“ C Le! .b‘A C': 1:5". PHI? “t and N T U i by :IU U . l "C”?a if t: ‘I‘. I 'I‘" a“. “he”; I v F w..:: ACKNOWLEDGMENTS Part of the research reported here has been supported by DARPA RADEO program (ONR N00014-96-1-0678), by the NSF Rapid Prototyping Initiative (NSF MlP-942—0351), and the Technology Reinvestment Program (eee- 9412783 613224). I would like to thank my advisor, Dr. Sticklen for his support and encouragement during my doctoral studies. Without stimulating discussions with Dr. Sticklen this dissertation would have not been possible. I indebted to my colleagues from the Intelligent Systems Laboratory for debates we had over the ideas behind this research. I especially thankful to Mr. Robert Hawkins and Dr. Timothy Lenz. I most thankful to my wife and colleague lliana Martinez, without her support and help I would be able to start and finish this research. ICDOII LEDG \IE\TS_..... TIM 0i C0\TE\”IS ......... 157 III WILLS '.5” 0i IlGIRESm. Elli XBBRD Mill)“ . ‘. BTRODICTIOL... .. W . i~1.7l'3\........... ..-. p"-.. . - .\?.!.-.\:L.‘.' rt: 5. 0‘ ,.-.'.,.., __‘- v .. i"‘.‘.!..l‘i =_l~.:\. . .4 3:3: "30:15"; _ '\“ U0-\It § ~ 133%.er ..._, With PROBLEM. .3 DEEP-“A ()3 ; 1.‘ I "e-.-, ' . .. l\.!g.I~C-‘~!C\\ THC, ‘I 'l ' .-. , . _ .. tiff-431?? ALE . 3... - m... ‘* -‘~'=~‘\’.-\ - ‘33: v -- i ~ 4 “- ”hr-5.3....” -.'.'.. t a ‘ i --. 0.10.2311; 2. 1 ~ 3 ‘1 I- ’. .~~ E“.‘i..-. I’ I r»- l n I P in. > - t5\J\‘/.¢.1\.!;\\‘l.\ YT." P .. "“\;\”T.-. - ~ :I. 1y 0" “Q l ..- Q‘,_ ~. ‘ H 4 ‘,€ \ I" a .av.‘ H"" I, . - . ‘0‘. {_ \l M! B . - . Q _ . .'-, N... : .. to ‘Y \_D‘E‘ " 1'39,~§3:P':-r. a. ‘ "‘-s.~;'- .1. r“ ‘x. " .. A It‘d!“ - .‘Iy .‘n 3‘. L. ,r . . x. 5' *2}th ‘ r . ‘. 05"», ‘ 'V- ~.I~K1C‘ “4 ‘1‘.*. I r‘J p" " A~J£ ((‘ ~5FN1: .I' ‘2' V ’3: I i}: All fi.7f’.\‘ “ TI . i I K-(IJI ”If . ,"l‘H .'~' T “Q: .‘ . l{.: C, y I) - y (" I ‘ '~ U! 1‘ :\‘ F . ‘ ‘ h ‘ A~§n fi>f\: .. ‘I F s.-\_! I 7r r 1‘ J": U" D TABLE OF CONTENTS ACKNOWLEDGMENTS IV TABLE OF CONTENTS V LIST OF TABLES VIII LIST OF FIGURES IX LIST OF ABBREVIATIONS X 1. INTRODUCTION 1 1.1. MOTIVATION l 1.2. IMPORTANCE OFTHE RESEARCH .. - - - 2 1.3. RESEARCH CONTEXT - ..... 3 1.4. RESEARCH OBJECTIVE ..... 7 1.5. DELIVERABLES ..... ..... . - 10 1.6. DISSERTATION ORGANIZATION .......................... .. l2 2. DOMAIN PROBLEM 13 2.1. INTRODUCTION TO COMPOSITES -. ..... - 15 2.2. HIGH-LEVEL PROBLEM-SOLVING STRATEGY OF SOCHARIS - - ......... 17 2.3. PROBLEM-SOLVING ARCHITECTURE OF SOCHARIS ....................... 20 2.3.1 . Translation and Skeletal Plan Generation ........................................................................... 20 23.2. Generating the Family of Technological Alternatives .......................................................... 21 2.3.3. Evaluation ............................................................................................................................. 22 2.4. ACCOMPLISHMENTS AND SHORTCOMINGS OF SOCHARIS AND APPLICATION DOMAIN PROBLEM STATEMENT . 23 3. PREVIOUS RESEARCH 26 3.1. OVERVIEW OF KNOWLEDGE-BASED SYSTEMS ................ . -- 26 3.1.1. Control Architectures ........................................................................................................... 26 3.1.2. Rule-Based Systems .............................................................................................................. 29 3.1.3. Hardwired Systems -_ - . - ............................................................................ 29 3.1.4. Blackboard-Based Systems ................................................................................................... 30 3.2. TASK-SPECIFIC ARCHITECTURES AND INTEGRATED KNOWLEDGE-BASED SYSTEM ........................ 34 3.2.1 . Knowledge Level Hypothesis ................................................................................................ 34 3.2.2. Second Generation Expert Systems ...................................................................................... 34 3.2.3. GENERIC’TASKS ................................................................................................................. 37 3.2.4. PROTEGE ............................................................................................................................ 40 3.2.5. KADS .................................................................................................................................... 41 3.3. ONTOLOGIES AND OTHER APPROACHES TO KNOWLEDGE SHARING iN KNOWLEDGE-BASED SYSTEMS . . 44 3.3.1. Syntactic Mapping ................................................................................................................ 44 33.2. KIF: Knowledge Interchange Format .................................................................................. 46 3.3.3. K QML: the pragmatic approach .......................................................................................... 48 3.3.4. Ontologies and Ontolingua ................................................................................................... 49 3.3.5. Tools for Developing Domain Ontologies ............................................................................ 51 3-4. RELATED RESEARCH IN SOFTWARE ENGINEERING ..... 54 3.4.]. From Data F low Diagrams to the Object Modeling Technique ........................................... 54 3 .42. Component Reuse ................................................................................................................. 56 V ? Patel-.43 3 7* 4 'l' --. k . ‘. .5 It: Oriana“) . '5 :90 R' -\ :‘ PRESS-543:. . H 0" :t’ 313323;»: x'l. if: FR'i"D(~.(.’- 355 rt {9' P'.-.'(t.t(.’ :i: {pivflflsrrl .‘.‘.‘ Slifi‘ffllti'T 3: (mas-ox .............. I NilSIS .\\D A Tlii 13 57133.01} . I‘ " .. wiafsxsffz'xasij I3 792:1 r. Pawns "a . , 44 1‘11. :5 .CT'f-‘z V I' . - u‘ E'T-T‘CM 0? ”7‘1": . P a. 'h”. ‘ u. LIZMRD ‘3; T \ ~ \lo ". , '1 I ‘4 2" 35.0“ C-‘f' .” .\;"'. P. ,.., .,,., v \;\lsbk)r~}\..u..unn.. ‘. PROBLEM STATEN. ... .‘AERHZE. P'i "4 IFIrz :14. ’ u;- L . \ \ . . -- ”Arno“ ’ .-..,_ W \ L1}, 1 -“ ' 5~J3Cfi€r “LI-- r" , "‘ ‘* Dirf'gr‘t‘ F.. '- \“‘ _. . ’ ‘ ~ birvrr: . .. -u. ' Em ~ _"\ _ _ ‘ . U‘LM -- ‘ ‘ F ' ”' 31"”.f‘r . g 4. . ‘1‘“ if... .- WW I. i " u... ‘\?3?\':‘.~ i" I “A PEPE 8‘ SifP/‘rrl :- ‘|. \ u .- L”; ‘ hJ!V"" l “ 1&1. Q“ 20.. A 1 ““ . .I _‘ I F t. 3‘ . Ns:: PH- ‘1; f ' '4 PI ." v‘f'ggr a p u l ._ , '. \':A L... 3“ .ish‘fi- .- l’. "-i-.J\L’:- .} Hr ' .- “I K‘ . T C'jlr'r- 3’ A 4 ”. "3 RUW 5. lil C(lt'p V . I", &‘T'.~:h|.tl h .3 . ‘ Bile. ‘ ' : run {- th 9" .r {'1 \1(‘{;;' a S t . Shaw 6 " s C, ”Kit..- \ 3.4.3. Personal Software Process ................................................................................................... 58 3.4.4. Domain Specific Soflware Architecture ................................................................................ 59 35. FUNCTION-BASED REASONING _ ...................................... . 61 35 .1 . Description of F unction-based Reasoning ........................................................................... 62 3.5.2. FR for Devices ...................................................................................................................... 66 3.5.3. FR for Processes ................................................................................................................... 68 3.5.4. FR for Sofiware Design and Understanding ........................................................................ 69 3.5.5. State of the Art .. ......................................................................................... 70 3.6. CONCLUSION 72 ANALYSIS AND A THEORY BEHIND APPROACH 74 4.1. INTRODUCTION ............. 74 4.2. WHAT IS NOT COVERED BY THE APPROACH? ......................... 75 4.3. THEORETICAL PRPMISF 76 4.4. FR AS A STRUCTURE MODELING METHODOLOGY 78 4.5. LIMITATIONS OF THE TRADITIONAL FR APPROACH 79 4.6. EXTENSION OF FUNCTION-BASED REASONING METHODOLOGY: FUNCTIONAL ONTOLOGY ........... 79 4.7. EXTENSION OF FUNCTION -BASED REASONING METHODOLOGY: INFORMATION PROCESSING ........ 81 4.8. CONCLUSION 83 PROBLEM STATEMENT AND APPROACH 85 5.1. PROBLEM STATEMENT 85 5.2. APPROACH 85 5.2.1. Integrated Knowledge-Based System as a Device: Functional Ontology ............................. 87 5.2.2. Augmenting Precondition Clause ......................................................................................... 90 5.2.3. Tying it All Together .................................................................................. 92 5.3. FRAMEWORK RESTRICTIONS 93 ILLUSTRATED APPROACH 99 6.1. BUILDING THE PS HIERARCHY- --- 101 6.1 .l . Socharis“ Example ............................................................................................................. 102 6.2. FUNCTIONAL MODEL: ASSIGNING FUNCTIONALITY TO THE NODES OF PS HIERARCHY ............... 104 6.2.1. Socharis* Example ............................................................................................................. 106 6.3. FUNCIIONAL MODEL: MACROEXPANSION ......... 109 6.3.1 . Socharis“ Example ............................................................................................................. 110 6.4. INFORMATION-PROCESSING MODEL ............ 112 6.5. INFORMATION-PROCESSING MODEL: PSH ............ 1 14 6.5.1. Socharis“ Example ............................................................................................................. 115 6.6. INFORMA'I'ION-PROCESSING MODEL: INPUT AND OUTPUT. 120 6.6.1. Socharis* Example ............................................................................................................. 120 6.7. INFORMATION PROCESSING MODEL: MAPPING ........................... 122 6.7.1. Socharis“ Example ............................................................................................................. 123 6.8. INFORMATION PROCESSING MODEL: PRECONDITIONS ....................... 125 6.8.1 . Qualitative and Quantitative Predicates ............................................................................ 125 6.8.2. Existential Predicates ......................................................................................................... 126 6.8.3. Socharis* Example ............................................................................................................. 126 6.9. INFORMATION PROCESSING MODEL: ACTIVATION CONTROL .......... . - - - 130 6.9.1. HC Control ...................................................................................... 131 6.9.2. Socharis“ Example ............................................................................................................. 132 6.9.3. RD Control ......................................................................................................................... 134 6.9.4. Socharis“ Example ............................................................................................................. 136 6.95. Boosting--- ..................................................................................................... 138 6.9.6. Socharis” Example .................................................................................. 138 6.10. FINAL REMARKS 139 6.10.1. Sequence of nodes' activation and mapping sequence ....................................................... 139 6.10.2. Color.coding__ ..................................................................... 140 vi '. II-NPLE\IE.\T.\T1(_)\ '.'. PITTEV-SOLHVCHZEH- '1 Emma MIDI; u; I- '.‘~ '.\T-”:a.\u.f‘.0\-PP._- Es . '.‘ Cmmi‘salvw '5 351332» I cowusmx L (manrnsmwz ELI. P'e;»:;:...... III. Ikt.'2;'f.;.(lt.’ , J Irina-Jr. PM: 4 51m! I: Shin." Sf: Pumcsl {rm .1' .‘I Same". .211; In '2: ‘CCfiECKAS To “.‘ri': L (mam-:3;- Russia LPN)! C15 1119313 A IUDMJDG L WWII B KNOII'LEDGL WWI C WAIT Am I \___ L'IEYDII D \IANITACTI I 7. RE-IMPLEMENTATION OF SOCHARIS 142 7.1. PROBLEM-SOLVING HIERARCHY OF RE-DESIGNED SOCHARIsKB -- - -- ............ 142 7.2. FUNCTIONAL MODEL OF RE-DESIGNED SOCHARIS 143 7.3. INFORMATION-PROCESSING MODEL OF RPS-DESIGNED SOCHARIS ...................... .. 145 7.4. ONTOLOGY, USER INTERFACE, PRE-, AND POST-PROCESSING 148 7.5. DISCUSSION 149 8. CONCLUSION 151 8.1. CONTRIBUTIONS TO THE KNOWLEDGE-BASED SYSTEMS FIELD .................................................... 152 8.1.1. Preamble ................................................... 152 8.1 .2. Functional Ontology ........................................................................................................... 154 8.1.3. Information-Processing Layer and Port Managers ............................................................ 155 8.1.4. S-Force: a Shell for Developing I-KBSs ............................................................................. 156 8.1 .5. Practical Application of S.Force ........................................................................................ 157 8.1.6. Summary and Venues of Future Research .......................................................................... 158 8.2. CONTRIBUTIONS TO THE APPLICATION DOMAIN 160 8.3. CONCLUDING REMARKS 161 APPENDICES 37 APPENDIX A KNOWLEDGE STRUCTURE OF SOCHARIS“ 165 APPENDIX B KNOWLEDGE STRUCTURE OF RIB-ENGINEERED SOCHARIS........................ 179 APPENDIX C MANUFACTURING ONTOLOGY REDESIGNED IN PROTEGE FRAMEWORK 228 APPENDIX D MANUFACTURING ONT OLOGY REDESIGNED IN XML 233 vii .25 a. Cafmrlson bE’. {a OZAQSSUEFEK rtcoe:~ 1‘ Fta‘ OHS cccccccc 'a:-:3.i cactofaCCI .lm‘ “Ff [A ”‘3' h Ltit UIIV VII 'I‘ 1:559'2131ieT-so‘ve's .luafl A I m uesc'pt'o“ o‘tx: ; HA I163”. oouoocooluunlnu 'r;7 ‘:""i f -. . . Leso La... ::3 “AMA 'IS a MI 0'- . UV Va‘ OII UL LIST OF TABLES Table 1. Comparison between the discussed approaches ................................ 43 Table 2. A possible mapping between frame-based and unary predicates representations ........................................................................................... 44 Table 3. Impact of applying DSSA methods to DICAM ..................................... 61 Table 4. Function ontology for GT based problem solvers ............................... 101 Table 5. Problem-solvers, participating in Socharis *. ................................... 100 Table 6. Description of types of behaviors employed in Functional Model of l-KBS ......................................................................................................... 105 Table 7. Variables of Layup Refiner Port Manager. ....................................... 119 Table 8. Comparison of the S-Force with other methodologies and Shells. 159 viii 1'37. Prc-be P-SO'VI“; 2 Backward ArC' :.."33.E xa~ple 01 KC 4 Q r : 235-. $396 ".5 oi of t' ’.= .Szfee'ishol ol l. A VCCA .................... ;.:'-6. PSrfiow diag'a ;.e.'. 36’9".“1‘65 Ola, igxei La'TeBach: I :93?” pe B ackE 35:3 ‘u'ayBOx ......... ‘Tncascajgd Seo » -. :‘3'33‘Mwew1 Keg «'= 2 I31 "mas tic _§'5'-P3 rstemSgt- .,._ ‘v v: ‘A j “1 593467138 of ll".‘ . .':.; he. " ' U. U alec mafi'hp- 4A N U a: E; ' ""53'09xcars ~ ‘ 7 ODOR fig PUT. II.” . Ilyt‘ IIDn 'n . ”an“; 19 Dane OI .b :.* gejmesva'a" ’ 'c :. _ 2319 ““W var ' :L .26 885 Q the '88 I I": 1‘! eff n aCElOrgef .9“ AC ”mm " ‘gOf V352" ' .:"'v ~Q 1 .~.- 35 h . Ea] ir‘6;:' a ‘V s F t. CH I.‘~ ‘ fl "fisafib 1. INTRODUCTION 1. 1. Motivation Since the 1960s research in Knowledge-Based Systems (KBS) has produced many successful practical applications in various domains. Bu dissecting problem-solving patterns, several schools of thought developed a number of general—purpose problem-solving methods (PSM). These methods are often used to solve a particular task. Meanwhile, the majority of practical problems require the use of a number of different PSMs to solve the problem at hand. An alternative to the development of a monolithic, large-sized KBS which incorporates all necessary PSMs is the development of a K88 that consists of a number of cooperating problem-solving units each of which is an instantiation of a specific PSM. Often such an instantiation leads to the development of separate knowledge-based system resulting in a collection of separate problem- solving modules. In order to perform a designated function, this collection of problem-solving modules requires careful and precise assembling or integrating. Such Integrated Knowledge-Based Systems (I-KBS) are an emphasis of this dissertation. I define an Integrated Knowledge-Based System as a K88 which consists of multiple, disparate problem-solving modules co-operating to solve a given problem. Ontological research has suggested that the use of shareable domain ontologies as an inter-agent language is a practical solution to the problem of communication between disparate modules. However, integration of a number of (w‘MQ-baSEd S v Q v.-- has: an Te: 8 w . »:- coy-Ma: 3'} {CW8 ’ 1A 0 1::1.‘es cl 3:, :.-r1 ‘4 395337.871? as an e. —1:..we'e c191 7*el03,, s of :r A. ’0! ’.' NV ‘1 h" .1 "A3 6 we av U | 4,. A j :1 \iHAJA " h v "" ' Ha“ MA U ‘,‘ Iv in“ '\ v. ”V Lt‘QLQIA ~ av“ do Is L‘ . i':;“‘ f V | knowledge.based systems in the l-KBS is more than the definition of a communication media and language; it requires the determination of the control and information flow as well. Software engineering practices suggest using the derivatives of object-modeling techniques (OMT) and component-based system development as an effective way to develop software systems. However, these methods were often neglected in the methodologies for development of knowledge-based systems. The focus of this dissertation is the development of a methodology which allows the integration of the disjoint knowledge-based systems into a functional l- KBS. 1.2. Importance of the Research KBS development methodologies, knowledge acquisition, knowledge re- use, and integration techniques for large-scale intelligent systems are the topics of a significant amount of research in the US and Europe. The importance of KBS research is underscored by the endeavors of European multi-national projects (such as ESPlRlT-l and ESPlRIT-II (van Heijst, Schreiber et al. 1997) (Wielinga and Schreiber 1994) and Vital (Motta, O’Hara et al. 1994)) as well as by support from US governmental agencies (such as DARPA1 (DAFiPA 1998) and NSF’s2 program on Knowledge and Cognitive Systems). in the introduction to DARPA’s High Performance Knowledge Bases (HPKB) project, it was noted that ‘ Defense Advance Research Project Agency 2 National Science Foundation “gheAl K58 0: gm: ng-fj1wgkncwlec, .1; es for as“;_ 91‘5" iu1da1ewtal D’C' («21-9399 bases ha. 19:52:11 techno-.95 1‘11‘al payofli 329'? es remem. T115 DVD-grass m f' 1:312:31 oi sy'SIens 1": IN" 1'1 a“=-.1.t;on was in ' JV! unv ‘g‘h-Nn' ' "own: ....w:?gv95 Enid Ou'v .x 153'“ 5:“ ed (new 6: Ll Research Conte. Advances in Obj-‘3: 3113:2191 oi the Ufiive In- ! l” V». 5v.‘.. “6.869188 as a v9 “[The Al KBS community] reached a threshold where the power gained from applying knowledge based technology is much greater than in the past. Techniques for creating large knowledge bases have advanced significantly. Many fundamental problems of how to perform efficient inference on large knowledge bases have been solved (although others remain). Many specialized techniques for creating and applying knowledge have matured. The potential payoff from combining all this research progress into one program is tremendous. ” (DARPA 1998) This progress in the K88 field made feasible the development and exploitation of systems intended to solve large and complex problems. However, not much attention was paid to the issue of development of practical methodologies and developmental environments that would support building complex integrated knowledge-based systems. 1.3. Research Context Advances in Object Modeling Technique laid the basis for the development of the Universal Modeling Language (UML) (Fowler and Scott 2000) that serves as a very expressive and convenient medium for modeling complex software systems with intricate communication between its different components. Rational Rose® — a commercial tool based on the UML — provides a “what you see is what you get” environment for modeling complex software systems starting at the conceptual level of requirements definition. As a result of the modeling process Rational Rose® generates a skeletal code in one of the object—oriented languages of choice: C++, Java, Visual Basic, etc. This skeletal . ”,3 ‘3 126: .3195 g. .e.,r1_ 2515:: of each 0:193" 31111123212315. As I: «an; 0" A“! , r F 5-139. 1e 5.1.113 9 1 ares without worn.“ 1 2’-:'e:"e.1':g them on g Vupr ..1e1:s. A: the $311: .r‘vté.‘C".-€."1’. iaCKS aPy St“ ...’ ““Am I , ,. ......ar;ce (“CW 9‘ :‘f ‘ am - Mime-cones: The 699900 Tag-r, n. ' I “ .‘3‘ \ '1 e~~210fconstr Mm.“ 5'UV\ ‘3 >535 that Its terra‘a Ityfctes u, e “- W.. M “'1‘,“ “we a 061731.04. ‘M ~ ., 5 he Inle'e“ WV 1 v ‘ E 35:: +1. . on ..,'e Driqfiinl “V'H'e 0f (1 i “N. 2‘1 m“. u ‘ - " ‘0r 9 r [0,, 91359171.. D ‘1 has 3c32a¢. 5" I l 15 aheha‘l . . " ”'81 ¢ tin... S code provides guidelines for the designer team by defining the input-output interface of each object, object specifications, and the channels for inter-object communications. As long they do not break through the defined in UML interface, the software engineer can implement the objects and define data structures without worrying about integration issues. By storing object models and retrieving them on demand, UML not only allows but encourages reusing components. At the same time, however, the area of knowledge-based systems’ development lacks any similar methodology applicable to designing large scale, high performance knowledge-based systems. The need in such a methodology and a proof-of-the-concept tool motivated this dissertation research. The Generic Task (GT) approach (Section 3.2.3) provides large—grain templates for constructing knowledge-based systems. However, GT is brittle in a sense that its templates are rigid and pre-defined. Therefore, in order to accommodate a deviation from a template it is necessary to re—program the code that governs the inference and/or knowledge representation in the template. This defies the principle of having a certain number of reusable, unchangeable templates for the problem-solving needs. On the other hand, it is often possible to identify parts of the overall problem that could be effortlessly tackled by one of the templates. This poses the problem of how to effectively integrate the resulting problem-solvers so they not only function properly, but the overall problem-solving organization is understandable and manageable. The alternative is to design KBSs following the CommonKADS approach (Section 3.2.5) and decompose the problem into a large set of primitives and 1a: rte-rate them in 111.1311ec‘ sesaraie 1, as: ass on the dew :’::’é"~$3".1i1.g mac-.12 3' ‘ f hfi,‘ QIRHADM Ire PhF‘IA. 'I'V' i u- v. usyU§VI VV' .V ' T15 dissefiatpn a ’Pn- d 11.13331) DQQ'aTm-fl :1..1«s.ea:.1.olw1..:h ca 3:11; imitate. By a ...e'1-scrver as at a C ”1‘00 or :m .1: r3 “Elf gem?“ “v :“E 1 Efnfi'a'g :- f' d“, ‘U. flfi. w bm Vtfl'cc A':~. } ."': analglfl“ ‘On 0? 3 :2:- then integrate them in a knowledge-based system. Each primitive module is programmed separately and, on practice, can rarely be reused. In a nutshell, it also relies on the developer’s programming skills to implement and integrate problem-solving modules. This approach results in the system with the problem- solving architecture concealed inside the code. This dissertation describes a methodology that eliminates excessive and unnecessary programming for problems that could be decomposed into smaller chunks, each of which can be solved by application of the large-grain problem- solving template. By assuming the black box stance i.e., looking at every problem-solver as at a black box with known functionality, inputs, and outputs, and using the Knowledge-Level Architecture Hypothesis (Sticklen 1989) (Section 3.22), it is feasible to compose and describe the problem-solving architecture of the integrated system. The composition of the system includes explicit specification of communication channels between co-operating entities and specifying their activation condition, whereas the description of the functionality of the integrated system should be built on functionality of each participating _ problem-solver, its connections, and its supervising control structures. In addition, the dissertation methodology provides implicit guidelines for designing an l-KBS: first, to decompose the problem into the chunks that could be easily handled by a single pre—defined template and second, define the communication and control flow between such modules. It is important to understand that the practical application of a knowledge-level architecture to design l-KBSs became possible in the light of recent advances in software engineering (Section 3.4), 39" "- ‘ MET-'75: war glsectcn 3 3': (L1 The iii-'89 ”131715 l. The new edgeLe. ' tar: idea of KLA 093.";358d into Sc: .t-agems and see; 5.”...Jre. The KLA. " Kmet‘aVOra Ctr. t acct-cation of Sl‘fware systems ”flames in 02:33: W’s'ilcatl. n me: '6 CO." 369' “a“ 18’. A cit-211$ In ‘ he CC" V...“ . U1 .. to 018" fl 9085 " may ‘5e AI ' ba'v‘EG-Wc E's * . k T hl'dv the C y Tait a t r -nQn§ 3“ .5 thaé .Ef‘nl communication techniques and approaches (Section 3.4), and component-based programming (section 3.4.2). The three mainissues that prompted this dissertation are listed below: 1. The Knowledge-Level Architecture hypothesis (KLA) (Section 3.2.2). The main idea of KLA is that if an agent [a knowledge based system] is decomposed into sub-agents [problem-solvers], then the composite agent can be understood at the knowledge level by a knowledge level description of sub-agents and specifying the sub-agents’ integration and communication structure. The KLA model of an integrated KBS is then used for validating the K88 behavior and finding integration conflicts in the l-KBS architecture. 2. The application of Function-Based Reasoning (FR) theory to modeling software systems 3. Advances in ontology research suggest using a domain ontology as a communication media for inter-agent communication. A domain ontology is the conceptualization of facts, terms, and assumptions and their inter- relations in the domain of interest. The purpose of domain ontologies is threefold (Gruber 1992). First, it helps to organize the domain terminology and to clarify possible misreadings of a term. Second, it helps in creating a database backbone for the multitude of problem-solvers in the domain of interest. Third, the ontology serves as a basis for inter-agent communication. That is, agents that participate in the problem-solving process communicate using this ontology and interpret it in the same way. lel? show that :esgvg and model r‘ saw-3‘ vnmx vu'c‘lme u l. It is '5qu a'ewc'ly used in :f- n A , rig-3 control a'crize S '5'5 PS) 33:! Exe: D A L k”,: 9': Contra! 1:62" , I ‘ I riec demo the g \- Ween is ‘ by! ._ A q . George-G C «A FEX. :le COHO'OI lam. :XtcutSl 0'36? a'e s :"h¢ ‘v ‘M' 'O . .S The mew ‘ '\ J35 ”We “IV Ag “~129th . ¢':e'!f' I will show that with some augmentations, the FR methodology allows designing and modeling integrated knowledge-based systems utilizing arbitrary control structures and with an emphasis on the system’s knowledge level architecture (KLA). It is possible to recognize three major control structures that are commonly used in the development of integrated systems: 1. Rigid Control architecture (RC), i.e. all interconnections between problem- solvers (PS) and execution order are determined during system development time. 2. Semi-Rigid Control architecture (SRC), i.e. PS’s interconnections are determined during the system development time. However, the exact order of Operation is decided on during run time. 3. Flexible Control architecture (FC), i.e. neither PS’ interconnections nor execution order are set a priori but emerge dynamically during the system’s operation. Modern methodologies for building integrated systems and multi-agent systems often concentrate on the implementation of one of the above control architectures. The methodology proposed in this dissertation aims to enable the l-KBS developer to use any combination of the control architectures listed above to closely fit the control flow of the problem at hand. 1.4. Research Objective The development of an I-KBS poses problems of decomposition, of knowledge acquisition, and of the integration of pre-built modules. The approach proposed in this dissertation aims to resolve some of these problems by: n the mea’ steerstée'fis 3'10 I 2. Tc 3'32." ze the mt: r.:-3.'es sated to s: The research is en n p. ; fllflffl‘ ' m: ...*:._. c353 k-"ICW f ‘-~'m ll ' me. “yeah lnCl’ "‘5 U ' UUH V d . iciezsnocse a 3'3: 531:3:- fro'r. the kn: 1‘. l T: Sic-"Th the met" 1. 2. Providing the means to decompose the problem into the set of manageable sub—problems and To organize the integration infrastructure based on the functionality of the modules called to solve each of these sub-problems. The research is focused on the problem of developing medium-to-large scale integrated knowledge—based systems. The process of building such a system generally includes the following consecutive steps: To decompose a problem into a set of smaller sub-problems that are easier to handle from the knowledge-engineering perspective. To identify the methods that are capable of solving these sub-problems, and if possible to locate pre-built modules that serve these purposes. To develop a domain ontology - a vocabulary of domain terms and their interrelations - to provide a backbone for the individual problem-solving modules as well as to arrange means for inter-problem-solver communications. To implement individual modules. To integrate individual modules in the target l-KBS leveraging available control information. To develop a front-end to the l-KBS that presents the results of the l-KBS run to an end-user. In spite of the fact that many of the above listed tasks have been addressed in often research, the issue of the development of functional l-KBS with an explicit problem-solving architecture, clear but flexible control structures, 3133528316 asses ”em: 3;, dzscusse: Tree are 3813?; I 322'353’. ":g’“, .959 {NSC 73:37 :zIy idecff T I “Mimi ’ .- w-‘l 0’98”:Z€- 133.15 derice in terms .2-3'.a fy of a derice ’“cIesol FR vi“: 3:1 ”1'. N. o A b'llb I I an Emphoy t0 8' ::I:S’fi ‘U C? mig- v 5.:51 and adaptable access to the information flow is an open question. The methodology discussed in this dissertation answers some of these questions. There are several difficulties that have to be taken into consideration when approaching these problems: 0 To correctly identify unitary problem-solving components. . To correctly organize functional decomposition-composition of the l—KBS. . To unambiguously direct the information and control flow through the l-KBS The traditional Function-Based Reasoning (FR) gives the means to reason about a device in terms of the functions of its sub-devices and to compose the functionality of a device from the functions of its components. Following one of the branches of FR, which uses the metaphor of device on software system, we apply this metaphor to an Integrated Knowledge-Based System. To do so, it will be necessary to augment the traditional Function-Based Reasoning theory to allow modeling and integrating l-KBSs as well as the explicit assignment of information and control flow between the cooperating entities. The core of my approach is the notion of function or role of a unitary problem-solver that is looked at as a black box with known inputs, outputs, and functionality. Given the decomposition of the problem at hand into chunks that could be solved by such unitary problem-solvers, the goal is to compose the higher-level problem-solver (capable of solving more complex problem) out of these black boxes. These higher-level problem-solvers in turn are used as black boxes to form higher level modules, and so on. The functionality of a larger problem-solver is a composition of the functionalities of lower-level problem- 5586 The (BSJR C i 33363 is 3 WM— 33:93:16 9'35“?” 15, Deliverablesr The outcome 5' meageeased 533°“? 33:32:33. To DiO‘I‘e Or the K88 5 3e c (3Q: .. -. A-gnertat'cn t'N-AA a vxy'v 1a] OeCOmDCS pa :5. ' ' .3 A.d:tcn of the .3. 3‘3 FUl'lhi:“" ‘ solvers. The result of the goal-driven recursive repetition of the composition procedure is a knowledge-based system that performs the desired function, i.e. solves the problem. 1.5. Deliverables The outcome of this work is a shell that allows building integrated knowledge-based systems using the theoretical framework discussed in this dissertation. To prove the validity of the methodology the shell is used to re- design a knowledge-based planning system. On the K88 side of the research the contributions are: KBS—1 . Augmentation of the Function-Based Reasoning methodology to allows functional decomposition of integrated knowledge-based systems using a limited set of unitary problem-solvers as base-line building blocks. KBS-2. Addition of an Information-Processing layer to the functional modeling methodology which enables an explicit assignment of information and control flow through the Functional Model. KBS-3. Addition of the capability of describing dynamic control over the parts of the Functional Model of the l-KBS, therefore enabling implementation of arbitrary distributed control structures and problem-solving units within the l- KBS. KBS-4. The development of a shell which supports building l-KBSs in the described framework. 10 l.e3 sseI’E’On T er ”‘syxe'n 53026 S “:S‘ed oniy by aft I In A. wits 2313.1 Passzb.‘.ty - ”IE-Cture Of its :3 derelcped S. eianme every p it an.-. «3.03 Ca", 355‘ LPG ul . A! V v 00.3341 f till: 2 , can Vuv ”HO A 3 Ric a II ”7‘1 A upzqfi" 3:53;“ 'p x“, u" h\ _ m JHC‘ : ‘V:§ ' ‘3 d . I Loewe-AI : - w. \_ _ ‘- - {a 6... . ‘:~ A b..- e P.‘.‘n ”-s I'. c’Sl + d \ ~i “‘42.: S “”9 r b‘rdN'IA \ The domain of choice is the domain of manufacturing with polymer composite materials3, where I target the existing intelligent manufacturing planning system - Socharis4 — and re-design it using the approach proposed in the dissertation. The main purpose of this re—design is to ease the maintenance of the system, since Socharis’s control is directly coded in Smalltalk and can be modified only by an experienced software engineer. The redesigned system features: CMD-1. Possibility of on-theofly change in the system’s architecture, the architecture of its components, and the knowledge content. Re-designed in the developed shell the new Socharis will provide graphical interfaces to examine every part of the system and the ability modify them if necessary. Modification can not only affect the knowledge encoded in the system, but also the control flow that governs the order of the problem-solvers’ activation. CMD-2. Explicit definition of the information and control flow between the components of the system that lets the user understand the problem-solving strategy of Socharis. This, in turn, may be used as an educational instrument for teaching manufacturing in polymer composites. An important conjecture that follows from the leveraging Knowledge-level architecture hypothesis is that the methodology discussed in this dissertation allows developing reusable integrated problem-solving architectures for non- trivial tasks in a way that the second-generation expert systems (Section 3.2.2) 3 Composite Manufacturing Domain - CMD ‘ Socharis is the Greek name of ancient Egyptian god Sekar - the god of crafts and construction 11 3:11:13 the deve'Ci 1.6. Dissertation The rest of tee : be ' 53:11:: pose-".1. its. 11:11.11 arid theoret; 1,5:2: the 5555;. - first? oft the p73: :5'15’“a on f'af“65‘5"i ”1911311 tbuIId 1 Kb: 113113.133! dome-I: 1'1'tez1rea'e 3.131355 '5. "vd'e a\£"' MGI' 3W6" mes z prompted the development of reusable problem-solving methods for common tasks. 1. 6. Dissertation Organization The rest of the dissertation is organized as follows: Chapter 2 introduces the domain problem that serves as a proving ground for the advocated approach. Historical and theoretical background is discussed (Chapter 3). Chapter 4 analyses the underpinning theory of the research. Chapter 5 gives a detailed statement of the problem, followed by a description of the approach and implementation framework. An illustrative example of using the developed framework to build l-KBSs is given in Chapter 6. Re-implementation of l-KBS for the described domain problem and discussion of the resulting problem-solving architecture are addressed in Chapter 7. In conclusion (Chapter 8) I address future research venues and general challenges in KBS research. 12 21:1" leg. to deg 12“.“:fcn} and the A 111 or 1.9152193 A 11.135. to. to 3551.15 1::sz 5 v‘vvh V 'e" d'v'es not ‘ la 3“";Ah «~- 51:}, there‘s h 3‘72“: H'h. boy V -»-:sosh.z-"-g. LC: V - a 5 (Se-7155:» iti- 75”'2'c~‘ ‘5‘ ~ “‘58 ca" be 3"»- ' y C?! ’ "'1‘: 8531: 15 55.7] 1. hi . ki 11.. ~‘vl. “"05. "u, I 55.1: v: y y ”a” A‘ 5... f‘ \A 3‘ v I_‘. I ‘F - h v ,Q-‘ih 2. DOMAIN PROBLEM Any research in KBS is usually composed of two problems: the domain problem (9.9. to diagnose a disease, to aid in design, or to find the cause of malfunction) and the Al problem. The latter is concerned with development of new or augmented Al theory. The former is concerned with the applying particular problem solving strategies, techniques, knowledge representation methods, etc. to solve a domain problem. Without a domain problem a K88 researcher does not have any means to support the validity of the advocated approach and, therefore, the described Al method is bound to be merely theoretic philosophizing. This dissertation introduces a problem in the domain of composite materials and demonstrates how the proposed approach to the development of integrated KBS can be used to solve it. The example domain problem (Martinez, Lukibanov et al. 1998; Martinez, Lukibanov et al. 1999) is described as follows: To create a system for generating conceptual manufacturing plans for mechanical assemblies made of composite materials which satisfies the following input output specifications. INPUT: The input to the system is given in terms of a conceptual composite assembly (CCA) (Lenz, Hawley et al. 1998; Zhou, Lenz et al. 1999). A part of the CCA called the configuration model represents an assembly hierarchically, depicting not only assembly-component relationships but also the relationships between geometric parameters and design features of the 13 ash: ““3y W“ 0”” $.36 S’SC‘. .re 0:316 base level ol 3'. 12mg one strut“. reesswg such leaf- '"”“""*s be ween “march?” .. .. N or 3589"" 367N693 objects and t e or swasse'w 325“ OEwe, rodah 993' . am about low: assembly. Within such a hierarchical configuration model, ontological members include structure objects (an assembly or a subassembly), component objects (the base level of atomic parts for the structural assembly), joining objects (fastening one structure or component to another), and feature objects (expressing such features as holes). An ontology of link types expresses the relationships between objects. Link types include part-whole links (assembly- component or assembly-internal joint), join links (expressing connectivity between objects and the joints between them), and feature links (component- feature or subassembly-feature). Each component node contains the description of its type, rough geometry and material class. Each joining node contains information about joining parameters. OUTPUT: The output of the system should be a family of conceptual hierarchical manufacturing plans for the manufacturing of the assembly. The generated manufacturing plans can be used for estimating both the properties of the final product and its required manufacturing resources, such as labor, tooling, machinery, etc. The plan is represented as a directed graph. The knowledge-based system that performs this function - Socharis - was created in the Intelligent Systems Laboratory at Michigan State University. Socharis was created using GT ITS (the Generic Task Integrated Tool Set). However, this tool set does not support complex control flow, which led the developers to code all the control information in VisualWorks Smalltalk. Such “closed source” architecture hinders the maintainability of Socharis especially in 14 at eonronmenl woe: 2:338: moor tobeC . Tbe next sect: osrecge roan-1232:: we: an introd' '-"‘ ”' ,.luwv uvk'U “A; a. .uAS v.- ubl . 21. Introduction A composite ma Quay AI ‘ - v' : c5 (reinforcing VFfiAA-Oiq V- Jab-twin on a ma: u ”298 Specific ber aaobmem: h“, ’ zeroed the “ma: ‘.e.:::.‘;'~- is A.“ 3 ‘ Vite” 8283' I “'3‘: (3'5 03 Oompgqioe \z‘apl "“ vb'areas be \a E‘Sr ' ' COQSE‘WH hi. L ’.'A.3. . "c l 'Eauzecj F‘s“ r f ‘ I j. LnC‘tlQha‘ « l :‘t‘v ‘ :fi "“3 0r SU339cfl V Vs =.=~ an environment where the knowledge base and the control flow should be changed and/or tuned for each particular deployment of Socharis. The next section discusses the architecture of Socharis and describes its knowledge organization, content, and knowledge-level architecture as well as provides an introduction to the domain of manufacturing with polymer composite materials. 2. 1. Introduction to Composites A composite material is a heterogeneous combination of two or more materials (reinforcing elements, fillers and binders), differing in form or composition on a macro-scale. The combination results in a material that maximizes specific performance properties traceable to one of the constituent materials or to the aggregate composite material. Composite materials have been termed the “materials of the future”. However, this increased design flexibility is often accompanied by an increased design complexity. Industrial designers of composite material systems and architectures work within narrowly defined sub-areas because of the vast expertise necessary to cover the entire domain. Consequently, the full design flexibility of composite materials is not typically realized. Design for manufacture has been historically more prevalent for polymer composites than metals. In part, this is because many design factors (e.g. , geometry, functional requirements, production rates, and material system) either constrains or suggests specific composite fabrication technologies. As the selection of a manufacturing process can greatly affect both the functional 15 :fz'e 533d CCSl 03 U3 A, n, fir‘ r"_ 39,36591IC0I'V' ~ lee some. ason of la :thgtn fistotataia; Ore the past se P9 ...'li Syrsf ems LE. codes- "It a c" ,; get .938 Mafia \lllez 3‘.‘A’Q3 A u, , . ~~~~~meooo*e"' ~ 3 9 Doug 3.33.! 855:3;w at”). 6’8 "533‘ exp: wing FEE-m ~ ""3 El’bl‘mg 53- \ l 3”“- 3 33 363513 Dart E 3 3e OE" 33383" 1 GI 72:; ,. ,1“ .th l 34‘ g pidflfie ‘I ";;V:n I g Dla'ts “S‘s . e 3 GEva- , H I C . i. ‘3' .5: EHEA‘ :‘a P3 . 333339;“ qualities and cost of the final product, manufacturing concerns often dominate purely design concerns. Even using solely manufacturing constraints, the variety of available composites fabrication technologies can complicate any conceptual- level comparison of fabrication alternatives for a part. Additionally, designers’ biases can simply eliminate possible alternate fabrication processes, artificially limiting the list of available options. Over the past several years, a software suite has been developed in the Intelligent Systems Laboratory at Michigan State University to accomplish integrated design and fabrication planning at the conceptual level (Lenz, Hawley et al. 1998; Martinez, Lukibanov et al. 1999; Zhou, Lenz et al. 1999)). It supports the conceptual design/re-design process for the transformation of metal structural assemblies to polymer composites. This software suite assists engineers in exploring the space of design and manufacturing possibilities and evaluating evolving solutions without detailed design or analysis. The suite produces a family of conceptual composite redesigns from the original metal part. Each member of this family is a valid redesign option, meeting the original design requirements. These redesigns are passed to a manufacturing planner for further evaluation. By reviewing alternative manufacturing plans suggested for the functionally equivalent conceptual designs, the designer can rule out those that are less effective and concentrate on the more effective plans. The resulting solutions will not only satisfy functional and aesthetic requirements, but can be easily manufactured. 16 The low: ng " l o 23}:.. 336 ”1833121835.- " ‘ .2160. Save. It; 15¢ 3‘: 33:13”. 8 concepts; 75:35:.ng piaonm: . mt Socharis v.2 22 High-Level F 133939 1 reflects t The following discussion presents Socharis (Lukibanov and Martinez 2000), the manufacturing fabrication planning portion of the software suite mentioned above. It generates a family of applicable conceptual manufacturing plans from a conceptual description of a composite assembly. The conceptual manufacturing planning strategy presented previously served as the framework upon which Socharis was built. 2.2. High-Level Problem-Solving Strategy of Socharis Figure 1 reflects the high-level problem solving strategy of Socharis, which mirrors the domain expert view of choosing an appropriate manufacturing plan for polymer composite assembly (Committee 1987; Bickerton, Stadtfeld et al. 1998). First, it is necessary to convert the description of the problem from the product designer description (Zhou, Lenz et al. 1999) to manufacturing engineer terminology. This problem is taken care of by the application of several problem- solvers that filter and convert the data. Along with translating the input data, this problem-solving stage takes care of partial assembly ordering — by developing a skeletal manufacturing plan. This plan is a graphical representation of temporal assembly constraints that indicate assembly operation precedences based on the part-subpart relations in the structure description (i.e. part A can not be connected with part B until subparts of A: A1 and A2 are bonded to part A). The next sub-problem is to process the converted description of every part to rule-out unsatisfactory technologies. The list of applicable technologies then enters the further stage of the problem-solving process which is the basis on 17 eat" pet's refiv‘l" sec «to the tag: ire later 5‘. teammate 2673697633818? . 1:3; 3:2 the reat Sim; so: 35 ct The prgc‘er r" A . I I1. #23 "‘ M in “Hi-wu- ! ' u v\J 3 3‘ l I 3‘51392. Lot :at 333-3392“ Viv» uuv.n. Th (Twain l. ~35 an of; .1.-f .3331 13313333} 1 V “n.| :3 e: 3‘0 33’" E! ‘h. 85. UC‘I 3“-S e V E}: ;\ES;EEE“‘ F t" s HA: V. «cm “~01 c \. :‘H. “I”: fig“ each part’s requirements generates sets of manufacturing parameters, which if used with the target technology will produced the desired part. The later stages of the problem-solving process tend to produce multiple results (a family of applicable manufacturing plans). To help the user to choose between alternatives the manufacturing plans are ranked by a set of estimators that rate the relative merits of each process. This stage concludes the problem- solving process of Socharis. The problem-solving architecture of Socharis consists of a large number of cooperating problem-solving agents. A composite materials domain ontology (Martinez, Lukibanov et al. 1999; Zhou, Lenz et al. 1999) is used to facilitate this cooperation. This domain ontology provides a vocabulary for representing knowledge about polymer composite materials. The domain ontology is a four layer deep hierarchy: Class Category -> Class-) Attributes -> Parameters. Each concept of the ontology also contains a succinct description of any assumptions made. Take, for example, a term definition for Shape -) Shell -) {AspectRatio, WallThickness, ...} —) {{low, medium, high},...}. An explicit definition of a Shell (e.g. , thin-walled planar or curvalinear structure) and its quantitative correspondence to the qualitative values of AspectRatio attribute minimize any potential ambiguity inherent in the term definition. Such comments are mandatory parts of the representation and adds meaning to the syntax of the term. 18 1-.-.‘f‘.'t‘ - r , O O ..-. -. 3'; ,Jf', *— ,— i n. A fi' Conceptual Composite Assembly fig Y —'I Skeletal Plan Creat ion J I [ Transl_z_1tion 1 —>( Feature translation ) ——§( Joining translation ) ‘—>( Shape translation ) ] l—Dl Data transformation 3 Feature adding method J [ Joining Order Identification ] [ Feature Method Selection L Machining Complexity ) 'l Skeletal Plan and Data for "echnology Selection 31nd Refinennent Molding Complexity 3% 1 (Technology Selector/Material) I ( Technology Selector/Shape, etc. ) E . (1333! Bit-Ill: N4 in RTM Refiner ) R, IM Refiner ) ( Swamp Refine}; Ln HEM n“ QM Refine; ) *VL FW Refinery Refined Conceptual Manufacturing Plan DEE as @ooling Turnaround Time‘— ( Labor \4 F Geometrical Regeatabilityk ——-'>( Operator Exposure) {Part Turnaround Ti me) Qtechanreat Properties bfl Skill Level ) )¢ P( Tooling Cost ) Ranked Conceptual Manufacturing Plans fig— Figure 1. Problem-solving Strategy of Socharis. ) 19 The purpose 0" .c'tal terminology a as creatng 3 dat; man of lrte'est. 3.731383%. That my”, sate usfing ti" 3 23. Problem-Sol 23‘. T'aos‘atgr The task 01 this : 15“.“ . ‘ its; 7" ' ‘1 ' " u"EWEVS OCW'TQ 333'FSKD3 ‘ ' U u I: a . .-.e. manuta: :Aa..,‘ , "w“- ”‘6‘wa 5' U . Skeletal p13,1 Cl “’3 '55 ‘k a!“ r‘ ' ' “‘ a =a£y5l$ < “53- Tne ge ”e'ated nu v, and a n n.. . Y re“ 15.3 a n ' “'9 Dian Ts . .ube add“: I‘ Vin-Of A The purpose of these ontologies is threefold. First, it helps to organize the domain terminology and to clarify possible misreadings of a term. Second, it helps in creating a database backbone for the multitude of problem-solvers in the domain of interest. Third, the ontology serves as a basis for inter-agent communication. That is, agents that participate in the problem-solving process communicate using this ontology and interpret it in the same way. 2.3. Problem-Solving Architecture of Socharis 2.3.1. Translation and Skeletal Plan Generation The task of this stage is to create a skeletal manufacturing plan and to prepare design parameters that will be processed by technology selectors/refiners downstream. This task is divided into three sub-tasks: creation of the skeletal manufacturing plan, data translation, and selection of the feature addition methods. Skeletal Plan Creation. Construction of a skeletal manufacturing plan requires the analysis of the existing conceptual configuration model of the artifact. The generated skeletal plan is topologically analogous to the design’s configuration model. At this point, the skeletal plan has only a rudimentary structure, and any required add-on features have not yet been included in the manufacturing plan. These additional details are extracted from the configuration model in a Data Translation. At this stage, the descriptive information about the mechanical structure is translated from the terminology used by designers into 20 ’55: used by ma'tcfa. 2:329 to the mancf. Feature Additl afeeu'e to a cor":~ "35‘7“9. the leatsre «2° whereas in razed. The meth: ”.5.: at that team-'95 VERA" "9 w. 9"" ei it. 2.3.2. Gene'a’” \ Afier a skeletaT i azaian teem-£55393i t 25: 82240338 i RAMA" dU' :vc VII-A‘- ‘h A. ! .hswtCeaCh $6938 Technology Sel featdres f 2} material” feafu" E solvers are l: ~"3‘3-3‘: a given cc'nc: that used by manufacturers. The translation involves a mapping of the design ontology to the manufacturing ontology. Feature Addition Method Selection. There are two methods for adding a feature to a component of a composite part: machining or molding. In machining, the feature is added to the component after the component has been fabricated, whereas in molding the feature is incorporated as the component is produced. The method for creating each individual feature must be decided based on that feature’s tolerance allowances and the production quantities of the component. 2.3.2. Generating the Family of TechncMcal Alternatives After a skeletal plan has been generated, Socharis assigns one or more fabrication technology to each component within the manufacturing plan. After each applicable fabrication technology is selected, manufacturing parameters specific to each selected technology are set. Technology Selection. The first use of the translated data occurs in this stage as the appropriate manufacturing technologies are selected. Two independent problem-solvers select applicable technologies based on (1) geometrical features of the component (shape, aspect ratio, wall thickness, etc. ) and (2) material features (type of resin, fiber architecture). The results of both problem solvers are lists of manufacturing technologies that theoretically could produce a given component. The intersection of these lists, therefore, represents the list of the technologies that satisfy all criteria given in the input data. The 21 ec'"c?:vges 30".; e the process iechnolog :e'aneters lOr ea exec-32:5 le. '5-35'9" "ts ieS ham ‘ “I.“ w" ‘CCfenL Cm: 35'5’7625r5 (e.g. “3 these pa' fin.‘ A . Heavy: w.‘h n‘ l i i “'3 . \ Pa '~. A . 'V‘E'r'lfi,‘ ‘ V v 4 " ~42?“ ' 5 .l . "Eat « - Lav‘ a“:- I‘u'A 5.54 jg ". . .‘ \ vblnfi c U'- \ \ n ‘ JAN _ “VERA technologies contained in this intersection are then passed to the refinement step for further processing. Technology Refinement. After the technologies are selected, the parameters for each technology are defined. These parameters include curing requirements (e.g. , time, pressure, curing type, post curing), tooling requirements (e.g. , tooling complexity, tooling material), and so on. The specific subsets of parameters vary among the different generic technologies. Component data (e.g. , geometry, material, and add-on features) and global parameters (e.g. , production, and global tolerance allowances) are used to define these parameter values. Each generic technology may contain many different sets of parameter values. Additionally, each component may be produced with multiple technologies. Therefore, some way to compare the generated manufacturing options is required. 2.3.3. Evaluation Running Socharis results in multiple manufacturing plans for every part in the assembly. Given the semi-deterministic assembly order, this leads to an exponential increase in the number of possible manufacturing plans. To enable navigation of this expansive space of possible manufacturing plans, Socharis’s last problem-solving stage ranks the technologies according to a predefined set of merits. Merit tables are traditionally used in engineering practice for ranking different design solutions. Every row in a merit table is associated with a critical manufacturing metric (e.g. , cycle time, tooling turnaround time, and operator skill 22 ‘3"¢:l' EaCh meWC . .- aeorgr‘eef. Afieii'"- " a .a‘tct‘le we.) We speak ' elaatet of time (c. rectanzal precede 32.37.!“ 'E’Oi SKl l Lafitte va‘ue item 1 Mn 75‘? a (cd accord... "-" Tileusercan 3.: 5395s only disc'a " ‘:~ ”“93- Tt‘si ac‘ d , \vynfidl Hes'gfi’ 1 ‘95,“. :11." 3. an . I . NJ Of knCV‘v Cs Elia-n . a A," V'v \ '5‘ u ': AA lid UV“, he ' l A.‘ :5:-~'A level). Each metric is linked to a weighting factor that reflects its importance to an engineer. Alternative technologies are ranked according to these merits by calculating the weighted sum of the estimated metrics. The specific metrics used in Socharis were selected to enable the evaluation of time (cycle time, tooling turnaround time), quality of the product (mechanical properties of the product, geometrical repeatability) and human factors (operator skill level, operator exposure, labor). This estimation assigns a qualitative value from one to ten for each metric. The alternative processes are then ranked according to the value of the weighted sum of the estimated metrics. The user can limit the design space under examination by requesting that Socharis only display the best few options for each component to be manufactured. This is possible because of the merit table evaluations. This significantly reduces the number of refined fabrication options among which the user must choose. 2.4. Accomplishments and Shortcomings of Socharis and Application Domain Problem Statement One of the most important contributions of Socharis to the area of conceptual design and manufacturing with composite materials was the integration of knowledge about eight generic manufacturing technologies in one system. This knowledge was specifically structured to suit the problem-solving goals of Socharis: to identify, instantiate, and evaluate manufacturing technologies for a composite assembly of interest. This concentrated knowledge source could be used to plan and estimate the manufacturability of the composite assemblies. 23 Asan lmpfifie rte-get $33935 werjaztmg with C we; is a tour-la: Eefiftifl used to may mismatch. Erin-371ml GT-ba. Emsmg a“: rite generalzaton t scg strategy of c 3335910i (levees-z". If-Ccste matefiats, listed, that a Ltrlw - -...c...nng ontcbg “'5 t“"lt'Ough the taxes a graphica' 'r‘ MET,“ a“? " 1‘ ~. CuL'YTon U i ,. It the km W. "1 ‘aco .. UL! his Cnfi-Q‘bt . “v. (“‘1 :1.“ m‘nfia. i ._ en , at,“ “mile“ | | As an important byproduct of the Socharis project, the research group at Intelligent Systems Laboratory developed a comprehensive ontology of manufacturing with composite materials (Lukibanov and Martinez 2000). This ontology is a four-layer deep class, sub-class hierarchy that accounts for the terminology used to describe both, the manufacturing processes and any auxiliary information. This ontology was used as a backbone for the development of GT-based problem-solvers that cooperate in Socharis. Establishing and documenting Socharis’s problem-solving architecture led to the generalization that these architectures representing a generic problem- solving strategy of conceptual manufacturing planning. This framework is suitable for developing planning systems in the domains other then polymer composite materials. Noted, that advanced users of Socharis have easy access to its Manufacturing ontology and the knowledge content of the constituent problem- solvers through the Generic Tasks Integrated Tool Set (GT ITS). GT ITS features a graphical user interface for modifying knowledge and the internal structure of problem-solvers. As a result it does not take much effort to update and augment the knowledge about the processes that are already part of the Socharis. The same is not true about the overall problem-solving architecture. In fact, this constitutes the main drawback of Socharis - inability to effortlessly change mid- and high-level problem-solving architecture. The reason for this is that the complexity of problem-solving by far exceeded which was presently supported in the GT ITS. The team of designers 24 i.e.: t: 953899 m tire S~afi£ttl D’Qg'am'm emit-e tor 3” a':"te:f:re. Even see e elecatng acct tel-eage ol Shaiita 8336. The 33.33153: siesme these sham; The task of ( I’fi‘Y‘“. A . I 3:.....-e-u Ill this (13: K‘I‘vli" h. ... lg aspects-re 0 :e' for building lr‘.‘ I: F‘A L'- ll'.zma‘t I mason flcw .lt'rw had to escape to the coding of the global control architecture in VisualWorks ® Smalltalk programming language. This led to a situation where it is almost impossible for an outsider to make any changes in the problem solving architecture. Even seemingly simple tasks such as adding more problem-solvers for evaluating additional manufacturing technology requires not only the knowledge of Smalltalk, but also familiarity with existing GT ITS architecture and code. The application domain problem of this research, consequently, is to overcome these shortcomings of the present Socharis Implementation. The task of exposing the problem-solving architecture of Socharis comprises the application domain goal of this research. The application of the described in this dissertation methodology allows representing the problem- solving architecture of Socharis in a graphical, easy to understand way. The shell for building integrated knowledge-based systems which supports the presented methodology allows changing Socharis's problem-solving architecture on the fly, adding and deleting components, reassigning control, and redirecting the information flow. It is necessary to note that the redesign will affect only knowledge-based core of Socharis ; other modules of Socharis lie outside the research focus reported in this dissertation. 25 T. 11. Overview c Tile dismiss: teespmerlt precece. ’Eit ll'ie 0i COr-pa s'ategi'esl and ex; “Pifil Y ' ' ‘M. the man 092‘; ‘;M~ ocsaeie into 5.. wedge level by a 5‘ A .‘t de-fi":nt ' ‘ -. g» is mEC' ~::‘A' q- _ 7- ‘~ 3'“ 3643i Ill 8"” “ to... ...z‘q LO 0 (e of (me r «grf‘fn - 3" “93 DEIOw [x c/ 3 1, J 3. PREVIOUS RESEARCH 3. 1. Overview of Knowledge-Based Systems The discussion about control architectures commonly used in the K88 development precedes the overview of knowledge—based systems to provide a new line of comparison between different approaches: prevalent control strategy(ies) and explicitness of their Knowledge Level Architectures (Sticklen 1989). The main idea of Knowledge Architecture Hypothesis is that if an agent is decomposable into sub-agents, then the larger agent can be understood at the knowledge level by a knowledge level description of sub-agents and specifying the sub-agents’ integration and communication structure. KLAH discussed in a greater detail in Section 3.2.2. 3.1.1. Control Architectures All currently employed KBS development integration schemes could be related to one of the control architectures or combinations of these architectures as described below: 1. Rigid Control architecture (RC), i.e. all interconnections between problem- solvers (PS) and their execution sequence are determined during system development time. 2. Semi-Rigid Control architecture (SRC), i.e. PS’s interconnections are determined during the system development time. However, the exact order of operation is decided on during run time. 26 3 Flexible Control execution order a steam. These control I‘- I p "“9“?" knowleog. RC has an e. era‘on of the sys: U at any connecte :afceatog (Noble? teet‘reess, the as: 'E‘Ef‘.'-'3i‘y‘ complex pro: to: “.onpiex probes“ Diver-33 Dy Riga Contr— i't.‘ 'me'cmneQEQ a. 3. Flexible Control architecture (FC), i.e. neither PS’ interconnections nor execution order are set a priori but emerge dynamically during the system’s operation. These control strategies differ significantly in the expressiveness of their respective knowledge level architecture (KLA). RC has an explicit KLA that is understood through input and output information of the system. Moreover, one can always perform an analysis of the KLA of any connected subpart of the system by analyzing the roles of each participating problem solver, information flow, and execution order. Nevertheless, the application of Rigid Control to the development of KBS for relatively complex problem rarely results in the most elegant or optimal solution, since complex problems seldom follow a simple problem-solving strategy thatiis covered by Rigid Control. In addition, this approach suffers from brittleness (i.e. unpredictable results for unexpected inputs) and often. Similar to the Rigid Control architecture, KLA of the Semi-Rigid Control could be expressed in terms of its input and conditional output. That is, given any interconnected subpart of the system and purposes/roles of each cooperating problem-solver one can determine the conditions in which this subpart will be active and the role of this subpart in the overall problem-solving process. However, the main drawback of the Semi-Rigid Control approach is that it does not provide enough run time flexibility, especially in case where emergent behavior is important. Another shortcoming is that this approach 27 $.37) r cuties ha' mates manta"; KLA of Flex: ere resorption of e , I tease of the whore 2:17.3th of me 39297361395 are no; L- are - “I It": .5555, thls as.“ . mete'miaiion 9'3 ate 3+3” (I "" w 3' 0f ki‘Cw 6’3“?““n .....J: at DOCKEKEE Tits dissertatc Q's. 850‘} VVLOn 3.1 .2 e‘,~.;,‘!w “"9"“ mew ..- L u re ._ ' “Lllffiht tvaJre as 31": to 5"s. at l G133 usually requires hand coding of conditional activation of problem-solvers which complicates maintenance and debugging of KBS. KLA of Flexible Control is difficult to determine. Given the knowledge- level description of each of the problem-solvers participating in K88 and the purpose of the whole system, one can hardly understand the role of an arbitrary combination of methods since their interconnections and input-output dependencies are not explicit and emerge only during run time. Flexible Control provides flexible, dynamic control over global problem solving process. Nevertheless, this approach also suffers from several shortcomings: . the termination problem (i.e. how do we know that result has been achieved) and . difficulty of knowledge debugging (the need to debug KBSs demands additional bookkeeping of activation records and problem-solving context). This dissertation describes the framework that allows developing and modeling KBSs that is able to use any of these control architectures or their combination. The implementation supports use of Generic Task (GT) (Chandrasekaran 1983) problem-solvers as bottom level building blocks for an I- KBS, however there is no theoretical limitation for types of individual problem- solvers. Section 3.1.2 provides an account of knowledge-based systems’ development methodologies with respect to the openness of their knowledge- Ievel architecture as well as to their ability to handle different kinds of control strategies. I also compare these methodologies along several directions, such 28 as exp‘ctoess ol : segment shell. State 198:), ti: 5 319139?an malOTi' 9 "a Thhm .n A‘I fi‘A 'c ”Wa‘ auia ac. 3.‘.2. Fife—E Deso'te the se it: is to encode lF eraezle raleoased A Jr :- «C 22:243.". System (F it is easy to SE‘ “EH3 i v » lure Is a SEDara Mario! drama, . In. "A ANDe-tve 0‘ ex;|.' 03"” as k" lasolm, l. l Nix 0f eVlGeh‘t ‘ as in the K58 it ‘ OI ll| ll‘ . 5f] as explicitness of the knowledge-level architecture and the availability of the development shell. 34.3. Rule-Based Systems Despite the serious critique of the rule-based methodology (Buchanan and Shortliffe 1984), this approach is extensively used in practice. In fact, the overwhelming majority of the commercially available K883 and KBS shells follow it. The main advantage of this method is its simplicity. All the developer needs to do is to encode lF-THEN rules using one of a large number of commercially available rule-based system shells (e.g. CLIPS: C Language Integrated Production System (Riley 1998) or Jess (Friedman-Hill 1997)) It is easy to see that a conventional rule-based system uses the FC where each rule is a separate problem solver. Major drawbacks of this approach (save for the usual critique) are: . Absence of explicit control, which is usually programmatically encoded in the conflict resolution strategy. . Lack of evident knowledge-level architecture. That is, the purpose of each rule in the K88 is unclear. Moreover, how rules are activated and selected in case of multiple firing is hidden in the conflict resolution module. This hinders structural analysis, troubleshooting, and effortless re-use of rule—based systems. 3.1.3. Hardwired Systems Hardwired systems represent a sizable portion of modern industrially used KBSs. Following this approach, the system is built of a number of modules 29 rose ways ol c 0mm fion is ‘. carries. This is a :: There are se. acreage is the e acre-ire of the S“: :55}, vete'nioed by nomination Chan." :ess to judge the rc :rcvc‘es a valuable a 3'3 $333.56” '. ' . " ““ limos C. Cf:.fla ‘ 3: :1 Oba‘. rn'hi “ ‘ pl V‘LJEE whose ways of cooperation are decided on at the development stage. Communication is usually done through sending messages over pre—defined channels. This is a clear example of RC. There are several benefits in using hardwired methodology. The main advantage is the explicit control and ability to assess the knowledge-level architecture of the system. The role of each component of the system can be easily determined by its input-output information. In addition, pre-established communication channels between different components of the system give the basis to judge the role of every inter-connected sub-part of the KBS. This provides a valuable assistance in determining knowledge flaws and conflicts in the system. This, in turn, enables easy maintenance of such systems. The major disadvantage of the hardwired approach to the development of KBS is the system’s brittleness. That is, the system can function unpredictably for certain groups of input. Another drawback is the system’s inflexibility to change global problem-solving strategy without ad hoc methods. 3.1.4. Blackboard-Based Systems A distinct family of KBS architectures is the successor of the “blackboard” approach initiated in mid-19703 by HEARSAY-II project (Erman, Hayes-Roth et al. 1988). One of the first available shells for development of blackboard systems was Stanford KSL’s BB1 (Johnson and Hayes-Roth 1987). B81 has a generic blackboard architecture that is represented in Figure 2. 30 Figure 2. 83a: Toe Software “H (33}. 33°f7i5ute ir‘. 33.2155“ 9333 K8 is .3153», any Sc: ‘AA- “VA. v-=‘I II {— ‘I Sources Blackboard Control Shell Figure 2. Blackboard Architecture The software specialist modules, which are called knowledge sources (KSs), contribute information that would lead to the solution of the problem. Usually, each KS is a planar rule-based system, though KSs’ internal architecture may follow any suitable problem-solving methodology (Vranes and Stanojevic 1995). The blackboard is the database that keeps the current problem-solving state. It could be seen as a collection of global variables accessible by all participants of the problem-solving process. The control shell governs the flow of problem—solving activity in the system. Based on the blackboard context it decides which of the KSs is to run next. The control shell is also traditionally implemented as a planar set of rules. Carver et..al. (Carver and Lesser 1992) noticed a control problem with the blackboard approach: ‘What makes blackboard control difficult is that it can be 31 tableware settse there may ire convent rszer‘, augmenta’. : M.‘ l" e o sail. methods a. . cs backboard is p; '7?"va sets of wo' t er 3% a. HOW'a' r I .T‘n. . ‘U 8‘ :‘II ' C fir P“ U I . i v “FMS ‘ S‘.‘ . “l 17"“ ““87; 8.2, highly problematic to determine expected value of KSls [knowledge sources] because there may be complex interrelationships among the KSIs.’ The conventional blackboard approach follows the FC. Nevertheless, modern augmentations to this methodology leverage the convenience of SRC and RC methods at the knowledge source level. That is the separate knowledge source might be constructed by following these approaches. (Hidlum, Sadeh et al. 1996) describe a blackboard-based system where the blackboard is partitioned into the number of contexts that correspond to different sets of working assumptions and different solutions and are active at different times. By doing this the developers limit the amount of knowledge visible to knowledge sources which, in turn simplifies the control. One of the attractive features of the blackboard approach is that it fits the hypothesis about the nature of cognition (Laird, Newell et al. 1987), (Brooks 1986). According to this hypothesis, different modules that are responsible for different aspects of cognition are active all the time and constantly processing information. These modules post results of their processes on the common media, so different sources may use information collected and processed by different modules. Another benefit of the approach is its implementational straightfonrvardness: given a problem, one needs to break the problem into smaller chunks without worrying about explicit chunks’ interconnections, one simply implements a problem solver for each of the chunks and links them to a shared blackboard. 32 However, t' 5353.27.22.95. La 3:37.09 its knov.» ciaxarooaseo K I. sch; role of any p; From the Ge sectors-are KBS is t I 'gceerfng (Schach 1. Tie causing of erase (the ca: affects: tlltalrttena'tce: another inter, variaCEES; ‘ZSeCorlty: a F allowingfcr; Z The structure 0 Shani“. ‘ ”we 0i coin: H 2. pt. . Cc is ”Qt elf-ma 833553 to the 555.5, . t " Wu" I M.‘ . t)leljt‘l‘el'r‘ However, the blackboard approach suffers from several significant disadvantages. Lack of explicit structural control knowledge and the inability to describe its knowledge-level architecture makes it difficult to maintain the blackboard-based KBS. Moreover it makes it impossible to describe the problem solving role of any part of the blackboard based KBS. From the development point of view, the way in which a particular blackboard KBS is being created defies several major principles of Software Engineering (Schach 1997). 1. The coupling of different problem-solvers is achieved through the global variable (the blackboard) which is considered bad practice in SE because it affects: 1.1.Maintenance: change is difficult, since with each instantiation of PS in another integrated KBS the developer needs to duplicate all global variables; 1.2. Security: a PS may be exposed to more data than it needs therefore allowing for potential breach of security. . 2. The structure of the generic control module (flat rule base) follows the principle of coincidental cohesion, i.e. it performs multiple unrelated actions, which degrades maintainability, and hinders reuse. 3. Data is not encapsulated, that is, every participating problem-solver has direct access to the variables on the blackboard, which potentially brings the security problems. 33 i" -. . ~ lie l...p'.r.”.c' Leve- Hypothesis l" (‘5; ‘gq‘n I I 31.359 level. ln 1 8'2er not be a (m .55.,“ . to the recro ":eoew ' .v nest of th 3.2. Task-Specific Architectures and Integrated Knowledge-Based System 3.2.1. Knowledge Level Hypothesis The important milestone in KBS research is certainly Newel’s Knowledge Level Hypothesis (Newell 1980) (KLH), where he suggested the existence of a knowledge level in computer systems which lies directly above the symbol level and is implementation independent. Newell argued that the representation itself should not be a topic of interest, but rather the nature of knowledge and its relation to the representation. The use of the KLH allows systems description independent of their internal representation and implementation details, which, consequently, suggests a systematic approach to the system’s analysis. Newell also introduced the notion of a rational agent that can be reasoned about in terms of its knowledge, goals, and behavior. KLH was criticized in (Sticklen 1989; Velde 1991; Velde 1993) because of its lack of concern about control knowledge, its non-operational character (it can only describe existent systems and does not help build new KBS), its not recognizing an agent’s ability to be decomposable, and its lack of predictive power. Nevertheless, the power that the KLH provides for KBS analysis guided numerous research thrusts in the KBS field that investigate problem solving methods, behaviors, and strategies. 3.2.2. Second Generation Expert Systems Clancey’s (Clancey 1985) analysis of MYCIN, his description of Heuristic Classification, and Chandrasekaran’s (Chandrasekaran 1983) work on reusable problem solving models led to the crystallization of the idea that there are 34 xenon inference ’AH‘ 5' 'fi. 3,5519%), $0.l.,.g. tits-stores USA. HAP, In R‘ 5:3 care-rd. on. lfi zA' A“. may rely on :MIM- .4 .....e...~.'e of the ; 08203; fits of EX; 392139 Other e *5‘. . ,‘b- F» AIR“ . ~19. " " in V'Vu‘,‘VS C! b. ‘Sfie' ‘RA “.5 a task ...st An common inference strategies or inference structures that can be used for problem solving. This is the working hypothesis of the Task Specific Architectures (T SA) “branch of’ KBS research, which heralded the beginning of Second Generation of Knowledge-Based Systems in the early eighties. Since then, methodological approaches to second generation expert systems almost invariably rely on mapping the structure of a knowledge level model to the architecture of the application. McDermott’s (McDermott 1988) role limiting models, Steel’s (Steels 1990) components of expertise, and KADS knowledge sources (Balder and Akkermans 1992) are other examples of generalized inference strategiess. The mentioned methodologies differ in several aspects: separation of the domain factual knowledge from the problem-solving knowledge, granularity of tasks that are chosen as basic inferences, etc. Nevertheless, each of the TSA approaches considers a task decomposable into a set of sub-tasks, where each of the sub- tasks could be solved by the application of a particular, generalized inference structure. Unfortunately, KLH does not provide insights on how this decomposition could be analyzed. On the contrary, it regards an agent as a non- decomposable entity. Sticklen (Sticklen 1989) suggested an augmentation to KLH which he called Knowledge Level Architecture Hypothesis (KLAH). The main idea of this hypothesis is that if an agent is decomposable into sub-agents, then the larger agent can be understood at the knowledge level by a knowledge level description 5 I will discuss the details of each mentioned methodology in the later sections 35 . -. l c" titted?“ a. ” Stride. Anotbe' assert solver 10' asrzecture. The C rm") OI the Gilli (Sitt‘eil 1989), at." escroosablllty. Y resigated by seve Steels (Steets eat lies directly at tezccoesed into rr be sb‘esks exec: 4‘ filer where it" .-. .Ct‘JeS. KLH h seats decompose All task-so “ecossaoliaty in teat: ~ .. tied probe 3' firm 32' H- -. . f‘ m it“ . ”.h\ 5' 0r: Hbs.tl" ‘:"‘A of sub-agents and specifying the sub-agents’ integration and communication structure. Another important contribution of KLAH is that it suggested that it is possible to create a model of a decomposable agent and use that model as a problem solver for validating the agent’s behavior, finding conflicts in the architecture. The paper was critiqued in (Clancey 1989; Slator 1989), but the majority of the criticism was targeted at the philosophical issues raised in (Sticklen 1989), although not all the critics agreed with the idea of agents’ decomposability. Yet, the similar ideas about agent’s decomposability were investigated by several researchers in KBS community. Steels (Steels 1990) defined a similar idea of knowledge use level: a level which lies directly above the knowledge level and which focuses on how a task is decomposed into manageable sub-tasks, what ordering should be imposed on the sub-tasks execution, etc. A similar idea underlines the concept of the KADS task layer where primitive inferences are combined in the problem-solving structures. KLH has evolved to the stage where it accepts the concept of an agent’s decomposability. All task-specific methodologies are based on the idea of task‘s decomposability into a number of subtasks, each of which could be handled by a pre-defined problem-solving method. However, the brittleness of large-grain Generic Tasks (Chandrasekaran and Johnson 1993) and vague approaches to task decomposition in small-grain problem-solving methods as in role limiting methods (McDermott 1988) and KADS (Wielinga and Schreiber 1994) caused 36 researched ‘0 3555.n;.5s;tlon as: 3.2.3. GENE The idea . tray in which CE stars. or disease arisen soivrog l 1993) The Generic tsetse: on a num: lite GT approach WC Slate Ulll‘xrer 75,, ’3 ‘ 98”) '805 ‘ lit- ‘ aDD'oech in (“at "‘5 that Sit.“ ' “Wenia‘j0n . Tax h . gnome C lvll ., +1. “Jan-JR at It‘s lL/Han'fl ’ H ER: VV( :1 Va’I’P 7‘ “U1 . I" ' VG! researchers to develop tools and methodologies that facilitate task decomposition and sub-task integration processes. _3_._2.3. GENERIC TASKS ‘The idea of generic task is not that interesting until we realize that the way in which generic tasks are executed shows many similarities across application domains. [for example] In the diagnosis of circuits, cars, power plants, or diseases, significant elements are in common, specifically, the same problem solving methods and the same types of domain models. ’ (Steels 1990) The Generic Task (GT) approach is a "large grain" view of problem solving focused on a number of primitive problem solving types - called "generic tasks". The GT approach was developed at the Laboratory for Intelligent Research at Ohio State University by a team of researchers led by Chandrasekaran in late '703 - early '805 (Chandrasekaran 1983; Chandrasekaran and Johnson 1993). This approach includes task -Ievel implementation, reusable, and executable shells that simultaneously support knowledge acquisition and system implementation. The list of primitive generic tasks is as follows. - Taxonomic Classification Task - Classify a (possibly complex) description of a situation as an element, as specific as possible, in classification hierarchy (Chandrasekaran, Mittal et al. 1979) (usually referred to as "hierarchical classification") - Function-based Reasoning - Given a causal understanding of how a "device" works, answer "what would happen if" type questions (Sticklen and 37 Chandraseka'a absf'action") . linow'éedge Dire obfain attribute: dafu'n i Object Synthes. safsiying cedar referred to as "to . Hypothesis mat: describe the pro . Addodive Asse exofained by tt east. associate Detion of the c Oi the given by; h COLIld be 1 378 Covers all DC a m‘ieniem me o ”Eh. I "my“ .y e? a! 11 "’2. 1‘3" Chandrasekaran 1985) (this primitive task was originally called "state abstraction") . Knowledge Directed Information Passing — Given attributes of some datum obtain attributes of some other datum, conceptually related to the original datum 0 Object Synthesis by Plan Selection and Refinement — Design an object satisfying certain specification (Brown 1987) (this primitive task is usually referred to as "routine design") . Hypothesis matching — Given a set of hypothesis and a set of datum that describe the problem state, decide if the hypothesis matches the situation . Abductive Assembly of Explanatory Hypotheses - Given a situation to be explained by the best explanatory account, and a number of hypotheses, each associated with degree of belief, and each of which offers to explain a portion of the data, construct the best composite explanatory hypothesis out of the given hypotheses. It could be said that one could never be sure that the list of above sets of GTs covers all possible situations. Nevertheless, the GT methodology provides a convenient mechanism for identifying an appropriate problem-solving method for the task at hand and has been effectively used for the development applied IS (Sticklen, Kamel et al. 1992; Sticklen, Kamel et al. 1992; Moy, McDowell et al. 1995; EI-Sheikh, Sticklen et al. 1996; Lenz, McDowell et al. 1996; EI-Sheikh, Penney et al. 1997; Kamel, Lukibanov et al. 1997; McDowell, Sticklen et al. 1 997), etc. 38 lSL's Gen lotioaoov et al. re Generic Task c asserts wrtlt we (33$ built in this atoning soecga Elected. Limitat-o "e systens betrav tees to the near 3.33: oi the she-1;. TIPS (Punc: $136593 D'Ob5ef: 339533” 0i probe 1.. 's93’aied K33 w. l “Al: :6... ISL’s Generic Task Toolset (Sticklen, Kamel et al. 1992; Kamel, Lukibanov et al. 1997), supports the development of integrated RC KBS within the Generic Task approach. This tool supports development expert systems for problems with well-defined and run-time unalterable control flow. KLA of the KBSs built in this tool set is also easily identifiable, since the roles of each participating specialists and each connected group of specialists are explicitly specified. Limitations of this method are evident: inability to dynamically adjust the systems behavior and inability to adopt flexible control architecture, which leads to the necessity to hard-code control mechanisms programmatically outside of the shell. TIPS (Punch 1989) is an architecture that allows integration of existing GT-based problem-solvers using sponsor-selector mechanism. TIPS is a collection of problem-solvers linked together via sponsor selectors. To create an integrated KBS within the TIPS framework the problem is first to decompose it into GT-based problem-solvers. Then each problem-solving unit is associated with a distinct sponsors-selector that controls the problem solver’s activation. Finally, it is necessary to specify a priority order for conflict resolution in case of multiple selectors firing. There are definite advantages in the TIPS architecture comparing to the pure blackboard approach: it allows leveraging domain control knowledge and it supports vertical integration where one problem solver can directly call another. The main drawback of TIPS is that it does not specify the mechanism on how knowledge is shared between problem solving modules. 39 Ancfher in: am proposed '. mesa bet 'een ash-ave the give". “I“ vh is STTIE CwmnKADS cg PROTEGE- '33 ‘ '6 QEnerafc. Another interesting GT-based integration approach GT-SOAR (Johnson 1991) is based on SOAR’s problem spaces (Laird, Newell et al. 1987). The author proposed to use SOAR mechanism of problem spaces to dynamically choose between available small-grain problem-solving methods in order to achieve the given task described in terms of initial state and goal state. This approach is similar to that proposed in several research directions within CommonKADS community, where researchers report on development of methods for integration of small-grain problem-solvers using blackboard approach (Glaser 1996) and using specialized grammars (Brazier 1997), etc. $2.4. PROTEGE PROTEGE-ll (Tu, Kahn et al. 1989; Tu, Eriksson et al. 1995) is 3 meta- tool that generates task—specific expert—system shells from libraries of reusable problem solving methods, domain-ontology, and knowledge acquisition modules. KBS created in PROTEGE-ll has strong feel of knowledge-level architecture through emphasizing explicit role of each participating module or connected collection of modules inside the expert system. PROTEGE-ll advocates flexible control architecture where the sequence of action could be planned dynamically during the run-time exploiting agenda-based control. Nevertheless, the implementation does not allow explicit stating of the control model inside the shell and requires additional hard-core programming in CLIPS or C. 40 '5 ,‘ ' .Iesgr, model. N f ”In ' ' Setlc coma: A) R . ., J C) as (D‘ K J (‘1 .‘i' a? \1 ) (I) 2‘ I- ——I ..‘T (D (I) -9 W i L ': ['t Uil.‘ Cy!“ yr yQ“ v: 039'; ~ A u 'vfisfi‘zy . v§‘ " \ ‘, ‘ 3 _‘ Vb ‘ In ."‘.A “a: 1‘: 123‘ \- . A our The KADS6 (Knowledge Analysis and Design Support) community takes the view that the development of KBS is a modeling activity during which the developer defines different layers of KBS and specifies connections between them. According to KADS there are several models that need to be specified during the KBS development cycle: Organizational model, Application model, Task Model, Model of Expertise, Model of cooperation, Conceptual model, and Design model. Model of expertise — the core of the KBS - consists of four layers: 1. Static domain knowledge is based on first-order order-sorted predicate calculus. This level contains domain factual knowledge, relations between objects etc. Knowledge sources - canonical inference steps - are the traditional generic methods such as classification, abduction, etc. In addition, the methods for knowledge transformation, selection and computation. The Task level contains knowledge about how elementary inference engines can be combined to achieve a certain goal. . The Strategic knowledge level determines what goals are relevant to solve a particular problem. Numerous KBS development environments that follow this approach were built over years. This section overviews several KBS building environments that were rooted in the KADS methodology. but differ in their approach to task decomposition-integration problem. 6 KADS was an ESPlRlT-l European multinational project that included organizations from France. Germany, Netherlands, and United Kingdom 41 The 00'“ Donates 665‘?” art-313w (Static (X Weston Dame; 73371353190” Ck rerelsre Impleme a“) that the KE grail-gram probe-"I law-3'. having done sear-med sea-tiles VITAL (Mot KIDS. VlTAL tak tie ,rifial problem Gill (genera‘azze' azzlfation of rule recess-m basic i ficrsach 511me new: sentence-re 55.71%? “5 b93989" :§;“.nll waist, - 9d aston :3'm‘l! A j . 6 \ lq‘ Lhé I“! . $771 This f0 nits “Nate y t I O The CommonKADS methodology (Wielinga and Schreiber 1994) promotes design time integration of problem solving methods using domain- ontology (static domain knowledge model) as communication glue. By defining a connection between the layers of the KBS developer states that the explicit communication channels and control strategy during system developing time, therefore implementing RC or SRC global problem-solving strategy. The main difficulty that the KBS developer faces following this approach is how to combine small-grain problem-solving components into a consistent model. On the other hand, having done this the integration of different parts of the system is being performed seamlessly. VITAL (Motta, O’Hara et al. 1994) is another approach originated within KADS. VITAL takes the iterative viewpoint on the K88 building process, where the initial problem statement is formalized using special kind of grammar called GDM (generalized directive model). Then the initial GDM is refined by application of rules of GDM grammar until it reaches terminal symbols that represent basic inference mechanisms. Unlike CommonKADS, the VITAL approach supports combination and integration of generic components by top- down sentence-refinement process. During this process, all the communication channels between the inference components along with their execution order are established automatically. The weakness of this methodology is in the extreme formalism that the KBS developer has to follow in order to describe the problem at hand. This formalism is not always capable of reflecting the given problem adequately. 42 Glasser (6‘ the integration 0 CoMollAS sup; :I instead ol deterr: , ages for the big {if GBSCI‘LDed any Wedge. which l'. The Tabie ‘ select-merit l-KBE ewe-m l-KBS or Glasser (Glaser 1996) proposed an opportunistic blackboard approach to the integration of CommonKADS inference engines. The described system CoMoMAS supports a model-oriented approach to the construction of KBS, but instead of determining the cooperation model during the design stage CoMoMAS argues for the blackboard-like run-time dynamic cooperation model. However, the described approach does not allow explicit representation of existent control knowledge, which is its main drawback. The Table 1 demonstrates comparison between discussed system for development l-KBSs. The bottom row is reserved for the augmented FR framework l-KBS construction that is one of the targets of the reported research. Explicity of Global Local control Ability to Shell KLA (1 - 5) control strategy handle multiple strategy control structures BB1, BBK 1 FC FC No Yes PROTEGE-ll 3 PC All Yes Yes Generic Task 5 RC RC No Yes Toolset (programming is needed) TIPS SRC RC No No GT SOAR RC FC No No CommonKADS SRC RC Some Slever a VITAL 5 RC, RC No Yes Some SRC CoMoMAS 2 PC PC No No Conventional FR 5 SRC RC No Yes Augmented FR ? ? ? ? ? Table 1. Comparison between the discussed approaches 43 13. Ontolo Knowledl Knowledge messed syste sieves liar the le'preblem 5W: 5.? l A ' due-sped speci 3'51"}? '1': 1 S . 3.3. Ontologies and Other approaches to Knowledge Sharing In Knowledge-Based Systems Knowledge sharing is one of the keys to the successful development of a composed system. Use of shared knowledge between cooperating agents ensures that the agents are able to understand common information necessary for problem solving. Moreover, it is likely that domain knowledge representation developed specifically for co-operated problem solving would be reused in later applications. The following sub-sections describe approaches to knowledge shanng. 3.3.1. Syntactic Mapping One of the strategies to achieve the inter-agent understanding is to create translators that will transform knowledge representation of one agent to knowledge representation of another agent when needed. In LOOM, for example (MacGregor 1991), different type of reasoning engines were used for different parts of problem solving: semantic net reasoning engine was responsible for terminological reasoning, another - used logical representation. In this case, information is translated from semantic network representation to Horn's clauses and back. Interfaces between different types of agents translated information from one representation to another (Table 2). FRAME_BASED REPRESENTATION UNARY PREDICATS Frame_name: Car Frame_name(Car) & Maker (Mercury) Maker: Mercury & Model (Mystique) & Year (1995) & Model: Mystique Color (Blue) Year: 1995 Color: Blue Table 2. A possible mapping between frame-based and unary predicates representations 44 Another 6 anizedge Basl FraneBased (F lFCPCl represe its case trans'a Disadvar Sifts-bar e: a]. Another example of syntactic integration is CYC (Lenat and Guha 1990). Knowledge Base in CYC is divided into two levels: convenient for inference Frame-Based (FB) representation is backed by First-Order Predicate Calculus (FOPC) representation in order to “... provide the requisite expressiveness”. In this case translation is be made in both direction FOPC (—) FB. Disadvantages of this type of integration are following (van Heijst, Schreiberetal. 1997): . Fixed syntactical mapping restricts expressiveness of representations. For example, if we are to express some piece of knowledge in some way in one of the representational formalisms, this will put constraints on how this knowledge will be represented in the other KR. This also may limit reasoning ability of a problem-solver as well as expressiveness of knowledge model. 0 Sometimes there is no obvious way to map one syntactical representation to another. . It is not feasible to make such converters for every possible representation in general. Meanwhile, the simplicity of this methodology allows ad hoc mapping procedures that can be written on the fly and do not require lead-time for developing high-level system architecture. This method can also be used for “hooking up” previously developed agents with new software. Such l-KBSs are characterized as follows: 0 small number of cooperating agents; 45 r similarsyrttac i nose—ope'atu KBS) is plan." ‘99?) As a pa lei-eased Kris I’te'ctangmg lr lifi-E'lis USP'S QECSEWanfiC In, " 5593) and Wd- Every I swam is e: l. , ‘1' randflng pr 5 I’ll". ..MU'UQS FITS) A ‘ ; FAN." “u“ fin HUI . (S 'E'Tlisn “firm 8 l U 'r ' " .. “18,:er ‘Uq‘h V -. k I “I’m ’A x ‘ ‘~ ‘Q L ~ ‘ 5 b ‘Ufire a similar syntactic structure of knowledge used by the agents; and . no oo-operation with “foreign” agents (agents, acting outside this particular I- KBS) is planned. MIR Knowledge Interchange Format An approach to standardization of knowledge representation is being developed under DARPA support in the KSE project7 (Genesereth, Fikes et al. 1992). As a part of this project, a group of researchers at Stanford University developed Knowledge Interchange Format (KIF) — a formal language for interchanging information among disparate computer programs. This language inherits LISP’s syntax and is a declarative representation of knowledge. The basic semantics of KIF is a correlation between the terms (constants and variables) and the sentences of the language and a conceptualization of the world. Every term denotes an object in the universe of discourse, and every sentence is either true or false. In order to be true, the sentence should satisfy the preset conditions and axioms. The authors also introduce non-monotonicity for handling non-monotonic knowledge. In other words, KIF is a language that supports First Order Predicate Calculus representation of knowledge with few additions. This research is, in fact, the first attempt to standardize knowledge representation (KR). The authors filed a draft with the American National 7 The DARPA Knowledge Sharing Effort (KSE) is a consortium to develop conventions facilitating sharing and reuse of knowledge bases and knowledge based systems. Its goal is to define, develop, and test infrastructure and supporting technology to enable participants to build much bigger and more broadly functional systems than could be achieved working alone. 46 sgidaid (Gene 52"." 'lel rep“ This met? 3.31510 logic theC' experience with 'ep'eseetatéon l Chandrasekaran a, ”is-Tod: I Dterent interp' satisiiable in one I Neolog‘rcai type ree'eserited usir ' lira-ll KR sche'~ men-sterile reasor andsoiorih. (32o Impassible l0 Cre MR wt thout iim ill Asst; ‘ ”“”9 the hi 5,. L " -' ' “'35? «on Of an a? "x‘ . a 1 _ A .. CI idtle‘“ A Gnu Standard (Genesereth 1998) in which they suggested that KIF should be a standard for representation of shared knowledge. This method has many attractive properties: clarity of representation; sound logic theory, which allows making proofs; with a few hundred years of experience with predicates handling and manipulating. Nevertheless, this representation has some noticeable shortcomings (Ginsberg 1991; Chandrasekaran and Johnson 1993) that can diminish the usefulness of this method: a Different interpretations can treat the same sentence differently, e.g. what is satisfiable in one interpretation may not be in the other. 0 Non-logical types of knowledge (e.g. images, video, and audio) can not be represented using KIF. - Many KR schemes involve different extensions of FOPC, such as non- monotonic reasoning, reasoning with limited data, reasoning with noisy data, and so forth. Given all the differences in modern approaches to KR it seems impossible to create a language that will capture all current and future trends in KR without limiting the latter. 0 Assuming the hypothesis that everything can be expressed in FOPC, the translation of an arbitrary knowledge into this form may be a very difficult task. For example, a translation of a probabilistic database into FOPC must include an axiomatization of the theory of probability itself. 0 Expressing arbitrary knowledge using any fixed and standardized KR method can lead to tailoring knowledge to this representation. 47 3.3.3. K 1. sec meractons 5‘37 eet'I'QTZTl‘leT‘il. momma? betwee" a k" . I I» system. The Lab's ‘ ’ " U eh ai- tie external in The ba 3.3.3. KQML: the pragmatic approach The scope of the External Interfaces Group within KSE is the run-time interactions between knowledge-based systems and other modules in a run-time environment. Special attention has been given to two important cases - communication between two knowledge-based systems and communication between a knowledge-based system and a conventional database management system. The Knowledge Query and Manipulation Language (KQML) (Finn, Labrou et al. 1997) language is one of the main results, which has come out of the external interfaces group of the KSE. The basis for the KQML approach is the understanding of the fact that common knowledge representation is not enough (or may not even be necessary) to make the communication between agents work. Some important pragmatic issues should be addressed first: . Which agent to communicate with and how to find them. . How to initiate and maintain exchange. 0 What domain ontology to use. KQML is concerned primarily with such pragmatic issues. KQML introduces a new class of agents - communication facilitators - capable of performing tasks for communication purposes, such as maintaining registry of service names, forwarding messages, routing messages, etc. Agents use these facilitators when they need to send a message to another agent. Facilitators may access other agents using with use of Domain Naming Service across the Internet. 48 KQML is is? is periormat. 1‘F_ A . “ha, _ a Cucge “ff”. ~ - V KQML is based on the balanced parenthesis list. The first element of the list is performative and the remaining are parameters. In the message in Figure 3 the agent stock-server asks for one reply about PRICE IBM, and wishes the value to be returned in variable ?price using language LPROLOG and ontology NYSE-TIKS. (ask-one :content (PRICE IBM ?price) :receiver stock-server :Ianguage LPROLOG :ontology NYSE-TICKS) Figure 3. Example of KQML query. Much experience has been gathered from the variety of projects which used KQML for inter-agent communication: Microsoft OLE2, experiment with distributed CYC based agents over local network at the University of Maryland, Object Management Group’s Common Object Request Broker Architecture (CORBA) (Ben-Natan 1995), Xerox’s ILU etc. 3.3.4. Ontologies and Ontolingua In order for an agent to reason and exchange information about a domain of discourse, it must use a conceptualization of that domain. This conceptualization should provide a vocabulary for representing knowledge about 49 tnedenain. . a. s E stooges (l Oriel: Once create: 3135M the domain. These conceptualizations are usually called domain ontologies or ontologies8 (Gruber 1992) Ontologies play different roles in knowledge-base development cycle. Once created for a particular domain the ontology: 0 provides the developer with a domain dictionary for representing domain knowledge; 0 provides with the glossary that is available for interacting between the user and the KBS - serves as an interoperation dictionary for agents that comprise KBS. Research of Knowledge System Laboratory at Stanford University led to the development of Ontolingua (Gruber 1992; Gruber 1993) - the tool (Ontolingua Server (Fikes 1997)) and a methodology that helps in the development, maintenance, and use of the domain ontologies. The backbone of Ontolingua is KIF (which is augmented with the frame-base representation). This representation allows expressing class - subclass hierarchies, relationships between classes, functions on relations, and instances of classes that describe domain knowledge. The Ontolingua Server enables collaborative development of ontologies over the Internet. Once logged into the server the user has the ability to create, load, edit, and save ontologies. The tool also gives possibilities to maintain the ‘g . 8 This definition is different from the definition of Ontology in philosophy where It is understood as a theory about that what can exist. Throughout this proposal, lwill use term ontology in the KBS sense. 50 ciiosegy, Che lDL.etc. Three ’rilea ol litter cci‘asc'ailve Grislsges 0‘. bf‘if‘rn‘ 'Aek‘ VU ll e l" ‘ scecifgcatnq 3f1"‘5‘l'3r3'7‘en “Gertrian ‘ E ivfllnah‘ l VAUU'ary- '1 3‘ b {Mi-‘7‘” ‘0 .ul’ !E a“. inl- timjzre "I“: A. :- ontology, check inconsistencies, translate to and from KIF, LOOM, CORBA’s IDL, etc. Three main impacts of the Ontolingua research are (i) crystallizing the idea of inter-agent communication through use of ontology, (ii) enabling the collaborative development of the domain ontologies, and (iii) sharing the domain ontologies over the Internet. Different research groups for the development of vocabularies are using the Ontolingua Server. Examples of such projects are CommerceNet - providing Internet accessibility to products’ descriptions and specifications, support of Enterprise project (Uschold and King 1995) in development ontologies description of business process, and lnterMed project (Gennari, D. E. Oliver et al. 1995) - providing Internet-based medical vocabulary. Similar approach to knowledge sharing was suggested in CommonKADS project. Detailed examples of this approach can be found in (Wielinga and Schreiber 1994). 3.3.5. Tools for Developing Domain Ontologies The development of domain ontology often precedes the development of the software systems that uses it. However, it is often the case that the process of building domain ontology stretches for the duration of the software development cycle. An example of such development is the Socharis project, during which the ontology of manufacturing with composite material was built first and then was augmented many times during the development of the Socharis system. 51 *7/3— . VT / 77 J The authors of Socharis developed Ontology Editor that was specifically tuned to represent composite manufacturing ontology. As a part of the dissertation research, this ontology was duplicated using Protégé (Figure 4, Appendix C) and XML (Figure 5, Appendix D) to demonstrate interchangeability of tools and methods. (5,; Protege/Win Ontoloquditor - [manuTechpont] .EIeQaczfilot Vewwndowuelp £12151 EELEJ .IIJEL'EI __l Slot 5 Detail 1 AlowedCIaaseslSmbolsNab —l_Zx.’_' name [:riiooicompleray rooICompiexiry .Iabor Labor " PressureKSl Temperature : $90 Res'nTransferMoId ‘ 0 Sum E {8 Tecl'inobgiMisc _ 5:0 CureType C) DeiverySystem _ O FberForm'ngMetho . C) HeatedTool 0 Heatndrlethod O Laba :0 P touring «1 °‘ » «l l _>l ForvI'IeEmfevtsF‘I l i i fl Figure 4. Screenshot of the Manufacturing Ontology in Protégé shell 52 it \l)rsserldlr0n\manlInloloqy xml » Microsoft Internet Explorer l Eie we». rm ‘ loos use“ ' ” " - l“.*.‘9@fl§ifi33l§}5§l”l 8325... Forms": Sfcp Rdresh Home ‘ Search Favories History I Md PM Eli j jmlglfizwlssaraoonwmmoloqym .1] (950 “we; ”i — (header id='Manufacturing Ontology“) - (class id='Tooling with Parameters"> _ (category id='AlumInium' /> (category idz'NickeI Electroforms' /> (category id='CRP" /> (category id='CeramIcs' /> (category id='Polymers' /> (category id='GRP" /> + (parameter type='oneOfVar' id="cure type") (parameter type='oneOfVar' id=“pressure-psi" /> + (parameter type='oneOfVar' id="time' /> + (category id='ExtrusIon"> 4» — - of device Precondition Postcondition By Traditionally, the device’s functionality is represented through the name of the function it performs, preconditions that should be satisfied before the device starts, postcondition expression which becomes TRUE after the device finished 64 its operation. hence. wilIC subordinate C. The no reasoning pa' hang carried 1 hence. The L changed, moot perform these . oath of the slug Function Cae'sal story of FR that has b81 ' FR methoc CGVice in Of‘ Functional question, 37 its operation, and By clause. By clause is the pointer to the behavior of the device, which achieves the device function through the functions of the subordinate devices or by means of world10 knowledge and definitions. The notion of slug of matter is in many ways central for the functional- reasoning paradigm. The slug is an indivisible fragment of a substance that is being carried through the causal network that explains the functionality of the device. The Laws of Conservation dictate that the slug of matter cannot be changed, modified. or destroyed without applying specific operators that explicitly perform these operations on it. One “reads” the causal network by tracing the path of the slug of substance through the functional representation of a device. Functional representation of a device along with the ability to understand causal story of the device’s function brings to light several important qualities of FR that has been leveraged in numerous FR applications: 0 FR methodology supports functional and structural representation of the device in one model, where one is naturally related to another. a Functional representation supports reasoning which answers a ‘What if?’ question, and allows tracing consequences of an arbitrary action, manifested through the changes in state variables. - FR supports variable granularities of knowledge in the same model. That is, there is no bottom level granule for device decomposition. The decomposition can go on until infinity or until the developer decides that a ‘0 The "world knowledge" term here refers to the knowledge about the universe of discourse 65 pa articular can be let . The ab II Chair) from required by FR metl' 653'- be exam: 3.5.2 F: \ Pegah's Bond and Pega an example cf senses for slrn found in (Kamel is an automatic particular level is sufficient for the description of the device’s behavior. This can be leveraged in another attractive quality of the FR approach: . The ability to explain achieved results by backtracking through the causal chain from the state that is needed to be explained at the level of explanation required by the user or a level maximally achievable by a system. FR methodology is flexible enough to be adapted to various areas. Next, describe examples of application of FR techniques in different domains are:. 3.5_.2. FR for Devices Pegah’s and Bond’s (Pegah, Bond et al. 1992; Bond and Pegah 1993; Bond and Pegan 1993) FR model for jet fighter FA-18 fuel system can serve as an example of the application of the FR methodology to modeling physical devices for simulation purposes. Another example of such modeling can be found in (Kamel, Sticklen et al. 1989; Sticklen, Kameletal. 1991). The test bed is an automatic cruise control system, which is schematically represented in Figure 7. In order to model the device for numerical and qualitative simulation authors extended FR approach with the addition of a new type of function to calculate and integrate qualitative and quantitative reasoning in a functional model. Hawkins (Hawkins, McDowell et al. 1993) has shown that FR can be used as a tool for the troubleshooting devices. The authors used an augmented FR approach for diagnosis in the External Active Thermal Control System for space station Freedom which transfers accumulated heat from inside the station to the outer space and maintains climate inside the station. The core idea of the 66 approach ist dense and, necessary die example of us ance1996), v. acar is used tc approach is that the inherent properties of FR enable causal reasoning about the device and, therefore, once the FR model of the device is complete, the necessary diagnostic information could be automatically generated. Another example of using the FR approach to troubleshooting devices was described in (Price 1996), where the author showed how FR model of the electrical system of a car is used to identify sneak electric paths. Command Speed Control Electronics Throttle Actuator Proportional Summing fl!” \ Amplifier Amplifier Cm‘ f VIM 3". Voltage To .. .. ..., Am 'l'fi" Converter J Maseru r Figure 7. Schematics of automatic cruise control (Modarres 1998) approached the problem of modeling nuclear plants from the functional viewpoint. The model of a plant consists of several hundred thousand functional units, which perform main and support functions that are combined in a functional model. While his approach is somewhat different from that of the mainstream FR community, it demonstrates important pragmatic issues: the scalability of functional approach, use of libraries of devices, and 67 AF 0-!- FF“ U» V' __; ((3 (C) Ir.1 - ..- functional decomposition of a device through the ‘goal-tree success-tree approach’. The FR approach was traditionally focused on modeling dynamic behaviors of devices. A theoretical augmentation allowing FR methodology to cover the modeling of static devices was proposed in (Lukibanov, Martinez et al. 1998). The authors demonstrated how knowledge of the mechanical structure of a device coupled with the available functional information could not only capture the design intent, but also aid in the re—design and in the reverse engineering of the device. Another attempt to use FR techniques for design purposes was presented in (Lossak, Yoshioka et al. 1998). The paper reported joint efforts of Japanese and German researchers, which resulted in a framework that allowed the use of libraries of devices for design. Devices are represented functionally with rudimentary geometrical data that allowed further manual detailing when design commitments are made. All previous examples dealt with the engineered entities. However, the FR approach was successfully applied to modeling biological systems (Sticklen 1987; Sticklen and Tufankji 1992) and medical diagnosis (I'sumoto and Tanake 1995). 3%. FR for Processes It was noted (Chandrasekaran 1993; Chandrasekaran and Kaindl 1996) that process modeling is an open problem for the FR approach. However, processes (engineered or biological) that deal with the transformation and/or 68 iarspoll 0’ 3 examplei L3 applOaCh at: extension ol 1 al. l998l. T parameters of describe how 8 not only deterrr hemanulactura The mair al.. models the Oi the other he hell is the subje 3.5.4. FR. A ompu lnctonality and tat could be UllC Computer progr mi3"0l.i'€i.llls (for Die-rt 'ied program tern we from the Il‘art . man and l fl... 63’” 't' J IDOS:.ion iOt transport of some kind of substance could benefit from the FR approach. For example, Lambert in (Lambert, Riera et al. 1997) presented a functional approach applied to modeling nuclear reprocessing. Another application and extension of the FR methodology was demonstrated in (Martinez, Lukibanov et al. 1998). The center of the authors’ attention is the dependencies between parameters of a manufacturing process and manufactured artifact. The authors describe how a functional model of a manufacturing process can be leveraged to not only determine the parameters of a manufactured artifact, but also estimate the manufacturability of the design. The main difference between these two approaches is that Lambert .et. al.. models the process through modeling the objects that perform this process. On the other hand, in the approach proposed by Martinez et. al.. the process itself is the subject of modeling through FR techniques. 3.5.4. FR for Software Design and Understandino A computer program is a special kind of device with well-established functionality and interfaces. Software systems have strong flavor of causality that could be understood by following the input data through the software system. Computer programs in general have well-established decomposition into subprograms (for procedural or functional programming) or objects (for object- oriented programming). These properties allow treating a software product as a device from the FR point of view. (Allemang and Chandrasekaran 1991) (Hartman and Chandrasekaran 1995) applied the ideas of functional decomposition to computer programs. The goal of the above research is to aid In 69 automatic p." «plied the r: lonetiohal arc aware ol its re to agents car agents operate EDDVOach using Sorenson 1995 designing and D’Gperties of Fl Iiclemeniairon aspFling the F R of 20 system (l 5551.: “d SOi’Mare automatic program understanding and debugging. (Murdoc and Goel 1998) applied the results of these studies and augmented them in research towards a functional architecture of reflective agents. A reflective agent is an agent that is aware of its reasoning. The authors claim that leveraging the FR representation for agents can greatly improve performance of the system within which these agents operate. The authors also demonstrate the performance of the proposed approach using meeting scheduling software as a test bed. Stroulia (Stroulia and Sorenson 1998) demonstrated the applicability of the FR methodology to designing and re—designing software. The authors leverage the diagnostic properties of FR models to find “bottlenecks” in software systems, where the implementation does not meet the design specifications. Another example of applying the FR methodology to software design can be found in the description of ZD system (Liver and Allemang 1995). The authors advocate component- based software engineering. They show how the FR approach is used to describe the functionality of software components and make binding decisions during system integration. The FR approach also gives the possibility to describe the software architecture, automatically generate a Data Flow Diagram, and ultimately, capture the design rationale. 3.5.5. State of the Art The current state of the art research on functional reasoning is focused on two major points — automatic generation of functional models and incorporating time into functional models. The first point is directly associated with following issues: 70 Model completeness, which is a twofold problem itself: — The causal model must be “true”, that is every “rule” in the model must be correct with respect to the variables of the model. - At every possible state, the model has to have enough information to generate the next set of possible states, i.e. the model should be self- sufficient. Libraries of devices. This issue has been addressed from both theoretical and practical points of view in many researches and applications. However, there are still problems remaining. These problems are concerned with library organization, device instantiation, property inheritance in the hierarchical libraries, etc. Model description. This is the problem of ‘faceplates’, i.e. how to describe the device with the “right” amount of information for the model assembler to make an educated decision on using a particular device from the library in the assembled model. Incorporating explicit time into the functional representation is an open problem. Yet, resolving this problem is very important for many different theoretical and practical purposes, and is essential for the practical applicability of FR methodology for great many different real life problems. Such as combining different time sensitive devices (e.g. a model of the cruise control and a model of climate control) with different time scales into a bigger model (e.g. a model of a car). 71 T) A.) (”an Problems of designing libraries of device were addressed in (Pegah, Hawkins et al. 1994) and now are being revisited and extended in ongoing research at Intelligent Systems Laboratory at Michigan State University. In the same research, Hawkins addresses the problem of incorporating time into the functional models and associated sub-problems. There are a number of problems directly or indirectly associated with the described venues of the research. Some of them will be addressed in the proposed research. 3. 6. Conclusion I would like to re-iterate the important theoretical and practical sources that prompted and contributed to this dissertation research. 1 Introduction of reusable problem-solving methods and task-specific architectures in the KBS research allows concentrating on the decomposition of a problem into the set of manageable units, where each unit has predefined functionality and inference strategy. 2 The Generic Task branch of TSA and the legacy software package (GT ITS) proved to be an effective tool for building practical small-scale KBSs. 3 Advances in integration methodologies and inter-object communication techniques allowed identification of generic control architectures and methods that allow integration of distributed units into a functional system. 4 Ontological research enabled the development of domain ontologies that are used to share knowledge between separate parties. 72 Tl mEii‘QdQ: Sitiens. 5 Universal Modeling Language and component-based software engineering take a black box point of view at the software modules, which allows concentrating on the modules’ functionality and treating the problem of integration of this modules separately. 6 The Function-Based Reasoning paradigm provided a functional perspective on any engineered or biological device. The extension of the FR paradigm on software systems enables their functional decomposition thus allowing concentrating on the function of every participating module, gradual problem decomposition, and progressive knowledge acquisition. The next section will show how the listed above theories are used to build methodology that supports the development of integrated knowledge-based systems. 73 4. ANALYSIS AND A THEORY BEHIND APPROACH 4. 1. Introduction To build a knowledge-based system that solves a domain problem is to create a software system that will model the functionality of the domain expert, i.e. solves the tasks usually performed by domain expert. More often than not this means that an internal l-KBS architecture should copy (at least partially) experts’ thought structure. The process of eliciting this structure and underlying domain knowledge - knowledge acquisition — is the core problem that has to be solved during the construction of a knowledge-based system. In the case when building a knowledge system involves reuse of existing problem-solving modules, the task of system building expands to include issues of integrating disparate problem-solving modules. Generally, the whole system building process could be divided into five major stages: 1. Assess the problem at hand and decompose it into manageable sub- problems. 2. Organize them in problem - sub-problem structure (so the solution of sub- problems leads to the solution of a larger problem) 3. Acquire problem-solving units responsible for solution of sub-problems 4. Determine information flow between problem-solving units by explicitly or implicitly connecting problem-solvers’ inputs and outputs as well as designating a working vocabulary and structure of messages that are being passed between units 74 5. Define necessary control that would manage activation of each participating problem-solving unit. The next Section lists issues that are not covered in this research and its reasons. The rest of this Chapter describes how the approach developed as a part of the research effort and covers the described above stages. 4.2. What is Not Covered by the Approach ? This dissertation intentionally omits problems of developing domain ontology. A domain ontology serves, as a backbone for building Integrated Knowledge Based Systems by providing working vocabulary that is syntactically and semantically understood by all participating units. The reason for leaving out such an important issue is that recent progress in ontological research resulted in the number of methods and tools for generating robust domain ontologies (Section 3.3). In addition, eXtensible Markup Language (XML) became de facto industry standard for developing domain vocabularies that in many cases play a role of ontologies by allowing store and reuse domain factual knowledge in flexible pre-defined structures. The application side of the dissertation (redesign of Socharis) is based in part on the ontology of manufacturing with composite materials that was developed as a part of the Socharis project. Another major KBS problem that is excluded from the scope of the research: is the problem of building individual problem-solvers (a substantial part of I-KBS building process). The reason for this is that research in Task-Specific Architectures (T SA) already produced a well-populated group of problem-solving methods that could be successfully applied to solve isolated problems of ordinary 75 complexity. However, the practical issues of integration of multiple problem solvers in to a working system were not in the focus of the research community. This research instead, centers on methodology that uses these problem-solving methods to develop large integrated KBSs. In fact, this dissertation is built on the foundation of one of schools of TSA - Generic Task approach - which supplies the unitary problem-solvers for building I-KBS in the described framework. 4.3. Theoretical Premise Sticklen’s Knowledge-Level Architecture Hypothesis, Steels’s Knowledge Use Level, and Van de Welde’s Modeling Libraries have one thing in common: all three of them consider the structural organization of problem-solving units (methods) as a crucial step in designing, describing, or modeling an intelligent system. The main thought behind these theories is that given the functionality of each agent and all the connections among the agents in the system it will be possible to understand the behavior of the system. and its sub-parts. While intuitively accurate, neither of these theories suggests how to organize agents, how to provide communication channels, and how to control execution order. , except for Van de Velde in (Velde 1994) where he suggested using any of the available methodologies (CommonKADS, Vital, etc. ) to do so. However, he stopped short of describing a mechanism that could lead to the realization of the Modeling Libraries. This dissertation is based on the premise that Function- Based Reasoning/Function-Based Modeling is able to model such structures in all their richness. 76 The Generic Task methodology serves as another important theoretical cornerstone of the described approach. Generic tasks proved to be a convenient instrument in knowledge acquisition along with development and deployment of knowledge-based systems. However the brittleness of GT templates caused the developers of KBSs programmatically alter the pre—defined inference engine and/or knowledge representation to adapt them to the problem at hand. Extending generic tasks, this dissertation capitalizes on the large-grain view of the problem-solving process at the same time allowing modifying control among the cooperating entities without re-programming problem-solving templates. In a sense, this approach enforces guidelines for designing an I-KBS using the set of pre—defined templates. The basic principle is to divide the problem into a number of smaller more manageable parts that could be solved by an application of a single template without altering it. Then integrate the resulting knowledge-based systems into a functioning I-KBS by defining control and information flow between them. However, it is important to understand that the only quality of Generic Tasks that has been heavily leveraged here is the possibility to apply the black- box point of view on any GT-based problem-solvers. This is because of the fact that each GT-based unitary KBS is self-sufficient in the sense that it contains all knowledge necessary for problem-solving as well an inference module. The significant conclusion is that any self-contained problem-solver could be used in the extension of the described methodology as long as its functionality could be "black boxed”. 77 I“. ’ V in: III A“ does FINE 9" vol Q" r "9 ‘yuv 4.4. FR as a Structure Modeling Methodology Inherent properties of the FR methodology - that sees a device as a recursive hierarchy of sub-devices — allow considering a software system (such as an integrated knowledge-based system) as a hierarchy of sub—systems. Along this line, the FR modeling mirrors the Rational Unified Process (RUP) (Fowler and Scott 2000) that considers structural decomposition of the software system as one of the stages of software development. RUP recently has become an industry standard for development of large, well documented software systems. Having its roots in Capability Maturity Model (Section 3.4.3) and Object Modeling Technique (Section 3.4.1), RUP goes beyond structural modeling and defines documenting policy, use-case models, block diagrams, etc. By following the Rational Unified Process the designer ideally finishes by generating skeletal code for the software system being designed. One of the RUP’s shortcomings in modeling knowledge-based systems comes from its ability of transforming the design intent into the code. Often, when dealing with knowledge-based systems the code is not important (inference engine is already written and being reused), but knowledge representation is not. However, RUP does not have facilities to operate with complex knowledge models often intrinsic for knowledge-based systems. Meanwhile, the use of the Function-Based Modeling techniques for problem decomposition allows the l-KBS designer concentrating on knowledge structure and representation, rather than on low-level methods for data handling. In addition, the natural for FR ability to arbitrarily choose the level of decomposition and explicitly define functionality of every participating subsystem 78 or“ > 3 ‘54 comes particularly handy when modeling the system out of the readily available components. 4.5. Limitations of the Traditional FR Approach In spite of the adequacy of the traditional FR methodology in modeling 1- KBS’ structure this theory suffers from several limitations: . The lack of an adequate ontology capable of describing the functionality of problem-solving units. a Inability to distinguish between different parts of the substance that is being passed through the functional model, i.e. treating it as an inseparable slug of matter. . Weakness of the pre-condition clause that made it very difficult to state complex conditions on the activation of parts of the functional model, which adds to the absence of complex control structures within the functional model. These drawbacks limit application of the FR techniques to modeling software systems to primitive ones. Systems with a simple information flow and straightforward functionality. 4. 6. Extension of Function-Based Reasoning Methodology: Functional Ontology The implemented in this dissertation extension to the function-based reasoning methodology deals with the issues outlined in previous section. The problem of insufficient ontology is managed thorough augmentation of functional ontology with new types of functionality and behavior (Section 5.2.1). The addition to the functional ontology in the presented research agrees with the use Of GT-based problem-solvers as bottom-level modules. That is, the functional 79 ontology is extended to describe functionality and behavior of specific types of problem—solving methods: hierarchical classifier and multiple routine designers. It is possible to carry on this extension further to include any other types of problem-solvers should they be chosen as a building block, therefore extending the usefulness of the methodology beyond the Generic Task framework. The use of augmented functional ontology not only helps to accurately describe the functionality of every component of modeled I-KBS, but also directs the problem decomposition process by suggesting available problem-solving methods and, by doing that, implicitly guiding the l-KBS designer to dissect the problem into the chunks manageable by available problem-solving methods. Another advantage of using such augmented functional ontology is as follows. According to the theory of task-specific architectures, every problem- solving method has a specific knowledge structure associated with it. Therefore, definition of a method automatically specifies an associate with this method knowledge representation. If we turn this argument around, than it could be said that one could identify an applicable problem-solving method by analyzing available knowledge and its representation. Consequently, a fixed set of problem-solving methods (an explicit enumeration in the functional ontoldgy) enables matching of knowledge structures in domain of interest to available knowledge representation. This also could be used as an instrument in problem decomposition process. The implementation of this extension to the FR methodology is described in detail in Section 5.2.1 of this dissertation. 80 4. 7. Extension of Function-Based Reasoning Methodology: Information Processing Conventionally, 3 FR model deals with a slug of substance (Section 3.5) that travels through a causal model. This slug of matter cannot appear, disappear, or transform (by changing in nature and magnitude) without application of specifically stated operations. While this is sufficient for the majority of engineered devices, a software system requires different approach. Information, that travels through the software system is not a monolithic slug but rather a collection of information streams each of which travels by a different (possibly independent) trajectory and could be created or destroyed without contradicting to any of conservation laws (which are of concern when dealing with physical devices). This dissertation introduces Port Managers that address both of the listed above concerns. Port Manager is an auxiliary device associated with every component of functional decomposition. Its main role is to supervise input and output variables of the device, translate them into internal representation if needed, connect with other port managers, and control activation of the corresponding device depending on the current problem-solving context. Port managers envelop their respective devices, therefore enforcing the black box point of view. The only way to access a device is through the input and output variables that are published in the device’s port manager. Any part of the I-KBS could be connected (dynamically or statically) to any number of co-operating modules. Any sub-set of input or output variables can participate in such connections. To support this quality of software systems port 81 (T, managers should be capable of performing multiple variable mappings, linking output variables of one device/problem-solver to input variables of another. Exercising multiple mapping mechanisms, the l-KBS developer can effectively model arbitrary information flow among the participating problem-solving modules. This feature could be related to the objectcriented programming techniques where the designer encapsulates data and methods and provides interfaces to access them from outside. Another problem that was listed as a shortcoming of the traditional FR, is the weakness of the control structures - preconditions - a Boolean expression on model’s state variables. Precondition is the only way to gain dynamic control over the execution: when precondition is satisfied the sub—device activates. While satisfactory for modeling engineered devices where the amount of modeled through variable substances small enough, this form of control seriously hinders adequate modeling of software systems. Port managers can considerably strengthen FR techniques in this respect. Port managers could not only perform all types of precondition checking, but also add controls, specific for problem-solving types participating in an l-KBS construction. This could be justified by the fact that different problem-solvers produce results of different structure that may require specific attention (e.g. enumerating and filtering). These different kinds of results might in turn be used by other problem-solvers. It is the task of port managers to recognize these structures and act correspondingly so that the problem-solver would receive input parameters of structure that agrees with it interface specification. 82 Idea to achieve taster f IIlle'erit SO ‘ l his or differ IETTI Ideally, a well-planned l-KBS should conform to a single domain ontology to achieve uniform understanding among participating entities. In case this rule is compromised, port managers should provide translating capability that would transform the outputs of one module to the input of another. In short, a port manager could be compared with a plug adapter/transformer kit that a sawy traveler caries around the world to plug to different electrical and telephone outlets with different voltages and configuration, so his or her device keeps receiving energy and data in different locations from different sources without being concerned of device’s malfunction. 4. 8. Conclusion The combination of the described in previous sections augmentations to the traditional Function-Based reasoning paradigm allows adequate description of the architecture of an Integrated Knowledge-Based System capitalizing on the functionality of the participating units, functional task-subtask decomposition, and explicit direction of the information flow. The major change that allows description of the l-KBS is the addition of the facility of port managers that handle the information and control flow. Without this change the application of the FR methodology falls short in competent modeling of l-KBSs because of its inability to express multiple flows of the substance through the functional model as well as deficiency of the control mechanism. Augmentation of the functional ontology, on the other side, lets the I-KBS designer concentrate on the directed decomposition of the problem at hand into chunks that could be handled by the units whose functionality is expressed in the 83 aroma permit: therel: rESoll hood; alnm U3 Ire augmented functional ontology. A flexible nature of this functional ontology permits its extension to include description of different problem-solving modules therefore adapting to new problems. The next step is to present a consistent methodology that if followed, will result in the l-KBS that solves the problem of interest. The next chapter introduces such a methodology and describes each proposed theoretical augmentation from the practical, implementational standpoint. 84 5.1 n 4. FUllo‘r "'Il\ prObiEp 5. PROBLEM STATEMENT AND APPROACH 5. 1. Problem Statement The goal of this research is to develop a framework for design and deployment of integrated knowledge-based systems. This research addresses the following problems: 1. Rapid modeling of system architecture for development of problem-solving architectures and on-the-fly modifications of existing systems. 2. Guiding the task decomposition process by assisting in the identification of the constituent sub-parts of the system, mapping the identified sub-tasks to the existing problem-solving methods, and re-using of existing problem- solvers. 3. lntegrating pre-built problem-solvers into the target system, leveraging control knowledge and using the domain ontology for the inter-agent communication. 5.2. Approach Following the proposed approach, building of an l—KBS is divided into three stages. Each stage corresponds to the construction of one of three l-KBS’ models: 1. Task-subtask decomposition model or Problem-Solving Hierarchy (PSH): a recursive division of the problem into smaller problems that could be tackled by unitary problem solvers. 2. Functional Model: shows a function (or a role) of each part of the l-KBS in the problem-solving process. 85 3. lnl. isr overal? Silt-pr: 805.;ng decom; CC .‘r’en al' prob 3f the fa “Ode of Sammie iiermec me , 4...: y . ‘el IS H M W anAI‘H “U, y 3. Information—Processing Model: shows how information (variables and control) is used and is passed between the different parts of the l-KBS. PSH can be understood as a recursive, domain dependent division of an overall problem into sub-problems that bottoms at the level where every identified sub-problem can be solved by some a priori identified method. This Problem Solving Hierarchy does not reflect a problem-solving flow but rather is a static decomposition, similar to the device-sub-device decomposition of the conventional FR. PSH allows the user and the designer to immediately assess all problem-solving units of an l-KBS, to see problem-sub-problem decomposition of the task at hand, and to access other models of the l-KBS. The Functional Model enables the designer to look at the function of each node of the PSH, where the function/role of every leaf of PSH is tied to a particular unitary problem solver or a formula. The function(s) of every intermediate node and the function(s) of the root of the PSH are composed of the functions of the other nodes of PSH. The Functional Model is used to generate a macroexpansion of the l-KBS: a network that shows a causal chain of firing different parts of PSH. This macroexpansion gives a high-level picture of the functionality of an l-KBS by imposing partial temporal order on the execution of the components of PSH. The traditional FR is usually concentrated on a particular slug of matter that passes through the functional model. In the case of l-KBS, this slug of matter is information that is being passed from one node of the Functional Model to another. The Information-Processing Model is used to unambiguously 86 deter 53% the a; of.“ H A w): “*‘afa: VI: A hetegsdry sit; “A“! hi villi to 3€<~. ., VV-JC.‘A l ‘Un determine the direction of each stream of the information flow as well as to define some control data used to manage the nodes of the Functional Model. 5.2.1. Integrated Knowledge-Based System as a Qevice: Functional _ Ontology I use a metaphor of a device to describe a problem-solver. According to the approaches described in previous section, its input data, output data, and a problem-solving behavior (which achieves a function of a problem-solver) can characterize any problem—solver. This characterization mirrors the functional characterization of a device, thus enabling use of the FR methodology on software systems including problem solvers. Following FR methodology an integrated KBS can be decomposed as follows: Problem-solver -) function 9 behavior-) Sub-problem solver 9 function -) behavior. . The decomposition goes further on until the developer reaches the level of granularity, where a type of each leaf-level sub-problem solver is matched to the one from the pre-defined set. One of the advantages of the FR approach is the possibility of estimating the overall behavior of the device, based on the behaviors of the sub-devices, and knowledge of connectivity of devices. To leverage this property of FR it is necessary to define bottom level behavior of every problem solver. However, it is difficult to describe precise behavior of an arbitrary problem—solver. Such description is bound to be very general and therefore, will not give good leverage 87 durint piecis delta? M“, in Vail "v‘ places i. 3:; sin 2. by during task decomposition. Focusing on specific types of problem-solvers allows precise defining of function and behavior for each of selected PS. These definitions are reflected in the proposed augmentation to the current functional ontology. The changed functional ontology will aid in the task decomposition process by: 1. supplying the guidelines for choosing a particular PS method for a given situation and, 2. by directing decomposition of a task into sub-tasks whose PS architecture matches to that of predefined problem-solving methods. In the research, I focus on classes of problem-solvers that are covered by a sub-set of GT problem-solvers: Hierarchical Classifier, Multiple Routine Designer, and Structured Matcher. However, there are no theoretical limitations on the type, size, etc. of bottom level problem-solver. The proposed functional ontology for the set of GT problem-solvers is shown on Table 4. 88 Will Solvel 1m. Hierar I Clea W Design Wu Matchel \ “gorilh CPS \ Aprobk SOlller Problem Function State Pre—condltion Post- Solver Variables condition Type Hierarchica To A set of All symptom Class I Classifier Classify Symptom variables are set Variable is To Select variables; Or specific set of set Class symptom variables is Or Variable set classification failed Routine To Design A set of Design requirements All Design Designer To Set design variables are set parameters Parameter requirements are set 3 variables; Or A set of Design design Failed parameters Structured To A set of All characteristic Matched Matcher Establish characteristic variables are set Or hypothesis variables; Specific set of found Set of characteristic Or hypothesis variables is set Matching failed Algorithmi To A set of input All input variables Output c PS Calculate variables; are set Or variables are A set of Specific set of input set output variables is set variables A Problem To Solve A set of input All input variables Output Solver variables; are set variables are A set of Or Specific set of set output input variables is set variables Table 4. Function ontology for GT based problem solvers 89 l0 00.7: is desc: 1'. Fun. 5.2.2. Augmenting Precondition Clause In order to seamlessly apply the FR methodology to designing and modeling l-KBSs it is necessary to overcome several theoretical and implementational shortcomings. In the traditional FR approach, the set of preconditions is the only method to control a device. According to this methodology, every function of the device is described as follows: 1. Function: of device 2. Precondition: 3. Postcondition: 4. By: The precondition generally takes the form of logical propositions on state variables. If the precondition is satisfied then the function is performed and the postcondition is set. In many cases, when FR is used to model a simple engineered device this control method is adequate and sufficient. However, for more complex devices with elaborate behavior(s) it is not enough to state simple Boolean preconditions. If we are to model moderate complexity KBS using FR methodology, we need to be able to express complex conditional and causal relationships between different parts of the system, conditional activation of problem-solvers, translating outputs of one module to another, etc. To tackle these issues I introduce the notion of port managers, an auxiliary mechanism associated with every device in the FR model, that would control its. Control functions of a port manager include, but not limited to: converting input to a 90 salirir VELl 9?: (r) C“) :‘ ‘_) liexibi l’ , . fir 0'. W8» lb: ”Etag EXECulg 019 mil ah; Sundial: device from one ontology to another, performing elaborate problem-solving procedures on inputs (e.g. deciding on defaults according to a specific problem solving context), conditional transferring of control to parent or children devices, etc. Where each module performs self-activation based on the current problem solving-context, the use of port managers will enable an adequate modeling of flexible and semi-restricted control. In fact, port managers will play the role of distributed control units associated with each device. In the cases, where the developer chooses to use a centralized control scheme, the function of port managers will be reduced to the traditional checking of Boolean preconditions. In addition to performing operations on inputs, the port manager might execute some actions on the output of the device. An example situation where one might use the output port manager is when the result of the device is not satisfactory and it would be preferable to run the device again. In this case, the port manager would modify the input data for the device and run the device again. Another use of a port manager for output may be the conditional activation of subordinate devices, when the developer elects to center the control at the parent device instead of transferring it to the sub~devices. The introduction of port managers will enable the modeling and designing integrated KBS with arbitrary architectures. Nevertheless, in order to provide advanced design and modeling capability it is necessary to overcome another shortcoming of the current FR implementation: its inability to perform internal cycles. 91 I!“ wax L1 Gucwni is Split 1 This era a mail behavio,’ at... mws ti la‘. 1 MHEdC w 5_.2.3. Tvinq it All Together In the proposed framework, the construction of an l-KBS starts with developing a problem-solving hierarchy, which is a direct application of a traditional FR methodology augmented as described in Section 5.2.1. The PSH is built top-down by specifying a root of hierarchy first and then working down. This creates branches and sub-devices where the leaf nodes are associated with a unitary problem-solver, executed through “by knowledge” or “by definition” behavior, or simple formula. The result of this process is the hierarchy that shows the decomposition of the problem into subproblems as perceived by a knowledge engineer. The next step is the development of a Functional Model of an l-KBS. This is usually done bottom-up by assigning the functionality to the leaf nodes and then composing the functionality of the intermediate nodes from already defined functional chunks. A macroexpansion of a Functional Model gives a view on the causal network of the interoperation of the parts of the l-KBS. In fact, the causal net defines partial execution order; where the nodes located farther from the source are being executed after those nodes located closer to the source. It is important to know that the execution order defined in macroexpansion does not necessarily express the real activation of the nodes, since the activation of the node depends also on preconditions and conditional operations defined through the port managers. Following the development of the Functional Model the l-KBS designer defines the Information-Processing Model that determines the activation conditions for every node of the functional model as well as variable mappings 92 between different parts of PSH. Described in Section 5.2.2 port managers perform these tasks by allowing the designer to access the variables of each port connect output variables of another port and arrange for their values to be passed to the internal variables of the node. Port managers enables the designer to create elaborate preconditions that not only include a series of predicates but also define collections of variables that have to be determined before the node is being activated. In addition, the port managers allow prescribing sets of default values to the variables to support standard reasoning as well as reasoning with incomplete data. On top of that, port managers provide a number of features that aid the designer in the process of developing l-KBS. The detailed illustrated example of building l-KBSs using the developed shell is given in the Chapter 6. In that Chapter I discussed not only the particularities of implementation of the proposed methodology, but also give a tutorial on building an l-KBS according to the described approach. 5.3. Framework Restrictions To correctly design an I-KBS using the described approach it is important to understand restrictions that it applies to the design process and the resulting architectures. The nature of the restrictions lies in the position that the described approach takes towards a unitary problem-solving unit. The unitary problem- solver is considered a black box. That is, a problem-solver is being looked at as an entity with known inputs, outputs, and functionality. There is not any other information known about a particular problem-solver. That means that an l-KBS designer manipulates problem solvers as LEGO® blocks without knowing their 93 internal structure, knowledge, and etc. This point of view is close to object- oriented and component-based software engineering from the object or component handling perspective. Therefore, it is reasonable to expect that the benefits of these methodologies to be extended to the described framework. These benefits include ease of components’ reuse, painless upgrade of components’ functionality as long as it does not affect its input and output specifications, ease of modeling and developing. However, software-engineering practices do not necessarily cover all the possible approaches to the designing of an l-KBS. Lets take for instance a generic problem that can be solved by problem- solver A, that in turn needs the result of problem- solver B to solve one of the intermediate steps. Three possible problem-solving architectures would perform a task at hand: 1. Large Black Box. To incorporate problem solver B into problem solver A therefore creating a bigger problem solver AB that performs functions of both problem solvers, A and B (Figure 8) Figure 8. Large Black Box 94 2.I Va 2. Multiple Black Boxes. To divide problem solver A into a number of smaller problem-solvers {A11 Ali; A21 A2j}. Where problem solvers A11 Ali generate inputs for problem solver B and problem solvers A21 A2)- work with the results of A11 Ali and B to produce final result (Figure 9). A2! )—~ -—1 A12 A22 _. —~ n A... L_. -——.l A A2j -~ Figure 9. Multiple Black Boxes 3. Gray Box. Using this architecture the l-KBS designer can access the internal variables of the problem solver A and re-rout them to the inputs and outputs of problem solver B (Figure 10Figure ). B n A Internal Variables T L111 1 Figure 10. Gray Box 95 The first method, Large Black Box, however convenient, poses three major problems. ' First, this architecture makes it difficult to reuse problem solver B in another I- KBS. That is, the reuse of B can be effected by two ways: a) by re- implementing it using acquired knowledge or b) by calling the problem solver AB with the set of inputs that will allow run of problem solver B and then filter the results (if possible). Both methods require considerably more efforts than case of separate implementation of B. Secondly, knowledge acquisition for one complex problem solver often is more elaborate than knowledge acquisition for two separate problem solvers. The reason for this lies in the shift in knowledge engineering where instead of developing problem solver A and B separately and then integrating them, the designer needs to work on these three issues simultaneously. Consider for example a problem of diagnosing of a malfunction (of a Mars probe) where several sub-problems require determining of some value. Suppose that a P8 for determining such a value exists and provides an answer in metric units. Then the designer needs to incorporate this PS into the structure of the diagnostic PS remembering not only to provide all necessary integration, but also to convert units from metric to SAE within the same problem solver. This leads to the third problem. Problem-solving architecture of AB problem solver is more complex then the respective architectures of problem solvers A and B separately, which may lead to difficulties with I-KBS’s maintenance. 96 The second architecture, Multiple Black Boxes, addresses three above problems by chunking the problem solver into smaller black boxes with simpler internal architecture. Nevertheless, in turn, states another two. . First, knowledge engineering for developing Multiple Black Boxes architecture for this problem might be “unnatural” for customary domain problem-solving practice. That is, the problem at hand might need a finer slicing (in knowledge and problem-solving methods chunks) then usual for the domain specialist. Lets look at the problem, introduced in the previous example and consider how it could be solved using Multiple Black Boxes architecture. First, every part of the diagnostic PS that uses the results of value setting PS becomes a separate problem solver and is being dealt with separately. Secondly, the part of diagnostic PS that prepares the data to be run by value setting PS also becomes a separate PS. Lastly, it is necessary to introduce an additional module that will convert units from metric to SAE. . Secondly, the growth of the number of cooperating problem solvers in an I- KBS may lead to a more complex architecture, which may hinder the system’s maintainability. The Gray Box solution is very popular nowadays in multi agent architecture. However, its implementation requires knowledge of internal structure of problem solver A and changing a point of view at a unitary problem solver from black box to gray box with the possibility to access internal variables and manipulation with them. Yet, in many cases the insides of a unitary problem solver are not visible to an l-KBS designer, especially in the case when the 97 system is being built by integrating readily available components. In addition to that, changing of the internal structure of a problem solver that is being used in several l-KBSs leads to an avalanche of changing code and/or knowledge in all co-operating problem solvers. Constant trade-off between ease of implementation, ease of maintenance, and ease of re-use drives the l-KBS designer to choose the most appropriate integration structure. The described approach leans towards the black box point of view at the unitary problem solver, therefore excluding Gray Box structures from the list of alternative solutions to an integration problem. Consequently, implementational framework that supports the development of l-KBSs using the described approach drives the designer to use Large Black Box or Multiple Black Boxes solutions to the integration problems. Yet, it is possible to escape to the Gray Box architecture using legacy implementation of MRD and HC. 98 6. ILLUSTRATED APPROACH To better understand the advocated approach it is helpful to walk through the process of building an l-KBS step-by-step using the developed Shell for Constructing Integrated Knowledge-Based Systems (S-Force). As an example, I will use the simplified problem statement for Socharis: to generate a family of applicable conceptual manufacturing plans from a conceptual description of a composite assembly. The knowledge-based kernel of this system deals with the problem of selecting, instantiating, and estimating a number of modern manufacturing technologies used to produce composite parts and consists of more than thirty unitary problem-solving modules. To make a walk through the system building process using S-Force readable I will limit the number of technologies that are considered for instantiation to Hand Lay-up and Resin Transfer Molding (RTM). In addition, I will reduce the number of estimation metrics to Part Turnaround Time and Tooling Cost metrics. Such limiting by no means lessens the control complexity of the I-KBS but instead it only reduces the number of problem-solvers that are being governed by the similar control and mapping structures. The description of full version of re-designed Socharis can be found in Section 6 and Appendix B. Similarly to the original, the problem of Socharis* - an abridged Socharis - is divided into three major parts: the technology selection, the technology refinement, and the technology estimation. At the first stage Socharis* chooses the manufacturing process according to the description of the composite part: 99 shape, material, tolerances, etc. Then, if RTM and/or Hand Lay-up technologies are selected, Socharis* sets the manufacturing parameters suitable to manufacture the composite part (multiple results are likely). Finally, for each of the parameterized manufacturing technologies, Socharis* calculates normalized metrics for the part’s turn around time and the tooling cost to help the designer to decide between multiple alternatives. The number of GT-based problem-solvers was developed to solve different subtasks of the overall Socharis’s problem. All separate problem- solvers were built using a consistent ontology of manufacturing with composite materials constructed as a part of the Socharis project. A list and short description of problem-solvers that are re-used in this example are shown in the Table 5 Name Type Responsibilities OperationSelector Hierarchical select manufacturing technology Classifier RTMRefiner Multiple Routine Set parameters for the RTM process Designer Lay-upRefiner Multiple Routine set parameters for the hand lay-up Designer rocess Part'I'I' Multiple Routine calculate metrics for the part turn Designer around time ToolingCost Multiple Routine calculate metrics for the cost of tooling Designer used to manufacture the part Table 5. Problem-solvers, participating in Socharis *. Building of an l-KBS using S-Force is done in stages, by constructing three models: 100 6| “A W 1. Task-subtask decomposition model or problem-solving hierarchy that shows a recursive division of the problem into smaller problems that could be tackled by unitary problem-solvers. 2. Functional Model that shows a function (or a role) of each part of the l-KBS in the problem-solving process. 3. Information-Processing Model that shows how information (variables and control) is used and is passed between the different parts of the l-KBS. In the following sections, I will describe the steps that the developer of the l-KBS takes to build these models and completes l-KBS in the S-Force environment. 6. 1. Building the PS Hierarchy The first step in building of an l-KBS using the developed shell is to construct a decomposition of the l-KBS into PS-subPS hierarchy: problem- solving hierarchy (PSH). This PSH is not a functional l-KBS, but rather a model of it that shows all available parts of the l-KBS organized in the meaningful clusters. These clusters represent task-subtask decomposition of the problem as it had been elicited from the field expert. Another way to look at PSH is that the solution of the problem defined for a node in PSH depends on the solution of its children (but may depend as well on the solution for other nodes). However, the actual order of subtasks’ execution and the restrictions on variable passing are defined in other models: functional and information passing. 101 6.1.1. Socharis* Example The problem-solving process for Socharis* could be divided into three parts: Technology Selector, Technology Refiner, and Estimator. Two latter also are divided into smaller parts: Lay-up Refiner and RTM Refiner, Tooling Cost Estimator and Part Turnaround Time Estimator respectively. This decomposition reflects problem-solving procedures usually performed by the manufacturing engineer while assessing alternatives for the part production: 1. Assess all possible spectrum of applicable technologies. 2. Consider possibility of altering different parameters. It is possible that one needs to consult different experts to set the correct parameters (in our case RTM and Hand Lay-up experts. ) 3. Evaluate choices according to the set of pre—defined metrics. The set of metric has to be pre-defined and normalized in order to provide fair estimation of alternatives (e.g. Tooling Cost and Part Turnaround Time). To start working in the S-Force environment, the l-KBS designer launches a correspondent VisualWorks image FRIPS. then clicks on the F button in the launcher toolbar to start Generic Task Integrated Toolset. Figure 11 shows the cascaded set of interfaces that guide the user through the process of creating new l-KBS: 1. Select PS -) New from the menu bar 2. Enter the name of the new l-KBS OD . Select the type of problem-solver "FRIntegratedProblemSolver" 4. Click 0k 102 Following, the designer creates the root of the hierarchy and subsequently adds subs to it in the "FR -) Device Hierarchy" editing window. Addition of a root is done by selecting "Relation -) Add root" from the top menu followed by entering the name of the node in the correspondent dialog window (Figure 12). PSH can have multiple roots if this is required by the particularities of the problem at hand. Ii? ‘ PS My 1123134” ' Choocotholypodl’loblomsmm M11:31:09¢n Name of new Problem Solver: < Fm” TOK—. cw“ " 4' ‘ :.:._' in - Lunch I i ' Figure 11. Cascaded set of interfaces guiding the developer through the rocess of creating new I-KBS Socharis Refiner __—J: What I: the name at the sub device 2 T_e—_chnology Se I Mal i_iflfli 1:1 Figure 12. Adding a sub to the node of PSH 103 Attaching subs to a parent node is done by action-clicking11 on the node where the sub is to be added, selecting Create Sub Device from the pop-up menu and entering the desired name (Figure 12Figure ). Part TT £311me A I Estimator |< Tooling Cost Estimator] ‘ 1 Example Socharis] W Layup Refiner I Technology Selector |\ i i RTM Ret'nerl \l \I I/ Figure 13. Problem-Solving Hierarchy of Socharis * Figure 13 shows complete PSH of Socharis* that mirrors task decomposition described earlier in this section. However, it is impossible to make any conclusion about run time order of activation of PSH nodes. This order is determined through functional and information passing models 6.2. Functional Model: Assigning Functionality to the Nodes of PS Hierarchy The next step in building an l-KBS is to define the Functional Model for its every part. Traditionally the list of behaviors' types consisted of “by Knowledge”, “by Definition”, “by Function of Device”, and “by Behavior of Device”. l augmented this list with the “by Problem-solver” type that allows associating a GT-Based problem-solver with a particular node of PSH. This behavior type u Action-click is middle button on 3-button mouse or Ctrl + right button in Win X environment, or command Click in Macintosh environment. 104 enriches the current implementation of FR modeling framework by allowing complex problem solving procedures being executed at the unitary device level instead of simple one-step operations. The distinction between types of behaviors is explained in Table 6. Type Description By Knowledge Unitary behavior. ls based on the common to particular domain knowledge. By Definition Unitary behavior. ls based on the domain definition of particular device. By Function of Device Complex behavior. Calls other device’s function By Behavior of Device Complex behavior. Calls particular behavior of another device. By Problem-solver Unitary behavior. Calls an associated with the node GT- based problem-solver Table 6. Description of types of behaviors employed in Functional Model of l-KBS To facilitate l-KBS building and maintaining, every node of PSH is associated with a variable - Number (stage counter) - which serves as a counter of problem—solving stages. This helps in supporting necessary bookkeeping as well as marks the meaningful milestones. As a rule, before the node is activated for the first time during problem-solving process, the value of stage counter is set to zero (unless otherwise specified by the system developer or the user). Each step in problem-solving process (or state change in traditional FR) is being marked by incrementing stage counter value. For example, if a device A has a function an with a behavior bhA of the type "by 105 Problem-solver: psA", then the state change that occurs in the bhA correspondent to the function an of the device A is as follows: A Number = 0 -) by ProblemSolver psA -) Set A Number to: 1 This information can be used to check if a particular node had been invoked during the problem-solving process and to check the status of the problem solving in case of multiple state-changes in a behavior of a node. On practice, the assignment of functionality is the bottom-up process. The developer associates the unitary functions with the lower level of PSH and then, builds the functional definitions of the upper nodes using the lower nodes functions and behaviors as building blocks. In this implementation, l limited the types of invoked GT-Based problem- solvers to Hierarchical Classifier and Multiple Routine Designer to support legacy software. On the other hand, these two types of problem-solvers cover broad enough spectrum of classes of problem to be exclusively used in the development of Socharis. However, as was noted earlier, there is no theoretical limitation on the type of unitary problem-solver that could be used in the advocated approach. §._2.1. Socharis* Example To define the functionality of each of the leaves of PSH the developer performs the following sequence of actions: 1. Action-clicks on the correspondent node and chooses "Browse device" from the pop-up menu 2. Action-clicks on the upper pane and selects "Add function" and Enters the name of the function 106 3. Calls the behavior interface by double clicking on the added function name in the upper pane 4. Adds behavior similarly to adding function 5. lnvokes behavior relation interface by double clicking on the name of the behavior 6. Finally, action-clicks on the Name Number node and chooses "Add state change" from the pop-up menu and then, selects the type of the state change link. '11. swarm panel. Bohaviou emu: 5 . Exanple Socharis Rather I . . 1 > l i V .Rehtlon inky l i , Bahaviors A Technology Selector ‘ Technology Selector Number - OJ :’ sag Davim ’ A i By ProblemSolver ‘0pemtion_$elec1or i ""2‘ Set Technology Selector Nutrbor 101 .i -. . 2"! . ‘ . ~ {‘1 l Figure 14. Sequence of interfaces leading to behavior definition Figure shows the cascaded sequence of interfaces that result in the definition of the behavior for the Technology Selector. PS Hierarchy window shows PSH of Socharis“. FRIPS Device window provides interface to information about a device (in this case, to the device Technology Selector) its functions and sub—devices. By selecting browse function (or double clicking on a function name), the user invokes function interface: a window with title FRIPS Function that shows all constituent behaviors of the function. The last 107 window - stBeh Behavior — was called from FRIPS Function. This interface represents behavior that leads to achieving a correspondent function. Below are the descriptions of functionality for each node of PSH for Socharis*. Device Function Behavior Operation Select by problem-solver Operation_Selector_New. Selector Technolog SimpleHCP Set operationSelector Number to 1 Y Lay-upRefiner Refine by problem-solver: Lay-up. Lay-up BasicRDProblemSolver Set Lay-upRefiner Number to 1 RTMRefiner Refine by problem-solver: RTM. BasicRDProblemSolver RTM Set RTMRefiner Number to 1 PartTT Estimate by problem-solver: PTT. BasicRDProblemSolver P'l‘l’ Set PartTT Number to 1 ToolingCost Estimate by problem-solver: ToolingCost. Tooling BasicRDProblemSolver Set ToolingCost Number Cost to 1. The functionality of upper level node is assembled from the functions of the lower level node as follows. Device Function Behavior Estimator Estimate by function Estimate PTT of device PartTT Technology and by function Estimate Tooling Cost of device Tooling Cost Set Estimator Number to 1 Refiner Refine by function Refine Lay-up of device Lay-upRefiner Technology and by function Refine RTM of device RTMRefiner Set Refiner Number to 1 It is easy to change the functionality of the device by editing the correspondent behavior. For example, to accommodate the particularities of problem-solving process in Socharis* it is necessary to perform estimation of the technological process right after the refining stage. Consequently, the updated functions of Lay-upRefiner and RTMRefiner are represented as follows: 108 .- Device Function Behavior Lay-upRefiner Refine Lay- By Problem-solver: Lay-up. up BasicRDProblemSolver Set Lay-upRefiner Number to 1 by function Estimate Technology of device Estimator Set Lay-upRefiner Number to 2 RTMRefiner Refine RTM By Problem-solver: RTM. BasicRDProblemSolver Set RTMRefiner Number to 1 by function Estimate Technology of device Estimator Set RTMRefiner Number to 2 Finally, the description of the functionality of the root device is described through the functionality of its children nodes: 5* Device Function Behavior Socharis Socharis by function Select Technology of device operation Example Function Set SocharisExample Number to 1. by function Refine Technology of Device Refiner Set SocharisExample Number to 2. 6. 3. Functional Model: Macroexpansion The functional description of each node does not give the full picture of the functionality of the overall I-KBS: to look at the full-blown Functional Model of the l-KBS it is necessary to generate its macroexpansion. Macro-expansion is the net (a directed graph with one or more sources and sinks) that represents causal (and therefore partial temporal) relationships between different parts of the PSH. There is an explicit succession in the execution of the nodes that are located on different levels of the network: nodes closer to the source are being executed before those farther from it. However, the execution order of the nodes that are IOcated on the same level of the macroexpansion cannot be determined from this 109 .- Inn“ me u”. u . .‘ . a“. ‘ a p k a . ‘0 a . " \‘h V; ‘O r M . ' p. ‘I Q . ‘5 ‘ \ b t . ‘- I a . ‘- u model. In addition, macroexpansion does contain neither information about variables passing between different parts of l-KBS, nor control knowledge about conditional nodes invocation, conditional looping, etc. The role of Information- Processing Model described in the next section is to explicitly define this kind of knowledge. _6_.§.1. Socharis* Example In order to assess the global causal story correspondent to the developed l-KBS the designer builds macroexpansion by selecting "PS -) Build Macroexpansion" in the menu. The macroexpansion of l-KBS Socharis* (Figure 15) can be browsed by selecting "Browse -) Browse Macroexpansion" from the top menu. To better understand what macroexpansion represents, let us examine Figure 15 more closely. This macroexpansion is read top—down (or left-to-right in case the user flipped the macroexpansion using one of the available commands). An explanation to this macroexpansion of l-KBS Socharis* could be given as follows. If Example Socharis Number equals 0 (i.e. the system has not been run yet) and Technology Selector Number equals 0 (T echnology Selector has not been invoked before) then S-Force runs problem-solver Technology Selector which sets the Technology Selector Number to 1 (i.e. acknowledges that this node has been invoked once. ) According to the behavior of the Example Socharis node, this finalizes the first stage of the problem solving process by setting the Example Socharis Number to 1. Then the systems checks if Refiner, 110 Lay-up Refiner, and RTM Refiner have not been called yet and if this is true, invokes the problem-solvers Lay-up and RTM. Further, after testing the invocation of Estimator, Part TT Estimator, and Tooling Cost Estimator, the system runs problem-solvers Part_turnaround_time, and ToolingCost. Finally, after all nodes finished successfully the system sets correspondent Numbers: Part TT Estimator Number and Tooling Cost Estimator Number to 1, Estimator Number to 1, Lay-up Refiner and RTM Refiner Numbers to 2, Refiner Number to 1, and at last Example Socharis Number to 2, therefore finishing problem-solving process. Example Socharis Wfll | l T echnoloqy Selector Number 2] By ProblemSolver ‘Operdion_Selector' Set Technology Selector Nimber To 3 seExanipleSocmmNumaroil Ref’nerNurnber-O Layup Refiner W - o] RTM Retner Mmberfl By ProblemSolver. ‘Leym' Set Leytp Refiner Mariner To 1 I By ProblemSolver: 'R‘IM' Set RTM Refiner Number To 1J \ Estimator Mmber -0 PartTTEst‘matorMmeer-Ol ToothostEsti‘ndorNurnber-O] » By ProblemSolver. Pat_tuneromd_tfme‘ Set Part TT Estinator lumber To lj By ProblemSolver: 'Tool'lng_cost' Set Tooling Cost Estimator Nimber T01 I SetEstimdorNunberTofJ SetEstlmatorNu'nberTo1] SetLeyupRemeerberTo2] SeIRTMRer’nerMmeerTo2] SetRet'nerMmberTofl SetReflneerberToll SetExempleSochenstberTofl Figure 15. Detailed macro-expansion of Socharis* 111 This is a detailed macroexpansion that shows both, pre— and post- assertions on Numbers. On practice however, it is more convenient to use condensed form of macroexpansion that displays only pre- assertions as shown on the Figure 16. 5" Macro [mention I Emmi mmmfl l l TeuvuogySelectorW-OI l l ByProblemSONer ‘Operulon_Selector‘SetTecmology Selector WTot dime 0| l me-Ol LewaetnerW-OI RTMRemM By ProuerriSolver: Leyw' Set Leyw Ret‘ner number To 1 nine 0| By ProblemSolver 'RTM’ Set RTM Rerner W T01 atT'me 0 EMUW-O . PatTTEstMoerber-OI ToothostEstmdorW-OI l i ByProblemSolver. m_Mn«m_me-sam n Estmotorlunber T01 armLo] ByProblemSolver 'Toohgjoa'Set roolmcw EMUW Tot dT‘mezfl i‘l b— 4 / Figure 16. Macroexpansion of Socharis* 6. 4. Information-Processing Model In order to define Information-Processing Model of an l-KBS it is necessary to perform six tasks: 1. Define input and output for every node of PSH. l.e. explicitly specify all variables that participate in a particular node prescribing whether the variable is input, output, or neither. 2. Determine whether or not the result should be passed to an upper device in PSH. 112 3. Define default values of input variables. l.e. assign values to the variables that will be used in this node in case a user or previous problem-solving activity has not assigned them. 4. Define mapping between different nodes. If a node takes its input values from the other node(s), it is necessary to explicitly specify that variables of the node take their values from a different node(s). 5. Define all preconditions to the nodes. l.e. specify qualitative, quantitative, and existential predicates that should be satisfied in order for the node to be activated. Qualitative and quantitative predicates are the tests on qualitative and numerical l-KBS variables respectively. In case of multiple predicates the system performs logical AND operation for all qualitative and quantitative predicates. Existential predicate is the table in which the designer indicates what variables should have values (be set) for the initiation of the node. It is possible that a particular node could be initiated with different sets of input variables therefore, S-Force performs logical OR operation for all existential predicates of the node. 6. Define the node’s activation control that depends on multiple output of other node(s). There are two types of this kind of control implemented in S-Force: iteration on the multiple output of other node(s) or conditional activation of a node using multiple output of other node(s) as a test expression. Port managers introduced in this dissertation resolve these tasks through convenient interface and automation of l-KBS building. 113 6. 5. Information-Processing Model: PSH S-Force gives two ways to define input and output information for every node of PSH: 1. Manually: by filling database with variables as its normally done within Generic Task Integrated Toolset and then updating port managers’ contents from this database. 2. Semi-automatically. In this mode S-Force automatically imports variables from the databases of cooperating problem-solvers and fills in internal variables for the ports. The designer then adds more variables it necessary, distributes variables into input and output variables’ lists, etc. Semi-automatic mode takes part when the l-KBS designer associates a behavior of a node with a particular existing GT-based problem-solver. S-Force imports all the variables from this problem-solver, converts variable types to the necessary standards, updates l-KBSs database with these variables, and adds these variables to the set of internal variables of the node. After all the variables of a problem-solver are imported into the l-KBS model, each variable is given a flag that indicate whether this variable is input, output, or neither. Finally, for each node of the PS hierarchy the designer identifies default output variable: a special kind of variable that holds values of the result of the node’s execution and whether or not this variable should be passed up the problem-solving hierarchy. There is no strict limitation on the direction of the variable assignment process: top—down or bottom-up traversal of PSH. On practice, the designer uses a mix of these strategies to see which study matches better to a specific 114 part of the PSH. Generally, it is a good idea to start with the node that is called first in the macroexpansion, and works its way down the macroexpansion network. $5.1. Socharis* gamble Updating I-KBS’s database with variables imported from a problem-solver is done automatically at the time the designer develops the Functional Model of the l-KBS and uses state change link type “by Problem-solver", as was explained in previous section. In order to access information about node’s variables it is necessary to action-click on the node in the PS Hierarchy Window and select Browse Port Manager as shown in the Figure 17. The Figure 18 represents the top pane of the Port Manager Interface for Lay-up Ref iner node that provides front end to Port Manager’s functions for managing variables. 5” PS Hierarchy HE] E Part TT Estimator] -\ Estimator |< Tooling Cost Estimator | Example Socharis M v LaWP R8“ Create Sub Device Technology Selector | Browse Device RTM Refine Browse Port Manger l4 Inspect Ream ' Standard Operations , Figure 172. Opening Port Manager interface 115 5" Port manager for: Layup Refiner HE] B All Variables Odput Variables — - Layup Refiner Idurrme .5 __> I ltoolingList .5 Laura Refine—r Fiesull <-. I Tool complexly Lat/urn Refiner l‘Itil poslcurlng curing type Browse Layup Refiner Resul :::~:-;.tr‘.n labor roar-Liz: 3" mm resin preprenget functional rental ftllrj‘r' _ termerature cn 212122.! curing type labor Md l manTechList post-runny ILeyup Refiner numb: are: 5 we 970W“ I “presswe producilol‘ .— / Remove I I Figure 18. Upper pane of the Port Manager Interface that allows manipulating with the node’s variables The central list is the list of all variables of the node: input, output, and internal. By clicking on the buttons at the right lower corner of this list the user can browse or remove a selected variable. To add a variable to the list of internal variables the designer clicks on Add button and chooses a variable from the database or by selecting ‘—another name—‘ from the list has a possibility to add a new variable to the l-KBS. A variable from the central list could be redirected to the input or output lists by selecting a variable and clicking on the left (to transfer to the input list) or right (to transfer to the output list) arrow. Button operation is associated with the input variables’ list. It enables the designer to assign actions that have to be done with the variables before the node is being activated (preconditions, defaults, mappings, and controls). The detailed description of each of mentioned operation would be given in the next Sections. Button Propagate Up is mostly used in the development stage when it is necessary to propagate the variable to the upper level node (for variable mapping purposes for example. ) To unload a variable from the input list the 116 designer selects it and click on the right arrow button located above Browse input variable button. Right hand side of the variable pane contains the list of output variables and four buttons: 1. 2. left arrow for unloading a selected variable from the output list Browse to browse a selected variable . Set Default to set the selected variable a default variable for the resulting value of node's operation, and . Pass result up button. This button sets the flag on the output variable that it should be passed to the upper node after the node finished operation. ' I Add l Lewaefher Resrl Br , Toolcornplexty i We Do you want to create a new variable . functional requremr it database? I SmallTallt Variable I fiberList . : depth i” E I Enter the name of variable I Layup Resuli I OK I Cancel I I Figure 19. Adding new variable to a node If the node functionality Is achieved through the “By Problem-solver” behavior, then result of, problem-solver is saved in to a variable of Smalltalk type Dictionary. In this case the designers executes the following sequence of actions 117 to determine where the result of problem-solver is being stored and how it is being passed up. 1. 2. Create new variable by clicking Add button and Selecting “another name‘ In the following dialog window, click on the Smalltalk variable button and enter the name of this variable. Figure 19 shows the cascaded set of interfaces that result in creating new variable Lay-up Refiner Result The next step is to move this variable to the output variables’ list. This is done by selecting Lay-up Refiner Result variable in the list of all variables and clicking on the right arrow at the upper right corner of the all variables’ list. Then, it is necessary to make this variable the Default output variable. Selecting this variable in the output variables’ list and clicking Set Default does this. Finally, if the designer decides to pass this variable up one level he or she selects this variable and clicks Pass result up and then, selects the output variable of the upper node where to pass the result. Note 1: the output variable of the upper node should already exist. Note 2, if a node receives results from more than one of its children it concatenates them, no intermediate result is lost. Figure 20 shows the set of interfaces that result in passing the value of Lay-up Refiner Result to the Refiner Result. 118 I. A ' - ‘ 4‘.“ v\‘ r _ , ...r' ,. "r ‘3. , . "‘9.“ ,. ...I.‘ I a WWW . Choose the Port to map to: Figure 20. Passing the result variable up one level The description of input and output variables for port manager for Lay-up Refiner is shown in the Table 7. Input Variables Internal Variables Output Variables Lay—up Refiner Number Lay-up Refiner Number Lay-up Refiner Number Lay-up Refiner Ctrl Lay-up Refiner Result Lay-up Refiner Result Depth Lay-up Refiner Ctrl curing type FiberList curing type labor Functional requirements depth postcuring Geometrical Complexity FiberList pressure Production functional requirements resin prepreg/wet ResinList Geometrical Complexity temperature Size labor Tool complexity Surface Quality postcuring toolingList Tolerances pressure manTechList production resin prepreg/wet ResinList size Surface Quality temperature Tolerances Tool complexity toolingList manTechList Table 7. Variables of Lay-up Refiner Port Manager. 119 All variables but Lay-up Refiner Ctrl, Lay-up Refiner Result, Lay-up Refiner Number, and manTechList are the variables from the correspondent problem-solver Operation_Selector_New. SimpleHCPS. Lay-up Refiner Result contains the result of the execution of this node. In this case, it will hold the name of the established specialists of hierarchical classifier. Lay-up Refiner Number is a bookkeeping variable that helps keep track of PS stages. Lay-up Refiner Ctrl is the control variable that controls the execution of this node. Finally, manTechList is the output control variable that holds input control value that activated this node. Descriptions of input/output/internal variables of other port managers for Socharis* can be found in Appendix A. 6. 6. Information-Processing Model: Input and Output Default values of input variables are used in cases where an existential predicate requires the presence of this variable but it was not supplied to a node. This feature of S-Force gives the designer an ability to develop robust systems, which are able to work with incomplete data. However, it is not a necessary step in the I-KBS development and might be skipped. 6.6.1. Socharis* Example To access an interface that allows various manipulating with input variables including definition of default variables the designer clicks on the operation button. This opens the bottom pane of the Port Manager Interface (Figure 21). At the lower right corner of this pane located the Default Values interface: a table with the left column containing all input 120 variables and right column representing their default values, where question mark (‘?’) means undefined. If the designer wants to set a default value for a variable he or she: 1. Clicks on the row in the Default Values table containing the desired variable 2. Selects the default value from the pop-up menu 3. Clicks Ok To reverse default values to undefined state the designer clicks Set to ‘undefined’ buflon. It is Important to exercise caution in using this feature. If used improperly it could mask problems in the l-KBS architecture such as gaps in variable mapping. In fact, it is better to develop the system first without employing default values’ tables and only then add them. Figure 21 shows that the default value for Res inList variable of Lay-up Refiner node is set to DGEBA. This means that if the value of Res inList was not set by previous problem-solving activity it will be set to DGEBA. 121 )2 Port manager [or Layup Helmet m Variables NI Variables 7 Output Variables ) tberLlst A <.. I Eeyup Refiner Numbe I: n) I emperalure .t Leyla: Refiler Name Layup Refiner Resu‘t <.. I Layup Ref’ner Nunu Tolerances Layup Refiner Ctrl manTechList Layup Refl'rer Ctrl curing type Browse J ooimList GeometricalComplext‘ Betta pressure prochctfon fiberList 5" 0““ l Layup Rether Result fu'ldionel reqtiemerr _q) functional requiremen _ Tool cornplexiy depth —J Geometric all omplertlt‘ PT“ rm '43 I postcuhg resil'Ust Browse I labor Md I tutor size ' postcuring rash preprenget I SufeceQudy mm I pressure 9'0“" l suing type _II Pr W . Up I production I Remove I 7 When: Wt WU” plum Qua'ttdive Exidence who I l Set to ‘Lnddined’ | Figure 21. Interface for definition of default values of input variables 6. 7. Information Processing Model: Mapping The next task is to specify how the information flows from one node of PSH to another during the problem-solving process. That is, to determine variable mapping between different parts of PSH. S-Force gives the ability to do so by using Mapping feature of Port Managers. Any node could receive information from many different sources during the problem solving. Moreover, depending on the problem-solving context a node could receive different kinds and type of information from the same node at different times. To accommodate this, S-Force enables the designer to create multiple variable mappings. At run time the mapping works as follows: once the 122 node is reached during the problem solving, S-Force iterates over the list of mappings and fills the values of all the variables that are defined there. There are two things that the l-KBS developer should keep in mind while mapping variables from one node to another: 1. Both variables (source and destination) should be defined using the same working ontology. Failure to do so will lead to a non-functional l-KBS since S- Force does not have enough information to translate the values. One of the solutions to this is to create translator problem-solver and map the variables through it. 2. If the mapping to be done from multiple output of a particular node then it is necessary to appoint a variable that would control mapping from this multiple output. The exact procedure of how to use multiple outputs to control a node is described in the Section 6.9.3 (RD Control). 6.7.1. Socharis* Example After clicking the operations button in the Port Manager’s window the designer accesses the interface that allows manipulating with input variables of the node before the node’s activation (Figure 21). To start working with mappings the designer clicks on the Mapping button, which calls mapping managing interface in the middle of the bottom pane. Then, to create mappings the designer repeats the following sequence of actions for each desired mapping: 1 . Clicks on the Add button 2. From the appeared list of ports managers associated with every node of PSH, the designer selects the port manager to make mapping from (source port). 123 3. Enters the suffix (usually a number) to differentiate between multiple mappings from the same port and clicks 0k. 4. The interface that allows defining a mapping is similar in feel to the Default Values interface. That is, by clicking on the row containing the name of the destination variable in the left column the designer calls list of all available source variables from the source port. The Figure 22 shows the cascaded set of interfaces that result in addition of mapping RefinerPort@1 for Lay-up Refiner Port Manager (a destination) from Refiner Port Manager (a source). ., . Layup Ref’ner Reed! ? W I iRTM RefnerPort Layup Refner Ctrl 7 PctTTEstin‘orl Baerarlflxforthlamappha c . W 7 ‘ lwI M“. 2.- I I l I I I L Figure 22. Adding of mapping 124 Lay-up Refiner node has two mappings: 1. One from Refiner node: all input values necessary for running the Lay-up multiple routine designer. 2. Secondly from Technology Selector node. This mapping indicated that input control variable of Lay-up Refiner is to be taken from output variable TSResult. The detailed description of setting up this kind of control is given in the Section 6.9. The designer can also delete and edit a selected mapping by clicking on buttons Remove and Edit correspondingly. 6. 8. Information Processing Model: Preconditions One of the roles the Port Managers play in an I-KBS is the setting and testing the preconditions. This role is inherited from the precondition clause of the traditional FR. The precondition clause usually contained a set of qualitative and quantitative predicates, all of which should be satisfied before the node is allowed to be executed. Meanwhile, the described framework augmented the precondition clause with a new kind of precondition: existential predicate. Existence predicate contains names of Input variables whose presence is necessary for running the node. This ensures that the node with multiple functionality and/or behaviors each of which uses just a subset of the data runs as soon as it receives enough data to execute some of its paths. 6.8.1. Qualitative and anntitative Predicates Qualitative predicates are designed to test l-KBSs variables that take value from a predefined collection of legal values, whereas quantitative 125 predicates test the values of l-KBSs numerical variables. A test expression for quantitative precondition may include complex formulas that could contain other l-KBSs variables. One important thing to remember while writing testing formulas for quantitative predicates is that precedence of arithmetic operations in these formulas is governed by the Smalltalk laws: all formulas are read left to right and no implicit precedence is stated (that is 2+3‘5 = 25. ) §.8_.2._I_Existential Predicates As it was mentioned earlier, existential predicates are used to specify sub- sets of input variables that should be set in order for the predicate to be satisfied. If there are more than one existential predicate defined for a particular port manager, then the collection of existential predicates is satisfied if either of members of this collection is satisfied. In addition to the function of activating the node whenever it has enough defined input variables to activate some of the behaviors, existential predicate play another important role. In a case when the node is called but there is not, enough information to run the node S-Force uses existential predicates as a template to fill in values of input variables from the default values table. 6.8.3. Skocghafls' Example To access interfaces for manipulating predicates the designer selects a Qualitative, Quantitative, or Existential from the predicate types list located in the upper left corner of lower pane of Port Manager Interface as shown in the Figure 23. 126 Dalaut Values SYM33830Pre A Surface Refiner ? fiberUst Refiner L____H \L Add I Remove I Browse I Sdto 'unddined’ I Figure 23. Predicate types list located at the upper left corner W“ SYM3383OPre IS. I- Variable Mater Value rem —"I ~' -—'I unknown -4I Figure 24. Qualitative predicate interface After the predicate type is selected, the central window shows the list of defined predicates of this type. The designer can add new predicate, remove, or browse selected predicate. To add a qualitative predicate the l-KBS designer: 1. Selects Qualitative in the predicate types list 2. Clicks Add in the central window 127 . In the appeared interface (Figure 24) the designer selects a qualitative variable from the Variable drop list, equals on not equals sign from the Operator drop list and a desired value of this variable from the Value drop list. . Clicks Ok To add a quantitative predicate the l-KBS designer: . Selects Quantitative in predicate types list . Clicks Add in the central window . In the appeared interface (Figure 5) the designer selects a Quantitative variable from the upper left Variable drop list, equal on not equals sign from the Operator drop list. In the right hand side calculator the designer enters the necessary formula using the Variables drop list to enter variables in the formula (operator precedence agrees with Smalltalk standards). . Clicks Enters and 0k 128 . _————————_——————_———,H W“ 5” Quantitative Predicate Node Browser HEB I W reqiiemen Tolerances procuction —rl- elf yaw. apnea I liliJflil—me quadratic——l k—w-.ww‘~- M— ..m—p- fi--.—-’~—n- . F~._ Figure 25. Quantitative predicate interface To add an existential predicate the l-KBS designer: 1. Selects Existence in the predicate types list 2. Clicks Add in the central window 3. In the Existential predicate interface (Figure26) the designer clicks on the rows that contains necessary variable therefore changing "2’ (not needed) to ‘*’ (should be set) - 4. Closes table 129 ”1..., St" lily ; Exrslence Predicate BE Layup Refiner Ctrl resinList * J Layup Refiner Numbe depth . GeometricalComplexlt' L R f' Ct l 7 functional requiremen 8WD 3 my r ' “forum functional requirements ' production Tolerances ‘ 7 SurfaceQuaIity ' GeometricalComplexity ' '- production . fiberLIS‘l " Layup Refiner Number ? I size Figure26. Existential predicate interface 6. 9. Information Processing Model: Activation Control Predicates’ mechanism allows testing preconditions for single valued variables and does not account for multiple results and multiple valued variables that are produced by problem-solvers employed in an l-KBS. However, it is highly desirable to have this feature to enhance the control over the I-KBS's execufion. S-Force operates with two basic types of GT problem-solvers, each of which could produce multiple results: Hierarchical Classifier (HC) and Multiple Routine Designer (MRD). Hierarchical Classifier results in a set of parameters with values: ‘matched’, ‘neutral’, ‘against’, etc. These values correspond to the HC’s confidence of how a particular parameter fits to the situation described through input variables. MRD’s output is a collection of sets of instantiated 130 parameters. Each set of this collection represents a valid solution to a given problem. It would be reasonable to allow the designer of an I-KBS to use these output to control the problem-solving process by either iterating over the MRD’s output or selecting a next part of l-KBS to activate based on HC’s output. In addition to above S—Force enables the designer use boosting, i.e. combining the results of a number of problem-solvers into a single result by selecting the results intersection (in a set theoretic notation). This technique is widely used in the many areas of artificial intelligence including machine learning (Schapire, Singer et al. 1998; Schapire and Singer 1998). In S-Force’s version, the designer can perform boosting of results of several hierarchical classifiers. This technique saves the time at the knowledge acquisition stage by allowing solving a given problem using different perspective in the multitude of problem- solvers in cases when the structure and knowledge architecture of a single problem-solver (that considers all aspects of the problem) is complex or unclear. 6.9.1. HC Control The result of Hierarchical Classifier (HC) is the list of its leaf specialists with their respected established values (e.g. matched, neutral, against). Hereafter, I will refer to all the specialists with values ‘matched’ as established specialists. It is often the case that the further l-KBS execution depends on the established specialists (e.g. a particular HC selects one or several named parts of an I-KBS to execute next. ) This behavior is very useful in implementing and modeling blackboard like mechanisms in an I-KBS, where the context defines 131 activation of the next module at the run time. S-Force enables the designer to use this kind of control over the I-KBS behavior in the run time through the HC Control. The designer creates a special input variable (a control variable) that is being mapped to from the source node - the node that produces multiple result. Then this control variable is associated with a set of values. When at least one of these values are matched to one of the values that are mapped from the source node the current node will be activated. To finalize definition of the HC control the designer should designate a variable that will keep the value that caused the activation of the node. This helps to keep current problem-solving context up—to-date. While the HC control is most suited to be used in adjunct with Hierarchical Classifier type of problem-solver it can also be used with any node that produces multiple results similar in nature with the result of H0. The use of the HC control with the booster is one of the examples of such operation (Section 6.9.5). 6.9.2. Socharis*gxample In the described example, the Lay-up Refiner node is being activated if the . Technology Selector node is HC Operation_Selector_New. SimpleHCPS has Lay-up as one of the established specialists. In previous section, I showed how to use the Lay-up Refiner Port Manager to execute mapping from a node to a node of PSH. The Figure 27 shows the mapping of the resulting variable of Technology Selector TSResult to Lay-up Refiner Ctrl. 132 '0 F Illons ; Variable Mapping . ., ,._-i::.. 3' 7 .l Quaidive . mm Refiner Reset ? Erdstence Ctrl ‘ ? II 'no I I Cartel J Figure 27. Mapping of HC Input Control The designer assigns the control and appoints the variable that will hold the value that activated the node as follows: 1. Adds new variable from l-KBS’s database manTechList and transfers it to the output variables’ list (this variable will hold the value that activated the nodei 2. Adds new SmallTalk variable Lay-up Refiner Ctrl and transfers it to the input variables’ list (this variable will hold values mapped from the other nodel 3. Clicks on the operations button to access input operation interface. 4. Creates mapping from port Technology SelectorPort — Technology SelectorPort@l — as described in Section 1. 7. 1 and maps the variable Lay-up Refiner Ctrl from TSResult. 5- Clicks on the Control button. Then clicks the Add button and selects Lay- up Ref iner Ctrl from the list of available control variables and click 0k 6. Selects Lay-up Ref iner Ctrl and clicks the HC control button 7. Clicks Yes to confirm choice of established specialists from the list. 133 8. Selects TSResult from the list of result variables of Technology Selector Port. 9. Selects Lay-up from the list of available leaf specialists and clicks OK, then clicks Cancel to stop selection. 9.1.lf the designer needs to select more then he or she specialist repeats step 8 until he or she selects all necessary specialists, then clicks Cancel 9.2.lf the designer wishes to input names of specialists by hand, he or she can do it by selecting No at the Step 7 and then entering desired values by hand using ‘%' as delimiter. 10. From the list of output variables of current port selects variable where to send the value that activated the node. In our case manTechList. The set of cascaded interfaces in the Figure results in the assigning HC control to the Lay-up Refiner Ctrl. This control will be satisfied if TSResult will contain Lay-up as one of the established specialists. 6.9.3. RD Control RD Control is associated with the typical multiple routine designer output: a collection of sets of design parameters with established values. One can expect to have the system iterate over the collection of the parameters using each set in problem solving to explore the solution space. In S-Force the designer is able to set this kind of the control of the node by mapping output variable of a node producing such kind of result (e.g. a node whose behavior is linked to a multiple routine designer) to an input control variable. 134 : II I. .. A Quarttdive , ? mm , I ring: {it}? 3:1..- Ilse eetabiehed specialists of the ml: med port can: control? : r ? ill _"°_l ‘7 L" I x m ,mwmmmmmu—al snow.“ I I .1133 CbooeeteatvaluelCaneeltoen M11350" " tobolrlthevabeottlreeortrol: EM -332.le Figure 28. Adding HC Control Similar to the HC Control, the RD Control can be used not only with the nodes whose behavior is achieved through the MRD problem-solver. In fact, the result of any node can be used to control iterations if this result complies with the structure of the output of MRD node. It is important however to take care of variable naming and used ontology. That is the names of the parameters in MRD output sets should correspond to the names of the input variables defined in mapping. The same is true for the used ontology: ontologies of the source node and the destination node should agree in the variables used for mappings. Otherwise, the problem-solving process would be compromised. 135 Output Variables ,— resin prepregMet A <-. labor curing type 3'0““! J ‘temperdure Layup Refiner Numb: 3" ”“3“" I manTechList toolingList pressure Tool complexity postcuring ‘J'c. Passrcsutnp I \l Figure 29. Output Variables of Lay-up Port Manager 6.9.4jocha_ris* Example The assignment of the RD Control to an input control variable is relatively straightforward task. In our example Tooling Cost Estimator should run for all sets of parameters set by either or both Lay-up Refiner and RTM Refiner nodes. The following sequence demonstrates how the l-KBS designer creates a RD Control from the Lay-up node to the Tooling Cost Estimator node. 1. Confirms that Lay-up Port Manager’s list of output variables includes all necessary information: all Lay-up. BasicRDProblemSolver output variables and the node’s designate output variable that holds the result of MRD run (Figure 29) 2. Creates new SmallTalk variable tceLay-upCtrl for Tooling Cost Estimator port manager and transfers it to the input variables’ list. 3. In port manager for Tooling Cost Estimator creates new mapping Lay-up Refiner Port @1 as shown in the Figure 30. Notice that the designer maps not only the variables that are needed for the run of the MRD associated with 136 the node, but also the control variable. Again, it is important to have Lay-up Refiner resulting variables match Tooling Cost Estimator input variables compliant in names and ontology Preconditions Mappings . . f .819pr £le Ad | Qualitative matinerpcfl?‘ “ l Quantitative $5 Variable Mapping Existence Cost Estimator ? manTechList manTechList material cost ? Tool Tool . T cost ? Mapping I cm I Result ‘ Ctrl RTm Ctrl Figure 30. Mapping of Lay-up Result onto Tooling Cost Estimator input and control variables 1. The next step is the assignment of the RD Control to the tceLay-upCtrl variable. To do so the designer accesses operations Interface and clicks on the Control button to invoke control manipulating interface. 2. Clicks Add button and select tceLay-upCtrl from the list of available variables. 3. Selects tceLay—upCtrl in the central window of operations interface and clicks RD Control. 4. Select Lay-up Refiner Port Manager from the list of available ports to specify that control is indeed passed from the Lay-up Refiner Node. 137 6.9.5. Boosting Combining the results of several different problem-solvers working on the same task from different perspectives proved an effective technique; this not only saves the time during the knowledge acquisition stage, but also tends to outperform a traditional approach. This method of combining the results is called boosting. S-Force employs a form of boosting that allows taking the results (in form of lists of values) of two nodes and combining them by finding their intersection. By applying this procedure iteratively, one can perform boosting for multiple nodes. 6.9.6. Socharis* Example Socharis* does not use this capability of S-Force, however in the original project this feature was used when the result of two Technology Selectors were combined to prune the list of applicable technological processes. Each Technology Selector chooses a list of appropriate manufacturing processes depending on: first - part geometrical and functional description; second - part material. To assign a node to a booster function it is necessary to perform the following steps: 1. While defining behavior of a booster node, define state change as “By Definition” and enter ‘of booster’ in the input field. 2. Open port manager interface of this node and create three Smalltalk variables list1, listz, and resulting variable. Note, naming list1 and list 2 is obligatory 138 3. Transfer list1 and list2 to input list, resulting to output list 4. Make resulting variable a default output variable 5. Make two mappings from port managers corresponding to two nodes that produce results for boosting. Map output variables of these nodes to list1 in one mapping and to list2 in another The result of booster node is similar in nature to the output of the node associated with HC: list of established specialists. Therefore, it can be used in another boosting operation. 6. 10. Final Remarks After the l-KBS developer built three models: problem-solving hierarchy, Functional Model, and information processing model, he or she can run the system by creating a new case (an instantiated set of I-KBS’s input variables) and selecting PS 9 Run from the S-Force Launcher window. The result of problem-solving process could be browsed by selecting Inspect Result in action-click pop-up menu for every node in PSH. If designed correctly then the global result will be located in the root of the PSH. 6.10.1. Meme of noggs’Jactivation and mapping seguence To build a fully functional l-KBS it is necessary to understand how S—Force works while running an l-KBS. The run of an l-KBS is a breadth-first traversal of the macroexpansion with performing precondition check, mapping, and defaults assignment. The sequence of actions that S-Force executes when it decides on an activation of a node are as follows: 1. Check if it is necessary to perform HC, RD, or Booster control and mapping. 139 2. In case when no control is specified: 2.1 .Assess all input variables 2.2. Do mapping if exists 2.3. Check Existential predicate and set defaults if necessary 2.4.Test remaining preconditions 2.5. Execute node (e.g. run associated problem-solver, perform state change) 3. In case when HC Control is specified: 3.1.Assess mapped control values and compare them to the list of values that activate the node 3.2. If the condition satisfied then perform steps 2. 1 through 2. 5 4. In case when RD Control is specified: 4.1 . For each sets in input MRD result collection 4.2. Map input sets 4.3. Execute steps 2. 1 through 2. 5 5. In case when boosting is specified: 5.1 . Map two input lists and find their intersection 6. Pass the result to the node up in the hierarchy if specified 7. Update l-KBS current case with the obtained as a result of the node run values 6.1 0.2. Color-coding While building a complex l-KBS it is important to keep track of what parts of the system has been assigned functionality and if assigned what it is. S-Force provides a special color coding of the nodes in PSH to quickly overview the 140 system in design. By selecting Utility -)Show 93 Types in the ps Hierarchy window, the designer accesses the interface where the nodes of the PSH are colored according to the specified function and/or behavior: RD or HC is associated with a behavior of the node the node’s functionality is achieved using “by Knowledge” or “by Definition” behaviors the node exhibits multiple functionality or behavior node does not have a function associated with it yet. Another color coding information available to the S-Force’s user is the coloring of the nodes after l-KBS run. In this case, the color of each node corresponds to the status of node’s activation during the problem-solving process: no precondition is specified and node has been activated precondition is satisfied precondition is satisfied and internal mapping was executed (e.g. mapping multiple routine designer's output to the input of this node) precondition(s) is satisfied after the default values were invoked preconditions are not satisfied the node was not called This color-coding enables fast tracking of gaps in functionality and information passing in an l-KBS. 141 7. RE-IMPLEMENTATION OF SOCHARIS The original Socharis consists of four major parts: the graphical user interface, the ontology editor, the conceptual composite assembly structure parser, and the knowledge-based kernel. This chapter describes how the framework for developing l-KBSs is used to redesign the knowledge-based core of Socharis. The main knowledge intensive section of Socharis is the part which is responsible for generating of manufacturing alternatives, instantiating them with the sets of technological parameters and estimating the merits for each generated alternative as was discussed in Section 4.2. The problem-solving architecture of Socharis and its parts (depicted on the Figure 1) was hard coded in Smalltalk, therefore restricting the maintenance of the system to the people intimately familiar not only with Socharis’s problem and Smalltalk, but also with the legacy software that Socharis is built on. The use of S-Force, the Shell for Constructing Integrated Knowledge- Based Systems, allows re-implementation of Socharis’s knowledge—based core (SocharisKB) in a framework of an advocated methodology that allows the designer and the user accessing the system, its knowledge-level architecture, and problem-solving architecture of its components. 7. 1. Problem-Solving Hierarchy of Re-Deslgned SocharisKB Following the domain dependent decomposition of the Socharis’s problem (Section 2.2) the Problem-Solving Hierarchy (PSH) of Re-Designed SocharisKB (Re-SocharisKB) is divided into three major parts: Technology Selector, 142 Technology Refiner, and Technology Estimator. Represented in the Figure 1 PSH of Re-SocharisKB follows the stationary task-subtask decomposition of the problem from the domain specialist’s viewpoint. Where each of three major sub- problems is‘further decomposed into a number of smaller sub-problems that could be handled by a GT-based problem-solvers or being solved through unitary operations like Boosting. Besides playing the role of task-subtask hierarchy, the PSH provides an access to every part of the I-KBS through the set of functional menus as well as enables system building and maintaining functions. 7. 2. Functional Model of Fla-Designed Socharis The macroexpansion of Re-SocharisKB (Figure 32"“) illustrates causal order of activation of node. Particularly it shows that first, the system selects technologies, then boosts the results of two selectors. Next, it instantiates the selected technologies by running correspondent problem-solver and finally, it estimates the parameterized technologies by activating nodes responsible for running estimator problem-solvers. ‘2 Due to the large size of the macroexpansion, I substituted a system screenshot with its copy rearranged so it fits the space allotted. 143 ’4’ PS Hleralchy BEE Relation UtiIity GeomRep A Labor MechProp Oper Exposure partTT Sk illLevel ToolingCost Estimator I ToollngTT Socharis I Refiner l Compression Molder Selector I ilamentWinding lnjectionMoldlng TM matSel (“mum i7 5 2 i .3" 2 3 ” opermionSelector selectionBooster \l llL Id Figure 31. PSH of SocharisKB 144 S-Force treats a macroexpansion as a network with distributed control where every node is being invoked as soon as the system reaches the node’s layer of the network. However, the node does testing the self-applicability through the mechanism of port managers. Macroexpansion gives an access to high-level information flow in an l-KBS, the level where the information is being treated as a monolithic slug of matter passing through the device’s (l-KBSs) Functional Model. opemimSelecmr Number- 0 W PS:'Opemton_Selector' Ser opaumSelecror Number to l j—— ! Socharis Number- 0 m By PS:'materfalTechnology' Set matSelNumber to l }— —~[Ref'mer Number- ojo—-[ By Definition ot'Boouer' Ser reiecr'rarBooerer Numberwl je—j selectimBooster- o k4 —b[ ComprerumMoum; Number fl By ”z'Comm Momm' Set CornuusionMold'n' Number tot }—-— —o{ FilunemWinding Number - o }——e{ By rs: 'FtlamemWinding' Set FilamentWinding Number m J— fljecumuomm. Number - o }——b{ By PS: ‘lnjectionMolding’ Set lnjectionMoldin; Number to I }-—— -O{ LayupNumbet-O} {Byl’sruyup'SetuyupNumberlol }—— -u[ Rennlnfision Number - 0} :1I By PS: 'Res‘mlnfusim' Ser Bermmnuiou Number g}———I @ {syn-Rm'wnmmmbermk— [ By PS 'GeometricalRepelmbiliry' Se! SeornRep Number to I ]¢———L6eumnep Number - ojm [ByPS’Labor'SetlaborNumbertolJlt {LaborNumber-olo- [By PS 'Meermicrlpropenier' Set mechPropenies NumberfiH mechProperties Number - 0 Ice [Byrs 'OpenrorJarpoeue' SetOperExponue Numbem I [o————{ Opetfixpoaue Number-o 1‘1qu Maw-” [Byrsm_1unmm_ruue'5er pem'rNumbemt 1]: purrrNumber-o [ By PS ‘SkilLLevel’ Set suumel Number to l 1‘: Eminent Number- 0 H [ By rs ‘ToolinLCost' Set ToolingCorr Number to If J] ToolingCost Number - o k [ By PS ”Toolingwume' serToounm Numbermt lo——[ ToolinflTNumber- 0 Ice Figure 32. Macroexpansion of SocharisKB 7.3. Information-Processing Model of Fla-Designed Socharis In spite of the telltale nature of the macroexpansion, it does not show all the information necessary for understanding the problem-solving behavior of Re- SocharisKB. Information-Processing Layer is specifically designed to show how information is used and processed by every node of the functional model 145 therefore exposing the problem-solving behavior of an l-KBS. Port managers are used to access the Information-Processing Model. Through the mechanism of port managers, the designer and the user can access individual nodes, their preconditions, mappings, and specific control. Organization of port managers for operationSelector, RTM, and Labor (Appendix B) nodes of PSH could illustrate three distinctive examples of control structures that are used in Socharis. Port manager for operationSelector indicates input and output variables of the node as well as existential conditions and default values. This port manager does not impose any mappings and dynamic control. That means that this node will activate the correspondent problem-solver if the existential predicate is satisfied. This node is directly and unconditionally mapped to Booster node that makes it an example of the Rigid Control architecture where the communication channels as well as the order of execution are being defined before the system has run. If we look at the RTM node, then besides the information about the input/output variables and mapping we can see that the node is being controlled by that variable rthoostCtrl which is mapped from boosterResult. rthoostCtrl has a type of HC control, which tells us that the node will be activated when the value of boosterResult will contain value “Resin Transfer Molding’ designated in control field of the rthoostCtrl. The similar control structure could be found at every node responsible for running individual technology refiners, which directly maps to the domain-derived strategy 146 for identifying perspective technologies. On the other hand, the problem-solving architecture of the part of Re-SocharisKB responsible for technologies’ instantiations is an example of the blackboard architecture. Blackboard is being modeled viabroadcasting variables’ values through the communication channels. Each refiner node (a knowledge source in blackboard terms) filters the necessary values through the mapping and activates the respective problem-solver if the value of the control variable triggers it. Macroexpansion of Socharis does not show that the nodes responsible for the estimation of a particular merit have to be executed as many times as a number of alternatives generated by Re-SocharisKB. However, if we take a look at the Information-Processing Model of SocharisKB (Appendix B) at one of the estimator nodes (e.g. Labor) we notice six control variables, each responsible for manipulating the node’s activation in case of a particular problem-solving context. Lets’ take a closer look at the control variable RTMCtrl. This variable is being mapped from the RTM Port from the RTMResult output variable and contains the result (likely to be multiple result) of the RTM refiner. In the case when the control is being handed to this node by the RTM node, the Labor node effects the mapping of the variables using RTMPort@1 mapping and iterates the Labor node for all values of the RTMResult. This is a clear example of Semi-Rigid Control Architecture, where one defines the communication channels but activation of the node and number of node’s iteration are determined only during the run time. 147 The above instances demonstrated the ability of the S-Force to re—produce three different kinds of control architectures (Section 3.1.1) using mechanism of dynamic control provided by port managers within the Information-Processing Model. 7. 4. Ontology, User Interface, Pre-, and Post-processing S-Force does not cover problems associated with the development of domain ontology, user interface, and algorithmic pre- and post-processing. The development of domain ontology in every particular case is a process where the KBS developer might use a number of available shells (e.g. Ontolingua server tool (Fikes 1997), ProtégéWin (Eriksson, Fergerson et al. 1999)) and then parse the result in to the knowledge structure convenient for building l-KBS. For Socharis, we developed a Manufacturing Ontology Editor (Martinez, Lukibanov et al. 1998; Martinez, Lukibanov et al. 1999) that allowed creating and modifying ontology of manufacturing with polymer composite materials. This manufacturing ontology is a four-level deep class-subclass hierarchy (Category -) Class -) Attribute -) Value) that describes a part as well as manufacturing technology used to produce it. Alternatively, I used ProtégéWin tool to create a similar ontology and output it into the balanced parenthesis list that could be easily parsed to re-create an existing ontology. However, ProtégéWin goes one step further by allowing creating interfaces that help produce instances using the developed ontology. These instances then can be sent to an external application for the processing. Unfortunately, as recognized by the team of creators of ProtégéWin, 148 development of a good interface is not a problem that could be undertaken by a general—purpose tool. The interfaces, generated by ProtégéWin are fair for the development purposes; however, they are totally unacceptable for the end-user. Similar reasons motivated my research to forego features of S-Force that would allow developing the end-user interface for a front-end application and concentrate on the development of an interface suitable for the developmental purposes. A particular domain— and application-dependent user interface can be developed in a Smalltalk environment using back-end of the S-Force that contains a list of pointers to all variables participating in the problem-solving process. It is also relatively straightforward to write CORBA or ActiveX interface definitions for the back—end of a developed l-KBS to use it as a server accessible by external applications. Algorithmic pre— and post-processing in a KBS are usually operations that prepare input data for the l-KBS and transforming the output data for user’s understanding. If some of these procedures are knowledge intensive they can be imported as parts of the l-KBS. However, for the most part of these procedures are highly domain, application, and user dependent hence, similar to end user interface and are left out of the scope of the described research. 7.5. Discussion Chapters 6 and 7 demonstrated the possibility of implementation of l-KBS using the framework that supports the described approach. The approach is based on the Function-Based Reasoning theory, augmented with new functional 149 ontology and addition of the Information-Processing layer that allows not only explicit assigning of input and output information for every node of Functional Model but also defining mapping, advanced preconditions, default values, and dynamic control. Section 7.3 demonstrated that the problem-solving architecture of Re- SocharisKB leverages Rigid Control, Flexible Control, and Semi-Rigid Control architectures at different points of a problem-solving process depending on the available information, which allows close fitting of the l-KBS problem-solving architecture to the domain engineer problem-solving strategy and tactics. 150 8. CONCLUSION This dissertation addresses two major problem areas consequently divided into the number of sub-goals: 1. In the knowledge-based systems area (KBS): development of methodology and implementing the supporting software framework for constructing integrated knowledge—based systems. KBS-1. Augmentation of the Function-Based Reasoning methodology that allows functional decomposition of a real world problem using as building blocks a limited set of types of unitary problem-solvers. KBS-2. Addition of an Information-Processing layer to the functional modeling methodology, which enables an explicit assignment of information and control flow through the Functional Model. KBS-3. Addition of the capability of describing dynamic device control over the parts of the Functional Model of the l-KBS, therefore enabling implementation of arbitrary distributed control structures and problem-solving units within the l-KBS. KBS-4. The development of a shell which supports building l-KBSs in the described framework. 2. In the area of composite materials (CMD): re-design of the knowledge-based core of the system Socharis whose goal was to generate a family of applicable conceptual manufacturing plans for assemblies made of polymer composite materials. 151 CMD—1. Possibility of on-the-fly change in the system’s architecture, the architecture of its components, and the knowledge content. Re—designed in the developed shell Socharis will provide graphical interfaces to examine every part of the system and to modify them if necessary. Modification cannot only affect the knowledge encoded in the system, but also the control flow that governs the order of the problem-solvers’ activation. CMD—2. Explicit definition of the information and control flow between the components of the system that lets the user to understand the problem- solving strategy of Socharis. This, in turn, may be used as an educational instrument for teaching manufacturing in polymer composites. This chapter reports on the accomplishments and the contribution of the dissertation research specifically covering the listed above sub-goals. 8. 1. Contributions to the Kno Madge-Based Systems Field 8.1.1. Preamble The major KBS goal of this dissertation research was to develop a methodology for constructing integrated knowledge-based systems. The foundation of the proposed approach is the Function-Based Reasoning theory. A number of qualities of the FR methodology such as explicit causal network, hierarchical device decomposition, and the ability to arbitrary vary the level of granularity of the decomposition prompted this researcher to consider it as the methodology for description of the integrated problem-solving architecture. In addition to that, application of the FR techniques to component-based software engineering described in (Liver and Allemang 1995) justified the use of this 152 methodology to describe integrated knowledge-based systems However, the function-based reasoning theory required certain modifications to accommodate the specifics of the modeled subject: an integrated knowledge based system. The main obstacles that prohibit direct application of the FR methodology to decomposition and modeling l-KBSs could be listed as follows (Section 3.2): o The lack of an adequate ontology capable of describing the functionality of problem-solving units. 0 Inability to distinguish between different parts of the substance that is being passed through the functional model, i.e. treating it as inseparable slug of matter. . Weakness of the precondition clause that made it very difficult to state complex conditions on the activation of parts of the functional model, which adds to the absence of complex control structures within the functional model. The additions to the current FR framework which have been proposed in this dissertation augment traditional FR and particularly to its implementation in the Intelligent Systems Laboratory’s legacy software package attacks these issues by: . Introducing changes to the functional ontology, including functional description of bottom-level devices/problem-solvers (Section 3.2.1) 0 Adding the notion of port managers that allow description of the information- processing layer that directs information and control flow in an l-KBS, and (Section 3.2.2) 153 0 Using port managers as the distributed control units that expand the notion of pre-condition in the traditional FR (Section 3.2.2) These augmentations allow using the FR techniques to describe l-KBS emphasizing task-subtask decomposition and the function of each separate or integrated component of the functional model. Below I summarize the specific accomplishments in the areas listed above. 8.1.2. Functional Ontology The modification to the traditional functional ontology (Section 3.2.1) includes description of functionality of GT-based problem-solving types. This ontology is best leveraged when the designer attempts to approach a new problem, which does not have a clear task - sub-task decomposition. In this case, the functional ontology guides the designer in identifying the role of subordinate units as one of the available problem-solving types. Moreover, it provides the designer with predetermined configuration of input and output data, specific for each type of problem-solver. This affects the process of building I- KBS since types of dynamic controls explicitly depend on the type and structure of this information. The result of multiple routine designer is a collection of sets of parameters that would satisfy the described in the inputs requirements the reasonable operation that could be performed on this result is consecutive look- up. On the other hand, the result of hierarchical classifier is the list of predetermined names with correspondent confidence value: “matched”, “neutral”, “against”, etc. The reasonable operation on this rather output structure is to 154 compare it with specified a priori test expression. Therefore, the structure of the available information may hint the KBS designer to choose one problem—solving unit over the other. In the-case of explicit or known task breakdown, the functional ontology of problem solving does not play its guiding role in task-decomposition process. In turn the designer is faced with the task of finding an available off-the-shelf problem-solving unit capable of tackling each identified sub-task. This problem spurs a challenging branch in the research in the theoretical and practical FR: a problem of concise and sufficient definition of a device and its functionality. Such definition or a template should enable automatic or semiautomatic retrieval of a device from the library of devices. The research toward creating such a universal template for a device description is currently undenivay in Stanford University‘s Knowledge Systems Laboratory and Ohio State University’s Laboratory for Artificial Intelligence Research. 8.1.3. Information-Processing Layer and Port Managers The most important innovation in the research reported is the introduction of an information—processing layer to the functional model (Section 3.2.2). This layer allows treating information flowing through the functional model as a flow of divisible streams of data and control, rather than as an inseparable slug of substance: a representation common for the traditional FR approach. Information-processing layer is accessible to the l-KBS developer through the mechanism of port managers, introduced in Section 3.2.2. Port managers govern the inputs and outputs of every device/problem-solver in the functional 155 model. They are able to perform testing of preconditions, checking assertions, assigning default values to the ports (input and output variables), map ports form one device to another, control device’s activation, etc. Using port managers, information flow through the functional model could be separated, unified, mapped from one module to another, and re-directed. Association of port managers with every device/problem-solver of the functional model allows associating of distributed control units with every part of the functional model. These control units enhance the functionality of their predecessors - precondition clauses - but also enable the development architectures with complex control structures including iteration and boosting. 8.1.4. S-Forcg_a_Shell for Develoging l-KBSs Following the proposed changes to the FR framework, the shell for constructing l-KBSs - S-Force (Chapters 6 and 7) — was implemented on the basis of legacy software package (GT ITS) suitable for the development of stand- alone or hard-wired GT-based problem-solvers. The legacy of GT ITS was the main reason for using the GT-based problem-solvers as base-line problem- solving units. Another consideration in favor of exploiting GT—based problem- solvers was the fact that they have been successfully applied to the development of the number of KBSs in the Intelligent Systems Laboratory at Michigan State University over the last decade. It is important to understand that in spite of use of GT-Based problem- solvers in S-Force, the methodology developed in this dissertation does not impose any restriction on the type of the problem-solving modules that serve as 156 basic building blocks. The main criterion is to be able to look at the problem- solving unit as at a black box with clearly identifiable input, output, and functionality. S-Force provides the developer with the graphical environment that allows on the fly designing and building l-KBSs by defining and systematically describing three layers of an l-KBS: the Problem-Solving Hierarchy, the Functional Model, and the Information-Processing Model (Chapter 6). Development of an l-KBS is finished when each leaf of the Problem-Solving Hierarchy is associated with a specific problem-solving unit. S-Force allows re- use previously built in the GT ITS framework units as parts of an l-KBS as well as supporting the design of the problem-solving units from scratch. 8.1.5. Practical Application of S-Force The practicality of S-Force was studied on several examples including re- designing knowledge-based core of Socharis system (Chapter 7 Appendix B) and building of an exemplary tutorial system (Chapter 6, Appendix A). S-Force’s features are proved adequate for designing and modeling integrated knowledge- based systems. In fact, it took approximately four hours to re-design KBS core of Socharis consisted of thirty cooperating entities, if all problem-solving units were available in advance. S-Force gives access to the knowledge level architecture of l-KBSs designed in it by the means of graphical user interfaces that disclose every part of the problem-solving architecture, functionality and internal structure of the constituent parts of an I-KBS, and an l-KBSs information-processing layer. 157 8.1.6. Summry an4d Venues of Future Research There are some implementation-level shortcomings of S—Force that should be addressed in future research. Current implementation of S-Force does not take advantage of possibility to distribute the problem-solving modules across the network. However, it is possible to locate modules on the different machines and call them asynchronously using one of available protocols and broker architectures. One thing that has to be kept in mind is the synchronization of results of multiple problem-solvers working on the same problem. One of the features of port managers unexplored in the current implementation is the possibility to post-process results of the run of the node. The addition of the post-processing capability can considerably increase the power of the shell to develop more complex problem-solving architectures. To summarize the features and the capabilities of the reported in this dissertation research towards developing methodology and the tool for constricting l-KBSs Table 8 below compares it with the existing methodologies and shells for building l-KBSs. The comparison is done along the lines presented in the Section 2.2.5 that underscores the explicitness of the knowledge level architecture, implemented control strategies, and the existence of the shell supporting the methodology. 158 Explicity of Global Local Ability to handle Shell KLA (1 - 5) control control multiple control strategy strategy structures BBf, BBK 1 FC SRC No Yes PROTEGE-ll 3 FC All Somewhat Somewhat (programming required) Generic Task 5 RC RC No Yes Toolset (programming is needed) TIPS 4 SRC RC No No GT SOAR 3 RC SRC No No CommonKADS 5 SRC RC Some Several VITAL 5 RC, some RC No Yes SRC CoMoMAS FC SRC No No Conventional FR SRC RC No Yes Augmented FR RC, SRC, RC, SRC, Yes Yes S-Foroo PC PC Table 8. Comparison of the S-Force with other methodologies and shells. The above discussion leads to the conclusion that the goals KBS-1 through KBS-4 were achieved in this dissertation. opened new research paths that could be investigated in the future: a Development of the device/problem-solver definition template However, the research - Augmentation S-Force to allow development and modeling distributed problem-solving architectures - Improvement of port-manager’s functionality with the addition of post- processing. 159 8.2. Contributions to the Application Domain Redesigning the knowledge-based core of Socharis using S-Force accomplished the stated in the Introduction to the dissertation application domain goals CMD—1 - CMD-2 by enabling the direct access to the control structures governing problem-solvers’ activation process. These control structures were previously hidden in the Smalltalk code that disallowed effortless alteration and augmentation of Socharis. Use of S-Force enabled the designer to directly access the decomposition of the problem of the conceptual manufacturing planning as it is perceived be a domain specialist. The major benefit of a re- designed system is that the control and information flows through a problem- solving process and are directly exposed to the designer through the graphical user interface. Such open architecture enables the designer making changes in the problem-solving architecture in the case of necessity to adapt future versions of Socharis to new deployment sites. Another important contribution of work on Socharis and re-designed Socharis in the application domain area is the hypothesis introduced in (Lukibanov, Martinez et. al.. 2000), which asserts that a high-level problem- solving architecture developed for Socharis is a high-level problem-solving architecture of the conceptual process planning task in general. Given this, the problem-solving skeleton of the redesigned Socharis can serve as a backbone for the process-planning intelligent systems in domains others than polymer composite materials. It would be challenging and engaging to take on the problem of manufacturing process planning in the area of metal- or woodworking 160 using the-Socharis’s problem-solving architecture implemented in S-Force as a starting point. 8. 3. Concluding Remarks By taking the hypothesis introduced in (Lukibanov, Martinez et. al.. 2000) - that supposes that problem-solving architecture of Socharis is, in fact, the problem-solving architecture of the conceptual manufacturing planning - one step further it is reasonable to suggest that there exists a number of problem- solving architectures commonly used in the problem-solving activity. The PSMs of Second-Generation Knowledge-Based Systems (Section 3.2) serve as templates for building solutions for homogeneous tasks, tasks that require a single method. In contrast, integrated problem-solving architectures can be used to approach heterogeneous problems that are impossible to solve by application of a single problem-solving method but rather by their combinations. The challenge is in identifying such architectures. Extracting and categorizing problem-solving architectures could be done only after analyses of a great number of different tasks and approaches or by generalizing on a successful implementation in a particular area. One of the sources where such an analysis is possible is the Domain Specific Software Architectures (DSSA) research (Mettala 1992) (Section 3.4.4). Five-year long DARPA sponsored research was aimed to identify common software architecture in six different areas: 1. Avionics Navigation 2. Guidance and Flight Director 161 3. Command and Control 4. Distributed Intelligent Control and Management (DICAM) for Vehicle Management 5. Intelligent Guidance, Navigation and Control 9’ Hybrid Control, and Prototyping Technology Research was distributed among several contractors: IBM Federal Sector Division, GTE Federal Systems, Tecknowledge Federal Systems, Honeywell Systems and Research Center, ORA Corporation, and TPW. This research resulted in the set of methodic and tools that defined specification, design, and validation of software systems specific for each domain. One the accomplishments of the DSSA project was the conclusion that mature software architecture should possess three basic elements: 0 well-defined notation for capturing architectures o well-defined methods for producing and analyzing formal models from specification, captured in notation . a well-defined method for producing implementation from a specification captured in the notation. However, no study was performed to identify similarity(s) between the developed software architectures and processes. The reason for this is that at that time, the researchers lacked the necessary methodology to describe the software architecture and processes in the unified way. Nowadays, Rational Unified Process (RUP) developed as a result of research in Capability Maturity Model, Personal Software Process, and Object Modeling Techniques can help in 162 capturing organizational flow and architectural details. Analyzing RUP models, it might be possible to recognize similarities in the overall organizational process as well as software architecture. However, knowledge-intensive processing is beyond the RUP covered area since it does not support knowledge modeling techniques. The information presented in this dissertation methodology provides means to model such knowledge-intensive tasks by describing problem-solving architectures that could be compared along three axis: problem decomposition, functional decomposition, and information processing. This feature enables comparison between a difference modeled in S-Force systems. Such an analysis followed by generalization could lead to definition of a number of useful problem-solving architectures that would serve as backbone for the next generation of knowledge-based systems consisting of multiple cooperating entities and featuring accessible knowledge level. 163 APPENDICES 164 KNOWLEDGE STRUCTURE OF SOCHARIS‘ Device: Example Socharis APPENDIX A Function: Example Socharis Fn Beahvior: Example Socharis Beh Port Manager: Example SocharisPort All variables: Example Socharis Number input output Example Socharis Result output Technolgqy Selector Number input Fiber_Architecture input size input Wall_Thickness input Aspect_Ratio input Shape input partMaterial input Layup Refiner Number input Tolerances input SurfaceOuality input GeometricalComplexity input functional requirements input Refiner Number input Layup Refiner Number input RTM Refiner Number input Production input Tooling Cost Estimator Number input Part TT Estimator Number input fiberList input Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: Controls: 165 Device: Estimator Function: EstimatorF Beahvior: EstimatorB Port Manager: EstimatorPort All variables: Estimator Number input output EstimatorResult output depth input ToolingCost Estimator Number input Part 11' Estimator Number input Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: Example SocharisPorth Estimator Number ? EstimatorResult ’7 depth Wall_Thickness Controls: 166 Device: Refiner Function: Refinean Beahvior: RefinerBh Port Manager: RefinerPort All variables: Refiner Number input output RefinerResult output Tolerances input SurfaceQuality input size input resinList input Production ingit GeometricalComplexity input Fiber_Architecture input RTM Refiner Number input dgath input functional requirements input Layup Refiner Number mut fiberList input Qualitative predicates: Quantitative predicates: Existential predicates: Production ? resinList ? Fiber_ Architecture * depth * Refiner Number ? GeometricalComplexity * functional requirements * Layup Refiner Number ? Tolerances * SurfaceQuality * RTM Refiner Number ? size * Default values: Mappings: Example SocharisPort@1 Refiner Number ? RefinerResult ? Tolerances Tolerances SurfaceQuality SurfaceQuality size size resinList partMaterial Production Production 167 GeometricalComplexity GeometricalComplexity F iber_Architecture F iber LArchitecture RTM Refiner Number 9 depth Wall_Thickness functional requirements functional requirements Layup Refiner Number ? Controls: 168 Device: Technology Selector Function: SelectTechnology Beahvior: stBeh Port Manager: Technology SelectorPort All variables: Tech Selector Number Ratio Fiber Architecture erial 8 size Wall Thickness TSResult Qualitative predicates: partMaterial ~= unknown Shape ~= unknown Quantitative predicates: Existential predicates: partMaterial Walljhickness Aspect_Ratio Shape TechnologSelector Number Fiber_Architecture fi '00 I t I' I size Default values: Mappings: Example SocharisPort@1 Technology Selector Number ? Aspect_Ratio Aspect_Ratio FibertArchitecture Fiber_Architecture partMaterial partMaterial Shape Shape size size Wall_Thickness Wall_Thickness TSResult ’? Controls: 169 Device: Part TT Estimator Function: Estimate PTT Beahvior: epttBeh Port Manager: Part 11' EstimatorPort All variables: Part 1T Estimator Number CMtem curi FWtem re lMtem re manTechList Part turnaround time resin resinList RTMHeati method size Wall Thickness La Ctrl RTM Ctrl Result Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: Layup RefinerPort@1\ Part TT Estimator Number 7 CMtemperature ? curing type curing type FWtemperature ? lMtemperature 7 manTechList manTechList Part turnaround time ? resin prepreg/wet resin prepreglwet resinList resinList RTMHeating method ? size size Wall_Thickness depth ptte Result ? ptte Layup Ctrl Layup Refiner Result ptte RTM Ctrl 9 EstimatorPort@1 Part TT Estimator Number ? CMtemperature ? curing type ? 170 FWtem peratu re 7 lMtemperature ? manTechList ? Part turnaround time ? resin preprenget ? resinList ? RTMHeatirgmethod ? size ’? Wall_Thickness depth ptte Result ? ptte Layup Ctrl ? ptte RTM Ctrl ? RTM RefinerPort@l Part 1'I' Estimator Number ? CMtemperature ? curing type CurinLtype FWtemperature ? lMtemperature ? manTechList manTechList Part turnaround time ? resin prepreg/wet ? resinList resinList RTM Heatingmethod Heatiqu method size size Wall_Thickness ? ptte Result 7 ptte Layup Ctrl ? ptte RTM Ctrl RTM RefinerResult Controls: ptte Layup Ctrl type rdlmutControl control name Ltte Layup Ctrl control Layup Refiner Result ptte RTM Ctrl type rdlnputControl control name ptte RTM Ctrl control RTM RefinerResult 171 Device: Tooling Cost Estimator Function: Estimate Toolig Cost Beahvior: etcBeh Port Tooling Cost EstimatorPort All variables: Tooling Cost Estimator Number input output manTechList input material cost Tool complexity Tooling cost toolinflst input tce Layup Ctrl input tce RTm Ctrl input tce Result output Qualitative predicates: toolingList ~= unknown Quantitative predicates: Existential predicates: manTechList tce RTm Ctrl ToolinLCost Estimator Number tce Layup Ctrl toolingList fieOeQeQI Default values: Mappings: Layup RefinerPort@l TooanCost Estimator Number I) manTechList manTechList material cost 9 Tool complexity Tool complexity Tooligqcost I, toolingList tce Result toolingList 9 tce Layup Ctrl tce RTm Ctrl Layup Refiner Result 9 RTM RefinerPort@l ToolingCost Estimator Number ? manTechList manTechList material cost ? Tool complexity Tool complexity Toolig cost ? toolingList ToolingMaterial tce Result ? toe Layup Ctrl ? tce RTm Ctrl RTM RefinerResult 172 Controls: tce RTm Ctrl type rdlnputControI control name tce RTm Ctrl control RTM RefinerResult tce Layup Ctrl tYPe rdlnputControI control name tce Layup Ctrl control Layup Refiner Result 173 Device: Layup Refiner Function: Refine Layup Beahvior: rlBeh Port Manager: Layup RefinerPort All variables: La R Number La Refiner Result La Refiner Ctrl curi fiberList functional irements GeometricalCom labor resin resinList size SurfaceQual tern re Tolerances Tool com tooli List manTechList Qualitative predicates: Quantitative predicates: Existential predicates: resinList depth Layup Refiner Ctrl functional requirements Tolerances SurfaceQuality GeometricalComplexity production fiberList Layup Refiner Number size egeeeeeagee Default values: [ resinList Mappings: Technology SelectorPort@1 I DGEBA 174 Refiner Number 7 Refiner Result ? Refiner Ctrl TSResult curi ? ’? fiberList 7 functional irements ? GeometricalCom ? labor ? ri ? re ? ? resin ? resinList ? runS ? size ? SurfaceQual ? tem re ? Tolerances ? Tool com ? tooli List ? manTechList ? RefinerPort@l Layup Refiner Number ? Layup Refiner Result ? Layup Refiner Ctrl ? curing type ? depth ? fiberList fiberList functional requirements functional requirements GeometricalComplexity GeometricalComplexity labor ? postcurirm ? pressure ? production Production resin prepreglwet ? resinList resinList runSystem ? size size SurfaceQuality SurfaceQuality temperature ? Tolerances Tolerances Tool complexity ? toolingList ? 175 I manTechList T? J Controls: Layup Refiner Ctrl type hclnputControI control name Layup Refiner Ctrl output . - manTechList control %Layup 176 Device: RTM Refiner Function: Refine RTM Beahvior: rrtheh Port Manager: RTM RefinerPort All variables: RTM Refiner Number RTM RefinerResult RTM Refiner Ctrl Curi tern re Curi time Curi FiberFormi Fiber Architecture GeometricalCom Heati method labor Postcu ired Production resinList runS size SurfaceQual Tolerances Tool com Tooli rial manTechList Qualitative predicates: Quantitative predicates: Existential predicates: RTM Refiner Ctrl RTM Refiner Number size Tolerances Production resinList SurfaceQuality GeometricalComplexity tans.»e.g.g Fiber_Architecture Default values: Mappings: TechnologLSelectorPort@1 RTM Refiner Number ? RTM RefinerResult ? RTM Refiner Ctrl TSResult 177 Curing temperature Curing time Cu ri nflpe FiberFormingethod Fiber_Architecture GeometricalComplexity Heating method labor PostcuripgRequired Production resinList runSystem size Tool complexity ToolingMaterial 'Q'QQ-Q'Q'Q'Q-QNJ-Q-Q-Q'0'0'0 RefinerPort@l RTM Refiner Number ? RTM RefinerResult ? RTM Refiner Ctrl ? Curing temperature ? Curing time ? Curing type ? FiberFormingMethod ? Fiber_Architecture Fiber_Architecture GeometricalComplexity GeometricalComlexity Heatimethod ? labor ? Postcuring Rewired ? Production Production resinList resinList runSystem ? size size SurfaceQuality SurfaceQuality Tolerances Tolerances Tool complexim ? ToolingMaterial ? Controls: RTM Refiner Ctrl type hclnputControI control name RTM Refiner Ctrl output manTechList control %RTM 178 APPENDIX B KNOWLEDGE STRUCTURE OF RE-ENGINEERED SOCI'IARIS Device: Socharis Function: Socharian Behavior: Socharith Port Manager: SocharisPort All variables: Socharis Number input output socharisResult output Selector Number input operationSelector Number input Aspect_Ratio input Fiber_Architecture input partMaterial input Shape input size input Wall_Thickness input matSel Number input GeometricalComplexity input production input Compression Molder Number input SurfaceQuality input Tolerances input Layup Number input fiberList imut functional requirements input RTM Number input Resin Infusion Number input FilamentWinding Number input inserts input Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: Controls: 179 Device: Estimator Function: Estimation Behavior: EstimatorBeh Port Manager: EstimatorPort All variables: Estimator Number input output estimatorResult output Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: Controls: 180 Device: Refiner Function: refinean Behavior: refinerBh Port Manager: RefinerPort All variables; Refiner Number input output refinerResult output GeometricalComplexity input production input Compression Molder Number input fiberArchList input resinList input SurfaceQuality irmut Tolerances input Layup Number input fiberList input depth size input functional requirements input RTM Number input Resin Infusion Number input FilamentWindirlgNumber input inserts input Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: SocharisPort@1 Refiner Number ? refinerResult ? GeometricalComplexity GeometricalComplexity production production Compression Molder Number ? fiberArchList Fiber_Architecture resinList partMaterial SurfaceQuality SurfaceQuality Tolerances Tolerances Layup Number 7 fiberList fiberList depth Wall_Thickness size size functional requirements functional requirements Controls: 181 Device: Selector Function: Selectoan Behavior: SelectorBh Port Manager: SelectorPort All variables: Selector Number selectorResult ector Number Ratio Fiber Architecture size Wall Thickness matSeI Number Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: SocharisPort@1 Selector Number selectorResult operationSelector Number Aspect_Ratio F iber_Architecture partMaterial Shape size Wall_Thickness matSel Number 'QQ-Q-Q-QND-G-Q-QND Controls: 182 Device: Geom Rep Function: ngun Behavior: grBeh Port Manager: Geom RepPort All variables: Geom Number GeometricalCom Geom R manTechList resin GeomR RTMCtrl cmCtrl imCtrl watrl riCtrl Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: LayupPort@1 GeomRep Number ? GeometricalComplexity GeometricalComplexity Geom_Rep ? manTechList manTechList resin prepreg/wet resin prepreg/wet Geom RepeatRslt ? IayupCtrl lyupRsIt RTMCtrl ? cmCtrl ? imCtrl ? watrI ? riCtrl ’? FilamentWindingPort@1 GeomRep Number ? GeometricalComplexity GeometricalComplexity Geom_Rep ? manTechList manTechList resin prepreg/wet ? GeomRepeatRslt 7 layupCtrl ? RTMCtrl ? cmCtrl ? 183 imCtrl ? watrl waesult riCtrl ? Compression MolderPort@1 GeomRep Number ? GeometricalComplexity GeometricalComplexity Geom_Rep ? manTechList manTechList resin prepreg/wet ? GeomRepeatRslt ? layupCtrl ? RTMCtrI ? cmCtrI cm Result imCtrI 7 watrl ? riCtrI ? RTMPort@1 GeomRep Number ? GeometricalComplexity GeometricalComplexity Geom_Rep ? manTechList manTechList resin prepreg/wet ? GeomRepeatRslt ? IayupCtrl ? RTMCtrl RTMResult cmCtrl ? imCtrl ? watrl ? riCtrI ? Resin lnfusionPort@1 GeomRep Number ? GeometricalComplexity GeometricalComplexity Geom_Rep ? manTechList manTechList resin preprpg/wet ? GeomRepeatRslt ? layupCtrl ? RTMCtrI ? cmCtrl ? imCtrI ? watrI ? riCtrl riResuIt InjectionMoIdiinort@1 GeomRep Number ? GeometricalComplexity GeometricalComplexity 184 GeompRep ? manTechList manTechList resin prepreg/wet ? GeomRepeatRslt ? layupCtrl ? RTMCtrl 9 cmCtrl ? imCtrl imResult watrI ? riCtrl ’7 Controls: imCtrl type rdlnputControl control name imCtrl control im Result cmCtrl type rdlnputControl control name cmCtrl control cm Result riCtrl type rdlnputControl control name riCtrl control manTechList RTMCtrI type rdlnputControl control name RTMCtrI control RTM Result layupCtrl type rdlnputControl control name layupCtrl control lyuflislt watrI type rdlnputControl control name watrl control waesult 185 Device: Labor Function: laboan Behavior: laborBeh Port Manager: LaborPort All variables: Labor Number labor Labor estimation manTechList l laborResult RTMCtrl cmCtrl imCtrl watrl riCtrI Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: LayupPort@1 Labor Number ? labor labor Labor estimation 7 manTechList manTechList layupCtrl IyupRslt laborResult RTMCtrI cmCtrl imCtrl watrl riCtrl FilamentWindingPort@1 Labor Number labor Labor estimation . manTechList IayupCtrl laborResult RTMCtrI cmCtrl imCtrl watrl riCtrI Q'Q-QQQ'O 3 o-ooo anTechList Result Qg-oro-o-o-o 186 Compression MolderPort@1 Labor Number ? labor labor Labor estimation ? manTechList manTechList layupCtrl ? laborResult ? RTMCtrI ? cmCtrI cmResult imCtrl ? watrI ? riCtrl ? RTMPort@1 Labor Number ? labor labor Labor estimation ? manTechList RTM Result layupCtrl ? laborResult ? RTMCtrl RTMResult cmCtrl ? imCtrI ? watrl 7 riCtrl ? Resin lnfusionPort@1 Labor Number ? labor labor Labor estimation ? manTechList manTechList layupCtrI ? laborResult ? RTMCtrl ? cmCtrl ? imCtrl ? watrl ? riCtrl riResult lnjectionMoldiinort@1 Labor Number ? labor ? Labor estimation ? manTechList manTechList layupCtrI ? laborResult ? RTMCtrI ? cmCtrl ? 187 imCtrI im Result watrI ? riCtrI ? Controls: cmCtrl type rdlnputControl control name cmCtrl control cm Result watrl type rdlnputControl control name watrl control waesuIt RTMCtrI type rdlnputControl control name RTMCtrl control RTMResult riCtrl type rdlnputControl control name riCtrl control riResult imCtrI type rdlnputControl control name imCtrl control imResult layupCtrl type rdlnputControl control name IayupCtrl control IyupRslt 188 Device: MechProp Function: mpFun Behavior: mpBeh Port Manager: MechPropPort All variables: MechP Number MachanicalP es manTechList resin mechP Result RTMCtrI imCtrl cmCtrI watrl riCtrl Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: lnjectionMoldinLPort@1 MechProp Number ? MachanicalProperties ’? manTechList manTechList resin prepreg/wet ? mechPropResult 7 IayupCtrl ? RTMCtrI ? imCtrl imResult cmCtrl ? watrl ? riCtrl ? FilamentWindingPort@1 MechProp Number ? MachanicalProperties ? manTechList manTechList resin prepreg/pet ? mechPropResult ? layupCtrI ? RTMCtrI ? imCtrl ? cmCtrI 7 watrl waesult riCtrl ? 189 Compression MolderPort@1 MechProp Number 7 MachanicalProperties 7 manTechList manTechList resin preprpg/wet 7 mechPropResult 7 layupCtrI 7 RTMCtrl 7 imCtrI 7 cmCtrl cmResult watrl 7 riCtrl 7 LayupPort@1 MechProp Number 7 MachanicalProperties 7 manTechList manTechList resin prepreg/wet resin prepreg/wet mechPropResult layupCtrI IyupRslt RTMCtrI 7 imCtrI 7 cmCtrl 7 watrl 7 riCtrl 7 RTMPort@1 MechProp Number 7 MachanicalProperties 7 manTechList manTechList resin prepreg/wet 7 mechPropResult 7 IayupCtrI 7 RTMCtrl RTMResult imCtrl 7 cmCtrl 7 watrl 7 riCtrl 7 Resin lnfusionPort@1 MechProp Number 7 MachanicalPrcmerties ? manTechList manTechList resin prepreglwet 7 mechPropResult 7 layupCtrl 7 RTMCtrl 7 imCtrl 7 190 cmCtrl 7 watrl 7 riCtrl riResult Controls: imCtrl type rdlnputControl control name imCtrl control imResult cmCtrl gpe rdlnputControl control name cmCtrl control cm Result RTMCtrl type rdlnputControl control name RTMCtrI control RTMResult IayupCtrI type rdlnputControl control name layupCtrl control lyuLRslt riCtrl ype rdlnputControl control name riCtrI control riResult watrl type rdlnputControl control name watrI control waesult 191 Device: OperExposure FuncfionzoeFun Behavior: oeBeh Port Manager: OperExposurePort All variables: Number Fiber fiberList manTechList Value resin resinList Solvents&Corrosives Toxins oeResult RTMCtrl cmCtrl imCtrl watrI riCtrl Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: LayupPort@1 OperExposure Number 7 Fiber 7 fiberList fiberList manTechList - manTechList OperatorExposeValue 7 resin prepregiwet resin prepreglwet resinList resinList Solvents&Corrosives 7 Toxins 7 oeResult 7 layupCtrl IyupRslt RTMCtrI 7 cmCtrl 7 imCtrI 7 watrl 7 riCtrl 7 FilamentWindingPort@1 I OperExposure Number I 7 J 192 Fiber fiberList manTechList go-o anTechList OperatorExposeValue resin prepregwet resinList Solvents&Corrosives Toxins oeResult layupCtrl RTMCtrl cmCtrl imCtrl watrI Result riCtrl .0 g .0 .0 .0 .0 .0 .0 .0 .0 .0 .0 Compression MolderPort@1 OperEiposure Number Fiber fiberList manTechList 3 ore-o anTechList OperatorExposeValue resin preprefivet resinList Solvents&Corrosives Toxins oeResult layupCtrl RTMCtrI cmCtrl mResuIt imCtrl watrl riCtrl 'Q-QNDO Q-Q-Q-QNJ'Q-Q-Q RTMPort@1 OperExp—dsure Number Fiber fiberList manTechList 3 o-o-o anTechList OperatorExposeValue resin prepreg/wet resinList SolventsaCorrosives Toxins oeResult IayupCtrl RTMCtrI :n-o-o-o-o-o-o-o TMResult 193 cmCtrI imCtrl watrl riCtrl Resin lnfusionPort@1 '0 '0 w) “‘2 OperExposure Number Fiber fiberList manTechList anTechList OperatorExposeValue resin prepreg/wet resinList SolventsaCorrosives Toxins oeResult IayupCtrl RTMCtrI cmCtrI imCtrI watrI 'QQ'QND-Q-O-QQ-Q'Q‘QB O-O-Q riCtrl riResult lnjectionMoIdinLPort@1 OperExposure Number Fiber fiberList 9 7 I) manTechList manTechList OperatorExposeValue resin prepreg/pet resinList Solvents&Corrosives Toxins oeResult IayupCtrl I) I) I) 7 9 7 7 9 RTMCtrl cmCtrI imCtrl ? i watrl riCtrl m 7 7 RefinerPort@l OperExposure Number 7 Fiber ? fiberList fiberList manTechList I) OperatorExposeValue resin prepreglwet 9 9 194 resinList resinList Solvents&Corrosives 7 Toxins 7 oeResult 7 layupCtrI 7 RTMCtrl 7 cmCtrl 7 imCtrl 7 watrl 7 riCtrl 7 Controls: IayupCtrI type rdlnputControl control name layupCtrl control IyupRslt riCtrl type rdlnputControl control name riCtrl control riResult watrI type rdlnputControl control name watrl control waesult RTMCtrI type rdlnputControl control name RTMCtrI control RTM Result cmCtrI type rdlnputControl control name cmCtrl control cm Result imCtrI type rdlnputControl control name imCtrl control im Result 195 Device: partTT Function: partTTfn Behavior: partTTBeh Port Manager: partTTPort All variables: TT Number CMtem re curi FWtem re lMtem re Part turnaround time resin resinList RTMHeati size Wall Thickness manTechList Result method rthtrl imCtrl cmCtrl watrI riCtrI Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: LayupPort@1 partTT Number 7 CMtemperature 7 curing type curingtype FWtemperature 7 lMtemperature 7 Part turnaround time 7 resin prepreg/wet resin prepreg/yvet resinList resinList RTMHeating method 7 size size Wall_Thickness depth manTechList manTechList pttResult 7 lyupControl IyupRslt RTM Number 7 196 rthtrl imCtrl cmCtrl watrl riCtrl FilamentWindingPort@1 LartTT Number CMtemperature curingtype FWtemperature emperature lMtemperature 9'0 Part turnaround time resin prepreg/wet delivery system resinList resinList RTMHeating method ? size size Wall_Thickness I) manTechList manTechList pttResult lyupControl rthtrl imCtrl cmCtrl watrl Result riCtrl '0g‘°0°\)'\)-0-\3 Compression MolderPort@1 partTT Number s) CMtemperature F0- emperature curing type FWtemperature lMtemperature Part turnaround time resin preprenget resinList RTMHeatinmethod size Wall_Thickness manTechList 3 o-o-o-o-ooo-o-o-o anTechList pttResult lyupControl rthtrl imCtrl cmCtrl mResult watrl riCtrl '0 '0 0 w) '0 '0 '0 197 RTMPort@1 partTT Number CMtemperature curing type FWtemperature lMtemperature Part turnaround time resin preppeg/wet resinList RTMHeatinwethod I -o -o -o -o -o «a -o -o eatinwethod size Wall_Thickness manTechList 3 -o-o anTechList pttResult l upControl rthtrl :no-o ' TMResult imCtrl cmCtrl watrl riCtrl '0 '0 '0 “Q Resin lnfusionPort@1 partTT Number CMtemperature curing type 00-0 urinp type FWtemperature lMtemperature Part turnaround time resin preprenget resinList RTMHeatinwethod Q'O'Q-Q'Q-Q-s) size Wall_Thickness Wall_Thickness manTechList manTechList ttResuIt 7 I upControl rthtrI imCtrI cmCtrI watrl \DNJ-Q-O-Q riCtrl riResult Moldi TT Number CMtem re In P curi FWtem re lMtemperature temperature Part turnaround time 7 resin prepreg/yvet 7 resinList resinList RTMHeating method 7 size . size Wall_Thickness 7 manTechList manTechList pttResult 7 lyupControl 7 rthtrI 7 imCtrl imResult cmCtrl 7 watrl 7 riCtrl 7 RefinerPort@l artTT Number 7 CMtemperature 7 curipqptype 7 FWtemperature 7 lMtemperature 7 Part turnaround time 7 resin preprpq/wet 7 resinList 7 RTMHeatinmethod 7 size 7 Wall_Thickness depth manTechList 7 pttResult 7 lyupControl 7 rthtrl 7 imCtrl 7 cmCtrl 7 watrl 7 riCtrl 7 Controls: riCtrl type rdlnputControl control name riCtrl control riResult rthtrl type rdlnputControl control name rthtrl control RTMResult imCtrl 199 type rdlnputControl control name imCtrl control im Result watrl e rdlnputControl control name watrl control waesult l upControl type rdlnputControl control name lyupControl control IyupRslt cmCtrl type rdlnputControl control name cmCtrI control cm Result 200 ll“ Device: SkillLeveI Function: leun Behavior: slBeh Port Manager: SkiIlLevelPort All variables: SkilILeveI N mber manTechList runS Skill level isesult I RTMCtrI cmCm imCtrl watrI riCtrl Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: lnjectionMoldiinort©1 SkilILevel Number 7 manTechList manTechList runSystem 7 Skill level 7 isesult 7 IayupCtrl 7 9 9 RTMCtrl cmCM . imCtrI im Result watrl 7 riCtrl 7 FilamentWindingPort@1 SkillLevel Number 7 manTechList manTechList runSystem Skill level isesuIt layupCtrl RTMCtrl cmCtrl imCtrI watrl riCtrl Result '0g‘°0-0'0-J'~)-0-0 201 Compression MolderPort@1 SkillLeveI Number 7 manTechList manTechList runSystem 7 Skill level 7 isesult 7 layupCtrl 7 RTMCtrl 7 cmCtrI cm Result imCtrl 7 watrl 7 riCtrl 7 LayupPort@1 SkillLevel Number 7 manTechList manTechList runSystem 7 Skill level 7 isesult 7 layupCtrl IyupRslt RTMCtrI 7 cmCtrI 7 imCtrl 7 watrI 7 riCtrI 7 RTMPort@1 SkillLeveI Number 7 manTechList manTechList runSystem 7 Skill level 7 isesult 7 IayupCtrl 7 RTMCtrl RTM Result cmCtrI 7 imCtrI 7 watrl 7 riCtrl 7 Resin lnfusionPort@1 SkillLevel Number 7 manTechList manTechList runSystem 7 Skill level 7 isesult 7 layupCtrl 7 RTMCtrI 7 cmCtrl 7 202 imCtrl 7 watrl 7 riCtrl riResult Controls: RTMCtrl type rdlnputControl control name RTMCtrI control RTM Result cmCtrI type rdlnputControl control name cmCtrl control cm Result layupCtrl type rdlnputControl control name layupCtrl control IyupRslt imCtrl type rdlnputControl control name imCtrl control imResult riCtrl type rdlnputControl control name riCtrl control riResult watrl pipe rdlnputControl control name watrl control waesult 203 Device: ToolingCost Function: tooligCost Behavior: toolingCostBeh Port Manager: ToolingCostPort All variables: Tooli Number manTechList material cost Tool com Tooli cost tooli List too“ esuh RTMCtrI cmCtrl imCtrl watrl riCtrl Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: lnjectionMoldingPort@1 ToolingCost Number 7 manTechList manTechList material cost 7 Tool complexitL tool complexity Tooling cost 7 toolingList toolingList tooliantResult 7 layupCtrl 7 RTMCtrl 7 cmCtrl 7 imCtrl imResult watrl 7 riCtrI 7 FilamentWindingflart©1 ToolirgCost Number 7 manTechList manTechList material cost 7 Tool complexity 7 Toolipgpost 7 toolingList toolingList toolinLCostResuIt 7 204 | RTMCtrl cmCtrl imCtrl watrl riCtrl - Compression MolderPort@1 ToolinLCost Number 7 manTechList manTechList material cost 7 Tool complexitL Tool complexity Tooling cost 7 toolingList toolimList toolingCostResult 7 IayupCtrl 7 RTMCtrl 7 cmCtrl cm Result imCtrl 7 watrl 7 riCtrl 7 LayupPort@1 ToolingCost Number 7 manTechList manTechList material cost 7 Tool complexity Tool complexity Toolinpcost 7 toolingList toolingList toolirngostResult 7 layupCtrl IyupRslt RTMCtrl 7 cmCtrl 7 imCtrl 7 watrl 7 riCtrI 7 RTMPort@1 ToolingCost Number 7 manTechList manTechList material cost 7 Tool complexity Tool complexity Toolingcost 7 toolingList ToolingMaterial toolingCostResult 7 layupCtrI 7 RTMCtrl RTMResult cmCtrl 7 205 imCtrI 7 watrl 7 riCtrl 7 Resin lnfusionPort@1 ToolinLCost Number 7 manTechList manTechList material cost 7 Tool complexity Tool complexity Toolinflzost 7 toolingList toolingMaterial toolingCostResult 7 IayupCtrl 7 RTMCtrl 7 cmCtrl 7 imCtrl 7 watrI 7 riCtrI riResult Controls: watrl type rdlnputControl control name watrl control waesult riCtrl type rdlnputControl control name riCtrl control riResult RTMCtrl type rdlnputControl control name RTMCtrI control RTMResult layupCtrl type rdlnputControl control name layupCtrl control IyupRslt imCtrl type rdlnputControl control name imCtrl control imResult cmCtrI type rdlngltControl control name cmCtrl control cm Result 206 Device: ToolingT‘I’ Function: tttFn Behavior: tttBeh Port Manager: ToolingTTPort All variables: Tooli 11' Number GeometricalCom e size Tooli Turn Around Time tooli List toolinTTResult RTMCtrl cmCtrl riCtrI watrI imCtrl Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: InjectionMoldinLPort@1 ToolingT‘l‘ Number 7 GeometricalComplexity GeometricalComplexity size size Tooling Turn Around Time 7 toolingList toolingst toolinTTResult 7 lyupCtrl 7 RTMCtrl 7 cmcm 7 riCtrl 7 watrI 7 imCtrI imResult RefinerPo@ ToolingLT Number 7 GeometricalComplexity 7 size size Tooling Turn Around Time 7 toolingist 7 toolinTTResult 7 lyupCtrI 7 RTMCtrl 7 cmCtrI 7 207 riCtrl 7 watrl 7 imCtrl 7 FilamentWindingPort@1 ToolipgTT Number 7 GeometricalComplexity GeometricalComplexity size size ToolingTurn Around Time 7 toolingList toolingList toolinTTResult 7 lyupCtrI 7 RTMCtrI 7 cmCtrl 7 riCtrl 7 watrl waesult imCtrl 7 Compression MolderPort@1 ToolingTI’ Number 7 GeometricalComplexity GeometricalComplexity size 7 Toolipg Turn Around Time 7 toolingList toolingList toolinTTResult 7 lyupCtrI 7 RTMCtrI 7 cmCtrI cmResult riCtrl 7 watrl 7 imCtrl 7 LayupPort@1 ToolingTT Number 7 GeometricalComplexity GeometricalComplexity size size . Tooling Turn Around Time 7 toolinLList toMist toolinTTResult 7 IfllpCtl’l IyupRslt RTMCtrI 7 cmCtrl 7 riCtrl 7 watrl 7 imCtrl 7 RTMPort@1 ToolingTT Number 7 GeometricalComplexity GeometricalComplexity 208 size size Toolig Turn Around Time 7 toolingList Toolingaterial toolinTTResult 7 lyupCtrl 7 RTMCtrl RTM Result cmCtrl 7 riCtrl 7 watrl 7 imCtrl 7 Resin lnfusionPort@1 Toolinng' Number 7 GeometricalCorrpexity GeometricalComplexitL size size ToolinLTurn Around Time 7 toolingist toolingMaterial toolinTTResult 7 IyupCtrI 7 RTMCtrl 7 cmCtrl 7 riCtrl riResult watrl 7 imCtrl 7 Controls: cmCtrI type rdlnputControl control name cmCtrl control cm Result riCtrl type rdlnputControl control name riCtrl control riResult watrl type rdlnputControl control name watrl control waesult RTMCtrI type rdlnputControl control name RTMCtrI control RTMResult lyupCtrl type rdlnputControl control name lyupCtrl control IyupRslt imCtrl 209 tYPe rdlnputControl control name imCtrl control imResult 210 Device: Compression Molder Function: cmFunction Behavior: cmBehavior Port Manager: Compression MolderPort All variables: Com Molder Number fiberArchList GeometricalCom e labor re-ksi ction resinList te re Tool corn tooli List boosterl cm Result manTechList Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: selectionBoosterPort@1 Compression Molder Number 7 fiberArchList 7 GeometricalComplexity 7 labor 7 pressure-ksi 7 production 7 resinList 7 temperature 7 Tool complexity 7 toolingList 7 boosterlnputControI boosterResult RefinerPort@l Compression Molder Number 7 fiberArchList fiberArchList GeometricalComplexity GeometricalComplexity labor 7 pressure-ksi 7 production production resinList resinList temperature 7 Tool complexity 7 211 Ltoolingist l 7 J Controls: boosterlnputControl e hclnputControl control name boosterlnputControl output - manTechList control Compression Molding 212 Device: FilamentWinding Function: wan Behavior: aneh Port Manager: FilamentWindingPort All variables: FilamentWindi Number cure del' s m functional irements GeometricalCom ure resinList size tern re tooli List waesult fwBoosterCtrl manTechList Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: selectionBoosterPort@1 FilamentWindingNumber cure type delivery system functional requirements GeometricalComplexity pressure production resinList size temperature toolingList waesuIt 0 '0 '0 '0 '0 '0 '0 '0 “Q '0 '0 '0 fwBoosterCtrl boosterResult RefinerPort@1 FilamentWindinLNumber cure type delivery system 0-0-0 functional requirements functional requirements GeometricalComplexity GeometricalComplexity pressure 7 213 production production resinList resinList size size temperature 7 toolingist 7 waesult 7 fwBoosterCtrl 7 Controls: fwBoosterCtrl type hclnputControl control name fwBoosterCtrl output manTechList control Filament WindipL 214 Device: InjectionMolding Function: ian Behavior: imBeh Port Manager: lnjectionMoldingPort All variables: InjectionMolding Number input output GeometricalComplexipL input heated tool output inserts input pressure-ksi output roducflon input resinList input size input temperature output tool complexity output toolingList output im Result output imBoostingtrl input manTechList output Qualitative predicates: Quantitative predicates: Existential predicates: GeometricalComplexity size inserts InjectionMolding Number resinList production ear.0ararar Default values: Linserts Mappings: selectionBoosterPort@1 [none InjectionMolding Number GeometricalComplexity heated tool insens pressure-ksi production resinList size temperature tool complexity toolingist imResult Q'Q°Q°Q-Q°0°Q°Q°Q°O'Q°Q imBoostingCtrl boosterResult 215 RefinerPort@1 lnjectionMoldingNumber 7 GeometricalComplexity GeometricalComplexity heated tool 7 inserts inserts pressure-ksi. 7 roduction production resinList resinList size size temperature 7 tool complexity 7 toolingList 7 Controls: imBoostingCtrI pe hclnputControl control lnjpction Molding output manTechList 216 Device: Layup Function: LayupFn Behavior: LayupBeh Port Manager: LayupPort All variables: La Number curi fiberList functional irements GeometricalCom e labor ri ction resin resinList runS m size SurfaceQual tem re Tolerances Tool corn e tooli List Rslt manTechList Qualitative predicates: Quantitative predicates: Existential predicates: fiberList size depth Layup Number resinList GeometricalComplexity Tolerances functional requirements SurfaceQuality IyupBoostCtrl '00 C It i I: i It I O I‘ roducfion Default values: Mappings: selectionBoosterPort@1 LLayup Number 217 curi 7 7 fiberList 7 functional irements 7 GeometricalCom 7 labor 7 ri 7 ure 7 7 resin 7 resinList 7 runS 7 size 7 SurfaceQual 7 tem re 7 Tolerances 7 Tool com e 7 tooli List 7 boosterResult Rslt 7 manTechList 7 RefinerPort@l Layup Number 7 curingtype 7 depth depth fiberList fiberList functional requirements functional requirements GeometricalComplexity GeometricalComplexity labor 7 ostcuring 7 pressure 7 production production resirmrtaflegwet 7 resinList resinList runSystem 7 size size SurfaceQuality SurfaceQuality temperature 7 Tolerances Tolerances Tool complexity 7 toolinggst 7 lyupBoostCtrl 7 IyupRslt 7 manTechList 7 Controls: 218 l hcl control name | o manTechList control La 219 Device: Resin Infusion Function: riFn Behavior: riBeh Port Manager: Resin lnfusionPort All variables: Resin Infusion Number input output curimp/pe output fiberArchList input FiberFormingMethod output fiberList input functional requirements input GeometricalComplexity input labor output postcuring output pressure output production input resinList input runSystem size input SurfaceQuality input temperature output Tolerances input Tool complexity output toolingMaterial output Wall_Thickness input riBoosterCtrl input riResult output manTechList output Qualitative predicates: Quantitative predicates: Existential predicates: resinList * Wall_Thickness * functional requirements * Resin Infusion Number 7 riBoosterCtrl 7 fiberList " SurfaceQuality * production * fiberArchList * size * Tolerances * GeometricalComplexity * Default values: Mappings: 220 selectionBoosterPort@1 Resin Infusion Number Gurmtyne fiberArchList FiberFormingMethod fiberList functional requirements GeometricalComplexity labor ostcuring pressure roducfion resinList runSystem size SurfaceQuality temperature Tolerances Tool complexity toolingMaterial Wall_Thickness '0'00"0'0-0°\)'\)-0°\)-Q°\)'\)'Q'Q'Q-QNDNJ'Q'Q-Q'Q riBoosterCtrl oosterResult riResult manTechList RefinerPort@l Resin Infusion Number 7 curing type 7 fiberArchList fiberArchList FiberFormingMethod 7 fiberList fiberList functional requirements functional requirements GeometricalComplexity GeometricalComplexity labor 7 mstcurinL 7 pressure 7 production production resinList resinList runSystem 7 size size SurfaceQuality SurfaceQuality terpperature 7 Tolerances Tolerances Tool complexity 7 toolin Material 7 Wall_Thickness depth 221 riBoosterCtrl 7 riResult 7 manTechList 7 Controls: riBoosterCtrl type hclnputControl control name riBoosterCtrl output manTechList control Resin Infusion 222 Device: RTM Function: RTMFn Behavior: RTMBeh Port Manager: RTMPort All variables: RTM Number input output Curingtemperature output Curing time output Curipgptype output FiberFormingethod output Fiber_Architecture input GeometricalComplexity input Heatingmethod output labor output Postcuring Required output Production input resinList input runSystem size input SurfaceQuality input Tolerances input Tool complexity output ToolingMaterial output rthoostCtrl input RTMResult output manTechList output Qualitative predicates: Quantitative predicates: Existential predicates: Default values: Mappings: . selectionBoosterPort@1 RTM Number 7 Curingemperature 7 Cunpg time 7 CuriLCLtype ? FiberFormingMethod 7 Fiber_Architecture 7 GeometricalComplexity 7 Heatirngethod 7 labor 7 PostcurinLRequired 7 Production 7 resinList 7 runSystem 7 223 size SurfaceQualim Tolerances Tool complexity ToolingMaterial '0 '0 U' '0 '0 '0 w} W) rthoostCtrl oosterResult RTM Result manTechList RefinerPort@l RTM Number 7 Curing temperature 7 CurinLtime 7 Curing type 7 FiberFormiggMethod 7 Fiber_Architecture fiberArchList GeometricalComplexity GeometricalComplexity Heatipg method 7 labor 7 Postcuhpg Required 7 Production production resinList resinList runSystem 7 size size SurfaceQuality SurfaceQuality Tolerances Tolerances Tool complexity 7 ToolingMaterial 7 rthoostCtrl 7 RTMResult 7 manTechList 7 Controls: rthoostCtrl type hclnputControl control name rthoostCtrl output manTechList control Resin Transfer Moldin Device: matSel Function: matSean Behavior: matSelBh Port Manager: matSeIPort All variables: matSel Number input output resinList input matSelResult output Qualitative predicates: resinList ~= unknown Quantitative predicates: Existential predicates: resinList matSel Number 7 Default values: Mappings: SelectorPort@1 matSel Number 7 resinList partMaterial matSelResult 7 Controls: 225 Device: operationSelector Function: opSean Behavior: opSelBh Port Manager: operationSelectorPort All variables: nSelector Number Ratio Fiber Architecture al 8 size Wall Thickness Result Qualitative predicates: size ~= unknown Aspect_Ratio ~= unknown partMaterial ~= unknown Fiber_Architecture ~= unknown Shape ~= unknown Wall_Thickness ~= unknown Quantitative predicates: Existential predicates: size Fiber_Architecture Shape operationSelector Number partMaterial Wall_Thickness Aspect_Ratio It Ir .00 i i I Default values: Fiber_Architecture quasilsotropic Shape casting Aspect_Ratio medium size medium partMaterial DGEBA Wall_Thickness medium Mappings: Controls: 226 Device: selectionBooster Function: boostean Behavior: boosterBh Port Manager: selectionBoosterPort All variables: selectionBooster Number input output list1 input list2 input boosterResult output Qualitative predicates: Quantitative predicates: Existential predicates: selectionBooster Number list1 list2 Default values: Mappings: matSelPort@1 selectionBooster Number 7 list1 matSelResult list2 7 boosterResult 7 operationSelectorPort@1 selectionBooster Number 7 list1 7 list2 opSelResult boosterResult 7 Controls: 227 APPENDIX C MANUFACTURING ONTOLOGY REDESIGNED IN PROTEGE FRAMEWORK (defclass PartTechnology (is-a Root) (role concrete) (slot techname (type STRING) (create-accessor read-write» (slot tech-description ;+ (allowed-classes Technology) (type INSTANCE) (create-accessor read-write») (defclass Technology (is-a Root) (role abstract) (multislot tool-complexity ;+ (allowed-classes ToolComplexity) (type INSTANCE) (create-accessor read-write» (slot name (type STRING) (create-accessor read-write») (defclass ResinTransferMolding (is-a Technology) (role concrete) (multislot postcuring-required ;+ (allowed-classes Postcuring) (type INSTANCE) (create-accessor read-write» (multislot curing-temperature ;+ (allowed-classes Temperature) (type INSTANCE) (create-aocessor read-write» (multislot heating-method ;+ (allowed-classes HeatingMethod) (type INSTANCE) (create-accessor read-write» (multislot fiber-forming-method ;+ (allowed-classes FiberFormingMethod) (type INSTANCE) (create-accessor read-write» (multislot curing-time ;+ (allowed-classes CuringTime) (type INSTANCE) (create-accessor read-write») (defclass Sprayup (is-a Technology) (role concrete) (multislot labor ;+ (allowed-classes Labor) (type INSTANCE) (create-accessor read-write» (multislot cure-type ;+ (allowed-classes CureType) (type INSTANCE) (create-accessor read-write)» (defclass Extrusion (is-a Technology) (role concrete» (defclass Pultrusion (is-a Technology) (role concrete)) (defclass CompressionMolding (is-a Technology) (role concrete) (multislot pressure-ksi ;+ (allowed-classes PressureKSl) (type INSTANCE) (create-accessor read-write» (multislot labor ;+ (allowed-classes Labor) (type INSTANCE) (create-accessor read-write» (multislot temperature ;+ (allowed-classes Temperature) (type INSTANCE) (create-accessor read-write)» (defclass Layup (is-a Technology) (role concrete) (multislot pressure 229 ;+ (allowed-classes Pressure) (type INSTANCE) (create-accessor read-write» (multislot labor ;+ (allowed-classes Labor) _ (type INSTANCE) (create-accessor read-write» (multislot postcuring ;+ (allowed-classes Postcuring) (type INSTANCE) (create-accessor read-write» (multislot cure-type ;+ (allowed-classes CureType) (type INSTANCE) (create-accessor read-write» (multislot resin-prepreg-wet ;+ (allowed-classes ResinPrepregWet) (type INSTANCE) (create-accessor read-write» (multislot temperature ;+ (allowed-classes Temperature) (type INSTANCE) (create-accessor read-write») (defclass TechnologyMisc (is-a Root) (role abstract» (defclass CureType (is-a TechnologyMisc) (role concrete) (slot cure-type (allowed-values autoclave microwave oven room press) (type SYMBOL) (create-accessor read-write») (defclass CuringTime (is-a TechnologyMisc) (role concrete) (slot curing-time (allowed-values days hours minutes) (type SYMBOL) (create—accessor read-write)» (defclass DeliverySystem (is-a TechnologyMisc) 230 (role concrete) (slot delivery-system (allowed-values prepreg wet winding wet rolled) (type SYMBOL) (create-accessor read-write») (defclass FiberFormingMethod (is-a TechnologyMisc) (role concrete) (slot fiber-forming-method (allowed-values braiding cut and place directed fiber stamping textile preforming) (type SYMBOL) (create-accessor read-write») (defclass HeatedTool (is-a TechnologyMisc) (role concrete) (slot heated-tool (allowed-values yes no) (type SYMBOL) (create-accessor read-write») (defclass HeatingMethod (is-a TechnologyMisc) (role concrete) (slot heating-method (allowed-values electric heat blanket heated platens microwave oil oven steam no heating) (type SYMBOL) (create-accessor read-write») (defclass Labor (is-a TechnologyMisc) (role concrete) (slot labor (allowed-values high medium low) (type SYMBOL) (create-accessor read-write)» (defclass Postcuring (is-a TechnologyMisc) (role concrete) (slot postcuring (allowed-values yes no possible) (type SYMBOL) 231 (create-accessor read-write)» (defclass Pressure (is-a TechnologyMisc) (role concrete) (slot pressure (allowed-values low moderate high) (type SYMBOL) (create-accessor read-write)» (defclass PressureKSl (is-a TechnologyMisc) (role concrete) (slot pressure-ksi (allowed-values 0. 5-2 0. 5-1. 5 1. 5-3. 5 2-5 5-10 10-20) (type SYMBOL) (create-accessor read-write») (defclass ResinPrepregWet (is-a TechnologyMisc) (role concrete) (slot prepreg-wet (allowed-values prepreg wet) (type SYMBOL) (create-accessor read-write)» (defclass Temperature (is-a TechnologyMisc) (role concrete) (slot temperature (allowed-values 25-50 25-100 50-150 80-150 100-200 150-200 150—300 200-250 200-300 250-350 300-450) (type SYMBOL) (create-accessor read-write») (defclass ToolComplexity (is-a TechnologyMisc) (role concrete) - (slot tool-complexity (allowed-values veryhigh high medium low) (type SYMBOL) (create-accessor read-write)» 232 APPENDIX D MANUFACTURING ONTOLOGY REDESIGNED IN XML «header id="Manufacturing Ontology"> 234 235 236 - 237 radius depth height length width 238 thickness height length width radius angle depth length width 239 depth length width radius numberOf width 240 depth length width depth length width height length 241 radius depth length width radius height 242 height lenght width depth length width height length width 243 244 245 246 247 BIBLIOGRAPHY 248 9. BIBILOGRAPHY Allemang, D. and B. Chandrasekaran (1991). Functional Representation and Program Debugging. 6-th Annual Knowledge Based Software Engineering Conference. Balder, J. and H. Akkermans (1992). “Formal Methods for Knowledge Modeling in the CommonKADS Methodology, A Compilation. ” Netherlands Energy Research Foundation ECN(December). Ben-Natan, R. (1995). CORBA: a Guide to Common Object Reguest Broker Archiecture, McGraw-Hill. Bickerton, S. , H. C. Stadtfeld, et al. (1998). Active Control of Resin Injection for the Resin Transfer Molding Process. American Society for Composites Thirteenth Technical Conference, University of Maryland Press. Bond, W. E. and M. Pegah (1993). “Automated Model Selection for Simulation Based on Relevance Reasoning. ” IEEE Expert. Bond, W. E. and M. Pegan (1993). “Representation and Reasoning about the Fuel System in the McDonnel Douglas FA—f 8 from a Functional Viewpoint. ” EEEI Expert April. Brazier, F. M. T. ,Wijngaards, N. J. E (1997). A Purppse-Driven Methom the Comparison of Mgpeling Frameworks. 7th Workshop on Knowledge Engineering: Methods and Languages (KEML '97), Open University, Milton Keynes, UK. Brooks, R. A. (1986). “A Robust Layered Control System for a Mobile Robot. ” IEEE Journal of Robotics and Automation RA-2(April): 14-23. Brown, D. C. (1987). Routine Design Problem Solving. Knowledge Based Systems in Engineering and Architecture. J. Gero, Addison-Wesley. Buchanan, B. G. and E. H. Shortliffe (1984). Rule-Based Exgrt Systems: The MYCIN Experiments of the Stanford Heuristic Prpgramming Project. Cambridge, MA, Addison-Wesley. Carver, N. and V. Lesser (1992). The Evolution of Blackboard Control Architectures. Amherst, University of Massachusetts. Chandrasekaran, B. (1983). “Towards Taxonomy of Problem-Solving Types. ” Al Magazine 4(1): 9-17. 249 Chandrasekaran, B. (1993). The Functional Representation Language: A Framework for Reasoning, Ohio State University. Chandrasekaran, B. and T. R. Johnson (1993). Generic Task And Task Structures: History, Critique and New Directions. Second Generation Exgrt Systems. J. P. K. J. M. David, and R. Simmons, Springer Verlag. Chandrasekaran, B. and H. Kaindl (1996). Representing Functional Requirements and User-System Interactions. AAAI-96 workshop on Modeling and Reasoning about Function, Portland, OR. Chandrasekaran, B. ,S. Mittal,etal. (1979). An Approach to Medical Diagnosis Based on Conceptual Structures. lJCAl-6. Chen, Y. and B. H. C. Cheng (1997). Formalizing and Automating Commnent Reuse. IEEE international conference on Tools with Al, Newport Beach, CA, IEEE Press. Clancey, W. J. (1985). “Heuristic Classification. ”Artificial Intelligence XXVII: 289-350. Clancey, W. J. (1989). “Commentary on Sticklen's 'Problem Solving Architecture at Knowledge Level'. ” Jogrnal of Experimental and Theoretical Artificial Intelligence 2. Committee, A. H. ,Ed. (1987). Engineered Material Handbook. Composites. Metal Park, OH, ASM International. DARPA, P. H. (1998). HPKB Introduction, Teknowledge. 1999. de Kleer, J. (1977). Mpltiple Representations of Knowledge in a Mechanics Problem-Solver. IJCAI-77, Cambridge, MA. El-Sheikh, E. , C. Penney, et al. (1997). Intelligent Tutoring for Polymer Composite Molding. 1997 Symposium on Low-Cost, High-Speed Polymer Composites Processing, Michigan State University, East Lansing, MI. EI-Sheikh, E. , J. Sticklen, et al. (1996). Neppr Wheat: Integrating Expert Systems and Crop Modeling Technology. 6th International Conference on Computers in Agriculture, Cancun, Mexico, American Society of Agricultural Engineers. Eriksson, H. ,R. W. Fergerson, etal. (1999). Automatic Genpration of Ontology Editors. Twelfth Banff Knowledge Acquisition for Knowledge-based systems Workshop, Banff, Alberta, Canada. 250 Erman, L. ,F. Hayes-Roth, etal. (1988). The Hearsay-ll Speech- understanding system: Integrating Knowledge to Resolve Uncertainty. Blackboard Systems. R. E. a. T. Morgan. Reading, MA,Addison-Wesley: 31- 86. Ferguson, P. ,W. S. Humphrey, et al. (1997). “Results of Applying the Personal Software Process. ” Computer(May): 24-31. Fikes, R. , A. Farquhar, & J. Rice. (1997). Tools for Assembling Modular Ontologies in Ontolingua, Knowledge Systems Laboratory, Stanford University. Finn, T. ,Y. Labrou,etal. (1997). KQML as an Agent Communication Language. §oftwpre Agents. J. Bradshaw. Menlo Park, CA, AAAI Press. Forbus, K. (1988). Qualitative Physics: Past, Present and Future. Exploring Artificial Intelligence. H. Shrobe, Morgan Kauffman: 239-296. Fowler, M. and K. Scott (2000). UML Distilled. Reading, MA, Addison-Wesley. Friedman-Hill, E. J. (1997). Jess, The Java Expert System Shell. Livermore, CA, Distributed Computing Systems at Sandia National Laboratories. Genesereth, M. R. (1998). Knowledge Interchange Format draft proposed American National Standard (dpANS). San-Francisco, CA, Stanford University. Genesereth, M. R. ,R. E. Fikes, etal. (1992). Knowledge Interchange Format Version 3. 0 Reference Manual. Stanford, Ca, Stanford University. Gennari, J. H. ,D. E. Oliver, etal. (1995). AWeb-Based Architecture fora Medical Vocabulapr ServerServer. Nineteenth Annual Symposium on Computer Applications in Medical Care. Ginsberg, M. L. (1991). “Knowledge Interchange Format: The KIF of Death. ” Al Magazine(Fall 1997): 57-63. Glaser, N. (1996). Contribution to Knowledge Acquisition and Modeling in a Multi-Agent Framework (The CoMoMAS Approach). Doctorat de I'Universite Henri Poincare, I'Universite Henri Poincare. Gruber, T. , R. (1993). “A Translation Approach to Portable Ontologies. ” Knowledge Acquisition 5(2): 199-220. Gruber, T. R. (1992). Ontolingua: A mechanism to Support Portable Ontologies. , Knowledge Systems Laboratory, Stanford University,. 251 Hartman, J. and B. Chandrasekaran (1995). Functional _‘Representation and Understanding of Software. Technology and Application 5th Annual Dual- Use Technologies & Applications Conference, IEEE and Rome Lab, Utica, NY, IEEE Press. adaptaion of FR to representation of software Hawkins, R. ,J. McDowell, K. ,,etal. (1993). Function-Based Modeling and Tropbleshooting. AAAI Workshop on Reasoning about Function. Hayes, P. (1979). The Naive Physics Manifesto. Expert System in the Microelectronic Agp. D. Michie, Edinburgh University Press. Hayes, W. and D. Zubrow (1995). Moving On Up: Data and Experience Doing CMM-Based Process Improvement. Pittsburg, Software Engineering Institute, Carnegie Mellon University. Hayes-Roth, F. ,L. D. Erman, etal. (1992). Domain-Specific Software Archittectures: Distributed Intelligent Control and Communication. SEI at Carnegie Mellon University, SEI at Carnegie Mellon University. Hidlum, D. W. , N. M. Sadeh, et al. (1996). Mixed-Initiative Management of Integrated Process-Planning and Production-Scheduling Solutions. Artificial Intelligence in Manufacturing Research Planning workshop, Albuquerque, NM, AAAI Press. Honeywell (1999). What are the Benefits of Using a DSSA7, Honeywell. 1999. Johnson, M. V. and B. Hayes-Roth (1987). Integrating diverse reasoning methods in BBL Annual Conference of the American Association for Artificial Intelligence, Seattle, Wa. Johnson, T. R. (1991). Generic Tasks in the Problem-Solving Space Paradigm: Building Flexible Knowledge Systems while Using Task Level Constraints. Columbus, Ohio State University: 166. Kamel, A. ,O. Lukibanov, etal. (1997). ATask Spfiific Arphitecture for Conceptual Fabrication Seguence Planning for Structural Assemblies made from Commsite Materials. Interfaces 1997, Montpellier, France. Kamel, A. ,J. Sticklen, etal. (1989). A Model-Based Approach for Organizing Quantitative Computations. Model-Based Diagnosis workshop, Paris, France, AAAI Press. Keuneke, A. , M. (1989). Machine Understanding of Devices Causal Explanation of Diagnostic Conclusions. Computer Science Department. Columbus, Ohio State University: 103. 252 proposed to make, to maintain, to prevent function Kuipers (1986). “Qualitative Simulation. ” Artificial Intelligence(29): 289-338. Laird, J. E. ,A. Newell,etal. (1987). “SOAR: An architecture for general intelligence. Artificgiaj Intelliggtce 33(3). Lambert, M. , B. Riera, et al. (1997). Application of Some Functional Analysis Techniques on molear Reprocessing System. 5th International Workshop on Functional Modeling of Complex technical Systems, Paris-Troyes, France, The Center of Technology Risk Studies at University of Marilnd College Park. Lenat, D. and Guha (1990). Building Large Knowledge-Based Systems, Addison Wesley. Lenz, T. ,M. Hawley, etal. (1998). “Virtual Prototyping in Polymer Composites. ” ournal of Thermopplastic Commsite Materials 11: 394-416. Lenz, T. ,J. K. McDowell, et al. (1996). “The Evolution of a Design Support Architecture for Polymer Composite Design. ” IEEE Expert Intelligent Systems and Their Application 11(5): 77-83. Liver, B. and D. Allemang (1995). “A Functional Representation for Software Design. ” International Journal of Software Engineering and Knowledge i Engineering 5(2): 227-269. ' Lossak, R. , S. ,, M. Yoshioka, et al. (1998). A Comparative Analysis of function modeling in the design systems DIICAD-Entwurf and FBS/KlEF—System. Functional Modeling and Teleological reasoning Work shop at AAAI-98, Madison, WS, AAAI Press. Lukibanov, O. and l. Martinez (2000). “ Socharis: The lnstantiation of a Strategy for Conceptual Manufacturing Planning. ” Journal of Aritficial Intelligence in Engineering Design and Manufacturing(Fall). Lukibanov, O. ,I. Martinez, etal. (1998). Metal to Commsites Structural Assemblies: Developing Appropriate Functional Modeling Frameworks for Static Analysis. FMfI' R Workshop at AAAI-98, WI. MacGregor, R. (1991). The Evolving Technology of Classification-Based Knowledge Representation Systems. Principles of Semantic Networks: Exploration in the Representation of Knowledge. J. Sowa, Morgan Kaufmann. Martinez, I. ,O. Lukibanov, etal. (1999). Augmenting Conceptual Design with Manufacturing: an Integrated Generic Task Approach. DETC-99/DFM99, Las Vegas, NV, ASME. 253 Martinez, I. , O. Lukibanov, et al. (1998). Function-Based Modeling of Fabrication Plgrfi for Structural Assemblies. Special Interest Group in Manufacturing Workshop: State of the Art and State of Practice (SIGMAN-98), Albuquerque, New Mexico, AAAI, Press. McDermott, J. (1988). “Preliminary Steps Towards a Taxonomy of Probglem Solving Methods. ” Automated Knowledge Ackuisition for Expert Systems. McDowell, J. K. ,J. Sticklen,etal. (1997). Conceptual Design of Manpfacturing Seguences for Commsite Assemblies. ACCE, Dearborn, MI. Mettala, E. , M. Graham (1992). The Domain-Specific Software Architecture Program. Pittsburg, PA, SEI at Carnegie Mellon University. Mili, H. , F. Mili, et al. (1995). “Reusing Software: Issues and Research Directions. ” IEEE Transactions on Software Engineering 21(6): 528-561. Modarres, M. (1998). Functional Modeling of Physical Systems Using the Goal Tree-Spccess Trep Frgmework. Functional Modeling and Teleological reasoning Work shop at AAAI-98, Madison, WS. Motta, E. , K. O'Hara, et al. (1994). A VITAL Solution to the Sisyphus ll Elevator Design Problem. 8th Knowledge Acquisition for Knowledge-Based Systems Conference, Banff, Canada. Moy, B. ,J. K. McDoweII,etal. (1995). Integrated Design and Agile Manufacturing in Pplvmer Matrix Composites: The Role of Intelligent Decision Supmrt Systems. SAMPE-1995, CA. Murdoc, J. and A. Goel (1998). A Functional Modeling Architecture for Reflecting Agents. Functional Modeling and Teleological reasoning Work shop at AAAI-98, Madison, WS, AAAI Press. Newell, A. (1980). The Knowledge Level (Presidential Address). AAAI-1980, Stanford, CA, AAAI. Pegah, M. , W. E. Bond, et al. (1992). “Representing and Reasoning about the Fuel System of the McDonnell Douglas F/A-18 from a Functional Perspective. ” IEEE Expert: in press. Pegah, M. , R. Hawkins, et al. (1994). Functional Modeling psing Standard Parts: Suppprting Conceptual Design. AAAI Workshop on Functional Reasoning, Seattle, Washington. Price, C. J. (1996). “Identifying Sneak Paths though Function. 254 Punch, W. F. (1989). A Diagnostic System Using A Task Integrated Problem Solver Architecture (TIPS), Including Causal Reasoning. Computer Science Department. Columbus, Ohio State University. Riley, G. (1998). CLIPS a Tool for Building Expert Systems, Gary Riley. 1999. Schach, S. R. (1997). Software Engineering with JAVA. Chicago, Richard D. Irwin, a Times Mirror Higher Education Group Inc. Schapire, R. ,Y. Singer, etal. (1998). Boosting and Rocchio Applied to Text Filtering. SIGIR’98, Melbourne, Australia. Schapire, R. E. and Y. Singer (1998). Improved Boosting Algorithms Using Confidence-rated Predictions. COLT-98, MAdison, WS, AAAI press. Sembugamoorthy, V. and B. Chandrasekaran (1986). Functional fipresentafition of the_Devices and Compilation of Diagnostic Prtmlem S_olving Systems. Hillsdail, NJ, Lawrence Erlbaum Associates. Slator, B. M. (1989). “Decomposing Meat: a Commentary on Sticklen's 'Problem Solving Architecture at Knowledge Level'. ” Journal of Experimental and Theoretical Artificial Intelligence 2. Steels, L. (1990). “Components of Expertise. ” Al Magazine(Summer): 28-49. compares generic task approach to KAD Stevens, W. P. ,G. J. Myers, etal. (1974). “Structured Design. ”_IB_ Systems Journal 13(2): 115-139. Sticklen, J. (1987). MDX2: An Integrated Medical Diagnostic System, Ohio State University. University Microfilm Number 87-17732 Sticklen, J. (1989). “Problem Solving Architectures at the Knowledge Level. ” Journal of Experimental and Theoretical Artificial Intelligence 1: 1-52. Sticklen, J. and B. Chandrasekaran (1985). Use of Deep Level Reasoning in Medical Diagnosis. Government Symposium in Expert Systems. Sticklen, J. , A. Kamel, et al. (1991). “Integrating Quantitative and Qualitative Computation in a Functional Framework. ” Enginpering Applications of Artificial Intelligence 4. 255 Sticklen, J. , A. Kamel, et al. (1992). “Fabricating Composite Materials: A Comprehensive Problem Solving Architecture Based on a Generic Task Viewpoint. ” IEEE Exgrt 7(2): 43-53. Sticklen, J. , A. Kamel, et al. (1992). An Artificial Intelligence-Based Design Tool for Thin Film Composite Materials. East Lansing, Michigan State University. Sticklen, J. and R. Tufankji (1992). “Utilizing a Functional Approach for Modeling Biological Systems. ” Mathematical and Computer Modeling 16: 145- 160. Stroulia, E. and P. Sorenson (1998). Supmrting Software Redesign: Functional Reasoning meets Meta-Case tools. FM/T R Workshop at AAAI-98, Madison, Wisconsin, AAAI Press. Tsumoto, S. and H. Tanake (1995). “Interpretation of Medical Laboratory Data Based on Functional Model. ”. Tu, S. W. , H. Eriksson, et al. (1995). “Ontology-based configuration of problem-solving methods and generation of knowledge -acquisition tools: Application of PROTEGE-II to protocol-based decision support. ” Artificial Intelligence in Medicine 7: 257-289. Tu, S. W. ,M. G. Kahn, etal. (1989). “Episodic skeletal -plan refinement based on temporal data. ”Communications of the ACM 32(12): 1439-1455. Uschold, M. and M. King (1995). Towards a Methodolmy for Building Ontologies. IJCAI-95. van Heijst, G. ,A. T. Schreiber, etal. (1997). “Using Explicit Ontologies in KBS Development. ”Int. Journal Human-Computer Studies 45: 183-292. Velde, W. V. d. (1994). A Constuctivisst View on Knowledge Engineering ECAI %. A. Cohn, Wiley 8r Sons, Ltd. Velde, W. V. d. (1991). “Tractable Rationality at the Knowledge Level. Velde, W. V. d. (1993). Issues in Knowledge Level Modelling. Second Generation Expert Systems. J. -M. David, J. -P. Krivine and R. Simmons. Berlin, Springer Verlag. Vranes, S. and M. Stanojevic (1995). “Integrating Multiple Paradigms within the Blackboard Framework. ” IEEE Transactions on Software Engineering 21(3): 244-262. 256 Wang, E. Y. and B. H. C. Cheng (1998). Formalizing and Integating the MotionfialMotflnto Object Oriented Design. 10th International Conference on Software Engineering and Knowledge Engineering, San Francisco. Wang, E. Y. ,H. A. Ritcher,etal. (1997). Formalizing and Integrating the Dynamic Model wit_hin QMT. IEEE International Conference on Software Engineering. Wielinga, B. J. and A. T. Schreiber(1994). Conceptual modeling of large reusable knowledge bases. Berlin, Germany, Springer Verlag. Zhou, K. ,T. J. Lenz, etal. (1999). A Problem Solving Architecture for Virtual Prototyping in Metal to Polymer Composite Redesign. ASME-99, Las Vegas, NV. 257