Enabling BDI group plans with coordination middleware: semantics and implementation

Abstract

This paper investigates the use of group goals and plans as programming abstractions that provide explicit constructs for goals and plans involving coordinated action by groups of agents, with a focus on the BDI agent model. We define a group goal construct, which specifies subgoals that the group members must satisfy for the group goal to succeed, subject to timeouts on the members beginning work on the goal, and then completing their subgoals. A group plan containing one or more group goals can be dynamically distributed amongst a set of agents and jointly executed without a need for explicit coordinating communication between agents. We define formal semantics that model the coordination needed to determine a group goal’s success or failure as updates to a shared state machine for the group goal. We implement the semantics directly as rewrite rules in Maude, and verify using LTL model checking that the intended coordination behaviour is achieved. An implementation of group plans and goals for the Jason agent platform is also described, based on an integration of Jason with the ZooKeeper coordination middleware via a set of generic Jason plans supporting group goals, and the Apache Camel integration framework. A evaluation of the performance of this implementation is presented, showing that the approach is scalable.

Appendices

Appendix

A Dynamic distribution of a group plan

Fig. 15

Example of role assignment and group plan execution in Jason

This appendix illustrates how group plans can be dynamically distributed to agents that have been recruited to jointly execute the plan. Figure 15 shows the Jason source code for an agent that is coordinating the selection of agents to participate in a group plan for the early stages of building a house, and then supervising the work. The group plan (shown in lines 61 to 66) involves the serial execution of two group goals: to build the foundations and to build the walls. The first group goal involves an agent playing the role of foundation_digger and digging the foundations while an agent with the supervisor role monitors the work. The second group goal is similar, with an agent in the wall_builder role building the walls, monitored by a supervisor. The foundation digger is not involved in the second goal, and so has the default “no-op” subgoal, and likewise, the wall builder has the default no-op subgoal for the first group goal. To illustrate the inclusion of other types of goal in a group plan, the agents all begin the plan by printing (locally) a message that they are starting to execute the plan.

The agent running this code begins with an “oversee house building” goal (line 12). The plan triggered by this goal (lines 15–19) looks up all group plans for the house_built goal (it will find only one, in lines 61–66), and triggers the two plans shown in lines 21–31 to try each discovered group plan in turn until one succeeds.¹⁵ Some query goals called by these plans (lines 23 and 25) invoke Jason rules (Horn clauses) imported in line 1, and other goals trigger the plans in lines 33 to 59—the details are not important here. The key aspects of the code are that the coordinating agent sends invitations to other agents to take on roles (line 41), then after all roles have been filled, the group plan is sent to all group members (line 53), and they are requested to achieve the triggering goal for the group plan (line 54). The coordinator, having predetermined that it will take on the overseer role (line 9), then prepends the agent-instantiated group plan to its plan base (line 57) and begins executing it itself (line 58). Line 68 shows the coordinator’s local plan for the overseer role’s monitor subgoal, which for simplicity of presentation takes the negligent approach of doing nothing.

B Group goal semantics in Maude

Fig. 16

The group goal semantics from Fig. 5 encoded in Maude

Figure 16 shows an excerpt of the Maude code that implements the group goal semantics presented in Fig. 5. This shows the direct correspondence between those semantics and our implementation used for model checking. A separate set of rules (not shown) encodes the local agent transitions shown in Fig. 9.

Each semantic rule is implemented by a conditional rewrite rule of the following form:

crl [RuleName] : Term1 => Term2 if Condition .

The rules in Fig. 16 non-deterministically rewrite terms representing configuration triples. For brevity, declarations of the (typed) variables and the data structures for their types are not shown, but we present a summary below. The full code can be found at https://bitbucket.org/scranefield/bdigroupplans/.

• The first element in a configuration triple is a set of goal trees (SGT), where each goal tree is an association (using the operator ‘::’) between an agent name (a string) and an intention stack. Note that the operator ‘,’ represents set union (which Maude knows to be associative, commutative and idempotent), and Maude’s ‘order-sorted’ type system enables a singleton set to denoted by a set element alone (with no additional syntax). Thus, the first element of the triple in line 2 matches any set of goal trees in which agent A has the intention stack LPB APB.

• LPB denotes a list of plan bodies. Maude uses juxtaposition to denote (associative) list concatenation, and, as for sets, single list elements can also denote singleton lists. Thus, the intention stack for agent A in line 2 matches any list of plan bodies that ends with the atomic (explained below) plan body APB.

• group-size, jto and cto are constants with the values used in our model checking: the group size is 2 and $(\texttt {jto},\texttt {cto})$ ranged over $\{10,20,30\}^2$ in different runs.

• PB represents a plan body (a list of goals). It may also include a list of back-up plan bodies as discussed in Sect. 5. A postfix succeeded or failed operator represents a success or failure flag attached to the plan body. Within a plan body, a local goal is denoted by a string (the goal name), and a group goal has the form gg(GName). The function current-goal retrieves the current goal in a plan body. This is the first element in the list of goals, as goals are removed after succeeding.

• APB denotes an atomic plan body: one that has no success or failure flag associated with it directly (as opposed to any flag that may be associated with its current goal). The functions current-goal-succeeded and current-goal-failed test whether the current goal in an atomic plan body has a success or failure flag (respectively).

• The second element in a configuration triple is a set of group goal states (GGSs). This is represented by a Maude Map, which is a set of mappings GName -> GGS between a goal name (a string) and a group goal state. The latter is a tuple containing the current state in the state machine shown in Fig. 1, the number of agents involved in the group goal, countdown values for join and completion timeouts, two sets of agents recording those that have joined the goal and those that have succeeded with their subgoals, and the last time an update to the state was made.

  The initialise function creates a new group goal state tuple with the goal in the Initial state of the state machine, and the functions started, succeeded and failed return an updated group goal state resulting from the state machine receiving the respective event. The (overloaded) ‘::’ operator tests whether a group goal state is in a specified state of the state machine (e.g. see line 62), and the ag-has-joined and ag-has-succeeded functions test whether the specified agent is included in the state tuple’s set of joined or succeeded agents (respectively).

  Maude’s function $hasMapping is used in lines 6 and 57 to test whether the set of group goal states includes a state tuple for a given group goal.

• The third element in a configuration is a time point T, modelled as a non-negative integer. The function advance-time(T) returns T + 1.

Note that the condition for the no-op rule includes the bound T < 1000 to ensure the rules define a finite transition system, and the fairness constraint T rem 5 =/= 0 that ensures that agent progress cannot be delayed forever, as discussed in Sect. 6.

The conditions for the local-computation and no-op plans are defined by the Boolean-valued functions presented in lines 54–97: coordination-rule-applies, pure-coordination-rule-applies and local-success-now-waiting-for-others. Each of these functions is defined by a series of conditional equations (ceq) for different cases that give a result of true, followed by an unconditional equation (eq), adorned with an owise (“otherwise”) attribute that declares that any inputs not matching the argument terms in the preceding cases should have a result of false. For semantic purity, Maude automatically computes the required condition for each “otherwise” case and converts the unconditional equation to a conditional one.