Conflict detection in Web based concurrent engineering design

Material Information

Conflict detection in Web based concurrent engineering design
Added title page title:
Conflict detection in Web-based concurrent engineering design
Zhuang, Ruiqiang
Place of Publication:
Gainesville FL
University of Florida
Publication Date:
Copyright Date:


Subjects / Keywords:
Concurrent engineering ( jstor )
Conflict management ( jstor )
Conflict resolution ( jstor )
Deadlines ( jstor )
Design engineering ( jstor )
Engineering ( jstor )
Freight ( jstor )
Product design ( jstor )
Software ( jstor )
Systems design ( jstor )
Aerospace Engineering, Mechanics and Engineering Science thesis, M.S ( lcsh )
Dissertations, Academic -- Aerospace Engineering, Mechanics and Engineering Science -- UF ( lcsh )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )


ABSTRACT: Concurrent engineering design is a complex process that commonly involves the cooperation of many people from different disciplines. When multiple design agents are involved, conflicts involving disagreements between agents are bound to arise. Management of conflicts is an important factor in determining if a group of people can work together successfully to produce a satisfactory design. Early detection of conflict is a key factor in conflict management. Since human conflict detection expertise is rare, a software conflict detection (CD) agent is sought. This work focuses on the development of such an agent which can support concurrent engineering design where designers (human agents) are distributed geographically but connected via the Internet. Detection is based on patterns of published parameter values, the only source of information sure to be available to the CD agent. This work results in a CD agent which runs in the background of a design effort, detects patterns of values likely to indicate disagreement among design agents, prioritizes these situations, and notifies design agents and/or conflict resolution agents present. Since the detection agent also identifies situations where difficulty in meeting requirements is predicted, designer will be notified of these situations. A web-based distributed design system is used as a test bed to demonstrate and evaluate the results of the work.
KEYWORDS: concurrent engineering design, conflict detection
Thesis (M.S.)--University of Florida, 1999.
Includes bibliographical references (p. 52-54).
System Details:
System requirements: World Wide Web browser and Adobe Acrobat Reader to view and print PDF files.
System Details:
Mode of access: World Wide Web.
General Note:
Title from first page of PDF file.
General Note:
Document formatted into pages; contains vi, 55 p.; also contains graphics.
General Note:
Statement of Responsibility:
by Ruiqiang Zhuang.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Ruiqiang Zhuang. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Resource Identifier:
45296504 ( OCLC )
002531717 ( AlephBibNum )
AMP7641 ( NOTIS )


This item has the following downloads:

Full Text








First of all, I want to express my deepest gratitude to my thesis advisor, Dr. Gale

E. Nevill, for teaching me and guiding me through this work. I am thankful for his time,

encouragement, and enthusiasm. His advice and support have been invaluable. I am

particularly appreciative of his ability to help me see the "big picture" when I was too

caught up in the details of what I was doing, and of his insistence on precision and clarity

of expression in my written work.

I want to thank Dr. Raphael T. Haftka for serving on my advisory committee.

I want to thank Dr. Edward K. Walsh for serving on my advisory committee.

A very special thanks to Mr. David Rockey for providing a convenient computer

environment in which to test our software.


A C K N O W L E D G M E N T S .................................................................................................. ii

A B S T R A C T ....................................................................................................... . ........ .. v


1 INTRODUCTION........................ .. ............... ...............

2 REV IEW OF RELA TED W ORK .......................................... ...................... ............... 5

2.1 Framework of a Cooperative, Concurrent Multiagent Design System.................5...
2.2 D efinitions of C conflict ................... ..............................................................7......
2.3 Causes of Conflict ..................... .. ........... .............................8
2.4 Conflict Detection ........................ ........... .............................9
2.5 C conflict R solution .. .................................................................... ... ............ 10

3 C O N F L IC T ..................................................................................................................... 12

3 .1 D efi n itio n .............................................................................................................. 12
3.2 C lasses of C onfl ict .............. ................... ............................................... 12
3.3 D election of C onfl ict ..................................................................... ............... 14

4 C O N FLIC T D E TE C TIO N ...................................................................... ................ 16

4 .1 D esign P process D om ain ......................................... ........................ ............... 16
4.2 Product Domain .................. .. ........... ................ ................ 17
4.3 D esign Fram ew ork A ssum ed ............................................................ ............... 19
4.4 Explicit Inconsistent/Incompatible Requirements and Relationships.................20
4.5 Implicit Inconsistent Requirements and Relationships....................................21
4.6 Patterns of Param eter Values ........................................................ 22
4.7 Conflict D election .... .. ................................. ............................ ............. 27
4 .8 N otifi catio n ............................................................................................................ 3 2

5 R E SU L T S .................................................................................................... . ........ .. 3 5

5.1 A Sim ulation E xam ple .......................................... ......................... ................ 35
5 .2 R e su lts ................................................................................................................. ... 4 0


6 C O N C L U SIO N S ..................................................... ................................................ 4 5

APPENDIX: DESCRIPTION OF PLANEWORLD ....................................................47

R E F E R E N C E S .................................................................................................................. 5 2

B IO G R APH ICAL SK ETCH .................................................................... ................ 55

Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science



Ruiqiang Zhuang

December, 1999

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

Concurrent engineering design is a complex process that commonly involves the

cooperation of many people from different disciplines. When multiple design agents are

involved, conflicts involving disagreements between agents are bound to arise.

Management of conflicts is an important factor in determining if a group of people can

work together successfully to produce a satisfactory design.

Early detection of conflict is a key factor in conflict management. Since human

conflict detection expertise is rare, a software conflict detection (CD) agent is sought.

This work focuses on the development of such an agent which can support concurrent

engineering design where designers (human agents) are distributed geographically but

connected via the Internet.

Detection is based on patterns of published parameter values, the only source of

information sure to be available to the CD agent. This work results in a CD agent which


runs in the background of a design effort, detects patterns of values likely to indicate

disagreement among design agents, priorities these situation, and notifies design agents

and/or conflict resolution agents present. Since the detection agent also identifies

situations where difficulty in meeting requirements is predicted, designer will be notified

of these situations.

A web-based distributed design system is used as a test bed to demonstrate and

evaluate the results of the work.


Modem aircraft, submarines, and buildings are often designed by people from

many companies, even countries. Concurrent engineering design with geographically

distributed agents is increasingly common. This new design process model is dramatically

different from traditional engineering design.

Many traditional design applications have used a sequential model of design

generation, which divides the design task into subtasks that are serially executed in a

prespecified pattern. Figure 1-1 shows a traditional sequential design model. This model

has successfully handled routine and semicustom design. However, sequential design is

brittle and inflexible and often requires numerous iterations through what can be an

expensive and time-consuming set of steps (Lander [1997]).

Traditional sequential design methods seem increasingly inappropriate to deal

with current large design projects. The main problem with this approach is the lack of

communication and then misunderstanding among design agents. Every agent makes

decisions based primarily on his own perspective, points of view, and local goals. This

commonly leads to disagreement at a later stage. Then agents have either to backtrack and

do their work all over again or to make suboptimal arbitrary decisions. These issues often

severely limit the number of design alternatives that can be examined.

Figure 1-1. Traditional sequential design

With the fast development of networks and the Internet, it becomes easy to

connect the agents together and strengthen communication among them so that they may

consider all aspects of the design concurrently. Concurrent design tries to solve the

problems that exist in traditional sequential design by detecting and considering

downstream constraints and conflicts early in the design process and by performing

subtasks simultaneously to the greatest degree possible. Figure 1-2 shows a concurrent

engineering design model. There are many advantages using this approach, for example,

every agent has an overall view of the design project, they can easily find their effects on

each other's work, and make decisions not just to optimize their own local goals, but give

more thought to global goals. They have a better understanding of each other's activities

and can identify and resolve problems earlier in the design process.

Figure 1-2. Concurrent engineering design

However, there are problems with concurrent design. Conflicts involving

disagreement between design agents are one of the most important. Although we believe

conflicts to be common, few examples have been found in the literature. A classic case is

the conflict between the design engineer who cares about product performance and the

manufacturing engineering who is concerned with ease of manufacturing at low cost

(Fleischer & Liker [1997]).

Handling conflict is one of the main factors that determine whether a group of

people can work together successfully and how collaborative work can continue even in

the presence of conflict. Before conflicts can be resolved, they must first be detected.

Also to make cooperation among designers more efficient, situations where difficulty in

meeting requirements are important and need get designers' attention. This work


addresses creating and testing a conflict/difficult detection software agent suitable for use

in web based design systems.


Most of the previous works have considered both conflict detection and resolution

but have focused primarily on resolving conflicts. Generally, they classified conflicts into

categories or class hierarchy structures and studied corresponding strategies to resolve

them. Methods for conflict detection (particularly early conflict detection) and for

determining their nature are not well explored in the literature.

2.1 Framework of a Cooperative, Concurrent Multiagent Design System

Design has become an increasingly cooperative endeavor carried out by multiple

agents with diverse kinds of expertise. Such a multiagent system is usually composed of

autonomous computer agents and human workgroups. There are many obvious

differences between computer agent and human agent. Relatively, the behavior of human

agents is more unpredictable and inconsistent than that of software agents. That makes

cooperation between human agents more complicated and adds to the difficulty of

developing distributed systems with human agents.

Effective collaboration is the key to a multiagent system. Such a system should

successfully manage information flow, design process, and conflict (Lander[1997a]).

Information should flow smoothly among the agents, results should be available when

and where they are needed, and the relationship among the subtasks should be exploited

whenever possible to achieve the highest-quality solutions with the least amount of

overall effort.

Harrington[1996], for example, used the layered structure shown in Figure 2-1 to

support engineering design. The blackboard is the hub of the framework and it holds all

the shared design information. The control layer is responsible for planning agent

execution. The negotiation layer is to resolve conflict between the disparate agents. The

capability and assumption maintenance layer is used to represent their capabilities and

make assumptions in order for the individual agents to collaborate with each other. The

agent is a design program that has the ability to function independently from other design

programs. The engineer on the boundary is supported by an agent in his/her task.

Figure 2-1. Concurrent engineering framework (Harrington[ 1996])

Blackboard technology is used extensively in distributed design systems. The

blackboard is a knowledge source given special status as a repository of shared

information (Rich [1991], Klein [1990]). Using blackboard objects, constraint and

conflict detection information can be added to the blackboard and a conflict resolution

agent can be established based on the blackboard.

2.2 Definitions of Conflict

Several definitions of conflict have been suggested, however there is no generally

accepted definition. Pruitt[1981] defined conflict as disagreement between two or more

viewpoints on some decision or values proposed in a design. Harrington [1995] adopted

Pruitt's definition of conflict and points out that these disagreements are due to the

differing needs that lead to incompatible preferences among the alternatives under

consideration. It is important to note that these needs are not the inherent cause of

conflict: it may be possible to find alternatives that are acceptable to all parties.

Harrington [1995] also states that conflicts can also be anticipated, where a design

decision is recognized to cause a potential conflicting situation some time in the future, or

a situation in which the decision optimality of another discipline is affected. This is very

important for those people who try to build a conflict free system. Anticipating conflict is

valuable in reducing design effort by identifying and resolving design conflicts before

they actually occur.

Easterbrook [1993] adopt Putnam and Poole's definition of conflict: the

interaction of interdependent people who perceive opposition goals, aims, and values, and

who see the other party as potentially interfering with the realization of these goals. This

definition highlights three general characteristics of conflict: interaction, interdependence,

and incompatible. Using this definition, conflict is not the opposite of cooperation, but a

phenomenon that may arise whether people are cooperating or not. Successful

cooperation depends on how the conflicts are handled.

2.3 Causes of Conflict

In a complex design system, conflicts may occur from many different reasons.

There is no general agreement on the structure of the classification of causes of conflict.

Different people use different criteria to classify causes of conflict that best facilitate their

work. Deutsch[1973] classified causes as: (1) control over resources; (2) preferences and

nuisances, where the tastes or activities of one party impinge upon another; (3) values,

where there is a claim that a value or set of values should dominate; (4) beliefs, when

there is a dispute over facts, information, reality; (5) the nature of the relationship

between the parties.

Robbins[1989] classified causes of conflict as follow: (1) communicational,

including insufficient exchange of information, noise, and the semantic differences that

arise from selective perception and difference of background; (2) structural, which

includes the goal compatibility of members of the group, jurisdictional clarity, and the

leadership style; (3) personal factors, including individual value systems and personality


Lander[1997] used the following classes: (1) incorrect information or knowledge;

(2) incomplete knowledge that leads to conflicting assumptions; (3) inconsistent beliefs;

(4) different criteria for evaluating alternative designs; (5) different reasoning

mechanisms; (6) interacting resource requirements.

2.4 Conflict Detection

Early conflict detection is very important for conflict avoidance and resolution.

Since some design states may have unsatisfiable constraint sets or generate negative

critiques while still at a high level of abstraction, we can often detect conflict before a lot

of effort has been invested in exploring that particular design (Klein[1990]).

Based on different definitions of conflict and classification of causes of conflict,

people use different methods to detect conflict. Conflict can be detected by identifying a

disagreement between two or more viewpoints on some decision or values proposed in a

design. Conflict can also be anticipated: although it does not have to be dealt with using

the same urgency as existing conflict, it may require an exchange of assumptions or a

change of the design route in such a direction that the anticipated conflict does not occur

(Harrington[ 1995]).

The detection task can also be viewed as a diagnosis task in which a default (i.e.,

the conflict) is located (Matta[1996]). Conflict symptoms can be first detected and

contributors may be transformed into hypotheses in order to define explicitly the elements

and the nature of the conflicts.

The Cooperative Design Engine (CDE) Klein[1990] provides three conflict

detection methods: (1) statement vs. statement, a kind of conflict that occurs when two

design statements that cannot simultaneously be true are asserted in the same design

context; (2) goal vs. goal, which occurs when two logically incompatible goals are

asserted; (3) goal vs. statement, which occurs when a goal is asserted that is logically

incompatible with the existing design state.

Although many authors have discussed detection, no explicit scheme for their

detection has been found. This is the impetus for the current work.

2.5 Conflict Resolution

Once a conflict is detected, a resolution method is selected and applied and the

result is then evaluated to determine if the conflict is resolved or not. In the latter case,

another method can be selected and applied, and so on (Matta[1996]).

Basically there are two options for resolving conflicts (Harrington[1995]). Firstly,

the conflicts can be resolved at development time from discussions with engineers.

Secondly, the conflict can be resolved at run-time, where conflicts are identified and

resolved when the system is in execution. Although development time conflict resolution

avoids the need for additional computation to detect and resolve conflict, it is impractical

in large complex domains with multiple viewpoints, as there are possible an enormous

number of interdependencies between the design decisions. Run-time conflict resolution

may be classified as either state oriented or worth oriented (Rosenschein &

Zlotkin[1994]). In a state-oriented approach, a goal state is identified.

Pruitt has identified three basic conflict resolution strategies from his research into

human work groups (Pruitt[1981]): cooperative behavior, competitive behavior, and

unilateral concession. Cooperative situations typically involve conflict resolution

techniques such as compromise, the abandonment of less important goals, and consensus.

The aim in a cooperative situation is to find as mutually beneficial a solution as possible


(Klein & Lu [1989]). In the cooperative design system, Klein provides first-class status

for conflict resolution expertise (Klein[1991]).

Findler [1995] studied how agents can resolve resource conflicts and effectively

accomplish the task in an environment of limited resources. He used a negotiation method

to allow agents to bid for tasks based upon the agent's capabilities. To resolve resource

conflicts, he used a hierarchical iterative conflict resolution method. A distributed

problem-solving agent runs on each processor representing an agent for solving problems.


3.1 Definition

There is not a consensus regarding definition of conflict, therefore it is important

to state the definition we will use. Normal or routine design can be viewed as a

negotiation between designers trying to choose concepts and parameter values so as to

meet project goals. We consider CONFLICTS to be exceptions to the normal design

process. That is, situations in which the normal design process fails. We define conflict as

disagreement between two or more agents, which is not being effectively resolved by the

routine design process. For examples, two agents cannot agree on the value of a

parameter or they have different views on how to evaluate a parameter.

3.2 Classes of Conflict

Matta [1996] defined generic models for the conflict management task in CE

(Concurrent Engineering). She divided conflicts to two categories: 1). Conflicts between

design and requirements. 2). Disagreements between some participants in the designers

group, according to their design assumptions. She didn't study the first category. Based

on our definition of conflict, the first type of situation is not considered. It is part of

normal design process.

Another way of organizing conflicts is by causes into classes as follows:

Product domain conflicts (conflict concerns the object being designed). These

may include, for example:

incompatible/inconsistent requirements,

global versus local constraints,

competition for limit resources,

disagreement about parameter values,

negative effects of one element on others, causation loops.

Process control conflicts (conflict concerns the design process). These may

include, for example:

orders of processes,

incompatible strategy,

allocation of responsibilities,


Control-level conflicts concern conflicting recommendations about the direction

the design process should take in trying to create a design. While conflict resolution at the

control level is clearly important, there does not seem to be a good theory of control even

for individual agents. It thus appears premature to try to develop a theory for detecting

and resolving control level conflicts among multiple agents. (Klein [1991]). Control

conflicts are not considered in this work.

The first step in conflict resolution is the detection of existing or potential

conflicts. Detection is the focus of this work.

3.3 Detection of Conflict

The task here is thus to identify existing or potential disagreement between

cooperative design agents regarding product domain decisions which are not being

satisfactorily resolved by the normal design process.

Further, we focus on web based design, and we seek a technique which uses

public information which can reasonably be expected to be published and thus available

to a CD agent. Note that we do not depend on private information which we do not expect

to be available. Two principal types of information are suggested: parameter values and

explicit messages between design agents.

It would be easy to set message grammar standards for machine_based agents.

However it is hard to interpret messages between human agents. In fact, there maybe no


However, in any design effort there must be design parameter values suggested

and over time, patterns of these values will formed. Therefore, in this work detection

focuses on patterns of parameter values.

Figure 3-1 shows the model we use. Note that CD could be useful even without

the presence of a specific conflict resolution(CR) agent.

Figure 3-1. Conflict Management Model

To facilitate conflict detection, we need a simple model of the design system. The

constant evolution of standards, technologies, and a dynamic marketplace demands a high

degree of adaptability in both design expertise and in the process of applying that

expertise (Lander [1997a]). Given design tasks, the constraints are generated, added,

deleted and modified during the whole design process. Conflict detection agent must be

able to function in this context of dynamic information. We will discuss how to establish

a design process model and how to detect conflict based on that model in the next



It may be possible to build a conflict free design system (called development time

conflict management) with autonomous software agents. However, with human agents, it

is probably not possible to do so and the greatest current need is for run time CR support.

We will build our CD agent to facilitate conflict detection at run time, that is, during the

design effort. Next we identify assumptions being made regarding the design effort.

4.1 Design Process Domain

Design activities are carried out by agents which may be human or software

agents. Lander[1997] defined agent as any relatively autonomous software component

that can communicate with humans or other software components and that contributes

expertise to the design process, whether that component is representing a user, assisting a

user, or autonomously performing some design task. Here either human or software

agents may be present.

Generally speaking, a design model can be competitive or cooperative. In

competitive situations each party has solely their own benefit in mind and has no interest

in achieving a globally optimal situation if such a solution provides them no added

personal benefit. In cooperative situations, the parties are united by the superordinate goal

of achieving a globally optimal solution, which often requires sacrificing personal benefit

in the interest of increased global benefit (Klein [1991]). Here we assume our design

agents (designers) are cooperative, since that is most appropriate for most engineering

design where the shared goal of producing the best possible solution exists. It is worth

noting that the cooperative model assumed encourages design agents to seek both global

and local goals, not to abandon local goals and have only global goals.

Further we assume that each design agent has primary responsibility for some part

or aspect of the product, works concurrently with other design agents, gives primary focus

to this aspect, and periodically publishes recommendations and monitors the

recommendations of other agents and the status of the overall design.

4.2 Product Domain

Description of the product to be designed is also required. Products will be

described in terms of objects, resources, relations among objects, and requirements which

objects and collections of objects must meet.

We use the object-oriented method to describe design objects, each design object

has its own attributes and functions. For example: We define a rectangle as follows:

Table 4-1: Description of a rectangle
Attribute X, Y (bottom left point coordinate)
Width, Height (size)
Function Area = Width x Height

We also utilize inheritance among design objects, i.e. a design object can inherit

from one or more existing design objects. In this way, the derived design object has all

the attributes and functions of its parents. For example, object A is derived from object B

and object C, so object A combines all the attributes and functions of object B and object


V2 V4
Funcl Func3
Func2 B C Func4

V V2 V4
Funcl Func3
Func2 Func4


Figure 4-1. Inheritance

In practice, this mechanism is quite useful. We can build our project in a

hierarchical structure. If well organized, we can define common design objects only once

and reuse them not just in the current project, but in the projects later on. For example, as

we defined the rectangle above, all of the design objects with a rectangular shape can

inherit from rectangle.

We note that while the CD agent developed was tested using an object oriented

design system, the agent is not limited to such systems.

4.3 Design Framework Assumed

Every design agent has public and private information. The focus here is on public

information, which has become part of the central database and thus can be viewed or

used by other design agents. It is each design agent's responsibility to publish up to date

information. This published information is the only source of information used by our CD

agent. Thus the CD agent monitors and analyzes the current status of the design product.

When it finds problems, it will notify involved design agents. It can also notify a conflict

resolution agent, if any. This structure is shown in Figure 4-2.

Conflict RcoIluion






Figure 4-2. Design framework


Following are the assumptions we made about design agents:

1. Each agent will have goals (local goals) for the design of his individual part,
explicit or implicit.

2. Agents are honestly cooperative, concerned with achieving local and global goals.
(Lander, [1997])

3. Agents will give primarily more attention on local goals, and secondarily on
global goals.

4. Agents will focus on one aspect (local goal) at a time, and give significant effort
to do it before going on to the next issue.

5. Each agent maintains internal consistency in his part of the design. There is no
conflict within each individual's part of design.

4.4 Explicit Inconsistent/Incompatible Requirements and Relationships

For detection purposes, product domain conflicts are conveniently divided into

two further categories:

A. Explicit inconsistencies defined by design agents for relationships among

B. Disagreements based on implicit inconsistencies and incompatibilities among
design agents.

Explicit inconsistencies occur when there are logical incompatibilities in

published information.

For example, we suppose statements A, B, C come from different design agents.

Requirements (logically incompatible)

A>B, B>A

Relationship (Incompatible)

A=B, B=C+1, C=A

Requirement & Relationship Incompatible

Relationship: A = B

Requirement: A > 100, B < 50

Unfortunately we do not expect agents to publish the basic relationships of their

work. Thus, although these cases can be detected using basic logic, they are unlikely to be

available to a CD agent. Fortunately however, they also can be expected to lead to

inconsistent values of parameters. In this work, we will thus seek to detect these problems

by consideration of the patterns of values resulting.

4.5 Implicit Inconsistent Requirements and Relationships

Implicit unpublished inconsistency is harder to detect compared to explicit

inconsistency. For example, (1). To evaluate the strength of a structure, different design

agents have different definitions of yield point. (2). In aircraft design, propulsion and

structure designers have different perception of importance of noise from the engine.

Propulsion designer may not have much concern for the noise coming from the engine,

but it may be very important from the structure designer's point of view.

We can only detect conflict based on published information; we do not know

everything in the design system. Most of the assumptions, local requirements and

functional relationships are private to design agents and design agents may even

intentionally keep them in secret. We only know the outputs or results made public in

terms of proposed parameter values. Therefore we must and will detect conflict based on

the patterns of published parameter values.

Note that while most parameters will be the responsibility of only one design

agent, requirements for compatibility between parameters will be expressed in terms of an

interface requirement. For example, I = PA PB which must be less than certain value e

does not belong to either agent. This parameter may belong to an agent at higher level.

4.6 Patterns of Parameter Values

Since patterns of published parameter values will be the basis for our detection,

we next explore possible significant patterns types. Following is a catalog of possible

patterns of parameter values resulting from two design agents. Conflicts involving three

or more agents are not considered. Combinations could also occur. Note that patterns of

values for individual agents are also a source of information.

4.6.1 Disagreement/Do Not Converge

Figure 4-3. Not converge design process

Note that:
+ values are results from agent A making most recent changes in database.
values are results from agent B making most recent changes in database.

Here the value patterns predict a divergent-type of behavior, away from acceptable

values. These are believed to show the most serious potential problems.

4.6.2 Converse to an UnacceDtable Value

Figure 4-4. Converge to an unacceptable value

Although these patterns represent agents reaching an agreement, they predict

failure of the routine design process. Therefore they will be called to agents attention.

They are probably less urgent than cases of diverging values.

4.6.3 Converge toward an Acceptable Value but Predicted to Reach Time Deadline
before Acceptable Value Reached

Figure 4-5. Converge to an acceptable value

Similar to the patterns in Figure 4-4, these patterns also represent agents reaching

an agreement and the design process proceeding in the right direction. However, they

predict failure of the routine design process. Therefore they will be called to agents'

attention too.

4.6.4 Converging to Acceptable Value NOT A CONFLICT


L Value

Acceptable domain + D +
+ +


+ Agent A
Agent B



L Value

1 + + + +
Acceptable doman


+ Agent A
0 Agent B

Oscillation 2

A Value
S+ 0 + +
Acceptable domain + 0 +

+ Agent A
Agent B

Oscillation 1



+ Agent A
Agent B



Figure 4-6. Converge to acceptable value

These patterns are not considered a conflict and will be ignored by CD agent.

4.6.5 Interpretation of Patterns

The goal of conflict detection is to recognize/predict as early as practical pattern

classes associated with conflicts and to notify design agents and/or CR agents in a

satisfactory manner. Next we need criteria for recognizing a conflict and a method for

establishing the priority or seriousness of conflicts detected.

4.7 Conflict Detection

Activity of the conflict detection agent is triggered by the update of design states.

The CD agent tries to learn from the known data and establish an estimation model to

predict future values (Figure 4-7), in particular, the predicted value at the design deadline

is sought. That is, will the value be satisfactory at the end of the design effort (Figure 4-


Figure 4-7. Prediction model

Value A

+ Current Value Deadline

Predicted Value


Figure 4-8. Prediction method

The predicted value is greatly affected by the number of previous points and the

estimation model chosen. If too many or too few previous points are chosen, the model

will not make good predictions. Further, for complex design processes, it is probably not

possible to choose one single estimation model that will be best for all situations. To keep

flexibility in CD agent, we choose the least square method (Zienkiewicz [1989]) which

allows any degree polynomial and any number of previous points. If we take m previous

points to get an estimation polynomial:

V = ao + a0 t + a2t2 + + ant".

Here is the matrix for the calculation ao, a,, ... and a,:

m m m m 0
1=1 =1 1=
m m m m m
z2 t It Z.. y 1 z ,
1=1 z=1 z=1 1=1 "1 ]1

a =

With this method, we can determine the degree of polynomial and the number of

previous points based on the characteristics of the design process; these are not

necessarily the same. We can also adjust our choice through feedback of information

from design agents.

To make this algorithm work for all cases we discussed before, we need to do the

following preprocess. Figure 4-9 shows two examples for case 1 and 3 below.

1. a
VO if Vo > b
V'= b if a < Vo < b
b+(a-Vo) if Vo
2. V > a or V > a

V, {a if Vo>a
Vo if Vo
3. V

V, V0 if Vo >a
a if Vo
Here, V : required value, Vo: original value, V': value after process.


L Value

+ + 0 +

Acceptable domain
a + + +

+ Agent A
0 Agent B
Before process

+ Agent A
Agent B
After process




Acceptable domain

+ Agent A
Agent B
Before process


k Value


Acceptable domain


+ Agent A
0 Agent B

After process

Figure 4-9. Preprocess

When multiple conflicts are present, we want to order them by severity and then

ignore less severe ones if necessary. To compare conflicts involving different parameters

we need to normalize the predicted values. Thus a reference value VRef for each

parameter is sought which allows presentation of different patterns on the same scale

(Figure 4-10). The severity ranking is chosen as proportional to the predicted normalized


+ 0


+(& ,g 104

distance from the acceptable region at deadline. It is hard to find a uniform method to

determine the reference value for all design parameters. For those design parameters

which have a finite acceptable region, the size of the acceptable region is a good

candidate. For those which do not have such constraints, one can use initial value or

average of the first several points. The reference value is subjected to change during the

design process to more appropriate value. Here we assume the existence of a reasonable

reference value for each parameter. We will not study the best way to determine reference


Severity Ranking
V Deadline
VRes Varl


Unacceptable region

... !Time

Figure 4-10. Severity ranking with normalization

Figure 4-11 following shows the procedures used for detection.

Figure 4-11. Conflict detection process

4.8 Notification

Notification concerns the communication between the conflict detection agent and

design agents and/or conflict resolution agent. Based on the detected result, CD agent

sends messages to design agents. The formality of the message, available additional

information, current state of the notified design agent, and how to interact with design

agents are all important issues.

First the notifying message should not be annoying but needs to be sufficiently

aggressive to get designer's attention. It should accurately show the problem and provide

appropriate available information expected to be useful in determining the causes of this


If there are many conflicts detected involving one design agent, a method to

evaluate the severeness of these conflicts is needed. This will also help a CD agent put

more focus on potentially severe/high priority conflicts. Some times solving one or more

conflicts will automatically solve some other conflicts, so what conflicts to show and in

what order to show them are also important.

We seek to make information available to design agents to help them track down

problems and solve the conflict. Therefore we provide design agents with the existing

relationships and history values concerned with the conflict. For example (see Figure 4-

12), assume that an aircraft's initial cost is the sum of all the modules' (cargo, fueltank,

propulsion and structure in the Planeworld model) initial cost. At the current time the cost

exceeds the requirement and it seems unlikely to make it at the deadline. Thus we send all

design agents a message.

i~eqi~emnt I

Pr- e I. ll.:.:. 1:i. 1 1 I II
Fr; i.:l, re J., -:, t [, :.:r] -,r ,:le 111i,-i E 5

hI .i,,_.. ..
'11 :i- 1- 1 '
11)1,) i _F.1i,,1,.ri -- i

1' 1 I1

'i- :!. -|

=!,:, | _ I I
."-',: ., _-* -' I I

H, -n*______________ Tjini
I 1 1 1 1:1 1 I 1 i1, l. .
13'd l 5 1. : .53

i od,.lle FI P rr Ir r 'irreg nr ' ___' |

I1rdl,.:. I
Ih ,,-.:. I
11h111 .:. I
11h,11 .*. I
11,.11 :. I

1: i

Figure 4-12. Notification

Effective notification represents another research problem. This thesis work does

not focus on notification; how to interact with human design agents needs further study.

We focus on conflict detection and seek only to suggest a reasonable form of notification.

IF Iu.-l.: ,


5.1 A Simulation Example

We will examine preliminary, conceptual design of a simplified 2-D cargo

"plane" using the Planeworld simplified design world. See Figure 5-1 below.

Overall Configuration/Aerodynamic Design Team
Cargo Modules/Design Team
FuelTank Modules/Design Team
Propulsion Modules/Design Team
[III Structure Modules/Design Team

Figure 5-1. 2-D "plane"

The plane is composed of four kinds of modules: Cargo module, FuelTank

module, Propulsion module, and Structure module. Other important considerations, such

as control, are intentionally omitted. Every module would be composed of components.

In this example we will not consider component level design.

We use the object-orient method discussed briefly in Chapter 4 to describe design

objects. Here the plane, modules (and components) are all design objects. Every design

object has its own attributes and functions.

Table 5-1. Attributes
Plane InitCost, Weight, CargoWeight, Speed, Range, Area

Aerodynamic Lift, Drag, EffectiveArea, LiftCoeff, DragCoeff

Cargo module InitCost, Weight, CargoWeight, Width, Height, Area
InitCostCoeff, WeightCoeff, CargoWeightCoeff
FuelTank module InitCost, Weight, Fuel, Width, Height, Area
InitCostCoeff, WeightCoeff, FuelCoeff
Propulsion module InitCost, Weight, FuelRate, Thrust, TSFC
ThrustCostRatio, ThrustWeightRatio
Structure module InitCost, Weight, Width, Height, Area
InitCostCoeff, WeightCoeff

TSFC: Thrust-Specific Fuel Consumption

Table 5-2. Functions
Aerodynamic Lift = EffectiveArea x LiftCoeff
Drag = EffectiveArea x DragCoeff
Cargo module Area = Width x Height
InitCost = Area x InitCostCoeff
Weight = Area x WeightCoeff
CargoWeight = Area x CargoWeightCoeff
FuelTank module Area = Width x Height
InitCost = Area x InitCostCoeff
Weight = Area x WeightCoeff
Fuel = Area x FuelCoeff
Propulsion module InitCost = Thrust / ThrustCostRatio
Weight = Thrust / ThrustWeightRatio
FuelRate = TSFC x Thrust
Structure module Area = Width x Height
InitCost = Area x InitCostCoeff
Weight = Area x WeightCoeff

Relationship is the interaction among design objects. We have chosen the

following highly simplified relationships among plane, modules and components in the

model. ( Children.X represents summation of the value X of all the children.)

Table 5-3. Relationships
Plane.Weight = Children.Weight
Plane.InitCost = Children.InitCost
Plane.CargoWeight = Cargo. CargoWeight
Plane.Speed = (Propulsion.Thrust /Structure.Drag) 0.5
Plane.Range=Plane. Speed x (FuelTank.Fuel/Propulsion.FuelRate)
Plane.Area = Structure.Area
Aerodynamic.EffectiveArea = Plane.Area
Cargo.Weight = Children.Weight
Cargo.InitCost = Children.InitCost
Cargo. CargoWeight = Children. CargoWeight
FuelTank.Weight = Children.Weight
FuelTank.InitCost = Children.InitCost
FuelTank.Fuel = Children.Fuel
Propulsion.Weight = Children.Weight
Propulsion.InitCost = Children.InitCost

Propulsion.Thrust = Children.Thrust
Propulsion.FuelRate = Children.FuelRate
Structure.Area = Children.Area
Structure.Weight = Children.Weight
Structure.InitCost = Children.InitCost

A requirement is a constraint which must be met at the completion of the design.

Following are the overall requirements.

Table 5-4. Overall requirements
Cost < 10 million$
Weight < 4,200 lb
Speed > 450 mph
CargoWeight > 50,000 lb
Range > 3000 miles

The Design Process is illustrated below in Figure 5-2. We have five design agents

and a conflict detection agent. The example task is to create an abstract "module level"

design satisfying the requirements.

The example design effort involved independent humans serving as design agents

of the five types listed in Figure 5-2. The simplified airplane design begins in the initial

state shown in Figure 5-3.



ai ra-





Figure 5-2. Design agents used in the example

At the beginning of the design, the requirements on Speed, Range, and

CargoWeight are not met, the requirements on InitCost and Weight are met obviously.

Here the design procedure focuses on trying to meet all the requirements.

E .l" F-dt 1.6 C-- I -lF
D M NI' 'U|ID '..R ,l r| "-' Mx.

I'Al.J -',"1',r'n.r
.j1 ilT li n .I

.'. ,I.Al Tj"e

W**1%,j ':;*C1**. ^ ^^^^
r..i.I F.. IT .I, I I1 1
-, .... Hzr"p.|,l-,,',,,^ ^ ^^ ^

t ,IrIC r ti-.i i : L,'
'1." i.., I.u. ^^^^,.,,e^^^

**i^Mj Ti'i~r'ii 1 4 4^ ^ ^^ ^
".,..%. .7.-.,.- I
..J:..lJ '-.. .. ''-.: fl I

'ii ".. .J-, .- ILJ ..jI
.I'r.:. | lrir J I.'".J.- +. J ^^^BI
.+ *i.-- .i e ,"h II m '.i -- --
/ 1- r.Ll- r r,, -.. H1 4 ^ 1 '. Hh; 1 n l
. :A-,: '.j l .'. .Vl.U FL F.TTJ I


* frdF I w"" 1 U .s'i~
r f "-"ht. p 1 ',"nd f[u
7[3I _, JLinr i,
I r ~

Figure 5-3. Initial design state

5.2 Results

During the design process, all kinds of design patterns discussed in Chapter 4 can

show up and represent certain kinds of conflict. Following are some conflicts detected

during the test design process.

Each design agent has a conflict notification window shown in Figure 5-4. When

there are conflicts detected, conflict messages are added to the list based on the ranking of

conflicts. It uses the normalization method discussed in Chapter 4.

Predicted Value Refrence Value
Severity Rating =Value
Reference Value

I r m [A] -i Ii' ,1. rI''I[ l

Designer can double click on any line of the message to see details of the conflict. Figures

5-5, 5-6, and 5-7 are windows showing the details of a conflict. Each window includes

the history of the parameter and current values of related parameters. Design agents can

also see which other design agents receive the same notification. They can discuss how to

resolve problems when necessary.

P I Cof ictDfiut Noi .- II OFnx
Fdl Edit i_-. H_ .lp

I-: 5:! i 4,} -. :l I l r ll 1
OF -' ..- 5]ssd, -I5.3 e- -

F: e 5.1,

Figure 5-4. Notification window

Figure 5-5, 5-6 show situations where difficulty in meeting problem requirements

is predicted. It is not clear that these are the results of conflicts. However in Figure 5-7

the values of the range parameter following actions by two different designers are

distinctly different and do not appear to be converging, a clear indication that a conflict


Heq~i~ment I

F_- e.l r.,er l ei ait 4l I-I-'I
Pre.di.:re.d al.e .:.l [ .egi\] I .de Idlir.e 5-'i: : .



1-i-il 1 I-

I .
S* *4 IT

1 3 .: '1 1 ". i
1333,- 112-1511

1c.d'.iI~ F- 5r5r;erer Irrizi-ir

* ejI I

* eji I
* c-ni'
* ejI .1

I- -I
1 L.

Figure 5-5. Divergence

F.:,l, i .

F c.i.Tl] i

Heq~i~ment I

Feli. reri.jenl Iil i :. 1 i .1 14 i:
Fre d,-.: ,Iu-. ,1 ,- .:,r [Ira o: :1] Yt 6 1 ,,ir e 11 51.1-1 I-


F .. *ini i -

I', 'llr.,

1 i Ti ri,
1 :'. l '1 ] .:i:

r I d.iI I F'5rarr,, r r I 'i.rre=rir '' l'.i-e

ru: *:-

I'': *: I
I.: *:

ii 4~:'
1 45'T

1 f~

Figure 5-6. Oscillation

1 ~I*IL~.
1..: :fr 1

11~-t~ -t
11: 2~ ~
1i~' i -
ii:1~i ~

1 II~ 1:

F I:,, i

I I1i: I11 .

1 33 ., 1: -- : 1 -_

Heq~i~ment I

F_' F; ...rie O:N:1
Fr e,-d..: -d ali .:.I [F u,_]e ] -b ,- ,-ng -111. :.:.

F, ,.

1 1 :! :

11 1 4 .

1.11 :1

1:1:1:1 :I

Fl brie

F c.~uI. ic-i

S F, II r-i r. cl'rf .r e i F o .eT.r .I *e ir.
* Fc l-: *:.I'.r ii.. I. IF ..l l-.-.'.h r *. -i .lri'el

F. nI_ r.'. .ll __ _, I'" lhr.

I I. I

0 I Ti''
1 1 5 1 : 3 '-F.1 1:1
1333 3 1E 1' 43


F..eIlR l'e

-1A .115.1 1
1 -4 .

43 -

Figure 5-7. Disagreement



The goal of this thesis work is to provide a computational model for supporting a

critical component of cooperative design: the run-time detection and notification of

conflicts. The long-term goal is to support autonomous conflict detection and resolution

among human and machine-based agents. This thesis's implementation has focused on an

important subset of this program, i.e., autonomous detection of cooperative product

domain-level conflicts in routine design, using human agents.

This work has proposed a model of distributed design system that supports

cooperative design and a model of conflict detection in such a cooperative design system.

This generic model can support a wide variety of domains. The distributed design system

model offers many insights into how conflict detection and design agents should operate.

Principally it is concluded that:

A useful available source of information to support CD efforts is the published
values of parameters.

Conflicts among design agents may lead to distinct patterns of parameter

Evaluations of these patterns can identify conflicts.

A software CD agent can monitor these patterns, recognize and rank conflicts,
and notify design agents and/or CR agent.

The software agent developed successfully detects and ranks conflicts
occurring during design in the Planeworld model.


The CD agent is expected to be applicable to other web-based design
environment and tasks.

It is believed that this work represents a significant addition to previous work in

this area.


This chapter will describe the overall structure of Planeworld. Refer to Planeworld

Programmer's guide (Nevill & Zhuang [1999]) for more details.

Planeworld is a web based distributed design system. It involves design of a two

dimensional highly simplified plane by human agents. It also includes a conflict detection

agent, which monitors ongoing design processes and notifies design agents when

conflicts occur. It is written in Visual C++ version 6.0(SP2) with MFC, COM/DCOM to

run in the Windows NT Version 4.0 (SP4) environment.

Planeworld has the following software components: Planeworld Service, Local

Data Service, Project Manager, Relationship, Requirement, Template, Module Design,

Component Design, Conflict Detection, and Messenger. Since design is such a complex

task it is normally divided into subtasks and completed by different design agents. We

have focused on separate components shown in Figure A-i in Planeworld to meet these


Figure A-1. Planeworld software components

We used 3-tier structure in Planeworld shows below. A 3-tier application uses

client/server computing model. The 3 tiers are: (1). The workstation or presentation

interface /Client agents. (2). The mediator /Local services. (3). The database and

programming related to managing it /Server.

Shared Information

Figure A-2. 3-tier structure

With three tiers or parts, each part can be developed concurrently by different

team of programmers coding in different languages from the other tier developers.

Because the programming for a tier can be changed or relocated without affecting the

other tiers, the 3-tier model makes it easier for an enterprise or software packager to

continually evolve an application as new needs and opportunities arise. Existing

applications or critical parts can be permanently or temporarily retained and encapsulated

within the new tier of which it becomes a component. At the same time, The 3-tier

application architecture is consistent with the ideas of distributed object-oriented


We used following object-oriented class hierarchy structure to describe design

objects: product, modules, components.

Figure A-3. Class hierarchy

Each design agent is responsible for certain parts (we call them modules) of a

project. Each module contains components. We define modules and components as

design objects. Following are the modules we defined in Planeworld: Cargo, Fueltank,

propulsion, structure and aerodynamic module.

We used the idea of template to reuse the definition of existing design objects. In

this way, designer agent can describe his/her own design object in a hierarchy structure to

make use of the definitions that already exist.

In Planeworld, we have the following definitions:

Relationship: interactions among design objects.

Requirement: constraints which must be met at the end of the design.

Goal (local or global): an optimal result of the design.

Shared information: make public by design agents to share among
design agents.

We also considered security issues in Planeworld. Each design object has

permission information about who can access this design object. Every design agent has

been granted some permissions.


Deutsch [1973]

Easterbrook [1993]

Findler [1995]

Fleischer [1997]

Harrington [1995]

Harrington [1996]

Hu [1996]

Klein [1989]

Klein [1990]

Klein [1991]

Deutsch M. The resolution of conflict: Constructive and
Destructive Processes. New Haven: Yale University Press 1973

S. M. Easterbrook, E. E. Beck, J. S. Goodlet, L. Plowman,
M. Sharples, C. C. Wood, A Survey of Empirical Studies of
Conflict, CSCW: Cooperation or Conflict? New York: Springer-
Verlag 1993

Nicholas V. Findler, Gregory D. Elder, Multiagent
Coordination and Cooperation in a Distributed Dynamic
Environment with Limited Resources,Artificial Intelligence in
Engineering Vol. 9 (1995), p229-238

Mitchell Fleischer, Jeffrey K. Liker, Concurrent Engineering
Effectiveness: Integrating Product Development Across
Organizations. Cincinnati: Hanser Gardner Publications 1997

John V. Harrington, Hossein Soltan, Mark Forskitt,
Negotiation in a Knowledge-Based Concurrent Engineering Design
Environment, Expert Systems Vol. 12 No. 2 (May 1995), p139-147

John V. Harrington, Hossein Soltan, Mark Forskitt,
Framework for Knowledge Based Support in a Concurrent
Engineering Environment,Knowledge-Based Systems Vol. 9
(1996), p207-215

Y. Hu, P. Liu, Y. Yan, D. Zheng, C. Ma, J. Bode, S. Ren, A
Multiagent System for the Support of Concurrent Engineering,
IEEE (1996), p959-964

Mark Klein and S.C.-Y.Lu, Conflict resolution in cooperative
design, Artificial Intelligence in Engineering, Vol. 4 No. 4 (1989),

Mark Klein, Conflict Resalution in Cooperative Design,
Ph.D. dissertation, Univ. Ill., Urbana-Champaign, Jan. 1990

Mark Klein, Supporting Conflict Resolution in Cooperative


Lander [1997a]

Lander [1997b]

Lin [1996]

Matta [1996]

Pena-Mora [1993]

Petrie [1995]

Pruitt [1981]

Rich [1991]

Sycara [1991]

Werkman [1991]

Design Systems, IEEE Transactions on Systems, Man. and
Cybernetics, Vol. 21 No. 6 (November-December 1991), pl379-

Michael Knapik, Jay Johnson, Developing Intelligent Agents for
Distributed Systems, New York: McGraw-Hill.

Susan E. Lander, Issues in Multiagent Design Systems,IEEE
Expert March-April 1997, p 18-26

Susan E. Lander, R. Lesser, Sharing Metainformation to
Guide Cooperative Search among Heterogeneous Reusable Agents,
IEEE Transactions on Knowledge and Data Engineering Vol. 9
No. 2 (March-April 1997), p193-208

J. Lin, M. S. Fox, T. Bilgic, A Requirement Ontology for
Engineering Design, Concurrent Engineering: Research and
Applications, Vol. 4 No. 3 (September 1996), p 279 291

Nada Matta, Conflict Management in Concurrent Engineering:
Modeling Guides, Proceeding in Conflicts in AI Workshop, ECAI,
Budapest, 1996

Feniosky Pena-Mora, Duvvuru Sriram, Robert Logcher,
Design Rationale for Computer-Supported Conflict Mitigation,
Journal of Computing in Civil Engineering Vol. 9 No. 1 (January
1995), p57-72

C. J. Petrie, T. A. Webster, M. R. Cutkosky, Using Pareto
Optimality to Coordinate Distributed Agents,AIEDAM, Special
Issue on Conflict Management in Design Vol. 9 No. 4 (September
1995), p 269 282

D.G. Pruitt, Negotiation Behavior, New York: Academic Press,

E. Rich, K.Knight, Artificial Intelligence, 2nd ed., New York:
McGraw-Hill 1991

K. P. Sycara, Cooperative Negotiation in Concurrent Engineering
Design, Computer Aided Cooperative Product Development,
Proceedings of MIT-JSME Workshop. D. Sriram, R. Logcher, S.
Fukuda (eds.), Cambridge, MA: MIT Press, 1991

Keith J. Werkman, Negotiation as an Aid in Concurrent


Engineering, Issues in Design Manufacture/Integration, DEVol. 39
(1991), p23-30

Zienkiewicz [1989] O.C. Zienkiewicz, R.L. Taylor, The Finite Element Method, 4th
ed., New York: McGraw-Hill, 1989


Ruiqiang Zhuang was born and grew up in The People's Republic of China. After

studying engineering mechanics at Tsinghua University he came to USA to pursue

graduate studies at University of Florida.