Artificial Intelligence in Engineering 11 (1997) 245-258

--

ELSEVIER

PII:

SO954-1810(96)00044-l

0 1997 Elsevier Science Limited. All tights reserved Printed in Great Britain 0954-1810/97/$17.00

Reconstructive memory in case-based design

B. Kumar & B. Raphael*
Department of Civil Engineering, University of Strathclyde, Glasgow, UK

(Received for publication

8 November 1996)

This paper describes an approach to applications of case-based reasoning in design based on utilising design methods used for solving similar problems in the past. In order to facilitate the implementation of this approach, data structures called MREM (Memory REconstruction Methods) are developed. This is based on Kolodners theory of reconstructive memory. An MREM based model of design is implemented in a prototype called CADREM (CAse based Design using REconstruction Methods). CADREMs casebase contains cases of conceptual structural design of buildings. 0 1997 Elsevier Science Limited.
Key words: case based reasoning, design, artificial intelligence, memory, structural design.

reconstructive

1 INTRODUCTION 1.1 Background Experiential knowledge plays a significant role in the human reasoning process. Previous experiences help in understanding new situations and in finding solutions to new problems. This use of experiential knowledge was lacking in many of the earlier computer models of problem solving before the advent of knowledge-based models. Making use of past experiences or cases for solving new problems is a relatively recent idea in artificial intelligence (AI) and is commonly known as Case Based Reasoning (CBR). The application of CBR to design, known as case based design (CBD) is still in its infancy. Several CBD systems have been developed that demonstrate its use in various domains. The domain chosen to test the ideas presented in this paper is the conceptual structural design of buildings. The conceptual structural design of buildings offers interesting possibilities in applying CBR techniques because of the lack of formal representations of design knowledge. Some of the earlier attempts at automating this include HI-RISE, ALL-RISE2 and ALTSEL.3 These systems are knowledge-based systems and do not possess any case-based reasoning capabilities. These systems have not entirely been successful because of the difficulties in representing domain knowledge formally. While formally documented knowledge may not be available for the selection of *Current address: Bangalore, India. Infosys, Research & Education Dept.,
245

components of a structural system, cases of structural design of buildings may be relatively easier to obtain. However, the difficulty lies in generating new designs from these cases. The effectiveness of a generic approach to CBD can be tested by applying it to this problem. This paper describes an approach based on re-using design methods from past designs in solving new problems. In order to facilitate the implementation of this approach, data structures called MREM (Memory REconstruction Methods) are developed. Development of MREMs and their use in a case-based design is the main focus of this paper. A detailed description of the indexing and retrieval used in this approach can be found in Ref. 4. This paper presents a more detailed description of development of MREMs and also briefly describes the retrieval mechanism as well as the prototype, called CADREM, developed to illustrate the ideas developed in this work. A detailed description of CADREM can be found in Ref. 5.

2 CASE-BASED

REASONING

CBR6 relies on storing solutions as well as problems and adapting these solutions to solve new similar problems. CBR has a relatively recent history and any commercial systems are yet to emerge. There are, however, a number of experimental systems available which have come out of research. Examples of case-based design are scattered all over in architecture.7 CBRs application in structural design is not that common. However, it is quite a common practice to employ approaches used in solving past problems to solve new problems. It is also quite

246

B. Kumar, B. Raphael

common to pick an old solution to a similar problem and adapt it for the current problem. Our strategy is based on the former approach. It must be emphasised that the question of adaptation of past designs for a new problem is non-trivial. However, the first realistic step in this area is to develop a system which simply assists a designer by replaying the similar past designs. The similarity of designs clearly first involves ensuring that there are similarities in the problem itself. Based on similarity in problem specification, a number of similar past designs can be retrieved from a case-base (analogous to a database) and the designer can choose to pick either a design from the set and adapt according to his wishes/requirements or pick different parts of different designs and synthesise them to form the final design. Case-based reasoning, by virtue of its very nature, lends itself as an extremely credible approach for domains which are not properly understood and are thus ill-structured and not well formalised. In the past, knowledge-based expert systems (or more commonly, expert systems) have been suggested as solving problems in ill-structured domains. But, the limited powers of rules in terms of how much and what type of information they can encompass seem to suggest their applications in design are almost infructuous. KBESs have been relatively successful in more prescriptive domains such as diagnosis. But their application in design appears limited. Knowledge acquisition from experts is an important bottleneck in the development of expert systems. CBR does seem to hold credible promises to overcome these limitations. 2.1 Issues in case-based design The main issues in case-based design are: 1. representation of design cases - contents of a case, indexing and retrieval mechanisms; and 2. adaptation of design cases for the current problem. 2.1.1 Representation of design cases Earlier research efforts in case-based design systems have used various factors in representing design cases. Representation of design cases can range between two extremes, i.e. generic class representation to specific case representation. Classes of design can be abstracted from specific cases where it is relatively easier to identify patterns or trends in designs or where products are manufactured on a mass-scale, e.g. mechanical products. However, in some domains it is more difficult to abstract classes of designs because of each product being unique. Building design is one such domain where each building is different and must be represented by a unique set of information. 2.1.2 Adaptation of past design cases The most important issue in automatic adaptation of a past design case is the identification of additional design

knowledge needed to accomplish it. As has been pointed out earlier, adaptation of past designs is a non-trivial task. In Hua et al.,8 the authors point out the problems associated with adaptation of past designs. It is clear that adaptation of design cases is a quite a complex and separate problem in its own right. In some cases, the adaptation might be only a parametric adaptation which is a more tractable problem. Our work involves generating rather than adapting designs with design methods used in solving similar problems in the past. The definition of design methods is given in section 3 and its application in structural design is illustrated in section 8.

3 MEMORY RECONSTRUCTION METHODS FOR CASE BASED DESIGN 3.1 Introduction In some domains, causal relationships may not be easily defined precisely so that design could be carried out from first principles. In such domains, operationai knowledge is more relevant than deep domain knowledge. (Operational knowledge makes explicit how a task is carried out or how a piece of knowledge is used). Incremental knowledge acquisition holds the key to satisfactory performance of a computer in these domains. The concept of Memory REconstruction Method (MREM) is developed as a means of incremental acquisition of design knowledge. MREM is a domain independent concept and it is based on Kolodners work on reconstructive memory. 3.1.1 Design methods The procedural aspect of the individual design cases is the main emphasis of this work. The motivation behind this is the observation that although structural engineering design, in general, does not follow a fixed procedure, individual designs do. This might involve qualitative and quantitative analysis, interpretations, heuristics and design decisions. An operational definition of a design method is as follows: The sequence of steps followed to arrive at a design is stored in a design method. 3.2 The concept of MREM 3.2.1 What is an MREM? Memory REconstruction Method (MREM) represents a procedure that can reconstruct the memory of a past event. In the context of design, MREM is defined as follows: An MREM represents a process that could be used to generate a past design solution or a part of it. 3.2.2 Background Kolodner presents a comprehensive theory of reconstructive memory, which considers memory organisation

Reconstructive memory in case-based design

247

(storage), retrieval, and integration of new items into memory (encoding) as problems that cannot be separated from each other, and explains all three in terms of each other. The central concept behind the theory of reconstructive memory is the principle that human remembering is often a process of reconstructing what must have happened rather than directly retrieving what did happen. Kolodners work is related to organising memory consisting of stories about past events and retrieving them in the right context. The MREM model developed in this work is an application of these principles to the domain of engineering design. 3.2.3 Use of MREMs MREMs represent procedural knowledge from particular cases. In artificial intelligence, the use of design plans to represent procedural knowledge is common.2.13 The conventional planning problem consists of arriving at the right sequence of predefined rules (or operators) to achieve a goal. The use of cases for such problems involves making use of past plans (sequences of rules). However, this requires prior knowledge in the form of rules (or operators). The approach using MREMs is very different. MREMs are meant to acquire rules as well as plans from cases which could be made use of in subsequent problems. In the MREM based model, the emphasis is on the procedural aspect of individual cases. Even though, design in general does not follow a fixed procedure, it is possible to find well defined procedures which might have been used to generate specific designs. The idea is to compile these procedures, generalise them and use them to create general design procedures. 3.3 Object oriented representation of MREMs The essential features of the object oriented representation of MREMs can be categorised under three headings, namely: 1. packaging hierarchy; 2. inheritance hierarchy; and 3. complementary views. These are explained in the subsequent sections. 3.3.1 Packaging hierarchy It is common to consider entities or objects as consisting of component parts that exist more or less independently of each other. In the schema-like representation, the components are represented as attributes of objects. Each component could also be an object having its own attributes and so on. This structure of object within objects results in a hierarchy known as the packaging hierarchy. In the representation of processes using MREMs the components represent parts of the process that could be identified as specific actions which exist more or less independently of each other. It may not be possible to decompose a solution into well defined parts, However, it is relatively easy to decompose specific

design methods since individual designs could consist of well defined steps. (Steps are not well defined for general design procedures, in contrast to specific ones.) The decomposition of a process into clearly identifiable parts enables the reuse of parts of a process even when the whole process may not be reusable. This is similar to reusing functions in a procedural programming language when the program is sufficiently modular. 3.3.2 Inheritance hierarchy Inheritance is a mechanism for bringing out abstraction relationships between objects. An inheritance represents an is-a type of relationship. In the traditional form of inheritance, a derived class inherits the variables and properties of the base class. Less abstract forms of a class are created using inheritance. 3.3.3 Complementary views In the previous section, the use of inheritance to bring out abstract relationships between objects was mentioned. However there are limitations to this approach. The main limitation of this mechanism is the fact that it is not always possible to clearly define the abstractions in the form of a hierarchy. A scheme is presented in this section, which is called complementary view model (CVM). This scheme is domain independent and could be used in the representation of objects in general, even though the main motivation is the representation of MREMs. A complementary view (CV) is a data structure for representing the correspondence between parts of an object (or class) and the parts of another object (or class). Using these correspondences, a CV states that an object (source) can be viewed as another predefined object (target) so that the knowledge from the target can be applied in the case of the source. A number of complementary views are possible to be defined for an object in terms of other objects. This is analogous to viewing an entity from different angles, each angle bringing out different features of the entity. In a particular view, the attributes of the source are related to the attributes of the target. The relationship could be a simple correspondence or it could be a complex mathematical or logical expression.14 3.3.4 Relation of CVM to existing techniques in OOP Complementary view scheme is similar to multiple inheritance (is-a type of relationships). Each CV represents one inheritance relationship, with the source object corresponding to the derived class, and the target object to the base class. But instead of inheriting the variables of the base class, certain properties of the base class are inherited. That is, the derived class does not have all the attributes of the base class, but certain aspects of the behaviour of the base class can be exported to the derived class since the relationships between the corresponding attributes are known. Consider the following example:

248

B. Kumar, B. Raphael 4 KNOWLEDGE ACQUISITION USING MREMS

The class rectangle has two attributes, namely, width and depth. The class square has just one attribute, side, representing the length of each side. Conventionally, if the class square is derived from class rectangle, square inherits the attributes width and depth. However a CV states that square can be viewed as a rectangle with the values of width and depth equal to the side of the square. The above view makes it possible to reuse the methods to calculate the geometric characteristics like the area of a rectangle, in the case of a square by suitable substitution of variables. Effectively, the properties (behaviour) of rectangle have been inherited by square. 3.3.5 Application of CVs to MREMs CVs supplement the knowledge about abstract relationships between MREMs. When a class of MREMs is identified as a specialisation of another class, but does not require the inheritance of the variables of the abstract class, CVs are used instead of inheritance. The definition of a CV brings forth the corresponding components of the two classes. Example. Consider following subtasks: an MREM, Ml, having the

The process of incremental knowledge acquisition using MREMs is described in this section. Learning takes place in three ways using MREMs. 1. addition of new MREMs; 2. learning of new relationships; and 3. generalisations. These are explained in the following subsections. 4.1 Addition of new MREMs The addition of new MREMs is accompanied by the process of integrating this into existing knowledge. There are two processes involved: 1. understanding; 2. classification. and

4.1.1 Understanding MREh4s The process of understanding an MREM involves drawing out inferences about it which help in classification. This could be done using any of the following techniques. Checking the features of the MREM to find out whether it belongs to any of the predefined types whose features are known. A simple example for this would be examining whether a MREM instantiates the variable depth-of-slab to find out whether it belongs to the specialised class, depth-ofslab-calculating-mrem. Checking the features of the MREM to find out what views can be generated about it using the prior knowledge of CVs. This would help in finding the position of the MREM in the abstraction network. Checking the actions taken by the MREM to find out what objectives could be satisfied using predefined knowledge of the objectives. This would enable classifying the MREM based on the objectives (or goals). Checking the dependency of the variables to find out under what conditions the MREM can be applied. This would enable classifying the MREM based on the preconditions. 4.1.2 Classijka tion There are three situations that would be encountered: 1. there are already existing MREMs for the same task; 2. the MREM is a specialisation of an existing one; and 3. the MREM is a generalisation of an existing one. When there are already existing MREMs for the same task it is inserted into the existing group. This means that there is nothing to distinguish between the MREMs

M 1.1 design vertical support system; Ml.2 design slab system; and M 1.3 design stability system. Consider another subtasks: MREM, M2, having the following

M2.1 check the shape of the building; M2.2 separate the shape into simple rectangular blocks; M2.3 position columns in the rectangular blocks; M2.4 design beam and slab system; M2.5 instantiate the variable stability-system. It can be seen from the above definitions that Ml and M2 cannot be related using the conventional form of inheritance. However, both MREMs perform similar operations which is not clear from the above definition. In order to bring out this fact, a CV is defined as follows (translated into natural language): M2 can be viewed as Ml with the following relationships: Subtask Ml. 1 corresponds to the combination of M2.1, M2.2 and M2.3. Subtask Ml.2 corresponds to M2.4. Subtask Ml.3 corresponds to M2.5. Even though the two MREMs have different set of subtasks, the above CV brings out the relationships between them. This view enables the computer system to modify an MREM by analogous substitution of components from another MREM. (Here the term component of an MREM refers to its subtask.)

Reconstructive memory in case-based design

249

of this group. The learning module has to look for additional knowledge for sub-specialisation within this group in order to bring out what MREM is applicable under a given situation. In the other two situations the MREM is inserted at the right position in the abstraction network. Some of the basic MREM types are listed in the appendix. 4.2 Learning new relationships The learning of new relationships could take place by the acquisition of three types of knowledge: 1. new CVs; 2. new ways to inherit an MREM; 3. new characteristics of an MREM. If the knowledge acquisition is to be made easy the formalism for adding the above three types of knowledge should be kept simple. The addition of the above knowledge could result in new positions for an MREM in the abstraction network. This would enable transporting extra knowledge into the MREM from its abstractions. 4.3 Generalisations There could be several processes that can generate the same solution. All these processes could be considered as equally good from the point of view of generating the original solution, but from the point of view of generality, these processes could be different. The simplest and the most efficient MREM could be one that can generate the solution to only the original problem, that is, one that is most specific. But since one of the objectives of storing MREM is reusability, this may not be the ideal one to be stored. It is not possible for the computer system to automatically identify the generality and the reusability of an MREM. This information can only be obtained by feedback from the user. The process takes place as follows: In the absence of any other information, the system assumes that the MREMs are reusable and generates designs using them. This is presented to the user (possibly in the training sessions) who comments on the reusability of the MREMs. The following information may be obtained from the user 1. whether the MREM can be reused in a given situation; 2. the conditions under which it can be reused; and 3. the modifications required for reuse. The issue of reusability is examined with respect to the following factors: (a) the goal; (b) the conditions under which the MREM can be applied; (c) the variables on which it operates (and their characteristics); and (d) the operations that are carried out.

All of these factors may not be completely known in a definition of MREM. The more these factors are known the more reusable it becomes. The MREM-architecture enables adding additional information into existing MREMs, whenever they become available. 4.3.1 The goal The goal could be described in different ways. Some of these include, (a) The name of the task which is accomplished by the MREM. Example: design-floor-slab. A description of the task in terms of the (b) operations to be carried out. Example: instantiate the variable, depth-of-slab. The characteristics of the context describing the (c) desired state. (The conditions that need to be satisfied by the variables in the context). Example: depth-of-slab less-than 100 mm. There could be several goals for an MREM. If an MREM has a well defined structure, it is possible to relate what component of an MREM contributes to achieving a certain goal. 4.3.2 The preconditions It is almost impossible to list out all the different conditions under which a particular series of actions could be taken. It is equally difficult to describe precisely a particular condition under which the action could be taken. (This is one of the reasons why rule based systems have not been very successful.) 4.3.3 Variables The actual variables are always known as it is part of the definition of the MREM. However what needs to be known is the general form of the variables in order to be reused. There are several possibilities: 1. The same process can be carried out on a number of variables (need not be the specific variable as in the MREM). For reuse, this list of variables need to be known. 2. The same process can be carried out on any variable that belongs to the same class. The name of the class in the abstraction hierarchy need to be known for reuse. 3. The same process can be carried out on any variable satisfying a set of conditions. The conditions or the characteristics of the variables that enable the process to be reused need to be known. 4. For a different set of initial conditions, the variables involved could be different. This information is required if the process has to be reused for different initial conditions.
Analogical replay of MREMs using generalisation of variables. When the general form of variables is known

the

MREMs

could

be played

using

analogical

250

B. Kumar, B. Raphael

substitution of components. That is, instead of using the original variables the MREM is applied by using its equivalent variables in a given problem. This analogous substitution of variables could produce surprisingly different solutions. 4.3.4 Operations (transformations) The operators that are used are known from the definition of the MREM. But for generalisation, the alternate operators that can be used under similar conditions need to be known. 4.3.5 Improving the reusability The following are the information reusability of an MREM:

that improve the

form a hierarchy depending on the importance of the criteria they represent. The hierarchy results from an RM controlling other RMs to handle more important criteria. The criteria represented by an RM could be combinations of less important criteria represented by the RMs below it. The term meta-RM will be used to denote RMs that control other RMs. (The meta-RMs either activate other RMs or deactivate them.) The use of an important criterion results in a more precise match in the retrieval whereas a less important criterion results in an imprecise match. In the event of a successful retrieval based on an important criterion, the RMs below it could be deactivated. Thus, the hierarchy of RMs would result in retrieval based on varying degrees of matches. 5.1 Representation of REs and RMs
5.1.1 Retrieval example

(a) The justifications (the reasons for taking certain decisions). The reasons for taking certain decisions in a particular problem need not mean that the same decisions can be taken under the same conditions for a different problem. It also does not mean that the same decisions can be taken only under the same conditions. However, the justification gives valuable clue regarding the reusability of a certain chain of actions. (b) Dependency relationship between design decisions (what decisions necessarily follow from a certain decision). This information may enable the reuse of certain parts of a process even when the whole process cannot be reused as such. Whenever this information is available it should be incorporated in the MREM in order to avoid the more difficult process of acquiring it through feed back from the user.

A retrieval example is also an MREM. It represents a process that was used in a specific situation in order to retrieve a case. Hence it can also be represented by the method object. However the attributes of a retrieval example needs some explanation. The usual attributes of a method-object used to represent a retrieval example are the following. 1. objective, 2. preconditions, 3. actions. Objective is a statement of the task for which the case is retrieved. Preconditions represent a set of conditions in the context. The action part defines the sequence of steps to be carried out when the preconditions are satisfied. The syntax of the action part permits probing into the case base and requesting cases having a given set of features. It could also contain the definition of a metric to specify how distant or different the case is from satisfying the given objective. 5.1.2 Retrieval method The only difference between a retrieval example and a RM is in the degree of generality. RMs are general procedures that can be applied in a variety of situations, whereas a retrieval example represents a process adopted in a specific situation. The data structure used to represent an RM is the same as that of a retrieval example. Superficially a RM looks like a rule, but a RM is different from a rule in the way it is used and its functionalities. A RM contains much more information than a rule which can only be applied in a given problem solving situation. It is used for tasks like automatically indexing cases, organising case memory, and interpreting a given situation. The mode of application of RMs in design is also different from that of rules. Since

5 INDEXING AND RETRIEVAL IN AN MREM-BASED SYSTEM In this section, a scheme for indexing and retrieval is presented, which is based on the basic philosophy of MREMs. This is called REtrieval Based on Examples (RBEX). The basic idea behind this is that retrieval of relevant cases requires a certain amount of domain dependent (sometimes case-dependent) control knowledge. The success of a retrieval system depends on how effectively this basic control knowledge is applied. Under the RBEX scheme, the processing knowledge used in individual retrieval examples (REs) are reused for future retrievals. Special data structures are used to represent the processing knowledge related to retrieval examples. Using retrieval examples, generalised methods called retrieval methods (RM) are created which handle different conditions for the retrieval of cases. Each RM represents a condition under which a case or a set of cases could be retrieved. It contains the basic knowledge to interpret a situation and determine the relevance of cases under the criteria that they represent. The RMs

Reconstructive memory in case-based design

251

it is impossible to cover all possible situations in the form of preconditions a lot of filling in of the gaps has to be done by the retrieval system using the minimum amount of information that is available within the definition of RMs. 5.2 Examples of REs and RMs An example is given in this section to illustrate the idea of REs and RMs. Consider an RE having the following definition:
Objective: Design of a floor slab. Preconditions: Span = 10m. Actions: Select a floor slab case involving a prestressed

Heuristic 1: Ignore all the problem specific constants in the preconditions and replace them with variables. Heuristic 2: The values of variables in the preconditions could be replaced by their abstractions. Heuristic 3: An abstract version of an RE or an RM can be created by replacing a subtask with an abstraction of the subtask.

6 A DESIGN PROCESS MODEL USING MREMS Figure 1 is a schematic representation of a design process model using MREMs. The steps involved in the process are described below. Step Step Step Step 1: 2: 3: 4: Problem specifications. Setting the top level task. Retrieval for the current task. Application of the MREM.

concrete waffle slab. The metric used is the absolute value of the difference between the specified span and the span defined in the case. Consider two other similar REs differing only in the precondition. The spans specified for these two are 11 m and 12 m respectively. The RM created using these examples contains the following precondition, 10 * span * 12. (In order to attain this particular precondition certain heuristics have to be used in the process of generalisation from examples.) The objective and the actions of this RM are the same as in the definition of the REs. A more elaborate description of RBEX can be found in Raphael and Kumar.4 5.3 Heuristics for creating RMs from REs The following are some of the heuristics used in creating RMs from REs.

The selected MREM is applied. The MREM could be a low level MREM or it could just set the subtasks. In the case of a low level MREM the actions defined in it are executed. In the case of a failure of MREM, the next highest ranking MREM for the current task is selected and executed. If all the MREMs fail the current task fails and it backtracks to the previous top level task after recording the failure, the process continues from Step 3. (At this stage, the next highest ranking MREM for this task is selected, as RBEX recognises the failure of the previous MREM.) In the event of the successful application of the MREM, partial solutions to the problem are obtained. These are instantiated in the context. Step 5: Setting the next task.

.
RBEX

Problem spec. Top level task

Fig. 1. Schematic representation of the design process model using MREMs.

252
7 CBR APPLICATIONS DESIGN IN STRUCTURAL

B. Kumar, B. Raphael 8.1.1 A description of the structural design process

The relevance of CBR to structural design or indeed any design is not hard to imagine. It is common practice to first try and find solutions to similar problems from the companys archives before developing a solution afresh. It is thus natural to develop design support systems using the CBR approach. The following section describes a prototype MREMbased design system. This prototype, CADREM, stores the methods that the designer might have used for generating designs (layout designs in this case) and tries to apply these methods for solving similar problems in future. CADSYN is a prototype case-based design system for structural systems which uses decomposition and synthesis of partial solutions to a problem. DDIS* is a hybrid case-based system for structural component design which uses case-dependent as well as independent design plans to arrive at a solution. It is, however, not clear as to what the utility of a case-based system might be for a domain so well understood and formalised as component design. Kumar and Krishnamoorthy6 present a general framework for CBR applications in engineering design and illustrate their ideas in the domain of bridge design. Another work which might be of relevance here is 0xman.17

A description of the structural design process is given in Ref. 19. From this discussion the following subtasks can be identified for the design process. 1. identify a pattern in the layout, 2. arrive at the components of the structural system which include, a slab system, a vertical load carrying system and a horizontal load resisting system. It should be noted that this is only one of the several approaches possible for conceptual structural design. Schodek interprets the design activity as manipulating the programmatic functions of the building with the objective of ordering them into a form such that when a physical building fabric is developed, the result will achieve the desired goals or aspirations. In this sense, the structural design is not independent of the architectural or functional design of the building. However, in order to simplify matters, structural design is separated from architectural and functional design. The spatial layout of the building forms the input to the structural design activity. Having obtained the spatial layout, the structural designer decides on a structural system, consisting of elements of adequate strength that do not violate the constraints set by the architect and other regulatory codes of practice. The constraints set by the architect may include the limitations on the placement of structural members within the building space and the limitations on the dimensions of the members. A single constraint may decide whether a totally different system should be adopted for a subsystem like roof system. What is important to note is that design may not simply consist of solving a set of equations, to satisfy a set of constraints. The conceptual structural design of buildings is very different from parametric design, where the design task consists of arriving at values for a set of variables. It is different from the configuration type of design, in which design consists of selecting a combination of components from a given set. It is not entirely a planning problem, in which the operators are predefined and the solution consists in arriving at the sequence. Nor is it simply a space-state-search problem, where the search space is clearly defined. It is also not even a domain in which designs can be generated from first principles, since the exact reasons for a structural system being the way it is, require deep domain knowledge. Finally, it is not an activity involving a fixed set of steps which can be coded by a procedural program either. The solution to a conceptual structural design problem is not just a set of attributes and values. It usually involves a qualitative description of the structural system normally accompanied by drawings. The design has considerable spatial and geometric characteristics making it difficult for adaptation. We thus feel that the method/s used to arrive at a solution is easier to be reused than the solution itself.

8 CADREM: MODEL

AN APPLICATION

OF THE MREM

8.1 Introduction

A prototype system was developed to demonstrate the ideas developed in this work. It is called CADREM (CAse based Design using REconstruction Methods). The emphasis was not on developing a computer system that could be put to use for real design problems, but on testing the model. Because of this, emphasis was not given to the efficiency of the code or the user interface. CADREM is a case-based design system for the conceptual structural design of buildings. CADREM consists of structural designs compiled from published literature.18 Possible design methods are created from them manually by doing a detailed study of these designs and fed into the system as MREMs. Guidelines provided by Schodek are followed in creating the design methods. He suggests that the type of structural system adopted in a building is largely a result of the geometric pattern that has been identified in the building layout. Certain patterns are more suitable for certain structural systems and so on. Using the methods that are compiled from cases, CADREM tries to generate a conceptual structural system for a given layout by identifying known patterns in the layout.

Reconstructive memory in case-based &sign

253

The problem is ill-defined and has multiple solutions, which cannot always be evaluated using expressions. 8.2 Applying the MREM model This concept of MREM was used in the development of CADREM. The design methods that were created manually from designs in published literature* were stored as MREMs. Cases in CADREM consist of these MREMs. It should be noted that the solution is implicit in the representation of an MREM since they can be reconstructed whenever necessary. Details of CADREM can be found elsewhere.5 In the following section some illustrations from CADREM are given. 8.3 Illustrations from CADREM
8.3.1 Some examples of MREMs

A brief study of the case. From the limited amount of information that is published, some assumptions have to be made about the design method. For example, the following information is not available:

1. What were the factors that led to the adoption of a solid flat slab system? 2. Why was the span to depth ratio taken as 24? 3. What factors led to the removal of the columns from the three corners of the building? 4. Was the span of 7.2m specified by the architect? 5. What were the problem specifications?
How to create an MREMfrom this case? There are three

issues involved here. 1. reconstructability 2. generality; and 3. efficiency. of the solution description;

Some examples of MREMs taken from CADREM are given in this section. The objective is to bring out some of the practical difficulties in creating MREMs and applying the MREM model.
Example: Case 1. Figure 2(a) shows the layout of a building (published by BCAt8). A symbolic representation of this case is shown in Fig. 2(b).
7200 c 1 7200 c 1 7200

300 slab

It is clear that any MREM should be able to reconstruct the original solution. But if reconstructability was the only consideration, it would have been easier to store the solution alone in the form of variables and values. For instance, storing the coordinates of the plan of the building and the position of the columns, the drawing [Fig. 2(a)] could be generated. It is clear that the information in Fig. 2(b) can be represented as attributes and values. However, storing the coordinates of the columns alone does not permit the application of this case to other problems as the shape and dimensions could be totally different. Hence the method to calculate the positions of the columns from the given shape and dimensions should be represented. For the particular shape, which is a square, the procedure turns out to be quite simple, but with some minor problems like, What should be done if the size of the square is not an integer multiple of the specified span? Should the span be modified or should the last series of columns be placed at a different spacing? If the span is modified, should the slab type and span to depth ratio still be kept the same? What should be done if the shape is a rectangle instead of a square? Should the procedure be defined in terms of a rectangle to make it more general?

The above discussion brings out the fact that there are a number of ways in which MREMs could be defined. Varying degree of generality could be introduced in MREMs without sacrificing the reconstructability of the original solution.

Fig. 2. (a) Case 1; (b) symbolic representation of Case 1.

An MREM de$nition. This MREM could be defined using the MREM-type subtask-definitions. The top level task for which the MREM can be applied is designing a layout. The subtasks for this MREM are defined as follows (translated into natural language for clarity):

254
1. Instantiate

B. Kumar, B. Raphael variable, number of floors, with the constant 2. Instantiate variable, design load, with the value 6.0. Check if the shape of the building is a rectangle. Position the columns (a sub-MREM does this task). Calculate the critical span from the column positions. Instantiate slab of type solidflat slab. Instantiate variable, span to depth ratio of the slab, with a value 24. Instantiate variable, depth of the slab, using a certain expression. Instantiate stability mechanism of type frame action. What extra knowledge does this MREM add to the system? (a) Some parts of the above MREM could be reused in a different problem. For example, the method to check the shape of the building and the method to position columns for a rectangular building could be applied to a different problem. (b) The values of variables used in the MREM could be reused for a different problem. For example, the value of span to depth ratio of the slab could be reused. (c) A solution plan is obtained from this MREM for solving this type of problems. (It is known to the system that the solution could be arrived at by carrying out the subtasks outlined.) The actual method (sub-MREM) used to carry out the subtasks may be obtained from other cases. For example, the same subtasks could be carried out for a building have a different shape with only the methods to position the columns and calculate the critical span replaced from a different case. Example: Case 2. Figure 3(a) shows the layout of a building published by BCA.18 Figure 3(b) shows the symbolic representation. The feature of this design case is the fact that the same floor slab has two different depths in two regions. In the middle region the depth of the slab is 300 mm corresponding to a column spacing of 7.5 m, whereas the outer region has a higher depth of the
3000

2. 3. 4. 5. 6. 7. 8. 9.

It should be noted that all the variables are instantiated within the MREM, even the variables like number of floors and design load which should normally be part of the problem specifications. There are two reasons for doing this in this manner. The first is, it is not clear what are specified in the problem specifications and hence the separation cannot be made. The second reason is that while an MREM is applied to a different problem, only the variables that are not specified already are instantiated using the method defined within the MREM.
3000 5 @ 7500

ti

3 @ 7500

!
!

400 slab

I
8

I
300 slab

I
n

400 slab

I I

I I

rl
Fig. 3. (a) Case 2; (b) symbolic representation

of Case 2.

Reconstructive memory in case-based design slab of 400mm, corresponding to a higher value of the column spacing. The fact that there is no single value of depth of slab or a single value of the span requires that the representation has to be slightly different from the previous one. The subtasks of the MREM in example 1 are not applicable in this case. This case is handled in CADREM as follows: The building is split into three regions as shown by dotted lines in Fig. 3(a). The problem is divided into two subproblems, the first subproblem to design the slab in the middle region and the second subproblem to design the slab in the outer two regions. (The boundaries of the three regions are stored in the preconditions.) The two subproblems are also identified as performing the same task as the original problem, namely, designing a layout. In the outer regions the columns are positioned at a larger spacing and in the inner region, the columns are positioned at a lower spacing. The top level subtasks are given below:
1. Check the shape of the 2. Separate the rectangular 3. Perform layout design MREMs for performing the one in example 1). . .
.

255
. .
. ,

& One way beam and slab

Floor type Num. floors Slab Span (m) Depth (mm) Span/depth Materials per sq. m ratio Concrete (m3) Rebar (kg)

1 10
6.0 220 27.27 0.26 42.0 5.0 Shear walls Grade C40 Code CPI 10

of floor area Design load (KN/m2) Stability Notes

building. region into three regions. for the three regions (the this subtask are similar to

Fig.

4.

Case

3 - (a) One-way beam and slab system, (b) symbolic representation of Case 3.

8.4 Sample outputs from CADREM How does this MREM alter the performance of the system? This MREM adds new processing knowledge to the system. Some of this is listed below: to divide a rectangular region into subregions; 2. the method of positioning columns at different spacings in the x and y directions. (The earlier MREM placed columns at the same spacing in the two directions.) The extra knowledge the system has acquired through the addition of this MREM may appear insignificant. But, this is a characteristic of incremental knowledge acquisition. Even if the amount of knowledge added at one time is small, it would result in considerable improvement in its capabilities due to combination of different pieces of knowledge. Integration of this MREM into the existing knowledge base. MREMs are represented as objects (in an objectoriented sense) and the objects are classified according to their type. The (sub-)MREMs for performing the layout design for the different regions of the building belong to the same type as the MREM in example 1. All of them perform the same task and have the same subtask decomposition. Hence they are grouped together. Note that any of the three MREMs (the main MREM as well as its subMREMs) could be chosen in a future problem for performing layout design. Similarly, the subMREMs instantiating the span to depth ratio of the slabs belong to the same type and are grouped together. Any of the three could be used in place of the others.
1. the method

Figures 4-7 are examples of snapshots of computer screens while running CADREM. On the top left is the input plan to CADREM. On the top right is the generated solution for this problem and on the bottom right is the case [Figs 4(a) and 4(b)] whose methods were used in generating this solution. This is a case involving a one-way-slab. It can be seen that for the given problem the input shape of the building is very different from the retrieved case. In spite of this, the case building-l was found to be similar to the problem because the pattern that was generated consisted of rectangular blocks continuous in one direction. Figure 6 is a screen shot for the same problem with a different solution. This solution was derived from a case involving two-way-spanning slab. Details of the solution

Fig. 5. One-way spanning arrangement.

256

Fig. 6. Two-way spanning arrangement.

. . . . . =I& . . . . . dl
a
0 0 0

B. Kumar, B. Raphael

knowledge can be incrementally added to the computer system which is automatically integrated into existing knowledge. Machine learning techniques like generalisation and conceptual clustering are relevant in this context and could probably give more power to CADREM.

9 CONCLUSIONS The following are the conclusions from this work: The view of remembering as a process of reconstruction of an event, rather than the direct retrieval of some information about the event, is a useful model for computer memory of past events. Storing the method (process) to reconstruct a past event enables more effective reuse of past information since a process can generate a class of solutions depending on different initial conditions. Representations that permit reasoning about processes are needed for adapting them to new situations. RBEX (retrieval based on examples) is a suitable alternative to conventional retrieval mechanisms. It fits in well with the MREM model as retrieval examples can also be represented as MREMs. Creation of RMs from REs are possible because of their object oriented representation which permit reasoning about them. Retrieval using RMs addresses many of the problems with existing approaches to retrieval. It avoids arbitrary similarity metrics and it integrates the process of assessing similarity with the design process.

like the column spacing are different from the previous solution and are taken from a different case. Figure 7 is a screen showing the input, solution and the retrieved case for a different problem. 8.5 Limitations of CADREM One of the main limitations of CADREM is the complexity in defining MREMs. The syntax of MREMs for performing complex operations are quite complex and is as difficult as writing a procedural programme for it. Hence, cases cannot easily be fed in by design engineers who are not familiar with CADREM. The power of a CBD system comes from the number and quality of its cases. CADREM is an experimental system with a limited number of cases. Because of this reason, the types of situations it can handle are limited. In the present implementation, the amount of machine learning in RBEX is limited. Most of the processing knowledge comes from retrieval examples. The improved performance as a result of the addition of retrieval examples comes mostly from the combination of parts of different examples and very little by generalisation. RBEX provides a means by which

9.1 Limitations and scope for future work The following are some of the limitations approach presented in this paper: of the

m:

Fig. 7. Solid flat slab system.

. . n_

The MREM-based approach provides a general framework for CBD. This approach suggests that research should focus on bringing out different ways in which cases could be used in specific design processes, rather than addressing issues in a generic fashion. Defining MREMs is a complex task. The difficulty lies in describing precisely the actions taken in a design. Means for simplifying this process need to be investigated. The issue of efficiency has to be addressed. Mechanisms needed for improving the speed of retrieval and application of MREMs have to be investigated. The process of generalisation of MREMs as well as REs could be improved using advanced machine learning techniques. The use of these techniques were not investigated in this research.

Reconstructive

memory in case-based design

251

REFERENCES
an expert system for the preliminary design of high rise buildings. Report No. R-85-146, Department of Civil Engineering, CarnegieMellon University, Pittsburgh, PA, 1985. 2. Sriram, D., Knowledge-based approaches to structural design. PhD dissertation, Department of Civil Engineering, Carnegie-Mellon University, Pittsburgh, PA, 1986. 3. Kumar, B., Knowledge Processing for Structural Design. Computational Mechanics Publications, Southampton, 1994. 4. Raphael, B. & Kumar, B., Indexing and retrieval of cases in a case-based design system. AZ EDAM, 1996, 10, 47-63. 5. Kumar, B. and Raphael, B., CADREM: a case-based system for conceptual structural design. Engineering with Computers, 1996 (in press). 6. Riesbeck, C. K. & Schank, R. C., Inside Case-Based Reasoning. Lawrence Erlbaum Associates, London, 1989. I. Schmitt, G., Bailey, S. & Smith, I. F. C., Advances and challenges in case based design. In Computing in Civil Engineering, ed. K. Khomeizeih. ASCE New York, June 1994, pp. 301-8. 8. Hua, K., Schmitt, G. & Faltings, B., What can case-based design do? Workshop on Case-Based Design Systems, Artijicial Intelligence in Design 92, 1992. 9. Hua, K. & Faltings, B., Exploring case-based building design-CADRE. AZ EDAM, 1993, 7(2), 135-43. IO. Kolodner, J. L., Case Based Reasoning. Morgan Kaufmann, San Mateo, CA, 1993. Il. Kolodner, J. L., Retrieval and Organizational Strategies in Conceptual Memory: A Computer Model. Lawrence Erlbaum Associates, London, 1984. 12. Wang, J. & Howard, H. C., A design-dependent approach to integrated structural design. AZ in Design 91, ed. J. S. Gero. 1991, pp. 151-69. 13. Mostow, J., Barley, M. & Weinrich, T., Automated reuse of design plans in BOGART. In AZ in Engineering Design, ed. C. Tong & D. Sriram, Ch. 2, 1989, pp. 57-103. 14. Raphael, B. & Kumar, B., Object-oriented representation of design cases. International Journal of Computers and Structures, 1995 (in press). 15. Maher, M. L. & Zhang, D. M., CADSYN: A case-based design process model. AI EDAM, 1993, 7(2), 977110. 16. Shiva Kumar, H. & Krishnamoorthy, C. S., A framework for case-based reasoning in engineering design. AZ EDAM, 1995, 9, 161-182. 17. Oxman, R., Precedents in Design: A Computational Model .for the Organization of Precedent Knowledge, Design Studies, Vol. 15. Butterworth-Heinemann, London, 1994, 141-158. 18. Matthew, P. W. & Bennett, D. F. H., Economic Long-Span Concrete Floors. British Cement Association, Wexham Springs, Slough, 1990. 19. Schodek, D. L., Structures. Prentice Hall, Englewood Cliffs, NJ, 1980.
1. Maher, M. L. & Fenves, S. J., HI-RISE

not have any information about where the particular value or the constant came from, e.g. var_inst_ with-constant: span_to_depth_ratio = 24.
MREMperforming variable instantiation with an expression: This MREM is more general since it can yield

different values of the variable corresponding to different values of the variables appearing in the expression. It still however does not have any information about why the expression was used or under what circumstances it can be reused, e.g. var_inst_expr: depth-of-slab = span/span-to-depth ratio.
MREM performing conditional instantiations: This involves a condition and a variable instantiation. Unlike a conditional expression in a programming language, the condition is considered as a reason (justification) for the particular action. These are similar to rules. However, they still cannot be regarded as general rules since they could contain hidden assumptions (which are not explicitly stated) and which are related to the particular problem solving episode, e.g. condition: num_floors > 15; action: stability = shear-walls. MREM performing variable group instantiations: This involves instantiating a group of variables that cannot be separated. Explicit knowledge is not available about the relationship between the values of the variables, e.g. slab-type = ribbed-slab, size-of-rib = 50. MREM performing transformation of variables: This involves modifying the value of a variable using an expression (transformation), e.g. transformation_var: depth-of-slab = 1.2 x depth-of-slab. Composite MREM: This denotes contains other MREMs within it.

an MREM

which

MREM that does planning: This denotes an MREM which does chaining of some predefined rules. MREM that does task elaboration: This denotes a process that just sets the subtasks for the current task. MREM that does constraint propagation: This denotes a process that adds new constraints using the existing constraints, e.g. constraint propagation: constraint cl: clear-height of a storey >3 m, propagated constraint c2: depth of slab < 300. Creating specialised classes of MREMs: Specialised classes of MREMs are created from the base classes according to several schemes. Some of the schemes used in creating special classes are mentioned in this section.

APPENDIX: SOME OF THE BASIC MREM TYPES

MREA4 performing stant: One of the variable simplest instantiation with a con-

MREMs is a variable instantiation with a constant. In order to represent this process all that requires to be stored are the variable name and the value of the constant. This MREM does

258

B. Kumar, B. Raphael MREMs that have a specific control structure: Special classes of MREMs could be created that follow a specific pattern in the control structure. For example, a propose-critique-modify type of MREM involves instantiating a solution, examining a set of conditions and then making certain modifications. MREMs that satisfy a certain goal or set of goals:

MREA4s that perform a speciJic task: Special classes of

MREMs can be created based on what they do. For example, a special class of MREMs could instantiate a specific design variable, say, span to depth ratio of a waffle slab.
MREMs that can be applied under a specljic situation:

Special classes of MREMs can be created based on the conditions under which they could be applied in given situation (similar to a forward chaining rule). For example, a special class of MREMs could do repair in the event of a failure of constraint, say, the depth of a slab exceeds the specified limit.

Special classes of MREMs could be created based on the goals they achieve. Different abstractions of the goals result in different abstractions of MREMs belonging to this class. For example, a special class of MREMs could satisfy the goal, provide lateral stability.