Engineering Design: Representation and Reasoning

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 includes concepts from AI because of their explanatory power and because of their utility as possible ingredients of practical design activity. This second edition has been enriched by the inclusion of recent work on design reasoning, computational design, AI in design, and design cognition, with pointers to a wide cross section of the current literature.

We start with a look at some key AI-based problem-solving methods and then review briefly some classical design aids. We do this to introduce some of the vocabulary and the underlying ideas used to describe design as a process of articulating and solving engineering problems. Then, having identified a language suitable for discourse about the discipline of design, we provide illustrations of new representations of design knowledge and how these representations help us apply that knowledge in design processes.

In Chapter 7, we review some of the current research in engineering design representation with an eye toward identifying future trends. In this final chapter, we also look at the roles that symbolic representation and knowledge-based expert systems can play in engineering design, in both practice and education. In Chapters 5 and 6, especially, we cast many examples in the style of objectoriented programming. In the research and applications literature, these illustrations are presented in pseudocode.

Although there are some common approaches e. We adopted Helvetica as the preferred font for all such examples, but we follow the preferences of the cited authors when it comes to capitalization, underscores, and so on. Thus, it may appear at first glance that we are being somewhat inconsistent in our presentation.

In fact, however, we are striving for consistency with the typeface and the intentions of the works cited. Finally, a note on referencing the many works whose ideas we build on in this rather personal view of design. The notes are organized by chapter sections, and the citations are keyed to the reference list found at the end of the book. We worked very hard to be both complete and fair as we compiled these notes and citations. However, perhaps flaunting our humanity, we apologize in advance for any errors in this regard and ask for a divine response from those who have been inadvertently forgotten or improperly cited!

Fenves Carnegie Mellon University provided an encouraging ear as I talked my way through a very early vision of this book, and he has maintained a friendly interest ever since. Rehak Carnegie Mellon University exercised his unique critical skills intelligently and perceptively over much of the life of the project. He did his best to keep me intellectually honest.

1. Account Options!
2. "Engineering Design: Representation and Reasoning" by Clive L. Dym and David C. Brown.
3. Das finnische Schulsystem (German Edition);
4. Three Wifes Tales.

What more could one ask of a critic? Conrad Guettler and Ms. Florence Padgett of Cambridge University Press have also earned large measures of gratitude. For some years, Conrad gently but persistently encouraged me to write this monograph, and Florence provided cheerful and unflagging editorial support during my life as a Press author. Steier Price Waterhouse provided helpful comments on some of the early chapters of the book.

So did my biking buddy, Alicia Ross of Claremont, who listened to me ramble as we cycled around the Inland Empire. Several publishers, corporations, and individuals have kindly granted me permission to reproduce or replicate figures that have originally appeared elsewhere. The citations for the particular works from which figures have been taken or adpated are given in the respective figure captions. Thus, my sincere thanks to Addison-Wesley 5. We both would like to thank our editor, Peter Gordon, for his encouragement and optimism.

This suggests that representation in design incorporates both representation of the artifact being designed as well as representation of the process by which the design is completed. We now examine briefly both types of representation. That it should not tip on level ground? That it should not tip on a mild slope? What is a mild slope? How much weight should a safe ladder support? Of what material should it be made?

How should the steps be attached to the frame? Should the ladder be portable? What color should it be? How much should it cost? Is there a market for this ladder? We have quickly identified several — but by no means all — of the questions in this very simple design problem, and we would not be able to answer most of them by just applying the mathematical models that originate in the engineering sciences. In fact, which equations do we use to describe the basic function of the ladder? We know that the function the ladder serves is to allow someone to climb up some vertical distance, perhaps to paint a wall, perhaps to rescue a cat from a tree limb, but it is for the designer to translate 1 2 FRAMING THE ISSUES these verbal statements of function into some appropriate mathematical models at some appropriate time — often early on — in the design process.

That is, we have no mathematical models that describe function directly; we infer functional behavior by reasoning about results obtained from manipulating mathematical models. Thus, we recognize already that a multiplicity or diversity of representations is needed for design, a collection of representation schemes that would enable description of those issues for which analytical physics-based models are appropriate; those that require geometric or visual analysis to reason about shape and fit; those that require economic or other quantitative analysis; and those requiring verbal statements not easily expressed in formulas or algorithms.

Some of the verbal requirements could be statements about function; about form e. However, representation in design is much Verbal statements are also made to describe or refbroader than modeling in engineering scierence behavior e. Advances in computing generin my trunk , and intent or rationale e. New programming styles have emerged in which we can capture more abstract conceptual and reasoned design knowledge that cannot be reduced to conventional algorithms.

Although we have discussed the role of representation in design before, we are not the first nor will we be the last to stress the importance of representation. The other six subjects in the curriculum, in which Simon describes design as the science of the artificial, are evaluation theory, algorithms and heuristics for identifying optimum and satisfactory designs, formal logic for design, heuristic search, resource allocation for search, and the theory of structure and design organization.

A brief sampling of recent design research in which representation figures prominently includes work on features in mechanical design; shape grammars; object-oriented data structures; interaction of form, function, and fabrication; formal theories of design; shape emergence; and so on.

We see from this list that the line between representing artifacts and representing the design process is not a sharp 1. We will have a chance to explore some of this and related work in Chapters 5 and 6. It is also important that we recognize that representation is not an end in itself but rather a means to an end; it is a way of setting forth a situation or formulating a problem so that we can find efficiently an acceptable resolution to a design problem.

This also implies that representation is strongly coupled to whatever strategy we have chosen for solving a problem whether in design or in some other domain. Because it is pointless to invoke alternate representations unless we gain some leverage thereby, the notion of changing the representation of a problem is inexorably linked to the idea that there is a problem-solving strategy available to us that uses this representation in a beneficial way.

This is not to say that the research objective of developing new representations should be limited to those for which a problem-solving strategy is available. Research on both artifact representation and problem solving should proceed independently, although perhaps in parallel. But the development of new representations does suggest that broader paradigms of problem solving should be integrated into the outlook of engineers and designers, the idea being that approaches such as AI-based paradigms and tools will become part of the arsenal of weapons available for better engineering.

In fact, design projects often originate with a brief verbal statement, such as President John F. In the clarification step, we ask the client to be more precise about what is really wanted by asking her or him questions: For what purposes is the ladder to be used? How much can the ladder itself weigh? What level of quality do you want in this ladder?

How much are you willing to spend? However, the degree of precision that we might demand from the client could well depend on where we are in the design process. There are formal methodologies for identifying trade-off strategies. For example, the form or configuration of the ladder is strongly related to its function: We are more likely to use an extension ladder to rescue a cat from a tree and a stepladder to paint the walls of a room. Similarly, the weight of the ladder will certainly have an impact on the efficiency with which it can be used to achieve its various purposes: The material of which the ladder is made not only influences its weight; it also is very influential in determining its cost and even its feel.

Thus, a possible design goal that was not even mentioned has suddenly emerged: These specific objectives can be stated in a number of ways, reflecting variously the desire to articulate specific dimensions or other attributes of the designed object, which are usually called prescriptive specifications; specific procedures for calculating attributes or behavior, which are embedded in procedural specifications; or the desired behavior of the device, which is encoded in performance specifications.

We reiterate that the specifications may evolve or be further detailed and refined as the design unfolds. The role of specifications in design has been the subject of much thought and discussion, and it is also clear that the techniques for stating design specifications and, later, fabrication specifications are intimately related to design-representation issues. The design process is evolutionary in nature, and we will come across choices to make and different paths to follow as a design unfolds.

For example, at some point in our ladder design, we have to confront the issue of fastening the steps to the ladder frame. The choices will be influenced by the desired behavior e. The particular process involved here could be called component selection, and it is invoked after we have decomposed the form of the ladder into its components or pieces, and after we have selected a particular type of component. We could say we are externalizing aspects of the process so that we can move them from our heads into some recognizable language s for further analysis.

There is no shortage of attempts to externalize design engineering processes, and we review many of these process models in Chapter 3. These descriptions and prescriptions are externalized to the extent that we can draw flow charts to describe the major steps of a design process, and the descriptions do point to analyses that need to be done and choices that must be evaluated, some of which can be done with conventional algorithms.

However, these descriptions cannot be made computable because they are all relatively abstract; that is, they are not refined enough or rendered in sufficient detail that we can identify the underlying thought processes. Again, the objective in refining these processes is not just to be able to render them computable; it is to be able to analyze them in sufficient detail that we can synthesize design processes out of their fundamental constituent processes.

When we do so in earnest in Chapter 6, we will see that we are taking advantage of research in AI and related fields such as cognitive science to examine and describe the activity that is called design. We view this as the representation of the design process as opposed to the representation of the artifacts that are being designed.

Designing paper-transport systems for copiers is difficult because of the number and kind of design variables and their complex interactions. Nonetheless, by identifying the way designers actually do this task, the designers of the PRIDE system built a knowledge-based system that does much of the same design task as human designers. That is, PRIDE uses a variety of representation formalisms to incorporate both algorithmic and heuristic aspects of the design problem.

It also uses a variety of inference schemes i. The PRIDE environment allows the designer to experiment with different designs, both graphically and procedurally, and it facilitates the tracking of dependencies between design decisions and the maintenance of multiple design paths. Furthermore, the PRIDE system works so well that it allows experienced designers to do feasibility studies in just a few hours, whereas it used to take four weeks to develop similar designs.

In addition, the PRIDE system is viewed as useful because it also has led to paper-copier designs that are both more consistent and of higher quality. We note two related points.

5 editions of this work

The reason for this is that the representations inherent in OR approaches, although they permit the inclusion of economic or similar performance metrics, do not admit those qualitative or strategic choices that cannot be reduced to numbers. The second line of argument supportive of what has been outlined is that whereas much of the work in design is empirical in nature, both in design practice and in design research, there is apparently no objective basis for describing and evaluating experiments in design.

Much of what is known and transmitted about how to design artifacts is — or is perceived to be — anecdotal in nature. To the extent that design knowledge is viewed as design lore, both the development of the discipline of design and its acceptance by the engineering community as a serious discipline with a rigor and logic of its own are inhibited.

Thus, in this context as well, it could prove useful to adopt the relevant terminology and paradigms from AI and related cognitive fields, subjects that are themselves highlighted by experimentation and empirical development. One example is the technique of protocol analysis, which may be described as the process of organizing, understanding, and modeling verbal reports and analyses.

This technique has been applied formally and informally to elicit and organize the knowledge that designers use in their own domains. The use of a formal structure and methodology in this particular context is bound to be beneficial in developing a communicable understanding of the process of design. In essence, the problem is as follows Figure 1.

A structural need is identified, whether it is for a mill building or a concert hall. Then we choose a structural concept, perhaps a simple steel frame and steel roof truss for the mill building, something considerably more complex for the concert hall, and we move to preliminary design. In this stage, we usually restrict our efforts to rough sizing of the principal structural members, the object being to see whether the type of structural system that we have chosen is practically feasible.

We then move on to flesh out the structure by estimating the types and sizes of the remaining members e. Then we home in on the final, detailed design in which we calculate actual dimensions and placements for all members and their connections. In the final step, we check to ensure that our design meets all statutory requirements, including both applicable building codes and design codes 1.

A pictorial view of the structural engineering problem Fenves, Let us now examine the kinds of design knowledge deployed in completing such a structural design. Among the kinds of knowledge we apply are classical mechanics e. Much of this knowledge is multilayered. For example, our understanding of the behavior of structural systems is realized at three distinct levels: How do we represent these different kinds of structural design knowledge? In fact, we use several different kinds of representations of the knowledge itself, including mathematical models for classical and structural mechanics e.

Such qualitative knowledge is often subjective and frequently expressed in rules. We should also recognize that we often cast the same knowledge in different languages, depending on the immediate problem at hand. For example, a statement typical of that found in building codes that the deflection of a floor in a residential building should not exceed its length in feet divided by is actually a restatement of equilibrium for a bent beam.

What is beginning to be true now is that we want to formally recognize this in the increasingly elaborate computer-based design tools we are developing. And, even more important for our present purpose, as we try to externalize our design knowledge, we are increasingly conscious of how we think about design. It is this raised consciousness we seek to expose here.

For example, it forces and flows, visualizations of those data, anihas been easier to develop knowledge-based mations of structural models, virtual manufacturing, expert systems to perform derivation tasks, and rapid prototyping. Similarly, in exploring applications of AI techniques to design, there are going to be differences that ought to be acknowledged from the outset. For example, truly routine design which is essentially a repetitive process is much more readily automated than nonroutine design, in which the form and function or their attributes of a successful design may not be easily described, if at all.

Thus, replication of routine design will offer different opportunities for automating with AI techniques than will the modeling of creative or original design. That is, it is likely that over time, a hierarchy of design tools will be developed to reflect these differing design tasks. As we articulate and acquire design knowledge, which we must do before we can represent it, we also acquire a keener understanding of that knowledge.

Furthermore, as we noted ulated that had not been previously recorded i. We have investigated computationally Boden ; Brown argued that the mathematics that we use Thus, we need to augment our mathematical modeling tools with others, such as graphics, logic, grammars, word and document processors, and — most relevant to this discussion — those tools based on symbolic representation.

We must caution, however, that we are not saying that there is no mathematical foundation underlying the symbolicrepresentation techniques the use of which we advocate. Indeed, there are very complex mathematical problems involved in computation in general and in developing the underlying structure of the kinds of AI programs that are used to develop the kinds of results that we will see later in this book. However, the mathematics involved there is concerned with representing the symbols and the processes used to compute with these symbols so that, ultimately, the computer can do as it is told.

Perhaps a very loose analogy is that this particular kind of mathematics is to the symbolic representation that we espouse as set theory and functional analysis are to the continuous mathematical models we routinely employ e. Thus, we view as parallel the descriptive representations offered by continuous mathematical models and by symbolic representation of physical and conceptual objects and their attributes and dependencies.

Mathematical modeling is discussed in Dym and Dym and Ivey The new, AI-based program We have discussed representation For a good text about knowledge representabefore in Dym and Dym b. Artificial Intelligence for Engineering Section 1. Otto and Antonsson present a formal The role of specifications in design is discussed in Fenves ; Stahl et al. Techniques for stating design specifications and their relationship to design-representation issues are described in Dym et al.

An interesting view of the role of operations research in design is that of Wilde Applications of knowledge-based systems to chemical engineering are offered in Lien, Suzuki, and Westerberg Protocol analysis is defined in Ericsson and Simon ; its application to design has been explored formally in Stauffer, Ullman, and Dietterich and Ullman, Dietterich, and Stauffer and informally in Mittal and Dym A steel design code can be found in AISC The types of knowledge deployed in structural engineering are discussed in Dym and Levitt b.

The ease of building knowledge-based systems is connected to the task they model by Bobrow, Mittal, and Stefik ; Dym ; and Fenves Knowledge acquisition for expert systems is discussed by Mittal and Dym Touretzky derives the basis for the inheritance structure that underlies the object-oriented descriptions described in Chapter 5. We see it often and in many different contexts. For example, just in perusing our daily newspapers, we read about people who are automobile designers, dress designers, architectural designers, sound-system designers, aircraft designers, organization designers, highway designers, system designers, and so on and so forth.

Design was done in very primitive societies for purposes as diverse as making basic implements e. However, because people have been designing artifacts for so long and in so many different circumstances, is it fair to assume that we know what design is, and what designers do and how they do it? And, of course, one of the themes of this book is that we are still struggling to find ways of externalizing and articulating even that which we do know about design.

However, we can never know for sure, because who is to say that small flint knives, for example, were not consciously used as models for larger, more elaborate cutting instruments? Certainly people must have thought about what they were making because they recognized shortcomings or failures of devices already in use and evolved more sophisticated versions of particular artifacts. Kant writes hides and innards of larger animals.

If we can be sure of anything, it would be that much of what they did was done by trial and error a process that has a modern reincarnation in the method called generate and test in which trial solutions are generated by some unspecified means and then tested against given evaluation criteria. What we do know about design problems in general — and engineering design problems in particular — is that they are typically open-ended and ill-structured, by which we mean the following: Petroski makes a similar point at a higher level of abstraction, arguing that failure is a major driver for design and that the failure of various devices or systems has spurred efforts to discover more robust engineering solutions.

Design problems are said to be open-ended because they usually have many acceptable solutions. The quality of uniqueness, so important in many mathematics and analysis problems, simply does not apply. Design problems are said to be ill-structured because their solutions cannot normally be found by routinely applying a mathematical formula in a structured way. It is these two characteristics in particular that make design such a tantalizing and interesting subject. Even the simple ladder design that we broached in Chapter 1 became a complex study because there were choices to make about the form and structure of the solution and because there was no single language for or ordering of the many different design issues that had to be addressed.

How much more complicated and interesting are projects to design a new automobile, a skyscraper, or a way to land someone on the moon. We can find discussions of design well back in recorded history. One of the most famous is the collection of works by the Venetian architect, Andrea Palladio — , whose works were apparently first translated into English in the eighteenth century, in which language they are still available today. Discussions of design have been prompted by the concerns of domains as diverse as architecture, decision making in organizations, and styles of professional consultation, including the practice of engineering.

Thus, it should not surprise us that there are many, many definitions of design or that these definitions, at a sufficiently high level of abstraction, seem very much alike. For example, one might say that design is a goal-directed activity, performed by humans, and subject to constraints.

The product of this design activity is a plan to realize the goals. Simon offers a definition that seems more closely related to our engineering concerns: The challenge posed here for design is not simply to create tools that accurately reflect existing domains, but to provide for the creation of new domains. Design serves simultaneously to bring forth and to transform the objects, relations and regularities of the world of our concerns.

This concept of design seems to combine the idea of design as an activity with the explicit articulation of the fact that some objects and their contexts are being represented — and perhaps changed or created by manipulating these representations — in order to produce a design. This definition thus seems to parallel the view of representation outlined in Chapter 1.

One aspect of design that we will not explore here, as we move toward a definition of engineering design, is the role of aesthetics in design. A brief history that aesthetics is unimportant in engineerof the computational study of aesthetics is provided ing design; however, we do wish to keep our by Greenfield We noted earlier that primitive designers almost certainly designed artifacts through the very process of making them.

It has been said that this approach to design is a distinguishing feature of a craft. With this in mind, it is also useful for us to distinguish engineering design from those domains — or crafts — wherein the designer actually produces the artifact directly, such as graphics or type design. An engineering designer typically does not produce an artifact; rather, he or she produces a set of fabrication specifications for that artifact.

That is, the designer in an engineering context produces a detailed description of the designed device so that it can be assembled or manufactured. Thus, that specification must be both complete and quite specific; there should be no ambiguity and nothing can be left out. Traditionally, fabrication specifications have been presented through some combination of drawings e.

Although completeness and specificity can be had with these traditional means, we cannot 2. DR has been studied for engineering suspend a second-floor walkway from a roof Burge and Bracewell as well as for software truss, hung it instead from a fourth-floor engineering Burge et al. The supports of the fourth-floor walkway were not designed to carry the second-floor walkway in addition to its own dead and live loads, so a major disaster ensued.

Had the designer been able to signal to the contractor his intentions of having the second-floor walkway suspended directly from the roof truss, this accident might never have happened. Thus, while still in an early design stage, the designer would have had to seek another solution. Only recently has this wall been penetrated — even broken — and manufacturing and assembly considerations are increasingly addressed while a product is still being designed, rather than afterward.

This new practice, called concurrent engineering, is becoming very important in design engineering, and it is a field that relies heavily on recent developments in computation, including the integration of multiple representations of artifacts. The Hyatt Regency tale and the implications we have drawn suggest that a major issue in engineering design — as distinguished from craftlike design — is the clear need for formalisms that can be used to represent fabrication specifications. In designing a formalism for fabrication specifications, we can learn from this disaster that there are requirements of completeness, specificity or absence of ambiguity , and functional intent that must be addressed.

Furthermore, as long as we are developing a new specification formalism, we should require that it also enable us to evaluate a design in terms of how well it meets the original design goals. We thus have another indication of the importance of representation as an issue in engineering design, although our emphasis would have to focus on translating the original design objectives and constraints into some version of the specification formalism and on recognizing that these specifications provide the starting point for some manufacturing process.

The purpose of design is to derive from a set of specifications a description of an artifact sufficient for its realization. Feasible designs not only satisfy the specifications but take into account other constraints in the design problem arising from the medium in which the design is to be executed e. As we move closer to a definition of engineering design, we should also account for the notion of design as a human activity or process, with all that is thus entailed about context and language. At the same time, as noted before, we must focus on the idea that plans are going to be produced from which an artifact can be realized.

Thus, a definition of engineering design must be broad enough to encompass a variety of concerns but not so abstract as to have no obvious practical implementation. Engineering design is the systematic, intelligent generation and evaluation of specifications for artifacts whose form and function achieve stated objectives and satisfy specified constraints. This definition incorporates many implicit assumptions, some of which we have already anticipated. We now explore the underlying assumptions in some detail, with the express intent of exposing the role of representation in design.

As a process, design is thoughtful and susceptible to understanding, even if complete understanding has not yet been achieved.

Refine your editions:

That is, along the lines of the discussion in the Preface and Chapter 1, we argue that much of design can be viewed as a cognitive process; thus, it can be modeled with inAn AI-oriented approach to investigating design creasing success. A successful representation — perhaps consisting of some ordering of multiple representations — can be found for both form and function, and there exists a calculus for their interaction.

Representing function is one of the most difficult problems in design representation, particularly so in our context of exploring 2. Artifigiven form or structure, we can usually cial Intelligence for Engineering Design, Analyinfer the purpose of the artifact. Howsis and Manufacturing Stone and Chakrabarti ever, given an intended function that and a chapter by Wood and Greer must be served, we cannot automatically provide references to most of the additional key deduce from the function alone what research in the field, including the continuing work form or structure the artifact must have.

However, if we were to start with a statement of purpose that we wish to connect two boards, there is no obvious link or inference that we can use to create a form or structure for a fastening device. This does not mean that given a catalog of fastening devices, we cannot choose one to accomplish a given intention.

In fact, we will see in Chapter 5 that among the attributes we can attach to device descriptions will be function and intent. But this is helpful only after we have already associated a purpose with a given device whose structure or form is known to us. Constructing a structure based on function alone is not, generally speaking, a process that is well enough understood that we can model it. Given a successful representation broad enough to span form and function, the original statement of a design problem, and in particular its objectives and any applicable constraints, can be cast in terms of this representation.

This, in a sense, is a self-evident truth, for we should have to conclude that the representation is not especially robust — or useful — if we cannot recast our design statement, design objectives, and given constraints in terms of that representation. There exist problem-solving techniques that exploit this representation for the generation and enumeration of design alternatives.

This too is fairly obvious for, as we remarked in Section 1. The generated designs can be translated from the multiplicity of representations into a set of fabrication specifications. Remember that the end point of a successful design is the production of a set of plans for making the designed artifact. This set of plans, the fabrication specifications, must have the properties of unambiguousness, completeness, and transparency; that is, it must stand on its own as thoroughly understandable cf.

Criteria for design evaluation can be stated and applied in terms of either the representation used in the problem-solving phase of the design process or the formalisms used for the design and fabrication specifications. Here, we are Designers have to face uncertainty throughout their noting simply that we can assess and design work.

The designers may be uncertain about evaluate our design at different points the priorities given to preferences, or even whether in the design process; consequently, we something is really a requirement; make deliberate may use different versions of our repassumptions not knowing whether those assumpresentation.

That is, successful designs about its quality. There also may not be any ure because of its contributions to air theory, or adequate models, about manufacturing pollution. It is not that problem solving and evaluation are less important; they are extremely important, but they too must be expressed and implemented at an appropriate level of abstraction. Thus, they are also inextricably bound up with concepts of Distinctions often are made among needs, requirerepresentation. Indeed, Simon has highly varying levels of abstraction. For software argued that the distinction is ephemeral.

Because for selecting a design from a set of designs, each this distinction, meaningful or not, is mainof which satisfies both the requirements and the tained in most of the design literature, we constraints. Cross presents a short discussion of design history and distinguishes design from a craft. Generate and test and other AI-based problem-solving methods are detailed in Dym and Levitt a. Discussion of design in other fields includes A modern treatment of AI is presented in Russell and architecture Alexander ; Salvadori Norvig , and the art of concurrent engineering ; Stevens , organizational decision is described by Salomone Definitions of design are given by, among many others, Agogino b , Dixon , Jones , Mostow , Simon , and Winograd and Flores Algorithms for aesthetics are presented in Stiny Levitt, Jin, and Dym describe both needs and architectures for concurrent engineering.

Fenves and Rehak stressed the importance of fabrication specifications. The definition of design was first presented in Dym and Levitt a and was extended in Dym b. The ephemeral nature of the difference between constraints and specifications was pointed out in Simon In this chapter, we review some of the established models of the design process. Then we go on to describe more recent articulations, some of which are rooted in the AI-based ideas mentioned earlier. Parts of the discussion may seem vague or abstract because we are trying to describe a complex process by breaking it down into smaller, more detailed pieces, but we are not going to produce a detailed cookbook that must be followed in order to complete a design.

We are simply trying to picture, in words and diagrams, what is going on in our head when we are doing design. In so doing, we find that we can decompose or break down the process into a sequence of steps by extracting and naming some of those steps. Finally, when we present the final fabrication specifications for the proposed design and typically also the justification for those specifications , we are documenting our completed design for the client. Studies of design have also point of the exercise.

We ties that facilitate cooperation. Hence, research on look now at some descriptions of the design individual design activity remains very important. This entire chapter is about characterizing design. As a result, we present abstractions of typical processes. In real life, one or more agents generate designs, guided or limited by constraints, preferences, evaluation knowledge, and a wide variety of knowledge and data. These limits derive from various sources, such as the knowledge, skill, and experience of the designer s ; available tools and methods; externally imposed needs and requirements; and limitations imposed by the physics.

Hence, the context for a particular design process can be infinitely varied, leading to wide variations in the actual process followed by different designers — even for the same requirements! One of the simplest models of design considers only transformations between types of representations. The model does not prescribe the order in which these processes occur and does not suggest the kinds of reasoning that might be used for each type of process.

Subsequent developments include a more complex model, as well as the use of this model to annotate protocols collected from designers i. In the second stage, evaluation, the design is tested against the design goals, constraints, and criteria that have been set forth by the client and the designers.

In the third stage, communication, the design is communicated to the manufacturers or fabricators. Although this model has the virtue of simplicity, it actually tells us relatively little about what goes on. 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.

Engineering design : representation and reasoning

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.

Engineering design : representation and reasoning / Clive L. Dym, David C. Brown - Details - Trove

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. 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.

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.

• ?
• People of the Book!
• ?
• Terror at Beslan: A Russian Tragedy with Lessons for Americas Schools?
• Captive du passé - Au coeur du soupçon (Harlequin Black Rose) (French Edition)!
• What Decision Neuroscience Teaches Us About Financial Decision Making (Annual Review of Financial Economics Book 1).

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.