DESMO-J

The discrete event simulator DESMO-J (see e.g. Page et al., 2000, Ch. 10) is a strongly ex-tended and re-designed object-oriented Java implementation of the Simula library DEMOS (Birtwistle, 1979). It oers support for event scheduling, process interaction, and combined models. Transaction- and activity-oriented models are mapped to process interaction mod-els with specic synchronization constructs such as resources. DESMO-J furthermore oers constructs for queues, statistical data-collectors, a congurable reporting system, and a simula-tion infrastructure based on the conceptual separasimula-tion of models and experiments (see Secsimula-tion 2.4.1). A simple Desktop- and Web-based graphical user interface to congure, run, and observe experiments is also included (Kiesel, 2004).

3.4.4.2. Agents in FAMOS

Though MABS is often understood as an extension of process interaction, agents in DESMO-J are technically based on event-oriented constructs. The reasons for this design decision are performance (since every simulation process employs an own Java thread) and better suitability for asynchronous event handling (Page and Kreutzer, 2005, p. 363).

Figure 3.10 shows the structure of a FAMOS agent (see also Knaak, 2002, Sec. 5.2.1): As an extended entity, it actively handles so-called signals. These are either received from other agents (external signals) or self-scheduled as future intentions (internal signals). Pending signals are stored chronologically on an 'inner' schedule, which is encapsulated from the environment as opposed to the global event list of DESMO-J (Page and Kreutzer, 2005, p. 363).

Figure 3.10.: Integration of FAMOS agents into the framework DESMO-J (adopted with modica-tions from Knaak et al., 2002). Figure and caption cited from (Page and Kreutzer, 2005, p. 365).

When the agent receives a signal, it dequeues and handles all signals that are scheduled for the current simulation time. This can cause the execution of actions (encapsulated in methods) and the addition of new signals (i.e. intentions) to the schedule. Finally, an external agent activation event is scheduled on DESMO-J's global event list for the time point of the rst (earliest) signal on the internal schedule.

To allow for exible behavior modeling, the actual handling of signals is delegated to a behavior module that is derived from an abstract base class Behaviour. As indicated above, this design is rather common in agent modeling. Similar to MadKit or JADE, dierent techniques for behavior modeling are supported by sub-classes of Behaviour. FAMOS currently includes the following modules (Knaak et al., 2002):

• A simple event-oriented behavior merely declares two abstract methods to implement reactions to signals and pro-active initial actions.

• A process-oriented behavior runs in a thread and provides methods for process synchroni-sation (such as hold) and signal handling. This module is rather similar to the standard agent behaviour in MadKit (see Section 3.4.2).

• The state machine encapsulates an interpreter for hierarchical and concurrent UML state charts. It is basically a modied version of the state chart framework from the open source CASE tool Fujaba²⁵ (Köhler, 1999). Implementation details and a comparison with Fujaba are provided in (Knaak, 2004). The domain-specic part of the state chart code is generated from XML scripts built with an included graphical editor.

• The rule engine encapsulates the JESS forward chaining rule interpreter for declarative modeling, quite similar to the integration of JESS into MadKit (see Section 3.4.2).

Dierent from behavior architectures in some agent platforms, the internal scheduler of a FAMOS agent does not run in an own thread. While this improves the performance of models with many agents, it complicates the implementation of dynamic deliberative architectures. As in MadKit, a FAMOS agent is equipped with one xed behavior module. The architecture could be extended to a dynamic plan execution environment by using the composite pat-tern (Gamma et al., 1995) similar to JADE. A possible design is sketched by Knaak (2002, Sec. 5.3.4). Czogalla and Matzen (2003) implemented a simple deliberative architecture to simulate the goal-directed behavior of passengers boarding an airplane.

3.4.4.3. Agent-Based Models in FAMOS

The main component of a FAMOS model is the environment that serves as a container for all agents. Furthermore it provides access to a communication infrastructure, a group-based organizational structure, and an optional spatial model.²⁶

The standard communication infrastructure is rather simple: transfer of signals is assumed to be instantanious and error-free. It could, however, be exchanged with a more complex implementation that e.g. simulates transfer durations and failure probabilities according to random distributions (Knaak, 2002, p. 87).

The organizational structure is based on the AGR model as implemented in MadKit. Dierent from the standard version, FAMOS supports the hierarchical embedding of groups reminiscent of the seminal MABS framework Swarm (Minar et al., 1996). In fact, this makes the role concept dispensable at the implementation level because roles contained in a group can be mapped to sub-groups. For compatibility, a subclass RoleGroup that supports roles is also included.

Groups can receive signals that they broadcast to all contained agents. They furthermore provide means for the functional referencing of contained agents similar to SeSAm (see Section 3.4.3).

As a main focus, FAMOS provides an extensible framework to model spatial structures and dynamics (i.e. agent movement and environmental processes). Spatial structures are represented in terms of abstract positions and connecting links. This abstract representation is realized by dierent topologies. FAMOS currently includes graph-based models and dierent kinds of

25http://www.fujaba.de, last visit 2012-09-17

26The following description is based on (Knaak, 2002, Secs. 5.2.3, 5.5).

regular and irregular grids (Meyer, 2008). Czogalla and Matzen (2003) implemented a 'vector-based' continuous model to represent cabin layouts of airplanes.

The movement of agents is realized by dierent movement strategies. These strategies determine how and when an agent moves between dierent positions of the spatial topology. Available movement strategies include random walk, gradient following, and movement along previously planned routes (Page and Kreutzer, 2005, p. 364). Due to the abstract spatial representation, movement strategies can in principle be re-used with dierent spatial topologies.

Besides agents, arbitrary objects implementing a certain interface can be located in the spatial environment. For each agent, the environment manages an individual horizon of perception and action, and the agent can query the environment for observable objects. The environment can also manage groups that agents automatically enter and leave when they reach certain spatial positions. Dynamics of environmental properties can be represented by macroscopic modeling constructs from DESMO-J such as events.

For the observation of agents, a variant of the probe concept from Swarm is used. DESMO-J provides so-called access points²⁷that provide a uniform interface to arbitrary object properties (Page and Kreutzer, 2005, p. 364). FAMOS includes a statistical observer (class Individual-Observer) that observes the access points of a set of agents. The results are displayed by the DESMO-J reporting system as tables, and common statistical quantities are computed over numerical properties.

3.4.5. Capa Agent Platform

Capa (Duvigneau, 2003) is an agent platform built on top of the Java-based Petri net simulator Renew (Page and Kreutzer, 2005, p. 361) described in Section 2.3.2.5. It is a fully FIPA-compliant re-implementation of the Mulan architecture (Section 3.3.3.1) realized with refer-ence nets and Java code. Thisprovides an explicit and easily understandable architecture for both platform and agent models (Page and Kreutzer, 2005, p. 362). The FIPA compatibility allows Capa to interact with other FIPA platforms such as JADE (Section 3.4.1).

Capa includes a number of additional visual development tools that support the dierent phases of the Paose approach:

• Net components for protocol nets and decision components are provided as additional toolbars in the Renew IDE.

• An editor for use case diagrams is embedded into Renew to document the results of the coarse design phase. From these diagrams a generator can build a new development project skeleton including folder structure and diagram templates (Cabac et al., 2007, p. 41).

• Another Renew plugin allows to draw AIP diagrams of agent interactions. These are automatically mapped to protocol net templates for every participant of the communica-tion. To implement an executable agent, the user lls these templates with Java code for elementary agent actions (Cabac et al., 2007, pp. 44).

27the term was adopted from the work by Bachmann (2003)

• R/D-diagrams are drawn with a Renew plugin called knowledge base editor. From the diagrams the tool generates so called role descriptions that can be integrated into knowl-edge bases of agents. Functionality to manage and start multi-agent applications is oered as well (Cabac et al., 2007, p. 43).

• Ontology diagrams are either created with the external tool Protege²⁸ or by using the feature structure (FS) plugin of Renew. Both tools also oer (at least experimental in the latter case) Java code generators (Cabac et al., 2007, p. 43).

The main tool to debug applications developed with Capa is the Mulan Viewer (Cabac et al., 2008b, Sec. 3). It provides a tree-structured view on the state of the platform according to the four levels of the Mulan architecture (Cabac et al., 2008b, p. 403). Starting from this view, it is possible to inspect the markings of all involved nets. A hierarchical inspection of net tokens and a UML-like display of data tokens is also possible (Cabac et al., 2008b, p. 404).

Furthermore the Mulan Viewer provides basic functionality to control agents and log ACL messages (Cabac et al., 2008b, p. 404). A dedicated message monitoring tool named Mulan Snier was developed in the context of this thesis and is described in Section 7.4.1.