Das Doc

7/31/2019 Das Doc

1/17

2012

Arindam Sarkar(20081010)

University Institute Of

Technology,Burdwan Universit

/ /

Distributed Agent System

Seminar Report

7/31/2019 Das Doc

2/17

1.Introduction

1.1 Distributed agent systems and

distributed AI

The modern approach to artificial intelligence (AI) is centered around

the concept of a rational agent. An agent is anything that can perceive

its environment through sensors and act upon that environment through

actuators (Russell and Norvig, 2003). An agent that always tries to opti-

mize an appropriate performance measure is called a rational agent. Such a

definition of a rational agent

is fairly general and can include human agents(having eyes as sensors, hands as actuators), robotic agents (having cam-

eras as sensors, wheels as actuators), or software agents (having a graphical

user interface as sensor and as actuator). From this perspective, AI can

be regarded as the study of the principles and design of artificial rational

agents.

However, agents are seldom stand-alone systems. In many situations

they coexist and interact with other agents in several different ways. Ex-

amples include software agents on the Internet, soccer playing robots (see

Fig. 1.1), and many more. Such a system that consists of a group ofagents

that can potentially interact with each other is called a Distributed agent

system (DAS), and the corresponding subfield of AI that deals withprinciples and design ofDistributed systems is called distributed AI.

1.2 Characteristics of Distributed systems

What are the fundamental aspects that characterize a DAS and distinguish it from a

single-agent system? One can think along the following dimensions:

7/31/2019 Das Doc

3/17

Figure 1.1: A robot soccer team is an example of a Distributedsystem.

Agentdesign

It is often the case that the various agents that comprise a DAS are designed

in different ways. A typical example is software agents, also called softbots,

that have been implemented by different people. In general, the design dif-

ferences may involve the hardware (for example soccer robots based on dif-

ferent mechanical platforms), or the software (for example software agents

running different operating systems). We often say that such agents are het-

erogeneous in contrast to homogeneous agents that are designed in an

identical way and have a priori the same capabilities. However, this distinc-

tion is not clear-cut; agents that are based on the same hardware/software

but implement different behaviors can also be called heterogeneous. Agent

heterogeneity can affect all functional aspects of an agent from perception

to decision making, while in single-agent systems the issue is simply nonex-

istent.

Environment

Agents have to deal with environments that can be either static (time-

invariant) or dynamic (nonstationary). Most existing AI techniques for

single agents have been developed for static environments because these areeasier to handle and allow for a more rigorous mathematical treatment. In

a DAS, the mere presence of multiple agents makes the environmentappear

dynamic from the point of view of each agent. This can often be problematic,

for instance in the case ofconcurrently learning agents where non-stable

behavior can be observed. There is also the issue which parts of a dynamic

environment an agent should treat as other agents and which not.

7/31/2019 Das Doc

4/17

Perception

The collective information that reaches the sensors of the agents in a DAS

is typically distributed: the agents may observe data that differ spatially

(appear at different locations), temporally (arrive at different times), or evensemantically (require different interpretations). This automatically makes

the world state partially observable to each agent, which has various con-

sequences in the decision making of the agents. An additional issue is sensor

fusion, that is, how the agents can optimally combine their perceptions in

order to increase their collective knowledge about the current state.

Control

Contrary to single-agent systems, the control in a DAS is typically dis-

tributed (decentralized). This means that there is no central process that

collects information from each agent and then decides what action each agentshould take. The decision making of each agent lies to a large extent within

the agent itself. The general problem ofDistributed decision making is the

sub ject of game theory. In a cooperative or team DAS1, distributed

decision making results in asynchronous compu- tation and certain

speedups, but it also has the downside that appropriate coordination

mechanisms need to be additionally developed. Coordina- tion ensures

that the individual decisions of the agents result in good joint decisions for

the group.

Knowledge

In single-agent systems we typically assume that the agent knows its own actions but

not necessarily how the world is affected by its actions. In a DAS, the levels of

knowledge of each agent about the current world state can differ substantially. For

example, in a team DAS involving two homogeneous agents, each agent may know

the available action set of the other agent, both agents may know (by communication)

their current perceptions, or they can infer the intentions of each other based on some

shared prior knowledge. On the other hand, an agent that observes an adversarial team

of agents will typically be unaware of their action sets and their current perceptions,

and might also be unable to infer their plans. In general, in a DAS each agent must

also consider the knowledge of each other agent in its decision making. A crucial

concept here is that ofcommon knowledge, according to which every agent

knows afact, every agent knows that every other agent knows this fact, and so on.

7/31/2019 Das Doc

5/17

Communication

Interaction is often associated with some form ofcommunication. Typ- ically we view

communication in a DAS as a two-way process, where all agents can potentially be

senders and receivers of messages. Communica- tion can be used in several cases, for

instance, for coordination among cooperative agents or for negotiation among self-

interested agents.Moreover, communication additionally raises the issues of what

network protocols to use in order for the exchanged information to arrive safely and

timely, and what lan- guage the agents must speak in order to understand each other

(especially if they are heterogeneous).

1.3 Applications

Just as with single-agent systems in traditional AI, it is difficult to anticipate the full

range of applications where DASs can be used. Some applications have already

appeared, especially in software engineering where DAS technology is viewed as a

novel and promising software building paradigm. A complex software system can be

treated as a collection of many small-size autonomous agents, each with its own local

functionality and properties, and where interaction among agents enforces total system

integrity. Some ofthe benefits of using DAS technology in large software systems are

(Sycara,1998):

Speedup and efficiency, due to the asynchronous and parallel compu- tation.Robustness and reliability, in the sense that the whole system can undergo agracefuldegradationwhen one or more agents fail.

Scalability and flexibility, since it is easy to add new agents to the system.Cost, assuming that an agent is a low-cost unit compared to the whole system.Development and reusability, since it is easier to develop and maintain a modularsoftware than a monolithic one.

A very challenging application domain for DAS technology is the Inter- net. Today the

Internet has developed into a highly distributed open system

7/31/2019 Das Doc

6/17

where heterogeneous software agents come and go, there are no well estab-

lished protocols or languages on the agent level (higher than TCP/IP),and the structure of the network itself keeps on changing. In such an envi-

ronment, DAS technology can be used to develop agents that act on behalf

of a user and are able to negotiate with other agents in order to achieve

their goals. Auctions on the Internet and electronic commerce are such ex-

amples (Noriega and Sierra, 1999; Sandholm, 1999). One can also think

of applications where agents can be used for distributed data mining and

information retrieval.

DASs can also be used for traffic control where agents (software or

robotic) are located in different locations, receive sensor data that are geo-

graphically distributed, and must coordinate their actions in order to ensure

global system optimality (Lesser and Erman, 1980). Other applications arein social sciences where DAS technology can be used for simulating inter-

activity and other social phenomena (Gilbert and Doran, 1994), in robotics

where a frequently encountered problem is how a group of robots can lo-

calize themselves within their environment (Roumeliotis and Bekey, 2002),

and in virtual reality and computer games where the challenge is to build

agents that exhibit intelligent behavior (Terzopoulos, 1999).

Finally, an application of DASs that has recently gained popularity is

robot soccer. There, teams of real or simulated autonomous robots play

soccer against each other (Kitano et al., 1997). Robot soccer provides a

testbed where DAS algorithms can be tested, and where many real-world

characteristics are present: the domain is continuous and dynamic, the be-havior of the opponents may be difficult to predict, there is uncertainty in

the sensor signals, etc.

1.4 Challenging issues

The transition from single-agent systems to DASs offers many potential

advantages but also raises challenging issues. Some of these are:

How to decompose a problem, allocate subtasks to agents, and syn-thesize partial results.

How to handle the distributed perceptual information. How to enableagents to maintain consistent shared models of the world.

How to implement decentralized control and build efficient coordina-tion mechanisms among agents.

How to design efficientDistributed planning and learning algorithms.How to represent knowledge. How to enable agents to reason about

the actions, plans, and knowledge of other agents.

7/31/2019 Das Doc

7/17

How to enable agents to communicate. What communication lan-guages and protocols to use. What, when, and with whom should an

agentcommunicate.

How to enable agents to negotiate and resolve conflicts.How to enable agents to form organizational structures like teams or coalitions. How to

assign roles to agents.

How to ensure coherent and stable system behavior.Clearly the above problems are interdependent and their solutions may affect each other. For

example, a distributed planning algorithm may require a particular coordination mechanism,

learning can be guided by the organizational structure of the agents, and so on. In the following

chapters we will try to provide answers to some of the above questions.

2.Distributed-agent Systems (DAS)

DPS considers how the task of solving a particular problem can be divided among a number of modules

that cooperate in dividing and sharing knowledge about the problem and its evolving solution(s).

7/31/2019 Das Doc

8/17

How problems are solved in distributed environment:-

Cooperative Distributed Problem Solving

Work on cooperative distributed problem solving began with the work of Lesser

and colleagues on systems that contained agent-like entities, each of which with

distinct (but interrelated) expertise that they could bring to bear on problems thatthe entire system is required to solve:CDPS studies how a loosely-coupled network of problem solvers can

work together to solve problems that are beyond their individual capabilities.

Each problem-solving node in the network is capable of sophisticated

problem-solving and can work independently, but the problems

faced by the nodes cannot be completed without cooperation. Cooperation

is necessary because no single node has sufficient expertise,

resources, and information to solve a problem, and different nodes

might have expertise for solving different parts of the problem.

Historically, most work on cooperative problem solving has made the benevolence

assumption: that the agents in a system implicitly share a common goal,

and thus that there is no potential for conflict between them. Ths assumption

implies that agents can be designed so as to help out whenever needed, even if

it means that one or more agents must suffer in order to do so: intuitively, all

that matters is the overall system objectives, not those of the individual agents

within it. The benevolence assumption is generally acceptable if all the agents in

a system are designed or 'owned' by the same organization or individual. It is

important to emphasize that the ability to assume benevolence greatly simplifies

the designer's task. Ifwe can assume that all the agents need to worry about isthe overall utility of the system, then we can design the overall system so as to

optimize this.

In contrast to work on distributed problem solving, the more general area

of multiagent systems has focused on the issues associated with societies of

self-interestedagents. Thus agents in a multiagent system (unlike those in typical

distributed problem-solving systems), cannot be assumed to share a common

goal, as they will often be designed by different individuals or organizations

in order to represent their interests. One agent's interests may therefore

conflict with those of others, just as in human societies. Despite the potential

for conflicts of interest, the agents in a multiagent system will ultimately need

to cooperate in order to achieve their goals; again, just as in human societies.

7/31/2019 Das Doc

9/17

Multiagent systems research is therefore concerned with the wider problems of

designing societies of autonomous agents, such as why and how agents cooperate

(Wooldridge and Jennings, 1994); how agents can recognize and resolve conflicts

(Adler et aL, 1989; Galliers, l988b; Galliers, 1990; Klein and Baskin, 199 1; Lander

et al., 1991); how agents can negotiate or compromise in situations where they

are apparently at loggerheads (Ephrati and Rosenschein, 1993; Rosenschein and

Zlotkin, 1994); and so on.

It is also important to distinguish CDPS from parallel problem solving (Bond

and Gasser, 1988, p. 3). Parallel problem solving simply involves the exploitation

of parallelism in solving problems. Typically, in parallel problem solving, the computational

components are simply processors; a single node will be responsible

for decomposing the overall problem into sub-components, allocating these to

processors, and subsequently assembling the solution. The nodes are frequently

assumed to be homogcneous in the sense that they do not have distinct cxpcrtise

- they are simply processors to be exploited in solving the problem. Although

parallel problem solving was synonymous with CDPS in the early days of multiagent

systems, the two fields are now regarded as quite separate. (However, it

goes without saying that a multiagent system will employ parallel architectures

and languages: the point is that the concerns of the two areas are rather different.)

Coherence and coordinationHaving implemented an artificial agent society in order to solve some problem,

how does one assess the success (or otherwise) of the implementation? What

criteria can be used? The multiagent systems literature has proposed two types

of issues that need to be considered.

Coherence. Refers to 'how well the [multiagent] system behaves as a unit, alongsome dimension of evaluation' (Bond and Gasser, 1988, p. 19). Coherence may be

measured in terms of solution quality, efficiency of resource usage, conceptualclarity of operation, or how well system performance degrades in the presence

of uncertainty or failure; a discussion on the subject of when multiple agents

can be said to be acting coherently appears as (Wooldridge, 1994).

Coordination. In contrast, is 'the degree.. .to which [the agents]. . .can avoid

'extraneous' activity [such as]. . .synchronizing and aligning their activities'

(Bond and Gasser, 1988, p. 19); in a perfectly coordinated system, agents will not

accidentally clobber each other's sub-goals while attempting to achieve a common

goal; they will not need to explicitly communicate, as they will be mutually

predictable, perhaps by maintaining good internal models of each other.

Thc presence of conflict between agents, in the sense of agents destructivclyinterfering with one another (whch requires time and effort to resolve), is an

indicator of poor coordination.

It is probably true to say that these problems have been the focus of more attention

in multiagent systems research than any other issues (Durfee and Lesser,

7/31/2019 Das Doc

10/17

7/31/2019 Das Doc

11/17

sub-problems, and so on, until the sub-problems are of an appropriate granularity

to be solved by individual agents. The different levels of decomposition

will often represent different levels of problem abstraction. For example, consider

a (real-world) example of cooperative problem solving, which occurs when

a government body asks whether a new hospital is needed in a particular region.

In order to answer this question, a number of smaller sub-problems need to be

solved, such as whether the existing hospitals can cope, what the likely demand

is for hospital beds in the future, and so on. The smallest level of abstraction

might involve asking individuals about their day-to-day experiences of the current

hospital provision. Each of these different levels in the problem-solving

herarchy represents the problem at a progressively lower level of abstraction.

Notice that the grain size of sub-problems is important: one extreme view

ofCDPS is that a decomposition continues until the sub-problems represent

'atomic' actions, which cannot be decomposed any further. This is essentially

what happens in the ACTOR paradigm, with new agents - ACTORs

being spawned for every sub-problem, until ACTORs embody individual program

instructions such as addition, subtraction, and so on (Agha, 1986). But

ths approach introduces a number of problems. In particular, the overheads

involved in managing the interactions between the (typically very many) subproblems

outweigh the benefits of a cooperative solution.

Another issue is how to perform the decomposition. One possibility is that

the problem is decomposed by one individual agent. However, this assumes

that t h s agent must have the appropriate expertise to do this - it must have

knowledge of the task structure, that is, how the task is 'put together'. If other

agents have knowledge pertaining to the task structure, then they may be able

to assist in identifying a better decomposition. The decomposition itself may

therefore be better treated as a cooperative activity.Yet another issue is that task decomposition cannot in general be done without

some knowledge of the agents that will eventually solve problems. There is no

point in arriving at a particular decomposition that is impossible for a particular

collection of agents to solve.

(2) Sub-problem solution. In this stage, the sub-problems identified during problemdecomposition are individually solved. This stage typically involves sharing

of information between agents: one agent can help another out if it has information

that may be useful to the other.

(3) Solution synthesis. In this stage, solutions to individual sub-problems are

integrated into an overall solution. As in problem decomposition, this stage maybe hierarchical, with partial solutions assembled at different levels of abstraction.

Note that the extent to which these stages are explicitly carried out in a particular

problem domain will depend very heavily on the domain itself; in some domains,

some of the stages may not be present at all.

7/31/2019 Das Doc

12/17

Figure 9.2 (a) Task sharing and (b) result sharing. In task sharing, a task is decomposedinto sub-problems that are allocated to agents, while in result sharing, agents supply each

other with relevant information, either proactively or on demand.

Given this general framework for CDPS, there are two specific cooperative

problem-solving activities that are likely to be present: task sharing and result

sharing (Smith and Davis, 1980) (see Figure 9.2).Task sharing. Task sharing takes place when a problem is decomposed to smallersub-problems and allocated to different agents. Perhaps the key problem to be

solved in a task-sharing system is that of how tasks are to be allocatedto individualagents. If all agents are homogeneous in terms of their capabilities (cf. the

discussion on parallel problem solving, above), then task sharing is straightforward:

any task can be allocated to any agent. However, in all but the most trivial

ofcases, agents have very different capabilities. In cases where the agents arereally autonomous - and can hence decline to carry out tasks (in systems that

do not enjoy the benevolence assumption described above), then task allocation

will involve agents reaching agreements with others, perhaps by using thetechniques described in Chapter 7.

Result sharing. Result sharing involves agents sharing information relevant to

their sub-problems. Ths information may be sharedproactively (one agentsends another agent some information because it believes the other will be

interested in it), or reactively (an agent sends another information in responseto a request that was previously sent - cf. the subscribe performatives in the

agent communication languages discussed earlier).

Task sharing in the Contract NetThe Contract Net (CNET) protocol is a high-level protocol for acheving efficient

cooperation through task sharing in networks of communicating problem solvers

(Smith, 1977, 1980a,b; Smith and Davis, 1980). The basic metaphor used in the

CNET is, as the name of the protocol suggests, contracting - Smith took h s inspiration

from the way that companies organize the process of putting contracts out

to tender (see Figure 9.3).

7/31/2019 Das Doc

13/17

[A] node that generates a task advertises existence of that task to other

nodes in the net with a task announcement, then acts as the managerof that task for its duration. In the absence of any information about

the specific capabilities of the other nodes in the net, the manager isforced to issue a general broadcastto all other nodes. If, however, themanager possesses some knowledge about whch of the other nodes

in the net are likely candidates, then it can issue a limited broadcasttojust those candidates. Finally, if the manager knows exactly which of

the other nodes in the net is appropriate, then it can issue apoint-topointannouncement. As work on the problem progresses, many such

task announcements will be made by various managers.

Nodes in the net listen to the task announcements and evaluate

them with respect to their own specialized hardware and software

resources. When a task to which a node is suited is found, it submits

a bid. A bid indicates the capabilities of the bidder that are relevant tothe execution of the announced task. A manager may receive several

such bids in response to a single task announcement; based on the

information in the bids, it selects the most appropriate nodes to execute

the task. The selection is communicated to the successful bidders

through an awardmessage. These selected nodes assume responsibil ity for execution of the task,

and each is called a contractorfor thattask.

7/31/2019 Das Doc

14/17

After the task has been completed, the contractor sends a reporttothe manager. (Smith, 1980b, pp. 60, 61)

[This] normal contract negotiation process can be simplified in

some instances, with a resulting enhancement in the efficiency of the

protocol. Ifa manager knows exactly which node is appropriate for

the execution of a task, a directed contractcan be awarded. Thls differs

from the announced contractin that no announcement is madeand no bids are submitted. Instead, an award is made directly. In such

cases, nodes awarded contracts must acknowledge receipt, and have

the option of refusal.

Finally, for tasks that amount to simple requests for information, a

contract may not be appropriate. In such cases, a request-response

sequence can be used without further embellishment. Such messages

(that aid in the distribution of data as opposed to control) are implemented

as requestand information messages. The request message is

used to encode straightforward requests for information when contractingis unnecessary. The information message is used both as a

response to a request message and a general data transfer message.

(Smith, 1980b, pp. 62, 63)

In addition to describing the various messages that agents may send, Smith

describes the procedures to be carried out on receipt of a message. Briefly, these

procedures are as follows (see Smith (1980b, pp. 96-102) for more details).

(1) Task announcement processing. On receipt of a task announcement, an

agent decides if it is eligible for the task. It does this by looking at the eligibility

specification contained in the announcement. If it is eligible, then details

of the task are stored, and the agent will subsequently bid for the task.(2) Bid processing. Details of bids from would-be contractors are stored by(would-be) managers until some deadline is reached. The manager then awards

the task to a single bidder.

(3) Award processing. Agents that bid for a task, but fail to be awarded it, simplydelete details of the task. The successful bidder must attempt to expedite the

task (whch may mean generating new sub-tasks).

(4) Request and inform processing. These messages are the simplest to handle.A request simply causes an inform message to be sent to the requestor, containing

the required information, but only if that information is immediately

available. (Otherwise, the requestee informs the requestor that the information is unknown.) An

inform message causes its content to be added to the recipi-Il

ent's database. It is assumed that at the conclusion of a task, a contractor will

send an information message to the manager, detailing the results of the expedited

task1.

E Despite (or perhaps because of) its simplicity, the Contract Net has become the

most implemented and best-studied framework for distributed problem solving.

7/31/2019 Das Doc

15/17

Result SharingIn result sharing, problem solving proceeds by agents cooperatively exchanging

information as a solution is developed. Typically, these results will progress from

being the solution to small problems, which are progressively refined into larger,

more abstract solutions. Durfee (1999, p. 131) suggests that problem solvers can

improve group performance in result sharing in the following ways.

Confidence: independently derived solutions can be cross-checked, highlightingpossible errors, and increasing confidence in the overall solution.

Completeness: agents can share their localviews to achieve a better overallglobalview.

Precision: agents can share results to ensure that the precision of the overallsolution is increased.

Timeliness: even if one agent could solve a problem on its own, by sharing asolution, the result could be derived more quickly.

Combining Task and Result SharingIn the everyday cooperative worlung that we all engage in, we frequentlycombinetask sharing and result sharing. In t h s section, I will briefly give an overview of

how this was achieved in the FELINE system (Wooldridge et al., 1991). FELINE was

acooperating expert system. The idea was to build an overall problem-solvingsystem as a collection of cooperating experts, each of which had expertise in

dstinct but related areas. The system worked by these agents cooperating to

bothshare knowledge anddistribute subtasks. Each agent in FELINE was in fact anindependent rule-based system: it had a working memory, or database, containing

information about the current state of problem solving; in addition, each agent

had a collection of rules, which encoded its domain knowledge.Each agent in FELINE also maintained a data structure representing its beliefs

about itself and its environment. This data structure is called the environment

model(cf. the agents with symbolic representations discussed in Chapter 3). It contained an entryfor the modelling agent and each agent that the modelling

agent might communicate with (its acquaintances). Each entry contained two

important attributes as follows.

Skills. This attribute is a set of identifiers denoting hypotheses which the agenthas the expertise to establish or deny. The slulls of an agent will correspond

roughly to root nodes of the inference networks representing the agent's

domain expertise.Interests. This attribute is a set of identifiers denoting hypotheses for whch thcagent requires the truth value. It may be that an agent actually has the expertise

to establish the truth value of its interests, but is nevertheless 'interested' in

them. The interests of an agent will correspond roughly to leaf nodes of the

inference networks representing the agent's domain expertise.

Messages in FELINE were triples, consisting of a sender, receiver, and contents.

The contents field was also a triple, containing message type, attribute, and value.

Agents in FELINE communicated using three message types as follows (the system

predated the KQML and FIPA languages discussed in Chapter 8).

7/31/2019 Das Doc

16/17

Request. If an agent sends a request, then the attribute field will contain an identifierdenoting a hypothesis. It is assumed that the hypothesis is one which lies

within the domain ofthe intended recipient. A request is assumed to mean thatthe sender wants the receiver to derive a truth value for the hypothesis.

Response. If an agent receives a request and manages to successfully derive atruth value for the hypothesis, then it will send a response to the originator of

the request. The attribute field will contain the identifier denoting the hypothesis:

the value field will contain the associated truth value.

Inform. The attribute field of an inform message will contain an identifier denotinga hypothesis. The value field will contain an associated truth value. An

inform message will be unsolicited; an agent sends one if it thinks the recipient

will be 'interested' in the hypothesis.

To understand how problem solving in FELINE worked, consider goal-driven

problem solving in a conventional rule-based system. Typically, goal-driven reasoning

proceeds by attempting to establish the truth value of some hypothesis.

If the truth value is not known, then a recursive descent of the inference network

associated with the hypothesis is performed. Leaf nodes in the inference network

typically correspond to questions which are asked of the user, or data that isacquired in some other way. Within FELINE, ths scheme was augmented by the

following principle. When evaluating a leaf node, if it is not a question, then the

environment model was checked to see if any other agent has the node as a 'slull'.

If there was some agent that listed the node as a slull, then a request was sent

to that agent, requesting the hypothesis. The sender of the request then waited

until a response was received; the response indicates the truth value of the node.

CONCLUSIONS:-

7/31/2019 Das Doc

17/17

Reference:-

[1]. Stuart Russell and Peter Norvig, Artificial

Intelligence: A Modern, c 1995, Prentice-Hall, Inc. [16]. Alper Caglayan and Colin Harrison,

"Agent Source Book", John Wiley & Sons, Inc, United States ofAmerica, 1997.

[2]. Fabio Michael Wooldridge, Developing An Introduction to MultiAgent System, Wiley

Series in Agent Technology.

Documents

Das Doc