close

Вход

Забыли?

вход по аккаунту

;docx

код для вставкиСкачать
Monitoring and Synchronization for Teamwork in GPGP
Sherief Abdallah
Nevin Darwish
Osman Hegazy
Computer Science Dept.
Faculty of Computers and
Information
Cairo University, Egypt
Computer Engineering Dept.
Faculty of Engineering
Cairo University, Egypt
Information Systems Dept.
Faculty of Computers and
Information
Cairo University, Egypt
[email protected]
[email protected]
ABSTRACT
This paper addresses the problem of oordinating a group
of agents involved in a team. To ahieve exible teamwork, agents should synhronize their work and monitor
their performane to avoid redundant work. Generalized
Partial Global Planning (GPGP) is one of the most ommon
tehniques used in oordinating ooperative agents, however, no tehnique is without limitations. Our work adopts
some onepts of STEAM to overome some of GPGP limitations. In partiular, we suggest adding oordination mehanisms to GPGP and extending TAEMS, the model underlying GPGP, to failitate suh mehanisms. The work has
suessfully been implemented using JAF arhiteture. The
oordination mehanisms are written as Soar rules where we
implemented a JAF omponent that implements the Soar
engine. Analysis of a ase study is presented along with
experimental results to illustrate the power of the proposed
work.
Categories and Subject Descriptors
H.4.m [Information Systems℄: Misellaneous
General Terms
Algorithms, Design, Reliability, Languages
Keywords
Coordination, Teamwork, GPGP, STEAM, SOAR
1.
INTRODUCTION
The need to oordinate dierent agents in order to redue
redundant work, maximize utilization of shared resoures,
inrease reliability of the system and enhane harateristis
of the overall solution is one of the main issues of multi-agent
systems researh. Cooperative agents have shared goals that
they plan to ahieve. Generalized Partial Global Planning
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SAC 2002 Madrid, Spain
Copyright 2002 ACM 0-58113-445-2/02/03 ... 5.00.
$
[email protected]
(GPGP) [3℄ is one of the tehniques that provide oordination among ooperative agents. It onsists of modular oordination mehanisms that use TAEMS model (Task Analysis, Environment Modeling, and Simulation) [2℄ to reason
about the environment. The result of oordination is a set
of ontrainsts that modulate the operation of the agent's
loal sheduler. However, the GPGP mehanisms do not
address speial oordination needs in ase of agents forming expliit teams. Tambe argued that to obtain exibility
and reliability in teamwork, expliit teamwork modeling is
required [11℄. His implemented teamwork model, STEAM,
implements a hybrid of joint intentions [4℄ and SharedPlan
theories [9℄.
In this work we suggest adding several oordination mehanisms, whih implement some of the onepts introdued
in STEAM, to GPGP. Some modiations of some of the
GPGP standard mehanisms are also proposed. These extensions ause better synhronization between team members and redue redundant teamwork. Throughout this paper we will use a simple ase study for illustration, the Attak City domain. It is required to attak a ity by an army
onsisting of two teams: air team with N members, and
ground team with M members. The attak has two forms:
air attak and ground attak. Air attak is undertaken by
the air team. The air attak mission onsists of three subtasks: y to ity, attak ity military points, and nally
return bak to base. Ground attak is undertaken by the
ground team and is divided into two subtasks: move to ity,
and takeover ity. Air attak failitates the mission of the
ground team by eliminating muh of possible resistane (i.e.
air attak should omplete before the start of ground attak
to inrease ground attak probability of suess; however,
the ground team might start its attak before air attak
ompletion with more risk).
In the following setions we takle this ase study using
both GPGP and STEAM frameworks, illustrating the main
limitations of eah. Setion 2 presents an overview of GPGP
and its underlying model, TAEMS followed by some of its
limitations. Setion 3 desribes briey STEAM framework
along with its main limitations. Implemented extensions
to GPGP are disussed in setion 4. Empirial results are
presented in setion 5 followed by the onlusion and future
work diretions.
2. GPGP
GPGP denes a set of modular oordination mehanisms
using a domain independent model, TAEMS. These mehanisms an be used in any ombination depending on the
domain of onern. The next subsetions desribes briey
TAEMS and GPGP mehanisms along with their limitations.
2.1 TAEMS
TAEMS model is omposed of tasks and subtasks organized in a task struture hierarhy (also alled task group ).
The leaves of the hierarhy are the methods, whih are exeutable ations. Eah method is haraterized by three dimensions: duration, ost, and quality. Duration is the time
spent exeuting the method. Cost represents the penalties
of exeuting the method. Quality is an abstrat measure to
quantify the suess of the method. Unertainty of the three
dimensions is modeled through disrete probability distributions. Tasks onsist of subtasks. Quality aumulation
funtions (QAFs) dene how the qualities of subtasks relate
to the super task quality, e.g., q sum QAF means the quality of the super task is the summation of subtasks' qualities.
Tasks are linked by interrelationships (also alled non-loal
eets ) that model interdependenies between tasks [2, 7,
8℄. Figure 1 shows a simplied TAEMS model for Attak
City domain. Tasks are shown as rounded edge retangles
(e.g. attak ity) while methods are shown as retangles (e.g.
y 1). QAFs are indiated below tasks' rounded retangles
(e.g. Attak City task has q max QAF). Two types of nonloal eets are shown, failitates (e.g. the dashed arrow
from Air Attak task to Ground Attak task), and enables
(e.g the solid arrow from Fly to City to Attak Targets).
Enables interrelationship means that aeting task (soure
of the arrow) must omplete suessfully before the start
of the aeted task (destination of the arrow). Failitates
means it is advantageous for the aeting task to omplete
before the start of the aeted task though not neessary.
Attack_City
Enables
Facilitates
Air_Attack
Fly_to_City
Fly_1
Fly_N
Ground_Attack
Attack_Targets
Attack_1
Attack_N
Return_to_Base
Return_1
Return_N
Move_to_City
Move_1
Move_N
Takeover_City
Takeover_1
Takeover_N
Figure 1: TAEMS model for Attak City domain
2.2 Coordination Mechanisms
Based on TAEMS model ve oordination mehanisms
were dened. The purpose of these oordination mehanisms is to reognize tasks' interdependenies and reate
orresponding ommitments and onstraints, whih in turn
is passed to the loal sheduler to produe globally better
shedules [3, 7℄. The rst mehanism deals with exhanging private views in order to onstrut a more global view.
The seond mehanism handles simple redundany where a
task's quality is the maximum of its subtasks' qualities and
these subtasks are also methods. Third mehanism takles
results exhange. Fourth and fth mehanisms reate ommitments in response to the presene of interrelationships
(mainly enables and failitates).
2.3 Limitations of GPGP
The main limitations of GPGP are as follows:
Representing the ontribution of eah member (agent),
in a given team task, by a subtask is inonvenient for
large teams onsisting of hundreds and even thousands
of agents (e.g. the number of leaves in gure 1 grows
as number of members per team inreases).
TAEMS does not provide an expliit way to express
ahievement of tasks performed by teams. For instane, for the subtask attak targets, it might be sufient to suessfully destroy 70% of the targets. The
lak of apability of expressing ahievement onditions
of overall team task might result in team members trying to omplete their part in an already ahieved task.
Predened GPGP mehanisms neither support synhronization of team members nor handle teamwork
redundany. Miss-synhronizing team members may
ause severe penalties on teamwork. For instane, if
an air agent started ying to ity without making sure
that other air agents also started ying to ity, there
is a large threat that the impatient air agent will be
destroyed. Redundany in teamwork is essential and
is required all through the exeution of the team task,
and until the suessful ompletion of the team task.
In GPGP, redundany avoidane ours before starting the exeution. Moreover, this simple mehanism
deals with tasks having QAF max, i.e. only one subtask is neessary. In teamwork domains, redundany
is observed in tasks with QAF sum, i.e. eah subtask
(ontrolled by a member of the team) ontribute somehow to the overall team's task and as more subtasks
sueed, the quality of the team task inreases.
3. STEAM
STEAM assumes the presene of a ommon team plan
shared by members of the team. The plan is presented as
a hierarhy of operators. Figure 2 shows operator hierarhy
for the Attak City domain. The key novelty of STEAM is
the introdution of team operators. Team operators dene
operators that should be performed by a team not individuals. These operators require speial treatment in that members must synhronize before starting exeution and one
synhronized a member an not stop exeuting the operator until ensuring mutual, synhronized termination for all
members. This is done through establishing a ommitment
protool. A team task is onsidered terminated if it is believed to be ahieved, unahievable, or irrelevant. STEAM
attah termination onditions, whih when evaluates to true
the team task is believed to be terminated. Main limitations
of STEAM are as follows:
Roles relationships, introdued in STEAM, provide
limited expressiveness. For instane, partial ordering
between y to ity and attak targets subtasks (y to
ity preedes attak targets) an only be modeled impliitly in the preonditions of the team operators:
y to ity and attak targets.
Unertainty is not modeled expliitly exept for ommuniation. This limits the agents' ability to reason
about 'risky' alternatives that might, exeptionally,
lead to great advantages.
Reative nature of this model provides exibility in
responding to unexpeted events. However, it is not
straightforward to use this model in reasoning about
temporal onstraints (deadlines, earliest start time,
et.) in a straightforward way.
The establish ommitments protool oordination ost2
(ommuniation and proessing) is proportional to
where n is number of agents in a team. This disadvantage is more severe for domains using point to point
ommuniation.
Attack_City
:::
n
Enables
Facilitates
Air_Attack
Ground_Attack
Fly_to_City
Attack_Targets
Return_to_Base
Move_to_City
Takeover_City
fly
templ
attack
templ
return
templ
move
templ
takeover
tmpl
Figure 3: TAEMS model fo Attak City domain with
[Attack_City]
templates introdued
[Air_Attack] *
[Fly_to_City]
[Attack_Targets]
Fly
Figure 2:
[Ground_Attack] *
Return_to_base
Attack
[Move_to_city]
Takeover_City
Move
STEAM operator hierarhy for Attak
City domain
4.
PROPOSED EXTENSIONS TO GPGP
It is noted that GPGP solves most of STEAM limitations. First, the GPGP framework is more expressive in
desribing interdependenies between tasks than STEAM.
Seond, TAEMS provides an expliit model of unertainty
(through probability distributions of quality, duration, and
ost), whih enables agents to reason about risky tasks having high prots, against safe tasks with lower prots. Third,
in GPGP agent's ations are sheduled, enabling agents to
reason about duration and imposed deadlines. Hene, we
have hosen the GPGP framework as the basis of our work.
We present some extensions to GPGP mehanisms and its
underlying TAEMS model, and then give a brief overview
of our implemented agent arhiteture.
4.1 TAEMS Extensions
The proposed extensions to TAEMS are two: modeling
organizational information and dening monitoring onditions.
4.1.1 Modeling Organizational Information
TAEMS speiation [8℄ does not provide a ompat way
of representing teams and the ontribution of eah team
member in a team task (rst limitation). We suggest a new
TAEMS objet, template. A template is any TAEMS objet
dened over a whole team not only a single agent. In general, this extension drops the number of objets required to
dene a task struture to a xed number of templates. For
example, in task y to ity, eah agent ontributes by
exeuting his method Fly i. A template Fly tmpl replaes
methods Fly 1, , and Fly N. As shown in gure 3 the
number of nodes at the lowest level in the task hierarhy
has dropped from (3 + 2 ) to only 5 nodes. Method
templates are shown as irles .
Ai
:::
N
M
4.1.2 Defining Achievement and Unachievability Conditions for Team Tasks
TAEMS speiation does not dene onditions of ahievement and/or unahievability for a task. In standard TAEMS,
there is only one (impliit) ahievement ondition applied
to all tasks: task quality is greater than zero. However,
TAEMS still provides us with abstrat measures (referred to
afterwards as monitoring terms ) that an be used to speify ahievement and/or unahievability onditions of a team
task, suh as:
Expeted distributions1 of quality, duration, ost, start
time and nish time.
Unertainty represented in probability distributions of
quality, duration, ..et.
Current (atual) values of quality, duration, ost, start
time and nish time.
For example, the following ondition speies that a task
T is unahievable if average expeted quality is less than
100, average expeted ost greater than 10 and probability
that T misses deadline is greater than 0.7: [q(T) < 100 AND
(T) > 10 AND p(ft(T)>dl(T)) > 0.7℄ where q(T) and (T)
are average expeted quality and ost (respetively) of task
T , ft(T) is expeted distribution of nish time of T, dl(T)
is deadline onstraint over T.
This lear and formal denition of monitoring terms an
be ontrasted to the approah used in STEAM where monitoring onditions an be of any form. The lak of formal definition degrades the reusability of oordination mehanisms
that respond to a spei monitoring ondition. For instane, we an dene a oordination mehanism that warns
team members when the probability that their team task
beomes unhaievable goes above 0.6.
4.2 GPGP Extensions
We suggest three extensions to GPGP mehanisms: a new
synhronization mehanism, a new monitoring framework,
and modifying the "ommuniate results" existing mehanism. We have implemented the three suggested extensions.
4.2.1 Adding Synchronization mechanisms
We added a new GPGP mehanism to ensure synhronization between team members, whih is based on establish ommitments protool (ECP). Figure 4 shows part of
the protool as a nite state mahine. It is noted that the
omplete protool has two roles: the team leader and a normal member of the team. There is a similar mehanism for
terminating team tasks. Apparent from gure 4 the leader
role is ritial (in synhronization and other mehanisms);
hene we added a reovery mehanism that detets leader
1
The expeted probaility distribution given the urrent beliefs of the agent (e.g. shedules, ommitments, et.)
:::
failure (using timeouts) and replaes the failing leader with
a funtioning agent (aording to a stati leadership hierarhy).
EC P c o n firm a t io n m e s s a g e re c ie v e d
/ in c re m e n t n u m b e r o f c o n firm e d m e m b e rs
s t a rt o f a te a m t a s k
S0
/ s e n d EC P in it ia tio n m e s s a g e
t o th e m e m b e rs M o f t e a m Θ
a n d w a it fo r c o n firm a tio n
a n d s e t t im e r
S1
a ll m e m b e rs
c o n firm e d
S2
t im e o u t
/ m a rk n o n c o n firm in g a g e n ts a s n o n fu n c t io n a l
Figure 4: FSM representing leader role in joint ommitment protool
4.2.2 Adding Monitoring Framework
We also added a monitoring framework to monitor team
task termination. One an agent believes either its team has
ahieved the urrently exeuting task or the urrently exeuting task is unahievable, the agent terminates its part of
it. Our monitoring framework diers from STEAM's monitoring framework in the use of monitoring terms. It should
be noted that we did not implement reovery mehanisms
introdued in STEAM. Currently, one an agent reognizes
the task is unahievable it terminates it and goes on exeuting any remaining, ahievable task. We plan to add a
omprehensive reovery apability in the future.
4.2.3 Modifying Communicating Results
In GPGP seond mehanism for ommuniating results,
eah aeting agent (ommitted to exeute an aeting task)
is responsible for ommuniating results to eah aeted
agent (exeuting an aeted task). For instane, for the
attak targets task eah air agent is responsible for ommuniating the suess (or failure) of his mission to:
Eah air agent, due to the enables interrelationship
between attak targets and return to base, resulting
in 2 messages.
Eah ground agent, due to the failitates interrelationship between air attak and ground attak, resulting
in messages.
We took advantage of the teams' organization and modied the mehanism suh that only the leader ommuniates
results on behalf of his team to aeted agents that are not
members of the team (members of the team have the same
knowledge of the team leader). So in the Attak City ase
study, eah air agent will be responsible for ommuniating
the suess (or failure) of its mission to eah air agent,
due to
being member of the air team, still resulting in 2 messages.
However, only the leader of the air team is responsible for
ommuniating the results of the air attak task, after its
termination, to eah ground agent, resulting in messages
instead of 3 messages.
N
M
N
the new ontrainsts), the ommuniation omponent (to enable agents to ommuniate together),
et. We implemented a oordination omponent, whih provides basi
funtionality for oordination mehanisms through a ommon substrate. Coordination mehanisms themselves are
implemented as Soar rules [6℄. Reent work, namely GPGP2
[12℄, implemented this substrate as a Finite State Mahine
engine. Coordination mehanisms were dened in terms of
nite mahine sripts that is parsed and ompiled and linked
to the substrate java ode. We took a ompletely dierent
approah. Our oordination substrate enapsulates a Soar
[6℄ ompiler and run-time engine. This provides more exibility as oordination mehanisms an be written in the form
of prodution rules. Furthermore, ahing of partial mathing results is supported (through RETE network). This partiular property is important to failitate the monitoring of
ahievement and unahievability onditions, whih is ontinually hanging throughout the exeution. Figure 5 shows
the anatomy of the module. A brief desription of eah omponent of the module is given below.
Soar Engine. This is the ore of the oordination module. It implements Rete network algorithm [10℄ and
the Soar arhiteture. Coordination mehanisms are
written as Soar prodution rules that is ompiled and
exeuted by our implemented engine. More details
about our implementation an be found in [1℄.
Soar/Java Translator. This omponent translates data
strutures from java lasses to the orresponding Soar
working memory elements (WMEs) and vie versa. It
is used whenever a data struture should be transferred
to/from the Soar engine.
Message Listener. This omponent allows oordination rules (mehanisms) to register the message header(s)
they are interested in. This is important to avoid
translating unimportant messages. When a message
with a registered header is reeived, the message is
translated and passed to the Soar Engine.
Property Listener. Through this omponent, oordination mehanisms an register the names of the properties they are interested in. Whenever a registered
property is added, hanged, or removed, the event is
translated and passed to the Soar Engine.
Command. The ommand omponent enapsulates interfae with other JAF omponents. When a Soar rule
requires to shedule a task struture, terminate urrently exeuting ation, et. it asks the Command
omponents.
:::
:::
S o a r P r o b le m S o lv e r
N
M e s s a ge
L is te n e r
S o a r /J a v a tr a ns la to r
M
M
N
4.3 Implementation
We used JAF [5℄ framework as basis for our implementation. We used some of the standard JAF omponents,
e.g. the sheduler omponent (to shedule the tasks given
P r o p e r ty
L is te n e r
C o m m a nd
r e g is t e r
m e s sa ge
r e c e iv e d
S o a r E ng in e
C o o r d in a t io n
R u le s
r e g is t e r
p r o p e r ty c h a n g e d
/a d d e d /r e m o v e d
Figure 5: Components of the oordination module
5.
RESULTS
In our results we explore the relationships between unertainty and teamwork misoordination. Three oordination
approahes that rely on the GPGP framework are onsidered. In the rst approah, both the monitoring framework
and the synhronization mehanism are disabled. The seond approah is same as the rst approah but with the synhronization mehanism added. The third approah, whih
is our proposed approah, has both, the synhronization
mehanism and the monitoring framework, enabled. Using the Attak City ase study, the three approahes were
tested under dierent degrees of unertainty (to be desribed
shortly) and at dierent team sizes. For eah ombination
(team size and degree of unertainty) 10 simulation runs
were exeuted and averaged to ompute dierent measures.
First we will dene two terms: degrees of unertainty and
teamwork miss-synhronization. Next we present the results, whih ensure the need for a monitoring framework in
addition to synhronization.
5.1 Degrees of Uncertainty
In TAMES, unertainty is modeled through the probability distributions of quality, ost, and duration. We will fous
our attention on duration unertainty as one of the major
auses of teamwork misoordination. We tested dierent oordination approahes against four duration distributions:
Distribution : P(5)=1 (i.e. the probability that the
method duration takes 5 time units equal 1)
Distribution : P(4)=0.9 and P(14)=0.1
Distribution : P(4)=0.8 and P(9)=0.2
Distribution : P(3)=0.5 and P(7)=0.5
We deliberately adjusted eah distribution suh that the
average duration remains onstant, 5, to fous attention on
the unertainty.
A
B
( )=1
X ( )
ni
C Sij
()
This measure is domain independent ompared to atual
penalties imposed on miss-synhronized team, whih is domain spei.
T M SM Ti
j =1
C
5.3 Lower Teamwork Miss-Synchronization
Figure 6 shows average TMSM when synhronization mehanism is disabled (original GPGP). Average TMSM is plotted against number of agents per team and for dierent degrees of unertainty. Generally, the unertainty dereases
from degree D down to degree A. The urve
shows
the maximum miss-synhronization (when all agents start
as one team and end up with eah agent onsitituting a
seperate subteam). As expeted, as number of agents inreases, TMSM inreases. It is less probable that all agents
start a team task at the same time as number of agents inreases. This observation beomes more evident from gure
7, whih shows the average possibility (without expliit oordination) that all members of a given task start/terminate
their team task at the same time. In addition, an early
miss-synhronization will, usually, ause subsequent misssynhronization in following team tasks (hene inreasing
the overall average TMSM). The urve plotted for degree
of unertainty D is the losest to the upper bound (
urve), onrming that as unertainty inreases TMSM inreases. With synhronization mehanism enabled, TMSM
drops to zero assuming reliable ommuniation.
M AX
M AX
C
D
5.2 Teamwork Miss-Synchronization
In order to evaluate teamwork oordination mehanisms,
we need to dene a measure of teamwork miss-synhronization.
Previous work of Tambe did not dene formal measure of
teamwork miss-synhronization (Tambe foused on ommuniation osts). We propose below a salar measurement for
teamwork miss-synhronization (TMSM) based on heuristis.
Teamwork miss-synhronization ours when members
of team either start or terminate a team task at dierent times. In other words, split into subteams 1 2
where is the number of subteams for . Funtion ()
returns ardinality of a team (number of members). The
proposed measure,
( ), should satisfy the following
riteria for two tasks 1 and 2 performed by same team :
If = 1 then
( )=0
If 1 2 then
( 1)
( 2)
If 1 = 2 = , and 9 1 suh that 8 1 ( 1 ) ( 2 ) then
( 1)
( 2)
We dene our measure of teamwork miss-synhronization
for task Ti to be:
Figure 6: TMSM without synhronization
M
Ti
Si ; Si ; :; Sini
ni
Ti
C
T M SM Ti
T
ni
n
T
T M SM Ti
> n
n
n; C S i
T M SM T
n
n
> C S j
Figure 7:
Probability of joint start/termination
without synhronizing
> T M SM T
S i
T M SM T
j;
j
< T M SM T
5.4 Lower Average Execution Time
Figure 8 shows average exeution time per method divided by mean (for normalization) and ompares the three
approahes under degree of unertainty D. In this degree
of unertainty, 50% of the time the task takes 3 yles, i.e.
the agent nishes early. In the other 50%, the agent nishes late. By exeution time we mean the time interval
sine an agent starts exeuting a method in servie of a
team task and until the same agent believes the team task of
servie has ompleted. We ignored ommuniation lateny,
whih is negligible ompared to methods duration (ying to
a ity, returning to base, et.). For our approah (with
synhronization and monitoring enabled) a xed ahievement ondition is used, team-task quality 9. We modeled eah agent's ontribution by 5 quality units; hene at
least two agents must omplete the task before onsidering
it ahieved. As expeted, as number of agents per team
inreases, redundany inreases and hene our proposed approah shows more savings (it beomes more likely that two
members of the team nishes early). With only synhronization mehanism enabled, average exeution time inreases as
number of agents inreases. This is mainly beause agents
that nish early must wait for slower agents to nish. Using
only the GPGP's original mehanism (with no synhrnization or monitoring), average exeution time is independent
of the number of agents. This is beause agents are independent from eah other. The upper limit of the average
exeution time is 1.4, whih is the maximum possible duration of a method, 7, divided by the expeted duration, 5.
Similarly, the lower limit of the average exeution time is
0.6, whih is the minimum possible duration of a method,
3, divided by the expeted duration, 5.
:::
For large teams with hundreds of members, salability
is a key issue. It is lear from the experiments that imposing a hierarhial organizational struture over TAEMS
task struture is essential to ope with omplexities. While
the presented framework supports hierarhial organization
of teams and subteams, we aim at testing our framework in
large variety of domains to measure the generality, exibility, and reusability of our framework.
ge
Figure 8: Average exeution time for the three approahes
5.5 Conclusion
This work illustrates how GPGP and its underlying model,
TAEMS, an be used to reason about teamwork. It takes
STEAM as an example of teamwork oriented oordination
framework, then illustrates how GPGP along with TAEMS
an be extended to provide same apabilities. The implemented oordination module substrate supports rule-based
oordination mehanisms, thus providing more exibility in
the design of oordination mehanisms. A new GPGP mehanism has been added to support synhronization between
team members. We also proposed extensions of TAEMS to
expliitly support ahievement and unahievability onditions of tasks and implemented a framework supporting it
to monitor team tasks performane.
While ahievement and unahievability onditions are originally used for reognizing the termination of a task, how
these onditions aet the sheduler performane is an interesting area of future work. Normal shedulers unaware of
these onditions might prefer shedules that are unahievable from the start. This triggers the need for more exible
shedulers.
6. ADDITIONAL AUTHORS
Additional authors: Ihab Talkhan (Computer Eng. Cairo
University, email: ihatalpha1-eng.airo.eun.eg).
7. REFERENCES
[1℄ S. Abdallah. Soar2Java pakage. World Wide Web,
http://www.geoities.om/sharios/soar.htm, 2000.
[2℄ K. Deker. Environment Centered Analysis and Design
of Coordination Mehanisms. Ph.D. thesis, University
of Massahusetts, 1995.
[3℄ K. Deker and V. Lesser. Designing a family of
oordination algorithms. In ICMAS, 1995.
[4℄ B. Grosz and S. Kraus. Collaborative plans for
omplex group ations. Artiial Intelligene,
86(2):269{357, 1996.
[5℄ B. Horling. A Reusable Component Arhiteture for
Agent Constrution. M.S. thesis, University of
Massahusetts, 1998.
[6℄ J. Laird, A. Newell, and Rosenbloom. Soar: An
arhiteture for general intelligene. Artiial
Intelligene, 33(1):1{64, 1987.
[7℄ V. Lesser and et al. Evolution of GPGP Domain
Independent Coordination Framework. Tehnial
Report 1998-5, University of Massahusetts, 1998.
[8℄ V. Lesser and et al. TAEMS White Paper. World
Wide Web,
http://mas.s.umass.edu/researh/taems/white/,
1998.
[9℄ H. Levesque and et al. On ating together. In
AAAI-90, Boston, MA, 1991.
[10℄ P. Nayak and et al. Comparison of the rete and treat
prodution mathers for soar. In AAAI-88, pages
693{698, 1988.
[11℄ M. Tambe. Towards exible teamwork. Artiial
Intelligene Researh, 7:83{124, 1997.
[12℄ T. Wagner and et al. Investigating Interations
Between Agent Conversations and Agent Control
Components. Tehnial Report 1999-7, University of
Massahusetts, 1999.
1/--страниц
Пожаловаться на содержимое документа