University of Southern California Dissertations and Theses

An argumentation-based approach to negotiation in collaborative engineering design

(USC Thesis Other)

An argumentation-based approach to negotiation in collaborative engineering design

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content AN ARGUMENTATION-BASED APPROACH TO NEGOTIATION IN COLLABORATIVE ENGINEERING DESIGN by Mathieu M. Geslin 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) August 2006 Copyright 2006 Mathieu M. Geslin ii Dedication To my parents Michel and Michèle and to my fiancée Bahar, for their unconditional love, support and continued encouragements throughout this journey. iii Acknowledgements First and foremost, I would like to express my deepest gratitude to my Ph.D. advisor Yan Jin, who provided me his guidance, continued support and encouragements. Yan has been an outstanding mentor and taught me a great deal through long hours spent in his office arguing and refining concepts, ideas and views on research matters as well as more casual topics. He always encouraged me to strive for clarity, logic and to challenge the obvious to achieve sound results in my work. Working with Yan on this research made me realize that there is no substitute for hard work and I vow to apply this precept in everything I endeavor in my future. I would like to acknowledge the members of my committee: Dr. Ron Blackwelder, Dr. Stephen C-Y. Lu, Dr. Geoffrey Shiflett and Dr. Maria Yang. Their constructive comments and criticisms during my qualifying proposal and on other occasions proved invaluable and helped me perfect my work and keep it on track. I would like to thank each of them for their help. I wish to particularly thank Dr Shiflett, whom I had the opportunity to help as a TA for his Dynamics and Computer-aided design classes. I hope to share some crêpes with you again soon. Next, I would like to thank the USC Mechanical Engineering School staff. I am thankful for the great availability and diligence of Silvana Martinez, the invaluable help of Marietta Penoliar, who enabled me to carry out the experiments described in this work in the best conditions possible. iv I would like to acknowledge my colleagues from the Impact Laboratory as well, who, through formal and informal discussions have helped me refine this work, and whose company I have enjoyed over the years: Dr. Pawat “Tum” Chusilp, Dr. Wei Li, Nishant Dikshit, Dae-Hwan Kim, Jieying “Jane” Zhang, Nan Jin, Qingfeng “Anna” Li, Hung Fu “Aaron” Chang, George Zouein, Sebastian Kernbaum, Hui “Daisy” Wang, Dr. Mohammed Reza Danesh and Dr. Li Zhao. Special thanks go to Shih-Wei “George” Chen for his invaluable contribution to the experiment phase of this research. He spent countless hours of his busy life of undergraduate student exploring with me the intriguing activity of collaborative engineering design and negotiation. I hope this experience will encourage him to pursue graduate work at USC. I am confident he will achieve great things. Finally, I would like to thank all my family and friends for their support and the fact that they never stopped believing in me, when I myself doubted. My parents, Michel and Michèle, and my brother Benoit were here for me every step of the way despite the distance. I would like to thank the Dutt family, Kumkum, Raj and Ashutosh for welcoming me as a member of their wonderful family, and giving me continued love and support. I would like to acknowledge Mary Ellen Hall and Jim Hallett, who first welcomed me in their home in the summer of 1995 and have treated me like their son ever since. Thank you so much for your love and support, you changed my life forever. v Last but not least, I would like to thank my wife-to-be, Bahar, whose unconditional love, care and attention helped me surpass the goals I had set for myself and make me a better person. Thank you, without you, none of this would have been possible. vi Table of Contents Dedication......................................................................................................................ii Acknowledgements ......................................................................................................iii List of Tables................................................................................................................ix List of Figures ..............................................................................................................xi Abbreviations.............................................................................................................xiii Abstract ......................................................................................................................xiv Chapter 1: Introduction...............................................................................................1 1.1 Background and motivations............................................................................1 1.2 Research problem and approach .....................................................................4 1.3 Thesis overview ..................................................................................................6 1.4 Thesis Organization...........................................................................................9 Chapter 2: Related work............................................................................................12 2.1 Introduction......................................................................................................12 2.2 Collaborative Engineering ..............................................................................14 2.2.1 Information modeling ...............................................................................14 2.2.2 Conflict management................................................................................15 2.2.3 Negotiation in collaborative engineering design ......................................17 2.2.4 TRIZ: How to resolve contradictions in creative problem solving ..........20 2.2.5 Robust design and tolerance synthesis .....................................................22 2.3 Negotiation in Social and Decision Science ...................................................23 2.3.1 Organizational conflict .............................................................................23 2.3.2 Economics and Game Theory...................................................................25 2.3.3 Legal issues...............................................................................................26 2.3.4 Negotiation Analysis ................................................................................28 2.3.4.1 The PrOACT way of thought ........................................................28 2.3.4.2 Joint Decision Making ..................................................................31 2.3.4.3 Distributive vs. Integrative negotiation.........................................32 2.4 Multi-Agent Systems and computer-supported activities............................33 2.4.1 Agent-based systems ................................................................................33 2.4.2 Negotiation Protocols ...............................................................................35 2.4.3 Argumentation-based Negotiation............................................................38 2.4.3.1 Languages......................................................................................39 2.4.3.2 Negotiation protocol......................................................................41 2.4.3.3 Information store ...........................................................................42 vii 2.4.4 Computer Supported Cooperative Work (CSCW) ...................................43 2.4.5 Computer Supported Collaborative Learning (CSCL) .............................45 Chapter 3: Issues in collaborative engineering design............................................47 3.1 Need for a new approach ................................................................................47 3.2 Research challenges.........................................................................................49 3.2.1 Challenges at the theoretical level ............................................................49 3.2.2 Challenges at the implementation level....................................................51 Chapter 4: ANED, an Argumentation-Based Negotiation framework for Engineering Design.....................................................................................................53 4.1 Overview of the approach...............................................................................53 4.2 Design Context Modeling................................................................................55 4.2.1 Design Context .........................................................................................55 4.2.2 Value and Design objectives ....................................................................62 4.2.3 Decision History Tree...............................................................................69 4.2.4 Design conflicts and Joint Design Decision .............................................73 4.3 Argumentation-based negotiation..................................................................77 4.3.1 Argument model .......................................................................................77 4.3.2 ABN Protocol ...........................................................................................81 4.3.3 ZOPA, strategies and strategy selection ...................................................86 4.4 A case study example: Trunk design problem..............................................98 4.4.1 Scenario and hypotheses...........................................................................98 4.4.2 Resolution...............................................................................................103 4.4.2.1 Parametric Value / Solution Level negotiation (Scenario 1).......103 4.4.2.2 Objective Level exploration (Scenario 2) ...................................106 4.4.2.3 Objective-level Negotiation and task redefinition for Innovative Ideas generation (Scenario 3)..................................................................109 4.5 Conclusions and remarks..............................................................................116 Chapter 5: Impact of an Argumentation-based Negotiation approach on collaborative Engineering Design ...........................................................................118 5.1 Experiment introduction...............................................................................120 5.1.1 Objectives ...............................................................................................120 5.1.2 Hypotheses..............................................................................................121 5.1.3 Experimental design ...............................................................................123 5.1.3.1 Treatments...................................................................................123 5.1.3.2 Statistical analysis .......................................................................124 5.1.4 Subjects...................................................................................................127 5.1.5 Procedure ................................................................................................128 5.2 Design problem ..............................................................................................132 5.2.1 Experiment problem: design of a water filter manufacturing line..........132 5.2.2 Machine selection: Compatibility and Issues resolution ........................134 5.2.3 Machines layout......................................................................................136 viii 5.3 Experiment results and discussion...............................................................138 5.3.1 Communication data encoding ...............................................................138 5.3.2 Scoring scheme.......................................................................................141 5.3.2.1 Score-based Design Performance Index (SDP) ..........................141 5.3.2.2 Design Space Exploration Index (DSE)......................................142 5.3.2.3 Negotiation Content Distribution (NCD)....................................143 5.3.2.4 Negotiation Process Distribution ................................................144 5.3.3 Impact of the protocol implementation on collaborative design negotiation .......................................................................................................146 5.3.3.1 Score-based Design Performance................................................146 5.3.3.2 Design space exploration performance .......................................148 5.3.3.3 Negotiation content distribution..................................................150 5.3.3.4 Negotiation Process Distribution ................................................154 5.3.4 Impact of the multi-level strategy support on collaborative design negotiation .......................................................................................................158 5.3.4.1 Score-based design performance.................................................158 5.3.4.2 Design space exploration performance .......................................161 5.3.4.3 Negotiation content distribution..................................................163 5.3.4.4 Negotiation Process Distribution ................................................165 5.3.5 Summary of findings ..............................................................................167 5.3.6 Limitations..............................................................................................169 Chapter 6: Contributions and future work............................................................171 6.1 Contributions .................................................................................................171 6.2 Future Work...................................................................................................176 Bibliography..............................................................................................................178 Appendices ................................................................................................................188 A-1 Designer 1 Process Morphology chart.......................................................188 A-2 Designer 2 Process Morphology chart.......................................................189 A-3 Compatibilities and issues sheet for designer 1.........................................190 A-4 Compatibility and issues sheet for designer 2 ...........................................192 A-5 Options List ...............................................................................................193 A-6 Negotiation chat logs samples ...................................................................195 A-7 One way ANOVA for design score ...........................................................196 A-8 Count of utterances used in experiment samples.......................................197 A-9 ANED testing - Experiment results ...........................................................198 A-10 Statistical correlation between experiment measures ..............................200 A-11 ANOVA Results ......................................................................................204 ix List of Tables Table 2.1: Even swaps method.....................................................................................30 Table 4.1: Resource classes of ANED .........................................................................60 Table 4.2: Design Objective Structuring Methods and Examples ...............................67 Table 4.3: Speech Acts precedence rules .....................................................................86 Table 4.4: Strategy application rules and conditions....................................................95 Table 4.5: Initial Design objectives of each designer.................................................100 Table 4.6: Parameters responsibility of each designer ...............................................101 Table 4.7: Functional requirements and design objectives ........................................102 Table 5.1: Experiment treatments...............................................................................122 Table 5.2: Design tasks, objectives and information..................................................134 Table 5.3: Negotiation utterance definitions ..............................................................139 Table 5.4: Typical chat log for each negotiation process phase.................................145 Table 5.5: Specifications of design outcomes ............................................................147 Table 5.6: Design Space Exploration results (CG-PG treatments) ............................148 Table 5.7: Results of negotiation chat log encoding ..................................................151 Table 5.8: Number and ratios of utterances used per phase .......................................155 Table 5.9: Specifications of design outcomes ............................................................159 Table 5.10: Design space exploration (PG-PSG treatments) .....................................162 Table 5.11: Results of negotiation chat log encoding ................................................163 Table 5.12: Number and ratios of utterances used per phase .....................................166 Table A-3-1: Local incompatibility table ...................................................................190 x Table A-3-2: Global incompatibilities and issues for designer 1 ...............................190 Table A-3-3: Issues description for designer 1...........................................................191 Table A-4-1: Local incompatibility table ...................................................................192 Table A-4-2: Global incompatibilities and issues ......................................................192 Table A-4-3: Issues description for designer 2...........................................................192 Table A-5-1: Option list for Designer 1 .....................................................................193 Table A-5-2: Option list for Designer 2 .....................................................................194 Table A-8: Count of utterances used in each experiment...........................................197 Table A-9-1: Design results summary........................................................................198 Table A-9-2: Analysis of creative process .................................................................198 Table A-9-3: Analysis of utterances used ..................................................................199 Table A-9-4: Analysis of utterances distribution .......................................................199 Table A-10-2: Pearson’s correlation index for PG and PSG groups..........................202 xi List of Figures Figure 2.1 ANED and related research work ...............................................................13 Figure 2.2: Dimensions of CSCW................................................................................43 Figure 4.1: Structure of ANED ....................................................................................53 Figure 4.2: Design Task structure ................................................................................61 Figure 4.3: Design Objective structure for a flossing device design problem .............66 Figure 4.4: DHT for a flossing device..........................................................................69 Figure 4.5: Part of a DHT with multiple alternatives for task T 111 ..............................71 Figure 4.6: Representation of collaborative decisions in DHT ....................................72 Figure 4.7: Decision model in ANED ..........................................................................76 Figure 4.8: Toulmin’s (1969) Argument Structure and Example ................................78 Figure 4.9: Speech acts and ABN protocol ..................................................................83 Figure 4.10: ZOPA representation ...............................................................................87 Figure 4.11: Multi-layer representation of design activity...........................................88 Figure 4.12: Solution exploration strategy representation ...........................................92 Figure 4.13: Elevation strategy between solution and constraint levels ......................93 Figure 4.14: Multi-layer model with strategies representation ....................................96 Figure 4.15: Configuration of the trunk design problem..............................................98 Figure 4.16: Suitable gas springs for designer B’s task .............................................102 Figure 4.17: Result of Negotiation over Design Objectives (Scenario 2)..................109 Figure 4.18: Decision history tree ..............................................................................110 Figure 4.19: Solution with a 2-part trunk with sliding upper part..............................115 xii Figure 4.20: Solution with a 2-part trunk with hinged upper part..............................116 Figure 5.1: ANOVA for adjusted design score ..........................................................126 Figure 5.2: Residual plots for adjusted design score..................................................127 Figure 5.3: Experiment setup .....................................................................................130 Figure 5.4: Water filter to be manufactured ...............................................................133 Figure 5.5: VISIO environment used for the layout task ...........................................137 Figure 5.6: Cost, space and SDP performance for CG and PG samples ....................148 Figure 5.7: Design space exploration for CG and PG samples ..................................149 Figure 5.8: Negotiation content distribution for CG and PG samples .......................152 Figure 5.9: ANOVA for total number of proposals vs. treatment..............................152 Figure 5.10: Utterances distribution over negotiation phases ....................................156 Figure 5.11: Cost, space and SDP performance for PG and PSG samples ................160 Figure 5.12: Negotiation content distribution for PG and PSG group .......................164 Figure 5.13: Utterances distribution over negotiation phases ....................................167 Figure A-1: Designer 1 Process Morphology Chart...................................................188 Figure A-2: Designer 2 Process Morphology Chart...................................................189 Figure A-4-1: Group 1 – Control Group ....................................................................195 Figure A-4-2: Group 2 – Protocol-Supported Group .................................................195 Figure A-5-1 ANOVA for adjusted design score (with 0.1/0.9 coefficients) ............196 Figure A-5-2 Residual plots for adjusted design score ..............................................196 xiii Abbreviations ANED: Argumentation-based Negotiation for Engineering Design ANOVA: Analysis of Variance CG: Control Group CSCW: Computer Supported Cooperative Work CSCL: Computer Supported Collaborative Learning DHT: Decision History Tree DSE: Design Space Exploration NCD: Negotiation Content Distribution PG: Protocol-supported Group PSG: Protocol and Strategy-supported Group SDP: Score-based Design Performance xiv Abstract In order to compete and be profitable in today’s market, companies must permanently accelerate the development of their products and reduce their time to market. To address these challenges, collaborative design frameworks based upon the decomposition of design problems into smaller sub-tasks have been implemented. These sub-tasks are carried out by multitalented design teams in a concurrent manner and their results eventually aggregated into a final product. Collaborative engineering is heavily dependent on the quality of the interactions between the team members. Today, these interactions are facilitated by a wide variety of tools, including computer-aided design software or product lifecycle management tools. E-mail and video conferencing have also significantly increased communication efficiency, improved the reactivity of engineers and addressed the issue of geographically dispersed teams. However, one question remains unaddressed despite a genuine need for an effective answer. Engineers working on technical projects and more generally individuals involved in team work are facing situations in which their objectives conflict with others’, their tasks have misfits or their approaches are clashing. The only solution to such standstills is to gather around a table (physically or virtually) and work them out by negotiating and trying the find common grounds to move forward. Engineering negotiation cannot rely on powerful tools for its basic theoretical foundation has not been established clearly. xv In this research, we introduce a framework of Argumentation-based Negotiation for engineering Design (ANED) which provides negotiation support to designers. This framework was developed to facilitate and guide the exchange of arguments between parties facing a conflict, in order to resolve their discrepancies through a negotiation process while maintaining consistency in their work, and promote creative alternatives. The ANED framework relies on a design context model used to describe the information generated during the design process, an argumentation-based negotiation protocol providing an organized structure for engineers to negotiate over their discrepancies and a strategy-support model offering strategic guidance. The developed framework has been evaluated through a case study and a collaborative design experiment. The results demonstrate the positive impact of this approach on design quality, efficiency and designers’ ability to generate design alternatives. 1 Chapter 1: Introduction 1.1 Background and motivations Engineering design is a multi-faceted activity whose goal is to achieve tradeoffs between competing – if not completely antithetical – criteria in order to deliver quality products to a demanding market. In automotive engineering, the market’s demand for more comfort and convenience onboard new vehicles pulls new cars weight upwards while skyrocketing gas prices make fuel economy a new priority. Engineers have to constantly explore new avenues to keep their products up to date with the market’s expectations. To keep up with such a fast-paced environment, teamwork has become essential. Design and engineering teams composed of experts in different technical areas are working together to define problems, identify requirements, make joint decisions about design tradeoffs and eventually achieve suitable designs. Such a process requires not only a flawless communication support, but also a proper understanding among the participants, as well as an environment prone to new ideas generation. Collaborative design is an activity in which multiple stakeholders are involved as it requires multiple bodies of knowledge. As a result, a seamless communication is essential between stakeholders to guarantee the completion of such a design process within the budgetary and time constraints. However, despite tremendous progress 2 made in the tools dedicated to interpersonal communication over the past decades, complete real-time knowledge and data sharing remains unrealistic. Even under the assumption that every communication issues were resolved, conflict situations would still arise as there is no way of preventing the unexpected (changes in the economy forcing the company to readjust its budgets, sub-contractors going bankrupt forcing in-house production of certain parts, etc…). Thus, conflict management will always be an important part of the collaborative design process. Unless design is done in an environment where decisions are purely hierarchy-based (the higher ranked person involved in the conflict has total authority), conflicts are usually handled through a negotiation process, during which the parties try to reach a mutually acceptable agreement. Negotiation is a process in which a joint decision is made by two or more parties [95]. The parties first verbalize contradictory demands and then move towards an agreement by a process of concession-making or search for new alternatives. For multi-criteria collaborative design problems, negotiation is a way for multiple designers to exchange information, acquire knowledge of other designers’ perspectives and intents, and identify new opportunities based on the learned information and knowledge. Therefore, design negotiation is not only a way to reach mutually acceptable solutions, but also a source of opportunities for new designs. Collaborative engineering support systems have been developed with the primary objective of achieving a seamless information flow among engineering systems. Shared database systems, communication protocols, and workflow systems have been developed to facilitate information sharing, design change propagation, and process 3 management. Hitherto, the issue of negotiation in collaborative design has been the subject of limited research. Scott et al., following Wood et al. ([116], [117], [132]) have introduced a Method of Imprecision to deal with the inherent imprecision of early stage design information. The purpose of the method is to formally represent and manipulate this type of information. Using preferences expressed by the designers, and an aggregation function, Scott et al. compute optimal trade-offs over design variables. The method is able to compare several configurations differing by two or more design variable values and decide what the optimal design is. Bahler et al. ([12],[13]) introduced a method to evaluate compromise solutions to conflicts in engineering design. The authors present a negotiation protocol relying on the elicitation of compromise solutions by the parties involved in the conflict, and which compares and ranks the solutions (quantitatively if possible) in order to suggest the most suitable compromise. This approach, as underlined by the authors, departs from both the research seeking to develop cognitive models of human negotiation, and the research seeking to automate the negotiation process (see Erman et al.[41]). We share Bahler’s approach as we aim at supporting human negotiation, not replacing it. However, as we’ll see in the next chapters, we do not base our support on the optimization of a choice between compromise solutions. We rather take a prescriptive approach to suggest suitable negotiation strategies to specific conflict situations. In our research, we take an argumentation-based negotiation approach to support collaborative design. Our intention is to develop a negotiation framework that will eventually link designers and engineering systems together at decision-level, 4 facilitates negotiation among them and create an environment suitable for idea generation stimulation. 1.2 Research problem and approach In current collaborative design practice, the distributed-problem solving method implemented to reach design objectives while integrating design requirements leads to unavoidable inconsistencies and often incompatible sub-task solutions. On the one hand, the distributed nature of the design environment and the limitations of communication tools prevent teams from achieving adequate information flow resulting in conflicts and incompatibilities. Numerous computer-based tools (i.e. 3D CAD software) facilitate information exchange about working principles, physical embodiment and product geometry in the late stages of the design process, but are for the most part unable to support early stage design work. On the other hand, an essential part of the design information related to the designers’ intent, value system and preferences is overlooked. No prevision is made to allow this exchange of intents and values; the designers must therefore inquire explicitly and directly about them. These inquiries are generally informal and the information content may be source of interpretation for lack of a clear communication model. Thus the collaborative design decisions agreed upon are not consistently foolproof. As a result, multiple design revisions, backtracking, concepts reformulations, and re-design efforts are necessary to maintain a design overall consistency. In addition, as inter-designer communication is established, the parties involved should be able not only to discuss design ideas and issues, but also have the ability to 5 create new concepts, invent new principles, and essentially build upon each other’s ideas, knowledge, and know-how. Recent research supports this view of engineering negotiation as a co-construction process during which advanced design work can be generated (Lu [76]). The research efforts presented in this dissertation propose a framework to address the issues of design conflict description, analysis and resolution by focusing on the inter-designers negotiation activity. In particular, this work emphasizes the fact that engineering conflicts faced in a collaborative setting should be seen as opportunity to further improve the design outcome. The key research issues to address are therefore: 1) How can we model design information to facilitate conflict description and conflict-related communication? 2) How can we support negotiation in conflict resolution while promoting alternative generation and minimizing intrusion into designers’ activity? 3) How can we support the conflict resolution activity and improve the design space exploration process? Academic objectives The academic objectives of this research are multiple: 1) To investigate design as a local and global decision-making process, and adapt negotiation theory results to the design world 6 2) To model the information generated in design in order to provide context- based support to design conflict resolution 3) To create a powerful framework, which can be used to improve inter- designer negotiation efficiency and simultaneously improve the thoroughness of the design space exploration. 1.3 Thesis overview The contributions of this research work relate to both the fundamental understanding of collaborative engineering design negotiation and the ways this activity can be effectively supported. A number of existing models view the design activity as a multi-objective optimization problem (see Andersson [5]) and focus on achieving this optimization in the most effective and efficient fashion. Numerous methods have been use to carry out the optimization such as Pareto-based, fuzzy logic or utility theory-based approaches to name a few. Such prescriptive approaches have the benefit of dealing mathematically with design activity and therefore provide some rigor to the design decision-making process. However, most approaches start off by establishing value functions depicting the participants’ value systems, but generally fail to describe the rationale behind each value function. Furthermore, we advocate that a subject’s value system may be altered at any time during the design process and its mathematical description at time t may be obsolete at a later time of the design. Thus we decided to propose an alternative to such approaches. Furthermore, we believe that such approaches do not incite participants to engage in any type of 7 exploratory activity but rather bring them to express their personal preference in order to mediate a consensus. We argue that such consensus reaching method is detrimental to design creativity and should be avoided. In this research work, we started by investigating the topic of design information and information modeling, as we established that sharing a design context model (DCM) is indispensable for the engineers and designers, in order to achieve seamless communication exchanges and maximize mutual understanding. We refer to this model as a design context model, since its content is not limited to design data. It also involves information pertaining to designers’ value systems, and the ongoing design process itself. In particular, this DCM relies on a description of design objectives allowing the users to unequivocally express and describe what is essential to them in the design work in progress. This design objective model allows the parties to justify their negotiation stance when resolving a design conflict and express how flexible their stance is. Using the Design Context Model, the parties are able to precisely understand what design information is discussed, and what the position of their collaborators is. However, design data also needs to be accurately accounted for in the design process itself. A decision-based approach to design was used to develop a Decision History Tree, physical representation of a hierarchical decomposition of a design task into sub-tasks and decision nodes. Each task and decision is associated to a set of design context elements. Keeping track of these links has a number of advantages as described in section 4. 8 Existing Multi-agent systems and artificial intelligence literature [61][62][67] [97][98][109][110] has shown that research efforts have been focused on creating autonomous and semi-autonomous system having the ability to handle task that require some degree of intelligence and do it on behalf of humans. An essential faculty of humans lies in their ability to argue about topics and influence each other to reach a consensus. A number of protocols have been devised [97] and grouped in a research field of its own called Argumentation-Based Negotiation. ABN departs from game-theoretic and heuristic-based approaches and puts arguments at the center of the negotiation activity. Researchers have proposed models of arguments and negotiation protocols adapted to diverse types of interaction mechanisms (information exchange, collaboration, coordination) and applications (Electronic trading, distributed business process management, air traffic control…). In this research work, we hypothesized that humans’ ability to argue and discuss issues is an asset but can also be detrimental in the context of collaborative negotiation as it can be a source of inefficiency. We proposed the following research hypothesis: providing members of a collaborative engineering design team with a limiting protocol, which allows them to use only specially formatted arguments, and under certain conditions, can improve the efficiency of the design and the design outcome itself. We devised a negotiation protocol and an argument model to support engineering negotiation and test our hypothesis. Generating arguments in accordance with the protocol and argument model is a critical step towards an efficient collaborative engineering negotiation methodology. 9 However, even though the parties involved may follow the protocol closely, there is no way for them to evaluate what the preferable directions of design exploration are given their respective positions, design objectives and assigned tasks. We propose a strategic model based on a decomposition of the design space over multiple abstraction levels, which allows the users to discuss their differences by following a logical sequence, and use a library of strategic moves to overcome them and reach mutually acceptable agreements. This thesis contains a detailed description of the ANED framework that was created to address the issue of collaborative design conflict resolution through inter- designer negotiation. It focuses extensively on the background research used in creating this framework, as well as the constitutive elements of the framework. It then introduces a case study created to point out the benefits of the framework, as well as a live experiment developed to assess the impact of the framework on a real-world problem. It concludes on the contributions of this research and proposes future research directions based on the established results. 1.4 Thesis Organization This thesis consists in 6 chapters including this introduction. A description of the content of each chapter is given below: 10 Chapter II: Related work This chapter presents a thorough literature review of the relevant research work done in three specific areas this doctoral work was built upon: negotiation research, multi- agent systems and collaborative engineering. We introduce significant results obtained in each discipline and suggest the benefits of synthesizing them into a common framework whose purpose will be to support conflict resolution with a powerful negotiation protocol. We demonstrate at the end of the chapter the legitimacy of proposing such an approach and its projected benefits. Chapter III: a Context and argumentation-based Negotiation framework for collaborative Engineering Design This chapter presents the architecture and contents of the ANED framework, and successively describes each of its sub-components in details. These components are the following: the design context model, the argumentation-based negotiation protocol and the agent-based support system. The purpose of each component is emphasized, as well as its relation with the others. Chapter IV: Case study: Trunk design problem Chapter IV introduces a case study based on a real design problem and demonstrates the usefulness of our approach, by examining several possible scenarios for number of design problems and comparing their results with traditional approaches. This case study was created as a preliminary evaluation of the ANED framework prior to the live experiment described in chapter V. 11 Chapter V: Impact of Argumentation-based Negotiation approach on collaborative engineering design This chapter introduces a collaborative design problem which was created by the author in order to assess the efficiency of ANED. The chapter first presents the context of the experiment as well as the objectives considered when the problem was generated. The problem is then introduced along with the rationale for each of its components. The last part of the chapter presents the results of the experiment as well as a detailed analysis. Chapter VI: Contributions and future work This chapter concludes the dissertation by going over the contributions of this research work and underlines the fundamental results observed. It concludes on the possible extensions of this research work and suggests directions of interest. 12 Chapter 2: Related work 2.1 Introduction Our research is built upon three main bodies of research, which have been explored extensively and for which concrete results have been established. This work is strongly related to collaborative engineering as it aims precisely at providing a framework to support the collaborative design activity. In addition, our approach focuses on the negotiation activity and conflict resolution and is in that respect related to negotiation and conflict resolution research. Finally, this research work is related to efforts made in the field of multi-agent systems, Computer-Supported Cooperative Work (CSCW) and Computer Supported Collaborative Learning (CSCW) where a number of communication protocols have been devised. We found inspiration in these fields when developing our inter-designer negotiation protocol. Figure 2.1 is a graphical representation of where our research stands with respect to these other research domains. Collaborative engineering: This research topic encompasses several issues, including design information representation and exchange, conflict detection, management and resolution within groups, as well as collaborative and joint decision-making and other relevant subjects. 13 Figure 2.1 ANED and related research work Negotiation research: This term covers the research done in social science and decision science, focused on decision-making and negotiation. It also includes the work done in Game Theory, Joint Decision Theory (also referred to as Decision Analysis) and more generally on the information exchange issue. Multi-agent systems: This term refers to work done in the field of Computer Science and Distributed Artificial Intelligence. One area attracting a lot of interest in this research community is that of argumentation-based negotiation between agents, in which autonomous agents get involved in negotiation processes, by exchanging arguments over issues at stake, in accordance with a given protocol. We reviewed this work with attention when developing our protocol. 14 In the following sections, we are presenting results from each of these research fields that we reviewed and considered when creating ANED. We will first go through a description of the achievements of Collaborative Engineering research and insist on those particularly relevant to us. We will then introduce a number of common features identified in diverse fields of negotiation research and which are applicable to collaborative design negotiation as well. Finally we proceed with a presentation of essential results observed in the fields of Multi-Agent Systems research as well as Computer Supported Cooperative Work (CSCW) and Computer Supported Collaborative Learning (CSCL). 2.2 Collaborative Engineering 2.2.1 Information modeling Arrow’s Impossibility Theorem [9] established that it is impossible from a situation where multiple stakeholders give multiple criteria to come to a single criterion that satisfies all the others. The “art” of multi-disciplinary optimization is a by-product of this realization. In most of today’s engineering activities and projects, no specific individual is able to solve the problem in a specified time limit, for those design problems have become multi-disciplinary and require expertise from many different fields. Distributed problem-solving (DPS) has become the solution to deal with such design problems, and provided a paradigm suited to tasks involving diversified disciplines. In such approaches, problems, locations, responsibilities, data, resources, risk, or even authority may be distributed, and key issues have to be 15 mastered to be successful: communication, organization and coordination. Several approaches to DPS have appeared, some focusing on organization, others on information-sharing, on process, or on dependency between tasks. The progress made in the realm of information technology has greatly contributed to the development of the DPS approach. More specifically, the Object-Oriented Technology, the advancement of networking (with the World Wide Web, the intranet networks…) and the creation of standards and consortiums such as STEP 1 , OMG 2 , or the NIIIP 3 , also facilitated DPS’s expansion. Other advances are related to the progress of design theory, which has established models of the design process, such as Pahl and Beitz’s [86] Engineering design – systematic approach. Finally, the introduction of CAD/CAM tools to model products and simulate their behavior, while providing a permanent access to all the stakeholders to the latest versions of the models. All of these advances in information modeling have contributed to improve the quality of communication exchanges between members of design teams, and consequently made collaborative engineering the most suitable approach to complex design problems. 2.2.2 Conflict management In section 2.2.2 we introduce the concept of organizational conflict and some of the work that has been done in this field in order to categorize conflicts, especially in the engineering design context. In this section, we are looking into existing models and 1 :STandard for Exchange of Product data 2 : Object Management Group/CORBA 3 National Industrial Information Infrastructure Protocol 16 systems dedicated to collaborative design conflict management. One of these conflict management systems is Klein’s Design Collaboration Support System [67][69][70], and was developed to support the conflict management process in collaborative design teams composed of both human and computer-based design agents. In DCSS, each design agent is provided an assistant whose role is to detect, classify and resolve conflicts, in a domain-independent fashion. The conflict detection module bears two functions, it provides design agents with a way to describe their design actions, in order to avoid unnecessary conflicts, and allows early conflict detection as well. The conflict detection tool uses two methods: a domain-independent method and a set of domain-dependent idioms. Klein’s model considers that all conflicts are related to unattainable constraints. These constraints can be inconsistent desired constraints on a component feature, inconsistent constraints on a component feature or inconsistent desired and actual constraints. The domain independent idioms are pre-existing idioms or “sentences”, which can be filled in with domain-specific details to instantiate the idiom into an active entity. In addition, Klein introduces a taxonomy of conflict causes as well as a conflict explanation module, based on a questioning process of the agent by the assistant, whose purpose is to create a list of reasonable explanations to each conflict. In order to solve conflicts, DCSS relies on a production- system like approach, and a set of FOR-IF-THEN rules. Once a conflict is identified and explained, the assistant generates a set of resolution suggestions. Other efforts in the conflict management domain have been made by Brazier et al. [22] or Bahler et al. [12], [13]. 17 2.2.3 Negotiation in collaborative engineering design Collaborative activities are characteristic of social groups animated by a common goal, such as commercial companies, non-profit organizations or international institutions. Rahim [96] analyzes conflicts in organizations, which are inherent to these social structures. Collaborative work necessarily involves conflicts, and as we noted earlier, negotiation remains the most rational and fair method to solve conflicts, that’s why negotiation in collaborative engineering is of interest to us. The purpose of the engineering activity has always been to devise products which address certain consumer needs. The complexity of some of today’s products such as satellites, automobiles, or large computer software necessitates the involvement of multi-disciplinary teams of engineers, in order to gather the necessary skills and know-how as well as reduce the development time. The diversity of stakeholders combined with the limitations of knowledge representation tools (Lu et al. [75]) lead to conflicts and failures in the collaborative design world. Lu et al. proposed a Socio- technical framework to describe collaborative engineering design, in which they point out the influence of the socio-technical environment on the design process, seen as a co-construction process influenced by both the social and technical dimensions of collaborative engineering design. This framework is introduced to develop a design rationale model for collaborative design. In order to address the knowledge representation issue, some models have been developed to support knowledge-sharing. Olsen et al. [86] (1994) proposed a formal approach to representing knowledge to facilitate communication between engineers 18 collaborating on a given project. McGuire et al. created SHADE (1993) [79] to improve knowledge representation and ease information sharing and collaboration between engineers using disparate engineering tools. On the negotiation side of the conflict management issue, important work has been done in the field of computer science to deal with negotiation amongst computer agents. We introduced some of the accomplishments in this field in the section presenting argument-based negotiation. In other domains of engineering, the contributions have been much more limited. Boehm and In [19] have created a system that supports engineers dealing with cost-quality conflicts, and helps them negotiate a mutually satisfactory balance. Yan et al. [135] proposed an agent-based system to support negotiation and automate the transaction process from customer order to manufacturing plan. Mark et al.’s COSMOS project (1994) [77] was created to support engineering negotiation by assessing the ramification of any design change and presenting a visualization of these ramifications to all the engineers whose work will be affected. Lu [76] proposes a decision-making paradigm baptized ECN (for Engineering as Collaborative Negotiation) as the foundation for collaborative engineering research. ECN is defined as “a socio-technical decision-making activity, where a team of stakeholders with different expertise and mixed motives engage in interactive and joint conflict resolutions to co-construct consensual agreements of some engineering matter”. ECN is based on research results in psychology, philosophy, sociology, management and decision science. ECN focuses on defining the roles of negotiation 19 in engineering decisions, how to represent knowledge to facilitate this negotiation, what type of negotiation processes should be followed by engineers, and how to resolve conflicts and reach consensus. In our work, we aim at addressing some of these points. In addition, we advocate that the quality of the outcome of a design process can be raised by instilling creative thinking through negotiation itself: conflicts are thus seen as opportunities of improving a design rather than an obstacle. Engineering design being a highly iterative type of activity, the information generated is more often than not, imprecise and time-sensitive. Scott and Antonsson (1996) [116] studied the imprecision that exists in engineering design data in the early stages of design processes, and noticed that this imprecision was the main trigger to informal negotiation between the groups (analysis, manufacturing, marketing,…) and individuals involved in the process. Wood and Antonsson [132] created the Method of Imprecision to formally describe how this imprecise, early-stage information should be handled using the mathematics of fuzzy sets. Their objective was to determine the optimal set of performance and Design variables such that an aggregation function taking into account the individual preferences of the designers is maximized. We depart from this approach as we provide a more prescriptive approach in our framework, by suggesting different strategies to explore the design space, based on the values expressed by the designers and other factors as well. We will elaborate on this topic in section 4. Pena Mora et al. [90] developed CONVINCER, a computer agent who models preference functions of the participants and computes an optimal settlement using principles from negotiation and game theories. Other efforts focusing 20 on conflict identification and resolution include (Klein et al [69]) or fuzzy logic based methods (Ceroni and Velazquez [25], Faratin et al [43]). In our research, we view negotiation not only as a means to resolve discrepancies among designers but also as a process of synthesis in which designers generate ideas and develop mutually beneficial new solutions. In the experiment part of this research, our objective was to analyze to what extent the outcome of a collaborative design problem can be affected by the implementation of a negotiation support protocol such as ANED’s. A number of experiments dealing with negotiation can be found in the literature but few of them are specific to the engineering design context. Several experiments were conducted in the field of social sciences and management to study the impact of personality on the negotiation outcome [42], or the difference between individual vs. group negotiators [94]. In the field of engineering design, Kirshmann et al’s [66] tested the influence of groupware on a design project. Their approach was similar to ours in its implementation but focused on the impact of tools such as video and audio connectivity, or application sharing. Our interest was focused on the effectiveness of ANED’s negotiation protocol, and groupware tools were only a means in our experiment. We were able to observe some very interesting results discussed in chapter 5. 2.2.4 TRIZ: How to resolve contradictions in creative problem solving TRIZ, the Russian acronym for Theory of Inventive Problem Solving, was initially introduced by Genrich Altshuller as a revolutionary approach to support concept and 21 idea generation in design. This work started in 1946 when Altshuller, a patent reviewer, established that creative thinking and innovations are the results of universal principles of invention, which can be systematically identified, and classified. Such classification resulted in a theory that can be taught in order to facilitate inventive thinking. Since its inception, numerous researchers have contributed to TRIZ and over 2 million patents have now been examined. Nakagawa [84] proposed a 50-word description of the essence of TRIZ: “(…) recognition that technical systems evolve towards the increase of ideality by overcoming contradictions mostly with minimal introduction of resources. Thus, for creative problem solving, TRIZ provides a dialectic way of thinking, i.e., to understand the problem as a system, to image the ideal solution first, and to solve contradictions.” TRIZ is thus a new view of technology as a collection of technical systems which evolve towards the “increase of ideality” where ideality is defined as the ratio: Principal Function Mass+Energy+Size Evolution occurs only by “overcoming contradictions” with a minimal use of resources as they tend to complicate systems. TRIZ identified two types of contradictions: technical contradictions (improving performance of one parameter or dimension is detrimental to other parameters) and physical contradictions (to contradictory requirements must be fulfilled simultaneously). A list of 40 principles was established by TRIZ researchers to solve technical contradictions, and four 22 principles of separation were chosen to handle physical contradictions (for a list of these principles see [35]). The three primary findings of TRIZ are that: 1. Problems and solutions were repeated across industries and sciences 2. Patterns of technical evolution were repeated across industries and sciences 3. Innovations used scientific effects outside the field where they were developed Different interpretations of the patent review have been proposed. Some are rather analytical methods: the ideal final result, Functional analysis and trimming, etc… while others are more prescriptive: 40 principles of problem solving, the separation principles... TRIZ theory has been successfully applied in a number of fields from IT product development, budget management, to planetary exploration projects at NASA’s JPL or cost analysis problems at Ford Motor Company. 2.2.5 Robust design and tolerance synthesis The concept of robust design was first introduced by Taguchi [129]. Its method is based on the observation that quality in engineering should be thought of as the variation from the design target along two components: production variation and bias. Taguchi pointed out that while quality control on manufacturing lines helps maintain product quality to acceptable levels, another type of quality control efforts, made during the product design and process design yields bigger payoffs. Taguchi recommended a two step design process: a robust design followed by tolerance 23 design. The first step aims at reducing product quality variation by reducing the sensitivity of the design of the product to sources of variation (uncontrollable parameters) instead of controlling those sources. Tolerance design is intended to evaluate how much variation of the design and noise factors is acceptable. The goal of the method is to determine the appropriate tolerances for design parameters (control factors) to minimize the product manufacturing and life cycle cost. Tolerance synthesis deals with the optimal allocation of tolerances and aims at refining the ad-hoc approach of assigning tolerances as loose as possible. Tolerance synthesis efforts have been directed to minimizing cost. For an exhaustive list of cost- tolerance models, readers can refer to Chase and Greenwood [27]. 2.3 Negotiation in Social and Decision Science 2.3.1 Organizational conflict Negotiation can be seen as a form of social conflict and as well as a conflict resolution process (Pruitt) [95]. Indeed, since negotiating consists in defending opposing positions, it is a conflict-driven activity, but its purpose is also to examine the origins of the conflicts and resolve them. Rahim [96] identified several types of conflicts occurring in organizations. We are going to go through the conflicts types relevant to this research work. 24 1. Affective conflict: refers to situation where the interaction parties realize that their feelings and emotions regarding the issues at hand are incompatible. This type of conflicts is also called psychological conflict (Ross et al., 1989 [111]), emotional conflict (Pelled et al.[89]) or interpersonal conflict (Eisenhardt et al. [39]). 2. Substantive conflict: refers to a situation where the parties disagree on the task or content issues. This type of conflict is also referred to as task conflict, cognitive conflict or issue conflict. 3. Conflict of interest: this term refers to a situation in which the parties have inconsistent preferences regarding the allocation of scarce resources. 4. Conflicts of value: in this case, the parties have different values and ideologies on given issues. 5. Goal conflict: This term refers to cases where the parties’ preferred outcomes are inconsistent. We can envision that the most important types of conflicts that are dealt with in the engineering design environment are the goal conflict, and the substantive conflict. The designers involved in a project are all contributing to a group effort and as a result all share similar values. Also, the group members are sharing the same interests, at least on a global – overall design purpose – scale. Their desire is to complete their project in the least amount of time and guarantee a high-value product. The way resources are allocated should therefore be indifferent to them. 25 In their work, Scott et al. [116] identify a finite list of design negotiation situations: unreachable target performance value, trade-offs between facets of performance, conflicts between design and manufacturing, conflicts between engineering groups, or incorporation of unquantifiable performances. Brazier et al. [22] present a method to model conflicts in the design process and how to manage those conflicts using strategic meta-knowledge about design processes and a rule-based approach. They identify four types of conflicts, three of them being related to a single agent’s design process, while the fourth one is related to the collaborative design case. The latter is of interest to us, as it covers the situations eventually leading to negotiation. The authors determine that the conflicts related to agent coordination can be of the following types: conflicts over language, over beliefs, over goals, over responsibilities, over levels of cooperation or over strategies used in a collaborative effort. In the presentation of our framework, we will develop an exhaustive list of the potential conflicts facing a designer involved in collaborative design work. 2.3.2 Economics and Game Theory In the context of economics, negotiation often refers to buyer-seller interactions, and the way prices are determined. Game theory also focuses on this type of interactions, even though the surplus allocation isn’t necessarily over money. Rubinstein’s model [113] of bargaining focuses on one-to-one negotiation over the division of a pie of size 1. Each player successively offers a partition rule and his opponent accepts or rejects it. When rejecting an offer, the respondent party has to 26 generate a counter offer, and so on, until an agreement is reached. This model has been widely reused and modified to account for particular situation. For instance, Rapoport et al. [103] study the effect of one-sided information and time discount, and show that subjects follow simple rules of thumb in choosing strategies. In the case of multiple negotiators, Mauleon et al. [78] have created a model to describe coalition formations, which is used to assess the impact of members’ compliance to the agreement on the coalition formation outcome and the per-member payoffs. In our research, we limited the scope of our work to a two-party case and reserved n-party cases for future extensions of this work. 2.3.3 Legal issues Studies have shown that parties involved in legal negotiation interact in similar patterns to those observed in economics. Two types of negotiation tactics are identified: parties are either cooperative or competitive (Korobkin 2000 [71]), depending on whether they formulate realistic demands or not. Another distinction found in legal negotiation (and many other types of negotiation) deals with distributive versus integrative negotiation. Parties engaged in distributive negotiation focus on sharing the available resources in the most acceptable manner (“Get a bigger slice of the pie”). Parties which engage in integrative negotiation try to find ways of creating joint gains (“make the pie bigger”). Korobkin describes negotiation as a two step process: Zone Definition, and Surplus Allocation. A “bargaining zone” within which agreements are possible is defined during the Zone Definition phase, and this process is similar to an economic activity. 27 The bargaining zone is also referred to as the ZOPA for Zone of Possible Agreement; (see Fisher and Ury [48], Mnookin et al., 2000 [80]). In the second phase, negotiators try to agree on a “single-deal point” within the bargaining zone. This surplus allocation activity relies on community norm and is inherently a social activity. Korobkin introduces the concept of Reservation Point, which represents, in an economic context, the maximum amount a buyer would pay for a good, or the minimum amount a seller would accept. If the buyer’s RP is higher than the seller’s, the distance between the two is the bargaining zone. The reservation point is also referred to as the BATNA for Best Alternative to Negotiated Agreement (Fisher and Ury, [48]). One of the recent fields of research in legal negotiation deals with integrative bargaining and the desire to create value through negotiation. The most common approach consists in adding issues to the negotiation, and make trade-offs. The studies show that disclosing preferences, resources, interests and alternatives can help to create value, but may also compromise the position of a negotiator if the other party doesn’t play fair game. The core of the problem lies in the ability of the negotiating parties to disclose information evenly, so that no one is taken advantage of, and both parties benefit from the value created. This statement is linked to the negotiation strategy issue. Parties can deliberately misrepresent their reservation point, or disclose inaccurate information in order to truncate the bargaining zone to their advantage. 28 2.3.4 Negotiation Analysis 2.3.4.1 The PrOACT way of thought Negotiation analysis (Raiffa et al. [99]) deals with both decision analysis and the issue of decisions in negotiation contexts. Hammond et al. ([56], [57]) introduced the PrOACT way of thought in order to facilitate the work of decision-makers about choice problems. This approach consists of the following steps: 1. Identify the Problem 2. Clarify the Objectives 3. Generate creative Alternatives 4. Evaluate the Consequences 5. Make Tradeoffs This method promotes a proactive approach to decision making, especially in the negotiation context. Faced with a decision without a clear answer, people may have the tendency to adopt a reactive behavior, waiting for additional information and thus postponing their decision making. In the negotiation context, this has significant repercussions, as the other party may take advantage of this passive attitude and set the negotiation agenda. 1. Identifying the Problem The goal of this phase is essentially to ensure that the decision-maker is addressing the right problem, by challenging his understanding of the choice facing him/her. Several methods are suggested, such as thinking broader and not limiting oneself to 29 the immediate problem, consulting friends or experts for their opinion, or examining the trigger that caused the decision problem. 2. Clarifying Objectives In this phase, the decision maker attempts to gather his objectives, i.e. the criteria by which he will judge the decision. In the negotiation theory field, authors such as Fisher and Ury [48] use the word ‘Interests” to convey the same idea as Raiffa’s Objectives. The objective of this second step is to promote a broad view of objectives, in order to gather an exhaustive list to base the analysis on. 3. Generating creative Alternatives Alternatives are the different ways a decision maker may try to meet his objectives. In the context of negotiation, the term alternative is reserved for choices outside of the negotiation, and the term option is used for choices within the negotiation. The former is usually the work of a single individual, while the latter is the fruit of joint decisions. 4. Evaluating the Consequences For this phase, Raiffa proposes conditional analyses, i.e. evaluation of how each alternative performs with respect to each objective. One can think of a matrix representation with the columns corresponding to alternatives and the rows to objectives, each cell containing an assessment of the performance of a given alternative against a given objective. Based on this evaluation, it may not be easy to elicit one best alternative, but it is certainly possible to eliminate some of the 30 alternatives by using dominance. For instance, if alternative A is better that B on two objectives and is as good as B on a third one, B can be declared dominated by A and eliminated from the list of potential choices. 5. Making Tradeoffs Once the dominated alternatives are eliminated, the decision maker may still be faced with a significant number of alternatives suitable to his decision problem. Tradeoffs come into play as the suitable method to determine the best alternative. These tradeoffs have to be made while keeping in mind the relative importance of each objective. A widespread method to deal with tradeoffs is the Even Swaps method introduced by Hammond et al. [56]. The simple example on Table 2.1 helps Cost (in dollars) Fun (high, medium, low) Alternative A 50 Medium Alternative B 85 High Table 2.1: Even swaps method understand the method. Let’s assume that the decision maker is trying to select an activity to do for a special occasion. He narrowed down his alternatives to A and B, none of them being clearly dominated by the other. For the decision maker, the even swap method consists in asking himself “how much money am I willing to give up to bring the fun level of alternative A to High score?” Assume the decision maker considers that he would be willing to give up an extra 20 dollars to raise the fun score from medium to high and thus maintain the overall value of the alternative to him. Once this swap is done, the decision maker can easily make his decision, knowing 31 that if alternative A and B were both scoring High on the fun factor, alternative A would cost 70 dollars. Alternative A is thus the preferred alternative. This method is sometimes hard to implement, but if the swaps are made in a consistent fashion, it provides very good results. 2.3.4.2 Joint Decision Making Joint decision making, as introduced by Raiffa et al. 184[99], is constrained by the following conditions: • The parties can make mutually agreed-upon joint decisions This is a fundamental difference with the game theory approach in which “players” make separate decisions which interact to produce joint payoffs. In joint decisions, the “parties” behave as a group. As a result the famous example of the prisoner’s dilemma doesn’t hold, since group rationality forces parties to cooperate. • The payoffs of each party depend either on the consequences of the joint decisions or on the BATNA of each party Contrary to Game Theory in which payoffs are determined by separate interaction decisions, in joint decision making, the group’s joint decision determines the payoffs of each party. • Parties can reciprocally and directly communicate with each other. The communication however may or may not be honest. 32 This approach clashes with the non-cooperative game theoretic approach of simultaneous choices with no pre-play communication. To deal with the honesty issue, Raiffa suggests the Full, Open, Truthful Exchange (FOTE), assuming that the parties completely share information in order to maximize the chance of joint gains. • Parties can be creative in the decisions they make Once again, this view departs from Game Theory, which assumes there is a predetermined set of strategies and associated payoffs, known by all players. In joint decision analysis, parties can elaborate new strategies, alternatives, and leave or join a negotiation. 2.3.4.3 Distributive vs. Integrative negotiation As seen in the chapter dealing with negotiation in the legal domain, two types of negotiation, integrative and distributive can be identified. The distinction is important as it separates problems in which the parties argue over the distribution of scarce resources (distributive type), from other problems in which the parties try to create “joint gains” (integrative type). Distributive negotiation (also referred to as “Claiming”) is the fruit of a competitive behavior on behalf of the parties who try to maximize their profit. In general, the good at stake is money, time, space or any other single commodity. Such a situation can be transposed to the design world, in which arguments over space or time are easily conceivable. 33 Integrative negotiation (also referred to as “Creating”) consists in integrating the parties’ capabilities and resources to generate more value. This approach is related to deal-making and coordination. In order to create value, parties have to share information about goals and priorities, to find an agreement that will satisfy both parties’ needs. This approach involves a risk for the involved parties, as there is no guarantee of a balanced disclosure of information nor any guarantee that the other parties are being honest in the process (see Pruitt [95]). 2.4 Multi-Agent Systems and computer-supported activities 2.4.1 Agent-based systems To introduce this section, we can attempt to answer the following question: “What is an agent? “. In the large body of literature dealing with agents and multi-agent systems, a multitude of definitions can be found to qualify agents: - “…a hardware or (more usually) software-based computer system that enjoys the following properties: autonomy […], social ability […], reactivity […], pro-activeness […]” according to Wooldridge & Jennings [133] - “Software agents are programs that engage in dialogs [and] negotiate and coordinate transfer of information.” is the definition used by M. Coen of the MIT AI Lab. - “Autonomous agents are computational systems that inhabit some complex dynamic environment; sense and act autonomously in this environment and by doing so realize a set of goals or tasks for which they are designed.” This 34 definition by P. Maes of MIT’s Media Lab insists on the achievement of goals as a key feature of agents. Many other definitions can be found. In their paper dealing with agents’ taxonomy, Franklin & al. [49] came up with the following definition: “An autonomous agent is a system situated within and a part of an environment that senses that environment and acts on it, over time, in pursuit of its own agenda and so as to effect what it senses in the future”. Five elements can be used to characterize an autonomous agent: its environment, sensing capabilities, actions, drives and action selection architecture. To qualify a software program as an agent, researchers agree that it must possess the following features: • Autonomous: The agent must have control over its own actions and be able to work and launch actions independent of the user or other actors • Reactive: Agents can detect changes in their environment and react to those in a timely manner by answering to events initiate actions • Communicative: agents must be able to interact and communicate with users and other agents • Goal-driven: Agents must have a purpose and act in accordance with it until it is fulfilled Many systems involving agents have been created to achieve multiple goals, and were generally intended to address the question: “How should a task be divided into sub-tasks so that they can be processed concurrently in an efficient manner?” Often times, each subsystem is making decisions with limited knowledge about the others, 35 therefore rationality is bounded (Tokoro) [126]. In some instances, each subsystem even pursues different goals for its own benefit instead of the common goal. The Advance Decision Environment for Process Tasks (ADEPT – See Norman et al. [83]) is another multi-agent architecture which features autonomous agents who negotiate or engage in joint decision-making by following pre-existing strategies. Agent-based systems’ relevance to our design research is not obvious this far, but a strong parallel exists in that both involve a distributed problem-solving activity, and we draw inspiration from multi-agent systems research to address issues in engineering design. 2.4.2 Negotiation Protocols In the DAI research community, negotiation is commonly defined as “a form of interaction in which a group of agents (2 or more) with conflicting interests and a desire to cooperate try to come to a mutually acceptable agreement on the division of scarce resources” see Rahwan et al. [97][98]. This definition can vary and sometimes covers any situation where two or more agents enter a dialogue in order to agree on a subject on whom they initially had different opinions or beliefs. Contract net protocol The Contract-Net Protocol proposed by R.G. Smith [122] is the classical protocol for task allocation in MAS. Its original purpose was to allocate tasks among a group of distributed problem solvers. The contract net protocol is essentially a set of rules 36 and protocols which focuses on communication and control for nodes in a distributed problem solving environment. Smith defines distributed problem solving as “the cooperative solution of problems by a decentralized and loosely coupled collection of knowledge-sources (KS’s) (these being procedures, sets of rules, etc.), located in a number of distinct processor nodes.” In order to solve the entire problem, the KS’s need to cooperate as no one of them has sufficient information to solve it in its entirety. Only through mutual sharing of information can the group reach a solution. The term decentralized is used to describe that both control and data are logically and geographically distributed: there is neither global control nor global data storage. Finally, “loosely coupled” means that the main activity of the KS’s is computation rather than communication. The major issue to address in task sharing is determining how tasks should be distributed among the nodes, and how nodes with tasks to be executed can find the most appropriate available nodes to execute those tasks. In the contract-net protocol context, the negotiation relies on four fundamental concepts: 1. It is a local process, and doesn’t require a centralized control 2. Information exchange is bi-directional (two-way process) 3. Each party involved in the negotiation evaluates information from its own perspective 4. Final agreement is achieved through mutual selection 37 The term contract-net refers to the collection of nodes, and the execution of a task is seen as a contract between two nodes. Any given node can take on two roles related to the execution of the task: Manager or Contractor. While the Manager is responsible for the monitoring the execution of a task and its result, the Contractor is in charge of the actual execution of it. The match between Contractors and Managers is done through a bidding process during which the available contractors evaluate tasks announcement made by the managers and submit bids on those for which they are suited. Managers then evaluate the bids and select the contractor they deem is the most qualified. Additionally, a Contractor may decide to partition his task and thus becomes a Manager for those contracts. This is how the hierarchical control structure of task sharing is established. The main breakthrough of the contract net protocol lies in the mechanism it provides to structure high-level interactions between nodes for cooperative task execution. In addition, it underlines the importance of negotiation as an interaction mechanism. Extensions of the Contract Net protocol Numerous extensions to the Contract Net protocol have been made by researchers, in order to address some of its shortcomings. Aknine et al. [1] introduced a protocol which allows contractors to manage multiple negotiation processes with Managers (and vice versa) is more time-efficient and fault tolerant. Sandholm [115] in his Marginal cost-based contracting approach uses marginal cost calculation as a decision factor for agents (if the payoff of the agent increases by accepting a contract, then he 38 will accept it). The Leveled Commitment Protocol (Andersson and Sandholm [5]) allows agents to be de-committed from a contract if they pay a penalty, but this may deter the agents from voluntarily offering to execute the tasks, and penalties may be difficult to calculate. Sandholm has also underlined that all of these approaches remain limited insofar as the protocols they introduce are very much context- dependent. Even though these approaches limit themselves to a task allocation process, they were essential in the development or Artificial Intelligence and Multi-agent systems. In the perspective of our work, they opened the door to the development of agent- based systems and in particular argumentation-based negotiation work. We explore the research done in the field of ABN in the following section, in order to get some insight as to how fundamental principles used in agent research may be adapted to engineering design negotiation amongst humans. 2.4.3 Argumentation-based Negotiation In the following, we are introducing Argumentation-Based Negotiation by going through a review of the existing research done in this field. We will study different approaches and will identify their strong points and shortcomings. Using Rahwan et al.’s work [97][98] we will go through each of the elements involved in ABN frameworks. In the ABN context, an argument is viewed as a piece of information used by an agent to either “justify its negotiation stance or (…) influence another agent’s negotiation stance” (Jennings et al. [62][60]). The principal benefit of this approach 39 lies in the fact that agents can not only exchange proposals but also critique these proposals, clarifying at the same time their negotiation stance. The benefit is bilateral since an agent whose proposal is critiqued can understand better what part was rejected by the other party, rather that receiving only a rejection and a counter- proposal. Several major components of the ABN frameworks were identified by Rahwan et al. [97] 2003, some of which were classified as external elements or environment, while the others belong to the ABN agents themselves. In the next section, we describe the external elements of ABN frameworks. 2.4.3.1 Languages In order to communicate, the agents have to rely on a given language, referred to as a communication language and which contains all the locutions or speech-acts (See Searle [118]) needed to articulate their arguments and express their intentions. Examples of communication languages are Finin et al.’s KQML (for Knowledge Query and Manipulation Language) [46][47] or the Foundation for Intelligent Physical Agents’ Agent Communication Language (FIPA ACL, see FIPA 2001). These two languages contain basic “performatives”, such as propose, accept, or reject, which are essential to negotiation and many others which are used by agents to critique arguments, request additional information or express preferences. KQML was introduced as a high-level message-oriented communication language for information sharing and negotiation (H.S. Hon, Comparison of KQML and FIPA 40 ACL Article 2). KQML relies on 41 reserved performatives and offers the possibility to create additional custom performatives to be used in specific contexts. It is applied to architectures composed of numerous agents who own and maintain a virtual knowledge base, containing their mental model of the world. FIPA ACL takes essentially the same approach, since it is message-oriented and doesn’t depend on the domain/content language. However, some differences exist between the two. For instance, in FIPA ACL, agents are not allowed to directly manipulate other agents’ virtual knowledge base. These languages are thought of as wrapper languages as they are implemented at a knowledge-level of communication and are used to encapsulate elements of a domain/context language which is specific to the agents’ environment. For instance, the locution offer(a, b, Price = $200 Λ Item = palm130, t 1 ) in the framework of Sierra et al. [121] means that agent a proposes to agent b the sale of the item palm130 at time t 1 for the price of $200. In ABN frameworks, the communication language is used to pass on more than just proposals, but also meta-information related to the agents’ desires, their preferences or the environment. In general, ABN framework designers create their own locutions to handle negotiation concepts, such as threat or rewards. The domain language has to be complete enough to enable the agents to negotiate over the objects of their environment, such as variables, constants, physical entities, etc…The richness of the domain language is particularly important, and as a general rule, the richer the domain language is, the more flexibility agents have in the 41 arguments available to them. The communication languages are intended to be adaptable to any context when they are associated with a domain language whose purpose is to convey information related to the agent’s environment. Therefore, using arguments in their negotiation utterances, agents can acquire information about their environment, request delays, ensure coherence in their beliefs or influence other agents. One research challenge in this domain is to build a standardized language that can be used by designers in any kind of environment. 2.4.3.2 Negotiation protocol Once a communication and a domain language are chosen, the ABN framework needs a set of rules, or protocol to determine how the negotiation process should be carried out among agents. This protocol specifies who is allowed to say what and when in the negotiation process. For instance, an agent who is requested to provide a tool he’s not currently using at the time of the request may or may not be forced to provide the tool, depending on the protocol rules. This protocol specifies rules for different issues dealt with in the negotiation context, such as rules for admission or withdrawal from the negotiation, rules deciding when a negotiation is over, whether a proposal is acceptable (conformance checking) or not given the negotiation history, or rules determining the outcome based on the negotiation exchange. Finally, the issue of commitments is also dealt with in the protocol, which determines how they should be handled, and when the agents can withdraw from a commitment. 42 Protocols can be specified explicitly, as in dialogue games (see Amgoud et al. [2]) or implicitly, as a set of if-then rules embedded in the agents’ specifications (see Kraus et al. 1998 [72]). One of the main issues to be addressed when creating such a framework is that of termination rules. Amgoud and Parsons (2001 [3]) handle this by preventing agents from using the same locutions over and over; Torroni (2002 [128]) established a maximum number of exchanged messages in a given dialogue. The problem of conformance checking is another challenge, and has not received the attention it deserves so far. 2.4.3.3 Information store Most ABN frameworks rely on commitment stores, externally accessible to agents and where the history of each agent’s commitments is compiled and tracked. One important distinction must be made between these commitment stores and the interaction history, the latter being a mere collection of utterances, without any sense of the consequences involved by the commitments. On the other hand, those consequences are explicitly stated in the commitment stores. Moreover, the commitment stores are updated using commitment rules governing the addition or removal of commitments. In Amgoud and Parsons [3], the commitments are added to the commitment store using dialogue-game rules. The way negotiation information is stored is a key step in creating an ABN framework, as it conditions the performance and the quality of the outcomes of the negotiation dialogues (Rahwan et al. [97]). To summarize this review of ABN, we can lay emphasis on the fact that it is addressing a number of shortcomings of classical agents’ negotiation by offering the 43 opportunity to agents to argue about their values and preferences, and try to convince others by exchanging arguments. We propose to adapt such a type of negotiation protocol to human interactions in design in order to limit communication to its essential elements and consequently improve efficiency and design quality. 2.4.4 Computer Supported Cooperative Work (CSCW) The acronym CSCW often considered as synonymous of Groupware, was first introduced by Cashman and Grief in 1984 [54], during a workshop focused on understanding how people work and how technology can support this work. A number of definitions have emerged since then. Greif defined CSCW as “an identifiable research field focused on the role of the computer in group work”. Other researchers rejected this viewpoint such as Bannon and Schmidt [14] who view CSCW as “an endeavor to understand the nature and requirements of cooperative work with the objective of designing computer-based technologies for cooperative work settings”. More generally, CSCW is viewed as an umbrella term applying to any type of research dealing with the use of computers to support activities of people working together. Same Time Different Times Same place Face-to-face (Classroom, Meeting room) Asynchronous interaction (project scheduling, coordination tools) Different place Synchronous distributed (Shared editors, video windows) Asynchronous distributed (Email, bulletin board…) Figure 2.2: Dimensions of CSCW 44 CSCW encompasses a multitude of computer science notions and technologies such as Human-Computer Interaction (HCI), computer networks, multimedia, virtual reality or artificial intelligence. CSCW scope is spread across two dimensions: time and space. Figure 2.2 above presents this four-category classification of CSCW systems. Some confusion in CSCW arose from divergent views of the distinction between collaboration and cooperation. While some researchers do not distinguish the terms and use them interchangeably, others like Dillenbourg and Baker [34] insist on the differences between the two terms: “We view collaboration as something much more specific. (...) Cooperative work can be accomplished by the division of labor among participants, as an activity where each person is responsible for a portion of the problem solving. Collaboration is a specific form of synchronous cooperation in interaction where negotiation takes place simultaneously on all three (…) levels, i.e. the agents are coordinating their problem solving interaction, developing shared meanings, and co-constructing problem solutions. Note that such co-construction does not exclude the existence of conflict, since, as many researchers have argued (…), the constructive resolution of conflicts may be a key factor in successful collaboration” Bannon and Schmidt [14] define cooperative work as constituted by “work processes that are related as to content, that is processes pertaining to the production of a particular product of service”. They insist on the fact that cooperative work relationships are planned or premeditated. In addition, they establish that cooperative work can be direct, indirect, distributed or collective, depending on the mode of interaction. In our research, we share Dillenbourg and Baker’s view of collaboration, and agree with the Artificial Intelligence approach which gives a central role to conflicts in the negotiation process. Contrary to Dillenbourg and Baker, we view negotiation as a 45 process by which conflicts may be resolved. We will further comment on this topic in chapter 3. 2.4.5 Computer Supported Collaborative Learning (CSCL) The research field of computer supported collaborative learning (CSCL) originated from the CSCW research body. The main distinction between the two is that CSCW focuses on communication techniques while CSCL focuses on what is being communicated. As a result, CSCW is used mainly in the business world to help group communication and productivity while CSCL is usually used in educational context to help student learn together effectively [58]. Numerous theories have been created to understand CSCL, such as Vygotsky’s Socio-cultural theory which emphasizes that individual cognitive gain occurs first through inter-psychological processes and subsequent intra-psychological ones. Another school of thought is based on Piaget’s Socio-constructivist approach which considers that it is through interactions with others and sharing one’s vision’s of reality that individuals master new approaches. Shared cognition constitutes a third approach which considers that the environment is “an integral part of cognitive activity and not merely a set of circumstances in which context-independent cognitive processes are performed.” See Dillenbourg et al. [35]. Other variants of these theories include cognitive apprenticeship, metacognition or Problem-based learning. A large number of tools have also been created such as MemoLAB, People Power or BootNap to name a few. Some of these systems focus on human agent-computer 46 agent interaction while others deal with human-human interactions. Our interest in this research is primarily to investigate human-human interactions in collaborative design. Dillenbourg et al. [34] created C-CHENE, a system facilitating collaborative learning of modeling energy in physics in a network. This system supports two human students’ communication by means of a chat box and a negotiation model embedded in the design of the communication interface. One of the main conclusions of the C- CHENE experiment was that “passive constraints” on the form of the students’ interaction, imposed by the interface, did succeed in encouraging them to engage in more task-related discussion and explanation rather than in the “free” chat-box interface. In our research, we took a very similar approach to observe the collaborative design process and we will demonstrate in chapter 5 that our experimental study generated very similar results. In their research, Dillenbourg et al. established that human agents develop several shared representations of a problem and move across different negotiation spaces during its resolution. They identified seven dimensions to negotiation: the mode of negotiation, the object of negotiation, the degree of symmetry, the degree of complexity, the degree of flexibility, the degree of systematicity and the degree of directness. A direct parallel can be drawn between this view and our model of design space presented in chapter 4 which considers design information as disseminated over multiple levels of abstraction. 47 Chapter 3: Issues in collaborative engineering design 3.1 Need for a new approach As of today, no approach has successfully focused on determining in details what the influence of the different “constituents” involved in the resolution of a given design conflict is. When people do design, design requirements, parts, objectives, process planning, knowledge, communication and other pieces of data all contribute to determine what the design outcome will be. We may classify those as product- related, process-related and rationale-related. Multiple commercial tools are available to handle product-related information, such as CAD/CAM solutions or simulation tools, and most of them have been extended to be used in a collaborative manner. Similarly, tools and theories have been created to support the design process, like process planning tools (Gantt chart, Pert…), including new integrated solution combining CAD/CAM and PLM (Product Lifecycle Management) such as Dassault Systems DELMIA. Recently, rationale capturing tools have become available as well, even though they are, for the most part, developed internally by companies or still in the research stage (SSPARCY [118], SRI’s Rationale Construction Framework [82][83], etc…). However developed and powerful these tools might be, they fail to encompass all three perspectives at once, and users need to constantly go from one to the other. Format compatibility issues or the absence user-friendliness are two of the 48 numerous hindrances of using such a configuration with multiple tools to support designers in their work. In our research, we share Dillenbourg and Baker’s view of collaboration, and agree with the artificial intelligence approach which gives a central role to conflicts in the negotiation process. Contrary to Dillenbourg and Baker, we view negotiation as a process by which conflicts may be resolved. We will further comment on this topic in chapter 3. The basis of our work relies on the premise that the broad and diverse range of “information pieces” existing in design processes is directly related to the way design is carried out. We advocate that these elements can be clearly identified and categorized into a taxonomy that will prove to be particularly useful. The main contribution of this taxonomy will be to provide unified definitions to help the parties involved in the design to communicate, argue or negotiate about the design work being done. The second element that is lacking in the existing frameworks and tools is an efficient way to support conflict resolution between designers, and in particular, a negotiation protocol using clear design context information. We consider conflicts as potential opportunities to foster innovation, rather than just problems to solve. Using appropriate strategies to address conflicts, we believe that, while sharing design information, designers can also reach more creative solutions. In addition, in the presentation of our model we’ll insist on the importance of sharing more than just design information: sharing design objectives and express values and perspectives on 49 issues is essential for a collaborative design team, in order to reach global optimality in the design process. The last dimension of our framework is related to Human interactions and communication support. We provide designers with a strategic model to deal with design conflicts. This model is based on a decomposition of the design space as a set of abstraction layers, and across which negotiation can spread in accordance with the type of conflict faced and the position of the parties involved. To sum up the objectives of our research, we aim at creating a context-based negotiation support system to resolve design conflicts, relying on a specific argumentation-based negotiation protocol and a set of strategies, which will be used by a community of collaborating designers. The experimental part of our research will aim at demonstrating a somewhat counter-intuitive result: formatting the negotiation exchanges and constraining them with a specific argument model and negotiation protocol is actually beneficial to the design process and its outcome. The next section underlines the challenges expected in the course of this research work. 3.2 Research challenges 3.2.1 Challenges at the theoretical level Several challenges can be foreseen at the theoretical level in the development of such a framework: 1. First, the modeling of the design context may be done in many different fashions and none of these can be declared more accurate than another, until a 50 real testing of the model is done. Therefore, developing an accurate and exhaustive design context model is a trial-and-error process, which requires multiple revisions. In our experience, as we make further headway in the creation of the ANED framework, we have discovered new elements which were added or redundancies and regularly went back to refine the context model. 2. Creating a negotiation protocol, relying on results from the negotiation theory research field, adapting them to the design world is another challenge, for there is no clear understanding of the different levels of discourse that are employed in current design negotiation practice. People may try to jump from a parameter-level discussion to redefining objectives or changing a part’s shape, without any kind of methodological logic. What should be the proper way to proceed? Is applying a rigid structure to the negotiation process going to improve or impair this very process? How should we structure the arguments which are exchanged? 3. A third challenge is faced when dealing with the interaction of parties involved in a negotiation process. What kind of strategies should be established to guide the parties? Will this guidance improve the results of the negotiation? Will the guided negotiation converge every time, sometimes or never? What should be done if no convergence is achieved? Can we reach a feasible solution? An optimal solution? (And how do we define optimality in this case?). 51 4. The last challenge we envision is that of encouraging designers’ ability to generate design alternatives. We argue that it is possible, through the implementation of a framework such as ANED, to encourage the designers, and significantly improve the creative content of inter-designer negotiations. Can we go as far as significantly impact the design outcome itself or is this impact limited to human interaction and not transferred to the design outcome? This list describes the major challenges to address in this work to prove its legitimacy and reach our research objectives. In the next section, we look into the challenges at the implementation level. 3.2.2 Challenges at the implementation level Creating an implementation of this framework will be challenging for the following reasons: 1. We must think through how we may integrate an ANED-based system in the designer’s work environment while minimizing any associated disruption. One of the goals of ANED is to facilitate the designer’s communication exchanges, and this can only be done if the software product provided to the designer requires minimum input from him. Therefore the issue of balancing designer involvement and beneficial is central in this work. 2. The second issue is related to the type of communication support provided to the subject. We envision a computer-based system relying on one of the 52 existing communication means commonly used in computer-supported collaborative work, it being email exchange, data repository, or more instantaneous solutions such as instant chat or audio and video conference. Decisions must be made as to how much involvement from the subject is necessary and sufficient and what should be its nature. 3. In the context of the experimental study of our framework, the actual implementation and experimental protocol and setup are key issues to address. We will focus on a two-party case and must evaluate what kind of computer- supported system and equipment are needed. In addition, we must determine what amount of responsibilities and involvement is reasonable to expect from the subjects in our experimental context to yield significant results. Finally, we must establish a suitable problem, which will integrate smoothly in the experimental setup. These are the main challenges that will be faced when ANED is implemented into a working software environment. Let’s proceed to a detailed description of ANED in the next chapter. 53 Chapter 4: ANED, an Argumentation-Based Negotiation framework for Engineering Design 4.1 Overview of the approach The ANED architecture can be represented as follows on Figure 4.1, using three main components: Figure 4.1: Structure of ANED Design Context model The Design context model is the backbone of this framework; it contains all the elements needed by the designers using the ANED framework. This model specifies in particular how the design process is viewed as a decision-based activity in ANED, and provides a domain-independent language to describe any kind of design activity. The benefits of this context model are two-fold. On the one hand, it provides a library of terms necessary to describe design information as well as a method to record the ANED Argumentation-based negotiation Protocol Strategic support system Design Context model 54 history of a given design process. Thus, it becomes possible to retain the substantial design knowledge contained in the unsuccessful trial-and-error attempts necessary to reach a suitable final design, and to associate this information with the decision nodes observed. On the other hand, this model provides a structure that facilitates conflicts handling, by enabling designers to communicate to each other information about their activity, objectives or preferences. Several types of conflicts can be identified as we’ll see in the next chapter. Argumentation-based Negotiation Protocol Besides the design context model introduced above, a communication protocol is needed in ANED in order to monitor and regulate designers’ communication. Typically, when a conflict situation arises, the parties involved contact each other and try to resolve their differences. The argumentation-based negotiation approach was selected as an appropriate paradigm to support human agents’ negotiation and conflict resolution. The reason for this choice is the versatility of this approach, which makes it possible to share personal preferences and justify them, as well as influence other parties’ preferences. Multi-level strategic approach The last key feature of the ANED framework is a multi-level strategy model. This model relies on a description of the design space as a set of discrete interrelated subspaces. The advantages of this model are multiple: • It provides a logical and structured organization of the design space enabling the users to clearly focus their communication exchanges. 55 • It enables users to associate conflicts with a specific level, focus on design space exploration at this particular level and venture to higher or lower level if need be, to investigate and resolve related conflicts. • It can provide a graphical representation of the design space facilitating inter- designer understanding This paragraph is a brief introduction to the main components of ANED and each of these elements are going to be introduced in details in what follows. 4.2 Design Context Modeling 4.2.1 Design Context We mentioned earlier the necessity of having a design context model upon which we can rely, in order to represent and manipulate the data produced and dealt with during the design process. Such a model has to be scaled properly so that it may be suitable to describe all the situations we consider within the scope of our research. In previous work carried out at the Impact Laboratory, Danesh (2001) [30][32] introduced the concept of Design Context which he defined as: “a subspace of the design space, which consists of all design alternative concepts and concept variants”. His intention was to describe the expansion of the design space during design, and the design context he introduced is a measurement of how much of the design space has been explored by designers. We depart from this work in the fact that we take a decision-based approach to consider the design process. The design activity is viewed as a succession of decision- 56 making steps, and the overall process depends on the choices made at each decision node. As a result, our goal is to account for all the information generated and accumulated at a given point in time, and which is used to proceed further ahead in the process. With this in mind, we try to identify all the elements designers deal with while carrying out their task to regroup them under the term of “Design Context”. Another contribution to the modeling of design information was offered by Zhao’s [136] Working Structure Based Approach to collaborative engineering design. One of the key contributions of this work is the establishment of a clear description of the design process constituents, as well as their relationships. This work is oriented towards the elicitation of an optimal design process, which is not our goal here. However, some concepts are relevant and will be re-used in this work. In the following, we are presenting the definition of all the components of our Design Context Model. We will try to provide examples to clarify the ideas expressed. These components are: Design Entities, Functional Requirements, Design Constraints, Operations, Work Elements, Design Objectives, Resources, and Design Task. Design Entity: The term Design Entity (DE) refers to the elements generated during the design process, and which are directly or indirectly addressing the customer requirements. Examples of such entities are: Design Parameters (DP) 57 Parts (P) Assemblies (A) Working Principles (WP) Definitions of the design parameters, working principles, and functional requirements can be found by the reader in Suh [123] and Pahl and Beitz [87]. Examples of design entity include the following: X 1 (Design Parameter), door handle (part), door lock assembly (assembly), spring elastic force (working principle). The design entities are the elements which will be at the heart of the conflict identification process and they will be critical in the argumentation-based negotiation. Functional Requirements: Following Suh [87], Functional requirements pertain to the functional domain and are specific requirements which determine the top-level design’s objective. These functional requirements are addressed through design parameters DP which characterize a physical embodiment. Doing design is thus the process of relating the functional requirements of the functional domain to the design parameters of the physical domain. We refer to the Functional requirements with the abbreviation FR. The functional requirements structure is the following: <FR>::=<Action> <Purpose> <Performance measure> (1) 58 Action usually refers to a design-related verb, often marking a preferred direction of evolution i.e. increase, reduce…Purpose refers to a type of performance on which the action is performed. The performance measure sets a target value for the requirement. Examples of FRs are: <Limit> <0-60 mph acceleration time to> <6 sec>, <Reduce> <material cost by> <20%>, etc… Design Constraints: Following Suh [123], we define constraints as the bounds on an acceptable solution. They can be of two types: input constraints, which are constraints in design specifications and system constraints, which are constraints imposed by the system in which the design solution must function. Input constraints are usually expressed as bounds on size, weight, materials, and cost, while system constraints are interfacial bounds such as geometric shape, capacity of machines or the laws of nature. We use the abbreviations IC and SC to refer to input constraints and system constraints respectively. We model constraints as follows: <DC>::=<DE> must be <superior>|<inferior>|<equal> to <Value> Operation: Following Zhao [136], we define an Operation (op) as a set of sequenced actions c i taken on design entity DE i , and represent it as follows: op i-j ={C i-j , θ i-j } (2) 59 o With C i-j ={c 1 , c 2 , …, c n } finite set of actions o And θ i-j =[C i-j ] the sequence of actions An action C is a notable effect on design entity DE i which entails a modification of one or several of that design entity’s properties. An example of operation on a parameter X is: (locate parameter, calculate new suitable value, edit value, enter new calculated value). Work Element: Based on Zhao’s work, and adapting it to our needs, we define a Work Element (we) as a 2-tuple operation-design entity. we i ={op i , DE i } (3) where op i refers to an operation and DE i is a design entity. The idea behind this representation is that designers’ work can be decomposed into Work Elements, similar to building blocks which, once all completed, constitute a complete sub-task solution. Design Objectives: A complete definition of a design objective will be provided in the next section. Nevertheless, we can mention here that design objectives are explicit descriptions of a designer’s value system regarding the task at hand. They are generated by the 60 designers to clearly express what are the key factors he is considering in his decision making process. Resource: We define a Resource (R) as the various means and tools used by designers and managers to perform work elements in order to achieve their assigned tasks. We define a limited set of resources necessary to cover all design activities: Computation resources, Modeling resources, Communication resources, Methodological resources, Database resources, and Manufacturing resources. The table below provides example for each category. Resource Class Example Computational and simulation resource Simulation software (FEM, …) Modeling tools CAD/CAM tools Communication resources Email, word processor, … Methodological tools Intranet-based methodology documents Database Suppliers’ catalogue Manufacturing tools CNC machine Table 4.1: Resource classes of ANED Design Task: Using the previous definitions, we can now define the term Design Task (T), which consists of the 3-tuple: T i ={(DO i j , we i j , R i j )} (4) 61 Therefore, a design task is composed of a number of sub-tasks, each of which is a set of design objectives, work elements and resources. Figure 4.2 is a representation of a design task according to this model. Figure 4.2: Design Task structure Using the definitions above, we are able to describe design tasks, what they entail, which design entities, resources are involved and what objectives the designer wishes to achieve by choosing such or such way of completing this very task. In the next section, we are going to expand on the concept of design objective, to underline how such objectives are driving the design activity of designers, and how sharing those objectives can improve the collaborative process according to decision and value theory. Legend Design sub-task Resource R Work element Design objective we DO we 1 1 we 1 3 we 1 4 DO 1 1 DO 1 1 DO 1 3 DO 1 2 R 1 4 R 1 3 R 1 5 Task T 1 62 4.2.2 Value and Design objectives Designers have personal values which characterize what is important to them in their activity. When working on a specific design problem, this value is expressed through design objectives that the designer aspires to, based on the functional requirements to achieve. Adapting from Danesh [32], we define a Design Objective (DO) as a purpose that a designer wants to achieve in a design activity, a direction towards which he’s aiming, and a design context or scope in which the objective is defined. In addition, a design objective can encompass a number of attributes used to describe how well a given objective is achieved, as well as an evaluation function providing (in a unit-less and scalar form) an assessment of the value generated by different alternatives . Let’s look at each of these items in detail: Purpose: introduces the performance, physical or functional property involved in the objective. Manufacturing cost, curb weight or weight distribution are examples of such purpose in vehicle design. Direction: clarifies which direction the designer prefers for the purpose. It can either be minimize or maximize. For instance Minimize manufacturing cost or minimize curb weight. Most of the time, this direction is obvious and could be omitted. Scope: describes the sub-space of the design space related to the design objective. Vehicle design is a general scope, while body design, or engine design are examples of smaller scopes. 63 Attributes: are used to measure the level of achievement of a given objective by a selected alternative. One or more attributes may be used to quantify this achievement, and each is associated with a specific unit. For instance, Maximize compactness can be measured by volume(m 3 ) or Maximum dimension (m) Function: is an actual value function that converts the performance (measured by the attributes) of each alternatives against the design objective and is used to rank the alternatives from most to least desirable. A design objective is thus represented by: <DesignObjective>::= <Direction> <Purpose> in <Scope> measured-by <Attributes> evaluated-by<Function> (5) An example of such a design objective could be: <maximize> <fuel economy> in <Vehicle Body design> measured-by <C D (drag coefficient), Projected EPA (mpg)>evaluated-by 5 types of objectives are identified: o Physical objectives: objectives related to physical characteristics at the embodiment design stage such as: <minimize> <weight> in <shaft design>. 64 o Functional objectives: these objectives related to the level of performance of a design solution, for instance <minimize> <fuel consumption> in <engine design> o Economical objectives: objectives related to the expected cost or profit generated by a given design alternative, such as <minimize> <manufacturing cost> in o Ergonomic and Environmental objectives: objectives related to the quality of the interaction between the artifact designed and its user, or between the artifact and the environment in which it is used. Examples of such objectives can be <maximize> <ease of use> in <handle design> or <maximize> <recyclability> in <material selection>. o Managerial objectives: objectives related to the design project performances and characteristics. <minimize> <lead time> in <vehicle design> or <maximize> <ease of access> in <design methodology documents distribution> Design objectives, are thus an expression of the designers’ value system, and have a tremendous impact on the design decision-making. In ANED, design is seen as a decision-making process, and as such is directly related to value. Every design task is seen as a design decision problem. Based on results from the decision theory research field, we adopt the PRoACT method as a suitable way to approach a decision problem 65 (Hammond et al. [57]). With minor modifications, this method can be suited to the engineering design environment. The PrOACT steps become: 1) Understand the design problem (or task) 2) Define design objectives and develop structures of design objectives in order to explicitly link design objectives to design context information for alternatives generation 3) Generate design alternatives (see special conditions below) 4) Evaluate the consequences of each alternative on the rest of the design process 5) Make tradeoffs between design alternatives, based on value assessment. The first step is common practice in engineering design work (as in the systematic design approach [87]). The second step is also similar to what it may be for classic decision-problems, and consists in sorting the means and ends objectives as well as putting them into perspective and realizing their respective influence on the decision. Creating a design objective structure can be difficult, but is a key step to relate each objective to the appropriate design context elements. While creating this structure, designers are also structuring their design space exploration and getting a better understanding of design alternatives available to them. The third step of the PrOACT model recommends a thorough search of the potential alternatives which is not suitable to the design world. Indeed, unlike a general decision problem, a design problem can have an infinite number of suitable solutions; therefore we must specify here that the search should be limited to the minimum number of design alternatives 66 giving the decision maker a comfortable level of confidence, i.e. no better solution than the ones in the set he currently has generated can be found (some may exist, but cannot be found for various reasons such as limited scientific knowledge, …). In most cases, the designer will use his experience and know-how to determine which alternatives are likely to be successful and which should be discarded right away. We can note that this step is a good test to separate novice from expert designers. The last two steps are similar to the general PrOACT method, and lead to the elicitation of a best alternative and a ranking list containing the most preferred alternatives. Figure 4.3: Design Objective structure for a flossing device design problem Let’s underline here that for the local decisions (i.e. decisions made by a designer without interaction with anyone else), designers usually proceed according to that list, attempting to solve their problem using the first alternative, and if this alternative reveals unsatisfactory, they try out the next one, and so on. The figure above represents a preliminary objective structure for a reusable device simplifying teeth flossing. Design a portable and reusable device to facilitate teeth flossing Maximize ergonomics Minimize Cost Maximize ease of use Maximize life span 67 Design objectives structuring In our research we have developed two methods to facilitate design objectives elaboration and structuring: Decomposition and refinement. Each of these methods can be applied to the purpose or the scope of a design objective. Table 4.2 below describes each of these methods and provides simple examples. Definition Examples Purpose Refinement: < Sc 1 > => < Sc 1 > where causes <minimize> in < vehicle development >=> <minimize> in < vehicle development > Purpose Decomposition: < Sc 1 > => < Sc 1 >∩< Sc 1 >∩ … ∩ < Sc 1 > where = ∩∩…∩ <minimize><vehicle noise> in < vehicle development >=> <minimize><engine noise> in < vehicle development >∩ <minimize> in < vehicle development > Scope Decomposition: < ScC 1 > => < Sc 1-1 >∩ < Sc 1-2 >∩ … ∩ < Sc 1-n > where <Sc 1 > = < Sc 1-1 >∩< Sc 1- 2 >∩…∩< Sc 1-n > <minimize><cost> in <vehicle development>=> <minimize><cost> in <vehicle design>∩ <minimize><cost> in <vehicle manufacturing>∩ <minimize><cost> in <vehicle materials> Scope Refinement: < Sc 1 > => < Sc 1-1 > where < Sc 1-1 >⊂ <Sc 1 > <minimize><cost> in <vehicle development>=> <minimize><cost> in <vehicle materials> Note: If the designer thinks both design and manufacturing are fixed costs, he/she may focus on only the material cost when making design decisions. Table 4.2: Design Objective Structuring Methods and Examples 68 Below is a brief description of each of these methods: Purpose decomposition: consists in decomposition a top –level objective into sub-objectives with more specific purposes. Purpose refinement: consists in focusing on a specific area of concern to refine an objective and clarify it. Scope decomposition: The scope of a design objective can be decomposed in order to generate sub-objectives whose scopes are both related to the original top-level scope. For instance, cost may be related to both material selection and manufacturing process. Scope refinement: Scope refinement elaborates a design objective into a lower level one by focusing its scope to a more specific one. For example, for ship design problems, both design cost and manufacturing cost are fixed costs. A designer may pay attention to variable costs by focusing specifically on materials. So he/she may elaborate the design objective “<minimize><cost> in <ship development>” into “<minimize> <cost> in <materials>”. In this case, the scope <materials> is much more focused than <ship development>. Equipped with such tools, the designers can systematize their personal decision- making process and ensure better results. We are going to look into joint decision- making in the next section and study how this model can be adopted to those decisions. 69 4.2.3 Decision History Tree In order to keep track of decision points, we introduce the concept of decision history tree (DHT), which is similar to Ran & Kuusela’s [102] Design Decision Tree (their model being limited to software design applications). This tree is a representation of the design process, and consists of a succession of two types of nodes: Tasks and Decisions. We have already introduced how we model a design task as a set of design objectives, resources and work elements. We will see below how we model a design decision as well. Figure 4.4: DHT for a flossing device The design history tree is a powerful tool to model and keep track of what can be referred to as the “design space exploration”, meaning the various strategies implemented to solve a design task and its sub-tasks. There is one design tree per designer, since every designer is a decision maker in the design process. Below is a representation of a decision history tree for a simple design task. Assume the design task consists of designing a device that can be used to floss teeth using only one hand. Task T 1 T 11 T 12 T 111 T 112 T 121 T 122 A 111 A 112 A 121 A 122 Legend Task Design Decision Selected Alternative 70 To make this representation more explicit, we list here possible tasks and alternatives corresponding to the design of a flossing device: o T 1 : Design a flossing device which can be used with only one hand o T 11 : Create a refillable flossing head o T 111 : Create a fixing mechanism for the floss allowing refill o T 112 : Create an ergonomic head to facilitate access to all parts of mouth o T 12 : Create a handle-like shape for the device’s body o T 121 : Create an ergonomic, easy-to-hold, shape for the handle o T 122 : Adapt Structure to support expected load The different alternatives A 111 , A 112 , A 121 and A 122 are specific design solutions to each of the low level sub-tasks. All these sub-tasks solutions, once aggregated constitute a final design solution for the global design task T 1 . For instance, A 111 may use a pinching mechanism, A 112 could be in a U shape, A 121 may use a flat oval shape to facilitate orientation and grip, and the overall structure may be derived from structure similar to an I-beam to resist the different mechanical constraints applied. Figure 4.4 represents an “ideal” process, where each sub-task was completed in one single attempt, reaching suitable alternatives. Most of the time, this is not the case and a number of design alternatives have to be created before a suitable is found. The 71 following figure represents part of the design task of Figure 4.4, in the situation where several alternatives (A 111 a , A 111 b , A 111 c ) were generated before the final choice was made to complete task T 111 . To continue with the example introduced earlier, we can imagine a situation where the designer had to go through two potential alternatives of fixing mechanisms to finally select the pinching mechanism (For instance, A 111 a can be a mechanism based on the use of a coil of floss unwinding on one side and rewinding on the other – process similar to the way correction tape dispensers work- and A 111 b could be a head with protruded heads on the sides, around which the floss can be wound). Figure 4.5: Part of a DHT with multiple alternatives for task T 111 The rejected alternatives can encompass entire tasks, or task decomposition branches, which can be revisited during a backtracking, and even replaced by a better decomposition and completely abandoned. This type of modification of the design T 11 T 111 T 112 A 111 c A 112 A 111 b A 111 a Legend Task Design Decision Selected Alternative Rejected Alternative side view Floss Handle 72 process is a major contributor to what we call the Design Space Exploration, referring to how much of the virtual solution space has been explored. The last particularity of the decision history tree we would like to point out is related to the inherently collaborative aspect of design. In the collaborative design setting, designers’ decisions are intertwined, and directly or indirectly affect each other. More often than not, designers are faced with conflict opposing them to one or several of their team partners and they initiate a negotiation dialogue (most of the time informally), in order to resolve the conflict. We advocate that, along with the unsuccessful design attempts, the negotiation dialogues between designers affecting design decisions should be recorded. Indeed, these exchanges are a rich source of meaningful data to explain the rationale of the design decisions made (designer A made decision D after contacting designer B and negotiating a deal D with him). Figure 4.6: Representation of collaborative decisions in DHT In addition to the structure of the design process, we will keep track of the design data related to each task and decision (using their components – work elements, Designer-2’s Decision History Tree Designer-1’s Decision History Tree Task Local Decision Collaborative/joint Decision Solution (rejected) Solution (final) Leads-to (active) Leads-to (inactive) Negotiate-With Legend 73 design objectives, resources, etc…) in order to have a complete and accurate snapshot of what was done, how and why. In the next section, we look into details at design decisions, how they are made, and what are their consequences. 4.2.4 Design conflicts and Joint Design Decision Decision-making usually focuses on the choice among several alternatives (Keeney [40]); we will consider in our case that this choice is motivated by a desire to solve design problems. We distinguish two types of decisions: individual decisions made by designers, and which are mainly problem-solving activities, and joint decisions, made collaboratively by designers who are sharing a common goal but opposing over issues related to their activity. In this section, we take a closer look at joint decisions, and first establish an exhaustive list of the possible conflicts to be handled. Conflicts in design The conflicts we identify are directly related to our design context model, i.e., these conflicts can be: Over Design Entities: Parameters, Working Principles, Parts, assemblies. Typically, these conflicts occur as one designer’s progress is hindered by the local decisions made by another designer whose work interfaces with the first one. For conflicts over parameters, problems of clearance, parts interference or unreachable parameter values are obvious examples. 74 Over Design Constraints: design constraints as they have been defined earlier are a significant source of conflicts. If we consider only the case of system constraints, which are related to the way pieces of a system fit together, it is patent that some conflicts occur very often at this level (a perfect fit on the first try is rarely achieved) Over Functional requirements: Functional requirements are similar to constraints in their impact on the designer’s task and thus produce the same effects. We can imagine many situations where functional requirements lead to conflicts, for instance, the set {maintain payload capacity, reduce overall volume to 1000 cu-in} for a container design problem. Over Design Objectives: The design objectives of designers working on the same project may clash, especially if those designers have expertise in different fields, and do not communicate efficiently enough. This conflict category is related to the strategic decisions made during design rather than low-level operations (as defined above). Over Resources: Resources may be a source of conflict for multiple reasons. We presented above several resource classes and each can be subject to conflict situations. For instance, incompatibilities between software may cause problems. In case the work of a designer is reused in a later phase of the design by another person the format compatibility should be guaranteed as early as possible. Over Work Elements: work elements are the building blocks of the design (elementary steps of a task resolution) and as such, they can be sources of 75 conflicts. While one designer may try to force X 1 ’s value to 5 mm, another designer may have locked in a parameter X n to a value that won’t allow X 1 to be set equal to 5. This is a low-level, solution-related type of conflict. Over Design Tasks: design tasks can be clashing or people may be working on the same task, creating incompatible or redundant solutions. In addition, task decomposition is not always perfectly coordinated and solutions aggregation turns out to be impossible in this case. In this work, we decided deliberately to ignore conflicts related purely to inter- personal relationships. This could be the topic of a whole new research work, trying to model what those inter-personal conflicts can be and how to manage them. We follow the principle of Full Open Truthful Exchange 184[99] (Raiffa), and assume that the designers are willfully helping each other and don’t hold information back, or behave maliciously in any way. In the previous section, we introduced a method suitable to handle local decision making. For collaborative/joint decisions, the situation is different. We consider that the decision is motivated by the emergence of a conflict, and that the decision is made to overcome this conflict and enable both parties to go back to their activity. We advocate that each party should initially proceed as described in section 4.2.2, prior to the encounter, in order to gather all the information needed. Once they come to the negotiation table with a list of acceptable alternatives, they attempt to align their perspectives and identify common grounds on which a mutually acceptable solution can be built. 76 Figure 4.7: Decision model in ANED We represented on Figure 4.7 the way joint decisions are envisioned in ANED. Once the conflict is identified, designers should put together the data related to it (such as the constraints they need to respect, the parameters they can adjust, etc...). Based on this collection of constraints, requirements, parameters, and the set of design objectives, the designers identify the type of conflict they are faced with. We distinguish two sets of conflicts (See Figure 4.7 above): Conflicts involving quantifiable properties (numerical values), and for which finding reservation points (RP) as well as a ZOPA (or Zone of Possible Agreement – a detailed description of ZOPA will be given in 3.3.3) is possible. Those conflicts are generally over parameters’ values, and can be solved using the ZOPA model. Once the ZOPA is established, the negotiation becomes similar to a game theory problem. Parties formulate offers successively by making concessions, until a firm agreement is reached (I.e. an Case where RP and ZOPA exist Case where no ZOPA exists 77 alternative is selected (SA for “Selected Alternative”). In case no ZOPA is found (i.e. there is no overlap between the ranges chosen by the parties), the conflict is considered as a non-numerical problem, and handled the same way the second set of conflicts is, as described below. Conflicts involving non-quantifiable properties. These conflicts can range from style, to ergonomics concerns, resources or task decomposition. They cannot be solved simply as the ZOPA model is not directly applicable; they require therefore a more strategic approach. Some effective strategies must be generated in order to guide the designers, and ensure they move in each other’s direction. We investigate the strategy selection issue in the next section. 4.3 Argumentation-based negotiation 4.3.1 Argument model In our ABN protocol, we adopt Toulmin’s model [129] of argument structure, based on the data-claim-warrant elements. Toulmin proposed that the first step in an argument exchange is for one party to express an opinion, called “claim”. If the claim is challenged, it has to be defended by “data” and “warrant” successively. This model is relatively simple and powerful enough to suit our purpose. 78 Figure 4.8: Toulmin’s (1969) Argument Structure and Example In this model, when negotiation starts a designer makes a “Claim” (“Hinge position h g should be 20cm<h g <25cm.”). If the claim is challenged by another designer, then the designer adduces “Data” (“Door size D s =60cm”) to defend it. If the challenger is still not satisfied with the data, then a “Warrant” (“If sports car, then h g < 0.5 D s ”) can be supplied by the designer, either voluntarily or at the request of the challenger. A “warrant” can be either a rule that states the relation between claim and data as shown in Figure 4.8, or a related higher-level issue. In this case, if the challenger starts to challenge the “warrant”—i.e., the higher-level issue, the negotiation moves to a higher-level in which the “warrant” becomes a “Claim” and negotiation continues. When a claim is challenged, the data that is provided depends on the warrants that the party is prepared to operate with, meaning that the data is not chosen randomly but is actually part of a warrant that party may or may not need to express in the future. We introduce below an exhaustive list of data, claims and warrants that are used in our model to support design negotiation. We use the Backus Naur Form to represent them. Data (Door side size D s =60cm) so: Claim (Hinge position should be 20cm<h g <25cm) since: Warrant (If sports car, then h g < 0.5 D s ) 79 Claim A claim is the first step taken by a designer in a negotiation process he has initiated to resolve a conflict situation. The purpose is to provoke awareness in the mind of the recipient that the current value or configuration of one (or several) design entity (ies) is going against that party’s wishes and should be modified. Therefore the structure of the claim should be as follows: <Claim> ::={<DE>|<FR>|<DC>|<DO>|<R>|<we>|<T>} IS <Value> | NOT ({<DE>|<FR>|<DC>|<DO>|<R>|<we>|<T>} IS <Value>) Data Data is used to provide a justification to a pre-expressed claim which was challenged, or to back up a claim that is made in the same argument. <Data> ::={<DE>|<FR>|<DC>|<DO>|<R>|<we>|<T>} HAS <Value> Warrant A warrant is also used to provide a justification, but it is relied upon only when data to back up a claim has already been provided to the other side. Warrants can be considered as rules, as they come after the “SINCE” term which proves an argument is true based on an unquestionable statement. Again, that warrant can be questioned, in which case another cycle starts, using this warrant (reformulated to match the claim 80 format) as a claim. The warrants express a direct relationship of causality between the characteristics of two design context elements. <Warrant>::= IF{<DE>|<FR>|<DC>|<DO>|<R>|<we>|<T>} IS <Value> THEN {<DE>|<FR>|<DC>|<DO>|<R>|<we>|<T>} IS <Value> Based on these definitions of claim, data and warrant, we use the following structure for the argument: <Argument>::= {<Claim>}|{<Claim> AS {<Data>|<Rule>}}| {<Claim> AS {<Data> AND SINCE <Warrant> | <Rule>}} <Rule>::= IF <Argument>|<Claim>|<Data>|<Warrant> THEN <Argument>|<Claim>|<Data>|<Warrant> <Value>::= Value or property (availability) assignable to corresponding Design Entity Value can also be “ok” or “not ok”, for instance to describe that a certain proposal is rejected because it will go against a design objective: NOT [<claim>] AS IF [<claim>] THEN [<DO> IS not ok] Using the above argument model, and the negotiation protocol below, we advocate that we can guide negotiation amongst designer to produce more valuable solutions. In our more recent research efforts, we have started to investigate various reasoning 81 method (deductive, inductive, and abductive) and are currently trying to adapt them to our framework to provide more leverage to the negotiating party. 4.3.2 ABN Protocol Rosenschein and Zlotkin’s [110] define a protocol as “the public rules by which agents will come to agreements. A protocol specifies the kinds of deals they can make, as well as the sequence of offers and counter-offers that are allowed”. In our research, we have developed a negotiation protocol based on the argumentation-based negotiation approach, meaning that the protocol facilitates the exchange of arguments between the parties involved, in order to exchange not only data but value systems as well. The benefit of this approach is that it gives a possibility to the negotiators to affect each other’s viewpoints (or stances as used in our protocol) and reach a global solution where everyone’s opinion is taken into account. We model a given engineering negotiation situation as shown below: N = [D, I, P; S, T] In this equation each letter represents the following sets: D = {d 1 , d 2 , … d n }: A set of participants, i.e., designers and/or computer agents I = {i 1 , i 2 , … i m }: A set of all types of issues that are negotiable. P = [r, q, a]: A protocol composed of : 82 communicative speech acts r={r 1 , r 2 , … r l ) negotiation states q={q 1 , q 2 , … q k } strategic actions a={a 1 , a 2 , …, a s } S = {s 1 , s 2 , … s g }: Strategies for choosing strategic actions, composed of a set of strategic rules T = {t 1 , t 2 , … t h }: Tactics for choosing proposed issues instances composed of a set of tactic rules. For a given collaborative design situation, participants, negotiable issues, the negotiation protocol and strategies are common knowledge to everyone, while different designers may have their own tactics (i.e. ways of behaving within the bounds of the strategy adopted). We will focus on strategies in the subsequent section. The negotiation protocol specifies what kind of “performative” the parties can use as a “wrapper” to explicitly pass on their arguments to the other side. In our ABN model, we chose to use speech-acts (Searle [118], Ballmer [10]), to provide the designers with a set of locutions to express their intention and unambiguously convey their state of mind regarding the claim-data-warrant exchanged. These Speech-Acts were carefully selected in order to generate the minimal set necessary to cover the range of design negotiation intentions. This choice was motivated by a desire to start with a simple and functional model, leaving the door open for a possible revision of the Speech-act set in the future development of this framework. At any moment during the negotiation process, the parties are in a given Negotiation State which describes their current intention. This negotiation state will be associated with a 83 speech act conveying this state of mind to the other party. Therefore, one or several speech acts are associated to each design state. Figure 4.9: Speech acts and ABN protocol The negotiation process is initiated when a designer proposes a claim to another one, in order to address an issue existing between them. The contacted party will consequently enter an evaluation state, while interpreting the incoming argument. Later, it will generate an argument in response to the proposal and send it out using a speech-act selected in accordance with the intention desired. The rest of the negotiation process will follow the same dynamics; designers may resort to data and warrants to back-up or question arguments, and eventually modify the stance of the other party to reach an agreement. 84 Figure 4.9 above is a representation of the ABN protocol; in this process, designer D1 initiates the negotiation exchange. At the bottom of the figure are listed the speech acts, negotiation states and strategic actions included in ANED. Let’s go through the list and define the role of each speech act with precision. Propose <Claim>: SA used to introduce an initial claim and initiate the negotiation process with another party Counter-Propose <Claim>: SA used to introduce a new claim going against another claim proposed by the other party earlier. Compromise <Claim>: SA used to express that the designer is giving in something in this claim in order to move towards an agreement. Critique NOT <claim> AS <data> (or SINCE <warrant>): SA which introduces a negated claim followed by data and possibly a warrant to justify the negation. The purpose of this SA is to convey the idea that the claim is not suitable to solve the problem as it is formulated. Defend <claim> AS <data> (or SINCE <warrant>): SA used to introduce data and/or warrant to justify or defend the claim challenged by the other party. Dissent <claim> AS <data> (or <rule> or SINCE <warrant>): SA used to reject or contradict a claim which is deemed unacceptable for obvious reasons. This SA is used to clearly express than no solution can be found by using the previous argument uttered by the other party. 85 Refine <claim1> WITH <claim2>: SA used to introduce a new claim whose content builds upon the last claim passed on by the other party. This SA proves useful in the creative thinking process occurring during integrative negotiation. Agree <Claim>: SA used to declare that an agreement is reached on the claim and that the party is committed to the agreement and will adjust its actions and activity in accordance with the agreement. Quit is not a speech act but a mere locution. It is used to end the negotiation exchange when no agreement has been reached and no opportunity of reaching such an agreement is seen by the party. We will create restrictions on the conditions under which using this locution is acceptable (to prevent any abuse). The table below presents a tentative selection of speech acts available to a party (right column) to respond to an argument introduced by a given speech act (left column). Having such rules ensures that the exchange is following a rational logic. Besides these speech acts, some rules have to be established regarding negotiation- related issues such as: rules of acceptability of arguments, respect of commitments, or rules regulating designers’ commitment withdrawal. 86 Speech Act Acceptable Speech Act in Response Propose Critique, Counter-propose, Agree, Dissent Counter- propose Critique, Counter-propose, Agree, Dissent Critique Defend, Counter-propose, Compromise Compromise Agree, Critique, Dissent Defend Agree, Compromise, Critique, Counter-propose, Refine, Dissent Dissent Defend, Compromise, Counter-Propose, Refine Refine, Agree, Counter-propose Agree Agree Table 4.3: Speech Acts precedence rules In addition, the way arguments are selected, i.e. the strategic actions selection is another topic to be addressed and will be done in this thesis work. 4.3.3 ZOPA, strategies and strategy selection Rosenschein and Zlotkin [110] define strategy as “the way an agent behaves in an interaction”. The rules of the interaction are specified by the protocol, but the exact deals that an agent proposes are a result of the strategy that his designer has put into him. In this section, we introduce the work done in our research to address the issue of strategy selection during negotiation. Often times, strategies and tactics are domain dependent and sometimes even task dependent. In the following are introduced the strategies we developed by studying collaborative design in the automotive engineering world. 87 Figure 4.10: ZOPA representation In the previous section, we have introduced two distinct sets of conflicts: quantifiable and non-quantifiable. We noted that quantifiable conflicts can be resolved using the ZOPA (for Zone Of Possible Agreement, Mnookin et al. [80]) model, developed in legal research. Figure 4.10 below is an example of such situation, the performance measure being arbitrary (it may be an engine piston displacement, the weight of a camshaft, or any other numerical value). Designer A and B each have a reservation point beyond which they will not go and decide to walk away (Quit) from the negotiation discussion. Naturally, a ZOPA can be established only when the reservation points elected by each party create a zone of overlap, within which a single deal point can be found. For situations in which the overlap is non-existent, the parties must circumvent the deadlock by following one of the strategies of ANED introduced in what follows. Performance Measure Designer A’s acceptable range Designer B’s acceptable range ZOPA Designer A’s Reservation point Designer B’s Reservation Point 88 Figure 4.11: Multi-layer representation of design activity Figure 4.11 represents the multi-layer approach adopted in ANED to describe the dimensions involved in the completion of a design task. To support negotiation strategy selection, we model the design as a multi-layer activity, in order to separate its distinct steps. By doing so, we identify four main layers, namely the Value level, the Function level, the Constraint level and the Parameter level. It is important to underline that this representation does not necessarily follow the natural flow of the design process (chronology-wise), but is rather a way to compartmentalize dimensions to serve our purpose. The natural process follows a top-down movement: starting for the company value system and its designer’s, a list of functional requirements is established. This list will guide the designers in their work by pointing out what importance should be granted to what design elements. Next, a set of design constraints will be generated to describe what kind of embodiment is acceptable. Parameter-level Constraint-level Function-level Value-level Compatible subspaces 89 Finally, designers reach the parameter level to set values on dimensions, properties, and geometry, create assemblies and generate fully detailed solutions to the task. In this research work, we argue that solving a conflict is essentially done by joining efforts to collaboratively find a ZOPA in any of these layers. Once the ZOPA is found, the parties can enter a “competitive” bargaining stage, in which they try to get the most benefits for themselves (increase their value). We have developed a set of strategies which can be applied by parties entering a negotiation phase. Those strategies are triggered by a number of conditions related to the design process. There are essentially two types of negotiation strategies: 1. Exploration: this strategy consists, at any level, in pushing the design work in new directions, by generating arguments about design context elements of the same level and thus expanding the “explored design space domain”. For instance, when parties have a conflict over a set of dimensions which do not fit certain constraints, introducing a third dimension, related to the first two and which can be adjusted to satisfy the constraints may bring up a satisfactory solution. Exploration can be compared to a distributive negotiation process, as the negotiation remains over the same subject, and aims at distributing the “value surplus” contained in each layer of the design space to reach amore valuable outcome. 90 2. Elevation: this strategy consists, at any level, in moving the negotiated topic towards a higher-level, by generating arguments about design context elements of both the current level and the higher-level. For instance, constraints guiding the maximum dimension of a part to achieve a certain fit, are limiting the design space at the parameter- level. If no agreement can be made at the parameter level by changing the parameter values, modifying the constraints and reaching a ZOPA there, will unlock the situation. Elevation can be compared to integrative negotiation, as the parties bring up a new topic to the discussion to finally agree. As we mentioned earlier, each of the two strategy types is applicable at every level, which leads to a total of 7 possible combinations (elevation is not possible at the top value-level. Let’s look into these diverse strategies available: Solution Exploration: When using this strategy, designers remain at the solution level, and explore different configurations for the conflicting elements (such as parameters values, parts positions and dimensions…). The purpose of this strategy is to ensure designers explore the solution space extensively to detect a configuration satisfactory for all parties. When following this strategy, the frequency of proposals and counter-proposals passing on new topic is fairly high. Indeed, new solutions are easy to generate as they usually require little creativity. When this strategy is implemented, the arguments generated 91 by the parties contain only solution-level vocabulary (Design entity, work element) in the claims. Restricting the scope of the domain language is used as a leverage to maintain the negotiation exchange to the solution level. Data introduced in arguments to back claims may contain language related to higher levels, since a given proposal may be rebuffed because of constraints, design objectives or other elements. Warrants have to be established prior to the formulation of any data, since the choice of data used to back up a claim can only be made and justified by the existence of a warrant containing the data at stake in the conditional part (IF) of the premise and the claim at stake in the conclusion part (THEN) of it. In addition, the data provided has to necessarily be related through the design context structure 4 to the claim backed up (i.e. the connection has to be explicit for all parties). If a party fails to provide a warrant when asked to back up a claim and data, their argument will be debunked. As a result, the domain language to be used in warrants and data is significantly constrained by the strategy adopted. The objective of this strategy is to help designers create a ZOPA by expanding the explored design space boundaries (“pushing the envelope”) towards each other until an overlap suitable for an agreement is detected. Figure 4.12 below describes graphically this strategy. The dotted-line arrows figure the explored design space “expansion” for each designer. 4 Taking a simple example: If Des-A proposes “Claim 1” and Des-B dissents: NOT “Claim 1” AS “Data1”. Then Data1 has to be such that there must exist a Warrant1:” IF Data1 THEN Claim2” where Claim2 and Claim1 are unambiguously related in the design context and mutually exclusive. 92 Figure 4.12: Solution exploration strategy representation Elevation from Solution to Constraint level (ESC): this strategy is used when the solution exploration strategy did not yield any result (even after significant expansion of each explored design spaces, no overlap seems to be found). This strategy is triggered by unlocking the set of domain language vocabulary related to design constraints (in particular the use of inequalities to introduce bounds on design entity values backed with warrant). Figure 4.13 represents the application of this strategy. Once no further exploration at the solution level can be done to reach an agreement, the discussion moves up to the constraint level (1), where a ZOPA may be identified. If so (case represented on fig. 14), the parties try to agree on a new set of constraints (2) such that when going back down to the solution level, a ZOPA can be found there (3) and the conflict resolved. In case no ZOPA is identified at the constraints level, the exploration strategy is then applied at this level, and so forth at each higher level. Similar constraints on the use of domain language in data and warrants exist when the elevation strategy is adopted. Solution level Des-A Des-B Overlap / ZOPA Initial design space explored by Des-B Initial design space explored by Des-A 93 Figure 4.13: Elevation strategy between solution and constraint levels We summarized the conditions of application of each strategy in Table 4.4 below, as well as the restrictions applied to the information contained in data, claims and warrants for each strategy. As explained earlier, the data used has to be related to the subject discussed in a clear way. Figure 4.14 summarizes all the strategies available to overcome conflict situations. Let us describe it by going through each level. The process is assumed to start with a conflict at the solution level, but would be applicable to any higher level. The parties investigate the context information (through Solution Exploration – SE) related to the conflict at hand and generate reservation points. If a ZOPA is detected, then the surplus allocation phase is engaged and an agreement found. If no ZOPA exists, Elevation from Solution to Constraint level is engaged (ESC) and a potential conflict at this level is sought and argued Constraint level Solution level Des-A Des-B ZOPA 1 No Overlap Initial design space explored by Des-B Initial design space explored by Des-A 2 3 94 about. At this level, parties may be talking about uncountable elements, and therefore a formal ZOPA as described before cannot be used, but a Constraint Level domain comparable to a ZOPA, i.e. a zone in the constraints space where designer A and B’s constraints become compatible, may be used. To facilitate qualitative ZOPA negotiation, we have developed in our research a set of semi-quantitative qualifiers to provide a metric over which designers can discuss the respect of critical unquantifiable elements. This set of qualifiers, which will be implemented in our case example in Chapter 4:, is limited to the following: S = {Very Firm, Firm, Flexible, Very Flexible} 95 Warrant contents Strategy Trigger situation Typical suitable conditions Claim contents Data contents IF THEN Solution exploration (SE) No ZOPA at Solution level Routine design DE, WE DE, WE, IC, SC, FR, and DO related to the DE,WE discussed DE, WE, IC, SC, FR, and DO related to the DE,WE discussed DE, WE Elevation Solution- Constraint (ESC) NO ZOPA at solution level after SE Routine design DE, WE, IC, SC DE, WE, IC, SC, FR, and DO related to the DE,WE, IC, SC discussed DE, WE, IC, SC, FR, and DO related to the DE,WE, IC, SC discussed DE, WE, IC, SC Constraints Exploration (CE) No ZOPA at Constraint level Routine design IC, SC DE, WE, IC, SC, FR, and DO related to the IC, SC discussed DE, WE, IC, SC, FR, and DO related to the IC, SC discussed IC, SC Elevation Constraint- Function (ECF) No ZOPA at Constraint level after CE Routine/Non routine design FR, IC, SC DE, WE, IC, SC, FR, and DO related to the FR, IC, SC discussed DE, WE, IC, SC, FR, and DO related to the FR, IC, SC discussed FR, IC, SC Function Exploration (FE) No ZOPA at Function level Non-routine design FR DE, WE, IC, SC, FR, and DO related to the FR discussed DE, WE, IC, SC, FR, and DO related to the FR discussed FR Elevation Function- Value (EFV) No ZOPA at Constraint level after FE Non-routine design FR, DO DE, WE, IC, SC, FR, and DO related to the FR,DO discussed DE, WE, IC, SC, FR, and DO related to the FR,DO discussed FR, DO Value Exploration (VE) No ZOPA at Value level Non-routine design DO DE, WE, IC, SC, FR, and DO related to the DO discussed DE, WE, IC, SC, FR, and DO related to the DO discussed DO Table 4.4: Strategy application rules and conditions Once a ZOPA is established, a solution can be found, new design constraints are generated and the lower-level issue is resolved. In case no zone of overlap is encountered at the constraints level, the second exploration method, Constraints 96 Exploration (CE), is implemented. The goal is to encourage designers to modify their constraints sets in order to create a situation where these sets become compatible. This is achieved by forcing designers to exchange arguments regarding these constraints and question their legitimacy. Once these sets are rendered compatible, new design constraints are generated and the designer can carry on with their tasks. Figure 4.14: Multi-layer model with strategies representation If a ZOPA cannot be found at the constraints level, ECF (elevation from Constraints to Function level) is implemented, and a similar process is initiated, but designers argue about function at this point. The same pattern is applied at this level and at the next (Value Level). In case the value exploration strategy proves unfruitful, the only alternative left for the designers is to redefine the design tasks to make them Designer A DE A DE B New DE A DO A DO B DC A DC B FR A FR B No Yes New DE B Yes Yes No No New DC A New DC B New FR A New FR B SE CE FE ESC ECF EFV New DO A New DO B VE Yes No Issue over DE Designer B Parameter Level Constraints Level Functional Level Value Level FL ZOPA Negotiation results PL ZOPA Task redefinition Strategies VL ZOPA Issue over DC Issue over FR Issue over DO CL ZOPA 97 compatible. Such a redefinition entails compromises on both ends and usually leads to less than optimal designs. In what follows, we present a case study putting the theory of ANED into perspective through a number of scenarios emphasizing the framework’s benefits. 98 4.4 A case study example: Trunk design problem 4.4.1 Scenario and hypotheses In this section, we introduce a case example based on the configuration of a hinge mechanism used to open the trunk on a hatchback vehicle. We consider a problem involving 3 designers each working on different subtask of the project. The figure below represents the overall configuration of the system, looking at the side of the vehicle. We simplify the real 3D situation by using a 2D model of the vehicle rear end, and representing the locking mechanism, gas spring, and hinge in a common plane, even though they belong to different ones (the ‘y’ direction is ignored). Figure 4.15: Configuration of the trunk design problem In this design problem, several issues have to be handled. First, the external shape of the trunk has to closely match the lines determined by the style department in order Locking mechanism Trunk Gas spring Hinges Rear body panel 99 to give an eye-pleasing result. On the other hand, the trunk needs to incorporate multiple functional surfaces on its inner surface to achieve various functions, such as enclosing the locking mechanism, providing support surfaces for the hinges, as well as fixing points for the gas springs. This challenge is resolved by using a hollow part made of the assembly of an inner and an outer panel. The inner panel contains all the functional surfaces while the outer shell respects the style. The second issue to deal with is related to the ergonomics of the trunk opening, and more specifically the kinematics of the opening movement. The trunk has to be easily open by customers of average size and force; therefore, the forces to apply on the trunk handle at opening and closing must be controlled. These forces depend strictly on the geometry of the system (i.e. where the gas springs are fixed and where the hinges are located), and the force of the gas springs selected. Finally, the last issue to deal with is the proper alignment and match with the rest of the vehicle’s body. The transitions have to be smooth on the outer parts, while the functional surfaces have to be in proper positions to guarantee that the functional requirements will be addressed. We chose this design problem because it involves three main parts with high dependencies between them; therefore in order to achieve a satisfactory solution in an efficient manner the designers will not only have to achieve task-level coordination, but value-level coordination as well. First, let’s introduce the players and their respective responsibilities in the overall design task; we will then introduce a detailed list of their design objectives and the functional requirements and constraints they each have to respect. 100 Designer Design Objectives Category <maximize> <functional surfaces integration> in <trunk design> Functional <maximize> <waterproof ness> in <trunk design> Functional <minimize> <weight> in <trunk design> Physical A <minimize> <cost> in <trunk design> Economical <maximize> <ease of use> in <handle positioning> Ergonomic <maximize> <ease of use> in <gas spring configuration> Ergonomic <minimize> <cost> in <hinges design> Economical B <maximize> <robustness> in <hinges design> Functional <maximize> <functional surfaces integration> in <rear body design> Functional C <maximize> <waterproof-ness> in <rear body design> Functional Table 4.5: Initial Design objectives of each designer Designer A is in charge of completing the trunk design. This task includes designing the inner and outer shell of the trunk, as well as ensuring that the functional surfaces are properly positioned to receive the locking mechanism, hinges, and the gas springs. In addition, the trunk in a closed position must be waterproof, which constitutes another constraint on the model, i.e. the sealing joint must be pressed in a homogeneous way (i.e. the surfaces of the trunk pressing against it must be perpendicular to it). Designer B is in charge of the kinematics and ergonomics of the trunk. He is responsible of the positioning of the gas springs, the trunk handle (we will consider that the grabbing point is the same for both movements – opening and closing), and the hinges. He has to ensure that the forces required to open and close the trunk are matching the ergonomics functional requirements Designer C is in charge of modeling the rear body of the vehicle, in particular the interface with the trunk, the hinges surface, the alignment of the locking mechanism with the hook fixed on the body, as well as the positioning of the sealing joint. 101 Table 3.5 lists the design objectives pursued by each designer in their respective tasks. They will affect each one of their decisions. Our argument is that if these are shared, the objectives of one designer will affect the decisions of another designer, and the outcome of this exchange will be an increased compliance between sub- solutions. Let us clarify the responsibilities over the parameters of the system as well. Figure 4.15: Configuration of the trunk design problem is a parameterized representation of the design components and Table 4.6 summarizes which parameters fall under the responsibility of each designer. We will assume that the origin is fixed and that Designer C has no control over its position. Designer Parameters responsibility A X2, Z2, Theta3, X6, Z6 B Theta1, Theta2, X3, Z3, X5, Z5, L1 C X1, Z1, X4, Z4 Table 4.6: Parameters responsibility of each designer Finally, let’s introduce the functional requirements considered in the design, as well as the design constraints, which will be dealt with and discussed during the design (Table 4.7). To keep the design problem simple, we further assume that Designer B can choose a gas spring only from the two alternatives shown in Figure 4.16. Therefore, the only two configurations possible for Designer B are L=279.4 mm or L=320.8 mm. The positions of the fixing points P 4 = (X4, Z4) and P 6 = (X6, Z6) are dependent and 102 directly related to the length of the gas spring (√((X6-X4)²+(Z4-Z6)²)=L). Designer B must make a selection here, in order to complete his task. Designer Functional Requirements Design Constraints A • Provide soundproof-ness • Provide clear rear visibility under any conditions • Ensure proper integration of functional components • Prevent access to interior space when desired for safety of belongings • Ensure smooth continuity between body and trunk • Provide opening angle of 85 deg • Maintain rear sightline to 12 feet for an average adult driver • Limit trunk weight below 20 lbs B • Maintain waterproof-ness between car body and trunk lid • Provide easy access to rear cargo space • Limit force needed at opening to 40 N • Limit force needed at closing to 35 N • Limit self-opening angle 1 to 40 deg • Limit self-closing angle 2 to 20 deg 1: angle beyond which the trunk needs no external force to open 2: angle beyond which the trunk needs no external force to close C • Ensure proper integration of functional components • Control hinge position to avoid interferences between trunk top part and rear top body • Optimize fixation point position to avoid interferences with other parts • Limit displacement of fixation points under loading to +/- 0.05 mm • Provide 5 mm adjustment space for hinge positioning Table 4.7: Functional requirements and design objectives Part number R: Ext. length P: Stroke Q: Comp. Length Forces (lbs) G1 431.8 152.4 279.4 75 G2 498.6 177.8 320.8 60 Figure 4.16: Suitable gas springs for designer B’s task 103 In the following, we present three realistic application scenarios of our framework to this problem. The first scenario describes the situation in which potential conflicts are at the parameter value level and ZOPA is attainable. The second scenario illustrates a situation where no ZOPA exists at lower level and higher-level ZOPA must be identified and negotiated. In the last scenario, we describe a co-constructive negotiation in which higher-level negotiation yields innovative design ideas. 4.4.2 Resolution Let’s consider the task of designer B of setting up the gas springs in a proper configuration in order to respect the “provide easy access to rear cargo space” requirement and the design constraints listed in Table 4.7. We will assume that the position of the hinges has been decided beforehand. At parameter-level, designer B needs to set proper values for the following parameters: X4, Z4, X6 and Z6. In addition, he needs to select suitable values for the gas spring characteristics, i.e. its length, stroke and force (i.e. choose between G1 and G2) 4.4.2.1 Parametric Value / Solution Level negotiation (Scenario 1) Case 1: a ZOPA is found Designer B sends a request for the creation of point P6 at (510, 295)) to designer A and point P4 to designer C. Let us assume that designer A cannot create the required fixation point. Designer A, who is unable to complete the task requested by Designer B will contact him to attempt solving the problem. We frame the negotiation exchange using our negotiation protocol, and its performatives. 104 The objective of both parties is to identify a ZOPA that will help them to solve this qualitative issue. This ZOPA is actually two dimensional as both x and z coordinates are to be decided upon. As long as this strategy is in order, the claims are limited to solution level. Designer A initiates the negotiation by suggesting a new point P6. The default strategy implemented here is the parameter level exploration (i.e. claims are made about parameter values only). 1/ Designer A: Propose [X 6 IS 530 mm] & [Z 6 IS 295 mm] 2/ Designer B: Critique NOT [X 6 IS 530 mm] AS [need more information] 3/ Designer A: Defend [X 6 IS 530 mm] SINCE IF [X 6 IS 510 mm] AND [Z 6 IS 295 mm] THEN [P6 IS NOT on Curve C1] AND [<maximize> <functional surfaces integration> in <trunk design> IS NOT ok] 4/ Designer B: Counter-Propose [P 6 IS on Curve C1] AND [Z 6 IS >265 mm and <285 mm] 5/ Designer A: Critique NOT [Z 6 IS >265 mm and <285 mm] AS [Need Justification] 6/ Designer B: Defend [Z 6 IS >265 mm and <285 mm] SINCE IF [Gas Spring G1 IS selected] AND [Z 6 IS <265 mm or >285 mm] THEN [Limit force needed at opening to 40N IS not-ok] 7/ Designer A: Compromise [P 6 IS on Curve C1] AND [Z 6 IS >280 mm] 8/ Designer B: Agree [P 6 IS on Curve C1] AND [Z 6 IS >280 mm] 105 9/ Designer B: Propose [Z 6 IS 280 mm] 10/ Designer A: Agree [Z 6 IS 280 mm]. The parties have agreed on a final value determined by the intersection of a curve C 1 and a parallel plane at Z 6 =280 mm. The agreement is the result of the determination of a ZOPA identified after designer A compromises to a Z 6 superior or equal to 280. The ZOPA is thus [280, 285] and at the first iteration, the value of 280 is accepted as an acceptable value for both parties. The negotiation may have taken a more competitive side, requiring several proposals. Here designer A’s position is fairly flexible and he accepts 280 mm right away. While remaining at the solution level, designer A could have generated an argument supporting the use of gas spring G2, for instance at step 7/: 7/ Designer A: Propose [Gas Spring G2 IS selected] Therefore multiple solutions can be generated depending which direction the parties are taking in their communication exchange. Case 2: no ZOPA is found In case no ZOPA is found at the parameter level, the negotiation may be oriented to the upper level: constraints level (ESC strategy) to resolve the conflict. Such a situation is presented below. After Designer B invokes a design constraint in a warrant, Designer A can generate an argument including a claim about this constraint, such as: (…) 106 7/ Designer A: Propose [Limit force needed at opening to 50N] 8/ Designer B: CounterPropose [Limit trunk weight below 10 lbs] 9/ Designer A: Critique NOT [Limit trunk weight below 10 lbs] AS [Minimize cost in trunk design IS NOT ok] 10/ Designer B: Compromise [limit trunk weight below 15 lbs] AND [limit force needed at 45 N] 11/ Designer A: Agree [limit trunk weight below 15 lbs] AND [limit force needed at 45 N] The compromise reached here is at the constraints level. The new set of constraints is not so stringent and designers can find a satisfactory solution. In the next scenario, we look into non-quantitative issues. 4.4.2.2 Objective Level exploration (Scenario 2) In this scenario we demonstrate how ZOPA at higher and qualitative level can be explored and recognized for reaching an agreement. Let us assume a situation where Designer B is attempting to fulfill the following design objectives: <maximize> <ease of use> in <handle positioning> <maximize> <ease of use> in <gas spring configuration> Assume further that the only attainable gas spring configuration after negotiation with Designers A and C, is such that the handle has to be positioned lower than previously expected. As a result the user would have to reach down. Although the forces needed would be maintained within the boundaries set by the design 107 constraints, the awkward user’s arm position renders the maneuver actually more difficult. In order to solve this deadlock, Designer B initiates a negotiation process with Designer A over their respective design objectives, in the hope of influencing the other side to change his design objectives and reach a compromise situation. As described above, to facilitate qualitative ZOPA negotiation, we introduce a set of semi-quantitative qualifiers to provide a metric over which we can discuss the respect of unquantifiable elements: very firm, firm, flexible, and very flexible. The strategy implemented here is the objective level exploration. 1/ Designer B: Propose [<maximize><functional surfaces integration>in <trunk design> IS flexible] 2/ Designer A: Dissent: [<maximize><functional surfaces integration>in <trunk design> IS very firm] SINCE IF [<maximize> <functional surfaces integration>in <trunk design> IS flexible] THEN [<Ensure proper integration of functional components> IS not-ok] 3/ Designer B: Counter-propose [<maximize><functional surfaces integration>in <trunk design> IS firm] 4/ Designer A: Compromise [<maximize><functional surfaces integration>in <trunk design> IS firm] AND [<maximize> <ease of use> in <handle positioning> IS flexible] 5/ Designer B: Critique NOT [<maximize><ease of use> in <handle positioning> IS flexible] AS [Need Justification] 108 6/ Designer A: Defend [<maximize><ease of use> in <handle positioning> IS flexible] SINCE IF [<maximize><ease of use> in <handle positioning> IS flexible] THEN [<Move trunk handle upwards> IS ok] AND [<move P 6 up to Z 6 =285 mm>] Designer A suggests here that relaxing the design objective to a lower level of importance will enable the designers to create a new work element, moving the handle position up to Z=285mm (previously adopted as a boundary of the ZOPA at the parameter value level), and resolving the issue (the handle reaching a more suitable position). The designers, through the exchange of arguments have been able to create the equivalent of a ZOPA by conceding on the stringency of their design objectives. Designer B consults Designer C to determine how high the handle can be moved while maintaining loosely the design objective on forces to apply (Designer C will move his fixation point P4 up to maintain somehow the efforts values). 7/ Designer B: Agree and Acquire information: [Designer C] 8/ Designer A: wait. Reaching a satisfactory value for the handle position with Designer C, Designer B comes back to finish the process with designer A: 9/ Designer B: Refine [<maximize> <ease of use> in <handle positioning> IS flexible] and [<Move trunk handle upwards by 110 mm> IS ok] 10/ Designer A: Agree [<Move trunk handle upwards by 110 mm> IS ok] 109 11/ Designer B: Agree Figure 4.17 represents the result of the negotiation process over design objectives on the design itself. The gas spring and the handle are both moved up as designer A and B compromise on their design objectives. The resolution of high-level conflicts led to a solution at the bottom parameter value level. Figure 4.17: Result of Negotiation over Design Objectives (Scenario 2) 4.4.2.3 Objective-level Negotiation and task redefinition for Innovative Ideas generation (Scenario 3) Let us consider the case example used in Scenario 1, and assume that no ZOPA is found through the exploration at the solution level. As a result, another approach has to be used. Let’s first look at the decision history tree at the point of the conflict: Final handle position Initial handle position 110 Figure 4.18: Decision history tree Designer A cannot perform the task requested by Designer B, as the negotiation proceeds, objective level information is analyzed and as no solution seems reachable, a task redefinition phase becomes necessary. We envision that such a task redefinition can be used to generate innovative ideas. 1/ Designer A: Propose [X 6 IS 530 mm] AND [Z 6 IS 295 mm] 2/ Designer B: Critique NOT [X 6 IS 530 mm] AS [need more information] 3/ Designer A: Defend [X 6 IS 530 mm] SINCE IF [X 6 IS 510 mm] AND [Z 6 IS 295 mm] THEN [P6 IS NOT on Curve C1] AND T A 1 T A 1-1 T A 1-2 T A 1-1-2 T A 1-1 : Design a 2 Panel Assembly T A 1-2 : Design an Assembly method T A 1 : Design trunk parts T B 1 : Design opening mechanism T B 1-2 : Select gas springs T B 1-1 : Determine gas springs fixing points Designer A’s tree Designer B’s tree Manager’s decision Design trunk Design rear body Designer C’s T C 1 : Design rear body model T C 2 : Integrate functional surfaces T A 1-1-1 : Design Inner Panel T A 1-1-2 : Design Outer Panel T A 1-1-1 T B 1 T B 1-1 T B 1-2 T C 1 T C 2 111 [<maximize> <functional surfaces integration> in <trunk design> IS not-ok] 4/ Designer B: Counter-Propose [P 6 IS on Curve C1] AND [Z 6 IS > 265 mm and < 285 mm] 5/ Designer A: Critique NOT [Z 6 IS >265 mm and <285 mm] AS [Need Justification] 6/ Designer B: Defend [Z 6 IS >265 mm and <285 mm] SINCE IF [Gas Spring G1 IS selected] AND [Z 6 IS <265 mm or >285 mm] THEN [Limit force needed at opening to 40N IS not-ok] At this point, the parties must try to solve the problem using a strategy that will help them go beyond the purely parameter-related arguments. For this, they are going to successively inquire about the reasons behind their requests and soon deal with the design objectives. 7/ Designer A: Critique NOT [Gas Spring G1 IS selected] AS [Need Justification] 8/ Designer B: Defend [Gas spring G1 IS selected] AS [Inner panel weight W1 = 5.3 lbs] AND [outer panel weight W2 = 8.5 lbs] AND SINCE [IF [Total trunk weight IS > 10 lbs and < 20 lbs] THEN [gas spring force needed IS 75 lbs]] 9/ Designer A: Critique NOT [IF [Total trunk weight IS >10lbs and <20 lbs] THEN [gas spring force needed IS 75 lbs]] SINCE [Need Justification] 112 10/ Designer B: Defend [IF [Total trunk weight IS >10 lbs and <20 lbs] THEN [gas spring force needed IS 75 lbs]] SINCE [<maximize> <ease of use> in <gas spring positioning> IS very firm]] Understanding that the problem is related to the weight of the trunk part, the designers can try to generate ideas to reduce this weight: 11/ Designer B: Propose [Inner trunk panel material IS Aluminum] and [Outer trunk panel material IS Aluminum] AS IF [Inner trunk panel material is Aluminum] AND [Outer trunk panel material IS aluminum] THEN [Trunk weight IS reduced by 5 lbs] 12/ Designer A: Dissent NOT [Inner trunk panel material IS Aluminum] and NOT [Outer trunk panel material IS Aluminum] AS IF [Inner trunk panel material IS Aluminum] AND [Outer trunk panel material IS Aluminum] THEN [<minimize> <cost> in <trunk design> IS not-ok] After trying to modify the material of the part which is also a parameter-level type of solution, and realizing that the solution is not suitable, the designers will move up successively to the constraints, functional or objective level. Assuming that the designers cannot agree on any of these levels, they may back-track the decision making process and reconsider choices made earlier about the tasks to complete. Thus far, they have clarified that designer B needs gas spring G1 to achieve the proper 113 opening angle and to satisfy requirements on the opening and closing forces despite the weight of the trunk and its dimensions. 13/ Designer B: Critique NOT [T A 1 IS Design a 2-panel assembly] AS IF [T A 1 IS Design a 2-panel assembly] THEN [<maximize> <ease of use> in <gas spring positioning> IS not-ok] 14/ Designer A: Agree NOT [T A 1 IS Design a 2-panel assembly] 15/ Designer B: Propose [T A 1 IS Design a 2-part trunk] AS IF [T A 1 IS Design a 2-part trunk] THEN [<minimize> <weight> in <trunk design> IS ok] 16/ Designer A: Refine [T A 1 IS Design a 2-part trunk] AND [T A 1-1 IS Design trunk parts] AND [T A 1-2 IS Design opening mechanisms] Designers A and B have put their ideas and objectives in perspective and generated a new solution by backtracking and revising earlier decisions. To conclude, they need to make choices about the downstream decision points: how to design the new parts, and the opening/closing mechanism. Depending on Designer C’s objectives, and the design constraints he has to follow, the outcome may differ. Solution 1: Assume that Designer C has the same constraints as earlier, but that given the weight change of the upper trunk part, a smaller gas spring, fixed lower (i.e. within Designer C’s range), can perform the desired function. Designer B is currently exchanging arguments with designer A, but needs to contact Designer C to ensure that this new configuration will suit his objectives. 114 17/ Designer B: Propose [T A 1-2-1 IS Select gas spring] AND [T A 1-2-2 IS Determine fixation points] 18/ Designer A: Agree [T A 1-2-1 IS Select gas spring] AND [T A 1-2-2 IS Determine fixation points] 19/ Designer B: Acquire_Information [Designer C] 20/ Designer A: wait At this point Designer B contacts Designer C to negotiate over the possibility of fixing a smaller gas spring in a new position. Designer C accepts and Designer B comes back to conclude the negotiation with Designer A. 21/ Designer B: Agree [T A 1-2-1 IS Select gas spring] AND [T A 1-2-2 IS Determine fixation points] 22/ Designer A: Agree [T A 1-2-1 IS Select gas spring] AND [T A 1-2-2 IS Determine fixation points] Figure 4.19 below represents the solution generated by this negotiation process. The parties may continue to discuss the downstream tasks or go back to their design activity. 115 Figure 4.19: Solution with a 2-part trunk with sliding upper part Solution 2: Let’s assume that designer C needs to work with the same constraints as before, but that no other surface is available to position the gas springs’ fixation points. Therefore, he rejects the proposition of designer B to position a smaller gas spring on his part. Designer B comes back to the negotiation table with designer A and attempts to generate another solution. 21/ Designer B: Critique NOT [T A 1-2-1 IS Select gas spring] AND [T A 1-2-2 IS Determine fixation points] AS IF [T A 1-2-2 IS Determine fixation points] THEN [maximize fixing point integration in rear body design IS not-ok] 22/ Designer A: Compromise [T A 1-2-1 IS Create sliding mechanism] and [T A 1-2-2 IS Determine sliding mechanism fixation point] 23/ Designer B: Agree [T A 1-2-1 IS Create sliding mechanism] and [T A 1-2-2 IS Determine sliding mechanism fixation point] Figure 4.20 is a representation of such a solution, the top part of the trunk incorporates a cavity on its sides, in which a pin may slide freely and guide the part to stack it above the roof. The bottom part is identical to the previous solution. 116 Figure 4.20: Solution with a 2-part trunk with hinged upper part Designer A and B, through the exchange of arguments containing design context information, and design objectives, have been able to overcome their initial parameter–level problem, by generating new design task and solutions, and focusing on sharing the design context information. 4.5 Conclusions and remarks This case example was presented to demonstrate the way negotiation can be structured in ANED, by following its systematic approach. The first scenario exemplifies the idea of ZOPA creation over quantitative elements, by presenting a conflict situation at parameter value level where the parties both have to compromise to reach a mutual agreement. Through arguments proposal, critique and counter-proposal, the parties identify what kind of solution is feasible, and manage to agree. The second scenario demonstrates how parties can argue about non-quantitative elements and create the equivalent of a ZOPA using the same ANED protocol. Strategy implementation controls which topics the parties can make claims about, and 117 helps frame the negotiation discussion. Semi-qualitative quantifiers are used to provide a metrics upon which designers can rely to explicitly express their preferences. The last scenario describes how designers can go beyond objective sharing and objective-level negotiation to argue about tasks and revise their previous judgments about the ways they are proceeding. It is shown that revising task decomposition may be a good method to solve conflicts and generate creative alternative solution simultaneously. We must insist here on the fact that this scenario only shows potential applications of the ANED framework and that it relies on a number of assumptions and hypotheses. In order to demonstrate a clear benefit of the framework, a design environment has been created to carry out real world experiment, comparing a traditional design approach and the ANED approach. Based on the results of these experiments, conclusions will be made about ANED, and recommendations about further enhancement or modification of the framework will be made. In the next chapter, we present this experiment conducted to assess the impact of ANED on the collaborative design process. 118 Chapter 5: Impact of an Argumentation-based Negotiation approach on collaborative Engineering Design In this research work, we view the collaborative design process as a decision- making and conflict resolution-oriented activity. In this process, designers and/or engineers from diverse backgrounds join forces to resolve complex, multi-disciplinary problems in order to create a final product whose intended use or implementation satisfies a target customer’s requirements list. We focus more specifically on an activity essential to a typical conflict resolution, namely the negotiation round the parties enter when they attempt to reach a mutually acceptable agreement. Depending on the type of conflict faced, its complexity, and how divergent the parties’ opinions are on the matter, the reconciliation of the parties’ differences may necessitate only a few words or, on the contrary, lengthy exchanges until an acceptable agreement is reached. We argue that inter-designer negotiation should not be viewed as a costly, time- consuming process during which the parties involved must impose their viewpoint at any cost. In contrast, we advocate that inter-designer negotiation should be thought of as an opportunity for the parties to constructively exchange perspectives on the conflict in order to gather a set of reliable and relevant data as well as identify promising directions to explore the available design space. 119 In our research work, we developed ANED, an argumentation-based approach to support collaborative engineering design negotiation. The ANED framework was presented in details in the previous section. In order to validate our approach and evaluate its impact on the collaborative design negotiation process, we created a collaborative design problem. This problem presented below, was designed to reward teams who adopt an integrative negotiation attitude and attempt to reach win-win situations. Several classifications of design problems have been proposed over the years (Brown and Chandrasekaran [23], Coyne et al. [30], Gero [51]) and even though none is predominant, the fact that design problems can be of different nature is commonly agreed upon. Creative or original design refers to the resolution of never-seen-before design problems, for which no pre-existing knowledge is available. Design projects at the forefront of technology are typical cases of creative design - e.g. development of the audio cassette in the sixties, large civil engineering projects or space exploration programs (Mars Rover). Routine design is a term used to describe a second set of design problems, which are characterized by the fact that readily available knowledge can be applied in order to solve them. Such design problems are very common and usually easier to deal with (e.g. car design, furniture design, etc…). In this experiment, our intention was to test the capabilities of ANED’s negotiation protocol in a situation as close to a real-world collaborative design problem as possible. Selecting a problem that required an original design approach had a number of interesting characteristics. First, the lack of prior knowledge may stimulate the 120 information exchange and argumentation amongst the parties, who cannot refer to shared concepts or ideas. Second, the need for a creative process can bring forward the potential for idea generation and inventiveness that exists in the collaborative design negotiation process. However, the inherently open-endedness of an original design problem makes it difficult to assess the quality of a design and jeopardizes our ability to create an adequate and reliable scoring scheme. Shah et al [118] proposed a design scoring method to assess the quality of individual design efforts. We deemed this scoring scheme not adequate for our experiment. Selecting a typical routine design problem addresses the scoring and design assessment issue, but weakens significantly the content of the negotiation process, and in particular its creative aspect. These arguments steered our research efforts towards a problem that would encompass both types of approach. A detailed description of the design problem used is given in section 5.2. The designed problem adopted combines a realistic design task, an average level of difficulty, some room for creativeness and design space exploration, and requires collaborative work and conflict resolution. 5.1 Experiment introduction 5.1.1 Objectives We conducted this experiment with several objectives in mind. Our first intention was to carry out an evaluation of the ANED negotiation protocol in order to assess its efficiency, identify its potential shortcomings, and propose further revisions to better support collaborative design negotiation. Our second objective was to investigate the 121 activity of collaborative design negotiation itself and more specifically how effective negotiation may be depending on the type of communicative activities performed. 5.1.2 Hypotheses We laid out the following hypotheses when he created this design problem: Experiment Hypotheses: 1. ANED’s argumentation-based negotiation (ABN) protocol can improve the effectiveness of a collaborative design negotiation process. We expect that exchanging formatted information, encapsulated in logically sequenced arguments, can improve mutual understanding between the parties involved, therefore contributing to a more effective exchange and should eventually translate into better design outcomes. 2. Implementing an Argumentation-based Negotiation protocol to support collaborative design will help designers be more creative: we expect to observe an improvement in the alternative generation phase of the negotiation process. Since we argue that ABN applied to collaborative design can facilitate information exchange, new ideas generation, and promote mutual understanding among the parties, we believe that the protocol implementation has a positive effect on the alternative generation ability of the subjects as they are able to explore a larger design solution space. 3. Providing a strategic support through a representation of design space over multiple levels of abstraction can improve the thoroughness of the design space exploration and result in a more efficient joint decision-making process. 122 We expect to see the involved parties reach agreements faster and more efficiently. 4. Complementing such protocol with a strategy support model enhances the efficiency of the design space exploration: we expect to observe longer exchanges between negotiation participants prior to an agreement as they argue about the issues they are facing and try to convince each other to change their position. Comparing the results obtained with the first and second treatment, we are able to evaluate the impact of the protocol on collaborative design negotiation. Similarly, comparing the results obtained with the second and third treatments, we are able to assess the impact of the negotiation strategy support on the collaborative design negotiation process. This strategy support is an extension of the negotiation protocol of ANED and was designed as such. As a result, a 2-way ANOVA is not relevant, and we chose to adopt this sequential approach, first comparing results from groups 1 (CG) and 2 (PG), then the results from groups 2 and 3 (PSG) (see Table 5.1). Protocol Support Implemented Yes No Yes PSG N/A 5 Strategy Support Implemented No PG CG Table 5.1: Experiment treatments 5 : Strategy support is an extension of the protocol. 123 5.1.3 Experimental design 5.1.3.1 Treatments The primary objective of the experiment was to test the ANED framework and more specifically the ABN protocol created to support designer’s negotiation. In order to do so, we recruited 24 subjects that we divided into 3 treatment groups. The subjects worked in teams of 2 and all solved the same design problem and were given the same amount of information and directions to do so. The treatments of each group differed by the type of environment the teams were working in: - The 4 teams of group 1 or Control Group (CG) were given complete freedom to solve the problem and were allowed to exchange any type of information through the communication channel that was made available to them in the experimental setup. No restriction was placed on the type of information they could exchange, the communication method they would employ (using the communication tool made available to them), or the approach they would use to resolve the problem. - The 4 teams of group 2 or Protocol-supported group (PG) were asked to resolve the problem by following ANED’s ABN protocol and argument model but were left free to choose any strategic approach they wished. The only constraint concerned the way their communication was framed: they had to exchange only ANED-compatible arguments, and follow the guidelines of precedence between arguments as listed in Table 4.3. 124 - The 4 teams of group 3 or Protocol and Strategy-supported group (PSG) were asked to resolve the problem by following ANED’s ABN protocol and argument model and were also introduced to the strategic approach to design conflict resolution of ANED (see 4.3.3). The implementation of this strategic approach was fairly loose as it didn’t enforce any specific approach, but it provided the subjects with suggested approach to handle issues over multiple levels of abstractions and how to maneuver between levels to achieve higher mutual understanding and create ZOPAs. 5.1.3.2 Statistical analysis One way analysis of variance (ANOVA) was performed with the negotiation type (two levels: ad-hoc (-1) and ANED-supported (+1)) as the independent variable for a number of dependent variables that will be introduced later on. The level of significance was chosen at α = 0.05 as a matter of convention. Pearson’s correlation coefficient was also used to support a number of observations. Those results are presented in what follows. We will rely on the F ratio as defined below to assess whether the null hypothesis can be rejected and accept our research hypothesis as statistically significant: between within MS F MS = With: MS between : between-group mean square MS within : within-group mean square 125 The degrees of freedom for between-groups and within-groups mean squares are: within total df N k = − With: k = number of groups N total = total number of scores in all groups combined In our experiment: 2 k = 8 total N = Thus: 1 between df = 8 2 6 within df = − = From statistics literature, we looked up the critical value for F at the 0.05 significance level: 1,6 5.99 F = For each analysis we will compare the F ratio value and grant statistical significance to studies whose F value is above 5.99. We performed a residual analysis in order to validate the ANOVA assumptions: 1. The treatment data must be normally distributed 2. The variance must be the same for all the treatments 3. All samples are randomly selected 4. All the samples are independent 1 between df k = − 126 Samples from the residual plots are presented below, along with the Minitab ANOVA results. The normality assumption (1) is verified by checking that the normal probability plot of the residuals (graph a) has a straight line pattern, which is the case. The equal variance is verified by ensuring that the range of residuals for each level of the factor is comparable (graph b), which is also the case here. The randomness of the samples was embedded in the design of the experiment. Finally, the independence assumption is verified by ensuring that no pattern can be found on the plot of the residuals versus the order (graph c). All the assumptions for ANOVA are therefore verified here. This verification was done on all the other ANOVA used in this work. One-way ANOVA: Adjust Score 0.1/0.9 versus Experiment Type Analysis of Variance for Adjust Score 0.1/0.9 Source DF SS MS F P Experiment type 1 229.0 229.0 8.82 0.025 Error 6 155.8 26.0 Total 7 384.7 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ---+---------+---------+---------+--- -1 4 74.225 4.422 (--------*--------) 1 4 84.925 5.689 (--------*--------) ---+---------+---------+---------+--- Pooled StDev = 5.095 70.0 77.0 84.0 91.0 Figure 5.1: ANOVA for adjusted design score 127 a) b) c) Figure 5.2: Residual plots for adjusted design score The complete list of ANOVAs used in this work is attached in the Appendix 6.2A- 11, along with the aforementioned plots. 5.1.4 Subjects The 24 subjects who participated in this study were recruited amongst the students attending the “Engineering design theory and methodology” class offered at the University of Southern California in the fall semester of 2005 and the “Senior design Project” class offered at the University of Southern California in the spring semester of 2006. The subjects selected among the students enrolled in the “senior design 128 project class” had all taken the “Engineering design theory and methodology class” in the fall of 2005 or earlier. Therefore all the subjects had been exposed to the same knowledge and information about design theory and methodology. Participation was strictly on a voluntary basis, and no coercive process was used. Teams of 2 students were created randomly, and the different treatments administered to each of them were also the product of a random process. The students were all undergraduates in their senior year, and majoring either in mechanical engineering or aerospace engineering. 15 students were male and 9 were female, 6 teams were composed of male students only, 3 were composed of female students only and the last 3 were mixed. Prior to conducting the experiment, the authors went through several testing sessions with the help of a couple of graduate students majoring in mechanical engineering in order to finalize the experiment and ensure that the complexity was adequate so that the resolution would be possible in the experiment’s allotted time. 5.1.5 Procedure One of the main requirements for the experimental setup was to ensure that no unmonitored communication could occur between the team members, and thus prevent any data loss for the post-experiment analysis. Having a face to face collaborative design session that would be recorded or videotaped was an acceptable alternative. However, our desire was to mimic collaborative design work in a distributed environment, which is a more adequate description of current design practices, and avoid any artificial process such as the think-aloud method (Ericsson & 129 Simon [40]; Gero & McNeill [52]) which can intimidate the subjects. In order to circumvent the risk of information loss, the subjects doing the experiment were physically separated, each of them working in a different room. The experiment was thus designed as a computer-based exercise (Figure 5.3). We selected the diagramming solution MS Visio as the primary software to support the resolution of the design problem in a distributed environment. This decision was motivated by several reasons. First, the Visio software is easy-to-use and a very short practice time is sufficient for users to familiarize themselves with it. This was a tremendous asset for this particular experiment. The second argument in favor of VISIO was the fact that it is highly customizable and enabled us to create a simple and convenient interface for the subjects’ tasks. The next issue to address was creating a setup favorable to concurrent collaborative work. This was achieved by using a wireless router in one of the experiment rooms, and run the conferencing solution MS NetMeeting. NetMeeting allows sharing of applications, and made it possible for the subjects to work on a single VISIO file from two different locations simultaneously. Finally, a means of communication had to be selected to allow the parties to communicate and negotiate. The requirements for this communication tool were to be as close to real-time as possible, easy to use, and easily recordable, in order to guarantee a smooth post-experiment analysis. The NetMeeting Chat tool was fulfilling all of the above requirements and was therefore selected as the 130 communication channel between the subjects. All of the subjects were fluent typists and were very comfortable with this tool. As mentioned above, three different treatments were implemented to assess the effectiveness of the protocol. Teams in group 1 were asked to solve the problem without any additional help while the teams of group 2 were requested to use the ANED protocol. The conversation of teams of group 2 was strictly limited to the exchange of ANED-compliant locutions. The teams of group 3 were subjected to the same constraints as those of group 2, with the difference that the teams of group 3 were familiarized with the strategic approach of ANED and in particular how multiple levels of abstraction can be identified and how the assigned problem resolution may be facilitated with these strategic considerations. In order to ensure that the parties would rigorously follow the ANED protocol and argument models, we provided the subjects with a template summarizing the rules of utterance exchanges and arguments structure as defined in ANED. This approach had the advantage of being non-intrusive, and the consistency of enforcement level was thus ensured. Figure 5.3: Experiment setup 131 The author ensured that each subject had understood the template by monitoring the first few communication exchanges and ensured that ANED’s format was followed rigorously. The actual set up was identical for group 2 (PG) and 3 (PSG). The initial PowerPoint presentation was the differentiating element between those two groups. The experimental setup is graphically represented on Figure 5.3. Each experiment sample lasted one hour and proceeded as follows: • t = 0 – 15 min: The subjects sit through an automated PowerPoint slideshow introducing the design exercise they are asked to resolve, and their respective responsibilities. • t = 15 – 25 min: Practice time for the subjects to familiarize with the problem, the data, the use of VISIO and the chat window. • t = 25 min – 1h: The subjects work collaboratively to solve the design problem. The subjects were encouraged to take notes during the presentation but were not allowed to ask additional questions at the end of the presentation. This rule was adopted for the sake of consistency between each sample. 132 5.2 Design problem As mentioned above, a purely creative design type of problem was ruled out for the sake of design evaluation as well as feasibility. We carefully designed this problem in order to guarantee that creative thinking would be observed and that an objective evaluation would be possible to achieve. Using a mechanical engineering design problem as a foundation, we introduced complexity to encourage and reward subjects who attempt to communicate with each other and reach joint decisions. The design problem selected is essentially a two-fold task: a selection task, and a layout task. Each task is explained in details in what follows. The problem was devised to create conflict situations such that the parties cannot fully complete their task nor can they achieve high-scoring designs unless they communicate with each other, make joint decisions and agree on solutions. In order to prevent participants from reaching a high-scoring design by chance, the author developed “artificial” conflicts (see description in 5.2.2). 5.2.1 Experiment problem: design of a water filter manufacturing line The design teams must create a virtual production line to manufacture an imaginary water filter assembly, i.e. a simple object composed of two parts: a grid and a filter body (see Figure 5.4). Each subject is responsible for part of the process: • Designer 1 in is charge of the fabrication of the filter body (Operations F 1 to F 5 ) 133 • Designer 2 is in charge of the grid production and assembly processes (Operations F 6 to F 9 ). Figure 5.4: Water filter to be manufactured The task of each subject is to select a set of machines from a pre-established list to carry out the set of operations needed to fabricate the water filter. Both types of pre- established lists (designer 1’s and designer 2’s), which we refer to as the process morphology chart, are presented on figure A-1 and A-2 of the appendix. Each row of the table represents an operation (F i ) to perform and each column contains two to three process/machine candidates (M ij ) for that specific operation, along with specifications and an explanatory cartoon. The specifications are a Cost in $ and Space in unit blocks. The data related to the cost and space is purely imaginary and was not intended to be representative of the actual cost of each operation or the space required for such equipment in real life. The numbers provided were artificially created by the authors to make the problem simple and interesting. Table 5.2 below summarizes the design tasks, the design objectives and the design information. Designer 2 Designer 1 Team 134 Design Tasks Design Objectives Information provided Designer 1 - Select a set of machines to produce part 1 - Lay out machines for operations F 1 to F 5 in factory according to problem rules - Simplified technical drawing of the part to create - A complete morphology chart for operations F 1 through F 5 - A partial morphology chart for operations F 6 to F 9 (no cost or space information provided) - A compatibilities and issues list * - An option’s list * Designer 2 - Select a set of machines to produce part 2 and assemble it with part 1 - Lay out machines for operations F 6 to F 9 in factory according to problem rules - Minimize cost of machine selection - Minimize space occupied by machines in factory - Ensure full compatibility and issues resolution in the final set of machines/processes selected - Simplified technical drawing of the part to create - A complete morphology chart for operations F 6 through F 9 - A partial morphology chart for operations F 1 to F 5 (no cost or space information provided) - A compatibilities and issues list * - An option’s list * Table 5.2: Design tasks, objectives and information 6 In order to maintain absolute consistency of the information disclosed to each sample, a document package containing the documents listed in Table 5.2 was handed to each member of each design team. During the 15-minute PowerPoint introduction, the subjects were able to refer to this document package and follow along, but were not allowed to exchange any information contained in them. In addition, the subjects were told to focus on low cost as a primary objective and consider the objective related to space as secondary. The rationale for this last instruction was motivated by the author’s desire to observe the way teams would deal with prioritization. 5.2.2 Machine selection: Compatibility and Issues resolution The design problem was created to reward an integrative approach to design negotiation (Raiffa et al. [99]) i.e. a willful desire to create joint gains, rather than a 6 :items described in the next sections 135 distributive approach limited to the mere allocation of existing resources – making the pie bigger vs. splitting it. Research has shown that parties involved in a typical negotiation process such as buyer-seller, benefit the most by adopting such an integrative approach. Testing such a hypothesis in the collaborative design context was also part of the objectives of this experiment. Definitions: Incompatibilities, Issues and Options Local incompatibilities, global incompatibilities and resolvable issues were designed to promote integrative behavior. Following are the definitions of each of these items: - Local incompatibility: two machines have a local incompatibility when they cannot be selected simultaneously by the designer who is in charge of the associated operations. Ex: M 32 and M 41 are locally incompatible; designer 1 cannot select both in his solution set. - Global incompatibility: Two machines have a global incompatibility when the operations they are addressing are the responsibility of different designers, and cannot be selected simultaneously. Ex: M 11 and M 61 are globally incompatible; designer 1 cannot select M 11 in his solution set if designer 2 selects M 61 and vice- versa. - Issue: Two machines which have an issue can be simultaneously selected only if the issue is addressed by an option selected from one of the designer’s options list. Ex: M 22 and M 61 have an issue (#2): “Cut grid must be checked dimensionally to match NC high quality”. 136 - Option: An option is an item which can be selected from the option list of either designer to resolve an issue encountered by the subjects during their machine selection task. Ex: Option #11 in designer 2’s options list “Dimensional Control Station”, which costs $3 and takes up two blocks of space addresses the aforementioned issue #2. Incompatibilities and issues were arbitrarily chosen to prevent the subjects from selecting the cheapest or the most compact set of machines, and force them to make decisions over local and global tradeoffs. Each of the two team member’s options list was different, and was designed to provide him with some of the solutions to his own issues as well as some of those encountered by his teammate. Therefore, the only way to properly resolve some of the issues is to discuss them, and collaboratively search for a solution. A sample of the document package handed over to the subjects during the experiment is attached in the appendix 6.2A-1 to 6.2A-5. A solution S for this task is thus a fully compatible set of machines: { }, 1..9, 1,3 ij S M i j = = ∈ along with a set of options: , 1,2 , 1,24 ∈ ∈ ik O i k when solving issues is necessary. 5.2.3 Machines layout The second task of the experiment, carried out either concomitantly or once the selection is completed, was created to encourage further a joint decision making process. VISIO was specifically used to support this layout design task. The subjects 137 were provided with a VISIO file containing a layout pane, with a representation of the walls of the factory. The space within the factory walls was divided into the same unit blocks used to characterize the machines size. The number of rows was limited to 3 and they were numbered from 1 to 3. Similarly the columns received a letter denomination, but were however not limited in their number. Figure 5.5 below presents a screen capture of the VISIO environment used. Figure 5.5: VISIO environment used for the layout task In addition to the main pane where the factory is represented, the subjects were given access to stencils (available via the tabs labeled “Experiment –Designer ‘i’” and “Options List – designer ‘i’” visible on Figure 5.5). When the subjects had selected a given machine, they were able to locate it in the appropriate stencil, and drag and drop it at the location of their choice. The following guidelines were given to the subjects: Stencils 138 - The layout must be as compact as possible in the horizontal direction - Space is shared between the two sets of machines selected by each designer - Machines cannot overlap - Machines selected by each subject must be laid out from left to right following the operations order (the machine selected for F 1 and F 6 must be positioned against the left wall) - Designer 1 must position his machines in the top half of the factory; however he is allowed to position them over the other half, so long as at least 50% of the machine surface is in the top half. - The same rule applied to designer 2 with the bottom half. These guidelines were enforced to give the subjects another opportunity to collaborate about the layout, explore possibilities and possibly discover additional win-win situations based on their respective selections. 5.3 Experiment results and discussion 5.3.1 Communication data encoding After each experiment, the following material was collected: - Final machines and options sets selected by the subjects - Final layout of the machines in the factory (VISIO file) - Transcript of the chat conversation between the two subjects Using the collected data, an evaluation was performed to assess the quality of the design outcome for each sample, as well as how efficient the negotiation process was. 139 The conversation logs collected during the design sessions were encoded using the locution types presented in ANED’s description (Section 4.3.2). Each utterance was matched with one of these locutions. Utterance type Description Example Proposal (Strategic) Utterance introducing a proposal related to a strategic approach to the problem “So why don’t we start with your machines?” Proposal – Local Utterance introducing a proposal dealing with a decision the utterer is responsible for Des.1: “I think M 41 is out for F4” Proposal – On other party Utterance introducing a proposal dealing with a decision the addressee is responsible for Des. 2 “Why don’t you use the 2-block machine for F4 because we are not saving any space” Critique Utterance introducing a criticism of an incoming proposal Des.1: “you shouldn’t use M 92 because it creates a conflict on my side” Counter- Proposal Utterance introducing a proposal following a previously rebutted proposal Des.2 responding the above critique: “we could use M93 then” Defense Utterance introducing a previously criticized proposal along with additional data backing it up Des.1: “…but it conflicts with M 11 …” Des.2: “it’s ok because M 11 won’t be used in all likelihood” Agreement Short utterance signifying acceptance of the last uttered proposal “yes, this choice is fine” Dissent Categorical rebuttal of a proposal “…so no M 11 ” Information request Utterance formulating an inquiry from the utterer regarding information known by the addressee Des.1: “Is there a 2-block machine for F 6 that is cheaper?” Information passing solicited Utterance introducing information previously requested from the utterer Des.2: “yes there is a cheaper one for F 6 ” Information passing voluntarily Utterance introducing information willfully transmitted to the addressee without prior request. “I don’t see any conflict on my side” Table 5.3: Negotiation utterance definitions After a first round of encoding, the coding scheme was modified to more accurately describe the content of the negotiation scripts recorded. Table 5.3 contains 140 the completed list of the utterance types used during this encoding task. The examples presented in the table were collected in the material produced by the subjects belonging to group 1 (CG). We refer to the subject delivering a sentence as the “Utterer” and the subject receiving the sentence as the “Addressee”. This list of utterances was inspired by the set of speech-acts (Searle 185[118], Ballmer and Brennenstuhl [10]) carefully chosen as the minimal set of locutions necessary to support effective negotiation when ANED was developed. Once the encoding was completed, a thorough count of the number of times each type of utterance appeared was computed and the data was compiled in a spreadsheet. In addition, for each sample chat log, the design session was divided into three segments or phases that appeared clearly during our analysis, based on the dynamics of the discussion: - Initial strategic planning: phase during which the subjects strategize about how to address the design problem. - Problem resolution: phase during which the subjects go through the selection process and the layout of the machines. During this phase, the parties argue about the most preferable solution set and attempt to achieve the cheapest and most compact compatible selection possible. - Design optimization: this phase consists of a post-completion analysis, during which the subjects try to improve their design generally by using swaps and comparing the outcome to the last selected set. 141 The number and proportion 7 of utterances exchanged during each phase was also compiled and entered in the spreadsheet. In order to minimize the risk of inconsistencies in the encoding, multiple rounds were used for each negotiation log. A sample of a negotiation log for each treatment group is given in Appendix6.2A-6. 5.3.2 Scoring scheme The quality of the subjects’ designs was evaluated according to the design objectives and requirements of the problem. We defined the indexes presented in the next sub-section to evaluate the design performance of each team. 5.3.2.1 Score-based Design Performance Index (SDP) This index is computed using two metrics: o A cost-based score Sc: this score assesses the performance of the design along the “minimize cost” design requirements. The maximal score Sc=100% was assigned to the cheapest design observed (m c =$58.5), while the score of Sc=0% was assigned to the design with the highest possible cost (M c =$87.5). A linear grading scheme was used. The Score Sc can be represented mathematically as: 1 c c c c c m A S M m − = − − With A c : cost of the machine set selected by the design team. 7 : ratio of number of utterances spoken during the phase to the total number of utterances 142 o A space-based score Ss: this score assesses the performance of the design along the “minimize space” design requirements. The space is measured along the horizontal direction. The computation follows the same logic as the computation of Sc. The most compact layout reached letter F. The space score can be mathematically represented as: 1 s s s s s m A S M m − = − − With M s : Maximum number of cells used (M s =7 – letter G) m s : Minimum number of cells used (M s =5 – letter E) A s : Number of cells used in the experiment evaluated The SPD index is computed using weighting factors: 0.8 0.2 c s SPD S S = × + × The weighting factors used were assigned in accordance with the problem guidelines emphasizing the importance of cost over space. The exact values of the coefficients were not disclosed to the subjects at the time of the experiment in order to ensure that the problem would not come across as a computational problem. 5.3.2.2 Design Space Exploration Index (DSE) We studied the way the designers dealt with the creative task required in the design problem completion, i.e. the issue resolution. The DSE constitutes one metric which can be used as an assessment of the designers’ ability to create design alternatives. It 143 was computed by first counting the number of issues discussed and the number of options considered while solving the problem. For each of these two measures (number of issues and options discussed) the highest number recorded throughout the experiment data – M I and M O respectively – were considered as full scores and scaled to 100%. The lowest values for each were both 0. An “issues exploration index” I and an “options exploration index” O were computed as follows: I I A I M = O O A O M = With A I : Number of issues discussed in the experiment evaluated A O : Number of options considered in the experiment evaluated Using an averaging of these two indexes, the DSE was calculated: ( ) 2 I O DSE + = This index is a relative scoring based on the best performances recorded during the experiment and does not constitute an absolute metric. 5.3.2.3 Negotiation Content Distribution (NCD) The term Negotiation Content Distribution refers to the assessment of the number of occurrence of each performative type in a given experiment sample. For each team, we computed the total number of occurrence for the following utterance types: 144 o Strategic Proposals o Proposals (Local, on Other Party, Counter Proposals) o Argumentative performatives (Critique, defend, dissent, refine) o Information requests Tracking this information provides an overview of the negotiation content in terms of the dominant communication activity in each case (CG, PG and PSG). In particular, in our analysis we will be able to cross-reference this information with other types of data in order to draw conclusions beyond the scope of the ANED protocol’s implementation. By doing so, it will be possible to investigate issues such as “what type of communication activity or argumentation performative has a positive or negative impact on the problem resolution and design outcome?” 5.3.2.4 Negotiation Process Distribution Negotiation Process Distribution refers to the assessment of the proportion of the total number of utterances devoted to each of the aforementioned phases of the negotiation process, e.g. Strategic Planning, Problem Resolution and Design Solution Optimization. Each chat log was divided into these three phases, based on the contents discussed. Table 5.4 below presents typical excerpts from the chat logs of the CG and which category they belong to. 145 Chat log recorded Corresponding negotiation phase Des 1: First process is for me, correct? Des 2: So why don’t we start with your machines? Des 1:Ok, to mod the part we have 5 options … Strategic planning phase Des 1: We did M 12 and M 32 , create holes is next Des 2: Ok Des 1: Column drill 3 wide $5, turret 1, $8 and gang drill $7 at 3 blocks long Des 2: Column or turret Des 1: Remember 50% in top half Des 2: so I say column … Problem resolution phase Des 1: How does 91 work for you? Des 2: 91 works, is it better? How much more does it cost? Des 1: It’s $9 vs. $6.5 Des 2: But it’ll cost $2 more to fix the problem Des 1: So should keep 93? … Design solution optimization Table 5.4: Typical chat log for each negotiation process phase For each sample, the number of locutions used in each phase was counted and the ratio to the total number of locutions was taken. For instance, the ratio of utterances used during the strategic planning phase can be represented by the equation: strategic planning strat Experiment Utterances r Utterances = ∑ ∑ The other ratios are computed in the same fashion: ∑ ∑ = Experiment resolution oblem resolution Utterances Utterances r Pr 146 ∑ ∑ = Experiment on optimizati Solution on optimizati Utterances Utterances r The results of this experiment are presented and discussed in the next two sections. 5.3.3 Impact of the protocol implementation on collaborative design negotiation Comparing results obtained using the first two treatments (i.e. control group and protocol-supported group), we were able to evaluate the impact of the protocol implementation on the design process and outcome. 5.3.3.1 Score-based Design Performance The selection sets and scores obtained by each groups are presented in Table 5.5. The table summarizes the specifications of the design outcomes generated by the design teams. Using the scoring scheme (see “For reference” section at the end of this document), we can right away notice that the improvement that was expected in the design result is very subtle. The average SDP of group 1 (Control group) is 81.4% versus 85.7% for group 2 (protocol-supported group). What’s more is that the second best SDP overall is from the 4 th sample of group 1, therefore the standard deviation is relatively large in both groups. Applying one-way ANOVA to the data with the experiment type (CG / PG) as the factor and the score as response doesn’t yield statistically significant result (F 1,6 =1.05, p=0.344). We believe that over a larger number of samples the standard deviation would significantly reduce, leading to more conclusive results. We will comment on this issue in chapter 6. 147 Group 1 (CG) Group 2 (PG) Experiment data Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Machine selection M 12 M 32 M 43 M 53 M 63 M 71 M 81 M 93 M 21 M 32 M 42 M 53 M 62 M 71 M 81 M 93 M 11 M 32 M 41 M 52 M 62 M 71 M 81 M 91 M 22 M 32 M 42 , M 52 M 63 M 71 M 82 M 93 M 11 M 32 M 43 M 52 M 62 M 71 M 82 M 91 M 11 M 32 M 43 M 53 M 62 M 71 M 82 M 93 M 11 M 32 M 43 M 53 M 62 M 71 M 82 M 93 M 12 M 32 M 43 M 53 M 63 M 71 M 83 M 91 Option selection #1-5 ($2) N/A N/A N/A N/A #1-16 ($1) #1-6 ($2) #2- 20($1) Total Cost $65.5 $64.5 $65 $62.5 $63 $58.5 $59.5 $64 Cost score S c 75.86% 79.31% 77.58% 86.2% 84.48% 100% 96.55% 81.03% Space used Up to F Up to E Up to F Up to E Up to E Up to G Up to F Up to F Space score S s 66% 100% 66% 100% 100% 33% 66% 66% SDP 73.9% 83.4% 79.3% 89.0% 87.6% 86.6% 90.4% 78.0% Average SDP 81.4% 85.7% Table 5.5: Specifications of design outcomes The recorded data showed that the teams from group 2 (PG) who performed poorly (sample 1 and 4) both failed to properly prioritize the design objectives introduced during the presentation. They gave priority to a compact design as opposed to a low- cost one. Furthermore, the teams from group 2 were generally more proficient at considering multiple alternatives, and this behavior translated in a number of factors, including the option selection visible in this table. We will underline other manifestations of this exploratory behavior in the following sections. Figure 5.6 below summarizes these comments by providing a graphical representation of the average cost, space and SDP for each group. Statistical significance is established for the average cost value. 148 Group 1 (CG) Group 2 (PG) Average cost score Average space score Average SDP 40% 50% 60% 70% 80% 90% 100% Score-based design performance CG - PG Average cost score Average space score Average SDP Figure 5.6: Cost, space and SDP performance for CG and PG samples 5.3.3.2 Design space exploration performance This data is very meaningful since exploring the set of available alternatives is essential to reach a good agreement, whatever the context may be. In any negotiation process, the final agreement is only as good as the best element of the set of agreements considered during the negotiation. If a better agreement is overlooked, it will not be selected and the negotiation outcome will remain suboptimal. The DSE scoring method was created to palliate the penalty implicitly assigned to teams who demonstrated significant design space exploration efforts but who failed to identify joint gains combinations. Group 1 (CG) Group 2 (PG) Creative process Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 # of Issues discussed 1 0 0 0 4 3 4 3 # of Options discussed 2 0 0 0 3 4 2 2 DSE 20.5% 0% 0% 0% 46.4% 47.3% 39.3% 33.0% Average DSE 9.4% 41.5% Table 5.6: Design Space Exploration results (CG-PG treatments) 149 Applying one-way ANOVA to the DSE index yields results supporting our second hypothesis. Using the DSE as the response and the experiment type (CG/PG) as the factor, the ANOVA shows that the protocol has a very significant effect on the design outcome (more thorough design space exploration) (F 1,6 = 38.21, p = 0.001). The members of the design teams of group 2, forced to create arguments, are able to build upon each others’ ideas better. Figure 5.7 is a graphical representation of the observed data. Group 1 (CG) Group 2 (PG) Average Issue index Average Option index DSE 0% 10% 20% 30% 40% 50% 60% 70% Alternative space exploration CG - PG Average Issue index Average Option index DSE Figure 5.7: Design space exploration for CG and PG samples Observation of the correlation between the experiment type (protocol-supported or not) and the number of issues discussed (representative of a creative process in this context) reveals another significant results. Pearson’s coefficient value computed is r = 0.961 (p = 0.000), indicative of a very strong correlation, and illustrates that the protocol-supported groups, compelled to generate meaningful arguments by the 150 protocol’s structure, also discuss key issues related to the crux of the problem. When ANED was developed, one of the initial postulates used stated that negotiation is not merely a communicative process but also a creative process, during which the parties not only exchange information about the design task, a design conflict or their personal value systems but also argue about them and attempt to influence each other. This creative process is sometimes referred to as design co-construction (Lu [76]) and is more often than not overlooked. Indeed, designers often adopt a competitive behavior rather than a cooperative one when entering a negotiation session with a co- worker and annihilate opportunities to create new ideas. This led us to the formulation of hypothesis #2. The results presented in this section corroborate this hypothesis, i.e. using an argumentation-based negotiation approach actually improves the design space exploration. The constraints on the communication exchange inherited from the protocol and the claim-data-warrant-based argument model (Toulmin’s model [129]) result in the exchange of more dependable arguments, rooted in solid, verifiable and logical data. 5.3.3.3 Negotiation content distribution The second objective of this experiment was to observe the impact of a negotiation protocol such as ANED’s on the collaborative negotiation process in engineering design. We presented results supporting hypothesis #2 in the previous section, in particular that the protocol helps improve the thoroughness of the subjects’ exploration. In this section, we intend to study the actual negotiation process in each sample and to draw some conclusions about the type of activities performed, and how 151 they contribute to improve or worsen the quality of negotiation outcome. Table 5.7 and figure Figure 5.8 present the results of the negotiation content distribution analysis. Several conclusions about design negotiation can be inferred from those results with the help of statistical analysis. Group 1 (CG) Group 2 (PG) Utterance type Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Proposal (strategic) 8 4 15 11 6 0 0 2 Proposals total (L/OP/CP) 6 2 10 9 14 12 21 12 Total argumentative 14 3 15 13 25 14 19 9 Information request 21 5 37 29 6 5 9 5 Issues discussed 1 0 0 0 4 3 4 3 Table 5.7: Results of negotiation chat log encoding We observe a significant difference between the two treatments in the type of activity dominating the negotiation process. The one-way ANOVA for the total number of non-strategic proposals (described by “Proposal total (L/OP/CP)” in the table) shows that the implementation of the protocol has a significant impact (F 1, 6 = 8.82, p = 0.025). Therefore, using ANED’s protocol encourages the parties to generate more proposals related to problem resolution. This result was expected and the protocol was designed such that proposals are the primary communication tool. 152 Figure 5.8: Negotiation content distribution for CG and PG samples Proposals are the locutions introducing possible agreement points: generating more proposals expands the range of the possible agreements set, which is in agreement with our prior observation about the design space exploration factor. The ANOVA results are presented Figure 5.9 below: One-way ANOVA: Prop total versus Treatment Analysis of Variance for Prop tot Source DF SS MS F P Treatment 1 120.1 120.1 8.82 0.025 Error 6 81.8 13.6 Total 7 201.9 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ------+---------+---------+---------+ 0 4 6.750 3.594 (---------*--------) 1 4 14.500 3.786 (--------*--------) ------+---------+---------+---------+ Pooled StDev = 3.691 5.0 10.0 15.0 20.0 Figure 5.9: ANOVA for total number of proposals vs. treatment Negotiation content distribution - Control Group 0 2 4 6 8 10 12 14 16 Strategic proposal Resolution proposal Total Argumentative Agreements Number of utterances Negotiation content distribution - Protocol supported group 0 2 4 6 8 10 12 14 16 Strategic proposal Resolution proposal Total Argumentative Agreements Number of utterances 153 The problem type has a second effect clearly visible with this data. The one-way ANOVA for the number of information request utterances supports the fact that the protocol use reduces the need for information request (F 1, 6 = 5.90, p = 0.051). It could be argued that the statistical significance of this result is questionable (p is slightly above 0.05) but the results significance was dampened by the fact that the second sample of the control groups hardly communicated during the experiment (information request = 5, proposal total = 2). We can explain this pattern as the result of two combined effects. First, the higher number of proposals for the protocol- supported groups is balanced by a lower number of information request/passing loops since the argument model used to generate the proposals assumes an information passing function (in the form of data and warrants backing up claims). It is thus natural to observe a different balance in the ratio proposal / information request between the two groups. Second, the efficiency of the argumentation-based negotiation in terms of mutual understanding amongst the subjects reduces the need for information requests. The subjects are able to incorporate essential information in the arguments they generate using Toulmin’s model of arguments and claims, data and warrants. A third one-way ANOVA for the proposal related to strategy shows conclusive results (F 1, 6 = 7.58, p = 0.033). The implementation of the protocol reduces the need for strategic-oriented exchanges. This pattern can be explained by the existence of a limitation in the negotiation protocol of ANED. Indeed, the number of performatives 154 in the protocol is limited and it appears that none of them was specifically designed to handle strategic discussions. Using the “propose” performative is a possibility but did not prove to be an intuitive one since hardly any team used it as a strategy planning tool. The experiment is therefore fulfilling its promises leading us to feedback on the usefulness of the protocol as well as its shortcomings. Following this observation, we suggest directions on revising the protocol to enable proper handling of strategic discussions in chapter 6. 5.3.3.4 Negotiation Process Distribution In this section, we went over the negotiation chat logs a second time and divided the discussion into three phases: • Strategic planning • Design problem resolution • Design solution optimization The distinction between each phase was easily identified. The transition between the first and second phase corresponds to a swing in the content of the arguments from hypothetical non-specific proposals used to identify strategic directions, to specific utterances proposing alternatives and committing to some of them when an agreement is reached. Similarly, the transition between the second and third phase is easily identified as it corresponds to the point of the resolution at which the parties have selected their first complete set of machines. 155 Group 1 (CG) Group 2 (PG) Utterances Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 For strategic planning 68 5 20 8 2 0 0 0 For design resolution 26 5 149 57 93 49 57 44 Number of utterances used For solution optimization 28 15 64 27 7 10 9 6 For strategic planning 0.56 0.20 0.09 0.09 0.02 0.00 0.00 0.00 For design resolution 0.21 0.2 0.64 0.62 0.91 0.83 0.86 0.88 Ratio of utterances used For solution optimization 0.23 0.60 0.27 0.29 0.07 0.17 0.14 0.12 Table 5.8: Number and ratios of utterances used per phase For each sample, we counted the number of utterances used in each phase, in order to estimate how important each of the phases was in the design solution generation process. We then gathered the data for each sample and conducted a statistical analysis. The raw results are presented in Table 5.8. By computing the average of each of the above ratios, we determine that: • 23% of the utterances are used for the strategic planning phase in the control groups versus virtually 0% in the protocol supported groups • 42 % are used in the problem resolution phase by the control groups versus 87% for the protocol-supported groups • 35% are used in the solution optimization phase by the control groups versus 12% in the protocol supported groups 156 Group 1 (CG) Group 2 (PG) Strategy phase Resolution phase Optimization phase 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% Percentage of utterances Negotiation process distribution CG - PG Strategy phase Resolution phase Optimization phase Figure 5.10: Utterances distribution over negotiation phases A statistical analysis backs up these observations in each case. The statistical significance for the second phase (F 1, 6 = 4.25, p = 0.085) is not strongly established as a result of the weak involvement of the second sample team in the experiment (only 5 utterances exchanged). In the other two phases, the data from the other sample is counter-balancing this weak involvement and leads to significant results in both cases (F 1, 6 = 13.33, p = 0.011 and F 1, 6 = 6.45, p = 0.044 for design resolution and solution optimization respectively). The design activity in each case can be graphically represented as in Figure 5.10. Two interesting results in the recorded data should be commented. First, the fact that the samples of group 2 are spending no statistically significant portion of their communication exchange on the strategic planning phase is rather surprising. Strategic planning is an essential part of the design process and many design models (such as Pahl and Beitz’s [87]) begin with this step. We attribute this result to the 157 format of the protocol which was designed with a focus on the argument exchange activity, assuming each participant knows exactly how to proceed in the design. The strategic planning phase is used to achieve this very goal: decide on how to proceed. While observing the subjects of group 2 the author realized the limitation of the protocol in this domain. In addition, the design problem used for this experiment was adequate in its complexity, if time and practicality are considered, but did not require a significant planning stage since the tasks to accomplish where relatively straightforward. This observation suggests that it would be judicious to provide the protocol users with performatives dedicated to strategic planning which can be easily identified as such and facilitate this step of the design process. In the statistical results for group 1, the behavior of team 1 (sample 1) is explained by the fact that the subjects took a computational approach to the problem rather than see it as a communication and data exchange exercise. They tried to resolve the problem with a mathematics-oriented type of reasoning and went through lengthy exchanges about what strategy to follow to achieve optimization. The second remarkable difference is the balance between resolution and optimization-related communication in the overall collaborative design process. The protocol-supported groups dedicated most of their communication exchange to problem resolution, and a minimal amount of their exchange discussing optimization/improvements of their current design. On the other hand, the control groups spent almost an equal amount of utterances for each phase. This result supports hypothesis 3: the ANED protocol contributes to a richer communication 158 contents amongst the subjects who spend more time arguing about their conflicting positions, exploring new alternatives, proposing compromises during the problem resolution. This more thorough design space exploration results in a convergence to a final design decision that is slower yet more efficient. This thoroughness reduces the need for post resolution-optimization, as visible in the data. In addition, the average amount of utterances used by each group reinforces the conclusion that design efficiency is improved with the protocol, as teams in group 1 used an average of 118 utterances to complete the problem while teams in group 2 needed only an average of 69. 5.3.4 Impact of the multi-level strategy support on collaborative design negotiation 5.3.4.1 Score-based design performance The third treatment group was exposed to the strategic model developed in ANED, and given a number of examples of cases where applying the multi-level model is beneficial. Our intent was to assess how effective this exposure to a multi-level approach to conflict resolution can be. Comparing the observed results with those of teams from group 2, who only received protocol support, should set forth the advantages or drawbacks of this strategic support. The design results for groups 2 and 3 are presented in Table 5.9 and Figure 5.11 below. We can draw a number of conclusions based on the raw costs and space results for this set of treatments. First, the average cost decreases ($59.37 vs. $61.25) between the two treatments group. Furthermore, the teams from the third treatment did not get 159 as high space scores as the teams of the second group which reveals a more thought- out process focusing on high cost score and compromising on the space score. The strategic support has thus been instrumental in keeping the design effort in line with the problem guidelines specifying the importance of cost over space. Group 2 (PG) Group 3 (PSG) Experiment data Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Machine selection M 11 M 32 M 43 M 52 M 62 M 71 M 82 M 91 M 11 M 32 M 43 M 53 M 62 M 71 M 82 M 93 M 11 M 32 M 43 M 53 M 62 M 71 M 82 M 93 M 12 M 32 M 43 M 53 M 63 M 71 M 83 M 91 M 11 M 33 M 43 M 53 M 63 M 71 M 82 M 93 M 22 M 32 M 43 M 53 M 63 M 71 M 82 M 93 M 11 M 32 M 43 M 53 M 63 M 71 M 82 M 93 M 22 M 32 M 43 M 52 M 63 M 73 M 82 M 92 Option selection N/A #1-16 ($1) #1-6 ($2) #2-20($1) #1-14 ($2), #2-9 ($1), #2-22 ($2) #2-23 ($1) #1-18 ($1) #1-9 ($1) #2-9 ($1) #2-23 ($1) #1-18 ($1) Total Cost $63 $58.5 $59.5 $64 $59.5 $59.5 $59.5 $59 Cost score S c 84.48% 100% 96.55% 81.03% 96.55% 96.55% 96.55% 98.27% Space used Up to E Up to G Up to F Up to F Up to G Up to F Up to G Up to F Space score S s 100% 33% 66% 66% 33% 66% 33% 66% SDP 87.6% 86.6% 90.4% 78.0% 83.8% 90.4% 83.8% 91.8% Average SDP 85.6% 87.5% Table 5.9: Specifications of design outcomes The observed scores for the cost do not demonstrate a direct advantage to using the multi-level model of design space. Indeed, even though the average cost decreases the difference is not statistically significant (F=1.97, p=0.21) and does not allow us to reach a conclusion. The standard deviation drops from a value of σ 2 =2.66 to σ 3 = 0.25 denoting a higher consistency of the design results among the teams of group 3. This observation corroborates the average number of issues selected by teams of each group in their final design (2.25 for group 3 against 0.75 for group 2). Indeed, both observations and the chat logs indicate that the teams from group 3 were more successful at finding advantageous swaps between 2 machine sets with no issue and cheaper sets of 2 machines having an issue and an appropriate option. 160 Group 2 (PG) Group 3 (PSG) Average cost score Average space score Average SDP 40% 50% 60% 70% 80% 90% 100% Score-based design performance PG - PSG Average cost score Average space score Average SDP Figure 5.11: Cost, space and SDP performance for PG and PSG samples Naturally, the SDP values follow comparable trends, as they are based on the scores along the cost and space performance measures. The average SDP shows a continued progression from the comparison between results from group 1 and group 2. However, the statistical significance is not clearly established. Therefore, the contributions of the strategic support on the design outcome quality are important but not as far-reaching as expected according to this experiment. One can account for the lack of conclusive results for some of the observed parameters by considering the limited range of possible scores along the space performance. Since all the teams’ results were contained within blocks E to G, only 3 possible space scores (33%, 66% and 100%) exist and this affects the SDP value. The author argues that a modified version of this experiment, using a larger range of machines, with 161 more diverse sizes and shapes, in order to broaden the set of solutions along the space metric, should remedy this issue. Secondly, the exposure to the strategy support received by the subjects of group 3 was limited both in time and scope. The strategy support was presented over three slides of the PowerPoint slideshow, in the form of examples based on conflicts the subjects were likely to face during the problem resolution. It is difficult to assess how well the subject understood the concepts presented during the slideshow as well as how much information they retained from the presentation. As explained earlier, a more comprehensive presentation would have been overly time-consuming and was therefore avoided. A longer and more thorough exposure may be necessary for the strategy support to be effective; however in the absence of such data, no such result can be reasonably claimed here. 5.3.4.2 Design space exploration performance In terms of design space exploration, the results of groups 2 and 3 show a progression in the average numbers of issues and options discussed considered, even though the statistical significance is not reached. The standard deviation is too large and the number of sample data points too low to achieve a fine peak resolution and statistical significance. Collecting additional data points would help reach a conclusion. 162 Our third hypothesis stated that an improvement in the thoroughness of the design space exploration was anticipated, as the strategy support was providing the subjects with a tool facilitating conflict resolution, ZOPA creation and design co-construction. The results obtained in this experiment do not back up this hypothesis (F 1,6 =1.49, p = 0.269). The design problem, despite careful planning, did not prevent design “by fluke”, and even though the second team of group 3 did not exhibit significant efforts to explore the design space thoroughly, they achieved a high scoring design. Thus, even though they scored poorly along the design space exploration index, their SDP index is high. The design problem falls short and proves to be insufficiently intricate to require extensive and thorough design space exploration to achieve a “good design”. In a real-world design task, the complexity stems from the fact that the solution space is continuous and not discrete as in the problem used in this experiment. There are virtually thousands of solutions for each task leading towards a design solution, and the likelihood of achieving a good design by chance is essentially annihilated. As underlined in chapter 6, the experimental context is not an accurate description of a real-world problem, but allows us to conduct a manageable study, which wouldn’t be the case with a full-scale real design problem. Group 2 (PG) Group 3 (PSG) Creative Process Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 # of Issues discussed 4 3 4 3 5 2 6 8 # of Options discussed 3 4 2 2 3 1 6 7 DSE 46.4% 47.3% 39.3% 33.0% 52.7% 19.6% 80.4% 100% Average DSE 41.5% 63.2% Table 5.10: Design space exploration (PG-PSG treatments) 163 We explained earlier the complexity inherent to using a real life problem in such an experiment, in particular at the implementation and evaluation levels. Since the design outcome remains at the virtual level, there is no possibility to evaluate its actual performances. 5.3.4.3 Negotiation content distribution Comparing the negotiation content distribution results from group 2 and 3 reveals conclusive information about the impact of the strategy support model of ANED. We demonstrated how the implementation of the ABN protocol resulted in a negotiation process richer in resolution proposals (local/on other party/counter proposal) and relying less on strategic proposal. We explained the increase in number of proposals by linking them to the simultaneous decrease in information request (IR). Information requests utterances are not indicative of any value system or design preference. They therefore do not facilitate joint agreements which are essentially an alignment of the parties’ value systems. The protocol helped the subjects to express their intentions in the negotiation by making proposals the main utterance used for argument exchange. The decrease in the number of strategic proposals between groups 1 and 2 was explained by the lack of a specific performative supporting such activity. Group 2 (PG) Group 3 (PSG) Utterance Type Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Proposal (strategic) 6 0 0 2 6 5 5 10 Proposals total (L/OP/CP) 14 12 21 12 32 16 27 29 Agreements 9 10 16 8 17 11 18 17 Total argumentative 17 9 6 8 20 6 9 18 Information request 6 5 9 5 16 8 17 43 Issues discussed 4 3 4 3 5 2 6 8 Table 5.11: Results of negotiation chat log encoding 164 Figure 5.12: Negotiation content distribution for PG and PSG group Group 3, who received strategy support, generated a significantly higher number of strategic proposals (F 1,6 = 5.93, p = 0.051) while the total number of other proposals continues to increase (F 1,6 = 8.40, p = 0.027). Two conclusions can be drawn from these results. First, the strategy-support stimulus whose effectiveness was questioned in our analysis in the previous section has a distinct effect on the types of utterances employed by the subjects. The density of the total argumentative content does not change; however, more proposals are exchanged. The subjects are conscious that the discussion should not be limited to the machine selection level, and later on to the machine layout level, but should spread over the machines issues/incompatibilities level as well as the other two. They can therefore generate proposals over a larger scope which is visible in the data. Second, the strategy support enables the parties to discuss strategic planning despite the protocol flaw identified earlier. Such result demonstrates that even though the protocol was not designed to handle strategic proposals, the strategic support approach partially makes up for this shortcoming. The author believe that the Negotiation content distribution - Protocol supported group 0 2 4 6 8 10 12 14 16 18 20 Strategic proposal Resolution proposal Total Argumentative Agreements Number of utterances Negotiation content distribution - Protocol and Strategy supported Group 0 2 4 6 8 10 12 14 16 18 20 Strategic proposal Resolution proposal Total Argumentative Agreements Number of utterances 165 implementation of a revised protocol addressing this limitation, along with strategic support will have a drastic impact on conflict resolution and joint decision making in a collaborative design context. In addition, the increased number of proposals discussed above is echoed by a direct increase in the number of agreements reached as visible in table 8 (F 1,6 = 6.79, p = 0.040). This result backs up hypothesis #3 which states that the strategy support improves the efficiency of the joint decision-making process. The translation from a larger number of agreements to a better design score is however not observed due to the problem’s nature and specifications. Nonetheless this result is very strong, and the author argues that applying a modified protocol to a real-world collaborative design problem would prove very beneficial. To summarize this section, emphasis should be put on the fact that the protocol, completed by the strategic model of ANED contributed to an increase in the number of proposals exchanged – both strategic and resolution-oriented – amongst the participants, resulting in a higher number of joint decisions visible in the high number of agreements reached. 5.3.4.4 Negotiation Process Distribution The last metric used in this experiment analysis deals with the distribution of utterances over three distinct phases. Comparing the data from group 1 and 2 showed that the protocol implementation leads to a quasi complete absence of a strategic planning phase as well as a reshuffling of the negotiation activities. While non- supported teams spent an average 23% of their communication exchanges 166 strategizing, 42% on the resolution itself and the remainder 35% optimizing their design result, the supported team bypassed the planning stage and devoted almost 90% of their time searching for a solution, and the remainder 10% optimizing it. Group 2 (PG) Group 3 (PSG) Utterances distribution Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 For strategic planning 2 0 0 0 0 0 0 0 For design resolution 93 49 57 44 50 43 63 117 Number of utterances used For solution optimization 7 10 9 6 49 13 32 50 For strategic planning 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 For design resolution 0.91 0.83 0.86 0.88 0.51 0.77 0.66 0.70 Ratio of utterances used For solution optimization 0.07 0.17 0.14 0.12 0.49 0.23 0.34 0.30 Table 5.12: Number and ratios of utterances used per phase In this second analysis, the teams of group 3 exhibited a behavior similar to those of group 2. Indeed, the strategic planning phase was totally missing from their design problem resolution approach, for the same reasons presented in the previous section. Nonetheless, the distribution over the other two phases of the problem resolution is appreciably different. One-way ANOVAs over the ratio of utterances used for design resolution and solution optimization yield both F 1,6 = 13.37 and p = 0.011 (since the ratio of strategic planning is null). The teams spent an average of 66% of their communication efforts over the design problem resolution phase and the remainder 34% optimizing the design solution (Figure 5.13). This redistribution of the two activities is synonymous of a more effective problem resolution phase, since the total amount of utterances used is comparable in the two groups. This observation agrees 167 with the conclusion established earlier about the higher efficiency of the joint decision making process for group 3 observed through the number of agreements reached. The team members, who adhere to the same strategic model, achieve better understanding of each other’s intentions and negotiative stance. Group 2 (PG) Group 3 (PSG) Strategy phase Resolution phase Optimization phase 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% Percentage of utterances Negotiation process distribution PG - PSG Strategy phase Resolution phase Optimization phase Figure 5.13: Utterances distribution over negotiation phases 5.3.5 Summary of findings The aforementioned experiment proved to yield a number of very significant findings about inter-designer negotiation, design co-construction and design space exploration. Let us summarize those findings. The first two sets of experiments (Group 1 and 2) revealed the advantages of the negotiation protocol implementation by drawing comparisons between the results from both groups. In particular, we demonstrated that: • The implementation of the negotiation protocol positively impact the thoroughness of the design space exploration 168 • The content of the negotiation communications is richer in problem resolution oriented proposals • Simultaneously, the need for pure information requests and exchange is strongly diminished – the proposals being an alternate vector to pass on information • The distribution of the collaborative negotiation process over the planning, resolution and optimization phases shows a strong emphasis on resolution, a short optimization phase and a quasi inexistent strategic planning phase The second and third experiment sets (group 2 and 3) exposed additional results related to the impact of the strategic support method of ANED. In particular, we established that: • The strategy support incites the subjects to generate more proposals – both strategic and resolution oriented – and thus argue more • A higher number of agreements is achieved by the subjects, revealing an improved decision-making process efficiency • The number of arguments exchanged being equal, the strategy supported teams are able to reach a final design faster and spend more time optimizing their results. If we refer to the hypotheses presented in the beginning of section 5.1.2, we can draw the following conclusions: 169 Hypothesis 1: Our experiment does not show evidence supporting the fact that ANED’s protocol directly helps improve design outcome. Indeed even though the score observed show a progression with the implementation of the protocol, statistical analysis does not allow us to rule out the null hypothesis. Hypothesis 2: The experiment results demonstrate that group 2, using the negotiation protocol of ANED was more creative than group 1, therefore our second research hypothesis is verified. Hypothesis 3: We verified that the strategy support provided to group3 helped this treatment group to achieve better design space exploration as well as a higher rate of agreement reaching situations, therefore hypothesis 3 is established. Hypothesis 4: We observed that the implementation of the protocol affected the typical negotiation practice with a reshuffling of the importance of the strategic planning, problem resolution and design optimization phases. As a result, this hypothesis is also confirmed. A number of limitations of this research were identified and are presented in the next section. 5.3.6 Limitations The aforementioned results were established by carrying out this research work and the experimental study presented in this thesis. However, we recognized the following limitations: 170 • A limited number of experiment samples, as well as the presence of some shortcomings in the design problem prevent us to draw significant conclusions regarding the score-based design performance. • The subject pool used for this experiment was constituted of students and not professional designers, which constitutes another limit of our approach. No matter how verse into design these subjects may have been, they lack professional experience and therefore do not portray accurately real-world design practices and typical design skills. • The communication vector used in the experiment part of this research (chat window) is only one channel of communication which constitutes a limitation and a departure from a real-world case. Our main motivation was to capture the communication in its entirety and avoid means of communication such as body language, signs, or uncontrolled speech which occur in face-to-face encounters. In a real world design situation, all these communication vectors are used, thus our approach is not completely realistic. In the next chapter, we go over the contributions of this research work and possible future extensions. 171 Chapter 6: Contributions and future work Let us conclude this dissertation by going over the contributions of this work and introducing a number of research directions which should be investigated in the future. 6.1 Contributions The ANED framework presented in this thesis was created during our research on collaborative design and negotiation, is based on the hypothesis that the use of a structured negotiation protocol to exchange formatted arguments according to specific rules can positively affect the negotiation process and its outcome. The key issues to address in dealing with collaborative conflict resolution and inter-designer negotiation are: • To determine what mechanisms are involved in collaborative design conflict resolution and joint-decision making • To determine what should be the necessary and sufficient amount of communication to ensure optimal conflict resolution process and outcome • To establish how the conflict resolution task should be conducted and determine what strategy support method would be adapted 172 • To establish what elements promote creative thinking and creative communication and how to embed them in a support tool Contribution to the information and process modeling of collaborative design Design information modeling In our research, we first established the need for a general design context model which can be used to unequivocally identify information and data pertaining to the design context. We provided a detailed description of each of the elements of this design context model and how they relate to each other. We also emphasized the fact that this design context information is constantly changing as the design proceeds, and can be organized using the Decision History Tree modeling tool. The DHT is based on a decision-based view of design and allows design information tracking and design change impact assessment (what the repercussions of a change in one design tasks are upon the rest of the design process). The importance of value systems in the conflict resolution phase has been established in a number of domains including collaborative design [67] and a number of systems and frameworks have been devised to address this topic. However, they either adopt a prescriptive approach or focus their investigation on agent-based systems. In our framework, we gave a critical role to the design objectives which are an expression of the designers’ values systems in the context of a given design task and thus influence their resolution in a critical way. An accurate description of these design objectives is essential to establish the parties’ 173 negotiation stance and such description constituted the last component of our design context model. Design process modeling Addressing the issue of collaborative design conflict resolution requires not only a way to model design context information, but also a communication protocol to support allow designers with conflicting value systems and negotiation stances to work out their differences and achieve a joint decision. Creating such protocol constituted the core of our research efforts, and resulted in ANED’s negotiation protocol, based on the adaptation of the ZOPA model to the collaborative design context. In the course of this framework development, much attention was dedicated to create a sound protocol, by handpicking an appropriate set of performatives, establishing rules of precedence between them and adopting a clear argument model. This argument model, adapted from the work of rhetorician Toulmin, relies on the concepts of claim, data and warrant and imposes on the users to make use of logically related information, preventing any foul play, information retention or deceptive tactics. Being able to exchange arguments to move towards a consensus requires such protocol and argument model, but it also requires some strategic initiative on behalf of the negotiation participants. We developed an advanced representation of the design space, using elements of ANED’s design context model, which we separated into layers or abstraction levels. This representation is the foundation of our strategic support system, and allows users to navigate between abstractions level, in order to 174 align their reservation points and create Zones of Possible Agreement, essential to reach a mutually acceptable agreement. This system is centered on two types of strategic moves – exploration and elevation – allowing designers to investigate the design space, generate new ideas, create ZOPAS and eventually reach consensuses. Contribution to the knowledge of collaborative design negotiation The usefulness of the ANED framework was first demonstrated through a case study inspired by a real-world design problem and the consideration of a number of scenarios. The case study emphasized how the protocol can improve tremendously the outcome of the conflict resolution phase whether quantitative or qualitative issues are at stake. To further investigate the impact of the ANED framework, we developed a collaborative design experiment, using an exercise involving teams of two designers that we specifically created. The objectives of this experiment were to evaluate the performance of design teams using ANED, using a number of metrics indicative of good collaborative design practices. We compared the results achieved by three different treatment groups: a control group (receiving no support), a protocol- supported group (whose communication was monitored to fulfill the ANED guidelines) and a protocol and strategy-supported group (using the ANED protocol and its multi-level strategy extension). 175 This experiment revealed three strong results about the use of an argumentation- based negotiation protocol in collaborative design negotiation. They can be summarized as follows: • Limiting the negotiation communications by allowing only formatted and logically sequenced arguments according to a regulating protocol such as ANED improves the alternative generation process of collaborative design teams. The protocol ensures that any unjustified or unnecessary utterances are weeded out; as a result essential issues are investigated more thoroughly. • The use of such protocol converts the typical negotiation exchange from an activity based on information-passing to an activity based on proposal and argument exchanges. The parties truly engage in the negotiation, and are able to convey their value systems in the arguments they generate, and understand the other side’s value system. • The number of arguments generated and their distribution along the strategic planning, problem resolution and design optimization phases are affected by the use of the protocol. In particular, subjects exchange more utterances, i.e. argue more, and spend the majority of their exchanges at the resolution stage, and the rest on the optimization phase. The second phase of the experiment analysis – comparison between the results from group 2 and 3 – revealed additional results. In particular: • The use of a strategy model results in the generation of more proposals – both strategic and resolution oriented – on behalf of the subjects, indicative of a 176 more prolific exchange. A higher number of ideas are exchanged within the same amount of time • In parallel, the quantity of agreements concluded by the subjects augments, revealing an improved decision-making process efficiency; the subject are able to align their positions faster and better by having a common model of the design space and sharing common strategies. • With the same resolution time and the number of arguments exchanged being equal, the strategy supported teams are able to reach a final design. They can therefore spend the additional time optimizing their results, a behavior observed in the experimental data. Therefore, our framework contributes to a better understanding of the intricacies of collaborative design negotiation and proposes an efficient and easy-to-use support system, suitable to two-party collaborative negotiation over design conflicts. Future extensions of this work, in particular computer-based implementation as suggested in the next section will help improve the design negotiation practice tremendously. 6.2 Future Work We point out the following directions as possible complements and extensions to this research work: • Generating more data point through additional experiments: First, let us underline that some additional results could be established with additional experiment samples, in particular about the Score-based Design Performance, a design quality assessment metric that we developed in this research. The 177 data collected in the experiment presented in this thesis are showing a trend but lack significant resolution to claim any effect of the protocol implementation on this specific measure. Using a larger sample pool would establish whether our approach is truly improving design outcome or not. • Multiparty negotiation handling: To control the complexity of our task in this research, we limited the scope of our investigation to two-party negotiation. Our results can be expanded to three subjects and subsequently to n-subjects. Several issues will arise when this framework is extended to multi-party cases, in particular when dealing with the prioritization and acceptability of utterances (who should speak when), the problem of coalition formation and how to handle it, and the establishment of ZOPAs to name a few. • Computer-based implementation of ANED: This framework can benefit by being complemented with an actual computer-based tool, either allowing the users to communicate using the protocol directly or acting as a translator converting user input information into ANED formatted arguments. In addition, we envision that such implementation could provide personalized support to designers through computer agents acting as assistants. These agents could support activities such as design information tracking and maintenance, design conflict detection and resolution strategy support, low-complexity conflict handling. 178 Bibliography [1] S. Aknine, S. Pinson, and M. F. Shakun, “An Extended Multi-Agent Negotiation Protocol”, Autonomous Agents and Multi-Agent Systems, 8, 5-45, 2004. 2004 Kluwer Academic Publishers. [2] L. Amgoud and N. Maudet, “Strategical Considerations for argumentative agents”, 9th International Workshop on Non-Monotonic Reasoning (NMR 2002), April 19-21, Toulouse, France, Proceedings 2002. [3] L. Amgoud, S. Parsons “Agent Dialogues with Conflicting Preferences.” Intelligent Agents VIII, 8th International Workshop, ATAL 2001, Seattle, WA, USA, August 1-3, 2001, Revised Papers 190-205. [4] A. Anderson, I. Birgean and J. K. MacKie-Mason, “Bilateral negotiation with fees”. Institute for Advanced Commerce, Workshop on Internet Based Negotiation Technologies, March 18-19, 1999 Yorktown Heights, NY. [5] J. Andersson, “A survey of multiobjective optimization in engineering design” Technical report: LiTH-IKP-R-1097, 2000. [6] M. Andersson and T. Sandholm, “Time-Quality Tradeoffs in reallocative Negotiation with Combinatorial Contract Types”, AAAI, 1999. [7] L. Anthony, W. C. Regli, J. E. John, S.V. Lombeyda, “An Approach to Capturing Structure, Behavior, and Function of Artifacts in Computer-Aided Design.” 186-192. Journal of Computer and Information Science and Engineering, Volume 1, Number 2, June 2001. [8] E. Antonsson and K.N. Otto, “Imprecision in Engineering Design”, ASME Journal of Mechanical Design, 1995, Volume 117(B), pp 25-32, 1995. [9] K. J. Arrow, “Social Choice and Individual Values”. New York: John Wiley and Sons (1951, 1963). [10] J. L. Austin, “How to Do Things with Words”, Cambridge, Mass.: Harvard University Press, 1962. [11] T. Ballmer and W. Brennenstuhl, “Speech Act Classification: A study in the Lexical Analysis of English Speech Activity Verbs”. Springer Series in Language and Communication 8, Springer- Verlag Berlin Heidelberg New York 1981. [12] D. Bahler, C. Dupont and J. Bowen, “A Mixed Quantitative/Qualitative Method for Evaluating Compromise Solutions to Conflicts in Collaborative Design”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 9, (No. 4), pp 325-336, 1995. [13] D. Bahler, C. Dupont and J. Bowen, “Mediating conflict in Concurrent Engineering with a Protocol Based on Utility”, 1994. 179 [14] L. Bannon & K. Schmidt, “CSCW: Four Characters in Search of a Context”. In Proc. First European Conf. on CSCW, Gatwick, UK, Sept. 1989. (Reprinted in J. Bowers & S. Benford (Eds.) Studies in Computer Supported Cooperative Work: Theory, Practice and Design. pp. 3- 16. (Amsterdam: North-Holland), 1989. [15] M. Beer, M. d’Inverno, M. Luck, N. R. Jennings, C. Preist and M. Schroeder, “Negotiation in Multi-Agent Systems”, Workshop of the UK Special Interest Group on Multi-Agent Systems (UKMAS’98). [16] E. Bellucci and J. Zeleznikow, “ AI techniques for modeling legal negotiation”, Proceedings of the 7th international conference on Artificial intelligence and law, Oslo, Norway, 108 - 116 (1999). [17] O. Benami and Y. Jin, “Creative Stimulation in Conceptual Design”, Proceedings of DETC.02. ASME 2002 Design Engineering Technical Conferences and Computer and Information in Engineering Conference Montreal, Canada, September 29-October 2, 2002. [18] K. Binmore and N. Vulkan, “Applying Game Theory to Automated Negotiation”, DIMACS Workshop on Economics, Game Theory and the Internet, April, 1997, at Rutgers University, New Brunswick, NJ. [19] B. Boehm and H. In, “Conflict Analysis and Negotiation Aids for Cost-Quality Requirements”, Keynote Address, Pacific Northwest Software Quality Conference, Oct.12, 1999. [20] A.H. Bond and L. Gasser, “An Analysis of Problems and Research in DAI”, In Readings in Distributed Artificial Intelligence, A.H. Bond and L. Gasser (Eds.), Morgan Kaufmann, San Mateo, CA, pp.3-35, 1988. [21] A. Boyars, W. A. Kusmik and M. Yukish, “Collaborative Engineering Across Organizational Boundaries”, presented at ASNE Day 2002. [22] F. M. T. Brazier, P. H. G. van Langen, and J. Treur, 1995. “Modeling conflict management in design: an explicit approach”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 9, (No. 4), pp. 353–366. [23] D. C. Brown and B. Chandrasekaran, “Experts systems for a class of mechanical design activity” in J. S. Gero (ed) Knowledge engineering in computer-aided design, Amsterdam, North Holland, 1985. [24] V. Calabuig, A Cunyat and G. Olcina, “Partially Revocable Commitments in a Negotiation with an Uncertain Deadline”, Research in Economics (2004), Vol. 58 no. 4, 371-380. [25] J. A. Ceroni and A. A. Velásquez, “Conflict detection and resolution in distributed design”. In Production Planning and Control, Vol. 14, No. 8, December 2003, 734-742. [26] M.K. Chang and C. C. Woo, “A Speech-act-based Negotiation Protocol: Design, Implementation and Test Use.” ACM Transactions on Information Systems (TOIS) Volume 12, Issue 4, 360-382, 1994. [27] K. W. Chase and W. H. Greenwood, “Design Issues in Mechanical Tolerance Analysis.” Manufacturing Review, 1988. 180 [28] H. R. Choi, H. S. Kim, Y. J. Park, B. J. Park, and Y. S. Park, “multi-agent based negotiation support systems for order-based Manufacturers”, Proceedings of the 5th international conference on Electronic commerce, Pittsburgh, Pennsylvania 479 - 487 (2003). [29] R. A. Crabtree, N. K. Baid, M. S. Fox, “Design Engineering: Problems in Coordination” Proceedings of Joint JSME/ASME, workshop on Design, Tokyo, Japan, June 1993. [30] R. D. Coyne, M. A. Rosenman, A. D. Radford and J. S. Gero, “Innovation and creativity in knowledge-based CAD, in J. S. Gero (ed) Experts systems in computer-aided design, Amsterdam, North Holland, 1987. [31] M. R. Danesh and Y. Jin, “An Agent-Based Decision Network for Concurrent Engineering”, in Journal of Concurrent Engineering Research and Application, Vol.9, No.1, pp.37-47, 2001. [32] M.R. Danesh Dezfuli, “A framework for Value-based conceptual engineering design”, Doctoral Dissertation, 2001, Aerospace and Mechanical Engineering Department, University of Southern California. [33] R. K. Dash, D. C. Parkes and N. R. Jennings. “Computational mechanism design: A call to arms”. IEEE Intelligent Systems, 18(6):40-47, 2003. [34] P. Dillenbourg and M.J. Baker, “Negotiation Spaces in Human-Computer Collaboration”. In Actes du colloque COOP'96, Second International Conference on Design of Cooperative Systems, pp. 187-206, INRIA, Juan-les-Pins, June 1996. [35] P. Dillenbourg, M. Baker, A. Blaye, & C. O'Malley, “The evolution of research on collaborative learning”. In E. Spada & P. Reiman (Eds) Learning in Humans and Machine: Towards an interdisciplinary learning science. (Pp. 189-211). Oxford: Elsevier, 1996. [36] W. Doise, “The development of individual competencies through social interaction”. In H.C. Foot, M.J. Morgan, & R.H. Shute (Eds.) Children helping children. Chichester: J. Wiley & sons. pp. 43-64, 1990. [37] E. Domb, “40 Inventive Principles with Examples” The TRIZ Journal, http://www.triz- journal.com, April, 1997. [38] K. Dorst and D. Hendricks, “The Role of the Design Context: In Practice and in Design Methodology” Design Thinking Research Symposium 5, dec. 18-20, 2001 [39] K. M Eisenhardt, J. L. Kahwajy, & L. J. Bourgeois, “Conflict and strategic choice: How top management teams disagree”. California Management Review, 39 (2), pp42– 62, 1997. [40] K. A. Ericson and H. A. Simon, “Protocol Analysis: Verbal reports as data”, MIT Press, Cambridge MA, 1993. [41] L. D. Erman., J. S. Lark and F. Hayes-Roth, “ABE: An Environment for Engineering Intelligent Systems”. IEEE Transactions on Software Engineering SE-14, 1758-1769, 1988. [42] W. M Evan and McDougall J. A., “Interorganizational conflict: A labor-management bargaining experiment”, Journal of Conflict Resolution Volume XI, No.4, Dec. 1967, pp 398-413. 181 [43] P. Faratin, C. Sierra and N. R. Jennings, “Negotiation decision functions for autonomous agents”. In International Journal of Robotics and Autonomous Systems, 24 (3-4). pp. 159-182, 1998. [44] P. Faratin and M. Klein, “Automated contract negotiation and execution as a system of constraints”. In Proceedings of the Workshop on Distributed Constraint Reasoning, IJCAI-01, Seattle, US, 33—45 [45] P. Faratin, “Automated Service Negotiation between Autonomous Computational Agents” Doctoral Thesis, Department of Electronic Engineering, Queen Mary & Westfield College, University of London, Dec. 2000. [46] T. Finin, R Fritzson, D. McKay and R. McEntire, “KQML as an Agent Communication Language” Proceedings of the Third International Conference on Information and Knowledge Management, CIKM ’94, ACM press Nov. 1994. [47] T. Finin, Y. Labrou and J. Mayfield, “Evaluating KQML as an agent communication language”. Intelligent Agents – Proceedings of the 1995 Workshop on Agent Theories, Architectures, and Languages (ATAL-95), Volume 1037 of Lecture Notes in Artificial Intelligence, pp 347-360. [48] R. Fisher and W. Ury, “Getting to Yes”. New York: Penguin Books, 1983. [49] S. Franklin and A. Graesser, “Is it an agent, or Just a Program?: A Taxonomy for Autonomous Agents”. Proceedings of ECAI ’96 workshop (ATAL), Budapest, Hungary, August 12-13, 1996, pp 21-35. [50] T. Furusawa and Q. Wen, “Flexibility of disagreement actions in negotiations”, International Journal of Game Theory, (2001) Vol. 30 , 19-39. [51] J. S. Gero, “Design prototypes: A knowledge representation schema for design”, AI magazine, Vol. 11 pp26-36, 1991. [52] J. S. Gero and McNeill, T., “An approach to analysis of design protocols”, Design Studies, Vol. 19, pp. 22-61, 1998. [53] M. Geslin and Jin, Y, “A context-based approach to engineering design negotiation”, in Proceedings of ASME 2005 International Design Engineering Technical Conferences, Long Beach, CA, September 24-28, 2005. [54] J. Grudin, "CSCW: History and Focus", IEEE Computer, 1994. [55] P.H. Gulliver, “Disputes and Negotiations: A Cross-Cultural Perspective”. Academic Press, New York, 1979. [56] J. S. Hammond, R. L. Kenney and H. Raiffa, “Even swaps: a rational method for making trade- offs”, Harvard Business Review, 76(2), 137-149, 1998. [57] J. S. Hammond, R. L. Kenney and H. Raiffa, “Smart choices”. Cambridge, Mass.: Harvard Business School Press, 1999. [58] J. W. D. Lin Hsiao, http://www.edb.utexas.edu/csclstudent/Dhsiao/theories.html 182 [59] X. Hu, J. Pang Y. Pang, M. Atwood W. Sun, W. C. Regli, “A survey on Design Rationale: Representation, capture and retrieval”. Proceedings of DETC’00, 2000 ASME Design Engineering Technical Conferences, September 10-13, 2000, Baltimore, Maryland [60] N. R. Jennings, P. Faratin, A. R. Lomuscio, S. Parsons, C. Sierra and M. Wooldridge "Automated negotiation: prospects, methods and challenges" Int. J. of Group Decision and Negotiation 10 (2) 199-215, 2001. [61] N. R. Jennings, S. Parsons, C. Sierra, P. Faratin “Automated Negotiation” Proc. 5th Int. Conf. on the Practical Application of Intelligent Agents and Multi- Agent Systems (PAAM-2000), Manchester, UK, 23-30. [62] N.R. Jennings, S. Parsons, P. Noriega, and C. Sierra., “On Argumentation-Based Negotiation”, in Proceedings of the International Workshop on Multi-Agent Systems, pp.1-7, Boston, USA. 1998. [63] Y. Jin, and S. Lu, “An Agent-Supported Approach to Collaborative Design”, CIRP Annals, 47/1:107-110, 1998. [64] R. L. Keeney, “Value-Focused Thinking: A Path to Creative Decision-making”. Harvard University Press, 1992. [65] K. Kim, B. C. Paulson Jr., R. E. Levitt, M.A. Fischer, C. J. Petrie Jr. “Distributed coordination of project schedule changes using agent-based compensatory negotiation methodology”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, (2003), 17, 115- 131. [66] J. S. Kirschman and J. S. Greenstein, “The use of groupware for collaboration in distributed student engineering design teams” Journal of Engineering Education, Oct 2002. [67] M. Klein, “Supporting conflict resolution in cooperative design systems”, IEEE Transaction on Systems, Man and Cybernetics. Special Issue on Distributed Artificial Intelligence. Volume 21, Number 6, December 1991. [68] M. Klein, “Supporting Conflict management in Cooperative Design Teams”, Journal of Group Decision Making and Negotiation. Special Issue on the 1992 Distributed AI Workshop, March 1993. [69] M. Klein, P. Faratin, H. Sayama and Y. Bar-Yam, “Negotiation Algorithms for Collaborative Design Settings” Proceedings of the 10th ISPE International Conference on Concurrent Engineering Research and Applications (CERA-03) [70] M. Klein, “Towards a Systematic Repository of Knowledge About Managing Collaborative Design Conflicts”. In Proceedings of the International Conference on AI in Design. Boston, MA. 2000. [71] R. B. Korobkin, “A Positive Theory of Legal Negotiation”, Georgetown Law Journal, Vol. 88, 2000. [72] S. Kraus, K. Sycara, & A. Evenchik, “Reaching agreements through argumentation: a logical model and implementation.” Artificial Intelligence 104(1–2), 1–69, 1998. 183 [73] K. Kwon, S. W. Cho, Y. Choi and G. Lee, “Application of Multi-Frontal Method in Collaborative Engineering Environment”, International Journal of CAD/CAM (2003), Vol. 3 No.2, pp 51-60. [74] K. Lewis, and F. Mistree, "Collaborative, Sequential and Isolated Decisions in Design," Journal of Mechanical Design, Vol. 120, pp. 643-652, 1998. [75] S. Y. Lu, F. Udwadia, B. Burkett, and J Cai: “Design Rationale for collaborative engineering design in the Socio-technical Framework”, Engineering School, University of Southern California, Los Angeles. [76] S. Y. Lu, “Engineering as Collaborative Negotiation – A New Paradigm for Collaborative Engineering”, Position Paper, 2003. [77] W. Mark, J. Schlossberg, S. Tyler & J. McGuire. “Cosmos: A System for Supporting Engineering Negotiation.” Concurrent Engineering: Research and Applications, 2, 173-182, 1994. http://citeseer.ist.psu.edu/mark94cosmos.html [78] A. Mauleon, V. Vannetelbosch, “Coalitional negotiation”, IEP Discussion Paper, Economic Theory Series, 9901. March 1999. [79] J. G. McGuire, D. R. Kuokka, J. C. Weber, J. M. Tenenbaum, T. R. Gruber, and G. R. Olsen. “SHADE: Technology for knowledge-based collaborative engineering.” Concurrent Engineering: Research and Applications, 1(3), 1993. http://citeseer.ist.psu.edu/mcguire93shade.html [80] R. H. Mnookin, S. R. Peppet, A.S. Tulumello. “Beyond Winning: Negotiating to Create Value in Deals and Disputes”. Belknap Press, April 2004. ISBN: 0674012313. [81] J. K. Murnighan and M. H. Bazerman, “A perspective on negotiation research in accounting and auditing”, The Account Review, Vol. 65, No.3 (Jul. 1990) 642-657. [82] K. L. Myers, N. B. Zumel and P. Garcia, “Automated capture of Rationale for the Detailed Design Process”, Proceedings of the 11 th Conference on Innovation Applications of Artificial Intelligence, 1999, AAAI 1999. [83] K. L. Myers, N. B. Zumel, and P. Garcia. “Acquiring design rationale automatically”. AI EDAM, 14(2):115--135, 2000. [84] T. Nakagawa, “Learning and Applying the Essence of TRIZ with Easier USIT Procedure”; Proceedings of ETRIA World Conference: TRIZ Future, Bath, UK, Nov. 7-9, 2001 pp. 151-164. [85] T. J. Norman, N. R. Jennings, P. Faratin, E. H. Mamdani, “Designing and Implementing a Multi- agent Architecture for Business Process Management”. Proceedings of ECAI ’96 workshop (ATAL), Budapest, Hungary. Aug. 12-13 1996. [86] G. R. Olsen, M. Cutkoski, J. M. Tenenbaum and T. R. Gruber, “Collaborative Engineering based on Knowledge Sharing Agreements”, Proceedings of the 1994 ASME Database Symposium, September 11-14, 1994, Minneapolis, MN. [87] G. Pahl, and W. Beitz, “Engineering Design: A systematic Approach”, edited by Ken Wallace, Springer-Verlag, The Design Council, 1988. 184 [88] S. Parson, C. Sierra and N. R. Jennings, “Agents that reason and negotiation by arguing”, Journal of Logic and Computation, 8 (3). pp. 261-292, Feb. 1998. [89] L. H. Pelled, K. M. Eisenhardt, and K. R. Xin, “Exploring the black box: An analysis of work group diversity, conflict, and performance”. Administrative Science Quarterly, 44, 1– 28, 1999. [90] F. Peña-Mora, and Wang, C. Y. “Computer-Supported Collaborative Negotiation Methodology”, Journal of Computing in Civil Engineering, Vol.12 No.2, pp 64-81, April 1998. [91] C. J. Petrie, “The Redux’ server”, proceedings of the international conference on intelligent and cooperative information systems (ICICIS), Rotterdam, 1993. [92] C. J. Petrie, T. A. Webster, and M. R. Cutkosky, “Using Pareto Optimality to Coordinate Distributed Agents”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 9 (No. 4), pp 313-323, 1995. [93] J. T. Polzer, E. A. Mannix and M. A. Neale, “Interest alignment and coalition in Multiparty Negotiation”. The academy of Management Journal, Vol. 41, No. 1 (Feb. 1998) 42-54. [94] J. T. Polzer, “Intergroup negotiations the effects of negotiating teams” Journal of Conflict Resolution, Vol. 40 No 4 December 1996, 678 698, Sage publications, Inc, 1996. [95] D. G. Pruitt, “Negotiation Behavior”. Organizational and occupational psychology series, Academic Press, 1981. [96] M. A. Rahim, “Managing Conflict in Organizations”, Praeger, New York, 1986. [97] I. Rahwan, S.D. Ramchurn, N.R. Jennings, P. McBurney, S. Parsons and L. Sonenberg, “Argumentation-based negotiation”, The Knowledge Engineering Review (2003). [98] I. Rahwan, L. Sonenberg, F. Dignum, “Towards interest-based negotiation” AAMAS’03, July 14–18, 2003, Melbourne, Australia. [99] H. Raiffa, J. Richardson, and David Metcalfe. “Negotiation Analysis: The Science and Art of Collaborative Decision Making”. The Belknap press of Harvard University Press, 2002. [100] M. G. Raith, “Fair Negotiation Procedures”, Mathematical Social Sciences (2000), Vol.39, 303- 322. [101] S. D. Ramchurn, N. R. Jennings, and C. Sierra, “Persuasive negotiation for autonomous agents: A rhetorical approach.” In Proceedings of IJCAI Workshop on Computational Models of Natural Argument, pages pp. 9-17, Acapulco, Mexico, 2003. [102] A. Ran and J. Kuusela, “Design Decision Trees”, Proceedings of the 8 th International Workshop on Software Specification and Design, 1996, 1996 IEEE. [103] A. Rapoport, I. Erev and R. Zwick. “An Experimental Study of Buyer-Seller Negotiation with One-Sided Incomplete Information and Time Discounting.” Management Science Journal, Vol. 41 (No. 3) (Mar. 1995), pp 377-394. [104] E. B. Rasmussen, "A Model of Negotiation, Not Bargaining: Explaining Incomplete Contracts" (May 2001). Harvard Law and Economics Discussion Paper No. 324. 185 [105] C. Reed, T. J. Norman, N. R. Jennings, “Negotiating the Semantics of Agent Communication Languages”, Computational Intelligence (2002), 18(2):229-252. [106] W. C. Regli, X. Hu, M. Atwood and W. Sun, “A Survey of Design Rationale Systems: Approaches, Representation, Capture and Retrieval”, Engineering with Computers (2000) 16: 209–235, 2000 Springer-Verlag London Limited. [107] I.M.M.J. Reymen, P. Kroes, and T. Basten. “Modeling the role of the design context in the design process: A domain-independent approach.” In D. Durling and J. Shackleton, editors, Common Ground, Design Research Society International Conference 2002, Proceedings, pages 917-927. Brunel University, London, UK, 5-7 September 2002. Staffordshire University Press, Stoke-on-Trent, UK, 2002. [108] L. Roque, & A. Almeida, “Towards the Design of Context”. CHI 2000 Workshop Research Directions in situated Computing, 2000. [109] J. S. Rosenschein and M. R. Genesereth, “Deals among Rational Agents”. Proc. 9th Int. Joint Conf. on AI (IJCAI-85), Los Angeles, 91-99, 1985. [110] J. Ronsenschein, and G. Zlotkin., “Rules of Encounter: Designing Conventions for Automated Negotiation among Computers”. MIT Press, Cambridge MA, USA, 1994. [111] R. S. Ross, and J.R. Ross, “Small groups in organizational settings”. Englewood Cliffs, NJ: Prentice-Hall, 1989. [112] A. Rubinstein, “Comments on the Interpretation of Game Theory”, Econometrica Vol. 59, No. 4 (Jul., 1991), 909-924. Published by The Econometric Society. [113] A. Rubinstein, “Perfect Equilibrium in a Bargaining model”, Econometrica Vol. 50, No. 1 (Jan. 1982) 97-110. [114] S. V. Rueda, A. J. Garcia and G. R. Simari, “Argument-based Negotiation among BDI agents”, JCS&T Vol. 2 No. 7, October 2002. [115] T. W. Sandholm, “An implementation of the Contract-Net Protocol based on marginal cost calculations”. Proceedings of the 12 th international Workshop on Distributed Artificial Intelligence. Hidden Valley, Pennsylvania, pp295-308, 1993. [116] M. J. Scott and E. K. Antonsson, “Formalisms for negotiation in Engineering Design”, Proceedings of the 1996 ASME DETC conference, Aug. 18-22, 1996, Irvine, California. [117] M. Scott, “Formalizing Negotiation in Engineering Design”, Ph.D. Thesis, California Institute of Technology, 1997. [118] Q. R. Scott, “SSPARCy: A Software Integration Support and Design Rationale Capture System” , Master Thesis, MIT, 2001. [119] J. Searle, “Speech Acts: An Essay in the Philosophy of Language”, Cambridge, Eng.: Cambridge University Press, 1969. [120] J. J., Shah, S. M. Smith and N. Vargas-Hernandez, “Metrics for measuring ideation effectiveness”, Design Studies V24 (2), pp111-134, 2003. 186 [121] C. Sierra, N. R. Jennings, P. Noriega and S. Parsons, “A framework for argumentation-based negotiation”. Proceedings of 4th Int. Workshop on Agent Theories, Architectures and Languages (ATAL 97) , pages pp. 167-182, Rhode Island, USA. [122] R.G. Smith, “The contract net protocol: High-level communication and control in a distributed Problem solver”, IEEE Transactions on computers, vol. 12, 1980. [123] N. P. Suh, “The Principles of Design”, Oxford Series on Advances Manufacturing, New York Oxford University Press, 1990. [124] K.P. Sycara, “Multiagent Compromise via Negotiation”. In Distributed Artificial Intelligence, Gasser, L. and Huhns M. Eds. Vol. 2. Pitman Publishing, London, 119-137, 1989. [125] S. Szykman and R. D. Sriram, W. C. Regli, “The Role of Knowledge in Next Generation Product Development Systems”, ASME Journal of Computation and Information Science in Engineering. Volume 1, Number 1, 2001. [126] Taguchi, G., 1993, ‘‘On Robust Technology Development, Bringing Quality Engineering Upstream,’’ ASME Press. [127] M. Tokoro, “An Agent is an Individual That Has Consciousness”, Proceedings of ECAI ’96 workshop (ATAL), Budapest, Hungary, August 12-13, 1996, pp 45-46. [128] P. Torroni, “A study on the termination of negotiation dialogues”. In Cristiano Castelfranchi and W. Lewis Johnson, eds., Proceedings of the 1st International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS-2002), Bologna, Italy, ACM Press, July 2002. ISBN 1- 58113-480-0 pp. 1223-1230, 2002. [129] S.E. Toulmin, “The uses of arguments”, Cambridge; New York: Cambridge University Press, 2003, 1969. [130] P. Wei, Y. Yan, Y. Ni, J. Yen and F. F. Wu, “A Multi-Agent Based Negotiation Support System for Cost Allocation of Cross-border Transmission”, Proceedings of the 34th Hawaii International Conference on System Sciences – 2001. [131] S. J. Wilsson, “Axioms for the outcome of negotiation in matrix games”, Journal of Mathematical Social Sciences, Vol 39, (2000) 323-348. [132] K. L. Wood and E. K. Antonsson, “Computations with Imprecise Parameters in Engineering Design: Background and Theory”. ASME Journal of Mechanisms, Transmissions, and Automation in Design, Vol. 111 (No. 4), pp 83-91, 1989. [133] M. Wooldridge & N. R. Jennings, “Agent Theories, Architectures and Languages: a Survey”. In Wooldridge and Jennings Eds. Intelligent Agents. Springer-Verlag, 1-22, 1995. [134] L. Xue, “Negotiation-proof Nash equilibrium”, International Journal of Game Theory, (2000) Vol 29., 339-357. 187 [135] Y. Yan, J. Yen and T. X. Bui, “A Multi-Agent Based Negotiation Support System for Distributed Transmission Cost Allocation”, Proceedings of the 33rd Hawaii International Conference on System Sciences – 2000. [136] L. Zhao, “ActiveProcess: A Process-Driven Approach to Supporting Collaborative Engineering”. Dissertation Proposal, Impact Laboratory, University of Southern California, 2001. 188 Appendices A-1 Designer 1 Process Morphology chart Figure A-1: Designer 1 Process Morphology Chart Alternative 1 Alternative 2 Alternative 3 Operations Description Specs Description Specs Description Specs F 1 : Casting M 11 : Sand Casting Cost: $15 Size: M 12 : Die Casting Cost: $21 Size: M 13 : Permanent mold casting Cost: $22 Size: F 2 : Machining M 21 : Milling machine M 22 : CNC Milling machine Cost: $18 Size: F 3 : Thread Cutting M 31 : Thread Milling Cost: $18 Size: M 32 : Thread Rolling Cost: $10.5 Size: M 33 : Thread grinding Cost: $9.5 Size: F 4 : Create Holes M 41 : Column drilling machine Cost: $5 Size: M 42 : NC turrent drilling machine Cost: $8 Size: M 43 : Gang Drilling machine Cost: $7 Size: PRODUCTION F 5 : Joining/ Assembly M 51 : Welding Cost:$7 Size: M 52 : Brazing Cost: $6 Size: M 93 : Mechanical Fasteners Cost: $3 Size: 189 A-2 Designer 2 Process Morphology chart Figure A-2: Designer 2 Process Morphology Chart Alternative 1 Alternative 2 Alternative 3 Operations Description Specs Description Specs Description Specs F 6 : Sheet cutting M 61 : Band saw cutting Cost: $2 Size: M 62 : Plasma cutting Cost: $5.5 Size: M 63 : Permanent mold casting Cost: $3.5 Size: F 7 : Grid pattern making M 71 : Piercing Cost: $5 Size: M 72 : Water jet cutting Cost: $11 Size: M 73 : Shearing Cost: $3 Size: Grid Production F 8 : Joining/ Assembly M 81 : Welding Cost: $7 Size: M 82 : Thread Rolling Cost: $5 Size: M 83 : Thread grinding Cost: $4 Size: F 9 : Heat treatment M 91 : Autoclave Cost: $9 Size: M 92 : Vertical furnace Cost: $5 Size: M 93 : Muffle furnace Cost: $6.5 Size: Assembly 190 A-3 Compatibilities and issues sheet for designer 1 X = Incompatibility I i = Issue M 11 M 12 M 13 M 21 M 22 M 31 M 32 M 33 M 41 M 42 M 43 M 51 M 52 M 53 M 11 X M 12 M 13 M 21 X M 22 M 31 M 32 M 33 X X X M 41 X X M 42 M 43 M 51 M 52 M 53 X Table A-3-1: Local incompatibility table M 61 M 62 M 63 M 71 M 72 M 73 M 81 M 82 M 83 M 91 M 92 M 93 M 11 X I 2 M 12 I 1 M 13 M 21 X I 3 M 22 M 31 M 32 I 5 M 33 X M 41 I 6 X M 42 I 7 M 43 M 51 M 52 M 53 X I 8 Table A-3-2: Global incompatibilities and issues for designer 1 191 I 1 M12 - M61 Require measure of water filter conduit dimensions for proper fit with filtering grid I 2 M11 - M63 Imprecision of sand casting requires additional fitting operation I 3 M21 - M63 Combined noise of circular saw and milling machine hazardous to operators I 4 M33 - M71 Thread grinding machine creates vibrations preventing proper piercing I 5 M32 - M73 Thread rolling machine heat affects shearing machine precision I 6 M41 - M81 Welding sparks hazardous to drilling machine operators I 7 M42 - M83 Holes drilled must have thread I 8 M53 - M93 Muffle furnace weakens screwed assemblies Table A-3-3: Issues description for designer 1 192 A-4 Compatibility and issues sheet for designer 2 X = Incompatibility I i = Issue m61 m62 m63 m71 m72 m73 m81 m82 m83 m91 m92 m93 m61 X m62 m63 m71 m72 m73 X X m81 m82 m83 X X m91 m92 X m93 Table A-4-1: Local incompatibility table m11 m12 m13 m21 M22 m31 m32 m33 m41 m42 m43 m51 m52 m53 m61 X I 1 X I 2 m62 m63 I 3 m71 m72 m73 I 4 X m81 m82 I 5 m83 X I 6 m91 m92 I 7 I 8 X m93 Table A-4-2: Global incompatibilities and issues I 1 M61 - M13 Mold casting machine requires hydraulic pressure feed I 2 M61 - M22 Cut grid must be checked dimensionally to match NC high quality I 3 M63 - M11 Safety of operators at risk when machines next to each other I 4 M73 - M32 Vibrations of shearing machine disrupt threading I 5 M82 - M41 Brazing operation affects structural strength of filter part I 6 M83 - M43 Fixation holes must be threaded I 7 M92 - M51 Welded part must be cooled at low temperature before heat treatment I 8 M92 - M52 Brazed areas must be chemically protected before being put in furnace Table A-4-3: Issues description for designer 2 193 A-5 Options List Option # Description Cost Size O 1 Industrial vacuum cleaner $2.00 1 block O 2 Display board $3.00 1 block O 3 Large mounting hooks $3.00 N/A O 4 Conveyor belt $1.00 2 blocks O 5 Nail gun $3.00 N/A O 6 Machine Lubricant $2.00 N/A O 7 Soundproof Wall $2.00 N/A O 8 Sanding machine for rapid surfacing $3.00 1 block O 9 Hand fitting station $1.00 1 block O 10 High quality spray guns for paint $3.00 N/A O 11 Dimensional control station $3.00 2 blocks O 12 Ventilation Unit $1.00 1 block O 13 Air conditioning unit $1.00 1 block O 14 Shock absorbers for machine $2.00 N/A O 15 UV spot lamp $3.00 N/A O 16 High performance hearing protection headset $2.00 N/A O 17 Engine coolant $1.00 N/A O 18 Heating pads $2.00 N/A O 19 46 inch ceiling fan $3.00 N/A O 20 Automated hole threading station $1.00 2 blocks O 21 Silent blocks $3.00 N/A O 22 High strength adhesive $2.00 N/A O 23 Quick unscrewing / re-screwing station $1.00 1 block O 24 High voltage fuse box $2.00 N/A O 25 Heat and UV-resistant protective screen $1.00 N/A Table A-5-1: Option list for Designer 1 194 Option # Description Cost Size O 1 Hydraulic press $3.00 1 Block O 2 Engine coolant $1.00 N/A O 3 Heating pads $3.00 N/A O 4 High performance fan $2.00 1 Block O 5 Insulation pads $2.00 N/A O 6 Low temperature cooling pads $2.00 N/A O 7 Painting booth $2.00 2 Blocks O 8 Rubber joints $3.00 N/A O 9 Safety rules training $1.00 N/A O 10 Silicone Sealant $3.00 N/A O 11 Pump for hydraulic actuation $1.00 2 Blocks O 12 Rust-resistant primer $3.00 N/A O 13 Hydro forming machine $2.00 2 Blocks O 14 Dimensional control station $2.00 2 Blocks O 15 Plastic coating machine $3.00 1 Block O 16 Tool for control of structural integrity of assemblies $1.00 3 Blocks O 17 Machine Lubricant $3.00 N/A O 18 Heat-protective solution for brazed parts $1.00 N/A O 19 Forging machine $2.00 2 Blocks O 20 Threading tap manual station $3.00 2 Blocks O 21 Sealant applicator $2.00 N/A O 22 High performance shock absorbers $1.00 N/A O 23 Ear plugs $3.00 N/A O 24 Industrial bench grinder $2.00 1 Block Table A-5-2: Option list for Designer 2 195 A-6 Negotiation chat logs samples … Des1 next process Des1 what size block do we want here so your blocks can fit? Des1 we can choose between 2 or 3 Des1 three is $3 Des2 And 2 ? Des1 two is $6 Des2 for the next process i have the options of 1 at $5.5; 3 @ $2; and 2 @ $3.5 Des1 ok and we can put it 100% in out half or is it only allowed 50%? Des2 can only be 50% in the top Des1 ok let's do 2 block Des2 but and then do which one of mine? Des1 m52 Des2 Okay … Figure A-4-1: Group 1 – Control Group … Des1 P>f6=M63 Des2 Cr>f6 = M62 AS f6 = M63 conflict with M11 Des1 D> f6=M63 AND add Engine coolant AS engine coolant cost is only 1 dollar Des2 Cr>Safety of operator at risk when M63 next to M11 Des1 D>Add Safety rules training AS cost IS 1 dollar and total cost IS 2 dollars? Des2 IR>2 dollars less? Des1 IPs> cost IS 2 dollars more on my side Des2 IPv> M63 is 2 dollars less than M62 … Figure A-4-2: Group 2 – Protocol-Supported Group 196 A-7 One way ANOVA for design score One-way ANOVA: Adjust Score 0.1/0.9 versus Experiment Type Analysis of Variance for Adjust Score 0.1/0.9 Source DF SS MS F P Experiment type 1 229.0 229.0 8.82 0.025 Error 6 155.8 26.0 Total 7 384.7 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ---+---------+---------+---------+--- -1 4 74.225 4.422 (--------*--------) 1 4 84.925 5.689 (--------*--------) ---+---------+---------+---------+--- Pooled StDev = 5.095 70.0 77.0 84.0 91.0 Figure A-5-1 ANOVA for adjusted design score (with 0.1/0.9 coefficients) a) b) c) Figure A-5-2 Residual plots for adjusted design score 197 A-8 Count of utterances used in experiment samples Group 1 (CG) Group 2 (PG) Utterance type Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Proposal (strategic) 8 4 15 11 6 0 0 2 Proposal Local 1 1 5 4 5 6 13 7 Proposal on other party 2 1 4 3 8 3 4 2 Counter-proposal 3 0 1 2 1 3 4 3 Proposals total (L/OP/CP) 6 2 10 9 14 12 21 12 Critique 5 0 0 3 8 3 2 1 Defense 0 0 0 1 7 1 0 0 Agreement 9 3 15 7 9 10 16 8 Dissent 0 0 0 2 1 0 1 0 Total argumentative 14 3 15 13 25 14 19 9 Information request 21 5 37 29 6 5 9 5 Information passing Solicited 12 2 24 22 6 4 5 3 Information passing Voluntarily 17 8 40 25 16 5 4 8 Issues discussed 1 0 0 0 4 3 4 3 Table A-8: Count of utterances used in each experiment A-9 ANED testing - Experiment results Table A-9-1: Design results summary Group 1 (CG) Group 2 (PG) Group 3 (PSG) Creative Process Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 # of Issues discussed 1 0 0 0 4 3 4 3 5 2 6 8 # of Options discussed 2 0 0 0 3 4 2 2 3 1 6 7 DSE 20.5% 0% 0% 0% 46.4% 47.3% 39.3% 33.0% 52.7% 19.6% 80.4% 100% Table A-9-2: Analysis of creative process Group 1 (CG) Group 2 (PG) Group 3 (PSG) Experiment data Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Machine selection M 12 M 32 M 43 M 53 M 63 M 71 M 81 M 93 M 21 M 32 M 42 M 53 M 62 M 71 M 81 M 93 M 11 M 32 M 41 M 52 M 62 M 71 M 81 M 91 M 22 M 32 M 42 , M 52 M 63 M 71 M 82 M 93 M 11 M 32 M 43 M 52 M 62 M 71 M 82 M 91 M 11 M 32 M 43 M 53 M 62 M 71 M 82 M 93 M 11 M 32 M 43 M 53 M 62 M 71 M 82 M 93 M 12 M 32 M 43 M 53 M 63 M 71 M 83 M 91 M 11 M 33 M 43 M 53 M 63 M 71 M 82 M 93 M 22 M 32 M 43 M 53 M 63 M 71 M 82 M 93 M 11 M 32 M 43 M 53 M 63 M 71 M 82 M 93 M 22 M 32 M 43 M 52 M 63 M 73 M 82 M 92 Option selection #1-5 ($2) N/A N/A N/A N/A #1-16 ($1) #1-6 ($2) #2-20($1) #1-14 ($2), #2-9 ($1), #2-22 ($2) #2-23 ($1) #1-18 ($1) #1-9 ($1) #2-9 ($1) #2-23 ($1) #1-18 ($1) Total Cost $65.5 $64.5 $65 $62.5 $63 $58.5 $59.5 $64 $59.5 $59.5 $59.5 $59 Cost score S c 75.86% 79.31% 77.58% 86.2% 84.48% 100% 96.55% 81.03% 96.55% 96.55% 96.55% 98.27% Space used Up to F Up to E Up to F Up to E Up to E Up to G Up to F Up to F Up to G Up to F Up to G Up to F Space score S s 66% 100% 66% 100% 100% 33% 66% 66% 33% 66% 33% 66% SDP 73.9% 83.4% 79.3% 89.0% 87.6% 86.6% 90.4% 78.0% 83.8% 90.4% 83.8% 91.8% Average SDP 81.4% 85.6% 87.5% 199 Group 1 (CG) Group 2 (PG) Group 3 (PSG) Utterance Type Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Proposal (strategic) 8 4 15 11 6 0 0 2 6 5 5 10 Proposals total (L/OP/CP) 6 2 10 9 14 12 21 12 32 16 27 29 Agreements 9 3 15 7 9 10 16 8 17 11 18 17 Total argumentative 10 0 1 9 17 9 6 8 20 6 9 18 Information request 21 5 37 29 6 5 9 5 16 8 17 43 Issues discussed 1 0 0 0 4 3 4 3 5 2 6 8 Definition: Total argumentative: Critique, Defend, Refine, Counter propose, Dissent Table A-9-3: Analysis of utterances used Group 1 (CG) Group 2 (PG) Group 3 (PSG) Utterances distribution Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 Sample 1 Sample 2 Sample 3 Sample 4 For strategic planning 68 5 20 8 2 0 0 0 0 0 0 0 For design resolution 26 5 149 57 93 49 57 44 50 43 63 117 Number of utterances used For solution optimization 28 15 64 27 7 10 9 6 49 13 32 50 For strategic planning 0.56 0.20 0.09 0.09 0.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 For design resolution 0.21 0.2 0.64 0.62 0.91 0.83 0.86 0.88 0.51 0.77 0.66 0.70 Ratio of utterances used For solution optimization 0.23 0.60 0.27 0.29 0.07 0.17 0.14 0.12 0.49 0.23 0.34 0.30 Table A-9-4: Analysis of utterances distribution 200 A-10 Statistical correlation between experiment measures Legend: Prop tot: total number of proposals exchanged IIO: Number of Issues / incompatibilities / options discussed IR: Number of Information requests exchanged Utt strat: Number of utterances exchanged in the strategy phase Utt reso: Number of utterances exchanged in the resolution phase Utt opti: Number of utterances exchanged in the optimization phase DSE: Design Space exploration Index (based on IIO) SDP: Score-based Design Performance Index (based on cost and space scores) Total argumentation: Number of critique, defend, refine, dissent utterances exchanged Prop strat: Total number of strategic proposals exchanged 201 First set of experiments: CG-PG.MTW Correlations: Treatment, Prop total, IIO, IR, Utt Strat, Utt reso, Utt optim, DS Treatment Proposal Total IIO IR Utterances Strategy Utterance resolution Utterance optimization DSE DP Total argumentation 0.771 Proposal Total 0.025 0.929 0.721 IIO 0.001 0.044 -0.654 -0.135 -0.569 IR 0.079 0.750 0.141 -0.644 -0.620 -0.389 0.260 Utterances Strategy 0.085 0.101 0.341 0.534 0.830 0.857 0.705 -0.194 -0.845 Utterance resolution 0.011 0.007 0.051 0.646 0.008 -0.720 -0.794 -0.793 0.041 0.334 -0.786 Utterance optimization 0.044 0.019 0.019 0.922 0.418 0.021 0.924 0.684 0.994 -0.620 -0.355 0.666 -0.764 DSE 0.001 0.061 0.000 0.101 0.388 0.071 0.027 0.385 0.514 0.245 -0.233 -0.661 0.494 -0.107 0.259 DP 0.347 0.192 0.559 0.579 0.074 0.213 0.800 0.536 0.498 0.374 0.629 -0.216 -0.050 0.441 -0.720 0.658 0.193 Total argumentation 0.210 0.362 0.094 0.608 0.906 0.274 0.044 0.076 0.648 -0.747 -0.376 -0.668 0.897 0.310 -0.319 0.205 -0.714 -0.303 -0.164 Strategic Proposal 0.033 0.359 0.070 0.003 0.455 0.441 0.626 0.047 0.466 0.699 Cell Contents: Pearson correlation, P-Value Table A-10-1: Pearson’s correlation index for CG and PG groups 202 Second Set of Experiments: PG-PSG.MTW Correlations: Experiment, Prop total, IIO, IR, Utt Strat, Utt reso, Utt optim, D Treatment Proposal Total IIO IR Utterances Strategy Utterance resolution Utterance optimization DSE DP Total argumentation 0.764 Proposal Total 0.027 0.658 0.859 IIO 0.076 0.006 0.618 0.727 0.899 IR 0.103 0.041 0.002 -0.378 -0.314 -0.174 -0.241 Utterances Strategy 0.356 0.449 0.680 0.565 -0.831 -0.881 -0.708 -0.497 0.434 Utterance resolution 0.011 0.004 0.049 0.211 0.283 0.831 0.877 0.700 0.498 -0.475 -0.999 Utterance optimization 0.011 0.004 0.053 0.210 0.235 0.000 0.445 0.676 0.931 0.859 -0.092 -0.445 0.440 DSE 0.269 0.065 0.001 0.006 0.828 0.269 0.276 0.210 0.160 0.194 0.402 0.093 0.048 -0.051 0.186 DP 0.617 0.705 0.644 0.324 0.827 0.911 0.904 0.660 0.490 0.588 0.871 0.943 0.051 -0.360 0.349 0.866 0.362 Total argumentation 0.217 0.125 0.005 0.000 0.905 0.381 0.397 0.005 0.379 0.705 0.606 0.737 0.767 0.207 -0.490 0.468 0.613 0.281 0.845 Strategic Proposal 0.051 0.111 0.037 0.026 0.622 0.218 0.243 0.106 0.500 0.008 Cell Contents: Pearson correlation, P-Value Table A-10-2: Pearson’s correlation index for PG and PSG groups 203 204 A-11 ANOVA Results Results for: CG-PG.MTW One-way ANOVA: Prop total versus Treatment Analysis of Variance for Prop tot Source DF SS MS F P Treatmen 1 120.1 120.1 8.82 0.025 Error 6 81.8 13.6 Total 7 201.9 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ------+---------+---------+---------+ 0 4 6.750 3.594 (---------*--------) 1 4 14.500 3.786 (--------*--------) ------+---------+---------+---------+ Pooled StDev = 3.691 5.0 10.0 15.0 20.0 205 One-way ANOVA: IIO versus Treatment Analysis of Variance for IIO Source DF SS MS F P Treatmen 1 55.13 55.13 37.80 0.001 Error 6 8.75 1.46 Total 7 63.88 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev --+---------+---------+---------+---- 0 4 1.000 1.414 (-----*-----) 1 4 6.250 0.957 (-----*-----) --+---------+---------+---------+---- Pooled StDev = 1.208 0.0 2.5 5.0 7.5 206 One-way ANOVA: DSE versus Treatment Analysis of Variance for DSE Source DF SS MS F P Treatmen 1 2646.3 2646.3 35.29 0.001 Error 6 449.9 75.0 Total 7 3096.2 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ----+---------+---------+---------+-- 0 4 5.125 10.250 (-----*------) 1 4 41.500 6.702 (------*------) ----+---------+---------+---------+-- Pooled StDev = 8.660 0 16 32 48 207 One-way ANOVA: Prop Strat versus Treatment Analysis of Variance for Prop Str Source DF SS MS F P Treatmen 1 112.5 112.5 7.58 0.033 Error 6 89.0 14.8 Total 7 201.5 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ------+---------+---------+---------+ 0 4 9.500 4.655 (--------*--------) 1 4 2.000 2.828 (--------*--------) ------+---------+---------+---------+ Pooled StDev = 3.851 0.0 5.0 10.0 15.0 208 One-way ANOVA: Utt reso versus Treatment Analysis of Variance for Utt reso Source DF SS MS F P Treatmen 1 0.4095 0.4095 13.33 0.011 Error 6 0.1843 0.0307 Total 7 0.5938 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev --+---------+---------+---------+---- 0 4 0.4175 0.2455 (--------*-------) 1 4 0.8700 0.0337 (--------*-------) --+---------+---------+---------+---- Pooled StDev = 0.1752 0.25 0.50 0.75 1.00 209 One-way ANOVA: Utt optim versus Treatment Analysis of Variance for Utt opti Source DF SS MS F P Treatmen 1 0.0990 0.0990 6.45 0.044 Error 6 0.0922 0.0154 Total 7 0.1912 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev --+---------+---------+---------+---- 0 4 0.3475 0.1702 (---------*---------) 1 4 0.1250 0.0420 (---------*---------) --+---------+---------+---------+---- Pooled StDev = 0.1239 0.00 0.15 0.30 0.45 210 Results for: PG-PSG.MTW One-way ANOVA: Prop total versus Treatment Analysis of Variance for Prop tot Source DF SS MS F P Treatmen 1 264.5 264.5 8.40 0.027 Error 6 189.0 31.5 Total 7 453.5 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ----------+---------+---------+------ 0 4 14.500 3.786 (---------*---------) 1 4 26.000 6.976 (---------*---------) ----------+---------+---------+------ Pooled StDev = 5.612 14.0 21.0 28.0 211 One-way ANOVA: Prop Strat versus Treatment Analysis of Variance for Prop Str Source DF SS MS F P Treatmen 1 40.50 40.50 5.93 0.051 Error 6 41.00 6.83 Total 7 81.50 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ----+---------+---------+---------+-- 0 4 2.000 2.828 (----------*---------) 1 4 6.500 2.380 (----------*---------) ----+---------+---------+---------+-- Pooled StDev = 2.614 0.0 3.0 6.0 9.0 212 One-way ANOVA: Agreemt versus Treatment Analysis of Variance for Agreemt Source DF SS MS F P Treatmen 1 60.50 60.50 6.79 0.040 Error 6 53.50 8.92 Total 7 114.00 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ----------+---------+---------+------ 0 4 10.750 3.594 (----------*---------) 1 4 16.250 2.217 (---------*----------) ----------+---------+---------+------ Pooled StDev = 2.986 10.5 14.0 17.5 213 One-way ANOVA: Utt reso versus Treatment Analysis of Variance for Utt reso Source DF SS MS F P Treatmen 1 0.08820 0.08820 13.36 0.011 Error 6 0.03960 0.00660 Total 7 0.12780 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ----+---------+---------+---------+-- 0 4 0.87000 0.03367 (--------*-------) 1 4 0.66000 0.10985 (-------*-------) ----+---------+---------+---------+-- Pooled StDev = 0.08124 0.60 0.72 0.84 0.96 214 One-way ANOVA: Utt optim versus Treatment Analysis of Variance for Utt opti Source DF SS MS F P Treatmen 1 0.09245 0.09245 13.37 0.011 Error 6 0.04150 0.00692 Total 7 0.13395 Individual 95% CIs For Mean Based on Pooled StDev Level N Mean StDev ---------+---------+---------+------- 0 4 0.12500 0.04203 (-------*--------) 1 4 0.34000 0.10985 (-------*--------) ---------+---------+---------+------- Pooled StDev = 0.08317 0.12 0.24 0.36 UMI Number: 3237771 3237771 2007 UMI Microform Copyright 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, MI 48106-1346 by ProQuest Information and Learning Company.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Efficient media access and routing in wireless and delay tolerant networks

PDF

The design and synthesis of concurrent asynchronous systems.

PDF

Internet security and quality-of-service provision via machine-learning theory

PDF

MUNet: multicasting protocol in unidirectional ad-hoc networks

PDF

The problem of safety of steel structures subjected to seismic loading

PDF

The importance of using domain knowledge in solving information distillation problems

PDF

A work structure based approach to collaborative engineering design

PDF

Protocol evaluation in the context of dynamic topologies

PDF

Probabilistic analysis of power dissipation in VLSI systems

PDF

Elevated inflammation in late life: predictors and outcomes

PDF

Spatial distribution of neuroendocrine motoneuron pools in the hypothalmic paraventricular nucleus

PDF

Three antibody-based immunotherapeutic modalities for malignancies

PDF

Initiation mechanism of estrogen neuroprotection pathway

PDF

The effects of marketing communication on consumers' choice behavior: the case of pharmaceutical industry

PDF

Colorectal cancer: genomic variations in insulin-like growth factor-1 and -2

PDF

Dual devotions: African American clergywomen and work-family dilemmas

PDF

A socio-technical approach to support collaborative engineering design

PDF

Semantic heterogeneity resolution in federated databases by meta-data implantation and stepwise evolution

PDF

The project life cycle and budgeting functions: planning, control, and motivation

PDF

On the spin-up and spin-down of a contained fluid

Asset Metadata

Creator Geslin, Mathieu M. (author)

Core Title An argumentation-based approach to negotiation in collaborative engineering design

School Graduate School

Degree Doctor of Philosophy

Degree Program Mechanical Engineering

Degree Conferral Date 2006-08

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)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c17-124681

Unique identifier UC11351146

Identifier 3237771.pdf (filename),usctheses-c17-124681 (legacy record id)

Legacy Identifier 3237771.pdf

Dmrecord 124681

Document Type Dissertation

Rights Geslin, Mathieu M.

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