Distributed generative CSP approach towards multi-site product

Distributed generative CSP approach towards multi-site product configuration A. Felfernig1 , G. Friedrich1 , D. Jannach1 , M.C. Silaghi2 , and M. Zanker1 1

Universitaet Klagenfurt, A-9020 Klagenfurt, Austria {felfernig,friedrich,jannach,zanker}@ifit.uni-klu.ac.at 2 Florida Institute of Technology (FIT), Melbourne, FL 32901, USA [email protected]

Abstract. Today’s configurators are centralized systems and do not allow manufacturers to cooperate on-line for offer-generation or sales-configuration. However, supply chain integration of configurable products requires the cooperation of the configuration systems from the different manufacturers that jointly offer solutions to customers. As a consequence, there is a business requirement for methods that enable the computation of such configurations by independent specialized agents. Some of the approaches to centralized configuration tasks are based on constraint satisfaction problem (CSP) solving. Most of them extend the traditional CSP approach in order to answer the specific expressivity and dynamism requirements for configuration and similar synthesis tasks. The distributed generative CSP (DisGCSP) framework proposed here builds on a CSP formalism that encompasses the generative aspect of variable creation and of extensible domains for problem variables. It also builds on the distributed CSP (DisCSP) framework, allowing for approaches to configuration tasks where the knowledge is distributed over a set of agents. Notably, the notions of a constraint and a nogood are generalized to an additional level of abstraction, extending inferences to types of variables. The usage of the new framework is exemplified by describing modifications to asynchronous algorithms. Our experimental evaluation gives evidence that for typical configuration tasks, encodings within a DisGCSP framework can be solved more efficiently than encodings with DisCSP.

1 Introduction/Background The paradigm of mass-customization allows customers to tailor (configure) a product or service according to their specific needs, i.e., the customer can select between several features and options that should be included in the configured product and can determine the physical component structure of the personalized product variant. Typically, there are several technical and marketing restrictions on the legal parameter constellations and on the physical layout. This led manufacturers to develop support for checking the feasibility of user requirements and for computing a consistent solution. Such functionality is provided by product configuration systems (configurators), which constitute a successful application area for different Artificial Intelligence techniques [27], e.g. description logics [17] or rule-based [2] and constraint-based solving algorithms. [8]

describes the industrial use of constraint techniques for the configuration of large and complex systems such as telecommunication switches and [16] details an example of a powerful tool based on Constraint Satisfaction available on the market. However, companies find themselves in dynamically determined coalitions with other highly specialized solution providers that jointly offer customized solutions. This high integration aspect of today’s digital markets requests that software products supporting the selling and configuration tasks are no longer conceived as standalone systems. A product configurator can be therefore seen as an agent with private knowledge that acts on behalf of its company and cooperates with other agents to solve configuration tasks. This paper abstracts the centralized definition of configuration tasks in [28] to a more general definition of a generative CSP that is also applicable to the wider range of synthesis problems. Furthermore, we propose a framework that allows us to address distributed configuration tasks by extending DisCSPs with the innovative aspects of local generative CSPs: 1. The constraints (and nogoods) are generalized to a form where they can depend on types rather than on identities of variables. This also enables an elegant treatment of the following aspects. 2. The number of variables of certain types that are active in the local Generative CSP (GCSP) of an agent, may vary depending on the state of the search process. In the DisCSP framework, the external variables existing in the system are predetermined, but in a DisGCSP the set of variables defining the problem is determined dynamically. 3. The domain of the variables may vary dynamically. Some variables model possible connections and they depend on the existence of components that could become connected. Namely, these domains extend when the possibility of connection to new components is created. We describe the interesting impact of the previously mentioned changes on asynchronous algorithms. After giving a motivating example in Section 2, Section 3 defines a generative CSP. Section 4 formalizes a distributed generative CSP and in Section 5 extensions to current DisCSP frameworks are presented. Finally, Section 6 evaluates DisGCSP encoding vs. classic DisCSP problem representation for typical configuration problems.

2 Example of configuration problem In the following we exemplify a problem from the domain of product configuration ([8]). A telecommunication switch consists of a set of frames, where each frame has optional connection points (denoted as ports) for modules to be plugged in. These modules can be configured to be either analog or digital (Figure 1). In addition, problemspecific constraints describe legal combinations of the number and configuration of the modules on the different frames. As different companies have to cooperate to provide a switching solution, the distribution aspect is inherent in this scenario. In order to keep the example simple, we assume a two-agent setting. The agents A1 and A2 are capable of configuring different functionalities of the telecommunication switch and therefore each of them owns a different set of constraints and they have a limited view on the

overall system, e.g., agent A1 requires only a view on the configuration of the upper two frames.

Fig. 1. Telecomunication switch

Short introduction on encoding technique When configuring large technical systems, the exact number of problem variables, i.e. employed modules and their connections, is not known from the beginning, it is therefore not efficient to formulate constraints directly on concrete variables. Instead, comparable to programming languages, variable types exist that allow us to associate a newly created variable with a domain and we can specify relationships in terms of generic constraints. [28] defines a generic constraint γ as a constraint schema, where meta-variables Mit act as placeholders for concrete variables of a specific type t, denoted by the superscript t. The subscript i allows us to distinguish between different meta-variables in one constraint3 . We therefore formalize this configuration task as a CSP, where for each frame two different types of variables exist. The first one encompasses the variables that represent the ports of a frame and the second one the modules to which the ports can be connected, i.e. tpa , tpb , tpc denote the types of port variables of frame A, B and C and ta , tb , tc represent the types of module variables. Every single port and module is represented by a variable4 . Variables representing modules take either the value 0 (analog) or 1 (digital), while port variables are assigned the index value of the module they are connected to. In our example for denoting a single variable the naming convention typei is chosen, where the subscript i gives the index value of variables of the same type, e.g., a1 , a2 , . . . represent the module instances on frame A and 3 4

The exact semantics of generic constraints is given in Definition 3 in Section 3.1 Note, that the frame components themselves are not explicitly modeled, but only via their characterizing port variables.

pa1 , pa2 , . . . are the names of its port variables. In order to be able to formulate restrictions on the amount of variables for each type a counter variable (xtype ) exists that holds the number of instantiated variables of type type. The configuration constraints are distributed between two agents, i.e., each agent Ai posesses a set of local constraints5 Γ Ai , i.e., Γ A1 = {γ1 , γ2 , γ4 , γ6 } and Γ A2 = {γ3 , γ5 , γ7 , γ8 }, which are defined as follows: Variables representing modules can take either the value 0 (’analog’) or 1 (’digital’). γ1 : M ta ≤ 1. γ2 : M tb ≤ 1. γ3 : M tc ≤ 1. For agent A1 the modules on frame A and those on frame B must be configured differently, i.e. all modules on frame A are set as ’analog’ and all modules on frame B as ’digital’ or vice versa. γ4 : M1ta = M2tb . For agent A2 the modules on frame A and on frame C must have the same configuration, i.e. they must be all set as either ’analog’ or ’digital’. γ5 : M1ta = M2tc . Agent A1 ensures, that the amount of modules on frame A is equal to the amount of modules on frame B. γ6 : xta = xtb ., where xta resp. xtb is a counter variable, that holds the amount of instantiated module variables on frame A resp. frame B. Similarly for agent A2 , the amount of modules on frame C must be at least as high as the amount of modules on frame A minus 1. γ7 : xta − 1 ≤ xtc . Agent A2 ensures that all modules on frame C are configured as ’digital’. γ8 : M tc = 1.

Example of the usage of the framework Now, we will exemplify the solving process in our framework for distributed generative constraint satisfaction explained later on this paper. Solving is performed by our asynchronous forward checking algorithm with local constraints (compare trace in Figure 3), that is detailed in Section 4. The subscripted index value of the agents Ai also denotes their priority, where 1 is highest. The example in Figure 2.a depicts an initial situation, where a customer-specific requirement imposes a restriction on the configuration result, e.g. the telecommunication switch must contain at least two modules that must be connected via ports to frame A. Agent A1 fulfills this initial customer requirement by generation of problem variables and communicates them via an announce message to the other Agent A2 . The parameter of an announce is a list of new variables denoted by a pair: (type,index). Agent A2 determines his interest in the newly announced variables and communicates an addlink message back. As can be seen from Figure 2.b, agent A1 creates two modules and their ports on frame B in order to fulfill constraint γ6 and sets modules on frame A to 0 and on frame B to 1 (constraint γ4 ). Agent A2 creates a module instance on frame C and configures it 5

For reasons of presentation we omit those constraints that ensure that all modules are connected and that once a port variable is assigned a value, the corresponding connected component variable must exist.

module variable

a1 = {?}

a1 = {0}

port variable pa1

pa1 rack A

rack A

b1 = {1}

pb1 rack B

rack B

c1 = {1}

pc1

c2 = {1}

pc2

rack C

rack C

a) Initial situation

a1 = {0}

b) first round

a1 = {1}

pa1

pa1 rack A

rack A

rack B

rack B

b1 = {1}

pb1

c1 = {1}

pc1

c2 = {1}

pc2 rack C

c) conflict occurence

d) solution

Fig. 2. Example problem

1: A1 announce(ta , 1, ta , 2, tpa , 1, tpa , 2)→ 2: A2 –addlink{(ta , 1), (ta , 2), (tpa , 1), (tpa , 2)}→ – 3: A1 announce(tb , 1, tb , 2, tpb , 1, tpb , 2) → 4: A2 announce(tc , 1, tpc , 1) → 5: A1 ok?M a , {1, 2}, 0 → 6: A1 ok?M pa , {1}, 1 → 7: A1 ok?M pa , {2}, 2 → 8: A2 nogood¬(M a , {1, 2}, 0) → 9: A1 ok?M a , {1, 2}, 0 →

A2 A1 A2 A1 A2 A2 A2 A1 A3

Fig. 3. Trace of the solving process with AFCc -GCSP

following constraint γ8 as ’digital’ (c1 = 1). In order to reflect the interchangeability of value assignments, generic assignments using a meta-variable, a set of index values and their assigned value are exchanged in an ok? message. When agent A1 communicates the assignments to module variables a1 and a2 to agent A2 an inconsistency is detected by agent A2 (violation of constraint γ5 ). As agent A2 is not capable of locally resolving this conflict by changing his local assignments, he calculates a nogood and communicates it back to agent A1 (Figure 2.c ). Note, that we use here generic nogoods that exploit the interchangeability of the conflicting variables, e.g., all variables of type ta must not take the value 0. Agent A1 resolves the conflict by changing its variable assignments and finally a solution is found (Figure 2.d). In this simple example, the generic nogood involved only one type, but in general it can involve several variable types. Consequently, a solution to a generative constraint satisfaction problem requires not only finding valid assignments to variables, but also determining the exact size of the problem itself. In the sequel of the paper we define a model for a Generative constraint satisfaction problem of a local configurator and detail then the extensions to an asynchronous algorithms in order to be applicable for DisGCSPs.

3 Generative Constraint Satisfaction In many applications, solving is a generative process, where the number of involved components (i.e., variables) is not known from the beginning. To represent these problems we employ an extended formalism that complies to the specifics of configuration and other synthesis tasks. For efficiency reasons, problem variables representing components of the final system are generated dynamically as part of the solution process because their exact number cannot be determined beforehand. The framework is called generative CSP (GCSP) [10, 28]. This kind of dynamicity extends the approach of dynamic CSP (DCSP) formalized by Mittal and Falkenhainer [19], where all possibly involved variables have to be known from the beginning, since the activation constraints reason on the variable’s activity state. [20] propose a conditional CSP to model a configuration task, where structural dependencies in the configuration model are exploited to trigger the activation of subproblems. Another class of DCSP was first introduced by [6] where constraints can be added or removed independently of the initial problem statement. A GCSP is extended in order to find a consistent solution while the DCSP in [6] has already a solution and is extended due to influence from the outside world (e.g., additional constraints) that necessitates finding a new solution. Here we give a definition of a GCSP that abstracts from the specifically for configuration tasks formulated approach in [28] and applies to the wider range of synthesis problems. Exploiting incremental relaxation of the unary constraints in CSPs (as we introduce in GCSP) is a promising technique for approaching any CSP. To formally refer to states reached along this relaxation, a first attempt could consider the framework given by the following definition [7, 26]:

Definition 1 (Open Constraint Satisfaction Problems). An Open CSP (OCSP), O, is defined as a set of CSPs with the same variables and constraints6 , O(1), O(2), .... A partial order, ≺, is defined on O. O(i) ≺ O(j) when all the values in any domain of O(i) are also present in the corresponding domain of O(j). O(i) ≺ O(j) implies i < j. Excepting O(1), all other CSPs in O have a predecessor: ∀j > 1, ∃i, O(i) < O(j). The relation between an OCSP and a Generative CSP will be discussed in more depth in Section 3.2. 3.1

Generative Constraint Satisfaction

Definition 2 (Generative constraint satisfaction problem (GCSP)). A generative constraint satisfaction problem is a tuple GCSP(X0 , Γ , T , Δ0 ), where: – X0 is the set of initially given variables. – Γ is the set of generic constraints. – T = {t1 , . . . , tn } is the set of variable types ti , where dom(ti ) associates the same domain to each variable of type ti , where the domain is a set of atomic values. – For every type ti ∈ T there exists a counter variable xti ∈ X0 that holds the number of variable instantiations for type ti . Thus, explicit constraints involving the total number of variables of specific types and reasoning on the size of the CSP becomes possible. The set of counter variables is C. – Δ0 is a relation on X0 \C ×(T, N ), where N is the set of positive integer numbers. Each tuple (x, (t, i)) associates a variable x ∈ X \ C with a unique type t ∈ T and an index i, that indicates x is the ith variable of type t. The function type(x) accesses Δ0 and returns the type t ∈ T for x and the function index(x) returns the index of x. Definition 3 (Generic constraint). A meta-variable Mi is associated a variable type type(Mi ) ∈ T and must be interpreted as a placeholder for all concrete variables xj , where type(xj ) = type(Mi ). A generic constraint γ ∈ Γ formulates a restriction on the meta-variables Ma , . . . , Mk , and eventually on counter variables. By generating additional variables and relaxing unary constraints7 , a previously unsolvable CSP can become solvable, which is explained by the existence of counter variables that hold the number of variables. To concisely specify that a meta-variable Mi has type t, we denote it by Mit . When modeling a configuration problem, variables representing named connection points between components, i.e., ports, will have references to other components as their domain. Consequently, we need variables whose domain varies depending on the size of a set of specific variables [28]. Example Given ta as the type of variables representing modules and tpa as the type of port variables that are allowed to connect to modules, then the domain of the pa 6

7

[31] introduces the notion of constraints that can be known without knowing domains, as a source of privacy in ABT. Which can be dually seen as addition of values.

variables dom(tpa ) must contain references to modules. This is specified by defining t dom(tpa ) = {0, . . . , ∞}, by a meta-constraint M1pa