Testing BDI-based Multi-Agent Systems using Discrete Event Simulation

TL;DR

This paper discusses how the control flow of BDI agents can be mapped onto a Discrete Event Simulation (DES), showing that such integration is possible at different degrees of granularity, and that different granularities in mapping BDI agents over DESs may lead to different degrees of fidelity.

Abstract

Multi-agent systems are designed to deal with open, distributed systems with unpredictable dynamics, which makes them inherently hard to test. The value of using simulation for this purpose is recognized in the literature, although achieving sufficient fidelity (i.e., the degree of similarity between the simulation and the real-world system) remains a challenging task. This is exacerbated when dealing with cognitive agent models, such as the Belief Desire Intention (BDI) model, where the agent codebase is not suitable to run unchanged in simulation environments, thus increasing the reality gap between the deployed and simulated systems. We argue that BDI developers should be able to test in simulation the same specification that will be later deployed, with no surrogate representations. Thus, in this paper, we discuss how the control flow of BDI agents can be mapped onto a Discrete Event Simulation (DES), showing that such integration is possible at different degrees of granularity. We substantiate our claims by producing an open-source prototype integration between two pre-existing tools (JaKtA and Alchemist), showing that it is possible to produce a simulation-based testing environment for distributed BDI} agents, and that different granularities in mapping BDI agents over DESs may lead to different degrees of fidelity.

Figures (8)

• Figure 1: Graphical representation of the AgentSpeak(L) architecture for BDI agents.
• Figure 2: Granularities for atomic BDI events. Yellow arrows are causal links. In AMA (light green) an event is a run of all control loops of the whole MAS; it implicitly synchronises all agents. In ACLI (emerald) an event is a single control loop iteration of a single agent, preventing phase interleaving. In ACLP (dark purple), single control loop phases of every agent can interleave. ABE is not shown as it is indistinguishable from ACLP at the agent level.
• Figure 3: Mapping JaKtA BDI abstractions onto Alchemist ones. Each Alchemist Node represents a physical device running a centralised JaKtA MAS. Simulation of distributed MAS is achieved having multiple Nodes in the same environment that communicate via Alchemist's Linking Rules. Each agent's control-loop is implemented as an Alchemist Reaction, with a custom TimeDistribution for each phase. Agents can act on and perceive Alchemist's molecules in the environment.
• Figure 4: Code extracts from the companion artifact. The agent specification (left) is completely platform-agnostic and reusable, some glue code (right) wires the logics with the underlying execution platform.
• Figure 5: Simulation snapshots for the three cases: AMA (left), ACLI (centre), and ACLP right for $\tau=0.6$. Every UAV is depicted with a different colour, the leader is the red one. The follower UAV count has been reduced to six for better visualisation. Color intensity captures the distance in time, more intense colors are closer to the current time. In AMA, all UAV follow a circular trajectory intersecting the leader's one. The formation is much less regular in ACLI, and it is completely lost in ACLP, showing that failing to capture the model nuances correctly may produce systems that work because of the abstraction gap.