Improving domain-independent intention selection in BDI systems

Abstract

The Belief Desire Intention (BDI) agent paradigm provides a powerful basis for developing complex systems based on autonomous intelligent agents. These agents have, at any point in time, a set of intentions encoding the various tasks the agent is working on. Despite its importance, the problem of selecting which intention to progress at any point in time has received almost no attention and has been mostly left to the programmer to resolve in an application-dependent manner. In this paper, we implement and evaluate two domain-independent intention selection mechanisms based on the ideas of enablement checking and low coverage prioritisation. Through a battery of automatically generated synthetic tests and one real program, we compare these with the commonly used intention selection mechanisms of First-In-First-Out (FIFO) and Round Robin (RR). We found that enablement checking, which is incorporated into low coverage prioritisation, is never detrimental and provides substantial benefits when running vulnerable programs in dynamic environments. This is a significant finding as such a check can be readily applied to FIFO and RR, giving an extremely simple and effective mechanism to be added to existing BDI frameworks. In turn, low coverage prioritisation provides a significant further benefit.

Appendices

Appendix 1: Synthetic domain details

We provide here further details on how the synthetic testbed used in Sect. 4 was produced.

1.1 Goal-plan trees

The goal-plan trees induced by the agent’s plan library can be considered perfect binary trees which have had selected branches “pruned” in order to create coverage gaps. We define the depth of a goal-plan tree according to the maximum depth to which subgoals are posted. The top-level goal is at depth 0, a plan relevant to a goal at depth $d$ is also at depth $d$, and subgoals posted by plans at depth $d$ are at depth $d+1$.

1.2 Gap levels

If a goal-plan tree has a gap level at depth $d$, then for every subgoal $!G$ at depth $d$ there is at least one possible world state where $!G$ has no applicable plan. These coverage gaps are modelled on p-effects, i.e., $!G$ is handled by a single plan, $!G : \phi \leftarrow \delta$, and its context condition $\phi$ is set to true in the plan which posted $!G$. The top-level goal has no coverage gaps, so in a tree with depth $d$ any gap layers must be exist between depths 1 and $d$. So, if a goal-plan tree has a depth of $d$ and $g$ gap levels, the number of possible combinations of gap layers is $\left( {\begin{array}{c}d\\ g\end{array}}\right) = \frac{d!}{(d-g)!g!}$.

In these experiments an agent is tasked with achieving 10 top-level goals, each of which can be decomposed into a binary goal-plan tree with a maximum depth of 4, and 2 gap levels. There are therefore 6 possible combinations of gap levels available. In order to have an even distribution of such structures, the gap layers in each of the ten goal-plan trees is randomly selected before each test.

1.3 Setting the coverage

The procedure for setting the coverage of a binary goal-plan tree is shown in Algorithm 1. As can be seen, it is a random, recursive process which sets the coverage of the top-level goal by setting the distributions of the context conditions of the various plans which occur in the tree. The random element ensures that even if two top-level goals have the same coverage, and the goal-plan trees beneath them have the same depth and the same gap layers, the coverage gaps within the trees will still be different.

1.4 Test steps

For each test, the following steps are performed:

• 1. Ten different top-level goals are randomly selected from the agent’s library.

• 2. A random coverage level $c \in [0.01, 0.99)$ is selected.

• 3. The coverage of each of the Ten top-level goals is set to $c$.

• 4. A random environmental dynamism level $d \in [0.0, 1.0)$ is selected.

• 5. The initial state of the environment is set by resampling each environment variable, as per each probability distribution. This state is then saved.

• 6. For each intention selection mechanism being tested:

  • (a) The Ten top-level goals selected in step 1 are posted, and the results of the agent runs are recorded.

  • (b) The environment is re-set to the state saved in step 5.

Appendix 2: Tower of Hanoi agent design

The standard Tower of Hanoi puzzle consists of three pins, $p_A$, $p_B$ and $p_C$, and $n$ discs, $d_1, d_2, \ldots , d_n$, numbered according to their size, with $d_1$ being the smallest and $d_n$ the largest. In the game’s initial state, all of the discs are placed on to pin $p_A$ in order of size, i.e., with disc $d_n$ at the bottom of the stack and $d_1$ at the top. The goal-plan tree structure used by the agent to solve a single instance of the Tower of Hanoi is shown in Fig. 9. In our tests, the agent is tasked with solving several Tower of Hanoi instances simultaneously. Therefore, at any point in time, the agent’s intention base may comprise several partially-executed instances of this intention.

The goal-plan tree’s top-level goal, ${ SolveTower }$, is handled by a single plan, ${ SubDivide }$, which divides the Tower of Hanoi problem into a series of smaller sub-problems. The branch stemming from the plan ${ RecursiveSolution }$ is a BDI implementation of a recursive solution to the Tower of Hanoi, while the alternative branch, ${ PathPlanningSolution }$, solves the tower by searching the state-space and planning a sequence of moves. We will now describe each component of the goal-plan tree in more detail (note that when referring to discs, $d_n$ will always refer to the largest disc, while all other subscripts denote variables).

1.1 Moving discs

The goal ${ MakeMove(d_k, p_x, p_y) }$ is posted by the agent whenever it needs to move disc $d_k$ from pin $p_x$ to pin $p_y$, and is handled by a single plan, the primitive action ${ MoveDisc }$. The context condition of ${ MoveDisc }$ first checks that the move is legal, i.e., that disc $d_k$ is at the top of $p_x$, and is smaller than the disc at the top of $p_y$. It then checks that the move is available, given the constraints imposed by the current state of the tower engines. If these conditions hold, then the plan will be selected and the disc moved, if not, then the ${ MakeMove }$ goal will have no applicable plans.

1.2 Solving sub-problems

The traditional solution to the Tower of Hanoi is recursive, i.e., to solve a tower of $n$ discs, it first solves a tower of $n-1$ discs. The base case, a tower of just one disc, can be solved trivially. The plan ${ SubDivide }$ sub-divides a Tower of Hanoi into sub-problems in a similar way. The aim of this plan is to stack discs $d_n, d_{n-1}, \ldots , d_1$ (where $d_n$ is the largest and $d_1$ the smallest) on to pin $C$. To achieve this it first attempts to stack $d_n$ on to $p_C$, and then both $d_n$ and $d_{n-1}$, etc. The subgoal ${ SolveSubTower(d_k) }$ represents the need to create a stack of discs, $d_n, d_{n-1}, \ldots , d_k$, on to $p_C$. ${ SubDivide }$ therefore synchronously posts $n$ instances of this goal, i.e., ${ SolveSubTower(d_n) },{ SolveSubTower(d_{n-1}) },\ldots ,{ SolveSubTower(d_1) }$.

Fig. 9

The goal-plan tree structure for the Tower of Hanoi agent

1.3 Recursive solution

The agent’s preferred techique for solving a stacking sub-problem is a modification of the traditional recursive solution. From an arbitrary initial state, this solution will build a stack of any given size on any pin using the fewest possible moves. The pseudocode for this algorithm is shown in Algorithm 2. For any values of $i, j$ such that $1 \le j \le i \le n$, the procedure will stack discs $d_i, d_{i-1}, \ldots , d_j$ onto a given pin $p_x$.

The structure of this algorithm is reflected directly in the structure of the goal-plan tree in Fig. 9. Calls to procedure BuildStack are represented by the goal of the same name, and the procedure body is implemented in the plan ${ RecursivelyBuildStack }$. Calls to procedure GetDiscToPin are represented by the goal of the same name, with its base and recursive cases implemented in plans ${ BaseCase }$ and ${ RecursiveCase }$. The plan ${ RecursiveSolution }$ handles a subgoal of the form ${ SolveSubTower(d_k) }$, which, as described above, represents the need to stack discs $d_n, d_{n-1}, \ldots , d_k$ onto $p_C$. The plan thus posts a single subgoal, ${ BuildStack(d_n, d_k, p_C) }$, which effectively “calls” procedure BuildStack, beginning the recursive process.

The goal ${ BuildStack(d_i, d_j, p_x) }$ represents the need to build a stack of discs, $d_i, d_{i-1},$ $\ldots , d_j$, on pin $p_x$. The plan ${ RecursivelyBuildStack }$ handles this goal, and achieves it by first getting disc $d_i$ on to the top of pin $p_x$, then placing disc $d_{i-1}$ on top of $d_i$, etc., until the stack is complete. It does this by posting a series of goals of type ${ GetDiscToPin }$.

As the name implies, the goal ${ GetDiscToPin(d_k, p_x) }$ represents the desire to place disc $d_k$ on to the top of pin $p_x$. It is handled by two plans, ${ BaseCase }$ and ${ RecursiveCase }$. The context condition of ${ BaseCase }$ is simply the boolean condition of the if-then construct in procedure GetDiscToPin, i.e., it checks to see if the goal ${ GetDiscToPin }$ has already been achieved. Thus, if selected, this plan need not do anything. The context condition of ${ RecursiveCase }$ is the negation of the same boolean condition. This plan first finds the “temporary” pin, $p_{tmp}$, i.e., the pin which is neither the destination pin, $p_x$, nor the pin which is disc $d_k$’s current location. It then posts a subgoal, ${ BuildStack(d_{k-1}, d_1, p_{tmp}) }$. The purpose of this recursive posting is to stack all discs smaller than $d_k$ onto the “temporary” pin, thus clearing the way for $d_k$ to be moved on onto $p_x$. This move is achieved by posting a ${ MakeMove }$ subgoal.

While simple and efficient, this method is brittle. When following this shortest route, it pays no attention to the current state of the engines, meaning that it may post a ${ MakeMove }$ goal that is not currently achievable. This might (depending on the intention selection scheme used) cause a goal failure which will propagate up to the ${ RecursiveSolution }$ plan.

1.4 Path planning solution

If the recursive solution fails, the agent has an alternative, path-planning based way of resolving the ${ SolveSubTower }$ goal. The plan ${ PathPlanningSolution }$ handles a goal of the form ${ SolveSubTower(d_k) }$, and simply posts a single goal, ${ PlanPath(d_k, p_C) }$.

The goal ${ PlanPath(d_k, p_x) }$ represents the need to plan a path to a state in which $d_n, d_{n-1}, \ldots , d_k$ are stacked on $p_x$. When it is posted, a breadth-first search over the space of all possible moves is performed and, given the current state of the engines, the shortest sequence of moves to all tower states which satisfy the goal are found. A separate instance of the plan ${ PathOption }$ is generated per sequence, and the plan instance with the shortest sequence is then selected for execution. The ${ PathOption }$ plan follows the path by posting a series of ${ MoveDisc }$ goals.

It is of course possible that while the path is being followed, the engine deteriorates in such a way as to block the path. In this case, the ${ PathOption }$ plan might fail while attempting an unavailable move. But rather than this failing the intention as a whole, this failure will prompt the goal ${ PlanPath }$ to be re-posted, and an alternative path will be sought. However, it is still posible for the path-planning solution to fail. If the engines are sufficiently deteriorated, it is possible that no desired states are accessible; in this case no applicable plans will be generated for the goal ${ PlanPath }$. Depending on the intention selection scheme in place, this may cause a goal failure which will propagate to the intention’s top-level goal.