Conflict Cause Identification in Web-based concurrent engineering design

MISSING IMAGE

Material Information

Title:
Conflict Cause Identification in Web-based concurrent engineering design
Physical Description:
xii, 187 leaves : ill. ; 29 cm.
Language:
English
Creator:
Jiang, Tianhong, 1969-
Publication Date:

Subjects

Subjects / Keywords:
Aerospace Engineering, Mechanics, and Engineering Science thesis, Ph. D   ( lcsh )
Dissertations, Academic -- Aerospace Engineering, Mechanics, and Engineering Science -- UF   ( lcsh )
Genre:
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )

Notes

Thesis:
Thesis (Ph. D.)--University of Florida, 2000.
Bibliography:
Includes bibliographical references (leaves 182-186).
Additional Physical Form:
Also available online.
Statement of Responsibility:
by Tianhong Jiang.
General Note:
Printout.
General Note:
Vita.

Record Information

Source Institution:
University of Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 022939959
oclc - 45112170
System ID:
AA00025730:00001

Full Text










CONFLICT CAUSE IDENTIFICATION IN
WEB-BASED CONCURRENT ENGINEERING DESIGN














By

TIANHONG JIANG













A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2000













ACKNOWLEDEGMENTS

I am grateful to the chairman of my committee, Dr. Gale E. Nevill, Jr., who

introduced this area of research to me. I would also like to thank him for his guidance, both professionally and personally, and also for his tremendous encouragement, advice and support during my doctoral work.

I would also like to thank the other members in my committee, Dr. Raphael T.

Haftka, Dr. Andrew J. Kurdila, Dr. Paul Fishwick, and Dr. Joseph Duffy for their valued advice, expertise, and support which helped in the development of this research project.

I would also like to thank Dr. Chang-Tsan Sun for his support and guidance during my first two years in this department and his continued friendship.

I would also like to thank Dr. Douglas D. Dankel and Dr. Bhavani V. Sankar for their valued advice in this research project.

I thank my colleague Ruiqiang Zhuang for his cooperation and support in this project. I would also like to thank my fellow graduate students Yunfei Feng, Weijian Wang, Dazhi Yu for their support in the experiments in this project.

Last, but not least, I would like to thank my wife, Yiting Li, for her love, support and understanding during the most trying years of my life and to my family in Pennsylvania, Minnesota, and China for their love and support.






ii













TABLE OF CONTENTS
page


ACKN O W LED eGM EN TS .................................................................................................

LIST OF TABLES ............................................................................................................. vi

LIST OF FIGURES .......................................................................................................... vii

AB STRA CT ...................................................................................................................... xii

1. INTRODU CTION ........................................................................................................... I

1.1 Traditional D esign vs. Concurrent D esign ............................................................... 1
1.2 Conflict in D esign .................................................................................................... 4
1.2.1 Existence of Conflict in Engineering D esign .................................................. 4
1.2.2 D efinition of Conflict ...................................................................................... 4
1.2.3 Conflict in Traditional D esign ........................................................................ 5
1.2.4 Conflict in Concurrent Design ........................................................................ 5
1.2.5 Conflict Dom ains and Sources ........................................................................ 5
1.2.6 Cooperation of Hum an and Software A gents ................................................. 6

2. REVIEW OF RELATED W ORK ................................................................................... 8

2.1 Inform ation Flow M anagem ent ............................................................................... 8
2.2 D esign Process M anagem ent ................................................................................... 8
2.3 Conflict M anagem ent ............................................................................................... 9
2.3.1 Conflict Classification .................................................................................... 9
2.3.2 Conflict Detection and Avoidance ................................................................ 10
2.3.3 Conflict Resolution ....................................................................................... 11
2.4 Sum m ary ................................................................................................................ 14

3. TH E N ATURE OF CON FLICTS .................................................................................. 15

3.1 Conflict D efinition ................................................................................................. 15
3.2 Conflict D etection .................................................................................................. 16
3.3 Conflict Classification ........................................................................................... 16
3.3.1 Dim ensions of Conflict Classes .................................................................... 17
3.3.2 A dditional Characteristics of Conflicts ......................................................... 19
3.4 Conflict Class Structure ......................................................................................... 23


iii








3.4.1 Requirement Types ....................................................................................... 25

3.4.2 Fundamental Causes ..................................................................................... 29
3.5 Conflict Cause Identification ................................................................................. 41

4. CONFLICT CAUSE IDENTIFICATION ..................................................................... 42

4.1 Introduction: Identification of the Conflict Causes ............................................... 42
4. 1.1 Review of Previous W ork ............................................................................. 42
4.1.2 The Basic Approach Taken in This W ork .................................................... 43
4.1.3 Conflict Cause Identification M odel ............................................................. 47
4.2 Conflict-related Agent Behavior M odel ................................................................ 50
4.2.1 A rule-oriented Agent Behavior M odel (ABM ) ........................................... 50
4.2.2 Description of Conflict-related Agent Behavior M odel ............................... 51
4.3 Value Indicator Patterns ......................................................................................... 53
4.3.1 Pattern Recognition Approach ...................................................................... 53
4.3.2 Basic Value Pattern Characteristics .............................................................. 54
4.3.3 Real W orld Conflict-related Value Indicator Patterns .................................. 62
4.4 Design Process Graph in the Forward Design Process .......................................... 78
4.4.1 Structure of the Design Process Graph ......................................................... 78
4.4.2 Use of the Design Process Graph in the Forward Design Process ................ 83
4.4.3 General Forward Design Process Results ................................................... 111
4.5 Inverse Process of Conflict Cause Identification ................................................. 113
4.5.1 Overview of the Conflict Cause Identification Process .............................. 113
4.5.2 Use of the Inverse Identification Process .................................................... 115
4.5.3 Summary ..................................................................................................... 117

5. SYSTEM IM PLEM ENTATION ................................................................................. 119

5.1 The C'I Software Agent ....................................................................................... 119
5. 1.1 M onitor the On-going Design Process ........................................................ 120
5.1.2 Calculating the VIP ..................................................................................... 121
5.1.3 Identify the Conflict Cause ......................................................................... 128
5.1.4 Notify the Design Agents ............................................................................ 129
5.2 Plane W orld System ............................................................................................. 130
5.2.1 Description of the 2-D Plane Model in the Plane World System ............... 130
5.2.2 Architecture of the Plane World Design and C'I System ........................... 137

6. EXPERIM ENTS AND RESULTS .............................................................................. 144

6.1 How W ere the Experiments Conducted? ............................................................. 144
6.2 Experimental Results ........................................................................................... 145
6.3 Summary of Experimental Results ...................................................................... 175

7. DISCUSSION AND CONCLUSIONS ....................................................................... 176


iv








G LO SSA RY .................................................................................................................... 179

LIST O F REFEREN CES ................................................................................................. 182

BIO GR A PH ICA L SKETCH ........................................................................................... 187













LIST OF TABLES

Table page

3-1: Local goals and related module attributes .................................................................. 38

3-2: Local goals and related module weight ...................................................................... 38

4- 1: Abbreviations used to identify Value Indicator Pattern ............................................. 57

4-2: Abbreviation of conflict classes ................................................................................. 62

4-3: Elements in the DPG .................................................................................................. 79

4-5: M apping of conflict classes which could produce various VIPs .............................. 114

5-1: Attributes of plane and modules in the 2-D plane .................................................... 132

5-2: M odule fimctions in the 2-D plane ........................................................................... 133

5-3: Relationships in the 2-D plane ................................................................................. 135

5-4: Requirements in Plane W orld ................................................................................... 137

6-1: Local goals and related module weight .................................................................... 155

6-2: Results of additional experiments ............................................................................ 173















vi













LIST OF FIGURES

I 1: Traditional design ......................................................................................................... 2

1-2: Concurrent Engineering Design ................................................................................... 3

3-1: Dim ensions in conflict class ....................................................................................... 19

3-2: An example involving (a) explicit logical inconsistency (b) implicit logical
inconsistency .............................................................................................................. 21

3-2--Continued ................................................................................................................... 22

3-3: Conflict class structure ............................................................................................... 24

3-4: An example of functional-influenced requirem ent ..................................................... 27

3-5: Two cases of different term inology ............................................................................ 29

3-6: Different point of view on the wing configuration in aircraft design ......................... 33

3-7: An example that different initial ranges lead to different solutions ........................... 34

3-8: An exam ple of positive feedback loop in tank design ................................................ 40

4- 1: Diagnosis of blood diseases in M YCIN expert system .............................................. 46

4-2: The C'I model in (a) design process (b) inverse identification process .................... 48

4-2--Continued ................................................................................................................... 49

4-3: Various monotonic value patterns .............................................................................. 58

4-4: Various oscillatory value patterns .............................................................................. 59

4-5: Various chaotic value patterns .................................................................................... 60

4-6: Various segmental value patterns ............................................................................... 61



vii








4-7: Mapping from the conflict class "different terminology, global requirement" to
associated VIPs............................................................................. 63

4-8: An example of VIPs expected to result from the conflict class "different terminology,
global requirement". ....................................................................... 64

4-9: Mapping from the conflict class "different perception, interface requirement" to
associated VIPs............................................................................. 67

4-10: An example of VIPs expected to result from the conflict class "different point of
view, interface-compatibility requirement". ............................................. 68

4-11: Mapping from the conflict class "conflicting local goal, global requirement" to the
associated VIPs............................................................................. 69

4-12: An example of the VIP expected to result from the conflict class "conflicting local
goals, global requirement"................................................................. 70

4-13: Mapping from the conflict class "conflicting local goal, functional-influenced
requirement (3 or more agents involved)" to associated VIPs ........................ 71

4-14: An example of a functional-influence requirement .................................... 72

4-15: An example of VIPs expected to result from the conflict class "conflicting local
goal, fuinctional-influenced requirement (3 or more agents involved)"............... 74

4-16: Mapping from the conflict class "inadequate communication, functional-influenced
requirement" to the associated VIPs...................................................... 75

4-17: An example of VIPs expected to result from the conflict class "Inadequate
communication, functional-influenced requirement". .................................. 77

4-18: Model of the interaction between agents in CE design ................................ 81

4-19: Results from the design loop............................................................. 82

4-20: The DPG of conflict class Cii in the forward design process ......................... 84

4-2 1: DPG of the conflicts class "different terminology, global requirement".............86

4-22: DPG of the conflict class "different terminology, interface-compatibility
requirement................................................................................ 88

4-23: DPG of the conflict class "different terminology, functional-influenced
requirement................................................................................ 89


viii








4-24: DPG of the conflict class "different perception, global requirement ........................ 91

4-25: DPG of the conflict class "different perception, interface-compatibility
requirem ent .. .............................................................................................................. 93

4-26: DPG of the conflict class "different perception, functional-influenced requirement"
with (a) two agents involved (b) three or more agents involved ............................... 96

4-26--C continued ................................................................................................................. 97

4-27: DPG of the conflict class "conflicting local goals, global requirement .................... 99

4-28: DPG of the conflict class "conflicting local goals, interface-compatibility
requirem ent .. ............................................................................................................ 102

4-29: DPG of the conflict class "conflicting local goals, functional-influenced
requirement (3 or more agents involved) .. ............................................................... 104

4-30: DPG of the conflict class "inadequate communication, global requirement .......... 106

4-3 1: DPG of the conflict class "inadequate communication, interface-compatibility
requirem ent .. ............................................................................................................ 108

4-32: DPG of the conflict class "inadequate communication, functional-influenced
requirem ent .. ............................................................................................................ 110

4-33: Mapping from "monotonic, divergent/global requirement"to the associated conflict
causes) (i.e. conflicting local goals) ....................................................................... 116

4-34: Mapping from "mouotonic, slowly convergent / functional-influenced requirement
(two agents involved)" to the associated conflict causes (i.e. conflicting local goals,
or different perception) ............................................................................................ 118

5-1: The C 'l processes ..................................................................................................... 120

5-2: An item in the RVHV table in database ................................................................... 121

5-3: Decision tree for determining the path shape ........................................................... 122

5-4: An example with pulses in history values of the requirement-related variable ........ 123 5-5: Decision tree for determining the segmental shape .................................................. 124

5-6: Decision tree for determining the monotonic shape ................................................. 125



ix








5-7: An example that the period of oscillatory path varies significantly ......................... 126

5-8: Decision tree for determining the oscillatory shape ................................................. 127

5-9: Predicted value ......................................................................................................... 127

5-10: Decision tree for determining the destination of a requirement-related variable ... 129 5-11: M odules in the 2-13 cargo plane ............................................................................. 131

5-12: Human design agents and software agents involved in the Plane World system ... 139 5-13: A design window in Plane World system ............................................................... 140

5-14: Distributed structure of the Plane World system .................................................... 141

6-1: Experiment design process in Plane World experiments ......................................... 146

6-2: Propulsion and wing-structure modules in the 2-D plane ........................................ 148

6-3: History values of the requirement-related variable DLWPBNHSpacing ................. 149

6-4: Conflict(s) Predicted window of Experiment 1 ........................................................ 150

6-5: Different preferred designs of the bolt/nut-holes (i.e. spacing) on interface between
the propulsion and wing-structure modules ............................................................. 154

6-6: History values of the requirement-related variable Weight of the plane .................. 156

6-7: Conflict(s) Predicted window of Experiment 2 ........................................................ 157

6-8: Positive feedback loop in the Plane World design experiment ................................ 160

6-9: An example of conflicting local goals/different perception between the tail-structure
and control agents regarding the propulsion modules' locations ............................. 163

6-10: History values of the requirement-related variable DXRightProp ......................... 164

6-11: Confli6t(s) Predicted window in Experiment 3 ...................................................... 165

6-12: Interaction between the propulsion modules and tail-structure modules in the design
process ...................................................................................................................... 168

6-13: History values of the requirement-related variable DXLeftProp ........................... 170



x









6-14: Conflict(s) Predicted window in Experiment 4 ...................................................... 171




























































xi














Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy CONFLICT CAUSE IDENTIFICATION IN WEB-BASED CONCURRENT ENGINEERING DESIGN By

Tianhong Jiang

May 2000


Chairman: Dr. Gale E. Nevill, Jr. Major Department: Aerospace Engineering, Mechanics and Engineering Science

This dissertation explores models and methods for Conflict Cause Identification (C'I) in web-based concurrent engineering (CE) design. Conflict classes and causes in CE design are identified, defined and cataloged. C'I methods are studied, organized and tested. The test-bed for this work is the Plane World aircraft design simulation program, created to support exploration of Conflict Cause Identification in a distributed, multiagent CE design environment.















xii














CHAPTER I
INTRODUCTION


1. 1 Traditional Design vs. Concurrent Design


Engineering design is a highly complex activity. Traditionally, design activity is divided into a sequence of sub-tasks and allocated to multiple designers or subcontractors (Harrington 1995). For example, the life cycle of a product can be divided into three stages: product design, manufacture, and operation/maintenance. The traditional design approach handles these stages in sequence (Figure I 1). In each stage, different design criteria are applied; i.e. performance is the critical factor considered in the product design phase while manufactureability and cost are the main concerns in manufacturing.

While relatively simple to manage, the traditional approach has some serious

drawbacks (Harrington 1996). Designers involved in various stages make their decisions based on their local goals with little concern for the other stages. This commonly causes conflicts I of design between the early and later stages and results in sub-optimal results. Re-work and Compromise models are commonly introduced to resolve the conflicts. Thtge work to some extent but are rather costly and inefficient (Harrington 1995).






1 The concept of conflict will be formally defined in Chapter 3.


1






2


Moreover, the traditional design approach usually requires designers to meet often in conference to resolve differences. This becomes impractical when the designers involved in the project are remote from one another. This situation is increasingly common in web-based design.



Design Agent I Product
Design Re-work & Compromise Design Agent 2 M re
anufactu =J




Re-work & Compromise Design Agent 3 Operation Maintenance




Figure 1-1: Traditional design



The concept of concurrent engineering (CE) has evolved to improve the design process. Concurrent engineering is a "systematic approach to creating a product design that simultaneously considers all elements of the product life cycle from conception through disposal" (Hoffinan 1997). In a CE process, all the agents in a design team work





3


together in the early design stage and important decisions are made considering the project's entire life cycle, rather than its individual design stages (Figure 1-2). This offers the potential for much more nearly optimal results than does the traditional sequential approach. However, to fulfill its promises, some serious problems in CE need to be resolved. One major problem involves explicitly dealing with a greatly increased number of disagreements and conflicts (Harrington 1996, Hoffman 1997). This problem becomes further exacerbated when design agents are located remote from each other, as is common in web-based design. Thus, it becomes important to ask how can potential conflicts be detected and avoided? When a conflict is encountered, how can it be resolved without seriously affecting the performance of the CE process? How much contribution can software agents make to dealing with conflicts? These questions are among the most critical issues actively studied currently in CE (Lander 1997a).


Design
Agent I

Product
Design




Design Design
Agent 2 Agent 3
Manufa n
cture Operation/
I mt
Laan e



Figure 1-2: Concurrent Engineering Design





4

1.2 Conflict in Desi


1.2.1 Existence of Conflict in Engineering Desi

Most literature assumes that conflict exists commonly in the engineering design (Klein 1990, Lander 1997a). However, only a few empirical studies of real world conflict between designers in collaborative concurrent design have been found. For example, Fleischer did some empirical studies in a case of conflict between the design engineers and the manufacture engineers because of different design considerations (Fleischer 1997). In his study, the design engineer's primarily concern is product performance, while the manufacturing engineer cares more about ease of manufacturing with low cost. The different preference and priority of the two types of engineers lead to conflicts in the design process.

1.2.2 Definition of Conflict

Conflicts have been defined in a number of ways. For example, conflict can be defined as "disagreement between two or more viewpoints on some decision or values proposed in a design" (Pruitt 198 1). Different opinions on design issues among agents commonly exist in the design process. The iterative exploration method (Easterbrook 1993), which serves as the heart of nearly all design, is a process for compromise and resolving disagreement. Often, it works reasonably well and the different designs converge into a compromise solution. However, at times resolution of disagreements is non-convergent, causing the design process to be blocked. Therefore, it becomes necessary to deal explicitly with the conflict.

The formal conflict definition used in this work will be discussed in Chapter 3.








1.2.3 Conflict in Traditional Design

Conflicts certainly exist in traditional design. However, in the traditional

approach, agents often have poor communication and seldom discuss conflicts before major commitments have been made (Harrington 1996). Rather, the agents make their decisions based on their own local goals, resources, and situation. The conflicts are there, but implicit and hidden. When conflicts are finally recognized, it is often late in the design process, when it is difficult and expensive to resolve them. Agents have either to backtrack in the design process or to live with the flaw, neither of which is a good solution.

1.2.4 Conflict in Concurrent Design

In the CE environment, all the agents are involved in a project concurrently, and seek to communicate their experience, knowledge, priorities, and criteria to all other participants (Owen 1985). Conflict thus becomes much more explicit. All members involved in a design effort are expected to join in the discussion and negotiation over disagreements encountered. In the CE process, conflict management becomes a more complex and crucial task. There are many types of conflicts with various causes and operation mechanisms. Further, conflict management expertise commonly varies from one type of conflict to another (Landers 1997a). Thus, it is important to identify conflict domains and sources.

1.2.5 Conflict Domains and Sources

Generally, conflicts may be classified as a belonging in one of the two domains (Matta 1996),





6


1. Product Domain, the domain of the product being designed,

2. Process Control Domain, the domain of control and organization of design activities.

Conflicts in the process control domain are complicated, poorly understood, and rarely studied in previous research (Matta 1996). In this study, we focus on the product domain conflicts.

The primary sources of product domain conflicts are:

1. Misunderstandings caused by the designers' different beliefs, viewpoints,

assumptions, terminology, tools and criteria for evaluating design objects

(Ramesh 1994, Lander 1997a),

2. Conflicting opinions over the conditions and consequences under which the

decisions of product design are made (Easterbrook 1993, Sycara 1991).

Meanwhile, process control conflicts may arise from the following causes,

1. Inconsistency in strategies and methods applied by design agents (Easterbrook

1993),

2. Different opinions on the allocation of tasks to each design agent (Easterbrook

1993),

3. Divergence of responsibilities and failure of cooperation among agents (Matta

1996).

The process control conflicts will not be considered further in this work.

1.2.6 Coopeiation of Human and Software Aget

Humans play the principal role in most engineering design today and are likely to continue to do so far into the future. However, there are rarely enough resources to





7

provide sufficient human Conflict Resolution (CR) expertise. Thus, the most valuable role for a software CR agent is believed to be supporting and augmenting the efforts of human design agents (Werkman 1991, Hu 1996). Therefore, in this work, focus is on developing a software agent, which can facilitate conflict avoidance and resolution by human agents. It is assumed that human agents are cooperative in the design process. That is, agents are assumed to be trying to cooperate.
















CHAPTER 2
REVIEW OF RELATED WORK

Current research in CE design systems is commonly divided into three categories: information flow, concurrent design process, and conflict management. Here the first two are discussed only briefly and the third is emphasized.

2.1 Information Flow Management


Standards are developed to coordinate the data and communication in each stage of information flow. For example, Standard for the Exchange of Product (STEP) is proposed by Lin (Lin 1996) for enhancing computer interpretation of information on products. The CORBA approach (Mowbray 1995) and Knowledge Query & Manipulation Language (Finin 1994) are used to improve communication and interoperability among design agents.

2.2 Design Process Management


In CE processes, coordinating methods and expertise such as Computational

Market Model (Wellman 1995) and Tracking Pareto Optimality (Petrie 1995) are applied to ensure that multiple agents coordinate their design activities to produce quality designs.





8





9

2.3 Conflict Management


Essential to performance of CE design processes, conflict management is clearly an important topic in current CE research. A number of approaches and techniques have been studied to detect, avoid and resolve CE conflicts efficiently.

2.3.1 Conflict Classification

It has been found that the methods used to detect and resolve one kind of conflict often will not work well for another one. Therefore, a common first step in conflict management is to build a taxonomy of conflict classes (Lander 1997a).

In Klein's cooperative design system (Klein 1991), a taxonomy of conflict classes associated with general advice suitable for resolving conflicts in these classes is proposed. Applying his conflict resolution (CR) expertise to local area network (LAN) design, Klein creates a taxonomy of four conflict types with a total of 115 conflict classes (Klein 1990, Klein 1991). Klein's taxonomy of conflict classes covers a broad range of CR problems. However, Klein does not clearly distinguish a Conflict from a Problem (or Difficult Issue) in the design. Conflict is the disagreement between two or more agents due to different design approach or parameter set-up etc. In contrast, Problem means an agent's difficulty in achieving the design goals. Also, Klein does not clearly distinguish between disagreements that are being successfully resolved by the basic design process and disagreements in which the basic design process is failing and thus is blocked. Furthermore, many of the classes are identified specifically to solve conflicts in LAN design and thus cannot be part of a generic CR system.





10

In contrast to Klein's flat structural organization of classes, which gives little information about the interaction between different classes, Matta builds a topology of conflict classes in a hierarchical structure (Matta 1996). In Matta's viewpoint, conflict is mainly handled as a disagreement between some participants rather than as a problem involving design and requirement. Two generic categories of conflicts are proposed by Matta: strategies and propositions. These two categories are then refined from very generic to very specific classes. In defining the hierarchy of conflict classes, the causes of various conflicts and their distinctive behavior are revealed and highlighted.

2.3.2 Conflict Detection and Avoidance

Probably the best way to manage a conflict is to avoid it before it happens (Lander 1997a). Since the majority of conflicts in CE systems are caused by misunderstanding and incomplete knowledge about the project design among agents, an informationsharing strategy is widely used in conflict avoidance. In this strategy, information such as local constraints, goals, and priorities are shared as much as possible among the agents involved in the design project (Lander 1997a).

In application, the detailed process of sharing information among agents affects greatly the performance of CR and the efficiency of design systems. Lander introduces the concept of meta-information, which describes some abstraction of an agent's solution space rather than its details (Lander 1997b). A reusable-agent system, a multi-agent computational system that uses a sharing meta-information mechanism and encodes some CR expertise, is applied to improve the efficiency of conflict avoidance. When required,





11

the reusable agent can dynamically apply appropriate CR expertise to diverse applications to avoid conflicts.

Some approaches based on "personal" information sharing have also been studied. Ramesh suggests to share part of private information such as terminology used by each participant to avoid the conflict (Ramesh 1994). Rollinger works on improving communication among agents to minimize knowledge inconsistency and conflict (Rollinger 1996).

2.3.3 Conflict Resolution

Not all conflicts can be avoided in CE design processes. When a conflict occurs, appropriate conflict resolution (CR) expertise must be applied to resolve it efficiently. Early Psychology and Social Science Approach

Early work on conflict resolution focuses on conflict in group interaction and human participants' behavior. Knowledge and expertise from artificial intelligence and social sciences, especially psychology, are heavily utilized. For example, Fedrizzi proposes an interactive multi-user group decision support system (GDSS) using fuzzy logic and linguistic knowledge (Fedrizzi 1988). A limitation of this approach is that it focuses on some very specific social or psychological issues rather than generic CR strategies and methods.

Computational Model Approach

Computational models, which encode the CR expertise by using mathematical

formalism, can be introduced to create a software agent to detect and resolve the conflicts in CE design process.





12

One of the early approaches to computational CR methods is the DevelopmentTime CR approach. Like compiling programs in software development, this approach attempts to resolve all potential conflicts by thorough discussion in the early stage before actually running the design process. A rule-based expert system is often used to coordinate the CR in multi-agent design. The compiling process includes verifying completeness and consistency of the expert system (Suwa 1982, Benzem 1987).

The Development-Time CR approach is static and impractical since it is virtually impossible to anticipate all the conflicts early in a design process. When new conflicts are encountered, the re-compiling process becomes fairly time-consuming. To overcome its shortcomings, some Running-Time CR approaches are later introduced to allow the conflict to be assessed when the system runs and resolved by tracking back the design process or relaxing some constraints (Feldman 1985). These approaches incorporate limited CR expertise. The CR expertise is represented by restrictive mathematical formalisms, which is one of the main disadvantages of such approaches.

To improve the Running-Time approach, Klein introduces a taxonomy of conflict classes and does some substantial research work on generic CR expertise (Klein 1990, Klein 199 1). In his Cooperative Design System, Klein builds a taxonomy of conflict classes. Associated expertise is developed to resolve both generic conflicts and conflict in a specific domain such as Solar Home design and Local Area Network (LAN) design. In Klein's system, a hierarchy of conflict classes is built, in which each conflict class inherits the attributes from its parent class and has more domain-specific features associated with more specific CR expertise. When a conflict is encountered, the design agent, which is a software agent, will determine the type of conflict and the appropriate





13


CR method from the very generic to the very specific to finally resolve the conflict. While the model works well in LAN design, many of the CR methods proposed are too specific to the LAN design and have limited use as generic CR guidelines.

Recently, Sobieski and Haftka introduce response surfaces, a low-order

polynomial, and neural networks to represent disciplinary response and objectives to an overall system designer, and facilitate conflict resolution (Sobieski 1996). These response surface and neural network methods have been applied to conflict resolution in design studies of supersonic transports (Balabonov 1996, Giunta 1996). Negotiation Approach

Rather than depending on the software agent to completely handle the conflict resolution, some suggest using negotiation between human agents with aid from some kind of Al system to resolve the conflicts and reach consensus in the design process. Matta suggests defining a library of generic components to guide CR modeling in CE design systems (Matta 1996). These components are arranged in a hierarchical structure, from the very generic types to the domain-specific ones. Meanwhile, various negotiation methods such as locating a consensus and introducing a third party are studied and encoded into the library. The negotiation approach is also applied by Findler in coordinating multiple agents in a Distributed Artificial Intelligence (DAI) system, which is a collection of geographically distributed intelligent decision-making agents with limited shared resources (Findler 1995). DAI based negotiation is also studied by Workman in the Designer Fabricator Interpreter (DFI) system that is developed to foster interaction and improve communication among agents from diverse background such as





14

preliminary designers, engineers and fabricators in order to solve conflicts efficiently (Werkman 1991).

2.4 Summary


In previous study, much work has been done in conflict classification, avoidance and resolution. However, there are some topics that have not been explored in depth yet. For example, how to separate the conflict from the difficult problem in design? How to identify the conflict causes in a web-based CE design environment? These questions will be studied in this work. In the next chapter, we will first explore the nature of conflicts.
















CHAPTER 3
THE NATURE OF CONFLICTS


3.1 Conflict Definition


Pruitt (Pruitt 198 1) and Harrington (Harrington 1995) define a conflict as

disagreement between two or more viewpoints on some decision or values proposed in a design. These authors distinguish conflict from the internal design problem inside each design agent. However, disagreement does not always lead to conflict. In routine design processes, the iterative exploration method, i.e. negotiation, is commonly used to find alternatives that are accepted by all parties (Easterbrook 1993). In the present work, conflict is considered as an exception to the normal routine design, where the disagreement resolution is non-convergent, causing the design process to be blocked.

Also, requirements play an important role in the existence of conflict. Without

some related requirement, no conflict can exist; even thought agents disagree on a design issue. For example, two automobile design agents, one in charge of exterior and another in charge of interior have different opinions on the color selection. The exterior design agent prefers-black, while the interior agent likes red. A conflict emerges only if there is a requirement of compatibility of interior and exterior colors. Otherwise, the conflict simply does not exist.




15





16


Based on the above insights, a conflict is defined here as follows: A conflict is a disagreement, between two or more agents involved in achieving some requirement, which is not being resolved satisfactorily by the basic design process.

3.2 Conflict Detection


It has been suggested that the best way to handle a conflict is to detect and avoid it (Lander 1997a). Various methods have been studied in previous research. For example, Lander proposed a sharing meta-information strategy (Lander 1997a).

R. Zhuang developed a computational model, which uses public information such as the design parameter values to detect the conflicts and problems in design (Zhuang 1999).

Conflict detection is not the focus of this study. Rather, Zhuang's model will be used to detect conflicts in design processes and provide input to the software Conflict Cause Identification (C'I) agent developed in this study. Since Zhuang's model cannot distinguish conflicts from problems, a computational model based on Value Indicator Patterns (VIP) and requirement types is developed and used in the C2 I agent to separate conflicts from problems in design processes. The details of the computational model and the C'I agent will be discussed in Chapter 4 and 5.

3.3 Conflict Classification


Previous studies show that conflicts vary from each other in fundamental causes and behaviors (Klein 1991). Conflict resolution methods tend to be appropriate for specific kinds of conflicts. Often, one method used to resolve one kind of conflict does





17


not work well for another one. Thus, it is desirable to group the conflicts in different categories, which are called Classes in this study.

3.3.1 Dimensions of Conflict Classes

As mentioned in Chapter 1, a conflict may generally be considered as belonging to one of the two domains, i.e. design product domain and process control domain (Matta 1996). Because the process control domain conflicts are complicated and little understood (Matta 1996), only the design product domain conflicts are studied in this work.

A design product conflict (simply called conflict hereafter) may be described along two dimensions: requirement type and fundamental cause (Figure 3-1).

1. Requirement type: Requirement and conflict are inseparable in engineering

design. The conflict will not exist if there is no related requirement. Also,

interactive relations and requirement type play an important role in the

conflict characteristic and behavior (Lander 1997a). Studying the various requirement types should help the design agent to understand the conflict

behavior and apply appropriate conflict resolution methods to a specific conflict-In this study, we classify the requirements into three types as

following:

1. 1 Aggregated requirement,

1.2 Interface related requirement,

1.3 Functional influenced requirement.





I Detailed definition of these requirement types will be given in Section 3.4.





18

2. Fundamental cause: Previous studies indicate that conflicts may occur for

various reasons, such as misunderstanding in communication, local-goal

incompatibility (Rollinger 1996), and different criteria for evaluating

alternative designs (Lander 1997b). Finding the conflict causes is the key to

conflict resolution methods. Here, we classify the conflict fimdamental causes

into following categories: 2.1 Different terminology,

2.2 Different perception of the design object,

2.3 Conflicting local goals,

2.4 Inadequate communication.

Thus, the conflict class is a combination of requirement type and conflict

fundamental requirement. As Figure 3-1 shows, a conflict class may be represented as a cell in the two-dimensional matrix.

For example, conflict class X may be expressed as:

(D.1 D 2 (3-1)

Where Dx1 is the requirement type dimension,

Dx2 is the fundamental cause dimension.

In conflict class identification discussed in following Chapter 4, it is found that different requirement types and fundamental causes lead to various different design behaviors, i.e. value indicator patterns. The two-dimensional matrix representation clearly illustrates the components of conflict classes.


2 Detailed definition of these fundamental causes will be given in Section 3.4.





19







Different
Terminology
Different
perception of the
design object
V
E Conflicting local
aj
-0 goals
U.
Inadequate
communication


Global Interface- Functionalrequirement compatibility influenced
requirement requirement 10 Requirement type (I) Figure 3 1: Dimensions in conflict class



3.3.2 Additional Characteristics of Conflicts


In this section, two important additional characteristics of conflicts are discussed:

(a) the availability of variable values and relationships to design agents involved in the conflict, and (b) the balance of variables involved in the conflict. Explicit Logical Inconsistency vs. Implicit Logical Inconsistenc


In engineering design, conflicts are the basic inconsistency causes, which result in the derived inconsistent symptoms throughout the relations among modules, components and their attributes. For example, consider two modules designed by two agents, i.e. Agent-A and Agent-B in a design project (Figure 3-2a and Figure 3-2b). Each module contains a set of attributes, connected by intra-module and inter-module relations. Some of the variables and relations are public, that is, besides their own agents; they are





20


accessible to other design agents and the C21 software agent. Others are internal, and accessible only to their own agents. In design process, the values of variables VAR-Al and VAR-B1 are considered inconsistent if they lead to explicit inconsistencies. Thus, an inconsistency between VAR-Al and VAR-B I propagates along relation chains in both modules, leading to an observable explicit inconsistent symptom, which involves two entirely different variables VAR-A3 and VAR-B3.

To determine the conflict class, the software agent needs to backtrack from the derived explicit inconsistency symptom to the basic inconsistency cause, through the linking relations. In some cases, these relations are available and readable to the human and software agents. But in other cases, they are inaccessible because they are part of the design agent's private information or hidden within the designer's mind, perhaps even unexpressed verbally. In the first set, named Explicit Logical Inconsistenc all associated relations and variable values are accessible and readable to all agents (Figure 3-2). In the second set, part or all of the relations and variables are inaccessible or unreadable. These are called Implicit Logical Inconsistency (Figure 3-2).

While the implicit logical inconsistency exists commonly in real-world

engineering design, it is rarely studied because of difficulty in tracking the privately held information in design and will not be studied here. In this study, only conflicts of the explicit logical inconsistency type are studied.






21








VAR-Al nInconsistency VAR-B
Cause RELATION-RA1 RELATION-RB I


VAR-A2 VAR-B2


RELATION-RA2 REFLATION-RB2Derived
VAR-A3 VAR-B3
Inconsistency Symptom





Readable/Available
information


(a) Explicit logical inconsistency




Figure 3-2: An example involving (a) explicit logical inconsistency (b) implicit logical inconsistency





22


















infrmaio L3IjW:jinfrato
:I :I. .- I. ..:.:.:.:.:.:.: . .





RELATION-RA2 RLTO'

~~Derivedm
VAR-A3 VAR-B33
~Inconsistency -~Symptom





[ Readable/Available Uraal/nvial



(b) Implicit logical inconsistency



Figure 3-2--continued



Balance of Attributes

Attribute balance may vary in different requirement types. In global requirements, attributes determined by all involved parties are balanced in that they are independent and directly contribute to the value of the global requirement variable. In the interface-related requirements, the related attributes are required to be compatible, i.e. of the same value in some sense. Thus, the attributes are balanced. However, in the functional-influenced





23


requirements, the relation between attributes is one-directional, i.e. one attribute's value is determined from the value of another one through some functional relationships. In this case, the attributes are referred as unbalanced.

Study of attribute balance helps us to understand the interactive relations and

behavior of attributes in various requirements. It is useful in identification of requirement types in conflict class identification.

3.4 Conflict Class Structure


From the previous sections, it is concluded that the most basic characteristics of the conflicts to be studied are requirement type and fundamental cause. Thus, conflict class is defined as a combination of requirement type and fundamental cause, as Figure 33 shows.

The requirements are grouped into set level and individual/local level. At set

level, there is aggregated requirement, while at individual/local level; there are interface compatibility requirements and functional-influenced requirements.

Similarly, the fundamental causes are grouped into three categories, i.e. different perceptions, conflicting local goals, and inadequate communication. The conflict causes in different perceptions category are further divided into five cases, i.e. different terminology, different point of view, different information, different model/tool, and different relational definition of an attribute.

hi the following section, the definitions and examples of these conflict classes are discussed in detail.





24



Design product conflict

Explicit logical
inconsistency Categories
Categories Cas
Dimensions Requirements at
Set Level Requirement
types
Requirements at Individual Level


Sam 3-3: C fccs t tu
Different terminology







Different perception of the design object





Fundamental Conflicting local goals
Causes



Inadequate communication a


Figure 3-3: Conflict class structure





25


3.4.1 Requirement Types

Global Requirement

Definition. A global requirement is a requirement that is imposed on a global variable, whose value is determined by two or more independent variables from different modules or parts. All the involved module variables are balanced. Examples. Global requirements can be divided into three categories: simple additive aggregation, complex function aggregation, and maximum/minimum requirement, as shown in the following examples.

1. Simple additive aggregation: In some aggregated requirement, the value of the

variable on which the requirement is imposed is simply aggregated by the sum of the contributing variables. For example, the overall weight of a plane is the

sum of the weight of its modules:

Plane.Weight = ZModule.Weight
AllModules

2. Complex function aggregation: Some requirement-related variables, such as

aircraft speed and range, are determined by complex functions of associated module variables. These functions are often non-additive and non-linear. For example, the speed and range of a plane are complex functions of parameters

of its configuration, propulsion, and fuel tank modules:


Plane.Speed = ComplexFunction ( ropulsion.Thust ,Configuration.Drag,...)


(Plane.Speed,
Plane.Range = ComplexFunction2 Propulsion.FuelRate, FuelTank.Fuel,...






26


3. Minimum/Maximum requirement: In this case, the requirement-imposed

variable is actually determined by the minimum or maximum value of the

associated module/component variables. For example, the strength of a plane

is the minimum strength of all modules and attachment components:

Plane.Strength = Min(Module.Strength, AttachmentComponent.St rength)

Interface-Compatibility Requirement

Definition. The interface-compatibility requirement is used to enforce the compatibility between module/component variables involved in an interface between modules. Since the involved modular variables are required to be compatible or of the same value, they are balanced in the requirement relation. Examples.

1. Interface-compatibility requirements are commonly used in industry such as

network engineering. In Klein's LAN design (Klein 1990), the data transferred

between two stations is required to have the same coding format.

2. In aircraft design, interfaces exist between attached modules, i.e. Propulsion

and Wing Structure. We assume these modules are fastened by bolts. Thus,

the holes for installing bolts and nuts of two adjacent modules are required to

be in the same position.

Functional-Influenced Requirement

Definition. A requirement of this type is imposed on a module's variable, which is determined by another module's variable value, or several other modules' variable values,





27


shown in Figure 3-4. Clearly, the variables in the functional-influenced requirement are unbalanced.




Requirement Module A Module B
imposed on variable Al

Variable A Variable B I




Figure 3-4: An example of functional-influenced requirement



Examples.

1. In Klein's house design case (Klein 1991), there is a requirement on the

cooling cost which is determined by a number of external features:

House.CoolingCost < $50/ month

The cooling cost is determined by the energy required by the cooling system, which is a complex function of outdoor temperature, sunlight, and the layout

of the windows especially in the south side3:

House.CoolingCost = Function KI (House.CoolingPowerOutput) Room.Temperature,
Environment.Temperature, House.CoolingPowerOutput = FunctionK2 Environment.Sunlight Environment.Sunlight, SouthSide.WindowLayout,...,



3 In the functions, subscripts KI and K2 indicate these are functions referred from Klein' work.





28


The sunlight effects the cooling cost greatly. In summer, the high summer sun raises the outdoor temperature. Also, if the south-facing front facets have large windows designed for better appearance, the insolation through these windows

will increase the room temperature and lead to excessive cooling cost. Thus,

the cooling cost of a house is functional-influenced by the appearance, i.e. the

layout of its windows of the south-facing facet. The requirement imposed on

the cooling cost is of functional-influenced type.

2. In aircraft design, the loading on a structure module is required to be less than

some fraction of its predicted strength:

Structure.Loading < Structure.Strength

For the rear structure, i.e. horizontal tail, its loading is a complex function of environmental factors such as air pressure, temperature, vibration, and noise.

(AirPressure,
Structure.Loading = Function, Temperature, 3 Vibration, Noise,....

Meanwhile, the environmental vibration and noise are affected by the

propulsion module's location, exhaust, and noise level.

Vibration = Function2 (Propulson:Noceiw.J SPropulsion.Noise,... )

Thus, the loading on a rear structure module is influenced by the propulsion module's attributes (i.e. location, noise) via a chain of related functions. The

requirement over the structure strength and loading is of functional-influenced

type.





29


3.4.2 Fundamental Causes~

Fundamental causes of conflicts are grouped into four categories: different terminology, different perceptions of the design object, conflicting local goal, and inadequate communication.

Different Terminology

Definition. In engineering design, agents use labels, which are also called terms, to represent the meaning of design entities such as variables and relations. In the case of different terminology, agents have different label-meaning relations for some variables in design.


IN~x ABELMEANING, LABELBMEANING,


Case 1 Case 2

Figure 3-5: Two cases of different terminology



This may involve two cases (Figure 3-5):

1. Agent-A and Agent-B use two different labels, i.e. LABELA and LABEL8 to

represent the same meaning, i.e. MEANTNGx. Thus, the two agents get

confused in communication, not knowing they are actually talking about the

same thing since labels they use are different.

2. Agent-A and Agent-B use a same label, i.e. LABEL, to represent two different

concepts (i.e. meanings), i.e. MEANINGx and MEANINGy. In this case, each

agent assumes that the other one talks about the same thing as he does.





30


Inevitably, each agent will be misled by the unexpected conclusion of the

other.

Examples. Both above situations occur in the engineering design. The following examples illustrate the different terminology concept.

1. Multidisciplinary product design: Designing multidisciplinary products such

as DVD (digital versatile disc/digital video disc) players often involves

various specialists in the fields of mechanical, electrical, optical, and software

engineering. Sharing information becomes complicated by the different

terminology, conventions used by each specialist (Ozawa 1998).

2. Structure strength: In structure design, the designers may have different

understanding of the structure strength, i.e. static vs. dynamic. From a static

perception, compression buckling and extensional strength are likely to be the main concerns. However, from a dynamic perception, strength may mean the

ability to resist fatigue and fracture caused by vibration, impact and noise.

Design agents with these two different backgrounds may have trouble in understanding each other because of different meanings of terminology.

3. Cargo capacity of an airplane may have the following different meanings:

Cargo weight, i.e. how many pounds of cargo the plane can carry,

Volume of cargo cabin, i.e. how many cubic feet of cargo can be put into

the cabin,

Minimum width and height of the cargo cabin, i.e. how large a single

cargo can be put into the plane.





31

Thus, people with different interests and backgrounds may interpret the term 46cargo capacity" in different ways, leading to trouble in information sharing

and design process.

Different Perceptions of the Design Objec

In collaborative design, the agents involved often come from various engineering backgrounds with different knowledge, experience, priorities, and criteria. Thus, it is common they may have different perceptions of the design entities, i.e. they may have different point of view (Ramesh 1994, Lander 1997a). Here, the different perceptions are divided into following cases: (1) different point of view, (2) different information, (3) different model/tool, and (4) different functional definition of an attribute. Definitions and examples of each case follow.

Different Point of View

Definition. In collaborative design, agents with different knowledge and experience background may consider the same object from different viewpoints, leading to different understanding and conclusion.

Examples. Conflicts resulting from different points of view are common in engineering design (Ramesh 1994, Lander 1997a). The following are some examples:

1. Automobile design: in the automobile industry, there are different points of

view about good car performance, that is, how to balance various primary and

auxiliary functions. Some companies prefer adding more auxiliary features

such as leather interior, and climate control. Obviously, it brings more ftm to

driving. However, to keep the cost low, some primary features such as





32

reliability and fuel efficiency may be sacrificed. Other companies tend to

focus on the primary functions such as the reliability and ftiel efficiency of the

engine and drive train system. In these designs, the auxiliary features are

considered as luxury or optional. These cars run well, lasting longer, yet are

not as comfortable as the former designs. When design agents with these two

points of view work together, they can be expected to have conflicting

opinions in design process.

2. Military design vs. civilian design: In aerospace industry, the military aircraft

designer's point of view is often dramatically different from that of the civilian aircraft designer. Traditionally, in military aircraft design, high

performance (i.e. agility, speed) is often the highest priority, while cost and

maintenance are secondary concerns. In contrast, civilian aircraft are designed

to be less expensive in both manufacturing and maintenance. Hence,

performance factors, such as agility and speed, are not the dominant concerns.

The different philosophies may lead to different point of view to the same

design object. For example, in plane structure design, the military-background

agents incline a design that is super light and super strong, being able to

sustain loading in pulling high G. The cost may be very high. The civilianbackground agents prefer a conventional design, which is easy to build, and

cost saving. It does not have to be super strong, i.e. only being able to sustain

relatively lower loading than that of the military aircraft. When the agents

with different background work together, different point of view may lead to

conflicts.






33


3. Aerodynamic vs. structure in aircraft design. Two agents work closely

together on design of the plane's wing. One is in charge of the aerodynamic

configuration and another works on the structure part. In the aerodynamic point of view, afterward-swept wing with high aspect ratio is desirable. It

provides high lift and low drag for the subsonic transport plane. However, in the structure point of view, straight wing with low aspect ratio is stronger and

lighter. Based on different consideration, these two agents may have

conflicting opinions on the wing design (Figure 3-6).








... ... ...... ..........
......... .. .................
.......... .... ....... .......
..........
............
.... ......


... ......
E



Aerodynamic viewpoint: Structure viewpoint:
AfterwaTd-swept wing with Straight wing with low
high aspect ratio aspect ratio



Figure 3-6: Different point of view on the wing configuration in aircraft design





34


Different Information

Definition. In collaborative design, two design agents sometimes use different information, input such as initial value, make the same calculation, but get different results.

Examples.

1. Numeric analysis: Different information input often causes conflicting results

in the numeric analysis in design. For example, two design agents use the

bisection method to compute the roots of a polynomial equation. If they input

different initial ranges, the roots found may be different even though the

computing processes are same. Here, as Figure 3-5 shows, Agent-A starts with

range [AjI, A2], while Agent-B begins with range [Bj, B21. Also, we have

[A, A2 ]r [B1, B2] = 0 Using bisection method, Agent-A may get root RA and

Agent-B may get root RB where RA = R, and RB = R3 (Figure 3-7).




Funion urve


Agent A's Agent B's
solution range solution range










Figure 3-7: An example that different initial ranges lead to different solutions





35


Different Model/Tool

Definition. Based on various considerations, i.e. experience, understanding, and availability of tools, two design agents use different models or tools to describe or evaluate the design object. Often, it leads to different result. Examples.

1. Different models Elastic model vs. viscous elastic model: In industry, elastic

model and viscous elastic model are often used to analyze the strength of

composite structures. Some people prefer the elastic model, which is simple

and easy to use, while others like the more complicated viscous elastic model.

In some cases, i.e. sandwich structure whose viscous characteristics becomes non-negligible, the computed results from the two models would be different

in some ways. Agents using different models could have conflicts in their

results.

2. Different tools NASTRAN and ABAQUS: NASTRAN and ABAQUS are

two common FEM (finite element method) tools for structure analysis. Some companies license NASTRAN, while others purchase ABAQUS. Generally,

their functions are similar with each other. However, it is learned that the two

software programs incorporate different models and algorithms in some cases4. Thus, the computed results from the two software programs may

become different.




4 From a private communication with Dr. Bhavani V. Sankar, Professor of Department of Aerospace Engineering, Mechanics, and Engineering Science, University of Florida.





36


For example, two groups participate in a joint project of structure design.

Agents in one group use NASTRAN, while agents in another group use

ABAQUS. Agents in the two groups may have conflict in their results of

structure analysis.

Different Functional Definition of an Attribute Definition. In this case, two agents use different functional descriptions of attributes with the same labels.

Examples.

1. Overall project cost: The overall project cost (OPC) is an important attribute

concerned in evaluating a project. However, there are various possible

functional definitions of this attribute. Traditionally, OPC contains only the

development and manufacturing cost.
Cost = Cost t~v~per+ Cost .
CotverallProject CotDevelopment + Costmanufacturing

Since the 1980s, more and more engineers tend to include the maintenance

cost, considering OPC as project life-cycle cost:

CostoverallProject = CotDevelopment + CoStimanufacturing Comaintenance

Meanwhile, for some specific products such as batteries, the disposal cost is

also included in the OPC:

COSt overall Project = COst Development + Costmanufacturing + Cost maintenance + Costdisposal

If the agents involved in the same project have different functional definition of attributes as above example, they may have conflicts in the design process.





37


Conflicting Local Goals

Definition. In a design team, each agent has his local goals. Some local goals are explicit (i.e. the thrust goal for a propulsion agent), while others are implicit (i.e. personal goals). This study focuses only on the explicit local goals.

To achieve their local goals, design agents manipulate the modules' variables in design. In some cases, their local goals are conflicting with each other, leading to violation of the associated requirements.



Examples.

1. Positive feedback loop: One example of conflicting local goal is the positive

feedback loop. In this case, an agent increases his attribute value in pursuit of

his own local goal. This in turn causes another agent to increase his attribute

value. In consequence, the related agents have to keep on increasing their attribute values in cascade. As a result, the global requirement is violated.

For example, in tank design, the overall performance of a tank is determined

by three major factors, i.e. firepower, mobility, and protection (Hunnicutt 1988). The tank design often involves modules of gunnery (including firecontrol system), power package (simply called engine hereafter), armor, and

vehicle structure (simply called structure hereafter). As Table 3-1 shows, each module's agent has his own local goals. These local goals are often related to

the module weight by functions, shown in Table 3-2.





38


Table 3-1: Local goals and related module attributes
AGENTS LOCAL GOAL VARIABLE LOCAL GOAL
Gunnery Caliber (Cal) and length- Bigger gun with larger caliber and
caliber ratio (Len) of the gun length-caliber ratio for superior firepower

Structure Internal space volume (Vol) Large internal space (for guns, engines,
and structure strength fuel) and more structure strength
(Strength)

Armor Armor protection area (Area) More armor to cover more area of the
tank

Engine Horse power (Hp) and fuel More powerful engine for better
(Fuel) mobility, more fuel for range




Table 3-2: Local goals and related module weight
MODULE LOCAL GOAL RELATED TO MODULE
AGENTS VARIABLE WEIGHT
Gunnery Caliber (Cal) and length- (Calo, ,
caliber ratio (Len) of the Weight Gu. = FuncA LenGun gun

Structure Internal space volume Vols,,e,
(Struct) (Vol) and structure
strength (Strength) Strengths,'c1
Weights,,, = Func, WeightG.n, Weight Engie,
FuelEngine


Armor Armor protection area c(AreaArmor
(Area) Weight Ar,.., Funcc.os'
volsova

Engine Horse power (Hp) and (HPEngine
fuel (Fuel) FuelEngine,
Weight Egi = Func Weightsr

Weight Ann.,





39


In pursuing these local goals, the agents may fall into a positive feedback loop, leading to violation of some global requirement such as overall weight of the vehicle. As Figure 1-8 shows, in the design, the gunnery agent attempts to field a bigger gun for superior firepower. To adapt the bigger gun, the structure agent tends to build a larger and stronger vehicle. Meanwhile, in order to provide better protection to the larger vehicle, the armor agent has to cover more area. Also, a more powerful engine, which is bigger, heavier, and less fuel-efficient, is needed. To contain the bigger engine and more fuel, the structure agent has to increase the vehicle size again, which often triggers another loop of design. All these come with the penalty of increased weight. As a result, the overall weight of the tank increases steadily, violating the global requirement of the tank weight. In history, the over-weighted tank design such as German Tiger-II in VMI, which resulted in immobility, often led to poor performance in battlefields (Macksey 1988). Another example is the American heavy tank program in WWII. After years of developed, the M6 tank was canceled by the Army due to its immense size and weight (i.e. over 60 tons, twice as heavy as the ones in service at that time) (Hunnicutt 1988).





40




Gunnery Module: Initialize the loop Structure Module:
B igger gun .................................. ....................... ON. M ore internal space
and structure strength


Global requirement on weight:
Weight < 30 tons


Engine Module: Armor Modu le:
More horsepower and More protection area
more fuel



Figure 3-8: An example of positive feedback loop in tank design



Inadequate Communication

Definition. In this case, for a period of time in design, some agents do not have sufficient communication necessary for coordinating their designs, or keep on ignoring the requests from other agents and the changes on the related attributes by other agents. Example.

1. Airplane design commonly involves multiple teams responsible for different

parts (i.e. aerodynamic configuration, structure, propulsion, fuel tank, cargo etc.). These different parts are the responsibility of different human design

agents. Human agents tend to work on the design issues one by one. That is,

each agent will focus on one aspect at a time, and give significant effort to do it before going on to the next issue. As long as agents pay prompt attention on their colleague's work, this will not cause any conflict. However, some agents may totally focus on their own design, ignoring the related variable changes or





41


the requests from other agents. Such situation may lead to conflicts in design

process. For instance, the delay in communication may lead to agents using

obsolete information in design.

3.5 Conflict Cause Identification


With knowledge of conflict nature discussed above, the next task is to develop an appropriate method to identifybe conflict class and cause when a conflict is detected in the design process. The details of Conflict Cause Identification are discussed in Chapter 4 and 5.
















CHAPTER 4
CONFLICT CAUSE IDENTIFICATION Effective identification of conflict cause is important for resolving conflicts in

design processes. It facilitates the design agents to assess the situation, i.e. the cause and behavior of the conflict precisely, and thus helps the agents to apply appropriate methods to resolve the conflicts.

4.1 Introduction: Identification of the Conflict Causes


4. 1.1 Review of Previous Work

Historically, various approaches have been proposed to identify conflict causes.

In Klein's work (Klein 1990, Klein 1991), a set of preconditions is suggested for each conflict class I. In the design process, the conflict resolution (CR) agent queries the design agents using relatively abstract questions in order to find a match to a conflict class's precondition. A specific query language is developed to carry out the query process. While formal language-based query is conceptually valid and makes the identification process well structured, its application is limited in real world design. In general, design agents prefer communicating in natural language. The formal query language is often hard to understand and therefore avoided by design agents (Easterbrook



In Klein's work, conflict class is considered equivalent as the conflict cause.


42





43


1993). In addition, many of the conflict classes proposed by Klein are too specific to LAN design and have limited use for conflict resolution in generic situations. Furthermore, Klein's system does not distinguish conflicts from difficult problems in design.

JUther than using a query approach, Cointe develops a library of generic

components, which stores the conflict-related design information (Cointe 1997)2. In this library, the design information is grouped into conflict class-related categories, i.e. needs, resources, and requirements. In finding the conflict class, the Evaluation agents assess the variables and relations in each category, looking for inconsistencies. Cointe's software agent works autonomously; that is, it retrieves the design information from the public data storage system such as the library rather than depending on querying the human agents, which they believe is often unreliable. However, in Cointe's system, the clustering of information in the library is based on various design facets rather than different conflict behaviors. In addition, the Evaluation agent only utilizes the current value of design data, and ignores the history of these data.

4.1.2 The Basic Approach Taken in This Work

Based on previous studies and our own research, a web-based Conflict Cause Identification (C'I) system has been developed. The C'I system tracks the history of design information (i.e. variable values in a design entity), extracts the Value Indicator Patterns (VIPs) from the information, retrieve the requirement types, applies appropriate computation to determine the conflict causes, and communicates the results to the





44


appropriate design agents, thus, supporting them in conflict resolution in the distributed design system.

The web-based C'I system involves three major components: the conflict-related Agent Behavior Model, the Value Indicator Pattern, and the Design Process Graph. Conflict-related Agent Behavior Model (ABM)

The conflict-related Agent Behavior Model (simply called the Agent Behavior Model or ABM hereafter) is a set of rules, which describe how human design agents behave and interact with each other in a web-based design environment. The ABM serves as the basis of Value Indicator Pattern and Design Process Graph analysis.

A general ABM would involve rules of agent behavior in various designing

aspects. In this study, focus is on the conflict-related rules only. The agent behavior rules (ABR) are collected and created from both studies referenced and our experience in the Plane World simulation. Since these rules have not been rigorously validated empirically, they are considered as assumptions in this work. Value Indicator Pattern (VIP)

Generally speaking, the pattern of an entity is a set of characterizing parameters, which describe some of its specific features (Wolff 1983). Pattern recognition and analysis is a popular data analysis method that identifies the patterns in the experimental data produced in an investigation and draws useful conclusions from them. In this study, Value Indicator Pattern (VIP) is viewed as a set of parameters characterizing variable



2 Cointe's work also considers conflict class as equivalent to conflict cause, with no consideration of the requirement type.





45


values, collected in the design history, which are tracked and analyzed to determine the conflict causes in design process.

Here focus is on the public variable values and relations, which are published into the public database system in the design process and readable to all design agents and the software C'I agent. In engineering design, there is also some information privately kept by individual design agent for internal use. Since it cannot be accessed by other agents, such private information is not included in the C'I process. Design Process Gr aph (DPG)

Using heuristic expert rules, expert systems are widely applied in industry and medical service to deal with difficult problems in complex domains which often resist precise description and rigorous analysis (Hayes-Roth 1983). One of the classical examples is NffCIN (Hayes-Roth 1983, Buchanan 1984), a rule-oriented expert system that addresses the problem of diagnosing and treating infectious blood diseases, which has been well established and tested for years.

Figure 4-1 shows the architecture of MYCIN. In diagnosing infectious blood diseases, MYCIN applies a set of heuristic rules to describe the relations of disease causes and consequent symptoms in various stages and situations. Using these rules, decision trees are constructed to describe the complex procedures from a fundamental disease to its corresponding symptoms, the cause-consequence relations involved and their possibilities, shown by the gray arrows. In reverse, the inverse processes are applied to backtrack the ftmdamental disease from the symptoms observed, shown by the dotted arrows (Buchanan 1984).





46



MYCIN diagnosis model
Disease causes Symptoms

blood
disease [needcision teeS Expert system rules


Pathology fundamental:
Disease behavior model




Figure 4-1: Diagnosis of blood diseases in MYCIN expert system



Using the MYCIN approach as a guide, a rule-based C21 system has been

developed, which uses the Agent Behavior Rules (ABRs) and resulting Design Process Graphs (DPGs) as the basis for identifying conflict class and cause from the Value Indicator Patterns (VIPs) obtained in design processes.

In the C21 system, the DPG derived from the ABRs can be used to describe the complex mapping relations between the conflict causes, requirement types and the corresponding symptoms, i.e. Value Indicator Patterns in the design process. In the reverse process, the software C21 agent can utilize the mapping relations described by DPG to identify' the conflict causes from the requirement type available and VIPs observed, thus, supporting the Conflict Cause Identification. Because there is no general





47


methods to invert the ABM rules in present artificial intelligence research' the mapping relationships between conflict classes and associated VIPs are used in the inverse identification process.

4.1.3 Conflict Cause Identification Model

The Conflict Cause Identification (C'I) model, shown in Figure 4-2, involves five major parts, i.e. conflict situation, Agent Behavior Model, Design Process Graph, Inverse Identification Process, and symptom.

1. Conflict situations: Grouped by various classes, the conflict situation is a

combination of fundamental causes and requirement types. In engineering design, the conflict situations are inputs to the design system, influence the agents, and produce the conflicting design results, i.e. the symptoms. These

are originally unknown and the result sought by the C'I system.

2. Agent Behavior Model (ABM): The model of conflict-related agent behavior

describes how design agents behave in conflict-related situations. ABM forms

the basis for the Design Process Graph. The rules in the ABM are collected from studies referenced and our exploration in the Plane World system. The

ABM is discussed in detail in Section 4.2.

3. Design Process Graph (DPG): Based on ABM, the DPG describes how

variables evolve from conflict situation to corresponding symptoms. The DPG

is discussed in Section 4.4.


3 From a private communication with Dr. Douglas D. Dankel, Assistant Professor of Department of Computer and Information Science and Engineering, University of Florida.






48


4, The inverse identification process is a backtracking through this graph, which

is discussed in Section 4.5.

5. Symptoms: Symptoms, which contain the Value Indicator Patterns (VIP), are

the output information associated with a conflict situation as produced by

agents in the web-based CE design. Symptoms are a history of design variable

values, which can be used to backtrack and determine the conflict causes.

Messages between design agents may also be part of the symptoms but are not

used in this study. The VIPs, that the C'I system depends on in this work, is

discussed in Section 4.3.


Conflict situation
. ....... ...............
Conflict
fundamental Design
process
causes Agents
Design Symptoms
< L DPG process
(Design loop) VIP




Lead to

Rules in
ABM




(a) DPG in design process Figure 4-2: The C'I model in (a) design process (b) inverse identification process





49




Backward Backward
Conflict situation identification Agents identification Symptoms
process
.......... ................... -.11 ........... 11 ................ p ro cess
VIP
Conflict Inverse DPG
fundamental 40 Mapping relationships
causes


Lead

M
Backward
Rules in ABM,
identification



:ead
process
DPG
<
..................................... . . l u n g


(a) DPG in inverse identification process Figure 4-2--continued



In the design process (Figure 4-2), the conflict situation, which contains both

conflict fundamental causes and requirement types, influences the agent, modeled by the ABM and DPG. Based on ABM rules, the DPG processes the input information and shows how associated variables and relations evolve as design agents seek to cooperate to achieve both local and global goals. The output design results contain the corresponding symptoms, i.e. the VIPs.

In the inverse identification process (Figure 4-2), the symptoms, i.e. the VIPs, are extracted from the design results. Also, the requirement type, stored in the public design information database that is available to the C'I agent, serves as a key factor in the backward process determining the conflict fundamental causes. Based on the mapping between the conflict cause, requirement types and associated VIPs, the C'I agent





50


identifies the most likely conflict causes from the VIPs observed and requirement type available. A unique conflict cause could perhaps be obtained if a sufficiently detailed and precise model of agent behavior rules and DPGs is created and sufficient data collected. In this study, due to the limited capability of our model, the C'I system will identify the set of possible and most likely conflict causes.

In the following sections, the four major components of the C'I systems

mentioned above, i.e. Agent Behavior Model, Value Indicator Pattern, Design Process Graph, and Inverse Identification Process will be discussed in detail.

4.2 Conflict-related Agent Behavior Model


4.2.1 A rule-oriented Agent Behavior Model (ABM)

An understanding of how the design agents behave in design, especially in a

distributed CE design environment, is necessary to predict conflict symptoms for Conflict Cause Identification. The Agent Behavior Model (ABM) is used for this purpose.

In this study, the conflict-related ABM contains a set of heuristic rules collected from previously referenced studies and our exploration in the Plane World simulation. These rules describe how the agents perform and interact with each other in the distributed design environment. A general ABM would describe the agent behaviors in various aspects such as conflict-related, personality-related, etc. Here, our model is limited to the-conflict related behaviors. The model has face validity in that it seems reasonable. Since this model has not been formally validated, it is considered to be a reasonable assumption.





51

Using the rules in natural language rather than a rigorous mathematical approach in the ABM has the following advantages,

1. Modeling human behavior often involves complex social and psychological

concepts, which are generally hard to describe and analyze rigorously. Current mathematics offers little help in this task. However, rule-based modeling often

works well (Hayes-Roth 1983).

2. Using natural language, the rule-based model of agent behavior is comfortable

to humans and easy to understand.

4.2.2 Description of Conflict-related Agent Behavior Model

The conflict-related ABM involves two parts, i.e. design agent context and agent behavior rules.

Design Agent Context

The design agent context is a set of assumptions, describing the basic

characteristics of the design agents in the design process. It contains the following items:

1. Each agent considers a complete set of significant parameters for his own part

(i.e. variables and relations in his design object) that must be included in his

design. However, there may be some parameters important to other agents that

are not included.

2. Each agent has goals, both local and global goals, for the design of his

individual part of the product, some explicit, some implicit.





52

3. -In pursuing local goals, each agent's choice of attribute values will vary

-around their preferred values within a limited range, i.e. not jump around

wildly.

Agent Behavior Rules

The agent behavior rules (ABR) are principles that describe how agents carry out their own part of design and coordinate with each other in a distributed design system. In this study, the following conflict-related ABRs are assumed:

1. Agents are honestly cooperative, seeking to achieve both local and global

goals. (Lander, 1997b)

2. Agents will give primary attention to local goals, and secondary attention to

global goals. (Ullman, 1997)

3. Agents will attempt to be cooperative and helpful when asked, but will remain

local goal oriented.

4. Agents will focus on one aspect (local goal) at a time, and give significant

effort toward achieving it before going on to another issue. (Ullman, 1997)

5. Agents will often delay responding to requests from others.

6. Each agent maintains internal consistency in his part of the design. There are

no conflicts within each individual's part of design.

7. Agents expect other agents to think and behave like they would.

8. Upon receiving several different requests from other agents in design, the

agent will focus on the latest request and tend to ignore the older ones if they





53


are conflicting. Thus, die latest one is considered to be most relevant to the

frequently changing design situation.

In aggregation, the design agent context assumptions and the agent behavior rules listed above define the ABM used in this study.

4.3 Value Indicator Patterns


4.3.1 Pattern Recognition App ach

As Figure 4-2 shows, to identify the conflict classes and causes, the C'I agent will track and analyze the explicit symptoms of the conflict, i.e. the output information of the conflict situation processed by agents in the forward design process. The conflict symptoms are divided into two principal types: Value Indicator Patterns and explicit messages.

Value Indicator Patterns (VIP

The Value Indicator Pattern (VIP) is a set of numerical characteristics of a

variable value history, which can be tracked and processed by the software C'I agent toward the goal of determining the conflict class and cause. The VIP considers both current and past values of the variables, which are public to all agents involved in the design.

In this study, VIPs are used as the basis for Conflict Cause Identification and involve the following considerations,

1. Patterns of numeric variable values are easy for the software C'I agent to

retrieve and analyze. In some cases, value patterns may be the only source of

design information available.





54


2. Value patterns are relatively easy to be interpreted and modeled using

mathematical methods.

Explicit Messages

In design, agents often communicate with each other via explicit messages.

Human design agents usually prefer using messages in natural language rather than the ones in a specially defined formal language, i.e. query language in Klein's system (Easterbrook 1993, Klein 1990).

Explicit messages are a potential resource for Conflict Cause Identification. However, their use has several serious drawbacks,

1. Messages are often hard to interpret by a software agent and also by human

agents at times, especially the ones in natural languages. It is usually possible to set rigorous grammar standards for machine based agents. However, human

agents are reluctant to comply with such grammar standards (Easterbrook

1993).

2. In some cases, there may be no messages at all. For example, some involved

human design agents may feel too busy with their own work to exchange

messages with others.

Thus, the C'I system will not utilize the explicit messages but rather exclusively focus on the Value Indicator Patterns.

4.3.2 Basic Value Pattern Characteristics

In a Value Indicator Pattern, a path is formed by the time-history values of each related variable, which commonly change frequently in the design process. These may be





55


described mathematically using an appropriate method. Interpreting the paths provides two principal types of information, i.e. the path shape and its destination. The shape demonstrates how the variable value changes with time in design. Meanwhile, from its past and current values, we can predict the curve's destination, i.e. predict its future values.

In this study, it has been found that the path's shape and destination

characteristics in VIPs vary due to different combinations of conflict cause and requirement type. Therefore, the VIPs are partitioned along the two basic dimensions, i.e. Shape and Destination.

Shape

In a design process, design agents change or adjust their variables' values as they seek to achieve both their own local goals and the global design requirements. Often, the change of value of one agent's variables results in cascade adjustment of other agents' design, often with subsequent adjustment required by the original agent, forming a loop in the design process. Thus, the shape of variable paths in value patterns reveals information regarding interactions between the agents and the possible causes of the conflict.

The value patterns are grouped into the following categories of shapes:

1. Monotonic: The major trend of a variable involves steadily ascending,

descending, or constant values.

2. Oscillatory: The major trend of a variable is an oscillation among several

clusters or families of values.





56


3. Chaotic: There is no simple rule to describe the behavior of a variable. The

variable values appear to be randomly distributed along the time axis.

4. Segmental: In this case, the values of a variable may be divided into several

segments along the time axis. Within each segment, the variable values are

clearly of one of the types listed above. However, for two adjacent segments,

the values either vary greatly or are of different types. Destination

1. Divergent: The variable values generally deviate increasingly from an

acceptable value.

2. Slow convergent: The variable converges towards an acceptable value in the

design process. However, the convergence speed is so slow that the variable is

unlikely to achieve an acceptable value before a required deadline time.

3. Converge to an unacceptable value or stable at several values: (a) for the case

of converging to an unacceptable value, the variable appears to be converging

to a value which is unacceptable, i.e. not equal to an acceptable one. The

predicted destination value could be either greater or less than an acceptable one. (b) For the case of stable at several values, the variable fails to converge

to an acceptable value, but appears to remain stable at several values.

4. Converge to an acceptable value: The variable is predicted to converge to an

acceptable value before any deadline. That is, the requirement is being

satisfied by the basic design process.





57


Various Types of Value Indicator Pattern

The combination of the above two dimensions (i.e. shape and destination) leads to

16 types of Value Indicator Patterns (VIPs), shown in Table 4-1. Examples of these

distinctive VIP types involving two agents are shown graphically in Figure 4-3 to Figure

4-6.




Table 4-1: Abbreviations used to identify Value Indicator Pattern
Destination Divergent Slow convergent Converge to an Converge to an
(DV) (SC) unacceptable acceptable value
value/stable at (CAV)
Shape several values
(CUS/SSV)
Monotonic
(MO) MO-DV MO-SC MO-CUV/SSV MO-CAV
Oscillatory
(OS) OS-DV OS-SC OS-CUV/SSV OS-CAV
Chaotic
(CH) CH-DV CH-SC CH-CUV/SSV CH-CAV
Segmental
(SG) SG-DV SG-SC SG-CUV/SSV SG-CAV






58




VleDeadline Value Deadline




0o@
0U



Time Time


Agent A Agent A
o Agent B 0 Agent B

(a) Monotonic (b) Monotonic, slow convergent
divergent



VleDeadline Value Deadline











Time *Time


9 Agent A Agent A
0 Agent B 0 Agent B

(c) Monotonic, converge to an unacceptable (d) Monotonic, converge to
value/stable at several values an acceptable value







Figure 4-3: Various monotonic value patterns






59




VleDeadline VleDeadline






000


00



Agent A Agent A
0 Agent B 0 Agent B

(a) Oscillatory, divergent (b) Oscillatory, slow convergent




VleDeadline VleDeadline




0 0



*

Time *Time


Agent A Agent A
0 Agent B 0 Agent B

(c) Oscillatory, converge to an unacceptable (d) Oscillatory, converge to
value/stable at several values an acceptable value







Figure 4-4: Various oscillatory value patterns






60




Value Deadline Value Deadline
0


0

A
cOTF,
--- -----------0
0 0

Time Time


9 Agent A 9 Agent A
0 Agent B 0 Agent B

(a) Chaotic, divergent (b) Chaotic, slow convergent




Value Deadline Value Deadline


.......... ...
0
Acceptable d
------------------ --- ----------------Acceptable do
0
..... ................. .......... ............. 0 .............
0
... ............... 0 ..........................
6 ...................


Time
Time


0 Agent A 9 Agent A
0 Agent B 0 Agent B

(c) Chaotic, converge to an unacceptable value (d) Chaotic, converge to an acceptable value
/stable at several values








Figure 4-5: Various chaotic value patterns






61




VleDeadline Value Deadline






0 Tim







Agent A Agent A
o Agent B 0 Agent B

(a) Segmental, divergent (b) Segmental, slow convergent




VleDeadline Value Deadline











Time Tim


Agent A Agent A
0 Agent B 0 Agent B

(c) Segmental, converge to an unacceptable (d) Segmental, converge to
value/stable at several values an acceptable value







Figure 4-6: Various segmental value patterns





62


4.3.3 Real World Conflict-related Value Indicator Patterns

In this work, Value Indicator Patterns are sought which form logical cohesive set that reflects real world design process behavior, and that can be reliably recognized by a software agent. The following examples illustrate that the VIPs chosen can and do arise in real world design efforts.

As discussed in the above sections, the C21 model assumes different combinations of conflict fundamental causes and requirement types commonly lead to different Value Indicator Patterns (VIPs). This section provides limited confirmation of this assumption. Here, several examples of different conflict classes and corresponding VIPs collected in literature referenced and Plane World simulations are discussed. Focus is on description of these VIPs. Details about how these VIPs are produced by results from the conflict situations will be discussed in Section 4.4. For convenience, the abbreviations used in referring to conflict classes are shown in Table 4-2.




Table 4-2: Abbreviation of conflict classes
Requirement type Global Interface- Functionalcompatibility (ICR) influenced
Conflict cause (GR) (FIR)
Different terminology
(DT) DT (GR) DT (ICR) DT (FIR)
Different perception
(DP) DP (GR) DP (ICR) DP (FIR)
Conflicting local goal
(CLG) CLG (GR) CLG (ICR) CLG (FIR)
Inadequate communication
(IC) IC (GR) IC (ICR) IC (FIR






63


Example 1: Different Terminology, Global Requirement


Figure 4-7 shows the mapping from the conflict class "different terminology,

global requirement" to the associated VIPs.


Conflict class

Requirement type Global requirement Interface- Functionalcompatibility influenced
Fundamental cause (GR) (ICR) (FIR)
Different terminology DT (GR) DT (ICR) DT (FIR)
(DT) 0 d
Different perception
(DP) ,
Conflicting local goal
(CLG)
Inadequate communication
(IC)


Value indicator pattern

Destination Divergent Sb converge Converge to an Converge to an
unacceptable acceptable value Svalue/stable at several value Shape (DV) C) CUV/SSV) (CAV)
Monotonic
(MO) A____ N___Oscillatory
(OS) ______ ______Chaotic
(CH) CH-DV CH-SC CH.CUV/SSV
Segmental
(SG)




Figure 4-7: Mapping from the conflict class "different terminology, global requirement" to associated VIPs






64




Value of the global Value of the global
Akrequirement-related Deadline requirement-related Deadline
variablevariable




0 00
0 0
0 00 0 0@

Time ,Time


(a) Chaotic, divergent (b) Chaotic, slowly convergent



ValueDeadline


7777-, 7--70 Values of the requirement-related
-4. variable due to Agent-A's design
change
0 Values of the requirementa 0 0 related varable due to AgentB's design change with his
0 understanding of the requests
from Agent-A
Time


(c) Chaotic, converge to an unacceptable value or stable at several values



Figure 4-8: An example of VIPs expected to result from the conflict class "different terminology, global requirement"





65

Consider the example of cargo capacity in aircraft design discussed in Section

3.4.2; two design agents responsible for the cargo and structure modules have different understanding of the term "cargo capacity". For instance, the cargo agent considers 66 cargo capacity" as the minimum width and height of the cargo cabin, while the structure agent interprets it as the maximum cargo weight. Meanwhile, there is a global requirement on the cargo performance measure, i.e. the minimum height and width of the cargo cabin.

Different terminology commonly leads to misunderstanding between the two

agents and conflicts in their designs. Thus, the behavior of each agent is irrational to the other and there appears to be no correlation between results. The VIPs which might result are illustrated in Figure 4-8. In the figure, the shape of design result (i.e. the global requirement-related variable) is chaotic, i.e. there is no simple rule to describe its behavior. Meanwhile, there are three possible destinations of the design result, i.e. (a) divergent, (b) slowly convergent, or (c) converge to an unacceptable value/stable at several values, as described in Section 4.3.2. Example 2: Different Perception, Interface-Compatibility Requirement

The mapping from the conflict class "different perception, interface-compatibility requirement" to the associated VIPs is shown in Figure 4-9.

To illustrate the VIPs of this class, consider the example of interface design

between the propulsion and structure modules discussed in Section 3.4. 1. In the example, module variables involved in the interface-compatibility requirement are balanced, in that they are not functionally dependent on each other but are assigned by their module





66

agents. They are, of course, required to be compatible in values. The two agents responsible for these two modules have different perceptions regarding desirable holepositions of attachment components, i.e. bolts and nuts. For instance, the propulsion agent might prefer wide spacing between bolts for saving the space for other links (i.e. fuel, electric etc.), while the structure agent might prefer smaller spacing for even distribution of the load. Each agent works on his module design primarily based on his own perception and is reluctant to change, perhaps hoping the other agent will change. Thus, the requirement that the hole-positions in the two modules should match will not be satisfied, a conflict in design.

Possible VIPs resulting from this conflict class are illustrated in Figure 4-10. The path shape of the requirement-related variable value (i.e. difference between the two designs) is expected to be monotonic. The destination could be one of two types, i.e. slowly convergent and converge to an unacceptable value/stable at several values, as described in Section 4.3.2.






67



Conflict class
Requirement type Global requirement Interface- Functionalcompatibility influenced
Fundamental cause (GR) (ICR) (FIR)
Different terminology
(DT)
Different perception DP (ICR)
(DP)
Conflicting local goal
(CLG)
Inadequate communication
(IC)
-II

Value indicator pattern
Destination Divergent Slow convergen Conver to an Converge to an unacc ble acceptable value value/sta e at several v ue Shape (DV) (SC) (CUV/S ) (CAV)
Monotonic
(MO) MO-SC MO-CUV/SSV
Oscillatory
(OS)
Chaotic
(CH)
Segmental
(SG)



Figure 4-9: Mapping from the conflict class "different perception, interface requirement" to associated VIPs






68


Difference between Deadline Difference between Deadline
two designs in two designs in
bolts/nuts positions bolts/nuts positions

0
0
0
0
0
............. Q Unacceptable
.... .................... .............. .........
0 value



Time Time


Agent of wing structure 0 Agent of wing structure
Agent of propulsion 0 Agent of propulsion
(a) Difference between the two designs: (b) Difference between the two designs:
Monotonic, slow convergent Monotonic, convergent to an unacceptable value


Figure 4-10: An example of VIPs expected to result from the conflict class "different point of view, interface-compatibility requirement"



Example 3: Conflicting Local Goals, Global Requirement

Figure 4-11 shows the mapping from the conflict class "conflicting local goals, global requirement" to the associated Value Indicator Pattern.

To illustrate the VIPs of this class, consider the example of tank design discussed in Section 3.4.2, the areas of gunnery, vehicle structure, armor, and engine are functionally connected to the global requirements of overall weight and performance measures (i.e. firepower, mobility, and protection).

In the design, the design agents responsible of the vehicle structure, armor, and engine modules have conflicts in achieving their local goals. One agent's design change results in cascade changes in other agents' designs, resulting in a positive feedback loop






69


and steady increase of the tank overall weight. Conflict becomes clear when the weight

goes beyond an acceptable value.


Conflict class

Requirement type Global requirement Interface- Functionalcompatibility influenced
Fun ental se (GR) (ICR) (FIR)
Different terminology
(DT)
DifferentDperception


Conflicting local goal CLG (GR)
(CLG)
Inadequate(c)CmmuncationI




Value indicator pattern

Destination Divergent Slow convergent Converge to an Converge to an unacceptable acceptable value value/stable at
several value
Shape (DV) _(SC) (CUV/SSV) (CAV)
Monotonic
(MO) MO-DV
Oscillatory
(OS)
Chaotic
(CH)
Segmental
(SG) T



Figure 4-11: Mapping from the conflict class "conflicting local goal, global requirement" to the associated VIPs



The associated VIP is shown in Figure 4-12. Here, the path shape of the

requirement-related value (i.e. weight of the tank) is monotonic. Its destination is

divergent, i.e. steadily increasing beyond the acceptable value due to the positive

feedback loop caused by conflicting local goals among design agents.





70



Weight of the tank Deadline

+
0



0
0

Time

0 Gunnery agent 0 Structure agent Armor agent
+ Engine agent



Figure 4-12: An example of the VIP expected to result from the conflict class "conflicting local goals, global requirement"



Example 4: Conflicting Local Goals, Functional-Influenced Requirement


Figure 4-134 shows the mapping from the conflict class "conflicting local goals, functional-influenced requirement" to the associated VIPs. For example, the aircraft design is divided into several parts, i.e. control, propulsion and structure assigned to different teams. Assuming the orientation of the propulsion exhaust is aftwards, values of some variables in both control and tail structure parts are influenced by the location and orientation of the propulsion unit.






4 In the figure, "FIR 3+" means functional-influenced requirement type with three or more agents involved.





71


For the control part, the yaw-controllability (Anderson 1989) when one of the two

propulsion units shuts down is influenced by the propulsion unit's location and

orientation.

For tail structure, the vibration and heat loading is also influenced by the

propulsion unit's location and orientation. The situation is illustrated in Figure 4-14.


Conflict class
Requirement type Global requirement Interface- Functionalcompatibility influenced
Fundamental cause (GR) (ICR) (FIR)
Different terminology
(DT)
Different perception
(DP)
Conflicting local goal CLG (F 3+)
(CLG)
Inadequate communication
(IC)


Value indicator pattern

Destination Divergent Slow co ent Co 'ge to an Converge to an
acceptable acceptable value lue/stable at several value Shapetc (D) (SC) (CUV/SSV) (CAV)
Monotonic
(MO)
Oscillatory
(OS) OS-DV OS-SC OS-CUVISSV
Chaotic
(CH)
Segmental
(SG)



Figure 4-13: Mapping from the conflict class "conflicting local goal, functionalinfluenced requirement (3 or more agents involved)" to associated VIPs






72


Here, the local goals of the agents responsible for the control and tail structure parts are conflicting with respect to values of the propulsion unit's location. The control agent wants the propulsion units to be placed close to the fuselage for better yaw controllability when one of the propulsion units is shut down. In contrast, the structure agent responsible for the tail structure wants the propulsion units to be located away from the fuselage so the tail can be cleared from the propulsion units' exhaust.



Local
Control requirement
imposed on
BI

Controllability

Propulsion (BI)
Function:
IB =F (A 1)
T Local
Location requirement
Tail structure
imposed on
(A 1) Function: C I

CI=G (Al)
Vibration/heat loading
(Cl)

Epp



Figure 4-14: An example of a fimctional-influence requirement



Because of the conflicting local goals, the agents responsible for the control and tail-structure modules send opposite requests to the propulsion agent about the propulsion's location, which leads to conflict in design. Since the ABM suggests that agents tend to respond to the most recent request, an oscillatory shape is anticipated.





73

Possible VIPs resulted from conflicting local goals are illustrated in Figure 4-15. In the VIPs, the shape of the requirement-related variables (i.e. the distance from the between the propulsion and the tail for the structure part and the distance between the propulsion unit and the fuselage for the control part) tends be oscillatory. The destinations could be (a) divergent, (b) slowly convergent, or (c) converge to an unacceptable value / stable at several values, as described in Section 4.3.2.






74




Value of C I in Tail- Deadline Value of C I in Tail- Deadline
structure module structure module

7Z t

0
0
0 0 0 0
0
0

0




Time Time

(a) Oscillatory, divergent (b) Oscillatory, slowly convergent



Value of C I in Tailstructure module Deadline Value of C1 in the tail-structure
module due to change of value of A I in the propulsion module on
--------- -request from the control agent


0 Value of C I in the tail-structure module due to change of value of
0 0 0
0 A I in the propulsion module on
request from the structure agent




Time

(c) Oscillatory, converge to an unacceptable value
or stable at several values



Figure 4-15: An example of VIPs expected to result from the conflict class "conflicting local goal, functional-influenced requirement (3 or more agents involved)"5





5 The VIPs of the requirement-related variable (i.e. B 1 in the control module) are similar and omitted here.





75


Example 5: Inadequate Communication, Functional-Influenced Requirement

Figure 4-16 shows the mapping between the conflict class "inadequate

communication, functional-influenced requirement" and the associated VIPs.


Conflict class
Requirement type Global requirement Interface- Functionalcompatibility influenced
Fundamental cause (GR) (ICR) (FIR)
Different terminology
(DT)
Different perception
(DP)
Conflicting local goal
(CLG)
Inadequate communication IC (FIR)
(IC) & Aa



Value indicator pattern
Detnton Diegn lwcneg n Arergae- verge to an
Divergen Slo levrg n eptable value
"valu ~ale at c
se Ina value
Shape (DV) _SC/ /SSV) (CAV)
Monotonic
(MO) '
Oscillatoryhoi(H(S
(OS)_______Chaotic
(CH)_____
Segmental
(SG) SG-DV SG-SC SG-CUVISSV



Figure 4-16: Mapping from the conflict class "inadequate communication, functionalinfluenced requirement" to the associated VIPs


To illustrate the VIPs of this class, consider the example of aircraft design

discussed in Section 3.4.2, which is decomposed into multiple teams responsible for

different modules of the aircraft. Meanwhile, there is a functional-influenced requirement





76


that the tail must be cleared from the exhaust of the propulsion units. Otherwise, the exhaust will cause high loading of heat, noise and vibration on the tail, leading to unacceptable damage to its structure. In design, some agents (i.e. the propulsion agent) may totally focus on their own modules and ignore the request messages or design changes from other design agents (i.e. the structure agent responsible for the tail), these may be inadequate communication between design agents leading to conflicts in the design. Thus, there are extended periods of inadequate communication followed by response.

Possible VIPs are illustrated in Figure 4-17. Here, the path shape of the value of the requirement-related variable (i.e. the clearance distance from the tail to the effect zone of the propulsions) is segmental. That is, the history values are divided into several segments. Within each segment, the values are relatively constant or converging toward a constant value. However, the values between two adjacent segments are significantly different. The destination of the requirement-related variable could be one of three types; i.e. (a) divergent, (b) slowly convergent, or (c) converge to an unacceptable value/stable at several values, as described in Section 4.3.2.






77





Value of the requirement- Value of the requirementrelated variable (i.e. the related variable (i.e. the
clearance distance from the clearance distance from the
tail to the propulsion's tail to the propulsion's
exhaust) in tail-structure part exhaust) in tail-structure
Deadline part Deadline

geptabit ili 3
ATMr
00
0 000
0 0




4j. Time 0 Time


(a) Segmental, divergent (b) Segmental, slow convergent


Value of the requirementrelated variable (i.e. the
clearance distance from the Value of the requirementtail to the propulsion's related variable (i.e. the
exhaust) in tail-structure part Deadline clearance distance from the
tail to the propulsion's
exhaust) when the propulsion agent focuses on his part of design and tends to ignore the 0 tail structure agent's requests
......... ... 0 0 ........................
.... .......... ............ ....... ....... .0 -0 ........
V20
..... .......... .......... ................. V 'O 0 Value of the requirem entrelated variable (i.e. the
clearance distance from the tail to the propulsion's
Time
exhaust) after the propulsion agent considers the tail
(c) Segmental, converge to an unacceptable structure agent's request and
value or stable at several values adjust his part of design




Figure 4-17: An example of VIPs expected to result from the conflict class "Inadequate communication, functional-influenced requirement"





78


4.4 Design Process Graph in-the Forward Design Process


Based on the ABM, Design Process Graphs (DPG) are developed to describe how the conflict fundamental causes lead to the specific Value Indicator Patterns (VIP) and the evolution of variables and relations in this procedure (Figure 4-3a). Thus, the mapping between conflict cause/requirement type and associated VIPs is identified and studied. In the inverse identification process, such mapping is inverted to determine the conflict fundamental causes from the VIPs observed and the requirement types available.

In the following section, the DPGs and their derivation of VIPs is presented. The inverse identification in which possible conflict class and cause are determined is presented in Section 4.5.

4.4.1 Structure of the Design Process Grap

The DPG contains the following elements:

1. Conflict cause: The fundamental causes of conflict. These are the principal

types of agent disagreements leading to conflicts in collaborative engineering

designs. In this study, seven fundamental causes are identified, defined, and

studied.

2. Requirement type: Requirement type, in combination with conflict cause,

plays a key role in determining the conflict symptoms. In this study, three

principal types of requirements are identified, (a) global, (b) interfacecompatibility, and (c) functional-influenced.






79

A further possible subdivision of requirement type is to the cases of

requirement relation type6, which may prove useful in the future but is not

used here.

3. Agent Behavior Rules (ABR): Rules in the ABM serve as a guideline in

construction of the process graphs, describing how the design agents are

predicted to behave and how the variables with relevance to several modules

are expected to evolve in the design process.

4. Variable: The variables mentioned here include both local variables in

individual modules and global variables related to global requirements.

5. Alternative patterns: The alternative patterns of a variable represent the

patterns, which may result from the choices made by design agents.

The symbols for the above elements used in figures of the DPG applied in the C21 model are shown in Table 4-3.




Table 4-3: Elements in the DPG
ELEMENTS IN DPG SYMBOLS

Conflict fundamental cause [ I Z

Design agentG il

Agent Behavior Rule (ABR)L ZZ Z

Variable valueLu I l



6 Teeare many different types of relations in the requirement such as (a) V < V0, (b) V > V0, (C) V E [V,. V21, and (d) V e [VI, V21.





80


Alternative patternL I ]

Requirement satisfied or not I


Specification of values


Information, or messages


ABM rules determine the agent behavior




As discussed in Section 3.3. 1, the conflicts are divided into different classes,

represented by cells in the matrix illustrated in Figure 3-1. Each class (i.e. Class C1j) is a combination of fundamental cause and requirement type (indicated by i and j). In this work, DPGs are introduced to describe how variables evolve in these different conflict classes.

Concurrent Engineering (CE) design commonly involves loops in design process. Figure 4-18 illustrates the inter4ction between agents and the resulting design loops in a design situation involving in a particular conflict class (i.e. Class Cj) In the design, Agent-A is responsible for variable VAR-Al of module A, and Agent-B is responsible for VAR-B 1 of module B. A requirement is imposed on a variable, i.e. VAR-R, which is determined by values of variables VAR-Al and VAR-B I through functions. According to the ABM rules, design agents seek to achieve both local and global goals. That is, they specify their variable values based on their own local goal evaluation and feedback from the public information (i.e. value patterns of the requirement-related variable VAR-R) and other agents (i.e. explicit messages). Therefore, Agent-A and Agent-B often alternate





81

in adjusting their variable values in order to cope with the other party's change in design, resulting in a series of loops as Figure 4-19 shows.

The important role of loops is a major difference between the Design Process Graph (DPG) and the decision trees commonly used in expert systems, which often do not involve loops (Raiffa 1970, Buchanan 1984).



Design situation involving global goals


................................................Fn to o










IFunctioe or
V A!Mat rules

Figue 4-8: ode rfth acti o between agnt innCErdesig n ..................r...................
Informati n................
SValue of variable Valu ofvral
VAR-A1 VAR-BI 1
/ Value of variable
/ r" / VAR-R

L"n Infofiation Informntion 0 0"
.. .. . .. ................... . . . . .. . .. . .. . .. . .. . .
S Request message from B to A


Inflenc Influence







Figure 4-18: Model of the interaction between agents in CE design





82





















Agent-A specifies B Agent-B specifies
A variable VAR-A l variable VAR-B I



Figure 4-19: Results from the design loop



Figure 4-20 illustrates the DPG of Case Cij. Here, one agent (i.e. Agent-A) adjusts the value of his module variable (i.e. VAR-Al) to achieve his local goal. The change of Agent-A's variable VAR-Al may affect other agents' variables, which are functionalrelated (i.e. Agent-B's variable VAR-B 1). Thus, based on the agent behavior rules, Agent-B is expected to adjust the values of VAR-B1 to achieve his local goals and the requirements. Often, Agent-A has to adjust VAR-Al due to the change of VAR-B 1 by Agent-B. Thus, the interaction among agents forms loops in the design process. In consequence, the associated requirement may be affected, producing one of several VIPs (i.e. VIPI and VIP2). The requirement may or may not be satisfied, indicated by the DPG.





83


In decision trees, not all paths (i.e. series of decisions) have to lead to desirable results (Raiffa 1970). Similarly, the paths in DPGs do not always lead to a violation of the requirement. If the requirement is violated, the information about how variables evolve along this path is composed to a Value Indicator Pattern (VIP) of this specific case. Here, only those paths that lead to requirement violation are considered in the DPGs in this study.

4.4.2 Use of the Design Process Graph in the Forward Design Process

In this section, analyses are described which show how the Design Process Graph (DPG), implicitly defined by ABM rules, leads to the change of designing state (i.e. variables, relations and requirements) in various cases of conflict fundamental causes and requirement types and leads to specific Value Indicator Patterns. Results are collected in Table 4-4.

Analysis 1: Different Terminology, Global Requirement

As introduced in Section 4.3.3, the mapping from the conflict class of different terminology with global requirement to the associated VIPs is shown in Figure 4-7.

Conflicts caused by different terminology may involve any one of the three

requirement-types, i.e. global, interface-compatibility, and functional-influenced. Here, the situation involving global requirement (Class C, 1) and its DPG is analyzed. This will be done using a specific example of cargo capacity in aircraft design (introduced in Section 4.3.3), where two agents are responsible for designs of cargo and structure modules (i.e. Agent-A for the cargo module and Agent-B for the structure module). The two agents have different meaning when they use the same term "cargo capacity".





84


Design situation
involving conflict class

Cij with global goals



Function,
..................................... or M ath rules .


Value of variable
VAR-R

-- --IP1 I 2




Fir 4 : TValue of variable C Requirementne r Value of variabledg o





ndeinA s Request message from B to A ic a a


Infuece i Influence






Figure 4-20: The DPG of conflict class Cii in the forward design process



In design, Agent-A sends a message to Agent-B asking him to increase cargo capacity (meaning the minimum width and height) of the cargo space. Due to different interpretation, instead of making more space available for the cargo, Agent-B strengthens the structure of the cargo space based on his understanding of the term "cargo capacity"






85


(i.e. interpreted as meaning the maximum cargo weight). In other word, Agent-B moves in a different direction than what is expected by Agent-A. In consequence, the related variables, the cargo space' s minimum width and height, do not change in any anticipated way and the requirements are not satisfied. To Agent-A, Agent-B's misunderstanding and subsequent action is irrational and unpredictable. So is the design result. The shape of the requirement-related variable values, i.e. the minimum width and height of cargo cabin, tends to be chaotic. Its destination could be divergent, slow convergent, or converge to an unacceptable value/stable at several values. The process is illustrated in Figure 4-21. The resulting VIPs are expected to be similar to those shown in Figure 4.8. Analysis 2: Different Terminology, Interface-Compatibility Requirement

To analyze the design process for the conflict class "different terminology,

interface-compatibility requirement.", assume two agents (i.e. Agent-A and Agent-B) are responsible for the designs of the interface between two modules (i.e. Module A and B). There is an interface-compatibility requirement that the two modules' interface design should be compatible, i.e. the difference between values of variable VAR-Al in Module A and VAR-B I in Module B should be within an acceptable small range:

I VAR-A 1 VAR-BJ < e

The two agents have different meaning when they use the term "TERMx", for

instance, Agent-A considers TERMx as a variable VAR-Al while Agent-B interprets it as another variable VAR-B2 rather than VAR-B 1, the counterpart of VAR-Al1.

In the design, Agent-A asks Agent-B via messages to change the value of TERMx (meaning VAR-B 1) to match his design of VAR-Al. Based on different understanding of





86

the term "TERMx" (i.e. interpreted as meaning VAR-B2), Agent-B tends to change the value of VAR-B2, which is not what Agent-A expects. Thus, the requirement on the difference between values of VAR-Al and VAR-B 1 will not be satisfied. SDesign situation
involving Conflict Class
C,j with global goals J f iFunction or Math


Value of the requirement- x






VIP= VIP VIP=
CH-DV CH-SC CH-UV/SSC

V ~~~ ~~~ ................... ........................ V

VleofvralsValue of module B's variable
Values of variables V
in module A (B I), assigned by Agent-B
involved in the Requirement with his understanding of the
requirement satisfied? request from Agent-A


A ent-A Request message trminoo B Agent-B




[ABR for Agent-A: ABR for Agent-B:
6, 1,'3,and 7



Figure 4-2 1: DPG of the conflicts class "di fferent terminology, global requirement"






87


Since Agent-B's misinterpretation and subsequent cannot be described in a simple rule, the shape of the design result tends to be chaotic. Its destination could be divergent, slow convergent, or converge to an unacceptable value/stable at several values.

Figure 4-22 illustrates the process. The resulting VIPs are also expected to be similar to those shown in Figure 4-8.

Analysis 3: Different Terminology, Functional-Influenced Requirement

In this case, two design agents (i.e. Agent-A and Agent-B) are responsible for designs of two modules (i.e. Module A and Module B) where a functional-influenced requirement is imposed on a variable in Module A (i.e. VAR-Al) whose value is controlled by the value of another module's variable (i.e. VAR-B 1). These two agents use different terms on VAR-B I. For example, Agent-A uses TA for VAR-B 1, while TA means another variable to Agent-B.

Thus, in the design, when Agent-A sends a message asking Agent-B to adjust

VAR-B 1 to his desired value, Agent-B tends to change some other variable's value due to the misunderstanding of Agent-A's terms. Similar to the situation in Analysis 1 and 2, Agent-B's misunderstanding and his design is unpredictable, the path of design result is chaotic. Its destination could be divergent, slow convergent, or converge to an unacceptable value/stable at several values.

The process is illustrated in Figure 4-23. The resulting VIPs are also expected to be similar to those shown in Figure 4-8.






88




Design situation

involving Conflict Class C,2 with global goals Function or Math
-..................... rules] ............. . .................. A



Value of the interfacecompatibihty requirementrelated variable



VIW VIP=
CH-DV CH-SC -UV/SSC

V .. ............................ ... ................. ......... I.



Values of variables Value of module B's variable
in module A (B 1), assigned by Agent-B
involved in the Requirement with his understanding of the
requirement ~ saisfiedd request from Agent-A






&Agent-A ....... gnw about changing the value of B I



ABR fo ABRt-A for Agent-B:
f6,Ag7 tA 13, and 7




Figure 4-22: DPG of the conflict class "different terminology, interface-compatibility requirement"