- Email: [email protected]
Assembly sequence planning using case-based reasoning techniques
Assembly sequence planning using case-based reasoning techniques P Pu and M Reschberger
Future computer aided design (CAD) systems will be not only smart, but also efficient in terms of solution strategies as well as time costs. This paper presents a problem-solving paradigm, namely case-based reasoning (CBR), and shows how it solves some constraintoriented design problems efficiently. CBR solves a new problem by retrieving from its case library a solution which has solved a similar problem in the past and then adapting the solution to the new problem. The efficiency of such a system relies on the completeness and compactness (small size) of such a case library. These two characteristics of a case library in turn rely on an indexing scheme for the set of cases in the library. How these issues can be solved and how a case-based reasoning system can be designed for such problems is illustrated here, and the authors' theory is presented as it is applied to the area of assembly sequence planning. Keywords: case-based reasoning, constraint-oriented design, assembly sequence planning Case-based reasoning (CBR) 1-3 provides an efficient strategy for solving problems, since systems designed by such techniques remember old solutions and apply them to new problems whenever circumstances permit. This paradigm also permits us to apply expertise in a domain where rules are hard to define. Problem solving using CBR techniques usually involves retrieving relevant previous solutions, adapting and combining previous solutions to solve the new problem, and recording failures so that they can be avoided in the future. The efficiency of such a system relies on the completeness and compactness of such a case library. These two characteristics of a case library in turn rely on an indexing scheme for the set of cases in the library. Department of Computer Science and Engineering, Universityof Connecticut,Storrs, CT 06269-3155, USA This paper was awarded the Best KBS Paper Prize at the Artificial Intelligence in Design '91 Conference Edinburgh, UK (25-27 June 1991) Vol 4 No 3 September 1 9 9 1
Many design problems are computationally expensive, thus providing a good domain to apply CBR techniques. This paper examines the domain of assembly sequence planning (ASP) 4-7 and analyses how CBR techniques can be applied to such a domain. Although it is often called planning, ASP problems are a type of constraint-oriented design problems in a sense that a goal is to be achieved while a set of constraints are to be satisfied. Illustrated in Figure 1, the ball-point pen is an example of ASP problems. The goal is to provide a sequence to assemble two parts at a time without backtracking so that the final configuration (a set of constraints) of the product is satisfied. One solution to this problem is to place the ink inside the tube, place the ink-tube inside the body, put on the head, put on the button, and finally put on the cap. A common mistake is to overlook the spatial relationship between the ink, tube, body, head, and button and to suggest putting the head and button on to the body before the tube and ink are placed inside the body. An initial examination of the nature of ASP problems made us realize that the goal-oriented planning paradigm (as in CHEF s, for example) found in the current CBR literature does not satisfactorily provide a model for solving design problems. CHEF takes a set of goals (e.g. 'give me a stir-fry with chicken and broccoli') as input and generates recipes that satisfy these goals. ASP requires a set of constraints to be given as input. While the goals in CHEF can be readily used to index the case library to facilitate the search for candidate cases, it is much less clear how the given constraints (being the only input to the ASP problems) can be used to guide the search. In a later section we discuss this observation in more detail. Only when we examine the constraints more closely do we realize that they give rise to many implicit goals. So somehow each problem must be decomposed into subproblems so that a CBR system can select from the case library the appropriate cases for each of the subproblems. This paper will examine four key issues related to the design of such a CBR system which solves constraint-oriented design problems: (a) how to succes-
0950-7051/91/030123-08 © 1991 Butterworth-Heinemann Ltd
123
Cap
Figure l.
Head
Body
Tube
Ink
The ball-point pen as an example of the A S P problems
sively decompose a given problem, (b) how to represent the cases in the case library, (c) how to control the search space, and (d) how to select the best case. These discussions are preceded by a section where we define what an ASP problem is. Our CBR system, CAB-Assembler, is fully implemented. Thus we describe the other components of the system after we have presented the theory. Several example devices which CAB-Assembler successfully solved are discussed in the performance section. Some run-time measures are also shown there to illustrate the performance of our system. Finally we conclude the paper by recapitulating the main points of this work and pointing out some important issues which are subject to further investigation.
Cap
a
Stick
Stick
PROBLEM DESCRIPTION The problem of finding a sequence with which the parts of a product can be assembled is called the assembly sequence planning problem. One of the valid sequences for the receptacle device shown in Figure 2a is as follows7: {(cap) (handle) (receptacle) (stick)} --, {(cap receptacle) (handle) (stick)} -~ {(cap receptacle stick) (handle)} -~ {(cap receptacle stick handle)} Each union of two pairs of parentheses defines an assembly operation. The input to an ASP system is always the set of objects or parts of a product in a totally disassembled state. Since the product has been successfully designed, there is a unique configuration with which the parts are arranged. This configuration, which is also part of the input, is called the relational model by Bourjault9 and defines a set of constraints on the set of parts. The relational model of the receptacle device is shown in Figure 2b. The labels on each arch of the relational model (or graph) are specifications of constraints among the parts. For example, it is specified that the cap is to be connected with the receptacle via a threaded-cylindrical contact (screwing on), the stick to be connected with the receptacle via a cylindrical contact (putting it inside), etc. But the relation model does not define the assembly order: it does not specify that the stick must be put inside the receptacle before both cap and handle are screwed into the receptacle. In a product, a part is the smallest non-decomposable entity. When two parts are joined, they form a subassembly. A part can also be joined with a subassembly to form another subassembly. We use the word piece to refer to either a part or a subassembly. An assembly plan, the output, is an ordered sequence of (assemble A B) actions where A and B are both pieces. Notice that one does not have to pay attention to how A and
Handle
Receptacle
]
Type: planar J normal: (0 1 0 ) / / / / ype: threadedylindrical
/
124
Button
VType: cylindrical axis: ((0 0 O)
J
'°! °'
Type." threadedcylindrical Receptacle I
Figure 2. model
@
[ Hald,e J
(a) The receptacle device (b) Its relational
B are put together, for instance whether they are joined by a planar, or threaded-cylindrical contact. These relations are called contact and attachment relations by Homem de Mello 6. This information is provided by the designer.
CBR SYSTEM FOR ASP To design an efficient CBR system, we have identified two important issues: a complete and compact case library and an effective indexing scheme. By a complete case library, we refer to the fact that after a small training period the CBR system should be able to solve most of the problems in the domain without having to add more cases to the library. By compactness, we mean a small and manageable case library. By an effective indexing scheme, we mean the ability to retrieve similar cases and the successfulness of applying these cases to new problems. The intuition of our solution to these issues is that we keep a library of cases that correspond to subsolutions so that a whole problem is solved by combining subsolutions, and we use constraints, which are input to the ASP process, as indices to organize cases. The reason why the library designed this way is small and complete is because in many engineering domains, problems are composed of a set of primitives, or so-called building blocks. For instance, in the electrical circuit domain, systems consist of AND, OR, and NAND gates at the gate level. Knowledge-Based Systems
enclosure. Figure 4 shows the stage just before the receptacle case is applied. In the next section, we will discuss our case representation. We illustrate how a case (called the fundamental case) which just assembles two pieces together and the receptacle are kept in the case library. To solve the box example, our system uses the fundamental case four times to put the walls together and the receptacle case once to place the ball inside the box.
In certain mechanical domains, building blocks are gears, ratchets, levers, and linkages. In the ASP domain, there is on the order of 10 basic ways of combining parts into subassemblies. In the next few sections of this paper, the solution to these issues is explained in detail. Several examples are used throughout these sections for illustrational purposes. We describe these examples first, as follows. The three devices shown in Figure 3 are different devices at first glance. Under closer examination, we realize that all three devices have a common enclosure characteristic: some parts in these devices eventually form a spatial enclosure; some parts of these devices must be placed inside the enclosure before it is completely formed. But how does one recognize that the enclosure characteristic is common in all three devices so that the solution for the receptacle can be applied to the ball-point pen and box, for example? For assembling the box, somehow the system has to first put the wall pieces together before it can use the receptacle solution to solve the enclosure characteristic. How can that be done?
Case library Almost no two devices have exactly the same compositions. Thus our case library captures a set of subsolutions (building blocks), such as the enclosure case and the fundamental case, rather than complete device assemblies. The case library accommodates all ASP problems we studied with a small set of cases. Each case corresponds to one step in assembling a subassembly. It has the following representation: • the abstract problem description (= APD, generalization) which is a set of features, where each feature defines a particular characteristic of a problem • feature weights • success and failure history • the plan
Successive reminding Suppose we know how to solve the receptacle device and want to use this experience to solve the box example. Initially it is hard to see the enclosure with the given seven pieces of the box. But if four walls were assembled together, we would begin to be reminded of the receptacle. Thus such an enclosure characteristic may only be apparent to us sometimes in a later stage of our planning process. The successive reminding idea is to make the system apply those solutions that remind it of the current stage of the assembly process. For this box example, the system is to be reminded of a case which just puts two pieces together in the beginning. Hopefully the system applies this solution until the wall pieces and the bottom of the box have been connected. Then the system is to be reminded of the receptacle case in order to solve the
Cap
Stick
Receptacle
Table 1 illustrates the case representation of the receptacle device (Figure 2a). In the beginning, all #succ and #fail fields are initialized to 1 and 0 respectively. Each piece involved in the case is a mandatory feature and has the highest weight, 6. Later on we discuss how other optional features can be included with lower weights. Although Table 1 presents the ASP solution of an entire device, it can be used to solve the ballpoint pen (Figure 1) partially. More precisely, it solves the enclosure problem in the ball-point pen. In fact, most cases represent solutions to subproblems. Shown in Table 2 is a solution used to partially assemble many devices. For our own convenience, we call such a case the pan-with-cover case, but it can be used to assemble
Handle
a
i, Cap Head
,
Body
Tube
b Figure 3.
Ink
Button
C
(a) Receptacle (b) Ball-point pen (c) Box
Vol 4 No 3 September 1991
125
® Figure 4. Table 1.
A partially assembled box The case representation of the receptacle device
Feature
Weight
Number of successes
Number of failures
Receptacle Cap Stick Handle
6 6 6 6
1 1 1 1
0 0 0 0
Solution:
Table 2. Feature Pan Cover Surf-surf Pan cover Solution:
{(receptacle handle) (stick)(cover)} {(receptacle handle stick)(cover)} {(receptacle handle stick cover)}
The case representation of a pan-cover device Weight
Number of successes
Number of failures
6 6 6
1 1 1
0 0 0
Selecting the best case { (pan cover) }
any two pieces if they are connected via the surfacesurface contact. To facilitate matching, a set of features (or feature vector) is associated with each case as an index and serves as the generalization of a problem. In other words, this set of features represents the characteristics of not only this particular case, but also a class of similar cases. We will elaborate on the indexing issue further in the next section. Each feature in the feature vector has the following additional information: feature weight and success and failure histories. The weight assignment gives preference to the more important features. Success and failure histories help the system select the best case in the future by recording experimental data. For each case, a plan or solution is attached so that once this case is chosen for a new problem, the solution is applied. Since the library is kept small, it is ordered sequentially instead of in a more sophisticated way, such as MOPs
3,1°.
Controlling the search The problem introduced by the successive reminding approach is a severe search problem which is illustrated with the following scenario. 126
The input to the system is a device in a totally disassembled state. The challenge is to identify in this totally disassembled device which characteristic problem in the case library to apply and when. This defines a large search space since there are usually a lot more parts involved in a disassembled device than those involved in a characteristic case. Doing the problem mathematically, the space is exponential. When the box example is initially matched with the receptacle case, there are 840 different ways of matching these two problems. The box initially has seven pieces and the receptacle case has four. Taking a permutation of four out of seven each time, there are 7 x 6 x 5 x 4 = 8 4 0 distinctive ways. This is computationally too expensive! With closer examination of the problem, we came up with a much more efficient way to do this task. Each case in the library and the ASP problem at hand are defined with a set of features. If we just include the number of pieces as mandatory elements in the feature field, the search space is exponential. However, once we include geometrical constraints as mandatory elements in the feature field, we came down to 187 possible combinations for this example. With the inclusion of spatial constraints, we came down further to 10 possible combinations. By including geometrical and spatial constraints in the feature field, we have avoided comparing incomparable cases. One observation is necessary here. The geometrical and spatial constraints are merely relationships between the parts of a device, which are presumed to be available in a data file. Thus these constraints do not require any overhead on the part of the users.
There are still 10 ways to fit the box into the receptacle case. If the case library contains more cases, the search space is still quite large. Determining the best case(s) is important to any CBR system. Many systems use heuristic metrics u-~s to determine the similarity between two cases. Often such a metric is domaindependent and requires a set of desiderata to be defined first. Our approach is quantitative and calculates a priority in terms of the usefulness of each feature using information from past experiences. For each feature, we calculate its priority as follows: 0 if m a n d a t o r y features do not m a t c h or
priority (F) =
#successes < #failures
~ r ~ s #successes
*
(#successes - - #fatlures) otherwise "
•
The priority of a case is the sum of the product of each feature priority and its weight. The formula for each feature is justified by the following considerations: 1 Match: if the feature of a case does not match with the feature of the problem at hand, the priority is neutral (=zero). 2 Success ratio: measure the number of successes over the total number of times this feature is selected. 3 Exaggeration: if a case is very successful, the chance of selecting it should be increased (encouragement); Knowledge-Based Systems
Repair r . . . . . . . ~"
Past experience I _ Update = case base ~ ....
Feature weights The features should not only be divided into important (mandatory) and unimportant (optional) but they should also be further subdivided into degrees of importance, also called weights. The overall range of the weights should depend on how exactly the differences among the features can be determined. This is very domain specific. For the ASP domain we use a range between 1 and 6. Plan In the ASP domain an action and also a group of actions can be represented by using 'assemble' and 'not assemble' as the only two operators. Some examples for the internal representation of plans are: (1) (assemble 1 2) (2) (not assemble 2 3) (3) (not assemble 1 3) where 1, 2, and 3 are piece variables. 'Not assemble' is important in avoiding failures. This operation is often included in a plan after a failure has occurred.
- -
Control and data flow
Figure 5. System architecturefor CAB-Assembler if a case has had many failures, the chance of selecting it should be decreased (punishment). 4 Weight: a feature which is supposed to be more important (higher weight) should have a higher chance of influencing the case priority than one that is of less importance. This is called 'salient-feature preference '13. The case base is initialized to 1 for all #successes fields and 0 for all #failure fields. By considering the successand failure-history of a feature and therefore of a case, the reasoner selects not only the most similar, but also the most useful case for a problem 13. HYPO 11.12 uses previous experience in the form of weights (called 'factors' or 'dimensions') in order to assess similarity. However that method is combined with information about the reasoner's task. Also the reasoner uses the weights only partially (notion of 'least commitment approach'). That method is therefore not suitable for the ASP domain.
OVERVIEW OF CAB-ASSEMBLER CAB-Assembler is an implementation of the ideas presented here and has various other components besides issues discussed earlier. A flow chart of how the system works is shown in Figure 5. We briefly describe the other components of the system as follows:
Input The input to the search and case selection mechanism of the case-based system are • the current state of a device (totally or partially disassembled), described in terms of predicate relations, • the case base. Vol 4 No 3 September 1991
Success and failure history The number of successes tells how often this case has contributed to successfully reaching a goal state when this specific feature matched with the new problem. However, if the goal state is not reached and this case with its 'bad' plan is declared as the reason for failure, all features that matched are increased by one for the #failure field. Combining plans The matching algorithm returns the results of the case examinations. These results are sorted in a descending order according to case priorities. The best plan is combined with the plan of the second closest case, the plan of the third closest case, and so on - until a specific action is found. Failure detection and error locating Failure-driven learning depends on the detection of the failure and on finding the reason for this failure. It is admitted as a very difficult task 1.3,8. Using a heuristic approach is a common way of locating the error. The implemented system solves this problem by simply asking the user whether the proposed action is acceptable. Similar to failure detection, locating the reason for failure is only important in the training stage. Therefore it is also solved through user interaction. Once the reason for failure is located, we know which action has caused the failure. Two methods are used in order to avoid repeating the same failure again: memorizing the failure and creating a new case for solving this problem. Whenever failure appears, both methods are applied. Learning by success When people solve a problem successfully, they tend to be encouraged by such an experience. Sometime later if the same or a similar problem appears they tend to use a plan that was more successful rather than one that has not been. In order to prefer the selection of a case, and with the case automatically its plan which was very successful in the past, success is memorized in a case. We 127
discussed this issue already in the paragraph on successand failure-history.
CAB-ASSEMBLER'S P E R F O R M A N C E Spatial reasoning has been particularly difficult in the ASP domain6. However many spatial problems, although different on the surface, share many similar characteristics. Thus our observation is that if spatial problems are difficult, not every one of them has to be solved from scratch. We go through two spatial examples in this section, step by step, to show how our system works, and discuss the performance in terms of time costs. The first example, the receptacle device, is meant to show how a case base is initially established. It encounters failures and is corrected by users via an interactive mode. Once a case base is established, we show that it offers flexibility in terms of solving similar problems. Furthermore, our research results show that it is best to train a case base with a more complicated example in order to accumulate more experiences. The case development for the bail-point pen is quite long, and thus is omitted here. See Reference 14 for detailed transcriptions. But we will show how the case base trained by the ball-point pen can be used to solve the receptacle case without failure (example 2). The receptacle example represents a typical enclosure problem: the stick cannot be put into its place after the other three parts already form a subassembly. The scenario:
Step 1: input: {cap handle receptacle stick), 'cb. fund'. The device is completely disassembled. The reasoner decides to assemble the parts cap and receptacle. Step 2: input: {(cap receptacle) handle stick), 'cb.fund'. The reasoner decides to connect the subassembly '(cap receptacle)' with the part 'handle'. Step 3" input: {(handle cap receptacle) stick), 'cb. fund'. The action 'connect stick (handle cap receptacle)' cannot be performed. Failure OccurS.
The action which connected the part 'handle' with the subassembly '(cap receptacle)' is blamed for the failure. The reasoner creates a new case which contains three pieces referred to as 'handle', '(cap receptacle)', and 'stick', respectively. The plan of the new case should in the future prevent the reasoner from connecting the pieces 'handle' and '(cap receptacle)' again. This prevention should not only work for the same problem, but also for any other situations similar to this one. The second part of the following transcript shows that the improved case base avoids making the same mistake, and solves this example successfully: *** start of transcript * ** (solve-problem "prob.rec.vert.sl" "cb.fund")
i am in training-mode Do you accept to connect piece (CAP) with piece (RECEPTACLE)? (y/n) ~ y 128
Do you accept to connect piece (HANDLE) with piece (CAP RECEPTACLE) ? (y/n) ~ y Do you accept to connect piece (STICK) with piece (HANDLE CAP RECEPTACLE) ? (y/n) ~ n Was connecting (CAP) with (RECEPTACLE) the error? (y/n) ~ n Was connecting (HANDLE) with (CAP RECEPTACLE) the error? (y/n) ~ y remembering SUCCESS for case FUNDAMENTALCASE bad case: FUNDAMENTAL-CASE Should (STICK) be added to the new case? (y/n) ~ y Should (HANDLE) be kept in the case? (y/n) ~ y Should (CAP RECEPTACLE) be kept in the case? (y/n) ~ y How would you like to name the new case? name ~ rec-1 remembering FAILURE for case FUNDAMENTALCASE Name for new case base---, cb.rec.1 storing improved case base in file CB.REC. 1 end of problem solving NIL (solve-problem "prob.rec.vert.sl" "cb.rec.l") i am in training-mode Do you accept to connect piece (RECEPTACLE) with piece (CAP) ? (y/n) ---, y Do you accept to connect piece (RECEPTACLE CAP) with piece (STICK) ? (y/n) ~ y Do you accept to connect piece (HANDLE) with piece (RECEPTACLE CAP STICK) ? (y/n) ~ y remembering SUCCESS for case REC-1 remembering SUCCESS for case REC-1 remembering SUCCESS for case FUNDAMENTALCASE Name for new case base ~ cb.rec.l.2 storing improved case base in file CB.REC. 1.2 end of problem solving NIL *** end of transcript *** Knowledge-Based Systems
Table 3.
Run-time behaviour - receptacle example
Pieces left to assemble
cb.fund
cb.rec.l
cb.pen.4
8 5 3f
19 10 4 --~2
54 17 10 =2
--
35
83
4 3 2 1
Table 4.
Column four (cb.pen.4) shows that the case library created for solving the ball-point pen (Figure 3b) can be used to solve the receptacle device. The significance here is that our system can be trained to solve a class of problems. In this case, both the receptacle device and the ball-point pen are part of the class of enclosure problems. Furthermore, if the system is trained to solve a more difficult problem in the same class, it can solve a simpler one without much failure. Several observations from the experiment are summarized here:
Run-time behaviour - ball-point pen example
Pieces left to assemble cb.fund cb.pen.1 cb.pen.2 cb.pen.3 cb.pen.4 cb.afi.5 6 5 4 3 2 1
17 12 9 6 4f
Y
.
24 18 13 8f
.
40 28 18 9 4f
.
56 37 22 9 5f
.
108 47 27 13 5 ~2
91 48 25 13 5 ~2
202
184
In the following transcript, prob.rec.vert.sl is the receptacle problem given to the system. The case base is cb.pen.4 which is obtained by training the system with the ball-point pen example. *** start of transcript ***
• The more pieces an assembly has, the longer it takes to calculate the next action. • The more cases a case base has, the longer is the run-time. • The number of pieces affects the run-time more than the number of cases does. Other problems our system solved included interlocking blocks and an assembly from industry which has 11 parts. Both of these have been studied by researchers in the ASP field. The run-time cost of the AFI problem is 3317 seconds (or 55 minutes), a rather low figure which we have not seen in other ASP systems.
RELATED WORKS
(solve-problem "prob.rec.vert.sl" "cb.pen.4")
Traditional assembly sequence planning methods
i am in training-mode Do you accept to connect piece (RECEPTACLE) with piece (HANDLE) ? (y/n) --~ y
The ideas on ASP problems described by References 4, 6, 7 and 9 have influenced our work in terms of representing the problem and understanding the nature of the problem. However, these methods are highly computationaUy intensive. Knowledge-based systems normally use heuristics to maximize the efficiency. De Fazio and Whitney 5 proposed a rule-based expert system to solve ASP problems. Some ASP problems, such as the interlocking blocks, pose constraints that are non-linear and cannot be solved by rules. Our system takes advantage of the observation that 'if ASP problems are generally computationaUy hard, not every one of them has to be solved from scratch.' Thus the first-principled method by Homem de Mello 6, for instance, can be viewed as the resort we come to when our system fails to retrieve a similar problem. However, most of the time the system can solve ASP problems by using past experiences efficiently, as we have shown in the performance tables.
Do you accept to connect piece (CAP) with piece (STICK) ? (y/n) ~ y Do you accept to connect piece (RECEPTACLE H A N D L E ) with piece (CAP STICK) ? (y/n) ~ y remembering SUCCESS for case PEN-4 remembering SUCCESS for case PEN-4 Name for new case base ~ cb.xy storing improved case base in file CB.XY end of problem solving NIL *** end of transcript *** Tables 3 and 4 illustrate the run-time to train the receptacle and ball-point pen case base. Each table shows the development of a case base from left to fight. If an action is not valid (failure), the label 'f' is used in that table entry. Each entry is the amount of time (in seconds) the system takes to come up with an assembly operation. Table 2 shows that it takes one failure to create a case base capable of solving the receptacle problem. Vol 4 No 3 September 1991
Case-based systems The major finding of this work is that current techniques, such as CHEF 2, in CBR address goal-oriented planning, rather than constraint-oriented planning which is more common in the engineering domain. Each case in the case library captures the solution of an entire problem, instead of the characteristic subproblems which comprise the whole. Thus it does not provide a model for ASP problems or other constraintoriented planning problems. Those CBR systems that did address engineering problem-solving issues 15n6tend to follow the goal-oriented paradigm also. 129
CONCLUSIONS AND FUTURE WORK The success of our approach relies on two factors: it solves new problems by retrieving subsolutions instead of complete solutions and it keeps a small case library of the primitives of the problem domain. To achieve the first, we must perform what is called successive reminding. Furthermore, an effective indexing scheme must be used so that at each stage of the assembly process, the system retrieves the right subsolution. To achieve the second, we observe that in the ASP and many other engineering domains, the underlying set of primitives which serve as building blocks for the whole class of problems is a small set. In the ASP case, there are on the order of ten primitive problems. Designing a CBR system with this principle in mind avoids a large case library, and thus achieves efficiency. We have studied heavily the enclosure problem in this research, since it is the most time-consuming one if first-principled approaches are used 6, which involve the use of path-planning algorithms. Our future work will include the further study of other characteristic problems. In Homem de Mello's work, there is a classification of what he called preference relations, of which enclosure is one (called the ordering preference). From our experience with the enclosure problem, it is a matter of training a case base with the capability of solving certain preference relations. The formula for calculating the best case or cases is subject to further study. For all the cases we tried with our current implementation, there are no undesirable behaviours found in the system. But this is not a satisfactory answer on theoretical bases. We are currently looking at mathematical treatments of distance functions in treating similarities (in our case, relevancy). One possible solution is to make the formula calculating how irrelevant a case is to a problem. Thus the best case is the one that is least irrelevant to the problem. If such a least distance formula can be shown to satisfy the triangular inequality 17, then it is guaranteed that the system will converge. That is, the more experiments we perform with the system, the better it is in terms of dealing with the selection of best cases. REFERENCES 1 Kolodner, J L (Ed.) Proceedings of 1st Case-Based Reasoning Workshop Morgan Kaufmann (1988) 2 Hammond, K J (Ed.) Proceedings of 2nd CaseBased Reasoning Workshop Morgan Kaufmann (1989)
130
3 Riesbeck, R and Schank, R Inside Case-based Reasoning Lawrence Erlbaum (1989) 4 Sanderson, A C and Homem de Mello, L S Task
Planning and Control Synthesis for Flexible Assembly Systems Springer-Verlag (1987) pp 331-353 5 De Fazio, T L and Whitney, D E 'Simplified generation of all mechanical assembly sequences' IEEE Journal of Robotics and Automation (December 1987) pp 705-708 6 Homem de Mello, L Task Sequence Planning for Robotic Assembly PhD Thesis, Carnegie Mellon University, Pittsburgh, USA (1989) 7 Sanderson, A C, Homem de Mello, L Z and Zhang, H 'Assembly sequence planning' AI Magazine Vol 11 No 1 (1990) pp 62-81 8 Hammond, K J Case-based Planning: ViewingPlanning as a Memory Task Academic Press, San Diego (1989) 9 Bourjault, A Contribution a une Approche Metho-
dologique de L'Assemblage Automatisd: Elaboration Automatique des S~quences Op~ratoires. Technical Report (Th~se d'l~tat), Universit6 de Franche-Comt6, Besan~on, France (1984) 10 Schank, R Dynamic Memory: A Theory of Learning in Computers and People Cambridge University Press (1982) 11 Ashley, K D and Rissland, E L 'Compare and contrast, a test of expertise' in Kolodner, J L (ed)
Proceedings of 1st Case-BasedReasoning Workshop 12
13 14
15
16
Morgan Kaufmann (1988) pp 31-36 Ashley, K D and Rissland, E L 'Weighting on weighting: a symbolic least commitment approach' in Proceedings of 7th National Conf. on Artificial Intelligence (1988) pp 239-244 Kolodner, J L 'Judging which is the "best" case for a case-based reasoner' Proceedings of 2nd CaseBased Reasoning Workshop (1989) pp 77-81 Reschberger, M Case-Based Reasoning for Assembly Sequence Planning Technical Report CSE-TR90-25, Department of Computer Science and Engineering, University of Connecticut, USA (1990) Barletta, R and Mark, W 1988 'Explanation-based indexing of cases' in Kolodner J L (ed), Proceedings of 1st Case-Based Reasoning Workshop Morgan Kaufmann (1988) Navinchandra, D 'Case-based reasoning in cyclops, a design problem solver' in Kolodner J L (ed)
Proceedings of 1st Case-Based Reasoning Workshop Morgan Kaufmann (1988) 17 Conte, S D and de Boor, C Elementary Numerical Analysis: An Algorithmic Approach McGraw-Hill Book Company, 3rd edition (1980)
Knowledge-Based Systems
Future computer aided design (CAD) systems will be not only smart, but also efficient in terms of solution strategies as well as time costs. This paper presents a problem-solving paradigm, namely case-based reasoning (CBR), and shows how it solves some constraintoriented design problems efficiently. CBR solves a new problem by retrieving from its case library a solution which has solved a similar problem in the past and then adapting the solution to the new problem. The efficiency of such a system relies on the completeness and compactness (small size) of such a case library. These two characteristics of a case library in turn rely on an indexing scheme for the set of cases in the library. How these issues can be solved and how a case-based reasoning system can be designed for such problems is illustrated here, and the authors' theory is presented as it is applied to the area of assembly sequence planning. Keywords: case-based reasoning, constraint-oriented design, assembly sequence planning Case-based reasoning (CBR) 1-3 provides an efficient strategy for solving problems, since systems designed by such techniques remember old solutions and apply them to new problems whenever circumstances permit. This paradigm also permits us to apply expertise in a domain where rules are hard to define. Problem solving using CBR techniques usually involves retrieving relevant previous solutions, adapting and combining previous solutions to solve the new problem, and recording failures so that they can be avoided in the future. The efficiency of such a system relies on the completeness and compactness of such a case library. These two characteristics of a case library in turn rely on an indexing scheme for the set of cases in the library. Department of Computer Science and Engineering, Universityof Connecticut,Storrs, CT 06269-3155, USA This paper was awarded the Best KBS Paper Prize at the Artificial Intelligence in Design '91 Conference Edinburgh, UK (25-27 June 1991) Vol 4 No 3 September 1 9 9 1
Many design problems are computationally expensive, thus providing a good domain to apply CBR techniques. This paper examines the domain of assembly sequence planning (ASP) 4-7 and analyses how CBR techniques can be applied to such a domain. Although it is often called planning, ASP problems are a type of constraint-oriented design problems in a sense that a goal is to be achieved while a set of constraints are to be satisfied. Illustrated in Figure 1, the ball-point pen is an example of ASP problems. The goal is to provide a sequence to assemble two parts at a time without backtracking so that the final configuration (a set of constraints) of the product is satisfied. One solution to this problem is to place the ink inside the tube, place the ink-tube inside the body, put on the head, put on the button, and finally put on the cap. A common mistake is to overlook the spatial relationship between the ink, tube, body, head, and button and to suggest putting the head and button on to the body before the tube and ink are placed inside the body. An initial examination of the nature of ASP problems made us realize that the goal-oriented planning paradigm (as in CHEF s, for example) found in the current CBR literature does not satisfactorily provide a model for solving design problems. CHEF takes a set of goals (e.g. 'give me a stir-fry with chicken and broccoli') as input and generates recipes that satisfy these goals. ASP requires a set of constraints to be given as input. While the goals in CHEF can be readily used to index the case library to facilitate the search for candidate cases, it is much less clear how the given constraints (being the only input to the ASP problems) can be used to guide the search. In a later section we discuss this observation in more detail. Only when we examine the constraints more closely do we realize that they give rise to many implicit goals. So somehow each problem must be decomposed into subproblems so that a CBR system can select from the case library the appropriate cases for each of the subproblems. This paper will examine four key issues related to the design of such a CBR system which solves constraint-oriented design problems: (a) how to succes-
0950-7051/91/030123-08 © 1991 Butterworth-Heinemann Ltd
123
Cap
Figure l.
Head
Body
Tube
Ink
The ball-point pen as an example of the A S P problems
sively decompose a given problem, (b) how to represent the cases in the case library, (c) how to control the search space, and (d) how to select the best case. These discussions are preceded by a section where we define what an ASP problem is. Our CBR system, CAB-Assembler, is fully implemented. Thus we describe the other components of the system after we have presented the theory. Several example devices which CAB-Assembler successfully solved are discussed in the performance section. Some run-time measures are also shown there to illustrate the performance of our system. Finally we conclude the paper by recapitulating the main points of this work and pointing out some important issues which are subject to further investigation.
Cap
a
Stick
Stick
PROBLEM DESCRIPTION The problem of finding a sequence with which the parts of a product can be assembled is called the assembly sequence planning problem. One of the valid sequences for the receptacle device shown in Figure 2a is as follows7: {(cap) (handle) (receptacle) (stick)} --, {(cap receptacle) (handle) (stick)} -~ {(cap receptacle stick) (handle)} -~ {(cap receptacle stick handle)} Each union of two pairs of parentheses defines an assembly operation. The input to an ASP system is always the set of objects or parts of a product in a totally disassembled state. Since the product has been successfully designed, there is a unique configuration with which the parts are arranged. This configuration, which is also part of the input, is called the relational model by Bourjault9 and defines a set of constraints on the set of parts. The relational model of the receptacle device is shown in Figure 2b. The labels on each arch of the relational model (or graph) are specifications of constraints among the parts. For example, it is specified that the cap is to be connected with the receptacle via a threaded-cylindrical contact (screwing on), the stick to be connected with the receptacle via a cylindrical contact (putting it inside), etc. But the relation model does not define the assembly order: it does not specify that the stick must be put inside the receptacle before both cap and handle are screwed into the receptacle. In a product, a part is the smallest non-decomposable entity. When two parts are joined, they form a subassembly. A part can also be joined with a subassembly to form another subassembly. We use the word piece to refer to either a part or a subassembly. An assembly plan, the output, is an ordered sequence of (assemble A B) actions where A and B are both pieces. Notice that one does not have to pay attention to how A and
Handle
Receptacle
]
Type: planar J normal: (0 1 0 ) / / / / ype: threadedylindrical
/
124
Button
VType: cylindrical axis: ((0 0 O)
J
'°! °'
Type." threadedcylindrical Receptacle I
Figure 2. model
@
[ Hald,e J
(a) The receptacle device (b) Its relational
B are put together, for instance whether they are joined by a planar, or threaded-cylindrical contact. These relations are called contact and attachment relations by Homem de Mello 6. This information is provided by the designer.
CBR SYSTEM FOR ASP To design an efficient CBR system, we have identified two important issues: a complete and compact case library and an effective indexing scheme. By a complete case library, we refer to the fact that after a small training period the CBR system should be able to solve most of the problems in the domain without having to add more cases to the library. By compactness, we mean a small and manageable case library. By an effective indexing scheme, we mean the ability to retrieve similar cases and the successfulness of applying these cases to new problems. The intuition of our solution to these issues is that we keep a library of cases that correspond to subsolutions so that a whole problem is solved by combining subsolutions, and we use constraints, which are input to the ASP process, as indices to organize cases. The reason why the library designed this way is small and complete is because in many engineering domains, problems are composed of a set of primitives, or so-called building blocks. For instance, in the electrical circuit domain, systems consist of AND, OR, and NAND gates at the gate level. Knowledge-Based Systems
enclosure. Figure 4 shows the stage just before the receptacle case is applied. In the next section, we will discuss our case representation. We illustrate how a case (called the fundamental case) which just assembles two pieces together and the receptacle are kept in the case library. To solve the box example, our system uses the fundamental case four times to put the walls together and the receptacle case once to place the ball inside the box.
In certain mechanical domains, building blocks are gears, ratchets, levers, and linkages. In the ASP domain, there is on the order of 10 basic ways of combining parts into subassemblies. In the next few sections of this paper, the solution to these issues is explained in detail. Several examples are used throughout these sections for illustrational purposes. We describe these examples first, as follows. The three devices shown in Figure 3 are different devices at first glance. Under closer examination, we realize that all three devices have a common enclosure characteristic: some parts in these devices eventually form a spatial enclosure; some parts of these devices must be placed inside the enclosure before it is completely formed. But how does one recognize that the enclosure characteristic is common in all three devices so that the solution for the receptacle can be applied to the ball-point pen and box, for example? For assembling the box, somehow the system has to first put the wall pieces together before it can use the receptacle solution to solve the enclosure characteristic. How can that be done?
Case library Almost no two devices have exactly the same compositions. Thus our case library captures a set of subsolutions (building blocks), such as the enclosure case and the fundamental case, rather than complete device assemblies. The case library accommodates all ASP problems we studied with a small set of cases. Each case corresponds to one step in assembling a subassembly. It has the following representation: • the abstract problem description (= APD, generalization) which is a set of features, where each feature defines a particular characteristic of a problem • feature weights • success and failure history • the plan
Successive reminding Suppose we know how to solve the receptacle device and want to use this experience to solve the box example. Initially it is hard to see the enclosure with the given seven pieces of the box. But if four walls were assembled together, we would begin to be reminded of the receptacle. Thus such an enclosure characteristic may only be apparent to us sometimes in a later stage of our planning process. The successive reminding idea is to make the system apply those solutions that remind it of the current stage of the assembly process. For this box example, the system is to be reminded of a case which just puts two pieces together in the beginning. Hopefully the system applies this solution until the wall pieces and the bottom of the box have been connected. Then the system is to be reminded of the receptacle case in order to solve the
Cap
Stick
Receptacle
Table 1 illustrates the case representation of the receptacle device (Figure 2a). In the beginning, all #succ and #fail fields are initialized to 1 and 0 respectively. Each piece involved in the case is a mandatory feature and has the highest weight, 6. Later on we discuss how other optional features can be included with lower weights. Although Table 1 presents the ASP solution of an entire device, it can be used to solve the ballpoint pen (Figure 1) partially. More precisely, it solves the enclosure problem in the ball-point pen. In fact, most cases represent solutions to subproblems. Shown in Table 2 is a solution used to partially assemble many devices. For our own convenience, we call such a case the pan-with-cover case, but it can be used to assemble
Handle
a
i, Cap Head
,
Body
Tube
b Figure 3.
Ink
Button
C
(a) Receptacle (b) Ball-point pen (c) Box
Vol 4 No 3 September 1991
125
® Figure 4. Table 1.
A partially assembled box The case representation of the receptacle device
Feature
Weight
Number of successes
Number of failures
Receptacle Cap Stick Handle
6 6 6 6
1 1 1 1
0 0 0 0
Solution:
Table 2. Feature Pan Cover Surf-surf Pan cover Solution:
{(receptacle handle) (stick)(cover)} {(receptacle handle stick)(cover)} {(receptacle handle stick cover)}
The case representation of a pan-cover device Weight
Number of successes
Number of failures
6 6 6
1 1 1
0 0 0
Selecting the best case { (pan cover) }
any two pieces if they are connected via the surfacesurface contact. To facilitate matching, a set of features (or feature vector) is associated with each case as an index and serves as the generalization of a problem. In other words, this set of features represents the characteristics of not only this particular case, but also a class of similar cases. We will elaborate on the indexing issue further in the next section. Each feature in the feature vector has the following additional information: feature weight and success and failure histories. The weight assignment gives preference to the more important features. Success and failure histories help the system select the best case in the future by recording experimental data. For each case, a plan or solution is attached so that once this case is chosen for a new problem, the solution is applied. Since the library is kept small, it is ordered sequentially instead of in a more sophisticated way, such as MOPs
3,1°.
Controlling the search The problem introduced by the successive reminding approach is a severe search problem which is illustrated with the following scenario. 126
The input to the system is a device in a totally disassembled state. The challenge is to identify in this totally disassembled device which characteristic problem in the case library to apply and when. This defines a large search space since there are usually a lot more parts involved in a disassembled device than those involved in a characteristic case. Doing the problem mathematically, the space is exponential. When the box example is initially matched with the receptacle case, there are 840 different ways of matching these two problems. The box initially has seven pieces and the receptacle case has four. Taking a permutation of four out of seven each time, there are 7 x 6 x 5 x 4 = 8 4 0 distinctive ways. This is computationally too expensive! With closer examination of the problem, we came up with a much more efficient way to do this task. Each case in the library and the ASP problem at hand are defined with a set of features. If we just include the number of pieces as mandatory elements in the feature field, the search space is exponential. However, once we include geometrical constraints as mandatory elements in the feature field, we came down to 187 possible combinations for this example. With the inclusion of spatial constraints, we came down further to 10 possible combinations. By including geometrical and spatial constraints in the feature field, we have avoided comparing incomparable cases. One observation is necessary here. The geometrical and spatial constraints are merely relationships between the parts of a device, which are presumed to be available in a data file. Thus these constraints do not require any overhead on the part of the users.
There are still 10 ways to fit the box into the receptacle case. If the case library contains more cases, the search space is still quite large. Determining the best case(s) is important to any CBR system. Many systems use heuristic metrics u-~s to determine the similarity between two cases. Often such a metric is domaindependent and requires a set of desiderata to be defined first. Our approach is quantitative and calculates a priority in terms of the usefulness of each feature using information from past experiences. For each feature, we calculate its priority as follows: 0 if m a n d a t o r y features do not m a t c h or
priority (F) =
#successes < #failures
~ r ~ s #successes
*
(#successes - - #fatlures) otherwise "
•
The priority of a case is the sum of the product of each feature priority and its weight. The formula for each feature is justified by the following considerations: 1 Match: if the feature of a case does not match with the feature of the problem at hand, the priority is neutral (=zero). 2 Success ratio: measure the number of successes over the total number of times this feature is selected. 3 Exaggeration: if a case is very successful, the chance of selecting it should be increased (encouragement); Knowledge-Based Systems
Repair r . . . . . . . ~"
Past experience I _ Update = case base ~ ....
Feature weights The features should not only be divided into important (mandatory) and unimportant (optional) but they should also be further subdivided into degrees of importance, also called weights. The overall range of the weights should depend on how exactly the differences among the features can be determined. This is very domain specific. For the ASP domain we use a range between 1 and 6. Plan In the ASP domain an action and also a group of actions can be represented by using 'assemble' and 'not assemble' as the only two operators. Some examples for the internal representation of plans are: (1) (assemble 1 2) (2) (not assemble 2 3) (3) (not assemble 1 3) where 1, 2, and 3 are piece variables. 'Not assemble' is important in avoiding failures. This operation is often included in a plan after a failure has occurred.
- -
Control and data flow
Figure 5. System architecturefor CAB-Assembler if a case has had many failures, the chance of selecting it should be decreased (punishment). 4 Weight: a feature which is supposed to be more important (higher weight) should have a higher chance of influencing the case priority than one that is of less importance. This is called 'salient-feature preference '13. The case base is initialized to 1 for all #successes fields and 0 for all #failure fields. By considering the successand failure-history of a feature and therefore of a case, the reasoner selects not only the most similar, but also the most useful case for a problem 13. HYPO 11.12 uses previous experience in the form of weights (called 'factors' or 'dimensions') in order to assess similarity. However that method is combined with information about the reasoner's task. Also the reasoner uses the weights only partially (notion of 'least commitment approach'). That method is therefore not suitable for the ASP domain.
OVERVIEW OF CAB-ASSEMBLER CAB-Assembler is an implementation of the ideas presented here and has various other components besides issues discussed earlier. A flow chart of how the system works is shown in Figure 5. We briefly describe the other components of the system as follows:
Input The input to the search and case selection mechanism of the case-based system are • the current state of a device (totally or partially disassembled), described in terms of predicate relations, • the case base. Vol 4 No 3 September 1991
Success and failure history The number of successes tells how often this case has contributed to successfully reaching a goal state when this specific feature matched with the new problem. However, if the goal state is not reached and this case with its 'bad' plan is declared as the reason for failure, all features that matched are increased by one for the #failure field. Combining plans The matching algorithm returns the results of the case examinations. These results are sorted in a descending order according to case priorities. The best plan is combined with the plan of the second closest case, the plan of the third closest case, and so on - until a specific action is found. Failure detection and error locating Failure-driven learning depends on the detection of the failure and on finding the reason for this failure. It is admitted as a very difficult task 1.3,8. Using a heuristic approach is a common way of locating the error. The implemented system solves this problem by simply asking the user whether the proposed action is acceptable. Similar to failure detection, locating the reason for failure is only important in the training stage. Therefore it is also solved through user interaction. Once the reason for failure is located, we know which action has caused the failure. Two methods are used in order to avoid repeating the same failure again: memorizing the failure and creating a new case for solving this problem. Whenever failure appears, both methods are applied. Learning by success When people solve a problem successfully, they tend to be encouraged by such an experience. Sometime later if the same or a similar problem appears they tend to use a plan that was more successful rather than one that has not been. In order to prefer the selection of a case, and with the case automatically its plan which was very successful in the past, success is memorized in a case. We 127
discussed this issue already in the paragraph on successand failure-history.
CAB-ASSEMBLER'S P E R F O R M A N C E Spatial reasoning has been particularly difficult in the ASP domain6. However many spatial problems, although different on the surface, share many similar characteristics. Thus our observation is that if spatial problems are difficult, not every one of them has to be solved from scratch. We go through two spatial examples in this section, step by step, to show how our system works, and discuss the performance in terms of time costs. The first example, the receptacle device, is meant to show how a case base is initially established. It encounters failures and is corrected by users via an interactive mode. Once a case base is established, we show that it offers flexibility in terms of solving similar problems. Furthermore, our research results show that it is best to train a case base with a more complicated example in order to accumulate more experiences. The case development for the bail-point pen is quite long, and thus is omitted here. See Reference 14 for detailed transcriptions. But we will show how the case base trained by the ball-point pen can be used to solve the receptacle case without failure (example 2). The receptacle example represents a typical enclosure problem: the stick cannot be put into its place after the other three parts already form a subassembly. The scenario:
Step 1: input: {cap handle receptacle stick), 'cb. fund'. The device is completely disassembled. The reasoner decides to assemble the parts cap and receptacle. Step 2: input: {(cap receptacle) handle stick), 'cb.fund'. The reasoner decides to connect the subassembly '(cap receptacle)' with the part 'handle'. Step 3" input: {(handle cap receptacle) stick), 'cb. fund'. The action 'connect stick (handle cap receptacle)' cannot be performed. Failure OccurS.
The action which connected the part 'handle' with the subassembly '(cap receptacle)' is blamed for the failure. The reasoner creates a new case which contains three pieces referred to as 'handle', '(cap receptacle)', and 'stick', respectively. The plan of the new case should in the future prevent the reasoner from connecting the pieces 'handle' and '(cap receptacle)' again. This prevention should not only work for the same problem, but also for any other situations similar to this one. The second part of the following transcript shows that the improved case base avoids making the same mistake, and solves this example successfully: *** start of transcript * **
i am in training-mode Do you accept to connect piece (CAP) with piece (RECEPTACLE)? (y/n) ~ y 128
Do you accept to connect piece (HANDLE) with piece (CAP RECEPTACLE) ? (y/n) ~ y Do you accept to connect piece (STICK) with piece (HANDLE CAP RECEPTACLE) ? (y/n) ~ n Was connecting (CAP) with (RECEPTACLE) the error? (y/n) ~ n Was connecting (HANDLE) with (CAP RECEPTACLE) the error? (y/n) ~ y remembering SUCCESS for case FUNDAMENTALCASE bad case: FUNDAMENTAL-CASE Should (STICK) be added to the new case? (y/n) ~ y Should (HANDLE) be kept in the case? (y/n) ~ y Should (CAP RECEPTACLE) be kept in the case? (y/n) ~ y How would you like to name the new case? name ~ rec-1 remembering FAILURE for case FUNDAMENTALCASE Name for new case base---, cb.rec.1 storing improved case base in file CB.REC. 1 end of problem solving NIL
Table 3.
Run-time behaviour - receptacle example
Pieces left to assemble
cb.fund
cb.rec.l
cb.pen.4
8 5 3f
19 10 4 --~2
54 17 10 =2
--
35
83
4 3 2 1
Table 4.
Column four (cb.pen.4) shows that the case library created for solving the ball-point pen (Figure 3b) can be used to solve the receptacle device. The significance here is that our system can be trained to solve a class of problems. In this case, both the receptacle device and the ball-point pen are part of the class of enclosure problems. Furthermore, if the system is trained to solve a more difficult problem in the same class, it can solve a simpler one without much failure. Several observations from the experiment are summarized here:
Run-time behaviour - ball-point pen example
Pieces left to assemble cb.fund cb.pen.1 cb.pen.2 cb.pen.3 cb.pen.4 cb.afi.5 6 5 4 3 2 1
17 12 9 6 4f
Y
.
24 18 13 8f
.
40 28 18 9 4f
.
56 37 22 9 5f
.
108 47 27 13 5 ~2
91 48 25 13 5 ~2
202
184
In the following transcript, prob.rec.vert.sl is the receptacle problem given to the system. The case base is cb.pen.4 which is obtained by training the system with the ball-point pen example. *** start of transcript ***
• The more pieces an assembly has, the longer it takes to calculate the next action. • The more cases a case base has, the longer is the run-time. • The number of pieces affects the run-time more than the number of cases does. Other problems our system solved included interlocking blocks and an assembly from industry which has 11 parts. Both of these have been studied by researchers in the ASP field. The run-time cost of the AFI problem is 3317 seconds (or 55 minutes), a rather low figure which we have not seen in other ASP systems.
RELATED WORKS
Traditional assembly sequence planning methods
i am in training-mode Do you accept to connect piece (RECEPTACLE) with piece (HANDLE) ? (y/n) --~ y
The ideas on ASP problems described by References 4, 6, 7 and 9 have influenced our work in terms of representing the problem and understanding the nature of the problem. However, these methods are highly computationaUy intensive. Knowledge-based systems normally use heuristics to maximize the efficiency. De Fazio and Whitney 5 proposed a rule-based expert system to solve ASP problems. Some ASP problems, such as the interlocking blocks, pose constraints that are non-linear and cannot be solved by rules. Our system takes advantage of the observation that 'if ASP problems are generally computationaUy hard, not every one of them has to be solved from scratch.' Thus the first-principled method by Homem de Mello 6, for instance, can be viewed as the resort we come to when our system fails to retrieve a similar problem. However, most of the time the system can solve ASP problems by using past experiences efficiently, as we have shown in the performance tables.
Do you accept to connect piece (CAP) with piece (STICK) ? (y/n) ~ y Do you accept to connect piece (RECEPTACLE H A N D L E ) with piece (CAP STICK) ? (y/n) ~ y remembering SUCCESS for case PEN-4 remembering SUCCESS for case PEN-4 Name for new case base ~ cb.xy storing improved case base in file CB.XY end of problem solving NIL
Case-based systems The major finding of this work is that current techniques, such as CHEF 2, in CBR address goal-oriented planning, rather than constraint-oriented planning which is more common in the engineering domain. Each case in the case library captures the solution of an entire problem, instead of the characteristic subproblems which comprise the whole. Thus it does not provide a model for ASP problems or other constraintoriented planning problems. Those CBR systems that did address engineering problem-solving issues 15n6tend to follow the goal-oriented paradigm also. 129
CONCLUSIONS AND FUTURE WORK The success of our approach relies on two factors: it solves new problems by retrieving subsolutions instead of complete solutions and it keeps a small case library of the primitives of the problem domain. To achieve the first, we must perform what is called successive reminding. Furthermore, an effective indexing scheme must be used so that at each stage of the assembly process, the system retrieves the right subsolution. To achieve the second, we observe that in the ASP and many other engineering domains, the underlying set of primitives which serve as building blocks for the whole class of problems is a small set. In the ASP case, there are on the order of ten primitive problems. Designing a CBR system with this principle in mind avoids a large case library, and thus achieves efficiency. We have studied heavily the enclosure problem in this research, since it is the most time-consuming one if first-principled approaches are used 6, which involve the use of path-planning algorithms. Our future work will include the further study of other characteristic problems. In Homem de Mello's work, there is a classification of what he called preference relations, of which enclosure is one (called the ordering preference). From our experience with the enclosure problem, it is a matter of training a case base with the capability of solving certain preference relations. The formula for calculating the best case or cases is subject to further study. For all the cases we tried with our current implementation, there are no undesirable behaviours found in the system. But this is not a satisfactory answer on theoretical bases. We are currently looking at mathematical treatments of distance functions in treating similarities (in our case, relevancy). One possible solution is to make the formula calculating how irrelevant a case is to a problem. Thus the best case is the one that is least irrelevant to the problem. If such a least distance formula can be shown to satisfy the triangular inequality 17, then it is guaranteed that the system will converge. That is, the more experiments we perform with the system, the better it is in terms of dealing with the selection of best cases. REFERENCES 1 Kolodner, J L (Ed.) Proceedings of 1st Case-Based Reasoning Workshop Morgan Kaufmann (1988) 2 Hammond, K J (Ed.) Proceedings of 2nd CaseBased Reasoning Workshop Morgan Kaufmann (1989)
130
3 Riesbeck, R and Schank, R Inside Case-based Reasoning Lawrence Erlbaum (1989) 4 Sanderson, A C and Homem de Mello, L S Task
Planning and Control Synthesis for Flexible Assembly Systems Springer-Verlag (1987) pp 331-353 5 De Fazio, T L and Whitney, D E 'Simplified generation of all mechanical assembly sequences' IEEE Journal of Robotics and Automation (December 1987) pp 705-708 6 Homem de Mello, L Task Sequence Planning for Robotic Assembly PhD Thesis, Carnegie Mellon University, Pittsburgh, USA (1989) 7 Sanderson, A C, Homem de Mello, L Z and Zhang, H 'Assembly sequence planning' AI Magazine Vol 11 No 1 (1990) pp 62-81 8 Hammond, K J Case-based Planning: ViewingPlanning as a Memory Task Academic Press, San Diego (1989) 9 Bourjault, A Contribution a une Approche Metho-
dologique de L'Assemblage Automatisd: Elaboration Automatique des S~quences Op~ratoires. Technical Report (Th~se d'l~tat), Universit6 de Franche-Comt6, Besan~on, France (1984) 10 Schank, R Dynamic Memory: A Theory of Learning in Computers and People Cambridge University Press (1982) 11 Ashley, K D and Rissland, E L 'Compare and contrast, a test of expertise' in Kolodner, J L (ed)
Proceedings of 1st Case-BasedReasoning Workshop 12
13 14
15
16
Morgan Kaufmann (1988) pp 31-36 Ashley, K D and Rissland, E L 'Weighting on weighting: a symbolic least commitment approach' in Proceedings of 7th National Conf. on Artificial Intelligence (1988) pp 239-244 Kolodner, J L 'Judging which is the "best" case for a case-based reasoner' Proceedings of 2nd CaseBased Reasoning Workshop (1989) pp 77-81 Reschberger, M Case-Based Reasoning for Assembly Sequence Planning Technical Report CSE-TR90-25, Department of Computer Science and Engineering, University of Connecticut, USA (1990) Barletta, R and Mark, W 1988 'Explanation-based indexing of cases' in Kolodner J L (ed), Proceedings of 1st Case-Based Reasoning Workshop Morgan Kaufmann (1988) Navinchandra, D 'Case-based reasoning in cyclops, a design problem solver' in Kolodner J L (ed)
Proceedings of 1st Case-Based Reasoning Workshop Morgan Kaufmann (1988) 17 Conte, S D and de Boor, C Elementary Numerical Analysis: An Algorithmic Approach McGraw-Hill Book Company, 3rd edition (1980)
Knowledge-Based Systems