analysis of design abstraction, representation and inferencing requirements for computer-aided...

Analysis of design abstraction,

representation and inferencing requirements

for computer-aided design

Jami J Shah

Mechanical and Aerospace Engineering, Arizona State University, Tempe, AZ 85287, USA

Peter R Wilson General Electric Company, Schenectady, N Y 12345, USA

A comparative study of contemporary CADICAMICAE software and engineering tasks reveals a mismatch between the requirements of engineering and the capabilities of contemporary software. The mismatch lies in several areas, which include: sets of information supported, levels of abstraction or detail, and functions to aid visualization, reasoning and decision-making. This paper examines the mismatch in the above areas by means of generic models and discusses the functional requirements for

developing computer-aided tool~ for automating and integrating some design engineering tasks.

Keywords: design process, computer-aided design, CAD-CAM

CAD-CAM technology has only provided a means for documentation, drafting and specification of nominal geometry for finite elements and NC. Few designers use these tools for developing designs or in aid of their reasoning and decision-making processes. The application of expert systems to design has produced a new generation of design tools but these lack a sound geometry basis and tend to be limited to very specific domains.

The fundamental cause of these problems is that the tools have been developed without regard for the engineering process that they were supposed to support.

The mismatch lies both in the form and the level at which information is represented in these systems. In this paper we examine the requirements for automating and integrating engineering tasks by studying the nature of selected tasks.

THE DESIGN PROCESS

The broad objective of design is to draw up plans for a system or device that can perform the desired function

Vol 10 No 3 July 1 9 8 9 0142-694X/89/03169-10 $03.00 © 1989 Butterworth & Co (Publishers) Ltd 169

with the desired specifications without violating given constraints. The area of design is too vast, varied, and complex to have a common vocabulary. The abstraction level varies with the objective of a given phase of design (design step) and the design category. For this reason we would like to classify design as follows:

Class I

Class II

Class II!

Novd design: design of a new device/system from concept. Evolutionary design: modification or further development of proven system(s) to create a new one with improved or different performance characteristics. Matching design: adapting a generic system/ component to the desired conditions.

Class IV Design synthesis: creating a new system from existing or standard components.

Our classification is based on the fact that the design process varies considerably across these categories. However, there may be some common steps, too. For example, once an initial design is found in Class I the problem may become a Class III or IV design.

One could also have combinations of several of the above categories. The final design in each of the above categories is arrived at through the iterative execution of various combinations of design steps or phases. Figure 1 lists some typical steps in mechanical systems design. The particular steps executed vary from case to case.

The design process has been under intensive study by

1. Problem definition (formulation)

2. Gathering information

3. Conceptual design (a) Idea generation (b) Evaluation/selection of ideas (c) Development of ideas into conceptual design (d) Form synthesis (e) Evaluation/selection of conceptual designs

4. Problem decomposition

5. Engineering analysis (design development) (a) Selecting governing equations/laws/rules: functional analysis (b) Material selection (c) Failure analysis (d) Assumption/determination of independent variables (e) Determination of dependent design variables through static, kinematic, dynamic, thermal, structural analysis, etc. (f) Comparison of performance variables to design specifications (g) Modelling and simulation (h) Determination of functional tolerances

6. System synthesis (a) Selecting components (b) System components (c) Matching components (d) Systematic combination

7. Optimization (a) Defining objectives (b) Expressing the design as an objective function with sets of constraints (c) Selecting optimization strategy (d) Numerical or analytical optimization to determine design variables (e) Comparison of objective function values for different designs

8. Experimentation (a) Determination of parameters that cannot be predicted theoretically (b) Comparison of predicted and actual behaviour using prototypes

9. Evaluation and redesign

10. Final selection of design

11. Detail design and documentation (a) Manufacturability evalution (b) Application of standards (c) Listing of parts (d) Cost estimation (e) Detail drawings (f) Creating solid models for use by other processes (g) Complete record of calculations and decisions leading to fmal design

12. Design specification

Figure 1. List of typical design steps

170 DESIGN STUDIES

psychologists, philosophers, computer scientists, designers and many others, but until the recent developments in computer tools for aiding or automating design such studies were regarded as purely academic. The initial design phase of type I is the least understood whereas types III and IV can be characterized fairly well. One of the earliest works was by Asimow 1, who divided design into a sequence of operations or steps. Each step, he suggests, receives general information (know-how) and specific information (problem definition). The outcome of each step is evaluated and either the results passed to the next step or the step is repeated. Many experienced design engineers have also written about the design process; Gordon Glegg 2 states that design is very indi- vidualized and there are no iron-clad rules. He outlines many guidelines for conceptual design. There are numer- ous modern textbooks on the subject 3-6. Cognitive scientists have also attempted to produce formal theories of design 7-1°. Many investigators felt that traditional models of the design process were based on the respective author's feeling of how design should be done, not on how it is actually done. To discover the latter process, they began protocol studies (UllmanH); that involved videotaping designers who had been asked to think out 'loud'. These tapes were analysed, leading to the identi- fication of atomic operations and information sets used in design (Tikerpuul2). These operators were discovered to be: Select, Create, Simulate, Calculate, Compare, Accept/Reject, Patch, Refine, Draw. The study developed a representation scheme for mechanical design in terms of object states (assembly, connections, features). This work is still in the early stages and the investigators are not sure yet how designers determine what to do next; consequently, the functional requirements for design expert systems are not clear.

From time to time, reports have been published on the relationship between form and function (Alexander 13, Rinderle 14, Waldron15); these researchers feel that the key to understanding designs is the understanding of transformation from function to form. Rinderle express- es function in terms of performance variables and form in terms of component size; thus, his work does not truly address function to form transformation because he does not deal with the synthesis of mechanism configurations from generalized functions. So the design falls into category II! not I. On the other hand, Waldron ~5 set out to determine function-form relations by inductive reasoning. Designers were asked to look at engineering drawings and pick out function features, i.e. geometry that corresponds to certain functions. Their end objective was to determine the requirements for computer aided conceptual design (CACD). We think that the approach is not based on sound reasons because: first, a drawing is not the entire design; it is a communication from designers to manufacturing shops on what is to be built; it does not have many design variables; it is static and the designed device may not be static. One should look at a design notebook or do protocol studies, in our opinion, to discover function relations. Second, a drawing is a result of detail design, it bears little resemblance

to conceptual design. In conclusion, we state that the area of function-form relationships is still a virgin terri- tory.

Another popular technique used for studying designs is through case studies. An early work is that of Marplesl6: this described a project where a number of mechanical design case studies were analysed. It was found that the design process could be represented as a hierarchy (or decision tree) where problems were divided up and solved separately at first. Solutions involved consideration of alternatives at each of the atomic levels. It is appropriate to mention that psychologists modelling human problem solving had formalized the lattice theory as early as 1948 (attributed to Birkhoff); and this has continued to develop to this day 17. A lattice is a more general form of a tree. Cognitive scientists believe that when the human brain solves large complex problems it constructs mental models to simplify and abstract representation of the real system. It is thought that there is an 'abstraction hierarchy' to allow a choice of levels at which to think. A lattice consists ,of nodes and paths which slope upwards or downwards; the nodes represent the state variables of the system. An element (node) that is lower than another one can be thought of as the 'cause' of the other. The paths represent causality or the direction in which the problem solver's thought will travel. With further development it may become possible to apply lattice structures to designs which may lead to the development of computer-based design aids, diagnostic tools, etc.

CONTEMPORARY CAD SOFTWARE

Let us examine CAD from the following perspectives:

• information representation (data structure/database) • working environment (level of communication,

visualization tools) • functions to aid decisions

The central element of today's CAD systems is the solid modeller that is used for creating a database defining the geometry of the part being modelled. The most popular schemes are Boundary Representation (B-rep) and Con- structive Solid Geometry (CSG). B-rep modellers store the evaluated geometry as a redundant hierarchy of topological entities (faces, loops, edges, vertices) with pointers to geometric entities (surfaces, curves, points). Euler-Poincare equations are used to ensure validity of the created datasets as real objects. CSG modellers store unevaluated (procedural) descriptions of objects. The data structure is a binary tree whose leaf nodes are primitive objects and interior nodes are Boolean set operators. If valid primitives are used and the Boolean operators are regularized, then it is assured that the resulting object will be a valid solid.

In light of the above facts, we can make the following observations.

• The database is incomplete; it does not contain toler-

Vol 10 No 3 July 1989 171

ances, finish, material attributes, for example. • The database stores very low level details of the

nominal geometry; ie there are no higher level abstrac- tions of a product's description. Examples of higher level information are: form features (holes, gear teeth, cutouts, etc,), overall part shape (rotational, prisma- tic, sheet, etc.), feature relationships (several coaxial diameters forming a stepped shaft, for example).

• Visual interpretation can only be done by the user; when an image of the part is rendered on the CRT then only can a person interpret the meaning of the geometry data. Thus, the user cannot simply query the database with questions like 'how many holes are there?' Instead, one must look at the image to answer that question.

• Solid modellers do not support most design function and cannot capture design intent. Because these modellers require the specifications of detailed geometry they can only be used when the details of a design are already known. This is to say that solid modellers are simply documentation tools and not design tools, except in a narrow spectrum of design problems where mass properties calculations, interference checking or layout are the major objectives.

Mismatch in the level of abstraction between the designer and the CAD tool has two undesirable consequences: it results in (a) loss of information and (b) a poor working environment. A fundamental requirement of com- munications is that people who wish to communicate use the same language; the rules used in interpreting a message must be the same as those used in expressing the message. A person who does not understand the meaning of words and rules of grammar but recognizes only the letters will not be able to decipher the meaning of a message as intended by the user.

When one compares today's CAX tools (computer- aided tool to support Task X) to engineering tasks, with respect to the level of information abstraction, the problems associated with CAX tools become obvious. For example, solid modelling may be suited to some detail design activities but not to conceptual design, because a product is represented at such a low level of abstraction. A solid model database cannot be used to drive applications such as Group Technology Classification or Manu- facturing Process Planning without considerable human intervention. For this reason, some of the experimental generative process planning systems use their own system for product definition or depend on users to define features by grouping entities from an image of the object being modelled.

This demonstrates that the fundamental requirement for CAX tools is that it not only support all information sets used in Task X but also information must be at the proper level of abstraction.

CHARACTERIZATION OF ENGINEERING TASKS

In order to identify explicitly the differences between

CAX and Task X we need conceptual models. The generic model shown in Figure 2 incorporates the essen- tial elements of such characterization for engineering tasks. Thus, Task X can be modelled by the following: objective, such as producing a system design or a process plan, etc., input information that it is driven by and output information that it produces. The task has a certain vocabulary, which we define as the medium of knowledge expression to aid reasoning. The information is represented at a certain level of abstraction or detail. We must also understand the nature of the engineering proces- s(es), i.e. the mechanics of reasoning and decision making.

It is convenient to think of the engineering process as a series of tasks; several tasks may be performed by the same engineer or by different groups of specialists. In performing each task, one constructs a problem state- ment that encompasses what is required, what is already known and what the constraints are. The person performing the task applies knowledge in the domain of the task to reach the goal. The knowledge can consist of equations/procedures from engineering science, rules from accepted practice, intuition and judgement from personal experience and company proprietary information related to the product.

Similarly, a CAX system can be characterized by the contents of its database, the environment it provides and the functions or operators it makes available to users for supporting the reasoning process. This is shown in Figure 3. Computer tools to support task X can be created at several levels: one may develop a tool simply to aid the human performing a task or a tool that performs other tasks autonomously. A CAX tool of the first type must support the vocabulary of the task and provide functions in support of the reasoning process. On the other hand, an autonomous tool must incorporate domain knowledge, in addition to the above requirements.

APPLICATION OF GENERIC TASK MODEL

We will now use the above models to compare engineering design to CAD.

Vocabulary and reasoning process of design

There is a misconception in the geometric modelling community that only tools that aid visualization of actual geometry are needed to design. A visual representation of the geometry is almost always required for the purpose of documentation, but as the list (Figure 1) indicates the representation requirements for the development of a

) TASK X Information Objective Information Input VOCabulary ) Output

Process/es t

DOMAIN KNOWLEDGE General rules and procedures (accepted practices) Proprietory information Personal expertise

Figure 2. Conceptual model for Task X

172 DESIGN STUDIES

I n f o r m a t i o n i n

), CAX TOOL Database

Environment Functions/operators

1

I USER Domain knowledge

) Information out

Figure 3. Conceptual model for CAX tool

design are quite varied. The dependence on visualization and the form of visualization vary with needs of the design decision-making process. At the conceptual stage of Class II or IV design, one often uses symbolic representations or flow charts, as shown in the examples of Figure 4. For Class I design, conceptual sketches may be even less formal and perhaps only meaningful to the designer himself. At some stages of design one may not need any form of visualization to make the required design decisions; often the problem is expressed and solved algebraically or heuristically.

For the purpose of illustration we will consider a simple design example of Class III, viz. a matching problem. A matching problem was deliberately chosen because the number of steps are fewer than in other categories. Suppose it is required to design a motion transmission system to transmit power from a driver shaft to a driven shaft. The first sub-task is to determine the type of system to be used, such as a belt drive, sprocket-chain drive, gears, etc. The following input information is needed by this sub-task:

• max power transmitted; load characteristics • max/min speeds and direction of rotation • speed ratio • centre distance between shafts • relative orientation of shafts (parallel, perpendicular,

inclined) • tolerance range of output speed

The reasoning proceeds as follows. If the minimum speed is too low, a belt drive system cannot be used because a rule of thumb is to design such for V-belt speeds in the neighbourhood of 4000 fpm to prevent significant slipping; of course, larger sheaves could be used too, but this depends upon other factors. If the maximum speed is high, chain drives cannot be used (neither can V-belts) because high inertia forces in metal chains cause them to fly off the sprocket, thus reducing efficiency. If the centre distance is too large, gear drives are not feasible. If there are strict and narrow limits on speed fluctuation some kind of gearing must be used. Other factors are similarly considered. This part of the decision-making process requires no visualization; only some qualitative reasoning and heuristics are used. Sup- pose that a gear drive is selected. The next task would be to determine the arrangement and pitch diameters of gears in the train. Using algebraic equations incorporat- ing pitch diameters and speed ratios in combination with rules from standard practice, the number of pairs required and gear pitch diameters are determined. Sketch-

COMBUSTOR

S Y M B O L I C REPRESENTATION

° ° °

S C H E M A T I C R E P R E S E N T A T I O N

l l % /

OUTPUT

GEOMETRIC REPRESENTATION

KINEMATIC REPRESENTATION

Figure 4. Examples of visualization methods. Ca) Symbolic representation. ( b ) Schematic representation. ( c ) Kinematic representation. ( d ) Geometric representation

Vol 10 No 3 July 1989 173

es are helpful at this time but the detailed geometry is not relevant. The only relevant parameters are centre positions of the gears and pitch diameters; the shape features of the gears are irrelevant. After a tentative arrangement has been selected a standard tooth form and size must be determined. The pitch diameters are subsequently ad- justed to allow using a standard tooth size.

Thus, the transmission system design can be fully specified by the following parameters: number of pairs, centreline positions, pitch diameters, number of teeth, tooth type, speeds and power transmitted. The only graphical representation needed will be an abstracted one such as that shown in Figure 5a. This may be followed by force analysis at the system level (Figure 5b) and then structural analysis of individual teeth, Figure 5c. Not until one engages in structural analysis of the gear train does it become necessary to use an actual geometric representation (Figure 5d). Designers think of the geometry in terms of form features, i.e. elements of a parts shape such as rim, arms, web, hub, etc. Thus, the nominal geometry needed in structural analysis can be expressed as sets of form features. Stress analysis of the gear body can be done by hand calculations (formula matching); gear teeth could be analysed with empirical formulas or finite element analysis may be deemed necessary. Depending upon the type of teeth and finite element (FE) program used, the FE model could be based on one of the following:

• 2D profile of one tooth • 2D profde of two teeth in contact • 3D form of (a) or (b) above

In none of the above cases can the geometric model of the gear assembly be used directly. Note that the designer has little use for the actual geometric form of the tooth (unless an FE analysis is done) because the following technological parameters describe a standard tooth com- pletely: diametral pitch, pitch diameter and pitch angle. We will term such sets of information as technological features. There is, of course, an equivalent geometric representation of the tooth in terms of form features.

A stipulation on noise level or a consideration of vibration modes at high speeds will lead to the specification of surface finish and tolerances on gear teeth. These can be considered to be precision features of the part.

After completing the functional and structural analysis of the gears, the designer will turn his attention to secondary machine elements such as the shafts on which the gears will be mounted, fastening method (splines, keys etc), bearings, seals and housing a representation such as the one in Figure 5e is helpful. Each of the components can be described by the nominal geometry of certain shape elements, i.e. form features, and variations from the nominal, i.e precision features. The characteristics of the materials to be used and treatments applied are also determined and documented. These will be termed material features.

From this synopsis of design development and documentation we learn the following.

• There are several basic categories of design; the steps undertaken, and the order in which these are undertaken, depend upon the design category as well as the designer's expertise and other constraints. CAD systems are only suitable for some aspects of detailed design.

• Experienced designers can quickly identify the most problematic or critical function. It is this function or problem that receives most attention at the early stages in design.

• When working at the system level, designers consider only some gross characteristics. Subsequently, they focus on certain aspects of the design or certain parts of the product. Designers store only relevant variables in their 'mental database', filtering out information that does not influence the task they are engaged in.

• Each design sub-task has its own vocabulary, which depends upon the information needed for performing the task and the level of abstraction (detail) required. This influences the way designs are represented. Descriptions could be textual, algebraic or graphic. There are many forms of graphic representation: symbolic, schematic, kinematic, geometric. The representation reflects the information available at the given phase of design and the form is chosen to aid those aspects of visualization that are relevant to the decision-making.

• Design is an iterative decision-making process that can involve any combination of heuristics, analysis, selection or synthesis. Parameters flow from task to task selectively and are either used to determine other parameters or modified or treated in more detail. Parameters can be geometric or technological.

• Many types of information sets are required. These sets are the elements of the design vocabulary. Some examples of such sets are: form features, precision features, assembly features, material features, etc.

• At the microscopic level a designer's actions can be broken down into the actions mentioned earlier from the study of Tikerpuu and Ullman '2.

When we apply the conceptual model proposed earlier to engineering design we produce the representation shown in Figure 6. Similarly, when the model is applied to CAD the representation is as shown in Figure 7. A comparison of these two models shows that the nature of CAD systems bears little resemblance to that of engineering design.

EXPERT SYSTEMS FOR DESIGN

So far, CAD has been the focus of our attention; but there is another kind of software on the horizon, viz. expert or knowledge-based systems. Expert system con- cepts have been used in developing software for design since 1983. For the most part, these systems have been developed independently of CAD. These systems have attempted to incorporate design knowledge obtained from experts or handbooks into computer programs for

174 Vol 10 No 3 July 1989

Oeor,B ~ Outlxff geor; Idler C

/ I \ , / !

N=600 rpm ~ - ~

Teeth • 12 Dio • ? Hp= 2

(a) Kinematic representation (b) System force analysis

Aclual Form-~ ,7~\ X { '

I

(C) Tooth form: structural representation

\

(d) Structural representation of one gear

\

×

t

(e) Structural representation of one arm

(f) Assembly representation (partial)

Figure 5. Representation of gear train at different levels of abstract~n. ( a ) Kinematic representation. (b ) System force analysis. ( c ) Tooth form structural representation. (d) Structural representation of one gear. (e) Structural representat~n of one arm. OO Assembly representation

aiding or automating design. Most knowledge is in the form of heuristics coded as if-then rules. These systems are designed such that the knowledge base is kept separate from the inference engine.

Several research systems have been implemented. For example, Shah 18'19 created a system for synthesis of simple planar structures limited to three supports and point loads; Dixon 2° reported a system for V-beh design, Vaghul zl for injection moulding parts, Kulkarni z2 for design of heat fins, Zarefar 23 for gear drives, Soni 24 for

selection of mechanisms, Brown 25 for air cylinder design, and there are many others. As evident, most expert systems targeted Class III problems, i.e the configuration was predefmed, only the components had to be sized up.

In the last two years the trend has been toward the development of generic systems for Class III problems. Two systems need special mention. DOMINIC I z6 is a system for iterative redesign in a domain independent manner. Another system developed with a commercial shell called KEE (Intel l iCorp) is reported by

Vol 10 No 3 July 1989 175

Objective

Create plans for device/part that can perform function to specifications without violating constraints

Vocabulary Drawings

Problem ~ Mixture of text, algebra, geometry ~ and/or non- definition graphics and symbols involving graphics specs

form, pi'ecision, material, technological parameters

Reasoning process

Mixture of heuristic reasoning, mathematical computations, geometric arrangement, comparisons, selection, iterative modifications

Figure 6. Application of conceptual model to engineering design

Ramachandran 27. It allows incorporation of four kinds of knowledge: initialization method, selection of critical goal, dependencies between variables and control. Both systems search for solutions by varying one parameter at a time but the selection method for this parameter is different. These systems can be set up for most Class III problems but a solution is not guaranteed.

A few systems have targeted Class IV design. For example, Meunier 2s discusses a generic model for mechanical system design. However, the method presupposes the existence of an initial system configuration with only the system variables remaining to be determined. A new component cannot be added or dropped from the system as part of the automated decision-making process.

A commercial shell called ICAD* is also available for building expert systems for design; it provides some primitive geometry definition for visual displays but the geometric models are unevaluated (intersections and Boolean operations are not available). Thus we see that the current generation of expert systems are also not suitable for most design tasks.

I N T E R A C T I O N S B E T W E E N E N G I N E E R I N G T A S K S

In an integrated system, different tasks interact by exchanging information. Just as task automation requires a model that characterizes the task, so also integration of various tasks requires a model of the interaction between them. Integration is beneficial not only for efficient

* ICAD is a product of ICAD Inc, Cambridge, MA, USA

Detailed nominal geometry

F ~ 7 .

Objective

To build a mathematical representation of nominal geometry

Vocabulary

Primitive volumes, geometric entities, graphic images, topological entities

Functions/operators

Boolean operators, sweeps, lofting, shaping and tweaking geometric entities view and display variations

Application of conceptual model to CAD

Geometric model

Table 1. Classification of interaction finks

Abstraction Phase class transformation class

Initial input link (il) Intermediate input link 02) Intermediate output link (ol) Final output link (02) Feedback link (re)

Decomposition link (D) Reconstruction link (R) Mapping link (M) Extraction link (E)

information transfer and elimination of redundant effort, it is also a must for global optimization of product design and manufacturing.

In an attempt to characterize the interaction, we will classify information transfer links on the basis of: (a) the phase of the process at which the information is intro- duced or output; and (b) the change in information abstraction level. This is done in Table I; symbols that will be used subsequently are shown in parentheses. The difference between initial and intermediate input is that the former is process independent but the latter is not, i.e it is only needed if the process proceeds a certain way. Output and feedback links are self-explanatory.

The explanation for abstraction transformation links is as follows. If information transfer is from a task that operates at a higher level of abstraction to one at a lower level it implies a decomposition. The reverse of this situation will require construction of higher level information from a lower level and is labelled here as a reconstruction link. Mapping is required when product data are represented in a different form but at the same level of abstraction. Extraction involves searching and obtaining specific pieces of information from a larger database.

Why is it important to understand these characteristics of links? Because we must know when, where, and in what form information required by a program will be available. Also, a mismatch in levels of abstraction means either that some information will be lost in decomposition or that the desired information cannot be obtained at all by reconstruction.

The example illustrated in Figure 8 is given to help understand the physical meaning of some of the terms used in our link classification system. When a designer interacts with a solid modeller, there is a mismatch in the abstraction level, because the solid modeller does not support form features, precision and technological features. Consequently, this information is lost; this link is shown as a D-type. The solid model cannot be used directly by process planning and requires considerable interaction for tasks such as NC. Many applications are not possible at all. Thus, a design modelling system is needed that will be capable of preserving the design

NC programmer

(~) 12

02 NC 11.12 NC program "~"~-)program Designer ( ) generator ®

Figure 8. Interaction links in contemporary CAD-CAM

176 DESIGN STUDIES

information available to the designer. Many automated applications are possible on the resulting database.

FUNCTIONAL REQUIREMENTS OF CAX T O O L S Information sets

The analysis of various engineering tasks in previous sections demonstrated that there are several sets of parameters used at different stages in task execution. For convenience we define a feature as a set of information related to some aspect of the product, such as its geometry or manufacturing, etc. Some of the features that we identified from our analysis are:

• Form features = nominal geometry o functional o aesthetic o assembly aids

• Assembly features = relationships between components of assemblies o fits o orientation o kinematic relations o mating surface pairs

• Material features = material composition and condi- tion o properties/specs o treatment

• Precision features = allowable deviations from nominal geometry o dimensional, form, geometric tolerances o surface finish

• Technological features = information related to part performance o performance parameters o operating variables o design constraints

It is obvious that all features that form part of a task's vocabulary must be supported by the CAX tool.

The first generation of feature based systems is already on the market: Pro-Engineer1- supports form features and Cimplex~ supports both form and precision features. But these systems lack the functions, visualization op- tions and inference mechanisms needed for design.

Abstraction level

Engineers operate at varying levels of abstraction; this allows them to focus on relevant information to prepare global strategy/plan while filtering out unnecessary information. Many individual parameters can be combined to create abstracted representations. For example, a

t Pro-Engineer is a product of Parametric Technologies, MA, USA :~ Cimplex is a product of Automation Technology Products (ATP), CA, USA

process planner needs to know if a part is generally rotational. This requires the determination of a parts envelope using only the major form features and filtering out all information related to minor ones. Relationships between these features and their juxtaposition must be known. This requires an abstracted representation of the part. On the other hand, if NC code was to be generated all details of the parts geometry will have to be taken into account. Thus, it is not sufficient simply to support all information set types but also to provide a multi-tiered database representing different levels of abstraction. For example, in a form feature modeUer the top level can be feature relationship graph, followed by feature property lists and instance data, then a global or CSG solid model, and the last level being the evaluated active boundaries of the object.

Visualization needs

It was observed earlier that engineers use many languages in the conduct of their tasks. This includes heuristics, algebra, computational techniques, symbolic manipula- tion and graphics. The graphic used does not always represent the actual geometry, as illustrated in Figure 4. If a CAX tool is to be designed for aiding in product development rather than just documentation, some mechanism must be found for these types of representations and for creating appopriate links between the different types of representations.

Functions/operators

CAD tools must provide operators corresponding to microscopic actions identified earlier and macroscopic combinations of these to support the reasoning process.

Inference mechanism

The needs for Class I and II design are not clear at this time and further studies in cognitive science are needed to understand fully this activity. Methods need to be developed to combine expert system techniques for Class III and IV, to enhance the search methods and to integrate these with conventional CAD.

REFERENCES

1 Asimow, M Introduction to design Prentice-Hall, Engle- wood Cliffs (1962)

2 Glegg, G The design of design Cambridge University Press, New York (1969)

3 Love, S Planning and creating successful engineering designs Van Nostrand (1980)

4 Ostrofsky, B Design, planning and development methodology Prentice-Hall, Englewood Cliffs (1977)

5 Pahl, G and Beitz, W Konstruktionslehre Vol 2, Springer- Verlag (1986)

6 Dieter, G Engineering Design McGraw-Hill (1983) 7 Eastman, C 'Explorations of the cognitive processes in

design', Doctoral dissertation Carnegie Mellon University (1968)

Vol 10 No 3 July 1989 177

8 Newell, A and Simon, H Human problem solving Prentice- Hall, Englewood Cliffs (1972)

9 Fiaeh, J 'Cognitive Engineering Science' Frontiers in Education Conference Rose Hulman Institute, Indiana (October 1987)

10 Spillers, W and Newsome, S 'The development of design theory' NSF workshop on features UCLA (February 1988)

I1 Ullman, D and Dietterich, T 'Mechnical design methodology: implications on future developments of CAD and KBS Engineering with Computers Vol 2 (1987) pp 21-29

12 Tikerpuu, J and Ullman, D 'General feature based frame representation for describing mechanical engineering design developed from empirical data' ASME Computers in Engineering Conference San Francisco (1988)

13 Alexander Notes on the synthesis of form Harvard University Press, Cambridge (1968)

14 Rinderle, J 'Implications of function-form-fabrication relations in design decomposition strategies' ASME Com- puters in Engineering Conference Chicago (1986)

15 Waldron, M and Waldron, K 'Position paper on conceptual CAD tools for Mechanical Engineering' ASME Com- puters in Engineering Conference San Francisco (1988)

16 Marples, D 'The decisions of engineering design' Eng. Design (December 1960) pp 1-16

17 Moray, N 'A lattice theory of mental models of complex systems' EPRL report 388-08 University of Illinois, Urbana (1988)

18 Shah, J 'Development of a KB for an Expert System for Design of Structural Ports' ASME Computers in Engineer- ing Conference (1985)

19 Shah, J and Pandit, L 'DEZINER--An expert system for conceptual form design of structural parts' ASME Compu- ters in Engineering Conference Chicago (1986)

20 Dixon, J R and Simmons, M K 'Expert systems for

engineering design: standard V-belt drive design as an example of the design-evaluate-redesign architecture' ASME Computers in Engineering Conference Las Vegas (1984)

21 Vaghul, M, Dixon, J and Zinsmeister, G 'Expert systems in a CAD environment: Injection molding part design as an example' ASME Computers in Engineering Conference (1985)

22 Kulkarni, V, Dixon, J, Sutherland, J and Simmons, M 'Expert systems for design: the design of heat fins as an example of conflicting sub-goals. . . ' ASME Computers in Engineering Conference (1985)

23 Zarefar, H, Lawley, T and Etesami, F 'PAGES: a Parallel Axis Gear Drive Expert System' ASME Computers in Engineering Conference Chicago (1986)

24 Soni, A, Weng, Y and Dade, M 'An intelligent mechanism selection consultant' ASME Computers in Engineering Conference Chicago (1986)

25 Brown, D and Chandrasekran, B 'An approach to expert systems for mechanical design--a progress report' ASME Computers in Engineering Conference, Las Vegas (1984)

26 Dixon, J, Howe, J, Cohen P, and Simmons, M 'Dominic I Progress toward domain independence by iteration redesign' ASME Computers in Engineering Conference Chi- cago (1986)

27 Ramaehandran, N, Shah, A and Langrana, N 'Expert system approach in design of mechanical components' ASME Computers in Engineering Conference San Francisco (1988)

28 Meunier, K and Dixon, J 'Iterative respecification: a computational model for hierarchical mechanical system design' ASME Computers in Engineering Conference San Francisco (1988)

178 DESIGN STUDIES

analysis of design abstraction, representation and inferencing requirements for computer-aided...

Documents