Software Engineering for Multi-Agent Systems IV: Research Issues and Practical Applications

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris ...

Author: Alessandro Garcia | Ricardo Choren | Carlos Lucena | Paolo Giorgini | Tom Holvoet | Alexander Romanovsky

24 downloads 411 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Moshe Y. Vardi Rice University, Houston, TX, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

3914

Alessandro Garcia Ricardo Choren Carlos Lucena Paolo Giorgini Tom Holvoet Alexander Romanovsky (Eds.)

Software Engineering for Multi-Agent Systems IV Research Issues and Practical Applications

13

Volume Editors Alessandro Garcia Lancaster University, Computing Department, InfoLab 21, Lancaster, LA1 4WA, UK E-mail: [email protected] Ricardo Choren SE/8, IME, Praça General Tibúrcio 80, Urca 22290-170, Rio de Janeiro/RJ, Brazil E-mail: [email protected] Carlos Lucena Pontifical Catholic University of Rio de Janeiro, Computer Science Department Rio de Janeiro, RJ - 22453-900, Brazil E-mail: [email protected] Paolo Giorgini University of Trento, Department of Information and Communication Technology Via Sommarive, 14, 38050 Povo (Trento), Italy E-mail: [email protected] Tom Holvoet K.U. Leuven, Department of Computer Science Celestijnenlaan 200A, 3001 Leuven, Belgium E-mail: [email protected] Alexander Romanovsky University of Newcastle, School of Computing Science Newcastle upon Tyne, NE1 7RU, UK E-mail: [email protected]

Library of Congress Control Number: 2006923375 CR Subject Classification (1998): D.2, I.2.11, C.2.4, D.1.3, H.3.5 LNCS Sublibrary: SL 2 – Programming and Software Engineering ISSN ISBN-10 ISBN-13

0302-9743 3-540-33580-3 Springer Berlin Heidelberg New York 978-3-540-33580-1 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springer.com © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 11738817 06/3142 543210

Foreword

With the integration of computing and communication into the very fabric of our social, economic, and personal existence, the manner in which we think about and build software has become the subject of intense intellectual, scientific, and engineering reexamination. New computing paradigms have been proposed and new software architectures are being examined. The study of multi-agent systems (MAS) is one important movement energized by a growing awareness that application development may need to follow radically new paths. Fundamentally, MAS denotes a new software specification and design paradigm. Moreover, when viewed in the context of large-scale deployment, it emerges as the embodiment of the quintessential concerns facing the software engineering community today. As computing and communication permeates the essential aspects of the societal infrastructure, software must become more nimble, slimmer, more natural, and more discrete. Software must integrate itself in an organic way into the activities it serves and the resources it exploits. Technological changes and their societal implications clearly impacted the evolution of MAS research. The starting point was the wired network that facilitated the development of distributed applications for which MAS appeared to offer a novel design strategy. The introduction of base stations and wireless communication (with devices that move along the fringe of the wired network and can disconnect unexpectedly for extended periods of time) highlighted the importance of disconnected interactions, highly decoupled computing, and migration across the wireless link. MAS proved to be particularly well suited to respond to the requirements of the new environment; for example, it seems natural for a disconnected host to rely on an agent migrated to the wired network to carry out work on its behalf. The advance of ad hoc networks offered still new opportunities and also new challenges for MAS research. Structuring applications as communities of agents that can float over a physically mobile infrastructure is clearly an intellectually exiting possibility to consider, but finding applications that match well to this environment remains a contentious point among researches and practitioners. Finally, MAS made its presence felt even in the newly emerging field of sensor networks. The flexibility of the basic MAS paradigm is indeed remarkable and all indicators point to its continuing evolution towards enabling application developers to achieve increasingly more effective utilization of the deployed computing and communications infrastructures. The most visible MAS contributions can be attributed to successful abstraction and conceptualization efforts that demonstrate the expressive power of the various embodiments of the basic paradigm across multiple technological substrates. However, only the combination of exciting conceptual frameworks with analytical power, design methodology, and engineering practice will lead to achieving a truly high impact on the society at large. These concerns should be formative elements for the MAS research agenda. Interestingly enough, the

VI

Foreword

content of this volume matches well with this perspective on the field. Papers on context awareness, coordination, and modeling continue to focus on strengthening and deepening our understanding of conceptual frameworks having both scientific and practical significance. Papers addressing requirements, architecture, and dependability capture methodological and engineering concerns. Analysis alone receives somewhat more limited coverage in this volume. MAS research is well positioned in terms of technical coverage of the field and promises to lead to the deployment of nimble and responsive user-centered applications. However, the community needs to recognize that in today’s environment the marketplace has a greater than ever voice in determining research relevance and impact. This is not due to the evolving patterns of research funding, but due to the high degree of integration of computing and communication into the workings of a modern society. Acknowledging this should lead to the emergence of a research paradigm that focuses on the creative integration of conceptual, engineering, and application concerns in the shaping of the next generation of MAS. I view this volume as an important step along this path. December 2005

Gruia-Catalin Roman Washington University in Saint Louis

Preface

Software is becoming present in every aspect of our lives, pushing us inevitably towards a world of autonomous distributed systems. The agent-oriented paradigm holds great promise for responding to the new realities of large-scale distributed systems. It is strongly rooted in the theories underlying multi-agent systems (MASs) and, as a result, offers appropriate software engineering abstractions and mechanisms to address issues such as context-awareness, openness, coordination, ubiquity, mobility, adaptation, and cooperation among heterogeneous and autonomous parties. Not surprisingly, multi-agent software development is one of the most rapidly growing areas of research in academia and software industry. Nevertheless, the complexity associated with software agents and MASs is considerable, posing new challenges to software engineering community. Without adequate development techniques and methods, MASs will not be sufficiently dependable, trustworthy and extensible, thus making their wide adoption by the industry more difficult. Commercial success of MAS applications requires scalable solutions based on well-understood software engineering approaches that ensure effective deployment and enable reuse. A large MAS is complex in many ways. When a set of agents interact over open heterogeneous environments, several problems emerge. For example, openess requires appropriate abstractions and mechanisms for supporting contextawareness. In addition, it makes their coordination and management challenging and increases the probability of exceptional situations, security holes and unexpected global effects. Moreover, as users and software engineers delegate more autonomy to their MASs and put more trust in their results, new concerns arise in real-life applications. Yet many of the existing agent-oriented solutions are far from ideal; in practice, systems are often built in an ad-hoc manner, are error-prone, not scalable, not dynamic, and not generally applicable to largescale environments. If agent-based applications are to be successful, software engineering approaches will be needed to enable scalable deployment. The main motivation for producing this book is the Software Engineering for Large-Scale Multi-Agent Systems (SELMAS) workshop series, which focuses on bringing together software engineering practitioners and researchers to discuss the several issues arising when MASs are used to engineer complex systems. SELMAS 20051 was the fourth edition of the workshop, organized in association with the 27th International Conference on Software Engineering (ICSE), held in Saint Louis, USA, in May 2005. The theme of this particular workshop edition was “Software Everywhere—Context-Aware Agents.” To produce the book based on this workshop edition, we decided to extend the workshop coverage, and to 1

Garcia, A. el al.: Software Engineering for Large-Scale Multi-Agent Systems - SELMAS 2005 (Workshop Report). ACM Software Engineering Notes, Vol. 30, N. 4, July 2005.

VIII

Preface

invite several of the workshop participants to write chapters for books based on their original position papers, as well as several other leading researchers in the area to prepare additional chapters. Thus, this book is a continuation of a series of three previous ones2−4 . This book brings together a collection of 15 papers addressing a wide range of issues in software engineering of MASs, reflecting the importance of agent properties in today’s software systems. The papers in this book describe recent developments in specific issues and practical experience. At the end of each chapter, the reader will find a list of relevant references for further reading. The papers in this book are grouped into five sections: Context-Awareness, Coordination, Dependability, Modelling, and Requirements and Software Architecture. The first section is especially dedicated to the SELMAS 2005 theme. The other sections contain high-quality contributions on other important complementary concerns in MAS development. We believe that this carefully prepared volume, describing the most recent developments in the field of software engineering for MASs, will be of particular value to all readers interested in these key topics. With a comprehensive selection of case studies and software engineering solutions for MASs applications, this book provides a valuable resource for a wide audience of readers. The main target readers for this book are researchers and practitioners who want to keep up with the progress of software engineering of MASs, individuals keen to understand the interplay between agents and other software development paradigms, and those interested in experimental results from MAS applications. Software engineers involved in particular aspects of MASs as a part of their work may find it interesting to learn about application of software engineering approaches in building real systems. Some chapters in the book discuss the transitions involving different MAS development phases, such as requirements, architecture specifications, and implementation. One key contribution of this volume is the description of the latest approaches to reasoning about complex MASs. We are confident that this book will be of considerable use to the software engineering community by providing many original and distinct views on such an important interdisciplinary topic, and by contributing to a better understanding and cross-fertilization among individuals in this research area. Our thanks go to all our authors, whose work made this book possible. Many of them also helped during the reviewing process. We would also like to express our gratitude to the members of the Evaluation Committee who were generous with their time and effort when reviewing the submitted papers. We specially thank all people involved—authors, workshop participants, and 2

3

4

Garcia, A., Lucena, C., Castro, J., Zambonelli, F., Omicini, A. (eds.): Software Engineering for Large-Scale Multi-Agent Systems. LNCS, vol. 2603, Springer-Verlag, April 2003. Lucena, C., Garcia, A., Romanovsky, A., Castro, J., Alencar, P. (eds.): Software Engineering for Multi-Agent Systems II. LNCS, vol. 2940, Springer-Verlag, February 2004. Choren, R., Garcia, A., Lucena, C., Romanovsky, A. (eds.): Software Engineering for Multi-Agent Systems III. LNCS, vol. 3390, Springer-Verlag, February 2005.

Preface

IX

reviewers—for making this book series and the SELMAS workshop editions a high-quality scientific joint project.

December 2005

Alessandro Garcia (Lancaster University, UK) Ricardo Choren (IME-Rio, Brazil) Carlos Lucena (PUC-Rio, Brazil) Paolo Giorgini (University of Trento, Italy) Tom Holvoet (K. U. Leuven, Belgium) Alexander Romanovsky (University of Newcastle, UK)

Organization

Evaluation and Program Committee N. Alechina (University of Nottingham, UK) E. Alonso (City University London, UK) R. Ashri (University of Southampton, UK) B. Bauer (Universität Augsburg, Germany) C. Bernon (IRIT, France) M. Brian Blake (Georgetown University, USA) P. Bresciani (IRST, Italy) J-P. Briot (Université Paris VI, France) G. Cabri (Universit` a di Modena e Reggio Emilia, Italy) J. Castro (UFPE, Brazil) M. Cossentino (ICAR-CNR, Italy) S. Cost (University of Maryland Baltimore County, USA) J. Debenham (University of Technology - Sydney, Australia) J. Dix (University of Manchester, UK) C. A. Fern´ andez (Universidad Politécnica de Madrid, Spain) M. Fredriksson (Blekinge Institute of Tech., Sweden) C. Ghidini (ITC-irst, Italy) M-P. Gleizes (IRIT, France) Z. Guessoum (Université Paris VI, France) B. Henderson-Sellers (U. of Technology - Sydney, Australia) K. Henricksen (University of Queensland, Australia) J. Indulska (University of Queensland, Australia) C. Jonker (Vrije Universiteit Amsterdam, The Netherlands) M. Kolp (Université Catholique de Louvain, Belgium) J. C. Maldonado (USP - So Carlos, Brazil) V. Mascardi (Università di Genova, Italy) H. Mouratidis (University of East London, UK) J. Odell (Agentis Software, USA) E. Oliveira (Universidade do Porto, Portugal) A. Omicini (Università di Bologna, Italy) S. Ossowski (Universidad Rey Juan Carlos, Spain) L. Penserini (ITC-irst, Italy) G. Rossi (Universidad Nacional de La Plata, Argentina) A. G. Serrano (Universidad Politécnica de Madrid, Spain) J. M. Serrano (Universidad Rey Juan Carlos, Spain) O. Shehory (IBM Research Center in Haifa, Israel) J. Shepherdson (British Telecommunications plc., UK) A. von Staa (PUC-Rio, Brazil) M. Stal (Siemens AG, Germany)

XII

Organization

W. Truszkowski (NASA, USA) M. Weiss (Carleton University, Canada) D. Weyns (Katholieke Universiteit Leuven, Belgium) M. Winikoff (RMIT University, Australia) F. Zambonelli (Universit` a di Modena e Reggio Emilia, Italy) A. Zisman (City University London, UK)

Table of Contents

Context-Awareness and Coordination Policy-Driven Configuration and Management of Agent Based Distributed Systems Anand R. Tripathi, Devdatta Kulkarni, Tanvir Ahmed . . . . . . . . . . . . .

1

Views: Middleware Abstractions for Context-Aware Applications in MANETs Kurt Schelfthout, Tom Holvoet, Yolande Berbers . . . . . . . . . . . . . . . . . .

17

An Adaptive Distributed Layout for Multi-agent Applications Koenraad Mertens, Tom Holvoet, Yolande Berbers . . . . . . . . . . . . . . . .

35

Self-organizing Approaches for Large-Scale Spray Multiagent Systems Marco Mamei, Franco Zambonelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

Coordination Artifacts as First-Class Abstractions for MAS Engineering: State of the Research Andrea Omicini, Alessandro Ricci, Mirko Viroli . . . . . . . . . . . . . . . . . .

71

Modeling Analysis and Design of Physical and Social Contexts in Multi-agent Systems Florian Klein, Holger Giese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

Engineering Organization-Based Multiagent Systems Scott A. DeLoach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

109

Developing and Evaluating a Generic Metamodel for MAS Work Products Ghassan Beydoun, César Gonzalez-Perez, Brian Henderson-Sellers, G. Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

126

Agent Roles, Qua Individuals and the Counting Problem Giancarlo Guizzardi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143

Requirements and Software Architecture A Product-Line Approach to Promote Asset Reuse in Multi-agent Systems Josh Dehlinger, Robyn R. Lutz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

161

XIV

Table of Contents

Characterization and Evaluation of Multi-agent System Architectural Styles Paul Davidsson, Stefan Johansson, Mikael Svahnberg . . . . . . . . . . . . . .

179

Improving Flexibility and Robustness in Agent Interactions: Extending Prometheus with Hermes Christopher Cheong, Michael Winikoff . . . . . . . . . . . . . . . . . . . . . . . . . .

189

Patterns for Modelling Agent Systems with Tropos Haralambos Mouratidis, Michael Weiss . . . . . . . . . . . . . . . . . . . . . . . . . .

207

Dependability On the Use of Formal Specifications as Part of Running Programs Giovanna Di Marzo Serugendo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

224

Adaptive Replication of Large-Scale Multi-agent Systems – Towards a Fault-Tolerant Multi-agent Platform Zahia Guessoum, Nora Faci, Jean-Pierre Briot . . . . . . . . . . . . . . . . . . .

238

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

255

Policy-Driven Configuration and Management of Agent Based Distributed Systems Anand R. Tripathi, Devdatta Kulkarni, and Tanvir Ahmed Department of Computer Science, University of Minnesota, Minneapolis, MN 55455, USA {tripathi, dkulk, tahmed}@cs.umn.edu

Abstract. In this paper, we demonstrate a policy-driven approach for building and managing large scale agent based systems. We identify different classes of policies for agent based component integration. We also identify the system services and mechanisms that are required for policydriven integration of components and their management. Policies are derived from the application level requirements and are used in dynamic configuration of agent based systems. Through case studies of two applications we demonstrate the utility of the policy-driven component integration approach in distributed agent systems.

1

Introduction

Building and managing large distributed component systems is becoming an increasingly challenging task. Continuous intervention by system administrators is generally limited in large-scale distributed environments. System support is needed for reconfiguration and reorganization when systems evolve with the addition of new components. Component based approaches for structuring distributed systems have sufficiently matured and are widely used today [1]. New challenges in using the component technology are concerned with building systems using dynamic integration of active components such as agents [2]. Policy-driven approaches have been used previously for managing distributed systems [3]. In this paper we propose a policy-driven approach for building distributed agent systems. We identify the policy classes and the essential services required in building distributed agent systems. Policies are derived from an application’s functional and non-functional requirements. The functional requirements of an application may require certain components to be present on an agent or certain agents to coordinate towards some common goals. The non-functional requirements of an application may state that all the agents and components should be monitored for failures. In the policy-driven integration approach, the agent composition and the inter-agent interactions are driven by the policies which are derived from the high level requirements. The policies act as a glue in creating a dynamic configuration of

This work was supported by National Science Foundation grants 0087514 and 0411961.

A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 1–16, 2006. c Springer-Verlag Berlin Heidelberg 2006

2

A.R. Tripathi, D. Kulkarni, and T. Ahmed

the system in order to satisfy the functional and non-functional requirements. Since the application requirements are realized through a set of policies hence it is important to monitor events indicating policy violations (policy-events) and perform policy-actions to ensure that the requirements are not violated. Such an event and an action pair forms a rule. These rules are derived from the policies and form the basic mechanism for building policy-driven systems. An agent is an active object encapsulating other components and is considered as a first-class component. It serves as an execution environment with security privileges; representing some principal in the environment. Moreover, an agent may be capable of migrating in the network. In this paper we use the term component to refer to objects that are contained in an agent; these objects may be active or passive. This agent model is supported through the Ajanta mobile agent programming framework [4, 5]. In policy-driven distributed agent systems, there are intra-agent policies for component integration, inter-agent policies for agent-to-agent interactions, and policies to ensure system robustness. Based on these policies, rules are derived for dynamic integration of agents and components in the system. Agent based distributed computing models provide an ideal foundation for policy-driven component integration. Agents are autonomous entities that can encapsulate and enforce local policies. Autonomous agents are capable of learning and adapting to the new or modified global policies that dictate the interactions among distributed agents. Mechanisms of self-configuration, self-monitoring and recovery can be built using agent’s capabilities. In this paper we identify policy classes and present essential services and mechanisms for building distributed agent systems. We use two case study examples to elaborate on this policy classification. One of these systems is targeted towards network monitoring using mobile agents [6] and the other is targeted towards building secure distributed collaborative applications from their highlevel specifications [7, 8, 9]. Both these systems are based on the Ajanta mobile agent programming framework. These two applications lie at the opposite end of the spectrum of building policy-driven distributed agent systems. Network monitoring represents the class of systems that are open and evolving. Such systems do not have any limit on the number of agents present in the domain. There can be spontaneous arrival or departure of agents in the domain. Network monitoring system is targeted towards large domains where hosts, agents, or components may get added or removed over a period of time. Network monitoring policies are related to the configuration, monitoring, and failure-recovery of agents and components in the domain. On the other hand the specification driven secure distributed collaboration framework is used for synthesizing collaborative application by integrating a set of agents and components having specific collaboration and security requirements. Only a fixed set of agents can participate in the collaboration. External agents cannot join the collaboration spontaneously after the collaboration environment has been instantiated. In this way the secure distributed collaboration system represents a closed agent system.

Policy-Driven Configuration and Management

3

Section 2 discusses the central concepts of the policy framework. We discuss the policy classification and the core set of services and mechanisms required for building policy-driven agent based systems in that section. In Section 3 we use the two representative applications (network monitoring, and secure distributed collaboration) to elaborate on the policy framework and show its utility in developing real systems. In Section 4 we compare the policies in network monitoring and distributed collaboration systems and conclude in Section 6.

2

Policy Framework for Agents in Distributed Environments

Figure 1 shows an agent immersed in the environment and interacting with other agents and services in the environment. Associated with each agent are two kinds of attributes: intrinsic and extrinsic. Intrinsic attributes of an agent are determined by the application level requirements. These include agent’s functional role, components present in the agent, and the associated component policies. An agent acquires extrinsic attributes when it enters an environment. These are determined by both application and domain level requirements. The extrinsic attributes of an agent include the external context information for the agent, information about other agents of specific attributes present in the environment, and agent interaction policies related to other agents in the domain. Other components may also need to be deployed on the agent, depending on the extrinsic attributes. Policies related to intra-agent components and inter-agent interactions determine the behavior of the agent. These policies depend upon the functional and Agent Based Distributed Computing Environment Agent Agent

Intrinsic Attributes

Agent Components

Policies

Agent

Role

Extrinsic Attributes Components Context Policies

Agent Interaction Policies

Agent

Agent Interaction Interface

Policy Enforcing Environment Functional, Non−functional and Domain Requirements (System level policies)

Configuration Service Failure Monitoring Service

Discovery Service Naming/Authentication Service

Infrastructure Services

Fig. 1. Agent immersed in the environment

4


non-functional requirements of an application and the domain specific requirements of the application domain. Below we present policies classes for building distributed agent systems. 2.1

Policy Classification

Related to any software application there are three kinds of requirements: functional requirements, non-functional requirements, and domain requirements [10]. Functional requirements capture the application’s essential functionality and services it should provide. Non-functional requirements capture aspects of security, performance, and fault-tolerance of the application which are orthogonal to the application’s core functionality. Domain requirements address the restrictions imposed on the application by the domain of usage of the application. We use system level policies to represent the above three kinds of application requirements. These policies include functional requirements such as which agents or components should be installed for the required functionality, how many instances of various agents are required and agent-to-host mappings. These policies also include non-functional requirements such as failure monitoring and timely recovery of agents in the system. In order to satisfy system level policies, we refine them into agent interaction policies and component integration policies. – Agent Interaction Policies: These policies determine the set of agents with whom an agent with a given set of attributes should communicate and interact with in some specific ways. Policies may also enforce certain constraints on these interactions based on security requirements. For example, an agent may be restricted to communicate only with the agents residing in a specific domain or owned by some designated set of users. The interaction relationships among agents, as determined by policies, are dynamic in nature as agent attributes and functionalities may change with time. – Component Integration Policies: These policies are related to the components deployed within an agent. Constraints on component behavior or relationship between different components deployed within an agent are captured by these policies. They also include the list of local and remote events that will invoke the component, access to any system resources required by the component, and co-location of other components for proper functioning. These policies also relate to other component attributes such as what state of the component should be checkpointed, how often checkpoints should be taken, and if the component gets deleted then which other local and remote components should be informed about this. These policies can be defined at the component design time or can also be modified dynamically later. 2.2

Services for Policy Enforcement in Agent Based Distributed Systems

We have identified above different policy classes for realizing the application level requirements in distributed agent systems. In such an approach it is important to monitor policy violations and perform policy reinforcement actions to ensure


Agent Discovery Service

Monitoring Policies

5

Configuration Service Configuration Database and Policies

Failure Monitoring Service

Policy Events

Monitoring

Policy Enforcement Conditions

Configuration Control Mechanisms

Policy Enforcement Actions

Control

Agent Computing Environment

Fig. 2. Policy Driven Configuration Management

that the application requirements are not violated at any time. System level services and mechanisms are required for performing such policy monitoring and configuration control activities. In our framework these actions are performed by the following services: agent discovery service, failure monitoring service, and configuration service. Figure 2 shows these essential services and the interactions between them. – Agent Discovery Service: This service is required for integrating new agents in the system. Its function is to detect the presence of new agents and notify the configuration service. In some architectures, the agents may first discover the configuration service and then inform the discovery service of their presence. – Failure Monitoring Service: This service performs the failure monitoring of agents, components and other services present in the domain. It generates failure events corresponding to the failure of an entity and sends these events to the configuration service. – Configuration Service:As new agents and components are deployed in such an environment, they need to self-configure according to the system policies. Similarly, when a component is removed from the system due to failures, or administrative reasons, or operational conditions (such as mobility of devices), appropriate reconfiguration actions are needed to be executed to preserve the invariants implied by the system policies. Configuration service has the knowledge of the global configuration policies and is able to take suitable actions when configuration change events are detected. The configuration service knows the “configuration change events” (policy-events) that are considered critical for policy enforcement, and it instructs agent discovery service and failure monitoring service about its interest in the detection of such events. These services detect such policy-events in the system and notify the configuration service of such changes. The configuration service is responsible for evaluating policies and enforcing them when critical changes occur. The configuration service consists of a configuration database and the policy enforcement engine. Various agent related queries can be performed on this

6


database. Examples of such queries are, finding all agents having a particular attribute, and finding an agent having certain set of attributes. This database can also store the initial configuration information for different types of agents in the system. This can be used to restart a failed agent. For example, it may list the set of components that must be installed on an agent at the time of restart and any specific initialization that needs to be performed for such components. In our approach, an important design principle is to require each agent to perform its own recovery after it has been restarted, so the configuration service is rarely involved in maintaining any information about an agent’s local state. Similarly, components within an agent should be designed to reconstruct their execution state, through checkpoints or other mechanisms such as soft-state [11, 12]. The configuration service receives configuration change events when the agent discovery service informs it of the addition of new agents/components in the system, or the failure monitoring service informs it of any agent failures or departures. On detecting agent arrival, the configuration service has to inform the arriving agent of the system level policies that determine its functionalities and interaction relationships with the existing agents. Some new components may also need to be integrated in the agent according to the system level policies. On detecting the failure of an agent, the configuration service may try to restart the failed agent on the same or a different host. Existing agents may need to be informed of the agent restart so that they can setup appropriate interaction relationships with the restarted agent. On receiving event notifications from the agent discovery service and the failure monitoring service, the configuration service performs the following functions. It identifies the policies that depend on the change events and identifies the agents that are affected by those policies. It also executes the actions required for enforcing the policies. In some applications, the policy enforcement actions may need to be performed cooperatively by a set of distributed agents in the environment. In such cases, the configuration service notifies all those agents. These actions ensure that the resulting system state conforms to the requirements and constraints implied by the policies. As shown in Figure 2, the above functions of the configuration service are performed by three kinds of entities namely policy enforcement conditions, policy actions, and configuration control mechanisms. Policy enforcement conditions identify the conditions under which a policy event should trigger policy actions. A policy action determines the set of agents and components that are affected by a given event according to the policies. It also determines which new agents and components need to be created and installed in the system, and how the interaction relationships among the agents in the system needs to be altered. For this, it may query the configuration database. Finally, it invokes the appropriate configuration control mechanisms to realize the necessary changes in the configuration. Agents, and the components contained in them, may also explicitly register with the configuration service their interests in certain specific kinds of configuration change events based on their local policies. This requires the


7

configuration service to maintain such events of interest, called call-back information, for existing agents. This call-back information is also stored in the configuration database.

3

Case Studies

In this section we provide two case studies demonstrating the utility of the policy framework for agent based distributed environments. 3.1

Network Monitoring System

Konark [6] is a network monitoring system which monitors hosts in a network for various kinds of events. In this system, mobile agents are launched to monitor each host in the environment. Each agent contains components, termed detectors, to detect events in the environment. New detectors can be added to an agent remotely. Examples of events in this system include user logins, program executions on a host, file modifications, and network traffic patterns related to intrusions. Agents can subscribe to events from other agents to detect compound events based on correlation of events from distributed sources. This is supported through the event subscription/notification mechanisms provided by Konark. The subscription/notification model for communication among agents is implemented using the underlying Ajanta agent communication model based on RMI. The execution of a detector in an agent can be triggered by events generated in the same agent or other agents in the environment. Other researchers have also developed similar event based systems for monitoring distributed systems [13, 14]. In our approach we use event detection and handling as a building block for policy management functions. The list of local or remote events that can trigger a detector form a triggering relation among detectors. It is termed trigger dependency. This makes Konark useful for correlating events occurring at different locations in a network system. Events are also stored in databases for long-term correlations. We illustrate the usefulness of the policy framework of Section 2 by showing its utility through three example requirements of network monitoring. The first two requirements are application level functional requirements, while the third requirement is system robustness requirement. For each high level requirement, we identify the policies and corresponding policy events and policy actions. Requirement 1: One of the application level requirements in the monitoring system is to detect abnormally high number of root login activities (successful/unsuccessful attempts) in the entire domain in a specified period of time. Following policies and rules are derived from this requirement. 1. (System level Policy 1): All agents in the system should contain the login detector. – Policy-Event: Arrival of a new agent in the domain. – Policy-Action: Install login detector in that agent.

8


2. (System level Policy 2): At least one agent should be present in the system to perform root login correlation across the entire domain. – Policy-Event: Failure of root login correlator agent. – Policy-Action: Install root login correlation component on another agent. 3. (Agent Interaction Policy): All the agents should send locally detected root login events to the correlator agent. – Policy-Event 1: Arrival of a new agent in the domain. – Policy-Action 1: Establish event subscription/notification relationship between the newly arrived agent and the correlator agent. – Policy-Event 2: New root login correlator agent is created. – Policy-Action 2: Change the event notification policy for all the agents such that they start reporting the root login events to the new correlator agent. 4. (Component Integration Policy): All the components required for root login detection should be present on an agent. The component integration policies for the root login detector at each host are shown in Figure 3. A periodic timer event triggers the execution of the Syslog Event detector. This detector generates events based on new log entries in the system log files. A Syslog Event triggers executions of the Connection Event detector, which filters and generates any login related events. This event triggers detectors for specific kinds of login, such as SSH, Telnet, and Rlogin. These detectors are filters which check if a given connection event belongs to a specific class. Any of these events, both local and remotely generated, trigger the RootLogin detector whose function is to determine if the login corresponds to the superuser. A trigger dependency marked only as local implies that the triggering event detector must be co-located in the same agent with the triggered detector. Similarly, a dependency marked only as remote implies that the triggering

Timer local

Syslog Event Detector local

Connection Event Detector local

SSH Detector Local or remote

local

Telnet Detector Local or remote

local

Rlogin Detector Local or remote

RootLogin Detector

Fig. 3. Component Trigger Dependency: Root Login Event Trigger Dependency


9

event detector must be in an agent different from the one containing the triggered detector. – Policy-Event: Failure of a required component within an agent. – Policy-Action: Deploy the failed component on the agent. Requirement 2: Network traffic should be continuously monitored for traffic using protocols and ports listed in the alerts posted in the known attack vectors on the CERT web site (http://www. us-cert.gov/channels/techalerts.rdf). Following policies and rules are derived from this requirement. 1. (System level Policy 1): There should be a monitoring agent in the system that should continuously monitor the CERT web site. – Policy-Event: The agent responsible for monitoring the CERT web site fails. – Policy-Action: Another agent should be started to perform the monitoring of the CERT web site. 2. (System level Policy 2): There should be at least one agent monitoring the network traffic for vulnerable port numbers appearing in the alerts posted on the CERT web site. – Policy-Event : Traffic monitoring agent fails. – Policy-Action : Restart the monitoring agent. Requirement 3: All the agents in the system should be monitored for failures. Each agent should contain a heartbeat monitor component and should send AgentAlive events to the AgentFailure monitoring agent. Following policies and rules are derived from the above requirement. 1. (System level Policy 1): All agents should be deployed with heartbeat monitoring component – Policy-Event: Arrival of a new agent in the domain. – Policy-Action: Deploy heartbeat monitoring component on the agent. 2. (System level Policy 2): There should be at least one agent that performs failure monitoring functionality for all other agents in the domain. – Policy-Event: The agent responsible for failure monitoring of other agents fails. – Policy-Action: Designate another agent for performing failure monitoring of other agents in the domain. 3. (Agent Interaction Policy): All agents should send heartbeat messages to the failure monitoring agent. – Policy-Event 1: Arrival of a new agent. – Policy-Action 1: Establish the appropriate event subscription/notification relationship between the new agent and the heartbeat monitoring agent. – Policy-Event 2: Restarting of the failure monitoring agent. – Policy-Action 2: Establish the event subscription/notification relationship between the restarted failure monitoring agent and all other agents.

10


We have tested configurations consisting of up to 1000 agents in our network test bed. It takes less than five minutes (4 minutes and 17 seconds) to perform a policy-driven configuration of the network monitoring application consisting of 1000 agents. System configuration time grows linearly with an increase in the number of agents. Each arriving agent needs to be configured according to the system level policies. In our current setup, a special agent performs the functions of the configuration service. With an increase in the number of agent arrivals, the load on this configuration agent also increases thus increasing the time required for system configuration. 3.2

Secure Distributed Collaboration System

Secure distributed collaboration framework [8] supports construction of secure collaborative activities from their high level specifications. Figure 4 shows the steps involved in creating the collaboration environment. The specification of an activity defines a set of roles and a shared object space in which collaborating users perform their tasks. Policies related to activities, roles, user context and objects are derived from the collaboration specification. The middleware contains generic manager agents for activity, role, and object management. The derived policies are given to the respective manager agents to realize a particular collaboration environment. The specification model supports expression of the desired policies for coordination and dynamic security. Users participate in a collaboration through roles by executing operations (tasks) associated with the roles. A user’s membership in a role represents a set of privileges, and these privileges are dynamically constrained by associating event-based preconditions with the role operations. Manager agents communicate and interact with each other according to the policies derived from the activity’s specification. The various different kinds of policies given to the agents in a collaboration environment are related to activity

Collaboration Specification

Activity Policy Modules

Activity Manager Agent

Role Policy Modules

Role Manager Agent

Object Policy Modules

Object Manager Agent

Runtime Collaboration Environment

Fig. 4. Collaboration Environment Creation Process

Policy-Driven Configuration and Management 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

11

Activity Meeting { ActivationConstraint currentTime > 8.00 am & currentTime < 6.00 pm Object room Object projector Object presentation Role Accountant { Operation DisplayFinancialData Precondition #(Chairperson.ApprovePresentation) = 1 & room.isPresent(thisUser) & room.isPresent(member(Chairperson)) Action projector.display(data) } Role Chairperson { AdmissionConstraint #(members(thisRole)) < 1 Operation ApprovePresentation Action presentation.approve() } } Fig. 5. Context aware collaboration activity specification

and role instantiation, role admission/activation, operation preconditions, and object access control. Policy-events are related to activities, roles, operations and services. Examples of events include instantiation of an activity, invocation of role operation, and admission/removal of a user from a role. The details of this model can be found in [8]. Figure 5 shows an example specification of a meeting activity. The activity declares three objects (room, projector and presentation) and two roles (Accountant and Chairperson). A role provides operations through which role members can access objects. Role operations can have preconditions. A precondition is a boolean condition involving two types of events: cardinality based events and query events. Cardinality events are related to the count of role operation invocations and query events are related to the boolean queries over the objects. The operator # is used to obtain the role operation invocation count. An activity can have ActivationConstraint for restricting the instantiation of the activity and a role can have AdmissionConstraint restricting the admission to the role. The specification in Figure 5 captures the following collaboration requirements. 1. The activity should be instantiated between 8.00 am and 6.00 pm (lines 2-3) 2. User in the Accountant role is allowed to invoke the DisplayFinancialData operation only if the Chairperson role has executed the ApprovePresentation operation and the members of the Accountant role and the Chairperson role are present in the room (lines 8-13). 3. Only one member is allowed to be present in the Chairperson role (lines 15-17).

12


These coordination and security requirements are enforced through the following set of policies. Requirement 1 restricts the instantiation of activity only within the allowed time. This policy is enforced at the Activity Manager. In this model, events are used to represent operation invocation by role members and any object related queries. As part of requirement 2, the Accountant role manager subscribes to the ApprovePresentation operation event from the Chairperson role manager and user presence events from the room object. Such events are conveyed to the appropriate subscribers on their occurrence. These form the agent interaction policies. For satisfying requirement 3, the role manager corresponding to the Chairperson role monitors user presence in the role. This policy is enforced by the Chairperson role manager component and involves no interaction with any other entity. This is the component integration policy for this example. All these policies are derived from the specification of the collaborative activity an example of which is shown in Figure 5. In order to change the policies one has to write a new specification. Writing a new specification results in the creation of a new collaboration environment. It is not possible to change the policies once the collaboration environment is realized. 3.3

Policy Derivation

In the policy-driven agent based component integration approach presented here, identification of the policy-events forms an important step in the approach. In case of Konark based network monitoring, the policy-events and policy-actions are derived manually from the high level requirements. Policies in Konark are expressed as event handlers that are executed when policy-events occur. In case of distributed collaboration system, the policy-events are expressed as preconditions for activity instantiation, role admission and role operation invocation in the XML framework. The policies for a particular collaborative application are also verified for correctness and consistency using SPIN based model checking [15]. In our future work we will explore the specification of Konark’s network monitoring policies through some policy specification language or through an XML specification framework similar to our framework for collaboration system. This will allow expression of policies in a more convenient fashion and also verification of policies for their correctness.

4

Discussion

Both the network monitoring system and the distributed collaboration system have been implemented. Details of the design and implementation can be found in [6] and [8], respectively. Both these systems extend the Ajanta programming model with application specific policies. The policy-driven paradigm provides flexibility in building the inter-agent interactions and dynamically extending the functionality of the agents in both these systems. In fact, policies give the agents the necessary autonomy in performing their tasks and managing their relationships with other agents and components in the system.


13

The nature of policies and the degree of agent autonomy differs between the two systems. Network monitoring is an example of open agent environment which can evolve over time with new agent arrivals, agent departures, and agent failures. In network monitoring system there are policies for configuration management of each detector within an agent, inter-agent communication and agent fail-over and restart. Agents have autonomy in deciding to whom they can report events, the rate at which events could be reported, restarting of a failed detector and maintaining event subscription and notification relationships. On the other hand, the specification driven collaborative application construction framework is used for synthesizing new collaborative applications and is a closed agent system. The policies in the distributed collaboration system deal with event based security and coordination requirements between the participating role agents in collaborative applications. The enforcement of security and coordination constraints for a collaborative application requires that agents be supplied with strict guidelines about event generation and notification, limiting their dynamism as compared to the network monitoring system. Policies help in specifying suitable tradeoffs for scalability of the network monitoring system at an expense of latency in detection of events of interest in the domain. For example, policies can be used to limit the reporting rate of successful root login events generated at a node to the correlator node with a possible delay in detecting whether the number of root login attempts in the domain is above a system defined threshold. The failure monitoring of the agents is also policy-driven wherein an agent can designate its monitoring peers and keep on sending regular AgentAlive events to them.

5

Related Work

The advantages of agent based architectures for building large scale software system are discussed in [16]. The application of agent based designs for building complex control systems are elaborated in [17] with specific concerns for diagnosis and repair functions needed in such systems to ensure robust operations. In [18] a three level model of organizational rules, organizational structures and organizational patterns is developed to address management aspects in open multi-agent environments. Policy-driven approach for building distributed agent systems presented here, reflects similar kinds of notions with specific focus on inter-agent interactions and intra-agent component integration. IETF has been active in the standardization of the terminology [19] and the specification of policy information model [20] for network monitoring. IETF defines the following policy classes: motivational policies (related to identifying whether policy goals are accomplished or not), configuration policies, installation policies, error and event policies, usage policies, security policies, and service polices. This policy classification arises from the requirement of having declarative policy specification, a deliberate design decision by the IETF Policy Framework WG. The agent interaction policies and component integration policies defined in this paper are of procedural nature providing a binding of the application

14


level requirements on to the agents in the domain. Policies are represented as condition-action pairs in the IETF model. In our model, policy conditions are represented as policy-events and policy actions are performed by event handlers. This is also similar to the approach of constraint preservation through the ECA (event, condition and action) model in active databases [21]. Other researchers have considered usage of policies in building agent systems [22]. In their approach policies related to roles, agent authorizations, and agent obligations are represented through Ponder policy language and are enforced through agent based middleware. Their policies are able to capture requirements of an open multi-agent system such as an agent based network management system. In our model, an agent’s access control policies can be realized by constraining its interactions with other agents through the agent interaction policies based on the agent’s role, authorizations, and obligations. Moreover, our policy framework is able to support diverse applications such as network monitoring and secure distributed collaboration. The use of policies and their enforcement is the central concept in our approach for building autonomic system architectures. Similar concepts have been proposed in the past by others in the context of law governed systems [23] and normative multi-agent systems [24, 25]. Law based management of open multiagent distributed systems has been studied in [26]. Policies can be viewed as a form of laws or norms. Similar to normative systems an agent’s policies in our framework are based on the agent’s context such as other agents present in the domain. The social pressure for enforcing norms in normative multi-agent systems is similar to our notion of policy enforcement in which policies are enforced based on the occurrence of policy events. In our work we demonstrate the utility of these concepts in a practical framework. Moreover, we identify the core set of services and mechanisms that are required for policy enforcement in autonomic configuration and management.

6

Conclusion

The design principle of separating policies from mechanisms has been known to system designers for a long time. The difficult part is to identify the policies and build mechanisms that can implement different kinds of policies. In this paper we have studied the application of this principle for building agent based distributed systems. We defined the policy classes and identified essential services for building distributed agent systems. Through two representative case studies we demonstrated the utility of this approach.

References 1. Szyperski, C.: Component Software Beyond Object-Oriented Programming. Addison-Wesley ACM Press (1998) 2. Tripathi, A.: Challenges Designing Next Generation Middleware Systems. Communications of the ACM 45 (2002) 39–42


15

3. Sloman, M.: Policy Driven Management for Distributed Systems. Plenum Press Journal of Network and Systems Management 2 (1994) 4. Karnik, N., Tripathi, A.: Security in the Ajanta Mobile Agent System. Software Practice and Experience 31 (2001) 301–329 5. Tripathi, A., Karnik, N., Vora, M., Ahmed, T., Singh, R.: Mobile Agent Programming in Ajanta. In: Proceedings of the 19th International Conference on Distributed Computing Systems. (1999) 190–197 6. Tripathi, A.R., Koka, M., Karanth, S., Pathak, A., Ahmed, T.: Secure Multi-Agent Coordination in a Network Monitoring System. In: Software Engineering for LargeScale Multi-Agent Systems, 2002 (SELMAS 2002), Springer, LNCS 2603. (2003) 251– 266 7. Tripathi, A., Ahmed, T., Kumar, R., Jaman, S.: Design of a Policy-Driven Middleware for Secure Distributed Collaboration. In: Proceedings of the 22nd International Conference on Distributed Computing Systems (ICDCS). (2002) 393 – 400 8. Tripathi, A., Ahmed, T., Kumar, R.: Specification of Secure Distributed Collaboration Systems. In: IEEE International Symposium on Autonomous Distributed Systems (ISADS). (2003) 149–156 9. Tripathi, A., Kulkarni, D., Ahmed, T.: A Specification Model for Context-Based Collaborative Applications. Elsevier Journal on Pervasive and Mobile Computing 1 (2005) 21 – 42 10. Sommerville, I.: Software Engineering 6th Edition. Pearson Education Asia (2002) 11. Clark, D.D.: The design philosophy of the DARPA internet protocols. In: SIGCOMM, Stanford, CA, ACM (1988) 106–114 12. Candea, G., Cutler, J., Fox, A.: Improving Availability with Recursive MicroReboots: A Soft-State System Case Study. Performance Evaluation Journal 56 (2004) 13. Rowanhill, J.C., Varner, P.E., Knight, J.C.: Efficient hierarchic management for reconfiguration of networked information systems. In: International Conference on Dependable Systems and Networks (DSN’04). (2004) 14. Mansouri-Samani, M., Sloman, M.: Monitoring Distributed Systems. IEEE Network (1993) 20–30 15. Ahmed, T., Tripathi, A.R.: Static Verification of Security Requirements in Role Based CSCW Systems. In: Proceedings of 8th ACM Symposium on Access Control Models and Technologies (SACMAT 2003), New York, ACM (2003) 196–203 16. Jennings, N.R.: An Agent-Based Approach for Building Complex Software Systems. Communications of the ACM (2001) 35–41 17. Jennings, N.R., Bussman, S.: Agent-based control systems: Why are they suited to engineering complex systems? IEEE Control Systems Magazine 23 (2003) 61–73 18. Zambonelli, F., Jennings, N.R., Wooldridge, M.: Organisational Abstractions for the Analysis and Design of Multi-Agent Systems. In: Agent Oriented Software Engineering. (2001) 19. IETF: Terminology for Policy-Based Management. In: RFC 3198. (2001) 20. IETF: Policy Core Information Model – Version 1 Specification. In: RFC 3060. (2001) 21. Ceri, S., Widom, J.: Deriving production rules for constraint maintenance. In: Proceedings of the sixteenth international conference on Very large databases, San Francisco, CA, USA, Morgan Kaufmann Publishers Inc. (1990) 566–577 22. Corradi, A., Dulay, N., Montanari, R., Stefanelli, C.: Policy-Driven Management of Agent Systems. In: Workshop on Policies for Distributed Systems and Networks (POLICY 2001). (2001) 214–229

16


23. Minsky, N., Ungureanu, V.: Law-Governed Interaction: A Coordination and Control Mechanism for Heterogeneous Distributed Systems. ACM Transactions on Software Engineering and Methodology (TOSEM) 9 (2000) 273 – 305 24. Lopez, F., Luck, M., d’Inverno, M.: A normative framework for agent-based systems. In: 1st International Symposium on Normative Multiagent Systems (NorMAS2005). (2005) 25. Jones, A., Sergot, M.: The characterisation of law and computer systems: The normative systems perspective. In: J.J.Ch. Meyer and R.J. Wieringa (eds.): Deontic Logic in Computer Science: Normative System Specification. John Wiley and Sons, Chicester. (1993) 275–307 26. Minsky, N.H., Murata, T.: On Manageability and Robustness of Open Multi-Agent Systems. In Lucena, C., Garcia, A., Romanovsky, A., Castro, J., Alencar, P., eds.: Proceedings of Computer Security, Dependability and Assurance LNCS, No. 2940, Springer-Verlag (2004) 189–206

Views: Middleware Abstractions for Context-Aware Applications in MANETs Kurt Schelfthout, Tom Holvoet, and Yolande Berbers K.U. Leuven - DistriNet - AgentWise taskforce, Celestijnenlaan 200A, 3001 Leuven, Belgium {Kurt.Schelfthout, Tom.Holvoet, Yolande.Berbers}@cs.kuleuven.be

Abstract. Programming applications for highly dynamic environments such as mobile ad hoc networks (MANETs) is complex, since the working context of applications changes continuously. This paper presents “views” as abstractions for representing and maintaining context information, tailored to applications in MANETs. An application agent can define a view by declaratively describing the context information it is interested in. A supporting middleware platform, called ObjectPlaces, ensures that the information represented by a view continuously reflects the agent’s context information, despite the dynamic situation in a MANET. We elaborate on the distributed protocol that ObjectPlaces uses to maintain the information of views, and give an evaluation of the protocol’s correctness and overhead.

1 Introduction Given the increasing pervasiveness of networks due to the advent of wireless communication, the next generation of distributed systems presumes little network infrastructure, and is comprised of computing devices (nodes) that can be carried around, or are placed on moving vehicles. Mobile computing nodes connected in such an ad hoc way form a mobile ad hoc network (MANET) [1]. An application developed for MANETs necessarily consists of distributed agents that need to communicate among each other to achieve a common goal. Given the dynamics of a MANET, this communication between application agents is complex: the nodes on which these agents live are mobile, and can disappear from a conversation at any time. Dealing with this complexity at the application level is hard, so an application developer benefits greatly from a coordination middleware that offers high level mechanisms to manage communication among agents. ObjectPlaces is a coordination middleware that supports a first order abstraction of an agent’s context. For our purposes, an agent’s context is the aggregate of all available information on currently reachable nodes in the MANET [2]. An agent’s context thus changes because (1) information on a reachable node is changed, or (2) the set of reachable nodes changes. In ObjectPlaces, an agent can gather context by defining a view. A view is built by the middleware based on a declarative specification that describes “how far” over the network the view reaches, and in what information the viewing agent is interested. A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 17–34, 2006. c Springer-Verlag Berlin Heidelberg 2006

18

K. Schelfthout, T. Holvoet, and Y. Berbers

The most important property of a view is that it is an actively maintained structure, that changes as the agent’s context changes. The agent can listen for new context events, e.g. the arrival of a new node carrying interesting information. A motivating example for such an active notion of context occurred in a real world application, wherein we are currently applying the ObjectPlaces middleware. In this application, automatic guided vehicles (AGVs) in a warehouse coordinate to transport goods [3]. AGVs communicate to avoid collisions (among other things); an AGV thus needs to be notified actively when another vehicle enters in a possible collision range. Other examples are rescue workers that want to be notified of incoming and leaving ambulances, battlefield scenarios where soldiers want to be notified of incoming transports, etc. If the middleware does not support an active context representation, the application programmer is forced to program such a representation using polling. In the following section, we describe the ObjectPlaces middleware in more detail. Then we discuss its relation to existing coordination middleware. In Sect. 4 we describe a protocol to maintain a view in a MANET. Then, the ObjectPlaces middleware and specifically the notion of a view is evaluated analytically and empirically in Sect. 5. Finally, we conclude.

2 Views on Objectplaces In ObjectPlaces, each agent can maintain “viewable data” in a local collection of objects called an objectplace1. The objects in an objectplace represent information that is of interest to other agents, and so contribute to the overall context information available. Other agents can gather copies of objects from objectplaces on nodes in their neighborhood using a view. In other words, context information is made available by putting it in a local objectplace, and can be gathered by building a view. Agents can coordinate by influencing each other’s context, much like what happens in everyday traffic: when a car driver is going to take a right turn, he or she turns on the turning indicator. Other drivers can see this “context change”, and react appropriately. First we describe how an agent can manipulate its local objectplace, then views are described in more detail. The section is concluded with a discussion of ObjectPlaces in relation to existing work. 2.1 Manipulating an Objectplace An objectplace by itself is basically a tuplespace variant: an objectplace is a set of objects that can be manipulated by operations such as put, read and take. Contrary to existing tuplespace approaches however, an objectplace has a fundamentally asynchronous interface: operations return control to the client immediately (an agent that uses the middleware is called a client of the middleware), and results are returned as they are available via a callback. This is important in order to allow views to be built efficiently and conveniently, see Sect. 3. 1

“ObjectPlaces” - the middleware - is written in plural and with two capitals, “objectplace” the software entity - is written without capitals.

Views: Middleware Abstractions for Context-Aware Applications

19

For clarity, we have made two simplifications. First, although an objectplace can be manipulated remotely, for this paper the reader can assume that an objectplace is only locally accessible. Views, discussed in the next section, provide a way for clients to observe the contents of remote objectplaces. Second, although a client can create objectplaces at will, we assume that the middleware offers exactly one objectplace on each node. Similar to tuplespaces, in order to read or take objects from an objectplace, clients indicate what objects they want to read by means of a template. A template is a function from the set of objects to a boolean value. Every object for which the template function returns true matches with the template. The operations on an objectplace are the following: put(Set, Callback) puts the given set of objects in the objectplace. Returns true to the callback if all objects were successfully added. take(ObjectTmplt, Callback) removes the objects matching with the template from the objectplace and returns them to the callback. watch(ObjectTmplt, EventTmplt, Lease, Callback) observes the content of the objectplace. Returns copies of objects matching the object template to the callback (the objectplace is not changed). The event template is used to indicate in what events on the matching object the client is interested in. Event template and lease are described in detail shortly. A watch operation’s event template can match with three possible events: is Present, isPut or isTaken. If the event template matches with isPresent, the objectplace returns copies of all matching objects it currently contains to the callback, and returns the empty set if there are no matches (this is important for so-called testfor-absence operations, where the client needs to know there are no matching objects). If isPresent is the only event with which the event template matches, the watch operation is finished. However, when the event template also matches with isPut or isTaken, the objectplace must return copies of matching objects that are either put in or taken from the objectplace. In order to do so, the operation is registered by the objectplace, and when an appropriate event occurs on an object matched by the object template, the client is notified. An event template that matches with isPresent and isPut for example, first returns copies of objects currently contained in the objectplace. When new matching objects are put in the objectplace, copies of these are returned in a subsequent call to the callback. Objects returned to the callback are also annotated with the event that occurred on the object, so the client can distinguish between events. To unregister watch operations that are waiting for an event, a watch can be provided with a Lease object. A client calls the discard operation on the Lease to unregister the corresponding watch operation. The same lease can be given as an argument to more than one watch; in that case, upon discard all these operations are unregistered atomically. 2.2 Views A view is a local collection of objects, reflecting the contents of multiple objectplaces on reachable nodes in the network based on a declarative specification. This collection

20


is continuously updated by the middleware, both with respect to changing contents of the objectplaces in the view, as with respect to changes in the network topology. A view thus represents the context of the viewing agent. To build a view, a client specifies: A distance metric and a bound determines “how far” over the network the client’s view will reach. An example is a hop count-metric with a bound of three: the view will span objectplaces reachable in a maximum of three hops from the node where the view is issued. An object template constrains what objects will be included in the view. Given these parameters, the ObjectPlaces middleware searches the network for nodes satisfying the constraints (using the protocol described in Sect. 4). On these nodes’ objectplaces, a watch operation with the given object template is executed. The watch’s event template matches with all possible events. The results of all these watch operations, which are events indicating the presence, arrival or removal of objects in an objectplace, are sent to the node issuing the view. This allows the viewing node to keep the view up to date with respect to changes in the content of the participating objectplaces. Changes in the network are handled by managing the watch registrations on the nodes in the view. When it is detected that a node moves out of the view, the view’s watch on the objectplace of that node is unregistered, and the viewing node is notified; when a node moves into the view, a watch on its objectplace is registered and consequently the viewing node is notified as well, see Fig. 1. How this detection is done is discussed in Sect. 4. A view is actively maintained in this way until it is released by the client. Any client on any node can build a view, and clients can specify as many views as they want. Each client can have its own set of views to observe the context that it is interested in.

(a)

(b)

(c)

Fig. 1. Circles denote nodes, ovals denote objectplaces, and the rectangle denotes a view. The other shapes represent data objects. (a) A viewing node declares a new view. The circle denotes the bound on the distance metric and so the nodes from which the middleware will gather data for this particular view. (b) The middleware has gathered the appropriate data, and the view is built. (c) A new node enters the zone, so the view is updated with the new data object that the node carries in its objectplace.


21

A client can not only specify constraints on the content of the view based on its interests, the content can also be represented in a client specific way (e.g. as a sorted collection). In its raw form, a view is built out of the events generated by the watch operations on the participating nodes, as well as events generated by the middleware when a node leaves or joins the view. Users of the middleware can program their own representation using these raw events. For example, we have provided an implementation of a view as a collection, supporting a collection interface common in object-oriented API’s (i.e. java.util.Collection in Java). This allows sorting and iterating over the collection for example. The collection is updated as watch events are generated, e.g. when an isPut is received, the corresponding objects are added to the collection. Usually, a view is described as such a collection in this paper, since it is the most common usage pattern. Other representations of a view can be an accumulation to a single value, e.g. the average of an attribute of the objects in the view, or translating objects in the view to objects the agent understands, to deal with heterogeneous agents. Both the contents and the representation of a view can thus be customized. As an example, suppose a car arriving at an intersection wants to know the positions of other cars, since the car has to give way from the right. It builds a view on all cars within 50 meters (distance metric and bound), containing position and car id objects (object template). The car chooses a sorted list as representation, closest car first. A traffic monitor nearby also builds a view on nearby cars, and car id objects, but accumulates the car id’s in a counter for traffic information purposes. In both cases, the content of the view is partly the same (car id’s), but the representation is different (a sorted list, vs. a count of the unique id’s). In conclusion, a view is a powerful abstraction that can be put to good use for coordination, since it is an active representation of a agent’s context. A view takes the heterogeneous nature of a MANET into account, because both the contents and the representation of a view can be tailored to each client’s wishes.

3 Discussion and Related Work The ObjectPlaces middleware can be seen as a hybrid between two well known approaches for coordination: publish/subscribe systems and tuplespaces. In order to characterize the difference between publish/subscribe (P/S) and tuplespaces (TS) systems for MANETs, we first define some terminology. The coordination middleware imposes two forms of coupling on its clients: space coupling and time coupling. Clients are considered to be coupled in space if the knowledge they have about each other’s location during communication is high. For example, request/reply communication is highly coupled in space: both sender and receiver need to know where the other is (e.g. address and port number). Clients are considered coupled in time if they need to be up at the same time in order to receive or send a message. Request/reply communication is again highly coupled in time: if one of the communicating parties is disconnected, the message cannot be delivered. Coupling in time is related to failure semantics of message delivery: the longer the receiver can be disconnected from the sender while the message can still be received, or in other words, the higher the persistence of a message, the higher time uncoupling a certain coordination model provides.

22


For MANETs, the middleware must be able to uncouple clients as much as possible, both in space - due to the dynamic nature, it is impossible to predict with whom to interact - and in time - nodes may join and leave the network dynamically. Another way to contrast coordination middleware is whether a certain sender can push messages to a receiver (i.e. notify him) and if a receiver can pull messages from the sender (i.e. polling). Generally, both forms should be possible: if there is only information-push, unnecessary messages may be sent to receivers who are not interested; if there is only information-pull, there could be wasted bandwidth due to unnecessary polling by the receiver. Now, publish/subscribe systems and tuplespace systems are described, and evaluated for MANET applications with respect to the characteristics mentioned above. Also, existing coordination models for MANETs are discussed and compared to the ObjectPlaces middleware. In a publish/subscribe (P/S) system (e.g. [4,5]), publishers send notifications of state changes to a list of subscribers. Subscribers are not known in advance but let the P/S middleware know of their interest in certain events through the use of subscriptions. The P/S middleware handles the delivery of notifications to the right subscribers. P/S systems are uncoupled in space: a publisher publishes events, not knowing with whom it communicates; a subscriber is handed some event in which it is interested, equally unaware of the originator of the message. Senders can push information to receivers, so that receivers only get notified when necessary. P/S systems are coupled in time: both publisher and subscriber need to be active at the same time in order to transmit an event. This is especially a problem in ad hoc networks since new nodes arrive in the network regularly. Previous events were not delivered to these newcomers, which either leads to a slower startup time (waiting until the publisher changes state and sends an event), or a regular publication of events by the publisher especially for possible newcomers. These events are unnecessary since the publisher has not changed state. This problem is implicitly addressed in various work in P/S systems. For example, [6] describes that, due to the appearance and reappearance of hosts, there is a phase immediately after reconnection in which a mobile subscriber needs to subscribe to events and wait until some events get fired until it can reassess the current state of the network. Buffers and virtual clients are introduced to subscribe to past events and events in future locations respectively. Generally, the problem of time coupling is handled through buffers which are assumed to be reliable and fixed, e.g. [7] [8] [9]. Such an infrastructure is however not available in MANETs. STEAM [10] is a P/S middleware for MANETs where subscribers can not only filter events on their content and subject, but also on location. STEAM defines proximities that are areas around a certain publisher, where subscribers can listen to events from that publisher. Publishers need to send events periodically to account for possible newly arrived subscribers. ObjectPlaces can be seen as a P/S variant: a view is a subscription to events on objectplaces in the vicinity of a client. Clients ”publish events” by manipulating objects in their local objectplace, which triggers watch operations of views that are observing that objectplace. The resulting events are then delivered to viewing clients. However, the problem of disconnection and reconnection is solved elegantly in ObjectPlaces, since a


23

message is always stored in an objectplace. Newly arrived clients can thus be brought up to date immediately by querying neighboring objectplaces using a view. At the same time, the view subscribes to events on the objectplace, and so keeps the viewing client up to date in the future as well. The objectplaces thus act as a buffer in which clients can store observable state. Senders are relieved of having to send events periodically. Tuplespaces (TS) systems, with Linda [11] as a first incarnation, provide a shared collection of data, called tuples, and a set of operations (read, write, take) on the collection to manipulate the data. Throughout the years, Linda has spawned many variants, e.g. [12] [13]. Because Linda’s synchronous, polling model did not provide some essential primitives for distributed programming (where asynchronous interaction is more efficient and convenient), several variants were created that add asynchronous primitives, e.g. [14][12][13]. Modern implementations thus acknowledge the information-pull problem by providing extra primitives that allow an event-based style of interaction with the tuplespace. An objectplace expands on this idea by making all operations fundamentally event-driven and asynchronous. This greatly simplifies the maintenance of a view. It also allows the maintenance to be done efficiently, since network messages are only sent if there was a change. No costly polling is necessary. TS provide time uncoupling: sender and receiver do not need to be active at the same time since the tuplespace stores their messages until removed. Concerning space coupling, although sender and receiver do not need to know each other, they do have to know in which tuplespace their interaction will occur. No system that we know of tries to implement a globally shared tuplespace in a distributed system (this would be impractical since any query would have to search the complete network), so interaction is confined to a certain tuplespace on a certain host the client has to know about beforehand. Tuplespace interaction entails more space coupling between clients than P/S systems: TS only provide identity uncoupling. Space coupling is especially a problem in MANETs, since it is a priori unknown with which nodes a client will interact. Work in tuplespace variants for MANETs has acknowledged these problems. Lime [15] is a middleware for mobile agents and mobile hosts that attaches a personal tuplespace to each agent in the application, and shares these tuplespaces transparently when two agents are on the same or on connected hosts. In ObjectPlaces, views provide better control: an agent can select exactly in which information on which hosts it is interested. Moreover, several agents can have different views, each tailored to its own wishes. The LIME middleware was extended fairly recently in EgoSpaces [2]. In EgoSpaces, clients can (similarly as in ObjectPlaces) build a view over the locally available network, based on a distance metric. We see two improvements made in ObjectPlaces. First, EgoSpaces’ view is always represented as a tuplespace (supporting primitives like in, inp, . . . ). In ObjectPlaces, the representation of the view can be tailored to the client’s wishes (e.g. a sorted collection), thus providing better support for heterogeneous agents. Second, an EgoSpaces view is mainly used as a one-shot query: generally, the view is not maintained actively. While it is possible to register reactions on a view in EgoSpaces, these can react ”only” to incoming tuples [16]. It is unclear how an agent can be notified of a tuple leaving it’s view (except by polling), a necessary precondition

24


for building an up to date client-side representation such as in ObjectPlaces. Also, a quite elaborate construction has to be set up to maintain an active view in EgoSpaces [16]. ObjectPlaces provides lightweight active views that are actively maintained by default (a “one-shot view” is a special case of the views described in this paper). TOTA [17] (Tuples On The Air) is a middleware that provides applications with the notion of a self-maintaining distributed tuple. Each node in the network hosts a tuplespace. A distributed tuple is propagated to nearby nodes, and can be changed with each propagation according to an application-specific rule (e.g. counting the number of hops from the root). This tuple is then maintained by the middleware as the network changes. In a way, TOTA does exactly the reverse of ObjectPlaces: instead of gathering objects from neighboring nodes, TOTA spreads objects (or tuples) to neighboring nodes. An important difference with ObjectPlaces is that a view is specific for every client, while a distributed tuple is the same for all observers. In other words, while in TOTA the ”sender” of a message (the agent that adds a distributed tuple) determines both who it reaches and what the content is, in ObjectPlaces the ”receivers” of a message (the clients that build a view) can determine both content and representation. We believe this makes ObjectPlaces better suited to deal with heterogeneous application domains. In conclusion, ObjectPlaces takes the best of both P/S and TS systems, and so overcomes the difficulties of both approaches for MANETs. An objectplace, by offering asynchronous operations, acts as a generator of events, which get transported to interested clients through views. However, a view also gathers the current content of objectplaces, so clients building a view are immediately up to date. Clients of the ObjectPlaces middleware are thus uncoupled in time (a local objectplace acts as a buffer), uncoupled in space (building a view requires no information about agents participating in the view), offers an information-pull mechanism (a view gathers information from neighboring objecplaces), and an information-push mechanism (manipulating a local objectplace, which triggers an event on watching views). In addition, the representation of a view can be tailored to the application agent’s wishes, and a view is actively maintained by the middleware automatically. A final note about ontology. ObjectPlaces neither restricts nor supports the definition of the contents of the exchanged objects. Making sure that different agents on different nodes can understand the objects exchanged through views is the responsibility of some higher abstraction layer, or the application. For a generic approach for defining a common ontology in a tuplespace-like scenario we refer to [18].

4 View Protocol The construction of a view in a MANET requires a distributed protocol that is able to find and maintain a set of reachable nodes in the network given a bound on a distance metric. This means that the protocol should be able to: (1) notify the viewing node when a node enters or leaves the view (2) register and deregister watch operations on nodes entering and leaving the view respectively; (3) route the events generated by the watch operations to the node where the view was defined. Existing ad hoc routing protocols (for an overview, we refer to [1]) are not adequate because they can only provide a fixed “distance metric” (usually hop count). Since the distance metric used for building the


25

view is application specific and determined at runtime, we need a protocol that does fit our requirements. This protocol can be viewed as an alternative to the one proposed in [2]. We assume from the underlying network layer that: (1) a single-hop broadcast is available that broadcasts a message to all nodes within communication reach, represented by the function broadcast (message); (2) a reliable single-hop unicast that sends a message to a designated node within communication reach, represented by the function unicast(message, idreceiver ). We can reasonably expect these functions to be built based on data link standards such as IEEE802.11 [19]. Algorithm 1. The view protocol Process Root: on timeout tbr 1: removeOutdated(participants, fp .tbr ) 2: broadcast(dist msg(idview , 0, idroot)) on receive content message c 3: updateT ime(participants, timestamp(c), c.idsender ) 4: updateV iew(participants, c.events) 5: Process Participant: on timeout tbr 6: removeOutdated(neighbors, fn .tbr ) 7: idparent = f indP arent(neighbors) 8: dcurrent = calculateDistance(neighbors, idparent ) 9: if dcurrent ≤ bound then 10: broadcast(dist msg(idview , dcurrent , idparticipant )) 11: events = objplace.watch(object template, allEvents, cb) 12: unicast(cont msg(idview , events, idparticipant ), idparent ) 13: else 14: alive = f alse 15: stop timer on receive distance message d 16: updateT ime(neighbors, timestamp(d), d.idsender ) 17: updateDistance(neighbors, d.distance, d.idsender ) 18: alive = true 19: start timer on receive content message c 20: if alive then 21: unicast(c, idparent )

The data structures necessary for the protocol are depicted in Table 1, while the protocol is depicted as Algorithm 1. The protocol builds and maintains a shortest path spanning tree, starting on the node with the client issuing the view, called the root. This tree determines which nodes are included in the view - these are called the participants in the view. In the text and in Algorithm 1 the protocol is described as if there is only one view - this is only for expository purposes. In reality this protocol is executed for every view in which a node participates. That is why with each message a unique view

26

K. Schelfthout, T. Holvoet, and Y. Berbers Table 1. Contents of data structures and communication messages

Root idview participants = {(idparticipant , timestamp, {object})} distance metric, bound object template

Participant idview neighbors = {(idneighbor , timestamp, distance)} idparent , dcurrent distance metric, bound object template

Distance msg idview idsender distance

Content msg idview idsender {event}

id, idview is transmitted. The data structures in Table 1 are also for one single view, and are duplicated for every view in which a node participates. The length of a path is determined by the distance metric, which is a parameter of the protocol. This allows building a shortest path based on hop count, but also on any other distance metric such as physical distance, or bandwidth. The only constraint on the distance metric is that it should increase monotonically the further it gets propagated from the root, to ensure that the distance does not grow out of bounds as it gets propagated in a loop. Such a metric can always be chosen, by including a hop count with any other metric the client chooses (e.g. physical distance) [2]. The view building process starts when a client issues a view. The node on which this client is located is responsible for building and maintaining it, and is the root for that view. The root first builds a unique id for the view, consisting of its own id and a sequence number that is unique on each node. Two activities now occur in parallel: the building and maintaining of the shortest path spanning tree, and the building and maintaining of the contents of the view. The contents of the view is maintained at the root and consists of a list of participants and the objects each participant’s objectplace currently contains. The spanning tree. To build and maintain the spanning tree, the root and all participants regularly broadcast distance messages. This allows participants to determine what their distance is from the root (dcurrent ), given the view’s distance metric. The root starts the tree-building process by broadcasting a distance message with the id of the new view, its own id and a distance of zero (line 2). Nodes that receive a distance message check whether they are participants in the view. To this end, each participant maintains a list of its neighbors - nodes from which it has recently received a distance message. Upon receipt of a distance message, the participant records the time the distance message was received from that neighbor (function updateT ime, l. 16), and the distance that neighbor broadcasted (function updateDistance, l.17). The participant sets the alive variable to indicate it should check whether it is in a view, and starts a timer (if the participant already was in the view, these have no effect). After every broadcast period, given by tbr , a participant recalculates its distance from the root based on its list of neighbors. First, neighbors for which the timestamp of the distance message that was last received is older than a given timeout, are removed (using removeOutdated, l.6). This timeout is given as a neighbor freshness factor fn that is multiplied with tbr to determine the actual timeout. The participant then determines the neighbor that is closest to the root using f indP arent (l.7). Based on its


27

parent’s distance, it calculates its own distance from the root dcurrent using the distance metric (l.8). If it is within the bound, it broadcasts a distance message itself (l.10), and repeats the process every tbr time to account for changes in the tree. Otherwise, it goes to sleep, waiting for new distance messages to come in that might change the situation (l.14-15). The end result of this protocol is that each node regularly checks whether or not is in the view, and knows a parent in the tree which is the closest to the root of all its neighbors. The contents of the view. Each node that is in the view, determines the objects it contributes to the view by executing a watch operation on its local objectplace. The resulting events of this watch are transported to the root using content messages. The events variable is the set of buffered events at the participant that have not been sent to the root yet (we are stretching notation in line 11, since these events are actually sent to callback cb). A node that receives such a content message from one of its children forwards it to its parent, so that it reaches the root (l.21). The root maintains a list of participants of the view. For each content message it receives, it updates the objects that participant contributes to the view (using updateV iew, l.4). It also records the reception timestamp of each content message (l.3), and removes those participants it hasn’t heard from for fp .tbr time, where fp is the freshness of the participants (l.1). This means that participants must periodically send a content message to the root, even when there are no events to be returned (events = {} ) to ensure that the root does not consider them out of the view (l.12). This protocol tolerates mobility of any node and disappearance of participants. New nodes are discovered by the periodic broadcasting of the distance messages. Nodes that should be removed from view are detected because they discover for themselves that they don’t have any more neighbors, or their distance has gone out of bounds. Changes in the spanning tree are similarly detected through exchange of distance messages. Using the spanning tree to deliver events. When sending content messages, the spanning tree is actually used as a multi-hop routing tree to the root. Although the shortest path from participant to root may not always be known, at least some path exists (possibly temporarily containing cycles) and events are delivered as long as every node on the path forwards the content message to its parent. However, in the case where a node that received an event goes down before forwarding the event, the event is lost. To compensate for this loss, one can choose to use a reliable link protocol from node to root, such as the alternating 1-bit protocol. Each event received by the root would then have to be acknowledged before the node can send another event. Although this makes the protocol reliable, it also induces additional overhead. One possible solution is to use unreliable best-effort event delivery, which may be tolerable for some applications where the view may be slightly incorrect or out of date. Regularly, the view may be “flushed” and current state from all nodes is sent again. Propagation of other parameters. The parameters of the view, such as the distance metric, also need to be sent from the root to the participants. This was not discussed, but is done in a straightforward way: whenever a node receives a distance message with an idview it does not know, it requests the relevant view parameters from the sender

28


of the distance message. When the node determines it is not in the view, it may delete this information - or decide to keep it for a while longer because it might become a participant in the view later. We do not elaborate further.

5 Evaluation The following parameters influence the correctness and the performance of the view: (1) the broadcast period tbr , (2) the freshness for neighbors fn , and (3) the freshness for participants fp . Instead of letting the application designer choose these experimentally, we mathematically derive bounds on these parameters, supporting the designer in making the right trade-offs. The view protocol is influenced by uncontrollable factors concerning the dynamics of MANETs. In order to keep the presentation clear, we focus on the dynamics of the network only - in other words we assume for the rest of this section that the contents of the objectplaces stays the same. We focus on this problem because this is where any problems and bad assumptions will be revealed. Specifically, we take into account the number of nodes on a given area and the speed of these nodes. The speed influences how busy the protocol will be updating changes, and the concentration determines connectivity, or the number of nodes in the view. We study how accurately the protocol can represent the perfect view, which is obtained by “stopping time” and comparing the view the protocol built at that time with how the view should look, given the current position and connectivity of the nodes. There are two kinds of errors: false exclusions, objects that are not in the view but should be; and false inclusions, objects that should not be in the view but are. Then, we look at overhead induced by distance messages, and describe some results from simulations. 5.1 False Exclusions A false exclusion occurs when a node enters the view, while the view didn’t notice the new arrival yet. The critical parameter to minimize this kind of false exclusion is the broadcast period. When this period is short enough, a new node entering the view receives a distance message from a neighbor early, and the view updates fast. Suppose nodes have communication range r, and relative speed vr , and we want to detect a node when it has traveled at most distance l into communication range of any participant. The worst case scenario occurs when an undetected node moves straight at another in the view. In this case, the maximum broadcast period to ensure that a node is detected is: tbr ≤

r−l vr

with no transmission delay and no message loss. Supposing a message can get lost with probability ploss , then the minimum broadcast period to ensure that a node is detected at a distance l with minimum probability pdetect is: r−l tbr ≤ n.vr


29

with n the number of resends until a probability of receiving a message pdetect is reached. From the inequality pdetect ≥ 1 − pnloss it follows that n≥

log(1 − pdetect ) log ploss

To incorporate message delays, these bounds should be tighter: one should subtract the message delay from a node to its neighbor and subtract the delay to send the contents from the new participant to the root. Another kinds of false exclusion occurs when the root removes a participant while it should not, because a content message did not reach the root in time. We write the duration it takes to send a message i as td,i (from the start of sending to the end of receiving), the time of reception of message i as trec,i and the freshness of a participant as fp . For each two consecutive content messages 1 and 2 it should be true at the root that trec,2 ≤ trec,1 + fp .tbr , otherwise a participant is removed in error. After some calculation, this becomes: td,2 − td,1 ≤ (fp − 1).tbr . This inequality gives a lower bound for both the freshness and the broadcast period. The inequality shows that the bound is dependent on the difference between two delays only. This means that if the delay increases fairly slowly, the protocol adapts to this increase. Only when the delay suddenly increases with a value of (fp − 1).tbr does a false exclusion result. In other words, the broadcast period and the freshness determine the robustness of the protocol to message delays and congestion. The upper and lower bound described above show the tradeoff between accuracy and performance. The smaller the broadcast period, the more accurate and responsive the view becomes. However, sending more messages affects the performance, and causes congestion. Choosing a small broadcast period and freshness also causes errors in the view by decreasing the protocol’s tolerance for delays. The bounds given accurately characterize the trade-off to make and so support the designer in his or her decisions. 5.2 False Inclusion False inclusion occurs when a node moves out of range or out of distance of the view, while the view still contains the node’s contents. Two parameters influence this: the broadcast period tbr and the freshness of the participants fp . Two scenarios exist. In the first scenario, a node that is in the view moves out of communication range. The time it takes to detect this is maximum fp .tbr +td , where td is the total transmission delay to successfully send a content message from the node to the root. In the second scenario, the node is within communication range but for some reason the network changes and the node is out of the view (i.e. it’s distance becomes greater than the bound on the view distance). The node is still within communication range with other nodes in the view. The total time it takes to remove this node from the view is tbr + td + fp .tbr , so a broadcast period longer than the first scenario since it is only after this time that the node’s parent broadcasts a new distance, so the node realizes that its distance from the root has changed. Concluding, in order to minimize errors, the broadcast period and the freshness should be as low as possible. However, as was shown in the previous section, this makes the protocol more brittle. A similar trade-off must thus be made.

30


5.3 Overhead The overhead incurred by the protocol is caused by the periodical broadcasting of distance messages. Content messages are the actual objects that are transferred, and thus represent the useful content of the communication channel. How many bandwidth is taken up by content messages is entirely up to the application: an application that builds far-reaching views on large objects that are changed frequently obviously consumes more bandwidth than a close-by view on small objects. Consequently, we focus our attention on the overhead incurred by distance messages. An upper bound for the number of distance messages broadcast dm on a shared communication channel with v views, each of them spanning maximum n nodes is: dm = v.n.

1 tbr

Given that a distance message consists of three 4 byte long data structures (see Table 1: two integers and an IP address), the bandwidth taken up by distance messages can be calculated. As an example, suppose a 1 Mb/s (IEEE802.11 offers bandwidth between 1 and 11 Mb/s) wireless channel should accommodate 50 views, each spanning 10 nodes, where each node broadcasts a distance message twice per second. This uses 96Kb/s on the channel, representing about 10% of the channel’s capacity. For a relatively low bandwidth channel with many quickly updating views, we feel this overhead is acceptable. Furthermore, as is shown in the next section, actual overhead is lower (the above formula provides an upper bound, since the number of nodes in a view varies). 5.4 Simulations The goal of the simulations is to evaluate whether a MANET is able to sustain a viewlike concept. Instead of focussing on achieving a detailed simulation that conforms to reality as much as possible, we instead opted for a more straightforward approach that exposes the reasons behind problems more easily, while still reflecting the most important realities in a MANET. In the simulations, N nodes move around randomly on a rectangular area of size l.w, with a constant speed v. Each node has a predefined transmission range r. A receiver node within that range can receive messages from the sending node. Sending and receiving messages takes time, resp. tsend and trec . Nodes move a distance every second. All other activities occur instantly. Of the nodes moving around, one root node tries to build a view with a distance metric that increases one unit with each hop, and a bound denoted by d (in other words, we want the content of all objectplaces within d hops). All nodes have an objectplace which contains exactly one object. This never changes - we focus again on the dynamism of the network, not of the objectplaces’ content. All results are obtained by doing 10 runs for tsim minutes each with identical parameters, and then averaging the results. The parameters are summarized in table 2. First, the influence of the speed and concentration of the nodes on the number of errors in the view is studied, fixing d = 3. In Fig. 2(a) we see the total number of seconds a view is wrong versus the number of nodes on the given area, for different


31

Table 2. Simulation parameters l.w tsim r N v d tsend , trec

size of area duration of the simulation transmission range of the nodes number of nodes node speed range of the view in hops duration of send and receive

(a)

100.100m2 30 minutes 20m variable variable variable 50ms

(b)

(c) Fig. 2. (a) False exclusions vs speed, (b) False inclusions vs speed, (c) False exclusion for different broadcast periods and freshness, with fp = 2.fn

speeds, due to false exclusions and false inclusions. The speed does not influence the error significantly, but the concentration does. This is as expected, because the broadcast period was set to 500ms, which gives the view plenty of time to update given the range of speeds we are looking at. However, we see that the number of views that are wrong due to false exclusions is very high with higher concentration of nodes. The reason for this is congestion: too many nodes in the view mean that content messages are not reaching the root in time, which causes the root to remove participants in error. This is due to the fact that fp = 1, which is the most unforgiving value possible (see Sect. 5.1).

32


To find a good trade-off, we fixed v = 0.5 m s , d = 3 and N = 25, a scenario that gave quite some errors in the previous tests. We also set fp = 2.fn , because as the content messages are multi-hop, they are more susceptible to delay. As can be seen in Fig. 2(c), the combination of freshness and broadcast period influences the correctness of the view greatly. Good values for this particular scenario seem to be tbr = 2000ms and fn = 1, or alternatively tbr = 1000ms and fn = 2.5. As was shown in the analysis, a shorter broadcast period and smaller freshness do not increase the accuracy of the view: on the contrary, they cause congestion which does more harm than good. The improvement obtained by choosing a higher broadcast period alone is remarkable, and stresses the importance of this parameter. So far, we have looked at the total number of seconds a view is wrong, and have been able to reduce this time from 100% to about 16% of the total duration. Although these numbers don’t look very promising, the criteria for marking a view as wrong are harsh: if only one object is missing, or should be missing but is included, the whole view is “wrong”. However, such a view may still be accurate enough to be used for practical purposes. In order to know how wrong the view actually is, we measured the total duration a node is falsely in- or excluded, and the average size of the view measured in the number of nodes included per second, for the same runs as the previous experiment. We found that the number of nodes in the view was on average 8 nodes (averaged over time). The number of falsely excluded nodes per second is 3.50. The protocol manages to build the perfect view 84% of the time, and gathers contents from 70% of the content it should gather the rest of the time. Similar results are obtained for false inclusions, where the problem was less severe to begin with. We also measured the message overhead in the simulations. Similarly as in Sect. 5.3, we measure the bandwidth used by distance messages. For these experiments, tbr was set to 500ms, and fp = fn = 1. The speed of the nodes does not have any influence on the overhead (which it shouldn’t, since nodes broadcast at a constant pace irrespective of their speed). The number of nodes, however, does: in Table 3, the overhead in bps (bits per second) is shown, and the percentage of the bandwidth this would use on a shared channel of 1Mbps. As can be seen, the overhead is 0,2% at the highest. This is again for only one view; for multiple views, the numbers can simply be multiplied by the number of views, since without optimizations each view sends out its own distance messages. Also note that the overhead % is pessimistic, since it assumes that all nodes send on the same shared channel, while in reality, due to sending range restrictions, two far-away nodes can be sending simultaneously without interference. For the example given in Sect. 5.3, 10 nodes with 50 views and tbr equal to 500 ms, the overhead on a 1Mbps second is thus 0.05%×50=2.5%, significantly lower than the worst case of 10%. The results are workable for applications where network infrastructure is not available (e.g. search and rescue scenarios) or where a best effort approach is tolerable Table 3. Overhead of distance messages Number of Nodes 5 10 15 20 25 30 Overhead bps 343 512 771 1169 1645 1985 Overhead % 0.03% 0.05% 0.08% 0.12% 0.16% 0.20%


33

(e.g. calling a cab via a PDA). The ObjectPlaces middleware was implemented in Java. An implementation in Java Micro Edition should pose no significant challenges. Also, the communication overhead induced is certainly acceptable. We believe that there are no objections to use ObjectPlaces on a wide range of resource constrained devices, to support a wide range of applications that need to be context-aware. However, the described protocol is but one way of supporting a view; in the automatic guided vehicle application discussed in the introduction, we are actually using a wireless network with access points in order to improve the reliability of communication. Collision avoidance is an application in which a best effort approach is not adequate. The concepts ObjectPlaces offers remain the same and retain their strengths for mobile applications; only the underlying implementation differs.

6 Conclusion This paper discussed a middleware system for MANETs that provides a powerful abstraction of context to the application. In ObjectPlaces, agents coordinate by building a view on information made available by remote agents in the network. The view is actively maintained, and is client-specific both in contents and in representation. We presented a distributed protocol that maintains such a view in a MANET, and showed acceptable performance results, mainly focussing on the accuracy of the view. While for the construction of a view we necessarily take a best-effort approach, it was shown that good insight in the working of the protocol helps performance. An interesting direction for future work is to provide to the application using the view an indication of how good the view represents reality at this point in time - in other words, estimate the accuracy of the view and show this to the application. This estimate can for example be based on a node’s location and a known probability distribution of the nodes in space, or can be learned through experience. This is useful where the accuracy of the view is important. If nodes know the view is probably wrong, they can move more slowly or change the broadcast frequency in order to increase the accuracy.

References 1. Royer, E., Toh, C.K.: A review of current routing protocols for ad-hoc mobile wireless networks. IEEE Personal Communications (1999) 2. Roman, G.C., Julien, C., Huang, Q.: Network abstractions for context-aware mobile computing. In: Proceedings of 24th International Conference on Software Engineering. (2002) 363–373 3. Weyns, D., Schelfthout, K., Holvoet, T., Lefever, T.: Decentralized control of E’GV transportation systems. In: Proceedings of AAMAS 2005 - Industry Track, Utrecht, The Netherlands (2005) 4. Carzaniga, A., Rosenblum, D.S., Wolf, A.L.: Design and evaluation of a wide-area event notification service. ACM Trans. on Computer Systems 19 (2001) 332–383 5. Segall, B., Arnold, D.: Elvin has left the building: A publish/subscribe notification service with quenching. In: AUUG 97. (1997) 6. Cilia, M., Fiege, L., Haul, C., Zeidler, A., Buchmann, A.P.: Looking into the past: enhancing mobile publish/subscribe middleware. In: Proceedings of the 2nd international workshop on Distributed event-based systems. (2003)

34


7. Fiege, L., Gärtner, F.C., Kasten, O., Zeidler, A.: Supporting mobility in content-based publish/subscribe middleware. In: Proceedings of the ACM/IFIP/USENIX International Middleware Conference. (2003) 8. Cugola, G., Jacobsen, H.A.: Using publish/subscribe middleware for mobile systems. ACM SIGMOBILE Mobile Computing and Communications Rev. 6 (2002) 25 – 33 9. Sun Microsystems, Inc.: Java message service spec. 1.1 (2002) 10. Meier, R., Cahill, V.: Exploiting proximity in event-based middleware for collaborative mobile applications. In: Proceedings of the 4th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS’03), Springer-Verlag Heidelberg, Germany (2003) 11. Carriero, N., Gelernter, D., Leichter, J.: Distributed data structures in linda. In: Proc. 13th ACM Symposium on Principles of Programming Languages. (1986) 12. Cabri, G., Leonardi, L., Zambonelli, F.: Mars: A programmable coordination architecture for mobile agents. IEEE Internet Computing 4 (2000) 26–35 13. Sun Microsystems, Inc.: The javaspaces v1.2.1 spec. (2002) 14. Rowstron, A.: Using asynchronous tuple space access primitives (bonita primitives) for process coordination. In Garlan, D., Mtayer, D.L., eds.: LNCS 1282: Coordination Languages and Models (Coordination’97), Springer-Verlag (1997) 426–429 15. Murphy, A., Picco, G.P., Roman, G.C.: Lime: a middleware for physical and logical mobility. In: Proc. of the 21th International Conference on Distributed Computing Systems (ICDCS-21). (2001) 16. Julien, C., Roman, G.: Active coordination in ad hoc networks. In: Proceedings of the 6th International Conference on Coordination Models and Languages. (2004) 17. Mamei, M., Zambonelli, F.: Self-maintained distributed tuples for field-based coordination in dynamic networks. In: The 19th Symposium on Applied Computing (SAC 04). (2004) 18. Blake, M.: Agent-based communication for distributed workflow management using jini technologies. International Journal on Artificial Intelligence Tools 12 (2003) 81–99 19. IEEE Computer Society LAN MAN Standards Committee: Wireless lan medium access control (MAC) and physical layer (PHY) specifications. IEEE Std 802.11-1997 (1997)

An Adaptive Distributed Layout for Multi-agent Applications Koenraad Mertens, Tom Holvoet, and Yolande Berbers AgentWise, Distrinet, Department of Computer Science, K.U. Leuven Celestijnenlaan 200A, B-3001 Leuven, Belgium [email protected], [email protected], [email protected]

Abstract. A multiagent application consists of an environment and a number of agents. The environment contains information that the agents use and manipulate to do their work. When a multiagent system is decentralized over a number of different hosts (i.e. more than one execution platform is used), the environment has to be decentralized as well. The distributed layout of the environment can influence the performance of agents and of the system. In this paper we discuss when a distributed system can dynamically change its distribution layout. Our focus is on a distributed environment in which mobile agents move around and are aware of the distributed nature of the system. Changes to the layout of the distribution are not only triggered by the agents (like other, application-specific actions), but they can also be triggered by external events and the environment itself. A layer of meta-agents monitors those triggers. It has the ability to pro-actively change the distribution layout over the different hosts when this improves the behavior and efficiency of the application. Using a specific application (solving distributed constraint satisfaction problems) as an example, we indicate the usefulness of changes to the distribution layout and how they can be incorporated easily into a multiagent application design. It turns out that for some problems, the improvement in efficiency can be more than 30%.

1 Introduction Multiagent systems consist of an environment and a number of agents that are situated in that environment [1]. Because in many multiagent systems, interaction between agents [2] (one of the means to reach a goal in multiagent systems) is done through or with a dependency on the environment [3,4], the environment is an important aspect of the design of the application. Nevertheless it is only recently that more attention is devoted to the environment [5,6,7]. In multiagent systems, the term ‘environment’ can be used for two different software concepts: – The execution environment: This refers to the platform used to execute the system, e.g. a Java VM or the Windows operating system. – Theapplicationenvironment:Thisreferstotheenvironmentinwhichtheagentsreside, e.g. a grid structure when the agents are players in a strategy game or a graph structure when the agents are fire trucks and police cars in the RoboCupRescue project. A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 35–52, 2006. c Springer-Verlag Berlin Heidelberg 2006

36

K. Mertens, T. Holvoet, and Y. Berbers

These software concepts should not be confused with the physical setting in which the application is executed, although they can have a similar topology. In a peer-to-peer application, the execution environment, the application environment, and the physical setting consists of a network of connected nodes. In this paper, we focus on the application environment. For the remainder of this paper, we refer to it as ‘environment’. To indicate the execution environment, we use the term ‘execution platform’. When a multiagent system is decentralized, the environment has to be decentralized as well: a multiagent system where the environment is located on one host and the agents are distributed over a number of hosts is not really decentralized, but rather a client-server approach. The distribution layout of the environment defines how the various parts of the environment are scattered over the available hosts. This becomes an important issue that influences the behavior and efficiency of the system. In decentralized systems, it should be possible to change the distribution layout of the environment in order to guide the behavior, or increase the efficiency of the system. One of the basic ideas in software engineering is to assign responsibilities to entities that have the required information to fulfill it (Information Expert pattern, [8]). In the case of a multiagent system, the agents and the environment collect information, so they should be responsible for detecting when and how the environment should be changed. In this paper we list which circumstances can trigger changes in the distribution layout of the environment. Because the reactions to those circumstances are highly application dependent, we apply our findings to a specific application: a decentralized multiagent system to solve distributed constraint problems. Using this application we show how dynamic changes can be incorporated in an existing application design, without disrupting the existing functionality. We describe a selection of the results that show the usefulness of dynamic adaptation of the decentralized environment. Although not all problems are equally suited to benefit from an adapting environment layout, our tests suggest that many practical applications do. The structure of this paper is as follows: first we define the concept of ”distribution layout of an environment” in Sect. 2. The circumstances that can trigger a dynamic change to the environment and the changes that can be requested are listed in Sect. 3. Section 4 gives a short overview of the CSAA framework: this is the case we discuss in Sect. 5 to illustrate the need for dynamic adaptability of the layout of the environment. The relation of our work to existing work is described in Sect. 6. The results of this case are discussed in Sect. 7. In Sect. 8 we finish with our conclusions.

2 Distribution Layout of the Environment The centralized version of running a multiagent system is shown in Fig. 1. There is one execution platform, running on a single processor. The environment and the agents interact with each other and are executed on top of the execution platform. When a multiagent system is decentralized, more than one execution platform is used (Fig. 2). In order to use these execution platforms, the environment has to be decentralized as well. When doing so, the environment is split in two parts: Logical environment: The part of the environment that interacts with the agents. In a decentralized setting, there can either be one big logical environment (a transparent

An Adaptive Distributed Layout for Multi-agent Applications

37

Fig. 1. Architecture of a centralized multi-agent system. The agents interact with the environment (solid arrows). Both agents and environment are executed (dotted arrows) on top of an execution platform (e.g. a Java VM) which runs on one single processor.

(a)

(b)

Fig. 2. Architecture of a decentralized multi-agent system. The agents interact with the logical environment. This can be (a) one logical environment for the whole application, or (b) a logical environment that is split up so the agents can be aware of the distributed nature of the application. The logical environment interacts with the different parts of the physical environment, which is always split up. The agents and environment are all executed on top of the execution platform that is located on the same processor as they are themselves.

layer, so the agents are not aware of the distributed nature of the system) or multiple small logical environments, one on each host (so the agents can be aware of the distributed nature, if their capabilities allow it). Physical environment: The part of the environment that interacts with the execution platform. This is always split in different parts on each host because it represents the way the information is stored in the decentralized system. The agents interact with the logical environment and are executed on top of the execution platform of the processor they are located on.

38


With respect to their knowledge of the decentralized system, there are two ways agents in such a system can behave: 1. The agents are unaware of the distribution. When agents move around in their logical environment, it is possible that they are moved from one host to another, but they are not aware of it (either because they do not have the capability or because the logical environment provides one big representation of the problem nature to them). The agents do not adjust their behavior when the application is ported from a centralized to a decentralized system. An example of this category is a distributed version of the traveling salesman problem, solved by a swarm of agents [9]. Each agent walks around in the graph structure, provided by the environment. Whether or not an agent goes from one host to another is not important for that agent. Each agent walks the path it wants to walk, it is the environment that makes sure an agent is moved to another host (and thus another execution platform) if necessary. When some subset of the nodes in the graph could be better grouped on the same host (because agents make a lot of moves inside that subset), it is up to the environment to group them. 2. The agents are aware of the distribution. When an agent moves from one host to another, it knows it has done so: the environment is presented as a number of separate logical environments to the agents. Each agent is also aware of the layout of the distribution and the consequences of distribution (e.g. cost of communication to other hosts, processor load,. . . ) and can take those consequences into account when deciding which action to take. A distributed computation intensive multiagent system, such as solving a complex differential equation, is an example of this category: each agent is located on a different host and each agent is responsible for calculating a piece of the equation (in this case the equation serves as the environment). Agents need information from other agents (neighboring parts of the equation), but as this information has to be fetched over a network link, accessing it is slower than accessing local information. As performance is important, each agent gets as much information as possible from its own host, minimizing the (slow) use of the network link.

3 Adaptation of the Environment Layout The goal of our system is to change the distribution layout of the logical environment. There are two categories of events that can trigger such a change: external and internal events. In this section, we first discuss those events in more detail. Next we introduce a layer of meta-agents that will perform the changes. Finally we give an overview of types of changes that can be necessary. 3.1 Events That Trigger a Change The events that trigger a change can be divided into two categories: external and internal events. External events are directly brought into the system by the user or a separate system. Internal events are produced by entities inside the system. There are two types of entities that can gather information that justifies a change in the distribution layout: the agents and the environment.


39

1. External events: brought into the system when the execution platform changes (e.g. a new host is added when solving an equation) or a change in the problem situation is introduced (e.g. an extra city is added when solving the traveling salesman problem). 2. Internal events: – Events produced by agents: happens when an agent detects that a change in the layout of the logical environment would increase its performance (e.g. if some agent in the equation solving application makes intensive use of the information present on another host it can request to be transferred to that host or that the data is transferred to his own host). The agents are only able to detect performance increases for themselves, they are unable to judge if this would also increase the efficiency of the application as a whole. This type of events is only possible when the agents are aware of the decentralized nature of the application. – Events produced by the environment: happens when the environment detects that there is some performance bottleneck in the overall distribution layout of the system (e.g. one host in the distributed computation has a much higher load than another host, which could be solved by rearranging the parts to be calculated). The agents and the different parts of the logical environment have only a partial view of the system. This implies that they are unable to judge if a change would have a positive global effect. Therefore, the events that are produced by the agents and the environment will not necessarily cause a change to happen. The events are stored as influences in the system. A separate entity monitors those influences and decides which action has to be taken. the layer of meta-agents we use to do this is discussed in Sect. 3.2. This is very similar to the application-specific actions that are done by agents: they only send influences to the environment, they do not actually perform the actions [10,11]. When two agents request a conflicting action at the same time, only one or even none of them can be carried out, that is up to the environment to decide (e.g. two different agents request to kick a ball at the same time, in two different directions: the resulting action will be a combination of both requests). In the same manner, several influences requesting a change in the distribution layout can contradict each other. In that case, it is up to the meta-agents to decide which change to perform. 3.2 A Layer of Meta-agents The environment itself is not a proactive entity in the system: it reacts to inputs and performs ongoing tasks such as pheromone evaporation, but it does not take itself the initiative to start new actions. Because of this non-proactive nature, the environment itself can not be responsible for interpreting the influences and changing the distribution layout. Additionally, in the applications we focus on, adjusting the distribution layout is a separate concern: it should not interfere with the correct behavior of the system, only with the performance. For that reason, we created an additional layer of meta-agents, whose sole purpose is to monitor the influences and adjust the distribution layout. For each part of the logical environment, one meta-agent is created. This is illustrated in Fig. 3.

40


Fig. 3. Architecture of a decentralized multi-agent system with a layer of meta-agents, responsible for adjusting the distribution layout. The logical environment consists of different parts (one for each host). In each part of the logical environment a number of agents (Ax) are located. The distribution layout is managed by a layer of meta-agents (MAx, one meta-agent per part of the logical environment).

A meta-agent has a limited view of the environment. By interacting with the other meta-agents and with the part of the logical environment it is associated with, each meta-agent is able to make decisions that have a global impact. However, the metaagents can only exchange meta-information: they can indicate what kind of information on a remote host is required by another host, but they should not exchange the information itself. The intent of the meta-agents is not to solve the application problem, but to adjust the environment so that the regular agents can solve the problem more efficiently. 3.3 Types of Requests for Changes There are three ways in which the distribution layout of the logical environment can be changed: 1. A new part is created. 2. An existing part is removed. 3. An existing part is moved from its host to another host. The first two types of changes are always triggered by external events: they must be carried out immediately because they influence the correctness of the application. The thirth type of change is mostly triggered by internal events. Internal events are generated by either the agents or the different parts of the logical environment. They create the influence that requests that a part the the logical environment has to be moved from one host to another host. The most explicit manner to request such a move, it to state the three items involved in the move: 1. The part that has to be moved, 2. The host on which that part is currently located and 3. The host to which the part has to moved.


41

Since the agents and the different parts of the logical environment only have a local and thus limited view of the system, they do not have the ability to decide if a proposed change has a positive impact on the system as a whole. Therefore, the influences that are produced by multiple entities are gathered by the layer of meta-agents and they decide which changes to the distribution layout are made. When all move-influences are fully specified , it becomes very difficult for the meta-agents to combine the different influences. The meta-agents have more options for combining the influences if the moves are specified less strictly, i.e. when only one or two out of the three items are specified, or when some items themselves are specified less strictly. Some examples are: – Only the host from which a part has to moved is specified. The meta-agents can choose which part has to be moved, and where to move it to. This can be used when one host has a high workload. – Only the destination host is specified. This can be used when one host has a low workload. The meta-agents can choose to move one big part of a highly loaded host, or different small parts from multiple host. – Two parts of the logical environment are specified that have to be placed on the same host. The meta-agents can choose on which host these parts have to be placed. This can either be one of their present hosts, or even a third host. – A part of the logical environment and an agent or a group of agents are specified that have to be placed on the same host. Again, the meta-agents can freely choose the destination host. Which requests are possible depends on the application, but in general, less strictly specified influences result in more freedom and a better combination by the meta-agents. In Sect. 5 we give further examples of the different circumstances for and types of adaptation. The examples are extracted from a specific application: solving of constraint satisfaction problems using a distributed swarm algorithm. The next section describes in short how this application works.

4 CSAA Framework The constraint satisfaction ant algorithm (CSAA) provides a general framework for solving constraint satisfaction problems (CSPs) using a swarm algorithm. CSPs are converted to a graph. This graph is used as the environment for a multiagent swarm application. Using an approach that is based on ant colony optimization (ACO) [12] a solution is searched.1 4.1 Centralized Framework In Fig. 4 a graph is constructed for a small CSP problem with 3 variables (A ∈ {4, 5, 6}; B ∈ {2, 3}; C ∈ {2, 3}) and 2 constraints: (A = B + C; B > C). Each variable is converted to a main node (nodes A, B and C on Fig. 4(a)). From each main node, there are as many edges as there are other main nodes, each leading to a child node (from main node A to child nodes AB and AC in Fig. 4(b)). From each 1

An implementation in Java of the CSAA framework can be found at http:// www.cs.kuleuven.be/˜koenraad

42


AB

A

B

A

AB

B

A

B BA

AC

AC

CB

CA

BC

C

C

C

(a)

(b)

(c)

Fig. 4. Construction of a graph for a problem with 3 variables: A ∈ {4, 5, 6}; B ∈ {2, 3}; C ∈ {2, 3} and 2 constraints: A = B + C; B > C. (a) Each main node represents a variable. (b) Going to the next main node is a two-step process: first the selection edge is chosen, then the value for the current variable (A has 3 possible values: there are 3 value edges from AB to B). (c) The complete graph for the problem. A reference to A = B + C is stored in A, B and C, a reference to B > C in B and C.

child node, there are as many edges as there are values for the variable of the previous main node. These edges all lead to the same main node (in Fig. 4(b) there are 3 edges from AB to B because the domain of variable A contains 3 values). The edges going from a main node to a child node are called selection edges because they select which main node will be visited next; the edges going from a child node to a main node are called value edges because they determine a value for a variable. The layout of the graph imposes a few restrictions on the kind of CSPs that can be solved: each possible value has to be represented by an edge, so values must be discrete and finite in number. The total number of nodes is n + n(n − 1), with n the number of variables. This makes that very big problems can not be solved by this centralized framework: the number of nodes would be too large to fit into the memory of a computer. A distributed version of the framework (see Sect. 4.2) or a modified version of the centralized framework can bypass this restriction. The multiagent system that is used to solve the CSP is organized as a swarm of agents. Each agent of the swarm moves around in the graph, constructing a solution while doing so. In each main node, a suited selection edge has to be chosen (each main node can only be visited once by the same agent); in each child node, a suited value edge has to be chosen (values have to comply with previous chosen value: the constraints of the CSP determine which values are suited and which are not). On each edge a feedback value (in the form of synthetic pheromones) is stored that influences the selection process. A more detailed description of the behavior of the agents and the pheromones can be found in [13]. 4.2 Distributed Framework In [14] a distributed version of the CSAA framework was presented. The agents in the system are aware of the distribution and adjust their behavior to this knowledge. The set of variables in the problem is split up in as many parts as there are hosts and each


43

Host I AB

DE

A

D

B

E

BA

AC

ED

DF

CB

CA

BC

FE EF

FD

GH

G

H HG

C GI

F

Host II

IH

IG

HI

I

Host III

Fig. 5. Distributed graph for the CSAA. A copy of a constraint involving A and D is stored both on host I and host II. A constraint involving only variables A, B and C is stored only on host I.

part is assigned to one host. Each host builds its own logical environment, holding only variables associated with the variables the host is responsible for. The constraints are also distributed over the hosts. Each hosts gets a copy of all constraints the variables it is responsible for are involved in. If a constraint concerns several variables that are located on different hosts, multiple copies of that constraint are kept: one on each host that has such a variable. The agents that try to solve the CSP jump from host to host. They must have visited all main nodes on a host before going to a next host. The hosts can be arranged in a loop, making the order in which each agent visits all hosts fixed. A second option is not to determine an order between the hosts, so each agent can choose for itself the order in which it will visit all hosts. A layout for a simple distributed problem with nine variables and six hosts is displayed in Fig. 5. The goal of the CSAA framework is flexibility. This requires the environment to be flexible: it must be possible to add new variables or constraints and to delete others. Because the environment has knowledge about the work load on the hosts, one of the responsibilities of the environment is an equal distribution of the work load. When the environment detects that the workload is ill balanced, it suggests changes to the layout. Agents can also suggest a reorganization to the environment layout, when some variables can be grouped together to be able to process them more efficiently. Which variables this are can only be determined by the agents. The three types of circumstances that call for a change in the environments distribution layout that were introduced in Sect. 3 are present in this application, as well as several of the changes that can be requested. They are discussed more thouroughly in the next section.

5 The CSAA Framework as a Use-Case for Environmental Adaptation Different types of changes to the distribution layout can be requested and there are different types of circumstances that call for a change. In Sect. 5.1 we give examples of

44


those circumstances and requests in the context of the CSAA framework, in Sect. 5.2 we explain how the environment is able to handle those requests when it is distributed itself. The main purpose is to illustrate the opportunities that changes to the environment layout can offer and to show how multiagent techniques can be used to incorporate this functionality into an existing application design. 5.1 Different Types of Requests for Change Changes Because of External Events. There are several external events that can trigger a change in the environments distribution layout. The most obvious are adding or removing variables, values, constraints or hosts. Others include a change in the host capabilities or the failure of a connection between two hosts. Whenever such an external event happens the environment must adapt. When a variable, value of constraint is deleted, the change to the distribution layout is rather trivial: the according part of the graph structure simply has to be removed. When an extra variable value or constraint is added, some extra edges and connections have to be added. Adding or removing such components could cause the work load to be ill distributed, but this will be handled automatically (see Sect. 5.1). When an extra variable is added, the environment has to decide which host to assign it to. The simplest option is to assign it to the host that has the lowest work load and let the agents decide if some other host is more suited with respect to the constraints that exist between the new variable and existing variables. A similar approach can be taken when a new host is added: the environment removes some variables from each host and assigns these variables to the new host. The agents are then responsible for rearranging the variables for efficiency. All changes that are requested because of external events, must be carried out immediately: a correct solution for the problem can not be found without those requested changes (with the exception of a new host that is added). For changes that are requested by agents or by the environment, explained in the following paragraphs, this is not the case. They can be postponed because they do not influence the correctness of the solution, but only the efficiency of the algorithm. Changes Requested by the Agents. Agents are responsible for assigning values to variables and checking the constraints of the problem. When an agent has already assigned values to a number of variables, it can sometimes happen that a next variable can not be assigned a value. E.g. variables A, B and C have already been assigned a value. There exists a constraint between variables A, B and D. Because of the chosen values for A and B, every possible value for D violates the constraint. When this happens, all value assignments between the assignment of the first variable in that constraint and the present variable were a waste of effort. In the example: the value that was chosen for C did not help in determining that no value for D could be found. To prevent this from happening in the future, all variables that are involved in the constraint should be assigned a value around the same time. In our examples this means that variables A, B and D should be placed on the same host. In this type of change request it does not matter which of the variables are moved to another host, or which host they are moved to: as long as the variables end up at the same host, the efficiency of the system will be increased. It is even possible that other


45

variables get moved as well (because of load balancing requirements). The request does not have to be carried out immediately: it does not influence the correct behavior of the application, it only affects the efficiency of the application. When two agents are running, and they both request a conflicting change at the same time, at least one of the requests can not be fulfilled. Furthermore, when solving highly constrained problems, executing all requests could mean that all variables are transferred to the same host (which, in a decentralized setting is obviously not the desired behavior). How this and other conflicts that can arise from multiple change requests are handled is explained in Sect. 5.2. Changes Requested by the Environment. The environment is responsible for grouping associated variables on the same host (the distribution layout) and providing a communication infrastructure for the agents. The distribution layout is closely related to the work load on each host. A change in work load can be caused by a change in distribution layout or because one of the hosts suddenly has to do more calculations (e.g. because the agents on that host gradually choose other values that require more calculations). In the CSAA framework the distribution of the workload is measured by comparing the period of time an agent needs to process all variables on the different hosts. The duration of this period needs to be the same to avoid bottlenecks. Differences in work load cause the environment to request a change in the distribution layout. As with the requests by agents, changing the distribution layout does not influence the correct behavior of the application and so the changes do not have to be carried out immediately. 5.2 Handling Requests for Change in a Distributed Setting Because the agents only interact with their logical environment, they can only send requests for changes to the distribution layout to that logical environment. The logical environment itself also produces requests for change. Therefore, we store all information about these requests in the logical environment. The layer of meta-agents that was introduced in Sect. 3.2 is responsible for adapting the distribution layout of the system. It takes as input external events and the information stored in the logical environment. Based on that information, it decides when and how the distribution layout must be changed. The next paragraphs give two examples of how the meta-agents interpret the requests for changes to the distribution layout. Transferring Data on Request of Agents. When an agent detects that a variable can not be assigned a value, it sends feedback to the environment. The agent indicates in its feedback which host contained the most restrictive variables that prohibited a value assignment. The environment stores this feedback in the node that is associated with the variable. This information is encoded under the form of pheromones (artificial imitations of the biological chemicals that e.g. ants use, [15]). For each host in the system, there is a different type of pheromone. When a meta-agent detects that one type of pheromone for a node exceeds a certain threshold, the variable that is associated with that node is transferred to the corresponding host. Using a threshold mechanism prevents all variables to be transferred at the same time. In combination with workload balancing (described in the next paragraph)

46


it prevents that all variables are transferred to one and the same host: because variables are only transferred gradually, the load balancing process has the necessary time to redistribute the variables that are present on crowded hosts. Balancing Workload. When agents are transferred from one part of the logical environment to another, they are first stored in a buffer at the receiving part. When the meta-agent that is associated with this part of the logical environment detects that the number of agents in the buffer becomes too high, one of the variables in the logical environment is transferred to another part of the logical environment. Which variable gets transferred depends on the host it gets transferred to. There are two possibilities: 1. When the order of the hosts is fixed, a variable gets transferred to the part of the logical environment that is located on the previous host. The workload of that previous host will certainly be lower: the previous host was able to fill the buffer of its successor, which means more agents were processed at the same time. 2. When the order of the hosts is not fixed, a variable gets transferred to the host with the lowest number of agents in its buffer. To avoid an election process between the hosts each time a variable has to be transferred, each part of the logical environment remembers the buffersize of each other part each time an agent is transferred to that part. The variable that is transferred is the variable whose associated node has the highest pheromone level for the host to be transferred to. One of the drawbacks that can arise when using both a dynamic transfer of the variables and workload balancing is that variables can be transferred back and forth between hosts. To prevent oscillations in the transfer of variables, the threshold in the meta-agents are adjusted by the workload balancing process. Each time this process transfers a variable away from a host, the threshold that is needed for other variables to be transferred to that host increases.

6 Related Work Research in the domain of resource allocation and load balancing has been active for a long time. In the last decade, research has shifted from centralized [16] and pseudodecentralized approaches (client-server approaches, like [17]) to completely decentralized approaches. In these decentralized approaches, multi-agent systems are a natural choice for coordinating the systems resources. Both intelligent agents [18], and in recent years swarms of reactive agents [19,20,21] have proven to be efficient. The approach that is described in this paper is no new approach, but merely an instantiation of existing techniques. According to the general model for load balancing schemes that is presented in [22] each load balancing scheme can be decomposed into four main criteria: 1. 2. 3. 4.

The triggering policy The selection policy The communication and domain policy The matching policy


47

As described in Sect. 5.2 the agents leave information on each host about the nodes that should be transferred by preference and which host they should be transferred to. This information is stored as pheromones in the logical environment. The meta-agent layer is responsible for the distribution layout and load balancing and uses the information in the pheromones to determine the triggering (pheromone level exceeds threshold, in combination with buffer size), selection (node with the highest pheromone level) and matching policy (preferred host to transfer to). As it is implemented now, no extra communication between meta-agents is needed to determine when and where to redistribute nodes. The advantage of this approach is that information is accumulated by the entities that are most suited to do so. The task of the agents is to search for a solution, which involves moving from host to host and taking into consideration dependencies between nodes. They are best suited to gather the information about these dependencies. The logical environment, which consists of collections of associated variables, is best suited to indicate when a host is overloaded or underloaded. The distribution layout of the system is a separate concern and a non-functional requirement: it does not influence the correctness of the system. Therefore, the adaptation of the distribution layout is done by a layer of meta-agents: the meta-agents can be changed to implement another load-balancing algorithm without changing the correctness of the system. Using a meta-level for non-functional requirements is a well-known technique [23,24] also.

7 Results The features of the adaptive environment, described in Sect. 5, were implemented and integrated into the existing CSAA framework. We tested this modified framework on a number of graph coloring problems, represented as partial constraint satisfaction problems. Based on the results, we distinguish between two classes of problems: completely connected graph coloring problems and partially connected graph coloring problems. In this section we give and discuss the results of one completely connected and two partially connected problems2. The difference between the different classes of problems allows us to define whether the use of the adaptive features is opportune for a given problem. Figures 6, 7 and 8 are averaged anytime curves. An averaged anytime curve illustrates how the average of the best solutions that are found improves as time (given by 2

All problems had hard as well as soft constraints. For each pair of variables and colors, 10 problems were created, each with a different number of hard constraints. The percentage of hard constraints ranged from 3% (easy problems) to 30% (more difficult problems) of all edges. The penalties for the soft constraints were chosen randomly between 1 and 50. Every problem was solved 10 times, so the figures display averages for 100 runs. We used a distribution layout of three heterogeneous hosts (ranging from an AMD 1600+ to a Pentium IV 2.6GHz). Initially the variables were randomly distributed on the hosts. The completely connected problem that is reported on in this paper had an edge (constraint) between each pair of variables. For the partially connected problems, the probability of an edge between two variables was 0.5. The completely connected problem and the first partially connected problem had 11 variables and 3 colors, the second partially connected problem had 15 variables and 5 colors.


350

48

Without self-adapting application environment

250 200

Solution

300

With self-adapting application environment

# Checks 1e+03

1e+04

1e+05

1e+06

80

Fig. 6. Progress results of the CSAA framework without an adapting environment (solid line) and with such an environment (dashed line) on a completely connected graph coloring problem with 11 nodes and 3 colors. Executed on three heterogeneous hosts.


40 20 0

Solution

60


# Checks 1e+03

1e+04

1e+05

Fig. 7. Progress results of the CSAA framework without an adapting environment (solid line) and with such an environment (dashed line) on a partially connected graph coloring problem with 11 nodes and 3 colors. Executed on three heterogeneous hosts.

the number of constraint checks) proceeds. Each curve starts as a thin line. This means not all 100 runs have found a solution yet: the shown value is the average best solution for the runs that have already found a solution. Once the curve becomes a thick line, all runs have found a solution. All three figures compare the results of the CSAA framework without an adaptive environment to the results of the CSAA framework with such an environment. 7.1 Completely Connected Problems In the first type of graph coloring problems, each node is connected by an edge to each other node. The results that were obtained for problems with 11 variables and 3 colors are depicted in Fig. 6. There is not a big difference in the results of the CSAA framework with and without an adaptive environment. The results with such an environment reach a first solution

60


49


20 0

Solution

40


# Checks 1e+04

1e+05

1e+06

Fig. 8. Progress results of the CSAA framework without an adapting environment (solid line) and with such an environment (dashed line) on a partially connected graph coloring problem with 15 nodes and 5 colors. Executed on three heterogeneous hosts.

a little bit faster for the easier problems (the thin dashed line starts sooner than the thin solid line), but for more difficult problems (the beginning of the thick lines), the difference is hardly noticeable. The quality of the solutions is very comparable, both during the solving process as at the end of the process. 7.2 Partially Connected Problems In the second type of graph coloring problems, the probability for two nodes to be connected by an edge (or constraint) was only 0.5, reducing the number of edges by 50%. The results that were obtained for problems with 11 variables and 3 colors are depicted in Fig. 7. The results for the problems with 15 nodes and 5 colors are depicted in Fig. 8. In contrast with the results of the fully connected problems, there is a noticeable difference when partially connected problems are solved using the CSAA framework with or without an adaptive environment. The intermediate results of the framework using the adaptive environment are better: as well for the easier problems as for the harder problems, a solution is found approximately 30% to 40% faster. The quality of those intermediate solutions is better also: for the problem with 11 variables of Figure 7, an average best solution that is within 30% of the final solution is found after approximately 3000 checks when using an adaptive environment. That is less than half the amount of checks than when such an environment is not used (approximately 7000 checks needed). The final solutions for both versions are approximately the same. Altough in Fig. 8, the last displayed solutions of both versions are not exactly the same yet, we expect them to reach the same value if the algorithms are allowed to run longer. 7.3 Observations A first thing we can conclude when we look at the results, is that the final solution that is found by the CSAA framework remains unchanged whether it uses an adaptive environment or not. Because the adaptations of the environment layout (moving variables from one host to another) are only concerned with the efficiency of the algorithm

50


(balancing workload and a more efficient use of the heuristics), this is an outcome that could be expected. A second conclusion is that not all problems are equally suited for the use of an adaptive environment. When solving graph coloring problems that consist of a completely connected graph, there is no effect in using the proposed adaptations. The workload on the hosts will probably benefit from an adaptive environment, but the adaptations will have no effect on the effectiveness of the heuristics. When a partially connected graph coloring problem is solved, the heuristics can be made more efficient by adapting the environment: in most partially connected graphs, there are some highly connected subgraphs. Putting those subgraphs on the same host will result in better heuristics and a faster convergence to the final solution.

8 Conclusions In this paper we presented a number of circumstances that cause the dynamic adaptation of the environment layout. A layer of meta-agents reacts upon triggers from the agents, the environment or external triggers to change the distribution layout of the system. To illustrate the different types of circumstances and requests, we used a distributed swarm algorithm for constraint satisfaction solving, the CSAA framework. In this framework, requests are done using standard swarm algorithm techniques: artificial pheromones. Our illustration shows the opportunities that dynamic adaptation of the environment layout offers and how existing mechanisms can be used to implement this into the context of a decentralized multiagent system. Not all problems are equally suited for the adaptive enhancements. When solving highly connected problems, there is no efficiency gain. The reason for this is the lack of structure in the problem description: the adaptations to the environment layout try to group parts of the environment that are highly related, but when all elements of the environment are equally related, these attempts do not succeed and they do not result in any efficiency gain. However, a fully connected graph is an artificial problem: most practical problems do have some structure in them. It is not always easy for a human to determine which parts of the problem belong together, so a manual decomposition is not feasible. When using an dynamic environment, this task can be done by the system itself. The results of solving partially connected graphs – an improvement in efficiency of more than 30% – prove that the efficiency of the system can be enhanced by this approach. Finally, while we demonstrated the use of an dynamic environment for solving constraint problems, other application domains could also benefit from it. The efficiency of all applications where some distributed coordination or computation takes place, benefits from a reduced use of the networking infrastructure and could be enhanced by a dynamic environment.

Acknowledgements This work has been funded by the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWT-Vlaanderen).


51

References 1. Ferber, J.: Multi-Agent System: An Introduction to Distributed Artificial Intelligence. Harlow: Addison Wesley Longman (1999) 2. Parunak, H.V.D., Brueckner, S., Fleischer, M., Odell, J.: Co-x: Defining what agents do together. In: Proceedings of the AAMAS 2002 Workshop on Teamwork and Coalition Formation. (2002) 62–69 3. Chialvo, D.R., Millonas, M.M.: How Swarms Build Cognitive Maps. In Steels, L., ed.: The Biology and Technology of Intelligent Autonomous Agents. Volume 144. Nato ASI Series (1995) 439–450 4. Huhns, M.N., Stephens, L.M.: Multiagent systems and societies of agents. In Weiss, G., ed.: Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. The MIT Press, Cambridge, MA, USA (1999) 79–120 5. Omicini, A.: Soda: societies and infrastructures in the analysis and design of agent-based systems. In: First international workshop, AOSE 2000 on Agent-oriented software engineering, Secaucus, NJ, USA, Springer-Verlag New York, Inc. (2001) 185–193 6. Parunak, H.V.D., Brueckner, S., Sauter, J., Matthews, R.S.: Distinguishing environmental and agent dynamics: A case study in abstraction and alternate modeling technologies. Lecture Notes in Computer Science 1972 (2001) 19–33 7. Weyns, D., Parunak, H.V.D., Michel, F., Holvoet, T., Ferber, J.: Environments for multiagent systems, state-of-the-art and research challenges. Lecture Notes in Artificial Intelligence 3374 (2005) 8. Larman, C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall PTR, Upper Saddle River, NJ, USA (2001) 9. Stützle, T., Dorigo, M.: ACO Algorithms for the Traveling Salesman Problem. In Miettinen, K., Makela, M., Neittaanmaki, P., Periaux, J., eds.: Evolutionary Algorithms in Engineering and Computer Science. Wiley (1999) 163–183 10. Ferber, J., Müller, J.P.: Influences and Reaction: A Model of Situated Multiagent Systems. In: Proceedings of the Second International Conference on Multi-agent Systems, AAAI Press (1996) 72–79 11. Weyns, D., Holvoet, T.: Formal Model for Situated Multi-Agent Systems. Formal Approaches for Multi-agent Systems. Special Issue of Fundamenta Informaticae 63 (2004) 125– 158 12. Dorigo, M., Di Caro, G.: The Ant Colony Optimization Meta-Heuristic. In Corne, D., Dorigo, M., Glover, F., eds.: New Ideas in Optimization. McGraw-Hill, London (1999) 11–32 13. Mertens, K., Holvoet, T.: CSAA; a Constraint Satisfaction Ant Algorithm Framework. In: Proceedings of the Sixth International Conference on Adaptive Computing in Design and Manufacture (ACDM’04), Springer-Verlag (2004) 285–294 14. Mertens, K., Holvoet, T.: CSAA; a Distributed Ant Algorithm Framework for Constraint Satisfaction. In: Proceedings of the 17th International FLAIRS Conference, AAAI Press (2004) 764–769 15. Grasse, P.: La reconstruction du nid et les coordinations inter-individuelles chez bellicostermes natalensis et cubitermes sp. la theorie de la stigmergie: Essai d’interpretation des termites constructeurs. Insect Societies 6 (1959) 41–83 16. Ross, K.W., Yao, D.D.: Optimal load balancing and scheduling in a distributed computer system. J. ACM 38 (1991) 676–689 17. SETI@Home: http://setiathome.ssl.berkeley.edu/ (1996-1999) 18. Cao, J., Spooner, D.P., Jarvis, S.A., Nudd, G.R.: Grid load balancing using intelligent agents. Future Generation Computer Systems, Special Issue on Intelligent Grid Environment: Principles and Applications (2005) 135–149

52


19. Schoonderwoerd, R., Holland, O., Bruten, J.: Ant-like agents for load balancing in telecommunications networks. In: AGENTS ’97: Proceedings of the first international conference on Autonomous agents, New York, NY, USA, ACM Press (1997) 209–216 ¨ 20. Montresor, A., Meling, H., Babao˘glu, O.: Messor: Load-Balancing through a Swarm of Autonomous Agents. In: Proceedings of the International Workshop on Agents and Peer-toPeer Computing in conjunction with AAMAS 2002, Bologna, Italy (2002) 21. Cao, J.: Self-organizing agents for grid load balancing. In: GRID ’04: Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing (GRID’04), Washington, DC, USA, IEEE Computer Society (2004) 388–395 22. Fonlupt, C., Marquet, P., Dekeyser, J.L.: Analysis of synchronous dynamic load balancing algorithms. In D’Hollander, E.H., Joubert, G.R., Peters, F.J., Trystram, D., eds.: Parallel Computing: State-of-the-Art and Perspectives, Proceedings of the Conference ParCo’95, 19-22 September 1995, Ghent, Belgium. Volume 11., Amsterdam, Elsevier, North-Holland (1996) 455–462 23. Robben, B.: Language Technology and Metalevel Architectures for Distributed Objects. Phd, Department of Computer Science, K.U.Leuven, Leuven, Belgium (1999) 24. Maes, P.: Concepts and experiments in computational reflection. In: Proceedings of OOPSLA’87. Volume 22. (1987) 147–155

Self-organizing Approaches for Large-Scale Spray Multiagent Systems Marco Mamei and Franco Zambonelli Dipartimento di Scienze e Metodi dell’Ingegneria, Università di Modena e Reggio Emilia, Italy {mamei.marco, franco.zambonelli}@unimo.it

Abstract. Large-scale multiagent systems will be the key software technology driving several future application scenarios. We envision a future in which clouds of microcomputers can be sprayed in an environment to provide, by spontaneously networking with each other, an endlessly range of futuristic applications. Beside this vision, similar kind of large-scale “spray” multiagent systems will be employed in several other scenarios ranging from ad-hoc networks of embedded and mobile devices to worldwide distributed computing. All of these scenarios present strong commonalities from the application development point of view, and new approaches and methodologies will be likely to apply, to some extent, to all of them. In particular, we argue that the issues related to the design and development of such spray multiagent systems call for novel approaches exploiting self-organization as first-class tools. With this regard, we survey a number of research projects around the world trying to apply self-organization to large-scale multiagent systems. Finally, we attempt at defining a rough research agenda that – in the long run – should integrate these ideas to develop a general and more assessed methodology for large-scale spray multiagent systems crosscutting several application domains.

1 Introduction Large-scale multiagent systems will be the key software technology driving next generation distributed computing systems. As the size and dynamism of computer networks grow, autonomous and decentralized approaches (i.e. multiagent systems) to develop applications will be the only viable solutions to handle the arising complexity. Today, the size and the dynamism of distributed service- and data-oriented activities on the Internet, to be sustainable, requires peer-to-peer multiagent approaches to interaction and data exchange [28, 31], as well as decentralized and autonomous approaches to system management and configuration [15]. In the near future, computer-based systems will be embedded in all our everyday objects and in our everyday environments. These systems will be typically communication enabled, and capable of coordinating with each other in the context of complex mobile distributed applications [17, 25, 27]. Also in this case, large-scale multiagent systems will be fundamental to handle the dynamism of the scenario. A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 53 – 70, 2006. © Springer-Verlag Berlin Heidelberg 2006

54

M. Mamei and F. Zambonelli

Looking a bit further, it is not hard to envision a future in which network of micro computers will be literally sold as spray cans, to be sprayed in an environment or on specific artifacts to enrich them with functionalities that, as of today, may appear futuristic and visionary [20, 36]. The number of potential applications of the scenario is endless, ranging from smart and invisible clothes, intelligent interactive environments, self-assembly materials and self-repairing artifacts. Besides the different physical scale of the components involved and of their interactions (from micro-computers interacting within networks extending across a few meters, to Internet hosts interacting at a world-wide scale), all of these types of spray multiagent system networks raise similar challenges as far as development and deployment of applications is involved, calling for radically novel approaches to distributed systems development and management. On the one hand, to avoid the unaffordable efforts related to the placement, configuration, and maintenance of such systems, there is the need of approaches enabling of deploying components without any a priori layout effort, and letting components to self-organize their application activities and self-retune their overall behavior depending on specific contingencies (e.g., localized faults and environmental changes) [15]. On the other hand, the autonomous and decentralized nature of the activities in such scenarios, together with the possibly unpredictable dynamics of the operating environments, is likely to make those systems exhibit unexpected, "emergent" behaviors - as recent observations in several types of decentralized networks (i.e., the Internet, the Web, as well as Gnutella) suggest. Therefore, there is also need for methodologies to predict and control the emergence of such behaviors and, when possible, offensively exploit them for the achievement of complex distributed tasks [4, 24, 37]. This paper aims at exploring the above issues and will be organized as follow: Section 2 details our vision about spray multiagent systems, starting from the microscale (i.e., literally spray-able computers), to the medium scale (smart artifacts and MANETs), up to the macro-scale (wide-area networks), and presents the key challenges to program such systems. From Section 3 to Section 6, we present four distinct approaches relying on self-organization to deal with such challenges. In particular, Section 3 will present a direct engineering approach to self-organization. Section 4 will present a reverse engineering approach. Section 5 will present a mixed approach in which directly engineered mechanism try to control reverse engineered behaviors (direct over reverse engineering). Section 6 presents another mixed approach in which reverse engineered mechanism combine directly engineered behaviors (reverse over direct engineering). Finally, Section 7 concludes the paper by attempting to define a roadmap of activities in the area of spray multiagent systems.

2 Spray Multiagent Systems and Application The concept of spray multiagent systems will soon pervade the ICT scenarios at every scale and at every level. In the following we will briefly survey our idea of future computer-based systems from the micro-scale (literally spray computer systems), to the medium-scale (handheld and wearable computers) to the global scale (Internet and Web computing). Moreover we introduce key challenges in programming spray multiagent systems application.

Self-organizing Approaches for Large-Scale Spray Multiagent Systems

55

2.1 Application Scenarios The Micro Scale. As proved in the context of the Smart Dust project at Berkeley [3], it is already possible to produce fully-fledged computer-based systems of a few cm3, and even much smaller ones will be produced in the next few years. Such computers, which can be enriched with communication capabilities (radio or optical), local sensing (e.g., optical, thermal, or inertial) and local effecting (e.g., optical and mechanical) capabilities, are the basic ingredients of our spray multiagent systems vision. Spray computers systems, as we imagine them, are clouds of sub-millimeterscale microcomputers, to be deployed in an environment or onto specific artifacts via a spraying or a painting process. Once deployed, such components will spontaneously network with each other and will coordinate their actions (i.e., local sensing and effecting) to provide specific “smart” functionalities. We imagine it will be possible, say in 2020, to go to the local store and there buy, for a few euros, a “pipe repairing” spray, made up of a cloud of MEMS microcomputers capable of navigating in a pipeline, recognizing the presence of holes, and self-assembling with each other so as perfectly repair the pipe. Similarly, we could imagine a spray to transform our everyday desk into an active one, capable of recognizing the positions and characteristics of objects placed on it and letting them meaningfully interact. Another peculiar application we envision is the “spray of invisibility” (described in [36]): a spray of micro devices capable of receiving and re-transmitting light emissions in a directional way, and capable of interacting with each other via shortrange wireless communications. When an object is covered by a layer of such spray, the emissions of the devices make external observers perceive exactly the same light configurations that they would have perceived if there were nothing in between. In fact sensors on the rear side of the object can receive such configurations and, via distributed coordination, can communicate them to emitters on the observer’s side to be retransmitted. Other types of application one could envision include any type of self-assembly artifact [20, 34], there included thing like Terminator T-1000, the nanoswarms of Michael Crichton’s novel “Prey” [9], and MEMS-based artificial immune systems and drugs [10]. Whatever the applications one envision, the key characteristics that will distinguish spray multiagent systems applications from traditional distributed computing systems are not – as one could at first think – the scale at which processes take place. After all the fact that an agent is executed on a micro device rather than on a high-end computer does not change it basic nature. Instead, what we think strongly distinguish spray multiagent systems are the facts that: •

•

Agent activities take place in a network whose structure derives from an almost random deployment process (as a spraying process is), and that is likely to change over time with unpredictable dynamics (due to environmental contingencies, failure of components, or simply mobility); The number of (hardware and, consequently, software) agents involved in a distributed application is dramatically high and hardly controllable. It is neither possible to enforce a strict configuration of software components nor to control their behavior during execution at a fine-grained level.

56


Both the above characteristics compulsory call for execution models in which applications are made capable of self-configuring and self-tuning their activities in a spontaneous and unsupervised way, adapting to whatever network structure and surviving network dynamics. The Medium Scale. On a different scale, spray multiagent systems well apply to the emerging scenarios of ubiquitous and pervasive computing, as enabled by handheld, wearable, and embedded, networked computing systems. We already typically carry on two or three computers (i.e., a cell phone, a laptop, and possibly a PDA). Also, our houses are already populated by a variety of microprocessor based furniture (e.g. TVs, phones, etc.). However, at the moment, the networking capabilities of these computerbased systems are under-exploited. On the contrary, very soon, the world around us will be densely populated by personal-area networks (e.g., the ensemble of Bluetooth enabled interacting computer-based devices we could carry on or we could find in our cars), local ad-hoc networks of handheld computers (e.g., networks of interacting PDAs carried by a team that have to directly interact and coordinate with each other in an open space), and furniture networks (e.g., Web-enabled fridges and ovens able to interact with each other and effectively support our cooking activities in a coordinated way). What we want to emphasize here is that the above types of networks, although being formed by different types of computer-based devices (let’s say, medium-end computers) and at different physical scales than literally spray multiagent systems, shares with them the same issues as far as the development and management of distributed multiagent applications is concerned. In fact: •

•

Most of these networks will be wireless, with structures dynamically varying depending on the relatives positions of devices, all of which intrinsically mobile (the persons in an ad-hoc network can move around in an environment and the position of home furniture can changed on needs) and characterized by the dynamic arrival dismissing of nodes (a PDA running out of power or a new home furniture being bought). Even if technically possible, it is simply not commercially and economically viable to consider deploying applications that would require explicit configuration and explicit tuning to meet the amorphous and dynamic nature of the networks in which applications will be expected to operate.

Also in these cases, new approaches are needed to develop applications in such open and dynamic scenarios. The Global Scale. Also in the case of macro-scale networks made up of high-end computer systems, i.e., the Internet and the Web, the dramatic growth of these networks and of the information and traffic to be managed, together with the increasing request for ubiquitous connectivity and the peculiar structures exhibited by such networks [1, 29], have recently raised researchers’ attention to the need of novel approaches to distributed systems management. From our perspective, these scenarios are in fact the first actually deployed systems that can be assimilated to a spray multiagent system. Traditional approaches to management, requiring human configuration efforts and supervision, fall short when the number of nodes in the network (or the number of


57

interrelated services and links in the Web) grows in a fully decentralized way, and when the presence of the nodes in a network is of an intrinsically ephemeral nature, as it is the case of laptops and, with regard to the Web, of several non-commercial data and services. In a number of application scenarios, the need to access data and services according to a variety of patterns and independently of the availability/location of specific servers and of the dynamics of the network have suggested the adoption of P2P approaches [28, 29]. In P2P computing, instead of promoting a strict control over the execution of software components and of their interactions (an almost impossible task given the dynamism of the scenario), the idea is to promote and support adaptive self-organization and maintenance of a structured network of logical relationships among components (i.e., an overlay network), to abstract from the physical “sprayed” nature of the actual network and survive events such the arrival of new nodes or the dismissing of some nodes. Overlay networks are currently the most widely investigated approach to distributed application development and management in worldwide computing, and are leveraging a variety of useful applications facilitating access to (and coordination over) a variety of world-wide distributed data and services. Although self-organizing overlay networks – as they are studied today – are not necessarily the only and best approach, the attention towards them is the body of evidence of the need – also in this scenario – for new self-organizing approaches to distributed application development. As a final note, we emphasize that, although the micro, medium, and global scale currently represent almost separated worlds, this will not be the case in the near future. All the above systems will probably be in the near future part of a mega decentralized network, including traditional Internet nodes, smart computer-enriched objects and furniture, networks of embedded and dispersed micro-sensors. For instance, the IPv6 addressing scheme will make it possibly to assign an Internet address to every cubic millimeter in the earth surface [12], thus opening the possibility for each and every computer-based component to become part of a single worldwide network. 2.2 Programming Spray Multiagent Systems Programming a spray multiagent system means to engineer a coherent and useful behavior from the cooperation of an immense number of unreliable parts interconnected in unknown, irregular, and time-varying ways. This translates in devising algorithms and control methodologies to let the sprayed computing devices self-organize their interaction patterns and their activities: devices have to start working together without the presence of any a-priori global supervisor or centralized controller. The basic low-level mechanisms upon which to rely to enable self-organization appear quite well-understood and are basically the same whatever the scale, whether that of sensor networks or that of wide-area P2P computing. Among the others: dynamic discovery of potential communication partners and of available services via broadcasting; localization and navigation in some sorts of spatial environment, whether physical (as in sensor networks) or computational (as in P2P systems). What is still missing is an assessed understanding of how to design, develop, and manage, self-organizing applications for these kinds of systems, leading to some

58


general purpose methodologies and programming environments. The main conceptual difficulty being that, while standard programming enables a direct-engineered control only on agents’ local activities, a variety of diverse application goals have to be achieved at a global scale. Identifying some general and abstract solution to enable the design and development – via a proper programming of self-organizing activities – of specific global application goals, would have a dramatic impact in all sketched scenarios (micro, medium and global scale). In this paper, without having solutions at hand, we survey a number of research efforts in this direction and try to identify some key directions to investigate. In the following sections, we are going to classify the self-organizing mechanisms being studied in the following way: In section 3, we will present direct engineering approaches to self-organization. These approaches aim at designing for scratch the activities of each agent, so that the whole multiagent system behaves as desired. This is the most conservative approach, and it can be reduced to some extend to “standard” decentralized application development (e.g. peer-to-peer software). In section 4, we will present reverse engineering approaches to self-organization. Here, the idea is to take a system (e.g. biological) that already exhibit some global behavior similar to the one we want to achieve. Then, try to reverse engineering its behavior and apply the result to a computation problem. This is basically the approach promoted by the swarm intelligence research community [5]. In section 5, we present a mixed approach (direct over reverse engineering) in which directly engineered mechanism try to control reverse engineered behaviors. The idea is to encourage the rise of only those behaviors that are useful to the application at hand. In section 6, we present the complementary mixed approach (reverse over direct engineering) in which reverse engineered mechanism try to combine directly engineered behaviors for the sake of realizing the whole application. In each section, we will first present a general overview of the approach. Then we survey a number of research projects trying to apply such ideas. Finally, we discuss the merits and shortcomings of the approach.

3 Direct Engineering of Self Organization 3.1 Overview Direct engineering approaches to self-organization basically aims at defining distributed algorithms that, starting from a few basic mechanisms (e.g., broadcast and localization), and exploiting local interactions and local computations, can provably lead a system to a final coherent global state. Unlike traditional distributed algorithms, self-organizing algorithms disregard micro-level issues such as ordering of events, process synchronization, and structure of the underlying networks (issues for which no possibility of control is assumed). Rather, they focus on the fact that the algorithm will eventually converge despite micro-level contingencies and that it will keep the system in the stable state despite perturbations (e.g., changes in the network structure).


59

3.2 Research Projects Micro Scale. Most of the researches in the area of micro-scale spray multiagent systems are performed in the context of the “sensor networks” research community [10]. There, the key issues being investigated relate to the identification of effective algorithms and tools to perform distributed monitoring activities by a cloud of distributed sensors in a physical environment (tracing the position and movement of an object, determining the occurrence of specific conditions, reporting sensed data back in an efficient way). These researches are indeed providing good insights on the theme of self-organization and are leading to some very interesting results. Techniques for self-localization, self-synchronization of activities, adaptive data distribution, all of which of primary importance for any type of spray multiagent systems, have been widely investigated [10, 21]. A typical example of a direct engineering approach to self-organization is distributed self-localization [21]. There, a number of randomly distributed particles can determine their geographical position starting from a few “beacon” particles (possibly self-determined via leader election and acting as reference frame) and recursively applying a local triangulation mechanism to determine their position with regard to close particles, until a global coherent positioning of all particles in the reference frame is reached. This is a good example for our idea of direct-engineered self-organization. The system self-organizes in that the agents act autonomously without the supervision of any external monitor or controller. However, the algorithm they follow is directly engineered so that they can achieve a final stable configuration. Medium Scale Direct. Coming to the medium scale, as far as we can see most of the researches are focusing either on routing algorithms for mobile ad-hoc networks [7] or on the definition of effective user-level ubiquitous environments [30]. Researches on routing algorithms for mobile networks share several common issues with researches on algorithms for data distribution on sensor networks. Routing in mobile ad-hoc networks, can be considered as a multiagent application where agents need to coordinate with each other to forward each other packets, so as to enable long range, multi-hop communication. Again, in our opinion, these algorithms can be considered as self-organizing, in that agents act autonomously without any central director. Researches on ubiquitous computing environments mostly focus on achieving dynamic interoperability of existing application-level components and of smartartifact and pervasive computing devices. For instance, the Gaia system developed at PARC [30], defines an architecture based on “active” interaction spaces, as a reification of a specific real-world environment (e.g., a meeting room), where preexisting (and pre-programmed) devices and user-level software components can dynamically enter, leave and autonomously interoperate with each other according to specific patterns specified as part of the active environment. Global Scale Direct Engineering. As far as the global scale is involved, most research on adaptive and unsupervised computing focus on the key idea of selforganizing overlay networks for P2P computing, which can be considered as a typical example of a direct engineering approach to self-organization. In P2P computing, an overlay network of peers is built over the physical network and, in that networks, peers act cooperatively to search specific data and services. In

60


first generation P2P systems (e.g., Gnutella [29]), the overlay network is totally unstructured, being built by having peers randomly connect to a limited number of other peers. Therefore, in these networks, the only effective way to search for information is message flooding. More recent proposals [28, 31] suggest structuring the network of acquaintances into specific regular “spatial shapes”, e.g., a ring or an N-dimensional torus. When a peer connects to the networks, it occupies a portion of that spatial space, and connects with those other peers that are neighbors accordingly to the occupied position of space. Then, data and services are allocated in specific positions in the network (i.e., by those peers occupying that position) depending on their content/description (as can be provided by a function hashing the content into specific coordinates). In this way, by knowing the shape of the network and the content/description of what data/services one is looking for, it is possible to effectively navigate in the network to reach the required data/services. 3.3 Pro and Cons Direct engineering approaches to self-organization have the great advantage of enabling engineers to achieve “by design” a specific robust self-organized behavior. Engineers, following standard methodologies, can design distributed algorithms to control distributed components to let them behave as specified by the application. Unfortunately, such approaches are effective only for a limited number of application needs. In fact, when the applications to be realized become more articulated, the complexity of the distributed algorithms involved may become overwhelming. For instance, extending P2P overlay-algorithms to highly mobile networks that can be partitioned (because of node mobility), merged and whose topology is likely to change quickly can become an overwhelming task from a direct engineering perspective.

4 Reverse Engineering of Self-organized Behaviors 4.1 Overview Reverse engineering approaches to self-organization aims at achieving complex coordinated behaviors by recreating in spray multiagent systems (and by adapting to specific application needs) the conditions to make some complex coordinated behaviors observed in other systems and in nature emerge in the computational spray multiagent system. In these cases, due to the complexity of the phenomena involved, engineers have no direct control on the evolution of the system, nor they can somehow prove that the system will behave as needed. Simply, they can be reasonably (i.e., probabilistically) confident that the global evolution of the system will eventually lead to the desired globally coordinated behavior. Simulations will be the workhorse of reverse engineering approaches. Simulations of spray multiagent systems will not only provide a framework on which to test the functionalities of a systems once developed, but they will be an integral part of the design and development process. Since the behavior of the components and of their interactions can hardly be modeled and predicted “on paper”, simulations appear


61

to be the only tool with which to have feedback on how a system will actually work. In other words, in reverse engineering approaches, the modeling phase consists in verifying via simulations the correctness of an idealized model suitable, but not necessarily close, to the target scenario (this model can be for example a biological or social model), then to refine the model and the simulations (that also realize a prototype implementation of the model) to rend both enough similar to the actual scenario to be taken in consideration as a candidate solution. In the past few years, several approaches to self-organization relying on the reverse engineering of diverse natural phenomena have been proposed in different areas and have shown their effectiveness in achieving difficult global coordination tasks. For instance, the phenomena of ant foraging [2, 18] and gossiping [6] turn out to be useful to discover path to information and diffuse information in networks of spray multiagent systems. 4.2 Research Projects Micro Scale. Some recent works on pattern formation for cooperative mobile robots [26, 35] try to reverse engineer natural phenomena such as chemical diffusion and embryogenesis activities to drive the movements of a swarm of tiny mobile robots (particles). In these works mobile robots connect with each other in an ad-hoc network to coordinate their movements. The main reversed abstractions, being researched, are those of chemical-gradients diffusion and local density estimation. These abstractions can be used by the robots to coordinate their movements. In particular, gradients can drive robots to reach specific locations [26, 35]. Density can be used to create diffusion-like processes, where robots tend to stay as far as possible from each other [35]. Both these two abstractions can be reverse-engineered in terms of distributed data structures (e.g., field-like hop-increasing structures and gradients of density pressures) over the ad-hoc network defined by robot themselves. Despite some promising results, up to now, the cited works focused on very simple motion strategies and computational particles – not much different from cellular automata cells. Medium Scale. In [23] a reverse-engineered pheromone-based approach to coordinate Unmanned Airspace Vehicles (UAVs) has been proposed. UAVs coordinate with each other by accessing a shared data space and leaving there pheromone-based data structures. In more detail, the shared data-space resembles the environment where UAVs are operating (it provides a digital representation of the battlefield). UAVs access the data-space on the basis of their physical-location that is mapped into a specific position in the data-space. On the basis of this mechanism, UAVs are able to spread and access digital pheromones in the data-space that mirrors their physical environment. This enables UAVs to coordinate on the basis of stigmergy [5]. In particular, by reverse engineering social insects behavior (that use pheromones to coordinate), UAV are able to perform sophisticated motion coordination task ranging from moving in formation, surround a target and avoid tracked enemies. This approach has been concretely implemented in a real-world scenario with great result. However, the techniques employed are very special purpose and it is difficult to extrapolate general lessons to be widely applied outside the motion coordination domain.

62


Global Scale. Several recent works in the area of Internet routing and distributed interactions are rooted on reverse engineering ideas coming from biology – i.e. ant foraging [2, 5, 6], or physics – i.e. potential fields [17]. As an example of this class of approaches (based on artificial ants), Anthill [2] support the design and development of adaptive peer-to-peer applications by relying on distributed mobile components (“ants”) that can travel and can indirectly interact and cooperate with each other by leaving and retrieving bunches of information (to act as synthetic pheromones) in the visited hosts. The key objective of anthill is to build robust and adaptive networks of peer-to-peer services by exploiting the capabilities of ants to re-organize their activity patterns accordingly to the changes in the network structure. These works are very promising, but a general methodology to let such reverse-abstractions widely applicable in the general context of Internet-based application, is still far from close. 4.3 Pro and Cons Reverse engineering approaches to self-organization have several advantages. First, it is possible to rely on results from other disciplines to explore a variety of complex coordination phenomena to be exploited in spray multiagent systems systems. Second, once the basic mechanisms underlying a self-organized behavior are understood and properly reproduced via simulation, programming an actual system to exhibit such behavior is dramatically simple, and it reduces to programming typically simple local rules and local interactions. In addition, the resulting system is intrinsically robust and adaptive, the result is typically robust and adaptive. Unfortunately, reverse-engineering approaches incur in two main potential drawbacks. First, generally speaking, reverse engineering approaches represent solutions looking for a problem1. Such approaches, in fact, start by reverse engineering a natural or social phenomenon (e.g. ants foraging) to devise a suitable spray-computer algorithm. Then, they look for problems (e.g. network routing) that can be solved by adopting the discovered algorithm. Although for a lot of algorithms it is rather easy to find suitable application domains, it can be difficult to find an already existing solution to the problem at hand. Second, the complex evolution of the system may cause several potential final states to be reached by a system, each of which potentially stable, without the possibility of predicting which ones will be actually reached after the selforganization process. In some cases, all of these states may be equivalent from the application viewpoint (e.g., in ant foraging, what matters is that a reasonably short path to food/information is reached, no matter what the path actually is). Also, in these cases, the presence of multi stable states may be also advantageous, because this ensure that the system, even if strongly perturbed (e.g., due to network or environmental dynamics), will be able to soon re-organize its activity into another stable state. However, in several other cases, the designer may wish that its system self-organizes to a specific global states, not to any one. 1

It is rather ironic that “solution looking for a problem” often sounds as a synonym for useless approach, in the research community. In fact, it is actually rather common as a business model. A company that finds a clever way to do something, then looks for problems (i.e. a market share) to sell that solution.


63

Both these two problems could be solved by mixing together direct and reverse engineering approaches. The introduction of direct engineered control could enable to better design the activity of the system so as to better encode a specified application task. Moreover, when the evolution of a system can lead to several final global states, and only a limited set of these are useful to the specific application purposes, the problem arise on how to control/direct the evolution of the system so as to ensure that it will self-organize as desired. Realizing such kind of mixed approach presents a number of challenges. On the one hand, introducing some sorts of direct engineered control should be done without undermining the basic advantages of the reverse engineering approach, i.e., its capability to promote the spontaneous formation of complex and robust patterns of activity with little design and coding efforts. On the other hand, for such a mixed approach to be possible, it is necessary that both direct algorithms and reversed selforganizing mechanism are modeled and coded with the same set of basic abstractions. In the next two sections we are going to survey some recent researches that aim to that direction.

5 The Control of Self-organizing Behaviors (Direct over Reverse Engineering) 5.1 Overview The main idea of this approach is the use of direct engineered mechanisms to control reverse engineered self-organizing behaviors. Specifically, it is based on these two key points: • •

Use reverse engineering approaches to find low-level mechanism and interaction primitives that are robust and flexible Use direct engineering to weave together several low-level mechanisms to achieve a desired application.

The core idea of this proposal is to compensate the lack of control typical of reverse approaches by superimposing a directly engineered control layer. At the same time, the lack of flexibility and scalability of most direct engineered solutions is compensated by the low level reverse engineered mechanisms that tend to be robust and flexible. 5.2 Research Projects Micro Scale. The Amorphous Computing project at MIT focuses on the problem of identifying suitable models for programming applications over amorphous networks of computational particles [20]. The particles constituting an amorphous computer have the capabilities of locally propagating sorts of computational fields in the network, and to locally sense and react to such fields (the field abstraction has been reverse-engineered from the biological concept of morphogen gradients). By having particles sense and re-propagate these fields, coordinated patterns of activities emerge in the system independently of the structure of the network. Moreover, the Amorphous computing project has defined a simple yet effective language for

64


programming particles on the basis of computational fields. On this base, it has been shown how it is possible to exploit such a language to let the particles (directly) selforganize a coordinate systems and self-determine their position in it, and to have a variety of global patterns getting (directly) organized in a system from local interactions. What the project has still not addressed are the problems related to mobile and ephemeral particles: the network is considered static, and the relative position of particles is considered fixed. In addition, the project focused only on the formation of spatial patterns, completely disregarding other application scenarios. Other sources of examples, come from recent proposals to control the motion of a modular robot. A modular robot is a collection of simple autonomous actuators with few degrees of freedom connected with each other. A distributed control algorithm is executed by all the actuators that coordinate to let the robot assume a global coherent shape or a global coherent motion pattern (i.e. gait). In [32] a mixed (direct-reverse) approach like the one discussed in this section has been proposed. At the bottom-level, reverse engineering has been applied to find a flexible and robust communication mechanism to let the robots interact. Such mechanism has been reverse-engineered form the biological concept of hormones. In abstract terms, a hormone is a message that triggers different actions at different subsystems and yet leaves the execution and coordination of these actions to the local subsystems. For example, when a human experiences sudden fear, a hormone released by the brain causes different actions, e.g., the mouth opens and the legs jump. Reverse engineering a hormone consists in modeling it by means of a type of message with specific properties [32]. At the toplevel, direct engineering has been applied to combine several hormones together with robots reactions to actually implement gait control mechanisms. Medium Scale. The reverse-engineered idea of fields (or morphogen gradients) have been applied to medium-scale pervasive-computing scenario in the context of the TOTA (Tuples On The Air) middleware [16]. TOTA relies on spatially distributed tuples, implementing the concept of field, for both supporting adaptive and uncoupled interactions between agents, and context-awareness. Agents can inject these tuples in the network, to make available some kind of contextual information and to interact with other agents. Tuples are propagated by the middleware, on the basis of application specific patterns, defining sorts of “computational fields”, and their intended shape is maintained despite network dynamics, such as topological reconfigurations. Agents can locally “sense” these fields and can rely on them for both acquiring contextual information and carrying on distributed self-organizing coordination activities. The TOTA programming model enable to specify and control (via direct engineering) the behavior of tuples and agents. The TOTA model is effective in realizing applications centered on “spatial” coordination, where the goal is to coordinate the activities of components in the space – either physical or network-based (e.g. motion coordination, self-assembly, network routing, etc.). However, the generality of this approach in supporting the design and development of a variety of applications and their power in supporting very largescale applications for highly dynamic networks is still to be proved. Global Scale. To the best of our knowledge, very few works tries to control self-organizing behaviors in global-scale computing. Swarm-Linda [18] is an antinspired system to realize distributed tuple spaces over the Internet. At the low-level a


65

reverse-engineered swarm of ant-agents performs a foraging-kind of algorithm to create routes to quickly access tuples in the distributed tuple space. At the top-level, tuples are accessed by means of the directly engineered Linda operations. Like in other ant-foraging-inspired systems, the basic drawback of this approach is in the fact that it is very special purpose. Bridging the gap between these (successful) examples and a methodology is far from simple. 5.3 Pro and Cons This kind of approach has a number of advantages. In particular it allows to actually design a distributed application and eventually prove its correctness. At the same time, the application can be grounded on reverse-engineered abstractions that can deal with most of the low-level complexity assuring flexibility and robustness. For example, the hormone-based control mechanism described above is designed to achieve a specific motion gait. It is flexible and robust, since the hormones on which it is grounded can tolerate local malfunctions, propagation delays, etc. [32]. The main drawback of this approach is that general-purpose methodologies to weave together low-level reverse-engineered behaviors to create an application are still unknown. Up to know only few and special purpose approaches have been proposed.

6 Self-composition of Designed Tasks (Reverse over Direct Engineering) 6.1 Overview This kind of mixed approach is complementary to the previous one. It uses reverse engineered self-organizing behaviors to weave together direct-engineered primitive applications. This is the realm of genetic-algorithms and learning-kind of approaches: direct-engineered primitive applications are combined by means of a genetic or learning based mechanism to achieve complex applications [13, 14]. Specifically, this approach is based on these two key points: • •

Use direct engineering approaches to find low-level mechanisms and primitive solutions to the problem at hand. Use reverse engineering approaches like genetic-algorithms and learning to combine, evolve and optimize directly engineered mechanism so as obtain a complete solution with good performance.

Complementary to the previous approach, this proposal tries to adopt, well defined, directly engineered mechanism to deal with to deal with the application fundamental tasks. Then it uses reverse engineering approaches to overcome the complexity required by the application. 6.2 Research Projects Micro Scale. One of the major problems in sensor networks is how to make sense of low-level sensor readings to infer some property on the environment being monitored.

66


Usually, sensors periodically transmit collected data to a central processing unit, that collects and elaborate all the data, and tries to infer what is happening in the environment. This kind of centralized architecture has several drawbacks (singlepoint-of-failure, high-cost in transmitting data to the central processing unit, scalability, etc.). New ideas are arising to make such computations distributed across the whole sensor network. In particular, some recent works [8, 33] are combining directly engineered approaches to data collection and data fusion, with reverseengineered approaches to learning and data-clustering (neural networks, etc.). More in detail, low-level directly-engineered mechanism are combined together by means of high-level reverse-engineering mechanism that enable the network to learn and classify autonomously what is happening. These works achieved very significant result, by greatly reducing the programming effort to manage a sensor network. However, they mainly focused on very simple learning behaviors, and complex applications have still to be tackled. Medium Scale. In [25] a peculiar system to tack people movements is presented. The system is based on a PDA coupled with a GPS device carried on by a user. The PDA on the basis of GPS reading is able to track the user and to infer if the user is moving by foot or it is in a vehicle (using inferred speed measure). At the low-level, this system uses directly-engineered mechanism to store and average GPS readings over time. At the high-level, it uses a reverse-engineered learning approach to let the system infer from low-level GSP reading high-level information (location and vehicle). The same approach has been applied in other works [27] to track and infer more general user activities. This system, although simple and special purpose, shows how reverse-engineered approaches at the top-level can greatly save programming effort. However, it is not easy to generalize it let is suitable to general application domains. Global Scale. One of the best examples of this class of approaches is represented by Internet search (meta)engines based on genetic algorithms [19, 22]. These are applications that allow a user to find information over the Web in a more efficient way. The key idea is to let the application build a personalized user profile so as to better discriminate between relevant and irrelevant documents. These kind of systems are basically build in two main parts [19, 22]: direct engineering is applied at the lowlevel to encode information retrieval agents on the basis of the user profile. Here direct algorithms for text processing and ranking are applied. Reverse engineering is applied in terms of a genetic algorithm at the top-level to create new information retrieval agents. In particular, such agents are created by replicating (with genetic operations – such as mutation and crossover) top-performing existing agents, so as to iteratively increase the system performances. Other examples come from some works related to the ADELFE methodology [11]. The ADELFE methodology proposes to design directly (with standard tools like UML) low-level agent behaviors. Top-level agent coordination patterns are instead autonomously derived from reverse-engineered evolutionary techniques. Such methodology has been applied to a number of scenarios. In [11] it has been applied to a global-computing scenario where agents are in charge of managing a work-flow application. In these context, low-level processes are modeled in terms of directly engineered agents, that have been explicitly programmed with the underlying business


67

logic. Top-level workflow is instead processed by means of a reversed evolutionary computing mechanism. Again, the main drawback of this approach is that it is very difficult to extend and apply the evolutionary-based algorithm to complex problems. 6.3 Pro and Cons The main advantage of this approach is that it greatly reduce the programming effort. Once the basic mechanisms to realize the application have been found, the reverseengineering part (e.g. genetic algorithms) handles the rest finding a suitable solution. However, with this regard, it is of course fundamental that the reverse engineered recombination does not disrupt the direct algorithms. The main drawback of this approach is that it leads to something like a black-box solution: eventual problems in the final outcome are difficult to be traced out and slight customizations in the final application are likely to need a complete rework. Besides these examples, the general problem of combining self-organizing behaviors and engineering approaches in a complex self-organizing system – which, to the authors’ opinions, will represent one of the key challenges for the whole research area of multiagent systems – is still open and widely uninvestigated. The urge for appropriate control models and for a uniform approach to direct and reverse engineering of self-organization appears even more compulsory when considering another factor: in several cases, even simple systems engineered with a direct approach may – due to simplifications in their modeling – exhibit unexpected self-organizing behaviors. Although sometimes such unexpected behaviors may be irrelevant or even useful for them to be offensively exploited (consider, e.g., the emergence of scaling in complex networks, and the advantages it carries to the robustness of the network [1]), sometimes they may be damaging and introduce the need to defend from them by proper forms of control.

7 Concluding Remarks and Research Agenda In the paper we presented four distinct approaches to take advantage of selforganization to deal with the challenges posed by large-scale multiagent systems. In our opinion, each of the presented approaches has merits and drawbacks and much further work will be required to develop a general framework that combines all of them meaningfully. To conclude, we sketch a rough research agenda for what we believe are the key challenges to be faced in the area of self-organization for the design, development, and control, of spray multiagent system applications. First, we think that researches should rely on a deeper understanding of the global behavior of spatially distributed systems of autonomous and interacting components, in any area. This could be used to exploit self-organization principles both offensively (i.e., to use them so as to achieve in a simple way globally coordinated behaviors) and defensively (i.e., to prevent the potential emergence of possibly dangerous selforganizing behaviors). Both cases may require the study of mechanisms and tools to somehow direct and engineering such systems in a decentralized way, so as to enforce some sorts of control over these systems despite the impossibility of controlling them

68


in their full. As previously anticipated, some recent approaches already take inspiration from phenomena of self-organization in real-world systems to defines adaptive and reliable solutions to specific contingent problems (e.g., ant-inspired algorithms and coordination based on computational fields). Currently underestimated phenomena occurring in other types of spatially distributed systems of autonomous components (e.g., macro-ecology patterns of population distribution and biodiversity, physics of granular media, emergence of synchronization, morphogenesis) are worth to be explored too. Also, more simulation work to possibly predict what types of behaviors the emergent scenarios of spray multiagent systems will exhibit will be compulsory. Once the above understanding will be quite assessed, we think there will be need to define a general purpose programming model for designing and deploying applications in such dynamic networks of spray multiagent systems, together with the development of associated middleware infrastructure and tools. One very ambitious objective could be for such a model to enable people to program, deploy, and control self-organizing and adaptive distributed applications (exploiting both direct and reverse engineering approaches) with a minimal background knowledge – the same as a undergraduate students can currently develop excellent distributed Web-based Java applications – and independently of the specific application scenario, sensor networks rather than wide-area distributed applications – the same as an undergraduate student can easily and with minimal efforts adapt its applications for execution on both a Linux workstation and a Cellular phone. The definition of such a model will clearly require the identification of a minimal set of abstractions enabling the modeling of salient characteristics of spray multiagent systems and their operational environments. In our opinion, approaches based on computational fields [16, 35] are very promising to this purpose, by enabling to uniformly model a wide variety of distributed selforganizing behaviors (both with direct and reverse engineering) and to effectively model also ant-inspired approaches [18]. However, this opinion is still to be verified. Eventually, all the above researches will definitely increase our understanding on the potentials of spray multiagent systems at any scale, and will likely cause a range of new application areas to come to the fore. For instance, systems such as worldwide file sharing and artifacts like the cloak of invisibility could have simply never been conceived a few years ago. The new software and hardware technology will call also for visionary application-oriented thinkers, to unfold in full the newly achieved application potentials.

References [1] R. Albert, H. Jeong, A. Barabasi, “Error and Attack Tolerance of Complex Networks”, Nature, 406:378-382, 2000. [2] O. Babaoglu, H. Meling, A. Montresor, “Anthill: A Framework for the Development of Agent-Based Peer-to-Peer Systems”, International Conference on Distributed Computing Systems, Vienna (A), 2002. [3] A. A. Berlin, K. J. Gabriel, “Distributed MEMS: New Challenges for Computation”, IEEE Computing in Science and Engineering, 4(1):12-16, 1997.


69

[4] C. Bernon, M.P. Gleizes, S. Peyruqueou, G. Picard, “ADELFE: a Methodology for Adaptive Multi-Agent Systems Engineering”, 3rd International Workshop Engineering Societies in the Agents World, LNAI No. 2577, 2002. [5] E. Bonabeau, M. Dorigo, G. Theraulaz, “Swarm Intelligence”, Oxford University Press, 1999. [6] D. Braginsky, D. Estrin, “Rumor Routing Algorithm For Sensor Networks”, 1ST Workshop on Sensor Networks and Applications (WSNA), 2002. [7] J. Broch, D. Maltz, D. Johnson, Y. Hu, J. Jetcheva, “A Perfomance Comparison of MultiHop Wireless Ad Hoc Network Routing Protocols”, ACM/IEEE Conference on Mobile Computing and Networking, ACM Press, Dallas (TX), 1998. [8] E. Catterall, K. Van Laerhoven, M. Strohbach, “Self-Organization in Ad-Hoc Sensor Networks: An Empirical Study”. In Proc. Of Artificial Life VIII, Sydney, Australia. MIT Press, 2002. [9] M. Crichton, “Prey: a Novel”, HarperCollins, 2002. [10] D. Estrin, D. Culler, K. Pister, G. Sukjatme, “Connecting the Physical World with Pervasive Networks”, IEEE Pervasive Computing, 1(1):59-69, 2002. [11] George J.P., Edmonds B. Glize P., Making self-organizing adaptive multi-agent systems work. To appear in Methodologies and Software Engineering for Agent Systems, Kluwer, 2004. [12] T. Imielinski, S. Goel, “Dataspace - querying and monitoring deeply networked collections in physical space”, IEEE Personal Communications Magazine, pp. 4-9 2000. [13] C. Jacob, “Illustrating Evolutionary Computation with Mathematica”, Morgan Kauffman Publisher, San Francisco, 2001. [14] J. Kennedy, R. Eberhart, “Swarm Intelligence”, Morgan Kauffman Publisher, San Francisco, 2001. [15] J. Kephart, D. M. Chess, "The Vision of Autonomic Computing", IEEE Computer, 36(1):41-50, 2003. [16] M. Mamei, F. Zambonelli, “Programming Pervasive and Mobile Computing Applications with the TOTA Middleware”, 2nd IEEE Conference on Pervasive Computing and Communications, Orlando (FL), 2004. [17] M. Mamei, F. Zambonelli, L. Leonardi, “Co-Fields: a Physically Inspired Approach to Distributed Motion Coordination”. IEEE Pervasive Computing, 3(2):52-60. [18] R. Menezes, R. Tolksdorf, “SwarmLinda: a New Approach to Scalable Linda Systems based on Swarms“, 16th ACM Symposium on Applied Computing, Melbourne (FL), 2003. [19] A. Moukas, P. Maes, “Amalthaea: An Evolving Multi-Agent Information Filtering and Discovery System for the WWW”, Journal of Autonomous Agents and Multi-Agent Systems", 1(1):59-88, 1998. [20] R. Nagpal, A. Kondacs, C. Chang, “Programming Methodology for Biologically-Inspired Self-Assembling Systems”, AAAI Spring Symposium on Computational Synthesis, 2003. [21] R. Nagpal, H. Shrobe, J. Bachrach, “Organizing a Global Coordinate System from Local Information on an Ad Hoc Sensor Network”, in Information Processing in Sensor Networks, LNCS No. 2643, Springer Verlag, 2003. [22] Z. Nick, P. Themis, “Web Search Using a Genetic Algorithm”, IEEE Internet Computing, 5(3):18-26, 2001. [23] V. Parunak, S. Brueckner, J. Sauter, “Digital Pheromones for Coordination of Unmanned Vehicles”, Workshop on Environments for Multi-agent Systems (E4MAS), LNAI 3374, Springer Verlag, 2004.

70


[24] V. Parunak, S. Bruekner, J. Sauter, "ERIM’s Approach to Fine-Grained Agents", NASA/JPL Workshop on Radical Agent Concepts, Greenbelt (MD), Jan. 2002. [25] D. Patterson, L. Liao, D. Fox, H. Kautz, "Inferring high-level behavior from low-level sensors",UBICOMP, Seattle, Washington, USA, 2003. [26] D. Payton, M. Daily, R. Estowski, M. Howard, C. Lee, “Pheromone Robotics”, Autonoumous Robots, Kluwer Academic Publishers, 11(3):319-324, 2001. [27] M. Philipose, K. Fishkin, M. Perkowitz, D. Patterson, D. Fox, H. Kautz, D. Hahnel, "Inferring Activities from Interactions with Objects", IEEE Pervasive Computing, 3(4):50-57, 2004 [28] S. Ratsanamy,, P. Francis, M. Handley, R. Karp, "A Scalable Content-Addressable Network", ACM SIGCOMM Conference 2001, 2001. [29] M. Ripeani, A. Iamnitchi, I. Foster, “Mapping the Gnutella Network”, IEEE Internet Computing, 6(1):50-57, 2002. [30] M. Roman et al., “ Gaia : A Middleware Infrastructure for Active Spaces”, IEEE Pervasive Computing, 1(4):74-83, 2002. [31] A. Rowstron, P. Druschel, “Pastry: Scalable, Decentralized Object Location and Routing for Large-Scale Peer-to-Peer Systems”, 18th ACM Conference on Middleware, Heidelberg (D), 2001. [32] W. Shen, B. Salemi, P. Will, “Hormone-Inspired Adaptive Communication for SelfReconfigurable Robots”, IEEE Transaction on Robotics and Automation, 18(5):1-12, 2002. [33] S. Simic, “A Learning-Theory Approach to Sensor Network”, IEEE Pervasive Computing 2(4):44-49, 2003. [34] K. Stoy, R. Nagpal, “Self-Reconfiguration Using Directed Growth”, 7th International Symposium on Distributed Autonomous Robotic Systems, Toulouse (F), 2004. [35] M. Vasirani, M. Mamei, F. Zambonelli, “Morphogenesis of Cooperative Mobile Robots with Minimal Capabilities”, presented at the 1st European Workshop on Multiagent Systems, Oxford (UK), 2003. [36] F. Zambonelli, M. Mamei, “The Cloak of Invisibility: Challenges and Applications”, IEEE Pervasive Computing, 1(4):62-70, 2002. [37] F. Zambonelli, M. Mamei, A. Roli, “What Can Cellular Automata Tell Us About the Behaviour of Large Multi-Agent Systems?”, in Software Engineering for Large Scale Agent Systems, LNCS No. 2603, April 2003.

Coordination Artifacts as First-Class Abstractions for MAS Engineering: State of the Research Andrea Omicini, Alessandro Ricci, and Mirko Viroli DEIS, Alma Mater Studiorum – Università di Bologna a Cesena via Venezia 52, 47023 Cesena, Italy {andrea.omicini, a.ricci, mirko.viroli}@unibo.it

Abstract. According to social / psychological theories like Activity Theory (AT), artifacts plays a fundamental role in the context of human organisations for supporting cooperative work and, more generally, complex collaboration activities. Artifacts are either physical or cognitive tools that are shared and exploited by the collectivity of individuals for achieving individual as well as global objectives. The conceptual framework of artifacts for MAS is meant to bring the same sort of approach to multiagent systems (MAS). In particular, coordination artifacts are the entities used to shape the agent environment so as to fruitfully enable, promote and govern cooperative and social activities of agent ensembles. Thus, coordination artifacts also capture and extend the notion of coordination medium as coming from the distributed system and DAI fields, by generalising over abstractions like blackboards, tuple spaces and channels. In this paper we account for the current state of the research on coordination artifacts. First we discuss the background from AT to artifact for MAS, then we summarise the model for the coordination artifact abstraction, and the state-ofthe-art of the research on models, methods and technologies currently available for engineering MAS application with coordination artifacts.

1 Introduction The need to achieve a coherent systemic behaviour in MASs and agent societies has led to more articulated approaches than those based on direct interaction and explicit communication. Environment-based coordination and, more generally, mediated interaction frameworks and infrastructures based on forms of coordination / cooperation without direct communication (see [1] for a recent survey) are among the most promising lines of research in the MAS field. Even outside MAS and CS, mediated interaction and environment-based coordination are highly debated issues in those research fields where collaborative and cooperative activities are studied in complex social contexts. Notable examples are CSCW and HCI [2], which recently focused on cognitive and social theories explicitly taking into account the role of environment in coordination— such as Distributed Cognition [3] and Activity Theory (AT) [4]. There, one of the most relevant issues is to understand what makes a good place for actors to work together out of an environment: re-formulated in MAS terms, the question is how to design the agent environment to suitably support social activities of a (possibly open) agent society. A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 71–90, 2006. c Springer-Verlag Berlin Heidelberg 2006

72

A. Omicini, A. Ricci, and M. Viroli

Adopting AT as a conceptual framework for MAS social activities has led to the recognition that agents are not the only abstractions to build MASs. Artifacts are also necessary to enable and constrain agent actions, to mediate their interactions with other agents and with the environment, and more generally to improve their ability to achieve their individual and social goals [5]. More specifically, coordination artifacts are social artifacts shared by agents in a MAS, which are meant to enable and govern the interaction among agents, and between agents and their environment. Along this line, coordination artifacts represent a straightfroward generalisation of the notion of coordination medium as coming from fields like coordination models and languages and distributed AI—including abstractions like tuple spaces, channels, blackboards and the alike. In this paper, we try to summarise the many results of our research on coordination artifacts and their role in the engineering of MASs (multiagent systems), and provide a comprehensive view of its many aspects and consequences, from MAS technologies and infrastructure to agent-oriented software engineering (AOSE) methodologies.

2 Artifacts: The Theoretical Background 2.1 Activity Theory as a Conceptual Frameworks Activity Theory (AT), also defined Cultural-Historical Activity Theory (CHAT), is a social psychological theory born in the context of Soviet Psychology from the work of Lev Vygotsky (1926–62), rooted in the dialectic materialism of Marx and Engels [6]. Originated as a part of the attempt to produce a Marxist Psychology, AT has been developed and evolved in the Soviet Union by Vygotsky’s students—Alexey Leontiev in particular—for the first half of the 20th century. Then, in the second half it spread also outside Soviet Union, first in Scandinavia and in Germany and then—at the end of the 1990s—in the United States. Nowadays it is widely applied also in the context of computer science related fields, such as Computer Supported Cooperative Work (CSCW) and Human Computer Interaction (HCI) (see [4] for a survey). Broadly speaking, AT is a very general framework for conceptualising human activities—how people learn, how society evolves—based on the concept of human activity as the fundamental unit of analysis. The approach was developed in contrast to the purely-cognitive approaches that were dominating the first years of the 20th century: according to them, human individual and social activities could be analysed and understood by merely focussing on the internal (mentalistic) representation of the individuals—in other words, based only on the individual information-processing capabilities. By contrast, the basic inspiration principle of AT is the principle of unity and inseparability of consciousness (human mind) and activity: human mind comes to exist, develops, and can only be understood within the context of a meaningful, goal-oriented, and socially determined interaction between human beings and their material environment. Interesting enough, this more or less sounds like the human-organisational version of the notion of situated intelligence by Brooks [7], where intelligence cannot be thought and conceived out of context, and interaction with the environment is proposed as the main source for intelligent behaviour of artificial systems.

Coordination Artifacts as First-Class Abstractions for MAS Engineering

73

In fact, a fundamental aspect for AT is the interaction between the individuals and the environment where they live, in other words their context. After an initial focus on the activity of the individuals, AT research evolved toward the study of human collective work and social activities, then faced issues such as coordination and organisation of activities in human society. In the context of MASs, the investigation of AT is of particular relevance because it remarks the fundamental role of the environment in the development of complex systems, and suggests how to shape the environment to make it favourable to the development of collaborative activities. According to AT, any activity carried on by one or more components of a systems— individually or cooperatively—cannot be conceived or understood without considering the tools or artifacts mediating the actions and interactions of the components. Artifacts on the one side mediate the interaction between individual components and their environment (including the other components), on the other side embody the part of the environment that can be designed and controlled to support components’ activities. Moreover, as an observable part of the environment, artifacts can be monitored along with the development of the activities to evaluate overall system performance and keep track of system history. In other words, mediating artifacts become first-class entities for both the analysis and synthesis of individual as well as cooperative working activities inside complex systems. Such a vision can be found also as a main aspect in Distributed Cognition [3], a branch of cognitive science which proposes that human cognition and knowledge representations, rather than being soley confined to the boundaries of an individual, is distributed across individuals, tools and artifacts in the environment. The complexity of activities of the social systems accounted for by AT and Distributed Cognition can be found nowadays in MASs. This is why we consider such conceptual frameworks as fundamental for the analysis and synthesis of social activities inside MAS, and in particular of the artifacts mediating such activities [8]. Examples range from coordination abstractions such as tuple centres [9], to pheromone infrastructure [10] in the context of stigmergy coordination, to the Institution abstraction in electronic-institution approaches [11], to cite some. 2.2 Goals of Agents and Use of Artifacts Other contributions to the artifact theoretical background come from cognitive sciences. In fact, by considering the conceptual framework described in [12], agents can be generally conceived as goal-governed or goal-oriented system. Goal-governed systems refer to the strong notion of agency, i.e. agents with some forms of cognitive capabilities, which make it possible to explicitly represent their goals, driving the selection of agent actions. Goal-oriented systems refer to the weak notion of agency, i.e. agents whose behaviour is directly designed and programmed to achieve some goal, which is not explicitly represented. In both goal-governed and goal-oriented systems, goals are internal. External goals instead refer to goals which typically belong of the social context or environment where the agents are situated. External goals are sorts of regulatory states which condition agent behaviour: a goal-governed system follows external goals by adjusting internal ones.

74


This basic picture is then completed by systems or parts of a system which are not goal-oriented, but function-oriented, i.e. explicitly designed to provide some kind of functionality and that can be suitably exploited or used by goal-oriented systems to support their activities. Keeping the same nomenclature as appears in human science theories—Activity Theory and Distributed Cognition in particular—we refer such entities as artifacts. We define the artifact abstraction in MAS as a computational device populating agents’ environment, designed to provide some kind of function or service, to be used by agents —either individually or collectively— to perform their activities. Contrary to agents, artifacts are not characterised by internal goals or by an autonomous behaviour, but in terms of a function1 , and its exploitation by agents through artifact use. If agents are often characterised by the intentional stance, artifacts are characterised by the design stance. It’s worth noting that the concept of destination is related but not identical the concept of function: it is an external goal which can be attached to an object or an artifact by users, in the act of using it. Then an artifact can be used according to a destination which is different from its function. Artifacts can represent either the resources or objects that are directly the objective of agent activities, or the tools that are used as a medium to achieve such objectives. An example for the first case is a database or a knowledge repository in general, used to store and retrieve information. A simple example for the second case is given by a blackboard, used by agents as a tool to communicate and coordinate. Actually, this is an example of coordination artifact, focus of next sections. As remarked for artifacts in human societies [12], an interesting distinction holds between use and use value, which concerns agents / artifacts relationships: there, use value corresponds to the evaluation of artifact characteristics and function, in order to select it for a (future) use. The distinction corresponds to two different kinds of external goals attached to an artifact: (i) the use-value goal, according to which the artifact should allow user agents to achieve their objective—such an external goal drives the agent selection of the artifact; (ii) the use goal, which directly corresponds to the agent internal goal, which guides the actual usage of the artifact. From the agent viewpoint, when an artifact is selected and used it has then a use-value goal which somehow matches its internal goal. By extending the above considerations, the classical tool-using / tool-making distinction from anthropology [13] can be articulated along three main distinct aspects, which characterise the relationship between agents and artifacts: – use – selection – construction and manipulation While the first two aspects are clearly related to use and use value, respectively, the third is the obvious rational consequence of a failure in the artifact selection process, or in the use of a selected artifact. Then, a new, different artifact should be constructed, or obtained by manipulation of an existing one. 1

The term “function” here refers to a functionality embodied by an artifact, and should not be confused with the same term as used e.g. in mathematics or in programming languages.


75

2.3 Cognitive Use of Artifacts Artifacts are available for agent use. So when intelligent agents are concerned, artifacts should be available for cognitive use. The strict relationship between intelligence and use of tools and artifacts is largely debated by anthropologists, psychologists and cognitive scientists in general [14]. In the field of robotics, this has led to the proposal of a “Tooling Test for Intelligence”, aimed at evaluating intelligence in terms of the ability to exploit tools [15]. In the MAS field, the same sorts of considerations have inspired the Agens Faber approach, based on the idea that agent intelligence should not be considered as separated by the agent ability to perceive and affect the environment—and so, that agent intelligence is strictly related to the artifacts that enable, mediate and govern any agent (intelligent) activity [16]. One of the key issues here and in the Agens Faber approach is how artifacts can be effectively exploited to improve agents’ ability to achieve individual as well as social goals. The main questions to be answered are then: How should agents reason to use artifacts in the best way, making their life simpler and their action more effective? How can agents reason to select artifacts to use? How can agents reason to construct or adapt artifact behaviour in order to fit their goals? On the one hand, the simplest case concerns agents directly programmed to use specific artifacts, with usage protocols directly defined by the programmer either as part of the procedural knowledge / plans of the agent for goal-governed systems, or as part of agent behaviour in goal-oriented system. In spite of its simplicity, this case can bring several advantages for MAS engineers, exploiting separation of concerns for programming simpler agents, by charging some burden upon specifically-designed artifacts. On the other hand, the intuition is that in the case of fully-open systems, the capability of the artifact to describe itself, its function, interface, structure and behaviour could be the key for building open MASs where intelligent agents dynamically look for and select artifacts to use, and then exploit them for their own goals. At a first glance, it seems possible to frame the agent ability to use artifacts in a hierarchy, according to five different cognitive levels at which the agent can use an artifact: unaware use — at this level, both agents and agent designers exploit artifacts without being aware of it: the artifact is used implicitly, since it is not denoted explicitly. In other words, the representation of agent actions never refers explicitly to the execution of operation on some kind of artifacts. embedded / programmed use — at this level, agents use some artifacts according to what has been explicitly programmed by the designer: so, the artifact selection is explicitly made by the designer, and the knowledge about its use is implicitly encoded by the designer in the agent. In the case of cognitive agents, for instance, agent designers can specify usage protocols directly as part of the agent plan. From the agent viewpoint, there is no need to understand explicitly artifact operating instructions or function: the only requirement is that the agent model adopted could be expressive enough to model in some way the execution of external actions and the perception of external events. cognitive use — at this level, the agent designer directly embeds in the agent knowledge about what artifacts to use, but how to exploit the artifacts is dynamically

76


discovered by the agent, reading the operating instructions. Artifact selection is still a designer affair, while how to use it is delegated to the agent rational capabilities. So, generally speaking the agent must be able to discover the artifact function, and the way to use it and to make it fit the agent goals. An obvious way to enable agent discovery is to make artifact explicitly represent their function, interface, structure and behaviour. cognitive selection and use — at this level, agents autonomously select artifacts to use, understand how to make them work, and then use them: as a result, both artifact selection and use are in the hands of the agents. It is worth noting that such a selection process could also concern sets of cooperative agents, for instance interested in using a coordination artifact for their social activities. construction and manipulation — at this level, agents are lifted up to the role of designers of artifacts. Here, agents are supposed to understand how artifacts work, and how to adapt their behaviour (or to build new ones from scratch) in order to devise out a better course of actions toward the agent goals. For its complexity, this level more often concerns humans: however, not-so-complex agents can be adopted to change artifact behaviour according to some schema explicitly pre-defined by the agent designers. To enable such scenarios, proper models, theories and then supporting frameworks and infrastructures are needed, making artifacts first-class entities from design to runtime. 2.4 A Basic Model of Artifacts in MAS By focussing on the essence and purposes of the artifact abstraction in MAS, a basic abstract model has been identified [17], useful in particular to enable its rational exploitation by intelligent agents [18]. According to such a model, an artifact for MAS possibly exposes (i) a usage interface, (ii) operating instructions, and (iii) a function description. On the one hand, this view of artifacts provides us with a powerful key for the interpretation of the properties and features of existing non-agent MAS abstractions, which can be then catalogued and compared based on some common criteria. On the other hand, it is also meant to foster the conceptual grounding for a principled methodology for the engineering of MAS environment, where artifacts play the role of the core abstractions. Usage Interface — One of the core differences between artifacts and agents, as computational entities populating a MAS, lays in the concept of operation, which is the means by which an artifact provides for a service or function. An agent executes an action over an artifact by invoking an artifact operation. Execution possibly terminates with an operation completion, typically representing the outcome of the invocation, which the agent comes to be aware of in terms of perception. The set of operations provided by an artifact defines what is called its usage interface, which (intentionally) resembles interfaces of services, components or objects—in the object-oriented acceptation of the term. In MASs, this interaction schema is peculiar to artifacts, and makes them intrinsically different from agents. While an agent has no interface, acts and senses the environment, encapsulates its control, and brings about its goals proactively


77

and autonomously, an artifact has instead a usage interface, is used by agents (and never the opposite), is driven by their control, and automatises a specific service in a predictable way without the blessing of autonomy. Hence, owning an interface strongly clearly differentiates agents and artifacts, and is therefore to be used by the MAS engineer as a basic discriminative property between them. Operating Instructions — Coupled with a usage interface, an artifact could provide agents with operating instructions. Operating instructions are a description of the procedure an agent has to follow to meaningfully interact with an artifact over time. In other words, they are a description of the possible usage protocols, i.e. sequences of operations that can be invoked on the artifact, in order to exploit its function. Besides a syntactic information, they can embed also some kind of semantic information that rational agents can eventually understand and exploit in their reasoning processes, to enable and promote the cognitive use of the artifact. So artifacts being conceptually similar to devices used by humans, operation instructions play a role similar to a manual, which a human reads to know how to use the device on a step-by-step basis, and depending on the expected outcomes he/she needs to achieve. For instance, a digital camera provides buttons and panels (representing its usage interface), and therefore comes with a manual describing how to use them—e.g. which sequence of buttons are to be pushed to suitably configure the camera resolution. Function Description — Finally, an artifact could be characterised by a function description (or service description). This is a description of the functionality provided by the artifact, which agents can use essentially for artifact selection. In fact, differently from operating instructions, which describes how to exploit an artifact, function description describes what to obtain from an artifact. Clearly, function description is an abstraction over the actual implementation of the artifact: it hides inessential details over the implementation of the service while highlighting key functional (input/output) aspects of it, to be used by agents for artifact selection. For instance, when modelling a sensor wrapper as an artifact, we may easily think of the operations for sensor activation and inspection as described via usage interface and operations instructions, while the information about the sensory function itself being conveyed through function description of the sensor wrapper. Defining a suitable formal description of function description and operating instructions is the first step toward the definition of formal theories about the rational selection and use of artifacts by intelligent agents, impacting on their reasoning (deliberation, planning) activities. First investigations about this aspect—focussing in particular on operating instructions—can be found in [18].

3 Coordination Artifacts Coordination artifacts are artifacts designed to provide some kind of coordination functionalities, and so exhibiting a coordinating behaviour. As a special case of artifacts for MAS, coordination artifacts are of particular interest in the context of agent societies, where they are usually exploited to achieve or maintain a global behaviour

78


which is coherent with the society’s social goal [17,19]. As such, a coordination artifact is an essential abstraction for building social activities, in that it is crucial both for enabling and mediating agent interaction, and for governing the social activities by ruling the space of agent interaction. Examples range from artifacts for concurrency management—such as semaphores, synchronisers, barriers, etc.—, to artifacts for communication management—such as blackboards, event services—, up to artifacts with articulated behaviours, such as workflow engines or auction engines. So, coordination artifacts generalise the common notion of coordination medium as coming from the field of coordination models and languages [20]: simply put, coordination artifacts are the artifacts for MAS encapsulating the activity of MAS coordination. As such, they are the main tool for engineering the space of agent interaction, taking care of issues like concurrency, synchronisation, sharing of resources, and the like. 3.1 Basic Properties of Coordination Artifacts Among the specific properties characterising coordination artifacts as artifacts with specific coordination functionality, we can list the following: Focus on interaction management — Coordination artifacts are specialised in automating coordination activities. For this purpose, they typically adopt a computational model suitable for effective and efficient interaction management, whose semantics can be easily expressed with concurrency frameworks, such as process algebras or Petri nets. Encapsulating coordination — Coordination artifacts encapsulate a coordination service, allowing user agents to abstract from how the service is implemented [21]. As such, a coordination artifact is perceived as an individual entity, but it can be actually distributed on different nodes of the MAS infrastructure, depending on its specific model and implementation. Encapsulation is the key to achieve reuse of coordination. MAS engineers can create and exploit handbooks or catalogues of coordination artifacts, embodying the solutions to general coordination problems in organisations, analogously to an handbook of organisation / coordination processes [22]. Finally, a coordination artifact provides a certain quality of coordination, in particular in terms of the scalability with respect to the dimensions identified by Durfee in [23], which are related to performance, robustness, reliability, and so on. The description of such dimensions is important to identify the range of applicability of the artifact in the engineering of agent societies. Changing coordination activities at run-time — Coordination artifacts are meant to support coordination in open agent systems, characterised by unpredictable events and dynamism. For this purpose, they have to support a specific form of artifact malleability: they should allow their coordinating behaviour to be adapted and changed dynamically. Changes of the coordination activities can in principle be made either (i) by engineers (humans) willing to sustain the MAS behaviour, or (ii) by agents responsible of managing the coordination artifact, with the goal of flexibly facing possible coordination breakdowns or improving the coordination service provided. Observing and controlling the coordination activities — A coordination artifact typically supports different level of artifact inspectability: (i) inspectability of its operating instructions and coordinating behaviour specification, aimed at letting


79

user agents to be aware of how to use it or what coordination service it provides; (ii) inspectability of its dynamic state and coordinating behaviour, aimed at supporting the testing and diagnosing (debugging) stages for the engineers and agents responsible of its management. Controllability is also fundamental for runtime management of a coordination artifact, by making it possible to freeze its working cycle, to trace it supporting step-by-step execution while watching its state, to restart it, and so on. So, from an operational viewpoint, a coordination artifact can be understood as a sort of virtual machine of coordination, executing some form of coordination specification, fully inspectable and controllable by artifact administrators [9]. Summing up, coordination artifacts are conceived to be engineering abstractions used for designing, building and supporting at runtime coordination in agent societies, suitably instrumenting their dynamic working environment. Also, they can be useful to support forms of scientific investigation of collective behaviours, since they encapsulate, enforce and possibly make inspectable and modifiable the(coordination) laws regulating the behaviour of agent societies. As mediating entities, coordination artifacts typically reify and manage agent communication events; accordingly, they can be used to trace and log the overall interaction behaviour of the agent societies exploiting them. Thus, they can also act as kinds of social memory, which can then be inspected for possible scientific analysis about global behaviours. 3.2 Engineering Social Activities with Coordination Artifacts The introduction of coordination artifacts impacts on the methodology adopted for engineering social activities in agent societies. Taking inspiration from Activity Theory, we can identify three different stages characterising any social activities supported by coordination artifact (see Fig. 1): Co-construction — In this stage, society engineers understand and reason about the social objectives of the society, and define a model of the social tasks required to achieve them. This implies understanding the shape of the agent interaction space, by also identifying the dependencies that need to be managed (dependency detection is a fundamental aspect of coordination, according to the theory of coordination [24] and to cognitive theories of agent societies [25]). Co-operation — In this stage, society engineers—and possibly intelligent agents— design and build the coordination artifacts according to the objective identified in the previous stage (co-construction). This implies understanding how to manage the dependencies previously identified, and defining a coordinating behaviour useful for that purpose. A model of coordination artifact must be chosen, according to its ability of embedding and enacting such a coordinating behaviour. Co-ordination — In this stage, coordination artifacts are exploited, supporting the execution of the social activity. Here, the focus is on the efficient execution and automation of the coordination activities. A parallel can be drawn between the three collaborative stages listed above (and depicted in Fig. 1) and the engineering stages as typically found in (agent-oriented) software engineering methodologies, i.e., analysis, design, development and deployment / runtime. Generally speaking, individual and social tasks are identified and described

80


Fig. 1. Levels of a social activities

in the analysis and design stages of such methodologies. Each individual task is typically associated with one specific competence of the system. Each agent in the system is assigned to one or more individual tasks, and assumes full responsibility for their correct and timely completion. From an organisational perspective, this corresponds to assigning each agent a specific role in the organisation. Conversely, social tasks represent the global responsibilities of the agent system. In order to carry out such tasks, several possibly heterogeneous competences usually need to be combined. The design of social tasks leads to the identification of global social laws that have to be respected / enforced by the society of agents, to enable the society itself to function properly and in accordance with the expected global behaviour. Given this picture, it is possible to identify a correspondence between the analysis stage (where individual and social tasks are identified) and the co-construction level, where the social objectives of the activities are shaped. Then, the identification of the social laws required to achieve the social tasks can be seen as a first step in the cooperation level. This level roughly corresponds to the design and development stages of the engineering process: coordination artifacts are the abstractions making it possible to design and develop social tasks. At the co-operation level such artifacts are designed and developed to embody and enact—as governing abstractions provided by the infrastructure—the social laws and norms previously identified. Finally, the deployment and execution stages correspond to the co-ordination level, when the coordination artifacts are instantiated and exploited. The dynamism among the levels, compared here to the engineering stages of a system, promote a new approach to the engineering of MASs that has been called online engineering: coordination artifacts can be analysed, tested, debugged, manipulated, adapted, and re-designed dynamically at runtime—and whole MASs along with them. In order to support online-engineering methodologies, at least two aspects are essential: first, working with abstractions featuring suitable properties such as inspectability, controllability and malleability, which are necessary for their online analysis and synthesis; second, designing and building infrastructures that support services enabling, access and exploitation (co-ordination stage), and tools for their inspection, control, adaptation (co-operation stage).


81

4 Infrastructures as Providers of Coordination Artifacts 4.1 Keeping Abstractions Alive: The Role of Infrastructures As virtual machines of coordination, coordination artifacts are more typically provided at the MAS infrastructure level rather than at the MAS application level. According to that, infrastructures should provide MAS with suitable artifacts, but also with the services for their access and use, effectively supporting the co-operation and co-ordination levels and the reflection / reification transitions (see Fig. 1). Services may range from artifacts creation and discovery to inspection and dynamic forgeability of their state and coordinating behaviour. Given their role of rulers of agent interaction, coordination artifacts can be seen as fundamental abstractions for governing infrastructures [26], i.e. infrastructure providing flexible and robust abstractions to model and shape the agent interaction space, in accordance with the social and normative objectives of systems. As illustrated for instance by the SODA methodology [27], coordination abstractions provided by a MAS infrastructure should represent the runtime embodiment of the same analysis / design abstractions used since the early stages of the MAS engineering process. Keeping abstractions alive along the whole engineering process is in fact essential to support advanced practices like online engineering: there is no viable way to evolve a system online when the design abstractions are no longer in place in the runtime. Here, then, infrastructures play a key role: they should provide MAS engineers with the same coordination artifact abstractions used in the analysis / design phases, as well as the tools to for their off-line / online development, deployment, monitoring and debugging. Infrastructures also represent an effective approach to the general issue of formalisability of complex systems, which may come from either pragmatical or theoretical problems. By their very nature, infrastructures intrinsically encapsulate key portions of systems—often in charge of the critical system behaviour. In the context of MASs, governing infrastructure encapsulate agent interaction and coordination through coordination artifacts. As a result, providing well-specified infrastructures, and in particular formally-defined coordination artifacts, promotes the discovery and proof of critical system properties. Most notably, a system property can be assessed at designtime through the formal definition of some design abstraction. Then, by ensuring compliance of the corresponding run-time abstraction provided by the infrastructure, such a property can be enforced at execution time and be automatically verified for any system based on the infrastructure. 4.2 The TuCSoN Coordination Infrastructure As a concrete example of a model / infrastructure bringing some of the main principles that characterise the coordination artifact framework, here we consider the TuCSoN coordination infrastructure for MASs [28]2 . TuCSoN enables agent interaction and coordination by means of tuple centres, working as a sort of coordination artifacts. Technically, TuCSoN tuple centres are programmable tuple spaces—reactive, 2

The TuCSoN technology can be downloaded at TuCSoN website http:// tucson.sourceforge.net

82


Fig. 2. A logical view of TuCSoN infrastructure

logic-based blackboards that agents associatively access by writing, reading, and consuming logic tuples (ordered collections of heterogeneous information chunks represented as first-order logic atoms) via simple communication operations (out, rd, in, inp, rdp) [9]. While the behaviour of a tuple space in response to communication events is fixed, the behaviour of a tuple centre can be tailored to the application needs by defining a set of specification tuples expressed in the ReSpecT language, which define how a tuple centre should react to incoming / outgoing communication events. So, unlike tuple spaces, tuple centres can be programmed with reactions so as to encapsulate coordination laws directly in the coordination media. From the topology point of view, tuple centres are collected in infrastructure nodes, distributed over the network, organised into articulated domains (see Fig. 2 for a logical view). So, tuple centres can be conceived as general-purpose coordination artifacts, which can be dynamically inspected and forged (programmed, tuned) to entail a specific coordinating behaviour. Generally speaking, tuple centres exhibit the properties that characterise coordination artifacts: they provide different levels of inspectability—both the communication and the coordination state can be inspected at runtime—, different levels of malleability and controllability—both by changing dynamically their coordinating behaviour and by controlling its execution by means of suitable infrastructure tools [29]. Also, we can identify the basic elements that characterise the abstract model of coordination artifacts: the usage interface is composed by the basic coordination primitives plus the primitives to inspect and change tuple centre behaviour. The coordinating behaviour specification is given by the ReSpecT specification. The notion of operating instructions is not directly supported in tuple centres, even if the ReSpecT specification tuples implicitly contain a description of how to exploit the tuple centre in order to obtain the coordinating service. 4.3 Examples of Coordination Artifacts in TuCSoN Coordination artifacts can be considered as units of reuse for engineering cooperative working environments: as agents encapsulate skills and competences concerning the execution of some task, the achievement of some goal or the solution of some problem, coordination artifacts encapsulate strategies, knowledge and experiences for constructing and ruling social activities.


83

In the following we describe some types of coordination artifacts commonly used in the engineering of systems, implemented on top of TuCSoN. The properties of inspectability, controllability and malleability of tuple centres should be considered in the background of all the examples: they are the key to conceive scenarios where the cooperative working environment can be analysed and improved at runtime, by inspecting and adapting the coordinating behaviour of its coordination artifacts. Coordination artifacts for communication. A common form of coordination artifacts is used to provide communication services, enabling the exchange of information among agents in open and dynamic contexts which require a certain level of uncoupling among the participants. In particular, coordination artifacts can be adopted to support communication even if participants do know each other (identity uncoplying), if they are not simultaneously taking part to the interaction (temporal uncoupling), if they do not belong to the same spatial context or they ignore their mutual position (spatial uncoupling).

mailbox msg(X)

msg(1,X)

last_msg_index(3)

SENDER msg(3,Z)

msg(Z)

last_msg(M)

first_msg_index(0)

SENDER

RECEIVER

msg(2,Y) num_messages(3) msg(Y)

SENDER reaction(out(msg(X),...) reaction(inp(last_msg(M),...) ...

reaction(out(msg(M)),( in r(msg(M)), in r(num messages(N)), N1 is N + 1, out r(num messages(N1)), in r(last msg index(I)), I1 is I + 1, out r(last msg index(I1)), out r(msg(I1,M)) )). reaction(inp(last msg(M)),( pre, in r(first msg index(I)), rd r(last msg index(N)), I < N, I1 is I + 1, out r(first msg index(I1)), in r(msg(I1,M)), out r(last msg(M)) )). reaction(inp(last msg(M)),( post, success, in r(num messages(N)),N1 is N - 1,out r(num messages(N1)) )).

Fig. 3. Mailbox tuple centre (Top) and its coordinating behaviour in ReSpecT (Bottom)

84


A mailbox for instance can be adopted as an artifact supporting temporal and spatial uncoupling among multiple senders and typically a single receiver, with some kind of policy – e.g. FIFO – for storing and accessing the messages. Fig. 3 shows a tuple centre – called mailbox – instrumented to provide the services of a mailbox. The usage interface accounts for an operation to insert new messages (by inserting a msg tuple), to retrieve last message (by retrieving the tuple last msg), and to read the number of messages available (by reading the tuple num messages). The tuple centre is programmed so as to realise a FIFO policy for managing messages: the ReSpecT specification defining tuple centre behaviour (shown in Fig. 3) basically indexes the messages as soon as they are inserted in the mailbox, keeping track of the index of the first and last message, and then using it to get last one on request. This policy could be adapted dynamically according to the need, for instance adopting a strategy based on priorities or establishing a maximum number of messages which can be stored in the mailbox. Blackboards are another kind of well-known coordination artifacts, as shared spaces of evolving knowledge where participants insert and access / retrieve information associatively. With respect to the original model developed in the context of DAI [30], here control is distributed and encapsulated within agents, while the blackboard can be programmed to have a reactive behaviour to manipulate knowledge according to social rules shared and acknowledged by the agents. Tuple centres directly map the notion of blackboard: the coordination primitives are meta-predicates to insert, inspect and retrieve knowledge in terms of logic tuples, forming a theory of communication. ReSpecT specification tuples represent the reactive rules which manipulate the theory of communication as a theory of coordination. Coordination artifacts for knowledge mediation. Coordination artifacts can be exploited to entail automated forms of knowledge mediation for managing heterogeneity in open environments. As an example, we consider a tuple centre mediating the interaction between agents providing some services or information, and agents looking for such services or related. As an abstract case, we suppose that an agent A needs to know information pq(X,Y). According to some social knowledge – which is unknown to agent A – the information can be constructed by aggregating knowledge represented by tuple p(X) and q(Y), provided by other agents working as knowledge sources. The tuple centre can be suitably programmed then to act as knowledge mediator, applying the rules to construct the information pq from p and q: reaction(rdp(pq(X,Y)), ( pre, rd_r(p(X)), rd_r(q(Y)), out_r(pq(X,Y)) )). reaction(rdp(pq(X,Y)), ( post, in_r(pq(X,Y)) )).

Whenever a request for reading information pq is executed, the information is constructed dynamically by reading the content of the tuples p and q and inserted as a new pq tuple in the tuple set to satisfy the request. The request fails if the information cannot be constructed, because of the absence of p or q. Coordination artifacts for resource sharing. Resource and task sharing are among the most common coordination problems in distributed and concurent systems. A working environment can be instrumented with coordination artifacts (tuple centres)


85

designed and programmed to provide some form of access policy in task or resource access, embodying mechanisms and synchronisation strategies well-known in concurrent systems, such as semaphores, synchronisation barries, monitors, etc. As a simple example, we consider here a tuple centre used to act as a semaphore. The P operation provided by a semaphore used to request and obtain access to the resource can be realised by means on an in(sem) operation, i.e. retrieving a tuple sem from the tuple centre; dually, the V operation used to manifest the release of the resource can be realised by inserting back the tuple in the tuple set, by means of an out(sem). To obtain the coordinating behaviour of a semaphore it is not necessary to program the tuple centre, since the basic form of synchronisation directly provided by the in and out coordination primitives is sufficient for the purpose. Programming the tuple centre would instead be needed to obtain a more articulated and robust solution, for instance allowing multiple agents to acquire the semaphore simultaneously. Coordination artifacts for workflow management. Workflow management concerns the automated integration and coordination of heterogeneous and independent activities involved in the same global business process. Among the others it includes activity scheduling and synchronisation, information and control flow management, exception management, and so on. Currently, in the context of service-oriented architectures – in particular Web Services – workflow management is also called orchestration [31]. Typically, special purpose languages – XPDL, BPEL are examples – can be used to define the workflow specification; their specification is executed by the workflow engine, the core component of Workflow Management Systems. A workflow engine – also called orchestration engine – can be framed here as a general purpose coordination

scheduler task_result(taskA,X)

AGENT A (in charge of task A) task_todo(taskC, args(X,Y))

AGENT B

task_result(taskB,Y)

(in charge of task B) reaction(out(task_result(taskA,X),( in_r(task_result(taskA,X)), in_r(task_result(taskB,Y)), out_r(task_todo(taskC,args(X,Y))))). reaction(out(task_result(taskB,Y),( in_r(task_result(taskB,Y)), in_r(task_result(taskA,X)), out_r(task_todo(taskC,args(X,Y))))).

Fig. 4. Scheduler tuple centre

AGENT C (in charge of task C)

86


artifact, which is dynamically programmed to enact a coordinating behaviour according to the workflow specification. In the context of MASs, a tuple centre then can be programmed to provide the services from a simple task scheduler up to a full-fledged general purpose workflow engine. As an example, here we consider the realisation of a simple scheduler of three activities – A, B and C – coordinated according a join pattern: task C can only start when both tasks A and B have been completed. Tasks are executed by independent agents, typically unaware of the global workflow and focussed on the achievement of their specific job. The tuple centre scheduler shown in Fig. 4 is an example of a coordination artifact providing such a scheduling service. The operation of the usage interface can be: – in(task todo(+TaskName,-TaskInfo)), for taking in charge the execution of a task. The presence of a tuple task todo manifests the fact that a specific task has to be done, according to current workflow. – out(task result(+TaskName,+TaskResult)), for communicating the result of the execution of a task, signaling its completion. In the example, TaskName can be taskA, taskB or taskC. The operating instructions of this coordination artifact to be followed by agents in charge of task execution would consist first in getting information about task, then in providing the result. Fig. 4 shows also the ReSpecT specification realising the scheduling behaviour: basically, a suitable task todo tuple is automatically generated in the tuple set as soon as the results of the execution of both tasks A and B are available. In [32] the architecture of a workflow management system based on TuCSoN is described, with tuple centres used as general purpose workflow engines.

5 Related Work The coordination artifact framework discussed in this paper has been mostly inspired on the one side directly by Activity Theory studies, and on the other side by the research work developed in the context of coordination models, languages and architectures, developed mainly in the field of concurrent systems [20]. In particular the notion of coordination artifact is strictly related to the programmable coordination medium abstraction defined in [33], on which the tuple centre model is based. According to the frequently adopted meta-model described in [34], a coordination model can be described by identifying the coordinables—the entities participating to coordination activities—, and the coordination media—the entities enabling and managing agent communication according to some coordination laws defining the semantics of the coordination activities. Programmable coordination media extend the basic notion of coordination medium by making its behaviour programmable with some specific language, so as to flexibly specify the coordination rules according to the need. So, programmable coordination media share some properties which characterise coordination artifacts, such as encapsulation of coordination and malleability of the behaviour. Instead, differently from programmable coordination media and coordination media in general, coordination artifacts do not manage necessarily communication among agents, but— more generally—interactions caused by the execution of operations provided by the


87

usage interface. Also, the coordination artifact framework introduces some structural properties—such as operating instructions—which are new with respect to the classic coordination meta-model, and which are indeed important in the context of open agent societies. The design and exploitation of cooperative working environment and related infrastructures for supporting coordination activities are central themes in the context of CSCW [2]. Here, the expressiveness and effectiveness of coordination through mechanisms mediating human interaction have been clearly remarked, and related models, languages and infrastructures have been developed [35,36]. Coordination artifacts feature some of the basic properties of coordinative artifacts defined in such contexts [2]— in particular the properties concerning malleability and linkability—, contextualising and extending them for the MAS context. Operating instructions, for instance, are part of the extension. Finally, the coordination artifact framework can be exploited as an analytical tool for describing existing coordination approaches based on some form of mediated interaction and environment-based coordination. For instance, the environment provided by the pheromone infrastructure in [10] supporting stigmergy coordination can be interpreted as a coordination artifact exploited by ants to coordinate: as such, it provides operations for depositing and sensing pheromones, and the coordinating behaviour is given by the environmental laws ruling the diffusion, aggregation and evaporation of pheromones. Also some coordination and organisation approaches developed in the context of intelligent / cognitive agents can be framed in terms of artifacts. A main example is is given by electronic institutions ([11] is an example), where agent societies live upon an infrastructure (middleware) which governs agent interaction according to the norms established for the specific organisation, representing both organisation and coordination rules. The institution then can be framed as a kind of shared artifact, characterised by an interface with operations that agents use to communicate, and providing a normative function on the overall set of agents.

6 Conclusion and Future Work Along with agents, artifacts constitute the basic building blocks both for MAS analysis and modelling, and for MAS development and actual construction—i.e., real first-class abstractions available to engineers throughout MAS design and development process, down to run-time. Artifacts are objects explicitly designed to provide some function, which guides their use. Typically, artifacts take the form of objects or tools that agents share and use to support their activities, and to achieve their (individual and social) objectives. By adopting a cognitive perspective over systems [37], agents are the entities of a system that are characterised by some goals to be pursued, whereas artifacts are the entities that are not intrinsically characterised by a goal (they are not goal-oriented). Instead, artifacts are characterised by the concept of use, where an agent using an artifact for its own goals implicitly (and temporarily) associates an external goal to the artifact itself. So, agents and artifacts can be assumed as the two fundamental abstractions required to model and shape the structure of MASs: a MAS is made by agents speaking with other agents and using artifacts in order to achieve their goals.

88


Coordination artifacts are a case of particular interest in the context of agent societies, where they are usually exploited to achieve or maintain a global behaviour which is coherent with the society’s social goal [17,19]. As such, a coordination artifact is an essential abstraction for building social activities, in that it is crucial both for enabling and mediating agent interaction, and for governing the social activities by ruling the space of agent interaction. In this paper, we summarised the main lines of the research about coordination artifacts, by trying to provide the reader with a coherent perspective of a number of different views and related results. Many developments still lay before us: to list just some, the full formalisation of the artifact model, the complete definition of an AOSE (agent-oriented software engineering) methodology exploiting the artifact abstraction —first investigations about this point can be found in [38]—, the construction of a well-structured and comprehensive taxonomy working both as a criterion for artifact classification and as a foundation for a well-principled methodology, the precise characterisation of the specific notion and role of coordination artifact, the development of an infrastructure fully exploiting the power of coordination artifacts. Along these lines, we expect MAS models and technologies to progress to a great extent in the next years.

References 1. Weyns, D., Parunak, H.V.D., Michel, F., eds.: Environments for MultiAgent Systems. Volume 3374 of LNAI. Springer-Verlag (2005) 1st International Workshop (E4MAS 2004), New York, NY, USA, 19 July 2004. Revised Selected Papers. 2. Schmidt, K., Simone, C.: Coordination mechanisms: Towards a conceptual foundation of CSCW systems design. International Journal of Computer Supported Cooperative Work (CSCW) 5 (1996) 155–200 3. Kirsh, D.: Distributed cognition, coordination and environment design. In: European conference on Cognitive Science. (1999) 1–11 4. Nardi, B.A., ed.: Context and Consciousness: Activity Theory and Human-Computer Interaction. MIT Press (1996) 5. Ricci, A., Viroli, M., Omicini, A.: Programming MAS with artifacts. In Bordini, R.P., Dastani, M., Dix, J., El Fallah Seghrouchni, A., eds.: 3rd International Workshop “Programming Multi-Agent Systems” (PROMAS 2005), AAMAS 2005, Utrecht, The Netherlands (2005) 163–178 6. Vygotsky, L.S.: Mind and Society. Harvard University Press (1978) 7. Brooks, R.A.: Intelligence without representation. Artificial Intelligence 47 (1991) 139–159 8. Ricci, A., Omicini, A., Denti, E.: Activity Theory as a framework for MAS coordination. In Petta, P., Tolksdorf, R., Zambonelli, F., eds.: Engineering Societies in the Agents World III. Volume 2577 of LNCS. Springer-Verlag (2003) 96–110 3rd International Workshop (ESAW 2002), Madrid, Spain, 16–17 September 2002. Revised Papers. 9. Omicini, A., Denti, E.: From tuple spaces to tuple centres. Science of Computer Programming 41 (2001) 277–294 10. Parunak, H.V.D., Brueckner, S., Sauter, J.: Digital pheromone mechanisms for coordination of unmanned vehicles. In: 1st International Joint Conference on Autonomous Agents and Multiagent Systems AAMAS’02, ACM Press (2002) 449–450 11. Esteva, M., Rosell, B., Rodr´ıguez-Aguilar, J.A., Arcos, J.L.: Ameli: An agent-based middleware for electronic institutions. In Jennings, N.R., Sierra, C., Sonenberg, L., Tambe, M., eds.: 3rd international Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 2004). Volume 1. New York, USA, ACM (2004) 236–243


89

12. Conte, R., Castelfranchi, C., eds.: Cognitive and Social Action. University College London (1995) 13. Gibson, K.R., Ingold, T., eds.: Tools, Language & Cognition in Human Evolution. Cambridge University Press (1993) 14. Hewes, G.W.: A history of speculation on the relation between tools and languages. [13] 20–31 15. Wood, A.B., Horton, T.E., Amant, R.S.: Effective tool use in a habile agent. In Bass, E.J., ed.: 2005 IEEE Systems and Information Engineering Design Symposium (SEADS 2005), Charlottesville, VA, USA, IEEE (2005) 75–81 16. Omicini, A., Ricci, A., Viroli, M.: Agens Faber: Toward a theory of artifacts for MAS. Electronic Notes in Theoretical Computer Sciences (2005) 1st International Workshop “Coordination and Organization” (CoOrg 2005), COORDINATION 2005, Namur, Belgium, 22 April 2005. Proceedings. 17. Omicini, A., Ricci, A., Viroli, M., Castelfranchi, C., Tummolini, L.: Coordination artifacts: Environment-based coordination for intelligent agents. In Jennings, N.R., Sierra, C., Sonenberg, L., Tambe, M., eds.: 3rd international Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 2004). Volume 1. New York, NY, USA, ACM (2004) 286–293 18. Viroli, M., Ricci, A.: Instructions-based semantics of agent mediated interaction. In Jennings, N.R., Sierra, C., Sonenberg, L., Tambe, M., eds.: 3rd International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 2004). Volume 1. New York, USA, ACM (2004) 286–293 19. Ricci, A., Viroli, M., Omicini, A.: Environment-based coordination through coordination artifacts. In Weyns, D., Parunak, H.V.D., Michel, F., eds.: Environments for Multi-Agent Systems. Volume 3374 of LNAI. Springer (2005) 190–214 1st International Workshop (E4MAS 2004), New York, NY, USA, July 2004, Revised Selected Papers. 20. Papadopoulos, G.A., Arbab, F.: Coordination models and languages. Advances in Computers 46 (1998) 329–400 21. Viroli, M., Omicini, A.: Coordination as a service: Ontological and formal foundation. Electronic Notes in Theoretical Computer Science 68 (2003) 457–482 1st International Workshop “Foundations of Coordination Languages and Software Architecture” (FOCLASA 2002), Brno, Czech Republic, 24 August 2002. Proceedings. 22. Malone, T.W., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., Quimby, J., Osborn, C.S., Bernstein, A., Herman, G., Klein, M., O’Donnell, E.: Tools for inventing organizations: Toward a handbook of organizational processes. Management Science 45 (1999) 425–443 23. Durfee, E.H.: Scaling up agent coordination strategies. IEEE Computer 34 (2001) 24. Malone, T., Crowston, K.: The interdisciplinary study of coordination. ACM Computing Surveys 26 (1994) 87–119 25. Conte, R., Castelfranchi, C.: Cognitive and Social Action. University College London (1995) 26. Omicini, A., Ossowski, S.: Objective versus subjective coordination in the engineering of agent systems. In Klusch, M., Bergamaschi, S., Edwards, P., Petta, P., eds.: Intelligent Information Agents: An AgentLink Perspective. Volume 2586 of LNAI: State-of-the-Art Survey. Springer (2003) 179–202 27. Omicini, A.: SODA: Societies and infrastructures in the analysis and design of agent-based systems. In Ciancarini, P., Wooldridge, M.J., eds.: Agent-Oriented Software Engineering. Volume 1957 of LNCS., Springer (2001) 185–193 28. Omicini, A., Zambonelli, F.: Coordination for Internet application development. Autonomous Agents and Multi-Agent Systems 2 (1999) 251–269

90


29. Denti, E., Omicini, A., Ricci, A.: Coordination tools for MAS development and deployment. Applied Artificial Intelligence 16 (2002) 721–752 Special Issue: Engineering Agent Systems – Best of “From Agent Theory to Agent Implementation (AT2AI-3)”. 30. Corkill, D.D.: Blackboard systems. Journal of AI Expert 9 (1991) 40–47 31. Peltz, C.: Web services orchestration and choreography. IEEE Computer 36 (2003) 46–52 32. Ricci, A., Omicini, A., Denti, E.: Virtual enterprises and workflow management as agent coordination issues. International Journal of Cooperative Information Systems 11 (2002) 355–380 Cooperative Information Agents: Best Papers of CIA 2001. 33. Denti, E., Natali, A., Omicini, A.: Programmable coordination media. In Garlan, D., Le Métayer, D., eds.: Coordination Languages and Models – Proceedings of the 2nd International Conference (COORDINATION’97). Volume 1282 of LNCS. Berlin (D), SpringerVerlag (1997) 274–288 34. Ciancarini, P.: Coordination models and languages as software integrators. ACM Computing Surveys 28 (1996) 300–302 35. Cortes, M.: A coordination language for building collaborative applications. International Journal of Computer Supported Cooperative Work (CSCW) 9 (2000) 5–31 36. Agostini, A., De Michelis, G., Grasso, M.A.: Rethinking CSCW systems: The architecture of MILANO. In Hughes, J.A., Prinz, W., Rodden, T., Schmidt, K., eds.: 5th European Conference on Computer Supported Cooperative Work (ECSCW’97), Kluwer Academic Publishers (1997) 33–48 37. Conte, R., Castelfranchi, C.: Cognitive and Social Action. UCL Press Limited, University College London, Gower Street, London, UK (1995) 38. Molesini, A., Omicini, A., Ricci, A., Denti, E.: Zooming multi-agent systems. In: 6th International Workshop on Agent-Oriented Software Engineering (AOSE 2005), AAMAS 2005, Utrecht, The Netherlands (2005)

Analysis and Design of Physical and Social Contexts in Multi-agent Systems Florian Klein and Holger Giese Software Engineering Group, University of Paderborn, Warburger Str. 100, D-33098 Paderborn, Germany [email protected], [email protected]

Abstract. The multi-agent paradigm promises to provide systems with the ability to adapt to changing external contexts. In this paper, we propose an approach for the model-driven design of context-aware multi-agent systems. We provide a classification for differentiating between different aspects of context and present a specification technique for modeling these aspects. We finally discuss the difficult transition from general requirements to implemented solution and propose some techniques.

1 Introduction As embedded systems and the programs running on them become more and more ubiquitous, the multi-agent paradigm is steadily gaining importance as a powerful approach to designing flexible solutions for real-world problems. Multi-agent systems (MAS) shift the primary focus from solving sophisticated, highly structured problems to less structured problems in complex environments, i.e. are oriented towards a more practical kind of intelligence. Interaction between agents and between agents and their surroundings, rather than the agents’ internal processes, is what predominantly drives multi-agent system analysis or design. Hence derives one of the major promises of the multiagent paradigm, the ability to adapt to changing external conditions and interface with a wide variety of agents in open and highly heterogeneous systems. On the flip side, this means that properly handling context – in a nutshell, with whom and in which way to interact – is one of the most important challenges in engineering multi-agent systems facing developers today. Context is often equated with location, especially in the mobile computing field. Consequently, many approaches are concerned with providing location transparency and/or ad hoc interaction with other agents or devices that are physically close to an agent [1]. This is often achieved by means of some sort of middleware providing an abstraction from the physical environment and location-transparent services, e.g., a shared tuple space [2] or some more sophisticated form of synchronized virtual environment

This work was developed in the course of the Special Research Initiative 614 - Self-optimizing Concepts and Structures in Mechanical Engineering - University of Paderborn, and was published on its behalf and funded by the Deutsche Forschungsgemeinschaft. Supported by the International Graduate School of Dynamic Intelligent Systems. A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 91–108, 2006. c Springer-Verlag Berlin Heidelberg 2006

92

F. Klein and H. Giese

[3]. The focus is generally on practical and implementation-level problems, as location as a concept seems fairly straight-forward. However, context in a broader sense is a more complex concept, as it can cover anything that affects the scope, shape and meaning of an agent’s interactions. Schmidt et al. stress that context ’is more than location’ [4] and propose human factors (user, social environment, task) and physical environment (conditions, infrastructure, location) as relevant aspects. We conjecture that dealing with such aspects conceptually, i.e., properly differentiating them and explicitly representing them when modeling a system, is essential for the development of complex embedded multi-agent systems. We therefore propose a meta model that captures various aspects of context and their relationships, which provides us with a unifying framework for analysing and modeling these aspects and exploiting the relationships between them. The elements of this meta model are presented in the following section, drawing on a number of real-world examples for illustration and motivation. A recent survey classifying and comparing approaches to context modeling [5] evaluates them with respect to formality and their ability to deal with distribution, ambiguity, perturbations, and existing environments. The survey identifies the ontologybased and the object-oriented categories as the most suitable. For specifying multiagent systems based on our meta-model, we use a UML-based, i.e. fundamentally object-oriented, notation with proprietary extensions that allows us to model both structural and behavioral aspects. What differentiates our specification technique from other approaches [6,7,8,9] is that all diagrams have operational semantics that allow their interpreted execution and enable code generation, whereas many of the conceptual diagrams used for expressing social dependencies and types of sequence diagrams used for protocol specifications by those approaches require human intervention for interpretation and disambiguation when implementing the specification. Section 3 presents the specification technique in more detail. A fundamental problem when dealing with context is the gap between the specification of desirable properties of a system, which are often expressed from a global, objective perspective, and the specification of agent behavior, which is necessarily connected to the agent’s subjective context. In Section 4, we discuss this transition from analysis (problem domain, requirements) to design (agent specification). We argue how the semantics of our specification facilitate this transition and, being operational, allow us to generate and validate prototypes of (even early) designs. We also present concrete approaches to handling different types of context and strategies for their distributed realization in Section 5. We close with an outlook on future work.

2 Classifying Context Formalizations of the concept of context have long been studied in AI research. [10] compares the two dominant formal theories of context, Propositional Logic of Context [11] and Local Models Semantics [12]. While these provide important insights on the epistemological aspects and theoretical limitations of context, they have gained, as [13] notes, little practical relevance for the design of multi-agent systems. In the vein of [4], various more pragmatic context classification schemas have been proposed (see [14]

Analysis and Design of Physical and Social Contexts in Multi-agent Systems

93

for a survey), often geared towards a specific aspect like human interaction or tied to a particular middleware or implementation technique. We see the added value of our meta model in the ability to pragmatically describe context at various levels in a consistent way, with operational semantics. Our model is characterized by the fundamental distinction between Physical and Conceptual entities. Whereas the former exist in their own right and may be observed by agents, the latter are derived by convention, based on observations. This grounding differentiates our metamodel from others that distinguish between physical/metaphysical contexts, e.g. [15]. Ultimately, we are primarily interested in enabling a layered approach to modeling, the Conceptual Layer being the place to deal with knowledge or social level [16] characterizations. While this is intuitive for embedded systems with physical components, it does not appear to be applicable to software in a meaningful way, as software is, in itself, completely based on conventions. This, however, depends on the selected level of abstraction: from an agent’s perspective, sensors and effectors operate in a direct fashion, and objects, files, messages, or other agents are observable entities in their own right. We believe the distinction to be helpful as it provides a way to define complex social constructs grounded in concrete entities. Our complete model covers many aspects of multi-agent systems, though we restrict our presentation to those parts that are directly relevant for understanding and handling contexts. 2.1 The Physical Layer On the Physical Layer, context is concrete. We differentiate between a general notion, describing the agent’s surroundings, and the specific instance situation facing an agent within those surroundings. Environment. An agent’s Environment is the system inside which it exists, and with which it interacts using its Sensors and Effectors. Setting system boundaries is a somewhat arbitrary modeling decision depending on the desired level of abstraction. The size of the Environment should be minimally sufficient for modeling all of an agent’s interactions and observations. For a software agent, the agent platform it runs on would be a good starting point. An intrinsic feature of Environments is that they are themselves embedded in and usually connected to other Environments. For a mobile information agent migrating to a different agent platform, the respective operating systems and the network infrastructure become relevant Environments, if only in transit. Likewise, when analyzing possible faults in an agent system, the Environment hierarchy should probably be extended to include the hardware it runs on. Even in the physical world, the exact boundaries remain arbitrary - a Mars rover’s most relevant Environment is (part of) the surface of planet Mars, but when communications with ground control are considered, one might want to include large parts of the solar system, if only at a very abstract level of detail. While the environment used to be seen as a kind of passive backdrop for the agents’ behavior, its importance for agent coordination, e.g., through stygmergy or by providing distributed services, is currently gaining attention (cf. [17]). This makes explicitly modeling them essential, even more so if agents are not specific to a particular Environment but expected to migrate between and perform well in different Environments.

94


Even though the requirements regarding environment models are very heterogeneous, we therefore propose three aspects that we consider essential in any description technique for specifying Environments: modeling Entities, Processes and Services. Entities represent the elements of the Environment that agents can perceive and influence. An Agent is thus a special kind of Entity. Entities and their relationships can be modeled by any kind of domain model or ontology description. The first step towards context-awareness on this level is to provide a model that an agent can understand or at least implicitly use. While for embedded systems the outside world can potentially serve as its own model, pure software agents need to be explicitly compatible with the target platform’s concepts or at least be able to map them to corresponding internal representations. E.g. [13] calls attention to this problem and proposes an algorithm that allows agents to acquire knowledge about their environment using fuzzy learning techniques. [18] discusses the transformation of terminological context expressed by formal ontologies. Processes basically describe change not caused by Agents, especially the rules and laws governing the Environment’s behavior. Examples include gravity on Earth or Mars and an agent platform scheduling execution, retrieving an Agent from persistent storage, or crashing. Processes can also be used to model the mechanical behavior of Entities that are no Agents. While these behavioral aspects could be subsumed under the ontology concept, consistently communicating them between heterogeneous agents is notoriously difficult. This leads to Services, which could be seen as a sort of low level abstraction placed on top of Entities and Processes. Services are provided through Processes or Entities (called Facilities) by the Environment. They may include generation (creation / retrieval) of agents, execution (scheduling / resources), life cycle management, discovery (directory services), communication infrastructure (message transport, (virtual) shared spaces), persistence, migration, security (authentication / integrity) and interfaces to other environments. Services are the domain of standards, be it de facto standards like Java or dedicated efforts like the FIPA. While homogenization is a pragmatic approach to this problem, the ultimate goal of ubiquitous, networked agent systems seems to require heterogeneous systems offering standardized service descriptions, e.g. extending techniques already used in conjunction with web services. Artifacts [19,20] could be seen as a generic approach to the conceptual modeling and description of Facilities. For the developer, context-awareness at this level basically comes down to understanding the nature and structure of one’s surroundings and ensuring technical interoperability. Interactional Context. The Agent’s Interactional Context is what is at the heart of ‘context-aware’ behavior. It consists of the Perceptive Context, the set of Entities the Agent can currently sense with its Sensors, and the Effective Context, the set of Entities it can directly affect with its Effectors. The relationship established by the Interactional Context is clearly neither symmetric nor transitive. We do not elaborate on the inverse relationship, i.e. who can sense or affect an Agent, as it is less relevant and difficult to operationalize (while an avatar in a shooter game has a vital interest both in knowing whom it can see and shoot and who can see and shoot it, the latter question is impossible to answer conclusively). The Interactional Context is determined by an Agent’s


95

Sensors and Effectors and the Environment: In a physical setting, the Environment acts on the Sensors’ and Effectors’ effectiveness and thus implicitly sets the context; in a software system, the Interactional Context is explicitly created by publishing information,

providing interfaces and setting permissions. An Agent’s Interactional Context represents a collection of the partitions on an Environment’s Entities for the different Sensors and Effectors. Here, context-awareness corresponds to situation-awareness, i.e. the ability to grasp and reason about specific instance situations, which probably comes closest to the common understanding of ‘context’. The Interactional Context is very important for an agent’s behavioral decisions because, on the one hand, it defines which interactions are at all possible, e.g. which communication partners or resources are available, and, on the other hand, it often suggests which actions might be required. Intelligent behavior in a real world scenario is closely connected to adapting to the current Interactional Context, reacting appropriately or even proactively anticipating it. Using a cooperative adaptive automotive lighting system that achieves optimal illumination while avoiding headlight glare, two oncoming cars enter each others Interactional Context as soon as they come in range of their wireless link. Informing each other of their presence, they can prepare to shade the appropriate area of their adaptive headlights as soon as the other car enters the effective context of the headlights, i.e. its driver could be blinded by the glare. Obviously, being able to focus on ‘local’ interactions can also greatly simplify designing and verifying agent behavior. This is not limited to agents in the physical world: The Interactional Context introduces a generalized concept of locality into a system’s description that is helpful when trying to structure and modularize the design. 2.2 The Conceptual Layer On the Conceptual Layer, we again distinguish a general notion of social structures existing in a system and an agent’s specific membership in these structures. Social Environment. The social environment is primarily concerned with organizational structure [21]. In [22,23], we introduced Communities as a flexible way to describe such structures by means of groups of agents sharing a common set of rules, possibly in a quite informal or ad-hoc fashion. Communities define Roles, prohibit, allow, or require certain behaviors and introduce conventions for interpreting observable behavior. This last aspect, the idea of Norms for deriving Conceptual from Physical entities, is central for dealing with the higher level aspects of MAS. The Conceptual Layer is an abstraction created to structure complex interactions and allow a more intuitive understanding – it is not concerned with the way these concepts are ultimately implemented, nor does the use of social metaphors imply any assumptions with respect to the agents’ cognitive capabilities. We therefore do not model an agent’s beliefs or intentions – which would presume a specific type of implementation – but merely its Professed Intentions (or Beliefs), i.e., what other agents can imply about an agent’s ‘state of mind’ from their observations, based on said Norms. Languages are Norms for interpreting specific observations, i.e. ascribing Professed Intentions to messages. Meaningful communication is thus only possible within the same Community, i.e., between agents sharing the same frame of reference. The types of Communities that exist in an Environment thus limit the possible interactions and exchanges.

96


An Agent’s Social Environment is therefore defined by the composition of Community Types that exist in its current Environment – in fact, we have proposed using Communities as architectural views for modeling non-orthogonal concerns [22]. An Agent moving to an auction platform would e.g. encounter a Community Type specifying the rules of conduct and a single persistent Community containing all trading agents, and a type for ad hoc Communities containing the participants of individual auctions. Once again, a central problem is interoperability: support for the relevant rule sets needs to be designed into the agents, or there needs to be a generic mechanism for communicating a standardized description to agents migrating into the environment. Social Context. Social Context provides a very powerful notion of context, dealing with dynamic social dependencies. It is, first of all, set by the Communities of which an agent is a member, and the Roles it plays in them. Based on the Norms of these Communities, Agents can then enter into a web of relationships with other agents by performing actions that are associated with Professed Intentions. An Agent may send a message or make a change in the Environment that is interpreted as a promise to follow a certain course of action (commissive), a command issued to another agent (directive), a permission to perform a certain action (permissive) or the simple profession that the agent holds a certain fact to be true (assertive). These Professed Intentions can then be used in rules to control the behavior of the Agent itself or other Agents, e.g., that an agent may only use a controlled resource if the controller agent has issued a permission, or that the debtor’s commitment to pay the winning bid in an auction is only fulfilled once the creditor has asserted receipt of the payment. In short, Social Context is about what an agent may expect of others and what others expect of it. The ability to dynamically assume Roles, as proposed by [24], or even dynamically join and quit Communities provides an important abstraction for modeling adaptive agent behavior. It is realized using the same mechanism based on Norms as above, e.g., two agents reaching the same intersection might form a ‘right-of-way’-community, decide who gets to first based on its rules, pass the intersection, and break up the community again. Likewise, an Agent could commit to a Role in reaction to certain perceptions, which would correspond to the concept of situated commitment [25]. The Social Context is thus shaped by observations, which in turn depend on the Interactional Context, i.e. what an Agent can actually sense. However, an Agent’s Social Context is not limited to the confines of its current Interactional Context. As opposed to the Physical Layer, conceptual relationships often are transitive, which allows Agents to leverage their Social Context in order to extend their Interactional Context. For example, robotic vehicles in a warehouse could only possess sensors for accurately detecting their own position, i.e. each position sensor’s Interactional Context only contain the vehicle itself. For locating other vehicles, they rely on the community of agents in the same warehouse. By committing to the execution of a publication pattern that mandates sending continuous updates about the agent’s position over a wireless link, the agents can suddenly ‘sense’ all other members of the community (if only with a certain latency). Nonetheless, one should never forget that Social Context is grounded in and thus dependent on the Physical Layer. In the above example, if the position sensor or the sensor/effector pair implementing the wireless link break, the transportation agent will break its commitment, a contingency that needs to be anticipated and handled by the


97

community. There are therefore two challenges with respect to Social Context: One is analyzing it at runtime and exploiting its potential, an application-specific problem that allows for any amount of creativity on the part of the designer; the other one is properly operationalizing it at the implementation (Physical) level, a more clearly defined problem that can be tackled by suitable design techniques as discussed below.

3 Specifying Context We now present the notation we use for specifying the various types of context described above. We use the control of autonomous (robotic) agents (see Figure 1) cooperatively handling the storing and shipping of goods in a warehouse as our example. Inside warehouses on a pier, cargo is stored on shelves. Forklifts can load Cargo into Shelves and onto Carriers, which move it into and out of the warehouses. Virtual Shipment Manager agents that can move between servers in the warehouses are responsible for accomplishing tasks, which consist of storing or retrieving a certain set of cargo items. Agents within the same warehouse can communicate using a wireless LAN.

Fig. 1. The Agents of the application example and a cargo item

Our notation is based on standard UML 2.0. Note that we employ the UML as a formal specification language with precise semantics: Prominently using story patterns [26], an extended type of UML collaboration diagram that allows specifying pre- and postconditions expressed as instance graphs, the open source UML CASE tool Fujaba1 is able to generate executable programs from graphical specifications. By adding a UML profile introducing the appropriate stereotypes, we strive to provide a precise but accessible description of a multi-agent system’s physical and social structure that is grounded in established modeling techniques from the software engineering domain. Our use of the UML parallels the application of notations that offer themselves for specific modeling purposes by several other approaches (see [6] for a survey), e.g. in the use of class diagrams for ontology modeling, object diagrams to describe system states and state charts for control structures [7], or a component-based model of agent interactions [8]. 3.1 Physical Layer Environment. The key element for the description of the Environment is the Entity model, which we describe using UML class diagrams. This model serves as the 1

www.fujaba.de

98


> LogicalObject

> PhysicalObject

__________________________________________________

- identifier : URI

Carrier

__________________________________________________

- id : String - position : Cell

WLAN > Shelf > Task

> Cargo

1100100100100001101001110111110 111001010101010001101000001101 0101111110111011101011101100110 1110100010100011101101010111101 1101111101011110110011011001001 0000011011000010101111101111010 0011101011101100110111010001010 1101100110101000111010111011001 0101011110111100100100100001101 101100100101111001010101010001 1101111010101001010111111011111

Forklift

ShipmentManager > Warehouse

> Server

> Pier

Fig. 2. Overview of key elements of the environment

foundation for the discussion of further concepts such as events or behaviors. Figure 2 gives an impression of the key elements of the system and their basic properties by means of a partial class diagram containing only selected associations. The pier is logically divided into a grid of discrete cells in order to simplify reasoning about positions.2 Based on this model, the Environment’s Processes can be defined by means of story patterns. Inertial movement of physical objects is implemented as a Process; agents only have Effectors for de- and accelerating. Figure 3 (a) shows a carrier moving from one cell to another. It also illustrates how story patterns specify graph transformations. The transformation rule consists of two instance graphs, the left-hand side (LHS), which is the precondition, and the right-hand side (RHS), which is the postcondition. The LHS is matched against the system’s instance graph at runtime. If an occurrence is identified, it is transformed to correspond to the RHS by creating, modifying and removing the appropriate elements. To achieve a more compact syntax, the LHS and the RHS are collapsed into a single graph: unmarked elements are unaffected by the transformation and are part of both the LHS and RHS. Elements marked with destroy are part of the LHS, but not anymore present in the RHS. Elements marked with create do not exist in the LHS and are created when applying the pattern. 2

Sparse, graph-like UML rules and difference equations provide a limited way of describing a system’s mechanics that is, however, sufficient for many applications. Differential equations and the underlying more complex numerics that are required for more accurate physical modeling can be included, but require specific approaches.

Analysis and Design of Physical and Social Contexts in Multi-agent Systems cr : Carrier

cra: Carrier

inside

> inside > ca : Cell

adjacent

crb : Carrier

inside > cb : Cell

99

inside > cc : Cell

a) A carrier robot moves from a cell to an adjacent cell

b) Two carrier robots collide

Fig. 3. Processes and conditions can be defined by story patterns

The Entity model also allows reasoning about relevant system properties. Instance situations that correspond to hazardous events we would like to preclude, e.g. collisions, can be specified using story patterns without side effects. As each logical cell can only accommodate one carrier at a time, two carriers that occupy the same cell have collided. This is expressed by the diagram in Figure 3 (b). We also need to model the Services offered by the Environment, i.e., the Entities (Facilities) through which they are provided and the Processes describing their functionality. The corresponding classes and story patterns can be reused between systems with similar infrastructure. In our example, the most important service is the wireless network provided through an access point that serves as the corresponding Facility. Besides, there are higher level services that e.g. provide the robots with knowledge about the warehouse layout or mobility to the Shipment Management agents. As the example system is closed and homogeneous, we can use the environment specification to design support for this particular Environment directly into the agents and do not need to provide mechanisms for communicating it at runtime, a problem in its own right. Interactional Context. We also need to describe the agents’ potential interactions with their environment. [27] models contexts by selecting specific subsets of a class structure. We proceed in a similar fashion, but use subsets induced by the agents’ Sensors and Effectors. These agent-specific views on the Entity model are described using the stereotype context. Figure 4 defines how a carrier agent can sense other physical objects by means of sonar if they are in range. The story pattern adds a concrete PhysicalObject to the Carrier’s Perceptive Context. Accessible attributes are marked read. Read marks can be annotated with the accuracy and delay of the measurements and the update frequency the corresponding Sensor provides. For example, agents can get a much more precise reading on their own position than on other agents, using sonar. Similar annotations specify valid ranges and limitations on changes to modifiable attributes made by Effectors. cr : Carrier

has

__________________________________________________

- position : Cell

> crs : Sonar __________________________________

- range : double

> po : PhysicalObject __________________________________________________

|| po.position - cr.position || - position : Cell {read} < crs.range

Fig. 4. Definition of a Sensor’s Perceptive Context

100

F. Klein and H. Giese fkl : Forklift cr : Carrier

has

> fk : Fork

> > located on located on cg : Cargo

> sh : Shelf

Fig. 5. Applying an Effector to Entities in the Effective Context

Story patterns that describe the actual application of an Effector (or Sensor) can than explicitly reference the context relation between the Effector and an Entity, as the Effector is of course restricted to interacting with Entities from its Effective Context. Figure 5 defines how a Forklift moves a Cargo item from a Shelf onto a Carrier using its Fork-Effector. In this case, the (previously specified) context relation implies that Forklift, Carrier, and Cargo are in adjacent cells. 3.2 Conceptual Layer Social Environment. In the Conceptual Layer, we consider the purpose of the system, i.e. transporting tasks, and other functional (e.g. avoiding collisions) and non-functional (e.g. efficiency, reliability, and fault tolerance) requirements. Depending on the nature of the requirements, we use different techniques to specify Community Types dealing with them. Safety-critical aspects like collision avoidance are handled by specialized Community Types expressed using an extended real-time variant of UML 2.0. They are modeled as coordination patterns that enable a scalable compositional technique for the automated verification of safety properties.3 The approach supports modeling complex behaviors through adding layers of refining patterns to a verified design. Aspects that are rather concerned with efficiency, such as the allocation of transportation tasks, are modeled with rules expressed as story patterns to allow for greater flexibility. The Social Environment of the warehousing system prominently features two types of Communities: the safety-critical LocalCoordination Community Type for coordinating robot movements and the Task Execution Community Type for allocating and carrying out tasks. Collision avoidance implemented in the Physical Layer would leave the vehicles without a way of reliably predicting behavior and entirely dependent on what limited information they can obtain from their Interactional Context. Even barring sensor failure, the limited perception of the Agents makes intelligently anticipating and avoiding hazards difficult. By designing a solution in the Conceptual Layer, we can partially overcome these limitations. Using a Community Type that requires the shuttles to commit to the continuous publication of their position and using cooperative and proactive collision avoidance strategies, we enable much more intelligent movement patterns. As the 3

A detailed description of our verification technique and an extensive review of related work concerning the modeling of real-time systems and compositional verification can be found in [28].


101

wireless network’s range is limited to the respective warehouse, one persistent Community exists per warehouse and wireless base station. This is actually a desirable situation, as a centralized solution would not scale well in terms of bandwidth and memory consumption, important factors for embedded systems. The Task Execution Community Type simply specifies rules of conduct for agreeing to take on and completing a task. A temporary Community implementing it is dynamically created whenever a Shipement Manager starts working on a new task. We provide more details in conjunction with the discussion of Social Context. Social Context. The specified Communities and Community Types shape the Social Environment. To compute the actual Social Context, we need to be able to specify rules for membership, assuming roles and professing intentions, each of which are expressed as story patterns in terms of Entities. Each access point is the defining member of a LocalCoordination Community. When a carrier enters the range of the access point, it becomes a member of the corresponding Community (see Figure 6 (a)). Besides the member relation, joining the Community implicitly adds a Commitment to adhere to its Community Type to the agent’s Professed Intentions. ac : LocalCoordination

> cr : Carrier

pub : PublicationPattern

>

ap : WLAN

Publisher cr : Carrier

Distributor

ap : WLAN

Fig. 6. Membership and required behavior in a Community

The Community Type specifies structural invariants in the form of compulsory roles triggered by sets of associated preconditions. In the example, every vehicle agent is required to act as a Publisher in the Publication pattern that ensures that all participants are kept informed about each other’s position. Using the information guaranteed by the Publication pattern as a bootstrap, it is then possible to implement complex routing and collision avoidance schemes by means of additional patterns that make use of the information about vehicle positions guaranteed to be available. The instantiation of the pattern is again triggered by a story pattern describing instance situations at the Entity level, provided in Figure 6 (b). A maximum acceptable delay for the instantiation of the pattern can also be supplied. For the non-critical task allocation, we use rule-based behavioral specifications. In Figure 7, we specify how a Carrier – that is cooperating with a ShipmentManager in order to complete a Task and is therefore member of the corresponding ad-hoc Community – announces its schedule and thus makes an implied commitment to it. The story pattern in the ScheduledTransport Commitment explicitly describes an observable instance situation at the Entity level that the agent will strive to bring about.

102

F. Klein and H. Giese tc : TaskExecution

cr : Carrier

>

>

st : ScheduledTransport ____________________________________________________________

> cg : Cargo

sends

sm : ShipmentManager

receives msg : SchedulingMessage

located on

> dst : Shelf

Fig. 7. An agent commits to the execution of a schedule sta : ScheduledTransport

cr : Carrier

stb : ScheduledTransport

Fig. 8. An agent professing conflicting commitments

In analogy to the hazardous events we specified in the Physical Layer, we can also specify undesirable constellations in the Conceptual Layer using the same techniques. The story pattern in Figure 8 describes a conflict caused by concurrent Commitments to two different schedules.

4 Analysing and Designing Context 4.1 Analysis The layered nature of our approach suggests beginning analysis in the Physical Layer. Especially when designing embedded systems, the hardware already determines much of the Physical Layer, whereas the Conceptual Layer is less constrained and leaves more room for creativity. Thus, (the object-oriented) analysis starts with the Entity model and then moves on to Processes and whichever Services may already be offered by the system. We also identify potential Agents, their Sensors and Effectors. As, in an embedded system, the Agents’ capabilities and Interactional Contexts are already fixed by the laws of physics, modeling these aspects correctly is essential. As the second step of the analysis phase, we turn to modeling system requirements, from a global perspective. Even though we focus on modeling the operational goals and dependencies here, it seems feasible to carry out the initial analysis using a notation incorporating soft goals and dependencies (e.g. [9]). For requirements that need to be formally verified, it is, however, desirable to express them as story patterns in terms of the elements of the analysis model. During analysis, the proposed categories, on the one hand, provide a structured way of looking at the system and, on the other hand, encourage thinking in terms of observable behavior, which will make implementing and especially validating the system later easier. 4.2 Iterative Design In order to decompose and operationalize the requirements, the first design step is to identify Community Types providing separate architectural views and charge each of


103

them with fulfilling specific requirements [22]. Depending on the nature of these requirements, we then specify a solution using the appropriate formalism, as discussed above. As the Community Types break down and structure the requirements, it should often be possible to reuse a solution for a similar problem. In the literature, specific answers for certain types of systems and contexts have been proposed. In the context of social laws [29], much work has been done to identify behavioral restrictions that are both effective and feasible. Law-governed interaction [30] is an approach that is based on designing social laws into the middleware that agents have to use to interact with a system. In this way, the Interactional Context is restricted to socially acceptable actions. Other approaches (e.g. [31]) introduce an authority that penalizes undesired behavior, thereby making social behavior the rational choice. [32] use model checking to verify the effectiveness of social laws. In [33], they tackle the question whether an agent’s knowledge is sufficient to fulfill its commitments by extending their model to include epistemological aspects. As our specification technique builds on existing software engineering techniques, we can apply our existing model checking techniques to a solution. We can formally verify whether the rules of an individual Community Type are sufficient for ensuring certain formal requirements, e.g. safety properties. We have formally verified several examples using this approach, among them an intersection management scheme and control structures for autonomous tracked vehicles. At this stage, it is also possible to generate prototypes from the specification. Simulating the Physical Environment based on the analysis model, we can execute a prototypical implementation of the specification of the Community Types. Using our unrestricted access to the simulated environment, we explicitly keep track of instantiated Communities, compute Interactional Contexts, determine membership in Communities, and assign Professed Intentions to behavior. The agents themselves, which are not specified yet at this time, are emulated by randomly picking from the required or, if no Community currently requires specific behavior, enabled behaviors for the agent. Here, the principle of grounding abstract concepts in implemented, observable entities and observable agent behavior allows us to test our specification at this early stage. Obviously, nondeterministic execution is not sufficient to decide whether an implementation fulfilling the specification exists, but it can already establish that a sufficiently narrow specification, e.g. a set of concrete traffic laws, can guarantee its requirements even for adversarial implementations. We have used this technique on a system containing 60 agents to validate the rules that controlled their movements.

5 Realization A correct realization of an agent needs to commit to all required behavioral invariants and respect all constraints imposed by the agent’s current Social Context. Locally, each Community correctly implements a subset of the system’s requirements, while the structure of the Social Environment should ensure a proper composition. As the Community Type specifications are expressed in terms of observable agent behavior, the transition from the social to the agent level is basically straight-forward. However, as the different aspects do not need to be orthogonal, the rules of different Cultures might be in conflict,

104


depending on the specific Social Context. It is the agents’ responsibility to resolve such conflicts and consistently manage their Social Context. Also, the assumptions about the Agents’ Interactional Context need to hold at the implementation level, i.e. they need to be able to perceive and achieve what the specification requires of them. This may make adding Sensors and Effectors or, preferably, infrastructure (by means of Services) necessary. We will discuss some strategies below. 5.1 Centralized Realization As discussed above, the operational semantics of our model and our specifications facilitate the realization of prototypes. As many aspects of the specification are expressed as story patterns, it is possible to directly implement these aspects by running graph matching algorithms that try to match the specification against the instance graph representing the system state at runtime. In this manner, required behavior or forbidden instance situations can be identified by a generic mechanism. If the Physical Layer is virtual, i.e. simulated, we run an Process for each agent that determines its Interactional Context. Another Process manages Community instantiation and decides membership. Each Community is explicitly represented in the system and monitors its own constraints. The transparency that such an explicit instantiation of the analysis and design model offers is very appealing when designing the agents’ internal structures, as it gives the developer direct insights into the agents’ contexts and reactions. However, a centralized implementation is in contradiction to the very nature of multi-agent systems and may not scale well to large systems. Still, it is an attractive idea is to keep a centralized prototype of the Community Type specifications around while designing a distributed solution on the agent level. Running both versions in parallel – on top of the simulated environment – not only enables the detection of observable behavior that violates the requirements, but also allows the identification of the discrepancies between the actual context and an agent’s perception of it that have caused the violation. This is similar to the debugging support presented in [34], where the agents’ behavior is validated against Petri Net specifications, but additionally factors in an agent’s context and perception of the system. 5.2 Distributed Realization The actual embedded systems force a transition to a distributed realization, as no simulated environment providing a global perspective exists. Generally, an agent can only be expected to react to events that are – directly or through social mediation – within its Interactional Context. A distributed model for realizing the specified interactions will have to take this into account, both with respect to physical and social contexts. Obviously, the idealized assumptions that the agents have direct access to an explicit representation of their physical and social environment and that pattern roles are triggered instantaneously and simultaneously for all involved agents have to be dropped. Below, we suggest strategies for compensating this. Strategies for Context Access. At the most basic level, agents require access to elementary knowledge that allows them to understand their Environment and interact with it. The Environment needs to provide Services to this respect that are established on top


105

of known infrastructure, e.g. look-up services [35] that enable clients to search a network for a specific service. In the example, the instantiation rules for LocalCoordination Communities depend on knowledge about the vehicles current position. Once agents have access to all relevant parts of the physical environment, we need to create an internal representation of the agents’ resulting knowledge about its physical context. By mirroring the Entity model, we obtain an object structure for matching the membership rule of the LocalCoordination Communities. This Explicit Context Model strategy suffers from the overhead required to represent the whole known physical environment as specified by the Entity model. Often, a stripped down model of the agent’s context that uses a simplified structure and represents only elements that are relevant for the agent’s decisions is sufficient. We refer to this strategy as the Specialized Context Model strategy. In our example, many patterns concerning physical location, membership and pattern instantiation can be interpreted using the same reduced context model. As mentioned above, the routing mechanism depends on the publication pattern, which extends the context information available to an agent with the other agents’ position and velocity data. The publication pattern in turn only depends on data that is locally available to an agent and some implied knowledge about the system’s topology. Such bootstrapping allows us to realize instantiation rules for patterns or communities which require additional information which is not directly available in the Interactional Context of the agents. We call extending the physical context model of an agent in this manner the Context Bootstrapping strategy. Strategies for Role Instantiation. To ensure that the local and concurrent instantiation of the pattern roles in each agent works, we have to extend the initialization phase of the pattern. The protocols employed within the patterns have to be able to compensate time differences introduced by delayed instantiation within bounds of the specified time frame (e.g. 0-40 ms for the Publication pattern). Notably in case of bootstrapping via other patterns, this time frame will often be reduced by the time spent gathering all required information. We refer to this step as the Asynchronous Instantiation strategy. Moreover, the pattern behavior must take into account that the instantiation of other pattern roles or opening a communication channel might fail. This is achieved by either the Fail-Safe Role Instantiation or Fail-Operational Role Instantiation strategy. If the Publication pattern fails for any reason, all vehicles in the affected warehouse could be required to simply stop in order to reach a fail-safe state. A fail-operational strategy would be to switch to a different sensor, i.e. sonar (which is used outside the range of the wireless network anyway), and keep working a lower speeds until the pattern is successfully established.

6 Conclusion and Future Work We have presented both a pragmatic classification of different types of context in multiagent systems and techniques for analysis and design using this classification. The operational semantics of our model facilitate the generation of centralized prototypes, which can then be used for validating distributed implementations. Building a framework for the prototyping of large multi-agent systems is currently the objective of a large student project. We have already begun to extensively use

106


and evaluate different techniques for the explicit and distributed handling of context and hope to develop additional realization strategies to compile a more comprehensive catalogue. The small examples we have implemented and verified already suggest that the meta model is indeed of practical value in designing and understanding a system, which we hope to fully evaluate by implementing the above warehouse scenario on a large scale. We also intend to continue working on the questions raised in Section 4. We believe there to be great potential for automated synthesis and formal verification of correct individual implementations of a social level specification.

References 1. Sen, R., Roman, G.C.: Context-sensitive binding - flexible programming using transparent context management. Technical Report WUCSE-03-72, Washington University, Department of Computer Science, St. Louis, Missouri (2005) To appear in the journal Synthese. 2. Julien, C., Payton, J., Roman, G.C.: Adaptive access control in coordination-based mobile agent systems. In Choren, R., Garcia, A., Lucena, C., Romanovsky, A., eds.: Software Engineering for Multi-Agent Systems III. Volume 3390 of Lecture Notes in Computer Science (LNCS)., Springer Verlag (2005) 254–271 3. Schelfthout, K., Holvoet, T.: Objectplaces: An environment for situated multi-agent systems. In: 3rd International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS), New York, NY, USA, ACM Press (2004) 1500–1501 4. Schmidt, A., Beigl, M., Gellersen, H.W.: There is more to context than location. Computers & Graphics 23 (1999) 893–901 5. Linnhoff-Popien, C., Strang, T.: A context modeling survey. In: Workshop on Advanced Context Modelling, Reasoning and Management (UbiComp 2004), Nottingham, England. (2004) 6. Bauer, B., Mller, J.P.: Using uml in the context of agent-oriented software engineering: State of the art. In: Agent-Oriented Software Engineering IV. Volume 2935 of Lecture Notes in Computer Science (LNCS). Springer Verlag (2003) 1–24 7. Kinny, D., Georgeff, M.: Modelling and Design of Multi-Agent Systems. In: Proceedings of Agent Theories, Architectures, and Languages (ATAL) 96. (1996) 8. Bauer, B., Odell, J.: Uml 2.0 and agents: how to build agent-based systems with the new uml standard. Engineering Applications of Artificial Intelligence 18 (2005) 141–157 9. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., Perini, A.: TROPOS: An AgentOriented Software Development Methodology. Journal of Autonomous Agents and Multiagent Systems (2003) 10. Serafini, L., Bouquet, P.: Comparing formal theories of context in AI. AI 155 (2004) 41–67 11. Buvaˇc, S., Buvaˇc, V., Mason, I.: Metamathematics of contexts. Fundamenta Mathematicae 23 (1995) Available from http://www-formal.stanford.edu/buvac. 12. Ghidini, C., Giunchiglia, F.: Local models semantics, or contextual reasoning = locality + compatibility. Artificial Intelligence 127 (2001) 221–259 13. Edmonds, B.: Learning and exploiting context in agents. In: Proceedings of the first international joint conference on Autonomous agents and multiagent systems, ACM Press (2002) 1231–1238 14. Kaenampornpan, M., O’Neill, E.: Modelling context: An activity theory approach. In: Proc. of the Second European Symposium on Ambient Intelligence (EUSAI 2004). Volume 3295 of Lecture Notes in Computer Science (LNCS)., Eindhoven, The Netherlands, November 8-11, 2004, Springer Verlag (2004) 367–375


107

15. Benerecetti, M., Bouquet, P., Bonifacio, M.: Distributed context-aware systems. HumanComputer Interaction 16 (2001) 213–228 16. Jennings, N.R.: On agent-based software engineering. Artificial Intelligence 117 (2000) 277–296 17. Weyns, D., Parunak, H.V.D., Michel, F., Holvoet, T., Ferber, J.: Environments for multiagent systems state-of-the-art and research challenges. In Weyns, D., Parunak, H.V.D., Michel, F., eds.: Environment for multi-agent systems: first international workshop, 2004, New York, NY. Volume 3374 of Lecture Notes in Computer Science. (2004) 1–47 18. Wache, H., Stuckenschmidt, H.: Practical context transformation for information system interoperability. In Akman, V., Bouquet, P., Thomason, R., Young, R., eds.: Modeling and Using Context: CONTEXT 2001, Dundee, UK. Volume 2116 of Lecture Notes in Computer Science (LNCS)., Springer Verlag (2001) 367–380 19. Viroli, M., Omicini, A., Ricci, A.: Engineering MAS Environment with Artifacts. In Weyns, D., Parunak, V., Michel, F., eds.: Proceedings of the Second International Workshop on Environments for MAS at AAMAS 2005, Utrecht, The Netherlands. (2005) 20. Omicini, A., Ricci, A., Viroli, M., Castelfranchi, C., Tummolini, L.: Coordination Artifacts: Environment-based coordination for intelligent agents. In Jennings, N., Sierra, C., Sonenberg, L., Tambe, M., eds.: 3rd International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS), New York, NY, USA, ACM Press (2004) 286–293 21. Ferber, J., Gutknecht, O.: A meta-model for the analysis and design of organizations in multi-agent systems. In: Proceedings of the 3rd International Conference on Multi Agent Systems (ICMAS98), Paris , France. (1998) 128–135 22. Klein, F., Giese, H.: Separation of concerns for mechatronic multi-agent systems through dynamic communities. In Choren, R., Garcia, A., Lucena, C., Romanovsky, A., eds.: Software Engineering for Multi-Agent Systems III. Volume 3390 of Lecture Notes in Computer Science (LNCS). Springer Verlag (2005) 272–289 23. Giese, H., Burmester, S., Klein, F., Schilling, D., Tichy, M.: Multi-Agent System Design for Safety-Critical Self-Optimizing Mechatronic Systems with UML. In: OOPSLA 2003 Second Workshop on Agent-Oriented Methodologies, Anaheim, CA, USA. (2003) 24. Kendall, E.A.: Role models – patterns of agent system analysis and design. BT Technology Journal 17 (1999) 46 – 57 25. Weyns, D., Steegmans, E., Holvoet, T.: Integrating free-flow architectures with role models based on statecharts. In: Software Engineering for Multi-Agent Systems III: Research Issues and Practical Applications. Volume 3390 of Lecture Notes in Computer Science (LNCS)., Springer Verlag (2005) 104–120 26. Fischer, T., Niere, J., Torunski, L., Zündorf, A.: Story Diagrams: A new Graph Rewrite Language based on the Unified Modeling Language. In Engels, G., Rozenberg, G., eds.: Proc. of the 6th International Workshop on Theory and Application of Graph Transformation (TAGT), Paderborn, Germany. LNCS 1764, Springer (1998) 27. Felfernig, A., Jannach, D., Zanker, M.: Contextual diagrams as structuring mechanisms for designing configuration knowledge bases in uml. In Evans, A., Kent, S., Selic, B., eds.: UML’2000 - The Third International Conference on The Unified Modeling Language, York, UK. Volume 1939 of Lecture Notes in Computer Science., Springer Verlag (2000) 240ff 28. Giese, H., Tichy, M., Burmester, S., Schäfer, W., Flake, S.: Towards the compositional verification of real-time uml designs. In: Proc. of the European Software Engineering Conference (ESEC/FSE), Helsinki, Finland, ACM Press (2003) 29. Shoham, Y., Tennenholtz, M.: On the synthesis of useful social laws for artificial agent societies. In: Proceedings of the Tenth National Conference on Artificial Intelligence (AAAI92), San Diego, CA. (1992)

108


30. Minsky, N.H., Ungureanu, V.: Law-governed interaction: a coordination and control mechanism for heterogeneous distributed systems. ACM Transactions on Software Engineering and Methodology (TOSEM) (2000) 31. Boella, G., Torre, L.V.D.: Enforceable Social Laws. In Dignum, F., Dignum, V., Koenig, S., Kraus, S., Singh, M.P., Wooldridge, M., eds.: Proceedings of the Fourth International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS), Utrecht, The Netherlands, ACM Press (2005) 682–689 32. van der Hoek, W., Roberts, M., Wooldridge, M.: Social laws in alternating time: Effectiveness, feasibility, and synthesis. Technical Report Technical Report ULCS-04-017, University of Liverpool (2005) To appear in the journal Synthese. 33. van der Hoek, W., Roberts, M., Wooldridge, M.: Knowledge and Social Laws. In Dignum, F., Dignum, V., Koenig, S., Kraus, S., Singh, M.P., Wooldridge, M., eds.: Proceedings of the Fourth International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS), Utrecht, The Netherlands, ACM Press (2005) 674–681 34. Padgham, L., Winikoff, M., Poutakidis, D.: Adding debugging support to the prometheus methodology. Engineering Applications of Artificial Intelligence 18 (2005) 173–190 35. Waldo, J.: The Jini architecture for network-centric computing. Communications of the ACM 42 (1999) 76–82

Engineering Organization-Based Multiagent Systems Scott A. DeLoach Multiagent and Cooperative Robotics Laboratory, Department of Computing and Information Sciences, Kansas State University, 234 Nichols Hall, Manhattan, Kansas 66506, USA [email protected] http://www.cis.ksu.edu/~sdeloach/

Abstract. In this paper, we examine the Multiagent Systems Engineering (MaSE) methodology and its applicability to developing organization-based multiagent systems, which are especially relevant to context aware systems. We discuss the inherent shortcomings of MaSE and then present our approach to modeling the concepts required for organizations including goals, roles, agents, capabilities, and the assignment of agents to roles. Finally, we extend MaSE to allow it to overcome its inherent shortcomings and capture the organizational concepts defined in our organization metamodel.

1 Introduction Recent trends in multiagent systems are toward the explicit design and use of organizations, which allow heterogeneous agents to work together within well-defined roles to achieve individual and system level goals [8], [19]. When focusing on team goals, organizations allow agents to work together by using individual agents to perform the tasks for which they are best suited. When emphasizing an individual agent’s goals, organizations provide the structure and rules that allow agents to find and carry out collaborative tasks with other, previously unknown agents, to the mutual benefit of each agent. In situations where the nature of the application environment makes teams susceptible to individual failures, these failures can significantly reduce the ability of the team to accomplish its goal. Unfortunately, most multiagent teams are designed to work within a limited set of configurations. Even when the team possesses the ability to accomplish its goal, it may be constrained by its own knowledge of team member’s capabilities. In most multiagent methodologies, the system designer analyzes the possible organizational structure and then designs one organization that will suffice for most anticipated scenarios. Unfortunately, in dynamic applications where the environment as well as the agents may change, a designer can rarely account for, or even consider, all possible situations. To overcome these problems, we are investigating techniques that allow multiagent teams to design their own organization at runtime [7]. In essence, we propose to provide the team with the organizational knowledge and let the team define its own organization based on its current context, goals and team capabilities. In this paper, we present a proposal to extend the Multiagent Systems Engineering (MaSE) methodology toward the analysis and design of multiagent organizations. While A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 109 – 125, 2006. © Springer-Verlag Berlin Heidelberg 2006

110

S.A. DeLoach

MaSE already incorporates many of the required organizational concepts such as goals, roles, laws, and the relations between these entities, it cannot currently be used to completely define a multiagent organization. Most importantly, we must extend MaSE with the notion of capabilities, upon which the definition of roles is based. We also add some specific relationships between these capabilities and existing MaSE concepts. The remainder of this paper is organized as follows. First, we present a review of relevant background research, including a short description of MaSE and its current weaknesses. Next, we give an overview of our metamodel that describes the elements in multiagent organizations. Finally, we discuss our extensions to MaSE that support the development of multiagent organizations and overcome some of its recognized problems.

2 Background A recent advance in agent-oriented software engineering has had a significant impact on multiagent development approaches such as MaSE [6], Gaia [18], and MESSAGE [12]. This advancement concerns the separation of the agents from the system framework, or organization [19]. Agents play roles within an organization; however, they are not the organization. The organization defines the social setting in which the agent must exist. An organization includes a structure as well as rules, which constrain valid agent behavior and interaction within the organization. While these advances are recent, there have been some discussions on how to incorporate them into existing multiagent systems methodologies. For instance, there is a proposal to extend the Gaia to incorporate social laws [19] and organizational concepts [18], while others have proposed implementing the organization as a separate institutional agent [17]. We have even proposed extending MaSE with rules and environmental entities [4], [5]. More recently, new methodologies and approaches have been proposed for building highly adaptive multiagent systems including Adelfe, which follows the AMAS theory [1, 14]. The goal of methods such as Adelfe is to allow designers to build systems that will produce some unknown functionality. This varies from the approach presented here as we are attempting to give the system the ability to adapt while still producing a know function and within certain limitations. 2.1 Multiagent Systems Engineering MaSE was originally designed to develop general-purpose multiagent systems and has been used to design systems ranging from computer virus immune systems to cooperative robotics systems [6], [7]. Each phase is presented below. Analysis Phase. The goal of the MaSE analysis phase is to define a set of roles that can be used to achieve the system level goals. This process is captured in three steps: capturing goals, applying use cases, and refining roles. • Capturing Goals. The first step is to capture the system goals by extracting them from the requirements, which is done by Identifying Goals and Structuring Goals. The purpose of the Identifying Goals is to derive the overall system goal and its

Engineering Organization-Based Multiagent Systems

111

subgoals. This is done by extracting scenarios from the requirements and then identifying scenarios goals. After the goals have been identified, the second step, Structuring Goals, categorizes and structures the goals into a goal tree, which results in a Goal Hierarchy Diagram that represents goals and goal/subgoal relationships. • Applying Use Cases. In this step, goals are translated into use cases, which capture the previously identified scenarios with a detailed description and set of sequence diagrams. These use cases represent desired system behaviors and event sequences. • Refining Roles. Refining Roles organizes roles into a Role Model, which describes the roles in the system and the communications between them. Each role is decomposed into a set of tasks, which are designed to achieve the goals for which the role is responsible. These tasks are documented using finite state automata-base Concurrent Task Diagrams. Concurrent tasks consist of a set of states and transitions that represent internal agent reasoning and communications. Design Phase. The purpose of the design phase is to take roles and tasks and to convert them into a form more amenable to implementation, namely agents and conversations. The MaSE design phase consists of four steps: designing agent classes, developing conversation, assembling agents and deploying the agents. • Construction of Agent Classes. The first step in the design phase identifies agent classes and their conversations and then documents them in Agent Class Diagrams. The Agent Class Diagram that results from this step is similar to object-oriented class diagrams with two differences: (1) agent classes are defined by the roles instead of attributes and methods and (2) relations between agent classes are conversations. • Constructing Conversations. Once the agent classes and the conversations are identified, the detailed conversation design is undertaken. Conversations model communications between two agent classes using a pair of finite state automata similar in form and function to concurrent tasks. Each task usually generates multiple conversations, as they require communication with more than one agent class. • Assembling Agent Classes. Assembling Agent Classes involves defining the agents’ internal architecture. MaSE does not assume any particular agent architecture and allows a wide variety of existing and new architectures to be used. The architecture is defined using components similar to those defined in UML. • Deployment Design. The final design step is to choose the actual configuration of the system, which consists of the number and types of agents in the system and the platforms on which they should be deployed. These decisions are documented in a Deployment Diagram, which is similar to a UML Deployment Diagram. 2.2 MaSE Weaknesses While MaSE provides many advantages for building multiagent systems, it is not perfect. It is based on a strong top-down software engineering mindset, which makes it difficult to use in some application areas. 1. MaSE fails to provide a mechanism for modeling multiagent system interactions with the environment. While we examined this topic in [5], it has never been fully integrated into MaSE.

112

S.A. DeLoach

2. MaSE also tends to produce multiagent systems with a fixed organization. Agents developed in MaSE tend to play a limited number of roles and have a limited ability to change those roles, regardless of their individual capabilities. As discussed above, a multiagent team should be able to design its own organization at runtime. While MaSE already incorporates many of the required organizational concepts such as goals, roles and the relations between these entities, it cannot currently be used to define a true multiagent organization. 3. MaSE also does not allow the integration of sub-teams into a multiagent system. MaSE multiagent systems are assumed to have only a single layer to which all agents belong. Adding the notion of sub-teams would allow the decomposition of multiagent systems and provide for greater levels of abstraction. 4. The MaSE notion of conversations can also be somewhat bothersome, as it tends to decompose the protocols defined in the analysis phase into small, often extremely simple pieces. When the original protocol involves more than two agents, it often results in conversations with only a single message. This makes comprehending how the individual conversations fit together more difficult.

3 Organization Metamodel To allow teams of agents to adapt to their environment by determining their own organization at runtime, we have developed a metamodel that describes the knowledge required to define an organization [7], [11]. Given this knowledge, we hypothesize that multiagent teams will be able to organize (and reorganize) themselves to adapt to their dynamic environments. Organization GA : set(Goal) : set(assigned) oaf() : [0..1]

requires

Capabilities Ontology

subgoal

triggers

Goal conjunctive : Boolean disjunctive : Boolean

precedes

related

Possesses score : [0..1]

coord

Role rcf(Agent) : [0..1]

Achieves score : [0..1]

Agent

Capable score : [0..1]

Potential score : [0..1]

uses

Organizational Agent

constrains

Fig. 1. Artificial Organization Metamodel

Policy


113

From the early days of organization research, organizations have typically been defined as including the concepts of agents who play roles within a structure that defines the relationships between the various roles [2]. We thus begin the foundation for our metamodel by defining what is meant by goals (G), roles (R), and agents (A). We also add four additional entities to our metamodel: capabilities (C), assignments (Φ), policies (P), and an ontology (Σ). Capabilities are central to the process of determining which agents can play which roles and how well they can play them, while policies constrain the assignment of agents to roles thus controlling the allowable states of the organization. The organization ontology supports agent communication and policy definition. A UML-based depiction of our organization metamodel is shown in Fig. 1. 3.1 Goals Every artificial organization is designed with a specific purpose, which defines the overall function, or goal of the organization. Within our metamodel, each organization has a set of goals, G, that it seeks to achieve in support of a single top-level goal go. We define a goal in its normal way as some desired end state. G is derived by decomposing go into a tree of subgoals that describe how go can be achieved. Following the KAOS goal based requirements modeling approach [16], we allow goals to be decomposed into a set of non-cyclic subgoals using either AND-refinement or ORrefinement, which are denoted via conjunctive and disjunctive predicates. Eventually, go is refined into a set of leaf nodes, denoted by GL, that may be achieved in order to achieve go. The active goal set, GA (where GA ⊆ GL), is the set of goals that an organization is trying to achieve at the current time. Goal g1 precedes goal g2 if g1 must be achieved before g2 can be achieved. Essentially, goal precedence allows the organization to work on one part of the goal tree at a time, thus reducing the size of GA. The triggers relation is similar to precedes in that it also restricts goals from being inserted in GA. However, instead of requiring goal achievement, the triggers relation allows new goals to be inserted into GA when a specified event occurs. precedes: G, G → Boolean triggers: GL, G → Boolean All goals are unachieved when the organization is initialized. Therefore, the initial active goal set, GA0, consists of all goals that have no predecessor goals or that do not require a trigger. However, as goals are achieved or events occur triggering new goal instances, GA, changes. Essentially, achieved goals are removed from the active goal set and new goals to be achieved are inserted. New goals must be startable (all their predecessor goals have been achieved) and, if they are triggered, they must have been triggered by an active goal. We denote a sequence of active goal sets GA’ as GA’ = [GA1, GA2, … GAn]. 3.2 Roles Each organization has a set of roles R that it can use to achieve its goals. A role defines an entity that is able to achieve a set of goals within the organization. Each role is responsible for achieving, or helping to achieve or maintain specific system goals.

114

S.A. DeLoach

The achieves function describes how well (in a range of 0 to 1) a particular role achieves a specific goal. achieves: R, GL → 0 .. 1 In order to perform a particular role, agents must have a sufficient set of capabilities (which are simply defined as atomic, named entities in our model). Agents possess capabilities, which may include physical capabilities (sensors or actuators) or computational capabilities (data access, knowledge, algorithmic, etc.), and roles require a certain set of capabilities. The set of capabilities required by a particular role is captured using the requires predicate. requires: R, C → Boolean Many times, instead of requiring agents to inherently posses all the required capabilities for a role, we would like to bestow the required capabilities on agents to allow them to play that role. While this does not generally work well with hardware agents (robots), with software agents, we are often free to download new algorithms, etc. Our approach to capabilities does not deny this type of role bestowal; it just requires care in defining the capabilities types in the model. Thus if an agent has the appropriate physical capabilities (computational power, communication access, etc.) we can download the specific algorithms and/or knowledge necessary to carry out a role. In many of our current multiagent systems, the algorithm is packaged with the role, not in the individual agents themselves. To carry out their responsibilities, roles may have to work with other roles within the organization. We capture the basic notion of two roles being related using a related predicate, which provides a means of identifying the allowable structure of a given organization. 3.3 Agents Our metamodel also includes a set of heterogeneous agents, A, within each organization. For our purposes, agents are computational system instances that inhabit a complex dynamic environment, sense and act autonomously in this environment, and by doing so realize a set of goals. Agents are assigned specific roles in order to achieve organizational goals. The current set of potential assignments of agents to a role is captured by the potential function. The range of the potential function indicates how well an agent can play a role and how well that role can achieve the goal, based on the achieves and capable scores. potential: A, R, GL → 0 .. 1 However, the potential function does not indicate that the actual assignment of agent a to role r to achieve goal g, has been made within the organization. It simply defines a set of possible assignments. To capture the notion of the actual assignments, we define an assignment set, Φ, which consists of agent-role-goal tuples, . If ∈ Φ, then agent a has been assigned by the organization to play role r in order to achieve goal g. As discussed above, however, only agents with the right set of capabilities may be assigned to a specific role. To capture a given agent’s capabilities, we define a possesses function, which returns a value in the range of 0 to 1


115

indicating no (0) capability or excellent (1) capability, which may change with time. Using the capabilities required by a role and capabilities possessed by an agent, we can compute the ability of an agent to play a give role, which we capture in the capable function. Finally, we capture the notion of agents coordinating, to achieve their goals using the coord predicate. possesses: A, C → 0 .. 1 capable: A, R → 0 .. 1 coord: A, A → Boolean Organizational agents (OA) are organizations that function as agents within another organization. Thus, organizational agents possess capabilities, may coordinate with other agents, and may be assigned to play roles. They represent an extension to the traditional Agent-Group-Role (AGR) model developed by Ferber [9] and the meta-model proposed by Odell [13]. Organizational agents allow the definition of a hierarchy of organizations, which provides both flexibility and scalability. 3.4 Capabilities Capabilities are key in determining exactly which agents can be assigned to what roles in the organization. Capabilities are atomic entities used to define the abilities of agents in relation to roles. Capabilities can capture soft abilities such as the ability to access resources, communicate, migrate, or computational algorithms. They also capture hard capabilities such as those of hardware agents such as robots, which include sensors and effectors. 3.5 Policies Organization policies are formally specified rules that describe how an organization may/may not behave in specific situations. In our metamodel, we distinguish between two specific types of policies: assignment policies (PΦ) and behavioral policies (Pbeh). Assignment policies deal with constraints that the assignment set, Φ must satisfy such as “an agent may play one role at a time” or “agents may work on a single goal at a time”. Behavioral policies define how agents should behave in solving the problem at hand. 3.6 Ontology The organization ontology defines the entities within the application domain and their relationships. From these definitions, we extract a set of data types and relationships that allow agents to communicate about application specific information. These domain entities and relationships are also used to help in defining application specific organization policies. We currently use static UML diagrams to define ontological concepts similar to the approach in [3]. 3.7 Organization Example An example of a multiagent team developed using our organization metamodel is shown in Fig. 2. The boxes at the top of the diagram represent goals (A … G), the

116

S.A. DeLoach

circles represent roles (R1 … R5), the pentagons represent capabilities (C1 … C5), and the rounded rectangles are agents (A1 … A4). The arcs on subgoal links denote conjunctive subgoals, whereas undecorated links denote disjunctive subgoals. The arrows between the entities represent the achieves, requires, and possesses functions/relations as defined above. The numbers beside the arrows represent the function value (e.g., possesses(A1,C1) = 0.5). These achieves values are generally assigned at design time and do not change. The possesses values, on the other hand, are computed by the individual agents based on their own internal assessment of their capabilities. We also assume we have assignment policies that (1) we only assign a single agent to each goal and (2) only one of the disjunctive goals F or G can be active at any time.

Fig. 2. Organization Example

Therefore, in this example the top-level goal, A, can be achieved by achieving both subgoals B and C, which can be achieved by achieving D and E in addition to either F or G. The achieves relation shows that either of the roles R1 or R2 can be used to achieve goal D while only role R3 can be used to achieve goal E. However, role R3 can also be used to achieve goal F, which can also be achieved by role R4. The only role capable of achieving goal G is role R5. The aim is for the organization to assign agents that can play the appropriate roles to achieve specific goals. Because of the disjunctive nature of goal C and the ability to use different roles in achieving individual goals, there is some assignment flexibility built into the system. Determining which agents should be assigned specific roles in order to achieve particular goals is based on the capabilities the agents currently possess. For instance,


117

Table 1. Capability Function

A1 A2 A3 A4

R1 0.5 0 0 0

R2 0 0 0 0

R3 0.6 0.7 0 0

R4 0 0 0.6 0.5

R5 0 0 0.6 0

role R1 requires only capability C1 while R3 requires only capability C2. Therefore, since agent A1 possesses both capabilities C1 and C2, it could be assigned to either role R1 or R3 in order to achieve goals D, E, or F. In this example, we thus compute the capable function value for each agent-role pair as shown in Table 1. For simplicities sake, we average the individual capability score required for each role. Combining the capable scores with the achieves score, we can easily compute the organizational capability score, Os, for any set of assignments that might be made. Based on these computations (keeping in mind our assignment policies), we can see that the maximum organizational capability score, and thus the optimal assignments are as follows: potential(A1,R1,D) = 0.25 potential(A2,R3,E) = 0.56 potential(A3,R5,G) = 0.42 Os = 1.23 3.8 Exemplar Implementation Although there is not a single “correct” way to implement our organizational metamodel, we suggest an example to help cement the concepts. Fig. 3 shows the implementation approach used in our current projects. Each agent is composed of two components: an Organizational Reasoning component and an Application Reasoning

Fig. 3. Example Implementation

118

S.A. DeLoach

component. The Organizational Reasoning component is concerned with computing the current assignment set φ based on the active goal set GA and the feedback received from the Application Reasoning component in regards to goal achievement, goal failure, or the occurrence of triggering events. The Application Reasoning component accepts its assignment and carries out the tasks necessary to play its assigned roles in pursuit of its assigned goals. The Organizational Reasoning component interacts with the other agent’s Organizational Reasoning components to ensure system coherence. Exactly how the coordination is carried out can vary. We have implemented a variety of centralized and distributed approaches to this coordination process; the best approach to this coordination process is domain and application specific. Part of the goal of the architecture presented in Fig. 3 is to be able to provide “plug-and-play” Organizational Reasoning components that can be selected based on application criteria.

4 O-MaSE To avoid designing static multiagent systems, we have extended MaSE to allow designers to design a multiagent organization, which provides a structure within which the multiagent system may adapt. This extended version of MaSE is called Organization-based MaSE (O-MaSE). A preliminary proposal for the O-MaSE methodology is described below. In general, many of the diagrams used in O-MaSE are variants of the UML class diagrams and use keywords to denote the difference between goals, roles, capabilities, agent classes, etc. Throughout this section, an Information Flow Monitoring System (IFMS) is used as an example of an organization-based multiagent system. The overall goal of the IFMS is to keep track of the information producers and consumers along with the actual flow of information through a dynamically reconfigurable enterprise information system. The information producers and consumers use a publish/subscribe mechanism that allows consumers to find and subscribe to appropriate information producers. Therefore, the IFMS must keep track of the various information paths between the producers and consumers as well as monitor the actual data flowing along those paths. The IFMS provides data in the form of current paths and information flow statistics to enterprise system operators who monitor the system for problems. 4.1 Requirements Requirements are translated into system level goals, which are documented in the form of an AND/OR goal tree. Fig. 4 shows the goal tree for the IFMS described above. Given goal precedence relations, it is possible to design goal structures that cannot be achieved, thus we would like to provide the assurance that the top-level goal can be achieved. We have replaced the non-specific MaSE goal tree with a tree with specific AND/OR decompositions to match the organization metamodel.


119

Fig. 4. Goal Hierarchy Diagram

The syntax has also changed in the O-MaSE goal model. We use standard UML class notation with the keyword «Goal». Each goal may be parameterized, with parameters annotated as attributes of the goal class. When goals are instantiated, they are given specific values for these attributes. The aggregation notation is used to denote AND refined goals whereas the generalization notation is used to denote OR refined goals. This notation is somewhat intuitive as AND refined goals require a composition of its subgoals to be achieved. Subgoals of an OR refined parent goal can be thought of as alternative ways to achieve the parent goal, or that they can be substituted in place of the parent goal. 4.2 Analysis Analysis begins by creating the Organization Model, which defines the organization’s interactions with external actors. Generally, there is one organization at the top level (denoted by the «Organization» keyword) and that organization becomes responsible for the top goal in the goal tree. Each organization can achieve goals and provide services, which are further refined via activity diagrams (similar to UML activity diagrams, not included in this paper). The designer can also use sequence diagrams for describing use cases at the system level, similar to the original version of MaSE. Each organization may also include sub-organizations to allow for abstraction during the design process. While we allow the use of services in O-MaSE to help define the activities that agents carry out while performing roles, they do not map directly to the organization metamodel as presented earlier. For the purposes of this paper, we only mention them for completeness, but do not elaborate on them, as their use in defining organizations is not required. An example of an Organization Model is shown in Fig. 5, where there are three actors making up the system’s environment: the ClientAPI, the ServerAPI, and the Admin. The arrows connecting the organization to the actors denote protocols that

120

S.A. DeLoach

Fig. 5. Organization Model

Fig. 6. Role Model

define the agent class’s interactions with the environment (these protocols are defined in detail in the high-level design stage). The relations between the organization and the goal and service classes (classes denoted by «Goal» and «Service» keywords) are fixed relation types. An organization provides services while achieving goals. These


121

relations may be shown via explicit relations between organizations and goals; however, the relations may also be embedded in a class as shown in Fig. 6 (where «achieves» relations are shown embedded within roles). Next, the organization model is refined into a role model (Fig. 6) that defines the roles in the organization, the services they provide, and the capabilities required to play them. Each role is designed to achieve specific goals from the Goal Model and provide specific activities refined from top-level services in the Organization Model. Again, the arrows between actors and roles and between two roles indicate protocols that are fully defined later in the design stage. The Role Model may also include capabilities (denoted by the «Capability» keyword), which are attached to the roles that require them by the «requires» keyword.

Fig. 7. Domain Model

At this point, O-MaSE differs from MaSE in that O-MaSE does not require the analyst to create concurrent task diagrams to describe the behavior of each role. This task is more appropriately carried out at the low-level design stage. The use of activities, which are refined via activity diagrams, allow the analyst to specify highlevel behavior without resorting to low-level details required by concurrent task diagrams. Throughout the analysis phase, the analyst should also capture and document the ontology that will be used within the system as part of the Domain Model. We have explored the integration of domain models into MaSE in [4]. The Domain Model allows the analyst to model domain entities, their attributes, and their relationships. Fig. 7 shows a simple example of a domain model using standard UML notation to show the relationships between two types of Clients: Source and Consumer. Sources produce InfoObjects while Consumers consume InfoObjects. 4.3 High-Level Design The first step in the high-level design is for the designer to use the Role Model and service activity diagrams to define the Agent Class Model as shown in Fig. 8. In the Agent Class Model, agents classes and lower-level organizations are defined by the roles played (which determines the goals they can achieve), capabilities possessed (which determines the roles they can play), or services provided. Fig. 8 shows the use of both explicit and embedded relations. The «plays» and «provides» keywords in the agent classes (denoted by the «Agent» keyword) define which roles instances of the agent class can play as well as the services it can provide. The «possesses» relation between agent classes and capabilities (denoted by the «Capability» keyword) indicates the capabilities possessed by instances of that class of agent.

122

S.A. DeLoach

Fig. 8. Agent Class Model sd subscribe : Initiator

: Participant subscribe (EntityType)

alternative

[refused]

refuse

[agreed]

agree inform (EntityList)

loop ()

[new data exists] inform (EntityUpdate) [failed]

failure

cancelled

Fig. 9. Protocol Model


123

One the Agent Class Model is complete, Protocol Models (Fig. 9) are used to define the message-passing protocols between agent classes. These Protocol Models follow the currently proposed AUML protocol diagrams [10], which allow the ability to show alternative and repetitive message structures. Fig. 9 captures a subscription protocol where the initiator wants to subscribe to information published periodically by the participant. After the initial subscribe message, the participant may either refuse or agree. If the participant refuses, the protocol terminates, which is denoted by the X symbol. Assuming the participant agrees, the participant sends an inform message with the current subscription information. The protocol then enters a loop where, typically, the participant sends an inform message with new information. However, the participant may send a failure message or the initiator a cancelled message, both of which end the protocol. 4.4 Low-Level Design In low-level design, we define agent behavior using an Agent State Model, which is based on finite state automata (Fig. 10). The Agent State Model is similar to the Init list = new(List) send(inform(success), clientObserver) [not OK] send(refuse, clientObserver) receive(request(start, client, type), clientObserver) Wait

Check ok =check(client) [OK] send(agree, clientObserver)

[not valid(agent)] send(failure, clientObserver) Create agent = createAgent(ObjectObserver) [valid(agent)] send(create(client, type), agent) [valid(agent)] send(request(shutdown), agent); send(inform(success), clientObserver)

Save list.addAgent(agent)

receive(request(stop, client, type), clientObserver)

Lookup agent = list.find(client, type) [not valid(agent)] send(failure, clientObserver)

Fig. 10. Agent State Model for AgentManager

124

S.A. DeLoach

original MaSE concurrent task diagrams, as it captures internal behavior and message passing between multiple agents. They feature an explicit send and receive actions to denote sending and receiving messages. The remainder of the syntax and semantics is defined in [6].

5 Conclusions In this paper, we have discussed the current version of MaSE and some of its shortcomings. With the extension of MaSE to O-MaSE we have dealt with each of these problems. Specifically, we have provided a mechanism for defining the multiagent systems interactions with the environment by adding external actors and defining the interactions protocols between the system and the actors. Second, we have extended MaSE to capture the organizational concepts identified in our organization metamodel. New concepts include AND/OR refinement of goals, integration of capabilities and the ability to model sub-teams, or sub-organizations. This feature allows designers greater levels of abstractions and directly complements the notion of organizational agents in our organization metamodel. Finally, we took the notion of concurrent tasks out of the analysis phase and integrated concurrent tasks with conversations into Agent State Models in the low-level design phase. We are currently using O-MaSE and our organization metamodel in several projects including an adaptive Battlefield Information System [7], cooperative robotic teams [11] and a system to monitor and control a large-scale information system. We are continuing to evolve O-MaSE to provide a flexible methodology that can be used to develop both traditional and organization-based systems. A long term goal is to provide a tailorable methodology that is fully supported by automated tools. We are currently building a new version of agentTool (aT3) within the Eclipse IDE to support O-MaSE1. Future plans include code generation for various platforms as well as integration with the Bogor model checking tool [15] to provide model validation and performance prediction metrics.

References 1. Bernon, C., Camps, V., Gleizes M.P., Picard G. Engineering Adaptive Multi-Agent Systems: the ADELFE Methodology. In B. Henderson-Sellers and P. Giorgini (Eds.), Agent-Oriented Methodologies. Idea Group Pub, June 2005, pp.172-202. 2. Blau, P.M. & Scott, W.R., Formal Organizations, Chandler, San Francisco, CA, 1962, 194-221. 3. Cranefield, S. & Pruvis, M. UML as an Ontology Modelling Language. Proc of the Workshop on Intelligent Information Integration, 1999. 4. DeLoach, S. A. Modeling Organizational Rules in the Multiagent Systems Engineering Methodology. Proc of the 15th Canadian Conference on Artificial Intelligence. 2002. 5. DeLoach, S. A. Analysis and Design of Multiagent Systems Using Hybrid Coordination Media. Proceedings of Software Engineering in Multiagent Systems (SEMAS 2002). 2002. 1

The current status of O-MaSE and the aT3 project can be found at the Multiagent and Cooperative Robotics Laboratory web site (http://macr.cis.ksu.edu/).


125

6. DeLoach, S. A., Wood, M. F. and Sparkman, C. H., “Multiagent Systems Engineering”. The International Journal of Software Engineering and Knowledge Engineering, 11(3), pp. 231-258, June 2001. 7. DeLoach, S.A., & Matson, E. An Organizational Model for Designing Adaptive Multiagent Systems. The AAAI-04 Workshop on Agent Organizations: Theory and Practice (AOTP 2004). 2004. 8. Dignum, V. A Model for Organizational Interaction: Based on Agents, Founded in Logic. PhD thesis, Utrecht University, 2004. 9. Ferber, J., and Gutknecht, O. A meta-model for the analysis and design of organizations in multi-agent systems. In Proceedings of Third International Conference on MultiAgent Systems (ICMAS'98), pages 128-135, IEEE Computer Society, 1998. 10. Huget, M.P., Bauer, B., Odell, J., Levy, R., Turci, P., Cervenka, R., and Zhu, H. http://www.auml.org/. FIPA Modeling: Interaction Diagrams, Working Draft. 2002. 11. Matson, E., DeLoach, S. Capability in Organization Based Multi-agent Systems, Proceedings of the Intelligent and Computer Systems (IS ’03) Conference, 2003. 12. MESSAGE: Methodology for Engineering Systems of Software Agents. Deliverable 1. Initial Methodology. July 2000. EURESCOM Project P907-GI. 13. Odell, J., Nodine, M., Levy, R. A Metamodel for Agents, Roles, and Groups. AgentOriented Software Engineering V, 5th International Workshop, AOSE 2004. 2004. 14. Picard, G. and Gleizes, M.-P. The ADELFE Methodology – Designing Adaptive Cooperative Multi-Agent Systems. In Bergenti, F. and Gleizes, M-P. and Zambonelli, F., editor, Methodologies and Software Engineering for Agent Systems. Kluwer Publishing, 2004. 15. Robby, Dwyer, M.B., & Hatcliff, J. Bogor: An Extensible and Highly-Modular Model Checking Framework, Proceedings of the Fourth Joint Meeting of the European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2003). 16. van Lamsweerde, A., Darimont, R., Letier, E. Managing conflicts in goal-driven requirements engineering. IEEE Transactions on Software Engineering. 24(11), pp 908-926, 1998. 17. Wagner, G. Agent-Oriented Analysis and Design of Organizational Information Systems. Proceedings of the 4th IEEE International Baltic Workshop on Databases and Information Systems, May 2000. 18. Zambonelli, F., Jennings, N.R., and Wooldridge, M.J. Developing Multiagent Systems: The Gaia Methodology. In AMC Transactions on Software Engineering Methodology 12(3), 317-370, 2003. 19. Zambonelli, F., Jennings, N.R., and Wooldridge, M.J. Organisational Rules as an Abstraction for the Analysis and Design of Multi-Agent Systems. IJSEKE. 11(3) pp. 303-328, June 2001.

Developing and Evaluating a Generic Metamodel for MAS Work Products Ghassan Beydoun1,2, César Gonzalez-Perez1,2, Brian Henderson-Sellers2, and G. Low1 1

School of Information Systems, Technology and Management, University of New South Wales, Sydney, Australia {g.beydoun, g.low}@unsw.edu.au 2 Faculty of Information Technology, University of Technology of Sydney, Sydney, Australia {brian, cesargon}@it.uts.edu.au

Abstract. MAS development requires an appropriate methodology. Rather than seek a single, ideal methodology, we investigate the applicability of method engineering, which focuses on project-specific methodology construction from existing method fragments and provides an appealing approach to organize, appropriately access and effectively harness the software engineering knowledge of MAS methodologies. In this context, we introduce a generic metamodel to serve as a representational infrastructure to unify the work product component of MAS methodologies. The resultant metamodel does not focus on any class of MAS, nor does it impose any restrictions on the format of the system requirements; rather, it is an abstraction of how the work product elements in any MAS are structured and behave both at design time and run-time. Furthermore, in this paper we validate this representational infrastructure by analysing two wellknown existing MAS metamodels. We sketch how they can be seen as subtypes of our generic metamodel, providing early evidence to support the use of our metamodel towards the construction of situated MAS methodologies.

1 Introduction There is an increasing software engineering interest in the use of multi-agent systems (MAS), a new class of distributed parallel software applications, that have already proved effective in the core tasks of automating management of information within businesses (e.g. computer network management applications [23]), building computational models of human societies to study emergent behaviour [14, 17, 34] and building cooperative distributed problem solving [22, 24]. The building blocks of a MAS are intelligent, autonomous and situated software entities: agents. The agent, the concept of agency and the full range of MAS abstractions offer the promise of making software systems easier to embed within our daily lives as suggested in [10]. In order to develop a MAS, some appropriate methodological approach is needed. Indeed, a significant number of such MAS methodologies already exist [20]. Notable examples are Gaia [36], Adelfe [2], Prometheus [28], PASSI [8]. However, since it is generally agreed [7, 18] that no single methodology is sufficient, regardless as to how well thought out it might be, any one of these individual methodologies will, by definition, have limited applicability e.g. to a specific domain or a specific type of software application. A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 126 – 142, 2006. © Springer-Verlag Berlin Heidelberg 2006

Developing and Evaluating a Generic Metamodel for MAS Work Products

127

We argue in this paper that attempting to simply combine existing methodologies into one large, high quality methodology, as suggested in e.g. [1] will prove to be impossible, because the sets of assumptions underlying each methodology are likely to be inconsistent and irreconcilable. We propose instead using method1 engineering [5, 26] to empower software developers to create methodologies from existing (method) fragments (i.e. self-contained components). Method engineering approaches have been successful in object-oriented development due to widely accepted modelling languages and constructs of OO software systems and development processes [19, 21, 30]. For method engineering to be equally successful in the context of MASs, a suitable representation of any potential agent-oriented methodology is required. The goal of such representation is to capture knowledge about methodologies. This includes concepts (plus their properties) related to products of the software development process, as well as concepts and their properties related to the software development process itself. These collections of concepts are often known respectively as product metamodel and process metamodel [30]. In this paper, we present a generic product metamodel2 for any MAS methodology. In this context, “product metamodel” is synonymous with “modelling language specification”. Our generic metamodel comprises the abstract syntax and semantics of such a modelling language. It does not make any assumptions about the kinds of MAS that it describes. It only makes assumptions about what are the essential properties of an agent. Our metamodel is the first to focus on conceptual and ontological underpinnings rather than being constrained for use in a single methodological approach. Moreover, in this paper, we reinforce our case for method engineering in the context of MAS development by validating our generic metamodel against two well known and applied MAS metamodels: TAO [32] and Islander3 [13]. We sketch how our metamodel can generate both of them. This constitutes early evidence that our method engineering proposal for MAS development is plausible. The rest of this paper is organised as follows: In Section 2, we justify our method engineering endeavour and describe our metamodel and its synthesis. In Section 3, we present a comparative analysis of this metamodel and two prominent (although not explicit) metamodels: those of Islander [13] and TAO [32]. We indicate that these two metamodels can be viewed as particular refinements of our metamodel. In Section 4, we conclude with a description of future work.

2 Generic MAS Metamodelling Edmonds et al. [10] rightly point out that we do not currently know all possible features of any MAS. They compare the science of MAS to the science of zoology, where we have a lot to discover about how the internals of a MAS change dynamically, and how this alters the overall behaviour of the system. They use this to formulate a theoretical argument against the possibility of having a one-size-fits-all methodology. In this section, we point to other current limitations in pursuing an 1

Both terms, method and methodology are considered synonymous in this paper. Henceforth, we use the term “metamodel” and “product metamodel” interchangeably. 3 Islander is a specification language. We compare our metamodel to its underlying model. 2

128

G. Beydoun et al.

all-encompassing methodology, advocating the alternative context-dependent method engineering approach. Methodologists often do not make it explicit (for instance, in terms of a metamodel or an ontology) what their assumptions are about the software development process, developers’ behaviour and the intended software products – assumptions that may even be contradictory between pairs of methodologies. Quite the opposite, they mostly remain implicit in the intermediate products, process steps and relationships between constructs of the methodology. Indeed, the methodology may be intended as a set of steps to be followed rigorously. Furthermore, a methodology remains constrained by its inherent process and modelling assumptions as to what kinds of MAS can be developed. For instance, a methodology that assumes agents to be cooperative (for adaptive systems) e.g. Adelfe [2] cannot be readily combined with any methodology that assumes agents to be competitive, as is the case in many market simulation applications [17] or negotiating agents in an e-market [11]. Thus, combining methodologies as they are turns out to be very difficult in the absence of explicit metamodels. In [1], combining metamodels of three methodologies led to a cumbersomely large model with little overlap. This suggests a missing intermediate layer of representation that unifies the different concepts from the three metamodels. Instead of attempting to combine metamodels, we propose factoring out common constructs for any MAS into a unifying metamodel of all methodologies (here just focussing on the work product aspects). Such a metamodel will clearly be more generic than any particular, methodology-specific metamodel. Its creation is presented in the next section. 2.1 Procedure to Create a Generic, Work Product Metamodel for MAS We start with a high level representation of what MASs look like and, from this, represent their generic common features. If strong assumptions are required to develop a MAS feature (e.g. mediation policies between negotiating agents), then such a feature is methodology-specific and therefore its representation is left to the methodology itself. Our metamodel is a consensual picture of what a MAS looks like. It is developed by surveying a range of methodologies as well as systems. We identify common concepts that developers often use and methodologists agree upon. Since our resultant metamodel is intended to be widely applicable, without any constraining prerequisites, it will be able to generate most methodologies (we anticipate). Our metamodel creation starts with what an agent is, and we extend this to how a MAS is distinguished from other software systems. At the system level, we do not make any assumptions about agents beyond their essential properties: autonomy, situatedness and interactivity. Any other non-definitional agent characteristic, visible at the system level, suggests a methodology-specific feature. For instance, adaptivity, sociability and proactivity are non-definitional properties of agents; some agents do not have them. For example, Adelfe’s [2] adaptive system design requires learning agents, hence some concepts in Adelfe’s metamodel are too specific to be included in our generic metamodel. At the same time, in developing our metamodel, we aim to cover as many features of a MAS as possible. We consider a wide range of MASs and we focus on what behavioural characteristics agents exhibit in this varying range. With regard to internal agent design, we ensure that any agent behaviour and internals can be described by our metamodel. Thus, any methodology (e.g. Adelfe which assumes adaptive agents) can be successfully generated using this metamodel.


129

In formulating this new metamodel, we ensure consistency, at the same time aiming to maximise coverage (including as many MAS concepts as possible) and generality (wide acceptance and familiarity to methodologists). To ensure consistency, coverage and generality are occasionally sacrificed. In some cases, coverage and generality are opposing and trade-off decisions are made. To construct our generic metamodel, we first decide on the set of concepts to be used, describing entities in any MAS and the relationships amongst them. Towards this, four initial steps are taken (iteratively): Step 1: We decide on the set of general concepts relevant to any MAS and its model. Some problem-specific concepts are omitted. For example, terms specific to robots (e.g. actuators) or to single-agent systems are not included. Literature from the following areas are all relevant: agent software engineering e.g. [4, 8, 27, 33], AI e.g. [25, 31, 35], distributed AI [9, 14] and cognitive science e.g. [29]. Step 2: We decide on definitions worth considering. Choice of a definition from a particular source depends on how explicit the source is in providing the definition. In addition, wide acceptance of the definition is taken into account. This way, the set of adopted concepts is grounded in what other people in the agent community think. Step 3: We reconcile differences between definitions where possible, giving hybrid definitions. Otherwise, choices are made based on consistency with earlier choices, i.e. where contradictory use of concepts between two or more sources occurs, we opt for the more coherent usage with the rest of the set of chosen concepts. For example, ‘Task’ is defined as set of behaviours by [29], and as ‘behaviour but with the significance of atomic part of the overall agent behaviour’ in [15]. Our suggested definition is “specification of a piece of behaviour that the MAS can perform”. Step 4: We designate chosen concepts into two sets: run-time concepts and designtime concepts. Each set has two scopes: system-related or agent internals related scope. This makes it easier to identify relationships between the chosen concepts according to its set and its scope. The results of our efforts in steps 1 to 4 are shown in Tables 1 and 2. It should be noted that the concept of environment statement is both a design-time and run-time concept. It is a unit of environment description, which is used by system designers. Environment statements may also be used by the agents themselves at run-time. Steps 1 to 4 above do not depend on any single software development methodology. The metamodel is not expected to be large enough to express a method to the same level of detail as the method itself. Rather, this proposed new metamodel, named FAML (FAME4 Agent-oriented Modelling Language) provides a complete set of concepts that describe all models to be included in any methodology, but not necessarily providing all required details for every methodology; some details being left to each individual methodology. The FAML metamodel is expected to be complete as far as describing internal structure of single agents is concerned (according to our three definitional properties of agents). However, not all concepts in the metamodel have to be used by a given 4

FAME is the project name under which FAML has been developed.

130

G. Beydoun et al. Table 1. Design-time concepts and their definitions

Term Action Specification Agent Definition Convention Environment Statement Facet Action Specification Facet Definition Functional Requirement Message Action Specification Message Schema Non-Functional Requirement Ontology Ontology Aggregation Ontology Concept Ontology Relationship Ontology Specialisation Performance Measure Plan Specification Requirement Role System Task

Definition Specification of an action, including any preconditions and postconditions. Specification of the initial state of an agent just after it is created. Rule that specifies an arrangement of events expected to occur in a given environment. A statement about the environment. Specification of a facet action in terms of the facet definition it will change and the new value it will write to the facet. Specification of the structure of a given facet, including its name, data type and access mode. Requirement that provides added value to the users of the system. Specification of a message action in terms of the message schema and parameters to use. Specification of the structure and semantics of a given kind of messages that can occur within the system. Requirement about any limits, constraints or impositions on the system to be built. Structural model of the application domain of a given system. Whole/part relationship between two ontology concepts. Concept included in a given ontology. Relationship between ontology concepts. Supertype/subtype relationship between two or more ontology concepts. Mechanism to measure how successful the system is at any point in time. An organised collection of action specifications. Feature that a system must implement. Specification of a behavioural pattern expected from some agents in a given system. Final product of a software development project. Specification of a piece of behaviour that the system can perform.

methodology. For example, if a given methodology is geared towards a simulation MAS composed of reactive agents, then concepts such Intention and Plan would not be needed. Such an omission for a specific situational method is well supported by the optional (0..1) cardinalities seen in the metamodel diagrams below. In connecting all filtered and synthesized concepts into one coherent metamodel, we omit all relations that are specific to some kinds of agents e.g. we do not include


131

Table 2. Run-time concepts and their definitions Term Action Agent Belief

Definition Fundamental unit of agent behaviour. A highly autonomous, situated, directed and rational entity. An environment statement held by an agent and deemed as true in a certain timeframe. An environment statement held by an agent, which represents a state deemed as good in a certain timeframe.

Desire Environment Environment History Environment Statement Event Facet

The world in which an agent is situated. The sequence of events that have occurred between the environment start-up and the present instant. A statement about the environment.

Occurrence of something that changes the environment history. Scalar property of the environment that is expected by the agents contained in it. Facet Action Action that results in the change of a given facet. Facet Event Event that happens when the value of a facet changes. Goal Ultimate desire. Intention A committed desire. Message Unit of communication between agents, which conforms to a specific message schema. Message Action Action that results in a message being sent. Message Event Event that happens when a message is sent. Obligation Behaviour expected from an agent at some future time. Plan An organised collection of actions.

learning features of adaptive agents. We also ensure that the set of terms is selfcontained, that is, concepts may only depend on each other in this set. We include only relations and concepts that apply to a general kind of agents (autonomous, situated and interactive). Some issues are left to the methodology or the developers, e.g. how plans are generated and discarded, how beliefs are updated and maintained/shared, verification and validation of the system. 2.2 The Proposed Generic Metamodel The FAML metamodel has two layers: design-time and runtime layers. Each layer may have two scopes: a system-related or agent-related scope. We present the metamodel in four different diagrams (Figure 1-4) to clearly group classes into four areas of concern: design-time system-related, runtime system-related (environment), design time agent-internals and run-time agent-internals classes. Figure 1 shows the classes of the metamodel that are directly related to the description of a MAS, i.e. design-time system-related classes. Design-time system-related classes (Figure 1) are concerned with features that can only be perceived by looking at the whole system at design time: • •

Roles, relationships between roles, relationship with message schemata. Tasks, and their relationships with roles.

132

G. Beydoun et al. +Responsible ResponsibleFor

1

*

CanUse

Role

*

+Name

*

+Collaborator 0..1

MessageSchema

0..*

CollaboratesIn

+Name +ParameterSpecs

0..* 1

+Particular

AgentDefinition

Convention

+InitialState

0..*

*

* OntologyConcept

*

0..1

+Common

1 0..*

Task +Parent

+Specification

1

1

1

+Name

1

+Description

+Child

Relates

0..1

*

System

Ontology

0..* 1 DerivedFrom

1

1

1 1

1 FacetDefinition

0..*

+Name +DataType +CanBeSensed +CanBeChanged +InitialValue

Requirement +Description

*

0..* 0..*

OntologyRelationship 0..*

*

FunctionalRequirement PerformanceMeasure

*

*

OntologyAggregation

+Description NonFunctionalRequirement

OntologySpecialisation

*

DerivedFrom *

CanSense CanChange IsIncompatibleWith *

0..* 0..*

* 0..*

Role +Name

0..1

+SuperType +SubType SpecialisesFrom

Fig. 1. System-related design-time classes. [The diamond notation indicates a generic wholepart relationship].

• • •

Agent definitions and relationships with roles. Use of ontologies to define domain application semantics. Environment access points and relationship with roles.

Figure 2 shows the classes related to the environment in which agents “live”, that is, run-time environment-related classes. Run-time environment-related classes are concerned with MAS features that exist only at runtime in the environment: • • • •

Environment history of totally ordered instantaneous events, showing the message log and the events. Events of different kinds. System access points and relationships with events. Relationships amongst agent definitions and the above constructs.

Developing and Evaluating a Generic Metamodel for MAS Work Products 1

1 Environ ment Histo ry 0..* {ordered}

Even t

1

+Timestamp ImplementedBy

Enviro nmen t

* MessageEven t

FacetEven t

+F romAgent +T oAgents +Param eter s

1

+C hangeSource +OldValue +N ew Value

0..*

1

1

0..*

IsOfT ype

A gen t

RefersT o

Messag eSch ema 1

0..* 0..*

F acet

+Nam e +ParameterSpecs

0..*

+Value

1

InitialisedFrom

1 F acet Defin ition +N ame +D ataT ype +C anBeSensed +C anBeChanged +InitialValue

AgentDef in ition 1 InitialisedFrom

1..*

+InitialState

Fig. 2. Run-time, environment-related classes Ag en tD efinit io n +InitialState 1..* PlanSp ecification 0..* 1..*

Actio nSpecification

0..*

+PreC ondition +PostCondition

F acetAct io n Specificatio n +N ewValue

M essageAction Sp ecificatio n +Par ameter s

0..*

0..*

Changes

1

FacetD efinit io n +Nam e +DataType +CanBeSensed +CanBeChanged +InitialValue

SendsMessageOf

1

Messag eSch ema +N am e +ParameterSpecs

Fig. 3. Agen+t-internals design-time classes

System

133

134

G. Beydoun et al.

Figure 3 shows the classes related to the agent internals at design time. These include: • •

Plan specification (if any). Action specification which can be a facet action or a message action specification. How action specification relates to facet definitions and message schemata.

•

Finally, Figure 4 shows the classes related to agent internals at run-time. These classes can only be perceived by considering the internals of agents at run-time: • • • • •

Plans and actions. Relationships between actions, messages and message schemata. Desires and beliefs. Intentions. Relationships between each of the above and the environment.

In the next section, we compare and contrast each of the above classes of our metamodel with the metamodels of two well known MAS descriptors: Islander [12, 13] and TAO [32, 33]. We will argue that all modelling components of TAO and Islander can indeed be seen as particular subtypes refining some classes in FAML. GeneratedF rom

Plan Sp ecification

Enviro nmentStatement +Specific ation

Obligatio n

1

+Specification

* 1

*

Plan

* Belief

*

*

A ctio n

1

1

1

+Sender Agent

F rom 1 FacetA ction

ResultsIn

MessageActio n

Desire 1

+Recipient

*

+IsGoal

*1

1

* *

*

*

*

*

M essage

GeneratedFrom

*

+ Parameters

GeneratedF rom 1

Of

To

MessageActio n Specification +Param eters

In tention *

*

*

IsAnInstance Of Changes

1 +Target

1

FacetA ction Sp ecification +NewValue

+Template

MessageSch ema

1

+Name +ParameterSpecs

F acet +Value

Plays

Ag en t *

Role *

Fig. 4. Agent-internals run-time classes

+Name


135

3 Comparative Study of Our Metamodel Multi Agent Systems modelling languages e.g. [6, 13, 32] allow software analysts to specify the structure and key features of the behaviour of the target system. Metamodels underlying such languages are product metamodels with similar scope to FAML. They do not include process-oriented concepts – in contrast to many AO methodologies, such as Gaia and Tropos, which focus on the process aspects at the expense of any product metamodel. MAS-ML [32] and Islander [11] are MAS modelling languages. In this section, we have chosen the TAO metamodel (underlying MAS-ML) and the metamodel underlying Islander as benchmarks to assess completeness of the FAML metamodel. Both metamodels are well documented and explained in [32, 33] and [12, 13] respectively. In addition, they both have been successfully applied in designing and building actual MASs. We compare the coverage of our generic metamodel with each. In the case of any clear overlap, we assess the rigour of the description in the given metamodel with the FAML metamodel. 3.1 Refinement of Islander from the FAML Metamodel Islander is a specification language targeting a particular class of MASs: electronic institutions. Hence, its underlying metamodel focuses on MASs with a large number of external agents that enter the system with their own plans and desires. Interactions amongst external agents are assumed to be mediated by internal agents that follow institutional policies rather than plans of their own. In other words, internal agents in Islander are reactive. In the case when plans (and internal constructs such as beliefs, learning mechanisms, intentions) are required, programming outside the specification of Islander would be required. Hence, classes related to agent internals in our metamodel are not refined at all in Islander. Using Islander, a MAS is described as a formal specification consisting of three components: a dialogical framework, which describes the set of roles and the format of messages exchanged (i.e. the communication language between agents within the institution); a set of scenes, which describe possible states of different activities taken by groups of agents; and a performative structure, which establishes how different activities (scenes) relate to each other in the broader context of the institution [12, 13]. An example of a high level specification of an e-market MAS, negotiation_space, modelling mediated negotiation between buyers and sellers, looks as follows in Islander: define-institution negotiation_space as dialogic-framework = negotiation_space_df performative-structure = negotiation_scenes norms = ()

At the system level, Islander refines our notions of roles and their relationships, IsIcompatibleWith and SpecialisesFrom (Figure 1), in its dialogical framework. However, it does not have our notion of Facet that specifies what things an agent can change in the environment, nor actions associated with the change. Islander assumes that the only action an agent can execute is sending a message to another agent. It implicitly associates messages with roles, within the intra-scene specification (task specification).

136

G. Beydoun et al.

Islander’s notion of Scene refines our notion of Task. It describes an activity in an e-institution that may involve a number of agents. Islander also refines our hierarchical decomposition of tasks and the associated child-parent relation between tasks (see Figure 1): intra-scene activities are decomposed into scene states. Transition between states is conditioned by messages exchanged and by scene constraints. This detailed refinement is beyond the scope of our metamodel and is an Islander-specific feature i.e. an example of a methodology-specific extension that the method engineer is responsible for. At our level of abstraction, a coarse Islander refinement of our task decomposition would only include identifying scenes and their states, together with all relevant roles. In Islander, some inter- and intra-scene activities are conditioned by institutional norms and constraints. These refine our notion of Convention, which explicitly describes static restrictions on agent behaviour. However, we do not anticipate a high level refinement to distinguish between task-specific constraints and institutional constraints (norms) as Islander does. We again view these as Islander-specific. Given the scope of Islander, specifying electronic institutions, this is not unexpected. Table 3. Islander refinement of FAML

FAML Construct

Corresponding Islander Refinement

Message Roles Task Task hierarchy Convention Ontology (domain structure) Non-functional requirements Obligation Environment History

Message Roles Scene Scene states Norms, Constraints Ontology (messages structures)

Environment Agent definition

Facet Event

#agent per scene, synchronization of agents Obligations (of activities within a scene). Stacks of messages (a stack of messages exists for each scene). Implicit in the collection of interactions available to all agents within the system, and determined by external agents leaving or entering scenes. Implicit in: sub-task allocation to agents, message specification assignment and constraints, and association between messages and roles within scenes. External agents entering or exiting a scene

Using Islander assumptions, the only activities taken by agents are receiving and sending messages. Indeed, the lowest level description of all activities generated within an institution can be expressed as a sequence of messages. The ontology specification in Islander describes the structures of messages exchanged about a domain. This view of ontology is a refinement of our more general view, where an ontology describes domain constructs and their relationships. Islander’s view again highlights


137

its assumptions about what kind of a MAS it models: electronic institutions revolving around controlled communication between agents. Agents do not have the power to change the institution, they only exchange messages. Islander specifies the number of agents in each scene, and the synchronisation of agents as they move between scenes. These are the only instances of non-functional requirements we find in Islander. In our metamodel, we leave all details of nonfunctional requirements to the refining method. Our notion of an explicit Agent Definition is not directly refined in Islander. Instead, Islander focuses on restricting the behaviour of external agents to the sending and receiving of messages applicable to the task and context in which the agent is interacting. The specification in Islander is a description of messages exchanged between agents, and constraints regarding which agent sends which message and when, all according to the role of the agent and their state in the e-Institution. This indirectly defines what agents can do and is a substitute of a refinement of our notion of Agent Definition. That is, Agent Definition is indirectly available through detailed specification of each scene, through allocation of sub-tasks (or scene states) within a scene. Our notion of Convention is also indirectly refined in Islander in dispersed details of the specification of sub-tasks within a scene (a transition between two states in a scene is restricted by conventions and message schemata). Finally, with respect our run-time concepts: Islander refines our notion of Obligation, Islander obligations are generated as a result of activities within a scene. Our notion of Environment is indirectly refined through the collection of interactions available to all agents within the system. In particular, the interactions environment in Islander is determined by external agents that may leave or enter the system at any time. This refines our notion of Facet Event. Our notion of Environment History is refined in Islander through a collection of stacks of messages. One stack of messages exists for each scene (task) being executed by the system. 3.2 Refinement of TAO from the FAML Metamodel TAO (Taming Agents and Objects) [33] is the metamodel underlying an extension to UML, to accommodate agent-oriented development, called MAS-ML (figure 5). The TAO metamodel retains object-oriented design concepts. In the following analysis, we are concerned only with the agent-oriented features of TAO. We analyse TAO metamodel units to show how they refine our metamodel. We choose TAO since it is another product metamodel. It focuses on structural aspects of MASs [33]. TAO’s refinement of our Functional Requirement centres on the notion of Organisation. Every TAO organisation is tightly coupled with an owner agent which has an ownership relation with the organisation (see Figure 5). Large goals are decomposed and allocated to agent roles controlled by the owner agent. Thus the notion of organisation is a container of refinements of our three notions of Task, Role and Agent Definition. These three notions are respectively refined within TAO organisations as follows: Responsibility, Role and its Owning Agent. TAO refines hierarchical relations between tasks as hierarchical relations between organisations. This, in turn, introduces hierarchical associations between roles. This is a TAO-specific refinement that is a direct consequence of the tight coupling of tasks, roles and agent definitions.

138

G. Beydoun et al.

5

Fig. 5. TAO metamodel showing MAS-ML abstractions and relationships

TAO’s notion of Organisation is more specific than Task Analysis, in that it assumes that organizing agents into cooperative and hierarchical groups is inherent to any MAS. Whilst cooperation between agents is a very useful and a common assumption, it is not a generic and inherent feature of all MASs. For example, it renders TAO impractical to competitive agents in many market simulation MASs. To maintain genericity of our metamodel, we do not assume that agent grouping is a methodologydependent feature. It is unclear to us whether or not identifying agent groups in the early stages of system analysis would assist in moving to the next architectural phase more effectively For every modelled system in TAO, there is a Main Organisation. This is an instance of our System construct (Figure 1). TAO bridges modelling the internals of agents to the functional requirements through the definition of the owner agent coupled with each organisation, which includes beliefs and plans that can be used to allocate roles and to control the entities involved in the goal of the organisation (Task). The owner agent may allocate some of these to agents that assume roles that are part of the organisation. Organisations have axioms that must be followed. This refines our notion of Convention. TAO has three notions to specify agent behaviour: Rights, Duties and Protocols. These respectively refine the following three notions from our metamodel: Action, Obligation and Message Schema. TAO’s protocols distinguish between sent and received messages for each role. TAO does not represent how plans are generated or dumped (this is left to the developers). TAO’s Environment notion refines the FAML Environment construct. It provides the habitat for executing agents. However, TAO is not explicit in making a distinction between messages exchanged between agents and agents changing certain features of 5

http://www.les.inf.puc-rio.br/mastools/masml_masmltool.html


139

the environment. This seems to be taken care of by the object-oriented features of the environment (in TAO, objects as well as agents may inhabit an environment (see Figure 5)). For instance, in the example of the online bookstore [32], objects are used to describe books being bought and sold (and the trading environment is changed consequently).

4 Discussion, Summary and Future Work We have argued that it is possible to refine our metamodel to obtain both the metamodel underlying Islander and TAO. To strengthen our argument, in this section, we compare the two refinements of our metamodel. We highlight key features of each of TAO and Islander and sketch possible extensions to both; then we conclude with an overview of future work. 4.1 Discussion on Our Comparative Study Our metamodel is explicit in some notions, whereas both Islander and TAO are implicit. Examples are Facet, Facet Event and Convention. Both emphasise task analysis and allocation of sub-tasks to agent roles. Islander does this with Scenes. TAO uses Organisations to represent the allocation of a task to a group of agents. TAO Organisation internals make it explicit which agent roles are responsible for which sub-tasks. This is dispersed in Islander’s state description of scenes. TAO is more comprehensive (in coverage) than Islander’s metamodel. Hence, there are more concepts of our metamodel that are not refined in Islander in comparison with those not refined in TAO. Particularly, this is the case for specifying internals of planning agents. Islander-specific features include a detailed modelling framework for specifying tasks. They are called scenes, decomposed into states, with transition between these states being conditioned by agent messages. Islander is richer than TAO in runtime concepts: it specifies synchronisation requirements between scenes and it also refines our Environment History. Neither feature exists in TAO. The later version of TAO [33] includes new dynamic features but Environment History is not one of them. Changing the structure of the system dynamically, that is system evolution, is not explicitly accommodated in our metamodel, neither for TAO nor Islander. However, we see the importance of this for future systems. Towards this, our current metamodel would entail new (dynamic) relationships amongst roles and between roles, as well as dynamic constructs such as Environment History. A way to evolve roles, involving monitoring message flows and using the Environment History, is described in [3]. Both TAO and Islander need enhancing to accommodate such an evolutionary MAS. In TAO, monitoring of messages and corresponding roles is easier because it has centralized associations between messages and roles. However, TAO needs the addition of Environment History, which Islander already possesses. Islander could benefit from a centralized association between roles and message schemata. TAO can use conditional boundaries of the organisation to implement evolutionary changes, combined with loosened authority of the organisation over roles of their agents. Islander could also include an ontology revision mechanism for its message specification.

140

G. Beydoun et al.

4.2 Summary and Future Work In this paper, we have provided a first step towards context-dependent method engineering for MAS development: a process-independent metamodel for an agentoriented modelling language to describe software components of any MAS. It captures problem-independent concepts and attributes involved in MAS requirement description and system design at various levels of details. The focus on the capturing of MAS features led us to a generic metamodel that is methodology independent. At the system level it can capture any problem independent concept, to a high level of abstraction. At the same time, our generic FAML metamodel is highly useable. It describes detailed product knowledge at the agent level and is enriched with constructs to represent the behaviour of agents within any MAS. It can represent properties of any type of agent. This paper provides, as well, preliminary evidence for the expressive power of our language constructed as a formalised synthesis of the implicit modelling approaches found in a number of existing agent-oriented methodologies. We have shown how the FAML metamodel can be refined to express metamodels underlying known MAS descriptors: MAS-ML (representing TAO) and Islander. The current work shown in this paper does not, however, totally validate our metamodel for its use towards MAS method engineering. Towards this, we plan to validate it against underlying metamodels of a number of other prominent methodologies, including Gaia [36] and Tropos [16]. We also plan to further identify and exemplify its individual elements in the analysis of an actual P2P retrieval MAS application. Beyond the metamodel validation, the next step of our work is to create a complementary generic process metamodel and to situate the presented agent-oriented modelling language within a full method engineering framework. The FAML modelling language will be stored in a repository as a collection of method fragments, which will be subsequently linked to other method fragments describing potential activities, tasks, techniques (i.e. process aspects), teams and roles (i.e. people aspects). Thus, a complete methodological framework will be provided, able to support the generation of complete, custom-made agent-oriented methodologies using the tenets of method engineering.

Acknowledgement This is contribution number 05/12 of the Centre for Object Technology Applications and Research. The work is supported by the Australian Research Council under Discovery grant number: DP0451213.

References 1. C. Bernon, M. Cossentino, M. Gleizes, P. Turci and F. Zambonelli: A Study of some Multi-Agent Meta-Models, in AOSE04. 2004. New York. 2. C. Bernon, M.-P. Gleizes, S. Peyruqueou and G. Picard: ADELFE, a Methodology for Adaptive Multi-Agent Systems Engineering, in Engineering Societies in the Agents World. 2002. Spain.


141

3. G. Beydoun, J. Debenham and A. Hoffmann: Using Messaging Structure to Evolve Agents Roles, in Intelligent Agents and Multi-Agent Systems VII, M. Barley and N. Kasabov, Editors. 2005, Springer: Australia. p. 18-30. 4. P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia and J. Mylopoulos: A Knowledge Level Software Engineering Methodology for Agent Oriented Programming, in Agents2001. 2001. Montreal: ACM. 5. S. Brinkkemper: Method Engineering: Engineering of Information Systems Development Methods and Tools. Information and Software Technology, 1996. 38(4): p. 275-280. 6. R. Choren and C. Lucena: Modeling multi-agent systems with ANote. Software and Systems Modelling, 2005. 4: p. 199-208, doi 10.1007/s10271-004-0065-y. 7. A. Cockburn: Selecting a project's methodology. IEEE Software, 2000. 17(4): p. 64-71. 8. M. Cossentino and C. Potts: A CASE tool supported methodology for the design of multi-agent systems, in International Conference on Software Engineering Research and Practice (SERP'02). 2002. Las Vegas (NV), USA. 9. E. Durfee and V. Lesser: Negotiating task decomposition and allocation using partial global planning., in Distributed Artificial Intelligence, L. Gasser and M. Huhns, Editors. 1989, Morgan Kaufmann: San Francisco. p. 229-244. 10. B. Edmonds and J. Bryson: The Insufficiency of Formal Design Methods - the necessity of an experimental approach, in AAMAS04. 2004. New York: ACM. 11. M. Esteva: Electronic Institutions: From Specification To Development, in AI Research Insitute. 2003, UAB - Universitat Autonòma de Barcelona: Barcelona. 12. M. Esteva: Electronic Institutions: From Specification To Development (PhD thesis), in AI Research Insitute. 2003, UAB - Universitat Autonòma de Barcelona. 13. M. Esteva, D.d.l. Cruz and C. Sierra: ISLANDER: an electronic institutions editor, in International Conference on Autonomous Agents & Multiagent Systems (AAMAS02). 2002. Italy: ACM. 14. J. Ferber and A. Drogoul: Using Reactive Multi-Agent Systems in Simulation and Problem Solving, in Distributed AI: Theory and Praxis, L. Avouris, Editor. 1992, Kluwer: Brussels. 15. FIPA: Methodology Glossary - FIPAMG. 2003. 16. F. Giunchiglia, J. Mylopoulos and A. Perini: The Tropos Software Development Methodology: Processes, Models and Diagrams, in Agent-Oriented Software Engineering III: Third International Workshop, AOSE 2002, F. Giunchiglia, J. Odell, and G. Weiß, Editors. 2003, Springer. p. 162-173. 17. Z. Guessoum, L. Rejeb and R. Durand: Using Adaptive Multi-Agent Systems to Simulate Economic Models, in AAMAS04. 2004. New York: ACM. 18. B. Henderson-Sellers: Method engineering for OO systems development. Comm. ACM, 2003. 46(10): p. 73-78. 19. B. Henderson-Sellers, J. Bohling and T. Rout: Creating the OOSPICE Model Architecture - a Case of Reuse. Software Process Improvement and Practice, 2004. 8(1): p. 41-49. 20. B. Henderson-Sellers and P. Giorgini, eds.: Agent-Oriented Methodologies. 2005, Idea Group: Hershey, USA. 21. B. Henderson-Sellers, A. Simons and H. Younessi: The OPEN Toolbox of Techniques. The OPEN Series. 1998, Harlow (Essex), UK: Addison-Wesley Longman. 22. T. Hogg and C. Williams: Solving the Really Hard Problems with Cooperative Search, in 11th National Conference on Artificial Intelligence. 1993. Washington, DC, USA: MIT Press. 23. E. Horlait: Mobile Agents for Telecommunication Applications (Innovative Technology Series: Information Systems and Networks). 2004, Portland: Kogan Page.

142

G. Beydoun et al.

24. L. Hunsberger and B.J. Grosz: A combinatorial auction for collaborative planning, in 4th International Conference on Multi-Agent Systems (ICMAS-00). 2000. 25. G.F. Luger: AI: Structures and Strategies for Complex Problem Solving. 2002: Addison Wesley. 26. J. Martin and J. Odell: Object-Oriented Methods: A Foundation. 1995, Englewood Cliffs, NJ: Prentice-Hall. 27. J. Odell, M. Nodine and R. Levy: A Metamodel for Agents, Roles, and Groups, in AOSE 2004, J. Odell and e. al., Editors. 2005, Springer: Berlin. p. 78-92. 28. L. Padgham and M. Winikoff: Developing Intelligent Agent Systems. A Practical Guide. Vol. 1. 2004, Chichester: J. Wiley & Sons. 225. 29. R. Pfeifer and C. Sheier: Understanding Intelligence. 2001: MIT Press. 30. J. Ralyté and C. Rolland: An Assembly Process Model for Method Engineering, in 13th Conference on Advanced Information Systems Engineering (CAiSE). 2001. Berlin: Springer. 31. S. Russell and P. Norvig: Artificial Intelligence, A modern Approach, the intelligent agent book. 2003: Prentice Hall. 32. V. Silva, R. Choren and C. Lucena: Using the MAS-ML to Model a Multi-Agent System, in Software Engineering for Multi-Agent Systems (SELMAS2003). 2003. Springer. 33. V. Silva and C. Lucena: From a Conceptual Framework for Agents and Objects to a Multi-Agent System Modeling Language. Autonomous Agents and Multi-Agent Systems, 2004. 8: p. 1-45. 34. G. Tidhar, C. Heinze, S. Goss, G. Murray, D. Appla and I. Lloyd: Using Intelligent Agents in Military Simulation or " Using Agents Intelligently", in 11th Conference on Innovative Applications of AI.. 1999. Orlando,Florida: MIT Press. 35. M. Wooldridge: Reasoning About Rational Agents. 2000: MIT Press. 36. M. Wooldridge, N.R. Jennings and D. Kinny: The Gaia Methodology for Agent-Oriented Analysis and Design, in Autonomous Agents and Multi-Agent Systems. 2000. The Netherlands: Kluwer Academic Publishers.

Agent Roles, Qua Individuals and the Counting Problem Giancarlo Guizzardi Laboratory for Applied Ontology (ISTC-CNR), Trento, Italy [email protected]

Abstract. Despite the relevance of the concept of role for conceptual modeling and agent-orientation, there is still in the literature a lack of consensus on the meaning of this notion and how it should be incorporated in existing conceptual modeling languages and frameworks. In this paper, we offer a contribution to this problem by employing a well-founded reference ontology (UFO) to analyze and reconcile two competing notions of role existing in the conceptual modeling literature. Moreover, a modeling solution based on this ontology is proposed, which incorporates the benefit of the two approaches analyzed.

1 Introduction Roles represent a fundamental notion for our conceptualization of reality. This notion has received much attention both in philosophical investigation [20,32] and in the conceptual modeling literature [2,31,34]. In particular, in the sub-area of conceptual modeling concerned with agent-oriented conceptual modeling, the concept of role is considered of fundamental relevance [5,25,26]. In a comprehensive study on this topic, Friedrich Steimman [31] defends that the role concept naturally complements those of object and relationship, standing on the same level of importance. However, Steimann also recognizes that “the role concept, although equally fundamental, has long not received the widespread attention it deserved”, and that “although there appears to be a general awareness that roles are an important modelling concept, until now no consensus has been reached as to how roles should be represented or integrated into the established modeling frameworks” [ibid., p.84]. The last statement can be verified by inspecting the diversity and incompatibility of the several conceptualizations of roles currently co-existing in the literature [2,18,31,34]. Recently, not only has the interest in roles grown continuously, but also has the interest in finding a common ground on which the different notions of role can be judged and reconciled [20,22]. In this paper, we employ the foundational ontology developed in [11,12] to provide real-world semantics, and to harmonize two competing notions of role present in the conceptual modeling literature. In section 2 we present the theoretical background of the work presented here, i.e., the foundational ontology which is employed in the rest of the paper. A discussion on the categories of this ontology is continued in section 3, in which we formally define the notion of role that is adopted in our ontological framework. In section 4, we discuss a second notion of role that deviates from most of the proposals in the literature. This second notion of role has been initially proposed in [34] to address a philosophical A. Garcia et al. (Eds.): SELMAS 2005, LNCS 3914, pp. 143 – 160, 2006. © Springer-Verlag Berlin Heidelberg 2006

144

G. Guizzardi

problem known as The Counting Problem but it has been later adopted by other modeling approaches. In section 5, by using the foundational ontology presented in section 2, we manage to provide an ontological interpretation for both notions of role discussed. Moreover, we propose a conceptual modeling solution based on this ontology that is able to harmonize these two competing notions of role while maintaining the benefits of the two approaches. Section 6 concludes the article by presenting some final considerations.

2 Background: The Unified Foundational Ontology (UFO-A) In this section, we present a fragment of a philosophically and cognitively well-founded reference ontology (foundational ontology) that has been developed in [11,12]. In particular, in [12], this ontology is named UFO (Unified Foundational Ontology) and is presented in three compliance sets. Here, we focus on the first of these sets (UFO-A), which is an ontology of endurants. As demonstrated in [12], this ontology comprise a number of core ontological categories that can be extended to provide a foundation for Agent Modeling Concepts (UFO-C). In the sequel, we restrict ourselves to a fragment of UFO-A, depicted in Figure 1 (see aforementioned references for details). In what follows, we offer a formal characterization of some of the notions discussed by using a language of quantified modal logics with identity. The domain of quantification adopted is that of possibilia, which includes all possible entities independent of their actual existence. Therefore we shall quantify over a constant domain in all possible worlds. Moreover, all worlds are equally accessible. As a result we have the simplest language of quantified modal logics (QS5) with identity [9]. Finally, all formulas described are assumed to hold necessarily. Entity

Universal

Relation

Monadic Universal

Substantial Universal

Kind

Quality Universal

Relator Universal

Substantial

Formal Relation

QuaIndividualUniversal

characterization

Moment

Quality

Material Relation

Existential Dependency

Phase

Role

Individual

Relator

QuaIndividual

Mediation

Fig. 1. Excerpt of the Foundational ontology UFO-A

A fundamental distinction in this ontology is between the categories of Individual and Universal. Individuals are entities that exist in reality possessing a unique identity. Universals, conversely, are space-time independent pattern of features, which can be realized in a number of different individuals. The core of this ontology exemplifies the so-called Aristotelian ontological square comprising the category pairs Substantial-Substantial Universal, Moment-Moment Universal. From a metaphysical point of view, this choice allows for the construction of a parsimonious ontology, based on the primitive and formally defined notion of existential dependence [11]:

Agent Roles, Qua Individuals and the Counting Problem

145

Definition 1 (existential dependence). Let the predicate ε denote existence. We have that an individual x is existentially dependent on another individual y (symbolized as ed(x,y)) iff, as a matter of necessity, y must exist whenever x exists, or formally (1). ■ ed(x,y) =def □(ε(x) → ε(y)). 2.1 Moments The word Moment is derived from the german Momente in the writings of E. Husserl and it denotes, in general terms, what is sometimes named trope, abstract particular, individual accident, or property instance [21]. In the scope of this work, the term bears no relation to the notion of time instant in ordinary parlance. The origin of the notion of moment lies in the theory of individual accidents developed by Aristotle. According to him, an accident is an individualized property, event or process that is not a part of the essence of a thing. We here use the term “moment” in a more general sense and do not distinguish a priori between essential and inessential moments. As pointed out by [28], there is solid evidence for moments in the literature. On one hand, in the analysis of the content of perception, moments are the immediate objects of everyday perception. On the other hand, the idea of moments as truthmakers underlies a standard event-based approach to natural language semantics. The notion of moment employed here comprises: (a) Intrinsic Moments or Qualities: an individualized (objectified) color, temperature, or weight, a symptom, a skill, a belief, an intention, an electric charge; (b) Relational Moments or Relators: a kiss, a handshake, a covalent bond, a medical treatment, but also social objects such as a flight connection, a purchase order and a commitment or claim [12]. An important feature that characterizes all moments is that they can only exist in other individuals (in the way in which, for example, electrical charge can exist only in some conductor). To put it more technically, we say that moments are existentially dependent on other individuals. Existential dependence can also be used to differentiate intrinsic and relational moments: qualities are dependent of one single individual; relators depend on a plurality of individuals. A special type of existential dependence relation that holds between a moment x and the individual y of which x depends is the relation of inherence (i). Thus, for an individual x to be a moment of another individual y, the relation i(x,y) must hold between the two. For example, inherence glues your smile to your face, or the charge in a specific conductor to the conductor itself. We formally characterize a moment as an individual that inheres in (and, hence, is existentially dependent upon) another individual: Definition 2 (Moment). (2). Moment(x) =def Individual(x) ∧ ∃y i(x,y)

•

In our framework, we adopt the so-called non-migration (or non-transferability) principle. This means that it is not possible for a moment m to inhere in two different individuals a and b: (3). ∀x,y,z (Moment(x) ∧ i(x,y) ∧ i(x,z) → y = z) This characteristic of moments seems at first counterintuitive. For example, if we have two particulars a (a red apple) and b (a red car), and two moments r1 (particular redness of a) and r2 (particular redness of b), we consider r1 and r2 to be different

146

G. Guizzardi

individuals, although perhaps qualitatively indistinguishable. What does it mean then to say that a and b have the same color? Due to (3), sameness here cannot refer to strict (numerical) identity, but only to a qualitative one (i.e., equivalence in a certain respect). In conformance with DOLCE [21], we distinguish between the color of a particular apple (its quality) and its ‘value’ (e.g., a particular shade of red). The latter is named quale, and describes a projection of an individual quality into a certain conceptual space [11]. The unique individual y that a moment x inheres in is termed the bearer of x and is defined as follows: Definition 3 (Bearer of a Moment) : (4). β(x) =def ιy i(x,y) 1

•

Finally, the bearer of a moment can itself be another moment. An example of moment inhering in another moment is the individualized time extension, or the graveness of a particular symptom. The infinite regress in the inherence chain is prevented by the fact that there are individuals that cannot inhere in other individuals, namely, substantials. 2.2 Substantial Substantials are individuals that posses (direct) spatial-temporal qualities and that are founded on matter. Examples of Substances include ordinary objects of everyday experience such as an individual person, a dog, a house, a hammer, a car, Alan Turing and The Rolling Stones but also the so-called Fiat Objects such as the North-Sea and its proper-parts, postal districts and a non-smoking area of a restaurant. In contrast with moments, substantials do not inhere in anything and, as a consequence, they enjoy a higher degree of independence. We define the category of substantials as follows: Definition 4 (Substantial). A substantial is an individual that does not inhere in another individual, i.e., which is not a moment. Formally, (5). Substantial(x) =def Individual(x) ∧ ¬Moment(x) ■ As we have previously stated, substantials enjoy a higher degree of independence when compared to moments. Can we make a stronger statement? Can we say that substantials are existentially independent from all other individuals? If we take the notion of existential dependence that we have given in definition 1, the answer is no. Since, there are certainly pairs (x,y) where x is a substantial that satisfy ed(x,y). For example, if y is any of the essential moments of x (the particular DNA of a person). Moreover, even if both x and y are substantials, ed(x,y) can be satisfied. Take for example a substantial and any of its essential parts (e.g., a car and its chassis as an essential part). Or, alternatively, a substantial x and another object y of which x is an inseparable part (e.g., a brain and person of which this brain is an inseparable part). The notions of essential and inseparable parts are discussed in depth in [11].

1

The iota operator (ι) used in a formula such as ιxϕ was defined by B. Russel and implies both the existence and the uniqueness of an individual x satisfying predicate ϕ.

Agent Roles, Qua Individuals and the Counting Problem

147

However, suppose that x and y are two substantials that are disjoint from each other, i.e., they are neither part of each other nor they share a common part. The symbols ∫ and < below represent disjointness and proper parthood2, respectively: (6). (x ∫ y) =def ¬(x < y) ∧ ¬(y < x) ∧ ¬(∃z (z < x) ∧ (z < y)). Then, in this case, we can say that x and y are necessarily independent from each other (symbolized as indep): (7). indep(x,y) =def ¬ed(x,y) ∧ ¬ed(y,x) (8). ∀x,y Substantial(x) ∧ Substantial(y) ∧ (x ∫ y) → indep(x,y) For example, a person depends on her brain, and a car depends on its chassis. However, a person (car) does not dependent on any other substantial that is disjoint from her (it). Notice that formula (8) also excludes the case of mutual existential dependence between substantials that share a common essential part (e.g., two rooms that share a wall as a mutual essential part). 2.3 Relations, Relators and Qua Individuals Relations are entities that glue together other entities. In the philosophical literature, two broad categories of relations are typically considered, namely, material and formal relations [14,29]. Formal relations hold between two or more entities directly, without any further intervening individual. Examples of formal relations include existential dependence (ed), inherence (i), part-of (

Software Engineering for Multi-Agent Systems IV: Research Issues and Practical Applications

Software Engineering for Multi-Agent Systems II. Research Issues and Practical Applications

Software Engineering for Large-Scale Multi-Agent Systems, Research Issues and Practical Applications, SELMAS 2002

Iterative Software Engineering for Multiagent Systems.. The MASSIVE Method

Engineering Wireless-Based Software Systems And Applications

Multiagent Engineering: Theory and Applications in Enterprises

Engineering Secure Software and Systems

Multiagent systems

Computer software engineering research

Professional issues in software engineering

Software Engineering for Multi-Agent Systems II

Combustion Engineering Issues for Solid Fuel Systems

Ontologies for Software Engineering and Software Technology

Combustion Engineering Issues for Solid Fuel Systems

Engineering Software for Accessibility

Categories for Software Engineering

Categories for Software Engineering

Practical fluid mechanics for engineering applications

Field-based coordination for pervasive multiagent systems

Systems of Systems Engineering: Principles and Applications

Software Engineering and Computer Systems, Part II

Software Engineering and Computer Systems, Part III

Advances on Practical Applications of Agents and Multiagent Systems: 9th International Conference on Practical Applications of Agents and Multiagent ... (Advances in Intelligent and Soft Computing)

Highlights in Practical Applications of Agents and Multiagent Systems: 9th International Conference on Practical Applications of Agents and Multiagent ... (Advances in Intelligent and Soft Computing)

Distributed Reason Maintenance for Multiagent Systems

Field-Based Coordination for Pervasive Multiagent Systems

Multiagent Systems - A Theoretical Framework for Intentions

Research Issues in Systems Analysis and Design, Databases and Software Development (Advances in Database Research Series)

Advances in Practical Applications of Agents and Multiagent Systems (Advances in Intelligent and Soft Computing, 70)

Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage

Cryptography Engineering: Design Principles and Practical Applications

Software Engineering for Multi-Agent Systems IV: Research Issues and Practical Applications

Software Engineering for Multi-Agent Systems II. Research Issues and Practical Applications

Software Engineering for Large-Scale Multi-Agent Systems, Research Issues and Practical Applications, SELMAS 2002

Iterative Software Engineering for Multiagent Systems.. The MASSIVE Method

Engineering Wireless-Based Software Systems And Applications

Multiagent Engineering: Theory and Applications in Enterprises

Engineering Secure Software and Systems

Multiagent systems

Computer software engineering research

Professional issues in software engineering

Software Engineering for Multi-Agent Systems II

Combustion Engineering Issues for Solid Fuel Systems

Ontologies for Software Engineering and Software Technology

Combustion Engineering Issues for Solid Fuel Systems

Engineering Software for Accessibility

Categories for Software Engineering

Categories for Software Engineering

Practical fluid mechanics for engineering applications

Field-based coordination for pervasive multiagent systems

Systems of Systems Engineering: Principles and Applications

Software Engineering and Computer Systems, Part II

Software Engineering and Computer Systems, Part III

Advances on Practical Applications of Agents and Multiagent Systems: 9th International Conference on Practical Applications of Agents and Multiagent ... (Advances in Intelligent and Soft Computing)

Highlights in Practical Applications of Agents and Multiagent Systems: 9th International Conference on Practical Applications of Agents and Multiagent ... (Advances in Intelligent and Soft Computing)

Distributed Reason Maintenance for Multiagent Systems

Field-Based Coordination for Pervasive Multiagent Systems

Multiagent Systems - A Theoretical Framework for Intentions

Research Issues in Systems Analysis and Design, Databases and Software Development (Advances in Database Research Series)

Advances in Practical Applications of Agents and Multiagent Systems (Advances in Intelligent and Soft Computing, 70)

Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage

Cryptography Engineering: Design Principles and Practical Applications

Recommend Documents