Artificial Intelligence and Design Automation Systems

This article was downloaded by: ["Queen's University Libraries, Kingston"]On: 08 October 2014, At: 12:43Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

Journal of Engineering DesignPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/cjen20

Artificial Intelligence and Design Automation SystemsG. N. BLOUNT a & S. CLARKE ba Design Division, School of Engineering , Coventry University , Coventry, UKb Garfield Engineering Ltd , Wolverhampton, UKPublished online: 25 Apr 2007.

To cite this article: G. N. BLOUNT & S. CLARKE (1994) Artificial Intelligence and Design Automation Systems, Journal ofEngineering Design, 5:4, 299-314, DOI: 10.1080/09544829408907891

To link to this article: http://dx.doi.org/10.1080/09544829408907891

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/cjen20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/09544829408907891

http://dx.doi.org/10.1080/09544829408907891

http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/page/terms-and-conditions

Journal of Engineering Design, Vol. 5, No. 4, 1994

Artificial Intelligence and Design Automation Systems

G. N. BLOUNT & S. CLARKE

SUMMARY This paper discusses an approach to programming computers to expand their use within the &sign function, using anificial intelligence (AI) techniques. The &sign process is discussed, along with the type of problems encountered and the atm'butes required of the designer for the solution of such problems. AI programming techniques are introduced as an extension to the field of computer-aided design (CAD) and the case for automatic design is presented. The design process is considered in terms of the theoretical model which is used as a basis for programming automatic design systems. A simple demonstration of the approach is given in the form of the selection of a solution principle for a pump problem and the development of that solution into a functional unit by design rules. A central theme of the method is the iterative use of the model, illustrating the concept at all levels of design decision-making.

1. Introduction

Design is one of the most important but (perhaps) least understood and, therefore, least structured functions in indusuy. The designer is given an open-ended problem with no unique goal state and relatively unconstrained means of obtaining a solution. It is a Function on the critical path of most engineering companies and, as such, is vital to their operation. In the ever-present drive for improvement, in attempts to structure and increase the efficiency of design work, design methodologists have attempted to bring order to the task, using techniques from management science.

Computers have also been introduced as designers' graphics and analysis tools, often in an attempt to increase efficiency. However, it appears that conventional computer-aided design (CAD) techniques are reaching the limit of their potential, and that new methods must be sought to achieve further increases in design efficiency. Computers have appropriately been applied in a fragmented fashion, by their specific application to particular problems, although integration is an increasing and necessary occurrence, along with technological and working practice advances.

Artificial intelligence (AI) computing techniques offer the potential for CAD to see expanded applications, and bring increases in efficiency and design confidence. A1 draws on techniques developed by cognitive psychologists to mimic the thought processes of humans, producing apparently intelligent behaviour. The techniques have found application in areas as diverse as vision systems, expert systems and game

G. N. Blount, Design Division, School of Engineering, Coventry University, Covenuy, UK; S. Clarke, Garfield Engineering Ltd, Wolverhampton, UK.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

300 G. N. Blount & S. Clarke

playing. The field of AI is considered in two sections: programming (search and representation) techniques and development tools.

Automatic design is an approach adopted by many researchers in the combined field and could eventually be one of the most widespread of the applications of AI in engineering design. This type of repetitive design activity accounts for approximately 60% of all engineering design work, so any improvements in the approach to programming automatic design systems could have widespread effects.

Many studies have been camed out into this potential and commercial systems are now available. The most common are expert systems that give advice on particular tasks with quite a narrow scope (see, for example, refs [l] and [2]). The most common engineering applications of expert systems at present are in the field of microelectronics [3]. Some are design analysis systems (see, for example, ref. [4]), while knowledged- based engineering (KBE) systems (such as ICAD) are essentially expert system shells for design problems. The user delines the rules and relationships that govern the design and manufacture of a product, using a design language (based on LISP in the case of ICAD), and KBE systems usually have interfaces to other software such as CAD and finite element programs.

Waterman [5] identified a number of general categories of use for expert systems. Dixon et al. [6] discussed an architecture for AI in design which places an emphasis on evaluation and redesign. This paper reviews the cognitive process of design and presents an attempt to use AI technology to automate this process in one application domain.

2. Requirements for Designing

2.1 Reasoning

By examining the design process using the attributes required of the designer, the case for a formal approach to design work may be presented. The most basic requirements, i.e. reasoning abilities, creativity and problem-solving abilities, are considered along with design problem-solving, which represents a subset of the latter.

The most basic requirement for solving problems is reasoning ability. There are several ways of analyzing this, and the following forms were considered in this work:

0 formal (or deductive) reasoning; 0 inductive (or analogical) reasoning;

procedural reasoning; meta-level reasoning.

In formal or deductive reasoning, one starts with statements that are self-evidently uue (or taken to be true) and, by mean of logical processes, sees what other uue statements can be derived from them.

Inductive reasoning occurs when we start with a set of special observations and, by extrapolation or analogy, make a generalization based on them.

Deductive thinking is an information rearranging process where we extract the implications of what is already known. Inductive thinking expands from the known to the unknown, but is not simple association. More specifically, it is a sophisticated process of hypothesizing, testing, and weighting the evidence-a kind of reasoning that is uniquely human.

Procedural reasoning uses simulation to answer questions and solve problems.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Artzjicial Intelligence and Design Automation Systems 30 1

When we use a program to answer' 'what is the sum of 3 and 4?', it runs a procedural model of arithmetic, just as a human would.

Meta-level reasoning is demonstrated by the way one answers the question 'what is the Queen's telephone number?'. One might reason that 'if I knew the Queen's telephone number, then I would know that I knew it because it is a notable fact'. This involves using knowledge about what one knows, particularly about the extent of one's knowledge and about the importance of certain facts.

2.2 Problem-solving

The above techniques are some of those used when we are reasoning about the world or solving problems with which we are confronted. Newell and Simon [7] stated that "A person is confronted with a problem when he wants something and does not know immediately what series of actions he must perform to get it". If one needs to find the square root of 1764 and remembers the procedure, one need only carry it out (procedural reasoning); the problem is trivial. However, if one has forgotten how to extract square roots, i.e. one does not have all the information, then it is a non-trivial problem.

The distinction between solving problems one knows how to solve (knowledge based) and those one does not know how to solve (real or non-trivial problems) is arbitrary; most situations involve some knowledge but some area of uncertainty. Because of this, two different types of mental activity are required to be performed: algorithmic and heuristic. An algorithm is a learnt and memorized working plan or procedure. When one lacks some of the requisite information to reach a goal, one must use more general strategies to achieve a solution; for example, taking what seems to be a likely approach up to a point where it seems unprofitable, backing up and trying another approach, and so on. These broad principles of exploration and evaluation are called 'heuristics'. Every algorithm or procedure is the result of what was once a problem requiring heuristic solution.

Newell and Simon's view of the interaction between the environment and the human is as follows.

First, one perceives the raw data and processes these perceptions far enough to recognize the task environment-the components of the problem or the terms in which it is presented. They may consist of words or other symbols and their meanings, or objects, or a mixture. Next, one transforms this information into what Newell and Simon called one's 'problem space'-a mental representation of the task environment. This is one's interpretation of where the goal is, where one is in relation to it, and what kinds of act must be performed to reach it-logical or arithmetical procedures, a shaking or jiggling of the pans, trial and error juxtapositions, etc.

Depending on the way that the problem space is perceived, one uses various kinds of information, drawn from memory or given with the problem, to process the data and move towards the goal. The total set of mental operations one uses in the effort to move from given information to the goal is what Newell and Simon called one's 'production system'-a computer science term that can be roughly translated into one's program.

In the course of carrying out the program, one notices whether or not any steps or series of steps decrease the distance to the goal; if so, one continues with it but, if not, one moves on to the next step in the program. If the entire program fails to carry one to the goal, then one quits, modifies the program or changes the problem space.

Dunker [8] saw that the route taken by the mind in groping towards a solution could be described in terms of a decision tree or solution tree. The problem-solver

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4


a a a a a a n/ FIG. 1. Diagram representing hierarchically organized knowledge.

starts out with only a general idea of which way to go, but sees a number of major avenues of thought branching out ahead; each in turn branches out into more specific avenues, and those into still more specific avenues. Solving the problem consists of making the correct choice at each fork or, if the branch chosen leads in the wrong direction or to a dead end, backing up and trying another, until one has worked one's way to the solution terminus. T o prevent the mind following every branch to its dead end, the mind prunes the search tree and takes only a tiny percentage of wrong forks, following most of them only part way.

From a variety of such studies, Newel1 and Simon and other researchers have been able to extract and describe, in information processing terms, a number of general characteristics of human problem-solving, including the following:

We work through a problem space in a serial manner. We avoid the use of trial-and-error search that blindly looks at every possibility, but do use this technique when the number of possibilities is very small. We use a selective search when trial and error is unworkable. One method of selective search is to comb through our experience for an analogy-some object or process related to the present problem-and use it as a guide. Two simple heuristics used in pruning the decision tree for a problem are as follows:

-best-fist search, i.e. at any fork in the tree, you first uy the next available node that appears closest to the goal;

-means-end analysis, i.e. having observed that some node lies closer to the goal than does your present state, you choose an allowable operation (a means) that will get you there, so making that node a subgoal with which to plan ahead through a series of subgoals.

We learn from experience. When a series of steps leads us towards the goal but then comes to a dead end, we do not go back to the beginning but so only as far as we must, so as not to discard any valid part of what we have learnt.

Reif [9] concluded that the knowledge of experts is hierarchically organized. In his mind, the specific details and phenomena of physics are logically grouped; these are

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Artificial Intelligence and Design Automation Systems 303

grouped into more general topics, and these topics are grouped into still more general topics.

Reif used the diagram in Fig. 1 to illustrate this point. The dotted lines referred to as 'pointers'; particular associations, created by experience, that lead directly from one specific to another, interconnecting the smaller branches of the tree and providing a series of short cuts.

Experts have many such interconnections in their minds, but they generally approach problems from the top down; this is the key to expertise. We find that the expert differs from the novice in three ways. One of these differences is domain knowledge. In medicine and other areas, the expert and novice have the same basic information but the expert has a larger experiential background, and this has added refinements and distinctions to the expert's basic knowledge. The expert doctor is able to recognize subcategories of the disease; they have a finer discrimination net.

The expert also has a high-altitude overview, which is hierarchical in structure. Highly expert people have an enormously efficient picture of what they are uying to do--they see things in perspective, so they know just what additional information they need. The less expert person collects a great deal of unnecessary data, because they do not know what they need to know, i.e. the non-expert has poor subject meta-knowledge. The third distinction-maybe the crucial one-is that the expert has many specifically tailored tricks to make the problem manageable--quick little associations based on a lot of experience, linking one or two scraps of information with the heart of the problem; pointers and crosslinks in the knowledge network.

Problem-solving in any expert domain involves hierarchical thinking and means- end analysis, but there is a great deal of thinking based on knowledge specific to that domain that consists of short cuts and tricks, and is not part of any general theory of problem-solving. The paradox of expertise, according to Hunt [lo] is that the expert often cannot tell you how helshe does what helshe does.

2.3 Creativity

Many people argue that the heart of design is the search for solutions to the problem, the success of which is measured by how creative the solution is. However, we assess the creativity of an idea in terms of our personal reactions to the idea itself. As de Bono [ l l ] put it, "creativity is a value word and represents a value judgement-no-one ever calls creative something new which he dislikes".

The creative process has been the subject of a great deal of speculation and very little research, and for good reason: part of the process (possibly the most important part) takes place in the subconscious. Thus, it can neither be described by the persons in whose mind it happens nor observed by others. The product of the mind's subconscious work emerges into the conscious but what takes place before that emerges remains unknown. T o date, cognitive scientists have only been able to speculate and make a few inferences about the unseen events.

Helmholtz [12], a German physiologist and physicist, described his own scientific investigations as proceeding through three stages:

0 saturation, which consists of the initial investigation, carried on until he could make no further progress with the problem;

0 incubation, which is the period of rest and recovery, during which, without conscious awareness of it, the materials in the mind were moved about and reorganized;

0 illumination, which is the appearance of a sudden and unexpected solution.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

304 G. N. Blount CY S. Clarke

Poincare [13] added a fourth step, i.e. that of verification. Despite many years of general agreement as to these stages of the creative process, only saturation and verification are well understood.

The creative idea is a problem-solving response in which heuristic search methods are used to find a trail that leads to a goal we may not clearly see. The important points are that we have never been along that same trail before, and we may not know what the goal is until we are there, and further work appears fruitless.

3. Design Problems

The process of design embraces the activities and events that transpire between the recognition of a problem and the specification of a functional, economical and other- wise satisfactory solution to that problem. Design is the general process by which the engineer applies hisiher knowledge, skills and point of view in the creation of devices, structures and processes. Therefore, it is the central activity in the practice of engineering. Whatever the engineer may be creating, helshe does so by the same basic design process [14].

The types of problem which the designer encounters generally require all the previously mentioned attributes (i.e. deductive reasoning, analogical reasoning, procedural reasoning and creative ability), to varying degrees, while solving tasks involving synthesis and analysis. Furthermore, problems in design often have unclear goals (i.e. they are open ended) and relatively unconstrained means of getting there; one may not even recognize the goal until one has reached it. These facts make control of the process potentially difficult, especially so as the required complexity of the solution increases. Because of the complex nature of design problems, many have attempted to formulate methods of solving them. While the various authors (see refs [IS-181, for example) use varying descriptors, titles and procedures, possibly as a result of their varying back- grounds, there is a common core which is central to the design process, regardless of the level at which the activity is being performed. The degree to which the various authors break down their functions differs from case to case, but all share the idea of a step-by-step advance from a qualitative to a quantitative phase. They all try to algorithmicize the process, express it by simple rules or laws, and stipulate a deliberate variation and combination of solution elements of differing complexity. Some of the features common to the various systemic methods are as follows:

0 they attempt to separate the logical and imaginative aspects of design, so that each plays its part without interaction and interference;

0 a record is obtained of the course of the design process; 0 at several stages, a large number of people can take pan in the design activity; 0 all factors concerned with the design can be kept continually under review; 0 the design proceeds by predetermined stages; 0 the distribution of effort between retrieval and generation of design information is

made explicit.

One is faced with the prospect that there is no unique solution to a design problem, but only a space within which acceptable answers lie, and no ideal solution is possible. The best solution is that which conforms to problem criteria most appropriately. Therefore, when testing solutions to a problem, one must judge relatively, as well as absolutely, if many solutions are possible.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Arttj5cial Intelligence and Design Automation Systems 305

INFERENCE ENGINE

Inference Control

EXPLANATION KNOWLEDGE SUBSYSTEM User

Expen

WORKING MEMORY d

FIG. 2 . Generic expert system architecture.

T

-- KNOWLEDGE BASE

Rules Facts

Most problems as presented to designers are ill defined and complex, and the designer is relatively unconstrained in the methods helshe uses to solve the problem. Each problem is different in that it requires a variation in weighting and control of individual phases. As one moves deeper into a design problem, the constraints applicable to any subproblem are determined by decisions previously made by the designer and will vary depending upon those decisions; this means that controlling this process is very difficult. Pahl and Beitz [IS] claimed that these categories account for around 75% of all design work, so that the impact of any increase in efficiency of design work is potentially large.

Most design methodologies [I91 have as their basic mode of operation the 'gener- ate-and-test' strategy, where the conceptual phase is involved in the generation of solutions and the analysis phases are the testing of possible solutions. The process contains many levels of generation and testing-throughout all phases-and this is the basis for the iterative nature of design. When using this method for design work, the designer uses heuristic (shallow) knowledge for solution generation (for example, if it looks correct, then it might be correct) and theoretical (deep) knowledge for the testing stage.

4. Artificial Intelligence

A1 draws parallels between the human brain and electronic brain, and covers a range of subjects, including robotics, game playing and expert systems. Within the subject area of expert systems, which is relevant to automating design, there are a number of subareas to consider. These can be broadly categorized as representation and search.

As shown in Fig. 2 , the two main components of an expert (or knowledge-based) system are the knowledge base and the inference engine. The knowledge base consists of a 'representation' of the expert knowledge, in the form of rules and facts. There are - a number of methods of representing knowledge [19], depending upon the time and money available for system development, and the type of problem areas encountered. . .

The inference engine is the component of the system that searches through the knowledge base, in an attempt to find a solution to the problem. A number of inferencing mechanisms [20] including backward chaining, where one starts with a goal and attempts to prove the goal; and forward chaining, where one attempts to find a solution from the data available.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4


Tools for the development of knowledge-based systems are frequently categorized into three types:

(1) languages (such as LISP and PROLOG); (2) expert systems 'toolkits' or 'environments' (such as ART, KEE and LOOPS); (3) expert system 'shells' (such as EMYCIN and SAVOIR).

Broadly speaking, languages are the most flexible method of programming, but they are more difficult and time consuming than other methods. Shells are a cost-effective and quick method of constructing a system, albeit within a rigid framework. Toolkits have the flexibility required and have features available to enable rapid construction of systems, but they require relatively expensive hardware and software.

5. Automatic Design

Typically, in design, one is presented with a solution search space that is bounded only by the experience of the designer and has ill-defined boundaries. In an expert system, the search space is defined by the programmer and, out of necessity-as a result of cost and technological constraints-is contained within a narrow domain which must have well-defined boundaries to maintain performance. In A1 design systems, one must devise a method of controlling the many variables and the constraints that they affect if one is to control the process successfully. In problems that require the generation of an original solution principle, the search for solutions requires the ability to reason in numerous ways, including reasoning by analogy, which is not generally available as an inferencing mechanism.

The above evidence suggests that the types of design problem most suited to A1 systemization are those that fall within the categories of variant or possibly adaptive design [15]. These follow a similar, previously solved problem, i.e. the solution principle is established. This would allow an efficient representation of the search space to be formalized and the process would be rendered controllable.

The following describes the application of the model of the design process developed for automatic design systems. The approach is described with the assistance of an example application, i.e. the selection and design of an engine oil pump. The choice of solution principle is used to give an overview of the process with more system details attached to the description of the detail design of the pump. T o use the design methodology as a basis for an A1 system, the following series of tasks must be performed:

0 specify the problem; 0 search for solution principles;

test solution principles; compare possible solution principles;

0 develop the most appropriate solution principle(s); 0 specify the complete solution.

These tasks are performed by a series of program modules which, as with most design methodologies, are identified by their inputs and outputs. The data for this example were supplied by one of the companies collaborating in the work. The required knowledge was acquired by conducting interviews with the company's engineering personnel.

The demonstration problem is to supply a 1.4 1, 41 kW automobile engine with lubricating oil. A pump is required to supply 23 1 min-' at an engine speed of

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Artijicial Intelligence and Design Automation Systems 307

6000 rev min-', a pressure of 4 a m and a fluid viscosity of 0.012 N s m-', at normal operating temperatures. The design is also constrained by the available volume within the engine sump to the solution envelope volume of 120 cm'. One is also concemed with the following criteria: high reliability; low cost; low maintenance; high mechanical efficiency; low envelope volume; and low mass.

The problem specification consists of a series of constraints and criteria to which the solution must conform to be successful. The specification is set up with the aid of a series of checklists arranged hierarchically, based on those found in industry [19]. The criteria are ranked and weighted by a straight comparison between two criteria to establish the ranking and an adjustment to the weights attached to each criterion if is necessary.

The constraints and criteria are represented as PROLOG clauses of the form

con (constraint, attribute, value) crit (criterion, attribute, weighing)

Where a constraint may be of the form

con (cost, max, 200)

i.e. the maximum cost of the solution must not exceed 200 units. In the case of criteria, we have

crit (cost, low, 8)

i.e. the weighing of the low cost criterion relative to the other criteria is 8. Depending upon the criterion or constraint, varying representations are required

and, as a form of control, the constraints are restricted to the problem domain. In the demonstration, the constraints are restricted to the performance and geometry, while the criteria are restricted to the economy, geometry and performance. The output from the specification module is stored in a module that is accessible from any part of the system.

At this stage of development, the solution principles are in the format required by the testing module, i.e. the information that is required for comparison against the specification is supplied. Information on the criteria is contained in clauses of the form

sol (number, criteria, relative-value)

e.g. sol (2, cost, 5), indicating that solution number 2 has a relative value of cost of 5 compared with some reference. The reference may be taken as another solution or some independent datum. At this stage, one is concemed only with relative values, such as the least expensive solution or that with the smallest volume.

Testing of solution principles against the problem specification consists of a comparison of constraint values for solution principles against the respective values for the specification. Any value falling outside the range indicated by the specification fails the test and the solution principle is rejected. However, at this stage in a design problem, one generally does not know if the solution principle will satisfy all the constraints and an educated (heuristic) guess must be made. It may be the case that sufficient information is not available until the solution has progressed well into the development stage.

The above process identifies those solution principles-and there may be many- that fall within the space bounded by the problem constraints. The most appropriate solution principle may now be identified using the problem criteria. Therefore, the specification for each solution principle is accessed, the value associated with each

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

G. N. Blount & S. Clarke

criterion for a solution principle is multiplied by the relative criterion weighting, and the result is recorded. The weighted values for all the criteria are summed for each solution principle and the process is repeated for each solution principle; the highest summed total indicates the most appropriate solution principle.

If the state of the solution development at this stage is such that it constitutes a solution, then the procedure is complete. This is the case for many selection problems where one is presented with discrete solutions to problems. In the context of the demonstration, the procedure presents the most appropriate solution principle- in the case of the demonstration, this is an external gear pump. The solution principle must now undergo the development and detailing cycle, which is performed by a knowledge base dedicated to the particular solution. The demonstration uses a simplified representation of a gear pump, the suucture of which may be organized in a hierarchical form, as shown in Fig. 3. Representing the problem in this form allows its solution using the backward chaining capabilities of PROLOG, i.e. the solution evolves from lead nodes of Fig. 3(a) upwards. This method of programming relies upon the procedural aspects of PROLOG as well as on the declarative aspect.

The design rules for performance covered the following:

cost (constraint and criterion); 0 flow rate (constraint); 0 envelope volume (constraint and criterion); 0 pressure increase (constraint);

viscosity (constraint); 0 reliability (criterion).

These had lowest level subrules to evaluate the actual performance. In addition, a top-level parameter list was implemented as a checklist for the designer. This covered the following: geometry; energy; forces; signals; safety; ergonomics; maintenance; transport; manufacture; quality; assembly; costs.

The principle was that each parameter is linked to the relevant design rules, so that the designer is guided through the construction of constraint and criteria values and requirements. Selecting the geometry, for example, would determine that the envelope volume had a certain maximum value (constraint) and should be minimized (criterion). Only certain of these parameters were implemented, as demonstrations of principle.

The detailing stages use the same methodology as the solution principle choice stages, with the problem specification being the source of solution assessment information. At this stage, decisions are primarily quantitative to determine the pump dimensions and performance. The solution search stage of development takes the form of a scan through a database of available solutions-in this case, gear dimensions. This information is stored in a database as structures, such as

gear (20, 8, 6)

where the arguments represent the gear tooth root diameter, tooth width and tooth height. A database of gear dimensions was constructed, spanning all combinations of gear diameters from 10 to 30 mm, gear widths from 5 to 15 mm and tooth heights from 2 to 6 mm.

Performing such searches can be inefficient and costly, and it is of concern to many in the A1 field who attempt to 'prune' the search tree or space using

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Artzj5cial Intelligence and Design Automation Systems 309

(a)

Housing

Driven Driver Cenue 4 Cese 4 Cover

Width Outer Inner Wall Outer diamete radius diicn. radius

A diameter height

Housing OD I

FIG. 3. (a) Interrelationship of design issues. (b) Gear pump layout.

various methods. The search may be restricted by using a series of geometry rules, such as

TW > = GID10.3 and TW = < GID10.5

which respectively state that the gear tooth width must greater than or equal to 0.3 times the root diameter, and the tooth width must also be smaller than or equal to half of the root diameter. These rules define the geometric limits between which solutions must fall for all gear pumps. This prevents excessive testing of solutions and uses 'shallow' knowledge which a designer would employ. Gears satisfying the initial test are taken through to a further test of problem-specific constraints in the specification. At this stage of design, testing would take the form of a deeper, theoretical investigation, such as stress, performance and thermal analysis. In the demonstration, this level of testing is concerned with the calculation of theoretical performance values such as the

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

3 10 G. N. Blount & S. Clarke

flow capacity. As with the choice of solution principle, this stage involves comparing the available solutions with the constraints in the problem specification.

As an example, the flow rate may be used as a performance constraint. This is calculated for each pair of gear dimensions, using a series of geometrical and theoretical equations. The gear tooth geometry determines a theoretically possible flow rate for a given angular velocity; the program uses the 'industry standard' assumption that the pump speed is half the crankshaft speed, and a slip factor is calculated to allow for leakage flow. Each gear dimension must be evaluated for each respective constraint, and a check made for compliance with the required constraining value. For example, if one considers gear dimensions of 30, 15 and 4 for the root diameter, tooth height and width, respectively, a flow rate of approximately 16.5 1 min-' is available. This value is below the constraining value of 25 I min-'. In the database, there are many dimensional options available, all of which must be tested. For example, if one considers gear dimensions of 30, 15 and 6, a flow rate of approximately 25.4 1 min- ' is available; this satisfies the flow rate constraint. The result of this is a set of solutions that have passed through a first filter.

Approximations of the envelope volume are required for constraint satisfaction and criteria comparisons. If one considers the previously satisfactory gear dimensions of 30, 15 and 6, an envelope volume may be approximated at 115 cm3 which satisfies the envelope volume constraint. If gear dimensions of 40, 15 and 6 are taken, then the envelope volume of 140 cm3 falls outside the constraining value and the solution attempt is rejected, even though it satisfies the flow rate constraint.

As with the higher levels, the next stage is one of comparing each possible solution with respect to the others, in order to obtain the most appropriate solution. At this quantitative stage of the design process, the use of percentages is particularly applicable, because the final solution principle is known and one may develop accurate quantitative tests, allowing precise comparisons. As an example, the envelope volume of the pump is required to be as small as possible, while conforming to the performance constraints. Multiplying the values for the envelope volume calculated in the constraint satisfaction stage into the most appropriate (i.e. smallest) volume gives a relative value. For example, if values of 80, 100 and 120 cm3 are calculated for the envelope volume, they may be represented relatively by the values 1.5, 1.2 and 1 respectively.

This process is repeated for all solutions and criteria, to build a matrix of relative values. As with the higher levels, this could be performed by knowledge bases acting as specialists that analyze solutions with respect to a particular criterion. In the case of reliability or other 'unquantifiable' criteria or constraints, some empirical, statistical or theoretical basis for analysis must be adopted. This represents an analysis of each solution with respect to the specification.

The next stage can be simplified into a multiplication of the relatives values of the solutions by the weighting from the specification. This is performed by matching the relevant PROLOG facts and comparing relevant values. For example, the low envelope volume criterion compiled earlier was given a weighting of 4. The program takes each solution and multiplies the relative value assigned to it-1.5, 1.2 and 1 in the previous example-by the criteria weighing (4) to give weighted values of 6, 4.8 and 4 respectively. The totals may then be summed for each solution, to give the most appropriate detailed solution from those solutions available. The program uses a bubble-sort procedure to order the solutions and presents the top of the list as the most appropriate solution. In the case of the demonstration example, the gear dimensions are as follows: root diameter, 30; tooth width, 15; tooth height, 6.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Arttjicial Intelligence and Design Automation Systems 3 11 - Constraint I I criteria I wmpilation

Top level

, . . . . . . . . . . . . . . . . . . : Sewnd level

i prompts

I I Problem specification crileria compilation ranking

Consult constraint weighting compilation program adjusunent

Consult criteria I wmpilation program Y

I Pump principle database

Problem specification

Compare solution principles with Rejected

principles

Consul1 criteria I weights

Multiply relative solution

Sum crileria total

Son solution totals

- Criteria analysis

programs - Costing now

flow rate env. vol.

solution principle

Possible solution analysis

Consult criteria

Consult analysis programs

Compare analysis results for

relative values

4-b

-internal gear pump

4

FIG. 4. Procedure to obtain most appropriate solution principle.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4


Initial filter

Gear size database Acccss gear database

Test geometric relationships Rcjcctcd solutions

Initial liltered solutions I

I Solution comparison I Consult critcria

Solution evaluation programs - Flow rate

env. VOI. cost. ctc.

Sum totals for all criteria

Possiblc solution asling

Evoluolc solutions for each wnsminl and criterion P

Consult constraints

Cornpw absolute solution valucs against spccilication

Filtcred solutions

4-+

SOR solution totals to give highest ranking

e

Most appropriate solution * FIG. 5. Detailed design procedure for internal gear pump.

These values, and others quoted earlier, were consistent with those of the actual pump used as an example. This provided a first-level validation of the program's principles. Other performance requirements were tried to test for robustness, which proved to be good. These tests were restricted to requirements that were likely to have a gear pump as the best solution, since quantitative knowledge was known for that type of solution.

The program was written in PROLOG 2 from Expert Systems International (professional level). The hardware used was an IBM PC-AT with 640 kbyte RAM and a 20 Mbyte hard disk. There was limited RAM available as working memory and this meant that the program had to use small modules.

A version of the overall strategy may be drawn (Figs 4 and 5) to show its interaction with the supporting procedures. These diagrams show only a few feedback or iterative loops, in order to simplify the representation. In problems of this type, PROLOG or any declarative language is of particular use, because of the nature and amount of data, and the manner in which the data are accessed. The structure of the language allows

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Artzjicial Intelligence and Design Automation Systems 3 13

easy access and maintenance of databases, and individual rules may be modified without affecting lengthy sections of procedural language.

There are two programming styles available in PROLOG: a declarative style and a procedural style. In declarative programming, the focus is on telling the system what it should know. Facts about objects and relationships are specified in databases as data structures, such as in the form of design rules or gear dimensional data. In procedural programming, the emphasis is on the specific problem-solving behaviour that the computer will exhibit. For example, a procedure may be written to control the design sequence at the system level.

Theses attributes make PROLOG ideally suited on this type of problem. The procedural capabilities are sufficient to construct a procedure to guide the search through various individual declarative stages.

6. Conclusion

A methodology has been presented as a model for automatic design systems. Its use has been demonstrated at various levels in design decision-making, and a number of problem areas have been identified. While the methods and the associated A1 technology are both in their infancy, the potential uses of A1 and theories of how one might advance towards practical systems using the work of cognitive scientists working in the design field have been displayed. A much greater understanding of the cognitive processes will be required before truly 'intelligent' systems are practical. Very precise solution search spaces are required to restrict searches and provide sufficient control. When one is presented with a precise problem area and well-defined goal states, practical systems are possible, and this is the starting point for widening their scope.

REFERENCES

[l] ALSINA, J., FIELDING, J.P., MORRIS, A.J. & ADROIT (1986) An Aircrafr Design Aid (Cranfield, College of Aeronautics, Cranfield Institute of Technology).

[2] JANSEN, J.J. & PUTGEN, H.B. (1987) AS DEP: an expert system for electric power plant design, Proceedings of the IEEE Expen Conference, 1987.

[3] SALDANHA, C.M. & LOWI-HER, D.A. (1986) Automating the design process for electro-magnetic devices, Computer Aided Engineering Journal, October.

[4] S w m , K. & M A ~ E W S , A. (1983) Expert computer systems in engineering design, Engineering, September.

[5] WATERMAN, D.A. (1986) A Guide to Expen Systems (Reading, MA, Addisoq- Wesley).

[6] DKON, J.R., SIMMONS, M.K. & COHEN, P.R. (1984) An architecture for application of artificial intelligence to design, Proceedings of the 21st Design Automation Conference (New York, IEEE).

[7] NEWELL, A. & SIMON, H.A. (1972) Human Problem Solving (Englewood Cliffs, NJ, Prentice Hall).

[8] DUNKER, K. (1945) On problem solving, Psychology Monographs 58, whole number 270.

[9] REIF, F. (1979) Cognitive mechanisms facilitating human problem solving in a realistic domain: the example of physics, Report (Berkeley, CA, University of California at Berkeley).

[lo] HUNT, M. (1955) The course where students lose their earthly shackles, life.

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4


[l I] DE BONO, E. (1979) The Use of Lateral Thinking (London, Penguin, Har- mondsworth).

[12] HELMHOLTZ, H. (1895) Popular Lectures on Scientific Subjects, 1st Series (London, Green).

[13] I~OINCARE, H. (1924) Mathematical creation, in: VERNON, P.E. (Ed.), Creativity (London, Penguin).

[14] KRIcK, V. (1969) An Introduction to Engineering and Engineering Design, 2nd edn (New York, Wiley).

[15] PAHL, G. & BEITZ, W. (1984) Engineering Design (London, The Design Council).

[I61 COULTHURST, A. & ELCOCK, D. (1980) Undergraduate engineering design-a partnership with industry, European Society for Engineering Education (SEFI) Confer- ence hceedings, Paris.

[17] h b l e m Analysis by Logical Approach (PABLA) (Atomic Weapons Research Establishment).

[I81 HUBKA, V. (1982) Principles of Engineering Design (London, Butterworth). [I91 CLARKE, S., BLOUNT, G.N. & COULTHURST, A. (1986) Educational and

industrial design methodologies, Repon 52, (Coventry, Coventry Polytechnic). [20] BARR, A. & FEIGENBAUM, E.A. The Handbook of Artificial Intelligence, Vol. 1

(London, Pitman).

Dow

nloa

ded

by [

"Que

en's

Uni

vers

ity L

ibra

ries

, Kin

gsto

n"]

at 1

2:43

08

Oct

ober

201

4

Documents

Artificial Intelligence and Design Automation Systems