Efficient environment management for distributed simulation of large-scale situated multi-agent systems

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCEConcurrency Computat.: Pract. Exper. (2014)Published online 2014 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/cpe.3254

Efficient environment management for distributed simulation oflarge-scale situated multi-agent systems�

Franco Cicirelli*,†, Andrea Giordano and Libero Nigro

Laboratorio di Ingegneria del Software, Dipartimento di Ingegneria Informatica Modellistica Elettronica e Sistemistica(DIMES), Università della Calabria, 87036 Rende, Cosenza, Italy

SUMMARY

Multi-agent systems have been proven very effective for the modelling and simulation (M&S) of complexsystems like those related to biology, engineering, social sciences and so forth. The intrinsic spatial characterof many such systems leads to the definition of a situated agent. A situated agent owns spatial coordinatesand acts and interacts with its peers in a hosting territory. In the context of parallel/distributed simulation ofsituated agent models, the territory represents a huge shared variable that requires careful handling. Frequentaccess by agents to territory information easily becomes a bottleneck degrading system performance andscalability. This paper proposes an original approach to modelling and distributed simulation of large-scalesituated multi-agent systems. Time management is exploited for resolving conflicts and achieving dataconsistency while accessing the environment. The approach allows a simplification of the M&S tasks bymaking the modeller unaware of distribution concerns while ensuring the achievement of good scalabilityand performance during the distributed simulation. Practical aspects of the approach are demonstratedthrough some modelling examples based on Tileworld. Copyright © 2014 John Wiley & Sons, Ltd.

Received 20 April 2012; Revised 20 December 2013; Accepted 07 February 2014

KEY WORDS: situated multi-agent systems; distributed simulation; distributed spatial environment;composed logical time; actors; Java

1. INTRODUCTION

In the last few years, agent-based computing [1, 2] has gained a widespread consensus as apromising paradigm for the modelling and the simulation of systems composed of autonomous andreactive entities interacting to each other and with their environment, so as to predict a higher-levelemerging behaviour. Such systems are very often highly resource demanding and require paralleland distributed discrete-event simulation techniques [3] to be adopted for their analysis [4, 5].As a consequence, a model has to be split into a network of interconnected concurrent logicalprocesses (LPs) [3]. Each LP hosts a collection of agents and maintains and processes a portion ofthe simulation state.

A broad range of studied systems belonging to, for example, biology, sociology, wildfires,economy and engineering domains, naturally owns a spatial character, leading to the concept ofsituated agents [2, 6] where each agent possesses spatial coordinates and is embedded and operatesin a hosting environment (territory). Although there exists a general agreement about the importanceof spatial environments in multi-agent systems (MASs) [7–10], in many agencies (e.g. Jade orZeus), the environment either is not a built-in component or has responsibilities that are kept at aminimum [7].

*Correspondence to: Franco Cicirelli, Laboratorio di Ingegneria del Software, Dipartimento di Ingegneria InformaticaModellistica Elettronica e Sistemistica (DIMES), Università della Calabria, 87036 Rende, Cosenza, Italy.

†E-mail: [email protected]‡This paper is an extended version of previous authors’ work [41].

Copyright © 2014 John Wiley & Sons, Ltd.

F. CICIRELLI, A. GIORDANO AND L. NIGRO

In general, parallel/distributed simulation of MASs, particular modelling facilities, can berequired to face specific issues like concurrency and distributed coordination/cooperation and toregulate access to distributed resources [11]. In addition, there is the problem of handling thelarge state of the shared spatial environment, which is only loosely associated with any agent [4].The management of this shared state constitutes a bottleneck that limits the speedup that can beattained [4, 5].

The paper proposes an original approach to distributing large situated multi-agent models forhigh-performance simulation. In particular, the approach allows a simplification of the M&S tasksby making the modeller unaware of distribution issues while ensuring the achievement of goodscalability and performance during simulation.

The approach rests on the assumption that an agent can act upon all the territory, but usually, itprivileges the manipulation of the information located in its nearness (i.e. its neighbourhood). Tothis end, the concepts of visibility radius (VR) and action radius (AR) are introduced. Such radii aredesigned to delimit the area within which an agent can efficiently read and change the status of theterritory and the state of agents located in it.

The territory and the agent population are partitioned and distributed among multiple LPs.Agents are supposed to be able to communicate to one another only by exchanging asynchronoustimestamped messages (events), whereas both a synchronous and asynchronous access to territoryare supported. Each LP proceeds by processing one single event at a time, which always runs tocompletion. Messages generated during the execution of an event, together with those received fromother LPs, get buffered so as to be subsequently selected, dispatched and processed. The approach,by using a purposely developed notion on composed logical time (CLT), exploits time managementto resolve conflicts and to achieve data consistency. Mechanisms are implemented on top of theTHEATRE [12] architecture, which is based on a lightweight actor (agent) model of computation.The approach generalizes and improves the preliminary experience, which was carried out in thecontext of distributing sequential RePast models [13, 14].

The paper is structured as follows. Section 2 reports related work. Section 3 discusses prob-lems about the distribution of shared state in the context of situated MASs. Basic ideas underlyingthe proposed approach are then presented. Section 4 proposes mechanisms designed to ensuredata consistency and conflict management. Section 5 suggests the THEATRE architecture as asolution domain wherein the proposed mechanisms are implemented. Benefits of the approachand the achievable high execution performance are demonstrated in Section 6 through a casestudy centred on Tileworld [15]. Finally, conclusions are given with an indication of ongoing andfuture work.

2. RELATED WORK

Managing the environment in MASs is a multifaced problem. Many issues are related toenvironment representation and definition, agent–environment communication and interactionpatterns, distribution concerns, engineering practices and so forth [7–9]. Although environmentalaspects could be explicitly addressed by the modeller, it is more convenient to manage the environ-ment as a system-wide concept, thus promoting it as a first-class entity [10] directly provided bythe multi-agent infrastructure. Popular agent-based frameworks (e.g. Jade, Zeus, Jack or Retsina),though, often reduce the environment to a message transport layer or a brokering infrastructure [7].RePast is one of the few popular frameworks having built-in support for managing spatial environ-ments. However, its runtime allows only a sequential and centralized execution of modelled systems.Distributed simulation of such models still remains an open and challenging issue [13, 14].

Because the MAS community usually assumes that actions performed by multiple agents arecarried out in parallel [7], models for actions [2] are often required to clarify how agents may acton each other and on the environment. More in particular, problems related to the synchronization,the collisions and the ordering of their actions on the environment need to be addressed [8]. Acentralized synchronization mechanism has been proposed in [16]. A Cycle function is consideredalong with a global synchronizer. The synchronizer ensures that, at a given moment, all the agentsare treated as acting simultaneously. The environment reacts to such actions only subsequently.

Copyright © 2014 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. (2014)DOI: 10.1002/cpe

EFFICIENT DISTRIBUTED SIMULATION OF SITUATED MAS SYSTEMS

After that, the environment reactions can be perceived by the agents, which can influence again theenvironment and so forth in an endless loop.

In the domain of the distributed simulation of situated agents, the aspects to be managed areconnected not only to concurrency and data consistency but also to performance and data availabil-ity. An alternative to the centralized synchronization model described earlier is proposed in [17]where the concept of synchronization regions is introduced. This mechanism is used to resolve con-flicts among concurrent actions and to reduce synchronization cost in a distributed setting. A regionis a group of agents that act simultaneously and independently from other agents. Regions are deter-mined by a decentralized synchronization algorithm at the time the actions are performed. In eachregion, the effects of actions are then evaluated and applied.

Other approaches for managing environmental issues rely on the use of a tuple-based middleware.The TOTA middleware [18] exploits spatially distributed tuples, which are propagated across anetwork in order to implement diffusive spaces [13]. Tuples can be injected into the system fromany network node and can propagate and diffuse according to tuple-specific propagation patterns.Agents can sense the distributed tuples and decide how to react.

Object-places [19] support information sharing among agents in mobile and ad hoc networks.Agents can describe and enrich the environment with objects that can be temporarily stored acrosssuitable places. Agents invoke operations in order to add and remove objects or to observe the con-tent of a specific object-place. Despite other tuple-space approaches, which are usually synchronous,operations can be carried out efficiently because the interface to the space is asynchronous (i.e.operations do not block, and their result is returned when it is available).

In [20], the distribution of the shared state upon the LPs is based on the concept of spheres ofinfluence. Spheres of influence are dynamically determined on the basis of the mutual interactionsamong entities in the system. The goal is to distribute the shared state to favour nearness betweenan agent and the information that it requires during execution. In [21], shared data are maintainedin a tuple-space, and an optimistic simulation algorithm is adopted for driving the simulation. Thetuple-space is partitioned by following a hierarchical schema based on the spheres of influence so asto avoid bottlenecks in managing shared data. The same approach is exploited in [22] where rangequery operations are allowed on shared data.

An effort aimed at generalizing interactions between agents and the environment is based onthe concept of artifact [23]. An artifact is used as a first-class entity to represent anything ina MAS that is not modelled as an agent. Agents represent the proactive and autonomous com-ponents of the system, whereas artifacts are passive and reactive [9]. CArtAgO [24, 25] is aJava-based open-source software that provides development and runtime support to artifacts-basedcomputational environments. CArtAgO is orthogonal to the specific technology and languagechosen for programming the agents. Distribution concerns are transparently managed by the infras-tructure. Some high-level mechanisms and primitives are instead made available to deal withconcurrency issues.

In [26], an agent-based distributed architecture for the simulation of air-traffic systems is pro-posed. Handling of spatial data is achieved by partitioning the territory and allocating each singlepartition to a different LP. A partition, along with the agents situated on it, determines the workloadof an LP. No details are provided about the strategy used to ensure data consistency and to avoidconflicts on shared data, for example, those occurring when different agents located on different LPstry to modify the same spatial data.

In this paper, a CLT notion is used for handling conflicts and to ensure data consistency. The useof a composed-time notion is not new in the field of computer simulation [3]. The goal is mainly toprevent causality-constraint violations among events and to favour simulation repeatability [27–30].In [31], the notion of super-dense time is used to implement an optimistic simulation algorithmfor DEVS models. This time notion is given by the set of non-negative real numbers plus a natu-ral number used as the second field. Simultaneous events have equal timestamps, and sequences ofzero-time events are ordered by the clock’s second field. The use of super-dense time allows a reduc-tion of rollbacks by ensuring that causally dependent input–output events will always have differenttimestamps. In [32], a triple-based time notion is used in order to implement a tie-breaking mecha-nism for simultaneous events and to enforce, through a step field, phase alternation between event



generation and event processing during a distributed simulation. This time management schemamakes the step field of the logical time very close to the granule concept introduced in [33]. In [34],a particular time model is used for the distributed simulation of deliberative agents. Simulation anddeliberative activities are executed concurrently. The overall time is given by the composition of thevirtual time of the simulation infrastructure and the time horizon reached by planning agents. Thesimulation proceeds only if the time used by the deliberative process exceeds the current time stepin simulation time.

To the best of the authors’ knowledge, the novelty of the approach proposed in this paper, isthe use of a CLT notion to guarantee a conflict-free execution of agents competing for resourcesdeployed over a territory. The way the logical time is determined is novel too. The approachmakes it possible to achieve a good simulation performance by avoiding the recourse to locks andsynchronization primitives when acting upon shared data.

3. DISTRIBUTING SPATIAL ENVIRONMENTS

A situated agent is embedded into a spatial environment (territory) and acts and interacts withthe space surrounding it. Interactions between agents and the territory can be asynchronous orsynchronous. Both communication models challenge us to ensure consistency and atomicity in adistributed and parallel scenario without wasting performance.

For example, let us consider two agents that compete for an exclusive use of a resource situatedin the territory. In the asynchronous scenario, firstly, an agent has to send a read message to theenvironment in order to know the status of the resource (e.g. available or busy); then the environmentreplies to the agent with the status of the resource. On receiving an availability message, the agentsends a write message in order to turn the status of the resource from available to busy. In case tworead messages are received and replied before a write one, two availability messages are delivered,thus leading the system into an inconsistent state (i.e. the resource is incorrectly acquired by bothagents). By adopting a synchronous communication schema, it is possible to avoid the exchange ofmessages, thence reducing the runtime overhead. Moreover, modelling activities are simplified inthat it is not required to adopt a send-wait for reply communication model. However, the problemtied to consistency still holds. In fact, it remains to be ensured that some sequences of read/writeoperations must be executed atomically.

In a parallel/distributed context, the territory is a huge shared variable of a concurrent system. Arecurrent access by agents to the territory can become a bottleneck that limits system performanceand scalability. The territory can be allocated to a single LP or can be partitioned on multiple LPs.The first approach implies that the scalability of the system is constrained by the memory of the LPthat contains the territory.

In the approach proposed in this paper, the spatial environment is arranged as a two-dimensionalgrid, which is statically split into spatial regions (see Figure 1 for a possible partitioning schema).Each region is allocated to a different LP [12, 26]. In addition, each situated agent is allocated to theLP that manages the region it belongs to. Naturally, splitting the space among different LPs requiresagent migration when an agent moves from a region to another.

Space Local LP Space

Figure 1. Environment space partitioning.



3.1. The problem of distributed shared state

The global state of a situated MAS comprises the states of agents and the state of the territory. Whenwe view the territory as a grid of cells, the status of the territory is the union of the states of itscells. Even if an agent could be able to perceive and act upon the state of the entire environment,more often, it only needs to read in and write on its neighbourhood. The neighbourhood of an agentlocated in a certain cell can be defined in terms of a VR and an AR centred on that cell. Visibilityand action radii refer respectively to read and write operations.

Operations inside the neighbourhood and operations outside it are explicitly distinguished. In thefollowing, we describe some mechanisms that provide an efficient execution of operations in theneighbourhood by using a synchronous approach even in a distributed scenario. In Section 4.4, theapproach is extended to support neighbourhood outside operations in an asynchronous way.

Splitting the space ensures that if the agent’s neighbourhood entirely falls within a single region,local synchronous access remains guaranteed. When the agent’s visibility or AR falls outside thelocal region, remote read/write operations and coordination among LPs are required. To avoid suchremote operations, the edge portion of a region is replicated in adjacent LP(s), that is, the LP(s)that manage contiguous regions of space. Such a portion is referred to as a border of the region. InFigure 2(a), the grey part highlights border areas of a territory split between two LPs.

The border area is made up of two distinct parts (Figure 2(b)): a local border, locally managed bythe LP, and a mirror border, which is a replica of the adjacent LP local border part. Agents locatedin a border area, along with their states, are also mirrored. Each agent located in a local border partis reflected in the mirror border part of an adjacent LP through a proxy version of itself (Figure 3).

The width of both local and mirror borders is set to the maximum of visibility and action radii.This ensures that, within the neighbourhood, read/write operations will be performed locally, thatis, in the same LP where the agent resides.

Region partitioning obviously creates problems of keeping consistency in border areas. An updateto a boundary local cell must also be reflected in the mirror part of an adjacent LP. A second prob-lem concerns conflict resolution during concurrent accesses to shared space cells by border agents

Local LP 0

Shared LP 0 Shared LP 1

Local LP 1

(a) Border areas of two adjacent LPs

Local LP 0

Local border LP 0

Mirror border LP 0 (Local border LP 1)

Mirror border LP 1 (Local border LP 0)

Local border LP 1

Local LP 1

(b) Detailed view of border areas

Figure 2. Boundary regions.

4

7

8

10

1

6

2

11

9

531

6

2

11

LP1 LP2

agentproxy

Figure 3. An agent distribution among adjacent logical processes (LPs).



executing in different LPs. In the approach proposed in this paper, such problems are solved by amechanism based on the use of a CLT notion as described in the following.

3.2. A mechanism for conflict resolution

As was previously stated, the management of the border area of a region represents a critical designissue. Every state change in a local border needs to be reflected in the mirror side of a neighbourLP. A state update can purposely be actualized at a proper time, thus guaranteeing data consistencyduring simulation. Furthermore, a border area must be guarded against conflicts as explained in thefollowing.

For the sake of simplicity, the following examples refer to a scenario in which each territory cellcan host one agent only. Therefore, a conflict exists among agents, which would decide to move tothe same cell at the same time.

In Figure 4(a), a scenario with a cell conflict is shown. A naive solution to prevent conflicts couldbe that of statically establishing an execution order among agents deployed over a border area. Sucha solution suffers from two drawbacks. First, agent ordering would imply an unfair system evolutionwhere some agents are always preferred with respect to others. A second problem would be a poorexploitation of the MAS intrinsic parallelism. Indeed, as shown in Figure 4(a), not all agents are inconflict with each other. Multiple agents can be allowed to move at the same time. For example, inFigure 4(a), agents A and B are completely independent from the others.

A more complex scenario is portrayed in Figure 4(b), where the AR is 1. Highlighted are cellsupon which agents can conflict with one another. In the right side of Figure 4(b) is portrayed apossible consistent advancement of the simulation where agents have moved, at the same time,without causing conflicts. Figure 4(c) shows the portion of space shared by agents when the AR is 2.

Potentially conflicting agents have a nonempty intersection between their spheres of actions, thatis, the spheres determined by the action radii. It is easy to see that the spheres of actions of twoagents have an intersection when the two agents have a distance from each other less than or equal to2�AR. To prevent conflicts while favouring parallelism among the agents, each agent can be taggedby a conflict-free number (CFN) that satisfies the following conflict-free assumption: two agentsbelonging to different LPs and that are distant less than or equal to 2 � AR must be flagged with

A

B

C

D

E F

(a) Potentially conflicting agents (b) An example of conflict resolution

LP1 LP2LP1 LP2 LP1 LP2

LP1 LP2

(c) Conflicting agents whenaction radius is 2

Figure 4. Conflicting scenarios.



a different CFN. The conflict-free assumption ensures that potentially conflicting agents will havedifferent CFNs. The use of CFNs introduces a partial order on agent executions, which preventsconflicts.

Conflict-free numbers are assigned to agents on the basis of their spatial positions. As a con-sequence, each cell owns its proper CFN. The CFN of an agent can be determined by adoptinga cell-oriented repetitive pattern that satisfies the conflict-free assumption. For example, Figure 5depicts a pattern where the AR is 2. Agents located in the cells having CFN D 4 cannot con-flict with one another. In these cells, indeed, there can be no agents belonging to different LP(s)that are far from each other by less than or equal to 2 � AR. To avoid the occurrence of privilegedpositions and thus unfair agent executions, the pattern is shuffled as the simulation time goes on.Shuffling is achieved by using a pseudo-random generator that takes the virtual time as seed. Allof this ensures that, without exchanging coordination messages, the CFN assignment algorithm,executed at both sides of a boundary region and at the same virtual time, remains deterministicdespite shuffling. An offset, agreed upon by the LPs and randomly determined at the start of a sim-ulation, can be added to the seed in order to change the sequences of shuffling during differentsimulation runs.

3.3. Generation of CFN patterns

Many different CFN patterns that satisfy the conflict-free assumption can be devised. To exemplify,patterns may differ from each other for the allowed set of CFNs and the frequency with which eachvalue is repeated in the borders of adjacent LPs. A simple scenario is highlighted in Figure 6(a)where only two values are exploited. In Figure 6(b), a different number for each cell is considered.None of these two patterns, though, is really convenient to use because agents located in adjacentLPs cannot concurrently execute. In addition, the second pattern will imply a higher level ofsynchronization among the LPs (Section 4).

The problem of generating a CFN pattern can be related to the graph colouring problem. How-ever, the adoption of a graph-based algorithm would deliver a CFN pattern like that shown inFigure 6(a). This is because the resulting graph corresponding to a CFN assignment problem isa bipartite graph where the two kinds of nodes are the conflicting cells in the border area of two

Figure 5. A conflict-free number repetitive pattern.



action radius = 1

(a)

LP1 LP2 LP1 LP2

action radius = 1

1

12

2

1

12

2

1

122

1

1

2

2

1 2

1

3

2

4

5

7

6

8

9

11

10

12

13

15

14

16

1718

(b)

Figure 6. Simple conflict-free number patterns.

adjacent LPs, which need different CFN values. Therefore, only two colours would suffice for thecolourability, thus impairing agent concurrency.

A good pattern should be adaptable to different action radii and should do the following: (i)minimize the cardinality of the set of admitted numbers in order to reduce synchronization amongLPs and (ii) augment the frequency of each used number, while making such a frequency as equalas possible among the LPs, so as to increase agent concurrency and fairness. One such pattern isnot tied to any specific simulation scenario, and as a consequence, it is exploitable in a generalsimulation context.

The generation of CFN patterns is a combinatorial problem whose complexity depends on thecardinality of the set of allowed numbers and the chosen AR. Developing algorithms for buildingoptimal CFN patterns is a challenging yet interesting issue that deserves further research. The goalin this paper, though, is to determine and adopt one such good pattern and evaluate its effectivenessin a simulation infrastructure.

The actual CFN pattern adopted in this work was established by using a backtracking-basedalgorithm and by fixing the cardinality of the admitted numbers to eight. With the problem beingintrinsically intractable, a higher value for the cardinality makes the algorithm practically unusable,whereas a lower value does not favour achievement of a good pattern.

The algorithm enumerates all the admissible patterns, and a score is attached to each of them bytaking into account the goodness of the pattern, that is, the score augments as the frequency of eachused CFN increases. Patterns having different frequencies of the same CFN on different LPs arediscarded.

The adopted pattern was selected among the highest scored patterns. In the following it is indi-cated the derived formula that reproduces the chosen pattern. Let s be the array containing theadmitted CFNs. The function f used to index s is

f .x; y; r/ D

ˇˇˇˇ

y%8r

4r�x%2r

r

ˇˇˇˇ� 4C

y%4r

2r� 2C .x C y/%2 (1)

that is,

CFN.x; y; r/ D sŒf .x; y; r/� (2)

where r is the AR, .x; y/ denotes a cell position in the border area and integer division is assumed.The pattern spans over 2r columns and repeats each 8r rows. Pattern shuffling follows frompermutations of s.



In case the AR is set to 2 and s is set to Œ0; 1; 2; 3; 5; 6; 7; 8�, f generates the same pattern reportedin Figure 5.

4. A TIE-BREAKING MECHANISM BASED ON TIME MANAGEMENT

In distributed simulation [3], time management is in charge of keeping a coherent virtual time (alsosaid logical or model time) advancement among the various LPs. The virtual time defines a partialorder execution of events in which events marked with the same time can potentially be processedin any order. In the proposed approach, time management is based on a conservative algorithm andon the use of an CLT notion. CLT is an expanded version of the logical time made up of the virtualtime plus other information (fields). The goal is to enforce a particular execution order among eventshaving the same model time so as to guarantee conflict resolution and data consistency during thedistributed simulation. The model remains unaware of the added fields, whereas the entire CLTconstitutes the ‘logical time’ from the time management point of view.

4.1. The CLT in its basic version

Composed logical time is a number that in binary can be viewed as the concatenation of two slots:the virtual time in the most significant slot and the CFN (Section 3.2) in the least significant one(Figure 7).

The timestamp of an event scheduled to be processed by an agent at a given virtual time t isdefined as a composed logical time where the slot of virtual time is set to t and the CFN is com-puted as described in Section 3.3. As a consequence, a tie-breaking mechanism is ensured amongsimultaneous events, that is, scheduled to occur at the same virtual time. The CLT defines a newpartial order among events, which always guarantees that potentially conflicting agents will notact concurrently.

4.2. Consistency among updates: adding the step field

In order to keep information on border regions aligned, changes occurring in a local border of anLP are gathered in a single update message subsequently sent to the LPs containing the relativemirror parts. To avoid the processing of stale data, update messages have to be actualized beforethe agents potentially influenced by such updates undertake a new action. As a consequence, anupdate occurring at CLT0 D ŒVirtualTime0jCFN0�must be reflected just before reaching any CLT00 DŒVirtualTime00jCFN00� such that CLT00 > CLT0. To guarantee this, a further step field is added to theCLT (Figure 8). It is worth noting that the conflict-free assumption guarantees that agents runningat CLT0 are surely not interested in these update messages.

A step is a bit field set to 1 only for the update messages (0 otherwise). More particularly, givena state change occurring at a specific virtual time and CFN (i.e. CLT D ŒVirtualTimejCFNj0�), thetimestamp of the relevant update message is marked with a CLT having the same virtual time, thesame CFN and a step slot set to 1.

Virtual time CFN

CLT

Figure 7. Basic structure of the adopted composed logical time (CLT).

Virtual time CFN

CLT

Step

Figure 8. Composed logical time (CLT) with the step field.



Virtual time CFN

CLT

StepEpoch

Figure 9. Final structure of composed logical time (CLT).

4.3. Multiple events at the same virtual time: adding the epoch slot

The so-far-described CLT is not yet enough to ensure a coherent and consistent model evolution inthe general case. For example, let us consider the case where an agent, with AR set to 1, movesfrom cell to cell on receiving a tick event. If two tick events are received at the same CLT, the agentbehaves by moving to two cells at the same time, thus violating its AR. To avoid this problem, onlyone event must be processed by an agent at the same CLT. Towards this, a further field epoch isadded to the CLT. If an agent has already processed an event at a given CLT, the next event at thesame CLT must be scheduled to occur at the next epoch. The final structure of the CLT is portrayedin Figure 9. The epoch field is essential also when an agent sends an immediate event (i.e. at thesame virtual time) to an agent marked with a smaller CFN. To avoid scheduling events in the past,the epoch slot is incremented again.

4.4. Neighbourhood outside operations

Read/write operations occurring out of the visibility/action radii are referred to as neighbourhoodoutside operations. Extending the approach described earlier by considering all the territory as‘neighbourhood’ would imply that the entire simulation has to become sequential. In fact, in order tosatisfy the conflict-free assumption, only one single LP at time would be able to process a message.In addition, extending the visibility area all over the territory would imply an increase in the bordersize until the whole territory on each LP is replicated, despite the adopted partitioning schema. Asa consequence, a huge amount of update operations would be executed.

Neighbourhood outside operations are managed asynchronously through the use of suitableread and write messages that are exchanged among agents and the environment. Atomicity onasynchronous read/write operations (Section 3) is obtained by using again the CLT without resortingto an explicit locking mechanism. Messages among agents and the environment are scheduled witha CLT in which CFN is set to a specific reserved value so as to avoid conflicts between neighbour-hood outside/inside operations. In the case multiple agents belonging to distinct LPs refer to thesame cell at the same virtual time, a different value of the epoch field is used to ensure atomicity ofoperations. In particular, a specific epoch value is assigned to each involved agent. Given an agent,the assigned epoch value remains unchanged for all the operations concerning the same cell at thesame virtual time, thus guaranteeing atomicity.

5. IMPLEMENTATION

The mechanisms described in Sections 3 and 4 allow both the use of a cooperative, threadless modelof concurrency in a distributed context and a synchronous access to distributed shared data withoutusing message passing. In order for the mechanisms to become really usable, a suitable frameworkwas developed in the context of the THEATRE multi-agent architecture [12]. Offered APIs werespecifically designed to better exploit the features of the proposed mechanisms and to abstract awayall the aspects relevant to programming in a distributed and concurrent scenario. THEATRE relies ona lightweight notion of actors supporting the agent metaphor. First, basic concepts of THEATRE andactors are surveyed, and then a description of the realized framework is provided.

5.1. An overview of THEATRE

A system [12] consists of a collection of execution sites named theatres. Each theatre providessystem-wide features, that is, the services supporting actor execution, migration and interactions. Inthe following, the THEATRE agency is supposed to be hosted by Java.



Actors (agents) capture the application business logic. THEATRE actors are a variant of the actormodel [35]: they are reactive threadless objects that encapsulate a data state and communicate toone another by asynchronous message passing. Messages are typed objects. Actors are at rest untila message arrives. Message processing is atomic: it cannot be suspended nor preempted. Messageprocessing represents the unit of scheduling and dispatching. Actors have a behaviour based ona finite state machine or ‘distilled’ statechart [36]. User-defined actor classes derive directly orindirectly from the actor base class. Similarly, message classes derive from the message base class.Each theatre computing node is equipped with the following components: an instance of the JavaVirtual Machine, a control machine, a transport layer, a local actor table and a network class loader(Figure 10).

The NetworkClassLoader is responsible for obtaining dynamically and automatically the class ofan object (e.g. a migrated agent) by retrieving it from a network remote codebase server. The Trans-portLayer furnishes the services for sending/receiving network messages and migrating agents.When moving to a different theatre, an actor leaves on the originating theatre a forwarder of itself(i.e. a proxy), which serves to redirect incoming messages to the current known location of the actor.The LocalActorTable contains references to local agents of the theatre. The ControlMachine hoststhe runtime executive of the theatre, with basic services of message scheduling/dispatching thatregulate local actors. Control machines in a THEATRE system coordinate with each other in order toensure a global synchronization strategy. In the following, a conservative synchronization structure[3, 12] that is based on the High-Level Architecture (HLA) [37] is assumed.

The HLA is a standard middleware for distributed simulations aiming at facilitating the reuseand the interoperability among (possibly heterogeneous) simulations. It centres on the concept offederation, which is composed of a certain number of federates. A federate is a single simulatormodelling a portion of a larger simulation. A theatre (LP) naturally maps to an HLA federate. Inthis paper, HLA is used as a transport layer and for exploiting its time management service only.The logical time presented to HLA is the CLT as described in Section 4.3.

5.2. Implementing spatial environments on top of THEATRE

The THEATRE architecture was extended by supplying an implementation of spatial environments(Figure 11) as first-class entities. A special actor named ActorEnv is introduced per LP, whichis devoted to implementing the mechanisms previously described in this paper. A suitable modelinterface (API) is provided through which agents can access/modify the territory. In addition, thecontrol machine was customized to handle the composed logical time notion described in Section 4.All burdens related to the management of CLT and update messages are completely hidden fromthe modeller.

Each ActorEnv has the responsibility of administrating the local portion of the territoryallocated to its hosting LP and of transparently handling the following: (i) communication withother ActorEnv(s) and (ii) agent migration in case an agent moves in a territory portion allocated

Figure 10. Snapshot of a THEATRE system. JVM, Java Virtual Machine.



Figure 11. A simplified UML class diagram of a customized THEATRE infrastructure.

to a different LP. Actors interact with the local ActorEnv for both neighbourhood inside/outsideread/write operations. Read/write operations refer to the shared state of the whole environment. Thisshared state is composed of the state of each cell (i.e. the actors located on it) along with the sharedstate of the agents. An agent can share some of its variables through the environment.

Neighbourhood outside operations are concretely implemented by a message exchange amongactors and the ActorEnv. The message interface of the ActorEnv comprises four kinds ofmessages:

� Read: used to read the content of a neighbourhood outside cell of the territory� Write: used to situate or move an agent in a neighbourhood outside cell or to change the shared

state of a neighbourhood outside agent� ContentMsg: the reply to a read message containing the list of actors located in the read cell

along with the relevant shared agent status� WriteSucceeded: the reply to a write message. It allows an agent to continue its behaviour after

a write operation

For neighbourhood inside operations, the ActorEnv furnishes a view of the neighbourhood ofan agent through objects that implement the Neighbourhood interface (Figure 12).

The software engineering process underlying the design of the realized framework is also devotedto foster robustness by limiting errors during the modelling activity. For example, requesting theneighbourhood does not require the specification of the identity of the requesting actor (Figure 15).ActorEnv is in charge of retrieving such an identity by querying the THEATRE runtime infras-tructure. This avoids a malicious and guideless use of the Neighbourhood. The main methodsof the Neighbourhood interface are shown in Figure 12. The use of ActorMatcher andCellMatcher interfaces (also Figure 11) simplifies neighbourhood exploration by allowing thespecification of application-dependent filtering criteria. A matcher is required each time an actoraccesses the content of a single cell or the content of the whole neighbourhood. Such interfacesoffer a single boolean method match, which is automatically used by the runtime infrastructure fordetermining, during territory exploration, which cells and cell content are of interest.

It is worthy to note that the API in Figure 12 makes the modeller completely unaware of distribu-tion concerns. The modeller, however, remains in charge of carefully choosing the size of visibilityand action radii. For example, reducing the size of the radii increases the number of neighbourhoodoutside operations, while using a larger size implies the management of a greater number of updatemessages. The values of these radii are established during the configuration phase. In this phase, thepartitioning schema of the territory is also specified.

6. A TILEWORLD MODEL

The following describes a concrete M&S experience based on the developed actor-based implemen-tation of spatial environments. The chosen example is concerned with Tileworld [15]. A territory



Figure 12. The neighbourhood interface.

with tiles, holes and obstacles (Figure 13) is defined. Agents are able to move upon the territoryin order to pick up tiles and subsequently use them to fill holes. Tiles and holes appear and dis-appear randomly. When a tile is picked up by an agent, it disappears definitively. When a hole istotally filled, it disappears definitively as well. Each hole has an associated score and a depth value.An agent gets a reward each time it completely fills a hole. An agent explores the territory towardsdetecting both visible tiles and holes while avoiding surrounding obstacles. Visible holes, tiles andobstacles are perceived when they fall in the visibility area of an agent.

Two different cases were considered to give evidence about the modelling benefits and goodsimulation performance achievable by exploiting the developed framework. The first case dependson the proposed approach. The modeller can thus be focused on the business logic of its situatedagent model without being distracted by distribution concerns. The process of defining agents’behaviour is simplified because, by using the ActorEnv-offered API, the interactions with thesurrounding environment (despite partitioning) are carried out in a synchronous way (i.e. throughmethod calls) without resorting to send/reply messages.

In the second case, a different Tileworld model is developed, which does not make use of theproposed approach but still relies on the THEATRE/HLA architecture and the actor model of compu-tation. It is now the responsibility of the modeller to take into account the issues related to conflictmanagement and territory partitioning. In particular, a lock-based mechanism is used to enforce



Figure 13. A Tileworld board.

consistency on distributed shared data. Moreover, all the operations involving remote entities areaccomplished by message passing.

In both cases, the territory is split among LPs, and the Tileworld models consist of the followingentities: TileWorldActors modelling agents moving around the environment; TileActors,HoleActors and ObstacleActors modelling respectively tiles, holes and obstacles. Thespatial environment is directly provided by the ActorEnv in the first case. In the second case, anentity managing the territory (TerritoryMGR) and another one managing locks (LockMGR) arepurposely designed and implemented. In the following, for simplicity, only the behaviour of theTileWorldActor agent is detailed.

It is useful to note that Tileworld is often used as a benchmark for testing MASs. A comparisonof the achievable performance using the infrastructure/approach proposed in this paper with that ofsimilar models reported in the literature, especially based on HLA-related technology, would be ofvalue. Existing approaches, though, are different in the adoption of specific hardware/software set-tings (e.g. workstations, local area network infrastructures and HLA implementations). Each of themexploits a different agent-based runtime environment (i.e. agencies) and uses a particular implemen-tation of Tileworld agents owning a specific behaviour. In [34, 38, 39], for instance, are reportedbenchmarks based on Tileworld that use a lower number of entities with respect to the number ofagents used in this paper. This is mainly due to the fact that THEATRE actors are very lightweight innature. As a consequence, carrying the comparison is very difficult from a practical point of view.

6.1. The Tileworld model with implicit environment management

The statechart depicted in Figure 14 captures the behaviour of a TileWorldActor thatcan find itself in one of four states, namely LOOK_FOR_TILE/LOOK_FOR_HOLE andMOVE_TO_TILE/MOVE_TO_HOLE. Activities are triggered by the use of a self-sent timedmessage StepMsg. On receiving such a message, the actor explores its neighbourhood to look for atile/hole or moves towards a previously sighted tile/hole. Processing StepMsgs drives forward thesimulation. Such messages are scheduled with a timeout value ensuring that an agent always moveswith the speed of one cell per time unit (Figure 15). In case the visibility area (neighbourhood) ofa TileWorldActor is empty, the method doAWeightedRandomStepWalk is used to establish thenext position to take according to a weighted random walk, which gives a probabilistic preferenceto the direction chosen by the actor in the previous step. The method headTowardTarget, instead, isused to do a step walk towards an engaged target by following a line-of-sight trajectory. A tile ora hole is reached when it falls within the AR of the tile world agent. Other details of the statechartshould be self-explanatory.



Figure 14. Statechart of a TileWorldActor.

Figure 15 shows the actual code of the TileWorldActor relevant to the MOVE_TO_HOLEstate, that is, when the actor is moving (with a tile) towards a previously sighted hole. The avail-ability of an engaged hole is evaluated through the variable visible that each hole owns and sharesthrough the environment. The TileWorldActor directs itself towards an engaged hole as long asit remains visible. When the hole falls within the AR of the TileWorldActor, the hole is filledby decrementing its depth shared variable. If the depth becomes zero, the hole is first made invisibleby setting its visible variable to false, and then the TileWorldActor’s score is increased.Finally, the actor switches to the LOOK_FOR_TILE state. If the engaged hole disappears, the actorchanges to the LOOK_FOR_HOLE state. In such a case, the StepMsg is scheduled without a timedelay to reflect the following: (i) no actions and movements have been made by the actor in theMOVE_TO_HOLE state and (ii) the activity of finding another hole can be started immediately.

The use of ActorEnv and the Neighbourhood interface offers a comfortable yet safe man-agement of shared data. The model is developed as if it would be simulated in a sequentialcentralized context. For example, the depth variable is decremented without considering that otheragents could perform the same operation concurrently. It is also transparently guaranteed that onlyone agent can gain a hole score, that is, only one agent atomically decreases the hole depth tozero and makes the hole invisible. Moreover, in a distributed context, no agent will operate onstale information regardless of its position over the territory. The operation of removing a filledhole is accomplished synchronously without caring if the entity is local or remote. Finally, duringmodelling, it is not required to take into account actor migration, which is implicitly handled byActorEnv.

6.2. The Tileworld model with explicit environment management

A TileWorldActor behaves in two different ways depending on its position upon the partitionedterritory. In case the actor neighbourhood comprises cells allocated to a different LP, the agent,before acting, has to lock the cells intersecting with a conflicting area. A lock is negotiated with thelock manager (LockMGR). After its use, a lock must be released in order to avoid deadlock or toavoid impairing activities of other agents.

Exploration of cells allocated on adjacent LPs is achieved by sending an exploration message tothe territory manager (TerritoryMGR). An exploration result is then awaited as part of a replymessage. Picking up tiles and filling holes are performed again by message passing in case thetarget agents are remote. An explicit migration is requested when an actor moves from an LP to



Figure 15. A code excerpt of the TileWorldActor relevant to the MOVE_TO_HOLE state.

another. When a TileWorldActor acts out of its territory borders, its behaviour is identical tothat reported in Figure 14.

Figure 16 shows the behaviour of a TileWorldActor in the most complex case, that is, whenthe actor is on a border area and the target hole/tile is remote. The statechart makes it clear thateach time a StepMsg is received (see the group transition between the ACTING and PREPARINGstates), regardless of the owned state, the agent sends a LockRequest to the lock manager.Following a LockGrant, the actor asks the territory manager for an ExploreResult messagecontaining a snapshot of the visible territory. The agent then comes back to the state owned justbefore asking for the lock (see the use of the history connector H on the transition outgoing theWAIT_FOR_LOCK state). In the ACTING state, the behaviour is similar to that shown in Figure 14except for the following: (i) activities are triggered by ExploreResult messages; (ii) the ownedlock needs to be released after each activity; (iii) each time a pickup/fill message is sent to a tile/hole,a DoneMsg (i.e. a commit) is awaited before releasing the lock.

6.3. Simulation settings

Some simulation experiments were carried out by using a toroidal territory of 1200�2700 cells ran-domly populated by an equal number of TileWorldActors, TileActors and HoleActorsalong with a fixed number of 10 000 ObstacleActors. The time a tile/hole remains visible into



Figure 16. New version of the TileWorldActor statechart.

a cell is uniformly distributed in [1. . . 50] time units (tu). The reappearance time for a tile/hole isuniformly distributed in [1. . . 20] tu. Both scores and depths for holes are uniformly distributed in[1. . . 4]. During a distributed simulation, the CFN pattern is determined by applying formulas 1 and2 reported in Section 3.3 and s is set to Œ0; : : : ; 8�. The model was equally split among a variablenumber of LPs/federates. An equal number of LPs/federates, ranging from one to three, is allocatedon to three WinXP (32 bit) Intel i7 CPU 960, four cores, 3.20 GHz, 3-GB RAM, interconnected bya gigabit ethernet switch in the presence of HLA pRTI 1516 [40]. Since the territory is a torus, eachregion has two adjacent LPs. Such a property also holds when augmenting the number of LPs. Cen-tralized simulations were performed by considering one LP on a single computational node, withoutthe use of HLA and by disabling the management of both CFNs and borders.

Three different scenarios were considered: a variable-load scenario, a constant-load scenarioand a comparative scenario. The first two refer to the Tileworld model served by implicit terri-tory management. In particular, the first scenario is used to extract the performance of the proposedapproach/infrastructure versus a variable population of TileWorldActors. The second scenariois devoted specifically to characterizing the infrastructure overhead in managing CFNs, borders andupdate messages. The third scenario, finally, compares simulation performance of the two Tile-world models, that is, with/without automatic territory management. All the simulation results wereobtained as the mean value of three runs. In order to assess the reliability of the simulation results,confidence intervals were evaluated. By using Student’s t -distribution and a 95% level of confidence,the obtained confidence intervals are NX ˙ � NX where NX is the mean value of the three simulationruns and � is at most 0:05.

6.4. The variable-load scenario

A variable population ranging from 1000 to 250 000 of TileWorldActors was considered. Dif-ferent configurations for the VR and AR were used. This means, for instance, that an AR set tok > 1 makes a TileWorldActor able, in a single move, to pick up a tile or fill up a hole locatedk cells far from its position. All of this aims to evaluate how the infrastructure behaves when, froma modelling point of view, agents with different acting/sensing capabilities are employed.

Each simulation run lasts until all the TileWorldActors ‘complete’ their mission. A missionis assumed to be completed when 99% of the tiles are put into holes. The percentage of 99%,instead of 100%, was chosen because experimentally it was found that it minimizes variability inthe completion time of each configuration of a given population and VR/AR.

The wall clock time (WCT) of a simulation run is influenced by the number of time units neededto complete the mission (missionTime). As a consequence, the value of WCT was normalized withrespect to the mission time (normalized WCT D nWCT D WCT=missionTime).



Simulation results showed in Figures 17–19(b) are obtained by considering three LPs, one foreach workstation. In particular, Figure 17 portrays the achieved simulation speedup versus the num-ber of Tileworld actors, whereas Figure 18(a,b) shows the observed nWCT versus the number ofTileworld actors. As one can see from Figure 18(a,b), particularly for the distributed scenario, theWCT increases in a fairly linear way with respect to the agent population, thus witnessing a goodscaling of the model and of the THEATRE-based simulation framework.

Speedup augments as the number of TileWorldActors grows (Figure 17). The curves sharplyincrease as the number of actors varies from 1000 to 50 000, thus exhibiting some efficiency evenwith a moderate load. Different trends for the speedup emerge when the agent population is fixedand the AR and VR values are varied. In case a constant number of 250 000 TileWorldActorsis used, the achieved speedup, as one might expect, increases as both AR and VR reduce(Figure 19(a)). With a constant number of 100 000 TileWorldActors, the achieved speeduptends to diminish as both AR and VR reduce (Figure 19(b)).

1.0

1.2

1.4

1.6

1.8

2.0

2.2

2.4

2.6

2.8

1 50 100 150 200 250

Sp

eed

up

(3

LP

s)

Number of TileWorldActor(s) (thousand)

AR=3 VR=10

AR=1 VR=30

AR=1 VR=10

AR=3 VR=30

Figure 17. Speedup versus the number of TileWorldActors.

0

5

10

15

20

25

1 50 100 150 200 250No

rmal

ized

Wal

lclo

ckT

ime

[sec

./t.u

.]

No

rmal

ized

Wal

lclo

ckT

ime

[sec

./t.u

.]

Number of TileWorldActor(s) (thousand) Number of TileWorldActor(s) (thousand)

AR=1 VR=10

Centralized

Distributed (3 LPs)

(a)

1 50 100 150 200 250

AR=3 VR=30

0

20

40

60

80

100

120

140

(b)

Centralized

Distributed (3 LPs)

Figure 18. Wall clock time versus the number of TileWorldActors.

2.47

2.51

2.55

2.59

2.63

2.67

AR=3VR=30

AR=1VR=30

AR=3VR=10

AR=1VR=10

Sp

eed

up

(3

LP

s)

250k TileWorldActor(s)

(a)

2.25

2.31

2.37

2.43

2.49

2.55

100k TileWorldActor(s)

(b)

AR=3VR=30

AR=1VR=30

AR=3VR=10

AR=1VR=10

Sp

eed

up

(3

LP

s)

Figure 19. Speedup versus action radius (AR) and visibility radius (VR) values.



Curves in Figure 19(a,b) can be motivated by considering that in the variable-load simulationscenario, a variation in AR and VR significantly modifies the behaviour of the simulated model and,therefore, the model load factor. In fact, by comparing Figure 18(a) and (b), the following emerges:(i) the normalized WCT required to execute a single simulation time unit is strongly related to theAR/VR values; and (ii) the curves of the normalized WCT in the centralized context, which onlydepends on the model load factor, are different. In addition, during each single simulation run, themodel load factor is not constant because the number of deployed tiles and holes upon the territorydiminishes while the TileWorldActors are completing their mission.

In Figure 20, the observed speedup versus a variable number of LPs and a given agent popula-tion is reported. A scenario of respectively one, two and three LPs/cores for each workstation wasconsidered. The number of TileWorldActors varied from 1000 to 250 000. From the curves, itresults that the speedup augments as the population of actors grows and the number of LPs increases.With respect to Figure 17, the achievable speedup in Figure 20 shows a more strict dependence withthe agent population. This is because the overhead for managing borders and CFNs increases as thenumber of LPs augments, whereas the specific load of each LP obviously reduces as the numberof LPs increases (i.e. it reduces as the model partitioning increases). As a consequence, to obtain agood speedup, a greater number of agents is required. For brevity, only the scenario with AR D 1and VR D 10 is reported. Good scaling, though, was confirmed also by other configurations of ARand VR.

6.5. The constant-load scenario

A fixed population of 150 000 TileWorldActors was adopted. Different values for VR and ARwere used while configuring the ActorEnvs. These values affect border areas, update messagesand CFN values. However, in order to highlight the infrastructure overhead, the model was operatedwith a constant intrinsic load factor. To this end, during simulation, each TileWorldActor usesa value for such radii fixed to 1. Moreover, each time a tile is picked up from the territory, a new tilereappears, and as soon as a hole is filled, the just-filled hole is replaced by a new empty one. Thenormalized WCT is reported in Figure 21(a,b). Here, only the distributed simulations were takeninto account. Indeed, simulations carried in the centralized scenario exhibit a constant value for thenormalized WCT versus AR/VR values, thus confirming a constant model load factor.

Obtained speedup is depicted in Figure 22(a,b). As expected, the speedup monotonically reducesas both the VR and AR augment. However, performance variations remain very limited despite thevariations of the radii. By comparing the two figures, it follows that performance is more influencedby a variation in the AR. This is mainly due to the way the CLT is defined and managed. In fact,when a message is sent, the CLT of the message cannot be fully determined. Its CFN slot dependson the position (not known a priori) owned by the recipient actor at the moment the message isreceived. As a consequence, messages to actors on a conflicting area may need to be rescheduledaccording to the corresponding CFN value. Obviously, by increasing the AR, the probability ofmessage rescheduling increases as well.

1

2

3

4

5

6

7

8

3 6 9

Sp

eed

up

Number of LP(s)

AR=1 - VR=10

250k

200k

150k

100k

50k

1k

Figure 20. Speedup versus the number of logical processes (LPs).



0.98

1.00

1.02

1.04

1.06

1.08

1.10

1.12

VR

=5

VR

=50

VR

=100

VR

=150

VR

=200

No

rmal

ized

Wal

lclo

ck T

ime

[sec

./t.u

.]

No

rmal

ized

Wal

lclo

ck T

ime

[sec

./t.u

.]

150k TileWorldActor(s) - 3 LPs - AR=5

1.05

1.10

1.15

1.20

1.25

1.30

1.35

1.40

AR

=5

AR

=50

AR

=100

AR

=150

AR

=200

150k TileWorldActor(s) - 3 LPs - VR=200

(a) (b)

Figure 21. Wall clock time versus action radius (AR) and virtual radius (VR) values.

2.00

2.05

2.10

2.15

2.20

2.25

2.30

VR

=5

VR

=50

VR

=100

VR

=150

VR

=200

Sp

eed

up

(3

LP

s)

150k TileWorldActor(s) -AR=5

(a)

1.601.651.701.751.801.851.901.952.002.05

AR

=5

AR

=50

AR

=100

AR

=150

AR

=200

Sp

eed

up

(3

LP

s)

150k TileWorldActor(s) -VR=200

(b)

Figure 22. Speedup in the constant-load scenario.

1

3

5

7

9

11

13

15

17

19

1 50 100 150 200 250

Sp

eed

up

Number of TileWorldActor(s) (thousand)

AR=3 VR=10

AR=1 VR=30

AR=1 VR=10

AR=3 VR=30

Figure 23. Speedup versus the number of TileWorldActor(s) (comparing the two Tileworld models).

6.6. The comparative scenario

Only distributed simulations using three LPs were considered. Model parameters are those describedin Section 6.4. Figure 23 shows the speedup evaluated by dividing the normalized WCT(s) mea-sured by simulating the model with the explicit territory management, by the normalized WCT(s)achieved on the other model. A higher speedup reflects a higher efficiency of the proposedapproach/infrastructure with the implicit territory management.

Figure 23 confirms that the speedup highly depends on the chosen AR/VR. As the number ofdeployed TileWorldActors increases, the speedup reduces. This mirrors that the model with



explicit territory improves its execution performance by having a greater load factor (see alsoFigure 17). The model without ActorEnvs behaves worse as the VR increases. This is due tothe management of the ExploreResult messages whose payload augments with a greater VR.In addition, the number of cells locked by each agent augments with VR because more locks arerequired on cells intersecting the agent neighbourhood and the borders. By fixing VR, the speedupdiminishes as the AR increases. This is because, as AR increases, an actor needs less to move acrossthe territory to complete its mission, and therefore, both ExploreResult messages and lockrequests reduce.

From the experiments, it emerges that in no case did the model with explicit territory managementoutperform that based on ActorEnvs. In the case of explicit territory management, multiple opti-mizations and tuning activities could be devised for gaining performance. Smart strategies could beemployed to augment specifically model concurrency, for example, by improving lock management,or to reduce the number of exchanged messages. For instance, the Explore/ExploreResultmessages could be grouped into bags whereas useless ExploreResult messages conveyingoverlapping contents could be avoided. Obviously, enforcing the finest optimizations will corre-spondingly increase the complexity of the LockMGR and that of the TerritoryMGR actors.However, developing effective optimization strategies can be very hard from the modelling pointof view. A main objective of this work is to demonstrate that the proposed approach is capableof completely relieving the modeller from taking care of the aspects related to the distributionand optimizations. Delivering good performance remains an issue of the underlying simulationinfrastructure only.

7. CONCLUSIONS

This paper proposes a novel approach to distributing shared spatial environments in MASs. Sharingspatial environments is challenging because it requires a large shared state to be carefully handled.The approach reduces inter-LP communications and uses a time-based mechanism that ensures dataconsistency and conflict management among competing situated agents. The goal is an exploita-tion of the high degree of parallelism that is normally available in agent-based systems and asimplification of territory management.

The proposed mechanisms were implemented on top of the THEATRE [12] agent-based architec-ture. The approach facilitates modeller activities by hiding distribution concerns. In addition, it iscapable of ensuring good model scalability and good simulation performance. Benefits provided bythe developed approach to distributed simulations were assessed by comparing the execution per-formance of two variants of a large Tileworld model, one of which is customized and does not makeuse of the realized features.

Ongoing and future work are geared at the following:

� extending the Tileworld model so as to test more complex strategies for territory explorationand path-finding schema, for example, by exploiting the A* searching algorithm� experimenting with the use of the infrastructure in large and highly dynamic systems, for

example, inspired by biology or social science� evaluating the adoption of special data structures enabling a more efficient access to informa-

tion contained in the territory� improving the ActorEnv interface by allowing a more fine-grained read/write control upon

shared data� studying and evaluating algorithms for generating CFN patterns� experimenting with dynamic partitioning schemes so as to increase/reduce the region assigned

to a specific LP on the basis of its actual workload� generalizing territory management, for example, by adopting hexagonal space cells, continuous

spaces, diffusive spaces and n-dimensional spaces� optimizing the framework implementation for multicore clusters, for example, by avoiding

object serialization during message passing among LPs allocated on the same workstation.



REFERENCES

1. Wooldridge M. An Introduction to Multi-agent Systems. John Wiley & Sons, Ltd.: London, UK, 2002.2. Ferber J. Multi-agent Systems: An Introduction to Distributed Artificial Intelligence. Addison Wesley Longman:

Boston, MA, USA, 1999.3. Fujimoto RM. Parallel and Distributed Simulation Systems. John Wiley: New York, NY, USA, 2000.4. Logan B. Evaluating agent architectures using simulation. Evaluating Architectures for Intelligence: Papers from the

2007 AAAI Workshop, AAAI Press, Vancouver, British Columbia, Canada, 2007; 40–43. Technical Report WS-07-04.5. Pawlaszczyk D, Strassburger S. Scalability in distributed simulations of agent-based models. Proceedings of Winter

Simulation Conference (WSC), Austin, TX, USA, 2009; 1189–1200.6. Bandini S, Manzoni S, Simone C. Dealing with space in multi-agent systems: a model for situated MAS. Proceed-

ings of the 1st Int. Joint Conference on Autonomous Agents and Multiagent Systems, New York, NY, USA, 2002;1183–1190.

7. Weyns D, Van H, Parunak D, Michel F, Holvoet T, Ferber J. Environments for multiagent systems: state-of-the-artand research challenges. Proceedings of the 1st International Workshop on Environments for Multi-Agent Systems(E4MAS), LNAI, vol. 3374, Springer, Utrecht, The Netherlands, 2005; 1–47.

8. Platon E, Mamei M, Sabouret N, Honiden S, Parunak HVD. Mechanisms for environments in multi-agent systems:survey and opportunities. Autonomous Agents and Multi-Agent Systems 2007; 14(1):31–47.

9. Kesaniemi J, Terziyan V. Agent-environment interaction in MAS - introduction and survey. In Multi-Agent Systems- Modeling, Interactions, Simulations and Case Studies, Alkhateeb F (ed.). IN-TECH Publishing: Vienna, Austria,2011; 203–226. ISBN: 978-953-307-176-3, (Chapter IX).

10. Weyns D, Omicini A, Odell J. Environment as a first class abstraction in multiagent systems. Autonomous Agentsand Multi-Agent Systems 2007; 14(1):5–30.

11. Gasser L, Kakugawa K, Chee B, Esteva M. Smooth scaling ahead: progressive MAS simulation from single PCs togrids. Proceedings of the International Conference on Multi-Agent and Multi-Agent-Based Simulation, MABS’04,Springer-Verlag, Berlin, Heidelberg, 2005; 1–10.

12. Cicirelli F, Furfaro A, Nigro L. An agent infrastructure over HLA for distributed simulation of reconfigurable systemsand its application to UAV coordination. SIMULATION: Transactions of The Society for Modeling and SimulationInternational 2009; 85(1):17–32.

13. Cicirelli F, Giordano A, Furfaro A, Nigro L. HLA_ACTOR_REPAST: an approach to distributing RePast models forhigh-performance simulations. Simulation Modelling Practice and Theory 2011; 19(1):283–300.

14. Minson R, Theodoropoulos GK. Distributing RePast agent-based simulations with HLA. Concurrency and Compu-tation: Practice and Experience 2008; 20(10):1225–1256.

15. Pollack ME, Ringuette M. Introducing the Tileworld: experimentally evaluating agent architectures. Proceedings ofNational Conference on Artificial Intelligence, Boston, Massachusetts, USA, 1990; 183–189.

16. Ferber J, Mauller JP. Influences and reaction: a model of situated multi agent systems. Proceedings of SecondInternational Conference on Multi-Agent Systems, Kyoto, Japan, 1996; 72–79.

17. Weyns D, Holvoet T. A formal model for situated multi-agent systems. Formal Approaches for Multi-Agent Systems,Special Issue of Fundamenta Informaticae 2004; 63(2):125–158.

18. Mamei M, Zambonelli F. Programming pervasive and mobile computing applications with the TOTA middleware.Proc. of the International Conference on Pervasive Computing (Percom), Orlando, Florida, USA, 2004; 263–273.

19. Weyns D, Schelfthout K, Holvoet T. Exploiting a virtual environment in a real-world application. Proceedingsof Second International Workshop Environments for Multi-Agent Systems (E4MAS 2005), LNCS, vol. 3830,Springer-Verlag, Berlin, Heidelberg, Utrecht, The Netherlands, 2005; 218–234.

20. Logan B, Theodoropoulos G. The distributed simulation of multiagent systems. Proceedings of the IEEE 2001;89(2):174–185.

21. Lees M, Logan B, Minson R, Oguara T, Theodoropoulos G. Modelling environments for distributed simulation.Proceedings of the 1st International Workshop on Environments for Multi-Agent Systems (E4MAS)), LNAI, vol. 3374,Springer, Utrecht, The Netherlands, 2005; 150–167.

22. Suryanarayanan V, Minson R, Theodoropoulos G. Synchronised range queries in distributed simulations of multi-agent systems. Proceedings of the IEEE/ACM 14th International Symposium on Distributed Simulation and RealTime Applications (DS-RT ’10), Washington, DC, USA, 2010; 79–86.

23. Ricci A, Viroli M, Omicini A. Programming MAS with artifacts. Programming Multi-Agent Systems, LNCS,vol. 3862, Springer-Verlag, Berlin, Heidelberg, 2006; 206–221.

24. CARTAGO. (Available from: http://cartago.sourceforge.net/) [Accessed on 10 December 2013].25. Ricci A, Viroli M, Piunti M, Omicini A. Environment programming in CArtAgO. Multi-Agent Programming:

Languages, Platforms and Applications 2009; 2:259–288.26. Šišlák D, Volf P, Jakob M, Pechoucek M. Distributed platform for large-scale agent-based simulations. Agents

for games and simulations: Trends in techniques, concepts and design, LNCS, vol. 5920, Springer-Verlag, Berlin,Heidelberg, 2009; 16–32.

27. Lamport L. Time, clocks and the ordering of events in a distributed system. Communications of the ACM 1978;21(7):558–565.

28. Ronngren R, Liljenstam M. On event ordering in parallel discrete event simulation. Proceedings of ThirteenthWorkshop on Parallel and Distributed Simulation (PADS), Atlanta, GA, USA, 1999; 38–45.


http://cartago.sourceforge.net/


29. Baldoni R, Raynal M. Fundamentals of distributed computing: A practical tour of vector clock systems. IEEEDistributed Systems Online 2002February; 3(2):1–18.

30. Zeng Y, Cai W, Turner SJ, Zhou S, Lee B-S. Characterization and delivery of directly coupled causal messages indistributed systems. Future Generation Computer Systems 2004; 20:171–178.

31. Nutaro J. On Constructing optimistic simulation algorithms for the discrete event system specification. ACMTransactions on Modeling and Computer Simulation 2008; 19(1):1–21.

32. Cicirelli F, Furfaro A, Nigro L. Actor-based simulation of PDEVS systems over HLA. Proceedings of 41st AnnualSimulation Symposium (ANSS’08), Ottawa, Canada, 2008; 229–236.

33. Zeigler BP, Ball G, Cho H, Lee JS, Sarjoughian HS. Implementation of the DEVS formalism over the HLA/RTI:problems and solutions. Proceedings of Simulation Interoperation Workshop (SIW), Orlando, FL, 1999.

34. Uhrmacher AM, Gugler K. Distributed, parallel simulation of multiple, deliberative agents. Proceedings of the Four-teenth Workshop on Parallel and Distributed Simulation, PADS ’00, IEEE Computer Society, Washington, DC, USA,2000; 101–108.

35. Agha G. Actors: a model of concurrent computation in distributed systems. MIT Press: Cambridge, MA, USA, 1986.36. Cicirelli F, Furfaro A, Nigro L. Modelling and simulation of complex manufacturing systems using statechart-based

actors. Simulation Modelling Practice and Theory 2011; 19(2):685–703.37. Kuhl F, Dahmann J, Weatherly R. Creating Computer Simulation Systems: An Introduction to the High Level

Architecture. Prentice Hall: Upper Saddle River, NJ, USA, 2000.38. Lees M, Logan B, Theodoropoulos G. Distributed simulation of agent-based systems with hla. ACM Transactions on

Modeling and Computer Simulation 2007; 17(3):11.39. Chen D, Theodoropoulos GK, Turner SJ, Cai W, Minson R, Zhang Y. Large scale agent-based simulation on the

grid. Future Generation Computer Systems 2008; 24(7):658–671.40. pRTI 1516, on-line. (Available from: http://www.pitch.se/prti1516/default.asp) [Accessed on 9 December 2013].41. Cicirelli F, Giordano A, Nigro L. Distributed simulation of situated multi-agent systems. Proceedings of the

IEEE/ACM 15th International Symposium on Distributed Simulation and Real Time Applications, Washington, DC,USA, 2011; 28–35.


http://www.pitch.se/prti1516/default.asp

Documents

Efficient environment management for distributed simulation of large-scale situated multi-agent systems