Solving Distributed Constraint Optimization Problems Using Logic Programming

05/10/2017 ∙ by Tiep Le, et al. ∙ New Mexico State University 0

This paper explores the use of Answer Set Programming (ASP) in solving Distributed Constraint Optimization Problems (DCOPs). The paper provides the following novel contributions: (1) It shows how one can formulate DCOPs as logic programs; (2) It introduces ASP-DPOP, the first DCOP algorithm that is based on logic programming; (3) It experimentally shows that ASP-DPOP can be up to two orders of magnitude faster than DPOP (its imperative programming counterpart) as well as solve some problems that DPOP fails to solve, due to memory limitations; and (4) It demonstrates the applicability of ASP in a wide array of multi-agent problems currently modeled as DCOPs. Under consideration in Theory and Practice of Logic Programming (TPLP).

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Distributed Constraint Optimization Problems (DCOPs) are optimization problems where agents need to coordinate the assignment of values to their “local” variables to maximize the overall sum of resulting constraint utilities [Modi et al. (2005), Petcu and Faltings (2005a), Mailler and Lesser (2004), Yeoh and Yokoo (2012)]. The process is subject to limitations on the communication capabilities of the agents; in particular, each agent can only exchange information with neighboring agents within a given topology. DCOPs are well-suited for modeling multi-agent coordination and resource allocation problems, where the primary interactions are between local subsets of agents. Researchers have used DCOPs to model various problems, such as the distributed scheduling of meetings [Maheswaran et al. (2004), Zivan et al. (2014)], distributed allocation of targets to sensors in a network [Farinelli et al. (2008)], distributed allocation of resources in disaster evacuation scenarios [Lass et al. (2008)], the distributed management of power distribution networks [Kumar et al. (2009), Jain et al. (2012)], the distributed generation of coalition structures [Ueda et al. (2010)] and the distributed coordination of logistics operations [Léauté and Faltings (2011)].

The field has matured considerably over the past decade, since the seminal ADOPT paper [Modi et al. (2005)]

, as researchers continue to develop more sophisticated solving algorithms. The majority of the DCOP resolution algorithms can be classified in one of three classes:

(1) Search-based algorithms, like ADOPT [Modi et al. (2005)] and its variants [Yeoh et al. (2009), Yeoh et al. (2010), Gutierrez et al. (2011), Gutierrez et al. (2013)], AFB [Gershman et al. (2009)], and MGM [Maheswaran et al. (2004)], where the agents enumerate combinations of value assignments in a decentralized manner; (2) Inference-based algorithms, like DPOP [Petcu and Faltings (2005a)] and its variants [Petcu and Faltings (2005b), Petcu and Faltings (2007), Petcu et al. (2007), Petcu et al. (2008)], max-sum [Farinelli et al. (2008)], and Action GDL [Vinyals et al. (2011)], where the agents use dynamic programming techniques to propagate aggregated information to other agents; and (3) Sampling-based algorithms, like DUCT [Ottens et al. (2012)] and D-Gibbs [Nguyen et al. (2013), Fioretto et al. (2014)], where the agents sample the search space in a decentralized manner.

The existing algorithms have been designed and developed almost exclusively using imperative programming techniques, where the algorithms define a control flow, that is, a sequence of commands to be executed. In addition, the local solver employed by each agent is an “ad-hoc” implementation. In this paper, we are interested in investigating the benefits of using declarative programming techniques to solve DCOPs, along with the use of a general constraint solver, used as a black box, as each agent’s local constraint solver. Specifically, we propose an integration of Distributed Pseudo-tree Optimization Procedure (DPOP) [Petcu and Faltings (2005a)], a popular DCOP algorithm, with Answer Set Programming (ASP) [Niemelä (1999), Marek and Truszczyński (1999)] as the local constraint solver of each agent.

This paper provides the first step in bridging the areas of DCOPs and ASP; in the process, we offer novel contributions to both the DCOP field as well as the ASP field. For the DCOP community, we demonstrate that the use of ASP as a local constraint solver provides a number of benefits, including the ability to capitalize on (i) the highly expressive ASP language to more concisely define input instances (e.g., by representing constraint utilities as implicit functions instead of explicitly enumerating their extensions) and (ii) the highly optimized ASP solvers to exploit problem structure (e.g., propagating hard constraints to ensure consistency). For the ASP community, the paper makes the equally important contribution of increasing the applicability of ASP to model and solve a wide array of multi-agent coordination and resource allocation problems, currently modeled as DCOPs. Furthermore, it also demonstrates that general, off-the-shelf ASP solvers, which are continuously honed and improved, can be coupled with distributed message passing protocols to outperform specialized imperative solvers.

The paper is organized as follows. In Section 2, we review the basic definitions of DCOPs, the DPOP algorithm, and ASP. In Section 3, we describe in detail the structure of the novel ASP-based DCOP solver, called ASP-DPOP, and its implementation. Section 4 provides an analysis of the properties of ASP-DPOP, including proofs of soundness and completeness of ASP-DPOP. Section 5 provides some experimental results, while Section 6 reviews related work. Finally, Section 7 provides conclusions and indications for future work.

2 Background

In this section, we present an overview of DCOPs, we describe DPOP, a complete distributed algorithm to solve DCOPs, and provide some fundamental definitions of ASP.

2.1 Distributed Constraint Optimization Problems

A Distributed Constraint Optimization Problem (DCOP) [Modi et al. (2005), Petcu and Faltings (2005a), Mailler and Lesser (2004), Yeoh and Yokoo (2012)] can be described as a tuple where:

  • is a finite set of (decision) variables;

  • is a set of finite domains, where is the domain of the variable , for ;

  • is a finite set of constraints, where is a -ary function that specifies the utility of each combination of values of variables in its scope; the scope is denoted by ;222For the sake of simplicity, we assume a given ordering of variables.

  • is a finite set of agents; and

  • maps each variable to an agent.

We say that a variable is owned by an agent if . We denote with the set of all variables that are owned by an agent , i.e., . Each constraint in can be either hard, indicating that some value combinations result in a utility of and must be avoided, or soft, indicating that all value combinations result in a finite utility and need not be avoided. A value assignment is a (partial or complete) function that maps variables of to values in such that, if is defined, then for . For the sake of simplicity, and with a slight abuse of notation, we will often denote simply with . Given a constraint and a complete value assignment for all decision variables, we denote with the projection of to the variables in ; we refer to this as a partial value assignment for . For a DCOP , we denote with the set of all complete value assignments for .

A solution of a DCOP is a complete value assignment for all variables such that

(1)

A DCOP can be described by its constraint graph—i.e., a graph whose nodes correspond to agents in and whose edges connect pairs of agents who own variables in the scope of the same constraint.

Definition 1 (Constraint Graph)

A constraint graph of a DCOP is an undirected graph where and

(2)

Given the constraint graph and given a node , we denote with the neighbors of , i.e.,

(3)
Definition 2 (Pseudo-tree)

A pseudo-tree of a DCOP is a subgraph of that has the same nodes as such that (i) the included edges (called tree edges) form a rooted tree, and (ii) two nodes that are connected to each other in appear in the same branch of the tree.

The edges of that are not included in a pseudo-tree are called back edges. Notice that tree edges connect a node with its parent and its children, while back edges connect a node with its pseudo-parents and pseudo-children—i.e., nodes closer to the root are parents or pseudo-parents, while those closer to the leaves are children or pseudo-children. A pseudo-tree of a DCOP can be constructed using distributed DFS algorithms [Hamadi et al. (1998)] applied to the constraint graph of the DCOP.

In this paper, we say that two variables are constrained to each other if they are in the scope of the same constraint. Given a pseudo-tree, the separator of a node is, intuitively, the set of variables that (i) are owned by the ancestors of , and (ii) are constrained with some variables that are either owned by or the descendants of . Formally, in a pseudo-tree, the separator of a node , denoted by , is:

(4)

We denote with , , , and the parent, the set of pseudo-parents, the set of children, and the set of pseudo-children of a node , respectively. For simplicity, if is a set of agents in , we also denote with the set of variables in that are owned by agents in .

(a) Constraint Graph (b) Pseudo-tree
for Utilities 0 0 5 0 1 8 1 0 20 1 1 3
(c) Utilities of Constraints with
Figure 1: Example DCOP
Example 1

Figure 1(a) shows the constraint graph of a DCOP where:

  • ;

  • where ( is the domain of the variable ;

  • where, for each ,

    • for the constraint we have that ;

    • the utilities specified by the constraint are given in Figure 1(c).

  • ; and

  • maps each variable to agent .

Figure 1(b) shows one possible pseudo-tree, where the dotted line is a back edge. In this pseudo-tree, , , , , and .

In a pseudo-tree of a DCOP , given let be the set of constraints in such that:

(5)

In the following, without causing any confusion, we often omit the superscript in (i.e., ) if there is only one pseudo-tree mentioned in the context.

Example 2

Considering again the DCOP in Example 1 and its pseudo-tree in Figure 1(b), we have .

2.2 The Distributed Pseudo-tree Optimization Procedure

The Distributed Pseudo-tree Optimization Procedure (DPOP) [Petcu and Faltings (2005a)] is a complete algorithm to solve DCOPs with the following three phases:333Here we detail an extended version of DPOP described in [Petcu and Faltings (2005a)] which removes the assumption that each agent owns exactly one variable. Pseudo-tree generation, UTIL propagation and VALUE propagation.

2.2.1 Phase 1: Pseudo-tree Generation Phase

DPOP does not require the use of any specific algorithm to construct the pseudo-tree. However, in many implementations of DPOP, including those within the DCOPolis [Sultanik et al. (2007)] and FRODO [Léauté et al. (2009)] repositories, greedy approaches such as the Distributed DFS algorithm [Hamadi et al. (1998)] are used.

The Distributed DFS algorithm operates as follows. First of all, the algorithm assigns a score to each agent, according to a heuristic function. It then selects an agent with the largest score as the root of the pseudo-tree. Once the root is selected, the algorithm initiates a DFS-traversal of the constraint graph, greedily adding the neighboring agent with the largest score as the child of the current agent. This process is repeated until all agents in the constraint graph are added to the pseudo-tree.

The agents’ scores can be chosen arbitrarily. A commonly used heuristic is the max-degree heuristic :

(6)

which sets an agent’s score to its number of neighbors. In situations where multiple agents have the same maximal score, the algorithm breaks ties according to a different heuristic, such as the variable-ID heuristic, which assigns to each agent a score that is equal to its unique ID. In our experiments, we use the max-degree heuristic and break ties with the variable-ID heuristic in the construction of the pseudo-tree.

2.2.2 Phase 2: UTIL Propagation Phase

The UTIL propagation phase is a bottom-up process, which starts from the leaves of the pseudo-tree and propagates upward, following only the tree edges of the pseudo-tree. In this process, the agents send UTIL messages to their parents.

Definition 3 (UTIL Messages [Petcu (2009)])

, the UTIL message sent by agent to agent , is a multi-dimensional matrix, with one dimension for each variable in . With a slight abuse of notation, we denote with the set of variables in the message.

Instead of using a multi-dimensional matrix, one can also flatten the multi-dimensional matrix into a table where each row of the table is for one combination of value assignment of variables in and the respective utility for that combination. For simplicity, in this paper, we will represent UTIL messages under their tabular form. We can observe that it is always true that . The semantics of such a UTIL message is similar to a constraint whose scope is the set of all variables in the context of the message (its dimensions). The size of such a UTIL message is the product of the domain sizes of variables in the context of the message.

Intuitively, a UTIL message summarizes the optimal sum of utilities in its subtree for each value combination of variables in its separator. An agent computes its UTIL message by (i) summing the utilities in the UTIL messages received from its child agents and the utilities of constraints whose scopes are exclusively composed of the variables of and the variables in its separator (i.e., ), and then (ii) projecting out the variables of , by optimizing over them. Algorithm 1 provides a formal description of Phase 2.

1 Each agent does:
2
3 forall  do
4        wait for message to arrive from
5        join UTIL messages from children as they arrive
6       
7 end forall
8 also join all constraints with parent/pseudo-parents
9 use projection to eliminate its owned variables
10 Send message to its parent agent
Algorithm 1 DPOP Phase 2 (UTIL Propagation Phase)

Algorithm 1 uses the JOIN operator (i.e., ) and the PROJECTION operator (i.e., ).

Definition 4 (Join Operator)

is the join of two UTIL matrices (constraints). is also a matrix (constraint) with as dimensions. For each possible combination of values of variables in , the corresponding value of is the sum of the corresponding cells in the two source matrices, i.e., where and are partial value assignments from for all variables in and , respectively.

Since UTIL messages can be seen as constraints, the operator can be used to join UTIL messages and constraints.

Example 3

Given 2 constraints and in Example 1, let . It is possible to see that . The utility corresponding to is . Moreover, .

For the operator, knowing that , is the projection through optimization of the matrix along axes representing variables in .

Definition 5 (Projection Operator)

Let be a set of variables where , and let be the set of all possible value combinations of variables in . A matrix is defined as: (i) , and (ii) for each possible value combination of variables in , .

Example 4

Considering again in Example 3, let . We have , and .

As an example for the computations in Phase 2 (UTIL propagation phase), we consider again the DCOP in Example 1.

Example 5

In the DCOP in Example 1, the agent computes its UTIL message, (see Table 1(a)), and sends it to its parent agent . The agent then computes its UTIL message, (see Table 1(b)), and sends it to its parent agent . Finally, the agent computes the optimal utility of the entire problem, which is .

Utilities  0 0 max( 5 + 5 , 8 + 8 ) = 16  0 1 max( 5 + 20 , 8 + 3 ) = 25  1 0 max( 20 + 5 , 3 + 8 ) = 25  1 1 max( 20 + 20 , 3 + 3 ) = 40 (a) Utilities  0 max( 5 + 16 , 8 + 25 ) = 33  1 max( 20 + 25 , 3 + 40 ) = 45 (b)
Table 1: UTIL Phase Computations in DPOP

2.2.3 Phase 3: VALUE Propagation Phase

Phase 2 finishes when the UTIL message reaches the root of the tree. At that point, each agent, starting from the root of the pseudo-tree, determines the optimal value for its variables based on (i) the computation from Phase 2, and (ii) (for non-root agent only) the VALUE message that is received from its parent. Then, it sends these optimal values to its child agents through VALUE messages. Algorithm 2 provides a formal description of Phase 3.

A VALUE message that travels from the parent to the agent , , contains the optimal value assignment for variables owned by either the parent agent or the pseudo-parent agents of the agent .

1 Each agent do:
2 wait for message from its parent agent    is the optimal value assignment for all variables in
3 is the set of all possible value combinations of variables in
4 forall   do
5        let be the partial optimal value assignment for variables in from
6        send as message to its child agent
7 end forall
Algorithm 2 DPOP Phase 3 (VALUE Propagation Phase)
Example 6

In the DCOP in Example 1, the agent determines that the value with the largest utility for its variable is 1, with a utility of 45, and then sends this information down to its child agent in a VALUE message, i.e., . Upon receiving that VALUE message, the agent determines that the value for its variable with the largest utility of the subtree rooted at the agent , assuming that , is 0, with a utility of 45. The agent then sends this information down to its child agent , i.e., . Finally, upon receiving such VALUE message, the agent determines that the value for its variable with the largest utility of the subtree rooted at the agent , assuming that and , is 0, with a utility of 25.

2.3 Answer Set Programming

Let us provide some general background on Answer Set Programming (ASP) (see, for example, [Baral (2003), Gelfond and Kahl (2014)] for more details).

An answer set program is a set of rules of the form

(7)

where , for each or is a literal of a first order language , and represents negation-as-failure (naf). For a literal , is called a naf-literal. For a rule of the form (7), the left and right hand sides of the rule are called the head and the body of the rule, respectively. Both the head and the body can be empty. When the head is empty, the rule is called a constraint. When the body is empty, the rule is called a fact. A literal (resp. rule) is a ground literal (resp. ground rule) if it does not contain any variable. A rule with variables is simply used as a shorthand for the set of its ground instances from the language . Similarly, a non-ground program (i.e., a program containing some non-ground rules) is a shorthand for all ground instances of its rules. Throughout this paper, we follow the traditional notation in writing ASP rules, where names that start with an upper case letter represent variables. For a ground instance of a rule of the form (7), denotes the set , while and denote and , respectively.

Let be a set of ground literals. is consistent if there is no atom such that . The body of a ground rule of the form (7) is satisfied by if and . A ground rule of the form (7) with nonempty head is satisfied by if either its body is not satisfied by or . A constraint is satisfied by if its body is not satisfied by .

For a consistent set of ground literals and a ground program , the reduct of w.r.t. , denoted by , is the program obtained from by deleting (i) each rule that has a naf-literal not in its body where , and (ii) all naf-literals in the bodies of the remaining rules.

is an answer set (or a stable model) of a ground program [Gelfond and Lifschitz (1990)] if it satisfies the following conditions: (i) If does not contain any naf-literal (i.e., in every rule of ) then is a minimal consistent set of literals that satisfies all the rules in ; and (ii) If contains some naf-literals ( in some rules of ) then is an answer set of . Note that does not contain naf-literals, and thus its answer set is defined in case (i). A program is said to be consistent if it has some answer sets. Otherwise, it is inconsistent.

The ASP language includes also language-level extensions to facilitate the encoding of aggregates (min, max, sum, etc.).

Example 7

Let us consider an ASP program that consists of two facts and one rule:

(8)
(9)
(10)

The third rule uses an aggregate to determine the maximum in the set . has one answer set: . Thus, is consistent.

Moreover, to increase the expressiveness of logic programming and simplify its use in applications, the syntax of ASP has been extended with choice rules. Choice rules are of the form:

(11)

where is called a choice atom, and are integers, , , and each is a literal for . This rule allows us to derive any subset of whose cardinality is between the lower bound and upper bound whenever the body is satisfied. or can be omitted. If is omitted, , and if is omitted, . Standard syntax for choice rules has been proposed and adopted in most state-of-the-art ASP solvers, such as clasp [Gebser et al. (2007)] and dlv [Citrigno et al. (1997)].

Figure 2: Solving a Problem Using ASP

Figure 2 visualizes how to solve a problem using ASP. In more detail, the problem is encoded as an answer set program whose answer sets correspond to solutions. The answer set program, which may contains variables, is then grounded using an ASP grounder, e.g., gringo [Gebser et al. (2011)]. The grounding process employs smart techniques to reduce the size of the resulting ground program, e.g., removing literals from rules that are known to be true, removing rules that will not contribute to the computation of answer sets.

Example 8

Let us consider an ASP program that consists of two facts and one rule:

(12)
(13)
(14)

Using a naive grounder that simply replaces consistently the variable with the two constants and , the ground program of consists of the two facts (12) and (13) and the two following ground rules:

(15)
(16)

It is easy to see that the ground rule (16) is unnecessary (i.e., its body cannot be satisfied by any set of literals due to the literal ) and should be removed. In contrast, the ground program of obtained by gringo has only three facts: (12), (13), and

(17)

We observe that the unnecessary rule (16) is omitted since its body cannot be satisfied (i.e., ), and the fact (17) is obtained from the rule (15) by removing all literals in its body because the grounder can determine as been always satisfied.

All the answer sets of the program produced by the ASP grounder are then computed by an ASP solver, e.g., clasp [Gebser et al. (2007)]. The solutions to the original problem can be determined by properly interpreting the different answer sets computed, where each answer sets corresponds to one of the possible solutions to the original problem. For readers who are interested in how to solve an answer set program, the foundations and algorithms underlying the grounding and solving technology used in gringo and clasp are described in detail in [Gebser et al. (2012), Kaufmann et al. (2016)].

3 Asp-Dpop

ASP-DPOP is a framework that uses logic programming to capture the structure of DCOPs, and to emulate the computation and communication operations of DPOP. In particular, each agent in a DCOP is represented by a separate ASP program—effectively enabling the infusion of a knowledge representation framework in the DCOP paradigm.

The overall communication infrastructure required by the distributed computation of DPOP is expressed using a subset of the SICStus Prolog language [Carlsson, M. et al. (2015)], extended with multi-threading and the Linda blackboard facilities. In ASP-DPOP, we use clasp [Gebser et al. (2007)], with its companion grounder gringo, as our ASP solver, being the current state-of-the-art for ASP. In this section, we will describe the structure of ASP-DPOP and its implementation.

Figure 3: The structure of an ASP-DPOP agent

3.1 The architecture of ASP-DPOP

ASP-DPOP is an agent architecture that reflects the structure of DCOPs, where several agents reflect the computation and communication operations of DPOP. The internal structure of each ASP-DPOP agent, shown in Figure 3, is composed of two modules. The first module is the Specification Module (SM), that encloses an ASP program which captures a corresponding agent as specified in the DCOP—i.e., the agent’s name, the agent’s neighbors, the description of the variables owned by the agent, the description of the variables owned by the agent’s neighbors, and the description of the constraints whose scope include any of the variables owned by the agent.

The second module is the Controller Module (CM), encoded as a Prolog program. The CM instructs the agent to perform the communication operations of DPOP, such as cooperating with other agents to generate a pseudo-tree, waiting for UTIL messages from child agents, sending the UTIL message to the parent agent (if present), waiting for the VALUE message from the parent agent (if present), and sending the VALUE messages to the child agents.

In ASP-DPOP, each DCOP is represented by a set of ASP-DPOP agents; each agent is modeled by its knowledge bases, located at its SM and CM, and it interacts with other agents in accordance to the rules of its CM.

3.2 ASP-DPOP Implementation: Specification Module (SM)

Let us describe how to capture the structure of a DCOP in the Specification Module of an ASP-DPOP agent using ASP. Let us consider a generic DCOP . We represent using a set of ASP-DPOP agents whose SMs are ASP programs . We will show how to generate for each agent . In the following, we say and in are neighbors if there exists and in such that , , and there is a such that . Given a constraint , we say that is owned by the agent if the scope of contains some variables owned by the agent .444 The concept of ownership of a constraint is introduced to facilitate the representation of ASP-DPOP implementation. Intuitively, an agent should know about a constraint if the agent owns some variables that are in the scope of such constraint. Under this perspective, a constraint may be owned by several agents.

For each variable we define a collection of ASP rules that includes:

  • A fact of the form

    (18)

    for identifying the name of the variable;

  • For each , a fact of the form

    (19)

    for identifying the possible values of . Alternatively, if the domain is an integer interval we can use the additional facts of the form

    (20)
    (21)

    to facilitate the description of the domain . In such case, the predicates similar to ones in (19) are achieved by the rule

    (22)

    Intuitively, and in (22) are variables that should be grounded with and from (20) - (21), respectively.

For each constraint , where , we define a collection of rules that includes:

  • A fact of the form

    (23)

    for identifying the name of the constraint;

  • For each variable , a fact of the form

    (24)

    for identifying the scope of the constraint; and

  • For each partial value assignment for all variables in , where are the value assignments of the variables , respectively, such that , a fact of the form

    (25)

    For each partial value assignment for all variables in , where are the value assignments of the variables , respectively, such that , a fact of the form555 is a special constant representing the smallest possible value in ASP language.

    (26)

Alternatively, it is also possible to envision cases where the utility of a constraint is implicitly modeled by logic programming rules, as shown in the following example. It is important to mention that, considering a constraint :

  • The order of variables (e.g., ) in , whose corresponding value assignments (e.g., ) that appear in facts of the forms (25) and (26), needs to be consistent in all facts of the forms (25) and (26) that relate to the constraint ; and

  • The order of the facts of the form (24) that are added to to identify the scope of the constraint needs to be consistent with the order of variables (e.g., ) mentioned in (1).

These requirements (i.e., (1) and (2)) are critical, because they allow Controller Modules to understand which variables belong to what values that appear in the facts of the forms (25) and (26), when Controller Modules read . This is done because, in SICStus Prolog, the search rule is “search forward from the beginning of the program.” Therefore, the order of the predicates (i.e., facts) that are added to SICStus Prolog matters.

Example 9

Let us consider a constraint whose scope is , and specifies that the utility of value assignments , is . The facts of the form (25) for the constraint can be modeled by the following rule

(27)

For each agent we define an ASP program that includes:

  • A fact of the form

    (28)

    for identifying the name of the agent;

  • For each variable that is owned by the agent , a fact of the form

    (29)
  • For each agent who is a neighbor of the agent , a fact of the form

    (30)
  • For each variable that is owned by an agent who is a neighbor of the agent , a fact of the form

    (31)
  • For each constraint owned by the agent , the set of rules

    (32)
  • For each variable that is in the scope of some constraints owned by the agent , the set of rules

    (33)

3.3 ASP-DPOP Implementation: Encoding UTIL and VALUE Messages

The ASP-DPOP framework emulates the computation and communication operations of DPOP, where each ASP-DPOP agent produces UTIL and VALUE messages, and forwards them to its parent and child agents, as DPOP does. In ASP-DPOP, UTIL and VALUE messages are encoded as ASP facts, as discussed in this subsection.

3.3.1 UTIL Messages

In DPOP, each UTIL message sent from a child agent to its parent agent is a matrix. In encoding a UTIL message in ASP-DPOP, we represent each cell of the matrix of the UTIL message, whose associated utility is not , as an ASP atom of the form:

(34)

which indicates that the optimal aggregate utility of the value assignments is , where . In other words, the parent agent knows that , …, if it receives the fact . It is important to know that the encoding of a UTIL message omits the cells whose associated utilities are .

In addition to facts of the form (34), also informs about variables in its separator. Thus, the encoding of the UTIL message sent from the agent to the agent includes also atoms of the form:

(35)
(36)

Each fact informs that is a variable in the separator of whose domain is specified by (lower bound) and (upper bound) and whose owner is .666For simplicity, we assume that the domains are integer intervals. It is also critical to note that the order of the atoms of the forms (35) - (36) matters, since such order will allow the respective Controller Module understand which variable belongs to the values stated in facts of the form (34) after reading such encoded UTIL messages.

Example 10

Consider again the DCOP in Example 1. The UTIL message, sent from the agent to the agent , in Table 1(a) is encoded as the set of the ASP atoms:

(37)
(38)
(39)
(40)
(41)
(42)
Example 11

Similarly, considering again the DCOP in Example 1, the UTIL message sent from the agent to the agent in Table 1(b) is encoded as the set of ASP facts:

(43)
(44)
(45)

3.3.2 VALUE Messages

In DPOP, each VALUE message sent from a parent agent to its child agents contains the optimal value assignment for variables owned by either the parent agent or the pseudo-parent agents of the agent . Thus, in encoding a VALUE message, we use atoms of the form:

(46)

where is the value assignment of the variable owned by the agent for an optimal solution.

Example 12

Consider again the DCOP in Example 1. The VALUE message sent from the agent to the agent is encoded as the ASP atom:

(47)

Similarly, the VALUE message sent from the agent to the agent is encoded as the set of the ASP atoms:

(48)
(49)

3.4 ASP-DPOP Implementation: Controller Module (CM)

Figure 4: Phase 2 and Phase 3 of Agent in ASP-DPOP on DCOP in Example 1

The controller module in each ASP-DPOP agent , denoted by , consists of a set of Prolog rules for communication (sending, receiving, and interpreting messages) and a set of rules for generating an ASP program that is used for the computations of a UTIL message and a VALUE message. In this subsection, we would like to discuss some code fragments to show how is structured.777The code listed in this section is a simplified version of the actual code for , showing a condensed version of the clause bodies; however, it still gives a flavor of the implementation of and should be sufficiently explanatory for the purpose of the controller module. To begin with, we will show how uses the Linda blackboard library of Prolog to exchange the messages.

There are three types of messages exchanged through the Linda blackboard; they are tree, util, and value messages that are used in Phase 1, Phase 2, and Phase 3, respectively, of DPOP. For sending (resp. waiting for) a message, we use the built-in predicate (resp. ) provided by the Linda library of Prolog. Every message is formatted as where the arguments denote the agent who sends this message, the agent who should receive this message, the type of the message, and the data enclosed in the message, respectively. The implementation of the communication and the three phases of DPOP are described next.

3.4.1 Sending Messages

The following Prolog rule generates a message of type , with content (Content), to be sent from an agent (From) to an agent (To):

% sending message
send_message(From,To,Type,Content) :-
                   out(message(From,To,Type,Content)).

3.4.2 Waiting for Messages

The following Prolog rule instructs agent (a_k) to wait for a message:

% waiting for a message
wait_message(From,a_k,Type,Data):- in(message(From,a_k,Type,Data)).

where , and will be unified with the name of the agent who sent this message, the type of the message, and the data enclosed in the message, respectively.

3.4.3 Creating the Pseudo-Tree: Phase 1

In this phase, ASP-DPOP agents cooperate with each other to construct a pseudo-tree. For simplicity, we will show here the clauses in for generating a pseudo-tree by initiating a DFS-traversal. We assume that the agent is not the root of the pseudo-tree. The agent waits for a message from an agent . The content () enclosed in such a message is the set of visited agents—i.e., the agents who have already started performing the DFS. Upon receiving a message, will execute the following clauses:

% pseudo-tree generation
generate_tree(Parent, Data):-
             assign_parent(Parent),
             assign_pseudo_parent(Data),
             append(Data, [a_i], NewData),
             depth_first_search(Parent, NewData).

% performing depth first search
depth_first_search(Parent, Data):-
             find_next(Data, Next_Agent),
             (Next_Agent == none ->
                     send_message(a_i, Parent, tree, Data)
                     ;
                     assign_child(Next_Agent),
                     send_message(a_i, Next_Agent, tree, Data),
                     wait_message(Next_Agent, a_i, tree, NewData),
                     depth_first_search(Parent, NewData)
             ).

Intuitively, upon receiving a message from the agent enclosed with data , the agent will execute the clause generate_tree(Parent, Data). Specifically:

  • It executes the clause , where it adds to its a fact of the form ;

  • It executes the clause which adds to its facts of the form , where is a neighboring agent of that appears in such that ;

  • It adds itself (i.e., ai) to the list of visited agents;

  • It starts performing a DFS, by executing the rule .

In order to perform a DFS, the agent will execute the rule to select a neighboring agent that will be visited next; this selection is based on some heuristics (i.e., the unvisited neighbor agent with the greatest number of neighbors). If such an agent exists (i.e., ), then will:

  • Execute the rule , used to add to its a fact of the form ;

  • Send a message to the agent ;

  • Wait for the reply message from the agent , which will provide the updated list of visited agents;

  • Recursively execute the rule .

Otherwise, if there is no agent (i.e., is equal to ), then the agent will reply a message to its agent . This implies that the agent has finished performing DFS at its branch.

When the agent is chosen to be the root of the pseudo-tree, it executes the rule immediately without waiting for the message from other agents. We note that an agent whose parent agent is will be the root of the pseudo-tree. It is also worth to notice that, at the end of this phase, the information about the parent, pseudo-parents, and child agents of each agent are added to via facts of the forms , , and , respectively.

Lemma 1

In ASP-DPOP, Phase 1 requires a linear number of messages in where is the number of agents.

We first prove that Phase 1 terminates. In fact, each agent in executing depth_first_search/2 will perform the rule to select a neighboring agent, i.e., , that is not in the set of visited agents to send a tree message to. can be seen as an unvisited neighboring agent of the agent .

The agent then waits to receive the tree message from enclosing an updated set of visited agents, and again send a tree message to another unvisited neighboring agent if it exists. We notice that the updated set of visited agents will be expanded with at least one agent that is since