ASA: A conceptual design-support system

Pergamon PIhS0952-1976(96)00080-2

EngngApplic. Artif lntell. Vol. 10, No. 1, pp. 99-111, 1997 © 1997 Elsevier Science Ltd

Printed in Great Britain. All rights reserved 0952-1976/97 $17.00 + 0.00

Contributed Paper

ASA: A Conceptual Design-Support System A L B E R T O G I R E T T I

University of Ancona, Italy

L U C A S P A L A Z Z I

University of Ancona, Italy

(Received June 1995; in revised form September 1996)

This paper proposes a computational architecture for conceptual design support that integrates typical CAD editing activities with symbolic information processing. The architecture is composed of a knowledge representation server and a variational CAD system. The knowledge-representation server is based on a terminological language which is expressive enough to represent the knowledge involved in a design process, and to support the typical inferences used in a case-based design-support system. The knowledge- representation server contains both episodic knowledge, stored as cases in a long-term memory, and general domain knowledge. It supports the usual strategies of case-based design-support systems as case retrieval and case adaptation. The variational CAD environment processes the geometric information. The variational approach to the geometric representation of domain elements separates the metric aspects from the topological aspects of design artefacts. As a consequence, inferences on topology can be performed at a symbolic level, obtaining an increased integration between geometric and symbolic knowledge. The system is part of the ASA project, under development at the University of Ancona. © 1997 Elsevier Science Ltd. All rights reserved

Keywords: Case-based reasoning, terminological languages, CAD, conceptual design, knowledge representation.

1. INTRODUCTION

Conceptual design is a human activity which benefits from the application of computer-aided design techniques. In the last decade, there has been an evolution of computer-aided design systems from drafting, calculation and simulation utilities, towards systems that are able to support the conceptual phase of the design processes (Eastman, 1991; Gero, 1993; Haber and Karghenas, 1994). Systems support- ing some aspects of conceptual design have been built according to different paradigms, such as task analysis, design prototypes, case-based reasoning, etc. (Yu and Adeli, 1991; Aouad et al., 1994; Chandrasekaran, 1990; Gero, 1990; Maher et al., 1995). The experience gained in conceptual design support has highlighted some issues:

• Design cannot be reduced only to a problem-solving task, at least in the sense adopted in the AI community. In fact, design has the further complexity that the requirements (i.e. goals) usually change during the process itself. Thus,

Correspondence should be sent to: Luca Spalazzi, Istituto di Informatica, University of Ancona, via Brecce Blanche, 60131 Ancona, Italy [E-mail: [email protected]] .

99

design is usually considered as an exploration task, i.e. it involves both the transformation of the initial requirements and the synthesis of the final device. Design is a task that operates on many different representations of the complex real world. Each world model captures only some partial aspects of the reality. Thus the different kinds of knowledge involved in the design process must be integrated (e.g. geometric knowledge, functional and/or behavioural models, past design experience, design process knowledge like histories, failures, etc.). Knowledge integration is quite common in the human practice. As a matter of fact, designers unconsciously integrate many different kinds of knowledge through the propagation of inference effects from one domain to others. For example, during the definition of a house lay-out, i.e. a purely geometric disposition of building elements, an architectural designer frequently makes inferences about lighting and/or thermal aspects, and propagates the effects to the geometrical disposition (mostly as additional constraints). The design activity is usually based on past experience, especially when the problem domain is not completely

I00 ALBERTO GIRETTI and LUCA SPALAZZI: ASA

modelled in a closed form. Experience provides designers with the appropriate guidelines in order to avoid mistakes previously made, to find solutions more efficiently, and to preview solutions. Thus, designers spend part of their time thinking about existing design experience and reviewing the literature, instead of starting from scratch. This involves the designer's ability to recall pieces of past successful designs, and to insert them into a new context according to considerations performed in different domains.

Design-support systems (Adeli and Hawkins, 1991; Barber et al., 1992; Berraris and Watson, 1994; Kolodner, 1991) are built with the aim of assisting the designer in the management of extensive and complex knowledge, and of providing some autonomous problem-solving abilities that are usually applied to limited and well-understood domains. Knowledge integration, reuse of past experience and design choice repercussions are the problems usually faced by such support. For example, knowledge integration requires a computational model that is able to represent every kind of processed knowledge uniformly (i.e. by using the same schema). Thus, knowledge integration strongly suggests the use of formal knowledge-representation languages. The reuse of past experience has been addressed by several authors using different approaches (Adeli and Yu, 1995; Kolodner, 1991). This issue plays a central role, especially in case-based reasoning (Kolodner, 1993). Case-based design support (Barber et al., 1992; Kolodner, 1991; Pearce et al., 1992) is the application of case-based reasoning to design support. The main processing cycle of a case-based design system can be summarised in the following phases: problem assessment, key definition, case retrieval, case adaptation, solution evaluation, solution storing, or, in case of failure, failure explanation, failure storing and solution repair. A complete explanation of the above phases and of the issues involved is outside the scope of this paper; the interested reader can find further information in (Kolodner, 1993). The requirement for knowledge integration in a case- based support system is specialised as the integration of episodic knowledge (cases) with general domain knowledge (domain models) (Goel, 1991; Bhatta et al., 1994). Tight integration of general domain knowledge with specific situation knowledge is the main issue involved in the construction of effective reasoning systems in complex, real-world situations. "If we put the two (case based reasoning and model based reasoning) together, letting each provide what it specialises in, we will be able to build robust reasoning systems that can both reason efficiently about generalised situations and cover idiosyncrasies of atypical ones" (Kolodner, 1993, p. 96). A good example of the integration of multiple types of knowledge and reasoning is given in (Goel and Chandrasekaran, 1992).

This paper proposes a computational architecture for conceptual design support, called the Architectural Sym- bolic Assistant (ASA) (Giretti et al., 1994; De Grassi et al., 1996). ASA integrates a case-based reasoning system with several domain models in order to produce a case-based

design-support system. The case-based reasoner adopts a terminological language for knowledge representation. The terminological language has been defined in order to capture the structural properties of the represented knowledge. The resulting knowledge structure uniformly represents both episodic knowledge, stored as cases in a long-term memory, and general domain knowledge. The main topic of this work is the analysis of the application of the formal knowledge- representation schema (i.e. the terminological system) to the construction of a case-based design system.

Section 2 gives some formal aspects of the knowledge representation, and Section 3 the related basic algorithms. Section 4 describes the architecture of the system. The system inferences, with some examples, are given in Section 5. Finally, Section 6 draws some conclusions.

2. KNOWLEDGE REPRESENTATION

Basically, the knowledge involved in a design process can be classified into static knowledge, which describes declarative theories of the application domain, and design task knowledge, which combines design goals with basic inference procedures. The following sections introduce the formalisms used in ASA for the representation of both domain and task knowledge.

2.1. Domain knowledge representation language-- ASACL

The basic assumption for the description of the application domain is that it is possible to structure the knowledge according to both generalisation/specialisation and part-of relationships. Therefore, the knowledge-representation schema follows the line of the structured knowledge representation (e.g. semantic networks and frames); in particular it reflects many aspects of terminological and feature languages (Plaza, 1995; Schaerf, 1994). On the KL- ONE line (Brachman and Schmolze, 1985), the basic knowledge-representation object is called a concept. Essen- tially a concept is a structured description of a meaningful aspect of the application domain; it may be a design element or a domain relationship. So a concept asserts the relevant conditions for the identification of the element or a relationship in a domain status. Indirectly, a concept also projects a classification on the application domain. The syntax and semantics of the ASA Concept Language (ASACL) are outlined below.

2.1.1. Definition 2.1 (ASACL syntax) Let ASA concept names, host concept names, attribute

names, function names, and host individual names be distinct sets of symbols. Then concept and attribute terms are inductively defined as follows:

Base:

• Every ASA concept name is an ASA concept term • Every host concept name is a host concept term • Every attribute name is an attribute term

ALBERTO GIRETTI and LUCA SPALAZZI: ASA 101

Step: Let C be a concept term. Let D, D~ . . . . . D~ be ASA concept terms. Let A, A~ . . . . . Ak be attribute terms. Let h~ . . . . . h, be host individual names. Let k~, k2 be numbers. Let n be a non negative integer. Let R be a function name. Then:

• HOST-THING • NUMBER • SYMBOL • STRING • (ONE-OF hi "" h,) • (RANGE kl k2)

are host concept terms;

• ASA-THING • (And D l D2 "'" Dk) • (All A C) • (RVM Aj A2) • (Test R A l A 2 ... A,)

are concept terms;

• THING • BOTTOM • host concept terms • ASA concept terms

are concept terms;

• (A I ""A. )

is an attribute term. Roughly speaking, a concept term represents a set of

domain individuals. An attribute term is a map among individuals. The term (A~ ... A,,) represents a function composition. T H I N G is a concept representing the whole domain. B O T T O M represents the empty set. The host concepts represent basic data types of the host language (LISP in this case). As a consequence, N U M B E R and (RANGE kl kz) represent the set of numbers and an interval respectively. S Y M B O L and (ONE-OF h~ ... h,,) represent all the symbols and a subset of symbols, respectively. Finally, S T R I N G denotes the set of host strings. The other concepts are used to represent the domain knowledge. (And CI Cz "'" Ck) is the concept sharing the features of Cl C2 "'" Ck, i.e. it is the intersection among the sets of individuals denoted by C1 C2 "'" Ck. (All A C) is a concept with an attribute A filled by instances belonging to C. (RVM A~ A2) denotes the set of individuals where the contents of the A~ and A2 attributes are equal. In practice, ASACL revealed the utility of attaching a procedure to test whether an individual belongs to a concept. The procedural attachment is represented by the concept (Test R A~ A2 "'" A.). The practice also revealed a useful and recurrent term combination, that is called Rule. It is useful to represent structural relationships among domain elements. (Rule R C (An A21) "'" (A~, Az,,)) is a concept whose attributes An, ..., AI, share respectively the same fillers of the attributes Az~, ..., A2, that belong to a concept C (the structural rule). (Rule R C (An Azl) "'" (AI,, A2,)) is equivalent to (And (All R C) (RVM An (Azj R)) "'" (RVM AI, , (Az, R))).

The semantics of ASACL are inductively defined on the semantics of concept names and attribute names. Let el be

the set of all domain individuals, then the interpretation of a concept name is a subset of A and the interpretation of an attribute name is a subset of ell × At. Thus the semantics of ASACL can be formally defined as follows.

2.1.2. Definition 2.2 (ASACL semantics) The ASACL semantics is defined relative to an inter-

pretation L An interpretation I consists of a domain, A, and an interpretation function (.)1. A is divided into two disjoint sets: AA and A n. The interpretation function is recursively defined as follows:

Base:

Let H be a host concept name. Let E be an ASA concept name. Let A be an attribute name. Let h, h~ . . . . . h, be host individual names. Let k~, k2 be numbers. Let R be a function name. Then:

(1) hIeAH (2) THING i: = AA

(3) ASA-THING/: = AA (4) HOST-THING/: =A n (5) BO'ITOMI: =0 (6) EICAA (7) HICAn (8) NUMBERICAn (9) SYMBOLICAH (10) STRINGICAn (11) (ONE-OF hi "" h , ) l : = { h / . . . . . h,/} (12) (RANGE kl k:)1: = {xl x e N U M B E R 1, x>kl, x<k2} (13) AI: AA'---I'A (14) RI: Aa---*{True, False}

where NUMBER 1 f3 SYMBOL1=0, NUMBER 1N STRINGI=0 , S Y M B O L Z A S T R I N G I = 0 , and A / and R 1 are total functions over A A.

Step:

Let C, D be concept terms, let A~ . . . . . A,, B~ . . . . . Bm be attribute terms, and let n be a positive integer. Then:

(1) (And C D)1:=C1fqD 1 (2) (ALIA C)I:={a~ AAIAt(a)eCI} (3) (RVM A~ A:) 1: = { a ~ dal A j l(a) =A2 I(a) } (4) (Test R AI "'" A,)I:={aEAA I RI(AI 1

( a) . . . . . A, l(a) ) = True } (5) (Ax "'" A,)/(a): =AI 1(... A t (a ) ...) for each a m A A.

Notice that according to the above semantics, the semantics of a rule can be derived as follows:

(Rule R C(A l A2)) /

:= {a e AAI R1(a) ~ CI AA ~(a) =A 12(Rl(a)) 1.

Now it is possible to define the notion of subsumption. A concept C1 subsumes a concept C2(C1 >i C2) if the set of individuals denoted by C/includes the set denoted by (?2.

102 ALBERTO GIRETTI and LUCA SPALAZZI: ASA

2.1.3. Definition 2.3 (subsumption) Let CI, C2 be concept terms. Then C~ subsumes

C2(CL>-C2) w.r.t. I iff C~tDC~. The subsumption relationship captures the generalisation/

specialisation relationship that can be stated between two concepts.

2.2. Task knowledge representation language

Design is basically a purposeful activity, in which many strategies are applied in order to accomplish a design goal. The application of a strategy in a design domain produces a transformation of the current state into a new one. Task knowledge is the knowledge related to the representation of goals, strategies and transformations. The ASA Planning Language (ASAPL) is the representation language of goals and strategies, and is based on the basic notion of primitive action. A primitive action is an immediately executable action, i.e. a basic transformation of the domain state. It transforms a set of instances (individuals) into a new one. Any planning expression represents a strategy in terms of (sub-)goals and primitive actions. Strategies are expressed by means of the ASA Planning Language as follows:

2.2.1. Definition 2.3 (ASA planning language--ASAPL) Given the set of concept terms and two disjoint alphabets

of symbols, primitive actions and goals; the set of planning expressions is inductively defined as the smallest set such that: if P, P~ . . . . . Pk are planning expressions and C is a concept term, then:

• Every primitive action is a planning expression. • Every goal is a planning expression. • (And P~ Pz "'" P~) is a planning expression. • (Or Pi Pz "'" Pk) is a planning expression. • (Sub P~ Pz) is a planning expression. • (Inelass P C) is a planning expression. • (Seq P~ Pz "'" P~,) is a planning expression. • (Orelse P~ Pz) is a planning expression. • (Iffail Pm Pz P3) is a planning expression.

And, Or, Sub and Inclass are called algebraic operators. Roughly speaking, the effects of (And P~ Pz "'" Pk) and (Or Pm Pz "'" Pk) are the intersection and union respectively of the effects of each strategy P~. (Sub P~ Pz) represents the effects of P~ minus the effects of P2. Seq, Orelse and Iffail are called control structures to handle failures (see Giunchiglia et al., 1994). The effects of (Seq Pt P2) are the effects of P2 applied to the effects of Pv When P~ fails (i.e. the final set of individuals is empty) the overall action fails too. (Orelse P~ P2) denotes the effects of Pi when it does not fail; otherwise the effects of P2- Similarly, (Iffail P~ P, P3) denotes the effects of the sequence P~, P3 when P~ does not fail; otherwise the effects of P> The semantics of planning expressions is inductively defined on the base of the semantics of goals and primitive actions and the starting situation (i.e. the initial set of individuals). Let XJC_AA be the set of all instances reachable by plans; the semantics of a goal G or a primitive action A is the set of all the

transitions from an individual to another one, i.e. A JCXJ X X y and GJCXJ X X ~.

2.2.2. Definition 2.4 (semantics of ASAPL) The semantics of ASAPL is defined relative to an

interpretation J. The interpretation J consists of a domain XJCA, a starting situation SC_X J, and an interpretation function (.)s s. The interpretation function is recursively defined as follows:

Base:

Let A be a primitive action. Let G be a goal. Let A J and G J be the semantics of A and G respectively. Then

• GsJ:={(a,b)l a~SA(a,b)EG J} • AsS: = { (a,b)l a ~ SA(a,b) ~_AI}.

Step:

Let P, P~ . . . . . P k be planning expressions. Let C be a concept term. Then

• (And PI P2)Js: = (a,b)l a ~ S A ( a,b ) E P ~s U PJsAb ~ im( PJ~s) if) im( P ~s)

• (Or Pi P2)~: = { ( a,b )la e S A ( a,b ) E PJ~s U P ~sAb E im( Pf ~) U im( P ~s) }

• (Sub Pj P2)~: = { (a,b)Fa E SA(a,b) E PJlsA(a,b) ¢£ PJs) }

• C ) s: = (Inclass P s { (a,b)la ~ SA(a,b) E PJsAb ~ C j }

• (Seq PiP2)Ss := { (Co,C2)lc 0 ~ SA 3c I .(co,cl) ~ PJsA(C.,C2) E (P2) J,,~o }

• (Orelse PI P2)~ :=

{ P~s i fP{s=O

P{s otherwise

• (Iffail PI P2 P3)Ss: =

{ P~s if P{s=O (Seq Pl P3)~ otherwise.

The language is interpreted by a planner that builds the related plan and applies the plan to the initial set of individuals.

3. ELEMENTARY TASKS

3.1. Subsumption

Subsumption is one of the main reasoning services offered by a concept-based system. Terminological languages allow the subsumption relationship to be computed (i.e. defined semantically) using the structure of the concept definition (which is essentially syntactic). The computational complexity of the subsumption algorithm depends on the expressive power of the defined language. An overview is given in Schaerf (1994). The algorithm for the computa- tion of the subsumption relationship in ASACL is a


straightforward extension of Borgida and Patel-Schneider (1994). The algorithm is sound but not complete: for any pair of concepts C and D, when the algorithm returns that D subsumes C (D-->C), this guarantees that D I ~ C ~ holds, but the converse is not true. A simplified version of the algorithm is given below.

3.1.1. Algorithm 3.1 (subsumption) Subsumes (D,C): D>--C holds if one of the following

verified: conditions is

(1) C is BOTTOM. (2) D is THING. (3) D is HOST-THING and C is a host concept term. (4) D is NUMBER and C is NUMBER or (RANGE kl k2). (5) D is SYMBOL and C is SYMBOL or (ONE-OF hj ...

h,,). (6) D and C are both STRING. (7) D is (RANGE kl k2) and C is (RANGE k 3 k4) and kl <~k3

and k4 <~ k2. (8) D is (ONE-OF h I ... h,,) and C is (ONE-OF k I ... k,,) and

{ k I .-. k m } { h I ... hn}.

(9) D is ASA-THING and C is an ASA concept term. (10) D is (And Di and D2) and Subsumes(Di,C) and

Subsumes(D2,C). (11) C is (And Dj and D2) and Subsumes(D, CO or

Subsumes(D,C2). (12) D is (All A Di) and C is (All A C 0 and Sub-

sumes (D,C O. (13) D is (RVM A B) and C is equal to D. (14) D is (All A D 1) and C is (And (All B Cj) (RVM A B))

and Subsumes( Di,Ci). (15) D is (And (RVM A B) (All B D~)) and C is (ALIA C 0

and Subsumes( D t , C~). (16) D is (Test R A~ ... A,) and C is equal to D. (17) D is an atomic concept and D is equal to C.

3.2. Deductive closure

Another important reasoning service is called "concept instantiation". In ASACL two kinds of concepts can be defined, primitive and derived. Primitive concepts assert the necessary conditions to identify the related domain aspects, while derived concepts assert both necessary and sufficient conditions. Therefore, primitive concepts are instantiated by means of procedures attached to the primitive concepts themselves. Derived concepts are recursively instantiated by means of the concepts which play a role in the definition, and satisfy the compositional rules. The recursion stops at primitive concepts.

The concept-instantiation procedure checks whether a set of primitive data exemplifies the intention expressed by a given concept structure. The concept instantiation procedure starts from the queried concept, and goes on through the links until a primitive concept is found. The attached procedure is performed, and the set of instances of the primitive concept is returned. The concept instantiation

receives a concept description as input, and computes all concept instances.

3.2.1. Algorithm 3.2 (concept instantiation) Concept_Instantiation ( C)

If C is a primitive concept then call the attached procedure and return the generated instance set.

Else if C is a derived concept of the form (And ... (All Ai Ci) ". (RVM AJ Bj) ... (Test Rk Akl "'" Ak,,) "-')

• For each (All A i Ci) do any possible assignment with instances generated by Concept_Instantiation ( Ci)

• For each (RVM Aj Bj) any possible assignment on attributes Aj, B i is in the instance set iff the assignment on AJ is equal to the assignment on Bj.

• For each (Test R, Akl ... Akn) any possible assignment o n Akl ... Atn is in the instance set iff the function attached to Rk returns true.

End

3.3. Planning

The planning algorithm generates a plan for a given goal. For each goal there exists a related planning expression with (sub-)goals and primitive actions. The system keeps track of the link between a goal and the related planning expression. The planning algorithm recursively generates a plan for each goal in the planning expression, and stops when the plan expression has only primitive actions. No detailed description of the algorithm is given here, since the implementation details are beyond the aim of the paper.

4. A COMPUTATIONAL ARCHITECTURE FOR DESIGN SUPPORT

This section introduces the ASA computational architecture, consisting of the memory organisation and the computational process flows.

4.1. The ASA architecture

One of the most important aspects of a knowledge-based system is its internal memory organisation. The ASA memory organisation is shown in Fig. 1. The episodic

Conceptual Memory

,L T Working Memory

7

1 7 Episodic Memory

Sub-Conceptual Layer

Fig. 1. Memory organisation in the ASA system.


memory and conceptual memory are long-term memories, while the sub-conceptual layer and the working memory are short-term ones.

The sub-conceptual layer is so called because it contains procedural knowledge that appears to be unstructured from the point of view of the conceptual memory. The implementation of the sub-conceptual layer consists of several custom sub-systems which perform specific domain- dependent actions. For example, in ASA one of those sub-systems is the CAD system, which contains custom procedures on geometrical and numerical data (Fig. 2). The CAD system is based on the variational geometry paradigm as defined in Light and Gossard (1982). The main idea is that the representation of the geometrical data is split into two aspects: the topological and metric aspects. Topology is implicitly defined through control points and constraints, while metric aspects are captured by the coordinate values of control points. A constraint-satisfaction engine estab- lishes the geometry once the values of parameters have been set*. On that base, detailed parametric representations of

*Constraint-satisfaction engines and variational CAD are well described in the literature (for instance see Kolodner (1993)); readers are referred there for more details.

architectural domain objects have been defined. Every object is a template containing primitive building blocks which are related by assembling constraints, and dimen- sioned according to default values. Moreover, this structure is not reflected on the conceptual side of the system, which still looks at the domain object as an atomic element * Domain objects usually also have some representations derived from the geometric one. For example, a thermal model of a window is obtained from the geometric model by assuming an approximate geometric representation (usually the volume occupied) and from some thermal transfer coefficients calculated on the basis of the materials used and their surfaces (Fig. 3). Given a derived value, a derived model also has the inverse transformation that imposes constraints on the related parameters of the physical model.

Conceptual and working memories are the usual T-BOX and A-BOX respectively of a terminological system. Therefore, the conceptual memory contains descriptive schemata of domain elements and relationships, and the working memory contains facts represented as concept

'The choice of what is primitive is not constrained by the system architecture, but only by efficiency and implementational limits.

Space

Architectural Space

Functional Space R o o m Circulation Space

B a t h ~ / ~ Architectural Element / / ~mmg room \ / \ ,/, \ / / Wall Door Window

v \ X / / " Kitchen ~ / Internal Wall \ '\ !

\ Stair ' 7 /~ ~ ', ', Conceptual Memory ' Comdor , ~ External Wall ,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . W i ; ; ....... ~ W 2 W 3 ) : ' / " , W 4 Di '{ . . . . . . . W i n l i ....... .,..K1.23 • • • • ..O ..O

W o r k i n g M e m o r y ": ::::!i}.:ii~:iii ::{:!.:!!{:!::.:::!} !~:: :::::::::::::::::::::::: ::::;~:. ....... : : / : : ' [ /::[}';: . ...... . . . . . . . . . . . . . . .......................... 7": ::. ~:] ~:::~:: . . : . . / . . . . . . . . . ;..." .......... ," ..." .. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,{ I . ., . / . , , ,, / : L ,.: .......... : . . . . . . . . ¢ < : i : [ [ i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sub-Conceptual Layer ./" // /"" ...S .........

t Fig. 2. An example of links among conceptual memory, working memory and sub-conceptual layer. Dashed lines are

procedural attachments or attribute links.


Geometr/~ ~I aterials

"••,i M/

thermal coefficient: surface: ...

(a) (b) (c) Fig. 3. An example of a domain object model. A domain object model is a detailed representation of geometrical and material attributes and of assembly

constraints (a). It is an assembly of more primitive parts (b). It has derived models obtained by the physical model (c).

instances (Fig. 2). Schemata are represented by means of ASACL; thus they are organised according to a subsumption hierarchy and structured by means of part-of relations. Moreover, concepts have attributes and rules that associate concepts to other concepts, forming a network that termi- nates at primitive concepts. These are a special kind of concepts, mirroring the sub-conceptual layer in the declarative knowledge representation. Every primitive concept instance has an image in the sub-conceptual layer (e.g. a parametric object in the variational CAD system) and a set of custom procedures. The procedures are the machinery used to exchange knowledge between the working memory and the sub-conceptual layer. Every time a primitive instance is inserted/modified in the working memory, a parametric object is created/modified in the sub-conceptual layer (e.g. a CAD system). On the other hand, every time a parametric object is created/modified in the sub-conceptual layer, the attached procedures create/modify an instance in the working memory, with the attributes appropriately filled. Therefore, the procedures maintain the working memory level, and the sub-conceptual layer is consistently updated.

Episodic memory contains multiple indexed working memory images called cases. Thus cases are sets of instances. Concepts have links pointing to the cases that contain their instances• Therefore, concepts can be used as an indexing machinery for case access•

The implementation of the case memory is analogous to a relational database. Every concept points to a table which shares the concept template, and contains attribute values and logical links to other table rows (Fig. 4).

5. INFERENCES FOR DESIGN SYNTHESIS So far, this paper has only discussed the basic inferences

supported by the formal knowledge-representation schema. These services are the fundamental tools for the construction of more elaborate inferences for design support. The main system-processing loop is shown in Fig. 5. It is

essentially composed of two phases: an editing phase where the designer manually elaborates the project, and a problem- solving phase in which the system designs the artefacts that satisfy the desired requirements. An interpretation merges the two processing phases, building an internal representation of the design that allows the problem-solving process to work in the current status. Therefore the conceptual interpretation (see Section 3.2) is a fundamental procedure in the support activity. At present, in order to build the working memory image of the design status, the system iterates through the concept-instantiation procedure until every concept has been activated.*

The main design-support activity of the ASA system is the design synthesis phase. Design synthesis is essentially a translation of design requirements into a structural description of an artefact. A requirement can be either functional or structural. Since the system procedures make no distinction between functional or structural requirements, the general term "requisite" will be used below, in both cases.

The requisite-to-structure translation is performed using a case-based reasoning technique (CBR) (Kolodner, 1993). Basically, case-based design synthesis consists of two steps: case retrieval and case adaptation. Case retrieval finds past design solutions, and case adaptation tries to place them into the current design context.

5.1. Case retrieval Case retrieval is the process that collects useful pieces of

situation knowledge from the episodic memory. In order to retrieve a useful case, the system should be aware of both design requisites and contextual constraints. In fact, design requisites contain the information for defining the set of possible structures that the artefact should have. Contextual constraints restrict that set to the structures which can be consistently inserted in the current design status. Therefore, queries must include the contextual constraints the case has to satisfy. This approach is called context-driven searching.

*Obviously this is quite an expensive strategy. A more efficient strategy would be concept activation by means of domain heuristics.


Space - - - - - . . . ~

Architectural Space

Functional Space Room Circulation Space

Living room / / / ~ \ A ' ~ / / D i n i n g m o m \ / ~ ~ ' k ~ / /

Be °°m V \ V /

Stair "¢ Conceptual Memory i Corridor ,' ...... /

............................................................... ' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \~ ............. I', Episodic Memory , \" /:I

Case-Id ~ Id Drawing Wall: "'" C C # 1 ~ ! K # I ~ ........ ::::::::::::

Architectural Element

Wall Door Window

Internal W a l l ~

'i, External Wall

Case-Id '\ \ Id ,Drawing CAD Obj Id C C # 1 ~ _.: . . l i t # 1

~-ltf#: ', l

- L- -..Ca~e-ld 11d ! Drawing CAD Obj Id ' ~ C - : # 1 3 . . . . . :DY#~

Fig. 4. Episodic memory organisation. Cases are stored as a set of logically linked tables.

Moreover, designers sometimes use a different strategy to formulate design problems. Rather than asserting from scratch the features that the solution should have, they specify which features should be maintained, and which should vary with respect to the current design status. This strategy is called case-base navigation. ]'he interesting aspect is that variations are usually defined by denoting the strategy, rather than the final result. Examples are queries

Editing

Context Driven Search

Deductive Closure

l Requisite

Formulation

v

Case Base Navigation

Context Insertion

] Fig. 5. The main working cycle of ASA.

like "Increase lighting" or "Get a rather comfortable living room". The current system implementation supports both context-driven searches and case-base navigation.

5.2. Context driven searching

In the ASA system a search key is defined by means of the same language used to describe concepts. As a matter of fact, a search key is basically a partial description of the desired case, so it can be viewed as a concept. The subsumption procedure is then used to find the set of subsumed concepts, and in turn the set of cases they exemplify. For example, the query key of Fig. 6(a) requests a flat with a kitchen and at least two bedrooms. The set of subsumed concepts has more specialised members, as depicted in Fig. 6(b), where there are specifications about dining/living room, bathroom and their mutual adjacencies. An interesting aspect is the possibility of including in the definition of the search key both attributes and structural requirements. As a matter of fact, the structural description (i.e. the RULE expression) can be used to point out the relationships between the desired case and the context. This is called contextual searching. Figure 7 shows a pictorial example of this aspect. Given the lay-out of Fig. 7(a), look for a living room with a different shape. In order to obtain the right access between the corridor [Fig. 7(b)] and the kitchen, it is possible to ask for the adjacencies and accesses that are already present in the context. Fig. 7(c) shows the search key expression. The search key has been built by specifying the context (i.e. the whole flat) and the desired dining-room features (i.e. L-shape) by means of attribute chaining. Contextual relationships constrain the search to


(AND (ALL Kitchen Room) (ALL Bedrooml Room) (ALL Bedroom2 Room))

(a)

(AND (ALL Kitchen Room) Bedroom 2 (ALL Bedrooml Room) (ALL Bedroom2 Room) | (q (ALL Bath Room) Bath ,J /" (ALL Living-room Room) t_q (ALL Kitchen Room) (RULE R1 Accessible (Kitchen Space I) (Living-room Space2)) (RULE R2 Accessible (Living-room Spacel) (Corridor Space2)) Bedroom 1 (RULE R3 Accessible (Corridor Spacel) (Bedrooml Space2) (RULE R4 Accessible (Corridor Space l) (Bedroom2 Space2) (RULE R5 Accessible (Corridor Spacel) (Bath Space2)))

(b) (c) Fig. 6. A query key (a), the concept subsumed by the key (b), and the graphical representation of the concept (c).

Living room

i

the cases that share a similar context (at least as much as the rule expresses).

5.3. Case-base navigat ion

Requisites can sometimes be expressed as desired variations of a given situation. They correspond to goal-

driven navigation through the set of known cases. In order to perform case-base navigation, the system needs an internal representation of the differences between two cases, called difference relationships. Since cases are represented according to multiple concepts, there are many possible difference relationships: one for every pair of concepts. This

Bedroom 2

rq

Bath ~ /"

~J

Bedroom 1

Living room

O

(a)

Bedroom2

B a ~ ~ . _ ~ v i n g room

• Kitchen

Bedrooml

(AND (ALL (Living-room Shape) L-Shape) (ALL (Kitchen Shape) Rectangle) (RULE R2 Accessible (Living-room Spacel)

(Corridor Space2)))

(b) (c) Fig. 7. Contextual search: the search key is built using a structural description. Given the working case (a) it is possible to define a search key (c) for

an L-shaped dining room that has accesses (b) and adjacency to the kitchen and the corridor.

Accessibility Collection

2 Rt_~_#12

I I

Case #C 123 Case #C 124

Conceptual Memory Episodic Memory

Fig. 8. An example of concept collections. Elements are linked by means of relationships by analogy. Elements correspond to a case in the case memory. Following a relationship path, induces a navigation in the case base.


Operator: op#12 Goal: reduce surface Plot: (Orelse delete_node

(Seq delete_node deletenode))

Operator: op#22 Goal: delete node Plot: (Action Rt_acc_#12)

(a)

Plan_Node Top t

InClass corridor_paths._#3

I Plan_Node op#12

I Orelse

J ~ Plan__node oW22 Seq

Action Rt acc #12 Plan node oi>#22

/

Action RI acc #12 (b)

Fig. 9. Two examples of operator structures in ASAPL (a). A plan tree (b).

Plan node op#22

I Action Rt ace #12

high number gives rise to a computational burden when searching is performed. Furthermore, in order to represent only semantically grounded differences, it seems pointless to compute relationships among concepts that are not semantically comparable. These considerations allow the introduction of a further structure on the knowledge- representation schema, to state the semantic affinity between two concepts. A concept collection is defined as a set of concepts that share a good degree of analogy. Figure 8 shows a pictorial example of a concept collection. In this case the accessibili ty relationships of layouts are represented using graphs. They are grouped in an "accessibility collection", where differences among elements are related to differences in the graph topologies. Each element denotes a set of cases in the case base. The idea is that if a reasoning process traverses a relationship link, the set of denoted cases changes in a known way, i.e. according to the meaning induced by that relationship. If the traversal of a link is considered as a primitive action, it is possible to use ASAPL to express complex navigation strategies. The connections

between a goal and the related strategies are maintained in a structure called operator [Fig. 9(a)]. For example, given the case on the right in the case base of Fig. 8, suppose that one is searching for a flat with a topology more suited to a dimensional surface reduction. Suppose also that the disposition of the bedroom satisfies the requisites, so this should be retained. It is possible to activate the goal reduce_ surface with the further constraint that the current corridor paths have to be maintained. The goal can be expressed as:

(InClass corridor paths_#3 reduce_surface)

The planner produces the plan search tree of Fig. 9(b). First it builds the TOP plan node with the goal. Then it looks for an operator suited to solving the reduce_surface goal, and finds op#12. The strategy in op#12 says that, in order to reduce the surface, one should try to delete a node in the accessibility collection. If a failure occurs, one should try one more deletion. The plan is interpreted depth first. When a primitive action is found, the difference relationship is traversed, and the set of cases related to the image concept

Bedroom 2

Bath ~ ,- ,,.j Living

room Bedroom 1

(AND (ALL Living-Room Room) (ALL Kitchen Room) (ALL Bedrooml Room) (ALL Bedroom2 Room) (ALL Bath Room) (ALL Corridor Room) (RULE R1 Accessible (Living-Room Spacel)

(Kitchen Space2)) (RULE R2 Accessible (Living-Room Spaeel)

(Corridor Space2)) (RULE R3 Accessible (Corridor Spacel)

(Bath Space2)) (RULE R4 Accessible (Corridor Spaeel)

(Bedl Space2)) (RULE R5 Access ible (Corridor Spacel)

(Bed2 Space2)))

(AND (ALL Living-Room Dining-Room) (ALL Kitchen Kitchen) (ALL Bedrooml Room) (RULE RI Accessible (Living-Room Spacel)

(Kitchen Space2)) (RULE R2 Accessible (Living-Room Space 1)

(? Space2)))

(a)) (b) (c)

Fig. 10. An example of a retrieved case (a) and its description in the adjacency collection (b) The description in (c) is the result after a focus of attention on "Dining-room" and "Kitchen" attributes.


............................................................. C Bedrooml

Living-room

(AND (AND (ALL Living-room Room) (ALL Kitchen Room) (ALL Kitchen Room) (ALL Bedrooml Room) (RULE RI Accessible (Living Spacel) (ALL Bedroom2 Room) (ALL Bath Room) (Kitchen Space2)) (ALL Corridor Room) _ (RULE R2 Accessible(Living Spacel) (RULE R3 Accessible ?(~Spacel-)" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ Space2)))

(Corridor Space2)) (RULE R4 Accessible (Corridor Space 1)

(Bath Space2)) (RULE R5 Accessible (Corridor Spacel)

(Bed I Space2))

(a) (b) Fig. 11. Rule mapping: a constraint-satisfaction process assigns values to dummy variable (i.e. the symbol "?") in both descriptions. The constraints are

determined by the concepts of the attributes.

is returned. If the set is empty, a failure is returned. In the example the execution of the plan produces the left-hand case in the case base of Fig. 8.

5.4. Model-guided context insertion

The reuse of past experience is strongly connected to the ability to relate it to the situation one is working on. In case- based reasoning, this process is usually called adaptation (Hua et al., 1992). Thus, adaptation is the process that inserts a previously retrieved case in the current context in order to obtain a coherent situation. In the ASA representational paradigm, the insertion basically consists of a juxtaposition of two sets of instances, the first belonging to the context and the second to the retrieved case. Cases are juxtaposed by finding the appropriate compositional rules (i.e. the rules that regulate the interactions between the retrieved and the contextual sets of instances). Context insertion is the most complex part of the reasoning process because it operates according to many different interacting representations of both context and case. The reasoning process can be decomposed into two main steps: focus of attention and rule mapping.

Once contextual searching has been performed, the retrieved case sketches the whole scenario (i.e. the desired piece is inserted in the context). Thus the first thing to do is to separate the desired part from the rest (focus of attention). This can be accomplished by selecting the attributes that identify them. The attributes are related to the rules linking these parts to the case context. The rule set gives a very good guideline for the following rule-mapping phase. In fact, rule mapping is a constraint-satisfaction problem where variables are the attributes in the retrieved rule set, and values are context attributes. The problem is to map

context attributes to the attributes of the retrieved rule set. The map must satisfy the implicit constraints stated by the compatibility with the attribute filler concepts. For example, Fig. 10(a) shows the case resulting from the contextual search of Fig. 10. The case is described in the "adjacency" collection by an instance of the concept of Fig. 10(b). The description of Fig. 10(c) is the result of a focus of attention operation on the "dining-room" and "kitchen" attributes. The description contains the attributes that are arguments of the operation, and of the related rules. Attributes involved in the selected rules which are not arguments of the focus of attention are replaced by (dummy) variables (i.e. "?" symbol). Rule mapping consists (Fig. 11) of the assignment of attribute names to dummy variables. Usually, the number of solutions depends on the number of concepts involved (i.e. use of more concepts implies having a more constrained solution). In more depth, given two concepts, the rule-mapping algorithm searches for a concept that is subsumed by the given ones. If it finds such a concept, this can be used as a model for the context insertion. Otherwise, a new concept is created with the same attributes and rules. At this point a constraint-satisfaction problem must be solved, where the variables are the dummy attribute names, the values are the attribute fillers, and the constraints are the rules.

6. CONCLUSIONS

The aim of this work has been the investigation of some recent directions in intelligent design support. The paper has proposed a computational architecture with a cognitively plausible structure in order to obtain a human-computer interaction that is as flexible as possible. A great effort has


been sustained to investigate the suitability of the terminological paradigm to develop a case-based design-support system.

The use of a concept language for the description of domain knowledge naturally leads to the implementation of a distributed case representation. Cases in the ASA architecture are distributed as attributes, and induce attribu- tive/part-of relationships among concepts. Multiple conceptual representations naturally coexist in a single case. It is quite natural to extend the general knowledge memory configuration to long-term memory, so that every case-base table contains the structure of the related concept instances. This approach avoids the representational grain-size problem that affects systems using highly structured case representation. In a distributed system like ASA, the case is naturally represented at different grain sizes by different concepts. The subsumption procedure, applied to a search key, finds the most appropriate representation size according to what is explicitly asserted in the query. Furthermore, the whole case representation can be easily updated when new conceptual descriptions are introduced into the system. Current limitations in the case representation consist of the restriction of the representation to the domain knowledge. The extension of the ontology to causal relationships, case outcomes and more generally to other aspects of the design process is in progress. In particular, the introduction of a design process model will improve the performance of the system in the retrieval of useful cases. The present work also investigates the effects of using partial case descriptions as search keys. Using a terminological language, the user is neither constrained to a fixed structure, nor given complete freedom in the formulation of descriptions. A terminological language offers enough expressiveness to describe meaningful situations, and enough structure to perform inferences on descriptions (e.g. subsumption and concept instantiation). The knowledge structure can be used to enhance the flexibility of the search procedure, and to propose new searching schemata (i.e. case-base navigation). Thus the choice of the right knowledge structure is at least as important as the choice of the right index vocabulary and case content. Furthermore, the right knowledge structure can be used to overcome the index-assignment problem. Data-base systems have been extensively used in design problems (see, for example, Adeli and Yu, 1995). They use unstructured keys. A typical search is performed by logically composing expressions on key values and retriev- ing the data-base records which satisfy the query expression. Subsumption introduces the further possibility of composing search expressions using the same descriptive schema of stored knowledge, and using them to reason on the structure of data-base relations (i.e. searching or navigating by using structural key properties) besides reasoning on values. Adaptation is another aspect covered by this work. Once again, the capability of adapting is based on the precise structure imposed on the knowledge- representation schema. The internal concept structure can be viewed as a set of contextual relationships among the component concepts. Formation rules have been used,

firstly, to retrieve parts of cases conforming to the same rules, and then as guidelines for parts compositions. Thus, formation rules contain both interpretative knowledge for data classification and synthesis knowledge for solution generation.

This work has some limitations: for simplicity its scope has been circumscribed to domain representations (e.g. architectural domain objects, rooms, flats, etc.). In the future the application of the terminological language to design process and physical-causal model representations will be investigated. At present, the system has no strategy for limiting the number of retrieved cases during searches with quite general keys. Another limitation is that the adaptation procedure is restricted to a substitution strategy and to context insertion, without any case-transformation possibility.

ASA has been implemented in Allegro Common Lisp and Autocad, under MS Windows.

Acknowledgements--This work has been conducted as part of ASA, a project under development at the University of Ancona, and has been done with the support of the Italian National Research Council (CNR), Special Project on Building (Progetto Finalizzato Edilizia). Mario De Grassi and Mauro Di Manzo have supervised the project and provided many useful insights. Tonino Cerquoni, Andrea Fornarelli, Massimo Lemma, Berardo Naticchia, Antonio Pistoia, Michele Profeti, Graziano Tellenio and Gianluca Zitti have participated in the implementation of ASA.

REFERENCES

Adeli, H. and Hawkins, D. W. (1991) A hierarchical expert system for design of floors in highrise buildings. Computer and Structures 41(4), 773-788.

Adeli, H. and Yu, G. (1995) An integrated computing environment for solution of complex engineering problems using the object-oriented programming paradigm and a blackboard architecture. Computer and Structures 54(2), 225-265.

Aouad, G. E, Kirkham, J. A., Child, T., Cooper, G. S., Ford, S., Brandon, P. S., Brown, E E., Oxman, R. E. and Young, B. (1994) An object- oriented model of building procurement. Microcomputers in Civil Engineering 9(6), 401-411.

Barber, J., Bhatta, S., Goel, A., Jacobson, M., Pearce, M., Penberthy, L., Shankar, M., Simpson, R. and Stroulia, E. (1992) AskJef: integration of case-based reasoning and multimedia technologies for interface design support. Proceedings of Artificial Intelligence in Design '92, pp. 457-475. Kluwer Academic, Boston.

Berraris, A. and Watson, A. S. (1994) A knowledge-based design tool to assist in preliminary seismic design. Microcomputers in Civil Engineer- ing 9(3), 199-209.

Bhatta, S., Goel, A. and Prabhakar, S. (1994) Innovation in analogical design: a model-based approach. Proceedings of Artificial Intelligence in Design '94, pp. 57-73. Kluwer Academic, Boston.

Borgida, A. and Patel-Schneider, P. E (1994) A semantics and complete algorithm for subsumption in the CLASSIC description logic. Journal of Artificial Intelligence Research l, 277-308.

Brachman, R. J. and Schmolze, J. G. (1985) An overview of the KL-ONE knowledge representation system. Cognitive Science 9, 217-260.

Chandrasekaran, B. (1990) Design problem solving: a task analysis. AI Magazine 11(4), 59-71.

De Grassi, M., Giretti, L. and Spalazzi, L. (1996) Applying formal methods to case-based design aids. Proceedings of Artificial Intelligence in Design '96, pp. 191-210. K|uwer Academic, Boston.

Eastman, C. M. (1991) The evolution of CAD: integrating multiple representation. Building and Environment 26( 1 ), 17-23.

Gero, J. S. (1990) Design prototypes: a knowledge representation schema for design. AI Magazine 11(4), 26-36.

Gero, J. S. (1993) New knowledge-based CAD models of design. In Management of Information Technology for Construction, ed. K. S.


Mathur, M. E Betts and K. W. Tham, pp. 199-208. World Scientific, Singapore.

Giretti, L., Spalazzi, L. and Lemma, M. (1994) ASA: an interactive assistant to architectural design. Proceedings of Artificial Intelligence in Design '94, pp. 93-108. Kluwer Academic, Boston.

Giunchiglia, E, Spalazzi, L. and Traverso, E (1994) Planning with failure. In Proceedings of AIPS 94, Chicago, IL.

Goel, A. (1991) A model-based approach to case adaptation. Proceedings of the Thirteenth Annual Conference of the Cognitive Science Socie~, pp. 143-148. Chicago, IL.

Goel, A. and Chandrasekaran, B. (1992) Case-based design: a task analysis. In Artificial Intelligence Approaches to Engineering Design, Vol. II: Innovative Design, ed. C. Tong and D. Sriram, pp. 165-184. Academic Press, San Diego, CA.

Haber, D. and Karshenas, S. (1994) CONCEPTUAL: an expert system for conceptual structural design. Microcomputers in Civil Engineering 5(2), 119-127.

Hua, K., Smith, I., Faltings, B., Shih, S. and Schmitt, G. (1992) Adaptation of spatial design cases. Proceedings of Artificial Intelligence in Design '92, pp. 559-575. Kluwer Academic, Boston.

Kolodner, J. (1991 ) Improving human decision making through case-based decision aiding. AI Magazine 12(2), 52-68.

Kolodner J. (1993) Case Based Reasoning. Morgan Kaufmann, San Mateo, CA.

Light, R. and Gossard, D. (1982) Modification of geometric models through variational geometry. Computer-Aided Design 14(4), 00-00.

Maher, M. L., Balachandran, M. B. and Zhang, D. M. (1995) Case-Based Reasoning in Design. Lawrence Erlbaum, Mahwah, NJ.

Pearce, M., Goel, A., Kolodner, J., Zimring, C., Sentosa, L. and Billington, R. (1992) Case-based decision support: a case study in architectural design. IEEE Expert 7(5), 14-20.

Plaza, E. (1995) A feature term approach to the structured representation of cases. Proceedings of First International Conference on Case-Based Reasoning '95, pp. 265-276. Springer, Berlin.

Schaeff, A. (1994) Query answering in concept-based knowledge representation systems. Algorithms, complexity and semantics issues. Ph.D. thesis, Universith degli Studi di Roma "La Sapienza'.

Yu, G. and Adeli, H. (1991) Computer-aided design using object-oriented programming paradigm and blackboard architecture. Microcomputers in Civil Engineering 6(3), 177-190.

AUTHORS' BIOGRAPHIES

Alberto Giret t i received an M.S. in Electronic Engineering from the University of Ancona, Italy, in 1990. He received a Ph.D. in Artificial Intelligent Systems from the University of Ancona in 1995. Currently he is working with the Artificial Intelligence in Design Laboratory at IDAU--Univers i ty of Ancona. His present research interests include terminological languages, case-based reasoning and variational CAD. Luca Spalazzi received an M.S. in Electronic Engineering and a Ph.D. in Artificial Intelligent Systems from the University of Ancona, Italy, in 1989 and 1994 respectively. He is currently working at the Istituto di Informatica--University of Ancona. His present research includes situated planning, terminological languages and case-based reasoning.

Documents

ASA: A conceptual design-support system