Representing strategic design knowledge

Pergamon PH:S0952-1976(96)00038-3

EngngApplic. Artif. InrelL Vol. 9, No, 4, pp. 349-357, 1996 Copyright © 1996 Elsevier Science Ltd

Printed in Great Britain. All rights reserved 0952-1976/96 $15.00+0.00

Contributed Paper

Representing Strategic Design Knowledge K E L V I N C L I B B O N

Loughborough University, U.K.

E R N E S T E D M O N D S

Loughborough University, U.K.

(Received December 1995; in revised form May 1996)

This paper proposes a logic-based computational model to support design. The model incorporates a meta- level architecture to explicitly represent the declarative design knowledge and strategic knowledge used by the designer. It consists of an object layer, a design requirements layer and strategies for exploring the design space. Particular attention is paid to the representation of strategic knowledge and how to reason with it. An extended first-order logic is also described, which has been used to represent some vehicle packaging knowledge. This computational model is being implemented in KA US (Knowledge Acquisition and Utilization System)--a general-purpose knowledge-based system, founded on multi-layered logic. The domain of car design is being used to evaluate the proposed meta-level architecture as a means of providing logic based support for design. Copyright © 1996 Elsevier Science Ltd

Keywords: Strategic knowledge, multi-layered logic, computational models, KAUS.

1. INTRODUCTION

At its most general level, design is concerned with producing a description of an artefact or process that meets a given set of objectives or requirements. Knowledge-based approaches to design assume that it proceeds through the utilization of an organized body of a priori knowledge. This knowledge is used both to structure and understand the design problem, and to form the basis of the design hypothesis.' Design can be formalized as the creation of new structures in response to some functional requirements. In this sense, design is an activity to derive an object model, whose structure meets the design requirements. An object model must be a faithful representation of an object possessing structural information to represent functional- ities: that is, attributes, properties, behaviour and relations with other objects. The approach advocated in this paper is that design starts with a hypothetical model. If this object model does not meet the requirements, then it is modified accordingly.

Any given design process begins with a problem specification, from which a set of requirements is derived.

Correspondence should be sent to: Prof. Ernest A. Edmonds, LUTCHI Research Centre, Depmtn~nt of Computer Studies, Loughborough University, Loughborough LEll 3TU, U.K. Email: E.A.Edmonds@ lboro.ac.uk.

This set of requirements is not usually well defined at the beginning of the design process, and does not remain static during it. For example, when designing a new car the initial requirements might be for a car that is low in price, reliable and economical. These ambiguous requirements will evolve as design decisions are made; such as to produce a new engine by modifying an existing economic low-priced one.

From an AI perspective, design can be considered to be the process of identifying problems, specifying functionality and generating appropriate solutions; with the support of some basic building blocks. In this research the object model is a declarative representation of the real object. It is not static. Design is a dynamic activity to find this model. It is also a non-deterministic activity, in the sense that there are an infinite number of possible structures that an object model can be. This paper stresses the importance of an explicit representation of the designer's knowledge, in order to support exploration of the design space. The major contribution of this paper is a declarative knowledge-based recta-level architecture, for the explicit representation of both domain design knowledge and design strategies.

The issues discussed in this paper are illustrated with reference to the domain of car design. The knowledge used forms part of the Vehicle Packager Knowledge Support System (VPKSS) developed at the LUTCHI Research Centre. Vehicle packaging is an approach to whole vehicle

349

350 KELVIN CLIBBON and ERNEST EDMONDS: REPRESENTING STRATEGIC DESIGN KNOWLEDGE

design, that incorporates a representation of the key sub- systems such as engine bay, passenger cell and boot compartment. For a discussion on vehicle packaging generally and a description of the VPKSS, see Ref. 2.

2. REPRESENTING DESIGN KNOWLEDGE

The major problem with building a knowledge base to solve aspects of a design problem is in finding the most effective representation for the knowledge. 3 Although AI techniques provide a means to develop computational processes which are informed by the designer's behaviour, they do not necessarily model it. In addition, because design domain knowledge is usually unbounded, it is particularly difficult to build a comprehensive and complete computational model of the domain beforehand. This section discusses knowledge-based terminology, paying particular attention to knowledge levels, and to the distinction between domain and design knowledge.

A knowledge base usually consists of conceptual, procedural and declarative knowledge. Conceptual knowledge is concerned with underlying ideas, theories, concepts, hypotheses, and relationships that exist within a domain. Declarative knowledge consists of the truths of a domain, and includes facts, terminology and classifications. Proce- dural knowledge refers to knowledge used to direct pathways of thought or actions, leading to solutions to problems that the system is trying to solve. Procedural knowledge is largely concerned with the manipulation of declarative or conceptual knowledge. This type of knowledge consists of rules-of-thumb and their control, weights of evidence, working procedures and strategies.

2.1. Knowledge levels

Within any domain, there are different levels of knowledge. A deep knowledge-based system uses representations of knowledge that are more sophisticated than simple heuristic rules. 4 Shallow systems consist of simple knowledge bases of procedures, linked by an overall strategy. A deep knowledge base consists of more-complex knowledge, such as the internal and causal structures of the system, and the relationships and interactions between the underlying components. Deep knowledge makes explicit the models of the domain and the inference mechanisms that operate over these models. 5 It tends to be implicit in shallow structures (see below), meaning that it is usually unavailable in the reasoning process. A deep system is one that contains an active representation (i.e. one that is available for computa- tion and manipulation) of the components and processes within a domain. Bylander 6 notes that there are two aspects to deep knowledge, that of the representation scheme, and that of the reasoning method.

Shallow systems are geared to problem solving, and rely on facts and rules. Facts are statements which assert a definite or predictable occurrence in any domain. Rules are statements that express relationships. They can be causal, a statement of an expert's procedure, or an overall strategy. Rules can also have probabilities or certainty factors

attached (i.e. weights of evidence). Deep systems, on the other hand, are concerned with

models of reality, and consist of causal knowledge, conceptual structures and classificatory knowledge. Causal knowledge is concerned with statements or representations that express the relationships between objects in a domain, and how and why they interact. Conceptual structures are the underlying relationships, representations and beliefs, inherent within a domain. Finally, classificatory knowledge is the ordering of the objects of the domain into hierarchies.

2.2. Domain vs design knowledge

Logan and Smithers j distinguish domain knowledge from design knowledge. Domain knowledge portrays the characteristics of the domain: the nature of the physical reality, the materials and techniques available to the designer, legis- lative controls, codes of practice and other standards that are largely invariant across designs (and designers) within a domain. Domain knowledge expresses facts about the domain and the properties, and attributes of basic objects and processes associated with it. This knowledge ultimately constrains the form of any design. It defines the boundaries for the space for possible designs, giving structure to the exploration space, and thus the problem.

Design knowledge is knowledge about how the space can be explored. It is derived from previous designs, and is concerned with how domain knowledge is used to define and solve design problems; how the space of possible designs is explored, giving an indication of the paths through the design space; and how a developing design problem structure is created, modified and refined. Design knowledge includes useful decomposition criteria and strategies, synthesis and analysis methods, and techniques for validating and documenting the design as it evolves.

A declarative representation scheme for domain and design knowledge is required. Declarative domain knowledge will support inferencing, and a declarative representation of design knowledge will support the designer in exploring the space of possible designs. Domain and design knowledge, however, are not orthogonal. There is often an important dependency relationship between the two, which means that one cannot sensibly be expressed without reference to the other. ~

3. COMPUTATIONAL MODELS OF DESIGN

Computational models of design can play an effective role in the division of labour within human-machine design systems. The designer can be supported in the formulation of problems and the exploration of the solution space] Computational systems can be discussed in terms of routine and non-routine design, in terms of the notion of exploring the solution space, as opposed to merely searching it, and from the perspective of cognitive models.

3.1. Routine and non-routine design

Gero 8 distinguishes two classes of design: routine design and non-routine design. Routine design, in computational

KELVIN CLIBBON and ERNEST EDMONDS: REPRESENTING STRATEGIC DESIGN KNOWLEDGE 351

terms, can be defined as that activity which occurs when all the necessary knowledge is known in advance, and proceeds within a well-defined space. All the design variables and their possible ranges are known, and the problem is one of instantiation.

With non-routine design, not all the variables which define the structure and the behaviour of the solution space are known in advance. Neither are all the design processes necessary to solve the design problem. Non-routine design focuses on processes for the introduction of new variables into the design, and their integration into the existing variable structure.

3.2. Searching vs exploring the design state space

Smithers et al . 9 view design as a knowledge-based exploration task, which starts with an initial set of requirements. A search problem is a triple consisting of: an initial problem description; a set of operators for transform- ing problems into subproblems (design decomposition); and a set of primitive problem descriptions, t° This type of problem solving corresponds to routine design. Exploration in design, by comparison, creates new design spaces, or modifies existing ones.

Search as design requires that the behaviour and structure state spaces be well defined. All the states need to be specifiable in advance. "Structure" is comprised of the components and their relationships which go to make up the designed artefact. 8 "Behaviour" describes what the product does, as opposed to "function", which is what the product is for."

Much of the current design research is focused on representations and processes founded on the design-as- search paradigm. The search for values of predefined variables forms the basis of routine computational models of design. By comparison, exploration as a computational process creates new, or modifies existing, state spaces.

3.3. Cognitive models and design

Designers use various cognitive devices. These devices include: abstraction mechanisms for generalization and task decomposition; heuristics, analogies, and metaphors to provide alternative formulations; and learning and knowledge compilation, to evolve and improve the quality and efficiency of the design process. 7

Computational models have been developed that reflect these cognitive devices. Cognitive models of the design process either model the problem-solving process in terms of design operators, heuristics and the problem space, or attempt to characterize generic aspects of design tasks. Computational models have been used to structure the design process as a top-down decomposition of the design problem. Although these models are explicit to the designer, systems based on this approach are limited to capturing routine design.

4. STRATEGIC KNOWLEDGE

Domain knowledge represents the characteristics of the domain in question, and defines the design space. Design

knowledge, by comparison, represents strategies for searching and exploring this space. This research is partially concerned with establishing the relationship between substantive knowledge as domain knowledge, and strategic knowledge as design knowledge. Within this context, strategic and substantive knowledge are now discussed.

Strategic knowledge is concerned with the control decisions made during the design phase, as the object model evolves. From a non-epistemological perspective knowledge is information that can be used to perform some intelligent task. Strategic knowledge is knowledge used by an agent to decide what actions to perform next, where actions have consequences that are external to the agent, t2 Strategic knowledge has more recently been defined as the knowledge used for deciding the course of action when there are conflicting c r i t e r i a . 13 At a high level of abstraction, strategic knowledge is concerned with knowledge about the approach or problem-solving method to be used. At a lower level, strategic knowledge might be concerned with the decisions necessary for a single action, t4 Strategic knowledge is used by the designer to decide what actions to perform in a given situation, where actions are considered to have observable consequences.

Strategic knowledge is distinguished from substantive knowledge of a domain, i.e. knowledge about what is believed to be true in the world. Both substantive and strategic knowledge underlie expertise in many domains. For example, a robot uses substantive knowledge to recognize and interpret situations in the world (an obstacle in its path), and strategic knowledge to decide what to do (to go round or over, etc.). In general, substantive knowledge is used to identify relevant states of the world, and strategic knowledge is used to evaluate the utility of possible actions, given a state.

Substantive knowledge is represented explicitly in knowledge bases. Strategic knowledge can be represented both implicidy and explicitly. Implicit behaviour has been achieved using implementation-level primitives such as numeric priorities. MYCIN's certain factors are an example of implicit strategic knowledge, t5 A more explicit representation of strategic knowledge is achieved via control blocks, which are sequential procedures attached to rules. BBI's blackboard architecture is an example of explicit strategic knowledge, t6 A key research issue is how can strategic knowledge be represented, and what kinds of strategic reasoning can be expressed during the design process?

Knowledge systems make control decisions at the implementation level. One such decision is conflict resolution, where the choice of which rule(s) to fire from a competing set is made. Strategic knowledge, by comparison, is defined at the knowledge level in terms of the effects on the observable behaviour of the agent. This occurs without reference to the internal symbolic-level organiza- tion of the knowledge system, t2 Substantive knowledge is used to derive or model the domain of endeavour. It classifies entities in the knowledge base in terms of the relationships, attributes and functions between them. The


procedure for deciding what to do when operating on the entities in the domain is strategy. This distinction between strategy and substantive knowledge is not the same as the difference between procedural and declarative knowledge representation, which is a symbolic-level distinction.

Models of design generally fail to be explicit about the kinds of control strategy required to consistently assign values to design variables. A knowledge-based architecture is required to model the process aspects of design, together with the necessary strategic knowledge. The dynamic aspects of the design process (i.e. those concerned with control and revision), will also need to be supported by this architecture.

4.1. Representing strategic knowledge The most straightforward method of representing strate-

gic knowledge is through the use of a procedural formulation. A procedural representation of a strategy specifies the sequence of steps that the system should take. For instance, a procedure might take the form, "do action A then B, then if condition X is true do action C, else do action D".

Strategies have been encoded as procedures in programming languages, such as Lisp. In some rule-based systems, for example that of Cooper and Wogrin, n7 task variables serve as control markers in the rule language, which direct the rule interpreter to execute modular sets of rules as subroutines. S l,~S for example, integrates procedural control in its representation language as "control blocks", which invoke rules.

Although procedural formulations of control can imple- ment a strategy, they represent it implicitly. The strategic knowledge that underlies the specific sequence of actions is hidden in the procedural representation, which specifies what to do as a procedure, but not why. Such representations are inadequate for representing the reasons underlying a strategy.

Metarules guide the use of knowledge, and decide what rules and methods are to be applied. There are essentially two types of metarules. Pruning metarules exclude particular rules from consideration. In terms of the goal tree, this amounts to a decision not to explore a given branch, and constitutes a judgement on the overall utility of a rule, as to whether it is of any use in a specific context. The other type of metarule encodes knowledge on the relative importance of rules. At the implementation level the metarule acts to reorder rules relevant to some goal before involving them. In rule-based systems the order in which rules appear in the knowledge base influences the inferencing process. Meta- rules that reorder amount to a less drastic decision as regards the goal tree. The branches are restructured rather than pruned. The seminal work on the explicit representation of control knowledge metarules was carried out in the MYCIN experiments ~5 and by Clancy. tg"z°

4.2. Strategic support for design The use of metarules to represent strategic knowledge is

not restricted to one level of metaknowledge, but can be

extended to indefinite levels. In addition, the inference engine used is still simple. Meta-level rules can select different types of inference mechanisms (such as forward- or backward-chaining) at appropriate points in the search process. The purpose of representing strategic knowledge with metarules is to tell the system which part of its substantial knowledge to apply in a given situation.

Research reported elsewhere, 21 has highlighted the need for support during design. The requirements are for support during knowledge exploration and in evaluating the object model. Knowledge used in the act of designing is dynamic, and in order to apply it effectively it must be evaluated during the process. At the same time, however, if the design is specified too strictly, then the freedom of the model- building activity is restricted, and there is no room for innovation. There is a trade-off between the freedom and the efficiency of design.

Strategic knowledge is used by the designer to identify and formulate the design problem. Having established the requirements, the designer will require strategic support to explore the design, particularly as new concepts emerge. This research is concerned with logic-based support, providing tools to guide the designer through iterative model building, model analysis, model evaluation and model modification. It is hypothesized that in having a sound theoretical logic-based foundation, support systems can check for consistency and correctness in the knowledge- base during model building.

5. A LOGIC-BASED ARCHITECTURE

The logic-based architecture proposed in this paper utilizes layers which consist of nodes. Nodes in the object layer contain descriptions of object models. Nodes in the requirements layer consist of sets of requirements for these objects. Interactions between the two layers can be represented by links. Strategies are needed to support exploration within and between the object and requirements spaces.

5.1. The MULTIK model

Researchers on the MULTIK (Multi-Layered Knowl- edge-Based Interfaces for Professional Users) project are developing a logic-based architecture, in order to support design. A declarative representation of the object model is represented independently from a declarative representation of the requirements. Links between nodes in the layers represent which set of requirements is related to which object model. Static aspects of the design are concerned with the object model and requirements domain knowledge. The strategic knowledge relating to the steps to be taken during the design process are the dynamic aspects. A meta- level architecture facilitates the representation of both the static and dynamic aspects of the design process. Strategic knowledge is necessary to determine in which layer the next step of the design process is to be made. It is necessary to perform object-level reasoning, with knowledge in the object level, as well as meta-level reasoning, about the

KELVIN CLIBBON and ERNEST EDMONDS: REPRESENTING STRATEGIC DESIGN KNOWLEDGE 353

knowledge in the object level. The meta-level architecture is depicted in Fig. 1.

5.2. Multi-layered logic

A multi-layered logic" knowledge representation formalism, capable of automatic consistency checking, representing complexity and dynamic model building, has been used to model vehicle packaging knowledge. It is based on the concept of hierarchical data abstraction, and is an extension to first-order logic (FOL), with data structuring capabilities. A data structure---human-specified or automat- ically generated is defined as a set based on ZF (Zermelo-Frankel) set theory.

MLL increases the declarative power of FOL. Although FOL is expensive in the sense that its notions of quantification and negation are not easy to represent unambiguously in network and structured data form, FOL is criticized for not being,expressive enough. In FOL every entity is taken into account when determining the truth value of a universally quantified formula. An MLL formula contains a restricted quantifier, which ranges over a sub-set of the domain of the relational structure. Restricted quantification improves efficiency and increases the declarative expressive power of the representation.

MLL has a set of primitive constructs including "element-of", "component-of", "power-set-of", "product- set-of", "union-of", "intersection-of" and "pair-of" relations, which are used to represent the object model and its requirements. These data structures can be included as terms in predicates, and are defined mathematically in terms of primitive structures according to composition rules. For example, the symbol * represents the power set operator, where *D means the set of subsets of D (excluding the

empty set). The syntax of MLL predicates has been expanded from

FOL to include a domain of each variable explicitly in the prefixes. For example (Vx/new_car)expensive(x) is the same as the first-order expression Vx(new_car(x)---.expensive(x)). Both mean newcar is expensive, but in the former expression, new_car denotes a set of new cars. To accommodate the modified syntax, an ordinary inference algorithm (resolution) has been modified in order to check for equality between data-structures--see Ref. 23 for details.

An MLL predicate can also include closed formulae, that is formulae without any free variables as the term. For example in the following (Vx lD)P( . . . , x . . . . . (Vx/C) R(...,x .... )) the evaluation of the inner predicate R can be performed independently from that of the outer predicate P. In terms of the model, the set of predicates that do not contain any predicates as terms, are located in the object level, while those that contain object-level predicate(s) as the terms(s), belong in the level above the object level, i.e. the meta-level.

6. A CASE STUDY

A working prototype version of the MLL Vehicle Packaging model is being developed in KAUS (Knowledge Acquisition and Utilization System). MLL rules are indexed and partitioned into several sets (worlds). It is possible to have independent local worlds to form separate knowledge sources. KAUS utilizes built-in predicates, called procedural type atoms (PTAs), to specify and change the worlds used during the inferencing process. A meta-level inferencing process can get information from the object level. Hence inferencing in one level is defined in the next highest

I~t Strategies ,.~1 i-,~ wv I

i S

Requirements Layer

no~e / CeUq:erntents

Object-Layer

Fig. I. A meta-level architecture for representing strategic design knowledge.


level. For further details on MLL and KAUS refer to Refs 22 and 24.

This section serves to demonstrate the MLL foundations of KAUS: its declarative power, in terms of object and requirement level hierarchies, and its meta-level capabilities. The vehicle packaging examples serve to illustrate the major substantive and strategic aspects of design. They are not, however, exhaustive. Some of the strategic search and exploration issues discussed above are not illustrated.

6.1. KAUS

KAUS is based on many sorted logic, where sort hierarchies are described in terms of set relationships, in which each set represents the sort of a set of entities. For example, the sort "cars" represents the set of cars, while "sports cars" and "family car" can be thought of as subsets of the set "cars"---the subsorts of the sort cars. So if a Lotus Esprit is designated as a sports car and a Vauxhall Cavalier as a family car, then the Lotus Esprit and Vauxhall Cavalier are members of the sorts sports car and family car, respectively.

The clausal representations of rules and facts in KAUS are arbitrary AND-OR logical formulas. A KAUS clause has a prefix in which the quantification and type declaration of variables appearing in the clause may be explicitly described. For example, a sentence "If a person Z is a parent of a male X and Y, and X is not equal to Y, then X is brother of Y" is represented in KAUS as follows:

[AX, Y/male ][AZ/person](l(brother X Y ) - (parent X Z)

- (pa ren t Y Z ) - ( $ n e X Y)).

[AX, Ylmale][AZ/person] is the prefix part of the clause. This can be read as "for all X and Y of type male and for all Z of type person". (l(brother X Y ) - (parent X Z) -pa ren t Y Z)~($ne X Y)) represents an OR formula which is logically equivalent to "(parent X Z)A(parent Y Z) A($ne X Y)---*(brother X Y)". I denotes the or-connective, ~ is the logical negation symbol and A represents the

logical symbol V.

KAUS has the expressive power to describe rules concerning sets. The domain of each variable is given explicitly in the prefix. Consider the following examples:

All cars have a passenger cell. Sports cars and family cars are types of cars. Cars are a subset of vehicles.

These can be expressed in KAUS as follows:

[AX/cars](have(Xpassenger-cell)). !ins_e cars sportsCar familyCar. !ins_e *vehicle cars.

In the above "cars" refers to the set of cars. Symbols beginning with capital letters relate to variables, and those beginning with lower-case letters represent predicates or basic objects. !ins_e defines the component_of relation. *vehicle denotes the power set of the set "vehicle". The first example is a predicate sentence (a rule). The second and third examples express relations between sets and objects.

In KAUS it is possible to define type hierarchies, which can be interpreted semantically as a representation of ISA structures of objects and PART-WHOLE structures of objects. For instance, cars can be classified into sports cars and family cars, and so on. In addition, cars are composed of engine bays, passenger cells and boots. The ISA and PART-WHOLE hierarchies are described in terms of set theory relationships among objects. The description of ISA and PART-WHOLE hierarchies of objects can be classified into two classes. One is concerned with the hierarchies of objects (in the object level), and another with hierarchies of objects in the meta-level. Objects in the meta-level are program clauses. Hierarchies in the meta-level describe the classification of program clauses. Figure 2 is an example description of part of an object level hierarchy for the car domain.

Note that al through to a4 describe hierarchies of generic objects. The statement a5 describes two instances of sportsCar, and a6 to al0 describe the specific PART-

al). !ins_e *model

a2). Tins e *car

a3). Tins_e *carParts

a4). Tins_e *passengerCell

a5). Tins_e *sportsCar

a6). Tins-e lotusEsprit:engineBay

a7). Tins_e lotusEsprit:boot

aS). Tins_e lotusEsprit:passengerCell

a9). tins_e IotusEsprit_passengerCell:frontPassenger

a 10). fins__e lotusEsprit_passengerCell:rearPassenger

car, plane, boat;

sportsCar, familyCar;

enginBay, boot, passengerCell;

frontPassenger, rearPassenger;

lotusEsprit, jaguarXJS

lotusEsprit_enginBay;

IotusEsprit_boot;

IotusEsprit_.passengerCell;

IotusEsprit fi'ontPassenger;

lotusEsprit_rearPassenger;

Fig. 2. An object-level hierarchy for the car domain.

KELVIN CLIBBON and ERNEST EDMONDS: REPRESENTING STRATEGIC DESIGN KNOWLEDGE

ruleSet

ruleEval ruleModify

evalEnginBay evalBoot evalPassengerCell modifyEnginBay modifyBoot modifyPassengerCell

Fig. 3. A hierarchy of objects in the meta-level.

355

WHOLE structure for the lotusEsprit. For example, in al, car plane and boat are described as subtypes of a supertype model. In a2, sportsCar and familyCar are defined as subtypes of a supertype cars, and so on. Figure 3 gives an example description of a hierarchy of objects in the meta- level.

The example above aims to classify car design rules into evaluation rules and modification rules. The evaluation and modification rules are classified into three rule sets with respect to the objects in the engine bay, boot and passenger cell. If, for example, the objects in the passenger cell were modified, then they will be so according to the associated modification rules, and evaluated according to rules on style (i.e. rules associated with comfort requirements for the passengers).

6.2. Reasoning with strategic knowledge Program clauses in KAUS can be classified according to

their utility, availability and relevance to specific domain tasks. This results in a hierarchical categorization of program clauses. A set of clauses that belong to a particular category in the hierarchy may be regarded as a description of a certain inference world. These inference worlds constitute strategies used by the designer during design. In terms of KAUS, strategic clauses can be built to change the current inference world. For example, with sports cars the emphasis during design is on the engine bay. Comfort in the passenger cell receives a lower priority, than when designing a family car. Most sports cars do not cater for rear passengers at all, or put their comfort at a low priority. Consider the passenger cell shown in Fig. 4.

The designer of a family car passenger cell will normally attempt to make the rear occupants as large as possible. The angles of the seats and lengths of the rear occupants' thigh and shin will be crucial. To illustrate how metarules can be

Front Passenger Rear Passenger

Shin Fig. 4. A typical passenger cell.

used to represent the designer's strategies for changing inference worlds, imagine that the designer is manipulating the rear passenger objects, by removing them or changing their shin and thigh lengths (from a set of upper and lower values). The underlying MLL KAUS representation is given in Fig. 5.

Metarules ml-m6 describe what is known (metaknowledge about the facts). For example, ml describes that the numberRearSeats for a sports car can be found from f4 (fact 4). The metarule m7 is a generic rule to derive what the object model looks like, given the rules rl and r2, facts fl to f6, and metarules ml-m6. Metarule m7 has a conditional ($scopkeKUs [X]), which restricts the clauses available to ($caU Predicate) to those known by Fact. With this setting, if the knowledge base is queried to find out what type of car (sports or family) the design tends to, i.e. (believe(X Design))?, X will be instantiated to aSportsCar. If the design requirements were for a family car, the designer could be prompted to change the number of rear passengers and leg measurements accordingly.

In the examples above, the object level hierarchy represented in Fig. 2 is typical of some substantive knowledge in a node of the object layer in Fig. 1. The same representation is used for nodal knowledge in the requirements layer. The hierarchy of meta-level objects in Fig. 3 would be used by the system to support the designer in exploring the design space. Metarule m7, in Fig. 5, is an example of some strategic reasoning on behalf of the requirements layer, where by the leading object-layer model (node) of Fig. 1 is checked for consistency against the leading requirements-layer node.

6.3. Logic-based support for design In terms of the proposed logic-based architecture,

strategic knowledge is concerned with how best to determine the next step or action to be taken by the designer, during the design process. This might amount to a set of rules or heuristics, used by the designer in certain situations. For example, if the object layer is densely populated with object models that fit the latest set of requirements, how can the designer be supported in exploring the object space and in making decisions on which object models to include in a candidate set? Search-control knowledge could be used to constrain browsing to those areas of the object layer that are likely to contain the best solutions.

MLL provides the means to explicitly represent strategic design knowledge. A design support system should actively assist the designer in exploring the design state space,


rl :(]asportsCar DesignlS)

r2:(lafamilyCar Designls)

fl :(numberRearSeats 2). ] f2: (rear_passenger_ShinLength 470). f3: (rear_passenger_ThighLength 447). J f4:(numberRearSeats _). ] f5: (rear__passenger_ShinLength 365). t f6: (rear passenger_ThighLength 344). J m 1 :(know numberRearSeats { h- 1,~f4 } ). m2:(know numberRearSeats {hr2,Lfl }). m3 :(know rear_passenger_shinLengt h { ~r 1,W3 }). m4:(know rear_passenger_shinLength {W2,W2 } ). m5:(know rear__passenger_thighLength {~r 1,kflS}). m6:(know rear_passenger_thighLength {kr'2,L¢3 }). m7:([APredieate/tuple]([, believe Predicate)

~(rear_passenger_shinLength ShinLength), --(rear_passenger_thighlength ThighLength)). --(numberRearSeats Number), ~(rear_passenger_shinLength ShinLength), drear__passenger thighlength ThighLength)).

rear occupants have plenty of leg room.

rear occupants have limited leg room.

"(knOW Fact) ~($seopeKUs [Fact] ~$eall Predicate)).

Fig. 5. MLL KAUS representation of some passenger cell knowledge.

throughout the design process. The system should also provide support for context-specific inference based on the design decisions, constraints, and the requirements defining the design problem; together with physical laws, heuristics and other domain knowledge relating to the parameters of the design. 9

In terms of the proposed logic-based architecture, multi- layered logic can be used to support the designer; in identifying problems; in specifying the functionality of the objects in the object model, in terms of their attributes, properties and behaviour; and in generating solutions where appropriate. Multi-layered logic forms the basic building blocks of the design process. It is natural formalism for representing computational design models. Inferencing across the model can be used to search for the values of the predefined variables of the objects in the object model. An explicit multi-layered representation of the designer's strategic knowledge extends the computational process to the exploration of the design space, thus making it possible to create new, or modify existing, state spaces.

7. DISCUSSION

A concern with meta-level models is that effective computational models of a complex task will have to cope with the problem of organizing and effectively applying large amounts of knowledge. Therefore, problems of knowledge acquisition, representation, and retrieval in knowledge-based systems still pose major challenges, if computational systems are to obtain an autonomous capability for design. 7

With meta-level structuring, the compuatational system will perform in a less primitive and more sophisticated way, but the underlying model tends to be less clear, especially when dependent on domain-specific meta-level concerns. Implicitly, meta-level models are based on the hope that a

limited number of domain-independent meta-levels with corresponding inferencing strategies and knowledge will be discovered.

The problem of control in reasoning is fundamental to all cognitive processes, and therefore a key issue in designing a knowledge-based system. The knowledge-based system decides what problems to solve, what knowledge to use, and which problem-solving methods and strategies to apply. Rosenman and Gero ~ argue that systems based on abduc- tive rules (i.e. where inferencing tries to identify conditions where deduction and induction will start) are too inflexible to support design. Their emphasis is on selecting the correct knowledge representation for the computational model to support design.

This research advocates access to that knowledge by the designer. Designers are provided with the capability to explore and expand the design space. Support for design in terms of multi-layered logic involves the addition of new variables and changes to the rules that govern the design process, both within and between the object and requirements layers. Exploration would be supported if the underlying relationships between domain/design knowledge and substantive/strategic knowledge are explicitly represented in a computational model of design.

Representing domain knowledge with multi-layered logic will facilitate inferencing across the design space. Repre- senting design knowledge with multi-layered logic will support the designer in exploring the design space. Design, in terms of the computational introduction of new objects into the object model, will be enhanced in using multi- layered logic to distinguish between domain-specific knowledge and design knowledge, on how best to explore the design space.

An explicit multi-layered representation of the designer's strategic knowledge will help the exploration of the design space, particularly in terms of the control decisions that

KELVIN CLIBBON and ERNEST EDMONDS: REPRESENTING STRATEGIC DESIGN K N O W L E D G E 357

have to be made as the object model evolves. The intention is to give the designer the freedom to explore a multi- layered representation of the design space.

8. CONCLUSION

A logic-based framework for design has been proposed, which incorporates a meta-level architecture to explicitly represent both domain design knowledge and design strategies. The KAUS logic programming language has been described with reference to illustrative vehicle packaging knowledge. The MLL which underpins this language has been proposed as a suitable formalism for representing the object model, the design requirements and the strategic knowledge used by the designer. It has been stated that a research framework is required to address the issue of providing computer-based support for design. This framework should take into account the designer-computer interaction issues, as well as those issues pertaining to the underlying knowledge representation of the design process. In particular, it is suggested that interaction with strategic design knowledge is important in supporting the design process.

Admowledgements--An earlier version of this paper was presented at the Third International Conference on Computational Models of Creative Design, at Heron Island in December 1995. Thanks to David Patrick and Linda Candy for their contributions to the work that led to this paper. The work was partly funded by the EPSRC, by the research grant GR/ J411405.

REFERENCES

I. Logan B. and Smitbers T. Creativity and design as exploration. Modelling Creativity and Knowledge-Based Creative Design (Edited by Gero J. and Maher M.), pp. 13q-- 175. Lawrance Erlbaum Associates (1993).

2. Candy L., Edmonds E. and Patrick D. Interactive knowledge support to conceptual design. AI System Support for Conceptual Design, Proc. 1995 Lancaster Int. Workshop on Engineering Design--LlWED "95, University of Lancaster, pp. 261)-278. Springer, London (1995).

3. Maher M. The importance of representation in AI in design. Research Directions for Artificial Intelligence in Design (Edited by Gern J. and Maher M.), pp. 49-54. Key Centre of Design Computing, University of Sydney (1995).

4. Bramer M. Expert systems: where are we and where are we going.

Expert Systems: Principles and Case Studies (Edited by Forsyth R.), 2nd Edn, pp. 31-56. Chapman & Hall (1989).

5. Steels L. Components of expertise. AI Mag. 11(2), 28-49 (1990). 6. Bylander T. Some causal models are deeper than others. Artif. lntell.

Med. 2(3), 23-128 (1990). 7. Coyne R. and Subrahmanian E. Computer supported creative design:

a pragmatic approach. Modelling Creativity and Knowledge-Based Creative Design (Edited by Gero J. and Maher M.), pp. 295-327. Lawrance Erlbaum Associates (1993).

8. Gem J. Introduction: creativity and design. Artificial Intelligence and Creativity (Edited by Dartnall T.), pp. 259-267. Kluwer (1994).

9. Smithers T., Conkie A., Doheny J., Logan B., MiUington K. and Tang M. Design as intelligent behaviour: an AI in design research programme. Department of AI Research Paper, Number 426 (1989).

10. Barr A. and Feigenbaum E. (Eds) The Handbook of Artificial Intelligence, Vol. 1. Kaufman (1982).

11. Rosenman M. and Gero J. Creativity in design using a design prototype approach. Modeling Creativity and Knowledge-Based Crea- tive Design (Edited by Gero J. and Naher M.), pp. 111-138. Lawrance Erlbaum Associates (1993).

12. Gruber T. Automated knowledge acquisition for strategic knowledge. Machine Learning 4(3-4), 293-336 (1989).

13. Tunez S., Bosch B., Bienvenido F., Marin R., Soria., Canabate F. and Mira J. Strategic knowledge in an expert system for agriculture. Cybernetics and Systems 23(3-4), 401-415 (1992).

14. Al-Dhaher K. and Harandi M. Representation of strategic knowledge. Proc. Industrial and Engineering Applications of AI and Etpert Systems Conf. 1991, Vol. 2, pp. 482-490 (1991).

15. Buchanan B. and Shortliffe E. Rule-Based Expert Systems: The MYCIN Experiments of the Stanford Heurisitc Programming Project. Addison-Wesley (1984).

16. Hayes-Roth B. A blackboard architecture for control. Artif. IntelL 26(3), 251-321.

17. Cooper T. and Wogrin N. Rule-Based Programming with OPS5. Morgan Kaufmann, Los Altos (1988).

18. Erman L., Scott A. and London P. Separating and integrating control in a rule-based tool. Proc. IEEE Workshop on Principles of Knowledge- Based Systems, pp. 37-43 (1984).

19. Clancy W. The epistemology of a rule-based expert system--a framework for explanation. Artif. Intell. 20(3), 215-251 (1983).

20. Claney W. From GUIDON to NEOMYCIN and HERCULES in twenty short lessons: ORN Final Report 1979-1985. A! Mag. 7(3), 40--60 (1986).

21. Candy L. and Edmonds E. Artefacts and the designer's process: implications for computer support to design. Revue Science et Techniques de la Conception 3( I ), 11-31 (1994).

22. Ohsuga S. and Yamauchi H. Multi-layer Iogic--a predicate logic including data structure as knowledge representation language. New Generation Computing, Special Issue on Knowledge Representation, 4, 403-439 (1985).

23. Ohsuga S. A new method of model description---use of knowledge base and inference. CAD System Framework (Edited by Bo K. and Lillehagen E), pp. 285-312. North-Holland, Amsterdam (1983).

24. Ohsuga S. A framework of knowledge based systems--multiple recta- level architecture for representing problems and problem-solving processes. Knowledge Based Systems 39(4), 204-214 (1990).

Documents

Representing strategic design knowledge