Many companies deploying mass customization strategies adopt product configuration systems to support their activities. While such systems focus mainly on configuration process support, mass customization needs to cover the management of the whole customizable product cycle. In this paper, we describe a graphical modeling framework that allows one to model both a product and its production process. We first introduce our framework. Then, we outline a possible implementation based on Constraint Logic Programming of such product/process configuration system. A comparison with some existing product configuration systems and process modeling tools concludes the paper.
Product configuration systems are software of interest for
companies deploying mass customization strategies, since
they can support them in the management of configuration
processes. In the past years many research studies have been
conducted on this topic
Process modeling tools, instead, allows one to effectively
deal with (business) process management. In general, they
allow the user to define a description of a process, and
guide she/he through the process execution. Also within
this field it is possible to find tools and scientific works
Mass customization needs to cover the management of the whole customizable product cycle, from product configuration to product production. Current product configuration systems and researches on product configuration, focus only on product modeling and on techniques for configuration process support. They do not cover product production process problematics, despite the advantages that coupling of product with process modeling and configuration could give.
This work is partially supported by GNCS and MIUR projects.
Inspired by the works of Aldanondo et al.
The paper is organized as follows. First, we introduce our framework in Sect. 2. Then, in Sect. 3 we show how a configuration system based on Constraint Logic Programming can be implemented on top of it. A comparison with some of the existing product configuration systems and process modeling tools is outlined in Sect. 4. An assessment of the work done and of future research directions is given in Sect. 5. 2
In this section, we present the PRODPROC graphical framework (cf. Sections 2.1 and 2.2). Moreover, we provide a brief description of PRODPROC semantics in terms of model instances (Sect. 2.3).
A PRODPROC model consists of a product description, a process description, and a set of constraints coupling the two. To better present the different modeling features offered by our framework, we will exploit a working example. In particular, we will consider a bicycle with its production process. 2.1
We are interested in modeling configurable products whose corresponding (producible) variants can be represented as trees. Nodes of these trees correspond to physical components, whose characteristics are all determined. The tree structure describes how the single components taken together define a configured product.
Hence, we model a configurable product as a multi-graph, called product model graph, and a set of constraints. Nodes of the multi-graph represent well-defined components of a product (e.g., the frame of a bicycle). While edges model haspart/is-part-of relations between product components. We require the presence of a node without entering edges in the product model graph. We call this node root node. A product model represents a configurable product. Its configuration can lead to the definition of different (producible) product variants.
Each node/component consists of a name, a set of variables modeling configurable characteristics of the component, and a set of constraints (called node constraints) involving variables of the node and variables of its ancestors in the graph. Each variable is endowed with a finite domain (typically, a finite set of integers or strings), i.e., the set of its possible values. Constraints define compatibility relations between configurable characteristics of a node and of its ancestors. The graphical representation of a node (cf. Fig. 1) consists of a box with three sections, each containing one of the elements constituting a node.
Node name Node variables Node constraints
Edge label Cardinality constraints
Node name
Node Card variables
Node constraints
In the description of a configured product, physical components are represented as instances of nodes in the product model graph. An instance of a node N odeN ame consists of the name N odeN ame, a unique id, and a set of variables equals to the one of N odeN ame. Each variable has a value assigned. The root node will have only one instance, such instance will be the root of the configured product tree.
Let us consider, for example, the node Frame of the (fragment of) product model graph for a bicycle, depicted in Fig. 2.1 The section Frame variables may contain the following couples of variables and domains: hF rameT ype; fRacing bike; Citybikegi; hF rameM aterial; fSteel; Aluminum; Carbongi: While in Frame constraints we may have the constraint
F rameT ype = Racing ) F rameM aterial 6= Steel: This constraint states that a frame of type racing can not be made of steel. An example of instance of F rame is the triple hF rame; 1; fF rameT ype = Racing; F rameM aterial = Carbongi. Note that values assigned to node instance variables have to satisfy all the node constraints. For the node Wheel (that also appears in Fig. 2) we may have the variables hW heelT ype; fRacing bike; City bikegi; hSpokeN umber; [18; 28]i; and the constraints
W heelT ype = hF rameT ype; F rame; [ ]i; (1) hF rameT ype; F rame; [rear wheel]i = Racing bike ) ) SpokeN umber > 20: (2) These constraints involve features belonging to an ancestor of the node Wheel, i.e., the node Frame. We refer to variables 1The depicted product model graph is one of the possible graphs we can define with our framework. We chose this one for presentation purposes only.
Frame Frame variables Frame constraints rear wheel rear gears constraints
Gears Gear variables Gear constraints in ancestors of a node using meta-variables, i.e., triples of the form hV arN ame; AncestorN ame; M etaP athi. This writing denotes a variable V arN ame in an ancestor node AncestorN ame (e.g., F rameT ype in F rame). The third component of a meta-variable, M etaP ath, is a list of edge labels (see below) describing a path connecting the two nodes in the graph (wildcards ‘ ’ and ‘?’ can be used to represent arbitrary labels and a sequence of arbitrary labels respectively). M etaP aths are used to define constraints that will have effect only on particular instances of a node. For example, the constraint (2) for the node W heel has to hold only for those instances of node W heel which are connected to an instance of node F rame through an edge labeled rear wheel. Intuitively, a node constraint for the node N has to hold for each instance of N , such that it has ancestors connected with it through paths matching with the M etaP aths occurring in the constraint.
An edge e = hlabel; N; M; Card; CCi of the product model graph is characterized by: a name (label), two node names denoting the parent (N ) and the child node (M ) in the has-part relation, the cardinality (Card) of such relation (expressed as either an integer number or an integer variable), and a set (CC) of constraints (called cardinality constraints). Such constraints may involve the cardinality variables (if any) as well as variables of the parent node and of its ancestors (referred to by means of meta-variables). An edge is graphically represented by an arrow connecting the parent node to the child node (cf. Fig. 1). Such an arrow is labeled with the edge name and cardinality, and may have attached an ellipse containing cardinality constraints.
An instance of an edge labeled label connecting a node N with a node M , is an edge connecting an instance of N and an instance of M . It is labeled label too.
Let us consider the edges front wheel and rear gear depicted in Fig. 2. The former is the edge relating the frame with the front wheel, its cardinality is imposed to be 1, and there is no cardinality constraint. Hence, there must be (only) one instance of the node Wheel connected to an instance of the node Frame through an edge labeled front wheel. The latter edge, rear gears, represents the has-part relation over the frame and the rear gears of a bicycle. Its cardinality is a variable named Card, taking values in the domain f0; 1g. Hence, we may have an instance of the node Gears connected to an instance of the node Frame through an edge labeled rear gears. Among the cardinality constraints of the edge rear gears we may have the following one:
F rameT ype = Racing ) Card = 1: Intuitively, a cardinality constraint for and edge e has to hold for each instance of the parent node N in e, such that N has ancestors connected with it through paths matching with M etaP aths occurring in the constraint.
As mentioned, we model a product as a graph and a set of constraints. Such constraints, called model constraints, involve variables of nodes not necessary related by haspart relations (node model constraints), as well as cardinalities of different edges exiting from a node (cardinality model constraints). Moreover, global constraints like alldifferent [van Hoeve, 2001] can be used to define node model constraints. In node model constraints, variables are referred to by means meta-variables. A M etaP ath in a node model constraint represents a path connecting a node to one of its ancestors in the graph. M etaP aths are used to limit the effect of a node model constraint to particular tuples of node instances. An example of node model constraint for the bicycle is the following one: hGearT ype; Gears; [rear gears]i = Special ) ) hSpokeN umber; W heel; [rear wheel]i = 26: (3) This constraint states that if the type of rear gears chosen is “Special”, then the rear wheel must have 26 spokes. Intuitively, a node model constraint has to hold for all the tuples of node variables of node instances reached by paths matching with the M etaP aths occurring in the constraint. 2.2
Processes can be modeled in PRODPROC in terms of activities and temporal relations between them. More precisely, a process is characterized by: a set of activities, a set of variables (as before, endowed with a finite domain of strings or of integers) representing process characteristics and involved resources; a set of temporal constraints between activities; a set of resource constraints; a set of constraints involving product elements; a set of constraints on activity durations. A process model does not represent a single production process. Instead, it represents a configurable production process, whose configuration can lead to the definition of different executable processes.
PRODPROC defines three kinds of activities: atomic activities, composite activities, and multiple instance activities. An atomic activity A is an event occurring in a time interval. It has associated a name and the following parameters.
Two integer decision variables, tstart and tend, denoting the start and end time of the activity. They define the tine interval [tstart; tend], and are subject to the implicit condition tend tstart 0. tstart denoting the duA decision variables d = tend ration of the activity.
A flag exec 2 f0; 1g.
We say that A is an instantaneous activity if d = 0. A is executed if exec = 1 holds, otherwise (i.e., if exec = 0) A is not executed. A composite activity is an event described in terms of a process. It has associated the same parameters of an atomic activity, and a model of the process it represents. A multiple instance (atomic or composite) activity is an event that may occur multiple times. Together with the Activity name Activity duration constraints (a)
Activity name Activity duration constraints (b)
Activity name Activity duration constraints
inst (c) usual parameters (and possibly the process model), a multiple instance activity has associated an integer decision variable (named inst) representing the number of times the activity can be executed. Note that the execution/non-execution of activities determines different instances of a configurable process. Figures 3a, 3b, and 3c, show the graphical representation of atomic activities, composite activities, and multiple instance activities, respectively.
Temporal constraints between activities are inductively defined starting from atomic temporal constraints. We consider as atomic temporal constraints all the thirteen mutually exclusive relations on time intervals introduced by Allen in [Allen, 1983] (they capture all the possible ways in which two intervals might overlap or not), and some other constraints inspired by constraint templates of the language ConDec [Pesic et al., 2007]. Some examples of atomic temporal constraints are listed as follows (for lack of space we avoid listing all of them), where A and B are two activities. Fig. 4 shows their graphical representations (we used a slightly different graphical notation for activities, i.e., we omitted the activity duration constraint sections).
1. A bef ore B to express that A is executed before B (cf.
Fig. 4a); 2. A during B to express that A is executed during the execution of B (cf. Fig. 4b); 3. A is absent to express that A can never be executed (cf. Fig. 4c); 4. A must be executed to express that A must be executed (cf. Fig. 4d); 5. A not co existent with B to express that it is not possible to executed both A and B (cf. Fig. 4e); 6. A succeeded by B to express that when A is executed then B has to be executed after A (cf. Fig. 4f).
The constraints 1 and 2 are two of the relations presented in [Allen, 1983]. The constraints 3-6 have been inspired by the templates used in ConDec [Pesic et al., 2007]. A temporal constraint is inductively defined as follows.
An atomic temporal constraint is a constraint.
If ' and # are temporal constraint, then ' and # and ' or # are temporal constraints.
If ' is a temporal constraint and c is a constraint on process variables, then c ! ' is an if-conditional temporal constraint, stating that ' has to hold whenever c holds. Also, c $ ' is an iff-conditional temporal constraint, stating that ' has to hold if and only if c holds. before during
c A conjunction of atomic constraints between two activities can be depicted by representing each constraint of the conjunction. Fig. 4g shows the graphical representation for a disjunction of atomic temporal constraints between two activities (i.e., for the constraint A bef ore B or A during B). An if-conditional and an iff-conditional temporal constraint with condition c are depicted in Fig. 4b and 4c, respectively. Finally, a non-atomic temporal constraint can be depicted as an hyper-edge connecting the activities involved in it, and labeled with the constraint itself.
The truth of atomic temporal constraints is related with the execution of the activities they involve. For instance, whenever for two activities A and B it holds that execA = 1 ^ execB = 1, then the atomic formulas of the forms 1 and 2 must hold. A temporal constraint network CN is a pair hA; Ci, where A is a set of activities and C is a set of temporal constraints on A. Fig. 5 shows the temporal constraint network of the bicycle production process.
Resource constraints [Laborie, 2003] are quadruple hA; R; q; T Ei, where A is an activity; R is a variable endowed with a finite integer domain; q is an integer or a variable endowed with a finite integer domain, defining the quantity of resource R consumed (if q < 0) or produced (if q > 0) by executing A; T E is a time extent that defines the time interval where the availability of resource R is affected by A. The possible values for T E are: F romStartT oEnd, Af terStart, Af terEnd, Bef oreStart, Bef oreEnd, Always, with the obvious meaning. Another form of resource constraint defines initial level constraints, i.e., expressions determining the quantity of a resource available at the time origin of a process. The basic form is initialLevel(R; iv), where R is a resource and iv 2 N. Examples of resource constraints for the bicycle production process are: hWheel construction; Aluminum; 4; Af terStarti; hFrame construction; W orkers;
qW 2 [ 1; 2]; F romStartT oEndi: The first constraint states that activity “Wheel construction” consumes 4 unit of aluminum once its execution starts. The second constraints states that activity “Frame construction” needs 1 or 2 workers during its execution. As for temporal constraint, we can define if-conditional (i.e., c ! hA; R; q; T Ei) and iff-conditional (i.e., c $ hA; R; q; T Ei) resource constraints. Their meaning are similar to the ones defined above for temporal constraints.
An activity duration constraint for an activity A, is a constraint involving the duration of A, process variables, and quantity variables for resources related to A. The following is an example of an activity duration constraint for the activity “Frame construction” in the bicycle production process (where F rameM ult is a process variable) d = 2 F rameMult
jqW j
PRODPROC also allows one to mix elements for modeling a process with elements for modeling a product, through constraints involving process variables and product variables. This is an example for the bicycle model
hF rameT ype; F rame; []i = Racing ) F rameM ult = 4: It relates the variable F rameT ype of the node F rame with the process variable F rameM ult. Another example is the following:
hrear gears; F rame; Gears; Cardi = Gears: This constraint relates the process variable Gears with the cardinality of the edge rear gears of the bicycle product model graph. The cardinality is represented by the quadruple hrear gears; F rame; Gears; Cardi, where the first element is an edge label, the second one is the name of the parent node of the edge, the third one is the name of the child node of the edge, and the last one is the name of the cardinality.
Product related constraints are another type of constraints coupling product elements with process elements. They make it possible to define resource constraints where resources are product components. More precisely, a product related constraint is a constraint on activities and product nodes that implicitly defines resource constraints, and constrains on process and product variables. A product related constraint has the form A produces n N f or B, where A and B are activities, n 2 N+, and N is the name of a node in the product model graph, having (at least) one incoming edge having associated a cardinality variable. Such a product related constraint corresponds to the following PRODPROC constraints: hA; RN ; qA 2 DRN ; Af terEndi; hB; RN ; n; Af terStarti; initialLevel(RN ; 0); aggConstraint(sum; CEN ; =; RN ); where RN is a resource variable whose domain DRN is defined as DRN = 0; PC2CEN max(DC ) (DC denotes the domain of C, and CEN is the list of cardinality variables of edges entering in N ). The constraint aggConstraint(sum; CEN ; =; RN ) is a global constraint stating that P = RN has to hold. An example of product relatedCc2oCnsEtNraint for the bicycle is
Wheel construction produces
2 W heel f or Bicycle assembly:
In general, constraints involving both product and process variables may allow one to detect/avoid planning impossibilities due to product configuration, and configuration impossibilities due to production planning, during the configuration of a product and its production process. 2.3
A PRODPROC model represents the collection of single (producible) variants of a configurable product and the processes to produce them. A PRODPROC instance represents one of such variants and its production process. To precisely define this notion we need to introduce first the notion of candidate instance. A PRODPROC candidate instance consists of the following components:
A set N I of node instances, i.e., tuples of the form N I = hN; i; VNiI i where N is a node in the product i model graph, i 2 N is an index (different for each instance of a node), VNiI = VN (VN is the set of variables of node N ). a set ANodes of assignments for all the node instance variables, i.e., expressions of the form V = value where V is a variable of a node instance and value belongs to the set of values for V .
A tree, called instance tree, that specifies the pairs of node instances in the relation has-part. Such a tree is defined as IT = hN I ; E I i, where E I is a set of tuples eI = hlabel; NiI ; MjI i such that there is an edge e = hlabel; N; M; Card; CCi in the product model graph, and N I , MjI are instances of N and M , respectively.
i A set ACards of assignments for all the instance cardinality variables, i.e., expressions of the form ICNeI = n i where NiI is an instance of a node N , e is an edge hlabel; N; M; Card; CCi, ICNeI = Card, and n is the i number of the edges hlabel; NiI ; CjI i in the instance tree, such that MjI is an instance of M .
A set AI of activity instances, i.e., pairs AiI = hA; ii where A is the name of an activity with execA = 1, and i 2 N is a unique index for instances of A.
A set E = fexecA j A is an activity ^ execA 6= 1g. A set AProc of assignments for all model variables and activity parameters (i.e., time instant variables, duration variables, execution flags, quantity resource variables, instance number variables), that is, expressions of the form P = value where P is a model variable or an activity parameter, and value 2 Z or value belongs to the set of values for P .
Fig. 6 depicts a fragment of the instance tree for a bicycle. The tree consists of an instance of node F rame, an instance of the node Gears, and two instances of node W heel.
A PRODPROC instance is a candidate instance such that the assignments in ANodes [ ACards [ AP roc satisfy all the constraints in the PRODPROC model (node constraints, temporal constraints, etc.), instantiated with variables of node instances and activity instances in the candidate instance.
The constraint instantiation mechanism, given a (partial) candidate instance (a candidate instance is partial when there are variables with no value assigned to), produces a set of constraints on candidate instance variables from each constraint in the corresponding PRODPROC model. A candidate instance has to satisfy all these constraints to qualify as an instance. We give here an intuitive description of how the instantiation mechanism works on different constraint types. Let us begin with node and cardinality constraints. Let c be a constraint belonging to the node N , or a constraint for an edge e between nodes N and M . Let us suppose that N1; : : : ; Nk are ancestors of N whose variables are involved in c, and let p1; : : : ; pk be M etaP aths such that, for i = 1; : : : ; k, pi is a M etaP ath from Ni to N . We define Ln as the set of ktuple of node instances hNjI ; (N1)jI1 ; : : : ; (Nk)jk i where: N I I j is an instance of N ; for i = 1; : : : ; k (Ni)jIi is an instance of Ni, connected with NjI through a path piI in the instance tree that matches with pi. For each k-tuple t 2 Ln, we obtain a constraint on instance variables appropriately substituting variables in c with variables of node instances in t. For example, the constraints (1) and (2) for the node W heel, lead to the following constraints on variables of node instances in Fig. 6 (hV; N I
IDi denotes the variable V of the instance with id ID of node N ).
hW heelT ype;W heel1Ii=hF rameT ype;F rameI1i; hW heelT ype;W heel2Ii=hF rameT ype;F rameI1i; hF rameT ype;F rameI1i=Racing bike) )hSpokeNumber;W heel2Ii>20: (4) (5) (6) The instantiation of (1) leads to the constraints (4) and (5), since it can be instantiated on both the couples of node instances appearing in Fig. 6 hW heel1I; F rameI1i and hW heel2I; F rameI1i. Instead, the instantiation of (2) leads to only one constraint, i.e. (6), because it can be instantiated only on the couple hW heel2I; F rameI1i.
Node model constraints are instantiated in a slightly different way. Let c be a node model constraint. Let us suppose that N1; : : : ; Nk are the nodes whose variables are involved in c, let p1; : : : ; pk be M etaP aths such that, for i = 1; : : : ; k, pi is a M etaP ath that ends in Ni. We define Lnmc as the set of ordered k-tuples of node instances h(N1)jI1 ; : : : ; (Nk)jk i I , where for i = 1; : : : ; k (Ni)jIi is an instance of Ni connected by a path piI with one of its ancestors in the instance tree, such that piI matches with pi. For each k-tuple t 2 Lnmc, we obtain a constraint on instance variables appropriately substituting variables in c with variables of node instances in t. If c is an alldifferent constraint, then we define an equivalent constraint on the list consisting of all the node instances of N1; : : : ; Nk, connected with one of their ancestors by a path matching with the corresponding M etaP ath. As an example, let us consider the constraint (3) for the bicycle, it can be instantiated on the couple hW heel2I; GearsI1i and leads to hGearT ype; GearsI1i = Special )
) hSpokeN umber; W heel2Ii = 26:
The instantiation of cardinality model constraints is very simple. Let c be a cardinality model constraint for the cardinalities of the edges with labels e1; : : : ; ek exiting from a node N . Let N1I ; : : : ; NhI be instances of N . For all i 2 f1; : : : ; hg, we instantiate c appropriately substituting the cardinality variables occurring in it, with the instance cardinality variables ICNe1I ; : : : ; ICNekI .
i i
Let us now consider process constraints. Let A be an activity, let AI1; : : : ; AIk be instances of A. Let r be the resource constraint hA; R; q; T Ei, we instantiate it on each instance of A, i.e., we obtain a constraint hAI ; R; qi; T Ei for each i i = 1; : : : ; k, where qi = q is a fresh variable or an integer. Let c be an activity duration constraint for A, for each i = 1; : : : ; k we obtain a constraint substituting in c dA with dAI , and each quantity variable q with the corresponding varii able qi. Finally, let B an activity, let B1I ; : : : ; BhI be instances of B. If c is a temporal constraint involving A and B, we obtain a constraint on activity instances for each ordered couple hi; ji, with i 2 f1; : : : ; kg, j 2 f1; : : : ; hg, substituting in c each occurrence of A with AI , and of B with BI . This i j mechanism can be easily extended to non-binary constraints. 3
Constraint Logic Programming (CLP) [Jaffar and Maher, 1994] can be exploited to implement a configuration system that, given a PRODPROC model (cf. Sect. 2), guide a user through the configuration process to obtain a PRODPROC instance (cf. Sect. 2.3). In this section, we first present a possible structure for such a system. Then, we briefly explain how a configuration problem can be encoded in a CLP program.
A CLP-based system can support a configuration process as follows. First, the user initializes the system (1) selecting the model to be configured. After such an initialization phase, the user starts to make her/his choices by using the system interface (2). The interface communicates to the system engine (i.e., the piece of software that maintains a representation of the product/process under configuration, and checks the validity and consistency of user’s choices) each data variation specified by the user (3). The system engine updates the current partial configuration accordingly. Whenever an update of the partial configuration takes place, the user, through the system interface, can activate the engine inference process (4). The engine instantiates PRODPROC constraints (cf. Sect. 2.3) on the current (partial) candidate instance defined by user choices, and encodes the product/process configuration problem in a CLP program (encoding a Constraint Satisfaction Problem, abbreviated to CSP). Then, the engine uses a finite domain solver to propagate the logical effects of user’s choices (5). Once the inference process ends (6), the engine returns to the interface the results of its computation (7). In its turns, the system interface communicates to the user the consequences of her/his choices on the (partial) configuration (8).
From a PRODPROC model and a user defined (partial) candidate instance corresponding to it, it is possible to obtain a CSP hV; D; Ci where: V is the set of all the variables appearing in the (partial) candidate instance; D is the set of domains for variables in V; C is the set of constraints in the PRODPROC model instantiated on variables of the (partial) candidate instance. Such a CSP can be easily encoded in a CLP program like the following one. csp_prodProc(Vars) :- DOMS, CONSTRS.
In it, Vars is the list of variables in V, DOMS is the conjunction of domain constraints for domains in D, and CONSTRS is the conjunction of constraints in C. Given a program with the above-described characteristics, a finite domain solver can be used to reduce the domains associated with variables, preserving satisfiability, or to detect the inconsistency of the encoded CSP (due to user’s assignments that violate the set of constraints or to inconsistencies of the original product model). Moreover, it can be used to determine that further node instances are needed, or that there are too many nodes in the instance tree. 4
In order to point out strengths and limitations of the PRODPROC framework, we present in this section a brief comparison with some of the most important product configuration systems and process modeling tools.
Answer Set Programming (ASP) [Gelfond and Lifschitz, 1988] has been used to implement product configuration systems that are specifically tailored to the modeling of software product families, e.g., Kumbang Configurator [Mylla¨rniemi et al., 2005]. Even if these systems result to be appealing for a relevant range of application domains, they lack of generality. In particular, they do not support global constraints, and the so called grounding stage may cause problems in the management of arithmetic constraints [Mylla¨rniemi et al., 2005].
Product configuration systems based on binary decision
diagrams (BDDs), e.g., Configit Product Modeler [Configit
A/S, 2009], trade the complexity of the construction of the
BDD, for the simplicity and efficiency of the configuration
process. Despite their various attracting features,
BDDbased systems suffer from some significant limitations. First,
they basically support flat models only, even though some
work has been done on the introduction of modules
Unlike ASP-based and BDD-based systems, CSP-based product configuration systems are (usually) capable of dealing with non-flat models and global constraints. Unfortunately, the modeling expressiveness of CSP-based systems has a cost, i.e., backtrack-free configuration algorithms for CSP-based systems are often inefficient, while non backtrack-free ones need to explicitly deal with dead ends. Moreover, most CSP-based systems do not offer high-level modeling languages (product models must be specified at the CSP level). Some well-known CSP-based configuration systems, such as ILOG Configurator [Junker, 2003], which features various interesting modeling facilities, and Lava [Fleischanderl et al., 1998], which is based on Generative-CSP, seem to be no longer supported. A recent CSP-based configuration system is Morphos Configuration Engine (MCE) [Campagna et al., 2010]. As other CSPbased systems, it makes it possible to define non-flat models. Its configuration algorithm is not backtrack-free, but it exploits back-jumping capabilities, to cope with dead ends, and branch-and-prune capabilities, to improve domain reduction. From the point of view of process modeling, PRODPROC can be viewed as an extension of MCE modeling language. In particular, it extends MCE modeling language with the following features: (1) cardinality variables, i.e., has-part/ispart-of relations can have non-fixed cardinalities; (2) product model graph, i.e., nodes and relations can define a graph, not only a tree; (3) cardinality constraints and cardinality model constraints, i.e., constraints can involve cardinalities of relations; (4) M etaP aths, i.e., a mechanism to refer to particular node instance variables in constraints.
PRODPROC can be viewed as the source code representation of a configuration system with respect to the MDA abstraction levels presented in [Felfernig, 2007]. PRODPROC product modeling elements can be mapped to UML/OCL in order to obtain platform specific (PSM) and platform independent (PIM) models. The mapping to OCL of M etaP aths containing ‘?’ wildcards and of model constraints requires some attention. For example, the latter do not have explicit contexts as OCL constraints must have. Since PRODPROC does not support the definition of taxonomies of product components, there will not be generalization hierarchies in PMSs and PIMs corresponding to PRODPROC models.
In the past years, different formalism have been proposed for process modeling. Among them we have: the Business Process Modeling Notation (BPMN) [White and Miers, 2008]; Yet Another Workflow Language (YAWL) [ter Hofstede et al., 2010]; DECLARE [Pesic et al., 2007].
Languages like BPMN and YAWL model a process as a detailed specification of step-by-step procedures that should be followed during the execution. BPMN and YAWL adopt an imperative approach in process modeling, i.e., all possibilities have to be entered into their models by specifying their control-flows. BPMN has been developed under the coordination of the Object Management Group. PRODPROC has in common with BPMN the notion of atomic activity, subprocess, and multiple instance activity. The effect of BPMN joins and splits on the process flow can be obtained using temporal constraints. In PRODPROC there are no notions such as BPMN events, exception flows, and message flows. However, events can be modeled as instantaneous activities and data flowing between activities can be modeled with model variables. YAWL is a process modeling language whose intent is to directly supported all control flow patterns. PRODPROC has in common with YAWL the notion of task, multiple instance task, and composite task. YAWL join and split constructs are not present in PRODPROC, but using temporal constraints it is possible to obtain the same expressivity. The notion of cancellation region is not present in PRODPROC, but our framework could be extended to implement it.
As opposed to traditional imperative approaches to process modeling, DECLARE uses a constraint-based declarative approach. Its models rely on constraints to implicitly determine the possible ordering of activities (any order that does not violate constraints is allowed). With respect to DECLARE, PRODPROC has in common the notion of activity and the use of temporal constraints to define the control flow of a process. The set of atomic temporal constraints is not as big as the set of template constraints available in DECLARE, however it is possible to easily the available ones so as to define all complex constraints of practical interest. Moreover, in PRODPROC it is possible to define multiple instance and composite activities, features that are not available in DECLARE.
From the point of view of process modeling, PRODPROC combines modeling features of languages like BPMN and YAWL, with a declarative approach for control flow definition. Moreover, it presents features that, to the best of our knowledge, are not presents in other existing process modeling languages. These are: resource variables and resource constraints, activity duration constraints, and product related constraints. Thanks to these features, PRODPROC is suitable for modeling production processes and, in particular, to model mixed scheduling and planning problems related to production processes. Furthermore, a PRODPROC model does not only represent a process ready to be executed as a YAWL (or DECLARE) model does, it also allows one to describe a configurable process. Existing works on process configuration, e.g., [Rosa, 2009], define process models with variation points, and aim at deriving different process model variants from a given model. Instead, we are interested in obtaining process instances, i.e., solutions to the scheduling/planning problem described by a PRODPROC model.
With respect to the works of Mayer et al. on service
process composition
The PRODPROC framework allows one to model products,
their production processes, and to couple products with
processes using constraints. The only works on the coupling of
product and process modeling and configuration we are aware
of are the ones by Aldanondo et al.
In this paper, we considered the problem of product and process modeling and configuration, and pointed out the the lack of a tool covering both physical and production aspects of configurable products. To cope with this absence, we presented a graphical framework called PRODPROC. Furthermore, we shown how it is possible to build a CLP-based configuration systems on top of it, and presented a comparison with some of the existing product configuration systems and process modeling tools.
We already implemented a first prototype of a CLP-based configuration system that uses PRODPROC. It covers only product modeling and configuration, but we are working to add to it process modeling and configuration capabilities. We also plan to experiment our configuration system on different real-world application domains, and to compare it with commercial products, e.g., [Blumo¨hr et al., 2009].