Index of /rozprawy2/11443

(1)

Faculty of Computer Science, Electronics and Telecommunications Department of Computer Science

Doctoral thesis

Agent model based on stream processing

in simulations and computational applications

Doctoral dissertation of: Łukasz Faber

Supervisor:

prof. dr hab. inż. Krzysztof Boryczko Auxillary supervisor:

dr inż. Roman Dębski

(2)

(3)

Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Informatyki

Rozprawa doktorska

Agentowy model wykorzystujący przetwarzanie

strumieniowe w zastosowaniach symulacyjnych

i obliczeniowych

Rozprawa doktorska przygotowana przez: Łukasz Faber

Promotor:

prof. dr hab. inż. Krzysztof Boryczko Promotor pomocniczy:

dr inż. Roman Dębski

(4)

(5)

Abstract

Large-scale simulations and computational problems require tools that support paral-lelism and, sometimes, distribution. Multi-agent-based problems are no different in this aspect. Moreover, there is an increased presence of General Purpose GPUs (GPGPUs) and other processing accelerators in the field of large-scale computations and simulations. The way they work, leads to a pipeline or data stream fashion of processing, where multiple data units are placed into their memory and then they are simultaneously processed by software

kernels. This is called Single Program-Multiple Data (SPMD) and is most suitable for

programming in a data parallel fashion. In the meantime, non-hardware-based solutions that offer stream or stream-like processing also gained popularity.

This dissertation tries to show that it is possible to augment an agent-based model with a stream-based execution to implement an effective and versatile platform for simulations and computational applications. It does it in three steps.

First, it reviews and analyses solutions that currently exist and that are present in the various multi-agent platforms used in agent-based modelling and simulation. This builds understanding of issues that need to be tackled when building an agent model and its implementation.

Second, it presents a simple, theoretical model of the stream-based agent processing (called here streaming agents) and then discuss its implementation. Concepts such as the stream processing, data parallelism and pipeline are used to construct (and later to implement) a general multi-agent model that can be used in agent-based modelling and simulations and in computational applications. To complete the view of the proposal, a software platform that wraps around this model is also discussed.

Third, it provides two use cases showing that this approach to the problem of con-structing a general agent model can potentially provide a more flexible solution to par-allelism and distribution in agent systems. The first use case involves a simulation of nanorobots flowing in the blood to locate illness markers. Its goal is to demonstrate how the proposed model and platform fit the complex hybrid simulation. The second one uses the introduced model to reimplement the well-known Evolutionary Multi-Agent System concept as a representation of a computational application.

(6)

(7)

Acknowledgements

Over the past six years I have received support and encouragement from a great number of individuals. I am thankful especially to:

Professor Krzysztof Boryczko, my supervisor, the supporter and the guide in the particle-simulation world, for helping me through these years and constantly providing me with new problems to solve.

Professor Marek Kisiel-Dorohinicki, my closest collaborator, for the encouragement and multiple discussions we held together on multi-agent and distributed systems.

Professor Aleksander Byrski, doctor Roman Dębski, doctor Kamil Piętak, for helping me a lot with ideas, proofreading and answering various questions.

My parents and my brother – all of this would not be possible without them. They encouraged and supported me through these years.

Last, but not least, Iza, my partner, a safe harbour in this long journey.

(8)

(9)

Hybridization . . . 77 5.2 Model overview . . . 77 Types of agents . . . 80 Formalisation . . . 81 5.3 Architecture overview . . . 82 5.4 Particle-based simulations . . . 83 Implementation overview . . . 83 Output . . . 84 Potential issues . . . 86 5.5 Agent-based simulations . . . 87 Agent types . . . 87

Position of agents in the environment . . . 91

Additional structures . . . 92

5.6 Communication between simulations . . . 93

5.7 Distribution and parallelism . . . 95

Particle-based simulation . . . 95

Agent-based simulation . . . 96

5.8 Comparison with the FLAME GPU model . . . 97

5.9 Summary and future works . . . 101

6 Case study: Evolutionary Multi-Agent Systems 103 6.1 Evolutionary Multi-Agent Systems . . . 103

6.2 Model overview . . . 105 6.3 Implementation . . . 107 Agent . . . 107 Pipeline . . . 107 6.4 Verification scenario . . . 108 6.5 Verification results . . . 112

6.6 Comparison with FLAME GPU model . . . 118

6.7 Summary and future works . . . 121

(12)

viii Contents

7.1 The model, the implementation and the platform . . . 123 7.2 Contributions . . . 124 7.3 Looking ahead . . . 125

A FLAME GPU model overview 127

(13)

List of Figures

2.1 A multi-agent system . . . 9

3.1 A shared datastore/memory model . . . 35

4.1 The agent tree in AgE 2 . . . 40

4.2 The distributed AgE architecture . . . 44

4.3 The streaming agents concept . . . 46

4.4 Streaming agents processing in a workplace . . . 54

4.5 The class diagram of a workplace and its dependencies . . . 55

4.6 The sequence diagram of the agent migration . . . 59

4.7 Levels of parallelism and concurrency in the streaming agents module . . . 61

4.8 The distributed architecture of AgE 3 . . . 66

4.9 Communication in a distributed application in AgE . . . 68

4.10 Computation loading and start . . . 70

5.1 A sample snapshot from the blood flow simulation . . . 75

5.2 The architecture of the offline version . . . 78

5.3 The architecture of the online version . . . 79

5.4 The overview of the concept of the system . . . 81

5.5 A snapshot from a step of the simulation . . . 84

5.6 A snapshot from a step of the simulation with all particles . . . 85

5.7 The Reynolds number as a function of a time step for various numbers of agents in blood and various stiffness of their material . . . 86

5.8 Step functions for the nanorobot in the blood simulation in the streaming agents model . . . 90

5.9 Distribution of a computational box over nodes in the particle-based simulation 96 5.10 Agent-based simulation distribution in correspondence to the particle-based simulation . . . 96

6.1 Evolutionary Multi-Agent System . . . 104

6.2 EMAS step functions in streaming agents model . . . 109 ix

(14)

x List of Figures

6.3 A merit factor value of the best solution over time for the problem size 𝐿 = 128and the cache size equal to 50 . . . 113 6.4 A number of evaluations over time for the problem size 𝐿 = 128 and the

cache size equal to 50 . . . 114 6.5 A merit factor value of the best solution over time for the problem size

𝐿 = 128and the time limit equal to 10 000 µs . . . 115 6.6 A number of evaluations over time for the problem size 𝐿 = 128 and the

time limit equal to 10 000 µs . . . 116 6.7 A number of evolutionary steps for the problem size 𝐿 = 128 and the cache

size equal to 50 . . . 117 6.8 A number of evolutionary steps for the problem size 𝐿 = 128 and the time

(15)

List of Tables

2.1 A short comparison of the discussed agent platforms . . . 21

3.1 Different options for messaging mechanisms . . . 28

5.1 Selected parameters used in particle-based simulations . . . 84

5.2 Common elements of agent definitions for FLAME GPU . . . 97

5.3 Agents definitions for FLAME GPU . . . 98

5.4 Messages used in the FLAME GPU version of the simulation . . . 99

5.5 The function layers in the FLAME GPU version of the simulation . . . 99

5.6 Agents functions in the FLAME GPU version of the simulation . . . 100

6.1 Parameters used for LABS executions in tests . . . 112

6.2 Agents definitions for FLAME GPU . . . 118

6.3 Messages used in the FLAME GPU version of EMAS . . . 119

6.4 The function layers in the FLAME GPU version of EMAS . . . 119

6.5 Agents functions in the FLAME GPU version of EMAS . . . 120

(16)

(17)

List of Listings

4.1 The agent in the streaming agents module . . . 52

4.2 Fields of the workplace in the streaming agents module . . . 53

4.3 Simplified signatures of the workplace operations . . . 54

4.4 The sample implementation of the step operation with a pipeline . . . 56

4.5 An implementation of the split operator . . . 58

4.6 An implementation of the energyBelowThreshold predicate . . . 58

4.7 An energy transfer implementation for a fight between agents . . . 62

4.8 An example computation configuration in JavaScript . . . 65

5.1 A fragment of the sample output from the particle simulation . . . 85

5.2 Fields of the Nanorobot class . . . 88

5.3 A simplified pipeline for the nanorobots simulation . . . 89

5.4 The base Generator class . . . 89

5.5 Fields of the ExternalAgent class . . . 91

5.6 Fields of the Particle class . . . 92

5.7 Fields of the ParticleGroup class . . . 93

5.8 The particles façade interface . . . 94

6.1 The Solution interface . . . 108

(18)

(19)

List of Algorithms

3.1 Agents in the simulated parallelism . . . 26

3.2 The example of a very simple query that counts all agents by their type . . . 29

3.3 A sample interaction with a callback in a remote procedure call . . . 32

3.4 A sample interaction with a future in a remote procedure call . . . 32

4.1 Execution of an aggregate agent step in AgE 2 . . . 41

4.2 Interaction of the workplace operations . . . 48

4.3 The family of convert functions . . . 50

4.4 The generator for the family of convert functions . . . . 51

4.5 A simple before-step operation . . . . 51

4.6 A simple after-step operation . . . . 51

4.7 A possible implementation of the message exchange . . . 64

6.1 Interaction between the workplace evaluator and the global evaluator . . . . 111

(20)

(21)

Chapter

1

Introduction

In agent-based modelling and simulations two approaches are usually used in building models: a) constructing a model ‘in-house’ from the ground up, or b) using a more general toolkit or a platform as a base for it. When choosing the second option, a researcher has a large number of software that they can use – in particular some surveys enumerate around ninety different platforms and tools [1].

This dissertation presents an agent model based on streaming processing with the goal of using it in simulations and computational applications. Along with the model, a supporting platform is presented, that provides distributed and parallel computing utilities.

This chapter presents the problem discussed in the dissertation (section 1.1) and its goals (section 1.2). Then, section 1.3 shows the previous works that led to this dissertation. Finally, section 1.4 presents its organization.

1.1 The problem

Large-scale simulations and computational problems require tools that support parallelism and, sometimes, distribution. Multi-agent-based problems are no different in this aspect. Various solutions have been proposed with the goal of achieving an optimal tool offering an easy way of supporting distribution and parallelism. This can be achieved in multiple ways: starting from simple thread-per-agent parallelism, through more complicated scheduling of multiple agents on a thread pool to more sophisticated solutions. Still, a lot of parallel and distributed agent-based platforms suffer from synchronization, state-sharing issues or other related problems [96]. Most of them are also focused on usage with typical research multi-node clusters as they use MPI as a layer of communication.

For many years General Purpose GPUs (GPGPUs) and other processing accelerators increased their popularity as the volume of data, that needs to be processed, has grown. They usually work in a pipeline or data stream fashion: multiple data units are placed into their memory and then they are simultaneously processed by kernels written in a technology-specific language. This model is a result of the way they are constructed – usually GPGPUs have a large number of cores (thus we talk about manycore processors) that have very small, but fast, local, private memory and larger, but slow, global, shared

(22)

2 Chapter 1. Introduction

memory. GPGPUs usually have to execute the same code at the same time on all cores. This is called Single Program-Multiple Data (SPMD) and is most suitable for programming in a data parallel fashion.

In the meantime, non-hardware-based solutions that offer stream or stream-like pro-cessing also gained popularity. Multiple software and cloud solutions were introduced. Two popular examples are Apache Kafka1_{or Google Cloud Dataflow.}2_{Often, they use} paradigms known from functional languages to increase scalability: immutable data, pure functions as operators and other similar concepts. This trend is visible also in pro-gramming languages: for example, with the Scala’s streams or Java’s stream extensions to collections.

The usual approach to using GPGPUs with agent-based systems was to delegate a work of an agent to the hardware. It requires that the delegated job is significantly large so the cost of transferring the data is overcome by the gains resulting from the parallel processing. However, in some applications, it is possible to reverse this approach and transfer whole populations of agents to the hardware and then execute a common algorithm with all of them. This is a SPMD approach to the agent-based systems.

The same approach can be used without accelerating hardware – the whole population of agents can be treated as a collection of data that can be processed using a parallel stream.

1.2 Goals

With trends presented in the previous section in mind, we approached the problem of constructing a general agent model that potentially can provide a more flexible approach to parallelism and constructing agent systems for computations and simulations. We aim to focus our attention on a particular class of these systems – these with multiple rather simple (in terms of internal logic) agents of a few types. Such systems are easy to find in simulations – for example traffic simulations that focus on traffic control or preventing jams, swarm behaviours simulations or some network intrusion models. They also arise from agent-based computational applications that comes from swarm-like models – for example, ant or bee colony algorithms – or other biologically-inspired systems like

evolutionary algorithms.

The main claim of the dissertation is thus: stream processing as a base for con-structing an agent-based model provides mechanisms for implementing an effect-ive and versatile platform for simulations and computational applications.

Some of the terms are elaborated more in the following paragraphs.

�Stream processing In the stream processing paradigm, a stream of data is created and

then passed through multiple, sequential functions (sometimes called ‘kernels’), which operate on each element of the stream. With our approach we will be discussing streams

of agents or streams of populations, where simple agents are passed through a pipeline of

functions.

1_{Official page:}_{https://kafka.apache.org/}_.

(23)

1.3. Previous works 3

�Agent-based model Agent-based modelling is at the centre of our approach. It is

a popular and well studied field of computer science (see Chapter 2) which provides a mechanism for a wide range of applications in multiple other fields.

�Effective and versatile platform We understand ‘effective’ and ‘versatile’ as

having a wide range of applications and, moreover, offering a scalability for end user needs. We aim at showing that the model can be used in multiple ways and that it can be scaled easily using parallelism and distribution.

Our approach to the stream processing is based mostly on solutions known from manycore accelerators. In these implementations, usually a single kernel3_{or multiple} sequential kernels, executed on multiple cores, process different portions of data in the identical way. Thus, we could say that we are bringing the SPMD approach to the agent world.

�Simulations and computational applications The presented model is

espe-cially well-suited for simulations and computational applications with multiple, simple agents of one or few types. Additionally, it is directed mostly at simulations and computa-tions that can be modelled with discrete time, where a well-defined step of the processing can be distinguished.

We present two examples of specific models built on top of it:

i) computational one – Evolutionary Multi Agent System (EMAS), and

ii) simulational one – hybrid agent-particle simulation of nanorobots flowing within the blood flow.

Both of these use agents with rather simple behaviours and both are based in the discrete-time execution.

1.3 Previous works

This dissertation builds on and extends previous works related to multi-agent systems that were written together with other collaborators (sorted by the date of publication):

[1] Łukasz Faber, Kamil Piętak, Aleksander Byrski and Marek Kisiel-Dorohinicki. ‘Agent-Based Simulation in AgE Framework’. In: Advances in Intelligent

Modelling and Simulation. Ed. by Aleksander Byrski, Zuzana Oplatková,

Marco Carvalho and Marek Kisiel-Dorohinicki. Springer Berlin Heidelberg, 2012, pp. 55–83. isbn: 978-3-642-28888-3. doi:10.1007/978-3-642-28888-3_3.

[2] Radoslaw Klimek, Łukasz Faber and Marek Kisiel-Dorohinicki.

‘Deduction-Based Modelling and Verification of Agent-Based Systems for Data Integration’. In: Man-Machine Interactions 3, Proceedings of the 3rd_{International}

Conference on Man-Machine Interactions, ICMMI 2013, Brenna, Poland, October

22-25, 2013. 2013, pp. 361–368. doi:10.1007/978-3-319-02309-0_39.

(24)

4 Chapter 1. Introduction

[3] Radoslaw Klimek, Łukasz Faber and Marek Kisiel-Dorohinicki. ‘Verifying data integration agents with deduction-based models’. In: Proceedings of the 2013

Federated Conference on Computer Science and Information Systems, Kraków, Poland, September 8-11, 2013. 2013, pp. 1029–1035.

[4] Daniel Krzywicki, Łukasz Faber, Kamil Pietak, Aleksander Byrski and Marek Kisiel-Dorohinicki. ‘Lightweight Distributed Component-Oriented Multi-Agent Simulation Platform’. In: Proceedings of the 27th_European

Conference on Modelling and Simulation, ECMS 2013, Ålesund, Norway, May

27-30, 2013. 2013, pp. 469–476. doi:10.7148/2013-0469.

[5] Łukasz Faber. ‘Agent-based Data Integration Framework’. In: Computer Science

(AGH) 15.4 (2014), pp. 389–410. doi:10.7494/csci.2014.15.4.389.

[6] Łukasz Faber, Krzysztof Boryczko and Marek Kisiel-Dorohinicki. ‘Hybrid Architecture For Simulation Of Blood Flow With Foreign Bodies’. In: 28th

European Conference on Modelling and Simulation, ECMS 2014, Brescia, Italy,

May 27-30, 2014. 28th_{European Conference on Modelling and Simulation,}

Brescia, Italy, 2014, pp. 523–529. doi:10.7148/2014-0523.

[7] Daniel Krzywicki, Łukasz Faber, Aleksander Byrski and

Marek Kisiel-Dorohinicki. ‘Computing agents for decision support systems’. In:

Future Generation Computer Systems 37 (July 2014), pp. 390–400. doi:

10.1016/j.future.2014.02.002.

[8] Daniel Krzywicki, Jan Stypka, Piotr Anielski, Łukasz Faber, Wojciech Turek, Aleksander Byrski and Marek Kisiel-Dorohinicki. ‘Generation-free Agent-based Evolutionary Computing’. In: Proceedings of the International Conference on

Computational Science, ICCS 2014, Cairns, Queensland, Australia, 10-12 June, 2014.

2014, pp. 1068–1077. doi:10.1016/j.procs.2014.05.096.

[9] Paweł Topa, Łukasz Faber, Jarosław Tyszka and Maciej Komosinski. ‘Modelling ecology and evolution of foraminifera in the agent-oriented distributed platform’. In: Journal of Computational Science (Aug. 2016). doi:

10.1016/j.jocs.2016.07.009.

[10] Joanna Kijak, Piotr Martyna, Aleksander Byrski, Łukasz Faber, Kamil Piętak and Marek Kisiel-Dorohinicki. ‘Collectively Intelligent Prediction in Evolutionary Multi-agent System’. In: International Journal of Microelectronics and Computer

Science 8.3 (2017), pp. 85–96.

[11] Daniel Krzywicki, Łukasz Faber and Roman Dębski. ‘Concurrent agent-based evolutionary computations as adaptive dataflows’. In: Concurrency and

Computation: Practice and Experience (2018). doi:10.1002/cpe.4702.

These research works were supported most of the time with the development of the agent-based platform AgE (see Chapter 4) and various specific applications based on it. Specifically, the presented model along with the supporting parallelism and distribution mechanisms was the basis for the new version of the platform.

(25)

1.4. Organization of the thesis 5

1.4 Organization of the thesis

The next three chapters discuss multi-agent systems, their building blocks and popular implementations.

Chapter 2 introduces agency and multi-agent systems along with their usual applica-tions, providing a general background for the thesis and the project. It presents concepts of their computational and simulational applications along with examples. Later, it reviews selected agent-based platforms with focus on the problems discussed in this dissertation. Chapter 3 continues this discussion in detail but it focuses on various aspects of implementation of agent-based systems – especially for simulations and computational usages.

Chapter 4 presents the model and the design of the streaming-based agent model and the supporting platform – AgE. The discussion follows from overview of the previous version of the platform and the agent model that it used.

Two following chapters presents sample usages and testing and illustrative applications for the model and the platform – one being a typical agent-based simulation and the other one – a new iteration of the well-known computational model.

Chapter 5 introduces a hybrid simulation architecture that joins particle-based simula-tions with the presented agent-based model.

Chapter 6 shows how the well-known Evolutionary Multi Agent Systems may be refitted to use the streaming-based model.

Finally, Chapter 7 concludes the dissertation, summarizes the contributions, discusses not yet solved problems, poses follow-up questions and reviews possible future works.

(26)

(27)

Chapter

2

Agent-based modelling, simulations

and computations

Agency and agent-based systems, modelling and simulations are rather wide discussion and research topics. Within this chapter we go through a short review of most important concepts and problems. First, we will discuss the definition of an agent itself (section 2.1), then multi-agent systems in general (section 2.2) and agent-based modelling and simula-tions (section 2.3). In section 2.4 we describe some general technological solusimula-tions used in the field and then, in section 2.5, we present a few selected agent-based platforms in detail.

2.1 Definition of an agent

Multiple different agent definitions are used within the research community (as shown by Franklin and Graesser [38]). They span from simple ones, that do not require much more than being able to ‘negotiate and coordinate transfer of information’, to more demanding, where autonomy, reasoning capabilities and intelligence are required.

Within this work, we follow mostly the definition offered by Jennings, Sycara and Woolridge: ‘[…] an agent is a computer system, situated in some environment, that is capable of flexible autonomous action in order to meet its design objectives […]’ ([50]).

By being situated in its environment, an agent is able to receive inputs from it and act on (change) it. Commonly, such terms as sensors and actuators are used as names for the interfaces between an agent and its environment.

The definition of autonomy will be usually related to the application of an agent, however it may be defined as ‘[an ability] to act without the direct intervention of humans (or other agents), and [having] control over its own actions and internal state’ ([50]).

By flexibility, Jennings, Sycara and Woolridge understand three properties: • responsiveness – an agent can respond to changes in the environment,

• pro-activeness – an agent can take initiative if it deems it appropriate for the current goal,

• sociality – an agent is able to interact with other agents and humans. 7

(28)

8 Chapter 2. Agent-based modelling, simulations and computations

On the other hand, Franklin and Graesser, state that flexibility is simply a property where ‘actions are not scripted’ ([38]).

Other authors require different sets of attributes for agents. For example, Macal and North define these as essential characteristics of an agent [65]:

• self-contained and modular – it is possible to define and find an agent boundary, • uniquely identifiable – each agent can be distinguished from others,

• autonomous and self-directed – it functions independently of others in its environ-ment,

• having behaviours – they are used in performing actions and taking decisions on the basis of information that is sensed from the environment,

• having state – a set of attributes that represent its current situation,

• social – an agent has dynamic interactions with others and it can recognize and distinguish their characteristics.

2.2 Multi-agent systems

In a multi-agent system, a process of solving a computational problem is decomposed into multiple, autonomous agents. They can actively follow some goals, based on their beliefs (i.e., perceived environment), plan their actions ahead and learn from experiences. In order to achieve this, multi-agent systems are often used along with other methods from Artificial Intelligence or Machine Learning. Agents may also own resources and interact with each other. The structure of the system is expected to emerge from these decentralized agent interactions. Thus, multi-agent systems are a bottom-up and decentralized approach to system design and problem solving.

Usually, multi-agent systems have the following properties [108, 50]: 1. Agents are autonomous and independent.

2. Agents are aware only of their local environment; in other words, no agent has all the data in the system.

3. There is no central control component (i.e., an agent that would be able to supervise the whole system).

Some researchers add also asynchronicity of the system to this set of properties [36]. Moreover, to execute their tasks in such a system agents usually need to have means of communication and mutual interactions. The way they are handled depends on the environment and system requirements. Agent-based (and multi-agent) systems are well-researched and extensively used solutions to a very wide range of different problems: transportation, metaheuristic problem solving [14], multi-robotics, social simulations, etc. Their properties make them well-suited for distributed systems [78]: they offer modularity and scale efficiently.

(29)

2.3. Agent-based modelling, simulations and computations 9

Figure 2.1 (based on [49]) presents a general concept of a multi-agent system. Agents communicate within boundaries arising from their spatial or organizational position. They also have a limited access to the environment – only its part is visible and accessible to them.

Environment

Communication boundaries

Agents views of the environment

Figure 2.1: A multi-agent system. Agents communicate within

bound-aries (for example, spatial ones) and can only observe a part of the envir-onment.

2.3 Agent-based modelling, simulations and

computations

Agent-based modelling and simulation is an approach to modelling complex systems based on agents and multi-agent systems in particular [66, 67]. It is well suited for modelling decision-making processes by individuals and social or organizational behaviours.

Macal and North specify three elements of an agent-based model [65]: 1. Agents, their attributes and behaviours.

2. Relationships and methods of interaction between agents – possibly with some topologies of communication.

(30)

3. An environment.

Agent-based modelling usually makes use of various interaction topologies, such as: grids, networks, graphs, continuous spaces (two- or three-dimensional), geographical (Geographical Information Systems – GIS) and random (unstructured).

Applications of agent-based modelling span multiple various fields and topics, such as biology, business, technology, economics, social sciences and computations [67]. Some examples of them are:

• Ilachinski presents multi-agent-based simulations of combat called EINSTein [48]. • Topa et al. present modelling of foraminifera evolution using an agent-based

ap-proach [102].

• Cetnarowicz proposes introduction of evolution to multi-agent systems [19].1 • Lopez-Sanchez et al. show how to simulate digital news markets [62].

• Schaefer et al. propose a formalisation of the hierarchical genetic search (HGS) using agent-based modelling [98].

• Grzonka et al. introduce the Multi-Agent-System-based Cloud Monitoring system with a goal to extend traditional monitoring systems with agent-based artificial intelligence [41].

• The author of this dissertation presents a data integration framework based on a multi-agent system [29] and earlier, similar approaches exist in works of Paula et al. [82].

A more comprehensive list of agent-based models in various domains was presented by Macal and North in [65] and [67].

2.4 Technological solutions

Multi-agent systems and, more generally, the concept of an intelligent agent have found multiple implementations, both as a way to model complex systems and as a programming paradigm to implement them. Several established agent-based technological solutions exist located on two ends of the openness spectrum.

On one side, we have very open systems, including FIPA compliant, fully-fledged environments like JADE or Jadex, where agents are basic units of software abstraction [4, 3, 88, 87]. The FIPA standard aims to create open, interoperable multi-agent systems, where fully-fledged autonomous software agents can express their needs or perceive the environment and other agents using specific languages and ontologies.

On the other end, there are minimalistic and easy-to-use modelling tools like NetLogo, where agents are only present at a domain level, as means of problem decomposition [99].

(31)

2.5. Review of agent-based platforms for simulations and computations 11

The first class of systems can be used to solve any problem that benefits from using an agent-oriented approach. However, in some particular classes of applications, this can be very inefficient. This happens especially in the case of simulations and computational applications, where agents and their behaviours are well defined. Such a MAS might not need to be open to other systems, to require the possibility of code migration or to support FIPA-compliant communication. For these cases systems of the second class are more efficient and a much better choice. However, they suffer from other drawbacks, as they do not support the component-oriented approach, which affects code reusability and make more complex problems hard to program. Also, these systems are usually not suited for running in distributed environments. In other words, they do not scale well with bigger problems or more complex systems.

In some cases, a multi-agent system may also be implemented without help of any software structures related to agents. This is often encountered in simulations or computa-tions modelling complex phenomena, such as natural or social ones. In these applicacomputa-tions, agents are building blocks of the model, which, in turn, may not be implemented with the use of any agent technology at all.

There are multiple multi-agent frameworks and platforms that can be used to create a simulation system [76, 58]. Some of them are oriented to specific kinds of simulations. For example, simulating movements of entities with the 3D visualisation (breve [54]) or a possibility of visual programming (SeSam [105]). When looking for universal agent-based simulation frameworks (especially in the open-source software domain), one should consider such products as, for example, Galatea [26], RePast [22], Mason [64]. Other ones are general-purpose agent-based programming frameworks (JADE [4]) that may be of course adapted to any kind of simulation. MadKit [43] should also be mentioned as a framework for simulating complex populations.

At this point, it is also important to mention AgE, a multi-agent framework developed for long time by the author [33]. It was successfully used in various scenarios, ranging from evolutionary computations to social simulations. This dissertation presents its new version based around stream processing.

The extended description of several agent-based platforms is continued in section 2.5 and AgE is described in more detail in Chapter 4.

2.5 Review of agent-based platforms for simulations

and computations

There are many multi-agent platforms supporting the implementation of distributed simulation and computations systems. However, they are very often focused on a specific usage envisioned by their authors [91, 58, 16]. Considering our needs, we review the following, general-purpose platforms:

• JADE [4, 3], • Jadex [88, 87], • MaDKit [43],

(32)

• MASON [63, 64],

• RePast Simphony [77] and Repast HPC [21], • Swarm [73],

• FLAME and FLAME GPU [95, 94, 93].

In the following sections, we discuss these platforms by presenting a general overview of their features and then by analysing properties interesting from the point of view of building a new agent model and a platform. We focus especially on these questions:

• how agents are run in the platform,

• how they can communicate with each other, • what are their types,

• whether it is possible to run a distributed computation, • whether it is possible to migrate agents between nodes.

Table 2.1 presents an overview of the discussed features for the presented platforms.

JADE

JADE2_{is a mature (created in 1998) platform which, from the beginning, was focused on} maintaining compatibility with FIPA3_{specifications, thus providing a usable and simple} middleware for agent-based applications.

The FIPA model defines various properties of an interoperable multi-agent system [89]. Specifically, it defines properties of an agent platform and a language for interactions between agents – Agent Communication Language (ACL). The main features that an agent platform should provide, from the point of view of the FIPA model, are:

• Agent Management System – a system that supervises the platform,

• Agent Communication Channel – a default, reliable and ordered communica-tion method based on messages,

• Directory Facilitator – a yellow pages service.

They should be implemented as specialised agents. JADE strictly follows these specifica-tions.

Architecturally, JADE distinguishes two main building blocks: • Agent Platform is a whole JADE platform currently running,

2_{Available at}_{http://jade.tilab.com/}_.

(33)

• Agent Container is a separate part of the platform that communicate with other containers using a communication protocol.

All in all, JADE is a platform, as its authors state, rather envisioned to aid with agent-oriented programming. It also emphasizes agent identity and separation from other agents. As such, it is more suited to model complex, internally heterogeneous applications than large-scale simulations requiring lightweight, uniform agents whose goal is performance and not standard compliance.

JADE is an open source, LGPL-licensed application written in Java. Its newest version is 4.5.

�Execution model The execution (and concurrency) model in JADE is an

imple-mentation of the thread-per-agent model. Generally speaking, each of agents uses a single, separate thread and has an additional internal round-robin scheduler with cooperative scheduling. Tasks can be scheduled hierarchically: each Behaviour task can be composed of other tasks and it controls their execution.

�Communication between agents Identification of agents is done by name, so

any agent can send message to any other agent providing it gains a knowledge of its name. It is also possible to specify message targets by their properties. Moreover, receivers do not have to exist at the time of sending the message. Messaging is implemented fully in a peer-to-peer fashion and is asynchronous. All communication is done by passing messages.

�Agent types Unfortunately, JADE does not provide an easy way to create many simple,

steppable agents and is better suited for applications requiring fully-fledged BDI agents.

�Distributed computation The framework puts a lot of pressure on distribution.

Agents can be automatically discovered by other agents and there is no central point of control.

�Agent migration Agent migration is also supported. It is possible for an agent to

migrate from one host to a different host both with its data and its code (i.e., the target host does not need to the have agent’s class available before the migration). A migration process can be used as a means of computation load control.

One of more interesting features of JADE, arising from its architecture and design decisions, is a possibility to run its agents uniformly on various kinds of devices – for example, on mobile phones.

Jadex

Jadex4_{is an object-oriented, agent-based framework focused on implementation of the}

belief–desire–intention (BDI) model. In Jadex, it is represented as beliefs, goals and plans.

(34)

Beliefs

In Jadex they are arbitrary objects that an agent considers as facts. Beliefs can be grouped in belief sets.

Goals

They are implementations of desires and agents always try to act in a way that can help in reaching a goal. They are represented as objects, can have dependencies between each other and can be divided into four types: perform, achieve, query and

maintain goals.

Plans

They consist of two parts: a head and a body. A head is a set of conditions, triggers and relations of the plan, whilst a body is a procedurally defined action executed as a part of it.

From the point of view, of an agent system architecture, Jadex is just an extension of JADE providing BDI-capable agents [11]. However, at some point of time authors of Jadex introduced a concept of active components [86]. This is an extension to the service component architecture (SCA) merging its concept of a component with an agent. In an active component, a SCA component is a passive entity with dependencies to other components and an agent – an autonomous one that can use sensors and effectors with a built-in reasoning mechanism. Together, they provide a dependency-based creation and initialization of complex agent hierarchies.

Jadex is an open source, GPL-licensed application written in Java. Its newest version is 3.0.86.

�Execution model Each component is running in a single separate thread.

�Communication between agents Similarly to JADE, communication between

agents can be done using messaging.

�Agent types Similarly to JADE, it does not provide any way to create lightweight

agents. There is a concept of a micro-agent in its documentation, however it is a concept related to creating POJO agents instead of agents based on components.

�Distributed computation Jadex is fully distributed. Remote instances can be

automatically discovered and are represented as local components within a platform instance.

(35)

MaDKit

MaDKit5_{is a multi-agent-based, modular and scalable library for building simulations.} Its structural organisation is based on the Agent/Group/Role (AGR) model [34].

In this model, there are no requirements to the internal structure of an agent. It is simply an entity that can actively communicate and has specific roles within one or multiple groups. Then, a role is a representation of a function (or identity) that agent performs within a group. And finally, a group is just a a set of agents. Groups can overlap.

In addition to the AGR model, the MaDKit platform uses following concepts: Micro-kernels

They provide only the basic functions: local messaging, management of local groups and roles, launching and killing of agents. All other features (remote messages, visualisation, monitoring and control of agents) are performed by agents. The kernel is also fully extensible using kernel hooks. Any agent of the system group can subscribe to a kernel hook and it will be notified in a publish-subscribe fashion about execution of kernel functions.

Agentification of services

It is a paradigm in which all non-essential platform services are handled by dedic-ated agents and can be easily replaced. Especially, communication and distribution facilities can be implemented this way. This facilitates use of any possible commu-nication mechanism and does not bind the platform to the one selected.

Graphic component model

It is a concept where each agent is fully responsible for its own graphical representa-tion – including rendering and event processing. The global GUI is managed by an additional graphical module.

MaDKit is an open source application licensed under CeCILL license. It is written in Java and its newest version is 5.2.

�Execution model By default, the decision on the agent execution policy is left for

the user. It is possible to create thread-based coarse-grained agents but also lightweight, fine-grained ones which can use any arbitrary scheduler defined by the user.

�Communication between agents Communication is implemented using

asyn-chronous messaging using an address of an agent or broadcasting a message to agents having a specific role within a group.

�Agent types As mentioned above, its up to the user what kinds of agents they will

create.

(36)

�Distributed computation Thanks to the agentification of services, distributed

computation is possible – any agent can ‘take over’ the role of a communicator and send messages to remote nodes. Since version 5 of MaDKit it is already supported by the platform and uses direct socket connections as a communication mechanism.

�Agent migration Migration is possible but it seems that the implementation must

be provided by the user.

MASON

MASON6_{is an agent-based simulation toolkit centred around ‘swarm’ simulations that} consist of large numbers of agents. Its design goals include: a small simulation core, visualization support, simulation checkpointing, efficiency with large simulations and em-beddability. The multi-layer architecture brings complete independence of the simulation logic from visualisation tools.

Somewhat intrinsic property of MASON is its binding of every simulation to some (physical or non-physical) space (called field). These spaces can be simple 2D or 3D arrays or more complicated graphs or geospatial coordinates.

There are no predefined communication nor organisation mechanisms. However, it is possible to create, for example, a network of agents using the built-in graph library.

MASON is an open source application licensed under Academic Free License. It is written in Java and its newest version is 19.

�Execution model Agents in MASON are based on a ‘steppable’ paradigm (so they

are lightweight agents in our terminology). Their execution is scheduled by the scheduler internal to the simulation and it is possible to use multiple independent schedulers in a single application. The scheduling model is flexible enough to support also agents running in their own threads. Single-node parallelism can be achieved by using parallel substeps of a steppable agent or using a separate asynchronous steppable that creates a separate thread.

�Communication between agents There are no communication mechanisms

be-sides method calls – usually an agent locates another one that is interesting in some way (for example, it is close in 2D space) and calls its relevant methods.

�Agent types Scheduling is flexible enough to support both heavy (using an

asynchron-ous steppable instance) and lightweight agents.

�Distributed computation The authors clearly state that distribution of

simula-tions was not intended as a feature to MASON. However, there is a third-party extension called D-MASON7_{[23, 25] that adds support for the transparent distribution over} mul-tiple physical nodes and supports load balancing. It has two implementations: one based

6_{Available at}_{https://cs.gmu.edu/~eclab/projects/mason/}_. 7_{Available at}_{https://sites.google.com/site/distributedmason/}_.

(37)

on a master-slave architecture using ActiveMQ, and another one decentralised, based on a MPI publish-subscribe model. Distribution of the workload is based on a division of fields into smaller spaces and the computation on different nodes is performed synchronously. Steps of the simulation are executed at the same time on all nodes and then the results are communicated before executing the next step.

�Agent migration Migration is supported in D-MASON (at least in the ActiveMQ

version, according to [24]).

Repast

Repast8_{is a widely used multi-platform agent-based modelling and simulation tool.} Cur-rently, there are actually two different tools under the same name: Repast Simphony that is a modelling system for small clusters and Repast for High Performance Computing that is targeted for large clusters.

Repast Simphony offers a modular and extensible architecture and provides visu-alization tools and multiple different projections utilities out-of-the-box. For example, multidimensional discrete grids, multidimensional continuous spaces, graph (network) or GIS projections are available. Moreover, it also includes various libraries supporting genetic algorithms, neural networks, regression, random number generation and other tools.

In both applications agents are simple classes of a used language (in Repast HPC they need to inherit a specific interface).

In Repast Simphony agents are grouped into hierarchical contexts (which can be agents, too). Contexts by themselves do not offer any structure or organisation to the agents they contain. The role of specifying the structure is delegated to aforementioned projections and it is possible to have multiple projections in a single context. Moreover, agents also can belong to multiple contexts. When an agent is in the sub-context it also exists in the parent context but the reverse is usually not true.

Repast Simphony and Repast HPC are open source applications licensed under Repast Suite License. Repast Simphony is written in Java and its newest version is 2.5, Repast HPC is written in C++ and its current version is 2.2.

�Execution model Repast Simphony provides two ways of scheduling agents:

uncon-ditional and watch-based. The former is used to schedule repetitive actions of an agent (e.g., ‘move’) in given distances of time, whilst the latter lets a method of an agent to be executed in case of some events happening. There is no support for thread-based agents. On the other hand, scheduling in Repast HPC can be only time-based (‘unconditional’ in terms used by Repast Simphony).

�Communication between agents Communication between agents is

implemen-ted by calling methods on object references and projections provide means to locate other agents. This behaviour is similar to MASON.

(38)

�Agent types Both versions support only lightweight, schedule-based agents.

�Distributed computation Parallel computations are supported in both

applica-tions, whilst distribution of workloads supposedly currently works only in Repast HPC. Parallelism is automatic because of the scheduling mechanism based on time and state change events. In Repast HPC, MPI is used as a tool to provide distributed computa-tions and the user must explicitly state the space division into MPI processes. Repast Simphony offered a Terracota-based9_{distribution plugin but it seems to be removed in} version 2.5 [20].

�Agent migration Repast HPC supports sending agents between processes

– tech-nically, an agent is serialized to a so-called ‘agent package’ and then recreated on a target node.

Swarm

Swarm10_{is the first (released around 1994) reusable software targeted at supporting} multi-agent systems. Its model is based around ‘swarms’ – collections of multi-agents and events scheduled in relation to those agents. Such a swarm represents both agents and time and, moreover, it can be an agent itself. So, agent actions and behaviour are emerging from the agents located inside it and swarms are hierarchical.

Swarm is an open source application licensed under GPL. It is written in Objective-C and Java and its newest version is 2.4.1.

�Execution model Swarm’s execution model is completely event-based. Parallelism is

achieved by executing separate scheduled actions at the same time (it is similar to Repast scheduling that was actually based on Swarm).

�Communication between agents Messaging is the main communication

mechan-ism between agents. In reality, it is a result of the implementation choices – Objective-C uses messaging to communicate between objects.

�Agent types Due to event-based execution model, Swarm does not support heavy,

thread-based agents.

�Distributed computation Swarm does not support any distribution.

�Agent migration Due to a lack of distribution, migration is unsupported. 9_{Available at}_{http://www.terracotta.org/open-source/}_.

(39)

2.6. Summary 19

FLAME and FLAME GPU

FLAME11_{(Flexible Large Scale Agent Modelling Environment) or FLAME GPU is an} agent-based modelling and simulation software that currently targets GPGPUs and previ-ously was created for using on HPC clusters.

In FLAME, an agent is an extension to a so-called ‘communicating X-Machine’ which is a finite state machine (FSM) with memory. It comprises of a name, a description, memory and functions. Memory of an agent is basically a set of named variables. Whereas functions have more complicated definition and consists of a name, a current and a next state, a condition of the transition, possible inputs and outputs.

An interesting property of FLAME is the use of an XML-based language known as XMML (X-Machine Mark-up Language) to describe the simulation model: environment, agents, messages, and so on. This model is coupled with actions for agents written in C syntax (CUDA kernels). Compiled together, they create a runnable application that executes fully on a GPGPU.

FLAME GPU is an open source application licensed under MIT License. It is written in C++ and CUDA and its newest version is 1.5.

�Execution model As the execution is entirely done on a GPGPU in the SPMD

(Single Program Multiple Data) fashion, we can call it a typical stream processing example.

�Communication between agents The only way for agents to communicate is

messaging. A message consists of a name, a description and multiple typed variables.

�Agent types FLAME agents are lightweight – they do not hold any heavy threads

and, due to the GPGPU-based execution, it is not possible to implement heavy agents.

�Distributed computation FLAME offers distributed computing on HPC (using

MPI), however the version working on GPGPUs does not provide this feature. The distribution is handled automatically by the MPI executor after compiling the code with proper parameters.

�Agent migration We did not find a way to migrate agents in the HPC version, and

the GPU version does not support migration due to not being distributed. However, there is a possibility to create new agents on the host side and inject them into the GPGPU, thus it is probably possible to create a mechanism for migration if needed.

2.6 Summary

This chapter presented basic definitions and concepts that are used through the rest of the dissertation. It also reviewed a few selected platforms for agent based modelling and simu-lation – their selections spanned from a general-purpose FIPA-based software, through simple simulation-centred solutions to mass-scale agent-based software frameworks.

(40)

The next chapter extracts the essential aspects of creating an agent model and the platform on the basis of the platforms presented here and on the experience of the author.

(41)

2.6. Su m ma ry 21

JADE Jadex MadKit Mason

Purpose Interoperability, BDI Active components Simulation Simulation

Execution model Thread-per-agent Event-driven Event-driven Event-driven

Ag-Ag comm. methods Messaging Messaging Messaging Method calls

Agent migration Yes Yes Possible Yes

Distributed comp. Yes (RPC, messaging) Yes Yes (sockets, messaging) Possible (messaging)

Heavy agents Yes Yes Yes Yes

Lightweight agents No No Yes Yes

Table 2.1: A short comparison of the discussed agent platforms. It

(42)

RePast Simphony RePast HPC Swarm FLAME GPU

Purpose Simulation Mass scale simulation Simulation Mass scale simulation

Execution model Event-driven Event-driven Event-driven Stream processing

Ag-Ag comm. methods Method calls Method calls Messaging Messaging

Agent migration Not needed Yes Not needed No

Distributed comp. No Yes (messaging) No Partially (HPC version)

Heavy agents No No No No

Lightweight agents Yes Yes Yes Yes

(43)

Chapter

3

Models for agent-based simulations

and computations

When creating an agent-based toolkit, a platform or a model we need to make several decisions about implementation models that will be used in our work. In this chapter, we discuss selected themes that show up commonly in various agent platforms.

Discussed topics include: Agent execution models

Methods of scheduling agents for execution of their code and how they can be run in parallel on CPUs is discussed in section 3.1.

Communication between agents

Three basic methods of communication between agents are discussed in section 3.2. Agent migration

Migration of agents between two environments is presented in section 3.3. Communication in distributed environments

As we are interested in distributed and parallel platforms, we separately discuss methods of communication between different physical nodes in a cluster in sec-tion 3.4.

Other aspects of distributed execution

Other decisions connected to building distributed systems are briefly presented in section 3.5.

Heterogenous execution environments

Models for GPGPUs and other hardware accelerators are discussed in section 3.6.

3.1 Agent execution models

Generally, execution models in multi-agent systems can be divided into two cases: 23

(44)

24 Chapter 3. Models for agent-based simulations…

i) thread-per-agent (1 ∶ 1), and

ii) thread pools for groups of agents (𝑚 ∶ 𝑛).

A notion of a thread that is used here requires an additional explanation, as the concept may mean very different things in different scenarios. In this chapter we discuss threads as a modelling concept that guarantees an independent execution of an agent. Thus, if an agent is allowed to posses a main loop, it usually will be modelled as a separate thread of execution.

Thread-per-agent

One of the natural ways to work with agents is to map each of them to its own separate (system) thread. In such a scenario, an agent usually has an internal main loop of execution and it has a full control over its own scheduling of actions (with respect to the operating system scheduler).

This is actually the ‘traditional’ way to talk about agent execution scheduling. For example, Wooldridge writes about multi-threading in multi-agent systems [108]:

‘[…] a multiagent system is inherently multi-threaded, in that each agent is assumed to have at least one thread of control.’ M. Wooldridge, 2009 Thus, it is a condition for an agent to be an independent entity executing within a system.

As a side note: this quote points out that agents can have more than one thread of control. We do not discuss this case because there is no difference from the thread-per-agent model when designing such a system. In thread-thread-per-agent model it is entirely possible for agents to start and control additional threads but there is still at least one controlling (main loop) thread for an agent.

This model is well-suited for a relatively small number of large, independent agents which perform heterogeneous tasks within a multi-agent system. Although modern operating systems can handle a large number of threads this comes with the assumption that most of the time these threads are idle, waiting on some kind of input/output. This assumption would not hold in the case of a simulation-oriented MAS where the execution of an agent is data-driven.

One of the well-known examples of this execution model is JADE [4, 3].

Thread pools

In this model multiple agents share a common thread pool and there are usually much more agents than threads in the pool. Execution of an agent in the pool may depend on multiple variables and different specifications. Two common situations where thread pools are used, are:

• event-driven execution, and • dataflow execution.

(45)

3.1. Agent execution models 25

A common problem with thread pools is scaling a number of threads to a number of agents. Many agents that are frequently scheduled for execution will require a significant number of threads for a simulation to run within the assumed time step.

Event-driven execution

With the event-driven execution, agents are scheduled to execute on threads in a thread pool when an event, that they are subscribed to, arrives. Usually, a specific method or function will be scheduled to be called when a specific event occurs. It may be, for example, an arrival of a message or an appearance of another agent in a close proximity to the current one. The time-based scheduling, where agent methods are executed at specified points of time, is also a kind of the event-driven execution in which events are fired by expiring timers.

A scheduling specification is usually provided directly in agent code or in a configur-ation. For example, a user could define that all cars in a traffic simulation perform their moves each second.

These scheduling methods are available, for example, in Repast Simphony [77]. The user can declare scheduling for agent methods using annotations – these methods can be executed at given time intervals or when some change occurs in the environment.

Some languages and libraries provide lightweight actors or green threads as tools to implement concurrent systems. These include, for example, Akka1_{actors and Erlang} lightweight processes. They are mostly event-driven, reactive and their communication is based on message passing. Although the event-based processing may occur in any model of execution, in these cases it is an inherent property of these systems.

In these models, agents are not executed with any particular scheduling and are not mapped to any specific thread group. Instead, they only ‘react’ to incoming events from other agents or from the environment.

Examples of using the fully actor-based execution are shown for example in works of Krzywicki [59, 60, 61].

Dataflow execution

In the dataflow model, the execution is modelled as a graph of operations that process a stream of data. Sometimes, in various contexts, it can also be called stream processing. The model is well-known from GPGPU languages such as OpenCL and CUDA.

When this model is used in multi-agent systems, a user needs to define small, reusable operations that transform a population of agents. These operations are then composed into a directed graph (a flow) and executed over the population transforming it into a new population.

With this model, similarly to the actor-based one, there is no specified scheduling or mapping of agents to threads. The population is split into separate threads, and a single operation is executed in these threads on each group of agents. It may be the same operation in all threads or different ones if there are no data dependencies between agents from different threads (that is, different threads may execute operations in the flow with

(46)

26 Chapter 3. Models for agent-based simulations…

different speed as long as agents in different threads do not need to exchange data – the flow is synchronized on the state of data). It is up to the runtime, to create threads needed to run the flow over the population. In some cases, it may use one thread for a whole population, or single thread per agent.

An example of such a model is presented in this dissertation. Simulated parallelism

This is a special case that uses simple agents with a short ‘execute’ method that is basically an inner part of the main loop. Agents are split into groups and each group is executed sequentially in a separate thread – a parent thread calls the ‘execute’ method of each agent, one after another (as shown in Algorithm 3.1). The executed method has to be short (in terms of computational time) and should be limited to a single step of an algorithm. This way, all agents within a group, are able to execute a single step of the algorithm time at the same moment. From a point of view of an agent, all agents execute their steps at the same time, thus the reason for calling it ‘simulated parallelism’. Different groups can be synchronized to keep the numbers of steps executed on each of them the same.

Require: agents is a set of simple agents with the execute method for step ← 1, … , 𝑛 do

for ag ← agents do

ag.execute()

end for end for

Algorithm 3.1:Agents in the simulated parallelism.

In some terms, this model is similar to thread pool but with constant assignments of agents to threads and inflexible scheduling. This kind of execution makes sense in cases where we have really big numbers of agents with short steps and we do not require more sophisticated scheduling. It may naturally occur in hierarchical agent models, where more complicated, thread-based agents use simpler agents to perform complex tasks.

This type of execution is used for example in AgE 2 [33].

3.2 Communication between agents

In this section, three methods of communication are described: i) message passing,

(47)

3.2. Communication between agents 27

iii) a blackboard.

Traditionally, message passing is the most often used method of communication between agents.

Message passing

Message passing is one of the most well-known ways for agents to communicate as it is a part of the FIPA specification. With this method, agents exchange messages that are some pieces of data (usually structured).

Message passing is a universal and flexible way of communication. In particular, it allows to flexibly specify messaging targets, for example:

• unicast targets, where a single agent is a receiver of messages,

• broadcast targets, where all agents within a system (or part of a system) receive a message,

• various types of multicast targets, where a subgroup of agents receives a message, • various types of anycast targets, where a single agent from a specified subgroup of

agents receive a message.

Multicast and anycast addressing can use various techniques for selecting agents. For example, selection by type – where only agents of a particular type are targets of messages. Unicast, besides selecting by an address of an agent, can use more sophisticated solutions. In MaDKit, selection by role can be used, where any agent that posses a given role receives a message.

It is also possible to specify different delivery semantics:

• with or without confirmation of receiving – a sender may be informed whether the message was received by a target,

• only for existing or also for future agents2_{– a sender may send a message to an agent} that will be present in the system in the future,

• in-order or out-of-order – whether messages will be delivered to the receiver in the same order they were sent.

The message passing can be also divided into synchronous or asynchronous versions. With the synchronous version, the sender sends a message and waits for a confirmation of receipt from another agent. In an asynchronous case, the sender continues its work after passing a message to an underlying transport mechanism.

A completely separate issue is the content of messages. It can be completely platform dependent or universal (for example FIPA ACL [79] or KQML [35]). Similarly, the format of messages may be binary (for example, instances of objects) or plain-text (for example, XML or JSON).