Luận án tiến sĩ: Engineering open environments for multi-agent simulation systems

Rym Zalila Mili, Chair In this work, we present the idea that agents and the environment play anequally important role in MAS design and propose an architecture for AgentEnvironment Syst

This dissertation was produced in accordance with guidelines which permitthe inclusion as part of the dissertation the text of an original paper or paperssubmitted for publication The dissertation must still conform to all otherrequirements explained in the “Guide for the Preparation of Master Thesesand Doctoral Dissertations at The University of Texas at Dallas.” It mustinclude a comprehensive abstract, a full introduction and literature reviewand a final overall conclusion Additional material (procedural and designdata as well as descriptions of equipment) must be provided in sufficient de-tail to allow a clear and precise judgement to be made of the importance andoriginality of the research reported It is acceptable for this dissertation toinclude as chapters authentic copies of papers already published, providedthese meet type size, margin and legibility requirements In such cases, con-necting texts which provide logical bridges between different manuscripts aremandatory Where the student is not the sole author of a manuscript, thestudent is required to make an explicit statement in the introductory mate-rial to that manuscript describing the student’s contribution to the work andacknowledging the contribution of the other author(s) The signatures of theSupervising Committee which precede all other material in the dissertationattest to the accuracy of this statement.

Renee Lynn SteinerAll Rights Reserved

SIMULATION SYSTEMS

by

RENEE LYNN STEINER, B.S., M.S

DISSERTATIONPresented to the Faculty ofThe University of Texas at Dallas

in Partial Fulfillment

of the Requirementsfor the Degree of

DOCTOR OF PHILOSOPHY INCOMPUTER SCIENCE

THE UNIVERSITY OF TEXAS AT DALLAS

December 2006

3238604 2007

UMI Microform Copyright

All rights reserved This microform edition is protected against unauthorized copying under Title 17, United States Code.

ProQuest Information and Learning Company

300 North Zeeb Road P.O Box 1346 Ann Arbor, MI 48106-1346

by ProQuest Information and Learning Company

I would like to thank Dr Rym Zalila Mili, my supervisor, for her manysuggestions and constant support during this research I would also like tothank Dr Kendra Cooper, Dr Jing Dong and Dr Kang Zhang for serving

on my committee I am also thankful to members of the DIVAs lab for theircontributions and encouragement

I am especially thankful to my family and friends who have sacrificed much

so that I might succeed in my goals

November 2006

v

SIMULATION SYSTEMS

Publication No

Renee Lynn Steiner, Ph.D

The University of Texas at Dallas, 2006

Supervising Professor: Dr Rym Zalila Mili, Chair

In this work, we present the idea that agents and the environment play anequally important role in MAS design and propose an architecture for AgentEnvironment System (AES) We consider environments as first class entitiesand propose a specification, design and implementation of the DIVAs envi-ronment DIVAs is a large scale multi-agent simulation tool in which agentsrepresent social entities and the environment an artificial world Our archi-tecture is based on software engineering concepts such as separation of con-cerns, modularity and information hiding This leads to adaptable systemsthat can support multiple application domains We discuss a Specificationand a Simulation Tool that illustrate the applicability of our results to variousproblems

vi

Acknowledgements v

Abstract vi

Table of Contents vii

List of Tables x

List of Figures xi

Introduction 1

1 State of the Art 4

1.1 Definitions 4

1.2 Classifications of MAS Environments 6

1.2.1 Classification from the Literature 6

1.2.2 Proposed Classifications 9

1.3 Assessing MASS 16

1.3.1 Assessment Criteria 16

1.3.2 Tool Assessment 17

1.4 Conclusion 18

2 Agent-Environment Systems 19

2.1 Defining Agent-Environment System 19

2.2 AES Agent Characteristics 20

2.3 AES Environment Characteristics 21

vii

2.5.1 Why AES? 28

2.5.2 The AES Architecture 31

2.6 Conclusion 33

3 Levels and Viewpoints for AES 34

3.1 UWEA Levels 34

3.1.1 Levels 34

3.1.2 Viewpoints 36

3.2 Conclusion 55

4 The DIVAs System 60

4.1 DIVAs Agent-Environment System 60

4.2 Conclusion 68

5 DIVAs Environment 70

5.1 Environment Components 70

5.1.1 Planning and Control Module (PCM) 72

5.1.2 Interactions 74

5.1.3 Information 78

5.1.4 Tasks 82

5.2 Environmental Events 83

5.3 Conclusion 84

6 Environment Specification Tool 85

6.1 Mapping Design to Implementation 85

6.2 Implementation Overview 88

6.3 Tool Usage 89

6.4 Modifying the Environment 92

viii

6.7 Conclusion 98

7 Environment Simulation Tool 99

7.1 Simulation Tool Implementation Overview 99

7.2 Tool Usage 99

7.3 Simulating the Environment 103

7.4 Simulation Tool Features 106

7.5 Conclusion 106

8 Experimental Results 108

8.1 Scenarios 108

8.1.1 Test Environment 108

8.2 Test Data 109

8.3 Result Interpretation 109

8.4 Conclusions 112

9 Conclusion 113

9.1 Contributions 113

9.2 Future Work 115

Bibliography 116 Vita

ix

1.1 Assessing MAS environments 17

8.1 System Configuration for Testing 1088.2 Experimental Results 110

x

1.1 MAS Environment Classification 10

2.1 Agent and Environment Commonalities 23

2.2 Interactivity illustration for AES 25

2.3 FIPA Abstract Architecture 29

2.4 FIPA Agent Management Reference Model 31

2.5 A General AES Architecture 32

3.1 Universal Abstraction 35

3.2 World Abstraction 35

3.3 Entity Abstraction 36

3.4 Atomic Abstraction 37

3.5 Universal Level Data Model 39

3.6 World Level Data Model, Environment 40

3.7 World Level Data Model, Agent 41

3.8 Entity Level Data Model, Environment 42

3.9 Entity Level Data Model, Agent 43

3.10 Entity Level Functional Model 49

3.11 Universal Level Behavioral Model, State Chart 51

3.12 Universal Level Behavioral Model, Interaction Diagram 51

3.13 World Level Behavioral Model, State Chart 52

3.14 World Level Behavioral Model, Interaction Diagram 52

3.15 Entity Level Behavioral Model 53

3.16 Universal Level Structural Model 55

3.17 World Level Structural Model 56

3.18 Entity Level Structural Model, Environment 57

xi

4.1 DIVAs Architecture 61

4.2 Geographical Simulation Environment 65

4.3 Environment partitioned into cells 66

4.4 Representation of the Environment 67

4.5 Hierarchical decomposition of the environment into cells 68

5.1 Expanding Agent and Environment Commonalities 71

5.2 Environment Architecture 72

5.3 Environment Class Diagram 73

5.4 Interaction Classes 75

5.5 MTS High Level Analysis Diagram 79

5.6 MTS CommunicationModel Class Diagram 80

5.7 Information Classes 81

6.1 Specifying the Simulation Space 86

6.2 Directly observing the DIVAs environment architecture in the Specification Tool 87

6.3 New Project Wizard 89

6.4 Environment Editor representing the environment in xml 90

6.5 Specifying the heart as the environment 95

6.6 Level 2 of heart as the environment 96

7.1 Launching the Simulation Tool 100

7.2 DIVAs Simulation Tool, Level 1 101

7.3 DIVAs Simulation Tool with multiple levels exposed 102

7.4 Context Sensitive Menuing for Edges 104

7.5 Context Sensitive Menuing for Nodes 105

xii

The application of Multi-Agent Systems (MAS) paradigms to modeling andsimulation of adaptive systems has become an important development in com-puting [20] While traditional modeling and simulation techniques are lim-ited to static domains, MAS-based simulation brings into focus the desirableattributes of emergence, self-organization, learning, and adaptive behavior,thus enabling the modeling and understanding of more real world complexapplication domains.

A number of agent-based simulation systems have been described in theliterature including MASON [52], Swarm [66], Repast [18], Ethos [85], As-cape [74], AgentSheets [80], XRaptor [64], CORMAS [14], SimAgent [86],and SeSAm [49] Most of these systems are often restricted to specific ap-plications, and are difficult to adapt to other domains In addition, thesesystems do not clearly separate between agents and environment responsibil-ities Researchers agree that this is a substantial weakness in MAS and haverecently organized workshops dedicated to the exploration of environments

as first class entities [92, 91, 94]

1

Our work is based on the idea that, by separating the agent from its vironmental responsibilities, both the environment and the agent are morerobust and adaptable Such a clear separation of duties and responsibilitiesleads to a reduction in unnecessary coupling and a more understandable, ex-tensible, reusable architecture New Multi-Agent Simulation tools make use

en-of this principle [18, 52]

Moreover, we subscribe to the idea that agents and environment play anequally important role, and propose a definition for Agent-Environment Sys-tems (AES) The AES concept is particularly useful when a) the environment

is dynamic and distributed, b) the environment includes entities that are notagents, and c) agents cannot have a complete view of the environment atany point in time As such, AES are subsets of MAS and supersets of agentsimulation tools We illustrate our concepts through the DIVAs environment.DIVAs (or Dynamic I nformation V isualization of Agent systems) is a socialsimulation tool in which the environment is a geographical map consisting

of a graph whose nodes indicate places and whose edges represent pathwaysbetween places

In Chapter 1, we define key terms and examine the state of the art of MultiAgent Simulation Systems and the environments they provide In Chapter 2,

we present the concept of the Agent Environment Architecture In Chapter 3,

we discuss the environment and agent from various levels of abstraction andpropose models for data, functional, behavioral and structural viewpoints.

In Chapter 4, we discuss the DIVAs system architecture In Chapter 5, weexamine the DIVAs environment architecture In Chapter 6, we introduceour Specification Tool implementation, and in Chapter 7, we inspect ourSimulation Tool implementation In Chapter 8, we discuss the experimentalresults achieved We finish by suggesting directions for future work for Multi-Agent Simulation System environments

STATE OF THE ART

In this Chapter, we discuss terms found in the MAS field and proceed withdiscussing the state of the art with respect to environments for Multi-AgentSystems, focusing on simulation systems

1.1 Definitions

In our work, we subscribe to the following definitions:

Agent An agent is a computer system that is situated in some ment, and that is capable of autonomous action in this environment inorder to meet its design objectives [6]

environ-Environment In situated MAS, the environment is an active entity withits own processes that can change its own state, independent of the ac-tivity of the embedded agents [91]

Multi-agent System (MAS) A MAS is a system that consists of a ber of agents, which interact with one-another Agents interact on behalf

num-of users with different goals and motivations To successfully interact,

4

they require the ability to cooperate, coordinate, and negotiate with eachother [97].

Multi-agent Simulation System (MASS) A computer simulation is thediscipline of designing a model of an actual or theoretical physical system,

executing the model on a digital computer and analyzing the executionoutput A MASS is a computer simulation specifically for a MAS [37, 22]

In the past few years, interest in environments for MAS has greatly creased A new workshop, Environments for Multiagent Systems (E4MAS),began in 2004 as part of the Autonomous Agents for Multi-agent Systems(AAMAS) conference [5] The workshop in 2004 resulted in the survey byWeyns et al.[91] This survey describes various MAS from the perspective

in-of the environment [91] By focusing on the environment, the authors stressthe importance that the environment plays in MAS as well as emphasizes therelative newness of accepting the environment as a primary abstraction Like-wise, more and more researchers agree that the environment should be treated

as a first-class entity We define a first-class entity as “a program buildingblock, an independent piece of software which provides an abstraction

or information hiding mechanism so that a module’s implementation can bechanged without requiring any change to other module” [1, 91] Hence, since

the environment only recently has been proposed as such, the amount of gineering, and therefore, the amount of architectures focusing on this topic

en-is limited

Therefore, in order to discuss the state of the art, we first discuss existingclassifications of MAS environments

1.2 Classifications of MAS Environments

In this section, we discuss the classification proposed by the mentioned surveyand continue with a proposed a classification for environments for MAS

1.2.1 Classification from the Literature

The referenced survey classifies environments into four categories: generalmodels, inter-agent facilities, agent-environment interaction, and environ-ments in agent oriented methodologies

• General models These are models which define general agent ment relationships (e.g., how the agent perceives the environment, howthe environment perceives the agent) Examples of such models are theinfluence/reaction model proposed by Ferber [27], the percept/effectormodel proposed by Russell and Norvig [82], and a model proposed byOdell et al which differentiates between the physical environment and

environ-the communication environment [68] Anoenviron-ther discussed model dealswith environments for mobile agents in which the agent possesses theability to migrate from one system to another in the course of complet-ing their goals These models are also referred to as Distributed AgentEnvironments (DAE) and commonly adhere to the OMG MASIF stan-dard [41] or the FIPA standard [36].

• Inter-agent facilities These are further divided based on the interactionmechanism: communication infrastructure, models for indirect interac-tion, and the environment as an organizational layer These divisionsare based on the taxonomy of agent interaction mechanisms proposed in[76] The communication infrastructure model addresses agent to agentcommunication and does not consider the environment The FIPA stan-dard defines these communications to great extent [36] Models for indi-rect interaction deal with entities that interact through a communicationabstraction and are characterized by properties such as name, space andtime uncoupling One way this can be accomplished is through the re-cent work on coordination artifacts of [72] Blackboard systems alsocould be used as the communication infrastructure in this case [19, 25].Also considered are tuple-based models which used associative access to

a shared dataspace for communication purposes [39] Another model is

stigmergy which requires that individual agents modify the environmentwhile others respond to the modification and modify it in turn [77] Fi-nally, regarding the models for indirect interaction, the survey mentionsinteraction models based on space which are generally derived from Cel-lular Automata (CA) [95, 7, 100] These models generally represent anabstraction of a physical environment and model problems in which spa-tial features play an important role [21] The final model of inter-agentfacilities discussed in this category is the when the environment repre-sents an organizational layer This refers to MAS that can be designed as

a computational organization that imposes a set of constraints on the havior of agents and offers a set of facilities and services that agents mayuse (e.g., “groups” act as an environment for the agent)[10, 31, 67, 30]

be-• Agent-environment interaction These are further refined by models foractive perception, action models, and task environments Models foractive perception deal with the ability of an agent to observe its envi-ronment Most of the research on perception can be found in roboticsand cognitive science For virtual environments, only a few theories andmodels have been proposed [3, 93] Models for action are based on theenvironmental transformation of states, i.e., an action is defined as a tran-sition of state [32, 90, 70, 27] Task models are presented in [9] which

defines a task environment as a tuple that specifies the properties of thesystem the agent will inhabit as well as the criteria by which an agenteither failed or succeeded in its task This environment is discussed ingreater detail in [82, 44, 4].

• Environments in agent oriented methodologies Several of these ologies offer support for some basic elements of the environment but

method-do not consider the environment as a first-class entity (i.e., Message,Prometheus, Tropos) [26, 40, 73] the only exception being Gaia [96].Since these are methodologies, they do not define an explicit architecturefor the environment

1.2.2 Proposed Classifications

We propose to classify environments into three broad categories: ConceptualEnvironments, Tuplespace and Metric Environments as represented in Figure1.1 [5] We begin our discussion with Conceptual Environments

• Conceptual Environments These are environments that are tional in nature and correspond to the Weyns category of inter-agentfacilities where the environment is an organizational layer Organiza-tions are based around concepts such as role, group, community etc

organiza- organiza- organiza-.

Graph Metric

Euclidean

Environment

Figure 1.1 MAS Environment Classification

[28, 31, 29] Examples of this type are found in MMASS[11], AGR merly called Aalaadin) [30], MOCA [10] and MadKit [42] which is based

(for-on AGR For example, in AGR, the designer first c(for-oncentrates (for-on theorganizational level by specifying the structures and pattern of activitiesamong the agents This is based on abstractions such as groups, roles,interaction protocols, etc After that, the developer then focuses on theagent’s internal architecture Therefore, the environment is only consid-ered as a “group” in which the agent interact’s with other agents Groupscan change in the course of the execution, therefore, the environment isnot fixed

• Tuplespace Tuple-based environments focus on distributed computingmodels For example, agents in this environment communicate by putting

tuples in and removing them from a shared space (i.e., the tuplespace).Examples of this type include MARS [17], JavaSpaces [89, 38], Object-Places [83], EgoSpaces [47], TOTA [55, 54] and LIME [65] TOTA is

a middleware that maintains distributed tuples Javaspaces is the basisfor Sun’s Jini technology and offers the possibility of remotely accessibletuplespaces which can accomplish distributed transactions across the tu-plespace ObjectPlaces, EgoSpaces and TOTA all provide mechanismsfor sharing tuples across tuplespaces In Lime, each agent carries its envi-ronment embedded within them When multiple agents are on the samehost, their tuplespace environments are merged, giving the illusion of ashared tuplespace

• Metric Environments The tools which falling within this category seethe environment as a grid-like structure either two-dimensional or three-dimensional Some have a basis in Cellular Automata [95, 7, 100] whichmake them suited to represent an abstraction of a physical environment[13, 11, 12] Most of the agent-based simulation tools fall within thisgroup The EthoModelling Framework [23] and AgentSheets [80] repre-sent the environment as a two-dimensional grid These works, however,treat the environment as a centralized, passive entity lacking representa-tions for situated objects MASON [52], Swarm [66, 62], and Repast [18]

are tools that also present the environment as a two-dimensional grid andwill be discussed later in the Chapter Also, AKIRA [78], whose envi-ronment can be represented metrically, has rules and dynamics that can

be used to model it as a simple agent AKIRA shares information via ablackboard and, while the environment is responsible for simple systemfunctions, it appears to be implemented as a single daemon Anotherwork has also been presented that represents the environment as a set ofenvironment logical processes (ELP)[51] While this type of environmentalso employs an Interest Management strategy, the authors use a “sharedspace” to pass around to the agents to circumvent the normal static na-ture of Interest Management However, the interaction between logicalprocesses is assumed to be known in advance therefore the interactionsare static MMASS’s [11] environment is a multi-layered environmentthat can be either spatial or conceptual representing a hierarchy amongagents Co-Fields [53] supports the coordination of agents in an environ-ment by means of distributed data structures that are spread by agents

or the environment Another proposed environment uses a pheromoneinfrastructure to indirectly share knowledge [16]

Now, further narrowing down the Metric Environment classification, wediscuss agent-based simulation systems many of which have been described

in the literature These include MASON [52], Swarm [66], Repast [18], Ethos[85], Ascape [74], AgentSheets [80], XRaptor [64], CORMAS [14], SimAgent[86], SDML [63], and SeSAm [49] Since most of these systems provide solu-tions for specific application domains, the architectures are not easily reusableoutside of their domain In addition, while some of the tools allow the sim-ulation modeler to change the visual representation of the environment, tothe best of our knowledge, none of these tools allows the users to dynamicallyaccess and modify the environment properties and behavior at run time.Therefore, further analysis is restricted to those tools that best compare

to our work such as the “framework and library” platforms of Swarm [66],Repast [18] and MASON [52] They are regarded as such since they provide

a conceptual framework for designing simulations as well as the libraries withwhich to implement the design [79]

• MASON is written in Java It has a central data object that holds state tofacilitate communication between entities and is passed in to each entity

to utilize Both agents and the environment live within “habitat cells”which serve as a localization of communication for the entities One thing

to note is that execution time was not seen to increase with an increase

in habitat cells [79] This would seem to indicate that the habitat cellshave very limited responsibility and may, in fact, be passive However,

they must be implemented for a simulation so, even if they exhibit verybasic functionality, they still require programming.

• Repast is written in Java and claims that it “provides a wide range of twodimensional agent environments and visualizations”[18] However, theenvironment is very simple, and there is no description of the interactionmechanisms between agents and environment Furthermore, Repast cou-ples its two dimensional environment tightly to the visualization; it would

be a programming effort to change the core structure of the visualization.Also coupled too closely is domain specific tooling with the framework;demonstration models are intermingled with the core software For ex-ample, habitat cells must be implemented by using the Repast libraryfor each distinct simulation In order to avoid this programming task,the environment must be the same between simulations However, if avisualization of the simulation is necessary, then a separate visualizationobject must be programmed for the habitat cell Repast also saw thesame behavior as MASON regarding the system performance when thequantity of habitat cells were increased, indicating environment passivity

• Swarm is written in Objective-C with a Java Adapter layer added as part

of Java Swarm which interacts with the Objective-C source Swarm is

considered the forefather of both Repast and MASON, since they ment Swarm-like functionality Swarm represents the environment as atwo dimensional grid whose visualization is coupled tightly to the model

imple-in much the same way as Repast Swarm too suffers from the same tations of the habitat cells as mentioned above If the goal is to program

limi-in Java, then Swarm would not be the first choice; the manner limi-in whichthey have wrapped the Objective-C calls with Java, is rather clumsy anddoes not allow for debugging of errors in the Objective-C source [79]

While the concept of framework and library systems is good, these tools dosuffer a few drawbacks For example, all three platforms couple the agent andenvironment models with the visualizations; one must program a visualizationobject for each entity in order to view it Another indication of the tightcoupling is that the platform considers a graphical update operation (i.e.,paint()) to be an “action” very similar to an agent action

Hence, having proposed a classification for MAS environments as well vided an overview of the tools, in the next section we offer an assessment ofthe mentioned environments

pro-1.3 Assessing MASS

In this section, we assess the environments according to criteria as described

by Russell and Norvig [82, 91]

1.3.1 Assessment Criteria

There are many ways to assess MASS such as the functionality provided, theapplication domain, and key system properties We choose to characterizesimulation systems based on the key properties as proposed by Russell andNorvig and accepted by most researches of MAS:

Accessible versus inaccessible: describes whether the agents have a full

or partial view of the environment

Deterministic versus nondeterministic: describes whether the next state

of the environment is uniquely determined by its current state and theagents’ actions

Static versus dynamic: describes whether the environment can change dependent of agent deliberations

in-Discrete versus continuous: describes whether the number of perceptsand actions are limited

Tools that exhibit these qualities can be characterized as open [99] and, assuch, present architectural challenges that we discuss in following Chapters.

1.3.2 Tool Assessment

We apply the above mentioned properties to the environments as described

in Table 1.1 It is interesting to note the similarities between the tools foreach category For example, conceptual environments tend to be inaccessi-ble, deterministic, static and discrete Those in the tuple category tend to

be inaccessible, nondeterministic, static and discrete Metric environmentsusually exhibit the properties of nondeterministic, dynamic and discrete

Table 1.1 Assessing MAS environments

Type Tool Accessible / Deterministic / Static / Discrete /

Inaccessible Nondeterministic Dynamic Continuous Conceptual AGR Inaccessible Deterministic Static Discrete

MOCA Inaccessible Deterministic Static Discrete MadKit Inaccessible Deterministic Static Discrete MARS Inaccessible Deterministic Static Discrete Tuple JavaSpaces Inaccessible Nondeterministic Static Discrete

ObjectPlaces Inaccessible Nondeterministic Static Discrete EgoSpaces Inaccessible Nondeterministic Static Discrete TOTA Inaccessible Nondeterministic Static Discrete LIME Accessible Nondeterministic Static Discrete Metric EthoModelling Inaccessible Nondeterministic Dynamic Discrete

Framework AgentSheets Inaccessible Nondeterministic Dynamic Discrete AKIRA Accessible Nondeterministic Dynamic Discrete ELP based Accessible Nondeterministic Static Discrete MASON Accessible Nondeterministic Dynamic Discrete Swarm Accessible Nondeterministic Dynamic Discrete Repast Accessible Nondeterministic Dynamic Discrete MMASS Inaccessible Nondeterministic Dynamic Discrete Co-Fields Inaccessible Nondeterministic Dynamic Discrete

1.4 Conclusion

As mentioned in the Weyns survey, “the challenge of engineering ments will pose significant challenges in both the design and implementa-tion of practical systems ”[91] Therefore, for environments that are inacces-sible, nondeterministic, dynamic and discrete (i.e., open environments), newtechniques are required in order to properly analyze and design environments

environ-In this dissertation, we offer a new approach

AGENT-ENVIRONMENT SYSTEMS

In this Chapter, we introduce and discuss Agent-Environment Systems, anabstract architecture for MAS We apply software engineering principles tothis abstraction Applying these principles translate the traditional MASdesign into a template for architecting multi-agent systems

2.1 Defining Agent-Environment System

We define Agent-Environment System (AES) [60, 87, 58] as a system posed of

com-1 a set of interacting agents,

2 a distinct distributed, dynamic environment in which these agents aresituated, and

3 a mechanism for agent-environment interactions

AESs can be viewed as subsets of multi-agent systems and supersets ofmulti-agent based simulation tools With few agents, the interactions be-tween the agents and the environment can be realized with existing infras-tructures and tools [52, 66, 18] As the system scales up to hundreds of

19

thousands of agents, in a largely distributed dynamic environment, ing the interactions becomes highly complex A modular design that utilizesthe separation of concerns between the agents and environment, helps managesuch complexity.

manag-However, before discussing an abstract architecture for these systems, thereexists a need to describe agent and environment characteristics

2.2 AES Agent Characteristics

While software agent lacks a universally agreed definition, several featureshave been proposed in the literature that an entity must possess before itcan be reasonably regarded as an agent [84, 6] The following characteristicsapply to AES agents:

• Autonomy: the ability of an agent to operate in a self-governing mannerwithout external control This also means that the agent is able to decidewhich task to perform at any given time

• Environment Awareness: the ability of an agent to operate withinthe context of an environment This also involves the ability of an agent

to partially perceive and interact with its environment This property isparticularly important in AESs

• Sociality: the ability of an agent to communicate, cooperate, coordinateand negotiate with other agents.

• Pro-activeness: the ability of an agent to exhibit opportunistic, directed behavior and take initiatives when appropriate

goal-• Reactiveness: the ability of an agent to respond in a timely manner toevents

2.3 AES Environment Characteristics

We propose to endow the environment with qualities similar to the onesdefined for agents, hence, the following characteristics apply to AES environ-ments:

• Autonomy: the ability of the environment to function in a self-governingmanner without external control

• Agent Awareness: the ability of the environment to partially perceivethe agent population and interact with it

• Interactivity: the ability of the environment to interact with agentsand other environment entities

• Pro-activeness: the ability of an environment to exhibit goal-directedbehavior

• Reactiveness: the ability of an environment to respond in a timelymanner to events.

At first glance, it may seem unnatural to view the environment as capable

of exhibiting qualities most often reserved for agents By defining differentlevels of abstraction, one can see that at the conceptual level agents and envi-ronments are distinct However, as one approaches the implementation level,the concepts merge For example, if agents are people and the environment

is the world, at the conceptual level, to the observer it is evident that thetwo concepts are separate and distinct

However, when implementing this model, to the software engineer, theinformation about the entities exhibit stronger and stronger similarities (seeFigure 2.1)

In the following paragraphs, we illustrate how these characteristics areapplied to AES where the environment is subdivided into cells

1 Pro-activeness Both agents and the environment have goals to satisfy.Agent goals are goals in the traditional sense whereas the goal of anenvironment cell is to maintain a stable state for the situated agents Forexample, a cell’s goal might be to recover a path in the shortest period oftime following the occurrence of an external event simulating a naturalphenomenon If a path is unusable following a flood event, the cell makes

Implementation Level Conceptual Level

Figure 2.1 Agent and Environment Commonalities

every effort to recover a near approximation to the original path in theshortest time.

2 Interactivity Both agents and environments communicate We guish between three types of communication: agent to agent, cell to cell,and agent to cell (see Figure 2.2)

distin-• Cell to cell interactivity This type of communication centers aroundexchanging information that may affect the state of another cell Forexample, if two adjacent cells c1 and c2 share a path, and c1 receives

an external event to remove the path, c1 will act on its portion of thepath and propagate the information to c2

• Agent to cell interactivity Agents communicate with cells to obtain

a vision of their immediate surroundings as well as to inform the cell

of a state change incurred by them For example, as an agent enters

a cell, it passes its business card to the cell The agent’s businesscard symbolizes the minimal amount of information needed by theenvironment This includes the agent’s id, position, etc

• Cell to agent interactivity Cells communicate with agents to impartchanges to the state of the cell that may affect an agent’s plan Forexample, if a path is removed from a cell’s graph, the agents withinthe cell are informed so that they may replan their trip if necessary

Figure 2.2 Interactivity illustration for AES

3 Partial Awareness Cells have a partial view of the agent population andagents have a partial view of the environment A cell is aware only ofthose agents within the cell’s boundaries; there is no need to know aboutagents that cannot affect its state An agent is only aware of the state ofthe cell in which it is situated; there is no need to know about cells that

it cannot see

Therefore, it can be concluded that an agent and an environment cellpossess many of the same qualities even though they realize those qualities

in different manners

2.4 Design Principles

There are numerous design principles that apply to system development Inthis Section, those principles that play significant roles in AES design arepresented [59, 71]

• Conceptual Integrity An AES architecture should be true to theagent and environment concepts and should be consistent Brooks arguesforcefully that “conceptual integrity is the most important consideration

in system design” [15]

• Separation of Concerns The significant complexity of MAS opment necessitates the separation between the various aspects of theproblem The following distinctions are proposed:

devel-1 Separation between agents and environment When designing agents,the environment should be viewed as a black box This leads toarchitectures where agents are decoupled from their environment, andvice versa

2 Separation between data, behavioral, functional and communicationviewpoints A designer should address the data, behavioral, functionaland communication processing aspects of the system separately Thisallows a better understanding of the various components