DESIGN INFORMATION FRAMEWORK TO SUPPORT ENGINEERING DESIGN PROCESS by Plamen Iordanov Bliznakov A Dissertation Presented in Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy ARIZONA STATE UNIVERSITY December 199 DESIGN INFORMATION FRAMEWORK TO SUPPORT ENGINEERING DESIGN PROCESS by Plamen Iordanov Bliznakov has been approved November 1996 APPROVED: , Chair Supervisory Committee ACCEPTED: Department Chair Dean, Graduate College ABSTRACT The objective of this research work is to develop a framework for capture and retrieval of engineering design information. The framework is intended to support the following applications: design information and rationale sharing, change propagation, constraint maintenance, design re-use, and design process management, control, and analysis. Part of the data is assumed to be entered by the designer into the developed design information system (DIS), while another resides in CAD models, text files, databases, etc., scattered in a heterogeneous distributed computing environment. The dissertation starts with a review of the related research in the areas of design process and product data modeling and distributed engineering databases. A classification of research approaches and software systems is proposed. Further, the information contents and functional requirements and some specifics of the software environment for the design information framework are clarified. The latter include specifics of CAD and other software products from the viewpoint of their “integration friendliness”, possibilities to exchange data and services with other software components. The proposed model-based and content-based approach to design information capture uses an object- oriented data model. A reduced affinity method is used to identify the major entity classes. They are: Product Data - design parameters, product components and functional units, and associated design methods and constraints; Design Processes - design tasks, sub-projects and projects; Organizational Units - persons, design groups, departments; and Sources of Information - computer files, paper documents, consultations with fellow designers, etc. The design rationale is represented using a specialization of the IBIS method as pros and cons for each entity selections made. The conceptual data model is further mapped onto a physical-level data model. It allows a uniform handling of both data and schema information.To demonstrate the feasibility of the proposed model, a prototype DIS is developed. It can be subdivided from a functional viewpoint into database and user interface managers and application modules. A three-tier implementation architecture both for the shared database and for the user interface manager is proposed. WWW protocols are used to implement distributed information access. The applicability of the developed framework is verified by recording sample data from a representative design project. DEDICATION To my wife Luba for all her patience and love. To my daughter Yana who managed to get born and grow up in half the time needed to complete this dissertation. ACKNOWLEDGMENTS This research was partially supported by the National Science Foundation Scientific Databases Program, with joint funding from the Division of Information, Robotics, and Intelligent Systems, the Division of Computer and Information Science and Engineering, and Design Theory / Methodology Program of the Engineering Directorate (Grant no. IRI-9117143). The author wishes to acknowledge the guidance, help and support from the members of his dissertation committee and foremost his graduate advisor Prof. Jami Shah. Since this work was part of a larger research project, it would have been impossible without the efforts of the author’s colleagues from the departments of Mechanical and Aerospace Engineering and Computer Science and Engineering at ASU who worked on related topics. Among them special acknowledgment is due to Dae Jeon, Prasad Ravi, Hong Liu and their graduate advisor Dr. Susan Urban from the CSE department, and to Mary Rogers, Govind Balakrishnan, and Sohail Qureshi from the MAE department. The work on this dissertation was also facilitated by the creative atmosphere at the department of MAE at ASU, and specifically at the Design Automation Lab, where the author had the chance to work alongside many talented students and researchers from different parts of the world. The author wants to acknowledge as well the influence of the ideas and opinion of a multitude of people both from the industry and academia. An important role was also played by the undergraduate students at ASU who participated in the TVC project and provided valuable test case material and feedback. TABLE OF CONTENTS Page ABSTRACT iii DEDICATION v ACKNOWLEDGMENTS vi TABLE OF CONTENTS vii LIST OF TABLES x LIST OF FIGURES xi NOMENCLATURE xii 1 INTRODUCTION 1 1.1 THE NEED 1 1.2 PROBLEM STATEMENT 3 2 REVIEW OF RELATED WORK 5 2.1 MODELS OF DESIGN PROCESS 5 2.2 MODELS OF DESIGNED ARTIFACTS 13 2.3 DISTRIBUTED ENGINEERING DATABASES 20 3 TAXONOMY OF DESIGN INFORMATION SYSTEMS 23 3.1 APPROACH TO THE DIS TAXONOMY DEVELOPMENT 23 3.2 CLASSIFICATION CRITERIA 25 3.2.1 Level of Sophistication / Functionality 25 3.2.2. Level of Product Data Abstraction 27 3.2.3 Level of Design Process Information Granularity 29 3.2.4 Level of Design Rationale Representation 31 3.2.5 Level of Collaboration/Sharing 32 3.2.6 Information Homogeneity Level 34 3.2.7 Level of Flexibility 35 3.3 CLASSIFICATION OF EXISTING DIS 36 SUMMARY 39 4 ANALYSIS OF FUNCTIONAL REQUIREMENTS 40 4.1 END-USER NEEDS 40 4.2 LIMITED CUSTOMER INTEREST SURVEY 44 4.3 "INTEGRATION FRIENDLINESS" OF DESIGN AUTOMATION TOOLS 44 SUMMARY 49 5 HIGH-LEVEL CONCEPTUAL DATABASE SCHEMA 53 5.1 ISSUES AND ALTERNATIVES 53 5.1.1 Level of formalization 53 5.1.2 Representation Granularity (level of abstraction) 54 5.1.3 Minimal Set of Primitives 54 5.1.4 Design Process, Methods, Constraints, and Rationale Representation 55 5.1.5 Product Data Representation 57 5.1.6 Process and product data links 58 5.1.7.Scope of the DIS Data Model 58 5.2 DATA MODEL REFINEMENT 61 5.3 CONCEPTUAL DESIGN DATA MODEL SPECIFICATION 65 5.3.1. Product Models (Data) 69 5.3.2. Information sources 74 5.4 MODEL VERIFICATION 75 5.5 REPRESENTATION OF COMPOSITE ENTITIES USING DIRECTED GRAPHS 76 5.5.1 Representation of Composite Design Processes and Product Units as Directed Graph Paths 76 5.5.2 Implicit Directed Graph Path Representation 80 5.5.3 Implicit Description of Some Important Features of DPR Graph Paths 82 SUMMARY 91 6 DEVELOPMENT AND IMPLEMENTATION OF A PHYSICAL-LEVEL DATA MODEL AND A USER INTERFACE MANAGER 92 6.1 GENERAL CONCEPTS OF THE DEVELOPED PHYSICAL-LEVEL DATA MODEL 94 6.1.1 Records as Class Instances 94 6.1.2 Multiple Field Occurrences within a Record 95 6.1.3 Static and Dynamic vs. Explicit, Derived, and System Values 96 6.1.4 Class Inheritance and Instance Data Embedding 97 6.2 DATA DEFINITION AND MANIPULATION LANGUAGE 99 6.3 ISSUES, ALTERNATIVES, AND SELECTED APPROACHES IN THE ASUDESIGN_UI DEVELOPMENT 100 6.3.1 Capture Interface 100 6.3.2 Remote Access to DIS and Security 101 6.3.3 Stateful UIMS Based on a Stateless Network Protocol 103 6.3.4 External vs. Internal UIMS 105 6.4 ENTITY INPUT AND MODIFICATION METHODS 106 6.5 FUNCTIONAL INTEGRATION INFRASTRUCTURE ARCHITECTURE 109 6.6 IMPLEMENTATION INTEGRATION INFRASTRUCTURE ARCHITECTURE 110 SUMMARY 117 7 VALIDATION 120 7.1 ORGANIZATION 121 7.2 INFORMATION SOURCES 122 7.3 DESIGN PROCESS REPRESENTATION 122 7.4 ARTIFACT MODEL 124 7.5 IMPLEMENTATION AND SAMPLE QUERIES 127 SUMMARY 128 8 CONCLUSIONS 130 8.1 RESEARCH SUMMARY 130 8.2 RECOMMENDED FUTURE RESEARCH 131 8.3 ORIGINAL CONTRIBUTIONS 132 PUBLICATIONS 134 REFERENCES 135 APPENDIX A. ASUDESIGN_DB SPECIFICATION 142 A.1 INTRODUCTION 142 A.2 ASUDESIGN_DB FILE FORMAT 142 A.3 MULTIPLE VALUE FORMAT 144 A.4 BNF DEFINITION OF ASUDESIGN_DB FILES. 146 A.5 FIELDS COMMON TO ALL RECORDS. 146 A.6 FIELDS COMMON TO RECORDS OF "ATTR" RECORD TYPE. 147 A.7 FIELDS COMMON TO RECORDS OF "CLASS" RECORD TYPE. 152 A.8 FIELDS COMMON TO RECORDS REPRESENTING CLASS INSTANCES 154 A.9 ASUDESIGN_DB DATA DEFINITION AND MANIPULATION FUNCTIONS 154 A.10 SAMPLE DERIVATION PROCEDURE 157 APPENDIX B. USER INTERFACE DEFINITION SPECIFICATION 160 B.1 OVERALL USER INTERFACE DEFINITION FILE STRUCTURE AND SYNTAX 160 B.2 CALL-BACK PROCEDURE PARAMETERS 160 B.3 MENU PARAMETERS 160 B.4 OPTION PARAMETERS 160 B.5 ENTRY FORM PARAMETERS 161 B.6 FORM ENTRY PARAMETERS 161 B.7 SAMPLE USER INTERFACE DEFINITION FILE 164 B.8 SAMPLE CALL-BACK PROCEDURE 166 APPENDIX C. LIBRARY OF SUPPORT FUNCTIONS 170 UTILITY FUNCTIONS 170 CHARACTER STRING ARRAY FUNCTIONS 170 COMMON-GATEWAY INTERFACE (CGI) FUNCTIONS 172 HYPERTEXT TRNASFER PROTOCOL (HTTP) CLIENT FUNCTIONS 173 Basic Functions 173 Extended Functions 173 FUNCTIONS RELATED TO THE MATH EXPRESSION EVALUATOR 175 LIST OF TABLES Table Page TABLE 1. CLASSIFICATION OF RELATED RESEARCH WORKS ACCORDING TO THE DEVELOPED TAXONOMY. 37 TABLE 2. CLASSIFICATION OF EXISTING DIS ACCORDING TO THE DEVELOPED TAXONOMY. 38 TABLE 3. RESULTS FROM A LIMITED CUSTOMER SURVEY. 43 TABLE 4. TAXONOMY OF APPLICATION SOFTWARE ACCORDING TO ITS "INTEGRATION FRIENDLINESS". 45 TABLE 5. VOCABULARY EXTRACTED FROM A SINGLE CASE STUDY 63 TABLE 6. REPRESENTATIVE LIST OF ENTITIES 63 TABLE 7. POSSIBLE MAPPINGS BETWEEN THE COMPONENTS OF THE FUNCTIONAL ARCHITECTURE AND THE COMPONENTS OF THE IMPLEMENTATION ARCHITECTURE. 112 TABLE 8. PRODUCT CLASS DEFINITION AND INSTANCE DATA FOR TRANSMISSION AFTER TASK #47B 126 TABLE 9. FIELD KEY SYMBOLS PERTAINING TO MULTI-VALUED FIELDS OCCURRING MULTIPLE TIMES WITHIN ONE RECORD 143 TABLE 10. FIELD KEY LETTERS. DIFFERENT TYPES OF FIELD VALUES ARE SHOWN IN THE ORDER OF THEIR PRIORITY FROM LOWEST TO HIGHEST 144 LIST OF FIGURES Figure Page FIGURE 3.1. A DIS CLASSIFICATION HYPER-SPACE DEFINED BY SEVEN ORTHOGONAL CLASSIFICATION CRITERIA 25 FIGURE 5.1. AN ALL-INCLUSIVE GLOBAL CONCEPTUAL VIEW OF DESIGN DATA 59 FIGURE 5.2. SELECTIVE GLOBAL CONCEPTUAL VIEW OF DESIGN DATA 60 FIGURE 5.3. HIGH-LEVEL SCHEMA OF THE DESIGN PROJECT DATABASE 66 FIGURE 5.4. CONSTRAINT CLASS AND SUBCLASSES. 71 FIGURE 5.5. FUNCTION CLASS AND SAMPLE SUBCLASSES 72 FIGURE 5.6. SAMPLE FUNCTIONAL REPRESENTATION OF A CANTILEVER BEAM SUPPORT 73 FIGURE 5.7. ONE OF THE POSSIBLE VIEWS AT THE DESIGN PROCESS 76 FIGURE 5.8. A LOOP REPRESENTING ITERATIONS IN A DESIGN PROCESS 77 FIGURE 5.9. PARALLEL BRANCHES OF A SINGLE DESIGN PROCESS 78 FIGURE 5.10. REPRESENTATION OF A GRAPH NODE 81 FIGURE 5.11. TRAVERSAL ALGORITHM : ON EACH STEP NODE INSCRIPTIONS ARE COMPARED TO STATUS STACK CONTENTS 82 FIGURE 5.12. N-ARY TREE STRUCTURE REPRESENTATION 84 FIGURE 5.13. LINEAR STRUCTURE REPRESENTATION 85 FIGURE 5.14. ADDING AN ITERATION LOOP TO THE GRAPH PATH (NUMBER OF ITERATIONS NOT KNOWN IN ADVANCE) 87 FIGURE 5.15. OVERALL LINEAR STRUCTURE WITH OR-BRANCHING 89 FIGURE 5.16. IMPLEMENTATION OF OR-BRANCHING WITHOUT USE OF THE PERCENT SIGN '%' 90 FIGURE 5.17. IMPLEMENTATION OF AND-BRANCHING 91 FIGURE 6.1. OVERALL ARCHITECTURE OF INTEGRATED INFRASTRUCTURE IMPLEMENTATION. 112 FIGURE 6.2. CLIENT SITE ARCHITECTURE. 113 FIGURE 6.3. INFORMATION REQUEST BROKER SITE ARCHITECTURE. 115 FIGURE 6.4. INFORMATION SERVER SITE ARCHITECTURE. 116 NOMENCLATURE CAD - Computer-Aided Design CAM - Computer-Aided Manufacturing CGI - Common Gateway Interface DBMS - DataBase Management System DIS - Design Information System DP - Design Process DPR - Design Process Representation DR - Design Representation EDM - Engineering Data Management FEM - Finite Element Modeling NC - Numerical Control oid - Object Identifier PDM - Product Data Management UI - User Interface UIMS - User Interface Management System URL - Uniform Record Locator, location (address) on the WWW WWW - World-Wide Web 1 INTRODUCTION 1.1 The Need Recently, a considerable attention to design process and rationale representation has been devoted by both academia and industry. Several factors determine the importance of information. First, together with the product data from previous projects, it is an important component of the design knowledge which a company accumulates over the years. The design knowledge gives companies a competitive edge in new developments. However, the companies typically do not have that knowledge adequately represented and organized. It remains scattered throughout many different media, from designer's sketch pads and notebooks, to computer files on various machines, and to individual designer minds. The lack of an adequate representation often causes parts of the design knowledge to be lost since employees leave the company, or simply because new projects do not immediately involve participants from old ones. Second, to reduce the time to market companies employ the principles of concurrent engineering. As a result, groups of designers from different disciplines (and sometimes from different companies), occasionally at physically distant locations may work in parallel on a single project. Keeping each participant informed about the relevant changes in the design and the rationale behind the changes becomes an important issue. Third, the companies tend to increase product support throughout its life cycle. The concept "Lust-to-dust" (i.e., from recognition of the need, to product disposal) reflects a more comprehensive understanding of the term "life cycle". Throughout the life cycle a company might need to make a number of changes in the product design. Practical experience shows that the changes either require a lengthy review procedure or cause unexpected and often undesirable effects. Structured DPR provides a number of benefits : it facilitates the control of a design project and the communication among the designers as well as between designers, customers, and suppliers; it improves corporate training of new designers; re-use, verification and auditing of past designs can be enhanced, etc. DPR can also be used to "roll back" to previous versions of the design. Such application as design knowledge acquisition can benefit directly from the development of a machine-understandable DPR as well. One important applications of DPR is storing the design history (DH) for future use in similar projects as well as to provide valuable generalized information about the design process. For these purposes, the description language has to represent not only the activities, objects and subjects involved in the process, but also the rationale behind these actions. Although a natural language coupled with generic graphics provides a high degree of flexibility, a formal, structured, and computer interpretable language can support more complex queries. DH representation, however, is not the only application of a DPR framework. Capturing the sequence and parameters of computer-aided activities can be used to automate some of the procedures, so that the application of iterative methods to solve a design problem become easier. Moreover, the development of design automation software can be facilitated. Again, these benefits can be achieved only if the DR is machine understandable. The modeling of a design process inevitably requires referencing product data which must have an adequate level of machine interpretability. In fact, some authors regard the design process as a special case of information processing. In that sense, disregarding the representation of the product model in a design process description would be analogous to skipping the data definition and leaving only the specification of the algorithms in a program description. Many different aspects of a product have to be modeled (hence, many different aspects of product models). Although not all product aspects necessarily generated by a computer program or stored on computer media, the following representations of a product are often referred to in the literature : functional model, assembly model, tolerance model, feature model (with various interpretations of the term "feature”), shape representation. The shape model typically includes topology and geometry of components. The two most widely used nowadays schemes for shape representation are boundary representation (B-rep) and constructive solid geometry (CSG). Other modeling schemes are occasionally preferred for some applications (e.g., octrees). The B-rep scheme stores components as a set of geometric entities (e.g., mathematical surfaces of some type, lines / curves "on" these surfaces, and important points with their coordinates), and topological entities (e.g., shells enclosed by surface faces, which themselves are enclosed by edges connecting vertices). The CSG scheme represents solids as a result of Boolean operations (union, difference and intersection) on a set of properly oriented primitives (e.g., boxes, frustums, spheres, torii, etc.). In practice the two schemes are often used together in a single program and data is converted from one representation to another. Such a combination is often referred to as "hybrid" representation. The feature model stores the engineering semantics behind shape elements. The semantics itself exists at different levels - from form features (which are similar to shape representation and in fact denote special cases of shape patterns) to application features. Tolerances add additional information to the feature model. They represent the allowable variation in the nominal shape of the components. The assembly model represents the relationships and constraints between components. The functional model has the highest level of abstraction and carries more semantics than other models enlisted above. It describes the functions of the whole product and its subsystems at various levels of abstraction. Some aspects of the product model are well-understood and there is a broad consensus on their representation within the design community. For example, the geometry representation is a well-developed aspect, although new methods for geometric modeling and their corresponding representations are still explored by researchers. Unfortunately, many aspects of design product description are less well- established. An example of such an aspect is the modeling of function and design intent. Besides product data, technical knowledge also constitutes an important company asset. According to (Shah91a), technical knowledge is expressed by heuristic design rules and captures knowledge about the generic steps, sequences, and dependencies of the design process. 1.2 Problem Statement The objective of this work can be formulated as follows: Develop a framework for capture and retrieval of routine mechanical engineering design information. The framework should support association of design process data (including the decisions made and rationale influencing these decisions) with product representations, constraints, and other related information as the artifact evolves. The representation should be well-suited to support various applications in the engineering design process. The objective can be achieved through the accomplishment of several goals: • To review, analyze and classify the related work in Design Theory and Methodology, Information Processing Theory, Modeling of Information Systems, etc. • To consider the various alternative solutions of the problem of DR and evaluate their advantages and disadvantages; select a feasible solution • To develop a DR conceptual data model at generic, non-specialized level to capture the information in a computer-intelligible format that would support various views at the DP and related data and various levels of abstraction for each view • To develop information integration infrastructure architecture and protocol to support the conceptual data model • To identify user interface operations and develop a UIMS with hypermedia browsing interface that allows access to DR from various viewpoints as well as formulation of high-level queries using a query-by-form interface • To demonstrate the feasibility of the proposed DR schema and infrastructure architecture by implementing a prototype DIS • To test the proposed framework and the implemented DIS on a case study 2 REVIEW OF RELATED WORK 2.1 Models of Design Process The DP models (and the research approaches they are result of) differ most generally depending on the stated objectives which the researchers pursue. The interest in DP modeling until recently was motivated by two major objectives: improve DP by suggesting an "optimal" model for that activity, and describe DP "as is" (Finger, Dixon 1989; Cross 1989). The former involves the development of so called "prescriptive models" to guide the designers "how to better go through the design process".(e.g., (VDA 1987)). The latter was first stimulated by the idea that design theory is a young science (at a pre-theory stage) and needs to be studied by empirical techniques to see how designers actually work. This objective was reflected in so called "descriptive models". One of the anticipated outcomes of this better understand of the DP was the development of improved design support tools. For example, in recent years descriptive models have been used to archive design procedures for the purposes of re-using the information for similar design problems in the future. The descriptive approach is based on observation of cases of design, and, more generally, of problem solving. The methods used in descriptive model development are : protocol studies of individual designers, development of cognitive models, case studies of design processes (including team activities), and other descriptive models. Prescriptive models try to provide a "recipe" for the design process. According to the canonical design process, the design problems can be divided into original or new, transitional or adaptive, and extensional or variant. Several major stages of the design process can also be outlined: need recognition, requirement specification, concept formulation, concept selection, embodiment design, production, maintenance. Three phases of thought include divergent, transformational, and convergent. According to studies done in Design Theory in Methodology area, the prescribed models are not strictly followed in practice. Some of the prescriptive design methodologies are: morphological analysis, prescriptive models for the design artifacts, axiomatic design, quality loss (Taguchi 1986). It can be pointed out that the line between the descriptive and prescriptive models of the DP is somewhat blurry. Even though prescriptive models are supposed to answer the question “how the process should be carried out”, they to some degree are based upon the past experience of the author(s), who either observed designers or designed themselves. At the same time, the works under the descriptive paradigm are also aimed at the development of some recommendations (i.e., prescriptions). Some taxonomies of DP models (e.g., (Finger, Dixon 1989) also add a third category, computer-based models. They are aimed at the development of automatic / automated design procedures. They include parametric design, configurational design, conceptual design, and models for distributed design problems. A computer-based model expresses a method by which a computer may accomplish a specified task. As can be seen from the definition, a computer-based model can be descriptive and/or prescriptive at the same time. Rather than classify a model as computer-based depending on its contents or the way it was developed, it is being done based on whether the model is detailed enough to be coded as a computer program. Since the present work aims at recording the DP "as is", a review of the research in the area of descriptive process modeling is done further in this section. The researchers take different views at the DP. Each view focuses on one aspect of the DP or another and can be more or less abstract. Since each model of a DP (as any other model) is an abstraction of the original, it differs from other models depending on the researcher’s viewpoint. One of the approaches for recording a DP is to represent it as a series of design operators as in the TEAM model proposed by Ullman (Ullman 1989). This work proposes a taxonomy of different design sub- processes (as viewed from the overall process perspective) in mechanical design. The author suggests a scheme which provides a framework for description of the sub-processes. The scheme includes fixed set of fields with a limited number of possible values for each field (although the author expects the set of values to be extended in the future). The problem being solved is described by its initial and final states, as well as the satisfaction criteria. Each of the description of the states includes refinement level and representation of the problem. Design process description includes the plan, processing action, effect, and failure action. The proposed taxonomy of design (sub)processes has certain advantages. It allows different activities to be compared. Assuming that after further refinement all possible values for the data fields can be enumerated, the taxonomy provides a foundation for structured representation of the design process. However, the rigid data structure does not reflect the actual diversity in design activities. Some of the fields will be irrelevant to particular processes, while others will be missing. The design operators from the TEAM model are further modified for practical use in the language for design procedures specification provided by the ASU Design Machine (Shah, Sen, Ghosh 1991) developed at the ASU DAL. Five generic types of steps are available in the language: function step, lookup step, input step, calculate step, and rule step. The atomic design steps are further being combined into design sequences, which in turn, comprise design procedures. One or more procedures can be associated with a given part class (e.g., gear). Each design procedure may calculate some or all parameters of the part. The language provides all the necessary facilities to specify major design activities which can be performed automatically. It lacks means for (and is not intended to) specify design activities not performed by the computerized system (e.g., interaction between designers). There is also no mechanism for recording rationale for each action. A similar approach representing a DP as a series of operators was undertaken by (Mueller 1990), although the model is not computational. In this work, 110 actions are identified (some of them being repeated with different meaning under various categories). They are classified into 21 groups of activities, with 3 groups having no entries (so the group headings for these groups are activities of their own). Some large groups of activities are devised into subgroups (e.g., Inform activities are subdivided into Internal to the designer and External-oriented). In other words, there are one, two, or three levels of abstraction for each activity. The classification covers a broad range of activities: from those performed at the initial stages of design to those ending the design process, from highly abstract to very specific, from individual to group. Several approaches to DPR take a more general view at the DP emphasizing one of its different facets. By doing so, they apply existing techniques for archiving a more general class of processes (e.g., documentation, decision making, knowledge rule application, information flow processes, etc.). The models reviewed below take one single view of the design process One of the approaches is considering the DP to be a specific case of a documentation procedure. In this case an organized document repository (drawings, notes, software output, etc.) is considered a sufficient reflection of the design history. The research issue in this approach is how to index the documents (Baudin, Underwood, Jody G.; Baya, Vinod; Mabogunje 1992; Baudin, Kedar; Underwood; Baya 1993; Baudin, Underwood, Baya 1993). A framework for classification of the questions asked by two designers in a behavioral study (and, hence, classification of the design information which answers the questions) was proposed in (Baya, Gevins, Baudin, Mabogunje, Toye, Leifer 1992). The objective of the research was to determine what information is important for design re-use and has to be recorded. The questions were classified according to 4 criteria: descriptor, subject class, criticality, and level of detail. A vocabulary for indexing formal and informal design information was developed. Most of the questions were classified successfully, although some were classified as "miscellaneous" and "other" under the first two criteria. The classification scheme proves to be the critical in this approach. Some researchers regard the DP as a specific case of decision-making process. The IBIS (Issue Based Information System) method (Rittel, Webber 1973) is a general, domain-independent and most broadly used approach to describing such processes (Moran, Carrol 1996). When applied to the DP, it considers it a negotiation process between different groups of people (e.g., designers, managers, customers, etc.). A design problem is represented as a sequence of issues. There might be different positions on each issue. Each position can have several related pros and cons (arguments). Each issue can suggest other issues, or be specialized or generalized into issues. A hypertext-like graphical tool gIBIS (Conklin, Begeman 1988) supports the IBIS method. It allows the user to browse through the graph structure representing the decision process, as well as to formulate simple queries specifying attribute values of a node in interest (e.g., author, date, etc.). The IBIS method assumes that formal specification of design objectives, rationale, etc. is not possible, so a textual representation is used. This assumption makes the approach generally applicable even to cases of initial stages of design. However, the objectives are not computable, so that the designer has to browse through the hypertext representation of the design process in order, say, to reuse it. The IBIS method was successfully applied for description of software development process (Yakemovic, Conklin 1989, Yakemovic, Conklin 1990). However, in some works in the area (e.g., (Mylopoulos, Bernstein., Wong 1990)) it is pointed out that besides the knowledge about design decisions and their justification, other information has to stored as well (e.g., data on the development process itself, including the methodology used, the team of developers implementing the software, etc.). An extension of the IBIS method which makes it more applicable to the description of mechanical engineering design process was proposed in (Ullman 1991) and (Nagy, Ullman, Dietterich 1992). The suggested enhancements include adding data about the design development constraints, functions, and the structure of the product and its components. Another extension to the IBIS notation are presented in (Potts 1996). The author explores and compares the possibilities to model design methodologies. A different design rationale notation called DRL (Decision Representation Language) is proposed in (Lee, Lai 1996). The authors compare the expressive power of DRL to that of IBIS and demonstrate the superiority of DRL. As a drawback, DRL is more complex to use. A Simpler notation called Questions, Options, Criteria (QOC) is proposed in (MacLean, Young, Bellotti, Moran 1996). It is based on the design space analysis method and associates possible fields within the design space with the design rationale. While IBIS is somewhat oriented towards rationale capture during the design process, QOC is intended to be constructed post factum and does not necessarily reflect the design process. A more formal representation of design rationale is proposed in (Ganeshan 1992). In this work, a design problem is represented as a conjunction of objectives. An objective is a desired characteristic of the design product; it is a relationship over variables and may be constraint (equality or inequality) or minimization / maximization of a variable. Objectives can be modified / introduced at any point of the design process and may have importance associated with them (as ranking or weights). The design process is characterized by 5 activities: Focus, Refinement, Evaluation, Selection, and Contradiction Resolution. A context for a design decision includes objectives used in the refinement, alternatives generated, objectives used in evaluation, evaluation matrix, importance information and criteria used for selection, and current bindings of the variables. The approach has the advantage of archiving the sequence in which decisions were made, and it provides explicit representation of objectives and alternative decompositions. Decisions affected by a change can be determined. The approach assumes that all objectives, selections, etc. are computable. Its applicability is limited to cases when design space can be characterized in a computable way and objectives can be defined over the design space. Also a single designer / single task situation are assumed. The DP can also be viewed as an information exchange process. Representation of Information Systems (IS) and the data flow within them dates to the early days of software engineering and block diagrams. The term "structured analysis" and the notation for representation of information flow in a form of Data Flow Diagrams (DFD) were introduced in (DeMarco 1978). Contributions to structured analysis were made in (Page-Jones 1988), (Ward, Mellor 1985), (Hatley, Pirbhai 1987), (Ross 1977), etc. (Ross, Schoman 1977) presented the Structured Analysis and Design Technique (SADT). SADT is a graphics language which allows to represent system components and interfaces by boxes and arrows. Multiple levels of detail are representable using this notation. In 1978 the US Air Force started Integrated Computer Aided Manufacturing Program (ICAM). The objective of this program was to increase manufacturing productivity by a broad application of computer technology. SADT was used as a basis for the development of ICAM definition methodology (IDEF). The IDEF techniques include : • IDEF0 for function modeling (IDEF0, 1993) • IDEF1 for information modeling; the technique was enhanced in 1983 to form IDEF1X (IDEF1 Extended) for semantic data modeling (IDEF1X, 1993) • IDEF2 for dynamics modeling • IDEF3 for process modeling (Mayer, Cullinane, deWitte, Knappenbergher, Perakath, Wells 1992) The basic modeling concepts in IDEF0 are functions (represented by boxes) and interfaces (represented by lines). Interfaces are classified as inputs to functions, outputs, controls and mechanisms. Inputs are transformed by a function into its outputs. Controls influence or determine the function, while mechanisms are the tools performing the function. IDEF0 allows multiple levels of detail. Each function box can be decomposed into a number of functions with corresponding links at lower level of detail. A typical number of function boxes in a diagram is between two and six. However, IDEF0 doesn't provide means to represent information such as "this two diagrams represent alternative function decomposition". IDEF3 was specifically created to model processes. In addition to functions (called units of behavior - UOBs) and links between them, this model introduces the concept of a junction box. Junction boxes are used to model the logic of branching of activities within a process. There are 3 types of junction boxes: and (&), or (O), and exclusive or (X). An and-box indicates that there are several parallel branches of activities and all of them have to be performed in order to complete the overall process. Exclusive or junctions denote that one and only one of the alternative branches has to be performed. Or junctions indicate that there are several alternative branches of activities; any one or more of them can be performed in a specific instance of the overall process. While IDEF3 was designed to represent processes, it also offers improved modeling capabilities with respect to IDEF0 and can be used to better represent the functionality of a system. In particular, alternative function decomposition can be defined using this technique. Not all semantic information is representable (or concisely representable) in IDEF3. For example, there might be 3 sequential activities in a process: activity A with 3 alternatives activity B with 2 alternatives, and activity C with 3 alternatives. IDEF3 cannot represent concisely such information as "alternative A1 can be combined with B1 and either C1 or C2, A2 is compatible with any one of B1 or B2 and C2 or C3, and A3 is compatible with B2 and either of C1 or C3". Such semantic information can only be represented using IDEF3 by describing in full all possible combinations as separate branches of the design process. Another example of a constraint not representable in IDEF3 is the number of iterations through a cycle. There can be a maximum permitted number of traversals through a cycle, or the number of iterations might be fixed and known in advance. While the IDEF techniques provide powerful modeling tools, they have not been adequately used in practice so far. In their analysis of IDEF, (Colquhoun, Begeman 1993) and (Kusiak, Larson, Wang 1994) point out the insufficient attention paid to data collection and model analysis. (Busby, Williams 1993) identifies the limitations of process modeling such as: lack of quantitative data, subjectiveness, and triviality of model query results. In an attempt to broaden the use of IDEF techniques, Kusiak et al. present algorithms for IDEF model analysis in (Kusiak, Larson, Wang 1994). These algorithms operate on an activity-activity incidence matrix and the corresponding directed graph representing the relationships between activities in the design process. IDEF0 and IDEF3 models are used for generating the matrices and graphs. The algorithms triangularize activity-activity incidence matrices to identify cycles and concurrent activities. The results can be used to eliminate avoidable cycles. The design (or, more specifically, the redesign) procedure can also be viewed as an optimization process. Such an approach is taken, for example, in the development of the domain independent shell for iterative redesign Dominic (Dixon, Howe, Cohen, Simmons 1987). Its scope is limited to "redesign problems", which are intellectually manageable and solvable without subdivision into smaller parts. Dominic is a hill- climbing algorithm. What makes it different from a standard optimization is the flexibility of its input language. Design problems for Dominic are basically defined in terms of problem specification parameters, design variables which are changed during the design process, performance parameters, analyses procedure, dependence between performance parameters and design variables, performance satisfaction scales, and constraints on design variables and / or problem specification parameters. Initial values of design variables are assigned through initial design procedure if one is available. Further, the inference engine changes the values of design variables, one at a time, to get satisfactory values for the performance parameters while obeying the constraints. Domain experts provide problem specification parameters, design variables, performance parameters, their priorities and satisfaction scales, etc. Dominic could be made more practical if it is coupled with a design process recording system which would capture the problem specification and its solution "on the fly". The Design Sheet project (Reddy, Fertig, Smith 1996) targets the early (conceptual) stages of the design process, although there us nothing prohibiting its use in later stages of the product development. Design Sheet is an engineering design and analysis tool (essentially, a constraint solver). The underlying approach represents the DP as a process of solving constraints between design variables. It uses the resulting constraint network to automatically derive computational procedures for performing user- specified tradeoff studies. By decomposing large constraint networks into smaller pieces that can be solved robustly, this approach can solve large systems of non-linear equations present in practical system models. The tool allows the user to change the inputs and outputs for the model without explicitly specifying a computational procedure. The authors claim that "no significant computer tools are available in conceptual design that provide the flexibility and risk management facilities envisioned by this program". This appears to be an overstatement. The functionality of Design Sheet is somewhat similar to commercial tools like Mathematica and TK-Solver, or spreadsheet programs. The advantages of Design Sheet seem to be its facilities to propagate uncertainty values as well to optimize the values of some of the design parameters. Such features as interfaces to other design tools, multi-user support, networking support, and versioning of constraint models are not mentioned in the publicly available text. It seems reasonable to assume that those features are not included in Design Sheet since the focus of the project was elsewhere. 2.2 Models of Designed Artifacts Many different aspects of a designed artifact have to be modeled (hence, many different aspects of product models). Although not all product aspects necessarily generated by a computer program or stored on computer media, the following representations of a product are often referred to in the literature : • functional model • assembly model • tolerance model • feature model (with various interpretations of the term "feature") • shape representation The state of the art in various aspects of product modeling is well-reflected by the results of the undergoing international effort to standardize product data for exchange purposes STEP. The objective of STEP is to provide a mechanism for neutral data exchange of all aspects of product information needed throughout product life cycle (not just geometry) (ISO10303-41). By the separation of logical and physical levels of data representation, the standard can be used not only for file exchange between CAD/CAM systems and archiving, but also for implementation of integrated product databases. In fact, STEP represents a series of International Standards (Parts of ISO 10303). Portions that are already international standards include some basic parts (e.g., Overview and Fundamental Principles, EXPRESS Language Reference Manual) as well as issues studied well enough during development of previous data exchange standards (e.g., Shape Representation, Product Structure Configuration, Drafting). Part 42 of STEP provides means for explicit representation of the shape of product model (ISO10303-42). The major sections in this part are: geometry, topology, and geometric shape models. The geometry section provides means for representation of curves and surfaces. The most basic geometric entities are point and direction. The remaining are defined directly or indirectly by them. Among the curves are lines, conics, general parametric curve (represented by B-spline curve entity), and some reverentially (or procedurally) defined curves (e.g., offset curve defined as a pointer to existing curve, distance along its normal, and direction). Stretches of different types can be combined by means of composite curve (the latter provides facilities to define the continuity at the transition points). B-splines were selected for free-form curves representation as most universal and well developed type. Bezier curves, for example, can be described as a B-spline with appropriate parameter values. All curve types provide clear parametrization which allows to specify a point on a curve (and, thus, trim it if needed, especially, an infinite curve) by specifying parameter value. The surface types supported are: plane, spherical, cylindrical, conical and toroidal surfaces, surfaces of revolution and linear extrusion, and, as with curves, B-spline type to represent free-form shapes (which allows representation of all types of polynomial and rational biparametric surfaces). Other analogous of corresponding curve types are trimmed, offset, and rectangular composite surfaces. Ruled surface type is not included in the standard. However, ruled surface with B-splines as boundary curves, can be represented as a B-spline surface. A common scheme for both 2-D and 3-D objects is used. Only one single (and most stable, according to the developers of the standard) form of representation for each entity type is selected. Hence, there are no means to represent different geometric constraints specified explicitly by the operator (end-user of a geometric modeling system). Such possibilities are envisioned in an further extension of STEP. The topology section deals with connectivity relationships. The fundamental entities are vertex, edge, path, loop, face, and shell. In cases where constraints applied to shell are too strong, connected edge set and connected face set can be used instead. For effective representation of faceted B-rep models (models in which faces are planar polygons bounded by straight line edges) the poly loop entity was added to the standard. Both geometry and topology can be used separately (e.g., topology representation only is important for defining a wiring diagram). Also, the topological entities can have associations with geometric elements (vertex, edge, and face can be associated with point, curve, and surface correspondingly). The geometry and topology representations are broadly used by the different forms of shape model. The major geometric shape models addressed by the standard are traditional constructive solid geometry (CSG) and boundary representation (B-rep). Spatial occupancy models (e.g., octree models) are not included in the standard. In CSG models are represented as Boolean expressions in which operands are involved in Boolean operations (union, intersection, and difference). The operands can be Boolean expressions themselves or CSG primitives. Solid primitives defined by the standard are: block, wedge, cone, cylinder, sphere and torus. In addition, half-space solids (semi-infinite solids bounded by a surface) and swept solids (solids of revolution and ones of linear extrusion) are allowed. Normally, solids should be defined in their final position, although there exists facility to copy their instances at new location / orientation. The B-rep models are the ones which extensively address the geometry and topology descriptions. The manifold solid B-rep imposes some constraints on the model: no "hanging" faces or edges are allowed (ones which do not bound solids and faces correspondingly) and all vertices are required to lie on edges. Faceted B-rep (model in which all faces are planar polygons bounded by poly loops) is a particular but most often encountered case and is specifically addressed by the standard. Non-manifold models, as well as ones originating from non-solid (e.g., wireframe) modeling systems, can be communicated through some other entities provided by the standard: shell based surface model, face based surface model, shell based wireframe model, edge based wireframe model, geometric 3D surface set, and geometric 3D curve set. The purpose of Part 47 of STEP is to define the information required to tolerance the shape of objects represented as 3-D geometric models (ISO10303-47). Tolerances are assumed to be "attached" to already existing 3-D geometry (typically, the B-rep), or to some geometric constructs which can be derived from shape description (e.g., centerlines of holes). In that sense this part relies in large extent on information defined in Part 42 and 43. Shape variation tolerances considered can be broken into two major groups: geometric tolerances and coordinate tolerances. Geometric tolerances include tolerances of surfaces' and curves' form, e.g., flatness, cylindricity, circularity, as well as tolerances of relative position (orientation and location), e.g., perpendicularity, parallelism, concentricity. Coordinate tolerances represent the traditional plus-minus tolerances and include the fit tolerances as a subset. Surface finish / surface roughness specifications are not included in the part, as well as tolerancing of all non-mechanical properties (e.g., tolerances of electrical values). The part deals with tolerances only from the viewpoint of definition of tolerance types and usage. It does not cover such aspects as tolerance representation (which is subject of Part 202: Associative Drafting) as well as good tolerance practices. A STEP Part 48 was intended to provide specifications for form feature representation. This part was eventually dropped out of the standard, but the preliminary text provides a good reference. According to that text (ISO10303-48), a form feature is a shape which corresponds to some preconceived pattern or stereotype, is of wide industrial interest, and, from the viewpoint of some application, it is desirable to handle it as an instance of this stereotype or pattern. The standard defines 2 schemas for data specification: form feature schema and form feature representation schema. Each one of them can be used separately. However, the form feature representation schema is in fact the one which actually provides the method for unambiguous specification of the shape of the features described under the first schema and, thus, augments it significantly. The preliminary text of this part of the standard dealt with rigid-body nominal shape only. It didn't cover association of non-shape information with the shape. "User-defined" features were not covered also. According to the form feature schema, the form features belong to one of the three large groups: volume (additive and subtractive) features, transitions (edge and corner blending), and feature pattern (features placed at equal distances along a line, circle, at nodes of a 2-D or 3-D grid, etc.). Each form feature has a "type" - a text label attached to it, as well as a set of parameters. The form feature type may be used to specify the particular kind of feature in question (e.g., "thread", "spline", etc.). However, the writers of application protocols were expected to define the particular character strings to be used in each case (Kramer 1992). The form feature schema allows references to single elements of the features (e.g., bottom of a depression). Generally speaking, all form feature representations with one exception are implicit, i.e., the data describing each feature allow to re-evaluate the geometric model (this, however, might not be required by the application). For example, a pattern of holes "drilled" at equal angular distance along a circle can be represented by a pointer to the "base" hole, the centerline of the pattern, angular distance, and the number of holes. The B-Rep can then be re-evaluated; however, for a drafting application it might be sufficient to draw just the centerlines of all holes and add a comment (e.g., ".45 DIA THRU 6 HOLES"). The exception is enumerative representation, which can be explicit (actual geometric elements are enumerated) or compound (all enumerated representations are form feature representations). Besides the enumerative representation there are volumetric representations, edge and corner blendings and replications (single or in a geometric pattern). Among the volumetric representations sweeping is best developed. It allows to define a shape as a surface swept by a profile while moved along some directress (in/out or along a pre-existing surface, or axisymmetric sweeping around an axis). Implicit representations for many profiles of wide use in engineering practice are specified in particular. However, profiles of such standard features as gears, splines, and threads are not among them (in fact, applications do not usually need to evaluate the exact geometric model of these features). The representation is also not quite appropriate for definition of sweeping along a helix (e.g., threads and helical gears) (Kramer 1992). As opposed to product data aspects discussed above, such areas as function modeling are not considered yet within the PDES/STEP effort (Ryan 1992). A popular general definition a product function is "transfer of material(s), energy, and/or signal(s)" (VDI 1987). However, this definition excludes such functions of a product as aesthetics, or insulation (the latter being basically prevention of transfer of material(s), energy and/or signal(s) ). The Bond Graph method (Dransfield 1987; Karnopp, Margolis, Rosenberg 1990) attempts to model in a unified way the presence and the interaction of effects which influence the dynamic performance of a system, regardless of the type of that system. The same ideal components are used to create models of different systems, e.g., mechanical, electrical, magnetic, hydraulic, pneumatic, thermal, etc. The model can further be used to formally prepare a corresponding set of equations describing the system’s dynamics. The set can be used to simulate the system using a computer. Standard product components and whole artifacts can also be modeled as instances of pre-defined classes. Each of these classes is characterized by a set of attributes. In that case, the models carry an even higher level of semantic information as they describe not only the shape, features, tolerances and the assembly information of the artifact, but what standards does it correspond to, possibly, the vendor, price, etc. For example, an instance of a ball bearing can be specified by its bore, outer diameter, thickness, material, vendor, part number, and price. Similarly, a certain type of motor can be specified by its peak torque, peak torque power, friction torque, motor constant, time constant, temperature rise per Watt, rotor inertia, outer and inner diameter, length, weight, vendor, part number, and price. PartNet (PartNet 1996) is using such representation to put catalog data about components on the WWW. The system has a taxonomy of components. The top level classification currently divides all components into three broad categories: Electromechanical, Electronic, and Mechanical. The taxonomy can be several levels deep (e.g., Electromechanical - Motor - Brushless). Selecting component category can be done either by browsing through the hierarchy of categories or by using a string matching (including wildcard character strings) search. Once a specific component category is selected, the user can specify a constraint involving specific instance attribute values (e.g., some attribute has to be greater than a certain value, some should be equal, etc.). As a result, PartNet will provide catalog data for the components in the selected category and matching the specified constraints. A specific instance can be selected by the user and associated files (e.g., corresponding pixel image, CAD models, etc.) can be retrieved. PartNet is implemented through gateways to various supplier databases. Its implementation assumes data retrieval and interpretation by a human user, although the concept can be upgraded to allow easier interpretation of the output information by computer applications. Lack of any structured representation of associated design procedures can be pointed out as a shortcoming of PartNet in its current form. The classification scheme is critical for this modeling approach. It is appropriate for standard components for which there is a consensus (or, at least, broad understanding) among suppliers and customers about the ontology to be used. However, for less standardized artifacts there could be differences (including differences in terminology among users from different disciplines). One approach to solving this problem is to allow users to extend existing ontologies (Olsen, Cutkosky, Tenenbaum, Gruber 1994, Fruchter, Reiner, Leifer, Toye 1996). Another approach is to use AI techniques to induce automatically the classification based upon the syntactic patterns contained in a design document (Dong, Agogino 1996). Yet a different approach is to provide a less formalized description of the artifacts and let the users do the interpretation. For example, IndustryNet (IndustryNet 1996) stores information about standard components and their manufacturers in hypertext files. It then allows the users to search through these files by keywords. As in the case of PartNet, gateways to suppliers’ data servers are provided. 2.3 Distributed Engineering Databases The research in engineering database development started back in early 1980s with such works as the ones published in (Encarnacao, Krause (ed.) 1982). Examples of database environments in support of engineering design include the PRIMA/MAD project (Hubel, Sutter 1992, Harder, Wegner, Mitschnag, Sikeler 1987), AREDAS (Vossen, Bimmermann, Buchholz 1988),the 3DIS system for VLSI design (Afsarmanesh, McLeod, Knapp, Parker 1985, Granacki, Knapp, Parker 1985), etc. None of these systems, however, addresses the issues of interoperability with CAD tools. The distributed heterogeneous character of engineering design data is addressed by Magleby and Gunn (Magleby, Gunn 1992). There software, Cimphony, provides Information Services Exchange to serve as an object request broker between CAD tools acting like agents. Each object maintain its own data model, no global conceptual view is provided. Objects are responsible to decide what services they need from other applications. They communicate with each other by sending requests. Standard UNIX interprocess interface is used for communication. New agents can be added to the environment without changes to the software and recompilation. Constraints can conceivably be imposed by an application on a model, but an overall mechanism to address constraint management is not provided. A hybrid hierarchical scheme for information exchange between mechanical and electrical CAD tools called Distributed Relevant Data Exchange Approach is proposed in (Wang, Richards, Wright 95). The information exchange within a single domain (e.g., mechanical) through a common database is envisioned. The authors further propose to exchange only the relevant data between mechanical and electrical domains through common neutral format files and a global database manager. The approach makes the information exchange more manageable. In addition, the approach is extensible and reduces the data communication. The dynamics of the data access and exchange is limited as the data transfer between domains needs to be initiated by the user. The work also does not aim at maintaining general design constraints across application models besides maintaining the consistent correspondence among the design data. Two research systems - ROSE (Hardwick, Spooner 1989) and EMTRIS (Rangan, Fulton 1991) utilize relational technology on lower level for faster indexing and retrieval and object-oriented techniques to describe the structure of the objects. For example, EMTRIS (Engineering and Manufacturing Technical Relational System) uses ORACLE to help engineers locate and retrieve design information. Most of the research in engineering data management mentioned above also concentrates on only one (although probably the most important one) aspect of the design-related data and knowledge: the product data. Additional problems for the comprehensive design information representation arise from the lack of adequate project history models. These design histories can be used, for example, to track ongoing projects and to re-use old designs. The data and knowledge which needs to be captured includes different versions (including obsolete ones) of product models related to a representation of design activities, decisions made, rationale, etc. As an outgrowth of the research in engineering data management, commercial Engineering Document Management / Product Data Management (EDM/PDM) systems appeared in recent years. They try to overcome the shortcomings of the traditional CAD computing environment and to improve the information sharing in large enterprises. Typical functions of EDM/PDM systems include "check-in" of a file (CAD model, text document, raster image, etc.) into a common database for others to "check-out". Files can be indexed by various attributes (e.g., by owner/author, department, creation date, etc.) and later located by specifying search values for those parameters. In addition, files can be organized in hierarchies corresponding to the product structure so that they can be located by browsing. A paradigm of electronic "folders" where users can "put" files and which can be passed from one user to another was pioneered in Hewlett-Packard’s WorkManager. EDM/PDM systems are typically built using the client-server architecture, where shareable files are stored on computers-server. Some of those systems require a specific underlying DBMS, while others allow the end-users to chose one of several options. The relational DBMS technology, however, dominates in this field even though the end-users are typically given an object-oriented view of the data. An important shortcoming of PDM systems at this point is the lack of a genuine integration and merging between different application models. In practice, PDM systems add another application model which might include remote file names and the CAD tools used for their creation and manipulation as attributes. To solve such problems as maintaining constraints across different application models (inter-system constraints) at least parts of these models need to be exported and integrated into CAD multidatabases. 3 TAXONOMY OF DESIGN INFORMATION SYSTEMS The increased efforts both in industry and academia in recent years lead to the accelerated development of Design Information Systems (DIS). These systems tend to have greater scope compared to traditional design automation tools by supporting collaborative design and integrating product data with design process and rationale information. This chapter starts with a formulation of a taxonomy of DIS which is used to present the different research approaches within the overall perspective. The taxonomy also could provide a basis for common understanding of the different terms and possible solutions. This taxonomy was developed jointly by the author, Prof. Shah, and Sohail Qureshi, another Ph.D. student in DAL. The principles applied in the development of the taxonomy were: (1) independence of the taxonomy from specific applications and application models supported by different DIS, and their implementation specifics; (2) orthogonality of the classification criteria; (3) limited number of classification criteria and options; (4) use of a vocabulary understandable by a broad circle of its potential users. Seven classification criteria of DIS were identified: sophistication (functionality), product data abstraction, design process information granularity, design rationale representation, collaboration (information sharing), information homogeneity, and flexibility. The taxonomy was applied by classifying the approach taken in some of the research works reviewed in the previous chapter and design information software products. 3.1 Approach to the DIS Taxonomy Development The development of a DIS taxonomy is approached here as a design problem, a sub-task of the overall work. Therefore, objective and requirements had to be formulated first. The objective of this sub-task was drawn up with potential users of this taxonomy in mind. Among those potential users are researchers in the fields of design automation, and design theory and methodology, as well as vendors and customers of DIS. The objective of this chapter was to provide a reference frame for existing and future research and development work in the field of DIS in order to establish common understanding of the different possible solutions both among researchers and between developers and customers. A number of requirements were applied in the development of the taxonomy. First, the taxonomy had to be independent of the specific applications and application models supported by different DIS, as well as their implementation specifics. Rather, the taxonomy had to reflect fundamental characteristics of DIS related to the nature of the design process and the information exchange. Second, different classification criteria had to be orthogonal. This requirement means that a DIS classified in one of the groups along a criterion can belong (at least, in theory) in any category along the rest of the criteria. Therefore, if each criterion is depicted as an axis in the overall space of possible DIS, a specific system can occupy any sub-space in it (fig. 2.1). Third, the number of classification criteria and options under each criterion had to be limited in order for the taxonomy to be practical. A very elaborate taxonomy describing each and every aspect of DIS at the expense of a larger number of classification criteria would be difficult to understand and not very useful in practice. "Three" was a tempting candidate for the number of criteria since a three dimensional space of possible DIS solutions would be easy to visualize and understand. It was considered, however, too small to provide a multi-faceted characteristic of DIS, so the number was limited to 6-7. Fourth, the taxonomy had to be developed in terms of a vocabulary understandable by a broad circle of its potential users. These users, as noted in the beginning of this section, could have different perspective at DIS, different educational background, and different work experience. That limited the taxonomy to the use of terms which are very broadly understood. Figure 3.1. A DIS classification hyper-space defined by seven orthogonal classification criteria 3.2 Classification Criteria Seven major classification criteria for DIS were included. These criteria are designed to be used in combination to characterize any specific DIS (e.g., a specific DIS will provide certain levels of sophistication / functionality for particular levels of product data abstraction, specific levels of design process information granularity, etc.). Along each criterion a specific DIS might support more than one level (e.g., all levels of sophistication might be provided by a particular system). On the other hand, some systems might provide no support along some of the criteria (e.g., a specific system might not keep any information about the design process as such, only maintain the product data). Therefore, if each of those criteria are represented by an orthogonal axis in the 7-dimensional space, a specific DIS can be depicted as part of this space (e.g., a possibly disjoint volume or hyper-planar shape). The classification criteria follow. 3.2.1 Level of Sophistication / Functionality This criterion shows the functionality offered by the DIS in terms of the ways the information could be recorded and retrieved. Higher level of functionality requires also a more structured (i.e., more machine interpretable) representation of the information and knowledge to support it. The following levels of sophistication are proposed: • Static Retrieval. At this level, the DIS represents a file management database. It supports such function as browsing through static files - a synchronous (serial) exchange of messages between the DIS and the user; at each stage the user has a limited number of choices. An example of such a system would be a WWW-based DIS in which the design information stored as HTML, VRML and other multimedia formats which can be retrieved by the user through a point-and-click hypermedia user interface. • Dynamic-Semi-structured Retrieval. At this level the DIS allows search and retrieval of unstructured and semi-structured design information. Again, the interaction represents a synchronous (serial) exchange of messages between the DIS and the user. However, at each stage the user is not limited with the selection but can specify the information of interest. An example of a system at this level would be a WWW-based DIS which provides a keyword search mechanism in addition to the browsing mechanism. • Dynamic-Structured Retrieval. At this level DIS support similar functionality as at the Dynamic-Semi-structured level, but allow structured queries. The query language is richer allowing specification of search values for specific objects and their attributes. Such level of sophistication assumes availability of a structured database with schema (meta-data) information. The structured database might have links to files containing human interpretable information. • Dynamic-Reactive Input. In addition to the functionality supported at the lower level of sophistication, the DIS at this level are capable of enforcing various types of constraints (including design constraints) by checking validity of user input information and rejecting invalid values. Structured queries where the user specifies values for specific attributes or establishes dynamic relationships between different objects are possible. • Dynamic-Proactive Input. At this level of functionality, the DIS are capable of constraint enforcement by propagating changes as a result of user input. For example, if a certain shaft diameter is changed the DIS can take some actions to modify the matching hole diameter. At this level, the re-use of design knowledge is also possible. 3.2.2. Level of Product Data Abstraction This criterion shows what is/are the level/s of abstraction of the recorded product data in the DIS database. These levels follow the typical stages of the design cycle, starting from the stages when the product is very vaguely defined and ending with the specific production instructions for the product. While there are some debates in the design research community about the subdivisions in the design cycle, the following subdivision is relatively broadly accepted and is useful for the purposes of this work: • Perceived Need. The need for a product could be realized by various actors in the design process - a customer, the marketing division, a bigger design project coordinator, etc. Often the need is formulated in a design breed, which contains the product name and basic purpose, area of application and environment, sources of information and requirements, list of desirable basic properties, deliverables, and deadlines. This is the most abstract definition of the future product. • Design Specification. At this stage more specific parameters of the product being designed are formulated by clarifying the task. A specification of the targeted customers of the product, metrics used to evaluate it, and survey of competing products - all provide a basis for comparison. The design constraints are also detailed. At this stage the basic options for the product are also typically considered (these options are then checked against standards, regulations, etc.). • Functional Design. Sometimes, this stage is also called "conceptual design". At this phase the various major design solutions are generated and evaluated. The principle design of critical sub-systems is selected. The basic design variables are determined. At this stage, the design process starts to converge after pursuing divergent approach in the beginning. • Embodiment Design. At this stage the preliminary layout and form of the future product are developed. The alternatives are evaluated against the technical and economic considerations and the best preliminary layout is selected. • Artifact Type Design. The product data at this phase includes a finalized arrangement and form information. (These data can be used for some checks for errors and cost effectiveness.) This stage of design provides specific solutions for particular design sub- problems. • Artifact Instance Design. The product data become yet more specific at this stage through finalizing the dimensions, material, and surface properties of all the parts. The results of the design process are represented in a way which would allow their use for the planning of the manufacturing of the product, its measurement and control, use, repair, and disposal. Calculations and checks are performed to confirm meeting of the initial requirements. The manufacturability and the required resources can to some extent be analyzed. A benchmarking can be performed. Depending on the type of the future production (mass vs. small-batch) a prototype and/or a pilot batch might be built and tested. • Manufacturing Process Design. While at the above mentioned level of abstraction the product is completely defined, at this stage the specifics of its manufacturing make the product data even more specific. Most generally, this includes selection of the methods to manufacture individual parts (with their respective nominal shape, within the specified tolerances and surface finish parameters, from the material previously selected), and to assemble, test, and package them. For example, for a part machined on an NC machine tool, the following parameters of the manufacturing process need to be defined: material (part blank), manufacturing method, machine tool, cutting tool, setup, jigs, and fixtures, manufacturing process sequences and conditions (e.g., feed rate, cutting speed), tool paths, etc. • Production Process Design. The manufacturing instructions are further matched with the available production resources and a specific schedule finalizes the data needed for the actual production. 3.2.3 Level of Design Process Information Granularity This criterion is intended to show the type of design activities which are reflected in the DIS database. The spectrum of possibilities starts with a very scrupulous account of miniature events and ends with a summarized information about the overall design project. While all of these can be "computer- interpretable" in one way or another, it typically would take a human interpretation to extract some semantic meaning of the stream of momentary events. Recording the information about the shorter (in time) design actions does not automatically assume that longer design steps are also adequately represented. For example, recording the momentary designer actions on a computer (like mouse motion or key strokes) is not sufficient to represent all the information about the design sub-projects (which may include data like sub-project start and end date, responsible person, sub-assemblies which were modified, etc.). As the level of granularity becomes more general, the data can be used by the DIS to answer directly high-level queries about the design process. An indication that the design process information is supported on a given level means that there are some data records for each instance of design steps on that level. • Momentary User Actions (e.g., mouse motion, key strokes, pencil motion, etc.; typical duration and occurrence frequency - fractions of a second to a couple of seconds). While the design activities at this level of granularity bear little semantic meaning, a record of them can be used to "replay" a design session. The potential purposes of such a "replay" can be: a protocol study, training of other designers, demonstrations, etc. The data can also be used for synchronous or asynchronous communication among multiple designers (e.g., in teleconferencing mode). Typically nowadays, this level of events granularity in the case of a computer-aided design is supported by the underlying windowing system (e.g., X-window). • Model and View Editing Commands (e.g., Perform Boolean Difference Operation in a geometric modeler or Calculate Required Power in a design procedure; typical occurrence frequency - fractions of a minute to several minutes). The records of design activities at this level of granularity can be used, for example, in design automation (e.g., to re-create a geometric model with changed values of some of the parameters - in the case of a parametric design). In a computer environment, they are also typically supported by the product modeling and other application software (e.g., CAD/CAM/CAE systems). • Work Session (a design session; typical duration - several hours). The design process data at this level of granularity can be used in the day-to-day management of the progress of the design, to locate the files generated during a design session on a given day, by a given designer, etc. The computer-based design process data at this level gets already into the domain of PDM systems. • Design Task (has clear design data inputs and outputs, responsibilities, and deadlines, some level of completeness of the results; typical duration - from 2-3 days up to 2-3 weeks). This design process information could show the general steps to design a sub- system or sub-assembly of the product (i.e., provide a general representation of a design procedure). It is also typically used for design project management. Software supporting the design process data at this level are project management systems and some PDMs (which represent internally workflows). • Design Sub-project (has well-defined design objects, clear requirements about the presentation of the results; typical duration - several weeks to several months). These types of data are used in design cycle management. • Design Project (complete design product; typical duration - several months to several years). This would be the highest-level design process information used for managerial purposes (e.g., to track the progress of several projects in a organization). 3.2.4 Level of Design Rationale Representation This criterion shows how structured (i.e., computer intelligible) vs. how unstructured (i.e., only human- interpretable) the design rationale representation is. The advantage of the structured representation is that it can generate automatically answers to some queries related to the design rationale and even automate to some degree the process of decision making. The advantage of the approaches employing less structured representation is in their flexibility. Quite often the design information (especially at the early stages of the design process) is vague and does not fit within the frame of a structured rationale representation. • Unstructured. The design rationale is recorded as human-interpretable comments associated with product data entities (e.g., the reason a specific feature was added to a part) or design process information (e.g., why a given action was taken). • Semi-structured. The information still needs interpretation by a human user, yet it is grouped in more uniform data structures. This allows the DIS to automatically answer such queries as "What were the alternatives considered for a given design decision ?", "Which alternative was selected ?", etc. • Structured. The design rationale is completely computable. Examples of such representations are the use of predicate logic and representation of the design process as a computable constraint satisfaction process. 3.2.5 Level of Collaboration/Sharing This criterion refers to the distribution of data and control in the underlying DIS database. At the lowest level, the DIS itself does not provide any support for distribution of data or database control. If any was to be provided, it would require extensive user involvement (essentially, re-entering the data stored in other databases through the user interface). As the level of collaboration / information sharing increases, the DIS provides better built-in functionality to support distributed information exchange between the global database and other databases (e.g., application model files) with lesser user involvement. The required intelligence (autonomy) of each database management sub-system also increases. There are several aspects of the information sharing. The first aspect is information exchange among the participants in the design process (i.e., among people). The second aspect is the data sharing between workstations (in general, between computers). While typically one designer is using one (or two, at most) workstations, this is not necessarily so in all cases. Several designers can also use the same workstation. For the purposes of this work, the DIS are separated into those which support a single virtual "site" (one designer working on one workstation) and those supporting multiple sites (with the latter one having several sub-cases). Another aspect of the data exchange is information sharing between different databases (e.g., databases of different application tools). Different databases can resides within the same site. Single database can also be distributed over several sites. This aspect of the information distribution is reflected jointly by this DIS classification criteria as well as by another classification criteria: Information Homogeneity (see Section 3.2.6). Besides the distribution of data, the distribution of control is another important factor. The two, in general, can be considered separately (e.g., the control can be either centralized or distributed for the case of distributed data). Some researchers suggest such an independent view at the two factors (e.g., (Ozsu, Valduriez 1991)). For the purposes of this work, however, to reduce the number of classification criteria the distribution of the database control was added as a more advanced feature which might logically follow the distribution of information. As indicated earlier, each of the levels of information sharing can in theory be combined arbitrarily with different levels along other criteria. Hence, a certain level of product data abstraction can be supported on one level of information sharing, while the product data on another level can be supported on a different level of sharing. Similarly, the design process information at different levels of granularity can be supported yet on different level(s) of information sharing. In practice, once certain level of information sharing (collaboration) is implemented, it can be used for any types of information recorded in a specific DIS. The following cases of information sharing in DIS can be outlined: • Single-site. The particular DIS does not provide any specific facilities for information sharing among multiple sites. All the data and database control are local. • Static. At this level the information can be exchanged (either between different databases on a single site or between different databases on multiple sites) through static files (e.g., IGES or STEP files in case of the product data exchange, KIF files in case of knowledge exchange, etc.). There is no common control mechanism for the different databases, the user is involved in the information exchange. • Dynamic. This level assumes availability of a common global database which is accessed by different DIS users and user applications to add, retrieve, modify, etc. the shared information. • Federated. This level assumes that the information at any specific time is distributed among several database sub-systems. Each part of the common shared database has certain autonomy. These subsystems can operate independently. They also allow shared access to at least part of their data from other database sub-systems through a certain protocol. 3.2.6 Information Homogeneity Level There are several aspects of the homogeneity (vs. heterogeneity) of information. For example, in a computer environment, the computer hardware, peripheral devices, operating systems, application software, and network protocols can all be homogeneous or heterogeneous. For the purposes of this work, the homogeneity of the medium, data model, and format of the data is considered important. Further, the homogeneity of any two media or two data models is defined based on the possibility to transfer data unambiguously in both directions between them. Therefore, a floppy disk, a hard disk, a computer network connection, and a CD-ROM would be considered a homogeneous "electronic" medium since they allow to transfer data among them without any loss. Paper and an electronic medium would be considered heterogeneous media since it is only possible to print out electronically stored data, but in general information recorded on paper cannot be automatically transferred to an electronic medium without some losses. Similarly, raster graphics images (e.g., in TIFF and GIF formats) can be considered employing a homogeneous data model since the data can be converted from one model to the other. Images in a vector and a raster formats, however, would be considered employing heterogeneous data models as vector recognition algorithms might lose some of the information (while the conversion in the opposite direction is trivial). Homogeneities of the medium and the data model are independent of each other. Same data model (e.g., the STEP data model) can be used to store data on different media (e.g., paper and an electronic medium). Similarly, different data models can be used on the same medium. Homogeneity of the data models is required but not sufficient for the homogeneity of the formats. Heterogeneity of the formats for an equivalent data model requires some type of data conversion, but typically it is a trivial task which can easily be automated. The following levels of data homogeneity can be supported by a DIS: • Single medium (e.g., paper), data model, and format, of the information • Single medium (e.g., and electronic medium), multiple formats, but single data model of the information (e.g., pixel image files in tiff and GIF formats) • Single medium (e.g., magnetic disk), multiple data models of the information (e.g., plain text files, image files, and audio files) • Multiple media, but single format and data model of information (e.g., STEP EXPRESS files recorded on paper and an electronic medium) • Multiple media and multiple formats, but single data model of information (e.g., a paper and an electronic medium 2-D drawing) • Multiple media, formats, and data models of information (e.g., a paper drawing and a computer-based 3-D geometric model) 3.2.7 Level of Flexibility These levels show how much modifications does a specific DIS allow with respect to the schema (meta- data) information in the global database. • Fixed schema - the schema is pre-defined. With respect to the product data, for example, this would mean that the particular DIS allows representing only specific artifact type(s), the attribute values of each instance can be different (i.e., a case of parametric design). With respect to the design process this would assume that the whole sequence of design steps is fixed and can only be repeated with different attribute values. • Forking schema - the schema is pre-defined up to some point, but can evolve from that point on. With regards to the product data, for example, this would correspond to a case of evolutionary design during which seed parts are used as a starting point and later are modified with some case-specific features. With respect to the design process data this would correspond to a case in which the design process is pre-defined (at some level of granularity) but can be modified to accommodate for case-specific design operations. • Flexible synthesis from a fixed set - some fixed set of schema chunks is pre-defined; they can be combined arbitrarily to form the meta-data for a specific design. With respect to the product data, for example, this would correspond to a case of configurational design in which some components (possibly, of different size) are pre- defined, but they can be combined arbitrarily to form a system. With regards to the design process this level of flexibility would correspond to a case where standard design procedures (e.g., for different sub-systems) are used to form an overall design process. • Open synthesis from an open set of meta-data components - the DIS allows to define any new class of data and combine those classes and their instances arbitrarily. With regards to the product data, for example, this level would correspond to novel design. With regards to the design process this level of flexibility would correspond to a synthesis of a design process schema from an open (extensible) set of design operations. 3.3 Classification of Existing DIS This section demonstrates the application of the taxonomy described above. First, some research works reviewed in Chapter 2 are classified in table 1 The taxonomy was also applied to the classification of some DIS software implementations. Several representative DIS from different classes were selected and classified in table 2. Some of them are a result of academic research, others were developed within research projects in industry, while the rest are commercial systems. For a detailed description of the systems see (Herling at al. 1995, Huber et al. 1995, Metaphase 1996, Pro/PDM 1996). The symbol + indicates support, - stands for “lack of support”, and (+) indicates “partial support”. Table 1. Classification of Related Research Works According to the Developed Taxonomy. Crite- rion Level \ System Static retrieval Sophis Dynamic-Semi-structured Retrieval tica Dynamic-Structured Retrieval (Baudin et al. 1992, Baudin et al. 1993a, Baudin et al. 1993b, Baya et al. 1992). tion Dynamic-Reactive Input Dynamic-Proactive Input Produc t Perceived need Design Specification Data Functional Design Bond Graphs Embodiment Design IGES, STEP, (Ghodous 1996) Ab- Artifact Type Design IGES, STEP, (Ghodous 1996) strac- Artifact Instance Design IGES, STEP, (Ghodous 1996) tion Manufacturing Process Design Production Process Design Momentary User Actions Pro Model & View Editing Commands (Mueller 1990), TEAM model (Ullman 1989), (Ghodous 1996), Dominic (Dixon et al. 1987) cess Work Session (Ghodous 1996), IDEF3 Design Task IDEF3 Granu Design Sub-project IDEF3 larity Design Project IDEF3 Ratio Unstructured Rep (Taylor 1993) nale Semi-structured Rep IBIS (Rittel et al. 1973, Yakemovic et al. 1989, Yakemovic et al. 1990, Ullman et al. 1991, Nagy et al. 1992, Mylopoulos et al. 1990, Potts 1996), gIBIS (Conklin et al. 1988), DRL (Lee et al. 1996), QOC (MacLean et al. 1996) Structured Rep (Ganeshan 1992) Colla- Single site bo- Static IGES, STEP, KIF ration Dynamic Federated Table 2. Classification of Existing DIS According to the Developed Taxonomy. Crite- rion Level \ System EDDS SYSFUND SYSFUND+ Meta- phase 2.0 Pro/PDM Static retrieval - - - - - Sophis Dynamic-Semi-structured Retrieval - - - - - tica Dynamic-Structured Retrieval + + + + + tion Dynamic-Reactive Input - - + (+) (+) Dynamic-Proactive Input - - + (+) - Produc t Perceived need + - - (+) (+) Design Specification + - - (+) (+) Data Functional Design (+) + + (+) (+) Embodiment Design (+) (+) + (+) (+) Ab- Artifact Type Design (+) - + + (+) strac- Artifact Instance Design - - (+) + + tion Manufacturing Process Design (+) - - + + Production Process Design (+) - - + + Momentary User Actions - - - - - Pro Model & View Editing Commands - - - - - cess Work Session (+) - - - - Design Task + - - + + Granu Design Sub-project + - - (+) (+) larity Design Project + - - (+) (+) Ratio Unstructured Rep - - - - - nale Semi-structured Rep - - - (+) - Structured Rep - - - - - Colla- Single site (+) + + + + bo- Static + - - + + ration Dynamic - - - + (+) Federated - - - - - Single medium, data model, and format + + + + + Homo- Single medium, data model, multiple formats - - - + + gene- Single medium, multiple data models - - - (+) (+) ity Multiple media, single data model and format - - - + + Multiple media and formats, single data model - - - + + Multiple media, data models, and formats - - - (+) (+) Fixed schema + + + - - Flexi- Forking schema - - - (+) (+) bility Flexible synthesis from fixed set - - - + + Open synthesis from open set - - - (+) (+) Note: “+” indicates support, “(+)” denotes partial support, and “-” indicates lack of support. Summary The objective of this chapter was to classify existing research approaches and development work in the field of DIS. In addition to serving as a review of related work for the purposes of this dissertation, this classification could allow to establish common understanding of the different possible solutions both among researchers and between developers and customers. In addition, the developed taxonomy allows to put the work of the DIS development presented in the subsequent chapters into perspective. The principles applied in the development of the taxonomy were: • independence of the taxonomy from specific applications and application models supported by different DIS, and their implementation specifics; • orthogonality of the classification criteria; • limited number of classification criteria and options; • use of a vocabulary understandable by a broad circle of its potential users. Seven classification criteria of DIS were identified: • sophistication (functionality) • product data abstraction • design process information granularity • design rationale representation • collaboration (information sharing) • information homogeneity • flexibility. The taxonomy was used to classify several research works and design information software products. 4 ANALYSIS OF FUNCTIONAL REQUIREMENTS There are multiple factors which determine the functional requirements for DIS. As in any design problem, the needs of the end-users drive the development of the DIS. Section 4.1 presents a general idea of those needs based on the experience of the author and other members of his research team. Section 4.2 compares this idea with the actual requirements stated by few potential users from an aerospace company in an informal interview. While the users' needs are the major factor determining the DIS design, it also has to blend within the overall design automation environment. A taxonomy is presented in Sections 4.3. It classifies design automation tools based on their "integration friendliness". 4.1 End-User Needs Design Information System may need to meet the needs of several classes of users: Designers, Managers, Manufactures, etc. The needs for each of these group are examined below: • Designers: • During the design process - DIS should provide support for a better coordination of designer's work with other members of the design team (including change propagation throughout the project), to understand the rationale of his/her colleagues; to backtrack to a previous design state and to iterate over some part of the design with changed design parameter values. • In re-designing the same (or similar) product - DIS should facilitate determining the specific steps that occurred in the preceding design process, the rationale and constraints that affected design decisions, and the versions and alternatives of the design specification; to automate some standard design procedures by re- using the structured representation of heuristics and routine design procedures once recorded. • In education and training - DIS should store representation of not just a specific instance but rather various possible alternative paths of standard or highly repetitive design procedures which can be learned and followed by novices. • Managers: • While the design project is in progress - DIS should allow tracking its progress (including deadlines, current critical path of tasks), finding out bottlenecks, etc. • After a project is completed - DIS should support analysis of successes and failures as lessons for future projects. • Manufacturers: • DIS should permit developing of manufacturing plans concurrently with the design process. • DIS should provide information needed for manufacturing evaluation. • Allow manufacturers to better understand the rationale behind dimensions and tolerances imposed by the designer; In the context of these potential applications the following principal database requirements can be extracted : 1) design parameters, constraints, and heuristics representation should be in a structured form allowing automatic execution of some standard design calculations and automated propagation of changes (possibly, after approval from "owners" of respective components of the design) 2) decision rationale should be stored along with the design decisions and alternatives considered; it could be in a less structured form (e.g., non-structured, allowing only human and not computer interpretation, or semi-structured allowing only partial interpretation). 3) the design process representation should include organizational data about the time activities were planned to take place and actually executed, person-hours spent, the responsible person(s) for each task, etc. 4) the activities covered by a DIS should include not just design and analysis, but also prototype manufacturing and testing 5) product data should be associated not only with different versions of the product (which are being refined throughout the design process), but also with different alternative options for the final product (all of which could go into production) The functionality of DIS includes data entry, modification, update, retrieval, and archiving. As the goal of DIS is to provide useful project information upon request, data retrieval is to a high degree determining the database and functional requirements. Typical queries which have to be supported in the context of the mentioned potential applications are: • What is the current design of artifact X ? • What are the sub-components of X ? • What system is X part of ? • What are the different alternative options for the design of X • What is the current value of parameter Y in the design of X ? • Who is the "owner" of the parameter Y ? • How was artifact X designed / analyzed / built / tested ? • When was artifact X designed / analyzed / built / tested ? • What is the target date for designing / analyzing / building / testing X ? • Who designed / analyzed / built / tested artifact X ? • Why was artifact X designed / analyzed / built / tested like that ? Table 3. Results from a Limited Customer Survey. Crite- rion Level Need Comment Static retrieval + For distributed access to documentation, CAD/CAM model files, etc. Sophis Dynamic-Semi-structured Retrieval + For access to "lessons learned" information about previous designs tica Dynamic-Structured Retrieval + tion Dynamic-Reactive Input + Dynamic-Proactive Input + Controlled change propagation Produc t Perceived need + Design Specification + Data Functional Design + Embodiment Design + Ab- Artifact Type Design + strac- Artifact Instance Design + tion Manufacturing Process Design + Production Process Design + Momentary User Actions - Pro Model & View Editing Commands - Note needed after project has been closed (does it ever get closed ?) cess Work Session + Design Task + Granu Design Sub-project + larity Design Project + Ratio Unstructured Rep nale Semi-structured Rep Structured Rep Colla- Single site - Past this stage bo- Static - Past this stage ration Dynamic + Need access control Federated - Single medium, data model, and format - Homo- Single medium, data model, multiple formats - gene- Single medium, multiple data models - ity Multiple media, single data model and format - Multiple media and formats, single data model - Multiple media, data models, and formats + Formats are not always compatible; this should be transparent to the DIS user; consistency should be enforced Fixed schema + For parametric design Flexi- Forking schema + For DFME bility Flexible synthesis from fixed set + Not for the design management as such; for tooling, testing equipment management Open synthesis from open set + Typical for CAD 4.2 Limited Customer Interest Survey This section provides further application of the taxonomy described in Section 3.2 in an informal survey of DIS customer needs. The survey is very limited. It provides results just for one company based on the replies from a few potential users. Further surveys are needed to come to statistically representative conclusions about the needs of industrial companies - potential users of DIS software. The company used in this preliminary survey is from the aerospace industry and is of a medium to large size. Several employees from different departments were questioned. The generalized results are shown in table 3. 4.3 "Integration Friendliness" of Design Automation Tools Integrating existing CAD and other application software was one of the major objectives of this work. For that reason it was important to identify different levels of "integration friendliness" and consider the possibilities for integration of different applications with each other and with the DIS in each particular case. Integrating different applications means at least allowing those applications to exchange parts of their respective application models. In particular, the meta-level DIS can be retrieving part of the application models data in order to verify certain constraints. As a result of this verification, DIS might need to modify (possibly, directly, but more often through a human user) data in a different application model. More advanced (in terms of "integration friendliness") applications allow automated access to their functions by other software programs (i.e., the former applications provide a service to the latter programs). The levels of "integration friendliness" are shown in table 4. Table 4. Taxonomy of Application Software According to Its "Integration Friendliness". Level Access to application data and functionality by other programs 0 Through a human-computer interface only 1 Through neutral exchange data files (e.g., files in IGES or STEP formats) 2 Through proprietary language procedures in batch mode 3 Through API (high-level programming language) function calls 4 Through object method calls on a local computer 5 Through static object method calls over a computer network 6 Through mobile objects delivered over a computer network The applications of level 0 provide minimum possibilities of integration with other programs. Their functionality is available only through some kind of human-computer interface (e.g., graphical, textual, etc.). Data exchange between such applications and other programs can be performed only through re- entering the information by a human user. In this process s/he can re-enter all relevant aspects of the application model. The process, however, is prone to human errors and is time consuming. Such a limited possibility for data exchange with other CAD systems can be encountered in cases of some custom-written proprietary programs, but is rare if ever observed in commercial applications. The applications at level 1 allow export of data (typically stored in a proprietary work format) into a file with well-documented format. The latter file format can be standardized formally (e.g., IGES or STEP) or be a de facto standard (e.g., DXF). Although a human user still might need to be involved in the information exchange cycle (e.g., to invoke the export command through the user interface), this action is routine and consumes little time. The neutral files can further be exchanged between computers running application network programs (e.g., ftp). One of the shortcomings of this mode of data exchange is poor selectiveness (typically, whole models are exported regardless of the particular needs). Additional modules might be needed to filter out only the required information. Another disadvantage is the unavoidable information loss, as the neutral data model is normally an intersection of the application models of software packages of a certain class (i.e., their “least common denominator”). For example, formats for geometric model exchange (e.g., respective parts of IGES and STEP) at present do not allow to represent the geometric constraints used by the user to define a model, even though most of the CAD packages store this information in their proprietary application databases. Lastly, some misinterpretations built into the pre- and post-processors can lead to inaccuracies in the data exchange through neutral files. This type of information exchange is typically available in the vast majority of commercial CAD systems (e.g., Pro/Engineer’s Pro/INTERFACE (Pro/INTERFACE 1996), I-DEAS STEP Data Translator (SDRC 1996b), etc.). The applications at level 2 allow some automated access to both their internal data and functionality. The data exchange between programs running on a single computer again is typically performed through files (and more rarely, as command line parameters or "mailboxes" in the computer RAM). Those files, however, can be generated by running a procedure in a proprietary (specific for the application software) language in batch mode by operating system calls. The procedure can be written at the time of the DIS set- up (if the specific queries are known in advance) or dynamically generated by a translator from the query language of the DIS onto the proprietary programming language. The application software functionality (e.g., determining mass properties for a geometric model of a part) is available to external applications through same procedures (although some part of the application functionality might not be available in this mode). A minor disadvantage of this type of integration is its somewhat lower dynamics (compared with the case at level 3), since the exchange data captures a snapshot of the application model at the time of the execution of the batch procedure. This type of access to individual application models is available in many larger and well-established CAD systems (for some of them the proprietary languages are part of their legacy user interfaces from the pre-graphical user interface era). For example, SDRC includes Open Language as part of its product I-DEAS (SDRC 1996). The application programs at level 3 provide access to their database and/or functionality through an API interface. This means, that DIS can have components running on a local computer which are linked to the API functions. These components can reply to queries and the instantaneous state of the application model can be reflected in the replies. More interestingly, the components could continuously monitor the state of the application model and can trigger reports to the meta-level DIS themselves. Data access through API calls is usually offered as an option for CAD systems which would allow development of some custom- written modules (often, the functionality of such interfaces is limited). Examples of such API libraries are the library for the products CATIA by Dassault Systems/IBM (CATIA 1996), Open Link for I-DEAS by SDRC (SDRC 1996a), and Pro/Develop for Pro/Engineer by PTC (PTC 1996a). EDS offers a toolkit called Parasolid (EDS 1996) which provides not only an API to their CAD/CAM/CAE software Unigraphics, but was also used by other companies to develop CAD products (e.g., SolidWorks 96 (Solidworks 1996)). Some "open architecture" toolkits provide API interfaces as the only means to access their functionality (e.g., ACIS by Spatial Technology (ACIS 1995)). With the advent of the object-oriented technology, application programs can be accessed as objects, invoking their methods. These objects can exchange information through a common "clipboard" in the memory of a local computer (level 4) or over a computer network (level 5). The former is provided, for example, by such operating systems as MS-Windows. Most of the CAD/CAM and 3-D geometric modeling products implemented on the MS-Windows platform (e.g., Solid Edge by Intergraph (Intergraph 1996), TriSpectives by 3D/EYE (3DEYE 1996), etc.) allow dynamic data exchange using the Microsoft standard OLE (Object Linking and Embedding). As a result, a dimension of a geometric model can be linked to a number in a spreadsheet program (e.g., Microsoft Excel). This “linking” allows the number to be modified from either program resulting in changes in the other application model as well. An extension to OLE called OLE for Design and Modeling with a CAD/CAM orientation (Intergraph 1996a) was developed by the Design and Modeling Advisory Council (DMAC 1996). The advantages of this approach compared to API calls are: better scalability of CAD/CAM systems (different programs can be developed independently and linked dynamically to work with each other), and improved possibilities for applying the “plug-and-play” approach (where each customer is able to select the most suitable software product for each function). Mechanisms for accessing software objects over a computer network are specified by the Common Object Request Broker Architecture (CORBA) (CORBA 1995) (developed by the international consortium OMG (OMG 1996)) and Common Object Model (COM) (jointly developed by Microsoft and Digital Equipment Corporation). At this level of information exchange, a program can request a “service” and get it from a program on a different workstation (after being directed to it by a request broker). The information exchange through remote method calls can be used to better distribute the computational load over a network and for providing services and “renting” software and hardware resources. Such possibilities for data exchange with commercial CAD systems are still rare. For example, I-DEAS Master Series 4 (SDRC 1996) offers CORBA support. Making CAD systems available as objects on a wide area (or global) computer network represents a challenging paradigm shift. If the messages which have to be exchanged between the software objects require high communication bandwidth relative to the size of the whole server object, it might be more efficient to deliver the whole object upon request by the client (level 6). The recently developed mobile code paradigm allows that. For example, a Java applet representing a product model can be delivered to the client. The client then can start interrogating that object (e.g., what class does it belong to, what methods does it offer), and invoke its methods. To reduce the size of the objects to be transferred, they can be distributed over multiple workstations at once (level 6a). A small part of the object (its “head”) can be transferred and interrogated at the client sites. This part can have just enough information to identify the object and its public information (public data and methods). The bulk of the information (object’s “body”) can remain at the site where the object originated, but still be accessible (if required) through the object’s “head”. For example, an object representing a model of a motor can have its basic parameters (e.g., input voltage, horse power, maximum r.p.m., etc.) as well as declarations of its methods (e.g., “Visualize”, “Get STEP Geometric Model”, “Get VRML Model”, “Get Pro/Engineer Model”, etc.). For some of the clients requesting this object (e.g., software agents searching a local or global network for a motor with certain characteristics) the values of the basic parameters will be sufficient. Other clients (e.g., a CAM system) can interrogate the object what “Get geometric model” methods are available (in the order of their preference from the client’s point of view) and execute the most appropriate method. That method can have portions residing at the site from which the object was retrieved and perform the transfer of the requested information in the requested format only at that point. Moreover, the methods can themselves consist of standard building blocks available on the computer network (including software components from third parties). For example, a “Visualize” method for an object can consist of a component converting the native geometric information to a standard VRML format, and then invoking a VRML viewer available from a third party on the network. Some software applications provide mixed possibilities for integration. For example, retrieving information from a CAD database can be available through an API interface (level 3), but recording information into this database might be available only through a human-computer interface (level 0). Summary The factors determining the functional requirements are analyzed in this chapter. As in any design problem, the user needs determine first and foremost the DIS design. Different potential users in the design process and their needs with regards to the DIS are considered. Further, the taxonomy developed in the previous chapter is used in a preliminary study of the needs of potential customers of DIS. Another important factor influencing the DIS design are the design automation tools which need to be interfaced. A taxonomy of CAD and other application programs with regards to their “integration friendliness” is developed. This taxonomy can be used by CAD vendors as a guidance for development of software which can be better integrated in a higher-level DIS. Based on the needs which a DIS has to satisfy, the potential applications of the design information and the specifics of the software environment, the functional requirements for the design information framework can be summarized as follows: (1) A DIS should be unobtrusive. The whole idea of recording the design information would be compromised if cooperation of the designers is not ensured. The common wisdom suggests that the designers have little to gain from a pure DIS (unless they work on a similar project in the future) and something to lose (e.g., they become less valuable to the company when the knowledge becomes readily available for re-use by others). There are some non-technical means to achieve designers' cooperation (e.g., by providing designers with job security, or involving them in the development of the DIS to be used). From technical point of view, though, one way to achieve a better response from the designers is to lower the time overhead they have to put into recording their activities. This can be achieved by establishing direct data exchange links to CAD and other application programs where possible. (2) Completeness of DR. The data stored should be sufficient to support as much as feasible from the queries discussed in Section 4.1 and from the intended applications: design information and rationale sharing, change propagation, constraint maintenance, design re-use, and design process management, control, and analysis. This implies, that design steps must be supplemented with the reasons and constraints for design decisions (among other information). Another implication is that at least part of the information should be in computer-intelligible format allowing automatic inferencing, not just retrieving of data. In particular, constraints (e.g., tables, graphs, and equations) should be available in a computer-intelligible format which can be used for design automation or change propagation. (3) Uniqueness of DR. The redundancy of information should be minimized. This is important not only to reduce the data entry load on the DIS users and not as much to lower the hardware requirements of the system, but rather to avoid possibilities for data discrepancies due to poor coordination of different design databases. (4) The design information should be accessible at different levels of detail; high-level views should be supported, for example, for design project management, while finer level of detail might be needed for such applications as design learning. (5) Incremental and incomplete specification of the design process and product data should be supported. This is the natural state of information in a DIS. Conflicting design specifications should be able to co-exist until later stages of the DP. (6) Easy search for a specific design information as well as generation of summary information. (7) A DIS should enforce a design methodology if required but should be flexible enough to serve as a knowledge acquisition tool. Different approaches (e.g., "top-down" or "bottom-up") should be adequately supported. (8) A DIS should provide a cost effective way to record DP. Besides the human effort this should take into account the hardware requirements. (9) As a corollary from requirements (1) and (3), a DIS should be compatible with existing application software used in the engineering design. It should make use of opportunities for static or dynamic data exchange with such products, whenever these possibilities exist. (10) Since one of the applications targeted by this work is design information sharing, a DIS should allow remote access to its data from multiple workstations. In addition, as a corollary from requirement (9) and since different application tools will reside on different workstations, a DIS should be able to access data distributed over a computer network. 5 HIGH-LEVEL CONCEPTUAL DATABASE SCHEMA This chapter formulates a high-level conceptual database representation to satisfy the functional requirements identified in Chapter 4. Since this schema determines to a high degree the functional capabilities of the developed DIS, the major issues are first identified, the pros and cons of the alternatives on each issue are compared, and the selections made are pointed out. The process used to develop and refine the database schema is described briefly in Section 5.2. It applies some design methods and techniques. The resulting high-level conceptual schema is specified in Section 5.3. Lastly, a directed graph representation of various composite entities is proposed in Section 5.4. 5.1 Issues and Alternatives The major issues considered being important for the work and the decisions made based on the targeted applications of the DIS are the following: 5.1.1 Level of formalization The level of formalization indicates how structured (i.e., computer -intelligible) the representation of the design process and associated product data is. At one extreme, only human interpretable representation could be stored (e.g., video and audio recordings of the design process, unstructured text, sketches - possibly, scanned into a computer, etc.). The benefit of this approach is its flexibility with regards to DP and product data which can be represented. On the other extreme, an attempt can be made to store the design process as a computational procedure (leaving out any additional information); this "program" then can be run on a computer without any need of human interpretation and intervention. Such an approach has far less flexibility, but allows to build more automated functionality into the DIS. Many middle-ground solutions could be found. This work, as outlined in the previous chapter, targets both types of applications - those which require computer-intelligible data and those assuming existence of additional, only human-interpretable information. Hence, both types of information are considered being important (see functional requirement (2) in the summary of Chapter 4). A hybrid model is proposed. It contains both computer and human - interpretable information. The computer - intelligible information is supposed to serve such applications as design automation and design analysis. Human-interpretable information can be used in such applications as product re-design. 5.1.2 Representation Granularity (level of abstraction) Design process and product representation could be at a single level of abstraction (i.e., no design process or product data entities are composed of others) or at multiple levels (i.e., there are composite entities at higher levels of abstraction which might reference more atomic entities at lower levels). In the former case, the issue is what should be this single level of abstraction. For the latter case, an issue is what is the lowest level of granularity in DIS. More abstract representations require less resources to record and later retrieve, search, and, generally, process the design representation. This is an especially important factor when the designers’ time is concerned. Of course, the representation granularity has to provide sufficient usefulness of the information recorded. Similar to the decision on the level of formalization, the selection of representation granularity is based on the needs of the variety of the targeted DIS applications (more specifically, the functional requirement (4) from the summary of the previous chapter). The approach envisaging multiple levels of abstraction was employed in this work. Such an approach allows to serve better the requirements of the different target applications of DIS. The finest level of granularity (primitive design methods and design variables) were selected based on the potential application requiring it - design automation. Hence, at that level recording of routine calculation procedures is possible. The composite entities provide different views at the set of primitives and also might have human- interpretable (e.g., multimedia) data associated with each of them. 5.1.3 Minimal Set of Primitives Identification of a minimal set of primitive entities (design operations, variables, actors, etc.) and their attributes sufficient to support targeted applications was important so that the DP and Product Data could be recorded in terms of primitives. Based on the functional requirements (2) and (3) outlined in the summary of Chapter 4, the set had to be "complete" (i.e., being able to describe the design information to a level of detail which would adequately support the applications) and "unique" (minimizing the redundancy of information). Formal methods of descriptive design process modeling were used to identify the set in this work. Design activities considered irrelevant for the targeted application were discarded. More details are provided in Section 5.3. 5.1.4 Design Process, Methods, Constraints, and Rationale Representation There appears to exist some ambiguity in the research community as to what the terms Design Process, Methods, Constraints, and Rationale exactly mean and what the relationships between them are. As noted in Chapter 2, for example, along one of the approaches the DP is considered a specific case of the decision making process. Hence, DP according to that paradigm can be adequately represented as a set of decisions made and the rationale for these decisions. Design Rationale is also being represented in various ways. One approach, for example, employs a set of decisions made and pros and cons for each decision (the IBIS method). Other approaches involve recording design constraints influencing the design (e.g., equations, graphs, etc.). Further, the design constraints for a specific design problem (e.g., a system of simultaneous equations describing the relations between the parameters of a V-belt drive) along with the methods for their solution can be considered “design procedures” or “design methods”. They are obviously related to (and sometimes blended into) the term DP. On this issue, as on others, based on the functional requirement for completeness of the data model and the diverse range of targeted applications which it has to support, a decision to represent all of the above aspects of a design was made. For the purposes of this work, the following distinction between the terms is made:: Design Process Representation - a representation of a specific instance of a design process (e.g., the design of a specific artifact done by a specific designer during a certain period of time). This representation would typically support such applications as management of an engineering organization or analysis of the DP. Design Method - a procedure used to obtain one model of the artifact being designed (typically, more specific) based on an earlier model of the design artifact (typically, more abstract). For example, “cook-book” design procedures usually exist for routine design tasks. This representation would typically be used for such applications of the design data as change propagation and design automation. As shown further in this chapter, the design methods in the proposed model are associated with the classes of the design artifacts they apply to (e.g., the class of V-belt drives). Design Rationale Representation - a reflection of the selections made by a designer (or a team of designers) during a DP. In particular, there could be decisions about the design methods to use (if there are several alternative methods to design the same class of artifacts) or design processes (e.g., tasks) to perform. The design rationale in the proposed model is represented using a specialization of the IBIS method (issues, alternatives, pros and cons for each alternative, and selection made). The DPR model could also be oriented towards a specific design problem or be general. In the former case, DPR could be a simple combination of design method instances. At the other extreme, each design problem could be considered unique (from DP point of view). The former approach greatly simplifies the database and user interface requirements, as well as the work required from the user. The latter approach provides greater flexibility. Since the DIS developed in this work is not aimed at a specific design problem, the former approach was not applicable. Yet another issue is the structure of DP which is to be representable. For example, one of the existing approaches is to represent processes as directed graphs. Each of the nodes can represent a sub-process and the arcs would correspond to the flow of information between sub-processes. If the graph is constrained to be acyclical, each node can be traversed just once. If a certain process is repeated (due to the iterative nature of the design), the iterations will have to be represented as distinct graph nodes. If the graph structure is allowed to be cyclical, iterations could be represented more concisely. Based on the functional requirement (9), both of these possibilities are allowed in the DPR chosen in this work. 5.1.5 Product Data Representation Since the DIS needs to record product data, an underlying product model was needed. STEP is a major international standard in the area of product data modeling currently under development (with some parts already accepted as an international standard). There are several other standards on product data modeling (p