Engineering Design: Representation and Reasoning

---

He has published Design Problem Solving: Knowledge Structures and Control Strategies, co-authored with B. From to , he was the Editor in Chief of Artificial Intelligence for Engineering Design, Analysis and Manufacturing and has been on the editorial boards of Concurrent Engineering: The authors believe that symbolic representation, and related problem-solving methods, offer significant opportunities to clarify and articulate concepts of design to lay Cambridge University Press Bolero Ozon.

Dym , David C. Contrary to a lot of popular mythology, the designs of popular products and successful systems do not appear suddenly, or magically. The authors believe that symbolic representation, and related problem-solving methods, offer significant opportunities to clarify and articulate concepts of design to lay a better framework for design research and design education.

Artificial Intelligence AI provides a substantial body of material concerned with understanding and modeling cognitive processes. This book adopts the vocabulary and paradigms of AI to enhance the presentation and explanation of design. It is sufficiently abstract that it does cover the examples we have already discussed, but not nearly in enough detail to advise us on how to proceed with a design. We cite one obvious question, How do we generate designs? One of the most widely cited models of the design process is displayed in Figure 3. In this model, the circles usually represent some form of description of the evolving design, although they sometimes represent a stage e.

As in our structural engineering example, we begin with a stated need, which first is elaborated through a process of questioning the client and gathering relevant data, until we arrive at a clear statement of the problem. Then we enter the conceptual design stage, in which we look for different concepts or schemes that can be used to solve the stated design problem.

In a bridge design, for example, our different schemes might be represented by different bridge types, say a 23 3. A pictorial view of the design process French, Selected scheme s Embodiment of scheme s Detailing Working drawings, etc. Our assessment of these three schemes would depend on some of the high-level attributes of our design goal, including the anticipated span length, financing, type of traffic, and aesthetic values of the client. The conceptual design stage is the most open-ended part of the design process: Thus, it is here that we are most likely to see negotiation among participants who have very diverse interests in order to resolve performance goals and other trade-offs.

At this stage, we probably focus more strongly on the function of the artifact than we do on its form — notwithstanding the bridge schemes just cited — except to the extent that all the participants in the design process see the artifact as a variation on a known theme or a mutation of a familiar artifact or design. In conceptual design, too, we cannot predict how subsystems will interact, which subgoals might conflict, which options may have to be ruled out because of local conditions, and so on, because we have not yet refined our design very much.

Again, for the bridge design, the nature of the gap being spanned e. The output of the conceptual-design stage is a set of possible concepts or schemes for the design. French defined a scheme as: By a scheme is meant an outline solution to a design problem, carried to a point where the means of performing each major function has been fixed, as have the spatial and structural relationships of the principal components.

A scheme should have been sufficiently worked out in detail for it to be possible to supply approximate costs, weights and overall dimensions, and the feasibility should have been assured as far as circumstances allow. A scheme should be relatively explicit about special features or components but need not go into much detail over established practice. In the structural design problem in Section 1. For the ladder, we might have a wooden stepladder as our scheme. Note that although we have identified only one scheme in each of these two examples, the output of the conceptual stage could be two or more competing schemes.

Engineering design : representation and reasoning

In fact, some would argue that the output of the conceptual stage should be two or more schemes because early attachment to a single design choice is viewed as a mistake. This tendency is so well known among designers that it has produced the aphorism: For example, we may still be entertaining the notion that the stepladder be made of either wood or aluminum or perhaps some more exotic material.

The next phase of the design process is called, variously, the embodiment of schemes and preliminary design. In this phase, we begin to select and size the major subsystems based on lower-level concerns that include the performance specifications and the operating requirements. For the ladder, for example, we would begin to size the side rails and the steps, and 3. In the mill-building example, we would lay out the roof truss in greater detail, including locating the roof purlins, estimating the size of the truss-joint connections, and so on. In preparing such a preliminary design, we might well use various estimates or backof-the-envelope calculations and algorithms as well as rules about size, efficiency, and so on.

And, in this phase of the design, we make a final choice from among our candidate schemes. Here, our concern shifts to refining the choices made in the preliminary design; our early choices are articulated in much greater detail, typically down to specific part types and dimensions. This phase of design is quite procedural in nature, and the procedures themselves are well known to us.

Engineering design : representation and reasoning - PDF Free Download

Much of the relevant knowledge is expressed in very specific rules as well as in formulas, handbooks, algorithms, databases, and catalogs. As a result, detailed design has benefited greatly from attempts to encode accessible databases within CADD tools. This stage has also become rather decentralized; that is, it is left almost completely to component specialists as the design moves much closer to being assembled from a library of standard pieces.

The final stage illustrated in Figure 3. However, we should note that although this model of the process is more detailed than the simple one we discussed at the beginning of this section, we are not much closer to knowing how to do a design. Both of the process outlines we have given are descriptive; that is, they describe what is being done rather than detailing what ought to be done. These models differ from the two descriptions given in Section 3. In the two descriptive models of the design process that we have just seen, we can recognize within them three generic tasks that are repeatedly performed, usually in an iterative fashion, within each phase of the design process.

These three tasks are: Synthesis is the task of assembling a set of primitive design elements or partial designs into one or more configurations that clearly and obviously satisfy a few key objectives and constraints. Synthesis is often considered as the task most emblematic of the design process. Analysis is the task of performing those calculations or analyses needed to assess the behavior of the current synthesis — or embodiment or preliminary design. For example, we calculate the bending stress and deflection of a loaded step of the ladder to see how the step behaves under a given set of loads.

We are doing the evaluation task when we compare our analyses of the attributes and behavior of the current design to the stated design specifications and constraints to see if this synthesis is acceptable. These task descriptions do provide a general statement about what we are actually doing when we design an artifact, but they are still fairly general.

The analytical phase of the design process involves two activities: In the programming activity, we identify those issues that are crucial in the design, in a manner very much akin to our earlier suggestions cf. Here, too, a plan is proposed for completing the design process, perhaps through the construction of a schedule of milestones and deliverables for the design project. The second activity we perform in the analytical phase is data collection, in which we collect and collate as much relevant data as possible and perhaps organize it into a design database that will be the data source for the duration of the design project.

The creative phase of the design process involves three activities: Analysis is the first activity in the creative phase. Here, in this very sary, our project schedule; and prepare a budget abstract prescriptive model, we use the term only for the design process. Development of the candidate designs is the final creative task. It includes both the evaluation of alternative conceptual designs and the preparation of preliminary designs or prototypes. The executive phase of the design process involves only one activity: This final activity, communication, is akin to the task of documenting the final manufacturing or fabrication specifications.

However, the middle stage, the creative phase, is a sort of puzzle. On the one hand, according to the description, the creative task depends on the application of analysis and logic. On the other hand, this stage also requires the exercise of subjective judgment and personal involvement in developing schemes or concepts. In truth, it is this part of the design process that is the most difficult to model or represent. Even in the clearest books on design, this phase is discussed only in very general descriptive terms; the design methods described are, in fact, only design aids that are intended to help us be creative and to cast as wide a net as possible.

However, as we have noted before, the boundaries between what we can and cannot now model are not static, so we should not be deterred by the apparent thickness of the creative filling in this design sandwich. Designers and scholars in Germany have put forward a more detailed set of prescriptions that reflect an attempt to systematize and formalize the design process. Two such models are displayed in Figures 3. The first reflects four stages, each of which consists of several tasks and produces specific outputs.

The clarification phase has as its output a design specification. This goal is achieved by clarifying the task presented by the client and elaborating a specification in sufficient detail so as to define a specific target toward which we can aim our design effort and against which we can, eventually, measure our success. The conceptual design phase has as its output a concept. This goal is achieved by identifying the most crucial or essential problems; establishing a function structure — that is, a framework within which the artifact will perform its primary function, including a decomposition of the primary function into subfunctions that will be performed by subsystems or individual components; formulating a solution procedure that can be successfully applied to the design problem; preparing concepts or skeleton designs or schemes; and evaluating candidate schemes against the relevant criteria, including both economic and technical metrics.

The embodiment design phase of the design process actually has two stages, the first of which has as its goal the production of a preliminary layout and the second of which has as its output a definitive layout. The preliminary layout is obtained by refining the conceptual designs, evaluating and ranking them against the design specifications, and choosing the best as the preliminary design. The definitive layout, the final output of the embodiment phase, is obtained by optimizing the preliminary design and by preparing preliminary parts lists and fabrication specifications.

A prescriptive model of the design process Pahl and Beitz, The design process as outlined in VDI— The detailed design phase, the final stage of the design process, has as its output the documentation of the designed artifact. This goal is achieved by checking our results and documenting our design in final manufacturing or fabrication specifications. This model, the most elaborate of those presented thus far, is still not the most complex. One of these guidelines refines the process into seven stages cf.

It is based on a set of models of five stages liability for a product design or for assuring in a design process. The inputs to any one stage conformance with some institutional design are dealt with by a set of stage-specific design approach. These depiction adds much to our understanding of the tions are not intended to imply a strict linear prodesign process.

At the heart of the matter cess that is entirely without iteration, as Dym et al. Despite allowing backseparate tasks done within each phase of the ward loops in the process, prescriptive models tend design process. We can model some design to suggest that designing is a sequential process tasks — for example, evaluation of a scheme that moves in steps from abstract to concrete.

In this light, it is particularly interesting to describe two information-processing models of design. The first such model we discuss is called the task-episode accumulation or TEA model. The design state incorporates all the information about a design as it evolves. The most important parts of the design state are 1 proposals for achieving design goals, and 2 constraints that the design must meet e. The design operators are primitive information processes that modify the design state as various design tasks Figure 3. Elaboration of the design process that characterizes stages in terms of their inputs, tasks performed, and outputs Dym et al.

A map of the design environment Ullman, Wood, and Craig, Some of the 10 operators developed in the TEA model are select, create, simulate, calculate, and so on. We can subdiuation, patching, planning, and selection.

5 editions of this work

This difvide the internal storage locations according ference may be due in part to the fact that TEA to whether they provide short-term memis intended to be an information-processing model, ory STM or long-term memory LTM. We ful computational models. Access to STM, for example, is very quick, but its capacity is very small. Cognitive studies seem to show that only seven chunks or meaningful units of information can be stored in STM at any instant, and that the chunks of experts are usually larger than those of novices.

Conversely, LTM has an essentially unbounded capacity but the access time is fairly long, on the order of 2 to 10 seconds per chunk. Preface and Section 1. We do not intend to go into further detail about the TEA model, in part because its authors view it as emerging and still under development, and in part because some of its details underlie a design taxonomy that we discuss in Section 4.

In that taxonomy, we articulate the design state, at various levels of abstraction, and the roles of some of the operators in greater detail. It is interesting to note, however, that this model has emerged from a conscious attempt to extend cognitive psychology models into the design domain. In the second information-processing model, design tasks are proposed and analyzed in terms of the information they use.

We note two basic sets of processes in this approach. The first set of processes propose design choices. The second set is a collection of auxiliary processes that provide information in support of generating or testing a design choice or commitment. As we delineate these two sets of processes, we introduce more of the terminology common to AI-based research in design problem solving see Chapter 6: There are four basic information processes that propose design commitments — that is, processes that generate design choices or make commitments about specific aspects of a design.

A basic and often-used approach to design is the decomposition or reduction of a problem into a set of smaller problems. We thus intend to solve the overall design problem by solving subproblems for which we have previously compiled or known solutions or that require searches of much smaller solution spaces. We can also view design as a process of design planning — that is, of formulating a plan of steps that need to be taken to produce the fabrication specifications for a designed artifact. The steps in the plan could be set out as goals to be achieved or in terms of the parts or components of the artifact.

In the process of design modification, we explicitly recognize the existence of previous designs that we can modify to meet our current design needs. We do need criteria for choosing designs that are close to the current problem, and it would be helpful to know why an old design fails to meet current goals and what must be modified so that we can adapt an old design. Such CBR systems can repair failed plans and build up a set of features that can be used to predict problems Hammond Constraint processing or manipulation can be a useful tool for design when the structure of the artifact is known and the design process can be reduced to selecting values for variables and parameters.

There are four basic types of information processing that provide auxiliary information — that is, information in support of generating or testing a design choice. The task of translating high-level goals and constraints into more detailed versions appropriate to the subproblems is generally very difficult to execute: This is particularly difficult, for example, with constraints on parameters that are accumulative. For example, if x is composed of a and b, and x must be less than 10 inches, then it is difficult to be more precise about either a or b. Such conjunctive goals are very difficult to deal with while designing, or repairing failing designs, due to the inherent dependencies.

The process of generating goals and constraints for subproblems is very important as we translate high-level goals and constraints into more detailed versions appropriate to the subproblems of the original decomposition. Much of the information required here is about how the pieces fit together. Design verification is that part of the design cycle in which we test our solution to verify that it meets all goals and constraints. Design criticism is information used to analyze failures, identify their causes, and suggest modifications to fix them. In closing this brief overview of information-processing models of design, it is worth noting that the auxiliary information processes are fairly typical problemsolving skills that can be invoked equally well to solve analysis problems; that is, they are not unique to design.

The processes involved in generating design choices, conversely, are relatively specialized toward design, where the idea is to create either an artifact or the specifications for an artifact. It is thus not surprising that the modeling of these design processes has become a fertile branch of research for the AI community, in large part driven by the recognition that algorithmic processes — suited as they are to aspects of evaluation, verification, optimization, and documentation — are simply inadequate in terms of providing the information needed to generate designs.

There is significant overlap among these process descriptions, the 3. This merely reflects the complexity of the design concerns that come into play in analyzing the design process. We have also noted that these process descriptions often fail us because they do not tell us how to go about the business of generating or creating designs. Although we can be rather specific — to the point of being algorithmic — about some aspects of the design process, we have a difficult time with design generation.

We address this point in greater detail in Chapter 6 but, having pointed out so often the limitations of these process descriptions, it seems worthwhile to introduce here some more traditional, inductive design methods, casting them in terms of the AI-based problem-solving methods that are discussed in much greater depth in Chapter 6. As a context for this discussion, we use the process description paralleling that shown in Figure 3.

One method used to clarify the original project statement is the construction of an objectives tree. Here, we make a hierarchical list — which actually branches out into a tree-like structure — in which all of the objectives that the design must serve Means-ends analysis MEA is a technique for reare ordered by degree of specificity. Then, ducing a problem by mapping a difference to an starting at the highest level of abstraction, action or actions that should help reduce that differwe have our top-level design goal, which is ence.

As we move rent state and some desired state e. MEA is thought of as recursive; that objectives, we find that we are generating is, reduced differences may need to be further the means by which the design will perform reduced. Thus, this method is related to a general problem-solving technique called means-ends analysis. Because the space is likely to be both large and complex, we do not want to look for solutions in an ad hoc fashion because we may miss good soluThe standard functional terms in the functional tions or, at best, take a very long time to basis Hirtz et al.

One method often proposed for hierarchy of different levels, thus providing supgenerating conceptual designs or schemes is port for refinement and perhaps for decompofunctional decomposition. Decomposition typically requires reasonthis method is to decompose the primary ing, but CBR can be used. Decompositions can function that the design is intended to perresult in subfunctions that are either indepenform into subfunctions, which in turn are dent of order or dependent on some behavior decomposed until some level is reached in that is part of another subfunction Erden et al.

Another general approach, particularly for conceptual design, is to follow a strategy of least commitment — that is, to make as few commitments as possible to any particular configuration because the data available are perhaps too abstract or very uncertain at this point in the design process. Or, it may be that the data are simply not available so early in the process. Least commitment is less a specific method than a strategy or a good habit of thought. It militates against making decisions before there is a reason to make them.

As a choices made at the conceptual design stage. However, every commitment we propagated far down the line.

Refine your editions:

In preliminary design, we are concerned with generating candidate solutions and then with either testing them to ensure conformance with design objectives and applicable constraints or evaluating them against metrics — for example, cost — that support a choice among otherwise adequate designs. One common reasoning strategy is generate and test, in which we devise a generating strategy that automatically generates large numbers of potential designs that are then tested against the relevant metrics and constraints. With this strategy, however, we must guard against a combinatorial explosion of the space of candidate designs in which we are simply overwhelmed by the number of possible designs that emerge as a consequence of different combinations of the design variables.

Often, having generated a solution that fails to meet a specified test, we want to redirect our search for a solution so as to fix the failure. In particular, in detailed or final design, we can often identify the decision s that precipitated a failure. In such cases, we can formally apply a problem-solving approach called backtracking to remedy the problem by undoing the decision s that caused the failure. This requires that we explicitly articulate the dependencies or links beween design decisions and the values of the artifact attributes that result from those 3.

This brings us closer to explaining how we actually go about designing artifacts, and it sets the stage for articulating a taxonomy of design tasks, as we do next. When constraints fail, VT uses the dependency record to guide knowledge-based backtracking to undo the decision that caused the failure. This approach does not systematically undo the last decision made each time because it is a waste of time if that decision was not the actual cause of the problem. The dependency record can also be used to discover how many subsequent decisions such a change might affect.

Other AIbased systems use implicit or explicit dependencies in a similar way. Models of the design process were proposed by Cross and French Constraint posting and propagation are included in , Constraints can term schemes for conceptual design. The be determined and then attached i. The pithy result e. The tasks of design are outevidence has been gathered such that the result lined in Asimow , Dym and Levitt is clear. It can take a constraint on an output of a plan model of design was originated in Archer action and reason about what must have been con and reviewed in Cross The ultimate a German approach to systematizing design type of constraint is a value e.

It is based on models of information-processing psychology developed in Newell and Simon and Stauffer Another information-processing model of design was developed by Brown and Chandrasekaran and is described in reasonable detail in Dym and Levitt a. Traditional methods for design e. Means—ends analysis as a problem-solving style is propounded in Newell and Simon , In so doing, we have identified some of the ways that problem-solving strategies could be employed in the design process. Now we turn to the task of trying to outline an organizational structure or taxonomy for design.

Are such taxonomies important? One viewpoint is that a scientific theory of design cannot be developed without such a taxonomy. Another is that such taxonomies allow us to compare design methods and design tools — especially those reflecting the newer computer-aided technologies the ideas of which are reflected in this discussion.

Our own viewpoint is stated somewhat differently in that we would stress any increase in our ability to understand and model the thought processes involved in design as being the best reason for developing such taxonomies. As we work toward this objective, we will simultaneously increase our abilities to compare various design tools and to develop and explore new design methods. We note also that, as with our characterizations of the design process, various taxonomies and classifications have been proposed, and there is certainly some overlap of ideas among them.

After we review these various taxonomies, in an order roughly corresponding to their chronological development, we will try to analyze in a principled way what we have learned from so describing the thought processes of design. Similarly, past experience helps us learn how to assemble and organize independent parts to achieve a desired overall behavior.

Such cases — in which we have a lot of the knowledge about parts, components, systems, and their functions — involve relatively routine design in which the problem-solving task is largely a process of matching requirements to previous attempts at meeting the same set of requirements. Oftentimes, however, the design goal is a device that is quite different from previous designs, or the number of alternatives that must be considered is very large, or the desired artifact is completely new.

In such cases, the design activity is more complicated: In some cases, the space of possible designs may not be easily or well defined. Therefore, any attempt to generate and test all possible designs would require a prohibitively large effort, so we need powerful ways to search through a large, complex space of possible designs.

We would expect in such situations that the knowledge obtained either from experience or from a deeper understanding of the domain plays an essential role in guiding our search for plausible design alternatives. Obviously, we may also use such knowledge to modify a design if some of our design choices turn out to be undesirable. The foregoing discussion suggests that we can characterize the type of design we may be facing in accordance with an assessment of the knowledge we have about the design domain and of the strategy we will use to solve the particular design problem at hand.

The knowledge assessment depends on how complete is the knowledge we use to generate designs — especially with regard to the degree of specificity we can attach to the form, goals, and constraints governing our design problem — and how complete is our store of additional or auxiliary knowledge that we require to test possible designs. The second significant factor for assessing design complexity has to do with how difficult it is to control the problem-solving process we use to search the space of possible solutions. This is because identifying a design as creative renders a judgment on that design, relative to personal or group norms Boden Thus, as strange as it may seem, being creative probably depends as much on who is making the judgment as on the design process itself: Highly nonroutine design is characterized by not knowing how to proceed and by a lack of immediately available appropriate knowledge.

This situation typically requires new activity that requires problem solving and much less reliance on existing methods. This classification is more or less equivalent to assessing how difficult it is to generate candidate designs. Specifically, then, three classes of design are identified in this taxonomy: Also known as creative design. Creative design is rare in that it usually leads to completely new products or inventions. It is typically characterized by a lack of both domain knowledge and problem-solving strategy knowledge. Here, the goals are vague, and we are short both of ways to effectively decompose problems and of designs for the subproblems.

This kind of design requires considerable problem solving even in its auxiliary processes. It is original, rare, and almost certainly not susceptible to encapsulation with current representation technologies — probably because we do not understand the origins or form of true creativity. The distinguishing mark of such design, sometimes called variant design, is that we know a lot about the design domain; that is, we understand the sources of our design knowledge but we lack a complete understanding of how that knowledge should be applied.

Thus, although we may be able to successfully decompose a design task into a number of subproblems of component design, it is the modification or replacement of the individual components that makes the design difficult to complete. The continuous revisions in automobile design that we have seen in the last several years provide a classic example of this.

Automobile basics are still very much the same, but the individual components are certainly quite different — and much more complex — than their counterparts of even a decade ago. Thus, although automobiles still have engines, transmission systems, and wheels, the subsystems that operate and connect them are much more sophisticated and complicated than they were only a few years ago. More recently, the intermediate class of designs — between creative design and routine design — has been termed innovative design, although the emphasis in this definition varies somewhat.

One view is as just expressed; that is, in innovative design, we lack a clear-cut problem-solving strategy. A second view is that innovative design perforce hinges on the application of reasoning from first principles — that is, from the fundamental physical equations and concepts used by engineers. The two views can be said to converge if we assume that the domain knowledge we know consists of the fundamental physical knowledge, whereas the problem-solving strategy we lack is the knowledge of how, where, and when we should apply this fundamental knowledge.

In routine design, we typically know in advance everything we need to know to complete a design. That is, we can identify the specific design or domain knowledge we need to complete the design or, we know the sources of that design knowledge and we know how to apply that knowledge. Thus, we typically would have effective ways to decompose design problems, well-understood and efficient compiled plans for designing components, and fairly complete information about the possible causes of design failures that can be appropriately applied during the design process.

However, if we make the description less abstract by adding more classes and details, then we are less likely to match every example of design: This, by the way, is one reason that algorithmic and decision-based models of design are limited in their ability to portray the entire scope of the design activity. Thus, it seems that there is always some sort of difficulty when describing design! Note that the three classes in the Brown and Chandrasekaran model are not distinct: In addition, it is important to recognize that any characterization of design activity applies only to a portion of the whole because each subproblem itself and its subproblems in turn might be Class 1, 2, or 3; that is, each subproblem might be more or less routine.

It is better to characterize the situation at any single point in time during design Brown because the situation can vary as the designer switches from subproblem to subproblem, recognizes what knowledge is appropriate, reasons out a plan to tackle some design subproblem, retraces steps after failing, and so on.

Thus, even in the simplest class of routine design, there is more than ample scope for the intelligent deployment of design knowledge. This taxonomy is interesting and suggestive but, unfortunately, its simplicity is limiting — the three classes of design do not appear to carry enough distinctive detail to be helpful for characterizing the wide variety of activies that fall under the rubric of design.

Routineness is thus a relative measure. What is routine for one designer may not be for another. Furthermore, given that designers appear to learn a great deal from experience, a problem that seemed difficult two years ago may now be seen as routine by any given designer. The expectation also may derive in part from the current state of design education if, for example, the specific domain knowledge and problem-solving strategy for solving a particular design problem or class of problems are generally taught in design courses.

Clearly, the community standard for a particular design problem is represented by the pool of existing design solutions. Thus, design problems are innovative in context, not in and of themselves, so we should be cautious about labeling innovative design. Similar reservations could be expressed about the term variant. In some of the literature, it has been used to describe Class 2 designs as we have just done.

In process planning, the term variant has been used to describe the process of choosing a plan from among a set of standard plans. Similarly, in design, the term could be taken to mean producing designs by varying prototypical designs. This describes how a design is produced but makes no judgment about its quality, originality, or routineness. If we were to think of variant designs being produced as a result of changing parameter values only, without changes in function features, form features, or topology, we would probably not classify these problems as innovative.

Finally, and as noted previously, routine design is still often sufficiently complex — and difficult to model computationally — that most KBES design applications have reflected attempts to provide advice for carrying out Class 3 routine design tasks. Some of these applications are described in Chapters 5 and 6, but first we move on to describe other design taxonomies.

This argument contends that an identifiable design process exists only in a fairly abstract way, as we have seen in Chapter 3, and that there are many different design processes that are carried out operationally, depending on the particular design problem, the designers involved, and the environment in which the design is done. Thus, design proceeds recursively through tasks and methods, with the selection of methods being context dependent. His analysis proposes that tasks can be of the type propose, verify, critique, or modify.

So, in a highly familiar situation, a propose subtask might be handled using case-based reasoning i. In a less familiar situation, a verify subtask might be done by simulation — for example, by verifying that a particular behavior occurs. This recursive model clearly explains the myriad possibilities for design activity. The state can be viewed as moving from knowing very abstract aspects to knowing very concrete aspects, such as particular parameter values.

This allows design to be defined as progressing from a more abstract state to a less abstract state. This progress can be viewed as being orthogonal to the degree of routineness: At the highest level of abstraction, a design problem is characterized here by the specification of two knowledge types: Once the initial and final states are specified, we will identify problem types as a function of the differences between the knowledge types of the two states. The seven mutually exclusive knowledge types used to define the two problem states are: This is the condition or need that provides the motivation for designing something.

Whereas perceived needs are often expressions of social or economic needs, engineering design is here limited to more refined, less abstract expressions of functional need. And, it should be noted, not all design problems begin at this abstract level; that is, many are stated at more refined or detailed levels. For our stepladder example cf. Chapters 1 and 3 , the perceived need could be that we want to provide a means to allow people to obtain access to heights exceeding their own, whereas the engineering-design version of the perceived need would be a statement of the need to provide the ability to support a given weight at a certain specified height.

In the taxonomy that we discuss in the next section, it is also noted that specifications are design requirements or goals that are based on the perceived need. Such design specifications may be based on functional performance or they may relate to other constraints, such as spatial constraints, manufacturing restrictions, cost, or applicable codes and standards.

This is the most detailed statement of the perceived need that can be made without reference to physical principles, form, or embodiment see the following discussion or specific artifact types. A function indicates what must be done without specifying how it is to be achieved. A functional requirement is a translation of the function into a detailed, quantitative, operational statement. For the stepladder, the functional requirements could state that among other things, each step should support a person weighing lubes and the weight of the ladder should not exceed 15 lubes.

This is a statement about the underlying physical principles that will be used to design the artifact, although this statement is done without reference to how these physical concepts will be displayed in the actual object. In the German literature, physical phenomena are called the working principles.

Thus, the stresses in a step that supports forces on the step might be restricted 4. This abstraction, although at times very convenient, may in fact inhibit thinking by short-circuiting the range of options being considered. Although not especially realistic for a ladder step, the statement given would allow us to design the step as a beam or as a truss, whereas we would ordinarily perhaps have just required the step to be a beam.

Concepts or embodiments represent a generalized form or shape based on the physical phenomena being developed to achieve a function. An artifact type represents a concept refined further, wherein the specific attribute types of the concept — although not their values — are detailed. Thus, the beam for the step might be specified as a thin plate or as an I-beam or perhaps as something else again, as long as the artifact type behaves like a beam.

Here, specific values are given for the artifact type, thus creating an instance of the artifact; in current jargon, we are instantiating the artifact. This is simply an assessment of whether a particular aspect of a design is deemed feasible. Then, the following two design-problem states are defined: The initial state of knowledge is one and only one of: A taxonomy of types of major design problems Dixon et al. Now, we need to remember that the complete specification of a knowledge state could, in fact, incorporate more than one of the six types relevant to it, depending on whether it is an initial or a final state.

However, when we define particular problem types, it is on the basis of a transformation from a single initial knowledge state to a single final knowledge state. With this in mind, Dixon and his colleagues propose a taxonomy of five major design problem types Figure 4. Problem types are identified according to the difference — which is normally a refinement — between discrete initial and final states of knowledge. For example, for preliminary and conceptual design and design feasibility, Preliminary Design: Thus, there is a strong association between parametric design and routine design.

Account Options

However, design is more likely to be routine when sequencing and decomposition knowledge exists in addition to decision-making knowledge. This can occur anywhere in the abstract-to-concrete spectrum. We will see in Sections 4. We could, for example, identify routine design as the following combination: An example of a knowledge state definition Dixon et al. Here, we could identify as routine design the process of choosing a concept or embodiment e.

Clearly, other choices could be made in the knowledge-state definitions that would lead to other design choices. For example, the phenomenon chosen could be bonding, in which case the embodiment would be a bonding agent, the artifact type could be a wood glue, and the artifact instance would be a particular type or brand of wood glue.

There are subclassifications of this top-level design taxonomy; for example, we could refine an artifact type as the specification of a physical type, an assessment type, and a complexity or coupling. We do not need such detail at this point, so we close by noting that the taxonomy presented in this section focuses on classifying aspects of the design problem, as distinct from the design process that entails both the people involved e. The particular focus of this work is to enable not only the formalization of design methods and theory but also the comparison of design tools, especially the more recent computer-aided design environments that are beginning to appear as commercial products.

Furthermore, this taxonomy is set in the context of the TEA design-process model discussed in Section 3. It is thus relevant both to our continuing focus on the design thought process and as an elaboration of the TEA model. Ullman explicitly includes the design environment and the design process in his taxonomy, arguing that a complete taxonomy must encompass more than the defined artifact. There are three top-level components: Each of these components is further refined as shown in the table displayed in Figure 4.

The slots in the right column are filled in as various options are identified. A form for a generalized mechanical design taxonomy Ullman, a. The latter are chosen from the same list of six possible initial knowledge states used in the previous taxonomy and applied here to both initial and final knowledge states; that is, The initial state of knowledge and the final state of knowledge are each characterized by one and only one of: Four such representation languages are identified: We say more about the representation languages of design in Chapter 5.

Another addition to the problem definition is the identification of the criterion that must be satisfied to declare a design complete. We like to think of designs being 49 4. However, the state of the art of optimal design is such that it normally can be applied only when there is a clear-cut mathematical model of the design objectives. In reality, however, we are quite pleased if we can satisfice — that is, if we can find a design solution that is satisfactory when judged by reasonable, often nonquantitative, measures that are usually less restrictive than those applied in formal optimization.

Furthermore, there is empirical evidence that many designers work toward just such ends. Four components are identified as essential for characterizing a design: The refinements of these catof ways, from mere plan execution at one end of egories are displayed in Figure 4. Four different kinds of design duction to AI—based planning is found in Hendler planning are identified. Refinements of the design process Ullman, a.

These search methods can be weak or strong, depending on the degree to which domain knowledge is used to guide the search. Some kind of action must be taken to execute the design plans just identified. Design processes have three identifiable effects on designs: More abstract views which the design is modified in some way are used to recognize specific methods or general that does not reflect a true refinement, such strategies that might be useful or even to recognize as where a longer screw is substituted when previous designs in the same general category.

The fourth and final category in the classification of design processes is concerned with the handling of shortcomings or failures in the proposed design. There are two basic approaches to fixing failures. One is to stop the process and proceed to apply some external fix. The other approach is to go through some iterative process to fix the failure by changing the failed aspects through the application of predetermined strategies and failure-analysis knowledge. We see in this last dichotomy the role, albeit implicit, that the intended use of the taxonomy plays in its construction.

This notion clearly is related to the idea of using the taxonomy to compare such computer-aided design tools. We are now in a position to use this taxonomy to describe some of the more commonly used descriptions of the design process. In doing so, we follow the 4. The completed taxonomy form for conceptual design Ullman, a.

Thus, conceptual design is defined simply in terms of the problem alone without reference to either the design environment or the processes applied Figure 4. We see that the refinement level and the representation of both the initial and final states are, in fact, fairly abstract. Selection design is that process by which a designer selects one or more parts or components from a list e.

This particular design characterization is interesting also because it shows up in a task-oriented taxonomy that we describe in Section 4. In addition to presenting completed forms for other design processes e. In filling out the taxonomy forms for Class 3 design cf. The completed taxonomy form for selection design Ullman, a. However, the overall taxonomy Figure 4. The detail is what makes it interesting, but the taxonomy for the whole routine-design problem disguises that detail. However, this refinement is often a very difficult process, which is one of the reasons that detailed taxonomies may be useful for exploring and understanding design.

This taxonomy includes the selection of configurations — as well as components — and it includes as a major element the characterization of the search space in which a design solution eventually will be found. In each of its four categories, we apply a selection process to design components and configurations. However, note how the characterizations given here differ from those that appear in Figure 4.

Here, we choose a component from among a set of available components the number of which defines the search space.

Here, we choose values for parameters for a component in order to meet stated requirements, such as in V-belt drive design. The size of the search space is characterized by the number of parameters, which is typically small. The size of the search space, which may be quite big, is defined by the number of feasible combinations of the components.

One example of configuration selection is the configuring of VAX computers for assembly. Although standard definitions of the configuration task require a predefined set of components, those components may be fully or partially specified.

By varying the specificity of the components provided, the strength of the prescription of the desired configuration, and the nature of the requirements and constraints, it is possible to describe a variety of possible types of configuration design. There are eight major types, including verification i. Here, we organize a known set of components into an architecture that has not been defined in advance. This is the most complicated task in this taxonomy because both the components and the architecture in which they are placed may have to be designed rather than simply selected.

The number of parameters could be very large and their values may vary continuously or discretely, such as in the design of paper-handling subsystems in copiers. This pragmatic classification of selection design incorporates elements that are not captured in the taxonomy given in Figure 4. However, it is also slightly different because it suggests a different refinement of the processing actions or problemsolving strategies. We return to it in Chapter 6 because it will Brown suggests another view of configurbe helpful in identifying specific probleming: We establishing abstract relationships plus arranging will also see that in the descriptions of some establishing specific relationships plus evaluating of its constituent elements, this breakdown testing the compatibility of components and verifyincorporates problem-solving strategies in a ing that goals have been satisfied.

• A Dangerous Low (The Dangerous Low Series Book 1)
• The Accidental Mistress: A Rouge Regency Romance
• Lost & Found
• Elbenthal-Saga: Der schwarze Prinz: Band 2 (German Edition)
• Kingdom Thinkers
• Mirror of Memories:Reminiscence and Rapture
• Mature Misbehaving 3