University of Southern California Dissertations and Theses

A work structure based approach to collaborative engineering design

(USC Thesis Other)

A work structure based approach to collaborative engineering design

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content A WORK STRUCTURE BASED APPROACH TO COLLABORATIVE ENGINEERING DESIGN Copyright 2002 by Li Zhao A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (MECHANICAL ENGINEERING) December 2002 Li Zhao Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UMI Number: 3093950 UMI UMI Microform 3093950 Copyright 2003 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, Ml 48106-1346 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90089-1695 This dissertation, written by L i Zhao under the direction o f h i s dissertation committee, and approved by all its members, has been presented to and accepted by the Director o f Graduate and Professional Programs, in partial fulfillment o f the requirements fo r the degree of D O C TO R O F PH ILOSOPH Y Director Date December 18. 2002 Dissertation Committee Chair Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “Physical concepts are free creations o f the human mind, and are not, however it may seem, uniquely determined by the external world. ” Albert Einstein, 1938 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Acknowledgements The last four years have been the most challenging and rewarding period of time in my life. I would like to thank the following people, for without their support, I would never be able to achieve what I really wanted. I would like to express my deep gratitude to my advisor, professor Yan Jin, for his guidance and encouragement during my years at USC. His advice and insights guided me throughout my study and will continue to guide me through my career. Aside from being an outstanding scholar, Yan is also a good friend and mentor who leads me to the gate of a wonderful life. I would like to thank the other members of my dissertation committee, professor Phil Muntz, professor Geoffrey Shiflett, and professor Satish Bukkapatnam, for being articulate and supportive to my research. Beyond specific critiques of my work, they have inspired me in many ways on how exciting this research work can be. I also want to thank professor Milind Tambe, a member o f my guidance committee, for being helpful and influential on the direction o f my study. I would like to thank all my current and former colleagues in the IMPACT (Improving Manufacturing Productivity with Advanced Collaboration Technology) Laboratory for helpful discussions, critical reviews of research reports, and companionships through the years: Dr. Mohammad Reza Danesh Dezfuli, Dr. Oren Benami, Dr. Kai-Lu Wang, Dr. Jian Cai, Dr. Ping Ge, Dr. Yoko Okinaka, Du Li, Weihua Zou, and Arun Raghunath. Learning about their work opened up new iii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. avenues for my research. Furthermore, I want to thank Mr. Shinji Yuasa from Toyota for providing case study and clarifying industrial requirements. Thanks also to Silvana Martinez-Vergas for her timely administrative support. I would like to thank all my friends for their support and encouragement. In particular, Bang Du, Jie Zhang, Dapeng Xie and Amy Gussin, they have been providing a refuge for me away from the pressures of work and study. Special thanks to Manli Zhu, Changhong Jiang, and Yijie Wang for mentally supporting me to maintain a sense of balance in my life. Finally, I would like to thank my parents, Danya Zhao and Shengling Wang, for their endless love. Without their standing behind me every step of the way it is not possible for me to achieve this goal. I dedicate this dissertation to them. This work was supported in part by Toyota Motor Corporation, Mitsubishi, and National Science Foundation’s award under grant number DMI-9734006. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Contents Epigraph ii Acknowledgements iii List of Tables viii List of Figures ix Abstract xiii 1 Introduction..............................................................................................................1 1.1 Background and Motivation................................................................................. 1 1.2 Research Questions..............................................................................................5 1.3 Research Objectives...................................... 8 1.4 Thesis Organization.............................................................................................. 9 2 Related Work......................................................................................................... 11 2.1 Introduction......................................................................................................... 11 2.2 Design Theory...................................................................................................... 12 2.2.1 Systematic Design...........................................................................................12 2.2.2 Axiomatic Design............................................................................................14 2.2.3 Total Design....................................................................................................16 2.2.4 Quality Function Deployment.......................................................................18 2.3 Process Modeling................................................................................................ 20 2.3.1 Digraph.............................................................................................................20 2.3.2 PERT/CPM ..................................................................................................... 21 2.3.3 IDEF3.............................................................................................................. 21 2.3.4 D SM ................................................................................................................ 22 2.3.5 Petri-Net.......................................................................................................... 23 2.3.6 Design Iteration M odel................................................................................. 25 2.3.7 Design Roadmap Framework........................................................................27 2.4 Distributed Artificial Intelligence..................................................................... 30 2.4.1 Contract Net Protocol.....................................................................................30 2.4.2 Multi-Agent Planning Architecture ..................................................... 33 2.4.3 ISAAC Analyst Agent M odel.......................................................................35 2.5 The Need for A New Approach........................................................................ 37 2.6 Summary............................................................................................................. 39 v Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 A Work Structure Based Approach...................................................................41 3.1 Introduction.......................................................................................................... 41 3.2 A Process Driven Work Paradigm....................................................................42 3.2.1 Requirements for A Conceptual Framework..............................................42 3.2.2 A Three-Level Process Driven Work Paradigm........................................ 44 3.3 A Work Structure Based Approach...................................................................47 3.3.1 Current Practice and Its Problems................................................................ 48 3.3.2 A New Approach: Work Structure Based Approach.................................50 3.3.3 The Steps of W SBA....................................................................................... 55 3.3.4 The Benefits and Challenges.........................................................................65 3.4 Summary.......................................................... 6 8 4 An Active Work and Process Model for WSBA...............................................69 4.1 Introduction.......................................................................................................... 69 4.2 Concepts and Definitions of AW PM .............................................................. 70 4.2.1 The Part of “Work” Model............................................................................70 4.2.2 The Part of “Process” Model.........................................................................78 4.3 Summary...............................................................................................................80 5 The Development of W SB A................................................................................. 83 5.1 Introduction.......................................................................................................... 83 5.2 Case Study: Building B locks.............................................................................84 5.3 Work-Element Operations................................................................................. 8 8 5.3.1 The Starting Point: Initial Work-Element...................................................90 5.3.2 Operation 1: Object-based Splitting WE-Splitb ......................................... 91 5.3.3 Operation 2: Operation-based Splitting WE-Split°....................................92 5.3.4 Operation 3: Operation-based Sequencing WE-Seq°................................ 93 5.3.5 Operation 4: Object-based Sequencing WE-Seqb......................................95 5.3.6 Operation 5: Operation-based Merging WE-Merg°...................................96 5.3.7 Operation 6 : Obj ect-based Merging WE-Mergb........................................ 97 5.4 Work-Net Algorithms.........................................................................................99 5.4.1 Constructing A Work-Net: WN-Constructing............................................99 5.4.2 Adding An Activity: WN-Activity Adding................................................103 5.4.3 Removing An Activity: WN-ActivityRemoving..................................... 105 5.4.4 Combining Activities: WN-Combining.....................................................107 5.4.5 Dividing An Activity: WN-ActivityDividing...........................................109 5.5 Active-Process Algorithms.............................................................................. 113 5.5.1 Generating Active-Process: AP-Generating.............................................113 5.5.2 Simulating Active-Process: AP-CriticalPathFinding...............................116 5 . 6 Summary.............................................................................................................119 6 System Realization and Verification................................................................ 121 6 .1 Introduction........................................................................................................ 121 vi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.2 System Architecture......................................................................................... 122 6.3 A Testing for A Hypothetic Design Scenario: Building Blocks................ 127 6.3.1 Startup and Login..........................................................................................129 6.3.2 Task Decomposition..................................................................................... 129 6.3.3 W ork-Element Elaboration......................................................................... 131 6.3.4 Work-Net Configuration..............................................................................132 6.3.5 Active-Process Collaboration and Adaptation..........................................133 6.3. 6 Work-Net Adaptation................................................................................... 137 6.4 A Testing for A Real Design Scenario: Inner Front Door Design.............. 142 6.4.1 Link Between Product Model and AW PM ............................................... 142 6.4.2 Interaction Between Agents and AutoCAD.............................................. 145 6.4.3 A Result From The Testing......................................................................... 147 6.5 System Evaluation and Discussion................................................................ 148 6 . 6 Summary............................................................................................................152 7 Contributions and Future Work.......................................................................153 7.1 Contributions..................................................................................................... 153 7.1.1 On Collaborative Engineering Design Methodology...............................153 7.1.2 On Engineering Process M odeling............................................................ 155 7.1.3 On Software System Development............................................................ 157 7.2 Future W ork...................................................................................................... 159 Bibliography 161 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List of Tables Table 5-1: Resources for Building Blocks.......................................................................85 Table 5-2: The activity table for BB example................................................................102 Table 5-3: The filter table for BB Example...................................................................102 Table 5-4: The permutation result of AP-Generating...................................................115 Table 5-5: The combination result of AP-Generating...................................................116 Table 5-6: The result of AP-CriticalPathFinding.......................................................... 118 Table 6-1: The work-element information table for activity a^.................................. 131 Table 6-2: Design activities of the Inner Front Door problem ................................... 143 Table 6-3: The work-elements of Inner Front Door Design........................................144 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List of Figures Figure 2-1: Position of proposed research....................................................................... 11 Figure 2-2: Process for Systematic Design...................................................................... 12 Figure 2-3: Process for Axiomatic Design....................................................................... 15 Figure 2-4: Process for Total Design................................................................................17 Figure 2-5: The House of Quality in QFD....................................................................... 18 Figure 2-6: An Example for Digraph................................................................................21 Figure 2-7: An example for PERT/CPM .........................................................................21 Figure 2-8: An example of Process Flow Schematics for IDEF3.................................22 Figure 2-9: An example for D SM ..................................................................................... 23 Figure 2-10: An example for Petri-Net............................................................................ 24 Figure 2-11: A process for an Automotive Stamping Die Design exam ple............... 26 Figure 2-12: The Signal Flow Graph of the Die Design Example................................26 Figure 2-13: Different views in DR framework.............................................................. 29 Figure 2-14: MPA single cell configuration....................................................................33 Figure 2-15: ISAAC model generation and analysis......................................................36 Figure 3-1: Three-level process driven work paradigm................................................. 44 Figure 3-2: A view of current practice............................................................................. 48 Figure 3-3: The Work Structure Based Approach..........................................................52 Figure 3-4: Major concepts and operations of WSBA................................................... 54 ix Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 3-5: The steps of WSBA........................................................................................ 65 Figure 4-1: A simple work-net illustration......................................................................71 Figure 4-2: Activities and work-elements........................................................................ 74 Figure 4-3: An illustration for the “work” m odel...........................................................78 Figure 4-4: Active-Process and working-procedures......................................................79 Figure 4-5: Layered Active Work & Process M odel......................................................81 Figure 5-1: Building Blocks case example...................................................................... 85 Figure 5-2: Activities involved in Building Blocks........................................................8 6 Figure 5-3: CPM chart for Building Blocks.....................................................................87 Figure 5-4: The initial work-element of activity a^.........................................................90 Figure 5-5: Object-based work-element splitting W E -S plit.........................................92 Figure 5-6: Operation-based work-element splitting WE-Split0 ...................................93 Figure 5-7: Operation-based work-element sequencing W E-Seq°...............................94 Figure 5-8: Object-based work-element sequencing WE-Seqb..................................... 95 Figure 5-9: Operation-based work-element merging WE-Merg°.................................97 Figure 5-10: Object-based work-element merging WE-Mergb..................................... 98 Figure 5-11: Algorithm of WN-Constructing................................................................100 Figure 5-12: Constructing a work-net.............................................................................101 Figure 5-13: Algorithm of WN-Adding..........................................................................103 Figure 5-14: Adding an activity.......................................................................................105 Figure 5-15: Algorithm of WN-ActivityRemoving......................................................105 Figure 5-16: Removing an activity.................................................................................106 x Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 5-17: Algorithm of WN-ActivityCombining.....................................................107 Figure 5-18: Combing two activities..............................................................................109 Figure 5-19: Algorithm of WN-ActivityDividing ...................................................110 Figure 5-20: Dividing an activity.................................................................................... 112 Figure 5-21: Algorithm o f AP-Generating..................................................................... 113 Figure 5-22: A simple example for AP-Generating......................................................115 Figure 5-23: Algorithm of AP-CriticalPathFinding......................................................116 Figure 5-24: A simple example for AP-CriticalPathFinding.......................................118 Figure 5-25: Summary of the mechanisms and algorithms.........................................120 Figure 6-1: Active-Process system architecture............................................................ 122 Figure 6-2: The testing BB case example...................................................................... 128 Figure 6-3: Screen dump - APS web page and login..................................................129 Figure 6-4: Screen dump - task decomposition ..................................................130 Figure 6-5: Screen dump - work-element elaboration................................................ 132 Figure 6 -6 : Screen dump - work-net configuration.....................................................133 Figure 6-7: Screen dump - active-process generation and simulation..................... 135 Figure 6 -8 : Screen dump - active-process coordination............................................. 135 Figure 6-9: Screen dump - active-process execution................................................. 136 Figure 6-10: Screen dump - engineering design w ork................................................136 Figure 6-11: Screen dump - updated tasks................................................................... 139 Figure 6-12: Screen dump - updated work-net.............................................................140 Figure 6-13: Screen dump - updated active-process...................................................140 xi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 6-14: Screen dump - the final product m odel...................................................141 Figure 6-15: Geometry model of design activity A i.....................................................143 Figure 6-16: Geometry model of design activity A 2 .....................................................143 Figure 6-17: Geometry model of design activity A 3 .....................................................144 Figure 6-18: Geometry model of design activity A4 .....................................................144 Figure 6-19: Work-Net for the Inner Front Door D esign........................................... 144 Figure 6-20: Interaction between Agents and CAD in a design cell..........................146 Figure 6-21: Screen dump - interface of Mechanical Desktop 5.0............................146 Figure 6-22: CPM chart for the testing example.......................................................... 147 Figure 6-23: Optimal active-process for the testing example.................................... 148 xii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Abstract Design is a process where products are defined and created. In the new century, the unceasingly growing complexity of engineering products needs more collaboration than ever. Collaborative design requires multiple people working together to achieve a uniform goal and emphasizes how integrated processes should be carried out systematically. Common data sharing approach and workflow management approach have been developed for engineering designers and project managers to conduct collaborative design. However, in current practice, these approaches are separately applied, i.e., the managers do planning based on workflows without knowing much of engineering details, while designers do engineering work with little knowledge of the overall project. This isolation causes the problems of process efficiency and flexibility, which are highly concerned by many industrial practitioners. In this research, we developed a work structure based approach for collaborative engineering design. Our goal is to improve product coherency, process efficiency, and process adaptability of collaborative engineering design by integrating management processes with engineering contents and endowing designers with authorities to make certain managerial decisions through coordination. For a specific task, a work structure is a network of engineering work items connected by engineering dependencies, which serves as a skeleton to generate feasible processes. From these processes, the one which best fits the current xiii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. situation is dynamically determined through the coordination between the manager and designers based on their various criteria. In order to capture engineering dependencies and link workflow with engineering details, an adaptive process model has been developed to model engineering work, work structure, and processes. Based on this model, a set of mechanisms and algorithms have been developed for intelligent agents to provide knowledge and coordination support for designers. As a result of this research, a comprehensive framework has been developed to support large-scale product development projects. Experiments of using this framework showed that by following this approach, engineering design processes can dynamically adapt to both requirement and technology changes, and the process efficiency can be significantly improved. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1 Introduction 1.1 Background and Motivation Design is a process where products are defined and created. Modem Large- scale engineering design problems, such as automobile design and aircraft design, are inherently very complex. Numerous pieces of mechanical and electronic parts, large amount of performance and safety calculations and analyses, various models and simulations of product systems and components created by CAD/CAM/CAE tools, and different prototypes built for testing and validating, are major factors that lead to the complexity of these contemporary design problems. No single individual is capable of dealing with this high level of complexity so that multiple people are required to work together. In the new century, the unceasingly growing complexity of products requires more collaboration than ever. Design that requires multiple people working together collaboratively to achieve a common goal is collaborative engineering design. It emphasizes how integrated processes and products are created systematically. This implies heavy use of computer applications, Internet communications, and organization management in order to save time, lower cost, and improve quality. Research on collaborative engineering design, as a relatively young discipline in design field, has three major areas, i.e., engineering work and coordination, project management, and knowledge management. Each of these three areas has its own concern: engineering work and coordination is more focused on coherency, i.e., 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the design solutions provided by multiple designers should work with each other; project management is more focused on efficiency, i.e., how to reach the maximal use of available resources; and knowledge management is more focused on adaptability, i.e., with small updates, the products and processes can keep being effective in a dynamically changing environment. Based on the experience and observations of working with several major automotive companies, we identified real world practical problems in the areas described above as following. In the area of engineering work and coordination, there are three major practical problems. First, it is very hard to maintain product consistency. In the universal decomposition-integration method for solving complex problems, decomposed activities are carried out separately by different designers. As a result, in integration the solutions provided by individual activities are often ill matched, either structurally or functionally. The reason is that usually these activities are highly coupled with each other, but unfortunately designers may overlook the relationships with others. Second, coordination of working procedures among designers is significantly insufficient. When multiple designers from different disciplines work together over distance and time, their objectives may not be uniform because they have their own intentions in making decisions. Designers have the freedom to determine working procedures for their own design activities. These working procedures may be optimal in local, however they may be incompatible with others and may have negative impacts in global. It is important for designers to 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. know about what and when they should coordinate with others for global benefits. Third, designers often lack means for coordination. Even when a designer recognizes the relationships with others and he or she intends to negotiate the working procedures, without a reliable coordination mechanism and system support the communication effort may lead to disruption. For example, it will be problematic if a designer with little experience holds a strong position during the coordination process; or it will be very inefficient if redundant and sometimes overwhelming amount of communications are passed back and forth during the coordination. Designers should exactly know how to successfully and efficiently go through the whole coordination process. In the area of project management, there are four major practical problems. First, it is difficult to adjust to requirement changes. Modem engineering design problems are customer-oriented so that the product definitions are always prone to change. Therefore, corresponding process definitions should be flexible enough for a project manager to do modifications to meet new requirements without breaking the current working process. Second, unpredictable exceptions always occur during process execution. Exceptions can arise from the changes of resources, organizational structures, and company policies. They also include process errors such as bad design decisions. The project manager should be able to detect the exceptions before they have disruptive impacts on the cost and schedule. Third, resources are not always efficiently used. Resources, especially well trained human experts, are expensive. The project managers are eager to seek the maximal resource 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. utilization on a time-to-time basis. Forth, project managers lack sufficient evaluation tools. Because designers are working over distance and time, it is very hard to monitor their performance and predict their outcome. Thus, the project current state is hard to identify and the discrepancy between the plan and the execution is hard to evaluate. Moreover, the control actions based on the evaluation results are hard to take, because on one hand a tight control policy will restrict designers’ creativity and freedom, and on the other hand a loose control policy will cause the risk of project failure. In the area of knowledge management, there are two major practical problems. First, reusable design and management knowledge, also called experience, is often not well organized in an enterprise. Experience is the most essential asset, which currently can only be accumulated and managed by human beings. Although many training courses are provided and tons of documents are generated, it often happens that a loss of a key designer or a key manager may cause an enterprise to go downhill. Second, currently an enterprise has few means to update and reuse accumulated design and management knowledge for slightly but frequently changing environment. How to apply the essential knowledge with the help o f advanced information technologies to cope with the changes and keep being competitive is highly concerned in most major enterprises. Above is a summary of practical problems we collected from today’s industry. Looking into these practical problems, we find all of them are related to, or partially related to, the issues of product coherency, and process efficiency and adaptability. 4 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Building on previous research and development work, the practical goal o f our research is to develop methods and computer systems to improve coherency, efficiency and adaptability of current practice. 1.2 Research Questions In the previous section we introduced the practical problems and issues we currently face in collaborative engineering design. In this section, we will discuss existing research approaches developed for dealing with them, and point out important research questions and challenges that need to be addressed in order to provide better solutions. In order to maintain the coherency among different design activities, i.e., maintaining consistent product interfaces between different components and solving possible design conflicts between designers, the data sharing approach has been developed and applied, where product data can be shared in a logically centralized product model so that a designer can timely retrieve design options and solutions from other designers and pass his or her results to others through the product model [4] [12] [21][24] [37], This data sharing approach has been proven a good method for transferring design information and correcting design illness. However, it has three limitations. 1) It only contains the results generated by the designers. The information of working procedures, i.e., design actions and events, which describe how these results are actually generated is not a part of product model. 2) The coordination process through which the designers solve design conflicts is not 5 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. captured. 3) The control information which defines how engineering activities should be carried out and how they are related to each other is also missing. Because of these limitations, the data sharing approach is less attractive for efficiency. In order to improve the efficiency, the workflow management approach has been developed and applied, which emphasizes engineering processes and attempts to make them more efficient by planning ahead, i.e., clearly defining design activities, their relationships, responsibilities, requirements, and resources [44][45] [46]. This approach also clarifies the roles of project participants. On one hand, project managers become more important. They can make plans and schedules by creating process definitions, assign tasks to designers by matching task requirements and engineers’ expertise, and manage the progress of the overall project by monitoring design events and making control actions. On the other hand, engineering designers are engaged in their work more collaboratively. After receiving task assignments, designers carry out their work and collaborate with others based on the workflow information to share machine resources, prevent design conflicts, and achieve possible concurrent engineering. Research related to the workflow management approach has been advanced in two general directions. One direction is to develop syntactic and semantic constructs and mechanisms to address the process representation issues [41] [42], Another direction is to study useful analysis and evaluation techniques to support process design by bringing potential coordination problems up front [15][16] [33]. 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In recent years, demand for high quality products, industrial globalization, and relentless competition has made the market more unpredictable. As a result, adaptability to changes has become a key requirement for enterprises’ success. Although the workflow management approach can dramatically improve the efficiency, it is being challenged by the dynamic changing environment which is characterized by high level of uncertainty, i.e., the products and processes worked for “yesterday” may or may not work for “today” or “tomorrow”. Unfortunately, this approach is incapable of dealing with the adaptability due to two reasons. 1) It views processes as static descriptions of plans for product development. It only works for a relatively stable design environment where plans and schedules can be enacted by pre-specified organizational goals, and design procedures and operations can be formalized by pre-defined executive rules. Therefore, it is not capable of adapting to environment changes, e.g., market changes and requirement changes. 2 ) It does not provide project management support for the needs of engineering work and coordination. Engineering processes are designed and controlled purely from the management point of view, where real engineering details are usually not included. Therefore, it cannot cope with technological changes, e.g., resource changes and design changes. To date, there is no valid approach that can successfully deal with the adaptability issue. In this thesis, the research question we attempt to answer is: how can we develop a new approach to handle the adaptability, and at the same time maintain the coherency and improve the efficiency for collaborative engineering 7 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. design? In order to establish the new approach, we have to meet three research challenges: 1) From a methodology point of view, what is the right way of doing things for collaborative engineering design in a dynamic design environment characterized by high level of uncertainty and changeability? 2) From a knowledge point of view, what knowledge is required for successful collaborative engineering design, i.e., coherency, efficiency, and adaptability, and how can we model, capture, represent, and apply it? 3) From an execution point of view, how project managers, engineering designers, and software systems should interact and coordinate with each other? 1.3 Research Objectives In this research, we look into the fundamental infrastructure o f collaborative engineering design, and set the research goals as following: 1) To understand the nature of collaborative design. 2) To explore a new methodology for maintaining the coherency, improving the efficiency, and handling the adaptability of collaborative design. 3) To develop a set of theories and technologies to systematically support engineering work and coordination, project management, and enterprise knowledge management. 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The result of this research is a comprehensive framework that can be applied to achieve successful collaborative engineering design practice. And the objectives of this research are: 1) Define a process-driven work paradigm to guide collaborative engineering design at three levels, namely, engineering collaboration level, project adaptation level, and enterprise knowledge management level. 2) Explore a Work Structure Based Approach to formalize the steps and operations for efficient and effective large-scale product development. 3) Develop an Active Work and Process Model to link engineering processes with product details, identify engineering work and manage their dependencies, generate and analyze working processes which are adaptive to changes. 4) Design and develop a prototype Active-Process System to testify the proposed approach. This thesis makes three important contributions to the knowledge and practice of collaborative engineering design by introducing: 1) A systematic methodology for collaborative engineering design practice. 2) An adaptive process model for dynamic process generation and analyses. 3) A software system for collaborative support by distributed agents. 1.4 Thesis Organization Besides this introduction chapter, this thesis is organized as following. 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 2 provides an extensive review of the literatures related to this thesis. It covers design theory, process modeling, and distributed artificial intelligence. Chapter 3 presents our proposed Work Structure Based Approach for collaborative engineering design. It includes a brief introduction of our process- driven work paradigm which conceptually defines how collaborative engineering should be conducted, and a detailed explanation and step-by-step guidance of the new approach. Chapter 4 presents our formal Active Work and Process Model applied for Work Structure Based Approach. The definitions and notations of work-net, activity, work-element, operation, action, object, parameter, filter, dependency- element, link, active-process, and working-procedure are introduced in this chapter. Chapter 5 further discusses the development of the Active Work and Process Model and the Work Structure Based Approach. Mechanisms and algorithms for work-element elaboration, work-net configuration and adaptation, and active-process collaboration and adaptation are presented, and a hypothetic case example Building Blocks is studied using these mechanisms and algorithms. Chapter 6 presents the architecture of our Active-Process System and discusses the system development issues. Practical applications are developed and tested by a hypothetic design problem and a real industry design problem. Evaluation and verification results are provided. Finally, Chapter 7 concludes this thesis by highlighting the contributions of this research. Directions of future work are also suggested in this chapter. 10 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2 Related Work 2.1 Introduction This research aims at exploring a process-driven approach for supporting collaborative engineering design. Our objectives are not only focused on developing systematic methodology to define the steps and operations throughout the lifecycle of collaborative design projects, but also on building the practical framework for facilitating the product development. Our effort towards the methodology and the framework draws upon three fields of research work, namely, design theory, process modeling, and distributed artificial intelligence, as shown in Figure 2-1. This Research Process Modeling Design Theory Digraph, PERT/CPM, DSM, IDEF3, Petri Net, D esign Iteration Model, D esign R oadm ap Fram ew ork System atic Design, Axiomatic Design, Total Design, Quality Function Deploym ent Distributed Artificial Intelligence . Contract Net Protocol, Multi-agent Planning Architecture, ISAAC Analyst A gent Model Figure 2-1: Position of proposed research This chapter presents an extensive review of the existing theories, frameworks, and techniques related to this thesis. 11 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.2 Design Theory In the field of design theory, research has been done to provide fundamental understandings and ideas on how engineering design work should be carried out. In order to find a systematic way to formalize and accelerate design, general entities and procedures are defined and developed. This research area provides us foundations for understanding design processes. We will review Systematic Design, Axiomatic Design, Total Design, and Quality Function Deployment in this section. 2.2.1 Systematic Design Systematic Design [50] takes a step-by-step approach to design, starting from clarifying the task and product planning, proceeding to the conceptual and embodiment design phases, and finally coming up with detail design, as shown in Figure 2-2. Product planning and task clarifying Embodiment design Conceptual design Detail design Figure 2-2: Process for Systematic Design 1) Product planning and task clarifying At the beginning of a product development, a company must have a product idea that promises to lead to a technically and economically viable product. This product idea cannot be given directly from the customers, instead, it comes from product planning which is a systematic search for, and a selection and development 12 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of, promising product ideas. The starting point for product planning is marketing. A product definition should be generated at the end of this phase. Designers start their work by clarifying a particular problem and define the task as fully and clearly as possible. A detail requirements list, the design specification, should also be drawn up at the end of this phase. 2) Conceptual design Conceptual design determines the principle of a solution. It is the major part of design process in which the basic solution is elaborated by 6 steps: Step 1: Abstracting to identify the essential problems. Step 2: Establishing function structure, which breaks down the overall function to sub-functions. Step 3: Searching for solution principles to fulfill the sub-functions. Step 4: Selecting suitable working principles which fulfill the demands of the requirements list and promise to be economic. Step 5: Firming up into principle solution variants. Step 6 : Evaluating the principle solutions. 3) Embodiment Design Embodiment design starts from the working structure, develops the design in accordance with technical and economic criteria and in the light of further information, and comes up with the point where subsequent detail design can lead directly to production. Several strategies, such as force transmission principle, 13 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. matched deformation principle, balanced force principle, etc, are suggested to guide the designers to advance through the design in this design stage. 4) Detail Design Detail design completes the design lifecycle. It generates final instructions about the layout, forms, dimensions and surface properties of all individual parts, the definitive selection of materials and final scrutiny of the production methods, operating procedures and costs. Overall, Systematic Design approaches the design process from a practical point of view, which enforces designers to think systematically and covers every phase of the design process from custom marketing to final production. It provides many forms, checklists, manuals and guidance to help designers to go through each design phase step-by-step. 2.2.2 Axiomatic Design Axiomatic Design [52] [83] [84] describes the design as a two directional interplays within four domains, namely, customer domain which defines the bottom line of an enterprise, functional domain which defines “what” we need to achieve, physical domain which defines “how” to realize “what”, and process domain which defines the resources needed to carry out “how”. The process for Axiomatic Design is shown in Figure 2-3. 14 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Z l) Mapping Customer Functional Physical Process domain domain domain domain Layer 1 Layer 2 Layer 3 Layer n Decomposition Figure 2-3: Process for Axiomatic Design As shown in Figure 2-3, from left to right is a mapping process across the four domains where a left domain represents problems and a right domain represents solutions. By this mapping process which defines ways to find the solutions in the right domain for the problems generated in the left domain, design is moving from one phase to the next phase. Also shown in Figure 2-3, from top to down is a decomposition process across layers, which moves a design from more abstract to more specific. In this design theory, the design process is operated in a zigzag manner. In each zigzag operation, multiple design alternatives are generated within which a designer will choose one as the solution. To help the designers make good decisions, two axioms are defined for designers to follow: 1) Independence Axiom: maintaining the independence of FRs The Independence Axiom defines the principle of how to do mapping from FRs to DRs. When we map the functional requirements in functional domain to their 15 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. alternative solutions in physical domain, the solution selected from DRs must be satisfying one functional requirement in FR without affecting other functional requirements. This helps to maintain the minimum dependencies among sub solutions and each functional requirement can be satisfied separately. 2) Information Axiom: minimizing the information content for the design The Information Axiom claims that for all of those mappings which satisfy the Independence Axiom, the one needs the minimum information is the best which should be selected by the designer. The information here is defines as the knowledge required for realizing a mapping. Overall, Axiomatic Design classifies engineering design in four domains and provides a unique mapping matrix to organize design process across different domains and decomposed layers. It also introduces the concept of functional dependencies and provides means to deal with them. 2.2.3 Total Design Total Design [60] views the design as a broadly business based activity in which specialists collaborate in the investigation of market, the selection of a project, conception and manufacture of a product and the provision of various kind o f user support. More extensive than Systematic Design, Total Design tries to develop a complete framework for design lifecycle, all the way from the initial customer needs to the selling of the final product, as shown in Figure 2-4. 16 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technology Technique stress Decision Costing | | Manufacture / ORGANISED Figure 2-4: Process for Total Design The lifecycle of Total Design is divided into six major steps as following: 1) Market analysis: analysis of the market or user needs 2) Product design specification: a comprehensive document detailing all the elements required to define the actual product 3) Conceptual design: generation of ideas to meet the specification 4) Detailed design: the technical design of the product 5) Manufacturing: actually making the product 6 ) Product sales and marketing: getting the product off the shelf and to the consumer Overall, Total Design has following advantages: 1) design seems as a “total” process, 2 ) manufacturing, sales and marketing are a vital part of the design theory, 3) design involves participation of experts from various disciplines, 4) it provides a 17 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “Pugh Design Matrix” as an effective tool for concept selection, and 5) it makes integration with other design theories possible. 2.2.4 Quality Function Deployment Quality Function Deployment (QFD) [23] has been used world wide in many industries and sectors to 1 ) prioritize spoken and unspoken customer wants and needs, 2) translate these needs into technical characteristics and specifications, and 3) build and deliver a quality product or service by focusing everybody toward customer satisfaction. The main features of QFD are its focus on meeting customer needs through the use of their actual statements, its facilitation of multi-disciplinary teamwork, and the use of a comprehensive matrix for documenting information, perceptions and decisions. This matrix is commonly called House of Quality (HOQ), which is shown in Figure 2-5. H ow s vs. Hows W ho 1 H ow s 5 W ho vs. W h ats W h ats W h ats vs. H ow s Now vs. W h ats How® Q H ow s v s. How M uches M uches Figure 2-5: The House of Quality in QFD HOQ is the first matrix that a product development team uses to initiate a QFD process. This matrix is especially powerful because of the amount of information 18 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. that can be documented and analyzed. QFD requires that the team ask specific questions about customer needs, competitors, and how their organization will meet the challenges of providing products that delight the customer. The steps in doing so are as following: 1) Identify the customers 2) Determine the customers’ requirements 3) Determine relative importance of the requirements 4) Identity and evaluate competition 5) Generate engineering specifications 6 ) Relate customers’ requirements to engineering specifications 7) Identify relationships between engineering requirements 8 ) Set engineering targets Overall, the major advantage of QFD is that it links the needs of customers with design. The expected and exciting customers’ requirements provide the best opportunity for competitive advantage if we can find a way to make them visible and then deliver on them. However, in this fast changing world, hitting the right target of customer satisfaction is made more difficult by fragmenting customer segments, new technology, and competitive pressures. QFD makes invisible requirements and strategic advantages visible, allows us to prioritize and deliver on them in a focused product development process. 19 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.3 Process Modeling In the field of process modeling, research has been done to represent and analyze design processes in different design domains, especially for describing complex and mature design processes that consist of many design activities. Theses processes often involve engineering dependencies and activity relations, such as feedback constraints, i.e., the result from one design activity may have impact on another design activity so that sometimes it needs to be re-engineered, and precedence constraints, i.e., one design activity must be finished so that another design activity can start. This research area provides us general instruments for supporting project management and workflow analysis. In this section, first we will review some traditional techniques in workflow management and process modeling, and then we will review two process models which are comparable with our research: Design Iteration Model and Design Roadmap Framework. 2.3.1 Digraph Digraph is the simplest way to represent a process. It is a graph whose edges are ordered pairs of vertices. That is, each edge can be followed from one vertex to the next. The only reason it can be viewed as a process representation is that the directed edges indicate the information, or knowledge needs to be transferred. Figure 2-6 is a Digraph example. 20 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 2-6: An Example for Digraph 2.3.2 PERT/CPM PERT (Program Evaluation and Review Technique) / CPM (Critical Path Method) was developed by the United States Department of Defense as a management tool for complex military projects and was soon adapted for being used in educational research and evaluation. Through PERT/CPM, complex projects can be blueprinted as a network of activities and milestones, i.e., the arcs represent activities and nodes represent the milestones. The most useful information carried in PERT/CPM chart is the length of an arc express the time duration to reach a corresponding milestone. Figure 2-7 is a PERT/CPM example. Figure 2-7: An example for PERT/CPM 2.3.3 IDEF3 The Integration Definition (IDEF) method for Process Description Capture (IDEF3) is designed to help collect, document and analyze the processes o f an A,F 21 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. existing or proposed system. It captures precedence and causality relations between situations and events in a form natural to domain experts by providing a structured method for expressing knowledge about how a system, process, or organization works using two types of schematics: Process Flow Schematics and Object State Transition Schematics. Process Flow Schematics capture knowledge of “how things work” in a process, while Object State Transition Schematics summarize the allowable transitions an object may undergo throughout a particular process. Figure 2-8 is a Process Flow Schematics example. , R e q u e s t i m a te r ia l - X • i 1 * 1 ________ J1 I d e n ti f y p o te n tia l s u p p li e r s R e q u e s t b id s E v a l u a te b id s i 1 4 1 i 1 ... > O r d e r r e q u e s te d m a te r ia l * i I d e n t i f y ' ■ - c u r r e n t s u p p li e r 3 1 P r e p a r e P u r c h a s e O b ta in A c c o u n t M a n a g e r 's a p p r o v a l O b ta in a u th o r i z a tio n s ig n a tu r e S u b m it s ig n e d P u r c h a s e R e q u e s t R e q u e s t 1.1.71 1.1.81 1 .1 .9 1 1 . 1 . 1 0 1 Figure 2-8: An example of Process Flow Schematics for IDEF3 2.3.4 DSM DSM (Design Structure Matrix) [81] is a unique matrix representation to indicate relationships between tasks. In such a matrix, columns and rows of the matrix represent the tasks and an “x” in cell(i, j) indicates that task[i] depends on task[j]. It offers a very concise and compact representation, and its matrix operations 22 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. are useful to manager task dependencies to improve a process. Figure 2-9 is a DSM example. Figure 2-9: An example for DSM 2.3.5 Petri-Net Petri-Net [25][58][59] is a graphical oriented language for design, specification, simulation and verification of a system. It is a directed graph that consists of two kinds of nodes: places and transitions. In a Petri-Net, circles and bars represent places and transitions, respectively, and unilateral arcs link either a place to a transition, or a transition to a place. A transition can be an event, an action, a computation step, etc. Corresponding meaning of a place can be a buffer storing pre condition, needed resource, and input data if it is a input place, or a buffer storing post-condition, released resource, and output data if it is an output place. Weight functions are attached on arcs to illustrate the conditions need to be satisfied before firing a transition and the results generated after firing a transition. Each place may contain one or several tokens denoted by dots representing specific information. A vector combining the number of tokes in all places is called a marking. So, a Petri- Net is a five-tuple (P, T, A, W, Mo), where: 23 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P = {pi, p2, . . pm} is a finite set of places, T = {ti, t2, . . tn} is a finite set of transitions, A c ( P x T ) u ( T x P ) i s a finite set of arcs, W: A — » {1,2,...} is the weight function attached to the arcs, Mq: P -» {0,1,2,...} is the initial marking. 6 l 1 P2 © Pi ti P2 t, Pi O p 2 ’ t, 6 p2 Pi 2 h O p 2 (a) (b) (c) (d) (e) 6 Pi h p2 (f) Figure 2-10: An example for Petri-Net As an example shown in Figure 2-10, this Petri-Net contains two places denoted by Pi and P2 , and two transitions denoted by ti and t2 . The initial marking is Mo=[2,l]. A weight 2 is attached on arc Pixti, which means 2 tokens in place Pi are needed to fire transition ti. If no weight function is specified on the arc, it is assumed to be equal to 1. From the initial state (Figure 2-10(a)), either ti or t2 can be fired. We choose to fire ti. After firing ti, 2 tokens in place Pi flow over ti and transform to 1 token in P2 (Figure 2-10(b)). We continue to execute a firing sequence cr=<ti,t2 ,t2 ,ti,t2> (Figure 2-10(b) - Figure 2-10(e)). In Figure 2-10(f), an ending marking Ms=[l,0] is reached, and no transitions can be fired after having M 5. 24 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Most commonly used techniques for analyzing Petri-Net include property analysis and invariant theory. Property analysis focuses on both structural and behavioral properties’ study which depend on the layout and performance of a system. Such properties include reachability, liveness, boundedness, reversibility, conflict, etc. Invariant theory is another powerful method based on linear algebraic operations. The connotative assumption is viewing the transformation o f a marking into another marking, which is represented in Petri-Net as the removal and replacement of tokens from one place to another by firing a transition in between, as two separate linear operations. This makes it possible to represent a Petri-Net with a matrix, called incidence matrix. By doing so, the behavior of a Petri-Net can be viewed as multiplying the incidence matrix. Overall, Petri-Net is most effective when used to capture and analyze dynamic status of a modeled system. As a mature research work, matrix, state equation and tree representations, and constant and stochastic values for execution time have been introduced for structural and behavioral analyses of a Petri-Net. 2.3.6 Design Iteration Model Design Iteration Model [15] focuses on understanding the impact of time- consuming iteration which can be found in complex design problems, and creating tools for modeling the product development and predicting the performance of the project organization. Specific analytical method is provided to calculate the project lead-time using DSM and Signal Flow Graphs techniques. 25 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As an example, Figure 2-11 shows a block diagram for a body panel die design process at an automotive firm. Its corresponding signal flow graph is shown in Figure 2-12. Panel Data Surface Data Analysis Results, '"D ie Geometry Analysis Results Surface Data Surface Data Verification Data Verification Data Production Die Panel Design Die Design Prototype Die Manufacturability Evaluation Surface Modeling Figure 2-11: A process for an Automotive Stamping Die Design example 1. Start 1. Start 6. Die Design-3 2. Die Design-1 7. Init. Surf. Modeling 3. Prelim. Mg. Eval.-1 8. Final Surf. Modeling 4. Die Design-2 9. Final Mg. Eval. 5. Prelim. Mg. Eval.-2 10. End Figure 2-12: The Signal Flow Graph of the Die Design Example In Figure 2-12, the iterative die development process is characterized by activity durations and transition probabilities shown in the arc expressions. The probability and time duration of every redesign task are changed after the first try. For example, the die design task appears three times as circle 2, 4, and 6 , with 3, 2, and 1 time durations and with 1, 0.75, and 0.25 probabilities. 26 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Given the signal flow graph representation of the die design process, graph transmission can be operated using the node elimination techniques (an algebraic technique for graph simplification), or using the set of node equations and eliminating the intermediate variables (a mathematical operation of signal flow graphs). Using this analytical method, the expected value of the project lead-time for the die design process example can be calculated by the form of TS f = [z 5(0.4+0.42z 3)] / (1-0.18z5 ), which is 36.2 time units. To gain further insights of the power of Design Iteration Model, there are two other analytical properties provided. One is sensitivity analysis. The sensitivity of lead-time to each parameter can be calculated in value of quantity hence we can obtain the impact of each small task on the overall project duration. The other is to calculate the participation factors of the system, which allows us to obtain the interactions between each two small tasks in value of quantity. Overall, Design Iteration Model has strong analytical power on project duration and its distribution. It can also be used to predict important performance features such as the expected mean and variance of lead-time for projects where redesign work are highly demanded. 2.3.7 Design Roadmap Framework Design Roadmap Framework [51] is an engineering process representation and modeling technique for describing large-scale, mature design processes involving a number of tasks. Its underlying representation is a graph of information-processing units with explicitly defined input and output feature elements. 27 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A Design Roadmap is a bipartite graph consisting of two primary node types, tasks and features. A task is the fundamental unit of a process. A feature is a unit of information or material upon which a task operates, such as data, e.g., scalar, vector, list, and graph, an aggregate property, e.g., electrical properties and geometry, or an artifact, e.g., a schematic drawing. Design Roadmap Framework clarifies three kinds of dependencies: 1) Precedence relationships among tasks and corresponding input/output entities (features) 2) Constraint relationships among elements of the design 3) A hierarchy of objects at different levels of detail or abstraction Furthermore, three classes of link objects encapsulate these dependencies: 1) Precedence link is defined between a task and a feature. It is the primary mechanism by which the Design Roadmap Framework captures the process and information flow. 2) Constraint link always connects two feature nodes. 3) Abstraction link connects the members of a sequence of nodes to a single parent node. As shown in Figure 2-13, different representation views are also developed in this model, each of which can support specific needs: 1) Graph view combines the features of Diagraph, PERT and SADT (Structured Analysis and Design Technique) representations. An example is shown in Figure 2-13 (a). 28 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2) Abstraction tree view adopts the IDEF representation. An example is shown in Figure 2-13 (b). 3) Matrix view is similar to DSM, which can be used to detect Circuits. An example is shown in Figure 2-13 (c). 4) List view provides a design specification to highlight precedence and constraint dependencies between adjacent nodes. Fee' Iback from F4 (a) A DR G raph View @ — »[V]— > Q — (b) A DR A bstraction Tree View (c) A DR Matrix View Figure 2-13: Different views in DR framework Overall, Design Roadmap Framework develops a process model for integration of component processes which 1 ) is based on an explicit relationship between tasks and entities (features); 2 ) combines precedence, abstraction and constraint relation; 3) is able to differentiate parallel and alternative paths; 4) is able to generate multiple custom views of the process; and 5) has rules for maintaining consistency o f the model while performing all operations. Some potential applications of this framework are: 1 ) to document complex engineering processes; 2 ) to design systems that require an integration of many functional components; 3) to detect and resolve 29 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. process anomalies; 4) to plan and manage dynamic collaborative projects; and 5) to distill reusable expertise into process templates and components. 2.4 Distributed Artificial Intelligence As described in the first chapter, to make a framework for collaborative engineering design practical and release designers from demanding coordination effort, intelligent agent technology should be used to collect the needed information, capture design events, monitor and report the progress, organize process knowledge, and provide collaboration means. Intelligent agents have to play an important role in this framework, as intelligent assistants for designers who master engineering fundamental knowledge, specific domain knowledge, and general organization and business methods. To date, tremendous work has been done in distributed artificial intelligence field on how to develop intelligent agents for supporting communication, negotiation and coordination of distributed problem solving, and how to extract and gather needed information from different software applications for making plans and decisions. This research area provides us the technologies which can be adopted for facilitating the coordination, analysis and optimization of design. In this section, we will briefly review Contract Net Protocol, Multi-Agent Planning Architecture, and ISAAC Analyst Agent Model. 2.4.1 Contract Net Protocol The Contract Net Protocol [77] is a high level protocol designed to facilitate distributed problem solving. This protocol assumes that a single problem is 30 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. cooperatively solved by a set of independent nodes. Each node is a sophisticated problem solving system that has a part of knowledge to solve a sub-problem but no one has sufficient information to solve the entire problem. Each node also has the ability to modify its behavior when the environment changes and make its own communication and cooperation strategies with other nodes. The overall task needs to be first decomposed into sub-tasks and then solved by different nodes. The efficiency is achieved by sharing the task between the nodes. Each node in a Contract Net takes two roles: “manager” who is responsible for assigning a task, monitoring the execution and processing the results, and “contractor” who is responsible for the execution. Typically, a node can take either one of these two roles, or both. There are two key issues: 1) how a “manager” node can find the most appropriate idle “contractor” node to accomplish a task at a time; and 2 ) how a “contractor” node can find a most appropriate task to execute when it is idle. To address these two issues, two problems need to be solved: 1) connection problem, i.e., “managers” and “contractors” need to make connections and communications; and 2 ) identification problem, i.e., it is important to find the most suitable “manager”-“contractor” pair. Contract Net Protocol emphasizes the communication and negotiation. The ways to solve the connection problem and identification problem are based on negotiation. There are four important ideas involved in the negotiation process: 1) It is a local process that does not involve centralized control. 2) There is a two-way exchange of information. 31 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3) Each part to the negotiation evaluates the information from its own perspective. 4) Final agreement is achieved by mutual selection. A typical negotiation is processed by three message exchanges: 1) Task announcement: the “manager” broadcasts or sends (if the “contractors” are identified) a message demanding a service. This message includes the destination address, origin address, message type (“TASK ANNOUNCEMENT”), contract number, task abstraction, eligibility specification (contractor requirements), bid specification (characteristics of the demanded service), and expiration time. 2) Task bid: those “contractors” that can accomplish the demanded requirements answer the manager and submit a bid that details its offer. This message includes the destination address, origin address, message type (“BID”), contract number, and node abstraction (“contractor’s offer). 3) Task award: the “manager” analyzes and compares the submitted bids, and awards the task to the “contractor” who provides the best service. If no bid can accomplish the expectation, the “manager” can start another demand. The awarding message includes destination address, origin address, message type (“AWARD”), contract number, and task specification (further data or specifications to execute the task). Overall, Contract Net Protocol is the first research effort to use a negotiation process that involves a mutual section by both “managers” and “contractors”, and it 32 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. offers means to structure high-level interactions between nodes for cooperative task execution. 2.4.2 Multi-Agent Planning Architecture The Multi-Agent Planning Architecture (MPA) [96] is a framework for combining different information technologies into a system to solve large-scale planning problems that cannot be solved by individual systems, but rather require the coordinated efforts of agents and human experts. MPA agents are sophisticated problem-solving systems making decisions in their own right. These agents are divided into two groups: base-level cells and meta level planning cells. Base-level cells take the responsibility to provide sequential solution generation and meta-level cells employ base-level cells to support parallel generation of qualitatively different solutions. Figure 2-14 is the architecture for generating single solutions to a planning task, where the arrowed links represent message flow, and links without arrowheads show planning cell composition. Create a plan Plan com plete R equest expand \ next level KQML M essage Plan Server, Plan ok? Annotations Triggers PA Tem poral R easoner (OPIS) Agent PA Schedule Critic (new) PA Scheduler (OPIS) PA Tem poral R easoner (Tachyon) Meta-PA Critic M anager (SIPE-2) PA S earch M anager one-level (SIPE-2)________ PA Tem poral Constraint Critic (SIPE-2) Meta-PA Planning Cell M anager (PRS) Planning Cell Designator Figure 2-14: MPA single cell configuration 33 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Planning-Cell Manager (PCM) is a meta-PA that controls the entire process, including initialization of the planning cell. The PCM specifies a Planning Cell Designator (PCD) who gives the name of the agent that fulfills each role in the planning cell. The Plan Server supports annotations, triggers, and different views of plans. Annotations are used to record features of the plan and triggers are used to notify agents of the posting of those features. The plan is written to the Plan Server, which can be understood by the scheduler and the planner. The Plan Server answers queries about the plan, and handles the annotations and the triggers. During planning, the Cell Manager repeatedly calls the Search Manager and the Critic Manager, and appropriately reacts to the messages returned until a final plan is found. The Cell Manager may change its planning strategy dynamically. The Search Manager expands the plan to another level of detail and writes the new plan to the Plan Server. The Critic Manager writes annotations about the plan, sometimes modifies the plan, and calls other agents, such as the Reasoner and Scheduler. The Scheduler is then called periodically to check the resource allocations. Depending on the PCM planning style, the period can be once per node, once per level, or once per plan. The Scheduler can recommend new resource assignments, which causes the Schedule Critic to modify the plan. The Scheduler posts annotations declaring which resources are over-utilized or near capacity. If resource constraints are sufficiently unsatisfied, it reports a schedule failure. 34 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Overall, MPA provides great flexibility. Separate software systems (OPIS, Tachyon, and SIPE-2, using KQML and PRS for support) cooperatively generate a plan. They are distributed on different machines, and are combined in multiple ways because of the flexible architecture. The Plan Server allows flexible communication of the plan among agents. The PCM encodes different strategies for monitoring and controlling the planning process, thus demonstrating dynamic strategy adaptation in response to partial results. 2.4.3 ISAAC Analyst Agent Model ISAAC Agent [61] is an automated analyst agent developed by Information Sciences Institute, University of Southern California for post-hoc, off-line agent- team analysis. While current research in agent teamwork focuses on providing guidance to agents about what is the good thing to do, this research made advancement in analyzing agent-team behavior and providing result to human developer to understand and improve team performance. ISAAC Agent has been successfully tested in the domain of RoboCup soccer tournament. In this research, multiple types of team behavioral models are built and analyzed with different granularities for an agent-team that involves tens or hundreds agents working together. These models are Individual Agent Key Event Model, Multiple Agent Key Interaction Model, and Team Model. Different analysis methods are developed for each model and the results are presented to users with different views. These models and their analysis flows are shown in Figure 2-15. 35 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. M ultiple M odels Current Data Trace Individual Key Agent Actions Key Patterns of Interaction Individual Agent Key Event Model perturbation Analysis Multiple Agent Key Interaction Model Previous Data Trace Engagem ents > Global Team Model - > Recom m endations perturbation Analysis Request Analysis Display to U ser Natural Language Summary Figure 2-15: ISAAC model generation and analysis As shown in Figure 2-15, the Individual Agent Key Event Model analysis emphasizes on critical events in an individual’s behavior history relevant to the team’s success. It uses C5.0 decision tree inductive learning algorithm to create rules for individual’s success or failure. The Multiple Agent Key Interaction Model emphasizes on the key interplays between multiple agents, which lead to the team’s success. It uses pre-defined pattern set to find those key patterns of success. The Global Team Model analysis emphasizes on why a team succeeds or fails over the entire period of engagement time. It uses the case studies mined from all previous available records to determine reasons for success and failure. Overall, ISAAC has two novel ideas in its great effort on teamwork analysis: 1 ) it uses multiple team behavioral models to analyze agent actions at different granularities, and provides analytical results in different aspects of team behaviors for different purposes; and 2 ) it supports perturbations of models which allows users to study what-if reason about agents and suggests agents to do better things to achieve the team’s success. 36 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.5 The Need for A New Approach Above existing research and other related research focus on various aspects of design, and make significant contributions on understanding the characteristics of design and providing useful theories and technologies to improve it. However, they have their own limitations when applied to support collaborative engineering design. The design methodologies developed in design theory area are problem- directed and focus on defining detailed procedures to find good solutions systematically. It is very useful for small-scale design work which can be done in sequence by a single designer or a small group of designers. Although it also applies decomposition-integration method to ease the work, dependencies, relationships and collaborations among sub-tasks are overlooked. Unfortunately, in large-scale design problems, activity relationships, engineering dependencies, and designers’ collaborations have significant impact on the way of doing design. Thus, for a methodology which can be successfully applied in collaborative engineering design domain, information flow and control flow must be considered and optimized besides energy, material and signal flows which have already been studied in existing design methodologies like Systematic Design and Axiomatic Design. Furthermore, supporting systems and tools, other than formalized design procedures, must be developed based on the methodology to practically support the design. In process modeling area, traditional workflow management and process modeling techniques have their own weak points. For example, Diagraph cannot detect circuits so relationships are hard to identify; PERT/CPM is designed for linear 37 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. processes so it becomes a serious restriction when representing a design process with iteration loops and simultaneous interaction; IDEF3 generates a large amount of documents which are difficult to maintain and to trace relationships and circuits, also they can easily lead to ambiguous interpretations; DSM has a very compact dependency representation but the dependencies between nodes are not immediately apparent, and it cannot differentiate different kinds of dependencies; Petri-Net has strong representation and analysis power but it has a major weakness, the complexity problem, i.e., it becomes too large even for a modest-size system. Other than these traditional techniques, recently developed process models and frameworks are often concentrated on one or the other specific aspect of process problems: Design Iteration Model elaborates iteration which is an important feature characterized in large-scale design processes, and provides project lead-time analysis in value of quantity, however, it does not cover other features such as dependency, conflict, coordination, etc, and it does not sufficiently address the representation issue. Design Roadmap Framework, right in the other way, has strong and comprehensive representation power but the analytical ability is weak. And more importantly, like other existing process models, both Design Iteration Model and Design Roadmap Framework are not capable of capturing dynamic information, e.g., the current state of a process and the chain of decisions and rationale that leads to that state. That is, adaptability is not concerned in existing process models. Thus, a new process model is demanded to support both representation and analysis, and deal with dynamic information in changing environment. 38 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Distributed Artificial Intelligence provides strong theoretical and technical insights. However, there is no direct mapping from distributed artificial intelligent problem solving, which is mainly undertaken by agent, to collaborative engineering design problem solving, which is highly involved with human beings, because: 1) design problems are very complicated, i.e., scientific and engineering fundamentals, specific domain knowledge, and general organization and business methods are highly required; 2) design work demands high level of creativity and innovation, however the intelligence and learning ability carried by agents cannot meet the intelligence at this level; 3) design requirements, activities and performance are not programmable and predictable, while agent goals, actions and result have strong causality which can be explicitly encoded; and 4) the actors of design activities, human designers, have strong social roles, psychological features and biological characteristics which are not involved in agents. Therefore, in order to systematically support collaborative engineering design, a new approach is required to overcome the limitation of existing research and address the issues discussed in the first chapter. Our proposed approach, a Work Structure Based Approach, and its related technologies will be presented in the remainder o f this thesis. 2.6 Summary In this chapter, we presented an extensive review of existing research in three fields of design theory, process modeling, and distributed artificial intelligence. In 39 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the field of design theory, we reviewed Systematic Design, Axiomatic Design, Total Design and Quality Function Deployment. In the field of process modeling, we reviewed some traditional techniques such as Digraph, PERT/CPM, IDEF3, DSM, and Petri-Net, as well as two state-of-art process models which are comparable to our work, Design Iteration Model and Design Roadmap Framework. In the field of distributed artificial intelligence, we reviewed Contract Net Protocol, Multi-Agent Planning Architecture, and ISACC Analyst Agent Model. We pointed out some of their advantages and shortcomings in dealing with large-scale collaborative engineering design problems. Above existing research provides a good point of departure for this thesis. From next chapter, we will start to present our approach for supporting collaborative engineering design, a Work Structure Based Approach and its related technologies. 40 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 A Work Structure Based Approach 3.1 Introduction In this chapter, we present our new approach to supporting collaborative engineering design. First, we will introduce a process-driven work paradigm as the overall vision for this research. The emphasis on this conceptual design framework will be the enterprise elements and operations that should be defined and employed for enterprises to succeed. We define three feedback or learning loops, namely, enterprise level learning loop, project level adaptation loop, and engineering level collaboration loop. After that, we will present our proposed Work Structure Based Approach (WSBA) in details. While most research developed to support collaborative design takes either the data sharing approach or the workflow management approach, we try to combine product details and workflow information together and push the design from both sides. The basic ideas behind WSBA are: 1) integrating management workflows with engineering contents is the way to improve collaborative engineering design practice; 2) endowing designers with authorities to make certain managerial decisions through coordination is essential to be efficient and effective; and 3) adapting to both environmental and technological changes is necessary for successful large-scale product development. 41 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.2 A Process Driven Work Paradigm In this section, we start our discussion on the requirements for a conceptual collaborative design framework. Then we will go through the process-driven work paradigm with three feedback and learning loops defined for enterprises’ operations. Although this dissertation does not cover all the issues included in this work paradigm, this section shows our research vision on what is the ideal framework for an enterprise to conduct contemporary collaborative design. 3.2.1 Requirements for A Conceptual Framework Engineering and management activities are not randomly carried out. Rather, they are well organized and arranged based on a clearly defined conceptual framework. Companies face the challenge of the high levels of product complexity, environment mutability, and market competition. We identified following requirements for a conceptual framework to help the companies to succeed. First, the conceptual framework should help engineering designers to share needed product and process information. On one hand, designers need to share the product information in which their engineering tasks are involved, e.g., which part of the product data is needed from others, which part of the design result is needed to deliver to others, and which part of the design work should be carried out through coordination. On the other hand, designers need to share the process information in which their design activities are involved, e.g., which activities are related, who is responsible for what, to whom to ask for design data, and to whom to deliver a result. 42 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Moreover, designers should coordinate local working procedures with each other for the benefits of the overall project, and be aware of the status of related activities. This information of current situation can be used to determine and adjust working procedures and seek possible opportunities for concurrent engineering, i.e., design work should be carried out simultaneously, rather than sequentially, for shorter lead- time and lower cost. Second, it should provide information for project managers to do analysis and make control decisions, help them to allocate and utilize distributed resources, and adapt the project development to the current situation when the environment changes. The design events and designers’ performance should be monitored, e.g. who is available, who is busy, who is advanced, who is behind, who needs help, who did what, and who should do what. By analyzing captured information, managers should be able to predict whether the overall project requirements can be satisfied, and decide what need to be done to achieve the design goals. And most importantly, when requirements are changed or design exceptions occurred, it should provide useful information for managers to make timely adjustment and right decisions to keep the project on track. Third, it should help enterprises to accumulate process knowledge, maintain them, and invent new ideas from previous experience. In our research we adopt the perspective that the operations of enterprises can be viewed as management of collections of projects. Engineering projects are carried out and managed based on plans. To compose a good project plan is the first effort when engaged in a project, 43 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. which should be done by using organized process knowledge accumulated from previous practice and experience. This enterprise learning ability is essential to deal with the frequently changing environment and technologies. In the following, we propose a three-level process-driven work paradigm as the conceptual framework for collaborative engineering design. 3.2.2 A Three-Level Process Driven Work Paradigm As shown in Figure 3-1, the work paradigm we proposed includes three feedbacks or learning loops. They are enterprise level learning loop, project level adaptation loop, and engineering level collaboration loop. Process definition Exei C csi ise k- Enterpris^'- ■teaming loop Engineering ,------1 ------ collaboration I Modify W i-;:- j 6 o p V ____ ) Process repository Project % adaptation looi Project team [ i k ivaluate Stor< Control k Monitor Figure 3-1: Three-level process driven work paradigm The most outside loop shown in Figure 3-1 is enterprise level learning loop. We assume that every enterprise maintains a process repository that stores good and proven processes and activities. When a project is given, a project manager designs specific process definitions by selecting relevant processes and activities from the 44 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. repository, composes and evaluates them, and finally chooses an optimal process definition for the project. The project manager’s experience of applying previous stored process knowledge plays an important role for this operation, and certain simulations can be done to assist the manager. After the original process definition is generated, it is executed by a project team which includes multiple designers from different disciplines. Designers use the original process definition to guide their local work and coordination with each other. Intermediate design results, progress reports, design events along with temporal stamps are either reported by designers or monitored by intelligent software agents to the project manager for the purposes of evaluation, control, and adjustment. At the end of this loop, a final process record carrying all process information is gathered and studied by enterprise level controllers. Lessons learned and knowledge extracted from this record is applied to generate an improved process definition for this project, which is then stored in the process repository for fixture use. The middle loop shown in Figure 3-1 is project level adaptation loop. During process execution, the project manager uses timely generated process execution record to identify the project status and evaluate the progress. The result of the evaluation is compared with the original process definition to find any discrepancy. If the discrepancy is out of a tolerance range, certain control command will be issued to relevant designers, and the original process definition will be modified to fit the current situation. Two possible situations, strain-driven situation and slack-driven situation, may happen in this loop. Under strain-driven situation, the target was set 45 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. too high that by current allocated resources it is impossible to have the work done, or unexpected design mistakes and exceptions happened to cause project delay, cost overrun, or quality decrease. The project manager must either loosen the target or reallocate more resources to rescue the project and recover the process. In contrast, under slack-driven situation, the target was set too conservative. The evaluation result shows that the project team has more capacity to do a more efficient work. The project manager should either tighten the target or remove some resources for other use. Process simulation and analysis tools should be used for supporting manager’s decisions. The most inside loop shown in Figure 3-1 is engineering level collaboration loop. Although the project level management provides short-term control on the process execution comparing with the enterprise level learning, it is only carried out at given milestones rather than on a time-to-time basis. Furthermore, due to the large amount of engineering content carried in large-scale design problems, the project manager usually is not able to make timely management decisions to facilitate designers’ engineering work and coordination. In order to make our proposed framework fully effective and practical, we need means to instantly support designers’ work and coordination. In addition to being updated of intermediate design results from other designers, a designer must know where and how to ask for needed design information. Moreover, to find the maximum coordination opportunities for achieving concurrent engineering, a designer needs to be aware of others’ working procedures and adapt his or her procedures in a time-to-time fashion. 46 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In order to dynamically support this level of engineering work and coordination, research should be done along both theoretical and technical directions. Theoretically, we should address the problem “how can we dynamically identify and manage interdependencies between activities during process execution”. Coordination mechanisms and communication protocols should be developed. Technically, intelligent software agents are required for gathering corresponding design information locally and globally, handling big amount o f communication data, and facilitating design decision-making and tracking. The above work paradigm opens many research topics in collaborative engineering design. The long-term goal of our process-driven research is to explore theoretical and technical solutions to realize this conceptual framework in all three levels, and develop software systems and tools to implement it. In this thesis, we propose a Work Structure Based Approach as the first step to approach this long term goal, which covers the essential topics and issues in the engineering and project levels. In scoping this thesis, the topics and issues in the enterprise level are left for future work, where WSBA shows great potentials. In the following section, we will present WSBA, a new approach for collaborative engineering design. 3.3 A Work Structure Based Approach In this section, we will formally introduce WSBA, a new approach to support collaborative engineering design. We will start from a brief discussion of the current practice of today’s industry and business practitioners, and point out its problems. 47 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Then we will introduce WSBA, which is a new approach that attempts to drive collaborative design from both sides of engineering details and project management. Formal steps of WSBA will be presented, and its benefits and challenges will be stated in this section. More detailed knowledge infrastructures and technologies of WSBA will be further presented in chapters 4, 5, and 6. 3.3.1 Current Practice and Its Problems As introduced in section 1.2, the data sharing approach and the workflow management approach have existed for decades. Various techniques and systems have been developed by industry and business practitioners for practice. In current practice, these two approaches are applied as shown in Figure 3-2. Product Product m odel Acty2 i Workflow 1 - ^ ActyS ^ Act/4 ) Workflow m a n a g e m e n t a p p ro ach D ata sharing approach Figure 3-2: A view of current practice In Figure 3-2, on one hand, project managers do planning and scheduling based on the workflow designed to guide a certain product development. They apply 48 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the workflow management approach to make careful plans by clearly defining design activities and indicating their relationships. And on the other hand, engineering designers work out engineering details based on the product model developed to share product data. They apply the data sharing approach to eliminate conflicts by exchanging timely generated design results. These two approaches are useful in the sense of each of them successfully solves one or the other aspect of collaborative design problems. However, in most enterprises, the workflow and the product model are isolated, and the data sharing approach and the workflow management approach are totally separately applied. That is, the project managers focus on the workflows without knowing much of the engineering details, while the engineering designers focus on the product models without knowing much of the overall projects. This isolation causes two problems, the efficiency problem and the flexibility problem. The first problem with isolation is the efficiency. In current practice, project managers hold important positions. They have to take care of many things to manage the projects so that they are not able to look into engineering details. The result is that their workflows may not reflect real engineering work. Only activity level relationships are clearly defined in the workflows. This causes the efficiency problem. That is, in these workflows, a successor activity cannot start until its predecessor activity has been fully finished, which is indicated by the their activity level relationships. However, if we look into the engineering details of sequential activities, we often find that only small parts of engineering work are related with 49 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. each other between the activities. Therefore, if a part of engineering work in the predecessor activity has been finished, some part of engineering work in the successor activity can actually start. We call this super concurrency and call the relationships between the related parts of engineering work engineering dependencies. If we can capture these engineering dependencies among activities, the efficiency can be significantly improved. Besides the efficiency problem, the other problem with isolation is flexibility, which is related to changes. There are two major kinds of changes in collaborative engineering design. One is environmental change, i.e., requirement change and market change, and the other is technological change, i.e., resource change and design change. These changes may easily happen in the middle of product development, which causes the predefined product out-of-date. Therefore, when the changes happen, the product has to change, and the workflow must change accordingly based on the redefined product. However, this cannot be done with the isolation of the workflow and the product model. We need a link between the workflow and the product to realize it. In order to overcome these two isolation problems and find new ways for collaborative engineering design, we propose a new approach, called Work Structure Based Approach, presented in the following sections. 3.3.2 A New Approach: Work Structure Based Approach Before we present the new approach for more efficient and effective collaborative engineering design, let’s first look into one fundamental question: who 50 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. can make a design more efficient and effective? Let’s consider an analogical question: in a Formula One auto race tournament, who runs a car fast and save? Is it the manager of the team who enacts racing strategy and plan, or is it the driver of the car who masters driving skills and makes instant decisions? Manager’s arrangement, although necessary to decide when and how to provide car service and issue control commands in a competition, it is the driver who finally owns the trophy. Although the question (“Who runs a car fast and save?”) is quite simple and the answer (“The Driver.”) is quite obvious, the rationale behind this case analogy leads to contemplative speculations on the actuality of current collaborative design practice. In current collaborative design practice, project managers hold dominant positions. They are responsible for almost everything of the product development, e.g., arranging design team, controlling product quality, lead-time, and cost, allocating resources, making decisions, and issuing detailed commands to designers based on their decisions. And at the same time, engineering designers are passively engaged in doing important but ordinary engineering work based on managers’ commands and instructions. This passive mode in engineering design is doubtful for both the managers and designers. It both pushes too much burden on the managers and restricts designers’ potentials for a more efficient and effective work. On one hand, critical design decisions made by managers are often imperative and superficial, because the managers usually do not have concrete engineering knowledge and do not have time to look into engineering details to make right and useful decisions. On the other 51 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. hand, designers are following managers’ decisions passively, because they are not aware of the situations of other activities. Designers, as we strongly believe, can do more beyond their current engineering work, since they are the ones who master substantial scientific fundamentals and engineering domain knowledge, they are the ones who exactly know what, when, where, and how to request or provide design information from or to others, and they are the ones who are capable of finding out coordination opportunities to shorten lead-time, lower cost, and improve quality. Therefore, for the purpose of improving collaborative engineering design, we believe one should not separate real engineering work contents from project management, and endowing designers with authority to make certain managerial decisions through collaboration is the key. In order to do this, we propose a new approach which drives the product development from both sides of engineering and management, and provides a foundation for designers to collaborate. This new approach, Work Structure Based Approach, is illustrated in Figure 3-3. Actyl Acty2 Acty3 W orkflow m W ork structure p r o c e s s e s i O W ork t t t r t r ^ W ork: an application of an o p eratio n on a p ro d u ct m o d el item " © „ w W ork stru ctu re: a netw ork of work g ro u p s c o n n e c te d by d ep . ■ © © P ro c e ss: a s e q u e n c e of w ork w hich d o e s not violate th e d ep . P ro d u c t m o d el Figure 3-3: The Work Structure Based Approach 52 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In Figure 3-3, there are three new concepts we introduced in this Work Structure Based Approach. They are work, work structure, and process. In between the product model and the workflow which have already existed and applied to support design, there is something called work. It is an application of an operation on a specific product model item. It is defined from both sides of the management and engineering. That is, from top down, workflow inputs activity relationship information, and from bottom up, product model inputs specific engineering information. After the work in each activity is clearly defined, they are structured and linked together to form a work structure. A work structure is a network of work groups connected by engineering dependencies. It is not a process which can be directly used to guide the product development. Rather, it provides a basis for generating multiple processes. A process, by our own definition, is a sequence of engineering work which does not violate the engineering dependencies captured in the work structure. From a specific work structure, multiple processes can be generated, which one to choose is an issue of optimization. The project manager can pick up one based on his criteria, such as the fastness and profits. However the designers also hold their criteria, such as workability and conveniency. The final working process should be determined by the coordination between the designers and the manager. Late in chapter 4, we will define three important concepts, namely, work- element, work-net, and active-process to model the work, the work structure, and the 53 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. process, respectively. These important concepts, as well as the major operations in WSBA, are further described in Figure 3-4. A ctivities A c t i v e - P r o c e s s Figure 3-4: Major concepts and operations of WSBA As shown in Figure 3-4, after the overall task is decomposed into multiple “activities” (the definition of “activity” will be provided in chapter 4), these design activities will be further elaborated in details. As a result, it will generate multiple “work-elements” for each activity (the definition of “work-element” will be provided in chapter 4). In this work elaboration, product information will be embedded into the process model for explicitly capturing low-level engineering dependencies. These low-level engineering dependencies, also called work-element dependencies, are then collected to configure a “work-net” which is a network of work-elements interconnected by their dependencies which then be shared among activities (the definition of “work-net” will be provided in chapter 4). The work-net itself is not a design process. However, it serves as a basis for all possible design processes whose 54 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. primary elements are presented by work-elements other than activities. Based on the work-net configuration, designers can coordinate with each other, and determine the most suitable process, called “active-process”, which fits the current situation best (the definition of “active-process” will be provided in chapter 4). That is, the active- process is actually a function of time, which can be dynamically adapted to the current work environment. WSBA is a systematic design methodology which is applicable to many types of collaborative design problems. No matter in what specific field, there are four major steps and one additional step to go through WSBA for a successful practice, as described in the next section. 3.3.3 The Steps of WSBA There are four major roles in WSBA. These roles are: manager (single), designer (multiple), agent (multiple, each agent is associated with a designer), and a distributed management system. There are four major steps and one additional step involved in WSBA. The four major steps are: task decomposition, work-element elaboration, work-net configuration, and active-process collaboration and adaptation. The additional step is work-net adaptation. Major step - Step 1: Task decomposition Just as an electronic system can be divided into sub-systems and elements, a complex design task can be broken down into sub-tasks of lower complexity. WSBA aims to support routine or semi-routine product development. It starts from 55 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the point right after product planning. That means, once a task is assigned, the initial product model associated with the task is already defined, and the requirements, goals, and resources are also clarified. Starting from this point, a project manager performs task decomposition which includes three sub-steps. Step 1-1: Generating multiple activities After studying requirement lists, project goals, available resources, and the product model, the project manager decides how many design activities should be created and managed to accomplish the development. Important activity attributes, such as activity name, activity ID, starting time, ending time, needed machine resources, dollar costs, etc, should be defined in this step. Step 1-2: Associating with product model After generating abstract design activities, the manager should associate them with the product model. This step requires minimum engineering knowledge from the manager. He or she should be able to define what part of the product model belongs to a specific activity, and what are the design outcomes should be provided. In section 3.2.2, we assume that an enterprise maintains a process repository storing good and proven processes and activities. The activities stored in the repository are already well defined and associated with a certain product model. In this case, step 1-1 and step 1-2 can be skipped. Step 1-3: Assigning activities to designers After defining design activities, the manager needs to assign each activity to a design unit. A design unit can be defined in different levels of granularity. It could 56 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. be an individual designer or a small group of designers. In this thesis, we treat an individual designer as a design unit, i.e., each activity belongs to one responsible designer. This step requires the manager to be aware of the skills of each designer, because the activity assignment should be match to the designer’s expertise. Overall, the project manager is responsible for the task decomposition, and the knowledge that the project manager should master is: human resource knowledge for assigning activities to appropriate designers, and minimum engineering product knowledge for associating activities with the product model. Major step - Step 2: Work-Element elaboration After a designer receives an activity assignment, he or she should elaborate the engineering work into details. In this step, a new concept work-element is introduced as both an analysis unit of management and an engineering unit of work. Each work-element has two parts of information. One part defines the engineering content and the other part defines the working procedures. It is a bridge between the process model and the product model to link them together. Moreover, low-level work-element dependencies are identified and captured in this step. Both the identification and manipulation of work-elements and their dependencies within a specific activity are carried by the responsible designer for that activity. This work- element elaboration step has three sub-steps. Step 2-1: Generating initial work-elements The responsible designer for a specific activity should generate the initial work-elements using specific engineering knowledge. Each initial work-element is a 57 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. piece of specifiable engineering work performing certain operations on certain objects. The objects represent the parts or components in the product model, and the operations define the actions required to generate expected design results. The objects and operations should be explicitly defined in this step. Step 2-2: Defining work-element dependencies Besides the operations and objects, in order to define low-level work-element dependencies, the inputs and outputs of each work-element also need to be explicitly identified. Among these inputs and outputs, some of them are related to other work- elements which belong to the same activity controlled by the same responsible designer, and the others are related to remote activities which are controlled by other designers. Thus, there are two kinds of work-element dependencies: internal work- element dependencies which specify the relationships of local work in the same activity, and external work-element dependencies which specify the relationships of work among different activities. Step 2-3: Refining work-elements and relations The number of the work-elements generated in step 2-1 can be big, and every work-element is a specific piece of work. By manipulating and managing the internal work-element dependencies which are specified in step 2-2, some work- elements should be combined together, and some work-elements should be sequenced one by one. This step is necessary with the concern of the complexity level of the task and development. It makes global analysis and management much easier. Moreover, while taking advantages of WSBA, we do not want to put 58 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. unnecessary overhead to designers. So, it is intelligent software agents’ responsibility to perform this step. This requires certain mechanisms and algorithms to be implemented in these agents. Overall, for each activity, the responsible designer is in charge of step 2-1 and step 2-2, and an intelligent software agent assigned to that activity is in charge of step 2-3. By involving agents in work-element elaboration, a significant amount of overhead can be saved for designers so that they can concentrate on value-adding work that demands creativity and innovation. The knowledge the designers should master is specific domain knowledge for generating work-elements and defining work-element dependencies. And the knowledge the agents should master is specific work-element mechanisms for refining local work-elements and their relationships. Major step - Step 3: Work-Net configuration After work-elements are elaborated in all activities, the manager, the management system, along with the agents should work together to configure a work-net. A work-net is an engineering network for design, specification, generation, simulation, and adaptation of engineering processes. It includes the information and relationships at both activity level and work-element level. This work-net configuration step has two sub-steps. Step 3-1: Collecting work-element information When the work-elements elaboration is finished in each activity, the agent of that activity should report the detailed work-element information and the dependencies to the management system. The management system itself is a server- 59 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. client distributed system where the server is located in an enterprise’s workstation, and multiple clients are located in designers’ sites. The server should provide services such as database maintenance, people administration, resource tracking, communication establishment, and for this step, collecting all the work-element information reports and maintaining them as structured data. Step 3-2: Constructing the work-net After every agent has provided the work-element information report, the management system and the manager will do the work-net construction. For each project, there is only one work-net which is a directed graph that consists of two primary types of nodes: activity nodes and filter nodes. The activity nodes contain work-element information in each activity, and filter nodes encapsulate work- element dependencies. The major construction work should be done by the management system in which certain algorithms are implemented. Overall, multiple agents and the management system should work together to perform 3-1, and the project manager and the management system should work together to perform step 3-2. The knowledge each role actor should master is: agents should understand the communication mechanism implemented by a specific agent language, the management system should be able to manipulate certain work-net algorithms, and the manager should know how to operate the system. Major step - Step 4: Active-Process collaboration and adaptation The work-net itself is not an engineering process. However, it contains all possible engineering processes represented by the execution orders of work-elements 60 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. in all activities. This nature of work-net implies two things: 1) it endows designers with authority to make certain lower level managerial decisions, which is important because designers are the ones who master concrete engineering knowledge and know where the opportunities for achieving efficiency exist; 2) it makes process adaptation and evolution possible. When changes happen, the optimal process defined at an earlier time ft becomes out-of-date, and a new optimal process should be generated at a later time t2 . Both optimal processes at ft and t2 are derived from the work-net and can be actively determined by designers and the manager. The process or processes, which dynamically evolves over time and is actively determined through a coadjutant effort of designers and the manager, is called active- process. The active-process collaboration and adaptation step has four sub-steps. Step 4-1: Generating possible processes After the configuration of the work-net, the management system should generate all possible processes from the work-net. Certain algorithms, basically, permutation algorithm and combination algorithm for generating processes, should be provided. Although the computer calculation cost for executing these algorithms changes due to the level of complexity of the work-net and sometimes the cost is big, the work-element information provided in step 2-3 and step 3-1 already includes feasible local procedures, which dramatically saves the calculation cost in this step. Step 4-2: Selecting the optimal process After all possible processes are generated, the manager should run analyses and simulations on them. The results should be sorted by different categories, such 61 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. as duration, dollar cost, and interaction load. Based on the manager’s criteria, he or she can select one or multiple processes and put them on a whiteboard for designers to discuss. Each designer can talk with each other, state his or her opinion and preference on the related part of selected processes, and provide usable suggestions to improve them. Although the manager has the final call in making decision, the execution process should be commonly agreed by all participating designers. Step 4-3: executing the selected process After the execution process is determined by the manager and designers, it should be executed by the design team. Designers, along with agents, will use this process to guide their work and coordination. Designers and agents have different responsibilities in the execution. Designers’ major responsibility is to carry out the design work on time and make important coordination decisions. In contrast, agents have heavy responsibility in exchanging design information, providing extensive reminders to designers, monitoring and propagating design events, providing and ranking options for certain decision situations, and possibly, bringing relevant engineering knowledge to designers when needed. Step 4-4: adapting the execution process The most important reason that active-process is so-called, and also one of its most important features, is that the process should always adapt to the current situation when technological changes happen and design exceptions occur. That is, during the execution of the active-process which is determined at time ti, if something happens at a time tz such that the current active-process does not fit any 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. more, then the process should be adapted and modified. In this case, step 4-1 through step 4-3 should be performed again. Thus, all these four sub-steps form a loop for actively updating the process based on the current situation. Overall, the manager, the management system, the designers, and the agents should work together closely to perform this active-process based collaboration and adaptation step or loop. The knowledge and technology each role actor should master are: manager should have good coordination and decision-making skill; the management system should be implemented with the algorithms for generating and evaluating the processes; designers should grasp scientific and engineering fundamentals and domain knowledge for real design work; and the agents should have variant functionalities in communicating, reminding, monitoring, and reasoning. Additional step - Step 5: Work-Net Adaptation Besides the above four major steps, there is one more important additional step in WSBA. The work-net, constructed in step 3, is not always fixed. When product requirements are changed during process execution, e.g., new features suddenly are required to be added into the product, the work-net should be modified and its configuration will be changed. This step has three sub-steps. Step 5-1: Modifying related activities There are four possible cases for a work-net adaptation: 1) when a new feature or a new requirement is added into a product, one or more new activities should be added into the work-net; 2 ) when some activity work is not required, one or more 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. existing activities should be removed from the work-net; 3) under slack-driven situation which is described in section 3.2.2, multiple activities should be combined into one activity to save resources for other use; and 4) under strain-driven situation which is also described in section 3.2.2, one activity should be divided to multiple activities to allocate more resources. In every case, the work-elements and their dependencies in the related activities should be modified. Step 5-2: Adapting the work-net This step is similar to the work-net configuration step. First, the agents o f all activities, including both the related and unrelated activities, should report or re report the detailed work-element information to the management system. Then, the management system and the manager should update the work-net configuration for the changes by manipulating the activities nodes and filter nodes. Thus, the old work-net is adapted to a new work-net. Step 5-3: Resuming the active-process Based on the new work-net configured in step 5-2, the active-process collaboration and adaptation step should be performed again. New possible processes will be generated, analyzed and simulated, and a new active-process will be selected, executed, and adapted by the design team. The project development is resumed. Overall, this additional step and the major step 4 forms a loop for environmental and technological changes. The manager, the management system, the designers, and the agents should work together closely to perform this work-net 64 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. based adaptation step/loop. The knowledge and technology each role actor should master in this step are similar to those in major steps, and certain mechanisms and algorithms should be provided. Above are all four major steps and one additional step involved in WSBA. They are concluded in Figure 3-5. T ask a s sig n e d E n vironm ent c h a n g e d Step 2: W ork-l'lenicnt elaboration Step 2-1: Generating initial work-elements Step 2-2: Defining work-elem ent dependencies Step 2-3: Refining work-elements and relations Step 3: W ork-N et configuration s te p 3-1: Collecting work-elem ent inform ation Step 3-2: Constructing the work-net___________ Step 1: Task tlccinn position I Step 5: W ork-N et Adaptation Step 1-1: Generating m ultiple activities Step 5-1: M odifying related activities Step 1-2: Associating with the product model Step 5-2: Adapting the work-net Step 1-3: A ssigning activities to designers Step 5-3: Resuming the active-process Step 4: Active-Process collaboration anti idaptation Step 4-1: Generating possible processes Step 4-2: Selecting the optimal process Step 4-3: executing the selected process Step 4-4: adapting the execution process Figure 3-5: The steps of WSBA 3.3.4 The Benefits and Challenges The proposed Work Structure Based Approach for collaborative engineering design has following three major benefits. 65 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. First, it provides a more efficient product development through coordination. This is because it endows designers with authority to make certain managerial decisions. Although project managers can make overall control of a product development, it is the designers who master concrete engineering knowledge and know how their work are related to others and where the opportunities for concurrent engineering exist. In WSBA, the participating designers are encouraged to coordinate with each other under the supervision of the project manager. Through the coordination, the designers can find out the maximum opportunities of concurrent engineering and their decisions are highly recognized and acknowledged for global decision-making. Second, it provides process adaptation for technological change. With the introduction of work-net, WSBA does not specify any static process but a complete setting of work and their relations. The execution process, i.e., active-process, is derived from the work-net and is a function of time t. It is dynamic and always prone to change when technological change happens during the process execution. Even for the same work-net configuration, under different situations the execution active-process can be totally different. Third, it provides work-net adaptation for environmental change. Today’s industry enterprises must deal with global competition, which requires rapidly development of new models and products for environmental change. Some major manufacturing companies have already been able to produce different products on the same flexible manufacturing line with slight adjustment. In WSBA, work-net 66 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. has similar functions as the flexible manufacturing line. It can generate new processes for new products by changing its configuration, integrating more design activities, and modifying existing activities. In order to take these advantages, WSBA has to meet following challenges. First, it requires a new process model which can link with product details, identify engineering work and their dependencies, and develop active-process. In most existing process models, the unit of analysis and operation is activity. They cannot provide adequate support for engineering collaboration, because low level work-element dependencies, other than activity precedence relationships, cannot be captured by these models. We will address this issue in chapter 4. Second, it requires a set of reliable mechanisms and algorithms for going through the five steps. Reviewing the four major steps and one additional step involved in WSBA, at least three groups of mechanisms and algorithms are required: work-element elaboration mechanisms in step 2 , work-net configuration and adaptation algorithms in step 3 and step 5, and active-process collaboration and adaptation algorithms in step 4. We will address this issue in chapter 5. Third, it requires software systems and intelligent tools to support coordination. WSBA requires a lot of coordination among the manager and designers, which introduces heavy information overhead. However, we do not want to put this overhead onto human beings. We still want the engineering designers and the project manager to concentrate on value-adding work that demands creativity and innovation. In order to do this, system software and tools, i.e., a server-client 67 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. management system and distributed intelligent agents, should be developed to support the manager and designers. We will address this issue in chapter 6 . 3.4 Summary In this chapter, we presented our new approach, Work Structure Based Approach, developed for more efficient and effective collaborative design. First, we stated the requirements for a conceptual framework and introduced our research vision, a process driven work paradigm for supporting collaborative engineering design at three levels, i.e., engineering level collaboration, project level adaptation, and enterprise level learning. Then, we provided a view of current practice and pointed out its problems. After that, we formally introduced the proposed WSBA, which uses a work structure for a specific task to drives the effectiveness and efficiency from both sides of engineering details and management technologies. We introduced three important concepts, i.e., work-element, work-net, and active- process. We also formalized four major steps and one additional step to go through WSBA, i.e., task decomposition, work-element elaboration, work-net configuration, active-process collaboration and adaptation, and work-net adaptation. Finally, we concluded the benefits and technological gaps that should be filled for WSBA. In the next chapter, we will develop an Active Work and Process Model as the fundamental technology of WSBA. 68 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4 An Active Work and Process Model for WSBA 4.1 Introduction In the last chapter, we introduced our Work Structure Based Approach to collaborative engineering design. So far, we have presented the overall view of this approach, and formalized five formal steps involved in it. This systematic approach requires a new process model to clarify the information and operations described in Figure 3-4 and Figure 3-5 so that the supporting mechanisms and algorithms can be developed. For this purpose, in this chapter, we introduce our formal process model, called Active Work and Process Model (AWPM). Mainly, we will present the concepts and definitions o f AWPM. Some o f the important concepts, i.e., activity, work-element, work-net, and active-process, have been curtly introduced in chapter 3, and others will be newly introduced in this chapter, i.e., operation, action, object, parameter, filter, dependency-element, link, and working-procedure. Here we will present their formal definitions. Among these twelve concepts, active-process and working-procedure are used to model the “process” in Figure 3-3, and the others are used to model the “work” and the “work structure”. This chapter provides fundamental concepts and notations for WSBA. Based on these concepts and notations, in the next chapter we will illustrate how to use them to solve collaborative engineering problems. 69 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.2 Concepts and Definitions of AWPM The Active Work and Process Model is constituted by two parts. The first part is a “work” model, which is used to provide links to specific product information, identify engineering work and capture the dependencies. The second part is a “process” model, which is used to represent and develop dynamic processes. 4.2.1 The Part of “Work” Model The concepts in this part of AWPM include work-net, activity, work-element, operation, action, object, parameter, filter, dependency-element, and link. Definition 1: Work-Net A work-net is denoted by WN and defined as: WN(t) = {A,F,L',t} (4.1) Where: A = {ai, a2 , a3 , ... am } is a finite set of activities to describe engineering sub tasks, F = {fi, f2 , f?, ... f„} is a finite set of filters to capture engineering dependencies among activities, and L c (A x F) u (F x A) is a finite set of links connecting activities and filters together to form the complete setting of engineering work. The graph view of a work-net is shown in Figure 4-1. It is a network configuration for design, specification, generation, simulation, and adaptation of engineering work and processes. It is a directed graph that consists of two primary 70 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. types of nodes: activities and filters, represented by circles and bars, respectively. Unilateral arrowhead arcs link either an activity to a filter, or a filter to an activity. An activity, by its definition given below, is an engineering task assigned to a single responsible designer. And a filter, by its definition given below, is a container encapsulating engineering dependencies among activities. Legend: a ) A ctivity Figure 4-1: A simple work-net illustration The appearance of time “t” in equation (4.1) indicates the improvement and adaptation feature of a work-net. First, in practical large-scale design projects, it is hard to obtain complete information of engineering work and their dependencies at the beginning phase of a product development lifecycle. The work-net has less information at the beginning but it becomes more and more concrete as long as more information is provided by participating designers gradually. And second, for the frequent changes of market needs and customer satisfactions, when the product model and the task requirement change, the work-net should be modified accordingly. To deal with the issues of the incompleteness and mutability, a work- net should always evolve over time when more detailed engineering information and new requirements become available. 71 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In the remainder of this dissertation, we use the following notations: °f: the set of input activities of filter f, i.e., the set of activities such that (a,f)eL; f°: the set of output activities of filter f, i.e., the set of activities such that (f,a)eL; °a: the set of input filters of activity a, i.e., the set of filters such that (f,a)eL; a0: the set of output filters of activity a, i.e., the set of filters such that (a,f)eL; Definition 2: Activity An activity is denoted by a, and defined as: ai ={WEi,Pi,P INi,P 0UTi} (4.2) Where: WEj = {wej-i, wej.2, wej.3, ... we,.i} is a finite set of work-elements, Pi is a finite set of parameters produced by activity as, P INj is a finite set of parameters needed as input by activity a; to produce Pi, and P 0UTi is a finite set of parameters required by and delivered to activities a ^ i,... where j, k, 1 # i. The definitions of work-element and parameter will be given shortly. In equation (4.2), P; is engineering knowledge which should be fed into the management system by the project manager, and P1 ^ is engineering knowledge which should be fed into the system by designers. The combination of Pi and P INi are used for constructing a work-net. P0UTj is not required from anyone because the management system can derive it from Pi and P IN j where j ^ i. 72 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Definition 3: Work-Element A work-element denoted by wej.j is a piece of specifiable engineering work of performing operation o on object b: we^j ={oi_j ,bi_j} (4.3) Where: O j.j is the work-element operation, and bi-j is the work-element object. Work-element is the key concept we introduced in AWPM to clearly define engineering work and link a product model to AWPM, where the b part of equation (4.3) identifies the “work” in the product model and the o part specifies the “working” in the process model. This allows us to provide engineering work and coordination support in a project managerial context. The relationship between activity and work-element is illustrated in Figure 4-2. It can be seen that concurrent engineering between sequential activities can be achieved if we can clearly define work-elements and manage their execution procedures. That is, a successor activity does not need to wait until its predecessor activity is fully completed, instead, it can start as soon as those relevant work-elements in its predecessor are finished. Moreover, by viewing work-element as the fundamental unit of both engineering work and project management, we can develop means to clearly monitor activity status during the execution, which provides more detailed and accurate information for process analysis and adaptation. 73 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. > Activity-2 Activity-1 Activity-3 Legend: o □ W ork-elem ent level engineering d ep e n d en c y Activity level p re c e d e n c e relation W ork-elem ent Activity Figure 4-2: Activities and work-elements Definition 4: Operation An operation in equation (4.3) denoted by O i_ j is defined as: (4.4) Where: Cj.j = {ci, C 2 , C 3, ... cm} is a finite set of actions taken on object b to generate expected results, and 6i = [Ci-j] is the sequence of Cj.j based on their underlying reasons. Some of these reasons are logical, i.e., depending on physical structure of objects; some are technical, i.e., depending on the choice of technical methods; and others are optional, i.e., depending on the priority of requests from other activities. Engineering designers should do reasoning for 0 j and feed it into the management system. Definition 5: Action An action c is a notable effect on the object b to produce one or multiple parameters in Pj, such as build, paint, draw, order, and so on. Definition 6: Object An object in equation (4.3) denoted by bj.j is defined as: 74 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7_____ __ ( jy in - e x jy in -e n jy o u t- e x jy o u t- e n \ / a c\ Oi_j — \i i-j, r /- /, r i-j, r /- / / Where: Pin = {pi, P2 , ... Pm} is the set of input parameters which are required for performing an action, Pout = {pi, p2, ... pn} is the set of output parameters which are produced by performing an action, Pex = {pi, p2 , ... pp} is the set of exogenous parameters which are received from or delivered to a work-element in a different activity at where k ^ i, and Pen = {pi, p2 , ... pq} is the set of endogenous parameters which are received from or delivered to the same activity aj. In this dissertation, we denote capital P as a set of parameters which has the same features, and lowercase p as a single parameter. Meanwhile, we denote capital EX and EN as the exogenous and endogenous parameter(s) o f activities, and lowercase ex and en as the exogenous and endogenous parameters(s) o f work- elements. Here it can be seen that the concept of object in AWPM is associated with a specific activity by exogenous and endogenous parameters, which is different to the normal object concept in a product model. The engineering actions performed on the endogenous parameters can be conducted locally at any proper time without affecting the work in other activities, while the engineering actions performed on the exogenous parameters have inevitable impact on other activities. In this sense, exogenous parameters are more important than endogenous parameters because they 75 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interconnect activities together so that the overall engineering work in all activities can be structured for further operations. Definition 7: Parameter A parameter p is a piece of specifiable product information which can be transferred between two design objects in the same activity or across different activities. It is the bridge to connect a product model to AWPM. Any parameter, such as length, height, radium, model, type, power, etc, of a part or a component in a product model can be a parameter in AWPM. Definition 8: Filter A Filter denoted by fij encapsulates engineering dependencies between two activities a; and ap fy={DEv} (4.6) Where: Fy e a ° v °aj, and DEjj = {dey-n-i, dey-12- 2 , deij_ 2 i-3 ,-- - dey.p q .k} is a finite set of dependency- elements which indicate work-element level engineering dependencies between the work-elements in aj and the work-elements in aj. Definition 9: Dependency-Element A dependency-element denoted by dejj.p q .k is defined as: d e 0 - P 9 - k = (w e i - p w e j - ‘ i ) (4-7) Where: 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. wej.p e W Ej, wej.q e W Ej, and pk g P out‘exi.p n P in'ex j.q. Definition 10: Link A link connects an activity to a filter or a filter to an activity. There are two kinds of links, output from activity link and input to activity link. An output from activity link denoted by l°(ai, fy) is defined as: l°i.ai, f iJ) = {px,p 2,p ^...p k} (4.8) Where: Pk e P°U T i- An input to activity link denoted by l'(fij, aj) is defined as: I' ifij ,aj ) = {pl,p 2,p 3,.. .pk} (4.9) Where: Pk 6 P ^j. So far, from definition 1 to definition 10, we defined engineering work and captured their dependencies. An illustration of this part o f “work” model in AWPM is shown in Figure 4-3. However, a work-net itself is not a process itself for guiding product development directly. Engineering processes must be derived and developed from the work-net for practical use. 77 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Legend: 0 Activity D F ilter P ^ Link W o rk - E le m e n t t K i X D D e p e n d e n c y - In p u t O u tp u t E le m e n t w e w e Figure 4-3: An illustration for the “work” model 4.2.2 The Part of “Process” Model The concepts in this part of AWPM include active-process and working- procedure. Definition 11: Active-Process An active-process is denoted by AP and defined as: AP(t) = {WP;t} (4.10) Where: WP = {wpi, wp2 , wp3, ... wpm} is a finite set of working-procedures. Definition 12: Working-Procedure A working-procedure is denoted by wp and defined as: W P, = WEj,aj} (4.11) Where: WEj = {wej.i, we,.2 , wej_3 , ... wej.i} is the set of work-elements which has been defined in activity a,, and 78 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. cjj = [WEj] is the working sequence which specifies the execution order of work-elements in activity a;. The above two concepts are used to define the engineering processes for practical use. As a simple example shown in Figure 4-4, an active-process is composed by the combination of the working-procedures of all activities. The working-procedure in each activity defines the execution order of work-elements in that activity. The determination of working-procedure is based on their underlying reasons (logically and technically) and the responsible designer’s preference. I (a) ac tiv e -p ro c e ss^ ) \ w e 2 w e ,'' (c y m m ) ' w e . - r w e , w e , / \ w e . w e. w e . / " a : (b) ac tiv e -p ro c ess^ ) Legend: o Activity □ W ork-Elem ent — Internal w ork-elem ent working se q u e n c e ------ ► External work-elem ent working se q u e n c e Figure 4-4: Active-Process and working-procedures The working-procedure in each activity is not fixed. The designer has the authority to decide it, and it is always prone to change. This feature makes a process adapt to changes when exceptions occur, or more efficient collaboration is possible based on designer’s engineering knowledge and observations. Thus, an active- process, which is the practical engineering process defined to guide the development, 79 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. is a function of time t which appears in equation (4.10). As an example, Figure 4- 4(a) represents the active-process at a time being ti, i.e., active-process(ti) = {(ai.wei— » ai.we2 -» ai.we3), (a2 .wei— » • a2 .we2-» a2 .we3), (a3.wei-> a3.we2— » a3.we3)}. Then, because new situations happen at time t2 , the working-procedures in the activities are changed by the designers. Figure 4-4(b) represents the active-process at time being t2 , i.e., active-process(t2) = {(ai.we2 — » ai.wei— > ai.we3), (a2 .we3— > a2 .we2 -> a2 .wei), ( a 3 . w e i —> a 3 . w e 3 — > • a 3 . w e 2 ) } . So far, we introduce definition 11 and definition 12 to define practical engineering processes which can be used to guide the product development directly, and show its adaptation feature which is important for dealing with changes. 4.3 Summary In this chapter, we presented a general process model for WSBA, called Active Work and Process Model. AWPM is formed by two parts. The first part is an engineering “work” model which is used to define engineering work in details and capture low level dependencies. The second part is an engineering “process” model which is used to guide engineering work and coordination directly. We have introduced twelve concepts in AWPM and provided their definitions. These concepts are: work-net, activity, work-element, operation, action, object, parameter, 80 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. filter, dependency-element, link, active-process, and working-procedure. As a summary, these concepts are layered in Figure 4-5. Activity W ork-Net Link Filter P aram eter Action W ork-Elem ent A ctive-Process Obiect O peration D ependency-E lem ent W orking-Procedure Active W ork and P ro c ess Model Figure 4-5: Layered Active Work & Process Model Among these concepts, work-element, work-net, and active-process are the key concepts we introduced in AWPM. Work-Element is used to clearly define the local engineering work in each activity. It also links AWPM with specific product information, where the b part of a work-element identifies the “work” in the product model and the o part specifies the “working” in the process model. This allows us to provide engineering work and coordination support in a managerial context, which creates great opportunities for concurrent engineering. Work-Net is used to clearly define the global engineering work in the whole project. It represents the detailed information of work-elements in all activities, and captures their dependencies using a network configuration. Based on work-net, engineering processes, whose basic representative unit is work-element, are derived and analyzed, and then the optimal 81 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. active-process is determined for execution. Furthermore, both work-net and active- process have a very important feature, adaptability, for environmental changes and technological changes, respectively. This chapter provided fundamental concepts and notations for the next chapter. In the next chapter, we will show how to use these concepts and notations for further development of the proposed Work Structure Based Approach described in chapter 3, i.e., how to perform work-element elaboration, work-net configuration and adaptation, and active-process collaboration and adaptation. 82 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5 The Development of WSBA 5.1 Introduction As stated in chapter 3, the proposed Work Structure Based Approach requires a set of mechanisms and algorithms for completing the five steps in a product development lifecycle. Recalling the four major roles categorized in section 3.3.3, i.e., the project manager, multiple engineering designers, the management system, and multiple software intelligent agents, some of these mechanisms and algorithms should be implemented in the management system and agents, others should be used as the guidance for human participants. In the last chapter, we presented an Active Work and Process Model for WSBA, which is composed of twelve concepts concluded in Figure 4-5. This model, on one hand, provides formal representation for engineering work and process, and on the other hand, provides primary elements and notations for developing mechanisms and algorithms required by WSBA. The development of these mechanisms and algorithms is the focus in this chapter. First, we will discuss a hypothetical collaborative engineering design problem, Building Blocks (BB). Then, in order to solve this BB problem, we will show how mechanisms and algorithms in different phases of WSBA can be developed. These mechanisms and algorithms fall into three categories. These categories are: work-element elaboration, work-net configuration and adaptation, and active-process collaboration and adaptation. We will develop six operations for 83 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. work-element elaboration, namely, WE-Splitb, WE-Split°, WE-Seq°, WE-Seqb, WE- Merg0, and WE-Mergb. We will develop five algorithms for work-net configuration and adaptation, namely, WN-Constructing, WN-ActivityAdding, WN- ActivityRemoving, WN-ActivityCombining, and WN-ActivityDividing. And we will develop two algorithms for active-process collaboration and adaptation, namely, AP-Generating and AP-CriticalPathFinding. We will show the details o f how we can use them to solve the Building Blocks problem. 5.2 Case Study: Building Blocks In this section we introduce a hypothetical collaborative design problem, Building Blocks. This example on one hand is simple and easy to understand, on the other hand has rich features that present a class of real world collaborative design problems such as layout design, structure design, and so on. As shown in Figure 5-1, the overall task of this problem is to build 36, 6 by 6 , blocks within a given time. Each block b y should be first constructed in different materials, i.e., glass, aluminum, and steel, then painted in different colors, i.e., red, blue, green, and yellow, and finally positioned from bottom up. Constructing a block of a specific material and painting it with a specific color will require corresponding machines, take certain time, and spend certain dollar cost to finish. Screws are used to connect upper layer blocks b y with lower layer blocks b j . i j . The 36 blocks are shown in Figure 5-l(a), and the parameters of each block are shown in Figure 5-l(b). The resources and the costs for using them are summarized in Table 5-1. 84 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. b 61 b 62 b 63 b 64 b 65 b 66 b 5i b sd b 53 b 54 b 55 b 56 b 41 b 42 b 43 b 44 b 45 b 46 b 31 b 32 b 33 b 34 b 35 b 36 b 21 f c > 22 b 23 b 2, b 25 b 26 t>11 b 12 b 13 b 14 b 19 b 16 1 2 3 4 5 6 (a) overall task V Screw position p2 X Color c Material m \ Screw position p1 (b) parameters of each block Figure 5-1: Building Blocks case example Table 5-1: Resources for Building Blocks Resource Block Time (Day) Cost (K$) Constructing machine Glass machine Glass block 4 2 Aluminum machine Aluminum block 3 3 Steel machine Steel block 2 4 Painting machine Red machine Red block 4 1 Blue machine Blue block 3 2 Green machine Green block 2 3 Yellow machine Yellow block 1 4 Because the project has to be finished in a limited period of time, a project team is formed by a project manager and multiple engineers. We assume that the manager has general project management knowledge and minimum product knowledge, i.e., task assignment, resource allocation, profit measurement, and so on, however he or she does not have concrete engineering knowledge about how the building work is really carried out. We also assume each designer has the same value system for selecting goals and has the same domains of interests, capabilities and expertise. We further assume that people in the project team can communicate 85 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. with each other over a reliable communication network through which they can exchange information without loss. To accomplish this task, we assume the project manager decomposes the overall task into eight activities which are shown in Figure 5-2. We further defined two types of constraints involved in this example, namely, base-ready constraint and color-match constraint. Base-ready constraint requires that any upper layer block b y cannot be put on unless the lower layer block b j _ i y has been positioned, and the screw position pi of b y must equal to screw position p2 o f b j . i j . However, before b j . i j is positioned the construction and paint o f b y can start. Color- match constraint requires that the horizontally neighboring blocks on activity interface should obey certain rules, e.g., they cannot be in the same color. That is, if the color o f b2 2 in activity a3 is painted to red, then the color of b2 3 in activity ai can be any color but red. This color-match constraint is only required for blocks in activity interface, such as bi3-bi4, b2 3-b2 4 , etc, while two neighboring blocks in the same activity are not required to comply with this constraint, such as bn-bi2 , bi4 -bi5, etc. The complexity of the color-match rules can vary. Instead of “they cannot be in Figure 5-2: Activities involved in Building Blocks 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the same color” which will be applied as the color-match rule in the remainder o f this dissertation, here is another more restricted example: color(by) = red, if .color (bj(hl)) = (green \ yellow) & color (bi(j+l)) = (blue \ green) blue, if .color (bi(j_V )) = (yellow \ red) & color {bi(J+ X )) = (green \ yellow) green, if .color (bj(j_{)) = (red \ blue) & color{biU+l)) = {yellow \ red) yellow, if .color (bj{j_V ) ) = {blue \ green) & color{bi(j+l)) = {red \ blue) So far in this Building Blocks example, the product and constraints have been defined. While Figure 5-1 illustrates the engineering tasks involved in this example, the eight activities in Figure 5-2 can be organized in different ways. Before we show how we can provide WSBA solutions, as a comparison, we first develop a CPM (Critical Path Method) diagram using the traditional workflow approach, which is shown in Figure 5-3. End Figure 5-3: CPM chart for Building Blocks In CPM, every successor activity cannot start until its predecessor activity has been fully finished. For the example in Figure 5-3, it can be seen that at project level activity as can start only after activity a\ has been finished. However, at engineering level as long as block bn in aj is finished, bsi in as can actually be built because its supporting block bn is already there, as shown in Figure 5-1. Thus, as we stated in 87 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. chapter 3 that the workflow solution provided in Figure 5-3 is not sufficient, WSBA provides a much better solution for not only the efficiency and effectiveness, but also the adaptability and flexibility for product and process development. In order to make WSBA real and practical, we must address three key issues in the following: work-element elaboration, work-net configuration and adaptation, active-process collaboration and adaptation, as discussed in chapter 3. 5.3 Work-Element Operations The development of WSBA is focused on how to support routine or semi routine large-scale design projects, i.e., a rough product model for a specific project should be available beforehand. Thus, we can assume that when a responsible designer accepts an activity assignment, he or she can figure out the inputs required to proceed the design activity and the outputs delivered after the finishing o f the design activity. However, upon the acceptance of an activity assignment, the work inside the activity is a black box which absorbs inputs and releases outputs, nobody clearly knows what is going on inside and what is related to outside, and without further elaboration on the work, the black box cannot be self-unclosed. Our opinion is that not every piece of engineering work done by others is related to a specific activity, and not every piece of engineering work done by a specific activity is related to others. If there is a “wall” (activity interface) between any two “rooms” (activities), only a limited number of “windows” (low level engineering dependencies) should be opened for circulating air (exchanging design information) 88 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and balancing the pressure (maintaining design consistency). Dealing with these numbered “windows” is certainly more efficient and effective than handling the whole “wall”. In order to unclose the black box and open the necessary “windows”, the engineering work inside an activity needs further elaboration, i.e., the entire activity work should be broken into work-elements, then these work-elements should be correctly linked with each other, and feasible work-procedures for carrying out these work-elements should be generated. The operations for work-element elaboration presented in this section are developed right for this purpose. As we have already seen in last chapter, a work-element is defined to include two parts of design information, where the “b” part identifies the “work” in the product model and the “o” part specifies the “working” in the process model. Both of these two parts will be elaborated by six operations. These operations, namely, object-based splitting WE-Splitb , operation-based splitting WE-Split°, operation-based sequencing WE- Seq°, object-based sequencing WE-Seqb , operation-based merging WE-Merg°, and I* object-based merging WE-Merg , are needed for decomposing an activity to multiple work-elements, defining the input and output parameters for each work-element, and determining the working sequence of the work-element execution by underlying reasons. For each operation we will provide an example related to activity a3 of the Building Blocks problem described in the last section. 89 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.3.1 The Starting Point: Initial Work-Element The starting point of work-element operations is the initial work-element weo. As an example shown in Figure 5-4, the whole task in activity a3 can be viewed as a single work-element: we0 = {o, b} = {build, block2i + block22 + block3i + block32 + blocks} — {{C 0 } { P ‘n"ex p ' n_en p o u t-ex p o u t - e r i || = {{(construct, paint, position), [construct -» paint -> position]}, {(bn.p2, bi2.p25 b23.c, b33.c, b4i.c, b43.c), 0 , (b22.c, b32.c, b42.c/p2, b3i.p2>, (b21.p1/p2/c/m, b22.p1/p2/m, b31.p1/c/m, b32.p1/p2/m, b42.pi/m)}} Where: is a separator where the part before it is a physical product object and the part after it is a specific parameter of that product object; “/” is a conjunction which means “and”; and “0 ” is an empty set. w e. Pj/c/r Legend: ( 3 ) Activity □ W ork-E lem ent E x o g en o u s p a ra m e te r p,x E n d o g en o u s p a ra m e te r p ,n Figure 5-4: The initial work-element of activity a3 90 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.3.2 Operation 1: Object-based Splitting WE-Splitb This operation splits the object part b of the work-element weo into multiple objects: WE - Splitb(we0 : we, + we2 + ... + we,.) (5.1) Where: ( 1 . 1 r „ r n i n - e x r j i n - e n r > o u t - e x T j o u t - e n i i . we0 = {o, b} = {o, {P o, p o, p o, p oil; r „ u i _ m i n - e x n i n - e n r j o u t - e x r j o u t - e n 1 1 . wei = {o,bi} = {o, {P 1 , P 1 , P 1 , P ill, ( i i _ f n i n - e x r j i n - e n n o u t - c x T j o u t - e n i i wej = {o, bj} - {o, {P j,P j,P j,P j}}. And: bh b2, ... bj e (b); P i n - e x , . T j i n - e x , , , . T > i n - e x _ r j i n - e x . l U r 2 ^ . . . ’ ^’^ j — “ o, Pin -en! U P in 'e n 2 u ... u P in 'e n j = Pin 'e n 0; P o u t - e x , , T > o u t - e x . . . . T j o u t - e x _ T > o u t - e x . l U r 2 ^ •••'->’P j — P o, P o u t - e n . . T j o u t - e n , , , . r » o u t - e n _ T j o u t - e n l U r 2 ^ ^ P j - P 0 - For example, the initial work-element weo in Figure 5-4 can be split into five work-elements as shown in Figure 5-5, i.e.: WE-Splitb (weo : wei + we2 + we3 + we4 + we5 ) Where wei = {build, block2i} = {build, {bn.p2, 0 , 0 , b21.p1/p2/c/m}} we2 = {build, block2 2} = {build, {(bn.p2, b23.c), 0 , b2 2.c, b22.p1/p2/m}} Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. we3 = {build, block3i} = {build, { 0 , b2i.p2, b3i.p2, b3i.pi/c/m}} we4 = {build, block32} = {build, {b33.c, b2 2-P2, b32.c, b32.pi/p2/m}} we5 = {build, block42} = {build, {(b4i.c, b43.c), b32.p2, b42.c/p2, b4 2.pi/m}} b3 2 -Pi/ b3 2 -C P,2-Pl^ P3 2'P; Pj/m ->a5 m ->a6 we2 we. we3 we, Legend: W ork-Elem ent Exogenous param eter pex E ndogenous param eter p“ Activity Figure 5-5: Object-based work-element splitting WE-Splitb 5.3.3 Operation 2: Operation-based Splitting WE-Split° This operation splits the operation part o of a work-element weo into multiple actions: WE - Split0(we0 : we, + we2 +... + wej) (5.2) Where: _ r „ l ) _ r / „ „ fT>in-ex r>in-en r>out-ex T,out-en ^ . we0 = {o, b} = {(ci, c2, ... cj), {P o, P o, P o, P o}}; wei = {oi, bi} = {ci, {Pin 'exi, Pin ‘eni, Po u t-exi, Po u t'en,}}; wej = {oj, bj} = { q , {Pin’exj, P in-en j, P out-ex j, P out'en j}}. And: c i,c 2, ... cj e (o); P in-ex , , ryin-ex , . . . T>in-ex _ T>in-ex . l U r 2 ^ • • • LJ r j —r o, P in-en , , Tjin-en , , , , rjin-en _ T>in-en , l U r 2 ^ • • • LJ r j —r q, 92 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P out-ex Tjout-ex 1 ^ “ 2 . . . . rjout-ex _ Tjout-ex . U . . . U r j — r 0 ? Pout-en . . T jout-en . . . . r> out-en _ T jout-en l ^ r 2 ^ v j — r o - For example, each of the five work-elements in Figure 5-5 can be split into three work-elements as shown in Figure 5-6, i.e.: WE-Split°(wei : wen + wen + wen) Where: wei = {o, b} = {build, block2 2} = {(construct, paint, position), {(bi2 .p2, b2 3.c), 0 , b2 2 -c, (b2 2.p1, b2 2 -P 2, b22.m)}} w en = {construct, block2 2} = {construct, { 0 , 0 , 0 , b2 2.n1 }} we 1 2 = {paint, block2 2} = {paint, { 0 , b23.c, b2 2.c, 0 } } w en = {position, block2 2 } = {position, { 0 , bi2.p2, 0 , (b2 2.p1, b2 2 -p2)} we. we. we. we. w e. we. we. we, we. w e 3: we. we. w et we, Legend: ( 3 ) Activity □ W ork-Elem ert E xogenous param eter p8* E ndogenous p aram eter p9 " Figure 5-6: Operation-based work-element splitting WE-Split° 5.3.4 Operation 3: Operation-based Sequencing WE-Seq° This operation orders multiple work-elements based on their underlying reasons and constraints: 93 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. W E -S eq °(w el + we2 +... + wej \ wex——>we2— —2— »we/-) (5.3) Where: wej = {0 1 , b,} = {cb {Pin " e X ,, Pin -en i, P0 U t -e X l, P0 u t’en j}}; wej = {0j, bj} = {C j, {Pin 'e x j, Pin 'e n j, Po u t-e x j, Po u t-e n j}}; — 2 — » is an operator called Operation Sequencing Operator Seq°. And: w eb we2, ... wej are all split from one parent work-element weo = {o, b} = {[ci, C 2 , ... C j], b} where [cb C 2 , ... C j] is the sequence of actions to be taken on b, i.e., Order(ci, c2, ... cj) = [cb c2, ... cj]. For example, the work-elements wen = {construct, block22}, wei2 = {paint, block22}, and wen = {position, block22} in Figure 5-6 should be sequenced by the order [construct, paint, position] as shown in Figure 5-7, i.e.: WE-Seq° (wen + wen + wen : wen — 2 — ► wen — > wen) Legend: Activity □ W ork-Elem ent I E xogenous p aram eter p"* E ndogenous pa ra m e te r p*r O p e rato r seq° Figure 5-7: Operation-based work-element sequencing WE-Seq° 94 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.3.5 Operation 4: Object-based Sequencing WE-Seqb This operation orders multiple work-elements based on their output and input parameters. W E -S eq °(w ex +we2 +... + wej :we1——>we2— —^ — >wej) (5.4) Where: wei = {01, bi} = {ci, {Pin ‘exi, Pin ’en i, Po u t'exi, po u t-e n i}}- wej = {oj, bj} = {cj, {Pin -ex-, Pin 'e n j, P0 u t-e x j, Po u t-e n j}}; , L >: is an operator called Object Sequencing Operator Seq . And: The performing of wej requires a parameter produced by wej.i i.e., 3p peP in 'e n j a pePo u t" e n j.i. L egend: Activity W o rk -E lem en t E x o g e n o u s p a r a m e te r p*K E n d o g e n o u s p a r a m e te r p*" O p e ra to r seq ° O p e ra to r s e q b Figure 5-8: Object-based work-element sequencing WE-Seqb For example, the execution of work-element we3 3 = {position, blocksi} = {position, { 0 , b2 i.p2 , 0 , (b3 1 .p1, b3 i.p2)} in Figure 5-7 should follow the execution of 95 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. work-element wen = {position, block2i} = {position, { 0 , bn.p2, 0 , (b21.p1, b2i-p2)} where b2i-P2 is found in po u t'en 1 3 and Pm " e n 3 3 as shown in Figure 5-8, i.e.: H A WE-Seq (wen + we33: w e n > we33) 5.3.6 Operation 5: Operation-based Merging WE-Merg° This operation merges multiple work-elements whose operation part o is performed on the same object b and the output has no impact on any other work- elements: W E - M e r g ° ( w e l —— > w e2 — — » ...— ^ > w e j :we0) (5.5) Where: wei = {01, bi} = {ci, {Pin 'exi, Pin ‘en i, Po u t-exi, Po u t-en i}}; wej = {oj, bj} = {C j, {Pin -e x j, Pin 'e n j, Po u t-e x j, Po u t-e n j}}; _ « • 1 1 _ r r „ _ - 1 rT->in-ex i-)in-en T->out-ex T>out-en , , we0-{ o , b} - {[ci, c2, ... cj], {P 0, P 0, P 0, P 0}}. And: wei, we2, ... wej are connected by Operator Seq° — 2 — > •; The parameters in po u t'e n 0f {wei, we2, ... wej} cannot be found in Pin 'e n of any other work-elements except {wei, we2, ... wej}, i.e., „ -T joiit-en .rjout-en lT 3out-en „,_ r> in -e n , . 0 • -idppeP iUP 2^-..^P jApeP ka k^l, 2, ... j; P in-ex , , n in -e x . . , . r>in-ex _ n in -e x . l U r 2 ^ ^ r j - r 0, P in-en . . rjin-en . . . , yjin-en _ rjin-en . l U r j ” ^ O j p“ U Po u t-e x 2 u ... U P°U t 'e X j = Po u t'ex 0 = 0 ; 96 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P out-en Tjout-en rjout-en _ Tjout-en 1 v r 2 ^ . . . U r j — r o- For example, wen = {construct, block2i} and we^ = {paint, blocks} in Figure 5-8 can be merged as shown in Figure 5-9, i.e.: WE-Merg° (wen — —» w en : wei 4 ) b ...m /c b «4 b 2 3 - ' | b ,2 ' P { \ w e i 3 j w e 2 1 H w e 2 2 H w e 2 3 J K & \ / b2 1 - P2 b , , . m b ~ , . c - > a . 7 2 2 P1 i b ”- c l . / i w e M | w e 4 ! H w e 4 ? H w e 4 3 J i 1 I \ J J J *>3 , P i b 3 1 ' P 2 b , 2 . m t £ P i j N° i I w e 5 1 H W e 5 2 H w e 5 3 I I I I I / b 4 2 . m b ^ V S J ^ r ' V P j L egend: O Activity n W o rk -E lem en t l E x o g e n o u s 1 p a r a m e te r p,x E n d o g e n o u s 1 p a r a m e te r p*" — O p e ra to r seq ° c" O p e ra to r s e q b Figure 5-9: Operation-based work-element merging WE-Merg° 5.3.7 Operation 6: Object-based Merging WE-Mergb This operation merges multiple work-elements whose object parts b have internal dependencies within the same activity. WE - M ergb (wej — —> we2 — —h —^wej : we0) Where: u l — f n i n - e x r ji n - e n T ^out-ex T ,o u t-e n ^ . wei - {oi, bi} = {ci, {P i, P i, P i, P i}}; (5.6) wej = {oj, bj} = {cj, {Pin-exj, P in-enj, P out-ex j, P out-enj}}; we0 = {o, b} = {[ci, c2, ... cj], {P And: in-ex T jin-en T>out-ex n o u t-en i ■ > 0 , r o, V o//- 97 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. L » wei, we2, ... wej are connected by Operator Seq ------ >; For all downstream work-elements wei, we2 , ... wem connect with wei, we2 , ... wej through Operator Seqb — —>, the parameters in po u t'e n of wei, we2 , ... wem cannot be found in Pin 'en of any other work-elements except wei, we2 , ... wem , i.e., -i3 p p e P 0 u t-eniu P 0 U t-e n 2 u ...u P 0 U t-e n m a p e P in 'en ka k ^ l, 2 ,... m; P in-ex . . rjin-ex . . . , n in -e x _ n in-ex . IvJr 2 ^ ^ * j * 0? P in-en . . n in -e n . . . . r>in-en _ n in -e n . 1 ^ a 2 ^ ^ -T j r o, P out-ex . , r>out-ex . . , , n o u t-ex _ riout-ex . l U r 2 ^ -T j “ " 0? P out-en . . r>out-en . , . . rjout-en _ r^out-en 1 U r 2 ^ ^ * j — r O ’ For example, w en = {position, block2 i} = {position, {bn.p 2 , 0 , 0 , (b2 i. p2, b2i. pi)}} and we3 3 = {position, blocks} = {position, {0 , b2i-P2 , b3i.p2, b3i.pi}} in Figure 5-9 have internal dependency through b2 i.p2, thus, these two work-elements should be merged as shown in Figure 5-10, i.e.; WE-Mergb (wei3 — » we33: wee) w e. w e . w e. w e. w e . w e. b3 2 .c-> as / b3 2 .p ,/p2 b4 2 .p , / j lh / b2 2 p ,/p2 b , / p 2 w e . w e, L e g e n d : o Activity □ Work-Element I Exogenous 1 param eter p*" Endogenous I param eter p*n — > Operator seq° Figure 5-10: Object-based work-element merging WE-Mergb 98 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. After above six work-element operations, the initial work-element of activity a3 in Figure 5-4 is decomposed into ten work-elements in Figure 5-10 with input and output parameters explicitly defined and linked. As the results of work-element operations, these work-elements are the basic units for engineering work, coordination, and management in WSBA. Moreover, They are essential for developing the algorithms of work-net configuration and adaptation. 5.4 Work-Net Algorithms In this section we develop the algorithms for work-net configuration and adaptation. In WSBA, these algorithms are used for constructing a work-net and adapting the work-net for certain situations, i.e., defining engineering work in the whole project, capturing the engineering level dependencies as well as activity level precedence relations, and updating the work-net when environmental changes happen because of market needs and customer satisfactions in the middle of the product development. We will develop five work-net algorithms, namely, WN- Constructing, WN-ActivityAdding, WN-ActivityRemoving, WN- ActivityCombining, and WN-ActivityDividing. For each algorithm we will give out an example related to the Building Blocks problem described in section 5.2. 5.4.1 Constructing A Work-Net: WN-Constructing After finishing the work-element operations in each activity, the associated intelligent agents of these activities should report the elaborated work-element information to the management system. The content of this reported information 99 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. should include detailed local engineering work, i.e., work-element identification, input parameters and out parameters (both endogenous and exogenous ones) of each work-element, operation and object sequencing Seq° and Seqb among work- elements. The local engineering work of each activity should then be connected with each other so that the engineering work of the whole design problem can be formed globally. The configuration of this global engineering work is so-called work-net whose definition has been given in chapter 4. An algorithm for constructing a work- net is provided in Figure 5-11, which generates activities, filters, work-elements, dependency-elements and all other needed work-net elements for describing engineering work contents of a specific design task and capturing engineering dependencies among related activities. Input: An initial activity set A = (aj, a2 , a3 , ... a*}. Output: A work-net = {A, F, L} where the activity set A = {ai, a2 , a3 , ... a*}, the filter set F = {fi, f2, fj, ... fi}, the link set L = {fi, I2 , 13, ... 1 0}, the work-element set WE* for each activity a\, and the dependency-element set DE| for each filter fi. Algorithm: for each activity a, do begin Pi := {pi, P2 , .. .pi} /* define parameters produced by a\ */ {pi, P2 , .. .pm } /* define parameters needed to produce Pj */ end for each activity a\ do begin /* derive parameters delivered to other activities */ p O U T , = 0 for each P^k in activity ak (k^i) do PO U T j := P0U Ti u (Pj n P^k) end for each activity a; do begin WE WE WE WE = {weo} /* create initial workelement */ = WE-Splitb (weo) /* perform WE-Splitb operation on weo */ = WE-Split°(wej) /* perform WE-Split° operation */ = W E -Seq°(w ej) /* perform W E -S eq° operation */ Figure 5-11: Algorithm of WN-Constructing 100 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. WEi := WE-Seqb(wej) /* perform WE-Seqb operation */ WEj := WE-Merg°(wej) /* perform WE-Merg° operation */ WE* := WE-Mergb(wej) /* perform WE-Mergb operation */ end for each activity a, do begin for each activity ai (tei) do begin DEii := 0 for each we; e WE; do begin for each pk e p o u t'e x j do begin for each wem = WE, do begin if pk e Pm -ex m then DE„ := DE„ u {pk} end end end if DE,i * 0 then do begin fn := {DEu} /* create filter from a, to a, */ l°(ai, fi,) := {DE„} /* create link from a, to f„ */ l'(fii, a,) := {DEu} /* create link from f„ to a, */ end end end Figure 5-11: Algorithm of WN-Constructing (Cont.) As an example, the BB problem in Figure 5-2 is given in Figure 5-12(a) again, and Figure 5-12(b) shows its work-net after executing algorithm WN-Constructing. (a) The product model and activities of BB problem (b) The Corresponding work-net Figure 5-12: Constructing a work-net 101 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 5-2 and table 5-3, the activity table and filter table, give out more detailed specifications related to activity a3 in the work-net shown in Figure 5-12(b). Table 5-2: The activity table for BB example Activity Work- element Action p in-ex p in -en r i-j p o u t-ex p o u t-en • •. . . ,., a3 w en construct, paint 0 0 0 b2 i.m, b2 i.c W e34 construct, paint 0 0 0 b3 i.m, b3 i.c we6 position bn.p 2 0 b31-P2 b2 i.p2, b2 1.p1, b3 1.p1 we2i construct 0 0 0 b2 2 .m we22 paint b2 3 -C 0 b2 2.c-»ai 0 we4i construct 0 0 0 b32.m we4 2 paint b33-C 0 b32.c->a5 0 we5i construct 0 0 0 b42.m we52 paint b4i.c, b43.c 0 b42.c->a5, b4 2.c— »a6 0 we7 position bl2-P2 0 b42-P2 b3 2.P1, b3 2 -P 2 , b22.pi, b22-P2, b4 2.Pl Table 5-3: The filter table for BB Example Filter From Activity To Activity Dependency- element Transferred parameter From work- element To work- element . . . . . . . . « . . . f * 3 1 a3 ai dej b2 2-c we2 2 we23 f35 a3 as dei b42.c we52 we43 de2 b32.c W e42 W e33 f36 a3 ae dei b31-P2 we6 we4i de2 b4 2-P2 we? we5 2 de3 b42.c we5 2 W e42 102 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.4.2 Adding An Activity: WN-ActivityAdding At any design phase during the development of a given design project, the product requirements can be changed due to the quick changes of market needs and customer satisfactions. Current industrial approaches cannot deal with this adaptability problem. That is, as long as the conceptual design phase of a specific project is finished, it goes all the way down to embodiment design and detail design, which means it cannot turn back to consider new requirements and add new activities. This adaptability problem is one of the major concerns of WSBA. Our WSBA provides a way to dynamically conduct or re-conduct conceptual design at any design phase, which allows new activities to be added into the project at any time without abandoning the engineering work already done before the change. For example, when a specific requirement such as “more safety for the car” is required in the middle of the development of a car design project, a new design activity such as “design ABS” can be added into the project, and corresponding changes should be made for the existing work-net. In order to do this, an algorithm for adding an activity is provided in Figure 5-13. Input: An existing work-net = {A, F, L} where A = {ai, a2, a3, ... a;}, F = {fi, f2, f3, ... fi}, L = {fi, 1 2, f i , ... 1 0}, and new activity aj = {WEj,Pj, PI N j, P° j}. Output: An updated work-net = {A’, F’, L’} where A ’ = {ai, a2, a3, ... a,, aj}, F’ = {fi, f2, f3, ... fi, fm , fn, ...}, and V = {fi, 1 2,13, ... 1 0, lp, lq, •••}. Algorithm: for each activity ai € A do begin P ,IN j:= {pi, P2, .. .pm} /* define parameters needed from aj */ end Figure 5-13: Algorithm of WN-Adding 103 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. for each activity a * do begin /* derive parameters delivered to aj */ P ’0UTi := 0 p,OUT ;= p ,O U T u (p. n p l N . ) end for each activity aj do begin if P’ i u P’ i * 0 then do begin WEj := WE-Merg°(wej) /* redo WE-Merg° operation to adjust to the change */ WEi := WE-Mergb(wej) /* redo WE-Mergb operation to adjust to the change */ end end for each activity a; do begin if P’Q U T j ^ 0 then do begin DEjj := 0 for each wem e WEj do begin for each pk e P’o u t'e x m do begin for each we„ e WEj do begin if pk g Pin 'e x n then DEjj := DEjj u {pk} end end end fij := {DEjj} /* create filter from aj to aj */ l°(ai, fij) := {DEjj} /* create link from aj to fy */ l'(flj, a ,) := {DEjj} /* create link from fij to aj */ end if P,IN j * 0 then do begin DEjj := 0 for each wem e WEj do begin for each pk e Po u t-ex m do begin for each wen e WEj do begin if P k g P,ln-ex „ then DEjj := DEjj u {pk} end end end fji := {DEjj} /* create filter from aj to aj */ l°(aj, fjO := {DEjj} /* create link from aj to fji */ l'(fji, aO := {DEjj} /* create link from fy , to aj */ end end A := A + {aj} /* add activity aj */ Figure 5-13: Algorithm of WN-Adding (Cont.) 104 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As an example for the BB problem, a new activity a . 9 is being added as shown in Figure 14(a). Figure 14(b) shows the updated work-net after executing algorithm WN-ActivityAdding. (a) Add an activity ag to BB problem (b) The Corresponding work-net Figure 5-14: Adding an activity 5.4.3 Removing An Activity: WN-ActivityRemoving In contrast to adding a new activity into an ongoing project, sometimes some existing activities are required to be removed also due to the environmental changes. A reversed algorithm, WN-ActivityRemoving is provided in Figure 5-15, which first breaks the links between needed activities and the abandoned activity, and then new links are built up again in the work-net for remaining activities. Input: An existing work-net = {A, F, L} where A = {ai, a2, a .3 ,... a;, aj}, F = {fi, fz, f3, ... fj, fm , fn, ...}, L = {11,12,13,... Ip, lp, lq, ...}, and the activity aj to be removed._____ Figure 5-15: Algorithm of WN-ActivityRemoving 105 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Output: An updated work-net = {A’, F \ L’} where A ’ = {ai, a2, a3, ... a.\), F’ = {fi, f2, f3, ... fi, ...}, and L’ = {li, 1 2, I3, ••• lo,...}. Algorithm: for each filter fij e °aj do begin L := L -{l°(ai,fy )} /* delete link from a; to fy */ L := L -{ l'(fij,aj)} /* delete link from fij to aj */ F := F - {fy} /* delete filter fij */ WEi := WE-Merg°(wei) /* redo WE-Merg° operation in ai */ WEj := WE-Mergb(wej) /* redo WE-Mergb operation in aj */ end for each filter fy e aj° do begin L :=L -{l°(a>fjO } /* delete link from aj to fji */ L : = L - { l I(fji,a i)} /* delete link from fji to ai */ F := F - {fji} /* delete filter fji */ WEj := WE-Merg°(wei) /* redo WE-Merg° operation in ai */ WEj := WE-Mergb(wej) /* redo WE-Mergb operation in a\ */ end A := A — {aj} /* delete activity aj */ Figure 5-15: Algorithm of WN-ActivityRemoving (Cont.) As an example for the BB problem, activity ag is being removed as shown in Figure 16(a). Figure 16(b) shows the updated work-net after executing algorithm WN-ActivityRemoving. M b1 4 M bM |^ ia| b„ (a) Rem ove the activity a a from BB problem (b) The Corresponding work-net Figure 5-16: Removing an activity 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.4.4 Combining Activities: WN-Combining Besides the ability of adding and removing activities, WSBA provides means to allocate resources more efficiently. This is important because resources, especially engineering designers, are very expensive. As described in section 3.2.2, during the process execution, slack-driven situations may happen. That is, when the evaluation result of the execution shows that the project team has more capacity to do a more efficient work, the project manager can remove resources, e.g., human designers, for other use by combining two activities to one activity and assigning it to a single designer. Corresponding algorithm to do this is provided in Figure 5-17. Input: An existing work-net = {A, F, L} where A = {ai, a2 , a3 , ... aj, aj}, {fi, fj, f3 , ... fl, fm, fn, • • •}, L = {li, I2 , I3, ... lo, 1 p , lq, ...}, and activities a, and aj to be combined. Output: An updated work-net = {A’, F’, L’} where A ’ = {ai, a2, a3, ... a’i}, F’ = {fb f2, f3, ... fi}, andL ’ = {lh 1 2,13, ... 1 0} Algorithm: for each filter fm m e °an where n = i v j do begin L : = L - { l 0(am,fmn)} /* delete link from am to fm n */ L := L — {l'(fmn5 a„)} /* delete link from fm n to an */ F := F - {fm n} /* delete filter fm „ */ WEm := WE-Merg°(wem ) /* redo WE-Merg° operation in am */ WEm := WE-Mergb(wem ) /* redo WE-Mergb operation in am */ end for each filter fm n e am ° where m = i v j d o begin L := L - {l°(am , fm n )} /* delete link from am to fm n */ L := L - {l‘ (fmn, an )} / * delete link from fm n to an * / F : = F - {fm n} / * delete filter fm n * / WEn : = WE-Merg°(we„) / * redo WE-Merg° operation in an * / WE„ : = WE-Mergb(we„) / * redo WE-Mergb operation in a„ * / end A : = A - {ai, aj} / * delete activity ai and aj * / P’ j - P i U P j / * combine parameter sets of a, and aj * / P ’ I N j - P ^ j U P^j / * combine input parameter sets of ai and aj * / Figure 5-17: Algorithm of WN-ActivityCombining 107 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. p>INj.= p ,IN j _ (p,IN n pOUT) p,INj.= p ,IN j _ (p ,IN . n p O U T .) p>O U T f_pO U T pO U T /* combine output parameter sets o f a; and aj */ p,omj;= p ,ouT (p .o ir ^ p iN ) p ,o o r;=ap,o ir r _ (p,oirri n p W j) W E’ j := {we0} /* create initial workelement in a’j */ W E’ j := WE-Splitb(we0 ) /* perform WE-Splitb operation in a’ j */ W E’ j := WE-Split°(we’ j) /* perform WE-Split° operation in a’ j */ WE’j := WE-Seq°(we’ j) /* perform WE-Seq° operation in a’ j */ WE’j := WE-Seqb(we’j) /* perform WE-Seqb operation in a’j */ WE’j := WE-Merg°(we’ j) /* perform WE-Merg° operation in a’j */ W E’ j := WE-Mergb (we’ j) /* perform WE-Mergb operation in a’ j */ for each activity a * e A do begin if pO U T u p ,iN . ^ 0 then do begin DEy := 0 for each wem e WEj do begin for each pk e Po ut-ex m do begin for each wen e WE’j do begin if pk e P’in -e x n then DEy := DEy u {pk} end end end fij := {DEy} /* create filter from a; to a’ j */ l0(ai5fij) := {DEy} /* create link from a - , to fij */ l‘ (fy, a’ j) := {DEy} /* create link from fy to a’ j */ end if P,N i u P ’O U T j * 0 then do begin DEji := 0 for each wem e WE’j do begin for each pk e P’o ut'ex m do begin for each wen e WEi do begin if pk e Pln 'e x „ then DEji := DEji u {pk} end end end fji ~ {DEji} /* create filter from a’ j to a * */ l°(a’ j, fjO := {DEji} /* create link from a’ j to fji */ l'(fji, ai) := {DEji} /* create link from fji to a * */ end end A := A — {a’ j} /* delete activity a’ j */ Figure 5-17: Algorithm of WN-ActivityCombining (Cont.) 108 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As an example for the BB problem, activity aj and ^ are combined to a’i as shown in Figure 18(a). Figure 18(b) shows the updated work-net after executing algorithm WN-ActivityCombining. (a) Combine activity a 1 and a 3 in BB problem (b) T he Corresponding work-net Figure 5-18: Combing two activities 5.4.5 Dividing An Activity: WN-ActivityDividing Also described in section 3.2.2, in contrast to the slack-driven situation, strain- driven situation may happen during the process execution. That is, the target is set too aggressive that by current allocated resources it is impossible to have the work done. Under this situation, the project manager should allocate more resources, e.g., human designers, by dividing one activity to two activities and assigning them to two responsible designers to get the job done. Corresponding algorithm for doing this is provided in Figure 5-19. 109 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. a ’i, aj}, F’ = {fi, Input: An existing work-net = {A, F, L} where A = {ai, a2, a3, ... a*}, F = {fi, f2, f3, ... fi}, L = {It, 1 2,13, ... 1 0}, and a; = {W Ej, Pj, P IN j, P ° T j} to be separated from at. Output: An updated work-net = {A’, F \ L’} where A ’ = {at, a2, a3, .. £ 2 , f 3 , • • • f m , f i , • • • }, and L = { I t , 1 2 , I 3 , . . . l o , l p , l q , . . . } . Algorithm: for each filter fm j e % do begin L := L -{ l° (a m ,f m i)} L : = L - { l ,(fm i,a i)} F := F - {fm t} WEm := WE-Merg°(wem ) WEm := WE-Merg (wem ) end for each filter f n e at° do begin /* delete link from am to fm i */ /* delete link from fm i to a; */ /* delete filter fm j */ /* redo WE-Merg0 operation in am */ /* redo WE-Mergb operation in am */ L L F L - {l°(aj, fin)} L — {l'(fjn, an )} F - {fjn} /* delete link from at to fjn */ /* delete link from fjn to an */ /* delete filter f n */ /* redo WE-Merg0 operation in an */ WE„ := WE-Merg°(wen ) WEn := WE-Mergb(wen ) /* redo WE-Merg0 operation in an */ end A := A {ai} P ’i : = P i - P j P ,IN i:= {Pl,P2, ...Pm} p . I N . :=:p ’IN i U (pIN i _ p I N j) P ’° UTi - {pi,P2,...p„} p ^ O U T := P ,0UTi u (P 0UTi - P O U T j) for activity ak e {a’i, aj} do begin WEk := {we0} WEk := WE-Splitb(we0 ) WEk := WE-Split°(wek ) WEk := WE-Seq°(wek ) WEk := WE-Seqb(wek ) WEk := WE-Merg°(wek ) WEk := WE-Mergb(wek ) /* delete activity aj */ /* adjust parameter set o f a ’i */ /* define input parameters in a ’i delivered from aj */ /* adjust input parameter set o f a ’i */ /* define output parameters in a ’i delivered to aj*/ /* adjust input parameter set o f a ’i */ /* create initial workelement */ /* perform WE-Splitb operation on weo */ /* perform WE-Split° operation */ /* perform WE-Seq° operation */ /* perform WE-Seqb operation */ /* perform WE-Merg0 operation */ /* perform WE-Mergb operation */ end for activity ak e {a’i, aj} do begin for each activity aj e A do begin P ,IN j:= {pi, p2, ...pm} /* define parameters needed from ak */ end Figure 5-19: Algorithm of WN-ActivityDividing 110 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. for each activity a\ do begin /* derive parameters delivered to ak */ P’0U Ti := 0 P ,0UTi := P ,0UTi u (Pi n P IN k) end for each activity a - , do begin if P ,INi u P ’° i * 0 then do begin WEj := WE-Merg°(wek) /* redo WE-Merg0 operation to adjust to the change */ WEj := WE-Merg (wek) /* redo WE-Merg operation to adjust to the change */ end end for each activity a, do begin if P’ i ^ 0 then do begin DEik := 0 for each wem e WE; do begin for each pk e P’o u t'ex m do begin for each we„ e WEk do begin if pk e Pm 'e x „ then DEik := DEik u {pk} end end end fik := {DEjk} /* create filter from a * to ak */ l°(ai, fik) := {DEik} /* create link from ai to fik */ l‘ (fik, ak ) := {DEik} /* create link from fk to ak */ end if P,IN j 0 then do begin DEk i := 0 for each wem e WEk do begin for each pk e Po u t-ex m do begin for each wen e WEj do begin if pk e P’m ‘e x n then DEki := DEki u {pk} end end end fki := {DEki} /* create filter from ak to aj */ l°(ak, fki) := {DEki} /* create link from ak to fki */ l'(fki, as) := {DEki} /* create link from fki to a * */ end end end A := A + {a’ b ai} /* add activity a’i and a\ */ Figure 5-19: Algorithm of WN-ActivityDividing (Cont.) Ill Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As an example for the BB problem, activity a $ is divided from a3 as shown in Figure 20(a). Figure 20(b) shows the updated work-net after executing algorithm WN-ActivityDividing. (a) Divide a 3 to a '3 and a 9 in BB problem d a ’ s a n d a g " A’ jbi a3 ■ * X !» > , (b) T he Corresponding work-net Figure 5-20: Dividing an activity Above five work-net algorithms are developed for work-net configuration and adaptation. As stated before, a work-net is a complete setting of work-elements and their dependencies. It does not provide a specific process for designers to follow. Instead, it implies multiple active-processes which can be dynamically coordinated and determined by all stakeholders for the most efficient execution. For the example shown in Figure 12(b), when the execution of work-element we6 in activity as has been finished, the intelligent agent of as delivers parameter b3 i.p2 to its output filter f36. Based on dependency-element dei = (a3.we6 — h,vP i > a6 .we4 i), f36 forwards b3i-P2 to its output place a6. When a6 receives b3i.p2, the execution of we4 i in a* can start. However, whether or not it really starts is determined by the responsible 112 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. designer of a& and the current situation, e.g., the designer of a$ can start \ve42 instead of we4 i if both of them are ready to start, because we42 can produces bs2 -P 2 which has been required by ag. The decision of whether first working on b4 i or bs2 is dynamically made through the coordination between designers for the most efficient use of resources and the biggest opportunity of concurrent engineering. In the next section, we will present how an active-process can be developed. 5.5 Active-Process Algorithms The work-net developed in the last section is not the end of WSBA to support collaborative engineering design. As described in chapter 3, active-process should be finally developed through the coordination between the project manager and participating designers. Although the coordination processes and mechanisms can be different and open, algorithms should be provided in order to generate and simulate all possible processes based on the work-net. In this section, we will develop two active-process algorithms, namely, AP-Generating and AP-CriticalPathFinding. 5.5.1 Generating Active-Process: AP-Generating The algorithm for generating active-process is provided in Figure 5-21. Input: An existing work-net = {A, F, L} where A = {ai, a2, a3, ... a;}, F = {fi, f^, f3, ... fi}, L = {lb 1 2,13, ... U , and each activity % = {WEU Pi, P ^ , P0 U T i}. Output: An active-process set {AP} which includes all possible active-processes AP = {WP}, where WP = {wpi, wp2, wp3, ... wp;}, where wpi = {W Ej, a;} .________________ Figure 5-21: Algorithm of AP-Generating 113 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Algorithm: for each activity aj e A do begin WPj := permutation(WEj) /* permute possible working-procedures of aj */ for each wpj e WPj do begin for every two wem , wen e wpj do begin if [wem , we„] c= aj and (wen — > ... — — > wem or wen — 2— > ... — 2 —> . wem ) then W Pj := W Pj - {wpj} /* delete inconsistent w p */ end end end {AP} := combination(WPj) /* combine possible active-processes */ Figure 5-21: Algorithm of AP-Generating (Cont.) The above AP-Generating is a rather abstract algorithm. It first permutes all possible working-procedures of the work-elements in each activity. After this, from the permutation result it removes those instances which violate the object-based sequence and operation-based sequence. Finally, it forms the set of active-processes by making combination of all possible working-procedures from all activities. This AP-Generating includes two general mathematical algorithms, permutation algorithm and combination algorithm, which are open questions in computational algorithm research area. There are many permutation and combination algorithms however each of which has its own strong and weak points depends on the type and the size of the problem. The choice of which one should be applied is crucial for the efficiency of WSBA, i.e., the computer calculation cost. To the scope of this thesis, we leave it as an open question because extensive evaluation work for are required to be done before we can draw a conclusion. As a simple example shown in Figure 5-22, both activity ai and a2 have four work-elements. The arrows of “internal work-element working sequence” and 114 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “external work-element working sequence” indicate the underlying orders to execute these work-elements. Table 5-4 shows the permutation result after executing AP- Generating algorithm, i.e., ai has 3 possible working-procedures (marked by “X”) while a2 has 6 possible working-procedures for the execution of work-elements. Table 5-5 shows all the possible combinations of the working-procedures in all activities, i.e., altogether there are 18 possible active-processes which are available for project stakeholders to choose the executive active-process. w e3 w e4 we1 we^j \ \ L egend: o Activity □ W ork-Elem ent — Internal w ork-elem ent working se q u e n c e -------► External w ork-elem ent working se q u e n c e Figure 5-22: A simple example for AP-Generating Table 5-4: The permutation result of AP-Generating Permutation Possible working- procedures Permutation Possible working- procedures ai a2 ai a2 1234 X X 3124 X X 1243 3142 X 1324 X X 3214 1342 X 3241 1423 3412 X 1432 3421 2134 4123 2143 4132 2314 4213 2341 4231 2413 4312 2431 4321 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 5-5: The combination result of AP-Generating Possible active- process Working- procedures Possible active-process Working- procedures ai a2 ai a2 1 1234 1234 10 1324 3124 2 1234 1324 11 1324 3142 3 1234 1342 12 1324 3412 4 1234 3124 13 3124 1234 5 1234 3142 14 3124 1324 6 1234 3412 15 3124 1342 7 1324 1234 16 3124 3124 8 1324 1324 17 3124 3142 9 1324 1342 18 3124 3412 5.5.2 Simulating Active-Process: AP-CriticalPathFinding The algorithm for simulating active-process is provided in Figure 5-23. Input: An active-process AP = {WP} where WP = {wpi, wp2 , wp3 , ... wpi}, where wp; = {W E j, ai}, and each work-element requires a time duration t(wej) to finish. Output: The lead-time of the active-process T(AP), and the critical path CriPath of work-elements that have to be finished on time otherwise the whole active-process will take longer. Algorithm: PATH := 0 for each working-procedure wpi e WP do begin onePath := 0 wej := firstWorkElementOf(wpi) /* get the first we of the wp */ onePath := onePath + (wej) /* set the head of the path */ 5 do begin for each work-element wej+i e nextWorkElementOf(wej) do begin if wej+i != lastWorkElementOf(wpke WP) then do begin onePath := onePath + (wej+i) /* prolong the path */ wej := wej+i goto 5 end ___________________ else then do begin_______________________________________ Figure 5-23: Algorithm of AP-CriticalPathFinding 116 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. onePath := onePath + {wej+i} /* prolong the path */ PATH := PATH + {onePath} /* finish a path */ end end end end T := 0 criPath := 0 for each path e PATH do begin t = sumOfDuration(wemepath) if T < t then do begin T = t criPath = path end end /* get the duration o f the path */ /* set the lead-time of the process */ /* set the critical path of the process */ Figure 5-23: Algorithm of AP-CriticalPathFinding (Cont.) After all the possible active-processes have been generated by AP-Generating, simulations should be done to these processes for different criteria and purposes, e.g., cost, time, interaction, and so on. The above algorithm AP-CriticalPathFinding is developed for an important simulation which is to find out: 1) what is the project lead-time for a specific active-process, and 2) which work-elements are critical, meaning that they have to be finished on time otherwise the whole project will take longer. As a simple example, Figure 5-24 shows an active-process including three working-procedures of activity ai, a2 , and a2 , each of which has 5, 4, and 4 work- elements, respectively. In Figure 5-24, the numerical number under each work- element indicates the units of time to finish that work-element. There are totally ten possible paths can be found in this active-process, as summarized in Table 5-6. The result shows that path w ei-» we2 -> we3-> we4 -»-w e 7-» weg— > • wee,— » wes is the 117 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. critical path of this active-process, which means that the delay of the execution of these work-elements will cause a longer lead-time than expected. This result is important for the project manager to choose the execution active-process from all the possible active-processes generated from AP-Generating, and then post it to all participating designers for discussion and coordination. Working- procedure of a . Working- procedure of a . Working- procedure of a . we we. we. we. we, we. we, we. we. we. we. we. Figure 5-24: A simple example for AP-CriticalPathFinding Table 5-6: The result of AP-CriticalPathFinding Path Work-elements in the path Lead- time Critical path 1 wei— » we2— > ■ we3— > we4— » wes 12 2 w ei-» we2 -» we8 -» we9 11 3 wei— » wq2— > we8 — > ■ we9— » we5 13 4 wei— > we2 — > we3— > ■ w e< 4— » we?— > we8 -> we9 17 5 wei-> we2 -> we3-> we4 ^ we7-> we8 — > we9-> we5 19 X 6 we6— > we7^ we8 — > we9 10 7 we6-> we7-> we8 — > • we9-> we5 12 8 Weio-> w en-> wei2— > wen 10 9 weio— > w en-> we9 7 10 w eio ^ wei i— > we9— > wes 10 118 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Above two algorithms are developed for active-process development. They are basic algorithms for the step of active-process collaboration and adaptation involved in WSBA as described in chapter 3. While AP-Generating generates all possible active-processes which are suitable for a given project and AP- CriticalPathFinding provides useful simulation results for the project manager to pickup a feasible execution active-process, the methods of how to decide the optimal active-process through coordination are not included in this thesis. The reason is that it is very hard to theoretically formalize the coordination process and mechanism for stakeholders to efficiently and effectively working together and making decisions. The decision-making theories and technologies for collaborative engineering design is out of the scope of this thesis, fortunately, they can be found in [13], a Ph.D. dissertation of the author’s colleague, which hopefully can be filled into this gap. 5.6 Summary In this chapter, we first discussed a hypothetic but illustrative collaborative design problem, Building Blocks, as the case example for further development of the proposed Work Structure Based Approach, and then developed a set of mechanisms and algorithms to consolidate WSBA. Referring to the five formal steps we concluded in chapter 3, here we developed six work-element operations for step 2, i.e., WE-Splitb, WE-Split0, WE-Seq°, WE-Seq°, WE-Merg0, and WE-Mergb, five work-net algorithms for step 3 and 5, i.e., WN-Constructing, WN-ActivityAdding, WN-ActivityRemoving, WN-ActivityCombining, and WN-ActivityDividing, and 119 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. two active-process algorithms for step 4, i.e., AP-Generating and AP- CriticalPathFinding. They are summarized in Figure 5-25. T a sk a s s ig n e d Step 1: I rt.sk decom position Step 1-1: G enerating m ultiple activities Step 1-2: A ssociating w ith the product m odel Step 1-3: A ssigning activities to designers Step 2: W ork-K lrm rnt elaboration Step 2-1: G enerating initial w ork-elem ents Step 2-2: D efining w ork-elem ent dependencies Step 2-3: R efining w ork-elem ents and relations Step 3: \ \ orL-Net configuration Step 3-1: C ollecting w ork-elem ent inform ation Step 3-2: C onstructing the w ork-net E n v iro n m en t c h a n g e d Step 4; Active-Process colla boration and a< 1 aptalion Step 4-1: G enerating possible processes Step 4-2: Selecting the optim al process Step 4-3: executing the selected process S tep 4-4: adapting the execution process Step 5: W ork-Net A daptation Step 5-1: M odifying related activities Step 5-2: A dapting the w ork-net Step 5-3: Resum ing the active-process W E-Split W E-Split W E-Seq W E-Seq° W E-M erg W N -C onstructm g W E-M erg W N -A ctivity A dding W N -A ctivityR em oving W N -A ctivityC om bining N -A ctivityD ividin A P-G enerating A P-C riticalPathFinding Figure 5-25: Summary of the mechanisms and algorithms So far, we have formalized our new approach for collaborative engineering design and developed theoretical and technological solutions. In the next chapter, we will develop systems and tools to realize this approach. We will develop a prototype system to support WSBA, and all the mechanisms and algorithms presented in this chapter will be implemented in that prototype system. 120 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6 System Realization and Verification 6.1 Introduction In this research, we not only develop conceptual methodologies and theories for solving large-scale collaborative engineering design problems, but also develop systems and tools to realize and validate our ideas. In this chapter, we will develop a prototype system, called Active-Process System (APS), for the Work Structure Based Approach and its supporting technologies presented in previous chapters 3, 4, and 5. First, we will design the system architecture for APS. Based on the requirements and nature of WSBA, APS is designed as a web-based, server/client- configured, and agent-distributed system which has seven major components, namely, web server, active-process server, active-process database, manager’s agent, designer’s agent, KICAD (Knowledge Infrastructure for Collaborative Product Development) agent, and CAD system. We will briefly introduce every component included in this architecture. Then, we will test and verify the APS system with two design scenarios. The first design scenario is a hypothetic one based on the Building Blocks. Our focus in the BB test will be the coordination between stakeholders, and the adaptation of work-net and active-process. We will show how APS can be used to facilitate the whole design process included in WSBA by going through all the design steps as detailed as possible. Screen dumps will be provided for this test. The second design 121 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. scenario is based on a real industry design problem, Inner Front Door Design. Our focus in this IFDD test will be the link between the product model and our process model AWPM, and the interaction between agents and the CAD system. Some Evaluation results with and without APS will be given based on this test. Finally, we will evaluate the system and discuss the observations gathered from the system development and testing. 6.2 System Architecture The major objective of Active-Process System is to provide a software platform for facilitating WSBA. Due to the nature and features of WSBA, the architecture of APS has been designed as a web-based, server/client-configured, and agent-distributed system as shown in Figure 6-1. Active-Process designer client site A CAD system Active-Process server site KICAD ag en t Active-Process m anager client site W eb se rv er D esigner’s ag en t CAD sy stem Manager object Designer object Active- P ro c e ss se rv er KICAD ag en t Active-Process designer client site B M anager’s ag e n t CAD system A ctive-Process d a ta b a se KICAD \ / ag e n t J Legend: Download swing applets from w eb server Two way external socket com munication Two w ay internal socket com munication D esigner’s ag en t Figure 6-1: Active-Process system architecture 122 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Generally speaking, APS belongs to server-client software architecture where a server is defined as the provider of services and a client is defined as a requester of services. It can be further categorized into 2-tier server-client architecture that commonly consists of three layers, namely, presentation layer, application processing layer, and data management layer. Presentation layer handles the user interface, such as session, text input, dialog, etc. This layer is exclusively allocated to the client. Application processing layer handles application computing, such as process development and enactment, events monitoring and reporting, resource services, etc. This layer is separately allocated to both the client and the server. Data management layer handles database issues and file services. This layer is completely allocated to the server. APS architecture falls into this three layers 2-tier server-client category. It includes seven major components distributed in one server and multiple clients. These components are described in the following. Web server Commonly, web server allows an enterprise to serve content over the Internet using the Hyper Text Markup Language (HTML). It accepts requests from browsers such as Netscape and Internet Explorer and then returns the appropriate HTML documents. A number of server-side technologies can be used to increase the power of the web server beyond its ability to deliver standard HTML pages, such as Java applet technology. An applet is a program written in the Java programming language, which can be included in a HTML page. When a user uses a Java enabled 123 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. browser to view a page that contains an applet, the applet’s code is transferred to the user’s computer and executed by the browser’s Java Virtual Machine (JVM). This helps an enterprise to improve the security and scalability in allocating software tools. In APS, all software tools, mainly, manager’s agent and designer’s agent, are developed as Java applets, located in the web server, and can be download to the user’s desktop through either Netscape or Internet Explorer. We apply Apache Web Server as the web server for our prototype system. Active-Process server Active-Process server provides project level services such as process repository maintenance, designers and managers’ administration, resource allocation, communication channel establishment, database connection, and so on. Besides these fundamental services, it includes two kinds of objects which can be initialized and invoked from the requests of clients: designer object and manager object. Each object represents a client and maintains two external socket communication channels: one is connected to the manager/designer’s agent in the client site, and the other is connected to the KICAD agent in the same client site. These objects provide database accesses to clients and communication facilitator between clients. Active-Process database Active-Process database maintains two levels of data: enterprise level data and project level data. Enterprise level data contains designers and managers’ profiles, resources availabilities and allocations, process repository storing proved processes and engineering activities, and so on. Project level data contains process information 124 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of each ongoing project, such as activity and work-element information and their dynamic status, activity level precedence relations and work-element level engineering dependencies, design events in every activity, interaction between related activities, and so on. In the prototype system, we implement MySQL database server which is extremely fast and easy to be customized for prototype system development, and certain effort has been made on Oracle database server which is applied as the enterprise solution. Manager’s agent Manager’s agent is developed as Java Swing applet. It includes user interface and project level global computation. It can be downloaded from the web server and then run in the project manager’s desktop. For a given project, security administration tools, graphic drawing tools, object management tools, process analysis tools, and communication assistance tools are embedded in this agent to help the project manager to log into the project team, construct and operate the corresponding work-net, manage and maintain work-elements in each activity, do dynamic analysis and simulation on active-processes, and issue certain commands to participant designers. Both the algorithms for work-net configuration and adaptation developed in section 5.4 and the algorithms for active-process collaboration and adaptation developed in section 5.5 are implemented in this agent. We use Java Swing components to program manager’s agent because they have more functionality than Java AWT components and have the same present on different platforms. 125 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Designer’s agent Designer’s agent is also programmed as Java Swing applet. It includes user interface and activity level local computation. Similar to the manager’s agent, it can be downloaded from the web server and run in a designer’s desktop. After a designer log into the project team, he or she can use this agent to accept/reject and load/save an assignment, elaborate the work-elements, schedule the working- procedures, and coordinate the active-process with others. The operations for work- element elaboration developed in section 5.3 are implemented in this agent. CAD system CAD system is where the engineering design work is truly carried out by designers. For each activity, a designer can create mechanical parts, define parameters of the parts, and design the values of these parameters using CAD system. We apply a customized AutoCAD’s Mechanical Desktop system for the prototype APS. We develop a Visual Basic Application (VBA) and embed it in the AutoCAD system. This VBA is used to capture all design events taken place in AutoCAD, such as part update and value change, and report these events to the corresponding KICAD agent through a two-way internal socket communication channel for further operations. KICAD agent KICAD agent is a standalone application developed by the KICAD agent project team in the author’s research lab. Although a lot of agent research has been done for both academic and practical purposes, e.g., personal assistant agent, mobile 126 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. software agent, and information retrieval agent, KICAD agent has a rather different context, specifically in engineering collaborative design domain. The major goal of KICAD agent is to provide engineering designers knowledge base support and enhance the productivity of their design work. KICAD agent has been designed to have three layered functionalities: 1) communication functionality, i.e., ability to process KQML, HTML, XML and other language formats; 2) generic functionality, i.e., basic capabilities that an agent should have, e.g. management, reasoning, coordination, autonomy, and so on; 3) extensive functionality, i.e., based on different applications, extensive modules are plug into this generic KICAD agent, e.g., the KICAD agent employed in APS has a specific module that enables it to collect and filter design events captured in the customized AutoCAD, and then forward valuable design information to the active-process server if necessary. All the above seven components of the APS architecture have been fully realized. In the following sections, we will illustrate how APS works for supporting WSBA by two design scenarios, Building Blocks and Inner Front Door Design, with different focuses. 6.3 A Testing for A Hypothetic Design Scenario: Building Blocks A Building Blocks case example has been discussed in section 5.2. Here we will provide system solutions for eventually solving this hypothetic design problem. The focus in this section will be fully demonstrating how APS can support the 127 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. complete design and coordination process included in WSBA. We will go through every step of WSBA presented in Figure 3-4. For demonstrating purpose, we simplify the 8 -activity BB problem discussed before to a 3-activity problem as shown in Figure 6-2. This testing Building Blocks case example has three activities ai, a2 , and a3 . The task for each activity is: ai includes four blocks bn, bn, bn, b2 3 ; a2 includes five blocks bi4 , bn, b2 4, b 3 3, b3 4 ; and a3 includes five blocks b2 i, b2 2, b3 i, b3 2, b4 2 . Initially, only activities ai and a3 are involved in the project. Then, in the middle of product development and process execution, the third activity a2 is added into the project for some reasons. The requirements and constraints for this testing BB case example are similar to the one we discussed in section 5.2. i f l l l t i l l A c t i v » ,= *t*, Figure 6-2: The testing BB case example We program the whole APS system using Java language which is compatible for most popular platforms. All seven components in Figure 6-1 are tested in both a Windows PC and a Unix/Linux workstation. Following we will go through all the steps for solving the BB testing problem in APS. 128 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.3.1 Startup and Login • Start up web server, active-process server, and active-process database. • Manager logs in from the APS home page through the web server, and a manager’s agent will be downloaded to the manager's client site. • Designer 1 logs in from the APS home page through the web server, and a designer’s agent will be downloaded to designer i ’s client site. • Designer 3 logs in from the APS home page through the web server, and a designer’s agent will be downloaded to designer i ’s client site. ■ & $ a a y » . . . j H H H tfdesgn uK.edW«pdeir»lapta».ta>l ActiveProcess Home Page Fie Edi M F c D lK T«i! Copyri^O 1998 -2002: r ....................... « Broughtto w to :Im a c tL a b . 1T S<- ® “ p ,,d™g" U K * * * Maintained b y Xi Zhao Manager's Loam Designer's Loam A N N O U N CEM EN TS Note: Because (he ActiveProcess i 1.2 API, they require Java Plug-in 1.2 or,' wont work with uncustomized 1.1 brows Plug-in, vis# the JavaP htg-fa product pag; l l t f h t t p ? / / t t e « g r » « u s c < e d a / « < J d w w s / ActiveProcess Manager Login on tnfprY tw t o x n t e iManagsr Tor I n t« P a s a w a r t : l„ « n H .™ . (fe u H Note; Because the preceding applet uses die Swinj 1.3. It won't work with uncustomized 1.1 browsers To download Java Plug-in, visit die ?Mft,Pk&r.ia product | Figure 6-3: Screen dump - APS web page and login Screen dump Figure 6-3 shows the APS web page and login interface. 6.3.2 Task Decomposition • Manager creates a new project named “Building Blocks”. 129 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Manager creates a new product model or loads an existing product model for BB from the active-process database through active-process server. • Manager creates activity ai and defines the task involved in a.\. • Manager creates activity a3 and defines the task involved in a3 . • Manager assigns activity ai to designer 1. • Manager assigns activity a3 to designer 3. • Designer 1 accepts activity ai. • Designer 3 accepts activity a3. -Inixl I tflM t Ai.'Mty WnfhNHt PlOCBSS llrip Task Pa&crtyttwi [finish Blo ck s _ Ob»ect_11 * Object 1 U - p g sig n arl | OK m essage ‘RegtsterRepiy from server ecetved m essage 'NewDesigner4 from Server eived m essage 'NewOeslgner* from Server {Outgoing Message: ient m essage 'ManagerRegister4 to. Server lent m essage 'QueryDeslgnerUst'to Server 'QueryProductModels* to Server 'QueryOesignerLisf to Server J S S G L E Figure 6-4: Screen dump - task decomposition Screen dump Figure 6-4 shows the interface of manager’s agent after task decomposition. 130 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.3.3 Work-Element Elaboration • Designer 1 defines the operation for each block of activity ai. • Designer 1 defines the initial work-elements of activity a\. • The agent of designer 1 elaborates the work-elements o f activity ai using the work-element operations developed in section 5.3 (however, the merging operations are not included in this prototype system). • Designer 3 defines the operation for each block of activity aj. • Designer 3 defines the initial work-elements of activity a$. • The agent of designer 3 elaborates the work-elements of activity a3 using the work-element operations developed in section 5.3 (however, the merging operations are not included in this prototype system). Table 6-1: The work-element information table for activity a3 WE Op Ob p in -e x p in -en po u t-ex p o u t-en 0 > h > Sue we Sue we a3 wi construct b2i 0 0 0 b2 i.m a3_w 2 0 a3_w2 paint b2i 0 0 0 b2 i.c a3_W 3 0 a3_W 3 position b2i bn-P2 0 0 b2 1 .p1> b2 i-P2 0 a3_w 9 a3_W 4 construct b22 0 0 0 b2 2 .m a3_w 5 0 a3_w 5 paint b2 2 b23.c 0 b2 2 -C 0 a3_w 6 0 a3_w 6 position b22 bl2 -P 2 0 0 b2 2 .p 1, b2 2 -P 2 0 a3 w ! 2 a3_w 7 construct b3i 0 0 0 b3 1 .ni a3_w 8 0 a3 _wg paint b3i 0 0 0 b3 i-c a3_w 9 0 a3_W 9 position b3i 0 b2 1 -P 2 0 b3 1 .p1, b3i-P2 0 0 a3 _wio construct b32 0 0 0 b 3 2.n1 a3 w n 0 A 3 J W 11 Paint b 3 2 0 0 0 b32.c a3 _wi2 0 131 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 6-1: The work-element information table for activity a3 (Cont.) A3_Wi2 position b3 2 0 b2 2 -P 2 0 b3 2 .pi, b 3 2 -P 2 0 a3_wi5 A3_Wj3 construct b42 0 0 0 b42.m a3_Wj4 0 a3 W 14 paint b42 0 0 0 b42.c a3_w i5 0 a3_w i5 position b42 0 b3 2 -P 2 0 b42-Pl> b4 2 -P 2 0 0 ArtMty Wofkrioinfiiit M plp 9 C 3 a _ 3 D a j . w j -IPlXl D w D A _3 □ * -3 Q a _ 3 Q a _ 3 D A .3 Q a j D a „ 3 Q aj Q a _ 3 Q a_3 Q A_3 D A -3 Q a_3.W_13 W J 2 W _ 3 W _ 4 W _ 5 W _ 8 W _ 7 W _ » W _ 8 W_10 W _ 1 1 W _ 1 2 W _ 1 3 W 14 JavaAppttWhddw A 3.W 1 4 A 3 W _ ? A 3.W 7 A_.'t.W_ A l.w i: I A IIN A_3.W_4 4 A_3.W_fi ; - 4 A_3.W_li A J.W 10 I A 3.W .11 I A 3.W 17 A iifV I'i 4 A I.W 11 4 A IW W orn Pr #Vlllnl ItTlBltll PfllpKllH' A . J W J 2 Object _32 ■ i | iu i p . ir < m i Object 77417 in n i- m I M w u n Object .324)1 t’li;l.l.'(lililt W 1 A_3.W_11 ■'[) Nik c ig UrkiWI n M i . t - i w i i i . q W t ' A.3.W.6 AJLW.15 .>iii<t1ifti NI.AII-. NOT READY OK Figure 6-5: Screen dump - work-element elaboration Table 6-1 shows the information of each work-element in activity a3 and screen dump Figure 6-5 shows the interface of designer 5’s agent after the work- element elaboration. 6.3.4 Work-Net Configuration • The agent of designer 1 reports the work-element information o f activity ai to the agent of manager. 132 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • The agent of designer 3 reports the work-element information o f activity a3 to the agent of manager. • The agent of manager configures the work-net using the WN-Constructing algorithm developed in section 5.4. A<-UwPror cs« Mainframe AttM ty W oikN el 9 B B uilding iocte 9 B A C t M t y 9 ESfU Oa _ i, w j Q A J.W J D A .1 W J Dajwj Q a j . w j D a j . w j Q a _ i,w . Q a i.w 1 Oaj. w . O a j . w . i Q a j . w j Q a j . w j © • B a 3 fdF e f B A J . / L 3 Q d e i Dd k D 0 6 3 ^ pr<*®(a(!s— & .L . _______ , « k W m kN * P rn u n s , . B uilding 6 HK M H airo A .-. • |B W A J .W J 1 _ J JZZ- OK Received m essag e •AsslgnResporise' from O eslgner t Received m essag e 'A ssignR esponse1 from D esigner 3 Received m essag e 'WoiKElemenflnto' from D esigner 1 R eceived m essag e •WortsEtementWo' from D esigner 3 , y L d ^ ^ jr k ^ y m ? z , id?;? • ' * l 4 d v s A p p t e l m essag e 'TaskAssIgn' to O eslgner 1 m essag e 'TashAsslgn' to D esigner 1 m essag e 'TaskAssIgn' to O eslgner 3 m essag e 'Paramlrifo' to D esigner 1 m essag e 'Paramlnfo1 to D esigner 3 Figure 6-6: Screen dump - work-net configuration Screen dump Figure 6 - 6 shows the interface of manager's agent after the work-net configuration. 6.3.5 Active-Process Collaboration and Adaptation • The agent of manager generates all possible active-processes from the work-net using the AP-Generating algorithm developed in section 5.5. 133 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • The agent of manager simulates the active-processes (focus on project lead- time) using the AP-CriticalPathFinding algorithm developed in section 5.5. • Manager selects an appropriate active-process from the simulation results. • Manager broadcasts the selected active-process to designer 1 and 3. • Designer 1 and designer 3 state their opinions on the selected active- process to manager. • Manager modifies the selected active-process based on designers’ opinions. • Manager re-broadcasting the modified active-process to designers. • • Manager clinches the modified active-process upon the agreement of all designers. • Manager assigns the modified active-process to all designers. • Designer 1 and designer 3 follow the active-process to carry out their design work. During this period, designers’ agents monitor the design events, report the design results and events to manager’s agent, forward design information to other designers’ agents, and provide extensive reminders to their responsible designers. Meanwhile, manager can issue certain control command to designers. • • When exceptions occur, the above procedures of active-process coordination and adaptation repeat. 134 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P io jo c t A ctM ty Wtafk Not ^ 'O 'S u lic iin g Gioctei ^ C 3 ActivrV 9 c3a_i Dvi D a j D a .ij Qalij Q a j Q aj.< Q a j.w D a jv v D a _ i.* < Q a j Da.iv D a .iv ® -@ A .3 9 OK Filter 9 ( 0 A . 1A . 3 Q D E 1 Q D E 2 D oes r t s w a i Q d e i A d t i v c . / V I A . W l M l * ' « A _ IW 1 1 1 . * IW .1 1 | j av* Apptei Winded 'A ssig n R esp o n se' from D esig n er 1 /A A A lM M n M A « A » A N l A m e s s a g e A ssig n R e sp o n se from D esig n er j m e s s a g e w ork E iem en tln fo ' from D e sig n er t m e s s a g e ’ W orkE iem entinfo’ from D esig n er a 'TaskA ssign' to D esig n er 1 'T askA sslgn' to D e sig n er 1 'T askA sslgn' to D e sig n er 3 •P aram in fo 'to D e sig n er 1 'P aram lnfo' to D esig n er 3 B Figure 6-7: Screen dump - active-process generation and simulation A ctiveProcess Client; Main! Activity WorkUement Help f I H j A J Q a j . w j J a v a O A J Q a j D a j D a j D a j D u O A J D a j D a j D a j D a j W_2 W_3 W _ 4 W_S W J W _7 W_8 W _ 9 W JO W J1 W J2 Window A J . W J — » A J .W _ ? — * A t .W .3 j A J . W J — « A 1 .W .5 — « A .1 .W f i ] A. 1.W 7 - -< A 1.W 0 — « A .1 .W .9 j ..................... r _ _ A..... . A ..1.W _10 — 1 A J ,W _ 1 1 1 - < A .1 .W J 2 ] - J d J xJ R 'i in i-i|u i’ ..u iin i'M e d — |:.M ii!i;jti-;ll‘iiii.i-iliii i> A J . W J A J W-2 A_1 W _1 A J W _7 AdMty A-i.wj A J W _5 A J W 6 t w _-n A J .W J A J . W J A J W J 1 W _7 R e je c t I A.] I Figure 6-8: Screen dump - active-process coordination 135 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. M iojett A clM ty W w k Net P u ir.o ss Help /? T 3 'g u jw i'iiF B l6 tN s ]* j ‘ < S > □ A c t i v i t y » 1 w _ « t G3A 1 * aF iite f C jA l-AJS C 1 a > a _ i ijp .jajxj r W « k H a m s irt P n tfN ifttM i . r I S P a M O U K t O M « l_ M - 1 S a i n s B S S H I P i .|i iia.'i i l l » i i t a i s ....a f R f H itP a r a ta O tdect 73.C i n i O n tp s A W ® ........ . O bisct _ » x - 1 l‘ v a i.i M e ied I R ...OK.... i n i ceivw i m e s l ^ 'e ,A S M pR espbH ser from 'D esigfief 1 ^ cetved m e s s a g e 'A ssig n R esp o n se' from D esig n er 1 f c d e c eiv e d m e s s a g e ‘ W a rk S em en tlo W from D e sig n er 1 ec etv e d m e s s a g e 'W arkS em entlttfo' from D esig n er 3 paasntrsem r It m e s s a g e 'T ask A ssig n 'to D esig n er 1 t m e s s a g e ‘T askA sslgn' to D e sig n er 1 t m e s s a g e 'T askA sslgn' to D e sig n er 3 t m e s s a g e 'P aram info' to D e sig n er 1 t m e s s a g e 'Param info' to D e sig n er 3 [Java AppM Window Figure 6-9: Screen dump - active-process execution A ctiveProcess £ Nent: Mail if r->t a Activity Workfctemenl Hei|» ^ I I a j Q a j . w j 0 A J . W J Q A J . W J Q a j . w j Q a j . w j Q a j . w j Q AJ.wjr Q a j . w j Q a j . w j 0 a j w j o Q a j . w j i Q a j w j 2 1.W .8 4 A 1.WJ Work I I ■Jajxi p t n Work! lenient— f r a m e A ’ W.4 m | ii: i . iIio ii C o n s t r u c t D ia l '.I _ Object J 2 ▼ M . l O , S READY J O . 00 D u r a t io n _ _ _ _ ZZ.J I sill! P .ila m M ■.< V ainn ■ u 'lp u t i 'a r a n t 0bj8ct_1?.m » iii.-.ig ii V a lu e gla;-. fn tu i Cancel Ja v a Applet Window Figure 6-10: Screen dump - engineering design work Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Screen dumps Figure 6-7, 6-7, 6-9, and 6-10 show the interface of active- process generation and simulation, active-process coordination, active-process execution, and the real engineering design work, respectively. In Figure 6-9, a work- element button with yellow color means this work-element is “finished”, a work- element button with green color means this work-element is “ongoing”, and a work- element button with gray color means this work-element is “waiting” for some information provided by other work-elements. It can be seen the work-element A1_W4 is “ongoing”, and work-element A3_W6 is “waiting” because its input exogenous parameter bn.p 2 has not been provided by work-element A1_W1. However, this restriction does not apply to work-element A3_W5. From Figure 6-9, although the input exogenous parameter b2 3 .c has not been provided by work- element A1_W11, work-element A3_W5 can still keep going to be “finished” because work-element A1W11 also requires an input exogenous parameter b2 2 .c from work-element A3_W5. The prototype APS simplifies this kind of cyclic design case by a first-come-first-go rule, i.e., in this example, the design of work-element A3_W5 can be free but the design of work-element Al-Wll should consider the design result of work-element A3_W5 which is early finished. 6.3.6 Work-Net Adaptation During the active-process execution, when the product requirements are changed due to various reasons, the work-net should be adapted and the procedures of active-process coordination and adaptation should repeat. Here, we show how a new activity can be added into the existing project (activities can also be removed, 137 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. combined, and divided in APS). We suppose that a new activity a2 is required to be added into the BB testing example and the product model of activity a2 is already stored in the active-process database. • Manager adds activity a2 to the BB testing project by loading the product model of activity a2 from the active-process database through active- process server. • Designer 2 logs in from the APS home page through the web server, and a designer’s agent will be downloaded to designer 2’s client site. • Manager assigns activity a2 to designer 2. • Designer 2 accepts activity a2 . • Designer 2 defines the operation for each block o f activity a2 . • Designer 2 defines the initial work-elements of activity a2 . • The agent of designer 2 elaborates the work-elements of activity a2 using the work-element operations developed in section 5.3 (however, the merging operations are not included in this prototype system). • The agent of designer 2 reports the work-element information of activity a2 to the agent o f manager. • Designer 1 specifies the dependencies between the product model of activity ai and the product model of new added activity a2 . • The agent of designer 1 reports the dependency information to the agent of manager. 138 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Designer 3 specifies the dependencies between the product model of activity a3 and the product model of new added activity a2 . • The agent of designer 3 reports the dependency information to the agent of manager. • The agent of manager refreshes the work-net using the WN- ActivityAdding algorithm developed in section 5.4. • Manager, designer 1, designer 2, and designer 3 working together to repeat the procedures of active-process coordination and adaptation presented above. fix M.imf r-iote P io jw t ActMty VttKkNrt l*rw(»ss Hrip T ida bU iiwirijj ? B a o kw RittlUmu Bku k s P it Q a _ 2 . v Q a _ 2 . v D A - ! ! * D a_ 2 .V 0 AJ2.V D A .2 .V 0 A J W 0 A _ 2 t f Q a_2V D A . 2 . V D A .2 - V 0 A - 2 * f \ 'A tM K D B S C T ljto l.. OIW Kt.HX Q A J W Du* D A .2.V S ent m essage 'MustKnowParam' to Designer 2 S en t m essage Param V alueTranster to D esigner 3 S ent m essage 'Param ValueTranster to D esigner 2 S ent m essage 'Param ValueTranster to Designer 1 S ent m essage 'ParamValueTranster1 to Designer 1 ® - E 3 a _ 3 ? « fitter Figure 6-11: Screen dump - updated tasks 139 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. AtiMty WiirkNiif I I w iim llnlp r ^ C 3 G b i^ n g 8 S o c k s I 9 C3AclMty ? C3A_2 D a „ 2 D A J D a . 2 Q a . 2 D a _ 2 Q a _ 2 D A J D a . 2 Q a . 2 D a _ 2 Q a _ 2 QA _2 D a j D a . 2 . D a_2.v ©■[3A.1 e-d»J f d Filler f r C 3 A_2-A_3 JsI j s I 'mmA. A— 1 ^ T t« L ij|# r . j |_ it flrrtf ni'A IA SH WIKMWI MUlUfc* •’ O T g n f^sp ^srfffim lD ^T O n '^ stved m essage 'A3signResponse‘ from D esigner i deceived m essage ’ AssignResponse* from D esigner 3 i m essage ■WorkElementlnfo’ from Designer 1 j ’ WorkBementinfo’ from Designer 3 ObHK.1^14 4 “ » > ■ < U «*» I V M ji M Designer 3___________ | i > a . i , * . I J Object Uj c '^Elaborated Sent m essage ‘TaskAssign1 to Oesigner 1 Sent m essage 'TaskAsstgn' to Designer 1 Sent m essage 'TsskAssign' to Designer 3 S en t m essage 'Paraminfo’ to Designer 1 S e nt m essage ‘Paraminfo* to Designer 3 p a « % W \ S Figure 6-12: Screen dump - updated work-net Atllvt-PrfKeAs: Project AcfMty Work Net P ro ro ss ttetp 9 O Building B lotks ' - | 9 |B) A ctivity 9 S lA .2 V . : » <A2W1. K / W I -■ « A^.VllJB « A J W « d A .JW .1 ll -1 A JW .< Daj s - B a i ® - E 3 a j 9 0 3 Filter ' » " » • > *A1W.1 « - 4 A .1 .W ,1 0 AA.1.W ,1 m& .... Obfact_3J ; - 1 A XVI S « A..3.W I < A 3.W 0 I A 1 W ! - •A .J.W .1 0 ■ A A JI.W J 12 C o n A iu d ■I ■ •wprktiemerm- inisneci AA/fii'W-lomDntDofli^dTni lA wvCfVvU 1 1 Iv S jw y v ! W w l A Im I w 1 11 v 11 v \ v c3 v j i yt Received m essag e ’ WorkEiementFinlshgd’ | I y. ^ m essage 'Param ValueTransfer to D esigner 3 lent m essage 'ParamValueTfansfer1 to D esigner 2 lent m essage 'Param ValueTranster1 to D esigner 1 m essage 'ParamValueTransfer* to Designer 1 Figure 6-13: Screen dump - updated active-process Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. .............. P ioiprI AclMfy Work Net P rn to ss H H fci ^ S i u j i d l n g S I o c k s $ Activity i e S /L 2 D a j D a.2 D a.J D a j Daj D a.2 Daj D a .2 D a j D a .2 D a j D a j D a j . D a j D a .2 . ® -S a j 1> C 3 Filter ©•rl* 2 -a - i ©“ E 3 A 2 A 1 p eceiv ed m essage W orkElementFinished1 from Designer Sent m essage 'MustKnowParam* to Designer 2 • j [Received m essage W orkElementReadyToGd' from Desi£ jRecerved m essage WorkElementFinished' from D esigner 1 b e n t m essage 'ParamvalueTransfer* to D esigner 3 sen t m essage 'ParamvalueTransfer* to D esigner 2 Received m essage W orkElementReadyToGo' from Desig pi w Sent m essage ‘ParamvalueTransfer* to D esigner 1 Sent m essage ‘ParamvalueTransfer* to D esigner 1 |j ava Figure 6-14: Screen dump - the final product model Screen dumps Figure 6-11, 6-12, 6-13, and 6-14 show the interface of the updated tasks, work-net, active-process and the final product model. So far, we have illustrated how APS can be used to support the complete design and coordination process included in WSBA and provided screen dumps for some of the important design steps. Practically, the real engineering design work in Figure 6-10 should be conducted in a conventional CAD system, and the product model in Figure 6-14 should also be shown in that system. In the next section, we will show how a specific CAD system, AutoCAD Mechanical Desktop 5.0, can be hooked up with the APS. 141 ptujnct N a m g jObje c L l 1 ObteCt.11* Vatua IslAfUvvPfoces*: Mainframe. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.4 A Testing for A Real Design Scenario: Inner Front Door Design In the last section, the testing for the hypothetic BB design scenario focuses on how APS can support the coordination and adaptation of WSBA. In this section, we will test APS using a real design scenario, Inner Front Door Design, to show how a specific product model is linked with the process model AWPM, and the interactions between agents and the CAD system. 6.4.1 Link Between Product Model and AWPM The Inner Front Door Design scenario is provided by Toyota motor company. A detailed description of this scenario can be found in [1]. This design problem includes four design activities: 1) Design activity 1: design three cross sections in details based on the drawing of the Outer Panel which comes from a clay model made by a styling designer. 2) Design activity 2: design the positions of Door-Hinge and Check-link to avoid interference with the front fender when the door is open. 3) Design activity 3: design the positions of Lock-&-Striker and Seal, and modify the cross section of the front door in order to engage the Lock and the Striker well, and moreover, to seal the body and the front door well. 4) Design activity 4: design the positions of Door-Trim and plastic Rivets with which the Door-Trim is fastened to assure the physical durability. 142 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The detailed activity information is shown in Table 6-2. Table 6-2: Design activities of the Inner Front Door problem Design activity Input Output Cross section Parts Others A! 0 0 drawing of Outer Panel Cross Section: 1, 2,3 a 2 2 a: Door-Hinge 0 position of attachment: a, b b: Check-Link a 3 3 c: Lock-&-Striker 0 position of attachment: c, d d: Seal A 4 1,3 e: Door-Trim position of attachment: d position of attachment: e The geometry models for these activities are shown from Figure 6-15 to Figure 6-18. / 1 / __________ i A1_W3 Cross Sections Figure 6-15: Geometry model of design activity Ai /" / / / / / / / A2J/V1-* A2_W2 -► A2 W 3 ^ (a) Door-Hinge (b) Check-Link Figure 6-16: Geometry model of design activity A2 143 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. / / / / “ / / / / < --------- I I I I A3_W2 A3 W1 (c) Lock_&_Striker (d) Seal Figure 6-17: Geometry model of design activity A3 (e) Door-Trim A4 W Figure 6-18: Geometry model of design activity A4 The work-net for Inner Front Door Design problem is shown in Figure 6-19, and the work-element Information is briefly shown in Table 6-3. c b y m o d e l i / fw n Figure 6-19: Work-Net for the Inner Front Door Design Table 6-3: The work-elements of Inner Front Door Design Design Activity Work- Element pin pout Preceding work- element Time Taken (Days) As S Wi 0 Clay Model 0 0 A! Ai Wi Clay Model Cross Section 1 S Wi 1 Ai W2 Clay Model Cross Section 2 S Wi 1 Ai W3 Clay Model Cross Section 3 S Wi 2 144 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 6-3: The work-elements of Inner Front Door Design (Cont.) a 2 A2 W i Cross Section 2 Door-Hinge 1 Ai W2 2 a 2 w 2 Cross Section 2 Check-Link Ai W2 1 a 2 w 3 Cross Section 2 Door-Hinge 2 Ai W2 2 a 3 A3 W i Cross Section 1 Seal Ai Wi 2 a 3 w 2 Cross Section 1 Lock-&-Striker Ai Wi 3 a 4 A4 _W i Cross Section 1, Cross Section 3, Seal Door-Trim Ai Wi, Ai W3, A3 W i 3 Ae E_W i Door-Hinge 1, Check-Link, Door-Hinge 2, Seal, Lock-&- Striker, Door- Trim 0 A2 W i, a 2 w 2, a 2 w 3, A3 W i, a 3 w 2, A4 W i 0 6.4.2 Interaction Between Agents and AutoCAD In practical APS design environment, designers should carry out engineering design work in a conventional CAD system, and KICAD agent should be in charge of exchanging design information between this CAD system and the active-process server, and then the active-process server should further exchanges design information between KICAD agent and designer/manager’s agents, as shown in Figure 6-1. Therefore, a CAD system must be hooked up with APS, and the interaction between the KICAD agents and the CAD system must be reliable and easy to customize. In the prototype APS, we apply AutoCAD Mechanical Desktop 5.0 as the testing CAD system. The interaction between the KICAD agents and Mechanical Desktop 5.0 is shown in Figure 6-20. 145 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Internet KICAD Agent VBA W rapper AutoCAD Mechanical Desktop Active-Process Server Designer/ M anager’s Design Intei face Design cell Figure 6-20: Interaction between Agents and CAD in a design cell In Figure 6-20, the VBA (Visual Basic Application) wrapper is responsible to capture all design information and events taken place in the Mechanical Desktop, and report them to KICAD agent for further transmission. KQML (Knowledge Query and Manipulation Language) is used as the message vehicle for agents, server, and CAD to communicate with each other, and XML (Extensible Markup Language) is used to capture the contents of the communication. Figure 6-21: Screen dump - interface of Mechanical Desktop 5.0 146 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 6-21 shows the customized Mechanical Desktop interface for Inner Front Door Design case example. 6.4.3 A Result From The Testing We have tested APS for the Inner Front Door Design project with the help of the students in the author’s research lab. From the result, an evaluation can be made to compare the project lead-time with and without the support o f APS. As the comparison, a CPM chart for the testing example is shown in Figure 6- 22 and the CPM project lead-time can be calculated based on the information provided in Table 6-3, which is: T C pm = + m ax(r/M 2 ’ T dAI + ^DA4 ) = ^ 4 1 _ * n + ^Al_W2 + ^Al_W3 + m a X ( C < 2 _ F n + ^A2_W2 + *A2 _ W 3 ^ A3 _W\ + ^A3_W2 + ^ 4 _ F T l ) = 1 +1 + 2 + max(2 +1 + 2,2 + 3 + 3) = 4 + 8 = 12 {days) Figure 6-22: CPM chart for the testing example In the experiment done with APS, the optimal active-process developed for the testing example is shown in Figure 6-23, and the APS project lead-time is: T ap ~ ^ A \ _ W \ + m a x ( ^ 3 _ » ' l + ^A3_W2’ ^A3_IVl + *A4_W1’ *Al_W2 J r ^A\_W3 + ^ A 4 _ W \ ^ A\_W2 + ^A2_Wl + ^A2_W2 ^ ^ A 2 _ W 3 ) = 1 + max(2 + 3,2 + 3,1 + 2 + 3,1 + 2 + 1 + 2) = 7 (days) 147 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. clay m odel A. A , A, Legend: ^ work-element dependency design activity check point working- procedure time Figure 6-23: Optimal active-process for the testing example Thus, the time saved by APS compared with CPM method is: T - T 1 2 - 7 5 AT = -2= 2- = —— - = — = 41% T 12 12 cpm This number is significant as one of the major advantage of using APS. However, based on the observation, we notice that APS introduces a certain amount of overhead because of the required coordination process. Although it is hard to provide mathematical calculations for this part of time overhead, we feel that for less complex collaborative problems, i.e., each activity may only take minutes or several hours to finish, the introduced overhead for coordination may be significant and not worth, but, for those complex collaborative design problems, i.e., each activity may take days or even months to finish, APS has been proved efficient and effective. 6.5 System Evaluation and Discussion From the implementation point of view, the results of the system development and testing exhibit following successes of APS: 148 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1) It supports the whole design process of WSBA starting from the decomposition of a given task through the finishing of detail engineering design work. 2) It implements all the mechanisms and algorithms developed for work- element elaboration, work-net configuration and adaptation, and active- process collaboration and adaptation. 3) It applies advanced Internet technologies for realizing the system architecture which meets one major enterprises’ desire of pushing their products and software tools to web. 4) It provides means for engineering designers to effectively and efficiently work with intelligent agents in the traditional CAD design environment. 5) It improves concurrent engineering which significantly shorten project lead-time. There are three observations based the experiments of using APS. They are related to complexity, overhead, and integration, as discussed in the following. The first observation is about complexity. Structurally, the work-net provides a compendious visualization of the engineering work involved in the whole design problem. Because it captures and represents design information in a hierarchical way, i.e., activity and work-element as well as filter and dependency-element, the size o f the work-net will not become enormous even for very large-scale design problems. However, when apply this concise structured work-net for generating active-processes, the complexity problem becomes a major issue. In section 5.5.1, 149 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. we developed AP-Generating algorithm for generating all possible processes based on the work-net. This algorithms works good for our testing cases which normally include less then 10 activities and less then 30 work-elements in each activity. However, intuitively speaking, because the computational cost increases exponentially to the size of activities and, more crucially, to the average size of work-elements in activities, this algorithm is not very efficient for very complicated problems. In order to solve this complexity problem, there are three possible solutions. First, employ a super workstation as the active-process server to run this algorithm fast. Second, collect more restrictive rules in activity level or release more control power to responsible designers of the activities. By doing this the number of possible working-procedures of each activity will be limited so that the complexity problem can be handled at activity level rather than at project level. Third, replace the AP-Generating algorithm with a set of well designed coordination mechanisms and protocols so that the active-process can be mainly determined by negotiation processes. The second observation is about overhead. From the development and testing, we notice that certain overhead is inevitable by using APS for product development, i.e., the information load. Here we conclude two kinds of information load. The first one is coordination load because constructing the work-net and adapting the active-process requires coordination and communication between activities. The second one is modeling load since connecting and maintaining a consistent linkage between the process model and the product model requires data collection and 150 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. mining in CAD system. Fortunately, by the proposed system architecture, some of the load can be handled by intelligent agents who take little time to collect information and pass them to one another. This already saves a big amount o f time for designer so that they can focus on value-adding work that demands creativity and innovation. In the current development, designers are only involved in the initial work setting, i.e., feed in the parameter set Pi and input parameter set PIN i o f each activity, and critical decision making situations. Except these, the work-element operations to elaborate engineering work in each activity, the work-net algorithms to construct and update the work-net under new situations, and active-process algorithms to determine and update the working process are all automated by agents. The third observation is about integration. The prototype APS is formed by three major parts of programs. The first part is active-process system itself, which includes the programs of web server, active-process server, active-process database, designer’s agent, and manager’s agent. The second part is KICAD agent and the third part is customized CAD system. The KICAD agent and the customized CAD system are developed in the author’s research laboratory for general purpose. From the experience of integrating these separate parts of codes to the prototype APS, the interface between the customized CAD system and the agent becomes a significant issue. The major industrial CAD systems, such as AutoCAD and I-deas, provide very weak interface to independent customer’s programs. In current implementation, we apply socket communication technique to exchange information between CAD and agent by a VBA program. However, it does not work reliably and consistently. 151 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. For example, the contents and frequency of the information transferring are limited, and the installation and customization is hard and machine dependent. When we push APS to real industrial applications, a better way to interact with CAD systems must be further explored. 6.6 Summary In this chapter, we discussed the implementation issue of WSBA. A prototype Active-Process System was developed. We presented the web-based, server/client- configured and agent-distributed system architecture which includes seven major components, namely, Web Server, Active-Process Server, Active-Process Database, Manager’s Agent, Designer’s Agent, KICAD Agent, and CAD System. We used Java language to program the system so that it has the same functionality and presentation in different platforms. We further tested the system using two design scenarios. In the Building Blocks testing, we verified how APS can be used to support the coordination and adaptation features of WSBA, and in the Inner Front Door Design testing, we showed how AWPM can be linked to a real product model, and how a CAD system can be hooked up with APS. A detailed evaluation and discussion about the system was provided. In the next chapter, we will conclude this thesis and suggest the directions for future work. 152 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7 Contributions and Future Work In this chapter, we conclude this thesis by highlighting its contributions, and then point out the opportunities for future work to advance this research. 7.1 Contributions This thesis provides a comprehensive framework for understanding the nature of collaborative engineering design process. Three major contributions can be made on the areas of collaborative engineering design methodology, engineering process modeling, and software system development. 7.1.1 On Collaborative Engineering Design Methodology The first major contribution of this thesis is on collaborative engineering design methodology. Most design methodologies developed up to date are problem- driven which emphasize finding good solutions based on functional requirements. This is very useful for less-complex design problems which can be done by an individual or a very small group of people. Prior to this research, the collaboration aspect of design methodology for large-scale design problems has not been well recognized and studied. The specific points of this thesis for collaborative engineering design methodology are as following. First, we defined a conceptual framework for collaborative engineering design and characterizing its requirements. Our three-level process-driven work paradigm is conceptually defined at three levels. They are enterprise level learning, project 153 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. level adaptation, and engineering level collaboration. Conceptual components and operations are defined and organized for supporting design and management activities in the whole product development lifecycle. Design theories, product and process models, communication techniques, and supporting software systems and tools can be developed as the surroundings of this conceptual framework. Second, we proposed a new approach for collaborative engineering design. This new approach, Work Structure Based Approach, combines management methods from business field and engineering methods from design field. In current practice, the uses of the workflow and the product model are isolated. On one hand, managers do planning based on the workflows without knowing much of engineering details. And on the other hand, designers do engineering work based on product models without knowing the other activities. This isolation causes the efficiency problem and the flexibility problem. The proposed Work Structure Based Approach successfully solves the isolation problems, drives collaborative design from both sides of management and engineering, and provides foundations and means for the managers and designers to collaborate in order to improve the coherency, efficiency, and adaptability. Third, we formalized detailed steps involved in the process of Work Structure Based Approach. These steps start from task decomposition for a given task, develop the process and product with unique concepts of work-element, work-net, and active-process, and end up with adaptation loops for the process and product. They are applicable to many types of collaborative design problems, no matter in 154 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. what specific field. Moreover, they are compatible with the concepts, methods, and findings of other disciplines. With slight changes and modifications, the steps originally developed for solving collaborative design problems in mechanical engineering domain can be applied for other domains where collaboration is highly demanded such as electronic design projects, computer software developments, business organizations, etc. 7.1.2 On Engineering Process Modeling The second major contribution of this thesis is on engineering process modeling. Most state-of-art process modeling technologies have either rich representation capability or impressive analysis power, however, prior to this research, the issues of adaptation aspect of process modeling for large-scale engineering problems have not been addressed. The specific points of this thesis for engineering process modeling are as following. First, we established the work-element concept to link specific product information to the general process model, Active Work and Process Model. Corresponding operations for work-element elaboration are provided. We believe it is limited to exclude specific engineering details from a process model. In order to support activity level engineering work and coordination in a project level managerial context, the product data must be linked with the process. Thus, on one hand, work-element concept is introduced as a unit of engineering work which can be explicitly linked to a specific product part and component, and on the other hand, 155 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. it is a unit of management element which can be used to compose processes and move the process analyses into a lower level than activity. Second, we developed the work-net concept to capture engineering level dependencies. Corresponding algorithm for work-net configuration is provided. In order to generate and optimize engineering processes for a given task and find out opportunities for concurrent engineering, lower level engineering dependencies, rather than activity level precedence relations, must be captured. A work-net represents detailed work-element information in activity nodes and encapsulates work-element dependencies in filter nodes. The work-net itself is not an engineering process and it does not specify any fixed process. Instead, it provides a complete setting of engineering work and dependencies that can be used to generate all feasible engineering processes for a specific task. Third, we introduced the active-process concept to generate, represent, simulate, analyze, and coordinate engineering processes. Corresponding algorithms for active-process collaboration and adaptation are provided. Although multiple engineering processes can be generated from the work-net, the execution process for a given task is not arbitrarily given by the manager who masters less engineering knowledge than participating designers. The enactment of the execution process must go through two steps: first, the project manager must do certain simulations and analyses on the processes, and second, designers should coordinate with each other and finally determine the execution process. 156 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Forth, we provided means to adapt to environmental changes and technological changes. This is the most important feature of Active Work and Process Model. Both the work-net and the active-process are functions of time “t”. Work-Net adaptation is essential for industry enterprises to deal with global competition which requires rapidly development and update of new products for market needs and customer satisfactions. Correspond algorithms for work-net adaptation are provided. Active-Process adaptation is essential for a product development to assure the project lead-time and budget when recourse exceptions and design mistakes occur during the process execution. The algorithms developed for active-process collaboration and adaptation can also be used for this purpose. 7.1.3 On Software System Development The third major contribution of this thesis is bn software system development. Recently, although engineering design environment has been improved due to the fast growing of computer technologies and many management software packages have been developed for specific purposes, prior to this research, a comprehensive system for supporting collaborative engineering design has not yet been designed and developed. The specific points of this thesis for software system development are as following. First, we explored a web-based, server/client-configured and agent-distributed system architecture for collaborative engineering design. This system architecture is designed based on three major requirements. First, it can be implemented on the basis of the proposed conceptual framework, the process-driven work paradigm. 157 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Second, it should support the proposed Work Structure Based Approach from the decomposition o f a given task through the actual embodiment engineering design. Third, it should be able to take the advantages of advanced information technologies for more effective product development without breaking down the traditional design environment, i.e., on one hand, it should meet the major enterprises’ desire of pushing their products and software tools to Internet, and on the other hand, it should keep engineering designers work with traditional CAD system. Second, we developed intelligent software agents to handle both design information and coordination. To date, intelligent agents have been extensively developed in many areas. However, current applications of agents are restricted in information access and filtering, electronic commerce, system and network management, and so on. The agent technologies have not been adopted in the engineering design area. In this thesis, we sketch the blueprint on how agents can be successfully used in collaborative engineering design to support the collaboration. In our framework, designers are focusing on engineering details and only involved in critical decision situations. It is the agents who really coordinate with each other to capture the engineering dependencies and determine the working process. Third, we developed a prototypes system which has potentials for industrial applications. The whole system is programmed by Java language which is compatible for most popular platforms so that the testing has been done in different enterprise environment. Through the testing, it shows that the prototype APS successfully supports the whole process of WSBA, implements all the algorithms 158 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and mechanisms developed based on AWPM, applies advanced information technologies for management and design, provides reliable communication and coordination means for designers, and improves the efficiency and effectiveness for large-scale collaborative engineering design. 7.2 Future Work Future work can be along both academic and practical directions. In this section, we identify four issues that can be addressed in the future. First, explore the issues and technologies for enterprise learning. On the design methodology area, referring to the three-level work paradigm, we have addressed the major issues in the engineering level collaboration loop and the project level adaptation loop. However, we have not yet investigated the topics in the enterprise learning loop. In order to realize the whole conceptual framework, many issues should be addressed and research should be done, e.g., what are the critical issues of knowledge accumulation, organization, adaptation, creation and application, how to develop a knowledge management system for enterprises’ success, etc. Second, enhance the analysis ability of Active Work and Process Model. On the process modeling area, comparing with the strong representative power of this model, its analysis ability has not been fully mined out although it shows great potentials. Because the graph view of this model is consisted by a typical networking topology, we can possibly borrow many existing networking 159 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. technologies to analyze the features of a work-net, e.g., how to measure the complexity of a work-net, what are critical activities that are prone to failure, how to manage work-elements in different granularities, etc. Third, develop more functionality for intelligent agents. On the system development area, intelligent agents have been successfully applied in APS, e.g., identifying and elaborating engineering work, monitoring and propagating design events, providing reminders for human beings, etc. However, in the current implementation their functions are still limited for real industry applications. More knowledge based functions should be developed and implemented into the agents, e.g., bringing relevant design knowledge to designers when needed, providing and ranking available choices for certain decision situations, etc. Forth, further validate this thesis with more real world experiments. In order to justify our proposed Work Structure Based Approach, we have done many simulative and synthetic experiments, such as Building Blocks case study and the Inner Front Door Design project. We are satisfied with the results of these experiments. However, the real world experiments are very hard to be conducted as a part of validation for this thesis, because hundreds of activities and designers are involved in typical real world projects in the collaborative engineering design field. We will promote our system to real industry application with the help o f our sponsors, and gather essential feedbacks for further validation o f this thesis. 160 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Bibliography [1] Araki, H. (2000) “A Study of Collaborative Environment for Product Development Process Innovation,” Doctoral Thesis, University of Tokyo [2] Baluja, S. and Davies, S. (1997) “Combining Multiple Optimization Tuns with Optimal Dependency Tree” [3] Benami, O. (2002) “A Cognitive Approach to Creative Conceptual Design,” Ph.D. Dissertation, Mechanical Engineering Department, University o f Southern California [4] Binnard, M. and Cutkosky, M. R. (2000) "A Design by Composition Approach for Layered Manufacturing," in ASME Transactions, Journal of Mechanical Design, Spring [5] Bowen, J. (1997) “Using Dependency Records to Generate Design Coordination Advice in a Constraint-Based Approach to Concurrent Engineering,” Computers in Industry, 33, 191-199 [6] Braha, D. and Maimon, O. (1997) “The Design Process: Properties, Paradigms, and Structure,” IEEE Transactions on Systems, Man, and Cybemetics- Part A: Systems and Humans, 27(2), 146-166 [7] Bras, B. F. (1991) “Designing Design Processes in Decision-Based Concurrent Engineering,” 1991 SAE International Warrendale, Pennsylvania [8] Cai, J. (2001) “A Socio-Technical Approach to Support Collaborative Engineering Design,” Ph.D. Dissertation, Mechanical Engineering Department, University of Southern California [9] Campos, L. M. (1996) “Characterizations of Decomposable Dependency Models,” Journal of Artificial Intelligence Research, 5, 289-300 [10] Carley, K. M. (1991) “Designing organizational structures to cope with communication breakdowns: a simulation model,” in Industrial Crisis Quarterly, Vol. 5, pp.19-57 [11] Cutkosky, M. R. (1990) “A Methodology and Computational Framework for Concurrent Product and Process Design,” in Mechanism and Machine Theory, 25/3, pp.365-381 161 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [12] Cutkosky, M. R., Glicksman, J. and Tenenbaum, J. M. (1996) “MadeFast: Collaborative Engineering Over the Internet,” Communications of the ACM, Vol. 39, No. 9,1996, pp. 78-87 [13] Danesh, M. R. D. (2001), “A Framework for Value-Based Conceptual Engineering Design,” Ph.D. Dissertation, Mechanical Engineering Department, University of Southern California [14] Duntsch, I. and Gediga, G. (1997) “Statistical Evaluation of Rough Set Dependency Analysis,” International Journal of Human-Computer Studies, 46, 589- 604 [15] Eppinger, S. D., Nukala, M. V. and Whitney, D. E. (1997) “Generalised Models of Design Iteration Using Signal Flow Graphs,” Research in Engineering Design, 9,112-123 [16] Eppinger, S. D. and Salminen, V. (2001) “Patterns of Product Development Interactions,” International Conference on Engineering Design, Glasgow, Scotland, Auguest [17] Finger, S. and Dixon, J. R. (1989a) “A Review of Research in Mechanical Engineering Design. Part I: Descriptive, prescriptive and computer-based models of design processes,” Research in Engineering Design, 1, 51-67 [18] Finger, S., and Dixon, J. R. (1989b) “A Review of Research in Mechanical Engineering Design. Part II: Representations, Analysis, and Design for the Lige Cycle,” Research in Engineering Design, 1, 121-137 [19] Gebala, D. A. and Eppinger, S. D. (1991) “Methods for analyzing design procedures,” in L. Stauffers LA (ed) Design Theory and Methodology, ASME, Miami, pp.227-232 [20] Geiger, D. J. (1993) “Logical and Algorithmic Properties of Conditional Independence and Graphical Models,” The Annals o f Statistics, 21(4), 2001-2021 [21] Gorti, S. R. and Sriram, D. (1994) “A Symbol-form Mapping Framework for Conceptual Design Support,” Proceedings of the 1st International Conference on Computing in Civil Engineering, ASCE 1591-1598, Washington D.C [22] Hammer, M. and Champy, J. (1993) “Reengineering the Corporation: a manifesto for business,” HarperBusiness [23] Hauser, J. R. and Clausing, D. P. (1988) “The House of Quality,” Harvard Business Review, Vol. 66, pp. 63-73, May-June 162 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [24] Jasnoch, U., Alok, S. K., and Haas, S. (1995) “A Collaborative Environment Based on Distributed Object-Oriented Databases,” Proceedings of the Fourth Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, IEEE Computer Society, April 20-22 [25] Jensen, K. (1996) “Coloured Petri-nets”, Springer, New York [26] Jin, Y., Kunz, J. and Levitt, R. E. (1997) “Object-Oriented Enterprise Modeling and Simulation of AEC Projects,” Microcomputers in Civil Engineering, 12,157-170 [27] Jin, Y. and Levitt, R. E. (1996) “The Virtual Design Team: A Computational Model of Project Organizations,” Computational & Mathematical Organization Theory, 2(3), 171-196 [28] Jin, Y. and Lu, S. (1998a), “An Agent Supported Approach to Collaborative Design,” CIRP Annals, 47(1) [29] Jin, Y. and Lu, S. (1998b) “Toward a Better Understanding of Engineering Design Models,” In Universal Design Theory (73-84), Shaker Verlag [30] King, A. M. (1999) “Development of a Methodology for Concept Selection in Flexible Design Strategies,” Journal of Engineering Design, 10(4), 329-349 [31] Klein, M. (1996) “Conflict management as part of an integrated exception handling approach,” (AI EDAM) Artificial Intelligence for Engineering Design, Analysis and Manufacturing, vol9, no4, p259-267 [32] Kuokka, D. R. (1995) “Communication Infrastructure for Concurrent Engineering,” Artificial Intelligence in Engineering Design, Analy and Manufacturing, 9,283-297 [33] Kusiak, A. N. (1995) “Decomposition and Representation Methods in Mechanical Design Transactions,” Transactions of the ASME, Special 50th Anniversary Design Issue, 117, 17-24 [34] Lansdown, J. (1987) “The Creative Aspects of CAD: A Possible Approach,” Design Studies, 8(2), 76-81 [35] Lewis, K. F. (1998) “Collaboratice, Sequential, and Isolated Decisions in Design,” Journal of Mechanical Design, 120, 643-652 [36] Lockledge, J. C. (1999) “Defining the Engine Design Process,” Journal of Engineering Design, 10(2), 109-124 163 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [37] Lu, S. and Baskin, A. (1993) “SWIFT: System Workbench for Integrating and Facilitating Teams,” Proceedings of the Second Workshop on Enabling Technologies for Collaborative Enterprises [38] Maher, M. L. (1990) “Process Models for Design Synthesis,” AI Magazine, 11(4), 49-58 [39] Maimon, O. and Braha, D. (1996) “On the Complexity of the Design Synthesis Problem,” IEEE Transactions on Systems, Man, and Cybemetics-Part A: Systems and Humans, 26(1), 142-160 [40] Malone, T. W. (1994) “The Interdisciplinary Study of Coordination,” ACM Computing Surveys, 26(1) [41] Mayer, R. J. and Menzel, C. P. (1991) “IDEF3 Technical Report,” WPAFB, OH: AL/HRGA [42] Mayer, R. J. and Menzel, C. P. (1998) “The IDEF Family of Languages,” Handbook on Architectures for Information System, Springer-Verlag, 1998, pp. 209- 241 [43] Mcmahon, C. A. (1996) “A Network Approach to Parametric Design Integration,” Research in Engineering Design, 8,14-32 [44] Medina-Mora, R. (1992) “The Action Workflow Approach to workflow Management Technology”, CSCW 92 Proceedings [45] Medina-Mora, R. and Cartron, K. W. (1996) “ActionWorkflow in Use: Clark County Department of Business License,” ICDE 1996, pp. 288-294 [46] Menzel, C. and Benjamin, P. C. (2001) “An Adaptive Process Management System (APMS),” Global Engineering, Manufacturing and Enterprise Networks, Boston, Kluwer Academic Publishers [47] Mistree, F. (1997) “Optimization in Decision-Based Design Position Paper,” Open Workshop on Decision-Based Design Orlando, Florida [48] Mueller A. R. and Varghese, J. (1985) “Knowledge-Based Code Selection Methods in Retargetable Microcode Synthesis,” IEEE Design and Test, 44-55 [49] Nilsson, N. J. (1991) “Logic and Artificial Intelligence,” Artificial Intelligence, 47, 31-56 [50] Pahl, G. and Beitz, W. (1996) “Engineering Design, A Systematic Approach,” Springer, 2n d ed. 164 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [51] Park, H. (1999) “Framework for Modeling Dependencies in Collaborative Engineering Processes,” Research in Engineering Design, 11, 84-102 [52] Park, B. C., Baldwin, F. D. and Suh, P. N. (1996) “Axiomatic Design of a Microcellular Filament Extrusion System,” Research in Engineering Design, 8, 166- 177 [53] Park, H. and Cutkosky, M. R., (1994) “An Agent-Based Approach to Concurrent Cable Harness Design,” Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 8, March, pp.45-61 [54] Parunak, H. V., Ward, A., Fleischer, M. and Sauter, J. (1997) “A Marketplace of Design Agents for Distributed Concurrent Set-Based Design,” RAPPID 97-1 [55] Parunak, H. V., Ward, A., Fleischer, M., Sauter, J. and Chang, T. (1997) “Distributed Component-Centered Design as Agent-Based Distributed Constraint Optimization,” AAAI'97 Workshop on Constraints and Agents [56] Parunak, H. V., Ward, A. and Sauter, J. (1998) “A Systematic Market Approach to Distributed Constraint Problems,” Proceedings of ICMAS [57] Pena-Mora, F., Sriram, R. D. and Logcher, R. (1996) “Conflict mitigation system for collaborative engineering,” (AI EDAM) Artificial Intelligence for Engineering Design, Analysis and Manufacturing, vol. 9, no2, plOl-124 [58] Peterson, J. L. (1993) “Petri-net Theory and The Modeling of Systems,” Prentice Hall, Englewood Cliffs, NJ [59] Proth, J. M. and Xie, X. L. (1994) “PETRI NETS: A Tool for Design and Management of Manufacturing Systems”, Wiley, West Sussex, England [60] Pugh, S. (1990) “Total Design: Integrated Methods for Successful Product Engineering,” Addison-Wesley [61] Raines, T., Tambe, M., and Marsella, S. (2000) “Automated agents that help humans understand agent team behaviors, ” Proceedings of the International conference on Autonomous, Agents [62] Reich, Y. (1991) “Design Knowledge Acquisition: Task Analysis and a Partial Implementation,” Knowledge Acquisition, 3(3), 237-254 [63] Reich, Y. (1995a) “A Critical Review of General Design Theory,” Research in Engineering Design, 7,1-18 [64] Reich, Y. (1995b) “The Study of Design Research Methodology,” Journal of Mechanical Engineering, 117, 211-214 165 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [65] Reich, Y., Konda, S., Levy, S. N., Monarch, I., and Subrahmanian, E. (1993) “New roles for machine learning in design,” Artificial Intelligence in Engineering, 8(3), 165-181 [66] Reich, Y., Konda, S., Levy, S. N., Monarch, I. and Subrahmanian, E. (1996) “Varieties and Issues of Participation and Design,” Design Studies, 17(2), 165-180 [67] Rene D. and Alla, H. (1992) “Petri-nets & Grafcet”, Prentice Hall, New Jersey [68] Richardson, T. (1996a) “A Discovery Algorithm for Directed Cyclic Graphs,” In Horvitz, E. and Jensen, F., In Proceedings of the 12th Conference on Uncertainty in Artificial Intelligence [69] Richardson, T. (1996b) “A Polynomial-Time Algorithm for Deciding Markov Equivalence of Directed Cyclic Graphical Models,” In Horvitz, E. and Jensen, F., In Proceedings of the 12th Conference on Uncertainty in Artificial Intelligence Morgan Kaufmann, San Francisco, CA [70] Rudolph, S. (1996) “Upper and Lower Limits for ‘The Principles of Design’,” Research in Engineering Design, 8,207-216 [71] Sarma, S. E. (1997) “Decision Monotonicity in Incremental Design: A Case Study of Design for Manufacture,” Research in Engineering Design, 9, 235-245 [72] Shachter, D. R. (1986) “Evaluating Influence Diagrams,” Operations Research, 34(6), 871-882 [73] Shafer, G. (1987) “Probability Judgment in Artificial Intelligence and Expert Systems,” Statistical Science, 2(1), 3-16 [74] Shimomura, Y., Takeda, H., Yoshioka, M., Umeda, Y. and Tomiyama, T. (1995) “Representation of Design Object Based on The Functional Evolution Process Model,” Proceedings of Design Theory and Methodology, ASME [75] Shimomura, Y., Tanigawa, S., Takeda, H., Umeda, Y., and Tomiyama, T. (1996) “Functional Evaluation Based on Function Content,” Proceedings of Design Theory and Methodology ASME [76] Simon, H. A. (1973) “The Structure of 1 1 1 Structured Problems,” Artificial Intelligence, 4, 181-201 [77] Smith, R. G. (1988) “The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver,” A.H. and Gasser, L. (Eds), “Readings in Distributed Artificial Intelligence,” 357-366, Morgan Kaufmann Publishers, Los Altos, CA 166 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [78] Spirtes, P. (1995) “Directed Cyclic Graphical Representation of Feedback Models,” In Besnard, P. and Hanks, S., Proceedings of the Eleventh Conference on Uncertainty in Artificial Intelligence San Mateo, Morgan Kaufmann Publishers, Inc [79] Spirtes, P., Rochardson, T., Meek, C., Schemes, R. and Glymour, C. (1996) “Using D-separation to Calculate Zero Partial Correlations in Linear Models with Correlated Errors,” Technical Report CMU-72-Phil [80] Sriram, D. and Logcher, R. (1993) “The MIT DICE project,” in Computer, Vol. 26, No. 1, Jan [81] Steward, D. V. (1981) “The Design Structure System: A Method for Managing the Design of Complex Systems,” IEEE Transaction on Engineering Management, EM-28(3), 71-74 [82] Sturges, R. H., O'Shaughnessy, K. and Kilani, M. I. (1996) “Computational Model for Conceptual Design Based on Extended Function Logic,” Artificial Intelligence in Engineering Design, Analysis and Manufacturing, 10, 255-274 [83] Suh, N. P. (1995a) “Axiomatic Design of Mechanical Systems,” Transactions of the ASME, 117,2-10 [84] Suh, N. P. (1995b) “Trends and Perspectives - Design and Operation of Large Systems,” Journal of Manufacturing Systems, 14(3), 203-213 [85] Svensson, D., Malmstrom, J., Pikosz, P. and Malmqvist, J. (1999) “A Framework for Modeling and Analysis Engineering Information Management Systems,” Proceedings of the 1999 ASME Design Engineering Technical Conferences Las Vegas, Nevada, ASME [86] Takeda, H. (1994) “Abduction for design,” In J.S. Gero and E. Tyugu, Formal Design Method for CAD, IFIP Transactions, B-18, 221-244. Amsterdam: Elsevier Science Publishers B.V [87] Takeda, H., Takaai, M. and Nishida, T. (1998) “Collaborative Development and Use of Ontologies for Design,” Proceedings of the Tenth International IFIP WG 5.2/5.3 Conference [88] Tambe, M. and Adibi, J. (1999) “Building agent teams using an explicit teamwork model and learning,” Artificial Intelligence, volume 110, pages 215-240 [89] Tate, D. (1996) “A Design Process Roadmap as a General Tool for Structuring and Supporting Design Activities,” Proceedings of the Second World Conference on Integrated Design and Process Technology Society for Design and Process Science (97-104), Austin, TX 167 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [90] Tomiyama, T. (1995) “A Design Process Model that Unifies General Design Theory and Empirical Findings,” 1995 Design Engineering Technical Conferences, 2, ASME [91] Ullman, G. D., Herling, D. and D'Ambrosio, B. (1997) “What to Do Next: Using Problem Status to Determine the Course of Action,” Research in Engineering Design, 9, 214-227 [92] Wang, C. (1997) “A Preliminary Review of Works by Farrokh Mistree on Models for Design” [93] Wang, K. L. (2002) “An Analytical Approach to Functional Design,” Ph.D. Dissertation, Mechanical Engineering Department, University o f Southern California [94] Wang, K. L. and Jin, Y. (1999) “Modeling Dependencies in Engineering Design,” Proceedings of the 1999 ASME Design Theory and Methodology Conference Las Vegas, Navada, ASME [95] Wang, K. L. and Jin, Y. (2000) “Managing Dependencies in Engineering Design,” Proceedings of the 2000 ASME Design Theory and Methodology Conference, Baltimore, Maryland, ASME [96] Wilkins, D. E. and Myers, K. L. (1998) “A Multi-Agent Planning Architecture,” Proceeding of A IPS-98,154-162, June [97] Yassine, A. A. (1999) “A Framework for Design Process Specifications Management,” Journal of Engineering Design, 10(3), 223-234 [98] Yoshikawa, H. (1981) “General Design Theory and a CAD System,” In Man- Machine Communication in CAD/CAM (35-58), North-Holland Publishing Company [99] Yoshioka, M. (1999) “Toward a Reasoning Framework o f Design as Synthesis,” Proceedings of the 1999 ASME Design Theory and Methodology Conference Las Vegas, Nevada, ASME [100] Zahedi, F. (1986) “Group Consensus Function Estimation When Preferences Are Uncertain,” Operations Research, 34(6), 883-894 168 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

A socio-technical approach to support collaborative engineering design

PDF

A hierarchical co-evolutionary approach to conceptual design

PDF

An analytical approach to functional design

PDF

A cognitive approach to creative conceptual design

PDF

Cognitive modeling of iteration in conceptual design

PDF

A document-driven approach to conceptual design

PDF

Investigation of a switching G mechanism for MEMS applications

PDF

A framework for value -based conceptual engineering design

PDF

Collaborative negotiation for early stage parametric design of mechanical systems

PDF

Investigation of several important phenomena associated with the development of Knudsen compressors

PDF

Experimentation and analysis of contour crafting (CC) process using uncured ceramic materials

PDF

Extending the COCOMO II software cost model to estimate effort and schedule for software systems using commercial -off -the -shelf (COTS) software components: The COCOTS model

PDF

General and explicit equations of motion for mechanical systems

PDF

Automotive engine model linearization

PDF

Hybrid scheduling methods for the general routing problem

PDF

A biologically inspired DNA-based cellular approach to developing complex adaptive systems

PDF

Design-for-reliability starting from conceptual design

PDF

A global study of nonlinear dynamical systems by a combined numerical-analytical approach

PDF

Full-scale experimental and analytical studies on high -strength concrete columns

PDF

Coordinating multiagent teams in uncertain domains using distributed POMDPs

Asset Metadata

Creator Zhao, Li (author)

Core Title A work structure based approach to collaborative engineering design

School Graduate School

Degree Doctor of Philosophy

Degree Program Mechanical Engineering

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag engineering, mechanical,OAI-PMH Harvest

Language English

Contributor Digitized by ProQuest (provenance)

Advisor Jin, Yan (committee chair), Bukkapatnam, Satish (committee member), Muntz, Phil (committee member), Shiflett, Geoffrey (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c16-267747

Unique identifier UC11339345

Identifier 3093950.pdf (filename),usctheses-c16-267747 (legacy record id)

Legacy Identifier 3093950.pdf

Dmrecord 267747

Document Type Dissertation

Rights Zhao, Li

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA