DETC2004-57013 - deseng.ryerson.ca - Ryerson University

Proceedings of DTM04: Design Theory and Methodology 28 Sep – 2 Oct, 2004, Salt Lake City

DETC2004-57013 DIAGRAMMATIC INFORMATION

VISUALISATION

OF

Filippo A. Salustri Ryerson University, Department of Mechanical and Industrial Engineering, 350 Victoria St., Toronto, Ontario, M5B 2K3, Canada tel: 416/979-5000 x7749; fax: 416/979-5265 email: [email protected]

ABSTRACT There is little methodological support for the early stages of product design that facilitates designers’ cognitive abilities to think about design problems. Yet decisions made during early design are the most crucial to product success. Diagrams present an excellent way to visualize qualitative information, and can stimulate clear, holistic thinking, but there have been no substantive research efforts to apply diagrammatic representation to early engineering design. We therefore introduce design schematics (DS) as such a tool. We outline the general benefits of diagramming and then consider the advantages and disadvantages of some existing diagramming methods. Our analysis motivates the development of DS. Several examples demonstrate how DS can capture important information during early design stages. We are currently developing a computational tool that implements DS and discuss some of the challenges we face in this regard. While there is not yet any quantitative data by which DS can be evaluated, there is anecdotal evidence suggesting that the tool has the potential to be of benefit to practicing designers. INTRODUCTION Designing products is becoming more difficult due to increasing complexity, precision and quality requirements, new materials, environmental and ergonomic issues, etc. Designing is especially difficult in the early stages of product development, due to a relative lack of methods to represent and reason about product models. The early stages are those that precede the establishment of product geometry, and are the most important. One may invoke the Pareto Principle to argue that most of the performance of a product is determined by these early design decisions. Moreover, engineering as a whole, and design in particular, has become a global endeavor organizationally and geographically. If concurrent and collaborative engineering

EARLY

PRODUCT

DEVELOPMENT

Jayesh Parmar Ryerson University, Department of Mechanical and Industrial Engineering, 350 Victoria St., Toronto, Ontario, M5B 2K3, Canada email: [email protected]

practices are to yield their full benefits, design information must be presented to different stakeholders in different ways, to maximize its usefulness to each stakeholder. Teams must share information with colleagues, suppliers, and managers who may be physically distant, so it is essential that information be presented clearly and concisely. There are cultural issues too: in the “global village”, design information written in one natural language can be misinterpreted by those not very familiar with it. Lessening the dependence on natural language will aid in the internationalization of design information and thus benefit culturally diverse collaborative teams. In order to address these issues, a variety of graphical techniques have been developed, such as bond graphs [1], Integrated Definition Language (IDEF) [2], entity-relationship diagrams [3], the Modelica language for physical systems modeling [4], and many kinds of block diagrams. These tools can serve in some aspects of PDPs. However, these tools are best suited and most readily applied to designs once the overall conceptual and systems design stages have been completed. This is understandable. In the early design stages, product information is vague and qualitative. Knowledge representation of this information in computable forms is very difficult. There are also issues of software usability. While work has been ongoing for many years to develop software that supports qualitative information (e.g. computer-based sketching), such software remains quite expensive and difficult to use compared to a simple sheet of paper and a pencil. Individual experience and preference, and group dynamics and synergy heavily influence the early design stages. These features are not captured readily by tools, because each tool commits to some underlying methodology. Each methodology implies certain perspectives on design and product development that are not necessarily shared by the tools’ user community. The authors believe that a solution lies in the development of simpler tools that rely more on informal representations of

1

Copyright © #### by ASME

product and design information. Our hypothesis is that the best product-modeling tool for the early design stages will facilitate human cognitive abilities rather than displace that burden from the human designer to the tool itself. That is, we are looking for a tool that promote clear, structured thinking in modern design environments rather than design automation per se. We need tools that help the designer think more clearly and about the right things. A graphical, rather than textual, notation may succeed here [5]. It is cliché to say that a picture is worth a thousand words, because it is true. In design meetings, designers typically use diagrams to aid the team’s work. These diagrams function as cognitive cues to the designers about important issues, decisions, and actions. Handbooks and textbooks are full of diagrams and figures. Appropriately laid out diagrams can communicate a holistic perspective of information that is very difficult to extract from purely textual descriptions. This gives designers a better overview of their work [6] and contributes substantively to collaborative capacity by facilitating a common mental model of the design among all team members. In summary, the authors believe that it is possible to design and implement a simple tool that will be small, usable, and effective for at least some of the upstream stages of design processes. This paper introduces such a tool, called design schematics (DS). It is a diagramming method intended to capture product information in early design. While computer support for DS would obviously help, we will focus here on the language of DS itself; nonetheless, some comments regarding the nature of a computer-based DS tool are given at the end of the paper. FUNDAMENTALS Various graphical and matrix-based tools are being investigated, including bond graphs, flow charts, IDEF, entityrelationship diagrams, the Modelica language, electrical block diagrams, Unified Modeling Language (UML) [7], design structure matrices [8], visual programming languages, and concept maps [9]. Though this background study is ongoing, some points of interest are already apparent. To the authors, the main disadvantage of all of these methods except concept maps is that they provide well-defined structures to specify product information unambiguously and prepare it for various analyses. This is not in itself bad, but in doing so these tools impose too many constraints on the early design stages, which can unnecessarily burden the cognition of designers. The chief hindrance of concept maps, on the other hand, is their lack of structure, which prevents designers from achieving the concentrated focus needed to treat design issues effectively and efficiently. DS is being developed to lie somewhere between concept maps on the one hand, and the more structured tools on the other. We are studying each tool to identify features that can be combined with concept maps to guide designers while preserving the flexibility needed in the early stages of design.

2.1. Requirements of Early Design The authors consider the early design stages to include strategic planning, requirements engineering, conceptual design, systems design, and configuration and layout. By the time that the configuration and layout stage is completed, a sense of physical size and shape is usually available, for which conventional CAD solutions may then be employed. Concept sketches may be possible, but sketching by computer is still an immature technology, seldom used in North American engineering industry. Furthermore, sketches are only able to capture some of the kinds of important information that engineers need to guide their thinking. They do not capture (easily) information about requirements, systems, etc. Thus, some new representation is needed. This representation must meet the following requirements. 1. Promote thinking and learning about design problems rather than just specifying solutions. 2. Be extremely intuitive and easy to learn. 3. Be flexible enough to represent different kinds of information consistently. 4. Provide an extensible structure to disambiguate kinds of information arising in the early design stages. 2.2. Designing as Learning The first requirement is the main reason we have chosen concept maps as the basis for DS. The authors subscribe to the notion that learning is the integration of new information into a learning agent’s existent cognitive structure [10], which can be seen as a richly interconnected network of information upon which cognitive processes operate. The more richly interconnected new information is, the greater the impact of the new information on cognitive processes of a learning agent, and the better the new information has been learned. We believe that designing – especially in the early stages – is a learning exercise. The acts associated with specifying the initial requirements, concepts, and systems of a product are acts of exploration and discovery, which result in learning. Once a design problem is understood well enough, at least part of the design answer is usually quite apparent. Indeed, it is a common perspective that design problems and their solutions evolve concurrently. In this view, then, effective design tools promote the integration of new information into a designer’s mind by being as compatible as possible with the network-based model of learning described here. 2.3. Concept maps as learning tools Concept maps are learning tools meant to target specifically the mode of learning noted above. They are visual representations of the key concepts in a domain and their interrelationships. Concepts are shown as nodes and relations as labeled arcs connecting the nodes. Concept maps that take the form of network graphs have been correlated to both deep learning and innovative thinking [9].

2


Concept maps have been classically used in early childhood education for both learning and assessment. Elsewhere, they are often used during brainstorming to capture quickly and easily ideas that are not precisely defined or understood. By using such an technique, the emphasis remains on the brainstorming itself (i.e. thinking), not on the mechanistic aspects of specifying its result in a prescribed format. We have experimented extensively with conventional concept maps for representing product information. The two major concept mapping software packages, CmapTools and Inspiration, were used to construct concept maps of several simple and medium-complexity electromechanical products. We have found that concept maps are just too simple to represent the breadth and scope of product information. Some areas requiring improvement include the following. Layout management. We have found that the layout of nodes in a concept map can communicate substantive information, and that the best layout for a particular diagram depends on the kind of information in the map. Examples of this are given below. Hierarchies. It must be possible to collapse one map into a single node within a larger map; this would allow direct representation of hierarchical levels of information. Hypergraph support. Generally, concept maps for design will be hypergraphs (e.g. supporting one-to-many links between nodes). This is rarely provided in existing systems. Anchor labelling. Conventional concept maps allow labels only on nodes and midway on links (i.e. named links). However, we have found that also allowing labels on the anchors (the heads and tails of links) substantially increases the flexibility and expressive richness. Filtering. All-inclusive maps can be too cluttered to be understood easily. Since designers tend to focus on specific aspects of designs sequentially, it must be possible to temporarily filter out unneeded information. The capacity to filter out various portions of a map would help maintain the integrity of the map as a whole while presenting only the minimum required information. Boolean and cardinality constraints. Conventional concept maps do not support boolean relationships between

nodes or links, nor do they support cardinality (e.g. that an assembly requires four of one kind of part). Clearly, finding a way to augment concept maps to support these features would be advantageous. 3. DESIGN SCHEMATICS This section gives an introduction to DS through a set of examples. The DS in this paper were drawn “by-hand” using Smartdraw (a generic drawing package). It will become evident that computer support for DS is important. The authors are working on such a tool, but our main interest here is to discuss the diagrammatic language of DS and to indicate its representational strength for early product modeling. As a sample problem, we use the design of a powered screwdriver, taken from [11]. In order to show the potential breadth of DS, we will use a simplified design process developed by Salustri. While the details of the process are beyond the scope of the current paper, we do advise readers that there is a rationale to the selection and ordering of DS here. We note that most companies that do design engineering have their own, proprietary ‘process’ for product development. We believe the principles of DS could be applied there as well – in the same way as each organization can have a different way of writing text documents, so too can each organization have its own way developing DS diagrams. To begin, we consider the description of a usage schematic (US), which allows designers to think about how a product might be used. Information to build a US can come from focus groups, consumer reports, marketing information, designers, etc. US help designers focus on customer needs, how a product will be used, and issues that arise as a result (e.g. safety). A possible US for the powered screwdriver is shown in Figure 1, which shows three task paths. The links in the US show the order of actions taken by users. The terminal node at the right end of this kind of DS has an implied feedback link connecting to the initial (leftmost) node. The number 1 at the branch in the Usage US indicates that only one of the branches can be followed. The links are unlabelled because there is only one kind of relationship in a US; the links indicate the order of steps in a product’s use. “PSD” stands for “powered screwdriver”.

Setup

get PSD from storage

hold PSD

couple bit & PSD

Recharge

couple charger & power supply

couple PSD & charger

wait for PSD to charge

Usage

couple screw & PSD

align PSD

activate PSD

decouple PSD & charger

1

drive screw

decouple charger & power supply

deactivate PSD

decouple PSD & screw

Figure 1: A possible usage schematic for a powered screwdriver.

3


Setup

get PSD from storage

hold PSD

distinctly visible in toolbox

ambidextrous controls

distinct colour

lateral symmetry

couple bit & PSD

symmetrical de/activation

hold bit

forces acting at bit/PSD interface

accomodate bit

bit sizes & types

Figure 2: One branch of the powered screwdriver US, with some PCs, FRs, and constraints attached. Designers can then add nodes indicating product characteristics (PCs – things a product must be), functional requirements (FRs – things a product must do), and constraints that follow from reasoning about the design implications of the US. Figure 2 shows the Setup usage scenario, with some of these other entities. The branches in Figure 2 are not labeled because the default meaning of a branch is that all the entities at the heads of those links must be attained for the entity at the root of the link to be attained. Blue nodes are PCs; green nodes Powered Screwdriver

durability

fabricability

are FRs; and yellow nodes are constraints. One can extract all the PCs, FRs, and constraints from a US and, by rearranging them, form a product design schematic (PDS) – a DS of the basic characteristics and functions expected of a suitable design. Our PDS representation combines aspects of the work by Pugh, [12] and Dym and Little [13]. The details of our representation are of secondary importance here because we are developing DS to support a variety of different “knowledge representations”. Our goal here is to show how a

long life

>= 5 years

survive heavy use

max torque

drive screws

max axial loading

maximise off the shelf parts

easily assembled unscrew screws functionality

usability

maintain screw alignment

well balanced

allow easy bit changing

ambidextrous

recharge quickly

charge time = discharge time

hold screws Figure 3: A partial product design schematic for the powered screwdriver. 4


Bit

allow easy bit changing

Waste Energy

Electricity Supply

recharge quickly

store energy

drive screws

Bit

Screw

couple screw & PSD

hold screws

maintain screw alignment

Installed Screw

User Force unscrew screws Figure 4: A partial function schematic for the powered screwdriver. PDS diagram may represent important design information. A partial PDS of the screwdriver is shown in Figure 3, for the Usage US in Figure 2. The rules for a PDS are quite simple. The links are unlabeled because the node colors imply the relationships. Bold nodes are of high importance, nodes without borders are of low importance, and the others are of middling importance. The left-most “column” of PCs defines some of the basic characteristics of any product. The next segment shows some PCs and FRs specific to the problem. The number of segments varies with the complexity of the problem. General PCs are linked to more specific PCs, which are linked to the FRs that define how a product achieves them. PCs and FRs in turn link to constraints that limit a product’s performance with respect to the FR. PDS that form hierarchies are consistent with the Independence Axiom of Suh’s Axiomatic Design [14]. However, such uncoupled designs are rare. The highlighted links (in red) in Figure 3 indicate interactions between PCs and FRs, which appear as cross-links in a PDS and which indicate graphically violations of the Independence Axiom. Suh’s design parameters have not yet been incorporated into our PDS; this is a point of future work. One may then develop a function schematic (FS) of the problem, which is a DS that captures the result of function decomposition. It is similar to the function diagrams of [11] and is used to expand the FRs into a function model of the product. A fragment of a FS for the powered screwdriver is shown in Figure 4. To save space, only some functions from the PDS are shown in Figure 4. Our intention is to demonstrate the DS language and not to provide a complete account of the screwdriver problem. In actual cases it will be important to indicate where and how a DS is incomplete. One way is shown in Figure 4: the dashed arrows on the function unscrew screws

shows that there is more to this FS than is shown. The green nodes are identical copies of their counterparts in the PDS. Also, the sides of function nodes have specific purposes. Borrowing from IDEF, inputs into the left side are resources consumed by the function and inputs into the top of a node indicate non-consumed resources (e.g. the bit of the screwdriver). Finally, one can use the FS to develop a product architecture schematic (PAS). Based somewhat on the diagrams by the same name in [15], our PAS are more structured. Again, our goal is to show that a PAS can represent important design information diagrammatically. A PAS for the powered screwdriver is shown in Figure 5. Note the feedback between the structural and drive systems (highlighted in red for clarity) is evident by a simple visual inspection of the PAS. This is due to the layout of the diagram, which is designed to highlight such patterns of interaction in the diagram. There is another possible presentation of systems in DS. This second presentation involves the simultaneous presentation of a product’s basic functional, systems, and physical structure. To demonstrate the advantage of such a presentation, we consider first Figure 6 (which is not a DS), which represents graphically a planetary gear system. An undergraduate student familiar with planetary gears but not with DS originally drew the figure; we think of it as a “naive” diagrammatic representation. Since the overall topology of a DS is not known a priori, one might start by simply grouping similar kinds of entities: functions and components. Colors are used to distinguish the two kinds of information. Different kinds of links are supposed to show relations between components, between functions, and between both. However, very little of the overall information structure is visible in this view. The links are confusing. Furthermore, one

5


Bit Screw Drive System Screw Bit Structural System

User Force

Electricity Supply

User Input

Waste Energy

Power System

Activation System

Feedback

Figure 5: A partial product architecture schematic for the powered screwdriver. function, withstand internal forces, would have to connect to every other node, confusing the diagram even more. Figure 7 shows the same information about the planetary gear system, but arranged according to a small set of deterministic rules. This new figure clearly gives a much better

Withstand Internal Forces

Receive Input Torque

impression of the overall system. Using partially overlapping nodes has eliminated many links, and there are only two kinds of links instead of three as in Figure 6. The rules for this kind of diagram are generally as follows. Functions “contain” the components that provide them. Functions that apply to large

Deliver Output Torque

Increase Torque Decrease Speed

Lower Friction Losses Transmit Reaction Forces

Input Shaft

Planetary Gear System

Carrier

Sun

Ground

Planet 1

Ring

Planet 2

Bearing

Bearing

Bearing

Output Shaft

Figure 6: A “naively” constructed diagram of a planetary gear system. 6


Planetary Gear System Withstand Internal Forces Receive Input Torque Input Shaft

Deliver Output Torque

Carrier

Increase Torque

Output Shaft

Sun

Planet 1 Decrease Speed Lower Friction Losses

Planet 2 Ring

Bearing

Bearing

Ground

Bearing

Transmit Reaction Forces

Figure 7: A design schematic of the same planetary gear system as Figure 6. regions (multiple components) contain the more “restricted” functions. System interface components reach the border of the large node marked planetary gear system. Black lines connect components so as to minimize crossed lines; similarly, white lines connect functions. Careful selection of diagrammatic forms clearly facilitates understanding the information in a diagram. COMPUTERISATION OF DESIGN SCHEMATICS Clearly, computer support for the development and manipulation of DS is important. In this section, the authors discuss how we are approaching the development of such software. There are three fundamental purposes for the computerization of DS. Developing DS diagrams “by hand” with existent software is onerous. Any benefits that might exist from the diagrammatic approach are cancelled out by the burden of creating the diagrams. However, it is easy to see how software, able to render and organize graphs in a variety of

ways, could dramatically reduce the amount of time to generate DS diagrams. Computerization improves usability. The DS presented in this paper were laid out with conventional diagramming software. This task was onerous because the layout itself conveys important design information. A computer tool to lay out DS automatically would solve this problem. Computerization improves information integrity. Nodes and links will be represented independent of the style of DS, so that they can appear consistently in multiple DS and thus communicate information more effectively to designers. Computerization increases the potential for design automation. Since a DS carries a certain amount of semantic content, that content can be examined and manipulated by artificial intelligence engines to conduct various analyses. The basis of a computerized DS (cDS) system is straightforward and well understood: there are many graph layout engines and software packages available both

7


commercially and for research purposes. What is missing in these packages is in the “intelligence” to support designoriented semantic content, particularly for layout purposes. To address this, the authors are developing an extensible intelligent graph layout engine. Within this engine, different modes will be available as run-time modules. A mode will have a layout algorithm and various standards for node and link appearances. Each kind of DS will have its own mode. Modes will be able to filter nodes and links so as to present only information pertinent to that mode. It will be possible to implement new modes and simply load them in the engine as “plug-ins”. Rules for each kind of DS will be written in a language we will develop expressly for this purpose. The language will allow one to define kinds of nodes and links, and the topological and geometric relations that can exist between nodes and links. We expect to make extensive use of constraint graphs [16] to develop the language. Constraint graphs are a knowledge representation technique that covers a broad range of diagram types, including for example flowcharts and concept maps. For example, a usage scenario mode will implement a layout algorithm that will ensure the user action nodes will appear organized in the style of Figure 2, and that other nodes will be arranged as well as possible without altering the US node layout. It will provide users with a library of nodes and links that can be used in that mode. The user will then be able to switch between US and, say, PDS while maintaining integrity of the underlying design information. Changes to one DS will transfer into others as defined by the specific filters and layout algorithms for the corresponding modes. INITIAL ASSESSMENT OF DESIGN SCHEMATICS Comparison to other methods The authors are unaware of other tools that provide a measure of “intelligence” to graph construction, layout, and manipulation for the early stages of engineering design; we continue to search the literature for other efforts nonetheless. With regards to existing forms of diagrammatic information representation in general, we may make the following comments. DS are more structured than general tools like concept maps. However, DS are also less structured than systems like Modelica and bond graphs. These other languages also do not treat the very early stages of product development, such as requirements specification, whereas DS are especially intended for them. Tools that are specific to individual stages, such as DOORS for requirements engineering, are unable to provide continuity of information visualization through many design stages. DS does share some characteristics with other diagrammatic methods, such as IDEF and flowcharts, but DS integrates them into a generalized framework to support a broader range of applications. This promotes the uniform use of DS throughout PDPs, which should benefit designers.

UML is another diagramming system that has been successful in software engineering. UML has little support for requirements analysis, but it does support other early design stages. However, the authors find the abstract symbols used to represent information in UML confusing in conventional engineering settings. We do not discount the future development of a uniform system of “glyphs” for non-software engineering environments, but we find short textual descriptions, as annotations on nodes and links in DS, are sufficient in every circumstance we have considered so far. We believe the issues of a symbol system for design and the development of a diagrammatic tool like DS are independent of each other, and we will treat them as such. We are currently evaluating UML 2.0 [17] which presents a substantially different graphical representation. At first glean, it appears that UML 2.0 is far more consistent with the general diagrammatic structure of DS than the existing version 1.5. It may be that UML 2.0 can be incorporated into DS (or vice versa); however, this point remains an open research issue at this time. Another tool related to DS is the design structure matrix (DSM) [8]. The topological similarities between graphs and matrices bears closer scrutiny than can be afforded here; a detailed comparison of DS and DSM methods will be the subject of a future paper. Still, we believe DS hold five advantages over DSMs. • DS promote learning through direct depiction of graphical networks that reflect the cognitive structures that appear to exist in human minds [10]. • More information can be associated directly with the relations between entities. In DSMs, such information is indicated by the contents of matrix cells; usually, this is a simple mark indicating a relation exists, or a single numeric value. In DS, information about relations can be much more extensive. • DSMs tend to be relatively sparse matrices. In many cases, more than half of the cells in a DSM are empty and the space they occupy on the page or computer screen is wasted. DS use space on the page or screen more efficiently. This makes DS visually more dense containers of information than DSMs. • DSMs have a single visual construct – the matrix cell – to represent all kinds of relations. When different relations are visualized in the same way, it is more possible for the user of the diagram to become confused. In DS, it is possible to use different visual constructs, thus improving the “readability” of the diagrams as well as making them richer information specification mechanisms. • The layout of a DS can communicate a more meaningful overall structure of the design than a DSM (which is limited by the nature of its matrix form). Also, different layouts of the same DS can communicate different kinds of information; there is no equivalent capacity in a corresponding DSM.

8


Experiences in Usage DS is a tool that is under development and it is, to the best of the authors’ knowledge, the first tool of its kind. Therefore, there is no quantitative data available yet for its evaluation. Nonetheless, the authors have used structured diagrams built with existing diagramming software in various teaching and research settings. In a senior undergraduate mechanical systems design course taught by Salustri, students use a PDS diagram to capture and reason about design problems. Students uniformly found the exercise “heavy” because they had had no previous exposure to concept maps. However, they also agreed that their appreciation for the complexity, breadth, and depth of a design problem was significantly improved. Students said they “knew the problem cold,” and subsequently reported experiencing far fewer problems as they designed than they did in other assignments where DS were not used. In research settings, the authors have found that DS help clarify thinking, document activities, and collaborate in teams. We have used DS and DS-like diagrams to study automotive drive trains, small appliances and tools, and small housing structures, as well as to manage research projects. (These experiences will be the subject of a future paper.) Though such demonstrations are unscientific, they do provide some anecdotal evidence to suggest that DS can be beneficial in design environments. We are currently planning a series of experiments to attempt to gauge the relative merits of DS compared to other approaches. There are two difficulties in this. First, because there are no other tools like DS (that we are aware of), it is difficult to find measures against which to assess DS (i.e. DS is “better” or “worse” than...what?). Second, the onerous chore of creating DS by hand can negatively affect subjective assessments of the tool – a software tool able to render DS quickly would be very useful, but we are still pursuing funding to support the development of such a computer tool. IMPACT ON COLLABORATION One of our goals in developing DS is to provide support for concurrent design practices, by creating a tool that can represent a wide variety of information – covering elements from requirements engineering through to systems design – in a manner that is intuitive to as broad a stakeholder community as possible. Perhaps the best way to explain how this might be is to consider one possible long-term vision of the evolution of DS. We hope, in the long term, to develop an intelligent, computerized “white-board”. It would have the appearance of a conventional white-board, on which users can write with markers. However, it would in fact be a large touch-sensitive display connected to an appropriate computer. Instead of markers, one would use styluses. As users draw nodes and links on this device, the underlying software would automatically “tidy up” the drawing layout, rearranging nodes

in accordance with DS rules and depending on the kind of DS being developed. In a design meeting, multiple users can collaborate directly on the electronic white board, adding and rearranging elements of DS as their discussions proceed. Since one is using a computerized tool, we envision having direct connections via the white board to the WWW, where immediate searches of databases and intranets would let the team deal immediately with issues as they arise, and link pertinent resources directly into the DS. Because users would develop DS in real-time in a computerized environment, it would be also possible to use the Internet to transmit and share the evolving diagrams in real-time to remote sites. This would supplement the use of video teleconferencing and Internet-based conferencing tools. While such an intelligent white board system is several years away, it is clear that the underlying capacity to draw, recognize, manage, and manipulate DS is an essential component of the system. Underlying such a facility is the need for a crisp definition of the diagrammatic language of DS – the mapping between engineering information and graphical symbols, and the algorithms needed to lay out the resulting graphs properly. This is what we are currently working on. CONCLUSIONS The authors have introduced a new tool to assist designers, design schematics, which is based on concept maps, augmented with certain features from other diagramming systems. The goal of concept maps is to facilitate the thinking processes of designers, not to automate the design process. The focus of the paper is on the DS representation and not on the admittedly significant computational aspects. Several examples are given to indicate how DS can capture meaningfully information during the early design stages, when (a) little or no information about product geometry is available and (b) decisions have the greatest impact on product performance. Since DS is still under development, there is no quantitative data by which to evaluate the tool. However, some anecdotal evidence gathered by the authors suggests that the tool does have potential to be of benefit to practicing designers. ACKNOWLEDGMENTS The authors graciously acknowledge the support of the Natural Sciences and Engineering Research Council of Canada.

REFERENCES [1] Karnopp, D.C., Margolis, D.L., and Rosenberg, R.C., 1990, System Dynamics: A Unified Approach, Wiley & Sons, New York. [2] --, 1993, “Integration Definition for Function Modeling”, NIST Defence Technical Information Center.

9


[3] Andries, M., and Engels, G., 1996, “A hybrid query language for an extended entity-relationship model,” J. Visual Languages and Computing, 7, pp.321-352. [4] Elmqvist H., Mattson S.E., and Otter M., 2001, “ObjectOriented and Hybrid Modeling in Modelica”, J. Europeen des Systemes Automatises, 35, pp. 1-10. [5] Kulpa, Z., 1994, “Diagrammatic representation and reasoning”, Machine Graphics 3, pp. 77-103. [6] Marshall M.S., Herman I., and Melançon G., 2001, “An object-oriented design for graph visualization”, Software Practice and Experience, 31, pp.739-756. [7] Booch G., 1999, The Unified Modeling Language User Guide, Addison-Wesley, New York. [8] Steward D.V., 1981, “The design structure system: a method for managing the design of complex systems”, IEEE Transactions on Engineering Management, 28, pp.71-74. [9] Novak J.D., 1998, Learning, creating, and using knowledge: concept maps as facilitative tools in schools and corporations, Lawrence Erlbaum Associates, New Jersey. [10] Novak J.D. and Gowin R., 1984, Learning how to learn, Cambridge University Press, Cambridge. [11] Stone R.B., Wood K.L., and Crawford R.H., 2000, “A heuristic method for identifying modules for product architectures”, Design Studies, 21, pp. 5-31. [12] Pugh S., 1991, Total design, Addison-Wesley, London. [13] Dym C.L. and Little P., 2000, Engineering design: a projectbased approach, Wiley & Sons, New York. [14] Suh N.P., 1990, Principles of Design, Oxford University Press. [15] Ulrich K.T. and Eppinger S.D., 1995, Product design and development, McGraw-Hill, New York. [16]Kremer R., 1997, Constraint graphs: a concept map metalanguage, PhD Thesis, Dept of Computer Science, University of Calgary. [17] --, 2003, “UML 2.0 Superstructure, 3rd Revision”, OMG document ad/03-04-01, Object Management Group.

10
