00001.tif

PDF

Download

Open document

Transcript (if available)

Content DESIGN-FOR-ASSEMBLY (DFA) by REV ERSE EN G IN EERING by G erard Jounghyun Kim A D issertation Presented to the FACULTY OF TH E GRADUATE SCHOOL UNIVERSITY O F SOUTHERN CALIFORNIA In P artial Fulfillment of the Requirem ents for the Degree D O C TO R OF PHILOSOPHY (Com puter Science) April 1994 Copyright 1994 G erard Jounghyun Kim UMI Number: D P 22884 All rights reserved INFORMATION TO ALL U SE R S The quality of this reproduction is d ep en d en t upon the quality of the copy submitted. In the unlikely even t that the author did not sen d a com plete manuscript and there are m issing p a g es, th e se will be noted. A lso, if material had to be rem oved, a note will indicate the deletion. Dissertation Publishing UMI D P 22884 Published by ProQ uest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQ uest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United S ta tes C ode ProQ uest LLC. 789 East Eisenhow er Parkway P.O. Box 1346 Ann Arbor, Ml 4 8 1 0 6 - 1346 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 This dissertation, w ritten by Gerard Jounghyun Kim under the direction of h..i.$....... D issertation Committee, and approved by all its members, has been presented to and accepted b y The Graduate School, in partial fulfillm ent of re- c p s quirem ents fo r the degree of D O C T O R OF PH ILOSOPH Y Dean of Graduate Studies „ , April 13, 1994 D a te ........................... DISSERTATION COMMITTEE Chairperson Dedication This dissertation is dedicated in the m em ory of my father-in-law, the late Chae- hyung Lee, and my friend, the late Han-sung Kim. ii Acknowledgement s I owe to so m any people in completing this thesis. First of all, I sincerely thank my advisor, Dr. George Bekey. He has shown me the true sense of the word, “teacher,” not only guiding me academically, but helping me come through the tough tim es during my graduate study at USC. His insights, often unknowingly, have sparked and pushed m y research to the present level. I am so grateful for his tru st and confidence in me. I express m y deep appreciation to other m em bers of my thesis com m ittee, Dr. Ken Goldberg, Dr. Behrokh Khoshnevis, Dr. Sukhan Lee, and Dr. Ari Requicha, for all the helpful criticism , suggestions, and encouragements on my research. In particular, Dr. Goldberg, in helping me w rite my first m ajor conference paper, has taught and m atured me into a more complete student of com puter science. His continuous interest has kept me on th e edge all the tim e. Being a Korean, Dr. Sukhan Lee has always been an inspiration to me. I am especially thankful to Dr. Lee, because he always had tim e for me for discussion of my work. There have been two groups of people whom I could always count on for support, fellowship, and even a helping hand in my research. One are m y colleagues at the Robotics Research Laboratory, namely, Andy Fagg, Tony Lewis, Gaurav Sukhatm e, Joungwoo Kim, Kusum Shori, Mike McHenry, Jim Montgomery, Dr. Hernsoo Hahn, Parag B atavia, Dr. Sungbok Kim, Dr. Hahksung Lee, Yeongwoo Choi, Chunsik Yi, A lberto Behar, Jun Park and Arvin Agah. I am especially indebted to Andy for thousands of things, ranging from little com puting questions to feedbacks on my research. The other are my fellow Korean friends at USC and at th e East Light Korean Church. Their hospitality and friendship will rem ain in my heart for m any years to come. I especially would like to express my gratitude to Pastor Joseph Lee, Dr. Jongje Jung, Dr. Hongyeop Song, Dr. Kyungmu Lee, Sungdon Cho, Bonghan 1 1 1 Cho, Woosuk Kim, Yongsung Park, members of th e ELKC Choir, and m em bers of the Korean Basketball Club. I am grateful to Dr. Kevin Lyons, Dr. Howard Bloom, and, Dr. Steven Ray for presenting me w ith an opportunity for a postdoctoral work at NIST. Dr. Lyons has helped me complete my research proposal and crystallized my ideas for future research directions. My biggest support group, of course, has been my friends and family back in Korea. My father, once a long tim e graduate student himself, has been my role m odel, while my m other’s teaching of perseverance, determ ination, and persistence had a lot to do w ith my success. I am lucky to have the m ost generous m other-in- law who has put up w ith an undeserving son-in-law. Also, I hope I can become a b etter big brother to So-hyung, Ah-hyung, Sooyoon and Kwangsung. My friends of “Ichon”, Dongju, Hyeongcheol, Youngje, and Jun, also deserve a special recognition for their friendship and support, since we first m et at the Yongsan highschool back in 1980. I thank my wife, Sooah, m other of our newborn son, Andrew. She certainly is a special person w ith lots of love. She has, for a long tim e, been putting up w ith a rather unglam ourous and sometimes lonely lifestyle of a graduate stu d en t’s wife. We have experienced m any obstacles together, and we were able to overcome them thanks to her often unappreciated wisdom, patience, and sacrifice. She really has brought out the best in me. Lastly, I thank God to be able to even say all this. IV Contents D ed ication ii A cknow ledgem ents iii List O f Tables viii L ist O f Figures x A b stract xiii 1 Introduction 1 1.1 Background and M o tiv a tio n ............................................................................. 1 1.2 Research Problem and Issu e s............................................................................. 3 1.2.1 Redesign by “Replay and Modify” ..................................................... 4 1.2.2 Redesign by Reverse E n g in e e rin g ..................................................... 6 1.2.3 Redesign by Case-based R e a s o n in g .................................................. 7 1.3 Organization of the T h e s is ................................................................................ 10 2 R elated W ork 11 2.1 Design-for-Assembly ( D F A ) ............................................................................. 11 2.1.1 Conventional Approaches to D F A ..................................................... 12 2.1.2 Lim itations of Conventional Approaches to D F A ......................... 13 2.2 Design C apture S y s te m s ..................................................................................... 14 2.2.1 Conventional Approaches to Design C a p tu r e ................................. 15 2.2.2 Design C apture and R e d e s ig n ............................................................ 15 2.3 AI in D e sig n ............................................................................................................ 16 2.3.1 Redesign by R e p la y ................................................................................. 16 2.3.2 Design Process M o d elin g ....................................................................... 17 2.4 Case-based and Analogical R e a so n in g ........................................................... 18 3 O verview of R E V -E N G E : A M odel for DFA R edesign 20 3.1 Problem S ta te m e n t.............................................................................................. 20 3.2 O verview ................................................................................................................... 21 v 4 K n o w le d g e R e p re s e n ta tio n a n d A c q u is itio n 26 4.1 Input R e p re se n ta tio n .......................................................................................... 29 4.2 Knowledge A c q u isitio n ....................................................................................... 31 5 D e sig n A n a ly sis 35 5.1 Assembly Expert (A -E X )................................................................................... 35 5.2 Problem R e p re s e n ta tio n ................................................................................... 39 6 D e sig n P la n C o n s tru c tio n 42 6.1 Design P l a n .................................................................. 42 6.2 Design Plan Construction P ro c e s s ................................................................... 44 6.2.1 Design Plan R e p re s e n ta tio n ................................................................. 44 6.2.2 Design Plan Construction .................................................................... 47 6.2.3 Design Plan Construction Heuristics ....................................................48 6.2.3.1 Prescriptive Design Model (Global Heuristics) . . . . 48 6.2.3.2 Local H euristics...................................................................... 50 6.2.4 Im p le m e n ta tio n ......................................................................................... 50 7 C a s e -b a se d D esig n M o d ific a tio n 58 7.1 Problem Solving Strategy ................................................................................ 60 7.2 Problem M apping and S e le c tio n ..................................................................... 62 7.3 Case Representation and Retrieval .............................................................. 65 7.4 Redesign V alid atio n ........................................ 68 7.5 Case A d a p t a t i o n ................................................................................................. 69 7.6 Execution of R e d e s ig n ...................................................................................... 70 7.7 Producing a Plan of Redesign: An E x a m p l e ............................................. 72 8 M o re E x a m p le s 79 8.1 An Old-Fashioned P lu g ...................................................................................... 79 8.2 M o u s e ..................................................................................................................... 83 8.3 Reticle A s s e m b ly ................................................................................................. 88 9 C o n c lu sio n 92 9.1 C ontributions ...................................................................................... 93 9.1.1 Model of DFA R e d e s ig n ....................................................................... 93 9.1.2 Inference of Design P l a n ....................................................................... 93 9.1.3 Global R edesign......................................................................................... 94 9.1.4 Case-based R e d e s ig n .............................................................................. 94 9.2 L im ita tio n s ........................................................................................................... 95 9.2.1 Lack of Domain Specifics....................................................................... 95 9.2.2 Geometric In fe a sib ility ............................................................ 95 9.2.3 Im plem entational P r o b le m s ................................................................ 95 9.3 Future Research D irectio n s............................................................................... 96 vi 9.3.1 A ddition of Domain Models ................. 96 9.3.2 Integration w ith Assembly P la n n in g ................................................... 98 A p p en d ix 100 A p p en d ix A Input D ata for Container E x a m p l e ..............................................................................100 A .l D e s ig n ........................................................................................................................ 100 A.2 Assembly O peration ............................................................................................ 102 A p p en d ix B Input D ata for Plug E x a m p le ........................................................................................ 104 B .l D e s ig n ........................................................................................................................ 104 B.2 Assembly O peration ............................................................................................ 110 B ibliography 113 vii L ist O f T ables 2.1 An exam ple DFA score table for feeding. L /D , A /B , and A /C denote ratio of length to diam eter, length to w idth, and length to height respectively. A dapted from [11] w ith perm ission.......................................... 12 2.2 Scores of DFA axioms of orientation efficiency. A dapted from [32] w ith permission from Society of M anufacturing Engineers. Copyright 1989. . ................................................................................................................... 13 2.3 Six m ain heuristics in determ ining an existence of analogy identified by [ 6 6 ] ....................................................................................................................... 19 4.1 Different types of standard design inform ation............................................. 27 4.2 Different types of non-standard design inform ation.........................................28 4.3 Design objects and typical slots and relations represented in REV EN G E.......................................................................................................................... 29 5.1 DFA Problem s generated for the three p art container exam ple (Figure 4 . 2 ) . .......................................................................................................................... 39 6.1 Exam ple constituents of a design state................................................................44 6.2 Examples of design actions in the “Design Space.” ....................................... 46 6.3 A default design plan generated for the three part container in text by REV -EN G E......................................................................................................... 53 7.1 Examples of DFA rules..............................................................................................60 7.2 Problem s m apped to portions of th e default design plan generated for the container (see Figure 4.2 and Table 5.1) by R EV -EN G E.......................64 7.3 An example of a redesign case................................................... 66 7.4 Redesign cases th at are retrieved for solving “expensive m ating type” problem (P R O B -M A TIN G -B A SE -C O V E R -LIA ISO N ) for th e container exam ple...................................................................................................................... 67 7.5 Checking design rationale of the container (Figure 4.2) w ith precon ditions and side effects of case-40...................................................................... 69 7.6 M atching actors in th e case w ith design objects in the container example. 70 7.7 A design plan for a new container w ith a force fit...................................... 74 viii 8.1 DFA problem s generated for the old-fashioned plug.................................... 80 8.2 A default design plan and problems generated by REV -EN G E for the P lug.............................................................................................................................. 81 8.3 A new design plan for the Plug. Design actions m arked w ith asterisks are newly introduced design actions...................................................................... 84 8.4 DFA problems generated for the DEC m ouse................................................ 86 8.5 A default design plan and problems generated by R EV -EN G E for the DEC m ouse............................................................................................................... 87 8.6 DFA problems generated for the reticle subassembly. ............................. 89 8.7 A default design plan and problems generated by REV -EN G E for th e reticle su b assem b ly ............................................................................................... 89 ix L ist O f F igu res 1.1 A before and after shot of an assembly redesigned w ith DFA prin ciples. The assembly, called reticle, is p art of a ground based ar m ored vehicle m anufactured by Texas Instrum ents’ Defense Systems and Electronics Group. A gear box was replaced w ith a cam, which created sm oother m otion and alm ost all of th e fasteners were elimi nated by using self securing parts. The connector bracket was incor porated into the housing. Reprinted w ith perm ission [81]........................ 2 1.2 Typical design fixes used in DFA redesigns. R eprinted w ith perm is sion of the Society of M anufacturing Engineers (SM E). Copyright 1983 from [6])........................................................................................................... 5 1.3 Redesigning an Itinerary........................................................................................ 6 1.4 Case-based redesign................................................................................................. 8 3.1 Research problem form ulation. Symbols, S, P, R, D, 0 , and N each denote Specification, Process, Rationale, Design, Original and New respectively................................................................................................................ 21 3.2 A rchitecture of REV -EN G E................................................................................. 22 3.3 REV -EN G E startu p window................................................................................ 25 4.1 Exam ple of a fram e representation of an assembly operation........................30 4.2 An illustration of changing design representation w ith knowledge ac quisition for a simple three p art container...................................................... 32 4.3 M enu-based acquisition of design rationale in R EV -EN G E........................... 33 5.1 Design-for-Assembly analysis criteria tree............................................................37 5.2 Exam ple of a problem representation................................................................ 40 5.3 A problem sum m ary panel of DFA analysis result for the three p art container example. There are three categories or dimensions of anal ysis, and each subcategory carries a different weight according to user specification. The overall score (or penalty) is shown in the lower right corner............................... 41 x 6.1 An exam ple of design states and a design action. Descriptive design objects are used as param eters for design actions. Both descriptive and derivational objects m ay be brought into existence by an appli cation of a design action, or by deliberate introduction by the planner consistently w ith other design states................................................................ 6.2 Construction of a design plan............................................................................. 6.3 A Prescriptive Design Model (PDM ) [5] [67] [34]....................................... 6.4 Exam ple of a design description in Prodigy Description Language O 'm > ........................................................................................................................................... 6.5 An exam ple of an Prodigy operator for expressing a design action. . . 6.6 Examples of a PDL search control rules......................................................... 6.7 A default design plan of a three p art container shown in a justification stru ctu re..................................................................................................................... 6.8 A default design plan of a three container shown in a REV -EN G E window. The scrollable window shows the first three stages of design w ith 5 design actions.............................................................................................. 7.1 Case-based Redesign.............................................................................................. 7.2 M apping DFA analysis to th e design plan...................................................... 7.3 Problem s m apped to portions of the design plan......................................... 7.4 Traces of retrieval of cases in R EV -EN G E..................................................... 7.5 A dapting a case to a current problem .............................................................. 7.6 A plan of redesign in a justification stru ctu re................................................ 7.7 A plan of redesign in a REV -EN G E window (scrolled down to show the portion changed com pared to Figure 7.3)................................................ 7.8 Original container m odeled using PADL-2 solid m odeller......................... 7.9 A possible redesign of the container using PADL-2 (m anual).................. 7.10 A sum m ary of analysis of the new design. Compare the to tal penalty score between the old (Figure 5.3) and the new (lower right corner). This score reflects the best possible situation (i.e. the m inim um penalty score) where no other problems are assum ed to be created after applying the redesign case......................................................................... 8.1 An old-fashioned plug........................................................................................... 8.2 Acquisition of design rationale............................................................................. 8.3 A newly designed plug w ith chamfers, a stop, and a snap fit (m anual). 8.4 Redesigning a DEC Mouse. Reprinted w ith perm ission from [1]. . . . 8.5 Acquisition of design rationale for DEC m ouse............................................. 8.6 Acquisition of design rationale during redesign............................................. 8.7 A possible redesign of the mouse following advice from REV -EN G E (m anual). Note th a t com pared to th e actual redesign in Figure 8.4, REV -ENG E was not able to recom m end the elim ination of the track ing ball due to simple lack of innovative knowledge................................ . 8.8 A possible redesign of the reticle subassembly following advice from R EV -EN G E (m anual). Note th a t com pared to th e actual redesign in Figure 1.1, REV-EN GE came up w ith a slightly different redesign, where th e Carriage is clipped on to the shafts..................... 91 9.1 Theory of generating a detailed and product specific redesign advice. 99 Abstract “Design-for-Assembly (DFA)” is an engineering m ethodology concerned w ith im proving product designs for easier and less costly assembly operations. M any of academ ic or industrial efforts in this area have been devoted to developm ent of anal ysis tools, th at is, tools for m easuring the “assem blability” of a design. On th e other hand, little attention has been paid to the actual redesign process. The goal of this thesis is to develop a model of redesign for DFA. A com puter- aided DFA tool, called REV -EN G E (REVerse EN G ineering), based on the model has been developed. REV -EN G E is based on a redesign m odel, known as the replay and modify paradigm [57], in which a previous design plan is replayed and modified wherever necessary and possible, in accordance to the original design intention, for newly specified design goals. The replay and modify paradigm is an effective redesign m ethod because it offers a m ore fundam ental solution than simple patch-ups by be ing able to get to th e root of the problem. In order to support the replay side of the paradigm , design inform ation, such as the design plan and design rationale, usually unavailable in practice, is acquired through a com bination of explicit knowledge ac quisition and autom atic inference, i.e. through re v e rs e e n g in e e rin g . As for the modify side of th e paradigm , REV -EN G E uses a case-based approach whereby old redesign strategies are stored, retrieved and adapted for different redesign circum stances. The architecture of REV -EN G E is composed of four m ain components: d e sig n a n a ly sis, k n o w le d g e a c q u is itio n , d e sig n p la n re c o n s tr u c tio n , and c a se -b a se d d e sig n m o d ific a tio n . Given inputs of descriptions of a design and associated assembly operations, a designer can interactively build a “high level” plan of redesign for DFA, using various com putational services provided by REV -EN G E th a t support th e replay and modify process. REV -EN G E has been im plem ented and tested w ith several exam ple, and shown promising and interesting results. xiii Chapter 1 Introduction 1.1 Background and Motivation “Design-for-Assembly (DFA)” is a design philosophy concerned w ith im proving prod uct designs for easier or less costly assembly operations. DFA can also lead to im provem ents in serviceability, reliability, and quality of th e end product [7]. Figure 1.1 depicts a typical application of DFA, showing before and after shots of an as sembly redesigned according to DFA principles [81]. It is easy to recognize th at the redesigned assembly not only has fewer parts, but also is sim pler to assemble. This type of redesign can bring significant cost savings in the required handling and assembly equipm ents. Since DFA was first introduced in th e U nited States by Dr. Geoffrey Boothroyd and Dr. P eter Dewhurst in the late 1970’s, DFA has become increasingly popular driven by th e emergence of m anufacturing autom ation, decreased tim e-to-m arket requirem ents and more fierce com petition. M any of the academ ic and industrial efforts in DFA have been devoted to de velopm ent of analysis tools, th a t is, tools for measuring the “assem blability” of a design. For exam ple, th e Product Design fo r Assembly Handbook of Boothroyd and Dewhurst [11] is a tool which provides ratings for each p art in an assembly based on p a rt’s ease of handling and insertion. There are num ber of commercial packages for assessing th e design quality in term s of DFA principles, and m any companies also have developed their own in-house software or methodologies for DFA analysis [7] [12] [49] [53] [55] [64] [79] [76] [77], 1 sofcsw e-iw c liK 'i wmmi} *mo£ C A S U U A C J J W S A S W , * ! » : . * O X * — , (M K srm :. I oecfou® S B » 1 Kf tl 'i ■ W l& r* SjSKiPI.IK; (C W S S r A tS * BfA O U f' smrr 'i v JfcS S S ® fjxs SSTt ri ^ «SM*££ m sim Figure 1.1: A before and after shot of an assembly redesigned w ith DFA principles. T he assembly, called reticle, is part of a ground based arm ored vehicle m anufactured by Texas Instrum ents’ Defense Systems and Electronics Group. A gear box was replaced w ith a cam, which created sm oother m otion and alm ost all of th e fasteners were elim inated by using self securing parts. T he connector bracket was incorporated into th e housing. R eprinted w ith permission [81]. 2 On th e other hand, however, little attention has been paid to th e actual redesign process. W hile th e purpose of an analysis tool is to identify specific problems w ith a design, a redesign to solve the problems still rem ains in th e hands of designers. To devise a redesign solution, a designer needs to com m unicate w ith m anufacturing en gineers, for instance, in order to find out constraints im posed by m anufacturing and assembly facilities. Therefore, a typical DFA redesign process m ay involve gathering various m em bers of th e product development team in a room, and “brainstorm ing” for a solution, and m aking sure the solution is acceptable to all. U nfortunately, the com m unication and cooperation among designers, m anagers, and m anufacturing en gineers is often ham pered by their differences in work culture and background, or sometim es even by geographical separation. Redesign (often viewed as inverse of analysis) is, in general, a difficult problem because there is often not a unique m apping from analysis results back to the design variables. Therefore, redesign requires m any iterations of “generate and te st” [68]. In fact, Hsu et al. has proven redesign problem to be N P-com plete [33]. In their proof, Hsu et al. form ulated th e redesign problem as a variant of a design problem. The design is represented as a process to which a set of variables are satisfied according to a given set of specifications. Then, The design problem is shown to be equivalent to th e problem of CNF-satisfiability. The goal of this thesis is to develop a model of redesign using DFA criteria. Based on the m odel, a com puter-aided tool for assisting designers in redesigning a product for im proved DFA can be constructed. Such a tool, for exam ple, could be used during the aforem entioned “DFA brainstorm ing session” and im prove upon the efficiency of the process and minimize the required personnel by m anaging the inform ation flow, and keeping track of possibly large num ber of design alternatives. It could also be used concurrently during the initial phase of design as a subsystem of a larger com puter-aided design (CAD) system to design a product “right at the first tim e.” 1.2 Research Problem and Issues T he m ain focus of this thesis is to address the following research issues in developing a model for DFA redesign, and im plem enting a redesign tool based on the model. 3 1.2.1 R e d e sig n b y “R ep la y and M o d ify ” A very im portant issue in developing a model for DFA redesign is th e issue of “global redesign vs. local patch-ups.” A patch-up solution refers to a local fix to the result or product of th e final design. For example, popular DFA design fixes shown in Figure 1.2 can be classified as patch-up solutions. On the other hand, instead of patching up the problems, a m ore fundam ental redesign m ight be possible by getting to th e root of the problems. For example, in Figure 1.1 by merging the front bracket onto the housing, problems th a t were associated w ith the bracket (e.g. th e need for screwing th e bracket onto the housing) are sim ply elim inated. A patch-up solution of replacing the screws/holes w ith a less expensive type of m ating would have worked w ith less im pact on reducing the overall assembly cost. M ethods of such a fundam ental redesign, hence called “global” redesign, are of particular interest, because, when successfully applied, they usually cut th e assembly cost more radically th an a solution solely m ade up of patch-ups. T he process of “global redesign” is m ore efficient (but difficult) th an th a t of patch-ups, since th e root of the problem m ust be addressed. Moreover, certain DFA problem s can not be solved by a simple patch. Therefore, it is im portant th a t a DFA redesign model allow both types of redesign. M any designs are created by adapting previous successful designs or modifying a candidate design to satisfy design goals it failed to m eet [57], One m ethod of redesign, known as th e replay and modify paradigm , is to replay a previous design plan, and modify th e plan wherever necessary and possible, in accordance to the original design intention, for newly specified design goals. Replay refers to an act of presenting a stored sequence of design decisions or design actions perform ed during a course of previously com pleted design process. The replay and modify paradigm is an effective redesign m ethod because it offers a m ore global solution th an simple patch-ups, by modifying the process of the design rath er th an the final result of the design process. Figure 1.3 illustrates the advantage of the replay and modify paradigm in creating a m ore global redesign. T he thin line represents a travel route design from Los Angeles to New York (an original design). Suppose we would like to design a new route of travel from Los Angeles to W ashington, D.C. (a redesign). Considering th a t 4 pin bolt parts no ch a m fe r cham fer fcettam p art Figure 1.2: Typical design fixes used in DFA redesigns. R eprinted w ith perm ission of th e Society of M anufacturing Engineers (SM E). Copyright 1983 from [6]). NY CH DC SF DY LA Figure 1.3: Redesigning an Itinerary. D.C. and New York is relatively close (a design variant), one possible solution is to extend th e existing travel plan by adding a route from New York to D.C. (a local patch). However, a b etter solution, for exam ple, is to “replay” the original itinerary from Los Angeles and “modify” th e route either from Chicago or Denver. 1.2.2 R e d e sig n b y R ev e rse E n g in eerin g Kuffner et al. and G ruber have studied th e task of redesign by observing m echan ical engineers at work and analyzing their protocols [25] [45]. T heir study have illustrated the role of questions and conjectures in redesign. A question is defined as an interrogation by the subject about any aspect of design, and a conjecture is defined as a conclusion or an assum ption about th e design inferred by th e subject from incom plete inform ation [45]. In brief, these studies have m anifested the use of reverse engineering in redesign. Reverse engineering1 roughly refers to an activity of 1The term “reverse engineering” is often used in the field of software engineering. In software engineering, the goal of reverse engineering is to automatically abstract code to a specification level such that the specifications can be modified and revised code can be automatically regenerated [10]. On the other hand the goal of reverse engineering in this thesis is to capture the process from given design specifications to the current design. (1) acquiring/inferring th e process, e.g. the design plan and design rationale, used in creating a given design, and (2) using th e inferred knowledge for design recreation or redesign [41] [42]. By analyzing the nature of questions and conjectures often asked and m ade by the subjects, their study has identified different types of design inform ation th a t is essential for redesign, but th a t is unavailable from standard design docum entations. Such inform ation includes knowledge of function, device behavior, design rationale, and design alternatives, among others. In a general dom ain, these types of knowledge are difficult to infer autom atically due to th e sheer enorm ity of the search space. A lternatively, recording and storing all the required design knowledge also presents a problem for practical reasons (see Section 2.2). A com promised solution may be to instead develop an intelligent and system atic m ethod of interactive knowledge acquisition. Their study gives hints on how the required design knowledge can be represented and structured for th a t purpose. T he concepts of reverse engineering and replay and modify are quite sim ilar and com patible in th a t in order to apply the replay and modify paradigm , the existence of a design plan record (i.e. th e process of design) is assumed, just as the original itinerary would be needed in redesigning the travel route. A design plan is a sequence of design actions th a t led to the actual original design. Also equally required for aj valid redesign is design rationale. Suppose in our travel route redesign exam ple, th a t the traveler needed to visit Chicago. If this rationale is still valid during redesign, thej alternative option of flying from Denver to D.C. should not be considered. D espite its im portance in redesign, it is yet to become a standard practice to record information,' such as design plan or design rationale, during design. Therefore, th e redesigner, who is often not the original designer of the product, m ust infer, guess, or acquire such inform ation for an effective and successful redesign. 1.2.3 R e d e sig n b y C a se-b a sed R ea so n in g In general, building a design/redesign system for a general dom ain (e.g. electro m echanical products) is a difficult task due to a potentially enormous am ount of required knowledge and differences between design theories among different design domains. 7 Current Problem Case Base Retrieve Redesign Case 1234 cross section external view Match <3 C 3 Redesign Figure 1.4: Case-based redesign. 8 Use of prior cases or episodes in design has been well known [4] [8] [17] [23] [27] [44] [52] [62]. T he idea of case-based reasoning in design, in th e context of redesign, is illustrated in Figure 1.4. Given a design to be modified, a redesign case sim ilar in various aspects to the problem atic design is retrieved from a pool of cases. A correspondence betw een objects in the current problem and th e retrieved case is established. Then, based on the correspondence,.a redesign is perform ed as prescribed in th e retrieved case. This m odel of reasoning is particularly applicable, since th e redesign process to be modeled in this thesis is one th a t proceeds w ithout a full behavioral m odel of th e target design (Establishing a “full” behavioral m odel of a given design through interactive knowledge acquisition would be difficult). This is com parable to situ ations where hum an designers can come up w ith an interesting design alternative w ithout fully understanding how th e design works, by simply applying general re design (or DFA) strategies and adapting it based on the physical structure of the design and using “common sense.” Moreover, redesigns th a t typically occur during DFA m ainly incur changes in the form of th e design rath er th an the function. Also, DFA is m ainly applied to portions of designs which exhibit m inim al kinem atic be havior (non-moving parts). This may be due to a tendency of redesigners to leave functions or behavior unchanged, while trying to im prove upon th e assem blability only. Typical examples include replacing screw/holes w ith force fits, m odifying part shapes, adding new features (such as chamfers, slots, grooves, etc.), rem oving fea tures, elim inating a p art by merging functions, etc. (see Figure 1.2). M any DFA redesign solutions seem to involve a novel com bination of “routine” redesign fixes and complex functional or behavioral reasoning specific to certain domains. A dditionally, even if the dom ain knowledge of the behavior of th e device can be m odeled, it alone does not provide a sufficient reasoning power for fully exploring th e design space, since m any qualitative judgm ents unrelated to th e dom ain need to be m ade (e.g. about physics, forces, common sense). Instead, by relying on prior cases, not only is the search space on design alternatives reduced, but also th e effort required in th e knowledge engineering is m uch relieved: th a t is, it is m uch more feasible to build a case base of redesigns th an reasoning and m odeling th e entire behavior of the design in response to various input and disturbances. This thesis in stead explores how far general design knowledge and experience can take to produce 9 interesting redesigns w ithout detailed dom ain models. There are several research and im plem entation issues associated w ith using case-based reasoning which include th e identification of appropriate case indices and m atch heuristics th a t determ ine the sim ilarity between th e current problem and th e cases, the representation of cases, and the adaptation process. 1.3 Organization of the Thesis The rest of the thesis is organized as the following. T he im m ediately following chap ter presents related work in DFA, design capture system s, and artificial intelligence in design. C hapter 3 overviews the architecture and various aspects of REV-EN GE, the proposed DFA redesign model. In the following four chapters, each compo nent of REV -EN G E, namely, design analysis, knowledge acquisition, design plan construction, and case-based design m odification, is elaborated and illustrated w ith a sim ple exam ple. In chapter 8, m ore exam ples of redesign w ith REV -EN G E are shown to highlight both th e m erits and lim itations of the approach. Finally, in the last chapter, concluding rem arks, research contributions, and possible future work, are given. 10 Chapter 2 Related Work 2.1 Design-for-Assembly (DFA) Recently, there has been a growing need and interest in concurrent or sim ultaneous engineering. In concurrent engineering, th e m anufacturability is considered during the design process to lower m anufacturing cost, im prove product quality and reduce m arketing tim e. “Design-for-Assembly (DFA)” is an aspect of m anufacturability focused on im proving th e assem blability of the product. T h at is, DFA is a process of optim izing product designs for easy and low cost assembly operations (see Figure 1.1, 1.2 and Table 7.1). An assembly-conscious design is desirable because it could result in significant savings in capital costs and assembly tim e, and thereby, higher design quality and efficiency. For exam ple, the IBM C orporation has successfully applied the concept of DFA to one of its printer models, by redesigning and reducing th e num ber of parts, which drastically lowered the p rin ter’s assembly cost, and price [6]. DFA is com m only practiced in Europe, Japan and in the U.S. Recently, DFA has been ap plied to assembly planning as well [48] [51]. An assembly-conscious design, however, is difficult, in general, because designers tend to focus only on the functionality of the product. Considering assem blability concurrently w ith th e functionality of a product seems to be a m ajor source of distraction th a t m ost traditional designers would like to avoid. This is specially apparent when there exist m any parts exerting various constraints upon each other. In m any cases, therefore, a redesign m ust be perform ed to achieve the goals of DFA, instead of incorporating th e DFA principles during the initial design phase. 11 very small parts large parts rotational non-rotational rotational non-rotational L /D < 1.5 L /D > 1.5 A /B < 3 A /C > 4 A /B > 3 A /B < 3 A /C < 4 L /D <1.5 L /D > 1.5 A /B < 3 A /C > 4 A /B > 3 C O H 1 VIVI 0 0 o 2 2 2 2 2 9 9 9 9 9 Table 2.1: An exam ple DFA score table for feeding. L /D , A /B , and A /C denote ratio of length to diam eter, length to w idth, and length to height respectively. A dapted from [11] w ith permission. 2.1.1 C o n v en tio n a l A p p ro a ch es to D F A Currently, there exist two m ain types of DFA m ethods. T he m ost popular m ethod is typified by the one pioneered by Boothroyd and D ew hurst [11]. In their approach, a product is analyzed according to various “ease of assem bly” criteria (such as sym m etry, dim ension, m ating direction, num ber of parts, etc.), organized w ith charts of scores, and a tabulated score is used to calculate a design efficiency ratio. M any other commercial system s or in-house m ethods [79] [49] [53] [64] [79] [77]. are based on this approach partly because the table lookup and the arithm etic procedure are easily com puterizable. Table 2.1 shows an exam ple of a DFA score table developed by Boothroyd and Dewhurst. T he second type of approach is called th e “axiom atic” m ethod [32] [2]. The axiom atic m ethod is simply a set of design guidelines th a t have been em pirically derived from years of experience in design and assembly operations. If correctly applied either during the initial design phase or th e redesign phase, they should result in a product th a t has an inherently low assembly cost [55] [76]. M any such DFA axioms have been identified by a num ber of researchers [32] [2] [6]. In particular, in an effort to m ake the axiom atic m ethod m ore evaluative, H oekstra has assigned scores to each of the design axioms in a subjective m anner, for exam ple, in a scale of 1 to 5 (see Table 2.2). Table 2.2 shows scores for design axioms th a t concern the orientation efficiency of parts. H oekstra showed th a t his m ethod can be used for DFA evaluation w ith a high correlation to B oothroyd’s m ethod. 12 Design for Assembly Axiom Cost P art tangles, nests or shingles 5 A sym m etric part w ithout m arked polarities 5 A sym m etric p art w ith m arked polarities 3 Sym m etric part 1 P a rt delivered to assembly station w ith known orientation 1 Table 2.2: Scores of DFA axioms of orientation efficiency. A dapted from [32] w ith perm ission from Society of M anufacturing Engineers. Copyright 1989. 2.1 .2 L im ita tio n s o f C o n v en tio n a l A p p ro a ch es to D F A B oth approaches are m ore suited for a com parative DFA design analysis rath er than for an actual redesign. The actual redesign of the product is still in th e hands of th e hum an designers. W hile m ost useful and cost-saving redesigns are based on a “global” redesign (vs. local patch-ups), conventional DFA tools usually fall short of guiding hum an designers tow ard a global solution. This is m ainly because the analysis has been perform ed upon final result of the design process, instead upon the design process itself. T he conventional DFA tools also do not provide any m eans for predicting the effect of design m odification w ith respect to th e intended function or other design criteria (such as m anufacturing cost, custom er satisfaction, etc.). Since, in th e absence of th e original designer, original design intention can not be taken into account, design problems found by the conventional tools are not necessarily am enable to change. For exam ple, certain design decisions rated “undesirable” w ith respect to DFA may have been due to a certain unavoidable design constraint or specification. An alternative approach is to develop more objective DFA m etrics w ith a sci entific basis so th a t the analysis result can be directly reflected to redesign. For exam ple, in [43], a num erical DFA m etric for feeding, called feedability, along with a set of specific redesign heuristics, have been developed based on a m athem atical m odel of a parallel jaw gripper. However, developing such types of DFA m etrics is a difficult task in general, since it is not clear if all facets of assem bly process can be m athem atically m odeled. However, while this approach m ay bring analysis and 13 redesign closer together, it would still exhibit th e same problem s of th e conventional m ethods in term s of producing global and valid solutions. Design capture system s can help repair lim itations of conventional DFA tools described above by providing capabilities for viewing th e design process in a global m anner (for exam ple, in term s of design plans) and validating design changes in accordance w ith the design rationale. In th e following section, a review of current approaches in design capture system s is presented. 2.2 Design Capture Systems In general, a design history refers to a record of all inform ation m anipulated by designers during th e design process. T he core of a design history includes a design plan and design rationales. A design plan is a sequence of design actions or design decisions which lead to th e creation of th e design, while design rationale refer to ex planatory design inform ation for the design actions such as design constraints, design specifications, design intent, design assum ptions, and etc. T he potential benefits of capturing design history has long been recognized. For exam ple, redesign can be greatly facilitated by th e availability of th e design history of the product by allow ing the redesigner to build on th e efforts of th e original designer, find potential flaws in th e original designer’s logic, or make im provem ents in light of new inform ation or advancing technology, as opposed to second-guessing or rederiving [13]. A cquiring a design history, however, is problem atic in practice. F irst of all, it is yet to becom e a standard practice of designers to record their design activities. Some designers keep “designer’s notebooks,” b u t the design notes are often unreadable, incom plete and ill-structured. Secondly, in m any cases, th e original designers are not available on site to provide the missing inform ation. Finally, current com puter- aided design (CAD) system s are not capable of capturing such design records. In the following two subsections, current researches in design capture system s are reviewed, and discussed w ith respect to their utility for redesign. 14 2.2.1 C o n v en tio n a l A p p ro a ch es to D e sig n C a p tu re One of th e earlier efforts in design capture systems was th e electronic notebook th a t encouraged designers to record their design process in pure tex t and graphics [46]. T he current popular approach is the semiformal approach which is based on eliciting sem i-structured tex t about design rationales during design, usually im plem ented in a hypertext environm ent. Based on the form alism of th e approach, it can be fur th er classified into those centered around design objects and design constraints [16], argum ents and issues [50] [54] [21], design alternatives [71], and others. According to G ruber [26], these types of approaches are called record and replay paradigm s, because design rationale is recorded during design, and replayed or retrieved at redesign tim e. Recently, new research efforts have been p u t tow ard autom atic inference of design rationale, based on sim ulation [26], and device behavior models [9]. According to G ruber [26], these types of approaches are called acquire and generate paradigm s in which design inform ation is captured during redesign through knowledge acquisition and knowledge based inference m ethods. 2 .2 .2 D e sig n C a p tu re an d R e d e sig n T he m ost serious drawback of th e record and replay paradigm is its low practical ity due to the burden of cum bersom e user interactions required for recording the rationale for every each design action [57]. Following is a typical reaction of an experienced designer [69]. “I have been designing PC boards on various CAD system s . . . . the design rationale in my opinion is very subjective and varies greatly from user to user. There m ay be several ways to produce the desired result. I believe th a t if a user were required to input the design rationale as a separate task it would be very cum bersom e and im practical. Designers have enough to worry about and rem em ber w ithout having ex tra details to input during the course of a design.” A nother problem is overflow of inform ation. In m ost cases, the record and replay; types of design capture systems are not associated w ith any specific “po st” design 15 task (e.g. addition of function, redesign of body, etc.). If a specific task, for which th e design capture system will be used, can be identified a priori, only the design inform ation im portant and critical to th e future task m ay be captured in a more efficient m anner. This problem also has partially m otivated the rise of th e acquire and generate paradigm s, in which only the design inform ation relevant to the task at hand is captured or inferred. However, the acquire and generate paradigm requires strong dom ain knowledge, such as qualitative behavior models, and sim ulation m od els, and therefore, its application is m ostly lim ited to a very narrow design domain. 2.3 AI in Design 2.3.1 R e d e sig n b y R ep la y Redesign by replay was first introduced by Mostow [57]. T he idea was based on Derivational Analogy in which the problem solving th a t leads to a design is saved and reused to find a design solution to a new problem [15]. T he basic im plicit as sum ption is th a t th e redesigned product would have a sim ilar design derivation as the original design. A num ber of design system s based on derivational analogy has been developed including REDESIGN [75], BOGART [58], and ARGO [35]. For example, in RED ESIG N , an idealized design history was hand constructed, th en replayed and modified to produce design variants of VLSI circuits. These system s worked well partially because the design process model of top-down refinem ent was well suited for the VLSI circuit design dom ain, and the search space was relatively lim ited since th e function-to-form m apping was m ore straightforw ard th an in m echanical design. Langrana et al. later extended and applied the core of the BO G A RT system to m echanical design dom ains (design of gears and belts), and developed M EET [47]. Design of gears and belts was somewhat sim ilar to VLSI circuit design in th a t design param eters of the form (e.g. gear radius, num ber of teeth, and belt length) tran s lated well to functional param eters (e.g. torque ratio). A raya et al. have developed a copier paper p ath design system , called PR ID E, which retrieves a pre-stored design plan and uses dependency directed backtracking w ith dom ain dependent modifica tion heuristics to achieve a new design [3]. Inui et al. proposed a d ata dependency m odel of a design process using an Assum ption-based T ru th M aintenance System 16 (ATMS) [18] [36]. Inui et al. used an ATMS to m odel a sequence of solid modeling operations and used operators such as undo, redo and back to generate variant solid models. T he acquisition of th e design plan in all of these system s were either hand constructed to an ideal form or recorded during design. 2 .3 .2 D e sig n P r o c e ss M o d e lin g There are other design process models or planning system s based on different strate gies and design representations. One popular m odel is th e iterative redesign of param etric designs [65]. In this m odel, a design is represented as set of constrained param eters, then a heuristic hill clim bing m ethod is applied iteratively to find pa ram eter values th a t satisfy th e given function requirem ents w ithout violating the given constraints. A nother popular design model is the functional approach, where a given design dom ain is qualitatively or functionally m odeled. Dom ain specific heuristics are used for generating a design or redesign by qualitatively reasoning about th e input and ou tp u t relationships. B oth P R O M P T [60], AIR-CYL [14], and K R IT IK [23] [24] belong to this approach. In the K R ITIK system , for instance, behavioral functions of a reaction wheel assembly aboard the H ubble space telescope are modeled using a functional representation language. A faulty design is detected from an inconsis tency betw een the desired and observed o u tp u t behavior. A redesign is achieved by selecting and applying a redesign strategy (e.g. component replacement). M odels of planning and replanning have influenced m any of the design system s to date. T he top-down refinem ent m odel of VEXED [74] and its variants (R E DESIGN , BO G A RT, and M EET), is a form of subgoaling and hiearchical planning [70]. Stefik’s M OLGEN system , a m olecular genetics experim ent design system , uses m eta-planning [73]. In m eta planning, there exist levels in planning spaces accord ing to degrees of abstraction. T he higher planning space contains knowledge about strategies to create and schedule steps in the lower planning space. M eta planning is also closely related to devising plans for solving constraint satisfaction problems which design is often regarded as [22]. T he problem of replanning, analogous to th e redesign problem , has been addressed by num ber of researchers [19] [29] [30] 17 [39] [38] [72] [78] [82]. Tractable yet dom ain independent approaches to replanning usually require design knowledge in the form of design rationale or causal models. 2.4 Case-based and Analogical Reasoning Case-based reasoning has attracted m uch attention in design [4] [8] [17] [23] [27] [44] [52] [62]. T he im portance and usefulness of previous cases in design have long been recognized. Case-based planning, sim ilar to derivational analogy, is based on th e idea th a t m achine problem solver m ust rely on abstracting past experiences to solve the current problem. It differs from straightforw ard rule-based planning, since it uses actual cases instead of generalized rules and case retrieval is generally more complex th an rule m atching. Also, case-based planning is usually closely associated w ith learning, because a case-based reasoner m ust reuse and learn from its own experiences to build new plans and to avoid past errors. Two of th e m ost im portant subproblem s in case-based planning are the indexing problem and the adaptation problem . T he indexing problem refers to th e problem of how to index and retrieve the case base efficiently, and the adaptation problem refers to the problem of how to autom atically adapt the retrieved case to th e current situation. A case-based reasoner usually redesigns by detecting differences between th e retrieved case and the current design and applying resolution schemes th a t are dom ain dependent. For exam ple, in C H EF, H am m ond’s Chinese food recipe designer, when the request was m ade to prepare a dish w ith a certain vegetable which violated conditions required in th e preparation steps in the retrieved plan, a m odification operator was fired to shuffle and introduce th e new steps in the plan to satisfy th e given goal [27]. W hile researchers in case-based reasoning are focused m ore on th e indexing and retrieval problem , researchers in analogical reasoning have focused m ore on the adap tatio n problem. Several algorithm s and heuristics have been developed by num ber of % researchers for autom atically generating an analogical solution of a targ et problem from a pool of problem s w ith known solutions [66]. A lthough “autom atic” genera tion of a DFA redesign is not an im m ediate goal of this proposal, th e principles and algorithm s are related to the overall m odel of REV -EN GE. For exam ple, in [59], the adaptation process has been modeled in three stages: grounding, deleting and 18 Heuristics Basis Strength Partial homomorphism Similarity in structure of problem representation Strong Consistent translation Consistency among multiple matches Strong Syntactic type Similarity in problem representation itself Strong Argument type Match between types of elements Variable Identical symbols Existence of exact match of key elements Weak Semantic type Match between semantics of elements Weak Table 2.3: Six m ain heuristics in determ ining an existence of analogy identified by [66] adding. In th e first stage, an initial m atch of a priori plausible associations is con structed. In th e second stage, this m atch is w hittled down to a subset of associations which fit together well according to a heuristic m easure. In th e th ird stage, holes are filled in th e w hittled down m atch. T he analogical problem solving m odel of [59] has much relevance to th e adaptation procedure of R EV -EN G E, although, th e issue of validation has not been addressed. According to [66], there are six im portant heuristics in determ ining an existence of analogy as shown in Table 2.3. M any of the replay and modify based design system s, such as RED ESIG N , BO G ART, A RG O , and PR ID E , do m ake use of one or m ore of these analogy heuristics, such as the p artial hom om orphism and identical symbols. 19 Chapter 3 Overview of REV-ENGE: A Model for DFA Redesign In this chapter, first a formal statem ent of th e research problem is given. T hen, an overview of REV -EN G E, a com puter-aided DFA tool is presented, as an im plem en tatio n of a solution to the research problem. REV -EN G E is based on three ideas, namely, “redesign by replay and modify,” “redesign by reverse engineering,” and “redesign by case-based ad ap tatio n .” 3.1 Problem Statement T he research problem of this thesis, to develop a m odel of DFA redesign and im plem ent a com puter-aided tool, can be formally stated as th e following. T he term s used in th e form ulation will be clarified in the discussion th a t follows (also see Figure 3.1). G iven, description of the original design (D o), acquire, the original set of design specifications of D o (So), the original design process used to derive D o (Po), and the original set of design rationale used in Po (R o), and help find, a new design process (Pn ), and a new set of design rationale (R n ) such that Pn and R n lead to a description of a new design (D n ), where, D n is “more easily assemblable” than D o , and, the set, R n - R o, is “consistent” with So and Ro- 20 Specification Space Design Space Figure 3.1: Research problem form ulation. Symbols, S, P, R, D, O, and N each denote Specification, Process, Rationale, Design, Original and New respectively. 3.2 Overview Figure 3.2 shows th e overall architecture of REV -EN G E. In general, design (or re design) is m odeled as an iteration of three step process: analysis, synthesis, and evaluation, as illustrated in the top portion of the figure [17]. REV -EN G E prim arily models th e synthesis (or design alteration stage as worded in th e figure) of the re design process as cycles of three m ain activities: knowledge acquisition, construction of a default design plan, and design m odification. Hence, REV -EN G E constitutes an inner set of cyclic activities w ithin th e design alteration stage, where design ac tivities occur m ore frequently th an in th e outer loop. T he inner loop can continue as long as a new analysis is not required. An analysis m ust be perform ed upon a given design to determ ine any need for a redesign. A design can be analyzed in m any different ways w ith respect to various criteria. Among them , DFA is of particular interest in this thesis. U nsatisfactory analysis results do not necessarily m ean th a t a new design or redesign (D n in Fig ure 3.1), for exam ple, w ith a higher assem blability and lower overall cost, exists. It is rath er a different level of a decision (of th e product developm ent team or m an agem ent) w hether to seek for a redesign or not, after considering th e relative cost of assem bly w ith respect to other cost criteria such as m anufacturing, production 21 Design Alteration Design Evaluation Design- Analysis Knowledge Acquisition - Functional Description - Design Rationale - Engineering Information - Assembly Operation Information Generate Design Plan using Design Knowledge Construction of Default Design Plan Map problems onto Responsible Design Actions - Predefined Design Actions - Determine Order among Design Actions Solve Selected Problem Select Next Problem Case-based Redesign Change Knowledge - Case Retrieval - Case Adaptation Light Traffic Heavy Traffic Figure 3.2: A rchitecture of REV -EN G E. volum e, etc. It is not w ithin the scope of this thesis to address how such a decision m ight be m ade or how to predict precisely if a b etter redesign exists at all. It is assum ed th a t a redesign is sought simply when an analysis reveals an existence of problem s. Given a description of a design including the original design specifications (i.e. So is assum ed to be given), th e knowledge acquisition m odule interactively acquires th e design rationale, Ro- Design rationale is represented and stru ctu red in such a way th a t it can easily be m apped onto the com ponents of th e design process, Po. M ore specifically, the design process, Po, is expressed as a sequence of design actions (e.g. a design plan) and each design action m ight be justified by one or m ore design rationale. If the analysis procedure determ ines an existence of a design problem , and thus, a redesign is required, a default design process, P o, is constructed. Viewing th e design process as a state space search, Po is inferred by using a default search heuristic and justifying each step of th e search w ith R o ■ Po is hence called a default design plan, since it is a sequence of probable design actions th a t m ight have happened during th e actual design. T he result of the analysis m ust m ap to com ponents of Po to find starting points of the transform ation from Po to PXr. In other words, the design problem s m ap to some portion of the design plan where th e problem m ight have originated. Usually, as a default rule, problem s th a t occur earlier in the design plan are attacked first, as they potentially have m ore global effects. For exam ple, change in a function stru ctu re in an early phase of design m ay elim inate a p art, which could have ripple effects on other parts of th e design. On the other hand, problem s th a t m ap to later stages of a design plan usually are local design problem s. For exam ple, slight dim ensional changes are usually possible w ithout affecting th e whole design. T hen, th e design plan is replayed and modified where necessary. T he applicability of the replay and modify paradigm is based on an assum ption th a t th e derivation of th e new design, D m , will be very sim ilar to th e old design, Do- T he design m odification is an interactive process based on a case-based m ethod. Therefore, a case-based approach is used to find a transform ation from (P o, R o ) to (Pjv, R n ) and to check if the set, R m - R o (newly introduced conditions), violates any already existing conditions in So and R q . W hile the default design plan provides a global 23 view in redesign, the case-based redesign focuses on solving one design problem at a tim e. Cases provide design fixes in term s of addition and deletion lists of design objects, and describe their side effects on function, cost, new problem s, and other factors. Once a relevant case is found, it is adapted to the current situation interactively. A fully autom atic case adaptation, a difficult research problem itself, requires dom ain models or dom ain theories for every target design dom ain, which is practically in feasible. R EV -EN G E, instead, provides various com putational services for assisting th e ad aptation process by generating plausible candidate m atches and keeping track of related design inform ation for validation. T he cycle of problem selection and problem solving continues until as m any problem s as possible can be solved. T he final solution can be represented as a new design plan, Pn - T he new design plan, expressed as series of high level design actions (vs. geom etric change), can then be handed to a CAD system user for him to follow and realize the redesign geometrically. Therefore, R EV -EN G E interactively and increm entally builds an integrated solution to the design problem s identified during th e analysis stage. R EV -EN G E has been im plem ented in COM M ON LISP and consists of approxi m ately 15,000 lines of code. G A R N ET, an X window user interface to LISP [61], has been used for developing the user interface. T he m odule th a t infers th e design plan has been im plem ented using a general problem solver, called PR O D IG Y [56]. Figure 3.3 shows the REV -EN G E startu p window. REV -EN G E realizes th e redesign model and allows user the following functionalities. • Load design and assembly operation data. • Interface to solid m odeller, called PADL-2 [28] for illustration. • Browse and acquire design rationale and other design knowledge. • Perform a DFA analysis and identify design problems. • R econstruct a design plan. • M ap problem s to responsible portion of the design plan. 24 Rev-Enge 2.0 Rov-Enge 2 la a knoulfldga-baMd cool Cor Design-£or~Aseeri>ly- This research was, in part, sponsored by 2MAK, HIST and MSF, and woe conducted at the university o£ southern California. Rev-Enga uses Garnet (3.2 Alpha), an X window user interface tool kit for LISP, and Prodigy, a symbolic problem solver, developed at the Carnegie Mellon University, and interfaces to PADL-2, a solid modeller developed at the University of of Southern California. Copyright (c) 1993 - Gerard Gounghyun Kim Load Assembly Data Browse/Acquire Knowledge DFA Analysis (A-EX) Q Design Plan generation Case-Based Redesign Save Image Q End Session Figure 3.3: REV -EN G E startu p window, e Select a design problem to attack. a Vary relative im portance (weights) of analysis and case retrieval param eters. • R etrieve old redesign cases. • Help adapt th e retrieved case to th e currently selected problem . • Help validate the applicability of th e retrieved case. • Execute a redesign as prescribed by the selected case. • G enerate a final report or redesign plan in term s of a new design plan. 25 Chapter 4 Knowledge Representation and Acquisition In order to im plem ent a com puter based redesign system , a representation scheme for various d a ta used in th e system is needed. This chapter addresses three knowl edge representation issues in REV-ENGE: first the content of the required design knowledge critical for redesign, th e content and form at of th e input design knowl edge, and the interactive acquisition m ethod for th e design knowledge missing from th e input. As m entioned in C hapter 2, Kuffner, Ullm an and G ruber have studied th e types and n atu re of inform ation solicited by designers during redesign [25] [45] [80]. Table 4.1 and 4.2 illustrates different types of such design inform ation. T he three im portant questions for each category are: (1) w hether th e type of design inform ation is relevant to th e redesign task at hand, (2) w hether th e type of design inform ation is provided by the “stan d ard ” design docum ents, such as CAD data, engineering database, and (3) how difficult it is to acquire the inform ation, if not provided by the standard design docum ents. In general, all of the types of design inform ation listed in Table 4.1 and 4.2 are useful for redesign. C ertain types of design inform ation m ay carry inform ation im portant and specific to DFA redesign. For exam ple, the knowledge of assembly operations, or special design attrib u tes (e.g. sym m etry) are im portant for DFA, while design rationale or design specification are essential in validating a proposed redesign. C ertain types of knowledge th a t are missing m ay be inferred as well, although this usually is difficult since it m ay require complex geom etric processing or reasoning about the design context. For exam ple, in [37], a concept of “suggestive” CAD system is introduced, where such a system tries to infer special attrib u tes of 26 Type Typical Contents Source Form Geometry Geometric Parameters Design Features Geometric Dimensions Geometric Constraints CAD Drawings, Group Tech. Codes Component Data Part Names Manufacturing Price Weight Part Material Database Assembly Plan Assembly Operations Assembly Plan Assembly Pose Subassemblies Required Fixtures Assembly Devices Assembly Planner Specification Design Specifications Customer Requirements Design Requirements Design Specs Table 4.1: Different types of standard design inform ation. a p a rt such as its sym m etry. A sim ilar system has been reported in [31]. Not to m ention th e com putational difficulty in deriving sym m etries, such inform ation m ay require different answers depending on a given design or analysis context1. Also, it is possible to infer certain product-specific design rationale or design constraints to some extent, given a detailed m odel of th e product. In general, it can be said th a t th e m ore knowledge and inform ation available, th e m ore effective and valid redesign is possible. Therefore, an integral p art of R EV -EN G E is acquire and capture as m uch as possible of th e design knowledge critical to redesign and missing from standard design docum ents. T he general approach used in R EV -EN G E is to predefine d ata structures for representing various types of design knowledge and present users w ith an easy-to-use interactive acquisition tool. To m inim ize user efforts, th e redesign tool m ust allow users (1) to proceed w ithout com pletely filling in th e missing knowledge 1 For instance, certain axis of symmetry may be more important than others depending on the DFA analysis criterion in question. 27 Type Typical Contents Structure Relative Part Locations Types of Connections Types of Matings Special Attributes Symmetry Handling Distance Tangling/Nesting Function Function of Parts Function of Features Relationships among Subfunctions Function Hierarchy Behavior Device Behavior Model Form-Behavior Relationship Design Actions Design Decisions Conjecture Hypothetical Assumptions Constraint Design Constraints Design Specifications and Requirements Rationale Reason for Choice of Parts Reasons for Choice of Design Decision Reasons for Choice of Design Parameter Reasons for Choice of Parameter Value Relation/ Dependency Ordering of Design Decisions Relationships among Design Parameters Dependencies among Design Information Alternatives Design Alternatives Design Failures Table 4.2: Different types of non-standard design inform ation. (although this m ight result in iterations of trial and error later), and (2) to enter new design knowledge any tim e during redesign for retrial. W hile a behavioral m odel of a product m ay provide a deep understanding of how a given product works and how design changes m ight affect specific behaviors of th e product, it is very difficult to acquire or construct such a behavioral m odel through an interactive acquisition process, because constructing a behavioral model of a product is a huge knowledge engineering effort itself. M ost design system s to date operate in a specific design dom ain (e.g. paper p ath design of copiers [3], air cylinders [14], etc.) where dom ain specific representations are developed and used to describe behavior a priori through extensive knowledge engineering. Judging from 28 Name Typical Slots (or Relations) assembly has-part, type, number-of-parts, number-of-connectives, total-assembly-time, has-function, has-problem Part part-of, has-feature, weight, material, type, stability, structurally-related-to, size, symmetry, moving-part?, has-function, has-problem, has-design-action, has-rationale Feature feature-of, type, size, subtle?, symmetry, has-function, has-problem, has-design-action, has-rationale Liaison mating-parts, connectives-involved, features-involved, type, has-function, has-problem, has-design-action, has-rationale Function type, description(textual), has-function, has-problem, has-design-action, has-rationale Table 4.3: Design objects and typical slots and relations represented in REV -EN G E. th e types of redesigns th a t R EV -EN G E is to handle (non-moving p arts), a rigorous behavioral m odel m ight not be an absolute requirem ent for fairly useful redesign assistance. Therefore, only a lim ited am ount of behavioral design inform ation is sought by REV -EN G E. Consequently, th e redesign assistance relies upon case-based reasoning rath er th an m odel-based reasoning. 4.1 Input Representation T he in p u t representation to REV -EN G E contains two types of inform ation: design and assem bly operations. T he representation scheme used in R E V -EN G E is basically collection of objects (in fram es) and relations among them . Table 4.3 describes some of design objects and design relations represented in REV -EN G E. Shown next in Figure 4.1 is an exam ple of a fram e representation for an assembly operation. This particular fram e describes an assembly operation of m ating two parts, base and cover, by screwing screw-1 into the holes, base-hole and cover-hole, using a fixture and via top-to-bottom (-z) assembly direction. The content of the input representation for both design and assem bly operation is assum ed to be obtainable except for the a ttrib u te values th a t are not usually available from standard design docum ents. Therefore, values for attrib u tes, such as sym m etry, has-function, clearance, has-rationale, and etc., are interactively obtained 29 (make-operation '0 2-screw :type screwing :special-op (list fix) :realizes (list base-cover-liaison) :parts-involved (list screw-1 subl) :major-features (list base-hole cover-hole) :helping-features nil :forms container :direction -z :active screw-1 :passive cover :next-op-of ol-align-base-cover :fixture minor :equipment (list robot) :constraint nil :description "Screw in screw-1." :symmetry-in-op "Yes" :clearance "Yes") Figure 4.1: Exam ple of a fram e representation of an assem bly operation. 30 through explicit knowledge acquisition. A m ore detailed pictorial exam ple w ith a sim ple three p art container is illustrated in Figure 4.2. Also see th e appendix for a full illustration of th e input data. 4.2 Knowledge Acquisition In R EV -EN G E, to m inim ize user efforts during knowledge acquisition, semi-formal d a ta structures for representing various types of design inform ation are used w ith a m enu-based acquisition tool (see Figure 4.3). T here are three types of knowledge acquisition in REV -EN G E. One is for filling in th e missing values for various attrib u tes of th e design and assembly operations, such as sym m etry, and clearance. Usually, the values for these attrib u tes are binary (yes or no answers). This additional inform ation about the design and assembly operations is prim arily used for the DFA analysis purposes, i.e. to find problem s based on these feature values. T he second type of knowledge acquisition is for acquiring design rationale and other design knowledge (such as function2). A d a ta stru ctu re for design rationale, for exam ple, has been designed in a simple way, so as to relieve th e user’s effort as m uch as possible. T he user needs to supply th e following three types of inform ation to specify a design rationale. F irst is the type of design rationale. Currently, there are three types of design rationale: design specification, design explanation, and design conjecture (see the :is-a slot in lower p art of Figure 4.3). Design explanation refers to any ty p e of design inform ation th a t can be used to explain a particular design action, such as design constraints and design intent. Design specification is a subclass of design constraints th a t is given by the design need and usually rem ains unchanged through th e design. Design conjectures are various design assum ptions m ade during design th a t m ay be retracted later. T he second type of inform ation needed to specify a design rationale is the type of design action th a t th e design rationale justifies. T here are currently four types of design actions, namely, create- function, create-form, select-form and detail-form as shown in Table 6.2 (also see -.type slot in lower p art of Figure 4.3). Finally, the user needs to specify which 2Function can be described in terms of design rationale, e.g. as a concept of “purpose”. 31 © Screw_l is-a: part type: screw has-rationale: nil Base is-a: part has-feature: base_hole has-rationale: nil Cover is-a: part has-feature: cover_hole has-rationale: nil Container is-a: assembly has-part: bottom, cover, screwl 1. Input Representation Spec-1 is-a: design-specification type: detail-form target: base property: size description: “base need to be at least 5 cubic inches.” Base is-a: part has-feature: base_hole has-rationale: nil symmetry: “No” tangle/nest?: “No” New Information New Attribute Values 2. Knowledge Acquisition 3. Updated Representation Cover is-a: part has-feature: cover_hole has-rationale: nil Screw_l is-a: part type: screw has-rationale: nil Container is-a: assembly has-part: bottom, cover, screw_l Base is-a: part has-feature: base_hole has-rationale: Spec-1 symmetry: “No" Tangle/Nest?: “No” Figure 4.2: An illustration of changing design representation w ith knowledge acqui sition for a sim ple three p art container. 32 Br-ouse/'ftcquir-e Knou ledge @ 1 f t }teveng&-Object Revenge -Typ e Cutoff-Percentage Index-Veight Problem-Summary Redeeign-Caee Threshold P h a n to m -A ction Design-Action Operation Subassembly De s 1 g n - R a ti o n a le Function Liaison Feature Part Assembly Problem 2 £k s t & Design-Rationale Conjecture Explanation f t Specification Base_Spec3 Container_Specl I B S PADL-2 OH PADL-2 OFF show/change Shade ^ Add Q Done Delete | k l PLUG_SPEC1 m J fOK 1 [A p p ly C a n c e l| I IS -A : (#k<SPECIFICATION?) TYPE: ICREATE-FUNCTIOH CREATE-FORM SELECT-FORM DETAIL-FOkH| PROPERTY: | § | PROPERTY: :HEIGHT JU STIFIES: NIL IS-JU ST IFIE D -B Y : NIL RATIONALE-OF: (#k<TOP> #k<BOTTOM?) DESCRIPTION: "m u st h a v e h e i g h t = 1 . 7 5 in c h " Figure 4.3: M enu-based acquisition of design rationale in REV -EN G E. 33 design object and a ttrib u te the design rationale explains, constrains or specifies (see :rationale-of and :property slot of Figure 4.3). Using this inform ation, th e design rationale can be be m apped later to a specific design decision, since th e tuple of (design action type, target object, property) uniquely defines a design decision. T he final type of knowledge acquisition in REV -EN G E is th e autom atic inference of th e design plan (sequence of design decisions) and this is described in C hapter 6. 34 Chapter 5 Design Analysis As described in C hapter 2, there are already several established m ethods of analyzing products w ith regards to DFA. It is not th e purpose of this research to devise a new m ethod of DFA analysis, b u t rath er to integrate th e existing m ethods into the redesign m odel. To accomplish this, conventional analysis m ethods require an augm entation so th a t th e problem s th a t are identified during th e analysis can be m apped to design decisions (which will be generated in later stages) th a t would be responsible for producing these problem s. T he purpose of m atching design problem s and th e correspondingly responsible design decisions is to obtain an ordering in which to solve th e problem s th a t is based on th e order of design decisions. This idea is based on the fact th a t th e problem s resulting from earlier design decisions m ust be solved first, as they present m ore fundam ental problem s th an the ones resulting from the later stages of design. This section describes a sim ple DFA analysis program (called A-EX) th a t has been im plem ented as p art of dem onstrating th e whole redesign model. 5.1 Assembly Expert (A-EX) A rule-based design analysis system , called th e Assembly E xpert (or A-EX), has been built. Sim ilar approaches have been reported in [40] [53]. However, such a system in isolation is generally of little use, since the redesign problem m ust be addressed from a to tal product developm ent point of view. T he expert system works in sim ilar ways to the conventional m ethods. Given a description of a design and th e assembly operations involved w ith th e design represented in a symbolic m anner, e.g. frames 35 (see C hapter 4), th e expert system sim ply finds DFA problem s and associates them w ith various types of predefined design actions (see C hapter 6) based on types of th e problem s, and types of th e problem atic design objects. Figure 5.1 shows a DFA analysis tree. T he tree represents various subcriteria of DFA used in A-EX, which can be either switched on or off depending on the user preference or need during analysis. Currently, there are 18 rules corresponding to each leaf in th e analysis tree. T he analysis is subdivided into three categories (cor responding to th e three interm ediate nodes in th e analysis tree): assem bly analysis, p art analysis, and operation analysis. T he assembly analysis analyzes th e design w ith respect to “global” features of the design, for exam ple, num ber of to tal con nectives (e.g. screws, nuts, etc.) and num ber of different m ating types (screwing, riveting, inserting, etc.). In th e following exam ple rule (expressed in plain English for illustration purpose), a problem is identified when th e ratio of the to tal num ber of connectives to the to tal num ber of parts is greater th an a fixed threshold. R u le 10: A ssess-relative-n o-of-con n ectives I F number — o f — connectives ^ ^ number — o f — parts ~ 5 T H E N Record a problem w ith a following description: problem type 1: mating problem type 2: time problem type 3: major problem type 4 • Rule 10 problematic design object: all mating liaisons problematic design object property: mating type problematic design action type: select-form description: “Relatively too many connectives are used.” T he p art analysis exam ines each p art and feature of th e design to find DFA prob lems. For exam ple, it exam ines the types of a feature, w hether a p a rt is standard, or w hether a p art is m ade of fragile m aterials. T he following rule, for exam ple, identifies a problem when a p art is likely to be nested or tangled during handling. 36 Design for A ssem bly Analysts nn r ri 1 1 1 riTu rnnnrrnun j> i> l> I«l»IiiilM i*iiT rlT < ‘ llWirifrr»YiViriWiiViYI< Different Mating Types [Assembly Analysis No of Connectives Part Requirement Symmetry in Handling Part Analysis [Nes t /Tangl in g | j ; Pull Analysi; (standardization Clearance Subtlty|; (Feature [Tool Requirement [Grasping Surface Symnetry in Operation |No of Assembly Direction Operation Analysis [Assembly Direction [Operation Time Fixture Requirement Existence of Helpful Feature Assembly Feature Type Figure 5.1: Design-for-Assembly analysis criteria tree. 37 W hether a p art will nest or tangle is determ ined by various special attrib u tes and answers to user queries obtained during knowledge acquisition. R u le 3: A ssess-n est-tan glin g IF part can nest or tangle, T H E N Record a problem w ith a following description: problem type 1: handling problem type 2: cost problem type 3: moderate problem type 4 • ' Rule 3 problematic design object: part problematic design object property: shape problematic design action type: select-form description: “The part shape is prone to nesting and tangling. ” T he operation analysis exam ines each assem bly operation and related design features to find DFA problem s. These features include clearance, tool requirem ents, existence of sym m etry, m ating cost, m ating tim e and etc. T he following rule, for exam ple, exam ines th e tim e cost (expressed in seconds) of types of m atings and and records a problem when th e tim e cost is greater th an a given threshold. REV -EN G E is equipped w ith a.knowledge base of different types of assem bly operations and their expected tim e and cost. R u le 5: A ssess-assem b ly-tim e IF time cost of operation type > 1 5 seconds, T H E N Record a problem w ith a following description: problem type 1: mating problem type 2: time problem type 3: moderate problem type 4- Rule 5 problematic design object: liaison 38 problematic design object property: mating type problematic design action type: select-form description: “Mating op exceeds the preferred time bound.” 5.2 Problem Representation A nother im portant im plem entation issue is the representation of problem s. The syntactic representation of problem s im pacts th e system perform ance as they are used as m ain indices for retrieving solution cases during th e redesign phase. This is because p art of th e indices of th e stored solution cases are types of design problem s they can solve. The right-hand side of the three exam ple rules in the previous section illustrate how a problem is represented in REV -EN G E. There are currently four attrib u tes (problem-type-1, problem-type-2, problem-type-3, and problem-type-4) based on th e n atu re of the problem . For exam ple, problem-type-1 specifies for which process th e DFA problem m ay incur m ore cost or tim e, e.g. m ating, setup, handling, m anufacturing or assembly planning. Problem-type-2 specifies w hether th e problem is m easured by m onetary cost or by tim e. Problem-type-3 specifies th e seriousness of th e problem , expressed in three levels, m inor, m oderate or m ajor. And, finally, problem-type-4 specifies which rule or criteria th e design had violated. Shown in Figure 5.2 is a representation of a problem associated w ith a m ating type (screwing) generated for th e simple container exam ple in Figure 4.2. Problem Name D escription PROB-ASYM -FEAT-COVER-HOLE Cover-hole is neither sym m etric or very asym m etric PROB-ASYM -FEAT-BASE-HOLE Base-hole is neither sym m etric or very asym m etric PROB-FEAT-EXIST-BTW -COVER-BASE No helping feature between Cover and Base PROB-FEAT-EXIST-BTW -SCREW -1-COV ER No helping feature betw een Screw an d Cover PROB-MATING-BASE-COVER-LIA1SON Expensive m ating type between Cover an d Base PROB-NON-NECESS-PT-BASE Base m ay be m erged PROB-NON-NECESS-PT-COVER Cover m ay be m erged PROB-STANDARD-BASE Base is not a stan d ard p a rt PROB-STANDARD-COVER Cover is n o t a stan d ard p a rt PROB-GRASP-SFC-SCREW -1 No grasping surface on Screw Table 5.1: DFA Problem s generated for th e three p art container exam ple (Figure 4.2). 39 {PROB-MATING-6932 :IS-A = (PROBLEM) :PR-TYPE-1 - MATING :PR-TYPE-2 = TIME :PR-TYPE-3 * MODERATE :PR-TYPE-4 ■ RULE-4 :TARGET-TYPE2 = (SCREWING) :TARGET-TYPE1 « (LIAISON) :PROPERTY = :TYPE :PROBLEM-OF = (BASE-COVER-LIAISON) :FUNCTIONAL-IMPORTANCE = (ASSEMBLY-FN) :DESCRIPTION = "Mating op exceeds the preferred time bound." :WEIGHT - 0.7 :RESPONSIBLE-DSGN-ACTION » SELECT-FORM > Figure 5.2: Exam ple of a problem representation. O ther indices or problem attrib u tes include th e problem atic design object and th e specific problem atic attrib u te. Also a very im portant index is th e probable design action type th a t is responsible for producing th e problem. These are the sam e four types of design action types used for th e describing design rationale (see Table 6.2). This inform ation m aps problem s to th e portions of th e design plan th a t are responsible for th e problems. T he first three problem types {problem-type-1, problem-type-2, and problem-type- 3) can have different weight (on a scale betw een 0 to 1) assignm ents, depending on their seriousness and im portance, which can be varied by the user. T he to tal penalty score (PS) is sim ply a weighted sum of the problem types, th a t is: p s - ' E uh • Pi, i~ l where, w, • represents the weight of problem type i, pt represents num ber of prob lems w ith problem type i, and n is th e to tal num ber of problems. T he objective of R EV -EN G E, therefore, is to reduce th e to tal penalty score as m uch as possible. Table 5.1 lists all th e problem s generated by A-EX for the three 40 P r o b le m A n a l y s i s Sum m ary: Figure 5.3: A problem sum m ary panel of DFA analysis result for th e three p art container exam ple. There are three categories or dim ensions of analysis, and each subcategory carries a different weight according to user specification. T he overall score (or penalty) is shown in th e lower right corner. p a rt container exam ple (see Figure 4.2). Figure 5.3 shows a problem sum m ary of an analysis result for th e same exam ple. There are to tal 10 DFA problem s th a t are identified w ith a total penalty score of 25.8 (lower right corner of th e figure). 41 Chapter 6 Design Plan Construction In REV -EN G E, direct knowledge acquisition is not th e only process for design cap ture. As a tool for redesign assistance, R EV -EN G E attem p ts to autom atically infer the design plan of a given design [42]. Design plans are of great im portance as redesign, in R EV -EN G E, is m odeled after a process of replay and modify. A com plete specification of a design plan through user interaction is difficult, because one would have to identify all plausible design actions and their interrelationships, and replay them concurrently in one’s m ind. Instead, R EV -EN G E assists designers by assum ing the role of design plan construction. 6.1 Design Plan In general, a design plan refers to an ordering (linear or partial) am ong various design actions which lead to th e creation of a given design. One straightforw ard design m ethod is by redesign, replaying a design plan of a sim ilar product. Similarly, one effective way of redesign is to replay th e design plan of th e initial design. Replay refers to an act of presenting a stored ordered sequence of design decisions and design actions perform ed in a course of a previously com pleted design process. It could refer to a series of CAD system screens illustrating interm ediate stages of design, or even to re-exam ination of a series of drawings and associated text. T he effectiveness of a replay m echanism depends on th e extent of th e knowledge represented by the design plan [57]. For a m ore effective replay m echanism , a design plan m ust be augm ented w ith th e rationale for each design action and its order. 42 For exam ple, the knowledge of design rationale can be used to validate proposed redesign and prune off unreasonable, yet possible, redesign possibilities. T he level of specificity is also im portant, not only for its effectiveness for redesign b u t also for the feasibility of construction. An overly specific design plan is difficult to construct because it requires scheduling of a large num ber of design actions at a very detailed level, which are often very dom ain and product specific. Also its specificity m ay introduce superfluous knowledge not necessarily required for a given redesign task. On th e other hand, an overly general design plan m ay be easier to construct, b u t would not be a useful basis for redesign. Therefore, th e level of specificity of a design plan for redesign m ust be chosen somewhere at th e m iddle of th e spectrum . At an appropriate level of specificity, a set of design actions can be predefined for a chosen domain. A design plan serves as th e central d ata stru ctu re in R EV -EN G E for th e following reasons. F irst, a design representation in term s of a design plan provides a way of redesigning by derivational analogy [15], i.e. by th e replay and m odify paradigm . In derivational analogy, the problem solving th a t leads to a design is reused to find a design solution to new problem . By viewing and m anipulating w ith the design plan, a b ird ’s eye view of interdependencies am ong various com ponents of th e design can be revealed. This feature provides a good validation scheme for achieving a “global” redesign solution. Secondly, a design problem can now be associated w ith a specific design action at a particular design stage. This is an im provem ent over th e conventional approach where a design problem is associated only w ith th e actual physical design com ponent rath er th an its derivational process. By associating problem s w ith th e design process, a m ore detailed redesign advice can be m ade, since a design decision specific to a problem atic a ttrib u te of th e design object is identified. T hird, th e stru ctu re of a design plan m ay act as a heuristic to solving constraint satisfaction problem s th a t often originate as subproblem s during redesign. T hree possible ways to construct a design plan are to (1) construct it m anually, (2) record the design process, or (3) have th e system infer it w ith strong dom ain knowledge. R EV -EN G E constructs a default design plan (vs. a tru e design plan) by ordering design actions using a fixed design process m odel, and augm enting it w ith local design rationale. 43 Types of C onstituents Exam ples Descriptive O bjects Physical p arts, features, CSG Tree C onceptual function, dimensions R elations has-parts, has-function, feature-of Derivational O bjects Design Explanation “selected force-fit for easy m ating operation" “can ’t p u t a slot because unreachable by interference” Design Specification “requires 5 N of force” Design Conjecture “assum ed cham fer is for easy insertion” Relations spec-of, explanation-of, has-rationale Table 6.1: Exam ple constituents of a design state. 6.2 Design Plan Construction Process 6 .2.1 D e sig n P la n R e p r e se n ta tio n A design can be viewed as a sequence of state transitions, w here at each design state, th e next design action is determ ined and applied, increm entally satisfying various types of constraining design inform ation such as design constraints, design specifications, and design rationale. Design actions are continuously applied until an acceptable design state is reached. A design state consists of a set of objects and facts or assertions about these objects, and represents a certain stage in the evolution of th e design to its accepted form. A design sta te includes two types of design inform ation (see Table 6.1 and Figure 6.1). One is th e descriptive inform ation about th e final design o u tp u t as realized in conventional CAD drawings and d a ta bases. T he other is the deriva tional inform ation such as design rationales, and design constraints which reflect the process of design. In REV -EN G E, a design plan is defined as a sequence of design actions and design states associated w ith them , rath er th an ju st a sequence of design actions alone. A default design plan is a design plan constructed using default knowledge. D e fin itio n 1 (D e sig n P la n ) A Design Plan is defined as a 5 tuple, D — (S, A, T, S q, S p ), where, (1) S is a nonem pty finite set o f design states, (2) A is a nonem pty finite set o f design actions, (3) T is a function which maps S x A into S (next-state function), (4) Sq is the start state, and 44 Design Action: add-feature (hole) & Derivational: d < 5 mm wood for quality mate to part-5” “use symmetry for DFA Descriptive: block (10,20,50) part_name: slab-1 material: wood Descriptive: block (10,20,50) part_name: slab-1 material: wood hole_diam = 5mm hole loc = center Derivational: d < 5 mm wood for quality mate to part-5 h o le lo c = center for symmetry Current Design State New Design State Figure 6.1: An exam ple of design states and a design action. D escriptive design objects are used as param eters for design actions. B oth descriptive and derivational objects m ay be brought into existence by an application of a design action, or by deliberate introduction by the planner consistently w ith other design states. 45 Types of Design Stage Design Actions Synopsis Conceptual create-function Create a function and determine type of function (e.g. primary, secondary, etc.) Function-to-form mapping create-form Create a physical part, feature, etc. corresponding to the functions Embodiment select-form Determine various aspects of parts features, etc., such as approximate size type of mating, approximate shape, etc. Detailed detail-form Finalize design by determining more detailed aspects of design such as material, tolerance, exact dimension, etc. Table 6.2: Exam ples of design actions in the “Design Space.” (5) Sp is a set o f final states or acceptable design instances. D efin ition 2 (D efau lt D esign P lan ) A default design plan is a design plan con structed, at least partially, using default knowledge. Default knowledge refers to design information that can not be confirmed to be true at the time of the construc tion. Possible design actions are predefined at an appropriate level of specificity, called th e “Design Space.” T he design actions in th e “Design Space” (see Table 6.2) are useful because they are applicable to a variety of m echanical engineering domains, yet sufficiently specific to describe interesting redesign strategies. Design actions in th e “Design Space” do not reflect m uch geom etric detail. An alternative approach to describing th e design plan at a higher level of specificity (e.g. in term s of low level geom etric design actions) is difficult, since a complex geom etric reasoning capability is required, and high-level redesign strategies can not be effectively expressed w ith a series of geom etric design actions. M any DFA redesigns m ay still be inferred and described w ithout m uch geom etric reasoning. Therefore, th e “Design Space” is defined above th e level of geom etric details. T he design plan in th e Design Space, therefore, m ay not necessarily be geom etrically feasible. 46 Design n a n Default Initial Design Slate .SeLofJ)eslgn.Actlons; N, create-function creaf e-form select-assembly-method Descriptive Design Inform atioir CAD data Part Data Feature Data Derivational Design Information Design Rationale . Des ign Constraints Design Specifications (Acquired) Final Design State O Design State | Application of Design Action Mapping (Search) Local Heuristics \ Global z Heuristics | (PDM) Figure 6.2: C onstruction of a design plan. 6 .2 .2 D e sig n P la n C o n str u c tio n Figure 6.2 illustrates a construction process of a default design plan. A t th e sta rt of th e construction process, there are three types of design inform ation available. F irst is th e descriptive design inform ation available from CAD drawings and engineering databases. T he second is the derivational design inform ation th a t is acquired from th e user through th e knowledge acquisition stage, or by autom atic system inference. T he th ird ty p e of design inform ation is a set of predefined design actions. A heuristic construction algorithm proceeds by selecting and scheduling probable design actions, and constructing design states associated w ith them . T he construction starts from a default initial design state, and ends at a final state w here all of design objects and design inform ations have been accounted for. T he com plexity of th e design plan construction process is 0 ( n 2), w here n repre sents th e num ber of objects th a t are being designed and their properties (In REV EN G E, they are functions, parts, liaisons, features, and th eir attrib u tes.). This is because only one p ath out of a finite search space is chosen. T h at is, selecting a 47 design action one at a tim e is analogous to designing and determ ining each property of a design object one at a tim e. Every tim e a design decision is m ade, there are one less design object on which a design action is to be perform ed. Therefore, the com plexity can be com puted by: n + (n - 1) -f (n - 2) -f ... -f- 2 -f- 1 = 0 ( n 2). 6 .2 .3 D e sig n P la n C o n str u c tio n H e u r istic s 6.2.3.1 P rescrip tive D esign M odel (G lobal H eu ristics) By observing engineering designers, design researchers have worked on system atizing th e process of design by identifying sequences and p attern s of events th a t are, by and large, common to all design projects. For exam ple, while certain types of design actions are applied early in design, others are applied later. Designers rarely reason about physical forms before functions. Also, features are usually added after parts are created. Such a design process m odel is called the Prescriptive Design Model (PD M ) [20]. T he assum ption of the PD M is th a t, if followed, it will result in a b etter design and in shorter tim e [34] [5] [67] and perhaps a design easier for m odification. Figure 6.3 shows a typical PDM . Typically, a PD M is highlighted by following features: (1) gradual refinem ents of design from sketches to detailed designs, (2) priorities on types of target objects by their functional im portance (e.g. m ain, auxiliary, assembly, special, etc.), and (3) an explicit separation betw een form design and layout design. For exam ple, following a PD M , a designer, following a PD M , m an design design com ponents th a t are im portant w ith respect to the m ain function of th e product first, m ay sketch th e overall design instead of designing one p art to its finest detail, or m ay finish designing th e forms of each p art before proceeding to consider how to assemble them . Designers, in practice however, usually design in a depth-first m anner, working on some p art of th e design to its finest detail before moving to another p art of the design space. In such depth-first m odels, it is difficult to m ake changes because of th e am biguous tem poral and causal relationship betw een the design actions. In the PD M , each refinem ent level is m ore clearly segregated which lends itself to easier m odification. Since a design plan to arrive at a particular instance of a design is not 48 r Clarification of Task > - Collect Information about Requirements and Constraints - Elaborate Detailed Specifications V 1 r Conceptual Design - Establishment of Function Structure - Search for Solution Principles - Map Function to Conceptual Form V ) \ r Embodiment Design - Map Conceptual Form to Physical Form - Preliminary Assembly Layout K ) \ r Detailed Design - Final Details on Form and Layout - Optimizations K J Figure 6.3: A Prescriptive Design M odel (PD M ) [5] [67] [34]. 49 necessarily unique, it is conjectured th a t it is possible to construct a default design plan of a design using th e PD M . For exam ple, if certain portion of the design m ust be undone to a coarser design level for reexam ination, then, in accordance w ith the PD M , other p arts of the design will be taken back to the same coarser level as well. T he coarser th e design level, th e m ore room there is for change in term s of satisfying various design constraints. In constructing a design plan for reverse engineering, since the original design process is assum ed to be unknow n, th e principles of PD M along w ith available design inform ation are used to select and schedule probable design actions and construct a default design plan. The PDM is used as a default design process m odel, since it is a general dom ain independent design model applicable to m any dom ains. For exam ple, while the PD M m ay place an ordering betw een certain classes of design actions (e.g. conceptual vs. detailed, those related to parts vs. those related to features, etc.), th e local heuristics are used to place an ordering betw een design actions w ithin a class (e.g. those related to feature-1 vs. those related to feature-2). 6 .2 .3 .2 L o c a l H e u ris tic s Orderings among design actions w ithin same design stage are determ ined by a heuris tic which utilizes related available design inform ation (e.g. type of design objects, num ber of specifications, num ber of constraints, types of constraints, num ber of stru ctu ral neighbors, types of stru ctu ral relationships, etc.). T he underlying con cept is analogous to using the “am ount of inform ation” heuristic in solving constraint satisfaction problem s (which design is often viewed as). T h a t is, for exam ple, in a constraint satisfaction problem , a variable w ith more conditions or constraints (i.e. inform ation) is usually attem p ted to be satisfied first ahead of others. If there is no t applicable knowledge available, an arb itrary ordering is used. T he ordering may be, overridden by an explicit specification by th e user as well. I 6 .2 .4 Im p le m e n ta tio n { T he planner is im plem ented using Prodigy, a general purpose problem solver based! on idealized rational intelligence [56]. Im plem enting the planner with Prodigy offers m odularity and ease of developm ent. In Prodigy, the descriptive and derivational 50 ( i s - a b a s e p a r t ) ( h a s - f e a t u r e b a s e b a s e - h o l e ) ( i s - a b a s e - h o l e f e a t u r e ) ( t y p e b a s e - h o l e h o l e ) ( i s - a b a s e - f l f u n c t i o n ) ( ty p e b a s e - f l m ain) ( i s - a s p e d s p e c ) ( s p e c - o f s p e d b a s e - f l ) ( t y p e s p e d c r e a t e - f u n c t i o n ) ( t y p e s p e d s e l e c t - f o r m ) ( d e s c s p e d "volum e > 50 c u b ic " ) b a s e i s a p a r t b a s e h a s a f e a t u r e b a s e - h o l e b a s e - h o l e i s a f e a t u r e b a s e - h o l e i s a h o le b a s e - f l i s a f u n c t i o n b a s e - f l i s a p r im a r y f u n c t i o n s p e d i s a s p e c i f i c a t i o n s p e d i s sp e c o f b a s e - f l s p e d a p p l i e s t o c r e a t i o n o f b a s e - f l s p e d a p p l i e s t o fo rm s e l e c t i o n to o t e x t u a l d e s c r i p t i o n o f s p e d Figure 6.4: Exam ple of a design description in Prodigy D escription Language (PD L). design inform ation is used as the sta rt state, while design actions are realized as operators. T he heuristic algorithm is im plem ented using P rodigy’s search control rules. T he goal is specified so as to create and schedule design actions for all design objects present in the design description. T h at is, Prodigy uses th e search control rules to select and schedule appropriate design actions to realize the given goal. A sta rt state represents a description of a design. A design is represented origi nally in fram es (see C hapter 4), then translated into Prodigy D escription Language (predicate logic type of expression). Exam ples of PD L predicates are shown in Figure 6.4. Figure 6.5 shows an exam ple of a design action create-main-function (a design operator th a t creates a function for a design com ponent of prim ary function of the product) realized as a Prodigy operator. T he preconditions specify conditions in which the design operator is applicable. T he effect is to justify th e design action and assign an ordering. Figure 6.6 shows exam ples of various search control rules. For exam ple, the goal preference rule use-explicit-override has the highest priority among the goab preference rules, and is used to indicate preference for design of an object th a t has explicit override constraints first. For exam ple, a constraint, (precede part-1 form part-2 function), specifies to design the form of part-1 ahead of the function of part-2, even though this, in general, violates the prescriptive design process model. 51 Search control rules w ith th e next highest priorities im plem ent th e prescriptive design process model. For exam ple, th e control rule create-function-first specifies th e design of functions first over conceptual forms or shapes. If any of above rules are not applicable, then the last default heuristic rules (local heuristics) are used which places ordering on design actions based on th e num ber of specifications and structurally neighboring parts of th e target object (see default-rule-1 and default- rule-2 in Figure 6.6). Shown in Table 6.3 is a linear default design plan generated by the system for th e three p art container exam ple Figure 4.2). T he sam e design plan is shown in a justification stru ctu re in Figure 6.7, and as a graph in an X window in Figure 6.8. In Figure 6.7, each circle and square correspond to some type of design action or design inform ation. A design action is justified by another set of design actions or design inform ation. T he num erics correspond to the ordering of the design plan in Table 6.3. 52 Order Design Action Design object 1 CREATE-MAIN-FUNCTION BASE-F1 2 CREATE-MAIN-FUNCTION COVER-FI 3 CREATE-MAIN-FORM BASE 4 CREATE-MAIN-FORM COVER 5 CREATE-ASSEMBLY-FUNCTION CONNECT-BASE-COVER 6 CREATE-ASSEMBLY-LIAISON BASE-COVER-LIAISON 7 SELECT-MAIN-FORM BASE 8 SELECT-MAIN-FORM COVER 9 SELECT-ASSEMBLY-METHOD BASE-COVER-LIAISON 10 CREATE-ASSEMBLY-FORM BASE-HOLE 11 CREATE-ASSEMBLY-FORM COVER-HOLE 12 CREATE-ASSEMBLY-FORM SCREW-1 13 SELECT-ASSEMBLY-FORM BASE-HOLE 14 SELECT-ASSEMBLY-FORM COVER-HOLE 15 SELECT-ASSEMBLY-FORM SCREW-1 16 DETAIL-MAIN-FORM BASE 17 D ETAIL- MAIN-FORM COVER 18 DETAIL-ASSEMBLY-FORM BASE-HOLE 19 DETAIL-ASSEMBLY-FORM COVER-HOLE 20 DETAIL-ASSEMBLY-FORM SCREW-1 Table 6.3: A default design plan generated for the three p art container in tex t by REV -EN G E. j I I * 53 (CREATE-MAIN-FUNCTION create a function if there is a function unaccounted and its type is main then create design action for it justification is just itself plus any other specs update ordering link signal goal accomplishment (params (<f> <da>)) (preconds (and (is-a <f> function) (type <f> main) (get-design-action-name create-function <f> <da>) (last-design-action <lda>))) (effects ((add (is-a <da> design-action)) (if (and (spec-of <sp> <f>) (type <sp> create-function)) (add (justifies <sp> <da>))) (add (target <da> <f>)) (add (type <da> create-function)) (add (designed <f> function)) (del (last-design-action <lda>)) (add (last-design-action <da>)) (if (last-design-action nil) (add (is-a start-action <da>))) (if (~ (last-design-action nil)) (add (has-next-action <lda> <da>)))))) Figure 6.5: An exam ple of an Prodigy operator for expressing a design action. (USE-EXPLICIT-OVERRIDE (priority 0) ;;; order those first with explicit override constraint (lhs (and (current-node <node>) (candidate-goal <node> (designed <ol> <pl>)) (candidate-goal <node> (designed <o2> <p2>)) (known <node> (precede <ol> <pl> <o2> <p2>)))) (rhs (prefer goal (designed <ol> <pl>) (designed <o2> <p2>)))) (CREATE-FUNCTIOW-FIRST ;;; prefer function creation over other unless it is assembly ; ; ; prefer over anything (priority 2) (lhs (and (current-node <node>) (candidate-goal <node> (designed <ol> function)) (candidate-goal <node> (designed <o2> <p2>)) (known <node> (~ (type <ol> assembly))))) ! (rhs (prefer goal (designed <ol> function) (designed <o2> <p2>)))) (DEFAULT-RULE-1 ;;; prefer to design object with more specs (priority 10) (lhs (and (current-node <node>) (candidate-goal <node> (designed <ol> <pl>)) (candidate-goal <node> (designed <o2> <p2>)) (known <node> (compare-no-of-specs <ol> <o2>)))) (rhs (prefer goal (designed <ol> <pl>) (designed <o2> <p2>)))) (DEFAULT-RULE-2 (priority 10) ; ; ; prefer to design object with more structural neighborhoods (lhs (and (current-node <node>) (candidate-goal <node> (designed <ol> <pl>)) (candidate-goal <node> (designed <o2> <p2>)) (known <node> (compare-no-of-nbhds <ol> <o2>)))) (rhs (prefer goal (designed <ol> <pl>) (designed <o2> <p2>)))) Figure 6.6: Exam ples of a PDL search control rules. 55 create-function /•— -v (base) ( 1 ) create-form (base) Specification- “container must not be circular” select-form , , (base, rectangular) f ? select-form (cover, rectangular Q design action 0 design information V justification external view cross section Original Design of Container 3 4 reate-function O O ( T ) W reate-form create-1 (cover) 7 8 /•"^.create-function ( 5 Xconnect-base-cover) create-form base-cover-liaison) (connect-base-cover, screwing) select-assembly-method create-form (base-hole) ( io select-form (base-hole, circular) create-form r-hole) ._reate-form 12 Yscrew) select-form (cover-hole, circular) select-form (screw, circular) Figure 6.7: A default design plan of a three p art container shown in a justification structure. 56 ^AV»VAVi VAV«V»V. ‘ . V t V A V /«A M O p M t-st-iC o b j » ib f r j& M & A a o K u h c j - t i v u }-C Figure 6.8: A default design plan of a three container shown in a REV -EN G E window. T he scrollable window shows the first three stages of design w ith 5 design actions. i i * i Chapter 7 Case-based Design Modification T he final stage of reverse engineering is design m odification. Design m odification in R EV -EN G E is based on a case-based m ethod. T he im portance of cases has long been recognized in design problem solving. In DFA, previously successful re design cases play an im portant role as well, since m any of the redesigns occur by applying and adapting a small set of “rules of th u m b ” such as those shown in Ta ble 7.1. Therefore, th e case-based redesign m ethod is especially appropriate for DFA by being psychologically realistic, and by not requiring a com plete underlying m odel of th e target design. Note th a t some of th e DFA rules, by them selves, are not am enable to straightforw ard application, because there exist p otential conflicts am ong design rules them selves, and w ith other factors such as m anufacturing costs, function, etc. For exam ple, the DFA rule no. 8 (designing an orienting surface) m ay conflict w ith th e DFA rule no. 5 (use sym m etrical parts) because the orienting, surface m ay introduce asym m etry. DFA rule no. 2 (design a stacked product) m ay significantly increase th e m anufacturing cost, even though it m ay reduce the assem bly cost. W hether or not these conflicts present a significant problem depends on each particular circum stance of the redesign at hand. To provide b ette r insights into solving such potential conflicts and to b etter anticipate their side effects, cases mustj include, among others, th e side effects of the proposed solution and explanation ofj those side effects. T he procedure of case-based redesign is sum m arized in Figurej 7.1. Briefly, case-based redesign proceeds by first selecting a problem to attack, re-J trieving candidate cases to solve it, selecting a case and validating its applicability,1 adapting the case to current situation and, then, executing the redesign. 58 Validate Applicability Establish a Match Select Next Problem Retrieve Candidate Cases Execute Redesign Select a Case Adapt Selected Case Failure A: Change Design Information and Continue Failure B : Select a New Case Figure 7.1: Case-based Redesign. 1. Reduce num ber of parts. 2. Design a stacked product. 3. Design a good base com ponent. 4. Use easy m ating m ethod. 5. Use sym m etrical parts. 6. If p arts can not be sym m etrical, use increased asym m etry. 7. Provide m eans to easily grip and hold th e part. 8. Design particular orienting surfaces. 9. Avoid p arts th a t tangle, nest or topple. Table 7.1: Exam ples of DFA rules. 7.1 Problem Solving Strategy W hile a case-based m ethod is used to solve each individual DFA problem , a prob lem solving strategy from a global point of view is needed. T h a t is, as the goal of R EV -EN G E is to help solve as m any problem s as possible, a global problem solving; strategy is needed to m anage possible problem interactions. Problem interaction refers to the phenom enon th a t solving one problem can either introduce a new prob lem , or elim inate an old problem. T he goal of the global problem solving strategy! can be form ally stated as below. G iv e n , a design state, D o, with a finite number o f problems, p \, P2 , ■ ■ ■ , i pn, and penalty score, Si, associated with eachpi, h e lp fin d a new design state, D n , to m inim ize the overall penalty score, m i = l where, m represents the new number o f problems in Djy. I One m ethod to avoid th e Frame problem [63] is to perform a new analysis every! tim e a case has been applied to solve a problem . This corresponds to popping outj of th e “inner loop” of design (see Figure 3.1). T h at is, a redesign advice can be generated for solving one problem , which a user can follow to realize a new design^ geom etrically. A design verification and assem bly planning are followed before per form ing a new analysis, which could produce new DFA problem s a n d /o r elim inate 60 old DFA problem s stem m ing from th e design change. A lthough this is an accept able m ethod for dealing w ith the Frame problem, this involves repetitive stages of tim e consuming and expensive procedures of design verification, assembly planning, geom etric design realization, and DFA analysis every tim e a single problem is solved. An altern ativ e-is a “batch” approach where solutions to as m any problem s as possible are attem p ted before popping out of the “inner loop.” T he Frame problem is handled first by augm enting the case-based redesign process w ith a capability to invalidate problem s th a t are related to the problem currently being solved. However, it is not straightforw ard to also include a capability to produce new problem s on the fly, while solving the problem at hand. This is because generating new problem s is not possible w ith a description of high level redesign advice, b u t rath er requires new geom etric details and a new assem bly plan. In other words, it requires popping out of the “inner loop.” Therefore, th e case-based m ethod m akes an assum ption th a t a proposed solution at least will not m ake the situation worse, even though there m ay be new problem s generated due to th e proposed redesign. T he assum ption is form ally stated as below. A s s u m p tio n 1 (T ra d e o ff) n m i= l i= l where, m represents the new number of problems after applying a redesign case to a design state with n problems. This assum ption is fairly reasonable in so far as th e appropriate redesign cases are stored in th e case base. T h at is, R EV -EN G E m ust m ake sure th a t only successful redesign cases w here above assum ption tu rn s out to be tru e are either stored orj used. This way, th e user can continue to a tte m p t to solve th e rem aining problems.| t W hen all th e problem s are attem p ted to be solved, th e user can pop out of the “inner loop.” This m ethod not only is much m ore efficient, but also has much m ore resem blance to th e way hum an designers redesign, trying their best to address as m any problem s as possible before reevaluating th e proposed redesign. REV EN G E, as a design aid, allows both alternative approaches. 61 7.2 Problem Mapping and Selection Design problem s identified by an analysis tool m ust m ap to some portion of the design plan w here th e problem m ight have originated. A fter a default design plan is generated, problem s are autom atically m apped to corresponding responsible design actions by A-EX, the R EV -EN G E DFA analysis expert system described in C hapter 5. T he analysis rules (explained in C hapter 5) associate each DFA problem w ith a p articu lar problem atic design object and a probable type of design action th a t m ight be responsible for them . For exam ple, if th e analysis result shows th a t th e problem lies w ith the type of m ating betw een p art A and p art B, then it should m ap to a design action, e.g. select- assem bly-m ethod(A, B, screwing)1, in the design plan which represents a selection of m ating types betw een p art A and p art B. Design Plan Part A PartB select-form (A, form-A) Analysis Results: select-form (B, form-B) 1. Mating between Part A and Part D reau im Reorientations due to Instability in Part A. select-assembly-method (A, B, screwing) 2. Mating between Part A and Part ITrequires a Holding Device for the Screwing Operation. Type between Part A and Part B is Expensive. 3. Mating Figure 7.2: M apping DFA analysis to the design plan. 1 S e le c t-a s s e m b ly -m e ih o d is a subclass of a design action type of select-form (see Table 6.2). 62 T here are three types of m appings. The first type is the sim plest, one-to-one m apping, w here a single design action is determ ined to be responsible for the problem as illu strated w ith analysis result 3 in Figure 7.2. T he second type is the m any-to-one m apping w here a single design action is responsible for m ore th an one DFA problems. This is illu strated w ith analysis results 2 and 3 which m ap to a single design action in Figure 7.2. T he last type of th e m apping is the one-to-m any m apping, where a single problem m ight have originated from conjunctive or disjunctive sets of design actions. In Figure 7.2, analysis result 2 is m apped to a set of two disjunctive design actions. T h a t is, analysis result 2 m ay be solved by m odifying either select-form,(A, fo rm -A ) (e.g. by changing the form so th a t it does not require a holding device), or select-assembly-method(A, B, screwing) (e.g. by changing th e type of m ating so th a t it does not require a holding device). To be com plete, there are also types of problem s th a t are caused by “m issing” design actions, i.e. design decisions th a t should have been m ade b u t were forgotten. For exam ple, one popular m ethod of enhancing th e assem blability of a design is to add guiding features (e.g. stops, chamfers, dim ples) for easier alignm ent or insertion of parts. Problem s th a t can be solved by adding new features can not be associated w ith a design decision since there is no design decision responsible for “n o t” creating these features. These problem s are m apped to a particular stage of design instead (see m iddle p art of Table 7.2). W hen there exist m ultiple problem s, those th a t m ap to th e earlier portion ofj th e design plan are attacked first, since th eir effect on the overall design is regardedj m ore im portant. Problem s th a t m ap to early or m iddle stages of a design plan could require global designs, because fixes m ade in those stages m ay have significant effects on th e following design stages. For exam ple, a change in a function stru ctu re may elim inate a p art, which could have ripple effects on th e design of other p arts in its neighborhood. On the other hand, problem s th a t m ap to later stages of a design! plan usually are local design problem s. For exam ple, slight dim ensional changesj are usually possible w ithout affecting the whole design. W hen there are m ultiple problem s m apped on a same portion of th e design plan, th e problem w ith a higher penalty score (m ore serious) is recom m ended attacked first. In this view point, a replaying m echanism offers a good system atic m ethod of redesign, because when there exist m ultiple design problem s, an ordering on which i S c S a ^ & a ia ii^ ^ Figure 7.3: Problem s m apped to portions of th e design plan. | problem to solve first is readily available by m apping each design problem to thej corresponding portion of the design plan. Also, th e redesigner has m ore insightsj into th e interaction, possibly harm ful, am ong th e m ultiple problem s. Table 7.2 shows DFA problem s generated for the container exam ple (see Table 5.1) m apped to th e design plan "(see Table 6.3). These types of problem s should be selected to be attacked after all other problem s associated w ith design actions in the sam e design* stage are solved or considered. R E V -EN G E allows the user to view th e problem s m apped on th e design plan* and select th e problem s to be solved by clicking (w ith a mouse) on a specific problem^ th a t is shown on th e subm enu of th e highlighted problem atic design action. T he highlighted node in Figure 7.3 represents th e problem atic design actions. Usually] I as a default rule, problem s th a t occur earlier in the design plan are recom m ended to be attack ed first. It is easy for the user to select problem s according to this^ criterion since the layout of th e design plan (w ith m apped problem s) is visually provided through th e user interface. If there are m ultiple problem s associated w ith a single design action, then th e default rule is to select the problem w ith m ore R EV -EN G E allows th e user to view th e problem s m apped on th e design plan and select th e problem s to be solved by clicking (w ith a mouse) on a specific problem th a t is shown on th e subm enu of th e highlighted problem atic design action. T he highlighted node in Figure 7.3 represents th e problem atic design actions. Usually, as a default rule, problem s th a t occur earlier in th e design plan are recom m ended to be attacked first. It is easy for the user to select problem s according to this criterion since the layout of th e design plan (w ith m apped problem s) is visually provided through th e user interface. If there are m ultiple problem s associated w ith a single design action, then th e default rule is to select th e problem w ith more weight (or im portance). T he weight of the problem is calculated by a weighted sum of user adjustable param eters. However, th e user is allowed to override any problem selection criteria. R EV -EN G E then allows th e user to retrieve and select a previous redesign case and adapt it to the current problem , through w hat is called, th e case-based redesign workbench (see Figure 7.3). 7.3 Case Representation and Retrieval Table 7.3 shows an exam ple of a redesign case. This particular exam ple is a case where screwing was replaced by a force-fit, guided by a popular DFA rule, “avoid using screws.” T he redesign cases are indexed by various aspects of th e problem th a t th e case solves (e.g. m ating problem , handling problem , m oderately serious problem , etc.), the types of design action th a t are relevant (problem in function! creation, problem in feature creation, problem in selecting m ating m ethod, etc.), the types of design objects in question (e.g. problem w ith p art, problem w ith feature,' etc.) and other indices. T he case also provides the actor list, add list, and delete list, expressed in predicate logic, for prescribing the redesign process. T he actor listj specifies design objects th a t appear in th e “script” of the redesign process. T he add list and delete list specify objects th a t are being introduced and w hat objects are being elim inated from th e current design. There is also a precondition list and aj side effect list, both represented in tex t, for th e user to view for m anually validating th e application of the case. The cases provide not only DFA redesign tactics, butj also th eir side effects such as im pacts on m anufacturing cost, serviceability, incurring constraints, etc., and th eir explanation. Therefore, although redesign in R E V -EN G E 65 Case 40 I n d e x E x a m p le Value Problem T ype 1 problem with m ating Problem T ype 2 problem with tim e of assembly operation Problem T ype 3 m oderate seriousness Problem T ype 4 DFA rule 1, DFA rule 2 Problem atic Design Action select-assem bly-m ethod Problem atic O bject Type assembly liaison Problem atic O bject Property m ating type Problem atic O bject Value screwing Functional Importance assembly function DFA Rule “use easier m ating m ethod” Description “replace screwing m ating with less expensive force fit m ating” Precondition List “clearance for force-fit features” “must be m ade of m alleable m aterials” Actors screw-1 (:is-a screw-1 part) (:type screw-1 screw) ... nut-1 (:is-a nut-1 part) (:type nut-1 nut) ... hole-1 (:is-a hole-1 feature) (:type hole-1 hole) ... Rem ove List screw-1, nut-1, hole-1, hole-2, ... Add List force-fit-1 (:is-a force-fit-feature-1 feature) ... Positive Effect List “reduction in number o f parts” Negative Effect List “increase in manufacturing cost” “m ating is less tight” Table 7.3: An exam ple of a redesign case. is centered around th e criteria of DFA, other design factors are taken into account to some extent. A case is retrieved based on a sim ilarity m etric. T he sim ilarity m etric measures' th e sim ilarity between the redesign situation of the currently given problem and th a t of the stored cases. The sim ilarity m etric currently is a sim ple weighted sum of m atching indices. T he m ost im portant m atch in retrieving a case is the m atch betw een features of th e currently selected problem , and features of the problem th e stored cases i solve. Therefore, for instance, the exam ple case in Table 7.3 is a good candidate for problem s generated by DFA rule-5 in C hapter 5, since there are m any m atching features {problem-type-1, problem-type-2, etc.). 66, C a n d id a te l i s t ( 1 . 0 C a n d id a te l i s t ( 2 .0 C a n d id a te l i s t ( 2 .2 C a n d id a te l i s t ( 3 .2 C a n d id a te l i s t ( 5 . 4 C a n d id a te l i s t ( 5 .9 (CASE-40 1 .0 ) (CA SE-37 (CASE-40 2 . 0 ) (CA SE-37 (CASE-40 2 . 2 ) (CA SE-37 (CASE-40 3 .2 ) (CA SE-37 (CA SE-40 5 . 2 ) (CA SE-37 (CA SE-40 5 . 7 ) (CASE-37 1 .0 ) (CA SE-36 0 .0 ) 2 . 0 ) (CA SE-36 0 .0 ) . . . 2 . 2 ) (CA SE-36 0 .2 ) 3 . 2 ) (CASE-36 0 .2 ) 3 . 9 ) (CA SE-36 0 .9 ) 3 . 9 ) (CA SE-38 3 .9 ) S o r t i n g . . . C a n d id a te l i s t ( 5 . 9 (CASE-40 5 .7 ) (CA SE-29 5 .7 ) (CA SE-24 5 .7 ) . . . Figure 7.4: Traces of retrieval of cases in REV -EN G E. Cases Score Description Case 40 5.7/5.9 Replace screwing with force-fit Case 29 5.7/5.9 Replace screwing with simple insertion Case 24 5.7/5.9 Replace screwing with snap fits Case 23 5.2/5.9 Use deep grooves and insert parts from the top instead of inserting the shaft through the holes Case 27 5.0/5.9 Assemble components on shaft by clipping instead of inserting shaft through the hole Table 7.4: Redesign cases th a t are retrieved for solving “expensive m ating ty p e” problem (P R O B -M A T IN G -B A SE -C O V E R -L IA ISO N ) for th e container exam ple. T he sim ilarity is m easured, given a problem description, over all th e stored cases, and th en th e cases are ranked accordingly. Shown in Figure 7.4 is a trace of R E V EN G E calculating m atching scores for each case in th e case base, and finally ranking them . The score in th e beginning of the list is the m axim um score at th a t particular stage of th e m atch. T hen, an arb itrary threshold value is used to reduce the candidate set to a m anageable size for a final user selection. Table 7.4 shows th e top five redesign cases retrieved for solving P R O B -M A T IN G -B A S E -C O V E R -L IA IS O N (see Table 5.1). 67 7.4 Redesign Validation T he procedure of validating each redesign corresponds to th e problem of making sure th a t newly introduced design knowledge is consistent w ith th e already existing design knowledge: th a t is, th e set, R n - R o , should be “consistent” w ith So and R o (see Figure 3.1). A case is first selected to be applicable only based on th e m atch score between surface features of th e current problem and th e stored cases. T he final selection is m ade by the user, since th e sim ilarity m etric is only based on superficial features, and does not reflect a “deep” understanding of the problem . Therefore, REV -EN G E, simply, m akes a first cut of probable solution candidates th a t are further checked for th eir applicability by users m anually inspecting the preconditions of the case against existing design rationale. For exam ple, case-40 in Table 7.3 would not be applicable for the th ree p art container, if th e p arts m ust be m ade of m etal (non- m alleable m aterial) (see Table 7.5). T he selected case is validated by m anually checking its preconditions and side effects (specified in tex t) against th e following design inform ation before the case is applied and a redesign is executed. • Existing knowledge of design rationale. For exam ple, in Figure 6.7, specificatiori- 1 in the left-hand side, belongs to the existing design rationale. • D irect antecedent of problem atic design action in question. An antecedent is any design action th a t justifies the problem atic design action. For instance, in Figure 6.7, design action 7, select-formfbase, rectangular), and design action 4,, create-form(cover) are direct antecedents of design action 8, select-form(cover,\ rectangular). A change in design action 8 should not be in conflict w ith the consequence of design action 4 and 7. If th ere exist any conflicts, a case m ay be judged to be inapplicable, and a new; case m ay be tried. An alternative is to change the design knowledge to elim inate the conflict and apply th e case. Only design conjectures or design explanation, whiclJ are am ong th e types of design rationale in REV -EN G E, m ay be changed or deleted] Design R ationale of C ontainer “m ust be rectangular” “m ust contain greater th an 50 cubic inch” Precondition of Case-40 “clearance for th e force fit feature exists” “p art m aterials m ust be m alleable” Side Effects of Case-40 “slight increase in m anufacturing cost” “m ating is less tig h t” Table 7.5: Checking design rationale of th e container (Figure 4.2) w ith preconditions and side effects of case-40. However, it is possible th a t th e related design rationale does not exist: for in stance, no explanation exists for the choice of m aterials for th e container (e.g. be cause th e user sim ply neglected to enter the inform ation during knowledge acquisi tion phase). T here are two possibilities. One is th a t th e user is now rem inded of the design requirem ent by visually checking the precondition list, and im m ediately validates or invalidates th e applicability of th e case. At th e sam e tim e, the design inform ation used to validate or invalidate th e applicability of th e case is entered for fu tu re use. In this case, required design inform ation is entered on dem and by thej need of th e redesign procedure. This is an im portant characterisitic of REV -EN G E in com parison to other types design capture system s. T he other possibility is th a t the user assum es th a t no rationale exists and, therefore, no conflicts arise. The^ redesign process is continued. If the user later finds out th a t th e assum ption wasj wrong, th en th e redesign is retracted to th a t point where th e wrong assumption! was m ade. R EV -EN G E provides easy access to all types of design inform ation de scribed above through m enus visually localized around the graphical representation of related problem s, cases and design actions on the screen. 7.5 Case Adaptation A fter a relevant case is retrieved and selected, a one-to-one m atch betw een the “actors” in th e redesign case and design objects in the current design is attem pted.) This is perform ed first by finding several candidate design objects in th e current design th a t m atch th e description specified in the actor list of the redesign caseJ C urrently, th e m atch heuristic is only based on th e num ber of m atching conditions.! Actors in Case-40 Candidates User Choice LIAISON-P1-P2 BASE-COVER-LIAISON BASE-COVER-LIAISON PART-1 COVER BASE COVER PART-2 COVER BASE BASE HOLE-1 COVER-HOLE BASE-HOLE COVER-HOLE HOLE-2 COVER-HOLE BASE-HOLE BASE-HOLE SCREW SCREW-1 SCREW-1 NUT NUT-1 NUT-1 PROBLEM CURRENT-PROBLEM PROB-MATING-BASE-COVER-LIAISON Table 7.6: M atching actors in th e case w ith design objects in th e container exam ple. For exam ple, case-40 specifies an actor, called part-1, w ith conditions such as (:is- a part-1 part)2, (:has-feature part-1 hole-1)3, (:type hole-1 hole)'1, and etc. REV EN G E searches for all design objects th a t satisfy above conditions and presents the| candidates to th e user in a graphical m anner (see Figure 7.5). T he user selects each final candidate by clicking on th e nodes of th e graph. T he m atch does not have toj necessarily be a one-to-one m atch. Table 7.6 shows m atch betw een actors from case-j 40 and design objects in the three p art container exam ple. If a m atch can not be I found betw een th e selected case and current design objects, then the case is markec inapplicable. 7.6 Execution of Redesign A fter th e process of adaptation, a redesign is executed as prescribed by the case (delete old objects, and add new objects). In addition, the case prescribes also to delete other problem s related to the current problem , and design objects dependent on th e m ain problem atic design object initially being deleted. For exam ple, if a part* is being deleted, then th e system m ust recursively delete all th e features, design actions, design rationale, and problem s th a t belong to the part. Therefore, solving 2Part-1 is a part. 3Part-l has a feature called hole-1. 4Type of hole-1 is a hole. 70 __l C aao-baaed R edesign W orkbench >!-M -!-:-: A * w vw V i • b /s ^ r s r v w \ v m v v m m *. tX c a p * > vV [CCVER_H0LE S. 0 rtvvAV^kAA/tfvuftnAAAA^MMwuvMtftAAA^nMnAAnnnnnnnnnnnj^AAAnnn/VinnAAnnfririrdNW/bnnjvuvnnAnMvvtf^Ann/VbnnnAnnnArtraV^VMV M I ^ V M W V M A M W W M Figure 7.5: A dapting a case to a current problem . 71 one problem usually removes m any other problem s as deleting one object m ay sim ply rem ove other parts of design th a t m ight have been m arked problem atic. A fter either all th e problem s are solved, or when sufficient num ber of problem s are solved, the final design plan can be generated which can be handed to a CAD system user for him or her to realize th e redesign geometrically. T he following trace from R E V EN G E is signalling th a t it is creating a new feature, F O R C E -F IT -1-747'5, changing a ttrib u tes of, and deleting other existing design objects. C r e a t i n g a new o b j e c t : FO R C E -FIT -1 -7 4 7 5 A d d in g /R e p la c in g (:OLD PROTRUSION) t o : TYPE o f F O R C E -F IT -1-7475 A d d in g /R e p la c in g (:OLD HOLE-1) t o : FEATURE-OF o f F O R C E -F IT -1-7475 A d d in g /R e p la c in g ( : FROM HOLE-1) t o : HAS-FUNCTION o f F O R C E -F IT -1-7475 A d d in g /R e p la c in g (:OLD PLASTIC-MATERIAL) t o : MATERIAL o f BASE A d d in g /R e p la c in g ( : OLD PR E S S -F IT ) t o :TYPE o f BASE_COVER_LIAISON D e l e t i n g BASE_HQLE . . . [ D e l e t i n g PR0B-MARKED-FEAT-BASE_HQLE-6881 . . . j D e l e t i n g CREATE-FORM-BASE_H0LE7054 . . . D e l e t i n g DETAIL-FORM-BASE_H0LE7110 . . . D e l e t i n g SELECT-F0RM-BASE.H0LE7076 . . . D e l e t i n g C0VER_H0LE . . . D e l e t i n g PR0B-MARKED-FEAT-CQVER_H0LE-6882 . . . D e l e t i n g CREATE-F0RM-C0VER_H0LE7062 . . . D e l e t i n g DETAIL-F0RM-C0VER_H0LE7114 . . . D e l e t i n g SELECT-F0RM-C0VER_H0LE7080 . . . D e l e t i n g SCREW_1 . . . D e l e t i n g PR0B-GRASP-SFC-SCREW _1-6821 . . . D e l e t i n g CREATE-F0RM-SCREW_17066 . . . D e l e t i n g DETAIL-F0RM-SCREW_17116 . . . D e l e t i n g SELECT-FQRM-SCREW_17082 . . . D e l e t i n g PROB-MATING-6874 . . . f 7.7 Producing a Plan of Redesign: An Example To b etter illustrate how design m odification can be perform ed using th e m ethod described so far, le t’s step through th e design plan of Figure 6.7 (Also see Figure 7.8). Suppose we would like to redesign th e container in Figure 7.8 w ith respect to DFA principles, and also suppose th e DFA analysis identified two problem s: (1) shape of cover and base are not sym m etric, and (2) screwing operation is expensive5. Each design problem can be m apped to th e corresponding portion of th e design plan where it could have originated. For exam ple, th e first problem m aps to select-form (base, rectangular) and select-form(cover, rectangular) (left corner of the Figure 6.7). The second problem m aps to th e portion of th e design plan where th e assem bly m ethod betw een th e base and the cover is selected, nam ely select-assembly-method(connect- base-cover, screwing) (m id-right side of Figure 6.7). Therefore, we start replaying the design plan from th e earliest stage th a t could have originated the problem s. S tarting from select-form (base, rectangular), the sys tem provides the user w ith a sim ilar case in which a rectangular p a rt was changed to a circular p a rt for sym m etry. Assum ing th e retrieved case did not suggest any pos sibility of significantly undesirable side effects, th e user tries to apply th e retrieved case to the current design by first attem p tin g to validate th e new design objectj (circular base) w ith th e “antecedent” of th e old design object (rectangular b a se )' T h e user quickly finds th a t specification-1 (m id-left side of Figure 6.7) conflicts with' th e design object to be newly introduced. Consequently, the shape of th e base, and hence th e design plan, is left unm odified despite its problem . Then, th e rest of th e plan is replayed till th e design action associated w ith the second design problem is encountered. Again, a relevant redesign case is retrieved! in which screw /holes were replaced by a force-fit (see Table 7.3). T he retrieved case specifies types of design objects to rem oved and added. For exam ple, as the m ating m ethod is changed, all th e holes and screws are rem oved, and a new force-fit feature is introduced. As there can not be found any design inform ation conflicting withj th e introduction of th e new feature, th e reconstruction algorithm generates a newj design plan as shown in tex t in Table 7.7, in a justification stru ctu re in Figure 7.6,1 and in a R E V -EN G E window in Figure 7.7. Figure 7.9 shows a possible redesign^ as would be realized by a CAD system user following th e prescription of the newj design plan. N ote th a t the analysis penalty score has been lowered from 25.8 to 15.8 after elim inating th e screw m ating (see Figure 7.10). Also, note th a t this reduced ! --------------------------------------------------------- i 5In DFA, symmetric parts are preferred because they have higher orientation efficiency, and screwing operation is regarded as one of the most expensive mating method. 73 Order Design Action Design object 1 CREATE-MAIN-FUNCTION BASE-F1 2 CREATE-MAIN-FUNCTION COVER-FI 3 CREATE-MAIN-FORM BASE 4 CREATE-MAIN-FORM COVER 5 CREATE-ASSEMBLY-FUN CTION CONNECT-BASE-COVER 6 CREATE-ASSEMBLY-LIAISON BASE-COVER-LIAISON 7 SELECT-MAIN-FORM BASE 8 SELECT-MAIN-FORM COVER 9 SELECT-ASSEMBLY-METHOD BASE-COVER-LIAISON 10 CREATE-ASSEMBLY-FORM FORCE-FIT-1-7417 11 SELECT-ASSEMBLY-FORM FORCE-FIT-1-7417 12 DETAIL-MAIN-FORM BASE 13 D ETAIL- M AIN - F 0 RM COVER 14 DETAIL-ASSEMBLY-FORM FORCE-FIT-1-7417 Table 7.7: A design plan for a new container w ith a force fit. score reflects th e m inim um penalty score possible after th e redesign because of the tradeoff assum ption of Section 7.1. Therefore, th e actual penalty score should be less th a n or equal to th e previous penalty score of 25.8 (see Figure 5.3), b u t greater th an or equal to 15.8. 74 . J external view cross section Redesign of a Container :reate-funetion create-function (base) xeate-fornr :reate-form Specification-L: “container m tw not be circular’ "^.create-function 5 ¥connect-base-cover) select-form „ „ (base, rectangular) '^.create-form 6 Xbase-cover-liaison) select-form .cover, rectangular select-assembly-method (connect-base-cover, force-fit) create-form (force-fit-feature) design action design information justification select-form (force-fit-feature) Figure 7.6: A plan of redesign in a justification structure. 75 P Aoaiyatt A . - .......................... — if. m: [5 - L i a s1 o n -T y p o '|-H-»js^ s-Liasi<x]-iype p+4HS-J^TO-Ease_Cover_Liai son]* - F nn - rorce> - F 1 1 -1 - 7 417 ] -> : :%|s-ABsan-Frm H i -Frm-»rorce-Fi t-1 - 7417 ^: | ; j Figure 7.7: A plan of redesign in a R EV -EN G E window (scrolled down to show the portion changed com pared to Figure 7.3). Figure 7.8: Original container m odeled using PADL-2 solid m odeller. Figure 7.9: A possible redesign of the container using PADL-2 (m anual). P r o b l e m I Problem Analysis Summary: CATEGORY-1 HANDLING SETUP MATING MANUFACTURING ASSEMBLY-PLANNING WEIGHT 1 0.8 1 0.5 0.3 MO 2 0 2 2 0 SCORE 2.0 0.0 2.0 1.0 0.0 CATEGORY"-2 TIME COST WEIGHT 1 1 NO 4 2 SCORE 4.0 2.0 CATEGORY-3 MINOR MODERATE MAJOR WEIGHT 0.3 0.7 1 MO 0 4 2 R e c o m p u te SCORE 0.0 2.8 2.0 D one TOTAL-NO 6 TOTAL-SCORE 15.8 ^wCCCC^ vw<MW^ *l C^ CiCCCwMwMCvC^ X*A»MNC*ivAW>w! C*i *wCw^ MC*i"i wC«^ ^ Figure 7.10: A sum m ary of analysis of th e new design. Com pare th e to tal penalty score between th e old (Figure 5.3) and the new (lower right corner). This score reflects th e best possible situation (i.e. the m inim um penalty score) w here no other,1 problem s are assum ed to be created after applying th e redesign case. 78 Chapter 8 More Examples In this chapter, th ree m ore exam ples of redesign w ith R E V -EN G E are presented to illu strate each feature of the redesign model: nam ely, reverse engineering and use of design rationale, case-based redesign w ithout a com plete dom ain m odel, and global redesign by replay of a design plan. Also, the exam ples reveal a num ber of im plem entational problem s w ith R EV -EN G E as discussed in detail in the final chapter. 8.1 An Old-Fashioned Plug T he first exam ple is th e redesign of an old-fashioned electric plug. Shown in Figure 8.1 is an exploded view of th e original design. The original design is represented w ith 6 p arts (a top p art, b o tto m p art, screw, nut, and two pins), and 6 features (a top hole, b o tto m hole, four grooves for th e pins, and a pocket for th e n u t on the b o tto m p art). A full in p u t representation can be found in th e appendix. D uring th e knowledge acquisition phase, suppose th a t four pieces of design ra tionale are acquired interactively as shown in Figure 8.2. T hen, a DFA analysis is perform ed to find problem s w ith th e design. T here are 11 DFA problem s th a t are identified by A-EX as listed in Table 8.1. A default design plan is generated and th e problem s are m apped accordingly. T he order of attacking th e problem s is shown in Table 8.2. R EV -EN G E first attem p ts to find a case relevant to solving the first problem , P R O B -N O N -N E C E S S -P T -B O T T O M , which indicate th a t B ottom m ay not be nec essary. T he criteria to judge w hether a p art is needed or not is based on th e three 79 Sere tv Pinl Pin2 Top Bottom Nat Figure 8.1: An old-fashioned plug. Problem Name Description PROB-FIX -PIN1-BOTTOM -LIAISON B ottom needs to be fixed to press fit the pins into slots PROB-DIR-TOP-BOTTOM -LIAISON N ut requires an assembly direction from the b o tto m PRO B-FEA T-BX IST-BTW -PIN1-BO TTO M No helping feature between P in l an d B ottom PRO B-FEA T-EX IST-BTW -PIN 2-B O TTO M No helping feature between Pin2 and B ottom PRO B-FEA T-EX IST-BTW -TO P-BO TTO M No helping feature betw een Top an d B ottom PRO B-FEA T-EX IST-BTW -N UT-1-BO TTO M No helping feature betw een N ut an d B ottom PRO B-FEA T-EX IST-BTW -SC REW -1-TOP No helping feature between Screw an d Top PROB-M ATING-TOP-BOTTOM -LIAISON Expensive m ating type betw een Top an d B ottom PRO B-N O N -NEC ESS-PT-TO P Top m ay be m erged PROB-NON-NECESS-PT-BOTTOM B ottom m ay be m erged PROB- G RASP-SFC- SCREW -1 No grasping surface on Screw Table 8.1: DFA problem s generated for th e old-fashioned plug. 80 {PLUG-SPEC-1 : IS -A = (SPECIFICATION) :TYPE = CREATE-FORM :DESCRIPTION = " m u s t b e d i s a s s e m b l a b l e . " : RATIONALE-OF = (TOP BQTTOM>) > {PLUG-SPEC-2 :IS -A = (SPECIFICATION) :TYPE = SELECT-FORM :DESCRIPTION = "m u s t b e m ade o f c o n d u c tin g m a t e r i a l . " : RATIONALE-OF = (PIN 1 P IN 2) > {PLUG-CONJ-l : IS -A = (CONJECTURE) :TYPE = DETAIL-FORM rDESCRIPTION = " i t s s i z e i s f i x e d s i n c e i t n e e d s t o b e p lu g g e d i n t o a s t a n d a r d o u t l e t . " : RATIONALE-OF = (P IN 1 P IN 2) > {PLU G -EX P-i : IS -A = (EXPLANATION) : TYPE = DETAIL-FORM :DESCRIPTION = " s h a p e o f b o d y i s r e c t a n g u l a r f o r e a s y g r a s p i n g . " : RATIONALE-OF = (TOP BOTTOM) > Figure 8.2: Acquisition of design rationale. O rder of A ttack O rder of Design A ction Design A ctio n / Design O b ject P roblem s M apped 1 5 C R E A TE-M AIN-FORM B O TTO M PR O B -N O N -N E C E SS-FT -B O TT O M 2 6 C RE A TE-M AIN-FORM T O P PR O B -N O N -N E C E SS-PT -T O P 3 19 SELEC T-A SSEM BLY -M ETH O D T O P-B O TT O M -LIA ISO N PRQ B -M A TIN G 4 20 SELECT-A SSEM BLY -M ETH O D PIN 1-B O T T O M-LIAISON PROB-FIX* PIN 1-B O T T O M -LIAISON 5 28 CREA TE-A SSEM BLY -FO RM NUT P R O B -D IR -T O P-B O TT O M -LIA ISO N 6 7 8 9 10 CR EA TE-A SSEM BLY -FO R M STAGE P R O B -FE A T -E X IST -B T W -PIN 1-B O T TO M P R O B -FE A T -E X IST -B T W -PIN 2-B O T T O M PR O B -FE A T-EX IST -B TW -TO P* B O T T O M PR O B -FE A T -E X IST -B T W -N U T -1-B O T T O M PR O B -FE A T-EX IST -B TW -SC R E W - 1-TO P 11 52 DETAIL-A SSEM BLY -FO RM SCREW -1 PRO B -G R A SP-SFC -SC R E W -1 I i Table 8.2: A default design plan and problem s generated by R EV -EN G E for the Plug. 81 axiom s originally proposed by B oothroyd [11]. They are: (1) does th e p art re quire th a t it be m ade of a different m aterial from its neighbors?, (2) does th e p a rt move relative to its neighbors?, and (3) does th e p art need to be disassem bled from its neighbors?. If the answers to above three questions are all “No,” th en it m ight be possible to m erge th e p art in question w ith one or m ore of its stru ctu ral neighbors. T h a t is, P R O B -N O N -N E C E S S -P T -B O T T O M (and P R O B N O N -N E C E SS-P T -T O P ) proposes th e possibility of m erging th e two parts, Top and Bottom . R EV -EN G E retrieves a redesign case th a t stru ctu rally merges two neighboring parts. However, th e user quickly finds, through th e user interface, th a t th e precondition of th e case conflicts w ith PLU G -SPEC -1 (See Figure 8.2) which specifies th a t th e body of the plug be disassem blable. Similarly, th e second problem , P R O B -N O N -N E C E S S -P T -T O P , is left unsolved as well. T he next problem , P R O B -M A T IN G , is alm ost th e sam e problem used through out th e thesis for th e container exam ple. B oth the case th a t replaces screwing w ith a force-fit (case- 4 0 ) and the case th a t replaces screwing w ith a snap fit (case-2 4 ) are retrieved as top candidates. F irst, an application of case-40 is attem p ted . The user notices a side effect of case- 4 0 resulting in a possibly loose m ating, and de cides case- 4 0 is inapplicable. Case-24 is retrieved instead and ad ap ted in a similar! m anner to the container exam ple. Therefore, th e relevant design inform ation is solicited on dem and, and recorded for possible future use. In executing this re design, several features and p arts are rem oved from th e design, (e.g. N ut, Screw, Top-hole, Bottom-hole, etc.) and new features (snap-fits) are added accordingly. Problem s 2, 9, 10 and 11 (P R O B -D IR -T O P -B O T T O M -L IA IS O N , P R O B -F E A T - E X IS T -B T W -N U T - 1-B O TTO M , P R O B -F E A T -E X IS T -B T W -S C R E W -1 -T O P and, P R OB- G RA SP-SFC - S C R E W -l) are rem oved autom atically, since they are associ ated w ith th e design objects th a t are rem oved from th e design. T he rem aining problem s are problem 5, 6, 7, and 8. Problem 5, P R O B -F IX - P IN 1 -B O T T O M -L IA IS O N states th a t a holding device is needed for th e bottom part while th e pins are press fit on it. R EV -EN G E is unable to find a relevant case, and th e user moves to th e next rem aining problem s. Problem 6, P R O B -F E A T -E X IS T - B T W -P IN 1 -B O T T O M , is a problem w ith a m issing “helping” feature. T h a t is, a' guiding feature or a cham fer could be added to enhance th e ease of m ating between! pins and the b o tto m p art. Problem 7 and 8 are sim ilar problem s and R EV -EN G E Chamfers G uiding F eature Snap B Figure 8.3: A newly designed plug w ith chamfers, a stop, and a snap fit (m anual). is able to retrieve a case th a t solves this problem by creating a cham fer or a guiding feature on th e appropriate part. A new design plan, shown in Table 8.3, is generated based on th e u p d ated design to be handed to a hum an designer for who can realize it geom etrically. A possible redesign is shown in Figure 8.3. 8.2 Mouse The second exam ple is a redesign of th e DEC (D igital Equipm ent C orporation) mouse. Shown in Figure 8.4 are before and after illustrations of th e m ouse redesigned m anually by a design team utilizing results from B oothroyd’s DFA analysis m ethod. This exam ple was one of th e success stories of DFA application illu strated in num er ous publications [1]. In REV -EN G E, the m ouse is represented in 12 p arts, namely, a cover, bottom , p rinted circuit board, ball, ball support, and four screws. J Known design specifications and design rationale are obtained from the user (See Figure 8.5). T hen, a DFA analysis is perform ed to find problem s w ith th e design. M ajor problem s found by A-EX is shown in Table 8.4. 83 Order Design Action Design Object 1 CREATE-MAIN-FUNCTION TOP-F1 2 CREATE-MAIN-FUNCTION BOTTOM-F1 3 CREATE-MAIN-FUNCTION PIN1-F1 4 CREATE-MAIN-FUNCTION PIN2-F1 5 CREATE-MAIN-FORM BOTTOM 6 CREATE-MAIN-FORM TOP 7 CREATE-MAIN-FORM PIN1 8 CREATE-MAIN-FORM PIN2 9 CREATE-ASSEMBLY-FUNCTION CONNECT-PLUG 10 CREATE-ASSEMBLY-FUN CTION CONNECT-PIN1 11 CREATE-ASSEMBLY-FUNCTION CONNECT-PIN2 12 CREATE-ASSEMBLY-LIAISON TOP-BOTTOM-LIAISON 13 CREATE-ASSEMBLY-LIAISON PIN 1-BOTTOM-LIAISON 14 CREATE-ASSEMBLY-LIAISON PIN2-BOTTOM-LIAISON 15 SELECT-MAIN-FORM BOTTOM 16 SELECT-MAIN-FORM TOP 17 SELECT-MAIN-FORM PIN1 18 SELECT-MAIN-FORM PIN2 19 SELECT-ASSEMBLY-METHOD TOP-BOTTOM-LIAISON 20 SELECT-ASSEMBLY-METHOD PIN 1-BOTTOM-LIAISON 21 SELECT-ASSEMBLY-METHOD PIN2-BOTTOM-LIAISON 22 CREATE-ASSEMBLY-FORM TOP-GRV1 23 CREATE-ASSEMBLY-FORM TOP-GRV2 24 CREATE-ASSEMBLY-FORM BOTTOM-GRV1 25 CREATE-ASSEMBLY-FORM BOTTOM-GRV2 26 CREATE-ASSEMBLY-FORM SNAP-FEATURE-A-7868* 27 CREATE-ASSEMBLY-FORM SNAP-FEATURE-B-7873* 28 CREATE-ASSEMBLY-FORM CHAMFER-FEATURE-1-7979* 29 CREATE-ASSEMBLY-FORM CH AMFER-FEATURE-1- 7995’ 30 CREATE-ASSEMBLY-FORM LOCATOR-1-7998* 31 SELECT-ASSEMBLY-FORM TOP-GRV1 32 SELECT-ASSEMBLY-FORM TOP-GRV2 33 SELECT-ASSEMBLY-FORM BOTTOM-GRV1 34 SELECT-ASSEMBLY-FORM BOTTOM-GRV2 35 SELECT-ASSEMBLY-FORM SNAP-FEATURE-A-7868* 36 SELECT-ASSEMBLY-FORM SNAP-FEATURE-B-7873* 37 SELECT-ASSEMBLY-FORM CH AM FER-FEATURE-1-7979* 38 SELECT-ASSEMBLY-FORM CH AM FER-FEATURE-1-7995* 39 SELECT-ASSEMBLY-FORM LOCATOR-1-7998* Table 8.3: A new design plan for th e Plug. Design actions m arked w ith asterisks are newly introduced design actions. o J B E F O R E * F rift Figure 8.4: Redesigning a D EC Mouse. R eprinted w ith perm ission from [1].) {MOUSE-SPEC-1 IS -A = (SPECIFICATION) TYPE = CREATE-FUNCTION DESCRIPTION = "m u s t b e a b l e t o d i s a s s e m b l e l o r o c c a s i o n a l c l e a n i n g " RATIONALE-OF = (BALL-SUPPORT-FN) {MOUSE-SPEC-2 IS -A = (SPECIFICATION) TYPE = SELECT-FORM DESCRIPTION = " s i z e i s d e te r m in e d a f t e r s i z e o f a hum an h an d " RATIONALE-OF = (COVER-HOUSING BOTTOM-HOUSING) Figure 8.5: A cquisition of design rationale for DEC mouse. 85 Problem Name D escription PROB-FIX-COVER-SW ITCH-C-LIAISON The center b u tto n need to be hold during assembly PROB-M ATING-COVER-BOTTOM -LIAISON Expensive m ating type betw een Cover an d B ottom PROB-NON-NECESS-PT-COVER-HOUSING Cover m ay be m erged PROB-NON-NECESS-PT-BOTTOM -HOUSING B ottom m ay be m erged PROB-NO N-NECESS-PT-BALL-SUPPORT Ball S upport m ay be m erged Table 8.4: DFA problem s generated for th e DEC mouse. O rder of A ttack O rder of Design A ction Design A ction/ Design O bject Problem s M apped 1 11 C R E ATE-M AIN-FORM COVER-HOUSING PR O B -N O N -N EC ESS-PT-C O V ER -H O U SIN G 2 12 CR E AT E-M AIN-FORM BO TTO M -H O U SIN G PR O B -N O N -N E C E SS-PT -B O TT O M -H O U SIN G 3 18 CR E ATE-M AIN-FORM BA LL-SU PPO RT PR O B -N O N -N E C E SS-PT -B A LL -SU PPO R T 4 44 45 46 SELECT-ASSEM BLY-M ETHOD CO V ER-BO TTO M -LIA ISO N PC B -B O TTO M -LIA ISO N PC B-C OVER-LIAISON PR O B -M A TIN G -C O V ER -B O TTO M -LIA ISO N 5 49 SELECT-ASSEM BLY-M ETHOD C O V ER-SW ITCH -C-LIA IS ON PR O B -FIX -C O V ER -SW ITC H -C -LIA IS ON Table 8.5: A default design plan and problem s generated by R EV -EN G E for the DEC mouse. A default design plan is generated and th e problem s are m apped accordingly. T he order of attacking the problem s is shown in th e first colum n of Table 8.5. j T he first two problem s address th e possibility of m erging Cover and B ottom into one part. Obviously, th e housing of the m ouse needs to be disassem bled in order to com plete th e entire assembly. T he user notices this and enters a new design; rationale, specifying th a t Cover and B ottom be disassem blable (see Figure 8.6). {MOUSE-SPEC-l : IS -A = (SPECIFICATION) :TYPE = CREATE-FORM : DESCRIPTION = "m u st b e a b l e t o d is a s s e m b l e " : RATIONALE-OF = (BOTTOM COVER) > Figure 8.6: A cquisition of design rationale during redesign. 86 T he user moves on to th e th ird problem th a t indicates th e possibility of m erging B all Support and Bottom . T he user is rem inded of th e design rationale, M O U SE- SPEC-1, associated w ith Ball support th a t specifies th e functional need of Ball Sup port, nam ely, for th e occasional cleaning of the m ouse w ithout unscrew ing screws. Since at this point in th e replay of th e design plan, th e m ating m ethod betw een Cover and B ottom is not determ ined, th e user quickly finds from th e design plan layout th e fourth problem deals w ith th e screwing operation, nam ely, P R O B -M A T IN G - C O V E R -B O T T O M -L IA ISO N . T he user overrides the recom m ended order of attack and solves th e fourth problem in advance by replacing screw s/holes w ith a snap fit. T hen, th e design rationale, M O U SE-SPE C -1, is retracted to justify the easier m ethod of m ating th a t can be used betw een th e cover and th e base. Therefore, no conflict arises in applying a redesign case th a t merges B all Support into th e Bottom . R E V -EN G E , however, erroneously overlooked the m ating required betw een Printed Circuit Board and Bottom . This resulted from th e fact th a t th e original m ating betw een Printed Circuit Board and B ottom was realized by th e sam e screws th a t realized th e m ating betw een B ottom and Cover. T he p articu lar case th a t was used to replace th e m ating type betw een th e Cover and B ottom was not applied to the m ating betw een Printed Circuit Board and B ottom , because of th e lim ited com po nent m atching capability of th e system . Figure 8.7 shows a possible redesign of a m ouse as recom m ended by using R EV -EN G E. N ote th a t in com parison w ith the real redesign shown in Figure 8.4, R EV -EN G E fails to elim inate th e tracking ball, where as in th e actual redesign, a non-m echanical m ethod of tracking the mouse m ovem ent was invented. R EV -EN G E is not able to perform this kind of innovation w ithout being equipped w ith th e appropriate knowledge. 8.3 Reticle Assembly T he th ird exam ple is th e redesign of a reticle assembly, p art of a ground based arm ored vehicle produced by Texas Instrum ents Defense System s and Electronics group (see Figure 1.1). In REV -EN G E, th e reticle subassem bly is represented in 18 p arts and associated features, nam ely, a housing, bracket, carriage, pin, coupling, four springs, th ree shafts, four rings, and two screws. 87 Figure 8.7: A possible redesign of (m anual). Note th a t com pared to was not able to recom m end th e eliri of innovative knowledge. Table 8.6 lists some of th e m ajor subassembly. A default design plan is genera1 T he order of attacking th e problems T he first problem attacked in N E C E S S -P T -R E T IC L E -B R A CKE1 © th e m ouse following advice from R E V -EN G E the actual redesign in Figure 8.4, R EV -EN G E aination of th e tracking ball due to sim ple lack DFA problem s th a t were found w ith th e reticle ;ed and th e problem s are m apped accordingly, is shown in Table 8.7. th e reticle assem bly exam ple is P R O B -N O N - n , in which R EV -EN G E prom pts th e user for P roblem Name D escription PROB-DIR-GEAR1-SHAFT3 G ear needs to be assem bled from th e b o tto m PROB-FIX -HOU SIN G-CARRIAGE-LIAISON A holding device is needed for assem bling the Carriage to the Housing PROB-M ATIN G-HOU SIN G- CARRIAGE-LIAISON Expensive type o f m ating betw een Housing an d Carriage PROB-M ATIN G-HOU SIN G-BRACKET-LIAISON Expensive type of m ating betw een Housing and Bracket PROB-M ATIN G- GE AR-SHAFT-LIAISON Expensive type o f m ating betw een G ear an d Shaft PRO B-NO N -NECESS-PT-RETICLE-BRA CK ET B racket m ay he m erged PRO B-N ON-NECE SS-PT-G EA R-1 G ear m ay be m erged Table 8.6: DFA problem s generated for th e reticle subassembly. 88 O rder of A ttack O rder of D esign A ction D esign A ctio n / Design O bject Problem s M apped 1 8 C R EA TE-M A IN -FO RM R E T IC L E -B R A C K E T P R O B -N O N -N E C E SS-PT -R ET IC LE -B R A C K ET 2 15 CREA TE-M A IN -FO RM GEAR1 PR O B -N O N -N E C E SS-PT -G E A R -1 3 15 C R EA TE-M A IN -FO RM GEAR1 PR O B -D IR -G EA R 1-SH A FT3 4 28 SELECT-A SSEM BLY -M ETH O D H O U SIN G -BRA C K ET-LIA ISO N PRO B -M A TIN G-HOU SIN G -B R A C K ET-LIA ISO N 5 29 SELECT-ASSEM BLY-M ETHOD H OU SIN G- CARRIAGE- LIAIS ON PRO B -M A TIN G-HOU SIN G -C A RR IA G E-LIA ISO N 6 29 SELEC T-A SSEM BLY -M ETH O D H OU SIN G -CARRIAGE-LIAISON PR O B -FIX -H O U SIN G -CA R RIA G E-LIA ISO N 7 30 SELECT-ASSEM BLY-M ETHOD G EA R-SH A FT-LIA ISO N PRO B -M A TIN G -G EA R -SH A FT-LIA ISO N Table 8.7: A default design plan and problem s generated by R E V -EN G E for th e reticle subassembly. an application of th e p art m erge redesign strategy. A p a rt m erge redesign strat- egy, w hereby a bracket is m erged into th e housing using a cast m etal technique, is applied. This redesign elim inates two screws, holes, and a related DFA problem , P R O B-M A TIN G -H O U SIN G -BR A C K E T -L IA ISON. T he next problem is PRO B- N O N -N EC ESS-PT-G EA R -1 in which R EV -EN G E recom m ends a case which re places a g ear/sh aft com bination w ith a single cam m echanism . A pplication of this re design case invalidates P R 0 B -D IR -G E A R 1 -S H A F T 3 and P R O B-M A TIN G - G E A R - S H A F T -L IA IS O N as th e relevant problem atic p art is rem oved from th e design. The next problem is th e problem w ith th e m ating betw een Carriage and Housing where Carriage needs to be held while th e springs and shafts axe inserted through the hole. A case w here p arts are clipped onto th e shaft instead of inserted through holes is retrieved and adapted, provided th a t a m alleable m aterial can be used for Carriage. A ppropriate features required for clipping Carriage on to th e shafts are added to its bottom . Figure 8.9 shows a possible a m anual redesign recom m ended by R EV -EN G E. 89 Carriage Clipping Feature Q Springs Cam Housing Figure 8.8: A possible redesign of the reticle subassem bly following advice from' R E V -EN G E (m anual). 90 Chapter 9 Conclusion Even w ithout original design records, intelligent designers can m ake default assum p tions ab o u t th e process of the design, to reason about possible redesign alternatives, i.e. by r e v e rs e e n g in e e rin g . This thesis has presented a m odel of redesign for DFA (and a redesign tool im plem ented based th e m odel), called REV -EN G E, m odeled af te r hu m an ’s capability of reverse engineering, to assist designers in perform ing DFA redesigns w ith m inim um inform ation about th e targ et design. T he REV -EN G E can alleviate th e cum bersom eness of th e conventional approach to design capture system s. It also saves user efforts by autom atically capturing design plans and pro viding stru ctu red knowledge acquisition. T he fram ework enhances th e cooperation betw een design analysis and redesign by m apping th e analysis o u tp u t directly to th e design process. T he case-based design m odification based on the design plan stru ctu re offers m ore global redesigns w ithout a rigorous functional or behavioral m odel by m aking fixes on th e process of design rath er th an th e o u tp u t of th e design. By incorporating different design process models for constructing th e default design plan, it can serve as a test bed for com paring different design process models as well. Redesigning for DFA involves application of known redesign techniques to wide va riety of design dom ains (routine redesign). T he m odel of R E V -EN G E provides a reasonable fram ework for “routine” redesign tasks, such as those often needed in DFA. 91 9.1 Contributions 9 .1 .1 M o d e l o f D F A R e d e sig n One of th e m ajor contribution of th e thesis is in th e developm ent of a redesign m odel for Design-for-Assembly. Most com m ercial DFA tools to d ate are analysis tools, th a t is, tools th a t m easure the “assem blability” of a design. No guidelines are available in how to go about redesigning a product once an analysis has been perform ed. R EV -EN G E, in addition to being a redesign tool, is a system atic m odel of redesign. It is dom ain independent in th a t it does not require a detailed behavioral m odel of th e targ et design, and relies on redesign cases th a t reflect general redesign strategies th a t apply across wide variety of design dom ains. A distinction is m ade betw een th e “inner loop” and th e “outer loop” of design (See Figure 3.1). W hile th e overall design activity iterates in stages of analysis, synthesis, and verification ( “o u ter” loop), there also is an “inner” .loop w ithin the synthesis stage w here th e best redesign solution is sought before beginning another iteration in th e outer loop. Such a problem solving strategy of R EV -EN G E helps user reduce overhead in perform ing repetitive generate-and-test design cycles. A cquisition of design inform ation, a critical elementj in redesign, occurs on dem and, instead of in batch, reducing the need of recording; everything during th e first phases of design. 9 .1 .2 In fere n c e o f D e sig n P la n A nother im p o rtan t contribution of th e thesis is the use and inference of design plans in solving a redesign problem . A lthough th e idea of derivational analogy is not th a t of th e author, its application has been ham pered by th e requirem ent th a t old derivations be stored for retrieval and ad aptation to new problem s. R E V -EN G E I instead takes a novel approach by guessing w hat the derivation could have been soj th a t this pre-storage requirem ent is not needed. This stem s from th e recognitionj of design as one of th e problem dom ains where derivation of th e solution could be inferred from th e solution to a larger extent th an in other problem dom ains. T he applicability of a notion of a “default” design plan is based on an assum ption th a t a redesign for DFA would be very sim ilar to its original design. 92 9 .1 .3 G lo b a l R e d e sig n M ost redesign system s to d ate exist as a subsystem of design system s. For exam ple, in B O G A RT [57] a redesign occurs by specifying a new design goal and restarting th e design. This kind of m odel is inherently dom ain dependent because th e design operators are specific to design goals specific to certain dom ain. In, AIR-CYL [14], a redesign is perform ed by applying a a prestored script th a t patches the inconsistency betw een the desired and observed functional behavior. This approach is not only dom ain dependent b u t also requires m uch knowledge engineering in m odeling the design dom ain to its very details. D rastic changes in design goals m ay not be accom m odated w ith such patch-up styles of redesign. In R EV -EN G E, a general m ethod, based on a replay and m odify paradigm , to achieve a “global” redesign is perform ed w hereby a source of th e problem is pinpointed and attem p ted to be solved. By get ting to th e root of the problem , redesign proceeds efficiently w ithout w asting tim e on solving problem s th a t m ay be invalidated later by other fundam ental problem s. 9 .1 .4 C a se-b a se d R e d e sig n Case-based reasoning has been applied to wide variety of design dom ains, e.g. Chi nese cooking, architecture, speech synthesis, and etc. T he goal of m ost of these system s is oriented tow ard design (instead of redesign), and, therefore, th eir sys tem s store com plete designs in their case base. Redesigning in these types of sys tem s involves retrieving a “b e tte r” design, extracting th e difference betw een the the b e tte r and the targ et artifact to be redesigned, and somehow resolving th e differ ence. T he m ain disadvantage of these types of system s is th a t they are inherently dom ain-dependent since com plete designs in a p articu lar class m ust be stored, and th e redesign tactics are very specific to th e given dom ain. Dom ain dependency also requires a large knowledge engineering effort. R E V -EN G E has been designed m ore as a redesign system . T he case-based rea- soner takes an alternative approach where old applications of redesign strategies are stored, retrieved, and adapted. 9.2 Limitations 9 .2 .1 Lack o f D o m a in S p e cifics T he redesign dom ain is restricted to only those m echanical designs th a t have m inim al kinem atic behaviors. W ith o u t a form al functional or behavioral m odel, REV-ENGE^ has lim ited capability for redesigns th a t incur significant functional change. This problem can be solved by obtaining a behavioral m odel of th e design and incorporate it into R E V -EN G E as design rationale. A related problem is th a t R EV -EN G E provides no m ethods for validating th e behavior of th e new design. Such a m ethod' requires a detailed product model. One possible fu tu re research direction is toj develop a system atic knowledge engineering procedure for acquiring product specific models and to reform ulate REV -EN G E as a dom ain independent redesign “shell,” so as to create a flexible redesign th a t combines th e best of both worlds. 9 .2 .2 G e o m e tr ic In fe a sib ility A nother problem is th a t th e resulting design plan is also not always geom etrically feasible because th e plan is represented at a level higher th an geom etry. A more] sophisticated case-based m ethod m ay reduce th e possibility of generating geom etri cally infeasible design plans. 9 .2 .3 Im p le m e n ta tio n a l P r o b le m s Several im plem entational aspects of th e system rem ain to be im proved upon, al though unrelated to th e overall theory of th e redesign m odel. They are: i I • Case-based reasoning: — M ore cases need to be stored, and a learning scheme m ay be required to j keep th e case base at a reasonable size. T he size of th e case base will not: I be a problem , in general, since th e redesign strategies are stored instead of th e redesign them selves. — Case representation is too sim plistic. This results in retrieval of “seem ingly” related redesign strategies th a t tu rn out to be inapplicable. 94 — T he m atching process of case retrieval m ethod and case ad ap tatio n is sim plistic. A m ore dynam ic retrieval and ad ap tatio n m ethod is needed to cope w ith varying design circum stances. • Design representation and analysis: T he design representation is lim ited and this ham pers th e effectiveness and soundness of th e analysis. Because of the am biguity of th e design representation, th ere are both problem s in effectively analyzing thfe design and identifying th e responsible design action. • Rigidity of th e design process: th e current design process m odel is based on a Prescriptive Design M odel im plem ented as Prodigy search control rules. O ther design models can be im plem ented in a sim ilar m ethod, and be provided for user selection. This would provide m ore flexibility to th e system . • Tradeoffs w ith other design criteria: T he current system handles tradeoff issues betw een DFA and other cost factors such as m anufacturing and serviceability in a very lim ited way. They are currently handled in th e case validation process as side effects (e.g. “increase in m anufacturing cost” ). A m ore num erical scheme is needed to provide users w ith m ore concrete inform ation to determ ine the various design tradeoffs. 9.3 Future Research Directions 9 .3 .1 A d d itio n o f D o m a in M o d e ls C urrent approaches to DFA (or Design-for-X in general) [11] typically only address a single narrow design criterion and lack th e ability to consider interactions w ith other processes in th e product realization process. For instance, one of th e very popular m ethod of sim plifying an assem bly design is to m erge m ultiple p arts into one (thereby elim inating the needs for handling and assem bly equipm ents). This design decision needs careful consideration as it m ight result in negatively im p act ing other design concerns such as cost of com ponents or tooling. A nother issue confronting DFA system s is th e lack of flexibility to incorporate com pany specific or o ther dom ain specific knowledge. This is a key to gaining ind u stry acceptance. Each 95 com pany or industry considers itself unique and an approach to capture this unique ness w ithout significant m odifications to the design tool architecture is im portant. A related problem is the inability to generate detailed redesign advice, particularly in geom etric details. D etailed product specific redesign suggestions are only feasible w ith a system equipped w ith dom ain specific knowledge. By incorporating dom ain specific knowledge, th e redesign problem can be form u lated as a “hierarchical” replanning problem , in which th e dom ain specific knowledge is used to reason about how to realize specific steps to achieve th e ab stract plan pro duced by REV -EN G E. In hierarchical planning, th e problem dom ain is represented as a hierarchy of abstraction spaces in which finer levels of detail are introduced [70]. H ierarchical planning form ulates problem solving in the planning space (vs. state space) and greatly lowers th e com putational complexity. In order to achieve m ore flexibility and ease of custom ization, th e specific redesign steps should be reasoned (instead of pre-stored) from dom ain specific knowledge th a t can be system atically constructed by th e user. T he initial specific redesign plan can be obtained by refining th e ab stract plan w ith th e following sources of knowledge. F irst is a database of old redesign cases. Each of th e case only contains redesign steps general to different design dom ains. Secondly, detailed characterizations of various assem bly and m anufacturing processes can provide a way of directly relating DFA analysis to geom etric redesign. For exam ple, in [43], a num erical DFA m etric for feeding, called feedability, along w ith a set of specific redesign heuristics, have been developed based on a m athem atical m odel of a parallel jaw gripper. Otherj processes (e.g. fixturing, kiting, transporting, etc.) m ay be m odeled in sim ilar ways. Finally, detailed product m odels supply insights into th e required com ponents and other design decisions pertaining to th e class of th e given product. This final piece of knowledge is th e essential ingredient in th e system needed for interfacing th e system 1 into a CAD system (or a solid m odeller) realistic visualization. T he issue of addressing th e ability of the DFA system to consider interactions! w ith other design processes n aturally falls under th e question of conflict resolution in planning. In other words, conflicts am ong the redesign steps w ith regards to otherj design criteria or process requirem ents m ust be detected and resolved. In classical hierarchical planning, such conflicts are solved by em ploying “critics” which examine' 96 th e generated plan, build a validation structure, and apply replanning heuristics (e.g. reordering, deleting, adding) to ensure th e soundness of th e plan [Sac87][Cha87]. In order to reason about conflict resolution in DFA redesign, a unified represen ta tio n of design rationale is proposed to serve as the validation structure. There are th ree types of knowledge (in th e form of design rationale) th a t m ust be consid ered to perform conflict resolution effectively: (1) design constraints im posed by th e product m odel, (2) design requirem ents im posed by th e assem bly and m anufacturing processes, and (3) design rationale from user in p u t unrelated to (1) and (2) such as sim ple designer’s preference. T he unified representation is inferred or transform ed from th e existing knowledge sources, namely, th e redesign cases, product m odel, pro cess m odels, and user input. Figure 9.1 shows th e overall theory and architecture of generating a detailed and product specific redesign advice. 9 .3 .2 In te g r a tio n w ith A sse m b ly P la n n in g i A nother possible extension of R EV -EN G E is th e integration w ith an assem bly plan ner. T he advantages of the integration can be sum m arized as: (1) a m ore com plete and global DFA analysis is possible such as th e identification of design problem s de pendent on a particular to th e assembly process m ay be identified in a form of design rationale. In effect, th e fram ework provides a m ore realistic DFA m ethodology th an trad itio n al m ethods of DFA. 97 Abstract space (REV-ENGE, user customization generation of detailed plan automatic inference Product models Cases Process models Unified DR conflict resolution Detailed space Redesign Plan Steps Figure 9.1: Theory of generating a detailed and product specific redesign advice. 98 A p p e n d ix A Input Data for Container Example This d a ta includes answers to th e yes/no questions in advance for convenience in running th e exam ple. A .l Design (make-assembly ' container "CONTAINER" :type mechanical) (make-part 'base :assembly container :type housing :width <25cm :length <25cm :height <25cm rmaterial plastic :rotational-symmetry "No" :axis-symmetry "No" :grasping-surface "Yes" rsubassembly-stability "Yes" :standard-part "No" :nest/tangle "No" :different-material "No" :moving-part "No") (make-part 'cover :assembly container j :type housing } :width <25cm :length <25cm .•height <10cm .•material plastic :rotational-symmetry "No" 99 :axis-symmetry "No" :grasping-surface "Yes" :subassembly-stability "Yes" :standard-part "No" :nest/tangle "No" :different-material "No" :moving-part "No") (make-part 'screw_l :assembly container :type screw rwidth <10cm :length <10cm :height <10cm :material steel :connected-parts (list base cover) :rotational-symmetry "Yes" :axis-symmetry "No" :grasping-surface "No" :subassembly-stability "No" :standard-part "Yes" :nest/tangle "No" :different-material "Yes" imoving-part "No") (make-feature 'base_hole :part base :width <10cm :length <10cm :height <10cm :type threaded-hole :location single-odd :subtle "No") (make-feature 'cover_hole :part cover :width <10cm :length <10cm :height <10cm :type threaded-hole :location single-odd :subtle "No") 100 (make-liaison 'base_cover_liaison (list base cover) screwing (list base_hole cover_hole) (list screw_l)) (make-function 'base_fl :type main-fn :object-list (list base) :description "container function") (make-function ^cover_fl :type main-fn :object-list (list cover) rdescription "cover function") (make-function * connect_base_cover :type assembly-fn :object-list (list screw_l base_hole cover_hole base_cover_liaison) rdescription "fix base and cover" :assembled-parts (list base cover)) (make-specification ’container_specl :type detail-form :rationale-of (list base cover) :desc "must contain greater than 50 cubic inch") (make-specification ’base_spec3 :type select-form :rationale-of (list base) :desc "must be rectangular") A.2 Assembly Operation (make-subassembly ' subl container :component-list (list base cover)) (make-operation 'ol-align-base-cover 101 :type aligning :special-op nil :realizes (list base_cover_liaison) :parts-involved (list cover base) :major-features (list base_hole cover_hole) :helping-features nil :forms (list subl) :direction -z :active (list cover) rpassive (list base) :fixture nil :equipment (list robot) :constraint nil :description "Align base and cover to hole." :symmetry-in-op "No" :clearance "Yes") (make-operation ’0 2-screw :type screwing :special-op (list fix) :realizes (list base_cover_liaison) :parts-involved (list screw_l subl) :major-features (list base_hole cover_hole) :helping-features nil :forms container :direction -z :active screw.1 :passive cover :next-op-of ol-align-base-cover :fixture minor :equipment (list robot) :constraint nil :description "Screw in screw.l." :symmetry-in-op "Yes" :clearance "Yes") 102 A p p e n d ix B Input Data for Plug Example T his d a ta includes answers to the yes/no questions in advance for convenience in running th e exam ple. B .l Design (make-assembly 'plug "PLUG" :type electro-mechanical) (make-part 'top :assembly plug :type housing :width <10cm .'length <10cm :height <10cm :material plastic :rotational-symmetry "No" :axis-symmetry "No" :grasping-surface "Yes" :subassembly-stability "Yes" :standard-part "Yes" :nest/tangle "No" :different-material "No" :moving-part "No") (make-part 'bottom :assembly plug :type housing :width <10cm :length <10cm :height <10cm rmaterial plastic :rotational-symmetry "No" 103 :axis-symmetry "No" :grasping-surface "Yes" :subassembly-stability "Yes" :standard-part "Yes" :nest/tangle "No" :different-material "No" :moving-part "No") (make-part 'pinl :assembly plug :type terminal-block :width <10cm :length <10cm :height <10cm :material steel :rotational-symmetry "No" :axis-symmetry "Yes" :grasping-surface "Yes" :subassembly-stability "Yes" :standard-part "Yes" :nest/tangle "No" :different-material "Yes" :moving-part "No") (make-part 'pin2 :assembly plug :type terminal-block :width <10cm :length <10cm :height <10cm :material steel :rotational-symmetry "No" :axis-symmetry "Yes" :grasping-surface "Yes" :subassembly-stability "Yes" :standard-part "Yes" :nest/tangle "No" :different-material "Yes" :moving-part "No") (make-part ,screw_l :assembly plug :type screw :connected-parts (list top bottom) 104 :type screw :width <10cm :length <10cm :height <10cm :material steel :rotational-symmetry "Yes" :axis-symmetry "No" :grasping-surface "No" :subassembly-stability "No" :standard-part "Yes" :nest/tangle "No" :different-material "Yes" :moving-part "No") (make-part >nut_l :assembly plug :type nut :connected-parts (list top bottom) :type nut :width <10cm :length CLOcm :height <10cm :material steel rrotational-symmetry "Yes" :axis-symmetry "Yes" :grasping-surface "Yes" :subassembly-stability "Yes" :standard-part "Yes" :nest/tangle "No" :different-material "Yes" :moving-part "No") (make-feature 'top_hole :part top :type threaded-hole :width <lcm .•length <lcm :height <lcm :location center :subtle "No") (make-feature 'bottom.hole 105 :part bottom :type threaded-hole :width <lcm :length <lcm :height <lcm :location center :subtle "No") (make-feature 'sqr.groove :part bottom :type groove :width <lcm :length <lcm :height <lcm :location center :subtle "No") (make-feature 1top.grvl :part top :type groove :width <lcm :length <lcm :height <lcm :location asymmetric :subtle "No") (make-feature 1top_grv2 :part top :type groove :width <lcm :length <lcm :height <lcm :location asymmetric :subtle "No") (make-feature ’bottom.grvl :part bottom :type groove :width <lcm :length <lcm :height <lcm :location asymmetric 106 :subtle "No") (make-feature 'bottom_grv2 :part bottom :type groove :width <lcm :length <lcm :height <lcm :location asymmetric :subtle "No") (make-liaison 'top_bottom_liaison (list top bottom) screwing (list top_hole bottom_hole sqr_groove) (list screw.l nut_l)) (make-liaison ,pinl_bottom_liaison (list pinl bottom) press-fit (list bottom_grvl top_grvl) nil) (make-liaison ,pin2_bottom_liaison (list pin2 bottom) press-fit (list bottom_grv2 top_grv2) nil) (make-function 'top_fl :type main-fn :object-list (list top) :description "plug top cover") (make-function 'bottom_fl :type main-fn :object-list (list bottom) :description "plug bottom cover") (make-function 'pinl_fl :type main-fn :object-list (list pinl) :description "flow current") (make-function Jpin2_fl 107 :type main-fn :object-list (list pin2) :description "flow current") (make-function 'connect_plug :type assembly-fn :object-list (list screw.l nut_l top_hole bottom_hole sqr_groove top_bottom_liaison) :description "assemble the plug" :assembled-parts (list top bottom pinl pin2)) (make-function 'connect_pinl :type assembly-fn :object-list (list bottom_grvl top_grvl pinl_bottom_liaison) :description "assemble pinl between bottom and top" :assembled-parts (list pinl bottom top)) (make-function * connect_pin2 :type assembly-fn :obj ect-list (list bottom_grv2 top_grv2 pin2_bottom_liaison) :description "assemble pin2 between bottom and top" :assembled-parts (list bottom pin2 top)) (make-specification 'plug.spec.l :type create-form :rationale-of (list top bottom) :desc "must be disassemblable") (make-specification 'plug_spec_2 :type select-form :rationale-of (list pinl pin2) :desc "must be made of conducting 108 material") (make-conjecture 'plug_conj_l :type detail-form :rationale-of (list pinl pin2) :desc "its size is fixed since it needs to be plugged into a standard outlet"))) (make-explanation 'plug_exp_l :type detail-form :rationale-of (list top bottom) :desc "shape of body is rectangular for easy grasping") B.2 Assembly Operation (make-subassembly 'subl plug :component-list (list pinl bottom)) (make-operation 'ol-mate-pinl-bottom :type inserting :special-op (list fix) :realizes (list PIN1_BQTT0M_LIAIS0N) :parts-involved (list pinl bottom) :major-features (list bottom_grvl) :helping-features nil :forms (list subl) :direction -z ractive (list pinl) :passive (list bottom) :has-next-op nil :next-op-of nil :fixture minor constraint nil equipment (list robot) :description "Insert pinl to bottom." :symmetry-in-op "Yes" clearance "Yes") 109 (make-subassembly ’ sub2 plug :component-list (list pin2 subl)) (make-operation ’o2-mate-pin2-bottom :type inserting :special-op nil :realizes (list PIN2_B0TT0M_LIAIS0N) :parts-involved (list pin2 subl) :major-features (list bottom_grv2) :helping-features nil :forms (list sub2) :direction -z :active (list pin2) rpassive (list bottom) :next-op-of (list ol-mate-pinl-bottom) . .-fixture nil :equipment (list robot) :constraint nil rdescription "Insert pin2 to bottom." :symmetry-in-op "Yes" :clearance "Yes") (make-subassembly ’ sub3 plug :component-1ist (list top sub2)) (make-operation ’o3-align-top-bottom :type aligning :special-op nil :realizes (list TOP_BOTTOM_LIAISON) rparts-involved (list top sub2) :major-features (list top_hole bottom_hole top.grvl top_grv2 bottom_grvl bottom_grv2) :helping-features nil :forms (list sub3) :direction -z :active (list top) :passive (list bottom) :next-op-of (list o2-mate-pin2-bottom) .-equipment (list robot) :fixture nil 110 :constraint nil :description "Align top on bottom by the hole." :symmetry-in-op "No" :clearance "Yes") (make-subassembly 'sub4 plug :component-list (list nut_l sub3)) (make-operation ’o4-insert-nut :type inserting :special-op (list fix rotating) :realizes (list TQP_B0TT0M_LIAIS0N) :parts-involved (list nut_l sub3) :major-features (list sqr_groove) :helping-features nil :forms (list sub4) :direction -z :active (list nut_l) :passive (list bottom) :next-op-of (list o3-align-top-bottom) • :constraint nil :equipment (list robot) :fixture minor :description "Insert nut_l." :symmetry-in-op "Yes" :clearance "Yes") (make-operation 'o5-screw :type screwing :special-op (list fix rotating) :realizes (list TOP_BOTTOM_LIAISQN) :parts-involved (list screw.1 sub4) :major-features (list top_hole bottom_hole) :helping-features nil :forms (list plug) :direction -z :active (list screw.l) :passive (list top) :next-op-of (list o4-insert-nut) :constraint nil 111 :equipment (list robot) :fixture moderate :description "Screw screw_l." :symmetry-in-op "Yes" :clearance "Yes") 112 Reference List [1] D igital builds a b etter mouse, 1990. Industry Week. [2] M. A ndreason, S. K ahler, and T. Lund. Design fo r Assembly. IF P Publications Ltd. and Springer-Verlag, 1983. [3] A. A raya and S. M ittal. Compiling design plans from descriptions of artifacts and problem solving heuristics. Proceedings o f International Joint Conference on A rtificial Intelligence, pages 552-558, 1987. [4] K. Ashley and K. Sycara. Tutorial: Case-based Reasoning. A m erican Associa tion of Artificial Intelligence, 1991. [5] M. Asimow. Introduction to Design. P rentice Hall, Englewood Cliffs, N J, 1962. [6] R. Bailey. P roduct design for robotic assembly. Proceedings o f the 13th In ter national Sym posium on Industrial Robots and Robots 7, 1:1144-1150, 1983. [7] R. B akerjian. Tool and M anufacturing E ngineer’ s Handbook, fth . Edition: Design fo r M anufacturability, volum e 6. Society of M anufacturing Engineers (SM E), 1992. [8] T. Bardasz and I. Zeid. Dejavu: A case-based reasoning designer’s assistant; shell. Proceedings o f International Conference on A rtificial Intelligence in D e sign, pages 477-496, 1992. [9] C. B audin, C. Sivard, and M. Zweben. Recovery of rationale for design changes: A knowledge-based approach. Proceedings o f IE E E Transactions on System , M an and Cybernetics, pages 745-749, 1990. [10] T. Biggerstaff. Design recovery for m aintenance and reuse. IE E E Com puter, pages 36-47, 1989. [11] G. B oothroyd and P. D ew hurst. Product Design fo r Assem bly Handbook. Boothroyd and D ew hurst, Inc., 1989. [12] G. B oothroyd and W . K night. Design for assembly. IE E E Spectrum , 30:53-55, Sept, 1993. 113 13] S. B radley and A. Agogino. Design capture and inform ation m anagem ent for concurrent design. International Journal o f System s A utom ation: Research and Applications, 1:117— 141, 1991. 14] D. Brown and B. C handrasekaran. Design Problem Solving. M organ K aufm an, 1989. 15] J. Carbonell. D erivational analogy: A theory of reconstructive problem solving and expertise acquisition. M achine Learning: A n Artificial Intelligence A p proach, 2, 1986. 16] A. Chen, D. M cGinnis, D. U llm an, and T. D ietterich. Design history represen tatio n and its basic com puter im plem entation. Design Theory and Methodology- D T M , pages 68-73, 1990. 17] R. Coyne, M. Rosenm an, A. Radford, M. B alachandran, and J. Gero. Knowledge-based Design System s. Addison-Wesley, Reading, M A, 1990. 18] J. de Kleer. An assum ption-based tru th m aintenance system . A rtificial Intelli gence:, 28, 1986. j 19] J. Fiksel and F. H ayes-Roth. Knowledge system s for planning support. IE E E j Expert, pages 16-23, Fall, 1989. 20] S. Finger and J. Dixon. A review of research in m echanical engineering design, p art i: D escriptive, prescriptive and com puter-based m odels of design processes. Research in Engineering Design, pages 57-67, 1989. 21] G. Fischer, A. Lemke, R. M cCall, and A. M orch. M aking argum entation serve design. H um an-C om puter Interaction, 6, 1991. 1 22] B. From ont and D. Sriram . C onstraint satisfaction as a planning process. Pro ceedings o f International Conference on Artificial Intelligence in Design, pages 97-117, 1992. 23] A. Goel. A m odel based approach to case adaptation. Proceedings o f 13th. A nnual Conference o f Cognitive Science Society, pages 143-148, 1991. 24] A. Goel and B. C handrasekaran. Functional representation of design and re-] design problem solving. Proceedings o f International Joint Conference on A r tificial Intelligence, pages 13-17, 1989. ; 25] T. G ruber, C. Baudin, J. Boose, and J. W eber. Design rationale capture as: knowledge acquisition: Tradeoffs in th e design of interactive tools. Technical R eport KSL-91-47, Stanford University, 1991. 114 [26] T. G ruber and D. Russel. G enerative design rationale: Beyond th e record and replay paradigm . Technical R eport KSL-92-59, Stanford University, 1992. [27] K. H am m ond. Case-Based Planning: Viewing Planning as a M em ory Task. A cadem ic Press, 1989. [28] E. H axtquist and H. M arisa. UM -10/2.2 PADL-2 user m anual. Technical report, Cornell Program m able A utom ation, Cornell University, 1988. [29] B. H ayes-Roth and F. Hayes-Roth. Cognitive m odel of planning. Cognitive Science, 3:275-310, 1979. [30] B. H ayes-Roth, F. H ayes-Roth, N. Shapiro, and K. W escourt. P lan n er’s work bench: A com puter aid to replanning. Technical rep o rt, R and Cooperation, 1981. [31] B. H ight. A utom atic attrib u te extraction for assem bly design analysis. Tech nical R eport M EP 8946, M ANE D ept, UCLA, 1989. [32] R. H oekstra. Design for autom ated assembly: An axiom atic and analytical m ethod. S M E Technical Paper, A D 89-416, 1989. [33] W . Hsu, C.S.G. Lee, and S. Su. Feedback evaluation of assembly plans. Tech nical Report, TR-ERC -92-3, Purdue University, 1992. [34] V. H ubka and W . Eder. Principles o f Engineering Design. B utterw orth Scien tific, 1982. [35] M. H uhns and R. Acosta. ARGO: An analogical reasoning system for solv ing design problem s. Technical R eport AI/CAD-092-87, M icroelectronics and C om puter Technology C orporation, A ustin, TX , 1987. [36] M. Inui and F. Kim ura. R epresentation and m anipulation of design and m an ufacturing process by d a ta dependency. Proceedgins o f IF IP Workshop in In telligent C A D , pages 169-182, 1990. [37] M. Jakiela. Intelligent suggestive CAD system s. Proceedings o f M IT -JS M E W orkshop in Cooperative Product Development, 1989. [38] S. K am bahm pati. M apping and retrieval during plan reuse: A validation struc tu re based approach. Proceedings o f N ational Conference on A rtificial Intelli gence, pages 170-175, 1990. [39] S. K am bahm pati. A theory of plan m odification. Proceedings o f N ational Con ference on Artificial Intelligence, pages 176-182, 1990. 115 [40] G. Kim and G. Bekey. AEX: A DFA analysis and advisory system . Proceedings o f IE E E Transactions on System , M an and Cybernetics, 1990. [41] G. K im and G. Bekey. Redesign by reverse engineering. Workshop Notes, A A A I W orkshop on Design Rationale Capture and Use, pages 147-153, 1992. [42] G. K im and G. Bekey. Design-for-assembly by reverse engineering. To appear in Proceedings o f International Conference on Artificial Intelligence in Design, 1994. [43] G. Kim , G. Bekey, and K. Goldberg. A shape m etric for design for assembly. Proceedings o f IE E E International Conference on Robotics and A utom ation, 1992. [44] J. Kolodner. Case-based Reasoning. M organ K aufm ann, 1993. [45] T . KufEner and D. Ullm an. The inform ation requests of m echanical design engineers. Proceedings o f Design Theory and Methodology Conference, 1990. [46] F. Lakin, H. W am baugh, L. Leifer, D. Cannon, and C. Sivard. T he electronic design notebook: Perform ing m edium and processing m edium . Visual Com puter: International Journal o f Com puter Graphics, 5:214-226, 1989. [47] N. Langrana, T. M itchell, and N. R am achandran. Progress tow ard a knowledge- based aid for m echanical design. Proceedings o f A S M E W inter A nnual M eeting, 1986. [48] C.S.G. Lee, W . Hsu, and S. Su. Feedback evaluation of assembly plans. Pro ceedings o f IE E E International Conference on Robotics and A utom ation, pages 2419-2424, 1992. [49] D. Lee and M. Melkanoff. P roduct design analysis using th e assem bly design evaluation m etric. Proceedings o f the A S M E Com puters in Engineering, Aug, 1991. [50] J. Lee. SIBYL: A tool for m anaging group decision rationale. Proceedings o f Conference on Com puter Supported Cooperative Work, pages 79-92, 1992. j t [51] S. Lee. Backw ard assembly planning w ith assembly cost analysis. Proceedings o f IE E E International Conference on Robotics and A utom ation, pages 2382-2391,1 1992. [52] M. L. M aher. Process m odels for design synthesis. A I M agazine, 11:49-58, W inter, 1990. [53] C. M anoharan, H. W ang, and A. Soom. An expert system for design for robotic assembly. Journal o f Intelligent M anufacturing, 1:17-29, 1990. 116 [54] R. M cCall. Issue serve system : A descriptive theory for design. Design M ethods and Theories, 20:443^458, 1986. [55] Miles. Design for assembly - a key elem ent w ithin design for m anufacture. Proceedings o f Institution o f M echanical Engineers, 203, 1989. [56] S. M inton, C. Knoblock, D. Kuokka, Y. Gil, R. Joseph, and J. Carbonell. Prodigy 2.0: The m anual and tutorial. Technical R eport CMU-CS-89-146, Carnegie Mellon University, 1989. [57] J. Mostow. Design by derivational analogy: Issues in the autom ated replay of design plans. Artificial Intelligence, 40:119-184, 1989. [58] J. Mostow and M. Barley. A utom ated reuse of design plans. Proceedings of International Conference on Engineering Design, pages 632-647, 1987. [59] J. M unyer. Ph.D . Thesis: Analogy as a M eans o f Discovery in Problem Solving and Learning. PhD thesis, Univ. of California, Santa Cruz, 1981. [60] S. M urthy and S. Addanki. PR O M PT : An innovative design tool. Proceedings o f N ational Conference on Artificial Intelligence, pages 637-642, 1987. j [61] B. M yers, D. Guise, R. D annenberg, B. V. Zanden, D. Kosbie, P. M archal,) E. Pervin, A. M ickish, J. Landay, R. M cdaniel, and D. Hopkins. T he garnet reference m anuals revised for version 2.1. Technical R eport CMU-CS-90-117- R3, Carnegie Mellon University, 1992. [62] D. N avinchandra. Exploration and Innovation in Design. Springer-Verlag, 1991. [63] P. Norvig. Paradigms o f Artificial Intelligence. M organ K aufm ann, 1993. [64] Ohashi and Miyakawa. The H itachi assem blability m ethod (AEM ). Interna tional Conference on Product Design fo r Assembly, 1986. [65] M. O relup, P. Cohen, J. Dixon, and M. Simmons. Dominic 2: M etal level control of iterative redesign. Proceedings o f National Conference on Artificial Intelligence, pages 25-30, 1987. [66] S. Owen. Analogy fo r A utom ated Reasoning. A cadem ic Press, 1990. [67] G. Pahl and W . Beitz (E dited by K. W allace). Engineering Design. T he Design, Council, Springer Verlag, 1984. ! i [68] B. Rao and S. Lu. Inverse engineering: Supporting synthesis activities in en gineering decision m aking. Annual Report, Knowledge Based Engineering Sys tem s Research Laboratory, pages 153-160, 1992. 117 [69] G. R yder, A pr 1992. Personal Com m unication. [70 [71 [72 [73 [74 [75 [76 [77 [78 [79 [80 [81 [82 E. Sarcedoti. Planning in a hierarchy of abstraction spaces. Artificial Intelli gence,, 5:115-135, 1974. D. Shema, J. Bradshaw , J. Covington, and J. Boose. Design knowledge capture and alternative generation using possibility tables in CA NARD. Knowledge Acquisition 2(4), pages 345-364, 1990. R. Simmons and R. Davis. G enerate, test and debug: Com bining associational rules and causal models. Proceedings o f International Joint Conference on A r tificial Intelligence, pages 1071— 1078, 1987. M. Stefik. Planning and m eta-planning (M OLGEN: P art 2). A rtificial Intelli gence, , 16:141-170, 1981. L. Steinberg. Design as refinem ent plus constraint propagation: The V EX ED experience. Proceedings o f N ational Conference on Artificial Intelligence, 1987. L. Steinberg and T. M itchell. T he Redesign system : A knowledge-based ap proach to VLSI CAD. IE E E Design and Test, pages 45-54, Feb, 1985. H. Stoll. Design for m anufacture. M anufacturing Engineering, pages 67-73, Jan , 1988. R. Sturges and J. Yang. Design for assembly evaluation of orientation difficulty features. Technical R eport ED RC-24-78-92, Carnegie Mellon University, 1992. G. Sussm an. A Com puter Model o f Skill Acquisition. A m erican Elsevier, 1977. Sapphire Design Systems. User M anual o f Assem bly View. Sapphire Design System s, Inc., 1989. D. U llm an, T. D ietterich, and L. Stauffer. A m odel of th e m echanical design process based on em pirical data. A I ED AM , 2:33-52, 1988. T. W elter. Designing for m anufacture and assembly, Sept 1990. Industry Week. R. W ilensky. Planning and Understanding. Addison-W esley, 1983. 118

Linked assets